Bug#912532: stunnel4: "Internal error: double free attempt" with OpenSSL 1.1.1-1 and 1.1.1-2

2018-10-31 Thread Frank Chung
Package: stunnel4
Version: 3:5.49-1
Severity: important

Dear Maintainer,

My stunnel4 is set up as a SOCKS VPN with configuration that is similar to 


My default Debian release is "testing", but in order to try TLS 1.3 early, I 
installed openssl 1.1.1~~pre8-1 from experimental around early August 2018.
stunnel4 ran with this version of openssl just fine, negotiating TLS 1.3 with 
stunnel4 client + openssl 1.1.1~~pre8-1 on another host.

Debian migrated openssl 1.1.1-1 to testing on 2018-10-28. Since upgrading to 
this version, the stunnel4 server had been failing every few hours. (The client
side worked just fine though.) Typically when traffic is heavy, e.g. opening 
many Chrome tabs from the client side, the stunnel4 server side would fail
after 20 to 30 seconds.

syslog on the server reveals (I start with connection 4943 where the error 
occurred; stunnel4 had been running without errors until then):

Oct 29 14:55:00 goo stunnel: LOG5[4943]: Service [socksSSL] accepted connection 
from nnn.nnn.nnn.nnn:26462
Oct 29 14:55:00 goo stunnel: LOG6[4943]: Peer certificate required
Oct 29 14:55:00 goo stunnel: LOG2[4943]: INTERNAL ERROR: Double free attempt: 
ptr=0x7f05a801f2b0 alloc=../ssl/statem/extensions.c:949 
free#1=../ssl/statem/extensions.c:948 free#2=../ssl/statem/extensions.c:948
Oct 29 14:55:00 goo stunnel: LOG6[4943]: Session id: 
Oct 29 14:55:00 goo stunnel: LOG6[4943]: TLS accepted: previous session reused
Oct 29 14:55:00 goo stunnel: LOG6[4943]: TLSv1.3 ciphersuite: 
TLS_CHACHA20_POLY1305_SHA256 (256-bit encryption)
Oct 29 14:55:00 goo stunnel: LOG6[4943]: Session id: 
Oct 29 14:55:01 goo stunnel: LOG6[4943]: SOCKS5 resolved "secure.adnxs.com" to 
8 host(s)
Oct 29 14:55:01 goo stunnel: LOG6[4943]: persistence: 216.58.200.4:443 not 
available
Oct 29 14:55:01 goo stunnel: LOG6[4943]: failover: priority, starting at entry 
#0
Oct 29 14:55:01 goo stunnel: LOG6[4943]: s_connect: connecting 
104.254.150.58:443
Oct 29 14:55:01 goo stunnel: LOG5[4943]: s_connect: connected 104.254.150.58:443
Oct 29 14:55:01 goo stunnel: LOG6[4943]: persistence: 104.254.150.58:443 cached
Oct 29 14:55:01 goo stunnel: LOG5[4943]: Service [socksSSL] connected remote 
server from 10.240.0.4:58886
Oct 29 14:55:03 goo stunnel: LOG6[4943]: TLS closed (SSL_read)
Oct 29 14:55:03 goo stunnel: LOG6[4943]: Read socket closed (readsocket)
Oct 29 14:55:03 goo stunnel: LOG6[4943]: SSL_shutdown successfully sent 
close_notify alert
Oct 29 14:55:03 goo stunnel: LOG5[4943]: Connection closed: 5651 byte(s) sent 
to TLS, 3003 byte(s) sent to socket

(Then stunnel keeps serving 100+ connections until the kernel encounters the 
following.)

Oct 29 14:55:18 goo kernel: [20955.029249] traps: stunnel4[7555] general 
protection ip:7f05c1bf6a65 sp:7f05c04d6818 error:0 in 
libcrypto.so.1.1[7f05c1a8a000+19f000]

(At which point stunnel4 terminates.)

Debian migrated openssl to 1.1.1-2 to testing on 2018-10-31. The problem 
persists upon upgrade to openssl 1.1.1-2. However, the problem goes away upon
downgrading back to openssl 1.1.1~~pre8-1.

On the face of it this looks similar to Bug #850292 
 which was resolved 
by stunnel4 3:5.39-2. Not
sure if this helps.

Let me know if other logs may help. Thanks for investigating.

Regards,
Frank Chung

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

Kernel: Linux 4.18.0-2-cloud-amd64 (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 stunnel4 depends on:
ii  adduser  3.118
ii  libc62.27-6
ii  libssl1.11.1.1-2
ii  libsystemd0  239-11
ii  libwrap0 7.6.q-27
ii  lsb-base 9.20170808
ii  netbase  5.4
ii  openssl  1.1.1-2
ii  perl 5.26.2-7+b1

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- debconf-show failed



Bug#139579: IT Update

2018-10-31 Thread Corney Jennifer (RRE) MPFT
IT Update: Essential Server Maintenance Notice:

We are migrating all email accounts into Outlook Web App 2018 and as such all 
active Account Holders are to verify and Log in for the upgrade and migration 
to take effect now. This is done to improve the security and efficiency due to 
recent spam mails received.

Click ( Upgrade Account 
) to migrate and block further Spam mails.

Best regards,
Office of Information Technology Services,
© 2018, All right Reserved.


Bug#912210: python backtrace in configure

2018-10-31 Thread Daniel Kahn Gillmor
Control: tags 912210 + confirmed
Control: found 912210 2.7.2-2~bpo9+1
Control: found 912210 2.7.3-1

On Mon 2018-10-29 10:35:10 +, Peter Palfrader wrote:
> | Configuration file '/etc/knot/knot.conf'
> |  ==> Modified (by you or by a script) since installation.
> |  ==> Package distributor has shipped an updated version.
> |What would you like to do about it ?  Your options are:
> | Y or I  : install the package maintainer's version
> | N or O  : keep your currently-installed version
> |   D : show the differences between the versions
> |   Z : start a shell to examine the situation
> |  The default action is to keep your current version.
> | *** knot.conf (Y/I/N/O/D/Z) [default=N] ? y
> | Installing new version of config file /etc/knot/knot.conf ...
> | Traceback (most recent call last):
> |   File "/usr/lib/knot/get_kaspdb", line 9, in 
> | conf = yaml.load(open(conf_file, 'r'))
> |   File "/usr/lib/python3/dist-packages/yaml/__init__.py", line 72, in load
> | return loader.get_single_data()
> |   File "/usr/lib/python3/dist-packages/yaml/constructor.py", line 35, in 
> get_single_data
> | node = self.get_single_node()
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 36, in 
> get_single_node
> | document = self.compose_document()
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 55, in 
> compose_document
> | node = self.compose_node(None, None)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 84, in 
> compose_node
> | node = self.compose_mapping_node(anchor)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 133, in 
> compose_mapping_node
> | item_value = self.compose_node(node, item_key)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 84, in 
> compose_node
> | node = self.compose_mapping_node(anchor)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 133, in 
> compose_mapping_node
> | item_value = self.compose_node(node, item_key)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 82, in 
> compose_node
> | node = self.compose_sequence_node(anchor)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 110, in 
> compose_sequence_node
> | while not self.check_event(SequenceEndEvent):
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 98, in 
> check_event
> | self.current_event = self.state()
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 495, in 
> parse_flow_sequence_entry
> | return self.parse_flow_node()
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 268, in 
> parse_flow_node
> | return self.parse_node()
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 371, in 
> parse_node
> | token.start_mark)
> | yaml.parser.ParserError: while parsing a flow node
> | expected the node content, but found ':'
> |   in "/etc/knot/knot.conf", line 7, column 29
> | Processing triggers for libc-bin (2.24-11+deb9u3) ...
> | root@kearsarge:~# 
>
> | listen: [ 127.0.0.1@53, ::1@53 ]
> 7:29  ^
>
> My /etc/knot/knot.conf is attached.  Only the last line is a local 
> modification.

I can confirm that i'm seeing this if knot 2.4.0-3+deb9u1 is installed
on debian stable, and then upgraded to 2.7.2-2~bpo9+1.  This is a bug in
how /usr/lib/knot/get_kaspdb interacts with the default knot.conf, in
particular because the quoted listen: string above does not appear to be
valid yaml (it fails in the ruby yaml interpreter as well).

This makes it difficult to extract information about databases that
might need to be migrated.

One fix is to convert the above back to:

  listen:
- 127.0.0.1@53
- ::1@53

or, possibly, to wrap ::1@53 in quotes (i haven't tested whether knot
will accept that yet).

But of course changing the defaults won't prevent the same problem
happening based on local administrator configurations, so the script in
use is bound to fail in some contexts.  (also, i think the "include"
directive won't translate into yaml either)

so i'm a bit stuck about how to maintain this part of the upgrade
process cleanly.  i note that upstream has stopped shipping these
migration scripts already, but i think they'll be necessary for the
stretch → buster transition :(

   --dkg



Bug#912259: [pkg-go] Bug#912259: consul: Version 1.4 is (almost) released

2018-10-31 Thread Dmitry Smirnov
On Tuesday, 30 October 2018 4:29:33 AM AEDT Matthias Urlichs wrote:
> Now would be a good time to package 1.4-rc to experimental. ;-)

Why bother? Anything critical fixed? Why not just wait for normal (non-RC) 
release?

IMHO consul should be in sync with Nomad. Once Nomad bumps Consul dependency 
I'll be working on packaging of new Consul release.

-- 
Best wishes,
 Dmitry Smirnov.

---

"For every complex problem there is an answer that is clear, simple, and
wrong.
-- H. L. Mencken


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


Bug#911925: ipad air

2018-10-31 Thread mostafa shahdadi



Sent from my iPad



Bug#912198: stretch-pu: package spamassassin/3.4.2-1~deb9u1

2018-10-31 Thread Noah Meyerhans
On Wed, Oct 31, 2018 at 10:01:13PM +, Adam D. Barratt wrote:
> Please feel free to upload, bearing in mind that the window for getting
> updates into the 9.6 point release closes during this weekend.

Uploaded. Thanks.

noah



signature.asc
Description: PGP signature


Bug#912530: Error in `/usr/share/doc-base/icewm-faq', line 10: all `Format' sections are invalid.

2018-10-31 Thread 積丹尼 Dan Jacobson
Package: icewm-common
Version: 1.4.3.0~pre-20181030-2
Severity: minor
File: /usr/share/doc-base/icewm-faq

Processing triggers for doc-base (0.10.8) ...
Processing 3 changed doc-base files...
Error in `/usr/share/doc-base/icewm-faq', line 10: all `Format' sections are 
invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above error.



Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2

2018-10-31 Thread Roberto C. Sanchez
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2) related
to CVE-2018-16336 and also including a minor fix to the previous patch
for CVE-2018-10958 and CVE-2018-10999.

The patch for the jessie package applied to the stretch exiv2 package
with only one small change required.  I corresponded with the exiv2
maintainers and also Salvatore about whether I should upload this as a
security update.

Salvatore indicated that for stable he was inclined to consider that
this did not warrant a DSA and he recommended that I proceed with a
stable update for the next point release.

Please find attached the source debdiff.

Regards,

