Bug#796730: pstreams: calls std::char_traits::move(s, NULL, 0)

[Eugene Seliverstov]

Just a note that initial ubsan error cannot be reproduced for 0.8.0 and 0.8.1 
with the latest sid compiler (6.2), jessie compiler (4.8) and clang (3.8).
Seems like the bug #65049 exists only for gcc 5.3 and 6.0.

---
Best regards,
Eugene Seliverstov



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl

[Kurt Roeckx]

On Wed, Nov 30, 2016 at 05:38:45AM +0100, Guillem Jover wrote:
> Control: reassign -1 openssl1.0
> 
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
> > clone 845193 -1
> > reassign -1 dpkg
> > retitle -1 dpkg: please do not add -specs= flags only on some architectures
> > thanks
> > 
> > Guillem Jover dixit:
> > >> I cannot build openssl1.0 any longer. Downgrading all binary
> > >> packages from src:dpkg to 1.18.10 makes the build succeed.
> > 
> > Interestingly enough, src:openssl (1.1) works, so…
> > 
> > >So, I think I'll reassign this to openssl1.0, if no other feedback
> > 
> > … this is probably legit. But I would *still* like to raise
> > another point.
> 
> Ok, thanks, doing so now.

So can someone explain what needs to be fixed in openssl? The
order of the CFLAGS needs to be changed?


Kurt

Bug#846315: scapy script not working, but it works in the CLI

[Arturo Borrero Gonzalez]

Source: scapy
Version: 2.3.2-0.1
Severity: normal

Hi,

the following scapy 2.3.2 simple script:

=
#!/usr/bin/env python3

from scapy.all import *

pkt = IP()
pkt.ttl = 2

conf.L3socket = L3RawSocket
sr1(pkt)
=

Produces this in my debian system:

Begin emission:
ERROR: --- Error in child 3589
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/scapy/sendrecv.py", line 89, in sndrcv
pks.send(p)
  File "/usr/lib/python3/dist-packages/scapy/supersocket.py", line 102, in send
self.outs.sendto(sx,(x.dst,0))
TypeError: a bytes-like object is required, not 'IP'
Traceback (most recent call last):
  File "./scapy", line 9, in 
sr1(pkt)
  File "/usr/lib/python3/dist-packages/scapy/sendrecv.py", line 345, in sr1
a,b=sndrcv(s,x,*args,**kargs)
  File "/usr/lib/python3/dist-packages/scapy/sendrecv.py", line 133, in sndrcv
r = pks.recv(MTU)
  File "/usr/lib/python3/dist-packages/scapy/supersocket.py", line 94, in recv
from arch import get_last_packet_timestamp
ImportError: No module named 'arch'

I installed it from the debian archive:

% aptitude install python3-scapy

What is even more weird is that executing the same script steps in the
scapy CLI they work fine:

% sudo scapy
INFO: Can't import python gnuplot wrapper . Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
INFO: Can't import python Crypto lib. Won't be able to decrypt WEP.
INFO: Can't import python Crypto lib. Disabled certificate manipulation tools
Welcome to Scapy (2.3.2)
>>> pkt = IP()
>>> pkt.ttl = 2
>>> conf.L3socket = L3RawSocket
>>> sr1(pkt)
Begin emission:
Finished to send 1 packets.
*
Received 1 packets, got 1 answers, remaining 0 packets



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

Kernel: Linux 4.8.0+ (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Johannes Schauer]

Hi Martin,

Quoting Martin Pitt (2016-11-30 08:52:51)
> The expected state is that it is a symlink to
> /run/systemd/resolve/resolv.conf, and that's the bit that apparently doesn't
> exist -- i. e. systemd-resolved.service is not running in your case. So using
> the second method and vmdebootstrapping a VM without the setup script and
> checking it inside sounds like a good next step.

okay, that will fix things in my case but how would the general problem here be
addressed. And who is at fault?

One solution might be to document that the autopkgtest qemu setupscript depends
on systemd-resolved.service running. Another solution would be to make the
script independent of it. Maybe there is also something that can be addressed
in vmdebootstrap?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Martin Steigerwald]

Am Mittwoch, 30. November 2016, 07:46:31 CET schrieb Klaus Ethgen:
> > Also, *if* you want to make this about systemd vs. SysV again:
> Well, systemd, or better the religiosity, systemd is spread, is part of
> this particular problem. Exactly that is the case, why so many users
> oppose systemd.

I fully agree with that. As I pointed out before the fuss about systemd is not 
just technical, it is a social issue with the way upstream receives and reacts 
to any kind of feedback that criticizes the way systemd goes about things.

> However, this should be fight somewhere else. Here we have a real
> problem, that is easily fixable. Look at devuan or debian jessie. Just
> do not link against libsystemd what pulls in too many uncontrollable
> dependencies.

Also agreed to that… libsystemd is almost one third of the size of libc6.so 
here… and it seems upstream basically stuffes *everything* into it, including 
reading process attributes that IMHO would be a task for a *different* shared 
object like the much lighter libprocps.so.6.0.0.

But the discussion would need to be brought upstream, it just seems that these 
days no one dares to do that. I am not keen to subscribe to systemd-devel 
mailing list ever again after my last attempt to channel user feedback to this 
list and having been attacked with "now you are being a dick" by Lennart 
personally who on the other side rightfully complained about being attacked in 
person himself. (I unsubscribed from debian-devel mailing list back then for 
similar reasons.)

There is a split in the community that has never been healed, people just try 
to ignore it, but I doubt that this bug report would be the right place to go 
about this. And I wonder whether there is someone who would muster to bring up 
the courage to bring this up with upstream again in a constructive way.

Closing with a note to Michael: I learned to know you at DebConf 2016 and I 
value your work. However I didn´t see what you called an ad hominen attack as 
actually being one.

(I may refrain from any further comment here as I think its not really the 
place to discuss it.)

Thank you,
-- 
Martin

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Martin Pitt]

Johannes Schauer [2016-11-30  9:16 +0100]:
> > The expected state is that it is a symlink to
> > /run/systemd/resolve/resolv.conf, and that's the bit that apparently doesn't
> > exist -- i. e. systemd-resolved.service is not running in your case. So 
> > using
> > the second method and vmdebootstrapping a VM without the setup script and
> > checking it inside sounds like a good next step.
> 
> okay, that will fix things in my case but how would the general problem here 
> be
> addressed. And who is at fault?

There's no "fix" here yet, we are still trying to find out what
happens in your case :-) So I can't say yet who is at fault -- the
most likely candidates are a bug in vmdebootstrap or systemd.

Hence I would like to see if vmdebootstrap is also broken without the
setup script. It might very well be possible that the autopkgtest
setup script changes some configuration which breaks resolved or
whatnot.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#844505: disper: Maybe problems with py27?

[elias]

Package: disper
Version: 0.3.1-2
Followup-For: Bug #844505

Hello People,

After a 'apt-get dist-upgrade' disper stopped working

if i run disper via 'strace -e open,access disper -e 2>&1' i see following 
things

