date:20181104

Bug#856573: chromium: pulldown menus not working (not pulling down)

2018-11-04 Thread Mark Carroll

I see the problem even in Chromium 69 with both twm and ctwm.

>From the three vertical dots I sometimes see a quick flash of
something but it disappears just as soon as it appears.

-- Mark

Bug#912907: jackd2 FTCBFS

2018-11-04 Thread Helmut Grohne

Source: jackd2
Version: 1.9.12~dfsg-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

jackd2 fails to cross build from source. The (host) python dependency is
not installable as its postinst fails. jackd2 really wants a build
architecture python for running waf though. Annotating it with :any
fixes that part. Then waf builds for the build architecture. For this
package providing the variables CC, CXX and PKGCONFIG is enough to make
it work. Please consider applying the attached patch.

Helmut
diff --minimal -Nru jackd2-1.9.12~dfsg/debian/changelog 
jackd2-1.9.12~dfsg/debian/changelog
--- jackd2-1.9.12~dfsg/debian/changelog 2018-02-25 20:41:33.0 +0100
+++ jackd2-1.9.12~dfsg/debian/changelog 2018-11-04 21:13:15.0 +0100
@@ -1,3 +1,12 @@
+jackd2 (1.9.12~dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Request the build architecture python for waf.
++ Tell waf which CC/CXX/PKGCONFIG to use.
+
+ -- Helmut Grohne   Sun, 04 Nov 2018 21:13:15 +0100
+
 jackd2 (1.9.12~dfsg-2) unstable; urgency=medium
 
   * Source-only re-upload to avoid pre-built amd64 binary
diff --minimal -Nru jackd2-1.9.12~dfsg/debian/control 
jackd2-1.9.12~dfsg/debian/control
--- jackd2-1.9.12~dfsg/debian/control   2018-02-25 19:36:15.0 +0100
+++ jackd2-1.9.12~dfsg/debian/control   2018-11-04 21:11:21.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: cdbs (>= 0.4.93~),
  debhelper (>= 9),
  d-shlibs,
- python (>= 2.6.6-3~),
+ python:any (>= 2.6.6-3~),
  dh-python,
  libsamplerate-dev,
  libasound2-dev (>= 1.0.18) [linux-any],
diff --minimal -Nru jackd2-1.9.12~dfsg/debian/rules 
jackd2-1.9.12~dfsg/debian/rules
--- jackd2-1.9.12~dfsg/debian/rules 2018-02-25 19:36:15.0 +0100
+++ jackd2-1.9.12~dfsg/debian/rules 2018-11-04 21:13:15.0 +0100
@@ -4,6 +4,7 @@
 export DEB_CFLAGS_MAINT_APPEND = -fvisibility=hidden
 export DEB_CXXFLAGS_MAINT_APPEND = -fvisibility=hidden
 
+-include /usr/share/dpkg/buildtools.mk
 -include /usr/share/cdbs/1/rules/upstream-tarball.mk
 -include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
@@ -35,7 +36,7 @@
 # Minimum assured version referenced upstream as library API/ABI
 ABI = 0.118.0
 
-WAF_EXTRA_ARGS = $(filter-out -j%,$(DEB_MAKE_EXTRA_ARGS))
+WAF_EXTRA_ARGS = CC='$(CC)' CXX='$(CXX)' PKGCONFIG='$(PKG_CONFIG)' 
$(filter-out -j%,$(DEB_MAKE_EXTRA_ARGS))
 
 waf-configure-options = --prefix=/usr --classic
 waf-configure-options += --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread James Bottomley

On Sun, 2018-11-04 at 21:10 +0100, Kurt Roeckx wrote:
> On Sun, Nov 04, 2018 at 11:39:59AM -0800, James Bottomley wrote:
> > > 
> > > On which side do you use tls-version-min?
> > 
> > client
> > 
> > >  Can you please give the version of both openvpn and openssl on
> > > both
> > > sides.
> > 
> > Client is openwrt, server is debian testing.  The package of the
> > server
> > was already provided in the bug report, but again it's
> > 
> > openssl 1.1.1-2
> > openvpn 2.4.6-1
> > 
> > Packages on the openwrt client are
> > 
> > libopenssl 1.0.2g-1
> > openvpn-openssl  2.3.6-5
> 
> So you're saying that even with tls-version-min 1.0 on your
> client side and with openssl.cnf changed on the server it's still
> not working?

No, I'm saying with no client tls-version-min specified at all (the
usual default openvpn config) it fails in 1.1.1 and works with 1.1.0

With client tls-version-min set to 1.0 it works with both.

James

Bug#912864: [Pkg-openssl-devel] Bug#912864: Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread Sebastian Andrzej Siewior

On 2018-11-04 11:39:59 [-0800], James Bottomley wrote:
> > > OK, so I'm weary of trying to construct a theory of what the bug
> > > actually is, why don't you try to come up with one.  The symptoms
> > > are
> > > that openvpn in openwrt works with server 1.1.0 and fails with
> > > server
> > > 1.1.1 if you don't specify tls-version-min 1.0 on the command line.
> > 
> > On which side do you use tls-version-min?
> 
> client
> 
> >  Can you please give the version of both openvpn and openssl on both
> > sides.
> 
> Client is openwrt, server is debian testing.  The package of the server
> was already provided in the bug report, but again it's
> 
> openssl 1.1.1-2
> openvpn 2.4.6-1
> 
> Packages on the openwrt client are
> 
> libopenssl 1.0.2g-1
> openvpn-openssl  2.3.6-5

That matches what I see. The Jessie version (which matches your openwrt
client) does TLSv1.0 only by default. If you specify tls-version-min
(even 1.0) then it tries 1.0+ and does the best possible protocol which
is TLS1.2 in my case.
Stretch seems to do the best possible version by default.
Buster/Testing has TLS1.0 disabled by default.
So in your environment the client tries TLS1.0 only and server does
TLS1.2 only. Adding tls-version-min on the client side enables
TLS1.0+ and handshakes with TLS1.2.

This behaviour has been reported as #912650 on the Debian side.

> James

Sebastian

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread Kurt Roeckx

On Sun, Nov 04, 2018 at 11:39:59AM -0800, James Bottomley wrote:
> > 
> > On which side do you use tls-version-min?
> 
> client
> 
> >  Can you please give the version of both openvpn and openssl on both
> > sides.
> 
> Client is openwrt, server is debian testing.  The package of the server
> was already provided in the bug report, but again it's
> 
> openssl 1.1.1-2
> openvpn 2.4.6-1
> 
> Packages on the openwrt client are
> 
> libopenssl 1.0.2g-1
> openvpn-openssl  2.3.6-5

So you're saying that even with tls-version-min 1.0 on your
client side and with openssl.cnf changed on the server it's still
not working? Either of those changes should be enough to get it
working as far as I understand.

I have almost the reverse in my setup, where the server is 2.3.4
and the client runs testing. On the server I've set the
tls-version-min 1.0 and everything works for me.

I will try to look at this in a few days.

Kurt

Bug#912906: vtk-dicom: build only for the default python3 version but build-depends on python3-all-dev

2018-11-04 Thread Mattia Rizzolo

Source: vtk-dicom
Version: 0.8.7-1~exp1
Severity: important

Dear maintainer,


your new upload of src:vtk-dicom added python3 bindings for vtk-dicom.
Thanks for them!

Unfortunately you added a build-dependency on python3-all-dev, which
pulls in all the supported python3 versions and kind of implies you are
going to build for all of them.  But in reality you are building only
for the default one.
This causes unwanted noise during times of transitions, like this, as it
makes your package appear in the transition tracker even when nothing
can be done.

