Bug#857701: nmu: lzo2_2.08-1.2

[Carlos Maddela]

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

Hello,

Trying to link against this library in Sid fails with this message:

> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/liblzo2.a(lzo1x_1.o):
>  relocation R_X86_64_PC32 against symbol `memset@@GLIBC_2.2.5' can not be 
> used when making a shared object; recompile with -fPIC

Rebuilding the package without any changes fixes the problem.

nmu lzo2_2.08-1.2 . ANY . unstable . -m "Rebuild with -fPIC"

Thanks.

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

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

Bug#856654: xdotool: please add examples for set_desktop —relative in manpage

[Daniel Kahn Gillmor]

Control: forwarded 856654 https://github.com/jordansissel/xdotool/pull/166

> Please add examples for "set_desktop --relative" — it's not immediately
> clear that you have to use "--" in order that negative numbers are parsed
> correctly:

Hi Lamby--

thanks for the suggestion.

I've forwarded it upstream.

Regards,

--dkg

Bug#857326: AH01796: AuthType NTLM configured without corresponding module

[Hamish Moffatt]

Ah, sorry it does work. I was testing with Basic authentication, which 
isn't enabled by default. When you try with NTLM it does work, at least 
when I put the config in a Directory or Location section.


For basic auth to work as well you can configure it as:


NTLMAuth on
NTLMAuthHelper "/usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp"
PlainTextAuthHelper "/usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-basic"

NTLMBasicAuthoritative on
NTLMBasicAuth on

AuthType NTLM
require valid-user



It works in a  too for basic authentication, although NTLM from 
Edge doesn't seem good. Proxy from Firefox and some other apps I tried 
seems ok though.


You can close this bug.


thanks
Hamish

Bug#857699: ioquake3 has a security vulnerability

[Daniel Gibson]

Package: ioquake3
Version: 1.36
Severity: grave

Hi,

earlier today ioquake3 fixed a vulnerability that, as far as I 
understand, could let malicious multiplayer servers execute code on 
connecting clients.
It affects all prior versions of ioquake3 (and I think also original 
Quake 3).
Details: 
https://ioquake3.org/2017/03/13/important-security-update-please-update-ioquake3-immediately/ 



So you should probably update to latest ioq3 git or backport the fix.

Cheers,
Daniel

Bug#857473: [Pkg-roundcube-maintainers] Bug#857473: roundcube: XSS issue in handling of a style tag inside of an svg element

[Guilhem Moulin]

Control: tag -1 pending

Hi,

On Sat, 11 Mar 2017 at 20:29:11 +0100, Salvatore Bonaccorso wrote:
> 1.2.4 roundcube release fixed a XSS issue in handling of a style tag
> inside of an svg element.

Thanks for the ping and the pointers!  I applied the fix to 1.2.3
(unstable) and 1.1.5 (jessie-backports).

Could someone else in the team upload the two source packages?  I don't
have upload privileges :-P  (Also I didn't tag the releases.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#857698: ITP: golang-code.gitea-git -- Go module that provides git access through shell

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-code.gitea-git
  Version : 0.0~git20170313.0.3374688-1
  Upstream Author : The Gitea Authors
* URL : https://code.gitea.io/git/
* License : Expat
  Programming Lang: Go
  Description : Go module that provides git access through shell

 This package provides a Go library that can be used to access git
 through shell commands.
 .
 Documentation: https://godoc.org/code.gitea.io/git

This is being packaged as a dependency of Gitea, but it also provides
a very generic and flexible interface that can be used for many projects.
-- 
Michael Lustfield


pgp07_yNVw3m1.pgp
Description: OpenPGP digital signature

Bug#857697: unblock: netcat-openbsd/1.130-3

[Guilhem Moulin]

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

Please unblock package netcat-openbsd

Since 1.110 nc(1) no longer shutdown network sockets when stdin closes.
This is a deliberate upstream decision, which can be reverted with the
new ‘-N’ flag [0].

For better compatibility with GNU netcat we've added a quit timer
(defaulting to -q0 since 1.89-4) to quit immediately after EOF.  However
our patch wasn't modified properly, and the upstream's new behavior with
respect to shutdown(2) lead to a regression in 1.130-1 and 1.130-2.

I'd like to upload 1.130-3 to Stretch as the regression affects libvirt
and QEMU users which use nc(1) to talk to remote hypervisor sockets, cf.
#854292.  Since 1.130-3 nc(1) defaults to ‘-q-1’ (matching upstream's
behavior), and ‘-q0’ is a mere alias for ‘-N’ (it was a no-op before).
Furthermore the new patch is also simpler, so we're reducing our delta
with upstream :-).  Debdiff enclosed.

unblock netcat-openbsd/1.130-3

-- 
Guilhem.

[0] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/netcat.c?rev=1.111=text/x-cvsweb-markup
[1] 
https://anonscm.debian.org/cgit/collab-maint/netcat-openbsd.git/tree/debian/patches/0005-quit-timer.patch
diff -Nru netcat-openbsd-1.130/debian/changelog 
netcat-openbsd-1.130/debian/changelog
--- netcat-openbsd-1.130/debian/changelog   2017-01-26 09:51:13.0 
+0100
+++ netcat-openbsd-1.130/debian/changelog   2017-03-06 09:48:36.0 
+0100
@@ -1,3 +1,12 @@
+netcat-openbsd (1.130-3) unstable; urgency=medium
+
+  * Change defaults from "-q0" to "-q-1" to match upstream defaults since the
+introduction of flag "-N" in version 1.110.  Passing a non-negative value
+to "-q" now implies "-N"; in particular, "-q0" is now a mere alias for
+"-N". (Closes: #854292)
+
+ -- Guilhem Moulin   Fri, 03 Mar 2017 20:32:55 +0100
+
 netcat-openbsd (1.130-2) unstable; urgency=medium
 
   * Fix handling of delayed exit option (Closes: #849192, LP: #1656785)
diff -Nru netcat-openbsd-1.130/debian/patches/0005-quit-timer.patch 
netcat-openbsd-1.130/debian/patches/0005-quit-timer.patch
--- netcat-openbsd-1.130/debian/patches/0005-quit-timer.patch   2017-01-26 
09:51:13.0 +0100
+++ netcat-openbsd-1.130/debian/patches/0005-quit-timer.patch   2017-03-06 
09:45:02.0 +0100
@@ -19,14 +19,19 @@
  .Op Fl s Ar source
  .Op Fl T Ar toskeyword
  .Op Fl V Ar rtable
-@@ -171,6 +172,10 @@ Proxy authentication is only supported for HTTP CONNECT 
proxies at present.
+@@ -171,6 +172,15 @@ Proxy authentication is only supported for HTTP CONNECT 
proxies at present.
  Specifies the source port
  .Nm
  should use, subject to privilege restrictions and availability.
 +.It Fl q Ar seconds
-+after EOF on stdin, wait the specified number of seconds and then quit. If
++after EOF on stdin, wait the specified number of
 +.Ar seconds
-+is negative, wait forever.
++and then quit. If
++.Ar seconds
++is negative, wait forever (default).  Specifying a non-negative
++.Ar seconds
++implies
++.Fl N .
  .It Fl r
  Specifies that source and/or destination ports should be chosen randomly
  instead of sequentially within a range or in the order that the system
@@ -38,21 +43,20 @@
  int   nflag;  /* Don't do name look up */
  char   *Pflag;/* Proxy username */
  char   *pflag;/* Localport flag */
-+int qflag = 0; /* Quit after some secs */
++intqflag = -1;/* Quit after some secs */
  int   rflag;  /* Random ports flag */
  char   *sflag;/* Source Address */
  int   tflag;  /* Telnet Emulation */
-@@ -171,6 +172,9 @@ ssize_t fillbuf(int, unsigned char *, size_t *);
+@@ -171,6 +172,8 @@ ssize_t fillbuf(int, unsigned char *, size_t *);
  static int connect_with_timeout(int fd, const struct sockaddr *sa,
  socklen_t salen, int ctimeout);
  
-+int   quit_fd = -1;
 +static void quit();
 +
  int
  main(int argc, char *argv[])
  {
-@@ -195,7 +199,7 @@ main(int argc, char *argv[])
+@@ -195,7 +198,7 @@ main(int argc, char *argv[])
signal(SIGPIPE, SIG_IGN);
  
while ((ch = getopt(argc, argv,
@@ -61,7 +65,7 @@
switch (ch) {
case '4':
family = AF_INET;
-@@ -248,6 +252,11 @@ main(int argc, char *argv[])
+@@ -248,6 +251,13 @@ main(int argc, char *argv[])
case 'p':
pflag = optarg;
break;
@@ -69,49 +73,43 @@
 +  qflag = strtonum(optarg, INT_MIN, INT_MAX, );
 +  if (errstr)
 +  errx(1, "quit timer %s: %s", errstr, optarg);
++  if (qflag >= 0)
++  Nflag = 1;
 +  

Bug#851066: flashplugin-nonfree broken for all new installations on jessie and sid

[Ben Caradoc-Davies]

Another user report, from debian-user:
https://lists.debian.org/debian-user/2017/03/msg00426.html

My fix confirmed by end user:
https://lists.debian.org/debian-user/2017/03/msg00491.html

Similar to post earlier in this bug report, copied here for the benefit 
of users. Works on jessie and sid amd64, with flashplugin-nonfree 
installed (but broken).


**

I also just tried purging and reinstalling, both with 3.6 (jessie 
package) and 3.7 (sid), and found them to be horribly broken. The 
problem is that, when Adobe updates the plugin, the flashplugin-nonfree 
installation process is broken until the maintainer Bart Martens updates 
some remote configuration files to enable the new version.


I was able to get it working with the following manual installation of 
the Adobe .tar.gz. I use this method because it is what the 
flashplugin-nonfree installer does, and I hope that when the package 
installer is working, my manual installation will be compatible. I hope 
that this approach minimises mess.


Download page:
https://get.adobe.com/flashplayer/

Download the .tar.gz (should be the same as this link):
https://get.adobe.com/flashplayer/download/?installer=FP_24.0_for_Linux_64-bit_(.tar.gz)_-_NPAPI=5504=1

For the next steps, you need to be root.

Extract the library (change the path to where you downloaded the .tar.gz):

tar zxfO /path/to/flash_player_npapi_linux.x86_64.tar.gz 
libflashplayer.so > /usr/lib/flashplugin-nonfree/libflashplayer.so


Fix permissions:

chmod 644 /usr/lib/flashplugin-nonfree/libflashplayer.so

Register the plugin:

update-alternatives --quiet --install 
/usr/lib/mozilla/plugins/flash-mozilla.so flash-mozilla.so 
/usr/lib/flashplugin-nonfree/libflashplayer.so 50


Now see if it works in Tools / Add-ons / Plugins and:
http://www.adobe.com/software/flash/about/

For future manual updates, only the tar command is required.

**

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#659620: RFP: wview -- Weather station daemon

[陳昌倬]

On Mon, Mar 13, 2017 at 01:57:32PM -0600, Kevin Locke wrote:
> The package is available at https://gitlab.com/kevinoid/wview with the
> standard git-buildpackage repository layout.  It includes a packaging
> TODO list in debian/TODO.md with items that were mostly for myself,
> but which potential packagers may want to consider.

Hi. 

Cannot access https://gitlab.com/kevinoid/wview, please help to check
if permission is correct.


-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#857696: unblock: opendmarc/1.3.2-1

[Scott Kitterman]

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

Please unblock package opendmarc

I would like to update opendmarc in stretch for two reasons.  One, I think,
good and the other, so so.  The good reason is that the package documentation
has issues significant enough that people are filing bugs at the RC level
because they think it is broken and they can't figure out how to set it up.  I
think that needs to be fixed.  The so so reason is to bump from a 1.3.2 beta
release to the final.  It's primarily patch to source conversion and a bit of
additional bug fixing.  I think we're better off shipping the final.

In order to make this easier to review, in addition to the full debdiff, I am
including a patches applied upstream only diff to more clearly show the
minimal changes in the upstream code.  I think the risk of updating is
negligible both based on the diff and the lack of issues reported on the
generally very active upstream mailing list (I have waited a bit for this
request to give others a chance to find any problems).

Since it's not clear how much of this the release team will agree is
appropriate, I have not uploaded to unstable, but I have a package that
exactly matches the debdiff built and ready to dput if approved.

unblock opendmarc/1.3.2-1
diff -Nru opendmarc-1.3.2~Beta1/configure opendmarc-1.3.2/configure
--- opendmarc-1.3.2~Beta1/configure	2016-12-18 04:49:44.0 -0500
+++ opendmarc-1.3.2/configure	2017-03-04 08:28:59.0 -0500
@@ -3074,7 +3074,7 @@
 #
 # library version, passed to libtool
 #
-LIBOPENDMARC_VERSION_INFO=$(printf %d:%d:%d 2 1 0)
+LIBOPENDMARC_VERSION_INFO=$(printf %d:%d:%d 2 2 0)
 
 
 #
diff -Nru opendmarc-1.3.2~Beta1/configure.ac opendmarc-1.3.2/configure.ac
--- opendmarc-1.3.2~Beta1/configure.ac	2016-12-18 04:48:45.0 -0500
+++ opendmarc-1.3.2/configure.ac	2017-03-04 08:28:39.0 -0500
@@ -1,7 +1,7 @@
 #   -*- Autoconf -*-
 # Process this file with autoconf to produce a configure script.
 #
-# Copyright (c) 2012-2016, The Trusted Domain Project.  All rights reserved.
+# Copyright (c) 2012-2017, The Trusted Domain Project.  All rights reserved.
 
 # Acceptable arguments to configure are:
 # 	The usual CC= etc.
@@ -33,7 +33,7 @@
 #
 
 m4_define([LIBVERSION_CURRENT], 2)
-m4_define([LIBVERSION_REVISION], 1)
+m4_define([LIBVERSION_REVISION], 2)
 m4_define([LIBVERSION_AGE], 0)
 
 #
diff -Nru opendmarc-1.3.2~Beta1/contrib/init/generic/Makefile.in opendmarc-1.3.2/contrib/init/generic/Makefile.in
--- opendmarc-1.3.2~Beta1/contrib/init/generic/Makefile.in	2016-12-18 04:49:46.0 -0500
+++ opendmarc-1.3.2/contrib/init/generic/Makefile.in	2017-03-04 08:28:57.0 -0500
@@ -289,9 +289,9 @@
 	  exit 1;; \
 	  esac; \
 	done; \
-	echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu contrib/init/generic/Makefile'; \
+	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign contrib/init/generic/Makefile'; \
 	$(am__cd) $(top_srcdir) && \
-	  $(AUTOMAKE) --gnu contrib/init/generic/Makefile
+	  $(AUTOMAKE) --foreign contrib/init/generic/Makefile
 .PRECIOUS: Makefile
 Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
 	@case '$?' in \
diff -Nru opendmarc-1.3.2~Beta1/contrib/init/redhat/Makefile.in opendmarc-1.3.2/contrib/init/redhat/Makefile.in
--- opendmarc-1.3.2~Beta1/contrib/init/redhat/Makefile.in	2016-12-18 04:49:46.0 -0500
+++ opendmarc-1.3.2/contrib/init/redhat/Makefile.in	2017-03-04 08:28:57.0 -0500
@@ -289,9 +289,9 @@
 	  exit 1;; \
 	  esac; \
 	done; \
-	echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu contrib/init/redhat/Makefile'; \
+	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign contrib/init/redhat/Makefile'; \
 	$(am__cd) $(top_srcdir) && \
-	  $(AUTOMAKE) --gnu contrib/init/redhat/Makefile
+	  $(AUTOMAKE) --foreign contrib/init/redhat/Makefile
 .PRECIOUS: Makefile
 Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
 	@case '$?' in \
diff -Nru opendmarc-1.3.2~Beta1/contrib/Makefile.in opendmarc-1.3.2/contrib/Makefile.in
--- opendmarc-1.3.2~Beta1/contrib/Makefile.in	2016-12-18 04:49:45.0 -0500
+++ opendmarc-1.3.2/contrib/Makefile.in	2017-03-04 08:28:57.0 -0500
@@ -350,9 +350,9 @@
 	  exit 1;; \
 	  esac; \
 	done; \
-	echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu contrib/Makefile'; \
+	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign contrib/Makefile'; \
 	$(am__cd) $(top_srcdir) && \
-	  $(AUTOMAKE) --gnu contrib/Makefile
+	  $(AUTOMAKE) --foreign contrib/Makefile
 .PRECIOUS: Makefile
 Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
 	@case '$?' in \
diff -Nru opendmarc-1.3.2~Beta1/contrib/rddmarc/Makefile.in opendmarc-1.3.2/contrib/rddmarc/Makefile.in
--- opendmarc-1.3.2~Beta1/contrib/rddmarc/Makefile.in	2016-12-18 04:49:46.0 -0500
+++ opendmarc-1.3.2/contrib/rddmarc/Makefile.in	2017-03-04 08:28:57.0 -0500
@@ -294,9 +294,9 @@
 	  exit 1;; \
 	  esac; \
 	

Bug#857326: AH01796: AuthType NTLM configured without corresponding module

[Hamish Moffatt]

On 11/03/17 08:36, Olly Betts wrote:

On Fri, Mar 10, 2017 at 02:59:10PM +1100, Hamish Moffatt wrote:

I've configured this module according to the README instructions, but it 
doesn't work - any
attempt to authenticate results in the following in the Apache log:

[Fri Mar 10 14:49:34.047665 2017] [authn_core:error] [pid 15805] [client 
192.168.42.2:40411] AH01796: AuthType NTLM configured without corresponding 
module

I have put the following in a .


AuthName "NTLM Authentication thingy"

NTLMAuth on
NTLMAuthHelper "/usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp"
NTLMBasicAuthoritative on
AuthType NTLM
require valid-user




I have marked this important as the package would seem to be unusable.

Did you enable the module as well as installing the package?

sudo a2enmod auth_ntlm_winbind

Once I do that, the verbatim first example in README (i.e. using
 rather than ) seems to work for me.  At least I don't
get the error above and a login box pops up in the broswer - I don't have
anything actually set up to auth against (which is why I've orphaned the
package).


Yes I do have the module enabled.

$ ls /etc/apache2/mods-enabled

access_compat.load  authn_core.load authz_user.load  deflate.load  
filter.load   mpm_prefork.confproxy_http.load  setenvif.load   
userdir.conf

actions.confauthn_file.load autoindex.conf   dir.conf  
headers.load  mpm_prefork.loadproxy.load   socache_shmcb.load  
userdir.load

actions.loadauth_ntlm_winbind.load  autoindex.load   dir.load  
include.load  negotiation.confreqtimeout.conf  ssl.confwsgi.conf

alias.conf  authz_core.load cgi.load env.load  
macro.loadnegotiation.loadreqtimeout.load  ssl.loadwsgi.load

alias.load  authz_groupfile.loaddav.load fastcgi.conf  
mime.conf proxy.conf  rewrite.load status.conf

auth_basic.load authz_host.load deflate.conf fastcgi.load  
mime.load proxy_connect.load  setenvif.confstatus.load


I tried it on a  and got the same thing.

DocumentRoot /srv/web/testproxy

Options FollowSymLinks
AllowOverride None

NTLMAuth on
NTLMAuthHelper "/usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp"

NTLMBasicAuthoritative on
AuthType NTLM
require valid-user


[Tue Mar 14 12:07:55.169134 2017] [authn_core:error] [pid 32017] [client 
192.168.42.2:45912] AH01796: AuthType NTLM configured without 
corresponding module




Hamish

Bug#855013:

[Greg Farough]

For the record, I have also observed this behavior in jessie. Pulseaudio
will mute when coming out of suspend, but only occasionally. I'll try to
get some logs.

-- 
-g

"A man can live and be healthy without killing animals for food;
therefore, if he eats meat, he participates in taking animal life
merely for the sake of his appetite. And to act so is immoral."

Bug#850861: Please add this patch

[Matthias Urlichs]

Please apply this patch.

libev-using programs are otherwise undebuggagble wih valgrind on i386.


-- 
-- Matthias Urlichs

From: Matthias Urlichs 
Date: Tue, 14 Mar 2017 01:44:51 +0100
X-Dgit-Generated: 1:4.22-2 9775ccac9c1ba148676b5b97658b4728647aab16
Subject: Don't use -1(%esp). It upsets valgrind and violates the i386 ABI.

Unfortunately, the author of libev refuses to fix this.

---

--- libev-4.22.orig/ev.c
+++ libev-4.22/ev.c
@@ -656,8 +656,8 @@ struct signalfd_siginfo
 #ifndef ECB_MEMORY_FENCE
   #if ECB_GCC_VERSION(2,5) || defined __INTEL_COMPILER || (__llvm__ && __GNUC__) || __SUNPRO_C >= 0x5110 || __SUNPRO_CC >= 0x5110
 #if __i386 || __i386__
-  #define ECB_MEMORY_FENCE __asm__ __volatile__ ("lock; orb $0, -1(%%esp)" : : : "memory")
-  #define ECB_MEMORY_FENCE_ACQUIRE __asm__ __volatile__ ("": : : "memory")
+  #define ECB_MEMORY_FENCE __asm__ __volatile__ ("lock; orb $0, 0(%%esp)" : : : "memory")
+  #define ECB_MEMORY_FENCE_ACQUIRE __asm__ __volatile__ (""   : : : "memory")
   #define ECB_MEMORY_FENCE_RELEASE __asm__ __volatile__ ("")
 #elif ECB_GCC_AMD64
   #define ECB_MEMORY_FENCE __asm__ __volatile__ ("mfence"   : : : "memory")


signature.asc
Description: OpenPGP digital signature

Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly

[Jiri Palecek]

On 14.3.2017 01:02, Jiri Palecek wrote:



On 13.3.2017 22:57, Simon McVittie wrote:

On Mon, 13 Mar 2017 at 21:58:17 +0100, Carsten Schoenert wrote:

I had modified the warpper script in the between time a little bit
different. I've done some more effort to catch some special arguments
and get them savely prepared to the binary call.
There are for sure more than one way to get the argument passing done.

+if [[ "${ARG}" =~ ([[:space:]]|[(,|=)]) ]]; then
+TB_ARGS="${TB_ARGS} \"${ARG}\""
+else
+# No special handling needed.
+TB_ARGS="${TB_ARGS} ${ARG}"
...
+eval "${MOZ_LIBDIR}"/"${MOZ_APP_NAME}" "${TB_ARGS}"

No, that is not general and could be a security vulnerability. Consider
what would happen with an argument containing $ or ` or backslashes.
If a quoting approach is to be preferred (possibly to make the script 
POSIX-compliant without bashisms), then the easiest (general) way is 
to quote it with apostrophes:


TB_ARGS="${TB_ARGS} '$(echo "$ARG" | sed "s/'/'\\\''/")'"

Bummer. sed expression must have /g flag:

TB_ARGS="${TB_ARGS} '$(echo "$ARG" | sed "s/'/'\\\''/g")'"

Sorry
Jiri Palecek

Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly

[Daniel Kahn Gillmor]

On Mon 2017-03-13 20:02:12 -0400, Jiri Palecek wrote:
> If a quoting approach is to be preferred (possibly to make the script 
> POSIX-compliant without bashisms), then the easiest (general) way is to 
> quote it with apostrophes:

0 dkg@alice:~$ head -n1 $(which thunderbird)
#!/bin/bash
0 dkg@alice:~$ 

please let's not get into eval and lowest-common-denominator stuff if we
don't need to.  if we've got bash in the shebang line, we should make
use of bash features :)

  --dkg

Bug#857686: (no subject)

[Robert Schlabbach]

But why? The kernel image is was built, the headers, everything - only the 
dependency packages wasn't built. So was it intentionally not built?

Bug#857694: dgit: Died at /usr/bin/dgit line 2196.

[Mattia Rizzolo]

Package: dgit
Version: 3.10
Severity: important

this dgit clone fails (the .tar.xz were there from a previously failed
call of the same dgit clone command):

mattia@warren ~/devel/debian/NMU/qt4-perl % dgit -D clone qt4-perl 
clone main body
| curl -sS https://api.ftp-master.debian.org/suites -w '%{http_code}'
=> `[{"name": "backports-new", "dakname": "backports-new", "architectures": 
["all", "source"], "components": ["main", "contrib", "non-free"], "codename": 
null, "archive": "backports-new"}, {"name": "backports-policy", "dakname": 
"backports-policy", "architectures": ["all", "amd64", "armel", "i386", "ia64", 
"kfreebsd-amd64", "kfreebsd-i386", "mips", "mipsel", "powerpc", "s390", 
"source", "sparc"], "components": ["main", "contrib", "non-free"], "codename": 
null, "archive": "backports-policy"}, {"name": "buildd-experimental", 
"dakname": "buildd-experimental", "architectures": ["all", "amd64", "arm64", 
"armel", "armhf", "hurd-i386", "i386", "kfreebsd-amd64", "kfreebsd-i386", 
"mips", "mips64el", "mipsel", "powerpc", "ppc64el", "s390x", "source"], 
"components": ["main", "contrib", "non-free"], "codename": 
"buildd-experimental", "archive": "build-queues"}, {"name": 
"buildd-jessie-backports", "dakname": "buildd-jessie-backports", 
"architectures": ["all", "amd64", "arm64", "armel", "armhf", "i386", 
"kfreebsd-amd64", "kfreebsd-i386", "mips", "mipsel", "powerpc", "ppc64el", 
"s390x"], "components": ["main", "contrib", "non-free"], "codename": null, 
"archive": "build-queues"}, {"name": "buildd-oldstable-proposed-updates", 
"dakname": "buildd-oldstable-proposed-updates", "architectures": ["all", 
"amd64", "armel", "armhf", "i386", "ia64", "kfreebsd-amd64", "kfreebsd-i386", 
"mips", "mipsel", "powerpc", "s390", "s390x", "source", "sparc"], "components": 
["main", "contrib", "non-free"], "codename": "buildd-wheezy-proposed-updates", 
"archive": "build-queues"}, {"name": "buildd-proposed-updates", "dakname": 
"buildd-proposed-updates", "architectures": ["all", "amd64", "arm64", "armel", 
"armhf", "i386", "mips", "mipsel", "powerpc", "ppc64el", "s390x", "source"], 
"components": ["main", "contrib", "non-free"], "codename": 
"buildd-jessie-proposed-updates", "archive": "build-queues"}, {"name": 
"buildd-squeeze-backports", "dakname": "buildd-squeeze-backports", 
"architectures": ["all", "amd64", "armel", "i386", "ia64", "kfreebsd-amd64", 
"kfreebsd-i386", "mips", "mipsel", "powerpc", "s390", "source", "sparc"], 
"components": ["main", "contrib", "non-free"], "codename": null, "archive": 
"build-queues"}, {"name": "buildd-squeeze-backports-sloppy", "dakname": 
"buildd-squeeze-backports-sloppy", "architectures": ["all", "amd64", "armel", 
"i386", "ia64", "kfreebsd-amd64", "kfreebsd-i386", "mips", "mipsel", "powerpc", 
"s390", "source", "sparc"], "components": ["main", "contrib", "non-free"], 
"codename": null, "archive": "build-queues"}, {"name": "buildd-squeeze-lts", 
"dakname": "buildd-squeeze-lts", "architectures": ["all", "amd64", "i386", 
"source"], "components": ["main", "contrib", "non-free"], "codename": 
"buildd-squeeze-lts", "archive": "build-queues"}, {"name": 
"buildd-stable-kfreebsd-proposed-updates", "dakname": 
"buildd-stable-kfreebsd-proposed-updates", "architectures": ["all", 
"kfreebsd-amd64", "kfreebsd-i386", "source"], "components": ["main", "contrib", 
"non-free"], "codename": "buildd-jessie-kfreebsd-proposed-updates", "archive": 
"build-queues"}, {"name": "buildd-testing-proposed-updates", "dakname": 
"buildd-testing-proposed-updates", "architectures": ["amd64", "arm64", "armel", 
"armhf", "i386", "mips", "mips64el", "mipsel", "ppc64el", "s390x"], 
"components": ["main", "contrib", "non-free"], "codename": 
"buildd-stretch-proposed-updates", "archive": "build-queues"}, {"name": 
"buildd-unstable", "dakname": "buildd-unstable", "architectures": ["all", 
"amd64", "arm64", "armel", "armhf", "hurd-i386", "i386", "kfreebsd-amd64", 
"kfreebsd-i386", "mips", "mips64el", "mipsel", "powerpc", "ppc64el", "s390x", 
"source"], "components": ["main", "contrib", "non-free"], "codename": 
"buildd-sid", "archive": "build-queues"}, {"name": "buildd-wheezy-backports", 
"dakname": "buildd-wheezy-backports", "architectures": ["all", "amd64", 
"armel", "armhf", "i386", "ia64", "kfreebsd-amd64", "kfreebsd-i386", "mips", 
"mipsel", "powerpc", "s390", "s390x", "source", "sparc"], "components": 
["main", "contrib", "non-free"], "codename": null, "archive": "build-queues"}, 
{"name": "buildd-wheezy-backports-sloppy", "dakname": 
"buildd-wheezy-backports-sloppy", "architectures": ["all", "amd64", "armel", 
"armhf", "i386", "ia64", "kfreebsd-amd64", "kfreebsd-i386", "mips", "mipsel", 
"powerpc", "s390", "s390x", "sparc"], "components": ["main", "contrib", 
"non-free"], "codename": null, "archive": "build-queues"}, {"name": "byhand", 
"dakname": "byhand", "architectures": ["all", "amd64", "arm64", "armel", 
"armhf", "hurd-i386", "i386", "ia64", "kfreebsd-amd64", "kfreebsd-i386", 
"mips", "mipsel", "powerpc", 

Bug#857693: libxapian30: Incorrect results from boolean filters

[Olly Betts]

Package: libxapian30
Version: 1.4.3-1
Severity: important
Tags: patch upstream

Kirill A. Shutemov noticed some queries in notmuch were giving different
answers on a repeat run without the data having changed.

Investigating, this turns out to be a bug in xapian-core with handling
an AND operator which is unweighted (e.g. under FILTER or AND_NOT) with
a subquery which uses the passed max weight value (the obvious case is
another operator such as OR) - the maximum weights of the subqueries
aren't initialised, but are then used to compute the maximum weight a
subquery needs to return - this can result in rejecting results which
should match.

This bug is present in both 1.2.x and 1.4.x.  It's presumably actually
affected many more people, but because there's no crash it's easy to
not notice the issue.

This is fixed in upstream git:

* 1.4 branch:
  https://trac.xapian.org/changeset/7b3349f91ae8e35592fe37606c4443b80577b924/git
* 1.2 branch:
  https://trac.xapian.org/changeset/6737fa7047142e2d3ce88a5bfaf7a4b5589ade9d/git

Cheers,
Olly

Bug#857335: ledger: Please provide python3-ledger package

[David Bremner]

Brian May  writes:

> David Bremner  writes:
>
>> IMHO the right place to deal with this is upstream. And presumably upstream
>> already knows?
>
> I am not sure of the best contact for upstream. Presumable the package
> maintainer has good contacts with upstream (Matt Palmer is listed as the
> package maintainer?). Talking to upstream, like it or not, is part of
> the job of maintaining Debian packages. It makes it easier on upstream
> only having to deal with one voice, the maintainer, who knows what
> direction they want to take the package.

You are currently lecturing the de facto maintainer of ledger. Matt
hasn't done an upload since 2012.

To expand on my previous (terse) remarks, when python3 support lands
upstream, I'll have a look at packaging it. When I say upstream already
knows, it's because you pointed me to a posting on upstream's mailing
list. But in case that got lost I also filed an upstream bug

  http://bugs.ledger-cli.org/show_bug.cgi?id=1203

> After the release of stretch I believe the plan is not to accept any new
> Python 2 packages. Eventually this is going to become an RC bug as a
> result of phasing out Python 2.7.

Well, no.  python-ledger will be removed if python2 is. That's not
exactly the same thing.


signature.asc
Description: PGP signature

Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly

[Jiri Palecek]

On 13.3.2017 22:57, Simon McVittie wrote:

On Mon, 13 Mar 2017 at 21:58:17 +0100, Carsten Schoenert wrote:

I had modified the warpper script in the between time a little bit
different. I've done some more effort to catch some special arguments
and get them savely prepared to the binary call.
There are for sure more than one way to get the argument passing done.

+if [[ "${ARG}" =~ ([[:space:]]|[(,|=)]) ]]; then
+TB_ARGS="${TB_ARGS} \"${ARG}\""
+else
+# No special handling needed.
+TB_ARGS="${TB_ARGS} ${ARG}"
...
+eval "${MOZ_LIBDIR}"/"${MOZ_APP_NAME}" "${TB_ARGS}"

No, that is not general and could be a security vulnerability. Consider
what would happen with an argument containing $ or ` or backslashes.
If a quoting approach is to be preferred (possibly to make the script 
POSIX-compliant without bashisms), then the easiest (general) way is to 
quote it with apostrophes:


TB_ARGS="${TB_ARGS} '$(echo "$ARG" | sed "s/'/'\\\''/")'"

use it:


eval something "$TB_ARGS"


Of course, arrays are much more convenient when you can put up with 
bashisms.


Regards
Jiri Palecek

Bug#857692: petsc: FTBFS in !linux

[Mattia Rizzolo]

Source: petsc
Version: 3.7.5+dfsg1-4
Severity: important

petsc fails to build in hurd-i386, kfreebsd-i386 and kfreebsd-amd64.
https://buildd.debian.org/status/package.php?p=petsc

This is particularly interesting as petsc is the last package in the
archive depending on gcc-5, only in those architecture.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#848220: gcc-5 should not ship in stretch

[Mattia Rizzolo]

On Thu, Dec 15, 2016 at 10:35:16AM +0100, Matthias Klose wrote:
> remaining issues:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gcc-5-legacy;users=debian-...@lists.debian.org

All the actionable ones are done (apart from llvm-toolchain-snapshot,
which doesn't seem to explictly be using any fixed version of gcc to
me).

> gcc-5-cross and gcc-5-cross-ports should be removed from testing at the same
> time. llvm-toolchain-snapshot is only in unstable. #835940 is asking for gcc-5
> to stay in unstable, which should be fine.

According to `dak rm -Rn gcc-5 gnat-5 gcc-5-cross gcc-5-cross-ports`
nothing (build-)depends on them anymore¹.  Do you think it can be
removed from unstable too now, or does it have a particular purpose?


¹ except petsc on kfreebsd/hurd, which can be ignored if unfixed

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#857327: libapache2-authenntlm-perl: does not work with Apache 2.4

[Hamish Moffatt]

On 11/03/17 02:46, gregor herrmann wrote:


 From reading the above URLs, it seems that
 remote_addr -> client_addr
 remote_ip -> client_ip
should do the trick.

Could you maybe try this proposed fix?
If it works, we can prepare an updated package for stretch.



I tried that, and it's better - no problems on the Apache side at least.

I think it's outdated on the NTLM side, as Edge on Windows 10 was not 
able to authenticate to it. But the basic authentication fallback works 
at least, as I was able to authenticate that way from cURL.


Given that this package has been broken for years without anyone 
noticing perhaps it should be removed instead?




thanks,

Hamish

Bug#857325: libapache2-authenntlm-perl: documentation inadequate

[Hamish Moffatt]

On 11/03/17 02:48, gregor herrmann wrote:

On Fri, 10 Mar 2017 15:05:18 +1100, Hamish Moffatt wrote:


The documentation does not provide any details of how to configure this module.

There is some documentation via "perldoc Apache2::AuthenNTLM" but this isn't 
referenced in the README.

A README is only for additional information, the real documentation
is always `man Apache2::AuthenNTLM' = `perldoc Apache2::AuthenNTLM'
(which may or may not be sufficient ...).

In this case upstream seems rather inactive, so I wouldn't expect
major improvements in the documentation ...



I didn't expect to find Apache module documentation in man - certainly 
the other Apache modules I just checked do not have man pages (fastcgi, 
php5).


Perhaps you could mention the manpage in the README?


regards

Hamish

Bug#857691: lgogdownloader: crashes if you have DLC for a missing game

[Simon McVittie]

Package: lgogdownloader
Version: 3.1-1
Severity: important
Tags: patch fixed-upstream

`lgogdownloader --list` crashes if your GOG account has DLC for a game
that you don't have, for example if you accidentally added the free DLC
for The Witcher 3 like I did. It doesn't seem to be possible to remove
items from an account once they have been added, so this is not something
that affected users can work around, except by buying the corresponding
game.

This was fixed upstream shortly after 3.1.

S
diffstat for lgogdownloader-3.1 lgogdownloader-3.1

 changelog   |8 
 patches/Fix-crash-in-Website-getGames.patch |   49 
 patches/series  |1 
 3 files changed, 58 insertions(+)