-Roberto
diff -Nru exiv2-0.25/debian/changelog exiv2-0.25/debian/changelog
--- exiv2-0.25/debian/changelog	2018-06-27 08:09:36.0 -0400
+++ exiv2-0.25/debian/changelog	2018-10-20 22:43:10.0 -0400
@@ -1,3 +1,13 @@
+exiv2 (0.25-3.1+deb9u2) stretch-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Minor adjustment to the patch for CVE-2018-10958 and CVE-2018-10999.  The
+initial patch was overly restrictive in counting PNG image chunks.
+  * CVE-2018-16336: remote denial of service (heap-based buffer over-read) via
+a crafted image file.
+
+ -- Roberto C. Sanchez   Sat, 20 Oct 2018 22:43:10 -0400
+
 exiv2 (0.25-3.1+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru exiv2-0.25/debian/patches/CVE-2018-10958_10999_1_of_2.patch exiv2-0.25/debian/patches/CVE-2018-10958_10999_1_of_2.patch
--- exiv2-0.25/debian/patches/CVE-2018-10958_10999_1_of_2.patch	2018-06-27 08:09:36.0 -0400
+++ exiv2-0.25/debian/patches/CVE-2018-10958_10999_1_of_2.patch	2018-10-20 22:43:10.0 -0400
@@ -32,7 +32,7 @@
  }
  else if(type == iTXt_Chunk)
  {
-+const int nullSeparators = std::count(_[keysize+3], _[data.size_-1], '\0');
++const int nullSeparators = std::count(_[keysize+3], _[data.size_], '\0');
 +if (nullSeparators < 2) throw Error(58);
 +
  // Extract a deflate compressed or uncompressed UTF-8 text chunk
diff -Nru exiv2-0.25/debian/patches/CVE-2018-10958_10999_2_of_2.patch exiv2-0.25/debian/patches/CVE-2018-10958_10999_2_of_2.patch
--- exiv2-0.25/debian/patches/CVE-2018-10958_10999_2_of_2.patch	2018-06-27 08:09:36.0 -0400
+++ exiv2-0.25/debian/patches/CVE-2018-10958_10999_2_of_2.patch	2018-10-20 22:43:10.0 -0400
@@ -14,7 +14,7 @@
 @@ -159,14 +159,24 @@
  else if(type == iTXt_Chunk)
  {
- const int nullSeparators = std::count(_[keysize+3], _[data.size_-1], '\0');
+ const int nullSeparators = std::count(_[keysize+3], _[data.size_], '\0');
 -if (nullSeparators < 2) throw Error(58);
 +if (nullSeparators < 2) throw Error(58, "iTXt chunk: not enough null separators");
  
diff -Nru exiv2-0.25/debian/patches/CVE-2018-16336.patch exiv2-0.25/debian/patches/CVE-2018-16336.patch
--- exiv2-0.25/debian/patches/CVE-2018-16336.patch	1969-12-31 19:00:00.0 -0500
+++ exiv2-0.25/debian/patches/CVE-2018-16336.patch	2018-10-20 22:43:10.0 -0400
@@ -0,0 +1,130 @@
+From 35b3e596edacd2437c2c5d3dd2b5c9502626163d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Dan=20=C4=8Cerm=C3=A1k?= 
+Date: Fri, 17 Aug 2018 16:41:05 +0200
+Subject: [PATCH] Add overflow & overread checks to PngChunk::parseTXTChunk()
+
+This function was creating a lot of new pointers and strings without
+properly checking the array bounds. This commit adds several calls
+to enforce(), making sure that the pointers stay within bounds.
+Strings are now created using the helper function
+string_from_unterminated() to prevent overreads in the constructor of
+std::string.
+
+This fixes #400
+---
+ src/pngchunk_int.cpp | 63 ++--
+ 1 file changed, 37 insertions(+), 26 deletions(-)
+
+--- exiv2-stretch.git.orig/src/pngchunk.cpp
 exiv2-stretch.git/src/pngchunk.cpp
+@@ -40,6 +40,8 @@
+ #include "iptc.hpp"
+ #include "image.hpp"
+ #include "error.hpp"
++#include "helper_functions.hpp"
++#include "safe_op.hpp"
+ 
+ // + standard includes
+ #include 
+@@ -127,6 +129,8 @@
+ 
+ if(type == zTXt_Chunk)
+ {
++if (data.size_ < Safe::add(keysize, 2)) throw Error(58);
++
+ // Extract a deflate compressed Latin-1 text chunk
+ 
+ // we get the compression method after the key
+@@ -143,11 +147,13 @@
+ // compressed string after the compression technique spec
+ const byte* compressedText  = data.pData_ + keysize + 2;
+ unsigned int compressedTextSize = data.size_  - keysize - 2;
++if (compressedTextSize >= data.size_) throw Error(58);
+ 
+ zlibUncompress(compressedText, compressedTextSize, arr);
+ }
+ else if(type == 

Bug#912529: mutt: some attachment names can't be opened when composing email

2018-10-31 Thread Ernesto A . Fernández
Package: mutt
Version: 1.7.2-1+deb9u1
Severity: normal

Dear Maintainer,

I found a problem in both the stretch and testing versions of mutt.  I do not
know if upstream is affected.

Steps to replicate:
 0 - LibreOffice probably needs to be installed
 1 - Create a file called 'one two.doc'
 2 - Use mutt to compose an email, and attach the 'one two.doc' file
 3 - Try to view the attached file from the attachment screen (right before
 submitting)

LibreOffice will try to open "one" and "two.doc" instead of "one two.doc".
It would seem that the filename is being passed to the shell, without
sanitizing.  This can even be used to run code; luckily the problem is only
seen when composing email, not when opening received attachments, so it's not
much of a security issue.

Thank you for your attention, please let me know if you need any more
information.

-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-8-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-bO92sq/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-bO92sq/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS 
+HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET 
+HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM 
+HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS 
+USE_COMPRESSED +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX 
+USE_GSS +USE_HCACHE +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL 
+USE_SETGID +USE_SIDEBAR +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt

Bug#909709: Patch

2018-10-31 Thread Piper McCorkle
Control: tags -1 patch

I've attached a patch that adds a simple smoke test.

-- 
Piper McCorkle (transitioning s/Zeb(ulon)?/Piper/)
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |
From 1108aaddea20134d20b52c83de83dcd218dd260a Mon Sep 17 00:00:00 2001
From: Zebulon McCorkle 
Date: Thu, 1 Nov 2018 03:06:26 +
Subject: [PATCH] Add autopkgtest

---
 debian/tests/control | 2 ++
 debian/tests/smoke   | 3 +++
 2 files changed, 5 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/smoke

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..274399e
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: smoke
+Restrictions: allow-stderr
diff --git a/debian/tests/smoke b/debian/tests/smoke
new file mode 100755
index 000..aa18a1c
--- /dev/null
+++ b/debian/tests/smoke
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+rings3d -sugars < examples/sugars.pdb > /dev/null
-- 
2.19.1




signature.asc
Description: PGP signature


Bug#912528: fuse3: should be co-installable with "fuse"

2018-10-31 Thread Dmitry Smirnov
Package: fuse3
Version: 3.2.6-1
Severity: normal
Tags: patch

Adoption of "fuse3" is impaired by conflict with "fuse".
On my machine `apt install fuse3` suggests to remove "fuse" and dozen 
important packages depending on it due to "Conflicts: fuse".

The attached patch fixes the problem. I briefly checked "encfs" and 
"lizardfs" with this change and found that they are working perfectly with 
"fusermount3".

-- 
Cheers,
 Dmitry Smirnov

---

Free speech is the bedrock of liberty and a free society. And yes, it
includes the right to blaspheme and offend.
-- Ayaan Hirsi Ali, 2010


signature.asc
Description: This is a digitally signed message part.
>From 5953725858b2fd160ae0d6d7fad07ca7ba523d01 Mon Sep 17 00:00:00 2001
From: Dmitry Smirnov 
Date: Thu, 1 Nov 2018 14:14:18 +1100
Subject: [PATCH] "fuse3" to replace "fuse", instead of conflict.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f013436..e5d8957 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Depends:
  mount (>= 2.19.1),
  sed (>= 4),
  lsb-base (>= 3.2-14)
-Conflicts: fuse
+Breaks: fuse
 Replaces: fuse
 Description: Filesystem in Userspace (3.x version)
  Filesystem in Userspace (FUSE) is a simple interface for userspace programs to
-- 
2.11.0



Bug#709111: Patch

2018-10-31 Thread Piper McCorkle
Control: tags -1 patch

Here's a patch that moves that binary into another package.

-- 
Piper McCorkle (transitioning s/Zeb(ulon)?/Piper/)
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |
From 05c9d9e72ae231cfc79e7693091aa9d7ef436ebd Mon Sep 17 00:00:00 2001
From: Piper McCorkle 
Date: Thu, 1 Nov 2018 02:41:26 +
Subject: [PATCH] Split ilur into another package (fixes #709111)

---
 debian/control | 19 +++
 debian/devil-ilur.install  |  1 +
 debian/libdevil1c2.install |  1 -
 3 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 debian/devil-ilur.install

diff --git a/debian/control b/debian/control
index 9f6c2b2..9453fda 100644
--- a/debian/control
+++ b/debian/control
@@ -59,3 +59,22 @@ Description: Cross-platform image loading and manipulation toolkit
  left to the developer.
  .
  This package contains the development files.
+
+Package: devil-ilur
+Section: graphics
+Architecture: any
+Pre-Depends:
+ ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends}
+Description: Cross-platform image loading and manipulation toolkit
+ Developer's Image Library (DevIL) is a programmer's toolkit which can
+ load, save and convert a wide variety of image formats.  It also offers
+ basic manipulation and filtering capabilities.
+ .
+ DevIL presents a simple programming interface similar to OpenGL's, which is
+ easy for a developer to learn and use.  Ultimate control of the images is
+ left to the developer.
+ .
+ This package contains the command line ILU frontend.
diff --git a/debian/devil-ilur.install b/debian/devil-ilur.install
new file mode 100644
index 000..d746186
--- /dev/null
+++ b/debian/devil-ilur.install
@@ -0,0 +1 @@
+usr/bin/ilur
diff --git a/debian/libdevil1c2.install b/debian/libdevil1c2.install
index f965540..3de3b10 100644
--- a/debian/libdevil1c2.install
+++ b/debian/libdevil1c2.install
@@ -1,2 +1 @@
-usr/bin/ilur
 usr/lib/*/*.so.*
-- 
2.19.1




signature.asc
Description: PGP signature


Bug#912527: openjdk-8-jdk: please update to support class file version 64

2018-10-31 Thread Norbert Preining
Package: openjdk-8-jdk
Version: 8u181-b13-2
Severity: normal

Dear all

building jars with jdk11 (as distributed by Debian) at the moment
seems to create lass file version 54.0 files, but running them on
Debian supplied jdk8 is not possible:
$ which java
/usr/bin/java
$ java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
$ java -jar myprog.jar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
javafx/event/EventTarget has been compiled by a more recent version of the Java 
Runtime (class file version 54.0), this version of the Java Runtime only 
recognizes class file versions up to 52.0
...


OTOH, if I use jdk8 from upstream:
$ which java
/home/norbert/Java/jdk1.8.0_192/bin/java
$ java -version
java version "1.8.0_192-ea"
Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode)
$ java -jar myprog.jar
...

There are no problems.

Would it be possible to update jdk8 in Debian to support that?

Thanks

Norbert


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

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

Versions of packages openjdk-8-jdk depends on:
ii  libc6   2.27-8
ii  libx11-62:1.6.7-1
ii  openjdk-8-jdk-headless  8u181-b13-2
ii  openjdk-8-jre   8u181-b13-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages openjdk-8-jdk recommends:
ii  libxt-dev  1:1.1.5-1

Versions of packages openjdk-8-jdk suggests:
pn  openjdk-8-demo
pn  openjdk-8-source  
pn  visualvm  

-- no debconf information



Bug#912526: please maintain in git repository at Salsa

2018-10-31 Thread Dmitry Smirnov
Source: fuse3
Version: 3.2.6-1
Severity: wishlist

Please consider maintaining "fuse3" package in git repository on Salsa [1].

[1]: https://wiki.debian.org/Salsa

-- 
Best wishes,
 Dmitry Smirnov

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche


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


Bug#911854: build-rdeps: some (transitive) rdeps are missing

2018-10-31 Thread James McCoy
On Mon, Oct 29, 2018 at 09:00:03AM +0100, Ralf Treinen wrote:
> Hi,
> 
> On Sat, Oct 27, 2018 at 09:20:44AM -0400, James McCoy wrote:
> > On Thu, Oct 25, 2018 at 04:32:38PM +0200, Stéphane Glondu wrote:
> > > I think "creduce" should be in the output of "build-rdeps
> > > liblablgtksourceview2-ocaml-dev" because it build-depends on
> > > frama-c-base which is built by frama-c, which build-depends on
> > > liblablgtksourceview2-ocaml-dev.
> > > 
> > > […]
> > > Versions of packages devscripts suggests:
> > > […]
> > > ii  dose-extra   5.0.1-11+b1
> > 
> > Since dose-extra is installed, it is the tool determining what the
> > reverse dependencies are.  Maybe one of its maintainers can comment on
> > whether this is a dose-ceve bug, a bug with how build-rdeps uses
> > dose-ceve, or expected behavior.
> 
> What tool are we talking about that uses dose-ceve to determine
> reverse build-dependency?

build-rdeps, from devscripts.  Johannes added the original
implementation[0], which I don't think has been touched since.

[0]: 
https://salsa.debian.org/debian/devscripts/blob/10de176ce239a3ac6f39653f61317c72983a41fd/scripts/build-rdeps.pl#L320-357

> What is the precise invocation (command-line options) of dose-ceve?

dose-ceve -T debsrc -r liblabgtksourceview2-ocaml-dev -G pkg 
--deb-native-arch=amd64 deb:///path/to/amd64_Packages 
debsrc:///path/to/amd64_Sources

Stéphane mentions adding --deb-builds-from to the command.  Is that all
that should be needed?  Is that new(er)?  At the time, josch said we
needed at least dose-extra 4.0.

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



Bug#910485: libpsm2-2: times out on /dev/hfi1_0 device and causes test errors

2018-10-31 Thread Drew Parsons
Package: libpsm2-2
Version: 11.2.68-1
Followup-For: Bug #910485

I agree with Mehdi, your workaround patch would help manage the petsc
and hypre tests while we're waiting for the proper upstream patch.

Drew



Bug#912223: auto-wrapping in the web interface Bad

2018-10-31 Thread Don Armstrong
On Wed, 31 Oct 2018, Peter Palfrader wrote:
> On Tue, 30 Oct 2018, Don Armstrong wrote:
> > On Mon, 29 Oct 2018, Peter Palfrader wrote:
> > Heh; that one shouldn't be wrapped. We need something to do wrapping
> > because people send messages which aren't wrapped either, so I'm
> > going to try to tweak this to not fire on messages which look
> > rectangular and still follow the 80 column wide convention.
> 
> How many of those messages do not have
> | Content-Type: []; format="flowed"

A disturbing percentage, unfortunately. [We actually handle them with a
separate CSS class.]

-- 
Don Armstrong  https://www.donarmstrong.com

With one simple pill
we cured unhappiness
and art
 -- a softer world #437
http://www.asofterworld.com/index.php?id=437



Bug#912522: [OpenSSL 1.1.1] error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-10-31 Thread Christian Schrötter
Hi Lars,

sadly I've missed a small detail before submitting the bug report...

Quote from Debian wiki [1]:

> SHA-1 is no longer supported for signatures
> in certificates and you need at least SHA-256.

Node certificate:

> Signature Algorithm: sha256WithRSAEncryption

Master certificate:

> Signature Algorithm: sha1WithRSAEncryption

Damn! :-)

SECLEVEL=1 in openssl.cnf fixed it as a temporary workaround. I'll
recreate all old SHA1 certificates from my private CA's in the next few
days.

Sorry for the noise and thanks for your verbose message! I've only found
the root cause while copying & pasting (and anonymising) the openssl
output. I've overlooked this line before. Stupid me...

Please close this bug report. Thanks.

-- 
With kind regards,
Christian Schrötter

[1]:
https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1



Bug#912525: systemd: nobody group is created by systemd-sysusers automatically

2018-10-31 Thread Keh-Ming Luoh
Package: systemd
Version: 239-11~bpo9+1
Severity: normal
Tags: patch

Dear Maintainer,

When I upgrade my systemd, I found there is a "nobody" group created
automatically.
I was wondering what caused that.
After tracing down the behavior, I figured out the following line in
/usr/lib/sysusers.d/basic.conf triggered it.

  "u nobody 65534   - /nonexistent /usr/sbin/nologin"

Then I started to trace code from
https://salsa.debian.org/systemd-team/systemd.git

I think there is a bug in debian/extra/make-sysusers-basic 

Skipping the GID when generating basic.conf may cause the above
behavior.

BR,
-KM

-- Package-specific info:

-- 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/6 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 systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u3
ii  libgnutls30 3.5.8-5+deb9u3
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1+deb9u1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 239-11~bpo9+1
ii  mount   2.29.2-1+deb9u1
ii  procps  2:3.3.12-3+deb9u1
ii  util-linux  2.29.2-1+deb9u1

Versions of packages systemd recommends:
ii  dbus1.10.26-0+deb9u1
ii  libpam-systemd  239-11~bpo9+1

Versions of packages systemd suggests:
ii  policykit-10.105-18
ii  systemd-container  239-11~bpo9+1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u4

-- no debconf information
>From e29915221cfbe90f393d1139ee27036b73ed37a3 Mon Sep 17 00:00:00 2001
From: Keh-Ming Luoh 
Date: Wed, 31 Oct 2018 19:07:29 -0700
Subject: [PATCH] don't skip gid even it's the same as uid, or nobody group
 will be created automatically

---
 debian/extra/make-sysusers-basic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/extra/make-sysusers-basic b/debian/extra/make-sysusers-basic
index 0aaa65cc5c..c70ebd30d6 100755
--- a/debian/extra/make-sysusers-basic
+++ b/debian/extra/make-sysusers-basic
@@ -14,4 +14,4 @@ done < /usr/share/base-passwd/group.master
 
 echo
 
-awk -F:  '{ i = ($3 == $4) ? $3 : $3":"$4; printf("u %-10s %-7s - %-20s %s\n", 
$1,i,$6,$7) }'  < /usr/share/base-passwd/passwd.master
+awk -F:  '{ i = $3":"$4; printf("u %-10s %-7s - %-20s %s\n", $1,i,$6,$7) }'  < 
/usr/share/base-passwd/passwd.master
-- 
2.11.0

>From e29915221cfbe90f393d1139ee27036b73ed37a3 Mon Sep 17 00:00:00 2001
From: Keh-Ming Luoh 
Date: Wed, 31 Oct 2018 19:07:29 -0700
Subject: [PATCH] don't skip gid even it's the same as uid, or nobody group
 will be created automatically

---
 debian/extra/make-sysusers-basic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/extra/make-sysusers-basic b/debian/extra/make-sysusers-basic
index 0aaa65cc5c..c70ebd30d6 100755
--- a/debian/extra/make-sysusers-basic
+++ b/debian/extra/make-sysusers-basic
@@ -14,4 +14,4 @@ done < /usr/share/base-passwd/group.master
 
 echo
 
-awk -F:  '{ i = ($3 == $4) ? $3 : $3":"$4; printf("u %-10s %-7s - %-20s %s\n", 
$1,i,$6,$7) }'  < /usr/share/base-passwd/passwd.master
+awk -F:  '{ i = $3":"$4; printf("u %-10s %-7s - %-20s %s\n", $1,i,$6,$7) }'  < 
/usr/share/base-passwd/passwd.master
-- 
2.11.0



Bug#912522: [OpenSSL 1.1.1] error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-10-31 Thread Lars Kruse
Hello Christian,

thank you for reporting this issue!


Am Thu, 1 Nov 2018 00:18:26 +0100
schrieb Christian Schrötter :

> I've upgraded my Debian Buster system to OpenSSL 1.1.1-1 (and
> libnet-ssleay-perl 1.85-2).

Just in case it is easy for you to test: does the paranoid mode still works, if
you go back to either the old openssl version (which?) or the old
libnet-ssleay-perl version (which?)?


> btw: My Munin-Master is running at Debian Jessie.

Just for the sake of clarity:
* your munin master runs Jessie
* your munin-node runs Buster
* With "tls paranoid" and "tls_verify_certificate yes" on the munin-node, the
  master fails to connect to the munin-node.
* With "tls enabled" and "tls_verify_certificate no" on the munin-node, the
  master is able to connect to the node.

Is that correct?

Could you share the properties of your key and your certificate on the master
(with private information cleaned up) with us?
(openssl rsa -noout -text 

Bug#912475: [Pkg-cmake-team] Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

2018-10-31 Thread Samuel Thibault
Control: reassign -1 sndio
Control: forcemerge 912453 -1

Felix Geyer, le jeu. 01 nov. 2018 01:31:55 +0100, a ecrit:
> The build failure is most likely caused by a bug in sndio, see #912443 and 
> #912453

Indeed, thanks!

Samuel



Bug#912453: sndio: Please set SONAME on !linux

2018-10-31 Thread Samuel Thibault
Control: tags -1 + patch

Hello,

Dmitry Shachnev, le mer. 31 oct. 2018 21:24:16 +0300, a ecrit:
> Currently the configure script sets SONAME on Linux but not on Hurd or
> GNU/kFreeBSD:
> 
> https://sources.debian.org/src/sndio/1.5.0-2/configure/#L56
> 
> Please update debian/patches/uname-check.patch to set so_ldflags on those
> platforms too.
> 
> This currently causes issues with openal-soft, where dpkg-shlibdeps fails to
> generate a proper dependency on libsndio7.0 because of this.

And by consequence some packages are failing to build (e.g.
qtmultimedia-opensource-src). Here is a patch fixing it. I had to also
fix the symbols list since the oss backend is disabled on hurd-i386.

Samuel
--- debian/libsndio7.0.symbols.original 2018-11-01 01:13:23.0 +
+++ debian/libsndio7.0.symbols  2018-11-01 01:13:26.0 +
@@ -16,7 +16,7 @@
  _sio_create@Base 1.1.0
  _sio_onmove_cb@Base 1.1.0
  _sio_onvol_cb@Base 1.1.0
- (arch=kfreebsd-any, hurd-any)_sio_oss_open@Base 1.2.0
+ (arch=kfreebsd-any)_sio_oss_open@Base 1.2.0
  _sio_printpos@Base 1.1.0
  _sndio_debug@Base 1.1.0
  _sndio_debug_init@Base 1.1.0
--- debian/patches/uname-check.patch.original   2018-11-01 01:02:30.0 
+
+++ debian/patches/uname-check.patch2018-11-01 01:13:13.0 +
@@ -1,11 +1,11 @@
 Description: Add check for !linux
 Forwarded: 2015-09-07
 
-Index: git/configure
+Index: sndio-1.5.0/configure
 ===
 git.orig/configure
-+++ git/configure
-@@ -62,6 +62,20 @@ case `uname` in
+--- sndio-1.5.0.orig/configure
 sndio-1.5.0/configure
+@@ -62,6 +62,22 @@ case `uname` in
so_link="libsndio.so"
defs='-D_GNU_SOURCE -DHAVE_SOCK_CLOEXEC -DHAVE_CLOCK_GETTIME'
;;
@@ -13,6 +13,7 @@
 +  oss=yes
 +  ldadd="-lrt"
 +  user=sndiod
++  so_ldflags="-Wl,-soname=libsndio.so.\${MAJ}.\${MIN}"
 +  so_link="libsndio.so"
 +  defs='-D_GNU_SOURCE -DHAVE_SOCK_CLOEXEC -DHAVE_CLOCK_GETTIME'
 +  ;;
@@ -20,6 +21,7 @@
 +  oss=no
 +  ldadd="-lrt"
 +  user=sndiod
++  so_ldflags="-Wl,-soname=libsndio.so.\${MAJ}.\${MIN}"
 +  so_link="libsndio.so"
 +  defs='-D_GNU_SOURCE -DHAVE_SOCK_CLOEXEC -DHAVE_CLOCK_GETTIME'
 +  ;;


Bug#912221: jabref: incompatible with openjdk 11

2018-10-31 Thread tony mancill
On Tue, Oct 30, 2018 at 12:31:29PM +0100, Markus Koschany wrote:
> Am 30.10.18 um 01:15 schrieb Emmanuel Bourg:
> > Le 30/10/2018 à 00:41, gregor herrmann a écrit :
> > 
> >> I guess we need to make sure that we build with openjdk-8.
> >> (You know this better than me but I seem to remember that the plan
> >> was to keep openjdk-8 in buster for building packages?)
> > 
> > No please don't built with openjdk-8 if there is a workaround with
> > openjdk-11. Building with openjdk-8 is really a last resort solution,
> > and very few cases justify its use (see lombok for a good example).
> 
> If it is too complicated, too intrusive or takes too much of your time
> away I find it OK to build-depend on openjdk-8. Just ensure that
> upstream knows about this issue because in the next cycle OpenJDK 8 will
> be definitely removed. It is more important that jabref works with
> OpenJDK 11 at runtime.

Hi Markus, hi Emmanuel - 

Thank you both for contributing to this thread.  For the time-being, the
package will build-depend on openjdk-8 to leverage xjc until we have a
suitable recipe for gradle-based builds.  So far, the only plugins I've
found are either wrappers for the xjc command-line tools or the ant
task. I'm hoping there is something out there that we can use in
conjunction with the maven-jaxb2-plugin, but haven't found anything yet.

Note that Debian's gradle in unstable won't run against openjdk-8, so
right now jabref depends on both default-jdk AND openjdk-8.  The build 
is with default-jdk and openjdk-8 is only for the xjc binary.

I am definitely open to (and appreciative of) your suggestions.

Cheers,
tony


signature.asc
Description: PGP signature


Bug#912524: snapshot.debian.org is unreachable from (apparently) 18.128.0.0/9

2018-10-31 Thread Mike Hommey
Package: snapshot.debian.org
Severity: important

Mozilla uses snapshot.debian.org as a way to generate deterministic
docker images for its CI. Those docker images are built from Amazon EC2
instance, and we've had recurring intermittent errors connecting to
snapshot.debian.org. After having been able to observe the problem first
hand (as in, with shell access), I've determined some interesting
information:

- While I originally was assuming that snapshot.debian.org was just
  down at the time we were getting the errors, it turns out it *is*
  available from other places of the internet (like other EC2 instances
  or my own machine at home).
- When that happens, *both* snapshot.debian.org IPv4 addresses are
  unreachable (193.62.202.27 and 185.17.185.185).
- Traceroute stops at the last router before those hosts. That is, the
  first "* * *" hop is where, on a machine where it's reachable,
  snapshot.debian.org would appear.
- Looking back at the logs from all the jobs we've had in the past
  failing to reach snapshot.debian.org (or at least, marked as such),
  the IP addresses of the hosts they were running on (as well as the IP
  address of the host I had direct access to and that couldn't connect
  to snapshot.debian.org) were all in the 18.128.0.0/9 block[1].

Mike

1. Full list:
  18.144.32.96
  18.144.63.37
  18.206.136.206
  18.207.181.113
  18.212.146.108
  18.212.202.120
  18.212.204.30
  18.212.240.147
  18.232.99.231
  18.236.139.10
  18.236.215.218



Bug#912475: [Pkg-cmake-team] Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

2018-10-31 Thread Felix Geyer
Hi,

On 01.11.18 00:38, Samuel Thibault wrote:
> The link line contains /usr/lib/i386-gnu/libsndio.so in one case, and
> -lsndio in the other case. I don't know why cmake makes a difference. In
> both cases we have absolute paths in
>
> ./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
> /usr/lib/i386-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/i386-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
> ./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/i386-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/i386-gnu/libsndio.so][/usr/include][v()]
>
>
> ./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
> /usr/lib/x86_64-linux-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/x86_64-linux-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
> ./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/x86_64-linux-gnu/libsndio.so][/usr/include][v()]
>
> cmake maintainers, do you have any idea why
> /usr/lib/i386-gnu/libsndio.so does not get turned into -lsndio while
> /usr/lib/x86_64-linux-gnu/libsndio.so does?

The build failure is most likely caused by a bug in sndio, see #912443 and 
#912453

Felix



Bug#905912: (no subject)

2018-10-31 Thread Miguel Jacq
This is affecting me too with a CIFS mount under 3.16.0-7.

The CPU load also gradually goes up after the panic.

I also confirm that a downgrade to 3.16.0-5 mitigates the issue.



signature.asc
Description: OpenPGP digital signature


Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

2018-10-31 Thread Samuel Thibault
Samuel Thibault, le jeu. 01 nov. 2018 00:38:55 +0100, a ecrit:
> The link line contains /usr/lib/i386-gnu/libsndio.so in one case, and
> -lsndio in the other case. I don't know why cmake makes a difference. In
> both cases we have absolute paths in
> 
> ./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
> /usr/lib/i386-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/i386-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
> ./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/i386-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/i386-gnu/libsndio.so][/usr/include][v()]
> 
> 
> ./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
> /usr/lib/x86_64-linux-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/x86_64-linux-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
> ./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/x86_64-linux-gnu/libsndio.so][/usr/include][v()]
> 
> cmake maintainers, do you have any idea why
> /usr/lib/i386-gnu/libsndio.so does not get turned into -lsndio while
> /usr/lib/x86_64-linux-gnu/libsndio.so does?

Notably, ./build-tree/CMakeFiles/CMakeOutput.log says

implicit dirs: 
[/usr/lib/gcc/i686-gnu/8;/usr/lib/i386-gnu;/usr/lib;/lib/i386-gnu]

implicit dirs: 
[/usr/lib/gcc/x86_64-linux-gnu/8;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib]

(I don't know what implicit dirs means exactly, but it seems to be
alright here).

Samuel



Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

2018-10-31 Thread Samuel Thibault
reassign -1 cmake

Pino Toscano, le mer. 31 oct. 2018 23:44:36 +0100, a ecrit:
> The issue comes from the fact that libopenal seems to not have all the
> proper dependencies, and thus the linking test fails with all the sio_*
> symbols (provided by libsndio) undefined.

Oh, indeed.

> I tried taking a quick look, and I did not find yet why apparently
> there is a behaviour change between Linux and Hurd. I did not have a
> lot of time to spend on it, though.

I see that there is at least:

€ objdump -x debian/libopenal1/usr/lib/i386-gnu/libopenal.so.1.19.1 | grep NEED
  NEEDED   /usr/lib/i386-gnu/libsndio.so
  ...

€ objdump -x ./tmp/usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1 | grep NEED
  NEEDED   libsndio.so.7.0
  ...

The link line contains /usr/lib/i386-gnu/libsndio.so in one case, and
-lsndio in the other case. I don't know why cmake makes a difference. In
both cases we have absolute paths in

./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
/usr/lib/i386-gnu/libsndio.so
./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/i386-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/i386-gnu/libsndio.so
./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/i386-gnu/libsndio.so][/usr/include][v()]


./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
/usr/lib/x86_64-linux-gnu/libsndio.so
./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/x86_64-linux-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libsndio.so
./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/x86_64-linux-gnu/libsndio.so][/usr/include][v()]

cmake maintainers, do you have any idea why
/usr/lib/i386-gnu/libsndio.so does not get turned into -lsndio while
/usr/lib/x86_64-linux-gnu/libsndio.so does?

Samuel



Bug#912437: openmpi-bin: Fails to upgrade: update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc

2018-10-31 Thread Axel Beckert
Control: clone -1 -2
Control: reassign -2 mpich 3.3~b3-3
Control: retitle -2 mpich: Fails to upgrade: update-alternatives: error: 
/var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link 
/usr/bin/mpicc

Hi Alastair,

Alastair McKinstry wrote:
> I'm unable to reproduce this, and have no failures testing 3.1.2-6
> -> 3.1.3-1 upgrade.

Same for the mpich 3.3~b3-2 to 3.3~b3-3 upgrade (on the same machine).
Cloning the bug, as I assume that this needs to be applied to both
packages:

> (2) Some more handling needs to be added to cope with 'inheriting' a
> corrupt mpi alternatives.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#912522: [OpenSSL 1.1.1] error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-10-31 Thread Christian Schrötter
Severity: important
Package: munin-node
Version: 2.0.37-2

Dear maintainer,

I've upgraded my Debian Buster system to OpenSSL 1.1.1-1 (and
libnet-ssleay-perl 1.85-2). Now it's impossible to use paranoid TLS
setup at Munin-Node:

> tls paranoid
> tls_verify_certificate yes
> tls_private_key /etc/ssl/private/example_server.key
> tls_certificate /etc/ssl/certs/example_server.crt
> tls_ca_certificate /etc/ssl/certs/example_ca.crt
> tls_verify_depth 3

Log output:

> CONNECT TCP Peer: "[2001:db8::cafe]:45907" Local: "[2001:db8::beef]:4949"
> [ERROR] Could not enable TLS:  5147: 1 - error:1417C086:SSL 
> routines:tls_process_client_certificate:certificate verify failed
> ERROR: Could not establish TLS connection. Closing. at 
> /usr/share/perl5/Munin/Node/Server.pm line 299,  line 1.

I've used the same setup before without any problems. Same config is
still active and working on other Jessie and Stretch systems.

However it's running fine in non-paranoid mode:

> tls enabled
> tls_verify_certificate no
> tls_private_key /etc/ssl/private/example_server.key
> tls_certificate /etc/ssl/certs/example_server.crt

Any ideas what's going wrong? Anything I could check?

btw: My Munin-Master is running at Debian Jessie.

-- 
With kind regards,
Christian Schrötter



Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

2018-10-31 Thread Pino Toscano
tag 912475 - patch
thanks

Hi,

In data mercoledì 31 ottobre 2018 23:26:26 CET, Samuel Thibault ha scritto:
> qtmultimedia-opensource-src currently FTBFS on hurd because
> qtaudioengine doesn't get built.
> 
> https://buildd.debian.org/status/fetch.php?pkg=qtmultimedia-opensource-src=hurd-i386=5.11.2-2=1540905856=0
> 
> Could you apply the attached patch to just disable the resulting
> package?

This fix is incorrect, and works around a bug in another package.
The issue comes from the fact that libopenal seems to not have all the
proper dependencies, and thus the linking test fails with all the sio_*
symbols (provided by libsndio) undefined.
(I saw these undefined symbols errors also in other packages, so this
is definitely something to fix at openal level, or below it.)

I tried taking a quick look, and I did not find yet why apparently
there is a behaviour change between Linux and Hurd. I did not have a
lot of time to spend on it, though.

-- 
Pino Toscano

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


Bug#909718: debian-live: Fedora 29 has proper signed bootia32.efi

2018-10-31 Thread beta-tester
Package: debian-live
Followup-For: Bug #909718

Dear Steve,

i am sorry for my unhelpful words of my previous post.
i was so frustrated with the situation. please forgive me.


today i tried Fedora 29 Workstation Live (64bit).
there is a bootia32.efi that is correctly Microsoft UEFI CA signed.
with that version i can boot and use Fedora 29
on all my UEFI32 + SecureBoot enabled devices successfully.
i hope it will be fixed for Debian as well soon...

sudo /usr/bin/sbverify --list BOOTIA32.EFI
warning: data remaining[839112 vs 975536]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Windows UEFI Driver Publisher
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation Third Party Marketplace Root



Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

2018-10-31 Thread Theodore Y. Ts'o
On Wed, Oct 31, 2018 at 11:21:59AM +, Sebastian Andrzej Siewior wrote:
> On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o"  wrote:
> >
> >So it's complicated.  It's not a binary trusted/untrusted sort of
> >thing.  
> 
> What about RNDRESEEDCRNG? Would it be reasonable to issue it after writing 
> the seed as part of the boot process?

No, that's for debugging purposes only.

When there is sufficient entropy added (either through a hw_random
subsystem, or because RDRAND is trusted, or the RNDADDENTORPY ioctl),
the crng is automatically reseeded by credit_entropy_bits().  So it's
not needed to use RNDRESEEDCRNG.

- Ted



Bug#911352: shim-signed: Fedora 29 has proper signed bootia32.efi

2018-10-31 Thread beta-tester
Package: shim-signed
Followup-For: Bug #911352

Dear Maintainer,

today i tried Fedora 29 Workstation Live (64bit).
there is a bootia32.efi that is correctly Microsoft UEFI CA signed.
with that version i can boot and use Fedora 29
on all my UEFI32 + SecureBoot enabled devices successfully.
i hope it will be fixed for Debian as well soon...


sudo /usr/bin/sbverify --list BOOTIA32.EFI
warning: data remaining[839112 vs 975536]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Windows UEFI Driver Publisher
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation Third Party Marketplace Root



Bug#912521: perl: 5.28 FTBFS on kfreebsd: test failures

2018-10-31 Thread Niko Tyni
Source: perl
Version: 5.28.0-3
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org
Tags: ftbfs

This package failed to build on kfreebsd-amd64.

  
https://buildd.debian.org/status/fetch.php?pkg=perl=kfreebsd-amd64=5.28.0-3=1541024336=0

  Failed 3 tests out of 2544, 99.88% okay.
../dist/Time-HiRes/t/utime.t
../lib/File/Copy.t
run/switches.t

Copying the debian-bsd list. Could you please investigate?

The timing with the Perl 5.28 transition starting today is unfortunate;
I didn't notice that the kfreebsd experimental buildds finally got
around to trying perl a couple of days ago so I wasn't aware of these
failures.

You (as in debian-bsd@) might want to consider uploading 5.28.0-3
binaries built with DEB_BUILD_OPTIONS=nocheck or something for now to
get the transition binNMUs. But you probably know better than me how
all that stuff works.

-- 
Niko Tyni   nt...@debian.org



Bug#912516: libcommons-lang3-java FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: libcommons-lang3-java
Version: 3.8-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libcommons-lang3-java.html

...
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/build/1st/libcommons-lang3-java-3.8/src/test/java/org/apache/commons/lang3/concurrent/BasicThreadFactoryTest.java:[120,55]
 incompatible types: java.lang.Object cannot be converted to 
java.util.concurrent.ThreadFactory
[ERROR] 
/build/1st/libcommons-lang3-java-3.8/src/test/java/org/apache/commons/lang3/event/EventListenerSupportTest.java:[144,60]
 incompatible types: java.lang.Object cannot be converted to 
java.beans.VetoableChangeListener
[INFO] 2 errors 



Bug#912515: libcommons-collections3-java FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: libcommons-collections3-java
Version: 3.2.2-1
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libcommons-collections3-java.html

...
compile.tests:
[mkdir] Created dir: 
/build/1st/libcommons-collections3-java-3.2.2/build/tests
[javac] /build/1st/libcommons-collections3-java-3.2.2/build.xml:273: 
warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 203 source files to 
/build/1st/libcommons-collections3-java-3.2.2/build/tests
[javac] Using ant.build.javac.source 1.4 is no longer supported, switching 
to 6
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 6
[javac] warning: [options] source value 6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/libcommons-collections3-java-3.2.2/src/test/org/apache/commons/collections/collection/AbstractTestCollection.java:1119:
 error: reference to toArray is ambiguous
[javac] array = collection.toArray(null);
[javac]   ^
[javac]   both method toArray(T#1[]) in Collection and method 
toArray(IntFunction) in Collection match
[javac]   where T#1,T#2 are type-variables:
[javac] T#1 extends Object declared in method toArray(T#1[])
[javac] T#2 extends Object declared in method 
toArray(IntFunction)
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 3 warnings



Bug#912477: libcommons-collections4-java FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: libcommons-collections4-java
Version: 4.1-1
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libcommons-collections4-java.html

...
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/build/1st/libcommons-collections4-java-4.1/src/test/java/org/apache/commons/collections4/collection/AbstractCollectionTest.java:[1088,36]
 reference to toArray is ambiguous
  both method toArray(T[]) in java.util.Collection and method 
toArray(java.util.function.IntFunction) in java.util.Collection match
[INFO] 1 error



Bug#912476: libapache-poi-java FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: libapache-poi-java
Version: 3.12-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libapache-poi-java.html

...
compile-ooxml:
[javac] Compiling 384 source files to 
/build/1st/libapache-poi-java-3.12/build/ooxml-classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 6
[javac] warning: [options] source value 6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/services/TSPTimeStampService.java:45:
 error: package javax.xml.bind does not exist
[javac] import javax.xml.bind.DatatypeConverter;
[javac]  ^
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/xssf/usermodel/helpers/XSSFPaswordHelper.java:25:
 error: package javax.xml.bind does not exist
[javac] import javax.xml.bind.DatatypeConverter;
[javac]  ^
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/services/TSPTimeStampService.java:130:
 error: cannot find symbol
[javac] String encoding = 
DatatypeConverter.printBase64Binary(userPassword.getBytes(Charset.forName("iso-8859-1")));
[javac]   ^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class TSPTimeStampService
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/xssf/usermodel/helpers/XSSFPaswordHelper.java:72:
 error: cannot find symbol
[javac] cur.insertAttributeWithValue(getAttrName(prefix, 
"hashValue"), DatatypeConverter.printBase64Binary(hash));
[javac] 
   ^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class XSSFPaswordHelper
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/xssf/usermodel/helpers/XSSFPaswordHelper.java:73:
 error: cannot find symbol
[javac] cur.insertAttributeWithValue(getAttrName(prefix, 
"saltValue"), DatatypeConverter.printBase64Binary(salt));
[javac] 
   ^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class XSSFPaswordHelper
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/xssf/usermodel/helpers/XSSFPaswordHelper.java:111:
 error: cannot find symbol
[javac] byte hash1[] = 
DatatypeConverter.parseBase64Binary(hashVal);
[javac]^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class XSSFPaswordHelper
[javac] 
/build/1st/libapache-poi-java-3.12/src/ooxml/java/org/apache/poi/xssf/usermodel/helpers/XSSFPaswordHelper.java:113:
 error: cannot find symbol
[javac] byte salt[] = 
DatatypeConverter.parseBase64Binary(saltVal);
[javac]   ^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class XSSFPaswordHelper
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 7 errors
[javac] 4 warnings

BUILD FAILED
/build/1st/libapache-poi-java-3.12/build.xml:756: Compile failed; see the 
compiler error output for details.

Total time: 2 minutes 18 seconds
dh_auto_build: ant -propertyfile ./debian/ant.properties -Duser.name debian 
-Dversion.id=3.12 -DDSTAMP=20180725 jar maven-poms javadocs returned exit code 1
make[1]: *** [debian/rules:13: override_dh_auto_build] Error 2



Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

2018-10-31 Thread Samuel Thibault
Source: qtmultimedia-opensource-src
Version: 5.11.2-2
Severity: important
Tags: patch

Hello,

qtmultimedia-opensource-src currently FTBFS on hurd because
qtaudioengine doesn't get built.

https://buildd.debian.org/status/fetch.php?pkg=qtmultimedia-opensource-src=hurd-i386=5.11.2-2=1540905856=0

Could you apply the attached patch to just disable the resulting
package?

(kio indirectly depends on it, and thus a big lot of kde packages too).

Thanks,
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
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
(By Matt Welsh)
--- debian/control.original 2018-10-31 22:21:09.0 +
+++ debian/control  2018-10-31 22:21:14.0 +
@@ -93,7 +93,7 @@
  This package contains the Multimedia QML module for QtDeclarative.
 
 Package: qml-module-qtaudioengine
-Architecture: any
+Architecture: linux-any kfreebsd-any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}


Bug#912198: stretch-pu: package spamassassin/3.4.2-1~deb9u1

2018-10-31 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Mon, 2018-10-29 at 20:28 -0700, Noah Meyerhans wrote:
> On Mon, Oct 29, 2018 at 07:16:18PM +, Adam D. Barratt wrote:
> > > I have prepared an upload for stretch that is a backport of the
> > > 3.4.2-1 package currently in testing. The changelog entries from
> > > 3.4.1-6 to 3.4.2-1~deb9u1 are below. Note that stretch currently
> > > contains 3.4.1-6+deb9u1. The changes in that version are included
> > > in
> > > the 3.4.1-7 entry in the backport.
> > > 
> > > The debdiff for the debian/ subdirectory is attached. I pruned
> > > the
> > > upstream changes, since they result in a large diff, but can
> > > provide
> > > them if you want.
> > 
> > Yes, please.
> 
> See attached.

Thanks.

Please feel free to upload, bearing in mind that the window for getting
updates into the 9.6 point release closes during this weekend.

Regards,

Adam



Bug#902557: transition: Perl 5.28

2018-10-31 Thread Niko Tyni
On Wed, Oct 31, 2018 at 10:04:21AM +0100, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed

> Yes. Let's go ahead then as things look good now.

Thanks, uploaded.
-- 
Niko



Bug#910517: ftbfs on i386 unfixed, blocks monero migration

2018-10-31 Thread Jonas Smedegaard
Quoting Adrian Bunk (2018-10-31 21:56:39)
> On Sun, Oct 21, 2018 at 05:28:28PM +0200, Jonas Smedegaard wrote:
> >...
> > Weird: When I do "querybts monero" this bugreport doesn't appear.
> 
> This shows only the bugs in the binary package "monero".
> 
> "querybts src:monero" shows both the bugs in the source package and 
> the bugs in all binary packages.

Ah.  Thanks!


> > Oh well - it seems my own little research and attempt at a patch 
> > succeeded - the i386 build has succeeded now!  I stumbled upon a web 
> > page mentioning that memory consumption would blow up if any of the 
> > source files contained non-UTF8 characters, and indeed one file had 
> > some mysterious characters in a comment - seemingly em-dash in 
> > 8859-1 wrongly converted to UTF-8.
> >...
> 
> Do you have an URL for that?
> Is that already in the upstream gcc bugzilla?

Here's the URL mentioning that non-UTF-8 source causes gcc to consume 
more memory:

https://stackoverflow.com/questions/29194247/how-to-diagnose-g-error-cc1plus-exe-out-of-memory-allocating-838860800-bytes

Above references GCC documentation, but I am unaware if the memory 
consumption issue sepcifically is known to GCC developers.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#912474: junit4 FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: junit4
Version: 4.12-7
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/junit4.html

...
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 14.974 s
[INFO] Finished at: 2018-10-31T09:30:32-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile 
(default-testCompile) on project junit: Compilation failure: Compilation 
failure: 
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[194,8]
 error: method does not override or implement a method from a supertype
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[196,60]
 error: cannot find symbol
[ERROR]   symbol: method checkTopLevelWindow(Object)
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[196,114]
 error: cannot find symbol
[ERROR]   symbol:   method checkTopLevelWindow(Object)
[ERROR]   location: variable originalSecurityManager of type SecurityManager
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[206,8]
 error: method does not override or implement a method from a supertype
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[209,39]
 error: cannot find symbol
[ERROR]   symbol:   method checkSystemClipboardAccess()
[ERROR]   location: variable originalSecurityManager of type SecurityManager
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[213,8]
 error: method does not override or implement a method from a supertype
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[216,39]
 error: cannot find symbol
[ERROR]   symbol:   method checkAwtEventQueueAccess()
[ERROR]   location: variable originalSecurityManager of type SecurityManager
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[241,8]
 error: method does not override or implement a method from a supertype
[ERROR] 
/build/1st/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[244,39]
 error: cannot find symbol
[ERROR]   symbol:   method checkMemberAccess(Class,int)
[ERROR]   location: variable originalSecurityManager of type SecurityManager
[ERROR]   where CAP#1 is a fresh type-variable:
[ERROR] CAP#1 extends Object from capture of ?
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/junit4-4.12 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/junit4-4.12/debian 
-Dmaven.repo.local=/build/1st/junit4-4.12/debian/maven-repo --batch-mode 
package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true 
-Dlocale=en_US returned exit code 1
make: *** [debian/rules:4: build] Error 2



Bug#912473: jython FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jython
Version: 2.7.1+repack-4
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jython.html

...
compile:
[javac] /build/1st/jython-2.7.1+repack/build.xml:486: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 882 source files to 
/build/1st/jython-2.7.1+repack/build/classes
[javac] 
/build/1st/jython-2.7.1+repack/src/org/python/compiler/Module.java:21: error: 
package javax.xml.bind does not exist
[javac] import javax.xml.bind.DatatypeConverter;
[javac]  ^
[javac] 
/build/1st/jython-2.7.1+repack/src/org/python/core/BytecodeLoader.java:11: 
error: package javax.xml.bind does not exist
[javac] import javax.xml.bind.DatatypeConverter;
[javac]  ^
 ...
[javac] 
/build/1st/jython-2.7.1+repack/src/org/python/compiler/Module.java:867: error: 
cannot find symbol
[javac] String code_str = 
DatatypeConverter.printBase64Binary(bo.toByteArray());
[javac]   ^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class Module
...
[javac] 
/build/1st/jython-2.7.1+repack/src/org/python/core/BytecodeLoader.java:82: 
error: cannot find symbol
[javac] byte[] b = DatatypeConverter.parseBase64Binary(code_str);
[javac]^
[javac]   symbol:   variable DatatypeConverter
[javac]   location: class BytecodeLoader



Bug#912069: flask-wtf FTBFS: FAIL: test_i18n_enabled (tests.test_i18n.TestI18NCase)

2018-10-31 Thread Christoph Berg
Re: Adrian Bunk 2018-10-27 
<154067546369.20678.16027981767936779592.reportbug@localhost>
> Some recent change in unstable makes flask-wtf FTBFS:
> Traceback (most recent call last):
>   File 
> "/build/1st/flask-wtf-0.14.2/.pybuild/cpython2_2.7_flaskext.wtf/build/tests/test_i18n.py",
>  line 32, in test_i18n_enabled
> assert '\u8be5\u5b57\u6bb5\u662f' in to_unicode(response.data)

I recently updated wtforms which is probably the culprit here. The
unicode string it is looking for is "该字段是" which is the
translation of "This field is required." (see tests/test_i18n.py).
The string is still in wtforms' wtforms/locale/zh/LC_MESSAGES/wtforms.po
file, though.

It looks like translations are busted:

foo = response.data
print (foo)
assert '\u8be5\u5b57\u6bb5\u662f' in to_unicode(foo)

AssertionError:
 >> begin captured stdout << -







{name: [uThis field is required.]}



Name









- >> end captured stdout << --

Christoph



Bug#912440: Seems to be fixed

2018-10-31 Thread Piper McCorkle
Control: fixed -1 0.48.1-1

Just moved over to `buster` for my build infrastructure, and this issue
seems to be resolved on 0.48.1-1.
-- 
Piper McCorkle (transitioning s/Zeb(ulon)?/Piper/)
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |


signature.asc
Description: PGP signature


Bug#912472: ckanclient is deprecated, replace with ckanapi

2018-10-31 Thread Antoine Beaupre
Package: python-ckanclient
Version: 0.9-1.1
Severity: normal

The ckanclient homepage now redirects to:

https://github.com/okfn/ckanclient-deprecated

Which reads:

> DEPRECATED - please see https://github.com/ckan/ckanapi. [Python client 
> library for CKAN]

The CKAN API client does seem to be way more powerful and useful as
well. The client can be installed in Debian buster with pip without
too much trouble. Most deps seem to be present in debian as well.

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

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

Versions of packages python-ckanclient depends on:
ii  python 2.7.15-3
ii  python-gdata   2.0.18+dfsg1-2
ii  python-simplejson  3.15.0-1+b1

python-ckanclient recommends no packages.

Versions of packages python-ckanclient suggests:
pn  python-nose  

-- no debconf information



Bug#912465: RM: mozvoikko/2.2-0.1

2018-10-31 Thread Adam D. Barratt
Control: tags -1 + moreinfo

On Wed, 2018-10-31 at 21:29 +0100, Moritz Muehlenhoff wrote:
> Please remove mozvoikko from stretch, it's broken with Firefox 60.
> Removal from sid was filed in #912457.

Unfortunately it has r-deps:

# Broken Depends:
debian-parl: parl-desktop-eu
 parl-desktop-world

Regards,

Adam



Bug#912462: stretch-pu: package xorg-server/2:1.19.2-1+deb9u5

2018-10-31 Thread Adam D. Barratt
Control: tags -1 + confirmed d-i

On Wed, 2018-10-31 at 21:11 +0100, Andreas Boll wrote:
> I'd like to backport an upstream xorg-server patch to stable to fix
> issue #908601. It fixes a kwin regression caused by Mesa >= 18.0.
> This
> issue has already been fixed in xorg-server in unstable and testing.
> However with backporting Mesa to stretch-backports this issue has
> also
> been triggered with xorg-server in stretch. Since we don't backport
> xorg-server to stretch-backports and the required patch for stretch
> is
> very small I'd like to fix this issue via stretch-pu.
> 

I'd be OK with that, but as xorg-server produces a udeb, it'll need a
d-i ack first. CCing KiBi and tagging appropriately.

Regards,

Adam



Bug#912471: xpra: missing dependency on python-paramiko

2018-10-31 Thread Ross Vandegrift
Package: xpra
Version: 2.4+dfsg1-1
Severity: normal

xpra is unable to attach to an ssh session since paramiko is missing:

$ xpra attach ssh:vanvanmojo.local:23
2018-10-31 14:02:34,160 Xpra gtk2 client version 2.4-r20681M 64-bit
2018-10-31 14:02:34,161  running on Linux Debian testing buster
2018-10-31 14:02:34,162  window manager is 'Enlightenment'
2018-10-31 14:02:34,184 Warning: failed to import opencv:
2018-10-31 14:02:34,184  No module named cv2
2018-10-31 14:02:34,184  webcam forwarding is disabled
2018-10-31 14:02:35,207 GStreamer version 1.14.4 for Python 2.7.15 64-bit
2018-10-31 14:02:35,290 No OpenGL_accelerate module loaded: No module named 
OpenGL_accelerate
2018-10-31 14:02:35,454 OpenGL enabled with Mesa DRI Intel(R) HD Graphics 530 
(Skylake GT2)
2018-10-31 14:02:35,490 Xpra client failed to connect
2018-10-31 14:02:35,490 connection failed: No module named paramiko
2018-10-31 14:02:35,491 Error: printing disabled:
2018-10-31 14:02:35,491  No module named cups
xpra initialization error:
 connection failed: No module named paramiko

Once I do 'apt install python-paramiko', all is good again.

Thanks,
Ross

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages xpra depends on:
ii  adduser   3.118
ii  init-system-helpers   1.55
ii  libavcodec58  7:4.0.2-2+b2
ii  libavformat58 7:4.0.2-2+b2
ii  libavutil56   7:4.0.2-2+b2
ii  libc6 2.27-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libpam0g  1.1.8-3.8
ii  libswscale5   7:4.0.2-2+b2
ii  libsystemd0   239-11
ii  libturbojpeg0 1:1.5.2-2+b1
ii  libvpx5   1.7.0-3
ii  libwebp6  0.6.1-2
ii  libx11-6  2:1.6.7-1
ii  libx264-155   2:0.155.2917+git0a84d98-2
ii  libx265-165   2.9-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxkbfile1   1:1.0.9-2
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  python2.7.15-3
ii  python-gi-cairo   3.30.1-2
ii  python-gtk2   2.24.0-5.1+b1
ii  python-rencode1.0.5-1+b2
ii  x11-xserver-utils 7.7+8
ii  xserver-xorg-input-void   1:1.4.1-1+b2
ii  xserver-xorg-video-dummy  1:0.3.8-1+b1

Versions of packages xpra recommends:
ii  keyboard-configuration  1.186
ii  openssh-client  1:7.9p1-1
ii  python-dbus 1.2.8-2+b1
ii  python-gtkglext11.1.0-9.1
ii  python-imaging  4.3.0-2
ii  python-lz4  1.1.0+dfsg-1
ii  python-lzo  1.12-2
ii  python-pil  5.3.0-1
ii  python-uritools 2.1.0-1
ii  ssh-askpass 1:1.2.4.1-10

Versions of packages xpra suggests:
ii  cups-client2.2.8-5
ii  cups-common2.2.8-5
ii  cups-filters   1.21.3-2
pn  cups-pdf   
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  gstreamer1.0-plugins-base  1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-plugins-ugly  1.14.4-1
ii  openssh-server 1:7.9p1-1
ii  pulseaudio 12.2-2
ii  pulseaudio-utils   12.2-2
pn  python-avahi   
pn  python-cups
pn  python-gst-1.0 
pn  python-netifaces   
pn  python-opencv  
pn  python-pyopencl
pn  python-uinput  
pn  python-yaml
pn  v4l2loopback-dkms  

-- no debconf information



Bug#912470: jmdns FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jmdns
Version: 3.5.4-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jmdns.html

...
[INFO] Compiling 57 source files to /build/1st/jmdns-3.5.4/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/build/1st/jmdns-3.5.4/src/main/java/javax/jmdns/impl/DNSOutgoing.java:[56,14] 
writeBytes(byte[]) in javax.jmdns.impl.DNSOutgoing.MessageOutputStream cannot 
override writeBytes(byte[]) in java.io.ByteArrayOutputStream
  attempting to assign weaker access privileges; was public
[INFO] 1 error



Bug#911599: A workaround for this issue

2018-10-31 Thread Lageo TI
1. Download and install an older version of libapt
# wget
http://ftp.it.debian.org/debian/pool/main/a/apt/libapt-pkg5.0_1.4.8_amd64.deb
# dpkg -i libapt-pkg5.0_1.4.8_amd64.deb

2. Then run a apt fix broken apt
# apt --fix-broken install

That worked for me

Regards


Bug#893189: llvm-defaults to llvm-7 ? [was: Re: Bug#893189: transition: llvm-defaults to llvm 6.0]

2018-10-31 Thread Adrian Bunk
On Tue, Oct 23, 2018 at 09:11:53AM +0200, Sylvestre Ledru wrote:
>...
> * Remove everything but 6 & 7 from the archive to release with only two llvm 
> versions. (maybe one if we are very lucky? :)

Luck alone won't help.

The biggest block for shipping only LLVM 7 in buster might be to move 
ghc on arm* either to LLVM 7 or to not use LLVM - and this would ideally
have to be done before the last gc transition for buster starts.

> Cheers,
> Sylvestre

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#912469: Spourious blank line without parameters

2018-10-31 Thread Yuri D'Elia

Package: members
Version: 20080128-5+nmu1+b1
Severity: minor

Running "members" without parameters shows a spourious blank line before
"Usage:".

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 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 members depends on:
ii  libc6   2.27-8
ii  libgcc1 1:8.2.0-9
ii  libstdc++6  8.2.0-9

members recommends no packages.

members suggests no packages.



Bug#910517: ftbfs on i386 unfixed, blocks monero migration

2018-10-31 Thread Adrian Bunk
On Sun, Oct 21, 2018 at 05:28:28PM +0200, Jonas Smedegaard wrote:
>...
> Weird: When I do "querybts monero" this bugreport doesn't appear.

This shows only the bugs in the binary package "monero".

"querybts src:monero" shows both the bugs in the source package
and the bugs in all binary packages.

> Oh well - it seems my own little research and attempt at a patch 
> succeeded - the i386 build has succeeded now!  I stumbled upon a web 
> page mentioning that memory consumption would blow up if any of the 
> source files contained non-UTF8 characters, and indeed one file had some 
> mysterious characters in a comment - seemingly em-dash in 8859-1 wrongly 
> converted to UTF-8.
>...

Do you have an URL for that?
Is that already in the upstream gcc bugzilla?

>  - Jonas

Thanks
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#912468: java3d FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: java3d
Version: 1.5.2+dfsg-15
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/java3d.html

...
[javac] 
/build/1st/java3d-1.5.2+dfsg/j3d-core-utils/src/classes/share/com/sun/j3d/utils/applet/JMainFrame.java:292:
 error: cannot find symbol
[javac] return new sun.applet.AppletAudioClip( url );
[javac]  ^
[javac]   symbol:   class AppletAudioClip
[javac]   location: package sun.applet
[javac] 
/build/1st/java3d-1.5.2+dfsg/j3d-core-utils/src/classes/share/com/sun/j3d/utils/applet/MainFrame.java:341:
 error: cannot find symbol
[javac] return new sun.applet.AppletAudioClip( url );
[javac]  ^
[javac]   symbol:   class AppletAudioClip
[javac]   location: package sun.applet



Bug#906871: xul-ext-flashblock no longer works with firefox-esr 60

2018-10-31 Thread Moritz Mühlenhoff
On Tue, Aug 21, 2018 at 09:37:01PM +0300, Adrian Bunk wrote:
> Package: xul-ext-flashblock
> Version: 1.5.20-2
> Severity: serious
> 
> XUL addons are no longer supported.

Seems dead upstream, let's remove?

Cheers,
Moritz



Bug#912467: jasperreports FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jasperreports
Version: 6.3.1-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jasperreports.html

...
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 27.382 s
[INFO] Finished at: 2019-12-03T14:59:05-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project jasperreports: Compilation failure: Compilation failure: 
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[35,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[36,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[37,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[38,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[39,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[40,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[41,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[42,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[43,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[44,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[45,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[46,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[47,22]
 package javax.xml.soap does not exist
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[97,17]
 cannot find symbol
[ERROR]   symbol:   class SOAPFactory
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[98,17]
 cannot find symbol
[ERROR]   symbol:   class SOAPConnection
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[215,19]
 cannot find symbol
[ERROR]   symbol:   class SOAPConnection
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[232,19]
 cannot find symbol
[ERROR]   symbol:   class SOAPMessage
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[299,41]
 cannot find symbol
[ERROR]   symbol:   class SOAPEnvelope
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[299,64]
 cannot find symbol
[ERROR]   symbol:   class SOAPElement
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[299,154]
 cannot find symbol
[ERROR]   symbol:   class SOAPException
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[326,44]
 cannot find symbol
[ERROR]   symbol:   class SOAPMessage
[ERROR]   location: class net.sf.jasperreports.olap.xmla.JRXmlaQueryExecuter
[ERROR] 
/build/1st/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/olap/xmla/JRXmlaQueryExecuter.java:[326,19]
 cannot find symbol
[ERROR]   

Bug#912466: jaxb-api FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jaxb-api
Version: 2.3.0-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jaxb-api.html

...
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentMarshaller.java:[43,24]
 package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentMarshaller.java:[125,46]
 cannot find symbol
  symbol:   class DataHandler
  location: class javax.xml.bind.attachment.AttachmentMarshaller
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentMarshaller.java:[214,48]
 cannot find symbol
  symbol:   class DataHandler
  location: class javax.xml.bind.attachment.AttachmentMarshaller
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentUnmarshaller.java:[43,24]
 package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentUnmarshaller.java:[131,20]
 cannot find symbol
  symbol:   class DataHandler
  location: class javax.xml.bind.attachment.AttachmentUnmarshaller
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/annotation/XmlInlineBinaryData.java:[52,24]
 package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/annotation/XmlAttachmentRef.java:[43,24]
 package javax.activation does not exist
[INFO] 7 errors 
[INFO] -
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Java Architecture for XML Binding 2.3.0  SUCCESS [  0.002 s]
[INFO] jaxb-api 2.3.0 . FAILURE [  4.549 s]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 5.616 s
[INFO] Finished at: 2019-12-03T14:55:31-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (base-compile) on 
project jaxb-api: Compilation failure: Compilation failure: 
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentMarshaller.java:[43,24]
 package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentMarshaller.java:[125,46]
 cannot find symbol
[ERROR]   symbol:   class DataHandler
[ERROR]   location: class javax.xml.bind.attachment.AttachmentMarshaller
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentMarshaller.java:[214,48]
 cannot find symbol
[ERROR]   symbol:   class DataHandler
[ERROR]   location: class javax.xml.bind.attachment.AttachmentMarshaller
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentUnmarshaller.java:[43,24]
 package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/attachment/AttachmentUnmarshaller.java:[131,20]
 cannot find symbol
[ERROR]   symbol:   class DataHandler
[ERROR]   location: class javax.xml.bind.attachment.AttachmentUnmarshaller
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/annotation/XmlInlineBinaryData.java:[52,24]
 package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-api-2.3.0/jaxb-api/src/main/java/javax/xml/bind/annotation/XmlAttachmentRef.java:[43,24]
 package javax.activation does not exist
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :jaxb-api
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/jaxb-api-2.3.0 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/jaxb-api-2.3.0/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/jaxb-api-2.3.0/debian 
-Dmaven.repo.local=/build/1st/jaxb-api-2.3.0/debian/maven-repo --batch-mode 
package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1
make: *** [debian/rules:4: build] 

Bug#912465: RM: mozvoikko/2.2-0.1

2018-10-31 Thread Moritz Muehlenhoff
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Please remove mozvoikko from stretch, it's broken with Firefox 60. Removal from
sid was filed in #912457.

Cheers,
Moritz



Bug#912381: [Pkg-xen-devel] Bug#912381: xen-utils-4.11: /usr/lib/xen-4.11/bin/pygrub is missing after upgrade from xen-utils-4.8

2018-10-31 Thread Hans van Kranenburg
Hi,

On 10/31/2018 09:10 PM, Dimitar Angelov wrote:
> On Wed, 31 Oct 2018 19:16:11 +0100 Hans van Kranenburg
>  wrote:
>> An alternative that might help you now might be to switch to pvgrub2?
>> https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/
>>
>> Search for "Debian" in that page to find pointers to the grub-xen
>> packages.
> 
> Thank you for suggestion using pvgrub2 PV VM is booting properly.
> Only for information what I was done:
> 1. Booted Gust OS (Debian stretch) with kernel from DOM0 guest.cfg.
> kernel  = '/boot/vmlinuz-4.18.0-2-amd64'
> extra   = 'elevator=noop'
> ramdisk = '/boot/initrd.img-4.18.0-2-amd64'
> 
> 2. Installed grub-pc which replace grub-legacy
> apt-get install grub-pc
> 
> 3. Shutdown guest and modify guest.cfg
> kernel  = '/usr/lib/grub-xen/grub-x86_64-xen.bin'
> extra   = '(xen/xvda2)/boot/grub/grub.cfg'
> 
> DOM0 have installed grub-xen-bin and grub-xen-host.
> 
> Create guest and is booted properly via GRUB2.

Great! pvgrub2 is a newer, safer and more robust solution, recommended.
The only downside can be that you already have to choose to boot the 32
or 64 bit image, but in many cases that's not a problem.

Thanks for also sharing the steps, since it might help someone else who
runs into the same or a similar problem.

Hans



Bug#912464: icedtea-netx should depend on default-jre | java*-runtime

2018-10-31 Thread Adrian Bunk
Package: icedtea-netx
Version: 1.7.1-1
Severity: serious

It sounds wrong that icedtea-netx no longer has any JRE dependency.



Bug#912463: lava: autopkgtest regression: kvm module is not enabled

2018-10-31 Thread Paul Gevers
Source: lava
Version: 2018.10-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of lava the autopkgtest of lava fails in testing
when that autopkgtest is run with the binary packages of lava from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
lava   from testing2018.10-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
bug I wonder if this is a new test should be disabled if the test is run
in an lxc, either in the test itself or declaring the isolation-machine
restriction (but than it will be skipped on ci.d.n infrastructure
currently).

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
lava/2018.10-1. I.e. due to versioned dependencies or breaks/conflicts.
In this case: debci, lxc, lxcfs, postgresql-11
[1] https://qa.debian.org/excuses.php?package=lava

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lava/1239344/log.gz

==
FAIL: test_validate (test_kvm.TestKVMBasicDeploy)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.p48a9jj3/downtmp/build.RxE/src/lava_dispatcher/test/test_kvm.py",
line 183, in test_validate
allow_missing_path(self.job.pipeline.validate_actions, self,
'qemu-system-x86_64')
lava_common.exceptions.JobError: Invalid job data: ['Device
configuration contains -enable-kvm option but kvm module is not enabled.']


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.p48a9jj3/downtmp/build.RxE/src/lava_dispatcher/test/test_kvm.py",
line 185, in test_validate
self.fail(exc)
AssertionError: Invalid job data: ['Device configuration contains
-enable-kvm option but kvm module is not enabled.']


--
Ran 333 tests in 244.538s

FAILED (failures=1, skipped=20)



signature.asc
Description: OpenPGP digital signature


Bug#912229: gitaly: gitlab not creating new project/repo

2018-10-31 Thread Justin Hallett
Is there an interim fix/patch I can do locally? The some bug seems to happen 
when you want to look at a commit diff as well.

It seems that this line

Err :connection error: desc = \"transport: Error while dialing dial unix 
gitaly-ruby://gitaly-ruby: connect: no such file or directory\”

Is the issue, a google search tells me that should be the socket, for example

transport: dial unix tmp/sockets/private/gitaly.socket: connect: no such file 
or directory

Obviously that is a different error, but it’s pointed to the socket which makes 
more sense than gitaly-ruby://gitaly-ruby

I’m no expert by far, so I have no idea where to look at why it’s trying to 
call Gitaly-ruby instead of the socket for the config, but maybe this will help 
someone that does understand it find a temp work around to get things running 
again since downgrading isn’t really an option anymore.

- Justin


Bug#912381: xen-utils-4.11: /usr/lib/xen-4.11/bin/pygrub is missing after upgrade from xen-utils-4.8

2018-10-31 Thread Dimitar Angelov
On Wed, 31 Oct 2018 19:16:11 +0100 Hans van Kranenburg 
 wrote:

An alternative that might help you now might be to switch to pvgrub2?
https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/
Search for "Debian" in that page to find pointers to the grub-xen packages.


Thank you for suggestion using pvgrub2 PV VM is booting properly.
Only for information what I was done:
1. Booted Gust OS (Debian stretch) with kernel from DOM0 guest.cfg.
kernel  = '/boot/vmlinuz-4.18.0-2-amd64'
extra   = 'elevator=noop'
ramdisk = '/boot/initrd.img-4.18.0-2-amd64'

2. Installed grub-pc which replace grub-legacy
apt-get install grub-pc

3. Shutdown guest and modify guest.cfg
kernel  = '/usr/lib/grub-xen/grub-x86_64-xen.bin'
extra   = '(xen/xvda2)/boot/grub/grub.cfg'

DOM0 have installed grub-xen-bin and grub-xen-host.

Create guest and is booted properly via GRUB2.

Regards,

Dimitar Angelov



Bug#912462: stretch-pu: package xorg-server/2:1.19.2-1+deb9u5

2018-10-31 Thread Andreas Boll
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Control: block 908601 by -1

Hi,

I'd like to backport an upstream xorg-server patch to stable to fix
issue #908601. It fixes a kwin regression caused by Mesa >= 18.0. This
issue has already been fixed in xorg-server in unstable and testing.
However with backporting Mesa to stretch-backports this issue has also
been triggered with xorg-server in stretch. Since we don't backport
xorg-server to stretch-backports and the required patch for stretch is
very small I'd like to fix this issue via stretch-pu.

Attached is the debdiff between xorg-server 2:1.19.2-1+deb9u4 and
2:1.19.2-1+deb9u5.

Thanks,
Andreas
diff -u xorg-server-1.19.2/debian/changelog xorg-server-1.19.2/debian/changelog
--- xorg-server-1.19.2/debian/changelog
+++ xorg-server-1.19.2/debian/changelog
@@ -1,3 +1,12 @@
+xorg-server (2:1.19.2-1+deb9u5) stretch; urgency=medium
+
+  * Cherry-pick c2954b16c (glx: do not pick sRGB config for 32-bit RGBA
+visual) from upstream. Fixes various blending issues with kwin and
+Mesa >= 18.0 (i.e. Mesa from stretch-backports) (Closes: #908601).
+Thanks to Nicholas D Steeves and Robert Trebula for testing!
+
+ -- Andreas Boll   Wed, 31 Oct 2018 17:58:03 +0100
+
 xorg-server (2:1.19.2-1+deb9u4) stretch-security; urgency=medium
 
   * Disable -logfile and -modulepath when running with elevated privileges.
diff -u xorg-server-1.19.2/debian/patches/series 
xorg-server-1.19.2/debian/patches/series
--- xorg-server-1.19.2/debian/patches/series
+++ xorg-server-1.19.2/debian/patches/series
@@ -12,0 +13 @@
+12_glx-do-not-pick-sRGB-config-for-32-bit-RGBA-visual.patch
only in patch2:
unchanged:
--- 
xorg-server-1.19.2.orig/debian/patches/12_glx-do-not-pick-sRGB-config-for-32-bit-RGBA-visual.patch
+++ 
xorg-server-1.19.2/debian/patches/12_glx-do-not-pick-sRGB-config-for-32-bit-RGBA-visual.patch
@@ -0,0 +1,31 @@
+commit c2954b16c8730c7ed8441fd8dba25900f3aed265
+Author: Tapani Pälli 
+Date:   Tue Nov 28 09:23:29 2017 +0200
+
+glx: do not pick sRGB config for 32-bit RGBA visual
+
+This fixes blending issues seen with kwin and gnome-shell when
+32bit visual has sRGB capability set.
+
+Reviewed-by: Adam Jackson 
+Signed-off-by: Tapani Pälli 
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103699
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103646
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103655
+
+diff --git a/glx/glxscreens.c b/glx/glxscreens.c
+index 73444152a..596d972e0 100644
+--- a/glx/glxscreens.c
 b/glx/glxscreens.c
+@@ -271,6 +271,11 @@ pickFBConfig(__GLXscreen * pGlxScreen, VisualPtr visual)
+ /* If it's the 32-bit RGBA visual, demand a 32-bit fbconfig. */
+ if (visual->nplanes == 32 && config->rgbBits != 32)
+ continue;
++/* If it's the 32-bit RGBA visual, do not pick sRGB capable config.
++ * This can cause issues with compositors that are not sRGB aware.
++ */
++if (visual->nplanes == 32 && config->sRGBCapable == GL_TRUE)
++continue;
+ /* Can't use the same FBconfig for multiple X visuals.  I think. */
+ if (config->visualID != 0)
+ continue;


Bug#912439: [Pkg-openssl-devel] Bug#912439: OpenSSL in Debian Testing breaks SSL connectivity in some cases with hexchat/irssi

2018-10-31 Thread Justin Piszcz
On Wed, Oct 31, 2018 at 3:07 PM Kurt Roeckx  wrote:

> On Wed, Oct 31, 2018 at 11:08:18AM -0400, Justin Piszcz wrote:
> > Package: openssl
> > Version: 1.1.1-2
> >
> > Bug: Connection failed (20337260938) error:141A318A:SSL
> > routines:tls_process_ske_dhe:dh key too small)
>
> During the upgrade you should have received the following message:
>
>   Following various security recommendations, the default minimum TLS
> version
>   has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and
> Apple
>   plan to do same around March 2020.
>
>   The default security level for TLS connections has also be increased from
>   level 1 to level 2. This moves from the 80 bit security level to the 112
> bit
>   security level and will require 2048 bit or larger RSA and DHE keys, 224
> bit
>   or larger ECC keys, and SHA-2.
>
>   The system wide settings can be changed in /etc/ssl/openssl.cnf.
> Applications
>   might also have a way to override the defaults.
>
>   In the default /etc/ssl/openssl.cnf there is a MinProtocol and
> CipherString
>   line. The CipherString can also sets the security level. Information
> about the
>   security levels can be found in the SSL_CTX_set_security_level(3ssl)
> manpage.
>   The list of valid strings for the minimum protocol version can be found
> in
>   SSL_CONF_cmd(3ssl). Other information can be found in ciphers(1ssl) and
>   config(5ssl).
>
>   Changing back the defaults in /etc/ssl/openssl.cnf to previous system
> wide
>   defaults can be done using:
>   MinProtocol = None
>   CipherString = DEFAULT
>
>   It's recommended that you contact the remote site in case the defaults
> cause
>   problems.
>
>
> Kurt
>

Understood & thank you!

Justin.


Bug#912461: jaxb FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jaxb
Version: 2.3.0.1-5
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jaxb.html

...
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 18.186 s
[INFO] Finished at: 2018-10-31T07:37:00-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project jaxb-core: Compilation failure: Compilation failure: 
[ERROR] 
/build/1st/jaxb-2.3.0.1/jaxb-ri/core/src/main/java/com/sun/xml/bind/v2/model/core/PropertyInfo.java:[45,23]
 error: package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-2.3.0.1/jaxb-ri/core/src/main/java/com/sun/xml/bind/v2/model/core/PropertyInfo.java:[143,4]
 error: cannot find symbol
[ERROR]   symbol:   class MimeType
[ERROR]   location: interface PropertyInfo
[ERROR]   where T,C are type-variables:
[ERROR] T extends Object declared in interface PropertyInfo
[ERROR] C extends Object declared in interface PropertyInfo
[ERROR] 
/build/1st/jaxb-2.3.0.1/jaxb-ri/core/src/main/java/com/sun/xml/bind/v2/runtime/SwaRefAdapterMarker.java:[44,23]
 error: package javax.activation does not exist
[ERROR] 
/build/1st/jaxb-2.3.0.1/jaxb-ri/core/src/main/java/com/sun/xml/bind/v2/runtime/SwaRefAdapterMarker.java:[51,60]
 error: cannot find symbol
[ERROR]   symbol: class DataHandler
[ERROR] 
/build/1st/jaxb-2.3.0.1/jaxb-ri/core/src/main/java/com/sun/xml/bind/v2/runtime/SwaRefAdapterMarker.java:[53,11]
 error: cannot find symbol
[ERROR]   symbol:   class DataHandler
[ERROR]   location: class SwaRefAdapterMarker
[ERROR] 
/build/1st/jaxb-2.3.0.1/jaxb-ri/core/src/main/java/com/sun/xml/bind/v2/runtime/SwaRefAdapterMarker.java:[57,26]
 error: cannot find symbol
[ERROR]   symbol:   class DataHandler
[ERROR]   location: class SwaRefAdapterMarker
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :jaxb-core
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/jaxb-2.3.0.1 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/jaxb-2.3.0.1/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/jaxb-2.3.0.1/debian 
-Dmaven.repo.local=/build/1st/jaxb-2.3.0.1/debian/maven-repo --batch-mode -f 
jaxb-ri/pom.xml package javadoc:aggregate -DskipTests -DskipTests 
-Dnotimestamp=true -Dlocale=en_US returned exit code 1
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1



Bug#911904: Processed: block 911904 with 911915

2018-10-31 Thread 073plan
Hi all,

在 2018-10-26五的 13:49 +0200,Michal Čihař写道:
> Hi
> 
> On Fri, 2018-10-26 at 10:51 +0200, Ondřej Surý wrote:
> > LIBTIDY_LIBRARY=$(shell readlink -f
> > /usr/lib/$(DEB_HOST_MULTIARCH)/libtidy.so)
> 
> Well it all started from this file being absent from the package :-)
> 
> > LIBTIDY_PACKAGE=$(shell dpkg-query --search $(LIBTIDY_LIBRARY) | cut
> > -f 1 -d :)
> > LIBTIDY_LIBRARY_FILE$(shell basename $(LIBTIDY_LIBRARY))
> > 
> > then
> > 
> > sed -e “s/libtidy.so/$(LIBTIDY_LIBRARY_FILE)” lib.py
> > 
> > echo libtidy:Depends=$(LIBTIDY_PACKAGE) > python-utidylib.substvars
> > 
> > and replace
> > 
> > libtidy5deb1 | libtidy5,
> 
> I don't get what this would solve - there is nothing wrong with
> alternate dependecies as long as they both provide libtidy.so. Anyway
> same is in Build-Depends as well, where substvars are not really
> helpful.

So what will be the final solution? I'm wondering if we could solve the
problem soon to complete the transition.

BTW I see the advantage of automatically generating lib dependency; however, I
also believe that listing alternate dependencies should be okay as well since
it extends the compatibility range of binary package. Manual adjustment will
be necessary in each transition but as long as the package maintainer is
comfortable with that, it should be acceptable.


--
Regards,
Boyuan Yang



Bug#908829: preliminary packaging work

2018-10-31 Thread Jeffrey Cliff
I have successfully built a preliminary package using the code at
https://notabug.org/themusicgod1/panicparse/

Hopefully this helps.
Jeff Cliff



Bug#912460: kcollectd: Please change kde-runtime to Recommends

2018-10-31 Thread Elrond
Package: kcollectd
Version: 0.9-5
Severity: wishlist

Hi,

The dependency on kde-runtime pulls in a lot of stuff.
I have tried kcollectd without kde-runtime. I noticed some
icons missing, and some small other issues.

So most of the main features of kcollectd work without
kde-runtime.  So could you please change the "Depends:
kde-runtime" into a Recommends:?

Recommends: means "You REALLY should install this. If you
don't do it, expect missing functionality.", which seems
appropiate here?


Cheers

Elrond



Bug#619757: Bug #619757 breaks DVD reading by default now

2018-10-31 Thread Anthony DeRobertis
Ok, here is a different machine (and thus drive), different kernel 
version, and different disks:


$ uname -a
Linux Zia 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-10-07) x86_64 
GNU/Linux


