Bug#895068: freecad does not start : "Illegal Instruction" returned

2018-04-06 Thread Adrian Bunk
Control: reassign -1 src:xerces-c 3.1.4+debian-2
Control: retitle -1 xerces-c: baseline violation on i386
Control: affects -1 freecad

On Sat, Apr 07, 2018 at 12:30:26AM +0200, Giuliano Cabrele wrote:
> Package: freecad
> Version: 0.16+dfsg2-3
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> A freshly installed Freecad did not start when launched from Xfce desktop.
> Trying to start from terminal produced the warning "Illegal Instruction" and 
> stop of the program.  
> The dmsg returns just a line:
> traps: freecad[12387] trap invalid opcode ip:b651da3d sp:bf9062e8 error:0
>   in libxerces-c-3.1.so[b62ab000+34a000].
> Thanks for the attention
>...

Thanks for your report, the root cause is that the --disable-sse2 was 
lost at some point in xerces-c, and the packages in stable and unstable
are therefore violating the i386 baseline due to using SSE2.

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#895044: [debhelper-devel] Bug#895044: debhelper: add support for Ninja with CMake

2018-04-06 Thread Niels Thykier
Control: tags -1 pending

Kyle Edwards:
> [...]
> 
> Just tested it, and I like it.
> 

Thanks. :)

I am glad it worked. :)

> One thing I did notice is that if your project doesn't have tests, you
> have to turn on nocheck when switching to cmake+ninja, because the ninja
> buildsystem fails if no "test" target exists (the makefile buildsystem
> seems to silently ignore the failure.) I don't think this is a
> deal-breaker, but it is something to keep in mind when switching to
> ninja. Perhaps this could be filed as a separate bug.
> 

Mmm, the reason why make does not fail is that we have a crude (but
functional) way to tell if a makefile target exists.  But we do not have
that for ninja and honestly, I have no idea how we would make it either.

If you have an idea, I would be happy to look at implementing it.

> Thank you for the quick response! I hope to see this in debhelper soon.
> 
> Kyle

Indeed; merged for debhelper 11.2.

Thanks,
~Niels



Bug#895105: fontforge-extras: Please remove myself from Uploaders

2018-04-06 Thread Christian Perrier
Package: fontforge-extras
Severity: minor

I'm not sure that this package is still useful.however, it it
still in unstable, as far as I can see though it hasn't got uploads
for years.

In any case, if it's not removed from unstable, please remove my name
from Uploaders as part of my "prepare to resign some day" work (sorry
for this).


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
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/bash
Init: systemd (via /run/systemd/system)



Bug#895005: procps: init script ignores local (all?) configuration

2018-04-06 Thread GSR
Package: procps
Version: 2:3.3.13-1
Followup-For: Bug #895005
Tags: patch

Hi again:

I think I found the issue, and some extras. Please see attached diff,
the important part is the last exit 0 that broke the sourcing done in
init-d-script. I also removed the useless check (that other script
checks if DAEMON is set and executable) and fixed QUIENT typo and the
function redefinitions.

Tested all commands avaliable in usage info (start, stop, status,
restart, try-restart, force-reload), all them work (ok or silent), but
try-restart prints things poorly (making status function return 1
makes thing look better but report "fail", which is probably worse).

I believe the QUIET_SYSCTL line and comment above it could become a
file named /etc/defaults/procps, init-d-script should take care of
including it.

Thanks,
GSR
 
--- procps	2018-04-07 04:01:42.155079422 +0200
+++ /etc/init.d/procps	2018-04-07 04:02:57.744576691 +0200
@@ -21,14 +21,20 @@
 DAEMON=/sbin/sysctl
 PIDFILE=none
 
+
+test -x $SYSCTL || exit 0
+
 # Comment this out for sysctl to print every item changed
 QUIET_SYSCTL="-q"
 
 do_start_cmd() {
 	STATUS=0
-	$DAEMON $QUIET_SYSCTL --system || STATUS=$?
+	$DAEMON $QUIENT_SYSCTL --system || STATUS=$?
 	return $STATUS
 }
 
-do_stop() { return 0; }
-do_status() { return 0; }
+do_stop() {}
+do_stop_cmd() {}
+do_status() {}
+
+exit 0


Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

2018-04-06 Thread Salvatore Bonaccorso
Hi Felix,

On Fri, Apr 06, 2018 at 09:40:40PM +0200, Felix Natter wrote:
> hello Security Team,
> 
> here are the CVE-2018-169 security updates for jessie and stretch:
> 
> [jessie]
> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=jessie-CVE-2018-169
> (jessie-CVE-2018-169 branch)
> 
> [stretch]
> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169
> (stretch-CVE-2018-169 branch)
> 
> Both are tested:
> - builds
> - activation log message is seen
> - Save and Load XML works
> 
> In what format would you like the "tested packages"? *.deb?
> 
> Here is the corrsponding upstream commit:
> https://github.com/freeplane/freeplane/commit/a5dce7f9f
> 
> The debdiffs are attached.

Thanks, I will try to review and ack those over this weekend. Thanks a
lot for your both work.

Reegarding the question:

Regarding: 

> In what format would you like the "tested packages"? *.deb?

That's not needed. We just have the requirement that the debdiff
should be the resulting one from the packages in the archive against
the built and tested packages, the later for obvious reason that we
want some assurance the packages have been tested to work.

The debdiff requirement (rather than only VCS commits) is to avoid
surprises on the actual result which will be uploaded to the archive
rather than just a series of commit in the packaging repos to be
reviewed.

Regards,
Salvatore



Bug#895104: why3: skip cvc4 autopkgtest on architectures without cvc4

2018-04-06 Thread Steve Langasek
Package: why3
Version: 0.88.3-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Dear Ralf,

In addition to bug #895103, the why3 autopkgtests also fail on non-x86
architectures in Ubuntu because the test dependencies for the why3+cvc4 test
cannot be satisfied.  The attached patch makes the test dependency
architecture-specific and lets it pass as a no-op on architectures without
cvc4.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru why3-0.88.3/debian/tests/control why3-0.88.3/debian/tests/control
--- why3-0.88.3/debian/tests/control2018-03-22 23:20:30.0 -0700
+++ why3-0.88.3/debian/tests/control2018-04-06 18:31:42.0 -0700
@@ -5,7 +5,7 @@
 Depends: why3, cvc3
 
 Tests: why3+cvc4
-Depends: why3, cvc4
+Depends: why3, cvc4 [any-amd64 any-i386 mips mips64el mipsel]
 
 Tests: why3+spass
 Depends:why3, spass
diff -Nru why3-0.88.3/debian/tests/why3+cvc4 why3-0.88.3/debian/tests/why3+cvc4
--- why3-0.88.3/debian/tests/why3+cvc4  2018-01-14 05:52:54.0 -0800
+++ why3-0.88.3/debian/tests/why3+cvc4  2018-04-06 18:32:34.0 -0700
@@ -2,6 +2,15 @@
 
 set -e
 
+case $(dpkg --print-architecture) in
+amd64|i386|hurd-i386|kfreebsd-amd64|kfreebsd-i386|mips|mips64el|mipsel)
+;;
+*)
+echo "SKIPPED cvc4 not available on this architecture"
+exit 0
+;;
+esac
+
 indir=debian/tests/why
 why3 config --detect-provers > /dev/null 2>&1
 for infile in $indir/*.mlw


Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable

2018-04-06 Thread Scott Talbert

On Sat, 7 Apr 2018, Norbert Lange wrote:


it appears that the files are installed in a subdirectory,
potentially to avoid confligs with previous versions?
result is that

import wx fails with

ImportError: No module named wx

I havent found a way to configure the installation


The purpose of the python-wxgtk4.0 package is primarily for application 
developers to use in porting their applications to wxPython 4.0 (Phoenix). 
There isn't much of a reason otherwise to use the Python 2 version of 
wxPython 4.0.  Instead, you should use python3-wxgtk4.0 with which you can 
'import wx'.


If you really would like to use the Python 2 version, you can do:

PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg
 python
import wx

Scott



Bug#895103: why3 server broken on multiple architectures

2018-04-06 Thread Steve Langasek
Package: why3
Version: 0.88.3-1
Severity: grave
Tags: patch
Justification: renders package unusable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Dear Ralf,

The 0.88.3 version of why3 has been blocked for a while from being included
in the upcoming Ubuntu 18.04 release due to failing autopkgtests on multiple
architectures, e.g.:

autopkgtest [08:58:21]: test why3+alt-ergo: [---
client_connect: connection failed: Connection refused (connect,) 
(socket_name=/tmp/why3server3f8c61sock)
autopkgtest [08:58:57]: test why3+alt-ergo: ---]
why3+alt-ergoFAIL non-zero exit status 1

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/w/why3/20180405_094212_aa650@/log.gz

I finally had a chance to track this down, and it turns out why3 0.88.3 is
completely broken upstream on various architectures (arm64, armhf, ppc64el,
and s390x, at least) due to wrong handling of return values from
getopt_long() that prevents why3-server from ever starting.

This issue was not seen in Debian's automated test runs because Debian only
runs autopkgtests for amd64: https://ci.debian.net/packages/w/why3/ but in
any case this would not have prevented the why3 package from being broken in
Debian testing because Debian unfortunately does not gate testing on
autopkgtest failures.

The attached patch fixes the trivial portability issue in why3, and as seen
at http://autopkgtest.ubuntu.com/packages/w/why3 the tests are now passing
for 0.88.3 on all architectures where they previously passed.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru why3-0.88.3/debian/patches/portable-getopt.patch 
why3-0.88.3/debian/patches/portable-getopt.patch
--- why3-0.88.3/debian/patches/portable-getopt.patch1969-12-31 
16:00:00.0 -0800
+++ why3-0.88.3/debian/patches/portable-getopt.patch2018-04-06 
17:22:54.0 -0700
@@ -0,0 +1,19 @@
+Description: fix unportable assumptions in getopt_long() handling
+ Don't store an int in a char and expect comparison to -1 to work across
+ architectures.
+Author: Steve Langasek 
+Last-Modified: 2018-04-06
+
+Index: why3-0.88.3/src/server/options.c
+===
+--- why3-0.88.3.orig/src/server/options.c
 why3-0.88.3/src/server/options.c
+@@ -30,7 +30,7 @@ void parse_options(int argc, char **argv
+   };
+   while (1) {
+  int option_index = 0;
+- char c = 0;
++ int c = 0;
+  c = getopt_long (argc, argv, "j:s:",
+   long_options, _index);
+  /* Detect the end of the options. */
diff -Nru why3-0.88.3/debian/patches/series why3-0.88.3/debian/patches/series
--- why3-0.88.3/debian/patches/series   2018-01-14 14:46:38.0 -0800
+++ why3-0.88.3/debian/patches/series   2018-04-06 17:20:54.0 -0700
@@ -0,0 +1 @@
+portable-getopt.patch


Bug#895102: colord: postinst script fails with "adduser: Only one or two names allowed"

2018-04-06 Thread Lars Kruse
Package: colord
Version: 1.3.3-2
Severity: normal

Dear Maintainer,

after installing the colord package (1.3.3-2), I received the following
error message:

 Setting up colord (1.3.3-2) ...
 adduser: Only one or two names allowed.
 dpkg: error processing package colord (--configure):
  installed colord package post-installation script subprocess returned error 
exit status 1
 dpkg: dependency problems prevent configuration of gnome-control-center:
   gnome-control-center depends on colord (>= 0.1.30); however:
 Package colord is not configured yet.

The following lines of the postinst script seem to be the problem:

 adduser --system --group --home /var/lib/colord colord \
 --quiet --gecos "colord colour management daemon"

Here the username "colord" is given somewhere between the other
arguments.
The manpage of colord documents, that the username should be the last
argument.

Indeed, the following call works ("colord" moved to the end of the
second line):

 adduser --system --group --home /var/lib/colord \
 --quiet --gecos "colord colour management daemon" colord

Cheers,
Lars



Bug#890521: mate-panel: Wrong behavior for drawer applet

2018-04-06 Thread Ernesto Domato
Package: mate-panel
Followup-For: Bug #890521

Hi,

I just want to let you know that this issue seems to be fixed with this 
release. So you can close this bug.

Thanks for all.
Ernesto

-- 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.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-2
ii  libcairo21.15.10-2
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libdconf10.26.1-3
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-6
ii  libgtk-3-0   3.22.29-3
ii  libice6  2:1.0.9-2
ii  libmate-desktop-2-17 1.20.1-1
ii  libmate-menu21.20.0-2
ii  libmate-panel-applet-4-1 1.20.1-1
ii  libmateweather1  1.20.0-1
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  librsvg2-2   2.40.20-2
ii  libsm6   2:1.2.2-1+b3
ii  libstartup-notification0 0.12-5
ii  libwnck-3-0  3.24.1-2
ii  libx11-6 2:1.6.5-1
ii  libxau6  1:1.0.8-1+b2
ii  libxrandr2   2:1.5.1-1
ii  mate-desktop 1.20.1-1
ii  mate-menus   1.20.0-2
ii  mate-panel-common1.20.1-1
ii  mate-polkit  1.20.0-1
ii  menu-xdg 0.5

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information



Bug#894816: [mikutter] mikutter doesn't start with error

2018-04-06 Thread dai
Control: forwarded -1 https://github.com/ruby-gnome2/ruby-gnome2/issues/1154
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#895100: roundcube: Remove php-mcrypt dependent

2018-04-06 Thread John Wong
Package: roundcube
Version: 1.3.3+dfsg.1-2
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

Since php7.2 is the default debian's php's version, and php7.2 does not had 
php-mcrypt,
So, please remove php-mcrypt dependent.
Thanks.

*** End of the template - remove these template lines ***


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

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

Versions of packages roundcube depends on:
ii  dpkg1.19.0.5
pn  roundcube-core  

roundcube recommends no packages.

roundcube suggests no packages.



Bug#895099: Invalid TLS Certificate -> white page with no warning

2018-04-06 Thread 積丹尼 Dan Jacobson
Package: epiphany-browser
Version: 3.28.0.1-1

https://bugzilla.gnome.org/show_bug.cgi?id=794930 must be a Debian bug,
only seen on i386, not amd64. Please have a look.

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