If making the build system build for all python3 versions is hard (as I
suspect it is, as it's not usually straightforward with cmake) please
change the build dependency on "python3-dev", so to pull in only the
stuff related to the default python3 version.

debian-python@ is available for more information in case you have any
doubt.


-- 
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#912905: ceph: build only for the default python3 version but build-depends on python3-all-dev

2018-11-04 Thread Mattia Rizzolo

Source: ceph
Version: 12.2.8+dfsg1-1
Severity: important

Dear maintainer,


your new upload of src:ceph added python3 bindings for ceph.
Thanks for them!

Unfortunately you added a build-dependency on python3-all-dev, which
pulls in all the supported python3 versions and kind of implies you are
going to build for all of them.  But in reality you are building only
for the default one.
This causes unwanted noise during times of transitions, like this, as it
makes your package appear in the transition tracker even when nothing
can be done.

If making the build system build for all python3 versions is hard (as I
suspect it is, as it's not usually straightforward with cmake) please
change the build dependency on "python3-dev", so to pull in only the
stuff related to the default python3 version.

debian-python@ is available for more information in case you have any
doubt.

-- 
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#912904: v4l-utils FTCFBS due to clang dependency

2018-11-04 Thread Helmut Grohne

Source: v4l-utils
Version: 1.16.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

v4l-utils' build dependency on clang poses issues for cross compilation.
The dependency asks for the host architecture clang, which cannot be
run. It's not obvious that just changing it to the build architecture
clang works as clang has an architecture-dependent default target.
However, v4l-utils uses clang for compiling bpf sources and therefore
always passes -target to clang. And that means we can indeed safely
annotate it with :native. Please consider applying the attached patch.

Helmut
diff --minimal -Nru v4l-utils-1.16.1/debian/changelog 
v4l-utils-1.16.1/debian/changelog
--- v4l-utils-1.16.1/debian/changelog   2018-10-18 20:18:22.0 +0200
+++ v4l-utils-1.16.1/debian/changelog   2018-11-04 20:44:51.0 +0100
@@ -1,3 +1,10 @@
+v4l-utils (1.16.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate clang Build-Depends with :native. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 04 Nov 2018 20:44:51 +0100
+
 v4l-utils (1.16.1-1) unstable; urgency=low
 
   * Imported Upstream version 1.16.1
diff --minimal -Nru v4l-utils-1.16.1/debian/control 
v4l-utils-1.16.1/debian/control
--- v4l-utils-1.16.1/debian/control 2018-10-18 20:18:22.0 +0200
+++ v4l-utils-1.16.1/debian/control 2018-11-04 20:44:51.0 +0100
@@ -7,7 +7,7 @@
 Build-Depends: debhelper (>= 8.1.3),
dh-autoreconf,
autotools-dev,
-   clang,
+   clang:native,
doxygen,
gettext,
graphviz,

Bug#912903: wm-icons: Please drop olwm and olvwm from Enhances: list

2018-11-04 Thread Boyuan Yang

Package: wm-icons
Severity: normal
Version: 0.4.0-10

Dear wm-icons maintainer,

Debian's FTP Masters just removed src:xview from Debian archive. As a
result, package olwm and olvwm both disappeared from the archive.
Please do not list them in the Enhances: list anymore.

If you need any help in it, please feel free to let me know.

--
Regards,
Boyuan Yang

Bug#912820: pkgsel 0.45+deb9u2 flagged for acceptance

2018-11-04 Thread Adam D Barratt

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: pkgsel
Version: 0.45+deb9u2

Explanation: install new dependencies when safe-upgrade (default) is selected

Bug#912902: mariadb-10.1: FTBFS on !linux

2018-11-04 Thread Samuel Thibault

Source: mariadb-10.1
Version: 1:10.1.35-1
Severity: important
Tags: patch

Hello,

mariadb-10.1 currently can't be built on !linux because it build-depends
on libsystemd-dev, which is not built any more on !linux. I have
attached a patch.

The Hurd build also needs a cmake file to properly enable _GNU_SOURCE
just like on Linux, I have attached a hurd.patch.

The installation file lists also need fixing, I have attached patch2.

And debian/libmariadbclient18.install will need a chmod +x

Samuel

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

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

-- 
Samuel
/*
 * Oops. The kernel tried to access some bad page. We'll have to
 * terminate things with extreme prejudice.
*/
die_if_kernel("Oops", regs, error_code);
(From linux/arch/i386/mm/fault.c)  
Index: mariadb-10.1-10.1.35/cmake/os/GNU.cmake
===
--- /dev/null
+++ mariadb-10.1-10.1.35/cmake/os/GNU.cmake
@@ -0,0 +1,33 @@
+
+# Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.
+# 
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; version 2 of the License.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA 
+
+# This file includes GNU/Hurd specific options and quirks, related to system checks
+
+INCLUDE(CheckSymbolExists)
+
+# Something that needs to be set on legacy reasons
+SET(_GNU_SOURCE 1)
+SET(CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS} -D_GNU_SOURCE=1)
+
+# Ensure we have clean build for shared libraries
+# without unresolved symbols
+# Not supported with AddressSanitizer
+IF(NOT WITH_ASAN)
+  SET(LINK_FLAG_NO_UNDEFINED "-Wl,--no-undefined")
+ENDIF()
+
+# 64 bit file offset support flag
+SET(_FILE_OFFSET_BITS 64)
--- debian//mariadb-server-10.1.install.original2018-11-04 
18:24:40.0 +
+++ debian//mariadb-server-10.1.install 2018-11-04 18:25:06.0 +
@@ -83,9 +83,9 @@
 usr/share/mysql/policy/selinux/mariadb-server.fc
 usr/share/mysql/policy/selinux/mariadb-server.te
 usr/share/mysql/policy/selinux/mariadb.te
-usr/share/mysql/systemd/use_galera_new_cluster.conf
-usr/share/mysql/systemd/mariadb.service
-usr/share/mysql/systemd/mariadb@.service
+[linux-any] usr/share/mysql/systemd/use_galera_new_cluster.conf
+[linux-any] usr/share/mysql/systemd/mariadb.service
+[linux-any] usr/share/mysql/systemd/mariadb@.service
 usr/share/mysql/wsrep_notify
 usr/share/mysql/mysql.server
 usr/share/mysql/my-large.cnf
--- debian/libmariadbclient18.install.original  2018-11-04 18:26:33.0 
+
+++ debian/libmariadbclient18.install   2018-11-04 18:26:41.0 +
@@ -1,5 +1,6 @@
+#!/usr/bin/dh-exec
 usr/lib/*/libmariadbclient.so.*
 usr/lib/*/mariadb18/plugin/client_ed25519.so
 usr/lib/*/mariadb18/plugin/dialog.so
-usr/lib/*/mariadb18/plugin/disks.so
+[!hurd-i386] usr/lib/*/mariadb18/plugin/disks.so
 usr/lib/*/mariadb18/plugin/mysql_clear_password.so
--- debian/control.original 2018-11-04 18:09:56.0 +
+++ debian/control  2018-11-04 18:10:00.0 +
@@ -22,7 +22,7 @@
libpam0g-dev,
libpcre3-dev (>= 2:8.35-3.2~),
libreadline-gplv2-dev,
-   libsystemd-dev,
+   libsystemd-dev [linux-any],
libxml2-dev,
lsb-release,
perl,

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread James Bottomley

On Sun, 2018-11-04 at 20:32 +0100, Kurt Roeckx wrote:
> On Sun, Nov 04, 2018 at 11:19:41AM -0800, James Bottomley wrote:
> > On Sun, 2018-11-04 at 20:15 +0100, Kurt Roeckx wrote:
> > > This is not at all how the version negiotation in TLS 1.2 and
> > > below works. The client just indicates the highest version it
> > > supports, so for instance TLS 1.2. It's then up to the server to
> > > pick a version that the client supports, so one that is smaller
> > > than
> > > TLS 1.2, and it might pick TLS 1.0 or 1.2. It will then send a
> > > server
> > > hello with that version.
> > 
> > OK, so I'm weary of trying to construct a theory of what the bug
> > actually is, why don't you try to come up with one.  The symptoms
> > are
> > that openvpn in openwrt works with server 1.1.0 and fails with
> > server
> > 1.1.1 if you don't specify tls-version-min 1.0 on the command line.
> 
> On which side do you use tls-version-min?

client

>  Can you please give the version of both openvpn and openssl on both
> sides.

Client is openwrt, server is debian testing.  The package of the server
was already provided in the bug report, but again it's

openssl 1.1.1-2
openvpn 2.4.6-1

Packages on the openwrt client are

libopenssl 1.0.2g-1
openvpn-openssl  2.3.6-5

James

Bug#912695: apt-show-versions: breaks "apt-get update" and uninstallable after Perl 5.28 upgrade

2018-11-04 Thread Niko Tyni

On Sun, Nov 04, 2018 at 06:09:36PM +0100, Salvatore Bonaccorso wrote:

> This is likely due to the perl upstream change around/with
> https://perl5.git.perl.org/perl.git/commitdiff/c0e3b4b51cabf15ed8fc5f564dfeea31c25f5239
> .
> 
> It can be workarounded by either setting higher limits for
> recursion_limit/recursion_limit_hash or disable it with -1
> 
> $Storable::recursion_limit=-1;
> $Storable::recursion_limit_hash=-1;
> 
> but I'm not sure this will be the right solution.

Thanks. I've filed #912900 about this on the Perl side. Christoph:
please use these workarounds at least for now. Apologies for the trouble.

Also, please let us know at p...@packages.debian.org when a workaround
is in Debian. We can then add dependency metadata on the perl side to
make sure apt-show-versions gets always upgraded before perl.

Longer term, I'm not sure Storable is the best tool for this (a cache
of apt list contents.) AFAICS you're reading the whole data structure
in memory even when you need just one entry? You might want to look at
the various Cache / CHI modules, or even just plain GDBM_File.
-- 
Niko Tyni   nt...@debian.org

Bug#912044: pbuilder config

2018-11-04 Thread Thorsten Alteholz


Hi Daniel,

thanks for your report. Can you please be a bit more verbose on how your 
pbuilder and chroot is configured? At the moment I am not able to 
reproduce the failure.


Thanks!
 Thorsten

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread Kurt Roeckx

On Sun, Nov 04, 2018 at 11:19:41AM -0800, James Bottomley wrote:
> On Sun, 2018-11-04 at 20:15 +0100, Kurt Roeckx wrote:
> > This is not at all how the version negiotation in TLS 1.2 and
> > below works. The client just indicates the highest version it
> > supports, so for instance TLS 1.2. It's then up to the server to
> > pick a version that the client supports, so one that is smaller than
> > TLS 1.2, and it might pick TLS 1.0 or 1.2. It will then send a server
> > hello with that version.
> 
> OK, so I'm weary of trying to construct a theory of what the bug
> actually is, why don't you try to come up with one.  The symptoms are
> that openvpn in openwrt works with server 1.1.0 and fails with server
> 1.1.1 if you don't specify tls-version-min 1.0 on the command line.

On which side do you use tls-version-min? Can you please give the
version of both openvpn and openssl on both sides.


Kurt

Bug#912901: mpich: FTBFS on hppa - testsuite timeout

2018-11-04 Thread John David Anglin

Source: mpich
Version: 3.3~b3-4
Severity: normal

Dear Maintainer,

The mpich build fails on hppa due to a timeout in the testsuite:

libtool: link: gcc -g -O2 "-fdebug-prefix-map=/<>=." -Wformat 
-Werror=format-security -o test_primitives test_primitives.o  -L../src 
/<>/src/openpa/src/.libs/libopa.a -lpthread
make[5]: Leaving directory '/<>/src/openpa/test'
make  check-TESTS
make[5]: Entering directory '/<>/src/openpa/test'
make[6]: Entering directory '/<>/src/openpa/test'
PASS: sanity
PASS: test_barriers
PASS: test_queue
E: Build killed with signal TERM after 150 minutes of inactivity

Build finished at 2018-11-04T05:51:50Z

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=mpich=hppa=3.3%7Eb3-4=1541310729=0

If one waits long enough (roughly 230 minutes), test_primitives completes
successfully.

Would it be possible to output some progress information in test_primitives
to avoid the timeout?

Regards,
Dave Anglin

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

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

-- no debconf information

Bug#912768: hplip-data: hp-toolbox fsck

2018-11-04 Thread Brian Potkin

On Sun 04 Nov 2018 at 20:03:52 +0100, Till Kamppeter wrote:

> Brian, if the user only wants to print with his printer (is it a print-only
> device or a multi-function device with scanner) driverless IPP printing
> works indeed, especially with HP devices. Then this is the recommended
> solution.

Till, as I said, I know I am not addressing the bug report directly, but
my skills do not extend to code writing; you have indicated a way forward
in this regard. Roll on driverless printing and raising users' awareness
it exists.

> Only for scanning one still needs drivers and in case of HP's multi-function
> devices HPLIP (a driverless IPP scanning standard is already there, but not
> yet adopted in actual hardware).

I was prepared to come to the question of scanning later. This does need
stuff from HP (which has done well by me) but not as much as provided by
the hplip package.

  apt install libsane-hpaio --no-install-recommends

gets everything needed for scanning.

Regards,

Brian.

Bug#857467: libreoffice-base: Postgresql — Cannot enter or edit data or edit table columns without primary key

2018-11-04 Thread Stéphane Aulery


Hello,

Le 30/10/2018 à 09:38, Lionel Elie Mamane a écrit :

On Tue, Oct 30, 2018 at 01:17:49AM +0100, Stéphane Aulery wrote:

forwarded 857467 https://bugs.documentfoundation.org/show_bug.cgi?id=45252


No, that upstream bug is about something else, namely that the
PostgreSQL SDBC driver does not implement changing table structure,
creating tables, deleting tables, etc. Only data manipulation (adding
rows, changing rows, deleting rows).

This Debian bug is that data manipulation is not possible without a
primary key on the table.



Ok. I have opened a new report on LO bugtracker.

Regards,

--
Stéphane Aulery

Bug#912900: perl: Storable stack recursion limit probe in 5.28 seems overly sensitive

2018-11-04 Thread Niko Tyni

Package: perl
Version: 5.28.0-3
Severity: important
Tags: upstream

  % perl -MStorable=nstore -e '$h->{$i}{a}{b}{c} = 0 while $i++<1; 
nstore($h, "testfile")'
  Max. recursion depth with nested structures exceeded at 
/usr/lib/x86_64-linux-gnu/perl/5.28/Storable.pm line 278, at -e line 1.

The documentation states

  Since Storable 3.05 we probe for the stack recursion limit for
  references, arrays and hashes to a maximal depth of ~1200-35000,
  otherwise we might fall into a stack-overflow.

but there's no recursion involved here, so it looks like the probe
heuristic is not quite working?

This broke apt-show-versions (#912695) and is sort of a regression,
not quite sure if we should consider it release critical or not.

Needs discussion upstream.
-- 
Niko Tyni   nt...@debian.org

Bug#912768: hplip-data: hp-toolbox fsck

2018-11-04 Thread Till Kamppeter

In general, it looks like that the HPLIP guys at HP are not testing well 
the GUI part. This caused the following bugs, all forwarded upstream but 
no fixes from upstream yet, only distro patches in the Ubuntu Cosmic 
package of HPLIP (3.18.7+dfsg1-2ubuntu2):


https://launchpad.net/bugs/1688684
  hp-check does not show distro names correctly but internal
  index numbers for them

https://launchpad.net/bugs/1745383
  QMessageBox() is called incorrectly

https://launchpad.net/bugs/1789184
  hp-toolbox does not start at all

The drivers themselves (CUPS filters/PPD files and SANE module) seem to 
work reasonably well, but for some small part of the device range a 
proprietary plugin is needed, and some of these devices probably also 
offer driverless IPP printing and this way one could work around the 
proprietary plugin at least if it concerns only printing.


For diagnostic purposes you can perhaps also use hp-check instead of 
hp-doctor as it has no GUI.


   Till

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread James Bottomley

On Sun, 2018-11-04 at 20:15 +0100, Kurt Roeckx wrote:
> This is not at all how the version negiotation in TLS 1.2 and
> below works. The client just indicates the highest version it
> supports, so for instance TLS 1.2. It's then up to the server to
> pick a version that the client supports, so one that is smaller than
> TLS 1.2, and it might pick TLS 1.0 or 1.2. It will then send a server
> hello with that version.

OK, so I'm weary of trying to construct a theory of what the bug
actually is, why don't you try to come up with one.  The symptoms are
that openvpn in openwrt works with server 1.1.0 and fails with server
1.1.1 if you don't specify tls-version-min 1.0 on the command line.

> So there are normally 2 cases that can be a problem:
> - The client sends TLS 1.0 and the server has 1.2 as minimum, so
>   the server say it's not supported.
> - The client sends TLS 1.2, the server answers with 1.0, the
>   client says 1.0 is too low.
> 
> The error message you showed says that it's the server that is
> rejecting the client's version, and that the server is running a
> 1.1.1 version. Are you sure you've actually restarted the server
> after changing the config file?

Yes, the server got rebooted after the upgrade.

James

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread Kurt Roeckx

On Sun, Nov 04, 2018 at 10:19:00AM -0800, James Bottomley wrote:
> On Sun, 2018-11-04 at 18:43 +0100, Kurt Roeckx wrote:
> > Older versions of openvpn only support TLS 1.0 because they told
> > OpenSSL to only use TLS 1.0. Adding the --tls-version-min 1.0
> > should make it support all TLS versions since openvpn 2.3.4 or
> > something like that, and I think 2.4 or newer should just work.
> 
> There's a difference: if you don't specify the command line tls-
> version-min, it actually asks openssl for the minimum version.  If you
> do specify, it takes what you tell it.

There is no API in OpenSSL to ask the minimum supported version.
What 2.3.4 does is that if you don't specify anything, it tells
OpenSSL to use TLS 1.0 only. What 2.4 does it just tell OpenSSL to
use any version it supports.

You can also specify that minimum version in the config file.

> > But if you changed the openssl.cfg to say all versions are
> > supported, it should work too, I'm not sure why you say otherwise.
> 
> Well, obviously because it doesn't work as the log attached in the bug
> report shows.
> 
> The values I have in openssl.cnf are the recommended
> 
> MinProtocol = None
> CipherString = DEFAULT
> 
> And it definitely works because imap has an android client at 0.9.8
> which didn't work before the addition of that.
> 
> The openssl code looks to use SSL_CTX_get_min_proto_version() if you
> don't specify a version, so it finds a protocol below tls 1.0 to
> present which causes the error.  From the ordering in openssl, this is
> likely to be SSLv3, isn't it?

With the above config SSL_CTX_get_min_proto_version() will return
0 indicating that all version supported at compile time are
supported. The minium at compile time is TLS 1.0.

> The bug here is that you shouldn't kill the negotiation just because
> the client offers to support SSLv3, you should move on to negotiate a
> more secure cipher and only error out if the client can't support any
> protocols openssl is told to consider secure.

This is not at all how the version negiotation in TLS 1.2 and
below works. The client just indicates the highest version it
supports, so for instance TLS 1.2. It's then up to the server to
pick a version that the client supports, so one that is smaller than
TLS 1.2, and it might pick TLS 1.0 or 1.2. It will then send a server
hello with that version.

So there are normally 2 cases that can be a problem:
- The client sends TLS 1.0 and the server has 1.2 as minimum, so
  the server say it's not supported.
- The client sends TLS 1.2, the server answers with 1.0, the
  client says 1.0 is too low.

The error message you showed says that it's the server that is
rejecting the client's version, and that the server is running a
1.1.1 version. Are you sure you've actually restarted the server
after changing the config file?

Kurt

Bug#900718: rsyslog: FTBFS on hurd-i386

2018-11-04 Thread Samuel Thibault

Hello,

Samuel Thibault, le mar. 12 juin 2018 00:35:15 +0200, a ecrit:
> Michael Biebl, le jeu. 07 juin 2018 13:40:45 +0200, a ecrit:
> > Am 07.06.2018 um 13:37 schrieb Samuel Thibault:
> > > Michael Biebl, le jeu. 07 juin 2018 13:34:48 +0200, a ecrit:
> > >> Anyway, such patches should best be sent upstream.
> > > 
> > > We don't have the manpower to chase all upstream bugtrackers and
> > > whatnot.
> > 
> > Same is true for me. I don't have the man power to keep maintaining
> > distro specific patches which belong upstream or playing bug proxy.
> 
> So, does anybody on debian-hurd have time for upstreaming?

So, can anybody on debian-hurd *please* take some time to have a look at
this?

The more people contribute to this kind of work, the less time I have
to spend on it, the more time I have to spend on more difficult issues
(llvm-toolchain, rustc, php7.3, etc.)

I have attached a refreshed patch.

Samuel
Index: rsyslog-8.34.0/runtime/modules.c
===
--- rsyslog-8.34.0.orig/runtime/modules.c
+++ rsyslog-8.34.0/runtime/modules.c
@@ -51,7 +51,7 @@
 #include 
 #include 
 
-#ifndef PATH_MAX
+#if !defined(PATH_MAX) && defined(MAXPATHLEN)
 #  define PATH_MAX MAXPATHLEN
 #endif
 
Index: rsyslog-8.34.0/plugins/imfile/imfile.c
===
--- rsyslog-8.34.0.orig/plugins/imfile/imfile.c
+++ rsyslog-8.34.0/plugins/imfile/imfile.c
@@ -66,6 +66,10 @@
 
 #include 
 
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
 MODULE_TYPE_INPUT
 MODULE_TYPE_NOKEEP
 MODULE_CNFNAME("imfile")

Bug#911120: espeakup: Does not fully install

2018-11-04 Thread Samuel Thibault

Samuel Thibault, le ven. 02 nov. 2018 00:52:55 +0100, a ecrit:
> Alex ARNAUD, le jeu. 01 nov. 2018 20:27:23 +0100, a ecrit:
> > >  espeakup
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> > Could it be possible to backport the fix to Stretch release?
> 
> Ah, right, the systemd service was already in Stretch, so we'd have to
> backport the fix, I have proposed this in #912629.

That got accepted, will be in 9.6 :)

Samuel

Bug#912899: python3-defaults FTCBFS: dependency python3.7 is not installable

2018-11-04 Thread Helmut Grohne

Source: python3-defaults
Version: 3.6.7-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

python3-defaults fails to cross build from source. The dependency on
python3.7 asks for a host architecture instance and that typically fails
its postinst. What you really need here is the build architecture
Python. Annotating the dependency with :any is enough to make
python3-defaults cross build successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru python3-defaults-3.6.7/debian/changelog 
python3-defaults-3.6.7/debian/changelog
--- python3-defaults-3.6.7/debian/changelog 2018-10-21 11:21:31.0 
+0200
+++ python3-defaults-3.6.7/debian/changelog 2018-11-04 20:00:08.0 
+0100
@@ -1,3 +1,10 @@
+python3-defaults (3.6.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python build dependencies with :any (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 04 Nov 2018 20:00:08 +0100
+
 python3-defaults (3.6.7-1) unstable; urgency=high
 
   * Really ship the policy in the python3 package, and update from the last
diff --minimal -Nru python3-defaults-3.6.7/debian/control 
python3-defaults-3.6.7/debian/control
--- python3-defaults-3.6.7/debian/control   2018-10-21 11:21:31.0 
+0200
+++ python3-defaults-3.6.7/debian/control   2018-11-04 19:59:29.0 
+0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Matthias Klose 
 Uploaders: Piotr Ożarowski 
-Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.17.11), python3.7 (>= 
3.6.7-1~),
+Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.17.11), python3.7:any (>= 
3.6.7-1~),
   lsb-release,
   python3-minimal:any,
   python3-docutils,
diff --minimal -Nru python3-defaults-3.6.7/debian/rules 
python3-defaults-3.6.7/debian/rules
--- python3-defaults-3.6.7/debian/rules 2018-10-21 11:21:31.0 +0200
+++ python3-defaults-3.6.7/debian/rules 2018-11-04 20:00:01.0 +0100
@@ -28,7 +28,7 @@
 STDLIBVER   := 3.6.7-1~
 
 ifeq (,$(filter $(distrelease),lenny etch squeeze wheezy lucid maverick natty 
oneiric precise quantal raring saucy trusty))
-  bd_i586 = dpkg-dev (>= 1.17.11), python3.7 (>= 3.6.7-1~),
+  bd_i586 = dpkg-dev (>= 1.17.11), python3.7:any (>= 3.6.7-1~),
 else
   bd_i586 = dpkg-dev (>= 1.16.1~),
 endif

Bug#912768: hplip-data: hp-toolbox fsck

2018-11-04 Thread Till Kamppeter

Brian, if the user only wants to print with his printer (is it a 
print-only device or a multi-function device with scanner) driverless 
IPP printing works indeed, especially with HP devices. Then this is the 
recommended solution.


Only for scanning one still needs drivers and in case of HP's 
multi-function devices HPLIP (a driverless IPP scanning standard is 
already there, but not yet adopted in actual hardware).


   Till

Bug#912627: asymptote: Asymptote crashes on attempt to create pdf file

2018-11-04 Thread Hilmar Preuße


Am 03.11.2018 um 06:54 teilte Norbert Preining mit:

On Fri, 02 Nov 2018, Hilmar Preuße wrote:


Hi,


Also this function is still mentioned on [2]. The issue in asy is still
in 2.47 (probably) and needs to be forwarded.


I tried to update asymptote, but xasy is rewritten in the new upstream
version and somehow does not work at all, uses strange python modules
that aren't packaged, etc etc. I fear I need to drop xasy.

Not sure what modules you're speaking about. After installing 
python3-pyqt5 & python3-pyqt5.qtsvg at least the ModuleNotFoundError is 
gone. Now I get:


hille@sid:~ $ xasy -h
Traceback (most recent call last):
  File "/usr/bin/xasy", line 5, in 
from Window1 import MainWindow1
  File "/usr/share/asymptote/GUI/Window1.py", line 23, in 
import xasy2asy as x2a
  File "/usr/share/asymptote/GUI/xasy2asy.py", line 36, in 
import xasyOptions as xo
  File "/usr/share/asymptote/GUI/xasyOptions.py", line 153, in 
class BasicConfigs:
  File "/usr/share/asymptote/GUI/xasyOptions.py", line 156, in BasicConfigs
'xasyconfig', os.path.join(_configPath, 'xasyconfig.cson'))
  File "/usr/share/asymptote/GUI/xasyOptions.py", line 80, in __init__