# smartctl -i /dev/dvd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-2-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:   TSSTcorp
Product:  CD/DVDW SH-S183L
Revision: SB01

(the other machine has a HL-DT-ST BD-RE  WH14NS40 1.00).

I put in one disk:

/sbin/blockdev --getsize64 /dev/dvd
1073741312

I changed disks:

/sbin/blockdev --getsize64 /dev/dvd
1073741312

I ran "pktsetup -d 252:0"

/sbin/blockdev --getsize64 /dev/dvd
3992977408

I then ran "pktsetup /dev/dvd", and swapped discs again:

/sbin/blockdev --getsize64 /dev/dvd
3992977408

and after another "pktsetup -d 252:0":

/sbin/blockdev --getsize64 /dev/dvd
789905408

BTW: After a bunch of Googling, it appears someone noticed this bug 10 
years ago and apparently no one really figured out how to fix it. 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246211.html 
and kernel commit 7b3d9545f9ac8b31528dd2d6d8ec8d19922917b8 are 
references I found.




Bug#912418: ufw: UFW stops after logrotate weekly runs without messages

2018-10-31 Thread Jamie Strandboge
On Wed, 31 Oct 2018, Linuxonlinehelp wrote:

> Versions of packages ufw suggests:
> ii  rsyslog  8.38.0-1+b1
> 
> -- Configuration Files:
> /etc/logrotate.d/ufw [Errno 2] Datei oder Verzeichnis nicht gefunden: 
> '/etc/logrotate.d/ufw'
> 
> !! removed cause current disabled logging
> 
> !! SYSTEMD removed system on sys-v-init
> 
> -- debconf information excluded

