Bug#916256: gitlab-runner fails when it tries to pull docker image gitlab-runner-helper:11.2.0

[Daniel Gomez]

Package: gitlab-runner
Version: 11.2.0+dfsg-2
Severity: important

Dear Maintainer,

Summary
---
gitlab-runner executes docker for the first time it tries to download docker
image gitlab-runner-helper:11.2.0
but it fails because repository does not exists with this tag name.

Related links:
* https://hub.docker.com/r/gitlab/gitlab-runner-helper/tags/

Expected behavior
-
gitlab-runner should be able to find the right tag name of gitlab-runner-
helper.

Error
-
ERRO[] Docker executor: prebuilt image helpers will be loaded from
/var/lib/gitlab-runner.
Running with gitlab-runner 11.2.0 (11.2.0)
Using Docker executor with image registry.gitlab.com/:latest ...
Pulling docker image gitlab-runner-helper:11.2.0 ...
ERROR: Job failed: Error response from daemon: pull access denied for gitlab-
runner-helper, repository does not exist or may require 'docker login'
(executor_docker.go:166:1s)
FATAL: Error response from daemon: pull access denied for gitlab-runner-helper,
repository does not exist or may require 'docker login'
(executor_docker.go:166:1s)

Command
---
$ gitlab-runner exec docker --docker-volumes $PWD/builds:/builds build

Workaround
--
Download gitlab-runner-helper 11.2.0 version using x86_64-6d9dd510 tag and
rename it locally.
$ docker run --rm -it gitlab/gitlab-runner-helper:x86_64-6d9dd510
$ docker tag  gitlab/gitlab-runner-helper:x86_64-6d9dd510 gitlab-runner-
helper:11.2.0
Now you can execute:
$ gitlab-runner exec docker --docker-volumes $PWD/builds:/builds build



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

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

Versions of packages gitlab-runner depends on:
ii  adduser  3.118
ii  ca-certificates  20170717
ii  git  1:2.19.2-1
ii  libc62.27-8
ii  lsb-base 10.2018112800

Versions of packages gitlab-runner recommends:
ii  cdebootstrap  0.7.7+b1
ii  xz-utils  5.2.2-1.3

Versions of packages gitlab-runner suggests:
ii  docker.io  18.06.1+dfsg1-2

-- Configuration Files:
/etc/gitlab-runner/config.toml [Errno 13] Permission denied: 
'/etc/gitlab-runner/config.toml'

-- no debconf information

Bug#916201: prboom-plus-game-server: Documentation bug: no TCP network, UDP instead

[Fabian Greffrath]

Hi Lucio,

Lucio Crusca wrote:
> The manpage says it works with TCP/IP networks. However, upon trying to
> figure the firewall rules out, I realized prboom-plus-game-server actually
> uses UDP, not TCP, and, obviously, the client side does the same, so this
> bug applies to the client manpage too.

thanks for caring about the documentation for prboom-plus!

Since upstream (Andrey) is quite inactive at the moment, would you mind
preparing a patch that I could suggest to him?

Thanks!

 - Fabian

Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

[vic...@gmail.com]

filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916255 for dash