access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libffi.so.6", O_RDONLY|O_CLOEXEC) = 8
open("/usr/lib/python2.7/ctypes/struct.x86_64-linux-gnu.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
open("/usr/lib/python2.7/ctypes/struct.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/python2.7/ctypes/structmodule.so", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/python2.7/ctypes/struct.py", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/python2.7/ctypes/struct.pyc", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/python2.7/ctypes/ctypes.x86_64-linux-gnu.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
open("/usr/lib/python2.7/ctypes/ctypes.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/python2.7/ctypes/ctypesmodule.so", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/python2.7/ctypes/ctypes.py", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/python2.7/ctypes/ctypes.pyc", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/python2.7/ctypes/_endian.x86_64-linux-gnu.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
open("/usr/lib/python2.7/ctypes/_endian.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/python2.7/ctypes/_endianmodule.so", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/python2.7/ctypes/_endian.py", O_RDONLY) = 7
open("/usr/lib/python2.7/ctypes/_endian.pyc", O_RDONLY) = 8
open("/proc/self/status", O_RDONLY) = 7
open("/proc/mounts", O_RDONLY)  = 7
open("/usr/share/disper/src/xrandr/os.x86_64-linux-gnu.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
open("/usr/share/disper/src/xrandr/os.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/share/disper/src/xrandr/osmodule.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/share/disper/src/xrandr/os.py", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/share/disper/src/xrandr/os.pyc", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/share/disper/src/xrandr/core.x86_64-linux-gnu.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
open("/usr/share/disper/src/xrandr/core.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/share/disper/src/xrandr/coremodule.so", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/share/disper/src/xrandr/core.py", O_RDONLY) = 6
open("/usr/share/disper/src/xrandr/core.pyc", O_RDONLY) = 7
open("/usr/share/disper/src/xrandr/xrandr.x86_64-linux-gnu.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
open("/usr/share/disper/src/xrandr/xrandr.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/share/disper/src/xrandr/xrandrmodule.so", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/share/disper/src/xrandr/xrandr.py", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/share/disper/src/xrandr/xrandr.pyc", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libX11.so.6", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libXau.so.6", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libXdmcp.so.6", O_RDONLY|O_CLOEXEC) = 7
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libXrandr.so.2", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libXext.so.6", O_RDONLY|O_CLOEXEC) = 7
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libXrender.so.1", O_RDONLY|O_CLOEXEC) = 7
access("/home/elias/.Xauthority", R_OK) = 0
open("/home/elias/.Xauthority", O_RDONLY) = 7
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7d567ae8} ---
+++ killed by SIGSEGV +++
Speicherzugriffsfehler

btw.

poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{iov_base="b\0\5\0\t\0\340\3", iov_len=8}, {iov_base="XKEYBOARD", 
iov_len=9}, {iov_base="\0\0\0", iov_len=3}], 3) = 20
poll([{fd=5, events=POLLIN}], 1, -1)= 1 ([{fd=5, revents=POLLIN}])
recvmsg(5, {msg_name=N

Bug#828351: inn2: FTBFS with openssl 1.1.0

[Marco d'Itri]

On Nov 29, Sebastian Andrzej Siewior  wrote:

> Please find attached a patch against the package which includes the
> three three patches mentioned here and was sbuild tested.
> Should I NMU it?
NO! I have a new package ready, but it needs some mild testing.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Julian Andres Klode]

(Huh, all emails are CCing listmaster - let's drop them for this
 subthread for now.)

On Wed, Nov 30, 2016 at 07:46:31AM +0100, Klaus Ethgen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi Martin,
> 
> Am Di den 29. Nov 2016 um 22:36 schrieb Martin Pitt:
> > Cristian Ionescu-Idbohrn [2016-11-29 22:16 +0100]:
> > > Eversince systemd came about into debian, you've shown direct or
> > > indirect disrespect, IMO, to people objecting against screwing up
> > > their systems, where they want to keep sysv instead of adopting
> > > systemd world domination.
> > 
> > The root issue here is not about the init system, but how initramfses
> > and separate partitions play together. Separate /usr without an initrd
> > has always been slightly broken,
> 
> No, it worked well for decades and it was exactly why you have small
> root and resizable /usr on other medias.

In your imagination, that is (yes, I too can write stupid replies
without any arguments - but I actually can provide arguments too,
see below).

> 
> It start getting broken when systemd start taking over the world.
> 
> > So, the set of what can be supported is certainly debatable, but as
> > history has shown it neither makes sense to support this use case nor
> > did anyone manage to actually do it. Hence the "wontfix".
> 
> As history shows, that is common use case and makes fully sense.

It used to make sense, but it never really worked, as you cannot make
a reasonable static decision as to what goes into / vs /usr. And thus,
some people had stuff like network they needed for mounting /usr or
otherwise early in boot, but the binaries for that happened to be in
/usr.

*All* these problems were solved with the introduction of initramfs,
which allows us to make the decision as to a minimal root filesystem
dynamically on the actual system.

Why maintain a second solution that is a lot of work, (because it)
always breaks, and only solves a small subset of the problems?

> 
> > Also, *if* you want to make this about systemd vs. SysV again:
> 
> Well, systemd, or better the religiosity, systemd is spread, is part of
> this particular problem. Exactly that is the case, why so many users
> oppose systemd.
> 
> However, this should be fight somewhere else. Here we have a real
> problem, that is easily fixable. Look at devuan or debian jessie. Just
> do not link against libsystemd what pulls in too many uncontrollable
> dependencies.

Just accept reality and move on.

There is no reason to try to keep that separate / madness up anymore:

(1) we have better solutions now
(2) nobody really uses the it -> no testing

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Johannes Schauer]

Hi,

Quoting Martin Pitt (2016-11-30 09:32:05)
> Hence I would like to see if vmdebootstrap is also broken without the setup
> script. It might very well be possible that the autopkgtest setup script
> changes some configuration which breaks resolved or whatnot.

sorry I didn't mention that before. Without the autopkgtest setup script,
vmdebootstrap finishes successfully.

cheers, josch


signature.asc
Description: signature

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Martin Pitt]

Hello Martin,

Martin Steigerwald [2016-11-30  9:20 +0100]:
> Also agreed to that… libsystemd is almost one third of the size of libc6.so 
> here… and it seems upstream basically stuffes *everything* into it, including 
> reading process attributes that IMHO would be a task for a *different* shared 
> object like the much lighter libprocps.so.6.0.0.
> 
> But the discussion would need to be brought upstream

Please let me clarify that you are talking about two different issues:

  1. libsystemd being too big, which is the part which can and should
  be discussed on the upstream systemd list indeed, as that's not
  something which is appropriate to change downstream. But this is
  entirely unrelated to this bug report.

  I sympathize with this, and maybe the earlier split into three
  smaller libraries was the better choice. And if someone refrains
  from starting the discussion with a tone like "you guys suck, break
  everything, and want to dominate the world", it might even be
  successful :-) (please forgive me the exaggeration)

  2. Debian supporting separate /usr without an initrd, and by
  extension, if boot-critical bits can link to stuff in /usr, which
  this bug is about. This is entirely a downstream Debian packaging
  issue (we could move liblz4 to /lib, like we did with other
  libraries), and does not belong on an upstream ML.

  Personally I think this part is a lost cause, both for technical
  reasons that have existed for a long time (which I will not repeat
  here), and even more so because the ongoing move to the /usr merge
  will make this completely obsolete -- if the *entire* OS is in /usr,
  then there is no alternative to an initrd anyway. This will finally
  make the whole design simpler, robust, maintainable, and reduce
  combinatorial explosion.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mi den 30. Nov 2016 um  9:36 schrieb Julian Andres Klode:
> In your imagination, that is (yes, I too can write stupid replies
> without any arguments - but I actually can provide arguments too,
> see below).

Thanks for insulting me. (I do not really care but it is good when it
goes against the users but it is bad when it is against DDs?)

[systemd religiosity]
> Just accept reality and move on.

That would mean to let debian die in its religious systemd world?

> There is no reason to try to keep that separate / madness up anymore:
> 
> (1) we have better solutions now

Seems to be no.

> (2) nobody really uses the it -> no testing

I didn't know that my name is nobody. And I also didn't know that I
share this name with many others.

It is just in your limited reality where it is "alternativlos", just to
qoute chancellor Merkel.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlg+kY0ACgkQpnwKsYAZ
9qzRxgv/Yv2pUPnreIkk/GrZ1nQ3x8dMLM1ASlWpov1lU0vacx2jMOqWho3Oyol9
oliRw/greuTuEHWhnjRYSSp6LvJjbrhK1zGxwOfo7m9PV9NKnsbkgsDsfpYwVgLD
yMNklpVaIa/l8X4/av+vGKIGcPovDhOGDzr5md3wvSNmddafEaiL+uK/BygTvDjk
wCNOX5mneRHR4ZNcjN7hqzJUTYZ8bYUJPTLl9/6abVfFg1jkzEwloR04znv0iPY+
Zl9oIvJo6Ov/T4kMdKkS8BkdMMS9E5jjH+LZ6BYaVyS2nwV6usc9KrfViDdxeEDn
xCa+PXQxyTEa5XUUc1b8lh+dj1V1u+HJUvj1rinr8Ig/SB+yaWFy5X1nfw/glF1c
k9SRWWW1bGEPQgQPt7sUhu/FLHz/w7synK8YvFZjZqx1ws2aXuB++z6d/bZFlsLE
+lAu6DeObAlmQx0h9eIVbR5i6KEppvJHT5Vzkoz4RX7FF81g8UUui1H0eXo/blia
RYV3enkz
=XJVt
-END PGP SIGNATURE-

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Martin Pitt]

Johannes Schauer [2016-11-30  9:39 +0100]:
> sorry I didn't mention that before. Without the autopkgtest setup script,
> vmdebootstrap finishes successfully.

Finish yes, that's the easy part. The interesting part is whether you
can boot that VM and resolve names in it? Is resolved running?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#846316: moc: window resizes, but only once

[Jamie Lentin]

Package: moc
Version: 1:2.6.0~svn-r2848-1
Severity: important

Dear Maintainer,

With 1:2.6.0~svn-r2848-1 MOC responds to window resizes, but only once.
After that any window resizes are ignored. There is a fix upstream already,
see the following thread:-

http://moc.daper.net/node/1554

Is a new version of the package possible?

Many thanks,

-- 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.8.0-1-amd64 (SMP w/4 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 moc depends on:
ii  libasound21.1.2-1
ii  libc6 2.24-5
ii  libcurl3-gnutls   7.51.0-1
ii  libdb5.3  5.3.28-12
ii  libfaad2  2.8.0~cvs20161113-1
ii  libflac8  1.3.1-4
ii  libgcc1   1:6.2.0-13
ii  libid3tag00.15.1b-12
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-3
ii  libltdl7  2.4.6-2
ii  libmad0   0.15.1b-8
ii  libmagic1 1:5.29-1
ii  libmodplug1   1:0.8.8.5-3
ii  libmpcdec62:0.1~r495-1
ii  libncursesw5  6.0+20160917-1
ii  libogg0   1.3.2-1
ii  libopusfile0  0.8-1
ii  libpopt0  1.16-10
ii  librcc0   0.2.12-0.1
ii  libresid-builder0c2a  2.1.1-15
ii  libsamplerate00.1.8-8
ii  libsidplay2   2.1.1-15
ii  libsidutils0  2.1.1-15
ii  libsndfile1   1.0.27-1
ii  libspeex1 1.2~rc1.2-1
ii  libstdc++66.2.0-13
ii  libtagc0  1.11.1-0.1
ii  libtinfo5 6.0+20160917-1
ii  libvorbis0a   1.3.5-3
ii  libvorbisfile31.3.5-3
ii  libwavpack1   4.80.0-1
ii  zlib1g1:1.2.8.dfsg-2+b3

moc recommends no packages.

Versions of packages moc suggests:
ii  moc-ffmpeg-plugin  1:2.6.0~svn-r2848-1

-- no debconf information

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Johannes Schauer]

Hi,

Quoting Martin Pitt (2016-11-30 09:51:10)
> Johannes Schauer [2016-11-30  9:39 +0100]:
> > sorry I didn't mention that before. Without the autopkgtest setup script,
> > vmdebootstrap finishes successfully.
> 
> Finish yes, that's the easy part. The interesting part is whether you can
> boot that VM and resolve names in it? Is resolved running?

yes, it runs fine and internet is working.

/etc/resolv.conf is indeed a symbolic link to /run/systemd/resolve/resolv.conf

systemd-resolved is running

cheers, josch


signature.asc
Description: signature

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Julian Andres Klode]

On Wed, Nov 30, 2016 at 09:45:08AM +0100, Klaus Ethgen wrote:
> Am Mi den 30. Nov 2016 um  9:36 schrieb Julian Andres Klode:
> > In your imagination, that is (yes, I too can write stupid replies
> > without any arguments - but I actually can provide arguments too,
> > see below).
> 
> Thanks for insulting me. (I do not really care but it is good when it
> goes against the users but it is bad when it is against DDs?)

I did not insult you. I just wrote that you make claims without
any arguments that do not match reality. In contrast, I demonstrated
that your claims are false and have shown how initramfs is a superior
solution compared a stand-alone root filesystem.

> 
> [systemd religiosity]
> > Just accept reality and move on.
> 
> That would mean to let debian die in its religious systemd world?

It has absolutely nothing to do with systemd.

> 
> > There is no reason to try to keep that separate / madness up anymore:
> > 
> > (1) we have better solutions now
> 
> Seems to be no.

I have given you one reasonable argument that we do have a better
solution with initramfs and proved that it solves all problems
that existed with a separate /usr partition.

> 
> > (2) nobody really uses the it -> no testing
> 
> I didn't know that my name is nobody. And I also didn't know that I
> share this name with many others.

Your name is not nobody. There might be a modest minority of users that
use a separate /usr without an initramfs. Standard Debian installations
use initramfs since a very long time.

And as so often, this stuff breaks. And if it is not used by the people
doing the uploads (and this is a huge group of people), the chance that
it will break installations without anyone noticing early is huge.

> It is just in your limited reality where it is "alternativlos", just to
> qoute chancellor Merkel.

eww.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#846317: ITP: zoph -- Web based digital image presentation and management system

[John Lines]

Package: wnpp
Severity: wishlist
Owner: John Lines 

* Package name: zoph
  Version : 0.9.4
* URL : http://www.zoph.org/
* License : GPL-2+
  Programming Lang: PHP
  Description : Web based digital image presentation and management system

Zoph (*Z*oph *O*rganizes *Ph*otos) is a web based digital image presentation
and management system. In other words, a photo album. It is built with
PHP and MySQL.

The backend database can relate an images to one of more albums, places,
people, catagories etc. Albums, places and catagories can be hierarchical.
Multiple users can be created, with individual access to albums.

Images can be imported via a web interface.
 
Gallery used to provide a web based image management system, but is no longer
packaged, and there appear to be no packages offering a similar functionality.
Version 0.8.0 of zoph was packaged for lenny, but dropped at bug #679417

Bug#846272: [Debichem-devel] Bug#846272: ga FTBFS on !x86 !ppc: error: unknown type name 'PAD_LOCK_T'

[Michael Banck]

severity 846272 important
severity 846273 important
thanks

Hi,

On Tue, Nov 29, 2016 at 08:56:55PM +0200, Adrian Bunk wrote:
> Severity: serious

It is my understanding that non-regression FTBFS errors are not RC,
hence important.


Thanks,

Michael

Bug#846272: [Debichem-devel] Bug#846272: ga FTBFS on !x86 !ppc: error: unknown type name 'PAD_LOCK_T'

[Adrian Bunk]

On Wed, Nov 30, 2016 at 10:09:52AM +0100, Michael Banck wrote:
> severity 846272 important
> severity 846273 important
> thanks
> 
> Hi,
> 
> On Tue, Nov 29, 2016 at 08:56:55PM +0200, Adrian Bunk wrote:
> > Severity: serious
> 
> It is my understanding that non-regression FTBFS errors are not RC,
> hence important.

"Doesn't build on an architecture where it built before"
is considered RC.

But the severity is actually irrelevant in practice, the old binaries
are already preventing the testing migration of ga.

> Thanks,
> 
> Michael

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#846319: letsencrypt.sh: Fails to create fullchain.pem

[Chris Boot]

Package: letsencrypt.sh
Version: 0.2.0-4
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Dear maintainer,

Since openssl 1.1 has migrated to stretch I am unable to renew my Let's
Encrypt certificates using letsencrypt.sh. The symptoms are:

 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
unable to load certificate
139783378379904:error:0D07207B:asn1 encoding routines:ASN1_get_object:header 
too long:crypto/asn1/asn1_lib.c:101:

What happens is that openssl is used with the same file/path for the
"-in" and "-out" arguments to openssl when converting the downloaded
issuer certificates from DER to PEM format. This produces the above
error message and results in a 0-byte chain.pem file.

The bug is fixed upstream in:
https://github.com/lukas2511/dehydrated/commit/7eca8aec5a6679ce5ca507386687d130cc38ce23

Regards,
Chris

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

Kernel: Linux 4.8.0-1-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 letsencrypt.sh depends on:
ii  curl 7.50.1-1
ii  openssl  1.1.0c-2

letsencrypt.sh recommends no packages.

letsencrypt.sh suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/letsencrypt.sh (from letsencrypt.sh package)

Bug#846244: [php-maint] Bug#846244: php5-phpdbg: lacks /usr/bin/phpdbg alternative

[Ondřej Surý]

Control: severity -1 wishlist
Control: tags -1 +wontfix

Hi Antoine,

this would change the behavior of stable system (imagine somebody
already has a symlink
or different copy of phpdbg), so this is not a material for updating
stable release.

php7.0-phpdbg already registers phpdbg using alternatives system in
Debian.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Tue, Nov 29, 2016, at 15:53, Antoine Musso wrote:
> Package: php5-phpdbg
> Version: 5.6.27+dfsg-0+deb8u1
> Severity: normal
> 
> Dear Maintainer,
> 
> I have installed php5-phpdbg from jessie/updates, the executable is
> available as /usr/bin/php5dbg. It would be very nice to add support for
> /usr/bin/phpdbg using the alternative system.  Then I guess the
> php7-phpdbg could also use that.
> 
> The reason is we have script that refers to 'phpdbg', eg without version
> information.
> 
> -- Package-specific info:
>  Additional PHP 5 information 
> 
>  PHP 5 SAPI (php5query -S): 
> phpdbg
> apache2
> cli
> 
>  PHP 5 Extensions (php5query -M -v): 
> curl (Enabled for phpdbg by maintainer script)
> curl (Enabled for apache2 by maintainer script)
> curl (Enabled for cli by maintainer script)
> sqlite3 (Enabled for phpdbg by maintainer script)
> sqlite3 (Enabled for apache2 by maintainer script)
> sqlite3 (Enabled for cli by maintainer script)
> pdo_sqlite (Enabled for phpdbg by maintainer script)
> pdo_sqlite (Enabled for apache2 by maintainer script)
> pdo_sqlite (Enabled for cli by maintainer script)
> readline (Enabled for phpdbg by maintainer script)
> readline (Enabled for apache2 by maintainer script)
> readline (Enabled for cli by maintainer script)
> redis (Enabled for phpdbg by maintainer script)
> redis (Enabled for apache2 by maintainer script)
> redis (Enabled for cli by maintainer script)
> opcache (Enabled for phpdbg by maintainer script)
> opcache (Enabled for apache2 by maintainer script)
> opcache (Enabled for cli by maintainer script)
> tidy (Enabled for phpdbg by maintainer script)
> tidy (Enabled for apache2 by maintainer script)
> tidy (Enabled for cli by maintainer script)
> intl (Enabled for phpdbg by maintainer script)
> intl (Enabled for apache2 by maintainer script)
> intl (Enabled for cli by maintainer script)
> xsl (Enabled for phpdbg by maintainer script)
> xsl (Enabled for apache2 by maintainer script)
> xsl (Enabled for cli by maintainer script)
> mcrypt (Enabled for phpdbg by maintainer script)
> mcrypt (Enabled for apache2 by maintainer script)
> mcrypt (Enabled for cli by maintainer script)
> pdo (Enabled for phpdbg by maintainer script)
> pdo (Enabled for apache2 by maintainer script)
> pdo (Enabled for cli by maintainer script)
> json (Enabled for phpdbg by maintainer script)
> json (Enabled for apache2 by maintainer script)
> json (Enabled for cli by maintainer script)
> 
>  Configuration files: 
> [PHP]
> engine = On
> short_open_tag = Off
> asp_tags = Off
> precision = 14
> output_buffering = 4096
> zlib.output_compression = Off
> implicit_flush = Off
> unserialize_callback_func =
> serialize_precision = 17
> disable_functions =
> pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,
> disable_classes =
> zend.enable_gc = On
> expose_php = Off
> max_execution_time = 30
> max_input_time = 60
> memory_limit = 128M
> error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
> display_errors = Off
> display_startup_errors = Off
> log_errors = On
> log_errors_max_len = 1024
> ignore_repeated_errors = Off
> ignore_repeated_source = Off
> report_memleaks = On
> track_errors = Off
> html_errors = On
> variables_order = "GPCS"
> request_order = "GP"
> register_argc_argv = Off
> auto_globals_jit = On
> post_max_size = 8M
> auto_prepend_file =
> auto_append_file =
> default_mimetype = "text/html"
> default_charset = "UTF-8"
> doc_root =
> user_dir =
> enable_dl = Off
> file_uploads = On
> upload_max_filesize = 2M
> max_file_uploads = 20
> allow_url_fopen = On
> allow_url_include = Off
> default_socket_timeout = 60
> [CLI Server]
> cli_server.color = On
> [Date]
> [filter]
> [iconv]
> [intl]
> [sqlite3]
> [Pcre]
> [Pdo]
> [Pdo_mysql]
> pdo_mysql.cache_size = 2000
> pdo_mysql.default_socket=
> [Phar]
> [mail function]
> SMTP = localhost
> smtp_port = 25
> mail.add_x_header = On
> [SQL]
> sql.safe_mode = Off
> [ODBC]
> odbc.allow_persistent = On
> odbc.check_persistent = On
> odbc.max_persistent = -1
> odbc.max_links = -1
> odbc.defaultlrl = 4096
> odbc.defaultbinmode = 1
> [Interbase]
> ibase.allow_p

Bug#844942: plastimatch: FTBFS: Tests failures

[Ghislain Vaillant]

control: tags -1 pending

On Sat, 19 Nov 2016 08:03:46 +0100 Lucas Nussbaum  wrote:

> The following tests FAILED:
>421 - vf-invert-trans-1 (Failed)
>422 - vf-invert-trans-1-stats (Failed)
>423 - vf-invert-trans-1-check (Failed)
>426 - wed-c (Failed)
> Errors while running CTest
> Makefile:152: recipe for target 'test' failed


The tests above have got mistakes in the declaration of their respective 
dependencies, which makes parallel run fail.


I have identified the mistakes and will push a patch fixing them.

Cheers,
Ghis

Bug#846321: libvirt-daemon should declare a dependency on iptables

[Pirate Praveen]

package: libvirt-daemon
version:  2.4.0-2
severity: important

On an apt-get dist-upgrade yesterday, libvirtd gave this error
(systemctl status libvirtd.service), after installing iptables, libvirtd
started without error. It should at least recommend iptables.

libvirt version: 2.4.0, package: 2 (Guido Günther  Tue,
15 N
]: hostname: nishumbha
]: direct firewall backend requested, but /sbin/iptables is not
available: No su
]: internal error: Failed to initialize a valid firewall backend
]: internal error: Failed to initialize a valid firewall backend
~



signature.asc
Description: OpenPGP digital signature

Bug#743599: lintian: false positive python-script-but-no-python-dep when using #!/usr/bin/python2

[Antonio Ospite]

Control: tags -1 patch

On Tue, 29 Nov 2016 20:56:00 +
Niels Thykier  wrote:

> 
> Hi,
> 
> Thanks for the provided patches.
> 
[...]
> 
> I have applied the changes to the test case.  However, the changes to
> the data files (regardless of which one I apply) cause a test regression
> there after AFAICT.
>
> The test failure is:
> > $ t/runtests -k -j1 t debian/test-out legacy-scripts
> > ENV[PATH]=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> > tests::legacy-scripts: diff -u t/tests/legacy-scripts/tags 
> > [...]/tests/scripts/tags.scripts
> > --- t/tests/legacy-scripts/tags 2016-11-29 20:42:28.674312854 +
> > +++ [...]/tests/scripts/tags.scripts2016-11-29 20:50:22.238324980 
> > +
> > @@ -13,11 +13,11 @@
> >  E: scripts: init.d-script-needs-depends-on-lsb-base etc/init.d/skeleton 
> > (line 40)
> >  E: scripts: missing-dep-for-interpreter jruby => jruby | jruby1.0 | 
> > jruby1.1 | jruby1.2 (usr/bin/jruby-broken)
> >  E: scripts: missing-dep-for-interpreter lefty => graphviz 
> > (usr/bin/lefty-foo)
> > +E: scripts: missing-dep-for-interpreter python2 => python:any | 
> > python-minimal:any (usr/bin/py2foo)
> >  E: scripts: package-installs-python-bytecode 
> > usr/lib/python2.3/site-packages/test.pyc
> >  E: scripts: php-script-but-no-phpX-cli-dep usr/share/scripts/php5foo
> >  E: scripts: php-script-but-no-phpX-cli-dep usr/share/scripts/phpfoo
> >  E: scripts: python-script-but-no-python-dep usr/bin/py2.Xfoo
> > -E: scripts: python-script-but-no-python-dep usr/bin/py2foo
> >  E: scripts: python-script-but-no-python-dep usr/bin/pyfoo
> >  E: scripts: shell-script-fails-syntax-check usr/bin/sh-broken
> >  E: scripts: wrong-path-for-interpreter usr/bin/lefty-foo 
> > (#!/usr/local/bin/lefty != /usr/bin/lefty)
> > fail tests::legacy-scripts: output differs!
> 
> I don't think that change was intentional, so I am sending the patch
> back for another review.
>

Lintian is right, I forgot to add the changes to
t/tests/legacy-scripts/tags.

New patch attached, rebased on top of the master branch.

I also updated the commit message to explain why the emitted error
changed, I hope it explains the changes clearly enough.

Thanks,
   Antonio

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

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
>From 347c834e66b9d21d7379ec2a32907d21c378a759 Mon Sep 17 00:00:00 2001
From: Antonio Ospite 
Date: Mon, 7 Nov 2016 16:55:26 +0100
Subject: [PATCHv2] data/scripts/interpreter.txt: fix false positive with python2
 as interpreter

When using dh_python2 the package ends up depending on pyhton:any
(Debian does not have a python2:any package).

However if a script uses python2 as the interpreter, the lintian
dependency checks fails:

  E: scripts: python-script-but-no-python-dep usr/bin/script_name

Basically lintian tries to look for a dependency on python2:any, it does
not know that python:any is OK as a dependency for scripts using python2
in the shebang line.

This can be verified by temporarily adding "python:any" to
t/tests/legacy-scripts/debian/debian/control and running the test:

  debian/rules runtests onlyrun=legacy-scripts

Lintian will not give the error anymore for pyfoo, but it will still
emit it for py2foo which is wrong.

Fix the issue adding python2 to the unversioned interpreters, the
rationale being that the python2 interpreter requires unversioned
dependencies.

After the fix, lintian will give a clearer error when the dependency is
really missing:

  E: scripts: missing-dep-for-interpreter python2 => python:any | python-minimal:any (usr/bin/py2foo)

And to prove that the false positive is not occurring anymore,
temporarily adding "python:any" to
t/tests/legacy-scripts/debian/debian/control will not give the error
anymore for py2foo either when running:

  debian/rules runtests onlyrun=legacy-scripts
---
 data/scripts/interpreters   | 1 +
 t/tests/legacy-scripts/tags | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/data/scripts/interpreters b/data/scripts/interpreters
index 81100d2..3f5e2d5 100644
--- a/data/scripts/interpreters
+++ b/data/scripts/interpreters
@@ -73,6 +73,7 @@ plackup=> /usr/bin, libplack-perl
 procmail   => /usr/bin
 pypy   => /usr/bin
 python => /usr/bin, python:any | python-minimal:any
+python2=> /usr/bin, python:any | python-minimal:any
 pforth => /usr/bin
 racket => /usr/bin
 rake   => /usr/bin
diff --git a/t/tests/legacy-scripts/tags b/t/tests/legacy-scripts/tags
index 58d6d62..913844d 100644
--- a/t/tests/legacy-scripts/tags
+++ b/t/tests/legacy-scripts/tags
@@ -13,13 +13,13 @@ E: scripts: init.d-script-has-unterminated-lsb-section etc/init.d/lsb-broken:15
 E: scripts: init.d-script-needs-depends-on-lsb-base etc/init.d/skeleton (line 40)
 E: scripts: missing-dep-for-interpreter jruby => jruby | jruby1.0 | j

Bug#770153: Please add patch with upstream fix

[Pietro Battiston]

Given the simplicity of the fix, I strongly suggest to add it as a
patch in Debian. It resorts to the following commit:
https://git.gnome.org/browse/gedit/commit/?id=f4ecdcb8807fec2594f62bf7a
7f179063f31e41b

... although I would add the following just for clarity:

https://git.gnome.org/browse/gedit/commit/?id=3bdfa5764deb9909dae9ef041
a7e9b6d6297341a

I would be happy to help (i.e. to prepare a unified patch).

Pietro

Bug#846316: moc: window resizes, but only once

[Elimar Riesebieter]

control: severity -1 normal
control: tags -1 +fixed-upstream


Hi Jamie,

thanks for reporting this issue.

* Jamie Lentin  [2016-11-30 08:45 +]:

> Package: moc
> Version: 1:2.6.0~svn-r2848-1
> Severity: important
> 
> Dear Maintainer,
> 
> With 1:2.6.0~svn-r2848-1 MOC responds to window resizes, but only once.
> After that any window resizes are ignored. There is a fix upstream already,
> see the following thread:-
> 
> http://moc.daper.net/node/1554
> 
> Is a new version of the package possible?

There is a new release planned for upload. It includes:


 r2917 | jcf | 2016-09-25 03:47:18 +0200 (Sun, 25 Sep 2016) | 9 lines

  Fix: Adapt to changed signal(2) behaviour under POSIX.

  Whether or not the signal handler is reinstated after a signal is
  received and handled is implementation dependant under POSIX.  Using
  sigaction(2) is both well defined and thread safe.

  Thanks to: Daniel T. Borelli (on whose patch this was based)
  Resolves: node/1554


Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)

Bug#846322: golang-google-cloud: FTBFS (undefined: grpc.SupportPackageIsVersion3)

[Santiago Vila]

Package: src:golang-google-cloud
Version: 0.0~git20160615-6
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang 
--builddir=/<>/build
   dh_testdir -i -O--buildsystem=golang 
-O--builddir=/<>/golang-google-cloud-0.0\~git20160615/build
   dh_update_autotools_config -i -O--buildsystem=golang 
-O--builddir=/<>/golang-google-cloud-0.0\~git20160615/build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure
dh_auto_configure: "google.golang.org/cloud" is already installed. Please check 
for circular dependencies.

# Remove examples.
rm -vrf /<>/build/src/google.golang.org/cloud/examples
removed 
'/<>/build/src/google.golang.org/cloud/examples/bigtable/search/search.go'
removed directory 
'/<>/build/src/google.golang.org/cloud/examples/bigtable/search'

[... snipped ...]

github.com/golang/protobuf/ptypes/timestamp
google.golang.org/cloud/bigtable/internal/cluster_data_proto
google.golang.org/cloud/bigtable/internal/cluster_service_proto
# google.golang.org/cloud/bigtable/internal/cluster_service_proto
src/google.golang.org/cloud/bigtable/internal/cluster_service_proto/bigtable_cluster_service.pb.go:29:
 undefined: grpc.SupportPackageIsVersion3
google.golang.org/cloud/bigtable/internal/data_proto
github.com/golang/protobuf/ptypes/any
google.golang.org/cloud/bigtable/internal/rpc_status_proto
google.golang.org/cloud/bigtable/internal/service_proto
# google.golang.org/cloud/bigtable/internal/service_proto
src/google.golang.org/cloud/bigtable/internal/service_proto/bigtable_service.pb.go:29:
 undefined: grpc.SupportPackageIsVersion3
google.golang.org/cloud/bigtable/internal/table_data_proto
google.golang.org/cloud/bigtable/internal/table_service_proto
# google.golang.org/cloud/bigtable/internal/table_service_proto
src/google.golang.org/cloud/bigtable/internal/table_service_proto/bigtable_table_service.pb.go:29:
 undefined: grpc.SupportPackageIsVersion3
google.golang.org/cloud/bigtable/internal/cbtrc
google.golang.org/api/container/v1
google.golang.org/cloud/container
github.com/golang/protobuf/ptypes/wrappers
github.com/golang/protobuf/ptypes/struct
google.golang.org/cloud/datastore/internal/type_proto
google.golang.org/cloud/datastore/internal/proto
# google.golang.org/cloud/datastore/internal/proto
src/google.golang.org/cloud/datastore/internal/proto/datastore.pb.go:950: 
undefined: grpc.SupportPackageIsVersion3
google.golang.org/cloud/internal/testutil
google.golang.org/api/logging/v1beta3
google.golang.org/cloud/logging
github.com/googleapis/gax-go
github.com/googleapis/proto-client-go/api
github.com/googleapis/proto-client-go/logging/type_
github.com/googleapis/proto-client-go/rpc
github.com/googleapis/proto-client-go/logging/v2
# github.com/googleapis/proto-client-go/logging/v2
src/github.com/googleapis/proto-client-go/logging/v2/logging.pb.go:216: 
undefined: grpc.SupportPackageIsVersion3
src/github.com/googleapis/proto-client-go/logging/v2/logging_config.pb.go:223: 
undefined: grpc.SupportPackageIsVersion3
src/github.com/googleapis/proto-client-go/logging/v2/logging_metrics.pb.go:183: 
undefined: grpc.SupportPackageIsVersion3
google.golang.org/api/pubsub/v1
google.golang.org/cloud/pubsub
google.golang.org/api/storage/v1
google.golang.org/cloud/storage
dh_auto_build: go install -v -p 1 google.golang.org/cloud 
google.golang.org/cloud/bigquery google.golang.org/cloud/bigtable 
google.golang.org/cloud/bigtable/bttest 
google.golang.org/cloud/bigtable/cmd/cbt 
google.golang.org/cloud/bigtable/cmd/loadtest 
google.golang.org/cloud/bigtable/internal/cbtrc 
google.golang.org/cloud/bigtable/internal/cluster_data_proto 
google.golang.org/cloud/bigtable/internal/cluster_service_proto 
google.golang.org/cloud/bigtable/internal/data_proto 
google.golang.org/cloud/bigtable/internal/rpc_status_proto 
google.golang.org/cloud/bigtable/internal/service_proto 
google.golang.org/cloud/bigtable/internal/table_data_proto 
google.golang.org/cloud/bigtable/internal/table_service_proto 
google.golang.org/cloud/compute/metadata google.golang.org/cloud/container 
google.golang.org/cloud/datastore 
google.golang.org/cloud/datastore/internal/proto 
google.golang.org/cloud/datastore/internal/type_proto 
google.golang.org/cloud/internal google.golang.org/cloud/internal/opts go
 ogle.golang.org/cloud/internal/testutil 
google.golang.org/cloud/internal/transport google.golang.org/cloud/logging 
google.golang.org/cloud/logging/apiv2/config 
google.golang.org/cloud/logging/apiv2/logging 
google.golang.org/cloud/logging/apiv2/metrics google.golang.org/cloud/pubsub 
google.golang.org/cloud/storage returned exit code 2
debian/rules:30: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_

Bug#846294: [pkg-go] Bug#846294: [peco] Binary ist statically linked

[Martín Ferrari]

On 29/11/16 22:06, Bruno Kleinert wrote:

> file says, the peco binary is statically linked:
> 
> (0)fuddl@flutschi:~$ file /usr/bin/peco 
> /usr/bin/peco: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> statically linked, stripped
> 
> Is that intentional? I would expect it to be dynamically linked.

All go applications are currently compiled statically.


-- 
Martín Ferrari (Tincho)

Bug#845018: RFS: quagga/1.1.0-1 [ITA] -- network routing daemons

[Scott Leggett]

On 2016-11-29.15:24, Vincent Bernat wrote:

> All good for me. It's uploaded!

Thanks again for your help!

-- 
Regards,
Scott.


signature.asc
Description: Digital signature

Bug#846323: mplayer extraction is broken

[Thibaut Paumard]

Package: gimp-gap
Version: 2.6.0+dfsg-5+b1
Severity: important

Dear maintainers,

MPlayer command-line parameters have changed to that mplayer-based extraction
fails with:

-aofile has been removed. Use -ao pcm:file= instead.
-jpeg has been removed. Use -vo jpeg: instead.

It should be fairly easy to patch gimp-gap to use the new interface.

Regards, Thibaut.



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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gimp-gap depends on:
ii  gimp 2.8.18-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-7
ii  libcairo21.14.6-1.1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgimp2.0   2.8.18-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libpng16-16  1.6.26-2
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages gimp-gap recommends:
ii  mplayer  2:1.3.0-5

gimp-gap suggests no packages.

-- no debconf information

Bug#725910: colormake: man page refers to non-existent configuration file

[Ludovic Rousseau]

Le 29/11/2016 à 21:36, Reuben Thomas a écrit :

On 29 November 2016 at 20:04, Ludovic Rousseau mailto:ludovic.rouss...@free.fr>> wrote:

On Wed, 09 Oct 2013 23:54:23 +0100 Reuben Thomas mailto:r...@sc3d.org>> wrote:

Package: colormake
Version: 0.9-1
Severity: minor

colormake(1) refers to /usr/share/colormake/colormake.rc, which does 
not exist.


Exact.
This file is not installed by the Debian package. The file also does not 
exist in the upstream tarball.

The idea is that the admin can _create_ this file so the same configuration 
will be used, by default, for all the system users.
The syntax is the same as for ~/.colormakerc

How do you propose to solve this bug?


​I hadn't read the man page closely enough to realise that this is a 
configuration file, thanks!

​A system-wide configuration file should surely be under /etc, not under 
/usr/share. So I would propose to solve the bug by moving the file. I guess 
this is an upstream bug?​


You are completely right. /etc is a better place.

Yes, it is an upstream bug already available at 
https://github.com/pagekite/Colormake/issues/14

Thanks

--
Dr. Ludovic Rousseau

Bug#846324: googletest: Split the gmock binary from the rest

[Norbert Lange]

Package: googletest
Version: 1.8.0-3
Severity: wishlist

Dear Maintainer,

please split up googletest into a source/header only package and a separate
package for the binary (only gmock_gen).

Reasons would be to get rid of the python dependency and the ability to make 
the includes and sources - which are enough for alot of use cases - available
as a package for all achitectures.

probably the package for the gmock_gen tool could be for all architectures
aswell?

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/12 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 googletest depends on:
pn  python:any  

googletest recommends no packages.

googletest suggests no packages.

-- no debconf information

Bug#846326: wrong CXX in plat-*/_sysconfigdata_nd.py

[Helmut Grohne]

Package: libpython2.7-minimal
Version: 2.7.12-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:protobuf

protobuf fails to cross build from source, because building the python2
extension fails. It uses the recorded CC (cross compiler) for compiling
C++ files (which apparently works) and then fails linking the extension
with "c++". That value comes from _sysconfigdata_nd.py key CXX. It
should really contain a cross compiler. The attached patch fixes the
problem by passing the right CXX to ./configure as already happens for
python3.5 where this problem is not present. Please consider applying
it.