diff -Nru lgogdownloader-3.1/debian/changelog lgogdownloader-3.1/debian/changelog
--- lgogdownloader-3.1/debian/changelog	2017-01-16 18:35:28.0 +
+++ lgogdownloader-3.1/debian/changelog	2017-03-13 22:27:46.0 +
@@ -1,3 +1,11 @@
+lgogdownloader (3.1-2) UNRELEASED; urgency=medium
+
+  * Team upload
+  * Backport patch from 3.2 fixing the ability to list games if a game
+has {'updates': null}
+
+ -- Simon McVittie   Mon, 13 Mar 2017 22:27:46 +
+
 lgogdownloader (3.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru lgogdownloader-3.1/debian/patches/Fix-crash-in-Website-getGames.patch lgogdownloader-3.1/debian/patches/Fix-crash-in-Website-getGames.patch
--- lgogdownloader-3.1/debian/patches/Fix-crash-in-Website-getGames.patch	1970-01-01 01:00:00.0 +0100
+++ lgogdownloader-3.1/debian/patches/Fix-crash-in-Website-getGames.patch	2017-03-13 22:27:46.0 +
@@ -0,0 +1,49 @@
+From: Sude 
+Date: Fri, 20 Jan 2017 00:15:50 +0200
+Subject: Fix crash in Website::getGames
+
+JSON value for updates can be null in some cases. For example when user owns a dlc but not the base game.
+This caused a crash due to std::stoi throwing std::invalid_argument exception
+
+Origin: upstream, 3.2, commit:22f47de4fcd8cd7ecc2a89fbb25f94efb1b3f743
+---
+ src/website.cpp | 26 +-
+ 1 file changed, 25 insertions(+), 1 deletion(-)
+
+diff --git a/src/website.cpp b/src/website.cpp
+index 0803432..8ca4c8c 100644
+--- a/src/website.cpp
 b/src/website.cpp
+@@ -163,7 +163,31 @@ std::vector Website::getGames()
+ gameItem game;
+ game.name = product["slug"].asString();
+ game.id = product["id"].isInt() ? std::to_string(product["id"].asInt()) : product["id"].asString();
+-game.updates = product["updates"].isInt() ? product["updates"].asInt() : std::stoi(product["updates"].asString());
++
++if (product.isMember("updates"))
++{
++if (product["updates"].isNull())
++{
++/* In some cases the value can be null.
++ * For example when user owns a dlc but not the base game
++ * https://github.com/Sude-/lgogdownloader/issues/101
++ * Assume that there are no updates in this case */
++game.updates = 0;
++}
++else if (product["updates"].isInt())
++game.updates = product["updates"].asInt();
++else
++{
++try
++{
++game.updates = std::stoi(product["updates"].asString());
++}
++catch (std::invalid_argument& e)
++{
++game.updates = 0; // Assume no updates
++}
++}
++}
+ 
+ unsigned int platform = 0;
+ if (product["worksOn"]["Windows"].asBool())
diff -Nru lgogdownloader-3.1/debian/patches/series lgogdownloader-3.1/debian/patches/series
--- lgogdownloader-3.1/debian/patches/series	2016-05-09 22:28:40.0 +0100
+++ lgogdownloader-3.1/debian/patches/series	2017-03-13 22:27:46.0 +
@@ -1 +1,2 @@
+Fix-crash-in-Website-getGames.patch
 manpage-whatis.patch

Bug#857660: SELinux: cannot sent policyload notice

[cgzones]

Hi list,
I created bug report against dbus 1.10 on Debian [1] due to failing to
send policyload notices.
Are there any objections or comments on the upstream patch[2]?
The patch works for me:

Mar 14 00:01:36 debianSE audit[441]: USER_AVC pid=441 uid=105
auid=4294967295 ses=4294967295
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:
received policyload notice (seqno=3)
 exe="/usr/bin/dbus-daemon"
sauid=105 hostname=? addr=? terminal=?'
Mar 14 00:01:36 debianSE dbus[441]: [system] Reloaded configuration

Best regards,
   Christian Göttsche


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857660
[2] 
https://cgit.freedesktop.org/dbus/dbus/commit/?id=a3a5935a0a038c3b44c61ce5719f0f7e647b96c6

Bug#857650: [DRE-maint] Bug#857650: ruby-json: Please build java extension

[Christian Hofstaedtler]

* Miguel Landaeta  [170313 19:45]:
> I noticed ruby-json Java extension was not being built from this
> package.
> 
> So, since I need that to get JRuby unit tests passing and it should be
> useful for real-world users, I added that missing component to this
> package.
> 
> If there are no objections to my approach (please see the debdiff
> below), I was planning to merge this and do an upload to experimental
> very soon.

Looks mostly good to me.

One thing:

> diff -Nru ruby-json-2.0.1+dfsg/debian/control 
> ruby-json-2.0.1+dfsg/debian/control
> --- ruby-json-2.0.1+dfsg/debian/control   2016-12-05 23:33:24.0 
> +
> +++ ruby-json-2.0.1+dfsg/debian/control   2017-03-13 11:54:41.0 
> +
> @@ -6,7 +6,11 @@
> Antonio Terceiro ,
> Cédric Boutillier 
>  Build-Depends: debhelper (>= 9~),
> +   default-jdk,
> gem2deb,
> +   git,
  ^^^

Is git actually needed for the build?
As far as I can see from the build log, the git call ends up
emitting just this error:

> fatal: Not a git repository (or any of the parent directories): .git

   -ch

Bug#857283: arb-common: broken symlinks: /usr/lib/arb/bin/mafft-*, /etc/arb/inputMasks/format.readme

[Pruesse, Elmar A2]

Hi, 

FYI: you can disable building those by passing "MAFFTLINKS=" as argument to 
make (overrides the variable containing the targets with empty string), or 
patching bin/Makefile accordingly.

Elmar

> On Mar 9, 2017, at 7:38 AM, Andreas Beckmann  wrote:
> 
> Package: arb-common
> Version: 6.0.6-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
>> From the attached log (scroll to the bottom...):
> 
> 2m1.8s ERROR: FAIL: Broken symlinks:
>  /usr/lib/arb/bin/mafft-xinsi -> mafft
>  /usr/lib/arb/bin/mafft-qinsi -> mafft
>  /usr/lib/arb/bin/mafft-nwnsi -> mafft
>  /usr/lib/arb/bin/mafft-nwns -> mafft
>  /usr/lib/arb/bin/mafft-linsi -> mafft
>  /usr/lib/arb/bin/mafft-ginsi -> mafft
>  /usr/lib/arb/bin/mafft-fftnsi -> mafft
>  /usr/lib/arb/bin/mafft-fftns -> mafft
>  /usr/lib/arb/bin/mafft-einsi -> mafft
>  /etc/arb/inputMasks/format.readme -> ../help/input_mask_format.hlp
> 
> There is /usr/lib/arb/lib/help/input_mask_format.hlp ...
> 
> 
> cheers,
> 
> Andreas
> 

Bug#748716: Bug#857525: libreswan: [INTL:de] updated German debconf translation

[Daniel Kahn Gillmor]

On Sun 2017-03-12 01:41:04 -0500, Helge Kreutzmann wrote:
> Please find the updated German debconf translation for libreswan
> attached.

I'm closing this bug report (#857525) because it seems you've translated
a part of upstream that doesn't exist in the debian packages.  This is
the same situation as https://bugs.debian.org/855475, which i also
closed.

I think the fact that you did extra (unnecessary) labor was caused by a
bug in the l10n scripts tools (https://bugs.debian.org/748716), which
needs attention.

sorry that you did work that didn't need doing!

  --dkg

Bug#857578: [Pkg-dns-devel] Bug#857578: knot-resolver: The package should not override blindly the config of trust anchors

[Daniel Kahn Gillmor]

On Sun 2017-03-12 16:45:40 -0400, Stephane Bortzmeyer wrote:
> I tried an alternative root and therefore set up trust_anchors.config
> to use the key of this alternative root.
>
> But, by default, the daemon is launched with
> --keyfile=/usr/share/dns/root.key and therefore uses the IANA key ->
> SERVFAIL
>
> I edited /etc/default/kresd, and fixed the problem, but I do not see
> why there are two configuration files, /etc/knot-resolver/kresd.conf
> and /etc/default/kresd. IMHO, the choices made by the sysadmin in
> /etc/knot-resolver/kresd.conf should be respected.

fwiw, i agree with Stephane here, and would actually take it further: i
think it would be great to strip down both /etc/default/kresd and
/etc/knot-resolver/kresd.conf to the point where we don't ship either of
them in the package.

This would result in a kresd that has no default configuration file,
since it is run from /run/knot-resolver/cache and so looks for
/run/knot-resolver/cache/config for its configuration file, which won't
exist because it was created by /usr/lib/tmpfiles.d/kresd.conf.

On systems managed by systemd, the local admin can use "systemctl edit
kresd.service" to override the ExecStart= directive in the [Service]
stanza to point to some preferred configuration with --config, or
override the WorkingDirectory= directive to point to both a preferred
configuration and a stable/persistent cache.  We could add documentation
explaining this approach in README.Debian if it's considered too obscure
at the moment.

That would leave the default knot-resolver package with only
/etc/knot-resolver/icann-ca.pem and /etc/init.d/kresd as configfiles.

I'd argue that we should be shipping icann-ca.pem in some other more
stable (non-config) location (and possibly not in this particular
package) since it's likely to be useful for other system processes too.
And i'd be happy to see /etc/init.d/kresd moved into a
knot-resolver-sysvinit package for those who want to see it run under
that system manager.  (by analogy, a knot-resolver-runit package for
those who want to see it run under runit would also be nice-to-have)

This configfile cleanup would still leave us with Stephane's open
question about how to choose the default trust anchors, and how to
override them.

Note that there are different behaviors for handling the trust anchors
in "managed" or "unmanaged" mode, e.g.:

   https://gitlab.labs.nic.cz/knot/resolver/merge_requests/134

By default, i think kresd bootstraps trust anchors from IANA over the
network.  Including --keyfile=/usr/share/dns/root.key explicitly in the
service handles things but it also breaks configurations like
Stephane's.

I've just opened an upstream report about improving that here:

   https://gitlab.labs.nic.cz/knot/resolver/issues/168

--dkg


PS other possible approaches to having a well-known "default
configuration" location for systemd-managed systems:

tmpfiles


We could add a line to /usr/lib/tmpfiles.d/kresd.conf to make it copy
the system configuration at machine startup:

   C /run/knot-resolver/cache/config - - - - /etc/knot-resolver/kresd.conf

but this would hvae the unpleasant property of any edits to
/etc/knot-resolver/kresd.conf not taking effect until system reboot.


ExecStart etc.
--

Alternately, we could add an explicit directive to kresd.service:

   ExecStartPre=/bin/cp /etc/knot-resolver/kresd.conf 
/run/knot-resolver/cache/config

that would at least transfer a stable config at service start.

We might want to figure out how to set up an ExecReload as well if
we want that to work.

But this starts to feel like a lot of heavy machinery, when the default
service should Just Work and it'd be nice that case be simple.



signature.asc
Description: PGP signature

Bug#857690: RFS: moka-icon-theme/5.3.5-2

[foss.freedom]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "moka-icon-theme"

 * Package name: moka-icon-theme
   Version : 5.3.5-2
   Upstream Author : Sam Hewitt 
 * URL : github.com/snwh/moka-icon-theme
 * License : GPL-3+/CC-BY-SA-4.0
   Section : misc

  It builds those binary packages:

moka-icon-theme - Tango-esque desktop icon set called Moka

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

  https://mentors.debian.net/package/moka-icon-theme


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

dget -x 
https://mentors.debian.net/debian/pool/main/m/moka-icon-theme/moka-icon-theme_5.3.5-1.dsc

Notes:
  have run linitian -i -I on both the sources and built .changes

As explained below - I have isolated the fix from upstream to the core
changes needed to resolve this bug.  I wasn't too sure if I should tag
this RC.  I've tested stretch with budgie-desktop and libreoffice and
I can confirm the bug is present in stretch.

If you do not consider this worthy for inclusion for stretch, IMHO it
is certainly suitable for further testing in unstable.  TIA for
consideration of this issue.

  Changes since the last upload:

   * bug-fix release
- add patch fix-overly-large-icons to resolve some applications
  scaling icons incorrectly

This is explained further in the patch-header

Description: fix overly large icons
 Due to a typo in index.theme, some applications incorrectly
 scale icons. The Type= parameter is case-sensitive and all instances
 of "scalable" should be "Scalable"
 .
 Upstream commit 87373de8d7e2c8ad1975174a46bfdb2d3cc7a40f
 resolves this issue - but the above commit is combined
 with a much larger set of changes.
Author: David Mohammed 
Origin: other
Bug: https://github.com/snwh/moka-icon-theme/issues/279
Forwarded: not-needed
Last-Update: 2017-03-13


  Regards,
   David Mohammed

Bug#851927: Raise severity?

[Alberto Bertogli]

Hi!

So now that testing is frozen in preparation for the upcoming release,
the behaviour users of the next Debian stable will be:

 - Cannot install extensions from the standard store (as they do in all
   other platforms).
 - Extensions they already have will stop working.
 - They won't be able to use Debian's package manager to install
   extensions either, as there is only a single one available.

While a workaround exists (editing a file in /etc), I think it's not
practical to expect users of a web browser know how to do it.


This situation seems quite unfortunate and I think will, in practice,
end up affecting a lot of users, specially the non-technical ones.

Can you consider raising the priority of this issue to serious/critical,
and allowing extensions by default again?

Thanks,
Alberto

Bug#857494: blender: Mouse pointer disappears / moved off screen

[Svein Engelsgjerd]

Package: blender
Version: 2.78.a+dfsg0-4
Followup-For: Bug #857494

Dear Maintainer,

I usually use blender om my 1st screen which are positioned to the left of my 
other two screens.
It only appears that the mousepointer disappears if blender is started on one 
of the two screens that are positioned to the right of the usual screen.
Not sure, but perhaps this have to do with the screen coordinates.
If the left begins at x0-1600,y0-1200 and the second begins at 
x1601-2881,y0-1024, third at x2882-4482 then it apperas that the mousepointer 
always
goes back to the first screen.
[screen1] - [screen2] - [screen3]

I usually use screen2 as the default screen with various programs running on 
screen1 and 3. Right now I have a power supply issue with my 1st screen
so it sometimes won't start up and other times it does. That is the reason I am 
using blender on other screens.

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

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

Versions of packages blender depends on:
ii  blender-data  2.78.a+dfsg0-4
ii  fonts-dejavu  2.37-1
ii  libavcodec57  7:3.2.4-1
ii  libavdevice57 7:3.2.4-1
ii  libavformat57 7:3.2.4-1
ii  libavutil55   7:3.2.4-1
ii  libboost-atomic1.62.0 1.62.0+dfsg-4
ii  libboost-chrono1.62.0 1.62.0+dfsg-4
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libboost-filesystem1.62.0 1.62.0+dfsg-4
ii  libboost-iostreams1.62.0  1.62.0+dfsg-4
ii  libboost-locale1.62.0 1.62.0+dfsg-4
ii  libboost-regex1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0 1.62.0+dfsg-4
ii  libboost-thread1.62.0 1.62.0+dfsg-4
ii  libc6 2.24-9
ii  libfftw3-double3  3.3.5-3
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3+b2
ii  libgcc1   1:6.3.0-6
ii  libgl1-mesa-glx [libgl1]  13.0.5-1
ii  libglew2.02.0.0-3+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgomp1  6.3.0-6
ii  libilmbase12  2.2.0-12
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-4+b1
ii  libjemalloc1  3.6.0-9.1
ii  libjpeg62-turbo   1:1.5.1-2
ii  libopenal11:1.17.2-4+b2
ii  libopencolorio1v5 1.0.9~dfsg0-6+b2
ii  libopenexr22  2.2.0-11+b1
ii  libopenimageio1.6 1.6.17~dfsg0-1+b2
ii  libopenjp2-7  2.1.2-1.1
ii  libopenvdb3.2 3.2.0-2.1
ii  libpcre3  2:8.39-2.1
ii  libpng16-16   1.6.28-1
ii  libpython3.5  3.5.3-1
ii  libsndfile1   1.0.27-1+b1
ii  libspnav0 0.2.3-1
ii  libstdc++66.3.0-6
ii  libswscale4   7:3.2.4-1
ii  libtbb2   4.3~20150611-2
ii  libtiff5  4.0.7-5
ii  libx11-6  2:1.6.4-3
ii  libxi62:1.7.9-1
ii  libxml2   2.9.4+dfsg1-2.2
ii  libxxf86vm1   1:1.1.4-1
pn  python3:any   
ii  zlib1g1:1.2.8.dfsg-5

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#849065: janus depends on libsrtp-dev (>= 1.5)

[Victor Seva]

El 13 mar. 2017 20:14, "Jonas Smedegaard"  escribió:

I am ready to release Janus now.  You wanted notice first?


Pong.

Go ahead, great work.

Bug#857689: dpkg: Fails to install evolution-dbgsym

[Paul Menzel]

Package: dpkg
Version: 1.18.23
Severity: normal

Dear Maintainer,


This morning installing a package with `apt` resulted in the error
below.

```
$ sudo apt install libevolution-dbgsym
[…]
Vormals nicht ausgewähltes Paket evolution-dbgsym wird gewählt.
dpkg: ../../src/filesdb.c:604: findnamenode: Zusicherung »(*pointerp)->name[0] 
== '/'«  nicht erfüllt.
[…]
```

(The translition is something like: “Assurance »(*pointerp)->name[0] ==
'/'« »(*pointerp)->name[0] == '/'« not valid.”)

Unfortunately, I did not save more of the output. Running the same
command this evening, everything worked. Also this noon on a different
system, I couldn’t reproduce this.

Note, that the system, where this happened uses a 32-bit user space.


Thanks,

Paul

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-9
ii  liblzma5 5.2.2-1.2+b1
ii  libselinux1  2.6-3
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-5

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.4~rc2
pn  debsig-verify  

-- no debconf information

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

Bug#857678: use /run prefix in systemd socket unit

[Simon McVittie]

On Mon, 13 Mar 2017 at 21:58:46 +0100, cgzones wrote:
> Since recently the reference policy defines the file contexts with
> /run prefixes [1] and only supports /var/run via a backward
> compatibility alias.

Is that backwards compatibility alias available in the stretch version
of the reference policy?

How old is the first reference policy where the /run version works?

How far in the future is the backwards compatibility alias expected to
go away?

> Please alter the path from /var/run/dbus/system_bus_socket to
> /run/dbus/system_bus_socket in /usr/lib/systemd/system/dbus.socket to
> avoid wrong file contexts in the future.

For better or worse, the canonical, interoperable path for the system
bus socket across multiple OS distributions is
/var/run/dbus/system_bus_socket (it has been that since long before
/run was widespread). If /var/run is equivalent to /run, then it shouldn't
matter either way. If /var/run is not equivalent to /run, then the version
we should probably prefer is /var/run.

S

Bug#857688: mkvtoolnix: README.source is a dangling symlink

[Johan Haggi]

Package: mkvtoolnix
Version: 9.8.0-dmo1
Severity: minor

ls -l /usr/share/doc/mkvtoolnix/README.source 
lrwxrwxrwx 1 root root 22 gen 22 17:26 /usr/share/doc/mkvtoolnix/README.source 
-> ../quilt/README.source

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386- no debconf information
-- 
Cura ut valeas
Johan Haggi
ante diem tertium Idus Martias MMDCCLXX ab Urbe condita


signature.asc
Description: PGP signature

Bug#856724: [INTL:da] Danish translation of the template apt-listbugs

[Francesco Poli]

On Sat, 4 Mar 2017 18:45:29 +0100 Francesco Poli wrote:

> On Sat, 4 Mar 2017 12:04:36 + (UTC) Joe Dalton wrote:
> 
> [...]
> > Please include the attached Danish apt-listbugs translation.
> > Proofreading has given some small corrections.
> [...]
> 
> Thanks for the update, I will soon take a look at it.

Here I am, sorry for the delay.

I have a question for you.

Is there a specific reason why "severity" is translated with
"alvorlighed" in two sentences, but with "vigtighed" in a third
sentence?

Can I change

  #: ../lib/aptlistbugs/logic.rb:230
  msgid "Bugs of severity %s"
  msgstr "Fejl med vigtigheden %s"

into

  #: ../lib/aptlistbugs/logic.rb:230
  msgid "Bugs of severity %s"
  msgstr "Fejl med alvorligheden %s"

?

Please let me know, so that we can further improve the translation!


P.S.: Please note that I know nothing about the Danish language, hence
I may be completely off-track. Please bear with me!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpuI2PPmrPq6.pgp
Description: PGP signature

Bug#788769: marked as done (entangle: FTBFS without networking: relax-ng: failed to load external entity [..] mallard-1.0.rng)

[Florian Schlichting]

Hi Michael,

On Fri, Mar 10, 2017 at 07:26:58PM +0100, Michael Biebl wrote:
> On Sun, 26 Feb 2017 17:00:22 +0100 Florian Schlichting 
> > Given that it's too late now to get a mallard-rng package into Stretch,
> > I suggest to ship the mallard-1.0.rng file as part of the yelp-tools
> > package for now (e.g. as /usr/share/yelp-tools/mallard/mallard-1.0.rng)
> > and simply use that as relaxng schema in yelp-check:
> 
> Let's go with this approach for stretch and see if we can improve the
> situation in buster.
> 
> Florian, can you send us a complete debdiff, which includes the
> installation of the mallard-rng schema, changelog entry etc.

please find attached the source diff, with which I built the package for
testing and from which I'd build the NMU. Feel free to massage the
changelog to your liking, or any other part of the patch, really.

Florian
>From 68378f6d7a412db85e6e5839812301b3ba136c54 Mon Sep 17 00:00:00 2001
From: Florian Schlichting 
Date: Mon, 13 Mar 2017 22:27:33 +0100
Subject: [PATCH] Ship a copy of mallard-1.0.rng and use that in yelp-check
 instead of downloading the same file every time. Closes: #788769

---
 debian/changelog   |8 +
 debian/mallard-1.0.rng | 2158 
 debian/patches/local-mallard-rng.patch |   60 +
 debian/patches/series  |1 +
 debian/yelp-tools.install  |1 +
 5 files changed, 2228 insertions(+)
 create mode 100644 debian/mallard-1.0.rng
 create mode 100644 debian/patches/local-mallard-rng.patch
 create mode 100644 debian/patches/series
 create mode 100644 debian/yelp-tools.install

diff --git a/debian/changelog b/debian/changelog
index 209a0c0..b348298 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+yelp-tools (3.18.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Ship a copy of mallard-1.0.rng and use that in yelp-check instead of
+downloading the same file every time. Closes: #788769
+
+ -- Florian Schlichting   Sun, 26 Feb 2017 16:30:17 +0100
+
 yelp-tools (3.18.0-2) unstable; urgency=medium
 
   * Convert from cdbs to dh.
diff --git a/debian/mallard-1.0.rng b/debian/mallard-1.0.rng
new file mode 100644
index 000..81a26c8
--- /dev/null
+++ b/debian/mallard-1.0.rng
@@ -0,0 +1,2158 @@
+
+http://relaxng.org/ns/structure/1.0;
+xmlns:mal="http://projectmallard.org/1.0/;
+ns="http://projectmallard.org/1.0/;>
+
+
+  
+
+
+
+  
+
+
+  
+
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+  http://www.w3.org/2001/XMLSchema-datatypes"/>
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+  
+
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+  http://www.w3.org/2001/XMLSchema-datatypes"/>
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+  
+
+
+
+  
+
+  
+
+  
+
+
+
+  
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+  
+
+
+
+  
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+  http://www.w3.org/2001/XMLSchema-datatypes"/>
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+
+  
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+
+  
+
+
+  
+
+
+
+  
+
+  http://www.w3.org/2001/XMLSchema-datatypes"/>
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+
+  
+
+
+  
+
+
+
+  
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+  
+
+
+
+  
+
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+  
+http://www.w3.org/2001/XMLSchema-datatypes"/>
+  
+
+
+  
+
+  
+
+
+  
+
+  
+

Bug#857660: SELinux: cannot sent policyload notice

[Simon McVittie]

On Mon, 13 Mar 2017 at 20:52:47 +0100, cgzones wrote:
> on SELinux enabled systems, dbus cannot send the policyload notification.
> 
> There is already a thread over at redhat [1], and bug reports at
> redhat [2] and dbus [3].
> Please, cherry-pick the fix from upstream [4].

The reason it's only in 1.11.x so far, and not the 1.10.x stable branch,
is that nobody who uses/knows SELinux seemed to be able to confirm that
this is in fact correct. Is it correct? Does it work?

If the combination of D-Bus and SELinux is important to you, it would be
great to have a regular reviewer/tester who we can cc on SELinux-related
patches. I know a reasonable amount about AppArmor, but I don't use
SELinux, and the SELinux-specific code often doesn't have anyone willing
to say that they're confident it's correct.

S

Bug#857687: mutt: Please release NeoMutt 2017-03-06

[Ivan Vucica]

Package: mutt
Version: 1.7.2-1
Severity: wishlist

Dear Maintainer,

Please release NeoMutt 2017-03-06 (Mutt 1.8.0 plus a few more fixes).

I strongly care about "Increase ACCOUNT.pass field size. (closes #3921)"; right
now, the password field is too short to pass through the Google OAuth2 access
token into the libsasl2 xoauth2 authentication method.

Thanks!

-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 3.16.0-4-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-2' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-sy
 stem-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20161229 (Debian 6.3.0-2) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D
 _FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS 
+HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET 
+HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM 
+HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS 
+USE_COMPRESSED +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX 
+USE_GSS +USE_HCACHE +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL 
+USE_SETGID +USE_SIDEBAR +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-forwref-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-kyoto-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt
patch-sensible-browser-neomutt
patch-sidebar-neomutt
patch-skip-quoted-neomutt

Bug#857686: linux-image-marvell for jessie-backports release 4.9+79~bpo8+1 not properly released

[Robert Schlabbach]

Package: linux-image-marvell
Version: 4.9+78~bpo8+1

The package linux-image-marvell for jessie-backports is in a broken state, as 
can be seen on the debian package website:

https://packages.debian.org/jessie-backports/linux-image-marvell

it shows version "4.9+78~bpo8+1" and a dependency on 
"linux-image-4.9.0-0.bpo.1-marvell" which is shown as "Package not available".

The links on the right side to the Changelog and the Download all refer to 
version "79~bpo8+1". That version has the correct dependency (ABI was bumped to 
bpo.2), but somehow it is not properly released.

apt on the target machine also only finds the old version "4.9+78~bpo8+1".

So it looks like the new version "79~bpo8+1" did not make it into the release 
database correctly. As a result, the Linux kernel dependencies on the target 
machine are also in a weird state, as the bpo.2 releases show up as currently 
not installed instead of as updates to the bpo.1 release.

Best Regards,
Robert Schlabbach

Bug#857685: ITP: minetest-mod-craftguide -- Minetest mod providing a crafting guide

[Julien Puydt]

Package: wnpp
Severity: wishlist

* Package name: minetest-mod-craftguide
  Version : 1.0
  Upstream Author : kilbith
* URL : https://github.com/minetest-mods/craftguide
* License : GPL-3
  Programming Lang: Lua
  Description : Minetest mod providing a crafting guide
 This minetest extension adds a crafting guide to the game, usable with
 a blue book named "Crafting guide" and two modes: standard and progressive.
 .
 It is the most comprehensive with the cleanest code of its category.

I plan to package it within the Debian Games Team repository, were other
minetest-mod-* packages already are.

Snark on #debian-games

Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly

[Simon McVittie]

On Mon, 13 Mar 2017 at 21:58:17 +0100, Carsten Schoenert wrote:
> I had modified the warpper script in the between time a little bit
> different. I've done some more effort to catch some special arguments
> and get them savely prepared to the binary call.
> There are for sure more than one way to get the argument passing done.

+if [[ "${ARG}" =~ ([[:space:]]|[(,|=)]) ]]; then
+TB_ARGS="${TB_ARGS} \"${ARG}\""
+else
+# No special handling needed.
+TB_ARGS="${TB_ARGS} ${ARG}"
...
+eval "${MOZ_LIBDIR}"/"${MOZ_APP_NAME}" "${TB_ARGS}"

No, that is not general and could be a security vulnerability. Consider
what would happen with an argument containing $ or ` or backslashes.

The attached script is a simplified version of that change. The goal is that
the input parses the same as the output.

$ ./t.sh hello
in: argv[1]=«hello»
out: argv[1]=«hello»
$ ./t.sh foo bar
in: argv[1]=«foo»
in: argv[1]=«bar»
out: argv[1]=«foo»
out: argv[1]=«bar»

So far so good, but quote marks and backslashes get lost:

$ ./t.sh "'foo bar'"
in: argv[1]=«'foo bar'»
out: argv[1]=«foo bar»
$ ./t.sh '\a'
in: argv[1]=«\a»
out: argv[1]=«a»

it's easy to get a syntax error:

$ ./t.sh "\""
in: argv[1]=«"»
./t.sh: eval: line 32: unexpected EOF while looking for matching `"'
./t.sh: eval: line 33: syntax error: unexpected end of file

and a maliciously supplied filename or argument (think invoking
thunderbird as a file or URL handler) can cause code execution
(imagine expr was a malicious command here):

$ ./t.sh '$(expr 2 + 2)'
in: argv[1]=«$(expr 2 + 2)»
out: argv[1]=«4»
$ ./t.sh '`expr 2 + 2`'
in: argv[1]=«`expr 2 + 2`»
out: argv[1]=«4»

Please use bash arrays as Daniel suggested: that is almost certainly
the simplest way to make this correct.

S


t.sh
Description: Bourne shell script

Bug#857684: unblock: ksirk/4:16.04.0-1.1

[John Paul Adrian Glaubitz]

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

Hi!

ksirk 4:16.04.0-1.1 contains a trivial patch which fixes the
FTBFS of ksirk on all architectures where char is unsigned
by default.

Thanks,
Adrian

unblock ksirk/4:16.04.0-1.1

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

Kernel: Linux 4.9.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)
diff -Nru ksirk-16.04.0/debian/changelog ksirk-16.04.0/debian/changelog
--- ksirk-16.04.0/debian/changelog  2016-05-21 23:36:29.0 +0200
+++ ksirk-16.04.0/debian/changelog  2017-03-06 10:44:11.0 +0100
@@ -1,3 +1,11 @@
+ksirk (4:16.04.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch: fix-signage-of-tbl-array.diff to fix FTBFS on
+architectures where 'char' is unsigned. (Closes: #856904)
+
+ -- John Paul Adrian Glaubitz   Mon, 06 Mar 2017 
10:44:11 +0100
+
 ksirk (4:16.04.0-1) unstable; urgency=medium
 
   [ Automatic packaging ]
diff -Nru ksirk-16.04.0/debian/patches/fix-signage-of-tbl-array.diff 
ksirk-16.04.0/debian/patches/fix-signage-of-tbl-array.diff
--- ksirk-16.04.0/debian/patches/fix-signage-of-tbl-array.diff  1970-01-01 
01:00:00.0 +0100
+++ ksirk-16.04.0/debian/patches/fix-signage-of-tbl-array.diff  2017-03-06 
10:41:34.0 +0100
@@ -0,0 +1,15 @@
+Description: Fix signage of tbl array in XMPP code
+Author: John Paul Adrian Glaubitz 
+Last-Update: 2017-03-06
+
+--- ksirk-16.04.0.orig/ksirk/iris/src/xmpp/base64/base64.cpp
 ksirk-16.04.0/ksirk/iris/src/xmpp/base64/base64.cpp
+@@ -45,7 +45,7 @@ QByteArray Base64::decode(const QString&
+   // 64 specifies eof
+   // everything else specifies data
+ 
+-  char tbl[] = {
++  signed char tbl[] = {
+   -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
+   -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
+   -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,62,-1,-1,-1,63,
diff -Nru ksirk-16.04.0/debian/patches/series 
ksirk-16.04.0/debian/patches/series
--- ksirk-16.04.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ ksirk-16.04.0/debian/patches/series 2017-03-06 10:44:09.0 +0100
@@ -0,0 +1 @@
+fix-signage-of-tbl-array.diff

Bug#857205: flash-kernel: Add support for TI OMAP4 PandaBoard-ES

[Uwe Kleine-König]

Control: tag -1 + pending

Hello,

On Thu, Mar 09, 2017 at 08:34:24AM +0100, Marc Kleine-Budde wrote:
> On 03/09/2017 02:35 AM, Sebastian Reichel wrote:
> > On Wed, Mar 08, 2017 at 08:53:50PM +, Marc Kleine-Budde wrote:
> >> +Machine: TI OMAP4 PandaBoard-ES
> >> +Kernel-Flavors: armmp armmp-lpae
> > 
> > OMAP4 is Cortex A9, so no LPAE support.
> 
> Thanks, fixed in v2 - see attachment.

I just committed this to git.

Thanks
Uwe


signature.asc
Description: PGP signature

Bug#854496: python-qtpy: FTBFS randomly (failing tests)

[Ghislain Vaillant]

On Mon, 2017-03-13 at 22:19 +0100, Santiago Vila wrote:
> On Mon, Mar 13, 2017 at 09:40:14AM +, Ghislain Vaillant wrote:
> > Could you try the following debdiff, please?
> 
> The proposed patch does not fix the FTBFS problem.
> See attach (but I also tried several more times).

Apart from the -a option, I don't have any other ideas besides using
pytest-xvfb.

> In case you want to reproduce this for yourself, I wrote a description
> of my build environment here:
> 
> https://people.debian.org/~sanvila/my-building-environment.txt
> 
> I would consider disabling the test suite (maybe to enable it again
> after the release of Debian 9).

I believe you are right, let's disable the tests for Stretch and re-
enable them in Buster using pytest-xvfb. I'll keep the autopkgtests
alive though since deb-ci seems to work.

Ghis

Bug#850464: nfs-blkmap.service fails to start at boot

[Nye Liu]

On Sat, Mar 11, 2017 at 08:15:02PM +0100, Andreas Henriksson wrote:
> Could you please test editing nfs-blkmap.service on your system
> and replace:
> PIDFile=/var/run/blkmapd.pid
> with:
> PIDFile=/run/blkmapd.pid
> .. and report back if that solves the issue or not?

Yes, this fixes the issue.

BTW, I am not sure who else to ask about this, but
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539201
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738063

are somewhat related.

There are a lot of problems with the systemd migration, and
none of them are getting fixed.

They're mostly related to nfs-common being disabled in systemd,
and partly due to stuff missing in /etc/init.d/nfs-kernel-server

If a user is expecting any of the following (due to their old
configuration in /etc/default):

enable nfs v2
disable nfs v3
disable nfs v4
statd
idmapd
blkmap
etc.

their system will be utterly broken, since each has to be manually
enabled via systemctl enable, and/or both
/etc/default/nfs-kernel-server and /etc/init.d/nfs-kernel-server have
to be patched.

In short, nfs-kernel-server is broken with systemd and nobody seems to
be addressing any of the issues.

I think there needs to a be a single unifying bug that summarizes all
of the current systemd/nfs issues so they can be addressed in a
coherent, multilateral manner.

Thanks for your time and attention, hopefully someone can take over
the mess...


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#856864: liblldb-3.8-dev: broken symlinks: /usr/lib/llvm-3.8/lib/liblldb*.so

[Andreas Beckmann]

Followup-For: Bug #856864
Control: clone -1 -2
Control: reassign -2 liblldb-3.9-dev
Control: found -2 1:3.9.1-4
Control: retitle -2 liblldb-3.9-dev: broken symlinks: 
/usr/lib/llvm-3.9/lib/liblldb*.so

Hi,

this issue also shows up in liblldb-{3.9,4.0,5.0}-dev. Sorry for missing
this earlier.

0m35.9s ERROR: FAIL: Broken symlinks:
  /usr/lib/llvm-3.9/lib/liblldb.so -> liblldb-3.9.so
  /usr/lib/llvm-3.9/lib/liblldb-3.9.so -> liblldb-3.9.so.1
  /usr/lib/llvm-3.9/lib/liblldb-3.9.1.so -> liblldb-3.9.so

0m31.2s ERROR: FAIL: Broken symlinks:
  /usr/lib/llvm-4.0/lib/liblldb.so -> liblldb-4.0.so
  /usr/lib/llvm-4.0/lib/liblldb-4.0.so -> liblldb-4.0.so.1
  /usr/lib/llvm-4.0/lib/liblldb-4.0.0.so -> liblldb-4.0.so

0m39.9s ERROR: FAIL: Broken symlinks:
  /usr/lib/llvm-5.0/lib/liblldb.so -> liblldb-5.0.so
  /usr/lib/llvm-5.0/lib/liblldb-5.0.so -> liblldb-5.0.so.1
  /usr/lib/llvm-5.0/lib/liblldb-5.0.0.so -> liblldb-5.0.so


Andreas


liblldb-3.9-dev_1:3.9.1-5.log.gz
Description: application/gzip

Bug#857335: ledger: Please provide python3-ledger package

[Brian May]

David Bremner  writes:

> IMHO the right place to deal with this is upstream. And presumably upstream
> already knows?

I am not sure of the best contact for upstream. Presumable the package
maintainer has good contacts with upstream (Matt Palmer is listed as the
package maintainer?). Talking to upstream, like it or not, is part of
the job of maintaining Debian packages. It makes it easier on upstream
only having to deal with one voice, the maintainer, who knows what
direction they want to take the package.

Also should point out there is a strong push at the moment to move
Debian to Python 3.x, as Python 2.7 is no longer being developed
anymore.

After the release of stretch I believe the plan is not to accept any new
Python 2 packages. Eventually this is going to become an RC bug as a
result of phasing out Python 2.7.
-- 
Brian May 

Bug#857309: kodi: 'kodi' user does not exist

[Moritz Schmidt]

Hi Balint,

thanks for your reply!

On 13.03.2017 20:36, Bálint Réczey wrote:

Control: severity -1 wishlist
Control: tags -1 confirmed

Hi Moritz,

2017-03-09 21:55 GMT+01:00 Moritz Schmidt :

Package: kodi
Version: 2:17.0+dfsg1-3
Severity: important

Dear maintainer,

I installed the kodi package on a fresh installed debian testing and enabled 
the kodi systemd-service which should start kodi in standalone mode.
The service file (/lib/systemd/system/kodi.service) is configured to run as 
'kodi' user, but this user doesn't exist after installation.
I think automatically adding the user when using him would make sense.

It would make sense if every installation used the kodi user, but
there are many people who start kodi from their normal session or set
up automatic logging in in the display manager to start kodi [1].

I was thinking about adding a debconf question about adding the kodi
user and enabling  the standalone mode during package configuration
but this is about the same amount of added complexity as the current
manual addition of the kodi user.

I think if someone sets up a system for kodi only the first added user
is usually the user which runs kodi anyway.


Yeah, a debconf question would be wonderful! I think that many prefer to 
just hit yes instead of setting it up on your own with all the hassle, 
but maybe I'm just lazy.



AFAIK the kodi-systemd-service way is preferred on constrained systems
where running even lightdm would waste too much memory,
but I have just found nodm [2] which could also help here.


If you don't have to - why would you want to use a DM? The 
kodi-systemd-service starts kodi via xinit so why would you need that on 
a standalone-system?



After adding the user everything works as expected.

Great!

I will consider adding the debconf question and creating the kodi
user, but not by default.

Thanks for your work and have a nice day,
Moritz Schmidt

Thanks!

Cheers,
Balint

[1] http://kodi.wiki/view/HOW-TO:Autostart_Kodi_for_Linux
[2] https://packages.qa.debian.org/n/nodm.html



Thanks again for your time and effort,
Moritz

Bug#857681: python-lldb-3.7: broken symlinks: /usr/lib/llvm-3.7/lib/python2.7/site-packages/lldb/*

[Andreas Beckmann]

Package: python-lldb-3.7
Version: 1:3.7.1-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m36.5s ERROR: FAIL: Broken symlinks:
  /usr/lib/llvm-3.7/lib/python2.7/site-packages/lldb/libLLVM-3.7.so.1 -> 
../../../x86_64-linux-gnu/libLLVM-3.7.1.so.1
  /usr/lib/llvm-3.7/lib/python2.7/site-packages/lldb/libLLVM-3.7.1.so.1 -> 
../../../x86_64-linux-gnu/libLLVM-3.7.1.so.1
  /usr/lib/llvm-3.7/lib/python2.7/site-packages/lldb/argdumper -> 
../../../../bin/argdumper
  /usr/lib/llvm-3.7/lib/python2.7/site-packages/lldb/_lldb.so -> 
../../../liblldb.so

libLLVM-3.7.1.so.1 is in llvm-3.7-dev
argdumper does not exist in 3.7
liblldb.so does not exist in 3.7

This bug seems to be specific to 3.7, I don't see something similar
in the newer releases.


cheers,

Andreas


python-lldb-3.7_1:3.7.1-3.log.gz
Description: application/gzip

Bug#857682: vlc-plugin-vlsub: unusable - needs to move to /usr/share/vlc/lua/extensions

[Sebastian Ramacher]

Package: vlc-plugin-vlsub
Version: 0.9.13-1
Severity: grave
Justification: renders package unusable

/usr/lib/vlc/lua/extensions is no longer on the Lua script search path, so the
script included in vlc-plugin-vlsub will not be loaded. It should move to
/usr/share/vlc/lua/extensions instead.

Also, since vlc itself now included the vlsub plugin, maybe this package should
simply be removed.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#854496: python-qtpy: FTBFS randomly (failing tests)

[Santiago Vila]

On Mon, Mar 13, 2017 at 09:40:14AM +, Ghislain Vaillant wrote:
> Could you try the following debdiff, please?

The proposed patch does not fix the FTBFS problem.
See attach (but I also tried several more times).

In case you want to reproduce this for yourself, I wrote a description
of my build environment here:

https://people.debian.org/~sanvila/my-building-environment.txt

I would consider disabling the test suite (maybe to enable it again
after the release of Debian 9).

Thanks.

python-qtpy_1.2.1-2_amd64-20170313T210329Z.gz
Description: application/gzip

Bug#857680: llvm-3.8-examples: broken symlinks: /usr/share/doc/llvm-3.8-examples/Makefile.* -> ../../../lib/llvm-3.8/build/Makefile.*

[Andreas Beckmann]

Package: llvm-3.8-examples
Version: 1:3.8.1-18
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m26.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/llvm-3.8-examples/Makefile.rules -> 
../../../lib/llvm-3.8/build/Makefile.rules
  /usr/share/doc/llvm-3.8-examples/Makefile.config -> 
../../../lib/llvm-3.8/build/Makefile.config
  /usr/share/doc/llvm-3.8-examples/Makefile.common -> 
../../../lib/llvm-3.8/build/Makefile.common

llvm-3.7-dev had /usr/lib/llvm-3.7/build/Makefile.*, but I don't see anything
similar in the newer packages.

The same problem exists in llvm-{3.9,4.0,5.0}-examples.


cheers,

Andreas


llvm-3.8-examples_1:3.8.1-18.log.gz
Description: application/gzip

Bug#857607: apache2.logrotate: don't invoke /etc/init.d/apache2 in postrotate script

[Stefan Fritsch]

On Monday, 13 March 2017 08:07:01 CET Sergio Gelato wrote:
> Now that apache2 includes a native systemd unit, it may be prudent to stop
> assuming that /etc/init.d/apache2 exists. (It's still distributed as part
> of the package, but since it's a configuration file system administrators
> are free to delete it.)

True.

> 
> The postrotate script in /etc/logrotate.d/apache2 invokes
> /etc/init.d/apache2 directly; according to section 9.3.3 of the Debian
> policy it should be using invoke-rc.d instead.

That section only talks about the package scripts (postinst, etc.). I don't 
think it is applicable for logrotate scripts.

The reason I didn't use invoke-rc.d is that it obeys runlevel constraints, 
which is not wanted in the logrotate script. But it seems invoke-rc.d has this 
limitation only for "start", not for "status" and "reload". So switching to 
invoke-rc.d should be fine.

Bug#857661: Acknowledgement (awesome: systray frequently messed up)

[Toni Mueller]

Hi,

the situation occurred again, and I was able to take a screenshot, the
relevant bits of which you can find attached.


Enjoy,
--Toni++

Bug#857658: biboumi: Wrong version of libbotan as build dependency

[Jonas Smedegaard]

Quoting Michel Le Bihan (2017-03-13 20:40:48)
> The build dependency set in the package is libbotan1.10-dev.
> 
> However, Biboumi needs libbotan >= 1.11
> 
> The result is that, when building, it is ignored and Biboumi gets built 
> without
> TLS support.
> 
> Please remove libbotan1.10-dev from build dependencies or (if possible) update
> libbotan to 1.11.

Right, the current build-dependency is of no use.

Thanks for reporting this!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly

[Carsten Schoenert]

Hello Daniel,

On Mon, Mar 13, 2017 at 04:26:43PM -0400, Daniel Kahn Gillmor wrote:
> Control: found 855334 1:45.8.0-1
> Control: tags 855334 + patch
> 
> Passing multiple arguments to Thunderbird is still a problem in 45.8.0-1
> except that the failures are silent now :/

I don't wanted to wait on this issue as the otherwise broken script was
a more conflicting thing and make the upload really grave.

> On Sun 2017-03-12 12:00:53 -0400, Guido Günther wrote:
> 
> > FWIW git-pbuilder has code to mangle options to pass them on to
> > pbuilder (which is a very similar problem) and uses a shell array. You
> > can rip out the code from there.
> 
> cool, thanks for the pointer!
> 
> I note that git-pbuilder is also a bash script, and it has a
> shell_quote() function which looks much more complex than just using the
> builtin printf's %q expansion, and git-pbuilder is also trying to mix
> explicitly-set external variables with internally-generated variables,
> which is more complex than what /usr/bin/thunderbird needs.
> 
> I think the simplest thing is to just replace the declaration,
> accumulation, and use entirely with array usage, and leave it at that.
> 
> I've included a patch here that appears to do the right thing for me.

Thanks for looking again into the a script.

I had modified the warpper script in the between time a little bit
different. I've done some more effort to catch some special arguments
and get them savely prepared to the binary call.
There are for sure more than one way to get the argument passing done.

https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?h=debian/sid=c2a1d77dd811ffd758f8306a71629e28490bc628

I have tested the script with these changes a lot and every argument is
now going correctly to the starting call of the TB binary, also given
arguments that are unknown for TB. But that's correct in my eyes as we
only want to filter out the argument for controling the wrapper.

I'm of course open for improvements. Given Christoph is solving #856185
he is planning to upload a version -2 probably within the next hours.

https://bugs.debian.org/856185

Regards
Carsten

Bug#857679: reopen #761909: system fails to shutdown if there is a mounted nfs share, due to it not being unmounted before network is brought down

[Giuseppe Bilotta]

Package: ifupdown
Version: 0.8.19
Severity: normal

I am still affected by issue #761909. Essentially, if there is a mounted nfs
share, shutdown will stall forever trying to unmount it unsuccessfully due to
the network going down before the attempted unmounting of the share. This only
happens with systemd.

The mount unit correctly depends on networking.service:

oblomov@oblomov:~$ systemctl list-dependencies oneforall.mount 
oneforall.mount
● ├─-.mount
● ├─system.slice
● └─network-online.target
●   └─networking.service
oblomov@oblomov:~$ 

but apparently this is not sufficient to get it unmounted before the network is
brought down. It's also hard to see why the network gets brought down early,
because the logs are always corrupt since the only way to complete the shutdown
or reboot is to forcefully kill the machine.


-- Package-specific info:
--- up and down scripts installed:
/etc/network/if-down.d:
total 16
-rwxr-xr-x 1 root root 1015 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  372 Jul  4  2016 openvpn
-rwxr-xr-x 1 root root  256 Jul 20  2013 resolvconf
-rwxr-xr-x 1 root root  332 Jan  6  2013 upstart
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
lrwxrwxrwx 1 root root   23 Jan 23 09:41 avahi-daemon -> ../if-up.d/avahi-daemon
lrwxrwxrwx 1 root root   29 Feb 11 00:16 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 1409 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 12
lrwxrwxrwx 1 root root   29 Feb 11 00:16 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root  344 Jan 28  2014 ethtool
-rwxr-xr-x 1 root root 4178 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 84
-rwxr-xr-x 1 root root  817 Jul 20  2013 000resolvconf
-rwxr-xr-x 1 root root 4359 May 29  2016 00check-network-cable
-rwxr-xr-x 1 root root 4341 Oct  1  2014 00check-network-cable.dpkg-old
-rwxr-xr-x 1 root root 5530 Feb  6  2016 10check-duplicate-ip
-rwxr-xr-x 1 root root 3848 Feb  6  2016 10check-duplicate-ip6
-rwxr-xr-x 1 root root 4280 Apr 10  2014 20static-routes
-rwxr-xr-x 1 root root 4566 Apr 10  2014 30check-gateway
-rwxr-xr-x 1 root root  923 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  484 Mar  6  2013 avahi-daemon
-rwxr-xr-x 1 root root 1685 Sep 22  2014 ethtool
-rwxr-xr-x 1 root root 4958 Jun  8  2014 mountnfs
-rwxr-xr-x 1 root root  900 Apr 28  2016 ntpdate
-rwxr-xr-x 1 root root  980 Jul 29  2016 openssh-server
-rwxr-xr-x 1 root root  385 Jul  4  2016 openvpn
-rwxr-xr-x 1 root root 1483 Jan  6  2013 upstart
lrwxrwxrwx 1 root root   32 Feb 20 11:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 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 ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.47
ii  iproute2 4.9.0-1
ii  libc62.24-9
ii  lsb-base 9.20161125

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5-3

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+4
pn  rdnssd  

-- no debconf information

Bug#857678: use /run prefix in systemd socket unit

[cgzones]

Package: dbus
Version: 1.10.16-1
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Hi,
dbus ships a systemd socket unit.
On SELinux enabled systems systemd automatically sets the correct file
context on creation according to the policy's configuration.
Since recently the reference policy defines the file contexts with
/run prefixes [1] and only supports /var/run via a backward
compatibility alias.

Please alter the path from /var/run/dbus/system_bus_socket to
/run/dbus/system_bus_socket in /usr/lib/systemd/system/dbus.socket to
avoid wrong file contexts in the future.

Best regards,
 Christian Göttsche



[1] 
https://github.com/TresysTechnology/refpolicy-contrib/blob/master/dbus.fc#L16

Bug#857677: use /run in systemd-tmpfiles config

[cgzones]

Package: openssh-server
Version: 1:7.4p1-6
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Hi,
OpenSSH-server ships a systemd-tmpfiles configuration for creating a
runtime directory.
On SELinux enabled systems, systemd-tmpfiles automatically sets the
correct file context on creation according to the policy's
configuration.
Since recently the reference policy defines the file contexts with
/run prefixes [1] and only supports /var/run via a backward
compatibility alias.
Please alter the path from /var/run/sshd to /run/sshd in
/usr/lib/tmpfiles.d/sshd.conf to avoid wrong file contexts in the
future.

Best regards,
Christian Göttsche


[1] 
https://github.com/TresysTechnology/refpolicy/blob/master/policy/modules/services/ssh.fc#L21

Bug#854496: python-qtpy: FTBFS randomly (failing tests)

[Ghislain Vaillant]

On Mon, 2017-03-13 at 21:41 +0100, Santiago Vila wrote:
> On Sat, Mar 11, 2017 at 10:47:36PM +, Ghislain Vaillant wrote:
> 
> > Could you point me to the specific commit or portion of the discussion
> > where the fix is described, please? I'd be happy to prepare a debdiff
> > for you to apply to check whether this fix you mention works with
> > src:python-qtpy.
> 
> This is the most relevant message from Bug #848063.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848063#64

src:python-qtpy does not use SDL, so I don't think this is the fix we
are looking for.

> In this case, just adding -a did not seem to fix the problem.

Could you try the debdiff I sent you nonetheless please?

Thanks,
Ghis

Bug#857425: lintian: unusual-interpreter ("#!/bin/false" in perl module)

[Hilmar Preuße]

forwarded 857425 https://savannah.gnu.org/bugs/index.php?50535
stop

On 10.03.2017 23:59, Hilmar Preuße wrote:

Hi,

> This bug is valid for 6.3.0.dfsg.1-1 and found in upstream package. I'll
> forward to upstream ASAP.
> 
Marking.

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

Bug#857676: python-cf-doc: broken symlink: /usr/share/doc/python-cf-doc/html/_static/requirejs.min.js -> ../../../../javascript/requirejs/requirejs.min.js

[Andreas Beckmann]

Package: python-cf-doc
Version: 1.3.2+dfsg1-4
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m25.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-cf-doc/html/_static/requirejs.min.js -> 
../../../../javascript/requirejs/requirejs.min.js

   

There is a /usr/share/javascript/requirejs/require.min.js, though.
 ^^

cheers,

Andreas


python-cf-doc_1.3.2+dfsg1-4.log.gz
Description: application/gzip

Bug#854496: python-qtpy: FTBFS randomly (failing tests)

[Santiago Vila]

On Sat, Mar 11, 2017 at 10:47:36PM +, Ghislain Vaillant wrote:

> Could you point me to the specific commit or portion of the discussion
> where the fix is described, please? I'd be happy to prepare a debdiff
> for you to apply to check whether this fix you mention works with
> src:python-qtpy.

This is the most relevant message from Bug #848063.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848063#64

In this case, just adding -a did not seem to fix the problem.

Thanks.

Bug#856869: clang-3.9: broken symlink: /usr/bin/scan-build-3.9-py -> ../share/clang/scan-build-3.9/bin/scan-build-py

[Sylvestre Ledru]

Le 13/03/2017 à 20:22, Andreas Beckmann a écrit :
> Followup-For: Bug #856869
>
> Hi Sylvestre,
>
> this issue also shows up in clang-4.0 and clang-5.0. Do you prefer
> separate bug reports for them or does the fix "automatically" flow to
> the newer versions?
>
> e.g.
>
> 0m46.8s ERROR: FAIL: Broken symlinks:
>   /usr/bin/scan-build-5.0-py -> 
> ../share/clang/scan-build-5.0/bin/scan-build-py
>
This is already fixed in the svn, thanks for asking :)

Bug#856805: gstreamer1.0-crystalhd: libgstbcmdec.so not found by gstreamer

[Sebastian Ramacher]

Control: severity -1 serious

On 2017-03-04 21:39:40, Luke Ross wrote:
> Package: gstreamer1.0-crystalhd
> Version: 1:0.0~git20110715.fdd2f19-11+b1
> Severity: important
> 
> Dear Maintainer,
> 
> I installed package gstreamer1.0-crystalhd on debian testing, but gst-
> inspect-1.0 revealed that the installed /usr/lib/gstreamer-1.0/libgstbcmdec.so
> was not being found by gstreamer (and so playback was not using CrystalHD).
> 
> When I symlinked this file into directory /usr/lib/x86_64-linux-
> gnu/gstreamer-1.0/ (where the other gstreamer plugins live) it started working
> and I was able to play back videos using the CrystalHD decoder (as I had
> already installed the kernel driver).

Raising the severity to serious since this makes the package in question
unusable.

Cheers

> With regards,
> 
> Luke
> 
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers jessie
>   APT policy: (500, 'jessie'), (500, 'all'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.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 gstreamer1.0-crystalhd depends on:
> ii  libc6   2.24-9
> ii  libcrystalhd3   1:0.0~git20110715.fdd2f19-11+b1
> ii  libglib2.0-02.50.3-1
> ii  libgstreamer-plugins-base1.0-0  1.10.3-1
> ii  libgstreamer1.0-0   1.10.3-1
> 
> gstreamer1.0-crystalhd recommends no packages.
> 
> gstreamer1.0-crystalhd suggests no packages.
> 
> -- no debconf information
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#857488: [Pkg-heka-maint] Bug#857488: lua-sandbox-extensions: circular_buffer module missing from package

[Mathieu Parent]

2017-03-11 21:54 GMT+01:00 Tollef Fog Heen :
> Package: lua-sandbox-extensions
> Version: 0~git20161128-1
> Severity: normal
>
> It seems like the circular_buffer module included in the upstream git
> repository is not included in the package.  This makes the
> throughput.lua analysis module pretty useless.

Yes, we know this. No enough time before stretch's freeze. We'll work
on it once stretch is released.

Also, given the build system, some work is needed to include this with
dh-lua. Help is appreciated.

Regards

-- 
Mathieu Parent

Bug#857675: libidn2-0 FTCBFS: runs host arch code during build (gentr46map, help2man)

[Helmut Grohne]

Source: libidn2-0
Version: 0.16-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cross building libidn2-0 is required for bootstrapping new architectures
as curl added it to its Build-Depends a while ago. Unfortunately, cross
building libidn2-0 currently fails. The immediate reason is failure to
execute gentr46map during build. It is not installed into any package
and should thus be compiled with the build architecture compiler, but
the build system opts for the host architecture compiler. After fixing
that, help2man fails running idn2. Fixing help2man calls doesn't have a
straight forward solution. One can choose among:
1. Stop using help2man and write proper documentation.
2. Skip rebuilding manual pages during cross builds.
3. Add a idn2:native  to Build-Depends and run that.
4. Build libidn2-0 twice. Once native, then cross.
In the attached patch, I opted for option 2. Please consider applying
it.

Helmut
diff --minimal -Nru libidn2-0-0.16/debian/changelog 
libidn2-0-0.16/debian/changelog
--- libidn2-0-0.16/debian/changelog 2017-01-16 09:20:46.0 +0100
+++ libidn2-0-0.16/debian/changelog 2017-03-13 20:27:32.0 +0100
@@ -1,3 +1,13 @@
+libidn2-0 (0.16-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: cross.patch (Closes: #-1)
++ Use CC_FOR_BUILD (and thus AX_CC_FOR_BUILD from autoconf-archive) to
+  build gentr46map, which thus requires libunistring-dev:native.
++ Skip the help2man step and use the pre-build manual page during cross.
+
+ -- Helmut Grohne   Mon, 13 Mar 2017 20:27:32 +0100
+
 libidn2-0 (0.16-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru libidn2-0-0.16/debian/control libidn2-0-0.16/debian/control
--- libidn2-0-0.16/debian/control   2016-12-30 08:01:16.0 +0100
+++ libidn2-0-0.16/debian/control   2017-03-13 20:27:32.0 +0100
@@ -2,7 +2,7 @@
 Section: libs
 Maintainer: Debian Libidn team 
 Uploaders: Simon Josefsson 
-Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, texinfo, texlive, 
help2man, gengetopt, libunistring-dev
+Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, texinfo, texlive, 
help2man, gengetopt, libunistring-dev, libunistring-dev:native, autoconf-archive
 Standards-Version: 3.9.8
 Priority: extra
 Homepage: https://www.gnu.org/software/libidn/#libidn2
diff --minimal -Nru libidn2-0-0.16/debian/patches/cross.patch 
libidn2-0-0.16/debian/patches/cross.patch
--- libidn2-0-0.16/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ libidn2-0-0.16/debian/patches/cross.patch   2017-03-13 20:27:32.0 
+0100
@@ -0,0 +1,72 @@
+From: Helmut Grohne 
+Subject: fix cross compilation
+
+ * Use the build architecture compiler fo building gentr46map as it is not
+   installed and executed during build.
+ * Use the prebuilt manual page idn2.1 during cross building, because running
+   help2man doesn't work.
+
+Index: libidn2-0-0.16/Makefile.am
+===
+--- libidn2-0-0.16.orig/Makefile.am
 libidn2-0-0.16/Makefile.am
+@@ -63,11 +63,11 @@
+   cat $(IDNA_TABLE) | $(srcdir)/gen-tables-from-iana.pl > $@.new
+   mv $@.new $@
+ 
+-noinst_PROGRAMS = gentr46map
+-gentr46map_LDADD = $(LTLIBUNISTRING)
++gentr46map$(BUILD_EXEEXT): gentr46map.c
++  $(CC_FOR_BUILD) $(AM_CPPFLAGS) $(CFLAGS_FOR_BUILD) -lunistring $< -o $@
+ 
+-tr46map_data.c: gentr46map.c gentr46map$(EXEEXT) $(TR46MAP) $(NFCQC)
+-  $(builddir)/gentr46map$(EXEEXT) > $@.new
++tr46map_data.c: gentr46map.c gentr46map$(BUILD_EXEEXT) $(TR46MAP) $(NFCQC)
++  $(builddir)/gentr46map$(BUILD_EXEEXT) > $@.new
+   mv $@.new $@
+ 
+ $(IDNA_TABLE):
+Index: libidn2-0-0.16/configure.ac
+===
+--- libidn2-0-0.16.orig/configure.ac
 libidn2-0-0.16/configure.ac
+@@ -31,6 +31,8 @@
+ AC_CANONICAL_HOST
+ 
+ AC_PROG_CC
++AM_CONDITIONAL(cross_compiling,[test "$cross_compiling" = yes])
++AX_PROG_CC_FOR_BUILD
+ gl_EARLY
+ m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
+ LT_INIT([win32-dll])
+Index: libidn2-0-0.16/gentr46map.c
+===
+--- libidn2-0-0.16.orig/gentr46map.c
 libidn2-0-0.16/gentr46map.c
+@@ -26,8 +26,6 @@
+not, see .
+ */
+ 
+-#include 
+-
+ #include 
+ #include 
+ #include 
+Index: libidn2-0-0.16/doc/Makefile.am
+===
+--- libidn2-0-0.16.orig/doc/Makefile.am
 libidn2-0-0.16/doc/Makefile.am
+@@ -34,11 +34,13 @@
+ dist_man_MANS = idn2.1 $(gdoc_MANS)
+ CLEANFILES = $(dist_man_MANS) lookup.c register.c stamp-vti version.texi 
$(srcdir)/libidn2.info
+ 
++if !cross_compiling
+ idn2.1: $(top_srcdir)/src/idn2.c $(top_srcdir)/src/idn2.ggo 
$(top_srcdir)/configure.ac
+   $(HELP2MAN) \
+   

Bug#857674: unblock: pd-cyclone/0.2~beta3-2

[IOhannes m zmoelnig]

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

Please unblock package pd-cyclone

this fixes a recently discovered piuparts issue (dangling symlinks).
since this is a leave package, impact should be minimal.

unblock pd-cyclone/0.2~beta3-2

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pd-cyclone-0.2~beta3/debian/changelog 
pd-cyclone-0.2~beta3/debian/changelog
--- pd-cyclone-0.2~beta3/debian/changelog   2016-11-11 12:41:02.0 
+0100
+++ pd-cyclone-0.2~beta3/debian/changelog   2017-03-13 15:19:53.0 
+0100
@@ -1,3 +1,9 @@
+pd-cyclone (0.2~beta3-2) unstable; urgency=medium
+
+  * Fixed symlinks to README.md (Closes: #857156)
+
+ -- IOhannes m zmölnig (Debian/GNU)   Mon, 13 Mar 2017 
15:19:53 +0100
+
 pd-cyclone (0.2~beta3-1) unstable; urgency=medium
 
   * New upstream version 0.2~beta3
diff -Nru pd-cyclone-0.2~beta3/debian/links pd-cyclone-0.2~beta3/debian/links
--- pd-cyclone-0.2~beta3/debian/links   2016-11-11 12:41:02.0 +0100
+++ pd-cyclone-0.2~beta3/debian/links   2017-03-13 15:19:53.0 +0100
@@ -1 +1 @@
-usr/lib/pd/extra/cyclone/README.txtusr/share/doc/pd-cyclone/README
+usr/lib/pd/extra/cyclone/README.mdusr/share/doc/pd-cyclone/README

Bug#855334: /usr/bin/thunderbird: $THUNDERBIRD_OPTIONS does not pass multiple args correctly

[Daniel Kahn Gillmor]

Control: found 855334 1:45.8.0-1
Control: tags 855334 + patch

Passing multiple arguments to Thunderbird is still a problem in 45.8.0-1
except that the failures are silent now :/

On Sun 2017-03-12 12:00:53 -0400, Guido Günther wrote:

> FWIW git-pbuilder has code to mangle options to pass them on to
> pbuilder (which is a very similar problem) and uses a shell array. You
> can rip out the code from there.

cool, thanks for the pointer!

I note that git-pbuilder is also a bash script, and it has a
shell_quote() function which looks much more complex than just using the
builtin printf's %q expansion, and git-pbuilder is also trying to mix
explicitly-set external variables with internally-generated variables,
which is more complex than what /usr/bin/thunderbird needs.

I think the simplest thing is to just replace the declaration,
accumulation, and use entirely with array usage, and leave it at that.

I've included a patch here that appears to do the right thing for me.

Regards,

--dkg

diff --git a/thunderbird b/thunderbird
index 28983ca..8d57976 100755
--- a/thunderbird
+++ b/thunderbird
@@ -45,7 +45,7 @@ export VERBOSE=0
 # set MOZ_APP_LAUNCHER for gnome-session
 export MOZ_APP_LAUNCHER
 
-TB_ARGS=""
+declare -a TB_ARGS=()
 while [ $# -gt 0 ]; do
 ARG="$1"
 case ${ARG} in
@@ -76,7 +76,7 @@ while [ $# -gt 0 ]; do
 exit 1
 ;;
 # every other argument is needed to get down to the TB starting call
-*) TB_ARGS="${TB_ARGS} ${ARG}"
+*) TB_ARGS+=("${ARG}")
 ;;
 esac
 shift
@@ -228,8 +228,8 @@ fi
 # If we are here we going simply further by starting Thunderbird.
 
 if [ "${DEBUG}" = "" ]; then
-output_debug "call '$MOZ_LIBDIR/$MOZ_APP_NAME ${TB_ARGS}'"
-$MOZ_LIBDIR/$MOZ_APP_NAME "${TB_ARGS}"
+output_debug "call '$MOZ_LIBDIR/$MOZ_APP_NAME ${TB_ARGS[*]}'"
+$MOZ_LIBDIR/$MOZ_APP_NAME "${TB_ARGS[@]}"
 else
 # User has selected GDB?
 if [ "$DEBUGGER" = "1" ]; then
@@ -237,7 +237,7 @@ else
 if [ -f /usr/bin/gdb ]; then
 if [ -f /usr/lib/debug/usr/lib/thunderbird/thunderbird ]; then
 output_info "Starting Thunderbird with GDB ..."
-LANG='' /usr/lib/thunderbird/run-mozilla.sh -g /usr/lib/thunderbird/thunderbird-bin "${TB_ARGS}"
+LANG='' /usr/lib/thunderbird/run-mozilla.sh -g /usr/lib/thunderbird/thunderbird-bin "${TB_ARGS[@]}"
 else
 output_info "No package 'thunderbird-dbg' installed! Please install first and restart."
 exit 1


signature.asc
Description: PGP signature

Bug#857673: sawfish: unused B-D on libaudiofile-dev

[sramacher]

Source: sawfish
Version: 1:1.11.90-1
Severity: wishlist
Usertags: unused-bd

sawfish currently declares a build dependency on libaudiofile-dev.
But none of the resulting binary packages has a dependency on
libaudiofile1. In case sawfish really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857671: dopewars: unused B-D on libaudiofile-dev

[sramacher]

Source: dopewars
Version: 1.5.12-17
Severity: wishlist
Usertags: unused-bd

dopewars currently declares a build dependency on libaudiofile-dev.
But none of the resulting binary packages has a dependency on
libaudiofile1. In case dopewars really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857672: timidity: unused B-D on libaudiofile-dev

[sramacher]

Source: timidity
Version: 2.13.2-40.5
Severity: wishlist
Usertags: unused-bd

timidity currently declares a build dependency on libaudiofile-dev.
But none of the resulting binary packages has a dependency on
libaudiofile1. In case timidity really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857670: libsdl1.2: unused B-D on libaudiofile-dev

[sramacher]

Source: libsdl1.2
Version: 1.2.15+dfsg1-4
Severity: wishlist
Usertags: unused-bd

libsdl1.2 currently declares a build dependency on libaudiofile-dev.
But none of the resulting binary packages has a dependency on
libaudiofile1. In case libsdl1.2 really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857669: festival: unused B-D on libaudiofile-dev

[sramacher]

Source: festival
Version: 1:2.4~release-3
Severity: wishlist
Usertags: unused-bd

festival currently declares a build dependency on libaudiofile-dev.
But none of the resulting binary packages has a dependency on
libaudiofile1. In case festival really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857668: lush: unused B-D on libaudiofile-dev

[sramacher]

Source: lush
Version: 1.2.1-9+cvs20110227+nmu1.1
Severity: wishlist
Usertags: unused-bd

lush currently declares a build dependency on libaudiofile-dev. But
none of the resulting binary packages has a dependency on
libaudiofile1. In case lush really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857665: gnumed-client: Please update recommends on cups-pdf

[Jeremy Bicha]

Package: gnumed-client
Version: 1.6.11+dfsg-1
Severity: important

gnumed-client recommends cups-pdf. But cups-pdf is a transitional
package in stretch pointing to
printer-driver-cups-pdf.

In Debian experimental and Ubuntu 17.04 Beta, the cups-pdf
transitional package has been dropped.

Thanks,
Jeremy Bicha

Bug#857666: gnuboy: unused B-D on libaudiofile-dev

[sramacher]

Source: gnuboy
Version: 1.0.3-7
Severity: wishlist
Usertags: unused-bd

gnuboy currently declares a build dependency on libaudiofile-dev. But
none of the resulting binary packages has a dependency on
libaudiofile1. In case gnuboy really no longer needs libaudiofile,
please remove the corresponding -dev package from Build-Depends.

Cheers 

Bug#857664: unblock: pd-ggee/0.26-5

[IOhannes m zmoelnig]

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

Please unblock package pd-ggee

the uploaded package fixes two bugs that make parts of the package practically
unusable.

- #792720 makes two modules unusable on amd64
- #793827 makes one module unusable on Pd>=0.43 (and even oldstable includes
  0.43)

the upload fixes an additional recently found piuparts problem (dangling
symlink).

thanks for considering

unblock pd-ggee/0.26-5

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pd-ggee-0.26/debian/changelog pd-ggee-0.26/debian/changelog
--- pd-ggee-0.26/debian/changelog   2015-06-03 19:57:20.0 +0200
+++ pd-ggee-0.26/debian/changelog   2017-03-13 15:14:16.0 +0100
@@ -1,3 +1,14 @@
+pd-ggee (0.26-5) unstable; urgency=medium
+
+  * Update Vcs-Browser stanza
+  * Added debian/git-tuneclone.sh script
+  * Canonical homepage for Pd-projects
+  * Drop symlink to non-existant examples (Closes: #857161)
+  * Updated "button" to Pd-GUI rewrite (Closes: #793827)
+  * Fixed access to tables on 64bit systems (Closes: #792720)
+
+ -- IOhannes m zmölnig (Debian/GNU)   Mon, 13 Mar 2017 
15:14:16 +0100
+
 pd-ggee (0.26-4) unstable; urgency=medium
 
   [ Hans-Christoph Steiner ]
diff -Nru pd-ggee-0.26/debian/control pd-ggee-0.26/debian/control
--- pd-ggee-0.26/debian/control 2015-06-03 17:10:46.0 +0200
+++ pd-ggee-0.26/debian/control 2017-03-13 15:14:16.0 +0100
@@ -8,9 +8,9 @@
puredata-dev,
quilt (>= 0.46-7~)
 Standards-Version: 3.9.6
-Homepage: http://puredata.info
+Homepage: http://download.puredata.info/ggee
 Vcs-Git: git://anonscm.debian.org/pkg-multimedia/pd-ggee.git
-Vcs-Browser: http://git.debian.org/?p=pkg-multimedia/pd-ggee.git;a=summary
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-multimedia/pd-ggee.git
 
 Package: pd-ggee
 Architecture: any
diff -Nru pd-ggee-0.26/debian/git-tuneclone.sh 
pd-ggee-0.26/debian/git-tuneclone.sh
--- pd-ggee-0.26/debian/git-tuneclone.sh1970-01-01 01:00:00.0 
+0100
+++ pd-ggee-0.26/debian/git-tuneclone.sh2017-03-13 15:14:16.0 
+0100
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+## script to initialize a cloned repository
+## with per (local) repository settings.
+
+# - ignore quilt's .pc/ directory
+# - enable the "--follow-tags" mode for pushing
+
+error() {
+ echo "$@" 1>&2
+}
+
+NAME=$(dpkg-parsechangelog -S Source)
+
+if [ "x${NAME}" = "x" ]; then
+ error "unable to determine package name"
+ error "make sure you run this script within a source package dir"
+ exit 1
+fi
+
+if [ ! -d ".git" ]; then
+ error "it seems like this source package is not under git control"
+ exit 1
+fi
+
+echo "tuning git-repository for ${NAME}"
+git config push.followTags true && echo "enabled push.followTags"
+
+GITEXCLUDE=".git/info/exclude"
+egrep "^/?\.pc/?$" "${GITEXCLUDE}" >/dev/null 2>&1 \
+  || (echo "/.pc/" >> "${GITEXCLUDE}" && echo "ignoring /.pc/")
+
+for branch in pristine-tar upstream master; do
+ git checkout "${branch}"
+done
diff -Nru pd-ggee-0.26/debian/links pd-ggee-0.26/debian/links
--- pd-ggee-0.26/debian/links   2015-06-03 17:07:35.0 +0200
+++ pd-ggee-0.26/debian/links   2017-03-13 15:14:16.0 +0100
@@ -1,2 +1 @@
 usr/lib/pd/extra/ggee/README.txtusr/share/doc/pd-ggee/README
-usr/lib/pd/extra/ggee/examples  usr/share/doc/pd-ggee/examples
diff -Nru pd-ggee-0.26/debian/patches/fix-64bit-arrays.patch 
pd-ggee-0.26/debian/patches/fix-64bit-arrays.patch
--- pd-ggee-0.26/debian/patches/fix-64bit-arrays.patch  1970-01-01 
01:00:00.0 +0100
+++ pd-ggee-0.26/debian/patches/fix-64bit-arrays.patch  2017-03-13 
15:14:16.0 +0100
@@ -0,0 +1,221 @@
+Description: fixing 64bit issues with table access
+ array_getfloatarray() is not 64bit-save, instead one must use
+ array_getfloatwords()
+Author: upstream
+Reviewed-by: IOhannes m zmölnig
+Last-Update: 2017-03-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- pd-ggee.orig/experimental/tabwrite4~.c
 pd-ggee/experimental/tabwrite4~.c
+@@ -12,9 +12,9 @@
+ t_object x_obj;
+ int x_phase;
+ int x_npoints;
+-float *x_vec;
++t_word *x_vec;
+ t_symbol *x_arrayname;
+-float x_f;
++t_float x_f;
+ t_sample x_1;
+ t_sample x_2;
+ t_sample x_3;
+@@ -22,8 +22,6 @@
+ float x_index;
+ } t_tabwrite4_tilde;
+ 
+-static void tabwrite4_tilde_tick(t_tabwrite4_tilde *x);
+-
+ static void *tabwrite4_tilde_new(t_symbol *s)
+ {
+ t_tabwrite4_tilde *x = (t_tabwrite4_tilde *)pd_new(tabwrite4_tilde_class);
+@@ -34,7 +32,7 @@
+ x->x_2 = 0.;
+   

Bug#857667: speech-tools: unused B-D on libaudiofile-dev

[sramacher]

Source: speech-tools
Version: 1:2.4~release-5
Severity: wishlist
Usertags: unused-bd

speech-tools currently declares a build dependency on
libaudiofile-dev. But none of the resulting binary packages has a
dependency on libaudiofile1. In case speech-tools really no longer
needs libaudiofile, please remove the corresponding -dev package from
Build-Depends.

Cheers 

Bug#857663: rdesktop: Mouse pointer glitch using rdesktop

[Gabriel Furtado Pires]

Package: rdesktop
Version: 1.8.2-3+deb8u1
Severity: normal

This glich I've only experienced using a moba "ECS P4M800-M v1.0"

When I try to use rdesktop in a computer with this specific motherboard, the 
mouse pointer change to a "glitch box", no matter if it's a windows or linux 
server.
This glitch doesn't happen in wheezy or stretch, and update to an newer version 
of rdesktop in jessie doesn't fix this. 

Apparently it's a problem with this specific motherboard (and jessie's 
package), since this doesn't occurs with another moba.


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

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

Versions of packages rdesktop depends on:
ii  libasound21.0.28-1
ii  libc6 2.19-18+deb8u7
ii  libgssglue1   0.4-2
ii  libpcsclite1  1.8.13-1+deb8u1
ii  libssl1.0.0   1.0.1t-1+deb8u6
ii  libx11-6  2:1.6.2-3
ii  libxrandr22:1.4.2-1+b1

Bug#843523: mosh: screen corruption with long lines

[john hood]

Apologies for dropping this on the floor.  I just had a quick look at
this, but the rendering looks OK from here with the Konsole I have
available at the moment.  Are you still seeing this problem?  If so, do
you see it with XTerm as well?

(I don't see any non-ASCII characters, so our common issues with Unicode
don't seem to apply here.  My best guesses are that either the termios
window size somewhere in the chain is out of sync with reality, or that
there's an issue with line wrap/automargins in one of the 3 terminal
emulators involved.  But neither of these feel like good guesses.)

regards,

  --jh

On 11/8/16 5:17 AM, Philipp Marek wrote:
>> We need you to run three separate invocations of "script", each one writing
>> to a different logfile.
>>
>> The first invocation will be before you even run mosh. Run something like
>> "script mosh_output" on your local machine.
>>
>> Then, *inside the resulting shell*, run "mosh server".
>>
>> Then, *inside that remote shell*, run "script tmux_output_and_mosh_input".
>>
>> Then, *inside the resulting shell*, run tmux.
>>
>> Then, *inside that*, run "script tmux_input".
>>
>> Then, *inside the resulting shell*, do whatever you can do to demonstrate
>> the problem.
>>
>> Then exit all the shells cleanly.
>>
>> The result will be two logfiles on the remote machine ("tmux_input" and
>> "tmux_output_and_mosh_input") and one logfile on the local machine
>> ("mosh_output").
>>
>> We'll need to examine all three logfiles to figure out where the problem is
>> happening.
> Okay, understood. You want _nested_ files.
>
> But "tmux" is local, so the counts are the other way around ;)
>
>
> Happens with 1.2.5 from jessie-backports, too; logfiles are attached.
> Just before the end I pressed Ctrl-L to restore the screen output; I hope 
> that doesn't interfere with your investigations.
>
> $ tput cols ; tput lines
> 80
> 24
>

Bug#857579: unblock: mbedtls/2.4.2-1 (pre-approval)

[Niels Thykier]

Control: tags -1 confirmed moreinfo

James Cowgill:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi,
> 
> I am wondering whether it's possible to include mbedtls 2.4.2 in
> stretch. While it does fix an RC security bug (#857560), it also
> contains a lot of other stuff - all of it bugfixes though.
> 
> The diff is attached, but it's pretty bug. There have been a number of
> changes which should have no effect at runtime (lots of documentation /
> comments updates, testsuite updates). Half of the diff is changes to the
> visual studio project files which is obviously irrelevant for Debian.
> 
> If this isn't approved, would cherry picking the 4 security bug fixes
> and their testcases be OK for stretch?
> 
> [...]
> 
> Thanks,
> James
> 
> [...]

Hi,

I have reviewed it and I agree that upstream release looks preferable
with one remark:

 * The test suite appears to be "time-bombed" via
   "tests/data_files/test-ca2_cat-future-invalid.crt".
 * Ideally, the buildability should not expire.
 * Furthermore, its "expire" date is "Sep 22 15:49:49 2023" which is
   uncomfortably close stretch's expected EOL on the LTS release
   (Said EOL is currently estimated to some time in 2022 and counting).

Please resolve that, upload and remove the moreinfo tag once the upload
has been processed and built on all relevant release architectures.

Thanks,
~Niels

Bug#857580: [Android-tools-devel] Bug#857580: adb dev*** Error in `adb': free(): invalid pointer: 0x000055867c446b90 ***

[Hans-Christoph Steiner]

積丹尼 Dan Jacobson:
>> "HS" == Hans-Christoph Steiner  writes:
> 
> HS> Thanks for the bug report!  Does this happen everytime, or just once?
> 
> Just once. I can't reproduce it.
> 
> By the way, apparently even just doing a tab expansion starts the server
> and leaves it running, without the user even hitting RET.
> 
> I installed it via aptitude I recall.

In order to do the lovely dynamic tricks like getting the device serial
from `adb devices`, the adb server needs to be running.  adb
automatically starts the server whenever a relevant command is started.

Bug#857662: cron broken in SELinux enforced mode due to system_u login mapping removal

[cgzones]

Package: cron
Version: 3.0pl1-128+b1
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Hi,
with the removal of the SELinux login entry for system_u [1], cron
stops working.

get_security_context [2] expects a NULL name when called for a system cronjob.
But it is called with "system_u" [2].

It worked so far cause getseuserbyname [3] translated the incorrect
name value "system_u" still to the "system_u" seuser.

Best regards,
  Christian Göttsche

[1] 
https://github.com/TresysTechnology/refpolicy/commit/79f31a04739dad7c7369616cd7c666a57c365511
[2] https://sources.debian.net/src/cron/3.0pl1-128/user.c/?hl=120#L218
[3] https://sources.debian.net/src/cron/3.0pl1-128/user.c/?hl=120#L51

--- user.c  2017-03-13 21:06:52.638905763 +0100
+++ user.c.fixed2017-03-13 21:07:48.654110814 +0100
@@ -215,7 +215,7 @@
if (is_selinux_enabled() > 0) {
char *sname=uname;
if (pw==NULL) {
-sname="system_u";
+sname=NULL;
}
if (get_security_context(sname, crontab_fd,
 >scontext, tabname) != 0 ) {

Bug#856815: kodi FTBFS on Alpha due to Intel assembler that is easily worked around

[Bálint Réczey]

Control: tags -1 confirmed moreinfo

Hi Michael,

2017-03-05 2:29 GMT+01:00 Michael Cree :
> Source: kodi
> Version: 2:17.0+dfsg1-3
> Severity: wishlist
> Tags: patch
> User: debian-al...@lists.debian.org
> Usertags: alpha
>
> kodi FTBFS on alpha due to Intel specific code [1].
>
> I attach a patch that enables generic code to be built rather
> than Intel specific code and with that kodi builds to completion
> on Alpha.

Thanks!

I am generally happy to receive patches from porters and would be open
to accepting it, but before I do so I have two questions:

Can kodi run on any alpha machine?

The kodi package is quite big. Would building the package worth it
considering the space needed on snapshot.d.o, on mirrors, etc?

Cheers,
Balint

>
> Cheers
> Michael.
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=kodi=alpha=2%3A17.0%2Bdfsg1-3=1487892844=0

Bug#659620: RFP: wview -- Weather station daemon

[Kevin Locke]

I've been using wview for a while and would like to see it in the
Debian archive as well.

I'm not a Debian Developer or Maintainer, but I've done some work on
the packaging for my own use which included updating to debhelper 10
with dh, updating to the current standards version, running the
daemons as non-root, using dh_apache2 to install the wview web
directories, and lots of fixes for lintian warnings.  I think the
package would need a lot more work before it would be acceptable to
the FTP Team, but if anyone is interested in working on it, they may
find my changes useful for reference or as a starting point.

The package is available at https://gitlab.com/kevinoid/wview with the
standard git-buildpackage repository layout.  It includes a packaging
TODO list in debian/TODO.md with items that were mostly for myself,
but which potential packagers may want to consider.

-- 
Cheers,  |  ke...@kevinlocke.name| XMPP: ke...@kevinlocke.name
Kevin|  https://kevinlocke.name  | IRC:   kevinoid on freenode

Bug#844939: git-remote-hg: FTBFS: Test failures

[Mark Nauwelaerts]

Hi,

On Wed, 11 Jan 2017 00:35:19 + Jonathan McCrohan  
wrote:


Unfortunately upstream [1] [2] is not responsive at the moment. I have
noticed another fork [3] which is in significantly better shape when
using Mercurial 4.0 (only two tests failing), but this has diverged
significantly from the original upstream. As a result, it is not
possible to cherry-pick a patch or two which would resolve this issue.

Assistance from someone with knowledge of both Git and Mercurial
internals would be gratefully accepted.

Regards,
Jon

[1] https://github.com/felipec/git-remote-hg/
[2] https://github.com/fingolfin/git-remote-hg/
[3] https://github.com/mnauw/git-remote-hg/



I am the maintainer/writer of the fork [3] mentioned above, which has indeed 
evolved quite somewhat from the original upstream to address quite some issues.


More relevant here; I have re-run the tests (of [3]) against (local checkout of) 
Mercurial 4.0 and Mercurial 4.1 and all tests pass in my setup (not counting 
harmless known breakages) (?).   So is there any more info on the failing ones 
that would allow resolving things to a clean test sheet?


Also, the compatibility adjustment to Mercurial 4.0 is fairly minor (afaics only 
1 commit involving a few lines), so if really desired/preferred that could 
probably be back-ported to the original upstream.  Though again, as said, there 
are quite some limitations and issues in the original that have been handled in 
the fork (somewhat regrettably so that way given the circumstances).


Regards,
Mark

Bug#857661: awesome: systray frequently messed up

[Toni Mueller]

Package: awesome
Version: 4.0-1
Severity: normal


Hi,

since a few weeks, my systray gets messed up. In particular, if I open
one of the programs listed there, the icons frequently get re-arranged,
but, much more annoying, awesome frequently starts to display the same
icon for several programs. Eg. at the moment, I can see two keyboard
icons (from fcitx), and two loudspeakers (from volti), where there
should have been a wicd and a clipit icon. If I manage to click the
'correct' icon, then the appropriate program will start - eg. clipit in
the case of one of the loudspeaker icons - but this is really, really
annoying. Sometimes, it flips back to normal, displaying every icon as
it should be. When I tried to take a screenshot, all icons flipped back
to normal, but it would be nice if awesome could always display the
correct icons by itself.


Cheers,
--Toni++



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

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

Versions of packages awesome depends on:
ii  dbus-x11  1.10.16-1
ii  gir1.2-freedesktop1.50.0-1+b1
ii  gir1.2-pango-1.0  1.40.3-3
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-1
ii  liblua5.1-0   5.1.5-8.1+b2
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.4-3
ii  libxcb-cursor00.1.1-3
ii  libxcb-icccm4 0.4.1-1
ii  libxcb-keysyms1   0.4.0-1
ii  libxcb-randr0 1.12-1
ii  libxcb-render01.12-1
ii  libxcb-shape0 1.12-1
ii  libxcb-util0  0.3.8-3
ii  libxcb-xinerama0  1.12-1
ii  libxcb-xkb1   1.12-1
ii  libxcb-xrm0   1.0-2
ii  libxcb-xtest0 1.12-1
ii  libxcb1   1.12-1
ii  libxdg-basedir1   1.2.0-1
ii  libxkbcommon-x11-00.7.1-1
ii  libxkbcommon0 0.7.1-1
ii  lua-lgi   0.9.1-1
ii  menu  2.1.47

Versions of packages awesome recommends:
ii  feh2.18-1
ii  rlwrap 0.42-3
ii  x11-xserver-utils  7.7+7

awesome suggests no packages.

-- no debconf information

Bug#793285: closed by Martin Quinson <martin.quin...@ens-rennes.fr> (Widelands builds without any problem with gcc5)

[Martin Quinson]

On Mon, Mar 13, 2017 at 07:50:42PM +0100, Matthias Klose wrote:
> > as the title says, this bug does not affect widelands, thus closing.
> 
> yes, it wouldn't have taken 16 months to confirm that. And no, none of these
> patches results in a build error.  So your reasoning is plain wrong. But who
> cares ...

I'm not sure I understand what you are talking about. I don't see no
reasonning on my side nor patch in this whole bug report, but I may be
blind. Could you please enlight me?

As for the long delay, yes. I'm doing my best, but it's not always
enough, sorry. When you first reported that bug, I did not feel
skilled enough to install an unstable build chain and test things in a
certain manner. Plus, I was thinking that a swamp recompilation of the
whole archive with gcc5 (once I've sorted out how to make an
experimental image) may have been more efficient than a swamp of bug
reporting "warning, *possible* issue ahead". But that's not easy
either. I did not know how to react about your bug report, and then I
forgot about it, sorry. 

I must however confess that I feel surprised to be bashed for finally
taking care of the problem at my tiny scale... But no offense taken: 
being the maintainer of such an amount of important packages is a huge
burden, and I'm still grateful for your work.

Bye, Mt.


signature.asc
Description: PGP signature

Bug#823714: gtk3-engines-breeze: add gtk3 (=3.18) to depends

[Jeremy Bicha]

On Mon, Mar 13, 2017 at 2:36 PM, Maximiliano Curia  wrote:
> Anyway, nothing to be done about the original report, the current breeze-gtk
> supports gtk 3.20 (only).

Yes, I agree with the bug being closed. GTK3 has stablized with the
gtk 3.22.* series (there will not be any 3.24 or newer gtk3 releases)
and development has begun on gtk4.

Therefore, the theme should not break any more for gtk3.

Thanks,
Jeremy Bicha

Bug#857660: SELinux: cannot sent policyload notice

[cgzones]

Package: dbus
Version: 1.10.16-1
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Hi,
on SELinux enabled systems, dbus cannot send the policyload notification.

There is already a thread over at redhat [1], and bug reports at
redhat [2] and dbus [3].
Please, cherry-pick the fix from upstream [4].

Best regards,
Christian Göttsche

[1] https://www.redhat.com/archives/linux-audit/2015-November/msg2.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1278602
[3] https://bugs.freedesktop.org/show_bug.cgi?id=92832
[4] 
https://cgit.freedesktop.org/dbus/dbus/commit/?id=a3a5935a0a038c3b44c61ce5719f0f7e647b96c6

Bug#738063: nfs-kernel-server: option to disable NFSv4 in /etc/default/nfs-kernel-server not working properly

[Nye Liu]

On Thu, 2 Feb 2017 21:55:28 -0800 Nye Liu  wrote:
> This bug is still not fixed.
>
> In addition, it doesn't appear as though "-V 2" will enable NFSv2, 
which seems to

> be disabled by default now.

Even worse, the old nfs-common script would automatically enable statd, 
idmapd, and gssd if needed.


Not sure about idmapd and gssd, but nothing automatically enables statd 
any longer - it has to be enabled manually via "systemctl enable rpc-statd."


This is very unexpected behavior for anyone wishing to run nfs v2 and/or v3

Bug#857638: unblock: manpages-de/1.22-1

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Dr. Tobias Quathamer:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package manpages-de. The package provides translations of
> various manpages within Debian, there are no binaries or libs included.
> Since the freeze, there have been many typo fixes and translation
> updates of previously untranslated strings.
> 
> unblock manpages-de/1.22-1
> 
> The package builds fine in a sid chroot. If you approve of this unblock,
> I'll upload to unstable.
> 
> Regards,
> Tobias

Please go ahead and remove the moreinfo tag once the upload has been
processed and built.

Thanks,
~Niels

Bug#857633: unblock: kscreen/4:5.8.5-2

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Maximiliano Curia:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release team,
> 
> KDE Plasma 5.8 is an LTS release that I consider fit to be updated in 
> stretch. 
> This particular request is for kscreen 5.8.5.
> 
> The fixes included in the kscreen 5.8.5 release are: 
>  translation updates
>  3 bug fixes:
>+ Handle nullptr when there is no Primary Output (d79dc2b)
>+ Improve screen resize when running in a vm (96db1a9 d5b9d37)
>+ Avoid setting the modes in disabled outputs (b4b5046)
> 
> On the Debian side of changes we add the requested upower recommends (#853171)
> 
> I'm attaching the full debdiff, the gitlogs of the upstream changes and the 
> diff of the debian changes.
> 
> Currently the version 5:5.8.5-1 is in experimental, and I'll upload the
> 4:5.8.5-2 version to unstable if this gets approved.
> 
> Please unblock package kscreen
> 
> Happy hacking,
> 
> unblock kscreen/4:5.8.5-2
> [...]

Please go ahead and remove the moreinfo tag once the upload has been
processed and built on all relevant release architectures.

Thanks,
~Niels

Bug#857658: biboumi: Wrong version of libbotan as build dependency

[Michel Le Bihan]

Package: biboumi
Severity: normal

The build dependency set in the package is libbotan1.10-dev.

However, Biboumi needs libbotan >= 1.11

The result is that, when building, it is ignored and Biboumi gets built without
TLS support.

Please remove libbotan1.10-dev from build dependencies or (if possible) update
libbotan to 1.11.



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

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

Bug#857659: gridengine-client: broken symlink: /var/lib/gridengine/jobsbin -> /usr/lib/gridengine/jobsbin

[Andreas Beckmann]

Package: gridengine-client
Version: 8.1.9+dfsg-4
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

2m40.9s ERROR: FAIL: Broken symlinks:
  /var/lib/gridengine/jobsbin -> /usr/lib/gridengine/jobsbin

A file called jobsbin is not found anywhere in Debian unstable.
Either you forgot to ship it, or you forgot to remove the obsolete link.


cheers,

Andreas


science-distributedcomputing_1.6.log.gz
Description: application/gzip

Bug#857309: kodi: 'kodi' user does not exist

[Bálint Réczey]

Control: severity -1 wishlist
Control: tags -1 confirmed

Hi Moritz,

2017-03-09 21:55 GMT+01:00 Moritz Schmidt :
> Package: kodi
> Version: 2:17.0+dfsg1-3
> Severity: important
>
> Dear maintainer,
>
> I installed the kodi package on a fresh installed debian testing and enabled 
> the kodi systemd-service which should start kodi in standalone mode.
> The service file (/lib/systemd/system/kodi.service) is configured to run as 
> 'kodi' user, but this user doesn't exist after installation.
> I think automatically adding the user when using him would make sense.

It would make sense if every installation used the kodi user, but
there are many people who start kodi from their normal session or set
up automatic logging in in the display manager to start kodi [1].

I was thinking about adding a debconf question about adding the kodi
user and enabling  the standalone mode during package configuration
but this is about the same amount of added complexity as the current
manual addition of the kodi user.

I think if someone sets up a system for kodi only the first added user
is usually the user which runs kodi anyway.

AFAIK the kodi-systemd-service way is preferred on constrained systems
where running even lightdm would waste too much memory,
but I have just found nodm [2] which could also help here.

> After adding the user everything works as expected.

Great!

I will consider adding the debconf question and creating the kodi
user, but not by default.

>
> Thanks for your work and have a nice day,
> Moritz Schmidt

Thanks!

Cheers,
Balint

[1] http://kodi.wiki/view/HOW-TO:Autostart_Kodi_for_Linux
[2] https://packages.qa.debian.org/n/nodm.html