Bug#847603: RFS: mod_pagespeed/1.11.33.4 [ITP] -- Apache module for rewriting web pages to reduce latency and bandwidth

[Sean Whitton]

control: tag -1 +moreinfo

Dear Jeff,

On Fri, Dec 09, 2016 at 02:43:32PM -0500, Jeff Kaufman wrote:
> I am looking for a sponsor for my package "mod_pagespeed":

This looks cool.  Here are some initial comments:

- I'm not prepared to fully review a package that is not available in
  git.  We might need multiple rounds of review, and git-diff(1) is
  invaluable for that.  Please consider `gbp import-dsc` or `dgit
  import-dsc` (the former is more popular; I prefer the latter)

- Your Vcs-* headers point to the upstream repository, which does not
  contain a debian/ directory.  Vcs-* headers are meant to point at a
  packaging repository.  Do you have one available somewhere?

- You have a very long list of quilt patches.  Have you considered
  merging some of them?  For example, all the -native patches could be a
  single patch.  Quilt patches can be a pain to manage when there are
  new upstream releases.

- I note that you have '#ifdef USE_SYSTEM_FOO' but your patch just
  strips off the whole conditional.  Wouldn't it be easier to use those
  USE_SYSTEM_* flags, instead of patching?

- generate.sh runs a copy of gyp in the source tree.  But gyp is
  packaged for Debian.  Please add a build-dependency on the packaged
  gyp, and run that instead (you might need another patch...)

- The package doesn't build in a clean sid chroot.  Log attached.

-- 
Sean Whitton
sbuild (Debian sbuild) 0.72.0 (25 Oct 2016) on zephyr.silentflame.com

+==+
| modpagespeed 1.11.33.4-1 (i386)  Fri, 30 Dec 2016 07:41:56 + |
+==+

Package: modpagespeed
Version: 1.11.33.4-1
Source Version: 1.11.33.4-1
Distribution: unstable
Machine Architecture: i386
Host Architecture: i386
Build Architecture: i386

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-i386-sbuild-dcccd87b-c0a4-4d7a-9cae-4908ef6a595f'
 with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://mirror.vorboss.net/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/swhitton/rfs/modpagespeed_1.11.33.4-1.dsc exists in /home/swhitton/rfs; 
copying to chroot
I: NOTICE: Log filtering will replace 
'build/modpagespeed-vvyuTA/modpagespeed-1.11.33.4' with '<>'
I: NOTICE: Log filtering will replace 'build/modpagespeed-vvyuTA' with 
'<>'

+--+
| Install build-essential  |
+--+


Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in 
'/<>/resolver-d63B9K/apt_archive/sbuild-build-depends-core-dummy.deb'.
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy
dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
Ign:1 copy:/<>/resolver-d63B9K/apt_archive ./ InRelease
Get:2 copy:/<>/resolver-d63B9K/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/resolver-d63B9K/apt_archive ./ Release.gpg
Get:4 copy:/<>/resolver-d63B9K/apt_archive ./ Sources [349 B]
Get:5 copy:/<>/resolver-d63B9K/apt_archive ./ Packages [430 B]
Fetched 1736 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install core build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  sbuild-build-depends-core-dummy
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 786 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 copy:/<>/resolver-d63B9K/apt_archive ./ 
sbuild-build-depends-core-dummy 0.invalid.0 [786 B]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 786 B in 0s (0 B/s)
Selecting previously unselected package sbuild-build-depends-core-dummy.
(Reading database ... 11483 files and directories currently installed.)
Preparing to unpack .../sbuild-build-de

Bug#849666: gradm2: FTBFS on arm64: /usr/bin/ld: cannot find -lfl

[GCS]

Control: tags -1 +unreproducible

On Thu, Dec 29, 2016 at 5:33 PM, Chris West (Faux)
 wrote:
> Source: gradm2
> Version: 3.1~201608131257-1
> Severity: serious
> Justification: fails to build from source
[...]
> The package fails to build:
[...]
 May you retry please? It built on a buildd some time ago. But more
importantly installed a basic Stretch (with empty tasksel options) in
a QEMU ARM64 machine yesterday evening. It was dist-upgraded to Sid
and gradm2 was built fine in it. Will try the QEMU + pbuilder build as
well, but you might just got some other, transient problem.

Thanks,
Laszlo/GCS

Bug#844264: release.debian.org: Please clarify "Packages must autobuild without failure"

[Niels Thykier]

Santiago Vila:
> Dear Release Managers:
> 
> If Release Policy wording is not going to be clarified in any way, that's ok.
> 
> [...]
> 
> Please advise.
> 
> Thanks.
> 

Hi Santiago,

Thanks for your interest in this subject and for wanting to increase the
stability of builds in Debian.

As Julien mentioned earlier, build failures are sadly not as black and
white as one might want them to be.  Especially if it comes at the cost
of blindly disabling all tests in the package.

That said, we should have the talk about what is "definitely not good
enough" - it does sound like you found some interesting cases here.
  But I do not think we have capacity for that talk right now in the
release team (between an incomplete openssl transition and the BTS
breaking causing britney to migrate tons of packages despite RC bugs).

 * Could I ask you to re-raise this issue again after the freeze?
 * For the known issues, we will deal with them as usual for stretch
   even if it is suboptimal.

Thanks,
~Niels

Bug#849726: mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Konstantin Khomoutov]

Package: mpd
Version: 0.19.21-1
Severity: important

Hi!

After upgrading an i686 machine running mpd from Jessie to Stretch,
I noticed mpd won't start -- exiting with return code 1 early at
startup:

| Dec 30 10:16:52 jukebox systemd[1]: [/lib/systemd/system/mpd.service:25] 
Unknown lvalue 'RestrictNamespaces' in section 'Service'
| Dec 30 10:16:54 jukebox systemd[1]: Started Music Player Daemon.
| Dec 30 10:16:55 jukebox mpd[4936]: config_file: loading file /etc/mpd.conf
| Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Main process exited, 
code=exited, status=1/FAILURE
| Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Unit entered failed state.
| Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Failed with result 
'exit-code'.

Running

  /usr/bin/mpd --no-daemon -v /etc/mpd.conf

by hand as root worked OK, so I've changed the ExecStart parameted in
the Systemd unit to

  /usr/bin/strace -o /tmp/mpd.log -f /usr/bin/mpd --no-daemon -v $MPDCONF

commented out all the system protection options, then started to
uncomment them one by one -- attempting to start the unit each time
(with proper invocations of `systemctl daemon-reload` in between).

Finally this spotted the problem which is the

  RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK

option.  With it being commented out, mpd starts OK.

Analyzing the strace output for relevant problems brought up several
attempts at opening sockets -- of types AF_UNIX and AF_INET.
Several of such failed attempts apparently get ignored by mpd, but the
last one actually makes it exit (silently for whatever reason) but with
the result code of 1.
The last lines of the strace's output are:

| 4938  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT 
(Protocol not supported)
| 4938  exit_group(1) = ?
| 4938  +++ exited with 1 +++

and the result of grepping it for EPROTONOSUPPORT is:

| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 
-1 EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT 
(Protocol not supported)


As to the essense of this but, it rather appears to affect Systemd v232
(as shipped by Stretch) specifically on i686 systems [1].

That bug's thread mentions [2], so I've added the unstable repository
and attempted to install systemd from there via

  apt install -t unstable systemd

but it told me the package I have installed is already the newest
version, and its changelog has the following snippet:

8<
systemd (232-2) unstable; urgency=medium

  * Drop RestrictAddressFamilies from service files.
