Bug#848046: glances: upgrade fails when server is disabled

[Axel Beckert]

Control: severity -1 important
Control: tag -1 + patch

Hi,

Ingo Saitz wrote:
> On Tue, Dec 13, 2016 at 11:47:32AM -0500, Daniel Echeverry wrote:
> > thanks for your report, Unfortunately I can't reproduce this issue,
> > Could you confirm from which glances version are you trying to update?
> 
> From /var/lib/dpkg.log:
> 2016-12-13 12:27:44 upgrade glances:all 2.6.2-2 2.7.1.1-1

Same here:

2016-12-10 22:15:51 upgrade glances:all 2.6.2-2 2.7.1.1-1

> So I was just upgrading from the previous glances version in unstable,
> 2.6.2-2. But I think the upgrade might be broken longer, Since this is
> the first upgrade of this package on my system:
> 
> 2016-11-12 14:49:01 install glances:all  2.6.2-2

I have glances installed since 2.5.1-1 (installed on 2016-05-04), but
/etc/default/glances which disables the daemon is even older.

> Have you tried upgrading (using sysvinit as init) without running
> glances server? The problem is, i believe, in the initscript, which gets
> called as /etc/init.d/glances reload on upgrade, but exits with an error
> code if the glances server is configured not to run. I have attached a
> patch for the initscript, which fixes the return code from
> /etc/init.d/glances reload by ignoring the failure to stop the glances
> server, when none should be running.

This observation fits with my observation. Also using sysvinit here.

IMHO this is of severity serious since it causes an dist-upgrade
failure ever since this started, but since it only happens with a
non-default init system, I'm only raising this to severity important.
Feel free to raise the severity further.

Random excerpt from my dpkg.log:

2016-12-14 17:41:06 status half-configured glances:all 2.7.1.1-1
2016-12-14 17:41:35 configure glances:all 2.7.1.1-1 
2016-12-14 17:41:35 status half-configured glances:all 2.7.1.1-1
2016-12-15 13:39:47 configure glances:all 2.7.1.1-1 
2016-12-15 13:39:47 status half-configured glances:all 2.7.1.1-1
2016-12-15 13:40:19 configure glances:all 2.7.1.1-1 
2016-12-15 13:40:19 status half-configured glances:all 2.7.1.1-1
2016-12-16 02:18:09 configure glances:all 2.7.1.1-1 
2016-12-16 02:18:09 status half-configured glances:all 2.7.1.1-1
2016-12-16 02:19:29 configure glances:all 2.7.1.1-1 
2016-12-16 02:19:29 status half-configured glances:all 2.7.1.1-1
2016-12-16 11:55:39 configure glances:all 2.7.1.1-1 
2016-12-16 11:55:39 status half-configured glances:all 2.7.1.1-1
2016-12-16 11:56:03 configure glances:all 2.7.1.1-1 
2016-12-16 11:56:03 status half-configured glances:all 2.7.1.1-1
2016-12-17 03:03:47 configure glances:all 2.7.1.1-1 
2016-12-17 03:03:47 status half-configured glances:all 2.7.1.1-1
2016-12-17 03:04:19 configure glances:all 2.7.1.1-1 
2016-12-17 03:04:19 status half-configured glances:all 2.7.1.1-1
2016-12-17 17:16:24 configure glances:all 2.7.1.1-1 
2016-12-17 17:16:24 status half-configured glances:all 2.7.1.1-1
2016-12-17 17:19:24 configure glances:all 2.7.1.1-1 
2016-12-17 17:19:24 status half-configured glances:all 2.7.1.1-1
2016-12-17 17:20:15 configure glances:all 2.7.1.1-1 
2016-12-17 17:20:15 status half-configured glances:all 2.7.1.1-1
2016-12-19 17:15:48 configure glances:all 2.7.1.1-1 
2016-12-19 17:15:48 status half-configured glances:all 2.7.1.1-1

That's the annoying part of this bug.

> --- a/etc/init.d/glances  2016-12-14 11:14:04.0 +0100
> +++ b/etc/init.d/glances  2016-12-14 11:13:43.0 +0100
> @@ -118,7 +118,12 @@ case "$1" in
>  ;;
>*)
>  # Failed to stop
> -log_end_msg 1
> +if [ "$RUN" != "true" ]; then
> +log_action_msg "disabled by /etc/default/$NAME"
> +log_end_msg 0
> +else
> +log_end_msg 1
> +fi
>  ;;
>  esac
>  ;;

I'll test that patch later.

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

Bug#849177: Python-numpy transition breaks at least two packages

[Andreas Tille]

Hi,

I have cloned bug #848758 where I suggested to revert the python-numpy
transition which other posters agreed upon.  Besides breaking
python-skbio I spotted another package python-skimage which fails with:


==
ERROR: skimage.filters.rank.tests.test_rank.test_all
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
 line 16, in test_all
check_all()
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/testing.py",
 line 232, in inner
result = func(*args, **kwargs)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
 line 89, in check_all
rank.windowed_histogram(image, selem))
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
 line 986, in windowed_histogram
pixel_size=n_bins)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
 line 90, in _apply_vector_per_pixel
pixel_size=pixel_size)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
 line 53, in _handle_input
out = np.empty(image.shape+(pixel_size,), dtype=out_dtype)
TypeError: 'numpy.float64' object cannot be interpreted as an index

--
Ran 1383 tests in 181.697s