Helmut
diff -u python2.7-2.7.12/debian/changelog python2.7-2.7.12/debian/changelog
--- python2.7-2.7.12/debian/changelog
+++ python2.7-2.7.12/debian/changelog
@@ -1,3 +1,11 @@
+python2.7 (2.7.12-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix wrong CXX in _sysconfigdata_nd.py: Pass CXX to configure. (Closes:
+#-1)
+
+ -- Helmut Grohne   Wed, 30 Nov 2016 10:51:39 +0100
+
 python2.7 (2.7.12-7) unstable; urgency=medium
 
   * Update to 20161121 from the 2.7 branch.
diff -u python2.7-2.7.12/debian/rules python2.7-2.7.12/debian/rules
--- python2.7-2.7.12/debian/rules
+++ python2.7-2.7.12/debian/rules
@@ -340,7 +340,7 @@
rm -rf $(buildd_shared)
mkdir -p $(buildd_shared)
cd $(buildd_shared) && \
- CC="$(CC)" AR="$(AR)" RANLIB="$(RANLIB)" \
+ CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" \
  CFLAGS="$(OPT_CFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
$(config_site) \
../configure \
@@ -355,7 +355,7 @@
rm -rf $(buildd_static)
mkdir -p $(buildd_static)
cd $(buildd_static) && \
- CC="$(CC)" AR="$(AR)" RANLIB="$(RANLIB)" \
+ CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" \
  CFLAGS="$(OPT_CFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
$(config_site) \
../configure \
@@ -369,7 +369,7 @@
rm -rf $(buildd_debug)
mkdir -p $(buildd_debug)
cd $(buildd_debug) && \
- CC="$(CC)" AR="$(AR)" RANLIB="$(RANLIB)" \
+ CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" \
  CFLAGS="$(DEBUG_CFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
$(config_site) \
../configure \
@@ -384,7 +384,7 @@
rm -rf $(buildd_shdebug)
mkdir -p $(buildd_shdebug)
cd $(buildd_shdebug) && \
- CC="$(CC)" AR="$(AR)" RANLIB="$(RANLIB)" \
+ CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" \
  CFLAGS="$(DEBUG_CFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
$(config_site) \
../configure \

Bug#846323: mplayer extraction is broken

[Thibaut Paumard]

Control: severity -1 wishlist

It's a preference that can be set at runtime. Ideally the default should
be the new API instead of the (very) old.

Regards, self.

Bug#846325: RFS: netperfmeter/1.6.1-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

NetPerfMeter is a network performance meter for the UDP,
TCP, MPTCP, SCTP and DCCP transport protocols over IPv4 and
IPv6. It simultaneously transmits bidirectional flows to an
endpoint and measures the resulting flow bandwidths and QoS.
The results are written as vector and scalar files. The vector
files can e.g. be used to create plots of the results.

Details can be found at: https://www.uni-due.de/~be0001/netperfmeter/ .

* Package name  : netperfmeter
Version : 1.6.1-1
Upstream Author : [fill in name and email of upstream]
* URL   : https://www.uni-due.de/~be0001/netperfmeter/
* License   : GPL, version 3
Section : net

It builds those binary packages:

 netperfmeter - Network Performance Meter

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/n/netperfmeter/netperfmeter_1.6.1-1.dsc

 
Regards,
Thomas


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

Bug#846327: RFS: bibtexconv/1.1.7-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

BibTeXConv is a BibTeX file converter which allows to export
BibTeX entries to other formats, including customly defined
text output. Furthermore, it provides the possibility to
check URLs (including MD5, size and MIME type computations)
and to verify ISBN and ISSN numbers.


Details can be found at: https://www.uni-due.de/~be0001/bibtexconv/ .

* Package name  : bibtexconv
Version : 1.1.7-1
Upstream Author : Thomas Dreibholz 
* URL   : https://www.uni-due.de/~be0001/bibtexconv/
* License   : GPL, version 3
Section : tex

It builds those binary packages:

 bibtexconv - BibTeX Converter
 ietf2bibtex - Create BibTeX entry for IETF document (RFC or Internet Draft)

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

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


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

 dget -x 
https://mentors.debian.net/debian/pool/main/b/bibtexconv/bibtexconv_1.1.7-1.dsc


Regards,
Thomas


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

Bug#828413: closed by Laurent Bigonville (Bug#828413: fixed in libssh 0.7.3-2)

[Laurent Bigonville]

Le 30/11/16 à 06:30, Salvatore Bonaccorso a écrit :

Hi Laurent,

On Tue, Nov 29, 2016 at 03:30:04PM +, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the src:libssh package:

#828413: libssh: FTBFS with openssl 1.1.0

It has been closed by Laurent Bigonville .

Saw that this was closed. I think the approach should be to lower the
severity and unblock the openssl transition if the FTBFS with openssl
1.1 is workarounded by explicitly build-depending on libssl1.0-dev.

I just reopened 828413, *but* lowered the severity and ublocked 827061
from it, as rationale for the above.

Hope above makes sense, have explicitly Cc'ed Kurt as well.


Yes, makes sense

Thanks

Bug#846328: RFH: autopkgtest -- automatic as-installed testing for Debian packages

[Martin Pitt]

Package: wnpp

I have been the only de-facto maintainer of autopkgtest for some
years, Ian does not have time for it any more. This has been fine so
far as maintaining Ubuntu's CI machinery has been a major part of my
current job in Canonical. However, from next year on I will move
somewhere else and thus won't have much time for autopkgtest any more.
As this is a central piece in Debian's CI too, it would be good to get
more hands on it.

Coordination and discussion happens on
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/autopkgtest-devel
which is fairly low-traffic. I'm happy to review patches and sponsor
uploads, but I'd really like to mentor other people about the
structure, how to test autopkgtest itself locally, etc.


Description: automatic as-installed testing for Debian packages
 autopkgtest runs tests on binary packages.  The tests are run on the
 package as installed on a testbed system (which may be found via a
 virtualisation or containment system).  The tests are expected to be
 supplied in the corresponding Debian source package.
 .
 See autopkgtest(1) and /usr/share/doc/autopkgtest.
 Depending on which virtualization server you want to use, you need to
 install additional packages (schroot, lxc, lxd, or qemu-system)
 .
 For generating tests of well-known source packages such as Perl and Ruby
 libraries you should install the autodep8 package.


Thanks in advance!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#846329: RFS: tsctp/0.6.3-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name  : tsctp
Version : 0.6.3-1
Upstream Author : Michael Tüxen 
* URL   : https://www.uni-due.de/~be0001/tsctp/
* License   : BSD
Section : net

It builds those binary packages:

 tsctp - SCTP Test Tool

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

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


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

 dget -x https://mentors.debian.net/debian/pool/main/t/tsctp/tsctp_0.6.3-1.dsc


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

Bug#846330: pirs: FTBFS on non-x86 architectures because it hard-wires CFLAGS

[John Paul Adrian Glaubitz]

Source: pirs
Version: 2.0.2+dfsg-1
Severity: serious
Justification: fails to build from source
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

pirs fails to build from source on all non-x86 architectures because it
hard-wires compiler flags and tries to build with -msse2 despite the
fact that this is an x86-only compiler flag:

g++ -DHAVE_CONFIG_H -I. -I..  -DSFMT_MEXP=19937 
-DPKGDATADIR='"/usr/share/pirs"' -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-msse2  -fopenmp -g -O2 -fdebug-prefix-map=/<>/pirs-2.0.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o InputStream.o 
InputStream.cpp
g++: error: unrecognized command line option '-msse2'

Please adjust your debian/rules or patch the upstream build system
to use -msse2 on supported targets only.

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

Bug#846297: mesa-vdpau-drivers: breaks vdpau for mpeg2video with mpv and vlc

[Andreas Boll]

Hi,

please provide the output from dmesg and vdpauinfo. Furthermore the
Xorg log would be useful too.

Thanks,
Andreas

On Tue, Nov 29, 2016 at 10:47:18PM +0100, Jörg-Volker Peetz wrote:
> Package: mesa-vdpau-drivers
> Version: 13.0.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> on my AMD CPU/AMD GPU hybrid HP Pavilion notebook under X with radeon video
> driver the vdpau hardware video output for the mpeg2video codec broke 
> beginning
> with Mesa 13.0. Such videos are totally scrambled on the screen now.
> Codec h264 is still working.
> 
> What additional information is needed to help fix it?
> 
> Regards,
> jvp.
> 


signature.asc
Description: Digital signature

Bug#846279: ghc: Problems with Backspace, Delete and arrow keys

[Ilias Tsitsimpis]

Control: tags -1 + moreinfo

Hi Richard,

On Tue, Nov 29, 2016 at 07:59PM, Richard Smith wrote:
> Since upgrading to ghc 8.0.1, when trying to backspace user-entered text 
> (e.g. a getLine event) in a
> running haskell program (whether compiled with this version of ghc, or 
> interpreted), the terminal
> displays "^?" for backspace, "^[[3~" for delete and other codes for arrow 
> keys.

This is the indented behavior of getLine. It has always been like this,
and didn't change with ghc v8.0.1.

> It appears to be previously reported, and resolved, here: 
> https://ghc.haskell.org/trac/ghc/ticket/2606

Please see comments 19 to 22 from the above ticket. They describe how
getLine is supposed to work, and how to get the indented results using
haskeline instead.

Does the above resolve your issue?

-- 
Ilias

Bug#837092: The package description needs to be more clear

[Alex Bennée]

We were discussing this on IRC:

   chazy: on debian/ubuntu UEFI for arm64 is included in
  package qemu-efi
   suihkulokki: cool.  who did this work?
   chazy: the debian Qemu team :)
   suihkulokki: cool
   nice of them
   it's the same way seabios (for x86) and openbios (for
  sparc, ppc?) is done
   suihkulokki: yes, but people really care about their x86
  hardware ;)
  > suihkulokki: so the qemu-efi on my x86 box is the x86 efi build?
   ajb-linaro: no. qemu-efi on your x86 is for aarch64. EFI
  build for x86/qemu is in package ovmf
   I think this is confusing for me. I can't bear how
  confusing this is for people outside our field of expertise.
  > suihkulokki: maybe changing the package description to be a bit more
  explicit? If I run "file" on the blob I just get the magic "data"
  type ;-)

So I learnt the package is what I need for running aarch64 guests on my
x86 box. Perhaps the description could be tweaked to make this clearer?

--
Alex Bennée

Bug#846331: nvidia-graphics-drivers: CVE-2016-7382, CVE-2016-7389: missing permissions check and improper validation vulnerability

[Andreas Beckmann]

Source: nvidia-graphics-drivers
Severity: serious
Tags: security upstream
Control: clone -1 -2 -3
Control: reassign -2 nvidia-graphics-drivers-legacy-340xx
Control: reassign -3 nvidia-graphics-drivers-legacy-304xx
Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2016-7382, 
CVE-2016-7389: missing permissions check and improper validation vulnerability
Control: retitle -3 nvidia-graphics-drivers-legacy-304xx: CVE-2016-7382, 
CVE-2016-7389: missing permissions check and improper validation vulnerability
Control: close -1 367.57-1
Control: close -2 340.98-1
Control: close -3 304.132-1

http://nvidia.custhelp.com/app/answers/detail/a_id/4246

CVE-2016-7382

NVIDIA GPU Display Driver contains a vulnerability in the kernel mode
layer (nvidia.ko) handler where a missing permissions check may allow
users to gain access to arbitrary physical memory, leading to an
escalation of privileges.

CVE-2016-7389

NVIDIA GPU Display Driver on Linux contains a vulnerability in the
kernel mode layer (nvidia.ko) handler for mmap() where improper input
validation may allow users to gain access to arbitrary physical memory,
leading to an escalation of privileges.

Fixed versions:

R370370.28
R367367.55
R340340.98
R304304.132


Andreas

Bug#846143: suricata: enable optional Hyperscan support

[Arturo Borrero Gonzalez]

On 29 November 2016 at 15:13, Sascha Steinbiss  wrote:
> Hi Arturo,
>
> [...]
>>> I would be curious to learn what the maintainers' and community thoughts 
>>> are,
>>> and would appreciate any comments you might have.
>>>
>>
>> Just posted to debian-devel to give a bit of visibility to our issue.
>> I, as well, would like to get a bit of feedback from other fellow
>> developers to know if there is a better approach.
>
> Great, many thanks for this. Reading the post I'm not sure there may
> have been some misunderstanding about the approach I took in my
> diversion based version, so I'll send a quick follow up if that's OK.
>

I think the alternatives method discussed at debian-devel seems like
the way to go.

@Sascha, would you handle the change or should I work on it?

Bug#846334: cross-toolchain-base-ports: FTBFS in testing (2 out of 2 hunks FAILED)

[Santiago Vila]

Package: src:cross-toolchain-base-ports
Version: 7
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
linux: 4.8.7-1 / 4.8.7-1cross1
glibc: 2.24-5 / 2.24-5cross1

old linux version: 4.8.7-1 / 1
old glibc version: 2.24-5 / 1

new linux version: 4.8.7-1cross2
new glibc version: 2.24-5cross2
START stamp-dir/init-glibc
rm -rf glibc-2.24
tar -x -f  /usr/src/glibc/glibc-2.24.tar.xz
cp -a /usr/src/glibc/debian/ glibc-2.24
cd glibc-2.24 ; \
QUILT_PATCHES=/<>/debian/patches/glibc/debian quilt --quiltrc 
/dev/null push -a && \
rm -rf .pc/
Applying patch dpkg-shlibs.patch
patching file debian/rules.d/debhelper.mk
Hunk #1 succeeded at 81 (offset 2 lines).

Applying patch local-kill-locales.patch
patching file localedata/SUPPORTED

Now at patch local-kill-locales.patch
if dpkg --compare-versions 2.24-5 le 2.24-5; then \
  cd glibc-2.24; \
  patch -p1 < ../debian/patches/glibc/glibc-update.diff; \
fi
patching file iconv/gconv.h
patching file sysdeps/powerpc/powerpc32/power6/memset.S
patching file sysdeps/powerpc/powerpc64/power6/memset.S
cd glibc-2.24; \
patch -p1 < ../debian/patches/glibc/glibc-depends.diff
patching file debian/rules.d/debhelper.mk
touch stamp-dir/init-glibc
START stamp-dir/init-gcc
set -e; \
mkdir gcc -p ; \
cd gcc ; \
ln -sf /usr/src/gcc-6/gcc-6.2.0.tar.xz gcc-6.2.0.tar.xz ;\
cp -a  /usr/src/gcc-6/debian/ . ; \
if [ -n "$(grep -v '^\#' /<>/debian/patches/gcc/series)" ]; then \
  QUILT_PATCHES=/<>/debian/patches/gcc quilt --quiltrc /dev/null  
push -a ; \
fi;
if dpkg --compare-versions 6.2.0-13 le 6.2.1-4; then \
  cd gcc; \
  patch -p1 < ../debian/patches/gcc/gcc-stage1.diff; \
fi
patching file debian/rules.patch
Hunk #1 FAILED at 151.
Hunk #2 FAILED at 187.
2 out of 2 hunks FAILED -- saving rejects to file debian/rules.patch.rej
debian/rules:213: recipe for target 'stamp-dir/init-gcc' failed
make: *** [stamp-dir/init-gcc] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The relevant part of the build log is included above.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#846335: cross-toolchain-base: FTBFS in testing (2 out of 2 hunks FAILED)

[Santiago Vila]

Package: src:cross-toolchain-base
Version: 14
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
linux: 4.8.7-1 / 4.8.7-1cross1
glibc: 2.24-5 / 2.24-5cross1

old linux version: 4.8.7-1 / 1
old glibc version: 2.24-5 / 1

new linux version: 4.8.7-1cross2
new glibc version: 2.24-5cross2
START stamp-dir/init-glibc
rm -rf glibc-2.24
tar -x -f  /usr/src/glibc/glibc-2.24.tar.xz
cp -a /usr/src/glibc/debian/ glibc-2.24
cd glibc-2.24 ; \
QUILT_PATCHES=/<>/debian/patches/glibc/debian quilt --quiltrc 
/dev/null push -a && \
rm -rf .pc/
Applying patch dpkg-shlibs.patch
patching file debian/rules.d/debhelper.mk
Hunk #1 succeeded at 81 (offset 2 lines).

Applying patch local-kill-locales.patch
patching file localedata/SUPPORTED

Now at patch local-kill-locales.patch
if dpkg --compare-versions 2.24-5 le 2.24-5; then \
  cd glibc-2.24; \
  patch -p1 < ../debian/patches/glibc/glibc-update.diff; \
fi
patching file iconv/gconv.h
patching file sysdeps/powerpc/powerpc32/power6/memset.S
patching file sysdeps/powerpc/powerpc64/power6/memset.S
cd glibc-2.24; \
patch -p1 < ../debian/patches/glibc/glibc-depends.diff
patching file debian/rules.d/debhelper.mk
touch stamp-dir/init-glibc
START stamp-dir/init-gcc
set -e; \
mkdir gcc -p ; \
cd gcc ; \
ln -sf /usr/src/gcc-6/gcc-6.2.0.tar.xz gcc-6.2.0.tar.xz ;\
cp -a  /usr/src/gcc-6/debian/ . ; \
if [ -n "$(grep -v '^\#' /<>/debian/patches/gcc/series)" ]; then \
  QUILT_PATCHES=/<>/debian/patches/gcc quilt --quiltrc /dev/null  
push -a ; \
fi;
if dpkg --compare-versions 6.2.0-13 le 6.2.1-4; then \
  cd gcc; \
  patch -p1 < ../debian/patches/gcc/gcc-stage1.diff; \
fi
patching file debian/rules.patch
Hunk #1 FAILED at 151.
Hunk #2 FAILED at 187.
2 out of 2 hunks FAILED -- saving rejects to file debian/rules.patch.rej
debian/rules:213: recipe for target 'stamp-dir/init-gcc' failed
make: *** [stamp-dir/init-gcc] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The relevant part of the build log is included above.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#846297: mesa-vdpau-drivers: breaks vdpau for mpeg2video with mpv and vlc

[Jörg-Volker Peetz]

Hi,

please see the attached files.

Thanks for caring,
jvp.


Andreas Boll wrote on 11/30/16 11:56:
> Hi,
> 
> please provide the output from dmesg and vdpauinfo. Furthermore the
> Xorg log would be useful too.
> 
> Thanks,
> Andreas
> 



[0.00] Linux version 4.8.11 (root@uruz) (gcc version 6.2.1 20161119 
(Debian 6.2.1-4) ) #1 SMP Sat Nov 26 13:24:47 CET 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz root=PARTUUID=06434654-01 
ro pcie_aspm=force radeon.audio=1 radeon.dpm=1
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xce447fff] usable
[0.00] BIOS-e820: [mem 0xce448000-0xce647fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xce648000-0xcfd3efff] usable
[0.00] BIOS-e820: [mem 0xcfd3f000-0xcfdbefff] reserved
[0.00] BIOS-e820: [mem 0xcfdbf000-0xcfebefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfebf000-0xcfef5fff] ACPI data
[0.00] BIOS-e820: [mem 0xcfef6000-0xcfef] usable
[0.00] BIOS-e820: [mem 0xf700-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/1443, BIOS F.23 
11/11/2010
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x22 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask C000 write-back
[0.00]   2 base C000 mask F000 write-back
[0.00]   3 base FFE0 mask FFE0 write-protect
[0.00]   4 base 0001 mask  write-back
[0.00]   5 base 0002 mask E000 write-back
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00023000 aka 8960M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xcff00 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] BRK [0x01992000, 0x01992fff] PGTABLE
[0.00] BRK [0x01993000, 0x01993fff] PGTABLE
[0.00] BRK [0x01994000, 0x01994fff] PGTABLE
[0.00] BRK [0x01995000, 0x01995fff] PGTABLE
[0.00] BRK [0x01996000, 0x01996fff] PGTABLE
[0.00] BRK [0x01997000, 0x01997fff] PGTABLE
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FE020 24 (v02 HP)
[0.00] ACPI: XSDT 0xCFEF5120 5C (v01 HPQOEM SLIC-MPC 
0003  0113)
[0.00] ACPI: FACP 0xCFEF4000 F4 (v04 HP 1443 
0003 MSFT 0113)
[0.00] ACPI: DSDT 0xCFEE2000 00E0D7 (v01 HP 1443 
F000 MSFT 0113)
[0.00] ACPI: FACS 0xCFE9C000 40
[0.00] ACPI: FACS 0xCFE9C000 40
[0.00] ACPI: HPET 0xCFEF3000 38 (v01 HP 1443 
0001 MSFT 0113)
[0.00] ACPI: APIC 0xCFEF2000 84 (v02 HP 1443 
0001 MSFT 0113)
[0.00] ACPI: MCFG 0xCFEF1000 3C (v01 HP 1443 
0001 MSFT 0113)
[0.00] ACPI: BOOT 0xCFEE1000 28 (v01 HP 1443 
0001 MSFT 0113)
[0.00] ACPI: SLIC 0xCFEE 000176 (v01 HPQOEM SLIC-MPC 
0001 MSFT 0113)
[0.00] ACPI: SSDT 0xCFEDF000 00052A (v01 AMDPOWERNOW 
0001 AMD  0001)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] No NUMA configuration found
[0.00] F