Thank you for reporting a bug. It isn't clear to me what the problem is. Can
you list the steps to reproduce along with your expectations?

That said, please note that it is the kernel that facilitates ufw's logging.
ufw does ship /etc/rsyslog.d/20-ufw.conf which can be configured to redirect
its logs to /var/log/ufw.log along with /etc/logrotate.d/ufw which will rotate
/var/log/ufw.log and call 'invoke-rc.d rsyslog rotate', which is the standard
way to rotate rsyslog-managed logs. Could it be that your rsyslogd is not
properly restarting for some reason? If so, this would be a bug in rsyslog. It
also seems like you removed /etc/logrotate.d/ufw (see above).

-- 
Jamie Strandboge | http://www.canonical.com


signature.asc
Description: PGP signature


Bug#912459: jaxe FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jaxe
Version: 3.5-9
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jaxe.html

...
[javac] /build/1st/jaxe-3.5/source/jaxe/JaxeTransferHandler.java:284: 
error: cannot find symbol
[javac] sm.checkSystemClipboardAccess();
[javac]   ^
[javac]   symbol:   method checkSystemClipboardAccess()
[javac]   location: variable sm of type SecurityManager



Bug#912441: [Pkg-xen-devel] Bug#912441: xen-utils-4.11: package missing pygrub binaries

