Bug#928560: vim-voom: vim-gnome transitional package no longer exists; please use vim-gtk3

2019-05-06 Thread Adam Conrad
Package: vim-voom
Version: 5.3-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch



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

  * debian/control: Depend on vim-gtk3 instead of obsolte vim-gnome.

The patch should be self-explanatory, I think.  As of vim 2:8.1.0693-1,
the vim-gnome transitional package (which depended on vim-gtk3) is no
longer, so you should depend directly on vim-gtk3 instead.

... Adam

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

Kernel: Linux 5.0.0-13-lowlatency (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru vim-voom-5.3/debian/control vim-voom-5.3/debian/control
--- vim-voom-5.3/debian/control 2018-08-04 04:20:38.0 -0600
+++ vim-voom-5.3/debian/control 2019-05-06 23:14:48.0 -0600
@@ -9,7 +9,7 @@
 Package: vim-voom
 Architecture: all
 # need vim-python support. but vim-python is virutal package.
-Depends: vim-nox (>= 7.2) | vim-gtk (>= 7.2) | vim-gnome (>= 7.2), 
${misc:Depends}
+Depends: vim-nox (>= 7.2) | vim-gtk (>= 7.2) | vim-gtk3 (>= 7.2), 
${misc:Depends}
 Recommends: vim-addon-manager
 Description: Vim two-pane outliner
  VOoM (Vim Outliner of Markups) is a plugin for Vim that emulates


Bug#924624: rclone: remote "crypt" is missing

2019-05-06 Thread Drew Parsons
Package: rclone
Followup-For: Bug #924624


crypt is there in your list, Item 9.


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

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

Versions of packages rclone depends on:
ii  libc6  2.28-10

rclone recommends no packages.

rclone suggests no packages.

-- no debconf information



Bug#928559: manpages: contrary to the manpage, the infinite loop in pldd(1) is no longer present

2019-05-06 Thread Asher Gordon

Package: manpages
Version: 4.16-1
Severity: minor
Tags: patch

Dear Maintainer,

The manpage for pldd(1) says

BUGS
   Since glibc 2.19, pldd is broken: it just hangs when executed.
   It is unclear if it will ever be fixed.

However, in glibc 2.28-10, this bug was fixed. The manpage should be
updated according to the patch below (of course you could put "None." or
"Many." or something like that in the BUGS section, as is the tradition
when you can't think of any bugs :-)):

--- man1/pldd.1~	2018-04-30 11:54:33.0 -0400
+++ man1/pldd.1	2019-05-07 01:05:44.440420437 -0400
@@ -96,12 +96,6 @@
 \fB-ex "quit" \-p $pid | grep '^0x.*0x'\fP
 .EE
 .in
-.SH BUGS
-Since glibc 2.19,
-.B pldd
-is broken: it just hangs when executed.
-.\" FIXME . https://sourceware.org/bugzilla/show_bug.cgi?id=18035
-It is unclear if it will ever be fixed.
 .SH EXAMPLE
 .EX
 $ \fBecho $$\fP   # Display PID of shell

Thanks,
Asher

-- 
The most delightful day after the one on which you buy a cottage in
the country is the one on which you resell it.
-- J. Brecheux

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.8.5-2

-- no debconf information


Bug#928558: reportbug: "message-fetch-field" should be "mail-fetch-field" in reportbug.el

2019-05-06 Thread Asher Gordon

Package: reportbug
Version: 7.5.2
Severity: normal
Tags: patch

Dear Maintainer,

When I run "reportbug -G" ("-G" to use the Gnus MUA), it starts up emacs
with a buffer containing the message, but it is in text-mode and not in
message-mode as one would expect. Here is the relevant part of the
*Messages* buffer:

Loading /usr/share/reportbug/reportbug.el (source)...done
Starting new Ispell process aspell with default dictionary...
let: Symbol’s function definition is void: message-fetch-field

As you can see, there is no function "message-fetch-field". It should
instead be "mail-fetch-field". A workaround is to put

(defalias 'message-fetch-field 'mail-fetch-field
  "Compatibility with reportbug(1)")

in your ~/.emacs which is what I did, and I am sending this with Gnus
now. However, the problem should really be corrected in
/usr/share/reportbug/reportbug.el as in the following patch:

--- share/reportbug.el~	2019-01-31 20:57:49.0 -0500
+++ share/reportbug.el	2019-05-07 00:24:08.944752814 -0400
@@ -28,8 +28,8 @@
   (interactive)
   (require 'gnus)
   (find-file reportbug-template)
-  (let ((subject (message-fetch-field "Subject"))
-(toaddr (or (message-fetch-field "To") "sub...@bugs.debian.org")))
+  (let ((subject (mail-fetch-field "Subject"))
+(toaddr (or (mail-fetch-field "To") "sub...@bugs.debian.org")))
 (gnus-narrow-to-body)
 (let ((body (or (buffer-string) "")))
   (gnus-summary-mail-other-window)

Thanks,
Asher

-- 
Real computer scientists don't program in assembler.  They don't write
in anything less portable than a number two pencil.

-- Package-specific info:
** Environment settings:
EDITOR="emacs"
PAGER="less"
INTERFACE="text"

** /home/asher/.reportbugrc:
reportbug_version "7.5.2"
mode standard
ui text
email "asd...@posteo.net"
smtphost "posteo.de"
smtpuser "asd...@posteo.net"
smtppasswd 
smtptls
http_proxy "socks5://localhost:9050"

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 reportbug depends on:
ii  apt1.8.0
ii  python33.7.2-1
ii  python3-reportbug  7.5.2
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4-daemon-light [mail-transport-agent]  4.92-2
ii  file   1:5.35-4
ii  gnupg  2.2.12-1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.0
ii  file   1:5.35-4
ii  python33.7.2-1
ii  python3-apt1.8.4
ii  python3-debian 0.1.34
ii  python3-debianbts  2.8.2
ii  python3-requests   2.21.0-1

python3-reportbug suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#928557: u-boot: CVE-2019-11690

2019-05-06 Thread Salvatore Bonaccorso
Source: u-boot
Version: 2019.01+dfsg-5
Severity: normal
Tags: security upstream
Forwarded: https://patchwork.ozlabs.org/patch/1092945

Hi Vagrant,

The following vulnerability was published for u-boot. I'm not sure how
relevant the issue is in Debian context, and we marked the issue at
least laready no-dsa for stretch.

CVE-2019-11690[0]:
| gen_rand_uuid in lib/uuid.c in Das U-Boot v2014.04 through v2019.04
| lacks an srand call, which allows attackers to determine UUID values
| in scenarios where CONFIG_RANDOM_UUID is enabled, and Das U-Boot is
| relied upon for UUID values of a GUID Partition Table of a boot
| device.


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-2019-11690
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11690
[1] https://patchwork.ozlabs.org/patch/1092945

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#926903: Installation-report addition

2019-05-06 Thread Cyril Brulebois
Ben Hutchings  (2019-05-06):
> 1. The installer-with-firmware is not installing firmware-amd-graphics
>automatically on systems with AMD GPUs that need it.
[…]

> I'm cloning this and will fix the second bug, but I don't know how to
> fix the first.

src:discover?


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


signature.asc
Description: PGP signature


Bug#928555: upgrade to buster from stretch suggests to remove bridge-utils

2019-05-06 Thread Brenden Eng
Please see correction, I ran `apt autoremove` and then restarted.

bridge-utils was not automatically removed during the installation, it was
after running `apt autoremove`


On Mon, 6 May 2019 23:54:05 -0400 Brenden Eng  wrote:
> Package: upgrade-reports
>
> Version: buster
>
> My system has a bridge interface configured in /etc/network/interfaces.
> I upgraded from stretch to buster.  After the successful upgrade in
> the list of packages to be auto-removed is bridge-utils.
>
> "The following packages were automatically installed and are no longer
required:
>   bridge-utils..."
>
> After running `sudo apt autoremove` and a subsequent restart,
> the host was missing its bridge interfaces.
>
> Manual installation of bridge-utils fixed the network interfaces.
>
> I suppose bridge-utils did not have any dependencies which was why it
> was auto-removed but this is an important package since loss of
> connectivity can occur if upgrading remotely.
>
> Thank you,
>
> -Brenden


Bug#833706: I have a problem in install

2019-05-06 Thread Cyril Brulebois
John Superman  (2019-05-05):
> Please help me to sucessfully install Kali Linux. Problem:loading
> libc6-udeb for unknown reasons

Please take this to Kali people.


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


signature.asc
Description: PGP signature


Bug#928506: installation-report: fails to find mirror under OpenBSD vmm(4) hypervisor

2019-05-06 Thread Cyril Brulebois
Control: tag -1 - d-i

Hi Matthew,

Matthew T Hoare  (2019-05-06):
> Dear Maintainer,
> 
>* What led up to the situation?
>I ran the installer under OpenBSD's vmm(4) hypervisor.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>Tried to connect to a mirror to download the installation packages.
>* What was the outcome of this action?
>The connection failed, a mirror was not found.
>* What outcome did you expect instead?
>That a mirror be detected and used.
> 
> -- Package-specific info:
> 
> Boot method: OpenBSD vmm(4) hypervisor
> Image version: 
> https://cdimage.debian.org/cdimage/buster_di_rc1/amd64/iso-cd/debian-buster-DI-rc1-amd64-netinst.iso
> Date: 2019-05-05 approx 11pm
> 
> Machine: vmm(4) in OpenBSD-current on ThinkPad X201
> Partitions: 
>  See attatched output.
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[E]
> Install tasks:  [E]
> Install boot loader:[O]
> Overall install:[O]
> 
> Comments/Problems:
> 
> The installer detected the virtual interface and was able to configure it but 
> was then unable to find the mirror.

“the mirror” isn't a thing. There are plenty of them. Which one did you
configure?

> I couldn't ping 8.8.8.8 from the busybox shell so it wasn't just name
> resolution. However I could manage to connect once the system was
> installed and booted, both ifupdown and systemd-networkd are fully
> functional.

Please share (compressed) /var/log/installer/syslog so that we have a
chance at trying to understand what happened. See below:

> Please make sure that the hardware-summary log file, and any other
> installation logs that you think would be useful are attached to this
> report. Please compress large files using gzip.


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


signature.asc
Description: PGP signature


Bug#928556: stretch-pu: package gocode/20150303-3+deb9u2

2019-05-06 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

the last stretch-pu update of gocode caused a regression on
jessie->stretch updates. If I make the recently added Pre-Depends
versioned to pull in the version from stretch first, everything seems to
work again as expected.


Andreas
diff -Nru gocode-20150303/debian/changelog gocode-20150303/debian/changelog
--- gocode-20150303/debian/changelog2019-04-05 10:36:56.0 +0200
+++ gocode-20150303/debian/changelog2019-05-07 05:08:04.0 +0200
@@ -1,3 +1,11 @@
+gocode (20150303-3+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * gocode-auto-complete-el: Make Pre-Depends: auto-complete-el versioned to
+fix upgrades from jessie to stretch.
+
+ -- Andreas Beckmann   Tue, 07 May 2019 05:08:04 +0200
+
 gocode (20150303-3+deb9u1) stretch; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gocode-20150303/debian/control gocode-20150303/debian/control
--- gocode-20150303/debian/control  2019-04-05 10:36:56.0 +0200
+++ gocode-20150303/debian/control  2019-05-07 03:55:56.0 +0200
@@ -29,7 +29,7 @@
 Package: gocode-auto-complete-el
 Section: editors
 Architecture: all
-Pre-Depends: auto-complete-el,
+Pre-Depends: auto-complete-el (>= 1.3.1-2+deb9u1),
 Depends: ${shlibs:Depends}, ${misc:Depends}, gocode,
 Enhances: gocode
 Description: gocode integration for Emacs


Bug#928555: upgrade to buster from stretch suggests to remove bridge-utils

2019-05-06 Thread Brenden Eng
Package: upgrade-reports

Version: buster

My system has a bridge interface configured in /etc/network/interfaces.
I upgraded from stretch to buster.  After the successful upgrade in
the list of packages to be auto-removed is bridge-utils.

"The following packages were automatically installed and are no longer required:
  bridge-utils..."

After running `sudo apt-get dist-upgrade` and a subsequent restart,
the host was missing its bridge interfaces.

Manual installation of bridge-utils fixed the network interfaces.

I suppose bridge-utils did not have any dependencies which was why it
was auto-removed but this is an important package since loss of
connectivity can occur if upgrading remotely.

Thank you,

-Brenden


Bug#927245: caveconverter: FTBFS (jh_build: Cannot find "caveconverter")

2019-05-06 Thread Wookey
On 2019-04-19 00:32 +0100, Wookey wrote:

> > jh_build: Compatibility levels before 9 are deprecated (level 7 in use)
> > jh_build: Cannot find (any matches for) "caveconverter" (tried in .)
> 
> Confirmed, thanks. I'll work out what's gone wrong there and upload a fix.

OK. Seems the issue was having an old unused javabuild file lying
around, referring to a source dir than no longer existed. It used to
not matter, but now jh_build correctly points out that the mentioned
directory no longer exists.

Referenced in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927243

However now it builds, but the resulting .jar doesn't know how to run itself:
$ caveconverter
run-detectors: unable to find an interpreter for /usr/bin/caveconverter

Same error running the actual jar:
$ /usr/share/caveconverter/CaveConverter.jar
run-detectors: unable to find an interpreter for 
/usr/share/caveconverter/CaveConverter.jar

Not sure why this used to work. Something to do with manifests?


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


signature.asc
Description: PGP signature


Bug#928554: dgit-nmu-simple should give an example of generating a patches-unapplied nmudiff

2019-05-06 Thread Sam Hartman

package: dgit
version: 8.3
severity: wishlist

The dgit-nmu-simple man page doesn't give any explicit examples of
generating an nmudiff.

It's unclear that we actually have a standard on whether an nmudiff
should be patches-applied or patches-unapplied.
I find that I typically get patches-unapplied nmudiffs, that if you use
a standard dpkg workflow without dgit they are easier, and having the
patch duplicated is harder to review.

I find it's unintuitive how exactly you generate a good
patches-unapplied nmudiff, so I looked for guidance in the man page and
didn't find any.



signature.asc
Description: PGP signature


Bug#921688: NMU Diff

2019-05-06 Thread Sam Hartman

Dear maintainer.
I made the following 0-day NMU of electrum.
I suspect that once you update to a new version you will not wish to
include these changes, but in the interest of awareness of your package
I wanted to make sure you were aware.

diff --git a/debian/changelog b/debian/changelog
index 4ff..c30a279 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+electrum (3.2.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * On startup print a warning that this version in insecure and then
+exit, Closes: #928518
+
+
+ -- Sam Hartman   Mon, 06 May 2019 22:11:19 -0400
+
 electrum (3.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/patches/replace-with-security-warning.patch 
b/debian/patches/replace-with-security-warning.patch
new file mode 100644
index 000..e8f409e
--- /dev/null
+++ b/debian/patches/replace-with-security-warning.patch
@@ -0,0 +1,60 @@
+From: Sam Hartman 
+Date: Mon, 6 May 2019 22:10:51 -0400
+X-Dgit-Generated: 3.2.3-1.1 3afceceac2d1042645e470189c13edb4f965e7a9
+Subject: Replace with security warning
+
+On startup print to GUI and stdio a security warning and then exit.
+
+---
+
+--- electrum-3.2.3.orig/electrum/electrum
 electrum-3.2.3/electrum/electrum
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python3
++#!/usr/bin/python3
+ # -*- mode: python -*-
+ #
+ # Electrum - lightweight Bitcoin client
+@@ -30,13 +30,42 @@ script_dir = os.path.dirname(os.path.rea
+ is_bundle = getattr(sys, 'frozen', False)
+ is_local = not is_bundle and os.path.exists(os.path.join(script_dir, 
"electrum.desktop"))
+ is_android = 'ANDROID_DATA' in os.environ
++try:
++import PyQt5
++except Exception:
++sys.exit("Error: Could not import PyQt5 on Linux systems, you may try 
'sudo apt-get install python3-pyqt5'")
+ 
++from PyQt5.QtGui import *
++from PyQt5.QtWidgets import *
++from PyQt5.QtCore import *
++import PyQt5.QtCore as QtCore
+ # move this back to gui/kivy/__init.py once plugins are moved
+ os.environ['KIVY_DATA_DIR'] = os.path.abspath(os.path.dirname(__file__)) + 
'/electrum/gui/kivy/data/'
+ 
+ if is_local or is_android:
+ sys.path.insert(0, os.path.join(script_dir, 'packages'))
+ 
++security_message = ''' \
++This version of Electrum is vulnerable to malicious code inserted by
++attackers and is being actively exploited to try and convince users to
++give their private credentials to attackers.  See
++https://bugs.debian.org/921688 for details.  Until the version in
++Debian is updated, please see https://electrum.org/download.html
++'''
++sys.stderr.write(security_message)
++
++
++from electrum.gui.qt.util import MessageBoxMixin
++class Window(QMainWindow, MessageBoxMixin):
++
++def __init__(self, *args, **kwargs):
++super().__init__(*args, **kwargs)
++self.show_warning(msg = security_message, title = "THIS APPLICATION 
is INSECURE")
++
++
++app = QApplication(["electrum", "gui"])
++window = Window()
++sys.exit(2)
+ 
+ def check_imports():
+ # pure-python dependencies need to be imported here for pyinstaller
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..8ffe66a
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+replace-with-security-warning.patch
diff --git a/electrum/electrum b/electrum/electrum
index dd35c35..8c5ef37 100755
--- a/electrum/electrum
+++ b/electrum/electrum
@@ -1,4 +1,4 @@
-#!/usr/bin/env python3
+#!/usr/bin/python3
 # -*- mode: python -*-
 #
 # Electrum - lightweight Bitcoin client
@@ -30,13 +30,42 @@ script_dir = os.path.dirname(os.path.realpath(__file__))
 is_bundle = getattr(sys, 'frozen', False)
 is_local = not is_bundle and os.path.exists(os.path.join(script_dir, 
"electrum.desktop"))
 is_android = 'ANDROID_DATA' in os.environ
-
+try:
+import PyQt5
+except Exception:
+sys.exit("Error: Could not import PyQt5 on Linux systems, you may try 
'sudo apt-get install python3-pyqt5'")
+
+from PyQt5.QtGui import *
+from PyQt5.QtWidgets import *
+from PyQt5.QtCore import *
+import PyQt5.QtCore as QtCore
 # move this back to gui/kivy/__init.py once plugins are moved
 os.environ['KIVY_DATA_DIR'] = os.path.abspath(os.path.dirname(__file__)) + 
'/electrum/gui/kivy/data/'
 
 if is_local or is_android:
 sys.path.insert(0, os.path.join(script_dir, 'packages'))
 
+security_message = ''' \
+This version of Electrum is vulnerable to malicious code inserted by
+attackers and is being actively exploited to try and convince users to
+give their private credentials to attackers.  See
+https://bugs.debian.org/921688 for details.  Until the version in
+Debian is updated, please see https://electrum.org/download.html
+'''
+sys.stderr.write(security_message)
+
+
+from electrum.gui.qt.util import MessageBoxMixin
+class Window(QMainWindow, MessageBoxMixin):
+
+def __init__(self, *args, **kwargs):
+super().__init__(*args, **kwargs)
+self.show_warning(msg = security_message, title = "THIS APPLICATION is 
INSECURE")
+
+ 

Bug#928553: stretch-pu: package libthrift-java/0.9.1-2.1~deb9u1

2019-05-06 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

The fix for CVE-2018-1320 was in sid (0.9.1-2.1) before the package got
removed, and is in jessie-lts (0.9.1-2+deb8u1), leaving stretch at an
older version than jessie-lts. So let's get it in stretch to restore
monotonic version ordering.


Andreas
diff -Nru libthrift-java-0.9.1/debian/changelog 
libthrift-java-0.9.1/debian/changelog
--- libthrift-java-0.9.1/debian/changelog   2014-10-17 00:28:43.0 
+0200
+++ libthrift-java-0.9.1/debian/changelog   2019-05-07 03:44:09.0 
+0200
@@ -1,3 +1,22 @@
+libthrift-java (0.9.1-2.1~deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Tue, 07 May 2019 03:44:09 +0200
+
+libthrift-java (0.9.1-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2018-1320:
+It was discovered that it was possible to bypass SASL negotiation
+isComplete validation in the org.apache.thrift.transport.TSaslTransport
+class. An assert used to determine if the SASL handshake had successfully
+completed could be disabled in production settings making the validation
+incomplete. (Closes: #918736)
+
+ -- Markus Koschany   Wed, 06 Feb 2019 19:04:12 +0100
+
 libthrift-java (0.9.1-2) unstable; urgency=low
 
   * Use 3.0 (quilt) source format.
diff -Nru libthrift-java-0.9.1/debian/patches/CVE-2018-1320.patch 
libthrift-java-0.9.1/debian/patches/CVE-2018-1320.patch
--- libthrift-java-0.9.1/debian/patches/CVE-2018-1320.patch 1970-01-01 
01:00:00.0 +0100
+++ libthrift-java-0.9.1/debian/patches/CVE-2018-1320.patch 2019-02-06 
19:04:12.0 +0100
@@ -0,0 +1,32 @@
+From: Markus Koschany 
+Date: Wed, 6 Feb 2019 18:59:31 +0100
+Subject: CVE-2018-1320
+
+Bug-Debian: https://bugs.debian.org/918736
+Origin: 
https://github.com/apache/thrift/commit/d973409661f820d80d72c0034d06a12348c8705e
+---
+ src/org/apache/thrift/transport/TSaslTransport.java | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/src/org/apache/thrift/transport/TSaslTransport.java 
b/src/org/apache/thrift/transport/TSaslTransport.java
+index b54746c..2f62016 100644
+--- a/src/org/apache/thrift/transport/TSaslTransport.java
 b/src/org/apache/thrift/transport/TSaslTransport.java
+@@ -268,7 +268,7 @@ abstract class TSaslTransport extends TTransport {
+ if (message.status == NegotiationStatus.COMPLETE &&
+ getRole() == SaslRole.CLIENT) {
+   LOGGER.debug("{}: All done!", getRole());
+-  break;
++  continue;
+ }
+ 
+ sendSaslMessage(sasl.isComplete() ? NegotiationStatus.COMPLETE : 
NegotiationStatus.OK,
+@@ -276,8 +276,6 @@ abstract class TSaslTransport extends TTransport {
+   }
+   LOGGER.debug("{}: Main negotiation loop complete", getRole());
+ 
+-  assert sasl.isComplete();
+-
+   // If we're the client, and we're complete, but the server isn't
+   // complete yet, we need to wait for its response. This will occur
+   // with ANONYMOUS auth, for example, where we send an initial response
diff -Nru libthrift-java-0.9.1/debian/patches/series 
libthrift-java-0.9.1/debian/patches/series
--- libthrift-java-0.9.1/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libthrift-java-0.9.1/debian/patches/series  2019-02-06 19:04:12.0 
+0100
@@ -0,0 +1 @@
+CVE-2018-1320.patch


Bug#928509: Firefox insecure because of missing extensions

2019-05-06 Thread Sylvain Beucler
Hi,

On 06/05/2019 23:33, Sylvain Beucler wrote:
> On 06/05/2019 15:47, Hideki Yamane wrote:
>> On Mon, 6 May 2019 15:04:09 +0200 Karsten  wrote:
>>> Package: firefox-esr
>>> Version: 60.6.1esr-1~deb8u1
>>  It was already done in unstable and stable-proposed-updates, and
>>  reporter asks about oldstable, so CC:ed to lts mailing list.
>>  
>>  LTS maintainers, could you build it for oldstable, please?
> I'm rebuilding the new version with the previous oldstable changes.
> (any estimated time for parallel build 4CPU/SSD?)
>
> If the build succeeds and if I can install extensions again, I'll upload
> to LTS.


https://lists.debian.org/debian-lts-announce/2019/05/msg9.html

Packages should be building now :)

Cheers!
Sylvain



Bug#927735: Package nvidia-kernel-dkms unmet dependencies

2019-05-06 Thread Andreas Beckmann
On 2019-04-22 07:09, TarotApprentice wrote:
> The one from Stretch-backports...
> # apt install -t stretch-backports nvidia-kernel-dkmsReading package lists... 
> DoneBuilding dependency treeReading state information... DoneSome packages 
> could not be installed. This may mean that you haverequested an impossible 
> situation or if you are using the unstabledistribution that some required 
> packages have not yet been createdor been moved out of Incoming.The following 
> information may help to resolve the situation:The following packages have 
> unmet dependencies: nvidia-kernel-dkms : Depends: nvidia-kernel-support--v1   
>    Recommends: nvidia-driver (>= 390.87) but it is not going 
> to be installed or  libcuda1 (>= 390.87) but 
> it is not going to be installedE: Unable to correct problems, you have held 
> broken packages.

Something strange had happened and some packages seem to have
disappeared from stretch-backports. This should be solved by the 418.56
driver stack that I just uploaded to stretch-backports, but it may take
a few days to become visible since it needs to be approved manually by a
backports-ftp-master.

Andreas



Bug#927735: 418.56-2 (now in sid) resolves

2019-05-06 Thread Andreas Beckmann
On 2019-04-28 06:33, TarotApprentice wrote:
> Another issue that is possibly related to Buster (using the RC1 iso image) if 
> one installs Buster and then the 410 version from buster or the 418 version 
> from sid results in Debian boot hanging and no desktop/logon prompt is 
> displayed. I can still ssh into the machine. Please advise if you’d like a 
> separate bug. If you don’t install Nvidia-kernel-dkms while you get an error 
> from nouveau complaining about unknown chipset you do get the desktop/login 
> prompt.

This is an unrelated issue, please file a separate bug (ideally by
running reportbug from the machine in buggy state while being logged in
via ssh).


Andreas



Bug#928497: nvidia-persistenced: Error in nvidia-persistenced source (postinst)

2019-05-06 Thread Andreas Beckmann
Control: tag -1 moreinfo

On 2019-05-06 08:01, Marcelo "Elppans" Klumpp wrote:
> There is an ambiguous configuration error in the file 
> "debian/nvidia-persistenced.postinst":

> It means that you should create a "home" folder in /var/run/nvpd/, but at the 
> end of the code it says DO NOT CREATE the folder.
> 
> If you want to create a folder, how can you NOT CREATE the folder you are 
> creating?

/var/run is a volatile path, anything needed there has to be created at 
runtime, not during installation.
And the home directory of nvpd is clearly *not* needed.

> Because of this, when installing the package, the following error occurs and 
> the service does not start:
> 
> Alert: The home directory /var/run/nvpd/ you specified can not be accessed: 
> No such file or directory
> 
> Alert: The home directory /var/run/nvpd/ you specified can not be accessed: 
> No such file or directory

This is just noisy.

> Adding system user 'nvpd' (UID 118) ...
> Adding new group 'nvpd' (GID 124) ...
> Adding new user 'nvpd' (UID 118) with group 'nvpd' ...
> Not creating personal directory '/var/run/nvpd/'.
> Created symlink 
> /etc/systemd/system/multi-user.target.wants/nvidia-persistenced.service → 
> /lib/systemd/system/nvidia-persistenced.service.

> Job for nvidia-persistenced.service failed because the control process exited 
> with error code.
> See "systemctl status nvidia-persistenced.service" and "journalctl -xe" for 
> details.

What is the actual error encountered while starting the service?

I can reproduce this (on a systemv system) with a (deliberately)
mismatching kernel module loaded:

Preparing to unpack .../nvidia-persistenced_418.56-1_amd64.deb ...
Unpacking nvidia-persistenced (418.56-1) over (390.87-1~deb9u1) ...
Setting up nvidia-persistenced (418.56-1) ...
Warning: The home dir /var/run/nvpd/ you specified can't be accessed: No such 
file or directory
Adding system user `nvpd' (UID 133) ...
Adding new group `nvpd' (GID 144) ...
Adding new user `nvpd' (UID 133) with group `nvpd' ...
Not creating home directory `/var/run/nvpd/'.
Stopping NVIDIA Persistence Daemon
Starting NVIDIA Persistence Daemon
nvidia-persistenced failed to initialize. Check syslog for more details.
invoke-rc.d: initscript nvidia-persistenced, action "restart" failed.
dpkg: error processing package nvidia-persistenced (--configure):
 installed nvidia-persistenced package post-installation script subprocess 
returned error exit status 1

in syslog I have:

nvidia-persistenced: Started (7837)
nvidia-persistenced: Failed to query NVIDIA devices. Please ensure that the 
NVIDIA device files (/dev/nvidia*) exist, and that user 133 has read and write 
permissions for those files.
nvidia-persistenced: Shutdown (7837)
kernel: [12558015.162992] NVRM: API mismatch: the client has the version 
410.104, but
kernel: [12558015.162992] NVRM: this kernel module has the version 396.54.  
Please
kernel: [12558015.162992] NVRM: make sure that this kernel module and all 
NVIDIA driver
kernel: [12558015.162992] NVRM: components have the same version.

With the correct kernel module loaded, nvidia-persistenced runs fine.


Andreas



Bug#928552: texlive-fonts-extra-links: missing Breaks+Replaces: texlive-fonts-extra (<< 2019)

2019-05-06 Thread Andreas Beckmann
Package: texlive-fonts-extra-links
Version: 2019.20190506-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../texlive-fonts-extra-links_2019.20190506-1_all.deb ...
  Unpacking texlive-fonts-extra-links (2019.20190506-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-fonts-extra-links_2019.20190506-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/texlive/texmf-dist/fonts/opentype/public/ebgaramond/EBGaramond-Initials.otf',
 which is also in package texlive-fonts-extra 2018.20190227-2
  Errors were encountered while processing:
   /var/cache/apt/archives/texlive-fonts-extra-links_2019.20190506-1_all.deb


cheers,

Andreas


texlive-fonts-extra=2018.20190227-2_texlive-fonts-extra-links=2019.20190506-1.log.gz
Description: application/gzip


Bug#924591: this requires linking in libsparse, which is from Android sources

2019-05-06 Thread Theodore Ts'o
clone 924591 -1
reassign 924591 fastboot 1:8.1.0+r23-4
retitle -1 e2fsprogs: add support for dynamically loading libsparse
severity -1 wishlist
thanks

I'm reassigning the original bug back to fastboot.  I've cloned the
bug and made it a feature request of having e2fsprogs dynamically load
libsparse if it is available.  That's not happening until after Buster
is released, though.

- Ted



Bug#928550: dpkg: warning: while removing openjdk-11-jre-headless:amd64, directory '/usr/lib/jvm' not empty so not removed

2019-05-06 Thread 積丹尼 Dan Jacobson
Package: openjdk-11-jre-headless:amd64
Version: 11.0.3+7-4
Severity: minor

dpkg: warning: while removing openjdk-11-jre-headless:amd64, directory 
'/usr/lib/jvm' not empty so not removed
$ find /usr/lib/jvm -type f -ls
/usr/lib/jvm/java-9-openjdk-amd64/lib/server/classes.jsa



Bug#928549: golang-github-abbot-go-http-auth: FTBFS: cannot find package "golang.org/x/crypto/bcrypt", "golang.org/x/net/context"

2019-05-06 Thread Andreas Beckmann
Package: golang-github-abbot-go-http-auth
Version: 0.4.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

golang-github-abbot-go-http-auth/experimental FTBFS with

 debian/rules build
dh build --buildsystem=golang --with=golang --builddirectory=_build
   dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=_build
   dh_autoreconf -O--buildsystem=golang -O--builddirectory=_build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/build/golang-github-abbot-go-http-auth-0.4.0'
dh_auto_configure
## Install test data files:
cp -v test.*  _build/src/github.com/abbot/go-http-auth//
'test.htdigest' -> '_build/src/github.com/abbot/go-http-auth/test.htdigest'
'test.htpasswd' -> '_build/src/github.com/abbot/go-http-auth/test.htpasswd'
make[1]: Leaving directory '/build/golang-github-abbot-go-http-auth-0.4.0'
   dh_auto_build -O--buildsystem=golang -O--builddirectory=_build
cd _build && go install 
-gcflags=all=\"-trimpath=/build/golang-github-abbot-go-http-auth-0.4.0/_build/src\"
 
-asmflags=all=\"-trimpath=/build/golang-github-abbot-go-http-auth-0.4.0/_build/src\"
 -v -p 3 github.com/abbot/go-http-auth
src/github.com/abbot/go-http-auth/basic.go:12:2: cannot find package 
"golang.org/x/crypto/bcrypt" in any of:
/usr/lib/go-1.11/src/golang.org/x/crypto/bcrypt (from $GOROOT)

/build/golang-github-abbot-go-http-auth-0.4.0/_build/src/golang.org/x/crypto/bcrypt
 (from $GOPATH)
src/github.com/abbot/go-http-auth/auth.go:7:2: cannot find package 
"golang.org/x/net/context" in any of:
/usr/lib/go-1.11/src/golang.org/x/net/context (from $GOROOT)

/build/golang-github-abbot-go-http-auth-0.4.0/_build/src/golang.org/x/net/context
 (from $GOPATH)
dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/build/golang-github-abbot-go-http-auth-0.4.0/_build/src\"
 
-asmflags=all=\"-trimpath=/build/golang-github-abbot-go-http-auth-0.4.0/_build/src\"
 -v -p 3 github.com/abbot/go-http-auth returned exit code 1
make: *** [debian/rules:9: build] Error 1


Andreas


golang-github-abbot-go-http-auth_0.4.0-1.log.gz
Description: application/gzip


Bug#928498: gitg: Crash with assertion failed

2019-05-06 Thread Bernhard Übelacker
Control: reassign 928498 gtksourceview3 3.24.9-2
Control: tags + 928498 upstream fixed-upstream patch
Control: affects 928498 gitg gedit



Dear Maintainer,
this crash seems to be described in upstream
bugs [1] and [2].

And upstream seems to have a fix commited
to the 3.24 branch [3] too.

A package libgtksourceview-3.0-1 built with the patch
does not crash gitg anymore.

Kind regards,
Bernhard


[1] https://gitlab.gnome.org/GNOME/gtksourceview/issues/54
[2] https://gitlab.gnome.org/GNOME/gtksourceview/issues/30
[3] 
https://gitlab.gnome.org/GNOME/gtksourceview/commit/06a9d3751c808870dc72e470700693d01f4fc284

# Buster amd64 qemu VM 2019-05-06


apt update
apt dist-upgrade


apt install systemd-coredump xserver-xorg lightdm openbox gdb fakeroot gitg 
gitg-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym libgtksourceview-3.0-1-dbgsym
apt build-dep gtksourceview3


reboot


mkdir /home/benutzer/source/gtksourceview3/orig -p
cd/home/benutzer/source/gtksourceview3/orig
apt source gtksourceview3
cd





mkdir xbmc
cd xbmc
git clone https://github.com/xbmc/xbmc.git
cd xbmc
export DISPLAY=:0
gitg
# click on "Krypton"





benutzer@debian:~/xbmc/xbmc$ gitg
**
GtkSourceView:ERROR:gtksourcecontextengine.c:5543:update_syntax: assertion 
failed: (g_slist_length (ce->priv->invalid) <= 1)
Abgebrochen (Speicherabzug geschrieben)



root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2019-05-07 00:05:33 CEST951  1000  1000   6 present   /usr/bin/gitg



root@debian:~# coredumpctl gdb 951
   PID: 951 (gitg)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Tue 2019-05-07 00:05:32 CEST (1min 6s ago)
  Command Line: gitg
Executable: /usr/bin/gitg
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (benutzer)
   Boot ID: f41413a2789c4ca899d7db4111d58cd7
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.gitg.1000.f41413a2789c4ca899d7db4111d58cd7.951.155718033200.lz4
   Message: Process 951 (gitg) of user 1000 dumped core.

Stack trace of thread 951:
#0  0x7f92a38887bb raise (libc.so.6)
#1  0x7f92a3873535 abort (libc.so.6)
#2  0x7f92a4786dc3 n/a (libglib-2.0.so.0)
#3  0x7f92a47e068a g_assertion_message_expr 
(libglib-2.0.so.0)
#4  0x7f92a472b444 n/a (libgtksourceview-3.0.so.1)
#5  0x7f92a472b5ab n/a (libgtksourceview-3.0.so.1)
#6  0x7f92a3f00c08 n/a (libgdk-3.so.0)
#7  0x7f92a47b8dd8 g_main_context_dispatch 
(libglib-2.0.so.0)
#8  0x7f92a47b91c8 n/a (libglib-2.0.so.0)
#9  0x7f92a47b925c g_main_context_iteration 
(libglib-2.0.so.0)
#10 0x7f92a3d9699d g_application_run (libgio-2.0.so.0)
#11 0x55893e723906 gitg_main_main (gitg)
#12 0x7f92a387509b __libc_start_main (libc.so.6)
#13 0x55893e6cfe5a _start (gitg)

Stack trace of thread 953:
#0  0x7f92a393f819 __poll (libc.so.6)
#1  0x7f92a47b9136 n/a (libglib-2.0.so.0)
#2  0x7f92a47b94c2 g_main_loop_run (libglib-2.0.so.0)
#3  0x7f92a3dcff66 n/a (libgio-2.0.so.0)
#4  0x7f92a47e1425 n/a (libglib-2.0.so.0)
#5  0x7f92a344bfa3 start_thread (libpthread.so.0)
#6  0x7f92a394a4cf __clone (libc.so.6)

Stack trace of thread 954:
#0  0x7f92a393f819 __poll (libc.so.6)
#1  0x7f92a47b9136 n/a (libglib-2.0.so.0)
#2  0x7f92a47b925c g_main_context_iteration 
(libglib-2.0.so.0)
#3  0x7f929d652ffd n/a (libdconfsettings.so)
#4  0x7f92a47e1425 n/a (libglib-2.0.so.0)
#5  0x7f92a344bfa3 start_thread (libpthread.so.0)
#6  0x7f92a394a4cf __clone (libc.so.6)

Stack trace of thread 952:
#0  0x7f92a393f819 __poll (libc.so.6)
#1  0x7f92a47b9136 n/a (libglib-2.0.so.0)
#2  0x7f92a47b925c g_main_context_iteration 
(libglib-2.0.so.0)
#3  0x7f92a47b92a1 n/a (libglib-2.0.so.0)
#4  0x7f92a47e1425 n/a (libglib-2.0.so.0)
#5  0x7f92a344bfa3 start_thread (libpthread.so.0)
#6  0x7f92a394a4cf __clone (libc.so.6)

Stack trace of thread 959:
#0  0x7f92a3944f59 syscall (libc.so.6)
#1  0x7f92a48030ba g_cond_wait_until (libglib-2.0.so.0)

Bug#920563: dracut: fails to boot with bash 5 as /bin/sh

2019-05-06 Thread Lehel Bernadt

Hi Thomas,

Yes it does.
Applied fix-bash-5.patch with "patch -p1" under /usr/lib/dracut, then 
ran "dracut --force" to regenerate the initramfs image.

After restarting, no problems at boot.

Regards,
Lehel

On 2019-05-05 21:34, Thomas Lange wrote:

Hi Lehel, hi Ingo,

it would be nice if you could check if fix-bash-5.patch from the URL
below fixes your problems.
I sure will also apply
0001-remove-bashism-in-various-boot-scripts.patch which is now also in 
upstream.



On Sat, 4 May 2019 18:30:09 +0200, Lehel Bernadt  
said:


> For inspiration on how to fix it you can look here:
>
https://github.com/void-linux/void-packages/tree/master/srcpkgs/dracut/patches
> (I don't know why these aren't in upstream though)




Bug#928548: unblock: libetpan/1.9.3-2

2019-05-06 Thread Ricardo Mones
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libetpan

The upload just adds an upstream patch to fix serious bug #927709.

Full debdiff attached, thanks in advance!

unblock libetpan/1.9.3-2

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libetpan-1.9.3/debian/changelog libetpan-1.9.3/debian/changelog
--- libetpan-1.9.3/debian/changelog 2019-01-26 20:49:11.0 +0100
+++ libetpan-1.9.3/debian/changelog 2019-05-06 23:27:54.0 +0200
@@ -1,3 +1,11 @@
+libetpan (1.9.3-2) unstable; urgency=high
+
+  * debian/patches/90_fix_tls_timeout.diff
+  - Add upstream patch to fix TLS timeout (Closes: #927709)
+  * Raised changelog urgency because of serious bug
+
+ -- Ricardo Mones   Mon, 06 May 2019 23:27:54 +0200
+
 libetpan (1.9.3-1) unstable; urgency=medium
 
   * New upstream version 1.9.3
diff -Nru libetpan-1.9.3/debian/patches/90_fix_tls_timeout.diff 
libetpan-1.9.3/debian/patches/90_fix_tls_timeout.diff
--- libetpan-1.9.3/debian/patches/90_fix_tls_timeout.diff   1970-01-01 
01:00:00.0 +0100
+++ libetpan-1.9.3/debian/patches/90_fix_tls_timeout.diff   2019-05-06 
23:27:54.0 +0200
@@ -0,0 +1,19 @@
+Origin: 
https://github.com/dinhviethoa/libetpan/commit/4aee22436809af67f23170fe15106b91ff2971e6
+Subject: Fix TLS timeouts with recent versions of GnuTLS
+ gnutls_handshake_set_timeout takes a timeout value in ms, but we were
+ providing a value in seconds. This means that on new-enough platforms
+ that use GnuTLS (e.g., Debian Buster), we would accidentally configure
+ a timeout 1,000 times shorter than requested.
+Bug-Debian: https://bugs.debian.org/927709
+
+--- a/src/data-types/mailstream_ssl.c
 b/src/data-types/mailstream_ssl.c
+@@ -636,7 +636,7 @@ static struct mailstream_ssl_data * ssl_data_new(int fd, 
time_t timeout,
+   timeout_value = mailstream_network_delay.tv_sec * 1000 + 
mailstream_network_delay.tv_usec / 1000;
+   }
+   else {
+-  timeout_value = timeout;
++  timeout_value = timeout * 1000;
+   }
+ #if GNUTLS_VERSION_NUMBER >= 0x030100
+   gnutls_handshake_set_timeout(session, timeout_value);
diff -Nru libetpan-1.9.3/debian/patches/series 
libetpan-1.9.3/debian/patches/series
--- libetpan-1.9.3/debian/patches/series2019-01-26 20:49:11.0 
+0100
+++ libetpan-1.9.3/debian/patches/series2019-05-06 23:27:54.0 
+0200
@@ -1,3 +1,4 @@
 # 10_unnecessary_linkage.diff
 11_use_openjade.diff
 12_add_dummy_readme.diff
+90_fix_tls_timeout.diff


Bug#928547: mailscripts: notmuch utilities should be better integrated into notmuch

2019-05-06 Thread Daniel Kahn Gillmor
Package: mailscripts
Severity: wishlist
Control: affects -1 notmuch

notmuch-{import-patch,extract-patch,slurpdebbug} could all be "notmuch"
subcommands, similar to the way that notmuch-emacs-mua is.  their
configuration could also be stored in notmuch's own configuration,
rather than in ~/.config/mailscripts.  that would make them nicer for
folks already using notmuch. (and for folks not using notmuch, those
tools aren't very useful ;) )

Making this a tighter integration would mean maybe fixing up "notmuch
help" (so that it learns about any installed subcommand extensions and
at least tries their manual pages), and maybe fixing the notmuch bash
tab completion as well.

also, it's not clear whether the configuration should be stored in the
config file for notmuch, or in the database.  I still believe we should
be getting rid of the config file if possible and storing most config in
the database, so i'd prefer to not store anything in the config file.

   --dkg


signature.asc
Description: PGP signature


Bug#928509: Firefox insecure because of missing extensions

2019-05-06 Thread Sylvain Beucler
Hi,

On 06/05/2019 15:47, Hideki Yamane wrote:
> On Mon, 6 May 2019 15:04:09 +0200 Karsten  wrote:
>> Package: firefox-esr
>> Version: 60.6.1esr-1~deb8u1
>  It was already done in unstable and stable-proposed-updates, and
>  reporter asks about oldstable, so CC:ed to lts mailing list.
>  
>  LTS maintainers, could you build it for oldstable, please?
I'm rebuilding the new version with the previous oldstable changes.
(any estimated time for parallel build 4CPU/SSD?)

If the build succeeds and if I can install extensions again, I'll upload
to LTS.

Cheers!
Sylvain



Bug#519076: lightyears: gameplay becomes too fast (for me)

2019-05-06 Thread Steve Cotton
On Tue, Mar 10, 2009 at 10:44:32PM +1300, Jasen Betts wrote:
> Package: lightyears
> Version: 1.3a-4
> 
> help! how can I slow down the gameplay or is it meant to be frantic?

This bug report is now 10 years old, but some comments (based on version 1.4):

The game can be treated as a puzzle, there's a strategy that makes it not 
frantic, even on expert mode (although I think the random events can sometimes 
make it impossible).

Some of the hints in the tutorial seem to be wrong.  Upgrading the nodes is 
important, and unupgraded nodes can reduce the steam pressure - when connected 
to another node that's at a high pressure, steam flows to the low pressure 
node, and is then lost if the node can't hold the pressure. 

Solution to the puzzle, encoded as it's a spoiler:

echo c3RhciB0b3BvbG9neSwgdXBncmFkZSBwaXBlcyB0b28K | base64 -d

Steve



Bug#928546: /etc/fstab.d

2019-05-06 Thread john.pseudonym1
Package: util-linux
Version: 2.29.2-1
Severity: normal

Hi,

As part of the hardening of an anonymity focused operating system called 
Whonix, we need to add different mount options for different filesystems e.g. 
hidepid=2 on /proc or noexec on /home. To make sure that a user's own fstab 
configurations are not messed up, we cannot use /etc/fstab for this. 
/etc/fstab.d would be the perfect thing for this but it seems that support for 
it has been 
[abandoned](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663623). Will 
support for this ever be brought back? If not, are there any good alternatives?

Best regards.

Bug#870644: openjpeg2: Make source package bootstrappable

2019-05-06 Thread Helmut Grohne
Source: openjpeg2
Version: 2.3.0-2
Followup-For: Bug #870644
Tags: patch

Here is a patch to demote the java stuff to Build-Depends-Indep. There
is no build profile necessary for these dependencies as one can simply
perform an arch-only build first and a full build later.

Helmut
diff --minimal -Nru openjpeg2-2.3.0/debian/changelog 
openjpeg2-2.3.0/debian/changelog
--- openjpeg2-2.3.0/debian/changelog2019-03-10 18:34:51.0 +0100
+++ openjpeg2-2.3.0/debian/changelog2019-05-06 22:36:49.0 +0200
@@ -1,3 +1,10 @@
+openjpeg2 (2.3.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote java dependencies to Build-Depends-Indep. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 06 May 2019 22:36:49 +0200
+
 openjpeg2 (2.3.0-2) unstable; urgency=high
 
   [ Hugo Lefeuvre ]
diff --minimal -Nru openjpeg2-2.3.0/debian/control 
openjpeg2-2.3.0/debian/control
--- openjpeg2-2.3.0/debian/control  2019-03-10 18:34:29.0 +0100
+++ openjpeg2-2.3.0/debian/control  2019-05-06 22:36:49.0 +0200
@@ -5,17 +5,18 @@
 Homepage: http://www.openjpeg.org
 Build-Depends: cmake (>= 2.8.2),
debhelper (>= 9),
-   default-jdk,
dh-apache2,
help2man,
-   javahelper (>= 0.37~),
libcurl4-gnutls-dev | libcurl-ssl-dev,
libfcgi-dev,
liblcms2-dev,
libpng-dev,
libtiff-dev,
-   libxerces2-java,
zlib1g-dev
+Build-Depends-Indep:
+   default-jdk,
+   javahelper (>= 0.37~),
+   libxerces2-java,
 Standards-Version: 4.1.0
 Section: libs
 Vcs-Browser: 
http://anonscm.debian.org/viewvc/collab-maint/deb-maint/openjpeg2/trunk/
diff --minimal -Nru openjpeg2-2.3.0/debian/rules openjpeg2-2.3.0/debian/rules
--- openjpeg2-2.3.0/debian/rules2017-10-16 07:43:41.0 +0200
+++ openjpeg2-2.3.0/debian/rules2019-05-06 22:36:49.0 +0200
@@ -7,7 +7,8 @@
 export DEB_CFLAGS_MAINT_APPEND = -fvisibility=hidden
 
 %:
-   dh $@ --parallel --with apache2,javahelper
+   dh $@ --parallel --with apache2 $(DH_ADDONS)
+build binary %-indep: DH_ADDONS=--with=javahelper
 
 CMAKE_EXTRA_FLAGS += -DCMAKE_SKIP_RPATH=ON \
   -DCMAKE_BUILD_TYPE:STRING=None \


Bug#928353: Fwd: release-notes: document mutt vs neomutt in buster

2019-05-06 Thread Justin B Rye
Antonio Radici wrote:
> This is what I propose to write down in the release notes, feel free to adjust
> as you see fit

Thanks!
> 
> 
> Starting from Buster, the mutt package will be shipped again from the original
> sources from https://www.mutt.org, this means that some of the features that
> were previously available due to patches applied to the mutt project, which we
> shipped as 'mutt' for the Stretch release, are no longer availables and that
> your configuration might be broken.
>
> If you want to restore the previous behavior you can install the 'neomutt'
> package which will ship the '/usr/bin/neomutt' binary; that is built off the
> sources from https://www.neomutt.org.

This describes things in an odd order.  Could we explain the Stretch
situation first, *then* what's happening in Buster?  And that
explanation needs to include the fact that the source of the patches
applied to the Debian mutt package was neomutt.  Something like:

  

mutt and neomutt

  In stretch, the package mutt
  had patches applied from the sources at https://www.neomutt.org;>https://www.neomutt.org. Starting
  from buster, the package providing /usr/bin/mutt will
  instead be purely based on the original sources from https://www.mutt.org;>https://www.mutt.org, and a separate
  neomutt package is available
  providing /usr/bin/neomutt.


  This means that some of the features that were previously provided by
  mutt are no longer available. If
  this breaks your configuration you can install neomutt instead.

  

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#928526: linux-image-4.19.0-4-amd64: data corruption when swapping to encrypted SSD with LVM and TRIM enabled

2019-05-06 Thread Simon Richter
Hi,

On 06.05.19 21:35, Simon Richter wrote:

> I can probably test intermediate versions and/or changes in setup, but this
> is difficult to automate because "bad" runs require manual file system
> repairs and every run requires LUKS setup to be repeated.

FWIW, using a separate LV and swapon --discard=pages seems to work, so
this is likely to be specific to swap files (which normally shouldn't be
affected by discards, as their allocation doesn't change, but the kernel
might have some default behaviour here that I'm not aware of).

   Simon



signature.asc
Description: OpenPGP digital signature


Bug#928401: [pre-approval] unblock: manpages/4.16-2

2019-05-06 Thread Paul Gevers
Control: tags -1 confirmed moreinfo

On 03-05-2019 23:28, Dr. Tobias Quathamer wrote:
> Am 03.05.19 um 22:58 schrieb Dr. Tobias Quathamer:
>> I've attached the .dsc debdiff. I can confirm that the debdiff of the
>> binary packages shows the newly included manpages.
> 
> ... however, the Replaces/Breaks have not been in the correct binary
> package stanza. Please take a look at the new debdiff. Sorry.

Please continue with the upload and remove the moreinfo tag once the
package is available in unstable.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928545: graphite2 has a dependency cycle with python3-fonttools

2019-05-06 Thread Helmut Grohne
Source: graphite2
Version: 1.3.13-7
Severity: important
Tags: patch

graphite2 Build-Depends on python3-fonttools, whose installation set
contains libgraphite2-3. That's bad for bootstrapping. It turns out that
graphite2 only needs python3-fonttools for running tests. Thus the
dependency can be annotated with . Please consider applying
the attached patch.

Helmut
diff --minimal -Nru graphite2-1.3.13/debian/changelog 
graphite2-1.3.13/debian/changelog
--- graphite2-1.3.13/debian/changelog   2019-01-15 21:08:22.0 +0100
+++ graphite2-1.3.13/debian/changelog   2019-05-06 22:19:07.0 +0200
@@ -1,3 +1,10 @@
+graphite2 (1.3.13-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends: python3-fonttools with . (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 06 May 2019 22:19:07 +0200
+
 graphite2 (1.3.13-7) unstable; urgency=medium
 
   * revert debian/patches/revert-49fce465ae4ee921f81e9fb8270177c16849a3e9.diff
diff --minimal -Nru graphite2-1.3.13/debian/control 
graphite2-1.3.13/debian/control
--- graphite2-1.3.13/debian/control 2019-01-09 23:55:48.0 +0100
+++ graphite2-1.3.13/debian/control 2019-05-06 22:19:05.0 +0200
@@ -3,7 +3,7 @@
 Section: libs
 Maintainer: Debian LibreOffice Maintainers 
 Uploaders: Rene Engelhard , Daniel Glassey 
-Build-Depends: debhelper (>= 9.20151219), dh-exec (>= 0.3), dpkg-dev (>= 
1.18.2~), cmake, python3 (>= 3.6), python3-fonttools, dh-python
+Build-Depends: debhelper (>= 9.20151219), dh-exec (>= 0.3), dpkg-dev (>= 
1.18.2~), cmake, python3 (>= 3.6), python3-fonttools , dh-python
 Build-Depends-Indep: asciidoc-dblatex, doxygen, docbook-xsl, 
texlive-latex-recommended, libxml2-utils, graphviz, python3-all, 
python3-setuptools
 Standards-Version: 4.1.0
 Homepage: http://graphite.sil.org/


Bug#928351: unblock dhcpcd5/7.1.0-2

2019-05-06 Thread Paul Gevers
Control: tags -1 moreinfo confirmed

Hi Scott,

On 06-05-2019 05:30, Scott Leggett wrote:
> On 2019-05-05.20:47, Salvatore Bonaccorso wrote:
>> As for all those CVEs are known (see respective bugs and
>> security-tracker), can you please add the rspective CVE ids as well to
>> the debian/changelog enttries?
> 
> Done, see amended debdiff attached.

Please go ahead and upload. Remove the moreinfo tag when you package is
available in unstable.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#926878: Bug

2019-05-06 Thread Paul Gevers
Hmm.

On 06-05-2019 21:52, Paul Gevers wrote:
> Also make sure you can help them moving forward with their unblock
> request, by making sure your *targeted* fixes are available in unstable.
> sa-exim would need to be unblocked first or at the same time, so don't
> add unnecessary changes to your package and file an unblock request when
> your package lands in unstable.

While typing the above, it seems that I mis-remembered the situation a
bit. Just to get it clear, is or is not your package currently broken in
buster? In other words, from sa-exim point of view, would you need an
improved exim package in buster?

If the answer to the above is no, the sa-exim package is fine, you want
to remove the "buster" tag from bug 926952 to prevent autoremoval from
buster. You also want to make sure that the severity of the bugs in
sa-exim are correct. As far as I can see at this moment, you only have
severity normal bugs.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928353: Fwd: release-notes: document mutt vs neomutt in buster

2019-05-06 Thread Antonio Radici
This is what I propose to write down in the release notes, feel free to adjust
as you see fit


Starting from Buster, the mutt package will be shipped again from the original
sources from https://www.mutt.org, this means that some of the features that
were previously available due to patches applied to the mutt project, which we
shipped as 'mutt' for the Stretch release, are no longer availables and that
your configuration might be broken.

If you want to restore the previous behavior you can install the 'neomutt'
package which will ship the '/usr/bin/neomutt' binary; that is built off the
sources from https://www.neomutt.org.




Bug#928544: debsources: wheezy gone missing

2019-05-06 Thread Jakub Wilk

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: debsources

Some (all?) wheezy packages have disappeared from sources.d.o.

For example, there's no wheezy package here:
https://sources.debian.org/src/bash/

It used to be there in the past:
https://web.archive.org/web/20180624202111/https://sources.debian.org/src/bash/

--
Jakub Wilk



Bug#928543: ucarp should depend on ifupdown|ifupdown2 instead of versioned ifupdown only

2019-05-06 Thread George Diamantopoulos
Package: ucarp
Version: 1.5.2-2.2
Severity: important

Dear Maintainer,

ucarp has the following 'Depends:' directive in its control file:
  Depends: ifupdown (>= 0.7.1)

ifupdown2 provides this as a virtual package:
  Provides: ifupdown

Since ifupdown2 does not use a versioned 'Provides:' directive, installation
of ucarp will have unsatisfied dependencies on systems with ifupdown2 installed.
This happens because a non-versioned Provides: directive cannot satisfy a 
versioned
Depends: directive, and ifupdown/ifupdown2 packages are mutually exclusive
so only one is installed on a system at any given time.

I reached out to ifupdown2 upstream and asked that they use a versioned 
"Provides"
with their package to overcome this problem:
  https://github.com/CumulusNetworks/ifupdown2/issues/100

However, they said that they have encountered issues with versioned Provides:,
additionally stating explicitly that these issues affect ucarp as well.
Their recommendation was to fix this by having ucarp depend on either
ifupdown or ifupdown2 instead.

Would you consider changing the "Depends:" directive to:
  Depends: ifupdown (>= 0.7.1) | ifupdown2
?

I have used ucarp for a while now with ifupdown2 and I haven't run into any 
issues
so far.

If you are positively inclined to make this change, I would greatly appreciate 
it
if it were to be included in the buster release.

Lastly, please note that the System Information provided by reportbug below 
concerns
a stretch machine on which I have installed a custom-built ucarp .deb package
which already includes the proposed change.

Thank you in advance.

Best regards,
George Diamantopoulos


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

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

Versions of packages ucarp depends on:
ii  ifupdown2 [ifupdown]  1.2.5-1
ii  libc6 2.24-11+deb9u4
ii  libpcap0.81.8.1-3

Versions of packages ucarp recommends:
ii  iproute2  4.9.0-1+deb9u1

ucarp suggests no packages.

-- no debconf information



Bug#926878: Bug

2019-05-06 Thread Paul Gevers
Hi Magnus,

On 05-05-2019 23:42, Magnus Holmgren wrote:
> after some investigation, I believe I have the issues in sa-exim under 
> control. The broken spool files were due to a memory corruption that could 
> easily be worked around. The issue with CHUNKING was mainly that SpamAssassin 
> uses CRLF to terminate header lines when the input message uses CRLF line 
> endings, and the CR needs to be stripped. With this taken care of, I don't 
> think SA-Exim is so buggy that it needs be removed from Debian. It does have 
> a 
> couple of advantages over the built-in spam ACL conditions, as outlined in 
> README.Debian.

I expect that for your package to remain useful the exim maintainers
will have to drop the changes that are currently in unstable, am I
right? Please align that with them.

Also make sure you can help them moving forward with their unblock
request, by making sure your *targeted* fixes are available in unstable.
sa-exim would need to be unblocked first or at the same time, so don't
add unnecessary changes to your package and file an unblock request when
your package lands in unstable.

If your changes are acceptable and accepted your package won't be
dropped from buster, but until that happens, autoremoval may still
remove your package and we may remove your package if fixing it stalls
the release process. Please keep the ball rolling.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928539: O: wmail -- WindowMaker docklet watching your inbox

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of wmail, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: wmail
Binary: wmail
Version: 2.0-3.1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 4.0.0), libdockapp-dev, libx11-dev, libxt-dev
Architecture: any
Standards-Version: 3.9.6
Format: 1.0
Files:
 d3c573da17da43ec2aa384835e7c6b01 1628 wmail_2.0-3.1.dsc
 a4eb33712e0650e79ffdffce2c9a1e4c 46468 wmail_2.0.orig.tar.gz
 186896c09b83a09d7603239de3dbbab1 27005 wmail_2.0-3.1.diff.gz
Checksums-Sha256:
 7f4a33229aef914b7f060d95c9ba676fa8c3a9ca1928dc45a69a230fcd2b3996 1628 
wmail_2.0-3.1.dsc
 edcf77bf6a638b96dbd78efe4802d260a68385ab2deb6d6774e325ea0cd3d245 46468 
wmail_2.0.orig.tar.gz
 628c7eecb2a7d495459afe3ee6612cb917fa41dc71439f0531b873d4acbb4c34 27005 
wmail_2.0-3.1.diff.gz
Package-List: 
 wmail deb x11 optional arch=any
Directory: pool/main/w/wmail
Priority: source
Section: x11

Package: wmail
Source: wmail (2.0-3.1)
Version: 2.0-3.1+b1
Installed-Size: 96
Maintainer: Julien Danjou 
Architecture: amd64
Depends: libc6 (>= 2.14), libdockapp3 (>= 0.6.2), libx11-6
Description-en: WindowMaker docklet watching your inbox
 wmail is a Window Maker docklet watching your inbox, which is either a
 ordinary mbox or a directory conforming to qmails Maildir format. It
 provides a nice little GUI displaying some useful pieces of information
 about your inbox (as many other nice wm-apps doing nearly the same
 thing...). Per default it uses the $MAIL environment-variable to locate
 the inbox you are using, other mailing mechanisms like POP or IMAP are
 not supported - use a tool like fetchmail to retrieve POP- or IMAP-based
 mail.
Description-md5: 64e63edc341f29ce54121224b8edf619
Tag: interface::graphical, interface::x11, mail::notification, role::program,
 scope::utility, suite::gnustep, uitoolkit::xlib, works-with::mail,
 x11::applet
Section: x11
Priority: optional
Filename: pool/main/w/wmail/wmail_2.0-3.1+b1_amd64.deb
Size: 27274
MD5sum: 23f1fdd1e4f615987ece296fb3a6780e
SHA256: affe2659852660f6a7a9d146227f16597a09124a3005cab84d30acb10ea6ce92



Bug#928538: O: xpyb -- Python bindings to XCB

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of xpyb, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: xpyb
Binary: python-xpyb
Version: 1.3.1-1.1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 7.0.50~), automake, autoconf, xcb-proto (>= 
1.7.1), libtool, pkg-config, libxcb1-dev (>= 1.1), python-all-dev (>= 2.5), 
dh-python, python-xcbgen (>= 1.7.1)
Architecture: any
Standards-Version: 3.9.3
Format: 3.0 (quilt)
Files:
 662eb6de6c7f6cb84b265b25d546b1c9 1802 xpyb_1.3.1-1.1.dsc
 612a3433da2226789c76c140fc4d75f9 24852 xpyb_1.3.1.orig.tar.xz
 f0b3706dc4bec186234ddb34ccdfc0f0 1708 xpyb_1.3.1-1.1.debian.tar.xz
Checksums-Sha256:
 96a74e6509b7efc2b0eadc7768e6a79307d7cef3a372dc3950e6b2c26fff0498 1802 
xpyb_1.3.1-1.1.dsc
 940e534dff69ab453487d82af6ebb0d478e74ef9201237bbf7a1a12d519609fc 24852 
xpyb_1.3.1.orig.tar.xz
 7133a496390d18335bd540e1fa5d0f50d17d59039b90aaceba58517afa1c12eb 1708 
xpyb_1.3.1-1.1.debian.tar.xz
Homepage: http://xcb.freedesktop.org
Package-List: 
 python-xpyb deb python optional arch=any
Directory: pool/main/x/xpyb
Priority: source
Section: python

Package: python-xpyb
Source: xpyb
Version: 1.3.1-1.1
Installed-Size: 567
Maintainer: Julien Danjou 
Architecture: amd64
Provides: python2.7-xpyb
Depends: libc6 (>= 2.14), libxcb1 (>= 1.6), python (<< 2.8), python (>= 2.7~), 
python:any (>= 2.7.5-5~)
Description-en: Python bindings to XCB
 This module provides Python binding to libxcb, the X C Bindings library.
 .
 It provides an interface to the X Window System protocol, designed to replace
 the Xlib interface, featuring latency hiding, small size, direct protocol
 access and thread support.
Description-md5: a5f362c7cba3a8486cb97766fc7f0d66
Homepage: http://xcb.freedesktop.org
Section: python
Priority: optional
Filename: pool/main/x/xpyb/python-xpyb_1.3.1-1.1_amd64.deb
Size: 57790
MD5sum: 7468d4de0d2ab570cb60c329a3c916bd
SHA256: 3b30a07b3a583fb6ac17a0b50ccfa77bea9e9158df60ad7f791e378615fa258c



Bug#928541: O: commando -- wrapper for argparse to define declaratively (Python 2)

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of commando, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: commando
Binary: python-commando, python3-commando
Version: 1.0.0-0.2
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 10), dh-python, python-all, python-fswrap, 
python-markdown, python-mock, python-nose, python-setuptools, python-yaml, 
python3-all, python3-fswrap, python3-markdown, python3-mock, python3-nose, 
python3-setuptools, python3-yaml
Architecture: all
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 5b86b0ec3abde82698f564956355a9b5 1873 commando_1.0.0-0.2.dsc
 0ba5d7c211dfa1c8e53ff99e08f33bac 13522 commando_1.0.0.orig.tar.gz
 841cf6c4f703f6ae379abdeee95866bb 2880 commando_1.0.0-0.2.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=collab-maint/commando.git;a=summary
Vcs-Git: git://git.debian.org/collab-maint/commando.git
Checksums-Sha256:
 864f503237e757b4ca3b5f56d8cf0bc120c057c4e26fdac4bd5982b5a009b87e 1873 
commando_1.0.0-0.2.dsc
 3cc802fc8c13d562d9de3ad9246da3f5931cc99c07cc9cc8a70cd0a816f75682 13522 
commando_1.0.0.orig.tar.gz
 b55fcb8c997c95c2b0c33f384e39fbdba5f0d9baf93377c65e07c53e901782bf 2880 
commando_1.0.0-0.2.debian.tar.xz
Homepage: https://github.com/hyde/commando
Dgit: eafd339948912bbb1979f8295f4bf621ae956349 debian archive/debian/1.0.0-0.2 
https://git.dgit.debian.org/commando
Package-List: 
 python-commando deb python extra arch=all
 python3-commando deb python extra arch=all
Directory: pool/main/c/commando
Priority: source
Section: python

Package: python-commando
Source: commando
Version: 1.0.0-0.2
Installed-Size: 51
Maintainer: Julien Danjou 
Architecture: all
Depends: python (>= 2.7) | python-argparse, python2.7, python:any (<< 2.8), 
python:any (>= 2.7.5-5~)
Description-en: wrapper for argparse to define declaratively (Python 2)
 A simple wrapper for `argparse` that allows commands and arguments to be
 defined declaratively using decorators. Note that this does not support all
 the features of `argparse` yet.
 .
 This package is for Python 2.
Description-md5: 617c26d34ea168e2f6e98b37f1479e33
Homepage: https://github.com/hyde/commando
Section: python
Priority: optional
Filename: pool/main/c/commando/python-commando_1.0.0-0.2_all.deb
Size: 11142
MD5sum: 3245604536a6afe9499aff20c72c4dc4
SHA256: 3d8d2bb6e3cfde864a133e90795f3f97c7199df109dcd090c3469bee89e31551

Package: python3-commando
Source: commando
Version: 1.0.0-0.2
Installed-Size: 51
Maintainer: Julien Danjou 
Architecture: all
Depends: python3:any (>= 3.3.2-2~)
Description-en: wrapper for argparse to define declaratively (Python 3)
 A simple wrapper for `argparse` that allows commands and arguments to be
 defined declaratively using decorators. Note that this does not support all
 the features of `argparse` yet.
 .
 This package is for Python 3.
Description-md5: 70091b6fa7dd873eafff3de064c3a3fa
Homepage: https://github.com/hyde/commando
Section: python
Priority: extra
Filename: pool/main/c/commando/python3-commando_1.0.0-0.2_all.deb
Size: 11204
MD5sum: 24ac26dcd1ac11661fe2e68108a97957
SHA256: f662798111c9bbab3891bc19bf8d0faadbf712052a97569d29bee4cd0789e711



Bug#928540: O: webcamd -- Capture images from video devices

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of webcamd, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: webcamd
Binary: webcamd
Version: 0.7.6-5.2
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 10~)
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 0a27b2217bed2e652ce1527c75ad77ed 1392 webcamd_0.7.6-5.2.dsc
 78d0185b67e72119b1f231ef2c099ea2 10839 webcamd_0.7.6-5.2.tar.gz
Checksums-Sha256:
 11b3b0d7a0e443cbca5e3271370baa94267cd34a00e877c9c504645636d4a455 1392 
webcamd_0.7.6-5.2.dsc
 81ff325312d665772b263c3f2814b0d218de94706adbaa73b93ebb7654dd3981 10839 
webcamd_0.7.6-5.2.tar.gz
Package-List: 
 webcamd deb net optional arch=all
Directory: pool/main/w/webcamd
Priority: source
Section: net

Package: webcamd
Version: 0.7.6-5.2
Installed-Size: 42
Maintainer: Julien Danjou 
Architecture: all
Depends: perlmagick, perl, xawtv, libnet-perl
Description-en: Capture images from video devices
 webcamd take images from your webcam and put it in your
 local web directory or upload it by FTP.
Description-md5: b16a6570bceeef674adcc8cc89ce7052
Tag: hardware::camera, interface::daemon, network::server, protocol::ftp,
 role::program
Section: net
Priority: optional
Filename: pool/main/w/webcamd/webcamd_0.7.6-5.2_all.deb
Size: 10940
MD5sum: d8e3b2c8831c885f27d75478af1531be
SHA256: 3b779b8106581834250a37c27dc2ea9fdd7b18bd790d6f16a4a9e8e499a18880



Bug#928542: O: python-fswrap -- unified object oriented interface to file system objects

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of python-fswrap, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: python-fswrap
Binary: python-fswrap, python3-fswrap
Version: 1.0.1-0.2
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 9), python-all, python-nose, python-pkg-resources, 
python-setuptools, python3-all, python3-nose, python3-pkg-resources, 
python3-setuptools
Architecture: all
Standards-Version: 4.0.0
Format: 3.0 (quilt)
Files:
 563edb89d41e7898be21b49c6b0a0e33 1867 python-fswrap_1.0.1-0.2.dsc
 97cdd8b909b3d8b260f262dce0292704 28097 python-fswrap_1.0.1.orig.tar.gz
 2330d7a42183e0d349d614059231ea8e 2224 python-fswrap_1.0.1-0.2.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/python-fswrap
Vcs-Git: https://salsa.debian.org/debian/python-fswrap
Checksums-Sha256:
 afcce94fa453ead86cb1b3b625b26b47db65eb18f5022c3fe33362b5278abdcf 1867 
python-fswrap_1.0.1-0.2.dsc
 623effe0aae2770e0c51c99147d7f4ccdb45aba68985d872edb765b59733287f 28097 
python-fswrap_1.0.1.orig.tar.gz
 d6cea103b5513da9fe493afa2a8c7118f42bee83122a5bf253a616348456af3c 2224 
python-fswrap_1.0.1-0.2.debian.tar.xz
Homepage: https://github.com/hyde/fswrap
Dgit: 036c668431f652f24940a49d3f76a5ec6349c46f debian archive/debian/1.0.1-0.2 
https://git.dgit.debian.org/python-fswrap
Package-List: 
 python-fswrap deb python extra arch=all
 python3-fswrap deb python extra arch=all
Testsuite: autopkgtest-pkg-python
Directory: pool/main/p/python-fswrap
Priority: optional
Section: misc

Package: python-fswrap
Version: 1.0.1-0.2
Installed-Size: 38
Maintainer: Julien Danjou 
Architecture: all
Provides: python2.7-fswrap
Depends: python (<< 2.8), python (>= 2.7), python:any (>= 2.6.6-7~)
Description-en: unified object oriented interface to file system objects
 File system operations in Python are distributed across modules: os,
 os.path, fnmatch, shutil and distutils. This module attempts to make the
 right choices for common operations to provide a single interface.
 .
 This package is for Python 2.
Description-md5: 5c394c978a0d5696eb692176d6858271
Homepage: https://github.com/hyde/fswrap
Section: python
Priority: optional
Filename: pool/main/p/python-fswrap/python-fswrap_1.0.1-0.2_all.deb
Size: 7760
MD5sum: 54144e835fb49d33c1c6072a4c9c7d14
SHA256: 9d9157ee74a81901bdf78275d3bf60a17f08efd9177caac01ab485ccd13d3f89

Package: python3-fswrap
Source: python-fswrap
Version: 1.0.1-0.2
Installed-Size: 38
Maintainer: Julien Danjou 
Architecture: all
Depends: python3:any (>= 3.3.2-2~), python3-distutils
Description-en: unified object oriented interface to file system objects 
(Python 3)
 File system operations in Python are distributed across modules: os,
 os.path, fnmatch, shutil and distutils. This module attempts to make the
 right choices for common operations to provide a single interface.
 .
 This package is for Python 3.
Description-md5: 0c8e04b86160f0dcf956bcc6e269c9ae
Homepage: https://github.com/hyde/fswrap
Section: python
Priority: extra
Filename: pool/main/p/python-fswrap/python3-fswrap_1.0.1-0.2_all.deb
Size: 7836
MD5sum: 7f4512dfc40acfaca84b5ded61ba79c5
SHA256: 1a481e92e0045a90ce659b89fbdd82504ccb9d6dfe822b2027583d4dc6438f95



Bug#928537: O: el-get -- install and manage elisp code for Emacs

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of el-get, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: el-get
Binary: el-get
Version: 3.1-1.1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 7.0.50~)
Architecture: all
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 2533ba9080be02d77bbd3896b24a37cc 1791 el-get_3.1-1.1.dsc
 0182c7d3ac3e3c31b3f0fdf2d381a9f0 61830 el-get_3.1.orig.tar.bz2
 aab0fbe943ca6a4d0ff200dc3c1099c8 3004 el-get_3.1-1.1.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=users/acid/el-get.git;a=summary
Vcs-Git: git://git.debian.org/users/acid/el-get.git
Checksums-Sha256:
 009bba3318ee1ac36e01bd75c206fb0f8ebfef522202255cecefe47ccd8097b5 1791 
el-get_3.1-1.1.dsc
 68de54f9c4d5e15e7064982f5750ae3be99d74c65893517a3eb4a8fc6d267751 61830 
el-get_3.1.orig.tar.bz2
 3b2f44144530a26a32367eb4857011a37879685131badbe951c9f2bec02ded88 3004 
el-get_3.1-1.1.debian.tar.xz
Homepage: http://github.com/dimitri/el-get/
Package-List: 
 el-get deb editors extra arch=all
Directory: pool/main/e/el-get
Priority: source
Section: editors

Package: el-get
Version: 3.1-1.1
Installed-Size: 349
Maintainer: Julien Danjou 
Architecture: all
Depends: emacs | emacsen
Description-en: install and manage elisp code for Emacs
 Allows you to install and manage elisp code for Emacs. It supports lots of
 differents types of sources and is able to 'install' them, 'update' them
 and 'remove' them, but more importantly it will 'init' them for you.
 .
 That means it will care about requiring the 'features' you need, loading
 the files, setting the 'Info' paths so that C-h i shows the new
 documentation you now depend on, and finally call your own :after function
 for you to setup the extension.
Description-md5: a6ae62ad92bab2937c57b972fd519f60
Homepage: http://github.com/dimitri/el-get/
Section: editors
Priority: optional
Filename: pool/main/e/el-get/el-get_3.1-1.1_all.deb
Size: 83224
MD5sum: 0293e6df4a1d605f2e30a255f6f3252b
SHA256: d450130ed61e9d589b41b168fffadfc26e0b79e55927eab95cb99cc72030ed1f



Bug#928529: O: sysrqd -- small daemon intended to manage Linux SysRq over network

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of sysrqd, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: sysrqd
Binary: sysrqd
Version: 14-1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 7.0.0)
Architecture: any
Standards-Version: 3.8.4
Format: 3.0 (quilt)
Files:
 aff88c2256137d10b147c5357ff0ad70 935 sysrqd_14-1.dsc
 85d5f304d35f788dbf4a96e1c2ec3e15 4805 sysrqd_14.orig.tar.gz
 9e379effaf81ae81c9fddbb16f99b630 2645 sysrqd_14-1.debian.tar.gz
Checksums-Sha256:
 01992da45de838b6a469be4262d72ff43077a183315c786a4f63836725f6b236 935 
sysrqd_14-1.dsc
 49d984a41ead4e6cbba66241b1e90dc4d2bb7db12333778e186e890e99f8c2b6 4805 
sysrqd_14.orig.tar.gz
 b98cf22b03d3b0586458c14c60a17652e42259e84b2cf19efe8a46cd9974fa99 2645 
sysrqd_14-1.debian.tar.gz
Directory: pool/main/s/sysrqd
Priority: source
Section: admin

Package: sysrqd
Source: sysrqd (14-1)
Version: 14-1+b2
Installed-Size: 33
Maintainer: Julien Danjou 
Architecture: amd64
Depends: libc6 (>= 2.2.5)
Description-en: small daemon intended to manage Linux SysRq over network
 Permits to execute usual SysRq commands by network, like:
 sync, umount, reboot, poweroff, sak, term, etc.
 .
 Its philosophy is to be very responsive under heavy load and
 try to be somehow reliable. Authentication is made by clear password.
Description-md5: 4315934805063646d2f44b304b9cbef5
Tag: implemented-in::c, interface::daemon, network::server, role::program,
 scope::utility
Section: admin
Priority: optional
Filename: pool/main/s/sysrqd/sysrqd_14-1+b2_amd64.deb
Size: 8624
MD5sum: 58964bd2a3d918f2fec3c46cddfd8d79
SHA256: f49e6cda68dcc4c842e4f2ea3b0cc3e6cbfa3aeb15d972174775c198452c806e



Bug#928535: O: libapache2-mod-defensible -- module for Apache2 which provides DNSBL usage

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of libapache2-mod-defensible, Julien Danjou 
,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libapache2-mod-defensible
Binary: libapache2-mod-defensible
Version: 1.4-3.1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 5.0.0), dh-apache2, apache2-dev (>= 2.2.3-2)
Architecture: any
Standards-Version: 3.8.0
Format: 3.0 (quilt)
Files:
 3b392310628d110d60aace75d662939a 1898 libapache2-mod-defensible_1.4-3.1.dsc
 966fbf324a5b38ab32da9af6e0f9ff5e 308078 
libapache2-mod-defensible_1.4.orig.tar.gz
 1d40992d83698852e9dc210421536fa2 3509 
libapache2-mod-defensible_1.4-3.1.debian.tar.gz
Checksums-Sha256:
 aed88b32d36a58a0e90bfe64cc0355ddd8e32478f6c4e18f7abd44d256c01532 1898 
libapache2-mod-defensible_1.4-3.1.dsc
 7472cc708962bc94a35c536e15485e33d0e4d174b4180a3c8147bcf1c164ba96 308078 
libapache2-mod-defensible_1.4.orig.tar.gz
 a03242f0e2857a067258898ac416ecec83a3882125bb300c6d6e9b7916490018 3509 
libapache2-mod-defensible_1.4-3.1.debian.tar.gz
Package-List: 
 libapache2-mod-defensible deb web extra
Directory: pool/main/liba/libapache2-mod-defensible
Priority: source
Section: httpd

Package: libapache2-mod-defensible
Version: 1.4-3.1
Installed-Size: 61
Maintainer: Julien Danjou 
Architecture: amd64
Depends: libc6 (>= 2.2.5), apache2-api-20120211
Description-en: module for Apache2 which provides DNSBL usage
 mod_defensible implements usage of DNSBL servers to block access to
 a Web site or to specific locations.
 .
 This package provides the module for Apache 2 server.
Description-md5: 13cd41dcd201668f67914aaa4c02ac88
Tag: role::shared-lib, suite::apache
Section: httpd
Priority: optional
Filename: 
pool/main/liba/libapache2-mod-defensible/libapache2-mod-defensible_1.4-3.1_amd64.deb
Size: 7140
MD5sum: c177acf37ac7f8148ec4fd78f35e3a4c
SHA256: 3bc1a779841510221bf39d16b2a590aff2005b0398c4262a2a8ecdeed1ab3675



Bug#928531: O: varmon -- VA RAID monitor

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of varmon, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: varmon
Binary: varmon
Version: 1.2.1-1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 5), libncurses5-dev
Architecture: any
Standards-Version: 3.8.0
Format: 1.0
Files:
 fce229ef93d97a5372f85ed4bb4f249e 948 varmon_1.2.1-1.dsc
 d930501abfe6f223db381a1720cc2f09 497921 varmon_1.2.1.orig.tar.gz
 fa5efa9ba9d8dc708101ecd6b11fd507 2957 varmon_1.2.1-1.diff.gz
Checksums-Sha256:
 d57b4d3c947f55a1ecbdaee4542933a8da5e2410024265b8aa7fa7937e5ca172 948 
varmon_1.2.1-1.dsc
 7ca2a6faad40e12cbdf140a6cf42e49944abcd840dcc51e0ddb8d76f9b1a0621 497921 
varmon_1.2.1.orig.tar.gz
 ee69f61a36cb424d5b8b74711e056362ec9190491a3c30d7ae3c8444f96b254b 2957 
varmon_1.2.1-1.diff.gz
Directory: pool/main/v/varmon
Priority: source
Section: admin

Package: varmon
Source: varmon (1.2.1-1)
Version: 1.2.1-1+b3
Installed-Size: 519
Maintainer: Julien Danjou 
Architecture: amd64
Depends: libc6 (>= 2.14), libncurses6 (>= 6), libtinfo6 (>= 6)
Description-en: VA RAID monitor
 A text-based tool to monitor DAC 960 RAID controllers. This
 includes Mylex RAID cards from the 960 and 1100 series,
 eXteremeRAID 2000 & 3000, AcceleRAID 352 & 170.
Description-md5: cc05db2005fb6a0b7d2fc23db08b0d81
Tag: admin::monitoring, hardware::storage, role::program, scope::utility,
 uitoolkit::ncurses, use::monitor
Section: admin
Priority: optional
Filename: pool/main/v/varmon/varmon_1.2.1-1+b3_amd64.deb
Size: 481660
MD5sum: 559c55a6701c54c450ba27f902573fb9
SHA256: d3b463a9f046a33aac58226e33849e3fafae4bb0a1d3ff8796afdbaada4ae8e4



Bug#928530: O: duma -- library to detect buffer overruns and under-runs in C and C++ programs

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of duma, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: duma
Binary: duma
Version: 2.5.15-1.1
Maintainer: Julien Danjou 
Build-Depends: cdbs, debhelper (>= 6)
Architecture: any
Standards-Version: 3.8.1
Format: 1.0
Files:
 f39269d8b8afad6b0b0f8a67c7d370ec 1075 duma_2.5.15-1.1.dsc
 fe630c69cbaa39caf225a3d9ed2fda1f 240479 duma_2.5.15.orig.tar.gz
 30264e60e40d05e80206d7f87a1e2e3e 7729 duma_2.5.15-1.1.diff.gz
Vcs-Browser: http://git.debian.org/?p=users/acid/duma.git
Vcs-Git: git://git.debian.org/git/users/acid/duma.git
Checksums-Sha256:
 66232faf71a23f3071be85cdca726825978667c7fcad3c96abdcbdeddb76c793 1075 
duma_2.5.15-1.1.dsc
 baaf794854e3093ad1bddadbfb8ad4b220a7117d70359ee216bd59e353734e17 240479 
duma_2.5.15.orig.tar.gz
 09a4ad85d7df51c9ae4e23b00bb80e4a31471d75f081610ae9d617b95e9db5f6 7729 
duma_2.5.15-1.1.diff.gz
Homepage: http://duma.sf.net
Directory: pool/main/d/duma
Priority: source
Section: devel

Package: duma
Source: duma (2.5.15-1.1)
Version: 2.5.15-1.1+b1
Installed-Size: 249
Maintainer: Julien Danjou 
Architecture: amd64
Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.1.1)
Description-en: library to detect buffer overruns and under-runs in C and C++ 
programs
 Open-source library to detect buffer overruns and under-runs
 in C and C++ programs.
 .
 This library is a fork of Bruce Perens Electric Fence library and adds
 some new features to it. Features of the DUMA library:
   * "overloads" all standard memory allocation functions like
 malloc(), calloc(), memalign(), strdup(), operator new, operator
 new[] and also their counterpart deallocation functions like free(),
 operator delete and operator delete[]
   * utilizes the MMU (memory management unit) of the CPU:
 allocates and protects an extra memory page to detect any illegal
 access beyond the top of the buffer (or bottom, at the user's option)
   * stops the program at exactly that instruction, which does the
 erroneous access to the protected memory page,
 allowing location of the defective source code in a debugger
 detects erroneous writes at the non-protected end of the memory
 block at deallocation of the memory block
   * detects mismatch of allocation/deallocation functions: f.e.
 allocation with malloc() but deallocation with operator delete
   * leak detection: detect memory blocks which were not deallocated
 until program exit
   * preloading of the library
   * allowing tests without necessity of changing source code or recompilation
Description-md5: 9933ed7014c8b166d4e2e4b7ca1c5ff0
Homepage: http://duma.sf.net
Section: devel
Priority: optional
Filename: pool/main/d/duma/duma_2.5.15-1.1+b1_amd64.deb
Size: 63674
MD5sum: 23d3f2966ef4bd84be3edd90517dd149
SHA256: 80d069dada54b25c1e313521960bacd9b8d701162e8fbb52784e6090d30edd4c



Bug#928536: O: python-first -- simple function that returns the first true value from an iterable

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of python-first, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: python-first
Binary: python-first, python3-first
Version: 2.0.0-2
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 8.0.0), python-all, python-setuptools, 
python3-all, python3-setuptools, dpkg-dev (>= 1.16.1~)
Architecture: all
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 f4e6d8a2cda7298a7af3e2fb37b41eba 2002 python-first_2.0.0-2.dsc
 894015e227d749f9f02b43b6d337cc3c 4948 python-first_2.0.0.orig.tar.gz
 578b0e344b19751bc9b501d1cedd7ea0 2563 python-first_2.0.0-2.debian.tar.gz
Vcs-Browser: http://git.debian.org/?p=collab-maint/python-first.git;a=summary
Vcs-Git: git://git.debian.org/collab-maint/python-first.git
Checksums-Sha256:
 5c81fe60102b23e2e0858c6284fb0538a727f60ffce01ba6f1538883ca88dff8 2002 
python-first_2.0.0-2.dsc
 c5711941f8ba8b091e73713eb0b45ddab663c060de324973b4cdd2290a1524ec 4948 
python-first_2.0.0.orig.tar.gz
 d0474eb1220341b4c2716930c86176425894e77e80baf6c8e67b9d0110f08757 2563 
python-first_2.0.0-2.debian.tar.gz
Homepage: https://github.com/hynek/first/
Package-List: 
 python-first deb python extra
 python3-first deb python extra
Directory: pool/main/p/python-first
Priority: optional
Section: misc

Package: python-first
Version: 2.0.0-2
Installed-Size: 63
Maintainer: Julien Danjou 
Architecture: all
Depends: python (>= 2.7), python (<< 2.8)
Description-en: simple function that returns the first true value from an 
iterable
 A MIT licensed Python package with a simple function that returns the
 first true value from an iterable, or None if there is none. If you need
 more power, you can also supply a key function that is used to judge the
 truth value of the element or a default value if None doesn’t fit your
 use case.
Description-md5: e7365c57d26d1c8766a5a5e1e0097533
Homepage: https://github.com/hynek/first/
Section: python
Priority: optional
Filename: pool/main/p/python-first/python-first_2.0.0-2_all.deb
Size: 6482
MD5sum: e6087d09ba28ea54e4f7ff428aba4f26
SHA256: b68c201e1849e398cac3992bd63fa00055590e0d41ae64e80bd523e655e03b08

Package: python3-first
Source: python-first
Version: 2.0.0-2
Installed-Size: 51
Maintainer: Julien Danjou 
Architecture: all
Depends: python3 (>= 3.2.3-3~)
Description-en: simple function that returns the first true value from an 
iterable
 A MIT licensed Python package with a simple function that returns the
 first true value from an iterable, or None if there is none. If you need
 more power, you can also supply a key function that is used to judge the
 truth value of the element or a default value if None doesn’t fit your
 use case.
Description-md5: e7365c57d26d1c8766a5a5e1e0097533
Homepage: https://github.com/hynek/first/
Section: python
Priority: optional
Filename: pool/main/p/python-first/python3-first_2.0.0-2_all.deb
Size: 5896
MD5sum: 32a46701ed3b91dcb08157c35cbf21ce
SHA256: fd58eb2dc73902bf3e2594cb77f6cdbd44be3666efb50740f6e17c805cc5a2a0



Bug#928532: O: rebuildd -- build daemon aiming at rebuilding Debian packages

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of rebuildd, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: rebuildd
Binary: rebuildd
Version: 0.4.2
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 7.0.50~), python, xsltproc, docbook-xsl, 
python-sqlobject, python-apt (>= 0.7.91~)
Architecture: all
Standards-Version: 3.9.3
Format: 3.0 (native)
Files:
 d557bb9081a7fdf540139981d7c3bc25 1645 rebuildd_0.4.2.dsc
 4a8c424004cb28f9c13422a4102820ae 78080 rebuildd_0.4.2.tar.gz
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=rebuildd/rebuildd.git
Vcs-Git: git://anonscm.debian.org/rebuildd/rebuildd.git
Checksums-Sha256:
 10ca7a8552bfb099eca50f138bd75b1699671b7a32e17017e2e2c91d19017c4e 1645 
rebuildd_0.4.2.dsc
 50280c43d24257da0910349480aa585a591fba97ce757e704a02375a9fd5c06e 78080 
rebuildd_0.4.2.tar.gz
Homepage: http://julien.danjou.info/software/rebuildd
Package-List: 
 rebuildd deb devel extra
Directory: pool/main/r/rebuildd
Priority: source
Section: devel

Package: rebuildd
Version: 0.4.2
Installed-Size: 236
Maintainer: Julien Danjou 
Architecture: all
Depends: python (>= 2.6.6-7~), python (<< 2.8), lsb-base, python-sqlobject, 
python-apt (>= 0.7.91~)
Recommends: pbuilder, python-gdchart2, python-webpy
Suggests: cowdancer
Description-en: build daemon aiming at rebuilding Debian packages
 This software allows you to manage a set of jobs. Each job is a package
 rebuilding task. Rebuilding is done by pbuilder (or cowbuilder if you want),
 or anything else, since everything is customizable via configuration file.
 It can also send build logs by email, event each log can be sent to a different
 email address.
 .
 rebuildd is multi-threaded, so you can run multiple build jobs in parallel.
 It is also administrable via a telnet interface. A Web interface is also
 embedded so you can see your jobs queue and watch log file in real-time in your
 browser.
 .
 rebuildd is designed to be run on multiple hosts even with different
 architecture set, and to parallelize the rebuild tasks.
Description-md5: 76d27decd54128ce277621aec3a9fab2
Homepage: http://julien.danjou.info/software/rebuildd
Tag: devel::buildtools, devel::debian, devel::packaging,
 implemented-in::python, interface::daemon, interface::web,
 role::program, suite::debian
Section: devel
Priority: optional
Filename: pool/main/r/rebuildd/rebuildd_0.4.2_all.deb
Size: 28830
MD5sum: 1bfb4759a97a01e95b8da6f40e201be2
SHA256: 514a6b2ed83d195ef6e5502134f9182b9243b3076eb89920a9786260295f7dec



Bug#928533: O: tetrinetx -- game server for Tetrinet

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of tetrinetx, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: tetrinetx
Binary: tetrinetx
Version: 1.13.16-14
Maintainer: Julien Danjou 
Build-Depends: debhelper (>> 5.0.0), libadns1-dev
Architecture: any
Standards-Version: 3.8.0
Format: 1.0
Files:
 a3ba9be2a70b848e0bd80c8a3ecd56c2 1719 tetrinetx_1.13.16-14.dsc
 32e5306bc26afc9e5acdca9c093947c0 81447 tetrinetx_1.13.16.orig.tar.gz
 264d92d3e938ae30c25d137716f6c848 10013 tetrinetx_1.13.16-14.diff.gz
Checksums-Sha256:
 75c34e899727dd00866589f6ad9852b73e57093590bfbc4dc0a35ce4bd6be9ea 1719 
tetrinetx_1.13.16-14.dsc
 2b7210a0c8950c13e648d8abc36b7bca8ce58035999526301a715aacd40d15d4 81447 
tetrinetx_1.13.16.orig.tar.gz
 41a03b611db2ecf8831f5137f4040e89106e66766ca4cf9e316d74c70d16375f 10013 
tetrinetx_1.13.16-14.diff.gz
Homepage: http://tetrinetx.sourceforge.net/
Package-List: 
 tetrinetx deb games optional
Directory: pool/main/t/tetrinetx
Priority: source
Section: games

Package: tetrinetx
Source: tetrinetx (1.13.16-14)
Version: 1.13.16-14+b1
Installed-Size: 183
Maintainer: Julien Danjou 
Architecture: amd64
Depends: libadns1 (>= 1.5.0~), libc6 (>= 2.14)
Suggests: gtetrinet
Description-en: game server for Tetrinet
 Provides a server for hosting Tetrinet games. Tetrinet is a variant of
 Tetris played over the internet. Up to six people may simultaneously connect
 to a server to participate in a game.
 .
 For more information about the Tetrinet game, visit http://www.tetrinet.us/
Description-md5: 731609c616ee10857e8cd56db572cbde
Homepage: http://tetrinetx.sourceforge.net/
Tag: game::tetris, interface::daemon, interface::graphical, interface::x11,
 network::server, role::program, uitoolkit::gtk, use::gameplaying,
 x11::application
Section: games
Priority: optional
Filename: pool/main/t/tetrinetx/tetrinetx_1.13.16-14+b1_amd64.deb
Size: 67334
MD5sum: 8bfc5abc56b528a057f252006c3c2b07
SHA256: e0c8600c6d5f72986f82ee32149a909b7f1af329db0ab3d2ca075bccae34bd43



Bug#928528: O: gsutil -- configure and manage Grandstream BudgeTone 100 VOIP and GX2000 phones

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of gsutil, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: gsutil
Binary: gsutil
Version: 3.1-1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>= 7), quilt
Architecture: all
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 216c9f0fc4bfa29088c6bc2f960e6054 1586 gsutil_3.1-1.dsc
 f2120631d8af97a5b613366292329eee 15237 gsutil_3.1.orig.tar.gz
 172c01e3213b43f59e4b94add7cd48e8 9269 gsutil_3.1-1.debian.tar.gz
Checksums-Sha256:
 8c9ef5fde21925d5220802a96b27ba666746de5bf8ea29ed3625b84737106c51 1586 
gsutil_3.1-1.dsc
 3c1b79a3cd84d9b19353bf82c87c17d4ccfdd17e30894eeb9abca35e47239a66 15237 
gsutil_3.1.orig.tar.gz
 eead77ac51dbefd3c82c8b9219784952ceb10caf9dd72f8aecfe248bb81d82b6 9269 
gsutil_3.1-1.debian.tar.gz
Directory: pool/main/g/gsutil
Priority: source
Section: admin

Package: gsutil
Version: 3.1-1
Installed-Size: 88
Maintainer: Julien Danjou 
Architecture: all
Depends: perl, libhtml-form-perl | libwww-perl (<< 6)
Description-en: configure and manage Grandstream BudgeTone 100 VOIP and GX2000 
phones
 GsUtil is a short program written to dump and restore the data
 from randstream BudgeTone 100 VOIP and GX2000 phone.
 Since a reboot is required to make the configuration change effective,
 this program does that too.
Description-md5: 3891eafadc1ee2365efaf793d68085a2
Tag: role::program
Section: admin
Priority: optional
Filename: pool/main/g/gsutil/gsutil_3.1-1_all.deb
Size: 23010
MD5sum: de97a620979322491dd33b2dd8d96319
SHA256: ed94b9e148d723b113444c75b2188609ce869f17b926de64b22efa26e959c82c



Bug#928534: O: pisg -- Perl IRC Statistics Generator

2019-05-06 Thread Tobias Frost
Package: wnpp

The current maintainer of pisg, Julien Danjou ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: pisg
Binary: pisg
Version: 0.73-1
Maintainer: Julien Danjou 
Build-Depends: debhelper (>> 5.0.0), docbook-utils
Build-Depends-Indep: perl (>= 5.6)
Architecture: all
Standards-Version: 3.9.4
Format: 1.0
Files:
 e38939fa9d809ef201780fdc82b8d27b 1639 pisg_0.73-1.dsc
 e0d43082c0bc20e19978743ebf2fcf8b 236539 pisg_0.73.orig.tar.gz
 73ccc8638a5d2255df957d87de0c900a 2747 pisg_0.73-1.diff.gz
Checksums-Sha256:
 57eff87a38ded985c0ce6435b658025b9c2e7eaf1ec7da1dc6a4ed03e78d4bed 1639 
pisg_0.73-1.dsc
 979efdd489114c10360dff9c7c8fdc287c126508e65790dfd0d0aa6fdf7d7c3b 236539 
pisg_0.73.orig.tar.gz
 4133626726a3f551b86b08a94d2329fa998679205c122c8738db1f5b23399509 2747 
pisg_0.73-1.diff.gz
Package-List: 
 pisg deb net optional
Directory: pool/main/p/pisg
Priority: source
Section: net

Package: pisg
Version: 0.73-1
Installed-Size: 817
Maintainer: Julien Danjou 
Architecture: all
Depends: perl
Suggests: libtext-iconv-perl
Description-en: Perl IRC Statistics Generator
 A Perl script which takes IRC logfiles and turns them into nice looking
 stats, which can be amusing to show to the users of your channel.
Description-md5: 61c4737ab0ed6315627f149d29c627a9
Tag: implemented-in::perl, interface::commandline, protocol::dcc,
 protocol::irc, role::program, scope::utility, use::chatting,
 use::converting, use::monitor, works-with::logfile
Section: net
Priority: optional
Filename: pool/main/p/pisg/pisg_0.73-1_all.deb
Size: 224338
MD5sum: 5b321b673259c5d3fe96e96d6c222b43
SHA256: 1db29346bd41ce82252a1adb7104096afcd426058daba281ed78dc219a2f0c9d



Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)

2019-05-06 Thread Ross Vandegrift
On Mon, May 06, 2019 at 10:20:25AM +0200, Thomas Goirand wrote:
> On 5/6/19 5:09 AM, Ross Vandegrift wrote:
> > Source: sqlalchemy
> > Version: 1.2.18+ds1
> > Followup-For: Bug #922669
> > 
> > I've confirmed that 1.2.18+ds1 is affected despite the description at [1].
> > Upstream has a patch for the 1.2 series at [2].
> > 
> > A debdiff including the patch is attached.  It builds and the tests pass.
> > However, the fix requires removing previously supported behavior.  Consumers
> > that depend on this have been found [3], so I'm not sure if this should be
> > shipped in buster.
> 
> Hi,
> 
> I'm sorry, but where exactly do you see a list of affected consumers?

I didn't find a list, I just wanted to note that upstream observed at
least one example (the bug report I linked as #3) of a user that was
broken by the required API change.

I don't know how concerned Debian should be about possible breakage.  I
don't use sqlalchemy much anymore, and never used the affected APIs.

Ross



Bug#928527: unblock: peek/1.3.1-6

2019-05-06 Thread Boyuan Yang
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock peek 1.3.1-6. This upload fixes https://bugs.debian.org/926386 ,
which caused the application to crash when recording GIF using the
ffmpeg backend.

The full debdiff is pasted here.

--
Thanks,
Boyuan Yang

diff -Nru peek-1.3.1/debian/changelog peek-1.3.1/debian/changelog
--- peek-1.3.1/debian/changelog2019-02-08 13:14:08.0 -0500
+++ peek-1.3.1/debian/changelog2019-05-06 13:27:48.0 -0400
@@ -1,3 +1,10 @@
+peek (1.3.1-6) unstable; urgency=high
+
+  * debian/patches: Add patch 0003 to fix double free crashing when
+passing string array to async function. (Closes: #926386)
+
+ -- Boyuan Yang   Mon, 06 May 2019 13:27:48 -0400
+
 peek (1.3.1-5) unstable; urgency=medium

   * Rebuild for Debian buster.
diff -Nru 
peek-1.3.1/debian/patches/0003-avoid-double-free-when-passing-string-array-to-async-function.patch
peek-1.3.1/debian/patches/0003-avoid-double-free-when-passing-string-array-to-async-function.patch
--- 
peek-1.3.1/debian/patches/0003-avoid-double-free-when-passing-string-array-to-async-function.patch
   1969-12-31 19:00:00.0 -0500
+++ 
peek-1.3.1/debian/patches/0003-avoid-double-free-when-passing-string-array-to-async-function.patch
   2019-05-06 13:27:48.0 -0400
@@ -0,0 +1,43 @@
+From: Bernhard Übelacker 
+Date: Mon, 6 May 2019 13:29:50 -0400
+Subject: Avoid double free when passing string array to async function
+
+Bug-Debian: https://bugs.debian.org/926386
+Last-Update: 2019-04-20
+Forwarded: https://github.com/phw/peek/issues/419
+---
+ src/post-processing/ffmpeg-post-processor.vala | 20 
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/src/post-processing/ffmpeg-post-processor.vala
b/src/post-processing/ffmpeg-post-processor.vala
+index c9727c0..1a3d59c 100644
+--- a/src/post-processing/ffmpeg-post-processor.vala
 b/src/post-processing/ffmpeg-post-processor.vala
+@@ -79,15 +79,19 @@ namespace Peek.PostProcessing {
+ var extension = Utils.get_file_extension_for_format
(config.output_format);
+ var output_file = Utils.create_temp_file (extension);
+
+-string[] args = {
+-  "ffmpeg", "-y",
+-  "-i", input_file.get_path (),
+-  "-i", palette_file.get_path (),
+-  "-filter_complex", "fps=%d,paletteuse".printf (config.framerate)
+-};
+-
+ var argv = new Array ();
+-argv.append_vals (args, args.length);
++
++argv.append_val ("ffmpeg");
++argv.append_val ("-y");
++
++argv.append_val ("-i");
++argv.append_val (input_file.get_path ());
++
++argv.append_val ("-i");
++argv.append_val (palette_file.get_path ());
++
++argv.append_val ("-filter_complex");
++argv.append_val ("fps=%d,paletteuse".printf (config.framerate));
+
+ if (config.output_format == OutputFormat.APNG) {
+   argv.append_val ("-plays");
diff -Nru peek-1.3.1/debian/patches/series peek-1.3.1/debian/patches/series
--- peek-1.3.1/debian/patches/series2019-02-08 13:13:19.0 -0500
+++ peek-1.3.1/debian/patches/series2019-05-06 13:27:48.0 -0400
@@ -1,2 +1,3 @@
 0001-src-Backport-upstream-trunk-code-till-20190121.patch
 0002-appdata-Fix-validation-warning-The-summary-tag-must-.patch
+0003-avoid-double-free-when-passing-string-array-to-async-function.patch



Bug#928526: linux-image-4.19.0-4-amd64: data corruption when swapping to encrypted SSD with LVM and TRIM enabled

2019-05-06 Thread Simon Richter
Package: src:linux
Version: 4.19.28-2
Severity: grave
Tags: upstream
Justification: causes non-serious data loss

Hi,

I have an older laptop with an SSD and an encrypted LVM setup with TRIM
passthrough through the crypto layers. Normally I run without swap space,
but occasionally I will set up a swap file if I anticipate a need for it.

I create the swap file on an encrypted partition using

dd if=/dev/zero of=/home/swap bs=1G count=8
mkswap /home/swap
swapon /home/swap

The file system in question is ext4 in a LVM logical volume in a PV that is
a LUKS volume inside a DOS partition on an SSD. The "discard" option is set
in /etc/crypttab.

Since upgrading from stretch to buster, processes using a lot of memory die
with signal 11 (often) or 6 (seldom), typically after being swapped in. I
can reproduce this rather consistently by compiling KiCad, which at one
point invokes four ld processes in parallel that each take roughly 3 GB of
RAM, causing some swapping: most of the time, one or two of the ld
processes terminates with a segmentation fault. Switching to Firefox during
that time almost certainly kills Firefox or the X server, so this seems
related to swapping.

I have also experienced some file system corruption on the /home partition
(that needed manual repair with fsck), it is not entirely clear to me if
that is coincidental or related. That partition has run without fsck for
some time before, but the affected files were all created shortly before
the system went into memory pressure. Other partitions were fine, but that
might also be because they are not usually written to during operation.

Memtest86+ reports no problems.

The same setup works fine with 4.9.0-8-amd64 from stretch, so this is a
regression.

I can probably test intermediate versions and/or changes in setup, but this
is difficult to automate because "bad" runs require manual file system
repairs and every run requires LUKS setup to be repeated.

   Simon

-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
initrd=\7fa8c2303086c2fad03bc1be50eaac8c\4.19.0-4-amd64\initrd 
root=/dev/mapper/coffee-root ro quiet

** Not tainted

** Kernel log:
[   20.645047] systemd-udevd[726]: Using default interface naming scheme 'v240'.
[   20.645574] videodev: Linux video capture interface: v2.00
[   20.646574] systemd-udevd[726]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
[   20.647277] usbcore: registered new interface driver qcserial
[   20.647289] usbserial: USB Serial support registered for Qualcomm USB modem
[   20.647997] qcserial 1-1.5:1.0: Qualcomm USB modem converter detected
[   20.648074] usb 1-1.5: Qualcomm USB modem converter now attached to ttyUSB0
[   20.648279] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   20.648800] usbcore: registered new interface driver cdc_wdm
[   20.651751] qcserial 1-1.5:1.2: Qualcomm USB modem converter detected
[   20.652053] usb 1-1.5: Qualcomm USB modem converter now attached to ttyUSB1
[   20.653496] qcserial 1-1.5:1.3: Qualcomm USB modem converter detected
[   20.653565] usb 1-1.5: Qualcomm USB modem converter now attached to ttyUSB2
[   20.654411] qmi_wwan 1-1.5:1.8: cdc-wdm0: USB WDM device
[   20.654574] qmi_wwan 1-1.5:1.8 wwan0: register 'qmi_wwan' at 
usb-:00:1a.0-1.5, WWAN/QMI device, 0a:b7:4f:bc:8b:4c
[   20.654622] usbcore: registered new interface driver qmi_wwan
[   20.655678] systemd-udevd[604]: Using default interface naming scheme 'v240'.
[   20.657076] systemd-udevd[604]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
[   20.657187] qmi_wwan 1-1.5:1.8 wwp0s26u1u5i8: renamed from wwan0
[   20.667147] uvcvideo: Found UVC 1.00 device FJ Camera  (04f2:b2fc)
[   20.686810] Bluetooth: Core ver 2.22
[   20.686822] NET: Registered protocol family 31
[   20.686823] Bluetooth: HCI device and connection manager initialized
[   20.686826] Bluetooth: HCI socket layer initialized
[   20.686827] Bluetooth: L2CAP socket layer initialized
[   20.686833] Bluetooth: SCO socket layer initialized
[   20.694365] usbcore: registered new interface driver btusb
[   20.712225] uvcvideo 1-1.6:1.0: Entity type for entity Extension 4 was not 
initialized!
[   20.712228] uvcvideo 1-1.6:1.0: Entity type for entity Extension 3 was not 
initialized!
[   20.712230] uvcvideo 1-1.6:1.0: Entity type for entity Processing 2 was not 
initialized!
[   20.712232] uvcvideo 1-1.6:1.0: Entity type for entity Camera 1 was not 
initialized!
[   20.712306] input: FJ Camera : FJ Camera  as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input19
[   20.712362] usbcore: registered new interface driver uvcvideo
[   20.712363] USB Video Class driver (1.1.1)
[   20.717468] systemd-udevd[643]: Using default interface naming scheme 'v240'.
[   20.743958] [drm] Initialized i915 

Bug#926594: (no subject)

2019-05-06 Thread Gordon Ball
Since this has been open for a month I have gone ahead and uploaded
5.7.8-1 to unstable, rather than leave the CVEs unfixed there.
Accordingly, please consider this now to be an unblock request.



Bug#928525: sshguard: Default configuration does not work as intended, needs configuration update

2019-05-06 Thread Andreas Stempfhuber

Package: sshguard
Version: 2.3.1-1
Severity: important

Dear Maintainer,

the default configuration shipped with the Debian package causes 
sshguard to count it's own attach messages as another attack and hence 
all hosts are blocked on their first login failure, e.g.:


Apr 24 01:42:52 vsn sshd[11354]: Failed password for root from 
112.85.42.189 port 35899 ssh2
Apr 24 01:42:53 vsn sshguard[11232]: Attack from "112.85.42.189" on 
service 100 with danger 10.
Apr 24 01:42:53 vsn sshguard[11232]: Attack from "112.85.42.189" on 
service 110 with danger 10.
Apr 24 01:42:54 vsn sshguard[11232]: Attack from "112.85.42.189" on 
service 110 with danger 10.
Apr 24 01:42:54 vsn sshguard[11232]: Blocking "112.85.42.189/32" for 120 
secs (3 attacks in 1 secs, after 1 abuses over 1 secs.)


Upstream ships an example configuration where this is not the case as it 
uses a different journalctl syntax. It works as it does not feed the 
sshguard log messages back to sshguard.


Two minor notes in addition:
- also options like IPV6_SUBNET, IPV4_SUBNET and BLACKLIST_FILE are 
missing in the Debian configuration file
- journalctl should IMHO use -n0 instead of -n1 because sshg-logtail 
does the same for tail


Please also consider an update for Buster to ship the package with a 
working default configuration.


Thanks

Andreas

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

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

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

Versions of packages sshguard depends on:
ii  libc6 2.28-10
ii  lsb-base  10.2019031300

Versions of packages sshguard recommends:
ii  nftables  0.9.0-2

sshguard suggests no packages.

-- Configuration Files:
/etc/sshguard/sshguard.conf changed [not included]
/etc/sshguard/whitelist changed [not included]

-- no debconf information



Bug#928524: lxqt-panel starts with a delay of approx. 30s when the statusnotifier plugin is enabled

2019-05-06 Thread Alf Gaida
Package: lxqt-panel
Version: 0.14.1-1
Severity: important

Dear Maintainer,

lxqt-panel will be displayed at systemstart with a 30s delay - in this time 
lxqt-runner is also not usable.
Reason is the statusnotifier plugin. Solution: adding a recommend to sni-qt, so 
old-fashioned applications
can use the indicator system with their systray.

Cheers Alf


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

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

Versions of packages lxqt-panel depends on:
ii  libasound2  1.1.8-1
ii  libc6   2.28-10
ii  libdbusmenu-qt5-2   0.9.3+16.04.20160218-1
ii  libkf5solid55.54.0-1
ii  libkf5windowsystem5 5.54.0-1
ii  liblxqt-globalkeys-ui0  0.14.1-1
ii  liblxqt-globalkeys0 0.14.1-1
ii  liblxqt00.14.1-1
ii  libpulse0   12.2-4
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libqt5x11extras55.11.3-2
ii  libqt5xdg3  3.3.1-1
ii  libqt5xml5  5.11.3+dfsg1-1
ii  libsensors5 1:3.5.0-3
ii  libstatgrab10   0.91-1+b2
ii  libstdc++6  8.3.0-6
ii  libsysstat-qt5-00.4.2-1
ii  libx11-62:1.6.7-1
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxkbcommon-x11-0  0.8.2-1
ii  libxkbcommon0   0.8.2-1
ii  libxrender1 1:0.9.10-1
ii  lxmenu-data 0.1.5-2
ii  lxqt-policykit  0.14.1-1

Versions of packages lxqt-panel recommends:
ii  lxqt-about  0.14.1-1
ii  lxqt-config 0.14.1-2
ii  lxqt-notificationd  0.14.1-1
ii  lxqt-panel-l10n 0.14.1-1
ii  lxqt-qtplugin   0.14.0-3
ii  lxqt-runner 0.14.1-1
ii  lxqt-session0.14.1-1
ii  pavucontrol-qt  0.14.1-1
ii  qlipper 1:5.1.2-1

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

-- no debconf information



Bug#928523: nvidia-driver: frequent black screen and screen shudder

2019-05-06 Thread Mathias Warnier
Package: nvidia-driver
Version: 390.116-1
Severity: important

Dear Maintainer,


After upgrade to latest stable driver version (390.116) I experience frequent
black screens and screen shudders. I've already re-installed the complete
driver package but to no avail.

No issues when using previous driver.

Kind regards,
Mathias



-- Package-specific info:
uname -a:
Linux debian 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 GNU/Linux

/proc/version:
Linux version 4.9.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1 (2019-04-12)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.116  Sun Jan 27 07:21:36 
PST 2019
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 

lspci 'display controller [030?]':
0a:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 
1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ZOTAC International (MCO) Ltd. GP107 [GeForce GTX 1050 Ti] 
[19da:a454]
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  6 20:17 /dev/dri/card0
crw-rw+ 1 root video 226, 128 May  6 20:17 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 May  6 20:17 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 May  6 20:17 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 May  6 20:17 /dev/nvidiactl
video:x:44:mathias,plex

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1299 May  6 20:03 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 May  6 19:54 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 May  6 19:54 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   50 May  6 19:54 
/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  6 19:54 
/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   57 May  6 19:54 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 May  6 19:54 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   54 May  6 19:54 
/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  6 19:54 
/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   44 May  6 19:54 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   44 May  6 19:54 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   51 May  6 19:54 
/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  6 19:54 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 May  6 19:54 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 May  6 19:54 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 May  6 19:54 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 May  6 19:54 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 May  6 19:54 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 May  6 19:54 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 May  6 19:53 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   52 May  6 19:53 
/etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
lrwxrwxrwx 1 root root   59 May  6 19:53 
/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   65 May  6 19:53 
/etc/alternatives/nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLESv1_CM_nvidia.so.1
lrwxrwxrwx 1 root 

Bug#928511: [Pkg-privacy-maintainers] Bug#928511: torbrowser-launcher hasn't updated itself to 60.6.2esr

2019-05-06 Thread shirish शिरीष
Hi all,

Seems https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 is tracking
parts of the bug.

I also saw https://blog.torproject.org/noscript-temporarily-disabled-tor-browser
but it doesn't indicate that a new release is supposed to be out soon.

Of the new comments the only thing I could figure out is that there is
an RC1 tarball of 8.0.9 but the report/comment itself wasn't that
encouraging.

https://blog.torproject.org/comment/281341#comment-281341

Would be looking out to when this is fixed.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C



Bug#928518: RM: electrum -- RoQA; Actively exploited for phishing

2019-05-06 Thread Andrey Rahmatullin
On Mon, May 06, 2019 at 12:00:22PM -0400, Sam Hartman wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hi.  As discussed in
> https://cointelegraph.com/news/phishing-attack-on-electrum-wallet-nets-hacker-almost-1-million-in-hours-report
> the version of electrum in sid is vulnerable to mallware and has been
> disabled by the electrum servers.  So basically the version in sid is
> only useful for getting your bitcoin phished.  At least until this
> version is updated it should be removed.  See #921688 for details.
> 
> I understand that removing electrum means that it will need to take a
> trip through new once fixed.
> I think in this instance given that we haven't fixed such a critical issue in 
> months, it is justified.
Note that it doesn't help with already installed packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#928235: Reason for omission of client-pending patch?

2019-05-06 Thread Bryce Harrington
For CVE-2019-11494, three patches were provided by the vendor:

  https://seclists.org/oss-sec/2019/q2/82

In Ubuntu we included the three patches, but in updating our merge with
Debian I notice you included only the latter two.  Is this because the
first one suppresses a warning, and is considered non-critical?

Thank you,
Bryce



Bug#812110: KeePassX 0.4 and KeePassX 2.0 should be in different packages

2019-05-06 Thread marjan cinober
Hi guys

I was irritated by this name collision for long time until I finally did
something about it. Here is my solution. Hope somebody with upload
privileges will publish it for everybody.

Run the attached script ant it will download latest release, patch it to a
new name keepassx1, build it and it will hopefully work for you as it is
working for me.

Warm regards  marjan

On Fri, 5 Feb 2016 04:31:44 +0300 Evgeny Kapun 
wrote:
> On 05.02.2016 00:13, Felix Geyer wrote:
> > On 20.01.2016 19:53, Evgeny Kapun wrote:
> >>> I think most tools support the .kdbx format by now so shipping just
one version seems like the
> >>> right choice to me.
> >>
> >> The problem is that if the same database is used on multiple machines,
they must be all upgraded
> >> at the same time. With your approach, it is not be possible to use the
same database on machines
> >> running, say, jessie and stretch. Unless the new version is backported
to old Debian versions (at
> >> least jessie), those versions would have no native tools which support
.kdbx format, and
> >> simultaneously upgrading multiple systems may not be possible.
> >
> > I'll upload 2.0.2 to jessie-backports once it reaches testing.
> >
> > Felix
>
> And still, if both versions have the same package name, it is not
possible to have them installed simultaneously.
>
>


buildKeepassxV1.sh
Description: application/shellscript


Bug#928522: pinyin-database: impossible to install the Pinyin add-on via the 'software application' debian stretch

2019-05-06 Thread yifan
Package: pinyin-database
Version: pinyin 1.7.3-2
Severity: normal

Dear Maintainer,

Trying to install this add-on I always end up with
E: could not find the repository

I don't know to install this to be able to write chinese character.

Thx for your help.



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

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



Bug#928518: RM: electrum -- RoQA; Actively exploited for phishing

2019-05-06 Thread Sam Hartman
> "Moritz" == Moritz Mühlenhoff  writes:

Moritz> On Mon, May 06, 2019 at 12:00:22PM -0400, Sam Hartman wrote:
>> 
>> Package: ftp.debian.org Severity: normal
>> 
>> Hi.  As discussed in
>> 
https://cointelegraph.com/news/phishing-attack-on-electrum-wallet-nets-hacker-almost-1-million-in-hours-report
>> the version of electrum in sid is vulnerable to mallware and has
>> been disabled by the electrum servers.  So basically the version
>> in sid is only useful for getting your bitcoin phished.  At least
>> until this version is updated it should be removed.  See #921688
>> for details.

Moritz> We have poor means for people to detect that a package has
Moritz> been removed from the archive (and needs local removal); an
Moritz> alternative might be to NMU in sid so that it sys.exit()s
Moritz> with a message stating that running Electrum is dangerous
Moritz> and has been enabled and only proceed with the removal in a
Moritz> few weeks?

At that point we could simply leave it until the new version comes
along.
If people want this solution I can make the NMU.

--Sam



Bug#928518: RM: electrum -- RoQA; Actively exploited for phishing

2019-05-06 Thread Moritz Mühlenhoff
On Mon, May 06, 2019 at 12:00:22PM -0400, Sam Hartman wrote:
> 
> Package: ftp.debian.org
> Severity: normal
> 
> Hi.  As discussed in
> https://cointelegraph.com/news/phishing-attack-on-electrum-wallet-nets-hacker-almost-1-million-in-hours-report
> the version of electrum in sid is vulnerable to mallware and has been
> disabled by the electrum servers.  So basically the version in sid is
> only useful for getting your bitcoin phished.  At least until this
> version is updated it should be removed.  See #921688 for details.

We have poor means for people to detect that a package has been removed
from the archive (and needs local removal); an alternative might be to
NMU in sid so that it sys.exit()s with a message stating that running
Electrum is dangerous and has been enabled and only proceed with the
removal in a few weeks?

Cheers,
Moritz



Bug#928521: rmlint-gui: File size limits lower than 1 Mb are treated as 0 Mb

2019-05-06 Thread Diego Caraffini
Package: rmlint-gui
Version: 2.8.0-3
Severity: normal
Tags: patch

Dear Maintainer,

In an attempt to only delete duplicates fo non-empty files, I set a lower size
limit on the duplicate file size of a few bytes, in the Settings view of the
gui, but shredder kept reporting them.

Clicking on the 'Generate script' button I saw in the script that the rmlint
command line that run by shredder contained the option:
"--size 0M-17179869184M"

This was observed to happen with lower limit up to 999 kb, and causes files
smaller than the set limit to be listed anyways and worse, if the upper limit
is also lower than 1 Mb, then only empty files are listed.

The observed result is that any file size limit lower than 1 Mb (both lower and
upper) is forced to 0 Mb before it is passed to the command line scanner with
incorrect value.

The expected result is that file size limits are passed correctly to the
command line scanner and no manual selection is needed to exclude unwanted
matches from deletion.

The issue can be tracked down to lines 177--181 of file
'/usr/lib/python3/dist-packages/shredder/runner.py'
%<--
extra_options += [
'--size', '{a}M-{b}M'.format(
a=min_size // (1024 ** 2),
b=max_size // (1024 ** 2)
)
%<--
 where all file size limits are converted to Mb, truncating to an integer.

The issue has already been reported and fixed upstream:
https://github.com/sahib/rmlint/commit/5a5cf895df405ae4eb3d4d9dd87d5c76de66dbbc

Please incorporate the fix at your leisure.

PS. I am not certain that adding the patch tag because I provide a link to the 
commit that fixes
the bug upstream is the correct thing to do, do in case it is not,
remove it.

Best regards,
Diego



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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT:it (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rmlint-gui depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtksource-3.0 3.24.9-2
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  python3  3.7.2-1
ii  python3-cairo1.16.2-1+b1
ii  python3-gi   3.30.4-1
ii  rmlint   2.8.0-3

Versions of packages rmlint-gui recommends:
ii  python3-colorlog  4.0.1-1

rmlint-gui suggests no packages.

-- no debconf information



Bug#925142: hp-plugin generates libsane udev rules lacking LABEL

2019-05-06 Thread Cristian Ionescu-Idbohrn
On Wed, 20 Mar 2019, Christian Kastner wrote:
> 
> Package: hplip
> Version: 3.18.12+dfsg0-2
> Severity: minor
> 
> The utility hp-plugin generated a file S99-2000S1.rules in
> /etc/udev/rules.d/, which I've attached. This sets up permissions for my
> HP LaserJet Pro MFP 176n.
> 
> Note that in line 26, there's a GOTO="libsane_rules_end", but there is
> no LABEL= for that.
> 
> Compare this to libsane's /lib/udev/rules.d/60-libsane.rules, which has
> a similar structure, but has such a matching LABEL.
> 
> Regards,
> Christian
> 
> PS: I guess that the simplest solution would be to get this LaserJet
> model into libsane's 60-libsane.rules (where 3 other LaserJets are
> already listed), but I don't have any experience with that -- can the
> maintainer do that trivially, or does this require code in the upstream
> project? If you happen to have experience with this process and it is
> trivial, please do share. Thanks!

Mee too.  In my case it's a HP-ColorLaserJet-MFP-M278-M281 (Driver: HP 
Color LaserJet Pro MFP M277 Postscript (recommended)).


Cheers,

-- 
Cristian



Bug#928353: Fwd: release-notes: document mutt vs neomutt in buster

2019-05-06 Thread Antonio Radici
Thanks for pinging me, I missed this, let me comment on the bug.

On Sun, May 05, 2019 at 02:51:35PM +0200, Paul Gevers wrote:
> Hi,
> 
> I'm not sure if this release-notes bug that I addressed to you actually
> reached you.
> 
> Paul
> 
> 
>  Forwarded Message 
> Subject: Bug#928353: release-notes: document mutt vs neomutt in buster
> Date: Thu, 2 May 2019 18:53:55 +0200
> From: Paul Gevers 
> To: Debian Bug Tracking System 
> 
> Package: release-notes
> X-Debbugs-CC: m...@packages.debian.org, j...@debian.org
> 
> Dear (neo|)mutt maintainers,
> 
> I recently learned about the mutt versus neomutt situation in buster via
> the blog [1] of jmtd (in X-D-CC). I believe mutt and neomutt warrant a
> note in the release notes, don't you agree?
> 
> As the maintainers of this software, you are in the best position to
> write this. Are you willing and able to provide a piece of text? MR
> against the release notes archive [2] are welcome, but otherwise just
> sent to this bug is fine.
> 
> Paul
> 
> [1] https://jmtd.net/log/mutt_year_zero/
> [2] https://salsa.debian.org/ddp-team/release-notes/
> 
> 
> 



Bug#928520: Provide systemd unit for unclutter

2019-05-06 Thread Jörg Sommer
Package: unclutter
Version: 8-21
Severity: wishlist

Hi,

maybe, could you ship this unit file as /usr/lib/systemd/user/unclutter.service?
This runs unclutter independent of the window manager and it aggregates
all log messages via journal.

```
[Unit]
Description=Daemon to remove idle cursor image from screen
Documentation=man:unclutter(1)
PartOf=graphical-session.target

[Service]
ExecStart=/usr/bin/unclutter -idle 4 -root

[Install]
WantedBy=graphical-session.target
```

Regards Jörg


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

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unclutter depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  libc6  2.28-10
ii  libx11-6   2:1.6.7-1

unclutter recommends no packages.

unclutter suggests no packages.

-- debconf information excluded


signature.asc
Description: PGP signature


Bug#928519: Provide systemd unit

2019-05-06 Thread Jörg Sommer
Package: ukui-polkit
Version: 1.0.2-1
Severity: wishlist

Hi,

maybe, could you ship this unit file as 
/usr/lib/systemd/user/ukui-polkit.service?
This runs ukui-polkit independent of the window manager and it aggregates
all log messages via journal.

```
[Unit]
Description=PolicyKit Authentication Agent
PartOf=graphical-session.target

[Service]
ExecStart=/usr/lib/x86_64-linux-gnu/ukui-polkit/polkit-ukui-authentication-agent-1
SyslogIdentifier=polkit-ukui

[Install]
WantedBy=graphical-session.target
```

Regards Jörg

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

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ukui-polkit depends on:
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libgl1 1.1.0-1
ii  libpolkit-qt5-1-1  0.112.0-6
ii  libqt5core5a   5.11.3+dfsg1-1
ii  libqt5dbus55.11.3+dfsg1-1
ii  libqt5gui5 5.11.3+dfsg1-1
ii  libqt5widgets5 5.11.3+dfsg1-1
ii  libstdc++6 8.3.0-7
ii  policykit-10.116-1

ukui-polkit recommends no packages.

Versions of packages ukui-polkit suggests:
pn  biometric-auth  

-- no debconf information


signature.asc
Description: PGP signature


Bug#927876:

2019-05-06 Thread Ricardo Pérez
This bug was reported by me one year ago on Launchpad:

https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1766068

Since Zsh 5.3, the command_not_found_handler() behavior has changed, as you
can see here:

https://github.com/zsh-users/zsh/blob/9e2afb92987d7fd96a838c15b6641cc1b634a825/README#L207-L214

Copy & paste:

  6) Previously, if the function command_not_found_handler was run
  in place of a command-not-found error, and the function returned
  non-zero status, zsh set the status to 127 and printed an error message
  anyway. Now, the status from the handler is retained and no additional
  message is printed. The main reasons for this change are that it was not
  possible to return a non-zero status to the parent shell from a command
  executed as a replacement, and the new implementation is more consistent
  with other shells.

So now, when you define a custom command_not_found_handler() function in
Zsh, the shell never print an error message by itself, i.e., the error
message must be printed by the handler function.

According to the above, I think the only solution is by remove the
'--no-failure-msg' option from the /etc/zsh_command_not_found and therefore
the command_not_found_handler() function is the only responsible to print
error messages to the user.


Bug#908589: ITP: gcc-8-doc -- documentation for the GNU compilers (gcc, g++, etc.)

2019-05-06 Thread Mattia Rizzolo
On Tue, Dec 25, 2018 at 12:03:23AM +0300, Dmitry Eremin-Solenikov wrote:
> Do you need any kind of help with gcc-8-doc package? An ITP is open
> since september without any logged progress on it.

And now we are May, and no news about it, we are about to release debian
buster, without any documentation for gcc, thanks to this...

Could you please be more active with the gcc documentation packages?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#928518: RM: electrum -- RoQA; Actively exploited for phishing

2019-05-06 Thread Sam Hartman

Package: ftp.debian.org
Severity: normal

Hi.  As discussed in
https://cointelegraph.com/news/phishing-attack-on-electrum-wallet-nets-hacker-almost-1-million-in-hours-report
the version of electrum in sid is vulnerable to mallware and has been
disabled by the electrum servers.  So basically the version in sid is
only useful for getting your bitcoin phished.  At least until this
version is updated it should be removed.  See #921688 for details.

I understand that removing electrum means that it will need to take a
trip through new once fixed.
I think in this instance given that we haven't fixed such a critical issue in 
months, it is justified.


signature.asc
Description: PGP signature


Bug#928517: current symlink missing for jessie

2019-05-06 Thread Floris Bos

Package: mirrors


http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/current/ 
no longer exists.


- It used to be there.

- "current" is still there for other Debian releases. (e.g. 
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/ )



We have some scripts that dedicated server providers use to provision 
servers in datacenters (PXE network installations), and those expect 
"current" to be there...




Yours sincerely,


Floris Bos



Bug#652727: ITA: simhash -- generate similarity hashes to find nearly duplicate files

2019-05-06 Thread laokz
Hi,

I'd like to adopt this package if Thomas Koch  isn't
interested in it yet.

But it may take a little time for me to dive into this work because I'm
a newbie of Debian Maintainerand.

Regards,
laokz



Bug#928473: dgit: not clear what to do when earlier uploads used dgit but intermediate ones didn't

2019-05-06 Thread Ian Jackson
Colin Watson writes ("Bug#928473: dgit: not clear what to do when earlier 
uploads used dgit but intermediate ones didn't"):
> On Sun, May 05, 2019 at 08:31:14PM +0100, Ian Jackson wrote:
> > --overwrite is intended for this situation.  The documentation talking
> > about "NMU changes" is speaking loosely, and should mention "changes
> > in uploads which weren't done with git" too.
> > 
> > It will make a pseudomerge of the synthetic import.  Is that a problem
> > for you ?
> 
> I'd been hoping to avoid the pseudomerge and have the histories be
> exactly identical, but I probably shouldn't be too precious about that,
> and you make a good point about allowing people with existing dgit
> clones to fast-forward.

Other than in split-brain quilt modes (which don't apply in this
case), the pseudomerge will appears on the branch you run `dgit push'
from.  So the histories will be identical because the pseudomerge will
be in your master.  Is that a problem ?  I thought I should mention
it...

> That makes sense now, and I agree.  FWIW, I found the documentation
> reasonably clear as far as it went, but the things I was missing were:
> 
>  * an explicit indication about --deliberately-not-fast-forward being
>non-fast-forwarding either from a synthetic local import or from the
>dgit server history;
> 
>  * an indication of which camp this particular situation falls into of
>the two options that are presented in various places and why, that
>is, the situation of a gap between two dgit pushes in which non-dgit
>uploads had happened.
...
> (A side note while I'm looking at this anyway: the use of "rewind" as a
> synonym for "non-fast-forwarding", while somewhat common in git
> terminology, is unfortunate.  The terms seem to be borrowed from video
> playback systems, where "rewind" is often just the exact opposite of
> "fast-forward", and so when I see "rewinding history" in a few places in
> dgit(1) my initial interpretation is that it must mean "updating a ref
> to point to an ancestor of the commit that it previously pointed to",
> whereas I think dgit(1) means "any push that isn't a fast-forward".  I
> don't know if I'm the only one for whom it has that connotation.)

Thanks.  That's three useful suggestions for improvement.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#927227: RFS: golang-gopkg-sourcemap.v1/1.0.5-2 [RC]

2019-05-06 Thread Shengjing Zhu
On Mon, May 6, 2019 at 4:42 PM Jongmin Kim  wrote:
>
> Dear Go team,
>
> I'm looking for a sponsor for the package "golang-gopkg-sourcemap.v1/1.0.5-2".
>
> This patch makes the package to use jQuery provided by Debian package
> (libjs-jquery) instead of getting from Internet, for fixing an RC bug: 
> #927227.
>
> The package is on:
>   https://salsa.debian.org/go-team/packages/golang-gopkg-sourcemap.v1
>
> The package was tested on both gbp and sbuild. It's also lintian-clean.
>
> Please consider to review and upload it. Any kind of suggestions are
> appreciated.
>
> Changes since the last upload:
>
>   golang-gopkg-sourcemap.v1 (1.0.5-2) unstable; urgency=medium
>
> * Team upload
> * d/gbp.conf:
>   - Set pristine-tar = False to override any global configs
>   - Set debian/sid as a debian branch
>   - Set upstream as an upstream branch
> * d/patches:
>   - Use local jQuery artifacts (Closes: #927227)
>   - Disable jQuery version-specific integrity tests
>
>-- Jongmin Kim   Mon, 06 May 2019 17:16:33 +0900
>

Uploaded.

If you want  to keep this package in buster, please open an unblock
request by running `reportbug release.debian.org`.

Thanks for your contributions.

-- 
Shengjing Zhu



Bug#928516: logrotate: Upgrading from stretch breaks logrotate if logrotate.conf was modified

2019-05-06 Thread Santiago Vila
Package: logrotate
Version: 3.14.0-4

Dear maintainer:

In a stretch system where the /etc/logrotate.conf has been modified
slightly, upgrading to buster and keeping the old configuration makes
entries for wtmp and btmp to be duplicated, as they are now in
separate files in logrotate.d. This makes the logrotate service to fail:

/etc/logrotate.conf:18 duplicate log entry for /var/log/wtmp
/etc/logrotate.conf:23 duplicate log entry for /var/log/btmp

I don't know how to fix this easily (maybe we should not even try to
fix it) but please consider writing something about it in a README or
in the release notes for buster or both.

Thanks.



Bug#928511: [Pkg-privacy-maintainers] Bug#928511: torbrowser-launcher hasn't updated itself to 60.6.2esr

2019-05-06 Thread shirish शिरीष
at bottom :-

On 06/05/2019, intrigeri  wrote:
>> I looked at #928415 and updated to firefox-esr 60.6.2esr-1 as can be
>> seen below -
>
> I assume you mean "Tor Browser", not torbrowser-launcher.
> Tor Browser 8.0.9 is not out yet. It should be released later today.
>

yup, meant the same. Thank you for the heads-up.


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C



Bug#908724: please add brcmfmac4356-pcie.txt to the package

2019-05-06 Thread Ben Hutchings
On Thu, 13 Sep 2018 08:21:01 +0200
"W. Martin Borgert"  wrote:
> Package: firmware-nonfree
> Version: 20180825+dfsg-1
> Severity: important
> 
> (Important, because it has a major effect on the usability for
> users of a specific hardware. Feel free to adjust.)
> 
> When installing Debian on the GPD Pocket, not only non-free
> firmware is needed for Wifi, but also the text file
> brcmfmac4356-pcie.txt needs to be installed in
> /lib/firmware/brcm/ which is fairly difficult:
> 
> https://wiki.debian.org/InstallingDebianOn/GPD/Pocket#Installation
> 
> Please add this file, so that mere mortals could install Debian
> on this device. Thanks!

Unfortunately this file is board-specific so we can't just ship a
single version.

Possibly we could provide multiple versions as alternatives, or make it
(a symlink to) a conffile.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure;
it can always serve as a bad example.




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


Bug#801655: xorg crashes with "NOUVEAU(0): failed to set mode: Permission denied" when exiting tty2-6 shell

2019-05-06 Thread Ed
On Tue, Oct 13, 2015 at 05:13:03am +0200, Alexandre Hoïde wrote:
> [  6636.047] (EE) NOUVEAU(0): failed to set mode: Permission denied
> [  6636.049] (EE) 
> Fatal server error:

I've also stumbled into this. Did anyone find a workaround?

-- 
Best regards,
Ed http://www.s5h.net/



signature.asc
Description: Digital signature


Bug#928509: Firefox insecure because of missing extensions

2019-05-06 Thread Karsten
Am 06.05.19 um 15:51 schrieb Antoine Beaupré:
> I am not sure I understand the problem you're trying to outline here.

The problem is to be spammed with advertisement 
 and to have no
No-Script.
It's true that i didn't know that the package xul-ext-noscript exists, but this 
is only a part of the solution.

> I would therefore argue that this effect is not necessarily a security
> hole in itself and affects only "third-party" code not shipped in
> Debian.

I will argue that Firefox is not usable any more without this senseful 
"third-party" stuff.

> I would otherwise be curious to hear more about which problem you
> specifically think 60.6.1 (the fixed version) actually still has that
> needs to be address and, ideally, how that should be addressed.

There are more and more problems like you can't use test automatization with 
this version.
Everything really useful in Firefox is going more and more to be not usable any 
more.

Is this the sense and target of the Mozilla Foundation?

> Thank you for the bug report!

Thank you for the quick answer!

My hope is that the LTS maintainers can fix the problem.
Thanks for the work on it.



Bug#928515: libjs-bootstrap-tour: Bootstrap sanitize breaks buttons in bootstrap-tour

2019-05-06 Thread Karsten Koop
Package: libjs-bootstrap-tour
Version: 0.11.0+dfsg-1
Severity: normal
Tags: patch

Dear Maintainer,

A recent security update to Bootstrap 3 (for CVE-2019-8331) brakes 
bootstrap-tour, because the sanitation removes the next/prev buttons
from the popover. A workaround is passing 'sanitize:false' option to popover(), 
see attached patch.

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

Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libjs-bootstrap-tour depends on:
ii  libjs-bootstrap  3.3.7+dfsg-2+deb9u2
ii  libjs-jquery 3.1.1-2+deb9u1

libjs-bootstrap-tour recommends no packages.

libjs-bootstrap-tour suggests no packages.

-- no debconf information
diff -uprN node-bootstrap-tour-0.11.0+dfsg/src/coffee/bootstrap-tour.coffee 
node-bootstrap-tour-0.11.0+dfsg-patched/src/coffee/bootstrap-tour.coffee
--- node-bootstrap-tour-0.11.0+dfsg/src/coffee/bootstrap-tour.coffee
2016-08-06 08:05:19.0 +0200
+++ node-bootstrap-tour-0.11.0+dfsg-patched/src/coffee/bootstrap-tour.coffee
2019-05-06 15:56:18.083204254 +0200
@@ -518,6 +518,7 @@
 title: step.title
 content: step.content
 html: true
+sanitize: false
 animation: step.animation
 container: step.container
 template: step.template


Bug#928514: python2.7 has a dependency cycle through xvfb

2019-05-06 Thread Helmut Grohne
Source: python2.7
Version: 2.7.16-2
Severity: important
Tags: patch

Bootstrapping python2.7 is difficult, because it has multiple dependency
cycles through xvfb. For instance:

src:libunwind Build-Depends texlive-extra-utils, which depends on a
package built from src:python2.7, which Build-Depends on xvfb, which
depends on a package built from src:libunwind.

python2.7 only uses xvfb for running its test suite and xvfb is not used
when building with DEB_BUILD_OPTIONS=nocheck. Consequently this cycle
can be broken by annotating the dependency with .

Helmut
diff -u python2.7-2.7.16/debian/changelog python2.7-2.7.16/debian/changelog
--- python2.7-2.7.16/debian/changelog
+++ python2.7-2.7.16/debian/changelog
@@ -1,3 +1,10 @@
+python2.7 (2.7.16-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends: xvfb with . (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 May 2019 13:01:20 +0200
+
 python2.7 (2.7.16-2) unstable; urgency=high
 
   [ Matthias Klose ]
diff -u python2.7-2.7.16/debian/control python2.7-2.7.16/debian/control
--- python2.7-2.7.16/debian/control
+++ python2.7-2.7.16/debian/control
@@ -15,7 +15,7 @@
   libgpm2 [linux-any],
   mime-support, netbase, net-tools, bzip2, time,
   libdb-dev (<< 1:6.0), libgdbm-dev, python:any, help2man,
-  xvfb, xauth
+  xvfb , xauth
 Build-Depends-Indep: python3-sphinx
 Build-Conflicts: tcl8.4-dev, tk8.4-dev,
   python2.7-xml, python-xml,


Bug#928512: cyrus-sasl2 FTCBFS: multiple reasons

2019-05-06 Thread Helmut Grohne
Source: cyrus-sasl2
Version: 2.1.27+dfsg-1
Severity: important
Tags: patch

cyrus-sasl2 fails to cross build from source for multiple reasons. The
immediate reason is that its Build-Depends are unsatisfiable. In
particular, python3-sphinx and libpod-pom-view-restructured-perl are
problematic due to the multiarch interpreter problem. Since a while,
we're entitled to annotate such dependencies with :native.

After doing so, the full build (with no profiles set) fails detecting
whether GSSAPI supports SPNEGO. Others ran into this problem already:
 * 
http://lists.openembedded.org/pipermail/openembedded-devel/2013-June/091202.html
 * https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2016-October/002906.html

While the OE folks produced a patch, they didn't make it upstreamable. I
think we can do better. The attached proposes using AC_CACHE_CHECK
(which is good practise for any AC_TRY_RUN) and should be upstreamable.
The debian/rules is updated to pass the cache variable for cross
building and validate it during native builds.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru cyrus-sasl2-2.1.27+dfsg/debian/changelog 
cyrus-sasl2-2.1.27+dfsg/debian/changelog
--- cyrus-sasl2-2.1.27+dfsg/debian/changelog2019-01-22 09:53:59.0 
+0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/changelog2019-05-06 15:14:31.0 
+0200
@@ -1,3 +1,13 @@
+cyrus-sasl2 (2.1.27+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate documentation Build-Depends with :native.
++ cross.patch: Support caching SPNEGO support test.
++ Provide and validate SPNEGO support test result.
+
+ -- Helmut Grohne   Mon, 06 May 2019 15:14:31 +0200
+
 cyrus-sasl2 (2.1.27+dfsg-1) unstable; urgency=medium
 
   [ Ryan Tandy ]
diff --minimal -Nru cyrus-sasl2-2.1.27+dfsg/debian/control 
cyrus-sasl2-2.1.27+dfsg/debian/control
--- cyrus-sasl2-2.1.27+dfsg/debian/control  2019-01-22 09:53:59.0 
+0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/control  2019-05-06 15:14:30.0 
+0200
@@ -18,12 +18,12 @@
libkrb5-dev ,
libldap2-dev ,
libpam0g-dev,
-   libpod-pom-view-restructured-perl,
+   libpod-pom-view-restructured-perl:native,
libpq-dev ,
libsqlite3-dev,
libssl-dev,
po-debconf,
-   python3-sphinx,
+   python3-sphinx:native,
quilt
 Build-Conflicts: heimdal-dev
 Vcs-Browser: https://salsa.debian.org/debian/cyrus-sasl2
diff --minimal -Nru cyrus-sasl2-2.1.27+dfsg/debian/patches/cross.patch 
cyrus-sasl2-2.1.27+dfsg/debian/patches/cross.patch
--- cyrus-sasl2-2.1.27+dfsg/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/patches/cross.patch  2019-05-06 
15:14:31.0 +0200
@@ -0,0 +1,35 @@
+--- cyrus-sasl2-2.1.27+dfsg.orig/m4/sasl2.m4
 cyrus-sasl2-2.1.27+dfsg/m4/sasl2.m4
+@@ -314,10 +314,10 @@
+   fi
+   LIBS="$cmu_save_LIBS"
+ 
+-  cmu_save_LIBS="$LIBS"
+-  LIBS="$LIBS $GSSAPIBASE_LIBS"
+-  AC_MSG_CHECKING([for SPNEGO support in GSSAPI libraries])
+-  AC_TRY_RUN([
++  AC_CACHE_CHECK([for SPNEGO support in GSSAPI 
libraries],[ac_cv_gssapi_supports_spnego],[
++cmu_save_LIBS="$LIBS"
++LIBS="$LIBS $GSSAPIBASE_LIBS"
++AC_TRY_RUN([
+ #ifdef HAVE_GSSAPI_H
+ #include 
+ #else
+@@ -338,11 +338,12 @@
+ 
+ return (!have_spnego);  // 0 = success, 1 = failure
+ }
+-],
+-  [ AC_DEFINE(HAVE_GSS_SPNEGO,,[Define if your GSSAPI implementation 
supports SPNEGO])
+-  AC_MSG_RESULT(yes) ],
+-  AC_MSG_RESULT(no))
+-  LIBS="$cmu_save_LIBS"
++],[ac_cv_gssapi_supports_spnego=yes],[ac_cv_gssapi_supports_spnego=no])
++LIBS="$cmu_save_LIBS"
++  ])
++  AS_IF([test "$ac_cv_gssapi_supports_spnego" = yes],[
++AC_DEFINE(HAVE_GSS_SPNEGO,,[Define if your GSSAPI implementation supports 
SPNEGO])
++  ])
+ 
+ else
+   AC_MSG_RESULT([disabled])
diff --minimal -Nru cyrus-sasl2-2.1.27+dfsg/debian/patches/series 
cyrus-sasl2-2.1.27+dfsg/debian/patches/series
--- cyrus-sasl2-2.1.27+dfsg/debian/patches/series   2019-01-22 
09:53:59.0 +0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/patches/series   2019-05-06 
15:14:31.0 +0200
@@ -18,3 +18,4 @@
 0033-cross.patch
 0019-Stop-importing-docutils_version-in-sphinx-build-manp.patch
 0020-Restore-LIBS-after-checking-gss_inquire_sec_context_.patch
+cross.patch
diff --minimal -Nru cyrus-sasl2-2.1.27+dfsg/debian/rules 
cyrus-sasl2-2.1.27+dfsg/debian/rules
--- cyrus-sasl2-2.1.27+dfsg/debian/rules2019-01-22 09:53:59.0 
+0100
+++ cyrus-sasl2-2.1.27+dfsg/debian/rules2019-05-06 15:14:31.0 
+0200
@@ -26,6 +26,11 @@
 -include /usr/share/dpkg/buildtools.mk
 export CC
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+# Debian's GSSAPI is known to support SPNEGO.
+export ac_cv_gssapi_supports_spnego=yes
+endif
+
 # see FEATURE AREAS in dpkg-buildflags(1)
 

Bug#928513: python3.7 has a dependency cycle through xvfb

2019-05-06 Thread Helmut Grohne
Source: python3.7
Version: 3.7.3-2
Severity: important
Tags: patch

Bootstrapping python3.7 is difficult, because it has multiple dependency
cycles through xvfb. For instance:

meson depends on a package built from src:python3.7, which Build-Depends
on xvfb, which depends on a package built from src:libdrm, which
Build-Depends on meson.

python3.7 only uses xvfb for running its test suite and xvfb is not used
when building with DEB_BUILD_OPTIONS=nocheck. Consequently this cycle
can be broken by annotating the dependency with .

Helmut
diff --minimal -Nru python3.7-3.7.3/debian/changelog 
python3.7-3.7.3/debian/changelog
--- python3.7-3.7.3/debian/changelog2019-04-03 07:39:12.0 +0200
+++ python3.7-3.7.3/debian/changelog2019-05-05 13:02:52.0 +0200
@@ -1,3 +1,10 @@
+python3.7 (3.7.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends: xvfb with . (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 May 2019 13:02:52 +0200
+
 python3.7 (3.7.3-2) unstable; urgency=medium
 
   * d/p/arm-alignment.diff: Don't allow unaligned memory accesses in the
diff --minimal -Nru python3.7-3.7.3/debian/control 
python3.7-3.7.3/debian/control
--- python3.7-3.7.3/debian/control  2019-04-03 07:39:12.0 +0200
+++ python3.7-3.7.3/debian/control  2019-05-05 13:02:50.0 +0200
@@ -15,7 +15,7 @@
   libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
   libgpm2 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],
   mime-support, netbase, bzip2, time, python3:any,
-  net-tools, xvfb, xauth
+  net-tools, xvfb , xauth
 Build-Depends-Indep: python3-sphinx, texinfo
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/cpython-team/python3/tree/python3.7


Bug#682369: confirmed

2019-05-06 Thread Matija Nalis
Control: found -1 60.6.1esr-1~deb9u1

Just to clarify, this bug happens even on normal browser close, when
session restore is *NOT USED* - that is, even when web pages are fully 
closed  before quitting the browser.

And it happens even with setting "When Firefox starts" to "Show a blank page"
(which should disable session restore functionality completely).

So the option "Keep (cookies) until: I close Firefox" *never* does anything.
It is quite deceptive :(

As workarounds, only options not to retain cookies when closing
firefox-esr browser I've found are:

- installing add-on like "Cookie Autodelete" to remove cookies automatically on 
*tab* close
- enabling "Always use private browsing mode" in "Preferences" / "Privacy & 
Security"
  (which also disabled sometimes useful session restore)
- manually deleting cookies before closing browser.

-- 
Opinions above are GNU-copylefted.



Bug#928415: could somebody look into #928511

2019-05-06 Thread shirish शिरीष
Dear all,

Could somebody look at #928511 . This is though in respect of
torbrowser though .

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C



Bug#928511: torbrowser-launcher hasn't updated itself to 60.6.2esr

2019-05-06 Thread shirish शिरीष
Package: torbrowser-launcher
Version: 0.3.1-2
Severity: grave

Dear Maintainer,
I looked at #928415 and updated to firefox-esr 60.6.2esr-1 as can be
seen below -

$ apt-cache policy firefox-esr
firefox-esr:
  Installed: 60.6.2esr-1
  Candidate: 60.6.2esr-1
  Version table:
 *** 60.6.2esr-1 500
500 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 60.6.1esr-1 990
990 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages

I was under the impression that just updating to the newest firefox
would solve the issue but it doesn't seem as simple as that.

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.2-1
ii  python3-gpg   1.12.0-6
ii  python3-pyqt5 5.11.3+dfsg-1+b3
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.8-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C



Bug#928509: Firefox insecure because of missing extensions

2019-05-06 Thread Antoine Beaupré
Control: severity 928509 normal

On 2019-05-06 15:04:09, Karsten wrote:
> Package: firefox-esr
> Version: 60.6.1esr-1~deb8u1
> Justification: user security hole
> Severity: grave
> Tags: security
>
> Hello Debian-Team,
>
> this security bug shall show that Firefox is going to be more and more 
> unusable to be secure in the internet.
>
> Today one of the most vulnerable things has happen, because all the 
> addons/extensions has gone,
> and there is no No-Script and Ublock or other Tracking-Protection any more.
> It is not possible to reinstall them!
>
> There are several articles about this out there like
> * 
> https://www.tenforums.com/browsers-email/131965-firefox-has-deleted-all-extensions-wont-reload-them.html
> * 
> https://discourse.mozilla.org/t/fixed-certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047/12
>
> When there is no fix for the used Firefox-Version, then a new browser 
> solution is needed for Debian.

I am not sure I understand the problem you're trying to outline here.

The package you filed this bug against (Firefox) does not ship with
uMatrix or uBlock or Noscript. It's true that those extensions, when
installed from the Mozilla add-ons site, got disabled due to the bug
described in #928415, but not the actual extensions (including uBlock)
shipped from Debian packages.

I would therefore argue that this effect is not necessarily a security
hole in itself and affects only "third-party" code not shipped in
Debian.

I'm therefore lowering the severity of this bug report, as it actually
keeps the *fixed* version of Firefox from migrating into Buster, making
this problem actually worse than it should be.

I would otherwise be curious to hear more about which problem you
specifically think 60.6.1 (the fixed version) actually still has that
needs to be address and, ideally, how that should be addressed.

Thank you for the bug report!

a.
-- 
La démocratie réelle se définit d'abord et avant tout par la
participation massive des citoyens à la gestion des affaires de la cité.
Elle est directe et participative. Elle trouve son expression la plus
authentique dans l'assemblée populaire et le dialogue permanent sur
l'organisation de la vie en commun.  - De la servitude moderne



Bug#928509: Firefox insecure because of missing extensions

2019-05-06 Thread Hideki Yamane
Hi,

On Mon, 6 May 2019 15:04:09 +0200 Karsten  wrote:
> Package: firefox-esr
> Version: 60.6.1esr-1~deb8u1

 It was already done in unstable and stable-proposed-updates, and
 reporter asks about oldstable, so CC:ed to lts mailing list.
 
 LTS maintainers, could you build it for oldstable, please?


> When there is no fix for the used Firefox-Version, then a new browser 
> solution is needed for Debian.

 No, you can migrate to Debian9 at least...


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp



Bug#926903: Installation-report addition

2019-05-06 Thread Ben Hutchings
Control: clone -1 -2
Control: retitle -1 installation-reports: Installer with firmware does not 
install firmware-amd-graphics
Control: reassign -2 firmware-amd-graphics
Control: retitle -2 firmware-amd-graphics: Should trigger initramfs rebuild

On Thu, 2019-05-02 at 11:10 +0100, Ben Hutchings wrote:
> On Thu, 2019-05-02 at 12:00 +1000, Tom Thekathyil wrote:
> > Hi Ben,
> > 
> > I ran 'update-initramfs -u' and got several lines saying
> > 
> > 'W: Possible missing firmware /lib/firmware/amdgpu/vega20_ xxx for
> > module a[off screen here]pu' where xxx refers to different items.
> > 
> > Regards, Tom Thekathyil
> 
> Yes, that's expected at the moment but those shouldn't be needed on
> your system.  I should have said, you need to reboot after this.

Since I have a suitable system, I have now reproduced this myself.
There are two bugs here:

1. The installer-with-firmware is not installing firmware-amd-graphics
   automatically on systems with AMD GPUs that need it.

2. The Desktop task now includes plymouth, which adds graphics drivers
   to the initramfs.  The firmware they request should be included as
   well, and will be if it is already installed.  But installing
   firmware-amd-graphics does not trigger an initramfs rebuild.

I'm cloning this and will fix the second bug, but I don't know how to
fix the first.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure;
it can always serve as a bad example.




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


Bug#927429: fixed in ghostscript 9.27~dfsg-2

2019-05-06 Thread Hideki Yamane
Hi Jonas,

On Sat, 20 Apr 2019 09:18:37 + Jonas Smedegaard  wrote:
> Source: ghostscript
> Source-Version: 9.27~dfsg-2

 Do you intend to put it into buster? (probably yes :)
 If so, please file unblock request for it.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp



Bug#926657: [Pkg-openldap-devel] Bug#926657: openldap: slapd process failure is not detected by systemd

2019-05-06 Thread Heitor Alves de Siqueira
Hi Ryan,

I'm attaching a patch for this which includes the override file.
Do you think this patch can be adopted in Debian until we have the
native service file? Please let me know if you think it needs any
changes!

Thanks,
Heitor
From 84316f458fb14592085f7e67d6aab349aaa312ff Mon Sep 17 00:00:00 2001
From: Heitor Alves de Siqueira 
Date: Mon, 6 May 2019 10:17:31 -0300
Subject: [PATCH] slapd: Fix systemd not detecting service failures

If the slapd daemon process exits due to some failure, the systemd
service is still reported as active even though the child (daemon)
process has exited with a signal. This is due to the sysv-generator unit
file for slapd telling the service to remain active after its process
exits.

This patch adds a systemd override file with 'RemainAfterExit=no', to
make the service behave in the expected way.

Closes: #926657

Signed-off-by: Heitor Alves de Siqueira 
---
 debian/slapd-remain-after-exit.conf | 3 +++
 debian/slapd.install| 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 debian/slapd-remain-after-exit.conf

diff --git a/debian/slapd-remain-after-exit.conf b/debian/slapd-remain-after-exit.conf
new file mode 100644
index ..b031203eaa9f
--- /dev/null
+++ b/debian/slapd-remain-after-exit.conf
@@ -0,0 +1,3 @@
+[Service]
+Type=forking
+RemainAfterExit=no
diff --git a/debian/slapd.install b/debian/slapd.install
index 2e7c9990a53d..ea197a99bf14 100644
--- a/debian/slapd.install
+++ b/debian/slapd.install
@@ -5,6 +5,7 @@ debian/ldiftopasswd usr/share/slapd
 debian/DB_CONFIG usr/share/slapd
 debian/slapd.conf usr/share/slapd
 debian/slapd.init.ldif usr/share/slapd
+debian/slapd-remain-after-exit.conf lib/systemd/system/slapd.service.d
 
 usr/lib/ldap/back_*.so*
 usr/lib/ldap/back_*.la
-- 
2.21.0



Bug#928509: Firefox insecure because of missing extensions

2019-05-06 Thread Karsten
Package: firefox-esr
Version: 60.6.1esr-1~deb8u1
Justification: user security hole
Severity: grave
Tags: security

Hello Debian-Team,

this security bug shall show that Firefox is going to be more and more unusable 
to be secure in the internet.

Today one of the most vulnerable things has happen, because all the 
addons/extensions has gone,
and there is no No-Script and Ublock or other Tracking-Protection any more.
It is not possible to reinstall them!

There are several articles about this out there like
* 
https://www.tenforums.com/browsers-email/131965-firefox-has-deleted-all-extensions-wont-reload-them.html
* 
https://discourse.mozilla.org/t/fixed-certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047/12

When there is no fix for the used Firefox-Version, then a new browser solution 
is needed for Debian.
>From my point of view it's really a pity with the Mozilla Foundation.

Cheers
karsten


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

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



  1   2   >