Bug#844692: Upload in progress

[Raphael Hertzog]

On Wed, 30 Nov 2016, Mathieu Parent wrote:
> NB: The version is 23-nmu3, as my request on alioth to be part of the
> team has not been approved (yet).

I think you are wrong. I saw you on the list of admins in the project.
Alioth does not automatically send any notification when you are added.
:-(

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#846332: nvidia-graphics-drivers: CVE-2016-7382, CVE-2016-7389: missing permissions check and improper validation vulnerability

[Luca Boccassi]

On Wed, 30 Nov 2016 12:12:23 +0100 Andreas Beckmann  wrote:
> Source: nvidia-graphics-drivers
> Severity: serious
> Tags: security upstream
> Control: clone -1 -2 -3
> Control: reassign -2 nvidia-graphics-drivers-legacy-340xx
> Control: reassign -3 nvidia-graphics-drivers-legacy-304xx
> Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2016-7382, 
> CVE-2016-7389: missing permissions check and improper validation vulnerability
> Control: retitle -3 nvidia-graphics-drivers-legacy-304xx: CVE-2016-7382, 
> CVE-2016-7389: missing permissions check and improper validation vulnerability
> Control: close -1 367.57-1
> Control: close -2 340.98-1
> Control: close -3 304.132-1
> 
> http://nvidia.custhelp.com/app/answers/detail/a_id/4246
> 
> CVE-2016-7382
> 
> NVIDIA GPU Display Driver contains a vulnerability in the kernel mode
> layer (nvidia.ko) handler where a missing permissions check may allow
> users to gain access to arbitrary physical memory, leading to an
> escalation of privileges.
> 
> CVE-2016-7389
> 
> NVIDIA GPU Display Driver on Linux contains a vulnerability in the
> kernel mode layer (nvidia.ko) handler for mmap() where improper input
> validation may allow users to gain access to arbitrary physical memory,
> leading to an escalation of privileges.
> 
> Fixed versions:
> 
> R370  370.28
> R367  367.55
> R340  340.98
> R304  304.132
> 
> 
> Andreas

This sounds nasty!

Do we need to upload 340.98 to stable security?

-- 
Kind regards,
Luca Boccassi


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

Bug#795052: sleuthkit: Uses embedded copy of libexif-0.6.20

[Eriberto Mota]

2015-08-09 20:58 GMT-03:00 Scott Kitterman :
> Source: sleuthkit
> Version: 4.1.3-11
> Severity: normal
>
> Although not a must in Debian policy, the preference is to not use embedded
> copies of libraries.  sleuthkit-4.1.3/framework/modules/c_LibExifModule has
> an embedded copy of libexif-0.6.20 that is used during package build.  It
> would be better to use the system libexif.

Control: tags 795052 moreinfo


Hi Scott,

I packaged the 4.3.1 version now. I did some checks and I saw that the
upstream does not use this library.

1. Via grep, I can not see a call for the library in main program. I
think that the upstream uses the directory to generate, manually,
files for MS Windows.

2. Removing the directory framework/modules/c_LibExifModule, the
package builds fine. The config.log and sleuthkit_4.3.1-1_amd64.build
don't show any call to libexif.

I thing this bug can be closed. What is your oppinion?

Thanks for your message.

Cheers,

Eriberto

Bug#846333: nvidia-graphics-drivers: CVE-2016-7382, CVE-2016-7389: missing permissions check and improper validation vulnerability

[Luca Boccassi]

On Wed, 30 Nov 2016 12:12:23 +0100 Andreas Beckmann  wrote:
> Source: nvidia-graphics-drivers
> Severity: serious
> Tags: security upstream
> Control: clone -1 -2 -3
> Control: reassign -2 nvidia-graphics-drivers-legacy-340xx
> Control: reassign -3 nvidia-graphics-drivers-legacy-304xx
> Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2016-7382, 
> CVE-2016-7389: missing permissions check and improper validation vulnerability
> Control: retitle -3 nvidia-graphics-drivers-legacy-304xx: CVE-2016-7382, 
> CVE-2016-7389: missing permissions check and improper validation vulnerability
> Control: close -1 367.57-1
> Control: close -2 340.98-1
> Control: close -3 304.132-1
> 
> http://nvidia.custhelp.com/app/answers/detail/a_id/4246
> 
> CVE-2016-7382
> 
> NVIDIA GPU Display Driver contains a vulnerability in the kernel mode
> layer (nvidia.ko) handler where a missing permissions check may allow
> users to gain access to arbitrary physical memory, leading to an
> escalation of privileges.
> 
> CVE-2016-7389
> 
> NVIDIA GPU Display Driver on Linux contains a vulnerability in the
> kernel mode layer (nvidia.ko) handler for mmap() where improper input
> validation may allow users to gain access to arbitrary physical memory,
> leading to an escalation of privileges.
> 
> Fixed versions:
> 
> R370  370.28
> R367  367.55
> R340  340.98
> R304  304.132
> 
> 
> Andreas
>

This is a fun one... the choice for Jessie and oldstable-backports is
either to keep the vulnerable 304.131 or get the completely and utterly
broken 304.132...

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

-- 
Kind regards,
Luca Boccassi


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

Bug#846338: Add Xsession.d script for desktop integration.

[Alexander Larsson]

Package: flatpak

As discussed on irc and in 
https://lists.freedesktop.org/archives/xdg-app/2016-October/000455.html
it seems that at least ubuntu yakkety needs a script similar to
/etc/X11/Xsession.d/65snappy to properly get XDG_DATA_DIRS set prior to
unity being launched.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a globe-trotting soccer-playing messiah who knows the secret of the 
alien invasion. She's a cold-hearted psychic vampire with someone else's 
memories. They fight crime! 

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Laurent Bigonville]

On Fri, 13 Nov 2015 17:03:46 +0100 Laurent Bigonville  
wrote:

> On Sun, 29 Mar 2015 05:30:23 +0200 m...@linux.it (Marco d'Itri) wrote:
> > On Jul 26, Laurent Bigonville  wrote:
> >
> > > Do you think that it could be possible to copy 70-uaccess.rules and
> > > 71-seat.rules (and maybe 73-seat-late.rules) in the initramfs?
> > Adding 70-uaccess.rules is easy, but 71-seat.rules runs some programs
> > like loginctl which is not available in the initramfs.
> > Maybe we need a simpler rules file just for the initramfs?
> > Is this change still needed?
> > What do other distributions do about this?
>
> Still would be nice to have yes.
>
> I see two RUN in the 71-seat.rules and the loginctl one is used to lock
> the session in case a keylogger is inserted while the machine is booted,
> is it a problem if the command fails? The other one is udevadm, isn't
> this one already in the initramfs?
>
> Looking at fedora, I see that they are copying the following rules:
>
> inst_rules \
> 70-uaccess.rules \
> 71-seat.rules \
> 73-seat-late.rules \
> 90-vconsole.rules \
> 99-systemd.rules
>
> but indeed they are also installing the loginctl apparently (and
> systemd-sysctl for 99-systemd.rules).

What could be done here?

Is it a problem if loginctl is not present in the initramfs? Would the 
rule be executed later in the boot again?


Same question for systemd-sysctl. Couldn't that one be added in the 
initramfs?

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

Le 30/11/2016 à 00:20, Markus Koschany a écrit :

> rm -rf /etc/tomcat8
> 
> I mean purge means purge. Remove all files, don't leave anything behind.

That's tempting but I wonder if we aren't missing something.

Other packages are installing things under /etc/tomcat8, for example
solr-tomcat and jspwiki, but fortunately in these cases the packages are
installing symlinks to other configuration files, and by the time
tomcat8 is purged these links have already been removed.

Is there another case where removing the files in /etc/tomcat8 is
undesirable? What about files created by the sysadmin in this directory
(like the ones we avoided to chmod on upgrades in #825786) ?


> As another improvement suggestion for Tomcat 9, we could stop deleting
> the tomcat user on purge and let the admin decide. I believe this is
> even consensus within the project and will protect against reusing files
> with the old GID and UID for something unintended.

I thought the users created by a package were supposed to be removed
when the package is purged, but this isn't a requirement in the policy.
I've found #621833 that deals with this topic and the consensus is
indeed not to remove the user.

If we follow the consensus I would also suggest reusing the same user
when switching to a new version to Tomcat. The last time I switched from
tomcat7 to tomcat8 it was annoying to chmod manually the log files of my
web applications. If there was a unique tomcat user for the
tomcat{7,8,9} package that would be easier.

This would be similar to the jetty8 and jetty9 packages sharing the same
'jetty' user (but in this case the user is also removed when the package
is uninstalled, this is problematic when the old package is removed
after the new one is installed).

Emmanuel Bourg

Bug#845193: [Pkg-openssl-devel] Bug#845193: dpkg: recent -specs PIE changes break openssl

[Thorsten Glaser]

Kurt Roeckx dixit:

>So can someone explain what needs to be fixed in openssl? The
>order of the CFLAGS needs to be changed?

Unfortunately, I have no idea; 1.1 builds, 1.0 doesn’t.

If you have an amd64 host (recent enough but not kernel 4.7)
you can add syscall.x32=y to GRUB_CMDLINE_LINUX and then use
your favourite out of pbuilder/cowbuilder/sbuild to try things
in an x32 chroot.

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#846339: ITP: golang-github-weaveworks-mesh -- go library to build distributed systems

[Martín Ferrari]

Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-github-weaveworks-mesh
  Version : 0+git20161024.3dd75b1
  Upstream Author : Weaveworks Ltd.
* URL : https://github.com/weaveworks/mesh
* License : Apache-2.0
  Programming Lang: go
  Description : go library to build distributed systems

 Mesh implements a gossip protocol that provide membership, unicast, and
 broadcast functionality with eventually-consistent semantics. In CAP terms, it
 is AP: highly-available and partition-tolerant.
 .
 Mesh works in a wide variety of network setups, including thru NAT and
 firewalls, and across clouds and datacenters. It works in situations where
 there is only partial connectivity, i.e. data is transparently routed across
 multiple hops when there is no direct connection between peers. It copes with
 partitions and partial network failure. It can be easily bootstrapped,
 typically only requiring knowledge of a single existing peer in the mesh to
 join. It has built-in shared-secret authentication and encryption. It scales
 to on the order of 100 peers, and has no dependencies.

This package is a dependency for prometheus-alertmanager.

Bug#846340: ITP: mlv -- Simplified multimedia library in C for beginners

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: mlv
  Version : 2.0.2
  Upstream Author : Adrien Boussicault and Marc Zipstein
* URL : http://www-igm.univ-mlv.fr/~boussica/mlv/index.html
* License : GPL
  Programming Lang: C
  Description : Simplified multimedia library in C for beginners


The mlv library is a simplified multimedia library.
The library is perfect for beginners in C programming who
want to use graphic and sound effects.
The library permit to:
 - draw figures, text and boxed text,
 - display images,
 - plays musics,
 - get Keyboard and mouse event,
 - get data by input boxes.
This tools is a simplified interface of the SDL libraries.
If you are not a beginner, we recommend you to use the 
SDL libraries (sdl, sdl-gfx, sdl-mixer,sdl-ttf) instead of
the mlv library.

Bug#845417: Cannot activate service check. The process status engine was disabled.

[Martin Sebald]

Hello Sergey,

sorry, I did not know that I have to build the package from the dsc file myself.

I just built the package and installed it. This time I was able to start Monit
with my config file.

The bug is fixed. Thank you! :-)

Cheers,
Martin

Bug#835049: (no subject)

[Marcos Mobley]

one bug (not really fixed but caught) upstream (in git but not released)
http://dev.deluge-torrent.org/ticket/2942#comment:5



signature.asc
Description: OpenPGP digital signature

Bug#846297: mesa-vdpau-drivers: breaks vdpau for mpeg2video with mpv and vlc

[Andreas Boll]

Control: tags -1 + upstream

Hi,

please report this upstream to
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa&component=Drivers%2FGallium%2Fr600
and let us know the bug number for tracking.

Thanks,
Andreas

On Wed, Nov 30, 2016 at 12:19:34PM +0100, Jörg-Volker Peetz wrote:
> Hi,
> 
> please see the attached files.
> 
> Thanks for caring,
> jvp.
> 
> 
> Andreas Boll wrote on 11/30/16 11:56:
> > Hi,
> > 
> > please provide the output from dmesg and vdpauinfo. Furthermore the
> > Xorg log would be useful too.
> > 
> > Thanks,
> > Andreas
> > 


signature.asc
Description: Digital signature

Bug#846143: suricata: enable optional Hyperscan support

[Sascha Steinbiss]

Hi Arturo,

[...]
>>> Just posted to debian-devel to give a bit of visibility to our issue.
>>> I, as well, would like to get a bit of feedback from other fellow
>>> developers to know if there is a better approach.
>>
>> Great, many thanks for this. Reading the post I'm not sure there may
>> have been some misunderstanding about the approach I took in my
>> diversion based version, so I'll send a quick follow up if that's OK.
> 
> I think the alternatives method discussed at debian-devel seems like
> the way to go.

I agree.

> @Sascha, would you handle the change or should I work on it?

I don't mind doing it, if it can wait until tomorrow.

Cheers
Sascha

Bug#816739: rsyslog-gnutls: imtcp/TLS hangs on dropped packages

[Michael Biebl]

On Tue, 17 May 2016 06:28:50 +0200 Michael Biebl  wrote:
> On Thu, 10 Mar 2016 17:23:50 +0100 Luca BRUNO  wrote:
> > On Wednesday, March 09, 2016 09:09:42 PM you wrote:
> > 
> > > I don't have the setup to test this. So if you want to see this fixed in
> > > stable, it would be great if you can apply the upstream fix on top of
> > > 8.4.2 and test whether it actually fixes the issue.
> > 
> > I have this running live in a log aggregation center, but unfortunately 
> > reproducing this is somehow non-deterministic (it randomly happens from 
> > time 
> > to time, after several weeks that it is running under moderate load, 
> > without 
> > simple triggers).
> > 
> > I have now applied this patch on top of 8.4.2-1+deb8u2, and I'll let it run 
> > for some time in the environment above to check if it still deadlocks 
> > (however 
> > I can't exclude false negatives if the bug doesn't trigger).
> 
> Any updates?

Ping

-- 
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#846164: dpkg-dev: Have dpkg-genchanges support a source+buildinfo-only upload

[Ximin Luo]

Guillem Jover:
> On Mon, 2016-11-28 at 22:00:32 +0100, Ximin Luo wrote:
>> It would be good to be able [..]
>> to do a binary build locally, but only upload the source package
>> *and* the buildinfo file.
> 
> This was the intention from the beginning. But when I mentioned this
> on IRC the other day, Ansgar said ftp-masters might not be too happy
> about accepting buildinfo files referencing artifacts that we might
> not be able to generated. Because there's no distinction between
> packages that are reproducible and ones that are not.
> 
>> This was one idea we had near the beginning of the R-B project. The
>> idea being developers could do this, then the buildds could try to
>> match what they built, as an extra check. Another advantage is that
>> the upload itself would be reduced in size.
> 
> Those are the reasons I gave to Ansgar, but I'd like his and
> ftp-masters input on this.
> 

OK, hopefully I can also argue in favour of it:

Indeed there's no distinction between packages that are reproducible, vs ones 
that are not. But this is the case even if we don't have source+buildonly-only 
uploads, and stick to binary or source-only uploads as in the current situation.

That is - if ftp-masters don't accept source+buildinfo-only uploads, and only 
allow source-only uploads, then there's *already* no indication whether the 
package is reproducible or not. People can certainly upload unreproducible 
packages and these would be accepted into the archive today.

What source+buildinfo-only .changes files do is, it allows the archive 
infrastructure to attempt a reproduction itself, since it has some knowledge of 
the result is "supposed" to be. If the reproduction fails, then it can either:

1. accept the upload (the current behaviour)
2. accept the upload but warn the uploader that it was unreproducible, and that 
the actually-built binaries are being used instead
3. reject the upload

I guess (3) would require much much more changes to the archive infrastructure 
and we're not even sure if we want that. However (2) would also be a 
significant improvement towards reproducibility, and is feasible to achieve - 
this wishlist feature being the first steps towards achieving that.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Tue, Nov 29, 2016 at 02:00:48PM +0100, Matthias Klose wrote:
> On 28.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:

> > Which apparently changed at some point in the toolchain, probably quite
> > some time ago, but fortunately we'd actually managed to remove all the
> > users before that happened so it didn't affect anyone.

> Wrong. Until the zconf.h header was moved from /usr/include to
> /usr/include/ these packages found the *wrong* header in
> /usr/include, now they don't find anything anymore.

So that'll be what changed.  But really this is a bug in the multiarch
support, zconf.h isn't at all architecture specific within the context
of Debian (there's a few things that change but they're all related to
completely non-Unix OSs).

> > Right now as far as I can tell there's been some change in the GNU D
> > compiler that's attempting to add usage of the multilib zlib versions
> > for some reason which is not at all clear to me.  You said something
> > about moving the GDC runtime to a shared library but I'm finding that
> > confusing as the issue with the header file as should also affect static
> > usage so it seems like there must be something else in the mix
> > somewhere.

> The libphobos configury falls back to the zlib copy shipped within the GCC
> sources, when the system zlib cannot be used. So sure, dropping the build
> dependencies on the multilib zlib packages does use the embedded copy, but
> that's not what you usually want to do.

OK, so this makes at least that part of things clearer.  It's not a
result of linking against the DSO but rather a result of not using an
embedded copy of the source.

> > It seems there's also something going on with x32 but as far as I can
> > tell that's orthogonal though it does seem to be related to changes in
> > GDC as well somehow.

> that's just the third multilib on amd64 and i386.

Well, there's a bunch of questions there - people seem generally
negative on x32 and the use cases for multilib with tooling for early
boot and so on don't seem to apply in any case.  I'd really have
expected that it'd just be added as a new architecture at this point.

> > Shouldn't people building i386 D programs on amd64 (or other similar
> > builds that would historically have been done with multilib) just be
> > using multiarch to install the 32 bit runtime?  Please bear in mind
> > that I'm not at all familiar with D here.

