Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

Le 17 déc. 2017 05:18, "Andreas Beckmann"  a écrit :

Hi Aurelien,

I can reproduce the problem in glxgears using nvidia driver 375.82-9~bpo9+1
and libc6 2.24-11+deb9u1 in a mostly stretch system:

I ran glxgears in gdb and it died here:

(gdb) bt
#0  0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at
genops.c:102
#1  0x76a13fa2 in _IO_new_file_init_internal
(fp=fp@entry=0x557b2510)
at fileops.c:151
#2  0x76a08573 in __fopen_internal (filename=0x557b2450
"/home/beckmann/.Xauthority", mode=0x73e04cb7 "rb", is32=1) at
iofopen.c:82
#3  0x73e04477 in XauGetBestAuthByAddr () from
/usr/lib/x86_64-linux-gnu/libXau.so.6
#4  0x74017070 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#5  0x740171ed in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#6  0x74016d1b in xcb_connect_to_display_with_auth_info () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#7  0x76f93e8a in _XConnectXCB () from /usr/lib/x86_64-linux-gnu/
libX11.so.6
#8  0x76f84bc2 in XOpenDisplay () from /usr/lib/x86_64-linux-gnu/
libX11.so.6
#9  0x63f4 in main (argc=, argv=)
at glxgears.c:762

   0x76a15360 <+512>:   callq  *%rax
(gdb) print /x $rax
$8 = 0xb08ebdf3733b6f74

(gdb) info shared
>FromTo  Syms Read   Shared Object Library
0x77dd9aa0  0x77df5340  Yes
 /lib64/ld-linux-x86-64.so.2
0x77b8dcc0  0x77bb6100  Yes (*)
 /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0
0x778d96d0  0x7792bb13  Yes (*)
 /usr/lib/x86_64-linux-gnu/libGLU.so.1
0x775e8f00  0x7765e291  Yes (*)
 /usr/lib/x86_64-linux-gnu/libGL.so.1
0x77297680  0x773038da  Yes
 /lib/x86_64-linux-gnu/libm.so.6
0x76f6fda0  0x76ff7434  Yes (*)
 /usr/lib/x86_64-linux-gnu/libX11.so.6
0x76d43700  0x76d4d49f  Yes (*)
 /usr/lib/x86_64-linux-gnu/libXext.so.6
0x769c0910  0x76aea403  Yes
 /lib/x86_64-linux-gnu/libc.so.6
0x766ae090  0x76756b69  Yes
 /usr/lib/x86_64-linux-gnu/libstdc++.so.6
0x7640dac0  0x7641dde5  Yes
 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x76208810  0x7620a5a3  Yes (*)
 /usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82
0x74734600  0x75817c77  Yes (*)
 /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
0x7422fd80  0x7423094e  Yes
 /lib/x86_64-linux-gnu/libdl.so.2
0x74012b40  0x740249f5  Yes (*)
 /usr/lib/x86_64-linux-gnu/libxcb.so.1
0x73e04010  0x73e04c8c  Yes (*)
 /usr/lib/x86_64-linux-gnu/libXau.so.6
0x73bfe340  0x73bffc48  Yes (*)
 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
0x739ea3d0  0x739f75df  Yes (*)
 /lib/x86_64-linux-gnu/libbsd.so.0
0x737e10e0  0x737e3ecf  Yes
 /lib/x86_64-linux-gnu/librt.so.1
0x735c7ab0  0x735d4811  Yes /lib/x86_64-linux-gnu/
libpthread.so.0

Since I wanted to know where that invalid pointer came from, I stopped a
few instructions earlier:

(gdb) break *__GI__IO_link_in+480
Breakpoint 3 at 0x76a15340: file genops.c, line 102.

(gdb) disassemble
Dump of assembler code for function __GI__IO_link_in:
   0x76a15160 <+0>: mov(%rdi),%eax
...
=> 0x76a15340 <+480>:   mov0x32a3a9(%rip),%rax#
0x76d3f6f0 <__libc_pthread_functions+368>
   0x76a15347 <+487>:   mov%rsp,%rdi
   0x76a1534a <+490>:   xor%edx,%edx
   0x76a1534c <+492>:   ror$0x11,%rax
   0x76a15350 <+496>:   xor%fs:0x30,%rax
   0x76a15359 <+505>:   lea-0x580(%rip),%rsi#
0x76a14de0 
   0x76a15360 <+512>:   callq  *%rax
...

(gdb) print /x $rax
$1 = 0xfbad248c
(gdb) stepi
0x76a15347  102 in genops.c
(gdb) print /x $rax
$2 = 0xd14c4c80fe79611d
(gdb) print &__libc_pthread_functions.ptr__pthread_cleanup_push_defer
$3 = (void (**)(struct _pthread_cleanup_buffer *, void (*)(void *), void
*)) 0x76d3f6f0 <__libc_pthread_functions+368>
(gdb) print __libc_pthread_functions.ptr__pthread_cleanup_push_defer
$4 = (void (*)(struct _pthread_cleanup_buffer *, void (*)(void *), void *))
0xd14c4c80fe79611d
(gdb) stepi
0x76a1534a  102 in genops.c
(gdb) stepi
0x76a1534c  102 in genops.c
(gdb) print /x $rax
$5 = 0xd14c4c80fe79611d
(gdb) stepi
0x76a15350  102 in genops.c
(gdb) print /x $rax
$6 = 0xb08ee8a626407f3c
(gdb) stepi
0x76a15359  102 in genops.c
(gdb) print /x $rax
$7 = 0xb08ebdf3733b6f74
(gdb) stepi
0x76a15360  102 in genops.c
(gdb) print /x $rax
$8 = 0xb08ebdf3733b6f74
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at
genops.c:102
102 in genops.c