Kernel: Linux 4.15.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages epiphany-browser depends on:
ii  dbus-x11 [dbus-session-bus]  1.13.2-1
ii  epiphany-browser-data3.28.0.1-1
ii  gsettings-desktop-schemas3.28.0-1
ii  iso-codes3.79-1
ii  libc62.27-3
ii  libcairo21.15.10-2
ii  libgcr-base-3-1  3.28.0-1
ii  libgcr-ui-3-13.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-6
ii  libgmp10 2:6.1.2+dfsg-3
ii  libgtk-3-0   3.22.29-3
ii  libhogweed4  3.4-1
ii  libicu57 57.1-9
ii  libjavascriptcoregtk-4.0-18  2.20.0-2
ii  libjson-glib-1.0-0   1.4.2-3
ii  libnettle6   3.4-1
ii  libnotify4   0.7.7-3
ii  libpango-1.0-0   1.42.0-1
ii  libsecret-1-00.18.6-1
ii  libsoup2.4-1 2.62.0-1
ii  libsqlite3-0 3.23.0-1
ii  libwebkit2gtk-4.0-37 2.20.0-2
ii  libxml2  2.9.7+dfsg-1

Versions of packages epiphany-browser recommends:
pn  browser-plugin-evince  
ii  ca-certificates20170717
pn  evince 
ii  libwebkit2gtk-4.0-37-gtk2  2.20.0-2
ii  yelp   3.28.0-1

epiphany-browser suggests no packages.

-- no debconf information



Bug#895098: RM: jhc/experimental -- RoQA; RC-buggy; FTBFS; unmaintained

2018-04-06 Thread dai
Package: ftp.debian.org
Severity: normal

Please remove src:jhc from archive.

I am a sponsor of jhc package [0] (not user).

It has RC bug [1] since 2015/7 that depends on REMOVED pacakges that
are libghc-hssyck-dev (REMOVED 2015/7) [2] and drift (REMOVED 2017/1) [3].

The maintainer of jhc package says he does not have time to fix them, maintain
it. Actually, he could do only initial uploading [0][4] and could not follow
new upstream releases [5].
I called for adoption of this to debian-haskell ML, but no response [6].

So, I request removal of jhc package as his delegate with his permission.

[0] https://tracker.debian.org/pkg/jhc
[1] https://bugs.debian.org/854136
[2] https://bugs.debian.org/792614
[3] https://bugs.debian.org/859484
[4] https://tracker.debian.org/news/410925
[5] http://repetae.net/dist/
[6] https://lists.debian.org/debian-haskell/2018/03/msg0.html
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#895032: RFS: deepin-music/3.1.8-1 [ITP]

2018-04-06 Thread Adam Borowski
On Fri, Apr 06, 2018 at 08:15:17PM +0800, Yanhao Mo wrote:
> * Package name: deepin-music
>   Version : 3.1.8-1
>   Upstream Author : Deepin Technology Co., Ltd.
> * URL : https://github.com/linuxdeepin/deepin-music
> * License : GPL-3+
>   Section : sound
> 
> It builds those binary packages:
> 
>   deepin-music - Awesome music player with brilliant and tweakful UI

Hi!
I'm afraid the copyright file lacks the vast majority of licenses and
copyright holders.  However, all parts not by Deepin are inside the vendor/
subdir, and don't seem to be used during the build (you properly use system
libraries instead of those so-called "convenience copies").

Thus, I think it'd be a lot better to, instead of painstakingly documenting
every bit in that dir, remove it (for example via "Files-Excluded" in the
watch file to automatically repack upstream tarballs).  This would also make
the Security Team like you a lot more, as such "convenience copies" make
their life hard as every problem requires searching the whole archive for
copies of a library that needs to be updated.  And these days, sometimes
packages get outright rejected, turning what used to be merely "best
practice" to fully mandatory.


The only other issue is a nitpick: the short description shouldn't be
capitalized unless you mean something named "Awesome".  You might also tone
down the wording a wee bit.

Looks good otherwise!


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄



Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

2018-04-06 Thread John Scott
Package: atril
Version: 1.20.0-1
Followup-For: Bug #895000

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am able to reproduce this with any PDF exactly as described.
Every time the stack trace is printed to the console, another
line like this becomes visible in dmesg:

segfault at bbadbeef ip 7fe2c127380c sp 7fffbe792a90 error 6 in 
libjavascriptcoregtk-4.0.so.18.7.8[7fe2c0466000+1063000]

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/2 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 atril depends on:
ii  atril-common 1.20.0-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  libatk1.0-0  2.28.1-1
ii  libatrildocument31.20.0-1
ii  libatrilview31.20.0-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libcaja-extension1   1.20.0-2
ii  libgail-3-0  3.22.29-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-4
ii  libgtk-3-0   3.22.29-2
ii  libice6  2:1.0.9-2
ii  libjavascriptcoregtk-4.0-18  2.20.0-2
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libsecret-1-00.18.6-1
ii  libsm6   2:1.2.2-1+b3
ii  libsoup2.4-1 2.62.0-1
ii  libwebkit2gtk-4.0-37 2.20.0-2
ii  libx11-6 2:1.6.5-1
ii  libxml2  2.9.4+dfsg1-6.1
ii  mate-desktop-common  1.20.0-1
ii  shared-mime-info 1.9-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages atril recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.6-2
ii  dbus-x11 [dbus-session-bus]   1.12.6-2
ii  gvfs  1.36.0-1

Versions of packages atril suggests:
ii  caja  1.20.0-2
ii  poppler-data  0.4.8-2
pn  unrar 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlrIHgYSHGpzY290dEBw
b3N0ZW8ubmV0AAoJEH1hRKYneTBy6S0IAJFobQOELgxsGe8K72e0kNuX5S6B0q3Z
U3UROLrKugCi5hRVNgbBqqLjQvdppg3coVv6ktcEGgR20UUuuNeV83w5P4MbJR0V
zp+8oveJg/ZSHVsK0DlQoTlUaGouCBGKvwEp2tb3tI+QfBkpV7DBWu9fwUQcIONJ
4mLMB0QQaobAnK5Jrq2OK1Lirf/j/IN1Qkbd1Vb9JyjODcHVvNygUXCvWKYT1zDH
yEBUUSwD2EOoWQyjgrIX/LhJ+kd37hjHjDqEko6CDKLWPoCflbcr4D5SYgHAtb+x
H65i6o0WIJeQvoeKwgiZohgQiOteOhkRWTpemotfXYnbzuybZCIqZIQ=
=eIvx
-END PGP SIGNATURE-



Bug#873581: fixed in python-certbot 0.20.0-3

2018-04-06 Thread Nye Liu
This bug should not have been closed. Log rotation does not fix the 
problem of certbot dumping tons of useless debug information into its logs.


It is inexcusable for an app that generates log files to not have a way 
to adjust log level.


https://github.com/certbot/certbot/issues/3481



Bug#895097: tracker.debian.org: doesn't show packages in backports-new in the version box

2018-04-06 Thread Mattia Rizzolo
Package: tracker.debian.org

SSIA


signature.asc
Description: PGP signature


Bug#704463: Buy and sell bitcoins near

2018-04-06 Thread emaily

buy and sell bitcoin near  
Join us for free
 
 

Bug#895096: debootstrap: -unpack-tarball option doesn't recognize tar.gz file

2018-04-06 Thread Hideki Yamane
package: debootstrap
severity: minor
tags: patch

Hi,

 --unpack-tarball option doesn't recognize tar.gz

> $ sudo debootstrap --unpack-tarball=/home/henrich/tmp/debootstrap.tar.gz sid 
> sid
> E: Unknown tarball: must be either .tar or .tgz


 And here's a proposed patch.
 
diff --git a/debootstrap b/debootstrap
index f67326c..1934f59 100755
--- a/debootstrap
+++ b/debootstrap
@@ -122,7 +122,7 @@ usage()
   --no-resolve-deps  don't try to resolve dependencies automatically
 
   --unpack-tarball=T acquire .debs from a tarball instead of http
-  --make-tarball=T   download .debs and create a tarball (tgz format)
+  --make-tarball=T   download .debs and create a tarball
   --second-stage-target=DIR
  Run second stage in a subdirectory instead of root
(can be used to create a foreign chroot)
@@ -577,10 +577,12 @@ if [ "$UNPACK_TARBALL" ]; then
fi
if [ "${UNPACK_TARBALL%.tar}" != "$UNPACK_TARBALL" ]; then
(cd "$TARGET" && tar -xf "$UNPACK_TARBALL")
+   elif [ "${UNPACK_TARBALL%.tar.[g|x]z}" != "$UNPACK_TARBALL" ]; then
+   (cd "$TARGET" && tar -xf "$UNPACK_TARBALL")
elif [ "${UNPACK_TARBALL%.tgz}" != "$UNPACK_TARBALL" ]; then
(cd "$TARGET" && zcat "$UNPACK_TARBALL" | tar -xf -)
else
-   error 1 NOTTAR "Unknown tarball: must be either .tar or .tgz"
+   error 1 NOTTAR "Unknown tarball: must be .tar.[gz,xz], .tar or 
.tgz"
fi
 fi



Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

2018-04-06 Thread Rogério Brito
Hi, Alex.

On Apr 06 2018, Alex ARNAUD wrote:
> Hello Rogério,
> 
> Could it be possible for you to provide us a PDF to help us to reproduce the
> issue?

Sure. One is attached here (just quickly created with latex), but the issue
happens with *any* PDF file that I tried (and I tried many) so far.

> > Do you have tried to check if "canberra-gtk-module" is installed?

Installing libcanberra-gtk3-module only makes the "Gtk-Message" thing go
away. The rest of the problem persists.


Thanks,

Rogério.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


test.pdf
Description: Adobe PDF document


Bug#894903: [Debian-med-packaging] Bug#894903: Bug#894903: please drop the runtime dependency on python3-distutils

2018-04-06 Thread Sascha Steinbiss
Hi,

>>> please drop the runtime dependency on python3-distutils, it's not needed 
>>> anymore.
>>> 
>>> http://launchpadlibrarian.net/363367629/ariba_2.11.0+ds-2_2.11.1+ds-2ubuntu1.diff.gz
>> 
>> I admit I do not understand in how far this patch would change anything
>> on thd distutils runtime dependency that was just added.  Sascha, could
>> you please comment on this?
> 
> Not sure about the patch either. But I'll look into removing the
> dependency if it's unnecessary.

Well, if I remove the dependency, then the test still fails with:

autopkgtest [02:21:49]: test test-example: [---
Traceback (most recent call last):
  File "/usr/bin/ariba", line 3, in 
import ariba
  File "/usr/lib/python3/dist-packages/ariba/__init__.py", line 56, in 
from ariba import *
  File "/usr/lib/python3/dist-packages/ariba/mic_plotter.py", line 8, in 

import matplotlib
  File "/usr/lib/python3/dist-packages/matplotlib/__init__.py", line 110, in 

import distutils.sysconfig
ModuleNotFoundError: No module named 'distutils.sysconfig'
autopkgtest [02:21:50]: test test-example: ---]
autopkgtest [02:21:50]: test test-example:  - - - - - - - - - - results - - - - 
- - - - - -
test-example FAIL non-zero exit status 1
autopkgtest [02:21:50]:  summary
test-example FAIL non-zero exit status 1

…again, due to a missing distutils. Did I miss something?

Cheers
Sascha



signature.asc
Description: Message signed with OpenPGP


Bug#895095: Acknowledgement (Migrate from SVN repository to git on salsa)

2018-04-06 Thread Julian Rüth
Sorry for the noise. This bug can be closed again. I had not known about
https://salsa.debian.org/python-team/applications/cython.



Bug#895095: Migrate from SVN repository to git on salsa

2018-04-06 Thread Julian Rüth
Package: cython
Version: 0.26-2

Debian's Cython repository should probably migrate from SVN to git. I
gave the migration a try here:
https://salsa.debian.org/saraedum-guest/cython

I tried to get the authors in the commit history right and migrate all
tags/branches following the guide at https://wiki.debian.org/Alioth/Git.
There were no errors during migration. Please let me know if you think
that something does not look right.



Bug#893355: Pending fixes for bugs in the maven-processor-plugin package

2018-04-06 Thread pkg-java-maintainers
tag 893355 + pending
thanks

Some bugs in the maven-processor-plugin package are closed in
revision 91b1d597207c0ff5470e0db5ccf9f0e7cf7e41db in branch 'master'
by Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/maven-processor-plugin.git/commit/?id=91b1d59

Commit message:

Fixed the build failure with Java 9 (Closes: #893355)



Bug#884947:

2018-04-06 Thread Yorik van Havre
This bug depends on #874727
Sorry, I don't know a better way to mark/inform that here...

Cheers
Yorik


Bug#894789: tightvnc-java: FTBFS with openjdk-9

2018-04-06 Thread Emmanuel Bourg
Control: tags -1 + patch

Here is a patch fixing this issue.
--- a/Makefile
+++ b/Makefile
@@ -22,12 +22,12 @@
  SocketFactory.java HTTPConnectSocketFactory.java \
  HTTPConnectSocket.java ReloginPanel.java
 
-OPTS = -source 1.3
+OPTS = -source 1.8
 
 all: $(CLASSES) $(ARCHIVE)
 
 $(CLASSES): $(SOURCES)
-   $(JC) -target 1.1 $(OPTS) -O $(SOURCES)
+   $(JC) -target 1.8 $(OPTS) -O $(SOURCES)
 
 $(ARCHIVE): $(CLASSES) $(MANIFEST)
$(JAR) cfm $(ARCHIVE) $(MANIFEST) $(CLASSES)


Bug#895083: python-wxgtk4.0: module wx is not usable

2018-04-06 Thread Norbert Lange
Package: python-wxgtk4.0
Version: 4.0.1+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

it appears that the files are installed in a subdirectory,
potentially to avoid confligs with previous versions?
result is that 

import wx fails with 

ImportError: No module named wx

I havent found a way to configure the installation

Regards,
Norbert Lange 


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

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

Versions of packages python-wxgtk4.0 depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8-20180321-1
ii  libpython2.7  2.7.14-7
ii  libstdc++68-20180321-1
ii  libwxbase3.0-0v5  3.0.4+dfsg-3
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-3
ii  python2.7.14-4
ii  python-sip4.19.8+dfsg-1
ii  python-six1.11.0-2

python-wxgtk4.0 recommends no packages.

Versions of packages python-wxgtk4.0 suggests:
pn  wx3.0-doc  

-- no debconf information



Bug#894788: vnc-java: FTBFS with openjdk-9

2018-04-06 Thread Emmanuel Bourg
Control: tags -1 + patch

Here is a patch fixing this issue.
--- a/makefile
+++ b/makefile
@@ -17,12 +17,12 @@
  vncCanvas.java optionsFrame.java clipboardFrame.java \
  animatedMemoryImageSource.java DesCipher.java
 
-OPTS = -source 1.3
+OPTS = -source 1.8
 
 all: $(CLASSES) $(ARCHIVE)
 
 $(CLASSES): $(SOURCES)
-   $(JC) $(OPTS) -target 1.1 -O $(SOURCES)
+   $(JC) $(OPTS) -target 1.8 -O $(SOURCES)
 
 $(ARCHIVE): $(CLASSES)
$(JAR) cf $(ARCHIVE) $(CLASSES)


Bug#893301: logisim FTBFS with openjdk-9

2018-04-06 Thread Emmanuel Bourg
Control: tags -1 + patch

Here is a patch fixing this issue.
--- a/src/com/cburch/logisim/gui/log/ComponentSelector.java
+++ b/src/com/cburch/logisim/gui/log/ComponentSelector.java
@@ -279,7 +279,7 @@
return true;
}
 