self.options = self.defaultOptions()
  File "/usr/share/asymptote/GUI/xasyOptions.py", line 38, in 
defaultOptions

opt = cson.loads(f.read())
AttributeError: 'NoneType' object has no attribute 'loads'

..which looks like a bug in xasy to me.

Regarding the original problem: as expected it is not solved in 4.77.

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

Bug#902557: marked as done (transition: Perl 5.28)

2018-11-04 Thread Niko Tyni

On Sun, Nov 04, 2018 at 06:23:09PM +0100, Mattia Rizzolo wrote:
> > And now in testing already, so closing this. Thanks again!
> 
> Note that in general a transition is considered "done" once the old
> package have been removed from testing.
> 
> This is not the case here, since both libperl5.26 and perl-modules-5.26
> are still in testing.
> However, I'll leave it to pochu to reopen the bug he feels strongly
> about this.

Fine by me of course. Thanks for educating me.
-- 
Niko

Bug#912898: gpgme1.0 FTCBFS: python issues

2018-11-04 Thread Helmut Grohne

Source: gpgme1.0
Version: 1.12.0-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gpgme1.0 fails to cross build from source. All of the reasons relate to
Python. The rest of gpgme1.0 cross builds just fine with no changes
needed.

The first problem are the Build-Depends. Rather than "pythonX.Y-dev",
one needs to depend on "libpythonX.Y-dev, pythonX.Y-dev:any". Then, the
relevant setup.py is invoked by the respective subdirectory Makefile
rather than say pybuild. The ways to tell setup.py (as implemented by
pybuild) can be described as arcane at best. The respective environment
variables and their values are anything but obvious.

In any case, the attached patch makes gpgme1.0 cross buildable. Please
consider applying it. If you have any idea on how to improve the
interface to Python here, please tell.

Helmut
diff --minimal -Nru gpgme1.0-1.12.0/debian/changelog 
gpgme1.0-1.12.0/debian/changelog
--- gpgme1.0-1.12.0/debian/changelog2018-10-18 17:54:17.0 +0200
+++ gpgme1.0-1.12.0/debian/changelog2018-11-04 17:34:40.0 +0100
@@ -1,3 +1,12 @@
+gpgme1.0 (1.12.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Update Python Build-Depends for cross compilation.
++ Export Python's fancy cross compilation variables.
+
+ -- Helmut Grohne   Sun, 04 Nov 2018 17:34:40 +0100
+
 gpgme1.0 (1.12.0-4) unstable; urgency=medium
 
   * no need to clean up build-py3.7 any longer
diff --minimal -Nru gpgme1.0-1.12.0/debian/control 
gpgme1.0-1.12.0/debian/control
--- gpgme1.0-1.12.0/debian/control  2018-10-18 06:39:56.0 +0200
+++ gpgme1.0-1.12.0/debian/control  2018-11-04 17:34:38.0 +0100
@@ -14,9 +14,11 @@
  gpgsm,
  libassuan-dev (>= 2.4.2),
  libgpg-error-dev (>= 1.24),
+ libpython-all-dev,
+ libpython3-all-dev,
  pkg-config,
- python-all-dev,
- python3-all-dev,
+ python-all-dev:any,
+ python3-all-dev:any,
  qtbase5-dev,
  scdaemon,
  swig,
diff --minimal -Nru gpgme1.0-1.12.0/debian/rules gpgme1.0-1.12.0/debian/rules
--- gpgme1.0-1.12.0/debian/rules2018-10-18 06:44:02.0 +0200
+++ gpgme1.0-1.12.0/debian/rules2018-11-04 17:34:40.0 +0100
@@ -3,6 +3,14 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export QT_SELECT := qt5
 
+include /usr/share/dpkg/architecture.mk
+
+# python2.7
+export PYTHONPATH:=/usr/lib/python2.7/plat-$(DEB_HOST_MULTIARCH)$(if 
$(PYTHONPATH),:$(PYTHONPATH))
+# python3.X, see pybuild for their meaning.
+export _PYTHON_HOST_PLATFORM:=${DEB_HOST_ARCH_OS}-${DEB_HOST_ARCH}
+export 
_PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata_m_${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}
+
 %:
dh $@ --builddirectory=build --with python2,python3

Bug#912897: ITP: ruby-chromedriver-helper -- Easy installation and use of chromedriver

2018-11-04 Thread Mangesh Divate

package: wnpp
Severity: wishlist
Owner: Mangesh Divate 
X-Debbugs-CC: debian-de...@lists.debian.org

*Package Name : ruby-chromedriver-helper
 Version : 2.1.0
 Upstream Author : Mike Dalessio
*URL :  *https://github.com/flavorjones/chromedriver-helper
*
*License : Expat
*Description :  Easy installation and use of chromedriver, the Chromium
project's seleniumweb driver adapter.

I am packaging this as a dependency of rails5

Bug#912629: espeakup 0.80-5+deb9u2 flagged for acceptance

2018-11-04 Thread Adam D Barratt

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: espeakup
Version: 0.80-5+deb9u2

Explanation: espeakup.service: Automatically load speakup_soft on daemon startup

Bug#912896: please cleanup

2018-11-04 Thread Harald Dunkel

Package: os-prober
Version: 1.76

os-prober writes a lot of hard-to-get-rid-of debug messages into
/var/log/messages. 2 problems:

- The syslog lines lack a common pattern, e.g. "os-prober". Instead
  they log entries for 40grub2, 83haiku, 10qnx, macosx-prober,
  20microsoft, etc. This is extremely difficult to filter and doesn't
  support a dedicated log file. I am forced to disable logging DEBUG
  entries completely.

- The environment variable to disable this (OS_PROBER_DISABLE_DEBUG)
  is neither documented (AFAICS), nor does os-prober support a config
  file to set it.

This should be improved.


Regards
Harri

Bug#912860: Don't ship libgtk2-perl in Bullseye

2018-11-04 Thread intrigeri

I've filed bug reports against all reverse dependencies (normal
severity for now), tracked using the gtk2-removal usertag:

https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=gtk2-removal=debian-perl%40lists.debian.org

All reverse dependencies are leaf packages. The vast majority are
either dead upstream, or orphaned in Debian, or de facto unmaintained…
or, pretty often, some combination thereof.

Bug#912895: macchanger-gtk: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: macchanger-gtk
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

This being said, I notice that #904559 and #887879 were not acted
upon, this package probably won't be in Buster, and the upstream URL
found in the Homepage control field gives a 404 error. So it looks
like this (short and simple) script needs a new active upstream.
If this does not happen, then I think we should remove this package
from the archive.

Cheers!
-- 
intrigeri

Bug#912768: hplip-data: hp-toolbox fsck

2018-11-04 Thread Brian Potkin

On Sun 04 Nov 2018 at 15:45:41 +0100, Cristian Ionescu-Idbohrn wrote:

> On Sun, 4 Nov 2018, Cristian Ionescu-Idbohrn wrote:
> > On Sat, 3 Nov 2018, Brian Potkin wrote:
> > > On Sat 03 Nov 2018 at 19:20:42 +0100, Cristian Ionescu-Idbohrn wrote:
> > > 
> > > > Package: hplip-data
> > > > Version: 3.18.10+dfsg0-1
> > > > Severity: grave
> > > > Justification: renders package unusable
> > > 
> > > 
> > > If you would explain why this is grave, we could adjust the severity.
> > 
> > I can no longer use primarily the scanner.
> > I think it got broken in 3.17.10 already.
> 
> So, what did I do?  Downgraded to 3.17.10+repack0-5.  Downgraded cups 
> too, to 2.2.8-5 (although I don't know if I had to; please advice, if 
> you can).  Got a laptop running testing where hplip/cups works as 
> expected, almost.  And the hack to make it work is here:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889468
> 
> This is just _one_ of the examples of how it it might look like:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1544912
> 
> And I experience similar problems.  So, this a list of what I 
> downgraded:
> 
> cups-bsd_2.2.8-5_amd64.deb
> cups-client_2.2.8-5_amd64.deb
> cups-common_2.2.8-5_all.deb
> cups-core-drivers_2.2.8-5_amd64.deb
> cups-daemon_2.2.8-5_amd64.deb
> cups-filters-core-drivers_1.21.3-2_amd64.deb
> cups-filters_1.21.3-2_amd64.deb
> cups-ipp-utils_2.2.8-5_amd64.deb
> cups-pk-helper_0.2.6-1+b1_amd64.deb
> cups-ppdc_2.2.8-5_amd64.deb
> cups-server-common_2.2.8-5_all.deb
> cups_2.2.8-5_amd64.deb
> hplip-data_3.17.10+repack0-5_all.deb
> hplip-gui_3.17.10+repack0-5_all.deb
> hplip_3.17.10+repack0-5_amd64.deb
> libcups2_2.2.8-5_amd64.deb
> libcupscgi1_2.2.8-5_amd64.deb
> libcupsfilters1_1.21.3-2_amd64.deb
> libcupsimage2_2.2.8-5_amd64.deb
> libcupsmime1_2.2.8-5_amd64.deb
> libcupsppdc1_2.2.8-5_amd64.deb
> libhpmud0_3.17.10+repack0-5_amd64.deb
> libsane-hpaio_3.17.10+repack0-5_amd64.deb
> printer-driver-hpcups_3.17.10+repack0-5_amd64.deb
> python3-cups_1.9.73-2+b1_amd64.deb
> python3-cupshelpers_1.5.11-3_all.deb
> 
> That's put on hold for now.
> 
> I got back printing and scanning functionality, but not all :(
> 
> The main problem with the hplip 3.18.10 is that hp-setup associates 
> the wrong:
> 
>   Found PPD file: hplip:0/ppd/hplip/HP/hp-laserjet_mfp_m28-m31.ppd
> 
> (which is not a _color_ printer, does not do _duplex_ and has only 
> _one_ tray, among other things)
> 
> with the printer:
> 
>   HP Color LaserJet MFP M281fdw
> 
> It should be:
> 
>   Found PPD file: 
> hplip:0/ppd/hplip/HP/hp-color_laserjet_pro_mfp_m277-ps.ppd  
> 
> instead.  This post:
> 
>   
> https://forums.fedoraforum.org/showthread.php?317915-Print-amp-scan-with-an-HP-Color-LaserJet-MFP-M281-(fdw)=1806395
> 
> could be another way to do it, but I don't know if that works with 
> hplip 3.18.10.
> 
> I wish hp-toolbox displayed like in attachment 1, not like in 
> attachment 2, but I'll live with it ;)
> 
> Any advise on ways to cleanup this mess is highly appreciated.

Can we just forget about the bug you reported for a while and, to begin
with, get you printing satisfactorily?

Why tie yourself into the tyranny of vendor supplied drivers? Get your
cups back to 2.2.8-5 and purge hplip and everything it pulled in. Have
the printer on the network and doing DNS-SD (Bonjour) broadcasting.
Purge cups-browsed. Now do

  lpstat -e

What do you get?

Cheers,

Brian

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

2018-11-04 Thread Chris Lamb

Tony,

> transition maintainership, we can file an RFA bug, which is all of the
> formality that is needed.

hm? No formalities are required. Indeed, an RFA bug would actually
be misleading here as it implies a request for anyone to adopt it
(vs.  me adopting it).
 
> Also, since I have porterbox access, let me know what would be helpful.

I wouldn't spend too long; this architecture is notorious. Just
make it non-fatal on that arch and move on. :)