> there's nothing you need to understand with D, just that it tries to use zlib 
> as
> a dependency.

No, it's trying to use a multilib zlib as a dependency.  That's still
really unclear to me here - to repeat my question above why aren't we
asking people who want to build non-native D applications to just
install the multiarch runtime?  The motivation I'm aware of for still
having the multilib packages is to allow other multilib packages to be
built with them but I'm not seeing any packages written in D (and it'd
be pretty surprising TBH given the narrow use case) so I'm not seeing
the use case.

> So removing these packages is fine with me too; in this case, please wait with
> the removal and I'll prepare a new source package to build these multilib
> libraries for the stretch release.

No, that's obviously not a good solution as it just ends up duplicating
the source.


signature.asc
Description: PGP signature

Bug#729582: Should recommen 8514 as tls port

[Michael Biebl]

Am 18.03.2014 um 21:27 schrieb Guido Günther:
> On Tue, Mar 18, 2014 at 07:01:18PM +0100, Rainer Gerhards wrote:
>> On Tue, Mar 18, 2014 at 4:56 PM, Michael Biebl  wrote:
>>
>>> Am 14.11.2013 16:23, schrieb Guido Günther:
 Package: rsyslog-gnutls
 Severity: wishlist

 Hi,
 It seems we currently doesn't make any recommendations concerning ports
 for syslog-tls usage. RFC 5425 uses 8514 - should we add something like
 this as a (commented out) rsyslog.d/tls snippet?
>>>
>>> Makes sense, I guess. That said, looking at my /etc/services, I get
>>> syslog-tls  6514/tcp   # Syslog over TLS [RFC5425]
>>>
>>>
>> I just checked, 6514 is the iana-assigned one [1]. Where have you seen 8514?
> 
> Typo on my end. 6514 is correct. I got that correct in 

I guess it would make the most sense, if this was fixed in the
documentation, specifically

http://www.rsyslog.com/doc/v8-stable/tutorials/tls.html
to recommend 6514 instead of 10514.
More specifically in
tutorials/tls.rst
tutorials/tls_cert_server.rst
tutorials/tls_cert_client.rst
tutorials/tls_cert_udp_relay.rst

Rainer, any other places I missed?


-- 
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#836983: arm64 too

[Frederic Bonnard]

Just for the record, this bug also happens on arm64.
This seems to be a regression. I'm trying to bisect that.


F.

Bug#846341: dh-make-golang: issue with DEBEMAIL

[Félix Sipma]

Package: dh-make-golang
Version: 0.0~git20161120.0.71f5e23-1
Severity: normal

When I use dh-make-golang I get:

Félix Sipma >

everywhere my address is needed. DEBEMAIL is set to

Félix Sipma 


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

Kernel: Linux 4.8.0-1-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-make-golang depends on:
ii  git   1:2.10.2-3
ii  git-buildpackage  0.8.7
ii  golang-go 2:1.7~3
ii  libc6 2.24-7
ii  pristine-tar  1.37

Versions of packages dh-make-golang recommends:
ii  postfix [mail-transport-agent]  3.1.3-4

dh-make-golang suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#846342: ITP: capstone -- lightweight multi-architecture disassembly framework

[Pranith Kumar]

Package: wnpp
Severity: wishlist
Owner: Pranith Kumar 

* Package name: capstone
  Version : 4.0
  Upstream Author : Nguyen Anh Quynh 
* URL : http://www.capstone-engine.org/
* License : NCSA
  Programming Lang: C++, Python
  Description : lightweight multi-architecture disassembly framework

Capstone is a disassembly framework with the target of becoming the ultimate
disasm engine for binary analysis and reversing in the security community.

I contribute to the upstream repository and would like to maintain it in
Debian. I need a sponsor.

-- 
Pranith

Bug#846343: protobuf FTCBFS: lots of issues

[Helmut Grohne]

Source: protobuf
Version: 3.0.0-9
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

protobuf fails to cross build from source for a variety of different
reasons:

 * Its dependency on g++ is unsatisfiable, because the host architecture
   g++ is requested and it conflicts with the build architecture g++
   requested by build-essential. In a distant future, you'd replace it
   with "g++-for-host (>= ...)", but for now that doesn't work.
   Thankfully, the dependency is satisfied in oldstable and can be
   removed.
 
 * Likewise the python-all and python3-all dependencies request Python
   for the host architecture. Installation of these packages simply
   fails in postinst (byte compilation). protobuf really wants to
   execute Python during build, so it should be requesting them for the
   build architecture (i.e. annotate those dependencies with :any).

 * python-google-apputils is Architecture: all and (implicitly)
   Multi-Arch: no. Thus it can never satisfy cross Build-Depends.
   Thankfully, it is nowhere used by protobuf anymore. The dependency
   can simply be dropped.

 * The build tries to run the compiled binary protoc. That fails,
   because protoc is compiled for the host architecture. Upstream
   advises that cross builds should pass --with-protoc=path/to/protoc.

 * After the build, protoc is used by generate_descriptor_proto.sh to
   regenerate sources. Of course, it cannot do that after a cross build.
   I propose doing the first build pass for the build architecture and
   then running generate_descriptor_proto.sh. When performing a cross
   build, another build passing --with-protoc is performed.

 * The python extension build is totally unaware of cross compilation.
   Setting the right environment variables solves that part.

 * Even then, due to bug #846326 in python2.7, the python2 extension
   build uses the build architecture linker. Explicitly overriding CXX
   fixes that as well.

The attached patch addresses all of the listed issues. After applying
it, protobuf cross builds successfully to e.g. arm64. Please consider
applying it even though it got a bit lengthy.

Helmut
--- protobuf-3.0.0/debian/changelog
+++ protobuf-3.0.0/debian/changelog
@@ -1,3 +1,18 @@
+protobuf (3.0.0-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Remove unused Build-Depends g++ (satisfied in oldstable) and
+  python-google-apputils.
++ Annotate python Build-Depends with :any
++ Run generate_descriptor_proto.sh on a native build before performing
+  the actual cross build
++ Save the native protoc in debian/native_protoc/ and pass it to the
+  cross build via --with-protoc
++ Set up environment variables for cross building python extensions
+
+ -- Helmut Grohne   Wed, 30 Nov 2016 12:58:07 +0100
+
 protobuf (3.0.0-9) unstable; urgency=medium
 
   * Backport upstream fix for Python 3 build failure (closes: #845686).
--- protobuf-3.0.0/debian/clean
+++ protobuf-3.0.0/debian/clean
@@ -1 +1,2 @@
 protoc.1
+debian/native_protoc/
--- protobuf-3.0.0/debian/control
+++ protobuf-3.0.0/debian/control
@@ -13,19 +13,17 @@
  , debhelper (>= 9)
  , dh-autoreconf
 # C/C++
- , g++ (>= 4:4.7)
  , zlib1g-dev
  , google-mock
  , libgtest-dev
 # Python
  , dh-python
- , python-all (>= 2.7)
+ , python-all:any (>= 2.7)
  , libpython-all-dev (>= 2.7)
- , python3-all (>= 3.3)
+ , python3-all:any (>= 3.3)
  , libpython3-all-dev (>= 3.3)
  , python-setuptools
  , python3-setuptools
- , python-google-apputils
  , python3-six
 # Manpage generator
  , xmlto
--- protobuf-3.0.0/debian/rules
+++ protobuf-3.0.0/debian/rules
@@ -1,9 +1,25 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CXX),default)
+CXX := $(DEB_HOST_GNU_TYPE)-g++
+endif
+
 %:
dh $@ --with autoreconf,python2,python3 --parallel
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+override_dh_auto_configure:
+   dh_auto_configure -- --host=$(DEB_BUILD_GNU_TYPE)
+
+PYTHON_CROSS_VARS += PROTOC=$(CURDIR)/debian/run_protoc
+PYTHON_CROSS_VARS += PYTHONPATH=/usr/lib/python$$pv/plat-$(DEB_HOST_MULTIARCH)
+PYTHON_CROSS_VARS += 
_PYTHON_HOST_PLATFORM=$(DEB_HOST_ARCH_OS)-$(DEB_HOST_GNU_CPU)
+# work around #846326:
+PYTHON_CROSS_VARS += CXX=$(CXX)
+endif
+
 override_dh_auto_build-arch:
 ## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
 ## be built. First we build it normally; then "generate_descriptor_proto.sh"
@@ -12,13 +28,27 @@
dh_auto_build --arch
bash -x ./generate_descriptor_proto.sh
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   # save the compiler
+   cp -Rv src/.libs debian/native_protoc
+   # clean everything but regenerated .pb.{cc,go} files
+   $(MAKE) clean
+   # cross build
+   dh_auto_configure -- --with-protoc=$(CURDIR)/debian/run_protoc
+   dh_auto_build --arch
+endif
+
# Generate the manpage.
xmlto man debian/protoc.xml
 
# P

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

Hi Paul,

Le 23/11/2016 à 01:46, paul.sz...@sydney.edu.au a écrit :

> Might protect against "static" things, but vulnerable to a race.

I'm not sure to understand, what kind of race could happen here?


> But really... why do you care about leaving some "dangling" useless
> object, owned by some long-gone UID or GID?

I don't know the motivations behind this complexity. I can imagine a
case where an administrator switches from tomcat8 to tomcat9 and doesn't
expect the old package to remove files unknown to him so they can be
moved to the configuration directory of the new package.

The upgrade scenario could look like this:

1. Install tomcat8
2. Declare a web application in /etc/tomcat8/Catalina/localhost
3. Uninstall tomcat8
4. Install tomcat9
5. Move /etc/tomcat8/Catalina/localhost/* to /etc/tomcat9/Catalina/localhost

If the step 3 also removes the webapp configuration the administrator is
going to be angry (but arguably less than having his system hacked).

Emmanuel Bourg

Bug#844240: Intent to not ship squirrelmail with stretch

[Thijs Kinkhorst]

On Mon, November 28, 2016 13:56, Scott Kitterman wrote:
> On Sun, 13 Nov 2016 18:31:48 +0100 Thijs Kinkhorst 
> wrote:
>> Package: squirrelmail
>> Severity: serious
>>
>> SquirrelMail has been missing from Stretch for a while now and I intend
>> to leave it that way. This bug is to document this explicit choice (and
>> room for any concerns).
>>
>> Upstream (of which I'm, at least on paper) part, has not made any new
>> release of SquirrelMail since 2011. There is some activity in commits
>> being done, but these do not result in releases.
>>
>> I've tried to work around this temporarily by packaging a snapshot of
>> upstream svn, but I'm not happy with that since this is an arbitrary
>> point in development and not a clear and tested release which we should
>> ship and support for years. Popcon for squirrelmail is significant but
>> shows a steady decline since 2010.
>>
>> Alternatives are availbale. There's the competing product roundcube
>> which is actively maintained in Debian and shows a steady popcon
>> increase. Another alternative is to install SquirrelMail from source
>> which is very easy and makes it easier to e.g. keep up with commits or
>> newer snapshots. The added value of a Debian package for squirrelmail is
>> hence not immense in my opinion.
>>
>> Of course this is not to pass any judgement value or to try to
>> discourage others from working on this package. I welcome any thoughts
>> in this bug report, or interest in putting the work into a sustainable
>> Debian package of squirrelmail.
>
> Squirrelmail is one of the blockers to php5 removal (See #846069).  Please
> comment on that bug about how we can keep squirrelmail, but still get rid
> of php5 (personally, I don't see how).

If PHP 5 is gone I see no reason to keep squirrelmail in unstable in its
current form. So we should remove it (as per #846069).


Cheers,
Thijs

Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

Le 22/11/2016 à 23:35, Paul Szabo a écrit :

> Then if the tomcat8 package is removed (purged?), the postrm script runs
>   chown -Rhf root:root /etc/tomcat8/
> and that will leave the file world-writable, setgid root

What about switching the files left to nobody:nogroup instead of
root:root? That would be less disruptive for the stable and oldstable
updates than removing /etc/tomcat8 completely.

Emmanuel Bourg

Bug#846069: RM: squirrelmail -- RoQA; RC-buggy; little upstream activity

[Thijs Kinkhorst]

On Mon, November 28, 2016 15:19, Scott Kitterman wrote:
> On Monday, November 28, 2016 02:45:29 PM Ondřej Surý wrote:
>> according to the upstream, the SVN snapshot is supposed to support PHP
>> 7.0, but it seems to be untested even by upstream (well, that's what I
>> am reading on the mailing list). One way or another, I agree with Thijs
>> that random SVN snapshot isn't really suited to be supported for next
>> stable cycle.
>>
>> Also I would like you to know that I am trying to properly investigate
>> all the options before filling RM bugs. So far the most common case is:
>> "last release in ~2011-2014 - added support for PHP 5.4/5.5" :(.
>
> Certainly.  I'm not at all meaning to call in to question your efforts.
> In this particular case it was pointed out to me that the maintainer had
> recently expressed a preference for keeping squirrelmail in unstable.
> While I don't think that's very sustainable, I'd prefer to get agreement
> where a php5 rdepend maintainer has expressed a preference.

As the maintainer you have my OK to remove squirrelmail from unstable.


Cheers,
Thijs

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Martin Pitt]

Laurent Bigonville [2016-11-30 12:58 +0100]:
> Is it a problem if loginctl is not present in the initramfs? Would the rule
> be executed later in the boot again?

Yes, the rules are being executed on all devices later on, though
systemd-udev-trigger.service (usually dubbed "coldplugging").

IMHO putting logind into the initrd would just be plain wrong and
bloat. That is not the initrd's job.

That said, adding only 71-seat.rules to the initrd seems okay to me,
even though it smells like a workaround. Is that sufficient for
plymouth's needs?

> Same question for systemd-sysctl. Couldn't that one be added in the
> initramfs?

Please not. It already gets run during boot, so it's again just
redundant and bloat for the initrd stage.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#846330: fix pending

[Ghislain Vaillant]

control: tags -1 pending

I have pushed a tentative fix on a staging branch. I have yet to 
validate it on debomatic.


Ghis

Bug#846344: ITP: libdata-treedumper-oo-perl -- Object-oriented interface to Data::TreeDumper

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libdata-treedumper-oo-perl
  Version : 0.09
  Upstream Author : Nadim Khemir 
* URL : https://metacpan.org/release/Data-TreeDumper-OO
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Object-oriented interface to Data::TreeDumper

This Perl module provides an object-oriented interface for
displaying Perl data structures and objects in a format that is
hopefully easier to read than the one produced by the standard
Perl Data::Dumper module.

I intend to maintain this module within the Debian Perl group.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#844444: [Pkg-privacy-maintainers] Bug#844444: parcimonie: should depend on gnupg1-curl (and obsolete gnupg-curl only as fallback)

[Axel Beckert]

Control: severity -1 important

Hi,

Daniel Kahn Gillmor wrote:
> On Wed 2016-11-16 03:42:14 +0900, Jonas Smedegaard wrote:
> > Package: parcimonie
> > Version: 0.10.2-4
> > Severity: serious
> > Justification: Policy 3.5
> >
> > parcimonie depends on gnupg-curl, but that package is no longer available
> > in the Debian unstable archive.
> 
> parcimonie does *not* depend on gnupg-curl, it Recommends: gnupg-curl.

This...

> > I guess the best would be if parcimonie could be adapted to the
> > interfaces provided by gnupg 2.x, but as a short-term workaround it
> > seems a fix would be to change to instead depend on gnupg-curl.
> 
> it does support gnupg 2.x.  please do not make it resort to gnupg1.

... together with this makes this issue definitely
non-release-critical. Hence downgrading the severity.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#846345: elfutils: Fix crash when adding sections to empty ELF files

[John Ogness]

Package: elfutils
Version: 0.166-2.2
Severity: normal
Tags: patch

Dear Maintainer,

Version 0.166 will crash if sections are added to an empty ELF
file. This problem has been fixed in the released upstream version
0.167. The exact commit that fixes the problem is here [0].

A new tool [1] has been submitted for inclusion in Debian that would
like to add sections to empty ELF files. This tool tests
_ELFUTILS_VERSION to make sure it is at least 167 before activating the
feature. Since this tool will most likely be available for stretch, it
would be nice if 0.167 of the elfutils was also in stretch (rather than
just patching 0.166).

Therefore, I am requesting that elfutils moves to the new upstream
version 0.167.

I have attached a diff against the 0.166-debian directory to allow
version 0.167 to be built. Hopefully this will help you. However, I was
unsure how to handle the m68k_backend.diff patch since version 0.167
provides an m68k backend and this differs from the one implemented in
the Debian patch. My diff ignores m68k_backend.diff, which is most
likely not what you want.

John Ogness

[0] 
https://git.fedorahosted.org/cgit/elfutils.git/commit/?id=96e140f6687922606657a76f185a73cf47908ef2
[1] https://lists.debian.org/debian-devel/2016/09/msg00224.html

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages elfutils depends on:
ii  libasm1 0.166-2.2
ii  libc6   2.24-5
ii  libdw1  0.166-2.2
ii  libelf1 0.166-2.2
ii  libstdc++6  6.2.0-13

elfutils recommends no packages.

elfutils suggests no packages.

-- no debconf information

diff -Nru elfutils-0.166/debian/changelog elfutils-0.167/debian/changelog
--- elfutils-0.166/debian/changelog	2016-10-18 07:13:34.0 +
+++ elfutils-0.167/debian/changelog	2016-11-30 12:17:52.050276511 +
@@ -1,3 +1,9 @@
+elfutils (0.167-1) unstable; urgency=medium
+
+  * New upstream.
+
+ -- John Ogness   Wed, 30 Nov 2016 13:04:21 +0100
+
 elfutils (0.166-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru elfutils-0.166/debian/libdw1.symbols elfutils-0.167/debian/libdw1.symbols
--- elfutils-0.166/debian/libdw1.symbols	2016-01-11 20:45:33.0 +
+++ elfutils-0.167/debian/libdw1.symbols	2016-11-30 12:17:52.050276511 +
@@ -18,4 +18,5 @@
  *@ELFUTILS_0.160 0.160
  *@ELFUTILS_0.161 0.161
  *@ELFUTILS_0.165 0.165
+ *@ELFUTILS_0.167 0.167
  *@ELFUTILS_0 0.126
diff -Nru elfutils-0.166/debian/patches/hppa_backend.diff elfutils-0.167/debian/patches/hppa_backend.diff
--- elfutils-0.166/debian/patches/hppa_backend.diff	2015-12-26 20:35:48.0 +
+++ elfutils-0.167/debian/patches/hppa_backend.diff	2016-11-30 12:17:52.050276511 +
@@ -722,28 +722,28 @@
 +extern int parisc_return_value_location_64(Dwarf_Die *, const Dwarf_Op **locp);
 +
 +#endif
-Index: elfutils-0.164/backends/Makefile.am
+Index: elfutils-0.167/backends/Makefile.am
 ===
 elfutils-0.164.orig/backends/Makefile.am
-+++ elfutils-0.164/backends/Makefile.am
-@@ -33,11 +33,12 @@ AM_CPPFLAGS += -I$(top_srcdir)/libebl -I
+--- elfutils-0.167.orig/backends/Makefile.am
 elfutils-0.167/backends/Makefile.am
+@@ -33,12 +33,12 @@ AM_CPPFLAGS += -I$(top_srcdir)/libebl -I
  
  
  modules = i386 sh x86_64 ia64 alpha arm aarch64 sparc ppc ppc64 s390 \
--	  tilegx
-+	  tilegx parisc
+-	  tilegx m68k bpf
++	  tilegx m68k bpf parisc
  libebl_pic = libebl_i386_pic.a libebl_sh_pic.a libebl_x86_64_pic.a\
  	 libebl_ia64_pic.a libebl_alpha_pic.a libebl_arm_pic.a\
  	 libebl_aarch64_pic.a libebl_sparc_pic.a libebl_ppc_pic.a \
--	 libebl_ppc64_pic.a libebl_s390_pic.a libebl_tilegx_pic.a
-+	 libebl_ppc64_pic.a libebl_s390_pic.a libebl_tilegx_pic.a \
-+	 libebl_parisc_pic.a
+ 	 libebl_ppc64_pic.a libebl_s390_pic.a libebl_tilegx_pic.a \
+-	 libebl_m68k_pic.a libebl_bpf_pic.a
++	 libebl_m68k_pic.a libebl_bpf_pic.a libebl_parisc_pic.a
  noinst_LIBRARIES = $(libebl_pic)
  noinst_DATA = $(libebl_pic:_pic.a=.so)
  
-@@ -111,6 +112,9 @@ tilegx_SRCS = tilegx_init.c tilegx_symbo
- libebl_tilegx_pic_a_SOURCES = $(tilegx_SRCS)
- am_libebl_tilegx_pic_a_OBJECTS = $(tilegx_SRCS:.c=.os)
+@@ -128,6 +128,9 @@ endif
+ libebl_bpf_pic_a_SOURCES = $(bpf_SRCS)
+ am_libebl_bpf_pic_a_OBJECTS = $(bpf_SRCS:.c=.os)
  
 +parisc_SRCS = parisc_init.c parisc_symbol.c parisc_regs.c parisc_retval.c
 +libebl_parisc_pic_a_SOURCES = $(parisc_SRCS)
diff -Nru elfutils-0.166/debian/patches/mips_backend.diff elfutils-0.167/debian/patches/mips_backend.diff
--- elfutils-0.166/debian/patches/mips_backend.diff	2015-12-26 20:40:19.0 +
+++ elfutils-0.167/debian/patches/mips_backend.diff	2016-11-30 12:17:52.054276472 +
@@ -650,55 +650,2

Bug#834694: evemu: new upstream release (2.5.0)

[Daniel Serpell]

Source: evemu
Followup-For: Bug #834694

Ping?

Please, update, current version in Debian is too old for diagnosing problems, 
as seen in
https://bugs.freedesktop.org/show_bug.cgi?id=98845 :

 "Debian hasn't updated the package in 2 years and some information that I rely 
on is missing."

Thanks,


-- 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.8.0-1-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)

Bug#846346: RFS: golang-github-restic-chunker/0.0_git20160919.0.bb2ecf9-1

[Félix Sipma]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for "golang-github-restic-chunker":

  golang-github-restic-chunker - implementation of Content Defined Chunking 
(CDC) in Go

Package: golang-github-restic-chunker
Version: 0.0_git20160919.0.bb2ecf9-1
Upstream Author: Alexander Neumann 
Homepage: https://github.com/restic/chunker
License: BSD-2-clause
Section: devel


Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-restic-chunker/golang-github-restic-chunker_0.0~git20160919.0.bb2ecf9-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://git.debian.org/git/pkg-go/packages/golang-github-restic-chunker.git
cd golang-github-restic-chunker
gbp buildpackage

Thanks.



signature.asc
Description: PGP signature

Bug#846347: RFS: golang-github-elithrar-simple-scrypt/1.1+git20161119.3.2325946-1

[Félix Sipma]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for "golang-github-elithrar-simple-scrypt":

  golang-github-elithrar-simple-scrypt - various purpose password hashes 
library using the scrypt KDF

Package: golang-github-elithrar-simple-scrypt
Version: 1.1+git20161119.3.2325946-1
Upstream Author: Matthew Silverlock 
Homepage: https://github.com/elithrar/simple-scrypt
License: MIT
Section: devel


Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-elithrar-simple-scrypt/golang-github-elithrar-simple-scrypt_1.1+git20161119.3.2325946-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://git.debian.org/git/pkg-go/packages/golang-github-elithrar-simple-scrypt.git
cd golang-github-elithrar-simple-scrypt
gbp buildpackage

Thanks.


signature.asc
Description: PGP signature

Bug#845385: Privilege escalation via removal

[Markus Koschany]

On 30.11.2016 14:17, Emmanuel Bourg wrote:
> Le 22/11/2016 à 23:35, Paul Szabo a écrit :
> 
>> Then if the tomcat8 package is removed (purged?), the postrm script runs
>>   chown -Rhf root:root /etc/tomcat8/
>> and that will leave the file world-writable, setgid root
> 
> What about switching the files left to nobody:nogroup instead of
> root:root? That would be less disruptive for the stable and oldstable
> updates than removing /etc/tomcat8 completely.

I guess just removing /etc/tomcat8/Catalina would be an option too. As
far as I know nothing else requires it to be present after the removal
of Tomcat. If there were applications with such a dependency we should
take a look at them.

Markus





signature.asc
Description: OpenPGP digital signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Matthias Klose]

On 30.11.2016 13:45, Mark Brown wrote:
> On Tue, Nov 29, 2016 at 02:00:48PM +0100, Matthias Klose wrote:
>> On 28.11.2016 19:42, Mark Brown wrote:
>>> On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:
> 
>>> Which apparently changed at some point in the toolchain, probably quite
>>> some time ago, but fortunately we'd actually managed to remove all the
>>> users before that happened so it didn't affect anyone.
> 
>> Wrong. Until the zconf.h header was moved from /usr/include to
>> /usr/include/ these packages found the *wrong* header in
>> /usr/include, now they don't find anything anymore.
> 
> So that'll be what changed.  But really this is a bug in the multiarch
> support, zconf.h isn't at all architecture specific within the context
> of Debian (there's a few things that change but they're all related to
> completely non-Unix OSs).

apparently the Z_U4 definition was generalized in 1.2.8:

#if !defined(Z_U4) && !defined(Z_SOLO) && defined(STDC)
#  include 
#  if (UINT_MAX == 0xUL)
#define Z_U4 unsigned
#  elif (ULONG_MAX == 0xUL)
#define Z_U4 unsigned long
#  elif (USHRT_MAX == 0xUL)
#define Z_U4 unsigned short
#  endif
#endif

so the files don't differ (anymore), and you can install the header in
/usr/include again.

The configure script still patches in the HAVE_UNISTD_H and HAVE_STDARG_H
definitions, but these always have the same outcome in Debian, plus the
libz-mingw-w64-dev package agrees with these definitions too.

>>> Right now as far as I can tell there's been some change in the GNU D
>>> compiler that's attempting to add usage of the multilib zlib versions
>>> for some reason which is not at all clear to me.  You said something
>>> about moving the GDC runtime to a shared library but I'm finding that
>>> confusing as the issue with the header file as should also affect static
>>> usage so it seems like there must be something else in the mix
>>> somewhere.
> 
>> The libphobos configury falls back to the zlib copy shipped within the GCC
>> sources, when the system zlib cannot be used. So sure, dropping the build
>> dependencies on the multilib zlib packages does use the embedded copy, but
>> that's not what you usually want to do.
> 
> OK, so this makes at least that part of things clearer.  It's not a
> result of linking against the DSO but rather a result of not using an
> embedded copy of the source.
> 
>>> It seems there's also something going on with x32 but as far as I can
>>> tell that's orthogonal though it does seem to be related to changes in
>>> GDC as well somehow.
> 
>> that's just the third multilib on amd64 and i386.
> 
> Well, there's a bunch of questions there - people seem generally
> negative on x32 and the use cases for multilib with tooling for early
> boot and so on don't seem to apply in any case.  I'd really have
> expected that it'd just be added as a new architecture at this point.

it's available in the GCC packages for a while now.

>>> Shouldn't people building i386 D programs on amd64 (or other similar
>>> builds that would historically have been done with multilib) just be
>>> using multiarch to install the 32 bit runtime?  Please bear in mind
>>> that I'm not at all familiar with D here.
> 
>> there's nothing you need to understand with D, just that it tries to use 
>> zlib as
>> a dependency.
> 
> No, it's trying to use a multilib zlib as a dependency.  That's still
> really unclear to me here - to repeat my question above why aren't we
> asking people who want to build non-native D applications to just
> install the multiarch runtime?  The motivation I'm aware of for still
> having the multilib packages is to allow other multilib packages to be
> built with them but I'm not seeing any packages written in D (and it'd
> be pretty surprising TBH given the narrow use case) so I'm not seeing
> the use case.

If we remove everything where "people seem generally negative on FOO", we'll end
up with a really small distro. We still require the multilibs for 32bit
architectures needing to build 64bit kernels, and I'd rather not ask people to
work around issues when they can be fixed.

>> So removing these packages is fine with me too; in this case, please wait 
>> with
>> the removal and I'll prepare a new source package to build these multilib
>> libraries for the stretch release.
> 
> No, that's obviously not a good solution as it just ends up duplicating
> the source.
> 

Bug#823770: Duplicate?

[Pietro Battiston]

Might be a(nother) dup of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770153

(which would be good news, since there is a fix)

Pietro

Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU]

[Pranith Kumar]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: capstone
  Version : 4.0
  Upstream Author : Nguyen Anh Quynh 
* URL : http://www.capstone-engine.org/
* License : NCSA
  Section : devel
  Programming Lang: C++, Python
  Description : lightweight multi-architecture disassembly framework

It builds those binary packages:

cstool  - lightweight multi-architecture disassembly framework - 
Command li
libcapstone-dev - lightweight multi-architecture disassembly framework - devel 
file
libcapstone4- lightweight multi-architecture disassembly framework - library
python-capstone - lightweight multi-architecture disassembly framework - Python 
bin

Capstone is a disassembly framework with the target of becoming the ultimate
disasm engine for binary analysis and reversing in the security community.

I contribute to the upstream repository and would like to maintain it in
Debian. I need a sponsor.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/capstone/capstone_4.0.0-next-0.1.dsc

More information about capstone can be obtained from 
http://www.capstone-engine.org

Changes since the last upload:

- Package New upstream version

-- 
Pranith

Bug#846350: redis-server does not start if /var/run/redis does not exist

[Peter Souter]

Subject: redis-server does not start if /var/run/redis does not exist
Package: redis-server
Version: 2:3.2.5-1~dotdeb+8.1
Severity: normal

Dear Maintainer,

redis-server does not start if /var/run/redis does not exist

>From my understanding of the systemd directory, this can be fixed by
adding a RuntimeDirectory to the servicefile

>From the docs:

  System daemons frequently require private runtime directories below
/run to place communication sockets and similar in. For these,
consider declaring them in their unit files using RuntimeDirectory=
(see systemd.exec(5) for details), if this is feasible.

So I believe adding RuntimeDirectory=redis to the
"/lib/systemd/system/redis-server.service" file in the package will
prevent this issue

Reproducible steps:

root@debian-redis-test:~# apt-get install redis-server --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  libjemalloc1
Use 'apt-get autoremove' to remove it.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 27 not upgraded.
Need to get 0 B/509 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 44319 files and directories currently installed.)
Preparing to unpack .../redis-server_2%3a3.2.5-1~dotdeb+8.1_amd64.deb ...
Unpacking redis-server (2:3.2.5-1~dotdeb+8.1) over (2:3.2.5-1~dotdeb+8.1) ...
Processing triggers for systemd (215-17+deb8u5) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up redis-server (2:3.2.5-1~dotdeb+8.1) ...

root@debian-redis-test:~# systemctl status redis-server
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled)
   Active: active (running) since Wed 2016-11-30 14:24:32 UTC; 1s ago
 Docs: http://redis.io/documentation,
   man:redis-server(1)
  Process: 6253 ExecStartPost=/bin/run-parts --verbose
/etc/redis/redis-server.post-up.d (code=exited, status=0/SUCCESS)
  Process: 6250 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
(code=exited, status=0/SUCCESS)
  Process: 6247 ExecStartPre=/bin/run-parts --verbose
/etc/redis/redis-server.pre-up.d (code=exited, status=0/SUCCESS)
 Main PID: 6252 (redis-server)
   CGroup: /system.slice/redis-server.service
   └─6252 /usr/bin/redis-server 127.0.0.1:6379

Nov 30 14:24:32 debian-redis-test run-parts[6247]: run-parts:
executing /etc/redis/redis-server.pre-up.d/00_example
Nov 30 14:24:32 debian-redis-test run-parts[6253]: run-parts:
executing /etc/redis/redis-server.post-up.d/00_example
Nov 30 14:24:32 debian-redis-test systemd[1]: Started Advanced key-value store.

root@debian-redis-test:~# systemctl stop redis-server

root@debian-redis-test:~# rm -rf /var/run/redis/

root@debian-redis-test:~# systemctl start redis-server
Job for redis-server.service failed. See 'systemctl status
redis-server.service' and 'journalctl -xn' for details.

root@debian-redis-test:~# journalctl -u redis-server --no-pager | grep pid
Nov 30 13:29:04 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 13:30:34 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 13:32:30 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 13:32:31 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 13:32:31 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 13:32:31 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 13:32:31 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:05:02 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:05:03 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:05:03 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:05:03 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:05:03 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:24:54 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:24:54 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:24:54 debian-redis-test systemd[1]: PID file
/var/run/redis/redis-server.pid not readable (yet?) after start-post.
Nov 30 14:24:55 debian-redis-test systemd[1]: PID fil

Bug#846349: ITP: r-cran-plogr -- GNU R C++ Logging Library

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-plogr
  Version : 0.1-1
  Upstream Author : Kirill Müller 
* URL : https://cran.r-project.org/package=plogr
* License : MIT
  Programming Lang: GNU R, C++
  Description : GNU R C++ Logging Library
 Plogr is a simple header-only logging library for C++ to be used with
 GNU R. Add 'LinkingTo: plogr' to 'DESCRIPTION', and '#include '
 in your C++ modules to use it.


Remark: This package is a new Build-Dependency for r-cran-rsqlite which
is needed to upgrade this package to the latest upstream version.  It
will be maintained by the Debian Med team at
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-plogr/trunk/

Bug#822828: Another duplicate?

[Pietro Battiston]

Notice that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823770
is probably itself a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770153

Pietro

Bug#820457: recode: please make the build reproducible (timestamps)

[Santiago Vila]

On Fri, 8 Apr 2016, Alexis Bienvenüe wrote:

> Source: recode
> Version: 3.6-22
> Severity: wishlist
> Tags: patch upstream
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> While working on the “reproducible builds” effort [1], we have noticed
> that 'recode' could not be built reproducibly.
> 
> The attached patch makes recode building using a recent version of
> help2man (from the debian package) instead of the old one shipped with
> the recode sources. This version honours the SOURCE_DATE_EPOCH
> environment variable, so that the date used in the documentation is
> taken from the last debian/changelog entry. [...]

Sorry for not answering before.

The proposed patch is certainly perfect for what it intends to do.

However, I don't really like what it does (setting the date to
the last debian/changelog entry) because that would appear that
I modified the manpage at every Debian release.

So I'm going to hardcode the date to the upstrem release date
(January 2001) with a much shorter patch. This may be a little bit
hacky, but the end result is closer to what I think it should be.

Thanks a lot.

Bug#846352: jessie-pu: package nvidia-graphics-drivers/340.98-1

[Andreas Beckmann]

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

Hi,

again we have some CVEs in the proprietary nvidia driver:
CVE-2016-7382, CVE-2016-7389: #846331

This requires updatiung to a new upstream release. Such updates always
happened via -pu instead of -security.

Since keeping the nvidia-graphics-drivers,
nvidia-graphics-drivers-legacy-340xx and
nvidia-graphics-drivers-legacy-304xx packages in sync is quite some bit
of work (and therefore the packaging is quite generic with a lot of
substitutions at build time), this jessie update also contains quite a
lot of small fixes backported from unstable as well as some bigger
changes:

* changed layout of the .orig.tar.gz: now one .orig-ARCH.tar.gz per
  architecture
* use the upstream conftest.sh script at module build time instead of
  providing our handcrafted conftest.h (which needed manual updates for
  each upstream release)
* generate the bug-control file to simplify backporting updates for
  improved bug reports
* drop all backward compatibility support for 96xx/173xx legacy drivers
* drop all backward compatibility support for EoL lenny and squeeze
* sync packaging with sid where possible

Every change should be listed in the changelog along with the package
version where it initially appeared in unstable.

There are no changes in the package layout (no new packages or files
being moved around (besides version string changes 340.96 -> 340.98)),
I'm attaching a binary debdiff as well, since it may not be obvious that
the substitution changes (to unify them with what we use in sid) in
debian/control result in unchanged binary packages.

The debhelper 8->9 bump is only inside the nvidia-kernel-source
package to adjust to reality, the src:nvidia-graphics-drivers package
was already at 9.

All these changes have been tested in sid and jessie-backports, in both
src:nvidia-graphics-drivers and
src:nvidia-graphics-drivers-legacy-340xx (and -304xx)

As usually, I used 340.98-1 as the version instead of 340.98-0+deb8u1,
to reduce the version number blowup in the precompiled kernel modules
(nvidia-graphics-modules will need a followup update).

The debdiff of debian/ is quite large, mainly due to getting rid of now
no longer used stuff. There are several new patches for the upstream
kernel module build system to make it work like in newer upstream
releases (where using conftest.sh works (nearly) out-of-the-box).

Thanks for considering.


Andreas


ngd-340.98-1.diff.gz
Description: application/gzip
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   /usr/lib/nvidia/current/libglx.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnvidia-compiler.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnvidia-glsi.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnvidia-tls.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLESv1_CM.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLESv2.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvcuvid.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-encode.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-fbc.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ifr.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ml.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-opencl.so.340.98
-rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/nvidia/current/libvdpau_nvidia.so.340.98
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.340.98
-rw-r--r--  root/root   /usr/share/nvidia/nvidia-367.ids
-rw-r--r--  root/root   
/usr/share/nvidia/nvidia-application-profiles-340.98-key-documentation
-rw-r--r--  root/root   /usr/share/nvidia/nvidia-application-profiles-340.98-rc
-rw-r--r--  root/root   /usr/src/nvidia-current-340.98/Makefile
-rw-r--r--  root/root   /usr/src/nvidia-current-340.98/NVIDIA_Changelog
-rw-r--r--  root/root   /usr/src/nvidia-current-340.98/conftest.sh
-rw-r--r--  root/root   /usr/src/nvidia-current-340.98/cpuopsys.h
-rw-r--r--  root/root   /usr/src/nvidia-current-340.98/dkms.conf
-rw-r--r--  r

Bug#844549: network-console broken: no screen to be resumed matching sh

[Roger Shimizu]

On Tue, Nov 22, 2016 at 3:05 AM, Roger Shimizu  wrote:
>
> I'll test the daily image on my Linkstation NAS.

I tested the daily image on my armel devices.
Both serial way and SSH way works fine. And if connect both serial and
SSH (network-console), serial/SSH seems to share the same screen
session, which is good and beyond what I expected.
It's exceeded what I have imagined.

Just one issue for SSH (network-console).
Since the SSH session shares the same screen with serial, the screen
size is limited to 80x25 (probably, I didn't count the number), which
is too small to most recent monitor devices.

Does it deserve a new bug report?
What do you think of it?

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

Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU]

[Paul Wise]

On Wed, Nov 30, 2016 at 10:32 PM, Pranith Kumar wrote:

> Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU]

This should not be an NMU because the package is orphaned and you
intend to adopt it. So you should change the version to 4.0.0-next-1,
add yourself to the maintainer field and remove any mention of NMU
from this RFS bug title and from the changelog.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#786566: this is affecting us

[Peter Palfrader]

severity 786566 serious
thanks

This schroot issue is affecting our debian.org porterboxes, and it
affects other users (e.g. torproject.org build environment) where more
than one chroot is being used at a time.

We really should fix this for stretch.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#846333: nvidia-graphics-drivers: CVE-2016-7382, CVE-2016-7389: missing permissions check and improper validation vulnerability

[Andreas Beckmann]

On 2016-11-30 12:35, Luca Boccassi wrote:
> This is a fun one... the choice for Jessie and oldstable-backports is
> either to keep the vulnerable 304.131 or get the completely and utterly
> broken 304.132...

Let's hope there is a new upstream release updating Xorg support soon
... I'll probably stay with 304.131 for now.


Andreas

Bug#846332: nvidia-graphics-drivers: CVE-2016-7382, CVE-2016-7389: missing permissions check and improper validation vulnerability

[Andreas Beckmann]

On 2016-11-30 12:32, Luca Boccassi wrote:
> Do we need to upload 340.98 to stable security?

There is no security support for non-free and contrib. These updates
always happed via -pu.

jessie-pu request filed: #846352


Andreas

Bug#845788: plasma-desktop: Incorrect values in ~/.config/plasma*

[Dmitry Shachnev]

¡Hola Maximiliano!

On Tue, Nov 29, 2016 at 02:43:44PM +0100, Maximiliano Curia wrote:
> Mmh, I see the en_NL option in the formats kcm, which isn't a valid locales
> value. This seems to be a qt issue, the combos are filled calling:
> QList allLocales = QLocale::matchingLocales(QLocale::AnyLanguage, 
> QLocale::AnyScript, QLocale::AnyCountry);

FWIW Qt does not maintain its own locales database, it uses a C++ file
generated from CLDR data instead. It looks like en_NL was added in CLDR v29.

See:

- https://code.qt.io/cgit/qt/qtbase.git/commit?id=eb26f2b19babf8cd
  (in this commit the English/Latin/Netherlands line was added)

- 
http://www.unicode.org/cldr/charts/latest/supplemental/territory_language_information.html#NL

(This is just a side note, I do not yet reject this bug.)

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#822078: debian-installer: Unbootable system after the installation on Dell XPS13 P54G model

[Steve McIntyre]

On Sun, Nov 20, 2016 at 02:57:17AM +0100, Cyril Brulebois wrote:
>Ramakrishnan Muthukrishnan  (2016-04-21):
>> I installed debian from a debian testing nightly iso image for amd64 on
>> a Dell XPS13 laptop.
>> 
>> The installation went smoothly. On the first reboot, after removing the
>> installation media (USB stick), the machine won't boot and complains
>> that it cannot find a boot media.
>> 
>> I then searched the web and found similar reports and found this guide:
>> 
>>  
>> 
>> which solved the problem by first preparing a boot media using rEFInd
>> and booting with it into the just installed Debian system and then
>> renaming/moving certain files. Pasting the relevant instructions below:
>> 
>> cd /boot/efi/EFI
>> cp -r debian BOOT
>> mv BOOT/grubx64.efi BOOT/bootx64.efi
>> 
>> Is this something specific to the way Dell XPS13 bios/efi firmware
>> expects? This is my first installation of Debian on a UEFI machine, so
>> perhaps there were better ways out of this? But perhaps like me, there
>> are other joe users new to EFI and face similar issues and then move
>> away after a failed installation.
>> 
>> I will be glad to help with further information and any further testing
>> on this machine.
>
>Could this be another case of needing this specific option?
>  
> https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path
>
>Cc-ing Steve, who might know.

Yes, it sounds exactly like that. :-(

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#846297: mesa-vdpau-drivers: breaks vdpau for mpeg2video with mpv and vlc

[Jörg-Volker Peetz]

Hi,

have reported this upstream: https://bugs.freedesktop.org/show_bug.cgi?id=98914
Tracking number is 98914.
Feel free to contact me, if further information is required.

Regards,
jvp.

Andreas Boll wrote on 11/30/16 13:28:
> Control: tags -1 + upstream
> 
> Hi,
> 
> please report this upstream to
> https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa&component=Drivers%2FGallium%2Fr600
> and let us know the bug number for tracking.
> 
> Thanks,
> Andreas
> 

Bug#846354: erlang: Backport installation wont pull deps

[Alexandros Prekates]

Package: erlang
Version: 1:19.1.6+dfsg-2~bpo8+1
Severity: normal

Dear Maintainer,

Trying to install erlang 1.19 from backport in my debian 8.5

sudo apt-get -V -t jessie-backports install erlang

i noticed that only erlang will be installeded.

$ LANG=en apt-cache -t jessie-backports policy erlang erlang-base
erlang:
  Installed: 1:19.1.6+dfsg-2~bpo8+1
  Candidate: 1:19.1.6+dfsg-2~bpo8+1
  Version table:
 *** 1:19.1.6+dfsg-2~bpo8+1 0
990 http://http.debian.net/debian/ jessie-backports/main amd64 Packages
100 /var/lib/dpkg/status
 1:17.3-dfsg-4 0
500 http://ftp.gr.debian.org/debian/ jessie/main amd64 Packages
erlang-base:
  Installed: 1:17.3-dfsg-4
  Candidate: 1:19.1.6+dfsg-2~bpo8+1
  Version table:
 1:19.1.6+dfsg-2~bpo8+1 0
990 http://http.debian.net/debian/ jessie-backports/main amd64 Packages
 *** 1:17.3-dfsg-4 0
500 http://ftp.gr.debian.org/debi

Depedencies wont be 'pulled'.

I tried with another package in backport and no problem.




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

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

Versions of packages erlang depends on:
ii  erlang-asn1   1:17.3-dfsg-4
ii  erlang-base   1:17.3-dfsg-4
ii  erlang-common-test1:17.3-dfsg-4
ii  erlang-corba  1:17.3-dfsg-4
ii  erlang-crypto 1:17.3-dfsg-4
ii  erlang-debugger   1:17.3-dfsg-4
ii  erlang-dev1:17.3-dfsg-4
ii  erlang-dialyzer   1:17.3-dfsg-4
ii  erlang-diameter   1:17.3-dfsg-4
ii  erlang-edoc   1:17.3-dfsg-4
ii  erlang-eldap  1:17.3-dfsg-4
ii  erlang-erl-docgen 1:17.3-dfsg-4
ii  erlang-et 1:17.3-dfsg-4
ii  erlang-eunit  1:17.3-dfsg-4
ii  erlang-gs 1:17.3-dfsg-4
ii  erlang-ic 1:17.3-dfsg-4
ii  erlang-inets  1:17.3-dfsg-4
ii  erlang-megaco 1:17.3-dfsg-4
ii  erlang-mnesia 1:17.3-dfsg-4
ii  erlang-observer   1:17.3-dfsg-4
ii  erlang-odbc   1:17.3-dfsg-4
ii  erlang-os-mon 1:17.3-dfsg-4
ii  erlang-parsetools 1:17.3-dfsg-4
ii  erlang-percept1:17.3-dfsg-4
ii  erlang-public-key 1:17.3-dfsg-4
ii  erlang-reltool1:17.3-dfsg-4
ii  erlang-runtime-tools  1:17.3-dfsg-4
ii  erlang-snmp   1:17.3-dfsg-4
ii  erlang-ssh1:17.3-dfsg-4
ii  erlang-ssl1:17.3-dfsg-4
ii  erlang-syntax-tools   1:17.3-dfsg-4
ii  erlang-tools  1:17.3-dfsg-4
ii  erlang-typer  1:17.3-dfsg-4
ii  erlang-wx 1:17.3-dfsg-4
ii  erlang-xmerl  1:17.3-dfsg-4

Versions of packages erlang recommends:
ii  erlang-examples1:17.3-dfsg-4
ii  erlang-ic-java 1:17.3-dfsg-4
ii  erlang-jinterface  1:17.3-dfsg-4
ii  erlang-mode1:17.3-dfsg-4
ii  erlang-src 1:17.3-dfsg-4

Versions of packages erlang suggests:
pn  erlang-doc   
pn  erlang-manpages  

-- no debconf information