-   public Enumeration children() {
+   public Enumeration children() {
return Collections.enumeration(Collections.emptySet());
}
}
--- a/src/com/cburch/logisim/gui/main/SimulationTreeNode.java
+++ b/src/com/cburch/logisim/gui/main/SimulationTreeNode.java
@@ -15,7 +15,7 @@
return false;
}
 
-   public abstract Enumeration children();
+   public abstract Enumeration children();
public abstract boolean getAllowsChildren();
public abstract TreeNode getChildAt(int childIndex);
public abstract int getChildCount();


Bug#895071: Suggests: hyperestraier and ruby-hyperestraier, which are ex-packages

2018-04-06 Thread Adam Borowski
Source: tdiary-contrib
Version: 5.0.8-1
Severity: normal

Hi!
Your package declares a Suggests: on {,ruby-}hyperestraier, which have been
removed.  Please remove this relationship.


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

Kernel: Linux 4.16.0-debug-00034-g57a36aaa2c3f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)



Bug#895070: Recommends: hyperestraier which has been removed

2018-04-06 Thread Adam Borowski
Package: mew-beta-bin
Version: 7.0.50~6.7+0.20170719-1
Severity: normal

Hi!
Like mew-bin, mew-beta-bin currently Recommends, and mew-beta Suggests,
hyperestraier.

Per Policy, §2.2.1:
# the packages in main
#
# • must not require or recommend a package outside of main for compilation
#   or execution (thus, the package must not declare a Pre-Depends, Depends,
#   Recommends, Build-Depends, Build-Depends-Indep, or Build-Depends-Arch
#   relationship on a non-main package unless that package is only listed as
#   a non-default alternative for a package in main),

As written, this violation would be a RC bug, but let's not get _that_
slavish towards the Policy.  But it's still something that's be nice to fix.


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

Kernel: Linux 4.16.0-debug-00034-g57a36aaa2c3f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mew-beta-bin depends on:
ii  libc6   2.27-3
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages mew-beta-bin recommends:
ii  ca-certificates 20170717
pn  hyperestraier   
pn  ruby
pn  ruby-sqlite3
pn  stunnel4 | stunnel  

mew-beta-bin suggests no packages.


Bug#895069: Recommends: hyperestraier which has been removed

2018-04-06 Thread Adam Borowski
Package: mew-bin
Version: 1:6.7-4
Severity: normal

Hi!
mew-bin currently Recommends, and mew Suggests, hyperestraier.

Per Policy, §2.2.1:
# the packages in main
#
# • must not require or recommend a package outside of main for compilation
#   or execution (thus, the package must not declare a Pre-Depends, Depends,
#   Recommends, Build-Depends, Build-Depends-Indep, or Build-Depends-Arch
#   relationship on a non-main package unless that package is only listed as
#   a non-default alternative for a package in main),

As written, this violation would be a RC bug, but let's not get _that_
slavish towards the Policy.  But it's still something that's be nice to fix.


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

Kernel: Linux 4.16.0-debug-00034-g57a36aaa2c3f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mew-bin depends on:
ii  libc6   2.27-3
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages mew-bin recommends:
ii  ca-certificates 20170717
pn  hyperestraier   
pn  ruby
pn  ruby-sqlite3
pn  stunnel4 | stunnel  

mew-bin suggests no packages.


Bug#895034: wordpress: versions 4.9.4 and earlier are affected by three security issues

2018-04-06 Thread Craig Small
On Sat, 7 Apr 2018 at 05:19 Salvatore Bonaccorso  wrote:

> Have you requested CVEs for those three new issues?
>
Yes I have, through SWF with their JSON templates.
I'll see how that goes.

 - Craig

-- 
Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


Bug#895068: freecad does not start : "Illegal Instruction" returned

2018-04-06 Thread Giuliano Cabrele
Package: freecad
Version: 0.16+dfsg2-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

A freshly installed Freecad did not start when launched from Xfce desktop.
Trying to start from terminal produced the warning "Illegal Instruction" and 
stop of the program.  
The dmsg returns just a line:
traps: freecad[12387] trap invalid opcode ip:b651da3d sp:bf9062e8 error:0
  in libxerces-c-3.1.so[b62ab000+34a000].
Thanks for the attention



-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freecad depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0   1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-signals1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u3
ii  libcoin80v5 3.1.4~abc9f50+dfsg1-2
ii  libfreeimage3   3.17.0+ds1-5
ii  libfreetype62.6.3-3.2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  liboce-foundation10 0.17.2-2
ii  liboce-modeling10   0.17.2-2
ii  liboce-ocaf-lite10  0.17.2-2
ii  liboce-ocaf10   0.17.2-2
ii  liboce-visualization10  0.17.2-2
ii  libpyside1.21.2.2-2+b1
ii  libpython2.72.7.13-2+deb9u2
ii  libqt4-network  4:4.8.7+dfsg-11
ii  libqt4-opengl   4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libqtwebkit42.3.4.dfsg-9.1
ii  libshiboken1.2v51.2.2-3.1
ii  libsoqt4-20 1.6.0~e8310f-3
ii  libspnav0   0.2.3-1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libx11-62:1.6.4-3
ii  libxerces-c3.1  3.1.4+debian-2
ii  libxext62:1.3.3-1+b2
ii  libzipios++0v5  0.1.5.9+cvs.2007.04.28-6
ii  pyside-tools0.2.15-1+b1
ii  python  2.7.13-2
ii  python-collada  0.4-2
ii  python-matplotlib   2.0.0+dfsg1-2
ii  python-pivy 0.5.0~v609hg-3.1
ii  python-ply  3.9-1
ii  python-pyside   1.2.2-2
ii  python2.7   2.7.13-2+deb9u2
ii  zlib1g  1:1.2.8.dfsg-5

freecad recommends no packages.

Versions of packages freecad suggests:
pn  graphviz  
pn  povray

-- no debconf information



Bug#895066: RM: libgnu-regexp-java -- ROM; No longer used, superseded by standard Java APIs

2018-04-06 Thread Emmanuel Bourg
Package: ftp.debian.org
Severity: normal

Hi,

Please remove the libgnu-regexp-java package. This regular expression
library for Java is no longer used in Debian and is dead upstream.
Java has gotten its own standard regular expression API in 2002 and
there is little hope this library will be useful again.

Thank you,

Emmanuel Bourg



Bug#818291: L-Root IPv6 address renumbering

2018-04-06 Thread Bernhard Schmidt
Control: fixed -1 2017020200

On Tue, Mar 15, 2016 at 12:52:24PM -0400, Simon Deziel wrote:

> On March 23rd, L-Root will stop responding on the old IPv6. Only the new
> IPv6 address will remain functional, see [1] for details.
> 
> Regards,
> Simon
> 
> 1: http://seclists.org/nanog/2016/Mar/255

Fixed in
https://salsa.debian.org/dns-team/dns-root-data/commit/330792d01cad64a48d7c16b1a856935c61fde13f,
released with 2017020200



Bug#894811: New upstream release

2018-04-06 Thread Thomas Goirand
On 04/04/2018 02:25 PM, Ghislain Vaillant wrote:
> Package: src:python-pbr
> Severity: wishlist
> 
> Dear maintainer,
> 
> Please consider upgrading the packaging to the latest version (4.0.1 at
> this time).
> 
> Cheers,
> Ghis

Hi Ghis,

Thanks for this bug report.

Thought, I don't really see the need to open a bug 3 days after the
upstream release to let me know that I should "consider upgrading". I
always do, and over the years, the PBR package in Debian has always been
maintained up-to-date.

Instead, could you please tell me why you need this version? What new
feature do you need that isn't in 3.1.1? I usually refresh all OpenStack
packages on every release, and the next one (ie: Rocky) is due for end
of this summer. Unless you tell me why, I don't see what the urgency is.

Cheers,

Thomas Goirand (zigo)



Bug#700972: patch

2018-04-06 Thread Aurélien COUDERC
Control: tags -1 + patch

Here’s a patch.


Cheers,
--
Aurélien
Index: scsitools-0.12/rescan-scsi-bus/rescan-scsi-bus.sh
===
--- scsitools-0.12.orig/rescan-scsi-bus/rescan-scsi-bus.sh
+++ scsitools-0.12/rescan-scsi-bus/rescan-scsi-bus.sh
@@ -587,9 +587,12 @@ modprobe sg >/dev/null 2>&1
 
 if test -x /usr/bin/sg_inq; then
 sg_version=$(sg_inq -V 2>&1 | cut -d " " -f 3)
-sg_version=${sg_version##0.}
-#echo "\"$sg_version\""
-if [ -z "$sg_version" -o "$sg_version" -lt 70 ] ; then
+sg_major_version=${sg_version%%.*}
+sg_minor_version=${sg_version##*.}
+#echo "\"$sg_major_version\""
+#echo "\"$sg_minor_version\""
+if [ -z "$sg_version" -o \
+	\( "$sg_major_version" -eq 0 -a "$sg_minor_version" -lt 70 \) ] ; then
 sg_len_arg="-36"
 else
 sg_len_arg="--len=36"


Bug#895036: lintian: please nag about get-orig-source targets that only call uscan

2018-04-06 Thread Chris Lamb
tags 895036 + pending
thanks

Fixed in Git, pending upload :)

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=e686928ffda5e618630a86854926b0cb65a3098f


Regards,

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



Bug#888491: [Pkg-dns-devel] Bug#888491: bind9: Provide up to date db.root in stable Debian release

2018-04-06 Thread Bernhard Schmidt
Control: tags -1 patch

On Wed, Jan 31, 2018 at 09:45:42PM -0500, Daniel Kahn Gillmor wrote:

> > From my measurements (Zurich, Switzerland), all old addresses are still
> > working, but new addresses are a bit faster in all cases. (by 10-20 ms
> > compared to old addresses).
> 
> shouldn't this data be removed from the bind9 package, and just have it
> instead depend directly on dns-root-data?
> 
> It'd be better if we only have to keep this stuff up-to-date in one
> place, which should most likley be /usr/share/dns/root.hints

Indeed.

https://salsa.debian.org/dns-team/bind9/merge_requests/2

should be enough for new installations (people who adjusted
named.conf.default-zones will get a debconf prompt).

I'd like to avoid doing anything magic with an existing db.root, I think
this has the potential to break a lot of things, while a slightly stale
hints file is only used for priming at startup.

Bernhard



Bug#895064: #895064: nsis fails when license data file is encoded in ISO-8859

2018-04-06 Thread Adam Borowski
> Nsis fails to create an installer file when presented a licese-data file that
> is ISO-8859 encoded. In the previous version, this worked.

> If the file is encoded as ASCII or UTF-8, this error does not occur.

Looks like a "don't do that, then" kind of error.

The sooner we deprecate ancient locales, the better.  These files are not
readable in most modern GUIs (non-UTF8 support is not even paid lip service
anymore), require per-file metadata, and what you mentioned, ISO-8859, is
not even Windows compatible.  8859-1 is 87% identical with CP1252, but
8859-2 and CP1250 have little overlap, etc.

So if nsis 3 requires Unicode, that's a much awaited improvement, not a
regression.  Requiring projects to have text encoded in UTF-8 allows it
being readable in all locales.  I for one live in Poland, get Windows
software in Polish, see Google's pages insisting on Polish despite
explicitely requesting English -- yet I had three years of German in school
thus I can at least roughly understand a bit of German translations you
write, at least to the point of being able to see if they look plausible. 
Yet with ISO-8859-1, I'd get all umlauts and betas[1] corrupted.  Thus,
German text might be uncomfortable to read -- but I also happen to have had
three years of Russian in school as well, you can guess that Russian text in
an ancient locale gets a little bit more mangled than the occasional umlaut.

Unicode has none of these issues.


ᛗᛖᛟᚹ!

[1]. You mean, ss was merely conflated with beta in some ancient charsets?
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄



Bug#894970: tomcat8: missing Depends on libservlet3.1-java

2018-04-06 Thread Emmanuel Bourg
Hi Thorsten,

Le 05/04/2018 à 19:01, Thorsten Glaser a écrit :

> Without libservlet3.1-java installed, deploying a simple WAR fails

This issue has already been reported in #867247, and subsequently fixed
in tomcat8/8.5.21-1 [1]. The fix should be backported to the package in
Stretch though.

Emmanuel Bourg

[1] https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=4e00f55



Bug#895065: libdevel-callchecker-perl: please increase the timeout of "threads.t"

2018-04-06 Thread Aurelien Jarno
Package: libdevel-callchecker-perl
Version: 0.007-2
Severity: wishlist
Tags: patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

libdevel-callchecker-perl 0.007-2 currently FBTFS on the riscv64 port,
due to insufficient timeout when running threads.t (it's running under
qemu-system VMs at the moment):

https://buildd.debian.org/status/fetch.php?pkg=libdevel-callchecker-perl=riscv64=0.007-2=1522095444=0

Increasing the timeout from 10 seconds to 30 seconds allows the
testsuite to pass.

I think that it would be nice if you could increase the timeout, it
should not give any penalty for other architectures if the test passes.
This is what the attached patch does.

Thanks,
Aurelien


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

Kernel: Linux 4.15.0_riscv-linux-4.15_2b0aa1de4+ (SMP w/1 CPU core)
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)
--- libdevel-callchecker-perl-0.007.orig/t/threads.t
+++ libdevel-callchecker-perl-0.007/t/threads.t
@@ -29,7 +29,7 @@ use Test::More tests => 3;
 use Thread::Semaphore ();
 use threads::shared;
 
-alarm 10;   # failure mode may involve an infinite loop
+alarm 30;   # failure mode may involve an infinite loop
 
 sub tsub1 (@) { $_[0] }
 sub tsub2 (@) { $_[0] }


Bug#895044: [debhelper-devel] Bug#895044: debhelper: add support for Ninja with CMake

2018-04-06 Thread Kyle Edwards

On 04/06/2018 04:15 PM, Niels Thykier wrote:

Control: tags -1 +patch

Kyle Edwards:

Package: debhelper
Version: 11.1.6
Severity: wishlist

Dear Maintainer,

Large projects which use CMake, such as VTK, take a long time to build
with the Makefile generator, and see significant build time improvements
when being built with the Ninja generator instead. Please consider
adding support for using the Ninja generator with CMake. Perhaps
something like:

$ dh --buildsystem=cmakeninja

I realize this may be tricky given how the buildsystems are implemented
in debhelper. I don't know much about Perl, but if it supports multiple
inheritance, would it be possible to make a class like "cmakebase" and
then have "cmake" and "cmakeninja" inherit from both "cmakebase" and
then "makefile" and "ninja" respectively?


[...]

Ok, I have written a sample patch series (attached) that should make
debhelper support cmake with the ninja backend.

The chosen syntax is:

   dh  --buildsystem=cmake+ninja

A review and some testing would be appreciated.

Thanks,
~Niels



Just tested it, and I like it.

One thing I did notice is that if your project doesn't have tests, you 
have to turn on nocheck when switching to cmake+ninja, because the ninja 
buildsystem fails if no "test" target exists (the makefile buildsystem 
seems to silently ignore the failure.) I don't think this is a 
deal-breaker, but it is something to keep in mind when switching to 
ninja. Perhaps this could be filed as a separate bug.


Thank you for the quick response! I hope to see this in debhelper soon.

Kyle



Bug#895064: [nsis] nsis fails when license data file is encoded in ISO-8859

2018-04-06 Thread Johannes Zarl-Zierl
Package: nsis
Version: 3.03-2
Severity: low

--- Please enter the report below this line. ---

Nsis fails to create an installer file when presented a licese-data file that 
is ISO-8859 encoded. In the previous version, this worked.

If the file is encoded as ASCII or UTF-8, this error does not occur.


Exact error message from NSISOutput.log:

!insertmacro: MUI_PAGE_LICENSE
LicenseData: wchar_t conversion failed!
Error in macro MUI_PAGE_LICENSE on macroline 21
Error in script "/home/zing/tmp/incoming/cmake_nsis_wchar_t/build-mingw/
_CPack_Packages/win64/NSIS/project.nsi" on line 547 -- aborting creation 
process


Steps to reproduce:
0. Save attached files "CMakeLists.txt", "INSTALL-MESSAGE.txt" and 
"mingw64.toolchain" into a new directory

1. Run cmake and cpack to create an NSIS installer:
cmake -DCMAKE_TOOLCHAIN_FILE=mingw64.toolschain .
cpack

2. NSIS aborts with the error message given above




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

Debian Release: buster/sid
  500 unstableftp.at.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-=
nsis-common  (>= 3.03-2) | 3.03-2
libc6  (>= 2.14) | 
libgcc1   (>= 1:3.0) | 
libstdc++6  (>= 5.2) | 
zlib1g  (>= 1:1.1.4) | 


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-
mingw-w64  | 5.0.3-1
nsis-doc   (>= 3.03-2) | 
nsis-pluginapi (>= 3.03-2) | 
wine   | 3.0-1




cmake_minimum_required (VERSION 3.0.0)
project (NSISBug)

install(FILES "${CMAKE_SOURCE_DIR}/INSTALL-MESSAGE.txt" DESTINATION doc)

## installer support using cpack (this section should come last):
set(CPACK_PACKAGE_NAME "NSISBug")
#set(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_SOURCE_DIR}/README.txt")
#set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "NSISBug - demonstrate a bug with nsis 3.03-2")
#set(CPACK_PACKAGE_INSTALL_DIRECTORY "NSISBug")
## maybe find a more useful vendor name?
#set(CPACK_PACKAGE_VENDOR "NSISBug.sf.net")
#set(CPACK_PACKAGE_VERSION "1.6.0")
#set(CPACK_PACKAGE_VERSION_MAJOR "1")
#set(CPACK_PACKAGE_VERSION_MINOR "6")
#set(CPACK_PACKAGE_VERSION_PATCH "0")
set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/INSTALL-MESSAGE.txt")

# allow user to add bin dir to path:
#set(CPACK_NSIS_MODIFY_PATH "ON")
include(CPack)
Copyright � 
## Cross compilation instructions:
#
# cmake -DCMAKE_TOOLCHAIN_FILE=../mingw64.toolchain -DCMAKE_BUILD_TYPE=Release -G Ninja ..
# ninja
# cpack -G NSIS64



# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)

# for ctest:
set(CMAKE_CROSSCOMPILING_EMULATOR wine64)

# static linking to avoid runtime dependency on mingw:
# Without this, the resulting executables would be smaller,
# but require mingw-w64 to be installed.
set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++")
set(CMAKE_SHARED_LINKER_FLAGS "-static-libgcc -static-libstdc++")

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH  /usr/share/mingw-w64)

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search 
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
# Run command: "/usr/bin/makensis" "/home/zing/tmp/incoming/cmake_nsis_wchar_t/build-mingw/_CPack_Packages/win64/NSIS/project.nsi"
# Output:
Processing config: /etc/nsisconf.nsh
Processing script file: "/home/zing/tmp/incoming/cmake_nsis_wchar_t/build-mingw/_CPack_Packages/win64/NSIS/project.nsi" (UTF8)
!insertmacro: select_NT_profile
Function: "select_NT_profile"
StrCmp "$ADD_TO_PATH_ALL_USERS" "1" equal=0, nonequal=environment_single
DetailPrint: "Selected environment for all users"
Push: all
Return
DetailPrint: "Selected environment for current user only."
Push: current
Return
FunctionEnd
!insertmacro: end of select_NT_profile
!insertmacro: select_NT_profile
Function: "un.select_NT_profile"
StrCmp "$ADD_TO_PATH_ALL_USERS" "1" equal=0, nonequal=environment_single
DetailPrint: "Selected environment for all users"
Push: all
Return
DetailPrint: "Selected environment for current user only."
Push: current
Return
FunctionEnd
!insertmacro: end of select_NT_profile
!define: "NT_current_env"="HKCU "Environment""
!define: "NT_all_env"="HKLM "SYSTEM\CurrentControlSet\Control\Session Manager\Environment""
!define: "WriteEnvStr_RegKey"="HKCU "Environment""
Function: "AddToPath"
Exch($0,0)
Push: $1
Push: $2
Push: $3
IfFileExists: "$0\*.*" ?  : AddToPath_done
ReadEnvStr: PATH->$1
StrLen $2 "$1"
IntCmp $2:0 equal=CheckPathLength_ShowPathWarning, < CheckPathLength_Done, > 

Bug#895059: RM: e2fslibs libcomerr2 [all] -- RoQA; NBS; obsolete arch:all package

2018-04-06 Thread Andreas Beckmann
Followup-For: Bug #895059
Control: retitle -1 RM: e2fslibs libcomerr2 [all] -- RoQA; NBS; obsolete 
arch:all package

another one from the same source:

e2fslibs   | 1.43.4-2  | stable | amd64, arm64, armel, 
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
e2fslibs   | 1.43.9-1  | unstable   | all
e2fslibs   | 1.44.1-1  | unstable   | amd64, arm64, armel, 
armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, 
powerpc, ppc64el, s390x

Andreas



Bug#820973: libsoup bug

2018-04-06 Thread Mathieu Parent
Control:  reassign -1 libsoup2.4-1 2.48.0-1

Hello,

According to https://bugzilla.gnome.org/show_bug.cgi?id=765106, this
is a libsoup bug, fixed in 2.54.1+.

Regards



-- 
Mathieu Parent



Bug#895063: RM: facter [all] -- RoQA; NBS; obsolete arch:all package

2018-04-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

factor is now arch:any:

facter | 2.4.6-1 | unstable   | all
facter | 3.11.0-1| unstable   | source, amd64, arm64, 
armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x

Andreas



Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

2018-04-06 Thread Ævar Arnfjörð Bjarmason

On Fri, Apr 06 2018, Eric Wong wrote:

> Ævar Arnfjörð Bjarmason  wrote:
>> On Fri, Apr 06 2018, Eric Wong wrote:
>> > Ævar Arnfjörð Bjarmason  wrote:
>> >
>> >> --- a/perl/Git.pm
>> >> +++ b/perl/Git.pm
>> >> @@ -554,7 +554,7 @@ sub get_record {
>> >>   my ($fh, $rs) = @_;
>> >>   local $/ = $rs;
>> >>   my $rec = <$fh>;
>> >> - chomp $rec if defined $rs;
>> >> + chomp $rec if defined $rs and defined $rec;
>> >
>> > I'm struggling to understand the reason for the "defined $rs"
>> > check.  I think it was a braino on my part and meant to use:
>> >
>> >chomp $rec if defined $rec;
>>
>> Whether this makes any sense is another question, but you seem to have
>> explicitly meant this at the time. The full function definition with
>> documentation:
>>
>> =item get_record ( FILEHANDLE, INPUT_RECORD_SEPARATOR )
>>
>> Read one record from FILEHANDLE delimited by INPUT_RECORD_SEPARATOR,
>> removing any trailing INPUT_RECORD_SEPARATOR.
>
> I've always known chomp to respect the value of $/; so chomp($rec)
> whould only cut out whatever $rs is, and be a no-op if $rs is undef.

Yup, you're right. I missed that.



Bug#895061: exclusions and dh_missing

2018-04-06 Thread Nicolas Boulenguez
Package: debhelper
Version: 11.1.6
Severity: wishlist

Hi.

Some debhelper commands log some files as installed while they are not,
so that dh_missing does not report them later.
* files missing because of nodocs
* files ignored because the package is not selected (-p/-N/-a/-i or similar)

Should excluded files also be marked as installed?
(for example, dh_installexamples does so)
The selected behaviour should probably be explicit in the --exclude
section of debhelper(7).

Please allow me to suggest a third way: reserve --exclude for
overrides of hardcoded lists, but ignore this option for explicit user
selections.

For example, --exclude is useful to prevent dh_compress acting on a
specific file, or dh_installdocs acting on a specific
debian/changelog, but "dh_installexamples --exclude=foo/bar foo" can
be avoided with a more specific pattern.

Even if the caller ends up generating a list, the result will probably
be more maintainable that black magic inside the dh_ tool.
See dh_installexamples for an example of the complexity added by --exclude.



Bug#895062: ITP: golang-github-smartystreets-gunit -- xUnit-style test fixture adapter for go test

2018-04-06 Thread Raju Devidas
Package: wnpp
Severity: wishlist
Owner: Raju Devidas 

* Package name    : golang-github-smartystreets-gunit
  Version : 1.2.0+git20180314.6f0d627-1
  Upstream Author : SmartyStreets
* URL : https://github.com/smartystreets/gunit
* License : Expat
  Programming Lang: Go
  Description : xUnit-style test fixture adapter for go test

 Yet another testing tool for Go.
 .
 It's a mix of good things provided by the built-in testing package, the
 assertions (https://github.com/smartystreets/assertions) you know
 and love from the GoConvey (http://goconvey.co) project, the xUnit
 (https://en.wikipedia.org/wiki/XUnit) testing style (the first real unit
 testing framework), and it's all glued together with go test.


Bug#895060: openjdk-11: Please drop obsolete patch hotspot-disable-jvmtihtml.diff

2018-04-06 Thread John Paul Adrian Glaubitz
Source: openjdk-11
Version: 11~7-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

The patch hotspot-disable-jvmtihtml.diff doesn't apply anymore,
please remove it completely. It also seems we don't need it
anymore at all, but I am checking openjdk-10 (and -11) on m68k
now to see whether we need another patch. I will open another bug
report for that if necessary.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#895059: RM: libcomerr2 [all] -- RoQA; NBS; obsolete arch:all package

2018-04-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

libcomerr2 is arch:any, again:

libcomerr2 | 1.43.4-2  | stable | amd64, arm64, armel, 
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libcomerr2 | 1.43.9-1  | unstable   | all
libcomerr2 | 1.44.1-1  | unstable   | amd64, arm64, armel, 
armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, 
powerpc, ppc64el, s390x


Andreas



Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

2018-04-06 Thread Eric Wong
Ævar Arnfjörð Bjarmason  wrote:
> On Fri, Apr 06 2018, Eric Wong wrote:
> > Ævar Arnfjörð Bjarmason  wrote:
> >
> >> --- a/perl/Git.pm
> >> +++ b/perl/Git.pm
> >> @@ -554,7 +554,7 @@ sub get_record {
> >>my ($fh, $rs) = @_;
> >>local $/ = $rs;
> >>my $rec = <$fh>;
> >> -  chomp $rec if defined $rs;
> >> +  chomp $rec if defined $rs and defined $rec;
> >
> > I'm struggling to understand the reason for the "defined $rs"
> > check.  I think it was a braino on my part and meant to use:
> >
> > chomp $rec if defined $rec;
> 
> Whether this makes any sense is another question, but you seem to have
> explicitly meant this at the time. The full function definition with
> documentation:
> 
> =item get_record ( FILEHANDLE, INPUT_RECORD_SEPARATOR )
> 
> Read one record from FILEHANDLE delimited by INPUT_RECORD_SEPARATOR,
> removing any trailing INPUT_RECORD_SEPARATOR.

I've always known chomp to respect the value of $/; so chomp($rec)
whould only cut out whatever $rs is, and be a no-op if $rs is undef.

> It doesn't make to remove the trailing record separator if it's not
> defined, otherwise we'd be coercing undef to "\n" while at the same time
> returning multiple records. But then of course the only user of this
> with an "undef" argument just does:
> 
> chomp($log_entry{log} = get_record($log_fh, undef));

Subtle difference, that chomp() still sees $/ as "\n".
$/ is only undef inside get_record.

> So we could also remove that chomp(), adn not check defined $rs, but IMO
> it's cleaner & more consistent this way.

I think the chomp is necessary. In git-svn.perl /^sub get_commit_entry {:

# 
open my $log_fh, '>', $commit_editmsg or croak $!;

# 
$msgbuf =~ s/\s+$//s;

# 

print $log_fh $msgbuf or croak $!;

# 
close $log_fh or croak $!;

# Above, we ensured the contents of $commit_editmsg has no trailing newline

if ($_edit || ($type eq 'tree')) {
chomp(my $editor = command_oneline(qw(var GIT_EDITOR)));
system('sh', '-c', $editor.' "$@"', $editor, $commit_editmsg);
}

# However, $editor is likely to introduce a trailing newline

rename $commit_editmsg, $commit_msg or croak $!;
{
require Encode;
# SVN requires messages to be UTF-8 when entering the repo
open $log_fh, '<', $commit_msg or croak $!;
binmode $log_fh;

# chomp trailing newline introduced by $editor:

chomp($log_entry{log} = get_record($log_fh, undef));



Bug#895058: cinnamon-control-center segfaults when opening network settings

2018-04-06 Thread Nicolas Braud-Santoni
Package: cinnamon-control-center
Version: 3.6.5-1
Severity: important

Hi,

Since my last upgrade, 3 days ago, cinnamon-control-center started
segfaulting whenever I attempt to access network settings:

> $ gdb cinnamon-control-center
> GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
> [...]
> Reading symbols from cinnamon-control-center...Reading symbols from 
> /usr/lib/debug/.build-id/fc/e7dccd7092d6a12aafa0b3cf62dc6ec636d04d.debug...done.
> done.
> (gdb) run
> Starting program: /usr/bin/cinnamon-control-center 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffed681700 (LWP 29038)]
> [New Thread 0x7fffece80700 (LWP 29039)]
> [New Thread 0x7fffd5839700 (LWP 29040)]
> [New Thread 0x7fffd1c76700 (LWP 29286)]
> 
> Thread 1 "cinnamon-contro" received signal SIGSEGV, Segmentation fault.
> 0x7fffd33ae383 in modules_initialized (object=, 
> res=0x55be1b10, user_data=)
> at src/libnma/nma-cert-chooser-button.c:98
> 98src/libnma/nma-cert-chooser-button.c: No such file or directory.
> (gdb) bt
> #0  0x7fffd33ae383 in modules_initialized (object=, 
> res=0x55be1b10, user_data=)
> at src/libnma/nma-cert-chooser-button.c:98
> #1  0x7fffd82c2af4 in ?? () from /usr/lib/x86_64-linux-gnu/libgck-1.so.0
> #2  0x7fffd82c343c in ?? () from /usr/lib/x86_64-linux-gnu/libgck-1.so.0
> #3  0x7618b6a5 in g_type_create_instance ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #4  0x7616c5a8 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #5  0x7616e420 in g_object_new_valist ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #6  0x7616e799 in g_object_new ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #7  0x7fffd33aecd2 in nma_cert_chooser_button_new (
> flags=flags@entry=NMA_CERT_CHOOSER_BUTTON_FLAG_NONE)
> at src/libnma/nma-cert-chooser-button.c:447
> #8  0x7fffd33af76e in init (cert_chooser=0x557943c0)
> at src/libnma/nma-pkcs11-cert-chooser.c:481
> #9  0x7fffd33aad5b in constructor (type=, 
> n_construct_properties=, construct_properties= out>)
> at src/libnma/nma-cert-chooser.c:635
> #10 0x7616c3de in ?? () from 
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #11 0x7616e420 in g_object_new_valist ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #12 0x7616e799 in g_object_new ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #13 0x7fffd33ab797 in nma_cert_chooser_new (title=, 
> flags=) at src/libnma/nma-cert-chooser.c:813
> #14 0x7fffd38c78be in cc_network_panel_init (panel=0x55a52a70)
> at cc-network-panel.c:1300
> #15 0x7618b6a5 in g_type_create_instance ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #16 0x7616c5a8 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #17 0x7616e420 in g_object_new_valist ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #18 0x7616e799 in g_object_new ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #19 0xd6e2 in activate_panel (gicon=0x558ffd30, 
> name=, 
> desktop_file=0x55836a80 
> "/usr/share/applications/cinnamon-network-panel.desktop", argv=0x0, 
> id=0x55c1dbe0 "network", shell=0x557c1370)
> at cinnamon-control-center.c:239
> #20 _shell_set_active_panel_from_id (shell=0x557c1370, 
> start_id=0x55c1dbe0 "network", argv=0x0, err=)
> at cinnamon-control-center.c:1038
> #21 0xbaa4 in item_activated_cb (view=, 
> name=, id=0x55c1dbe0 "network", 
> desktop_file=, shell=0x557c1370)
> at cinnamon-control-center.c:341
> #22 0x76166f6d in g_closure_invoke ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #23 0x76179d3e in ?? () from 
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #24 0x761823f5 in g_signal_emit_valist ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #25 0x76182e0f in g_signal_emit ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #26 0xe442 in iconview_item_activated_cb (icon_view= out>, 
> path=0x55a84da0, cc_view=0x55a72290) at cc-shell-item-view.c:143
> #27 0x76166f6d in g_closure_invoke ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #28 0x76179d3e in ?? () from 
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #29 0x761823f5 in g_signal_emit_valist ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #30 0x76182e0f in g_signal_emit ()
>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #31 0xe5d3 in iconview_button_release_event_cb (
> widget=, event=, cc_view=0x55a72290)
> at cc-shell-item-view.c:111
> #32 0x774f9e1b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #33 0x76166f6d in 