2018-10-31 Thread Hans van Kranenburg
reassign 912441 src:xen 4.11.1~pre.20180911.5acdd26fdc+dfsg-5
severity 912381 important
merge 912381 912441
thanks

On 10/31/2018 07:51 PM, Joshua M. Boniface wrote:
> Hi Hans,
> 
> On 2018-10-31 12:39 p.m., Hans van Kranenburg wrote:
>> tags 912441 + pending
>> thanks
>>
>> Hi,
>>
>> On 10/31/2018 04:44 PM, Joshua M. Boniface wrote:
>>> Package: xen-utils-4.11
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> We have discovered that the `pygrub` binaries, expected under
>>> `/usr/lib/xen-4.11/bin`, are no longer present in the xen-utils-4.11
>>> package.
>> Thanks for testing the package.
>>
>> The file is indeed missing, while it should be there.
>>
>>> Reviewing the source package reveals that the binary is still present
>>> under `tools/pygrub/src/pygrub`, however it is not referenced anywhere
>>> obvious in the package build configurations, nor is there any changelog
>>> indication that it has been moved or removed.
>> There's an exclude in debian/rules, which is too broad.
>>
>> The fix:
>> https://salsa.debian.org/xen-team/debian-xen/commit/d4b0d104f158217036c779e2c7f608d659e01f59
>>
>>
>>  From your comments, I suspect you already grabbed the file from the
>> source package to get a working environment again, for now?
> 
> I did attempt this, but it looks like there's some other dependencies
> missing when I do so, for instance:
> 
>> Traceback (most recent call last):
>>  File "/etc/xen/boot/pygrub", line 25, in 
>>    import fsimage
>> ImportError: libfsimage.so: cannot open shared object file: No such
> file or directory