RestrictAddressFamilies= is broken on 32bit architectures and causes
various services to fail with a timeout, including
systemd-udevd.service.
While this might actually be a libseccomp issue, remove this option for
now until a proper solution is found. (Closes: #843160)

 -- Michael Biebl   Sat, 05 Nov 2016 22:43:27 +0100
8<

So it appears you'd better comment that option as well for now of ship
a dedicated unit files specifically for i686 systems if this is
possible.

OTOH, upstream appears to have some developments on [1], so maybe asking
systemd maintainers on whether it's possible to integrate some upstream
fix for this seccomp issue is worthwhile.


Thanks!


1. https://github.com/systemd/systemd/issues/4575
2. https://bugs.debian.org/843160


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

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

Versions of packages mpd depends on:
ii  adduser   3.115
ii  init-system-helpers   1.46
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-0.3
ii  libao41.2.2-1
ii  libasound21.1.2-1
ii  libaudiofile1 0.3.6-3
ii  libavahi-client3  0.6.32-1
ii  libavahi-common3  0.6.32-1
ii  libavcodec57  7:3.2.2-1
ii  libavformat57 7:3.2.2-1
ii  libavutil55   7:3.2.2-1
ii  libbz2-1.01.0.6-8
ii  libc6 2.24-8
ii  libcdio-cdda1 0.83-4.2+b1
ii  libcdio-paranoia1 0.83-4.2+b1
ii  libcdio13 0.83-4.2+b1
ii  libcurl3-gnutls   7.51.0-1
ii  libdbus-1-3   1.10.14-1
ii  lib

Bug#849318: RFS: eoconv/1.5-1

[Sean Whitton]

Dear Andreas,

On Sun, Dec 25, 2016 at 02:42:42PM +0100, Andreas Henriksson wrote:
> This repository looks whack. How do you build it? You should really add
> a debian/README.source with the details if you intend to use this as the
> official packaging vcs (as listed by the Vcs-* fields).

You might want to look at the origtargz(1) tool from devscripts to
handle this sort of repository.  You can just do this to get something
buildable:

% origtargz -u

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#842026: RFS: bundlewrap/2.9.1-1, ITP: 838029 -- Decentralized configuration management system with Python

[Sean Whitton]

control: tag -1 +moreinfo

Dear Jonathan,

On Tue, Oct 25, 2016 at 01:48:49PM +0200, Jonathan Carter (highvoltage) wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors (cc debian-python),
> 
> I am looking for a sponsor for my package "bundlewrap":

I just took at look at your source package.  You are not using the
dh_python tool, which means that your package fails several points of
the Python applications packaging policy (in particular, the .py files
you install are not bytecompiled).

Further, you list each dependency manually, whereas with dh_python you
could just use the $(python:Depends) substvar.  Please check out
dh_python!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848830: dcmtk: remote stack buffer overflow CVE-2015-8979

[Tobias Frost]

Hi Balint,

this bug can be closed, can't it?

--
tobi

Bug#845803: fixed in gpgme1.0 1.8.0-3

[Stuart Prescott]

Dear GPGME maintainers,

While the priorities have been lowered in the package, this has not yet been 
reflected in the archive and so all binary packages from this source are 
currently installed by the "Standard" task stretch:

$ aptitude search '?source-package(gpgme1.0)' -F$'%p:%s/%P' --disable-columns

libgpgme-dev:libdevel/standard 
libgpgme11:libs/optional
libgpgmepp-dev:libdevel/standard
libgpgmepp-doc:doc/standard
libgpgmepp6:libs/standard
libqgpgme7:libs/standard
python-gpg:python/standard
python3-gpg:python/standard

Given that these priorities are changed in the package but not the archive, I 
assume that you'd like the archive updated too. Would you be able to ask the 
ftp-masters to adjust the overrides? (Or would you like me to do that for 
you?)

I believe the correct bug title is¹:

override: libgpgme-dev:libdevel/extra, llibgpgmepp-dev:libdevel/extra, 
libgpgmepp-doc:doc/optional, libgpgmepp6:libs/optional, 
libqgpgme7:libs/optional, python-gpg:python/optional, python3-
gpg:python/optional

(without whatever line-breaks creep into it, obviously...)

BTW updating these overrides is one of the final remaining steps required to 
removing Python 2 from the default installation in stretch.²


cheers
Stuart


① 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file

② https://lists.debian.org/debian-python/2016/12/msg00070.html

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#849725: jessie-pu cairo/1.14.0-2.1+deb8u2

[Salvatore Bonaccorso]

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

Hi

src:cairo in jessie is affected by CVE-2016-9082 which would not
warrant a DSA. A while back in october the issue was already fixed in
unstable, cf. #842289. I would like to propose the attached debdiff
for the upcoming point release.

Note: in the 1.14.0-2.1 -> 1.14.0-2.1+deb8u1 the binary package
binary-cairo-perf-utils got one more binary added
(/usr/bin/cairo-perf-graph-files). Whit this update that goes back to
the 1.14.0-2.1 situation.

Regards,
Salvatore
diff -Nru cairo-1.14.0/debian/changelog cairo-1.14.0/debian/changelog
--- cairo-1.14.0/debian/changelog   2016-03-19 22:38:11.0 +0100
+++ cairo-1.14.0/debian/changelog   2016-12-30 07:30:39.0 +0100
@@ -1,3 +1,12 @@
+cairo (1.14.0-2.1+deb8u2) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2016-9082: DoS attack based on using SVG to generate invalid pointers
+from a _cairo_image_surface in write_png.
+(Closes: #842289)
+
+ -- Salvatore Bonaccorso   Fri, 30 Dec 2016 07:30:39 +0100
+
 cairo (1.14.0-2.1+deb8u1) jessie; urgency=medium
 
   * Fix CVE-2016-3190
diff -Nru cairo-1.14.0/debian/patches/CVE-2016-9082.patch 
cairo-1.14.0/debian/patches/CVE-2016-9082.patch
--- cairo-1.14.0/debian/patches/CVE-2016-9082.patch 1970-01-01 
01:00:00.0 +0100
+++ cairo-1.14.0/debian/patches/CVE-2016-9082.patch 2016-12-30 
07:30:39.0 +0100
@@ -0,0 +1,107 @@
+From c812d1c1935cccf096a60ad904e640fdc83bd41c Mon Sep 17 00:00:00 2001
+From: Adrian Johnson 
+Date: Thu, 20 Oct 2016 21:12:30 +1030
+Subject: [PATCH] image: prevent invalid ptr access for > 4GB images
+
+Image data is often accessed using:
+
+  image->data + y * image->stride
+
+On 64-bit achitectures if the image data is > 4GB, this computation
+will overflow since both y and stride are 32-bit types.
+
+https://bugs.freedesktop.org/show_bug.cgi?id=98165
+---
+ boilerplate/cairo-boilerplate.c | 4 +++-
+ src/cairo-image-compositor.c| 4 ++--
+ src/cairo-image-surface-private.h   | 2 +-
+ src/cairo-mesh-pattern-rasterizer.c | 2 +-
+ src/cairo-png.c | 2 +-
+ src/cairo-script-surface.c  | 3 ++-
+ 6 files changed, 10 insertions(+), 7 deletions(-)
+
+--- a/boilerplate/cairo-boilerplate.c
 b/boilerplate/cairo-boilerplate.c
+@@ -42,6 +42,7 @@
+ #undef CAIRO_VERSION_H
+ #include "../cairo-version.h"
+ 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -976,7 +977,8 @@ cairo_surface_t *
+ cairo_boilerplate_image_surface_create_from_ppm_stream (FILE *file)
+ {
+ char format;
+-int width, height, stride;
++int width, height;
++ptrdiff_t stride;
+ int x, y;
+ unsigned char *data;
+ cairo_surface_t *image = NULL;
+--- a/src/cairo-image-compositor.c
 b/src/cairo-image-compositor.c
+@@ -1575,7 +1575,7 @@ typedef struct _cairo_image_span_rendere
+ pixman_image_t *src, *mask;
+ union {
+   struct fill {
+-  int stride;
++  ptrdiff_t stride;
+   uint8_t *data;
+   uint32_t pixel;
+   } fill;
+@@ -1594,7 +1594,7 @@ typedef struct _cairo_image_span_rendere
+   struct finish {
+   cairo_rectangle_int_t extents;
+   int src_x, src_y;
+-  int stride;
++  ptrdiff_t stride;
+   uint8_t *data;
+   } mask;
+ } u;
+--- a/src/cairo-image-surface-private.h
 b/src/cairo-image-surface-private.h
+@@ -71,7 +71,7 @@ struct _cairo_image_surface {
+ 
+ int width;
+ int height;
+-int stride;
++ptrdiff_t stride;
+ int depth;
+ 
+ unsigned owns_data : 1;
+--- a/src/cairo-mesh-pattern-rasterizer.c
 b/src/cairo-mesh-pattern-rasterizer.c
+@@ -470,7 +470,7 @@ draw_pixel (unsigned char *data, int wid
+   tg += tg >> 16;
+   tb += tb >> 16;
+ 
+-  *((uint32_t*) (data + y*stride + 4*x)) = ((ta << 16) & 0xff00) |
++  *((uint32_t*) (data + y*(ptrdiff_t)stride + 4*x)) = ((ta << 16) & 
0xff00) |
+   ((tr >> 8) & 0xff) | ((tg >> 16) & 0xff00) | (tb >> 24);
+ }
+ }
+--- a/src/cairo-png.c
 b/src/cairo-png.c
+@@ -671,7 +671,7 @@ read_png (struct png_read_closure_t *png
+ }
+ 
+ for (i = 0; i < png_height; i++)
+-row_pointers[i] = &data[i * stride];
++row_pointers[i] = &data[i * (ptrdiff_t)stride];
+ 
+ png_read_image (png, row_pointers);
+ png_read_end (png, info);
+--- a/src/cairo-script-surface.c
 b/src/cairo-script-surface.c
+@@ -1201,7 +1201,8 @@ static cairo_status_t
+ _write_image_surface (cairo_output_stream_t *output,
+ const cairo_image_surface_t *image)
+ {
+-int stride, row, width;
++int row, width;
++ptrdiff_t stride;
+ uint8_t row_stack[CAIRO_STACK_BUFFER_SIZE];
+ uint8_t *rowdata;
+ uint8_t *data;
diff -Nru cairo-1.14.0/debian/patches/series cairo-1.14.0/debian/patches/series
--- cairo-1.14.0/debian/patches/series  2016-03-19 22:36:20.

Bug#675716: fvwm corrupts a sticky window over FvwmPager at desktop change

[Jaimos Skriletz]

On Fri, 25 Jan 2013 00:53:36 +0100 Vincent Lefevre  wrote:
> On 2013-01-24 15:16:46 -0800, Vincent W. Chen wrote:
> > As Thomas Adam noted, what graphics driver are you using?
>
> nouveau. It is known to have a redraw bug with some NVIDIA cards
> (e.g. bug 640464).
>
> > Is there another graphics driver that you can try to reproduce this
> > bug?
>
> I don't know which other one can be used. Last time I tried vesa
> (for bug 640464), it didn't work at all.
>
> > In other words, are you still affected by this problem?
>
> I haven't upgraded fvwm yet. After that, I'll try to reproduce the bug.
>
> If this is a driver bug, bug 689514 might be also one. Unfortunately
> I don't have any test results from other users (in particular those
> using the same cards and driver) for these bugs.
>

Hello,

I am just seeing if you have figured out if this was a video driver
bug or not? Do you still experience this with with fvwm 2.6.7?

jaimos

Bug#746005: Problems in Lilipond and Guile -- #746005

[duck]

Quack,

I think the release team should have been involved much much earlier.

It seems having Lilypond working with recent Guile before the release is 
not going to happen. Even if it built properly there would maybe have 
runtime bugs to solve.


If people are willing to maintain Guile 1.8 into stable during another 
release lifetime, I guess the release team would be ok with it. Maybe it 
would be possible to provide a backport of Guile 2.x and newer Lilypond 
later (when it works) and drop Guile 1.8 and current Lilypond from 
stable in a subsequent point release. This could be announced in the 
release notes from the start, so no surprise.


Anyway, I'm Cc-ing the release team so they don't discover the problem 
much later.


\_o<

--
Marc Dequènes

Bug#849724: apcupsd: not built with modbus/usb support

[Jan Ceuleers]

Package: apcupsd
Version: 3.14.12-1.1
Severity: normal

Dear Maintainer,

Newer APC UPS devices require support for a protocol called modbus.
For apcupsd to be able to control such UPSes, it needs to be
built with modbus/usb support (--enable-modbus-usb build option and
build dependencies on libmodbus-dev and libusb-dev).

Please consider rebuilding apcupsd packages with the above option
and build dependencies enabled in all supported versions of Debian.

For more information please refer to [1].

[1]: http://marc.info/?t=14822908242&r=1&w=2

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

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

Versions of packages apcupsd depends on:
ii  libc6 2.19-18+deb8u6
ii  libgcc1   1:4.9.2-10
ii  libwrap0  7.6.q-25

Versions of packages apcupsd recommends:
ii  apcupsd-doc  3.14.12-1.1

Versions of packages apcupsd suggests:
pn  apcupsd-cgi  
ii  udev 215-17+deb8u5

-- Configuration Files:
/etc/apcupsd/apcupsd.conf changed [not included]
/etc/default/apcupsd changed [not included]

-- no debconf information

Bug#849723: vagrant package --base fails

[Michael Cordingley]

Package: vagrant
Version: 1.9.0+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
vagrant package --base 
   * What was the outcome of this action?
/usr/share/rubygems-integration/all/gems/vagrant-1.9.0/plugins/commands/package/command.rb:59:in
 `package_base': uninitialized constant 
VagrantPlugins::CommandPackage::Command::SecureRandom (NameError)
Did you mean?  SecureRandom
from 
/usr/share/rubygems-integration/all/gems/vagrant-1.9.0/plugins/commands/package/command.rb:42:in
 `execute'
from 
/usr/share/rubygems-integration/all/gems/vagrant-1.9.0/lib/vagrant/cli.rb:42:in 
`execute'
from 
/usr/share/rubygems-integration/all/gems/vagrant-1.9.0/lib/vagrant/environment.rb:274:in
 `cli'
from 
/usr/share/rubygems-integration/all/gems/vagrant-1.9.0/bin/vagrant:118:in `'
from /usr/bin/vagrant:22:in `load'
from /usr/bin/vagrant:22:in `'

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

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

Versions of packages vagrant depends on:
ii  bsdtar 3.2.1-5
ii  curl   7.51.0-1
ii  openssh-client 1:7.3p1-5
ii  ruby   1:2.3.3
ii  ruby-bundler   1.13.6-2
ii  ruby-childprocess  0.5.9-1
ii  ruby-erubis2.7.0-3
ii  ruby-i18n  0.7.0-2
ii  ruby-listen3.0.3-3
ii  ruby-log4r 1.1.10-4
ii  ruby-net-scp   1.2.1-4
ii  ruby-net-sftp  1:2.1.2-3
ii  ruby-net-ssh   1:3.2.0-1
ii  ruby-nokogiri  1.6.8.1-1
ii  ruby-rb-inotify0.9.7-1
ii  ruby-rest-client   1.8.0-3

vagrant recommends no packages.

Versions of packages vagrant suggests:
ii  virtualbox  5.1.10-dfsg-1

-- no debconf information

Bug#849441: libgtk2-perl: failed to retrieve property `gtk-primary-button-warps-slider' of type `gboolean'

[Salvatore Bonaccorso]

Control: severity -1 normal

Hi Ritesh

On Tue, Dec 27, 2016 at 01:28:33PM +0530, Ritesh Raj Sarraf wrote:
> Package: libgtk2-perl
> Version: 2:1.2499-1
> Severity: important
> 
> Hello,
> 
> I have been seeing this error for a couple of months now, for all tools
> that use libgtk2-perl. So far, I'm not sure what may be the cause of
> this error.
> 
> Setting up libgoa-1.0-common (3.22.3-2) ...
> Processing triggers for gnome-menus (3.13.3-8) ...
> Processing triggers for dbus (1.10.14-1) ...
> Setting up libqt5designer5:amd64 (5.7.1-1) ...
> Processing triggers for hicolor-icon-theme (0.15-1) ...
> Setting up ext4magic (0.3.2-7) ...
> Setting up systemd-container (232-8) ...
> Setting up libtracker-miner-1.0-0:amd64 (1.10.3-1) ...
> Setting up libpam-systemd:amd64 (232-8) ...
> Gtk-Message **: (for origin information, set GTK_DEBUG): failed to retrieve 
> property `gtk-primary-button-warps-slider' of type `gboolean' from rc file 
> value "((GString*) 0x5615bf21c000)" of type `gboolean' at 
> /usr/lib/x86_64-linux-gnu/perl5/5.24/Gtk2.pm line 126.
> Gtk-Message **: (for origin information, set GTK_DEBUG): failed to retrieve 
> property `gtk-primary-button-warps-slider' of type `gboolean' from rc file 
> value "((GString*) 0x5615bf21c000)" of type `gboolean' at 
> /usr/lib/x86_64-linux-gnu/perl5/5.24/Gtk2.pm line 126.
> Setting up tracker (1.10.3-1) ...
> Installing new version of config file 
> /etc/xdg/autostart/tracker-store.desktop ...
> Setting up libqt5designercomponents5:amd64 (5.7.1-1) ...
> Setting up tracker-extract (1.10.3-1) ...
> Installing new version of config file 
> /etc/xdg/autostart/tracker-extract.desktop ...
> Setting up libqt5help5:amd64 (5.7.1-1) ...
> Setting up libgoa-1.0-0b:amd64 (3.22.3-2) ...
> Setting up gir1.2-tracker-1.0:amd64 (1.10.3-1) ...
> Setting up qttools5-dev-tools:amd64 (5.7.1-1) ...

Sidenote: you can set GTK_DEBUG in your environment, to see in which
configuration file the 'gtk-primary-button-warps-slider' setting comes
from?

I have not narroved it down, but I can reproduce similar Gtk-Messages
by putting properties with gboolean values in a configuration file,
say

gtk-primary-button-warps-slider = false

or

gtk-primary-button-warps-slider = true

in ~/.gtkrc-2.0 and run the sample simple_menu.pl:

$ perl simple_menu.pl 
Gtk-Message **: (for origin information, set GTK_DEBUG): failed to retrieve 
property `gtk-primary-button-warps-slider' of type `gboolean' from rc file 
value "((GString*) 0x559455dcff20)" of type `gboolean' at 
/usr/lib/x86_64-linux-gnu/perl5/5.24/Gtk2/SimpleMenu.pm line 26.
Callback:
$VAR1 = 'user data';
$VAR2 = 9;
$VAR3 = bless( {}, 'Gtk2::RadioMenuItem' );
Callback:
$VAR1 = 'user data';
$VAR2 = 10;
$VAR3 = bless( {}, 'Gtk2::RadioMenuItem' );

Needs closer investigation though.

Salvatore

Bug#849700: [Pkg-mc-devel] Bug#849700: mcedit does not more work

[Yury V. Zaytsev]

On Thu, 29 Dec 2016, Michelle Konzack wrote:


Package: mc
Version: 3:4.8.3-10

Since I updated my Debian 7 mc does not more work!


Well, you have upgraded a system with a very outdated mc, but apparently 
mc itself wasn't upgraded, and now it broke your mc as a side-effect and 
you are asking what could be the problem?


To be honest, no idea, the upgraded packages seem to be mostly irrelevant 
to the matter. It seems that you have some problem with a terminal 
emulator or how keys are delivered to the console applications... check 
that other applications like vim are still ok, remember whether you have 
changed anything in this area, see which sequences are delivered in cat.


Any suggestions what could happen to my system? I searched now 3 days 
without success!


First you can find out whether it's a user profile problem or a 
system-wide problem by creating a new user and running mc in there.


--
Sincerely yours,
Yury V. Zaytsev

Bug#849722: python-xapian: QueryParser.add_boolean_prefix() throws TypeError with grouping=''

[Jameson Graef Rollins]

Package: python-xapian
Version: 1.4.1-1
Severity: normal

The QueryParser apparently has three overloaded .add_boolean_prefix() methods.  
The first, listed here:

https://xapian.org/docs/apidoc/html/classXapian_1_1QueryParser.html#a8590431c481fe0eea43cd4ce619a0816

says that the grouping should be specified as an empty string.
However, specifying the empty string results in the following
exception:

servo:~ $ python -c "import xapian; qp = xapian.QueryParser(); 
qp.add_boolean_prefix('tag', 'K', '')"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/xapian/__init__.py", line 10485, in 
_queryparser_add_boolean_prefix
return __queryparser_add_boolean_prefix_orig(self, s, proc, exclusive)
TypeError: in method 'QueryParser_add_boolean_prefix', argument 4 of type 
'std::string const *'
servo:~ 1$

The second version seems to work fine though:

servo:~ 0$ python -c "import xapian; qp = xapian.QueryParser(); 
qp.add_boolean_prefix('tag', 'K', False)"
servo:~ 0$

Tried to report this issue upstream directly but I couldn't seem to
register an account at trac.xapian.org.

Thanks so much for maintaining such a useful package!

jamie.


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

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

Versions of packages python-xapian depends on:
ii  libc62.24-8
ii  libgcc1  1:6.2.1-5
ii  libstdc++6   6.2.1-5
ii  libxapian30  1.4.1-1
ii  python   2.7.11-2
pn  python:any   

python-xapian recommends no packages.

Versions of packages python-xapian suggests:
ii  xapian-doc  1.4.1-1

-- no debconf information

Bug#823792: Bug#688280: reassign 688280 to adb

[Salvatore Bonaccorso]

Hi Paul,

On Fri, Dec 30, 2016 at 01:04:30PM +0800, Paul Wise wrote:
> Control: reopen 823792
> Control: found 823792 1:7.0.0+r1-1
> 
> On Tue, 2016-12-27 at 20:01 +0100, Salvatore Bonaccorso wrote:
> 
> > It is really good that you and your team though have fixed the copy in
> > android-platform-system-core (bug #823792) via new upstream versions
> > which fixed that source-wise.
> 
> I don't think this is actually fixed by the new upstream versions,
> take a look at the GetLogFilePath function via codesearch:
> 
> https://sources.debian.net/src/android-platform-system-core/1:7.0.0%2Br1-2/adb/client/main.cpp/?hl=58#L37

Yes you are right, although the code restructured, you are right it
still uses /tmp/adb.log in the end (if no TMPDIR is set in the env).

Regards,
Salvatore

Bug#849721: please build mailutils with python3 bindings

[Matthias Klose]

Package: src:mailutils
Version: 1:3.1.1-1

please build mailutils with python3 bindings.  while the code has some comments
about python3, it fails in the configury, and then later building the
extensions.  with the attached patch you'll get to the first build error in the
extensions.

  * Build using python3.

diff -Nru mailutils-3.1.1/debian/control mailutils-3.1.1/debian/control
--- mailutils-3.1.1/debian/control	2016-12-12 10:48:21.0 +0100
+++ mailutils-3.1.1/debian/control	2016-12-30 06:13:56.0 +0100
@@ -24,7 +24,7 @@
libpam0g-dev,
libreadline-dev,
libwrap0-dev,
-   python-dev (>= 2.6.6-3~),
+   python3-dev,
texinfo,
zlib1g-dev
 Standards-Version: 3.9.8
@@ -203,15 +203,15 @@
  collection of small shell programs to read and handle mail in a very flexible
  way.
 
-Package: python-mailutils
+Package: python3-mailutils
 Section: python
 Architecture: any
 Depends: mailutils-common (= ${source:Version}),
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends}
-Provides: ${python:Provides}
-Description: GNU Mail abstraction library (Python interface)
+Provides: ${python3:Provides}
+Description: GNU Mail abstraction library (Python3 interface)
  GNU Mailutils is a rich and powerful protocol-independent mail framework.
  It contains a series of useful mail libraries, clients, and servers.
  .
diff -Nru mailutils-3.1.1/debian/patches/python3.diff mailutils-3.1.1/debian/patches/python3.diff
--- mailutils-3.1.1/debian/patches/python3.diff	1970-01-01 01:00:00.0 +0100
+++ mailutils-3.1.1/debian/patches/python3.diff	2016-12-30 06:15:23.0 +0100
@@ -0,0 +1,15 @@
+Index: b/configure.ac
+===
+--- a/configure.ac
 b/configure.ac
+@@ -1196,8 +1196,8 @@ if test "$status_python" = yes; then
+ AC_ARG_VAR([PYTHON_CONFIG], [The name of python-config binary])
+ AC_PATH_PROG([PYTHON_CONFIG], python-config)
+ if test -n "$PYTHON_CONFIG"; then
+-  PYTHON_LIBS=`python-config --libs`
+-  PYTHON_INCLUDES=`python-config --includes`
++  PYTHON_LIBS=`$PYTHON_CONFIG --libs`
++  PYTHON_INCLUDES=`$PYTHON_CONFIG --includes`
+ else
+   status_python=no 
+ fi
diff -Nru mailutils-3.1.1/debian/patches/series mailutils-3.1.1/debian/patches/series
--- mailutils-3.1.1/debian/patches/series	2016-12-25 02:47:54.0 +0100
+++ mailutils-3.1.1/debian/patches/series	2016-12-30 06:15:23.0 +0100
@@ -6,3 +6,4 @@
 readline.patch
 10_guile-snarf-CPP.patch
 hurd.patch
+python3.diff
diff -Nru mailutils-3.1.1/debian/python3-mailutils.install mailutils-3.1.1/debian/python3-mailutils.install
--- mailutils-3.1.1/debian/python3-mailutils.install	1970-01-01 01:00:00.0 +0100
+++ mailutils-3.1.1/debian/python3-mailutils.install	2016-11-24 13:02:23.0 +0100
@@ -0,0 +1,2 @@
+usr/lib/python*/*-packages/mailutils/*.py
+usr/lib/python*/*-packages/mailutils/*.so
diff -Nru mailutils-3.1.1/debian/python-mailutils.install mailutils-3.1.1/debian/python-mailutils.install
--- mailutils-3.1.1/debian/python-mailutils.install	2016-11-24 13:02:23.0 +0100
+++ mailutils-3.1.1/debian/python-mailutils.install	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-usr/lib/python*/*-packages/mailutils/*.py
-usr/lib/python*/*-packages/mailutils/*.so
diff -Nru mailutils-3.1.1/debian/rules mailutils-3.1.1/debian/rules
--- mailutils-3.1.1/debian/rules	2016-12-12 11:25:13.0 +0100
+++ mailutils-3.1.1/debian/rules	2016-12-30 06:15:23.0 +0100
@@ -31,6 +31,8 @@
 endif
 
 DEB_CONFIGURE_SCRIPT_ENV += DEFAULT_CUPS_CONFDIR=/usr/share/cups/mime
+DEB_CONFIGURE_SCRIPT_ENV += PYTHON=/usr/bin/python3
+DEB_CONFIGURE_SCRIPT_ENV += PYTHON_CONFIG=/usr/bin/python3-config
 
 DEB_CONFIGURE_EXTRA_FLAGS += \
 	--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
@@ -70,8 +72,8 @@
 build/mailutils-doc::
 	$(DEB_MAKE_INVOKE) html
 
-binary-install/python-mailutils::
-	dh_python2 -p$(cdbs_curpkg) --no-guessing-versions
+binary-install/python3-mailutils::
+	dh_python3 -p$(cdbs_curpkg) --no-guessing-versions
 
 DEB_DH_STRIP_ARGS := --dbgsym-migration='mailutils-dbg (<< 3.0-1~)'
 

Bug#845478: dpkg postinst script fails to move files in /etc

[HJ]

Hi,

I finally found some free time to look closer, however I really couldn't
fix it so I reinstalled a fresh testing and surprise it worked fine. Not
sure what caused this issue on the old system but it works now so I guess
this bug can be closed ;)

Bug#849720: [synaptic] Synaptic ignores its settings

[HJ]

Package: synaptic
Version: 0.83+nmu1
Severity: serious

Its now impossible to change settings inside Synaptic:

Here is a video showing the issue:

https://drive.google.com/open?id=0B_2_dsXrefR-VEE0dk1ZYzYwaUU


--- System information. ---
Architecture:
Kernel: Linux 4.8.0-2-amd64

Debian Release: stretch/sid
500 testing ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-==
libapt-inst2.0 (>= 0.8.16~exp12) | 1.4~beta2
libapt-pkg5.0 (>= 1.1~exp9) | 1.4~beta2
libatk1.0-0 (>= 1.12.4) | 2.22.0-1
libc6 (>= 2.14) | 2.24-8
libcairo-gobject2 (>= 1.10.0) | 1.14.8-1
libcairo2 (>= 1.2.4) | 1.14.8-1
libept1.5.0 | 1.1+nmu3+b1
libgcc1 (>= 1:3.0) | 1:6.2.1-5
libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.36.0-1
libglib2.0-0 (>= 2.16.0) | 2.50.2-2
libgnutls30 (>= 3.5.0) | 3.5.7-3
libgtk-3-0 (>= 3.3.16) | 3.22.5-1
libpango-1.0-0 (>= 1.14.0) | 1.40.3-3
libpangocairo-1.0-0 (>= 1.14.0) | 1.40.3-3
libpcre2-8-0 | 10.22-2
libstdc++6 (>= 5.2) | 6.2.1-5
libvte-2.91-0 | 0.46.1-1
libx11-6 | 2:1.6.4-2
libxapian30 | 1.4.1-1
zlib1g (>= 1:1.1.4) | 1:1.2.8.dfsg-4
hicolor-icon-theme | 0.15-1


Recommends (Version) | Installed
==-+-=
gksu | 2.0.2-9
OR kdebase-bin |
OR policykit-1 | 0.105-17
libgtk2-perl (>= 1:1.130) | 2:1.2499-1
rarian-compat | 0.8.1-6
xdg-utils | 1.1.1-1


Suggests (Version) | Installed
==-+-===
dwww |
menu | 2.1.47
deborphan |
apt-xapian-index |
tasksel | 3.38
software-properties-gtk |

Bug#849719: O: cyclades-serial-client

[Russell Coker]

Package: wnpp
Severity: normal

The package cyclades-serial-client is designed to work with Cyclades terminal
servers (which have not been manufactured for a while) and other devices using
RFC 2217 (which probably includes some Cisco gear that's still in service).

It has a shared object that takes over library calls like tcsetattr(3) to
implement a fake serial port.

I haven't used this for years and don't have enough spare time to maintain it.
I can assist if someone else wants to take it over.

Bug#849718: [synaptic] Synaptic does not ask about changes anymore

[HJ]

Package: synaptic
Version: 0.83+nmu1
Severity: grave

Hi,

unlike previous synaptic releases this one doesn't ask about changes 
anymore,


for example:

 I can now remove the adwaita-icon-theme however this will not ask 
about the automatically changes so gtk will be removed and all packages 
that depend on(eg lightdm and synaptic itself.


another exampe:

i remove libvlc will will remove all qt packages since they depend on a 
phonon backend again no asking that those packages will be removed, too.


--- System information. ---
Architecture:
Kernel: Linux 4.8.0-2-amd64

Debian Release: stretch/sid
500 testing ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-==
libapt-inst2.0 (>= 0.8.16~exp12) | 1.4~beta2
libapt-pkg5.0 (>= 1.1~exp9) | 1.4~beta2
libatk1.0-0 (>= 1.12.4) | 2.22.0-1
libc6 (>= 2.14) | 2.24-8
libcairo-gobject2 (>= 1.10.0) | 1.14.8-1
libcairo2 (>= 1.2.4) | 1.14.8-1
libept1.5.0 | 1.1+nmu3+b1
libgcc1 (>= 1:3.0) | 1:6.2.1-5
libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.36.0-1
libglib2.0-0 (>= 2.16.0) | 2.50.2-2
libgnutls30 (>= 3.5.0) | 3.5.7-3
libgtk-3-0 (>= 3.3.16) | 3.22.5-1
libpango-1.0-0 (>= 1.14.0) | 1.40.3-3
libpangocairo-1.0-0 (>= 1.14.0) | 1.40.3-3
libpcre2-8-0 | 10.22-2
libstdc++6 (>= 5.2) | 6.2.1-5
libvte-2.91-0 | 0.46.1-1
libx11-6 | 2:1.6.4-2
libxapian30 | 1.4.1-1
zlib1g (>= 1:1.1.4) | 1:1.2.8.dfsg-4
hicolor-icon-theme | 0.15-1


Recommends (Version) | Installed
==-+-=
gksu | 2.0.2-9
OR kdebase-bin |
OR policykit-1 | 0.105-17
libgtk2-perl (>= 1:1.130) | 2:1.2499-1
rarian-compat | 0.8.1-6
xdg-utils | 1.1.1-1


Suggests (Version) | Installed
==-+-===
dwww |
menu | 2.1.47
deborphan |
apt-xapian-index |
tasksel | 3.38
software-properties-gtk |

Bug#688280: reassign 688280 to adb

[Paul Wise]

Control: reopen 823792
Control: found 823792 1:7.0.0+r1-1

On Tue, 2016-12-27 at 20:01 +0100, Salvatore Bonaccorso wrote:

> It is really good that you and your team though have fixed the copy in
> android-platform-system-core (bug #823792) via new upstream versions
> which fixed that source-wise.

I don't think this is actually fixed by the new upstream versions,
take a look at the GetLogFilePath function via codesearch:

https://sources.debian.net/src/android-platform-system-core/1:7.0.0%2Br1-2/adb/client/main.cpp/?hl=58#L37

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#849717: Wrong return value from pthread_mutex_trylock

[Mattias Ellert]

Source: libc0.3-dev
Version: 2.24-8
Severity: important

According to the documentation (man page) for pthread_mutex_trylock:

The pthread_mutex_trylock() function shall be equivalent to
pthread_mutex_lock(), except that if the mutex object referenced by
mutex is currently locked (by any thread, including the current
thread), the call shall return immediately.

RETURN VALUE
  The pthread_mutex_trylock() function shall fail if:

  EBUSY  The mutex could not be acquired because it was already locked.

Here is a short test program


#include 
#include 
#include 

int main() {
  pthread_mutex_t m;
  int i;
  printf("%s: %i\n", "EBUSY", EBUSY);
  printf("%s: %i\n", "EAGAIN", EAGAIN);

  i = pthread_mutex_init(&m, NULL);
  printf("%s: %i\n", "init", i);
  i = pthread_mutex_lock(&m);
  printf("%s: %i\n", "lock", i);
  i = pthread_mutex_trylock(&m);
  printf("%s: %i\n", "trylock", i);
  i = pthread_mutex_unlock(&m);
  printf("%s: %i\n", "unlock", i);
  i = pthread_mutex_destroy(&m);
  printf("%s: %i\n", "destroy", i);
}


On Linux this behaves according to the documentation:

EBUSY: 16
EAGAIN: 11
init: 0
lock: 0
trylock: 16
unlock: 0
destroy: 0

I.e. the trylock on the already locked mutex returns EBUSY.

On Hurd the following happens:

EBUSY: 1073741840
EAGAIN: 1073741859
init: 0
lock: 0
trylock: -1
unlock: 0
destroy: 0

I.e. the trylock on the already locked mutex returns -1 instead.

This causes programs using GLib to abort execution:

GLib (gthread-posix.c): Unexpected error from C library during
'pthread_mutex_trylock': Error in unknown error system: . 
Aborting.
Aborted

Mattias


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

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

I hope you're enjoying the holidays.  Mine have been busy, and I hope
this version of src:muse-el is of sufficient quality to be uploaded to
the archive, because the addition of the new package elpa-muse won't
be possible after Jan 5th.

On Sat, Dec 10, 2016 at 02:46:11PM -0700, Sean Whitton wrote:
> Dear Nicholas,
> 
> On Wed, Dec 07, 2016 at 09:16:28PM -0500, Nicholas D Steeves wrote:
> > Thank you once again for holding me to high standards and for taking
> > the time to point out what needs work!
> 
> And thank you for your patience with this review process.
> 
> I saw some more problems.  Some of these are quite elementary errors:
> 
> 1. You're still not closing the ITA properly.  You are missing a '#'
> character.
> 
> 2. There is a spurious '+' character in your rules file that is subtly
> breaking the build.
> 
> I notice that you have an application to be a DM.  These sorts of errors
> can cause broken uploads, and confusion among collaborators.  Please try
> to get into the habit of checking your commits very carefully,
> especially when they are intended for upload to Debian.

I'm collecting a list of mistakes I'm likely to make when I'm not 100%
focused on the work I'm doing; in the future, I plan to use it as a
personal checklist.  If any of these mistakes fall into the "useful
for other new packages" category, please let me know and I'll find a
wiki.d.org article to contribute to.  On the other hand, maybe they're
just dumb mistakes ;-)

> Okay, now the less elementary stuff:
> 
> 2. Upstream's README says that the license for contrib/*blosxom is
> different from the main project.  This should be reflected in
> d/copyright (though see below for other issues to resolve first).

Done/pending.

> 3. Point 15 from my previous e-mail not yet addressed:
> > Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment to
> > the control file.
> 
Ah, specifically with a comment in d/control vs d/changelog.  Fixed,
plus a mistake I missed; in d/changelog I had intended to compromise
with recommends vs requires, but failed to make the change to
d/control).

> 4. "- Change section to editors; Change priority to optional."
> 
> This should be two separate lines.

Notice of this kind of convention I'd like to see in a "New Packages
Guide" ;-)

> 5. Have you figured out that "binary package" stuff discussed in your
> previous e-mail by yourself, or is that something I can help you with?

Sorry, unfortunately I have not.  Yes, please help me with this and
feel free commit directly to pkg-emacsen.

> > I've contacted Michael Olson about the possibility of providing an
> > examples/mwolson tarball on his website, because as I see it the
> > external links are an integral part of the Muse-managed website
> > example.  Specifically, I believe the intent of the example is to
> > provide a copy of a website that is browsable online so that the user
> > can explore both the source layout of a Muse-managed project and
> > browse the result.  In the meantime, I've added an override; if that
> > override is unacceptable, please let me know.  If we can keep the
> > override, I'd be happy to notify users--with NEWS--of the potential
> > privacy breach.
> 
> Looks good to me -- thanks for figuring out the warnings.
> 
> It would be good to limit the override to that directory.  Lintian
> overrides support wildcards, so you should be able to do something like
> this (not tested):
> 
> elpa-muse binary: 
> privacy-breach-generic*/usr/share/doc/elpa-muse/examples/mwolson/*

Originally I tried (and failed) to limit the override, so fell back to
the sloppy glob approach.  For future reference to anyone reading this
thread, this is the syntax that worked for me:

elpa-muse binary: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/*

> > > 10. How are the *.py files meant to be used?  Are they supposed to
> > > be copied into a pyblosxom installation, or run directly from where
> > > they are installed?  If the latter, they should be bytecompiled and
> > > installed into /usr/share/elpa-muse/contrib.  If the former, they
> > > are fine as they are.
> > 
> > By reading the following from getstamps.py:
[...]
> > It would seem that these are intended to be used in the following
> > manner: user reads the headers of these contributed python programs,
> > then adapts them to his/her needs, then copies them to the blog
> > project dir (eg: ~/my_blog).  Previous versions of src:muse-el
> > installed these contributed programs to
> > /usr/share/doc/muse-el/contrib.
> 
> I would be inclined to put them in /usr/src/elpa-muse.  The propellor
> package puts a copy of its upstream source code in /usr/src/propellor.
> 
> The current location is fine if you prefer.  Thanks for the explanation.

You're welcome.  In this particular case, I prefer to be conservative
vs disruptive ;-)

> > > 11. I've now reviewed d/copyright.  Unfortunately, you can't claim
> > > that the debian/ directory is GPL-3+ without con

Bug#849716: ITP: weresync -- A program to easily clone linux drives incrementally.

[Daniel Manila]

Package: wnpp
Severity: wishlist
Owner: Daniel Manila 

* Package name: weresync
  Version : 0.2
  Upstream Author : Daniel Manila 
* URL : https://github.com/DonyorM/weresync
* License : Apache2
  Programming Lang: Python3 
  Description : A program to easily clone linux drives incrementally.

Using rsync and various partitioning tools, weresync simulates a normal clone 
and creates a drive that is almost exactly the same as the original drive. 
However it is able to do this from a running drive or to a drive smaller than 
the original drive. This is written in Python but makes use of many aspects of 
the Linux ecosystem.

Hopefully, you think this package looks amazing and you want to try it right 
away. However, you may be skeptical about the usefulness of weresync. You may 
be thinking, I can do this exact same thing using gparted or ddrescue. Hear me 
out! There are a few reasons to use weresync over the other tools.

First and foremost, most other cloning tools require confidence in one's 
technical skill. dd will easily destroy your drive, gparted requires knowing 
what flags and partition types to use, and CloneZilla is just about the 
opposite of user friendly. weresync primarily attempts to help people who don't 
want to spend the time and effort to learn how to safely use a cloning tool.

But weresync also has some of its own features. It contains the ability to 
properly copy a partition table to a new drive and format the new drive. It 
uses rsync to copy so, unlike most other cloning tools, it will update 
incrementally – saving time. weresync has good default directory exclusions 
(such as /dev or /proc) so it won't copy parts of your system which should not 
be copied. On top of this weresync will create new UUIDs for the partitions on 
the cloned drive, allowing the clone to be used alongside the original drive. 
But the clone will still be bootable because weresync updates the fstab and 
reinstalls the boot loader. Not to mention it can complete the entire clone 
while leaving the original drive running ("hot cloning"), unlike dd or 
CloneZilla.

All of this is accomplished with one button click.

--

I am the upstream author of this package and I will be maintaining it as I
produce updates on the upstream code. I will need a sponsor to post this package
to Debian.

Bug#810742: upstream bug

[Mike Kupfer]

The upstream bug for this is

  https://sourceforge.net/p/mh-e/bugs/476/

regards,
mike

Bug#849715: mailutils: Incorrect Vcs-Svn header in source package

[Stuart Prescott]

Source: mailutils
Version: 1:3.1.1-1
Severity: normal

Dear Maintainer,

The mailutils source package declares:

  Vcs-Svn: https://anonscm.debian.org/git/collab-maint/mailutils.git

which incorrectly states that the package is maintained in Subversion while
pointing to a git repository. This (obviously) causes debcheckout to fail:

$ debcheckout mailutils
declared svn repository at 
https://anonscm.debian.org/git/collab-maint/mailutils.git
svn co https://anonscm.debian.org/git/collab-maint/mailutils.git mailutils ...
svn: E175009: Unable to connect to a repository at URL 
'https://anonscm.debian.org/git/collab-maint/mailutils.git'
svn: E175009: XML Parsing failed: Unexpected root element 'html'
checkout failed (the command above returned a non-zero exit code)

The actual git repo that is listed is also empty:

$ git clone https://anonscm.debian.org/git/collab-maint/mailutils.git
Cloning into 'mailutils'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

It's easy to forget to push after uploading.

cheers
Stuart

Bug#849714: guerillabackup -- resilient, distributed backup and archiving solution

[halfdog]

Package: wnpp
Severity: wishlist

Package name: guerillabackup
Version: 0.0.0
Upstream Author: halfdog 
URL: https://github.com/halfdog/guerillabackup
Sources URL: https://github.com/halfdog/guerillabackup.git
License: LGPLv3
Programming Lang: Python
Description: guerillabackup supports backup generation and transfer
  especially in non-standard environments like on private equipment.
Dependencies: python

Long description:
 The tool supports asynchronous, local-coordinated, distributed
 secure backup generation, forwarding, verification, storage
 and deletion even in rugged environments. The system is open
 to integration of own code. The codebase is very small and
 kept simple to ease auditing.
 .
 Unlike business backup solutions, guerillabackup also considers
 following conditions that might be encountered with private use:
 * infrastructure uptime below 99%, e.g. machines not always powered
 * poor network connectivity, e.g. mobile access, parallel video
   streaming
 * poor physical access and anti-theft protection of machines
 * no security monitoring of machines
 .
 See /usr/share/doc/guerillabackup/Design.txt section "Requirements" 
 for more information.


After receiving the wnpp bug issue number and adding it to
debian/changelog, final package will be available at
https://mentors.debian.net/package/guerillabackup

Bug#842222: Two node-babel ITPs

[Pirate Praveen]

On Fri, 30 Dec 2016 00:20:43 +0200 Adrian Bunk  wrote:
> Control: forcemerge -1 849291
> 
> Hi,
> 
> both of you sent ITPs for node-babel, please coordinate regarding who 
> will actually package it.

Hi Lucas,

The work I have already done is here.
https://anonscm.debian.org/cgit/pkg-javascript/node-babel.git

I'm using npm packages to bootstrap as it has circular dependencies. We
can upload all packages together to contrib first and then move them to
main when they work with packaged versions.

I have uploaded the packages here https://people.debian.org/~praveen/babel/

We need to fix rollup and lerna builds with packaged babel to move
further. Some problems are being discussed in pkg-javascript-devel list.



signature.asc
Description: OpenPGP digital signature

Bug#849713: override: flpsed:graphics/optional

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

Hi,

flpsed doesn't conflicts with other packages and doesn't have specialized
requirements. In accordance with Debian Policy, the right priority is optional.
So, I am asking for change from extra to optional. The current package in
unstable already sets optional.

Thanks in advance!

Regards,

Eriberto

Bug#849712: motion: Motion starts but immediately exits when run as a daemon using systemd

[Tim Edwards]

Package: motion
Version: 3.2.12+git20140228-8build1
Severity: normal

Dear Maintainer,

I've tried using motion as a systemd service, the problem is that it seems to 
die as soon as I start it. I suspect this the following things are stopping it 
running correctly:

- the package doesn't set '/var/log/motion/' to be owned by 'motion', which 
means the daemon can't write to its log file and dies
motion[26465]: [17281408] [EMG] [ALL] motion_startup: Exit motion, cannot 
create log file /var/log/motion/motion.log: Permission denied

- the package doesn't set /var/run/motion to be owned by motion:
[1404] [ERR] [ALL] [Dec 30 09:40:33] myfopen: Error opening file 
/var/run/motion/motion.pid with mode w+: Permission denied
[1404] [EMG] [ALL] [Dec 30 09:40:33] become_daemon: Exit motion, cannot 
create process id file (pid file) /var/run/motion/motion.pid: Permission denied

- motion doesn't look for the configuration file /etc/motion/motion.conf, it 
actually looks for /etc/motion.conf - I could resolve this with a symlink sudo 
ln /etc/motion/motion.conf /etc/motion.conf


tim@localhost:~$ systemctl status motion
● motion.service - LSB: Start Motion detection
   Loaded: loaded (/etc/init.d/motion; bad; vendor preset: enabled)
   Active: active (exited) since Fri 2016-12-30 09:40:33 AEDT; 4h 21min ago
 Docs: man:systemd-sysv-generator(8)
  Process: 26496 ExecStop=/etc/init.d/motion stop (code=exited, 
status=0/SUCCESS)
  Process: 26504 ExecStart=/etc/init.d/motion start (code=exited, 
status=0/SUCCESS)
Tasks: 0
   Memory: 0B
  CPU: 0

Dec 30 09:40:32 localhost systemd[1]: Starting LSB: Start Motion detection...
Dec 30 09:40:33 localhost motion[26504]:  * Starting motion detection daemon 
motion
Dec 30 09:40:33 localhost motion[26504]:...done.
Dec 30 09:40:33 localhost systemd[1]: Started LSB: Start Motion detection.
Dec 30 09:40:33 localhost motion[26511]: [1404] [NTC] [ALL] conf_load: 
Processing thread 0 - co
Dec 30 09:40:33 localhost motion[26511]: [1404] [NTC] [ALL] motion_startup: 
Motion 3.2.12+git20
Dec 30 09:40:33 localhost motion[26511]: [1404] [NTC] [ALL] motion_startup: 
Logging to file (/v

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

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

Versions of packages motion depends on:
ii  adduser3.113+nmu3ubuntu4
ii  debconf [debconf-2.0]  1.5.58ubuntu1
ii  libavcodec-ffmpeg-extra56  7:2.8.10-0ubuntu0.16.04.1
ii  libavfilter-ffmpeg57:2.8.10-0ubuntu0.16.04.1
ii  libavformat-ffmpeg56   7:2.8.10-0ubuntu0.16.04.1
ii  libavutil-ffmpeg54 7:2.8.10-0ubuntu0.16.04.1
ii  libc6  2.23-0ubuntu5
ii  libjpeg8   8c-2ubuntu8
ii  libmysqlclient20   5.7.16-0ubuntu0.16.04.1
ii  libpq5 9.5.5-0ubuntu0.16.04
ii  libsdl1.2debian1.2.15+dfsg1-3
ii  libsqlite3-0   3.11.0-1ubuntu1

Versions of packages motion recommends:
ii  ffmpeg  7:2.8.10-0ubuntu0.16.04.1

Versions of packages motion suggests:
pn  mysql-client   
pn  postgresql-client  

-- Configuration Files:
/etc/default/motion changed:
start_motion_daemon=yes

/etc/motion/motion.conf changed:
daemon on
process_id_file /var/run/motion/motion.pid
setup_mode off
logfile /var/log/motion/motion.log
log_level 6
log_type all
videodevice /dev/video1
v4l2_palette 17
; tunerdevice /dev/tuner0
input -1
norm 0
frequency 0
rotate 0
width 1280
height 960
framerate 1
minimum_frame_time 3
; netcam_url value
; netcam_userpass value
netcam_keepalive off
; netcam_proxy value
netcam_tolerant_check off
auto_brightness off
brightness 100
contrast 0
saturation 0
hue 0
roundrobin_frames 1
roundrobin_skip 1
switchfilter off
threshold 1500
threshold_tune off
noise_level 32
noise_tune on
despeckle_filter EedDl
; area_detect value
; mask_file value
smart_mask_speed 0
lightswitch 0
minimum_motion_frames 1
pre_capture 0
post_capture 0
event_gap 60
max_movie_time 0
emulate_motion off
output_pictures on
output_debug_pictures off
quality 75
picture_type jpeg
ffmpeg_output_movies on
ffmpeg_output_debug_movies off
ffmpeg_timelapse 0
ffmpeg_timelapse_mode daily
ffmpeg_bps 50
ffmpeg_variable_bitrate 0
ffmpeg_video_codec mpeg4
ffmpeg_deinterlace off
sdl_threadnr 0
use_extpipe off
;extpipe mencoder -demuxer rawvideo -rawvideo w=320:h=240:i420 -ovc x264 
-x264encopts 
bframes=4:frameref=1:subq=1:scenecut=-1:nob_adapt:threads=1:keyint=1000:8x8dct:vbv_bufsize=4000:crf=24:partitions=i8x8,i4x4:vbv_maxrate=800:no-chroma-me
 -vf denoise3d=16:12:48:4,pp=lb -of   avi -o %f.avi - -fps %fps
snapshot_interval 0
locate_motion_mode off
locate_motion_style box
text_right %Y-%m-%

Bug#785612: patch

[Kunal Mehta]

Control: tags -1 patch

I've attached a pretty simple patch that updates the link, link text,
and switches the protocol to HTTPS.


Index: developer.wml
===
--- developer.wml	(revision 3584)
+++ developer.wml	(working copy)
@@ -358,8 +358,8 @@
 	": package in stable proposed updates (not shown if also in stable security)" . html_br();
 $help_data .= html_blank(). html_span("Light blue", "", "proposed-updates-new") . ": package " .
 	html_a("pending", "https://ftp-master.debian.org/proposed-updates.html";) . " for stable proposed updates (not shown if also in stable security)" . html_br();
-$help_data .= html_blank(). html_span("Dark purple", "", "bpo") . ": package on " .
-	html_a("backports.org", "http://backports.org/";) . html_br();
+$help_data .= html_blank(). html_span("Dark purple", "", "bpo") . ": package in " .
+	html_a("Debian backports", "https://backports.debian.org/";) . html_br();
 $help_data .= html_blank(). html_span("Purple", "", "testing") .
 	": testing version" . html_br();
 $help_data .= html_blank(). html_span("Green", "", "unstable") .


signature.asc
Description: OpenPGP digital signature

Bug#846989: Please migrate to emacs25

[Rob Browning]

> For example, assuming the package works with emacs25, a dependency like
>
>   emacs25-nox | emacs25 | emacs24
>
> should suffice.

...and this does appear to work fine.  I was able to build the package
via sid sbuild with this change, and the resulting package appears to
work fine in emacs25.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#849711: linux-image-4.8.0-2-amd64: OThere are a lot of fails on kernel 4.8.0-2 in MacBook 4.1

[Benjamin Perez]

Package: src:linux
Version: 4.8.11-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   when i upgrade kernel 4.7.0-1 to 4.8.0-1 and 4.8.0-2

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I'm programmer

   * What was the outcome of this action?
   My laptop don't work correctly, I need use downgrade with kernel 4.7.0-1 to 
start an work normaly.

   * What outcome did you expect instead?
   Beter performance.

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


-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=2d8f3975-eec5-4b1c-bb55-44c50321bdef ro quiet

** Tainted: PWOE (12801)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[  245.974024]  mbcache hid_apple hid_appleir hid_generic usbhid hid sr_mod 
cdrom sd_mod ata_generic ata_piix ahci libahci firewire_ohci libata i2c_i801 
i2c_smbus firewire_core scsi_mod crc_itu_t sky2 ehci_pci fjes uhci_hcd ehci_hcd 
usbcore usb_common
[  245.974049] CPU: 1 PID: 958 Comm: Xorg Tainted: PW  OE   
4.8.0-2-amd64 #1 Debian 4.8.11-1
[  245.974050] Hardware name: Apple Inc. MacBook4,1/Mac-F22788A9, BIOS 
MB41.88Z.00C1.B00.0802091535 02/09/08
[  245.974052]  0286 b7c539a5 8fd269f5 
9f6b4c9278a0
[  245.974057]   8fa7c16e 9f6b7654 
9f6b4c9278f8
[  245.974061]   08000dcf 9f6b73c894b0 
9f6b4c8e9a80
[  245.974065] Call Trace:
[  245.974070]  [] ? dump_stack+0x5c/0x77
[  245.974074]  [] ? __warn+0xbe/0xe0
[  245.974077]  [] ? warn_slowpath_fmt+0x5f/0x80
[  245.974080]  [] ? finish_wait+0x3e/0x70
[  245.974100]  [] ? drm_wait_one_vblank+0x1a3/0x1b0 [drm]
[  245.974103]  [] ? wake_atomic_t_function+0x60/0x60
[  245.974149]  [] ? intel_pre_plane_update+0x19d/0x1b0 [i915]
[  245.974193]  [] ? intel_atomic_commit_tail+0x159/0xfe0 
[i915]
[  245.974206]  [] ? 
drm_atomic_helper_check_planes+0x185/0x1e0 [drm_kms_helper]
[  245.974210]  [] ? mutex_lock+0xe/0x30
[  245.974253]  [] ? intel_fbc_choose_crtc+0x1e/0x1e0 [i915]
[  245.974296]  [] ? intel_prepare_plane_fb+0x9d/0x280 [i915]
[  245.974339]  [] ? intel_atomic_commit+0x438/0x560 [i915]
[  245.974359]  [] ? drm_wait_one_vblank+0x71/0x1b0 [drm]
[  245.974402]  [] ? intel_release_load_detect_pipe+0x1f/0x80 
[i915]
[  245.974447]  [] ? intel_tv_detect+0x330/0x5e0 [i915]
[  245.974459]  [] ? 
drm_helper_probe_single_connector_modes+0x26b/0x510 [drm_kms_helper]
[  245.974483]  [] ? drm_mode_getconnector+0x317/0x360 [drm]
[  245.974487]  [] ? hrtimer_start_range_ns+0x190/0x3e0
[  245.974506]  [] ? drm_ioctl+0x1af/0x460 [drm]
[  245.974530]  [] ? drm_mode_getcrtc+0x120/0x120 [drm]
[  245.974534]  [] ? do_vfs_ioctl+0x9f/0x5f0
[  245.974537]  [] ? recalc_sigpending+0x17/0x50
[  245.974540]  [] ? SyS_ioctl+0x74/0x80
[  245.974543]  [] ? system_call_fast_compare_end+0xc/0x96
[  245.974546] ---[ end trace 6a623f3506f90deb ]---
[  246.239622] fuse init (API version 7.25)
[  264.416174] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] 
*ERROR* [CRTC:29:pipe B] flip_done timed out
[  264.520037] [ cut here ]
[  264.520078] WARNING: CPU: 0 PID: 958 at 
/build/linux-lIgGMF/linux-4.8.11/drivers/gpu/drm/drm_irq.c:1224 
drm_wait_one_vblank+0x1a3/0x1b0 [drm]
[  264.520080] vblank wait timed out on crtc 1
[  264.520082] Modules linked in: fuse binfmt_misc uvcvideo videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_core btusb videodev btrtl media btbcm 
btintel bluetooth nls_ascii nls_cp437 vfat fat isight_firmware iTCO_wdt 
iTCO_vendor_support joydev appletouch coretemp kvm_intel evdev kvm wl(POE) 
applesmc irqbypass input_polldev snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_hda_codec efi_pstore snd_hda_core pcspkr snd_hwdep snd_pcm 
efivars snd_timer cfg80211 lpc_ich sg snd mfd_core apple_bl rfkill soundcore 
i915 drm_kms_helper drm sbs sbshc button battery ac shpchp video i2c_algo_bit 
acpi_cpufreq tpm_tis tpm_tis_core tpm parport_pc ppdev lp parport efivarfs 
ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb 
glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64
[  264.520164]  mbcache hid_apple hid_appleir hid_generic usbhid hid sr_mod 
cdrom sd_mod ata_generic ata_piix ahci libahci firewire_ohci libata i2c_i801 
i2c_smbus firewire_core scsi_mod crc_itu_t sky2 ehci_pci fjes uhci_hcd ehci_hcd 
usbcore usb_common
[  264.520190] CPU: 0 PID: 958 Comm: Xorg Tainted: PW  OE   
4.8.0-2-amd64 #1 Debian 4.8.11-1
[  264.520191] Hardware name: Apple Inc. MacBook4,1/Mac-F22788A9, BIOS 
MB41.88Z.00C1.B0

Bug#849710: override: virt-what:admin/optional

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

Hi,

virt-what doesn't conflicts with other packages and doesn't have specialized
requirements. In accordance with Debian Policy, the right priority is optional.
So, I am asking for change from extra to optional. The current package in
unstable already sets optional.

Thanks in advance!

Regards,

Eriberto

Bug#849708: override: ocaml-libvirt:ocaml/optional

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

Hi,

ocaml-libvirt doesn't conflicts with other packages and doesn't have
specialized requirements. In accordance with Debian Policy, the right
priority is optional. So, I am asking for change from extra to optional.
The current package in unstable already sets optional.

Thanks in advance!

Regards,

Eriberto

Bug#849709: override: virt-top:admin/optional

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

Hi,

virt-top doesn't conflicts with other packages and doesn't have specialized
requirements. In accordance with Debian Policy, the right priority is optional.
So, I am asking for change from extra to optional. The current package in
unstable already sets optional.

Thanks in advance!

Regards,

Eriberto

Bug#849707: gksu grants root priveleges without password

[Darrin Swanson]

Package: gksu
Version: 2.0.2-9
Severity: important

Dear Maintainer,

I installed gksu on a new jessie 8.6 system; it grants super user privelege
without prompting for root password.

I have searched for solutions on the internet, but found none. Uninstalling and
reinstalling gksu doesn't solve the issue. I have found no keyrings which may
be storing the root password.

This is a serious security breach.



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 gksu depends on:
ii  gconf-service 3.2.6-3
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u7
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgconf-2-4  3.2.6-3
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libgksu2-02.0.13~pre1-8
ii  libglib2.0-0  2.42.1-1+b1
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libstartup-notification0  0.12-4
ii  sudo  1.8.10p3-1+deb8u3

Versions of packages gksu recommends:
ii  gnome-keyring  3.14.0-1+b1

gksu suggests no packages.

-- no debconf information

Bug#849217: jruby: FTBFS (sbuild hangs)

[Miguel Landaeta]

owner 849217 !
tags 849217 + moreinfo help
thanks

On Fri, Dec 23, 2016 at 06:49:41PM +0100, Santiago Vila wrote:
> Package: src:jruby
> Version: 1.7.26-1
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>
> [...]
> 
> E: Build killed with signal TERM after 60 minutes of inactivity
> 
> 
> In this case, sbuild aborted the build because it detected too much
> time without log activity, which is what happens when the build hangs.
> 
> If you need a full build log, just say so and I will include it,
> but the build also hangs in the reproducible builds autobuilders:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jruby.html
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the page for this package.
> 

Hello Santiago,

Can you provide the full log of the failed build attempt?

I can't reproduce this issue, although I don't use sbuild to build my
packages but cowbuilder.

Since I couldn't reproduce the issue with my builder tool of choice,
I'll setup sbuild later to try again. In the meantine, the full build
log could be handy.

Any help to diagnose/reproduce the issue is more than welcome.

Thanks,

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid” / freeimage API issues

[James Cowgill]

Control: severity -1 grave

Hi,

This is RC because nothing using ogre will start anymore.

On 29/12/16 21:52, Thibaut Girka wrote:
> Package: libogre-1.9.0v5
> Version: 1.9.0+dfsg1-7+b2
> Severity: important
> 
> Any Ogre game/application (for instance, funguloids, available in Debian)
> crashes with the following output:
> 
>   Creating resource group General
>   Creating resource group Internal
>   Creating resource group Autodetect
>   SceneManagerFactory for type 'DefaultSceneManager' registered.
>   Registering ResourceManager for type Material
>   Registering ResourceManager for type Mesh
>   Registering ResourceManager for type Skeleton
>   MovableObjectFactory for type 'ParticleSystem' registered.
>   ArchiveFactory for archive type FileSystem registered.
>   ArchiveFactory for archive type Zip registered.
>   ArchiveFactory for archive type EmbeddedZip registered.
>   DDS codec registering
>   FreeImage version: 3.17.0
>   This program uses FreeImage, a free, open source image library supporting 
> all common bitmap formats. See http://freeimage.sourceforge.net for details
>   terminate called after throwing an instance of 'std::logic_error'
> what():  basic_string::_M_construct null not valid
>   Abandon
> 
> This started happening since upgrading libfreeimage3, so this might be a bug 
> in
> it rather than in Ogre itself, but I haven't investigated any further yet.

This appears to be a regression in the Debian patch applied in
libfreeimage3 3.17.0+ds1-4.

Ogre contains this (OgreMain/src/OgreFreeImageCodec.cpp:98):
> for (int i = 0; i < FreeImage_GetFIFCount(); ++i)
> {
>   // Skip DDS codec since FreeImage does not have the option 
>   // to keep DXT data compressed, we'll use our own codec
>   if ((FREE_IMAGE_FORMAT)i == FIF_DDS)
>   continue;
>   
>   String exts(FreeImage_GetFIFExtensionList((FREE_IMAGE_FORMAT)i));
[loop body continues]
[String is typedefed to std::string]

This code assumes that FreeImage_GetFIFExtensionList will never return
NULL for values of i between 0 and FreeImage_GetFIFCount(). However in
the most recent Debian version of freeimage,
FreeImage_GetFIFExtensionList(27 / FIF_FAXG3) does return NULL.

It is unclear to me who is wrong here. The documentation does not
suggest anything about when FreeImage_GetFIFExtensionList can fail,
although the examples always check FreeImage_FIFSupportsReading before
calling it. Can any freeimage maintainer suggest the best way to fix this?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#849706: please re-enable Heimdal GSSAPI support

[Jelmer Vernooij]

Package: libsasl2-2
Version: 2.1.27~101-g0780600+dfsg-1
Severity: wishlist

Please re-enable the building of the libsasl2-modules-gssapi-heimdal package in
cyrus-sasl2.

My apologies for requesting this so quickly after requesting the removal of this
binary package and so briefly before the freeze. The timing is so unfortunate
because the threat of removal of Heimdal from a Debian release (of which that
previous request was a part) helped emphasize the urgency of a release to
upstream - and so a release eventually happened in mid-December after a 5 year
silence. 

I'm working on a patch to reverse the removal of 
libsasl2-modules-gssapi-heimdal.

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

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

Versions of packages libsasl2-2 depends on:
ii  libc62.24-8
ii  libsasl2-modules-db  2.1.27~101-g0780600+dfsg-1

Versions of packages libsasl2-2 recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-1

libsasl2-2 suggests no packages.

-- no debconf information

Bug#849593: libfftw3-single3: dependencies in shlibs file not tight enough (Was: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe)

[James Cowgill]

Hi,

On 30/12/16 00:50, Ghislain Vaillant wrote:
> On Thu, 29 Dec 2016 00:30:58 + James Cowgill  wrote:
>> Control: severity -1 serious
>> Control: clone -1 -2
>> Control: reassign -2 libfftw3-single3 3.3.5-1
>> Control: block -1 by -2
>> Control: retitle -2 libfftw3-single3: dependencies in shlibs file not tight 
>> enough
>>
>> Hi,
>>
>> On 29/12/16 00:02, Oleksandr Gavenko wrote:
>>> Package: ardour
>>> Version: 1:5.5.0~dfsg-1
>>> Severity: important
>>>
>>> Application is being crashing constantly with:
>>>
>>> bash# ardour5
>>> /usr/lib/ardour5/ardour-5.5.0: symbol lookup error: 
>>> /usr/lib/ardour5/ardour-5.5.0: undefined symbol: 
>>> fftwf_make_planner_thread_safe
>> [...]
>>> Versions of packages ardour depends on:
>> [...]
>>> ii  libfftw3-single3 3.3.4-2
> 
> How come? Both testing and unstable have 3.3.5-1.

I don't think that matters. Partial upgrades should work (and
derivatives may rely on it).

>> This package is the problem. The fftwf_make_planner_thread_safe
>> function is only present in fftw3 3.3.5 (so upgrading your package
>> would fix this). fftw3 should generate a stricter dependency so that
>> this doesn't happen.
> 
> libfftw3-dev depends on libfftw3_single3 (=${binary:Version}).
> 
> How is that not strict enough?

I'm talking about the dependency from ardour to libfftw3_single3. The
dependency from libfftw3-dev doesn't matter here.

>> fftw3 maintainers: to fix this you either need to provide a symbols
>> file, or pass a suitable -V option to dh_makeshlibs so the shlibs file
>> contains a stricter dependency.
> 
> Please be more explicit about the expected outcome (i.e. the stricter
> dependency you keep mentioning).

Please read policy 8.6 which describes most of this more fully.

The goal is for dpkg-shlibdeps to generate a dependency like
"libfftw3-single3 (>= 3.3.5)" for any package which uses
fftwf_make_planner_thread_safe. This is needed otherwise you may get a
linker error like ardour does, and it's is done by using the symbols or
shlibs systems as described in policy 8.6.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#849705: unrtf: Stack buffer overflow

[Skylake]

Package: unrtf
Version: 0.21.9-clean-2

I've found a Stack-based buffer overflow in unrtf 0.21.9, which affects three 
functions including: cmd_expand, cmd_emboss and cmd_engrave.

# convert.c

static int
cmd_expand (Word *w, int align, char has_param, int param) {
char str[10];
if (has_param) {
sprintf(str, "%d", param/4); // Overflow, 9-digit negative value triggers the 
bug
if (!param)
attr_pop(ATTR_EXPAND);
else
attr_push(ATTR_EXPAND, str);
}
return FALSE;
}

Apparently writing a negative integer to the buffer can trigger the overflow 
(Minus sign needs an extra byte).

* How to trigger the bug *

$ echo "\expnd-4" > poc
$ unrtf poc






*** buffer overflow detected ***: unrtf terminated
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xb764f37a]
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xb76dfe07]
/lib/i386-linux-gnu/libc.so.6(+0xf60a8)[0xb76de0a8]
/lib/i386-linux-gnu/libc.so.6(+0xf58b8)[0xb76dd8b8]
/lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0xa6)[0xb7653bf6]
/lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0xf66)[0xb762b1d6]
/lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0x90)[0xb76dd950]
/lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x20)[0xb76dd8a0]
unrtf[0x804c7b8]
unrtf[0x804f77d]
unrtf[0x804f9e7]
unrtf[0x804920b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7600276]
unrtf[0x804953c]
=== Memory map: 
08048000-0805b000 r-xp  08:01 405354 /usr/bin/unrtf
0805b000-0805c000 r--p 00012000 08:01 405354 /usr/bin/unrtf
0805c000-0805d000 rw-p 00013000 08:01 405354 /usr/bin/unrtf
0805d000-08085000 rw-p  00:00 0
0952d000-0954e000 rw-p  00:00 0 [heap]
b75ca000-b75e6000 r-xp  08:01 393233 
/usr/lib/i386-linux-gnu/libgcc_s.so.1
b75e6000-b75e7000 r--p 0001b000 08:01 393233 
/usr/lib/i386-linux-gnu/libgcc_s.so.1
b75e7000-b75e8000 rw-p 0001c000 08:01 393233 
/usr/lib/i386-linux-gnu/libgcc_s.so.1
b75e8000-b7799000 r-xp  08:01 395818 
/usr/lib/i386-linux-gnu/libc-2.24.so
b7799000-b779b000 r--p 001b 08:01 395818 
/usr/lib/i386-linux-gnu/libc-2.24.so
b779b000-b779c000 rw-p 001b2000 08:01 395818 
/usr/lib/i386-linux-gnu/libc-2.24.so
b779c000-b779f000 rw-p  00:00 0
b77a3000-b77a6000 rw-p  00:00 0
b77a6000-b77a8000 r--p  00:00 0 [vvar]
b77a8000-b77aa000 r-xp  00:00 0 [vdso]
b77aa000-b77cc000 r-xp  08:01 393914 /usr/lib/i386-linux-gnu/ld-2.24.so
b77cc000-b77cd000 rw-p  00:00 0
b77cd000-b77ce000 r--p 00022000 08:01 393914 /usr/lib/i386-linux-gnu/ld-2.24.so
b77ce000-b77cf000 rw-p 00023000 08:01 393914 /usr/lib/i386-linux-gnu/ld-2.24.so
bf992000-bf9b3000 rw-p  00:00 0 [stack]
Aborted

* Test environment *

Linux debian 4.7.0-1-686-pae #1 SMP Debian 4.7.8-1 (2016-10-19) i686 GNU/Linux
libc6 2.24-8

Regards,
Amir


Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#849593: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe

[Ghislain Vaillant]

On Thu, 29 Dec 2016 00:30:58 + James Cowgill  wrote:
> Control: severity -1 serious
> Control: clone -1 -2
> Control: reassign -2 libfftw3-single3 3.3.5-1
> Control: block -1 by -2
> Control: retitle -2 libfftw3-single3: dependencies in shlibs file not tight 
> enough
> 
> Hi,
> 
> On 29/12/16 00:02, Oleksandr Gavenko wrote:
> > Package: ardour
> > Version: 1:5.5.0~dfsg-1
> > Severity: important
> > 
> > Application is being crashing constantly with:
> > 
> > bash# ardour5
> > /usr/lib/ardour5/ardour-5.5.0: symbol lookup error: 
> > /usr/lib/ardour5/ardour-5.5.0: undefined symbol: 
> > fftwf_make_planner_thread_safe
> [...]
> > Versions of packages ardour depends on:
> [...]
> > ii  libfftw3-single3 3.3.4-2

How come? Both testing and unstable have 3.3.5-1.

> This package is the problem. The fftwf_make_planner_thread_safe
> function is only present in fftw3 3.3.5 (so upgrading your package
> would fix this). fftw3 should generate a stricter dependency so that
> this doesn't happen.

libfftw3-dev depends on libfftw3_single3 (=${binary:Version}).

How is that not strict enough?

> fftw3 maintainers: to fix this you either need to provide a symbols
> file, or pass a suitable -V option to dh_makeshlibs so the shlibs file
> contains a stricter dependency.

Please be more explicit about the expected outcome (i.e. the stricter
dependency you keep mentioning).

Thanks,
Ghis

Bug#849704: mate-screensaver: Please package and upload 1.17.0 as it has some gtk+3 commits

[shirish शिरीष]

Package: mate-screensaver
Version: 1.16.0-1
Severity: wishlist

Dear Maintainer,
Please upload 1.17.0 as soon as possible as once we hit 2017-01-05: we
will be hit by "Soft" freeze which means no new packages, no re-entry
as well. although normal migrations will be allowed.

Looking at the upstream commit messages
https://github.com/mate-desktop/mate-screensaver/commits/master , the
following are the changes upstream -

@raveit65

release 1.17.0
raveit65 committed on Nov 25
@raveit65

sync with transifex
raveit65 committed on Nov 25
Commits on Nov 21, 2016

@monsta

move to GTK+3 (>= 3.14), drop GTK+2 code and --with-gtk build option

monsta committed on Nov 21
1
@monsta

fix indent a bit
monsta committed on Nov 21
@monsta

build: require libmate-menu 1.10
monsta committed on Nov 21
Commits on Oct 20, 2016

@gapan

Also look for gdm-binary process

gapan committed on Oct 20
Commits on Oct 2, 2016

@raveit65

GTK+-3 gs-grab-x11: use correct GTK_VERSION_CHECK

raveit65 committed on Oct 2

While we have no idea when MATE will release 1.18.0 it would be nice
if for the whole stretch cycle we have minimum gtk+3 issues.

Just my 2 paise.

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

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

Versions of packages mate-screensaver depends on:
ii  dbus-x11  1.10.14-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-8
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-1
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libgl1-mesa-glx [libgl1]  13.0.2-3
ii  libglib2.0-0  2.50.2-2
ii  libgtk-3-03.22.5-1
ii  libice6   2:1.0.9-1+b1
ii  libmate-desktop-2-17  1.16.1-1
ii  libmate-menu2 1.16.0-1
ii  libmatekbd4   1.16.0-1
ii  libnotify40.7.7-1
ii  libpam0g  1.1.8-3.3
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libsm62:1.2.2-1+b1
ii  libstartup-notification0  0.12-4
ii  libsystemd0   232-8
ii  libx11-6  2:1.6.4-2
ii  libxext6  2:1.3.3-1
ii  libxklavier16 5.4-2
ii  libxss1   1:1.2.2-1
ii  libxxf86vm1   1:1.1.4-1
ii  mate-desktop-common   1.16.1-1
ii  mate-screensaver-common   1.16.0-1
ii  mate-session-manager  1.16.0-2

Versions of packages mate-screensaver recommends:
ii  mate-power-manager  1.16.0-1

Versions of packages mate-screensaver suggests:
ii  rss-glx0.9.1-6+b4
ii  xscreensaver-data  5.34-2

-- no debconf information

-- 
  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#845450: Found the cause

[LRN]

After once again trying to make it work i finally found out why this is
happening (i kind of knew *what* was happening, but not why).

Turns out, Kodi does indeed have separate stereoscopic modes - input mode (i.e.
what kind of content the file has) and output mode (i.e. how Kodi UI, and
subtitles, should be rendered).

One is changed in the 3d-glass-options-button, and its default value can be
changed in Player/Videos section of Kodi global settings.
The other is changed separately in video settings when playing a file, and it
is absent from global settings. Instead, current file settings can be saved as
defaults for all media.

What happened to me was that, apparently, i've switched media file settings
from Auto to Side-by-Side at some point, and saved it as default for all
further files, without understanding what i was doing. This might have been
necessary due to Kodi misdetecting media stereoscopic layout, i don't know.

Anyway, this bug can be either closed as not-a-bug, or fixed with some kind of
doc-fix. One could argue that it's not good to be able to have mismatching
input/output stereoscopic settings, as this can easily degrade the picture
quality, but this feature does have legitimate uses (quality degradation
notwithstanding), and it's not up to Debian package maintainers to change that
anyway.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


0x6759BA74.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Harlan Lieberman-Berg]

Toni Mueller  writes:
> I hope I can collaborate with the maintainer of the ansible package to
> maintain this package.

For the record, the Ansible packaging team stands by to help however we
can.

Thanks, Toni!

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

Package: wnpp
Severity: wishlist
Owner: Toni Mueller 

* Package name: ansible-doc
  Version : 2.2.0.0-1
  Upstream Author : RedHat 
* URL : http://www.ansible.com/
* License : GPL-3
  Programming Lang: HTML, JavaScript
  Description : Documentation for Ansible

Currently, the Ansible package in Debian lacks proper offline
documentation. This package aims to supply the documentation in HTML
form offline, so one should not need to go to the aoupstream website to
read it.

Yours truly frequently suffers under bad network conditions, which make
reading the website infeasible or outright impossible, so I think the
package is useful.

I hope I can collaborate with the maintainer of the ansible package to
maintain this package.
 

Bug#849702: RM: gotmail -- ROM; No longer useful- web services used no longer exist

[paul cannon]

Package: ftp.debian.org
Severity: normal

Gotmail was a web scraper for fetching mail from Hotmail.com and
MSN.com. Those services are now powered by live.com, which is wholly
different and which (as I understand it) can now forward messages on its
own more simply.

p

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[John Paul Adrian Glaubitz]

On 12/29/2016 10:36 PM, Andreas Bombe wrote:
> If I upload now, it won't be part of the stretch release.

Ok, I actually overlooked the fact that the package hasn't entered
testing yet at all. Then it's indeed a good idea to wait first
and then upload the fixed package.

> but who guarantees that mips and mipsel will still be
> release architectures for buster?

I think it's very unlikely that mips and mipsel are being removed
for Buster given the fact that there are 8 active porters. We don't
get rid of architectures just because they aren't fancy new 64-bit
architectures although some people in Debian would want to see
that.

> So I'd rather have it work on all release architectures and actually be
> in the release.

Yes, but please let's update the package as soon as it has entered
testing. It will still be able to migrate, although I'm not 100%
sure whether it will be blocked on mips/mipsel but we'll see.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#849701: can't handle Chinese characters in the title bar

[Toni Mueller]

Package: sakura
Version: 3.3.4-3
Severity: normal


Hi,

I just discovered that Sakura apparently cannot handle UTF-8 window
titles. Please see the attached screenshot, which shows two carets with
question marks, where I would like to see two Chinese characters.


Thank you!


Cheers,
--Toni++



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

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

Versions of packages sakura depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-2
ii  libgnutls30  3.5.7-2
ii  libgtk-3-0   3.22.5-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpcre2-8-0 10.22-2
ii  libvte-2.91-00.46.1-1
ii  zlib1g   1:1.2.8.dfsg-4

sakura recommends no packages.

sakura suggests no packages.

-- no debconf information

Bug#818230: Fwd: aircrack-ng: please make the build reproducible

[Samuel Henrique]

Hi Reiner,

Could you please follow up the discussion at[1]?

I added you as a collaborator on my fork, so what you push there will
update on the PR (check your email for a github collab. invite)

[1]https://github.com/aircrack-ng/aircrack-ng/pull/91

Samuel Henrique 

2016-12-25 18:13 GMT-02:00 Reiner Herrmann :

> Control: tags -1 + patch
>
> On Sun, Dec 25, 2016 at 11:05:56AM -0200, Samuel Henrique wrote:
> > Could you please update the patch to rc4? I would be infinitely grateful
> :)
>
> Updated patch attached. :)
>
> > Also, i believe you can also send this upstream, but if you don't, i can
> do
> > that for you.
>
> Please send it upstream, thanks!
>
> Regards,
>   Reiner
>
>
>
>

Bug#836016: netcfg: Drop unnecessary loopback config in /etc/network/interfaces

[Philipp Kern]

Hi,

On 08/30/2016 10:17 AM, Martin Pitt wrote:
> Please drop it as this is unnecessary extra parsing work at boot. I
> attach an untested (only build-tested) initial patch. The main thing
> I'm not sure about is whether this actually needs to clear
> /etc/network/interfaces when NetworkManager is installed -- would
> anything write "real" interfaces to /e/n/i in this case?

it needs to, yes. Otherwise you end up with the interface being
unmanaged from n-m, despite the n-m snippet having been written. I
suppose what we could do is just empty it out. At least trying that out
was successful for me. I also tested the non n-m case and that was fine.

> In a more general vein, ifupdown creates an appropriate /e/n/i on
> package installation already. It would be nicer if netcfg would not
> completly overwrite this and instead just add files to
> /etc/network/interfaces.d/

Yeah, I suppose we could do that. Is there already a naming convention
here? Would /etc/network/interfaces.d/${interface}.conf work? (Note that
for n-m we use a generic untranslated "Wired connection 1" with no
adapter matching specified in the snippet.)

Similarly I guess we could pre-configure systemd-networkd in some way,
but right now there's no package to check for. (Which is how we
determine if network-manager configuration needs to be written out.)

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#848947: closed by Jerome Benoit (Bug#848947: fixed in bibtool 2.66+ds-2)

[gi1242+debianbugs]

Thanks! I confirm it's fixed on my system with the update.

GI

-- 
File not found. Should I fake it? (Y/N)

Bug#846991: Please migrate to emacs25

[Rob Browning]

Rob Browning  writes:

> For example, assuming the package works with emacs25, a dependency like
>
>   emacs25-nox | emacs25 | emacs24
>
> should suffice.

Actually that does appear to work, once some additional minor changes
are made.

Checked via sid sbuild, and testing the install/remove and basic
functionality of the resulting package after applying this patch:

diff --git a/debian/control b/debian/control
index c33b77b..ec9b6b4 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,8 @@ Homepage: https://launchpad.net/vm
 Priority: optional
 Maintainer: Manoj Srivastava 
 Standards-Version: 3.9.6
-Build-Depends-Indep: debhelper (>= 9.0.0), autotools-dev, emacs24,
+Build-Depends-Indep: debhelper (>= 9.0.0), autotools-dev,
+ emacs25-nox | emacs25 | emacs24,
  texinfo, texlive-latex-base, texlive-fonts-recommended
 
 Package: vm
diff --git a/debian/vm.postinst b/debian/vm.postinst
index cb67d19..86267bb 100644
--- a/debian/vm.postinst
+++ b/debian/vm.postinst
@@ -186,7 +186,7 @@ case "$1" in
 fi
 
 if which ucfr >/dev/null; then
-for flavour in emacs24 emacs22 emacs23 emacs-snapshot xemacs21; do
+for flavour in emacs25 emacs24 emacs22 emacs23 emacs-snapshot xemacs21; do
 	STARTDIR=/etc/$flavour/site-start.d;
 	STARTFILE="${package_name}-init.el";
 if [ -e "$STARTDIR/50$STARTFILE" ]; then
diff --git a/debian/vm.postrm b/debian/vm.postrm
index 23245eb..bf48510 100644
--- a/debian/vm.postrm
+++ b/debian/vm.postrm
@@ -117,7 +117,7 @@ case "$1" in
 rm -f -f $ELDIR/vm.elc
 fi
 
-for flavour in emacs24 emacs22 emacs23 emacs-snapshot xemacs21; do
+for flavour in emacs25 emacs24 emacs22 emacs23 emacs-snapshot xemacs21; do
 ELCDIR=/usr/share/$flavour/site-lisp/$package_name/
 if [ -f /etc/$flavour/site-start.d/50vm-init.el ]; then
 rm -f /etc/$flavour/site-start.d/50vm-init.el
@@ -136,7 +136,7 @@ case "$1" in
 
 # This package has previously been removed and is now having
 # its configuration purged from the system.
-for flavour in emacs24 emacs22 emacs23 emacs-snapshot xemacs21; do
+for flavour in emacs25 emacs24 emacs22 emacs23 emacs-snapshot xemacs21; do
 	STARTDIR=/etc/$flavour/site-start.d;
 	STARTFILE="${package_name}-init.el";
 if which ucf >/dev/null; then

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#844147: ck: FTBFS: build timeout

[Robert Edmonds]

Lucas Nussbaum wrote:
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

> The full build log is available from:
>http://aws-logs.debian.net/2016/11/11/ck_0.4.4-1_unstable.log
> 
> This failure happens on a CPU with TSX extensions available, but is not
> reproducible on a machine without them. For context, I recommend reading the
> thread starting at https://lists.debian.org/debian-devel/2016/11/msg00210.html
> 
> The node used is an Amazon EC2 VM with 64 cores. /proc/cpuinfo says:
>model: 79
>model name : Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
>stepping : 1

Hi, Lucas:

If I understand the upstream source correctly, TSX support is not
enabled unless --enable-rtm is explicitly passed to the configure
script, which we don't do for the Debian build. According to your build
log, RTM is disabled:

   RTM = CK_MD_RTM_DISABLE

So I'm confused as to how TSX support in the build system's CPU could be
the cause. I think your FTBFS might actually be due to #764827 ("ck:
upper bound on cores being used in tests"). It looks like building on
systems with a high number of cores can cause the test suite to take an
unreasonable amount of time, so I've uploaded 0.5.2-2 which limits the
number of cores used to a small value.

Could you retry your build with ck >= 0.5.2-2 once it hits the archive?

Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Bug#849700: mcedit does not more work

[Michelle Konzack]

Package: mc
Version: 3:4.8.3-10

Since I updated my Debian 7 mc does not more work!

Exactly following happen:

I write THIS E-Mail to the BTS and have to avoid hiting ENTER for a  new
line because otherwise it show me the dialog SAVE.

When I klick ENTER or CANCEL (have  to  do  this  continously),  in  the
background the newly written file crippled and destroyed.

I use MC every day for programming, but this  error  happen  AFTER  this
update:

[ /var/log/apt/term-2016-12.log ]---
Log started: 2016-12-27  15:30:18
(Reading database ... =0D(Reading database ... 5%=0D(Reading database ... 
10%=0D(Reading database ... 15%=0D(Reading database ... 20%=0D(Reading database 
... 25%=0D(Reading database ... 30%=0D(Reading database ... 35%=0D(Reading 
database ... 40%=0D(Reading database ... 45%=0D(Reading database ... 
50%0D(Reading database ... 55%=0D(Reading database ... 60%=0D(Reading database 
... 65%=0D(Reading database ... 70%=0D(Reading database ... 75%=0D(Reading 
database ... 80%=0D(Reading database ... 85%=0D(Reading database ... 
90%=0D(Reading database ... 95%=0D(Reading database ... 100%=0D(Reading 
database ... 114497 files and directories currently installed.)=0D
Preparing to replace bash 4.2+dfsg-0.1+deb7u3 (using 
.../bash_4.2+dfsg-0.1+deb7u4_amd64.deb) ...=0D
Unpacking replacement bash ...=0D
Processing triggers for man-db ...=0D
Processing triggers for menu ...=0D
Setting up bash (4.2+dfsg-0.1+deb7u4) ...=0D
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide 
/usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode=0D
Processing triggers for menu ...=0D
(Reading database ... =0D(Reading database ... 5%=0D(Reading database ... 
10%=0D(Reading database ... 15%=0D(Reading database ... 20%=0D(Reading database 
... 25%=0D(Reading database ... 30%=0D(Reading database ... 35%=0D(Reading 
database ... 40%=0D(Reading database ... 45%=0D(Reading database ... 
50%=0D(Reading database ... 55%=0D(Reading database ... 60%=0D(Reading database 
... 65%=0D(Reading database ... 70%=0D(Reading database ... 75%=0D(Reading 
database ... 80%=0D(Reading database ... 85%=0D(Reading database ... 
90%=0D(Reading database ... 95%=0D(Reading database ... 100%=0D(Reading 
database ... 114497 files and directories currently installed.)=0D
Preparing to replace tar 1.26+dfsg-0.1 (using 
.../tar_1.26+dfsg-0.1+deb7u1_amd64.deb) ...=0D
Unpacking replacement tar ...=0D
Processing triggers for mime-support ...=0D
Processing triggers for man-db ...=0D
Setting up tar (1.26+dfsg-0.1+deb7u1) ...=0D
(Reading database ... =0D(Reading database ... 5%=0D(Reading database ... 
10%=0D(Reading database ... 15%=0D(Reading database ... 20%=0D(Reading database 
... 25%=0D(Reading database ... 30%=0D(Reading database ... 35%=0D(Reading 
database ... 40%=0D(Reading database ... 45%=0D(Reading database ... 
50%=0D(Reading database ... 55%=0D(Reading database ... 60%=0D(Reading database 
... 65%=0D(Reading database ... 70%=0D(Reading database ... 75%=0D(Reading 
database ... 80%=0D(Reading database ... 85%=0D(Reading database ... 
90%=0D(Reading database ... 95%=0D(Reading database ... 100%=0D(Reading 
database ... 114497 files and directories currently installed.)=0DPreparing to 
replace imagemagick-common 8:6.7.7.10-5+deb7u7 (using 
.../imagemagick-common_8%3a6.7.7.10-5+deb7u10_all.deb) ...=0DUnpacking 
replacement imagemagick-common ...=0D
Preparing to replace libxml2:amd64 2.8.0+dfsg1-7+wheezy6 (using .../libxml2=
_2.8.0+dfsg1-7+wheezy7_amd64.deb) ...=0D
De-configuring libxml2:i386 ...=0D
Unpacking replacement libxml2:amd64 ...=0D
Preparing to replace libxml2:i386 2.8.0+dfsg1-7+wheezy6 (using 
.../libxml2_2.8.0+dfsg1-7+wheezy7_i386.deb) ...=0D
Unpacking replacement libxml2:i386 ...=0D
Setting up libxml2:amd64 (2.8.0+dfsg1-7+wheezy7) ...=0D
ldconfig: /usr/lib/x86_64-linux-gnu/libarchive.so.12 is not a symbolic link=0D
=0D
Setting up libxml2:i386 (2.8.0+dfsg1-7+wheezy7) ...=0D
ldconfig: /usr/lib/x86_64-linux-gnu/libarchive.so.12 is not a symbolic link=0D
=0D
(Reading database ... =0D(Reading database ... 5%=0D(Reading database ... 
10%=0D(Reading database ... 15%=0D(Reading database ... 20%=0D(Reading database 
... 25%=0D(Reading database ... 30%=0D(Reading database ... 35%=0D(Reading 
database ... 40%=0D(Reading database ... 45%=0D(Reading database ... 
50%=0D(Reading database ... 55%=0D(Reading database ... 60%=0D(Reading database 
... 65%=0D(Reading database ... 70%=0D(Reading database ... 75%=0D(Reading 
database ... 80%=0D(Reading database ... 85%=0D(Reading database ... 
90%=0D(Reading database ... 95%=0D(Reading database ... 100%=0D(Reading 
database ... 114497 files and directories currently installed.)=0D
Preparing to replace libarchive12:amd64 3.0.4-3+wheezy3 (using 
.../libarchive12_3.0.4-3+wheezy5_amd64.deb) ...=0D
Unpacking replacement libarchive12:amd64 ...=0D
Preparing to replace libavutil51:amd64 6:0.8.17-2+deb7u2 (using 
.../libavutil51_6%3a0.8.18-0+deb7u1_amd64.

Bug#849699: [mtr] Please package v0.87

[Samuel Henrique]

Source: mtr
Version: 0.86-1
Severity: wishlist
Tags: patch

Hello, while having a general look for packages who might need updates for
Stretch, i found out that mtr was outdated and decided to take a look at it.

I have made several changes to the packaging while updating it to v0.87,
you can see the package on mentors[1] and at collab-maint[2].

I would like to co-maintain mtr with you, but if you feel like not to,
please feel free to use my changes without adding me as an uploader (note
that the package on mentors and collab does that).

Here's a short summary of the main changes i've made:
* Bump DH level to 10.
* Enable bindnow hardening flag.
* Create a d/clean file to allow multiple builds.
* Bump Standards-Version to 3.9.8.
* Add a watch file.
* Convert copyright to DEP-5.
* Start using git for packaging.

I belive updating to v.087 will also let Ubuntu sync with us again, as
they've patched mtr to fix an upstream problem not present anymore on 0.87.

There's also a considerable amount of bugs which i believe should be
closed, they were marked as fixed but not closed. If you accept my help, i
can do some bug triage :)

[1]:https://mentors.debian.net/package/mtr
[2]:https://anonscm.debian.org/git/collab-maint/mtr.git

Samuel Henrique 

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

[Sean Whitton]

Hello again Jörg,

On Thu, Dec 29, 2016 at 10:16:13PM +, Sean Whitton wrote:
> We are almost ready to upload.

I found one more issue...

- /usr/share/xtrkcad/{logo.bmp, html, examples, demo} should be in 
/usr/share/doc/xtrkcad

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842222: Two node-babel ITPs

[Adrian Bunk]

Control: forcemerge -1 849291

Hi,

both of you sent ITPs for node-babel, please coordinate regarding who 
will actually package it.

Thanks
Adrian

-- 

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

Bug#846987: Please migrate to emacs25

[Rob Browning]

Rob Browning  writes:

> For example, assuming the package works with emacs25, a dependency like
>
>   emacs25-nox | emacs25 | emacs24
>
> should suffice.

...and it appears to.  A sid sbuild was successful, and the resulting
package seemed to work fine with emacs25.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#846985: Please migrate to emacs25

[Rob Browning]

Rob Browning  writes:

> For example, assuming the package works with emacs25, a dependency like
>
>   emacs25-nox | emacs25 | emacs24
>
> should suffice.

...and it appears to.  A sid sbuild was successful, and the resulting
package seemed to work fine with emacs25.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#849698: jessie-pu: package python-crypto/2.6.1-5+deb8u1

[Sebastian Ramacher]

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

Hi

I'd like to fix CVE-2013-7459 (#849495) in jessie via the next point release.
The issue was marked as no-dsa.

The proposed debdiff is attached. The same patch was applied to the package in
unstable.

Cheers
-- 
Sebastian Ramacher
diff --git a/debian/changelog b/debian/changelog
index ecee2bf..0a58374 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-crypto (2.6.1-5+deb8u1) jessie; urgency=high
+
+  [ Salvatore Bonaccorso ]
+  * Throw exception when IV is used with ECB or CTR (CVE-2013-7459)
+(Closes: #849495)
+
+ -- Sebastian Ramacher   Thu, 29 Dec 2016 18:03:48 +0100
+
 python-crypto (2.6.1-5) unstable; urgency=medium
 
   * debian/patches/asn1-decoding.patch: Fix TypeError in ASN1 implementation.
diff --git a/debian/patches/CVE-2013-7459.patch 
b/debian/patches/CVE-2013-7459.patch
new file mode 100644
index 000..f7c6d81
--- /dev/null
+++ b/debian/patches/CVE-2013-7459.patch
@@ -0,0 +1,84 @@
+From 8dbe0dc3eea5c689d4f76b37b93fe216cf1f00d4 Mon Sep 17 00:00:00 2001
+From: Legrandin 
+Date: Sun, 22 Dec 2013 22:24:46 +0100
+Subject: [PATCH] Throw exception when IV is used with ECB or CTR
+
+The IV parameter is currently ignored when initializing
+a cipher in ECB or CTR mode.
+
+For CTR mode, it is confusing: it takes some time to see
+that a different parameter is needed (the counter).
+
+For ECB mode, it is outright dangerous.
+
+This patch forces an exception to be raised.
+---
+ lib/Crypto/SelfTest/Cipher/common.py | 31 +++
+ src/block_template.c | 11 +++
+ 2 files changed, 34 insertions(+), 8 deletions(-)
+
+--- a/lib/Crypto/SelfTest/Cipher/common.py
 b/lib/Crypto/SelfTest/Cipher/common.py
+@@ -239,19 +239,34 @@ class RoundtripTest(unittest.TestCase):
+ return """%s .decrypt() output of .encrypt() should not be garbled""" 
% (self.module_name,)
+ 
+ def runTest(self):
+-for mode in (self.module.MODE_ECB, self.module.MODE_CBC, 
self.module.MODE_CFB, self.module.MODE_OFB, self.module.MODE_OPENPGP):
++
++## ECB mode
++mode = self.module.MODE_ECB
++encryption_cipher = self.module.new(a2b_hex(self.key), mode)
++ciphertext = encryption_cipher.encrypt(self.plaintext)
++decryption_cipher = self.module.new(a2b_hex(self.key), mode)
++decrypted_plaintext = decryption_cipher.decrypt(ciphertext)
++self.assertEqual(self.plaintext, decrypted_plaintext)
++
++## OPENPGP mode
++mode = self.module.MODE_OPENPGP
++encryption_cipher = self.module.new(a2b_hex(self.key), mode, self.iv)
++eiv_ciphertext = encryption_cipher.encrypt(self.plaintext)
++eiv = eiv_ciphertext[:self.module.block_size+2]
++ciphertext = eiv_ciphertext[self.module.block_size+2:]
++decryption_cipher = self.module.new(a2b_hex(self.key), mode, eiv)
++decrypted_plaintext = decryption_cipher.decrypt(ciphertext)
++self.assertEqual(self.plaintext, decrypted_plaintext)
++
++## All other non-AEAD modes (but CTR)
++for mode in (self.module.MODE_CBC, self.module.MODE_CFB, 
self.module.MODE_OFB):
+ encryption_cipher = self.module.new(a2b_hex(self.key), mode, 
self.iv)
+ ciphertext = encryption_cipher.encrypt(self.plaintext)
+-
+-if mode != self.module.MODE_OPENPGP:
+-decryption_cipher = self.module.new(a2b_hex(self.key), mode, 
self.iv)
+-else:
+-eiv = ciphertext[:self.module.block_size+2]
+-ciphertext = ciphertext[self.module.block_size+2:]
+-decryption_cipher = self.module.new(a2b_hex(self.key), mode, 
eiv)
++decryption_cipher = self.module.new(a2b_hex(self.key), mode, 
self.iv)
+ decrypted_plaintext = decryption_cipher.decrypt(ciphertext)
+ self.assertEqual(self.plaintext, decrypted_plaintext)
+ 
++
+ class PGPTest(unittest.TestCase):
+ def __init__(self, module, params):
+ unittest.TestCase.__init__(self)
+--- a/src/block_template.c
 b/src/block_template.c
+@@ -170,6 +170,17 @@ ALGnew(PyObject *self, PyObject *args, P
+   "Key cannot be the null string");
+   return NULL;
+   }
++  if (IVlen != 0 && mode == MODE_ECB)
++  {
++  PyErr_Format(PyExc_ValueError, "ECB mode does not use IV");
++  return NULL;
++  }
++  if (IVlen != 0 && mode == MODE_CTR)
++  {
++  PyErr_Format(PyExc_ValueError,
++  "CTR mode needs counter parameter, not IV");
++  return NULL;
++  }
+   if (IVlen != BLOCK_SIZE && mode != MODE_ECB && mode != MODE_CTR)
+   {
+   PyErr_Format(PyExc_ValueError,
diff --git a/debian/patches/series b/debian/patches/series
index e077da9..191ab43 100644
--- a/debian/pat

Bug#849697: lshw: Option -version broken

[Christoph Biedl]

Source: lshw
Version: 02.18-0.1
Severity: normal
Tags: upstream patch

Dear Maintainer,

the stretch version of lshw no longer shows the version information:

$ lshw -version
unknown

The reason is in lshw-B.02.18/src/core/version.cc: The versiontag
definition in line 13 contains a variable $URL$ that was expanded
to an URL in earlier versions, then getpackageversion() picked the
version number from that path (which is, err, interesting). This
no longer works and the code falls back to "unknown".

The patch attached changes getpackageversion to use a defined constant
that is picked from the lshw.spec file. By doing so you can also drop
the hard-coded line in debian/rules.

Afterwards:

$ lshw -version
B.02.18

Regards,
Christoph

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

Kernel: Linux 4.9.0 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

diff --git a/debian/patches/restore-version-option.patch b/debian/patches/restore-version-option.patch
new file mode 100644
index 000..1c12ef1
--- /dev/null
+++ b/debian/patches/restore-version-option.patch
@@ -0,0 +1,26 @@
+Subject: Restore the -version command line option
+Author: Christoph Biedl 
+Forwarded: No
+
+--- a/lshw-B.02.18/src/core/version.cc
 b/lshw-B.02.18/src/core/version.cc
+@@ -27,6 +27,8 @@
+ 
+ const char *getpackageversion()
+ {
++  return UVERSION;
++
+   static char * result = NULL;
+   char * lastslash = NULL;
+ 
+--- a/lshw-B.02.18/src/Makefile
 b/lshw-B.02.18/src/Makefile
+@@ -20,7 +20,7 @@
+ 
+ CXX?=c++
+ INCLUDES=-I./core/
+-DEFINES=-DPREFIX=\"$(PREFIX)\" -DSBINDIR=\"$(SBINDIR)\" -DMANDIR=\"$(MANDIR)\" -DDATADIR=\"$(DATADIR)\"
++DEFINES=-DPREFIX=\"$(PREFIX)\" -DSBINDIR=\"$(SBINDIR)\" -DMANDIR=\"$(MANDIR)\" -DDATADIR=\"$(DATADIR)\" -DUVERSION=\"$(UVERSION)\"
+ #CXXFLAGS=-g -Wall -g $(INCLUDES) $(DEFINES) $(RPM_OPT_FLAGS)
+ CXXFLAGS=$(CXX_DEB_FLAGS) $(INCLUDES) $(DEFINES) 
+ ifeq ($(SQLITE), 1)
diff --git a/debian/patches/series b/debian/patches/series
index c4eb7c4..6c87466 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -11,3 +11,4 @@ spelling-error.patch
 fix-manpage.patch
 Avoid-crash-in-scan_dmi_sysfs-when-running-as-non-ro.patch
 fix-width-handling.patch
+restore-version-option.patch
diff --git a/debian/rules b/debian/rules
index e1c7189..1fad8d0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,8 +26,8 @@ ifeq ($(DEB_BUILD_GNU_TYPE),alpha-linux-gnu)
 endif
 
 
-uver=B.02.18
-srcdir=lshw-$(uver)/src
+export UVERSION=$(shell awk '($$1=="Version:"){print $$2}' lshw.spec | head -1)
+srcdir=lshw-$(UVERSION)/src
 
 configure: configure-stamp
 configure-stamp:


signature.asc
Description: Digital signature

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

[Sean Whitton]

control: tag -1 +moreinfo

Hello Jörg,

On Thu, Dec 29, 2016 at 07:03:26PM +0100, Jörg Frings-Fürst wrote:
> first thanks for your first review.

No problem.

I've now taken a proper look at your copyright file.  Some problems:

- the "FreeBSD" license has a standard shortname: BSD-2-clause

- did you make up the 'mixed', 'BSD-Revised' and 'permissive' license
  shortnames?  I suspect there are standard names -- try
  http://codesearch.debian.net

- you can't claim 2017 copyright on debian/ since we will upload this
  before 2017 begins :)

- if you run `licensecheck --copyright -r .` you will find many files
  that are Copyright 2005 David Bullis.  Maybe you should add this to
  the "Files: *" stanza?

- Mikko Nissinen also holds copyright on app/i18n/stripmsg.c

- copyright years for getopt.*, uthash.h, gwin32.c, mswbitmap.c and
  others are wrong -- why did you add '-2015' when the file was not
  edited since the earlier year?

- copyright for app/tools/halibut/charset/macenc.c wrong

> > >   Changes since the last upload:
> > > 
> > >   * New Maintainer (Closes: #849139):
> > > - debian/control: Add myself as maintainer.
> > > - debian/copyright: Add myself to debian/*.
> > >   * New upstream release (Closes: #847843, #784423).
> > 
> > In #847843, Mike Gabriel suggests team maintenance of xtrkcad.  Have you
> > got in touch with him about maintaining xtrkcad together?  Is he aware
> > of your ITA?  #847843 is itself almost an ITA, and it was submitted only
> > very recently, so you should be sure that your upload doesn't treat on
> > Mike's toes.
> > 
> My mistake. I have only skimmed through the text. I have ask Mike per
> mail and add him as Uploader.

Great.  I suggest writing "(Closes: #847843)" next to the Uploader
change -- it is okay to 'close' a bug more than once in a single upload.

> >   * Remove debian/source/options.
> > 
> > Why?
> 
> To use the default compression. Comment is added.

Okay.

> >
> > >   * Remove debian/source.lintian-overrides.
> > >   * Change debian/compat to 10 (no changes required).
> > >   * debian/control:
> > > - Bump Standards-Version to 3.9.8 (no changes required).
> > > - Bump debhelper B-D minimum version to 10.
> > > - Add Vcs-* tags.
> > > - Change Priority from extra to optional.
> > 
> > Just a reminder that you will have to submit a bug against
> > ftp.debian.org to have this actually take effect (post-adoption).
> > 
> 
> Because of the Priority change?
> 
> The change was based on the comment at the old PTS[1].

Ah.  You could mention this in your changelog, so I wouldn't ask the
question :)  E.g.

- Change Priority from extra to optional.
  To match current ftp-master override file.

> > >   * debian/rules:
> > >    - Enable hardening.
> > >   * New debian/patches/0700-info_file.patch to add requested directory 
> > > entry
> > > and INFO-DIR-SECTION.
> > >   * Rewrite debian/watch to use the sf redirector.
> > > - Add files to exclude in debian/copyright.
> > >   * Rewrite debian/copyright.
> > 
> > Lintian tags you can easily fix:
> > 
> > I: xtrkcad source: vcs-field-uses-insecure-uri vcs-git 
> > git://anonscm.debian.org/collab-maint/xtrkcad.git
> 
> My option to not change git to https was to start a git-gui client
> directly. If you want I change it.

Are you saying that git-gui cannot use https URIs?

It's okay to keep git:// if it is more convenient for you.

> > I: xtrkcad: spelling-error-in-binary usr/bin/xtrkcad Minumum Minimum
> 
> I have add a new patch 0900-spelling-errors.patch to correct the
> spelling error.

Thanks, and great work forwarding the patch.

> > It looks like you used wrap-and-sort -- please add this to the
> > changelog, so a future contributor knows which options to use.  E.g.
> > 
> > * Run wrap-and-sort -abst

You haven't added this to the changelog yet...

> > 
> > You made changes to d/rules not documented in the changelog.
> 
> sry. Also I don't have a git commit message. I have add a comment about
>  this.

What do you mean about "git commit message"?

Changelog for d/rules LGTM.

>
>  
> > 
> > After making further changes, don't forget to re-run `dch -r`, and
> > please remove the moreinfo tag from this bug to put it back in my queue.
> > 
> done

Ditto for this second review.

We are almost ready to upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848781: [Debichem-devel] Bug#848781: tiledarray: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Michael Banck]

Hi,

On Mon, Dec 19, 2016 at 10:26:11PM +0100, Lucas Nussbaum wrote:
> > unknown location(0): fatal error: in 
> > "distributed_storage_suite/array_operator": memory access violation at 
> > address: 0x7f53709e95d0: no mapping at fault address
> > /<>/tests/distributed_storage.cpp(102): last checkpoint: 
> > "array_operator" entry.
> > unknown location(0): fatal error: in 
> > "distributed_storage_suite/array_operator": memory access violation at 
> > address: 0x7fc69c66f5d0: no mapping at fault address
> > /<>/tests/distributed_storage.cpp(102): last checkpoint: 
> > "array_operator" entry.
> > E: Build killed with signal TERM after 150 minutes of inactivity

Upstream is now on this and could reproduce the issue, see
https://github.com/ValeevGroup/tiledarray/issues/100 

I've had a look at the new upstream version (0.6.0), and I've also
switch libmadness-dev and (locally) tiledarray to MPICH, but that did
only help in so far as the build is no longer hung after the fatal
error, but just errors out, proceeding to the binary-arch stage and
succeeding eventually (as we ignore test suite failures).

So it would no longer FTBFS, but there's still something fishy going on
here.


Michael

Bug#847101: kimchi source updated

[Lucio Correia]

I've uploaded new source with latest upstream release (2.3.1):

dget -x 
https://mentors.debian.net/debian/pool/main/k/kimchi/kimchi_2.3.1-1.dsc


Regards,
--
Lucio Correia

Bug#849658: [Debichem-devel] Bug#849658: ga: FTBFS on arm*: src/locks/locks.c:16:1: error: unknown type name 'PAD_LOCK_T'

[Michael Banck]

severity 849658 important
thanks

Hi,

On Thu, Dec 29, 2016 at 03:57:34PM +, Chris West (Faux) wrote:
> Source: ga
> Version: 5.4~beta~r10636+dfsg-3
> Severity: serious
> Justification: fails to build from source
> Tags: sid stretch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> The package fails to build:
> 
> libtool: compile:  mpicc -DHAVE_CONFIG_H -I. -I./src/devices/sockets 
> -I./src/include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -c src/locks/locks.c  
> -fPIC -DPIC -o src/locks/.libs/locks.o
> src/locks/locks.c:16:1: error: unknown type name 'PAD_LOCK_T'
>  PAD_LOCK_T *_armci_int_mutexes;
>  ^~

Thanks for the notice, but AFAICT this is not a regression, so I'm
adjusting the severity.  I'm afraid it needs porting to arm (and some
other architectures).


Michael

Bug#847102: ginger source updated

[Lucio Correia]

I've uploaded a new source package with new upstream release (2.3.1):

dget -x 
https://mentors.debian.net/debian/pool/main/g/ginger/ginger_2.3.1-1.dsc


Regards,
--
Lucio Correia

Bug#847102: RFS: ginger/2.3.0-1 - HTML5-based host management tool

[Lucio Correia]

Hi,

On Mon, 19 Dec 2016 08:06:40 +0100 Tobias Frost  wrote:

Control: block 775747 by -1

Please retitle the "RFP" bug (#775747) to "ITP" and set yourself as
owner.

--
tobi


OK, trying to find out how to do that.

Regards,
--
Lucio Correia

Bug#849483: debian-policy: emacs build dependencies probably need adjustment

[Rob Browning]

Rob Browning  writes:

> And finally, we'd like to remove emacs24 from the archive as soon as
> it's feasible, so please try to upgrade to emacs25, or add optional
> support for emacs25 as soon as you can.
>
> For example, assuming the package works with emacs25, a dependency like
>
>   emacs25-nox | emacs25 | emacs24
>
> should suffice.

Actually it looks like debian/rules will also need a minor adjustment,
i.e. perhaps change this:

  EMACS := emacs24

to

  EMACS := emacs

or similar.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid”

[Thibaut Girka]

Package: libogre-1.9.0v5
Version: 1.9.0+dfsg1-7+b2
Severity: important

Any Ogre game/application (for instance, funguloids, available in Debian)
crashes with the following output:

  Creating resource group General
  Creating resource group Internal
  Creating resource group Autodetect
  SceneManagerFactory for type 'DefaultSceneManager' registered.
  Registering ResourceManager for type Material
  Registering ResourceManager for type Mesh
  Registering ResourceManager for type Skeleton
  MovableObjectFactory for type 'ParticleSystem' registered.
  ArchiveFactory for archive type FileSystem registered.
  ArchiveFactory for archive type Zip registered.
  ArchiveFactory for archive type EmbeddedZip registered.
  DDS codec registering
  FreeImage version: 3.17.0
  This program uses FreeImage, a free, open source image library supporting all 
common bitmap formats. See http://freeimage.sourceforge.net for details
  terminate called after throwing an instance of 'std::logic_error'
what():  basic_string::_M_construct null not valid
  Abandon

This started happening since upgrading libfreeimage3, so this might be a bug in
it rather than in Ogre itself, but I haven't investigated any further yet.

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

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

Versions of packages libogre-1.9.0v5 depends on:
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-8
ii  libegl1-mesa [libegl1-x11]  13.0.2-3
ii  libfreeimage3   3.17.0+ds1-4
ii  libfreetype62.6.3-3+b1
ii  libgcc1 1:6.2.1-5
ii  libgl1-mesa-glx [libgl1]13.0.2-3
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libstdc++6  6.2.1-5
ii  libx11-62:1.6.4-2
ii  libxaw7 2:1.0.13-1
ii  libxrandr2  2:1.5.1-1
ii  libxt6  1:1.1.5-1
ii  libzzip-0-130.13.62-3
ii  zlib1g  1:1.2.8.dfsg-4

libogre-1.9.0v5 recommends no packages.

libogre-1.9.0v5 suggests no packages.

-- no debconf information

Bug#847108: ginger-base source updated

[Lucio Correia]

I've uploaded a new package with latest upstream version:

dget -x
https://mentors.debian.net/debian/pool/main/g/ginger-base/ginger-base_2.2.2-1.dsc

Regards,
--
Lucio Correia

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[Andreas Bombe]

On Thu, Dec 29, 2016 at 10:18:07PM +0100, John Paul Adrian Glaubitz wrote:
> That's correct. But I usually rather prefer fixing a package everywhere
> than just saying "Works on amd64, I don't care about the rest because
> I don't use anything else.".
>
> My point is, if you upload it now, you have more testing time for the
> package on all release architectures being part of testing and more
> time to make sure the patch is not breaking anything else.

If I upload now, it won't be part of the stretch release. I'd definitely
have a lot of time for testing then, but who guarantees that mips and
mipsel will still be release architectures for buster?

So I'd rather have it work on all release architectures and actually be
in the release.


Andreas

Bug#849695: sslsniff: libraries should be linked in LDADD, not LDFLAGS (FTBFS with ld --as-needed)

[Logan Rosen]

Package: sslsniff
Version: 0.8-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

In Makefile.am, libraries are linked against in LDFLAGS (which is meant for
linker options), not LDADD. This causes an FTBFS with ld --as-needed in
Ubuntu, where the order of linking matters.

See 
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries 
for more
information.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/Add-missing-libraries-at-link-time.patch: Update to add
libraries to LDADD instead of LDFLAGS, fixing FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru sslsniff-0.8/debian/patches/Add-missing-libraries-at-link-time.patch sslsniff-0.8/debian/patches/Add-missing-libraries-at-link-time.patch
--- sslsniff-0.8/debian/patches/Add-missing-libraries-at-link-time.patch	2016-11-22 11:02:04.0 -0500
+++ sslsniff-0.8/debian/patches/Add-missing-libraries-at-link-time.patch	2016-12-29 16:24:36.0 -0500
@@ -19,6 +19,6 @@
  sslsniff_SOURCES = Bridge.hpp SSLConnectionManager.cpp FingerprintManager.hpp FirefoxAddonUpdater.hpp FirefoxUpdater.hpp HTTPSBridge.hpp Logger.hpp RawBridge.hpp SessionCache.hpp SSLBridge.hpp SSLConnectionManager.hpp sslsniff.hpp UpdateManager.hpp certificate/AuthorityCertificateManager.hpp certificate/Certificate.hpp certificate/CertificateManager.hpp certificate/TargetedCertificateManager.hpp http/HttpBridge.hpp http/HttpConnectionManager.hpp http/HttpHeaders.hpp http/OCSPDenier.hpp util/Destination.cpp util/Destination.hpp util/Util.hpp FirefoxUpdater.cpp Logger.cpp SessionCache.cpp SSLBridge.cpp HTTPSBridge.cpp sslsniff.cpp FingerprintManager.cpp certificate/AuthorityCertificateManager.cpp certificate/TargetedCertificateManager.cpp certificate/CertificateManager.cpp http/HttpBridge.cpp http/HttpConnectionManager.cpp http/HttpHeaders.cpp UpdateManager.cpp http/OCSPDenier.cpp FirefoxAddonUpdater.cpp
  
 -sslsniff_LDFLAGS = -lssl -lboost_filesystem -lpthread -lboost_thread -llog4cpp
-+sslsniff_LDFLAGS = -lssl -lboost_filesystem -lpthread -lboost_thread -llog4cpp -lcrypto -lboost_system
++sslsniff_LDADD = -lssl -lboost_filesystem -lpthread -lboost_thread -llog4cpp -lcrypto -lboost_system
  
  EXTRA_DIST = certs/wildcard IPSCACLASEA1.crt leafcert.pem updates/Darwin_Universal-gcc3.xml updates/Linux_x86-gcc3.xml updates/WINNT_x86-msvc.xml

Bug#849478: closed by Ola Lundqvist (Re: [Pkg-tigervnc-devel] Bug#849478: tigervnc: CVE-2014-8241: NULL pointer dereference flaw in XRegion)

[Ola Lundqvist]

Hi

Thank you. I'll check again. I probably failed to check this as most
were rejected and I checked almost all other lines.

// Ola

On 29 December 2016 at 22:03, Salvatore Bonaccorso  wrote:
> Control: reopen -1
> Control: found -1 1.6.0+dfsg-4
>
> On Thu, Dec 29, 2016 at 07:18:11PM +, Debian Bug Tracking System wrote:
>> Hi Salvatore
>>
>> I have looked into this bug however and this one is indeed solved.
>> Unless I'm looking with very grumble eyes (I probably do as I should
>> be in bed).
>
> The problem should be in lines 1079-1090:
>
> 1077 else
> 1078 {
> 1079 /*
> 1080  * No point in doing the extra work involved in an Xrealloc if
> 1081  * the region is empty
> 1082  */
> 1083 newReg->size = 1;
> 1084 Xfree((char *) newReg->rects);
> 1085 newReg->rects = (BoxPtr) Xmalloc(sizeof(BoxRec));
> 1086 }
> 1087 }
> 1088 Xfree ((char *) oldRects);
> 1089 return;
> 1090 }
>
> The patch from Red Hat, does add a check for newReg->rects, which in above is
> missing (cf. Lines after 1085).
>
> Hope this helps.
>
> Regards,
> Salvatore



-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[Andreas Bombe]

On Wed, Dec 28, 2016 at 04:29:52PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/28/2016 04:18 PM, Radovan Birdic wrote:
> > Here is new generic patch that should work for all architectures.
> > I added "--as-needed" flag that ensures linking with latomic library only 
> > if it is necessary.
> > 
> > With this patch package builds successfully on mips, mipsel, mips64el and 
> > i386.
> 
> And on powerpc as well, just verified on the porterbox.
> 
> Thanks for the updated patch!

Thanks for the work. I was aware of the build failure but I will wait
until the package has made it to testing before uploading a fix.

That patch would also enable --as-needed generally as I understand it. I
didn't try that, but if it works so much the better.

I will upload this fix in a few days then.


Andreas

Bug#847105: wok source updated

[Lucio Correia]

I've uploaded a new source package containing:

- Updated to latest upstream version (2.3.1)
- Fixes for Andreas' review comments, except separated packaging of 
javascripts, for which I'm working on.


Regards,

--
Lucio Correia

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[John Paul Adrian Glaubitz]

On 12/29/2016 10:15 PM, Andreas Bombe wrote:
> 1) Right now would still be too late with the 10 day transition in
>effect.

Well, it would reset the transition counter back to 10 days.

> 2) Unless I'm mistaken, a build failure on release architectures is only
>a blocker if it previously built on that architecture. At least the
>testing excuses list appears to only mention age < 10 days to block
>transition.

That's correct. But I usually rather prefer fixing a package everywhere
than just saying "Works on amd64, I don't care about the rest because
I don't use anything else.".

My point is, if you upload it now, you have more testing time for the
package on all release architectures being part of testing and more
time to make sure the patch is not breaking anything else.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[Andreas Bombe]

On Thu, Dec 29, 2016 at 10:02:01PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/29/2016 09:57 PM, Andreas Bombe wrote:
> > Thanks for the work. I was aware of the build failure but I will wait
> > until the package has made it to testing before uploading a fix.
> 
> Not sure why. It affects two release architectures, so the package would
> be missing in testing for release architectures. I would upload it right
> away to have the package fixed everywhere on all release architectures
> as soon as possible, but it's, of course, up to you.

1) Right now would still be too late with the 10 day transition in
   effect.
2) Unless I'm mistaken, a build failure on release architectures is only
   a blocker if it previously built on that architecture. At least the
   testing excuses list appears to only mention age < 10 days to block
   transition.

Either way, an upload right now would be no help at best.


Andreas

Bug#839695: qemu: GTK3 configure options not used in build

[Michael Tokarev]

29.12.2016 20:15, Jindřich Makovička wrote:
> I was trying to build a patched QEMU package, and for some reason, GTK3
> options were not passed to configure - I had to put them on separate lines:
> 
> # gtk display (see also sdl display)
> # --enable-gtk
> # --with-gtkabi=3.0
> # --enable-vte
>  libgtk-3-dev, libvte-2.91-dev,

I fixed it in git. Thank you for the report and investigation!

/mjt

Bug#746005: please migrate to guile-2.0

[Dr. Tobias Quathamer]

Am 29.12.2016 um 20:43 schrieb Anthony Fok:

So, how about the following?

 1. Include a local copy of guile-1.8 (multiple upstream tarballs)
 in our LilyPond 1.18.2 packaging, probably compiling guile-1.8 statically
 into so that a functional and stable LilyPond can stay in Debian.

I would be happy to do all the hands-on work, and provide the
necessary patches if successful, to make #1 happen before the Stretch
Freeze.


Hi Anthony,

thanks for your ideas to help LilyPond stay in Debian stable -- however, 
I'm afraid that we're a bit late with that. As you're probably aware of, 
LilyPond is currently not in testing. The release managers have set this 
deadline:


[2017-Jan-05]
Soft freeze (no new packages, no re-entry, 10-day migrations)

At this point, we don't have ten days left for the migration to testing, 
even if we could upload right now. Unfortunately, this means that 
lilypond will not be allowed to re-enter testing.


I think you would need to ask the release managers if they would unblock 
this package for Stretch, otherwise an upload will not make much sense.


To be honest, I doubt that they will grant a freeze exception, even more 
so if the plan is to include guile 1.8, which has been removed from 
testing for a while now.


Regards,
Tobias




signature.asc
Description: OpenPGP digital signature

Bug#849694: baresip: should build-depend on libssl-dev, FTBFS in Ubuntu

[Logan Rosen]

Package: baresip
Version: 0.4.20-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

baresip should build-depend on libssl-dev because it links against it. It pulls
in this build dependency transitively in Debian, but it doesn't in Ubuntu,
causing it to FTBFS. [1]

In Ubuntu, the attached patch was applied to achieve the following:

  * Add ssl to dev-deps and regenerate debian/control to fix FTBFS.

Thanks for considering the patch.

Logan Rosen

[1] 
https://launchpadlibrarian.net/299660980/buildlog_ubuntu-zesty-amd64.baresip_0.4.20-1_BUILDING.txt.gz

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

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru baresip-0.4.20/debian/control baresip-0.4.20/debian/control
--- baresip-0.4.20/debian/control	2016-12-22 06:58:27.0 -0500
+++ baresip-0.4.20/debian/control	2016-12-29 15:59:07.0 -0500
@@ -18,6 +18,7 @@
  libspandsp-dev,
  libvpx-dev,
  libopus-dev,
+ libssl-dev,
  pkg-config
 Maintainer: Debian VoIP Team 
 Uploaders: Vasudev Kamath ,
diff -Nru baresip-0.4.20/debian/rules baresip-0.4.20/debian/rules
--- baresip-0.4.20/debian/rules	2016-12-22 06:41:55.0 -0500
+++ baresip-0.4.20/debian/rules	2016-12-29 15:59:07.0 -0500
@@ -13,7 +13,7 @@
 
 # Build-Depends
 dev-deps = cairo2 rem asound2 avcodec avformat avdevice
-dev-deps += gstreamer1.0 re evdev gsm1 spandsp vpx opus
+dev-deps += gstreamer1.0 re evdev gsm1 spandsp vpx opus ssl
 
 CDBS_BUILD_DEPENDS += , $(patsubst %, $(comma) lib%-dev,$(dev-deps))
 CDBS_BUILD_DEPENDS += , pkg-config

Bug#370337: Fwd: Re: Make /etc/default/slapd automatically configurable

[Petter Reinholdtsen]

[Ryan Tandy]
> It looks like it's possible using gnutls-cli >= 3.5.0.
>
> gnutls-cli -p 389 --x509cafile /etc/ldap/certs/ca.crt
> --starttls-proto=ldap --save-cert=ldap.example.org.crt
> ldap.example.org < /dev/null

Seem to work like a charm here:

% gnutls-cli -p 389 --x509cafile /etc/ldap/certs/ca.crt \
  --starttls-proto=ldap   --save-cert=ldap.example.org.crt \
  192.168.1.16 < /dev/null
Error setting the x509 trust file
Resolving '192.168.1.16:389'...
Connecting to '192.168.1.16:389'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject 
`EMAIL=postmaster@postoffice.intern,CN=tjener.intern,OU=Automatically-generated 
LDAP SSL key,O=LDAP server,L=Skolen,ST=NA,C=NO', issuer 
`EMAIL=postmaster@postoffice.intern,CN=tjener.intern,OU=Automatically-generated 
LDAP SSL key,O=LDAP server,L=Skolen,ST=NA,C=NO', serial 0x00cbe2455339cab094, 
RSA key 1024 bits, signed using RSA-SHA1, activated `2012-02-02 17:24:28 UTC', 
expires `2022-01-30 17:24:28 UTC', key-ID 
`sha256:9885ac708688fa6fe941371a32ecdec6891a428647932e72ae9b01bc0075420a'
Public Key ID:
sha1:995429e2f6e72af62e353d864e8c276249ad0c25

sha256:9885ac708688fa6fe941371a32ecdec6891a428647932e72ae9b01bc0075420a
Public key's random art:
+--[ RSA 1024]+
|  .. |
|  E . . ...  |
|   o o ...   |
|  . . +. o   |
|   + + +So   |
|* o O =  |
|   . . * = . |
|  + . .  |
| . =+.   |
+-+

- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
The name in the certificate does not match the expected. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.
% diff -ur ~/ldap.example.org.crt /etc/ldap/ssl/ldap-server-pubkey.pem 
%

I guess this mean we can change /etc/init.d/fetch-ldap-cert and stop
editing /etc/default/slapd.

-- 
Happy hacking
Petter Reinholdtsen

Bug#849478: closed by Ola Lundqvist (Re: [Pkg-tigervnc-devel] Bug#849478: tigervnc: CVE-2014-8241: NULL pointer dereference flaw in XRegion)

[Salvatore Bonaccorso]

Control: reopen -1
Control: found -1 1.6.0+dfsg-4

On Thu, Dec 29, 2016 at 07:18:11PM +, Debian Bug Tracking System wrote:
> Hi Salvatore
> 
> I have looked into this bug however and this one is indeed solved.
> Unless I'm looking with very grumble eyes (I probably do as I should
> be in bed).

The problem should be in lines 1079-1090:

1077 else
1078 {
1079 /*
1080  * No point in doing the extra work involved in an Xrealloc if
1081  * the region is empty
1082  */
1083 newReg->size = 1;
1084 Xfree((char *) newReg->rects);
1085 newReg->rects = (BoxPtr) Xmalloc(sizeof(BoxRec));
1086 }
1087 }
1088 Xfree ((char *) oldRects);
1089 return;
1090 }