Bug#895057: RFH: ltsp -- network booted thin and fat clients

2018-04-06 Thread Vagrant Cascadian
Package: wnpp
Severity: normal

It has been several years since I've actually maintained a real-world
deployment of LTSP, and there are very few other active developers of
the project upstream. I have continued to maintain it in Debian as best
I can, and would love to see it continue to be supported in Debian, but
would really need some active co-maintainers to keep it viable
long-term.

Right now there is an RC bug regarding support for the transition to
FreeRDP2 (which I've never used):

  https://bugs.debian.org/892626

Of course there are a few other bugs in Debian and upstream.

The main source packages affected are ltsp, ldm, ltspfs and the
much-neglected ltsp-docs.

There's also ltsp-manager, currently only in experimental, which is an
attempt to simplify installation and management of LTSP environments.

Another source package is libpam-sshauth, which is a major piece of an
attempt to replace the deficiencies of LDM with a regular display
manager using PAM... this has long been on the plans for a next
generation LTSP, but hasn't gotten beyond the proof of concept phase.


I've CCed debian-edu in the bug report, as that project has some of the
largest active users of ltsp in Debian that I'm aware of.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#895044: [debhelper-devel] Bug#895044: debhelper: add support for Ninja with CMake

2018-04-06 Thread Niels Thykier
Control: tags -1 +patch

Kyle Edwards:
> Package: debhelper
> Version: 11.1.6
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Large projects which use CMake, such as VTK, take a long time to build
> with the Makefile generator, and see significant build time improvements
> when being built with the Ninja generator instead. Please consider
> adding support for using the Ninja generator with CMake. Perhaps
> something like:
> 
> $ dh --buildsystem=cmakeninja
> 
> I realize this may be tricky given how the buildsystems are implemented
> in debhelper. I don't know much about Perl, but if it supports multiple
> inheritance, would it be possible to make a class like "cmakebase" and
> then have "cmake" and "cmakeninja" inherit from both "cmakebase" and
> then "makefile" and "ninja" respectively?
> 
> 
> [...]

Ok, I have written a sample patch series (attached) that should make
debhelper support cmake with the ninja backend.

The chosen syntax is:

  dh  --buildsystem=cmake+ninja

A review and some testing would be appreciated.

Thanks,
~Niels

>From d3bc4c31453aabea565f8991dcbe1d9e1a0fc737 Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Fri, 6 Apr 2018 19:49:20 +
Subject: [PATCH 1/2] Rewrite build system to support a "target build system"

Several of the build systems consists of a configure step that
generates a buildscript for another build tool.  Notable examples
being "cmake" and "meson", which even supports multiple backend tools.
This change makes it natively possible for debhelper to support such
build systems with multiple backends.

Note that only build systems with multiple backends have been
rewritten.

Signed-off-by: Niels Thykier 
---
 lib/Debian/Debhelper/Buildsystem.pm   | 117 +-
 lib/Debian/Debhelper/Buildsystem/cmake.pm |  33 +++--
 lib/Debian/Debhelper/Buildsystem/meson.pm |  20 -
 lib/Debian/Debhelper/Buildsystem/ninja.pm |   8 --
 lib/Debian/Debhelper/Dh_Buildsystems.pm   |  71 +-
 t/buildsystems/03-bs-auto-buildable.t |  14 ++--
 6 files changed, 216 insertions(+), 47 deletions(-)

diff --git a/lib/Debian/Debhelper/Buildsystem.pm b/lib/Debian/Debhelper/Buildsystem.pm
index a0ce6367..6e822c45 100644
--- a/lib/Debian/Debhelper/Buildsystem.pm
+++ b/lib/Debian/Debhelper/Buildsystem.pm
@@ -11,15 +11,26 @@ use warnings;
 use Cwd ();
 use File::Spec;
 use Debian::Debhelper::Dh_Lib;
+use Debian::Debhelper::Dh_Buildsystems qw(load_buildsystem);
 
 # Build system name. Defaults to the last component of the class
 # name. Do not override this method unless you know what you are
 # doing.
 sub NAME {
-	my $this=shift;
-	my $class = ref($this) || $this;
+	my ($this) = @_;
+	my $class = ref($this);
+	my $target_name;
+	if ($class) {
+		if ($this->IS_GENERATOR_BUILD_SYSTEM) {
+			$target_name = $this->{'targetbuildsystem'}->NAME;
+		}
+	} else {
+		$class = $this;
+	}
 	if ($class =~ m/^.+::([^:]+)$/) {
-		return $1;
+		my $name = $1;
+		return "${name}+${target_name}" if defined($target_name);
+		return $name;
 	}
 	else {
 		error("ınvalid build system class name: $class");
@@ -37,6 +48,43 @@ sub DEFAULT_BUILD_DIRECTORY {
 	"obj-" . dpkg_architecture_value("DEB_HOST_GNU_TYPE");
 }
 
+# Return 1 if the build system generator
+sub IS_GENERATOR_BUILD_SYSTEM {
+	return 0;
+}
+
+# Generator build-systems only
+# The name of the supported target systems.  The first one is
+# assumed to be the default if DEFAULT_TARGET_BUILD_SYSTEM is
+# not overridden.
+sub SUPPORTED_TARGET_BUILD_SYSTEMS {
+	error("class lacking SUPPORTED_TARGET_BUILD_SYSTEMS");
+}
+
+# Generator build-systems only
+# Name of default target build system if target is unspecified
+#  (e.g. --buildsystem=cmake instead of cmake+makefile).
+sub DEFAULT_TARGET_BUILD_SYSTEM {
+	my ($this) = @_;
+	my @targets = $this->SUPPORTED_TARGET_BUILD_SYSTEMS;
+	# Assume they are listed in order.
+	return $targets[0];
+}
+
+# For regular build systems, the same as DESCRIPTION
+# For generator based build systems, the DESCRIPTION of the generator build
+# system + the target build system.  Do not override this method unless you
+# know what you are doing.
+sub FULL_DESCRIPTION {
+	my ($this) = @_;
+	my $description = $this->DESCRIPTION;
+	return $description if not exists($this->{'targetbuildsystem'});
+	my $target_build_system = $this->{'targetbuildsystem'};
+	return $description if not defined($target_build_system);
+	my $target_desc = $target_build_system->FULL_DESCRIPTION;
+	return "${description} combined with ${target_desc}";
+}
+
 # Constructs a new build system object. Named parameters:
 # - sourcedir- specifies source directory (relative to the current (top)
 #  directory) where the sources to be built live. If not
@@ -46,6 +94,8 @@ sub DEFAULT_BUILD_DIRECTORY {
 #  DEFAULT_BUILD_DIRECTORY directory will be used.
 # - parallel - max number of parallel processes to be spawned for building
 #  

Bug#819160: Bug#892626: Switch from freerdp-x11 to freerdp2-x11

2018-04-06 Thread Mike Gabriel

Hi Vagrant

On  Fr 06 Apr 2018 22:10:52 CEST, Vagrant Cascadian wrote:


On 2018-04-06, Mike Gabriel wrote:

On Sun, 11 Mar 2018 13:59:14 + Mike Gabriel
 wrote:
 > the freerdp-x11 (1.1 series) package shall not be included in buster.
 > Please replace ltsp-client's dependency on it by a dependency on
 > freerdp2-x11.
 >
 > When switching to the new FreeRDP2 version, make sure you use the new
 > command line syntax for the xfreerdp command.


I don't personally use FreeRDP (or even LTSP anymore for that matter),
do you think you could provide references to a summary of the changes in
syntax?

Or maybe even a patch? :)

With my LTSP hat on, old and worn out though it may be, I'd think we'd
maybe still want to provide support for the old variant for backports
and legacy setups, so it might be appropriate to create a new script,
especially in light of:

#819160: ltsp-client-core: Please provide seperate
 usr/share/ltsp/screen.d/rdesktop and xfreerdp scripts

  https://bugs.debian.org/819160



Raising this bug to RC level. The ltsp-client package is the last
package that prevents us from having the old freerdp (FreeRDP 1.1)
src:package removed from Debian.


Apologies for taking so long to explore this.


live well,
  vagrant


I'll see what I can do after having returned from VAC (around the 15th  
April)...


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



pgpDHcqjq771Z.pgp
Description: Digitale PGP-Signatur


Bug#895056: [debhelper-devel] Bug#895056: Dh_Lib.pm: avoid creating empty log of installed files

2018-04-06 Thread Niels Thykier
Control: tags -1 moreinfo

Nicolas Boulenguez:
> Package: debhelper
> Version: 11.1.6
> Severity: wishlist
> Tags: patch
> 
> In Dh_Lib.pm, "sub log_installed_files" starts with:
>   return if $dh{NO_ACT};
> I suggest
>   return if $dh{NO_ACT} or not @patterns;
> instead so that the file is only created if it is useful.
> (seen with DEB_BUILD_OPTIONS=nodoc dh_installinfo).
> 

Those empty files are quite deliberate as dh_missing informs you which
tools reported that they would install files.

See also "Logging helpers and dh_missing:" in doc/PROGRAMMING, which
describes the interface between dh_missing and dh_install* helpers.

Thanks,
~Niels



Bug#819160: Bug#892626: Switch from freerdp-x11 to freerdp2-x11

2018-04-06 Thread Vagrant Cascadian
On 2018-04-06, Mike Gabriel wrote:
> On Sun, 11 Mar 2018 13:59:14 + Mike Gabriel 
>  wrote:
>  > the freerdp-x11 (1.1 series) package shall not be included in buster.
>  > Please replace ltsp-client's dependency on it by a dependency on
>  > freerdp2-x11.
>  >
>  > When switching to the new FreeRDP2 version, make sure you use the new
>  > command line syntax for the xfreerdp command.

I don't personally use FreeRDP (or even LTSP anymore for that matter),
do you think you could provide references to a summary of the changes in
syntax?

Or maybe even a patch? :)

With my LTSP hat on, old and worn out though it may be, I'd think we'd
maybe still want to provide support for the old variant for backports
and legacy setups, so it might be appropriate to create a new script,
especially in light of:

#819160: ltsp-client-core: Please provide seperate
 usr/share/ltsp/screen.d/rdesktop and xfreerdp scripts

  https://bugs.debian.org/819160


> Raising this bug to RC level. The ltsp-client package is the last 
> package that prevents us from having the old freerdp (FreeRDP 1.1) 
> src:package removed from Debian.

Apologies for taking so long to explore this.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#895011: [debhelper-devel] Bug#895011: dh_installwm: please mention --all in manual page

2018-04-06 Thread Peter Pentchev
On Fri, Apr 06, 2018 at 09:41:15PM +0200, Nicolas Boulenguez wrote:
> > Hmm, isn't this covered by the "common debhelper options" section in
> > the debhelper(7) manual page?  I believe that this is the reason it is
> > not mentioned in any of the separate commands' manual pages.
> 
> You may be confusing "shared options" and "common options".
> The section you are refering to starts with:
> 
>   The following command line options are supported by some debhelper
>   programs. See the man page of each program for a complete
>   explanation of what each option does.
> 
> Other tools either document --all or ignore it.

I'm sorry.  Of course you're right.  I hadn't woken up yet, I guess.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature


Bug#894674: (no subject)

2018-04-06 Thread Max Resnick
I've used the patch provided and rebuilt the deb on 4.15 and can confirm this 
fixed the udp error message.  Using PAP auth w/ ipsec works again, however 
can't confirm other possible regressions beyond my usecase.



Bug#895056: Dh_Lib.pm: avoid creating empty log of installed files

2018-04-06 Thread Nicolas Boulenguez
Package: debhelper
Version: 11.1.6
Severity: wishlist
Tags: patch

In Dh_Lib.pm, "sub log_installed_files" starts with:
  return if $dh{NO_ACT};
I suggest
  return if $dh{NO_ACT} or not @patterns;
instead so that the file is only created if it is useful.
(seen with DEB_BUILD_OPTIONS=nodoc dh_installinfo).



Bug#876410: libgl2ps1: please include support for SOURCE_DATE_EPOCH

2018-04-06 Thread Mike Miller
On Sat, Mar 24, 2018 at 23:08:25 +0100, Anton Gladky wrote:
> thanks for the bugreport. I do not think, that adding the
> fixed timestamp to all files produced by the gl2os that is
> what the users want.

Thank you for your reply.

Respectfully, I am a user of gl2ps, and I do want to be able to use it
to write deterministic postscript output.

I do think the current behavior should be the default, I am only asking
for an option to create an output with a known timestamp.

If this is not done in gl2ps, then my workarounds include embedding a
patched version of gl2ps.c, using faketime, or post-processing the .ps
files to edit the timestamp strings. None of these are particularly
appealing options.

My original report may have sounded like a "why not?" request. So just
to be clear, I do have a real need for gl2ps to produce postscript files
that are deterministic.

Cheers,

-- 
mike


signature.asc
Description: PGP signature


Bug#895055: ITP: python-sounddevice -- Python module to play and record sound

2018-04-06 Thread Yaroslav Halchenko
Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: python-sounddevice
  Version : 0.3.10
  Upstream Author : Matthias Geier 
* URL : http://python-sounddevice.readthedocs.io/
* License : MIT/X
  Programming Lang: Python
  Description : Python module to play and record sound

 This Python module provides bindings for the PortAudio library and a
 few convenience functions to play and record NumPy arrays containing
 audio signals.

 Needed for upcoming updated package of PsychoPy



Bug#895011: [debhelper-devel] Bug#895011: dh_installwm: please mention --all in manual page

2018-04-06 Thread Nicolas Boulenguez
> Hmm, isn't this covered by the "common debhelper options" section in
> the debhelper(7) manual page?  I believe that this is the reason it is
> not mentioned in any of the separate commands' manual pages.

You may be confusing "shared options" and "common options".
The section you are refering to starts with:

  The following command line options are supported by some debhelper
  programs. See the man page of each program for a complete
  explanation of what each option does.

Other tools either document --all or ignore it.



Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

2018-04-06 Thread Felix Natter
hello Security Team,

here are the CVE-2018-169 security updates for jessie and stretch:

[jessie]
https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=jessie-CVE-2018-169
(jessie-CVE-2018-169 branch)

[stretch]
https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169
(stretch-CVE-2018-169 branch)

Both are tested:
- builds
- activation log message is seen
- Save and Load XML works

In what format would you like the "tested packages"? *.deb?

Here is the corrsponding upstream commit:
https://github.com/freeplane/freeplane/commit/a5dce7f9f

The debdiffs are attached.

@Markus: Did you already submit the update for wheezy?

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!


jessie-CVE-2018-169.debdiff
Description: Binary data


stretch-CVE-2018-16.debdiff
Description: Binary data


Bug#894549: debhelper: dh_usrlocal may remove a direct subdirectory of /usr/local

2018-04-06 Thread Nicolas Boulenguez
> use the "hashref" based autoscript?

The attached updated diff switches
from strings and sed expressions
back to arrays (again) and hashrefs (new).

> The "justdirs" is supposed to be in "opposite" order of "dirs"
> ("justdirs" are in "removal order" while "dirs" are in "creation order")
> but as far as I can see that ordering is not preserved in the patch.

They are not supposed to be in opposite order.
Actually, @justdirs contains strictly less elements than @dirs.
During the same recursive traversal,

* @dirs is appended each parent before its childs. This is the order
  in which subdirectories are discovered in $tmpdir/usr/local/ during
  the traversal, so it is by construction compatible with later
  re-creation during install.

* @justdirs is appended all childs before their parent.  The list is
  constructed in the same code part actually removing the directory
  from $tmpdir/usr/local/, so this order is compatible with
  uninstallation

* In both lists, the childs are traversed in alphabetical order to
  ensure reproducible scripts. This is unrelated with the two previous
  constraints.

If this explanation seems convincing, please paste it inside comments
before the File::Find::file recursion.

> I think dh_usrlocal might be ready for some test cases to avoid future
> breakage.

The attached test.sh implements some suggested tests.
--- a/dh_usrlocal
+++ b/dh_usrlocal
@@ -77,54 +77,49 @@
 
 	if (-d "$tmp/usr/local") {
 		my (@dirs, @justdirs);
-		find({bydepth => 1,
-		  no_chdir => 1,
+		find({no_chdir => 1,
+		  preprocess => sub {
+			# Ensure a reproducible traversal.
+			return sort @_;
+		  },
+		  postprocess => sub {
+			# Uninstall, unless a direct child of /usr/local.
+			$_ = $File::Find::dir;
+			s!^\Q$tmp\E!!;
+			push @justdirs, $_ if m!/usr/local/.*/!;
+			# Remove a directory after its childs.
+			doit('rmdir', $File::Find::dir);
+		  },
 		  wanted => sub {
+			# rmdir would fail later anyways.
+			error("${File::Find::name} is not a directory")
+if not -d $File::Find::name;
+			# Install directory before its childs.
 			my $fn = $File::Find::name;
-			if (-d $fn) {
-my $user = 'root';
-my $group = 'staff';
-my $mode = '02775';
-if (should_use_root()) {
-	my $stat = stat $fn;
-	$user = getpwuid $stat->uid;
-	$group = getgrgid $stat->gid;
-	$mode = sprintf "%04lo", ($stat->mode & 0);
-	if ($stat->uid == 0 && $stat->gid == 0) {
-		$group = 'staff';
-		$mode = '02775';
-	}
+			$fn =~ s!^\Q$tmp\E!!;
+			return if $fn eq '/usr/local';
+			if (should_use_root()) {
+my $stat = stat $File::Find::dir;
+if ($stat->uid == 0 && $stat->gid == 0) {
+	push @dirs, "$fn 02775 root staff";
+} else {
+	my $user = getpwuid $stat->uid;
+	my $group = getgrgid $stat->gid;
+	my $mode = sprintf "%04lo", ($stat->mode & 0);
+	push @dirs, "$fn $mode $user $group";
 }
-
-
-
-$fn =~ s!^\Q$tmp\E!!;
-return if $fn eq '/usr/local';
-
-# @dirs is in parents-first order for dir creation...
-unshift @dirs, "$fn $mode $user $group";
-# ...whereas @justdirs is depth-first for removal.
-push @justdirs, $fn;
-doit('rmdir', $_);
-			}
-			else {
-warning("$fn is not a directory");
+			} else {
+push @dirs, "$fn 02775 root staff";
 			}
 		  }}, "$tmp/usr/local");
-		doit('rmdir', "$tmp/usr/local");
-	
-		my $bs = "\\"; # A single plain backslash
-		my $ebs = $bs x 2; # Escape the backslash from the shell
+
 		# This constructs the body of a 'sed' c\ expression which
 		# is parsed by the shell in double-quotes
-		my $dirs = join("$ebs\n", sort @dirs);
-		pop @justdirs; # don't remove directories directly in /usr/local
-		my $justdirs = join("$ebs\n", reverse sort @justdirs);
 		if (! $dh{NOSCRIPTS}) { 
 			autoscript($package,"postinst", "postinst-usrlocal",
-   "/#DIRS#/ c${ebs}\n${dirs}");
+   { 'DIRS' => join ("\n", @dirs)}) if @dirs;
 			autoscript($package,"prerm", "prerm-usrlocal",
-   "/#JUSTDIRS#/ c${ebs}\n${justdirs}") if length $justdirs;
+   { 'JUSTDIRS' => join ("\n", @justdirs)}) if @justdirs;
 		}
 	}
 }


test.sh
Description: Bourne shell script


Bug#895035: osc: crashes with memory corruption when using new libssl1.1

2018-04-06 Thread Kurt Roeckx
On Fri, Apr 06, 2018 at 07:54:44PM +0100, Simon McVittie wrote:
> On Fri, 06 Apr 2018 at 19:44:18 +0200, Kurt Roeckx wrote:
> > On Fri, Apr 06, 2018 at 01:58:03PM +0100, Simon McVittie wrote:
> > > This is probably a bug in libssl1.1 or in python-m2crypto, but I'm
> > > reporting it against osc for now, because that's the only place I know
> > > how to reproduce it at the moment. X-Debbugs-Cc'd to the lower-level
> > > packages' maintainers.
> > 
> > Can you run it under valgrind?
> 
> There's a lot of Python-related noise, but yes. It looks like a
> use-after-free in m2crypto, maybe?

It at least doesn't look like an OpenSSL issue at first look.


Kurt



Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

2018-04-06 Thread Alex ARNAUD

Hello Rogério,

Could it be possible for you to provide us a PDF to help us to reproduce 
the issue?


Do you have tried to check if "canberra-gtk-module" is installed?

Best regards,
Alex.

Le 06/04/2018 à 05:28, Rogério Brito a écrit :

Package: atril
Version: 1.20.1-1
Severity: minor

Hi.

First of all, please, change this bug report to anothe package if
appropriate (but I don't see this problem with evince, though).

Second, I am setting the severity of this bug to minor only because I
haven't seen further problems with it and I am not using atril to read epub
books (and I don't know if that would change the result).

When running atril with *any* PDF file, I see a stack trace like the
following:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ atril test.pdf
Gtk-Message: 00:14:29.194: Failed to load module "canberra-gtk-module"
Gtk-Message: 00:14:29.564: Failed to load module "canberra-gtk-module"
1   0x7f598ae7b807 
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x17) 
[0x7f598ae7b807]
2   0x7f598eff3adf /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x766adf) 
[0x7f598eff3adf]
3   0x7f598eff533c /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x76833c) 
[0x7f598eff533c]
4   0x7f598f12ce0a /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x89fe0a) 
[0x7f598f12ce0a]
5   0x7f598f12ab1d /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x89db1d) 
[0x7f598f12ab1d]
6   0x7f598ee7e5fb /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x5f15fb) 
[0x7f598ee7e5fb]
7   0x7f598ee7eee5 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x5f1ee5) 
[0x7f598ee7eee5]
8   0x7f598ae965c3 
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3WTF7RunLoop11performWorkEv+0xf3)
 [0x7f598ae965c3]