Regards,

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

Bug#912894: odot: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: odot
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

This being said, the package was orphaned last year and the current
"votes" count on popcon is 2. So I think should remove it from the
archive if/once it's clear that it won't be ported to GTK+ 3.

Cheers!
-- 
intrigeri

Bug#912893: odot: Upstream homepage URL redirects to an unrelated news site

2018-11-04 Thread intrigeri

Source: odot
Severity: normal

The URL found in the Upstream control field
(http://home.arcor.de/kaffeetisch/odot.html) now redirects to
https://www.arcor.de/, which as far as I can tell is a generic news
site and not the homepage of odot.

Bug#912891: pcsc-tools: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: pcsc-tools
Severity: normal
X-Debbugs-Cc: lionel.vic...@unforgettable.com
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Boilerplate put aside, apparently the only GTK+ 2 program shipped in
this package is the gscriptor GUI. I'm therefore directly Cc'ing
Lionel Victor, who's the upstream author according to the homepage :)

Cheers!
-- 
intrigeri

Bug#912892: pybuild confuses host and target

2018-11-04 Thread Helmut Grohne

Package: dh-python
Version: 3.20180927
File: /usr/bin/pybuild

/usr/bin/pybuild has:

| try:
| # Set _PYTHON_HOST_PLATFORM to ensure debugging symbols on, f.e. i386
| # emded a constant name regardless of the 32/64-bit kernel.
| env.setdefault(
| '_PYTHON_HOST_PLATFORM',
| 
'{env[DEB_TARGET_ARCH_OS]}-{env[DEB_TARGET_ARCH]}'.format(env=env))
| except KeyError:
| pass

That's wrong. You're confusing host and target here. Please use
DEB_HOST_* instead of DEB_TARGET_*. Refer to man 1 dpkg-architecture for
their definitions.

Helmut

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread James Bottomley

On Sun, 2018-11-04 at 18:43 +0100, Kurt Roeckx wrote:
> Older versions of openvpn only support TLS 1.0 because they told
> OpenSSL to only use TLS 1.0. Adding the --tls-version-min 1.0
> should make it support all TLS versions since openvpn 2.3.4 or
> something like that, and I think 2.4 or newer should just work.

There's a difference: if you don't specify the command line tls-
version-min, it actually asks openssl for the minimum version.  If you
do specify, it takes what you tell it.

> But if you changed the openssl.cfg to say all versions are
> supported, it should work too, I'm not sure why you say otherwise.

Well, obviously because it doesn't work as the log attached in the bug
report shows.

The values I have in openssl.cnf are the recommended

MinProtocol = None
CipherString = DEFAULT

And it definitely works because imap has an android client at 0.9.8
which didn't work before the addition of that.

The openssl code looks to use SSL_CTX_get_min_proto_version() if you
don't specify a version, so it finds a protocol below tls 1.0 to
present which causes the error.  From the ordering in openssl, this is
likely to be SSLv3, isn't it?

The bug here is that you shouldn't kill the negotiation just because
the client offers to support SSLv3, you should move on to negotiate a
more secure cipher and only error out if the client can't support any
protocols openssl is told to consider secure.

James

Bug#912890: pidgin-openpgp: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: pidgin-openpgp
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Additionally, I notice that:

 - This package was orphaned back in 2012.

 - Upstream seems to be… a code dump in a Pidgin upstream ticket
   comment: https://developer.pidgin.im/ticket/288
   So perhaps my suggestion to contact upstream is kind of moot :/

 - There are other options for this use case nowadays, such as OTR,
   which are probably better for most use cases.

So perhaps it would be best to remove this package from Debian.

Cheers!
-- 
intrigeri

Bug#912889: tinyca: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: tinyca
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#912888: clamtk: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: clamtk
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#912887: neutron-fwaas: [INTL:pt] Portuguese translation for debconf messages

2018-11-04 Thread Traduz - DebianPT



Package: neutron-fwaas
Version: 1:13.0.0-4
Tags: l10n, patch
Severity: wishlist

Resent with correct subject

Updated Portuguese translation for neutron-fwaas's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
# Copyright (C) 2018 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the neutron-fwaas package.
#
# Rui Branco - DebianPT , 2018.
#
msgid ""
msgstr ""
"Project-Id-Version: neutron-fwaas 1:13.0.0-4\n"
"Report-Msgid-Bugs-To: neutron-fw...@packages.debian.org\n"
"POT-Creation-Date: 2018-10-25 13:59+\n"
"PO-Revision-Date: 2018-11-02 19:26+\n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Rui Branco \n"
"Language-Team: \n"

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid "Run default configuration for neutron-fwaas ?"
msgstr "Correr a configuraÃ§Ã£o predefinida para o neutron-fwaas ?"

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid ""
"Neutron-fwaas will be configured to use ovs and firewall_v2. If you want to "
"run now, please make sure you have configured database.connection in neutron."
"conf:"
msgstr ""
"O neutron-fwaas serÃ¡ configurado de modo a usar ovs e firewall_v2. Se quiser "
"corrÃª-lo agora certifique-se que configurou database.connection no "
"neutron.conf:"

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid ""
"If you don't choose this option, no database migration will be run and no "
"plugin will be enabled, these things you have to do manually."
msgstr ""
"Se nÃ£o escolher esta opÃ§Ã£o, nÃ£o serÃ¡ executada nenhuma migraÃ§Ã£o de base de 
dados e nÃ£o serÃ¡ activado nenhum plugin, assim terÃ¡ que as executar manualmente."

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"neutron-fwaas-common\"."
msgstr ""
"Pode alterar esta opÃ§Ã£o mais tarde correndo \"dpkg-reconfigure -plow neutron-"
"fwaas-common\"."

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

2018-11-04 Thread Stefan Fritsch

On Sunday, 4 November 2018 18:36:19 CET Thorsten Glaser wrote:
> This is a real WTF. I found https://serverfault.com/a/892300/189656
> and thought “hey, Apache 2 still documents SSLCertificateChainFile,
> plus it’s the proper way to specify the chain given it’s normally
> separate from the certificates, and there’s no warning message about
> that directive, but let’s give it a shot”.

SSLCertificateChainFile still does something, it's not a no-op in the source. 
Maybe you are hitting https://bz.apache.org/bugzilla/show_bug.cgi?id=62880 . 
That would  cause non-deterministic behavior (depending on what went on before 
the SSLCertificateChainFile is encountered).  If you have time, you could try 
the patch attached to that bug. Right now, I don't have time to prepare test 
packages.

Cheers,
Stefan

Bug#912886: shim-signed: [INTL:pt] Updated Portuguese translation for debconf

2018-11-04 Thread Traduz PT

Package: shim-signed
Version: 1.28+nmu1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for shim-signed's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
# Copyright (C) 2017 THE shim-signed'S COPYRIGHT HOLDER
# This file is distributed under the same license as the shim-signed package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: shim-signed 1.28\n"
"Report-Msgid-Bugs-To: shim-sig...@packages.debian.org\n"
"POT-Creation-Date: 2018-11-04 08:13+0100\n"
"PO-Revision-Date: 2018-11-04 18:07+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2\n"

#. Type: text
#. Description
#: ../templates:1001
msgid "Configuring UEFI Secure Boot"
msgstr "A configurar o Secure Boot UEFI"

#. Type: error
#. Description
#: ../templates:2001
msgid "Invalid password"
msgstr "Palavra-chave invÃ¡lida"

#. Type: error
#. Description
#: ../templates:2001
msgid ""
"The Secure Boot key you've entered is not valid. The password used must be "
"between 8 and 16 characters."
msgstr ""
"A chave do Secure Boot que introduziu nÃ£o Ã© vÃ¡lida. A palavra-chave deve "
"conter entre 8 a 16 caracteres."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Disable UEFI Secure Boot?"
msgstr "Desactivar o Secure Boot?"

#. Type: boolean
#. Description
#. Type: note
#. Description
#: ../templates:3001 ../templates:5001
msgid ""
"If Secure Boot remains enabled on your system, your system may still boot "
"but any hardware that requires third-party drivers to work correctly may not "
"be usable."
msgstr ""
"Se o Secure Boot persistir no seu sistema, poderÃ¡ arrancar na mesma mas "
"qualquer hardware que necessite de drivers de terceiros poderÃ¡ nÃ£o funcionar."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Enable UEFI Secure Boot?"
msgstr "Activar o Secure Boot UEFI?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"If Secure Boot is enabled on your system, your system may still boot but any "
"hardware that requires third-party drivers to work correctly may not be "
"usable."
msgstr ""
"Se o Secure Boot estiver activo no seu sistema, poderÃ¡ arrancar na mesma mas "
"qualquer hardware que necessite de drivers de terceiros poderÃ¡ nÃ£o funcionar."

#. Type: note
#. Description
#: ../templates:5001
msgid "Your system has UEFI Secure Boot enabled"
msgstr "O seu sistema possui o Secure Boot activo."

#. Type: note
#. Description
#: ../templates:5001
msgid "UEFI Secure Boot is not compatible with the use of third-party drivers."
msgstr "O Secure Boot UEFI nÃ£o Ã© compatÃvel com o uso drivers de terceiros."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"The system will assist you in toggling UEFI Secure Boot. To ensure that this "
"change is being made by you as an authorized user, and not by an attacker, "
"you must choose a password now and then use the same password after reboot "
"to confirm the change."
msgstr ""
"O sistema irÃ¡ auxiliÃ¡-lo a comutar para o Secure Boot UEFI. Para garantir "
"que esta modificaÃ§Ã£o Ã© efectuada por um utilizador autorizado e nÃ£o por um "
"atacante, deverÃ¡ escolher uma palavra-chave neste momento e entÃ£o usar a "
"palavra-chave a seguir ao arranque para confirmar a alteraÃ§Ã£o."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"If you choose to proceed but do not confirm the password upon reboot, the "
"Secure Boot configuration will not be changed, and the machine will continue "
"booting as before."
msgstr ""
"Se escolher continuar sem definir a palavra-chave apÃ³s o arranque, a "
"configuraÃ§Ã£o do Secure Boot nÃ£o serÃ¡ alterada e o sistema serÃ¡ capaz de "
"arrancar como antes."

#. Type: password
#. Description
#: ../templates:6001
msgid "UEFI Secure Boot password:"
msgstr "Palavra-chave do Secure Boot UEFI?"

#. Type: password
#. Description
#: ../templates:6001
msgid "Please enter a password for configuring UEFI Secure Boot."
msgstr ""
"Por favor introduza uma palavra-chave para configurar o Secure Boot UEFI."

#. Type: password
#. Description
#: ../templates:6001
msgid ""
"This password will be used after a reboot to confirm authorization for a "
"change to Secure Boot state."
msgstr ""
"Esta palavra-chave serÃ¡ utilizada apÃ³s reiniciar de modo a confirmar a "
"alteraÃ§Ã£o do estado do Secure Boot."

#. Type: password
#. Description
#: ../templates:7001
msgid "Re-enter password to verify:"
msgstr "Volte a introduzir a palavra-chave para confirmar:"

#. Type: password
#. Description
#: ../templates:7001
msgid ""
"Please enter the same password again to verify that you have typed it "
"correctly."
msgstr ""
"Introduza a palavra-chave de

Bug#912884: daemontools-run: move /etc/service to /service please, etckeeper explodes

2018-11-04 Thread Thorsten Glaser

Package: daemontools-run
Version: 1:0.76-7
Severity: important

I was wondering why my /etc is 11 GiB in size.

Turns out /etc/.git (from etckeeper) is 10 GiB,
because it covers /service/*/log/main/* from dæmontools.

This is… unfortunate.

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

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

Versions of packages daemontools-run depends on:
ii  daemontools  1:0.76-7

daemontools-run recommends no packages.

daemontools-run suggests no packages.

-- no debconf information

Bug#912883: libxapian30: freelist block leaks which are reported as corruption

2018-11-04 Thread Olly Betts

Package: libxapian30
Version: 1.4.3-2+deb9u1
Severity: important
Tags: patch upstream

If changes to a new database which don't modify the termlist table
are committed, then a block which has been allocated to be the root
block in the termlist table gets leaked.  This case is triggered by
notmuch - the result is a database which is slightly larger than
it would otherwise be, but works fine *except* that consistency
checking with xapian-check/Database::check() detects there's an
unused block not on the freelist and reports this as
"DatabaseCorruptError" - this tends to alarm users.

While tracking down the above problem, I found a second case where
blocks can be leaked when cancel_transaction() is called.

Both of these were fixed in upstream xapian-core 1.4.7 - the combined
patch is attached.

Cheers,
Olly
diff --git a/xapian-core/backends/glass/glass_table.cc b/xapian-core/backends/glass/glass_table.cc
index 7342f7496c48..1669431b6c6c 100644
--- a/xapian-core/backends/glass/glass_table.cc
+++ b/xapian-core/backends/glass/glass_table.cc
@@ -1639,6 +1639,7 @@ GlassTable::read_root()
 	/* writing - */
 	SET_REVISION(p, revision_number + 1);
 	C[0].set_n(free_list.get_block(this, block_size));
+	C[0].rewrite = true;
 	}
 } else {
 	/* using a root block stored on disk */
@@ -1853,9 +1854,7 @@ GlassTable::flush_db()
 	}
 }
 
-if (Btree_modified) {
-	faked_root_block = false;
-}
+faked_root_block = false;
 }
 
 void
@@ -1944,6 +1943,13 @@ GlassTable::cancel(const RootInfo & root_info, glass_revision_number_t rev)
 item_count =   root_info.get_num_entries();
 faked_root_block = root_info.get_root_is_fake();
 sequential =   root_info.get_sequential();
+const string & fl_serialised = root_info.get_free_list();
+if (!fl_serialised.empty()) {
+	if (!free_list.unpack(fl_serialised))
+	throw Xapian::DatabaseCorruptError("Bad freelist metadata");
+} else {
+	free_list.reset();
+}
 
 Btree_modified = false;
 
diff --git a/xapian-core/tests/api_backend.cc b/xapian-core/tests/api_backend.cc
index a520be112286..a6d97742865f 100644
--- a/xapian-core/tests/api_backend.cc
+++ b/xapian-core/tests/api_backend.cc
@@ -1666,3 +1666,23 @@ DEFINE_TESTCASE(checkatleast4, backend) {
 TEST_EQUAL(mset.size(), 0);
 return true;
 }
