Bug#964417: buster-pu: package mod-gnutls/0.9.0-1.1~deb10u1

[Adrian Bunk]

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

  * Backported patches to fix test failures with the
apache CVE-2019-10092 fix. (Closes: #950300)
  * Disable a test that fails with GnuTLS >= 3.6.11. (Closes: #950301)
  * Backported a fix for a possible segfault on failed TLS handshake.

Technically the #950301 fix is not necessary in buster,
but the tests of this package are so fragile with changes
in build dependencies that disabling a test that might
pass is better-safe-than-sorry.

Bug#964417: buster-pu: package mod-gnutls/0.9.0-1.1~deb10u1

[Adrian Bunk]

On Tue, Jul 07, 2020 at 12:58:41AM +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
>   * Backported patches to fix test failures with the
> apache CVE-2019-10092 fix. (Closes: #950300)
>   * Disable a test that fails with GnuTLS >= 3.6.11. (Closes: #950301)
>   * Backported a fix for a possible segfault on failed TLS handshake.
> 
> Technically the #950301 fix is not necessary in buster,
> but the tests of this package are so fragile with changes
> in build dependencies that disabling a test that might
> pass is better-safe-than-sorry.

The missing debdiff is attached.

cu
Adrian
diff -Nru mod-gnutls-0.9.0/debian/changelog mod-gnutls-0.9.0/debian/changelog
--- mod-gnutls-0.9.0/debian/changelog   2019-02-08 23:27:06.0 +0200
+++ mod-gnutls-0.9.0/debian/changelog   2020-07-07 00:37:00.0 +0300
@@ -1,3 +1,20 @@
+mod-gnutls (0.9.0-1.1~deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for buster.
+
+ -- Adrian Bunk   Tue, 07 Jul 2020 00:37:00 +0300
+
+mod-gnutls (0.9.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backported patches to fix test failures with the
+apache CVE-2019-10092 fix. (Closes: #950300)
+  * Disable a test that fails with GnuTLS >= 3.6.11. (Closes: #950301)
+  * Backported a fix for a possible segfault on failed TLS handshake.
+
+ -- Adrian Bunk   Sat, 08 Feb 2020 23:14:39 +0200
+
 mod-gnutls (0.9.0-1) unstable; urgency=medium
 
   [ Fiona Klute ]
diff -Nru 
mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch
 
mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch
--- 
mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch
 1970-01-01 02:00:00.0 +0200
+++ 
mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch
 2020-02-08 17:20:28.0 +0200
@@ -0,0 +1,40 @@
+From dcec2098a29e43d93efe6b0b6150e35ef198a1eb Mon Sep 17 00:00:00 2001
+From: Fiona Klute 
+Date: Thu, 28 Nov 2019 10:42:46 +0100
+Subject: Fix possible segfault (NULL pointer dereference) on failed TLS
+ handshake
+
+Calling ssl_var_lookup() after a failed handshake could lead to GnuTLS
+session information functions being called on a NULL session pointer,
+leading to segfault. I observed this in a case where mod_http2 was
+trying to check the negotiated TLS version after the client rejected
+the server certificate.
+---
+ src/mod_gnutls.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/mod_gnutls.c b/src/mod_gnutls.c
+index d6edffc..b667a9c 100644
+--- a/src/mod_gnutls.c
 b/src/mod_gnutls.c
+@@ -2,7 +2,7 @@
+  *  Copyright 2004-2005 Paul Querna
+  *  Copyright 2008, 2014 Nikos Mavrogiannopoulos
+  *  Copyright 2011 Dash Shendy
+- *  Copyright 2015-2018 Fiona Klute
++ *  Copyright 2015-2019 Fiona Klute
+  *
+  *  Licensed under the Apache License, Version 2.0 (the "License");
+  *  you may not use this file except in compliance with the License.
+@@ -178,7 +178,7 @@ char* ssl_var_lookup(apr_pool_t *p, server_rec *s 
__attribute__((unused)),
+ mgs_handle_t *ctxt = get_effective_gnutls_ctxt(c);
+ 
+ /* TLS parameters are empty if there is no session */
+-if (ctxt == NULL || ctxt->c == NULL)
++if (ctxt == NULL || ctxt->c == NULL || ctxt->session == NULL)
+ return NULL;
+ 
+ if (strcmp(var, "SSL_PROTOCOL") == 0)
+-- 
+2.20.1
+
diff -Nru 
mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch
 
mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch
--- 
mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch
  1970-01-01 02:00:00.0 +0200
+++ 
mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch
  2020-02-08 17:20:44.0 +0200
@@ -0,0 +1,291 @@
+From 20a20dfab4f9b854228ae1999b912dcab7f8c260 Mon Sep 17 00:00:00 2001
+From: Krista Karppinen 
+Date: Fri, 1 Nov 2019 23:07:20 +0200
+Subject: Test suite: ignore "Content-Length" header
+
+Do not check the returned "Content-Length" header value when running the
+tests, as long as it's valid. This will allow for more flexibility in
+matching the content in the future.
+---
+ test/runtests| 5 +++--
+ test/tests/00_basic/output   | 1 -
+ test/tests/01_serverwide_priorities/output   | 1 -
+ test/tests/03_cachetimeout_in_vhost/output   | 1 -
+ test/tests/04_basic_nosni/output | 1 -
+ test/tests/06_verify_sni_a/output| 1 -
+ test/tests/07_verify_sni_b/output  

Bug#907981: stretch-pu: package openbsc/0.15.0-2

[Adrian Bunk]

On Thu, Jul 02, 2020 at 08:19:46PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2018-09-04 at 20:38 +0200, Ruben Undheim wrote:
> > I would like to upload a fix for FTBFS (#880233) to stretch.
> > The same fix has been in sid earlier:
> 
> Apologies for the long delay. I'm not sure how this got overlooked for
> so long.
> 
> If this is still something you'd be interested in fixing, then please
> go ahead, bearing in mind that the window for getting fixes into the
> final point release before stretch moves to LTS is the weekend after
> this one.

The change in libdbi that broke openbsc is being reverted in #893439,
I would recommend dropping the openbsc change.

> Regards,
> 
> Adam

cu
Adrian

Bug#948650: stretch-pu: package nginx/1.10.3-1+deb9u3

[Adrian Bunk]

On Sat, Jun 20, 2020 at 08:22:51PM +0100, Adam D. Barratt wrote:
> On Mon, 2020-03-30 at 22:05 +0100, Adam D. Barratt wrote:
> > On Mon, 2020-01-20 at 22:43 +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Sat, 2020-01-11 at 12:19 +0200, Christos Trochalakis wrote:
> > > > I'd like to upload nginx 1.10.3-1+deb9u4, addressing the non-
> > > > critical
> > > > CVE-2019-20372.
> > > > 
> > Please go ahead, thanks.
> > 
> > Ping?
> 
> As a note, we're now planning for the final point release for stretch
> before it moves to LTS. Is this update still something of interest?

I have uploaded the package to DELAYED/2.
Feel free to cancel if anyone disagrees.

> Regards,
> 
> Adam

cu
Adrian

Bug#948652: buster-pu: package nginx/1.14.2-2+deb10u1

[Adrian Bunk]

Control: retitle -1 buster-pu: package nginx/1.14.2-2+deb10u2

The version was correct in the debdiff but not in the bug title.

On Mon, Jan 20, 2020 at 10:43:58PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2020-01-11 at 12:24 +0200, Christos Trochalakis wrote:
> > I'd like to upload nginx 1.14.2-2+deb10u2, addressing the non-
> > critical
> > CVE-2019-20372.
> > 
> 
> Please go ahead.

I have uploaded the package to DELAYED/2.
Feel free to cancel if anyone disagrees.

> Regards,
> 
> Adam

cu
Adrian

Bug#964712: buster-pu: package storebackup/3.2.1-2~deb10u1

[Adrian Bunk]

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

  * Set maintainer to Debian QA Group. (see #856299)
  * Add patch to change the way the lockfile is opened in the Perl code.
(Fixes: CVE-2020-7040) (Closes: #949393)

CVE-2020-7040 is "no DSA" in stretch and buster.
diff -Nru storebackup-3.2.1/debian/changelog storebackup-3.2.1/debian/changelog
--- storebackup-3.2.1/debian/changelog  2012-06-17 07:31:31.0 +0300
+++ storebackup-3.2.1/debian/changelog  2020-07-09 14:59:51.0 +0300
@@ -1,3 +1,19 @@
+storebackup (3.2.1-2~deb10u1) buster; urgency=medium
+
+  * QA upload.
+  * Rebuild for buster.
+
+ -- Adrian Bunk   Thu, 09 Jul 2020 14:59:51 +0300
+
+storebackup (3.2.1-2) unstable; urgency=medium
+
+  * QA upload.
+  * Set maintainer to Debian QA Group. (see #856299)
+  * Add patch to change the way the lockfile is opened in the Perl code.
+(Fixes: CVE-2020-7040) (Closes: #949393)
+
+ -- Adrian Bunk   Wed, 08 Jul 2020 15:54:21 +0300
+
 storebackup (3.2.1-1) unstable; urgency=low
 
   * change short description, recommendation from Heinz-Josef Claes
diff -Nru storebackup-3.2.1/debian/control storebackup-3.2.1/debian/control
--- storebackup-3.2.1/debian/control2012-06-16 13:21:56.0 +0300
+++ storebackup-3.2.1/debian/control2020-07-08 15:54:21.0 +0300
@@ -1,7 +1,7 @@
 Source: storebackup
 Section: utils
 Priority: optional
-Maintainer: Ryan Niebur 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 7.2), perl
 Standards-Version: 3.9.3
 Homepage: http://www.nongnu.org/storebackup/
diff -Nru storebackup-3.2.1/debian/patches/CVE-2020-7040.patch 
storebackup-3.2.1/debian/patches/CVE-2020-7040.patch
--- storebackup-3.2.1/debian/patches/CVE-2020-7040.patch1970-01-01 
02:00:00.0 +0200
+++ storebackup-3.2.1/debian/patches/CVE-2020-7040.patch2020-07-08 
15:54:21.0 +0300
@@ -0,0 +1,27 @@
+Description: changing the way the lockfile is opened in the Perl code
+Author: Jan Ritzerfeld
+Author: Utkarsh Gupta 
+Bug-Debian: https://bugs.debian.org/949393
+Origin: https://www.openwall.com/lists/oss-security/2020/01/20/3/1
+Last-Update: 2020-02-04
+
+--- a/lib/fileDir.pl
 b/lib/fileDir.pl
+@@ -22,7 +22,7 @@
+ 
+ push @VERSION, '$Id: fileDir.pl 364 2012-02-12 14:14:44Z hjc $ ';
+ 
+-use Fcntl qw(O_RDWR O_CREAT);
++use Fcntl qw(O_RDWR O_CREAT O_WRONLY O_EXCL);
+ use POSIX;
+ 
+ require 'prLog.pl';
+@@ -404,7 +404,7 @@
+ '-str' => ["creating lock file <$lockFile>"]);
+ 
+ &::checkDelSymLink($lockFile, $prLog, 0x01);
+-open(FILE, "> $lockFile") or
++sysopen(FILE, $lockFile, O_WRONLY | O_CREAT | O_EXCL) or
+   $prLog->print('-kind' => 'E',
+ '-str' => ["cannot create lock file <$lockFile>"],
+ '-exit' => 1);
diff -Nru storebackup-3.2.1/debian/patches/series 
storebackup-3.2.1/debian/patches/series
--- storebackup-3.2.1/debian/patches/series 2012-06-16 13:19:48.0 
+0300
+++ storebackup-3.2.1/debian/patches/series 2020-07-08 15:54:21.0 
+0300
@@ -1 +1,2 @@
 fix-spelling-error-in-manpage
+CVE-2020-7040.patch

Bug#964713: stretch-pu: package storebackup/3.2.1-2~deb9u1

[Adrian Bunk]

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

  * Set maintainer to Debian QA Group. (see #856299)
  * Add patch to change the way the lockfile is opened in the Perl code.
(Fixes: CVE-2020-7040) (Closes: #949393)

CVE-2020-7040 is "no DSA" in stretch and buster.
diff -Nru storebackup-3.2.1/debian/changelog storebackup-3.2.1/debian/changelog
--- storebackup-3.2.1/debian/changelog  2012-06-17 07:31:31.0 +0300
+++ storebackup-3.2.1/debian/changelog  2020-07-09 14:54:23.0 +0300
@@ -1,3 +1,19 @@
+storebackup (3.2.1-2~deb9u1) stretch; urgency=medium
+
+  * QA upload.
+  * Rebuild for stretch.
+
+ -- Adrian Bunk   Thu, 09 Jul 2020 14:54:23 +0300
+
+storebackup (3.2.1-2) unstable; urgency=medium
+
+  * QA upload.
+  * Set maintainer to Debian QA Group. (see #856299)
+  * Add patch to change the way the lockfile is opened in the Perl code.
+(Fixes: CVE-2020-7040) (Closes: #949393)
+
+ -- Adrian Bunk   Wed, 08 Jul 2020 15:54:21 +0300
+
 storebackup (3.2.1-1) unstable; urgency=low
 
   * change short description, recommendation from Heinz-Josef Claes
diff -Nru storebackup-3.2.1/debian/control storebackup-3.2.1/debian/control
--- storebackup-3.2.1/debian/control2012-06-16 13:21:56.0 +0300
+++ storebackup-3.2.1/debian/control2020-07-08 15:54:21.0 +0300
@@ -1,7 +1,7 @@
 Source: storebackup
 Section: utils
 Priority: optional
-Maintainer: Ryan Niebur 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 7.2), perl
 Standards-Version: 3.9.3
 Homepage: http://www.nongnu.org/storebackup/
diff -Nru storebackup-3.2.1/debian/patches/CVE-2020-7040.patch 
storebackup-3.2.1/debian/patches/CVE-2020-7040.patch
--- storebackup-3.2.1/debian/patches/CVE-2020-7040.patch1970-01-01 
02:00:00.0 +0200
+++ storebackup-3.2.1/debian/patches/CVE-2020-7040.patch2020-07-08 
15:54:21.0 +0300
@@ -0,0 +1,27 @@
+Description: changing the way the lockfile is opened in the Perl code
+Author: Jan Ritzerfeld
+Author: Utkarsh Gupta 
+Bug-Debian: https://bugs.debian.org/949393
+Origin: https://www.openwall.com/lists/oss-security/2020/01/20/3/1
+Last-Update: 2020-02-04
+
+--- a/lib/fileDir.pl
 b/lib/fileDir.pl
+@@ -22,7 +22,7 @@
+ 
+ push @VERSION, '$Id: fileDir.pl 364 2012-02-12 14:14:44Z hjc $ ';
+ 
+-use Fcntl qw(O_RDWR O_CREAT);
++use Fcntl qw(O_RDWR O_CREAT O_WRONLY O_EXCL);
+ use POSIX;
+ 
+ require 'prLog.pl';
+@@ -404,7 +404,7 @@
+ '-str' => ["creating lock file <$lockFile>"]);
+ 
+ &::checkDelSymLink($lockFile, $prLog, 0x01);
+-open(FILE, "> $lockFile") or
++sysopen(FILE, $lockFile, O_WRONLY | O_CREAT | O_EXCL) or
+   $prLog->print('-kind' => 'E',
+ '-str' => ["cannot create lock file <$lockFile>"],
+ '-exit' => 1);
diff -Nru storebackup-3.2.1/debian/patches/series 
storebackup-3.2.1/debian/patches/series
--- storebackup-3.2.1/debian/patches/series 2012-06-16 13:19:48.0 
+0300
+++ storebackup-3.2.1/debian/patches/series 2020-07-08 15:54:21.0 
+0300
@@ -1 +1,2 @@
 fix-spelling-error-in-manpage
+CVE-2020-7040.patch

Bug#964714: buster-pu: package appstream-glib/0.7.14-1+deb10u1

[Adrian Bunk]

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

  * Backport upstream fix for FTBFS in the year 2020.
(Closes: #949169)
diff -Nru appstream-glib-0.7.14/debian/changelog 
appstream-glib-0.7.14/debian/changelog
--- appstream-glib-0.7.14/debian/changelog  2018-12-05 23:29:52.0 
+0200
+++ appstream-glib-0.7.14/debian/changelog  2020-07-09 15:16:46.0 
+0300
@@ -1,3 +1,11 @@
+appstream-glib (0.7.14-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for FTBFS in the year 2020.
+(Closes: #949169)
+
+ -- Adrian Bunk   Thu, 09 Jul 2020 15:16:46 +0300
+
 appstream-glib (0.7.14-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
 
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
--- 
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
  1970-01-01 02:00:00.0 +0200
+++ 
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
  2020-07-09 15:16:46.0 +0300
@@ -0,0 +1,40 @@
+From 953c8e529d7291e60a95e580967ed79ce2c9ccf0 Mon Sep 17 00:00:00 2001
+From: Richard Hughes 
+Date: Mon, 6 Jan 2020 11:04:56 +
+Subject: trivial: Fix CI by moving 'future' back a bit
+
+2020 seemed like such a long time in the future all those years ago...
+---
+ data/tests/broken.appdata.xml   | 2 +-
+ libappstream-glib/as-app-validate.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/data/tests/broken.appdata.xml b/data/tests/broken.appdata.xml
+index f7a5386..cf80f5b 100644
+--- a/data/tests/broken.appdata.xml
 b/data/tests/broken.appdata.xml
+@@ -40,7 +40,7 @@
+ This is a duplicate release on the same day!
+   
+ 
+-
++
+   
+ This is a release in the future!
+   
+diff --git a/libappstream-glib/as-app-validate.c 
b/libappstream-glib/as-app-validate.c
+index c1103ac..f50e4e4 100644
+--- a/libappstream-glib/as-app-validate.c
 b/libappstream-glib/as-app-validate.c
+@@ -864,7 +864,7 @@ as_app_validate_release (AsApp *app,
+AS_PROBLEM_KIND_ATTRIBUTE_MISSING,
+" has no timestamp");
+   }
+-  if (timestamp > 20120101 && timestamp < 20251231) {
++  if (timestamp > 20120101 && timestamp < 20351231) {
+   ai_app_validate_add (helper,
+AS_PROBLEM_KIND_ATTRIBUTE_INVALID,
+" timestamp should be a UNIX 
time");
+-- 
+2.20.1
+
diff -Nru appstream-glib-0.7.14/debian/patches/series 
appstream-glib-0.7.14/debian/patches/series
--- appstream-glib-0.7.14/debian/patches/series 1970-01-01 02:00:00.0 
+0200
+++ appstream-glib-0.7.14/debian/patches/series 2020-07-09 15:16:46.0 
+0300
@@ -0,0 +1 @@
+0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch

Bug#964715: buster-pu: package mydumper/0.9.5-1+deb10u1

[Adrian Bunk]

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

  * Link mydumper against libm. (Closes: #956020)

libmariadb-dev removed some libraries like -lssl and -lm
from Libs in the pkg-config file.

This is correct, and reduces the amount of unnecessary linking.

But in mydumper this exposed a missing -lm
(OpenSSL is not used directly by mydumper).

gcc appears to inline the one call to ceil() on all release
architectures except armel/armhf/mips/mipsel, only on these
architectures did the libmariadb-dev change expose the FTBFS.
diff -Nru mydumper-0.9.5/debian/changelog mydumper-0.9.5/debian/changelog
--- mydumper-0.9.5/debian/changelog 2018-12-19 11:17:53.0 +0200
+++ mydumper-0.9.5/debian/changelog 2020-07-09 15:25:49.0 +0300
@@ -1,3 +1,10 @@
+mydumper (0.9.5-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Link mydumper against libm. (Closes: #956020)
+
+ -- Adrian Bunk   Thu, 09 Jul 2020 15:25:49 +0300
+
 mydumper (0.9.5-1) unstable; urgency=medium
 
   * New upstream release (Closes: #897913)
diff -Nru mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch 
mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch
--- mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch 
1970-01-01 02:00:00.0 +0200
+++ mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch 
2020-07-09 15:25:49.0 +0300
@@ -0,0 +1,26 @@
+From 47b179ace22a2b4f4e5a3e783d6a79cc44a65708 Mon Sep 17 00:00:00 2001
+From: Adrian Bunk 
+Date: Fri, 8 May 2020 20:12:57 +0300
+Subject: Link mydumper against libm
+
+This is required due to mydumper.c using ceil().
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index ca9591f..ea4bb85 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -37,7 +37,7 @@ if (WITH_BINLOG)
+ else (WITH_BINLOG)
+   add_executable(mydumper mydumper.c server_detect.c g_unix_signal.c 
connection.c getPassword.c)
+ endif (WITH_BINLOG)
+-target_link_libraries(mydumper ${MYSQL_LIBRARIES} ${GLIB2_LIBRARIES} 
${GTHREAD2_LIBRARIES} ${PCRE_PCRE_LIBRARY} ${ZLIB_LIBRARIES} stdc++)
++target_link_libraries(mydumper ${MYSQL_LIBRARIES} ${GLIB2_LIBRARIES} 
${GTHREAD2_LIBRARIES} ${PCRE_PCRE_LIBRARY} ${ZLIB_LIBRARIES} stdc++ m)
+ 
+ 
+ add_executable(myloader myloader.c connection.c getPassword.c)
+-- 
+2.20.1
+
diff -Nru mydumper-0.9.5/debian/patches/series 
mydumper-0.9.5/debian/patches/series
--- mydumper-0.9.5/debian/patches/series2018-12-19 11:17:53.0 
+0200
+++ mydumper-0.9.5/debian/patches/series2020-07-09 15:25:49.0 
+0300
@@ -1,3 +1,4 @@
 0001-manpage-whatis-description.patch
 0002-dont-install-documentation-source.patch
 0005-fix-cmake-define-ssl
+0001-Link-mydumper-against-libm.patch

Bug#948652: buster-pu: package nginx/1.14.2-2+deb10u1

[Adrian Bunk]

On Fri, Jul 10, 2020 at 11:01:13AM +0100, Adam D. Barratt wrote:
> On Wed, 2020-07-08 at 16:07 +0300, Adrian Bunk wrote:
> > Control: retitle -1 buster-pu: package nginx/1.14.2-2+deb10u2
> > 
> > The version was correct in the debdiff but not in the bug title.
> > 
> > On Mon, Jan 20, 2020 at 10:43:58PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Sat, 2020-01-11 at 12:24 +0200, Christos Trochalakis wrote:
> > > > I'd like to upload nginx 1.14.2-2+deb10u2, addressing the non-
> > > > critical
> > > > CVE-2019-20372.
> > > > 
> > > 
> > > Please go ahead.
> > 
> > I have uploaded the package to DELAYED/2.
> > Feel free to cancel if anyone disagrees.
> 
> Out of interest, have you tested the patch directly, or just built and
> uploaded Christos's debdiff?

The debdiff was already approved by the release team,
and the patch matches the one linked from the security tracker.

My testing was just basic build and install testing.

> Regards,
> 
> Adam

cu
Adrian

Bug#964881: RM: getlive/2.4+cvs20120801-1

[Adrian Bunk]

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

getlive is broken due to Hotmail changes (#950452)
and was already removed from buster (#959491).

Bug#964883: RM: gplaycli/0.2.1-1

[Adrian Bunk]

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

gplaycli in buster was broken by Google API changes (#950112)
and already removed in the last buster point release (#958231).

I have confirmed that the older version in stretch is also nonfunctional.

Bug#964885: RM: kerneloops/0.12+git20140509-6

[Adrian Bunk]

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

The kerneloops package is no longer usable since the
service http://oops.kernel.org is no longer available. (#953172)

It was already removed from buster. (#958575)

Re: Optional Build-Depends

[Adrian Bunk]

On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote:
>...
> We have came up with a syntax, one goal being to break parsers and not
> silently ignore optional deps:
> 
>   Build-Depends: foo? (>= 1) | baz

Any suggestion has to equally cover runtime dependencies,
the same situation is common there.

> The behavior being:
> 
>If foo resolves to a valid package name, this is a normal
>dependency. So if it's like version 0.9, the dependency would
>be unsat/depwait
> 
>For tools stripping alternatives, which I think buildds do,
>it becomes slightly more complex, as they need to check if
>foo exists:
> 
>  foo exists => drop `| baz`
>  foo does not exist => drop `foo? (>= 1.0) |`
> 
>(this is obviously a recursive thing)
>...

How would optional dependencies be handled for testing migration
and testing autoremoval?

The intuitive handling would be that the package can migrate to testing 
when baz is in testing but foo is not,
and can stay in testing when foo gets removed from testing but baz stays 
in testing.[1]

If anyone would suggest checking whether foo is in unstable
the obvious next question would be what should happen if foo
is stuck in NEW at the time the package enters unstable,
and foo then enters unstable after the migration of your package.

foo might have missed the freeze deadline, this would break
uploading your package to unstable during the freeze.

> 1. You can start optionally build-depending on stuff available
>only on some architectures, without having to use arch restriction
>lists.
> 
>   Arch restriction lists are tediuous, especially also because in
>   the case of libraries, they need to be recursively applied:
>
> libfoo is only available on bar
> libbaz depends on libfoo
>
>   results in build-depends: libbaz [bar]
>
>   With optional build-depends, you can just write libbaz? and
>   not have to update the dep each time libfoo appears on a new
>   arch. (apply argument to longer recursive chains)
>...

It was never necessary to use arch restriction lists for that.

When several reverse dependencies are affected, the correct solution
for this problem is one package (or Provides) foobaz that selects the 
package for an architecture.

cu
Adrian

[1] assuming no runtime dependencies are generated on packages from foo

Re: Bug#828097: Possible to keep old tidy?

[Adrian Bunk]

On Tue, Oct 04, 2016 at 09:21:00PM +, Gianfranco Costamagna wrote:
> Hi,
> (not sure why this bug is still open)
> 
> 
> >The upgrade of tidy to the newer version breaks what MediaWiki expects
> >(see test failures:
> >), and updating
> >MediaWiki to be compatible with the newer tidy isn't an option either:
> >.
> 
> >>So is it possible to keep the older version of tidy around? Preferably
> >also via the php-tidy library, though I'm not sure exactly how that
> >integration would work.
> 
> 
> I really don't think this is possible.
> There can be only one tidy implementation, and we have maintainer choose
> the actively maintained one (also Fedora did, and I'm sure other distro too).
> 
> Fix the code with the new library is your best solution.
> Or make somebody upload the old tidy with a different library name, and patch
> the code to use that one.
> (I would oppose such bad way to deal with a library update btw)

There is no technical reason why the two tidy versions couldn't coexist 
long-term in the archive if someone would ITP the old version back into 
unstable - the libraries have different so-names so that was already 
handled, and by using alternatives and/or calling the old binary tiny-old.

This would not be desirable, but shouldn't cause any problems.

The tidy PHP extension is a different story.

php-horde-text-filter is the only rdep of php{,5,7.0}-tidy that
is not completely broken (galette is pretty RC-buggy), so making
the tidy PHP extension in stretch use the old tidy would also
likely be doable.[1]

But the solution with minimum impact for everyone else would be to ITP 
the old tidy version back into unstable with the binary renamed to 
tidy-old, and patching MediaWiki to not use the PHP extension.

Looking at [2], it seems that for buster the problem will be fixed by 
MediaWiki no longer using tidy?

> G.

cu
Adrian

BTW: Why doesn't the mediawiki package have any kind of dependency
 on tidy or php-tidy?

[1] Which tidy version does php-horde-text-filter expect?
[2] https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy

-- 

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

Re: Bug#828097: Possible to keep old tidy?

[Adrian Bunk]

On Wed, Oct 05, 2016 at 01:17:28AM +0300, Adrian Bunk wrote:
> On Tue, Oct 04, 2016 at 09:21:00PM +, Gianfranco Costamagna wrote:
> > Hi,
> > (not sure why this bug is still open)
> > 
> > 
> > >The upgrade of tidy to the newer version breaks what MediaWiki expects
> > >(see test failures:
> > ><https://people.wikimedia.org/~legoktm/tidy-failures.log>),
>...

Looking at the log again, are there any actual semantic changes in the 
output of the different tidy versions that affect MediaWiki?

This looks like testcase failures due to different indentation,
not like something that would make any difference at all when
viewed with a browser.

cu
Adrian

-- 

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

Re: Bug#833574: monotone: FTBFS on powerpc (test suite failure)

[Adrian Bunk]

Control: found 833574 1.1-4
Control: fixed 833574 1.1-7

On Sat, Sep 10, 2016 at 08:39:41PM +0200, Markus Wanner wrote:
> On 08/06/2016 10:59 AM, Julien Cristau wrote:
> > the latest monotone security upload failed to build on powerpc with an
> > error in the test suite, see the build log at
> > https://people.debian.org/~carnil/buildd-logs/monotone/monotone_1.1-4+deb8u1_powerpc-20160510-1643.gz
> 
> This seems related to #797386, which I fixed in 1.1-7 by adjusting the
> test. See patch 51-sigpipe-test.diff.
> 
> I'm certain this is irrelevant from a security perspective, as the
> binaries remain the same with or without the patch. However, I'm not
> sure how to proceed with this bug, either.

A testcase that fails sometimes is not good.

This is a testcase-only fix that is already in unstable,
that fixes sporadic build failures.

I would suggest to upload 1.1-4+deb8u2 (created on top of 1.1-4+deb8u1) 
with 51-sigpipe-test.diff added to jessie, but Julien (or any other SRM) 
should confirm that.

> Kind Regards
> 
> Markus Wanner

cu
Adrian

-- 

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

Re: Architecture qualification meeting, scheduling

[Adrian Bunk]

[ fullquote adding -ports, for people not following -release or -devel ]

On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
> 
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also take
> input from porters.
> 
> As the schedule is currently wide open, please express your availability in
> the linked Doodle poll. There are 56 slots available, mostly in the European
> evening but a handful are daytime coinciding with the Cambridge
> mini-Debconf.
> 
> Porters, please note your architecture in your response ("name (arch)").
> 
> About the format of the meeting:
> Much like the Jessie meeting, it will be held via IRC in
> oftc.net/#debian-release and will be primarily a discussion amongst the
> release team. We will evaluate each port on the most up-to-date information
> available to us, and determine if it will be a release architecture for
> Stretch. We may ask for clarification from porters who are present if there
> are points at issue, but we ask that you are read-only otherwise.
> 
> http://doodle.com/poll/362qvb89cvu43d4z

Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
information available to you, and the "candidate" line how a decision
would look like based on the current information?

cu
Adrian

-- 

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

Re: Porter roll call for Debian Stretch

[Adrian Bunk]

[ adding debian-powerpc ]

On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier  schrieb:
> > If I am to support powerpc as a realease architecture for Stretch, I
> > need to know that there are *active* porters behind it committed to
> > keeping it in the working.  People who would definitely catch such
> > issues long before the release.  People who file bugs / submit patches etc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> a powerpc-specific build failure of mariadb in stable. The maintainer
> said he can't work on it, so if anyone considers himself/herself a
> powerpc porter, this is something to look it.

Can you give a hint what exactly should be looked at?

The bug did not make it clear that there is any problem left at all when 
I looked at it recently.

The last message was closing the bug.

There was a control command reopening the bug without giving any 
rationale, but the last control command was
  fixed 832931 10.0.27-1

buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

If there is a problem left somewhere it is well-hidden, and not visible 
immediately when looking at the bug - I thought this was already resolved.

> Cheers,
> Moritz

cu
Adrian

[1] https://buildd.debian.org/status/package.php?p=mariadb-10.0&suite=jessie

-- 

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

Re: Porter roll call for Debian Stretch

[Adrian Bunk]

On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote:
> On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> > [ adding debian-powerpc ]
> > 
> > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > > Niels Thykier  schrieb:
> > > > If I am to support powerpc as a realease architecture for Stretch, I
> > > > need to know that there are *active* porters behind it committed to
> > > > keeping it in the working.  People who would definitely catch such
> > > > issues long before the release.  People who file bugs / submit patches 
> > > > etc.
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > > a powerpc-specific build failure of mariadb in stable. The maintainer
> > > said he can't work on it, so if anyone considers himself/herself a
> > > powerpc porter, this is something to look it.
> > 
> > Can you give a hint what exactly should be looked at?
> 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0&arch=powerpc&ver=10.0.27-0%2Bdeb8u1&stamp=1473621159
> 
> > The bug did not make it clear that there is any problem left at all when 
> > I looked at it recently.
> > 
> > The last message was closing the bug.
> > 
> > There was a control command reopening the bug without giving any 
> > rationale, but the last control command was
> >   fixed 832931 10.0.27-1
> 
> For unstable, yes. The stable package is still broken.

Thanks.

When skimming through that the bug I thought it was fixed in 
upstream 10.0.27, and no comment in the bug indicated otherwise.

As (pretty passive) reader of debian-powerpc, I am also puzzled by the 
fact that I cannot recall #832931 ever being mentioned there.

An email to the bug and the mailing list of the port stating that there 
is a problem, and what is known about it, can be really helpful for 
getting such a bug resolved.


> > buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]
> 
> That's an artefact of how builds for suites with "overlays" (i.e. pu /
> tpu) are displayed. If one actually looks at the archive:
> 
> mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
> mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
> armhf, i386, mips, mipsel, ppc64el, s390x

Ouch.

I thought the information in the version tracking was wrong
when buildd.d.o showed green.


> Regards,
> 
> Adam

cu
Adrian

-- 

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

ppc64el porter situation

[Adrian Bunk]

Disclaimer:
I am not a member of the release team, and I am only speaking for myself.


The architecture requalification status for stretch [1] lists the 
ppc64el porter situation as green, but there are three reasons why
the situation doesn't look that good to me.


First, official status of the porters:
- 1 DD
- 1 DM
- 2 no DD/DM

Is a DM enough, if the only DD gets killed by a car [2] the day after 
the release of stretch?


Second, all 4 committed porters seem to be employees of IBM.

What happens if for whatever good or bad reason IBM decides in 2018
or 2019 to go away from ppc64el, and all 4 committed porters get fired?

The wording of the porter commitment is already limited to "I intend to",
and there is the single point of failure that one business decision
by IBM might reduce the number of porters immediately from 4 to 0.


Third, the skills of the committed porters for post-release work.

It is extremely valuable when people are doing manual and automated 
testing and fix the usual porting issues prior to the release.

But the most important skills required post-release until end-2020 are 
quite different.

How many of the committed ppc64el porters are personally able to fix
difficult issues that require intimate knowledge of hardware, kernel
and toolchain?

Lack of redundancy in these skills was the problem of the sparc port
in wheezy when the only skilled porter left.


The s390x port is yellow in the porters row due to having only two 
porters committed.

Just looking at the numbers 4 sounds twice as good as 2, but for the 
reasons explained above I think the ppc64el porter situation is actually
worse than on s390x, and should be marked as yellow or red.


cu
Adrian

[1] https://release.debian.org/stretch/arch_qualify.html
[2] I do not wish bad to anyone, but from the Debian point of view
this is why reduncancy is required.

-- 

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

Re: Enabling PIE by default for Stretch

[Adrian Bunk]

Hi,

since PIE is now default in unstable, I assume all/most of these bugs 
should be changed to RC?

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906&users=bal...@balintreczey.hu;dist=unstable

cu
Adrian

-- 

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

Re: ppc64el porter situation

[Adrian Bunk]

On Wed, Oct 19, 2016 at 09:06:14AM -0200, Breno Leitao wrote:
> Hello Adrian,

Hi Breno,

> Let me share my view as the only DD listed as ppc64el porter.

thanks for your reply.

Just to state it explicitely in case that was not clear, I do not have 
any problem with you personally or the ppc64el port in general.

I am just saying that I see a risk for the ppc64el port in the
unlikely case that IBM makes a sudden move away from PowerPC
during the lifetime of stretch.

> On Mon, Oct 17, 2016 at 10:50:01PM +0300, Adrian Bunk wrote:
> > Is a DM enough, if the only DD gets killed by a car [2] the day after
> > the release of stretch?
> 
> The other DM is in the process of becoming a DD[1]. This might reduce
> the truck factor by half.
> 
> [1] https://nm.debian.org/person/frediz

That's good news.

> > Second, all 4 committed porters seem to be employees of IBM.
> >
> > What happens if for whatever good or bad reason IBM decides in 2018
> > or 2019 to go away from ppc64el, and all 4 committed porters get fired?
> 
> I understand your point here. ppc64el architecture is IBM's current and
> future focus. ppc64el is also planned for POWER9 and beyond. While it's
> hard to predict what future business decisions IBM may make, we believe
> the future of ppc64el and OpenPower systems looks good.
> 
> There are many other distros that support ppc64el at this moment, as
> Ubuntu, Fedora, SLES, RHEL and others coming. So, your point is not
> Debian specific, but, generic to the Linux ecossystem.

Debian is in a different situation, the porters of these distributions 
are likely employed by the company behind the distribution and not
by IBM.

> > The wording of the porter commitment is already limited to "I intend
> > to", and there is the single point of failure that one business
> > decision by IBM might reduce the number of porters immediately from 4
> > to 0.
> 
> Right, since ppc64el machines are not desktop/personal machines, it is
> harder to get porters, compared to more pervasive architectures, as amd64.
> I hope to have more DD porters in the future, as ppc64el become more
> prevalent.
> 
> lso, there are many other hardware manufactors and partners that relies
> on Linux for the Power platform[1]. In my opinion, the Power platform is
> bigger than IBM at this moment.
> 
> [1] http://openpowerfoundation.org/membership/current-members/

https://en.wikipedia.org/wiki/MeeGo#Companies_supporting_the_project

That's also an impressive list of companies, isn't it?
When the one company that mattered switched to a different platform,
the whole platform collapsed immediately.

The whole Power platform also seems to be mostly around IBM.

>...
> On the other side, if there is a requirements for being a porter that
> says that the porter might be able to fix difficult issues on kernel and
> toolchain, then it is a different story. I do not believe that this
> requirement exists.
>

It is not a requirement for every porter, but that skill is required.

Debian got burned in wheezy in the sparc port when no porter was 
available to fix a broken kernel after the release.

That was an embarrassment to the Debian stability and quality that noone 
wants to ever see again.

cu
Adrian

-- 

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

Re: ppc64el porter situation

[Adrian Bunk]

On Wed, Oct 19, 2016 at 12:06:59PM +0200, Aurelien Jarno wrote:
> Hi,

Hi Aurelien,

>...
> To me it looks like they are really skilled for that job. Do you have
> actual facts showing the contrary?

Niels said that I shouldn't hesitate to let the release team know when
I believe there is an issue they have overlooked.[1]

I do believe that there is a risk in the ppc64el port in the unlikely 
case that IBM suddenly moves away from PowerPC, and that is currently 
not mentioned in the architecture requalification table.

This is not about past work done by the ppc64el porters, this is about
a specific single point of failure that could happen in the future.

In my opinion this is a risk, and the release team should be aware
of it when making the decision regarding architectures in stretch.

I do appreciate the answers from Breno and you that addressed some
of the things I brought up.

I do expect the release team to read this discussion and take it
into consideration.

I am not involved in the decision regarding ports in stretch,
and any decision is fine with me.

> Aurelien

cu
Adrian

[1] https://lists.debian.org/debian-release/2016/10/msg00131.html

-- 

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

Re: ppc64el porter situation

[Adrian Bunk]

On Thu, Oct 20, 2016 at 03:58:21PM -0400, Lennart Sorensen wrote:
> On Thu, Oct 20, 2016 at 03:54:43PM -0400, Lennart Sorensen wrote:
> > I think Freescala/NXP might disagree.  Not sure if the e6500 core could
> > ruin ppc64el or not, but they certainly make a lot of powerpc chips.
> 
> That should have said 'run' not 'ruin'.  That would have been rather
> interesting otherwise.

Freescala/NXP is not even on the OpenPOWER member list - this is not the 
old power.org

For their network processors Freescala/NXP is moving away from PowerPC, 
and their first ARM based network processors are already on the market.

> Len Sorensen

cu
Adrian

-- 

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

Re: Enabling PIE by default for Stretch

[Adrian Bunk]

On Thu, Oct 20, 2016 at 11:43:22PM +0200, Bálint Réczey wrote:
> Hi Adrian,

Hi Bálint,

> 2016-10-20 21:02 GMT+02:00 Adrian Bunk :
> > Hi,
> >
> > since PIE is now default in unstable, I assume all/most of these bugs
> > should be changed to RC?
> 
> Yes, they should.
>...

I went through all the bugs and made them RC.

Whenever a bug was clearly in another package or had to be merged with 
another bug I also did that.

There are 3 exceptions left in the list:

#586572 libdpkg-dev: Please provide a libdpkg shared library
I assume this would only be relevant for #835149?

#837425 deets: FTBFS with bindnow and PIE enabled
As I wrote in the bug, it works for me.
And I do not understand why it does not fail for me.
Can you reproduce it in unstable?

#837663 kannel-dev: Please build libgwlib.a with -fPIC
Can you double-check whether something went wrong when you submitted 
this bug?

Thanks
Adrian

-- 

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

Re: premail is marked for autoremoval from testing

[Adrian Bunk]

On Sat, Oct 22, 2016 at 04:39:13AM +, Debian testing autoremoval watch 
wrote:
> premail 0.46-10 is marked for autoremoval from testing on 2016-11-20
> 
> It (build-)depends on packages with these RC bugs:
> 837712: xemacs21: FTBFS with bindnow and PIE enabled

Is this bogus?

I cannot see any direct or indirect (build-)depends of premail
on xemacs21.

cu
Adrian

-- 

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

Re: premail is marked for autoremoval from testing

[Adrian Bunk]

On Sat, Oct 22, 2016 at 11:24:46AM +0100, Adam D. Barratt wrote:
> On Sat, 2016-10-22 at 11:17 +0300, Adrian Bunk wrote:
> > On Sat, Oct 22, 2016 at 04:39:13AM +, Debian testing autoremoval watch 
> > wrote:
> > > premail 0.46-10 is marked for autoremoval from testing on 2016-11-20
> > > 
> > > It (build-)depends on packages with these RC bugs:
> > > 837712: xemacs21: FTBFS with bindnow and PIE enabled
> > 
> > Is this bogus?
> > 
> > I cannot see any direct or indirect (build-)depends of premail
> > on xemacs21.
> 
> It would need someone more familiar with the autoremovals code to
> confirm, but I imagine it's due to premail's dependency on the
> "mail-reader" virtual package, which is provided by, among others,
> xemacs21-gnome-mule, xemacs21-gnome-mule-canna-wnn,
> xemacs21-gnome-nomule, xemacs21-mule, xemacs21-mule-canna-wnn and
> xemacs21-nomule.

Looking at the tracker page for premail [1] you seem to be right 
regarding where the problem is:

premail already got removed from testing 4 times this year when
a mail-reader was removed, and always re-entered testing the
following day.

Some autoremoval bug involving virtual packages and contrib?

> Regards,
> 
> Adam

cu
Adrian

[1] https://tracker.debian.org/pkg/premail

-- 

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

Re: ppc64el porter situation

[Adrian Bunk]

On Fri, Oct 21, 2016 at 01:30:13PM -0400, Lennart Sorensen wrote:
> On Thu, Oct 20, 2016 at 11:18:39PM +0300, Adrian Bunk wrote:
> > Freescala/NXP is not even on the OpenPOWER member list - this is not the 
> > old power.org
> 
> Neither is AMCC as far as I can tell.  Doesn't mean they aren't still
> doing powerpc.

Are they developing new powerpc products?

Their latest products are also pretty ARM.

> > For their network processors Freescala/NXP is moving away from PowerPC, 
> > and their first ARM based network processors are already on the market.
> 
> That's not what they are telling their customers.  They insist they are
> very much behind both arm and powerpc.

Are you talking about new e6500 SoCs, or are you only talking about 
support for existing products?

I have no doubt they will continue to provide support for e6500 for 
several years, just like they supported SoCs with SPE cpus in their
SDK until December 2015.

They released only two e6500 based SoCs for QorIQ (T2080 and T4240),[1]
and for one of them samples of ARM replacements are already available.

These are anyway big endian, but the general situation is that there
is not much powerpc development left that does not depend on IBM.

> Len Sorensen

cu
Adrian

[1] with T2081/T4160/T4080 variants, plus two in the Qonverge platform

-- 

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

Static libraries - PIC or PIE?

[Adrian Bunk]

Hi Bálint,

there is some confusion regarding how static libraries should be 
compiled now.

Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".

Why do these say -fPIC and not -fPIE?

My current understanding is that a binNMU would recompile the the static 
library with PIE (not PIC), and that this is sufficient.

Thanks
Adrian

-- 

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

Re: Static libraries - PIC or PIE?

[Adrian Bunk]

On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> Hi Ardian,

Hi Bláint, ;-)

> 2016-10-23 10:18 GMT+02:00 Adrian Bunk :
> > Hi Bálint,
> >
> > there is some confusion regarding how static libraries should be
> > compiled now.
> >
> > Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".
> >
> > Why do these say -fPIC and not -fPIE?
> 
> I suggest using -fPIC, because then the shared libraries would be
> usable in shared (PIC) libraries libraries, too.

you have created a lot of confusion by mixing two separate issues.

One of the worst examples:
#837658 libfl-dev: Please build libfl_pic.a with -fPIC
#841203 nmu: flex_2.6.1-1

A _pic.a library compiled without -fPIC sounds like a clear bug,
and a binNMU that will recompile it with -fPIE won't fix that bug.

> This in many cases also simplify debian/rules.

No, it would actually make building static libraries a real pain.

Think of a normal source package building shared libraries,
static libraries and some programs.

How do you want to tell the build system of the package that it should 
build the static libraries with -fPIC, but not the programs?

> I also suggested changing the policy #837478.

Unless I misunderstand something, current policy is perfectly fine
for the PIE change, and your claims in #837478 that building static 
libraries with -fPIC would be required for PIE binaries are not
correct.

> > My current understanding is that a binNMU would recompile the the static
> > library with PIE (not PIC), and that this is sufficient.
> 
> In most of the cases this would be sufficient, but at the time I filed the
> bugs the default was -no-pie, thus it was not an option.

It is clear that the binNMUs have to happen after the change.

It would have created less confusion to not file bugs in cases where no 
maintainer action is required, ask the release team to schedule binNMUs 
for the static libraries known to need them immediately after the 
compiler change, and announce on debian-devel-announce that some 
transient build failures might be observed immediately after the 
compiler change until the binNMUs are done.

I'll sort out what binNMUs are required later today.

> I'm OK with performing binnmu-s and decreasing the severity of the 'solved'
> bugs to wishlist.

With the exception of special cases like #837658 a binNMU will 
completely solve it, and there is no point in having wishlist
bugs for something not really permitted by policy.

> Cheers,
> Balint

cu
Adrian

-- 

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

Re: Static libraries - PIC or PIE?

[Adrian Bunk]

On Sun, Oct 23, 2016 at 03:17:06PM +0200, Bálint Réczey wrote:
> Hi Adrian,
> 
> 2016-10-23 13:26 GMT+02:00 Adrian Bunk :
> > On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> >> Hi Ardian,
> >
> > Hi Bláint, ;-)
> 
> I'm sorry. :-)

No problem. :-)

>...
> >> This in many cases also simplify debian/rules.
> >
> > No, it would actually make building static libraries a real pain.
> 
> Could you please show an example?
> I went trough many packages and adding -fPIC was really
> straight-forward every time. OTOH packages providing both
> shared and static libraries build some parts twice like in antlr's
> case:

Usually building everything twice is done by the build system of the 
package, and debian/rules just calls $(MAKE)

> build-stamp:
> dh_testdir
> uudecode -o debian/antlr.snk debian/antlr.snk.uue
> $(MAKE) -f debian/Makefile.debian compile build_antlr
> $(MAKE) -C lib/cpp CXXFLAGS="+ -fPIC -DPIC"
> mv -f lib/cpp/src/libantlr.a debian/libantlr-pic.a
> $(MAKE) -C lib/cpp clean
> $(MAKE) -C lib/cpp
> touch build-stamp

That's a good example why this is a real pain.

You really don't want to force maintainers to dissect the build of their 
packages, especially in the normal case where just calling $(MAKE) was
working without your proposed requirement.

Just passing normal CFLAGS from dpkg-buildflags through the package 
build to the compiler is still not working in a huge number of packages 
after years, and this would be worse by several orders of magnitude.

> > Think of a normal source package building shared libraries,
> > static libraries and some programs.
> >
> > How do you want to tell the build system of the package that it should
> > build the static libraries with -fPIC, but not the programs?
> 
> It is usually already done by upstream or at least in packaging
> since we require -fPIC for shared libs.

You are completely wrong on that.

-fPIC is required and used for shared libraries.
Static libraries compiled with -fPIC are *very* rare.

Compiling with -fPIC for the shared library and without -fPIC for the 
static library is the one and (usually) only reason why all objects
are compiled twice when building libraries.

>...
> I assume non-PIC static library used in a PIC shared library is the
> specific case mentioned in the original text, which still does not
> work on any architecture.

Why do you want to forvce maintainers to go through great pain to get 
that working?

It is usually a bug when you end up linking a static library into a 
shared library, and in addition to a performance penalty you would
lose the benefit of getting a build failure for such bugs.

There are some rare cases of packages not building shared libraries. 
There might be other exotic situations where linking a static library 
into a shared library makes sense.
Requiring discussion of these on a case-by-case basis on debian-devel
as policy requires sounds pretty appropriate to me.

> >> > My current understanding is that a binNMU would recompile the the static
> >> > library with PIE (not PIC), and that this is sufficient.
> >>
> >> In most of the cases this would be sufficient, but at the time I filed the
> >> bugs the default was -no-pie, thus it was not an option.
> >
> > It is clear that the binNMUs have to happen after the change.
> 
> Yes, it was expected, but I think the changes would still be
> useful on architectures not enabling PIE because they allow
> enabling pie in reverse dependencies selectively.

Is there actually a good reason why PIE was only enabled on the release
architectures?

In any case, this would not provide any kind of reason for requiring 
to build static libraries with PIC.

>...
> Cheers,
> Balint

cu
Adrian

-- 

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

Bug#841839: nmu: kannel-dev_1.4.4-3

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837663 by -1

nmu kannel-dev_1.4.4-3 . ANY . unstable . -m "MySQL 5.7 recompile (removes 
-lmysqlclient_r from "gw-config --libs")"

Please close #837663 when the binNMUs are in the archive.

Bug#841921: nmu: binutils_2.27-9

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837350 by -1

nmu binutils_2.27-9 . ANY . unstable . -m "recompile static libraries with PIE"

RC bug #837350 should be closed when the binNMUs are in unstable.

Bug#841927: nmu: check_0.10.0-3

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837445 by -1

nmu check_0.10.0-3 . ANY . unstable . -m "recompile static libraries with PIE"

RC bug #837445 should be closed when the binNMUs are in unstable.

Bug#841930: nmu: jack-audio-connection-kit_1:0.125.0-1+b1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837423 by -1

nmu jack-audio-connection-kit_1:0.125.0-1 . ANY . unstable . -m "Recompile 
static libraries with PIE"

RC bug #837423 should be closed when the binNMUs are in unstable.

Bug#841938: nmu: ocaml_4.02.3-7

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837359 by -1

nmu ocaml_4.02.3-7 . ANY . unstable . -m "Recompile static libraries with PIE"

RC bug #837359 should be closed when the binNMUs are in unstable.

Bug#841938: Also block the binNMU requests

[Adrian Bunk]

Control: block -1 by 841921 837350

ocaml seems to require updated binutils for building,
also express this here.

cu
Adrian

-- 

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

Bug#841939: nmu: ocamlgraph_1.8.6-1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837456 by -1

nmu ocamlgraph_1.8.6-1 . ANY . unstable . -m "Recompile static libraries with 
PIE"

RC bug #837456 should be closed when the binNMUs are in unstable.

Bug#841941: nmu: mlton_20100608-5.1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837567 by -1

nmu mlton_20100608-5.1 . ANY . unstable . -m "Recompile static libraries with 
PIE"

RC bug #837567 should be closed when the binNMUs are in unstable.

Bug#841942: nmu: psicode_3.4.0-6

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837569 by -1

nmu psicode_3.4.0-6 . ANY . unstable . -m "Recompile static libraries with PIE"

RC bug #837569 should be closed when the binNMUs are in unstable.

Bug#841946: nmu: libint_1.1.6-2

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837686 by -1

nmu libint_1.1.6-2 . ANY . unstable . -m "Recompile static libraries with PIE"

RC bug #837686 should be closed when the binNMUs are in unstable.

Bug#841948: nmu: madness_0.10-8

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837699 by -1

nmu madness_0.10-8 . ANY . unstable . -m "Recompile static libraries with PIE"

RC bug #837699 should be closed when the binNMUs are in unstable.

Bug#842010: nmu: daq_2.0.4-3

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837687 by -1

nmu daq_2.0.4-3 . ANY . unstable . -m "Recompile static libraries with PIE"

RC bug #837687 should be closed when the binNMUs are in unstable.

Bug#842030: nmu: antlr_2.7.7+dfsg-7

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837489 by -1

nmu antlr_2.7.7+dfsg-7 . ANY . unstable . -m "Recompile static libraries with 
PIE"

RC bug #837489 should be closed when the binNMUs are in unstable.

Bug#842031: nmu: lp-solve_5.5.0.15-4

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 841683 by -1

nmu lp-solve_5.5.0.15-4 . ANY . unstable . -m "Recompile static libraries with 
PIE"

RC bug #841683 should be closed when the binNMUs are in unstable.

Bug#819530: Bad interation with libstdc++ transition.

[Adrian Bunk]

On Wed, Oct 26, 2016 at 10:39:08PM +0200, Niels Möller wrote:
> Hi,
> 
> as a user, I experience a pretty bad interaction between this transition
> and the recent libstdc++ transition.
> 
> I have a system with a mix of packages from stable and testing, which
> usually works fine. However, upgrading to the latest libstdc++ at this
> point breaks a lot of things due to gcc-6 C++ incompatibilities (which I
> don't fully understand, I usually don't care much about C++). What I see
> is that apt-get install -t testing libstdc++6 would have to uninstall
> *lots* of stuff, including build-essential, texlive, libreoffice and
> most of kde. So I don't want to do that at this time.
>...

This sounds like a problem in apt to me, and I've seen issues like
that before.

What does apt say for
  apt-get install -t testing libstdc++6 build-essential
?

If it gives an error, manually add the packages it cannot install on the 
commandline, until you either found the actual dependency problem or apt
found a way forward.

When apt found a way forward, and if it still wants to remove packages 
you want to keep, also add them on the commandline.

> Regards,
> /Niels

cu
Adrian

-- 

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

Bug#827061: transition: openssl

[Adrian Bunk]

On Tue, Oct 25, 2016 at 08:09:06PM +0200, Moritz Muehlenhoff wrote:
> On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote:
> > On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote:
> > > 
> > > I'm sorry but I'm going to have to nack this for Stretch, as much as I 
> > > like to
> > > approve transitions and get new stuff in. I have looked at the opened 
> > > bugs and
> > > I'm afraid this still is too disruptive. I have noticed that you have 
> > > forwarded
> > > some of them and sent patches, and I appreciate that. We can do this 
> > > early in
> > > the Buster cycle, so let's look at the status of this and prepare for the
> > > transition when Stretch gets released.
> > 
> > Is having 2 version of OpenSSL in Stretch an option?
> 
> We've discussed this within the security team and we'd be fine with
> a one-time exception to have two openssl releases in stretch; the API
> changes are clearly too invasive to cover the entire Debian archive,
> but 1.1 also carries sufficiently important new features (like support
> for chacha20/poly1305) to warrant the extra complexity.

What are actually the exact technical benefits of 1.1 that are relevant 
for the software in stretch?

Which new features are desirable for all OpenSSL-using software,
and for which new features is it a good option that only software
using these features opts in to using 1.1?

The only way to make chacha20/poly1305 available for all OpenSSL-using 
code in stretch would be to patch 1.0.2. Patches are available and 
LibreSSL ships this since the original release in July 2014, so that 
should be doable.

Improvements to the defaults like #728504 (disable RC4 by default) can 
be backported to 1.0.2 even more easily. And these are things that 
really should be done in any case, unless stretch ships without 1.0.2

What is the situation regarding other important 1.1 features?

> (It's the release team's call of course).
> 
> Cheers,
> Moritz

cu
Adrian

-- 

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

Bug#827061: transition: openssl

[Adrian Bunk]

Disclaimer:
I am not a member of the release team, and I am only speaking for myself.

On Sat, Oct 29, 2016 at 02:28:12AM +0200, Kurt Roeckx wrote:
>...
> I think the most important new security feature in the 1.1.0
> version is the extended master secret support. There are also a
> bunch of others like the chacha20-poly1305 and x25519, but they're
> less important. All TLS using applications really should start
> ussing the EMS, not just a few that want to switch to 1.1.

This implies that OpenSSL 1.0.2 in stretch has to support EMS.

Reality is that a significant part of the archive will likely
use 1.0.2 in stretch, and planning should not be based on the
unlikely case that everything compiles and works smoothly with 1.1.0

The soft freeze is only 2 months away, and therefore a complete 
transition to 1.1.0 in stretch would imply that libssl1.0.2 must be 
removed from testing in November if it should not delay the whole 
release - I'd expect there will be plenty of runtime bugs in both 
OpenSSL itself and the 1.1.0 support of various users that will
require debugging and fixing, and runtime testing of everything
has to start ASAP.

If everything that is important in 1.1.0 should be used by all
users of OpenSSL in stretch, then the best solution for stretch
is to ship only 1.0.2 and add all desired features there.

1.0.2 is also LTS, and has upstream security support for an additional 
16 months after upstream support for 1.1.0 has ended.

I am aware that this is not a nice solution, but since there does not 
seem to be a realistic 1.1.0-only solution without impact on the release 
schedule it might be the best among the available options.

> Kurt

cu
Adrian

-- 

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

Re: Bug#828408: fixed in libpoe-filter-ssl-perl 0.30-2

[Adrian Bunk]

On Sat, Nov 12, 2016 at 06:43:35PM +, Jonathan Wiltshire wrote:
> On 2016-11-12 17:57, gregor herrmann wrote:
> > On Sat, 12 Nov 2016 18:45:31 +0100, Moritz Muehlenhoff wrote:
> > 
> > > On Sat, Nov 12, 2016 at 04:50:25PM +, gregor herrmann wrote:
> > > > Source: libpoe-filter-ssl-perl
> > > >* Use OpenSSL 1.0.2 for the time being. (Closes: #828408)
> > > 
> > > Don't close such bugs. You used a workaround, but the bug still
> > > persists. If there are valid exceptions not to move to openssl 1.1,
> > > they should rather be tagged stretch-ignore.
> > 
> > Thanks for your mail.
> > 
> > Indeed I was a bit unsure what to do with this bug (closes or
> > downgrade+unblock or close+clone ...), and I've seen this discussed
> > on #debian-release earlier today but I didn't see a consensus or
> > clear guidance there.
> > 
> > I'm happy to have the release team / security team / OpenSSL
> > maintainers change the bug status or tell me what the preferred
> > method is, as soon is there is a clear consensus.
> 
> stretch-ignore would not be appropriate. If the bug has been worked around,
> please downgrade and unblock.

How does the release team track that all fixes are in stretch?

Example:

#843988 looks like a runtime issue triggeren by compiling
stunnel4 with OpenSSL 1.1 instead of 1.0.2

One way to fix this for now would be using OpenSSL 1.0.2 in the
build dependencies.

If this fix would never migrate to testing for whatever reason,
you would end up with an stunnel4 in stretch that uses libssl1.0.2
but build-depends on libssl-dev.

Imagine a DSA for stunnel4 in 2018.

> Thanks,

cu
Adrian

-- 

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

Re: Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)

[Adrian Bunk]

On Mon, Nov 14, 2016 at 08:44:35AM +0100, Ondřej Surý wrote:
> On Mon, Nov 14, 2016, at 08:21, Adrian Bunk wrote:
> > On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote:
> > > > Looking at mod_ssl_openssl.h and the comment in #828330,
> > > > I'd suggest the change below to add a dependency on libssl1.0-dev
> > > > to apache2-dev.
> > > 
> > > And that exactly happens meaning that PHP 7.0 can no longer be built
> > > unless all it's build-depends (including PHP 7.0) and rdepends move to
> > > libssl1.0-dev as well.
> > > 
> > > So a nice deadlock, right? To be honest I would rather have a slightly
> > > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go
> > > than revert all the work I have done.
> > > 
> > > I reviewed the patch Kurt has provided and I don't see any strong reason
> > > why anything should break.
> > >...
> > 
> > Can you guarantee that rdeps of Apache can use 1.0.2 in stretch when 
> > Apache itself uses 1.1?
> 
> Why?

How do you fix rdeps of Apache that are not compiling or working
stable with 1.1?

We are already inside the stretch freeze.

Many packages are not even compiling with 1.1

And run-time testing with 1.1 has not even begun for most packages.
Did you confirm that the Apache code you reviewed actually works
flawlessly? Runtime bugs like #843988 are possible.

> > That is the most important question here.
> 
> No, I think the question is:
> 
> Can we migrate (or drop) all rdeps to 1.0.2?

The answer is "yes, we can migrate all".

All OpenSSL-using packages in unstable were compiled with and using 
1.0.2 until libssl-dev switched from 1.0.2 to 1.1 just 2 weeks ago.

Even today 80% of all libssl dependencies in unstable are still
against libssl1.0.2 (1.1 binNMUs have not yet been done).

> > This is what my "mod_ssl_openssl.h and the comment in #828330"
> > was referring to.
> > 
> > The dual 1.0.2/1.1 setup for stretch can only work when any set of 
> > packages in the archive that needs the same OpenSSL version stays
> > at 1.0.2 unless *all* packages in this set are compiling and working
> > fine with 1.1
> 
> The *set* you are talking probably cover whole archive, since the
> Build-Depends of PHP are quite vast and here are the Build-Depends
> of Build-Depends:
> 
> (This is from stretch, not from unstable)
> apache2-dev libssl-dev (>= 0.9.8m)
> libc-client2007e-dev libssl-dev
> libcurl4-openssl-dev libssl-dev
> libevent-dev libssl-dev
> libkrb5-dev libssl-dev
> libpq-dev libssl-dev
> libsasl2-dev libssl-dev
> libsnmp-dev libssl-dev (>> 0.9.8)
> 
> Greping just Depends: on -dev packages is slightly more optimistic:
> 
> apache2-dev libssl-dev (<< 1.1)
> libc-client2007e-dev libssl-dev
> libpq-dev libssl-dev
> libsnmp-dev libssl-dev
> 
> But ultimately I am afraid that libssl dependencies are so entagled
> that it will cover all archive.

"all archive" is not correct, but more packages in stretch using
1.0.2 than 1.1 sounds realistic.

> > And since the OpenSSL version used is part of the libcurl3 ABI
> > (see #844018 for details), using 1.1 in stretch is anyway not
> > really an option for Apache/PHP in stretch.
> 
> What you are really saying is that using OpenSSL 1.1 is generally
> not an option for stretch.

It is not a realistic option for larger groups of packages that have to 
use the same OpenSSL version.

It was clear before the OpenSSL default changed that using only 1.1 in 
stretch would not be realistic.

It was known before the OpenSSL default changed that problems like with 
libcurl3 could happen.

Considering that we are already in the freeze, for any OpenSSL 1.1 
related problem without a simple and fast solution the only option
within the stretch release schedule is to move packages back to 1.0.2

> Cheers,

cu
Adrian

-- 

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

Bug#845095: nmu: aspectc++_1:2.1-2

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: affects -1 src:undertaker

nmu aspectc++_1:2.1-2 . ANY . unstable . -m "Recompile static libraries with 
PIE"

Re: What is going on with gtkdatabox?

[Adrian Bunk]

On Thu, Nov 24, 2016 at 08:40:43AM +0100, Andreas Tille wrote:
> Hi again,
> 
> On Thu, Nov 24, 2016 at 02:49:56AM +, peter green wrote:
> > 
> > brp-pacu: has a build-dependency on libgtkdatabox-0.9.2-0-dev |
> > libgtkdatabox-dev . Unfortunately buildds only look at the first option
> 
> I'm now realising that the first option has installable candidates which
> is astonishing since I assumed that with a new source package upload the
> binaries created by the previous version would vanish from the mirrors.
> That's the first case I see this happen.  Did I miss anything? :-(
> 
> In any case ibgtkdatabox-0.9.2-0-dev and
> libgtkdatabox-0.9.2-0_0.9.2.0+dfsg-1_amd64.deb should vanish from the
> mirrors.

"only look at the first option" != "use the first available option"

To prevent exactly this kind of problems, the libgtkdatabox-dev 
alternative in the build dependencies won't be considered by the
buildds for unstable.

> Kind regards
> 
>   Andreas.

cu
Adrian

-- 

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

Bug#846265: nmu: 1.0.5-1_1.0.5-1

[Adrian Bunk]

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

nmu 1.0.5-1_1.0.5-1 . amd64 . unstable . -m "Recompile with boost1.62"

Maintainer-uploaded binaries compiled with boost1.58

Bug#846265: nmu: cassiopee_1.0.5-1

[Adrian Bunk]

Control: retitle -1 nmu: cassiopee_1.0.5-1

On Tue, Nov 29, 2016 at 07:47:36PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu 1.0.5-1_1.0.5-1 . amd64 . unstable . -m "Recompile with boost1.62"
>
> Maintainer-uploaded binaries compiled with boost1.58

Sorry, that should be:

nmu cassiopee_1.0.5-1 . amd64 . unstable . -m "Recompile with boost1.62"


cu
Adrian

-- 

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

Bug#827061: transition: openssl

[Adrian Bunk]

On Wed, Nov 30, 2016 at 07:43:36PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-05 21:59:27 [+0100], Sebastian Andrzej Siewior wrote:
> > I've been playing with ben. I tried a few things and this is the best I
> > was able to achieve [0]:
> > 
> > title = "openssl 1.0";
> > is_affected = .build-depends ~ /libssl1.0-dev/;
> > is_good = .depends ~ /libssl1.0.2/;
> > is_bad = .depends ~ /libssl1.1/;
> > 
> > And
> > 
> > title = "openssl 1.1";
> > is_affected = .build-depends ~ /libssl-dev/;
> > is_good = .depends ~ /libssl1\.1/;
> > is_bad = .depends ~ /libssl1\.0\.2/;
> 
> This does not cover packages which link against 1.0.2 but do not depend
> on libssl-dev (but inherit their dependencies).
> So it is up to you what you setup but something should be done because
> the auto tracker is gone.

Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
give a reasonably small superset of all packages that need a binNMU?

> Sebastian

cu
Adrian

-- 

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

Bug#827061: transition: openssl

[Adrian Bunk]

On Thu, Dec 01, 2016 at 09:15:44PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-12-01 00:52:59 [+0200], Adrian Bunk wrote:
> > Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
> > give a reasonably small superset of all packages that need a binNMU?
> 
> Do you mean something like
>  is_affected = .depends ~ /libssl1\.0\.2/ & ! .build-depends ~ 
> /libssl1.0-dev/;
> 
> which results in [0] ? This gives you all packages with a B-D libssl-dev
> and D libssl1.0.2 like [1] but also lists package which do not depend on
> libssl-dev.
>...

Yes, that's what I had in mind.

Note that this is a superset of all packages requiring binNMUs,
and it is not expected to become all-green in stretch.

> Sebastian

cu
Adrian

-- 

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

Bug#842177: Bug#847974: xmds2: FTBFS in stretch

[Adrian Bunk]

On Mon, Dec 12, 2016 at 05:42:37PM +, Santiago Vila wrote:
> Package: src:xmds2
> Version: 2.2.2+dfsg-2
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>...
> warning: the size of octave_hdf5_id is smaller than the size of HDF5 hid_t
> warning: called from
> lorenz.m at line 2 column 3
> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>   #000: ../../../src/H5G.c line 464 in H5Gopen2(): not a location
> major: Invalid arguments to routine
> minor: Inappropriate type
>   #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
> major: Invalid arguments to routine
> minor: Bad value
> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>   #000: ../../../src/H5Gdeprec.c line 796 in H5Gget_num_objs(): not a 
> location ID
> major: Invalid arguments to routine
> minor: Inappropriate type
>   #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
> major: Invalid arguments to routine
> minor: Bad value
> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>   #000: ../../../src/H5G.c line 725 in H5Gclose(): not a group
> major: Invalid arguments to routine
> minor: Inappropriate type
>...
> The build history I keep is like this:
> 
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161118T125207Z
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161123T025916Z
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161128T001945Z
> Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161202T231309Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161207T065906Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214652Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214639Z
> Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214702Z
> 
> Something happened in stretch between 2016-12-02 and 2016-12-07
> that made this package to FTBFS.

What happened was the hdf5 transition.

Gilles, you seem to have somehow missed xmds2 in your transition 
planning?

> Please tell me if you need a full build log, and I will attach it.
> 
> (Using sbuild on a single CPU virtual machine, it always fails for me,
> on different machines, so it should be easy to reproduce).
> 
> Thanks.

cu
Adrian

-- 

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

Bug#851436: nmu: llvm-defaults_1:3.8-34

[Adrian Bunk]

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

nmu llvm-defaults_1:3.8-34 . armel . unstable . -m "llvm-toolchain-3.8 is now 
available on armel"

Bug#851482: nmu: ocrad_0.25-1

[Adrian Bunk]

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

nmu ocrad_0.25-1 . ANY . unstable . -m "Static library rebuild with PIE"


This should fix
  https://ci.debian.net/packages/o/ocrad/unstable/amd64/

Re: Bug#851466: khmer: autopkgtest is failing

[Adrian Bunk]

Control: reassign -1 release.debian.org
Control: retitle -1 nmu: bzip2_1.0.6-8

On Sun, Jan 15, 2017 at 10:29:25AM +0100, Andreas Tille wrote:
> Package: khmer
> Severity: normal
> 
> Hi,
> 
> the autopkgtest of khmer is failing[1] with
> 
> ...
> + c++ -o test-prog-static -std=c++11 
> /usr/share/doc/khmer-common/test-compile.cc 
> /usr/lib/x86_64-linux-gnu/liboxli.a /usr/lib/x86_64-linux-gnu/libz.a 
> /usr/lib/x86_64-linux-gnu/libbz2.a
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libbz2.a(bzlib.o): relocation 
> R_X86_64_32S against symbol `BZ2_crc32Table' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libbz2.a(compress.o): relocation 
> R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared 
> object; recompile with -fPIC
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libbz2.a(decompress.o): relocation 
> R_X86_64_32S against `.rodata' can not be used when making a shared object; 
> recompile with -fPIC
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libbz2.a(blocksort.o): relocation 
> R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared 
> object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> ...
> 
> The solution probably would be to fix the makefile to include -fPIC.

What is required is a binNMU of bzip2 with PIE:

  nmu bzip2_1.0.6-8 . ANY . -m "Rebuild static library with PIE"

> Kind regards
> 
>Andreas.
> 
> [1] 
> https://ci.debian.net/data/packages/unstable/amd64/k/khmer/20170112_131441.autopkgtest.log.gz

cu
Adrian

-- 

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

Bug#851871: RM: remove gcc-5 from stretch

[Adrian Bunk]

On Thu, Jan 19, 2017 at 03:07:03PM +0100, Matthias Klose wrote:
> Package: release.debian.org
> Tags: stretch
> 
> Please remove gcc-5, gcc-5-cross and gcc-5-cross-ports from testing.  Now that
> the linux source is built using gcc-6, the list of packages also needing 
> removal
> are acoording to [1]:
> 
>  - nvida-cuda-toolkit
>  - starpu-contrib
>...

Their fix might actually be blocked by outdated information in #835940.

Quoting the relevant part from #835940:

On Mon, Nov 28, 2016 at 11:23:27AM +0100, Matthias Klose wrote:
> On 28.11.2016 02:08, lumin wrote:
> > Hello guys,
> >
> > I successfully compiled caffe with CUDA_8.0.44-2 and
> > clang-3.8 (the current default clang). Maybe we can
> > replace GCC-5 with Clang-3.8 to solve this problem.
> >
> > That means Stretch still has chance to ship CUDA8,
> > and users are expected to compile with Clang/LLVM
> > instead of GCC-6, as long as the CUDA rDepends
> > compile with clang.
> >
> > I only tested caffe-contrib.
>
> My guess is that clang-3.8 will be gone for the release as well ...


What is the final decision regarding LLVM versions in stretch?


> Matthias

cu
Adrian

-- 

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

Bug#851995: nmu: db5.3_5.3.28-12

[Adrian Bunk]

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

After the #851391 fix this will give libdb5.3-java-* also on mips64el.

nmu db5.3_5.3.28-12 . mips64el . unstable . -m "Rebuild with libgcj-common 
1:6.3-1 to get libdb5.3-java-*"
dw db5.3_5.3.28-12 . mips64el . -m "libgcj-common (>= 1:6.3-1)"

Bug#851995: nmu: db5.3_5.3.28-12

[Adrian Bunk]

On Sun, Jan 22, 2017 at 05:35:28PM +0100, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Fri, Jan 20, 2017 at 18:32:08 +0200, Adrian Bunk wrote:
> 
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > After the #851391 fix this will give libdb5.3-java-* also on mips64el.
> > 
> > nmu db5.3_5.3.28-12 . mips64el . unstable . -m "Rebuild with libgcj-common 
> > 1:6.3-1 to get libdb5.3-java-*"
> > dw db5.3_5.3.28-12 . mips64el . -m "libgcj-common (>= 1:6.3-1)"
> > 
> binNMUs on a single arch for m-a:same packages are painful until dpkg
> gets fixed.  It might be better to do a no-change source upload here.

Why is a source upload required?

Could you just make the binNMU on ANY:

nmu db5.3_5.3.28-12 . ANY . unstable . -m "Rebuild with libgcj-common 1:6.3-1 
to get libdb5.3-java-* on mips64el"

> Cheers,
> Julien

cu
Adrian

-- 

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

Bug#852693: nmu: llvm-defaults_0.34

[Adrian Bunk]

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

I messed up the version number in #851436, assume that's the
reason why no binNMU happened after it was scheduled.

nmu llvm-defaults_0.34 . armel . unstable . -m "llvm-toolchain-3.8 is now 
available on armel"

Bug#852693: nmu: llvm-defaults_0.34

[Adrian Bunk]

On Thu, Jan 26, 2017 at 03:46:21PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> I messed up the version number in #851436, assume that's the
> reason why no binNMU happened after it was scheduled.
> 
> nmu llvm-defaults_0.34 . armel . unstable . -m "llvm-toolchain-3.8 is now 
> available on armel"

Looking at control and the m-a:same comment in #851995,
this should be:

nmu llvm-defaults_0.34 . ANY . unstable . -m "llvm-toolchain-3.8 is now 
available on armel"

cu
Adrian

-- 

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

Bug#852703: nmu: non-empty -gcj packages on mips64el

[Adrian Bunk]

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

With #851391 fixed, these packages should get the intended contents
also on mips64el.

nmu libxml-commons-resolver1.1-java_1.2-7 . mips64el . unstable . -m "Rebuild 
with libgcj-common 1:6.3-1 to get non-empty libxml-commons-resolver1.1-java-gcj"
nmu libxerces2-java_2.11.0-7 . mips64el . unstable . -m "Rebuild with 
libgcj-common 1:6.3-1 to get non-empty libxerces2-java-gcj"
nmu swt-gtk_3.8.2-3 . mips64el . unstable . -m "Rebuild with libgcj-common 
1:6.3-1 to get non-empty libswt-gtk-3-java-gcj"
nmu libsaxon-java_1:6.5.5-10 . mips64el . unstable . -m "Rebuild with 
libgcj-common 1:6.3-1 to get non-empty libsaxon-java-gcj"
nmu libjaxp1.3-java_1.3.05-2 . mips64el . unstable . -m "Rebuild with 
libgcj-common 1:6.3-1 to get non-empty libjaxp1.3-java-gcj"
nmu docbook-xsl-saxon_1.00.dfsg.1-6 . mips64el . unstable . -m "Rebuild with 
libgcj-common 1:6.3-1 to get non-empty docbook-xsl-saxon-gcj"

Bug#852859: unblock: mknbi/1.4.4-13

[Adrian Bunk]

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

Please unblock package mknbi (FTBFS fix).

unblock mknbi/1.4.4-13


diff -Nru mknbi-1.4.4/debian/changelog mknbi-1.4.4/debian/changelog
--- mknbi-1.4.4/debian/changelog2016-08-03 15:40:44.0 +0300
+++ mknbi-1.4.4/debian/changelog2017-01-28 00:23:07.0 +0200
@@ -1,3 +1,10 @@
+mknbi (1.4.4-13) unstable; urgency=medium
+
+  * QA upload.
+  * Add patch from Steve Beattie to fix PIE FTBFS. (Closes: #852851)
+
+ -- Adrian Bunk   Sat, 28 Jan 2017 00:23:07 +0200
+
 mknbi (1.4.4-12) unstable; urgency=medium
 
   * QA upload.
diff -Nru mknbi-1.4.4/debian/patches/07-disable-pie.patch 
mknbi-1.4.4/debian/patches/07-disable-pie.patch
--- mknbi-1.4.4/debian/patches/07-disable-pie.patch 1970-01-01 
02:00:00.0 +0200
+++ mknbi-1.4.4/debian/patches/07-disable-pie.patch 2017-01-28 
00:22:04.0 +0200
@@ -0,0 +1,18 @@
+Author: Steve Beattie 
+Subject: disable position independent executables by default
+---
+ Makefile |1 +
+ 1 file changed, 1 insertion(+)
+
+Index: b/Makefile
+===
+--- a/Makefile
 b/Makefile
+@@ -20,6 +20,7 @@ OLDGAS:= $(shell $(AS) --version | grep
+ CFLAGS=   -I. -Os -ffreestanding -fstrength-reduce 
-fomit-frame-pointer \
+   -fgnu89-inline \
+   -fno-stack-protector \
++  -no-pie -fno-PIE \
+   -m32 -mcpu=i386 \
+   -Wall -W -Wno-format -Wno-unused 
-DVERSION=\"$(VERSION)$(EXTRAVERSION)\"
+ LDBINARYFLAG= --oformat binary -m elf_i386
diff -Nru mknbi-1.4.4/debian/patches/series mknbi-1.4.4/debian/patches/series
--- mknbi-1.4.4/debian/patches/series   2016-08-03 15:40:44.0 +0300
+++ mknbi-1.4.4/debian/patches/series   2017-01-28 00:23:02.0 +0200
@@ -4,3 +4,4 @@
 04-no-stack-protector.patch
 05-gcc-5.patch
 06-reproducible-builds.patch
+07-disable-pie.patch

Bug#852945: RM: packages that migrated by mistake, batch 1

[Adrian Bunk]

On Sat, Jan 28, 2017 at 01:11:39PM +, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Quite a lot of packages accidentally migrated to testing on 2016-12-29
> despite open RC bugs. Here is a first batch. Unless I missed something,
> they all have popcon < 100 and no maintainer response for a while.
>...

What is the point in asking for manual removal of packages that are 
mostly already scheduled for autoremoval 11 hours from now?

> Regards,
> S
>...

cu
Adrian

-- 

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

Re: Draft for taging 32 RC bugs with can-defer, will-remove or is-blocker

[Adrian Bunk]

On Sat, Jan 28, 2017 at 01:20:00PM +, Niels Thykier wrote:
> Hi,
> 
> I have a quick review of the RC bugs in *key* packages that are unfixed
> in unstable according to UDD.  The following is a list of 32 of these
> (out of about 180) with proposed verdicts/tagging to start a debate
> about them.
> 
> 
> There are 3 verdicts:
> 
>  * can-defer (serious bug, but not a blocker - could be fixed in via pu
>   or a security upload)
>- This implies a "stretch-ignore".

These are mostly CVE fixes, sometimes "no-dsa" in jessie.

Deferring something now and doing a DSA later sounds wrong to me,
IMHO a "stretch-ignore" would imply that the security team is OK
with having that unfixed during the lifetime of stretch.

>...
> > 814978  gcc-5   will-remove gcc-5: gnat paths are 
> > wrong due to ada-gcc-name.diff
> > 848220  gcc-5   will-remove gcc-5 should not ship 
> > in stretch

firefox-esr uses gcc-5 on arm* (#852009), the changelog says:

  * debian/control*, debian/rules: Compile with GCC 5 on testing/unstable
on arm* because of crashes when building with GCC 6. (FTBFS)

This is the hard part of the gcc-5 removal that was already requested
in #851871.

> > 835960  gcc-5-cross will-remove gcc-5-cross: 
> > non-standard gcc/g++ used for build (gcc-5)
> > 835777  gcc-5-cross will-remove gcc-5-cross: FTBFS: 
> > patch fails to apply
> > 835692  gcc-5-cross-ports   will-remove gcc-5-cross-ports: 
> > FTBFS: patches fail to apply
> > 835961  gcc-5-cross-ports   will-remove gcc-5-cross-ports: 
> > non-standard gcc/g++ used for build (gcc-5)

Removal was already requested as part of #851871.

>...
> Thanks,
> ~Niels
>...

cu
Adrian

-- 

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

Re: Draft for taging 32 RC bugs with can-defer, will-remove or is-blocker

[Adrian Bunk]

On Sat, Jan 28, 2017 at 07:20:00PM +, Niels Thykier wrote:
> Moritz Mühlenhoff:
> > Niels Thykier  schrieb:
> >>> 852603virglrenderer   can-defer   virglrenderer: 
> >>> CVE-2016-10163
> >>> 852604virglrenderer   can-defer   virglrenderer: 
> >>> CVE-2017-5580
> > 
> > This hasn't been in a stable release yet and it already orphaned. If noone
> > picks it up or fixes it, let's rather remove it.
> > 
> > Cheers,
> > Moritz
> 
> That indeed seems like a better solution given the context; I am putting
> those down as "will-remove".

Sounds like good solution considering:

- reason: qemu build-depends libvirglrenderer-dev
  source: virglrenderer

qemu (1:2.8+dfsg-2) unstable; urgency=medium
...
  * Revert "enable virtio gpu (virglrenderer) and opengl support"
Revert "switch from sdl1 to gtk3"
Revert other gtk2/drm/vte/virgl-related changes
Reopens: #813658, #839695
The change were too close to stretch release and too large,
bringing too much graphics stuff for headless servers,
will re-think this for stretch+1.
sdl1 back: Closes: #851509
virtio-3d bugs: Closes: #849798, #852119
...
 -- Michael Tokarev   Mon, 23 Jan 2017 14:06:54 +0300

qemu was the only rdep of virglrenderer.

> Thanks,
> ~Niels

cu
Adrian

-- 

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

Re: Bug#853189: tracker.debian.org: Ecnoding issue / Code injection through Maintainer field (and probably others)

[Adrian Bunk]

On Mon, Jan 30, 2017 at 04:48:55PM +0100, Mattia Rizzolo wrote:
> On Mon, Jan 30, 2017 at 03:43:44PM +0100, Dominik George wrote:
> > tracker.debian.org apparently has encoding issues, not of the “schei�
> > encoding” kind, but it even seems to break the HTML completely and even
> > introduces new elements into the DOM in some way…
> > 
> > أحمد المحمودي (Ahmed El-Mahmoudy), e.g., in the Maintainer field of
> > python-whoosh [1] triggers the issue in the “testing migrations” pane
> > (but not in the Maintainer field itself…).
> 
> That's coming from the excuses.yaml coming from
> https://release.debian.org/britney/excuses.yaml (debian-released CCed):
>...

Niels correctly stated in IRC that the tracker is actually using
update_excuses.html

My guess regarding the cause would be that the tracker fails to properly
parse bi-directional text in update_excuses (Arabic is right-to-left).

cu
Adrian

-- 

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

Bug#827061: transition: openssl

[Adrian Bunk]

On Thu, Feb 02, 2017 at 09:09:56PM +0100, Sebastian Andrzej Siewior wrote:
>...
> > You can go to http://reproducible.debian.net/$srcpkgname and see for 
> > yourself
> > whether they build fine in our environment. If they do, you can rule out
> > "parallel" as causing this…
> 
> I see. I looked at kannel. The -j1 version:
>...
> That "flow object not accepted by port" seems not to be the issue but
> the fact, that wtls.tmp is reused and probably removed too early.

The kannel package does not claim to support parallel building.

If you attempt parallel building on that,
then any build failures are your fault.

> Sebastian

cu
Adrian

-- 

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

Please allow arden 1.0-3 to migrate to testing

[Adrian Bunk]

Hi,

arden was recently changed from binary-any to binary-all (#852313),
but testing migration is blocked by:
  arden/i386 unsatisfiable Depends: python-htseq

The root cause is #819617, which might not get fixed in time for stretch.

Please allow arden into testing despite not being installable on i386.

Thanks
Adrian

-- 

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

Bug#854198: Packages that are now part of request-tracker4 must be removed from testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

#852258 rt-authen-externalauth: FTBFS: Your installed version of RT (4.4.1-2) 
is too new
#851987 rt-extension-spawnlinkedticketinqueue: Obsolete with RT 4.4
#851986 rt-extension-sla: Obsolete with RT 4.4

These are now part of request-tracker4 and request-tracker4
has proper Conflicts, so they must be removed to allow
testing migration of request-tracker4.

Bug#860401: unblock: mecab/0.996-3.1

[Adrian Bunk]

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

Please unblock package mecab

unblock mecab/0.996-3.1

diff -Nru mecab-0.996/debian/changelog mecab-0.996/debian/changelog
--- mecab-0.996/debian/changelog2016-10-09 20:52:05.0 +0300
+++ mecab-0.996/debian/changelog2017-04-10 21:55:12.0 +0300
@@ -1,3 +1,11 @@
+mecab (0.996-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't disable PIE, to make static libraries usable with
+gcc defaulting to PIE. (Closes: #859425)
+
+ -- Adrian Bunk   Mon, 10 Apr 2017 21:55:12 +0300
+
 mecab (0.996-3) unstable; urgency=medium
 
   * use debhelper 10 
diff -Nru mecab-0.996/debian/rules mecab-0.996/debian/rules
--- mecab-0.996/debian/rules2016-10-09 20:52:05.0 +0300
+++ mecab-0.996/debian/rules2017-04-10 21:55:12.0 +0300
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 # -*- Makefile -*-
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:

Bug#860402: unblock: libiscsi/1.17.0-1.1

[Adrian Bunk]

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

Please unblock package libiscsi

unblock libiscsi/1.17.0-1.1

diff -Nru libiscsi-1.17.0/debian/changelog libiscsi-1.17.0/debian/changelog
--- libiscsi-1.17.0/debian/changelog2016-05-24 12:20:05.0 +0300
+++ libiscsi-1.17.0/debian/changelog2017-04-10 22:05:20.0 +0300
@@ -1,3 +1,11 @@
+libiscsi (1.17.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't disable PIE, to make static libraries usable with
+gcc defaulting to PIE. (Closes: #859414)
+
+ -- Adrian Bunk   Mon, 10 Apr 2017 22:05:20 +0300
+
 libiscsi (1.17.0-1) unstable; urgency=medium
 
   * new upstream release (Closes: #822870)
diff -Nru libiscsi-1.17.0/debian/rules libiscsi-1.17.0/debian/rules
--- libiscsi-1.17.0/debian/rules2016-05-24 12:15:36.0 +0300
+++ libiscsi-1.17.0/debian/rules2017-04-10 22:05:14.0 +0300
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
+export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 %:
dh $@ --with autoreconf

Bug#860820: unblock: tau/2.17.3.1.dfsg-4.2

[Adrian Bunk]

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

Please unblock package tau

unblock tau/2.17.3.1.dfsg-4.2

diff -Nru tau-2.17.3.1.dfsg/debian/changelog tau-2.17.3.1.dfsg/debian/changelog
--- tau-2.17.3.1.dfsg/debian/changelog  2017-01-14 00:08:41.0 +0200
+++ tau-2.17.3.1.dfsg/debian/changelog  2017-04-20 17:48:20.0 +0300
@@ -1,3 +1,12 @@
+tau (2.17.3.1.dfsg-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove incorrect /usr/share/doc/tau-examples/examples/python
+symlink from tau-examples, thanks to Andreas Beckmann for
+reporting. (Closes: #858475)
+
+ -- Adrian Bunk   Thu, 20 Apr 2017 17:48:20 +0300
+
 tau (2.17.3.1.dfsg-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tau-2.17.3.1.dfsg/debian/rules tau-2.17.3.1.dfsg/debian/rules
--- tau-2.17.3.1.dfsg/debian/rules  2017-01-14 00:08:35.0 +0200
+++ tau-2.17.3.1.dfsg/debian/rules  2017-04-20 17:48:20.0 +0300
@@ -226,9 +226,8 @@
mkdir -p debian/tau-examples/usr/share/doc/tau
ln -s ../tau-examples/examples debian/tau-examples/usr/share/doc/tau/
 
- # symlink python examples already living in python-tau
+ # remove python examples already living in python-tau
rm -rf debian/tau-examples/usr/share/doc/*/examples/python
-   ln -s ../python-tau/examples 
debian/tau-examples/usr/share/doc/tau-examples/examples/python
 
  # Adjust TAUROOTDIR for installed version
perl -pi -e 's!^TAUROOTDIR\t.*!TAUROOTDIR = /usr/lib/tau!' \

Bug#860856: RM: live-f1/0.2.10-1.1

[Adrian Bunk]

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

#858109 live-f1 isn't working anymore due to changes on the data-providing side

Already removed from stretch, should also be removed from jessie.

Bug#861332: RM: linux-grsec-base/6

[Adrian Bunk]

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

Similar to linux-grsec, linux-grsec-base should not be part
of stretch.

This removal request has been blessed by Yves-Alexis Perez.

Bug#861391: jessie-pu: package apf-firewall/9.7+rev1-3+deb8u1

[Adrian Bunk]

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

diffstat for apf-firewall_9.7+rev1-3 apf-firewall_9.7+rev1-3+deb8u1

 apf-firewall-9.7+rev1/debian/changelog  |9 +
 apf-firewall-9.7+rev1/debian/control|4 +---
 apf-firewall-9.7+rev1/debian/patches/series |1 +
 debian/patches/support-kernel-3-and-later.patch |   18 ++
 4 files changed, 29 insertions(+), 3 deletions(-)

diff -u apf-firewall-9.7+rev1/debian/changelog 
apf-firewall-9.7+rev1/debian/changelog
--- apf-firewall-9.7+rev1/debian/changelog
+++ apf-firewall-9.7+rev1/debian/changelog
@@ -1,3 +1,12 @@
+apf-firewall (9.7+rev1-3+deb8u1) jessie; urgency=medium
+
+  * QA upload.
+  * Set maintainer field to Debian QA Group.
+  * Add patch from Christoph Biedl to make it work with
+kernel 3.x and newer. (Closes: #701674)
+
+ -- Adrian Bunk   Fri, 28 Apr 2017 14:01:55 +0300
+
 apf-firewall (9.7+rev1-3) unstable; urgency=low
 
   * [7e08452] Added iproute in Depends (Closes: #631594)
diff -u apf-firewall-9.7+rev1/debian/control 
apf-firewall-9.7+rev1/debian/control
--- apf-firewall-9.7+rev1/debian/control
+++ apf-firewall-9.7+rev1/debian/control
@@ -1,12 +1,10 @@
 Source: apf-firewall
 Section: net
 Priority: optional
-Maintainer: Giuseppe Iuculano 
+Maintainer: Debian QA Group 
 Build-Depends: quilt (>= 0.40), debhelper (>= 7)
 Standards-Version: 3.9.2
 Homepage: http://www.rfxn.com/projects/advanced-policy-firewall/
-Vcs-Git: git://git.debian.org/git/users/derevko-guest/apf-firewall.git
-Vcs-Browser: http://git.debian.org/?p=users/derevko-guest/apf-firewall.git
 
 Package: apf-firewall
 Architecture: all
diff -u apf-firewall-9.7+rev1/debian/patches/series 
apf-firewall-9.7+rev1/debian/patches/series
--- apf-firewall-9.7+rev1/debian/patches/series
+++ apf-firewall-9.7+rev1/debian/patches/series
@@ -4,0 +5 @@
+support-kernel-3-and-later.patch
only in patch2:
unchanged:
--- apf-firewall-9.7+rev1.orig/debian/patches/support-kernel-3-and-later.patch
+++ apf-firewall-9.7+rev1/debian/patches/support-kernel-3-and-later.patch
@@ -0,0 +1,18 @@
+Subject: Make work with kernel 3.x and newer
+Author: Christoph Biedl 
+Bug-Debian: https://bugs.debian.org/701674
+
+--- a/files/internals/functions.apf
 b/files/internals/functions.apf
+@@ -65,9 +65,10 @@
+ ml() {
+ MOD=$1
+ VALMOD=$2
++KREL_MAJOR="${KREL%%.*}"
+ if [ "$KREL" == "2.4" ]; then
+   MEXT="o"
+-elif [ "$KREL" == "2.6" ]; then
++elif [ "$KREL" == "2.6" ] || [ "$KREL_MAJOR" -ge 3 ]; then
+   MEXT="ko"
+ elif [ ! "$KREL" == "2.4" ] && [ ! "$KREL" == "2.6" ]; then
+   if [ ! "$SET_VERBOSE" == "1" ]; then

Bug#861392: jessie-pu: package libindicate/0.6.92-2+deb8u1

[Adrian Bunk]

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

diffstat for libindicate_0.6.92-2 libindicate_0.6.92-2+deb8u1

 changelog |   10 ++
 control   |5 ++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff -u libindicate-0.6.92/debian/changelog libindicate-0.6.92/debian/changelog
--- libindicate-0.6.92/debian/changelog
+++ libindicate-0.6.92/debian/changelog
@@ -1,3 +1,13 @@
+libindicate (0.6.92-2+deb8u1) jessie; urgency=medium
+
+  * QA upload.
+  * Set maintainer to the QA group.
+  * libindicate-gtk3-dev: Depend on libindicate-gtk3-3 instead of
+libindicate-gtk3, thanks to Andreas Beckmann for finding this
+bug. (Closes: #715066)
+
+ -- Adrian Bunk   Fri, 28 Apr 2017 14:23:07 +0300
+
 libindicate (0.6.92-2) unstable; urgency=low
 
   * Team upload.
diff -u libindicate-0.6.92/debian/control libindicate-0.6.92/debian/control
--- libindicate-0.6.92/debian/control
+++ libindicate-0.6.92/debian/control
@@ -2,8 +2,7 @@
 Section: libs
 Priority: optional
 XS-Python-Version: >= 2.6
-Maintainer: The Ayatana Packagers 
-Uploaders: Evgeni Golov 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 5.0),
cdbs (>= 0.4.41),
libgtk2.0-dev (>= 2.24.4-1~),
@@ -94,7 +93,7 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- libindicate-gtk3 (= ${binary:Version}),
+ libindicate-gtk3-3 (= ${binary:Version}),
  libindicate-dev (= ${binary:Version}),
  libdbus-glib-1-dev (>= 0.76),
  libgtk-3-dev (>= 3.0)

Bug#861395: jessie-pu: package libvorbisidec/1.0.2+svn18153-1~deb8u1

[Adrian Bunk]

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

diffstat for libvorbisidec_1.0.2+svn18153-0.2 
libvorbisidec_1.0.2+svn18153-1~deb8u1

 changelog |   16 
 control   |4 ++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff -u libvorbisidec-1.0.2+svn18153/debian/control 
libvorbisidec-1.0.2+svn18153/debian/control
--- libvorbisidec-1.0.2+svn18153/debian/control
+++ libvorbisidec-1.0.2+svn18153/debian/control
@@ -1,6 +1,6 @@
 Source: libvorbisidec
 Priority: extra
-Maintainer: Daniel Kahn Gillmor 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 7.0.50), autotools-dev, devscripts, automake, 
libtool, libogg-dev, pkg-config
 Standards-Version: 3.8.3
 Section: libs
@@ -10,7 +10,7 @@
 Package: libvorbisidec-dev
 Section: libdevel
 Architecture: any
-Depends: libvorbisidec1 (= ${binary:Version}), ${misc:Depends}
+Depends: libvorbisidec1 (= ${binary:Version}), ${misc:Depends}, libogg-dev
 Description: Integer-only Ogg Vorbis decoder, AKA "tremor" (Development Files)
  libvorbisidec is an Ogg Vorbis audio decoder (also known as
  "tremor"), implemented with no floating point arithmetic.  This makes
diff -u libvorbisidec-1.0.2+svn18153/debian/changelog 
libvorbisidec-1.0.2+svn18153/debian/changelog
--- libvorbisidec-1.0.2+svn18153/debian/changelog
+++ libvorbisidec-1.0.2+svn18153/debian/changelog
@@ -1,3 +1,19 @@
+libvorbisidec (1.0.2+svn18153-1~deb8u1) jessie; urgency=medium
+
+  * QA upload.
+  * Rebuild for jessie.
+
+ -- Adrian Bunk   Fri, 28 Apr 2017 14:42:20 +0300
+
+libvorbisidec (1.0.2+svn18153-1) unstable; urgency=medium
+
+  * QA upload.
+  * Set maintainer to Debian QA Group. (see #698378)
+  * Add libogg-dev dependency to libvorbisidec-dev.
+(Closes: #739864)
+
+ -- Adrian Bunk   Mon, 23 Jan 2017 22:57:11 +0200
+
 libvorbisidec (1.0.2+svn18153-0.2) unstable; urgency=low
 
   * Non-maintainer upload.

Bug#861397: jessie-pu: package xshisen/1:1.51-4.1+deb8u1

[Adrian Bunk]

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

diffstat for xshisen-1.51 xshisen-1.51

 changelog  |9 +
 control|6 +++---
 patches/fix_segfault.patch |   33 +
 patches/series |1 +
 4 files changed, 46 insertions(+), 3 deletions(-)

diff -Nru xshisen-1.51/debian/changelog xshisen-1.51/debian/changelog
--- xshisen-1.51/debian/changelog   2013-10-27 21:46:53.0 +0200
+++ xshisen-1.51/debian/changelog   2017-04-28 14:57:38.0 +0300
@@ -1,3 +1,12 @@
+xshisen (1:1.51-4.1+deb8u1) jessie; urgency=medium
+
+  * QA upload.
+  * Set maintainer to the QA team.
+  * Fix frequent segfault on start, thanks Alexey Shilin.
+(Closes: #765504)
+
+ -- Adrian Bunk   Fri, 28 Apr 2017 14:54:37 +0300
+
 xshisen (1:1.51-4.1) unstable; urgency=low
 
   [ Paul Gevers ]
diff -Nru xshisen-1.51/debian/control xshisen-1.51/debian/control
--- xshisen-1.51/debian/control 2013-10-27 20:30:37.0 +0200
+++ xshisen-1.51/debian/control 2017-04-28 14:53:34.0 +0300
@@ -1,12 +1,12 @@
 Source: xshisen
 Section: games
 Priority: optional
-Maintainer: Zak B. Elep 
+Maintainer: Debian QA Group 
 Build-Depends: autotools-dev, debhelper (>= 9), libmotif-dev, libx11-dev, 
libxmu-dev, libxpm-dev, libxt-dev, libxaw7-dev, xutils-dev
 Standards-Version: 3.9.3
 Homepage: http://www.techfirm.co.jp/~masaoki/xshisen.html
-Vcs-Browser: https://github.com/zakame/debian-pkg-xshisen
-Vcs-Git: git://github.com/zakame/debian-pkg-xshisen.git
+#Vcs-Browser: https://github.com/zakame/debian-pkg-xshisen
+#Vcs-Git: git://github.com/zakame/debian-pkg-xshisen.git
 
 Package: xshisen
 Architecture: any
diff -Nru xshisen-1.51/debian/patches/fix_segfault.patch 
xshisen-1.51/debian/patches/fix_segfault.patch
--- xshisen-1.51/debian/patches/fix_segfault.patch  1970-01-01 
02:00:00.0 +0200
+++ xshisen-1.51/debian/patches/fix_segfault.patch  2017-04-28 
14:53:34.0 +0300
@@ -0,0 +1,33 @@
+--- xshisen-1.51.orig/body.C
 xshisen-1.51/body.C
+@@ -53,6 +53,7 @@ Body::Body(int g, int x, int y, Widget p
+ piepos[i] = new PiePos(num_each);
+ }
+ clearqueue = 0;
++hintArray  = NULL;
+ hintNum= 0;
+ pause  = 0;
+ if (game >= NUM_GAME*2)
+@@ -227,8 +228,6 @@ Body::refreshhint(void)
+ p = new Point[max_c][2];
+ t = new Point[xsize*ysize/PKIND];
+ 
+-if (hintNum == 0)
+-delete[] hintArray;
+ for(int i=0; iGetPosArray(t, num);
+ for(int j=0; j

Bug#861399: RM: grive/0.2.0-1.1

[Adrian Bunk]

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

#783169 grive: please remove grive from archive - no longer works after Google 
API changes of 2015-04-20

For this reason, the package has already been removed from
unstable in #811333.

Bug#861968: unblock: rdiff-backup-fs/1.0.0-5

[Adrian Bunk]

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

Please unblock package rdiff-backup-fs

diffstat for rdiff-backup-fs-1.0.0 rdiff-backup-fs-1.0.0

 changelog   |   11 
 control |2 
 patches/0001-Build-with-debug-information-to-make-dbgsym-package-.patch |   31 
++
 patches/0001-Rename-variable-mount-to-mount_dir-to-avoid-calling-.patch |  117 
++
 patches/series  |2 
 5 files changed, 162 insertions(+), 1 deletion(-)

diff -Nru rdiff-backup-fs-1.0.0/debian/changelog 
rdiff-backup-fs-1.0.0/debian/changelog
--- rdiff-backup-fs-1.0.0/debian/changelog  2011-08-18 13:09:55.0 
+0300
+++ rdiff-backup-fs-1.0.0/debian/changelog  2017-05-04 15:38:39.0 
+0300
@@ -1,3 +1,14 @@
+rdiff-backup-fs (1.0.0-5) unstable; urgency=medium
+
+  * QA upload.
+  * Set maintainer to Debian QA Group. (see #831722)
+  * Apply patches from Bernhard Übelacker:
+- Fix segmentation fault caused by variable named "mount".
+  (Closes: #858316)
+- Build with debug information to make dbgsym package useful.
+
+ -- Adrian Bunk   Thu, 04 May 2017 15:38:39 +0300
+
 rdiff-backup-fs (1.0.0-4) unstable; urgency=low
 
   * Applied changes to avoid FTBFS with ld --as-needed (Closes: #632476)
diff -Nru rdiff-backup-fs-1.0.0/debian/control 
rdiff-backup-fs-1.0.0/debian/control
--- rdiff-backup-fs-1.0.0/debian/control2011-08-18 13:07:42.0 
+0300
+++ rdiff-backup-fs-1.0.0/debian/control2017-05-04 15:38:39.0 
+0300
@@ -1,7 +1,7 @@
 Source: rdiff-backup-fs
 Section: utils
 Priority: extra
-Maintainer: Sergio Talens-Oliag 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 7.0.50~), autotools-dev, libz-dev, libfuse-dev, 
pkg-config, dh-autoreconf
 Standards-Version: 3.9.2
 Homepage: http://code.google.com/p/rdiff-backup-fs/
diff -Nru 
rdiff-backup-fs-1.0.0/debian/patches/0001-Build-with-debug-information-to-make-dbgsym-package-.patch
 
rdiff-backup-fs-1.0.0/debian/patches/0001-Build-with-debug-information-to-make-dbgsym-package-.patch
--- 
rdiff-backup-fs-1.0.0/debian/patches/0001-Build-with-debug-information-to-make-dbgsym-package-.patch
1970-01-01 02:00:00.0 +0200
+++ 
rdiff-backup-fs-1.0.0/debian/patches/0001-Build-with-debug-information-to-make-dbgsym-package-.patch
2017-05-04 15:38:39.0 +0300
@@ -0,0 +1,31 @@
+From e075d46fe35845f175e15f36af564b632d03dafa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
+Date: Wed, 19 Apr 2017 17:26:46 +0200
+Subject: Build with debug information to make dbgsym package useful.
+
+---
+ configure.ac | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 9afba35..7f7482a 100644
+--- a/configure.ac
 b/configure.ac
+@@ -46,11 +46,11 @@ AC_TYPE_SIZE_T
+ dnl checking type of system to provide proper compile and linking flags
+ 
+ case ${host} in
+-*-*-linux-*|*-*-k*bsd*-*) AC_SUBST(CFLAGS, ["-Wall -O3 `pkg-config 
--cflags fuse`"])
++*-*-linux-*|*-*-k*bsd*-*) AC_SUBST(CFLAGS, ["-Wall -g -O3 `pkg-config 
--cflags fuse`"])
+   AC_SUBST(LIBS, ["$LIBS `pkg-config --cflags --libs 
fuse` -lz"]);;
+-*-*-bsd-*)AC_SUBST(CFLAGS, ["-Wall -O3 `pkg-config 
--cflags fuse`"])
++*-*-bsd-*)AC_SUBST(CFLAGS, ["-Wall -g -O3 `pkg-config 
--cflags fuse`"])
+   AC_SUBST(LIBS, ["$LIBS `pkg-config --cflags --libs 
fuse` -lz"]);;
+-*-*-darwin*)  AC_SUBST(CFLAGS, ["-Wall -O3 `pkg-config --cflags 
fuse`"])
++*-*-darwin*)  AC_SUBST(CFLAGS, ["-Wall -g -O3 `pkg-config --cflags 
fuse`"])
+   AC_SUBST(LIBS, ["$LIBS `pkg-config --cflags --libs 
fuse` -lz"]);;
+ *)AC_MSG_WARN(No automatic flags for this host 
system; set compile/linking flags manually);;
+ esac
+-- 
+2.11.0
+
diff -Nru 
rdiff-backup-fs-1.0.0/debian/patches/0001-Rename-variable-mount-to-mount_dir-to-avoid-calling-.patch
 
rdiff-backup-fs-1.0.0/debian/patches/0001-Rename-variable-mount-to-mount_dir-to-avoid-calling-.patch
--- 
rdiff-backup-fs-1.0.0/debian/patches/0001-Rename-variable-mount-to-mount_dir-to-avoid-calling-.patch
1970-01-01 02:00:00.0 +0200
+++ 
rdiff-backup-fs-1.0.0/debian/patches/0001-Rename-variable-mount-to-mount_dir-to-avoid-calling-.patch
2017-05-04 15:38:39.0 +0300
@@ -0,0 +1,117 @@
+From 9a60b26d8a1e7e7240569561c96006817279b78f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
+Date: Wed, 19 Apr 2017 18:05:06 +0200
+Subject: Rename variable mount to mount_dir to avoid calling it as function.
+
+Looks like the dynamic linker us

binNMU required for softhsm2 backport

[Adrian Bunk]

#854610 libsofthsm2 is not installable because of wrong libssl dependency

This looks like being caused by building in an unclean chroot.

Who is responsible for backports binNMUs, in this case for libsofthsm2 
on amd64?

Thanks
Adrian

-- 

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

Bug#858846: jessie-pu: package apt-cacher/1.7.10

[Adrian Bunk]

On Sun, Apr 23, 2017 at 09:38:42PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-03-27 at 16:47 +0100, Mark Hindley wrote:
> > I would like to arrange update of apt-cacher 1.7.10 in Jessie to fix the 
> > HTTP
> > splitting issue tracked in #858739 (no CVE allocated).
> > 
> > I have prepared 1.7.10+deb8u1 which is available from 
> > http://hindley.org.uk/~mark/debian
> 
> Please go ahead.
>...

Mark, did this upload get lost somewhere?

This CVE is now fixed in wheezy-security and uploaded for
stretch, but not yet for jessie.

And in a related topic:

#786661 apt-cacher: Does not work in inetd mode - fails to create 
/var/run/apt-cacher

This RC bug was reported against the version in jessie and is still 
unfixed there.

Could you add this fix and then send a debdiff to the bug so that Adam 
can approve fixing also this issue in jessie?

> Regards,
> 
> Adam

Thanks
Adrian

-- 

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

Bug#862353: jessie-pu: package chkrootkit/3.2~deb8u1

[Adrian Bunk]

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


 changelog |   24 
 control   |3 ++-
 patches/fix-stack-smash.patch |   12 
 patches/series|1 +
 rules |4 +++-
 5 files changed, 42 insertions(+), 2 deletions(-)

diff -Nru chkrootkit-0.50/debian/changelog chkrootkit-0.50/debian/changelog
--- chkrootkit-0.50/debian/changelog2015-03-23 11:22:11.0 +0200
+++ chkrootkit-0.50/debian/changelog2017-05-11 19:59:11.0 +0300
@@ -1,3 +1,27 @@
+chkrootkit (0.50-3.2~deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for jessie.
+
+ -- Adrian Bunk   Thu, 11 May 2017 19:58:29 +0300
+
+chkrootkit (0.50-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix-stack-smash.patch:
+- Fix segfault when running chkrootkit. (Closes: #767403)
+
+ -- Artur Rona   Sun, 06 Sep 2015 21:48:14 +0200
+
+chkrootkit (0.50-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing dependency on openssh-client. Closes: #785322
+  * Add Built-Using field to track the source package required to rebuild
+the statically linked binary. Closes: #769353
+
+ -- Raphaël Hertzog   Tue, 07 Jul 2015 17:48:12 +0200
+
 chkrootkit (0.50-3) unstable; urgency=high
 
   * [9e1ed7f] Ignore Suckit false positive (Closes: #740898)
diff -Nru chkrootkit-0.50/debian/control chkrootkit-0.50/debian/control
--- chkrootkit-0.50/debian/control  2015-03-23 11:22:11.0 +0200
+++ chkrootkit-0.50/debian/control  2015-07-07 19:01:01.0 +0300
@@ -11,7 +11,8 @@
 
 Package: chkrootkit
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, binutils, net-tools, debconf, 
procps
+Built-Using: ${Built-Using}
+Depends: ${shlibs:Depends}, ${misc:Depends}, binutils, net-tools, debconf, 
procps, openssh-client
 Description: rootkit detector
  The chkrootkit security scanner searches the local system for signs
  that it is infected with a 'rootkit'. Rootkits are set of programs
diff -Nru chkrootkit-0.50/debian/patches/fix-stack-smash.patch 
chkrootkit-0.50/debian/patches/fix-stack-smash.patch
--- chkrootkit-0.50/debian/patches/fix-stack-smash.patch1970-01-01 
02:00:00.0 +0200
+++ chkrootkit-0.50/debian/patches/fix-stack-smash.patch2014-10-30 
22:26:29.0 +0200
@@ -0,0 +1,12 @@
+diff -Naurp chkrootkit-0.49.orig//chkutmp.c chkrootkit-0.49//chkutmp.c
+--- chkrootkit-0.49.orig//chkutmp.c2009-07-30 09:43:17.0 -0400
 chkrootkit-0.49//chkutmp.c 2011-03-14 09:31:05.394307962 -0400
+@@ -98,7 +98,7 @@ int fetchps(struct ps_line *psl_p)
+   while (isspace(*s)) /* skip spaces */
+   s++;
+   d = pid;
+-  for (x = 0; (!isspace(*s)) && (*d++ = *s++) && x <= 
UT_LINESIZE; x++)   /* grab pid */
++  for (x = 0; (!isspace(*s)) && (*d++ = *s++) && x <= UT_PIDSIZE; 
x++)/* grab pid */
+   ;
+   *d = '\0';
+   curp->ps_pid = atoi(pid);
diff -Nru chkrootkit-0.50/debian/patches/series 
chkrootkit-0.50/debian/patches/series
--- chkrootkit-0.50/debian/patches/series   2015-03-23 11:22:11.0 
+0200
+++ chkrootkit-0.50/debian/patches/series   2015-09-06 22:48:07.0 
+0300
@@ -16,3 +16,4 @@
 kfreebsd.patch
 php.patch
 Suckitfalse.patch
+fix-stack-smash.patch
diff -Nru chkrootkit-0.50/debian/rules chkrootkit-0.50/debian/rules
--- chkrootkit-0.50/debian/rules2015-03-23 11:22:11.0 +0200
+++ chkrootkit-0.50/debian/rules2015-07-07 18:55:13.0 +0300
@@ -26,6 +26,8 @@
INSTALL_PROGRAM += -s
 endif
 
+BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), 
' -W libc-dev-bin)
+
 configure: configure-stamp
 configure-stamp:
dh_testdir
@@ -80,7 +82,7 @@
dh_fixperms
dh_installdeb
dh_shlibdeps
-   dh_gencontrol
+   dh_gencontrol -- -VBuilt-Using="$(BUILT_USING)"
dh_md5sums
dh_builddeb
 
 

Bug#862363: jessie-pu: package dwww/1.12.1+deb8u1

[Adrian Bunk]

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


 debian/changelog |8 
 scripts/dwww-convert |2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff -Nru dwww-1.12.1/debian/changelog dwww-1.12.1+deb8u1/debian/changelog
--- dwww-1.12.1/debian/changelog2014-01-14 00:10:17.0 +0200
+++ dwww-1.12.1+deb8u1/debian/changelog 2017-05-11 22:14:30.0 +0300
@@ -1,3 +1,11 @@
+dwww (1.12.1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply fix from Holger Spielmann for the `Last-Modified' header.
+(Closes: #850016, #850885)
+
+ -- Adrian Bunk   Thu, 11 May 2017 22:07:36 +0300
+
 dwww (1.12.1) unstable; urgency=medium
 
   * apache.conf: add an `Alias /dwww /var/www/dwww' line to accommodate
diff -Nru dwww-1.12.1/scripts/dwww-convert 
dwww-1.12.1+deb8u1/scripts/dwww-convert
--- dwww-1.12.1/scripts/dwww-convert2014-01-14 00:10:17.0 +0200
+++ dwww-1.12.1+deb8u1/scripts/dwww-convert 2017-05-11 22:03:26.0 
+0300
@@ -327,7 +327,7 @@
 print "Content-type: $mime_type" . (defined $mime_charset ? "; 
charset=$mime_charset\n" : "\n");
 my @stat = stat( $filename );
 my $mtime = $stat[9];
-print "Last modified: " . gmtime($mtime) . "\n";
+print "Last-modified: " . gmtime($mtime) . "\n";
 print "Content-Disposition: inline; filename=\"$base_name\"\n";
 print "\n";
 } # }}}

Bug#862367: jessie-pu: package dsh/0.25.10-1.1+deb8u1

[Adrian Bunk]

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


 debian/postinst  |   27 +++
 debian/preinst   |   20 
 dsh-0.25.10/debian/changelog |8 
 dsh-0.25.10/debian/postrm|3 +++
 dsh-0.25.10/debian/rules |1 -
 5 files changed, 58 insertions(+), 1 deletion(-)

diff -u dsh-0.25.10/debian/changelog dsh-0.25.10/debian/changelog
--- dsh-0.25.10/debian/changelog
+++ dsh-0.25.10/debian/changelog
@@ -1,3 +1,11 @@
+dsh (0.25.10-1.1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply fix from Ivo De Decker to not ship a symlink for
+/etc/dsh/group/all (Closes: #788585)
+
+ -- Adrian Bunk   Thu, 11 May 2017 22:34:33 +0300
+
 dsh (0.25.10-1.1) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff -u dsh-0.25.10/debian/postrm dsh-0.25.10/debian/postrm
--- dsh-0.25.10/debian/postrm
+++ dsh-0.25.10/debian/postrm
@@ -1,6 +1,9 @@
 #! /bin/sh
 
 if [ "$1" = "purge" ]; then
+  rm -f /etc/dsh/group/all
+  # might be created in preinst on upgrade
+  rm -f /etc/dsh/group/all.dpkg-backup
   rmdir --ignore-fail-on-non-empty /etc/dsh/group
   rmdir --ignore-fail-on-non-empty /etc/dsh
 fi
diff -u dsh-0.25.10/debian/rules dsh-0.25.10/debian/rules
--- dsh-0.25.10/debian/rules
+++ dsh-0.25.10/debian/rules
@@ -56,7 +56,6 @@
$(MAKE) install DESTDIR=$(CURDIR)/debian/dsh
cp $(CURDIR)/debian/machines.list 
$(CURDIR)/debian/dsh/etc/dsh/machines.list
cp $(CURDIR)/dsh.conf $(CURDIR)/debian/dsh/etc/dsh/dsh.conf
-   ln -s ../machines.list $(CURDIR)/debian/dsh/etc/dsh/group/all
install -d $(CURDIR)/debian/dsh/usr/lib/update-cluster
install -m 755 $(CURDIR)/debian/dsh.updatelist 
$(CURDIR)/debian/dsh/usr/lib/update-cluster/
 
only in patch2:
unchanged:
--- dsh-0.25.10.orig/debian/postinst
+++ dsh-0.25.10/debian/postinst
@@ -0,0 +1,27 @@
+#! /bin/sh
+
+if [ "$1" = "configure" ] && [ -z "$2" ]; then
+   if [ ! -e /etc/dsh/group/all ]
+   then
+   # manually create the symlink instead of shipping it
+   # see https://bugs.debian.org/788585
+   ln -s ../machines.list /etc/dsh/group/all
+   fi
+fi
+
+# see preinst
+SYMLINK="/etc/dsh/group/all"
+LASTVERSION="0.25.10-1.3~"
+
+if [ "$1" = "configure" ] &&
+   [ -n "$2" ] &&
+   dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then
+   if [ -e ${SYMLINK}.dpkg-backup -o -h ${SYMLINK}.dpkg-backup ] &&
+  [ ! -e "$SYMLINK" ]
+   then
+   mv -f "${SYMLINK}.dpkg-backup" "$SYMLINK"
+   fi
+fi
+
+#DEBHELPER#
+
only in patch2:
unchanged:
--- dsh-0.25.10.orig/debian/preinst
+++ dsh-0.25.10/debian/preinst
@@ -0,0 +1,20 @@
+#! /bin/sh
+
+# Handle the upgrade from the symlink shipped in the package to the symlink
+# created by the postinst
+# see https://bugs.debian.org/788585
+
+# this code is based on symlink_to_dir in dpkg-maintscript-helper
+
+# note that this also works if /etc/dsh/group/all is not a symlink
+SYMLINK="/etc/dsh/group/all"
+LASTVERSION="0.25.10-1.3~"
+
+if [ "$1" = "install" -o "$1" = "upgrade" ] &&
+   [ -n "$2" ] && [ -h "$SYMLINK" -o -e "$SYMLINK" ] &&
+   dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then
+   mv -f "$SYMLINK" "${SYMLINK}.dpkg-backup"
+fi
+
+#DEBHELPER#
+

Bug#862406: RM: ears/1.0.1-2.1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Control: tags -1 jessie

#786338 ears: broken since python-musicbrainz has been removed

I can reproduce that none of the commands works in jessie,
despite the dependency python-musicbrainz2 being installed.

It seems the #628475 "fix" changed the dependency from
python-musicbrainz to python-musicbrainz2 without any
conversion to make it also work with python-musicbrainz2.

Bug#862414: jessie-pu: package ed/1.10-2.1~deb8u1

[Adrian Bunk]

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

The only patch in the package (that was previously not applied)
is the following to fix "ed: ships /usr/share/info/dir.gz on arm64":

--- ed~/Makefile.in 2013-05-05 12:43:38.0 +0200
+++ ed/Makefile.in  2013-05-05 13:44:02.841303992 +0200
@@ -57,7 +57,7 @@
 check : all
@$(VPATH)/testsuite/check.sh $(VPATH)/testsuite $(pkgversion)
 
-install : install-bin install-info install-man
+install : install-bin install-man
 
 install-bin : all
if [ ! -d "$(DESTDIR)$(bindir)" ] ; then $(INSTALL_DIR) 
"$(DESTDIR)$(bindir)" ; fi



 changelog |   15 +++
 rules |3 +++
 2 files changed, 18 insertions(+)

diff -u ed-1.10/debian/changelog ed-1.10/debian/changelog
--- ed-1.10/debian/changelog
+++ ed-1.10/debian/changelog
@@ -1,3 +1,18 @@
+ed (1.10-2.1~deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for jessie.
+
+ -- Adrian Bunk   Fri, 12 May 2017 16:17:58 +0300
+
+ed (1.10-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: add build-arch target to ensure patches
+get applied (Closes: #799702)
+
+ -- Jonathan Wiltshire   Sat, 20 Feb 2016 12:49:56 +
+
 ed (1.10-2) unstable; urgency=medium
 
   * enable DEB_BUILD_MAINT_OPTIONS = hardening=+all
diff -u ed-1.10/debian/rules ed-1.10/debian/rules
--- ed-1.10/debian/rules
+++ ed-1.10/debian/rules
@@ -22,6 +22,9 @@
 build: patch-stamp
dh build
 
+build-arch: patch-stamp
+   dh build
+
 clean: unpatch
dh clean
dh_clean Makefile config.status *.o ed red

Bug#862438: jessie-pu: package eterm/0.9.6-1+deb8u1

[Adrian Bunk]

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

 eterm-0.9.6/debian/changelog |8 
 src/command.c|2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff -u eterm-0.9.6/debian/changelog eterm-0.9.6/debian/changelog
--- eterm-0.9.6/debian/changelog
+++ eterm-0.9.6/debian/changelog
@@ -1,3 +1,11 @@
+eterm (0.9.6-1+deb8u1) jessie; urgency=medium
+
+  * QA upload.
+  * Apply patch from Arnaud Ceyrolle to fix problems when starting
+or stopping the shell caused by an integer overflow. (Closes: #770369)
+
+ -- Adrian Bunk   Fri, 12 May 2017 19:52:47 +0300
+
 eterm (0.9.6-1) unstable; urgency=low
 
   * QA upload.
only in patch2:
unchanged:
--- eterm-0.9.6.orig/src/command.c
+++ eterm-0.9.6/src/command.c
@@ -1561,7 +1561,7 @@
  * child processes remain alive upon deletion of the window.
  */
 {
-unsigned short i;
+unsigned long i;
 unsigned long max_fds;
 
 /* get number of available file descriptors */

Bug#862439: unblock: eterm/0.9.6-5

[Adrian Bunk]

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

Except for some whitespace change in command.c, the only
difference after applying patches is the one-line #728813
fix in fix-esetroot-on-pseudocolor.patch

This one-line bugfix is the part I would like to see in stretch.

If unblocking this is not acceptable, I can make a t-p-u
(or unstable) upload containing only the #728813 fix on
top of 0.9.6-4.


 changelog|9 +++
 patches/command.c.patch  |   44 ---
 patches/fix-esetroot-on-pseudocolor.patch|   14 ++
 patches/manpage-is-dated-2008-08-17  |   11 
 patches/manpage-is-dated-2008-08-17.patch|   11 
 patches/run-shell-correctly.patch|   16 ++
 patches/series   |   11 ++--
 patches/typos-in-eterm-1-in  |   31 -
 patches/typos-in-eterm-1-in.patch|   32 +
 patches/typos-in-eterm-reference-html|   13 -
 patches/typos-in-eterm-reference-html.patch  |   13 +
 patches/we-will-do-fine-without-the-build-date   |   13 -
 patches/we-will-do-fine-without-the-build-date.patch |   13 +
 13 files changed, 114 insertions(+), 117 deletions(-)

diff -Nru eterm-0.9.6/debian/changelog eterm-0.9.6/debian/changelog
--- eterm-0.9.6/debian/changelog2016-03-05 18:22:37.0 +0200
+++ eterm-0.9.6/debian/changelog2017-01-29 20:02:04.0 +0200
@@ -1,3 +1,12 @@
+eterm (0.9.6-5) unstable; urgency=medium
+
+  * QA upload.
+  * Rename all patches to have .patch ending.
+  * Fix Esetroot on PseudoColor visual. Closes: #728813.
+Thanks to Kevin Ryde for the patch.
+
+ -- Santiago Vila   Sun, 29 Jan 2017 19:02:04 +0100
+
 eterm (0.9.6-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru eterm-0.9.6/debian/patches/command.c.patch 
eterm-0.9.6/debian/patches/command.c.patch
--- eterm-0.9.6/debian/patches/command.c.patch  2016-03-05 18:12:49.0 
+0200
+++ eterm-0.9.6/debian/patches/command.c.patch  1970-01-01 02:00:00.0 
+0200
@@ -1,44 +0,0 @@
-Description: Workaround for making Eterm run shell.
-Forwarded: not-needed
-Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770369
-Author: Arnaud Ceyrolle 
-Index: eterm-0.9.6/src/command.c
-===
 eterm-0.9.6.orig/src/command.c
-+++ eterm-0.9.6/src/command.c
-@@ -1561,7 +1561,7 @@ get_tty(void)
-  * child processes remain alive upon deletion of the window.
-  */
- {
--unsigned short i;
-+unsigned long i;
- unsigned long max_fds;
- 
- /* get number of available file descriptors */
-@@ -2354,7 +2354,7 @@ run_command(char **argv)
- privileges(REVERT);
- }
- 
--/* Permanently revoke all privileges for the child process.  
-+/* Permanently revoke all privileges for the child process.
-Root shells for everyone are tres uncool ;^) -- mej */
- #ifdef _HPUX_SOURCE
- setresuid(my_ruid, my_ruid, my_euid);
-@@ -3671,7 +3671,7 @@ main_loop(void)
- D_SCREEN(("Adding %d lines (%d chars); str == %8p, cmdbuf_ptr == 
%8p, cmdbuf_endp == %8p\n",
-   nlines, cmdbuf_ptr - str, str, cmdbuf_ptr, 
cmdbuf_endp));
- #if FIXME_BLOCK
--/* 
-+/*
-  * iconv() is not my friend. :-( I've tried various things
-  * to make this work (including UCS2, SJIS, EUCJ, and
-  * WCHAR_T), but nothing has worked.  I'm obviously
-@@ -3800,7 +3800,7 @@ v_doPending(void)
- 
- /* Write data to the pty as typed by the user, pasted with the mouse,
-  * or generated by us in response to a query ESC sequence.
-- * Code stolen from xterm 
-+ * Code stolen from xterm
-  */
- void
- v_writeBig(int f, char *d, int len)
diff -Nru eterm-0.9.6/debian/patches/fix-esetroot-on-pseudocolor.patch 
eterm-0.9.6/debian/patches/fix-esetroot-on-pseudocolor.patch
--- eterm-0.9.6/debian/patches/fix-esetroot-on-pseudocolor.patch
1970-01-01 02:00:00.0 +0200
+++ eterm-0.9.6/debian/patches/fix-esetroot-on-pseudocolor.patch
2017-01-29 19:06:00.0 +0200
@@ -0,0 +1,14 @@
+From: Kevin Ryde 
+Subject: Fix Esetroot on PseudoColor visual
+Bug-Debian: https://bugs.debian.org/728813
+
+--- a/utils/Esetroot.c
 b/utils/Esetroot.c
+@@ -180,6 +180,7 @@
+ }
+ imlib_context_set_display(Xdisplay);
+ imlib_context_set_visual(DefaultVisual(Xdisplay, 
DefaultScreen(Xdisplay)));
++imlib_context_set_colormap(DefaultColormap(Xdisplay, 
DefaultScreen(Xdisplay)));
+ im = imlib_load_image_immediately(fname);
+ if (!im) {
+ fprintf(stderr, "%s:  Unable to load image file \"%s\".\n", *argv, 
fname);
diff -Nru eterm-0.9.6/debian/patches/manpage-is-dat

Bug#862453: jessie-pu: package fwsnort/1.6.5-2~deb8u1

[Adrian Bunk]

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

 changelog |   18 ++
 control   |4 ++--
 gbp.conf  |4 
 patches/fix-dport-bracket-usage.patch |   27 +++
 patches/series|1 +
 5 files changed, 52 insertions(+), 2 deletions(-)

diff -Nru fwsnort-1.6.5/debian/changelog fwsnort-1.6.5/debian/changelog
--- fwsnort-1.6.5/debian/changelog  2014-08-30 20:11:55.0 +0300
+++ fwsnort-1.6.5/debian/changelog  2017-05-12 23:18:55.0 +0300
@@ -1,3 +1,21 @@
+fwsnort (1.6.5-2~deb8u1) jessie; urgency=medium
+
+  * QA upload.
+  * Rebuild for jessie.
+
+ -- Adrian Bunk   Fri, 12 May 2017 23:18:30 +0300
+
+fwsnort (1.6.5-2) unstable; urgency=medium
+
+  * Orphan the package. (See #831274.)
++ Set Maintainer to Debian QA Group.
+  * Add a debian/gbp.conf and "-b debian" to Vcs-Git to reflect the git
+repository layout.
+  * Add patch to also remove square brackets from single port definitions.
+(Closes: #860164)
+
+ -- Axel Beckert   Sat, 06 May 2017 16:17:38 +0200
+
 fwsnort (1.6.5-1) unstable; urgency=low
 
   * Imported Upstream version 1.6.5
diff -Nru fwsnort-1.6.5/debian/control fwsnort-1.6.5/debian/control
--- fwsnort-1.6.5/debian/control2014-08-30 20:11:55.0 +0300
+++ fwsnort-1.6.5/debian/control2017-05-06 13:31:14.0 +0300
@@ -3,9 +3,9 @@
 Priority: optional
 Build-Depends: debhelper (>= 8)
 Build-Depends-Indep: po-debconf
-Maintainer: Franck Joncourt 
+Maintainer: Debian QA Group 
 Standards-Version: 3.9.5
-Vcs-git: git://anonscm.debian.org/collab-maint/fwsnort.git
+Vcs-Git: git://anonscm.debian.org/collab-maint/fwsnort.git -b debian
 Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=collab-maint/fwsnort.git;a=summary
 Homepage: http://www.cipherdyne.org/fwsnort/
 
diff -Nru fwsnort-1.6.5/debian/gbp.conf fwsnort-1.6.5/debian/gbp.conf
--- fwsnort-1.6.5/debian/gbp.conf   1970-01-01 02:00:00.0 +0200
+++ fwsnort-1.6.5/debian/gbp.conf   2017-05-06 13:18:38.0 +0300
@@ -0,0 +1,4 @@
+# Configuration file for git-buildpackage and friends
+
+[DEFAULT]
+debian-branch = debian
diff -Nru fwsnort-1.6.5/debian/patches/fix-dport-bracket-usage.patch 
fwsnort-1.6.5/debian/patches/fix-dport-bracket-usage.patch
--- fwsnort-1.6.5/debian/patches/fix-dport-bracket-usage.patch  1970-01-01 
02:00:00.0 +0200
+++ fwsnort-1.6.5/debian/patches/fix-dport-bracket-usage.patch  2017-05-06 
14:22:03.0 +0300
@@ -0,0 +1,27 @@
+Description: Also remove square brackets from single port definitions
+Bug-Debian: https://bugs.debian.org/860164
+
+--- a/fwsnort
 b/fwsnort
+@@ -1137,10 +1137,10 @@
+ }
+ 
+ for my $var (qw(sport dport)) {
++$hsh{$var} =~ s/\[//;
++$hsh{$var} =~ s/\]//;
+ next unless $hsh{$var} =~ /,/;
+ if ($ipt_have_multiport_match) {
+-$hsh{$var} =~ s/\[//;
+-$hsh{$var} =~ s/\]//;
+ my $ctr = 1;
+ my @ports = split /\s*,\s*/, $hsh{$var};
+ my $ports_str = '';
+@@ -1162,8 +1162,6 @@
+ "$hsh{$var} until the $ipt_str multiport match is 
supported " .
+ "at line: $line_num.");
+ $hsh{$var} =~ s/,.*//;
+-$hsh{$var} =~ s/\[//;
+-$hsh{$var} =~ s/\]//;
+ }
+ }
+ 
diff -Nru fwsnort-1.6.5/debian/patches/series 
fwsnort-1.6.5/debian/patches/series
--- fwsnort-1.6.5/debian/patches/series 1970-01-01 02:00:00.0 +0200
+++ fwsnort-1.6.5/debian/patches/series 2017-05-06 14:22:03.0 +0300
@@ -0,0 +1 @@
+fix-dport-bracket-usage.patch

Bug#862457: jessie-pu: package gdm3/3.14.1-8~deb8u1

[Adrian Bunk]

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

The Uploaders field changed since it is automatically
generated during the build, listing the uploaders from
the 10 most recent uploads in the changelog that are
also GNOME team members.


 changelog |   14 ++
 control   |2 +-
 patches/07_fix_caribou_path.patch |   15 +++
 patches/series|1 +
 4 files changed, 31 insertions(+), 1 deletion(-)

diff -Nru gdm3-3.14.1/debian/changelog gdm3-3.14.1/debian/changelog
--- gdm3-3.14.1/debian/changelog2015-04-04 10:20:26.0 +0300
+++ gdm3-3.14.1/debian/changelog2017-05-13 00:19:02.0 +0300
@@ -1,3 +1,17 @@
+gdm3 (3.14.1-8~deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for jessie.
+
+ -- Adrian Bunk   Sat, 13 May 2017 00:18:41 +0300
+
+gdm3 (3.14.1-8) unstable; urgency=medium
+
+  * d/p/07_fix_caribou_path.patch: Fix the path to the caribou daemon in the
+autostart desktop file (Closes: #784671)
+
+ -- Laurent Bigonville   Tue, 09 Jun 2015 15:04:11 +0200
+
 gdm3 (3.14.1-7) unstable; urgency=medium
 
   * Add Conflicts/Replaces: gdm in libgdm1 as well. Closes: #781535.
diff -Nru gdm3-3.14.1/debian/control gdm3-3.14.1/debian/control
--- gdm3-3.14.1/debian/control  2015-04-04 10:30:27.0 +0300
+++ gdm3-3.14.1/debian/control  2017-05-13 00:24:05.0 +0300
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Andreas Henriksson , Josselin Mouette 
, Laurent Bigonville 
+Uploaders: Josselin Mouette , Laurent Bigonville 

 Build-Depends: gnome-pkg-tools (>= 0.16.3),
debhelper (>= 8.1.3),
cdbs (>= 0.4.122~),
diff -Nru gdm3-3.14.1/debian/patches/07_fix_caribou_path.patch 
gdm3-3.14.1/debian/patches/07_fix_caribou_path.patch
--- gdm3-3.14.1/debian/patches/07_fix_caribou_path.patch1970-01-01 
02:00:00.0 +0200
+++ gdm3-3.14.1/debian/patches/07_fix_caribou_path.patch2015-06-09 
15:37:34.0 +0300
@@ -0,0 +1,15 @@
+Description: Fix caribou daemon path in autostart file
+From: Laurent Bigonville 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784671
+Forwarded: not-needed
+
+--- a/data/autostart/caribou-autostart.desktop.in
 b/data/autostart/caribou-autostart.desktop.in
+@@ -1,6 +1,6 @@
+ [Desktop Entry]
+ Type=Application
+ Name=Caribou
+-Exec=@LIBEXECDIR@/caribou
++Exec=/usr/lib/caribou/caribou
+ AutostartCondition=GSettings org.gnome.desktop.a11y.applications 
screen-keyboard-enabled
+ X-GNOME-AutoRestart=true
diff -Nru gdm3-3.14.1/debian/patches/series gdm3-3.14.1/debian/patches/series
--- gdm3-3.14.1/debian/patches/series   2015-03-11 20:27:40.0 +0200
+++ gdm3-3.14.1/debian/patches/series   2015-06-09 13:59:34.0 +0300
@@ -1,3 +1,4 @@
+07_fix_caribou_path.patch
 08_frequent-users_greeter.patch
 09_default_session.patch
 16_xserver_path.patch

Bug#862480: unblock: gui-ufw/17.04.1-1.1

[Adrian Bunk]

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

Please unblock package gui-ufw

 changelog |8 
 control   |2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff -Nru gui-ufw-17.04.1/debian/changelog gui-ufw-17.04.1/debian/changelog
--- gui-ufw-17.04.1/debian/changelog2016-11-02 22:23:31.0 +0200
+++ gui-ufw-17.04.1/debian/changelog2017-05-13 13:23:39.0 +0300
@@ -1,3 +1,11 @@
+gui-ufw (17.04.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on net-tools, thanks to João Pirralha
+for the bug report. (Closes: #855400)
+
+ -- Adrian Bunk   Sat, 13 May 2017 13:23:39 +0300
+
 gui-ufw (17.04.1-1) unstable; urgency=medium
 
   * New upstream release, upstream changelog:
diff -Nru gui-ufw-17.04.1/debian/control gui-ufw-17.04.1/debian/control
--- gui-ufw-17.04.1/debian/control  2016-11-02 22:23:31.0 +0200
+++ gui-ufw-17.04.1/debian/control  2017-05-13 13:23:19.0 +0300
@@ -14,7 +14,7 @@
 Package: gufw
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, ufw (>= 0.34~rc), gir1.2-gtk-3.0,
- policykit-1, gir1.2-webkit2-4.0, python3-gi
+ policykit-1, gir1.2-webkit2-4.0, python3-gi, net-tools
 Description: graphical user interface for ufw
  gufw is an easy and intuitive way to manage your Linux firewall. It supports
  common tasks such as allowing or blocking pre-configured, common p2p, or

Bug#862486: RM: gnuvd/1.0.12-1

[Adrian Bunk]

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

#767076 gnuvd not able to search for words

Quoting the #851896 removal from unstable:
  This package queries a Dutch online dictionary. However, the server
  changes its output frequently, the package no longer works. Upstream has
  stopped updating the package since 2012.

Bug#862503: RM: hbro/1.1.2.2-2

[Adrian Bunk]

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

#783389 hbro segfaults

I can reproduce on amd64 that it always segfaults at startup,
and the discussion in the bug and upstream indicates that this
is some issue related to how GMP is used in hbro.

The solution for unstable/stretch was to remove the package.