Bug#862838: rockdodger: Please explain Software failure, Guru meditation in the man page

[Pararaum]

Hi!

The requested fix

> If (a), then the errors should be more descriptive, if (b), please
mention this
> is a feature in the man page.

has been added to the development of rockdodger. A patch is attached to
this email.

Ciao,
Robert diff -r 6f4d2c79329b rockdodger.6
--- a/rockdodger.6	Fri Jul 31 21:34:40 2015 +0200
+++ b/rockdodger.6	Mon May 29 08:49:29 2017 +0200
@@ -1,5 +1,5 @@
 .\"  Hey, EMACS: -*- nroff -*-
-.TH ROCKDODGER 6 "Sep 4, 2014"
+.TH ROCKDODGER 6 "May 29, 2017"
 .\" Please adjust this date whenever revising the manpage.
 .\"
 .\" Some roff macros, for reference:
@@ -45,6 +45,15 @@
 .TP
 .B Esc
 Quit game.
+
+.SH GURU MEDITATION (Errors)
+Error messages (aka software failures) are usually reported by a so
+called "guru meditation". The guru meditation will be displayed in the
+top of the screen in a blinking border. If this happens please send in
+a bug report and provide the colour of the border (red, yellow, green,
+blue) and the two hex numbers after the hash ('#'). This will help
+greatly in locating the failure.
+
 .SH OPTIONS
 .TP
 .B \-h

Bug#862992: systemd: avoid attempt to re-create /etc/mtab by systemd-tmpfiles-setup.service

[Martin Pitt]

Hello Maximilian,

Maximilian Stein [2017-05-28 22:12 +0200]:
> I tried it again and apparently, /etc/mtab was actually created by FAI,
> not by debootstrap, sorry for the confusion. But maybe it would be an
> idea to create it by debootstrap to avoid its creation on the first boot?

Please let's not. /etc/mtab is a thing of the past, and nothing should use it
any more. util-linux had been the primary reason for still having it in jessie,
but in testing util-linux, systemd, udisks, etc. completely ignore that file
(aside from the backwards compat jobs to create it if not present).

After wheezy's release I would rather drop the /etc/mtab creation bit from
systemd, and FAI should do the same.

Martin


signature.asc
Description: PGP signature

Bug#863412: Acknowledgement (xca uses PRINTABLESTRING by default, ignoring RFC 2459)

[Harald Dunkel]

PS: Obviously RFC 5280 (the successor of RFC 2459) is not that
precise about using UTF8 or PRINTABLESTRING anymore.

Sorry for the noise
Harri

Bug#863595: gnome-control-center: Can't save configuration if 'Use this connection only for resource on its network' is checked

[Jason Crain]

Control: forwarded -1 https://bugzilla.gnome.org/708500

On Sun, May 28, 2017 at 11:05:44PM -0400, Fabian Inostroza wrote:
> Manually configuring a network interface and checking the option 'Use this 
> connection only for 
> resources on its network' doesn't allow to save it, the Apply button is 
> grayed out.

The Apply button is grayed out whenever an invalid configuration is
detected.  In this case, the invalid configuration is because you both
specified a gateway through manual configuration and checked the 'only
for resources on its network' aka 'never default' box.  Instead, you
should use '0.0.0.0' or '::' for the gateway field if you really want to
use the 'never default' box.

In version 3.24 the dialog is changed to allow the gateway to be left
blank, which should make this less confusing in the future.

Bug#863584: CVE-2017-2824

[Salvatore Bonaccorso]

Control: retitle zabbix: CVE-2017-2824 CVE-2017-2825

On Sun, May 28, 2017 at 10:42:47PM +0200, Moritz Muehlenhoff wrote:
> Source: zabbix
> Severity: grave
> Tags: security
> 
> Please see
> http://www.talosintelligence.com/reports/TALOS-2017-0325/
> http://www.talosintelligence.com/reports/TALOS-2017-0326/

The second one now leads to a 404, looks like TALOS report has a
whiespace suffixed in the URL,
https://www.talosintelligence.com/reports/TALOS-2017-0326%20/ should
work.

And looks the CVE was corrected as well (previously both referenced
CVE-2017-2824).

Regards,
Salvatore

Bug#863583: CVE-2017-7473

[Salvatore Bonaccorso]

On Sun, May 28, 2017 at 10:40:37PM +0200, Moritz Muehlenhoff wrote:
> Package: ansible
> Severity: important
> Tags: security
> 
> This was only reported in Red Hat bugzilla and further information
> is scarce: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7473

Additional info: This *might* be releated to
https://github.com/ansible/ansible/issues/22505 but I got no reply to
my question there.

Regards,
Salvatore

Bug#863600: python3-twisted: cannot cancel a DelayedCall (fixed in upstream)

[Goetz, Philippe]

Package: python3-twisted
Version: 16.6.0-2
Severity: important

Dear Maintainer,

Under stretch (and sid twisted=17.1.0), it is not possible to cancel a 
DelayedCall in python3:
p.cancel()
  File "/usr/lib/python3/dist-packages/twisted/internet/base.py", line 96, in 
cancel
self._str = bytes(self)
TypeError: 'DelayedCall' object is not iterable

This is fixed in upstream from https://github.com/twisted/twisted.git:

$ git show 5a5e5ca33b2a552ae2ca91e5dd38bd75e07306ff
commit 5a5e5ca33b2a552ae2ca91e5dd38bd75e07306ff
Author: Craig Rodrigues 
Date:   Sat Jan 14 19:55:09 2017 -0800

DelayedCall needs to call str(self), not bytes(self) to work on Python 3

diff --git a/src/twisted/internet/base.py b/src/twisted/internet/base.py
index 3e1c63cbf..fbb7619b8 100644
--- a/src/twisted/internet/base.py
+++ b/src/twisted/internet/base.py
@@ -101,7 +101,7 @@ class DelayedCall:
 self.canceller(self)
 self.cancelled = 1
 if self.debug:
-self._str = bytes(self)
+self._str = str(self)
 del self.func, self.args, self.kw

 def reset(self, secondsFromNow):
diff --git a/src/twisted/internet/test/test_base.py 
b/src/twisted/internet/test/test_base.py
index ba6964a40..7fee2004e 100644
--- a/src/twisted/internet/test/test_base.py
+++ b/src/twisted/internet/test/test_base.py
@@ -183,6 +183,7 @@ class DelayedCallTests(TestCase):
 Create two L{DelayedCall} instanced scheduled to run at different
 times.
 """
+self.patch(DelayedCall, 'debug', True)
 self.zero = self._getDelayedCallAt(0)
 self.one = self._getDelayedCallAt(1)

@@ -193,6 +194,7 @@ class DelayedCallTests(TestCase):
 C{str}, includes the unsigned id of the instance, as well as its state,
 the function to be called, and the function arguments.
 """