9   0x7f598aebf619 
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18(+0xe51619) 
[0x7f598aebf619]
10  0x7f598bcad0f5 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x155) 
[0x7f598bcad0f5]
11  0x7f598bcad4c0 /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) 
[0x7f598bcad4c0]
12  0x7f598bcad7d2 /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xc2) 
[0x7f598bcad7d2]
13  0x7f598aebffc0 
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3WTF7RunLoop3runEv+0x100)
 [0x7f598aebffc0]
14  0x7f598f2e1628 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0xa54628) 
[0x7f598f2e1628]
15  0x7f598e1d8a87 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) 
[0x7f598e1d8a87]
16  0x5609d14e095a 
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess(_start+0x2a) 
[0x5609d14e095a]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The first line is the most curious (WTFCrash :-))... Just for reference,
when I run with evince, this is what I get:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ evince test.pdf
Gtk-Message: 00:22:50.170: Failed to load module "canberra-gtk-module"
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If any further information is needed, please let me know.


Thanks,

Rogério.

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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 atril depends on:
ii  atril-common 1.20.1-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  libatk1.0-0  2.28.1-1
ii  libatrildocument31.20.1-1
ii  libatrilview31.20.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libcaja-extension1   1.20.0-2
ii  libgail-3-0  3.22.29-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-4
ii  libgtk-3-0   3.22.29-2
ii  libice6  2:1.0.9-2
ii  libjavascriptcoregtk-4.0-18  2.20.0-2
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libsecret-1-00.18.6-1
ii  libsm6   2:1.2.2-1+b3
ii  libsoup2.4-1 2.62.0-1
ii  libwebkit2gtk-4.0-37 2.20.0-2
ii  libx11-6 2:1.6.5-1
ii  libxml2  2.9.4+dfsg1-6.1
ii  mate-desktop-common  1.20.0-1
ii  

Bug#895034: wordpress: versions 4.9.4 and earlier are affected by three security issues

2018-04-06 Thread Salvatore Bonaccorso
Hi Craig,

On Thu, Apr 05, 2018 at 09:12:45PM +1000, Craig Small wrote:
> Source: wordpress
> Version: 4.9.4-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> WordPress 4.9.5 fixes 3 security issues:
> 1) Don't treat localhost as same host by default.
> 2) Use safe redirects when redirecting the login page if SSL is forced.
> 3) Make sure the version string is correctly escaped for use in generator 
> tags.
> 
> The patches are:
> 1) 42894 - https://core.trac.wordpress.org/changeset/42894
> 2) 42892 - https://core.trac.wordpress.org/changeset/42892
> 3) 42893 - https://core.trac.wordpress.org/changeset/42893

Have you requested CVEs for those three new issues?

Regards,
Salvatore



Bug#894561: add new variable

2018-04-06 Thread Bastian Blank
Hi

On Wed, Apr 04, 2018 at 10:36:46AM +0200, Thomas Lange wrote:
> FAI_PACKAGE_NAME_CHECK=0
> or
> DISABLE_PACKAGE_NAME_CHECK=1
> 
> Which variable name is better? Do you have any better name?

You don't have an existing naming schema for that?

I would go for the later, or you decide that all variables should have
FAI as prefix.