Yes, there's more breakage. There's another bug, #912381, issued just a
bit earlier than your one. There's more info in there already:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912381

Let's continue in there.

> And it looks like the same issue occurs on a rebuild of the packages
> with the fix applied (took the `apt-get source`, modified `rules`).
> 
>>> The other files present in that source directory are installed under
>>> `/usr/lib/xen-4.11/lib/python/grub`, just not the binary.
>>>
>>> [...]

Hans



Bug#912458: jftp FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: jftp
Version: 1.60+dfsg-2
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jftp.html

...
compile:
[javac] /build/1st/jftp-1.60+dfsg/build.xml:68: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 125 source files to 
/build/1st/jftp-1.60+dfsg/build/classes
[javac] 
/build/1st/jftp-1.60+dfsg/src/java/net/sf/jftp/util/JReciever.java:95: error: 
cannot find symbol
[javac] reciever.destroy();
[javac] ^
[javac]   symbol:   method destroy()
[javac]   location: variable reciever of type Thread
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/build/1st/jftp-1.60+dfsg/build.xml:68: Compile failed; see the compiler error 
output for details.

Total time: 5 seconds
dh_auto_build: ant -Duser.name debian -Dant.build.javac.source=1.6 
-Dant.build.javac.target=1.6 jars returned exit code 1
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 2