+DelayedCall.debug = False
 dc = DelayedCall(12, nothing, (3, ), {"A": 5}, None, None, lambda: 1.5)
 self.assertEqual(
 str(dc),

With best regards,
Philippe Goetz

Siemens AG
Building Technologies Division
Solution and Service Portfolio
Danger Management System
BT SSP SOL R&D CI DMS
Siemensallee 84
76187 Karlsruhe, Germany 
mailto:philippe.go...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; 
Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; 
Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael 
Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial 
registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. 
DE 23691322

Bug#863599: python-autobahn: twisted WebSocketResource don't work against twisted 16.6.0 (upstream bug #701)

[Goetz, Philippe]

Package: python-autobahn
Version: 0.14.1+dfsg1-2
Severity: important

Dear Maintainer,

Under stretch, when using autobahn.twisted.resource.WebSocketResource no 
onMessage is received.

This is a known upstream issue 
https://github.com/crossbario/autobahn-python/issues/701

Several commits has been made to fix it.

Here the git diff for the patch from 
https://github.com/crossbario/autobahn-python.git
(which has been successfully been tested):

git diff v0.14.1..64693e4693eeeda50bc781bdce4d4dba3172ebf5 -- 
autobahn/twisted/resource.py
diff --git a/autobahn/twisted/resource.py b/autobahn/twisted/resource.py
index 79d979f4..cb3b7b23 100644
--- a/autobahn/twisted/resource.py
+++ b/autobahn/twisted/resource.py
@@ -126,7 +126,7 @@ class WebSocketResource(object):

 # Take over the transport from Twisted Web
 #
-transport, request.transport = request.transport, None
+transport, request.channel.transport = request.channel.transport, None

 # Connect the transport to our protocol. Once #3204 is fixed, there
 # may be a cleaner way of doing this.
@@ -139,6 +139,12 @@ class WebSocketResource(object):
 transport.protocol = protocol
 protocol.makeConnection(transport)

+# On Twisted 16.3.0+, the transport is paused whilst the existing
+# request is served; there won't be any requests after us so we can
+# just resume this ourselves.
+if hasattr(transport, "resumeProducing"):
+transport.resumeProducing()
+
 # We recreate the request and forward the raw data. This is somewhat
 # silly (since Twisted Web already did the HTTP request parsing
 # which we will do a 2nd time), but it's totally non-invasive to our

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

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

Versions of packages python-autobahn depends on:
ii  python-cbor0.1.24-1+b1
ii  python-concurrent.futures  3.0.5-3
ii  python-lz4 0.8.2+dfsg-2
ii  python-msgpack 0.4.8-1
ii  python-nacl1.0.1-2
ii  python-qrcode  5.3-1
ii  python-six 1.10.0-3
ii  python-snappy  0.5-1.1
ii  python-trollius2.1~b1-4
ii  python-twisted 16.6.0-2
ii  python-txaio   2.5.1+2016.10.03.git.623ef68776-1
ii  python-zope.interface  4.3.2-1
pn  python:any 

python-autobahn recommends no packages.

python-autobahn suggests no packages.

-- no debconf information

With best regards,
Philippe Goetz

Siemens AG
Building Technologies Division
Solution and Service Portfolio
Danger Management System
BT SSP SOL R&D CI DMS
Siemensallee 84
76187 Karlsruhe, Germany 
mailto:philippe.go...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; 
Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; 
Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael 
Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial 
registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. 
DE 23691322

Bug#863598: meson: Please include converter tools

[Jeremy Bicha]

Package: meson
Version: 0.40.1-1
Severity: wishlist

According to http://mesonbuild.com/Porting-from-autotools.html
"Meson comes with a helper script ac_converter"

Neither of the two scripts in the tools/ directory are provided in the
Debian binary package. Please change this. It could be a separate
binary package since they aren't needed to build an app that already
uses meson.

Thanks,
Jeremy Bicha

Bug#863597: mkwinpeimg --iso tries to use mkisofs which is no longer present

[Gabriel Parrondo]

Package: wimtools
Version: 1.11.0-1

mkwinpeimg --iso tries to invoke mkisofs, which is not provided by any package.

As per the wiki[0], the package mkisofs is no longer available in
debian and the preferred replacement is xorriso.

Both xorriso and genisoimage have command-line compatibility with
mkisofs, so a workaround is to create a symlink:

ln -s /usr/bin/xorriso /usr/bin/mkisofs

Here's the output before creating the symlink:

$ mkwinpeimg --iso --windows-dir="$dir" winpe.iso
ERROR: To make a bootable ISO image of Windows PE, we need the "mkisofs"
program, but it doesn't seem to be installed.  Please install the "cdrkit"
package to continue, or try omitting the --iso option to make a disk image
instead of an ISO image.

Here's the output afterwards:
$ ln -s /usr/bin/xorriso /usr/bin/mkisofs
$ mkwinpeimg --iso --windows-dir="dir/" winpe.iso
:: Copying primary boot files from mounted Windows ISO (dir/)
 [DONE]
:: Exporting image from "dir//sources/boot.wim"
 [BUSY] Using LZX compression with
1 thread
Archiving file data: 641 MiB of 641 MiB (100%) done


 [DONE]
:: Making ISO image "winpe.iso"

 [BUSY] xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia
project.



 [DONE]
The image (winpe.iso) is 257501184 bytes.


This happens in Debian Stretch:
$ apt-cache policy wimtools
wimtools:
  Instalados: 1.11.0-1
  Candidato:  1.11.0-1
  Tabla de versión:
 *** 1.11.0-1 500
500 http://ftp.us.debian.org/debian stretch/main i386 Packages
100 /var/lib/dpkg/status
$ apt-cache policy xorriso
xorriso:
  Instalados: 1.4.6-1+b1
  Candidato:  1.4.6-1+b1
  Tabla de versión:
 *** 1.4.6-1+b1 500
500 http://ftp.us.debian.org/debian stretch/main i386 Packages
100 /var/lib/dpkg/status
$ apt-cache policy genisoimage
genisoimage:
  Instalados: 9:1.1.11-3+b2
  Candidato:  9:1.1.11-3+b2
  Tabla de versión:
 *** 9:1.1.11-3+b2 500
500 http://ftp.us.debian.org/debian stretch/main i386 Packages
100 /var/lib/dpkg/status


[0]: https://wiki.debian.org/genisoimage

Bug#863519: unblock blockdiag/1.5.3+dfsg-2

[Kouhei Maeda]

Hi,

2017-05-28 21:50 GMT+09:00 Jonathan Wiltshire :
> On Sun, May 28, 2017 at 08:51:27AM +0900, Kouhei Maeda wrote:
>> +  * Bumps version debian/compat to 9.
>> +- Fixes package-uses-deprecated-debhelper-compat-version.
>
> This isn't OK, please remove it.

This means that reverting debian/compat version, and increments debian version?

Regards,
--
Kouhei Maeda 
 KeyID 4096R/7E37CE41

Bug#863385: cloud.debian.org: Latest stretch AMI (ami-772ab761) fails to launch successfully into VPCs

[Andy Sizer]

On Fri, 26 May 2017 at 20:52 Ross Vandegrift  wrote:

> On Fri, May 26, 2017 at 09:15:35AM +0700, Andy Sizer wrote:
> > I tried to launch in instance from the latest stretch ami
> > (ami-772ab761 i.e. us-east-1) into a VPC. It failed - more
> > specifically networking.service failed.
>
> I just tried this AMI and all looks good to me.  Anything unusual about
> your
> VPC?  I'm using a default VPC without IPv6.
>
>
The VPC in question is configured as follows:

* IPv6 CIDR - x.y.z.0/24
* IPv6 CIDR - none
* DHCP options: domain-name = ec2.internal, domain-name-servers =
AmazonProvidedDNS
* Route table - nothing interesting here - just a 'gateway'
* ClassicLink - disabled
* Network ACL - again nothing interesting - the default inbound, outbound
rules, 1 associated subnet (i.e. the same as the VPC's)
* Tenancy - default
* DNS resolution - yes
* DNS hostnames - yes
* ClassicLink DNS support - no

It's not obvious to me that there's anything unusual there. Not sure when
this VPC was created, it predates my time here (> 2 years). FWIW the wheezy
and jessie AMIs launched fine into this VPC.

Anyway, I then did the following:

* launch ami-772ab761 in EC2-classic
* edit /etc/network/interfaces - add an entry for 'ens3' before 'eth0' -
same config
* create a new AMI
* launch new AMI into our VPC
* It came up 'OK' and was accessible via SSH.

The following might be informative:

root@ip-10-42-42-64:/var/log# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: ens3:  mtu 9001 qdisc mq state UP group
default qlen 1000
link/ether 0e:0c:48:21:5d:14 brd ff:ff:ff:ff:ff:ff
inet 10.42.42.64/24 brd 10.42.42.255 scope global ens3
   valid_lft forever preferred_lft forever
inet6 fe80::c0c:48ff:fe21:5d14/64 scope link
   valid_lft forever preferred_lft forever

root@ip-10-42-42-64:/var/log# ifconfig
ens3: flags=4163  mtu 9001
inet 10.42.42.64  netmask 255.255.255.0  broadcast 10.42.42.255
inet6 fe80::c0c:48ff:fe21:5d14  prefixlen 64  scopeid 0x20
ether 0e:0c:48:21:5d:14  txqueuelen 1000  (Ethernet)
RX packets 806  bytes 81137 (79.2 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 673  bytes 123224 (120.3 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@ip-10-42-42-64:/var/log# ifquery --read-environment --list
lo
ens3
eth0

[ ens3 AND eth0 ?? ]

root@ip-10-42-42-64:/var/log# head -n 18 /var/log/cloud-init-output.log
Cloud-init v. 0.7.9 running 'init-local' at Mon, 29 May 2017 02:34:12
+. Up 35.35 seconds.
Cloud-init v. 0.7.9 running 'init' at Mon, 29 May 2017 02:34:16 +. Up
39.66 seconds.
ci-info: Net device
info+
ci-info:
++--++-+---+---+
ci-info: | Device |  Up  |Address |   Mask  | Scope |
Hw-Address|
ci-info:
++--++-+---+---+
ci-info: |  lo:   | True |   127.0.0.1|255.0.0.0|   .   |
  . |
ci-info: |  lo:   | True |   .|.|   d   |
  . |
ci-info: | eth0:  | True | 10.233.189.228 | 255.255.255.192 |   .   |
22:00:0a:e9:bd:e4 |
ci-info: | eth0:  | True |   .|.|   d   |
22:00:0a:e9:bd:e4 |
ci-info:
++--++-+---+---+
ci-info: +Route IPv4
info+
ci-info:
+---+++-+---+---+
ci-info: | Route |  Destination   |Gateway | Genmask |
Interface | Flags |
ci-info:
+---+++-+---+---+
ci-info: |   0   |0.0.0.0 | 10.233.189.193 | 0.0.0.0 |
 eth0   |   UG  |
ci-info: |   1   | 10.233.189.192 |0.0.0.0 | 255.255.255.192 |
 eth0   |   U   |
ci-info:
+---+++-+---+---+

Let us know if there's anything else you'd like.

Seems like we have a workaround. But we'd prefer to be provisioning an
'official' AMI - if nothing else the workaround adds additional complexity
to our automation scripts.


>

Bug#863596: mytop can't installed

[Jörg Frings-Fürst]

Package: mytop
Version: 1.9.1-4
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

with the last mariadb upgrade I get:

~ > apt-get install mytop
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 mariadb-client-10.1 : Kollidiert mit: mytop aber 1.9.1-4 soll installiert
werden
E: Fehler: Unterbrechungen durch pkgProblemResolver::Resolve hervorgerufen;
dies könnte durch zurückgehaltene Pakete verursacht worden sein.




- -- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/6 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)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlkrl74ACgkQCfifPIyh
0l21fxAAh4bIU82OrwMKbBCbM3JP652VrfY7Qw5flAdeyEVBfSDYaoJcCSt1oJK3
00ncmRNVHj37wVz4W4qhy/0qE8U4Ly2jIka3GorsIsDQNfS6c0TUVnfplxqQiKtS
504xocVVLpv1Rr/RxovqlMhLyGlq5g3H4bdtHjGkvCxiht5Pv+aVJxejXk/beFgi
6c6fQLXN+G+Uu42lT++b/7ej1jPoxZvjQuKIpx1A2XvI9036e0TRXcWpjLWyAzot
f2YiJnJy2+lewbexyDlJnXZALDfNIaGUrrvA0N9H9lzQv+KG5ZomLOFK96UiD4O3
DLbJuAstGxBD1tdlX5cpTAgxE8DnpqSZsGJo9u/qOkPP8fAbPrWHtFmo4i1oPhAL
x7nFt+mtZbp+siAFtKa1OXqjj/k3J09JkUxIcjjgniyIu/dGVURs970NTOSxTxSg
qxqvTWvGkgxh0YHo0GK3wj/ppVfmxrGdouCZ/zY8tloyVWY26gzgUxtO6owy8Xyj
IFGURHdaDycsIwfr327J6tQolk9/1dUdYg0ZSgIHWzElsztHthZugHaTBZIDFo19
7Rj6xSdXkqBMN+P6Nh33BKb4rfvWLa1UIvg7KprQnBDXUojPyuJORjZlZGal3cWf
XNdRX1YC9BN3eulfyDPiWUWuaoEDNAZElx0PpHBopSjE0Mvdp5k=
=dXLj
-END PGP SIGNATURE-

Bug#863595: gnome-control-center: Can't save configuration if 'Use this connection only for resource on its network' is checked

[Fabian Inostroza]

Package: gnome-control-center
Version: 1:3.22.2-1
Severity: normal

Dear Maintainer,

Manually configuring a network interface and checking the option 'Use this 
connection only for 
resources on its network' doesn't allow to save it, the Apply button is grayed 
out.

nm-connection-editor works fine.


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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.43-1
ii  apg2.2.3.dfsg.1-4+b1
ii  colord 1.3.3-2
ii  desktop-file-utils 0.23-1
ii  gnome-control-center-data  1:3.22.2-1
ii  gnome-desktop3-data3.22.2-1
ii  gnome-settings-daemon  3.22.2-2
ii  gsettings-desktop-schemas  3.22.0-1
ii  libaccountsservice00.6.43-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-10
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libcanberra-gtk3-0 0.30-3
ii  libcanberra0   0.30-3
ii  libcheese-gtk253.22.1-1+b1
ii  libcheese8 3.22.1-1+b1
ii  libclutter-1.0-0   1.26.0+dfsg-3
ii  libclutter-gtk-1.0-0   1.8.2-2
ii  libcolord-gtk1 0.1.26-1.1
ii  libcolord2 1.3.3-2
ii  libcups2   2.2.1-8
ii  libfontconfig1 2.11.0-6.7+b1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libgnome-bluetooth13   3.20.1-1
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgoa-1.0-0b  3.22.5-1
ii  libgoa-backend-1.0-1   3.22.5-1
ii  libgrilo-0.3-0 0.3.2-2
ii  libgtk-3-0 3.22.11-1
ii  libgtop-2.0-10 2.34.2-1
ii  libgudev-1.0-0 230-3
ii  libibus-1.0-5  1.5.14-3
ii  libkrb5-3  1.15-1
ii  libmm-glib01.6.4-1
ii  libnm0 1.6.2-3
ii  libnma01.4.4-1
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpolkit-gobject-1-0  0.105-17
ii  libpulse-mainloop-glib010.0-1
ii  libpulse0  10.0-1
ii  libpwquality1  1.3.0-1+b1
ii  libsmbclient   2:4.5.8+dfsg-2
ii  libsoup2.4-1   2.56.0-2
ii  libupower-glib30.99.4-4+b1
ii  libwacom2  0.22-1+b1
ii  libx11-6   2:1.6.4-3
ii  libxi6 2:1.7.9-1
ii  libxml22.9.4+dfsg1-2.2

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.2-4
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.22.0.1-1+b1
ii  gnome-online-accounts 3.22.5-1
ii  gnome-user-guide  3.22.0-1
ii  gnome-user-share  3.18.3-1+b1
ii  iso-codes 3.75-1
ii  libcanberra-pulse 0.30-3
ii  libnss-myhostname 232-23
ii  mousetweaks   3.12.0-1+b1
ii  network-manager-gnome 1.4.4-1
ii  policykit-1   0.105-17
ii  pulseaudio-module-bluetooth   10.0-1
ii  realmd0.16.3-1
ii  rygel 0.32.1-3
ii  rygel-tracker 0.32.1-3
ii  system-config-printer-common  1.5.7-3

Versions of packages gnome-control-center suggests:
ii  gstreamer1.0-pulseaudio  1.10.4-1
pn  libcanberra-gtk-module   
ii  libcanberra-gtk3-module  0.30-3
ii  x11-xserver-utils7.7+7+b1

-- no debconf information

Bug#862057: Fwd: Bug#862057: udev: If more than one NIC the system is booting longer

[Michael Biebl]

On Mon, 8 May 2017 12:03:16 +0200 a a  wrote:
> Hi.
> The error message is systremd-udevd : swq 598
> `/devices/pci:00/:00:08.0/net/eth1`
> is taking a long time. After this i have the one normal interface like eth0
> and the other have renameX. This is in Vbox enviroment. I have tried to

Can you share your VBox configuration, especially the network hardware
configuration.



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



signature.asc
Description: OpenPGP digital signature

Bug#863364: RFA: pydocstyle -- Python docstring style checker (PEP-257 conventions)

[陳昌倬]

Control: retitle -1 ITA: pydocstyle -- Python docstring style checker
Control: owner -1 !

On Thu, May 25, 2017 at 09:11:16PM +0200, Daniel Stender wrote:
> Package: wnpp
> Severity: normal
> 
> I request an adopter for the pydocstyle package [1].

I will adopt this package.


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Elana Hashman]

All,

We are getting very close!

I have completed packaging for the three outstanding blocking bugs:

- #862233: use maven 3.5.0 and upgrade to pomegranate 0.4.0-alpha1
  https://anonscm.debian.org/cgit/pkg-clojure/pomegranate-clojure.git/ 
-- this
  one is complicated, wanted a few more eyes before upload, but I did 
test it


- #712908: packaged stencil 0.5.0
  https://anonscm.debian.org/cgit/pkg-clojure/stencil-clojure.git/ -- 
Barry

  Warsaw promised me he'd upload this at the PyCon sprints

- #719664: packaged parsley 0.9.3
  https://anonscm.debian.org/cgit/pkg-clojure/parsley-clojure.git/ -- 
just need

  a sponsor

Once these all get uploaded and freeze is over, we should be able to get 
the

leiningen packaging completed. Looking forward to that.

- e

Bug#863579: www.debian.org: include wiki team in /intro/organization

[José Gatica]

That sounds like a great idea  :)

On Mon, May 29, 2017 at 08:23:30AM +0800, Paul Wise wrote:
> On Sun, 2017-05-28 at 22:35 +0200, Laura Arjona Reina wrote:
> 
> > It would be nice to include the wiki team members in
> > /intro/organization, as well as the mail contact.
> 
> That seems reasonable.
> 
> > [Neither] https://wiki.debian.org/DebianWiki/Contact nor
> > https://wiki.debian.org/Teams/DebianWiki list people names, so people in the
> > wiki team should say if they want to appear there and provide the list of
> > names, positions, and mail addresses to list.
> 
> The team membership is technically defined by the wikiadm group in
> LDAP. In addition, Erinn Clark and Olly Betts do not recieve wiki@
> email right now and Erinn Clark and Asheesh Laroia aren't active teammembers. 
> Olly Betts joined to help out with the search stuff IIRC.
> 
> $ ldapsearch -ZLLL -x -h db.debian.org -b ou=users,dc=debian,dc=org 
> supplementaryGid=wikiadm uid gecos
> dn: uid=93sam,ou=users,dc=debian,dc=org
> uid: 93sam
> gecos: Steve McIntyre
> 
> dn: uid=erinn,ou=users,dc=debian,dc=org
> uid: erinn
> gecos: Erinn Clark
> 
> dn: uid=pabs,ou=users,dc=debian,dc=org
> uid: pabs
> gecos: Paul Wise
> 
> dn: uid=paulproteus,ou=users,dc=debian,dc=org
> uid: paulproteus
> gecos: Asheesh Laroia
> 
> dn: uid=olly,ou=users,dc=debian,dc=org
> uid: olly
> gecos: Olly Betts
> 
> email-virtualdomains (master=) $ git grep wiki:
> debian.org/aliases:wiki: p...@debian.org, 93...@debian.org, 
> paulprot...@debian.org
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise



-- 
José Gatica A.
ParrotSec Ambassador  -  Debian Wiki
https://docs.parrotsec.org/doku.php/user/josegatica
https://wiki.debian.org/JoseGatica
www.josegatica.cl

---
Libérate de los grilletes digitales del software privativo.
--- USA SOFTWARE LIBRE ---
Más info en http://www.fsf.org y en http://www.gnu.org
También puedes visitar http://www.stallman.org

-
No imprimas este mensaje a menos que sea estrictamente necesario.
Tenemos una inmensa deuda con nuestro Medio Ambiente.

Bug#846548: marked as pending

[Eric Dorland]

* Julien Cristau (jcris...@debian.org) wrote:
> On Mon, May 22, 2017 at 03:42:57 +, Eric Dorland wrote:
> 
> > tag 846548 pending
> > thanks
> > 
> > Hello,
> > 
> > Bug #846548 reported by you has been fixed in the Git repository. You can
> > see the changelog below, and you can check the diff of the fix at:
> > 
> > https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0
> > 
> So, erm.  This seems like it would break using libengine-pkcs11-openssl
> in an application using libssl1.0.2.  As a SONAME bump it also seems
> rather inappropriate during the freeze.

That's a good point. I was trying to provide an alternative to the
broken NMU that was going to be uploaded, but yes this will break
applications built against libssl1.0.2. It does fix using this with
the openssl tool however.

> I'm very interested in having this fixed in stretch so I can get the
> secure-boot stuff working on ftp-master, but this doesn't look like the
> way to go.  Not to mention that you'd have to justify the bump from
> 0.4.3 to 0.4.4.
> 
> Can you explain your plans here?

As you suggested in your followup, the way forward would appear to be
to upload a new libp11 source package that builds against
libssl1.0.2. I can also backport all of the changes to 0.4.3 and
upload to testing-proposed-updates. Does that sound reasonable?

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93

Bug#863267: [Python-modules-team] Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8

[Brian May]

On 2017-05-26 19:05, Neil Williams wrote:

> No. This is django making the wrong decision about problems it has
> previously supported when trying to include bug fixes for other
> problems. It is a regression in django 1.10

Feel free to argue this point in
https://code.djangoproject.com/ticket/28250 

Otherwise, I think we have three options. I recommend reading the Django
ticket in full before deciding. 

1. Apply work around from
https://code.djangoproject.com/ticket/28250#comment:1 by manually
recording that the database transaction has been applied. This could
potentially be automated as part of the postinst. 

2. Remove migration from postinst, and give instructions for manually
updating the database. Modify
/usr/share/doc/python-django/examples/migrate-south (maybe create new
file in Django package) so instead of installing Django 1.6.x in a
virtualenv and running migrations, it installs Django 1.8.x into
virtualenv and runs migrations. 

https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/tree/debian/contrib/migrate-south


3. Drop lava-server from testing. 

Also it might be worth updating the migrate script in Django - as per
option 2 - even if you decide 1 is the best option. Would help in case
any similar problems are identified - maybe with packages not in Debian
- after the release.

Bug#863513: [Reportbug-maint] Bug#863513: Bug#863513: Bug#863513: reportbug: No GUI; only '--ui=text'

[Sandro Tosi]

On Sun, May 28, 2017 at 4:06 PM, Nis Martensen  wrote:
> On Sat, 27 May 2017 22:32:49 -0400 Sandro Tosi  wrote:
>> do you know of a way to create a menu entry only if the needed
>> dependencies are installed?
>
> One could put the desktop file (and possibly the code for the GTK UI)
> into a separate package, which would depend on the required libraries.
> Attaching a first draft patch.

thanks (as always) for the patch! I'm still uncertain on the future of
the GTK+ UI: currently there is no one that willing to properly
maintain that UI; probably we should just split it into a separate
binary *and* source package and fine a way to provide UIs as plugin,
installable in a dir reportbug can scan and eventually enable them

> Not something for stretch, though.

hehe indeed


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#863594: veusz-helpers: duplicates .../veusz/resources symlink

[Aaron M. Ucko]

Package: veusz-helpers
Version: 1.21.1-1+b1
Severity: grave
Justification: renders package unusable (veusz becomes uninstallable)

The recent binNMU of veusz-helpers for sip-api-11.3 somehow made it
duplicate the /usr/lib/python2.7/dist-packages/veusz/resources symlink
from the main veusz package.  Even though the symlinks are identical,
dpkg tolerates this situation only with --force-overwrite:

  Unpacking veusz-helpers (1.21.1-1+b1) over (1.21.1-1) ...
  dpkg: error processing archive 
/tmp/user/0/apt-dpkg-install-y5VKrI/28-veusz-helpers_1.21.1-1+b1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/veusz/resources', 
which is also in package veusz 1.21.1-1
[...]
  $ sudo dpkg -i --force-overwrite 
/var/cache/apt/archives/veusz-helpers_1.21.1-1+b1_amd64.deb
  (Reading database ... 2474063 files and directories currently installed.)
  Preparing to unpack .../veusz-helpers_1.21.1-1+b1_amd64.deb ...
  Unpacking veusz-helpers (1.21.1-1+b1) over (1.21.1-1) ...
  dpkg: warning: overriding problem because --force enabled:
  dpkg: warning: trying to overwrite 
'/usr/lib/python2.7/dist-packages/veusz/resources', which is also in package 
veusz 1.21.1-1
  Setting up veusz-helpers (1.21.1-1+b1) ...

Could you please take a look, and ensure that the symlink once again
winds up in only one binary pacakges?

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386, x32

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

Versions of packages veusz-helpers depends on:
ii  libc6 2.24-10
ii  libgcc1   1:6.3.0-18
ii  libqt4-xml4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libstdc++66.3.0-18
ii  python2.7.13-2
ii  python-numpy [python-numpy-abi9]  1:1.12.1-2
ii  python-qt44.11.4+dfsg-2+b1
ii  python-sip [sip-api-11.3] 4.18.1+dfsg-2

veusz-helpers recommends no packages.

Versions of packages veusz-helpers suggests:
ii  veusz  1.21.1-1

-- no debconf information

Bug#863579: www.debian.org: include wiki team in /intro/organization

[Paul Wise]

On Sun, 2017-05-28 at 22:35 +0200, Laura Arjona Reina wrote:

> It would be nice to include the wiki team members in
> /intro/organization, as well as the mail contact.

That seems reasonable.

> [Neither] https://wiki.debian.org/DebianWiki/Contact nor
> https://wiki.debian.org/Teams/DebianWiki list people names, so people in the
> wiki team should say if they want to appear there and provide the list of
> names, positions, and mail addresses to list.

The team membership is technically defined by the wikiadm group in
LDAP. In addition, Erinn Clark and Olly Betts do not recieve wiki@
email right now and Erinn Clark and Asheesh Laroia aren't active teammembers. 
Olly Betts joined to help out with the search stuff IIRC.

$ ldapsearch -ZLLL -x -h db.debian.org -b ou=users,dc=debian,dc=org 
supplementaryGid=wikiadm uid gecos
dn: uid=93sam,ou=users,dc=debian,dc=org
uid: 93sam
gecos: Steve McIntyre

dn: uid=erinn,ou=users,dc=debian,dc=org
uid: erinn
gecos: Erinn Clark

dn: uid=pabs,ou=users,dc=debian,dc=org
uid: pabs
gecos: Paul Wise

dn: uid=paulproteus,ou=users,dc=debian,dc=org
uid: paulproteus
gecos: Asheesh Laroia

dn: uid=olly,ou=users,dc=debian,dc=org
uid: olly
gecos: Olly Betts

email-virtualdomains (master=) $ git grep wiki:
debian.org/aliases:wiki: p...@debian.org, 93...@debian.org, 
paulprot...@debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#860950: steam: crashes at startup

[Clayton]

> Can you provide more information about your system and how to
> reproduce this?  Others have tried and failed, so there must be more
> to it.  Try backing up .steam somewhere else so it tries to start
> fresh.

I just tried on a different x86_64 machine and it works for me there
too. However on the original i386 machine from which I reported the
bug, I can still reliably reproduce.

Clayton

Bug#863593: ITP: golang-github-chai2010-gettext-go -- GNU gettext for Go

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-chai2010-gettext-go
  Version : 0.0~git20160711.0.c6fed77-1
  Upstream Author : chai2010
* URL : https://github.com/chai2010/gettext-go
* License : BSD-3-clause
  Programming Lang: Go
  Description : GNU gettext for Go

This library implements the interface of the GNU gettext library for
Go. Use the SetLocale and BindTextdomain functions to add
internationalization and localization features to your Go application
using translation files.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#823110: cups-filters: Versioned dependency on imagemagick makes using graphicsmagick harder

[Yuri D'Elia]

Package: cups-filters
Version: 1.11.6-3
Followup-For: Bug #823110

I second this, and push it further.
cups-filters depends on imagemagik for "convert" alone, and it's used only in:

 /var/lib/cups/filter/imagetobrf
 /var/lib/cups/filter/texttobrf

Both usage of convert are absolutely trivial, and graphicsmagick can fulfil
both without problems.

I originally filed a bug to downgrade the dependency of braille-dependent tools
to a Recommends.

Please change the dependency to:

 Recommends: imagemagick (>= 6.4~) | graphicsmagick-imagemagick-compat

Please note that I do not want to dismiss braille support here. I'd rather see
braille filters split into a separate package where we can properly Depend on
the required tools instead.

-- System Information:
Debian Release: 9.0
 APT prefers unstable
 APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64
(x86_64)

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

Versions of packages cups-filters depends on:
ii  bc   1.06.95-9+b3
ii  cups-filters-core-drivers1.11.6-3
ii  ghostscript  9.20~dfsg-3.2
ii  imagemagick  8:6.9.7.4+dfsg-9
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-9
ii  libc62.24-10
ii  libcups2 2.2.1-8
ii  libcupsfilters1  1.11.6-3
ii  libcupsimage22.2.1-8
ii  libfontconfig1   2.12.1-0.1
ii  libfontembed11.11.6-3
ii  libgcc1  1:6.3.0-18
ii  libijs-0.35  0.35-12
ii  libpoppler64 0.48.0-2
ii  libqpdf176.0.0-2
ii  libstdc++6   6.3.0-18
ii  poppler-utils0.48.0-2

Versions of packages cups-filters recommends:
ii  colord1.3.3-2
pn  liblouisutdml-bin | liblouis-bin  

Versions of packages cups-filters suggests:
pn  antiword   
pn  docx2txt   
pn  foomatic-db-compressed-ppds | foomatic-db  

-- Configuration Files:
/etc/modules-load.d/cups-filters.conf [Errno 2] No such file or directory: 
'/etc/modules-load.d/cups-filters.conf'

Bug#858924: gnome-calendar: Segfault in gcal_manager_create_event when adding event

[Jason Crain]

On Sat, Apr 22, 2017 at 06:46:34PM -0500, Jason Crain wrote:
> On Tue, Mar 28, 2017 at 01:36:45PM -0400, Daniel Gnoutcheff wrote:
> > 1. Click on an empty day to add a new event
> > 2. Click "Edit Details..."
> > 3. Click "Done"
> > 
> > Result: gnome-calendar segfaults.  
> 
> This crash is fixed upstream with the attached patch.

Can this be fixed for stretch?  This bug means that trying to create a
new event and using the "Edit Details..." button in gnome-calendar will
make it crash.  I've attached a debdiff (patch copied from upstream)
that fixes this in the unstable version.

Since gnome-calendar has different versions in testing and unstable, I
think this would require going through testing-proposed-updates.  If a
maintainer agrees with the patch and uploads it to unstable, I'll create
a release.debian.org bug to ask for approval to also upload to
testing-proposed-updates.
diff -Nru gnome-calendar-3.22.4/debian/changelog 
gnome-calendar-3.22.4/debian/changelog
--- gnome-calendar-3.22.4/debian/changelog  2017-03-29 16:00:23.0 
-0500
+++ gnome-calendar-3.22.4/debian/changelog  2017-05-28 10:31:05.0 
-0500
@@ -1,3 +1,10 @@
+gnome-calendar (3.22.4-2) unstable; urgency=high
+
+  * Add debian/patches/0003-set-edit-dialogs-event-to-NULL-after-saving.patch:
+fix crash when creating a new event. (Closes: #858924)
+
+ -- Jason Crain   Sun, 28 May 2017 10:31:05 -0500
+
 gnome-calendar (3.22.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
gnome-calendar-3.22.4/debian/patches/0003-set-edit-dialogs-event-to-NULL-after-saving.patch
 
gnome-calendar-3.22.4/debian/patches/0003-set-edit-dialogs-event-to-NULL-after-saving.patch
--- 
gnome-calendar-3.22.4/debian/patches/0003-set-edit-dialogs-event-to-NULL-after-saving.patch
 1969-12-31 18:00:00.0 -0600
+++ 
gnome-calendar-3.22.4/debian/patches/0003-set-edit-dialogs-event-to-NULL-after-saving.patch
 2017-05-28 10:31:05.0 -0500
@@ -0,0 +1,39 @@
+From: Yash Singh 
+Date: Fri, 10 Mar 2017 17:58:52 +0530
+Subject: window: set edit dialog's event to NULL after saving
+
+Earlier the app used to crash when a new event was added using the
+'Edit Details' buttion/dialog. This was happening because edit dialog's
+event was set to NULL before the event was being stored in the calendar
+through the 'edit_dialog' and hence the app was crashing.
+
+This patch fixes the above-mentioned issue by saving the event before
+setting the edit dialog's event to NULL.
+
+Origin: upstream, 
https://git.gnome.org/browse/gnome-calendar/commit/?id=6f87ada70dbeae71e3428ee3a63f79b8c918f121
+Bug: https://bugzilla.gnome.org/779733
+Bug-Debian: https://bugs.debian.org/858924
+Last-Update: 2017-05-28
+---
+ src/gcal-window.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/src/gcal-window.c
 b/src/gcal-window.c
+@@ -1102,7 +1102,6 @@
+   event = gcal_edit_dialog_get_event (edit_dialog);
+   view = GCAL_VIEW (window->views[window->active_view]);
+ 
+-  gcal_edit_dialog_set_event (edit_dialog, NULL);
+   gtk_widget_hide (GTK_WIDGET (dialog));
+ 
+   switch (response)
+@@ -1149,6 +1148,8 @@
+   break;
+ 
+ }
++
++  gcal_edit_dialog_set_event (edit_dialog, NULL);
+ }
+ 
+ static void
diff -Nru gnome-calendar-3.22.4/debian/patches/series 
gnome-calendar-3.22.4/debian/patches/series
--- gnome-calendar-3.22.4/debian/patches/series 2016-09-14 17:30:46.0 
-0500
+++ gnome-calendar-3.22.4/debian/patches/series 2017-05-28 10:22:32.0 
-0500
@@ -1,2 +1,3 @@
 0001-Hide-GOA-sources-on-Unity.patch
 0002-Spawn-Ubuntu-s-credentials-panel-instead-of-the-GOA-.patch
+0003-set-edit-dialogs-event-to-NULL-after-saving.patch

Bug#863578: Initial upload to experimental should probably still merge history

[Russ Allbery]

Sean Whitton  writes:

> For the first upload of policy 4.0.0.x to unstable, I'm suggesting
> --deliberately-not-fast-forward so that the history is a linear
> descendent of the upload you made to experimental today.  With
> --overwrite, instead, the parent of HEAD would be a pseudomerge with
> dgit's representation of policy 3.9.8.0.  Maybe you prefer this, of
> course.

Oh, hm.  I actually think the second is better, isn't it?  Since it allows
anyone who had cloned dgit's representation of 3.9.8.0 to update cleanly
to the current dgit tree.

-- 
Russ Allbery (r...@debian.org)   

Bug#863592: UDD should use https for links

[Adrian Bunk]

Package: qa.debian.org
Severity: minor
User: qa.debian@packages.debian.org
Usertags: udd

I noticed that the links to the bugs from UDD bugs searches are
http and not https.

>From a quick grep through the sources there seem to be more
places where https could be used instead of http.

Bug#863578: Initial upload to experimental should probably still merge history

[Sean Whitton]

On Sun, May 28, 2017 at 03:12:11PM -0700, Russ Allbery wrote:
> Oh, okay, I think I understand.  And then, when uploading to unstable, it
> would then work?  Or would I need --overwrite on the upload to unstable?

In the context of uploads that are new to a suite, it is best to think
of --overwrite and --deliberately-not-fast-forward as mutually
exclusive.

For the first upload of policy 4.0.0.x to unstable, I'm suggesting
--deliberately-not-fast-forward so that the history is a linear
descendent of the upload you made to experimental today.  With
--overwrite, instead, the parent of HEAD would be a pseudomerge with
dgit's representation of policy 3.9.8.0.  Maybe you prefer this, of
course.

(This is a pretty confusing aspect of dgit that only became apparent
after some conversations Ian had at FOSSDEM.  Sorry that documentation
has not caught up.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863578: Initial upload to experimental should probably still merge history

[Russ Allbery]

Sean Whitton  writes:
> On Sun, May 28, 2017 at 02:59:16PM -0700, Russ Allbery wrote:

>> Does that merge the dgit history of the package from the unstable
>> branch into the history in the way that dgit-maint-native implies is
>> supposed to happen?  Or by "be a descendent of unstable" do you mean a
>> descendent of the dgit unstable repository?

> No, it basically prevents that automatic merge from happening (and as
> such it only works when the package is new in the suite).

Oh, okay, I think I understand.  And then, when uploading to unstable, it
would then work?  Or would I need --overwrite on the upload to unstable?

-- 
Russ Allbery (r...@debian.org)   

Bug#863578: Initial upload to experimental should probably still merge history

[Sean Whitton]

On Sun, May 28, 2017 at 02:59:16PM -0700, Russ Allbery wrote:
> > This is already possible: have your git history be a descendent of
> > unstable, and use --deliberately-not-fast-forward instead of
> > --overwrite.  Documentation of this is waiting in #856402.
> 
> Ah, yes, I presume that would work.

Just to be clear, this is a bit of a fudge, and not the use for which
--deliberately-not-fast-forward option was intended.  That's why it's
somewhat hidden away.

> Does that merge the dgit history of the package from the unstable
> branch into the history in the way that dgit-maint-native implies is
> supposed to happen?  Or by "be a descendent of unstable" do you mean a
> descendent of the dgit unstable repository?

No, it basically prevents that automatic merge from happening (and as
such it only works when the package is new in the suite).

By "descendent of unstable" I just meant your old, non-dgit history
which contains a commit corresponding to what you last uploaded to
unstable.

> > In light of what I wrote above, the suggestion would be to have
> > --deliberately-not-fast-forward be implicit for --new uploads to
> > experimental where HEAD is a descendent of dgit/dgit/sid?
> 
> I think the missing piece may be how the naive new user like myself, who
> is currently told to just do dgit push --overwrite, should create the
> appropriate merge so that this condition is true of my existing
> repository.  (I know enough Git that I could probably fumble my way
> through, but dgit should probably do it for me somehow.)

I think what I suggested would supply that, but it might not be wise to
ignore the user's --overwrite.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863591: Mention --build-products-dir in dgit-maint-gbp(7)

[Sean Whitton]

Package: dgit
Version: 3.10
Severity: minor

On Sun, May 28, 2017 at 02:47:30PM -0700, Russ Allbery wrote:
> Could you mention --build-products-dir in dgit-maint-gbp, since this
> is a very common setting?

I agree with Russ -- as he wrote in another message, gbp users very
often have build products output somewhere other than ..

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863578: Initial upload to experimental should probably still merge history

[Russ Allbery]

Sean Whitton  writes:

> This is already possible: have your git history be a descendent of
> unstable, and use --deliberately-not-fast-forward instead of
> --overwrite.  Documentation of this is waiting in #856402.

Ah, yes, I presume that would work.  Does that merge the dgit history of
the package from the unstable branch into the history in the way that
dgit-maint-native implies is supposed to happen?  Or by "be a descendent
of unstable" do you mean a descendent of the dgit unstable repository?

> In light of what I wrote above, the suggestion would be to have
> --deliberately-not-fast-forward be implicit for --new uploads to
> experimental where HEAD is a descendent of dgit/dgit/sid?

I think the missing piece may be how the naive new user like myself, who
is currently told to just do dgit push --overwrite, should create the
appropriate merge so that this condition is true of my existing
repository.  (I know enough Git that I could probably fumble my way
through, but dgit should probably do it for me somehow.)

-- 
Russ Allbery (r...@debian.org)   

Bug#863578: Initial upload to experimental should probably still merge history

[Sean Whitton]

On Sun, May 28, 2017 at 01:34:04PM -0700, Russ Allbery wrote:
> If a package that hasn't been using dgit is uploaded using dgit to
> experimental, when it hasn't been uploaded to experimental before,
> one cannot use the --overwrite option and merge previous dgit history.
> Presumably (I haven't gotten that far yet) this will happen on the
> first upload to unstable.

This is already possible: have your git history be a descendent of
unstable, and use --deliberately-not-fast-forward instead of
--overwrite.  Documentation of this is waiting in #856402.

(In your case, I would suggest using this trick on the first upload to
unstable, so that can be a descendent of the history in experimental.)

> I may be naive about dgit's branch model, but it seems like it would
> be good to merge dgit's history with the maintainer's history as early
> as possible in this process, and experimental uploads (when there's no
> previous experimental upload) should be considered a descendent of the
> unstable history.
> 
> The separation makes a lot of sense to me for stable branches or
> backports branches, but experimental is not a "true" suite in the way
> in which it's used in Debian; it's more of a temporary branch from
> unstable, and I guess I was expecting dgit to treat it that way.

In light of what I wrote above, the suggestion would be to have
--deliberately-not-fast-forward be implicit for --new uploads to
experimental where HEAD is a descendent of dgit/dgit/sid?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863582: Allow configurable build directory

[Russ Allbery]

Control: forcemerge 857316 -1 

Sean Whitton  writes:

> I believe that Ian's intention is that the build tool should be
> configured to put build products somewhere else, and then dgit should be
> told where they are using --build-products-dir.  I.e. you have
> ~/.gbp.conf telling gbp where to put build products, and then

> % dgit --build-products-dir ~/foo gbp-build

Oh!  That was the flag I was missing.  Thank you.  Could you mention
--build-products-dir in dgit-maint-gbp, since this is a very common
setting?

> Of course, it really should be possible to set a permanent
> --build-products-dir in ~/.gitconfig.  That's #857316.

> Does this fulfill your feature request?  If so, this bug should be
> merged with #857316.

Yup!  That seems fine.  Thank you!

-- 
Russ Allbery (r...@debian.org)   

Bug#862992: systemd: avoid attempt to re-create /etc/mtab by systemd-tmpfiles-setup.service

[Cyril Brulebois]

Hi,

Maximilian Stein  (2017-05-28):
> I tried it again and apparently, /etc/mtab was actually created by
> FAI, not by debootstrap, sorry for the confusion.

Ah, this would explain. :)

> But maybe it would be an idea to create it by debootstrap to avoid its
> creation on the first boot?

I'm not convinced by this. There a quite a bunch of situations where
debootstrap is used to create a system that's not even supposed to be
booted from, so I guess having systemd do its automatic fixing of bits
if that's needed… is just fine as-is. Even more so since we already have
appropriate instructions within debian-installer for setups where's a
system to be run is being installed.


KiBi.


signature.asc
Description: Digital signature

Bug#863582: Allow configurable build directory

[Sean Whitton]

On Sun, May 28, 2017 at 01:38:30PM -0700, Russ Allbery wrote:
> I use git-buildpackage for all of my package building, and one reason why
> is that I deeply dislike the default Debian behavior of cluttering the
> parent directory with random package build files.  git-buildpackage has
> always supported configuring a build directory (../build-area appears to
> be common) to use for build output, where it doesn't clutter directory
> listings and can easily be purged after successful uploads.
> 
> It looks like dgit doesn't support this.

I believe that Ian's intention is that the build tool should be
configured to put build products somewhere else, and then dgit should be
told where they are using --build-products-dir.  I.e. you have
~/.gbp.conf telling gbp where to put build products, and then

% dgit --build-products-dir ~/foo gbp-build

Of course, it really should be possible to set a permanent
--build-products-dir in ~/.gitconfig.  That's #857316.

Does this fulfill your feature request?  If so, this bug should be
merged with #857316.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#792552: [pkg-cryptsetup-devel] Bug#792552: still doesn't continue shutdown process

[Pali Rohár]

On Sunday 28 May 2017 21:26:53 Guilhem Moulin wrote:
> Hi Pali,
> 
> On Thu, 25 May 2017 at 18:23:00 +0200, Pali Rohár wrote:
> > Same problem there. I have up-to-date Debian Stretch with
> > LUKS-encrypted rootfs and system hangup on every shutdown or
> > reboot.
> > 
> > I debugged this problem and found out that after this log message
> > 
> > [] Stopping remaining crypto disks...
> > 
> > is called cryptsetup luksClose  And cryptsetup itself freeze.
> 
> Which init system are you using?  Your diagnostic looks pretty much
> like
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791944#27

Exactly.

> which as I explained in message #86 is due to /etc/init.d/sendsigs
> killing systemd-udevd at shutdown/reboot time, thereby causing
> dmsetup to hang.

And removing remaining socket file /run/udev/control before invoking 
cryptsetup fixes hanging.

> The udev/systemd maintainers have fixed #791944,
> but their fix probably didn't land into Stretch yet.

Seems it is not in Stretch yet: 
http://metadata.ftp-master.debian.org/changelogs/main/s/systemd/systemd_232-23_changelog

Should I create release bug report for Stretch? This seems to be a big 
problem if shutdown/reboot procedure hangs when using encrypted disk.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#863590: unblock: libsndfile/1.0.27-3

[IOhannes m zmoelnig]

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

Please unblock package libsndfile

this upload backports fixes for a number of security-related bugs
(CVE-2017-7742, CVE-2017-8361 CVE-2017-8362 CVE-2017-8363 CVE-2017-8365) from
upstream.

since libsndfile is a widely used library for reading/writing soundfiles of many
formats, security issues affect quite a number of ordinary desktops.

unblock libsndfile/1.0.27-3

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libsndfile-1.0.27/debian/changelog libsndfile-1.0.27/debian/changelog
--- libsndfile-1.0.27/debian/changelog  2017-04-04 15:33:45.0 +0200
+++ libsndfile-1.0.27/debian/changelog  2017-05-28 22:52:39.0 +0200
@@ -1,3 +1,24 @@
+libsndfile (1.0.27-3) unstable; urgency=medium
+
+  * Mentioned CVEs fixed by fix_bufferoverflows.patch
+(CVE-2017-7741, CVE-2017-7586, CVE-2017-7585)
+  * Backported patch for error handling of malicious/broken FLAC files
+(CVE-2017-7742, CVE-2017-7741, CVE-2017-7585)
+(Closes: #860255)
+  * Backported patch to fix buffer read overflow in FLAC code
+(CVE-2017-8362)
+(Closes: #862204)
+  * Backported patches to fix memory leaks in FLAC code
+(CVE-2017-8363)
+(Closes: #862203)
+  * Backported patch to fix buffer overruns in FLAC-code
+(CVE-2017-8365, CVE-2017-8363, CVE-2017-8361)
+(Closes: #862205, #862203, #862202)
+
+  * Added Vcs-* stanzas to d/control
+
+ -- IOhannes m zmölnig (Debian/GNU)   Sun, 28 May 2017 
22:52:39 +0200
+
 libsndfile (1.0.27-2) unstable; urgency=medium
 
   * Backported fixes for buffer-write overflows from 1.0.28.
diff -Nru libsndfile-1.0.27/debian/control libsndfile-1.0.27/debian/control
--- libsndfile-1.0.27/debian/control2017-04-04 15:33:45.0 +0200
+++ libsndfile-1.0.27/debian/control2017-05-28 22:52:39.0 +0200
@@ -9,6 +9,8 @@
  libasound2-dev [linux-any]
 Standards-Version: 3.9.8
 Homepage: http://www.mega-nerd.com/libsndfile/
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/libsndfile.git
+Vcs-Browser: https://anonscm.debian.org/git/collab-maint/libsndfile.git
 
 Package: libsndfile1-dev
 Section: libdevel
diff -Nru libsndfile-1.0.27/debian/patches/CVE-2017-7742.patch 
libsndfile-1.0.27/debian/patches/CVE-2017-7742.patch
--- libsndfile-1.0.27/debian/patches/CVE-2017-7742.patch1970-01-01 
01:00:00.0 +0100
+++ libsndfile-1.0.27/debian/patches/CVE-2017-7742.patch2017-05-28 
22:52:39.0 +0200
@@ -0,0 +1,89 @@
+Description: more fixes for FLAC error handling
+ fixes CVE-2017-7742, CVE-2017-7741, CVE-2017-7585
+Author: Eric de Castro Lopo
+Origin: upstream
+Applied-Upstream: 
https://github.com/erikd/libsndfile/commit/60b234301adf258786d8b90be5c1d437fc8799e0
+Last-Update: 2017-05-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- libsndfile.orig/src/flac.c
 libsndfile/src/flac.c
+@@ -68,9 +68,9 @@
+   unsigned bufferpos ;
+ 
+   const FLAC__Frame *frame ;
+-  FLAC__bool bufferbackup ;
+ 
+   unsigned compression ;
++
+ } FLAC_PRIVATE ;
+ 
+ typedef struct
+@@ -187,10 +187,9 @@
+ 
+   if (pflac->ptr == NULL)
+   {   /*
+-  **  Not sure why this code is here and not elsewhere.
+-  **  Removing it causes valgrind errors.
++  ** This pointer is reset to NULL each time the current frame 
has been
++  ** decoded. Somehow its used during encoding and decoding.
+   */
+-  pflac->bufferbackup = SF_TRUE ;
+   for (i = 0 ; i < channels ; i++)
+   {
+   if (pflac->rbuffer [i] == NULL)
+@@ -206,6 +205,11 @@
+ 
+   len = SF_MIN (pflac->len, frame->header.blocksize) ;
+ 
++  if (pflac->remain % channels != 0)
++  {   psf_log_printf (psf, "Error: pflac->remain %uchannels 
%u\n", pflac->remain, channels) ;
++  return 0 ;
++  } ;
++
+   switch (pflac->pcmtype)
+   {   case PFLAC_PCM_SHORT :
+   {   short *retpcm = (short*) pflac->ptr ;
+@@ -381,7 +385,6 @@
+   pflac->frame = frame ;
+   pflac->bufferpos = 0 ;
+ 
+-  pflac->bufferbackup = SF_FALSE ;
+   pflac->wbuffer = buffer ;
+ 
+   flac_buffer_copy (psf) ;
+@@ -906,11 +909,19 @@
+ static unsigned
+ flac_read_loop (SF_PRIVATE *psf, unsigned len)
+ { FLAC_PRIVATE* pflac = (FLAC_PRIVATE*) psf->codec_data ;
++  FLAC__StreamDecoderState state ;
+ 
+   pflac->pos = 0 ;
+   pflac->len = len ;
+   pflac->remain = len ;
+ 
++  state = FLAC__stream_decoder_get_state (pflac

Bug#860763: imagemagick: /etc/imagemagick-6/policy.xml useless limits settings

[Yuri D'Elia]

Package: imagemagick-6-common
Version: 8:6.9.7.4+dfsg-9
Followup-For: Bug #860763

I agree with the original reporter here. The policy includes arbitrary limits
which cannot easily be modified by invoking the commands.

If we want to ensure the "resource" limits do not get exceeded in order to
avoid a potential DOS, the admin should use ulimit(1).

The '' policy also kills the
ability to annotate text in a pipe:

 echo 'x' | convert -annotate '@-' ...

will fail with a 'not authorized' error, which is rather confusing as this is
precisely the kind of example as done in the documentation.

Of course, @[path] will allow to read-in external data, but this somehow
implies that the user of convert is *not* under control of the annotation text.

This seems a rather weak form of protection which prevents a rather useful
feature.

The only "policy" that I agree with is to disable remote delegates (I never
expect an image toolkit to perform remote queries).

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
display:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
import:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
montage:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
stream:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org

-- System Information:
Debian Release: 9.0
 APT prefers unstable
 APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64
(x86_64)

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

-- Configuration Files:
/etc/ImageMagick-6/policy.xml changed [not included]

Bug#863589: fpc: Please adjust fp-units-gfx.install.in for linux-m68k

[John Paul Adrian Glaubitz]

Source: fpc
Version: 3.0.0+dfsg-11
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

I just bootstrapped fpc for m68k. In order for the build to work the next
time the buildds are building it, the debian/fp-units-gfx.install.in
needs to be adjusted so that usr/lib/fpc/*/*/*/graph* and
usr/lib/fpc/*/*/*/opencl* aren't missing during dh_install.

Thus:


diff -Nru old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in 
new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in
--- old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-04-09 
11:44:58.0 +0200
+++ new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-05-28 
23:11:23.52224 +0200
@@ -1,11 +1,11 @@
 #! /usr/bin/dh-exec
 usr/lib/fpc/*/*/*/ggi*
-usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-ppc64]
+usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-m68k !linux-ppc64]
 usr/lib/fpc/*/*/*/hermes*
 usr/lib/fpc/*/*/*/imagemagick*
 usr/lib/fpc/*/*/*/libgd*
 usr/lib/fpc/*/*/*/libpng*
-usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-powerpc !linux-ppc64]
+usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-m68k !linux-powerpc !linux-ppc64]
 usr/lib/fpc/*/*/*/opengl*
 usr/lib/fpc/*/*/*/opengles*
 usr/lib/fpc/*/*/*/ptc*  [!freebsd-any]

Could you apply this change for the next upload?

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in 
new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in
--- old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-04-09 
11:44:58.0 +0200
+++ new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-05-28 
23:11:23.52224 +0200
@@ -1,11 +1,11 @@
 #! /usr/bin/dh-exec
 usr/lib/fpc/*/*/*/ggi*
-usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-ppc64]
+usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-m68k !linux-ppc64]
 usr/lib/fpc/*/*/*/hermes*
 usr/lib/fpc/*/*/*/imagemagick*
 usr/lib/fpc/*/*/*/libgd*
 usr/lib/fpc/*/*/*/libpng*
-usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-powerpc !linux-ppc64]
+usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-m68k !linux-powerpc !linux-ppc64]
 usr/lib/fpc/*/*/*/opengl*
 usr/lib/fpc/*/*/*/opengles*
 usr/lib/fpc/*/*/*/ptc*  [!freebsd-any]

Bug#863367: [Pkg-openssl-devel] Bug#863367: libecryptfs-dev: unable to install because of unmet dependency

[David Kalnischkies]

On Sat, May 27, 2017 at 04:31:46PM +0200, Kurt Roeckx wrote:
> In general, I disagree that we should declare a conflict at both
> sides of the conflict and that the package manager should be able
> to deal with a conflict on just one side. It's not a conflict that
> involves version numbers.

The idea behind not automatically having the conflict effect both sides
is that a package which declares a conflict has a competitive advantage
over the conflictee as it reduces the score of the conflictee which
makes it easier for the conflictor to win against it in fights.
If apt would apply the conflict automatically on both sides the
advantage disappears. That hinders the successful resolution of the
usual situation in case a conflict isn't declared on both sides: The
package which hasn't the conflict is the "old" package (not updated for
the release e.g. because it was removed) which should loose against the
"new" package which has the conflict declared.


Beside that little heuristic trickery I believe it to be cleaner and
more discoverable for a user that such a conflict exists and is intended
if it is declared on both sides.

And lastly, I guess 'domain knowledge' is involved as we wouldn't be
talking if libssl-dev would be a new mail-transport-agent. It would be
perfectly clear that it must conflict with the others even if there is
no technical reason for it given that the other mail-transport-agents
already conflict with it.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#863588: unblock: wicd/1.7.4+tb2-4 (documentation and translation only)

[Axel Beckert]

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

Please unblock package wicd, it only contains documentation fixes,
translation bug fixes and one new translation:

* I oversaw in the previous upload that there was still an outdated,
  non-source-format-3.0 related debian/README.source. I replaced it
  with some useful documentation for the team.

* A semantically wrong translation ("automatically connect" vs "never
  connect") has been found and fixed in the Galician translation
  file. See https://bugs.debian.org/856690.

* A Vietnamese translation file has been added.

* One uploader's name has been normalized to ASCII-only letters.

Diffstat:

 README.source   |   28 21 +7 - 
0 !
 changelog   |   18 16 +2 - 
0 !
 control |2 1 + 1 - 
0 !
 patches/43-fix-wrong-Galician-translation.patch |   19 19 +0 - 
0 !
 patches/series  |1 1 + 0 - 
0 !
 po/vi.po|   33 33 +0 - 
0 !
 6 files changed, 91 insertions(+), 10 deletions(-)

Full debdiff:

diff -Nru wicd-1.7.4+tb2/debian/README.source 
wicd-1.7.4+tb2/debian/README.source
--- wicd-1.7.4+tb2/debian/README.source 2016-01-23 22:43:47.0 +0100
+++ wicd-1.7.4+tb2/debian/README.source 2017-05-24 21:36:58.0 +0200
@@ -1,12 +1,26 @@
 wicd for Debian

+===
 
-This package uses quilt to manage all modifications to the upstream
-source.  Changes are stored in the source package as diffs in
-debian/patches and applied during the build.
+Where to look for wicd patches from other distributions?
+
 
-Please read how to use quilt in the provided documentation:
+* Gentoo:
+  https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/wicd/files
+* ArchLinux:
+  + https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/wicd
+  + https://aur.archlinux.org/cgit/aur.git/tree/?h=wicd-patched
+* Voidlinux:
+  https://github.com/voidlinux/void-packages/tree/master/srcpkgs/wicd/patches
+* Pull-requests against outdated upstream repo at GitHub:
+  https://github.com/dpaleino/wicd/pulls
+* openSUSE:
+  https://build.opensuse.org/package/show/home:msalle:extras/wicd
 
-  /usr/share/doc/quilt/README.source
+Bug reports with patches
+
 
- -- David Paleino   Wed, 24 Dec 2008 10:40:45 +0100
+* Upstream: https://bugs.launchpad.net/wicd/+bugs?field.tag=patch
+* Ubuntu:
+  https://bugs.launchpad.net/ubuntu/+source/wicd/+bugs?field.tag=patch
+
+ -- Axel Beckert , Wed, 24 May 2017 21:36:58 +0200
diff -Nru wicd-1.7.4+tb2/debian/changelog wicd-1.7.4+tb2/debian/changelog
--- wicd-1.7.4+tb2/debian/changelog 2017-01-22 17:16:07.0 +0100
+++ wicd-1.7.4+tb2/debian/changelog 2017-05-28 22:20:00.0 +0200
@@ -1,3 +1,17 @@
+wicd (1.7.4+tb2-4) unstable; urgency=medium
+
+  [ Axel Beckert ]
+  * Drop old quilt-related contents of debian/README.source and hijack it
+for inter-distribution hints.
+
+  [ Giap Tran ]
+  * Add patch to fix wrong Galician translation (Closes: #856690,
+LP: #1689138)
+  * Add Vietnamese translation.
+  * Change my name to ASCII-compatible variant also in debian/changelog.
+
+ -- Axel Beckert   Sun, 28 May 2017 22:20:00 +0200
+
 wicd (1.7.4+tb2-3) unstable; urgency=medium
 
   [ Axel Beckert ]
@@ -18,7 +32,7 @@
 (re)generates. Also update mention path in an older NEWS.Debian item
 to avoid confusion. (Closes: #773809)
 
-  [ Giáp Trần ]
+  [ Giap Tran ]
   * Remove $DAEMON_OPTIONS from reload function.
 
   [ John C. Peterson ]
@@ -41,7 +55,7 @@
   * Declare compliance with Debian Policy 3.9.8. (No changes needed.)
   * Switch Vcs-Git header from git:// to https://.
 
-  [ Giáp Trần ]
+  [ Giap Tran ]
   * Add default DAEMON_ARGS="--keep-connection" to /etc/default/wicd
 (Closes: #816076)
 
diff -Nru wicd-1.7.4+tb2/debian/control wicd-1.7.4+tb2/debian/control
--- wicd-1.7.4+tb2/debian/control   2017-01-22 06:08:42.0 +0100
+++ wicd-1.7.4+tb2/debian/control   2017-05-08 00:41:25.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian WICD Packaging Team 
 Uploaders: Axel Beckert ,
-   Giáp Trần 
+   Giap Tran 
 Build-Depends: debhelper (>= 9~),
dh-python,
python (>= 2.6.6-3~)
diff -Nru wicd-1.7.4+tb2/debian/patches/43-fix-wrong-Galician-translation.patch 
wicd-1.7.4+tb2/debian/patches/43-fix-wrong-Galician-translation.patch
--- wicd-1.7.4+tb2/debian/patches/43-fix-wrong-Galician-translation.patch   
1970-01-01 01:00:00.0 +0100
+++ wicd-1.7.4+tb2/debian/patches/43-fix-wrong-Galician-translation.patch   
2017-05-24 22:53:46.0 +0200
@@ -0,0 +1,19 @@
+Description: Fixed wrong Galic

Bug#863587: redshift: Can't get location because no response from API

[Jan Wójtowicz]

Package: redshift
Version: 1.9.1-4
Severity: important

Dear Maintainer,
I tried to use Redshift and it asked for package `geoclue` for providing
location. I installed it and launched redshift again (through console) and it
tried to use geoclue to find location - without success. The only way to use
redshift is to uninstall geoclue package and to set location manually. Redshift
installed from debian stretch sources seems to work fine, maybe fix could be
ported from there.
Here's the output from when I tried to start it within console.
===
jan@acer-aspire-debian:~$ redshift
Trying location provider `geoclue'...
Started Geoclue provider `Geoclue Master'.
Using provider `geoclue'.
Could not get location: xmlNanoHTTPMethod did not get a response from
http://api.hostip.info/
..
Could not retrieve location from provider.

Yours,
Jan



-- System Information:
Debian Release: 8.8
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates'), (90, 'testing'), (1, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages redshift depends on:
ii  libc6 2.19-18+deb8u9
ii  libdbus-1-3   1.8.22-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libdrm2   2.4.58-2
ii  libgeoclue0   0.12.99-4
ii  libglib2.0-0  2.42.1-1+b1
ii  libx11-6  2:1.6.2-3
ii  libxcb-randr0 1.10-3+b1
ii  libxcb1   1.10-3+b1
ii  libxml2   2.9.1+dfsg1-5+deb8u4
ii  libxxf86vm1   1:1.1.3-1+b1

redshift recommends no packages.

redshift suggests no packages.

-- no debconf information

Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

[Sean Whitton]

Hello Nicholas,

On Sun, May 28, 2017 at 02:27:04PM -0400, Nicholas D Steeves wrote:
> Test colir-color-parse condition:
> (void-function colir-color-parse)
>FAILED   1/16  colir-color-parse
> ...
> dh_elpa_test: emacs -batch -Q -l package --eval (add-to-list
> 'package-directory-list "/usr/share/emacs/site-lisp/elpa") --eval
> (add-to-list 'package-directory-list
> "/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -L . -l
> ivy-test.el --eval (ert-run-tests-batch-and-exit) returned exit code 1
> debian/rules:4: recipe for target 'build' failed make: *** [build]
> Error 2 dpkg-buildpackage: error: debian/rules build gave error exit
> status 2
> 
> The test in question is around L210 of ivy-test.el.  If I manually
> load-file colir.el and eval-expression (colir-color-parse "#ab1234")
> with emacs25, it returns the correct triplet as a list, so I'm not
> sure where the problem is or how to proceed.  Commenting out
> autopkgtest-pkg-elpa in d/control doesn't seem to help.  Any advice
> for debugging this with greater verbosity, since my
> ignorance/inexperience is preventing further progress on this ITP?
> Not installing ivy-test.el seems sloppy...

I think it's just a missing (require 'colir) at the top of ivy-test.el.
You could patch it in, or since upstream might not be willing to merge
such a patch, use in d/elpa-test:

ert_eval = (load-file "colir.el")

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863586: CVE-2017-4965 CVE-2017-4966 CVE-2017-4967

[Moritz Muehlenhoff]

Package: rabbitmq-server
Severity: grave
Tags: security

Please see
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-4965
https://security-tracker.debian.org/tracker/CVE-2017-4966
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-4967

Cheers,
Moritz

Bug#863585: bugs.debian.org: View of usertags on bug summary page

[Sean Whitton]

Package: bugs.debian.org
Severity: wishlist

Hello,

It would be great if we could see usertags set on a bug on the bug
summary page.  For debian-policy, for example, the only way to find out
the process stage that a bug has reached[1] is to visit
, which is less convenient.

Thanks.

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

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386
 (i686)

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863584: CVE-2017-2824

[Moritz Muehlenhoff]

Source: zabbix
Severity: grave
Tags: security

Please see
http://www.talosintelligence.com/reports/TALOS-2017-0325/
http://www.talosintelligence.com/reports/TALOS-2017-0326/

Cheers,
Moritz

Bug#863583: CVE-2017-7473

[Moritz Muehlenhoff]

Package: ansible
Severity: important
Tags: security

This was only reported in Red Hat bugzilla and further information
is scarce: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7473

Cheers,
Moritz

Bug#863582: Allow configurable build directory

[Russ Allbery]

Package: dgit
Version: 3.10
Severity: wishlist

I use git-buildpackage for all of my package building, and one reason why
is that I deeply dislike the default Debian behavior of cluttering the
parent directory with random package build files.  git-buildpackage has
always supported configuring a build directory (../build-area appears to
be common) to use for build output, where it doesn't clutter directory
listings and can easily be purged after successful uploads.

It looks like dgit doesn't support this.  At least, I don't see any
configuration option that lets me set it, and dgit was unable to find
builds in my configured build directory for upload.  And there's no
mention of this (quite common) configuration in the dgit-maint-gbp man
page.

Could this please be added?  Or if I'm missing the documentation for it,
maybe a few pointers to the correct documentation could be added to that
man page?

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

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

Versions of packages dgit depends on:
ii  apt   1.4.4
ii  ca-certificates   20161130+nmu1
ii  coreutils 8.26-3
ii  curl  7.52.1-5
ii  devscripts2.17.5
ii  dpkg-dev  1.18.24
ii  dput-ng [dput]1.12
ii  git [git-core]1:2.11.0-4
ii  git-buildpackage  0.8.12.2
ii  libdpkg-perl  1.18.24
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-2
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1-2

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.4p1-10

Versions of packages dgit suggests:
pn  sbuild  

-- no debconf information

Bug#863578: Initial upload to experimental should probably still merge history

[Russ Allbery]

Package: dgit
Version: 3.10
Severity: wishlist

If a package that hasn't been using dgit is uploaded using dgit to
experimental, when it hasn't been uploaded to experimental before,
one cannot use the --overwrite option and merge previous dgit history.
Presumably (I haven't gotten that far yet) this will happen on the
first upload to unstable.

I may be naive about dgit's branch model, but it seems like it would
be good to merge dgit's history with the maintainer's history as early
as possible in this process, and experimental uploads (when there's no
previous experimental upload) should be considered a descendent of the
unstable history.

The separation makes a lot of sense to me for stable branches or
backports branches, but experimental is not a "true" suite in the way
in which it's used in Debian; it's more of a temporary branch from
unstable, and I guess I was expecting dgit to treat it that way.

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

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

Versions of packages dgit depends on:
ii  apt   1.4.4
ii  ca-certificates   20161130+nmu1
ii  coreutils 8.26-3
ii  curl  7.52.1-5
ii  devscripts2.17.5
ii  dpkg-dev  1.18.24
ii  dput-ng [dput]1.12
ii  git [git-core]1:2.11.0-4
ii  git-buildpackage  0.8.12.2
ii  libdpkg-perl  1.18.24
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-2
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1-2

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.4p1-10

Versions of packages dgit suggests:
pn  sbuild  

-- no debconf information

Bug#863579: www.debian.org: include wiki team in /intro/organization

[Laura Arjona Reina]

Package: www.debian.org
Severity: normal

It would be nice to include the wiki team members in /intro/organization, as
well as the mail contact.

Nor https://wiki.debian.org/DebianWiki/Contact nor
https://wiki.debian.org/Teams/DebianWiki list people names, so people in the
wiki team should say if they want to appear there and provide the list of
names, positions, and mail addresses to list.



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

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

Bug#863581: RM: resteasy/3.1.0-1

[Moritz Muehlenhoff]

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

Please remove resteasy from stretch. It's affected by a number of
security issues and has no rev deps in stretch (dogtail-pki is
only in sid at this point). This can be straigtened out for buster.
Acked by Timo Aaltonen.

Cheers,
   Moritz

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Branko Majic]

Package: cloud.debian.org
Severity: important

Dear Maintainer,

When additional networks are configured in Vagrantfile, this can
result in Vagrant boxes randomly failing while bringing them up. Issue
occurs both with debian/jessie64 and debian/contrib-jessie64.

Reproduction steps:

1. Install latest version of Vagrant and VirtualBox. Issue should be
   reproducible with older versions too.

2. Create a simple Vagrantfile with the following content:

%
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "debian/contrib-jessie64"

  config.vm.define "machine" do |machine|
machine.vm.hostname = "machine"
machine.vm.network "private_network", ip: "10.64.128.10"
  end

end
%

3. Bring up and destroy the Vagrant machine repeatedly (several
   repetitions may be needed to reproduce the issue):

vagrant up && vagrant destroy -f


Expected results:

1. Step (3) of reproduction steps always succeeds.


Actual results:

1. Step (3) of reproduction steps intermittently fails, with error:

%
machine: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
%


Additional information:

Host environment is Gentoo x86_64, VirtualBox 5.1.18, Vagrant 1.9.5,
debian/contrib-jessie64 8.7.0.

Some testing was done with bento/debian-8.7 base box too, and the
issue could not be reproduced. After some troubleshooting, it turned
out that with debian/jessie64 box the network interfaces eth0 and eth1
may "swap places". E.g. instead of default (NAT) adapter being eth0
and private adapeter being eth1, default adapter would become available
as eth1, and private adapter would become available as eth0, making it
impossible for Vagrant to connect (no IP assigned, since
/etc/network/interfaces assumes eth0 is the NAT adapter for purpose of
getting address from built-in DHCP).

After comparing the files in two boxes, turned out that
debian/contrib-jessie64 defines different network adapter type for
first network adapter and remaining ones (82540EM vs Am79C973). This
probably results in somewhat random ordering in the VM itself when
adapters are being named. Relevant file where this is defined is
"box.ovf".

One could work around this issue with private network definition as:

machine.vm.network "private_network", ip: "10.64.128.10", nic_type: "82540EM"

The best way would be, however, to fix it in base box image instead,
similar to what the Bento box does (all the network interfaces, even
unused ones have 82540EM specified as adapter type). This is especially
true because of how hard it is to figure the issue out (took me a
while to realise what is happening).

Alternative would be to introduce udev rules that would ensure the NAT
network adapter always gets the same name based on MAC.


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

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

Bug#863577: include translation teams in /intro/organization

[Laura Arjona Reina]

package:www.debian.org

It would be nice to include the translation teams in the webpage
www.debian.org/intro/organization

The user support mailing lists are done using some script, it can
serve as inspiration for l10n-language teams.

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#863576: Perl error on --overwrite --new

[Russ Allbery]

Package: dgit
Version: 3.10
Severity: minor

I'm uploading a native package (debian-policy) using dgit that has never
used dgit before, and I'm uploading the package to experimental.  This
isn't really anticipated by dgit-maint-native, so I went down a path of
trying to use the command there, being told that the package doesn't exist
in that suite (I'm going to file another wishlist bug about that), and
being told to add --new.  But if I do that, I get the following output:

mithrandir:~/dvl/debian/policy$ dgit -wgf --overwrite --new push
canonical suite name is experimental
no version available from the archive
Use of uninitialized value $objid in hash element at /usr/bin/dgit line 991.
! Push failed, while preparing your push.
! You can retry the push, after fixing the problem, if you like.

I was able to guess that the problem was that --overwrite and --new aren't
meaningful together, but the error message is quite opaque and flags a line
in the middle of deep dgit plumbing that doesn't make the cause obvious.

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

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

Versions of packages dgit depends on:
ii  apt   1.4.4
ii  ca-certificates   20161130+nmu1
ii  coreutils 8.26-3
ii  curl  7.52.1-5
ii  devscripts2.17.5
ii  dpkg-dev  1.18.24
ii  dput-ng [dput]1.12
ii  git [git-core]1:2.11.0-4
ii  git-buildpackage  0.8.12.2
ii  libdpkg-perl  1.18.24
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-2
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1-2

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.4p1-10

Versions of packages dgit suggests:
pn  sbuild  

-- no debconf information

Bug#863575: unblock: node-concat-stream/1.5.1-2

[Ross Gammon]

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

Please unblock package node-concat-stream

Node-concat-stream is vunerable to Uninitialized Memory Exposure (CWE-201).
This was reported in bug https://bugs.debian.org/cgi-
bin/bugreport.cgi?archive=no&bug=863481. This was fixed upstream, and a version
of the fixing commit is included in this version as a patch. The patch has been
tested with the upstream testsuite, which unfortunately has to be disabled as
the testing framework (node-tape) does not exist in testing.

More information can be found in the attached debdiff (between tesing &
unstable), in the patch description.

unblock node-concat-stream/1.5.1-2

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

Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
diff -Nru node-concat-stream-1.5.1/debian/changelog node-concat-stream-1.5.1/debian/changelog
--- node-concat-stream-1.5.1/debian/changelog	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/changelog	2017-05-28 16:19:49.0 +0200
@@ -1,3 +1,12 @@
+node-concat-stream (1.5.1-2) unstable; urgency=high
+
+  * Apply upstream fix for Uninitialized Memory Exposure weakness CWE-201
+(Closes: #863481)
+  * Use stretch git branch
+  * Use Ubuntu email address
+
+ -- Ross Gammon   Sun, 28 May 2017 16:19:49 +0200
+
 node-concat-stream (1.5.1-1) unstable; urgency=low
 
   * Initial release (Closes: #796351)
diff -Nru node-concat-stream-1.5.1/debian/control node-concat-stream-1.5.1/debian/control
--- node-concat-stream-1.5.1/debian/control	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/control	2017-05-28 16:19:49.0 +0200
@@ -2,13 +2,13 @@
 Section: web
 Priority: optional
 Maintainer: Debian Javascript Maintainers 
-Uploaders: Ross Gammon 
+Uploaders: Ross Gammon 
 Build-Depends: debhelper (>= 9),
dh-buildinfo,
nodejs
 Standards-Version: 3.9.6
 Homepage: https://github.com/maxogden/concat-stream#readme
-Vcs-Git: git://anonscm.debian.org/pkg-javascript/node-concat-stream.git
+Vcs-Git: git://anonscm.debian.org/pkg-javascript/node-concat-stream.git -b stretch
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-concat-stream.git
 
 Package: node-concat-stream
diff -Nru node-concat-stream-1.5.1/debian/gbp.conf node-concat-stream-1.5.1/debian/gbp.conf
--- node-concat-stream-1.5.1/debian/gbp.conf	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/gbp.conf	2017-05-28 16:19:49.0 +0200
@@ -6,7 +6,7 @@
 
 # The default name for the Debian branch is "master".
 # Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = stretch
 
 # git-import-orig uses the following names for the upstream tags.
 # Change the value if you are not using git-import-orig
diff -Nru node-concat-stream-1.5.1/debian/patches/series node-concat-stream-1.5.1/debian/patches/series
--- node-concat-stream-1.5.1/debian/patches/series	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/patches/series	2017-05-28 16:19:49.0 +0200
@@ -1 +1,2 @@
 readable-stream.patch
+to-string_numbers.patch
diff -Nru node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch
--- node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch	1970-01-01 01:00:00.0 +0100
+++ node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch	2017-05-28 16:19:49.0 +0200
@@ -0,0 +1,81 @@
+Description: to-string numbers written to the stream
+ Node-concat-stream is vulnerable to Uninitialized Memory Exposure. This
+ possible memory disclosure vulnerability exists when a value of type number
+ is provided to the stringConcat() method and results in concatination of
+ uninitialized memory to the stream collection.
+ This is a result of unobstructed use of the Buffer constructor, whose
+ insecure default constructor increases the odds of memory leakage.
+ See https://snyk.io/vuln/npm:concat-stream:20160901 for further details.
+Origin: upstream, https://github.com/maxogden/concat-stream/
+Bug: https://github.com/maxogden/concat-stream/issues/55
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863481
+Applied-Upstream: https://github.com/maxogden/concat-stream/pull/47/commits/3e285ba5e5b10b7c98552217f5c1023829efe69e
+Last-Update: 2017-05-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- node-concat-stream.orig/index.js
 node-concat-stream/index.js
+@@ -73,6 +73,10 @@
+   return /Array\]$/.test(Object.prototype.toString.call(arr))
+ }
+ 
++function isBufferish (p) {
++  return 

Bug#863574: smemstat command crashes on ARM based machine (part 2)

[Helder Alves]

Package: smemstat
Version: 0.01.10-2
Severity: important

When I run smemstat command with root user I'm getting "Segmentation fault"
error, while everything works fine when I run it with any regular user.

I'm running Debian Jessie 8.8 on armel architecture.

This issue seems related with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852070

Below you'll find my /proc/cpuinfo:


root@arm:~# cat /proc/cpuinfo
processor   : 0
model name  : ARM926EJ-S rev 5 (v5l)
BogoMIPS: 226.09
Features: swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part: 0x926
CPU revision: 5

Hardware: Freescale MXS (Device Tree)
Revision: 
Serial  : 


--
Helder Alves

Bug#862992: systemd: avoid attempt to re-create /etc/mtab by systemd-tmpfiles-setup.service

[Maximilian Stein]

Hi,

I tried it again and apparently, /etc/mtab was actually created by FAI,
not by debootstrap, sorry for the confusion. But maybe it would be an
idea to create it by debootstrap to avoid its creation on the first boot?

Best,
Maximilian



signature.asc
Description: OpenPGP digital signature

Bug#863518: nftables: "workstation" example breaks alternate keyboard layout in gdm

[Arturo Borrero Gonzalez]

Control: severity -1 normal

On 28 May 2017 at 00:54, Harlan Lieberman-Berg
 wrote:
>
> Bizarrely, the quite simple "workstation" example causes the language picker 
> in
> gdm3 to disappear and the default layout to switch back to qwerty.  As far as 
> I
> can tell this doesn't happen on the next boot, but rather a couple of boots
> later.
>
> Disabling the nftables ruleset and rebooting fixes the problem completely.
>
> I'm not sure whether this is an nftables bug or a gdm bug, but I'm putting it
> here as similar iptables rules don't cause this behavior.
>

Hi,

I've been using this example ruleset for years now, with no issues.
The example ruleset isn't buggy. Generally, if a machine is
misbehaving after loading a firewall ruleset, it usually means that
the ruleset policy is wrong for your environment/configuration. This
is highly possible, and that's why the file is just an example: you
will probably need to tune the ruleset or the rest of the
configuration of your machine.

Regarding the 'uninterruptable sleep', the nft command line interface
tool (what the nftables package contains) is by no means intended to
interfere with kernel ability to send signals to other running process
(i.e. to interrupt others processes). No code is included in this
package. How could a bug in the nftables CLI tool led to chrome to
hang?

So your problem is likely in another place. Probably the kernel. Did
you check 'dmesg' after the issue happens? Perhaps you are hitting an
oops related to the network stack. The strace you attached shows that
nftables hangs when trying to talk to the netlink subsystem.

A nfnetlink/nf_tables kernel bug is indeed more likely, but then this
bug belongs to the linux package.

To summarise, this is my opinion on the possibilities of this bugs:
* configuration issue in your machine
* linux kernel bug

I'm Lowering the severity right now because of this.

Bug#863513: [Reportbug-maint] Bug#863513: Bug#863513: reportbug: No GUI; only '--ui=text'

[Nis Martensen]

On Sat, 27 May 2017 22:32:49 -0400 Sandro Tosi  wrote:
> do you know of a way to create a menu entry only if the needed
> dependencies are installed?

One could put the desktop file (and possibly the code for the GTK UI)
into a separate package, which would depend on the required libraries.
Attaching a first draft patch.

Not something for stretch, though.
>From 14fc7be72a49b704fa3f2cbff275a546fbcd0878 Mon Sep 17 00:00:00 2001
From: Nis Martensen 
Date: Sun, 14 May 2017 21:32:43 +0200
Subject: [PATCH 7/9] split off the GTK ui into a separate package

 - debian/control: create new package "reportbug-gui"
 - adjust depends/recommends/suggests as needed
 - move the .desktop file into the GUI package
---
 debian/control | 29 -
 debian/rules   |  2 +-
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 44eb97c..31d224d 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Homepage: http://alioth.debian.org/projects/reportbug/
 Package: reportbug
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, apt, python3-reportbug (= ${source:Version})
-Suggests: postfix | exim4 | mail-transport-agent, gnupg | pgp, debconf-utils (>> 1.1.0), debsums (>= 2.0.47), file (>> 1.30), dlocate, python3-urwid, python3-gi, python3-gi-cairo, gir1.2-gtk-3.0, gir1.2-vte-2.91, python3-gtkspellcheck, xdg-utils, emacs23-bin-common | emacs24-bin-common, claws-mail (>= 3.8.0)
+Suggests: postfix | exim4 | mail-transport-agent, gnupg | pgp, debconf-utils (>> 1.1.0), debsums (>= 2.0.47), file (>> 1.30), dlocate, python3-urwid, emacs23-bin-common | emacs24-bin-common
 Description: reports bugs in the Debian distribution
  reportbug is a tool designed to make the reporting of bugs in Debian
  and derived distributions relatively painless.  Its features include:
@@ -32,6 +32,9 @@ Description: reports bugs in the Debian distribution
  .
  This package also includes the "querybts" script for browsing the
  Debian bug tracking system.
+ .
+ This package only includes a text interface. Please install the
+ "reportbug-gui" package for a graphical user interface.
 
 Package: python3-reportbug
 Section: python
@@ -46,3 +49,27 @@ Description: Python modules for interacting with bug tracking systems
  tools that want to interact with the Debian bug tracking system.
  .
  To actually report a bug, install the reportbug package.
+
+Package: reportbug-gui
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}, apt, reportbug (= ${source:Version}), python3-reportbug (= ${source:Version}), python3-gi, python3-gi-cairo, gir1.2-gtk-3.0, gir1.2-vte-2.91
+Recommends: python3-gtkspellcheck, xdg-utils
+Suggests: claws-mail (>= 3.8.0)
+Description: reports bugs in the Debian distribution (GUI)
+ reportbug is a tool designed to make the reporting of bugs in Debian
+ and derived distributions relatively painless.  Its features include:
+ .
+  * Integration with mutt and mh/nmh mail readers.
+  * Access to outstanding bug reports to make it easier to identify
+whether problems have already been reported.
+  * Automatic checking for newer versions of packages.
+  * Optional automatic verification of integrity of packages via debsums.
+  * Support for following-up on outstanding reports.
+  * Optional PGP/GnuPG integration.
+ .
+ reportbug is designed to be used on systems with an installed mail
+ transport agent, like exim or sendmail; however, you can edit the
+ configuration file and send reports using any available mail server.
+ .
+ This package provides the graphical user interface (GUI) for desktop
+ systems.
diff --git a/debian/rules b/debian/rules
index 66335a8..4741864 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,7 +25,7 @@ override_dh_auto_install:
 	chmod 0755 $(CURDIR)/debian/reportbug/usr/bin/*
 	cp -p conf/reportbug.conf $(CURDIR)/debian/reportbug/etc
 
-	cp -p debian/desktop $(CURDIR)/debian/reportbug/usr/share/applications/reportbug.desktop
+	cp -p debian/desktop $(CURDIR)/debian/reportbug-gui/usr/share/applications/reportbug.desktop
 
 override_dh_installman:
 	dh_installman man/*
-- 
2.1.4

Bug#863572: ITP: wallpaperdownloader -- Download, manage and change your favorite wallpapers from the Internet

[Eloy García Almadén]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?b?RWxveSBHYXJjw61hIEFsbWFkw6lu?= 

* Package name: wallpaperdownloader
  Version : 2.7
  Upstream Author : Eloy García Almadén 
* URL : https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader
* License : GPL-3
  Programming Lang: Java
  Description : Download, manage and change your favorite wallpapers from
the Internet

WallpaperDownloader is a GUI Java-based application for downloading, managing
and setting wallpapers from different sources. Currently there are five
providers implemented. It allows the user to define keywords in order to
download those wallpapers which fit the search terms. Users can bookmark their
favorite wallpapers too, delete those who don't want to keep and move them to
another location. It implements a background changer to change automatically
the wallpaper in 1,5,10,30 or 60 minutes. It currently support a lot of Desktop
Environments including Plasma 5, GNOME Shell, Unity, XFCE and MATE.

Additional information
- I think this package is useful for people who likes wallpapers and loves to
download, manage and change them automatically using a GUI and using their own
keywords. I use it on a daily basis and a lot of people is currently using it
because it is published in the Ubuntu Store (as a snap package:
https://uappexplorer.com/app/wallpaperdownloader.egarcia) and in AUR for Arch
Linux (https://aur.archlinux.org/packages/wallpaperdownloader/). There are some
other packages providing the same functionality (as Variety for example), but I
think WallpaperDownloader is the only one which allows the user to define
exactly the search terms to find their favorite wallpapers.

- WallpaperDownloader is currently under development and new features are
included in every release. This is the Wiki of the project, so you can check
all the history, versions, features and more:
https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/wiki/Home

Thanks!

Bug#863573: unblock: diamond/4.0.515-4

[Sandro Tosi]

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

Please unblock package diamond

This upload improves (even if only slightly, as a proper solution is still being
worked on by upstream) the stop/restart time of diamond, by setting the systemd
killmode to mixed.

A source debdiff is attached

unblock diamond/4.0.515-4

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru diamond-4.0.515/debian/changelog diamond-4.0.515/debian/changelog
--- diamond-4.0.515/debian/changelog2017-01-22 17:28:37.0 -0500
+++ diamond-4.0.515/debian/changelog2017-05-28 15:48:29.0 -0400
@@ -1,3 +1,10 @@
+diamond (4.0.515-4) unstable; urgency=medium
+
+  * debian/diamond.service
+- set KillMode to `mixed`; Closes: #854842
+
+ -- Sandro Tosi   Sun, 28 May 2017 15:48:29 -0400
+
 diamond (4.0.515-3) unstable; urgency=medium
 
   * debian/control
diff -Nru diamond-4.0.515/debian/diamond.service 
diamond-4.0.515/debian/diamond.service
--- diamond-4.0.515/debian/diamond.service  2016-02-16 09:29:38.0 
-0500
+++ diamond-4.0.515/debian/diamond.service  2017-05-28 15:48:15.0 
-0400
@@ -4,6 +4,7 @@
 [Service]
 ExecStart=/usr/bin/python /usr/bin/diamond --log-stdout --foreground
 Restart=on-abort
+KillMode=mixed
 
 [Install]
 WantedBy=multi-user.target

Bug#838177: [os-prober] Version 1.75 has the same bug

[Antonio De Luci]

Package: os-prober
Version: 1.75

No correct initrd line for Arch Linux with microcodes installed.

--- System information. ---
Architecture:
Kernel: Linux 4.9.0-3-amd64

Debian Release: 9.0
500 unstable mirror3.mirror.garr.it
500 unstable ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6 (>= 2.4) | 2.24-10
grub-common | 2.02~beta3-5


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#863499: [Pkg-xfce-devel] Bug#863499: Trash: sort the files/folders by "time of deletion"

[Yves-Alexis Perez]

On Sat, 2017-05-27 at 21:56 +0200, Christian Buhtz wrote:
> while viewing the content of the Trash there is no way to sort the files and
> folders by there deletetion date/time. So I have no way to find the last
> deleted files.

What about sorting by modification date?

Regards,
-- 
Yves-Alexis

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

Bug#792552: [pkg-cryptsetup-devel] Bug#792552: still doesn't continue shutdown process

[Guilhem Moulin]

Hi Pali,

On Thu, 25 May 2017 at 18:23:00 +0200, Pali Rohár wrote:
> Same problem there. I have up-to-date Debian Stretch with LUKS-encrypted 
> rootfs and system hangup on every shutdown or reboot.
> 
> I debugged this problem and found out that after this log message
> 
> [] Stopping remaining crypto disks...
> 
> is called cryptsetup luksClose  And cryptsetup itself freeze.

Which init system are you using?  Your diagnostic looks pretty much like

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791944#27

which as I explained in message #86 is due to /etc/init.d/sendsigs
killing systemd-udevd at shutdown/reboot time, thereby causing dmsetup
to hang.  The udev/systemd maintainers have fixed #791944, but their fix
probably didn't land into Stretch yet.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#863442: pan window to large

[Ralf]

Back again :)

1) starting pan --verbose
2) playing with the "View -> Body Pane -> Monospace font" option 

3) output:

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
news.pan.NZB was not provided by any .service files

(pan:8729): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size
>= 0' failed in GtkExpander

-- 
Ralf 

Le dimanche 28 mai 2017 à 21:29 +0200, Ralf a écrit :
> Hi Dominique,
> 
> Thank you for feedback.
> 
> Changed several times the "View -> Body Pane -> Monospace font" value
> (sorry my UI is in French), not precisely understanding what you
> expected me to do there :) : As I did 2-3 times, the windows expanded
> far to the right, as explained in the 1st report (without staying in
> a
> specially long written post).
> 
> - Once the windows size has been mistakenly drawn by the window
> manager, when I shut down Pan and relaunch it, I get the same, to
> large
> window, it's impossible to resize it by hand.
> 
> - If I wait a few seconds, I might get a correct size back, or I get
> the wrong size, I don't understand now what makes things change or
> not.
> 
> Guess this won't help much ... Sorry :)
> 
> Ralf
> 

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Chris Lamb]

Hi,

> runit-init: Cannot reboot or shutdown after installing (or removing) the 
> package.

See also:

  https://bugs.debian.org/863539
  https://bugs.debian.org/863541
  https://bugs.debian.org/863542
  https://bugs.debian.org/863543


Regards,

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

Bug#863442: pan window to large

[Ralf]

Hi Dominique,

Thank you for feedback.

Changed several times the "View -> Body Pane -> Monospace font" value
(sorry my UI is in French), not precisely understanding what you
expected me to do there :) : As I did 2-3 times, the windows expanded
far to the right, as explained in the 1st report (without staying in a
specially long written post).

- Once the windows size has been mistakenly drawn by the window
manager, when I shut down Pan and relaunch it, I get the same, to large
window, it's impossible to resize it by hand.

- If I wait a few seconds, I might get a correct size back, or I get
the wrong size, I don't understand now what makes things change or not.

Guess this won't help much ... Sorry :)

Ralf

-- 
Ralf 

Le dimanche 28 mai 2017 à 16:51 +0200, Dominique Dumont a écrit :
> On vendredi 26 mai 2017 23:48:42 CEST you wrote:
> > The origin seems to be a post in a debian newgroup, the
> > linux.debian.ports.hurd contains a post titled "Still Failing: g-i-
> > installation_debian_sid_daily_hurd_lxde/353".
> 
> I found the article you mention but pan 0.141 displays it correctly.
> 
> Can you try changing the setting in "View -> Body Pane" menu ?
> 
> All the best

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

Hi there--

On Sun 2017-05-28 19:54:33 +0200, Ivo De Decker wrote:

> On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote:
>> May I suggest only removing runit-init from the runit source package, if
>> the bug can't be fixed in time for the stretch release?
>
> Sure. That just needs someone to upload such an NMU very soon. I suggested
> this already at the end of message #49:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49
>
>> Because runit itself doesn't cause the issue discussed here, is useful
>> on its own, and several packages depend on it.
>
> If this bug can be fixed by removing runit-init, the removal of the other
> packages isn't necessary, but please note that this would need to happen very
> soon.

fwiw, i'm willing to provide such an NMU, because i consider runit to be
a useful package.  However, it'll be done under duress, as i don't think
that the removal of runit-init is strictly necessary.

fwiw, i've run debian systems with runit as PID 1 for years, long before
there was a runit-init package, and without the runit-init package even
today.  So it's certainly possible to achieve the runit-as-pid-1
situation without the package.  But if the only issue with runit-init is
the first reboot when switching initsystems, then i don't think that
should rise to the level of an RC bug.  as written upthread, when you
switch initsystems, some level of pain is to be expected.

removing runit-init from debian just means that people switching init
systems will have *more* pain (because they'll be totally on their own
with the conversion).

anyway, if folks want this NMU in order to keep runit in debian, i'll
provide it, but i don't think it's a great idea.

--dkg


signature.asc
Description: PGP signature

Bug#863571: RFS: openldap/2.4.44+dfsg-5

[Ryan Tandy]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor to upload a security fix (remote crash) to 
openldap. The fix is targeted for stretch and the release team has 
pre-approved the unblock in #863569.


I have uploaded the source package to mentors:

https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.44+dfsg-5.dsc

Changes since the previous upload:

 * debian/patches/ITS-8644-wait-for-slapd-to-start-in-test064.patch: Fix an
   intermittently failing test by waiting for slapd to start before running
   tests. (ITS#8644) (Closes: #770890)
 * debian/patches/ITS-8655-paged-results-double-free.patch: Fix a double free
   in the MDB backend on a search including the Paged Results control with a
   page size of 0. (ITS#8655) (Closes: #863563)

Thank you,
Ryan

Bug#863565: default install of 'sudo'

[Cyril Brulebois]

Philipp Kern  (2017-05-28):
> On 28.05.2017 19:03, Geert Stappers wrote:
> > Please install 'sudo' default.
> > 
> > Explaining why it is not installed, is also fine.
> 
> Don't we install it already when the root password is unset? (I.e. I
> think then you end up with a setup where the primary user is allowed to
> sudo to root.)

Yeah; documented (even if a bit hidden) in:
  https://www.debian.org/releases/jessie/amd64/apas03.html.en


KiBi.


signature.asc
Description: Digital signature

Bug#721430: @stilor

[Geert Stappers]

> 
> : host al-ip4-mx-vip2.prodigy.net[144.160.235.144] said: 553
> 5.3.0 alph162 DNSBL:ATTRBL 521< 82.161.218.215 >_is_blocked.For assistance
> forward this email to abuse_...@abuse-att.net (in reply to MAIL FROM
> command)
>

So Stilor didn't get my e-mail.

abuse-att.net has been contacted.

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Jan Niehusmann]

Hi,

On Sun, May 28, 2017 at 07:54:33PM +0200, Ivo De Decker wrote:
> On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote:
> > May I suggest only removing runit-init from the runit source package, if
> > the bug can't be fixed in time for the stretch release?
> 
> Sure. That just needs someone to upload such an NMU very soon. I suggested
> this already at the end of message #49:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49

But who decides that this is the right way to go? Just removing a
package is not usually something which should be done with an NMU.

Especially as this bug only affects systems switching to runit. There
may be people happily running runit as their init system. Just leaving
them with an unmaintained init system doesn't seem to be a good idea,
either. In fact, that may be less user friendly than this bug. How could
we handle future security issues in that package, for example?

As runit-init is part of current stable, we need to provide some upgrade
path if we want to remove it.

BTW, according to the initial reporter, "The same procedure was required
to return to systemd as PID1." So systemd seems to be broken in the
same way. Therefore, simply replacing runit-init with a transitional
package depending on systemd wouldn't work either.

> If this bug can be fixed by removing runit-init, the removal of the other
> packages isn't necessary, but please note that this would need to happen very
> soon.

Removing runit-init from the init package may be worse than keeping it,
see above.

Of course, removing runit-init, runit and all reverse-dependencies would
be even worse, so it may be a workaround in case the release team
decides that keeping runit-init in its current form is absolutely not
acceptable.

Jan

Bug#863569: (pre-approval) unblock: openldap/2.4.44+dfsg-5

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sun, May 28, 2017 at 11:24:00AM -0700, Ryan Tandy wrote:
> I would like to upload a late-breaking security fix to openldap:
> 
>   * debian/patches/ITS-8655-paged-results-double-free.patch: Fix a double free
> in the MDB backend on a search including the Paged Results control with a
> page size of 0. (ITS#8655) (Closes: #863563)
> 
> A Debian user reported this crash bug in slapd. The default Debian 
> configuration uses the MDB backend and allows unauthenticated users to 
> search the directory; therefore for us this qualifies as a remote DoS.
> 
> With your permission, I'd like to include one additional fix:
> 
>   * ITS-8644-wait-for-slapd-to-start-in-test064.patch: Fix an intermittently
> failing test by waiting for slapd to start before running tests.
> (ITS#8644) (Closes: #770890)
> 
> This issue caused some havoc in the last upload; you may remember that 
> we ended up re-bootstrapping on ppc64el and binNMUing everywhere. The 
> root cause was actually the tight dependency between libldap-2.4-2 and 
> libldap-common, but I think revisiting that should wait for buster. For 
> now, including this patch will improve the reliability of maintenance 
> uploads during stretch's lifetime.
> 
> Both patches have already been reviewed upstream and will be included in 
> the upcoming 2.4.45 release.
> 
> Thanks again for all your work on making stretch great,

Please go ahead with the upload and remove the moreinfo tag from this bug once
the builds on all (relevant) architectures are in unstable.

Cheers,

Ivo

Bug#690763: marked as done (installation-guide: sudo and no password for root user situation)

[Holger Wansing]

Control: reopen -1


ow...@bugs.debian.org (Debian Bug Tracking System) wrote:
> Your message dated Sat, 27 May 2017 16:16:01 +0200
> with message-id <20170527161601.6274648e.bapti...@mailoo.org>
> and subject line Re: installation-guide: sudo and no password for root user 
> situation
> has caused the Debian Bug report #690763,
> regarding installation-guide: sudo and no password for root user situation
> to be marked as done.

Baptiste stated:

A similar change was introduced in r68416, so I'm closing this bug.
Thanks.



Yes, that's right.
But that mentioned commit does only add such sentence into the "Installation
Howto", which is an appendix from the "Installation guide". These both are
rarely the same manuals, but the one in a extremly short version, and the
other quite detailed. Which means, people who read the "long version", means
the main part of the installation guide, will most likely not read the
installation howto as well. So that persons will not know about the 
sudo/no-password-for-root infos.

Therefore I reopen this bug, I will add such sentence into the main part of
installation guide as well (however after the release of Stretch).


Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#863570: mb2md fails on mboxes from bugs.debian.org

[Daniel Kahn Gillmor]

Package: mb2md
Version: 3.20-8
Severity: normal

I pulled an mbox for debian bug #861536 from this URL:

 
https://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=861536;mboxmaint=yes

Then i ran mb2md on it to try to turn the mbox into a maildir.
however, it produced a single file in the maildir, rather than the
14-message thread it should have created.

I wrote the following python3 program to extract the messages instead:

---
#/usr/bin/python3
import mailbox
import sys
mbox = mailbox.mbox(sys.argv[1])
mdir = mailbox.Maildir(sys.argv[2])
for x in mbox:
mdir.add(x)
---

and this python program extracted the 14 messages as expected.

I have not dug any deeper into mb2md to figure out why it is
misbehaving.

--dkg


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

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

Versions of packages mb2md depends on:
ii  libtimedate-perl  2.3000-2
ii  perl  5.24.1-2

mb2md recommends no packages.

mb2md suggests no packages.

-- no debconf information

Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs

[Nicholas D Steeves]

Hi Sean,

On Tue, May 23, 2017 at 08:22:19PM +0100, Sean Whitton wrote:
> 
> While upstream's git repo is called 'swiper', it's clear that the
> overarching project has been renamed to 'ivy' -- see the releases
> page.[1]
> 
> Filing this RFP and immediately converting to an ITP for Nicholas, who
> is busy IRL but has 90% of the packaging in hand.
> 
> [1]  https://github.com/abo-abo/swiper/releases

Thank you for filing this on my behalf :-)  I've pushed a preliminary
package to ssh://git.debian.org/git/pkg-emacsen/pkg/emacs-ivy.git

Unfortunately one test fails:
...
Running 16 tests (2017-05-28 13:30:14-0400)
Test colir-color-parse backtrace:
  (let ((fn-220 (function equal)) (args-221 (list (colir-color-parse "
  (lambda nil (let ((fn-220 (function equal)) (args-221 (list (colir-c
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test colir-color-parse nil (lambda nil (
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test c
  ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  eval((ert-run-tests-batch-and-exit))
  command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
  command-line()
  normal-top-level()
Test colir-color-parse condition:
(void-function colir-color-parse)
   FAILED   1/16  colir-color-parse
...
dh_elpa_test: emacs -batch -Q -l package --eval (add-to-list
'package-directory-list "/usr/share/emacs/site-lisp/elpa") --eval
(add-to-list 'package-directory-list
"/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -L . -l
ivy-test.el --eval (ert-run-tests-batch-and-exit) returned exit code 1
debian/rules:4: recipe for target 'build' failed make: *** [build]
Error 2 dpkg-buildpackage: error: debian/rules build gave error exit
status 2

The test in question is around L210 of ivy-test.el.  If I manually
load-file colir.el and eval-expression (colir-color-parse "#ab1234")
with emacs25, it returns the correct triplet as a list, so I'm not
sure where the problem is or how to proceed.  Commenting out
autopkgtest-pkg-elpa in d/control doesn't seem to help.  Any advice
for debugging this with greater verbosity, since my
ignorance/inexperience is preventing further progress on this ITP?
Not installing ivy-test.el seems sloppy...

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#863569: (pre-approval) unblock: openldap/2.4.44+dfsg-5

[Ryan Tandy]

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

Dear release team,

I would like to upload a late-breaking security fix to openldap:

  * debian/patches/ITS-8655-paged-results-double-free.patch: Fix a double free
in the MDB backend on a search including the Paged Results control with a
page size of 0. (ITS#8655) (Closes: #863563)

A Debian user reported this crash bug in slapd. The default Debian 
configuration uses the MDB backend and allows unauthenticated users to 
search the directory; therefore for us this qualifies as a remote DoS.

With your permission, I'd like to include one additional fix:

  * ITS-8644-wait-for-slapd-to-start-in-test064.patch: Fix an intermittently
failing test by waiting for slapd to start before running tests.
(ITS#8644) (Closes: #770890)

This issue caused some havoc in the last upload; you may remember that 
we ended up re-bootstrapping on ppc64el and binNMUing everywhere. The 
root cause was actually the tight dependency between libldap-2.4-2 and 
libldap-common, but I think revisiting that should wait for buster. For 
now, including this patch will improve the reliability of maintenance 
uploads during stretch's lifetime.

Both patches have already been reviewed upstream and will be included in 
the upcoming 2.4.45 release.

Thanks again for all your work on making stretch great,

Ryan

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

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru openldap-2.4.44+dfsg/debian/changelog openldap-2.4.44+dfsg/debian/changelog
--- openldap-2.4.44+dfsg/debian/changelog	2017-04-16 20:10:43.0 -0700
+++ openldap-2.4.44+dfsg/debian/changelog	2017-05-28 09:59:48.0 -0700
@@ -1,3 +1,14 @@
+openldap (2.4.44+dfsg-5) unstable; urgency=medium
+
+  * ITS-8644-wait-for-slapd-to-start-in-test064.patch: Fix an intermittently 
+failing test by waiting for slapd to start before running tests.
+(ITS#8644) (Closes: #770890)
+  * debian/patches/ITS-8655-paged-results-double-free.patch: Fix a double free 
+in the MDB backend on a search including the Paged Results control with a 
+page size of 0. (ITS#8655) (Closes: #863563)
+
+ -- Ryan Tandy   Sun, 28 May 2017 09:59:46 -0700
+
 openldap (2.4.44+dfsg-4) unstable; urgency=medium
 
   * Improve the slapd/ppolicy_schema_needs_update debconf template. Thanks to 
diff -Nru openldap-2.4.44+dfsg/debian/patches/ITS-8644-wait-for-slapd-to-start-in-test064.patch openldap-2.4.44+dfsg/debian/patches/ITS-8644-wait-for-slapd-to-start-in-test064.patch
--- openldap-2.4.44+dfsg/debian/patches/ITS-8644-wait-for-slapd-to-start-in-test064.patch	1969-12-31 16:00:00.0 -0800
+++ openldap-2.4.44+dfsg/debian/patches/ITS-8644-wait-for-slapd-to-start-in-test064.patch	2017-05-28 09:57:44.0 -0700
@@ -0,0 +1,40 @@
+From b622163ecf14a179d932f779164af5e393311dd8 Mon Sep 17 00:00:00 2001
+From: Ryan Tandy 
+Date: Tue, 25 Apr 2017 01:28:25 +
+Subject: [PATCH] ITS#8644 wait for slapd to start in test064
+
+---
+ tests/scripts/test064-constraint | 17 +
+ 1 file changed, 17 insertions(+)
+
+diff --git a/tests/scripts/test064-constraint b/tests/scripts/test064-constraint
+index 94f86be..2ac53ac 100755
+--- a/tests/scripts/test064-constraint
 b/tests/scripts/test064-constraint
+@@ -117,6 +117,23 @@ if test $WAIT != 0 ; then
+ fi
+ sleep 1
+ 
++echo "Using ldapsearch to check that slapd is running..."
++for i in 0 1 2 3 4 5; do
++	$LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT1 \
++		'objectclass=*' > /dev/null 2>&1
++	RC=$?
++	if test $RC = 0 ; then
++		break
++	fi
++	echo "Waiting 5 seconds for slapd to start..."
++	sleep 5
++done
++if test $RC != 0 ; then
++	echo "ldapsearch failed ($RC)!"
++	test $KILLSERVERS != no && kill -HUP $KILLPIDS
++	exit $RC
++fi
++
+ echo "Adding basic structure..."
+ $LDAPADD -D "$MANAGERDN" -H $URI1 -w $PASSWD -f $ROOTLDIF &>/dev/null
+ RC=$?
+-- 
+2.1.4
+
diff -Nru openldap-2.4.44+dfsg/debian/patches/ITS-8655-paged-results-double-free.patch openldap-2.4.44+dfsg/debian/patches/ITS-8655-paged-results-double-free.patch
--- openldap-2.4.44+dfsg/debian/patches/ITS-8655-paged-results-double-free.patch	1969-12-31 16:00:00.0 -0800
+++ openldap-2.4.44+dfsg/debian/patches/ITS-8655-paged-results-double-free.patch	2017-05-28 09:58:07.0 -0700
@@ -0,0 +1,28 @@
+From 0cee1ffb6021b1aae3fcc9581699da1c85a6dd6e Mon Sep 17 00:00:00 2001
+From: Ryan Tandy 
+Date: Wed, 17 May 2017 20:07:39 -0700
+Subject: [PATCH] ITS#8655 fix double free on paged search with pagesize 0
+
+Fixes a double free when a search includes the Paged Results control
+with a page size of

Bug#548853: module-init-tools: depmod.conf manpage corruption

[Chris Lamb]

Version: 1:2.0.0-36

Hi,

> module-init-tools: depmod.conf manpage corruption

This was fixed in 1:2.0.0-36:

  * Prevent undefined behaviour in memcpy parameter overlap; docbook-to-man
can insert random characters into the output. e.g. it will sometimes
generate an "I" instead of a literal tab. Thanks to Chris West
 and Yuri Gribov 
(Closes: #842635, #858389)


Regards,

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

Bug#863568: cfengine3: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: cfengine3
Version: 3.9.1-4.2
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#852293: kde-l10n-de: Version to old missing translations

[Andrej Mernik]

Package: kde-l10n-sl
Version: 4:16.04.3-1
Followup-For: Bug #852293

Dear Maintainers,

we have less than three weeks before Stretch release and this bug is still not
fixed. The translations were pulled at start of July 2016, the applications
(for example) were pulled months later.

It might not seem a big deal, but some KDE translation teams do majority of
work a few weeks before major releases and backport anything left (or fixes)
after the release. This means Stretch will ship with incomplete translations or
translations containing string bugs already fixed in upstream.

Please consider updating the translations.

Thanks and best regards,
Andrej Mernik



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

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

Versions of packages kde-l10n-sl depends on:
ii  libkdecore5  4:4.14.26-2
ii  libkf5i18n5  5.28.0-2

kde-l10n-sl recommends no packages.

Versions of packages kde-l10n-sl suggests:
ii  kde-standard  5:92

-- no debconf information

Bug#863565: default install of 'sudo'

[Philipp Kern]

On 28.05.2017 19:03, Geert Stappers wrote:
> Please install 'sudo' default.
> 
> Explaining why it is not installed, is also fine.

Don't we install it already when the root password is unset? (I.e. I
think then you end up with a setup where the primary user is allowed to
sudo to root.)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Ivo De Decker]

Hi,

On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote:
> May I suggest only removing runit-init from the runit source package, if
> the bug can't be fixed in time for the stretch release?

Sure. That just needs someone to upload such an NMU very soon. I suggested
this already at the end of message #49:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49

> Because runit itself doesn't cause the issue discussed here, is useful
> on its own, and several packages depend on it.

If this bug can be fixed by removing runit-init, the removal of the other
packages isn't necessary, but please note that this would need to happen very
soon.

Cheers,

Ivo

Bug#863567: rmail: unable to install because of unmet dependency

[s3v]

Package: rmail
Severity: normal


rmail is currently uninstallable on Stretch:

# apt-get -o Debug::pkgProblemResolver=1 install rmail
Reading package lists... Done
Building dependency tree
Reading state information... Done
Starting pkgProblemResolver with broken count: 2
Starting 2 pkgProblemResolver with broken count: 2
Investigating (0) rmail:amd64 < none -> 8.15.2-8 @un puN Ib >
Broken rmail:amd64 Depends on sendmail-bin:amd64 < none | 8.15.2-8 @un uH >
  Considering sendmail-bin:amd64 0 as a solution to rmail:amd64 9998
  Re-Instated liblockfile-bin:amd64
  Re-Instated liblockfile1:amd64
  Re-Instated lockfile-progs:amd64
  Re-Instated sendmail-base:amd64
  Re-Instated sendmail-cf:amd64
  Re-Instated sendmail-bin:amd64
Investigating (0) exim4:amd64 < 4.89-2 @ii mK Ib >
Broken exim4:amd64 Depends on exim4-daemon-light:amd64 < 4.89-2 @ii mR >
  Considering exim4-daemon-light:amd64 0 as a solution to exim4:amd64 7
  Added exim4-daemon-light:amd64 to the remove list
Broken exim4:amd64 Depends on exim4-daemon-heavy:amd64 < none | 4.89-2 @un uH >
  Considering exim4-daemon-heavy:amd64 0 as a solution to exim4:amd64 7
  Try Installing exim4-daemon-heavy:amd64 < none | 4.89-2 @un uH > before 
changing
exim4:amd64
  Fixing exim4:amd64 via keep of exim4-daemon-light:amd64
Investigating (0) exim4-daemon-heavy:amd64 < none -> 4.89-2 @un uN Ib >
Broken exim4-daemon-heavy:amd64 Conflicts on mail-transport-agent:amd64 < none 
@un H >
  Conflicts//Breaks against version 2.64-8+b2 for ssmtp but that is not InstVer,
ignoring
  Conflicts//Breaks against version 8.15.2-8 for sendmail-bin but that is not
InstVer, ignoring
  Conflicts//Breaks against version 2.0.2+nmu1 for qmail-run but that is not
InstVer, ignoring
  Conflicts//Breaks against version 3.1.4-7 for postfix but that is not InstVer,
ignoring
  Conflicts//Breaks against version 6.0.2p1-2 for opensmtpd but that is not 
InstVer,
ignoring
  Conflicts//Breaks against version 1:1.13-1.2 for nullmailer but that is not
InstVer, ignoring
  Conflicts//Breaks against version 1.6.6-1 for msmtp-mta but that is not 
InstVer,
ignoring
  Considering exim4-daemon-light:amd64 0 as a solution to 
exim4-daemon-heavy:amd64 0
  Holding Back exim4-daemon-heavy:amd64 rather than change 
mail-transport-agent:amd64
Investigating (1) rmail:amd64 < none -> 8.15.2-8 @un puN Ib >
Broken rmail:amd64 Conflicts on exim4-daemon-light:amd64 < 4.89-2 @ii mK >
  Considering exim4-daemon-light:amd64 0 as a solution to rmail:amd64 9998
  Added exim4-daemon-light:amd64 to the remove list
  Fixing rmail:amd64 via remove of exim4-daemon-light:amd64
Investigating (1) exim4:amd64 < 4.89-2 @ii mK Ib >
Broken exim4:amd64 Depends on exim4-daemon-light:amd64 < 4.89-2 @ii mR >
  Considering exim4-daemon-light:amd64 0 as a solution to exim4:amd64 7
  Added exim4-daemon-light:amd64 to the remove list
Broken exim4:amd64 Depends on exim4-daemon-heavy:amd64 < none | 4.89-2 @un uH >
  Considering exim4-daemon-heavy:amd64 0 as a solution to exim4:amd64 7
  Try Installing exim4-daemon-heavy:amd64 < none | 4.89-2 @un uH > before 
changing
exim4:amd64
  Fixing exim4:amd64 via keep of exim4-daemon-light:amd64
Investigating (1) exim4-daemon-heavy:amd64 < none -> 4.89-2 @un uN Ib >
Broken exim4-daemon-heavy:amd64 Conflicts on mail-transport-agent:amd64 < none 
@un H >
  Conflicts//Breaks against version 2.64-8+b2 for ssmtp but that is not InstVer,
ignoring
  Conflicts//Breaks against version 8.15.2-8 for sendmail-bin but that is not
InstVer, ignoring
  Conflicts//Breaks against version 2.0.2+nmu1 for qmail-run but that is not
InstVer, ignoring
  Conflicts//Breaks against version 3.1.4-7 for postfix but that is not InstVer,
ignoring
  Conflicts//Breaks against version 6.0.2p1-2 for opensmtpd but that is not 
InstVer,
ignoring
  Conflicts//Breaks against version 1:1.13-1.2 for nullmailer but that is not
InstVer, ignoring
  Conflicts//Breaks against version 1.6.6-1 for msmtp-mta but that is not 
InstVer,
ignoring
  Considering exim4-daemon-light:amd64 0 as a solution to 
exim4-daemon-heavy:amd64 0
  Holding Back exim4-daemon-heavy:amd64 rather than change 
mail-transport-agent:amd64
Investigating (2) rmail:amd64 < none -> 8.15.2-8 @un puN Ib >
Broken rmail:amd64 Conflicts on exim4-daemon-light:amd64 < 4.89-2 @ii mK >
  Considering exim4-daemon-light:amd64 0 as a solution to rmail:amd64 9998
  Added exim4-daemon-light:amd64 to the remove list
  Fixing rmail:amd64 via remove of exim4-daemon-light:amd64
Investigating (2) exim4:amd64 < 4.89-2 @ii mK Ib >
Broken exim4:amd64 Depends on exim4-daemon-light:amd64 < 4.89-2 @ii mR >
  Considering exim4-daemon-light:amd64 9998 as a solution to exim4:amd64 7
Broken exim4:amd64 Depends on exim4-daemon-heavy:amd64 < none | 4.89-2 @un uH >
  Considering exim4-daemon-heavy:amd64 0 as a solution to exim4:amd64 7
  Try Installing exim4-daemon-heavy:amd64 < none | 4.89-2 @un uH > before 
changing
exim4:amd64
Investigating (3) rmail:amd64 < none -> 8.15.2-8 @un puN Ib >
Broken rmail:amd64 Confl

Bug#863566: libgraphicsmagick1-dev: Linking different versions of libjpeg (62 and 8) causes failure to load JPEG files

[Henner Zeller]

Package: libgraphicsmagick1-dev
Version: 1.3.20-3+rpi1
Severity: important

Dear Maintainer,

When linking anything against this package, the linker complains that

/usr/bin/ld: warning: libjpeg.so.8, needed by /usr/lib/libGraphicsMagick.so, 
may conflict with libjpeg.so.62


and indeed, the library is linked against both libjpeg library versions:

$ ldd /usr/lib/libGraphicsMagick.so | grep jpeg
libjpeg.so.8 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.8 (0x76a0f000)
libjpeg.so.62 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 (0x7644f000)

In practice this means, that it actually fails to load JPG pictures right now 
using
that library, possibly because symbols are getting confused.

I suspect that two different image sub-libraries use different dependencies so 
we end
up with this incompatible mix.


[
Context in which this was discovered: my image viewer for LED panels connected
to the Raspberry Pi ceased to work for JPEG
https://github.com/hzeller/rpi-rgb-led-matrix/tree/master/utils#image-viewer
]

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.4.34-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgraphicsmagick1-dev depends on:
ii  libbz2-dev 1.0.6-7
ii  libc6-dev  2.19-18+deb8u9
ii  libexif-dev0.6.21-2
ii  libfreetype6-dev   2.6-2rpi1rpi1g
ii  libgraphicsmagick3 1.3.20-3+rpi1
ii  libice-dev 2:1.0.9-1
ii  libjasper-dev  1.900.1-debian1-2.4+deb8u3
ii  libjbig-dev2.1-3.1
ii  libjpeg-dev1:1.3.1-12
ii  libjpeg62-turbo-dev [libjpeg-dev]  1:1.3.1-12
ii  liblcms2-dev   2.6-3+deb8u1
ii  libltdl-dev2.4.2-1.11
ii  libpng12-dev [libpng-dev]  1.2.50-2+deb8u3
ii  libsm-dev  2:1.2.2-1
ii  libtiff5-dev [libtiff-dev] 4.0.3-12.3+deb8u3
ii  libwmf-dev 0.2.8.4-10.3+deb8u2
ii  libx11-dev 2:1.6.2-3
ii  libxext-dev2:1.3.3-1
ii  libxml2-dev2.9.1+dfsg1-5+deb8u4
ii  x11proto-core-dev  7.0.31-1
ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-2

libgraphicsmagick1-dev recommends no packages.

Versions of packages libgraphicsmagick1-dev suggests:
pn  graphicsmagick  

-- debconf information excluded

Bug#863565: default install of 'sudo'

[Geert Stappers]

Package: debian-installer
Severity: wishlist


Please install 'sudo' default.

Explaining why it is not installed, is also fine.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#863186: [ftpmas...@ftp-master.debian.org: Processing of dcut._ametzler_debian_org_.1495989962.26313.commands]

[Andreas Metzler]

- Forwarded message from Debian FTP Masters 
 -
Date: Sun, 28 May 2017 16:59:01 +
From: Debian FTP Masters 
To: ametz...@debian.org
Subject: Processing of dcut._ametzler_debian_org_.1495989962.26313.commands
Message-Id: 

Log of processing your commands file 
/dcut._ametzler_debian_org_.1495989962.26313.commands:

> reschedule libtasn1-6_4.10-1.1_allonly.changes 0-day
libtasn1-6_4.10-1.1_allonly.changes moved to 0-day
libtasn1-6_4.10-1.1.dsc moved to 0-day
libtasn1-6_4.10-1.1.debian.tar.xz moved to 0-day
libtasn1-3-bin_4.10-1.1_all.deb moved to 0-day
libtasn1-doc_4.10-1.1_all.deb moved to 0-day

Greetings,

Your Debian queue daemon (running on host usper.debian.org)
- End forwarded message -

Bug#863564: libgraphicsmagick++1-dev: Missing dependency on required libwebp-dev

[Henner Zeller]

Package: libgraphicsmagick++1-dev
Version: 1.3.25-8
Severity: important

Dear Maintainer,

After the package is installed,

$ GraphicsMagick++-config --ldflags --libs

mentions -lwebp as its dependencies.

However, it is not automatically installed as part of the dependencies,
making compilations that link the library in this package fail:
  /usr/bin/ld: cannot find -lwebp

This can be fixed manually by installing libwebp-dev.

Somewhere down the dependency chain of the libgraphicsmagick++* packages, the
dependency on libwebp-dev is missing and needs to be added.

This was observed in Jessie and Stretch.

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

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

Versions of packages libgraphicsmagick++1-dev depends on:
ii  libgraphicsmagick++-q16-12  1.3.25-8
ii  libgraphicsmagick1-dev  1.3.25-8

libgraphicsmagick++1-dev recommends no packages.

Versions of packages libgraphicsmagick++1-dev suggests:
pn  graphicsmagick  

-- no debconf information

Bug#863186: libtasn1-6: diff for NMU version 4.10-1.1

[Andreas Metzler]

On 2017-05-25 Salvatore Bonaccorso  wrote:
> Control: tags 863186 + pending

> Dear maintainer,

> I've prepared an NMU for libtasn1-6 (versioned as 4.10-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer (or reschedule to earlier, or cancel if you
> would like to do an upload on your own).
[...]

Thank you, rescheduled to 0-day.

cu Andreas


signature.asc
Description: PGP signature

Bug#863563: double free with Paged Results control and pagesize 0

[Ryan Tandy]

Package: slapd
Version: 2.4.44+dfsg-4
Severity: important
Tags: security fixed-upstream
Control: forwarded -1 http://www.openldap.org/its/?findid=8655
Control: found -1 2.4.40+dfsg-1+deb8u2
Control: found -1 2.4.31-2+deb7u2

Karsten Heymann discovered that a user with access to search the 
directory can crash slapd by issuing a search including the Paged 
Results control with a page size of 0. Opening a bug for tracking in 
Debian now that the ITS is public.

Bug#859227: mixmaster: ssl 1.1 support

[solo-debianbugs]

Control: tags -1 + patch

The attached patch moves the code over to using the openssl 1.1 api. It
is entirely renames / accessors.

Chris.

diff --git a/mixmaster-3.0.0/Src/crypto.c b/mixmaster-3.0.0/Src/crypto.c
index 1025b6d..e860a67 100644
--- a/mixmaster-3.0.0/Src/crypto.c
+++ b/mixmaster-3.0.0/Src/crypto.c
@@ -82,6 +82,7 @@ static int read_seckey(BUFFER *buf, SECKEY *key, const byte id[])
   int len, plen;
   byte *ptr;
   int err = 0;
+  BIGNUM *key_n, *key_e, *key_d, *key_p, *key_q, *key_dmp1, *key_dmq1, *key_iqmp;
 
   md = buf_new();
   bits = buf->data[0] + 256 * buf->data[1];
@@ -94,32 +95,36 @@ static int read_seckey(BUFFER *buf, SECKEY *key, const byte id[])
 
   ptr = buf->data + 2;
 
-  key->n = BN_bin2bn(ptr, len, NULL);
+  key_n = BN_bin2bn(ptr, len, NULL);
   buf_append(md, ptr, len);
   ptr += len;
 
-  key->e = BN_bin2bn(ptr, len, NULL);
+  key_e = BN_bin2bn(ptr, len, NULL);
   buf_append(md, ptr, len);
   ptr += len;
 
-  key->d = BN_bin2bn(ptr, len, NULL);
+  key_d = BN_bin2bn(ptr, len, NULL);
   ptr += len;
 
-  key->p = BN_bin2bn(ptr, plen, NULL);
+  key_p = BN_bin2bn(ptr, plen, NULL);
   ptr += plen;
 
-  key->q = BN_bin2bn(ptr, plen, NULL);
+  key_q = BN_bin2bn(ptr, plen, NULL);
   ptr += plen;
 
-  key->dmp1 = BN_bin2bn(ptr, plen, NULL);
+  key_dmp1 = BN_bin2bn(ptr, plen, NULL);
   ptr += plen;
 
-  key->dmq1 = BN_bin2bn(ptr, plen, NULL);
+  key_dmq1 = BN_bin2bn(ptr, plen, NULL);
   ptr += plen;
 
-  key->iqmp = BN_bin2bn(ptr, plen, NULL);
+  key_iqmp = BN_bin2bn(ptr, plen, NULL);
   ptr += plen;
 
+  RSA_set0_key(key, key_n, key_e, key_d);
+  RSA_set0_factors(key, key_p, key_q);
+  RSA_set0_crt_params(key, key_dmp1, key_dmq1, key_iqmp);
+
   digest_md5(md, md);
   if (id)
 err = (memcmp(id, md->data, 16) == 0) ? 0 : -1;
@@ -134,6 +139,7 @@ static int read_pubkey(BUFFER *buf, PUBKEY *key, const byte id[])
   int len;
   byte *ptr;
   int err = 0;
+  BIGNUM *key_n, *key_e;
 
   md = buf_new();
   bits = buf->data[0] + 256 * buf->data[1];
@@ -144,13 +150,14 @@ static int read_pubkey(BUFFER *buf, PUBKEY *key, const byte id[])
 
   ptr = buf->data + 2;
 
-  key->n = BN_bin2bn(ptr, len, NULL);
+  key_n = BN_bin2bn(ptr, len, NULL);
   buf_append(md, ptr, len);
   ptr += len;
 
-  key->e = BN_bin2bn(ptr, len, NULL);
+  key_e = BN_bin2bn(ptr, len, NULL);
   buf_append(md, ptr, len);
   ptr += len;
+  RSA_set0_key(key, key_n, key_e, NULL);
 
   digest_md5(md, md);
   if (id)
@@ -164,17 +171,22 @@ static int write_seckey(BUFFER *sk, SECKEY *key, byte keyid[])
   byte l[128];
   int n;
   BUFFER *b, *temp;
+  const BIGNUM *key_n, *key_e, *key_d, *key_p, *key_q, *key_dmp1, *key_dmq1, *key_iqmp;
+
+  RSA_get0_key(key, &key_n, &key_e, &key_d);
+  RSA_get0_factors(key, &key_p, &key_q);
+  RSA_get0_crt_params(key, &key_dmp1, &key_dmq1, &key_iqmp);
 
   b = buf_new();
   temp = buf_new();
 
-  n = BN_bn2bin(key->n, l);
+  n = BN_bn2bin(key_n, l);
   assert(n <= 128);
   if (n < 128)
 buf_appendzero(b, 128 - n);
   buf_append(b, l, n);
 
-  n = BN_bn2bin(key->e, l);
+  n = BN_bn2bin(key_e, l);
   assert(n <= 128);
   if (n < 128)
 buf_appendzero(b, 128 - n);
@@ -187,37 +199,37 @@ static int write_seckey(BUFFER *sk, SECKEY *key, byte keyid[])
   buf_appendc(sk, 4);
   buf_cat(sk, b);
 
-  n = BN_bn2bin(key->d, l);
+  n = BN_bn2bin(key_d, l);
   assert(n <= 128);
   if (n < 128)
 buf_appendzero(sk, 128 - n);
   buf_append(sk, l, n);
 
-  n = BN_bn2bin(key->p, l);
+  n = BN_bn2bin(key_p, l);
   assert(n <= 64);
   if (n < 64)
 buf_appendzero(sk, 64 - n);
   buf_append(sk, l, n);
 
-  n = BN_bn2bin(key->q, l);
+  n = BN_bn2bin(key_q, l);
   assert(n <= 64);
   if (n < 64)
 buf_appendzero(sk, 64 - n);
   buf_append(sk, l, n);
 
-  n = BN_bn2bin(key->dmp1, l);
+  n = BN_bn2bin(key_dmp1, l);
   assert(n <= 64);
   if (n < 64)
 buf_appendzero(sk, 64 - n);
   buf_append(sk, l, n);
 
-  n = BN_bn2bin(key->dmq1, l);
+  n = BN_bn2bin(key_dmq1, l);
   assert(n <= 64);
   if (n < 64)
 buf_appendzero(sk, 64 - n);
   buf_append(sk, l, n);
 
-  n = BN_bn2bin(key->iqmp, l);
+  n = BN_bn2bin(key_iqmp, l);
   assert(n <= 64);
   if (n < 64)
 buf_appendzero(sk, 64 - n);
@@ -234,15 +246,17 @@ static int write_pubkey(BUFFER *pk, PUBKEY *key, byte keyid[])
 {
   byte l[128];
   int n;
+  const BIGNUM *key_n, *key_e, *key_d;
 
   buf_appendc(pk, 0);
   buf_appendc(pk, 4);
-  n = BN_bn2bin(key->n, l);
+  RSA_get0_key(key, &key_n, &key_e, &key_d);
+  n = BN_bn2bin(key_n, l);
   assert(n <= 128);
   if (n < 128)
 buf_appendzero(pk, 128 - n);
   buf_append(pk, l, n);
-  n = BN_bn2bin(key->e, l);
+  n = BN_bn2bin(key_e, l);
   assert(n <= 128);
   if (n < 128)
 buf_appendzero(pk, 128 - n);
@@ -383,23 +397,23 @@ int pk_encrypt(BUFFER *in, BUFFER *keybuf)
 }
 int buf_crypt(BUFFER *buf, BUFFER *key, BUFFER *iv, int enc)
 {
-  des_key_schedule ks1;
-  des_key_schedule ks2;
-  des_key_schedule ks3;
-  des_cblock i;
+  DES_key_schedule *ks1;
+  DES_key_schedule *ks2;
+  DES_key_schedule *k

Bug#863562: jessie-pu: package libonig/5.9.5-3.2

[Jörg Frings-Fürst]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have the release 5.9.5-3.2+deb8u1 with fixes for the CVE's:

 CVE-2017-9224
 CVE-2017-9226
 CVE-2017-9227
 CVE-2017-9228
 CVE-2017-9229

ready, The debdiff is attached.


- -- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlkq/Q4ACgkQCfifPIyh
0l3LkQ//UY/XbO0adWiAPyombGW3e+lSRikPyn+cZfroCGgkkp7W1ch+xqiB+TyT
CU8sBMqiRGFEm9OY0gCljmaalZ1/Hoi7TGdTuo56pfu7/g/TPn8IUYef5NPGySRb
/8+RUF1hFIBRWeHHwnhJ6mJ3f00FnzQK9i0j05Oew/upgzQpL+uaJv8Dzu+swgqI
L+qlORuMN9V1sFkMwBMSaRmkLUkDw7C0LUYy21seb9ONmiCW+a3/7a/NuRYOE/S9
T2Kkn5moykCd87eW36DRoak7pFAbIdXMbzhAiQB2gd4cJRbpiN30TIX3YOMbnRPL
2S3jPrmsSIpbGYsfnn6ZkjfavwW9fwfjTUehrn6jX2bKwuwdRxIt5z57V1uuex9N
MpBQWL8jKfMMscfz3YzOJPdz0XicVYAHBN0zswapHtZDfnlOwNoj3I6iPng0QEGj
vQ2zD/P0wSoD8JeMfotOKeHaCXoWcQxmJmacGPS2BnA03OvKlSC7HGNyLnOu7Dws
ye8oCglZNpLmF/1cr7nvrHSnpiPc4MvyYxnFDSTFvB15ugsgoMaNdf2gvEXiUHNo
R+ZY2wCil3R4IKvpvKGYqpReNKOACjc+EhNU5KzrWvA39jdvJmkGZTc9IqV8E+Z+
q2q4ponTuPY47s2iB5SGBHIo5bpuhdwqREsB6VsCWyWde9gDm6A=
=aAPj
-END PGP SIGNATURE-
diff -Nru libonig-5.9.5/debian/changelog libonig-5.9.5/debian/changelog
--- libonig-5.9.5/debian/changelog  2014-12-28 12:11:12.0 +0100
+++ libonig-5.9.5/debian/changelog  2017-05-28 16:59:55.0 +0200
@@ -1,3 +1,15 @@
+libonig (5.9.5-3.2+deb8u1) stable; urgency=medium
+
+  * New debian/patches/0500-CVE-2017-922[4-9].patch:
+- Cherrypicked from upstream to correct:
+  + CVE-2017-9224 (Closes: #863312)
+  + CVE-2017-9226 (Closes: #863314)
+  + CVE-2017-9227 (Closes: #863315)
+  + CVE-2017-9228 (Closes: #863316)
+  + CVE-2017-9229 (Closes: #863318)
+
+ -- Jörg Frings-Fürst   Sun, 28 May 2017 16:59:55 
+0200
+
 libonig (5.9.5-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libonig-5.9.5/debian/patches/0500-CVE-2017-922[4-9].patch 
libonig-5.9.5/debian/patches/0500-CVE-2017-922[4-9].patch
--- libonig-5.9.5/debian/patches/0500-CVE-2017-922[4-9].patch   1970-01-01 
01:00:00.0 +0100
+++ libonig-5.9.5/debian/patches/0500-CVE-2017-922[4-9].patch   2017-05-26 
07:07:41.0 +0200
@@ -0,0 +1,121 @@
+Correct CVE-2017-922[4-9]
+ Fix mutilple invalid pointer dereference, out-of-bounds write memory 
+ corruption and stack buffer overflow,
+Origin: Cheerypicked from upstream
+Bug: https://github.com/kkos/oniguruma/issues/[55|56|57|58|59|60]
+Bug-Debian: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=86331[2|3|4|5|6|8]
+Forwarded: not-needed
+Last-Update: 2017-05-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: 5.9.5-3.2-deb8u1/regexec.c
+===
+--- 5.9.5-3.2-deb8u1.orig/regexec.c
 5.9.5-3.2-deb8u1/regexec.c
+@@ -1425,14 +1425,9 @@ match_at(regex_t* reg, const UChar* str,
+   break;
+ 
+ case OP_EXACT1:  MOP_IN(OP_EXACT1);
+-#if 0
+   DATA_ENSURE(1);
+   if (*p != *s) goto fail;
+   p++; s++;
+-#endif
+-  if (*p != *s++) goto fail;
+-  DATA_ENSURE(0);
+-  p++;
+   MOP_OUT;
+   break;
+ 
+@@ -3128,6 +3123,8 @@ forward_search_range(regex_t* reg, const
+ }
+ else {
+   UChar *q = p + reg->dmin;
++
++  if (q >= end) return 0; /* fail */
+   while (p < q) p += enclen(reg->enc, p);
+ }
+   }
+@@ -3207,18 +3204,25 @@ forward_search_range(regex_t* reg, const
+ }
+ else {
+   if (reg->dmax != ONIG_INFINITE_DISTANCE) {
+-  *low = p - reg->dmax;
+-  if (*low > s) {
+-*low = onigenc_get_right_adjust_char_head_with_prev(reg->enc, s,
+-*low, (const 
UChar** )low_prev);
+-if (low_prev && IS_NULL(*low_prev))
+-  *low_prev = onigenc_get_prev_char_head(reg->enc,
+- (pprev ? pprev : s), *low);
++if (p - str < reg->dmax) {
++  *low = (UChar* )str;
++  if (low_prev)
++*low_prev = onigenc_get_prev_char_head(reg->enc, str, *low);
+   }
+   else {
+-if (low_prev)
+-  *low_prev = onigenc_get_prev_char_head(reg->enc,
+- (pprev ? pprev : str), *low);
++  *low = p - reg->dmax;
++  if (*low > s) {
++*low = onigenc_get_right_adjust_char_head_with_prev(reg->enc, s,
++ *low, (const UChar** 
)low_prev);
++if (low_prev && IS_NULL(*low_prev))
++  *low_prev = onigenc_get_prev_char_head(reg->enc,
++

Bug#863561: network-manager: won't connect after gnome-keyring-dialog

[user2304]

Package: network-manager
Version: 1.6.2-3
Severity: normal

Dear Maintainer,

i got a problem using networkmanager together with gnome-keyring.

* What led up to the situation?

- Trying to connect to wifi using the networkmanager-applet while gnome-keyring 
is still closed (e.g. after booting) triggers the "Unlock keyring"-Dialog.
- After entering the PW, the keyring is opened
- Networkmanager fails to connect, see following output of syslog

- A second attempt while keyring is still opened is successful.

* Expected behaviour

- Connection at the first attempt.

* Out of syslog of first connection attempt

May 28 17:34:07 system NetworkManager[514]:   [1495985647.5780] manager: 
NetworkManager state is now CONNECTING
May 28 17:34:07 system NetworkManager[514]:   [1495985647.5796] device 
(wlx98ded019dc08): state change: prepare -> config (reason 'none') [40 50 0]
May 28 17:34:07 system NetworkManager[514]:   [1495985647.5812] device 
(wlx98ded019dc08): Activation: (wifi) access point 'Home.Wireless.Internet' has 
security, but secrets are required.
May 28 17:34:07 system NetworkManager[514]:   [1495985647.5813] device 
(wlx98ded019dc08): state change: config -> need-auth (reason 'none') [50 60 0]
May 28 17:34:07 system dbus-daemon[698]: Activating service 
name='org.freedesktop.secrets'
May 28 17:34:07 system NetworkManager[514]:   [1495985647.6020] device 
(wlx98ded019dc08): supplicant interface state: disabled -> inactive
May 28 17:34:07 system gnome-keyring-d[1254]: couldn't access control socket: 
/run/user/1000/keyring/control: No such file or directory
May 28 17:34:07 system dbus-daemon[698]: Successfully activated service 
'org.freedesktop.secrets'
May 28 17:34:07 system dbus-daemon[698]: Activating service 
name='org.gnome.keyring.SystemPrompter'
May 28 17:34:07 system dbus-daemon[698]: Successfully activated service 
'org.gnome.keyring.SystemPrompter'
May 28 17:34:07 system gcr-prompter[1261]: GtkDialog mapped without a 
transient parent. This is discouraged.
May 28 17:34:11 system NetworkManager[514]:   [1495985651.4604] device 
(wlx98ded019dc08): No agents were available for this request.
May 28 17:34:11 system NetworkManager[514]:   [1495985651.4604] device 
(wlx98ded019dc08): state change: need-auth -> failed (reason 'no-secrets') [60 
120 7]
May 28 17:34:11 system NetworkManager[514]:   [1495985651.4606] manager: 
NetworkManager state is now DISCONNECTED
May 28 17:34:11 system NetworkManager[514]:   [1495985651.4610] device 
(wlx98ded019dc08): Activation: failed for connection 'Home.Wireless.Internet'
May 28 17:34:11 system NetworkManager[514]:   [1495985651.4615] device 
(wlx98ded019dc08): state change: failed -> disconnected (reason 'none') [120 
30 0]



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

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

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.18-1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2
ii  libc6  2.24-10
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5
ii  libgudev-1.0-0 230-3
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.6.2-3
ii  libpam-systemd 232-23
ii  libpolkit-agent-1-00.105-17
ii  libpolkit-gobject-1-0  0.105-17
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b1
ii  libsoup2.4-1   2.56.0-2
ii  libsystemd0232-23
ii  libteamdctl0   1.26-1+b1
ii  libuuid1   2.29.2-1
ii  lsb-base   9.20161125
ii  policykit-10.105-17
ii  udev   232-23
ii  wpasupplicant  2:2.4-1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.76-5+b1
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

-- 

mail: user2...@web.de

Bug#721430: crosstool-ng, Debian Maintainer and/or PR 352

[Geert Stappers]

On Mon, May 22, 2017 at 09:11:14PM +, Chris Packham wrote:
> On 23/05/17 09:05, Geert Stappers wrote:
> > 
> > I have a git clone of https://github.com/cpackham/crosstool-ng.git
> > found the patch for the PR.
> > 
> > I'll join it with my work from yesterday.
> > 
> > And we have to find a way how we join effort.
> > 
> 
> OK let me know if you need any help.

I'm looking for a candidate for maintaining crosstools-ng in Debian.

Find attached a debian tar as starting point.
It can also go in https://github.com/crosstool-ng/crosstool-ng/pull/352



Groeten
Geert Stappers
Debian Developer
volunteering for uploading crosstools-ng into Debian
-- 
Leven en laten leven


crosstool-ng_1.23.0-1.debian.tar.xz
Description: Binary data


signature.asc
Description: Digital signature

Bug#863560: network-manager-gnome: NetworkManager Applet does not hide unmanaged virtual interfaces

[Marcus Jodorf]

Package: network-manager-gnome
Version: 1.4.6-1
Severity: normal


Dear maintainer,

NetworkManager Applet shows useless entries of unmanaged interfaces.
In my case it is virtual interfaces from vmwware workstation.

# nmcli d
DEVICETYPE  STATE CONNECTION  
wlp1s0wifi  connected mywifi 
cdc-wdm0  gsm   disconnected  --  
eth0  ethernet  unavailable   --  
vmnet1ethernet  unmanaged --  
vmnet8ethernet  unmanaged --  
loloopback  unmanaged --  

Here vmnet1 and vmnet8 lead to completely useless entries greyed out in
the applets' menu like this
"Ethernet ()
 device not managed
 Ethernet ()
 device not managed"

Since these are always listed at the top of the menu taking up considerable
space this is simply annoying.

And this could be a usability problem when one has more such interfaces
and less screen estate.

Same problem with the 1.8.0-1 version from experimental.

Only way I found to get rid of these stupid entries was to change the
source:

--- network-manager-applet-1.4.6.orig/src/applet-device-ethernet.c
+++ network-manager-applet-1.4.6/src/applet-device-ethernet.c
@@ -73,6 +73,10 @@ ethernet_add_menu_item (NMDevice *device
GtkWidget *item;
gboolean carrier = TRUE;

+   if (nm_device_get_state (device)) {
+   return;
+   }
+
if (multiple_devices) {
const char *desc;

--- network-manager-applet-1.4.6.orig/src/applet.c
+++ network-manager-applet-1.4.6/src/applet.c
@@ -1319,11 +1319,6 @@ nma_menu_device_get_menu_item (NMDevice
break;
}

-   if (!managed) {
-   item = gtk_menu_item_new_with_label (_("device not managed"));
-   gtk_widget_set_sensitive (item, FALSE);
-   }
-
return item;
 }


Best regards,

Marcus Jodorf



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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.10.18-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2+b1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-10
ii  libcairo2 1.14.8-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.12-1
ii  libjansson4   2.9-1
ii  libmm-glib0   1.6.4-1
ii  libnm01.8.0-2
ii  libnma0   1.4.6-1
ii  libnotify40.7.7-2
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libsecret-1-0 0.18.5-3.1
ii  network-manager   1.6.2-3
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-6

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.20.0-3
ii  iso-codes3.75-1
ii  mobile-broadband-provider-info   20161204-1
ii  notification-daemon  3.20.0-1+b1
ii  xfce4-notifyd [notification-daemon]  0.3.6-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#858931: isakmpd: Patch

[solo-debianbugs]

Control: tags -1 + patch

The attached patch moves the code over to using the appropriate
accessors for OpenSSL 1.1 in most cases. I have disabled 40-bit
DES, and not ported that code, as the crypto is comically useless
in the modern world.

Chris.
diff --git a/isakmpd-20041012/apps/certpatch/certpatch.c b/isakmpd-20041012/apps/certpatch/certpatch.c
index 0a0125a..a619db6 100644
--- a/isakmpd-20041012/apps/certpatch/certpatch.c
+++ b/isakmpd-20041012/apps/certpatch/certpatch.c
@@ -147,8 +147,6 @@ main (int argc, char **argv)
* EVP_get_digest_byname.
*/
 
-  SSLeay_add_all_algorithms ();
-
   /* Use a certificate created by ssleay and add the appr. extension */
   printf ("Reading ssleay created certificate %s and modify it\n",
 	  certin);
@@ -171,7 +169,7 @@ main (int argc, char **argv)
 }
 
   /* Get the digest for the actual signing */
-  digest = EVP_get_digestbyname (OBJ_nid2sn (OBJ_obj2nid (cert->sig_alg->algorithm)));
+  digest = EVP_get_digestbyname (OBJ_nid2sn (X509_get_signature_nid(cert)));
 
   if (!X509_set_version (cert, 2))
 {
@@ -293,7 +291,7 @@ main (int argc, char **argv)
   BIO_free (file);
 
   printf ("Creating Signature: PKEY_TYPE = %s: ",
-	  pkey_priv->type == EVP_PKEY_RSA ? "RSA" : "unknown");
+   EVP_PKEY_id(pkey_priv) == EVP_PKEY_RSA ? "RSA" : "unknown");
   err = X509_sign (cert, pkey_priv, digest);
   printf ("X509_sign: %d ", err);
   if (!err)
diff --git a/isakmpd-20041012/crypto.c b/isakmpd-20041012/crypto.c
index d74191e..2995119 100644
--- a/isakmpd-20041012/crypto.c
+++ b/isakmpd-20041012/crypto.c
@@ -105,12 +105,13 @@ struct crypto_xf transforms[] = {
 #define DC	(void *)
 #endif
 
+#ifdef USE_DES
 enum cryptoerr
 des1_init(struct keystate *ks, u_int8_t *key, u_int16_t len)
 {
-	/* des_set_key returns -1 for parity problems, and -2 for weak keys */
-	des_set_odd_parity(DC key);
-	switch (des_set_key(DC key, ks->ks_des[0])) {
+	/* DES_set_key returns -1 for parity problems, and -2 for weak keys */
+	DES_set_odd_parity(DC key);
+	switch (DES_set_key(DC key, ks->ks_des[0])) {
 	case -2:
 		return EWEAKKEY;
 	default:
@@ -131,19 +132,20 @@ des1_decrypt(struct keystate *ks, u_int8_t *d, u_int16_t len)
 	des_cbc_encrypt(DC d, DC d, len, ks->ks_des[0], DC ks->riv,
 	DES_DECRYPT);
 }
+#endif
 
 #ifdef USE_TRIPLEDES
 enum cryptoerr
 des3_init(struct keystate *ks, u_int8_t *key, u_int16_t len)
 {
-	des_set_odd_parity(DC key);
-	des_set_odd_parity(DC(key + 8));
-	des_set_odd_parity(DC(key + 16));
+	DES_set_odd_parity(DC key);
+	DES_set_odd_parity(DC(key + 8));
+	DES_set_odd_parity(DC(key + 16));
 
 	/* As of the draft Tripe-DES does not check for weak keys */
-	des_set_key(DC key, ks->ks_des[0]);
-	des_set_key(DC(key + 8), ks->ks_des[1]);
-	des_set_key(DC(key + 16), ks->ks_des[2]);
+	DES_set_key(DC key, ks->ks_des[0]);
+	DES_set_key(DC(key + 8), ks->ks_des[1]);
+	DES_set_key(DC(key + 16), ks->ks_des[2]);
 
 	return EOKAY;
 }
@@ -154,7 +156,7 @@ des3_encrypt(struct keystate *ks, u_int8_t *data, u_int16_t len)
 	u_int8_tiv[MAXBLK];
 
 	memcpy(iv, ks->riv, ks->xf->blocksize);
-	des_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
+	DES_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
 	ks->ks_des[1], ks->ks_des[2], DC iv, DES_ENCRYPT);
 }
 
@@ -164,7 +166,7 @@ des3_decrypt(struct keystate *ks, u_int8_t *data, u_int16_t len)
 	u_int8_tiv[MAXBLK];
 
 	memcpy(iv, ks->riv, ks->xf->blocksize);
-	des_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
+	DES_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
 	ks->ks_des[1], ks->ks_des[2], DC iv, DES_DECRYPT);
 }
 #undef DC
diff --git a/isakmpd-20041012/crypto.h b/isakmpd-20041012/crypto.h
index 1095c7e..902c359 100644
--- a/isakmpd-20041012/crypto.h
+++ b/isakmpd-20041012/crypto.h
@@ -108,7 +108,7 @@ struct keystate {
 	u_int8_tiv2[MAXBLK];
 	u_int8_t   *riv, *liv;
 	union {
-		des_key_schedule desks[3];
+		DES_key_schedule *desks[3];
 #ifdef USE_BLOWFISH
 		blf_ctx blfks;
 #endif
diff --git a/isakmpd-20041012/debian/control b/isakmpd-20041012/debian/control
index cc5ddfd..cf3a994 100644
--- a/isakmpd-20041012/debian/control
+++ b/isakmpd-20041012/debian/control
@@ -3,7 +3,7 @@ Maintainer: Jochen Friedrich 
 Priority: optional
 Section: net
 Standards-Version: 3.8.4
-Build-Depends: debhelper (>= 7.0.50~), libssl1.0-dev | libssl-dev (<< 1.1.0~), libgmp-dev, libpcap-dev, linux-kernel-headers
+Build-Depends: debhelper (>= 7.0.50~), libssl-dev, libgmp-dev, libpcap-dev, linux-kernel-headers
 
 Package: isakmpd
 Priority: optional
diff --git a/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep b/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep
index 32104ed..4c2edb3 100644
--- a/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep
+++ b/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep
@@ -39,7 +39,7 @@ CFLAGS+=	-DHAVE_GETNAMEINFO -DUSE_OLD_SOCKADDR -DHAVE_PCAP \
 		-I/usr/include/openssl
 
 FEATURES=	debug tripledes blowfish cast ec aggressive x509
-FEATURES+=	dpd na

Bug#780706: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes

[Geert Stappers]

Control: tag -1  help


Hi,

Arduino packaging now builds for 1.8.2.  Get the source code for it through

   debcheckout arduino


However there is Java error and that is reason why
the Debian Java packaging team is in the CC.


The complete error
8<---8<
$ arduino
Picked up JAVA_TOOL_OPTIONS: 
Error parsing gtk-icon-sizes string: ''
java.lang.SecurityException: Invalid signature file digest for Manifest main 
attributes
at 
sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:314)
at 
sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:268)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:316)
at java.util.jar.JarVerifier.update(JarVerifier.java:228)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:383)
at java.util.jar.JarFile.getInputStream(JarFile.java:450)
at 
sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:977)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at processing.app.BaseNoGui.initPackages(BaseNoGui.java:483)
at processing.app.Base.(Base.java:252)
at processing.app.Base.main(Base.java:135)
$
8<---8<

My websearch did bring me to 
https://stackoverflow.com/questions/999489/invalid-signature-file-when-attempting-to-run-a-jar

It tells me to tweak a build.xml file.
It is the point where I get lost, where I need help.

Is it the file app/build.xml that needs something like






??


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Bug#862155: need upgrade of mate-desktop and caja to fix desktop background

[Philipp Pilhofer]

Am 28.05.2017 um 16:59 schrieb Vlad Orlov:
> Reassigning the bug to metapackage since fixing it requires upgrading
> of both mate-desktop (to 1.16.2) and Caja (to 1.16.3). Also merged all
> the duplicate reports since they're all about the same regression.
> 

Yes, an upgrade would be most appreciated (also see #861031), as it is really 
awful to ship a DE
with obvious bugs like this one ...


Cheers,
Philipp