The patch from Red Hat, does add a check for newReg->rects, which in above is
missing (cf. Lines after 1085).

Hope this helps.

Regards,
Salvatore

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[John Paul Adrian Glaubitz]

On 12/29/2016 09:57 PM, Andreas Bombe wrote:
> Thanks for the work. I was aware of the build failure but I will wait
> until the package has made it to testing before uploading a fix.

Not sure why. It affects two release architectures, so the package would
be missing in testing for release architectures. I would upload it right
away to have the package fixed everywhere on all release architectures
as soon as possible, but it's, of course, up to you.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Sean Whitton]

Hello Pierre,

On Thu, Dec 29, 2016 at 09:20:02PM +0100, Pierre-Elliott Bécue wrote:
> Le mardi 27 décembre 2016 à 22:11:38+, Sean Whitton a écrit :
> > Hello Pierre,
> > 
> > On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote:
> > > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit :
> > > > control: tag -1 +moreinfo
> > > > 
> > > > Dear Pierre,
> > > > 
> > > > Thank you for your interest in adopting this package.
> > > > 
> > > > Unfortunately, your work has not been properly integrated with what is
> > > > already in Debian:
> > > > 
> > > > - you marked version 0.4.74-4 as released but it was never uploaded
> > > 
> > > True. Yet, it is in the team repo.
> > 
> > The changelog tracks the Debian archive.  You should merge the existing
> > 0.4.74-4 changelog entry with your changes.
> 
> 0.4.74-4 is not in the debian archive, only in the team repo. How should I
> merge exactly?