vic...@gmail.com  於 2018年12月12日 週三 下午1:56寫道：
>
> It's dash. dash source src/expand.c, function expmeta calls to
> readdir(), which may throw EOVERFLOW when some field size doesn't fit,
> and add AC_SYS_LARGEFILE to configure.ac fixes this problem.
>
> === BEGIN dash TRACE ===
> Tracing started.
> waitforjob(%0) called
> pid 15608, evaltree(0xfffef918: 0, 1) called
> evalcommand(0xfffef918, 1) called
> expandmeta(0xfffef948, 3) called
> expandmeta(0xfffef968, 3) called
> expandmeta str: /usr/share/vim/*
> expmeta(/usr/share/vim/*, 16, 0) called
> expmeta metaflag 1
> expmeta opendir(/usr/share/vim/)
> expmeta begin loop
> expmeta break loop: readdir error, errno 75
> expmeta end loop
> evalcommand arg: ls
> evalcommand arg: /usr/share/vim/*
> searchexec "ls" returns "/usr/bin/ls"
> === END dash TRACE ===
>
> You-Sheng Yang

Bug#916255: dash may fail to expand wildcard path correctly

[You-Sheng Yang]

Package: dash
Version: 0.5.10.2-1
Severity: important
Tags: patch upstream

Dear Maintainer,

A path expansion issue was firstly found while installing
python3-docutils/sid on armel/armhf/mips/mipsel, and has been reported
as bug 916225. Dash failed to expand the line for exe in
/usr/share/docutils/scripts/python3/* in python3-docutils' postinst
script, and failed the installation. With some more investigation into
this issue, I got following trace messages for dash:

Tracing started.
waitforjob(%0) called
pid 15608, evaltree(0xfffef918: 0, 1) called
evalcommand(0xfffef918, 1) called
expandmeta(0xfffef948, 3) called
expandmeta(0xfffef968, 3) called
expandmeta str: /usr/share/vim/*
expmeta(/usr/share/vim/*, 16, 0) called
expmeta metaflag 1
expmeta opendir(/usr/share/vim/)
expmeta begin loop
expmeta break loop: readdir error, errno 75
expmeta end loop
evalcommand arg: ls
evalcommand arg: /usr/share/vim/*
searchexec "ls" returns "/usr/bin/ls"

/usr/share/vim/* here shows such expansion failure doesn't only occur to
python3-docutils' postinst script, but also many other places. The errno
75 (EOVERFLOW) shows readdir() call may fail when one of the fields to
return cannot be represented correctly, so large file support should be
enabled whenever available.

A merge request has been sent to
https://salsa.debian.org/debian/dash/merge_requests/2 .

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916225

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

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

Versions of packages dash depends on:
ii  debianutils  4.8.6
ii  dpkg 1.19.2
ii  libc62.28-2

dash recommends no packages.

dash suggests no packages.

-- debconf information excluded

Bug#916125: hunspell: "hunspell -D" does not print loaded dictionary

[Rene Engelhard]

Hi,

On Wed, Dec 12, 2018 at 06:09:26AM +0100, can...@free.fr wrote:
> > Or fixing emacs, see
> > https://github.com/hunspell/hunspell/issues/608#issuecomment-444955561
> > ff.
> 
> Well, hunspell's manpage definitely asserts that -D should print the loaded 
> dictionary path.
> Adding a null file is more of a hack than a proper fix.

Jup, was just pointing out that there apparently have been commits in
emacs to work around this.

Regards,

Rene

Bug#916254: gravitywars FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: gravitywars
Version: 1.102-34
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gravitywars fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - makes gravitywars cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru gravitywars-1.102/debian/changelog 
gravitywars-1.102/debian/changelog
--- gravitywars-1.102/debian/changelog  2015-11-21 21:34:43.0 +0100
+++ gravitywars-1.102/debian/changelog  2018-12-12 07:13:38.0 +0100
@@ -1,3 +1,10 @@
+gravitywars (1.102-34.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 12 Dec 2018 07:13:38 +0100
+
 gravitywars (1.102-34) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru gravitywars-1.102/debian/rules 
gravitywars-1.102/debian/rules
--- gravitywars-1.102/debian/rules  2015-11-21 21:34:43.0 +0100
+++ gravitywars-1.102/debian/rules  2018-12-12 07:13:37.0 +0100
@@ -4,7 +4,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) USE_SDL=1
+   dh_auto_build -- USE_SDL=1
 
 override_dh_install:
cp GravityWars101 $(CURDIR)/debian/gravitywars/usr/games/gravitywars

Bug#916253: efax FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: efax
Version: 1:0.9a-19.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

efax fails to cross build from source, because it passes the build
architecture compiler "gcc" to make. Using the one supplied from dpkg's
buildtools.mk fixes that. The upstream build system then runs the build
architectrue strip, which breaks generation of -dbgsym packages and
DEB_BUILD_OPTIONS=nostrip beyond breaking cross compilation. The
attached patch enables cross building efax-dbgsym. Please consider
applying it.

Helmut
diff -u efax-0.9a/debian/changelog efax-0.9a/debian/changelog
--- efax-0.9a/debian/changelog
+++ efax-0.9a/debian/changelog
@@ -1,3 +1,12 @@
+efax (1:0.9a-19.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Supply $(CC) from dpkg's buildtools.mk.
++ Defer stripping to dh_strip.
+
+ -- Helmut Grohne   Wed, 12 Dec 2018 07:07:06 +0100
+
 efax (1:0.9a-19.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u efax-0.9a/debian/rules efax-0.9a/debian/rules
--- efax-0.9a/debian/rules
+++ efax-0.9a/debian/rules
@@ -10,6 +10,7 @@
 #export DH_VERBOSE=1
 
 include /usr/share/dpatch/dpatch.make
+-include /usr/share/dpkg/buildtools.mk
 
 
 CFLAGS = -Wall -g -DDEBIAN
@@ -26,8 +27,8 @@
 build-stamp: patch-stamp
dh_testdir
 
-   $(MAKE) efax CC="gcc" CFLAGS="$(CFLAGS)" 
-   $(MAKE) efix CC="gcc" CFLAGS="$(CFLAGS)"
+   $(MAKE) efax CC="$(CC)" CFLAGS="$(CFLAGS)" 
+   $(MAKE) efix CC="$(CC)" CFLAGS="$(CFLAGS)"
 
touch build-stamp
 
--- efax-0.9a.orig/Makefile
+++ efax-0.9a/Makefile
@@ -25,11 +25,9 @@
 
 efax:  efax.o efaxlib.o efaxio.o efaxos.o efaxmsg.o
$(CC) -o efax $(LDFLAGS) efax.o efaxlib.o efaxio.o efaxos.o efaxmsg.o
-   strip efax
 
 efix:  efix.o efaxlib.o efaxmsg.o
$(CC) -o efix $(LDFLAGS) efix.o efaxlib.o efaxmsg.o
-   strip efix
 
 install:
cp fax efax efix $(BINDIR)

Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

[vic...@gmail.com]

It's dash. dash source src/expand.c, function expmeta calls to
readdir(), which may throw EOVERFLOW when some field size doesn't fit,
and add AC_SYS_LARGEFILE to configure.ac fixes this problem.

=== BEGIN dash TRACE ===
Tracing started.
waitforjob(%0) called
pid 15608, evaltree(0xfffef918: 0, 1) called
evalcommand(0xfffef918, 1) called
expandmeta(0xfffef948, 3) called
expandmeta(0xfffef968, 3) called
expandmeta str: /usr/share/vim/*
expmeta(/usr/share/vim/*, 16, 0) called
expmeta metaflag 1
expmeta opendir(/usr/share/vim/)
expmeta begin loop
expmeta break loop: readdir error, errno 75
expmeta end loop
evalcommand arg: ls
evalcommand arg: /usr/share/vim/*
searchexec "ls" returns "/usr/bin/ls"
=== END dash TRACE ===

You-Sheng Yang

Bug#916252: cinnamon: new upstream release(s)

[Andres Salomon]

Package: cinnamon
Version: 3.8.8-1
Severity: wishlist

Hi,

There's a bunch of new upstream releases of cinnamon.
Cinnamon 4.0.5 is the most recent version, although if
you don't want to upgrade to 4.x. before Buster, there's
also a 3.8.9 release.  It would be great to get these
into Debian.

Thanks,
Andres

Bug#916125: hunspell: "hunspell -D" does not print loaded dictionary

[candeb]

> $ apt-file search flyspell
> dictionaries-common:
> /usr/share/dictionaries-common/site-elisp/flyspell.el
> emacs-common: /usr/share/emacs/25.2/lisp/textmodes/flyspell.elc
> emacs-el: /usr/share/emacs/25.2/lisp/textmodes/flyspell.el.gz
> emacspeak:
> /usr/share/emacs/site-lisp/emacspeak/lisp/emacspeak-flyspell.el
> jed-extra: /usr/share/jed/jed-extra/drop-in/flyspell.sl
> xemacs21-basesupport:
> /usr/share/xemacs21/xemacs-packages/lisp/text-modes/flyspell.elc
> xemacs21-basesupport-el:
> /usr/share/xemacs21/xemacs-packages/lisp/text-modes/flyspell.el.gz
> 
> Erm, which one of these is the real(tm) one?

For emacs 25 (which I use):
emacs-common: /usr/share/emacs/25.2/lisp/textmodes/flyspell.elc
source in emacs-el: /usr/share/emacs/25.2/lisp/textmodes/flyspell.el.gz


> 
> > Reverting the commit, or moving the leave logic a little later,
> > solves this.
> 
> Or fixing emacs, see
> https://github.com/hunspell/hunspell/issues/608#issuecomment-444955561
> ff.

Well, hunspell's manpage definitely asserts that -D should print the loaded 
dictionary path.
Adding a null file is more of a hack than a proper fix.

Cheers,
Itaï.

Bug#916251: dvd+rw-tools: FTBFS with glibc 2.28

[Logan Rosen]

Source: dvd+rw-tools
Version: 7.1-13
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

dvd+rw-tools currently fails to build from source with glibc 2.28
because they changed the way the 'major' and 'minor' macros can be
accessed. [1] Specifically:

* The macros 'major', 'minor', and 'makedev' are now only available from
  the header ; not from  or various other
  headers that happen to include .  These macros are rarely
  used, not part of POSIX nor XSI, and their names frequently collide with
  user code; see https://sourceware.org/bugzilla/show_bug.cgi?id=19239 for
  further explanation.

   is a GNU extension.  Portable programs that require
  these macros should first include , and then include
   if __GNU_LIBRARY__ is defined.

We saw the following errors while building in Ubuntu accordingly:
growisofs.o growisofs_mmc.o  -lpthread -o growisofs
/usr/bin/ld: growisofs.o: in function `find_raw_device':
./growisofs.c:658: undefined reference to `major'
/usr/bin/ld: ./growisofs.c:659: undefined reference to `minor'
/usr/bin/ld: growisofs.o: in function `grab_sg':
./growisofs.c:704: undefined reference to `minor'
collect2: error: ld returned 1 exit status

This is reproducible in sid as well.

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

  * debian/patches/glibc-2.28.patch: Fix FTBFS with glibc >= 2.28.

Thanks for considering the patch.

Logan Rosen

[1] https://www.sourceware.org/ml/libc-alpha/2018-08/msg3.html

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru dvd+rw-tools-7.1/debian/patches/glibc-2.28.patch 
dvd+rw-tools-7.1/debian/patches/glibc-2.28.patch
--- dvd+rw-tools-7.1/debian/patches/glibc-2.28.patch1969-12-31 
19:00:00.0 -0500
+++ dvd+rw-tools-7.1/debian/patches/glibc-2.28.patch2018-12-11 
23:42:00.0 -0500
@@ -0,0 +1,26 @@
+--- a/growisofs.c
 b/growisofs.c
+@@ -444,6 +444,10 @@
+ #include 
+ #include "mp.h"
+ 
++#if defined(__GNU_LIBRARY__)
++# include 
++#endif
++
+ #if defined(__unix) || defined(__unix__)
+ # include 
+ # include 
+--- a/transport.hxx
 b/transport.hxx
+@@ -53,6 +53,10 @@
+ #define ENV_LOCALE".OCP"
+ #endif
+ 
++#if defined(__GNU_LIBRARY__)
++# include 
++#endif
++
+ #include "asctable.h"
+ 
+ #define CREAM_ON_ERRNO_NAKED(s)   \
diff -Nru dvd+rw-tools-7.1/debian/patches/series 
dvd+rw-tools-7.1/debian/patches/series
--- dvd+rw-tools-7.1/debian/patches/series  2018-10-09 10:05:01.0 
-0400
+++ dvd+rw-tools-7.1/debian/patches/series  2018-12-11 23:38:51.0 
-0500
@@ -10,3 +10,4 @@
 ignore_pseudo_overwrite.patch
 10-blue-ray-bug713016.patch
 fix_burning_bd-r_discs.patch
+glibc-2.28.patch

Bug#902443: [Pkg-kde-extras] Bug#902443: Bug#902443: Please add DAEMON_OPS to the service file

[Scott Kitterman]

On Wednesday, December 12, 2018 05:00:32 AM Diederik de Haas wrote:
> On woensdag 12 december 2018 04:47:37 CET Scott Kitterman wrote:
> > > My reaction was in response to "DAEMON_OPTS is never defined"
> > 
> > OK. I guess I should have been clearer:
> > 
> > Never defined in the systemd unit file.
> 
> I agree. Consequently the patch seems incomplete.
> 
> Now your other remark also 'lands' with me. The differences between init
> systems seem undesirable to me. Probably best fixed upstream.

Unfortunately, they are intentional (different design goals/philosophies), so 
it's not particularly solvable (and let's not have this devolve into another 
sysv init versus systemd thread - they are what they are).

Scott K

Bug#916250: android-platform-art: FTBFS with ld --as-needed

[Logan Rosen]

Source: android-platform-art
Version: 8.1.0+r23-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

android-platform-art currently fails to build from source with ld
--as-needed, which is by default in Ubuntu. This linker argument
requires that libraries be placed in the order that they are needed,
after the objects that require them. Libraries should not be colocated
with LDFLAGS - those are specifically options for the linker itself.

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

  * debian/lib{art,sigchain}.mk: Move libraries to LIBS variable at the
end of linking command to fix FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru android-platform-art-8.1.0+r23/debian/libart.mk 
android-platform-art-8.1.0+r23/debian/libart.mk
--- android-platform-art-8.1.0+r23/debian/libart.mk 2018-12-05 
14:19:06.0 -0500
+++ android-platform-art-8.1.0+r23/debian/libart.mk 2018-12-11 
23:02:50.0 -0500
@@ -400,6 +400,8 @@
   -L/usr/lib/$(DEB_HOST_MULTIARCH)/android \
   -Ldebian/out \
   -Wl,-rpath=/usr/lib/$(DEB_HOST_MULTIARCH)/android \
+  -shared -Wl,-soname,$(NAME).so.0
+LIBS += \
   -lbacktrace \
   -lbase \
   -lcutils \
@@ -411,12 +413,11 @@
   -lpthread \
   -lsigchain \
   -lz \
-  -lziparchive \
-  -shared -Wl,-soname,$(NAME).so.0
+  -lziparchive
 
 debian/out/$(NAME).so.0: $(OBJECTS_CXX) $(OBJECTS_ASSEMBLY)
mkdir --parents debian/out
-   $(CXX) -o $@ $(LDFLAGS) $^
+   $(CXX) -o $@ $(LDFLAGS) $^ $(LIBS)
ln -s $(NAME).so.0 debian/out/$(NAME).so
 
 clean:
@@ -432,4 +433,4 @@
clang -o $@ $(CFLAGS) $(CPPFLAGS) $^
 
 operator_out.cc: $(SOURCES_OPERATOR)
-   python3 tools/generate-operator-out.py runtime $^ > $@
\ No newline at end of file
+   python3 tools/generate-operator-out.py runtime $^ > $@
diff -Nru android-platform-art-8.1.0+r23/debian/libsigchain.mk 
android-platform-art-8.1.0+r23/debian/libsigchain.mk
--- android-platform-art-8.1.0+r23/debian/libsigchain.mk2018-11-14 
00:22:16.0 -0500
+++ android-platform-art-8.1.0+r23/debian/libsigchain.mk2018-12-11 
23:02:50.0 -0500
@@ -4,12 +4,12 @@
 SOURCES := $(foreach source, $(SOURCES), sigchainlib/$(source))
 
 CPPFLAGS += -Isigchainlib
-LDFLAGS += \
+LDFLAGS += -shared -Wl,-soname,$(NAME).so.0
+LIBS += \
   -ldl \
-  -lpthread \
-  -shared -Wl,-soname,$(NAME).so.0
+  -lpthread
 
 debian/out/$(NAME).so.0: $(SOURCES)
mkdir --parents debian/out
-   $(CXX) -o $@ $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $^
-   ln -s $(NAME).so.0 debian/out/$(NAME).so
\ No newline at end of file
+   $(CXX) -o $@ $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $^ $(LIBS)
+   ln -s $(NAME).so.0 debian/out/$(NAME).so

Bug#902443: [Pkg-kde-extras] Bug#902443: Please add DAEMON_OPS to the service file

[Diederik de Haas]

On woensdag 12 december 2018 04:47:37 CET Scott Kitterman wrote:
> > My reaction was in response to "DAEMON_OPTS is never defined"
> 
> OK. I guess I should have been clearer:
> 
> Never defined in the systemd unit file.

I agree. Consequently the patch seems incomplete.

Now your other remark also 'lands' with me. The differences between init 
systems seem undesirable to me. Probably best fixed upstream.

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

Bug#902443: [Pkg-kde-extras] Bug#902443: Bug#902443: Bug#902443: Please add DAEMON_OPS to the service file

[Scott Kitterman]

On Wednesday, December 12, 2018 04:43:26 AM Diederik de Haas wrote:
> On woensdag 12 december 2018 02:48:25 CET Scott Kitterman wrote:
> > >It is defined in /etc/init.d/quasselcore (with value "", but one can
> > >change that)
> > 
> > Right, but that's for sysv init, not the systemd service file.  I don't
> > believe systemd looks in /etc/init.d at all.
> > 
> > Did you test this?
> 
> I didn't test it. I just noticed that it was defined for sysv-init and used
> there and afaict, Alf was requesting a similar functionality for systemd.
> (I don't even know how it could/should be done in systemd)
> 
> My reaction was in response to "DAEMON_OPTS is never defined"

OK. I guess I should have been clearer:

Never defined in the systemd unit file.

Scott K

Bug#865851: Info received (drf-extensions FTBFS with Django 1.11)

[Wookey]

On 2018-12-07 04:03 +, Debian Bug Tracking System wrote:

I have now uploaded drf-extensions 0.4.0-1.1 to delayed/10, so this
should become sorted in due course if everyone is happy with that.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#915094: Additional information.

[Theodore Y. Ts'o]

On Sat, Dec 01, 2018 at 12:23:51AM +, Gong S. wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> >Can you tell what version of the kernel you are using?
> 4.19.0-trunk-amd64. I guess that I am not getting any semblance of support 
> with an experimental kernel.
> However, when I upgrade from 4.19.0-rc7 to 4.19.0-trunk, the problem is still 
> there, so it does not look like a kernel problem.

That certainly doesn't mean that it's not a kernel bug; it just means
that it's a kernel bug that wasn't fixed between 4.19-rc7 and 4.19.

The inline_data feature isn't enabled by default because we're not
100% confidence that it's fully rock solid.  We are regularly running
regression testing on that configuration, and while there are some
test failures with inline_data enabled that aren't there with the
default options, none of them have caused processes to get stuck:

ext4/4k: 444 tests, 2 failures, 42 skipped, 4442 seconds
  Failures: ext4/034 generic/388
ext4/encrypt: 512 tests, 1 failures, 123 skipped, 2638 seconds
  Failures: ext4/034
ext4/dioread_nolock: 443 tests, 2 failures, 42 skipped, 4338 seconds
  Failures: ext4/034 generic/388

vs

ext4/adv: 448 tests, 4 failures, 48 skipped, 4149 seconds
  Failures: ext4/034 generic/399 generic/477 generic/519

So basically, at the moment I can't really recommend this feature for
general use --- although this particular failure which you've reported
is a new one for me.

> >How/when did you enable this feature?
> Just me poking around options in the man page. I assume that I can save some 
> space with small files.
> >It looks like you were trying to upgrade some packages when you ran into 
> >this issue.
> It happened to random processes. It happened to "mandb", "perl" and 
> "chromium" most frequently. Sometimes it happens to very basic processes like 
> "ls" or "rm" (happened once when I try to remove Chromium's cache folder).
> Also, if a process is stuck, the processes will be stuck again if I invoke 
> that program again.

Is this true even if you reboot?   What if you force an fsck check on the file 
system?

   - Ted

Bug#902443: [Pkg-kde-extras] Bug#902443: Bug#902443: Please add DAEMON_OPS to the service file

[Diederik de Haas]

On woensdag 12 december 2018 02:48:25 CET Scott Kitterman wrote:
> >It is defined in /etc/init.d/quasselcore (with value "", but one can
> >change that)
> 
> Right, but that's for sysv init, not the systemd service file.  I don't
> believe systemd looks in /etc/init.d at all.
> 
> Did you test this?

I didn't test it. I just noticed that it was defined for sysv-init and used 
there and afaict, Alf was requesting a similar functionality for systemd.
(I don't even know how it could/should be done in systemd)

My reaction was in response to "DAEMON_OPTS is never defined"

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

Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

[vic...@gmail.com]

Simon McVittie  於 2018年12月12日 週三 上午4:22寫道：
>
> Control: tags -1 + moreinfo
>
> On Wed, 12 Dec 2018 at 00:45:34 +0800, You-Sheng Yang wrote:
> > Somehow dash failed to expand /usr/share/docutils/scripts/python3/*, so
> > that exec variable is simply '/usr/share/docutils/scripts/python3/*',
> > which is later expanded as extra dozens of update-alternatives'
> > arguments. To be more detailed, at the time executed, dash path
> > expansion still worked as it's able to expand /usr/share/* and
> > /usr/share/docutils*, but it failed to expand /usr/share/docutils/* and
> > any other pattern with a /usr/share/docutils/ prefix. Files has been
> > installed correctly and accessible, but dash simply unable to expand
> > such globs.
>
> The obvious question is: why don't basic operations like glob() work
> on the system in question?
>
> Is there something unusual on the system where these expansions failed,
> like a non-standard filesystem or kernel, or weird permissions
> (directories not 0755 or files not 0755 or 0644) anywhere under
> /usr/share/docutils?

They have been correctly installed. Only expanding /usr/share/docutils/* and
any other expanding attempt with a /usr/share/docutils/ prefix failed.
Actually many other directories under /usr/share has the same problem in dash.
Not just /usr/share/docutils.

> You mentioned Docker containers. What is the host system and how are
> these Docker containers configured? If /usr is an overlayfs or similar,
> failing to evaluate a glob might be a bug in the overlay implementation?

I was running docker images from docker.io/vicamo/debian:sid- on the
same host, so the same host configuration applies to all available Debian Sid
images. Other paths have the same issue, with or without python3-docutils
installed. I think the root cause should be in dash, but since ptrace is not
available inside a qemu-based foreign arch container, it would probably take
some time to hunt for the root cause.

> (Since 32-bit ARM and MIPS are not exactly fast machines, I would
> suggest building your kernels with dpkg-buildpackage -B and using an
> x86_64 machine to build documentation, which would maybe sidestep this
> by not needing docutils at all.)

Just like you, I don't like work-arounds, either. Anyway, the problem is
python3-docutils fails to install on container based Sid
armel/armhf/mips/mipsel environments. I don't own a real arm32/MIPS board, so
I cannot verify if this also happens outside a qemu jail. But while many
debian installations today are actually container images, I'd still say this
is critical enough that I would recommend a quick fix to unblock all other
people while the issue being investigated.

> > Replace that path glob with a `find ... -type f` fixes the problem.
>
> Sorry, I don't think python3-docutils can be expected to swap a path
> expansion for a subprocess that ought to be equivalent to work around
> whatever is going on with these systems - and definitely not without
> understanding what it is that's going wrong and why.
>
> smcv

You-Sheng Yang

Bug#916188: misc-manuals: Fixes

[Theodore Y. Ts'o]

tags 916188 +pending
thanks

Thanks for sending the patch.  I've applied it to the e2fsprogs maint
branch.

- Ted

Bug#915942: libext2fs2: ships empty directory /usr/share/doc/libext2fs

[Theodore Y. Ts'o]

tags 915942 +pending
thanks

On Sat, Dec 08, 2018 at 04:18:38AM +0100, Andreas Beckmann wrote:
> Package: libext2fs2
> Version: 1.44.4-2
> Severity: minor
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> due to a typo in debian/rules, line 388, the libext2fs2 package ships
> the empty directory /usr/share/doc/libext2fs (missing the SOVERSION
> in the name).

Oops!!  Thanks for pointing this out!

> PS: and now I still need to understand why this disappears on some
> stretch->buster upgrade paths ...

For stretch these documents were installed in /usr/share/e2fslibs.
This was a screw up as part of the rename of e2fslibs to libext2fs2.

- Ted

Bug#916249: luksipc: Should depend on cryptsetup-bin, not cryptsetup

[Matthew Gabeler-Lee]

Package: luksipc
Version: 0.04-2+b1
Severity: normal

luksipc just needs the binaries (/sbin/cryptsetup) from cryptsetup-bin, it
doesn't need the boot process integration from cryptsetup.  As such it
should depend just on the bin package.

This is useful if one is using it with disk images or the like and don't
want update-initramfs to constantly produce scary warnings about not being
able to find your boot device if it isn't encrypted.

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages luksipc depends on:
ii  cryptsetup  2:1.7.3-4
ii  dmsetup 2:1.02.137-2
ii  libc6   2.27-8

luksipc recommends no packages.

luksipc suggests no packages.

-- no debconf information

Bug#902443: [Pkg-kde-extras] Bug#902443: Please add DAEMON_OPS to the service file

[Scott Kitterman]

On December 12, 2018 1:09:17 AM UTC, Diederik de Haas  
wrote:
>On Tue, 11 Dec 2018 11:03:06 -0500 Scott Kitterman
> 
>wrote:
>> What does this accomplish?  As far as I can see, DAEMON_OPTS is never
>defined 
>> (defaults isn't sourced and AIUI there's no easy way to do that).
>
>It is defined in /etc/init.d/quasselcore (with value "", but one can
>change 
>that)

Right, but that's for sysv init, not the systemd service file.  I don't believe 
systemd looks in /etc/init.d at all.

Did you test this?

Scott K

Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)

[Elimar Riesebieter]

* Thorsten Glaser  [2018-12-10 18:18 +0100]:

> found 870396 1.1.7-1
> thanks
> 
> Here is an updated debdiff, as usual. It still fixes the segfaults.

Why don't you try to push your patches upstream? I won't because you
are the author and you know what you did.

Elimar
-- 
  On the keyboard of life you have always
  to keep a finger at the escape key;-)


signature.asc
Description: PGP signature

Bug#916248: ITP: hcxtools -- Small set of tools convert packets from captures for the use with latest hashcat or John the Ripper

[Dererk]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

   Package name: hcxtools
Version: 5.1.0
Upstream Author: ZerBea 
URL: https://github.com/ZerBea/hcxtools 
License: MIT 
Description: Small toolkit for capturing wlan traffic and conversion to 
hashcat or John the Ripper formats. 
 

-- 
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most tunefs man 
pages)

Bug#916247: elogind: user sessions have issues if elogind is restarted

[Arthur Marsh]

Package: elogind
Version: 239.3-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

running 

service elogind restart

from within a desktop session, elogind restarted alright, but with the
next audio track that I attempted to play I received the error:

Failed to create secure directory (/run/user/1000/pulse): 
No such file or directory

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

logging out of the user session and logging in again resulted in audio 
playback working again.

   * What was the outcome of this action?
   * What outcome did you expect instead?

If restarting elogin impacts user sessions like this, a reinstall or 
upgrade via aptitude should warn of the possible impacts and not restart
the servic unless the user accepts this.


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


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux beowulf/ceres
Release:10
Codename:   n/a
Architecture: x86_64

Kernel: Linux 4.20.0-rc6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages elogind depends on:
ii  dbus 1.12.10-1+devuan1
ii  debconf  1.5.69
ii  libacl1  2.2.52-3+b1
ii  libc62.28-2
ii  libelogind0  239.3-1
ii  libselinux1  2.8-1+b1
pn  libudev1 
ii  lsb-base 10.2018112800

Versions of packages elogind recommends:
ii  policykit-1  0.105-22

elogind suggests no packages.

-- no debconf information

Bug#902443: Please add DAEMON_OPS to the service file

[Diederik de Haas]

On Tue, 11 Dec 2018 11:03:06 -0500 Scott Kitterman  
wrote:
> What does this accomplish?  As far as I can see, DAEMON_OPTS is never defined 
> (defaults isn't sourced and AIUI there's no easy way to do that).

It is defined in /etc/init.d/quasselcore (with value "", but one can change 
that)

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

Bug#916246: patroni doesnt bootstrap

[Peter.Chubb]

Package: patroni
Version: 1.5.1-2
Severity: normal

Dear Maintainer,

I edited /etc/patroni/config.yml (copy appended), installed a 
brand new postgresql, ran patroni /etc/patroni/config.yml and see:
2018-12-12 11:40:43,456 INFO: Lock owner: None; I am test-db
2018-12-12 11:40:43,468 INFO: trying to bootstrap a new cluster
2018-12-12 11:40:43,471 INFO: Lock owner: None; I am test-db
2018-12-12 11:40:43,471 INFO: not healthy enough for leader race
2018-12-12 11:40:43,472 INFO: bootstrap in progress
2018-12-12 11:40:43,472 INFO: Running custom bootstrap script: 
/usr/share/patroni/pg_createcluster_patroni
Creating new PostgreSQL cluster 11/testdb ...
/usr/lib/postgresql/11/bin/initdb -D /var/lib/postgresql/11/testdb --auth-local 
peer --auth-host md5
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_AU.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/11/testdb ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

/usr/lib/postgresql/11/bin/pg_ctl -D /var/lib/postgresql/11/testdb -l 
logfile start

Ver Cluster Port Status OwnerData directoryLog file
11  testdb  5433 down   postgres /var/lib/postgresql/11/testdb 
/var/log/postgresql/postgresql-11-testdb.log
2018-12-12 11:40:44,816 INFO: postmaster pid=928
10.13.1.77:5432 - no response
2018-12-12 11:40:44,842 INFO: removing initialize key after failed attempt to 
bootstrap the cluster
2018-12-12 11:40:44,852 INFO: renaming data directory to 
/var/lib/postgresql/11/testdb_2018-12-12-11-40-44
2018-12-12 11:40:44,952 INFO: Lock owner: None; I am test-db
Traceback (most recent call last):
  File "/usr/bin/patroni", line 11, in 
load_entry_point('patroni==1.5.1', 'console_scripts', 'patroni')()
  File "/usr/lib/python3/dist-packages/patroni/__init__.py", line 182, in main
return patroni_main()
  File "/usr/lib/python3/dist-packages/patroni/__init__.py", line 149, in 
patroni_main
patroni.run()
  File "/usr/lib/python3/dist-packages/patroni/__init__.py", line 114, in run
logger.info(self.ha.run_cycle())
  File "/usr/lib/python3/dist-packages/patroni/ha.py", line 1275, in run_cycle
info = self._run_cycle()
  File "/usr/lib/python3/dist-packages/patroni/ha.py", line 1183, in _run_cycle
return self.post_bootstrap()
  File "/usr/lib/python3/dist-packages/patroni/ha.py", line 1079, in 
post_bootstrap
self.cancel_initialization()
  File "/usr/lib/python3/dist-packages/patroni/ha.py", line 1074, in 
cancel_initialization
raise PatroniException('Failed to bootstrap cluster')
patroni.exceptions.PatroniException: 'Failed to bootstrap cluster'

config.yml is:

scope: "11-testdb"
namespace: "/postgresql-common/"
name: test-db

#etcd:
#  host: 127.0.0.1:2379

consul:
  host: 127.0.0.1:8500
#  host: https://127.0.0.1:8500

#zookeeper:
#  hosts: 127.0.0.1:2181

restapi:
  listen: 10.13.1.77:8008
  connect_address: 10.13.1.77:8008
#  certfile: /etc/ssl/certs/ssl-cert-snakeoil.pem
#  keyfile: /etc/ssl/private/ssl-cert-snakeoil.key
#  authentication:
#username: username
#password: password

# ctl:
#   insecure: false # Allow connections to SSL sites without certs
#   certfile: /etc/ssl/certs/ssl-cert-snakeoil.pem
#   cacert: /etc/ssl/certs/ssl-cacert-snakeoil.pem

bootstrap:
  # Custom bootstrap method
  method: pg_createcluster
  pg_createcluster:
command: /usr/share/patroni/pg_createcluster_patroni

  # this section will be written into Etcd:///config after 
initializing new cluster
  # and all other cluster members will use it as a `global configuration`
  dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
#master_start_timeout: 300
#synchronous_mode: false
#standby_cluster:
#  host: 127.0.0.1
#  port: 
#  primary_slot_name: patroni
postgresql:
  use_pg_rewind: true
  use_slots: true
  parameters:
wal_level: hot_standby
hot_standby: "on"
wal_keep_segments: 8
max_wal_senders: 10
max_replication_slots: 10
wal_log_hints: "on"
#archive_mode: "on"
#archive_timeout: 1800s
#archive_command: mkdir -p ../wal_archive && test ! -f 
../wal_archive/%f && cp %p ../wal_archive/%f
#  recovery_conf:
#restore_command: cp ../wal_archive/%f %p

  # some desired options for 'initdb'
  initdb:  # Note: It needs to be a list (some options n

Bug#916245: ITP: websocket-api -- Java API for WebSocket (JSR-356)

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: websocket-api
  Version : 1.1
  Upstream Author : Oracle
* URL : https://github.com/javaee/websocket-spec
* License : CDDL-1.1 or GPL-2 with Classpath exception
  Programming Lang: Java
  Description : Java API for WebSocket (JSR-356)

Java API for WebSocket (JSR-356) defines a standard API for the development
of websocket applications, both on the server side as well as on the Java
client side.

The Java WebSocket API is already partially packaged in libservlet3.1-java,
but this package is tied to src:tomcat8 which won't be part of Buster. The
new tomcat9 package no longer builds the JavaEE APIs (Servlet, JSP,EL and
WebSocket APIs) and separate API packages are introduced to replace them.

This package will be maintained by the Java Team.

Bug#900774: O: opendkim

[Scott Kitterman]

Updating to orphan the package, fundamentally I've lost motivation on this 
package.  I still think it's important, but I don't have the time/priority for 
it.  I should also have mentioned there is a shared library, so you have to 
know how to do shared library packaging.

> opendkim is the major open source C implementation of the DKIM (Domain Keys
> Identified Mail) protocol (see RFC 6376).  I believe it is important that it
> be in Debian and well maintained, but I am no longer using it, so my ability
> to test things and my motivation are not what they were.
> 
> The opendkim upstream effort is not dead, but a bit intermittent and slow.
> There is a single upstream developer who is quite busy and so loses focus on
> this project and then periodically jumps back in.
> 
> The project recently moved from Source Forge to GitHub and there is a new
> Beta that needs packaging.
> 
> Some understanding of DKIM is important to maintaining this package, but I
> do not think you need to be a protocol expert.  I am willing to provide
> advice and some assistance to a new maintainer (because I think opendkim is
> important to be in Debian and well maintained), so you won't be entirely on
> your own.

Scott K

Bug#908160: Delayed NMU, diff

[Hilko Bengen]

Dear maintainer,

I have just NMU'd open-iscsi/2.0.874-7.1, delayed by 5 days. Relevant
diffs are attached to this mail. Feel free to reschedule or cancel my
upload as you see fit.

Cheers,
-Hilko
>From 38db62d2cae88adb9f5c9d9622cb7ef9fdb9728a Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 12 Dec 2018 01:01:21 +0100
Subject: [PATCH 1/2] Update patch for missing macro (Closes: #908160)

---
 ...lude-sys-sysmacros.h-to-properly-define-minor.patch | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/debian/patches/include-sys-sysmacros.h-to-properly-define-minor.patch b/debian/patches/include-sys-sysmacros.h-to-properly-define-minor.patch
index f6322c7..857acd2 100644
--- a/debian/patches/include-sys-sysmacros.h-to-properly-define-minor.patch
+++ b/debian/patches/include-sys-sysmacros.h-to-properly-define-minor.patch
@@ -1,8 +1,10 @@
 Description: Include  to properly define minor()
 Origin: upstream, https://github.com/open-iscsi/open-iscsi/commit/6d68ef5871c94c6ebbbe6e6b1fe0bc2dce711052
 
 a/iscsiuio/src/unix/libs/bnx2x.c
-+++ b/iscsiuio/src/unix/libs/bnx2x.c
+Index: open-iscsi/iscsiuio/src/unix/libs/bnx2x.c
+===
+--- open-iscsi.orig/iscsiuio/src/unix/libs/bnx2x.c
 open-iscsi/iscsiuio/src/unix/libs/bnx2x.c
 @@ -50,6 +50,7 @@
  #include 
  #include 
@@ -11,3 +13,15 @@ Origin: upstream, https://github.com/open-iscsi/open-iscsi/commit/6d68ef5871c94c
  
  #include "config.h"
  
+Index: open-iscsi/iscsiuio/src/unix/libs/bnx2.c
+===
+--- open-iscsi.orig/iscsiuio/src/unix/libs/bnx2.c
 open-iscsi/iscsiuio/src/unix/libs/bnx2.c
+@@ -46,6 +46,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "config.h"
+ 
-- 
2.11.0

>From 73195ad1bfc267f112045f1d722783dc992400c7 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 12 Dec 2018 01:06:25 +0100
Subject: [PATCH 2/2] Debian release 2.0.874-7.1

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 2ceddc1..1c4b15d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+open-iscsi (2.0.874-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * [38db62d] Update patch for missing macro (Closes: #908160)
+
+ -- Hilko Bengen   Wed, 12 Dec 2018 01:05:19 +0100
+
 open-iscsi (2.0.874-7) unstable; urgency=medium
 
   * [eeda27c] Enable back pristine-tar as we have now committed it
-- 
2.11.0

Bug#916244: freeipa: Still depends on nodejs on all architectures

[John Paul Adrian Glaubitz]

Source: freeipa
Version: 4.7.1-3
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

The change to disable freeipa-server on architectures where nodejs isn't
available to make freeipa buildable on these targets didn't work [1].

The affected architectures still show as BD-Uninstallable [2] meaning the build
dependencies cannot be installed and it's obviously because of nodejs:

freeipa build-depends on:
- node-uglify:sparc64
node-uglify depends on missing:
- nodejs:sparc64

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/freeipa-team/freeipa/commit/5a1fb50a0a813749f2af73061a137a85107e9a7f
> [2] https://buildd.debian.org/status/package.php?p=freeipa&suite=unstable

--
 .''`.  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#916160: lsof FTBFS with glibc 2.28

[Andres Salomon]

Hi,

Just FYI, this build failure is already fixed in the latest version of 
lsof (4.91).


I've attached a backport of the upstream fix.  I (or someone else) could
NMU 4.89, but given that we're still a month away from the transition
freeze I'd much rather see lsof updated to the new version.  Norbert, 
are

you looking for a co-maintainer or someone to take this package?

Thanks,
Andres




--- lsof-4.89+dfsg/tests/LsofTest.h	2008-07-05 09:21:17.0 -0700
+++ lsof_4.91_src/tests/LsofTest.h	2018-02-14 06:21:50.0 -0800
@@ -31,7 +31,7 @@
 
 
 /*
- * $Id: LsofTest.h,v 1.12 2008/07/05 16:21:07 abe Exp $
+ * $Id: LsofTest.h,v 1.13 2018/02/14 14:21:44 abe Exp $
  */
 
 