> If the variable is not set at all, the default will be to check the
> variable names.

Parse error.

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1



Bug#818609: lintian: python-script-but-no-python-dep false positive

2018-04-06 Thread Chris Lamb
Hi Neil,

> $ /usr/share/lava-server/debian-dev-build.sh -p lava-server

I tried building as per your instructions but it starting re-cloning
a bunch of stuff within the chroot, after installing fuse, grub, node
etc. etc. …

Could you simply provide this lava-dev .deb somewhere publically? :)

> the upstream helper script builds whatever is in the git working
> tree, without fussing about uncommitted changes like git-bp.

As an aside: I understand that git-buildpackage is not for everyone,
but here is a great example of where common, shared tools would really
have a benefit and would save this round trip to fixing this issue. I
mean, this script seems a *lot* more fuss than just committing first
or passing --git-ignore-new … !)


Best wishes,

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



Bug#895054: apt-listchanges: [INTL:nl] Dutch translation of debconf messages

2018-04-06 Thread Frans Spiesschaert
 
 
Package: apt-listchanges 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of apt-listchanges
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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


Bug#895053: xsol FTCBFS: invokes the build architecture compiler

2018-04-06 Thread Helmut Grohne
Source: xsol
Version: 0.31-13
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xsol fails to cross build from source, because it uses the make default
$(CC). Please include /usr/share/dpkg/buildtools.mk to set up a proper
$(CC). The attached patch implements that.