+
+/// Regression test for glass bug fixed in 1.4.6 and 1.5.0.
+DEFINE_TESTCASE(nodocs1, transactions && !remote) {
+{
+	Xapian::WritableDatabase db = get_named_writable_database("nodocs1");
+	db.set_metadata("foo", "bar");
+	db.commit();
+	Xapian::Document doc;
+	doc.add_term("baz");
+	db.add_document(doc);
+	db.commit();
+}
+
+size_t check_errors =
+	Xapian::Database::check(get_named_writable_database_path("nodocs1"),
+Xapian::DBCHECK_SHOW_STATS, );
+TEST_EQUAL(check_errors, 0);
+
+return true;
+}
diff --git a/xapian-core/tests/api_transdb.cc b/xapian-core/tests/api_transdb.cc
index eda0a6ef5936..32eede143f5a 100644
--- a/xapian-core/tests/api_transdb.cc
+++ b/xapian-core/tests/api_transdb.cc
@@ -1,7 +1,7 @@
 /** @file api_transdb.cc
  * @brief tests requiring a database backend supporting transactions
  */
-/* Copyright (C) 2006,2009 Olly Betts
+/* Copyright (C) 2006,2009,2018 Olly Betts
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -126,3 +126,24 @@ DEFINE_TESTCASE(canceltransaction2, transactions) {
 
 return true;
 }
+
+/// Regression test for glass bug fixed in 1.4.6 and 1.5.0.
+DEFINE_TESTCASE(canceltransaction3, transactions && !remote) {
+{
+	Xapian::WritableDatabase db = get_named_writable_database("canceltransaction3");
+	db.begin_transaction();
+	Xapian::Document doc;
+	doc.add_term("baz");
+	db.add_document(doc);
+	db.cancel_transaction();
+	db.add_document(doc);
+	db.commit();
+}
+
+size_t check_errors =
+	Xapian::Database::check(get_named_writable_database_path("canceltransaction3"),
+Xapian::DBCHECK_SHOW_STATS, );
+TEST_EQUAL(check_errors, 0);
+
+return true;
+}


signature.asc
Description: PGP signature

Bug#912885: gcstar: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: gcstar
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

FWIW I've tried to check whether upstream was already on it, but the
link to their issue tracker [1] is broken: it points to a service that
was closed 1.5 years ago.

[1] http://www.gcstar.org/contribute.en.php#tasks

Cheers!
-- 
intrigeri

Bug#912882: gmusicbrowser: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: gmusicbrowser
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

FTR this port has been requested upstream back in 2013:

   https://github.com/squentin/gmusicbrowser/issues/57

Cheers!
-- 
intrigeri

Bug#912881: : [INTL:pt] Portuguese translation for neutron-fwaas debconf messages

2018-11-04 Thread Traduz PT

Package: neutron-fwaas
Version: 1:13.0.0-4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for neutron-fwaas's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
# Copyright (C) 2018 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the neutron-fwaas package.
#
# Rui Branco - DebianPT , 2018.
#
msgid ""
msgstr ""
"Project-Id-Version: neutron-fwaas 1:13.0.0-4\n"
"Report-Msgid-Bugs-To: neutron-fw...@packages.debian.org\n"
"POT-Creation-Date: 2018-10-25 13:59+\n"
"PO-Revision-Date: 2018-11-02 19:26+\n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Rui Branco \n"
"Language-Team: \n"

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid "Run default configuration for neutron-fwaas ?"
msgstr "Correr a configuraÃ§Ã£o predefinida para o neutron-fwaas ?"

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid ""
"Neutron-fwaas will be configured to use ovs and firewall_v2. If you want to "
"run now, please make sure you have configured database.connection in neutron."
"conf:"
msgstr ""
"O neutron-fwaas serÃ¡ configurado de modo a usar ovs e firewall_v2. Se quiser "
"corrÃª-lo agora certifique-se que configurou database.connection no "
"neutron.conf:"

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid ""
"If you don't choose this option, no database migration will be run and no "
"plugin will be enabled, these things you have to do manually."
msgstr ""
"Se nÃ£o escolher esta opÃ§Ã£o, nÃ£o serÃ¡ executada nenhuma migraÃ§Ã£o de base de 
dados e nÃ£o serÃ¡ activado nenhum plugin, assim terÃ¡ que as executar manualmente."

#. Type: boolean
#. Description
#: ../neutron-fwaas-common.templates:1001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"neutron-fwaas-common\"."
msgstr ""
"Pode alterar esta opÃ§Ã£o mais tarde correndo \"dpkg-reconfigure -plow neutron-"
"fwaas-common\"."

Bug#912880: gprename: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: gprename
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#912879: email-reminder: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: email-reminder
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi François!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

I notice you're also upstream for this project, so please consider
porting the GUI to libgtk3-perl. I've personally ported a couple Perl
GTK+ apps from 2.x to 3.x and it's rather straightforward.
Upstream for the GTK+ 3 and GObject Introspection Perl bindings is
responsive and happy to add missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

2018-11-04 Thread tony mancill

On Sun, Nov 04, 2018 at 06:42:14AM -0500, Chris Lamb  wrote:
> Hi Tom,
> 
> > > Tempting to disable the tests on this architecture (or, rather, making
> > > them non-fatal).
> >
> > I'd prefer the latter, but might be better to simply disable 'em on
> > mips64el since they sit there doing nothing for ~2.5 hours apparently
> 
> Ah, but only sometimes according to earlier in this bug so I would
> make them run but non-fatal.
> 
> > I'm not sure what kind of formalities are involved (if any) in
> > this sort of "direct" adoption
> 
> No formalities; I just upload. Let me know concretely and
> definitively whether you want me to do this & fix this bug at the
> same time. (It's a little unclear at the moment given you are asking
> Tony to do some work in your previous message.)

I'm in the same situation as Chris - I just try to upload when things
are ready...  Tom, I can take care of the upload of 0.14.0-3 as soon as
it's ready and then the backport upload.  If you do decide you'd like to
transition maintainership, we can file an RFA bug, which is all of the
formality that is needed.

Also, since I have porterbox access, let me know what would be helpful.
We could sit down together and see what's actually happening during
those 150 minutes.

Cheers,
tony

signature.asc
Description: PGP signature

Bug#912878: gresolver: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: gresolver
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Otherwise, #885741 and #912382 suggest that this package should
probably be removed from the archive.

Cheers!
-- 
intrigeri

Bug#912877: gui-apt-key: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: gui-apt-key
Severity: normal
X-Debbugs-Cc: Axel Beckert 
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

This being said, I notice that this package is RC-buggy, not in
testing currently, and the last maintainer upload was 10 years ago.
So Cc'ing Axel, who did the last upload, in case he's interested to
take the lead here :) Otherwise, I think the best course of action
will be to remove this package from the archive.

Cheers!
-- 
intrigeri

Bug#900718: rsyslog: FTBFS on hurd-i386

2018-11-04 Thread Samuel Thibault

Hello,

Additionally, the attached patch is needed since lsof is non available
on non-linux.

Samuel
--- debian/control.original 2018-11-04 17:45:38.0 +
+++ debian/control  2018-11-04 17:46:03.0 +
@@ -28,7 +28,7 @@
python ,
libfaketime ,
systemd [linux-any] ,
-   lsof ,
+   lsof [linux-any] ,
 Standards-Version: 4.2.1
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/debian/rsyslog.git

Bug#912876: gtkorphan: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: gtkorphan
Severity: normal
X-Debbugs-Cc: Fabio Marzocca 
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Usually I would write here: "Please get in touch with the upstream
project and suggest they port this application to libgtk3-perl.
I've personally ported a couple Perl GTK+ apps from 2.x to 3.x and
it's rather straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add missing
bits to the bindings".

But I notice that:

 - The previous maintainer (Cc'ed) before this package was orphaned
   is also the upstream author.

 - This package won't be in Buster due to #904562, which I filed back
   in July.

So I guess that what this app needs is a new upstream maintainer.
If that does not happen, I think we should remove this package
from the archive.   

Cheers!
-- 
intrigeri

Bug#900716: librdkafka: FTBFS on hurd-i386

2018-11-04 Thread Samuel Thibault

Hello,

Samuel Thibault, le lun. 04 juin 2018 00:19:45 +0200, a ecrit:
> librdkafka is currently FTBFS on hurd-i386, thus preventing rsyslog from
> building, and thus from the standard task to be installable at all.
> 
> The attached patch fixes the couple of odd assumptions that make the
> build fail, could you apply them soon so we can have an installable
> hurd-i386 system again?

"soon" can't really wait for months :)

I have uploaded the attached changes to DELAYED/0.

Samuel
diff -Nru librdkafka-0.11.6/debian/changelog librdkafka-0.11.6/debian/changelog
--- librdkafka-0.11.6/debian/changelog  2018-10-24 11:01:10.0 +0200
+++ librdkafka-0.11.6/debian/changelog  2018-11-04 18:41:48.0 +0100
@@ -1,3 +1,10 @@
+librdkafka (0.11.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch to fix hurd-i386 build (Closes: #900716).
+
+ -- Samuel Thibault   Sun, 04 Nov 2018 18:41:48 +0100
+
 librdkafka (0.11.6-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru librdkafka-0.11.6/debian/patches/hurd.diff 
librdkafka-0.11.6/debian/patches/hurd.diff
--- librdkafka-0.11.6/debian/patches/hurd.diff  1970-01-01 01:00:00.0 
+0100
+++ librdkafka-0.11.6/debian/patches/hurd.diff  2018-11-04 18:41:07.0 
+0100
@@ -0,0 +1,28 @@
+Index: librdkafka-0.11.4/src/rd.h
+===
+--- librdkafka-0.11.4.orig/src/rd.h
 librdkafka-0.11.4/src/rd.h
+@@ -158,8 +158,8 @@ static RD_INLINE RD_UNUSED char *rd_strn
+ #ifdef __APPLE__
+ /* Some versions of MacOSX dont have IOV_MAX */
+ #define IOV_MAX 1024
+-#elif defined(_MSC_VER)
+-/* There is no IOV_MAX on MSVC but it is used internally in librdkafka */
++#elif defined(_MSC_VER) || defined(__GNU__)
++/* There is no IOV_MAX on MSVC or GNU but it is used internally in librdkafka 
*/
+ #define IOV_MAX 1024
+ #else
+ #error "IOV_MAX not defined"
+Index: librdkafka-0.11.4/src/snappy_compat.h
+===
+--- librdkafka-0.11.4.orig/src/snappy_compat.h
 librdkafka-0.11.4/src/snappy_compat.h
+@@ -5,7 +5,7 @@
+ 
+ #ifdef __FreeBSD__
+ #  include 
+-#elif defined(__APPLE_CC_) || defined(__MACH__)  /* MacOS/X support */
++#elif defined(__APPLE_CC_) || (defined(__MACH__) && defined(__APPLE__))  /* 
MacOS/X support */
+ #  include 
+ 
+ #if__DARWIN_BYTE_ORDER == __DARWIN_LITTLE_ENDIAN
diff -Nru librdkafka-0.11.6/debian/patches/series 
librdkafka-0.11.6/debian/patches/series
--- librdkafka-0.11.6/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ librdkafka-0.11.6/debian/patches/series 2018-11-04 18:41:18.0 
+0100
@@ -0,0 +1 @@
+hurd.diff

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread Kurt Roeckx