@@ -77,6 +77,12 @@
 #include 
 
 #include 
+
+#if	defined(LT_DIAL_linux) && LT_VERS>=414014
+#undef	major
+#include 
+#endif	/* defined(LT_DIAL_linux) && LT_VERS>=414014 */
+
 #include 
 #include 
 

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Sam Hartman]

Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me
for Debian weekend tasks.

Bug#914879: Сlosing a tab causes the window to close

[Bernhard Übelacker]

Dear Maintainer,
tried just to reproduce and found that this issue should be
solved upstream with commit [1].
Upstream has also an entry in their bug tracker [2].

This commit is not yet included in an upstream released version.

[1] 
https://git.xfce.org/apps/xfce4-terminal/commit/terminal/terminal-window.c?id=49de8821b08c490297a518f9a4472f85de5f3c25
[2] https://bugzilla.xfce.org/show_bug.cgi?id=14645

Kind regards,
Bernhard

Bug#916232: check breaks riemann-c-client autopkgtest

[Gergely Nagy]

On Tue, Dec 11, 2018 at 7:42 PM Paul Gevers  wrote:
> autopkgtest [04:39:51]: test symver: [---
> In file included from tests/check_symver.c:9:
> tests/tests.h:10: warning: "ck_assert_float_eq" redefined
>  #define ck_assert_float_eq(X, Y) \
>
> In file included from tests/check_symver.c:3:
> /usr/include/check.h:784: note: this is the location of the previous
> definition
>  #define ck_assert_float_eq(X, Y) _ck_assert_floating(X, ==, Y, float, "")
>

This appears to be an issue in riemann-c-client. I'll fix it, test it,
and upload a new version tomorrow. Thanks for reporting the issue!

-- 
|8]

Bug#915059: RM: fuji -- RoQA; low popcon, RC buggy

[Dr. Tobias Quathamer]

control: reassign -1 ftp.debian.org
control: retitle -1 RM: fuji -- RoQA; low popcon, RC buggy
control: severity -1 normal
control: tags -1 - buster sid

Dear FTP team,

please remove the package fuji from unstable. It has been RC buggy for
over a year (#876827) without a maintainer response. I've tried to
contact the maintainer to ask about removal of this package (see this
bug), also without a response. The package has a low popcon value of 3.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#914887: tt-rss: Permission denied error when creating a database user in postgresql

[Sunil Mohan Adapa]

reassign 914887 dbconfig-common 2.0.10
retitle 914887 Permission denied error when configuring postgresql
tags 914887 + patch
thanks

The problem with configuring tt-rss with postgresql turns out to be in
dbconfig-common due to usage of su. Similar bugs were fixed in
quassel-core[1] and monkeysphere[2] packages.

When using su on systems with restricted login (such by restricting in
/etc/security/access.conf), a permission denied error is thrown when
performing database operations using psql. 'runuser' command (part of
util-linux like su) is better suited to simply run a command as a user
without the need for a login shell. Further, su(1) recommends using
runuser when used by privileged users.

Attached patch uses runuser in the pgsql methods instead of su. The
shell is not required anymore. However, due to the way single quoted
strings are passed around in variables such as 'extra', more changes
would be required. The shell is kept to make the patch minimally impacting.

As the bug impacts all FreedomBox machines trying to install tt-rss,
please consider making a release with the fix as soon as you can.

Links:

1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906794
2) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911907

Thank you,

-- 
Sunil
From 254be21e9c323e29f178af26fbcb062832264144 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Tue, 11 Dec 2018 14:17:06 -0800
Subject: [PATCH] pgsql: Fix issue with su on systems with restricted logins

When using su on systems with restricted login (such by restricting in
/etc/security/access.conf), a permission denied error is thrown when performing
database operations using psql. 'runuser' command (part of util-linux like su)
is better suited to simply run a command as a user without the need for a login
shell. Further, su(1) recommends using runuser when used by privileged users.

This patch uses runuser in the pgsql methods instead of su. The shell is not
required anymore. However, due to the way single quoted strings are passed
around in variables such as 'extra', more changes would be required. The shell
is kept to make the patch minimally impacting.

Closes: #914887
---
 internal/pgsql | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/internal/pgsql b/internal/pgsql