(gdb) print &_pthread_cleanup_push_defer
$9 = (void (*)(struct _pthread_cleanup_buffer *, void (*)(void *), void 

Bug#884576: ITP: pokemmo -- Multiplayer online game based on the Pokemon universe

[Carlos Donizete Froes]

Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: pokemmo
  Version : 1.4.1
  Upstream Author : Carlos Donizete Froes 
* URL : https://pokemmo.eu
* License : GPL-3.0+
  Programming Lang: Shell
  Description : Multiplayer online game based on the Pokemon universe

 PokeMMO is an emulator of several popular console games with additional
 features and multiplayer capabilities.
 .
 But you can face other players and even form groups with your friends,
 do joint battles and group missions.
 .
 You can call them to duel with you or even watch the fight with other people.

Bug#884571: RM: torbrowser-launcher/0.1.9-1+deb8u3

[Roger Shimizu]

[ CC pkg-privacy-maintainers list for the record ]

On Sun, Dec 17, 2017 at 1:59 PM, Roger Shimizu  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
>
> The old version of torbrowser-launcher cannot work properly anymore,
> because it uses the embedded old key.
> That's also the reason why it also missed the stretch release [0].
>
> People want to use it in oldstable(jessie) should consider sloppy
> backports [1].
>
> So please kindly help to remove torbrowser-launcher/0.1.9-1+deb8u3.
> Thank you!
>
> [0] https://bugs.debian.org/861744
> [1] https://wiki.debian.org/TorBrowser#Debian_8_.22Jessie.22

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
Control: tags -1 + moreinfo

Package name: syncthingtray
Version : 0.7.1
Upstream Author : Martchus 
URL : https://github.com/Martchus/syncthingtray
License : GPL-2+
Programming Lang: C++ and QML
Description : a tray applet, plasmoid, and Dolphin integration for Syncthing

Long descriptions have yet to be written, because I haven't yet
decided if we should also provide a light variant that doesn't depend
on Qt Webkit or Web Engine.  The source package would need to be built
twice to do this, and I'd like to target this in the future rather
than right now.  When the plasmoid is declared stable I think that it
might be reasonable for it to provide syncthingtray and conflict with
it, so that syncthingtray can provide the light version.  This might
require a third binary package that contains only a few shared files.
Please let me know what you think!

Here is my WIP copy:

Package: syncthingtray
...
Description: Tray applet for Syncthing
 This package provides quick access to the most frequently used
 Syncthing features. It cannot yet add or remove shared folders or
 manage Device IDs by itself; however, it provides access to the
 official web UI from its system tray icon using Qt WebEngine.
 .
 It enables Syncthing notifications via Qt if possible and falls back
 to D-Bus notifications if necessary, shows the status of the
 Syncthing systemd unit, and can start or stop Syncthing using this
 unit. Of course the tray application can be configured to
 automatically start Syncthing.
 .
 Additionally it features a simple command line utility called
 syncthingctl that can check Syncthing status, trigger
 rescan/pause/resume/restart, and wait for idle before doing
 something.

Package: plasma-syncthing
...
Description: Dolphin integration for Syncthing
 This package contains a KIO plugin that displays the synchronisation
 status of a directory and makes the following Syncthing actions
 available in Dolphin:
   * Rescan selected items
   * Rescan entire Syncthing directory
   * Pause/resume Syncthing directory
 .
 It also contains an experimental implementation of syncthingtray
 as a KDE Plasma 5 Plasmoid rather than as a tray application.

I believe that this package is useful because deeper desktop
integration makes it easier to transition from Dropbox to Syncthing.
One of the reasons I'd like to start with KDE integration is because
I'm disappointed with how poorly Dropbox is integrated into it.

I will start using syncthingtray as soon as I've packaged it, and have
tagged this bug moreinfo until I've had a chance to thoroughly test
it.  To the best of my knowledge no existing package provides this
functionality for Syncthing; however, it is similar to dropboxd's tray
applet.

If this proposal is well received then collab-maint seems most
appropriate, otherwise I'll probably maintain it on the KDE Addons
Team.  I will need a sponsor for the initial upload.

Sincerely,
Nicholas

Bug#884574: debhelper: fix typo

[Hideki Yamane]

Package: debhelper
Severity: minor
Tags: patch

Hi,

 Just fix typo in pod file (unncessary -> unnecessary).


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
>From ce47eeb3078f742bd739c00e607d6d7020fd5c5f Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Sun, 17 Dec 2017 14:41:25 +0900
Subject: [PATCH 2/2] typo fix

also fix po files
---
 man/po4a/po/de.po | 2 +-
 man/po4a/po/debhelper.pot | 2 +-
 man/po4a/po/es.po | 2 +-
 man/po4a/po/fr.po | 2 +-
 man/po4a/po/ja.po | 4 ++--
 man/po4a/po/pt.po | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/man/po4a/po/de.po b/man/po4a/po/de.po
index a58c7316..363af420 100644
--- a/man/po4a/po/de.po
+++ b/man/po4a/po/de.po
@@ -697,7 +697,7 @@ msgstr ""
 #: debhelper.pod:252
 msgid ""
 "As an optimization, B will try to avoid passing these options to "
-"subprocesses, if they are unncessary and the only options passed.  Notably "
+"subprocesses, if they are unnecessary and the only options passed.  Notably "
 "this happens when B does not have a I parameter "
 "(or its value is 1)."
 msgstr ""
diff --git a/man/po4a/po/debhelper.pot b/man/po4a/po/debhelper.pot
index b176566b..d0869397 100644
--- a/man/po4a/po/debhelper.pot
+++ b/man/po4a/po/debhelper.pot
@@ -501,7 +501,7 @@ msgstr ""
 #: debhelper.pod:252
 msgid ""
 "As an optimization, B will try to avoid passing these options to "
-"subprocesses, if they are unncessary and the only options passed.  Notably "
+"subprocesses, if they are unnecessary and the only options passed.  Notably "
 "this happens when B does not have a I parameter "
 "(or its value is 1)."
 msgstr ""
diff --git a/man/po4a/po/es.po b/man/po4a/po/es.po
index 8c471011..a537d26e 100644
--- a/man/po4a/po/es.po
+++ b/man/po4a/po/es.po
@@ -792,7 +792,7 @@ msgstr ""
 #: debhelper.pod:252
 msgid ""
 "As an optimization, B will try to avoid passing these options to "
-"subprocesses, if they are unncessary and the only options passed.  Notably "
+"subprocesses, if they are unnecessary and the only options passed.  Notably "
 "this happens when B does not have a I parameter "
 "(or its value is 1)."
 msgstr ""
diff --git a/man/po4a/po/fr.po b/man/po4a/po/fr.po
index fb9604c4..b06ffd74 100644
--- a/man/po4a/po/fr.po
+++ b/man/po4a/po/fr.po
@@ -752,7 +752,7 @@ msgstr ""
 #: debhelper.pod:252
 msgid ""
 "As an optimization, B will try to avoid passing these options to "
-"subprocesses, if they are unncessary and the only options passed.  Notably "
+"subprocesses, if they are unnecessary and the only options passed.  Notably "
 "this happens when B does not have a I parameter "
 "(or its value is 1)."
 msgstr ""
diff --git a/man/po4a/po/ja.po b/man/po4a/po/ja.po
index fa1d08b6..93ea7599 100644
--- a/man/po4a/po/ja.po
+++ b/man/po4a/po/ja.po
@@ -674,12 +674,12 @@ msgstr ""
 "10 (以降) の場合は B<--parallel> をデフォルトに、そうでない場合は B<--no-"
 "parallel> が指定されます。"
 
-# FIXME: typo: unncessary
+# FIXME: typo: unnecessary
 #. type: textblock
 #: debhelper.pod:252
 msgid ""
 "As an optimization, B will try to avoid passing these options to "
-"subprocesses, if they are unncessary and the only options passed.  Notably "
+"subprocesses, if they are unnecessary and the only options passed.  Notably "
 "this happens when B does not have a I parameter "
 "(or its value is 1)."
 msgstr ""
diff --git a/man/po4a/po/pt.po b/man/po4a/po/pt.po
index fc58cd99..53708bea 100644
--- a/man/po4a/po/pt.po
+++ b/man/po4a/po/pt.po
@@ -691,7 +691,7 @@ msgstr ""
 #: debhelper.pod:252
 msgid ""
 "As an optimization, B will try to avoid passing these options to "
-"subprocesses, if they are unncessary and the only options passed.  Notably "
+"subprocesses, if they are unnecessary and the only options passed.  Notably "
 "this happens when B does not have a I parameter "
 "(or its value is 1)."
 msgstr ""
-- 
2.15.1

>From 2980bbe7e90dec0ea6825b441be33f176d0ffa96 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Sun, 17 Dec 2017 14:39:45 +0900
Subject: [PATCH 1/2] fix typo

unncessary -> unn"e"cessary
---
 debhelper.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debhelper.pod b/debhelper.pod
index 0e45a4d2..dd73c3f9 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -250,7 +250,7 @@ If neither option is specified, debhelper currently defaults to
 B<--parallel> in compat 10 (or later) and B<--no-parallel> otherwise.
 
 As an optimization, B will try to avoid passing these options to
-subprocesses, if they are unncessary and the only options passed.
+subprocesses, if they are unnecessary and the only options passed.
 Notably this happens when B does not have a
 I parameter (or its value is 1).
 
-- 
2.15.1

Bug#857597: closed by Lukas Schwaighofer <lu...@schwaighofer.name> (Re: Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC)

[David Christensen]

Debian Bug Tracking System:

debian-9.3.0-i386-xfce-CD-1.iso on a USB flash drive boots to Debian 
Installer on computer with Intel D865GBFLK motherboard and Pentium 2.8E 
GHz processor.



Thank you, everybody.  :-)


David

Bug#884573: RM: torbrowser-launcher/0.2.6-2~bpo8+1

[Roger Shimizu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The old version of torbrowser-launcher cannot work properly anymore,
because it uses the embedded old key.
That's also the reason why it also missed the stretch release [0].

People want to use it in stable(jessie) should consider sloppy
backports [1].

So please kindly help to remove torbrowser-launcher/0.2.6-2~bpo8+1.
Thank you!

[0] https://bugs.debian.org/861744
[1] https://wiki.debian.org/TorBrowser#Debian_8_.22Jessie.22

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#884572: lintian.debian.org: 'more' links from the maintainer reports to the full reports

[Paul Wise]

Package: lintian
Severity: wishlist

On lintian.debian.org in the maintainer report it would be nice to have
a 'more' link on each package that would link to the corresponding part
of the full report with all the info/pedantic/experimental tags. I
often want to see the additional tags and need to resort to modifying
the URL in my browser instead of clicking a link, this would be faster.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#884571: RM: torbrowser-launcher/0.1.9-1+deb8u3

[Roger Shimizu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The old version of torbrowser-launcher cannot work properly anymore,
because it uses the embedded old key.
That's also the reason why it also missed the stretch release [0].

People want to use it in oldstable(jessie) should consider sloppy
backports [1].

So please kindly help to remove torbrowser-launcher/0.1.9-1+deb8u3.
Thank you!

[0] https://bugs.debian.org/861744
[1] https://wiki.debian.org/TorBrowser#Debian_8_.22Jessie.22

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#884570: openbox: Invalid output from pipe-menu "openbox-menu -i lxde-applications.menu"

[Paul Wise]

Package: openbox
Version: 3.6.1-5
Severity: normal

When I try to open the Applications menu in openbox, I get an error:

Invalid output from pipe-menu "openbox-menu -i lxde-applications.menu"

This is because I have gnome-menus installed instead of lxmenu-data,
but the openbox menu.xml uses lxde-applications.menu from lxmenu-data
and openbox does not depend on lxmenu-data.

There are some possible solutions here:

Add a dependency from openbox to lxmenu-data. This would be simple and
straight-forward but hard-coding LXDE menus doesn't seem correct.

Drop the lxde-applications.menu argument from the openbox-menu call.
openbox is not LXDE so this makes some sense.

Enhance openbox-menu so that it can take multiple arguments and choose
the first one that exists on the system. This would then require
openbox to depend on each of the menu packages it uses.

$ dpkg -S /etc/xdg/openbox/menu.xml
openbox: /etc/xdg/openbox/menu.xml
$ grep Applications /etc/xdg/openbox/menu.xml
  
$ apt-file search lxde-applications.menu
lxmenu-data: /etc/xdg/menus/lxde-applications.menu
$ apt-cache show openbox | grep lxmenu-data

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

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

Versions of packages openbox depends on:
ii  libc6 2.25-3
ii  libglib2.0-0  2.54.1-1
ii  libice6   2:1.0.9-2
ii  libobrender32v5   3.6.1-5
ii  libobt2v5 3.6.1-5
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-4+b2
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1+b2
ii  libxcursor1   1:1.1.14-3.1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  openbox-menu  0.8.0+hg20161009-1

Versions of packages openbox recommends:
ii  obconf  1:2.0.4+git20150213-2
ii  obsession   20140608-2+b1
ii  python-xdg  0.25-4
pn  scrot   

Versions of packages openbox suggests:
ii  fonts-dejavu   2.37-1
ii  libxml2-dev2.9.4+dfsg1-5.2
pn  openbox-gnome-session  
pn  openbox-kde-session
ii  python 2.7.14-3
pn  tint2  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."

[Andreas Beckmann]

On 2017-12-16 05:34, Chris Manougian wrote:
>>> root@asus:/home/chris# glxinfo | grep OpenGL
>>> libGL error: No matching fbConfigs or visuals found
>>> libGL error: failed to load driver: swrast
>>> X Error of failed request:  GLXBadContext
>>>   Major opcode of failed request:  154 (GLX)
>>>   Minor opcode of failed request:  6 (X_GLXIsDirect)
>>>   Serial number of failed request:  48
>>>   Current serial number in output stream:  47

Is root able to access $DISPLAY? Can it start an xterm?
Does it work as a regular user?
Does glxinfo output anything non-error at all?
Why is it trying to load swrast?


Andreas

on stretch with driver from backports:

$ DISPLAY=:0 glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 730/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 375.82
OpenGL core profile shading language version string: 4.50 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5.0 NVIDIA 375.82
OpenGL shading language version string: 4.50 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)

OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 375.82
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Bug#866476: rapid-photo-downloader: depends on obsolete python-imaging (replace with python3-pil or python-pil)

[Antoine Beaupre]

Control: block 866476 by 867527

I believe that the newer version of RPD doesn't require imaging *or*
pil:

https://bazaar.launchpad.net/~dlynch3/rapid/zeromq_pyqt/view/head:/requirements.txt

so i believe this will be fixed along with #867527

On Thu, Jun 29, 2017 at 04:39:19PM +, Matthias Klose wrote:
> Package: src:rapid-photo-downloader
> Version: 0.4.11-1
> Severity: important
> Tags: sid buster
> User: d...@debian.org
> Usertags: imaging-pillow
> 
> One or more binary packages built from this source depends on or
> recommends python-imaging, which is obsolete for some years now.
> Please build the source using the python-pil package. If your
> package doesn't need to be built with Python2, please consider using
> Python3 and depend on python3-pil.
> 
> Planning to remove python-imaging for the buster release, so the
> severity of this issues might be raised.

-- 
It is not enough to fight for the land; it is even more important to
enjoy it. While you can. While it’s still here.
- Edward Abbey


signature.asc
Description: PGP signature

Bug#867527: rapid-photo-downloader: Please update to rapid-photo-downloader 0.9, uses QT as backend.

[Antoine Beaupre]

On Thu, Oct 19, 2017 at 11:28:47AM -0200, Herbert Fortes wrote:
> Hi,
> 
> Damon Lynch, damonly...@gmail.com, sent me an email
> asking about python-gphoto2.
> 
> I set myself as 'owner' of  #781693[0]. It blocks
> this bug if I understood right.
> 
> [0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781693
> 
> I will try to do the Debian package this weekend. If
> there is something that I should know, please send me
> an email.

So that seems to have been fixed, yet we are still blocked on a bunch of
other packages:

867800: RFP: python-prind -- Python Progress Bar and Percent Indicator
Utility

867801: RFP: python-mediainfo -- This small package is a wrapper around
the MediaInfo library.

867799: RFP: python-colour -- Converts and manipulates common color
representation (RGB, HSL, web, …)

867802: RFP: python-rawkit -- rawkit is a ctypes-based LibRaw binding
for Python inspired by the Wand API.

Anyone working on those?

it'd be great to see an up to date version of r-p-d in debian!

a.
-- 
La destruction de la société totalitaire marchande n'est pas une affaire
d'opinion. Elle est une nécessité absolue dans un monde que l'on sait
condamné. Puisque le pouvoir est partout, c'est partout et tout le temps
qu'il faut le combattre. - Jean-François Brient, de la servitude moderne


signature.asc
Description: PGP signature

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Andreas Beckmann]

Hi Aurelien,

I can reproduce the problem in glxgears using nvidia driver 375.82-9~bpo9+1 and 
libc6 2.24-11+deb9u1 in a mostly stretch system:

I ran glxgears in gdb and it died here:

(gdb) bt
#0  0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at 
genops.c:102
#1  0x76a13fa2 in _IO_new_file_init_internal 
(fp=fp@entry=0x557b2510) at fileops.c:151
#2  0x76a08573 in __fopen_internal (filename=0x557b2450 
"/home/beckmann/.Xauthority", mode=0x73e04cb7 "rb", is32=1) at iofopen.c:82
#3  0x73e04477 in XauGetBestAuthByAddr () from 
/usr/lib/x86_64-linux-gnu/libXau.so.6
#4  0x74017070 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#5  0x740171ed in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#6  0x74016d1b in xcb_connect_to_display_with_auth_info () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#7  0x76f93e8a in _XConnectXCB () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x76f84bc2 in XOpenDisplay () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x63f4 in main (argc=, argv=) at 
glxgears.c:762

   0x76a15360 <+512>:   callq  *%rax
(gdb) print /x $rax
$8 = 0xb08ebdf3733b6f74

(gdb) info shared
>FromTo  Syms Read   Shared Object Library
0x77dd9aa0  0x77df5340  Yes /lib64/ld-linux-x86-64.so.2
0x77b8dcc0  0x77bb6100  Yes (*) 
/usr/lib/x86_64-linux-gnu/libGLEW.so.2.0
0x778d96d0  0x7792bb13  Yes (*) 
/usr/lib/x86_64-linux-gnu/libGLU.so.1
0x775e8f00  0x7765e291  Yes (*) 
/usr/lib/x86_64-linux-gnu/libGL.so.1
0x77297680  0x773038da  Yes 
/lib/x86_64-linux-gnu/libm.so.6
0x76f6fda0  0x76ff7434  Yes (*) 
/usr/lib/x86_64-linux-gnu/libX11.so.6
0x76d43700  0x76d4d49f  Yes (*) 
/usr/lib/x86_64-linux-gnu/libXext.so.6
0x769c0910  0x76aea403  Yes 
/lib/x86_64-linux-gnu/libc.so.6
0x766ae090  0x76756b69  Yes 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
0x7640dac0  0x7641dde5  Yes 
/lib/x86_64-linux-gnu/libgcc_s.so.1
0x76208810  0x7620a5a3  Yes (*) 
/usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82
0x74734600  0x75817c77  Yes (*) 
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
0x7422fd80  0x7423094e  Yes 
/lib/x86_64-linux-gnu/libdl.so.2
0x74012b40  0x740249f5  Yes (*) 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
0x73e04010  0x73e04c8c  Yes (*) 
/usr/lib/x86_64-linux-gnu/libXau.so.6
0x73bfe340  0x73bffc48  Yes (*) 
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6
0x739ea3d0  0x739f75df  Yes (*) 
/lib/x86_64-linux-gnu/libbsd.so.0
0x737e10e0  0x737e3ecf  Yes 
/lib/x86_64-linux-gnu/librt.so.1
0x735c7ab0  0x735d4811  Yes 
/lib/x86_64-linux-gnu/libpthread.so.0

Since I wanted to know where that invalid pointer came from, I stopped a few 
instructions earlier:

(gdb) break *__GI__IO_link_in+480
Breakpoint 3 at 0x76a15340: file genops.c, line 102.

(gdb) disassemble
Dump of assembler code for function __GI__IO_link_in:
   0x76a15160 <+0>: mov(%rdi),%eax
...
=> 0x76a15340 <+480>:   mov0x32a3a9(%rip),%rax# 
0x76d3f6f0 <__libc_pthread_functions+368>
   0x76a15347 <+487>:   mov%rsp,%rdi
   0x76a1534a <+490>:   xor%edx,%edx
   0x76a1534c <+492>:   ror$0x11,%rax
   0x76a15350 <+496>:   xor%fs:0x30,%rax
   0x76a15359 <+505>:   lea-0x580(%rip),%rsi# 
0x76a14de0 
   0x76a15360 <+512>:   callq  *%rax
...

(gdb) print /x $rax
$1 = 0xfbad248c
(gdb) stepi
0x76a15347  102 in genops.c
(gdb) print /x $rax
$2 = 0xd14c4c80fe79611d
(gdb) print &__libc_pthread_functions.ptr__pthread_cleanup_push_defer
$3 = (void (**)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 
0x76d3f6f0 <__libc_pthread_functions+368>
(gdb) print __libc_pthread_functions.ptr__pthread_cleanup_push_defer
$4 = (void (*)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 
0xd14c4c80fe79611d
(gdb) stepi
0x76a1534a  102 in genops.c
(gdb) stepi
0x76a1534c  102 in genops.c
(gdb) print /x $rax
$5 = 0xd14c4c80fe79611d
(gdb) stepi
0x76a15350  102 in genops.c
(gdb) print /x $rax
$6 = 0xb08ee8a626407f3c
(gdb) stepi
0x76a15359  102 in genops.c
(gdb) print /x $rax
$7 = 0xb08ebdf3733b6f74
(gdb) stepi
0x76a15360  102 in genops.c
(gdb) print /x $rax
$8 = 0xb08ebdf3733b6f74
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at 
genops.c:102
102 in genops.c

(gdb) print &_pthread_cleanup_push_defer
$9 = (void (*)(struct 

Bug#883556: libsqlite3-0-dbg: missing Build-Ids, please drop -dbg package in favour of automatic -dbgsym packages

[Paul Wise]

On Tue, 05 Dec 2017 14:56:14 +0800 Paul Wise wrote:

> The libsqlite3-0-dbg package is missing Build-Ids for some files,
> please drop the -dbg package in favour of automatic -dbgsym packages.

While switching to -dbgsym packages is better, you can also rebuild
using debhelper 11, which fixes the cause of this issue:

https://bugs.debian.org/884152

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#884569: Unknown Symbol error when loading Tun driver

[Ryan Thoryk]

Package: linux-image-4.9.0-4-amd64
Version: 4.9.51-1
Severity: important

I've been trying to use the vpn on my system, but am getting the error
"Unknown symbol dev_get_valid_name (err 0)" when trying to load the
"tun" driver.  When using modprobe, I get:
"modprobe: ERROR: could not insert 'tun': Unknown symbol in module, or
unknown parameter (see dmesg)"

I haven't tried any other kernels to see if they're affected.

-- 
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#884568: RFP: cucumber.js -- test runner from Gherkin feature descriptions

[Ben Finney]

Package: wnpp
Severity: wishlist

* Package name: cucumber.js
  Version : 3.2.0
  Upstream Author : Cucumber Limited
* URL : https://github.com/cucumber/cucumber-js
* License : Expat
  Programming Lang: JavaScript
  Description : test runner from Gherkin feature descriptions

  Cucumber is a tool for automatically running tests written in the
  Gherkin plain language for behaviour definition. Because they're
  written in plain language, they can be read by anyone on your
  team. Because they can be read by anyone, you can use them to
  help improve communication, collaboration and trust on your
  team.

  Cucumber.js is the JavaScript implementation of Cucumber and
  runs on both Node.js and modern web browsers.

-- 
 \   “Killing the creator was the traditional method of patent |
  `\protection” —Terry Pratchett, _Small Gods_ |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#879958: python3-pyqt5.qtwebengine: package not available for Raspberry Pi

[peter green]

On 16/12/17 16:10, Dmitry Shachnev wrote:

Control: tags -1 moreinfo

Hi, and sorry for the delay!

On Fri, Oct 27, 2017 at 06:41:31PM +0200, activityworkshop wrote:

Package: python3-pyqt5.qtwebengine
Severity: important

Dear Maintainer,

According to packages.debian.org, this package is only built for amd64 and
i386 architectures.
To use it on the Raspberry Pi, one would need it to be built also for ARM.
The Qt5 packages on which this one depends, such as libqt5qui5,
libqt5webenginecore5, libqt5webenginewidgets5 etc, already appear to be
built.
Is this just an oversight, that the python bindings are missing?

As an aside, Raspbian already includes architecture-neutral packages which
depend on this python3-pyqt5.qtwebengine package, and these fail to install.

In fact I think this bug report should go to Raspbian, not to Debian.

>From the Raspbian build logs [1], it looks like qtwebengine is available
there only in buster, not in stretch (even though the version from Debian
stretch builds fine on armhf).

Also for some reason even when I added qtwebengine/armhf support to pyqt5 in
5.7+dfsg-6, the Raspbian developers reverted that change in 5.7+dfsg-6+rpi1
upload (and it is still reverted in 5.9+dfsg-2+rpi1 [2]):

   * Disable webengine for armhf, we do not currently have (and may never have)
 it in Raspbian.

  -- Peter Michael Green   Sat, 09 Sep 2017 01:01:09 
+

I do not know the reasoning for that change, so adding Peter to CC in hope
he can explain it.

Hi.

qtwebengine built sucessfully but failed to pass the armv7 contamination check, 
so was not uploaded. The combination of hellishly long build times, massively 
complicated build systems (chromiums build system embedded in qt) which i'm 
unfamiliar with and the fact that I have little idea how to properly test 
qtwebengine put further detailed investigation of this beyond what I can 
reasonablly do.

If someone can fix it so it doesn't show armv7 contamination and/or they can 
show that any (remaining) armv7 contamination is a false positive (i.e. it is 
gaurded behind runtime checks) then we can work to get a qtwebengine package in 
Raspbian.

The raspberry pi foundation have a chromium package but again I don't have the 
expertise to turn it into something suitable for Raspbian proper (i.e. no 
dependencies on raspberry pi foundation libraries. I also don't know how 
similar the plain chromium source is to the embedded chromium in qtwebengine.

Bug#884152: lintian: report about mismatches between the Build-IDs field and the content of /usr/lib/debug/

[Paul Wise]

Control: clone -1 -2
Control: severity -1 normal
Control: reopen -2
Control: reassign -2 lintian
Control: retitle -2 lintian: report about mismatches between the Build-IDs 
field and the content of /usr/lib/debug/

On Tue, 12 Dec 2017 17:44:43 +0800 Paul Wise wrote:
> On Tue, 12 Dec 2017 06:46:00 + Niels Thykier wrote:
> 
> > I am moving this to debhelper.  A maintainer does not and cannot
> > influence this. The bug has to be fixed in debhelper and a lintian tag
> > would simply serve to annoy people about a bug they cannot fix.
> 
> I still think this needs to be checked in lintian for several reasons:
> 
> To quantify the problem. I found a few manually when running
> find-dbgsym-packages but I'm definitely not going to check everything.
> 
> To discover which packages need rebuilding after the debhelper bug is
> fixed and to encourage maintainers to do uploads to fix the issue,
> since the release team doesn't seem to like to do binNMUs for
> debhelper bugs related to debug symbols (see #882051).
> 
> To catch any packages not doing standard things; creating Build-Ids
> outside of debhelper and doing it wrong or doing things in overrides
> that break the list of Buildd-Ids etc.
> 
> To catch any future debhelper bugs that might cause this issue.

For these reasons, and now that the debhelper bug is fixed, I am
requesting that lintian check for this issue. Please mention that the
solution usually is to rebuild with the fixed debhelper. Please also
encourage dropping the -dbg in favour of automatic -dbgsym packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#884566: ITP: node-autolinker -- Utility for automatically linking URLs, emails, etc. in text

[Daniel Ring]

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

* Package name: node-autolinker
  Version : 1.6.0
  Upstream Author : Gregory Jacobs 
* URL : https://github.com/gregjacobs/Autolinker.js
* License : Expat
  Programming Lang: JavaScript
  Description : Utility for automatically linking URLs, emails, etc. in text

 Autolinker is a utility for automatically adding hyperlinks to URLs, email
 addresses, phone numbers, Twitter handles, and hashtags in a given block of
 text or HTML.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#884152: lintian: report about mismatches between the Build-IDs field and the content of /usr/lib/debug/

[Paul Wise]

On Tue, 12 Dec 2017 13:39:14 + Chris Lamb wrote:

> What actually is the cause of the bug out of interest?

There is an explanation in the commit fixing this:

https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=6dfb3f5321d9ca32e1e1ce6bb8f2af6ed69560f0

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#884565: ITP: visidata -- terminal utility for exploring and arranging tabular data

[Anja]

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

Hello,

I would like to submit a packaged VisiData [1] for inclusion in
the Debian repository. It is licensed under GPL3 and has an existing manpage.


Currently, its available through pypi [2], but I feel that it would be
a valuable addition to Debian's terminal toolkit. It is a vim-like spreadsheet
 application for surveying and analysing tabular data [3] from the terminal.


Data can also be piped in and I primarily use it for processing the output from
curls, telnets and grep at work.

There are some demos available at visidata.org/test.


[1] http://visidata.org/

[2] https://pypi.python.org/pypi/visidata

[3] tsv, csv, fixed width, json, sqlite, etc


Thank you for your time,

-- 
Anja

Bug#884549: transition: libepubgen

[Rene Engelhard]

Hi,

On Sun, Dec 17, 2017 at 12:49:07AM +0100, Emilio Pozuelo Monfort wrote:
> Please go ahead.

OK, uploaded.

(A writerperfect_0.9.6-1+b1_amd64.changes also uploaded, so we don't
even need a bin-NMU when that goes out of NEW)

Regards,

Rene

Bug#881536: ffmpeg: Breaks sound in kodi

[Stefan Hachmann]

On Sat, 18 Nov 2017 16:18:10 + James Cowgill  wrote:

> Thanks. Reassigning the bug to kodi.
> 
> I think fixing the audio is easier than fixing the video (which only
> works due to a workaround patch in ffmpeg). Maybe removing this decode
> call is all that is needed?
> https://anonscm.debian.org/git/pkg-multimedia/kodi.git/tree/xbmc/cores/VideoPlayer/VideoPlayerAudio.cpp#n489

Yes, works fine after removal of decode call (with 17.6 from debian git[1]).
Thanks. :-)

[1] To compile it, directory 'kodi-17.6+dfsg1/addons/' have to be
completed with missing library.* directories ...

Best regards,
Stefan


Patch:
--- a/xbmc/cores/VideoPlayer/VideoPlayerAudio.cpp
+++ b/xbmc/cores/VideoPlayer/VideoPlayerAudio.cpp
@@ -486,7 +486,7 @@
 // guess next pts
 m_audioClock += audioframe.duration;

-int ret = m_pAudioCodec->Decode(nullptr, 0, DVD_NOPTS_VALUE, 
DVD_NOPTS_VALUE);
+int ret = 0;
 if (ret < 0)
 {
   CLog::Log(LOGERROR, "CVideoPlayerAudio::DecodeFrame - Decode Error. 
Skipping audio packet (%d)", ret);

Bug#875684: Bug#870669: libidn: Make source package bootstrappable

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2017-11-19 23:49 Manuel A. Fernandez Montecelo:

2017-11-04 23:09 Manuel A. Fernandez Montecelo:

2017-09-13 14:19 Helmut Grohne:


Though I'd much rather see libidn go. Most rdeps but hesiod have moved
on to libidn2-0.


Are you sure about this, Helmut?  There are lots of packages that
build-depend on libidn11-dev (like 55), very few on libidn2-dev and
libidn2-0-dev (there was a rename), like 10 in total.

So unless "build-rdeps --old" is not accurate, I think that most deps
have not migrated yet.

It looks like this package will continue with us for many months,
possibly years and at least one stable release, so the more important to
get this sorted out for a package which is part of the initial
debootstrap set.



Since it's unlikely to happen very soon (from a comment by upstream in
this report), I think that it shouldn't stop this being applied.


I am preparing a NMU for this fix.

To the maintainers: if you don't want it applied please speak soon, so I
don't waste time on a fix that will be reverted :)


Since there has been no reply from the maintainers to neither of #870669
nor #875684 since reported (4.5 and 3+ months respectively), and almost
a month since my last e-mail announcing my intention to NMU, I think
that I am going to upload straight away rather than upload to delayed.

I wouldn't normally be in a hurry when uploading such a thing, but I
have more time to attend to any issue caused with the upload in the next
week than in the last days of the year.

.debdiff attached, but since the package is under collab-maint I am
going to push the changes there too.

I imported the changes of 1.33-2, which hadn't been added (or pushed) to
the repo in collab-maint.


Lastly, a note about my changes related to #875684 (using help2man when
cross-building).

I decided to disable it for cross-builds rather than building twice,
instead of the original one proposed, for the following reasons:

- Some builds in the last 2-3 years took 20 or 30 minutes in release
 architectures (armel, mips and mipsel), and in several ports arches
 took 30 mins to 1h, and in some extreme case 5h with m68k (built in
 qemu I think).  Normally one would cross-build with a fast machine,
 but if somebody does it with hardware not that powerful (e.g. a small
 arm board) or in emulated environments, it's a significant increase.
 (Even going from 5 to 10 minutes is significant, IMO).

- Unlike in other packages, the file is right there, and it's there for
 reasons like this, I imagine, otherwise it serves no purpose.

- Even if I know that it will make your (Helmut) checks with diffoscope
 complain about this file, at a more fundamental level, I don't think
 that going the extra mile to build a file which is a dump of --help in
 the command line makes any sense.

 This is done to satisfy the "requirement" in Debian to ship manpages,
 but I find it an odd practice (a static page saying "undocumentaed,
 try --help" would probably be better) and even harmful, because it
 creates problems for cross-building.

- And more importantly, the original patch for that bug made me scratch
 my head a bit and it complicates things, while I prefer to either make
 minimal or straightforward changes or, in the best cases, simplify the
 packaging, not making it more difficult to understand.

- If it's really really important to do it in that way, we can always
 change it later, it's not like this is a definitive change.


Cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru libidn-1.33/debian/changelog libidn-1.33/debian/changelog
--- libidn-1.33/debian/changelog2017-09-12 11:18:33.0 +0200
+++ libidn-1.33/debian/changelog2017-12-17 00:04:41.0 +0100
@@ -1,3 +1,15 @@
+libidn (1.33-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not use help2man when cross-building (Closes: #875684)
+  * Update list of active maintainers
+- Remove Anibal Monsalve Salazar
+
+  [ Helmut Grohne ]
+  * Move java dependencies to Build-Depends-Indep (Closes: #870669)
+
+ -- Manuel A. Fernandez Montecelo   Sun, 17 Dec 2017 00:04:41 
+0100
+
 libidn (1.33-2) unstable; urgency=high
 
   * CVE-2017-14062: Fix integer overflow in decode_digit (Closes: #873903)
diff -Nru libidn-1.33/debian/control libidn-1.33/debian/control
--- libidn-1.33/debian/control  2017-09-12 11:18:33.0 +0200
+++ libidn-1.33/debian/control  2017-12-16 23:00:02.0 +0100
@@ -2,9 +2,10 @@
 Section: libs
 Priority: optional
 Maintainer: Debian Libidn Team 
-Uploaders: Anibal Monsalve Salazar , Simon Josefsson 
, Ondřej Surý 
+Uploaders: Simon Josefsson , Ondřej Surý 

 Standards-Version: 3.9.8
-Build-Depends: debhelper (>= 9), gcj-jdk [!arm !hppa !hurd-i386 !mips64el], 
fastjar [!arm !hppa !hurd-i386 !mips64el], dh-autoreconf, autopoint (>= 

Bug#880936: nodejs: updated version available upstream

[Jérémy Lal]

2017-12-16 18:26 GMT+01:00 Félix Sipma :

> On 2017-12-14 17:45+0100, Jérémy Lal wrote:
> >>
> >> On 2017-12-13 14:55+0100, Félix Sipma wrote:
> >>> On 2017-12-02 13:21+0100, Sébastien Villemot wrote:
>  On Sat, Dec 02, 2017 at 01:08:55PM +0100, Félix Sipma wrote:
> > On 2017-11-05 21:27+0100, Jérémy Lal wrote:
> >> 2017-11-05 21:19 GMT+01:00 Félix Sipma :
> 
> >>> node version 8.9.0 LTS is available upstream. Could you consider
> >> packaging
> >>> it?
> 
> >> Sure, but nodejs 6.11.x first has to go in testing...
> >
> > Is there still something preventing 6.12.x from migrating to testing?
> 
>  Yes, it fails to build on mips and mipsel:
> 
>  https://buildd.debian.org/status/package.php?p=nodejs
> >>>
> >>> OK, thanks. More specifically, this test is failing:
> >>>
> >>> not ok 1219 parallel/test-zlib
> >>> ---
> >>> duration_ms: 154.551
> >>> severity: fail
> >>> stack: |-
> >>>   buffer.js:11
> >>>   super(arg1, arg2, arg3);
> >>>   ^
> >>>
> >>>   RangeError: Array buffer allocation failed
> >>>   at Buffer.Uint8Array (native)
> >>>   at FastBuffer (buffer.js:11:5)
> >>>   at createUnsafeBuffer (buffer.js:38:12)
> >>>   at allocate (buffer.js:181:12)
> >>>   at Function.Buffer.allocUnsafe (buffer.js:141:10)
> >>>   at Function.Buffer.concat (buffer.js:309:23)
> >>>   at InflateRaw.stream.Stream.stream.Stream.node.pipe.pipe.on.on.
> common.mustCall
> >> (/<>/test/parallel/test-zlib.js:153:29)
> >>>   at InflateRaw. (/<>/test/common/
> >> index.js:445:15)
> >>>   at emitNone (events.js:91:20)
> >>>   at InflateRaw.emit (events.js:185:7)
> >>> ...
> >>>
> >>> Could it be that the hosts ran out of RAM?
> >>
> > 2017-12-14 17:38 GMT+01:00 Félix Sipma :
> >
> >> It would be interesting to have 8.x in experimental to see if the build
> >> still
> >> fails. Who knows? We may be lucky :-).
> >>
> >> @Jérémy: could you consider uploading this?
> >
> > If everything goes well i'll upload it in a few hours.
> >
> > Jérémy
>
> Also note that 6.12.1 changelog mentions a lot of changes to tests...
>

That might be a start, yes. However we are seeing segfaults at runtime,
so even if tests are fixed these bugs won't go away.

Meanwhile i've been trying hard to compile nodejs 8,
with openssl 1.1.0 support backported from nodejs 9, and it works !
(it needs to build againt bundled libuv, cctest can't build, and few js
tests fail).

So i'm going to upload it to experimental really soon now (i'm doing last
minute
checks).

Jérémy

Bug#884404: Misleading output when try to upload not released packages

[Ben Finney]

On 17-Dec-2017, Alf Gaida wrote:
> If you call correct behaviour a design change you are right

You have not shown any of the existing behaviour to be incorrect; you
have acknowledged that it is correct. (That is unrelated to whether
different proposed behaviour might *also* be correct.)

Instead, what you have proposed is justified not by any incorrect
behaviour of the program, but a preference between alternative
designs. So this report is a request for enhancement, since we both
agree the existing behaviour is correct.

Thanks again for describing the details.

-- 
 \ “A good politician is quite as unthinkable as an honest |
  `\   burglar.” —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#884358: marked as done (gajim: broken dependencies, gajim no longer starts)

[Antonio Ospite]

On Sun, 17 Dec 2017 00:27:57 +0100
Antonio Ospite  wrote:

> Hi,
> 
> I had to fix the "logs.db" database to be able to have the history
> working with gajim 0.16.11 so I am pasting some info below in case
> someone else needs it.
>

When I wrote 0.16.11 I actually meant 0.16.11.git20171214-1 from Debian
experimental.

[...]
> See the attached script, you might have to slightly change it to make
> it work according to what previous version of gajim you were using
> before, I had 0.16.8-5 but I am not sure if the misspelled
> "additinal_data" column was there from some version from git I might
> have run at some point.
> 

The misspelled 'additinal_data' column was introduced here
https://dev.gajim.org/gajim/gajim/blob/gajim-1.0.0-alpha1/gajim/common/optparser.py#L866
when updating from a previous version.

However the code, and newly created tables, actually use
'additional_data'.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#884358: marked as done (gajim: broken dependencies, gajim no longer starts)

[Antonio Ospite]

Hi,

I had to fix the "logs.db" database to be able to have the history
working with gajim 0.16.11 so I am pasting some info below in case
someone else needs it.

The error I was getting was like:

  The database file (/home/ao2/.local/share/gajim/logs.db) cannot be
  read. Try to repair it (see
  https://dev.gajim.org/gajim/gajim/wikis/help/DatabaseBackup) or remove
  it (all history will be lost).

However the pointed wiki page only gave instructions about backing up
the database, not about repairing it. So, some SQL dance was necessary.

See the attached script, you might have to slightly change it to make
it work according to what previous version of gajim you were using
before, I had 0.16.8-5 but I am not sure if the misspelled
"additinal_data" column was there from some version from git I might
have run at some point.

Make sure you have run the instructions on the wiki to backup the
_original_ database, just to have a safety net:

  $ sqlite3 ~/.local/share/gajim/logs.db .dump > backup.sql
  $ mv ~/.local/share/gajim/logs.db ~/.local/share/gajim/logs.db.old

You might have to remove any new database created only
with the new version (rm -i ~/.local/share/gajim/logs.db).

Restore the backup and repair the database:

  $ sqlite3 ~/.local/share/gajim/logs.db < backup.sql
  $ sqlite3 ~/.local/share/gajim/logs.db < 
gajim_0.16.8_fix_logs_table_for_0.16.11.sql

Start gajim.

Keep in mind that you have to select a contact first to be able
to see the logs history.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


gajim_0.16.8_fix_logs_table_for_0.16.11.sql
Description: application/sql

Bug#884549: transition: libepubgen

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 16/12/17 16:43, Rene Engelhard wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> new upstream version. The EPUB3 support needed ABI bumps. It already cleared
> NEW.
> 
> There's (right now) only one reverse-depends in sid: writerperfect.
> The 0.9.5 in sid right now doesn't build against the new library but 0.9.6
> (NEW) does.
> 
> In the upcoming 6.0 LibreOffice will also use libepubgen for epub export,
> so in experimental libreoffice also is affected. From LibreOffice 6.0 rc1
> onwards it even expects the new version and doesn't build/passes the tests
> against the older.

Please go ahead.

Emilio

Bug#884404: Misleading output when try to upload not released packages

[Alf Gaida]

If you call correct behaviour a design change you are right, but thats
not my problem anymore, i have an eight year tradition running self
patched dput's.

Cheers Alf

Bug#884564: suitesparse: FTBFS on i386: out of memory

[Andreas Beckmann]

Source: suitesparse
Version: 1:5.1.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

suitesparse/experimental FTBFS on i386 (and any-i386, x32 and
some ports), but succeeds on all other 32-bit release architectures:

https://buildd.debian.org/status/fetch.php?pkg=suitesparse=i386=1%3A5.1.0-1=1512882884=0

cc1: out of memory allocating 65536 bytes after a total of 3464364032 bytes
CMakeFiles/graphblas.dir/build.make:65: recipe for target 
'CMakeFiles/graphblas.dir/Source/GB_AxB_builtin.c.o' failed



Andreas

Bug#775942: FTCBFS for multilib enabled architectures

[Manuel A. Fernandez Montecelo]

Thanks for fixing the issue!

-- 
Manuel A. Fernandez Montecelo 

Bug#882059: python-ibus package is missing in testing repository

[Van Goodwin]

Hello,

> This bug report was very difficult to understand for me initially ...
> When filing bug a report, please make sure to explain situation clearly.

I am sorry that you were not able to immediately understand the bug report,
however I feel that I did clearly and fully describe the situation.  I
stated the problem I was having, the steps I took to try to resolve the
problem, the reasoning behind the steps I took,  and the result of my
efforts to resolve the problem.  I used concise, meaningful sentences and
proper grammar.  I truly do not know what else I could have done to make my
description of the situation more understandable.  The comments that you
wrote throughout my written description indicate that you understood the
situation after reading the description.  Perhaps you mean that it was the
information automatically supplied at the beginning of the bug report by
the reportbug program that confused you.

> Also, are you using this package seriously or were you just trying to
> use this package for curiosity...

I did use this package seriously.  I have used it since I first started
using Debian.  It is necessary to be able to use the tegaki handwriting
recognizer as an input method.

> When you file a GRAVE bug with the not-exactly-correct facts, you are
> causing negative service to many people.  Please be careful.  I hope you
> understand this.  In short, there is no bug for ibus.  Wrong package to
> blame!  Unless you are very sure, don't use this level of bug.

Filing the bug report against python-ibus was my mistake, but it was an
honest one.  After reading your explanation of the cause of my problem, I
now realize that the bug should have been filed against ibus-tegaki since
it should no longer be depending on python-ibus.  Howerver, when I was
filing the bug report I did not know that all packages that had previously
depended on python-ibus were supposed to have been updated to remove that
dependency nor did I find anything stating that while investigating my
problem, so I thought that ibus-tegaki was fine and that the problem was
that python-ibus had been removed from the repository by mistake thus
making python-ibus unusable and the bug severity GRAVE.  As you have noted,
the severity is still GRAVE, but the fault lies with ibus-tegaki.

> For case like this, please don't label ibus bug as i10n.  This is
> neither translation error, not the encoding problem, nor localization
> specific font rendering problem.

I apologize for the incorrect use of the l10n tag; I tried to make the best
selection I could from the limited options offered to me by the reportbug
program and it seemed to be the most appropriate choice since my ability to
select an input method for a foreign language was impacted.  From your
feedback, I now suppose that it would have been better to select the option
for no tags.

> Hmmm... maybe no one is using this package... it should be removed from
> all stable/testing/unstable

Well, no one using any current version of Debian is using it now since it
is broken.  According to a post on Github, the tegaki project is no longer
being maintained so there will be no fix coming from them.  I expect that
this issue will not get fixed and ibus-tegaki will be removed from stable,
testing, and unstable.  It is a shame since it was the best Japanese
handwriting input method I have found for Linux.  The tegaki recognizer
still works, but without integration with ibus or scim working  and no way
to copy to the clipboard, it is useless for anything except for practicing
one's handwriting.

Thank you

Bug#869391: gnome-control-center: Add input source dialog crashes when "Show All input sources" is enabled

[Jason Crain]

On Sat, Jul 22, 2017 at 08:00:00PM -0400, Felipe Sateler wrote:
> I enabled all input sources in the tweak tool. Now I can't add input
> sources. g-c-c crashes with the following backtrace below.

I would like to fix this in stretch, but I don't have upload
capabilities.  If I get approval from a SRM, is a gnome team member
willing to upload it?  Debdiff for the proposed change is attached.
diff -Nru gnome-desktop3-3.22.2/debian/changelog 
gnome-desktop3-3.22.2/debian/changelog
--- gnome-desktop3-3.22.2/debian/changelog  2016-11-08 08:14:44.0 
-0600
+++ gnome-desktop3-3.22.2/debian/changelog  2017-12-15 18:44:50.0 
-0600
@@ -1,3 +1,12 @@
+gnome-desktop3 (3.22.2-1+deb9u1) stretch; urgency=medium
+
+  [ Jason Crain ]
+  * d/p/Fix-heap-use-after-free-with-duplicate-xkb-layouts.patch: Fixes crash
+in gnome-control-center when adding an input source with "Show All Input
+Sources" enabled. (Closes: #869391)
+
+ -- Jason Crain   Fri, 15 Dec 2017 18:44:50 -0600
+
 gnome-desktop3 (3.22.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
gnome-desktop3-3.22.2/debian/patches/Fix-heap-use-after-free-with-duplicate-xkb-layouts.patch
 
gnome-desktop3-3.22.2/debian/patches/Fix-heap-use-after-free-with-duplicate-xkb-layouts.patch
--- 
gnome-desktop3-3.22.2/debian/patches/Fix-heap-use-after-free-with-duplicate-xkb-layouts.patch
   1969-12-31 18:00:00.0 -0600
+++ 
gnome-desktop3-3.22.2/debian/patches/Fix-heap-use-after-free-with-duplicate-xkb-layouts.patch
   2017-12-15 18:44:50.0 -0600
@@ -0,0 +1,32 @@
+From: Jason Crain 
+Date: Mon, 24 Jul 2017 22:32:01 -0500
+Subject: Fix heap-use-after-free with duplicate xkb layouts
+
+Debian's gnome-control-center can crash when show-all-sources is
+enabled.  When parse_end_element in gnome-xkb-info.c encounters
+duplicate layouts, it will free the memory for the first layout while it
+is still in a hash table.
+
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=785320
+Bug-Debian: https://bugs.debian.org/869391
+Origin: upstream, 
https://git.gnome.org/browse/gnome-desktop/commit/?id=dda675941777a876c1e9b08f922de72d32e73273
+Last-Update: 2017-12-15
+---
+ libgnome-desktop/gnome-xkb-info.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+--- a/libgnome-desktop/gnome-xkb-info.c
 b/libgnome-desktop/gnome-xkb-info.c
+@@ -405,6 +405,12 @@
+ 
priv->current_parser_variant->xkb_name,
+ NULL);
+ 
++  if (g_hash_table_contains (priv->layouts_table, 
priv->current_parser_variant->id))
++{
++  g_clear_pointer (>current_parser_variant, free_layout);
++  return;
++}
++
+   g_hash_table_replace (priv->layouts_table,
+ priv->current_parser_variant->id,
+ priv->current_parser_variant);
diff -Nru gnome-desktop3-3.22.2/debian/patches/series 
gnome-desktop3-3.22.2/debian/patches/series
--- gnome-desktop3-3.22.2/debian/patches/series 2015-10-14 11:42:32.0 
-0500
+++ gnome-desktop3-3.22.2/debian/patches/series 2017-12-15 18:44:50.0 
-0600
@@ -0,0 +1 @@
+Fix-heap-use-after-free-with-duplicate-xkb-layouts.patch

Bug#850803: gajim: No persistent notifications in Plasma 5

[W. Martin Borgert]

Hi Francesco,

could you check, whether the problem is gone with Gajim
1.0.0~alpha1 from unstable?

Thanks in advance!

Bug#766331: gajim: 0.16 UI occasionally sort-of crashes

[W. Martin Borgert]

I had this problem in 0.16.x (x <= 8) sometimes, but not anymore in
0.16.11.git*/1.0.0~alpha1.

Bug#785562: Status update

[Dr. Tobias Quathamer]

Am 15.12.2017 um 16:51 schrieb Emilio Pozuelo Monfort:
> On 15/12/17 15:23, gregor herrmann wrote:
>> On Tue, 31 Oct 2017 11:52:19 +0100, Dr. Tobias Quathamer wrote:
>>
>>> I've just uploaded openshot-qt to Debian, it's sitting in the NEW queue.
>>> Once it's accepted, I plan to remove openshot from Debian, so that this
>>> bug can be resolved.
>>
>> openshot-qt is in unstable now.
>>
>> Are there any plans to help users with the transition from openshot
>> to openshot-qt, like the former depending on the latter before its
>> removal or a transitional dummy package or something?
>>
>> Currently users will detect openshot-qt just by chance ...
> 
> Why was this renamed to openshot-qt? Upstream is still called 'openshot', so 
> I'm
> not sure it makes sense to embed the toolkit in the package name...
> 
> Emilio
> 

Hi,

my plan was to convert openshot into an empty transitional package which
depends on openshot-qt.

The renaming has been done by the previous maintainer, who already did
much work but then orphaned the packaging. I have to admit that I did
not think too much about the new package name and I'm not sticking to
it. However, it made sense to me, because the new program is a complete
rewrite of the old codebase, so starting the Debian package from scratch
seemed sensible.

Do you think that it might be better to reuse the "old" package openshot
instead? Most (if not all) of the currently open bugs against openshot
would no longer apply and could be closed, but that's of course manageable.

I'm open for suggestions ... :-)

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#882695: preliminary debian packaging pull request upstream

[Jeffrey Cliff]

https://github.com/ethereum/eth-utils/pull/33 contains a first attempt at
making a building package for eth-utils. It comes from my github repository
at https://github.com/themusicgod1/eth-utils

Hope this helps,
Jeff Cliff

Bug#884558: proftpd-dfsg FTCBFS: fails stripping with the build architecture strip

[Hilmar Preuße]

On 16.12.2017 23:07, Hilmar Preuße wrote:

Hi Helmut,

> However we do call dh_gencontrol right before the dh_builddeb call. Do
> you have a fast explanation why we don't see debug packages?
> 
OK, found it. We have to call dh_strip before dh_gencontrol.

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

Bug#884563: networking-sfc: FTBFS: tests fail with AttributeError: 'module' object has no attribute 'NAME_MAX_LEN'

[Andreas Beckmann]

Source: networking-sfc
Version: 2.0.1~git20160926.27f311e-1
Severity: serious
Justification: fails to build from source

Hi,

networking-sfc FTBFS in a current sid+experimental environment while
running the tests:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/networking-sfc-2.0.1~git20160926.27f311e'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
ostestr
/usr/lib/python2.7/dist-packages/os_testr/ostestr.py:120: UserWarning: No 
.stestr.conf file found in the CWD. Please create one to to replace the 
.testr.conf. You can find a script to do this in the stestr git rep
ository.
  warnings.warn(msg)

=
Failures during discovery
=
--- import errors ---
Failed to import test module: 
networking_sfc.tests.unit.db.test_flowclassifier_db
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File "networking_sfc/tests/unit/db/test_flowclassifier_db.py", line 30, in 

from networking_sfc.db import flowclassifier_db as fdb
  File "networking_sfc/db/flowclassifier_db.py", line 34, in 
from networking_sfc.extensions import flowclassifier as fc_ext
  File "networking_sfc/extensions/flowclassifier.py", line 173, in 
'validate': {'type:string': attr.NAME_MAX_LEN},
AttributeError: 'module' object has no attribute 'NAME_MAX_LEN'
[...]

Full log attached.


Andreas


networking-sfc_2.0.1~git20160926.27f311e-1.log.gz
Description: application/gzip

Bug#884558: proftpd-dfsg FTCBFS: fails stripping with the build architecture strip

[Hilmar Preuße]

On 16.12.2017 20:59, Helmut Grohne wrote:

Dear Helmut,

> proftpd-dfsg fails to cross build from source, because make install
> tries to strip proftpd (via install -s) with the build architecture
> strip and fails doing so. Stripping is best performed by dh_strip to get
> useful -dbgsym packages. Thus the easy solution is to pass
> --disable-strip and just doing so makes the cross build succeed. Please
> consider applying the attached patch.
> 
Many thanks for your bug report!

I've applied now the patch in my local copy. I had the hope that we
would get now dbgsym packages, which is not the case. I see the
following messages in the build log:

dh_builddeb: Not building dbgsym package for proftpd-basic as it has no
control file
dh_builddeb: Please use dh_gencontrol to avoid this issue

However we do call dh_gencontrol right before the dh_builddeb call. Do
you have a fast explanation why we don't see debug packages?

Many thanks!

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



proftpd-dfsg_1.3.5e-1_amd64.7z
Description: application/7z-compressed

Bug#853424: gnash: ftbfs with GCC-7

[John Horigan]

It is unfortunate that the author of revision 63 chose to remove rgba8_pre,
rather than create linear and sRGB variants.

If you replace agg::rgba8_pre(r,g,b,a) with
agg::rgba8(r,g,b,a).premultiply() it should work for both the old and new
versions of libagg

-- john

On Sat, Dec 16, 2017 at 12:11 AM Juhani Numminen 
wrote:

> Control: retitle 853424 gnash: FTBFS with agg 1:2.4-r127+dfsg1-1
>
> Hi,
>
> This is the first warning in my build log (attached):
>
> make[4]: Entering directory
> '/build/gnash-0.8.11~git20160608/tmp.build/librender'
>   CXX  libgnashrender_la-Renderer_agg.lo
> In file included from ../../librender/agg/Renderer_agg.cpp:146:0:
> ../../librender/agg/Renderer_agg_style.h: In member function 'void
> gnash::AddStyles::operator()(const gnash::SolidFill&) const':
> ../../librender/agg/Renderer_agg_style.h:617:28: error: 'rgba8_pre' is not
> a member of 'agg'
>  _sh.add_color(agg::rgba8_pre(color.m_r, color.m_g, color.m_b,
> ^
> ../../librender/agg/Renderer_agg_style.h:617:28: note: suggested
> alternative: 'rgba_pre'
>  _sh.add_color(agg::rgba8_pre(color.m_r, color.m_g, color.m_b,
> ^
>
> It seems that rgba8_pre really was removed from the headers in the last
> upload of agg.
>
> https://sources.debian.org/src/agg/2.5+dfsg1-11/include/agg_color_rgba.h/#L436
>
> https://sources.debian.org/src/agg/1:2.4-r127+dfsg1-1/include/agg_color_rgba.h
>
> In the upstream repository, the removal was done in revision 63.
> https://sourceforge.net/p/agg/svn/63/?page=2#diff-17
>
> https://sourceforge.net/p/agg/svn/63/tree/agg-2.4/include/agg_color_rgba.h?diff=518286af2718467b8b34c637:62
>
>
> Best regards,
> Juhani
>

Bug#840147: gajim: another home-phoning bug (in proxy65_manager) (privacy violation)

[W. Martin Borgert]

In current versions of Gajim, the test is disabled by default.
(One can set the config variable test_ft_proxies_on_startup to
True, however, to enable the test.)

Bug#884048: gnome-shell: /usr/lib/gnome-shell/gnome-shell-calendar-server continually crashes with segfault

[Adrian Bunk]

Control: severity -1 serious

On Sat, Dec 16, 2017 at 09:19:18PM +0100, Michael Biebl wrote:
> Control: severity -1 important
> 
> > Dec 10 13:17:40 lavaine kernel: [ 3324.799650] gnome-shell-cal[2352]: 
> > segfault at 10812 ip 7f2eeafd0324 sp 7ffd0bc3d6d0 error 4 in 
> > libical.so.2.0.0[7f2eeaf8d000+5e000]
> To explain what's happening here:
> gnome-shell links directly against libical (here against v2) and also
> against libecal (from evolution-data-server).
> evolution-data-server was updated to link against libical v3. The result
> is, that gnome-shell was now loading libical2 (directly) and libical3
> (indirectly via libecal) into its address space. This is not supported
> and leads to the crash.
> 
> I decided to add a Conflicts: libical2 to libecal (see #884012) to avoid
> this situation.
> 
> So from my POV, this bug can be closed. Other DDs mentioned on
> #debian-devel though, that this conflicts should be added directly to
> libical3. I'm thus leaving this bug report open for further discussion
> but downgrade the severity, as the immediate issue (the segfault in
> gnome-shell) is addressed by #884012.

KDE has/had similar problems, setting back to RC to prevent testing 
migration until this is sorted out.

> Regards,
> 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#884562: linux-image-4.9.0-4-armmp-lp: Enable CONFIG_SND_SOC_SPDIF for cubietruck spdif

[Stefan Fritsch]

package: src:linux
version: 4.9.65-3
severity: important

This is a follow-up to #857410 . CONFIG_SND_SOC_SPDIF is also required to make 
spdif work on the cubietruck.

By accident I have not stopped using my self-compiled kernel and did not 
notice that spdif does not actually work with the debian kernel. Sorry.

Cheers,
Stefan

Bug#884561: stretch-pu: package pam-krb5-migrate/0.0.11-4

[Dominik George]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I would like to update pam-krb5-migrate in stretch to fix #873271.

Right now, the package is unusable because it installs files to the
wrong directories.

I took over maintenance of the package, which is why I also change the
maintainer in the new package (as to not wrongly mark it as an NMU).

Diff attached.

Cheers,
Nik

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlo1jcQxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pZW/RAA0yjmuxuBzOktQoyjNzKgUel0Tv4D
MEl7p7vscUJKwL9RJ/HkB95J38fSFJkwCtWBhg9dpDin6VCqZvg4B5XCjYyxYWd6
7kW7dPxf76GHoRj5qeoEjlFp5vP5k/NhuBI2by6t+z35lTtBDEtHaqzFTvoR2+jm
2GpkqdKk/u7slD1BNyOP9XG/gKfViC7DjO0QNIyNESWJ1t5liwFWvx35W1e/+izC
FWG/By4WbmFaZiDYcZIUKQyy5d57swziVQwAzKSf1ItwgJC+lFy5iLMUMVgMHBxd
fWePt/FF+MQmhNEV+WRr8PbCPNudQaZB3QW1PvHXzusvQprELxgqpLA1FuRT47J1
y4AvkJFYG3iXRDhhn7m5B9ZsKl2t4HWg87HNUw3daoew/yWNzeHA8baBCs77VOm5
E3+JcGxfeTqjtAuXH0rXuzTH4o5sZWWVs2st1jmJIEKvEbbWbqh1dwsarpXVnDkK
DXtHoj/E4HXGin9gJAH3dBiV6udbolTXzTGHzbsEtbpjmgGc0IjhIPRDWRamt3fX
p2EIGKW1yXWnAYhEk3PWPM1pgmijdVgr3aJOTIdQYV9K8RTA9e6r/nQBEKenk6xX
FDrYOQyW/VF7ew5VKmDGjZglJ3Fj93IO002l/xJSZDvqDJY+D+PvaQcJ1bvEgMi6
thO1UGJbKoniyX4=
=MSeb
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index f59576e..f1c26a0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pam-krb5-migrate (0.0.11-4+deb9u1) stretch; urgency=medium
+
+  * Fix install paths. (Closes: #873271)
+  * Make myself maintainer (instead of marking this an NMU,
+which it isn't).
+
+ -- Dominik George   Sat, 16 Dec 2017 21:51:59 +0100
+
 pam-krb5-migrate (0.0.11-4) unstable; urgency=medium
 
   * Drop support for Heimdal. Closes: #837695
diff --git a/debian/control b/debian/control
index 98ccc21..d10797d 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
 Source: pam-krb5-migrate
 Section: admin
 Priority: optional
-Maintainer: Jelmer Vernooij 
+Maintainer: Dominik George 
 Standards-Version: 3.9.8
 Build-Depends: comerr-dev,
debhelper (>= 5.0.70~),
diff --git a/debian/libpam-krb5-migrate-mit.install 
b/debian/libpam-krb5-migrate-mit.install
index 859fba5..77f7a0f 100644
--- a/debian/libpam-krb5-migrate-mit.install
+++ b/debian/libpam-krb5-migrate-mit.install
@@ -1,2 +1,2 @@
-mit/pam_krb5_migrate_mit.so /lib/security/pam_krb5_migrate_mit.so
-debian/libpam-krb5-migrate-mit.pam-config 
/usr/share/pam-configs/krb5-migrate-mit
+mit/pam_krb5_migrate_mit.so lib/security
+debian/libpam-krb5-migrate-mit.pam-config usr/share/pam-configs

Bug#884344: ejabberd: After updating to latest erlang packages, ejabberd refuses to start

[E Harris]

uI was already running loglevel 4, and changing it to 5 gave no additional 
info.  There was nothing in the error.log or crash.log either, in fact those 
files hadn't even been opened, as the timestamps were still of times 
pre-upgrade.


However, your hint to look for firewall issues was a good one.

Looks like this was a problem with ejabberdctl using ipv6 by default.  We 
don't use ipv6 here, so had no rules loaded for ipv6, and the default 
iptables policy was set to drop.  Since Debian configures ipv6 addresses 
automatically I guess it was trying to use ipv6 anyway and never fell 
back to using ipv4.


Apologies for the error.  But this failure mode should probably give 
something more useful that just a timeout with no useful messages.  Perhaps 
it should emit a message to say that ejabberdctl couldn't contact the 
daemon?


Thanks.

Bug#884560: apt-get will not take no for an answer

[Alexander Lyons Harkness]

Package: apt
Version: 1.5~rc4
Severity: important

Dear Maintainer,

When using apt-get to upgrade my system today, I reviewed the update summary
and decided to cancel the upgrade (so my graphics drivers would not be
uninstalled). (I had left apt waiting at the prompt for ~5 minutes - might that
have an effect?) However, apt-get continued with the upgrade after I entered 'n'
at the prompt. I attached the summarised terminal output (copied and pasted)
below. I was able to cancel the upgrade with Ctrl-C. I was not immediately
able to reproduce this bug, so I think this is likely an intermittent problem.

 $ sudo apt-get update; sudo apt-get dist-upgrade
 > Get:1 http://ftp.uk.debian.org/debian testing InRelease [142 kB]
 > [...]
 > Fetched 28.2 MB in 25s (1,119 kB/s)  
 >   
 > Reading package lists... Done
 > Reading package lists... Done
 > Building dependency tree   
 > Reading state information... Done
 > Calculating upgrade... Done
 > The following packages were automatically installed and are no longer 
 > required:
 > [...]
 > xserver-xorg-video-nvidia xserver-xorg-video-radeon xxd zenity-common
 > 862 upgraded, 75 newly installed, 45 to remove and 1 not upgraded.
 > Need to get 1,636 MB of archives.
 > After this operation, 642 MB of additional disk space will be used.
 > Do you want to continue? [Y/n] n
 > Get:1 http://ftp.uk.debian.org/debian testing/main amd64 libc-l10n all 
 > 2.25-3 [844 kB]
 > Get:2 http://ftp.uk.debian.org/debian testing/main amd64 locales all 2.25-3 
 > [3,288 kB]
 > Get:3 http://ftp.uk.debian.org/debian testing/main amd64 libc6 amd64 2.25-3 
 > [2,721 kB]
 > Get:4 http://ftp.uk.debian.org/debian testing/main i386 libc6 i386 2.25-3 
 > [2,501 kB]

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.12\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.11\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.12\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && 

Bug#787332: doublecmd-gtk: Inconsistent behavior - unselect files

[Graham Inggs]

Hi Svein

I think this problem may be fixed now in doublecmd 0.8.0.
Would you please confirm?

Regards
Graham

Bug#884559: lintian: Run png's through zopflipng

[Ville Skyttä]

Package: lintian
Version: 2.5.55
Severity: minor

Dear Maintainer,

Running *.png through zopflipng would save a bit in file sizes, see
attached patch.

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

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

Versions of packages lintian depends on:
ii  binutils  2.29.1-4ubuntu1
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1build1
ii  dpkg  1.18.24ubuntu1
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4ubuntu1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2build2
ii  libdpkg-perl  1.18.24ubuntu1
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1build3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-8ubuntu1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2build1
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-8ubuntu1
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1build3

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24ubuntu1
ii  libhtml-parser-perl3.72-3build1
ii  libtext-template-perl  1.46-1

-- no debconf information
>From 5f53621e44b774fdba02b9edf585859f5fef21c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Skytt=C3=A4?= 
Date: Sat, 16 Dec 2017 22:55:25 +0200
Subject: [PATCH] Run reporting/images/*.png through zopflipng -m

---
 reporting/images/ico.png| Bin 355 -> 230 bytes
 reporting/images/l.png  | Bin 1588 -> 669 bytes
 reporting/images/logo-small.png | Bin 3828 -> 2830 bytes
 3 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/reporting/images/ico.png b/reporting/images/ico.png
index 
cd7355d7526b1ff1222b69fade9fd3d202230271..e78bd5bf286a83614134b6decf5681d49428eb77
 100644
GIT binary patch
delta 202
zcmV;*05$*P0_FjbB!8_*L_t(|0b`

Bug#867558: flask-ldapconn FTBFS: build dependencies python-ldap3/python3-ldap3 are only available in more recent versions

[Dominik George]

Control: tags -1 + upstream

>  builddeps:flask-ldapconn : Depends: python-ldap3 (< 2.0~) but it is not 
> going to be installed
> Depends: python3-ldap3 (< 2.0~) but it is not 
> going to be installed

ldap3 version 2 requires a complete rewrite. Upstream tracks this at
https://github.com/rroemhild/flask-ldapconn/20

-nik


signature.asc
Description: PGP signature

Bug#828451: Upstream are aware but stuck

[Sebastian Andrzej Siewior]

On 2017-12-16 12:55:35 [+], deb...@fau.xxx wrote:
> Upstream are aware of this issue, but quite stuck on it, by the look of
> it:
> 
>  * https://github.com/netty/netty-tcnative/issues/263
>  * https://github.com/netty/netty/issues/6320
> 
> This is going to be a problem, as netty-tcnative can't be removed from
> testing, as it chains to fop, which half the world build-deps on for docs.

My understanding is that the only open issue is the renegotiation that is no
longer supported/ possible. If that is that the case then I suggest to drop
that and be done with it. Renegotiation initiated by the client is something
one does not want (since it may cause high load on the server). Also I don't
know anything *good* it will bring.

Sebastian

Bug#870001: openvswitch-switch: switch takes a very long time to start or fails without upstream's SYSTEMCTL_SKIP_REDIRECT=yes

[Michael Biebl]

On Fri, 28 Jul 2017 18:51:18 +0200 John Keates  wrote:
> Package: openvswitch-switch
> Version: 2.6.2~pre+git20161223-3
> Severity: important
> 
> Dear Maintainer,
> 
> I setup openvswitch-switch with a small number of switches that have one 
> physical interface each. Upon boot, they get configured extremely slow, 
> taking over half an hour to get basic networking up.
> 
> On IRC and the upstream repository, I found out that systemd now needs 
> SYSTEMCTL_SKIP_REDIRECT=yes on newer systems, on top of the existing 
> _SYSTEMCTL_SKIP_REDIRECT=yes. This is added in the upstream version, but not 
> in the current versions in Stretch, Buster or Sid.

SYSTEMCTL_SKIP_REDIRECT is an internal implementation detail of the
systemd lsb hook and should *never* be used in an init scripts directly.

You should get to the bottom this and find out why the SysV init script
is slow to start up instead of applying workarounds/hacks.

@Thomas: Please remove this hack from the init script



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



signature.asc
Description: OpenPGP digital signature

Bug#853122: linux-image-4.13.0-0.bpo.1-amd64: Also present at Gigabyte GA-AM1M-S2H

[Rainer Dorsch]

Package: src:linux
Version: 4.13.13-1~bpo9+1
Followup-For: Bug #853122

Dear Maintainer,

for reference: this issue is still present in 4.13.13 (which is expected, since 
upstream did not yet handle Zoltan's patches) and applies to my Gigabyte 
GA-AM1M-S2H mainboard.

Regards
Rainer

-- Package-specific info:
** Version:
Linux version 4.13.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.13.13-1~bpo9+1 
(2017-11-22)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.13.0-0.bpo.1-amd64 
root=UUID=bd19343e-2b8e-4052-989c-2627246c915f ro quiet

** Not tainted

** Kernel log:
[4.022597] [drm] RAM width 128bits DDR
[4.032093] [TTM] Zone  kernel: Available graphics memory: 1736752 kiB
[4.032096] [TTM] Initializing pool allocator
[4.032103] [TTM] Initializing DMA pool allocator
[4.032147] [drm] radeon: 512M of VRAM memory ready
[4.032149] [drm] radeon: 2048M of GTT memory ready.
[4.032170] [drm] Loading kabini Microcode
[4.032988] radeon :00:01.0: firmware: direct-loading firmware 
radeon/kabini_pfp.bin
[4.033347] radeon :00:01.0: firmware: direct-loading firmware 
radeon/kabini_me.bin
[4.033550] radeon :00:01.0: firmware: direct-loading firmware 
radeon/kabini_ce.bin
[4.033828] radeon :00:01.0: firmware: direct-loading firmware 
radeon/kabini_mec.bin
[4.034051] radeon :00:01.0: firmware: direct-loading firmware 
radeon/kabini_rlc.bin
[4.034370] radeon :00:01.0: firmware: direct-loading firmware 
radeon/kabini_sdma.bin
[4.034379] [drm] Internal thermal controller without fan control
[4.035646] [drm] radeon: dpm initialized
[4.036687] radeon :00:01.0: firmware: direct-loading firmware 
radeon/bonaire_uvd.bin
[4.036699] [drm] Found UVD firmware Version: 1.64 Family ID: 9
[4.037329] radeon :00:01.0: firmware: direct-loading firmware 
radeon/BONAIRE_vce.bin
[4.039173] [drm] Found VCE firmware/feedback version 40.2.2 / 15!
[4.039214] [drm] GART: num cpu pages 524288, num gpu pages 524288
[4.069861] [drm] PCIE GART of 2048M enabled (table at 0x0030E000).
[4.070084] radeon :00:01.0: WB enabled
[4.070104] radeon :00:01.0: fence driver on ring 0 use gpu addr 
0x2c00 and cpu addr 0xa084b742bc00
[4.070107] radeon :00:01.0: fence driver on ring 1 use gpu addr 
0x2c04 and cpu addr 0xa084b742bc04
[4.070109] radeon :00:01.0: fence driver on ring 2 use gpu addr 
0x2c08 and cpu addr 0xa084b742bc08
[4.070112] radeon :00:01.0: fence driver on ring 3 use gpu addr 
0x2c0c and cpu addr 0xa084b742bc0c
[4.070114] radeon :00:01.0: fence driver on ring 4 use gpu addr 
0x2c10 and cpu addr 0xa084b742bc10
[4.071045] radeon :00:01.0: fence driver on ring 5 use gpu addr 
0x00078d30 and cpu addr 0xaf3641c38d30
[4.071390] radeon :00:01.0: fence driver on ring 6 use gpu addr 
0x2c18 and cpu addr 0xa084b742bc18
[4.071393] radeon :00:01.0: fence driver on ring 7 use gpu addr 
0x2c1c and cpu addr 0xa084b742bc1c
[4.071396] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.071397] [drm] Driver supports precise vblank timestamp query.
[4.071457] radeon :00:01.0: radeon: using MSI.
[4.071495] [drm] radeon: irq initialized.
[4.078830] Adding 8378364k swap on /dev/sda5.  Priority:-1 extents:1 
across:8378364k SSFS
[4.090169] [drm] ring test on 0 succeeded in 2 usecs
[4.090284] [drm] ring test on 1 succeeded in 3 usecs
[4.090306] [drm] ring test on 2 succeeded in 3 usecs
[4.090523] [drm] ring test on 3 succeeded in 4 usecs
[4.090531] [drm] ring test on 4 succeeded in 4 usecs
[4.136627] [drm] ring test on 5 succeeded in 1 usecs
[4.157135] [drm] UVD initialized successfully.
[4.266822] [drm] ring test on 6 succeeded in 15 usecs
[4.266842] [drm] ring test on 7 succeeded in 3 usecs
[4.266843] [drm] VCE initialized successfully.
[4.269850] [drm] ib test on ring 0 succeeded in 0 usecs
[4.429744] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: 
(null)
[4.573427] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: 
(null)
[4.650006] random: crng init done
[4.678518] audit: type=1400 audit(1513451935.668:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=458 comm="apparmor_parser"
[4.683342] audit: type=1400 audit(1513451935.673:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=459 comm="apparmor_parser"
[4.683350] audit: type=1400 audit(1513451935.673:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=459 
comm="apparmor_parser"
[4.683355] audit: type=1400 audit(1513451935.673:5): apparmor="STATUS" 

Bug#884048: gnome-shell: /usr/lib/gnome-shell/gnome-shell-calendar-server continually crashes with segfault

[Michael Biebl]

Control: severity -1 important

> Dec 10 13:17:40 lavaine kernel: [ 3324.799650] gnome-shell-cal[2352]: 
> segfault at 10812 ip 7f2eeafd0324 sp 7ffd0bc3d6d0 error 4 in 
> libical.so.2.0.0[7f2eeaf8d000+5e000]
To explain what's happening here:
gnome-shell links directly against libical (here against v2) and also
against libecal (from evolution-data-server).
evolution-data-server was updated to link against libical v3. The result
is, that gnome-shell was now loading libical2 (directly) and libical3
(indirectly via libecal) into its address space. This is not supported
and leads to the crash.

I decided to add a Conflicts: libical2 to libecal (see #884012) to avoid
this situation.

So from my POV, this bug can be closed. Other DDs mentioned on
#debian-devel though, that this conflicts should be added directly to
libical3. I'm thus leaving this bug report open for further discussion
but downgrade the severity, as the immediate issue (the segfault in
gnome-shell) is addressed by #884012.

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



signature.asc
Description: OpenPGP digital signature

Bug#884558: proftpd-dfsg FTCBFS: fails stripping with the build architecture strip

[Helmut Grohne]

Source: proftpd-dfsg
Version: 1.3.5d-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

proftpd-dfsg fails to cross build from source, because make install
tries to strip proftpd (via install -s) with the build architecture
strip and fails doing so. Stripping is best performed by dh_strip to get
useful -dbgsym packages. Thus the easy solution is to pass
--disable-strip and just doing so makes the cross build succeed. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru proftpd-dfsg-1.3.5d/debian/changelog 
proftpd-dfsg-1.3.5d/debian/changelog
--- proftpd-dfsg-1.3.5d/debian/changelog2017-01-26 13:23:53.0 
+0100
+++ proftpd-dfsg-1.3.5d/debian/changelog2017-12-16 18:06:47.0 
+0100
@@ -1,3 +1,10 @@
+proftpd-dfsg (1.3.5d-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Configure with --disable-strip (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 16 Dec 2017 18:06:47 +0100
+
 proftpd-dfsg (1.3.5d-1) unstable; urgency=medium
 
   [ Hilmar Preuße ]
diff --minimal -Nru proftpd-dfsg-1.3.5d/debian/rules 
proftpd-dfsg-1.3.5d/debian/rules
--- proftpd-dfsg-1.3.5d/debian/rules2017-01-26 13:23:53.0 +0100
+++ proftpd-dfsg-1.3.5d/debian/rules2017-12-16 18:06:45.0 +0100
@@ -40,7 +40,7 @@
 --with-includes=$(shell pg_config --includedir):$(shell 
mysql_config --include|sed -e 's/-I//') \
 --mandir=/usr/share/man --sysconfdir=/etc/$(NAME) 
--localstatedir=/run --libexecdir=/usr/lib/$(NAME) \
 --enable-sendfile --enable-facl --enable-dso --enable-autoshadow 
--enable-ctrls --with-modules=mod_readme \
---enable-ipv6 --enable-nls --enable-memcache 
--with-lastlog=/var/log/lastlog --enable-pcre $(DEVELOPT)
+--enable-ipv6 --enable-nls --enable-memcache 
--with-lastlog=/var/log/lastlog --enable-pcre $(DEVELOPT) --disable-strip
 
 ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
   CONF_ARGS += --build $(DEB_HOST_GNU_TYPE)

Bug#704527: biber: Character "(" not allowed in key although valid in BiBTeX

[Hilmar Preuße]

On 15.12.2017 20:57, Norbert Preining wrote:

Hi Norbert,

> I faintly remember some discussion on one of the recent biber issues 
> on github and a new version coming out that fixes that.
> 
Hmm, I had a look at the repository and recently closed issues + open
issues, but did not find something.

The 2.10 beta at least still reports this as syntax error:

hille@amd64-sid:~$ biber 704527
INFO - This is Biber 2.10 (beta)
INFO - Logfile is '704527.blg'
INFO - Reading '704527.bcf'
INFO - Found 1 citekeys in bib section 0
INFO - Processing section 0
INFO - Looking for bibtex format file '704527.bib' for section 0
INFO - Reading ascii input as UTF-8
INFO - LaTeX decoding ...
INFO - Found BibTeX data source '704527.bib'
ERROR - BibTeX subsystem: /tmp/XiQzd7D7kf/704527.bib_11146.utf8, line 1,
syntax error: found ")", expected ","
INFO - ERRORS: 1

However I'm not sure if it is even the fault of biber. If you know more,
let us know. Thanks!

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#884557: diffoscope: please support Android ROM boot.img introspection

[Simon Josefsson]

Package: diffoscope
Version: 88
Severity: wishlist

Hello.  I'd like to see reproducible builds of Replicant (an Android
clone), and diffoscope support for Android boot.img files would be
useful.  See diffoscope --debug output below.

It can be done through , see
ideas here .  Use the -i
parameter to display info about the image, and -x to extract its
components.  I tested and the resulting initrd.img can be diffoscope'd
further already.

Cheers,
/Simon
2017-12-16 18:36:57 D: diffoscope.presenters.formats: Will generate the 
following formats: text
2017-12-16 18:36:57 D: diffoscope.main: Starting diffoscope 88
2017-12-16 18:36:57 D: diffoscope.locale: Normalising locale, timezone, etc.
2017-12-16 18:36:57 D: diffoscope.main: Starting comparison
2017-12-16 18:36:57 D: diffoscope.comparators: Loaded 62 comparator classes
2017-12-16 18:36:57 D: diffoscope.comparators.utils.specialize: Unidentified 
file. Magic says: Android bootimg, kernel (0x40008000), ramdisk (0x4100), 
page size: 2048, cmdline (console=ttySAC2,115200)
2017-12-16 18:36:57 D: diffoscope.comparators.utils.specialize: Unidentified 
file. Magic says: Android bootimg, kernel (0x40008000), ramdisk (0x4100), 
page size: 2048, cmdline (console=ttySAC2,115200)
2017-12-16 18:36:57 D: diffoscope.comparators.utils.compare: Comparing 
2/boot.img (FilesystemFile) and 3/boot.img (FilesystemFile)
2017-12-16 18:36:57 D: diffoscope.comparators.utils.file: 
File.has_same_content: < 
2/boot.img> < 3/boot.img>
2017-12-16 18:36:57 D: diffoscope.comparators.utils.specialize: Unidentified 
file. Magic says: Android bootimg, kernel (0x40008000), ramdisk (0x4100), 
page size: 2048, cmdline (console=ttySAC2,115200)
2017-12-16 18:36:57 D: diffoscope.comparators.utils.specialize: Unidentified 
file. Magic says: Android bootimg, kernel (0x40008000), ramdisk (0x4100), 
page size: 2048, cmdline (console=ttySAC2,115200)
2017-12-16 18:36:57 D: diffoscope.comparators.utils.command: Executing xxd 
2/boot.img
2017-12-16 18:36:57 D: diffoscope.comparators.utils.command: Executing xxd 
3/boot.img
2017-12-16 18:36:57 D: diffoscope.diff: Running diff -aU7 
/tmp/tmpx1bwiuyq_diffoscope/fifo1 /tmp/tmpx1bwiuyq_diffoscope/fifo2
2017-12-16 18:36:58 D: diffoscope.comparators.utils.command: xxd 2/boot.img 
returned (exit code: 0)
2017-12-16 18:36:59 D: diffoscope.comparators.utils.command: xxd 3/boot.img 
returned (exit code: 0)
2017-12-16 18:37:01 D: diffoscope.diff: diff -aU7 
/tmp/tmpx1bwiuyq_diffoscope/fifo1 /tmp/tmpx1bwiuyq_diffoscope/fifo2: returncode 
1, parsed True
2017-12-16 18:37:01 D: diffoscope.presenters.formats: Generating 'text' output 
at '-'
--- 2/boot.img
+++ 3/boot.img
@@ -1,9 +1,9 @@
-: 414e 4452 4f49 4421 4855 3300 0080 0040  ANDROID!HU3@
-0010: 9fde 0c00  0041    f040  ...A...@
+: 414e 4452 4f49 4421 e84e 3300 0080 0040  ANDROID!.N3@
+0010: f7df 0c00  0041    f040  ...A...@
 0020: 0001 0040 0008       ...@
 0030:          
 0040: 636f 6e73 6f6c 653d 7474 7953 4143 322c  console=ttySAC2,
 0050: 3131 3532 3030       115200..
 0060:          


signature.asc
Description: PGP signature

Bug#884556: debhelper: dh_missing - support wildcards in d/not-installed

[Niels Thykier]

Package: debhelper
Version: 10.10.9
Severity: wishlist
Control: submitter -1 m...@gnuservers.com.ar

"""
Please consider adding wildcard support for the debian/not-installed
files before making this the default. In the package pkg-kde-tools,
the /usr/share/pkg-kde-tools/qt-kde-team/3/list-missing.mk make script
implements a (rather primitive) support for wildcards in
debian/not-installed which might be used as a base for dh_missing.
"""

(https://lists.debian.org/debian-devel/2017/11/msg00172.html)

Bug#884555: Subject: RFS: diodon/1.7.0-1

[Oliver Sauder]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "diodon"

 * Package name: diodon
   Version : 1.6.0-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon/
 * License : GPLv2
   Section : utils

It builds those binary packages:

 diodon - GTK+ Clipboard manager
 diodon-dev - GTK+ Clipboard manager (development files)
 gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
 libdiodon0 - GTK+ Clipboard manager (main library)

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/diodon


Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.7.0-1.dsc

Changes since the last upload:

  * New upstream release.
  * Add initial Wayland support (LP: #1727042)
  * Workaround for hotkey not working on various DEs (LP: #1630375)
  * Support instante paste on XFCE4 Terminal (LP: #1707041)
  * Move from cdbs to dh calls
  * Bump Standard Version to 4.1.2
  * Use compat version 10

Regards,
 Oliver Sauder






signature.asc
Description: OpenPGP digital signature

Bug#884436: xdg-open: wrongly handled file/URL in LXQt

[Alf Gaida]

Control: severity -1 important

Justification: #884436 renders xdg-open nearly useless regarding open
files for LXQt - for Debian and all derivatives

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch (add patch tag)

[adrian15]

Control: tags -1 + patch

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

[adrian15]

I attach a patch that fixes this bug.

Now using:

--linux-flavours="amd64:amd64 686"

in a i386 system does install amd64 kernel from amd64 architecture in a
transparent manner.

Please tell me if there's something to be polished so that it's accepted
upstream.

This patch:

* It uses the current git head ( d33943ea7a71ba5d874eb20f47bb898da485c77d )

* Can also be found at:
** Repo: https://github.com/rescatux/live-build.git
** Branch: foreign-architecture-support-quicktest3


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From 2db746bc858683cee82130caef496376c5bf11f7 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Fri, 15 Dec 2017 17:22:57 +
Subject: [PATCH] Fixed foreign architecture package support to linux kernel
 flavours

This problem originated in Stretch where amd64 kernel is not part of i386 repo.
So it needs to be fetched from amd64 repo.

So first of all you need to enable amd64 foreign architecture in your i386 system
thanks to:

dpkg --add-architecture amd64
apt-get update
.

Once you have done this thanks to this commit
now you can set linux flavours ( --linux-flavours ) as:

"i386 amd64:amd64"

in a i386 system and it will install the amd64 kernel alongside the i386 system.
---
 functions/defaults.sh| 12 
 scripts/build/chroot_linux-image |  2 +-
 scripts/build/config |  4 
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/functions/defaults.sh b/functions/defaults.sh
index 78ca358d1..541cf8a7b 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -475,6 +475,18 @@ Set_defaults ()
 			;;
 	esac
 
+	if [ -z "${LB_PACKAGE_LINUX_FLAVOURS}" ]
+	then
+		LB_PACKAGE_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS}"
+		LB_LINUX_FLAVOURS=""
+		for FLAVOUR in ${LB_PACKAGE_LINUX_FLAVOURS}
+		do
+			PACKAGE_FILTERED_FLAVOUR="$(echo ${FLAVOUR} | awk -F':' '{print $1}')"
+			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS} ${PACKAGE_FILTERED_FLAVOUR}"
+		done
+	fi
+
+
 	# Set linux packages
 	LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES:-linux-image}"
 
diff --git a/scripts/build/chroot_linux-image b/scripts/build/chroot_linux-image
index a96c4e529..d06ad8261 100755
--- a/scripts/build/chroot_linux-image
+++ b/scripts/build/chroot_linux-image
@@ -48,7 +48,7 @@ Create_lockfile .lock
 #		;;
 #esac
 
-for FLAVOUR in ${LB_LINUX_FLAVOURS}
+for FLAVOUR in ${LB_PACKAGE_LINUX_FLAVOURS}
 do
 	for PACKAGE in ${LB_LINUX_PACKAGES}
 	do
diff --git a/scripts/build/config b/scripts/build/config
index c692a926f..850cbb9b5 100755
--- a/scripts/build/config
+++ b/scripts/build/config
@@ -1116,6 +1116,10 @@ LB_KEYRING_PACKAGES="${LB_KEYRING_PACKAGES}"
 # (Default: autodetected)
 LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS}"
 
+# \$LB_PACKAGE_LINUX_FLAVOURS: set kernel flavour package to use
+# (Default: autodetected)
+LB_PACKAGE_LINUX_FLAVOURS="${LB_PACKAGE_LINUX_FLAVOURS}"
+
 # \$LB_LINUX_PACKAGES: set kernel packages to use
 # (Default: autodetected)
 LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES}"

Bug#875505: doxygen: build-dependency ruby-compass obsolete and broken

[Aurelien Jarno]

control: severity -1 serious

On 2017-09-11 22:02, Jonas Smedegaard wrote:
> Source: doxygen
> Severity: normal
> Tags: serious
> 
> I made a mistake that cause FTBFS of doxygen, but would prefer to fix it
> in doxygen as that would be needed anyway at a later point:
> 
> ruby-compass is obsolete and will likely not be released with Buster.
> Its replacement is Sass - either the reference Ruby implementation or
> alternatives linked with libsass including sassc.

This build-dependency of doxygen is not installable anymore, therefore
it's not possible to build doxygen in unstable anymore. For this reason,
I am raising of this bug with the severity to serious.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#884554: [fonts-droid-fallback] Explain that Noto is the new Droid & fix legacy documents

[Marcel Partap]

Package: fonts-droid-fallback
Version: 1:6.0.1r16-1.1
Severity: normal

--- Please enter the report below this line. ---
>From the description of the fonts-droid-fallback package it is not clear why 
>fonts-droid has vanished from Debian (i.e. that Noto grew out of Droid and is 
>the same but better) and how to fix legacy documents (install Noto fonts & 
>change documents from Droid {Sans,Serif,Mono} => Noto {Sans,Serif,Mono})

Also, a fontconfig file could be shipped with
> 
>   Droid {...}
>   
>   Noto {...}
>   
> 


--- System information. ---
Architecture: 
Kernel:   Linux 4.14.0-2.3-liquorix-amd64

Debian Release: buster/sid
  510 unstableliquorix.net 
  510 unstableftp.de.debian.org
  510 unstabledl.winehq.org 
  510 unstabledeb-multimedia.org 
  510 testing ftp.de.debian.org 
  509 experimentalftp.de.debian.org 
  502 zesty   ppa.launchpad.net 
  502 yakkety ppa.launchpad.net 
  500 zesty   build.openmodelica.org 
  500 stable  ftp.de.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Package's Depends field is empty.

Recommends   (Version) | Installed
==-+-===
fonts-noto-mono| 20171026-2


Suggests(Version) | Installed
=-+-===
fonts-noto| 20171026-2

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

[adrian15]

Package: live-build
Version: 1:20171207
Severity: normal

Dear Maintainer,

   * Introduction

Jessie had linux-amd64 package in its own i386 section.
Stretch has linux-amd64 package not in i386 section but in amd64 section
only.
When using live-build with Jessie you could use in an i386 Jessie system
this option:
 --linux-flavours="amd64 586"
in order to the amd64 kernel to be installed alongside the 586 kernel in
the same live cd image.

   * What led up to the situation?

Trying to rewrite a live-build configuration from Jessie to Stretch:
 --linux-flavours="amd64 686"

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

I tried this option (using live-build in Stretch):
 --linux-flavours="amd64:amd64 686"

   * What was the outcome of this action?

It failed because linux-image-amd64:amd64-* path for kernel filenames
are not found.

   * What outcome did you expect instead?

I expected the linux-image-amd64:amd64 to be installed and the appropiated
foreign architecture (amd64) to be added in an i386 system.


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

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

Versions of packages live-build depends on:
ii  debootstrap  1.0.89

Versions of packages live-build recommends:
ii  apt-utils   1.4.8
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5+deb9u1

live-build suggests no packages.

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Pirate Praveen]

On ശനി 16 ഡിസംബര്‍ 2017 11:16 വൈകു, Ghislain Vaillant wrote:
> You are deliberately taking an extreme case to fulfill your narrative. I
> would not fit nodejs and chai in the same basket.

see below, ruby-webmock is comparable here.

>> I did not even get heads up with webmock transition in ruby team. It was
>> right away FTBFS and autoremoval from testing for packages failing to
>> build with webmock 3.
> 
> And?

I had to get the tests ported to ruby-webmock 3, not the person who
uploaded ruby-webmock 3.

3 of my packages got removed from testing.

>> I can try and help, but as maintainer of libjs-fetch, it is your
>> responsibility to fix issues of your package when dependencies change.
> 
> We are talking about a *test* dependencies which now makes the build
> fail after a major version bump. It makes sense to expect more
> information from the corresponding maintainer.

That is how ruby-webmock, ruby-rspec etc were handled.

> Should we expect every single maintainer affected by an FTBFS to go read
> the release notes of chai in order to figure what broke between version
> 3 and 4. I am very skeptical about this.

yes, at least that is how I had to do with many ruby test framework
transitions and I think that is only reasonable or we can't really
update any package that is depended on by large number of packages.

>> 1. chai itself is FTBFS with nodejs 6
> 
> That's unfortunate indeed.
> 
>> 2. we generally want to ship the latest versions
> 
> But not systematically.
> 
>> 3. Some packages are already starting to require newer versions of chai,
>> for example node-yargs (whose tests are disabled currently).
> 
> It makes sense to disable them if they specifically require chai >= 4.
> 

Right now I did that, but going forward, it makes to sense to
disable/port tests of packages that needs an older version. That is how
any transition is handled, chai is not anything special. I know it is
hard and I have to do the same for my other packages too, but that is
part of what it takes to maintain a package.

>> You could ask upstream to move to chai 4 and take their help. Or you
>> could also disable tests.
> 
> Disabling the tests would be a serious downgrade considering testing is
> currently working, unlike node-yargs. I am seriously uncomfortable with
> this proposal.

node-yargs tests are working with chai 4 and we are in a better to
position to support chai 4 than chai 3.5 for buster.

> I can ask upstream, though chai is officially pinned at version 2.x there.
> 

I do that regularly. I did that for ruby-webmock 3.



signature.asc
Description: OpenPGP digital signature

Bug#884116: linux-image-4.9.0-4-amd64: screen atrifacts then crash

[Jerome]

    Hi,

    I have a similar issue, for me it occurred when upgrading from 
kernel package 4.9.0-3 (stable) to 4.9.0-4. With the later I sometimes 
got display content corruptions, always very quickly got X 
freeze/lock-up. Once or twice I could change to a console and observed 
the "*ERROR* CPU pipe A FIFO underrun" message in the kernel log. Trying 
to stop/start the X session always got to a complete lock-up.


    Some other bugs are similar: #859639, #884001. The kernel version 
where people experienced the issue can change though.


    I tried using the Intel driver instead of modesetting, as it helped 
for some people, but it didn't help in my case.


    I tried a newer kernel, 4.13.0-0.bpo.1 from backports: it helped a 
bit. Where 4.9.0-4 froze very quickly, sometimes right at the SDDM login 
other times after less than a minute, 4.13 could last several hours and 
some suspend/resume cycles. But it also had the same issue eventually.


    I enabled the IOMMU (intel_iommu=on), and it caught something. 
There seem to be an access error before the freeze:


[14312.568400] DMAR: DRHD: handling fault status reg 3
[14312.568406] DMAR: [DMA Write] Request device [00:02.0] fault addr 
1197000 [fault reason 23] Unknown
[14319.871599] [drm] GPU HANG: ecode 8:0:0x85db, in Xorg [1265], 
reason: Hang on rcs0, action: reset

[14319.871639] drm/i915: Resetting chip after gpu hang
[14327.894140] drm/i915: Resetting chip after gpu hang
[14337.878141] drm/i915: Resetting chip after gpu hang
[14349.878136] drm/i915: Resetting chip after gpu hang
[14448.886146] drm/i915: Resetting chip after gpu hang

    So where I observed the "CPU pipe A FIFO underrun", now I don't see 
it anymore but it's replaced by this IOMMU error (DMAR), followed by the 
GPU HANG. When this happens, the X display freezes but I can get back to 
a console reliably, even if it typically takes several seconds. If I try 
to restart the X session however, I quickly get back into the same 
problems. When I can get to a console I see many IOMMU exceptions:


[14457.416489] DMAR: DRHD: handling fault status reg 3
[14457.416496] DMAR: [DMA Write] Request device [00:02.0] fault addr 
1e2 [fault reason 23] Unknown

[14457.416584] DMAR: DRHD: handling fault status reg 2
[14457.416591] DMAR: [DMA Write] Request device [00:02.0] fault addr 
1e2 [fault reason 23] Unknown

[14461.966545] dmar_fault: 544 callbacks suppressed
[14461.966549] DMAR: DRHD: handling fault status reg 3
[14461.966562] DMAR: [DMA Write] Request device [00:02.0] fault addr 
1e25000 [fault reason 23] Unknown

[14461.966751] DMAR: DRHD: handling fault status reg 2

    Even with the IOMMU enabled the system ends up freezing solid if I 
persist, requiring a power cycle. The only reliable way to recover from 
such an error is a power cycle anyway.


    All this on an up to date Debian Stretch 9.3, on a Thinkpad X1 with 
5th gen CPU (i5-5200U). I use SDDM with KDE5/Plasma.


    For now I'm back on kernel 4.9.0-3, which is the last usable for 
me. I doesn't mean the underlying issue is not there (bug report #859639 
has the issue starting with 4.9.0-1), maybe some little changes makes 
the issue probability changes widely depending on system and configurations?
    I'm not competent to investigate this further on my own, but if 
anyone as suggestions on tests to make to investigate this issue, let me 
know.


Thanks

Bug#884154: Forwarded upstream

[Ghislain Vaillant]

Control: forwarded -1 https://github.com/github/fetch/issues/594

Bug#879041: libglvnd0-nvidia

[Chris Manougian]

I searched libglvnd and this is what comes up:

libglvnd-core-dev [This is Installed]
libglvnd-dev [This is installed]
libglvnd0 [This is installed]
libglvnd0-nvidia [Not Installed]
libglvnd0:i386 [This is installed]

libglvnd0-nvidia is version  384.98-3, and it makes sense that it should be
installed.

If I try to install libglvnd0-nvidia, Synaptic want to uninstall half of my
OS.

Here's what it looks like when I try to install it in terminal:

root@asus:/home/chris# apt-get install libglvnd0-nvidia
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:
 libglvnd0-nvidia : Conflicts: libglvnd0:i386 but 1.0.0-1 is to be installed
E: Unable to correct problems, you have held broken packages.
root@asus:/home/chris#

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Ghislain Vaillant]

Le 16/12/17 à 17:31, Pirate Praveen a écrit :

On ശനി 16 ഡിസംബര്‍ 2017 10:44 വൈകു, Ghislain Vaillant wrote:

I don't know anything about chai. Besides, since you are its maintainer,
I would expect the investigation to be done by yourself rather than myself.


No, that is not how a transition is supposed to work. Do you expect
maintainer of nodejs package to fix all issues of all packages using
nodejs by themselves when updating nodejs versions?


You are deliberately taking an extreme case to fulfill your narrative. I 
would not fit nodejs and chai in the same basket.



I did not even get heads up with webmock transition in ruby team. It was
right away FTBFS and autoremoval from testing for packages failing to
build with webmock 3.


And?


I can try and help, but as maintainer of libjs-fetch, it is your
responsibility to fix issues of your package when dependencies change.


We are talking about a *test* dependencies which now makes the build 
fail after a major version bump. It makes sense to expect more 
information from the corresponding maintainer.


Should we expect every single maintainer affected by an FTBFS to go read 
the release notes of chai in order to figure what broke between version 
3 and 4. I am very skeptical about this.



I meant context about why the package now FTBFS. I understand this is a
transition and I don't think uploading to unstable is wise before FTBFS
issues such as this one are fixed. Is there an urgency in having chai
4.x in testing/unstable?


Indeed, that is why it is uploaded first to experimental and giving
heads up to packages affected by this transition. We can definitely wait
for a reasonable time before uploading to unstable.


Which is appreciated.


1. chai itself is FTBFS with nodejs 6


That's unfortunate indeed.


2. we generally want to ship the latest versions


But not systematically.


3. Some packages are already starting to require newer versions of chai,
for example node-yargs (whose tests are disabled currently).


It makes sense to disable them if they specifically require chai >= 4.


You could ask upstream to move to chai 4 and take their help. Or you
could also disable tests.


Disabling the tests would be a serious downgrade considering testing is 
currently working, unlike node-yargs. I am seriously uncomfortable with 
this proposal.


I can ask upstream, though chai is officially pinned at version 2.x there.

Bug#884525: closed by Andreas Tille <ti...@debian.org> (Bug#884525: fixed in mobyle 1.5.5+dfsg-4)

[tomás zerolo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Dec 16, 2017 at 04:24:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:mobyle package:

[...]

>  mobyle (1.5.5+dfsg-4) unstable; urgency=medium
>  .
>* Remove Google Analytics beacon.
>  Closes: #884525

I'm speechless: thanks a million for the quick fix!

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlo1UdMACgkQBcgs9XrR2kaJLQCfa8s+xgJUIS8UnTgHUHmpfS5O
6wUAniCV01WHniPCBS6Hz16RzcnyiUFU
=Y9xd
-END PGP SIGNATURE-

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Pirate Praveen]

On ശനി 16 ഡിസംബര്‍ 2017 10:44 വൈകു, Ghislain Vaillant wrote:
> I don't know anything about chai. Besides, since you are its maintainer,
> I would expect the investigation to be done by yourself rather than myself.

No, that is not how a transition is supposed to work. Do you expect
maintainer of nodejs package to fix all issues of all packages using
nodejs by themselves when updating nodejs versions?

I did not even get heads up with webmock transition in ruby team. It was
right away FTBFS and autoremoval from testing for packages failing to
build with webmock 3.

I can try and help, but as maintainer of libjs-fetch, it is your
responsibility to fix issues of your package when dependencies change.

> I meant context about why the package now FTBFS. I understand this is a
> transition and I don't think uploading to unstable is wise before FTBFS
> issues such as this one are fixed. Is there an urgency in having chai
> 4.x in testing/unstable?

Indeed, that is why it is uploaded first to experimental and giving
heads up to packages affected by this transition. We can definitely wait
for a reasonable time before uploading to unstable.

1. chai itself is FTBFS with nodejs 6
2. we generally want to ship the latest versions
3. Some packages are already starting to require newer versions of chai,
for example node-yargs (whose tests are disabled currently).

You could ask upstream to move to chai 4 and take their help. Or you
could also disable tests.



signature.asc
Description: OpenPGP digital signature

Bug#884552: debian-cd: Support KERNEL_PARAMS in arm64

[Vagrant Cascadian]

Package: debian-cd
Version: 3.1.20
Severity: normal
Tags: patch

Currently, debian-cd does not modify the grub.cfg to include
KERNEL_PARAMS on arm64.  On x86, it works because it derives the grub
entries from isolinux configuration files, which do support
KERNEL_PARAMS.

The following patch adds support for this for stretch and buster on
arm64.

diff --git a/tools/boot/buster/boot-arm64 b/tools/boot/buster/boot-arm64
index f7cbe42..d00b5f2 100755
--- a/tools/boot/buster/boot-arm64
+++ b/tools/boot/buster/boot-arm64
@@ -155,6 +155,9 @@ if [ -d boot$N/grub ] ; then
 # in case they're still there
 sed -i "s,\%install\%,$INSTALLDIR,g" $CDDIR/boot/grub/grub.cfg
 
+# Substitute custom KERNEL_PARAMS into grub.cfg
+sed -i "s,/vmlinuz ,/vmlinuz $KERNEL_PARAMS ,g" $CDDIR/boot/grub/grub.cfg
+
 else
 echo "  No EFI boot code for $ARCH on CD$N"
 fi
diff --git a/tools/boot/stretch/boot-arm64 b/tools/boot/stretch/boot-arm64
index f7cbe42..d00b5f2 100755
--- a/tools/boot/stretch/boot-arm64
+++ b/tools/boot/stretch/boot-arm64
@@ -155,6 +155,9 @@ if [ -d boot$N/grub ] ; then
 # in case they're still there
 sed -i "s,\%install\%,$INSTALLDIR,g" $CDDIR/boot/grub/grub.cfg
 
+# Substitute custom KERNEL_PARAMS into grub.cfg
+sed -i "s,/vmlinuz ,/vmlinuz $KERNEL_PARAMS ,g" $CDDIR/boot/grub/grub.cfg
+
 else
 echo "  No EFI boot code for $ARCH on CD$N"
 fi


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#880936: nodejs: updated version available upstream

[Félix Sipma]

On 2017-12-14 17:45+0100, Jérémy Lal wrote:
>>
>> On 2017-12-13 14:55+0100, Félix Sipma wrote:
>>> On 2017-12-02 13:21+0100, Sébastien Villemot wrote:
 On Sat, Dec 02, 2017 at 01:08:55PM +0100, Félix Sipma wrote:
> On 2017-11-05 21:27+0100, Jérémy Lal wrote:
>> 2017-11-05 21:19 GMT+01:00 Félix Sipma :

>>> node version 8.9.0 LTS is available upstream. Could you consider
>> packaging
>>> it?

>> Sure, but nodejs 6.11.x first has to go in testing...
>
> Is there still something preventing 6.12.x from migrating to testing?

 Yes, it fails to build on mips and mipsel:

 https://buildd.debian.org/status/package.php?p=nodejs
>>>
>>> OK, thanks. More specifically, this test is failing:
>>>
>>> not ok 1219 parallel/test-zlib
>>> ---
>>> duration_ms: 154.551
>>> severity: fail
>>> stack: |-
>>>   buffer.js:11
>>>   super(arg1, arg2, arg3);
>>>   ^
>>>
>>>   RangeError: Array buffer allocation failed
>>>   at Buffer.Uint8Array (native)
>>>   at FastBuffer (buffer.js:11:5)
>>>   at createUnsafeBuffer (buffer.js:38:12)
>>>   at allocate (buffer.js:181:12)
>>>   at Function.Buffer.allocUnsafe (buffer.js:141:10)
>>>   at Function.Buffer.concat (buffer.js:309:23)
>>>   at 
>>> InflateRaw.stream.Stream.stream.Stream.node.pipe.pipe.on.on.common.mustCall
>> (/<>/test/parallel/test-zlib.js:153:29)
>>>   at InflateRaw. (/<>/test/common/
>> index.js:445:15)
>>>   at emitNone (events.js:91:20)
>>>   at InflateRaw.emit (events.js:185:7)
>>> ...
>>>
>>> Could it be that the hosts ran out of RAM?
>>
> 2017-12-14 17:38 GMT+01:00 Félix Sipma :
> 
>> It would be interesting to have 8.x in experimental to see if the build
>> still
>> fails. Who knows? We may be lucky :-).
>>
>> @Jérémy: could you consider uploading this?
> 
> If everything goes well i'll upload it in a few hours.
> 
> Jérémy

Also note that 6.12.1 changelog mentions a lot of changes to tests...


signature.asc
Description: PGP signature

Bug#834290: Warn about libraries with excessive priority?

[Josh Triplett]

On Sat, Dec 16, 2017 at 09:51:48AM +, Chris Lamb wrote:
> Fixed in Git:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=588cbc9069b53c8be4ca6e66e010cfb507b095e6

Thanks for the fix; however, this doesn't look like it covers the cases I
originally reported. This covers packages matching /^lib.+-dev$/ in
section "libdevel"; I certainly agree that the tag also applies there.
However, I originally proposed also applying this to packages in section
"libs" matching /^lib/ and not /-bin$/ , and I reviewed every package
matching that test to make sure there were no false positives.

I've attached a patch implementing this.

- Josh Triplett
>From 48c06e8d04bf8ba5e4e7c96f0e6243faa1fe5d44 Mon Sep 17 00:00:00 2001
From: Josh Triplett 
Date: Sat, 16 Dec 2017 09:12:16 -0800
Subject: [PATCH] excessive-priority-for-library-package: Handle non-dev
 packages too

Exclude packages ending in -bin (for libc-bin and future-proofing) and
libc packages.

Expand the test accordingly.
---
 checks/fields.pm   |  6 +++--
 .../debian/debian/control.in   | 27 +-
 .../tags   |  1 +
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/checks/fields.pm b/checks/fields.pm
index f5cb67123..37c4a906d 100644
--- a/checks/fields.pm
+++ b/checks/fields.pm
@@ -593,8 +593,10 @@ sub run {
   unless $KNOWN_PRIOS->known($priority);
 
 tag 'excessive-priority-for-library-package', $priority
-  if $pkg =~ m/^lib.+-dev$/o
-  and $info->field('section', '') eq 'libdevel'
+  if $pkg =~ m/^lib/o
+  and $pkg !~ m/-bin$/o
+  and $pkg !~ m/^libc[0-9.]+$/o
+  and any { $_ eq $info->field('section', '') } qw(libdevel libs)
   and any { $_ eq $priority } qw(required important standard);
 }
 
diff --git a/t/tests/fields-excessive-priority-for-library-package/debian/debian/control.in b/t/tests/fields-excessive-priority-for-library-package/debian/debian/control.in
index 7cc798109..2bb8a6964 100644
--- a/t/tests/fields-excessive-priority-for-library-package/debian/debian/control.in
+++ b/t/tests/fields-excessive-priority-for-library-package/debian/debian/control.in
@@ -5,6 +5,16 @@ Standards-Version: {$standards_version}
 Build-Depends: {$build_depends}
 Rules-Requires-Root: no
 
+Package: lib{$source}42
+Architecture: {$architecture}
+Depends: $\{shlibs:Depends\}, $\{misc:Depends\}
+Priority: important
+Description: {$description} (lib)
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
+
 Package: lib{$source}-dev
 Architecture: {$architecture}
 Depends: $\{shlibs:Depends\}, $\{misc:Depends\}
@@ -15,6 +25,21 @@ Description: {$description} (dev)
  Lintian.  It is part of the Lintian test suite and may do very odd
  things.  It should not be installed like a regular package.  It may
  be an empty package.
+ .
+ (This is a dev package.)
+
+Package: lib{$source}-false-positive-bin
+Architecture: {$architecture}
+Depends: $\{shlibs:Depends\}, $\{misc:Depends\}
+Section: libdevel
+Priority: required
+Description: {$description} (false positive bin)
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
+ .
+ (This is a -bin false positive)
 
 Package: lib{$source}-false-positive-dev
 Architecture: {$architecture}
@@ -27,4 +52,4 @@ Description: {$description} (false positive)
  things.  It should not be installed like a regular package.  It may
  be an empty package.
  .
- (This is a false positive)
+ (This is a -dev false positive)
diff --git a/t/tests/fields-excessive-priority-for-library-package/tags b/t/tests/fields-excessive-priority-for-library-package/tags
index 22cee044d..1b388a49c 100644
--- a/t/tests/fields-excessive-priority-for-library-package/tags
+++ b/t/tests/fields-excessive-priority-for-library-package/tags
@@ -1 +1,2 @@
 W: libfields-excessive-priority-for-library-package-dev: excessive-priority-for-library-package standard
+W: libfields-excessive-priority-for-library-package42: excessive-priority-for-library-package important
-- 
2.15.1

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Ghislain Vaillant]

Le 16/12/17 à 17:07, Pirate Praveen a écrit :

On ശനി 16 ഡിസംബര്‍ 2017 08:41 വൈകു, Ghislain Vaillant wrote:

Why is this happening with chai 4.x and not 3.5?


That is what we need to find out. Possibly some deprecated methods are
removed from new version.


I don't know anything about chai. Besides, since you are its maintainer, 
I would expect the investigation to be done by yourself rather than myself.



Sorry, but I am gonna need more context to fix this.


We are trying to update chai from 3.5 to 4.x but noticed this package
fails with chai 4.x. Once we upload chai 4.x to unstable, it will cause
FTBFS (and severity will be changed to serious) and we wanted to give a
heads up before that. This is the normal procedure of a transition.


I meant context about why the package now FTBFS. I understand this is a 
transition and I don't think uploading to unstable is wise before FTBFS 
issues such as this one are fixed. Is there an urgency in having chai 
4.x in testing/unstable?

Bug#884526: jigdo-file: Does not report package rejections because checksum mismatch

[Thomas Schmitt]

Hi,

long live the netinst ISOs !

But my patch is not good. Much too many false positive messages.

At least i now know that the program execution really gets through that
code part. But obviously it does this not only with files which were
actually downloaded.

Also i learned that
  mfile->leafName()
does not show the package file name but rather paths like
  
debian-6.0.7-amd64-netinst.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/o/openssl/libssl0.9.8_0.9.8o-4squeeze14_amd64.deb

But i still do not understand how this program is supposed to work on the
large scale.


Have a nice day :)

Thomas

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Pirate Praveen]

On ശനി 16 ഡിസംബര്‍ 2017 08:41 വൈകു, Ghislain Vaillant wrote:
> Why is this happening with chai 4.x and not 3.5?

That is what we need to find out. Possibly some deprecated methods are
removed from new version.

> Sorry, but I am gonna need more context to fix this.

We are trying to update chai from 3.5 to 4.x but noticed this package
fails with chai 4.x. Once we upload chai 4.x to unstable, it will cause
FTBFS (and severity will be changed to serious) and we wanted to give a
heads up before that. This is the normal procedure of a transition.



signature.asc
Description: OpenPGP digital signature

Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console

[Simon McVittie]

On Sat, 16 Dec 2017 at 10:53:22 +, Holger Levsen wrote:
> On Sat, Dec 16, 2017 at 10:21:40AM +, Chris Lamb wrote:
> > [Adding Holger, the original submitter, to the CC - please see the last two 
> > messages for some more context]
> > Wow, thank you so much for the detailed explanation! 
> 
> indeed & thank you too for keeping me in the loop.
> 
> This is great news as I'd like to get rid of these issues in
> src:debian-edu-config for buster and it seems there's now enough
> documentation that we'll be able to do so.

Sending this specifically to you in case you missed it, since you weren't
in Cc at the time: for debian-edu-config, you don't need documentation
for how to replace /etc/dbus-1/system.d/hal-debian-edu.conf because I'm
fairly sure it already has no practical effect:

In this specific case: you should probably drop the file (preferably
into a bonfire), since HAL is very, very obsolete, and I very much
hope debian-edu no longer uses or ships it. The parts of HAL where
high-level APIs made sense were replaced by the DeviceKit services,
which were later renamed to or replaced by udisks, upower and possibly
others; lower-level device enumeration and change-notification were
superseded by using udev directly.

hal was most recently in Debian as part of wheezy (oldoldstable), so
the file triggering the lintian warning in debian-edu-config is useless
and can safely be removed, unless debian-edu has some lookaside package
repository with packages that are no longer in Debian (in which case I
would still recommend dropping hal as soon as possible, because it
hasn't been maintained for years).

If you want to configure access control for the services that replaced
hal, you'll need to write polkit policies (but if nobody has noticed a
problem with them, their defaults might well be fine for your use case).

smcv

Bug#884526: jigdo-file: Does not report package rejections because checksum mismatch

[Thomas Schmitt]

Hi,

if i shall place a bet, then i'd say the checksum mismatch in
  https://sources.debian.org/src/jigdo/0.7.3-5/src/mkimage.cc/#L508
is where the message should be issued:

  ...
  case JigdoDesc::MATCHED_FILE: {
/* If file present in cache, copy its data to image, if
   not, copy zeroes. if check==true, verify MD sum match.
   If successful, turn MatchedFile into WrittenFile. */
...
if (mfile == 0 || self->md5() != *(mfile->getMD5Sum(cache))) {
  // Write right amount of zeroes

Here it should say something. The file was found but the checksum does not
match. (Still riddling under which circumstances mfile would be 0.)

  memClear(buf, readAmount);
  while (*img && toWrite > 0) {
size_t n = (toWrite < readAmount ? toWrite : readAmount);
writeBytes(*img, buf, n);
reportBytesWritten(n, off, nextReport, totalBytes, reporter);
toWrite -= n;
  }
  if (result == 0) result = 1; // Soft failure
} else {
  /* Copy data from file to image, taking care not to
 write beyond toWrite. */
  int status = fileToImage(img, *mfile, *self, checkMD5,
  imageInfo.blockLength(), reporter, buf, readAmount, off,
  nextReport, totalBytes);
  toCopy.pop();
  if (result < status) result = status;
  if (status == 0) { // Mark file as written to image
  ...

Function fileToImage() does its own checksum verification, but i believe to
see in
  https://sources.debian.org/src/jigdo/0.7.3-5/src/mkimage.cc/#L407
that it would issue a message if this verification failed:

} else if (checkMD5
   && (md.finish() != matched.md5()
   || (rsyncLen > 0 && rs != matched.rsync( {
  err = subst(_("Error: `%1' does not match checksum in template data"),
  fileName);
}

So if the check in fileToImage() issues an error message, then a MD5
mismatch of the whole file should issue such a message, too.
That much is clear.
But i can only hope that this is the place where in my case the files
got rejected.

I hacked myself a jigdo-file with
===
--- src/mkimage.cc.orig 2017-12-16 16:24:10.297866522 +0100
+++ src/mkimage.cc  2017-12-16 16:55:49.369873692 +0100
@@ -507,6 +507,16 @@ namespace {
   (mfile != 0 ? mfile->leafName() : ""), toCopy.size());
 if (mfile == 0 || self->md5() != *(mfile->getMD5Sum(cache))) {
   // Write right amount of zeroes
+
+  // ts B71216 : Experimental (especially the mfile message)
+  if (mfile == 0) {
+reporter.error(_("mfile == 0 with matched file"));
+  } else {
+string err = subst(_("MD5 mismatch with matched file `%1'"),
+   mfile->leafName());
+reporter.error(err);
+  }
+
   memClear(buf, readAmount);
   while (*img && toWrite > 0) {
 size_t n = (toWrite < readAmount ? toWrite : readAmount);
===
and tried to provoke the messages.

But Philip Hands must have been faster with repairing the package files.
My unfinished DVD-2 simply got completed.
  OK: Checksums match, image is good!   

I will probably try to fake a mismatch later this weekend.
(Something like hardcoding a package name into my hack and throwing
 artificial mismatch during a full download. I should have made a copy
 of my incomplete DVD-2. Now each try will last 20 minutes and Telekom
 will begin to hate me.)


Have a nice day :)

Thomas

Bug#884551: libopentoken6 : Ada lexer not well reset avec a call to Set_Text_Feeder

[Lionel Draghi]

Package: libopentoken6-dev
Version: 6.0b-5+b2
File: libopentoken6
Severity: normal

Dear Maintainer,

while processing a bunch of Ada files, the OpenToken Ada Lexer is 
sometimes ignoring the call to Set_Input_Feeder, and continue to parse 
the previously opened Ada file.


I read this in OpenToken.Token.Enumerated.Analyzer :

    --  Reset Analyzer, to start finding tokens. This is appropriate
    --  when the Feeder text has been changed.

    procedure Reset (Analyzer : in out Instance);

It seems appropriate, but it's not done in the Ada lexer.

For the Java lexer, no problem, as the analyzer instantiation is exposed 
in the package spec, the user can add a call to Analyzer.Reset just 
before Analyzer.Set_Text_Feeder.


But, for the Ada lexer, as the analyzer instantiation is hidden in the 
body, and there no Reset procedure available in the spec, there is no 
solution on user side.


I suggest to patch Set_Input_Feeder in ada_lexer.adb to do the same thing :

    procedure Set_Input_Feeder (File : in Ada.Text_IO.File_Type) is
    begin
   Ada.Text_IO.Set_Input (File);
   Analyzer.Reset; --> added line
   Analyzer.Set_Text_Feeder (OpenToken.Text_Feeder.Text_IO.Create 
(Ada.Text_IO.Current_Input));

>    end Set_Input_Feeder;


thanks,

--
-- Lionel

PS : unable to send something with reportbug!



-- System Information:


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libopentoken6-dev depends on:
ii  gnat   6.1
ii  gnat-6 6.3.0-18
ii  libopentoken9  6.0b-5+b2

libopentoken6-dev recommends no packages.

libopentoken6-dev suggests no packages.

-- no debconf information

Bug#884530: [Pkg-utopia-maintainers] Bug#884530: udisks2: udisks 2.7.4-1 unable to start

[Michael Biebl]

Am 16.12.2017 um 16:58 schrieb jEsuSdA 8):

> I can't reproduce the exact error message cause I'm runing the 2.1.8-1
> version, but the 2.7.4-1 said:
> 
> Failed to activate service "org.freedesktop.UDisks2"
> usr/lib/udisks2/udisksd: symbol lookup error
> 
> I hope this can help. ;)

Not really. This is way to unspecific. Please install 2.7.4-1 again and
get us an exact error message.

Please also attach the output of
ldd /usr/lib/udisks2/udisksd

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



signature.asc
Description: OpenPGP digital signature

Bug#879958: python3-pyqt5.qtwebengine: package not available for Raspberry Pi

[Dmitry Shachnev]

Control: tags -1 moreinfo

Hi, and sorry for the delay!

On Fri, Oct 27, 2017 at 06:41:31PM +0200, activityworkshop wrote:
> Package: python3-pyqt5.qtwebengine
> Severity: important
>
> Dear Maintainer,
>
> According to packages.debian.org, this package is only built for amd64 and
> i386 architectures.
> To use it on the Raspberry Pi, one would need it to be built also for ARM.
> The Qt5 packages on which this one depends, such as libqt5qui5,
> libqt5webenginecore5, libqt5webenginewidgets5 etc, already appear to be
> built.
> Is this just an oversight, that the python bindings are missing?
>
> As an aside, Raspbian already includes architecture-neutral packages which
> depend on this python3-pyqt5.qtwebengine package, and these fail to install.

In fact I think this bug report should go to Raspbian, not to Debian.

From the Raspbian build logs [1], it looks like qtwebengine is available
there only in buster, not in stretch (even though the version from Debian
stretch builds fine on armhf).

Also for some reason even when I added qtwebengine/armhf support to pyqt5 in
5.7+dfsg-6, the Raspbian developers reverted that change in 5.7+dfsg-6+rpi1
upload (and it is still reverted in 5.9+dfsg-2+rpi1 [2]):

  * Disable webengine for armhf, we do not currently have (and may never have)
it in Raspbian.

 -- Peter Michael Green   Sat, 09 Sep 2017 01:01:09 +

I do not know the reasoning for that change, so adding Peter to CC in hope
he can explain it.

I can still do an upload for Debian stretch, but only if you confirm that it
will be useful for you. See #880080 for my discussion with the Release Team.

[1]: https://buildd.raspbian.org/status/logs.php?pkg=qtwebengine-opensource-src
[2]: 
http://archive.raspbian.org/raspbian/pool/main/p/pyqt5/pyqt5_5.9+dfsg-2+rpi1.debian.tar.xz

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#702858: Pending fixes for bugs in the pentaho-reporting-flow-engine package

[pkg-java-maintainers]

tag 702858 + pending
thanks

Some bugs in the pentaho-reporting-flow-engine package are closed in
revision a97eaa6b0dfb0c6e538478ed5e83c48735969c43 in branch 'master'
by Rene Engelhard

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/pentaho-reporting-flow-engine.git/commit/?id=a97eaa6

Commit message:

fix jfreereport symlink (closes: #702858)

Bug#884530: [Pkg-utopia-maintainers] Bug#884530: udisks2: udisks 2.7.4-1 unable to start

[jEsuSdA 8)]

El 16/12/17 a las 14:15, Michael Biebl escribió:

Control: notfound -1 2.1.8-1
Control: found -1 2.7.4-1
Control: tags -1 moreinfo

Am 16.12.2017 um 12:08 schrieb jEsuSdA:

Package: udisks2
Version: 2.1.8-1
Severity: important

Dear Maintainer,

I updated the usdisk2 to 2.7.4-1 version and a lot of problems appears.

One of the annoying one was they appear a lot of devices icon on every gtk
application: Nautilus, Thunar, XFdesktop, GTK Open/Save Dialogs, etc.

More info here:
https://mail.xfce.org/pipermail/xfce/2017-December/035877.html

I found the problem was caused by udisk2 that was unable to start.


What's the output of
systemctl status udisks2



I can't reproduce the exact error message cause I'm runing the 2.1.8-1 
version, but the 2.7.4-1 said:


Failed to activate service "org.freedesktop.UDisks2"
usr/lib/udisks2/udisksd: symbol lookup error

I hope this can help. ;)

Bug#871228: Add FAQ: do the oldmail files just grow and grow?

[Osamu Aoki]

control: tags -1 wontfix

On Tue, Aug 08, 2017 at 12:10:07PM -0600, Charles Cazabon wrote:
> 積丹尼 Dan Jacobson  wrote:
> > 
> > OK, now all you need to do is add to the FAQ:

Sigh ...

> > Q: Do the oldmail files just grow and grow?
> 
> Not only is that not a Frequently Asked Question, it is a Never Asked
> Question.

Well said.  Thanks, Charles.

> When I get users asking me this, I'll worry about it.

Excuse me not convincing Dan to stop.  He goes hyperbolic on some bug
reports.

Dan,

I think you mean well but your bug reports like this waste many people's
time.  Please think about it. I am marking this as a "wontfix" bug.

I am not closing this as a reminder to you.

Regards,

Osamu

Bug#884550: regression(?) in greeter-hide-users=true behavior

[Benjamin Kaduk]

Package: lightdm-gtk-greeter
Version: 2.0.3-1

After my latest upgrade/reboot, the behavior of lightdm has changed.
Previously, on fresh boot and lock screen I would be
presented with a username/password entry dialog with empty username,
empty password, and focus on username.  The new behavior has
username pre-populated and focus on password.  (Is this more likely
to be lightdm-gtk-greeter or lightdm itself?)

My understanding is that greeter-hide-users=true is intended to not
give any indication of the valid users on the machine, whether
currently/previously logged in or not.  (If I am in error here,
please accept my apologies and close the report.)  I think I am
using an unmodified stock debian config,

root@prolepsis:~# lightdm --show-config
   [Seat:*]
   A  greeter-session=lightdm-greeter
   A  greeter-hide-users=true
   A  session-wrapper=/etc/X11/Xsession

   Sources:
   A  /usr/share/lightdm/lightdm.conf.d/01_debian.conf
   B  /etc/lightdm/lightdm.conf


My latest upgrade went from 2.0.2-1 to 2.0.3-1, but the previous
upgrade cycle did not involve a reboot, if that would have been
necessary to get the 2.0.2-1 version running.

Thanks,

Ben

Bug#884548: seqan2: FTBFS: several tests fail

[Andreas Beckmann]

Source: seqan2
Version: 2.3.2.000platform-issues8-6f85721+dfsg-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

seqan2 FTBFS on most platforms with failing unittests:

https://buildd.debian.org/status/package.php?p=seqan2=experimental

on amd64:

The following tests FAILED:
257 - test_demo_tutorial_journaled_set_solution_online_search_finder 
(Failed)
382 - app_test_razers (Failed)
383 - app_test_razers3 (Failed)
384 - app_test_razers3_sequential (Failed)


Andreas

Bug#884549: transition: libepubgen

[Rene Engelhard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

new upstream version. The EPUB3 support needed ABI bumps. It already cleared
NEW.

There's (right now) only one reverse-depends in sid: writerperfect.
The 0.9.5 in sid right now doesn't build against the new library but 0.9.6
(NEW) does.

In the upcoming 6.0 LibreOffice will also use libepubgen for epub export,
so in experimental libreoffice also is affected. From LibreOffice 6.0 rc1
onwards it even expects the new version and doesn't build/passes the tests
against the older.

Ben file:

title = "libepubgen";
is_affected = .depends ~ "libepubgen-0.0-0" | .depends ~ "libepubgen-0.1-1";
is_good = .depends ~ "libepubgen-0.1-1";
is_bad = .depends ~ "libepubgen-0.0-0";

(or use auto-libepubgen)

Regards,

Rene

Bug#884547: Preferred mixer in volume-plugin should be pavucontrol-qt instead of pavucontrol

[Alf Gaida]

Package: lxqt-panel
Version: 0.12.1~13-gde791908
Severity: normal

Apply the upstream change

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

Kernel: Linux 4.14.6-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxqt-panel depends on:
ii  libasound2  1.1.3-5
ii  libc6   2.25-4
ii  libdbusmenu-qt5-2   0.9.3+16.04.20160218-1
ii  libglib2.0-02.54.2-1
ii  libkf5solid55.37.0-2
ii  libkf5windowsystem5 5.37.0-2
ii  liblxqt-globalkeys-ui0  0.12.1~4-gc79d560-1
ii  liblxqt-globalkeys0 0.12.1~4-gc79d560-1
ii  liblxqt00.12.1~1-g18bc68f-1
ii  libmenu-cache3  1.1.1~2-g583c190-1
ii  libpulse0   11.1-4
ii  libqt5core5a5.9.2+dfsg-6
ii  libqt5dbus5 5.9.2+dfsg-6
ii  libqt5gui5  5.9.2+dfsg-6
ii  libqt5widgets5  5.9.2+dfsg-6
ii  libqt5x11extras55.9.2-1
ii  libqt5xdg3  3.1.1~0-1
ii  libqt5xml5  5.9.2+dfsg-6
ii  libsensors4 1:3.4.0-4
ii  libstatgrab10   0.91-1+b1
ii  libstdc++6  7.2.0-17
ii  libsysstat-qt5-00.4.1~2-g412c245-1
ii  libx11-62:1.6.4-3
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3
ii  libxkbcommon-x11-0  0.7.1-2
ii  libxkbcommon0   0.7.1-2
ii  libxrender1 1:0.9.10-1
ii  lxmenu-data 0.1.5-2
ii  lxqt-about  0.12.1~1-gd1ed3ac-1
ii  lxqt-policykit  0.12.1~1-g710c599-1

Versions of packages lxqt-panel recommends:
ii  lxqt-config 0.12.1~5-g6123e40-1
ii  lxqt-notificationd  0.12.1~1-g3ed7511-2
ii  lxqt-panel-l10n 0.12.1~17-g445c3ff1-1
ii  lxqt-qtplugin   0.12.1~1-gdfa18ac-2
ii  lxqt-runner 0.12.1~1-gc47a674-3
ii  lxqt-session0.12.1~5-gdee21be-2
ii  pavucontrol 3.0-3.1
ii  pavucontrol-qt  0.3.1~0
ii  qlipper 1:5.1.1-2

Versions of packages lxqt-panel suggests:
ii  lxqt   22
ii  lxqt-core  22

-- no debconf information

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

[Markus Koschany]

Am 16.12.2017 um 15:55 schrieb Sean Whitton:
> Hello Markus,
> 
> On Wed, Dec 13 2017, Markus Koschany wrote:
> 
>>> This would mean that we are not explicitly stating in our d/copyright
>>> file the difference between GPL-2 and GPL-2+.  To learn of the
>>> difference, a user would need to view the full spec of the copyright
>>> format.
>>
>> IMO this is already the case. What we do right now and what is
>> accepted by the ftp-master is, that we write for GPL-2 and GPL-2+ in
>> one package:
>>
>> License: GPL-2
>>  On Debian systems the full text of the GPL-2 can be found in
>> /usr/share/common-licenses/GPL-2
>>
>>
>> License: GPL-2+
>>  On Debian systems the full text of the GPL-2 can be found in
>> /usr/share/common-licenses/GPL-2
> 
> I am surprised to hear that this is accepted by ftp-master.  Would you
> mind pointing to an example package?

ufoai-data.


> ISTM that the text must explain what the '+' means to be acceptable, but
> I am not an ftp-master.

In my opinion this is uncontroversial because the official copyright
format 1.0 documentation makes use of the same conventions.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

If you feel that it should be better explained then I suggest that we
improve the documentation of copyright format 1.0.

>> I don't think it is a burden to take a look at the copyright format
>> 1.0 specification.
> 
> It requires Internet access, though.

I think it is fair to assume that the vast majority of our users have
internet access in 2017.

> One of the reasons we ship
> uncompressed d/copyright with every binary package is so that the
> copyright information is available offline; if we're not explaining what
> the '+' means, that's no longer true.  That's what I mean by a
> regression.

Simple solution: Install a copy of copyright format 1.0 into base-files
or another essential package, document best practices and point to this
document on the local system.

>> If the Policy editors cannot make a decision with regards to
>> debian/copyright then we should ask the DPL to seek legal advice and
>> when necessary start a GR for reasons of legitimacy.
> 
> If we think this issue is important enough to spend money on that.  I am
> not convinced it is.

Then we need a GR. Simply claiming that something violates the law
without proof cannot be the right way for a large project like Debian.
This is a very important topic because writing debian/copyright is not
optional in Debian. I simply believe that most people appreciate doing
something meaningful in their free time.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#884546: sreview: FTBFS: missing B-D on perl modules Mojo::JSON Mojo::Pg Moose DBI

[Andreas Beckmann]

Source: sreview
Version: 0.2.2-1
Severity: serious
Justification: fails to build from source

   dh_auto_configure
perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fdebug-prefix-map=/build/sreview-0.2.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linu
x-gnu-gcc -g -O2 -fdebug-prefix-map=/build/sreview-0.2.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Warning: prerequisite Mojo::JSON 0 not found.
Warning: prerequisite Mojo::Pg 0 not found.
Warning: prerequisite Moose 0 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for SReview
Writing MYMETA.yml and MYMETA.json

   dh_auto_test
make -j4 test TEST_VERBOSE=1
make[1]: Entering directory '/build/sreview-0.2.2'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" 
"-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" 
t/*.t
t/config.t . 
1..9
ok 1 - use SReview::Config;
ok 2 - loading nonexisting config produces a warning but succeeds
ok 3 - An object of class 'SReview::Config' isa 'SReview::Config'
ok 4 - loading an existing config file succeeds and prints no warning
ok 5 - Config dump output is as expected
ok 6 - Description of configuration value is as expected
ok 7 - Trying to parse a syntactically invalid perl script produces an exception
ok 8 - Trying to read a config variable that does not exist produces an 
exception
ok 9 - Reading data that does not exist yet produces the default
ok

#   Failed test 'use SReview::Video;'
#   at t/convert.t line 7.
# Tried to use 'SReview::Video'.
# Error:  Can't locate Mojo/JSON.pm in @INC (you may need to install the 
Mojo::JSON module) (@INC contains: /build/sreview-0.2.2/blib/lib 
/build/sreview-0.2.2/blib/arch /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/build/sreview-0.2.2/blib/lib/SReview/Video.pm line 74.
# BEGIN failed--compilation aborted at 
/build/sreview-0.2.2/blib/lib/SReview/Video.pm line 74.
# Compilation failed in require at t/convert.t line 7.
# BEGIN failed--compilation aborted at t/convert.t line 7.
[...]

and also

Error:  Can't locate Mojo/Pg.pm in @INC
Error:  Can't locate Moose.pm in @INC
Can't locate DBI.pm in @INC


Andreas


sreview_0.2.2-1.log.gz
Description: application/gzip

Bug#884154: FTBFS with chai 4.1.2 in experimental

[Ghislain Vaillant]

Why is this happening with chai 4.x and not 3.5?

Sorry, but I am gonna need more context to fix this.

Ghis

On Tue, 12 Dec 2017 14:00:12 +0530 Pirate Praveen  
wrote:

package: libjs-fetch
version: 2.0.3-1
severity: important

I'd like to upload chai 4.1.2 to unstable soon, please fix these failures.

xvfb-run -a -s "-screen 0 640x480x16" ./script/test
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pravi'
Error loading resource
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js
(203). Details: Error transferring
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js
- server replied: Not Found


․ArrayBuffer
is deprecated in XMLHttpRequest.send(). Use ArrayBufferView instead.
․

  94 passing (578ms)
  11 pending
  21 failing

  1) polyfill Headers returns null on no header found:
 isNull@http://localhost:3901/node_modules/chai/chai.js:4757:58
http://localhost:3901/test/test.js:208:18
callFn@http://localhost:3901/node_modules/mocha/mocha.js:4613:25
run@http://localhost:3901/node_modules/mocha/mocha.js:4
  06:13
  runTest@http://localhost:3901/node_modules/mocha/mocha.js:5002:13
  http://localhost:3901/node_modules/mocha/mocha.js:5080:19
  next@http://localhost:3901/node_modules/mocha/mocha.js:4927:16
  http://localhost:3901/node_modules/mocha/mocha.js:4937:11
  next@http://localhost:3901/node_modules/mocha/mocha.js:4875:25
  http://localhost:3901/node_modules/mocha/mocha.js:4904:9
  timeslice@http://localhost:3901/node_modules/mocha/mocha.js:6042:27

  2) polyfill Headers deletes headers:
 isNull@http://localhost:3901/node_modules/chai/chai.js:4757:58
http://localhost:3901/test/test.js:221:18
callFn@http://localhost:3901/node_modules/mocha/mocha.js:4613:25
run@http://localhost:3901/node_modules/mocha/mocha.js:4
  06:13
  runTest@http://localhost:3901/node_modules/mocha/mocha.js:5002:13
  http://localhost:3901/node_modules/mocha/mocha.js:5080:19
  next@http://localhost:3901/node_modules/mocha/mocha.js:4927:16
  http://localhost:3901/node_modules/mocha/mocha.js:4937:11
  next@http://localhost:3901/node_modules/mocha/mocha.js:4875:25
  http://localhost:3901/node_modules/mocha/mocha.js:4904:9
  timeslice@http://localhost:3901/node_modules/mocha/mocha.js:6042:27

  3) polyfill Headers throws TypeError on invalid character in field name:
 throws@http://localhost:3901/node_modules/chai/chai.js:6320:16
http://localhost:3901/test/test.js:237:18
callFn@http://localhost:3901/node_modules/mocha/mocha.js:4613:25
run@http://localhost:3901/node_modules/mocha/mocha.js:4606:13
runTest@http://localhost:3901/n
  de_modules/mocha/mocha.js:5002:13
  http://localhost:3901/node_modules/mocha/mocha.js:5080:19
  next@http://localhost:3901/node_modules/mocha/mocha.js:4927:16

Bug#884545: node-parse-glob: FTBFS and Debci failure with node-is-glob 4.0.0-1

[Adrian Bunk]

Source: node-parse-glob
Version: 3.0.4+dfsg-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/n/node-parse-glob/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-parse-glob.html

...
  48 passing (45ms)
  1 failing

  1) should get a base path: qmarks::

  AssertionError: '?' == '.'
  + expected - actual

  -?
  +.
  
  at Context. 
(/build/1st/node-parse-glob-3.0.4+dfsg/test.js:364:12)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:223:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:216:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:373:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:451:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:298:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:308:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:246:23)
  at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:275:5)
  at runCallback (timers.js:672:20)
  at tryOnImmediate (timers.js:645:5)
  at processImmediate [as _immediateCallback] (timers.js:617:5)



debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#884544: node-glob-parent: FTBFS and Debci failure with node-is-glob 4.0.0-1

[Adrian Bunk]

Source: node-glob-parent
Version: 3.0.1-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/n/node-glob-parent/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-glob-parent.html

...

  13 passing (15ms)
  1 failing

  1) glob-parent should strip glob magic to return parent path:

  AssertionError: qmarks must be escaped
  + expected - actual

  -path/?
  +path
  
  at Context. (/build/1st/node-glob-parent-3.0.1/test.js:48:12)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:223:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:216:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:373:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:451:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:298:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:308:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:246:23)
  at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:275:5)
  at runCallback (timers.js:672:20)
  at tryOnImmediate (timers.js:645:5)
  at processImmediate [as _immediateCallback] (timers.js:617:5)



debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#884543: node-glob-base: FTBFS and Debci failure with node-is-glob 4.0.0-1

[Adrian Bunk]

Source: node-glob-base
Version: 0.3.0-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/n/node-glob-base/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-glob-base.html

...
  9 passing (676ms)
  1 failing

  1) glob-base: qmarks::

  AssertionError: expected Object { base: '.', glob: '?', isGlob: 
false } to equal Object { base: '.', glob: '?', isGlob: true } (at isGlob, A 
has false and B has true)
  + expected - actual

   {
 "base": ".",
 "glob": "?",
  -  "isGlob": false
  +  "isGlob": true
   }
  
  at Assertion.fail (/usr/lib/nodejs/should/lib/assertion.js:92:17)
  at Assertion.value (/usr/lib/nodejs/should/lib/assertion.js:164:19)
  at Context. (/build/1st/node-glob-base-0.3.0/test.js:129:26)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:223:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:216:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:373:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:451:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:298:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:308:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:246:23)
  at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:275:5)
  at runCallback (timers.js:672:20)
  at tryOnImmediate (timers.js:645:5)
  at processImmediate [as _immediateCallback] (timers.js:617:5)



debian/rules:8: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#851547: gnome-shell: under Wayland, alt-tab switcher fails when using focus-follow-mouse

[Sean Whitton]

Hello Thomas,

On Wed, Dec 13 2017, Thomas Schwinge wrote:

> Has a solution already been found for this issue, or at least a
> workaround?

Unfortunately I don't know.  I abandoned using Wayland because of this
bug...

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field

[Sean Whitton]

Hello Steve,

On Tue, Dec 12 2017, Steve Langasek wrote:

> I strongly disagree with this.  I think this adds more syntax without
> adding any more information.
>
> The License: field is already very consistently used to contain
> whatever details of the license are required to be shipped with the
> package - either a full text of a license, or a license grant with a
> pointer to /usr/share/common-licenses.  If people feel that it's
> insufficiently obvious that this is the correct usage of the field, by
> all means, let's document that better; but let's not make a
> backwards-incompatible change to the syntax that doesn't benefit users
> of the file.

This is emphatically /not/ backwards-incompatible.

It's an optional field and we are not touching the description of the
License: field.  For those who are worried about this issue, both
License: and License-Grant: can be used; for those who are not, such as
yourself, you can just keep using License: as you have been doing.
There is no consensus on either of these options so we're making both
possible.

Does this weaken your disagreement?

-- 
Sean Whitton


signature.asc
Description: PGP signature