On Sun, Nov 04, 2018 at 08:59:05AM -0800, James Bottomley wrote:
> Package: openssl
> Version: 1.1.1-2
> Severity: important
> 
> I've applied all the downgrades recommended to the openssl.cnf file
> and most services are now working again with the exception of openvpn.
> 
> The only failure seems to be a VPN connection to an openwrt router.
> The router is running Chaos Calmer 15.05 and has an upgraded openssl
> (to 1.0.2g-1).
> 
> The error is on the debian server side and only shows up at openvpn
> extreme verbosity:
> 
> Sun Nov  4 08:40:04 2018 us=149552 50.35.68.20:56038 OpenSSL: 
> error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported 
> protocol
> 
> The full verbose negotiation is
> 
> Sun Nov  4 08:40:04 2018 us=116122 50.35.68.20:56038 Control Channel MTU 
> parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
> Sun Nov  4 08:40:04 2018 us=116160 50.35.68.20:56038 Data Channel MTU parms [ 
> L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
> Sun Nov  4 08:40:04 2018 us=116243 50.35.68.20:56038 Local Options String 
> (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,cipher 
> AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
> Sun Nov  4 08:40:04 2018 us=116263 50.35.68.20:56038 Expected Remote Options 
> String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto 
> UDPv4,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
> RSun Nov  4 08:40:04 2018 us=116336 50.35.68.20:56038 TLS: Initial packet 
> from [AF_INET]50.35.68.20:56038, sid=812b650a 26613bfb
> WRRWRSun Nov  4 08:40:04 2018 us=149552 50.35.68.20:56038 OpenSSL: 
> error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported 
> protocol
> Sun Nov  4 08:40:04 2018 us=150331 50.35.68.20:56038 TLS_ERROR: BIO read 
> tls_read_plaintext error
> Sun Nov  4 08:40:04 2018 us=150984 50.35.68.20:56038 TLS Error: TLS object -> 
> incoming plaintext read error
> Sun Nov  4 08:40:04 2018 us=151598 50.35.68.20:56038 TLS Error: TLS handshake 
> failed
> Sun Nov  4 08:40:04 2018 us=152357 50.35.68.20:56038 SIGUSR1[soft,tls-error] 
> received, client-instance restarting
> 
> Obviously this was all working with 1.1.0 so something seems to have
> changed in the tls negotiation routines.
> 
> I can fix this in the client by adding the openssl command
> --tls-version-min 1.0 so it probably means, the way openvpn works that
> the openssl version installed in openwrt has some strange TLS version
> < 1.0 but clearly openssl shouldn't error out when presented with
> lower ciphers it should negotiate the mutually acceptable version.

Older versions of openvpn only support TLS 1.0 because they told
OpenSSL to only use TLS 1.0. Adding the --tls-version-min 1.0
should make it support all TLS versions since openvpn 2.3.4 or
something like that, and I think 2.4 or newer should just work.

But if you changed the openssl.cfg to say all versions are
supported, it should work too, I'm not sure why you say otherwise.


Kurt

Bug#912875: gnome-shell-extension-weather: Stretch open weather extension does not support mbar unit whereas upstream code does

2018-11-04 Thread David Woolley

Package: gnome-shell-extension-weather
Version: 0~20160325.gitb5415ec-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Tried to configure open weather extension for UK standard barometric pressure
unit of millibars, as used in public weather forecasts.

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

Enabled the extension.  Opened it from the tile bar.  Noted that it used the US
unit of inches of mercury.  Selected the settings option and units tab and
tried to select mbar.

   * What was the outcome of this action?

There was no mbar unit. The closest was Bar, but to the, default, 1 decimal
place precision, this is not sufficient. Pa (pascal) gives the right precision,
but gives the decimal point in the wrong place.

   * What outcome did you expect instead?

The menu to include a mbar, or millibar option, which reported numbers with
values close to 1,000.

I checked the upstream on GitLab, and this did include a mbar option, in
extension.js, as enumeration 10.  I looked at the same file in Debian, and the
last entry was enumeration 9.

It is fairly clear from the source code that the internal reprsentation is in
millibars!



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

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

Versions of packages gnome-shell-extension-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-clutter-1.0   1.26.0+dfsg-3
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-soup-2.4  2.56.0-2+deb9u2
ii  gnome-shell  3.22.3-3

Versions of packages gnome-shell-extension-weather recommends:
ii  gnome-tweak-tool  3.22.0-1

gnome-shell-extension-weather suggests no packages.

-- no debconf information

Bug#912874: libdata-treedumper-renderer-gtk-perl: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: libdata-treedumper-renderer-gtk-perl
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#912873: debian-edu-install: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: debian-edu-install
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#912872: clawsker: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: clawsker
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

I see that upstream is active so I expect this port should be totally
doable in this timeframe.

Cheers!
-- 
intrigeri

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

2018-11-04 Thread Thorsten Glaser

retitle 912277 apache2: SSLCertificateChainFile silently ignored, causing 
AH01903 startup failure
thanks

> 2.4.33-3+b1 is the oldest version I can downgrade to, and it
> also exhibits the problem. WTF.

This is a real WTF. I found https://serverfault.com/a/892300/189656
and thought “hey, Apache 2 still documents SSLCertificateChainFile,
plus it’s the proper way to specify the chain given it’s normally
separate from the certificates, and there’s no warning message about
that directive, but let’s give it a shot”.

So I did:

# cat /etc/ssl/W_lan_tarent_de.cer /etc/ssl/W_lan_tarent_de.ca 
>/etc/ssl/combined-cer-chain.pem

Then I edited /etc/apache2/sites-enabled/default-ssl.conf, commenting
out SSLCertificateFile and SSLCertificateChainFile, and adding

SSLCertificateFile /etc/ssl/combined-cer-chain.pem

tglase@tglase:~ $ sudo cleanenv / /etc/init.d/apache2 stop
Stopping Apache httpd web server: apache2.
Server was not running ... (warning).
tglase@tglase:~ $ sudo cleanenv / /etc/init.d/apache2 start
Starting Apache httpd web server: apache2 ..

.oO(wait, what?)

tglase@tglase:~ $ curl --head https://$(hostname -f)/ 
HTTP/1.1 200 OK
Date: Sun, 04 Nov 2018 17:34:29 GMT
Server: Apache/2.4.35 (Debian)
Content-Type: text/html;charset=UTF-8

.oO(what now?)

So it turns out that, ever since some upgrade, the directive
SSLCertificateChainFile is *silently* ignored, but this only
becomes apparent when you stop+start instead of restart (so
they are *still* not equivalent ☹).

I don’t think this acceptable. Ideally, the option would be
still supported; it does no harm and has worked for decades.

If that’s not desired, it MUST yield a warning.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#912871: Depends on libgtk2-perl, that won't be part of Bullseye

2018-11-04 Thread intrigeri

Package: checkgmail
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Alternatively, as suggested on #904557 a few months ago,
I think this package should be removed from the archive.

Cheers!
-- 
intrigeri

Bug#874727: OSG changing VRML renderer away from coin3

2018-11-04 Thread Christoph Berg

Re: To markus 2018-10-05 <20181005080326.gb13...@msg.df7cb.de>
> > it's a packaging bug - libcoin is statically linked with libexpat, and
> > the version being used is outdated. So anything that uses libcoin and
> > libexpat will run into a segfault.
> > 
> > I am not aware of any other application that uses libcoin.
> 
> I noticed because PostGIS is affected via postgis B-D -> libsfcgal-dev
> -> libsfcgal-osg1 -> libopenscenegraph100v5 -> libcoin80v5. Looking at
> https://udd.debian.org/cgi-bin/autoremovals.cgi there's quite a few
> packages depending on coin3. So the question whether this affects
> freecad only or more packages is making quite a difference.

There is some indirect progress on this, Sebastiaan Couwenberg has
submitted patches to change OSG's VRML renderer to SGI Inventor:

| Patches for both OSG packages have been submitted to use SGI Inventor
| instead of COIN:
|
|  https://bugs.debian.org/912866 (openscenegraph)
|  https://bugs.debian.org/912867 (openscenegraph-3.4)

Christoph

Bug#912870: Depends on libgtk2-perl that won't be part of Bullseye

2018-11-04 Thread intrigeri

Source: asciio
Severity: normal
User: debian-p...@lists.debian.org
Usertags: gtk2-removal

Hi!

This package depends on libgtk2-perl, that I intend to remove
from testing soon after the Buster release, and then from sid at
some later point during the Bullseye development cycle:

   https://bugs.debian.org/912860

Please get in touch with the upstream project and suggest they
port this application to libgtk3-perl. I've personally ported
a couple Perl GTK+ apps from 2.x to 3.x and it's rather
straightforward. Upstream for the GTK+ 3 and GObject
Introspection Perl bindings is responsive and happy to add
missing bits to the bindings.

Cheers!
-- 
intrigeri

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

2018-11-04 Thread Thorsten Glaser

Dixi quod…

> I just hit this on another machine, it’s the 2.4.35-1 → 2.4.37-1 upgrade
> that caused the failure.

Given that I originally reported this against 2.4.35-1 and that…

> More debugging data points: this did not occur immediately after
> the package upgrade, only when I did an /etc/init.d/apache2 stop
> followed by start.
> 
> Worse, this persists after downgrading apache2, apache2-bin,
> apache2-data, apache2-utils to 2.4.35-1 (?!?!?!).

… this is obviously nonsense.

2.4.33-3+b1 is the oldest version I can downgrade to, and it
also exhibits the problem. WTF.

We did switch certificates recently, but OpenSSL accepts them…

Still puzzled,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#902557: marked as done (transition: Perl 5.28)

2018-11-04 Thread Mattia Rizzolo

> And now in testing already, so closing this. Thanks again!

Note that in general a transition is considered "done" once the old
package have been removed from testing.

This is not the case here, since both libperl5.26 and perl-modules-5.26
are still in testing.
However, I'll leave it to pochu to reopen the bug he feels strongly
about this.


-- 
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#902775: game-data-packager: please add support for GOG's "Jazz Jackrabbit Collection" package

2018-11-04 Thread Simon McVittie

Control: tags -1 = moreinfo

On Fri, 02 Nov 2018 at 10:58:09 +0100, Fabian Greffrath wrote:
> > as announced in #898301 I am going to package the OpenJazz engine
> > which plays Jazz Jackrabbit's data files. These are now available for
> > download on GOG.com. The contents of the packages as seen by "gdb
> > make-template" is attached.
> 
> now that my openjazz package has been accepted into Debian [1], it would
> be nice to get some progress into this. The package expects its data files
> in "/usr/share/games/jazz-jackrabbit/".

Which of the data files in the template you sent does it need, and where
do they go? (An answer in YAML format would be perfect, an answer in words
would also be fine.)

Until recently, make-template would guess that everything in app/
is needed, except for files that look like licenses, documentation,
or Windows/DOS executables. It now lists tmp/ as well, because GOG have
started shipping some games that need files outside app/.

If some of the .DOC files need to accompany the game data, then this will
need modification. Equally, if some of the game files aren't needed (you
should be able to tell from the engine source code), they can be dropped.

I attach a wild guess at what might be needed.

The "game" in the "gog:" block needs to be set to whatever is listed in
your `lgogdownloader --list` output, which might be jazz_jackrabbit or
jazz_jackrabbit_collection or something else entirely. The "url" is
the end of .
The two don't always match, unfortunately, and I don't think I can find
out the right "game" for games I don't own.

smcv
---
longname: Jazz Jackrabbit
copyright: © 1994 Epic MegaGames
packages:
  jazz-jackrabbit-data:
gog:
  url: jazz_jackrabbit_collection
  game: jazz_jackrabbit_collection# this is a guess
install:
  - assets
doc:
  - documentation
  - licenses

files:
  setup_jazz_jackrabbit_2.0hf_(16882).exe:
unpack:
  format: innoextract
  contents:
- assets
- documentation
- licenses
- GOG cruft

groups:
  archives:
group_members: |
  23609360  e3226006fef35728823326d6525ba53b 
setup_jazz_jackrabbit_2.0hf_(16882).exe

  assets:
group_members: |
  507f5551a249cb492f278880d8b445931d .INI
  1438769c46dc9a8ecbf0e458f8844254df205e BLOCKS.000
  96389 3e96f14a0e82854e682467ecc74fd670 BLOCKS.001
  101307c0ae642f03b0b43a71014b224a00aea0 BLOCKS.002
  86598 88af3ea8dd0bb291d6b908eb72c35460 BLOCKS.003
  77847 47ef1495812212988b0e81d658cb93b1 BLOCKS.004
  1871911173d1dc25401cc4f3141982f6e3a6c4 BLOCKS.005
  137958eb19778c78123082d8e759417e61d2d2 BLOCKS.006
  146538f10c97f224d3a2ed7be94afe53835738 BLOCKS.007
  103147e923b9f066022a19d0b5e10ae04c0b20 BLOCKS.008
  142685c890dccdd9eaf0aba7213b592808354a BLOCKS.009
  145242b7e99825b03b379411b7d943f7b07128 BLOCKS.010
  1387170c01719b456c9b0d56512cd733fcb973 BLOCKS.011
  152890e0ef3d4bebdfbf691258cf43f2d9714a BLOCKS.012
  1120546c298b1f23ec89ae257ac00c90d88c74 BLOCKS.013
  156682c84d0baa930b673f6ef334bb81415e1e BLOCKS.014
  112070fabde1722a6b4a94263498413cd66401 BLOCKS.015
  13264711dda5d0b45958673033eafc36737df7 BLOCKS.016
  100621c1741331140f91a9f73bb2b3b33eff2d BLOCKS.017
  100961d610eb0e9ec9ec96dc54b9b1ce493da3 BLOCKS.020
  1586880c911cd9c8b81a6c5838f9bb8ece4c6b BLOCKS.022
  1007483f1093f2c4d5d2b6a198ca24e1759a44 BLOCKS.023
  1736808b5aa732715be47985904dacb73bbd6c BLOCKS.030
  177459da46cecd1ea53b57109afcb060829940 BLOCKS.031
  158103b44176f16aa7e4683b6e8df72b7f2b69 BLOCKS.032
  1669590a70f78d92727c4a0ab51a3de0f9cfe3 BLOCKS.033
  147171ae03bf33a096b72758f437f7a156ff17 BLOCKS.034
  105609f733154709616ca9bbb1dee7e2915b13 BLOCKS.035
  57638 7572aa950fc3b508a2b3c5a92fce366f BLOCKS.036
  93566 dded68f87fab807d0022e0762488968e BLOCKS.037
  78206 461e9836e47434b4396e9e3e3e813711 BLOCKS.038
  158103b44176f16aa7e4683b6e8df72b7f2b69 BLOCKS.041
  96581 de7401f0f86332510d35f070e1030ddf BLOCKS.050
  96580 b8f2977ee00e51c4659cf7c1346c9a90 BLOCKS.051
  96832 c5e600a01671f77ff1e59a396da3e34d BLOCKS.052
  1610222e942c6f260b57f8bd515268becf873f BONUS.000
  51832 a90a22d0fb4b7d1193299f57aa729ae8 BONUS.0SC
  98008 fb3da04a51001d1a0c743e2de4cad7e0 BONUS.PSM
  54765 a74545bc1f8da695092484be4ff2d105 BONUS2.000
  62546 f731474749792dde15b1274a94385bf9 BONUS3.000
  59143 9524a8713ec6366225e227cdb2e3b5fb BONUS4.000
  60107 a5c7efcbd2098e7a674e251e33e46e8b BONUS5.000
  53279 e14a5e2c6f1bd0f99095e025f9ac66ea BONUS6.000
  6455  4b5e279d1c6fbb3577fcafee71ceca02 BONUSMAP.000
  8827  ace00e71bcb0674d629c132ff63d89a7 BONUSMAP.001
  6372

Bug#874727: libcoin80v5: Program using libcoin80v5 and any other library that uses lebexpat1 segfaults.

2018-11-04 Thread Bernhard Übelacker

Hello all,
tried to reproduce and still receive the crash triggered by either SVG
import or the manual action in the python console.

The parameter --enable-system-expat seems to just defines HAVE_SYSTEM_EXPAT,
which seems not used later.

Attached patch makes coin3 not to build the subdirectory src/xml/expat
and avoids linking to that local libexpat.la.

I assume therefore now following warning is shown:
dpkg-shlibdeps: warning: symbol XML_ParserFree used by 
debian/libcoin80v5/usr/lib/x86_64-linux-gnu/libCoin.so.80.0.0 found in none of 
the libraries.

But a local built package libcoin80v5 with this patch applied makes
Freecad not crash on SVG import or the manual action in python console.

Upstream seems to have added in [1] related changes into the cmake build system.

Kind regards,
Bernhard


freecad 0.17+dfsg1-5
libcoin80v5 3.1.4~abc9f50+dfsg3-2

[1] 
https://bitbucket.org/Coin3D/coin/pull-requests/107/allow-to-use-system-expat/diff
Description: Do not build and link internal expat

Author: Bernhard Ãbelacker 
Bug-Debian: https://bugs.debian.org/874727
Forwarded: no
Last-Update: 2018-11-04

---

--- coin3-3.1.4~abc9f50+dfsg3.orig/src/Makefile.am
+++ coin3-3.1.4~abc9f50+dfsg3/src/Makefile.am
@@ -83,7 +83,7 @@ libCoin@SUFFIX@_la_LIBADD = actions/liba
 	hardcopy/libhardcopy.la threads/libthreads.la   \
 	shaders/libshaders.la shadows/libshadows.la geo/libgeo.la   \
 	foreignfiles/libforeignfiles.la xml/libxml.la   \
-	xml/expat/libexpat.la profiler/libprofiler.la   \
+	profiler/libprofiler.la \
 	vrml97/libvrml97.la scxml/libscxml.la soscxml/libsoscxml.la $(SUPERGLULIBADD)
 endif
 endif
--- coin3-3.1.4~abc9f50+dfsg3.orig/src/Makefile.in
+++ coin3-3.1.4~abc9f50+dfsg3/src/Makefile.in
@@ -224,7 +224,6 @@ LTLIBRARIES = $(lib_LTLIBRARIES)
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	geo/libgeo.la \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	foreignfiles/libforeignfiles.la \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	xml/libxml.la \
-@HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	xml/expat/libexpat.la \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	profiler/libprofiler.la \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	vrml97/libvrml97.la \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	scxml/libscxml.la \
@@ -702,7 +701,7 @@ DEFAULT_INCLUDES = -I$(top_builddir)/inc
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	hardcopy/libhardcopy.la threads/libthreads.la   \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	shaders/libshaders.la shadows/libshadows.la geo/libgeo.la   \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	foreignfiles/libforeignfiles.la xml/libxml.la   \
-@HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	xml/expat/libexpat.la profiler/libprofiler.la   \
+@HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	profiler/libprofiler.la \
 @HACKING_DYNAMIC_MODULES_FALSE@@MAC_FRAMEWORK_FALSE@	vrml97/libvrml97.la scxml/libscxml.la soscxml/libsoscxml.la $(SUPERGLULIBADD)
 
 @HACKING_DYNAMIC_MODULES_TRUE@@MAC_FRAMEWORK_FALSE@libCoin@SUFFIX@_la_LIBADD = 
--- coin3-3.1.4~abc9f50+dfsg3.orig/src/xml/Makefile.am
+++ coin3-3.1.4~abc9f50+dfsg3/src/xml/Makefile.am
@@ -1,6 +1,6 @@
 ## Process this file with automake to generate Makefile.in.
 
-SUBDIRS = expat
+SUBDIRS = 
 
 RegularSources = \
 document.cpp \
--- coin3-3.1.4~abc9f50+dfsg3.orig/src/xml/Makefile.in
+++ coin3-3.1.4~abc9f50+dfsg3/src/xml/Makefile.in
@@ -424,7 +424,7 @@ target_alias = @target_alias@
 target_cpu = @target_cpu@
 target_os = @target_os@
 target_vendor = @target_vendor@
-SUBDIRS = expat
+SUBDIRS = 
 RegularSources = \
 document.cpp \
 element.cpp \

Bug#912869: znc: systemd unit file missing + default znc user

2018-11-04 Thread K. de Jong

Package: znc
Version: 1.6.5-1+deb9u1
Severity: wishlist

Dear Maintainer,


I would like to request the following additions to this package:
1) A systemd unit file for easy state management, an example can be
found here: https://wiki.znc.in/Running_ZNC_as_a_system_daemon#systemd
2) Let the package create a default znc user and use that user in the systemd 
unit, the
creation of this user is also mentioned in the Debian wiki:
https://wiki.debian.org/ZNC_IRC_bouncer