index 3aa7778..d4b2d4a 100644
--- a/internal/pgsql
+++ b/internal/pgsql
@@ -100,8 +100,8 @@ _dbc_psql(){
 _dbc_psql_cmd_setup
 if [ "${dbc_ssl:-}" ]; then PGSSLMODE="require"; fi
 extra=$(_dbc_psql_cmd_args)
-_dbc_debug "su -s /bin/sh $localuser -c \"env HOME='${_dbc_pgsql_tmpdir}' PGPASSFILE='${_dbc_pgsql_tmpdir}/.pgpass' PGSSLMODE='$PGSSLMODE' psql --set \\\"ON_ERROR_STOP=1\\\" -q $extra ${*:-}\" 2>&1"
-dbc_error=$(su -s /bin/sh $localuser -c "env HOME='${_dbc_pgsql_tmpdir}' PGPASSFILE='${_dbc_pgsql_tmpdir}/.pgpass' PGSSLMODE='$PGSSLMODE' psql --set \"ON_ERROR_STOP=1\" -q $extra ${*:-}" 2>&1) || retval=$?
+_dbc_debug "runuser --user $localuser -- /bin/sh -c \"env HOME='${_dbc_pgsql_tmpdir}' PGPASSFILE='${_dbc_pgsql_tmpdir}/.pgpass' PGSSLMODE='$PGSSLMODE' psql --set \\\"ON_ERROR_STOP=1\\\" -q $extra ${*:-}\" 2>&1"
+dbc_error=$(runuser --user $localuser -- /bin/sh -c "env HOME='${_dbc_pgsql_tmpdir}' PGPASSFILE='${_dbc_pgsql_tmpdir}/.pgpass' PGSSLMODE='$PGSSLMODE' psql --set \"ON_ERROR_STOP=1\" -q $extra ${*:-}" 2>&1) || retval=$?
 _dbc_psql_cmd_cleanup
 return $retval
 }
@@ -133,8 +133,8 @@ _dbc_dropdb(){
 _dbc_psql_cmd_setup
 if [ "${dbc_ssl:-}" ]; then PGSSLMODE="require"; fi
 extra=$(_dbc_psql_cmd_args)
-_dbc_debug "su -s /bin/sh $localuser -c \"env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropdb $extra $*\" 2>&1"
-dbc_error=$(su -s /bin/sh $localuser -c "env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropdb $extra $*" 2>&1) || retval=$?
+_dbc_debug "runuser --user $localuser -- /bin/sh -c \"env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropdb $extra $*\" 2>&1"
+dbc_error=$(runuser --user $localuser -- /bin/sh -c "env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropdb $extra $*" 2>&1) || retval=$?
 _dbc_psql_cmd_cleanup
 return $retval
 }