Helmut
diff --minimal -Nru xsol-0.31/debian/changelog xsol-0.31/debian/changelog
--- xsol-0.31/debian/changelog  2017-01-21 16:53:38.0 +0100
+++ xsol-0.31/debian/changelog  2018-04-06 20:21:27.0 +0200
@@ -1,3 +1,10 @@
+xsol (0.31-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let buildtools.mk provide a cross CC. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 06 Apr 2018 20:21:27 +0200
+
 xsol (0.31-13) unstable; urgency=medium
 
   * Fix manpage typo.
diff --minimal -Nru xsol-0.31/debian/rules xsol-0.31/debian/rules
--- xsol-0.31/debian/rules  2013-06-21 09:13:45.0 +0200
+++ xsol-0.31/debian/rules  2018-04-06 20:21:26.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+
 # Use hardening options to build the package
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 LIBS+=-lXm -lXt -lX11


Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

2018-04-06 Thread Ævar Arnfjörð Bjarmason

On Fri, Apr 06 2018, Eric Wong wrote:

> Ævar Arnfjörð Bjarmason  wrote:
>> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the
>> original report.
>
> Thanks for taking a look at this.  Also https://bugs.debian.org/894997
>
>> --- a/perl/Git.pm
>> +++ b/perl/Git.pm
>> @@ -554,7 +554,7 @@ sub get_record {
>>  my ($fh, $rs) = @_;
>>  local $/ = $rs;
>>  my $rec = <$fh>;
>> -chomp $rec if defined $rs;
>> +chomp $rec if defined $rs and defined $rec;
>
> I'm struggling to understand the reason for the "defined $rs"
> check.  I think it was a braino on my part and meant to use:
>
>   chomp $rec if defined $rec;

Whether this makes any sense is another question, but you seem to have
explicitly meant this at the time. The full function definition with
documentation:

=item get_record ( FILEHANDLE, INPUT_RECORD_SEPARATOR )

Read one record from FILEHANDLE delimited by INPUT_RECORD_SEPARATOR,
removing any trailing INPUT_RECORD_SEPARATOR.

=cut

sub get_record {
my ($fh, $rs) = @_;
local $/ = $rs;
my $rec = <$fh>;
chomp $rec if defined $rs;
$rec;
}

It doesn't make to remove the trailing record separator if it's not
defined, otherwise we'd be coercing undef to "\n" while at the same time
returning multiple records. But then of course the only user of this
with an "undef" argument just does:

chomp($log_entry{log} = get_record($log_fh, undef));

So we could also remove that chomp(), adn not check defined $rs, but IMO
it's cleaner & more consistent this way.



Bug#895043: libgtk-3-0: unexplained downstream patch disables VIQR input method in Vietnamese locales

2018-04-06 Thread Simon McVittie
On Fri, 06 Apr 2018 at 13:34:32 -0400, Jeremy Bicha wrote:
> On Fri, Apr 6, 2018 at 10:03 AM, Simon McVittie  wrote:
> > The Debian packages for GTK+ 2 and GTK+ 3 both have the patch quoted
> > below, which changes the upstream default behaviour.
>
> The Ubuntu bug is
> https://launchpad.net/bugs/191451

Thanks, that provides a lot more context. I've changed the commit message
to the following:

> From: Ming Hua 
> Date: Thu, 13 Mar 2008 18:09:25 -0500
> Subject: Do not use VIQR input method for vi locale by default
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> 
> In the Vietnamese Quoted-Readable input method, punctuation following a
> base letter is converted into diacritical marks, for example a( → ă.
> (See .)
> A 2008 bug report in Ubuntu argued that this is a problematic default,
> particularly when typing passwords, where the effect of the punctuation
> is non-obvious.
> 
> According to the bug reporter, VIQR is popular with Vietnamese users
> living elsewhere in the world, where Vietnamese keyboards are unlikely
> to be readily available, but is not a popular choice within Vietnam,
> where the Telex or VNI input modes are preferred.
> 
> [smcv: Add a summary of the Ubuntu bug]
> Bug-Debian: https://bugs.debian.org/895043
> Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/191451
> Forwarded: no

Is that a good summary of the situation?

Vietnamese users: Is this a change we should be asking for upstream, for
GTK+ 4? I would prefer it to either go upstream, or be reverted: having a
permanent Debian-specific change seems bad.

At the moment, we apply this patch to GTK+ 2 and GTK+ 3, but not to GTK+ 4.

smcv



Bug#887903: akregator suddenly crashes. nouveau_fence.c: No such file or directory

2018-04-06 Thread s3v
Upgrading to 4:17.12.3-1 doesn't solve the problem but the crash vanishes after
switching from nouveau to Nvidia proprietary drivers.

Regards



Bug#893251: Pending fixes for bugs in the jabref package

2018-04-06 Thread pkg-java-maintainers
tag 893251 + pending
thanks

Some bugs in the jabref package are closed in revision
1c74bebda74c84722b17531dc5b1c5145ea7a199 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jabref.git/commit/?id=1c74beb

Commit message:

Make (build) dependency on liblog4j2-java versioned.

Closes: #893251



Bug#895035: [Pkg-openssl-devel] Bug#895035: osc: crashes with memory corruption when using new libssl1.1

2018-04-06 Thread Kurt Roeckx
On Fri, Apr 06, 2018 at 01:58:03PM +0100, Simon McVittie wrote:
> Package: osc
> Version: 0.162.1-1
> Severity: grave
> Justification: osc tool becomes mostly unusable
> 
> This is probably a bug in libssl1.1 or in python-m2crypto, but I'm
> reporting it against osc for now, because that's the only place I know
> how to reproduce it at the moment. X-Debbugs-Cc'd to the lower-level
> packages' maintainers.
> 
> Steps to reproduce:
> 
> * have an account on any OBS instance (I used :
>   anyone can register there, but an account is required to use the API)
> * be in a temporary directory
> * rm -fr binaries
> * osc -A https://api.opensuse.org getbinaries openSUSE:Leap:15.0 \
>   hello standard x86_64
>   (or some project/package combination that exists on your OBS)
> 
> Expected result: osc downloads hello into ./binaries
> 
> Actual result: osc usually segfaults in glibc malloc-related functions,
> probably due to memory corruption; sometimes glibc detects the memory
> corruption itself and aborts instead.
> 
> Workaround: Downgrading libssl1.1 to 1.1.0f-3+deb9u2 from stable-security
> makes osc work correctly, so presumably this is a behaviour change
> between 1.1.0f and 1.1.0h, either a regression or something that triggers
> a pre-existing bug in python-m2crypto (or possibly osc).

Can you run it under valgrind?


Kurt



Bug#893251: jabref 3.8 is started with OpenJDK 9 instead of 8

2018-04-06 Thread gregor herrmann
Control: tag -1 + pending

On Fri, 06 Apr 2018 11:13:02 +0200, Emmanuel Bourg wrote:

> > Should we reassign this bug to liblog4j2-java (+ affects jabref)? I
> > suppose the problem doesn't exclusively hit jabref?
> I've uploaded liblog4j2-java/2.10.0-2 that should work with Java 8.
> Could you give it a try?

That's excellent news, thank you!

Let me try ...

During build I see some scary output:

Malformed class file [module-info.class] in jar 
[/usr/share/maven-repo/org/apache/logging/log4j/log4j-api/debian/log4j-api-debian.jar]
 found on classpath, which means that this class will cause a compile error if 
referenced in a source file. Gradle 5.0 will no longer allow malformed classes 
on compile classpath.
at 
org.gradle.api.internal.changedetection.state.JvmClassHasher.visit(JvmClassHasher.java:154)
at 
org.gradle.api.internal.changedetection.state.JvmClassHasher.hashJarFile(JvmClassHasher.java:122)
at 
org.gradle.api.internal.changedetection.state.DefaultCompileClasspathSnapshotter.normaliseFileElement(DefaultCompileClasspathSnapshotter.java:75)
at 
org.gradle.api.internal.changedetection.state.AbstractFileCollectionSnapshotter$FileCollectionVisitorImpl.visitCollection(AbstractFileCollectionSnapshotter.java:144)
at 
org.gradle.api.internal.file.AbstractFileCollection.visitRootElements(AbstractFileCollection.java:234)
at 
org.gradle.api.internal.file.CompositeFileCollection.visitRootElements(CompositeFileCollection.java:185)
at 
org.gradle.api.internal.changedetection.state.AbstractFileCollectionSnapshotter.snapshot(AbstractFileCollectionSnapshotter.java:71)
at 
org.gradle.api.internal.changedetection.rules.AbstractNamedFileSnapshotTaskStateChanges.buildSnapshots(AbstractNamedFileSnapshotTaskStateChanges.java:87)
at 
org.gradle.api.internal.changedetection.rules.AbstractNamedFileSnapshotTaskStateChanges.(AbstractNamedFileSnapshotTaskStateChanges.java:54)
at 
org.gradle.api.internal.changedetection.rules.InputFilesTaskStateChanges.(InputFilesTaskStateChanges.java:28)
at 
org.gradle.api.internal.changedetection.rules.TaskUpToDateState.(TaskUpToDateState.java:55)
at 
org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.getStates(DefaultTaskArtifactStateRepository.java:164)
at 
org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.isUpToDate(DefaultTaskArtifactStateRepository.java:79)
at 
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:51)
at 
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at 
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at 
org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
at 
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at 
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at 
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at 
org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at 
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at 
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
at 
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
at 
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 

Bug#894824: popt FTCBFS: api-sanity-checker dependency unsatisfiable

2018-04-06 Thread Michael Jeanson
On 2018-04-04 11:24, Helmut Grohne wrote:
> Source: popt
> Version: 1.16-11
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> popt fails to cross build from source, because its build dependency on
> api-sanity-checker is unsatisfiable. In general, Architecture: all
> packages can never satisfy cross Build-Depends unless marked Multi-Arch:
> foreign. In this case however, api-sanity-checker is entirely
> unnecessary, because it is only used for testing and we cannot test
> during cross builds anyway. Thus annotating the dependency with
>  is sufficient to get satisfiable cross Build-Depends again. I
> used reproducible builds to verify that this change does not affect the
> resulting binary packages. Please consider applying the attached patch.
> 
> Helmut
> 

Hi,

Thanks for the patch, I've applied it in git, I'll wait on some other
changes to upload unless this is blocking something on your side?

Regards,

Michael



Bug#895043: libgtk-3-0: unexplained downstream patch disables VIQR input method in Vietnamese locales

2018-04-06 Thread Jeremy Bicha
On Fri, Apr 6, 2018 at 10:03 AM, Simon McVittie  wrote:
> The Debian packages for GTK+ 2 and GTK+ 3 both have the patch quoted
> below, which changes the upstream default behaviour. It was applied with
> the comment "imported from Ubuntu" and no further information. As far as
> I can tell, instead of enabling the VIQR Vietnamese input method in vi_*
> locales, it leaves it disabled in all locales unless explicitly enabled.
> It isn't clear why this change is desirable.
>
> If this change is good for Vietnamese-speaking users of Debian and Ubuntu,
> we should explain why in the patch metadata, apply it to GTK+ 4, and (if
> the reason isn't completely Debian-specific) send it upstream. Conversely,
> if it's a bad change, we should consider reverting it.
>
> Can anyone shed some light on this?

The Ubuntu bug is
https://launchpad.net/bugs/191451

But I have no idea if the patch is still valid.

Thanks,
Jeremy Bicha



Bug#895052: gtkgl2 FTCBFS: configures for the build architecture

2018-04-06 Thread Helmut Grohne
Source: gtkgl2
Version: 2.0.1-2.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gtkgl2 fails to cross build from source, because it configures for the
build architecture. The easiest way to pass the relevant --host flag is
letting dh_auto_configure do it. After doing so, gtkgl2 cross builds
successfully. Please consider applying the attached patch.

Helmut
diff -u gtkgl2-2.0.1/debian/changelog gtkgl2-2.0.1/debian/changelog
--- gtkgl2-2.0.1/debian/changelog
+++ gtkgl2-2.0.1/debian/changelog
@@ -1,3 +1,11 @@
+gtkgl2 (2.0.1-2.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes:
+#-1)
+
+ -- Helmut Grohne   Fri, 06 Apr 2018 19:33:19 +0200
+
 gtkgl2 (2.0.1-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u gtkgl2-2.0.1/debian/rules gtkgl2-2.0.1/debian/rules
--- gtkgl2-2.0.1/debian/rules
+++ gtkgl2-2.0.1/debian/rules
@@ -7,7 +7,7 @@
 build-stamp:
dh_testdir
dh_autoreconf
-   ./configure --prefix=/usr --with-lib-GL
+   dh_auto_configure -- --with-lib-GL
$(MAKE) LIBS+=-lX11
touch $@
 


Bug#894967: mac-robber FTCBFS: uses the build architecture compiler

2018-04-06 Thread Helmut Grohne
Hi Raphaël,

On Fri, Apr 06, 2018 at 10:07:30AM +0200, Raphael Hertzog wrote:
> it's not the first time that you are submitting such fixes. Would you like
> to be added to the pkg-security team so that you can commit (and even upload
> if you feel like) your fixes directly ?

Thanks for your offer, but I think it doesn't scale. My fixes are in no
way specific to pkg-security. I'd love to fix things directly, but
that'd require more uniformity from the archive. Possibly dgit can
provide that one day.

At the moment, I even file patches for orphaned packages rather than
uploading them directly. I think this has two benefits:
 * I do not make such packages appear as maintained when they are not.
 * Someone else reviews my patch and catches the occasional error. The
   present feedback I get suggests that around 1% to 3% of my patches
   contain mistakes.

My present workflow with using bugs.d.o as a patch distribution system
scales somewhat. In parallel to submitting patches, I try to turn
generic fixes into lintian tags[1]. Do you have any suggestions to
improving that?

Helmut

[1] E.g.

https://lintian.debian.org/tags/autotools-pkg-config-macro-not-cross-compilation-safe.html

https://lintian.debian.org/tags/pkg-config-unavailable-for-cross-compilation.html
https://lintian.debian.org/tags/multiarch-foreign-pkgconfig.html
https://lintian.debian.org/tags/multiarch-foreign-shared-library.html
https://lintian.debian.org/tags/multiarch-foreign-static-library.html



Bug#894872: astyle: symbols adjustments to support build with -O3

2018-04-06 Thread Matteo Cypriani
Hi Steve,

On Wed, 04 Apr 2018 21:54:49 -0700
Steve Langasek  wrote:
> While the 3.1-1 upload includes adjustments to the symbols files
> specifically for supporting builds with -O3, version 3.1-1 still
> fails to build in Ubuntu on ppc64el where the port is built with -O3
> by default.
> 
> Please find attached a patch which handles making all the necessary
> remaining template symbols 'optional'.

Thank you very much for the patch, I'll include it in the next upload.

  Matteo


pgphN_CbZAemd.pgp
Description: PGP signature


Bug#893523: transition: qtbase-opensource-src

2018-04-06 Thread Lisandro Damián Nicanor Pérez Meyer
I'm afraid that I won't be able to start the transition until monday.
I *think* Dmitry is more or less in the same position. If that means
giving the go to another transition and deACK this one please go
ahead.

Sorry for the inconvenience.

P.S.: sorry for the double posts, I forgot to CC the bug.



Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

2018-04-06 Thread Eric Wong
Ævar Arnfjörð Bjarmason  wrote:
> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the
> original report.

Thanks for taking a look at this.  Also https://bugs.debian.org/894997

> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -554,7 +554,7 @@ sub get_record {
>   my ($fh, $rs) = @_;
>   local $/ = $rs;
>   my $rec = <$fh>;
> - chomp $rec if defined $rs;
> + chomp $rec if defined $rs and defined $rec;

I'm struggling to understand the reason for the "defined $rs"
check.  I think it was a braino on my part and meant to use:

chomp $rec if defined $rec;



Bug#895051: liblldb-6.0-dev: missing API/*.h files

2018-04-06 Thread Sylvestre Ledru
Hello


On 06/04/2018 17:50, Nishanth Aravamudan wrote:
> Package: llvm-toolchain-6.0
> Version: 1:6.0-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic ubuntu-patch
> 
> Dear Maintainer,
> 
> In Ubuntu, the attached patch was applied to achieve the following:

Thanks for the patch!
I updated the vcs with it!

S



Bug#890305: cppcheck still depends on python:any

2018-04-06 Thread Joachim Reichel
tag 890305 -pending
tag 890305 +help
thanks

Hi,

I did the suggested change but I still get

Depends: [...] python3:any (>= 3.5~), python:any, python3-pygments

in the cppcheck binary package. And there is still the lintian warning about the
old python version.

Is there something else that needs to be done?

  Joachim



Bug#894289: [Git][med-team/picard-tools][master] 5 commits: Fixed the build failure with Java 9 (Closes: #894329)

2018-04-06 Thread Andreas Tille
Hi Emmanuel

On Fri, Apr 06, 2018 at 03:36:30PM +, Emmanuel Bourg wrote:
> Emmanuel Bourg pushed to branch master at Debian Med / picard-tools

Thanks a lot.  However, I think it makes sense to start with htsjdk
where I upgraded to latest upstream in Git.  If we fix this we could
upgrade to latest picard-tools (with new problems to expect - I
never experienced a smooth version upgrade of both libs.  So help
for htsjdk would be really appreciated.

Kind regards

Andreas.

-- 
http://fam-tille.de



Bug#895051: liblldb-6.0-dev: missing API/*.h files

2018-04-06 Thread Nishanth Aravamudan
Package: llvm-toolchain-6.0
Version: 1:6.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

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

  * debian/patches/install-lldb-sb-headers.patch: Install lldb's
SB headers (pr36630).  Thanks to Pavel Labath .
LP: #1761009


Thanks for considering the patch.

*** /tmp/tmp5CXR4z/llvm-toolchain-6.0_1:6.0-1ubuntu2.debdiff
diff -Nru llvm-toolchain-6.0-6.0/debian/patches/install-lldb-sb-headers.patch 
llvm-toolchain-6.0-6.0/debian/patches/install-lldb-sb-headers.patch
--- llvm-toolchain-6.0-6.0/debian/patches/install-lldb-sb-headers.patch 
1969-12-31 16:00:00.0 -0800
+++ llvm-toolchain-6.0-6.0/debian/patches/install-lldb-sb-headers.patch 
2018-04-05 15:05:20.0 -0700
@@ -0,0 +1,58 @@
+From 8f577000b2fe2f5bf5d08e352a2f15f9421f9c82 Mon Sep 17 00:00:00 2001
+From: Pavel Labath 
+Date: Thu, 8 Mar 2018 15:52:46 +
+Subject: [PATCH] Install lldb's SB headers (pr36630)
+
+These were removed in r309021 in what looks like an accidentally
+committed change. This brings them back.
+
+I also rename the header component to lldb-headers (instead of
+lldb_headers) to match the llvm style and add a special
+install-lldb-headers target, which installs just the headers.
+
+git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@327016 
91177308-0d34-0410-b5e6-96231b3b80d8
+Origin: upstream, 
https://github.com/llvm-mirror/lldb/commit/8f577000b2fe2f5bf5d08e352a2f15f9421f9c82.patch
+Bug-Ubuntu: https://launchpad.net/bugs/1761009
+Forwarded: will be done by Nishanth Aravamudan
+Last-Update: 2018-04-05
+
+--- llvm-toolchain-6.0-6.0.orig/lldb/cmake/modules/LLDBConfig.cmake
 llvm-toolchain-6.0-6.0/lldb/cmake/modules/LLDBConfig.cmake
+@@ -277,27 +277,31 @@ include_directories(BEFORE
+ 
+ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
+   install(DIRECTORY include/
+-COMPONENT lldb_headers
++COMPONENT lldb-headers
+ DESTINATION include
+ FILES_MATCHING
+ PATTERN "*.h"
+ PATTERN ".svn" EXCLUDE
+ PATTERN ".cmake" EXCLUDE
+ PATTERN "Config.h" EXCLUDE
+-PATTERN "lldb-*.h" EXCLUDE
+-PATTERN "API/*.h" EXCLUDE
+ )
+ 
+   install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/
+-COMPONENT lldb_headers
++COMPONENT lldb-headers
+ DESTINATION include
+ FILES_MATCHING
+ PATTERN "*.h"
+ PATTERN ".svn" EXCLUDE
+ PATTERN ".cmake" EXCLUDE
+-PATTERN "lldb-*.h" EXCLUDE
+-PATTERN "API/*.h" EXCLUDE
+ )
++
++  add_custom_target(lldb-headers)
++  set_target_properties(lldb-headers PROPERTIES FOLDER "Misc")
++
++  if (NOT CMAKE_CONFIGURATION_TYPES)
++add_llvm_install_targets(install-lldb-headers
++ COMPONENT lldb-headers)
++  endif()
+ endif()
+ 
+ if (NOT LIBXML2_FOUND AND NOT (CMAKE_SYSTEM_NAME MATCHES "Windows"))
diff -Nru llvm-toolchain-6.0-6.0/debian/patches/series 
llvm-toolchain-6.0-6.0/debian/patches/series
--- llvm-toolchain-6.0-6.0/debian/patches/series2018-02-27 
00:08:44.0 -0800
+++ llvm-toolchain-6.0-6.0/debian/patches/series2018-04-05 
15:03:28.0 -0700
@@ -47,3 +47,4 @@
 silent-llvm-isel-fuzzer.diff
 test-keep-alive.diff
 sparc64-add-missing-tls-get-addr.diff
+install-lldb-sb-headers.patch


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

Kernel: Linux 4.15.0-13-generic (SMP w/4 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)
LSM: AppArmor: enabled

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd



Bug#894961: closed by Roland Gruber <p...@rolandgruber.de> (Re: Bug#894961: ldap-account-manager: missing dependencies on php-xml and php-zip)

2018-04-06 Thread Thorsten Glaser
found 894961 5.5-1+deb9u1
thanks

This is still a grave RC bug in stable, though.



Bug#895008: kicad: can't start pcbnew

2018-04-06 Thread Carsten Schoenert
Hello Leonardo and Aurel,

On Fri, Apr 06, 2018 at 03:39:30PM +0200, Leonardo Canducci wrote:
> Just to clarify: I'm running sid and gnome with debian repository only.
> Kicad did work a couple of months ago.
> 
> Downgrading python-wxgtk3.0 fixes the problem here too.
> 
> Leonardo
> 
> 2018-04-06 15:19 GMT+02:00 Aurelien Jacobs :
> 
> > Hello,
> >
> > I can confirm this issue.
> >
> > Since I upgraded my sid install today, pcbnew fails to start with those
> > kind of messages :
...
> > I reproduced this issue on 2 different machines (both updated to latest
> > sid today).
> >
> > It seems to be realted to latest version of python-wxgtk3.0.
> > When I downgrade this package to 3.0.2.0+dfsg-6 (from buster) pcbnew
> > starts working again.

thanks for checking this, I'm on testing and there isn't this issue
happen.
src:wxpython3.0 is depending on src:wxwidgets3.0-gtk3 and this package
is on a way of a transition [1]. So one day kicad would be binNMU'ed. I'll
have a look at this on the weekend.

[1] https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

Regards
Carsten



Bug#895050: RFP: pleroma -- an ostatus/activitypub-compatible microblogging server

2018-04-06 Thread Jeff Cliff
Package: wnpp
Severity: wishlist

* Package name: pleroma
  Version : 0.9.0
  Upstream Author : lain 
* URL : https://git.pleroma.social/pleroma/pleroma
* License : AGPL-3.0
  Programming Lang: elixir
  Description : an fediverse-compatible microblogging web/gopher server

Pleroma is a microblogging server software that can federate (= exchange
messages with) other servers that support the same federation standards
(OStatus and ActivityPub) - ie the Fediverse. This includes GNU Social,
Mastodon, Peertube, Friendica and other servers. Using pleroma you can host a
server for yourself/your friends/your community and stay in control of your
online identity, but still exchange messages with people on larger servers
across the fediverse.

This package should not be confused with the pleroma frontend (pleroma-fe).

Pleroma claims to be built on "a lot less technology than Mastodon", to be
"High-performance", "light" on memory usage, and to be capable of running on a
Rasperry Pi.  Pleroma also supports gopher.

Pleroma is ActivityPub even in its internal data structures. Activities are
actually saved as JSON in the database, so the external and internal
representations are the same. Why should you care? Because it makes it easier
for Pleroma to add new Activity types. Adding a new Activity type in Pleroma
involves no database changes, you just need to add some rules how to handle
them.  This will make it easier to add new features in the future.



Bug#895049: RM: bisho -- ROM; dead upstream

2018-04-06 Thread Ying-Chun Liu (PaulLiu)
Package: ftp.debian.org
Severity: normal

Dear ftp-master,

Please remove bisho package from Debian. This package is from Moblin
project which is already dead for about 8 years.

There's currently no replacement in Debian for this package. But seems
unnecessary.

Yours,
Paul

-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature


Bug#894667: beep, #894667 and information leakage

2018-04-06 Thread Richard Kettlewell
Hi,

There's an additional issue, which is that the ability to open arbitrary
caller-chosen files represents at least an information leak, and maybe
more serious. See the comments starting at:
https://github.com/johnath/beep/issues/11#issuecomment-379215473

ttfn/rjk



Bug#895016: soundconverter: Soundconverter AssertionError

2018-04-06 Thread jEsuSdA 8)

El 06/04/18 a las 12:36, James Cowgill escribió:

Control: tags -1 moreinfo

Hi,

On 06/04/18 11:06, jesusda wrote:

Package: soundconverter
Version: 3.0.0-1
Severity: important

Dear Maintainer,

Soundconverter does not load, showing an AssertionError and crashing.

I've tested the stable, testing and sid versions and all them chrashed. Maybe
the error was caused by any dependency I'm not able to find.

[...]

Versions of packages soundconverter depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  gir1.2-glib-2.0  1.56.0-2
ii  gir1.2-gstreamer-1.0 1.12.4-1
ii  gir1.2-gtk-3.0   3.22.29-2
ii  gstreamer1.0-plugins-base1.14.0-dmo1

Try installing all gstreamer related packages from the official Debian
repositories instead of from deb-multimedia.org.

James


Updating **ALL**  the **GSTREAMER PYTHON**  packages solves the issue.

Sorry. ;)

Thanks a lot!



Bug#895048: git: git verify-commit is broken

2018-04-06 Thread Joerg Jaspert
Package: git
Version: 1:2.11.0-3+deb9u2
Severity: normal

Dear Maintainer,

one for upstream:

git verify-commit has an interesting and unexpected behaviour.
That is, setting gpg.program I can instruct git to use that program for
gpg actions. According to manpage:

 gpg.program
 Use this custom program instead of "gpg" found on $PATH
 when making or verifying a PGP signature. The program
 must support the same command-line interface as GPG,
 namely, to verify a detached signature, "gpg --verify
 $file - <$signature" is run, and the program is expected
 to signal a good signature by exiting with code 0, and
 to generate an ASCII-armored detached signature, the
 standard input of "gpg -bsau $key" is fed with the
 contents to be signed, and the program is expected to
 send the result to its standard output.

One would expect that exit 0 for a verify means "This signature is
fine".

For gpg verify-commit that DOES NOT MATTER. You can exit 1, and it happily
goes of saying all is fine. YOu can exit 0 and it happily goes of saying
"bad, broken".

It MUST HAVE gnupg status like output on stdout and goes to parse it.
So if you send it a line of (with a trailing space)

[GNUPG:] GOODSIG 

it will ALWAYS exit 0, no matter what your actual gpg.program said.
If you do not send this (or anything at all), it ALWAYS exit 1.

This is wrong according to the manpage. If i set gpg.program, exit 0 of
that means "sig is good". Not "parse some random text somewhere and see
yourself" magic.

-- 
bye, Joerg



  1   2   3   >