I'll leave it to the reader to consider lowering the severity of this
bug and risking that python-skimage (and possibly other packages) will
not reach the next stable release.  While python-skbio is a package of
minor importance python-skimage has several reverse depends and should
be saved.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#849179: ITP: node-sorted-object -- Return a copy of an object with its keys sorted

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-sorted-object
  Version : 2.0.1
  Upstream Author : Domenic Denicola  (https://domenic.me/)
* URL : https://github.com/domenic/sorted-object#readme
* License : Espat
  Programming Lang: JavaScript
  Description : Return a copy of an object with its keys sorted

 Node.js module to create a version of an object with its keys sorted
 so that you'll get a consistent order every time on serializing.
 This makes it easier to diff the resulting JSON.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#849180: ooniprobe: adequate complains about a broken symlink of ooniprobe.conf.sample

[shirish शिरीष]

Package: ooniprobe
Version: 2.1.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: broken-symlink adequate

Dear Maintainer,
Adequate reported a broken symlink -

$ adequate ooniprobe
ooniprobe: broken-symlink
/usr/share/doc/ooniprobe/examples/ooniprobe.conf.sample ->
../../../ooni/ooniprobe.conf.sample

I went to see if the original file is in its place.

/usr/share/doc/ooniprobe/examples $ cat ooniprobe.conf.sample
cat: ooniprobe.conf.sample: No such file or directory

Obviously if the file is not there, the symlink will be broken.

Please fix the above.

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

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

Versions of packages ooniprobe depends on:
ii  adduser3.115
ii  geoip-database 20161109-1
ii  init-system-helpers1.46
ii  python-certifi 2016.2.28-1
ii  python-geoip   1.3.2-1+b2
ii  python-ipaddr  2.1.11-2
ii  python-klein   15.3.1-1
ii  python-openssl 16.2.0-1
ii  python-pkg-resources   28.7.1-1
ii  python-pyasn1  0.1.9-2
ii  python-scapy   2.3.3-1
ii  python-twisted-core16.6.0-2
ii  python-txsocksx1.15.0.2-1
ii  python-txtorcon0.17.0-1
ii  python-yaml3.12-1
ii  python-zope.interface  4.3.2-1
pn  python:any 
ii  tor0.2.8.11-2

Versions of packages ooniprobe recommends:
ii  python-dumbnet  1.12-7
ii  python-pypcap   1.1.5-1

Versions of packages ooniprobe suggests:
pn  geoip-database-contrib  
ii  obfsproxy   0.2.13-2

-- debconf information:
* ooniprobe/run-cronjob: true


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#831965: Status of asciidoc upload?

[Raphael Hertzog]

On Fri, 23 Dec 2016, Joseph Herlant wrote:
> Hi Raphael,
> 
> Thanks a lot for the upload. Unfortunately there were misses in the
> copyright file.
> I fixed that, retagged and pushed to the git repo and to mentors.
> Let me know if you find anything else that need to be fixed.

Yes, I think you went too far by marking files licensed under GPL version
1 only.

Thorsten asked to add the GFDL and the MIT license to appropriate files,
he did not ask to mark files under GPL v1 only. And I doubt that the
author intended to put files under GPL v1 only when the global license
states GPL-2+.

Furthermore your "GPL" license entry has a pointer to
"/usr/share/common-licenses/GPL-2" instead of
"/usr/share/common-licenses/GPL" (if you really want to keep that
reference to GPL v1 only).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#849175: jessie-pu: package ganeti-instance-debootstrap/0.14-2

[Apollon Oikonomopoulos]

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

Dear SRMs,

I would like to update ganeti-instance-debootstrap in Jessie to fix 
#834404. In particular, the proposed update includes an upstream commit 
that replaces all instances of `losetup -s' with `losetup --show', as 
the former is no longer supported since util-linux 2.21.

Please find attached a full debdiff of the proposed upload.

Regards,
Apollon
diff -Nru ganeti-instance-debootstrap-0.14/debian/changelog 
ganeti-instance-debootstrap-0.14/debian/changelog
--- ganeti-instance-debootstrap-0.14/debian/changelog   2014-05-23 
11:56:33.0 +0300
+++ ganeti-instance-debootstrap-0.14/debian/changelog   2016-12-23 
10:48:28.0 +0200
@@ -1,3 +1,9 @@
+ganeti-instance-debootstrap (0.14-2+deb8u1) jessie; urgency=medium
+
+  * Replace losetup -s with losetup --show (Closes: #834404)
+
+ -- Apollon Oikonomopoulos   Fri, 23 Dec 2016 10:48:28 
+0200
+
 ganeti-instance-debootstrap (0.14-2) unstable; urgency=medium
 
   * Use kpartx's sync mode:
diff -Nru 
ganeti-instance-debootstrap-0.14/debian/patches/0002-Replace-losetup-flag-s-with-show.patch
 
ganeti-instance-debootstrap-0.14/debian/patches/0002-Replace-losetup-flag-s-with-show.patch
--- 
ganeti-instance-debootstrap-0.14/debian/patches/0002-Replace-losetup-flag-s-with-show.patch
 1970-01-01 02:00:00.0 +0200
+++ 
ganeti-instance-debootstrap-0.14/debian/patches/0002-Replace-losetup-flag-s-with-show.patch
 2016-12-23 10:48:28.0 +0200
@@ -0,0 +1,71 @@
+From 913c6e4222969470796729cf188bb79a78635d8a Mon Sep 17 00:00:00 2001
+From: "Jose A. Lopes" 
+Date: Fri, 24 Jan 2014 10:23:01 +0100
+Subject: [PATCH] Replace 'losetup' flag '-s' with '--show'
+
+This fixes issue 690.
+
+Signed-off-by: Jose A. Lopes 
+Reviewed-by: Klaus Aehlig 
+---
+ create | 2 +-
+ export | 2 +-
+ import | 2 +-
+ rename | 2 +-
+ 4 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/create b/create
+index c276b04..6565176 100755
+--- a/create
 b/create
+@@ -36,7 +36,7 @@ CACHE_FILE="$CACHE_DIR/cache-${SUITE}-${DPKG_ARCH}.tar"
+ # This is needed for file disks.
+ if [ ! -b $blockdev ]; then
+   ORIGINAL_BLOCKDEV=$blockdev
+-  blockdev=$(losetup -sf $blockdev)
++  blockdev=$(losetup --show -f $blockdev)
+   CLEANUP+=("losetup -d $blockdev")
+ fi
+ 
+diff --git a/export b/export
+index 46aa74c..8941621 100755
+--- a/export
 b/export
+@@ -25,7 +25,7 @@ set -e
+ # This is needed for file disks.
+ if [ ! -b $blockdev ]; then
+   ORIGINAL_BLOCKDEV=$blockdev
+-  blockdev=$(losetup -sf $blockdev)
++  blockdev=$(losetup --show -f $blockdev)
+   CLEANUP+=("losetup -d $blockdev")
+ fi
+ 
+diff --git a/import b/import
+index 2d9b58e..a69759d 100755
+--- a/import
 b/import
+@@ -25,7 +25,7 @@ set -e
+ # This is needed for file disks.
+ if [ ! -b $blockdev ]; then
+   ORIGINAL_BLOCKDEV=$blockdev
+-  blockdev=$(losetup -sf $blockdev)
++  blockdev=$(losetup --show -f $blockdev)
+   CLEANUP+=("losetup -d $blockdev")
+ fi
+ 
+diff --git a/rename b/rename
+index 652d6b7..81bf8dd 100755
+--- a/rename
 b/rename
+@@ -28,7 +28,7 @@ CLEANUP+=("rmdir $TMPDIR")
+ # This is needed for file disks.
+ if [ ! -b $blockdev ]; then
+   ORIGINAL_BLOCKDEV=$blockdev
+-  blockdev=$(losetup -sf $blockdev)
++  blockdev=$(losetup --show -f $blockdev)
+   CLEANUP+=("losetup -d $blockdev")
+ fi
+ 
+-- 
+2.10.2
+
diff -Nru ganeti-instance-debootstrap-0.14/debian/patches/series 
ganeti-instance-debootstrap-0.14/debian/patches/series
--- ganeti-instance-debootstrap-0.14/debian/patches/series  2014-05-23 
11:56:33.0 +0300
+++ ganeti-instance-debootstrap-0.14/debian/patches/series  2016-12-23 
10:48:28.0 +0200
@@ -1 +1,2 @@
 0001-Use-sync-kpartx-mode-when-creating-devices.patch
+0002-Replace-losetup-flag-s-with-show.patch

Bug#843471: Intent to NMU to fix #843471 [Was: Bug#843471: libspice-client-gtk-3.0-5: virt-manager segfaults in libspice-client-gtk]

[intrigeri]

Control: tag -1 +patch
Control: severity -1 important

Hi Liang Guo,

Christophe Fergeau:
> This is most likely the crash fixed by this upstream commit:
> https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=03c016bea939ee4a26e90d80fa1012a993a8ea47

I've been affected by this bug for a while, which made my usage of
virt-manager a pain. Applying this commit on top of spice-gtk 0.33-3
made the problem go away. I would really like this to be fixed in
Stretch, so I intend to NMU this package to delayed+5 (diff attached),
so that 0.33-3.1 has a chance to migrate to testing before my upload
reaches sid.

What do you think?

(I'd like to fix #797855 in time for Stretch as well, but that'll be
for another day.)

Cheers,
-- 
intrigeri

diff -Nru spice-gtk-0.33/debian/changelog spice-gtk-0.33/debian/changelog
--- spice-gtk-0.33/debian/changelog	2016-12-10 16:06:07.0 +0100
+++ spice-gtk-0.33/debian/changelog	2016-12-22 13:45:38.0 +0100
@@ -1,3 +1,11 @@
+spice-gtk (0.33-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian_843471-clipboard_Fix_crash_by_handling_error.patch:
+new patch, cherry-picked from upstream (Closes: #843471).
+
+ -- intrigeri   Thu, 22 Dec 2016 12:45:38 +
+
 spice-gtk (0.33-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru spice-gtk-0.33/debian/patches/debian_843471-clipboard_Fix_crash_by_handling_error.patch spice-gtk-0.33/debian/patches/debian_843471-clipboard_Fix_crash_by_handling_error.patch
--- spice-gtk-0.33/debian/patches/debian_843471-clipboard_Fix_crash_by_handling_error.patch	1970-01-01 01:00:00.0 +0100
+++ spice-gtk-0.33/debian/patches/debian_843471-clipboard_Fix_crash_by_handling_error.patch	2016-12-22 13:45:07.0 +0100
@@ -0,0 +1,40 @@
+commit 03c016bea939ee4a26e90d80fa1012a993a8ea47
+Author: Victor Toso 
+Origin: upstream, https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=03c016bea939ee4a26e90d80fa1012a993a8ea47
+Bug-Debian: https://bugs.debian.org/843471
+Date:   Fri Oct 14 18:12:01 2016 +0200
+
+clipboard: Fix crash by handling error
+
+As manual states below, text could be NULL for different reasons and
+we should handle that. I've included a debug message to help
+identifying possible regressions from wayland's clipboard.
+
+This crash is a regression from 7b0de6217670e0f668aff2949f
+
+ "The text parameter to callback will contain the resulting text if
+ the request succeeded, or NULL if it failed. This could happen for
+ various reasons, in particular if the clipboard was empty or if the
+ contents of the clipboard could not be converted into text form."
+
+Resolves: rhbz#1384676
+
+Signed-off-by: Victor Toso 
+Acked-by: Pavel Grunt 
+
+diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
+index 3ff4e9a..3e0ec74 100644
+--- a/src/spice-gtk-session.c
 b/src/spice-gtk-session.c
+@@ -945,6 +945,11 @@ static void clipboard_received_text_cb(GtkClipboard *clipboard,
+ if (self == NULL)
+ return;
+ 
++if (text == NULL) {
++SPICE_DEBUG("Failed to retrieve clipboard text");
++return;
++}
++
+ g_return_if_fail(SPICE_IS_GTK_SESSION(self));
+ 
+ selection = get_selection_from_clipboard(self->priv, clipboard);
diff -Nru spice-gtk-0.33/debian/patches/series spice-gtk-0.33/debian/patches/series
--- spice-gtk-0.33/debian/patches/series	2016-12-10 16:06:07.0 +0100
+++ spice-gtk-0.33/debian/patches/series	2016-12-22 13:44:41.0 +0100
@@ -1,2 +1,3 @@
 explicitly-enable-subdir-objects.patch
 spice-gtk-get-it-compiled-against-openssl-1.1.0.patch
+debian_843471-clipboard_Fix_crash_by_handling_error.patch

Bug#848894: Cannot reproduce on sbuild; thoughts on architecture=amd64

[roucaries bastien]

On Wed, Dec 21, 2016 at 11:54 PM, Hilko Bengen  wrote:
> control: tag -1 unreproducible
>
> Good evening.
>
> In my linux/amd64 sbuild setup, dx builds just fine.
>
> What had me puzzled, though, is how the message "checking architecture
> type... amd64" came to be. If uname works correctly, the string "amd64"
> could not have been generated inside the DX_ARCHITECTURE function
> (acinclude.m4). Could it be that ARCH=amd64 was part of the environment
> that got passed to pbuilder ... and to the configure script?
>
> Indeed, when I call the configure script with the ARCH environment
> variable set, I can reproduce the effect:

Yes I think so. Please close
> ,
> | $ ARCH=amd64 ./configure
> | [...]
> | checking whether large file support needs explicit enabling... yes
> | checking architecture type... amd64
> | checking architecture specific stuff... done
> | checking for a BSD-compatible install... /usr/bin/install -c
> `
>
> Cheers,
> -Hilko

Bug#849182: ITP: node-pad -- Left and right string padding

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-pad
  Version : 1.0.2
  Upstream Author : David Worms 
* URL : https://github.com/wdavidw/node-pad#readme
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Left and right string padding

 Node.js module that provides a simple function to pad strings
 in both left and right directions.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#849181: ITP: node-progress -- Flexible ascii progress bar

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-progress
  Version : 1.1.8
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/node-progress
* License : Expat
  Programming Lang: JavaScript
  Description : Flexible ascii progress bar

 Node.js module to flexibly create progress bars for CLI user
 interfaces.
 Supports back-and-forth movement and colors.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#848310: RM: targetcli -- ROM; superseded by targetcli-fb, from new LIO-fb upstream

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2016-12-23 at 09:10 +0100, Harald Dunkel wrote:
> Is there an upgrade path from the old targetcli 2.0 to the
> new targetcli-fb and lio-fb?

No. This isn't supported in the packages. The upstream data format is also
changed amongst LIO and the -fb fork.

I recently blogged about possibilities but it is not supported and you should
use it at your own risk.

https://www.researchut.com/blog/lio-migration-to-fb


- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhc3hwACgkQpjpYo/Lh
dWlx8A/+LWXP79jTvp+gQ5DSHkVhNOzivmMrUlE9ZjOjR/4k6J1qL8iOsjahX2Ys
6u97YzdQCtPBoLqt58zxoViegWuPTHIu2msSsJrvY1gB1SWryhLux5hvphH5P4JL
PoB/mLpolg4kGZDy0i/82vgMEbMQ+WlW69FfZ8eJ2W/KTysDMEWUdie9ik7fps9V
eB6swvxBqOqHZJzVxEaspe6DexL2ExPqXCmSwZSnE+/OprRjbF22Lfo3GpDNBQCn
SC2A15fuffKzV62K4LMxg/SWQrF6HaL22nv75NQaiIk186A18jaq8ab8QQBrU5vF
2ZpgWCNddOMtqhKjcdNjpuKfJ9hlKMWWKKcHrCV2GdzLZ0oSQFB+2oo9aclrEmqH
Gz0ZY6h3rYKnv+tZvA6D/yfT0izy4gteDp5496P2vkUYCAo3Lz/876te8UVye/sn
GLmAFnTXkRYrHmDsoJ8d/7kzMHIHpICB+1Mse2pv92xPg1wN9c/R90BwZOWYZEyq
bHgtqovBrMfgfp3TKAVfINRNAKQCZ6EOrYdApfBIrUw1NAL0HtwbqK9/ivI0YpPX
NBZyypfVXow2u9VGXoAM5CWk74kFgrIojR+hbCsjEHz3HInuLKPEZlZioR0+ai9y
abDGyNNHqYNf3XgjD1NFHJP9Xxbdw08JrU4n1CmhhXcDhjVZI0I=
=DjTN
-END PGP SIGNATURE-

Bug#848310: RM: targetcli -- ROM; superseded by targetcli-fb, from new LIO-fb upstream

[Harald Dunkel]

Is there an upgrade path from the old targetcli 2.0 to the
new targetcli-fb and lio-fb?

Regards
Harri

Bug#838941: RFS: duperemove/0.11~beta3-3 ITP

[Adam Borowski]

On Mon, Sep 26, 2016 at 10:12:04PM +0100, peter.zahrad...@znik.sk wrote:
>  * Package name: duperemove

Uhm guys, what's the status on this?  Unless you upload by pretty much
today, there's little chance it will get into stretch -- the effective
freeze date is in unstable (ie, past NEW) by Dec 26, and those lazy
ftpmaster guys will sit with their families instead of working on our
packages...  Shameful lack of respect for our tardiness! :p

I use duperemove a lot, it'd be sad if it didn't make it into stretch.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#840589: Bug#848112: Python-skimage depends on unavailable package python-dask

[Andreas Tille]

Hi,

On Thu, Dec 22, 2016 at 10:04:22PM -0700, Stefan van der Walt wrote:
> OK by me, too.
> 
> On December 22, 2016 9:45:10 PM Yaroslav Halchenko 
> wrote:
> 
> >On December 22, 2016 4:52:41 PM EST, Andreas Tille  wrote:
> >>place were people who intend to help can effectively join the effort.
> >>This package is blocking invesalius from migrating to testing and
> >>chances are low that it will reach stretch.  So if the problem is to
> >>pick a team I'll move it to Debian Science on 10 hours.  I really hope
> >>that this might push things if nothing is happening otherwise.
> >
> >I don't mind - move or NMU the fix

OK, thanks for the confirmation and as promised I created:

 https://anonscm.debian.org/git/debian-science/packages/skimage.git

Please note: I removed debian/gbp.conf and used the branches as
described in Debian Science policy.  If those Uploaders who finally work
on the package prefer a different layout please document this in
debian/README.source.

I also commited a patch that's simply skiping the tests mentioned in
#840589.  I do not really like this kind of "hiding eyes from problems"
workaround and thus I would not really close bug #840589 but IMHO it is
apropriate to lower its severity and work on later on this together with
upstream (those who intend to keep on maintaining the package please
open an upstream issue - will not continue here).

Ole, if you would please commit the patch you named in #848112 and
upload the package to make sure it can migrate right in time and will
enable other packages to migrate as well?

HOWEVER, we have another problem:  If I build the current state in Git
I'm running into:


==
ERROR: skimage.filters.rank.tests.test_rank.test_all
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
 line 16, in test_all
check_all()
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/testing.py",
 line 232, in inner
result = func(*args, **kwargs)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
 line 89, in check_all
rank.windowed_histogram(image, selem))
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
 line 986, in windowed_histogram
pixel_size=n_bins)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
 line 90, in _apply_vector_per_pixel
pixel_size=pixel_size)
  File 
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
 line 53, in _handle_input
out = np.empty(image.shape+(pixel_size,), dtype=out_dtype)
TypeError: 'numpy.float64' object cannot be interpreted as an index

--
Ran 1383 tests in 181.697s

FAILED (SKIP=54, errors=1)


I'm opening a bug against python-numpy to revert the transition that
has happened after the transition freeze (see #848758 for details).

Kind regards

 Andreas.


-- 
http://fam-tille.de

Bug#848732: g2clib: FTBFS: gcc: error: g2_unpack3.o: No such file or directory

[Lucas Nussbaum]

Hi,

On 22/12/16 at 09:08 +, Alastair McKinstry wrote:
> Hi,
> 
> Can you re-run this rebuild in your environment ? g2clib has built in
> all autobuilders (the day before), and I've retested
> locally both by hand, with pbuilder and sbuild, and its worked
> successfully. The log has no hint as to what failed; the
> .o files appeared to build, and then disappear - disk space?

You use debian/compat = 10, which means that dh will automatically build
in parallel.

g2clib builds fine with DEB_BUILD_OPTIONS=parallel=1

The machine I'm using has 64 cores. You might be able to reproduce the
failure by setting DEB_BUILD_OPTIONS=parallel=n with a high enough
value. 16 seems to be enough to get it to fail.

Lucas

Bug#847698: pgloader FTBFS on arm64: The value 64 is not of type (INTEGER -32 63)

[Christoph Berg]

Re: Adrian Bunk 2016-12-10 
<148139247737.5151.15852766254365495913.reportbug@localhost>
> ;; loading system "pgloader"
> Fatal TYPE-ERROR:
>   The value
> 64
>   is not of type
> (INTEGER -32 63)

After some poking this turned out to be a bug in sbcl on arm64.
Upstream plans to fix it tomorrow.

Christoph

Bug#845750: postfix: Cleanup does not see the postfix-pcre.so.1.0.1 file (and probably others libraries)

[Cyril Chaboisseau]

Package: postfix-pcre
Version: 3.1.3-6
Followup-For: Bug #845750

Hello,

Just for your information, the bug still exists in postfix-pcre 3.1.3-6
and I could not make it disappear by un-chrooting the different parts in
the master.cf (and all the comments/informations in the ticket could not
help either)
n.b. : I don't have a pcre directory in /etc/postfix

in my case, the problem appeared when upgrading from 3.1.3-4 and I had
to downgrade in order to have a well functioning postfix again

let me know if you want that I test other possibilities to solve this
bug
in my opinion, the gravity should be raised as it renders postfix
unusable (bouncing mails) because the header_checks does not work

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (90, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16-2-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages postfix-pcre depends on:
ii  libc6 2.24-8
ii  libpcre3  2:8.39-2
ii  postfix   3.1.3-6

postfix-pcre recommends no packages.

postfix-pcre suggests no packages.

-- no debconf information

Bug#848961: nano: please update syntax highlighting for nftables

[Benno Schulenberg]

On 2016-12-23 08:55, Arturo Borrero Gonzalez wrote:
> On 22 December 2016 at 19:17, Benno Schulenberg  wrote:
>> Have you also tried removing the \ from  \@?
> 
> Yes, it works too.

Thanks.  Committed and pushed: 2fbb71d5.  It will be in 2.7.3 next week.

Regards,

Benno

Bug#847804: libsane:amd64: please update to recent snapshot suporting lide 120

[Jörg Frings-Fürst]

Hello Michal,


thank you for spending your time helping to make Debian better with
this bug report. 


At the list[1] the Status of "CanoScan LiDE 120" is unsupported.

I think the best way is to ask the Upstream direct at[2].


CU
Jörg

[1] http://www.sane-project.org/sane-mfgs.html#Z-CANON
[2] http://lists.alioth.debian.org/mailman/listinfo/sane-devel

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#847804: libsane:amd64: please update to recent snapshot suporting lide 120

[Michal Suchanek]

Hello,

On 23 December 2016 at 10:02, Jörg Frings-Fürst
 wrote:

> At the list[1] the Status of "CanoScan LiDE 120" is unsupported.

That's technically true. AFAIK no SANE release supports it.

> I think the best way is to ask the Upstream direct at[2].

And with the build of upstream git snapshot provided at [3] it works for me.

> [1] http://www.sane-project.org/sane-mfgs.html#Z-CANON
> [2] http://lists.alioth.debian.org/mailman/listinfo/sane-devel
[3] 
https://build.opensuse.org/package/show/home:michals:debian/sane-backends-new

Thanks

Michal

Bug#848287: python-testing.mysqld: (build-)depends on mysql-{client,server}

[Dominik George]

Control: severity -1 important

Hi,

> Your package (build-)depends on mysql-server/client. Since we're
> transitioning to mariadb as the default mysql provider, you should
> switch your build dependencies and dependencies to something like:
> 
> default-mysql-server | virtual-mysql-server, default-mysql-client | 
> virtual-mysql-client
> 
> I have seen in your override that you have forwarded this upstream.
> I am filing this anyway to keep track of this along with the rest of the
> packages.

Lowering priority to important (you said "should").

As we are in a transition freeze and nothing along that lines will
happen to stretch, I do not see why this should remove
python-testing.mysqld and all packages that depend on it from testing.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#844543: new version available

[chrysn]

Source: aiocoap
Followup-For: Bug #844543

hello tin, 

i've recently released 0.3; that's probably late for stretch, but still
worth a try!

best regards
chrysn


signature.asc
Description: PGP signature

Bug#849174: RM: open-build-service [amd64 i386 arm64 armhf mips mips64el mipsel ppc64el s390] -- ANAIS; All binary packages that built from source package open-build-service no longer built on amd64,

[李健秋]

Package: ftp.debian.org
Severity: normal

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

Hello,

Started looking at this bug report yesterday but got discracted...

I spotted much the same issues as Chrisian so I'll instead just
echo what he's saying and add a few comments.
(I'll be able to sponsor you once the package is ready.)

On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
> Hi,
> 
> as announced on IRC, I'm just doing a review, since I'm not a DD
> and can't sponsor:
> 
>  - packaging in a VCS would be nice to have (plus the appropriate
>Vcs-Browser / Vcs-... headers in d/control)
> 
>  - debian/copyright:
> 
>  * Tobias Klauser wasn't just active in 2016, the earliest
>copyright notice of his I could find in the package is
>from 2014; so s/2016/2014-2016/ there
> 
>  * missing mention of Copyright (C) 2012 Christoph Jaeger
>for pkt.h
> 
>  * missing mention of Copyright (C) 2009-2012 Daniel
>Borkmann for util.[ch]

The debian/copyright issue is the only major reason I seen not to
upload right now, because this issue will possibly mean rejection
from NEW queue. Please carefully look at all source files
and document copyright holders (autogenerated build files can
be excluded).


> 
>  - debian/compat: why only 9? compat 10 is considered stable now
>and unless you have a good reason I would recommend that any new
>package should use compat 10. (please read the debhelper manual
>though for information on what changed between 9 and 10)

(compat 10 also gives you a nice automatic dh-autoreconf and
dh-systemd. Don't forget both to bump debian/compat and the
debhelper build-dependency.)

> 
>  - init.d: this file name works with dh_installinit, but is not
>documented, so I'd recommend using llmnrd.init as the file name

I see you're already credited by upstream so I assume you have
already established a good relationship with your upstream.
That's very good and very useful. Keep your upstream happy.
Upstreams like contributions. You have a golden opportunity 
on upstream issue #2.

> 
>  - init.d: any particular reason you don't use init-d-script? (See
>current /etc/init.d/skeleton for how this works; it will
>automatically source /etc/default/$scriptname and interpret the
>DAEMON_ARGS variable, so your init script could probably be just
>a couple of lines that set the name of the executable)

I'd recommend *against* "init-d-script". It has several outstanding
issues, is unmaintained/orphaned/unproven and AIUI that also means the
init script becomes debian-only.

> 
>  - any reason you don't install the systemd service provided by
>upstream in addition to the init script?

Please do. Please also consider improving the systemd service
shipped by upstream. (Another golden opportunity for upstream
contributions.)
Most importantly have a look at the User= directive as it seems
like running unprivilegied is preferred (see upstream issue #4).
See also the Restrict*= directives provided by systemd which
would also be nice to limit the potential attack surface.

> 
>  - debian/rules: nice and clean, I like it
> 
>  - upstream's build system does git id to get the git revision of
>the current source - but that will clash if you have the packaging
>in git (which can happen implicitly when someone checks out the
>package source via e.g. dgit)
> 
>Minor cosmetic thing, but makes the package non-reproducible
>depending on whether you build from unpacked .dsc or from a git
>environment
> 
>  - lintian warnings:
>W: llmnrd: binary-without-manpage usr/bin/llmnr-query
>W: llmnrd: binary-without-manpage usr/sbin/llmnrd
> 
> 
>  - you should probably add a line "export Q =" to debian/rules to
>disable silent builds. While these look nicer, automated build
>log scanners such as blhc aren't able to catch problems.

debhelper today automatically disables silent rules when building
on buildds. Using Q environment variables isn't the normal thing though.
Even better than to explicitly disable silent build would be to
hook up Q to the automatic debhelper version (V=1?).


> 
>  - Building in sbuild appears to work fine.
> 
>  - Package appears to work fine (though I don't have any llmnr
>device running at the moment, so I could only test name
>resolution of my own system)
> 
> Regards,
> Christian
> 


Regards,
Andreas Henriksson

Bug#849120: dgit-maint-merge(7): Use debian/source/patch-header

[Sean Whitton]

On Thu, Dec 22, 2016 at 06:56:05PM +, Sean Whitton wrote:
> Move the sample commands for obtaining a patch queue from README.source
> to debian/source/patch-header.

It also resolves a Lintian tag complaining about the DEP-3 template that
would otherwise be inserted as a patch header.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Raphael Hertzog]

On Wed, 21 Dec 2016, Ole Streicher wrote:
> I am quoting popcon here since they give a lower estimate of the number
> of users who actually did the test. Nothing more. Nothing about importance.

It gives an estimate of users who ran debootstrap and got the package
installed. It does not give an estimate of how many people ran
debian-installer and saw this menu.

> "Confusion" is not just something mythical that we can't see empirical.
> We will see it in help requests, blog posts, also bug reports, and other
> complaints. If the raise of confusion is "inacceptable" as stated here,
> I would really ask for some empirical evidence for this. At least, I did
> some homework by checking that no complaints popped up somewhere in the
> net (except the one I already mentioned).

Except that the persons who are installing a weekly build of testing
are advanced users that are less likely to be confused than the stable
users.

So while I like to be able to refer to real complains and real problem,
in this specific case it's hard to do so except when it's too late.

So I agree with Cyril and the d-i team, we should be cautious here.

Let's focus everybody's energy on getting Phil's patch merged instead
of continuing this discussion.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#849162: Issue will be addressed in snap package, please revert conflict in snapd

[Andreas Tille]

Hi,

while we are usually following a first comes first served policy if it
comes to name space conflicts I think it is apropriate to rename the
executable in the package snap to snap-hmm (and provide the original
name in /usr/lib/debian-med/bin which is used in other name space
conflicts).  I will do so quite soon to fix the bug in snap.

Please do not discriminate users of package snap by not beeing able to
install snapd and remove the non-policy conformant conflict in snapd.  I
think it would have been better to leave at least 24 hours for
discussing the issue even if we are quite near to the freeze.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#848903: Bug#848394: Bug#848903: metastudent: autopkgtests fail since 2016-12-05

[Andreas Tille]

On Tue, Dec 20, 2016 at 08:15:48PM +0100, Andreas Tille wrote:
> I just notice a commit from Tanya so according to the commit log
> the issue seems to be solved. :-)  (Well done! ;-) )

Hmm, I notice that while #848394 is really done bug #848903 with the
failed tests was not addressed.  Tanya, I think you confirmed some fix
via mail but did you really commited the change to SVN or am I missing
something?

Kind regards and thanks for your contribution anyway

Andreas.

-- 
http://fam-tille.de

Bug#848310: RM: targetcli -- ROM; superseded by targetcli-fb, from new LIO-fb upstream

[Harald Dunkel]

On 12/23/2016 09:19 AM, Ritesh Raj Sarraf wrote:
> On Fri, 2016-12-23 at 09:10 +0100, Harald Dunkel wrote:
>> Is there an upgrade path from the old targetcli 2.0 to the
>> new targetcli-fb and lio-fb?
> 
> No. This isn't supported in the packages. The upstream data format is also
> changed amongst LIO and the -fb fork.
> 

Good to know. Try-and-failure could have become much more expensive
than setting up a new iscsi host.

Regards
Harri



signature.asc
Description: OpenPGP digital signature

Bug#844583: sbuild: allow arbitrary version suffix for binary rebuild (binNMU)

[Johannes Schauer]

Hi,

Quoting Raphael Hertzog (2016-12-22 21:24:55)
> Thanks for your work on sbuild!

thank you! Your contributions are also very valued. :)

Since you mentioned making the text of the changelog entry user controllable,
maybe you are also interested in the upcoming --binNMU-changelog option which
lets you pass the *complete* new changelog entry to sbuild.

This option is added to support rebuilding binNMU-ed packages from buildinfo
files where the new changelog entry is stored in the Binary-Only-Changes field
and has to be passed to sbuild exactly in that format to make the build
byte-by-byte reproducible.

But depending on what you want to do, maybe this option is also for you?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#849149: bpfcc: FTBFS: FlexLexer.h: No such file or directory

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2016-12-22 at 18:42 -0500, Aaron M. Ucko wrote:
> Builds of bpfcc in minimal environments (notably, the autobuilders)
> have been failing:
> 
>   /«PKGBUILDDIR»/src/cc/frontends/b/lexer.h:22:23: fatal error: FlexLexer.h:
> No such file or directory
> 
> Please declare a build dependency on libfl-dev, on which flex no
> longer depends so that it can properly be Multi-Arch: foreign.  (See
> #840080.)
> 

Thanks Aaron. This is done but I have other build failures on i386 arch which is
blocking the upload.

https://github.com/iovisor/bcc/issues/873

> Thanks!
> 
> FTR, I'm filing this bug as a regression because it would interfere
> with binNMUs.

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhc5q4ACgkQpjpYo/Lh
dWnoww/5Abbij7k877sN7MU9+WrezXN1M+jalZehAy+hoPnnJgsdxy3objfNX3kf
VLSVH3MKAz+zTqvss+qEyPmrOFPgk3MIQSUs36Fa+jOCRCbJut4DGwwdttyF7m+M
aS5t9Kl4lJl54VyrqD9HgVbZMf9ZO8ZxP6XS8CnlphhDJsKInNUugFU+wNN+k+Wd
q8zQUwbL35vQifcSIneQou/hZY3Vu+KjR5QXOoLLp74iabariGizqiE2clUnUoqw
bjy+HCBDZU8UNLJFQzcBFJbbOo5stIJEa9oj19b/G8DYTCmliEVT+zE204QDeSc3
RKi1f367cq69xRDw/xpWeAu7eEbkT+GDYGlbwjxdrqrCx/sM8XJUH1m1qAX0s8wh
pc29+DHtz23m+gQ5mK6CMZ2IqMUhySmPYbf2Kv8hx34vfgyZhS6GilpCq/JSwi+R
lHNldT4XX2lcwwbSECVyX3EAxKodoA4/Jm85yst9Rn2queA8JmZicRSZH+jXRkHp
q5hdscC//HsTL/U2pKlPL51pngi48elrh/wHeu4wQfcd0wJB8j82zXawIxbzUNS4
v9S3+3ySKPNoZjkrQVBHtdgpPzYwkAHTu5KPARBz6HqalDX0GEC1/woEcN8SeJkc
sS6ih5OwI/l9aep9uVuNEW1h2LoAyGU8nF4JW7M6ClNQLBDNzzk=
=cCE8
-END PGP SIGNATURE-

Bug#849178: ITP: node-array-from -- ES2015 Array.from ponyfill

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-array-from
  Version : 2.1.1
  Upstream Author : Tomek Wiszniewski and Benjamin Barber
* URL : https://github.com/studio-b12/array-from#readme
* License : Expat
  Programming Lang: JavaScript
  Description : ES2015 Array.from ponyfill

 Node.js module providing a ponyfill (i.e. a polyfill that
 doesn't overwrite the native method) for the ES 2015 (ES6)
 Array.from().
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#831965: Status of asciidoc upload?

[Joseph Herlant]

Hi Raphael,

Thanks a lot for the upload. Unfortunately there were misses in the
copyright file.
I fixed that, retagged and pushed to the git repo and to mentors.
Let me know if you find anything else that need to be fixed.

Thanks!
Joseph

Bug#849173: ondir: FTBFS on hurd due to PATH_MAX

[Christian Seiler]

Package: ondir
Version: 0.2.3+git0.55279f03-1
Severity: important
Tags: confirmed

(Recording this so I don't forget it.)

ondir FTBFS on Hurd because it uses PATH_MAX, which isn't available
there (Hurd has no path limit).

Build log:
https://buildd.debian.org/status/fetch.php?pkg=ondir=hurd-i386=0.2.3%2Bgit0.55279f03-1=1482457296

I plan on doing an update for this at the beginning of the Buster
release cycle. (I don't want to mess things up by patching this in
Stretch so close to the freeze.)

Regards,
Christian

Bug#849172: ondir: don't override Makefile variables, pass CFLAGS as environment variables instead

[Christian Seiler]

Package: ondir
Version: 0.2.3+git0.55279f03-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: Gianfranco Costamagna 

CFLAGS etc. should be passed in via environment variables (so that
dh_auto_build etc. work out of the box without an override), but
that needs changes to upstream's Makefile.

Once ondir has entered Stretch I plan on sending a pull request
upstream that updates the Makefile, and to package a new version
with a simpler debian/rules. Maybe that will even happen in time
before the Stretch freeze, but that is unclear.

Regards,
Christian

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Pali Rohár]

Hi! Now I uploaded new version to mentors.

On Friday 23 December 2016 10:18:52 Andreas Henriksson wrote:
> Hello,
> 
> Started looking at this bug report yesterday but got discracted...
> 
> I spotted much the same issues as Chrisian so I'll instead just
> echo what he's saying and add a few comments.
> (I'll be able to sponsor you once the package is ready.)
> 
> On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
> > Hi,
> > 
> > as announced on IRC, I'm just doing a review, since I'm not a DD
> > 
> > and can't sponsor:
> >  - packaging in a VCS would be nice to have (plus the appropriate
> >  
> >Vcs-Browser / Vcs-... headers in d/control)
> >  
> >  - debian/copyright:
> >  * Tobias Klauser wasn't just active in 2016, the earliest
> >  
> >copyright notice of his I could find in the package is
> >from 2014; so s/2016/2014-2016/ there
> >  
> >  * missing mention of Copyright (C) 2012 Christoph Jaeger
> >  
> >for pkt.h
> >  
> >  * missing mention of Copyright (C) 2009-2012 Daniel
> >  
> >Borkmann for util.[ch]
> 
> The debian/copyright issue is the only major reason I seen not to
> upload right now, because this issue will possibly mean rejection
> from NEW queue. Please carefully look at all source files
> and document copyright holders (autogenerated build files can
> be excluded).

Should be fixed now.

> >  - debian/compat: why only 9? compat 10 is considered stable now
> >  
> >and unless you have a good reason I would recommend that any new
> >package should use compat 10. (please read the debhelper manual
> >though for information on what changed between 9 and 10)
> 
> (compat 10 also gives you a nice automatic dh-autoreconf and
> dh-systemd. Don't forget both to bump debian/compat and the
> debhelper build-dependency.)

dh_make just generate template with debhelper 9.

dh-autoreconf is useless here as this package does not use any autoconf 
or automake. There is just plain Makefile.

Anyway, changed to debhelper 10.

> >  - init.d: this file name works with dh_installinit, but is not
> >  
> >documented, so I'd recommend using llmnrd.init as the file name
> 
> I see you're already credited by upstream so I assume you have
> already established a good relationship with your upstream.
> That's very good and very useful. Keep your upstream happy.
> Upstreams like contributions. You have a golden opportunity
> on upstream issue #2.

Renamed to llmnrd.init.

> >  - init.d: any particular reason you don't use init-d-script? (See
> >  
> >current /etc/init.d/skeleton for how this works; it will
> >automatically source /etc/default/$scriptname and interpret the
> >DAEMON_ARGS variable, so your init script could probably be just
> >a couple of lines that set the name of the executable)
> 
> I'd recommend *against* "init-d-script". It has several outstanding
> issues, is unmaintained/orphaned/unproven and AIUI that also means
> the init script becomes debian-only.

Init script I used from old template provided by Debian and slightly 
modified it. As llmnrd does not generate pidfile, I used start-stop-
daemon with -b and -m args.

So I cannot use init-d-script easily.

Maybe I can report feature request to upstream to include support for 
creating pid file. And together with support for forking, start-stop-
daemon can be used without -b -m.

> >  - any reason you don't install the systemd service provided by
> >  
> >upstream in addition to the init script?
> 
> Please do. Please also consider improving the systemd service
> shipped by upstream. (Another golden opportunity for upstream
> contributions.)
> Most importantly have a look at the User= directive as it seems
> like running unprivilegied is preferred (see upstream issue #4).
> See also the Restrict*= directives provided by systemd which
> would also be nice to limit the potential attack surface.

Reasons why I did not install systemd service file:

1) it is not installed by make install, so I forgot about it

2) it is not fully compatible with provided init.d script

3) I'm not familiar with systemd (not even big fan)

Init.d script loads additional args from /etc/default/llmnrd DAEMON_OPTS 
and there is specified default argument -6 which enabled IPv6 support.

I hope Debian is already IPv6 ready and enabling IPv6 support is useful 
in Debian.

1) is not a problem for me, but 3) discredit me to properly handle 
DAEMON_OPTS from /etc/default/llmnrd properly.

Anyway, current init script is working fine with systemd, so missing 
systemd service file is not a problem for using llmnrd.

I would rather have IPv6 support as systemd service file.

If somebody want to improve systemd service file I will let this part...

> >  - debian/rules: nice and clean, I like it
> >  
> >  - upstream's build system does git id to get the git revision of
> >  
> >the current source - but that will clash if you have the
> >packaging in 

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Pali Rohár]

On Friday 23 December 2016 11:28:39 Pali Rohár wrote:
> > >  - debian/compat: why only 9? compat 10 is considered stable now
> > >  
> > >and unless you have a good reason I would recommend that any
> > >new package should use compat 10. (please read the debhelper
> > >manual though for information on what changed between 9 and
> > >10)
> > 
> > (compat 10 also gives you a nice automatic dh-autoreconf and
> > dh-systemd. Don't forget both to bump debian/compat and the
> > debhelper build-dependency.)
> 
> dh_make just generate template with debhelper 9.
> 
> dh-autoreconf is useless here as this package does not use any
> autoconf or automake. There is just plain Makefile.
> 
> Anyway, changed to debhelper 10.

Now lintian on mentors shows warning:

package-uses-experimental-debhelper-compat-version
10

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


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

Bug#839371: xine-lib-1.2: FTBFS: ./src/video_out/video_out_xcbshm.c:723: undefined reference to `xcb_poly_fill_rectangle'

[harald]

Dear Debian Maintainer,

https://anonscm.debian.org/hg/xine-lib/xine-lib-1.2/rev/e72410d807a3
seems to fix this bug, but recreation of src/video_out/Makefile.in is
needed to get it working (btw. 1.2.7 is out since two months but I guess
out of scope for Stretch).

Kind regards
Harald Jenny

Bug#849183: RM: blasr [i386 armel mipsel] -- ROM; new build-dependency not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


blasr has a new build-dependency (pbbam) that is not available on 32-bit
architectures.

Many thanks and regards
Afif

Bug#849187: RM: kmer-tools -- ROM; superceded by kmer

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


The source package has been renamed, so this old source package should
be removed. I noticed that this doesn't happen automatically if the source
package is renamed without a change in the upstream version, which is the
case here.

Many thanks and regards
Afif

Bug#841610: fixed in statsmodels 0.8.0~rc1+git59-gef47cd9-1

[Sebastiaan Couwenberg]

Hi Yaroslav,

On 11/28/2016 02:38 PM, Yaroslav Halchenko wrote:
> On Sun, 27 Nov 2016, Sebastiaan Couwenberg wrote:
> 
>> This bug is not fixed on i386 yet where the build failed due the various
>> test failures, specifically:
> 
>>  ValueError: I/O operation on closed file
> 
>> Is work in progress to fix this issue on i386 too?
> 
> this particular one iirc is due to a bug in pandas, which was fixed but
> build on i386 fails for other reason due to PyTables [1], which I will
> ask to be included in debian package after (re)solution accepted
> upstream.  Then hopefully we would get to the finishing line with
> pandas, and thus statsmodels
> 
> [1] https://github.com/PyTables/PyTables/pull/587

I see that the PR was merged, is a fix for the Debian package in the works?

pandas and its reverse dependencies are still marked for removal from
testing on January 5th, which is also the date for the Soft Freeze after
which removed packages won't be allowed back into testing.

No having pandas and geopandas in stretch would be sad.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#848708: atop: cronjob to rotate file should be smarter

[Marc Haber]

Hi Philipp,

thanks for your bug report.

On Mon, Dec 19, 2016 at 07:17:23PM +0100, Ph. Marek wrote:
> When using "atop" on a machine that's not running 24/7, the cronjob at 
> 00:00 is not run more often than not (depending on your usage pattern, of 
> course ;). This makes some use of "atop" harder than necessary; "atop -r y" 
> doesn't work, you'll need the right amount of "y"esterdays to find the 
> right file.
> 
> So, either
>  1) the cronjob could be smarter, to check whether the date has 
> changed (and then would need to run every minute?),
>  2) or "atop" could be handling that (just open the file for every write, 
> ie. by default every 600 seconds, with the correct path newly 
> calculated), 
>  3) or things like suspend/resume could signal atop to start a new file.
> 
> I guess option 2 would be the easiest one to implement, and the most likely 
> to be correct.

I do agree. I will forward this upstream for consideration for a later
release. I will, however, only do this after a more current atop has
arrived in testing - as this behavior is not a regression, which means
that the issue you're reporting won't be fixed in time for stretch
anyway.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#849193: RFS: hoteldruid/2.2.0-1

[Marco M. F. De Santis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "hoteldruid":

* Package name: hoteldruid
  Version : 2.2.0-1
  Upstream Author : Marco M. F. De Santis
* URL : http://www.hoteldruid.com
* License : AGPLv3
  Section : web

It builds those binary packages:

  hoteldruid - web-based property management system for hotels or B

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


  http://mentors.debian.net/package/hoteldruid

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

dget -x 
http://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.2.0-1.dsc


More information about hoteldruid can be obtained from 
http://www.hoteldruid.com.


Changes since the last upload:

  * New upstream release. (Closes: #699184)
  * debian/po: include new template translations
 + pt_BR.po: Brazilian Portuguese by Adriano Rafael Gomes. (Closes: 
#839275)

  * Added /usr/share/appdata/hoteldruid.appdata.xml for hoteldruid-launcher

Regards,
Marco M. F. De Santis

Bug#849195: ITP: uvloop -- fast implementation of asyncio event loop on top of libuv

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski 

* Package name: uvloop
  Version : 0.6.7
  Upstream Author : Yury Selivanov 
* URL : http://github.com/MagicStack/uvloop
* License : MIT
  Programming Lang: Python
  Description : Fast implementation of asyncio event loop on top of libuv

 uvloop is a fast, drop-in replacement of the built-in asyncio
 event loop. uvloop is implemented in Cython and uses libuv
 under the hood. It makes asyncio 2-4x faster.

Binary package names: python3-uvloop python3-uvloop-dbg

Bug#845750: postfix: Cleanup does not see the postfix-pcre.so.1.0.1 file (and probably others libraries)

[Scott Kitterman]

On Friday, December 23, 2016 09:09:03 AM Cyril Chaboisseau wrote:
> Package: postfix-pcre
> Version: 3.1.3-6
> Followup-For: Bug #845750
> 
> Hello,
> 
> Just for your information, the bug still exists in postfix-pcre 3.1.3-6
> and I could not make it disappear by un-chrooting the different parts in
> the master.cf (and all the comments/informations in the ticket could not
> help either)
> n.b. : I don't have a pcre directory in /etc/postfix
> 
> in my case, the problem appeared when upgrading from 3.1.3-4 and I had
> to downgrade in order to have a well functioning postfix again
> 
> let me know if you want that I test other possibilities to solve this
> bug
> in my opinion, the gravity should be raised as it renders postfix
> unusable (bouncing mails) because the header_checks does not work

I don't have an immediate suggestion.  I have some other improvements I'm 
working on that may help with this as a side effect.  I'd like to try those 
first.

Since it's only the milter header checks that don't work and not all of them, 
the package is not unusable.  This shouldn't be more than important and is 
probably more appropriately normal severity.

Scott K

Bug#849169: [buildd-tools-devel] Bug#849169: sbuild: Expect programe reported "no more ptys" and failed in rebuilding gcc with normal (non-root) user

[Johannes Schauer]

Control: tag -1 + unreproducible

Hi,

Quoting Xiangyu LIU (2016-12-23 07:36:00)
>I want to rebuild locally gcc-5 and gcc-4.9 in current stretch by Sbuild.
> 
> 
>I download the source of gcc-5 (Debian) and gcc-4.9 (from Ubuntu) and 
> rebuild by "sbuild -d stretch gcc-x.dsc".
>But building failed with reporting:
>   "The system has no more ptys. Ask your system administrator to create 
> more."
>   "while executing"
>   "spawn ls"
> 
>I gave a try in Sbuild with root user:
># expect -c "spawn ls"
>It is OK to output "spawn ls"
> 
>But when I type above command with normal user:
>sh-4.4$ expect -c "spawn ls"
>spawn ls
>The system has no more ptys.  Ask your system administrator to 
> create more.
>while executing
>"spawn ls"
> 
>I check the /dev/pts, it was mounted in sbuild (with both root/normal 
> users):
> sh-4.4$ mount | grep pts
> devpts on /dev/pts type devpts 
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> 
> (stretch-amd64-sbuild)root@WFA256:/# mount | grep pts
>  devpts on /dev/pts type devpts 
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> 
>   
>I have same issue in pbuilder if I rebuild gcc by:
>   $ sudo pbuilder build gcc-.dsc
> 
>But it is OK if rebuild with root user by sbuild
>   $ sudo sbuild -d stretch gcc-.dsc
> 
> 
>Yes I can rebuild gcc by sudo sbuild, but I don't know what is happening 
> in Sbuild with normal user.
>Any comment or advice would be very appreciated !

I cannot reproduce your issue in several ways.

 - 'expect -c "spawn ls"' works for me independent of whether I'm root or not
 - building src:gcc-5 works fine on my system inside a stretch chroot without
   being root
 - building src:gcc-5 works fine on the Debian buildds
   https://buildd.debian.org/status/package.php?p=gcc-5

Since you have the same issue with pbuilder, this does not seem to be an sbuild
specific bug. Instead this could either be:

 - a FTBFS bug in src:gcc-5 (but that's unlikely because I just successfully
   built it on stretch)
 - a misconfiguration of your system

I fear you have to ask elsewhere for advice as I am not familiar with the gcc
build system or show me that this really is a bug in sbuild.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#849054: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#849054: Removed package(s) from unstable)

[Scott Kitterman]

On Friday, December 23, 2016 12:36:30 PM Adam D. Barratt wrote:
> On Fri, 2016-12-23 at 13:04 +0100, Axel Beckert wrote:
> > Control: reopen -1
> > 
> > Hi,
> > 
> > Fathi Boudra wrote:
> > > > In which case it presumbaly wants removing from unstable?
> > > 
> > > from unstable and experimental. thanks.
> 
> [...]
> 
> > Please also remove that completely outdated package from experimental.
> 
> In my experience, the FTP Team generally prefer a single bug report to
> cover removal from a single suite, with multi-suite removal involving
> multiple bug reports (similarly to multi-source removals).

Yes.  Please.

Scott K

Bug#845750: postfix: Cleanup does not see the postfix-pcre.so.1.0.1 file (and probably others libraries)

[Cyril Chaboisseau]

Package: postfix-pcre
Followup-For: Bug #845750

I take back what I said this morning:
the downgrade did NOT solved the problem

actually, here is the kind of errors I had in the mail.info file:

Dec 23 12:40:43 cerber postfix/cleanup[11472]: warning: unsupported dictionary 
type: pcre (no/postfix-pcre.so.1.0.1: No such file or directory)

and what I did not noticed, is the "no/..." when trying to load the file

my problem is I had the following in the main.cf
shlib_directory = no

which is apparently something that I picked up from the following ticket
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815070#26

so, I just had to be replace with the right directory:
shlib_directory = /usr/lib/postfix


and now, everything's fine


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (90, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16-2-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages postfix-pcre depends on:
ii  libc6 2.24-8
ii  libpcre3  2:8.39-2
ii  postfix   3.1.3-6

postfix-pcre recommends no packages.

postfix-pcre suggests no packages.

-- no debconf information

Bug#849198: libxml2: CVE-2016-9596: stack exhaustion while parsing xml files in recovery mode

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.4+dfsg1-2.1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for libxml2.

CVE-2016-9596[0]:
stack exhaustion while parsing xml files in recovery mode

Unfortunately apart the bug [1] which only states "stack exhaustion
while parsing xml files in recovery mode" there is no further
information about this vulnerability. I tried ask Red Hat folks if
there is more information available.

This bug should help to start tracking this issue.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9596
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9596
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1408302

Regards,
Salvatore

Bug#840503: flowblade: Please package flowblade 1.10

[W. Martin Borgert]

Control: retitle -1 flowblade: Please package flowblade 1.10

1.10 has been released with nice improvements:

https://github.com/jliljebl/flowblade/blob/master/flowblade-trunk/docs/RELEASE_NOTES.md#flowblade-110

Bug#848826: More info. on vainfo

[shirish शिरीष]

Dear Sebastian,

Sorry for not replying earlier. Seems both your answers didn't reach
me. I was looking at the pkg-multimedia mailing list and found your
answers.

I am subscribing to the bug so this doesn't happen.

Replying to your queries -

a. So I guess you are not running this from a terminal running in X?

a. I AM running this from a terminal running in X.

b. Or you do not have i965-va-driver installed, which you should get
automatically
if you do not have recommends disabled.

b. Wrong again. I do have i965-va-driver installed.

$ aptitude search i965-va-driver
i   i965-va-driver
- VAAPI driver for Intel G45 & HD Graphics family

Please let me know if you need any more details.

I have been seeing this in videos I have been playing (and some refuse
to play at all which used to play earlier) -

(+) Video --vid=1 (*) (h264)
 (+) Audio --aid=1 --alang=und (*) (aac)
[vo/opengl] GLX not found.
[vo/opengl] GLX not found.
[vo/vdpau] Error when calling vdp_device_create_x11: 1
[vo/xv] No Xvideo support found.
[vo/sdl] SDL_CreateRenderer failed
[vo/sdl] SDL_CreateRenderer failed
[vo/sdl] SDL_CreateRenderer failed
[vo/sdl] SDL_CreateRenderer failed
[vo/sdl] No supported renderer
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva
error,driver_name=(null)
[vaapi] vaInitialize(): unknown libva error
[vo/x11] Warning: this legacy VO has bad performance. Consider fixing
your graphics drivers, or not forcing the x11 VO.

And this happens on different systems, one which needs and has the
i965-va-driver and the other one which is a much more dated system.

Dunno if this gives you any more clues or not. I am using mpv as my
video player.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#837068: glshim uploaded to mentors.debian.net

[Fathi Boudra]

Hi,

Your upload of the package 'glshim' to mentors.debian.net was
successful. Others can now see it. The URL of your package is:
https://mentors.debian.net/package/glshim

The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/main/g/glshim/glshim_0.42-1.dsc

Thanks.

Bug#849185: ITP: node-cli-cursor -- Toggle the CLI cursor

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-cli-cursor
  Version : 1.0.2
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/cli-cursor#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Toggle the CLI cursor

 Node.js module to toggle the CLI cursor; the cursor is gracefully
 restored if the process exits.
 .
 Node.js is an event-based server-side JavaScript engine.

It is required for node-inquirer (ITP: https://bugs.debian.org/848364)
which in turn is required by node-yarnpkg 0.18 (ITP:
https://bugs.debian.org/843021) and lerna
(https://wiki.debian.org/Javascript/Nodejs/Tasks/lerna), the latter is
necessary for babel-cli.

My intention is to package it within the javascript maintainers team.

The repo will be on alioth:
https://anonscm.debian.org/git/pkg-javascript/node-cli-cursor.git

Paolo

Bug#849138: atop installation fails, like meanwhile fixed upstream issue

[Martin Steigerwald]

Dear Vincent,

thank you for your report.

Please check whether atopacctd is still running?

You are upgrading from version 2.24 which had a bug in atopacctd that left it 
hanging around and only killable by SIGKILL.

The message "/run/pacct_shadow.d: File exists" hints at a still running 
atopacctd. This has been an upstream issue, which is fixed in atop 2.25 I 
think. I upgraded from atop 2.25 to 2.26 without any issue. Since for Jessie 
=> Stretch the upgrade will be between 1.26-2 and 2.26, I do not expect this 
issue to happen.

Additionally I do not agree with the severity of grave for this bug report. 
The package is definately usable. However I leave it to Marc, the maintainer of 
the atop package, to downgrade the severity to what he sees fits.

Thanks,
-- 
Martin

Bug#849138: atop installation fails

[Marc Haber]

severity #849138 normal
merge #849138 #842136
thanks

Hi Vincent,

this is the second time this week that you're filing a duplicate of an
already existing bug with a severely inflated severity. While I
appreciate your attention on atop, I would really love if you could
look whether the issue you're reporting already exists.

This being said, I do agree that #842136 is an issue that we should
look into, but I don't think it's a release stopper. The issue is
related to a bug in the version of atop being replaced, that has been
addressed with atop 2.2.5. I do doubt that this would happen when
you're upgrading from the ancient version that is currently in unstable.

I would appreciate if you could test that, by installing the version
from unstable and the upgrading to the current version in
experimental. That would _really_ help.

Geetings
Marc


On Thu, Dec 22, 2016 at 10:39:28PM +0100, Vincent Lefevre wrote:
> From: Vincent Lefevre 
> Subject: Bug#849138: atop installation fails
> To: Debian Bug Tracking System 
> Reply-To: Vincent Lefevre , 849...@bugs.debian.org
> Date: Thu, 22 Dec 2016 22:39:28 +0100
> X-Debian-PR-Package: atop
> X-Mailer-Info: https://www.vinc17.net/mutt/
> User-Agent: Mutt/1.7.1-6878-vl-r94147 (2016-11-29)
> 
> Package: atop
> Version: 2.2.6-1~exp1
> Severity: grave
> Justification: renders package unusable
> 
> # apt install atop/experimental
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Selected version '2.2.6-1~exp1' (Debian:experimental [amd64]) for 'atop'
> The following packages were automatically installed and are no longer 
> required:
> [...]
> The following packages will be upgraded:
>   atop
> 1 upgraded, 0 newly installed, 0 to remove and 51 not upgraded.
> Need to get 142 kB of archives.
> After this operation, 7168 B of additional disk space will be used.
> Get:1 http://ftp.de.debian.org/debian experimental/main amd64 atop amd64 
> 2.2.6-1~exp1 [142 kB]
> Fetched 142 kB in 0s (1082 kB/s)
> Retrieving bug reports... Done
> Parsing Found/Fixed information... Done
> Retrieving bug reports... Done
> Parsing Found/Fixed information... Done
> Reading changelogs... Done
> apt-listchanges: Do you want to continue? [Y/n] 
> (Reading database ... 505551 files and directories currently installed.)
> Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ...
> Unpacking atop (2.2.6-1~exp1) over (2.2.4-1~exp1) ...
> Setting up atop (2.2.6-1~exp1) ...
> Installing new version of config file /etc/cron.d/atop ...
> Installing new version of config file /etc/logrotate.d/psaccs_atop ...
> Installing new version of config file /etc/logrotate.d/psaccu_atop ...
> Job for atopacct.service failed because of unavailable resources or another 
> system error.
> See "systemctl status atopacct.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript atopacct, action "start" failed.
> ● atopacct.service - Atop process accounting daemon
>Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor 
> preset: enabled)
>Active: failed (Result: resources) since Thu 2016-12-22 22:35:09 CET; 8ms 
> ago
>  Docs: man:atopacctd(8)
>   Process: 24056 ExecStart=/usr/sbin/atopacctd (code=exited, status=0/SUCCESS)
>  Main PID: 619 (code=killed, signal=KILL)
> 
> Dec 22 22:35:09 cventin systemd[1]: Starting Atop process accounting daemon...
> Dec 22 22:35:09 cventin atopacctd[24056]: /run/pacct_shadow.d: File exists
> Dec 22 22:35:09 cventin systemd[1]: atopacct.service: PID file 
> /run/atopacc…tory
> Dec 22 22:35:09 cventin systemd[1]: Failed to start Atop process 
> accounting…mon.
> Dec 22 22:35:09 cventin systemd[1]: atopacct.service: Unit entered failed 
> state.
> Dec 22 22:35:09 cventin systemd[1]: atopacct.service: Failed with result 
> 'r…es'.
> Hint: Some lines were ellipsized, use -l to show in full.
> dpkg: error processing package atop (--configure):
>  subprocess installed post-installation script returned error exit status 1
> Processing triggers for systemd (232-8) ...
> Processing triggers for man-db (2.7.6.1-2) ...
> Errors were encountered while processing:
>  atop
> 
> Details about the error:
> 
> Dec 22 22:35:09 cventin systemd[1]: Starting Atop process accounting daemon...
> -- Subject: Unit atopacct.service has begun start-up
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> -- 
> -- Unit atopacct.service has begun starting up.
> Dec 22 22:35:09 cventin atopacctd[24056]: /run/pacct_shadow.d: File exists
> Dec 22 22:35:09 cventin systemd[1]: atopacct.service: PID file 
> /run/atopacctd.pid not readable (yet?) after start: No such file or directory
> Dec 22 22:35:09 cventin systemd[1]: Failed to start Atop process accounting 
> daemon.
> -- Subject: Unit atopacct.service has failed
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> -- 
> -- Unit atopacct.service has failed.
> -- 
> -- The result is 

Bug#838941: RFS: duperemove/0.11~beta3-3 ITP

[peter . zahradnik]

On 2016-12-17 22:27, Gianfranco Costamagna wrote:

Hello,

Files: interval_tree.c interval_tree_generic.h



Copyright: 2012 Michel Lespinasse 
License: GPL-2

which then below lists GPL-2 license with address: Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
However I can see that in interval_tree_generic.h itself is address:
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307  USA

What should I do?



ask upstream to fix the address :)

btw, I'm more interested in this change:
-License: GPL-2

+License: GPL-2+

at least for interval_tree_generic.h
(and add the License text too)



fixed, license text for GPL-2+ was already there
https://mentors.debian.net/debian/pool/main/d/duperemove/duperemove_0.11~beta4-1.dsc


For xxhash.c: In file is BSD 2-Clause and I have verified it in it's
upstream https://github.com/Cyan4973/xxHash/blob/dev/LICENSE so in
opyright file I have:

Files: xxhash.h xxhash.c
Copyright: 2012-2014 Yann Collet
License: BSD-2-Clause




I can't see any issue with license for this file. Please advise


Looks good to me... Not sure what I missed!

G.


Thanks

Bug#838976: libmonitoring-livestatus-perl: FTBFS: Failed 1/15 test programs. 0/118 subtests failed.

[Sebastiaan Couwenberg]

Control: tags -1 patch fixed-upstream

This issue has been fixed upstream with the attached patch cherry-picked
from the upstream git repository.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


0001-skip-threaded-test-on-perl-5.24-fixes-1.patch
Description: inode/symlink

Bug#842166: renewed sponsorship-request

[Willem Vermin]

I uploaded a new version of findent:

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

https://mentors.debian.net/debian/pool/main/f/findent/findent_2.7.3-1.dsc

The package is now build in chrooted sid.

Please have a look again.

Regards,

Willem

Bug#847659: #847659: [dma] postinst maintainer script fails

[Uli Schlachter]

On 19.12.2016 00:04, Christian Hofstaedtler wrote:
> Control: tags -1 + moreinfo
> 
> Dear Submitter,
> 
> I've quickly tried to reproduce your bug report, but failed to do
> so. Please provide more info.

I'm happy to do so, I just didn't have any good ideas on which
information. :-)

> Were you upgrading from a previous version? If so, which?

Yes. This started to happen during the upgrade from 0.11-1 to 0.11-1+b1.

Also, in the mean time the problem fixed itself for whatever reason.
According to dpkg.loa, configuring the package failed 11 times [1] and
the twelth attempt was successful.

I have no idea what caused this problem and I can no longer reproduce.
Feel free to close this report.

Cheers,
Uli

[1]:
$ grep 'configure dma:amd64 0.11-1+b1' /var/log/dpkg.log | wc -l
12

-- 
Homophobia - The fear that another man will treat you the way you treat
women.

Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages from init.d scripts

[Henrique de Moraes Holschuh]

On Sat, Dec 17, 2016, at 10:57, Andreas Henriksson wrote:
> The entire section is specific to sysvinit and already solved
> by LSB in that case. There's no point in reinventing LSB.

Then, instead of deleting it entirely, wouldn't it be better to replace
it with text directing maintainers to follow the relevant sections of
the LSB?

-- 
  Henrique de Moraes Holschuh 

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

Hi again Pali Rohár,

On Fri, Dec 23, 2016 at 11:29:59AM +0100, Pali Rohár wrote:
> Now lintian on mentors shows warning:
> 
> package-uses-experimental-debhelper-compat-version
> 10

Yes, lintian is simply wrong/outdated here. It's just a tool to help you
find issues, don't blindly follow lintian like if it was religion or
policy. Normally you'd consider a lintian override in cases where you
have confirmed lintian is wrong, but in this case the warning will
likely go away by itself if you just give it some time for new lintian
releases to appear.

More importantly I wanted to mention a detail which might be useful to
consider before uploading your package:

You use DAEMON_OPTS in the default file, while sysvinit seems to be
standardizing on DAEMON_ARGS  to avoid the messy work of later
migration of conffile settings you might want to consider switching to
DAEMON_ARGS now before the first version has been uploaded. You decide.

FYI, I also filed issues upstream for potential systemd service
improvements. #15, #16.
Shipping the file is as simple as running
"echo etc/llmnrd.service >> debian/llmnrd.install"
as dh compat 10 takes care of the rest for you.
You might want to consider dropping the attached patch in
debian/patches/ and adding debian/patches/series containing it's
name to preserve default file configuration under both init systems.

Regards,
Andreas Henriksson
--- a/etc/llmnrd.service
+++ b/etc/llmnrd.service
@@ -4,7 +4,8 @@
 
 [Service]
 Type=simple
-ExecStart=/usr/sbin/llmnrd
+EnvironmentFile=-/etc/default/llmnrd
+ExecStart=/usr/sbin/llmnrd $DAEMON_OPTS $DAEMON_ARGS
 Restart=on-failure
 User=nobody
 Group=nogroup

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

Hello,

On Fri, Dec 23, 2016 at 11:18:03AM +0100, Christian Seiler wrote:
> Hi there,
> 
> sorry for the formatting, writing this on my phone.
> 
> 
> Am 23. Dezember 2016 10:18:52 MEZ, schrieb Andreas Henriksson 
> :
[...]
> >on upstream issue #2.
> 
> I'm not sure that'll work. In contrast to systemd services init scripts are 
> necessarily very distro-dependent. You can hack together something that's 
> cross-distro, but that's really ugly.
[...]

If only looking at major distributions Debian is likely the only one
still using init scripts. OTOH apparently upstream thinks catering
for the niche distros is important enough to file a bug report
about it against his own software. Making the debian init script
more portable could just be seen as a future improvement IMO. :P

[...]
> IMHO init scripts are distro-dependent anyway (see above). I didn't know 
> about the issues in init-d-script and since I use that in my own packages, 
> I'll look into that. Any pointers?
[...]

See existing bug reports, many contain init-d-script in title at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sysvinit

My personal opinion is that for example breaking the LSB hooks
that redirects direct /etc/init.d/foo invokations to using systemctl
(which you really, really want to do when) under running systemd is
quite unfortunate (#826214, #826215). I also find it very unfortunate
that minor bugs that goes unfixed gets worked around depending on
implementation-specific ways which means that the more people who use
init-d-script the hard it will become to ever fix it up without breaking
all users which then relies on the exact current/previous
implementation.

I've already asked about rolling back to the old skeleton but
since noone is caring for sysvinit that has just ended up in void.
When this issue was brought up with dh-make maintainers they instead
decided to just completely drop sysvinit example. :/

If needed, we should probably discuss this further elsewhere as this
is getting off-topic for the llmnrd sponsorship bug report.

Regards,
Andreas Henriksson

Bug#849186: RM: pbseqlib [i386 armel mipsel] -- ROM; new build-dependency not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal
Control: block -1 with 849183 849184

pbseqlib is now built with pbbam, which is not available on 32-bit
architectures. I've also filed for removal of the reverse-dependencies on
these architectures for the same reason (see blocking bugs).

Many thanks and regards
Afif

Bug#846842: nethogs: please make the build reproducible

[Chris Lamb]

[Please retain 846...@bugs.debian.org in CC]

Hey Arnout,

Thanks for getting in touch and for your kind words on reproducible
builds. :)

> To me it doesn't sound unreasonable to consider the last segment of the
> build path part of the build environment

Could you elaborate why? We feel that the entire build path including
the basename(1) (or "last segment") to be:

  a) something up to the local package builder to decide.

  b) A poor method of storing metadata. It seems quite fragile and also
 non-intuitive; if a user searches the source tree for the version
 number, they won't actually find it within any of the files!

Our comprehensive testing framework deliberately varies this build path
to flush out these issues FYI.


Regards,

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

Bug#843531: diffoscope: walks through packages twice when comparing two .changes

[Chris Lamb]

tags 843531 + pending
thanks

Pushed to master:

  https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=f47459f


Regards,

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

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Control: reassign 848016 brltty-espeak


I still can confirm these issues (Debian testing, Brltty 5.4-3 and 
brltty-espeak 5.4-3). They also
occur after a fresh installation of Debian testing (minimal installation).  
Especially the speech
delay is a serious problem and should be addressed before the final release.

I currently run Brltty from the git repository (Rev BRLTTY-5.4-135-g9b144929) 
with the
libespeak-dev:amd64 version 1.48.04 package. That combination still works as 
expected (no delay and
no monotonous output).

Every two or three days I encounter a espeak crash. That means, that Brltty 
still works but the
speech output is killed. A simple restart of Brltty fixes that. In summer, when 
this issue occurred
for the first time, that crashes came much more often (about every 5 minutes). 
I don't know, why
that's much better now.

So far I didn't encounter such behavior with the brltty-espeak package from the 
Debian repositories,
which is linked against libespeak-ng. Therefore we may choose between the 
reproducible espeak-ng
problems and the old espeak crashes, which became much less common for no 
apparent reason.

I highly appreciate the espeak-ng development and I hope, that the delay and 
output problems can be
fixed there in time. But at the current situation, we have to find the least 
problematic solution
for the upcoming Debian release. Would the espeak crashes still occur much more 
often, the choice of
course would be, to link against espeak-ng. But under the condition, that the 
espeak crashes now
occur so infrequently, I think, that linking against the old espeak library is 
the less painful
solution for now.

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

On Fri, Dec 23, 2016 at 11:28:39AM +0100, Pali Rohár wrote:
> Hi! Now I uploaded new version to mentors.
> 
[...]
> So I cannot use init-d-script easily.
[...]

Thanks for following up with a good explanation for the choices
you make.

[...]
> Reasons why I did not install systemd service file:
[...]

You're ofcourse free to decide not to spend time on specific things,
but at the same time by integrating your package in a less than
optimal way with Debian you'll likely not attract as much interest
from potential sponsors.

Also, any network facing daemon really need to think about security
implications. Just running as root and not caring is in my opinion
not a good option.

Other options than using the systemd feature would be:
 * help upstream implement the privilegies dropping feature.
 * use start-stop-daemon to start under a less privilegied user.

Either way you'll need to implement the integration in your package
to create the less privilegied user. See adduser.

Not sure I'll consider this a blocker, but it's borderline for me.

Will review your new revision when I find time.

Regards,
Andreas Henriksson

Bug#849188: libmonitoring-livestatus-perl: VCS repository listed in the package does not exist

[Bas Couwenberg]

Source: libmonitoring-livestatus-perl
Version: 0.74-1
Severity: normal

Dear Maintainer,

The VCS repository listed in the package does not exist on ALioth:

 git://git.debian.org/pkg-nagios/pkg-libmonitoring-livestatus-perl.git

Please create the repository and push your local changes to Alioth.

Kind Regards,

Bas

Bug#848112: Python-skimage depends on unavailable package python-dask

[Ole Streicher]

Control: tags 848112 pending

Hi all,

On 23.12.2016 10:08, Andreas Tille wrote:
> Ole, if you would please commit the patch you named in #848112 and
> upload the package to make sure it can migrate right in time and will
> enable other packages to migrate as well?
> 
> HOWEVER, we have another problem:  If I build the current state in Git
> I'm running into:
> TypeError: 'numpy.float64' object cannot be interpreted as an index

I have a fix for both, and after a final test build, I will upload.

The package still seems to be in bad shape; during the docs generation
exceptions are thrown like

ValueError: 3-dimensional arrays must be of dtype unsigned byte,
unsigned short, float32 or float64
TypeError: 'numpy.float64' object cannot be interpreted as an index

They are ignored, however, but show that some work is still needed.

Cheers

Ole

Bug#758094: apt-listchanges: changelogs for tglase.lan.tarent.de

[Thorsten Glaser]

On Fri, 23 Dec 2016, root wrote:

>   * Disable assembly usage on x32. Related to Bug #758094.
> 
>  -- Andreas Boll   Thu, 15 Dec 2016 15:16:56 +0100

Thanks, this appears to help (at least, glxgears works now).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#845464: fixed in iptables 1.6.0+snapshot20161117-4

[Arturo Borrero Gonzalez]

Hi,

this seems fixed in iptables/libxtables12 1.6.0+snapshot20161117-4, isn't it?

Please, confirm and close the bug.

Bug#849034: broadcom-sta-dkms: Can't connect to wireless, regression

[Eduard Bloch]

Control: severity 849034 important

Hallo,
* Lisandro Damián Nicanor Pérez Meyer [Wed, Dec 21 2016, 09:46:14PM]:
> Package: broadcom-sta-dkms
> Version: 6.30.223.271-5
> Severity: serious
> Justification: The package becomes unusable
> 
> I've found out that using the debian revision -5 of this package leaves
> me without being able to connect to any network, failing on every attempt.

It works for me and at least the guy who submitted the recent patch.

Are you using network-manager (probably even without knowing)?
Did you turn off MAC address randomization?

> If I downgrade to the -4 version I can get the WiFi to work again.

I doubt that this is the only reason. This driver is so buggy and
unpredictable that it's hard to attribute errors correctly.

Try adding

[device]
wifi.scan-rand-mac-address=no

to /etc/NetworkManager/NetworkManager.conf and rebooting.

Regards,
Eduard.

-- 
Every great idea is worthless without someone to do the work. --Neil Williams

Bug#849054: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#849054: Removed package(s) from unstable)

[Adam D. Barratt]

On Fri, 2016-12-23 at 13:04 +0100, Axel Beckert wrote:
> Control: reopen -1
> 
> Hi,
> 
> Fathi Boudra wrote:
> > > In which case it presumbaly wants removing from unstable?
> > 
> > from unstable and experimental. thanks.
[...]
> Please also remove that completely outdated package from experimental.

In my experience, the FTP Team generally prefer a single bug report to
cover removal from a single suite, with multi-suite removal involving
multiple bug reports (similarly to multi-source removals).

Regards,

Adam

Bug#849196: Sometimes, supress_warnings misses one of its attributes

[Ole Streicher]

Package: src:python-numpy
Severity: serious
Version: 1:1.12.0~b1-1
X-Debbugs-Cc: debian-scie...@lists.debian.org
Forwarded: https://github.com/numpy/numpy/issues/8413
Affects: src:skimage

When trying to compile skimage, I sometimes get the following error:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/transform/tests/test_integral.py",
line 46, in test_vectorized_integrate
assert_equal(expected, integrate(s, r0, c0, r1, c1))  # test deprecated
  File
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/transform/integral.py",
line 86, in integrate
warn("The syntax 'integrate(ii, r0, c0, r1, c1)' is "
  File
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/_warnings.py",
line 16, in warn
warnings.warn(message, stacklevel=stacklevel)
  File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line
2199, in _showwarning
self._orig_show(message, category, filename, lineno,
AttributeError: 'suppress_warnings' object has no attribute '_orig_show'

or

ERROR: test suite for 
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 229, in run
self.tearDown()
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 352, in tearDown
self.teardownContext(ancestor)
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 368, in
teardownContext
try_run(context, names)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
inspect.getargspec(func)
  File "/usr/lib/python3.5/inspect.py", line 1040, in getargspec
stacklevel=2)
  File "/usr/lib/python3/dist-packages/numpy/testing/utils.py", line
2199, in _showwarning
self._orig_show(message, category, filename, lineno,
AttributeError: 'suppress_warnings' object has no attribute '_orig_show'

Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages from init.d scripts

[Andreas Henriksson]

Hello Henrique de Moraes Holschuh,

Thanks for looking into this!

On Fri, Dec 23, 2016 at 11:56:36AM -0200, Henrique de Moraes Holschuh wrote:
> 
> 
> On Sat, Dec 17, 2016, at 10:57, Andreas Henriksson wrote:
> > The entire section is specific to sysvinit and already solved
> > by LSB in that case. There's no point in reinventing LSB.
> 
> Then, instead of deleting it entirely, wouldn't it be better to replace
> it with text directing maintainers to follow the relevant sections of
> the LSB?

Primarily that would be something I'd consider a "further improvement" that
could be added on top of the changes I've proposed.
This is (hopefully) not the last change to policy after all.

Fwiw, I'm hoping as much discussion as possible (including LSB) can happen
separately rather than extending this (and and every other policy change
proposal) into eternity (and thus never getting anywhere).

Secondly, from what I hear from LSB maintainer is that it's targeted for
(future) removal because it's considered obsolete these days. Thus I'm
not sure how much value it would be to struggle to get LSB documented
into policy and when we've finally reached that goal in a decade or so
LSB has already stopped existing as a package in Debian
(I might be overly pessimistic about the speed of policy changes but I'm
personally focused on trying to get rid of obsolete parts rather than
adding right now. Help welcome on the adding part or anywhere.)

I'm thus leaving it to someone else to consider (and coordinate with LSB
maintainers opinions on the topic) if LSB should be documented in
policy. The existing text though is not useful so should be removed IMHO.

As already mentioned, this is layed out as a patch series for policy
editors to pick and choose as they see fit. Feel free to leave patch 11
out (or use someone elses patch if one has been proposed as an
alternative).

Your feedback (as statements rather than questions) about each patch
in the series would be appreciated! Please second the ones you think
are good as they are. Please outright object to the ones you don't like
(and preferrably propose an alternative patch).

Regards,
Andreas Henriksson

Bug#811986: qwtplot3d: diff for NMU version 0.2.7+svn191-10.1

[Arto Jantunen]

Control: tags 811986 + pending

Dear maintainer,

I've prepared an NMU for qwtplot3d (versioned as 0.2.7+svn191-10.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Arto Jantunen

diff --git a/debian/changelog b/debian/changelog
index 2307d95a8148..78897e5515e0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+qwtplot3d (0.2.7+svn191-10.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Apply patch from Graham Inggs  to update symbols
+for gcc 6 (Closes: #811986)
+
+ -- Arto Jantunen   Fri, 23 Dec 2016 14:26:35 +0200
+
 qwtplot3d (0.2.7+svn191-10) unstable; urgency=medium
 
   * Disable qt5 library on architectures armel and armhf. 
diff --git a/debian/libqwtplot3d-qt4-0v5.symbols b/debian/libqwtplot3d-qt4-0v5.symbols
index c45435b68e59..bc8ac0b53ff2 100644
--- a/debian/libqwtplot3d-qt4-0v5.symbols
+++ b/debian/libqwtplot3d-qt4-0v5.symbols
@@ -243,10 +243,10 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER#
  _ZN5Qwt3D4Axis9setMajorsEi@Base 0.2.7
  _ZN5Qwt3D4Axis9setMinorsEi@Base 0.2.7
  _ZN5Qwt3D4AxisC1ENS_6TripleES1_@Base 0.2.7
- _ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7
  _ZN5Qwt3D4AxisC1Ev@Base 0.2.7
  _ZN5Qwt3D4AxisC2ENS_6TripleES1_@Base 0.2.7
- _ZN5Qwt3D4AxisC2ERKS0_@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D4AxisC2ERKS0_@Base 0.2.7
  _ZN5Qwt3D4AxisC2Ev@Base 0.2.7
  _ZN5Qwt3D4AxisD0Ev@Base 0.2.7
  _ZN5Qwt3D4AxisD1Ev@Base 0.2.7
@@ -268,7 +268,7 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER#
  _ZN5Qwt3D5ArrowD0Ev@Base 0.2.7
  _ZN5Qwt3D5ArrowD1Ev@Base 0.2.7
  _ZN5Qwt3D5ArrowD2Ev@Base 0.2.7
- _ZN5Qwt3D5Color12createVectorERSt6vectorINS_4RGBAESaIS2_EE@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D5Color12createVectorERSt6vectorINS_4RGBAESaIS2_EE@Base 0.2.7
  _ZN5Qwt3D5GL2QtEddd@Base 0.2.7
  _ZN5Qwt3D5Label11setPositionENS_6TripleENS_6ANCHORE@Base 0.2.7
  _ZN5Qwt3D5Label12devicefonts_E@Base 0.2.7
@@ -380,9 +380,9 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER#
  _ZN5Qwt3D6Plot3DD0Ev@Base 0.2.7
  _ZN5Qwt3D6Plot3DD1Ev@Base 0.2.7
  _ZN5Qwt3D6Plot3DD2Ev@Base 0.2.7
- _ZN5Qwt3D7MappingD0Ev@Base 0.2.7
- _ZN5Qwt3D7MappingD1Ev@Base 0.2.7
- _ZN5Qwt3D7MappingD2Ev@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D7MappingD0Ev@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D7MappingD1Ev@Base 0.2.7
+ (optional=templinst)_ZN5Qwt3D7MappingD2Ev@Base 0.2.7
  _ZN5Qwt3D8CellData5clearEv@Base 0.2.7
  _ZN5Qwt3D8CellDataD0Ev@Base 0.2.7
  _ZN5Qwt3D8CellDataD1Ev@Base 0.2.7
@@ -475,6 +475,7 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER#
  _ZNK5Qwt3D8LogScale8ticLabelEj@Base 0.2.7
  _ZNK5Qwt3D9CrossHair5cloneEv@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS2_S4_EERKS2_@Base 0.2.7
+ (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EE19_M_emplace_back_auxIJRKS2_EEEvDpOT_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EED1Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EED2Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D4AxisESaIS1_EED1Ev@Base 0.2.7
@@ -482,11 +483,14 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER#
  (optional=templinst)_ZNSt6vectorIN5Qwt3D4AxisESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D4RGBAESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPS1_S3_EEmRKS1_@Base 0.2.7
+ (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EE17_M_default_appendEm@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EED1Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EED2Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D6Plot3D5LightESaIS2_EEaSERKS4_@Base 0.2.7
+ (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base 0.2.7
+ (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE19_M_emplace_back_auxIJS1_EEEvDpOT_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIPdSaIS0_EEaSERKS2_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIS_IPdSaIS0_EESaIS2_EED1Ev@Base 0.2.7
@@ -496,9 +500,12 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER#
  (optional=templinst)_ZNSt6vectorIS_IjSaIjEESaIS1_EED2Ev@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIS_IjSaIjEESaIS1_EEaSERKS3_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIdSaIdEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPdS1_EERKd@Base 0.2.7
+ (optional=templinst)_ZNSt6vectorIdSaIdEE19_M_emplace_back_auxIJRKdEEEvDpOT_@Base 0.2.7
  (optional=templinst)_ZNSt6vectorIdSaIdEEaSERKS1_@Base 0.2.7
  

Bug#849177: Python-numpy transition breaks at least two packages

[Ole Streicher]

Hi all,

On 23.12.2016 11:19, Andreas Tille wrote:
> I'm also not sure and people who know better than me should feel free to
> close bug #849177.  I'd be really happy if there are better solutions to
> fix python-skimage in the next 36 hours.  My reading of the arguments in
> #849177 is that there are other reasons to revert the upgrade even
> without the additional problem - thus I was opening the bug report
> independently from other packages like python-skimage and python-skbio.

While the original FTBFS for skimage is solved now, I found another
problem with numpy 1.12 RC (and skimage) which I reported upstream:

https://github.com/numpy/numpy/issues/8413

Currently, this keeps up to get a version of skimage into Debian that
has a chance to migrate.

This is really very disappointing to run into those problems just a few
hours before the window for the stretch migration closes.

Sandro, could you please *immediately* rollback the numpy RC or at least
upload a version that otherwise solves all the regressions that are
still open? Please put a stable, working version of numpy that we all
can rely on. Time matters here.

Best regards

Ole (quite angry in the moment, sorry.)

Bug#849197: RFS: a2jmidid/8~dfsg0-2.1 [NMU]

[Fernando Seiti Furusato]

Package: sponsorship-request
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "a2jmidid"
This NMU is so it builds on ppc64el. The FTBFS bug report with the
patch have been open for quite some time now.

* Package name: a2jmidid
  Version : 8~dfsg0-2.1
  Upstream Author : Nedko Arnaudov 
* URL : http://home.gna.org/a2jmidid
* License : GPL-2
  Section : sound

It builds those binary packages:

  a2jmidid   - Daemon for exposing legacy ALSA MIDI in JACK MIDI systems

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/a2jmidid/a2jmidid_8~dfsg0-2.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * debian/patches:
- ppc64-sigsegv.patch: sigsegv.c: added condition to use ucontext.h
  for ppc64, which wasn't being covered. (Closes: #769141)

Thanks and regards,
Fernando

Bug#849177: Python-numpy transition breaks at least two packages

[Ghislain Vaillant]

On Fri, 2016-12-23 at 10:43 +0100, Andreas Tille wrote:
> Hi,
> 
> I have cloned bug #848758 where I suggested to revert the python-numpy
> transition which other posters agreed upon.  Besides breaking
> python-skbio I spotted another package python-skimage which fails with:
> 
> 
> ==
> ERROR: skimage.filters.rank.tests.test_rank.test_all
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
>  line 16, in test_all
> check_all()
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/testing.py",
>  line 232, in inner
> result = func(*args, **kwargs)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
>  line 89, in check_all
> rank.windowed_histogram(image, selem))
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
>  line 986, in windowed_histogram
> pixel_size=n_bins)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
>  line 90, in _apply_vector_per_pixel
> pixel_size=pixel_size)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
>  line 53, in _handle_input
> out = np.empty(image.shape+(pixel_size,), dtype=out_dtype)
> TypeError: 'numpy.float64' object cannot be interpreted as an index
> 
> --
> Ran 1383 tests in 181.697s

Sounds like the kind of bug upstream would be interested in getting
fixed. This implementation must be relying on an implicit integer type
for the overall shape of the filter. My initial guess would be that
pixel_size ends-up being a float rather than an int here?

Not sure whether it is worth reverting numpy for this. From a quick
search, it looks like skimage has had issues like this in the past.

Ghis

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Christian Seiler]

Hi there,

sorry for the formatting, writing this on my phone.


Am 23. Dezember 2016 10:18:52 MEZ, schrieb Andreas Henriksson 
:
>On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
>>  - init.d: this file name works with dh_installinit, but is not
>>documented, so I'd recommend using llmnrd.init as the file name
>
>I see you're already credited by upstream so I assume you have
>already established a good relationship with your upstream.
>That's very good and very useful. Keep your upstream happy.
>Upstreams like contributions. You have a golden opportunity 
>on upstream issue #2.

I'm not sure that'll work. In contrast to systemd services init scripts are 
necessarily very distro-dependent. You can hack together something that's 
cross-distro, but that's really ugly.

Also, Debian (+ derivatives) is just about the only major distro that still 
supports traditional init scripts, except for maybe Slackware: Gentoo always 
had their own thing that wasn't compatible.

RH had /etc/sysconfig instead of /etc/default and had different includes for 
helper functions, just to give an idea what differences there are. SuSE hat yet 
another include library. RH didn't support LSB headers but had similar headers 
based on chkconfig to express dependencies.

>>  - init.d: any particular reason you don't use init-d-script? (See
>>current /etc/init.d/skeleton for how this works; it will
>>automatically source /etc/default/$scriptname and interpret the
>>DAEMON_ARGS variable, so your init script could probably be just
>>a couple of lines that set the name of the executable)
>
>I'd recommend *against* "init-d-script". It has several outstanding
>issues, is unmaintained/orphaned/unproven and AIUI that also means the
>init script becomes debian-only.

IMHO init scripts are distro-dependent anyway (see above). I didn't know about 
the issues in init-d-script and since I use that in my own packages, I'll look 
into that. Any pointers?


>>  - any reason you don't install the systemd service provided by
>>upstream in addition to the init script?
>
>Please do. Please also consider improving the systemd service
>shipped by upstream. (Another golden opportunity for upstream
>contributions.)
>Most importantly have a look at the User= directive as it seems
>like running unprivilegied is preferred (see upstream issue #4).
>See also the Restrict*= directives provided by systemd which
>would also be nice to limit the potential attack surface.

Ack.

>>  - you should probably add a line "export Q =" to debian/rules to
>>disable silent builds. While these look nicer, automated build
>>log scanners such as blhc aren't able to catch problems.
>
>debhelper today automatically disables silent rules when building
>on buildds. Using Q environment variables isn't the normal thing
>though.
>Even better than to explicitly disable silent build would be to
>hook up Q to the automatic debhelper version (V=1?).


Yeah, probably do something like

ifneq($(V),1)
Q?=@
endif

instead of just

Q?=@

in upstream's Makefile.

That said: I concur that these are all minor issues that can be fixed later and 
that d/copyright is the only blocker for an upload. And if this is to go into 
Stretch, the upload needs to happen today.

Since Andreas is willing to sponsor I'd recommend fixing that issue immediately 
and after Jan. 5th when it is in Stretch to fix the rest.

Regards,
Christian

Bug#849177: Python-numpy transition breaks at least two packages

[Andreas Tille]

Hi Ghislain,

On Fri, Dec 23, 2016 at 10:02:33AM +, Ghislain Vaillant wrote:
> On Fri, 2016-12-23 at 10:43 +0100, Andreas Tille wrote:
> > Hi,
> > 
> > I have cloned bug #848758 where I suggested to revert the python-numpy
> > transition which other posters agreed upon.  Besides breaking
> > python-skbio I spotted another package python-skimage which fails with:
> > 
> > 
> > ==
> > ERROR: skimage.filters.rank.tests.test_rank.test_all
> > --
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
> > self.test(*self.arg)
> >   File 
> > "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
> >  line 16, in test_all
> > check_all()
> >   File 
> > "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/testing.py",
> >  line 232, in inner
> > result = func(*args, **kwargs)
> >   File 
> > "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
> >  line 89, in check_all
> > rank.windowed_histogram(image, selem))
> >   File 
> > "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
> >  line 986, in windowed_histogram
> > pixel_size=n_bins)
> >   File 
> > "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
> >  line 90, in _apply_vector_per_pixel
> > pixel_size=pixel_size)
> >   File 
> > "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
> >  line 53, in _handle_input
> > out = np.empty(image.shape+(pixel_size,), dtype=out_dtype)
> > TypeError: 'numpy.float64' object cannot be interpreted as an index
> > 
> > --
> > Ran 1383 tests in 181.697s
> 
> Sounds like the kind of bug upstream would be interested in getting
> fixed. This implementation must be relying on an implicit integer type
> for the overall shape of the filter. My initial guess would be that
> pixel_size ends-up being a float rather than an int here?

Yes, sure.  Any volunteer to submit the issue upstream?  Sorry, I will
not manage it in a sensible time frame.
 
> Not sure whether it is worth reverting numpy for this. From a quick
> search, it looks like skimage has had issues like this in the past.

I'm also not sure and people who know better than me should feel free to
close bug #849177.  I'd be really happy if there are better solutions to
fix python-skimage in the next 36 hours.  My reading of the arguments in
#849177 is that there are other reasons to revert the upgrade even
without the additional problem - thus I was opening the bug report
independently from other packages like python-skimage and python-skbio.

Kind regards

  Andreas.
-- 
http://fam-tille.de

Bug#849189: mini transition: libcec

[Bálint Réczey]

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

Dear Release Team,

I would like to update libcec in unstable to the 4.0 version because
kodi upstream switched to using it from kodi 17 beta 5. At the moment
kodi package is patched to use the older libcec 3 but this is an
undesirable divergence from upstream.

The mini transition would involve libcec and its single reverse
dependency, kodi, which I plan updating to beta6.

I'm aware of the transitions freeze but given the minimal impact and
risk of this transition I think it may get an exception.

Cheers,
Balint

Bug#840589: Bug#848112: Python-skimage depends on unavailable package python-dask

[Andreas Tille]

Hi Ole,

On Fri, Dec 23, 2016 at 12:14:07PM +0100, Ole Streicher wrote:
> 
> I have a fix for both, and after a final test build, I will upload.

Thanks a lot.  BTW, I'm fine if you close / lower severity of #849177.
 
Kind regards

   Andreas. 

-- 
http://fam-tille.de

Bug#849191: ITP: jimfs -- in-memory file system implementing the java.nio.file APIs

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 

* Package name: jimfs
  Version : 1.1
  Upstream Author : Google Inc.
* URL : https://github.com/google/jimfs
* License : Apache-2.0
  Programming Lang: Java
  Package source  : https://anonscm.debian.org/git/pkg-java/jimfs.git
  Description: in-memory file system implementing the java.nio.file APIs


Jimfs is an in-memory file system for Java 7 and above, implementing the
java.nio.file abstract file system APIs. Jimfs supports almost all the
APIs under java.nio.file. It supports:

Creating, deleting, moving and copying files and directories.
Reading and writing files with FileChannel or SeekableByteChannel,
InputStream, OutputStream, etc.
Symbolic links.
Hard links to regular files.
SecureDirectoryStream, for operations relative to an open directory.
Glob and regex path filtering with PathMatcher.
Watching for changes to a directory with a WatchService.
File attributes. Built-in attribute views that can be supported
include "basic", "owner", "posix", "unix", "dos", "acl" and "user". Do
note, however, that not all attribute views provide useful attributes.
For example, while setting and reading POSIX file permissions is
possible with the "posix" view, those permissions will not actually
affect the behavior of the file system.

Jimfs also supports creating file systems that, for example, use
Windows-style paths and (to an extent) behavior. In general, however,
file system behavior is modeled after UNIX and may not exactly match any
particular real file system or platform.

Bug#845701: marked as pending

[Thorsten Glaser]

Dominik George dixit:

>Bug #845701 reported by you has been fixed in the Git repository. You can
>see the changelog below, and you can check the diff of the fix at:
>
>
> http://git.debian.org/?p=pkg-remote/packages/xrdp.git;a=commitdiff;h=5143905

404 - No such project

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#848364: status of node-inquirer

[Paolo Greppi]

Hi,

the repo on alioth is up to date and builds fine if you install locally
all the dependencies missing to date.

These are on the way:
  name ITPRFS / NEW
- cli-width (^2.0.0)   849141 NEW today
- restore-cursor (^1.0.1)  849145 NEW today
- run-async (^2.2.0)   849147 NEW today

And these are pending (but the repos are up to date too):
- cli-cursor (^1.0.1)  849185 pending restore-cursor
- rx (^4.1.0)  848964 pending node-grunt-contrib-copy/uglify

We can't run the node-inquirer tests because they require mockery ...
but you can try it with:

  quilt push -a
  nodejs examples/pizza.js

It seems to work ...

Paolo

Bug#849034: broadcom-sta-dkms: Can't connect to wireless, regression

[Lisandro Damián Nicanor Pérez Meyer]

Hi Eduard!  Sorry for the loosy format, I'm on the phone.

I've closed the big short after I opened it, found out that downgrading
wpasupplicant did the trick.

However I'll try the NM tip you sent, maybe it's related.

Thanks a lot!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

El dic 23, 2016 9:36 AM, "Eduard Bloch"  escribió:

> Control: severity 849034 important
>
> Hallo,
> * Lisandro Damián Nicanor Pérez Meyer [Wed, Dec 21 2016, 09:46:14PM]:
> > Package: broadcom-sta-dkms
> > Version: 6.30.223.271-5
> > Severity: serious
> > Justification: The package becomes unusable
> >
> > I've found out that using the debian revision -5 of this package leaves
> > me without being able to connect to any network, failing on every
> attempt.
>
> It works for me and at least the guy who submitted the recent patch.
>
> Are you using network-manager (probably even without knowing)?
> Did you turn off MAC address randomization?
>
> > If I downgrade to the -4 version I can get the WiFi to work again.
>
> I doubt that this is the only reason. This driver is so buggy and
> unpredictable that it's hard to attribute errors correctly.
>
> Try adding
>
> [device]
> wifi.scan-rand-mac-address=no
>
> to /etc/NetworkManager/NetworkManager.conf and rebooting.
>
> Regards,
> Eduard.
>
> --
> Every great idea is worthless without someone to do the work. --Neil
> Williams
>

Bug#840246: closed by Pino Toscano <p...@debian.org> (krita 3.x just available in Debian)

[Gregor Riepl]

> Yesterday krita was finally accepted in the archive, from the NEW queue,
> and it's currently in experimental.
> It will be in unstable soon.

Awesome!
Thank you very much.

Bug#842239: Not fixed in 1.6.0-2, please reopen

[Roderich Schupp]

This bug is not fixed in 1.6.0-2.
I just (Dec 23, ~2pm) scanned a document and saved it as PDF. But the
metadata claims Dec 22, 1am:

$ pdfinfo /build/work/rsc2017.pdf
Title:  Urlaubsmeldung
Subject:NONE
Keywords:   NONE
Author: Roderich Schupp
Creator:gscan2pdf v1.6.0
Producer:   PDF::API2 2.030 [linux]
CreationDate:   Thu Dec 22 01:00:00 2016 CET
ModDate:Thu Dec 22 01:00:00 2016 CET

Moreover, the file's mtime was also set to this date:

$ stat /build/work/rsc2017.pdf
  File: /build/work/rsc2017.pdf
  Size: 86450   Blocks: 176IO Block: 4096   regular file
Device: 802h/2050d  Inode: 2490385 Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 2000/roderich)   Gid: ( 2000/roderich)
Access: 2016-12-23 14:18:39.636340759 +0100
Modify: 2016-12-22 01:00:00.0 +0100
Change: 2016-12-23 14:16:33.955023348 +0100
 Birth: -



Cheers, Roderich

Bug#849200: nagios-images: Outdated packaging

[Bas Couwenberg]

Source: nagios-images
Version: 0.8
Severity: normal
Tags: patch

Dear Maintainer,

The packaging for nagios-images is outdated as reported by lintian. An
ancient Standards-Version is used, and an extra-license-file false
positive is not addressed. The package also installs symlinks for
nagios3 which has been removed from unstable.

The attached patches resolve this issue.

Kind Regards,

Bas
>From b55b14fc2910e73afefcf6b6a835a296479499ca Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Fri, 23 Dec 2016 15:07:45 +0100
Subject: Update Vcs-* URLs for move to git.

---
 debian/changelog | 1 +
 debian/control   | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 881be09..02b0bbb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ nagios-images (0.9) UNRELEASED; urgency=medium
 
   * Team upload.
   * Restructure control file with cme.
+  * Update Vcs-* URLs for move to git.
 
  -- Bas Couwenberg   Fri, 23 Dec 2016 15:06:34 +0100
 
diff --git a/debian/control b/debian/control
index 2b1a4eb..511961c 100644
--- a/debian/control
+++ b/debian/control
@@ -6,8 +6,8 @@ Section: net
 Priority: optional
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.4
-Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-nagios/nagios-images/
-Vcs-Svn: svn://anonscm.debian.org/pkg-nagios/nagios-images/trunk/
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-nagios/pkg-nagios-images.git
+Vcs-Svn: https://anonscm.debian.org/git/pkg-nagios/pkg-nagios-images.git
 
 Package: nagios-images
 Architecture: all
-- 
2.1.4

>From cef9fb3b739c506e1a0b043b42016deb46c60cdd Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Fri, 23 Dec 2016 15:13:16 +0100
Subject: Update copyright file using copyright-format 1.0.

---
 debian/changelog |  1 +
 debian/copyright | 56 
 2 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c94259e..eb3d9df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,7 @@ nagios-images (0.9) UNRELEASED; urgency=medium
   * Restructure control file with cme.
   * Update Vcs-* URLs for move to git.
   * Enable parallel builds.
+  * Update copyright file using copyright-format 1.0.
 
  -- Bas Couwenberg   Fri, 23 Dec 2016 15:06:34 +0100
 
diff --git a/debian/copyright b/debian/copyright
index a4f2a2b..4b640ee 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,30 +1,30 @@
-Format-Specification: 
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall=196
-Packaged-By: Debian Nagios Maintainer Group 

-Packaged-Date: Thu,  6 Oct 2005 19:12:42 +0200
-Upstream-Source: ftp://ftp.debian.org/dists/unstable/main/source/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Contact: Debian Nagios Maintainer Group 

+Source: https://anonscm.debian.org/cgit/pkg-nagios/pkg-nagios-images.git
 
-Copyright (C) 2005  Debian Nagios Maintainer Group
-Copyright Bernhard Albler 
-Copyright Cook Garry 
-Copyright Didier LIROULET 
-Copyright Brad Werschler 
-Copyright Altinity 
+Files: *
+Copyright: 2005, Debian Nagios Maintainer Group
+ Bernhard Albler 
+ Cook Garry 
+ Didier LIROULET 
+ Brad Werschler 
+ Altinity 
+License: GPL-2+
 
-License:
-
-  This program is free software; you can redistribute it and/or modify
-  it under the terms of the GNU General Public License as published by
-  the Free Software Foundation; either version 2 of the License, or
-  (at your option) any later version.
-
-  This program is distributed in the hope that it will be useful,
-  but WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-  GNU General Public License for more details.
-
-  You should have received a copy of the GNU General Public License
-  along with this package; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
-
-On Debian systems, the complete text of the GNU General
-Public License can be found in `/usr/share/common-licenses/GPL'.
+License: GPL-2+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+ .
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY 

Bug#846842: Fwd: Re: Bug#846842: nethogs: please make the build reproducible

[Chris Lamb]

[Forwarding to BTS]

- Original message -
From: Arnout Engelen 
To: Chris Lamb 
Subject: Re: Bug#846842: nethogs: please make the build reproducible
Date: Fri, 23 Dec 2016 11:37:55 +0100

Hi Chris,

First off, thanks for your efforts in making the builds more reproducible,
this is an important topic.

I'm the upstream nethogs author/maintainer, and I'd like to see if there's
something more I can do to help.

'determineVersion.sh' indeed uses `pwd` (when building from outside git).
Indeed in general leaking the full build path into the artifact seems like
a bad idea (https://reproducible-builds.org/docs/build-path/). In this
particular case, though, I only use the last segment of the path to
determine the version.

To me it doesn't sound unreasonable to consider the last segment of the
build path part of the build environment (so I already consider the nethogs
build 'reproducible' in that regard). Do you have any thoughts on that?


Kind regards,

Arnout

On Sat, Dec 3, 2016 at 6:00 PM, Chris Lamb  wrote:

> Source: nethogs
> Version: 0.8.5-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: builpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0], we noticed
> that nethogs could not be built reproducibly.
>
> This is due to upstream's determineVersion.sh using the output
> of "pwd".
>
> Patch attached. It overrides from debian/changelog.
>
>
>  [0] https://reproducible-builds.org/


Regards,

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

Bug#849184: RM: pbdagcon [i386 armel mipsel] -- ROM; new build-dependency not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


pbdagcon (like blasr) has a new build-dependency on pbbam, which is not
available on 32-bit architectures.

Many thanks and regards
Afif

Bug#828351: inn2: FTBFS with openssl 1.1.0

[Marc Haber]

On Wed, Nov 30, 2016 at 09:36:25AM +0100, Marco d'Itri wrote:
> On Nov 29, Sebastian Andrzej Siewior  wrote:
> 
> > Please find attached a patch against the package which includes the
> > three three patches mentioned here and was sbuild tested.
> > Should I NMU it?
> NO! I have a new package ready, but it needs some mild testing.

If you upload to experimental, people could help with testing. It
would be a pity if inn2 would not be in stretch.

Greetings
Marc

Bug#849192: netcat-openbsd: different behaviour - outout vanished

[Cristian Ionescu-Idbohrn]

Package: netcat-openbsd
Version: 1.130-1
Severity: important

This is netcat-openbsd 1.105-7
--

Command line is:

$ echo 'ehlo itsme' | nc.openbsd host.example.com 25

The output is:

220 host.example.com ESMTP Postfix
250-host.example.com
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

The simple trace is:

  1  0.0  1.1.1.11 ? 1.1.1.1   TCP 74 47242?smtp(25) [SYN] Seq=0 
Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1188714834 TSecr=0 WS=128
  2  0.000130857   1.1.1.1 ? 1.1.1.11  TCP 74 smtp(25)?47242 [SYN, ACK] Seq=0 
Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1189398612 TSecr=1188714834 
WS=128
  3  0.000171694  1.1.1.11 ? 1.1.1.1   TCP 66 47242?smtp(25) [ACK] Seq=1 Ack=1 
Win=29312 Len=0 TSval=1188714834 TSecr=1189398612
  4  0.000539830  1.1.1.11 ? 1.1.1.1   SMTP 77 C: ehlo itsme
  5  0.000555726  1.1.1.11 ? 1.1.1.1   TCP 66 47242?smtp(25) [FIN, ACK] Seq=12 
Ack=1 Win=29312 Len=0 TSval=1188714834 TSecr=1189398612
  6  0.000682959   1.1.1.1 ? 1.1.1.11  TCP 66 smtp(25)?47242 [ACK] Seq=1 Ack=12 
Win=29056 Len=0 TSval=1189398612 TSecr=1188714834
  7  0.009776682   1.1.1.1 ? 1.1.1.11  SMTP 106 S: 220 host.example.com ESMTP 
Postfix
  8  0.009800662  1.1.1.11 ? 1.1.1.1   TCP 66 47242?smtp(25) [ACK] Seq=13 
Ack=41 Win=29312 Len=0 TSval=1188714836 TSecr=1189398615
  9  0.009807945   1.1.1.1 ? 1.1.1.11  SMTP 195 S: 250 host.example.com | 250 
PIPELINING | 250 SIZE 1024 | 250 VRFY | 250 ETRN | 250 ENHANCEDSTATUSCODES 
| 250 8BITMIME | 250 DSN
 10  0.009822556  1.1.1.11 ? 1.1.1.1   TCP 66 47242?smtp(25) [ACK] Seq=13 
Ack=171 Win=30336 Len=0 TSval=1188714836 TSecr=1189398615



This is netcat-openbsd 1.130-1
--

Same command line:

$ echo 'ehlo itsme' | nc.openbsd host.example.com 25

There is _no_ output.

It seems nc.openbsd is closing the socket before reading/showing
whatever host.example.com returns.  Note the two resets '[RST]'
bellow.

 11 25.973506450  1.1.1.11 ? 1.1.1.1   TCP 74 47246?smtp(25) [SYN] Seq=0 
Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1188721327 TSecr=0 WS=128
 12 25.973662894   1.1.1.1 ? 1.1.1.11  TCP 74 smtp(25)?47246 [SYN, ACK] Seq=0 
Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1189405106 TSecr=1188721327 
WS=128
 13 25.973690712  1.1.1.11 ? 1.1.1.1   TCP 66 47246?smtp(25) [ACK] Seq=1 Ack=1 
Win=29312 Len=0 TSval=1188721327 TSecr=1189405106
 14 25.973728427  1.1.1.11 ? 1.1.1.1   SMTP 77 C: ehlo itsme
 15 25.973747259  1.1.1.11 ? 1.1.1.1   TCP 66 47246?smtp(25) [FIN, ACK] Seq=12 
Ack=1 Win=29312 Len=0 TSval=1188721327 TSecr=1189405106
 16 25.973845701   1.1.1.1 ? 1.1.1.11  TCP 66 smtp(25)?47246 [ACK] Seq=1 Ack=12 
Win=29056 Len=0 TSval=1189405106 TSecr=1188721327
 17 25.974788937   1.1.1.1 ? 1.1.1.11  SMTP 106 S: 220 host.example.com ESMTP 
Postfix
 18 25.974817575  1.1.1.11 ? 1.1.1.1   TCP 54 47246?smtp(25) [RST] Seq=13 Win=0 
Len=0
  ^^^
 19 25.974872212   1.1.1.1 ? 1.1.1.11  SMTP 195 S: 250 host.example.com | 250 
PIPELINING | 250 SIZE 1024 | 250 VRFY | 250 ETRN | 250 ENHANCEDSTATUSCODES 
| 250 8BITMIME | 250 DSN
 20 25.974896332  1.1.1.11 ? 1.1.1.1   TCP 54 47246?smtp(25) [RST] Seq=13 Win=0 
Len=0
  ^^^

If I add the '-q1' option (wait one second after EOF on stdin) to the
command line:

$ echo 'ehlo itsme' | nc.openbsd -q1 host.example.com 25

then I get the expected output:

220 host.example.com ESMTP Postfix
250-host.example.com
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Note, no '[RST]' in the packet trace.

  1  0.0  1.1.1.11 ? 1.1.1.1   TCP 74 47742?smtp(25) [SYN] Seq=0 
Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1189159653 TSecr=0 WS=128
  2  0.000144981   1.1.1.1 ? 1.1.1.11  TCP 74 smtp(25)?47742 [SYN, ACK] Seq=0 
Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1189843431 TSecr=1189159653 
WS=128
  3  0.000173801  1.1.1.11 ? 1.1.1.1   TCP 66 47742?smtp(25) [ACK] Seq=1 Ack=1 
Win=29312 Len=0 TSval=1189159653 TSecr=1189843431
  4  0.000208860  1.1.1.11 ? 1.1.1.1   SMTP 77 C: ehlo itsme
  5  0.000338115   1.1.1.1 ? 1.1.1.11  TCP 66 smtp(25)?47742 [ACK] Seq=1 Ack=12 
Win=29056 Len=0 TSval=1189843432 TSecr=1189159653
  6  0.001715233   1.1.1.1 ? 1.1.1.11  SMTP 106 S: 220 host.example.com ESMTP 
Postfix
  7  0.001733564  1.1.1.11 ? 1.1.1.1   TCP 66 47742?smtp(25) [ACK] Seq=12 
Ack=41 Win=29312 Len=0 TSval=1189159653 TSecr=1189843432
  8  0.001875842   1.1.1.1 ? 1.1.1.11  SMTP 195 S: 250 host.example.com | 250 
PIPELINING | 250 SIZE 1024 | 250 VRFY | 250 ETRN | 250 ENHANCEDSTATUSCODES 
| 250 8BITMIME | 250 DSN
  9  0.001895568  1.1.1.11 ? 1.1.1.1   TCP 66 47742?smtp(25) [ACK] Seq=12 
Ack=170 Win=30336 Len=0 TSval=1189159653 TSecr=1189843432
 10  1.002139332  1.1.1.11 ? 1.1.1.1   TCP 66 47742?smtp(25) [FIN, ACK] Seq=12 
Ack=170 Win=30336 Len=0 

Bug#849054: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#849054: Removed package(s) from unstable)

[Axel Beckert]

Control: reopen -1

Hi,

Fathi Boudra wrote:
> > In which case it presumbaly wants removing from unstable?
> 
> from unstable and experimental. thanks.

Debian Bug Tracking System wrote:
> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
> 
>  qtemu |  1.0.5-2.1 | source, amd64, i386, kfreebsd-amd64, kfreebsd-i386, 
> powerpc

qtemu only has been removed from unstable, but is still present in
experimental.

This makes existing installations with the experimental repo listed in
sources.list to try to update qtemu to an uninstallable experimental
package dating back to 2009.

Please also remove that completely outdated package from experimental.

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

Bug#849194: right-mouse-utton menu is empty

[Roderich Schupp]

Package: gnome-shell-extension-system-monitor
Version: 31-1
Severity: important
Tags: upstream

Right-clicking on any system-monitor item in the desktop (e.g. a graph)
produces an empty menu und the following error in the logs:

Dec 22 22:54:32 macarthur gnome-shell[969]: JS ERROR: TypeError: St.Table is 
not a constructor

build_menu_info@/usr/share/gnome-shell/extensions/system-moni...@paradoxxx.zero.gmail.com/extension.js:115

Battery<.update_battery@/usr/share/gnome-shell/extensions/system-moni...@paradoxxx.zero.gmail.com/extension.js:923

wrapper@resource:///org/gnome/gjs/modules/lang.js:178


The packaged version in Debian (tag v31) is more than 2 years old.
This bug was fixed over a year ago (97cb07e). 
Please consider packaging a recent snapshot. I'm running master without
any problems.

Cheers, Roderich


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

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

Versions of packages gnome-shell-extension-system-monitor depends on:
ii  gir1.2-gtop-2.02.34.1-2
ii  gir1.2-networkmanager-1.0  1.4.4-1
ii  gnome-shell3.22.2-1

gnome-shell-extension-system-monitor recommends no packages.

gnome-shell-extension-system-monitor suggests no packages.

-- no debconf information

Bug#849205: Pending fixes for bugs in the libgd-barcode-perl package

[Jeremy Bicha]

On Fri, Dec 23, 2016 at 10:29 AM,
 wrote:
> Commit message:
>
> Add real package libgd-perl as first alternative in Depends.

Why are you keeping the alternate dependencies? They do not exist in
Debian stable (or unstable).

Thanks,
Jeremy Bicha

Bug#849210: ntopng: fails to start

[Aaron M. Ucko]

Package: ntopng
Version: 2.4+dfsg1-1
Severity: important

As of version 2.4, ntopng fails to start on my system.  I'm not sure
what specifically is going wrong; all I see in ntopng.log is

23/Dec/2016 10:38:43 [Ntop.cpp:1121] Setting local networks to 127.0.0.0/8
23/Dec/2016 10:38:43 [Redis.cpp:92] Successfully connected to redis 
127.0.0.1:6379@0
23/Dec/2016 10:38:43 [Ntop.cpp:1095] Parent process is exiting (this is normal)

System logs additionally show the ndpi "INTERNAL ERROR" from
https://github.com/ntop/ntopng/issues/638, but AFAICT this error
shouldn't be fatal, and rebuilding ndpi with upstream's patch applied
made no difference.

Could you please take a look?

Thanks!

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

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

Versions of packages ntopng depends on:
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libcurl3-gnutls  7.50.1-1
ii  libgcc1  1:6.2.1-5
ii  libgeoip11.6.9-4
ii  libhiredis0.13   0.13.3-2
ii  libjson-c3   0.12.1-1.1
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libmariadbclient18   10.0.28-2
ii  libndpi4 1.8-1
ii  libpcap0.8   1.8.1-3
ii  librrd8  1.6.0-1+b1
ii  libsqlite3-0 3.15.2-1
ii  libstdc++6   6.2.1-5
ii  libzmq5  4.1.5-2
ii  lsb-base 9.20161125
ii  ntopng-data  2.4+dfsg1-1
ii  redis-server 3:3.2.6-1
ii  zlib1g   1:1.2.8.dfsg-4

ntopng recommends no packages.

Versions of packages ntopng suggests:
pn  geoip-database-contrib  

-- no debconf information

Bug#849154: ITP: xattrvi -- easily view and edit extended filesystem attributes in user-namespace

[Jonas Große Sundrup]

Am 23.12.2016 um 09:47 schrieb bugs-deb...@antipoul.fr:
>> * URL : https://github.com/cherti/mailexporter
> The correct URL seems to be https://github.com/cherti/xattrvi

Oops, you are absolutely right. Slipup of mine when filing the ITP, it
it will be correct in the package. Thanks for pointing out!


> Interesting piece of software though.

Thanks, I'll try to still get it into stretch, we'll see. :)


  ~ Jonas

Bug#849212: msgpuck: CVE-2016-9036: Invalid handling of map16 format in mp_check()

[Salvatore Bonaccorso]

Source: msgpuck
Version: 1.0.3-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/rtsisyk/msgpuck/issues/12

Hi,

the following vulnerability was published for msgpuck.

CVE-2016-9036[0]:
Invalid handling of map16 format in mp_check()

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9036
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9036
[1] https://github.com/rtsisyk/msgpuck/issues/12
[2] http://www.talosintelligence.com/reports/TALOS-2016-0254/

Regards,
Salvatore