With these additions the znc package will have more out-of-the-box
experience.


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.4 (stretch)
Release:9.4
Codename:   stretch
Architecture: armv7l

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

Versions of packages znc depends on:
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+rpi1+deb9u1
ii  libicu5757.1-6+deb9u2
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libssl1.1   1.1.0f-3+deb9u2
ii  libstdc++6  6.3.0-18+rpi1+deb9u1

Versions of packages znc recommends:
pn  znc-perl
pn  znc-python  
pn  znc-tcl 

znc suggests no packages.

Bug#912868: rdesktop: fails to connect to a VirtualBox 5.2 server

2018-11-04 Thread luc

Package: rdesktop
Version: 1.8.3-2+b1
Severity: normal

Dear Maintainer,

After enabling the RDP server for a VM in VirtualBox 5.2.20, I tried to connect
to it using `rdesktop `. Rdesktop outputs:

Autoselected keyboard map en-us
Failed to negotiate protocol, retrying with plain RDP.
ERROR: Connection closed

And exits with status 76. My rdesktop version is 1.8.3-2+b1.

When retrying with a binary built from source (not the latest release, which
dates from 2015, but the current git status, branch master, as of 2018-11-04),
this issue no longer occurs.



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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 rdesktop depends on:
ii  libasound21.1.6-1
ii  libc6 2.27-6
ii  libgssglue1   0.4-2+b2
ii  libpcsclite1  1.8.23-3
ii  libssl1.1 1.1.1-2
ii  libx11-6  2:1.6.6-1
ii  libxrandr22:1.5.1-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
ii  pcscd  1.8.23-3

-- no debconf information

Bug#912865: ITP: mako - lightweight notification daemon for Wayland

2018-11-04 Thread Birger Schacht

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: mako
  Version : 1.1
  Upstream Author : emersion
* URL : https://wayland.emersion.fr/mako/
* License : Expat
  Programming Lang: C
  Description : lightweight notification daemon for Wayland

mako is a lightweight notification daemon for Wayland compositors that
support the layer-shell protocol.

There is already a python template library for python with the source
package name mako- i'm not sure what the best namechange for the
notification daemon could be? Should only the source packge be renamed
or also the binary package? If the former, is mako-src to generic?



signature.asc
Description: OpenPGP digital signature

Bug#850171: Recommend that manpages contain an EXAMPLES section

2018-11-04 Thread Russ Allbery

Mattia Rizzolo  writes:

> What I mean is: if there is really enough people wanting this change by
> all means do it, but 1. make the wording clear that is really optional
> (in this view, I see "recommended" as too strong a word) and 2. I really
> hope lintian won't start bothering for this.

Maybe https://wiki.debian.org/UpstreamGuide would be a better place for
this?  Currently, it doesn't even explicitly recommend that upstream
provide man pages.

-- 
Russ Allbery (r...@debian.org)

Bug#912866: openscenegraph: Use SGI Inventor instead COIN for VRML.

2018-11-04 Thread Bas Couwenberg

Source: openscenegraph
Version: 3.2.3+dfsg1-2
Severity: important
Tags: patch

Dear Maintainer,

