Bug#900327: ITP: golang-github-git-lfs-go-netrc -- netrc file parser for Go programming language.

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-git-lfs-go-netrc
  Version : 0.0~git20180525.e0e9ca4-1
  Upstream Author : Git LFS
* URL : https://github.com/git-lfs/go-netrc
* License : Expat
  Programming Lang: Go
  Description : netrc file parser for Go programming language.

 go-netrc A Golang package for reading and writing netrc files. This
 package can parse netrc files, make changes to them, and then serialize
 them back to netrc format, while preserving any whitespace that was
 present in the source file.
 .
 GoDoc (https://godoc.org/github.com/bgentry/go-netrc)

This is a patched version of golang-github-bgentry-go-netrc that is used by
git-lfs.

Bug#900326: nvidia-driver: Nvidia 390.48.3 install erroneously enables Orca screen reader.

[rich hartley]

Package: nvidia-driver
Version: 390.48-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Installed Nvidia driver 390.48.3 and dependencies from Debian non free repos.

Reboot.

Orca screen reader spontaneously enabled itself for log in screen and there is
no way to turn it off.

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

Uninstalled Orca via Synaptic.

   * What was the outcome of this action?

System would not boot. Grub screen comes up, select Debian and screen blinks
grey/black/grey/black.
Also tried to boot to Debian recovery mode. Same problem. Lots of verbose
verbage rolls past and then the system fails to boot.
Eventually reinstalled Debian via netinstall cd, same issue. Open source video
driver, no Orca. Installed Nvidia, Orca starts yapping but only at the login
screen.


   * What outcome did you expect instead?

That Orca would shut up.


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



-- Package-specific info:
uname -a:
Linux Debian 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux

/proc/version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.48  Thu Mar 22 00:42:57 PDT 
2018
GCC version:  gcc version 7.3.0 (Debian 7.3.0-19) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208 [GeForce GT 
730] [10de:1287] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ZOTAC International (MCO) Ltd. GK208B [GeForce GT 730] 
[19da:730b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 May 28 16:47 /dev/dri/card0
crw-rw+ 1 root video 226, 128 May 28 16:47 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 May 28 16:47 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 May 28 16:47 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 May 28 16:47 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 May 28 16:47 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 May 28 16:47 pci-:01:00.0-render -> ../renderD128
video:x:44:rich

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 May 28 15:12 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   51 May 28 15:12 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   50 May 28 15:12 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 May 28 15:12 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   54 May 28 15:12 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 May 28 15:12 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   51 May 28 15:12 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 May 28 15:12 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 May 28 15:12 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 May 28 15:12 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 May 28 15:12 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 May 28 15:12 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 May 28 15:12 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 May 28 15:12 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 May 28 15:11 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   59 May 28 15:11 
/etc/alternatives/nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0
lrwxrwxrwx 1 root root   62 May 28 15:11 
/etc/alternatives/nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLESv2_nvidia.so.2
lrwxrwxrwx 1 

Bug#900325: apt-cacher-ng: please remap security archive

[Stuart Prescott]

Package: apt-cacher-ng
Version: 3.1-1
Severity: wishlist

Dear Maintainer,

The Debian security archive now has several different ways of addressing it:

  http://security.debian.org/
  http://security.debian.org/debian-security/
  http://deb.debian.org/debian-security/
  https://deb.debian.org/debian-security/

(and SRV records for security.d.o now exist too)

I currentlty have all of the following through different chroots or virtual
machines that were created with different generations of tools:

  /var/cache/apt-cacher-ng/deb.debian.org/debian-security/
  /var/cache/apt-cacher-ng/security.debian.org/debian-security/
  /var/cache/apt-cacher-ng/security.debian.org/

It would be nice if apt-cacher-ng mapped these to a canonical name like is
done with debrep so that different machines with slightly different URLs
for the security archive can effectively share the same cache.

thanks
Stuart


-- Package-specific info:

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'proposed-updates'), (550, 
'stable'), (500, 'stable-debug'), (500, 'stable'), (60, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apt-cacher-ng depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.24
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u3
ii  libgcc11:6.3.0-18+deb9u1
ii  liblzma5   5.2.2-1.2+b1
ii  libssl1.1  1.1.0f-3+deb9u2
ii  libstdc++6 6.3.0-18+deb9u1
ii  libsystemd0232-25+deb9u3
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-5

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.6.32-2
pn  doc-base  
ii  libfuse2  2.9.7-1

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/port: keep
* apt-cacher-ng/tunnelenable: true
* apt-cacher-ng/cachedir: keep
* apt-cacher-ng/gentargetmode: No automated setup
* apt-cacher-ng/proxy: keep
* apt-cacher-ng/bindaddress: keep

Bug#900324: mouse buttons not working in fullscreen mode

[Harald Dunkel]

Package: tigervnc-viewer
Version: 1.7.0+dfsg-8

If I switch to full screen mode, than the mouse buttons are not
working anymore. F8 shows me just a white rectangle, i.e. I cannot
switch back to Window mode, either.

Desktop is fvwm.


Regards
Harri

Bug#900323: undertow: CVE-2018-1067: HTTP header injection using CRLF with UTF-8 Encoding (incomplete fix of CVE-2016-4993)

[Salvatore Bonaccorso]

Source: undertow
Version: 1.4.3-1
Severity: important
Tags: security upstream
Forwarded: https://issues.jboss.org/browse/UNDERTOW-1302

Hi,

The following vulnerability was published for undertow, the original
CVE-2016-4993 fixed via 1.4.3 upstream was incomplete. No fix
available at the time of writing.

CVE-2018-1067[0]:
| In Undertow before versions 7.1.2.CR1, 7.1.2.GA it was found that the
| fix for CVE-2016-4993 was incomplete and Undertow web server is
| vulnerable to the injection of arbitrary HTTP headers, and also
| response splitting, due to insufficient sanitization and validation of
| user input before the input is used as part of an HTTP header value.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1067
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1067
[1] https://issues.jboss.org/browse/UNDERTOW-1302

Regards,
Salvatore

Bug#899178: adding support conf.d in /etc

[Daniel Baumann]

tag 899178 + patch
thanks

jftr, here's a patch for this. I'll send a merge request on salsa later on.

Regards,
Daniel
commit e561fc3f5ef81afa43cbe1746642ce663c491bdf
Author: Daniel Baumann 
Date:   Tue May 29 05:47:00 2018 +0200

Updating config_files_path.patch to also include /etc/powerline as configuration directory (Closes: #899178).

Previously, only user specific configurations could be stored in
~/.config/powerline. Now /etc/powerline can additionally be used
as configuration directory which is system specific but applying
globally for all users at the same time.

The priority is now as follows (the later overwriting the
previous):

  1. /usr/share/powerline/config_files
  2. /etc/powerline
  3. ~/.config/powerline

Signed-off-by: Daniel Baumann 

diff --git a/debian/patches/config_files_path.patch b/debian/patches/config_files_path.patch
index d0ea015..eeae03f 100644
--- a/debian/patches/config_files_path.patch
+++ b/debian/patches/config_files_path.patch
@@ -2,16 +2,17 @@ Description: Adds Debian configuration path
 Bug-Debian: https://bugs.debian.org/758551
 Author: Jerome Charaoui 
 Forwarded: not-needed
-diff --git a/powerline/__init__.py b/powerline/__init__.py
-index 9d2bb68..0feefc9 100644
 a/powerline/__init__.py
-+++ b/powerline/__init__.py
-@@ -148,8 +148,7 @@ def get_config_paths():
+
+diff -Naurp powerline.orig/powerline/__init__.py powerline/powerline/__init__.py
+--- powerline.orig/powerline/__init__.py
 powerline/powerline/__init__.py
+@@ -148,8 +148,8 @@ def get_config_paths():
  	config_dirs = os.environ.get('XDG_CONFIG_DIRS', DEFAULT_SYSTEM_CONFIG_DIR)
  	if config_dirs is not None:
  		config_paths[:0] = reversed([join(d, 'powerline') for d in config_dirs.split(':')])
 -	plugin_path = join(os.path.realpath(os.path.dirname(__file__)), 'config_files')
 -	config_paths.insert(0, plugin_path)
++	config_paths.insert(0, '/etc/powerline')
 +	config_paths.insert(0, '/usr/share/powerline/config_files')
  	return config_paths
  
diff --git a/debian/powerline.README.Debian b/debian/powerline.README.Debian
index f80b685..8224d59 100644
--- a/debian/powerline.README.Debian
+++ b/debian/powerline.README.Debian
@@ -56,8 +56,14 @@ Configuration
 The default configuration files for Powerline are located in
 /usr/share/powerline/config_files
 
-A user may customize Powerline by copying the contents of this directory into
-~/.config/powerline and modifying the JSON-formatted configuration files.
+root may customize Powerline system-wide by copying the contents of this directory
+into /etc/powerline and modifying the JSON-formatted configuration files.
+This will overwrite the configuration from /usr/share/powerline/config_files
+and apply globally for all users on the system.
+
+Additionally a user may customize Powerline by using ~/.config/powerline accordingly.
+This will overwrite both the configuration from /usr/share/powerline/config_files
+and /etc/powerline, applying to the current user only.
 
 Documentation for the various configuration options is found in the
 powerline-doc package, at this URL:
diff --git a/debian/powerline.dirs b/debian/powerline.dirs
new file mode 100644
index 000..05b7d97
--- /dev/null
+++ b/debian/powerline.dirs
@@ -0,0 +1 @@
+/etc/powerline
diff --git a/debian/powerline.postrm b/debian/powerline.postrm
index a6db113..f6580c6 100644
--- a/debian/powerline.postrm
+++ b/debian/powerline.postrm
@@ -5,6 +5,7 @@ set -e
 case "${1}" in
 	purge)
 		rm -f /etc/profile.d/zz-powerline.sh
+		rmdir /etc/powerline > /dev/null 2>&1 || true
 		;;
 
 	remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)

Bug#846793: (no subject)

[Frédéric WANG]

On 29/05/2018 02:01, Hugo Lefeuvre wrote:
> Thanks for the patch ! I've had a look, and while it's perfectly ok to
> do it that way, I'd rather opt for the same source package as STIX 1
> with multiple upstream tarballs (so, we'd build both STIX 1 and STIX 2
> in the same source package).
>
> I'm going to take care of it in the next days. Don't hesitate to ping me
> next week if the package isn't in NEW.

Great, thank you for taking care of it.




signature.asc
Description: OpenPGP digital signature

Bug#900322: FTBFS if built twice in a row

[Arnaud Fontaine]

Package: nitrokey-app
Version: 1.3.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: qa-doublebuild

Hi,

Building twice in  a row fails because  of .ts files being  updated during the
build. Here is the error message on the second build:

  dpkg-buildpackage: info: source package nitrokey-app
  dpkg-buildpackage: info: source version 1.3.0-1
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Jan Luca Naumann 

  dpkg-buildpackage: info: host architecture amd64
   dpkg-source --before-build nitrokey-app-1.3.0
  dpkg-source: info: applying 0001-use-debhelper-for-bash-completion.patch
   fakeroot debian/rules clean
  dh clean --with bash-completion
 dh_auto_clean
 dh_clean
  rm -f debian/debhelper-build-stamp
  rm -rf debian/.debhelper/
  rm -f -- debian/nitrokey-app.substvars debian/files
  rm -fr -- debian/nitrokey-app/ debian/tmp/
  find .  \( \( \
  \( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o 
-path .\*/.hg -o -path .\*/CVS -o -path .\*/.pc -o -path .\*/_darcs \) -prune 
-o -type f -a \
  \( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
   -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
   -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
   -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
  \) -exec rm -f {} + \) -o \
  \( -type d -a -name autom4te.cache -prune -exec rm -rf {} + 
\) \)
   dpkg-source -b nitrokey-app-1.3.0
  dpkg-source: info: using source format '3.0 (quilt)'
  dpkg-source: info: building nitrokey-app using existing 
./nitrokey-app_1.3.0.orig.tar.gz
  dpkg-source: info: local changes detected, the modified files are:
   nitrokey-app-1.3.0/i18n/nitrokey_arabic.ts
   nitrokey-app-1.3.0/i18n/nitrokey_de_DE.ts
   nitrokey-app-1.3.0/i18n/nitrokey_en.ts
   nitrokey-app-1.3.0/i18n/nitrokey_fr.ts
  dpkg-source: info: you can integrate the local changes with dpkg-source 
--commit
  dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/nitrokey-app_1.3.0-1.diff.glsyzx
  dpkg-buildpackage: error: dpkg-source -b nitrokey-app-1.3.0 subprocess 
returned exit status 2

Cheers,
Arnaud Fontaine

Bug#899165: switching to python3 by default

[Daniel Baumann]

tag 899165 + patch
thanks

jftr, here's a patch for this. I'll send a merge request on salsa later on.

Regards,
Daniel
commit 860d86cd37ab107e19cefb445bb89334b6bbbedb
Primary key fingerprint: F2B6 45DF 1196 4018 E769  3B9F 4613 D5C7 94A6 A9B2
Author: Daniel Baumann 
Date:   Tue May 29 05:18:00 2018 +0200

Switching to use python3 by default (Closes: #899165).

Signed-off-by: Daniel Baumann 

diff --git a/debian/control b/debian/control
index 2683a05..f44be63 100644
--- a/debian/control
+++ b/debian/control
@@ -34,13 +34,12 @@ Description: powerline symbols font
 Package: powerline
 Architecture: any
 Depends:
- python-powerline,
+ python3-powerline,
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends},
 Recommends:
  fonts-powerline,
- python3-powerline,
 Suggests:
  powerline-doc,
  vim-addon-manager,
diff --git a/debian/patches/series b/debian/patches/series
index 30c6ca5..30d1d2d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ bindings_path.patch
 config_files_path.patch
 add_powerline_compile_flags.patch
 set_default_shell_theme.patch
+use_python3_by_default.patch
diff --git a/debian/patches/use_python3_by_default.patch b/debian/patches/use_python3_by_default.patch
new file mode 100644
index 000..061db28
--- /dev/null
+++ b/debian/patches/use_python3_by_default.patch
@@ -0,0 +1,93 @@
+Author: Daniel Baumann 
+Description: Switching to use python3 by default (Closes: #899165).
+
+diff -Naurp powerline.orig/client/powerline.py powerline/client/powerline.py
+--- powerline.orig/client/powerline.py
 powerline/client/powerline.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/powerline/bindings/awesome/powerline-awesome.py powerline/powerline/bindings/awesome/powerline-awesome.py
+--- powerline.orig/powerline/bindings/awesome/powerline-awesome.py
 powerline/powerline/bindings/awesome/powerline-awesome.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/powerline/bindings/bar/powerline-bar.py powerline/powerline/bindings/bar/powerline-bar.py
+--- powerline.orig/powerline/bindings/bar/powerline-bar.py
 powerline/powerline/bindings/bar/powerline-bar.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/powerline/bindings/i3/powerline-i3.py powerline/powerline/bindings/i3/powerline-i3.py
+--- powerline.orig/powerline/bindings/i3/powerline-i3.py
 powerline/powerline/bindings/i3/powerline-i3.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/powerline/bindings/lemonbar/powerline-lemonbar.py powerline/powerline/bindings/lemonbar/powerline-lemonbar.py
+--- powerline.orig/powerline/bindings/lemonbar/powerline-lemonbar.py
 powerline/powerline/bindings/lemonbar/powerline-lemonbar.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/powerline/bindings/pdb/__main__.py powerline/powerline/bindings/pdb/__main__.py
+--- powerline.orig/powerline/bindings/pdb/__main__.py
 powerline/powerline/bindings/pdb/__main__.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/scripts/powerline-config powerline/scripts/powerline-config
+--- powerline.orig/scripts/powerline-config
 powerline/scripts/powerline-config
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/scripts/powerline-daemon powerline/scripts/powerline-daemon
+--- powerline.orig/scripts/powerline-daemon
 powerline/scripts/powerline-daemon
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, print_function)
+ 
+diff -Naurp powerline.orig/scripts/powerline-lint powerline/scripts/powerline-lint
+--- powerline.orig/scripts/powerline-lint
 powerline/scripts/powerline-lint
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/python3
+ # vim:fileencoding=utf-8:noet
+ from __future__ import (unicode_literals, division, absolute_import, 

Bug#900321: Icons not displayed

[Arnaud Fontaine]

Package: nitrokey-app
Version: 1.3.0-1
Severity: important
Tags: patch upstream

Hi,

First of  all, thanks  for packaging  nitrokey-app! Since  nitrokey-app 1.3.0,
icons are not displayed anymore:
  QSystemTrayIcon::setVisible: No Icon set
  qt.svg: Cannot open file ':/images/new/icon_NK.svg', because: No such file or 
directory
  qt.svg: Cannot open file ':/images/new/icon_safe.svg', because: No such file 
or directory
  qt.svg: Cannot open file ':/images/new/icon_harddrive.svg', because: No such 
file or directory
  qt.svg: Cannot open file ':/images/new/icon_fragezeichen.svg', because: No 
such file or directory
  qt.svg: Cannot open file ':/images/new/icon_quit.svg', because: No such file 
or directory

More  generally  all  the  resources  (as listed  in  resources.qrc)  are  not
available   because  they   are  not   compiled  and   linked  to   the  final
executable. This  has been reported upstream  already[0] and the fix  has been
merged  too[1].   After  applying  the  patch of  this  merge  request[2]  and
rebuilding the package, I can confirm that  icons and other text files are now
visible.

Could you please apply this patch? Thanks!

Cheers,
Arnaud Fontaine

[0] https://github.com/Nitrokey/nitrokey-app/issues/345
[1] https://github.com/Nitrokey/nitrokey-app/pull/346
[2] 
https://github.com/Nitrokey/nitrokey-app/pull/346/commits/30587e2e8915b14c0256feff39bca39b6646203c

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

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

Versions of packages nitrokey-app depends on:
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-3
ii  libnitrokey33.3-2
ii  libqt5core5a5.10.1+dfsg-7
ii  libqt5gui5  5.10.1+dfsg-7
ii  libqt5svg5  5.10.1-2
ii  libqt5widgets5  5.10.1+dfsg-7
ii  libstdc++6  8.1.0-3

Versions of packages nitrokey-app recommends:
ii  libccid   1.4.29-2
ii  pcscd 1.8.23-3
ii  scdaemon  2.2.7-1

nitrokey-app suggests no packages.

-- no debconf information

Bug#900320: ITP python-libnmap -- Python Nmap library

[Samuel Henrique]

Package: python-libnmap
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages


​* Package name: python-libnmap
  Upstream Author : Ronald Bister 
* URL : https://pypi.org/project/python-libnmap/
 
* License : Creative Common "Attribution" license (CC-BY) v3
  Programming Lang: Python
  Description : Library enabling Python developers to
 manipulate nmap process and data:
* automate or schedule nmap scans on a regular basis
* manipulate nmap scans results to do reporting
* compare and diff nmap scans to generate graphs
* batch process scan reports
* ...
 The lib currently offers the following modules:
* process: enables you to launch nmap scans
* parse: enables you to parse nmap reports or scan results (only XML so
  far) from a file, a string,…
* report: enables you to manipulate a parsed scan result and
de/serialize
  scan results in a json format
* diff: enables you to see what changed between two scans
* common: contains basic nmap objects like NmapHost and NmapService. It
is
  to note that each object can be “diff()ed” with another similar
object.
* plugins: enables you to support datastores for your scan results
directly
  in the “NmapReport” object. from report module:
* mongodb: insert/get/getAll/delete
* sqlalchemy: insert/get/getAll/delete


​I intend to maintain this package under the DPMT team.

This package is a dependency of changeme (#898680).


-- 
Samuel Henrique 

Bug#900319: ITP python-shodan -- The official Python library for accessing Shodan

[Samuel Henrique]

> * URL : https://github.com/ztgrace/changeme

​The correct URL would be: https://github.com/achillean/shodan-python​




-- 
Samuel Henrique 

Bug#899135: fixed in git

[Daniel Baumann]

tag 899135 + pending
tag 899142 + pending
tag 899153 + pending
tag 899150 + pending
tag 899184 + pending
thanks

These bugs are fixed in git, tagging them as pending.

Regards,
Daniel

Bug#900319: ITP python-shodan -- The official Python library for accessing Shodan

[Samuel Henrique]

Package: python-shodan
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages


​* Package name: python-shodan
  Upstream Author : John Matherly 
* URL : https://github.com/ztgrace/changeme

* License : ICU
  Programming Lang: Python
  Description : Shodan is a search engine for Internet-connected
devices.
Google lets you search for websites, Shodan lets you search for devices.
This library provides developers easy access to all of the data stored in
Shodan in order to automate tasks and integrate into existing tools.

​I intend to maintain this package under the DPMT team.

This package is a dependency of changeme (#898680).


-- 
Samuel Henrique 

Bug#900318: new nethack version available

[Elguavas]

Package: nethack
Version: 3.6.0-4
Severity: wishlist

hi, netchack 3.6.1 has been out a little while now. would be nice to see 
it packaged when you are able. ;)


source is linked already from the maintainer page for the package.

cheers!

Bug#900317: debian-installer: black screen and no answer from X server

[Cyril Brulebois]

Package: debian-installer
Severity: serious
Justification: unresponsive d-i

Hi,

Trying a build against the new linux ABI, I've just discovered another
issue with the graphical installer. It just shows a black screen, which
is tracked in #898468 already (which reminds me I need to follow up
there with my findings). Unfortunately the issue seems more severe now
as X doesn't react to ctrl-alt-fN key strokes, making it hard(er) to
debug what's happening.

Going back to the previous linux ABI shows the same behaviour (so both
4.16.0-1 and 4.16.0-2 are affected), so I suppose it could be due to the
new X server. It seems to start at least, since I'm briefly seeing its
startup logs.


Interested people could look at images from the last few days and check
the differences in build logs for further suspects:
  https://d-i.debian.org/daily-images/amd64/

For this bug:
 - OK = ctrl-alt-fN can switch ttys. You'll likely see messages about
“random” things (see #898468).
 - KO = ctrl-alt-fN doesn't seem to have any effects.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#899406: requests.Session doesn't properly handle closed keep-alive sessions

[Daniele Tricoli]

forwarded 899406 https://github.com/requests/requests/issues/4664
thanks

Hello Jonathan,
thanks for your report!

On Wednesday, May 23, 2018 10:16:57 PM CEST Jonathan Lynch wrote:
> Package: python-requests
> Version: 2.18.4
[CUT detailed description]

I forwarded the issue upstream since it's not Debian specific. Do you have a 
test that is able to reproduce systematically the issue? If yes can you attach 
on upstream bug tracker?

Kind regards,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#900315: RFS: olivetti-mode/1.6.0-1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "olivetti-mode"

Dear Jonathan,

I've CCed you because you sponsored the last upload of olivetti-mode.
If you're satisfied with the quality of my work would you please
consider granting DM upload rights for this package?

Package name: olivetti-mode
Version : 1.6.0-1
Upstream Author : Paul Rankin 
URL : https://github.com/rnkn/olivetti
License : GPL-3+
Section : editors

It builds this binary package:

elpa-olivetti - Emacs minor mode to more comfortably write prose

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

https://mentors.debian.net/package/olivetti-mode

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

dget -x 
https://mentors.debian.net/debian/pool/main/o/olivetti-mode/olivetti-mode_1.6.0-1.dsc

Or download with git:

git clone https://salsa.debian.org/emacsen-team/olivetti-mode.git

More information about olivetti-mode can be obtained from 
https://github.com/rnkn/olivetti.

Changes since the last upload:

olivetti-mode (1.6.0-1) unstable; urgency=medium

  * New upstream release.
  * debian/control:
- Add missing homepage.
- Change section to editors, which is more accurate and discoverable.
- Relax debhelper dep to allow backporting.
- Switch Vcs from alioth to salsa.
- Update Maintainer team name and email address.
  * debian/copyright: Add 2017 to copyright range.
  * Update 0001-Fix-version-declared-in-ELPA-header.patch to declare 1.6.0.
  * Declare Standards-Version: 4.1.4. (No additional changes needed)

 -- Nicholas D Steeves   Sat, 26 May 2018 21:36:45 -0400

olivetti-mode (1.5.9-1) unstable; urgency=medium


Regards,
Nicholas D Steeves

Bug#900248: Direct Render problem

[Dean Loros]

Yes---the change in xorg caused the problem. I linked the nvidia  libglx.so
from
/usr/lib/xorg/modules/linux/ to /usr/lib/xorg/modules/extensions/ (renamed
the libglx.so in /extensions to libglx.so.bak). Restarted my system & now
have direct rendering.

dean@debian:~$ glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 960/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.59
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 390.59
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.59
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

That is a "temporary" fix that works.

Bug#900314: [patch] relax dh 11 build dep to 11~ so a no-change bpo remains possible

[Nicholas D Steeves]

Package: btrfs-progs
Version: 4.16.1-1
Severity: normal
Control: tags -1 patch

Hi Dimitri,

Trivial patch attached.  The rational is debhelper/11.2.1~bpo9+1 does not 
fulfill >= 11, so 11 should be 11~.

Cheers,
Nicholas
>From 5fe6e97ec8ef978ac5655c04517ec07e7116a5bf Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Mon, 28 May 2018 20:36:44 -0400
Subject: [PATCH] Relax debhelper build dep so that no-change bpos remain
 possible.

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

diff --git a/debian/control b/debian/control
index 620e2b1b..bb78d454 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: admin
 Priority: optional
 Maintainer: Dimitri John Ledkov 
 Uploaders: Dimitri John Ledkov 
-Build-Depends: debhelper (>= 11),
+Build-Depends: debhelper (>= 11~),
e2fslibs-dev,
pkg-config,
libacl1-dev,
-- 
2.17.0

Bug#896666: qemu-system-x86: page allocation failure: 4.16.0-0.bpo.1-amd64

[Russell Mosemann]

 
Package: src:linux
Version: 4.16.5-1~bpo9+1
Severity: important

 
 
 
May 28 18:32:33 vhost004 kernel: qemu-system-x86: page allocation failure: 
order:4, mode:0x140c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
May 28 18:32:33 vhost004 kernel: qemu-system-x86 cpuset=emulator 
mems_allowed=0-1
May 28 18:32:33 vhost004 kernel: CPU: 9 PID: 23442 Comm: qemu-system-x86 
Tainted: G  I  4.16.0-0.bpo.1-amd64 #1 Debian 4.16.5-1~bpo9+1
May 28 18:32:33 vhost004 kernel: Hardware name: HP ProLiant DL380 G6, BIOS P62 
08/16/2015
May 28 18:32:33 vhost004 kernel: Call Trace:
May 28 18:32:33 vhost004 kernel:  dump_stack+0x5c/0x85
May 28 18:32:33 vhost004 kernel:  warn_alloc+0xfc/0x180
May 28 18:32:33 vhost004 kernel:  __alloc_pages_slowpath+0xded/0xe00
May 28 18:32:33 vhost004 kernel:  ? _cond_resched+0x16/0x40
May 28 18:32:33 vhost004 kernel:  __alloc_pages_nodemask+0x212/0x250
May 28 18:32:33 vhost004 kernel:  kmalloc_order+0x14/0x40
May 28 18:32:33 vhost004 kernel:  kmalloc_order_trace+0x1d/0xa0
May 28 18:32:33 vhost004 kernel:  kvm_dev_ioctl+0xb4/0x680 [kvm]
May 28 18:32:33 vhost004 kernel:  do_vfs_ioctl+0xa2/0x620
May 28 18:32:33 vhost004 kernel:  SyS_ioctl+0x74/0x80
May 28 18:32:33 vhost004 kernel:  do_syscall_64+0x6c/0x130
May 28 18:32:33 vhost004 kernel:  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
May 28 18:32:33 vhost004 kernel: RIP: 0033:0x7f2a05a0bdd7
May 28 18:32:33 vhost004 kernel: RSP: 002b:7fffc50fed58 EFLAGS: 0246 
ORIG_RAX: 0010
May 28 18:32:33 vhost004 kernel: RAX: ffda RBX: ae01 
RCX: 7f2a05a0bdd7
May 28 18:32:33 vhost004 kernel: RDX:  RSI: ae01 
RDI: 000b
May 28 18:32:33 vhost004 kernel: RBP:  R08: 55de26f419b8 
R09: 0050
May 28 18:32:33 vhost004 kernel: R10: 0020 R11: 0246 
R12: 55de27a7bd90
May 28 18:32:33 vhost004 kernel: R13: 0002 R14: 0120 
R15: 
May 28 18:32:33 vhost004 kernel: Mem-Info:
May 28 18:32:33 vhost004 kernel: active_anon:9943 inactive_anon:13313 
isolated_anon:0
  active_file:248152 inactive_file:821236 
isolated_file:0
  unevictable:16675 dirty:48225 writeback:0 
unstable:0
  slab_reclaimable:62697 
slab_unreclaimable:412397
  mapped:24632 shmem:10022 pagetables:5330 
bounce:0
  free:76874 free_pcp:118 free_cma:0
May 28 18:32:33 vhost004 kernel: Node 0 active_anon:24988kB 
inactive_anon:36276kB active_file:807376kB inactive_file:1315172kB 
unevictable:4604kB isolated(anon):0kB isolated(file):0kB mapped:40136kB 
dirty:20388kB writeback:0kB shmem:6188kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 28 18:32:33 vhost004 kernel: Node 1 active_anon:14784kB 
inactive_anon:16976kB active_file:185232kB inactive_file:1969772kB 
unevictable:62096kB isolated(anon):0kB isolated(file):0kB mapped:58392kB 
dirty:172512kB writeback:0kB shmem:33900kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 16384kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 28 18:32:33 vhost004 kernel: Node 0 DMA free:15892kB min:20kB low:32kB 
high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 28 18:32:33 vhost004 kernel: lowmem_reserve[]: 0 3486 30139 30139 30139
May 28 18:32:33 vhost004 kernel: Node 0 DMA32 free:136480kB min:5204kB 
low:8772kB high:12340kB active_anon:23512kB inactive_anon:33720kB 
active_file:788752kB inactive_file:1284216kB unevictable:1600kB 
writepending:20384kB present:3643520kB managed:3577952kB mlocked:1600kB 
kernel_stack:2992kB pagetables:8264kB bounce:0kB free_pcp:0kB local_pcp:0kB 
free_cma:0kB
May 28 18:32:33 vhost004 kernel: lowmem_reserve[]: 0 0 26653 26653 26653

May 28 18:32:33 vhost004 kernel: Node 0 Normal free:41552kB min:39784kB 
low:67076kB high:94368kB active_anon:1588kB inactive_anon:2556kB 
active_file:18628kB inactive_file:30704kB unevictable:3004kB writepending:4kB 
present:27787264kB managed:27292884kB mlocked:3004kB kernel_stack:1592kB 
pagetables:424kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
May 28 18:32:33 vhost004 kernel: lowmem_reserve[]: 0 0 0 0 0
May 28 18:32:33 vhost004 kernel: Node 1 Normal free:113572kB min:45096kB 
low:76032kB high:106968kB active_anon:14784kB inactive_anon:16976kB 
active_file:185232kB inactive_file:1970136kB unevictable:62096kB 
writepending:172512kB present:31457276kB managed:30943772kB mlocked:62096kB 
kernel_stack:5176kB pagetables:12632kB bounce:0kB free_pcp:472kB local_pcp:0kB 
free_cma:0kB
May 28 18:32:33 vhost004 kernel: lowmem_reserve[]: 0 0 0 0 0
May 28 18:32:33 vhost004 kernel: Node 0 DMA: 1*4kB (U) 

Bug#900313: libcurl4: 7.60.0-2 broke binaries built against older versions

[Mike Hommey]

Package: libcurl4
Version: 7.60.0-2
Severity: important

Dear Maintainer,

Starting a program built/linked against a previous version of libcurl4
(git-remote-http in a local build of git, for instance), fails with:

./git-remote-http: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version 
`CURL_OPENSSL_3' not found (required by ./git-remote-http)

And sure enough, relinking makes the binaries use the CURL_OPENSSL_4
version.

Mike


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

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

Versions of packages libcurl4 depends on:
ii  libc6 2.27-3
ii  libcom-err2   1.44.2-1
ii  libgssapi-krb5-2  1.16-2
ii  libidn2-0 2.0.4-1.1
ii  libk5crypto3  1.16-2
ii  libkrb5-3 1.16-2
ii  libldap-2.4-2 2.4.46+dfsg-5
ii  libnghttp2-14 1.32.0-1
ii  libpsl5   0.20.1-1
ii  librtmp1  2.4+20151223.gitfa8646d.1-2
ii  libssh2-1 1.8.0-1
ii  libssl1.1 1.1.0h-4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages libcurl4 recommends:
ii  ca-certificates  20180409

libcurl4 suggests no packages.

-- no debconf information

Bug#846793: (no subject)

[Hugo Lefeuvre]

Hi Frédéric,

> > If anybody has time to package STIX 2, feel free to submit your update/
> > NEW package, I'll be glad to upload it.
> 
> @Hugo: Have you been able to check the patch?

Thanks for the patch ! I've had a look, and while it's perfectly ok to
do it that way, I'd rather opt for the same source package as STIX 1
with multiple upstream tarballs (so, we'd build both STIX 1 and STIX 2
in the same source package).

I'm going to take care of it in the next days. Don't hesitate to ping me
next week if the package isn't in NEW.

Regards,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#897447: jessie-pu: package ghostscript/9.06~dfsg-2+deb8u7

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2018-05-26 at 11:19 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sat, May 26, 2018 at 09:39:34AM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2018-05-02 at 20:53 +0200, Salvatore Bonaccorso wrote:
> > > This is the corresponding update (as proposed for stretch-pu in
> > > #897188 for stretch) for ghostscript to address CVE-2018-10194
> > > and
> > > CVE-2016-10317.
> > > 
> > 
> > Please go ahead.
> 
> Thank you, uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#891611: jessie-pu: package subversion/1.8.10-6+deb8u6

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2018-05-20 at 19:31 -0400, James McCoy wrote:
> On Mon, Feb 26, 2018 at 10:12:15PM -0500, James McCoy wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: jessie
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > This upload would fix crashes that are seen when using subversion's
> > Perl
> > bindings.  In particular, git-svn has been a common victim since
> > its
> > memory usage patterns tend to cause the right conditions.
> > 
> > I've verified this against the originally reported issue[0] and
> > Salvatore Bonaccorso, who prodded me to prepare the upload, has
> > verified
> > it against their problematic repository.
> 
> Uploaded, per the workflow changes described in
> <1523909491.2872.15.ca...@adam-barratt.org.uk>.
> 

Flagged for acceptance into o-p-u.

Regards,

Adam

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Peter De Wachter]

Package: nvidia-driver
Followup-For: Bug #900248

I think this bug is caused by a change in xserver 1.20. The nvidia
libglx.so gets installed in /usr/lib/xorg/modules/linux/, but this
directory has been removed from X's search path. As a result X only
finds the default libglx.so in /usr/lib/xorg/modules/extensions/.
See this commit:
https://cgit.freedesktop.org/xorg/xserver/commit/?id=97bd6e453676516891250389ec0fd695c110087c

Best regards,
Peter

Bug#900312: RFS: khronos-api/4.6+git20180514-1~bpo9+1

[Jens Reyer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "khronos-api"

 * Package name: khronos-api
   Version : 4.6+git20180514-1~bpo9+1
   Upstream Author : The Khronos Group Inc.
 * URL : https://www.opengl.org/registry
 * License : Apache-2.0
   Section : x11

It builds those binary packages:

khronos-api - Khronos XML API Registry

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

  https://mentors.debian.net/package/khronos-api


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

dget -x
https://mentors.debian.net/debian/pool/main/k/khronos-api/khronos-api_4.6+git20180514-1~bpo9+1.dsc


Changes since the last upload:

I only added myself to uploaders, otherwise this is a no-change upload
of the package from unstable to stretch-backports.

It's a now required build-dependency for the src:wine backports.

I'm a DM with upload-rights for khronos-api and I'm in the backports
acl, so I only need a sponsor for this first NEW upload to
stretch-backports.

I informed the maintainer about the stretch-backport (but he's usually
not available for sponsoring).

Greets
jre

Bug#900248: Direct Render problem

[Dean Loros]

Greetingstwo more of us have commented on this bug. I have a fully
updated install & am experiencing this problem (nothing pinned). I have
posted the nvidia-bug-report via a google drive link in the bug report.
Still running 390.59-1, the system works with no GL apps working properly.
Cairo Dock shows artifacts during animations. GLXGears looks "normal"
(several 100fps low). My baseline game (Linux version of UT2004) runs at
about 10~15fps. All newer games run about 1~2fps. I have not reverted
back--am able to test if more information is needed.

-- 
Cheers!!!
Dean Loros
Performance by Design Ltd.
autocrosser at http://forums.linuxmint.com

Bug#895866: Bug 895866

[Burton Rhodes]

Is there any update on this issue?

Thanks,
Burton

Burton Rhodes
AFrameSoftware

bur...@aframesoftware.com
www.AFrameSoftware.com

Bug#882197: stretch-pu: package variety/0.6.3-5+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2017-11-24 at 10:57 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2017-11-19 at 21:21 -0800, James Lu wrote:
> > I've prepared an update for Variety to fix some shell injection
> > bugs
> > caused by crafted filenames. These fixes are backported from the
> > 0.6.6 release which is currently in unstable.
> 
> Assuming that the resulting package has been built and tested in a
> stretch environment, please go ahead.

Rather belatedly uploaded; flagged for acceptance.

Regards,

Adam

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Herbert Snorrason]

On Mon, 28 May 2018 21:32:38 +0900 Norbert Preining
 wrote:
> I downgraded all the nvidia stuff to 390.48-3 and with the same
> kernel (and the same error message of the kernel) all works back fine as
> normal:
I tried to do that, and wound up not being able to install any of the
nvidia stuff. So for clarity: Did you also downgrade the X server?

> My suspect is that (from aptitude.log):
> [REMOVE] libgles1-glvnd-nvidia:amd64 390.48-3
> [REMOVE] libgles1-glvnd-nvidia:i386 390.48-3
> two package which seem to be not available or installable in sid at the
> moment.

That doesn't show up on my system, so seems unlikely to be the culprit.

With greetings,
  Herbert Snorrason

Bug#897188: stretch-pu: package ghostscript/9.20~dfsg-3.2+deb9u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2018-05-26 at 11:09 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sat, May 26, 2018 at 09:39:12AM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sun, 2018-04-29 at 20:43 +0200, Salvatore Bonaccorso wrote:
> > > I would like to propose the following ghostscript update via a
> > > stretch
> > > point release. It adresses two CVEs which do not warrant a DSA on
> > > it's
> > > own but would still be good to be adressed in stable.
> > > 
> > > It adresses: 
> > >  - CVE-2018-10194 / 896069. Triggering the poc was not possible
> > > here
> > >    but the fix consist of doing an additional check in
> > >    set_text_distance function.
> > >  - CVE-2016-10317, testing happened with the fixed version
> > > against
> > > the
> > >    provided poc. The fix requires a previous prerequisite change.
> > > 
> > 
> > Please go ahead; sorry for the delay.
> 
> Thank you! Uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#876944: jessie-pu: package bwm-ng/0.6-3.1

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2018-05-18 at 10:25 +0100, Jonathan Wiltshire wrote:
> On Sat, Nov 18, 2017 at 10:39:47PM -0200, Samuel Henrique wrote:
> > 2017-11-18 17:03 GMT-02:00 Adam D. Barratt  > k>:
> > 
> > > On Wed, 2017-09-27 at 00:53 -0300, Samuel Henrique wrote:
> > > > This is a small change on d/rules passing "--without-
> > > > libstatgrab"
> > > > (as advised by upstream on a duplicate bug report[1]) to fix
> > > > #855215[2].
> > > > 
> > > 
> > > While I assume the end result is sane, passing both --with-
> > > libstatgrab
> > > and --without-libstatgrab to the same configure invocation is at
> > > best
> > > confusing...
> > > 
> > 
> > Thanks for catching that, it was my mistake.
> > 
> > There's an updated debdiff attached, already pushed to git.
> 
> For the avoidance of doubt, a confirmed tag means you can go ahead
> and
> upload.
> 

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#900309: alpine: does not render HTML internally

[Thorsten Glaser]

Package: alpine
Version: 2.21+dfsg1-1+b1
Severity: normal

In pine, when I get an HTML eMail, I press cursor-right to get to this view:

   1 4 lines   Text/PLAIN
   214 lines   Text/HTML

Then I go to the second line and press cursor-right again, and it renders
the HTML internally, with actionable links even.

In alpine, however, it asks this instead:

View selected Attachment?
Y [Yes]
N No

However, when I press Y/Enter, when started from X11, it runs Opera on
the file (which is almost never the thing I want), and when started from
a terminal (e.g. via ssh), it just does *nothing* so I consider it a bug,
with the preferred fix being internal rendering just like pine, and the
alternatively accepted lazy solution being it using lynx to display it.

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

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

Versions of packages alpine depends on:
ii  libc6 2.27-3
ii  libgssapi-krb5-2  1.16-2
ii  libkrb5-3 1.16-2
ii  libldap-2.4-2 2.4.45+dfsg-1
ii  libpam0g  1.1.8-3.7
ii  libssl1.1 1.1.0h-4
ii  libtinfo6 6.1+20180210-4
ii  mlock 8:2007f~dfsg-5

Versions of packages alpine recommends:
pn  alpine-doc  

Versions of packages alpine suggests:
ii  aspell  0.60.7~20110707-5
ii  postfix [mail-transport-agent]  3.3.0-1+b1

-- no debconf information

Bug#900214: RFS: elpy/1.21.0-1

[Nicholas D Steeves]

On Sun, May 27, 2018 at 08:58:23PM +0100, Chris Lamb wrote:
> tags 900214 + pending
> thanks
> 
> > I am looking for a sponsor for my package "elpy"
> 
> Uploaded. :P)

Thank you! :-D


signature.asc
Description: PGP signature

Bug#867731: RFS: smart-mode-line/2.11.0-1 [ITP]

[Nicholas D Steeves]

Hi Chris,

On Sun, May 27, 2018 at 09:01:37PM +0100, Chris Lamb wrote:
> Hi Nicholas,
> 
> > OTTO documentation
> 
> (Hm?)

It seems the abbreviation for "on the topic of" isn't as common as I
had thought!

> > I'm thinking about a mini-project that could save a lot of people time and
> > that might encourage every maintainer to provide a README.source ;-)
> 
> Only if it contains genuinely useful info specific to that package --
> would really love to avoid the "boy who cried wolf" with that file.
> 
> See, for example, this bug report from 2009:
> 
>   https://bugs.debian.org/543260

Yup, that convinces me to give up on the mini-project.

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#894827: apache2: Apache workers are hanging after reload

[Michał Klichowicz]

Hi,

I think I'm affected by the same problem.

After upgrading to 2.4.33-3 it's happening consistently after every
reload, to all the workers (making all the requests to the server time
out until I restart the server).

I've been juggling between one of the older versions (2.4.25-3) and the
current version and under .25 it does not happen every time, but after
some longer time from server restart, a reload would once again start
causing hanging.

The only indication in the logs of what's happening during the reload,
are segfaults in Apache error.log:

[core:notice] [pid 908] AH00052: child pid 3508 exit signal Segmentation
fault (11)

and in kernel log:

apache2[1728]: segfault at 7f1389bcf660 ip 7f1389bcf660 sp
7fff3fba3298 error 14 in mod_vhost_alias.so[7f139026f000+2000]

followed by errors (AH00106) from shell scripts that I've set up to
handle piped logging - but these are logged only during the reload, not
while the server in unresponsive, so this might be irrelevant.

Since I've got the configuration that's generating the problem
consistently, is there anything I can do to help track it down?

Cheers,
Michał K.

Bug#900310: python-ase test suite fails with latest python-flask

[Daniel Watkins]

Package: python-ase
Version: 3.16.0-1
Severity: normal

Dear Maintainer,

When running autopkgtests in Ubuntu, the python-ase test suite fails
with the latest python-flask[0].  I have prepared a patch for the Ubuntu
package to address this, which I will adapt to the Debian package and
add to this report.


Thanks,

Dan


[0] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/p/python-ase/20180517_175507_a3e3f@/log.gz

Bug#900311: recoll: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: recoll
Version: 1.23.7-4
Severity: serious

Dear maintainer: This package fails to build from source when built
with dpkg-buildpackage -A:

[...]
running install_egg_info
Writing 
/<>/debian/tmp/usr/lib/python3/dist-packages/Recoll-1.0.egg-info
 dpkg-genbuildinfo --build=all
 dpkg-genbuildinfo: error: binary build with no binary artifacts found; 
.buildinfo is meaningless 
dpkg-buildpackage: error: dpkg-genbuildinfo --build=all subprocess
returned exit status 25

To reproduce, please try "dpkg-buildpackage -A".


This happens because debian/rules has a binary-indep target which does
nothing:

binary-indep: build install

The arch:all packages are supposed to be created there, but the target
does not create any packages, they are only created in binary-arch.

Sorry, I don't have a fix, but I would personally recommend switching
to a dh-style debian/rules as part of the fix.

I would also recommend that you try to upload packages
in source-only form, i.e. using "dpkg-buildpackage -S"
so that this kind of bugs never propagate to testing.

Thanks.

Bug#900089: [zfs-dkms]

[Chris Dos]

lsb_release -is = Devuan

Also installed the sysvinit patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826994

I deployed a Stretch test system from an upgrade from Jessie along with the
sysvinit patch.  To my surprise, zfs-dkms compiled fine.

So it seams that on the entire server with 1733 packages, only the spl-dkms
zfs-dkms zfs-initramfs zfs-zed require the lsb-release package dependency.

Can this dependency be removed so Devuan and other Debian based distributions
will continue to work with these packages?

Looking at the source:
grep -r lsb_release *
debian/zfs-dkms.dkms:case `lsb_release -is` in
debian/zfs-dkms.dkms.debhelper:case `lsb_release -is` in
debian/zfs-dkms/usr/src/zfs-0.7.9/dkms.conf:case `lsb_release -is` in
So there are three references.

Looking at: debian/zfs-dkms.dkms, debian/zfs-dkms.dkms.debhelper,
debian/zfs-dkms/usr/src/zfs-0.7.9/dkms.conf, all three have the same check.
  --with-linux=$(
case `lsb_release -is` in
  (Debian)
if [[ -e ${kernel_source_dir/%build/source} ]]
then
  echo ${kernel_source_dir/%build/source}
else
  # A kpkg exception for Proxmox 2.0
  echo ${kernel_source_dir}
fi
  ;;
  (*)
echo ${kernel_source_dir}
  ;;
esac
  )

Is it necessary to use the lsb_release case statement?  Would it not be best
just to use something like this for maximum compatibility with Debian based
distros?
  --with-linux=$(
if [[ -e ${kernel_source_dir/%build/source} ]]
then
  echo ${kernel_source_dir/%build/source}
else
  # A kpkg exception for Proxmox 2.0
  echo ${kernel_source_dir}
fi
  )


I would like to see the entire debian folder tree go into ZoL source.  Debian
is the core for a lot of distributions and it would be good see a debian
folder added to ZoL source.

I have attached a patch to remove the lsb_release check listed above.
zfs-dkms installed and compiled cleanly on Devuan Jessie, Devuan Ascii
(Stretch), and Devuan Ceres (Sid).

I guess this bug can be changed from Grave to Wishlist, though I hope
lsb_release dependency is removed.

Chris

Description: Remove lsb_release dependency to work on other distributions.
Author: Chris Dos 
Bug-Debian: https://bugs.debian.org/900089
Forwarded: no
--- a/scripts/dkms.mkconf
+++ b/scripts/dkms.mkconf
@@ -25,7 +25,15 @@
 PRE_BUILD="configure
   --prefix=/usr
   --with-config=kernel
-  --with-linux=\${kernel_source_dir}
+  --with-linux=\$(
+if [[ -e \${kernel_source_dir/%build/source} ]]
+then
+  echo \${kernel_source_dir/%build/source}
+else
+  # A kpkg exception for Proxmox 2.0
+  echo \${kernel_source_dir}
+fi
+  )
   --with-linux-obj=\${kernel_source_dir}
   --with-spl=\${source_tree}/spl-\${PACKAGE_VERSION}
   --with-spl-obj=\${dkms_tree}/spl/\${PACKAGE_VERSION}/\${kernelver}/\${arch}
--- a/debian/zfs-dkms.dkms
+++ b/debian/zfs-dkms.dkms
@@ -6,8 +6,6 @@
   --prefix=/usr
   --with-config=kernel
   --with-linux=$(
-case `lsb_release -is` in
-  (Debian)
 if [[ -e ${kernel_source_dir/%build/source} ]]
 then
   echo ${kernel_source_dir/%build/source}
@@ -15,11 +13,6 @@
   # A kpkg exception for Proxmox 2.0
   echo ${kernel_source_dir}
 fi
-  ;;
-  (*)
-echo ${kernel_source_dir}
-  ;;
-esac
   )
   --with-linux-obj=${kernel_source_dir}
   --with-spl=${source_tree}/spl-${PACKAGE_VERSION}
--- a/debian/zfs-dkms.dkms.debhelper
+++ /dev/null
@@ -1,93 +0,0 @@
-BUILD_DEPENDS[0]="spl"
-AUTOINSTALL="yes"
-PACKAGE_NAME="zfs"
-PACKAGE_VERSION="0.7.9"
-PRE_BUILD="configure
-  --prefix=/usr
-  --with-config=kernel
-  --with-linux=$(
-case `lsb_release -is` in
-  (Debian)
-if [[ -e ${kernel_source_dir/%build/source} ]]
-then
-  echo ${kernel_source_dir/%build/source}
-else
-  # A kpkg exception for Proxmox 2.0
-  echo ${kernel_source_dir}
-fi
-  ;;
-  (*)
-echo ${kernel_source_dir}
-  ;;
-esac
-  )
-  --with-linux-obj=${kernel_source_dir}
-  --with-spl=${source_tree}/spl-${PACKAGE_VERSION}
-  --with-spl-obj=${dkms_tree}/spl/${PACKAGE_VERSION}/${kernelver}/${arch}
-  $(
-[[ -r /etc/default/zfs ]] \
-&& source /etc/default/zfs \
-&& shopt -q -s extglob \
-&& \
-{
-  if [[ ${ZFS_DKMS_ENABLE_DEBUG,,} == @(y|yes) ]]
-  then
-echo --enable-debug
-  fi
-  if [[ ${ZFS_DKMS_ENABLE_DEBUG_DMU_TX,,} == @(y|yes) ]]
-  then
-echo --enable-debug-dmu-tx
-  fi
-}
-  )
-  --with-spl-timeout=600
-"
-POST_BUILD="cp
-  ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/zfs_config.h
-  ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/module/Module.symvers
-  ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/${kernelver}/${arch}/
-"
-REMAKE_INITRD="$(
-  if [ -e /usr/share/initramfs-tools/hooks/zfs \
-   -o -e 

Bug#900310: debdiff

[Daniel Watkins]

Attached is a patch which imports an upstream commit that fixes the
offending test.
diff -Nru python-ase-3.16.0/debian/changelog python-ase-3.16.0/debian/changelog
--- python-ase-3.16.0/debian/changelog	2018-04-03 08:24:35.0 -0400
+++ python-ase-3.16.0/debian/changelog	2018-05-28 16:50:14.0 -0400
@@ -1,3 +1,11 @@
+python-ase (3.16.0-2) unstable; urgency=medium
+
+  * debian/patches/fix-broken-ase.db.app-test.patch: [PATCH] Fix broken
+ase.db.app test.  Thanks to Jens Jørgen Mortensen
+.
+
+ -- Daniel Watkins   Mon, 28 May 2018 16:50:14 -0400
+
 python-ase (3.16.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru python-ase-3.16.0/debian/patches/fix-broken-ase.db.app-test.patch python-ase-3.16.0/debian/patches/fix-broken-ase.db.app-test.patch
--- python-ase-3.16.0/debian/patches/fix-broken-ase.db.app-test.patch	1969-12-31 19:00:00.0 -0500
+++ python-ase-3.16.0/debian/patches/fix-broken-ase.db.app-test.patch	2018-05-28 16:49:19.0 -0400
@@ -0,0 +1,54 @@
+From fff2cfc78484044e22ee24bf73d5d1c27bd7f491 Mon Sep 17 00:00:00 2001
+From: Jens Jørgen Mortensen 
+Date: Thu, 3 May 2018 21:50:57 +0200
+Subject: [PATCH] Fix broken ase.db.app test
+
+Has been broken for a long time, but new Flask is now complaining - as it should.
+---
+ ase/test/db/db_web.py | 14 +-
+ 1 file changed, 5 insertions(+), 9 deletions(-)
+
+diff --git a/ase/test/db/db_web.py b/ase/test/db/db_web.py
+index e077b19..1c68d63 100644
+--- a/ase/test/db/db_web.py
 b/ase/test/db/db_web.py
+@@ -1,23 +1,20 @@
+ from ase import Atoms
+ from ase.db import connect
+ import ase.db.app as app
++
+ c = connect('test.db', append=False)
+-plot = {'title': 'A test',
+-'data': [{'label': 't1', 'x': 'x', 'y': 't1'},
+- {'label': 't2', 'style': 'y--',
+-  'x': 'x', 'y': 't2'}],
+-'xlabel': 'x',
+-'ylabel': 'y'}
++
+ x = [0, 1, 2]
+ t1 = [1, 2, 0]
+ t2 = [[2, 3], [1, 1], [1, 0]]
++
+ c.write(Atoms('H2O'),
+ foo=42.0,
+ bar='abc',
+-data={'test': plot,
+-  'x': x,
++data={'x': x,
+   't1': t1,
+   't2': t2})
++
+ c.metadata = {'title': 'Test title',
+   'key_descriptions':
+   {'foo': ('FOO', 'FOO ...', '`m_e`')},
+@@ -30,7 +27,6 @@ page = c.get('/').data.decode()
+ assert 'Test title' in page
+ assert 'FOO' in page
+ c.get('/id/1')
+-c.get('/plot/test-1.png')
+ c.get('json/1').data
+ c.get('sqlite/1').data
+ c.get('sqlite?x=1').data
+--
+libgit2 0.27.0
+
diff -Nru python-ase-3.16.0/debian/patches/series python-ase-3.16.0/debian/patches/series
--- python-ase-3.16.0/debian/patches/series	2018-04-03 07:57:00.0 -0400
+++ python-ase-3.16.0/debian/patches/series	2018-05-28 16:49:19.0 -0400
@@ -1 +1,2 @@
 fix-privacy-breach.patch
+fix-broken-ase.db.app-test.patch

Bug#900307: cmake: Unable to install on unstable due to outdated libcurl3 dependency

[Jaen]

Package: cmake
Severity: normal

Dear Maintainer,

cmake can not be installed together with curl on unstable, because cmake
depends on libcurl3, while curl depends on libcurl4, which conflicts
with libcurl3.

I guess the dependency should be updated?

Result from apt:

> aptitude install cmake
The following NEW packages will be installed:
  cmake cmake-data{a} libcurl3{a} librhash0{a} libuv1{a} 
0 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,508 kB/5,084 kB of archives. After unpacking 25.2 MB will be used.
The following packages have unmet dependencies:
 libcurl4 : Conflicts: libcurl3 but 7.60.0-1 is to be installed
The following actions will resolve these dependencies:

 Remove the following packages:  
1) curl [7.60.0-2 (now, unstable)]   


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

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

Versions of packages cmake depends on:
pn  cmake-data
ii  libarchive13  3.2.2-3.1
ii  libc6 2.27-3
pn  libcurl3  
ii  libexpat1 2.2.5-3
ii  libgcc1   1:8.1.0-3
ii  libjsoncpp1   1.7.4-3
pn  librhash0 
ii  libstdc++68.1.0-3
pn  libuv1
ii  procps2:3.3.15-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages cmake recommends:
ii  gcc   4:7.3.0-3
ii  make  4.2.1-1

Versions of packages cmake suggests:
pn  cmake-doc
ii  ninja-build  1.8.2-1

Bug#900306: vlc: bit sample indicator always on 32 bit with audio files

[Francesco]

Package: src:vlc
Version: 3.0.2-0+deb9u1
Severity: minor

Dear Maintainer,

The bit audio sample indicator in "coder information" always shows "32 bit"
with audio files even with a file that have different bit sampling.


-- System Information:
Debian Release: 9.4
Architecture: amd64 (x86_64)

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

Versions of packages vlc depends on:
ii  dpkg 1.18.24
ii  vlc-bin  3.0.2-0+deb9u1
ii  vlc-l10n 3.0.2-0+deb9u1
ii  vlc-plugin-base  3.0.2-0+deb9u1
ii  vlc-plugin-qt3.0.2-0+deb9u1
ii  vlc-plugin-video-output  3.0.2-0+deb9u1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.2-0+deb9u1
pn  vlc-plugin-samba   
ii  vlc-plugin-skins2  3.0.2-0+deb9u1
ii  vlc-plugin-video-splitter  3.0.2-0+deb9u1
ii  vlc-plugin-visualization   3.0.2-0+deb9u1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc6   2.24-11+deb9u3
ii  libc6-udeb [libc6]  2.19-18+deb8u6
ii  libvlc5 3.0.2-0+deb9u1

Versions of packages libvlc5 depends on:
ii  dpkg1.18.24
ii  libc6   2.24-11+deb9u3
ii  libc6-udeb [libc6]  2.19-18+deb8u6
ii  libvlccore9 3.0.2-0+deb9u1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.2-0+deb9u1

Versions of packages libvlccore8 depends on:
ii  dpkg1.18.24
ii  libc6   2.24-11+deb9u3
ii  libc6-udeb [libc6]  2.19-18+deb8u6
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libidn111.33-1

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.14-2

Versions of packages vlc-bin depends on:
ii  libc6   2.24-11+deb9u3
ii  libc6-udeb [libc6]  2.19-18+deb8u6
ii  libvlc-bin  3.0.2-0+deb9u1
ii  libvlc5 3.0.2-0+deb9u1

Versions of packages vlc-plugin-base depends on:
ii  dpkg 1.18.24
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-2
ii  libasound2   1.1.3-5
ii  libass5  1:0.13.4-2
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.2.10-1~deb9u1
ii  libavformat577:3.2.10-1~deb9u1
ii  libavutil55  7:3.2.10-1~deb9u1
ii  libbasicusageenvironment12016.11.28-1
ii  libbluray1   1:0.9.3-3
ii  libc62.24-11+deb9u3
ii  libc6-udeb [libc6]   2.19-18+deb8u6
ii  libcairo21.14.8-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.0-5
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.4-1
ii  libfaad2 2.8.0~cvs20161113-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libfribidi0  0.19.7-1+b1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgcrypt20  1.7.6-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u3
ii  libgpg-error01.26-2
ii  libgroupsock82016.11.28-1
ii  libharfbuzz0b1.4.2-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.9.4c-9
ii  liblivemedia57   2016.11.28-1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8+deb9u1
ii  libmatroska6v5   1.4.5-2
ii  libmicrodns0 0.0.3-3
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-7+b2
ii  libmpg123-0  1.23.8-1+b1
ii  libmtp9  1.1.13-1
ii  libncursesw5 6.0+20161126-1+deb9u2
ii  libnfs8  1.11.0-2
ii  libogg0  1.3.2-1
ii  libopenmpt-modplug1  0.2.7386~beta20.3-3+deb9u2
ii  libopus0 1.2~alpha2-1
ii  

Bug#898209: charliecloud: Change service by systemd in po-debconf

[Alban Vidal]

Dear Peter,

Le 28/05/2018 à 21:04, Peter Wienemann a écrit :
> how could I decline such a kind offer? :-)
>
> Please feel free to perform the update and create a merge request.

I have sent the merge request.

https://salsa.debian.org/hpc-team/charliecloud/merge_requests/2

Regards,

Alban

Bug#776798: catfish: never stops searching -- doesn't find anything

[Reto Schoch]

Package: catfish
Version: 1.4.4-1
Followup-For: Bug #776798

Dear Maintainer,

I cannot confirm the bug. Catfish runs on my system fine like ever,
i.e. it finds files and closes properly.

-- System Information:
Debian Release: buster/testing
Architecture: amd64 (x86_64)
Kernel: Linux 4.16.0-3-amd64

Bug#900210: thunderbird: Thunderbird AppArmor config disables ability to send entirely

[Carsten Schoenert]

Hello intri, hello Vincas,

this looks like something you guys should have a look at please. Thanks!

@intrigeri
The uploads of TB 52.8.0 to stretch- and jessie-security did have
cherry-picked your reverted commit c33dba2f from unstable so the issue
of the user are not related to this modification I guess.

Am 27.05.2018 um 18:54 schrieb Stephen Dowdy:
> Package: thunderbird
> Version: 1:52.8.0-1~deb9u1
> Severity: important
> 
> 
> Attempting to send e-mail results in a popup:
> 
> [ Send Message Error ]
> Sending of the message failed.
> 
> 
> # aa-status --enabled  && echo "AppArmor Enabled"
> AppArmor Enabled
> 
> # aa-status | egrep '(profiles|thunderbird)'
> 54 profiles are loaded.
> 21 profiles are in enforce mode.
>thunderbird
>thunderbird//browser_java
>thunderbird//browser_openjdk
>thunderbird//gpg
>thunderbird//sanitized_helper
> 33 profiles are in complain mode.
> 6 processes have profiles defined.
>thunderbird (32689) 
> 
> 
> dmesg shows the following apparmor DENIED messages:
> 
> [62711.954571] audit: type=1400 audit(1527437094.186:58): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/run/user/1000/xauth-1000-_0" pid=32700 comm="thunderbird" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> [62711.960341] audit: type=1400 audit(1527437094.194:59): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> [62711.971343] audit: type=1400 audit(1527437094.202:60): 
> apparmor="DENIED" operation="mkdir" profile="thunderbird" 
> name="/run/user/1000/thunderbird_sdowdy/" pid=32689 comm="thunderbird" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [62711.971925] audit: type=1400 audit(1527437094.206:61): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> [62712.747197] audit: type=1400 audit(1527437094.978:62): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> [62712.895221] audit: type=1400 audit(1527437095.126:63): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/etc/xdg/mimeapps.list" pid=32689 comm="thunderbird" requested_mask="r" 
> denied_mask="r" fsuid=1000 ouid=0
> [63310.628483] audit: type=1400 audit(1527437692.863:64): 
> apparmor="DENIED" operation="mknod" profile="thunderbird" 
> name="/run/user/1000/nsemail.eml" pid=32689 comm="thunderbird" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [63310.671468] audit: type=1400 audit(1527437692.907:65): 
> apparmor="DENIED" operation="open" profile="thunderbird" 
> name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" 
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> 
> $ env | grep /run/user
> TMPDIR=/run/user/1000/
> GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
> DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
> XDG_RUNTIME_DIR=/run/user/1000
> XAUTHORITY=/run/user/1000/xauth-1000-_0
> 
> I suspect because i explicitly set TMPDIR to XDG_RUNTIME_DIR (something that 
> should be pretty normal, even better than using /tmp, IMHO), that AppArmor 
> should allow for this.
> (i'm not entirely sure that's the issue, but it seems likely)
> 
> 
> Also, for general purposes...
> I did choose to allow/use maintainer's version of AppArmor configuration in 
> the recent update, however, i think you should respect the existing 
> enforce/complain/disable state of the user's system, as i'd previously done:
> 
> aa-complain /etc/apparmor.d/usr.bin.thunderbird 
> (which i am back to now in order to keep working)
> 
> 
> thanks,
> --stephen
> 
> 
> -- System Information:
> Debian Release: 9.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.16.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 thunderbird depends on:
> ii  debianutils   4.8.1.1
> ii  fontconfig2.11.0-6.7+b1
> ii  libatk1.0-0   2.22.0-1
> ii  libc6 2.24-11+deb9u3
> ii  libcairo-gobject2 1.14.8-1
> ii  libcairo2 1.14.8-1
> ii  libdbus-1-3   1.10.26-0+deb9u1
> ii  libdbus-glib-1-2  0.108-2
> ii  libevent-2.0-52.0.21-stable-3
> ii  libffi6   3.2.1-6
> ii  libfontconfig12.11.0-6.7+b1
> ii  libfreetype6  2.6.3-3.2
> 

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Marc]

Package: nvidia-driver
Version: 390.59-1
Followup-For: Bug #900248

Dear Maintainer,

I have the exact same issue. I've spent few hours trying to install/reinstall 
all nvidia package until I've found this bug.
I've also tried to create package from the 396 svn version, but was not able to 
create all i386 packages.

Happy to test anything if it can help in any way

Marc

-- Package-specific info:
uname -a:
Linux arrakis 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 
GNU/Linux

/proc/version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.59  Wed May  9 22:33:42 PDT 
2018
GCC version:  gcc version 7.3.0 (Debian 7.3.0-19) 

lspci 'display controller [030?]':
09:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 
670] [10de:1189] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GK104 [GeForce GTX 670] [1043:841b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 May 28 08:23 /dev/dri/card0
crw-rw+ 1 root video 226, 128 May 28 08:23 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 May 28 08:23 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 May 28 08:23 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 May 28 08:23 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 May 28 08:23 pci-:09:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 May 28 08:23 pci-:09:00.0-render -> ../renderD128
video:x:44:dkm

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 May 28 20:42 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   47 May 27 22:29 
/etc/alternatives/glx--libEGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   49 May 27 22:29 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   49 May 28 20:42 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   51 May 28 20:42 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   46 May 27 22:29 
/etc/alternatives/glx--libGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   46 May 27 22:29 
/etc/alternatives/glx--libGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 May 27 22:29 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 May 27 22:29 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 May 28 20:42 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 May 28 20:42 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 May 28 20:42 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 May 28 20:42 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 May 27 22:29 
/etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   50 May 27 22:29 
/etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 May 27 22:29 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 May 27 22:29 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 May 28 20:42 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   52 May 28 20:42 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 May 28 20:42 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 May 28 20:42 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 

Bug#888353: moc: FTBFS with FFmpeg 3.5

[James Cowgill]

Control: tags -1 patch

Hi,

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> Source: moc
> Version: 1:2.6.0~svn-r2949-2
> Severity: important
> User: debian-multime...@lists.debian.org
> Usertags: ffmpeg-3.5-transition
> 
> Hi,
> 
> Your package FTBFS with the upcoming version 3.5 of FFmpeg.

The attached patch fixes this.

James
Description: Fix FTBFS with FFmpeg 4.0
Author: James Cowgill 
Bug-Debian: https://bugs.debian.org/888353
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/decoder_plugins/ffmpeg/ffmpeg.c
+++ b/decoder_plugins/ffmpeg/ffmpeg.c
@@ -697,7 +697,7 @@ static void *ffmpeg_open_internal (struc
 	 * FFmpeg/LibAV in use.  For some versions this will be caught in
 	 * *_find_stream_info() above and misreported as an unfound codec
 	 * parameters error. */
-	if (data->codec->capabilities & CODEC_CAP_EXPERIMENTAL) {
+	if (data->codec->capabilities & AV_CODEC_CAP_EXPERIMENTAL) {
 		decoder_error (>error, ERROR_FATAL, 0,
 "The codec is experimental and may damage MOC: %s",
 data->codec->name);
@@ -705,8 +705,8 @@ static void *ffmpeg_open_internal (struc
 	}
 
 	set_downmixing (data);
-	if (data->codec->capabilities & CODEC_CAP_TRUNCATED)
-		data->enc->flags |= CODEC_FLAG_TRUNCATED;
+	if (data->codec->capabilities & AV_CODEC_CAP_TRUNCATED)
+		data->enc->flags |= AV_CODEC_FLAG_TRUNCATED;
 
 	if (avcodec_open2 (data->enc, data->codec, NULL) < 0)
 	{
@@ -725,7 +725,7 @@ static void *ffmpeg_open_internal (struc
 
 	data->sample_width = sfmt_Bps (data->fmt);
 
-	if (data->codec->capabilities & CODEC_CAP_DELAY)
+	if (data->codec->capabilities & AV_CODEC_CAP_DELAY)
 		data->delay = true;
 	data->seek_broken = is_seek_broken (data);
 	data->timing_broken = is_timing_broken (data->ic);


signature.asc
Description: OpenPGP digital signature

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Luca Boccassi]

On Mon, 2018-05-28 at 21:32 +0900, Norbert Preining wrote:
> > Looks like the kernel module fails to load:
> 
> No, that is the usual artifact with newer kernels, this is well
> known. I
> am running the latest stable kernels normally, currently 4.16.11
> (actually .12 is out), and that has been the case since the 4.15
> series
> (AFAIR). I downgraded all the nvidia stuff to 390.48-3 and with the
> same
> kernel (and the same error message of the kernel) all works back fine
> as
> normal:
> 
> [   13.240792] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
> [   13.265609] nvidia-modeset: Allocated GPU:0 (GPU-ae45f56a-df50-
> cbc7-737d-a20dd48d7bdd) @ PCI::01:00.0
> [   13.409365] [ cut here ]
> [   13.409369] Bad or missing usercopy whitelist? Kernel memory
> exposure attempt detected from SLAB object 'nvidia_stack_cache'
> (offset 11440, size 3)!
> [   13.409375] WARNING: CPU: 2 PID: 1168 at mm/usercopy.c:81
> usercopy_warn+0x7d/0xa0
> ...
> 
> # glxinfo | grep OpenGL
> ...
> OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2
> OpenGL core profile version string: 4.6.0 NVIDIA 390.48
> ...
> 
> My suspect is that (from aptitude.log):
> [REMOVE] libgles1-glvnd-nvidia:amd64 390.48-3
> [REMOVE] libgles1-glvnd-nvidia:i386 390.48-3
> two package which seem to be not available or installable in sid at
> the
> moment.
> 
> Best
> 
> Norbert

Nah gles1 is deprecated - I don't have it either on my sid+gnome
installation, and yet everything works just fine.

Have you done a selective upgrade by any chance? Are mesa and xorg all
up to date? Is anything pinned?

-- 
Kind regards,
Luca Boccassi

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

Bug#900066: gitlab: 500 error on merge request creation

[Simon Vetter]

Thanks.

I applied the update earlier this morning and can confirm that the bug 
is fixed.


Cheers,

-Simon

--
Simon Vetter
Embedded Software Engineer - EDF store & forecast
Phone: +33 7 83 40 26 11

On 05/26/2018 03:36 PM, Salvatore Bonaccorso wrote:

Hi,

On Sat, May 26, 2018 at 06:25:40PM +0530, Pirate Praveen wrote:

On Saturday 26 May 2018 03:34 PM, Simon Vetter wrote:

Awesome, thank you for your prompt reply.

In the meantime and assuming the fix is in non-compiled code (i.e.
ruby), would you mind sharing a patch here so I can apply it and get
merge requests up and running again?

Sure, here is the patch.

https://salsa.debian.org/ruby-team/gitlab/commit/cfdebd5834791b9152dc32af10a63b8db6ddbab9

The regression update (DSA-4206-2) has been issued and the packages
available on the security mirrors.

Regards,
Salvatore

Bug#900305: Please add Recommends: elpa-imenu-list to enable document structure sidebar

[Nicholas D Steeves]

Source: markdown-mode
Version: 2.3+154-1
Severity: normal

Hi,

I just noticed that markdown-mode prominently advertises support for
imenu-list sidebars that display document structure
  https://jblevins.org/projects/markdown-mode/
  https://jblevins.org/projects/markdown-mode/screenshots/20170818-001.png

and in my opinion that is an upstream recommendation for imenu-list.  
Regrettably the project doesn't document how to replicate this layout, other 
than noting

  * markdown-nested-imenu-heading-index - Use nested imenu heading
instead of a flat index (default: t). A nested index may provide
more natural browsing from the menu, but a flat list may allow for
faster keyboard navigation via tab completion.

  * markdown-add-footnotes-to-imenu - Add footnote definitions to the
end of the imenu index (default: t).

in their README.md.

I'd be happy to commit the change to debian/control, and/or filing a
PR with upstream about documenting how to reproduce this layout.

Cheers,
Nicholas

Bug#900203: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory

[Helmut Grohne]

On Mon, May 28, 2018 at 02:07:00PM -0500, Rob Browning wrote:
> Hmm, I cannot reproduce that here in a 2.2.3+1-4 git tree via:
> 
>   DEB_BUILD_PROFILES="cross nocheck" \
>   DEB_BUILD_OPTIONS="parallel=2 nocheck" \
>   nice fakeroot dpkg-architecture -amipsel -c dpkg-buildpackage -B
> 
> on an amd64 machine that's somewhere between stretch and buster.  I lost
> the log (I can retry if it seems advisable), but at the end it didn't
> appear to be building anything mipsel-related.

I'm sorry, I don't usually build with dpkg-buildpackage directly and
thus I messed up the instructions. dpkg-buildpackage has its own
--host-arch switch. Please try:

  DEB_BUILD_PROFILES="cross nocheck" \
  DEB_BUILD_OPTIONS="parallel=2 nocheck" \
  nice fakeroot dpkg-buildpackage -B --host-arch=mipsel

> Any thoughts about what might be best to try next?

Initially, I thought the failure was 100% reproducible for any
architecture. That doesn't seem to be the case. Let me try building
guile-2.2 for most release architecture with sbuild:

arm64: successful
armel: ftcbfs, ftcbfs
armhf: ftcbfs, ftcbfs
mips: multiarch skew linux-libc-dev
mips64el: successful
mipsel: multiarch skew linux-libc-dev
powerpc: ftcbfs, ftcbfs
ppc64el: successful
s390x: ftcbfs

I ran each ftcbfs build twice to rule out the possibility of a random
ftcbfs. So we have a non-random ftcbfs for some architectures. I'm a bit
surprised about s390x here as it is the only failing 64bit architecture.

Hope this helps

Helmut

Bug#898631: thunderbird: efail attack against S/MIME and PGP/MIME

[Carsten Schoenert]

Control: retitle 898631 thunderbird: still efail attack issue possible
against S/MIME and PGP/MIME in some circumstances


Hi again,

Am 27.05.2018 um 10:04 schrieb intrigeri:
> Hi Thunderbird maintainers!
> 
> My understanding (by reading some Thunderbird upstream mailing lists)
> is that 52.8.0 only has part of the EFAIL fixes and the remaining
> fixes will go into 52.8.1.

that's correct, unfortunately.

> So perhaps this bug should not be marked as fixed in 1:52.8.0-1?
> Or are the remaining problems tracked on another bug report that
> I could not find?

No, right now there is no other issue to track this. I had finished all
my work on TB 52.8.0 before it was clear that the Efail thing isn't
fully fixed bu 52.8.0.

I wouldn't like to reopen the previous bug report and just use this one
here to keep tracking the remaining issue. Hopefully Mozilla will do a
release of 52.8.1 next week.

-- 
Regards
Carsten Schoenert

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[George Shuklin]

Package: nvidia-driver
Version: 390.59-1
Followup-For: Bug #900248

I confirm this problem. I got it at upgrade from sid to sid, unfortunately, I
lost exact version change. Now I can reproduce it with upgrade between testing
and sid.
390.48-3 is working
390.59-1 is broken

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX
660 Ti] [10de:1183] (rev a1) (prog-if 00 [VGA controller])
...
Kernel driver in use: nvidia
Kernel modules: nvidia




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

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

Versions of packages nvidia-driver depends on:
ii  nvidia-alternative 390.59-1
ii  nvidia-driver-bin  390.59-1
ii  nvidia-driver-libs 390.59-1
ii  nvidia-installer-cleanup   20151021+8
ii  nvidia-kernel-dkms [nvidia-kernel-390.59]  390.59-1
ii  nvidia-legacy-check390.59-1
ii  nvidia-support 20151021+8
ii  nvidia-vdpau-driver390.59-1
ii  xserver-xorg-video-nvidia  390.59-1

Versions of packages nvidia-driver recommends:
ii  nvidia-persistenced  390.25-1
ii  nvidia-settings  390.48-2

Versions of packages nvidia-driver suggests:
ii  nvidia-kernel-dkms  390.59-1

Versions of packages nvidia-driver-libs:amd64 depends on:
ii  libgl1-nvidia-glvnd-glx  390.59-1
ii  nvidia-egl-icd   390.59-1

Versions of packages nvidia-driver-libs:amd64 recommends:
ii  libgles-nvidia2  390.59-1
ii  libglx-nvidia0   390.59-1
ii  libnvidia-cfg1   390.59-1
ii  libopengl0   1.0.0+git20180308-2
pn  nvidia-driver-libs-i386  
ii  nvidia-egl-wayland-icd   390.59-1
ii  nvidia-vulkan-icd390.59-1

Versions of packages xserver-xorg-video-nvidia depends on:
ii  libc6  2.27-3
ii  libnvidia-glcore   390.59-1
ii  nvidia-alternative 390.59-1
ii  nvidia-installer-cleanup   20151021+8
ii  nvidia-legacy-check390.59-1
ii  nvidia-support 20151021+8
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.0-2

Versions of packages xserver-xorg-video-nvidia recommends:
ii  nvidia-kernel-dkms [nvidia-kernel-390.59]  390.59-1
ii  nvidia-settings390.48-2
ii  nvidia-vdpau-driver390.59-1

Versions of packages xserver-xorg-video-nvidia suggests:
ii  nvidia-kernel-dkms  390.59-1

Versions of packages nvidia-alternative depends on:
ii  dpkg1.19.0.5+b1
ii  glx-alternative-nvidia  0.8.3
ii  nvidia-legacy-check 390.59-1

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   2.3-3
ii  nvidia-installer-cleanup   20151021+8
ii  nvidia-kernel-support [nvidia-kernel-support--v1]  390.59-1

nvidia-kernel-dkms recommends no packages.

Versions of packages glx-alternative-nvidia depends on:
ii  dpkg  1.19.0.5+b1
ii  glx-alternative-mesa  0.8.3
ii  glx-diversions0.8.3
ii  update-glx0.8.3

glx-alternative-nvidia suggests no packages.

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.27-3
ii  libdrm-intel1  2.4.92-1
ii  libdrm22.4.92-1
ii  libpciaccess0  0.14-1
ii  libpixman-1-0  0.34.0-2
ii  libudev1   238-5
ii  libx11-6   2:1.6.5-1
ii  libx11-xcb12:1.6.5-1
ii  libxcb-dri2-0  1.13-1
ii  libxcb-dri3-0  1.13-1
ii  libxcb-sync1   1.13-1
ii  libxcb-util0   0.3.8-3+b2
ii  libxcb11.13-1
ii  libxcursor11:1.1.15-1
ii  libxdamage11:1.1.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxinerama1   2:1.1.3-1+b3
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxshmfence1  1.3-1
ii  libxss11:1.2.2-1+b2
ii  libxtst6   2:1.2.3-1
ii  libxv1 2:1.0.11-1
ii  libxvmc1   2:1.0.10-1
ii  

Bug#873327: aegisub FTBFS with luajit 2.1

[Bruno Perel]

The patch was merged in the Github repo :
https://github.com/Aegisub/Aegisub/pull/48 .

Bug#732796: Please remove the link from open to openvt

[Andreas Henriksson]

Hello Vitezslav Crhonek,

Gürkan Myczko sent the below forwarded message to fedora devel list
in May 2017, but it seems there was no followup so I'm trying
sending it directly to you as you seem to be the one who has
been actively committing to the kbd package in fedora.

In summary, some people would like to se "open" command be used
for a different purpose than the current decades old compatibility
link. Personally I think if/when the link is removed we should make
sure it's not reused for anything for multiple releases/years to avoid
confusion about it pointing to different things in different
things in different distros.

What do you think? Is it doable to drop it in Fedora?

I'd be willing to drop it in Debian which should trickle down to
all derived .deb based distros. Hopefully if you change Fedora
the rest of the .rpm world will follow suite. This should make
the change pretty universal I think and avoid deviating between
different distros.

Regards,
Andreas Henriksson



- Forwarded message from Gürkan Myczko  -

Date: Wed, 17 May 2017 14:00:52 +0200
From: Gürkan Myczko 
To: de...@lists.fedoraproject.org
Cc: 732...@bugs.debian.org
Subject: Please remove the link from open to openvt
User-Agent: Roundcube Webmail/1.2.5

Hello,

First, I have no relation to Fedora, but I write here because of this bug in
Debian:

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

Would you guys at Fedora feel like it's time to get rid of the symlink
/bin/open to make space for
xdg-open (for fdo fans) or gopen/openapp (for macOS, GNUstep fans).

The name change was like 16 years ago. And I wasn't able to find anything
still using /bin/open.

Thanks,
Myczko


- End forwarded message -

Bug#763910: the last version of xdrawchem does is no longer buggy

[Georges Khaznadar]

Hello, the new version of xdrawchem is now based only on a maintained
development tree (version 1.10), and the bug about undesired text exists
no longer.

I shall close the bugs related to this issue.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#872623: kbd: setmetamode fails with StackSmashing detected

[Andreas Henriksson]

Control: forwarded -1 https://github.com/legionus/kbd/pull/16
Control: tags -1 + upstream

Hello,

Sorry for the late followup.

On Sat, Aug 19, 2017 at 04:08:50PM -0400, alsau...@pragmasoft.com wrote:
[...]
> Upon closer examination, it appears that the KDGKBMETA IOCTL that
> is called by setmetamode.c, is subsequently calling:
>put_user (, (int __user*) arg);
> 
> Unfortunately, the argument (ometa) is only declared as "char" in
> setmetamode.c.  So, in essence, we are asking the kernel to store
> an  into a user space location that has only been
> allocated as a "char".
> 
> I now believe that the appropriate correction is to change the
> "char ometa, nmeta;" declaration in setmetamode.c to
> "unsigned int ometa, nmeta;".  During my testing, this change
> eliminated the StackSmashing detection and subsequent traceback.
[...]

I agree with your analysis. Would be best to discuss this issue
upstream, but since the fix seemed obvious I went ahead and
submitted https://github.com/legionus/kbd/pull/16

Thanks for your detailed bug report and analysis.

Regards,
Andreas Henriksson

Bug#888356: retroarch: FTBFS with FFmpeg 3.5

[James Cowgill]

Control: forwarded -1 https://github.com/libretro/RetroArch/pull/5733
Control: tags -1 fixed-upstream

Hi,

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> Source: retroarch
> Version: 1.3.6+dfsg1-1
> Severity: important
> User: debian-multime...@lists.debian.org
> Usertags: ffmpeg-3.5-transition
> 
> Hi,
> 
> Your package FTBFS with the upcoming version 3.5 of FFmpeg.

This was fixed upstream in retroarch 1.6.9 by the above pull request.

James



signature.asc
Description: OpenPGP digital signature

Bug#900176: [PKG-Openstack-devel] Bug#900176: tripleo-heat-templates: CVE-2017-12155

[Salvatore Bonaccorso]

Hi Thomas,

On Mon, May 28, 2018 at 05:04:06PM +0200, Salvatore Bonaccorso wrote:
> Hi Thomas,
> 
> On Mon, May 28, 2018 at 03:08:52PM +0200, Moritz Muehlenhoff wrote:
> > On Mon, May 28, 2018 at 02:41:28PM +0200, Thomas Goirand wrote:
> > > I don't think anyone can even use tripleo-heat-templates in Debian, as
> > > we don't have a working TripleO anyway. I just asked for its removal
> > > form Sid. Therefore, I don't really feel like spending the time on
> > > fixing this will be remotely useful.
> > > 
> > > In this kind of situation, shall we simply close the bug?
> > 
> > Removal from unstable will close this bug automatically, so you
> > don't need to do anything :-)
> 
> Ack on the above, so please leave it open (because technically the bug
> is there).
> 
> But given the reason you brough: would it be sensible to remove it as
> well from stable (on next point release)? If it has not rdepdendencies
> then you can just ask for removal by filling a bug against
> release.d.o.

Aehm, nevermind it's not in stable. So nothing has to be done
further (I seem to have gotten confused).

Regards,
Salvatore

Bug#898209: charliecloud: Change service by systemd in po-debconf

[Peter Wienemann]

On 27.05.2018 21:23, Alban Vidal wrote:> If you whant, i can update by
myself and create merge request.

Dear Alban,
how could I decline such a kind offer? :-)

Please feel free to perform the update and create a merge request.

Cheers, Peter

Bug#900203: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory

[Rob Browning]

Helmut Grohne  writes:

> There are a number of ways to reproduce:
>  * pbuilder --host-arch mipsel guile-2.2_*.dsc
>  * sbuild --host=mipsel --add-depends=libc-dev,libstdc++-dev
>--profiles=cross,nocheck
>(That --add-depends is necessary, because #815172.)
>  * DEB_BUILD_PROFILES="cross nocheck" DEB_BUILD_OPTIONS=nocheck
>dpkg-architecture -amipsel -c dpkg-buildpackage -B

Hmm, I cannot reproduce that here in a 2.2.3+1-4 git tree via:

  DEB_BUILD_PROFILES="cross nocheck" \
  DEB_BUILD_OPTIONS="parallel=2 nocheck" \
  nice fakeroot dpkg-architecture -amipsel -c dpkg-buildpackage -B

on an amd64 machine that's somewhere between stretch and buster.  I lost
the log (I can retry if it seems advisable), but at the end it didn't
appear to be building anything mipsel-related.

Any thoughts about what might be best to try next?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#900301: libcurl4 and libcurl3 cannot coeixst, which breaks php

[Nye Liu]

Package: curl
Version: 7.60.0-2
Severity: critical
Justification: breaks the whole system

libcurl3 and libcurl4 cannot coexist, which breaks php (among quite a
few other packages):

The following NEW packages will be installed:
  curl libcurl4{ab}
0 packages upgraded, 2 newly installed, 0 to remove and 982 not upgraded.
Need to get 254 kB/570 kB of archives. After unpacking 1,074 kB will be used.
The following packages have unmet dependencies:
 libcurl4 : Conflicts: libcurl3 but 7.60.0-1 is installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) apache2 [2.4.33-3 (now, unstable)]
2) apache2-bin [2.4.33-3 (now, unstable)]
3) libapache2-mod-php [1:7.2+61 (now, unstable)]
4) libapache2-mod-php7.2 [7.2.4-1+b1 (now, unstable)]
5) libcurl3 [7.60.0-1 (now, unstable)]
6) php-curl [1:7.2+61 (now, unstable)]
7) php7.2-curl [7.2.4-1+b1 (now, unstable)]

This means that curl 7.60 is uninstallable unles you break the system.

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

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

Versions of packages curl depends on:
ii  libc6 2.27-3
ii  libcurl4  7.60.0-2
ii  zlib1g1:1.2.11.dfsg-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#900304: flask-cache: Incomplete debian/copyright?

[Chris Lamb]

Source: flask-cache
Version: 0.13.1-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Jelmer Vernooij 

Hi,

I just ACCEPTed flask-cache from NEW but noticed it was missing 
attribution in debian/copyright for at least the Sphinx theme and
(possibly) flask_cache/_compat.py.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload. :)


Regards,

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

Bug#866652: runit: Should depend on runit-(systemd|sysv) to be present

[KAction]

[2018-02-22 13:13] chrysn 
> part 1 text/plain 473
> Package: runit
> Version: 2.1.2-9.2
> Followup-For: Bug #866652
> 
> Hello Dmitry,
> 
> If this is implemented (which I think is a good idea), please implement
> it in a way that users of runit as PID 1 can also satisfy the
> dependency, eg. by making the dependency "runit-systemd | runit-any"
> where runit-any is virtual and provided by runit-systemd, runit-sysv,
> and users of runit-init can make it "Provides: runit-any" even if a
> runit-init does not come back to Debian.

I am considering

Recommends: runit-sysv | runit-init | runit-systemd

but, since runit-init /depends/ on runit, it feels almost like loop. Am
I correct, that this is bad thing?

Bug#900248: More Information

[Dean Loros]

I did not have: [REMOVE] libgles1-glvnd-nvidia:amd64 390.48-3 [REMOVE]
libgles1-glvnd-nvidia:i386 390.48-3 in my upgrade to 390.59.

Upgrade: xserver-xorg-video-vesa:amd64 (1:2.3.4-1+b2, 1:2.3.4-1+b3),
libcuda1-i386:i386 (390.48-3, 390.59-1), libgles-nvidia2:amd64 (390.48-3,
390.59-1), libgles-nvidia2:i386 (390.48-3, 390.59-1), libnvidia-ml1:amd64
(390.48-3, 390.59-1), nvidia-vulkan-icd:amd64 (390.48-3, 390.59-1),
nvidia-vulkan-icd:i386 (390.48-3, 390.59-1), nvidia-driver-libs-i386:i386
(390.48-3, 390.59-1), xserver-xorg-core:amd64 (2:1.19.6-1, 2:1.20.0-2),
nvidia-egl-icd:amd64 (390.48-3, 390.59-1), nvidia-egl-icd:i386 (390.48-3,
390.59-1), nvidia-driver:amd64 (390.48-3, 390.59-1),
xserver-xorg-video-fbdev:amd64 (1:0.4.4-1+b5, 1:0.4.4-1+b6),
nvidia-vulkan-common:amd64 (390.48-3, 390.59-1), nvidia-vdpau-driver:amd64
(390.48-3, 390.59-1), libgl1-nvidia-glvnd-glx:amd64 (390.48-3, 390.59-1),
libgl1-nvidia-glvnd-glx:i386 (390.48-3, 390.59-1), libglx-nvidia0:amd64
(390.48-3, 390.59-1), libglx-nvidia0:i386 (390.48-3, 390.59-1),
nvidia-smi:amd64 (390.48-3, 390.59-1), libnvidia-egl-wayland1:amd64
(390.48-3, 390.59-1), libnvidia-egl-wayland1:i386 (390.48-3, 390.59-1),
nvidia-detect:amd64 (390.48-3, 390.59-1), nvidia-kernel-dkms:amd64
(390.48-3, 390.59-1), libegl-nvidia0:amd64 (390.48-3, 390.59-1),
libegl-nvidia0:i386 (390.48-3, 390.59-1), nvidia-egl-common:amd64
(390.48-3, 390.59-1), libnvidia-ptxjitcompiler1:amd64 (390.48-3, 390.59-1),
libnvidia-ptxjitcompiler1:i386 (390.48-3, 390.59-1), libnvidia-cfg1:amd64
(390.48-3, 390.59-1), libnvidia-cfg1:i386 (390.48-3, 390.59-1),
nvidia-legacy-check:amd64 (390.48-3, 390.59-1), nvidia-opencl-common:amd64
(390.48-3, 390.59-1), nvidia-egl-wayland-icd:amd64 (390.48-3, 390.59-1),
nvidia-egl-wayland-icd:i386 (390.48-3, 390.59-1),
libnvidia-fatbinaryloader:amd64 (390.48-3, 390.59-1),
libnvidia-fatbinaryloader:i386 (390.48-3, 390.59-1),
nvidia-kernel-support:amd64 (390.48-3, 390.59-1), libnvidia-compiler:amd64
(390.48-3, 390.59-1), nvidia-driver-libs:amd64 (390.48-3, 390.59-1),
nvidia-driver-libs:i386 (390.48-3, 390.59-1), nvidia-driver-bin:amd64
(390.48-3, 390.59-1), xserver-xorg-video-nvidia:amd64 (390.48-3, 390.59-1),
libcuda1:amd64 (390.48-3, 390.59-1), libcuda1:i386 (390.48-3, 390.59-1),
nvidia-egl-wayland-common:amd64 (390.48-3, 390.59-1),
libnvidia-glcore:amd64 (390.48-3, 390.59-1), libnvidia-glcore:i386
(390.48-3, 390.59-1), libnvidia-eglcore:amd64 (390.48-3, 390.59-1),
libnvidia-eglcore:i386 (390.48-3, 390.59-1), libxslt1.1:amd64 (1.1.32-1,
1.1.32-2), libxslt1.1:i386 (1.1.32-1, 1.1.32-2), nvidia-opencl-icd:amd64
(390.48-3, 390.59-1), nvidia-alternative:amd64 (390.48-3, 390.59-1)
End-Date: 2018-05-26  19:58:51

I also have a Google Drive link to the nvidia-bug-report.log
 nvidia-bug-report.log

I am still running 390.59, so am ready to try changes --
Cheers!!!
Dean Loros
Performance by Design Ltd.
autocrosser at http://forums.linuxmint.com
dean@debian:~$ glxgears
3755 frames in 5.0 seconds = 750.255 FPS
4040 frames in 5.0 seconds = 807.917 FPS
4306 frames in 5.0 seconds = 860.307 FPS
4284 frames in 5.0 seconds = 856.658 FPS
4281 frames in 5.0 seconds = 856.183 FPS
4300 frames in 5.0 seconds = 859.959 FPS
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
  after 79675 requests (79673 known processed) with 0 events remaining.

Bug#900302: FTBFS: bitrot

[Clint Adams]

Source: gitit
Version: 0.12.2.1-1
Severity: serious

gitit needs patching for newer dependencies (feed in particular)

Bug#900286: ITP: spm -- simple password manager

[Jakub Wilk]

* Paride Legovini , 2018-05-28, 17:33:

spm is a single fully POSIX shell compliant script


Somehow these kind of grandiose claims are never true.

This script:
- has a shebang[0];
- passes -G to grep (not in POSIX);
- uses readlink(1) (not in POSIX).

But anyway, this is an implementation detail, so I don't think it 
belongs to the package description.



with basic tools such as find(1) and tree(1).


find(1) is in POSIX, so I'm not sure it was mentioned explicitly.
tree(1) is not "basic". It's obscure.

Passwords are stored as GPG encrypted files with directories funtioning 
as (sub)groups.


Typo: funtioning -> functioning


In Debian the script will be installed as 'spm.sh'


That would be against Policy §10.4.
Please talk to upstream about choosing a different name.


[0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
“If the first line of a file of shell commands starts with the 
characters "#!", the results are unspecified.”


--
Jakub Wilk

Bug#763989: bug fixed in the last version

[Georges Khaznadar]

Hello, the undo commands seem to do the job.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#900303: latencytop FTCBFS: upstream build system hard codes build architecture build tools

[Helmut Grohne]

Source: latencytop
Version: 0.5
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

latencytop fails to cross build from source, because the upstream build
system hard codes build architecture build tools. The attached patch
makes them substitutable and cdbs substitutes them, so it makes
latencytop cross build successfully. Please consider applying it.
Regarding your question "FIXME: Use autoconf?" I can say that autoconf
would most likely have avoided this bug report.

Helmut
diff --minimal -Nru latencytop-0.5/Makefile latencytop-0.5+nmu1/Makefile
--- latencytop-0.5/Makefile	2018-05-28 20:41:44.0 +0200
+++ latencytop-0.5+nmu1/Makefile	2018-05-28 20:40:37.0 +0200
@@ -1,16 +1,17 @@
 # FIXME: Use autoconf ?
 HAS_GTK_GUI = 1
 
+PKG_CONFIG ?= pkg-config
 DESTDIR =
 SBINDIR = /usr/sbin
-XCFLAGS = -W  -g `pkg-config --cflags glib-2.0` -D_FORTIFY_SOURCE=2 -Wno-sign-compare -I/usr/include/ncursesw
-LDF = -Wl,--as-needed `pkg-config --libs glib-2.0`   -lncursesw 
+XCFLAGS = -W  -g `$(PKG_CONFIG) --cflags glib-2.0` -D_FORTIFY_SOURCE=2 -Wno-sign-compare -I/usr/include/ncursesw
+LDF = -Wl,--as-needed `$(PKG_CONFIG) --libs glib-2.0`   -lncursesw 
 
 OBJS= latencytop.o text_display.o translate.o fsync.o
 
 ifdef HAS_GTK_GUI
-  XCFLAGS += `pkg-config --cflags gtk+-2.0` -DHAS_GTK_GUI
-  LDF += `pkg-config --libs gtk+-2.0`
+  XCFLAGS += `$(PKG_CONFIG) --cflags gtk+-2.0` -DHAS_GTK_GUI
+  LDF += `$(PKG_CONFIG) --libs gtk+-2.0`
   OBJS += gtk_display.o 
 endif
 
@@ -26,10 +27,10 @@
 
 # We write explicity this "implicit rule"
 %.o : %.c
-	gcc -c $(CFLAGS) $(XCFLAGS) $< -o $@
+	$(CC) -c $(CFLAGS) $(XCFLAGS) $< -o $@
 
 latencytop:  $(OBJS) latencytop.h Makefile
-	gcc $(CFLAGS) $(OBJS) $(LDF) -o latencytop 
+	$(CC) $(CFLAGS) $(OBJS) $(LDF) -o latencytop 
 
 clean:
 	rm -f *~ latencytop DEADJOE *.o

Bug#513062:

[SCOTT STEINBERG]

unblocked please

Bug#900239: libprocps-dev: symlink to libprocps.so broken in /usr/lib

[Sven Joachim]

Control: tags -1 + patch

On 2018-05-27 23:43 +0200, Stanislaw Halik wrote:

> Package: libprocps-dev
> Version: 2:3.3.15-1
> Severity: normal
>
> Hey,
>
> The libprocps-dev package depends on `libprocps7' but contains a broken
> symlink to `libprocps.so.6' in the /usr/lib search path.
>
> Otherwise the compiler picks up `libprocps.a' from the same directory,
> that fails since it's not built with -fPIC.

This actually makes packages FTBFS, but even if that were not the case
the severity bump to "serious" was correct I think.

> I believe the original intention was to have a non-broken symlink to
> `libprocps.so.7'.

Indeed, trivial patch attached.  Ideally such mistakes should be caught
at build time, but I am not quite sure how to best achieve that.  The
only advice I can give is to run adequate(1) on the installed packages
which reports such broken symlinks, which might also be done in an
autopkgtest[1].

Cheers,
   Sven


1. https://bugs.debian.org/743198

diff --git a/debian/libprocps-dev.links b/debian/libprocps-dev.links
index ee8758e..4f49c17 100755
--- a/debian/libprocps-dev.links
+++ b/debian/libprocps-dev.links
@@ -1,2 +1,2 @@
 #! /usr/bin/dh-exec
-lib/${DEB_HOST_MULTIARCH}/libprocps.so.6 usr/lib/${DEB_HOST_MULTIARCH}/libprocps.so
+lib/${DEB_HOST_MULTIARCH}/libprocps.so.7 usr/lib/${DEB_HOST_MULTIARCH}/libprocps.so

Bug#279602: bug no longer found in the new version

[Georges Khaznadar]

Hello,

the file tixwidgets.tcl exists no longer in the newest package. Hence, I
consider to close this bug report.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#894371: gdcm FTBFS with openjdk-9

[Emilio Pozuelo Monfort]

Control: retitle -1 gdcm: depends on openjdk-8

On Sun, 29 Apr 2018 10:18:08 +0200 Gert Wollny  wrote:
> >As a workaround to let the poppler transition complete in raspbian I
> >whipped up a version of the package that forces openjdk-8.
> 
> I intend to do the same, 

Retitling for the current scope of the bug: openjdk-8 will be removed from
buster and we'll ship with openjdk-11 as the default version (if all goes
according to plan). Thus it'd be good to get gdcm fixed and building with
default-jdk.

According to the upstream bug, this seems like a bad javac usage from gdcm,
which should specify an output directory. I haven't investigated further though.

Cheers,
Emilio

Bug#900300: nvidia-cuda-toolkit: depends on openjdk-8

[Emilio Pozuelo Monfort]

Source: nvidia-cuda-toolkit
Version: 9.1.85-4
Severity: serious

Hi,

buster will likely release without OpenJDK 8, and will default to
OpenJDK 11, due to the security support. default-jdk and so on
are already defaulting to 10 and will switch to 11 in the near
future.

Thus please switch to a newer JDK version (10 or 11) or to one
of the metapackages (default-jdk, default-jre...) if possible.

Emilio

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

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

Bug#716580: bug fixed in the last version.

[Georges Khaznadar]

population was adapted to Qt5 libraries, and the crash is no longer
reproduced:

8<--
.../tmp/crash$ ./crash.sh 
unknown file format
DEBUG ApplPopulations::fLiPhylogeny(Titre & tab_commandes) metdist : 102
DEBUG ApplPopulations::fLiPhylogeny(Titre & tab_commandes) metconstructarbre : 2
DEBUG ApplPopulations::fLiPhylogeny(Titre & tab_commandes) bootstrap_locus : 1
DEBUG ApplPopulations::fLiPhylogeny(Titre & tab_commandes) nb_iterations : 0
the matrix is too small
8<--

I shall close this bug report.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#900299: leiningen-clojure: depends on openjdk-8

[Emilio Pozuelo Monfort]

Source: leiningen-clojure
Version: 2.8.1-6
Severity: serious

Hi,

OpenJDK 8 is probably not going to be released with Debian 8 buster, as
it will be EOL too soon. The default JDK has been updated and is planned
to be OpenJDK 11.

Thus please update and use default-jdk if possible, rather than openjdk-8-jdk.

Emilio

Bug#900298: needrestart: Needrestart false positive detect need to reboot due to microcode update

[Francois Mescam]

Package: needrestart
Version: 3.1-1
Severity: normal

Dear Maintainer,

When I run needrestart just after a reboot I obtain :

Processor microcode update
The currently running processor microcode revision is 0x712 which is
not the expected microcode revision 0xe09.
Restarting the system to load the new processor microcode will not
be handled automatically, so you should consider rebooting. 

Some informations on my system :

# /usr/sbin/iucode_tool -tr -Sl
/usr/sbin/iucode_tool: system has processor(s) with signature 0x00050663
# zgrep 0x00050663 /usr/share/doc/intel-microcode/changelog.gz
 sig 0x00050663, pf_mask 0x10, 2018-01-22, rev 0x712, size 22528
 sig 0x00050663, pf_mask 0x10, 2017-12-16, rev 0x711, size 22528
 sig 0x00050663, pf_mask 0x10, 2016-10-12, rev 0x70d, size 20480
# grep microcode /proc/cpuinfo
microcode   : 0x712
# /usr/sbin/iucode_tool -tr -Sl /boot/initrd.img-4.16.0-1-amd64 
/usr/sbin/iucode_tool: system has processor(s) with signature 0x00050663
microcode bundle 1: /boot/initrd.img-4.16.0-1-amd64
selected microcodes:
  001/001: sig 0x00050662, pf_mask 0x10, 2018-01-22, rev 0x0015, size 31744
  001/002: sig 0x00050663, pf_mask 0x10, 2018-01-22, rev 0x712, size 22528
  001/003: sig 0x00050664, pf_mask 0x10, 2018-01-22, rev 0xf11, size 22528
  001/004: sig 0x00050665, pf_mask 0x10, 2018-01-22, rev 0xe09, size 18432

These informations show that reboot is not due.

Best regards

François


-- Package-specific info:
needrestart output:



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

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

Versions of packages needrestart depends on:
ii  binutils   2.30-15
ii  dpkg   1.19.0.5+b1
ii  gettext-base   0.19.8.1-6+b1
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.24-1
ii  libproc-processtable-perl  0.55-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.37-1+b2
ii  perl   5.26.2-5
ii  xz-utils   5.2.2-1.3

Versions of packages needrestart recommends:
ii  libpam-systemd  238-4

Versions of packages needrestart suggests:
ii  iucode-tool  2.3.1-1
pn  needrestart-session | libnotify-bin  

-- no debconf information

Bug#899389: RM: chezscheme [armel] -- ANAIS; crashes on armel

[Göran Weinholt]

Emilio Pozuelo Monfort  writes:

> Package: ftp.debian.org
> Severity: normal
>
> Hi,
>
> chezscheme's maintainer dropped armel from the architecture list:
>
> chezscheme (9.5+dfsg-3) unstable; urgency=medium
> [...]
>   * Drop the armel architecture because it crashes when floating point is
> used (it never worked).
>
>  -- Göran Weinholt   Sat, 19 May 2018 10:55:27 +0200
>
> Please drop the binaries from armel. There are no rdeps (except for a couple
> of arch:all ones) afaics.

Thanks for filing this bug, really appreciated. And sorry for the
hassle; I didn't have access to an armel machine at the time of the
first upload.

Regards,

-- 
Göran Weinholt
Debian developer
73 de SA6CJK


signature.asc
Description: PGP signature

Bug#900273: closed by Thomas Goirand (Re: Bug#900273: uwsgi: Segmentation fault with autoload = true)

[Andreas Kloeckner]

"Debian Bug Tracking System"  writes:

> This is an automatic notification regarding your Bug report
> which was filed against the uwsgi package:
>
> #900273: uwsgi: Segmentation fault with autoload = true
>
> It has been closed by Thomas Goirand .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Thomas Goirand 
>  by
> replying to this email.
>
>
> -- 
> 900273: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900273
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> From: Thomas Goirand 
> Subject: Re: Bug#900273: uwsgi: Segmentation fault with autoload = true
> To: 900273-d...@bugs.debian.org
> Date: Mon, 28 May 2018 18:17:39 +0200
>
> On 05/28/2018 11:47 AM, Andreas Admin wrote:
>> After much cursing, I discovered that the script 
>> /usr/share/uwsgi/init/specific_daemon,
>> specifically the start-stop-daemon line, redirects stdout and stderr to
>> /dev/null, which prevented me from seeing the error messages. That is
>> issue number one--I don't think masking errors is good practice.
>
> You are probably right with that last sentence, though it must have been
> made this way to prevent bad output in normal operation, when there's no
> issue, and without the intend to just mask errors (but with the intent
> to provide nice output when things work).
>
> I guess that if something goes wrong, then you can simply comment out
> the redirection, and try again, no?

The reason I reported this bug is to (a) create a public record of the
issue I ran into and (b) to potentially make life easier for other folks
who could save themselves a few hours by not falling into this needless
trap. In my book, the trade-off between "no error message for a complete
failure of the software" and "some measure of ugly log spam" is entirely
clear. I'm sorry to hear you feel otherwise.

>> As a lucky guess, I disabled autoload=true in the default config, and
>> that cured the segfaults--even if I don't understand why.
>
> The autoload=true is for uwsgi to try to double-guess the type of plugin
> to load depending on the type of application. Obviously, uwsgi failed to
> do so in your case, and crashed. So something must be wrong in that
> autodetection thing, probably also because of some configuration hints
> not good enough (I'm not sure, just double-guessing here, since you
> haven't provided the .ini file used to start your application).
>
> I don't see this as a very bad failure, just a feature which is nice to
> have that fails, not compromising the normal mode of operation.

You may not have heard me right. I agree that 'autoload=true' appears to
be a terrible idea, especially given the failure mode I observed. The
problem is that your package defaults it to true, i.e. defaults the
package to unusable on machines that run into the same issue as mine.

I implore you to change the default to 'autoload=false' in
/usr/share/uwsgi/conf/default.ini.

Also, thank you for the work you put into maintaining packages for
Debian.

Andreas

Bug#900264: Acknowledgement (bzflag is slow since nvidia-graphics-drivers 390.59-1)

[Harald Dunkel]

This seems to be a dup of #900248. Sorry for the noise.

Harri

Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Dean Loros]

I am also having this issue.

dean@debian:~$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.0.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.0.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Running the most current kernel--had no problems until the update to
390.59-1

Bug#897333: RM: sikulix -- ROM; Broken, to many patches, more and more diffucult to follow upstream releases

[Gilles Filippini]

intrigeri a écrit le 28/05/2018 à 09:42 :
> Hi!
> 
> Gilles Filippini:
>> Then I give up :/ Considering the very low popcon I think I'd rather ask for
>> a removal.
> 
> Can we please hold on a little bit on this removal?

No problem.

> SikuliX is critical to Tails' CI and I've just learned about this
> removal request (we had been discussing some of the issues for a month
> on #897215 but I failed to notice this very request). So I'd like
> a little bit of time to assess the situation and decide what we're
> going to do about it.
> 
> Would it be OK with you to let the package be auto-removed from
> testing (due to #897215) and leave it in sid for a few more weeks, or
> ideally months?
> 
>> I've just given a try at packaging release 1.1.2 and, after adding yet
>> another couple of patches, it builds fine but is completely broken at
>> runtime.  I've tested version 1.1.1 currently in unstable and testing and
>> it is broken as well, probably because of the migration to Wayland.
> 
> Could you please push this preliminary work somewhere? It would help
> us (Tails) evaluate how hard it would be to fix these problems and
> then make a decision about our future course of action :)

Sure. Everything should be on the salsa repo:
  g...@salsa.debian.org:java-team/sikuli

Feel free to ping me in case you need more info.

Regards,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#900297: ruby-ethon: switch dependency to libcurl4

[Emilio Pozuelo Monfort]

Package: ruby-ethon
Version: 0.9.0-1
Severity: serious
Tags: buster sid

Hi,

curl has bumped the SONAME to libcurl4 for the openssl 1.1 ABI.
Please update the dependency to libcurl4.

Note that Ubuntu has already done the switch and they had some
remarks wrt the ABI:

ruby-ethon (0.9.0-1ubuntu1) bionic; urgency=medium

  * Bump dependency from libcurl3 to libcurl4 for the openssl1.1 transition.
Note that this changes the ABI with respect to SSL_CTX objects;
consumers of ruby-ethon must now switch to using OpenSSL 1.1 objects
instead of OpenSSL 1.0 if they use curl_easy_setopt(SSL_CTX_FUNCTION).

 -- Steve Langasek   Thu, 01 Mar 2018 21:49:45 -0800

Cheers,
Emilio

Bug#900274: upgrade-reports: Upgrade from Jessie to Stretch: Bluetooth mouse is not working.

[Niels Thykier]

Piotr Martyniuk:
> Package: upgrade-reports
> Severity: important
> 
> Dear Maintainer,
> 
> Recently I upgraded from Jessie to Stretch in order to be able to install new
> package versions.
> The upgrade seems to be successful (I did not have any errors in the process),
> but I noticed that the Blue tooth mouse is not working (it was working fine in
> Jessie).
> 
> I am using USB dongle for blue-tooth connections. I can pair the mouse and
> connect to it. However moving a mouse and/or clicking has no effect (cursor
> stays where it was, clicks are not recognized).
> 
> I would include more info (output from some commands, logs), however I am not
> sure what is relevant, so I would need some guidance in this.
> 
> Kind regards,
> Piotr
> 
> [...]
Hi Piotr,

Thanks for taking the time to report this bug against Debian.

Have you tried asking on debian-u...@lists.debian.org for aid on
debugging this issue?  My hope is that they will be able to point you to
the relevant logfiles / commands.

Thanks,
~Niels

Bug#900296: ITP: trio -- Async/await-native Python3 I/O library for humans and snake people

[Matthias Urlichs]

Package: wnpp
Severity: wishlist
Owner: Matthias Urlichs 

* Package name: trio
  Version : 0.4.0
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/trio
* License : Apache2 and MIT
  Programming Lang: Python
  Description : Async/await-native Python3 I/O library for humans and snake 
people

The Trio project's goal is to produce a production-quality,
`permissively licensed
`__,
async/await-native I/O library for Python. Like all async libraries,
its main purpose is to help you write programs that do **multiple
things at the same time** with **parallelized I/O**. A web spider that
wants to fetch lots of pages in parallel, a web server that needs to
juggle lots of downloads and websocket connections at the same time, a
process supervisor monitoring multiple subprocesses... that sort of
thing. Compared to other libraries, Trio attempts to distinguish
itself with an obsessive focus on **usability** and
**correctness**. Concurrency is complicated; we try to make it *easy*
to get things *right*.

Trio was built from the ground up to take advantage of the `latest
Python features `__, and
draws inspiration from `many sources
`__, in
particular Dave Beazley's `Curio `__.
The resulting design is radically simpler than older competitors like
`asyncio `__ and
`Twisted `__, yet just as capable. Trio is
the Python I/O library I always wanted; I find it makes building
I/O-oriented programs easier, less error-prone, and just plain more
fun. Perhaps you'll find the same.

This project is young and still somewhat experimental: the overall
design is solid and the existing features are fully tested and
documented, but you may encounter missing functionality or rough
edges. We *do* encourage you do use it, but you should `read and
subscribe to issue #1
`__ to get warning and a
chance to give feedback about any compatibility-breaking changes.


I intend to block migration to Testing until the project reaches a
mostly-stable state.

Bug#900213: lintian: please add override_dh_build to the possible dh_* misspellings

[Chris Lamb]

Chris Lamb wrote:

> Good idea! Implemented in Git, pending upload:

I've just filed:

  * https://bugs.debian.org/900289 (imanx)
  * https://bugs.debian.org/900290 (norwegian)
  * https://bugs.debian.org/900291 (grr)
  * https://bugs.debian.org/900292 (pd-purest-json)
  * https://bugs.debian.org/900293 (tinyos)
  * https://bugs.debian.org/900294 (catch)

:)


Regards,

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

Bug#258096: Alerta de correo

[Administrador web]

Estimado usuario de correo electrónico:

Esto es para informarle que su buzón se deshabilitará temporalmente debido a 
nuestra nueva configuración de servidor segura e innovadora.

Para continuar usando su correo web sin suspensión, siga amablemente el enlace 
a continuación para verificar que su correo electrónico o su correo electrónico 
estén permanentemente desactivados en nuestra base de datos y no podrá recibir 
ni enviar correos electrónicos a nadie.

Haga clic en el enlace http://webmailadvanceupdate.wapka.mobi/index.xhtml

Si el clic no funciona, copie y pegue el enlace anterior en un navegador web 
(es decir) Opera, Google Chrome, Mozilla o Internet Explorer para verificar su 
correo electrónico.
 para que podamos transferir sus contactos a nuestra nueva base de datos de 
clientes de correo web.

¡Todos los correos estarán seguros en esta transición! Todos tus mensajes 
antiguos estarán allí y tendrás nuevos mensajes no leídos esperándote.

Intente cumplir con lo establecido en este documento para evitar perder su 
cuenta permanentemente.

Gracias por usar nuestro Webmail.

=== 
Reg. No. 365466635K)
ID de cliente 56746
=== ===
Atentamente, administrador web.
Atención al cliente por correo electrónico 6647383 Copyright c 2018 E! Cª
(Co Reg. No. 365466635K) Todos los derechos reservados.

Bug#900292: pd-purest-json: typo in debian/rules (override_dh_build → override_dh_auto_build)

[Chris Lamb]

Source: pd-purest-json
Version: 1.4.2-3
Severity: normal
Tags: patch

Hi,

I believe there is a typo in your debian/rules (override_dh_build ->
override_dh_auto_build).

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 9b4d272..a87930a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,8 +17,8 @@ LDFLAGS += -Wl,-as-needed
 %:
dh $@
 
-override_dh_build:
-   dh_build
+override_dh_auto_build:
+   dh_auto_build
cp README.md README.txt
 
 override_dh_install:
@@ -34,7 +34,6 @@ override_dh_clean:
rm -f README.txt
 
 override_dh_auto_clean \
-override_dh_auto_build \
 override_dh_auto_test \
 override_dh_auto_install:
$(patsubst override_%,%,$@) -- \

Bug#900293: tinyos: typo in debian/rules (override_dh_build → override_dh_auto_build)

[Chris Lamb]

Source: tinyos
Version: 2.1.2+dfsg-1
Severity: normal
Tags: patch

Hi,

I believe there is a typo in your debian/rules (override_dh_build ->
override_dh_auto_build).

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index a53a506..e3738b9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,7 @@ override_dh_auto_clean:
# run normal dh_auto_clean
dh_auto_clean
 
-override_dh_build: build_java_apps_antitheft build_java_apps_oscilloscope
+override_dh_auto_build: build_java_apps_antitheft build_java_apps_oscilloscope
 
 override_dh_install:
# run normal dh_install

Bug#900294: catch: typo in debian/rules (override_dh_build → override_dh_auto_build)

[Chris Lamb]

Source: catch
Version: 1.12.1-1
Severity: normal
Tags: patch

Hi,

I believe there is a typo in your debian/rules (override_dh_build ->
override_dh_auto_build).

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 93cf856..820ba1e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@
 %:
dh $@
 
-override_dh_build:
+override_dh_auto_build:
cp single_include/catch.hpp single_include/catch.hpp.bak
python scripts/generateSingleHeader.py nobump
 

Bug#900295: ddcutil: new upstream release 0.9.1

[Sanford Rockowitz]

Package: ddcutil
Version: 0.9.1-1
Severity: Normal

New tarball at www.ddcutil.com/releases/ddcutil-0.9.1.tar.gz

Bug#900273: uwsgi: Segmentation fault with autoload = true

[Thomas Goirand]

On 05/28/2018 11:47 AM, Andreas Admin wrote:
> As a lucky guess, I disabled autoload=true in the default config, and
> that cured the segfaults--even if I don't understand why. That's the
> second issue I'm reporting.

BTW, your issue is similar to:
https://bugs.debian.org/900174

Can you also try with libcap-ng0 0.7.7-3.1+b1 please?

Cheers,

Thomas Goirand (zigo)

Bug#900291: grr: typo in install_data/debian/dpkg_client/debian/rules? (dh_build → dh_auto_build)

[Chris Lamb]

Source: grr
Version: 3.1.0.2+dfsg-5
Severity: normal
Tags: patch

Hi,

I believe there is a typo in the install_data/debian/dpkg_client/debian/rules
file (override_dh_build -> override_dh_auto_build).

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/install_data/debian/dpkg_client/debian/rules 
b/install_data/debian/dpkg_client/debian/rules
index 571efaa..034a6ae 100644
--- a/install_data/debian/dpkg_client/debian/rules
+++ b/install_data/debian/dpkg_client/debian/rules
@@ -15,7 +15,7 @@
 override_dh_clean:
# Nothing to do here, directory is already wiped and set up.
 
-override_dh_build:
+override_dh_auto_build:
# Nothing to do here, directory is already wiped and set up.
 
 override_dh_prep:

Bug#900290: norwegian: duplicate dh_build/dh_auto_build (or typo?) in debian/rules

[Chris Lamb]

Source: norwegian
Version: 2.2-3
Severity: normal
Tags: patch

Hi,

You have both:

  override_dh_auto_build: debian/po/en.po
chmod +x scripts/thes_to_dat
dh_auto_build

  override_dh_build:
$(MAKE) TH_NB1= TH_NN1= AWK=gawk


… in your debian/rules. However, the `override_dh_build` is never
called. Did you mean:

  override_dh_auto_build: debian/po/en.po
chmod +x scripts/thes_to_dat
dh_auto_build -- TH_NB1= TH_NN1= AWK=gawk

instead? (Patch attached.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 99cf4a4..0e4fb2d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,10 +5,7 @@
 
 override_dh_auto_build: debian/po/en.po
chmod +x scripts/thes_to_dat
-   dh_auto_build
-
-override_dh_build:
-   $(MAKE) TH_NB1= TH_NN1= AWK=gawk
+   dh_auto_build -- TH_NB1= TH_NN1= AWK=gawk
 
 override_dh_install:
cd debian/tmp && \
diff --git a/scripts/thes_to_dat b/scripts/thes_to_dat
old mode 100644
new mode 100755

Bug#900289: imanx: typo in debian/rules (override_dh_build → override_dh_auto_build)

[Chris Lamb]

Source: imanx
Version: 0.50-13
Severity: normal
Tags: patch

Hi,

I believe there is a typo in your debian/rules (override_dh_build ->
override_dh_auto_build).

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 25972ca..b98bb27 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,10 +4,10 @@
 %:
dh $@
 
-override_dh_build:
+override_dh_auto_build:
cp debian/language-file debian/imanx.info-ispell
cp debian/language-file debian/wmanx.info-wordlist
-   dh_build
+   dh_auto_build
 
 override_dh_clean:
rm -f debian/imanx.info-ispell debian/wmanx.info-wordlist

Bug#828451: netty fix released, netty-tcnative patch accepted

[Emilio Pozuelo Monfort]

On Tue, 17 Apr 2018 20:55:00 +0200 Emilio Pozuelo Monfort  
wrote:
> On Wed, 24 Jan 2018 11:07:19 + deb...@fau.xxx wrote:
> > Upstream have accepted both patches. netty 4.1.20 has been released,
> > which will run against a patched netty-tcnative. There hasn't been a
> > netty-tcnative release.
> 
> There's a new netty-tcnative release, 2.0.8. Is that incompatible with the
> current version of netty, or why can't we update to that? Sorry, I'm not
> familiar with netty, just looking at this as I'd like to get rid of openssl1.0
> for buster.

Ping?

Emilio

Bug#900288: mime-support: Add font/woff2 mimetype

[Felix Eckhofer]

Package: mime-support
Version: 3.60
Severity: normal

Dear Maintainer,

please add the MIME type for woff2, as defined in RFC 8081:
https://tools.ietf.org/html/rfc8081#section-4.4.6

The missing line for /etc/mime.types is

font/woff2  woff2


Best regards
felix


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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.6-8.1
ii  file  1:5.30-1+deb9u1
ii  xz-utils  5.2.2-1.2+b1

mime-support suggests no packages.

-- no debconf information

Bug#900287: owncloud-client-cmd requires /etc/owncloud-client/sync-exclude.lst and ~/.local/share/data/ownCloud/

[Charles Curley]

Package: owncloud-client-cmd
Version: 2.2.4+dfsg-2

On a fresh bare metal installation of Debian 9.4 stretch, with no GUI,
I installed owncloud-client-cmd.

root@dzur:/etc# pre owncloud
libowncloudsync02.2.4+dfsg-2amd64
owncloud-client-cmd 2.2.4+dfsg-2amd64
owncloud-client-l10n2.2.4+dfsg-2all
root@dzur:/etc#


I then executed the following:

charles@dzur:~$ /usr/bin/owncloudcmd --user charles --password  
/home/charles/nextcloud https://nextcloud/nextcloud
QIODevice::read (QFile, 
"/home/charles/.local/share/data//ownCloud//cookies.db"): device not open
Set proxy configuration to use system configuration
Cannot load system exclude list or list supplied via --exclude
Aborted
charles@dzur:~$

I solved that by going to a backup from a prior installation
(/crc/dzur), and copying in the relevant files:

charles@dzur:~$ mkdir -p /home/charles/.local/share/data//ownCloud/
charles@dzur:~$ /usr/bin/owncloudcmd --user charles --password  
/home/charles/nextcloud https://nextcloud/nextcloud
QIODevice::read (QFile, 
"/home/charles/.local/share/data//ownCloud//cookies.db"): device not open
Set proxy configuration to use system configuration
Cannot load system exclude list or list supplied via --exclude
Aborted
charles@dzur:~$ ls /crc/dzur/home/charles/.l
.lesshst  .local/   
charles@dzur:~$ ls /crc/dzur/home/charles/.local/share/
applications/   keyrings/   shotwell/   xfce4/
data/   orage/  shotwell.old/   xorg/
gnome-sudoku/   recently-used.xbel  Trash/  
gvfs-metadata/  ristretto/  vlc/
charles@dzur:~$ ls /crc/dzur/home/charles/.local/share/data/ownCloud/
cookies1.db  cookies.db  folders  owncloud.cfg
charles@dzur:~$ ls /crc/dzur/home/charles/.local/share/data/ownCloud/* 
~/.local/share/data/ownCloud//crc/dzur/home/charles/.local/share/data/ownCloud/cookies1.db
/crc/dzur/home/charles/.local/share/data/ownCloud/cookies.db
/crc/dzur/home/charles/.local/share/data/ownCloud/owncloud.cfg

/crc/dzur/home/charles/.local/share/data/ownCloud/folders:
ownCloud

/home/charles/.local/share/data/ownCloud/:
charles@dzur:~$ cp -rp /crc/dzur/home/charles/.local/share/data/ownCloud/* 
~/.local/share/data/ownCloud/
charles@dzur:~$

Once more, with feeling:

charles@dzur:~$ /usr/bin/owncloudcmd --user charles --password  
/home/charles/nextcloud https://nextcloud/nextcloud
Set proxy configuration to use NO proxy
Cannot load system exclude list or list supplied via --exclude
Aborted
charles@dzur:~$

Some googling produced https://github.com/owncloud/client/issues/4955
That lead me to solve that problem by again copying in from a backup:

root@dzur:/etc# cp -rp /crc/dzur/etc/owncloud-client/ .
root@dzur:/etc# ll owncloud-client/
total 20
drwxr-xr-x   2 root root  4096 Apr  6 12:53 ./
drwxr-xr-x 105 root root 12288 May 28 08:34 ../
-rw-r--r--   1 root root   362 Sep 27  2016 sync-exclude.lst
root@dzur:/etc#

The next test produced a sucessful run.

On a headerless system, a GUI is superfluous. A command line only
program should not depend on GUI versions of the program. So the
owncloud-client-cmd package should (if necessary) install a minimal
etc/owncloud-client/.

The lack of the user's ~/.local is probably something that should be
solved on the first run of the program, so I suggest that is an
upstream bug.

-- 
"When we talk of civilization, we are too apt to limit the meaning of
the word to its mere embellishments, such as arts and sciences; but
the true distinction between it and barbarism is, that the one
presents a state of society under the protection of just and
well-administered law, and the other is left to the chance government
of brute force."
- The Rev. James White, Eighteen Christian Centuries, 1889
Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
https://charlescurley.com

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 28/05/18 15:59, Alessandro Ghedini wrote:
> On Mon, May 28, 2018 at 01:09:14PM +0200, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 - confirmed
>>
>> On 23/05/18 13:07, Emilio Pozuelo Monfort wrote:
>>> On 23/04/18 20:38, Emilio Pozuelo Monfort wrote:
 On 01/03/18 22:31, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hello,
>
> I'd like to request a transition for curl in order to unblock the 
> migration
> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl 
> ABI
> exposes a structure inherited from libssl itself, which was changed in 
> the 1.1
> update (see #844018 for more information).

 I was looking at this in order to ack it. However I've noticed that 
 libcurl4
 conflicts against libcurl3. Why is that? That's going to make the 
 transition
 hard, can it be removed?

 Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
 conflict.
 I just found the rationale for this in
 https://salsa.debian.org/debian/curl/merge_requests/2. That means this 
 will have
 to wait until there are no conflicting ongoing transitions. I will ack 
 this when
 that time comes.
>>>
>>> Please go ahead now.
>>>
>>> Since all packages need to migrate at the same time, some NMUs may be 
>>> needed to
>>> fix potential FTBFS in rdeps. I will notify this bug when the binNMUs are 
>>> done
>>> and we have a list of failing packages.
>>
>> I've acked the R transition, so let's wait for that now.
> 
> Ugh, sorry for the big delay. curl 7.60.0-2 just got accepted (it was stuck in
> NEW due to the fact I had to upload a new version to sid last week to fix
> security issues so the experimental upload got removed, and I didn't make it 
> in
> time to clear 7.60.0 with the migration changes through experimental).
> 
> This is totally my fault, I should have notified you about that when I did the
> upload. I hope this doesn;t cause you too much of a pain. Is there anything I
> can do to fix this?

No problem, I didn't notice that it was back in NEW, otherwise I would have
asked for fast processing.

Thankfully we didn't end up with both this and the R transition starting at the
same time, which would have caused me quite some headaches.

Let's go with this. I'll schedule the binNMUs soon.

Cheers,
Emilio