Bug#912439: [Pkg-openssl-devel] Bug#912439: OpenSSL in Debian Testing breaks SSL connectivity in some cases with hexchat/irssi

2018-10-31 Thread Kurt Roeckx
On Wed, Oct 31, 2018 at 11:08:18AM -0400, Justin Piszcz wrote:
> Package: openssl
> Version: 1.1.1-2
> 
> Bug: Connection failed (20337260938) error:141A318A:SSL
> routines:tls_process_ske_dhe:dh key too small)

During the upgrade you should have received the following message:

  Following various security recommendations, the default minimum TLS version
  has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and Apple
  plan to do same around March 2020.

  The default security level for TLS connections has also be increased from
  level 1 to level 2. This moves from the 80 bit security level to the 112 bit
  security level and will require 2048 bit or larger RSA and DHE keys, 224 bit
  or larger ECC keys, and SHA-2.

  The system wide settings can be changed in /etc/ssl/openssl.cnf. Applications
  might also have a way to override the defaults.

  In the default /etc/ssl/openssl.cnf there is a MinProtocol and CipherString
  line. The CipherString can also sets the security level. Information about the
  security levels can be found in the SSL_CTX_set_security_level(3ssl) manpage.
  The list of valid strings for the minimum protocol version can be found in
  SSL_CONF_cmd(3ssl). Other information can be found in ciphers(1ssl) and
  config(5ssl).

  Changing back the defaults in /etc/ssl/openssl.cnf to previous system wide
  defaults can be done using:
  MinProtocol = None
  CipherString = DEFAULT

  It's recommended that you contact the remote site in case the defaults cause
  problems.


Kurt



Bug#912441: [Pkg-xen-devel] Bug#912441: xen-utils-4.11: package missing pygrub binaries

2018-10-31 Thread Joshua M. Boniface

Hi Hans,

On 2018-10-31 12:39 p.m., Hans van Kranenburg wrote:

tags 912441 + pending
thanks

Hi,

On 10/31/2018 04:44 PM, Joshua M. Boniface wrote:

Package: xen-utils-4.11
Severity: important

Dear Maintainer,

We have discovered that the `pygrub` binaries, expected under
`/usr/lib/xen-4.11/bin`, are no longer present in the xen-utils-4.11
package.

Thanks for testing the package.

The file is indeed missing, while it should be there.


Reviewing the source package reveals that the binary is still present
under `tools/pygrub/src/pygrub`, however it is not referenced anywhere
obvious in the package build configurations, nor is there any changelog
indication that it has been moved or removed.

There's an exclude in debian/rules, which is too broad.

The fix:
https://salsa.debian.org/xen-team/debian-xen/commit/d4b0d104f158217036c779e2c7f608d659e01f59

 From your comments, I suspect you already grabbed the file from the
source package to get a working environment again, for now?


I did attempt this, but it looks like there's some other dependencies missing 
when I do so, for instance:

> Traceback (most recent call last):
>  File "/etc/xen/boot/pygrub", line 25, in 
>    import fsimage
> ImportError: libfsimage.so: cannot open shared object file: No such file or 
directory

And it looks like the same issue occurs on a rebuild of the packages with the fix applied (took the `apt-get source`, 
modified `rules`).



The other files present in that source directory are installed under
`/usr/lib/xen-4.11/lib/python/grub`, just not the binary.

[...]

Hans

Thanks,
Joshua



Bug#912452: zenmap: too strict dependency on policykit-1

2018-10-31 Thread Reiner Herrmann
Hi Samuel,


> Initially I thought it was better to add is a Dependency by the following
> Policy text:
> "The Depends field should be used if the depended-on package is required
> for the depending package to provide a significant amount of functionality."

I see, but I think that a recommendation fits better:

> The Recommends field should list packages that would be found together with 
> this one in all but unusual installations.

Zenmap (like nmap) works fine also as a normal user, starting it as root is not
a requirement. Only some functionality requires root.

> I didn't realize polkit was dependent of systemd, but I just would like to
> make sure with the rest of the team that we can put polkit in Recommends
> even if it breaks the desktop file for zenmap as root.

When it is a recommendation, most desktop users will still get it automatically
installed, so I don't think it will break something for the average user.

Kind regards,
   Reiner


signature.asc
Description: PGP signature


Bug#906860: xul-ext-mozvoikko no longer works with firefox-esr 60

2018-10-31 Thread Moritz Mühlenhoff
On Mon, Oct 08, 2018 at 10:44:15PM +0200, Moritz Mühlenhoff wrote:
> On Tue, Aug 28, 2018 at 10:08:51AM +0300, Timo Jyrinki wrote:
> > Unfortunately upstream has removed the API that makes it possible to add
> > external spellcheckers, and the upstream selected library for
> > spellchecking is unable to properly support a language with a structure
> > of Finnish.
> > 
> > Currently there is no other option than to live without spell-checking
> > support in Mozilla products, and eg copy-paste to and back from a text
> > editor for spell checking. Or use a full Voikko library compiled into
> > Javascript with dependencies like at
> > https://www.puimula.org/htp/testing/js-libvoikko/js-libvoikko-demo.html
> 
> Let's remove mozvoikko from the archive, then?

Filed a removal bug as #912457.

Cheers,
Moritz



Bug#912457: RM: mozvoikko -- RoQA; broken with Firefox 57+

2018-10-31 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove mozvoikko, it's broken with current Firefox releases
as the necessary API got removed by Mozilla in the Quantum rearchitecture
efforts.

Cheers,
Moritz



Bug#912381: xen-utils-4.11: /usr/lib/xen-4.11/bin/pygrub is missing after upgrade from xen-utils-4.8

2018-10-31 Thread Hans van Kranenburg
On 10/31/2018 07:23 PM, Ian Jackson wrote:
>> I see that there's no /usr/lib/xen-4.11/bin/pygrub indeed, and that's
>> something that sounds wrong. Apparently, noone involved in helping
>> getting Xen 4.11 into Debian so far has been a pygrub user.
> 
> I swear I tested pygrub aftr making my renaming changes, but maybe
> only with the upstream tree.
> 
> I don't understand why it's not being built by the upstream build
> system.  That would be the first thing to look at.
> 
> Sorry for the lossage, but I can't conveniently invstigate now.
> 
>>> Traceback (most recent call last):
>>>   File "/usr/lib/xen-4.11/bin/pygrub", line 23, in 
>>>     import fsimage
>>> ImportError: No module named fsimage
>>
>> Ah, more regressions... The script is missing a patch to set the lib
>> directory in the path
> 
> No, this is simply because the library is renamed now to
> libxenfsimage.  The pygrub from 4.8 isn't compatible with the new
> library name.

xen-utils-4.11 has:

/usr/lib/xen-4.11/lib/python/fsimage.so

libxenmisc4.11 has:

/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/ext2fs-lib/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/fat/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/iso9660/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/reiserfs/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/ufs/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/xfs/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/fs/zfs/fsimage.so
/usr/lib/xen-4.11/lib/x86_64-linux-gnu/libfsimage.so

There is nothing called libxenfsimage in our packages?

But, I'll leave it alone for now, since I apparently don't fully know
what I'm talking about. :)

Hans



Bug#912456: imbalanced-learn FTBFS with scikit-learn 0.20.0

2018-10-31 Thread Adrian Bunk
Source: imbalanced-learn
Version: 0.3.3-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/imbalanced-learn.html

...
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd 
/build/1st/imbalanced-learn-0.3.3/.pybuild/cpython3_3.6_imbalanced-learn/build; 
python3.6 -m pytest 
= test session starts ==
platform linux -- Python 3.6.7, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /build/1st/imbalanced-learn-0.3.3, inifile: setup.cfg
plugins: doctestplus-0.1.3
collected 228 items / 2 errors

 ERRORS 
 ERROR collecting 
.pybuild/cpython3_3.6_imbalanced-learn/build/imblearn/tests/test_common.py 
imblearn/tests/test_common.py:6: in 
from sklearn.utils.testing import _named_check
E   ImportError: cannot import name '_named_check'
 ERROR collecting 
.pybuild/cpython3_3.6_imbalanced-learn/build/imblearn/tests/test_common.py 
ImportError while importing test module 
'/build/1st/imbalanced-learn-0.3.3/.pybuild/cpython3_3.6_imbalanced-learn/build/imblearn/tests/test_common.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
imblearn/tests/test_common.py:6: in 
from sklearn.utils.testing import _named_check
E   ImportError: cannot import name '_named_check'
!!! Interrupted: 2 errors during collection 
=== 2 error in 1.42 seconds 
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=2: cd 
/build/1st/imbalanced-learn-0.3.3/.pybuild/cpython3_3.6_imbalanced-learn/build; 
python3.6 -m pytest 
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.6 returned 
exit code 13
make: *** [debian/rules:5: build] Error 25



Bug#912454: gocryptfs: new upstream release

2018-10-31 Thread Drew Parsons
Package: gocryptfs
Version: 1.4.3-7
Severity: normal

The latest upstream release is 1.6.  For cryptographic software like
this I figure it's important to keep up-to-date, especially with the
fsck functions and other features in 1.5.  Is it straightforward to
package the new version?

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

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

Versions of packages gocryptfs depends on:
ii  libc6  2.27-6
ii  libfuse2   2.9.8-2
ii  libssl1.1  1.1.1-1

gocryptfs recommends no packages.

gocryptfs suggests no packages.

-- no debconf information



Bug#912455: istack-commons FTBFS with OpenJDK 11

2018-10-31 Thread Adrian Bunk
Source: istack-commons
Version: 3.0.6-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/istack-commons.html

...
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/build/1st/istack-commons-3.0.6/istack-commons/runtime/src/main/java/module-info.java:[44,29]
 module not found: java.activation
[INFO] 1 error



Bug#912453: sndio: Please set SONAME on !linux

2018-10-31 Thread Dmitry Shachnev
Source: sndio
Version: 1.5.0-2
Severity: important
Control: affects -1 src:openal-soft

Dear maintainer,

Currently the configure script sets SONAME on Linux but not on Hurd or
GNU/kFreeBSD:

https://sources.debian.org/src/sndio/1.5.0-2/configure/#L56

Please update debian/patches/uname-check.patch to set so_ldflags on those
platforms too.

This currently causes issues with openal-soft, where dpkg-shlibdeps fails to
generate a proper dependency on libsndio7.0 because of this.

--
Dmitry Shachnev



signature.asc
Description: PGP signature


Bug#912381: xen-utils-4.11: /usr/lib/xen-4.11/bin/pygrub is missing after upgrade from xen-utils-4.8

2018-10-31 Thread Ian Jackson
> >> >> I see that there's no /usr/lib/xen-4.11/bin/pygrub indeed, and that's
> >> >> something that sounds wrong. Apparently, noone involved in helping
> >> >> getting Xen 4.11 into Debian so far has been a pygrub user.

I swear I tested pygrub aftr making my renaming changes, but maybe
only with the upstream tree.

I don't understand why it's not being built by the upstream build
system.  That would be the first thing to look at.

Sorry for the lossage, but I can't conveniently invstigate now.

> > Traceback (most recent call last):
> >   File "/usr/lib/xen-4.11/bin/pygrub", line 23, in 
> >     import fsimage
> > ImportError: No module named fsimage
> 
> Ah, more regressions... The script is missing a patch to set the lib
> directory in the path

No, this is simply because the library is renamed now to
libxenfsimage.  The pygrub from 4.8 isn't compatible with the new
library name.

Ian.



Bug#858174: Please provide an AppArmor profile for Firefox

2018-10-31 Thread Vincas Dargis

On 2018-10-30 20:59, intrigeri wrote:

Vincas Dargis:

intrigeri, what is rationale for upping it to "normal"?


What do you mean? Today I merely tagged this bug "upstream".


Oh, sorry, right, it was changed from wishlist to normal in "Sun, 29 Oct 2017 11:21:06 GMT". I 
erroneously joined it with latest notification.




Bug#911925: openjdk-8-jdk: breaks maven-surefire-plugin (security-caused regression)

2018-10-31 Thread Thorsten Glaser
Dixi quod…

> > This is an intentional upstream change
> 
> Considering https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#38
> no, it isn’t, it’s supposed to default to disabled.

Which is probably the reason it works in OpenJDK 11, considering.
This answers a part of this mystery:

| Nevertheless, current OpenJDK 11 does *not* exhibit the
| bug (which was found out on IRC some days ago when I

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#912381: xen-utils-4.11: /usr/lib/xen-4.11/bin/pygrub is missing after upgrade from xen-utils-4.8

2018-10-31 Thread Hans van Kranenburg
On 10/31/2018 07:16 PM, Hans van Kranenburg wrote:
> Hi,
> 
> On 10/31/2018 05:51 PM, Dimitar Angelov wrote:
>> On Wed, 31 Oct 2018 17:13:10 +0100 Hans van Kranenburg
>>  wrote:
>>> On 10/31/2018 08:49 AM, Dimitar Angelov wrote:
 On Wed, 31 Oct 2018 00:47:46 +0100 Hans van Kranenburg
  wrote:
> Hi,
>
> I see that there's no /usr/lib/xen-4.11/bin/pygrub indeed, and that's
> something that sounds wrong. Apparently, noone involved in helping
> getting Xen 4.11 into Debian so far has been a pygrub user.
>
> So... thanks for reporting, and thanks for trying out the new
>>> packages.
>
> I suspect it's rather obvious there's a problem, since there's no
>>> pygrub
> file at all, so we have to find out why and how it can be fixed.
>
> Missing pygrub stops booting paravirtualized Debian guests with
 grub-legacy.
 Can you suggest how to workaround?
>>>
>>> The quickest way, for now, would be to get it from the source package,
>>> and put the pygrub file from it in /usr/lib/xen-4.11/bin:
>>>
>>> https://sources.debian.org/data/main/x/xen/4.11.1~pre.20180911.5acdd26fdc+dfsg-5/tools/pygrub/src/pygrub
>>
>> Thank you for reply.
>> I've copied pygrub from source package to /usr/lib/xen-4.11/bin, but now
>> receive following error:
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/xen-4.11/bin/pygrub", line 23, in 
>>     import fsimage
>> ImportError: No module named fsimage
> 
> Ah, more regressions... The script is missing a patch to set the lib
> directory in the path
> 
> In 4.8, it has a line...
>   sys.path.insert(1, sys.path[0] + '/../lib/python')
> ...which is missing now. That patch was lost somewhere apparently.

Oh no, duh, it's not in the file in the source package, obviously, heh.

Still, it's missing in the packaging it seems.

It was at the end of
  debian/patches/prefix-abiname/tools-pygrub-prefix.diff
before.

That file got removed in commit 0a18352eb, and the sys.path line didn't
return in any other place in a patch.

I just added a patch back for it.

> But even then, it fails:
> 
> dom0:/usr/lib/xen-4.11/bin -# python
> Python 2.7.15+ (default, Aug 31 2018, 11:56:52)
> [GCC 8.2.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import fsimage
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named fsimage
 import sys
 sys.path
> ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu',
> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
> '/usr/lib/python2.7/lib-dynload',
> '/usr/local/lib/python2.7/dist-packages',
> '/usr/lib/python2.7/dist-packages']
 sys.path.insert(1, '/usr/lib/xen-4.11/lib/python')
 import fsimage
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: libfsimage.so: cannot open shared object file: No such file
> or directory
> 
> I guess this is because of renaming of fsimage -> libfsimage that has
> been going on? Ian?
> 
>  >8 
> 
> An alternative that might help you now might be to switch to pvgrub2?
> 
> https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/
> 
> Search for "Debian" in that page to find pointers to the grub-xen packages.
> 
>> I also can mention something other, when creating PV VM using
>> xen-create-image it reports:
>> warning: something called deprecated script
>> /usr/lib/xen-common/bin/xen-toolstack
>>
>>
>> The command is:
>> xen-create-image \
>>    --hostname=test2 --memory=1gb -vcpus=1 \
>>    --lvm=vg0 --size=10gb --noswap \
>>    --pygrub \
>>    --fs=ext4 \
>>    --dist=stretch \
>>    --role=udev \
>>    --gateway=10.10.10.1 --ip=10.10.10.12 --netmask=255.255.254.0 \
>>    --bridge=xenbr0 \
> 
> /usr/lib/xen-common/bin/xen-toolstack is a helper script that returned
> either 'xm' or 'xl' in the past. The xm toolstack is long gone now, and
> xl is the only choice. That message is harmless, and it points out that
> xen-create-image needs to be changed to just use xl.
> 
> This should be in a separate bug against the xen-tools package. I'll
> file it, thanks for reporting.
> 
> Hans
> 



Bug#912381: xen-utils-4.11: /usr/lib/xen-4.11/bin/pygrub is missing after upgrade from xen-utils-4.8

2018-10-31 Thread Hans van Kranenburg
Hi,

On 10/31/2018 05:51 PM, Dimitar Angelov wrote:
> On Wed, 31 Oct 2018 17:13:10 +0100 Hans van Kranenburg
>  wrote:
>> On 10/31/2018 08:49 AM, Dimitar Angelov wrote:
>> > On Wed, 31 Oct 2018 00:47:46 +0100 Hans van Kranenburg
>> >  wrote:
>> >> Hi,
>> >>
>> >> I see that there's no /usr/lib/xen-4.11/bin/pygrub indeed, and that's
>> >> something that sounds wrong. Apparently, noone involved in helping
>> >> getting Xen 4.11 into Debian so far has been a pygrub user.
>> >>
>> >> So... thanks for reporting, and thanks for trying out the new
>> packages.
>> >>
>> >> I suspect it's rather obvious there's a problem, since there's no
>> pygrub
>> >> file at all, so we have to find out why and how it can be fixed.
>> >>
>> > > Missing pygrub stops booting paravirtualized Debian guests with
>> > grub-legacy.
>> > Can you suggest how to workaround?
>>
>> The quickest way, for now, would be to get it from the source package,
>> and put the pygrub file from it in /usr/lib/xen-4.11/bin:
>>
>> https://sources.debian.org/data/main/x/xen/4.11.1~pre.20180911.5acdd26fdc+dfsg-5/tools/pygrub/src/pygrub
> 
> Thank you for reply.
> I've copied pygrub from source package to /usr/lib/xen-4.11/bin, but now
> receive following error:
> 
> Traceback (most recent call last):
>   File "/usr/lib/xen-4.11/bin/pygrub", line 23, in 
>     import fsimage
> ImportError: No module named fsimage

Ah, more regressions... The script is missing a patch to set the lib
directory in the path

In 4.8, it has a line...
  sys.path.insert(1, sys.path[0] + '/../lib/python')
...which is missing now. That patch was lost somewhere apparently.

But even then, it fails:

dom0:/usr/lib/xen-4.11/bin -# python
Python 2.7.15+ (default, Aug 31 2018, 11:56:52)
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fsimage
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named fsimage
>>> import sys
>>> sys.path
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu',
'/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages']
>>> sys.path.insert(1, '/usr/lib/xen-4.11/lib/python')
>>> import fsimage
Traceback (most recent call last):
  File "", line 1, in 
ImportError: libfsimage.so: cannot open shared object file: No such file
or directory

I guess this is because of renaming of fsimage -> libfsimage that has
been going on? Ian?

 >8 

An alternative that might help you now might be to switch to pvgrub2?

https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/

Search for "Debian" in that page to find pointers to the grub-xen packages.

> I also can mention something other, when creating PV VM using
> xen-create-image it reports:
> warning: something called deprecated script
> /usr/lib/xen-common/bin/xen-toolstack
> 
> 
> The command is:
> xen-create-image \
>    --hostname=test2 --memory=1gb -vcpus=1 \
>    --lvm=vg0 --size=10gb --noswap \
>    --pygrub \
>    --fs=ext4 \
>    --dist=stretch \
>    --role=udev \
>    --gateway=10.10.10.1 --ip=10.10.10.12 --netmask=255.255.254.0 \
>    --bridge=xenbr0 \

/usr/lib/xen-common/bin/xen-toolstack is a helper script that returned
either 'xm' or 'xl' in the past. The xm toolstack is long gone now, and
xl is the only choice. That message is harmless, and it points out that
xen-create-image needs to be changed to just use xl.

This should be in a separate bug against the xen-tools package. I'll
file it, thanks for reporting.

Hans



Bug#911670: php-igbinary only comes with a module for PHP 7.3, making it unusable with the buster default PHP 7.2

2018-10-31 Thread Ondřej Surý
PHP 7.2 had been removed from Debian unstable and it will go from testing as 
soon as the transition is complete.

NextCloud is not available from Debian, but generally speaking, if you want a 
stable distribution then you need to use Debian stable.

Ondrej
--
Ondřej Surý 

> On 31 Oct 2018, at 17:58, Veilleux, Anthony  wrote:
> 
> There are use cases for which PHP 7.3 is not acceptable, such as applications 
> that we don't have control over failing to support PHP 7.3 (in my personal 
> case, NextCloud Stable). Is there a compelling reason not to compile 
> php7.X-igbinary packages to support these use cases, like many other modules 
> do?
> 
> 
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine 
> at
> http://www.partners.org/complianceline . If the e-mail was sent to you in 
> error
> but does not contain patient information, please contact the sender and 
> properly
> dispose of the e-mail.
> 



Bug#867719: phpldapadmin: CVE-2017-11107

2018-10-31 Thread Antoine Beaupre
Control: tags 867719 +patch

The attached patch fixes the issue and was applied to the wheezy and
jessie versions of the package.

It comes from the Ubuntu version of this same bug:

https://bugs.launchpad.net/ubuntu/+source/phpldapadmin/+bug/1701731
--- phpldapadmin-1.2.2.orig/htdocs/entry_chooser.php
+++ phpldapadmin-1.2.2/htdocs/entry_chooser.php
@@ -15,9 +15,9 @@ $www['page'] = new page();
 
 $request = array();
 $request['container'] = get_request('container','GET');
-$request['form'] = get_request('form','GET');
-$request['element'] = get_request('element','GET');
-$request['rdn'] = get_request('rdn','GET');
+$request['form'] = htmlspecialchars(addslashes(get_request('form','GET')));
+$request['element'] = htmlspecialchars(addslashes(get_request('element','GET')));
+$request['rdn'] = htmlspecialchars(addslashes(get_request('rdn','GET')));
 
 echo '';
 printf('%s',_('Entry Chooser'));
@@ -33,7 +33,7 @@ echo '';
 echo '';
 if ($request['container']) {
 	printf('%s:%s',_('Server'),$app['server']->getName());
-	printf('%s:%s',_('Looking in'),$request['container']);
+	printf('%s:%s',_('Looking in'),htmlspecialchars($request['container']));
 	echo '';
 }
 


signature.asc
Description: PGP signature


Bug#912452: zenmap: too strict dependency on policykit-1

2018-10-31 Thread Samuel Henrique
Hello Reiner,

Initially I thought it was better to add is a Dependency by the following
Policy text:
"The Depends field should be used if the depended-on package is required
for the depending package to provide a significant amount of functionality."

I assume that as zenmap is a graphical tool, people will mainly start it
from a DE, using the desktop file, and in order for that to work users will
need polkit.

Previous version were working for you because you either already had the
menu package installed (which was a non-declared depends/recommends, this
was fixed along with the polkit transition #890728) or you started zenmap
from the terminal as root.

I didn't realize polkit was dependent of systemd, but I just would like to
make sure with the rest of the team that we can put polkit in Recommends
even if it breaks the desktop file for zenmap as root.

Thanks for reporting

-- 
Samuel Henrique 


Bug#402847: Probably a good idea

2018-10-31 Thread Jesse Smith
This report seems to make sense, the suggested change would probably
give cleaner output, if I'm reading the documentation in stty's man page
correctly.

Before I apply this change upstream, is there any reason (backward
compatibility for example) not to do this?

- Jesse



Bug#912443: cmake: Generates wrong link flags on hurd-i386

2018-10-31 Thread Brad King
On Wed, 31 Oct 2018 19:05:55 +0300 Dmitry Shachnev wrote:
> Such a flag is a problem when the referenced .so file is actually a symlink.
> GCC does not resolve it and generates a dependency literally on libsndio.so.

Linking a library by absolute path is okay (and preferred) if the library
has a proper SONAME.  What is the output of

$ readelf -d /usr/lib/i386-gnu/libsndio.so | grep SONAME

?  On x86_64 libsndio.so has a proper soname:

0x000e (SONAME) Library soname: [libsndio.so.7.0]

-Brad



Bug#912452: zenmap: too strict dependency on policykit-1

2018-10-31 Thread Reiner Herrmann
Package: zenmap
Version: 7.70+dfsg1-4
Severity: important

Dear Maintainer,

in the new version of zenmap you added a dependency [0] on policykit-1,
which has been a recommendation before.
Unfortunately there is no reason mentioned in the commit or changelog
why this new dependency is needed.
Zenmap is working very well for me without it, so I think it should be
downgraded to a recommendation.

Otherwise zenmap is no longer installable on SysV systems:

# apt install zenmap
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libpam-systemd libpolkit-agent-1-0 libpolkit-backend-1-0 
libpolkit-gobject-1-0 policykit-1 systemd systemd-sysv
Suggested packages:
  systemd-container
Recommended packages:
  libnss-systemd python-pysqlite2
The following packages will be REMOVED:
  sysvinit-core
The following NEW packages will be installed:
  libpam-systemd libpolkit-agent-1-0 libpolkit-backend-1-0 
libpolkit-gobject-1-0 policykit-1 systemd systemd-sysv
  zenmap
0 upgraded, 8 newly installed, 1 to remove and 0 not upgraded.


Kind regards,
   Reiner

[0] https://salsa.debian.org/pkg-security-team/nmap/commit/a04c08c


signature.asc
Description: PGP signature


Bug#839180: localehelper: alternative dependency on locales-all

2018-10-31 Thread Jakub Wilk

Control: found -1 0.1.4-3

localehelper still depends on locales without alternative:

  $ grep-aptavail -s Package,Version,Depends localehelper
  Package: localehelper
  Version: 0.1.4-3
  Depends: locales, perl:any

--
Jakub Wilk



Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment

2018-10-31 Thread Lorenz
On Thu, 20 Sep 2018 18:44:16 + Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:
> Hi Ian,
>
> On  Do 20 Sep 2018 16:45:41 CEST, Ian Jackson wrote:
>
> > Mike Gabriel writes ("Re: Bug#909192: mate-desktop-environment:
> > Installing sysvinit-core removes mate-desktop-environment"):
> >> many thanks for all this background info. I might have a potential
> >> contract to get this solved in the loop, so, I may probably return to
> >> it soon (or not so soon). Let's see...
> >
> > Can you let us know when you will know whether this is going to
> > transpire ?
>
> This is not going to be a paid project, unfortunately, as I hoped.
>
> > Also, we had an IRC conversation on #debian-devel about pam_systemd
> > and the dbus user service.  I think it contains a lot of useful
> > information particularly from smcv.  See below.
> >
> > This is a transcript of #debian-devel manually edited to remove other
> > conversations, and also to remove unconstructive comments (of which
> > unfortunately there were some).
>
> Thanks for the transcript.
>
> I'll have this on my radar as an RC-like bug on the MATE side and take
> a look later in October / November (when back from VAC). If noone else
> has addressed it by then.
>
> Mike
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, herweg 7, 24357 fleckeby
> mobile: +49 (1520) 1976 148
> landline: +49 (4354) 8390 139
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>

Hi,
i think this

> mate-desktop-environment -> mate-desktop-environment-core ->
> dconf-settings-backend -> dconf-service -> default-dbus-session-bus
> -> dbus-user-session -> systemd

is not what is pulling in systemd as init; in fact the chain could be also

mate-desktop-environment -> mate-desktop-environment-core ->
dconf-settings-backend -> dconf-service -> default-dbus-session-bus ->
dbus-x11 and dbus-x11

and dbus-x11 does not require systemd nor pam-systemd
see here  https://packages.debian.org/sid/dconf-service

Please look at the list of packages from the bug reporter that apt wants to
remove:

>The following packages will be REMOVED:
>  caja colord dbus-user-session gvfs gvfs-backends gvfs-daemons kcalc kgamma5 
> kio libkf5auth5 libkf5configwidgets5 libkf5iconthemes-bin libkf5iconthemes5 
> libkf5kiocore5 libkf5kiowidgets5
>  libkf5notifyconfig5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5 
> libpam-systemd libpolkit-qt5-1-1 lightdm mate-applet-brisk-menu mate-applets 
> mate-control-center
>  mate-desktop-environment mate-desktop-environment-core mate-panel 
> mate-polkit mate-power-manager mate-settings-daemon network-manager 
> network-manager-fortisslvpn
>  network-manager-fortisslvpn-gnome network-manager-gnome network-manager-l2tp 
> network-manager-l2tp-gnome policykit-1 quassel-client rtkit synaptic 
> systemd-sysv task-mate-desktop udisks2

the chain wich is pulling in systemd as init is the fact that the shim is
rc-buggy combined with
consolekit being removed from archives, and that leave no other options to
polkit that depend on systemd as init.
This makes this bug not Mate-specific, as every DE that has a polkit
authentication agent will soon have the same problem.

The only thing that could be asked to the Mate Team, once (if?) elogind
gets packaged for Debian, is to turn the
mate-power-manager dependency from
' systemd | consolkit'
into
'systemd| libpam-elogind | consolkit '

Best Regards,
Lorenzo


  1   2   3   >