Due to the unresolved RC bug in coin3 (#874727) OSG and its reverse
dependencies will be autoremoved from testing.

Please consider the attached patch to use SGI Inventor instead of COIN
for VRML.

Kind Regards,

Bas
diff -Nru openscenegraph-3.2.3+dfsg1/debian/changelog 
openscenegraph-3.2.3+dfsg1/debian/changelog
--- openscenegraph-3.2.3+dfsg1/debian/changelog 2016-05-16 22:07:18.0 
+0200
+++ openscenegraph-3.2.3+dfsg1/debian/changelog 2018-11-04 15:32:45.0 
+0100
@@ -1,3 +1,10 @@
+openscenegraph (3.2.3+dfsg1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use SGI Inventor instead COIN for VRML. See: #874727
+
+ -- Bas Couwenberg   Sun, 04 Nov 2018 15:32:45 +0100
+
 openscenegraph (3.2.3+dfsg1-2) unstable; urgency=medium
 
   * Fix FTBFS on Hurd.  Thanks Bas Couwenberg (Closes: #824395).
diff -Nru openscenegraph-3.2.3+dfsg1/debian/control 
openscenegraph-3.2.3+dfsg1/debian/control
--- openscenegraph-3.2.3+dfsg1/debian/control   2016-05-16 16:31:19.0 
+0200
+++ openscenegraph-3.2.3+dfsg1/debian/control   2018-11-04 15:32:45.0 
+0100
@@ -15,7 +15,7 @@
lib3ds-dev,
libfreetype6-dev,
libpng-dev,
-   libcoin80-dev,
+   inventor-dev,
libgdal-dev,
libx11-dev,
libxmu-dev,

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

2018-11-04 Thread Thorsten Glaser

Hi Stefan,

> On Monday, 29 October 2018 20:31:54 CET Thorsten Glaser wrote:
> > tglase@tglase:~ $ cat /var/log/apache2/error.log
> > [Mon Oct 29 20:18:58.090841 2018] [ssl:emerg] [pid 17306] AH01903: Failed to
> > configure CA certificate chain!
> > [Mon Oct 29 20:18:58.090919 2018] [ssl:emerg] [pid 17306] AH02311: Fatal
> > error initialising mod_ssl, exiting.
> > See /var/log/apache2/error.log for more information AH00016: Configuration
> > Failed
> 
> Have you looked into  /var/log/apache2/error.log if there is more 
> information? 

the thing you quoted was exactly what was in /var/log/apache2/error.log
as the “cat” showed…

I just hit this on another machine, it’s the 2.4.35-1 → 2.4.37-1 upgrade
that caused the failure.

> If there is none, try adding loglevel ssl:debug and re-try.

OK, thanks for the debugging help.

That gives:

[Sun Nov 04 17:05:02.839408 2018] [ssl:info] [pid 18196] AH01887: Init: 
Initializing (virtual) servers for SSL
[Sun Nov 04 17:05:02.839427 2018] [ssl:info] [pid 18196] AH01914: Configuring 
server ci-busyapps.lan.tarent.de:443 for SSL protocol
[Sun Nov 04 17:05:02.839433 2018] [ssl:debug] [pid 18196] 
ssl_engine_init.c(1748): AH10083: Init: (ci-busyapps.lan.tarent.de:443) mod_md 
support is unavailable.
[Sun Nov 04 17:05:02.839729 2018] [ssl:emerg] [pid 18196] AH01903: Failed to 
configure CA certificate chain!
[Sun Nov 04 17:05:02.839739 2018] [ssl:emerg] [pid 18196] AH02311: Fatal error 
initialising mod_ssl, exiting. See /var/log/apache2/error.log for more 
information
AH00016: Configuration Failed

So perhaps the mod_ssl backport / new feature was bad?

On a hunch, I tried a2enmod md, but that does not change much:

[Sun Nov 04 17:05:47.417353 2018] [ssl:info] [pid 18229] AH01887: Init: 
Initializing (virtual) servers for SSL
[Sun Nov 04 17:05:47.417371 2018] [ssl:info] [pid 18229] AH01914: Configuring 
server ci-busyapps.lan.tarent.de:443 for SSL protocol
[Sun Nov 04 17:05:47.417377 2018] [ssl:debug] [pid 18229] 
ssl_engine_init.c(1748): AH10083: Init: (ci-busyapps.lan.tarent.de:443) mod_md 
support is available.
[Sun Nov 04 17:05:47.417663 2018] [ssl:emerg] [pid 18229] AH01903: Failed to 
configure CA certificate chain!
[Sun Nov 04 17:05:47.417673 2018] [ssl:emerg] [pid 18229] AH02311: Fatal error 
initialising mod_ssl, exiting. See /var/log/apache2/error.log for more 
information
AH00016: Configuration Failed


More debugging data points: this did not occur immediately after
the package upgrade, only when I did an /etc/init.d/apache2 stop
followed by start.

Worse, this persists after downgrading apache2, apache2-bin,
apache2-data, apache2-utils to 2.4.35-1 (?!?!?!).

Dazed and confused,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#912867: openscenegraph-3.4: Use SGI Inventor instead COIN for VRML.

2018-11-04 Thread Bas Couwenberg

Source: openscenegraph-3.4
Version: 3.4.1+dfsg1-4
Severity: important
Tags: patch

Dear Maintainer,

Due to the unresolved RC bug in coin3 (#874727) OSG and its reverse
dependencies will be autoremoved from testing.

Please consider the attached patch to use SGI Inventor instead of COIN
for VRML.

Kind Regards,

Bas
diff -Nru openscenegraph-3.4-3.4.1+dfsg1/debian/changelog 
openscenegraph-3.4-3.4.1+dfsg1/debian/changelog
--- openscenegraph-3.4-3.4.1+dfsg1/debian/changelog 2018-09-05 
21:56:37.0 +0200
+++ openscenegraph-3.4-3.4.1+dfsg1/debian/changelog 2018-11-04 
15:34:31.0 +0100
@@ -1,3 +1,10 @@
+openscenegraph-3.4 (3.4.1+dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use SGI Inventor instead COIN for VRML. See: #874727
+
+ -- Bas Couwenberg   Sun, 04 Nov 2018 15:34:31 +0100
+
 openscenegraph-3.4 (3.4.1+dfsg1-4) unstable; urgency=medium
 
   * debian/control: Updated Vcs-* fields.
diff -Nru openscenegraph-3.4-3.4.1+dfsg1/debian/control 
openscenegraph-3.4-3.4.1+dfsg1/debian/control
--- openscenegraph-3.4-3.4.1+dfsg1/debian/control   2018-09-05 
16:58:20.0 +0200
+++ openscenegraph-3.4-3.4.1+dfsg1/debian/control   2018-11-04 
15:34:31.0 +0100
@@ -15,7 +15,7 @@
lib3ds-dev,
libfreetype6-dev,
libpng-dev,
-   libcoin80-dev,
+   inventor-dev,
libgdal-dev,
libx11-dev,
libxmu-dev,

Bug#901689: libasound2: Fails to find configuration for Intel HDA soundcard

2018-11-04 Thread mh


Dear Maintainer,

I can verify this problem using libasound2 version 1.1.7-1. However, 
when I downgraded to libasound2_1.1.6-1 sound worked properly. The 
suggest fix of adding


'HDA Intel' cards.HDA-Intel

worked for me with version libasound2_1.1.7-1.

Running sid, amd64, kernel version 4.18.0-2-amd64.


Regards,

Michael Heyes

Bug#912695: apt-show-versions: breaks "apt-get update" and uninstallable after Perl 5.28 upgrade

2018-11-04 Thread Salvatore Bonaccorso

Hi

This is likely due to the perl upstream change around/with
https://perl5.git.perl.org/perl.git/commitdiff/c0e3b4b51cabf15ed8fc5f564dfeea31c25f5239
.

It can be workarounded by either setting higher limits for
recursion_limit/recursion_limit_hash or disable it with -1

$Storable::recursion_limit=-1;
$Storable::recursion_limit_hash=-1;

but I'm not sure this will be the right solution.

Regards,
Salvatore

Bug#743133: Processed: Move bug from clang-4.0 to clang-8

2018-11-04 Thread Sylvestre Ledru

Bonjour Marc!

Sorry about the latency! I fixed it in the repo. Will be fixed in 7-9!
Cheers

S


Le 04/11/2018 à 15:21, Debian Bug Tracking System a écrit :
> Processing commands for cont...@bugs.debian.org:
>
>> reopen 743133
> Bug #743133 {Done: Debian FTP Masters } 
> [clang-4.0] clang-3.5: target selection in manpage
> 'reopen' may be inappropriate when a bug has been closed with a version;
> all fixed versions will be cleared, and you may need to re-add them.
> Bug reopened
> No longer marked as fixed in versions 1:4.0.1-10+rm.
>> reassign 743133 clang-8 1:8~svn343154-1
> Bug #743133 [clang-4.0] clang-3.5: target selection in manpage
> Bug reassigned from package 'clang-4.0' to 'clang-8'.
> No longer marked as found in versions 
> llvm-toolchain-snapshot/1:4.0~svn279916-1.
> Ignoring request to alter fixed versions of bug #743133 to the same values 
> previously set
> Bug #743133 [clang-8] clang-3.5: target selection in manpage
> Marked as found in versions llvm-toolchain-snapshot/1:8~svn343154-1.
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.

Bug#912863: RM: libjs-jquery-uploadify -- RoQA; needs manual cruft removal

2018-11-04 Thread Adrian Bunk

Package: ftp.debian.org
Severity: normal
Control: block 908768 by -1
Control: tags 908768 - moreinfo

jquery-goodies (12-1.1) unstable; urgency=low

  * Non-maintainer upload.
  * Drop the obsolete libjs-jquery-uploadify. (Closes: #905602)

 -- Adrian Bunk   Sat, 22 Sep 2018 21:04:15 +0300

Bug#912864: openssl: new version of openssl breaks some openvpn clients

2018-11-04 Thread James Bottomley

Package: openssl
Version: 1.1.1-2
Severity: important

I've applied all the downgrades recommended to the openssl.cnf file
and most services are now working again with the exception of openvpn.

The only failure seems to be a VPN connection to an openwrt router.
The router is running Chaos Calmer 15.05 and has an upgraded openssl
(to 1.0.2g-1).

The error is on the debian server side and only shows up at openvpn
extreme verbosity:

Sun Nov  4 08:40:04 2018 us=149552 50.35.68.20:56038 OpenSSL: 
error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported 
protocol

The full verbose negotiation is

Sun Nov  4 08:40:04 2018 us=116122 50.35.68.20:56038 Control Channel MTU parms 
[ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sun Nov  4 08:40:04 2018 us=116160 50.35.68.20:56038 Data Channel MTU parms [ 
L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Sun Nov  4 08:40:04 2018 us=116243 50.35.68.20:56038 Local Options String 
(VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,cipher 
AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sun Nov  4 08:40:04 2018 us=116263 50.35.68.20:56038 Expected Remote Options 
String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,cipher 
AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
RSun Nov  4 08:40:04 2018 us=116336 50.35.68.20:56038 TLS: Initial packet from 
[AF_INET]50.35.68.20:56038, sid=812b650a 26613bfb
WRRWRSun Nov  4 08:40:04 2018 us=149552 50.35.68.20:56038 OpenSSL: 
error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported 
protocol
Sun Nov  4 08:40:04 2018 us=150331 50.35.68.20:56038 TLS_ERROR: BIO read 
tls_read_plaintext error
Sun Nov  4 08:40:04 2018 us=150984 50.35.68.20:56038 TLS Error: TLS object -> 
incoming plaintext read error
Sun Nov  4 08:40:04 2018 us=151598 50.35.68.20:56038 TLS Error: TLS handshake 
failed
Sun Nov  4 08:40:04 2018 us=152357 50.35.68.20:56038 SIGUSR1[soft,tls-error] 
received, client-instance restarting

Obviously this was all working with 1.1.0 so something seems to have
changed in the tls negotiation routines.

I can fix this in the client by adding the openssl command
--tls-version-min 1.0 so it probably means, the way openvpn works that
the openssl version installed in openwrt has some strange TLS version
< 1.0 but clearly openssl shouldn't error out when presented with
lower ciphers it should negotiate the mutually acceptable version.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages openssl depends on:
ii  libc6  2.27-8
ii  libssl1.1  1.1.1-2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20170717

-- Configuration Files:
/etc/ssl/openssl.cnf changed [not included]

-- no debconf information

Bug#906081: Fwd: [debian-mysql] Bug#906081: galera-3: FTBFS on non-linux systems

2018-11-04 Thread Otto Kekäläinen

Thanks Samuel!



su 4. marrask. 2018 klo 14.18 Samuel Thibault (sthiba...@debian.org)
kirjoitti:

> Hello,
>
> Otto Kekäläinen, le lun. 15 oct. 2018 12:02:46 +0300, a ecrit:
> > Since upstream is positive, please make a PR directly on upstream at
> > https://github.com/codership/galera/?
>
> I pushed to
>
> https://github.com/codership/galera/pull/527
>
> Samuel
>


-- 
Otto Kekäläinen
https://keybase.io/ottok

Bug#912737: [Pkg-openssl-devel] Bug#912737: Bug#912737: openssl: SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed

2018-11-04 Thread Sebastian Andrzej Siewior

On 2018-11-04 15:10:42 [+0100], Julien Lecomte wrote:
> Hello
Hi,

> Thanks to your remark I tried connecting my computer directly to the set-top
> box.
> 
> Connected directly, the file downloads fine (verified via md5sum).
> Connected indirectly, the download shows the issues I encountered.
> 
> The "indirect" route is desktop <-> ubiquiti unifi switch <-> ubiquiti unifi
> security gateway <-> set-top box.
> 
> I'll move the issue directly to ubiquiti to figure out what is going wrong.

Okay. Could you please try
openssl s_client -connect download.lenovo.com:443

and check if you see the same ciphers & certificate with and without the
ubiquiti HW in between?

> Thanks
> Julien

Sebastian

Bug#912862: Please provide libgap.la

2018-11-04 Thread Tobias Hansen

Source: gap
Severity: wishlist

Dear Bill,

please ship libgap.la in the Debian package. Sagemath started using gap's 
version of libgap so it would be much better for us if we could do so as well. 
That way we could completely get rid of libgap-sage.

As far as I see this would just amount to adding
$(MAKE) libgap.la
to debian/rules and installing that file in gap-dev (or another package).

Best,
Tobias

Bug#912819: llvm-toolchain-7: FTBFS on hurd-i386

2018-11-04 Thread Sylvestre Ledru



Le 04/11/2018 à 15:02, Samuel Thibault a écrit :
>
> Also, it's missing -I/usr/include/$(DEB_HOST_MULTIARCH), that's also
> problematic. I guess we need to define

Or just disable libc++ for hurd ;)


S

Bug#912861: RM: clamtk-nautilus [all] -- ROM; NBS - arch all cruft

2018-11-04 Thread Scott Kitterman

Package: ftp.debian.org
Severity: normal

clamtk-nautilus | 5.25-1| unstable   | all

NBS as of 5.26-1.  Not in cruft report, so needs manual rm.

Scott K

Bug#912819: llvm-toolchain-7: FTBFS on hurd-i386

2018-11-04 Thread Samuel Thibault

Sylvestre Ledru, le dim. 04 nov. 2018 17:46:04 +0100, a ecrit:
> Le 04/11/2018 à 15:02, Samuel Thibault a écrit :
> > Also, it's missing -I/usr/include/$(DEB_HOST_MULTIARCH), that's also
> > problematic. I guess we need to define
> 
> Or just disable libc++ for hurd ;)

That's an option indeed :)

I guess packages depending on llvm don't use c++ that much for now?

The non-definition of __GNU__ and __ELF__ and missing
/usr/include/i386-gnu inclusion will however quickly pose problems, so
at least I'll fix these.

Samuel

Bug#912819: llvm-toolchain-7: FTBFS on hurd-i386

2018-11-04 Thread Sylvestre Ledru



Le 04/11/2018 à 17:47, Samuel Thibault a écrit :
> Sylvestre Ledru, le dim. 04 nov. 2018 17:46:04 +0100, a ecrit:
>> Le 04/11/2018 à 15:02, Samuel Thibault a écrit :
>>> Also, it's missing -I/usr/include/$(DEB_HOST_MULTIARCH), that's also
>>> problematic. I guess we need to define
>> Or just disable libc++ for hurd ;)
> That's an option indeed :)
>
> I guess packages depending on llvm don't use c++ that much for now?
AFAIK, no package in Debian uses libc++ yet.
> The non-definition of __GNU__ and __ELF__ and missing
> /usr/include/i386-gnu inclusion will however quickly pose problems, so
> at least I'll fix these.

ok, thanks!

S

Bug#908964: evince: reports "! SyncTeX Error : No file?" at startup

2018-11-04 Thread G. Branden Robinson

Package: evince
Version: 3.30.1-1
Followup-For: Bug #908964

This problem is reproducible on the version of evince in testing, and
with the following trivial document:

$ cat > hello.txt
Hello, world!

Make me with "groff -Tpdf hello.txt > hello.pdf".

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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  evince-common3.30.1-1
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libevdocument3-4 3.30.1-1
ii  libevview3-3 3.30.1-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgnome-desktop-3-173.30.1-1
ii  libgtk-3-0   3.24.1-2
ii  libnautilus-extension1a  3.30.0-4
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libsecret-1-00.18.6-3
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1

Versions of packages evince suggests:
ii  gvfs 1.38.0-2
ii  nautilus-sendto  3.8.6-2
ii  poppler-data 0.4.9-2
pn  unrar

-- no debconf information

Bug#910104: hypre: autopkgtest times out most of the times

2018-11-04 Thread Drew Parsons

Source: hypre
Followup-For: Bug #910104

Hi Paul, a workaround for Bug#910485 has been uploaded with libpsm2
11.2.68-2.

But the debci blacklist on hypre seems to block tests triggered
manually using the ci API.

Is it possible to trigger a hypre test in unstable (with libpsm2
11.2.68-2) to see what state it's currently in?

Drew

Bug#912860: Don't ship libgtk2-perl in Bullseye

2018-11-04 Thread intrigeri

Source: libgtk2-perl
Severity: important
X-Debbugs-Cc: jbi...@debian.org
User: debian-p...@lists.debian.org
Usertags: gtk2-removal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs

The Debian GNOME Maintainers are working to reduce GTK+ 2 usage in
Debian. GTK+ 3 has been declared stable with its 3.22 release in
September 2016. Bullseye will likely be frozen early 2021, which will
already have given upstream authors more than four years to migrate.

The GTK+ 2 bindings for Perl are stable but nobody is actively working
on them: the last time significant fixes were committed upstream was
in 2015 and nobody is following up on the bug reports anymore. So I'd
be uncomfortable seeing us commit to support this stack until mid-2024
(likely end of Bullseye security support), let alone mid-2016 (LTS).

Therefore, I intend to remove libgtk2-perl from testing soon after the
Buster release, and then from sid later during the Bullseye
development cycle. I'll file bug reports soonish against all
reverse-dependencies so their maintainers have a couple years to find
a solution.

I've personally ported a couple Perl GTK+ apps from 2.x to 3.x and
it's mostly straightforward. Upstream for libgtk3-perl and
libglib-object-introspection-perl is responsive and happy to add any
bits that may be missing.

If critical bits of Debian still depend on libgtk2-perl (d-i?),
please let me know :)

Cheers,
-- 
intrigeri

Bug#912617: libsdl2-image: CVE-2018-3977: do_layer_surface code execution vulnerability

2018-11-04 Thread Chris Lamb

Hi Manuel,

> I suppose that it's better that you go ahead unless they reply
> between now and you reading this e-mail.

Sure. From this I will go ahead and upload to sid. I've requested
access to the Salsa group so I can push my changes.

(I still await the Security Team on stable.)


Regards,

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

Bug#912859: mark python3-distutils-extra Multi-Arch: foreign

2018-11-04 Thread Helmut Grohne

Package: python3-distutils-extra
Version: 2.41
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

python3-distutils-extra cannot satisfy cross Build-Depends from e.g.
python-apt. In general, Architecture: all packages can never satisfy
cross Build-Depends unless marked Multi-Arch: foreign. In this case, the
marking looks correct to me, but it is not entirely trivial to verify.
On the dependency side, there is intltool, which is already Multi-Arch:
foreign. Then there is python3:any, which is also fine due to the :any
annotation. Then it does have maintainer scripts for byte compilation.
That step producs architecture-dependent .pyc files, but those .pyc
files will work with whatever python3 was installed. So that should be
fine as well. If someone ever uses python3-distutils-extra with an
embedded interpreter, the corresponding .pyc files will be missing, but
that's likely a minor issue compared to the problems we solve by marking
it Multi-Arch: foreign. Please consider applying the attached patch.

Helmut
diff --minimal -Nru python-distutils-extra-2.41/debian/changelog 
python-distutils-extra-2.41+nmu1/debian/changelog
--- python-distutils-extra-2.41/debian/changelog2018-03-25 
21:22:32.0 +0200
+++ python-distutils-extra-2.41+nmu1/debian/changelog   2018-11-04 
17:22:53.0 +0100
@@ -1,3 +1,10 @@
+python-distutils-extra (2.41+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all packages Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 04 Nov 2018 17:22:53 +0100
+
 python-distutils-extra (2.41) unstable; urgency=medium
 
   * Update Vcs-* for the move to salsa.debian.org
diff --minimal -Nru python-distutils-extra-2.41/debian/control 
python-distutils-extra-2.41+nmu1/debian/control
--- python-distutils-extra-2.41/debian/control  2018-03-25 21:22:32.0 
+0200
+++ python-distutils-extra-2.41+nmu1/debian/control 2018-11-04 
17:22:51.0 +0100
@@ -23,6 +23,7 @@
 
 Package: python-distutils-extra
 Architecture: all
+Multi-Arch: foreign
 XB-Python-Version: ${python:Versions}
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, intltool
 Suggests: devscripts
@@ -38,6 +39,7 @@
 
 Package: python3-distutils-extra
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, intltool
 Suggests: devscripts
 Description: enhancements to the Python3 build system

Bug#912858: argon2: FTBFS on hurd-i386

2018-11-04 Thread Samuel Thibault

Source: argon2
Version: 0~20171227-0.1
Severity: important
Tags: patch

Hello,

argon2 FTBFS on hurd-i386 because its Makefile does not know how to
build a shared library, could you apply the attached patch? (we need
this package for php7.3).

Samuel

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

Kernel: Linux 4.19.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: argon2-0~20171227/Makefile
===
--- argon2-0~20171227.orig/Makefile
+++ argon2-0~20171227/Makefile
@@ -58,7 +58,7 @@ BUILD_PATH := $(shell pwd)
 KERNEL_NAME := $(shell uname -s)
 
 LIB_NAME=argon2
-ifeq ($(KERNEL_NAME), Linux)
+ifeq ($(KERNEL_NAME), $(filter $(KERNEL_NAME),Linux GNU))
LIB_EXT := so.$(ABI_VERSION)
LIB_CFLAGS := -shared -fPIC -fvisibility=hidden -DA2_VISCTL=1
SO_LDFLAGS := -Wl,-soname,lib$(LIB_NAME).$(LIB_EXT)

Bug#912857: libruby2.5 is wrongly marked Multi-Arch: same

2018-11-04 Thread Helmut Grohne

Package: libruby2.5
Version: 2.5.1-6+b1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

libruby2.5 is wrongly marked Multi-Arch: same. It fails to coinstall on
amd64 and arm64:

| Unpacking libruby2.5:arm64 (2.5.1-6+b1) ...
| dpkg: error processing archive 
/tmp/apt-dpkg-install-xsTPRC/29-libruby2.5_2.5.1-6+b1_arm64.deb (--unpack):
|  trying to overwrite shared 
'/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png', 
which is different from other instances of package libruby2.5:arm64
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
| Errors were encountered while processing:
|  /tmp/apt-dpkg-install-xsTPRC/29-libruby2.5_2.5.1-6+b1_arm64.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)

The multiarch hinter says:

| libruby2.5 conflicts on 
/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png on 
any two of amd64, arm64, armel, armhf, and 6 more

Please remove the erroneous Multi-Arch: same marking or fix the file
conflict.

Helmut

Bug#811496: Preparing to close the bug report

2018-11-04 Thread Gabriel F. T. Gomes

On 04 Nov 2018, Gabriel F. T. Gomes wrote:
>
>Bug reports [1,2,3,4] explaining that the fix needs to be done by the
>packages: dkms, dlocate, git, and grub2, have been created.

I forgot the links.  :)

[1] https://bugs.debian.org/912849
[2] https://bugs.debian.org/912850
[3] https://bugs.debian.org/912852
[4] https://bugs.debian.org/912854

< 1 2 3 4 >

101 - 200 of 312 matches

Mail list logo