@@ -159,8 +159,8 @@ _dbc_dropuser(){
 _dbc_psql_cmd_setup
 if [ "${dbc_ssl:-}" ]; then PGSSLMODE="require"; fi
 extra=$(_dbc_psql_cmd_args)
-_dbc_debug "su -s /bin/sh $localuser -c \"env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropuser $extra $*\" 2>&1"
-dbc_error=$(su -s /bin/sh $localuser -c "env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropuser $extra $*" 2>&1) || retval=$?
+_dbc_debug "runuser --user $localuser -- /bin/sh -c \"env HOME='$_dbc_pgsql_tmpdir' PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' dropuser $extr

Bug#915787:

[Pranith Kumar]

Thanks, updating the gems fixed this issue.

-- 
Pranith

Bug#916243: gitlab installation failure

[Pranith Kumar]

Package: gitlab
Version: 11.3.11+dfsg-1
Severity: important

Dear Maintainer,

Trying to install gitlab throws the following error, please fix.

Setting up gitlab (11.3.11+dfsg-1) ...
`/var/www` is not writable.
Bundler will use `/tmp/bundler/home/pranith' as your home directory temporarily.
Creating runtime directories for gitlab...
Updating file permissions...
error: could not lock config file /var/www/.gitconfig: Permission denied
dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned error 
exit status 255
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

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

Versions of packages gitlab depends on:
ii  asciidoctor   1.5.8-1
ii  bc1.07.1-2+b1
ii  bundler   1.16.1-3
ii  bzip2 1.0.6-9
ii  dbconfig-pgsql2.0.10
ii  debconf [debconf-2.0] 1.5.69
ii  gitlab-common 11.3.11+dfsg-1
ii  gitlab-shell  8.3.3+dfsg-2
ii  gitlab-workhorse  7.4.0+debian-2
ii  lsb-base  10.2018112800
ii  nginx 1.14.1-1
ii  nginx-extras [nginx]  1.14.1-1
ii  nodejs8.11.2~dfsg-1
ii  npm   5.8.0+ds6-2
ii  openssh-client1:7.9p1-4
ii  postgresql-client 11+197
ii  postgresql-client-11 [postgresql-client]  11.1-1+b2
ii  postgresql-contrib11+197
ii  rake  12.3.1-3
ii  redis-server  5:5.0.2-1
ii  ruby  1:2.5.1
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-acts-as-taggable-on  5.0.0-2
ii  ruby-addressable  2.5.2-1
ii  ruby-akismet  2.0.0-1
ii  ruby-arel 6.0.4-1
ii  ruby-asana0.6.0-1
ii  ruby-asciidoctor-plantuml 0.0.8-1
ii  ruby-asset-sync   2.4.0-1
ii  ruby-attr-encrypted   3.1.0-1
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-batch-loader 1.2.1-1
ii  ruby-bcrypt-pbkdf 1.0.0-2
ii  ruby-bootstrap-form   2.7.0-1
ii  ruby-browser  2.5.3-1
ii  ruby-carrierwave  1.2.3-1
ii  ruby-charlock-holmes  0.7.6-1
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-commonmarker 0.17.9-1
ii  ruby-connection-pool  2.2.2-1
ii  ruby-creole   0.5.0-2
ii  ruby-default-value-for3.1.0-1
ii  ruby-device-detector  1.0.1-2
ii  ruby-devise   4.4.3-1
ii  ruby-devise-two-factor3.0.3-1
ii  ruby-diffy3.2.1-1
ii  ruby-doorkeeper   4.4.2-1
ii  ruby-doorkeeper-openid-connect1.5.2-1
ii  ruby-dropzonejs-rails 0.8.2-1
ii  ruby-ed25519  1.2.4-1
ii  ruby-email-reply-trimmer  0.1.6-1
ii  ruby-escape-utils 1.2.1-1+b1
ii  ruby-excon0.60.0-1
ii  ruby-faraday  0.13.1-2
ii  ruby-fast-blank   1.0.0-1+b1
ii  ruby-flipper  0.13.0-3
pn  ruby-flipper-active-record
pn  ruby-flipper-active-support-cache-store   
ii  ruby-fog-aliyun   0.2.0-1
ii  ruby-fog-aws  2.0.1-1
ii  ruby-fog-core 1.45.0-2
ii  ruby-fog-google   1.8.1-2
ii  ruby-fog-local0.3.0-1
ii  ruby-fog-openstack0.1.6-4
ii  ruby-fog-rackspace0.1.1-4
ii  ruby-fogbugz  0.2.1-3
ii  ruby-font-awesome-rails

Bug#916224: mediathekview: seems to depend on vlc

[Markus Koschany]

Control: forwarded -1 https://github.com/mediathekview/MediathekView/issues/400
Control: retitle: mediathekview: first start without VLC should not require 
second confirmation

Am 11.12.18 um 21:06 schrieb Dominik George:
> Control: rettle -1 mediathekview: first start without vlc is inobvious
> Control: reopen -1
> Control: severity -1 minor
> 
> Hi,
> 
>> No, not really. You can choose to adjust the settings when you first run
>> mediathekview and even if you proceed with the standard settings the
>> program will start even without vlc being installed. The wizard only
>> sets some basic settings but you can override them, either immediately
>> on first start or later in the settings menu.
> 
> I do know that - however, you don't get to this point if vlc is not
> installed on first start - at least not in an obious way. mediathekview
> insists on getting a path to vlc provided several times before starting.
> 
> If you leave the VLC field empty, it will bring up a separate fialog
> asking you to enter the path to vlc again. If you leave it empty, the
> same dialog comes up again.
> 
> At this point, I thought mediathekview would just not start without vlc
> - actually, if you click OK again without entering anything,
> mediathekview starts up fine.
> 
> I changed the bug metadata accordingly.
> 
> -nik

Ok, now I understand the real issue. The second dialog requires a second 
confirmation if
you leave the field to set the VLC path empty. That's most likely a bug. I have 
forwarded
this upstream to

https://github.com/mediathekview/MediathekView/issues/400

Markus




signature.asc
Description: OpenPGP digital signature

Bug#916220: saidar: segfault after couple of minutes

[Bernhard Übelacker]

Hello Mindaugas Celiesius,
I just tried to reproduce the crash.
Unfortunately it did not crash in my test.

Therefore I assume the information you provided is not
sufficient for the Maintainer to correct the program.

Maybe you could install a core dump collector like systemd-coredump.
When another crash happens you can enumerate the recorded crashes by:
  coredumpctl list

And possibly provide the information given by:
  coredumpctl gdb

This output would be even better if saidar-dbgsym from the
debug symbol repositories described in [1].

Kind regards,
Bernhard

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

Bug#915334: Upstream icon 3.5.1 seems to have this fixed

[Santiago Vila]

Étienne Mollier  wrote:

> On Mon, 10 Dec 2018 19:02:28 +0100 =?UTF-8?Q?=c3=89tienne_Mollier?= 
>  wrote:
> > Please disregard this patch, it seems the proper change has been
> > brought upstream, in icon version 3.5.1, to take in account the
> > necessary change for GlibC 2.28:
> > 
> > http://www2.cs.arizona.edu/icon/current/
> 
> I'm wrong, it will be part of the next version probably, but not
> icon 3.5.1.  The patch may help finally.

Thanks a lot for testing the patch.

I've just made a QA upload to fix this.

Bug#618332: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

On 2018-12-11 13:48:19 +0100, Oleg Broytman wrote:
> I run screen wrapped with tput calls:
> 
> tput smcup; screen -S test; tput rmcup

This will hide error messages. For instance:

$ tput smcup; screen -r does_not_exist; tput rmcup

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#912801: irony-mode: Please switch to llvm-toolchain-7

[Nicholas D Steeves]

control: tag -1 -help
control: tag -1 pending

Libclang-7 ftbfs is fixed in the new upstream release.  I did a quick
build just now to confirm, and all that remains is the usual
maintenance/updates and QA on the package before uploading.

Bug#916242: RM: dotlrn -- RoQA; Depends on obsolete software, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove dotlrn. It's unmaintained (last upload in 2014), depends
on aolserver, which is being removed and is already gone from testing/sid
for eight months due to the removal of aolserver-xotcl (without any followup)

Cheers,
Moritz

Bug#916241: RM: openacs -- RoQA; depends on obsolete software, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove openacs. It hasn't seen an upload since 2016 and is broken
in sid/testing for eight months due to the removed aolserver-xoctl. The
rest of the aolserver packages is also in the process of being removed.

Cheers,
Moritz

Bug#910577: gdb-multiarch: libbabeltrace1 dependency not tight enough

[Michael Jeanson]

On 2018-12-11 2:54 p.m., Adrian Bunk wrote:
> Most important is to fix the root cause:
> 
> $ cat /var/lib/dpkg/info/libbabeltrace1\:amd64.shlibs 
> libbabeltrace-ctf-metadata 1 libbabeltrace1
> libbabeltrace-ctf-text 1 libbabeltrace1
> libbabeltrace-ctf 1 libbabeltrace1
> ...
> $ 
> 
> Reverse dependencies could then be fixed for buster by binNMU.

Ok, so if I understand correctly.

Either, "libbabeltrace-ctf1" should be added to the dependencies of the
3 ctf shared objects in the shlibs file. That way packages that link
with any of theses libs will have an explicit dependency on
"libbabeltrace-ctf1", which will work with both old and new babeltrace
packages.

Or the dependency on "libbabeltrace1" should be versioned to explicitly
pull a package that includes the ctf sub-library.

Do you have an opinion on which of these solutions is preferable.

Thanks,

Michael

Bug#888392: [debian-mysql] Bug#888392: Bug#888392: Bug#888392: mariadb-connector-c: FTBFS on non-Linux: version script unused

[Sergei Golubchik]

Hi, Otto!

On Dec 11, Otto Kekäläinen wrote:
> Hello Aaron!
> 
> If the solution is evident to you, can you perhaps make a pull request
> on Salsa (https://wiki.debian.org/Teams/MySQL/patches) or even
> upstream?

IF(Linux) was added six years ago in v2.2.1, before even version script
was used. It was only around "-Wl,--no-undefined --Wl,--as-needed".

Version script was added few months later.

I am sure nobody cared about hurd at that early stage :)

But now it looks like a good time to fix it and correct that IF().

Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org

Bug#916240: libpodofo: CVE-2018-14320

[Salvatore Bonaccorso]

Source: libpodofo
Version: 0.9.6+dfsg-3
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for libpodofo.

CVE-2018-14320[0]:
| This vulnerability allows remote attackers to disclose sensitive
| information on vulnerable installations of PoDoFo. User interaction is
| required to exploit this vulnerability in that the target must visit a
| malicious page or open a malicious file. The specific flaw exists
| within PdfEncoding::ParseToUnicode. The issue results from the lack of
| proper validation of user-supplied data, which can result in a memory
| corruption condition. An attacker can leverage this in conjunction
| with other vulnerabilities to execute arbitrary code in the context of
| the current process. Was ZDI-CAN-5673.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14320
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14320
[1] https://www.zerodayinitiative.com/advisories/ZDI-18-1046/
[2] https://sourceforge.net/p/podofo/code/1953

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#916239: libsane: 60-libsane.rules refers to non-existing file /usr/lib/udev/hwdb.d/20-sane.hwdb

[Christian Weiske]

Package: libsane
Version: 1.0.27-3.1
Severity: minor

Dear Maintainer,

The file /lib/udev/rules.d/60-libsane.rules refers to the non-existing file

  /usr/lib/udev/hwdb.d/20-sane.hwdb

The file is actually located at:

  /lib/udev/hwdb.d/20-sane.hwdb

Please fix the location in the rules file.


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

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

Versions of packages libsane depends on:
ii  acl2.2.52-3+b1
ii  adduser3.118
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-2
ii  libgphoto2-6   2.5.21-1
ii  libgphoto2-port12  2.5.21-1
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libsane-common 1.0.27-3.1
ii  libsnmp30  5.7.3+dfsg-4+b1
ii  libssl1.1  1.1.1a-1
ii  libtiff5   4.0.10-3
ii  libusb-1.0-0   2:1.0.22-2
ii  udev   239-15

Versions of packages libsane recommends:
ii  sane-utils  1.0.27-3.1

Versions of packages libsane suggests:
ii  avahi-daemon  0.7-4+b1
pn  hplip 

-- no debconf information

Bug#915326: ksh FTBFS with glibc 2.28

[Juhani Numminen]

Control: tags -1 patch

On Sun, 02 Dec 2018 22:01:31 +0200 Adrian Bunk  wrote:
> Source: ksh
> Version: 93u+20120801-3.3
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ksh.html
> 
> ...
> /build/1st/ksh-93u+20120801/src/lib/libast/string/fmtdev.c: In function 
> 'fmtdev':
> /build/1st/ksh-93u+20120801/src/lib/libast/string/fmtdev.c:44:16: error: 
> expected expression before ';' token
>   ma = major(mm);
> ^
> /build/1st/ksh-93u+20120801/src/lib/libast/string/fmtdev.c:45:16: error: 
> expected expression before ';' token
>   mi = minor(mm);
> ^
> mamake [lib/libast]: *** exit code 1 making fmtdev.o

Hi,

I've attached a patch that gets rid of the FTBFS.
I did not test the resulting built package.

This fix is from upstream,
https://github.com/att/ast/commit/0d9d80e91c3b1bdb7ab037a25dbe8e01f81b18a6

--
Juhani
Description: Include  for major/minor on glibc
Origin: https://github.com/att/ast/commit/0d9d80e91c3b1bdb7ab037a25dbe8e01f81b18a6
Bug-Debian: https://bugs.debian.org/915326
Last-Update: 2018-12-11

--- a/src/lib/libast/string/fmtdev.c
+++ b/src/lib/libast/string/fmtdev.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char*
 fmtdev(struct stat* st)

Bug#916224: mediathekview: seems to depend on vlc

[Dominik George]

Control: rettle -1 mediathekview: first start without vlc is inobvious
Control: reopen -1
Control: severity -1 minor

Hi,

> No, not really. You can choose to adjust the settings when you first run
> mediathekview and even if you proceed with the standard settings the
> program will start even without vlc being installed. The wizard only
> sets some basic settings but you can override them, either immediately
> on first start or later in the settings menu.

I do know that - however, you don't get to this point if vlc is not
installed on first start - at least not in an obious way. mediathekview
insists on getting a path to vlc provided several times before starting.

If you leave the VLC field empty, it will bring up a separate fialog
asking you to enter the path to vlc again. If you leave it empty, the
same dialog comes up again.

At this point, I thought mediathekview would just not start without vlc
- actually, if you click OK again without entering anything,
mediathekview starts up fine.

I changed the bug metadata accordingly.

-nik


signature.asc
Description: PGP signature

Bug#901080: libtest-differences-perl: t/column-headers.t fails with verbose tests

[Niko Tyni]

reassign 901080 libtest-simple-perl 1.302141-1
forwarded 901080 https://github.com/Test-More/test-more/issues/810
tag 901080 = patch fixed-upstream
affects 901080 libtest-differences-perl
clone 901080 -1
reassign -1 perl 5.28.0-1
block -1 with 901080
thanks

On Sat, Jul 21, 2018 at 03:30:16PM +0300, Niko Tyni wrote:
> 
> On Fri, Jul 20, 2018 at 11:54:04PM +, Debian Bug Tracking System wrote:
> 
> >[ gregor herrmann ]
> >* debian/rules: turn off verbosity for tests as a workaround for test
> >  failures with newer Test-Simple. (Closes: #901080)
> 
> Thanks for working around this! I'm reopening this as it's still a real
> bug even though it's not hit by our build system anymore. Hope that's
> OK with you.

Test-Simple upstream considers it a bug on their side and has fixed it
with 
https://github.com/Test-More/test-more/commit/91e6fa0fa83976eb0b95e4329563850f08e678d0

So reassigning.

As Test-Simple is also in Perl core, I'm cloning another bug there.
The issue needs to be fixed in the separate package first.
-- 
Niko Tyni   nt...@debian.org

Bug#916207: lintian: debian-watch-does-not-check-gpg-signature certainty considered annoying

[Scott Kitterman]

On Tuesday, December 11, 2018 10:34:16 AM Felix Lechner wrote:
> Hi Scott,
> 
> Many people find the tag cumbersome, and some people think it should
> go away. At the same time, upstream sources are more trustworthy when
> verified; and that is in the project's overall interest. Could your
> concern be resolved by better naming?
> 
> I process the tag name (it has already been renamed once [1]) as
> "debian-watch-does-not-check-A-gpg-signature." Without a signature
> that is an objective fact.
> 
> On Tue, Dec 11, 2018 at 5:18 AM Scott Kitterman  
wrote:
> > As designed, debian-watch-does-not-check-gpg-signature does not check if
> > upstream provides a GPG signature to make checking it possible.
> 
> When I process the name as
> "debian-watch-does-not-check-THE-gpg-signature"---which is maybe the
> way you are reading it---it means the same as
> 'debian-watch-could-verify-download' but the tag does not behave like
> it.
> 
> My suggestion would be to rename the tag to
> 'built-from-unverified-sources' or similar. What do you think?
> 
> > when if there's no upstream signature, it's not at all a problem
> > the maintainer can fix.  "Certainty: possible" seems much more reasonable
> > to me.
> 
> The tag would continue to be of Certainty: certain.

That assumes there's only one way to verify sources.  I think it's too 
generic.

I realize it's virtually impossible to please everyone on things like this.

I think lintian should point out actionable issues.  If upstream doesn't sign 
their releases, there's no action to take here.  I think lintian should either 
grow the ability to see if there's something upstream that's signed based on 
the existing watch file and only flag this issue if there is or change the 
certainty.

I know which of those is easier.

I have more than once seen potential sponsors insist packages be 'lintian 
clean' (including sometimes pedantic) before they would sponsor things.  These 
kinds of unactionable tags cause friction for new contributors.  They are not 
harm free.

Scott K

Bug#910577: gdb-multiarch: libbabeltrace1 dependency not tight enough

[Adrian Bunk]

On Tue, Dec 11, 2018 at 02:47:01PM -0500, Michael Jeanson wrote:
> On 2018-11-26 3:51 p.m., Adrian Bunk wrote:
> > Control: reassign -1 libbabeltrace1 1.5.3-2
> > Control: severity -1 serious
> > Control: affects -1 gdb-multiarch
> > 
> > On Mon, Oct 08, 2018 at 11:35:10AM +0200, Matthias Urlichs wrote:
> >> Package: gdb-multiarch
> >> Version: 8.1-4
> >> Severity: important
> >>
> >> gdb-multiarch requires libbabeltrace-ctf1.
> >>
> >>   --\ Versions of libbabeltrace-ctf1 (3)   
> >>  
> >> p1.5.1-1
> >> i1.5.6-1
> >> i A  libbabeltrace1 1.5.6-1
> >>
> >> Apparently the build process picks up the fact that libbabeltrace-1.5.6-1
> >> contains the -ctf sub-library, but then doesn't depend on >=1.5.6.
> >> Thus 1.5.1 ends up being installed, which doesn't contain the plugin.
> >> ...
> > 
> > Reassigning to libbabeltrace1 where this bug should be fixed.
> > 
> > cu
> > Adrian
> > 
> 
> Hi,
> 
> I'm quite unsure how to fix this properly. I understand the problem but
> every solution I come up with involves modifying already released
> packages. I'm open to any suggestion.

Most important is to fix the root cause:

$ cat /var/lib/dpkg/info/libbabeltrace1\:amd64.shlibs 
libbabeltrace-ctf-metadata 1 libbabeltrace1
libbabeltrace-ctf-text 1 libbabeltrace1
libbabeltrace-ctf 1 libbabeltrace1
...
$ 

Reverse dependencies could then be fixed for buster by binNMU.

> Michael

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#909497: CUDA 10 available now

[Andreas Beckmann]

On 2018-12-11 06:53, Graham Inggs wrote:
> On Thu, 6 Dec 2018 at 16:03, Andreas Beckmann  wrote:
>> My plans are 9.2 (or 10.x if someone has time to look into it, so,
>> probably not)
>> 410.xx driver is already in NEW
> 
> Ubuntu already have a 410.xx driver, so I'm keen for 9.2 to be
> uploaded to unstable.  I can spend some time on preparing 10.x in
> experimental.

Can you take a look at what needs to be done for the CUDA 9.2 transition
in sid?
https://release.debian.org/transitions/html/auto-nvidia-cuda-toolkit.html
Most dependencies are out of testing already (probably due to RC bugs
for requiring ancient compilers) ...

Which packages
* can be binNMUed (manually by me or another DD, not by the release team)
* need sourceful uploads
* should get sourceful uploads to change ... and ...
?

I think there is not much point opening a transition bug since this will
be completely at our hands ...


Andreas

Bug#916235: thunar: [sid] Missing dependency libexo-1-0, "open terminal here" do not work by default if thunar is installed on other desktop env.

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-12-11 at 19:51 +0100, Grzegorz Krukar wrote:
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate
> ***
> 
>* What led up to the situation?
> 
> 1. Install thunar with gnome 3.
> 2. Try to "Open Terminal Here"
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> 
> Error "Failed to launch preffered application for category
> "TerminalEmulator"
> Failed to execute child process [...] exo-helper-1 (no such file or
> directory)"

Hi,

thanks for the bug report. Can you run dpkg -l |grep exo and paste the result?
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwQFMYACgkQ3rYcyPpX
RFuxMQf+KOgHsqYI4qJTmDjokEwiwTcrRXw6rBexSTRG1QLa9aeaBVy3loyF5pwh
tIBIJB9OrjBHJzdO5fZwS48zZMQ/a+CyDDaTbnScO8RM622kGsc+U0q3vJeH/TPe
rtEtb9z7px7yN0xZap9XlrM5jrcESC5eyh4SJ0a6jlsC7hHkoOl3NrRCSlolwoJx
X9CGJXIDLT4kddsa5HF0VZKToTJQG9F3WBd0HmWSIv91+SQ4EwyRufD9e7a1UGBc
o2COgzbkSn6q5OpeE/v1kJp/kOwinrpjIRhpj1XOJizvj9c6ZvvLx0VBvXm+CC8g
0OfQaVR/GhCVwyNbNBS7rZr7Yk4Nlw==
=eZBG
-END PGP SIGNATURE-

Bug#910577: gdb-multiarch: libbabeltrace1 dependency not tight enough

[Michael Jeanson]

On 2018-11-26 3:51 p.m., Adrian Bunk wrote:
> Control: reassign -1 libbabeltrace1 1.5.3-2
> Control: severity -1 serious
> Control: affects -1 gdb-multiarch
> 
> On Mon, Oct 08, 2018 at 11:35:10AM +0200, Matthias Urlichs wrote:
>> Package: gdb-multiarch
>> Version: 8.1-4
>> Severity: important
>>
>> gdb-multiarch requires libbabeltrace-ctf1.
>>
>>   --\ Versions of libbabeltrace-ctf1 (3) 
>>
>> p1.5.1-1
>> i1.5.6-1
>> i A  libbabeltrace1 1.5.6-1
>>
>> Apparently the build process picks up the fact that libbabeltrace-1.5.6-1
>> contains the -ctf sub-library, but then doesn't depend on >=1.5.6.
>> Thus 1.5.1 ends up being installed, which doesn't contain the plugin.
>> ...
> 
> Reassigning to libbabeltrace1 where this bug should be fixed.
> 
> cu
> Adrian
> 

Hi,

I'm quite unsure how to fix this properly. I understand the problem but
every solution I come up with involves modifying already released
packages. I'm open to any suggestion.

Michael

Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

[Simon McVittie]

Control: tags -1 + moreinfo

On Wed, 12 Dec 2018 at 00:45:34 +0800, You-Sheng Yang wrote:
> Somehow dash failed to expand /usr/share/docutils/scripts/python3/*, so
> that exec variable is simply '/usr/share/docutils/scripts/python3/*',
> which is later expanded as extra dozens of update-alternatives'   
> arguments. To be more detailed, at the time executed, dash path   
> expansion still worked as it's able to expand /usr/share/* and
> /usr/share/docutils*, but it failed to expand /usr/share/docutils/* and
> any other pattern with a /usr/share/docutils/ prefix. Files has been
> installed correctly and accessible, but dash simply unable to expand
> such globs.

The obvious question is: why don't basic operations like glob() work
on the system in question?

Is there something unusual on the system where these expansions failed,
like a non-standard filesystem or kernel, or weird permissions
(directories not 0755 or files not 0755 or 0644) anywhere under
/usr/share/docutils?

You mentioned Docker containers. What is the host system and how are
these Docker containers configured? If /usr is an overlayfs or similar,
failing to evaluate a glob might be a bug in the overlay implementation?

(Since 32-bit ARM and MIPS are not exactly fast machines, I would
suggest building your kernels with dpkg-buildpackage -B and using an
x86_64 machine to build documentation, which would maybe sidestep this
by not needing docutils at all.)

> Replace that path glob with a `find ... -type f` fixes the problem.

Sorry, I don't think python3-docutils can be expected to swap a path
expansion for a subprocess that ought to be equivalent to work around
whatever is going on with these systems - and definitely not without
understanding what it is that's going wrong and why.

smcv

Bug#916237: texmaker FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: texmaker
Version: 5.0.2-2.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

texmaker fails to cross build from source, because texmaker.pro hard
codes the build architecture pkg-config and thus fails finding
synctex.pc. The attached patch fixes that and makes texmaker cross
buildable. Please consider applying it.

Helmut
--- texmaker-5.0.2.orig/texmaker.pro
+++ texmaker-5.0.2/texmaker.pro
@@ -1066,7 +1066,7 @@
 #not for openSUSE :
 metainfo.path = $${METAINFODIR}
 
-LIBS += $$system(pkg-config --libs synctex)
+LIBS += $$system($$pkgConfigExecutable() --libs synctex)
 
 DEFINES += DEBIAN_SPELLDIR
 

Bug#916236: golang-golang-x-net-dev: FTBFS on s390x - rawconn.go undefined: getsockopt

[Alexandre Viau]

After taking a look at the package, it looks like it could have to do
with 01-Fix_s390x_build.patch.

Do you think that you can take a look at this?

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#888392: [debian-mysql] Bug#888392: Bug#888392: Bug#888392: mariadb-connector-c: FTBFS on non-Linux: version script unused

[Otto Kekäläinen]

Hello Aaron!

If the solution is evident to you, can you perhaps make a pull request
on Salsa (https://wiki.debian.org/Teams/MySQL/patches) or even
upstream?

Also note these issues where upstream has tweaked how symbols are
published and versioned:
* https://jira.mariadb.org/browse/MDEV-13619
* https://jira.mariadb.org/browse/MDEV-13589

Bug#915515: [debian-mysql] Bug#915515: [libmariadb2] Aborts a program in whole, using this library with the option MYSQL_OPT_RECONNECT

[Otto Kekäläinen]

Hello!

Thanks for the report. Can you reproduce this with latest libmariadb3
package? The old libmariadb2 series is not maintained in Debian
anymore.

Bug#916234: depending software build failure (arm64, armel, mips)

[Anton Gladky]

Hello,

#915934 can be related. Please forward to GCC.

Anton
Am Di., 11. Dez. 2018 um 19:54 Uhr schrieb Filippo Rusconi :
>
> Package: libeigen3-dev
> Version: 3.3.5-2
> Severity: serious
>
>
> Greetings,
>
> when building libpwiz on the arm64, armel, mips architectures, the build fails
> with the following error:
>
> In file included from /usr/include/eigen3/Eigen/SparseCore:50,
>  from /usr/include/eigen3/Eigen/Sparse:26,
>  from /usr/include/eigen3/Eigen/Eigen:2,
>  from pwiz/analysis/demux/DemuxTypes.hpp:24,
>  from pwiz/analysis/demux/DemuxDebugWriter.hpp:23,
>  from pwiz/analysis/demux/DemuxDebugWriter.cpp:20:
> /usr/include/eigen3/Eigen/src/SparseCore/SparseBlock.h: In member function 
> 'Eigen::internal::sparse_matrix_block_impl BlockCols>::BlockType& 
> Eigen::internal::sparse_matrix_block_impl BlockCols>::operator=(const BlockType&)':
> /usr/include/eigen3/Eigen/src/SparseCore/SparseBlock.h:216:33: error: 
> expected primary-expression before '>' token
>return operator=(other);
>  ^
>
> Please, see
>
> https://buildd.debian.org/status/fetch.php?pkg=libpwiz&arch=arm64&ver=3.0.18342-1&stamp=1544522661&file=log
> https://buildd.debian.org/status/fetch.php?pkg=libpwiz&arch=armel&ver=3.0.18342-1&stamp=1544523773&file=log
> https://buildd.debian.org/status/fetch.php?pkg=libpwiz&arch=mips&ver=3.0.18342-1&stamp=1544524240&file=log
>
> I am not positively sure that this package is guilty, but I cannot see another
> bug reporting route at the moment.
>
> Sincerely,
> Filippo
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libeigen3-dev depends on:
> ii  pkg-config  0.29-4+b1
>
> libeigen3-dev recommends no packages.
>
> Versions of packages libeigen3-dev suggests:
> pn  libeigen3-doc   
> pn  libmpfrc++-dev  
>
> -- no debconf information
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
> ⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
> ⢿⡄⠘⠷⠚⠋⠀   Debian Developer
> ⠈⠳⣄  http://msxpertsuite.org
>   http://www.debian.org
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#916234: depending software build failure (arm64, armel, mips)

[Juhani Numminen]

Control: reassign 916234 gcc-8
Control: forcemerge 915934 916234
Control: affects 915934 src:libpwiz

Hello,

On Tue, 11 Dec 2018 19:49:59 +0100 Filippo Rusconi  wrote:

> Greetings, 
> 
> when building libpwiz on the arm64, armel, mips architectures, the build fails
> with the following error:
[...]

> 
> I am not positively sure that this package is guilty, but I cannot see another
> bug reporting route at the moment.

The error message is the same as with #915934, reassigning.

--
Juhani

Bug#916236: golang-golang-x-net-dev: FTBFS on s390x - rawconn.go undefined: getsockopt

[Alexandre Viau]

Package: golang-golang-x-net-dev
Version: 1:0.0+git20181201.351d144+dfsg-1

It looks like the golang-golang-x-net-dev build is broken on s390x.

Syncthing gets the following error during build:

```
src/golang.org/x/net/internal/socket/rawconn.go:49:14: undefined: getsockopt
src/golang.org/x/net/internal/socket/rawconn.go:60:11: undefined: setsockopt
src/golang.org/x/net/internal/socket/rawconn_msg.go:26:14: undefined:
recvmsg
src/golang.org/x/net/internal/socket/rawconn_msg.go:62:14: undefined:
sendmsg
```

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#916008: wmhdplop FTBFS with glibc 2.28

[Andreas Metzler]

On 2018-12-11 "Torrance, Douglas"  wrote:
> On 12/10/2018 08:54 PM, Doug Torrance wrote:
[...]
> > Indeed.  This (and a couple other commits) hadn't been included in an 
> > official release yet.  I just fixed this, and version 0.9.11 is now 
> > available [1].  I'll prepare a new Debian package soon.

> The new package is ready and pushed to git [1]. 

Great, thanks.

> Andreas, are you able to review and sponsor?

Might take a little bit of time - weekend.

cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#916125: hunspell: "hunspell -D" does not print loaded dictionary

[Rene Engelhard]

forwarded 916125 https://github.com/hunspell/hunspell/issues/608
thanks

On Mon, Dec 10, 2018 at 12:31:44PM +0100, Itaï BEN YAACOV wrote:
> Commit 27829f0 which pplies to version 1.7.0 makes "hunspell -D" without 
> files quit early.
> Too early to print the loaded dictionary, making "hunspell -D" not perform as 
> expexted [...]

See https://github.com/hunspell/hunspell/issues/608

> and breaking eacs flyspell.

$ apt-file search flyspell
dictionaries-common:
/usr/share/dictionaries-common/site-elisp/flyspell.el
emacs-common: /usr/share/emacs/25.2/lisp/textmodes/flyspell.elc
emacs-el: /usr/share/emacs/25.2/lisp/textmodes/flyspell.el.gz
emacspeak:
/usr/share/emacs/site-lisp/emacspeak/lisp/emacspeak-flyspell.el
jed-extra: /usr/share/jed/jed-extra/drop-in/flyspell.sl
xemacs21-basesupport:
/usr/share/xemacs21/xemacs-packages/lisp/text-modes/flyspell.elc
xemacs21-basesupport-el:
/usr/share/xemacs21/xemacs-packages/lisp/text-modes/flyspell.el.gz

Erm, which one of these is the real(tm) one?

> Reverting the commit, or moving the leave logic a little later, solves this.

Or fixing emacs, see
https://github.com/hunspell/hunspell/issues/608#issuecomment-444955561 ff.

Regards,

Rene

Bug#916235: thunar: [sid] Missing dependency libexo-1-0, "open terminal here" do not work by default if thunar is installed on other desktop env.

[Grzegorz Krukar]

Package: thunar
Version: 1.8.2-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

1. Install thunar with gnome 3.
2. Try to "Open Terminal Here"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Error "Failed to launch preffered application for category "TerminalEmulator"
Failed to execute child process [...] exo-helper-1 (no such file or directory)"

   * What outcome did you expect instead?

Open terminal without installing additinal dependency

*** 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.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.2-2
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.28-2
ii  libcairo2   1.16.0-1
ii  libexo-2-0  0.12.2-2
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.1-3
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-3
ii  libpango-1.0-0  1.42.4-4
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-3-0  1.8.2-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.2-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1
ii  gnome-shell [polkit-1-auth-agent] 3.30.2-1
ii  gvfs  1.38.1-1
ii  libcairo-gobject2 1.16.0-1
ii  libpangocairo-1.0-0   1.42.4-4
ii  libxfce4panel-2.0-4   4.12.2-1
ii  thunar-volman 0.9.0-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-3
ii  xdg-user-dirs 0.17-1

Versions of packages thunar suggests:
pn  thunar-archive-plugin 
pn  thunar-media-tags-plugin  

-- no debconf information

Bug#916234: depending software build failure (arm64, armel, mips)

[Filippo Rusconi]

Package: libeigen3-dev
Version: 3.3.5-2
Severity: serious


Greetings, 


when building libpwiz on the arm64, armel, mips architectures, the build fails
with the following error:

In file included from /usr/include/eigen3/Eigen/SparseCore:50,
from /usr/include/eigen3/Eigen/Sparse:26,
from /usr/include/eigen3/Eigen/Eigen:2,
from pwiz/analysis/demux/DemuxTypes.hpp:24,
from pwiz/analysis/demux/DemuxDebugWriter.hpp:23,
from pwiz/analysis/demux/DemuxDebugWriter.cpp:20:
/usr/include/eigen3/Eigen/src/SparseCore/SparseBlock.h: In member function 
'Eigen::internal::sparse_matrix_block_impl::BlockType& Eigen::internal::sparse_matrix_block_impl::operator=(const BlockType&)':
/usr/include/eigen3/Eigen/src/SparseCore/SparseBlock.h:216:33: error: expected 
primary-expression before '>' token
  return operator=(other);
^

Please, see 


https://buildd.debian.org/status/fetch.php?pkg=libpwiz&arch=arm64&ver=3.0.18342-1&stamp=1544522661&file=log
https://buildd.debian.org/status/fetch.php?pkg=libpwiz&arch=armel&ver=3.0.18342-1&stamp=1544523773&file=log
https://buildd.debian.org/status/fetch.php?pkg=libpwiz&arch=mips&ver=3.0.18342-1&stamp=1544524240&file=log

I am not positively sure that this package is guilty, but I cannot see another
bug reporting route at the moment.

Sincerely,
Filippo

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

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

Versions of packages libeigen3-dev depends on:
ii  pkg-config  0.29-4+b1

libeigen3-dev recommends no packages.

Versions of packages libeigen3-dev suggests:
pn  libeigen3-doc   
pn  libmpfrc++-dev  

-- no debconf information

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#916233: Difficulty with Debian Buster netinst dvd on Mac Pro 1,1

[David George Henderson III]

Package: d-i.debian.org
Severity: important

I'm trying to install Debian testing on a Mac Pro 1,1 dedicated 
boot/swap/root partition set.

The 12/3/2018 debian-testing-amd64-i386-netinst.iso DVD boots using the 
refit boot manager.
     It hangs at the first splash screen when I select install for amd64.
     This is very similar to what I notice in 915...@bugs.debian.org

What works to install Debian Buster/testing on a Mac Pro 1,1 with Radeon 
570 video card:

1. Install Jessie/amd64 without X11 using the amd64-i386 netinst dvd
2. Perform a dist-upgrade to Buster, still without any X11.
     The dist-upgrade ran without an intermediate upgrade to Stretch.
     After doing this I have a functional system with no X11 window 
manager using firmware video.
     (This was tested with a shutdown and reboot)
3. After performing the dist-upgrade to buster:
     a. install xserver-xorg-video-nouveau
     b. install xfce following directions in https://wiki.debian.org/Xfce

What seems to be failing with the Buster amd64-i386 netinst:
     It looks like installer disk seems to be running the 
xserver-xorg-video-radeon driver.
     This behavior for xserver-xorg-video-radeon seems to have 
started with Stretch
     The Mac Pro 1,1 has a 32 bit ia32 EFI firmware.
     I have never gotten the radeon driver to work on this machine 
for either Stretch or Buster.
     What does work is xserver-xorg-video-nouveau

I have a change suggestion for the debian installer:
     Go back to using the text window installer.
     If you can't go back to using the text window installer,
     run installer under xserver-xorg-video-nouveau


Init: systemd (via /run/systemd/system)

*** /home/dgh/mp_config.txt
dgh@mpgpt:~$ lspci
00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller 
Hub (rev
30)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 
Port
2-3 (rev 30)
00:03.0 Non-VGA unclassified device: Intel Corporation 5000 Series 
Chipset PCI
Express x4 Port 3 (rev 30)
00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7
(rev 30)
00:05.0 Non-VGA unclassified device: Intel Corporation 5000 Series 
Chipset PCI
Express x4 Port 5 (rev 30)
00:06.0 Non-VGA unclassified device: Intel Corporation 5000 Series 
Chipset PCI
Express x4 Port 6 (rev 30)
00:07.0 Non-VGA unclassified device: Intel Corporation 5000 Series 
Chipset PCI
Express x4 Port 7 (rev 30)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine
(rev 30)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers 
(rev
30)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers 
(rev
30)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers 
(rev
30)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved 
Registers
(rev 30)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved 
Registers
(rev 30)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers 
(rev
30)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers 
(rev
30)
00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition 
Audio
Controller (rev 09)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI 
Express
Root Port 1 (rev 09)
00:1c.1 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI 
Express
Root Port 2 (rev 09)
00:1c.2 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI 
Express
Root Port 3 (rev 09)
00:1c.3 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI 
Express
Root Port 4 (rev 09)
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB
Controller #1 (rev 09)
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB
Controller #2 (rev 09)
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB
Controller #3 (rev 09)
00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB
Controller #4 (rev 09)
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI
USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC
Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev
09)
00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA AHCI 
Controller
(rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus 
Controller
(rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Upstream Port
(rev 01)
01:00.1 PIC: Intel Corporation 6311ESB/6321ESB I/OxAPIC Interrupt Controller
(rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X
Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream
Port E1 (rev 01)
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream

Bug#916232: check breaks riemann-c-client autopkgtest

[Paul Gevers]

Source: check, riemann-c-client
Control: found -1 check/0.12.0-0.1
Control: found -1 riemann-c-client/1.10.3-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of check the autopkgtest of riemann-c-client fails
in testing when that autopkgtest is run with the binary packages of
check from unstable. It passes when run with only packages from testing.
In tabular form:
   passfail
check  from testing0.12.0-0.1
riemann-c-client   from testing1.10.3-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
output it seems that the new check generates output on stderr, where it
didn't produce output that output before. I can't just if check should
output this to stderr, or if riemann-c-client should just update the
test to allow output to stderr (Restrictions: allow-stderr).

Currently this regression is contributing to the delay of the migration
of check to testing [1]. Due to the nature of this issue, I filed this
bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/riemann-c-client/1487985/log.gz

autopkgtest [04:39:51]: test symver: [---
In file included from tests/check_symver.c:9:
tests/tests.h:10: warning: "ck_assert_float_eq" redefined
 #define ck_assert_float_eq(X, Y) \

In file included from tests/check_symver.c:3:
/usr/include/check.h:784: note: this is the location of the previous
definition
 #define ck_assert_float_eq(X, Y) _ck_assert_floating(X, ==, Y, float, "")

Running suite(s): Riemann C client library symbol versioning tests
100%: Checks: 2, Failures: 0, Errors: 0
autopkgtest [04:39:51]: test symver: ---]
autopkgtest [04:39:52]: test symver:  - - - - - - - - - - results - - -
- - - - - - -
symver   FAIL stderr: In file included from
tests/check_symver.c:9:



signature.asc
Description: OpenPGP digital signature

Bug#915273: mumble: sound glitches when starting mumble

[Chris Knadle]

Axel Regnat:
> Not sure what you mean with "AppArmor audit daemon log" but I couldn't find
> anything from apparmor in kern.log or sys.log when starting mumble. I also
> updated to 1.3 like you suggested and the problem seems to be fixed. Thanks 
> for
> your help.
> 
> Axel

You're very welcome.  :)  I'm glad Mumble 1.3 fixes this.

Re: AppArmor audit daemon:
When using AppArmor it's beneficial to get reports of when certain actions are
blocked, such as using apparmor-notify, and I believe another way is to use
auditd to log these events.  As long as you have some way of knowing when
AppArmor blocks an action, that's all I was looking for, so that you could debug
if that was the reason for the issue.

And thanks for marking and closing the bug.  :)

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#916207: lintian: debian-watch-does-not-check-gpg-signature certainty considered annoying

[Felix Lechner]

Hi Scott,

Many people find the tag cumbersome, and some people think it should
go away. At the same time, upstream sources are more trustworthy when
verified; and that is in the project's overall interest. Could your
concern be resolved by better naming?

I process the tag name (it has already been renamed once [1]) as
"debian-watch-does-not-check-A-gpg-signature." Without a signature
that is an objective fact.

On Tue, Dec 11, 2018 at 5:18 AM Scott Kitterman  wrote:
> As designed, debian-watch-does-not-check-gpg-signature does not check if
> upstream provides a GPG signature to make checking it possible.

When I process the name as
"debian-watch-does-not-check-THE-gpg-signature"---which is maybe the
way you are reading it---it means the same as
'debian-watch-could-verify-download' but the tag does not behave like
it.

My suggestion would be to rename the tag to
'built-from-unverified-sources' or similar. What do you think?

> when if there's no upstream signature, it's not at all a problem
> the maintainer can fix.  "Certainty: possible" seems much more reasonable to
> me.

The tag would continue to be of Certainty: certain.

Kind regards,
Felix

[1] 
https://salsa.debian.org/lintian/lintian/commit/0cbebd4ba0b2a067383616e18981eeb9de5d7df2

Bug#916231: osspd FTBFS on mips: osspd.c:769:15: error: 'IOC_IN' undeclared

[Helmut Grohne]

Source: osspd
Version: 1.3.2-9
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

While trying to cross build osspd for mips, I ran into a failure that I
could reproduce natively on minkus.d.o, but not on amd64. I suspect this
is related to glibc/2.28. A build ends with:

| gcc -Wall -pthread -g -O2 -fdebug-prefix-map=/home/helmutg/osspd-1.3.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse 
-DSLAVE_DEFAULT_PATH=\"/usr/lib/osspd\" -o osspd osspd.c -lfuse -pthread -L. 
-lossp -pthread -Wl,-z,relro
| osspd.c:41:2: warning: #warning mmap support disabled for now [-Wcpp]
|  #warning mmap support disabled for now
|   ^~~
| In file included from /usr/include/mips-linux-gnu/sys/soundcard.h:1,
|  from osspd.c:29:
| osspd.c: In function 'mixer_do_ioctl':
| osspd.c:769:15: error: 'IOC_IN' undeclared (first use in this function); did 
you mean 'SIOC_IN'?
|   if (!(cmd & (SIOC_IN | SIOC_OUT)))
|^~~
| osspd.c:769:15: note: each undeclared identifier is reported only once for 
each function it appears in
| osspd.c:769:25: error: 'IOC_OUT' undeclared (first use in this function); did 
you mean 'SIOC_OUT'?
|   if (!(cmd & (SIOC_IN | SIOC_OUT)))
|  ^~~~
| osspd.c: In function 'notify_poller':
| osspd.c:1842:1: warning: no return statement in function returning non-void 
[-Wreturn-type]
|  }
|  ^
| osspd.c: In function 'ossp_daemonize':
| osspd.c:1923:3: warning: ignoring return value of 'chdir', declared with 
attribute warn_unused_result [-Wunused-result]
|chdir("/");
|^~
| At top level:
| osspd.c:1978:39: warning: 'adsp_ops' defined but not used 
[-Wunused-const-variable=]
|  static const struct cuse_lowlevel_ops adsp_ops = {
|^~~~
| make[2]: *** [Makefile:56: osspd] Error 1
| make[2]: Leaving directory '/home/helmutg/osspd-1.3.2'
| dh_auto_build: make V=1 -j1 SLAVESDIR=/usr/lib/osspd 
UDEVDIR=/lib/udev/rules.d returned exit code 2
| make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2
| make[1]: Leaving directory '/home/helmutg/osspd-1.3.2'
| make: *** [debian/rules:7: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#915273: mumble: sound glitches when starting mumble

[Axel Regnat]

Not sure what you mean with "AppArmor audit daemon log" but I couldn't 
find anything from apparmor in kern.log or sys.log when starting mumble. 
I also updated to 1.3 like you suggested and the problem seems to be 
fixed. Thanks for your help.


Axel

Bug#916230: Svlogd: log files named as `timestamp.u' even if there is no processor in place

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-19
Severity: normal

Hi Dmitry,

I have several log directories with more than 10 log files.
This is true when there are no config files and also when there is
a config file that sets `num' to 10.
The patch for #878476 (Fix spin lock on systems with poor clock) excluded
`.u' files from being deleted, and this fix highlighted that svlogd is
naming some or all log files as `timestamp.u' instead of `timestamp.s'.
I have no `processor' in place so this looks wrong to me.
Also, with a mix of `.t' and `.u' log files the number of old log
files is no longed guaranteed to be equal to `num'.

Some example below

# ls /var/log/socklog/main/
@40005bec9d4312f06574.s  @40005becbdb61a29ab84.s  
@40005bfb1d87038ba954.s  config
@40005beca56327c6e25c.s  @40005becc5d20d12bbac.s  
@40005c04f9792a66167c.u  current
@40005becad7d096ee8cc.s  @40005bf08a8011444bb4.s  
@40005c05672f19f2cca4.u  lock
@40005becb59a286cceec.s  @40005bf1e6aa28b2ffac.u  
@40005c0c14131dcfcc3c.u

# cat /var/log/socklog/main/config 
s99
n10

# ls /var/log/git-daemon/
@40005b998548043f1ad4.u  @40005bec24580f89227c.u  
@40005c0c14131d51beb4.u
@40005bd6c9511b69cca4.u  @40005bf1e6aa2881d9a4.u  current
@40005be9f5cb053c62ac.u  @40005c05672f1ad020cc.u  lock

#ls /var/log/openntpd/
@40005b998548032ffc94.u  @40005bf83e0606a08a74.s  
@40005c07cc2238359084.s
@40005bd6c9511c410a34.u  @40005bfd27a1004150b4.s  
@40005c0be372278ac3bc.s
@40005be9f5cb03eb2e74.u  @40005bffd5160718b814.s  
@40005c0c14131d8716f4.u
@40005bec24580dc9abb4.u  @40005c02d1022e67248c.s  
@40005c0fa55f0ec476d4.s
@40005bf03e4023305e94.s  @40005c032bcb2c921e3c.s  current
@40005bf1e6aa287041bc.u  @40005c04f9792a5447e4.u  lock
@40005bf3fbac120daa7c.s  @40005c05672f1990edf4.u

Am I missing something about the `processor' thing?


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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6 2.28-2
ii  runit-helper  2.7.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-19

runit suggests no packages.

-- Configuration Files:
/etc/runit/3 changed [not included]

-- no debconf information

Bug#916229: poxml FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: poxml
Version: 4:17.08.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

poxml fails to cross build from source, because it fails running tests
in the presence of DEB_BUILD_OPTIONS=nocheck. The attached patch adds
support for the nocheck option and thus fixes a cross build. Please
consider applying it.

Helmut
diff --minimal -Nru poxml-17.08.3/debian/changelog 
poxml-17.08.3/debian/changelog
--- poxml-17.08.3/debian/changelog  2017-11-19 12:54:00.0 +0100
+++ poxml-17.08.3/debian/changelog  2018-12-11 07:21:39.0 +0100
@@ -1,3 +1,10 @@
+poxml (4:17.08.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 11 Dec 2018 07:21:39 +0100
+
 poxml (4:17.08.3-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru poxml-17.08.3/debian/patches/nocheck.patch 
poxml-17.08.3/debian/patches/nocheck.patch
--- poxml-17.08.3/debian/patches/nocheck.patch  1970-01-01 01:00:00.0 
+0100
+++ poxml-17.08.3/debian/patches/nocheck.patch  2018-12-11 07:15:30.0 
+0100
@@ -0,0 +1,21 @@
+--- poxml-17.08.3.orig/CMakeLists.txt
 poxml-17.08.3/CMakeLists.txt
+@@ -2,6 +2,8 @@
+ 
+ cmake_minimum_required (VERSION 2.8.12 FATAL_ERROR)
+ 
++option(ENABLE_TESTS "enable running tests during build" ON)
++
+ find_package(ECM 1.7.0 REQUIRED CONFIG)
+ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${ECM_MODULE_PATH} 
${ECM_KDE_MODULE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules)
+ 
+@@ -82,7 +84,9 @@
+ 
+ 
+ 
++if(ENABLE_TESTS)
+ add_subdirectory(tests)
++endif()
+ 
+ 
+ feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)
diff --minimal -Nru poxml-17.08.3/debian/patches/series 
poxml-17.08.3/debian/patches/series
--- poxml-17.08.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ poxml-17.08.3/debian/patches/series 2018-12-11 07:14:24.0 +0100
@@ -0,0 +1 @@
+nocheck.patch
diff --minimal -Nru poxml-17.08.3/debian/rules poxml-17.08.3/debian/rules
--- poxml-17.08.3/debian/rules  2017-11-19 12:50:22.0 +0100
+++ poxml-17.08.3/debian/rules  2018-12-11 07:21:37.0 +0100
@@ -4,3 +4,8 @@
 
 include /usr/share/pkg-kde-tools/qt-kde-team/3/debian-qt-kde.mk
 include /usr/share/pkg-kde-tools/qt-kde-team/2/l10n-packages.mk
+
+ifneq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
+override_dh_auto_configure:
+   dh_auto_configure --buildsystem=kf5 -- -DENABLE_TESTS=OFF
+endif

Bug#916031: Runs unpaper multiple times unnecessarily

[Jeff]

Thanks for the log file.

If you look at it, you can see tha unpaper is only called four times -
or at least up until the point at which it is cut off - you seem to have
posted it before quitting gscan2pdf, and thus the bottom is missing.

I suspect that the extra processes you are seeing are due to the
conversions from pnm back to png, once after the initial scan, and once
after unpaper, i.e. in your case there are 3 processes per page -
pnm->png, unpaper, pnm->png, plus the final save at the end, if it happens.

I haven't tried to make gscan2pdf guess how many processes will be
started. If, for instance, unpaper splits the pages, and thus the number
of pages doubles, and perhaps you run OCR on the results, then the
number of processes will be higher still.

gscan2pdf can't always know when you hit the scan button, how many
processes will be created, as it can't always know how many pages are in
the ADF.

The total number of processes is not incremented until the new job is
queued for the thread, which now doesn't happen until its predecessors
have finished, in order to prevent race conditions.

I think, therefore, that the bug is not making a better job of
displaying the final number of processes to the user.



signature.asc
Description: OpenPGP digital signature

Bug#916095: lintian: False positive: license-problem-gfdl-invariants

[Chris Lamb]

Hi Dmitry,
 
> > >   any later version published by the Free Software Foundation; with no
> > >   Invariant Sections, no Front-Cover and Back-Cover texts.  [..]
> > 
> > … is that it is missing an explicit reference to having "no bad
> > sections". See #698667 for some of the background?
> 
> I am fine with override, but long description asked to report a bug in
> case of false-positive.

As I understand it, I don't believe this is a false-positive as it is
missing "no bad sections".


Regards,

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

Bug#916011: Blank dialog — Can't locate object method "vbox" via package "Gtk3::Dialog"

[Jeff]

Thanks for the report. The error message was enough for me to find and
fix the problem - vbox() calls left over from gtk+-2.

You'll see the fix in the next release.



signature.asc
Description: OpenPGP digital signature

Bug#909015: abiword: Crashes on startup with GLib-ERROR

[Bernhard Übelacker]

Control: reassign 909015 libcogl20 1.22.2-2
Control: affects 909015 abiword

Dear Maintainer,
this crash seems to be caused by a broken opengl configuration.
It could still be seen with buster when e.g. someone has the
nvidia-driver-libs-nonglvnd installed without the kernel module loaded.

Unfortunately there is no output at stdout that would point
the user to that direction. Instead the application just crashes.

With attached patch the cogl initialization would at least just fail and
clutter could write an error message to stdout.
  Unable to initialize Clutter: Unable to initialize the Clutter backend: no 
available drivers found.

Kind regards,
Bernhard
From 338a1c3c8a10c4e28cadf96e0ce76d933ede625d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Tue, 11 Dec 2018 18:25:59 +0100
Subject: [PATCH] Fail gracefully when no usable device is found.

Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909015
---
 cogl/cogl-context.c|  2 +-
 cogl/driver/gl/gles/cogl-driver-gles.c | 20 
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/cogl/cogl-context.c b/cogl/cogl-context.c
index a7eed29..9503561 100644
--- a/cogl/cogl-context.c
+++ b/cogl/cogl-context.c
@@ -679,7 +679,7 @@ _cogl_context_get_gl_extensions (CoglContext *context)
 #ifdef HAVE_COGL_GL
   if (context->driver == COGL_DRIVER_GL3)
 {
-  int num_extensions, i;
+  int num_extensions = 0, i;
 
   context->glGetIntegerv (GL_NUM_EXTENSIONS, &num_extensions);
 
diff --git a/cogl/driver/gl/gles/cogl-driver-gles.c b/cogl/driver/gl/gles/cogl-driver-gles.c
index e94449f..7ef375a 100644
--- a/cogl/driver/gl/gles/cogl-driver-gles.c
+++ b/cogl/driver/gl/gles/cogl-driver-gles.c
@@ -238,6 +238,23 @@ _cogl_get_gl_version (CoglContext *ctx,
  minor_out);
 }
 
+static CoglBool
+check_gl_version (CoglContext *ctx,
+  char **gl_extensions,
+  CoglError **error)
+{
+  if (!_cogl_context_get_gl_version (ctx))
+{
+  _cogl_set_error (error,
+   COGL_DRIVER_ERROR,
+   COGL_DRIVER_ERROR_UNKNOWN_VERSION,
+   "The GLES version could not be determined");
+  return FALSE;
+}
+
+  return TRUE;
+}
+
 static CoglBool
 _cogl_driver_update_features (CoglContext *context,
   CoglError **error)
@@ -259,6 +276,9 @@ _cogl_driver_update_features (CoglContext *context,
 
   gl_extensions = _cogl_context_get_gl_extensions (context);
 
+  if (!check_gl_version (context, gl_extensions, error))
+return FALSE;
+
   if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_WINSYS)))
 {
   char *all_extensions = g_strjoinv (" ", gl_extensions);
-- 
2.19.2

Bug#916228: firefox-esr: Some images with descriptions are not read by Orca

[Colomban Wendling]

Package: firefox-esr
Version: 52.9.0esr-1
Severity: normal
Tags: a11y upstream
User: b...@hypra.fr
Usertags: hypra
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1513270

Dear Maintainer,

Some images are not properly announced by the Orca screen reader because
they incorrectly expose the `invalid` state through AT-SPI, which leads
to them being filtered out.  See the upstream report for a sample to
reproduce the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1513270

Regards,


-- Package-specific info:

[some stripped as they are not relevant -- the issue is not limited to
 this system or Firefox version, and is confirmed on 60.3 and others as
 well]

-- Addons package information
ii  firefox-esr 52.9.0esr-1  amd64Mozilla Firefox web 
browser - Extended Support Release (ESR)
ii  firefox-esr-l10n-fr 52.9.0esr-1  all  French language package 
for Firefox ESR
ii  gnome-shell 3.30.1-2 amd64graphical shell for the 
GNOME desktop
ii  rhythmbox-plugins   3.4.2-4  amd64plugins for rhythmbox 
music player
ii  webext-https-everywhere 2018.9.19-1  all  Extension to force the 
use of HTTPS on many sites
ii  xul-ext-adblock-plus2.9.1+dfsg-1 all  advertisement blocking 
extension for web browsers
ii  xul-ext-firebug 2.0.17-1 all  web development plugin 
for Firefox
ii  xul-ext-flashblock  1.5.20-2 all  Mozilla extension to 
block Adobe Flash content
ii  xul-ext-gnome-keyring   0.12-1   all  Store mozilla passwords 
in GNOME Keyring
ii  xul-ext-tabmixplus  0.5.0.4-1all  add dozens of new 
capabilities to tabbed browsing
ii  xul-ext-webdeveloper1.2.13-1 all  web developer extension
ii  xul-ext-y-u-no-validate 2013052407-3 all  browser extension to make 
security exceptions temporary by default

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.1-1
ii  libasound21.1.6-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.1-1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-8
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-3
ii  libsqlite3-0  3.25.2-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-8
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-1
ii  libxcb1   1.13.1-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-5
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16.1-1
pn  mozplugger 

-- debconf-show failed

Bug#916225: List folders dash cannot expand under /usr/share

[vic...@gmail.com]

for d in $(ls -1 /usr/share); do (/bin/sh -c "ls /usr/share/$d/*"
&>/dev/null) || echo $d; done

This gives a list of folders that `ls /usr/share//*` fails
under dash. So /usr/share/docutils is just one of them.

Bug#916225: Additional info

[vic...@gmail.com]

-- System Information (Debian Sid armel running inside docker container):
Debian Release: buster/sid
 APT prefers unstable
 APT policy: (500, 'unstable')
Architecture: armel (armv7l)

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

Versions of packages python3-docutils depends on:
ii  docutils-common  0.14+dfsg-3
ii  python3  3.7.1-2
ii  python3-roman2.0.0-3

Versions of packages python3-docutils recommends:
pn  libpaper-utils
pn  python3-pil   
pn  python3-pygments  

Versions of packages python3-docutils suggests:
pn  docutils-doc
pn  fonts-linuxlibertine | ttf-linux-libertine  
pn  texlive-lang-french 
pn  texlive-latex-base  
pn  texlive-latex-recommended   

Bug#916227: dictionaries-common: ispell-find-hunspell-dictionaries fails to find installed dictionaries

[Sebastien Hinderer]

Package: dictionaries-common
Version: 1.28.1
Severity: normal

Dear Maintainer,

For some reason ispell-find-hunspell-dictionaries does not find the installed 
hunspell dictionaries, leading ispell-hunspell-dictionary-alist to be nil.

Will be happy to provide any information that can help fixing this.

output of hunspell -D is:

```
SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/shindere/.openoffice.org/3/user/wordbook:/home/shindere/.openoffice.org2/user/wordbook:/home/shindere/.openoffice.org2.0/user/wordbook:/home/shindere/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/usr/share/hunspell/fr_MC
/usr/share/hunspell/fr_LU
/usr/share/hunspell/fr_CH
/usr/share/hunspell/fr_CA
/usr/share/hunspell/fr_BE
/usr/share/hunspell/fr_FR
/usr/share/hunspell/fr
/usr/share/hunspell/en_US
/usr/share/myspell/dicts/fr_MC
/usr/share/myspell/dicts/fr_LU
/usr/share/myspell/dicts/fr_CH
/usr/share/myspell/dicts/fr_CA
/usr/share/myspell/dicts/fr_BE
/usr/share/myspell/dicts/fr_FR
```

Thanks!

Sébastien.

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

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

Versions of packages dictionaries-common depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  emacsen-common 3.0.4
ii  libtext-iconv-perl 1.7-5+b7

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  hunspell  1.7.0-2
ii  wamerican [wordlist]  2018.04.16-1
ii  wfrench [wordlist]1.2.4-1

-- debconf information:
  dictionaries-common/invalid_debconf_value:
  dictionaries-common/selecting_ispell_wordlist_default:
  dictionaries-common/ispell-autobuildhash-message:
  dictionaries-common/old_wordlist_link: true
* dictionaries-common/default-wordlist: francais (French)
  dictionaries-common/debconf_database_corruption:
* dictionaries-common/default-ispell:

Bug#916226: diffoscope pytest warnings

[Jelle van der Waa]

Package: diffoscope
Version: 107

Running the tests with 4.0.1 produces the following error:

tests/comparators/test_icc.py:53: in cd_iccdump_version
val = subprocess.check_output(('cd-iccdump', icc1().path)).decode('utf-8')
E   _pytest.warning_types.RemovedInPytest4Warning: Fixture "" called 
directly. Fixtures are not meant to be called directly, are created 
automatically when test functions request them as parameters. See 
https://docs.pytest.org/en/latest/fixture.html for more information.
=== warnings summary ===

-- 
Jelle van der Waa

Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

[You-Sheng Yang]

Package: python3-docutils
Version: 0.14+dfsg-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

While trying to install build-deps for linux kernel package,
python3-docutils failed to install on Sid armel/armhf/mips/mipsel and
passed on other official Sid architectures. The postinst script failed
with following error messages:

Setting up python3-docutils (0.14+dfsg-3) ...
update-alternatives: priority must be an integer
Use 'update-alternatives --help' for program usage information.
dpkg: error processing package python3-docutils (--configure):
 installed python3-docutils package post-installation script
 subprocess returned error exit status 2

With some more inspection into the postinst script, the for-loop inside
is to be blamed:

for exe in /usr/share/docutils/scripts/python3/*
do
update-alternatives --install /usr/bin/${exe##*/} ${exe##*/}
$exe 20
done

Somehow dash failed to expand /usr/share/docutils/scripts/python3/*, so
that exec variable is simply '/usr/share/docutils/scripts/python3/*',
which is later expanded as extra dozens of update-alternatives'   
arguments. To be more detailed, at the time executed, dash path   
expansion still worked as it's able to expand /usr/share/* and
/usr/share/docutils*, but it failed to expand /usr/share/docutils/* and
any other pattern with a /usr/share/docutils/ prefix. Files has been
installed correctly and accessible, but dash simply unable to expand
such globs.

Replace that path glob with a `find ... -type f` fixes the problem.

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

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

Versions of packages python3-docutils depends on:
ii  docutils-common  0.14+dfsg-3
ii  python3  3.7.1-2
ii  python3-roman2.0.0-3

Versions of packages python3-docutils recommends:
ii  libpaper-utils1.1.24+nmu5
ii  python3-pil   5.3.0-1
ii  python3-pygments  2.2.0+dfsg-2

Versions of packages python3-docutils suggests:
pn  docutils-doc   
ii  fonts-linuxlibertine   5.3.0-4
pn  texlive-lang-french
ii  texlive-latex-base 2018.20181116-1
pn  texlive-latex-recommended  

-- no debconf information

Bug#916087: lintian: "exec failed: Text file busy" when running tests by tag

[Chris Lamb]

tags 916087 + pending
thanks

Applied, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/15642271b7e838c9f7e4261d65e6548d9ff77251

  debian/changelog | 5 +
  1 file changed, 5 insertions(+)


Regards,

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

Bug#916224: mediathekview: seems to depend on vlc

[Dominik George]

Package: mediathekview
Version: 13.2.1-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

the package recommends vlc or mpv or mplayer.  However, mediathekview
refuses to finish the startup wizard if vlc is not installed.  It seems vlc
is needed as a dependency.

- -nik

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mediathekview depends on:
ii  default-jre [java9-runtime] 2:1.11-70
ii  java-wrappers   0.3
ii  libcommons-compress-java1.18-1
ii  libcommons-configuration2-java  2.2-1
ii  libcommons-dbcp2-java   2.5.0-1
ii  libcommons-lang3-java   3.8-2
ii  libcommons-pool2-java   2.6.0-1
ii  libcontrolsfx-java  9.0.0+hg20181001-1
ii  libguava-java   19.0-1
ii  libh2-java  1.4.197-4
ii  libjackson2-core-java   2.9.4-1
ii  libjchart2d-java3.2.2+dfsg2-2
ii  libjiconfont-font-awesome-java  4.7.0.0-1
ii  libjiconfont-java   1.0.0-1
ii  libjiconfont-swing-java 1.0.1-1
ii  libjide-oss-java3.7.4+dfsg-1
ii  liblog4j2-java  2.11.1-1
ii  libmbassador-java   1.3.1-1
ii  libmiglayout-java   5.1-2
ii  libokhttp-java  3.11.0-1
ii  libopenjfx-java 11.0.1+1-1
ii  libswingx-java  1:1.6.2-4
ii  libxz-java  1.8-2
ii  openjdk-10-jre [java9-runtime]  10.0.2+13-2
ii  openjdk-11-jre [java9-runtime]  11.0.1+13-3

Versions of packages mediathekview recommends:
ii  flvstreamer  2.1c1-1+b2
ii  mpv  0.29.1-1
ii  vlc  3.0.4-3+b3

Versions of packages mediathekview suggests:
ii  ffmpeg  7:4.0.3-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlwP6YoxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylkoMEACZtILd
PQpQSULMu8iSx19jOzlqbXDvhePjtZ8iZr8IzmSO78w3t0ec3mDILL/W0Yp18nRf
I5cdJvkU+w+v17UOrQK5DmpT/mdMLyXT4tgiG9flVvhZHHlK0QXQ49qdqDF/Gu3n
Sg/P40S1cNEU85QPLR1BAPVZ6abwRefbWki4y2mb8Mk1+Ie0BDfnjMnH35QuNrMQ
9h1g9GUSXYnY4dcTCAnNPU/QDOSiSxUhqTwzu0byKIk/JSATjPvrytSRTq/WX/R+
gKqdrpEprp9jEq/aCzwtl2S1ooExXX8RyW0GX6PBSB8ISVumBcT5fH5x52dxTUbo
trxIeAPqEn729xEabo6675g0GBkkZKZ5Nh6jLztkK1el32oYcye65g0NIwVrf5q6
VzOIjDcGzfEsJIk+qOYuPpgV3PR9OjAdKmfXVpLJK9U3A1mym+TYjJX+4VxzRJet
aW1TLWzqF51GuU4O/84BYDFEIhqMy9MEtrTAjWX3oLicEIaUR/Kh726ep7I8bDzG
rnkv0O96FIOuZefm03/KPY5Gtj3D1BZT9rRq2kGb0sw2CatWZ+aIYULEnlVA3to3
BaBR222feP6DEhANQOs8cfNls8AO0qPvfgXXzuCe73soKp/qcZQGqCQYjGmXqTpE
u904q2GArZB//NjrCUVcyTwh5XCQuka8oM18uw==
=yVSc
-END PGP SIGNATURE-

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Andreas Beckmann]

Package: moonshot-gss-eap
Version: 1.0.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

moonshot-gss-eap/experimental FTBFS against the new xmltooling and
friends stack:

util_saml.cpp:46:10: fatal error: xmltooling/util/DateTime.h: No such file or 
directory
 #include 

It's probably time to upload the package to sid once this got fixed.


Andreas


moonshot-gss-eap_1.0.1-3.log.gz
Description: application/gzip

Bug#916222: libopenmpt0: crashes with SIGSEGV when using OpenCV from Java

[Jakub Vaněk]

Hi,

I made a mistake - the affected version is 0.2.7386~beta20.3-3+deb9u3
from "http://deb.debian.org/debian stable/main armel Packages". The
version specified in this bugreport (deb9u4) is my locally built
version.

Thanks,

Jakub Vanek

Bug#916222: libopenmpt0: crashes with SIGSEGV when using OpenCV from Java

[Jakub Vanek]

Package: libopenmpt0
Version: 0.2.7386~beta20.3-3+deb9u4
Severity: important
Tags: patch

Dear Maintainer,

I am trying to load OpenCV from Java. However, OpenCV
depends on ffmpeg and ffmpeg depends on libopenmpt0.
Sadly, JVM segfaults when it attempts to load this library.

The fix is described in bug #892272, but it was not applied
to Debian stable. I have tried setting Xss Java option and also
changing the ulimit stack size, but neither did help. However
I do not think this is an OpenJDK bug.

There are also some preexisting bug reports outside of Debian BTS:
https://github.com/opencv/opencv/issues/10080
https://github.com/opencv/opencv/issues/10157

This is a backtrace of Java crashing:

Thread 2 "java" received signal SIGSEGV, Segmentation fault.
OpenMPT::CResamplerSettings::CResamplerSettings (this=0xb5bde858) at 
soundlib/Resampler.h:65
65  SrcMode = SRCMODE_POLYPHASE;
(gdb) bt
#0  OpenMPT::CResamplerSettings::CResamplerSettings (this=0xb5bde858) at 
soundlib/Resampler.h:65
#1  OpenMPT::CResampler::CResampler (fresh_generate=false, this=0xb5bde858) at 
soundlib/Resampler.h:109
#2  OpenMPT::ResampleCacheInitialzer::ResampleCacheInitialzer (this=0x9dcc4d58 
) at soundlib/Tables.cpp:1030
#3  0xb6fdf124 in call_init (l=, argc=argc@entry=4, 
argv=argv@entry=0xbefff5b4, env=env@entry=0xbefff5c8) at dl-init.c:72
#4  0xb6fdf248 in call_init (env=, argv=, 
argc=, l=) at dl-init.c:30
#5  _dl_init (main_map=main_map@entry=0xa2092608, argc=4, argv=0xbefff5b4, 
env=0xbefff5c8) at dl-init.c:120
#6  0xb6fe3ca8 in dl_open_worker (a=) at dl-open.c:575
#7  0xb6fdefb4 in _dl_catch_error (objname=0xb5c3097c, 
objname@entry=0xb5c2ed4c, errstring=0xb5c2ede0, errstring@entry=0xb5c2ed50, 
mallocedp=0xb5c2ed4c, mallocedp@entry=0xb5c2ed4b, operate=0xb5c2ed50, 
args=args@entry=0xb5c2ed54) at dl-error.c:187
#8  0xb6fe345c in _dl_open (file=0xa24d1e08 
"/usr/lib/jni/libopencv_java249.so", mode=-2147483647, caller_dlopen=0xb6883cf8 
, nsid=-2, argc=4, argv=0xbefff5b4, 
env=0xbefff5c8) at dl-open.c:660
#9  0xb6f4db5c in dlopen_doit (a=0xb5c2efa0) at dlopen.c:66
#10 0xb6fdefb4 in _dl_catch_error (objname=0xb5c3097c, 
objname@entry=0xb5a00554, errstring=0x0, errstring@entry=0xb5a00558, 
mallocedp=0xb5a00554, mallocedp@entry=0xb5a00550, operate=0xb5a00558, 
operate@entry=0xb6f4dadc , args=args@entry=0xb5c2efa0) at 
dl-error.c:187
#11 0xb6f4e310 in _dlerror_run (operate=0xb6f4dadc , 
args=args@entry=0xb5c2efa0) at dlerror.c:163
#12 0xb6f4dc2c in __dlopen (file=file@entry=0xa24d1e08 
"/usr/lib/jni/libopencv_java249.so", mode=mode@entry=1) at dlopen.c:87
#13 0xb6883cf8 in os::Linux::dlopen_helper (ebuflen=1024, ebuf=0xb5c2f040 "", 
filename=0xa24d1e08 "/usr/lib/jni/libopencv_java249.so") at 
/build/jdk/src/hotspot/os/linux/os_linux.cpp:1849
#14 os::dll_load (filename=filename@entry=0xa24d1e08 
"/usr/lib/jni/libopencv_java249.so", ebuf=ebuf@entry=0xb5c2f040 "", 
ebuflen=ebuflen@entry=1024) at /build/jdk/src/hotspot/os/linux/os_linux.cpp:1682
#15 0xb65d9d64 in JVM_LoadLibrary (name=0xa24d1e08 
"/usr/lib/jni/libopencv_java249.so") at 
/build/jdk/src/hotspot/share/prims/jvm.cpp:3445
#16 0xb5b8727c in Java_java_lang_ClassLoader_00024NativeLibrary_load0 
(env=0xb5a10680, this=0xb5c2f9f8, name=0xb5c2f9f4, isBuiltin=) 
at /build/jdk/src/java.base/share/native/libjava/ClassLoader.c:353
#17 0xb38550a4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I have rebuilt the libopenmpt0 package with the two patches from the
previous issue and indeed, they solve the problem.
https://github.com/OpenMPT/openmpt/commit/6f8f7be5848be8c4487b1779c332b802674f6747.patch
https://github.com/OpenMPT/openmpt/commit/133007530cbe737f4b56db907aa6baee0ea5b17d.patch

How to reproduce:
- pick an ARM device with Debian Stretch userland
- install java and libopencv2.4-java
- try running 
https://github.com/ev3dev-lang-java/examples/blob/master/opencv/src/main/java/example/opencv/HelloWorldCV.java

Summary:
 * I want to be able to do an equivalent of dlopen() on this library from 
HotSpot JVM.
 * I expect the call to succeed.
 * What happens instead is that the call causes a segmentation fault. This is 
probably due to a stack overflow in the library on initialization.
 * evasive.gy...@gmail.com had found a fix for this issue in two upstream 
commits, details are above.

Thanks,

Jakub Vanek


-- System Information:
Debian Release: 9.6
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: armel (armv7l)

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

Versions of packages libopenmpt0 depends on:
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libmpg123-0 1.23.8-1+b1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libvorbis0a 1.3

Bug#916221: node-prismjs: Unable to install due to missing node-clipboard

[Andreas Tille]

Package: node-prismjs
Severity: grave
Justification: renders package unusable

Hi,

$ sudo apt-get install node-prismjs
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 node-prismjs : Depends: node-clipboard (>= 1.7.1) but it is not installable


There is no package node-clipboard available in Debian.

Kind regards

   Andreas.


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

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

Bug#916203: nmu: ghc-8.4.4 transition

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 11/12/2018 12:53, Ilias Tsitsimpis wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Dear release team,
> 
> we (the Debian Haskell Group) have uploaded ghc-8.4.4 to unstable, and
> need to re-build every haskell library with this new version of ghc.
> 
> pochu (CC-ed) took care of most of the required binNMUs, but didn't
> schedule the mips* ones because ghc was not yet available on those
> architectures.
> 
> Could you please schedule the remaining binNMUs? Here is a (hopefully
> complete) list.

Done.

Let's see how things go once mips*el catches up.

Cheers,
Emilio

Bug#893723: 893723

[Sébastien Delafond]

Control: tag -1 + upstream
Control: forwarded -1 https://github.com/NagVis/nagvis/issues/79

This has apparently been closed in "recent releases", although upstream
doesn't mention when that happened exactly. Scouring through git log, it
appears to be in this commit:

  commit da8746985d21b517a66ec8795a672192e4551b49
  Author: Lars Michelsen 
  Date:   Fri Apr 22 13:18:48 2016 +0200

FIX: Fixed some compatibility issues with PHP 7. NagVis should work with it.

This would make 1.9b7 the first release containing the fix.

Cheers,

-- 
Seb

Bug#916220: saidar: segfault after couple of minutes

[Mindaugas Celiesius]

Package: saidar
Version: 0.91-1+b1
Severity: important

Dear Maintainer,

When i start saidar with argument '-c', after couple of minutes it crashes with 
segmentation fault. In command "dmesg" i see this message "[ 1581.181577] 
saidar[4646]: segfault at 0 ip 7f39de74053e sp 7ffe88e43b58 error 4 in 
libc-2.24.so[7f39de6b1000+195000]"
I suggest that program be corrected.

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

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

Versions of packages saidar depends on:
ii  libc6  2.24-11+deb9u3
ii  libncurses56.0+20161126-1+deb9u2
ii  libstatgrab10  0.91-1+b1
ii  libtinfo5  6.0+20161126-1+deb9u2

saidar recommends no packages.

saidar suggests no packages.

-- no debconf information

Bug#913950: squid: should improve handling of Debian packages

[Mike Gabriel]

Hi Amos,

On Tue, 20 Nov 2018 20:32:55 +1300 Amos Jeffries  
wrote:


>Thus I am a bit surprised that Mike saw a useful improvement this 
config. The expectation from me is that these rules make Squid spendmore 
bandwidth re-fetching objects it does not strictly have to. A net 
negative on bandwidth gains over a default proxy config.


This is indeed interesting, as I adopted the settings from 
squid-deb-proxy as is without any modifications.


I tested the settings on a Debian 9 machine running squid3. My test was 
a debootstrap of an unstable chroot.


Whithout these settings, the download phase was always 4 minutes (on a 
ADSL 16.000 line).


With these settings applied, the first debootstrap's download phase 
still took 4 minutes, but the following debootstrap's download phases 
took 20 seconds or even less. I did not look into details regarding 
packaging being re-fetched, because the improvement already made me 
happy enough.


Thanks+Greets,

Mike

Bug#916219: nixnote2: Non-free icon

[Boyuan Yang]

Package: nixnote2
Version: 2.1.1-1
Severity: serious

Nixnote2 before 2.1.1 (including 2.1.1) is using a CC-BY-ND icon,
which is incompatible with DFSG.

This problem has been fixed by using a GPL-3-licensed icon to replace
the old one in git trunk. We should consider uploading the git trunk
version (or the next upstream release) before Buster freeze.

--
Thanks,
Boyuan Yang