This is roughly what I have in mind:

pyvtk (0.5.18-1) unstable; urgency=low

  [ Jakub Wilk ]
  * Use canonical URIs for Vcs-* fields.
  * Remove obsolete Conflicts/Replaces with python2.3-pyvtk and
python2.4-pyvtk.

  [ Stefano Rivera ]
  * Convert inline patch to 3.0 (quilt) to ease git-dpm migration.

  [ Ondřej Nový ]
  * Fixed VCS URL (https)

  [ Pierre-Elliott Bécue ]
  * New maintainer (Closes: #795017).
  * New upstream release
  * Uses pybuild for building the package.
  * Cleaning debian/*

 -- Pierre-Elliott Bécue   Sat, 17 Dec 2016 00:24:15 +0200

> > > > - your work is not pushed to the team git repository
> > > 
> > > I have no permission to push.
> > 
> > Have you asked to join the team?
> 
> I don't feel that I've done enough to get permissions, maybe my
> interpretation is wrong.

I see what you mean, and every Debian team is different.

However, chances are they would prefer that you join the team and push
your git history there, as then other team members can more easily build
upon your work.

So please submit a request, explaining that you want to work on pyvtk.
If they say no, it's not a big deal!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849581: RFS: numpydoc/0.6.0+ds1-1

[Sean Whitton]

Hello Ghislain,

On Thu, Dec 29, 2016 at 03:35:23PM +, Ghislain Vaillant wrote:
> I pushed a refreshed tag pointing at the latest commit already:
> 
> https://anonscm.debian.org/cgit/python-modules/packages/numpydoc.git/tag/?h=debian/0.6.0%2bds1-1
> 
> Isn't that enough?

It's fine, it just might cause some confusion later on since there are
two tags in existence, with the same name but signed by different
people.

This was basically my fault for not telling dgit not to create the
second tag.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845710: RFS: mongovi/1.0.0-1 [ITP]

[Sean Whitton]

Dear Tim,

On Thu, Dec 29, 2016 at 07:51:56PM +0100, Tim Kuijsten wrote:
> On Thu, Dec 29, 2016 at 06:46:58PM +, Sean Whitton wrote:
> > control: tag -1 +moreinfo
> > 
> > Dear Tim,
> > 
> > Is this package available in a git repository?
> > 
> > The Vcs-* headers point to a repo that does not contain a debian/
> > directory.  They should point to a repository containing the source
> > package.
> 
> Ah, I thought it was the general repository, not Debian specific :)
> Then I guess it's best to remove the VCS link, rigth?

I think it would be best to keep the packaging in a git repository and
point Vcs-* there, but if you prefer not to, it would be best to remove
those fields, yes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849640: linux-image-4.8.0-0.bpo.2-amd64: The display comes up black with the 4.8.11 kernel on intel graphics, skylake processor

[Steinar Bang]

> Ben Hutchings :

> But this motherboard apparently doesn't have a DisplayPort.  Perhaps
> the driver is confused about this.

> Which type of connector is the monitor really plugged into?

A VGA connector.

Bug#847843: Debian bug #847843

[Mike Gabriel]

Hi Jörg,

On  Do 29 Dez 2016 17:15:52 CET, Jörg Frings-Fürst wrote:


Hello Mike,


xtrkcad is now orphaned[1] and I want to adopt it.

As you offered I have taken you as an uploader.

I plan to split the packages und asking the team after the stretch
freeze.

You find my work at[2].


CU
Jörg

[1] https://bugs.debian.org/849139
[2] https://anonscm.debian.org/cgit/collab-maint/xtrkcad.git


Cool! I missed the orphaning... Have you taken a look at my debian/  
folder as posted here [1]?


There are some improvements in that debian/ folder IIRC,

esp.

  debian/copyright (no wildcarded Files: section)
  debian/man/xtrkcad.1
  debian/control (package split-up in xtrkcad and xtrkcad-common)


Also interesting...

  debian/rules (the tarball recreation dropping various unneeded files)




Mike

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847843#5


--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpHc4Jx8RLAl.pgp
Description: Digitale PGP-Signatur

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Sean Whitton]

Hello Alberto,

On Thu, Dec 29, 2016 at 05:01:29PM +0100, Alberto Luaces wrote:
> Sean Whitton writes:
> >
> > If not, you should merge the changelog entries for -1 and -2.  It's just
> > confusing to have changlog entries that never made it into the Debian
> > archive.
> >
> 
> Well, it seemed cleaner than modifying an already published history, but
> I understand no solution is immune to drawbacks.  I have now pushed the
> new, fixed branch.  Please note that you will have to re-synchronise, or
> clone the repository again from scratch.

Oh dear, that wasn't what I meant!  I was suggesting you just make a
commit merging the changelog entries together.  Anyway, it's done now.

I'd like to suggest some improvements to your changelog:

>   * Updated d/control according to d.e.a.p.t. guidelines.

Only an existing team member would know what d.e.a.p.t. is!  Perhaps add
the URI ?

You also rewrote d/rules, but this is not mentioned in the changelog.

>   * Update standards to 3.9.8.

Did you have to change anything in the packaging for this update?  If
not, it's conventional to write "(no changes required)".

>   * Disabled parents in clojure mode due to upgrading errors.

This is meaningless to someone not already familiar with yasnippet.  You
wrote a great patch header, so I would suggest just this changelog
entry:

* Add 0001-Avoid-.dpkg-new-upgrading-error.patch

Please accept my apologies for not raising these suggestions in a
previous e-mail, and thank you for your patience with this sponsorship
process -- I'm confident I'll be able to upload after your next update.

(don't forget dch -r)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849693: haml-elisp: needs trivial change for emacs25

[Rob Browning]

Package: haml-elisp
Version: 1:3.1.0-3

After this patch, it appears to work fine in emacs25:

diff --git a/debian/haml-elisp.emacsen-install b/debian/haml-elisp.emacsen-install
index b3d88df..11f95d1 100644
--- a/debian/haml-elisp.emacsen-install
+++ b/debian/haml-elisp.emacsen-install
@@ -4,7 +4,7 @@ SRC_FILE="haml-mode.el"
 # Right now only emacs23 and emacs24 are supported. If the future
 # brings support for other emacsen, we can keep this same logic - just
 # update this regex
-SUPPORTED_EMACSEN="^emacs2[34]$"
+SUPPORTED_EMACSEN="^emacs2[345]$"
 FLAVOR="$1"
 
 if echo $FLAVOR | egrep -vq $SUPPORTED_EMACSEN; then

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#849688: Acknowledgement (package in debian/testing is development version, severely broken)

[Richard B. Kreckel]

On 12/29/2016 08:59 PM, Richard B. Kreckel asked:
> Can a user downgrade to 0.24 once he has started using 0.25.1?

On 12/29/2016 09:22 PM, Jens Georg replied:
> Yes, that's perfectly fine as long as you go for shotwell-0.24.3,
> otherwise you re-introduce an db index issue.

Bug#849660: [Ceph-maintainers] Bug#849660: ceph: FTBFS on armel: error: field 'result' has incomplete type 'std::promise'

[Gaudenz Steinlin]

Hi Emilio

Emilio Pozuelo Monfort  writes:

> Source: ceph
> Version: 10.2.5-2
> Severity: serious
>
> Your package failed to build on armel:
>
> utilities/backupable/backupable_db.cc:297:30: error: field 'result' has 
> incomplete type 'std::promise'
>  std::promise result;

I'm already working on the build issues on armel. Unfortunately without
much success until now. There are two main issues:

Building the NEON optimized variant of jerasure fails. This can be fixed
by either disabling NEON alltogether or by adding -mfloat-abi=softfp to
compilation of the relevant files. The second solution would be
preferable and builds OK. But I need to verify that this is really only
an optional run time selected "plugin" and no other code get's NEON
instructions as those are not generally available on armel machines. You
can see this problem a bit further up in the build log.

The second problem is much tricker to solve. Rocksdb relies on
std::future which does not work on armel due to a GCC bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

All my attempts to build ceph without rocksdb have failed so far. While
it's easy to disable to build of rocksdb itself, linking then fails
later because of missing symbols. I have not yet found a way to
completely disable all components that use rocksdb even if I only build
the client parts.

If I can't find a solution soon I'll probably request the removal of
ceph from armel. But this should only be a last resort option as there
are quite a few reverse dependencies.

Gaudenz

-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#734688: Logs are not rotated for a month

[Christoph Biedl]

Hello again everybody,

in order to get this issue finally resolved, I've contacted the
maintainer (Paul Martin) yesterday. Given the time of the year a reply
might take a few days. So for the moment: I've prepared a non-maintainer
upload for the new upstream version, please give it a try and report
back:

https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.11.0-0.1.dsc

Note about rebuilding: The test suite is rather picky about file system
specifics, using sbuild/overlay results in an error.

Cheers,
Christoph


signature.asc
Description: Digital signature

Bug#521932: ITA: songwrite -- guitar tablature editor and player

[Anthony Fok]

retitle 521932 ITA: songwrite -- guitar tablature editor and player
owner 521932 !
thanks

I am adopting songwrite to help it stay in Debian 9.0 "stretch", the
upcoming stable release.

The most important change is to change "Depends: lilypond" to a
"Recommend", so just in case lilypond does not make it, songwrite
could still stay in,
see http://bugs.debian.org/746005 for lilypond's struggle with the
removal of guile-1.8 and the incompatibility with guile-2.0.

The upload will happen later today.

The next steps will be to package python-editobj2 (?) and songwrite2,
which people say are much nicer, but that will be for some other day.
The upstream source tarballs are at http://download.gna.org/songwrite/
.

Cheers,
Anthony

Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Pierre-Elliott Bécue]

Le mardi 27 décembre 2016 à 22:11:38+, Sean Whitton a écrit :
> Hello Pierre,
> 
> On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote:
> > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit :
> > > control: tag -1 +moreinfo
> > > 
> > > Dear Pierre,
> > > 
> > > Thank you for your interest in adopting this package.
> > > 
> > > Unfortunately, your work has not been properly integrated with what is
> > > already in Debian:
> > > 
> > > - you marked version 0.4.74-4 as released but it was never uploaded
> > 
> > True. Yet, it is in the team repo.
> 
> The changelog tracks the Debian archive.  You should merge the existing
> 0.4.74-4 changelog entry with your changes.

0.4.74-4 is not in the debian archive, only in the team repo. How should I
merge exactly?

> > 
> > Actually, it is included. The commit is just hidden in the history of the
> > team git repository for an unknown reason. See commit
> > 53434cf161a64ab9ac1578fec3613cce20ed451b and merge commit
> > 6fd4d560cf1f1f25a581a28a3c0a93ebd3159386. I added manually the changelog
> > that has been truncated in the merge.
> 
> Sorry, my fault, thanks for fixing up the changelog in your upload.

No worries, you're welcome. :)

> > > - your work is not pushed to the team git repository
> > 
> > I have no permission to push.
> 
> Have you asked to join the team?

I don't feel that I've done enough to get permissions, maybe my
interpretation is wrong.

-- 
PEB


signature.asc
Description: PGP signature

Bug#849691: RFS: gnome-shell-extension-radio/1.4-1 [ITP] -- GNOME shell extension for listening to Internet radio streams

[leo]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnome-shell-extension-radio", 
(see ITP [1]) :


* Package name: gnome-shell-extension-radio
  Version : 1.4-1
  Upstream Author : hslbck 
* URL : 
https://github.com/hslbck/gnome-shell-extension-radio

* License : GPL-3+
  Section : gnome

It builds those binary packages:

  gnome-shell-extension-radio - GNOME shell extension for listening to 
Internet radio streams


The source package is available at [2].

Packaging is available at [3].

Everything is ready except a few contributors informations missing in 
`debian/copyright` but I hope it'll to be fixed soon, see [4].


This is my first Debian package, sorry if I'm doing something wrong...

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849522
[2] http://213.246.39.125/~leo/packaging/gnome-shell-extension-radio/
[3] 
https://gitlab.com/zapashcanon/gnome-shell-extension-radio-packaging/tree/master/debian

[4] https://github.com/hslbck/gnome-shell-extension-radio/issues/43

--

Cheers,

Léo Andrès