date:20160812


Sorry, was my first upgrade package. The next is aware of what to do. :)


Em 12-08-2016 21:59, Antonio Terceiro escreveu:

On Fri, Aug 12, 2016 at 07:39:06PM -0300, Carlos Donizete Froes wrote:

Hi, Terceiro.

> osmose-emulator is already in Debian ...

I'm sorry, but I do not know what the procedure is to update the 
version

that is in Debian for this new. :(

In this version of the packaging has several improvements and would 
like to

put it on Debian.


You don't need to file a new ITP bug for package updates ... the ITP is
just for the first version


--
Carlos Donizete Froes [a.k.a coringao]
- https://wiki.debian.org/coringao
GPG: 4096R/B638B780
2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#834093: guile-2.0: leaves alternatives after purge: /usr/bin/guile, /usr/share/man/man1/guile.1.gz

2016-08-12 Thread Rob Browning

Andreas Beckmann  writes:

> 0m38.2s INFO: Warning: Package purging left files on system:
>   /etc/alternatives/guile -> /usr/lib/x86_64-linux-gnu/guile-2.0/bin/guile
>  not owned
>   /etc/alternatives/guile.1.gz -> /usr/share/man/man1/guile-2.0.1.gz   not 
> owned
>   /usr/bin/guile -> /etc/alternatives/guilenot owned
>   /usr/share/man/man1/guile.1.gz -> /etc/alternatives/guile.1.gz   not 
> owned

Ahh, right.  That's just an oversight.  I moved the binary, but forgot
to update the prerm.  I'll fix it in the next upload.

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#834179: ITP: osmose-emulator -- Sega Master System and Game Gear console emulator

2016-08-12 Thread Antonio Terceiro

On Fri, Aug 12, 2016 at 07:39:06PM -0300, Carlos Donizete Froes wrote:
> Hi, Terceiro.
> 
> > osmose-emulator is already in Debian ...
> 
> I'm sorry, but I do not know what the procedure is to update the version
> that is in Debian for this new. :(
> 
> In this version of the packaging has several improvements and would like to
> put it on Debian.

You don't need to file a new ITP bug for package updates ... the ITP is
just for the first version


signature.asc
Description: PGP signature

Bug#829528: Please migrate bash-completion file from "bash-completion" package to desktop-file-utils

2016-08-12 Thread Dmitry Smirnov

On Sunday, 3 July 2016 7:38:02 PM AEST Josh Triplett wrote:
> The changelog for 0.23-1 mentions:
> >   * Do not install bash-completion (already provided by
> >   "bash-completion").
> 
> This seems the wrong way around.

Not quite... When I was preparing last upload of "desktop-file-utils"
I've corrected (deprecated) location where bash-completion file was installed 
to -- that's how I found conflict with "bash-completion".
It appears that on most systems "bash-completion" would actually provide 
completion for "desktop-file-utils" so no longer installing completions into 
deprecated location should not change anything.

Also it does not help the matter that available completions for "desktop-
file-utils" are different so one should check which one is better...

I agree that it would be better to ship "desktop-file-utils" completions in 
its own package instead of "bash-completion"...

> bash-completion provides completions
> for packages that don't provide completions for themselves.

Then perhaps this bug should be cloned or re-assigned to "bash-completion" in 
order to drop completions for "desktop-file-utils" so they could be re-
introduced to the latter. "bash-completion" should stop providing those 
completions first, in order to allow "desktop-file-utils" to take over.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Problems are not stop signs, they are guidelines.
-- Robert H. Schuller

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

Bug#834175: digikam: please depend on the default version of boost

2016-08-12 Thread Steve M. Robbins

Hi,

I'll switch it back shortly.

On Friday, August 12, 2016 7:37:33 PM CDT Mattia Rizzolo wrote:

> for some reason you swapped your build-dependency on the metapackage
> libboost-graph-dev to the versioned libboost-graph1.60-dev.

Here's the story: I worked on digikam 5.0.0 a month ago, when the default 
boost was 1.58.   That didn't work, so I used 1.60 which, at the time, was the 
latest.  I forgot about this when I built 5.1.0.  

-Steve

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

Bug#833990: logreq depends on transitional package etoolbox

2016-08-12 Thread Norbert Preining

Hi Adrian,

> Please also provide a transition that will remove the old logreq 
> package from the systems of users.
> 
> > What do you need logreq for? No rdepends whatsoever?
> 
> biblatex is an rdepends (see #833967).

I'm not sure what you want me to do? I can add a conflict against
logreq, then it will be removed as it has disappeared.
I don't want to introduce a transitional package since there are
no rdepends in sid (yes, biblatex, but that has disappeared in
sid, too).

When conflicts are in place, a dist-upgrade should remove these
two packages (and others) automatically.

Doesn't that suffice?

All the best

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#785691: Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

2016-08-12 Thread Pheeble


This is not a 'bug' as such.

One of the GTK+ devs decided to insert this warning into the Gtk Dialog 
function gtk_dialog_map because he thinks no dialog window (as used by 
LOTS of applications, including Zenity) should run without a parent 
window - see 
https://mail.gnome.org/archives/commits-list/2014-May/msg00576.html and 
https://github.com/GNOME/gtk/blob/master/gtk/gtkdialog.c.


Or perhaps it is a bug - in Gtk+.

Bug#833492: Additional info

2016-08-12 Thread Chris Tillman

Just tagging on to say that I've noticed the scroll bar widget isn't
properly placed (stays at the top) when I use Ctrl-End to go to the end of
the document. Maybe that's where the messages are coming from. If I resize
the window, the scroll bar thumb moves to the bottom.

-- 
Chris Tillman

Bug#804087: #804087 ITP: ruby-svn2git -- Ruby tool for importing existing svn projects into git.

2016-08-12 Thread Dmitry Smirnov

On Friday, 5 August 2016 9:25:06 AM AEST Sascha Girrulat wrote:
> Am 05.08.2016 um 02:46 schrieb Dmitry Smirnov:
> > It turned out that package is useless to my needs 
> 
> Hm, thats a pity ;-). Would you tell me the reason why it is useless for
> you? Do you miss some features?

I needed a way to mirror Subversion repository to Git but ruby-svn2git is not 
helpful in that regards despite being mentioned in official GitLab docs...

ruby-svn2git does very little. It looks like (at least for some repositories) 
it may be better to use my own "git-svn-convert-tags":

https://gitlab.com/onlyjob/git-svn-convert-tags

As for SVN mirror I ended up setting up intermediate bare repository with 
special push config to push remote SVN branches as normal ones...

-- 
Best wishes,
 Dmitry Smirnov.

---

Truth never damages a cause that is just.
-- Mahatma Gandhi

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

Bug#834201: ImportError: No module named '_xapian'

2016-08-12 Thread Jameson Graef Rollins

Package: python3-xapian
Version: 1.4.0-2
Severity: grave
Justification: renders package unusable

I run into the following ImportError when I try to import the python3
xapian module:

servo:~ 0$ python3 -c 'import xapian'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/xapian/__init__.py", line 37, in 
_xapian = swig_import_helper()
  File "/usr/lib/python3/dist-packages/xapian/__init__.py", line 36, in 
swig_import_helper
return importlib.import_module(mname)
  File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: No module named '_xapian'
servo:~ 1$

Thanks.

Looking forward to seeing python3-xapian in testing soon!

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.6.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 python3-xapian depends on:
ii  libc62.23-4
ii  libgcc1  1:6.1.1-11
ii  libstdc++6   6.1.1-11
ii  libxapian30  1.4.0-1
ii  python3  3.5.1-4
pn  python3:any  

python3-xapian recommends no packages.

Versions of packages python3-xapian suggests:
ii  xapian-doc  1.2.23-1

-- no debconf information

Bug#834200: [libvulkan1] libvulkan1 is not multiarch-aware

2016-08-12 Thread Michał Mirosław


Package: libvulkan1
Version: 1.0.8.0+dfsg1-1
Severity: important

--- Please enter the report below this line. ---

Please make libvulkan1 multiarch aware. This is required for 32-bit 
version of Vulkan ICD from latest nvidia driver package (367.35).


Thanks.

--- System information. ---
Architecture: amd64
Kernel: Linux 4.6.5mq

Debian Release: stretch/sid
900 testing ftp.icm.edu.pl
800 jessie-backports ftp.icm.edu.pl
750 stable www.deb-multimedia.org
750 stable security.debian.org
750 stable repos.fds-team.de
750 stable ftp.icm.edu.pl
700 unstable ftp.icm.edu.pl
600 experimental ftp.icm.edu.pl
500 unstable-debug debug.mirrors.debian.org
500 testing-debug debug.mirrors.debian.org
500 stable dl.google.com
500 stable deb.opera.com
500 proposed-updates ftp.icm.edu.pl
1 experimental-debug debug.mirrors.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-===
libc6 (>= 2.17) |
libgcc1 (>= 1:3.0) |
libstdc++6 (>= 5.2) |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#834199: dh-make-perl: Uses deprecated Dpkg::Source:Package variable

2016-08-12 Thread Guillem Jover

Package: dh-make-perl
Version: 0.91
Severity: normal

Hi!

This package uses the scalar $diff_ignore_default_regexp from the
Dpkg::Source::Package module, which was deprecated in dpkg 1.17.2.

Please switch to use the get_default_diff_ignore_regex() function.

(For reference, this is documented in the man page for the module and
was mentioned in the debian/changelog. I'm not sure how to make this
kind of thing more visible to API users, w/o having to annoy via a
NEWS file countless program users that get the libdpkg-perl packaged
automaticallt pulled, suggestions welcome!)

Thanks,
Guillem

Bug#833615: [nvidia-graphics-drivers] update to 367.35

2016-08-12 Thread Luca Boccassi

On Aug 13, 2016 00:53, "Michał Mirosław"  wrote:
>
> On Fri, Aug 12, 2016 at 04:32:31PM +0100, Luca Boccassi wrote:
> > Control: tags -1 - patch
> > Control: tags -1 pending
> >
> > On Sun, 2016-08-07 at 01:50 +0200, Michał Mirosław wrote:
> > > Source: nvidia-graphics-drivers
> > > Severity: normal
> > > Tags: patch
> > >
> > > --- Please enter the report below this line. ---
> > >
> > > Please consider updating to 367.35. PoC patch attached.
> >
> > We already have a 367 branch:
> >
> >
https://anonscm.debian.org/viewvc/pkg-nvidia/packages/nvidia-graphics-drivers/branches/367/
> >
> > It will most likely be uploaded sometimes soon.
> >
> > In the meanwhile, if you are interested in trying it by building locally
> > you can follow instructions on the wiki:
> >
> >
https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN
>
> Ah, great! Built and installed, though libvulkan1 is not multiarch-aware,
so
> 32-bit vulkan ICD does not install.
>
> Best Regards,
> Michał Mirosław

Yes I have noticed the same issue, please feel free to open a bug against
libvulkan1 for that.

Kind regards,
Luca Boccassi

Bug#833615: [nvidia-graphics-drivers] update to 367.35

2016-08-12 Thread Michał Mirosław

On Fri, Aug 12, 2016 at 04:32:31PM +0100, Luca Boccassi wrote:
> Control: tags -1 - patch
> Control: tags -1 pending
> 
> On Sun, 2016-08-07 at 01:50 +0200, Michał Mirosław wrote:
> > Source: nvidia-graphics-drivers
> > Severity: normal
> > Tags: patch
> > 
> > --- Please enter the report below this line. ---
> > 
> > Please consider updating to 367.35. PoC patch attached.
> 
> We already have a 367 branch:
> 
> https://anonscm.debian.org/viewvc/pkg-nvidia/packages/nvidia-graphics-drivers/branches/367/
> 
> It will most likely be uploaded sometimes soon.
> 
> In the meanwhile, if you are interested in trying it by building locally
> you can follow instructions on the wiki:
> 
> https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN

Ah, great! Built and installed, though libvulkan1 is not multiarch-aware, so
32-bit vulkan ICD does not install.

Best Regards,
Michał Mirosław

Bug#834002: Please add mips64el to the architecture list

2016-08-12 Thread James Cowgill

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: retitle -1 Please add mips64el to the architecture list
Control: block -1 by 828982
Control: tags 828982 patch

Hi Anibal,

> Source: golang-defaults
> Version: 2:1.6.1+1
> Severity: important
> 
> Hello,
> 
> Please add mips, mipsel and mips64el in the architecture list.

Since there is no golang implementation for mips 32-bit, this would be
quite difficult to do for mips and mipsel :)

It also requires mips64el to be enabled in golang-1.6 (or 1.7) so I've
made that a blocker of this bug.

James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXrl4TAAoJEMfxZ23qLQHvSPwP/j0pmHUAGRM/Yj2DW58XiW4J
rtqJbuoxpkyLG4XBHIh5nlLTXCoPpSvgwcI0VVx2NCWKdbXuvqZ+r2K/c4USJWqh
KOLJSiw4tUdMWNRE2eLDIoI7nZhrWx2RVBytnn4HVDgkeoRCdTiUUOkFx3fML1Ov
At4FtPVHC+ZI4xYDb5YnVR5P2xwn0/5t0i3ocYqrbx/LXtq/LEg3YOEEQynUkAYP
sf0syDO74t0DmOgy2HPEhYj1N+2NbLIN+MJRXORh04feTx2UZyU3lO8O90Yrw9YZ
wFnEuCC5BLErGUxJeKuRixxdcLRHM2QT4XdwkRQpolNf8FN+7sXBxr2imJixtphI
On6tYENks0XEui42lErzhqWVaeGB2o96vonQV7myXWB0LBOl17DtnRoTSZRscKXl
Rx/ADxT2kAVXWR7/8iS86butuBlg2isQZo96kO0HUz8Nf+M9X2azqV2+VWmse9xp
XYT/2KZFRT5i5wAUHQrch6vmed/djqZinYOtQdg43eKMePChoaoARXb+1mZ4msgr
udK5BJP+GHRb+BiK51MOlsz1b8e8htVax7rfgn+wyjNAbC3TrsXViv5o13t8qN4l
HQ6atl/ZRZpPHQeuWLFmN6xeszJP90uGVIp3Chixl7m1w8Q2QIIahybfoI0sMZ5h
kSEDZXSQ22Mp98IKzX3c
=02wh
-END PGP SIGNATURE-

Bug#834198: ITP: python-oxd -- Python bindings for Gluu OxD server

2016-08-12 Thread Adrian Alves

Package: wnpp
Severity: wishlist
Owner: Adrian Alves 

* Package name: python-oxd
  Version : 2.4.4
  Upstream Author : Gluu 
* URL : https://github.com/GluuFederation/oxd-python
* License : MIT
  Programming Lang: Python
  Description : Python bindings for Gluu OxD server

Python Client Library for oxd Server -- OpenID Connect
Client RP Middleware. For information about oxD,
visit http://oxd.gluu.org

Bug#834197: [Greg Wooledge] Re: bash(1) says /etc/bash.bash.logout, should be bash_logout

2016-08-12 Thread Daniel Kahn Gillmor

Package: bash
Version: 4.3-15

Hi debian bash folks!  it seems that there is a debian-specific
systemwide logout mechanism, which is improperly documented.  (see
forwarded message below).

Regards,

--dkg

--- Begin Message ---
On Fri, Aug 12, 2016 at 09:59:00AM -0400, d...@fifthhorseman.net wrote:
> I think the documentation is wrong about the systemwide filename that
> bash reads when a login shell exits.  the manpage says
> "/etc/bash.bash.logout", but the binary appears to be built with
> "/etc/bash.bash_logout" (note the change from "." to "_").

This is a vendor (distribution) feature.  Submit a bug report to your
operating system.

Upstream bash does not read either of those files, and does not mention
either of them in its man page.
--- End Message ---


signature.asc
Description: PGP signature

Bug#834196: add dpkg trigger for /etc/audit/rules.d folder to have newly installed rules files take effect

2016-08-12 Thread Patrick Schleizer

Package: auditd
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

please add a dpkg trigger. Once a new auditd rules file is dropped into
/etc/audit/rules.d folder, run within the Debian maintainer script:

/sbin/augenrules --load || true

Cheers,
Patrick

Bug#827733: busybox-init & busybox-init-sysv

2016-08-12 Thread Jon Boden

On Sun, Jul 24, 2016 at 04:00:26PM +0200, Jon Boden wrote:
> 
> FWIW here's a patch to add busybox-init package based on Benda's suggestions 
> (tested on ubuntuBSD with both sysv-rc and openrc).

Here's a new version of the patch. This one adds two packages akin to what 
upstart-sysv and systemd-sysv do:

1. busybox-init provides /etc/inittab and /lib/busybox/init. Then you can pass 
init=/lib/busybox/init in bootloader to use BusyBox init (GRUB even adds a menu 
entry if you edit SUPPORTED_INITS in /etc/grub.d/10_linux).

2. busybox-init-sysv provides the /sbin/init symlink (and /sbin/halt, etc) and 
Conflicts with other packages providing the same files.

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
diff -Nur -x '*~' ../debian/busybox-init.dirs debian/busybox-init.dirs
--- ../debian/busybox-init.dirs	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init.dirs	2016-08-13 00:34:51.445711837 +0200
@@ -0,0 +1 @@
+lib/busybox
diff -Nur -x '*~' ../debian/busybox-init.install.hurd debian/busybox-init.install.hurd
--- ../debian/busybox-init.install.hurd	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init.install.hurd	2016-08-13 00:23:01.934431547 +0200
@@ -0,0 +1 @@
+debian/init/hurd/inittab	/etc
diff -Nur -x '*~' ../debian/busybox-init.install.kfreebsd debian/busybox-init.install.kfreebsd
--- ../debian/busybox-init.install.kfreebsd	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init.install.kfreebsd	2016-08-13 00:23:01.934431547 +0200
@@ -0,0 +1 @@
+debian/init/kfreebsd/inittab	/etc
diff -Nur -x '*~' ../debian/busybox-init.install.linux debian/busybox-init.install.linux
--- ../debian/busybox-init.install.linux	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init.install.linux	2016-08-13 00:23:01.934431547 +0200
@@ -0,0 +1 @@
+debian/init/linux/inittab	/etc
diff -Nur -x '*~' ../debian/busybox-init.links debian/busybox-init.links
--- ../debian/busybox-init.links	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init.links	2016-08-13 00:34:41.205550048 +0200
@@ -0,0 +1 @@
+bin/busybox lib/busybox/init
diff -Nur -x '*~' ../debian/busybox-init.postinst debian/busybox-init.postinst
--- ../debian/busybox-init.postinst	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init.postinst	2016-08-13 00:21:22.763510848 +0200
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+
+# update grub on first install, so that the alternative init system boot
+# entries get updated
+if [ "$1" = configure ] && [ -z "$2" ] && [ -e /boot/grub/grub.cfg ] && which update-grub >/dev/null 2>&1; then
+update-grub || true
+fi
+
+#DEBHELPER#
diff -Nur -x '*~' ../debian/busybox-init-sysv.links debian/busybox-init-sysv.links
--- ../debian/busybox-init-sysv.links	1970-01-01 01:00:00.0 +0100
+++ debian/busybox-init-sysv.links	2016-08-13 00:34:21.657233870 +0200
@@ -0,0 +1,4 @@
+bin/busybox sbin/init
+bin/busybox sbin/halt
+bin/busybox sbin/reboot
+bin/busybox sbin/poweroff
diff -Nur -x '*~' ../debian/control debian/control
--- ../debian/control	2015-08-07 23:39:01.0 +0200
+++ debian/control	2016-08-13 00:36:04.886804859 +0200
@@ -76,6 +76,45 @@
  busybox-initramfs provides a simple stand alone shell that provides
  only the basic utilities needed for the initramfs.
 
+Package: busybox-init
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, busybox, openrc | sysv-rc
+# file conflict because of /etc/inittab
+Conflicts: sysvinit (<< 2.88dsf-44), sysvinit-core
+Section: admin
+Description: BusyBox implementation of Init
+ BusyBox combines tiny versions of many common UNIX utilities into a single
+ small executable. It provides minimalist replacements for the most common
+ utilities you would usually find on your desktop system (i.e., ls, cp, mv,
+ mount, tar, etc.). The utilities in BusyBox generally have fewer options than
+ their full-featured GNU cousins; however, the options that are included
+ provide the expected functionality and behave very much like their GNU
+ counterparts.
+ .
+ This package provides a minimalist implementation of Init, which can be
+ started by passing init=/lib/busybox/init parameter in your bootloader.
+
+Package: busybox-init-sysv
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, busybox-init
+# file conflict because of /sbin/init
+Conflicts: sysvinit (<< 2.88dsf-44), sysvinit-core,
+ upstart (<< 1.13.2-0ubuntu10) [linux-any], upstart-sysv [linux-any],
+ systemd-sysv [linux-any]
+Section: admin
+Description: BusyBox implementation of /sbin/init
+ BusyBox combines tiny versions of many common UNIX utilities into a single
+ small executable. It provides minimalist replacements for the most common
+ utilities you would usually find on your desktop system (i.e., ls, cp, mv,
+ mount, tar, etc.). The utilities in BusyBox generally have fewer options than
+ their full-featured GNU cousins; however, the options that are included
+ provide the expected

Bug#834195: unzip: recmatch in match.c has nonfree license

2016-08-12 Thread Legimet

Package: unzip
Version: 6.0-16+deb8u2
Severity: serious
Justification: Policy 2.1

Dear Maintainer,

The function recmatch in match.c has the following nonfree license,
which forbids selling for profit:

 Copyright (C) 1990-1992 Mark Adler, Richard B. Wales, Jean-loup Gailly,
 Kai Uwe Rommel and Igor Mandrichenko.

 Permission is granted to any individual or institution to use, copy,
 or redistribute this software so long as all of the original files are
 included unmodified, that it is not sold for profit, and that this copy-
 right notice is retained.

The function was taken from zip's util.c when zip was under a nonfree
license. Parabola has a patch that replaces it with recmatch from a
newer version of zip, under a free license:
https://git.parabola.nu/abslibre.git/tree/libre/unzip/match.patch
(though the part which changes allowed to aLlowed should be removed)

Thanks

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

Kernel: Linux 4.6.0-0.bpo.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 unzip depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u4

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-8

-- no debconf information

Bug#834194: munin-plugins-core: ntp_states plugin: Use of uninitialized value $peers_condition{}

2016-08-12 Thread Nye Liu

Package: munin-plugins-core
Version: 2.0.25-2
Severity: important
Tags: upstream patch

Dear Maintainer,

2016/08/12-15:45:23 [5316]  Use of uninitialized value 
$peers_condition{"..."} in print at /etc/munin/plugins/ntp_states line 161.

https://github.com/munin-monitoring/munin/issues/714


--- /etc/munin/plugins/ntp_states   2015-08-30 01:09:20.0 -0700
+++ ntp_states  2016-08-12 15:45:19.326208155 -0700
@@ -52,6 +52,7 @@
  "falsetick" => 1,
  "excess"=> 2,
  "backup"=> 3,
+ "outlier"   => 4,
  "outlyer"   => 4,
  "candidate" => 5,
  "sys.peer"  => 6,


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

Kernel: Linux 4.6.3-x86_64-linode70 (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 munin-plugins-core depends on:
ii  munin-common  2.0.25-2
ii  perl  5.22.2-3

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-2

Versions of packages munin-plugins-core suggests:
pn  conntrack 
pn  libcache-cache-perl   
ii  libdbd-mysql-perl 4.035-1
ii  libnet-dns-perl   0.81-2+b1
pn  libnet-netmask-perl   
pn  libnet-telnet-perl
ii  libxml-parser-perl2.44-1+b1
ii  python2.7.9-1
ii  ruby  1:1.9.3.3
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.484-2

-- no debconf information

Bug#789381: libpoe-api-peek-perl: FTBFS with perl 5.22: test failures

2016-08-12 Thread gregor herrmann

On Mon, 01 Aug 2016 08:57:07 -0300, Prof. Ernesto Hernández-Novich wrote:

> On Sat, 30 Jul 2016 14:35:09 +0200 intrigeri  wrote:

> > A month later: any update on this side?
> Nothing.

webgui was removed from the archive. RoQA, #834084.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#834193: python-pip: pip2 is not the same as pip: makepip missing for pip2

2016-08-12 Thread Daniel Hahler

Package: python-pip
Version: 8.1.1-2ubuntu0.1
Severity: important

Dear Maintainer,

debian/rules uses the "makepip.py" program to generate fixed/custom pip
and pip3 scripts, but leaves the original pip2 alone:

override_dh_python3:
dh_python3
rm -f debian/python3-pip/usr/bin/pip
rm -f debian/python3-pip/usr/bin/pip3.?
rm -rf debian/python3-pip/usr/lib/python3.?
python3 debian/makepip.py /usr/bin/python3 \
debian/python3-pip/usr/bin/pip3

override_dh_python2:
dh_python2
rm -f debian/python-pip/usr/bin/pip2.?
python3 debian/makepip.py /usr/bin/python \
debian/python-pip/usr/bin/pip

% diff -u /usr/bin/pip*
--- /usr/bin/pip 2016-05-24 14:23:26.0 +
+++ /usr/bin/pip2 2016-05-24 14:23:16.0 +
@@ -1,11 +1,10 @@
 #!/usr/bin/python
-# GENERATED BY DEBIAN
-
+# EASY-INSTALL-ENTRY-SCRIPT: 'pip==8.1.1','console_scripts','pip2'
+__requires__ = 'pip==8.1.1'
 import sys
+from pkg_resources import load_entry_point

-# Run the main entry point, similarly to how setuptools does it, but
because
-# we didn't install the actual entry point from setup.py, don't use the
-# pkg_resources API.
-from pip import main
 if __name__ == '__main__':
- sys.exit(main())
+ sys.exit(
+ load_entry_point('pip==8.1.1', 'console_scripts', 'pip2')()
+ )

I think there should be an additional line in override_dh_python2:

 python3 debian/makepip.py /usr/bin/python \
  debian/python-pip/usr/bin/pip2

I've noticed this because Saltstack will prefer "pip2" over "pip".

Reported for Ubuntu on Launchpad in
https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1612264.


-- 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)

Kernel: Linux 4.4.0-34-generic (SMP w/1 CPU core)
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-pip depends on:
ii  ca-certificates  20160104ubuntu1
ii  python-pip-whl   8.1.1-2ubuntu0.1
pn  python:any   

Versions of packages python-pip recommends:
ii  build-essential12.1ubuntu2
ii  python-all-dev 2.7.11-1
ii  python-setuptools  20.7.0-1
ii  python-wheel   0.29.0-1

python-pip suggests no packages.

-- no debconf information

Bug#833187: RFS: yuma123/2.8-1 [ITP] -- netconf/YANG toolchain

2016-08-12 Thread Vladimir Vassilev


Vincent,

The packaging project git I work with is available here 
https://sourceforge.net/projects/pkg-yuma123/


On 08/06/2016 10:10 PM, Vincent Bernat wrote:

How should netconfd be running? I see that netconf-subsystem should be
configured inside OpenSSH. What about netconfd? Is it spawned by
netconf-subsystem?
`netconfd` started without any arguments creates UNIX socket 
/tmp/ncxserver.sock and listens for connections.


`netconf-subsystem` is called from OpenSSH and connects to 
/tmp/ncxserver.sock for each ssh client connecting to  the netconf 
subsystem. `man netconfd` or the wiki guides e.g. 
http://www.yuma123.org/wiki/index.php/Yuma_Quickstart_Guide#NETCONF_Server 
contain detailed information.


Vladimir

Bug#778945: konwert: please make the build reproducible

Dear Maintainer,

> Source: konwert
> Version: 1.8-11.2build1
> Tags: patch

There hasn't seem to be any update on this bug in 537 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777376: mpack: please make the build reproducible

Dear Maintainer,

> Source: mpack
> Version: 1.6-8
> Tags: patch

There hasn't seem to be any update on this bug in 552 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#778204: ratfor: please make the build reproducible

Dear Maintainer,

> Source: ratfor
> Version: 1.0-15
> Tags: patch

There hasn't seem to be any update on this bug in 547 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777322: dtc-xen: please make the build reproducible

Dear Maintainer,

> Source: dtc-xen
> Version: 0.5.4-1
> Tags: patch

There hasn't seem to be any update on this bug in 552 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777443: qemu-launcher: please make the build reproducible

Dear Maintainer,

> Source: qemu-launcher
> Version: 1.7.4-1ubuntu2
> Tags: patch

There hasn't seem to be any update on this bug in 551 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#776955: elida: please make the build reproducible

Dear Maintainer,

> Source: elida
> Version: 0.4+nmu1
> Tags: patch

There hasn't seem to be any update on this bug in 556 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777274: xzgv: please make the build reproducible

Dear Maintainer,

> Source: xzgv
> Version: 0.9.1-3
> Tags: patch

There hasn't seem to be any update on this bug in 552 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777410: freecdb: please make the build reproducible

Dear Maintainer,

> Source: freecdb
> Version: 0.75
> Tags: patch

There hasn't seem to be any update on this bug in 551 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777019: ucspi-unix: please make the build reproducible

Dear Maintainer,

> Source: ucspi-unix
> Version: 0.36-4
> Tags: patch

There hasn't seem to be any update on this bug in 555 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#776935: cgilib: please make the build reproducible

Dear Maintainer,

> Source: cgilib
> Version: 0.6-1
> Tags: patch

There hasn't seem to be any update on this bug in 556 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

2016-08-12 Thread Rick Thomas

On Aug 12, 2016, at 9:21 AM, Pete Batard  wrote:

> Okay. I have now gone through a dpkg -i install of all the (non dbgsym) .deb 
> I see on your server, and also issued a reboot for good measure, but I still 
> see the same problem with journald being failed, along with dependent services

Hi Filipe,

Would you like me to also do what pete describes (all the .deb files) or is 
there a more fine-grained test you’d like me to try?

Rick

Bug#834191: I am silly

2016-08-12 Thread Jonas Thiem

I'm silly, I somehow thought reportbug's warning about the package not
being installed didn't also mean it doesn't even exist..

I meant to file this bug for package ca-cacert ( https://packages.debia
n.org/sid/misc/ca-cacert ), but apparently that package was removed
anyway? I'm confused, and I hope I didn't make too much of a mess in
your bug system, I'm more used to bugzilla :x sorry guys

Bug#824990: Please update transmission to 2.92

2016-08-12 Thread Jeremy Bicha

> On Fri, Aug 12, 2016 at 11:03 PM, Jeremy Bicha  wrote:
>> On Fri, Aug 12, 2016 at 5:26 PM, Sandro Tosi  wrote:
>>> how did you manage the internal libraries? are they available in ubuntu?
>>
>> Sorry, I didn't test build on Debian this time to make sure that it works.
>>
>> Ubuntu's only made a few changes. Here, I'll attach a full diff for you.
>>
>> Maybe you need update-glib-gettext.m4.patch too.
>>
>> Thanks,
>> Jeremy Bicha

On Fri, Aug 12, 2016 at 6:07 PM, Sandro Tosi  wrote:
> no i'm talking about the libraries in third-party/ dir and the fact
> they are downloaded during build - how did you deal with them?
>
> also, why u replied only to me and not to the whole recipients set of
> before? feel free to forward this msg

My mistake for not hitting Reply All.

Ubuntu's builders don't have internet access and transmission 2.92
seemed to build fine.

https://launchpad.net/ubuntu/+source/transmission/2.92-0ubuntu1

Jeremy Bicha


ubuntu-transmission-changes.debdiff
Description: Binary data

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

2016-08-12 Thread Francesco Poli

On Fri, 12 Aug 2016 00:45:55 +0200 Julian Andres Klode wrote:

> On Fri, Aug 12, 2016 at 12:40:44AM +0200, Francesco Poli wrote:
[...]
> > Please reply to my question
[...]
> > 
> > In the meanwhile, I am reopening the bug.
> 
> Yes, sorry, I forgot to take this out of the changelog.

No problem, reopening the bug was easy enough...

> So, basically,
> AFAICT, what we should do is ignore the interrupt, because if the child
> process exits with any error, we will error out as well. And if a child
> exits because of a SIGINT, it's exit code won't be 0.

Well, this sounds reasonable, after all.
I haven't been able to find a counterargument, although you have to
take into account that I am no expert of signal handling, so I could be
wrong...

Please implement the fix soon.
Thanks for your time and helpfulness!


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


pgpHzY0siE_fh.pgp
Description: PGP signature

Bug#834192: handbrake: please make the build reproducible

Source: handbrake
Version: 0.10.5+ds1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed
that handbrake could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/006-reproducile-build.patch1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/006-reproducile-build.patch2016-08-12 
22:56:04.545879965 +0100
@@ -0,0 +1,42 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-12
+
+--- handbrake-0.10.5+ds1.orig/make/configure.py
 handbrake-0.10.5+ds1/make/configure.py
+@@ -841,7 +841,7 @@ class Project( Action ):
+ 
+ url_ctype = '_unstable'
+ url_ntype = 'unstable'
+-self.build = time.strftime('%Y%m%d') + '01'
++self.build = time.strftime('%Y%m%d', now) + '01'
+ self.title = '%s %s (%s)' % (self.name,self.version,self.build)
+ else:
+ m = re.match('^([a-zA-Z]+)\.([0-9]+)$', suffix)
+@@ -860,7 +860,7 @@ class Project( Action ):
+ url_ctype = '_unstable'
+ url_ntype = 'unstable'
+ 
+-self.build = time.strftime('%Y%m%d') + '00'
++self.build = time.strftime('%Y%m%d', now) + '00'
+ self.title = '%s %s (%s)' % (self.name,self.version,self.build)
+ 
+ self.url_appcast = 'https://handbrake.fr/appcast%s%s.xml' % 
(url_ctype,url_arch)
+@@ -1430,6 +1430,8 @@ try:
+ if arg == '--verbose':
+ verbose = Configure.OUT_VERBOSE
+ 
++now = time.gmtime(int(os.environ.get('SOURCE_DATE_EPOCH', time.time(
++
+ ## create main objects; actions/probes run() is delayed.
+ ## if any actions must be run earlier (eg: for configure --help purposes)
+ ## then run() must be invoked earlier. subequent run() invocations
+@@ -1743,7 +1745,7 @@ int main()
+ else:
+ doc.add( 'BUILD.cross.prefix', '' )
+ 
+-doc.add( 'BUILD.date',   time.strftime('%c') )
++doc.add( 'BUILD.date',   time.strftime('%c', now) ),
+ doc.add( 'BUILD.arch',   arch.mode.mode )
+ 
+ doc.addBlank()
--- a/debian/patches/series 2016-08-12 22:14:29.905943199 +0100
--- b/debian/patches/series 2016-08-12 22:55:44.093714828 +0100
@@ -2,3 +2,4 @@
 002-Remove-embedded-downloaded-copies-of-various-librari.patch
 003-remove-vpx.patch
 005-use-libtoolize.patch
+006-reproducile-build.patch

Bug#834191: ca-cert: Fedora / Red Hat thinks CACert license is non-free

2016-08-12 Thread Jonas Thiem

Package: ca-cert
Severity: normal
Tags: upstream


The Red Hat legal team has reviewed the CACert licensing,
which appears to have this copyright license which must be adhered to when
including and using the certificates:

http://www.cacert.org/policy/RootDistributionLicense.html

They seem to think it is non-free, details are here:

https://bugzilla.redhat.com/show_bug.cgi?id=474549#c34

TL;DR: I suppose looking at the green lock and thinking it's secure possibly
means "relying" on the cert, and the license has a usage restriction on this
unless you sign up for the CACert community agreement, which itself requires
explicit sign-up (who actually knows and does that?), arbitration clause etc.

But IANAL, read the Red Hat link above for all the details.

PS: fwiw, this reportbug was run inside a docker container, I hope that
won't mess anything up with this report

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

Kernel: Linux 4.6.4-301.fc24.x86_64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#833760: cufflinks: please use the default boost version

2016-08-12 Thread Mattia Rizzolo

On Fri, Aug 12, 2016 at 10:59:11PM +0200, Andreas Tille wrote:
> Sorry, this does not help.  There is this large thread on
> debian-devel[2] which I triggered and which IMHO goes totally in the
> wrong direction nitpicking about copyrights inside binary packages which
> is IMHO orthogonal to the interest of our users (would a user really
> *copy* from binary results and if this really stupid intention is really
> done would this person care about copyright at all? - may be I'll write
> something in this thread but I'm afraid that's just a waste of time).

yeah, I'm aware of that.  I'm subscribed to d-d, and I've been quite
shocked to see how nobody actually cared of the starting issue, and the
thread quickly diverged towards more abstract, just plain academic
goals that are quite clear to everybody are not going to be perfectly
achived anytime soon.

> Cufflinks just does not build (neither with boost 1.60 nor 1.61 and
> I have no chance to upload it.  Feel free to request the removal of
> 1.60 since it does not change the situation.

I'm sorry if I conveyed the idea that I didn't get the problem, or some
more wild idea like implying you didn't care or something…. I've read
#833493 (besides, I'm subscribed to d-med-packaging@, so I received
it too) and understand the issue and how packaging lemon is going to at
least make possible to fix this, and how that is blocked on nonsense in
d-d@...

I just wanted to make you well aware of the current situation around
this bug outside this particular package, nothing more :)

> > > [2] https://lists.debian.org/debian-devel/2016/08/msg00099.html
> > 
> > /me does some lobbying for it.

meaning I prodded Thorsten out of d-d to either process the package
again after the small flame in d-d, or at least tell us what he expects
from us.

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#834189: php-common: php-maintscript-helper loses admin changes on package reinstall/upgrade

2016-08-12 Thread Christoph Anton Mitterer

duplicate of #831807?

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#834190: perl: please make the output of ExtUtils::Command::MM reproducible

Source: perl
Version: 5.22.2-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that ExtUtils::Command::MM generates perllocal.pod files that are
not reproducible.

For example:

  -=head2 Sun Jul  3 14:56:53 2016: Chttps://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm 
b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm
index 203b3aa..0f1217b 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm
@@ -213,7 +213,8 @@ sub perllocal_install {
: @ARGV;
 
 my $pod;
-$pod = sprintf < L<$name|$name>
 
  =over 4

Bug#806606: basemap: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

On 08/12/2016 11:30 PM, Sebastiaan Couwenberg wrote:
> On 08/12/2016 11:25 PM, Sandro Tosi wrote:
>> please remove the upload, or move it to a longer wait queue, i'll deal
>> with it this weekend
> 
> Thanks for the feedback, I've rescheduled the upload to DELAYED/5.

The changes file hasn't been processed yet, so the reschedule command
couldn't be processed either. I'll send it again when I get the mail for
the upload processing.

Kind Regards,

Bas

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

Bug#833878: I suggest not packaging syncthing-inotify

2016-08-12 Thread Alexandre Viau

Oops, wrong PR link:
 - https://github.com/syncthing/syncthing/pull/2807

On 12/08/16 05:26 PM, Alexandre Viau wrote:
> Hello,
> 
> syncthing-inotify is going to be merged into mainline Syncthing, so the
> separate repository will be depracated.
> 
> See:
>  - https://github.com/syncthing/syncthing/pull/3328
> 
> I would expect this PR to be merged before Stretch.
> 
> You can still package syncthing-inotify and then file a removal request
> when the PR is merged if you want.
> 
> Cheers,
> 

-- 
Alexandre Viau
alexan...@alexandreviau.net



signature.asc
Description: OpenPGP digital signature

Bug#834163: libmagick++: undefined behavior on concurrent access because mutex locking is poorly done

2016-08-12 Thread Guillaume Gimenez




Le 12/08/2016 à 22:44, Bastien ROUCARIES a écrit :

On Fri, Aug 12, 2016 at 6:16 PM, Guillaume Gimenez  wrote:

Package: libmagick++-6.q16-5v5
Version: 8:6.8.9.9-7.2
Severity: important
File: libmagick++
Tags: patch

Dear Maintainer,

There is a bug in the locking implentation (RAII was the intended C++ idiom) 
that has been fixed upstream.

http://git.imagemagick.org/repos/ImageMagick/commit/5cbe21ed2728da0e611154d2f8e41bb63095a62c

Unfortunately, the commit message is empty...

In the unfixed code, the mutex acquisition has no effect and doesn't prevent 
concurrent access to ref counters.

This bug generates a lot of crashes when Magick++ is used with multi-threaded 
applications


Do you have a small test case ?

If so it is a security bug. Could you ask for a CVE ?

Bastien


Of course here it is

I spotted this bug with a program I am developing
https://github.com/ploki/darkflow
Since it doesn’t look like a minimal test case I wrote this small test 
program which triggers the bug on im 6.8 but doesn’t on im 6.9 which has 
the fix applied.


$ cat bug.cc
#include 
using namespace Magick;
int main(int argc, char **argv)
{
  Image plop("/usr/share/pixmaps/debian-logo.png");
#pragma omp parallel for
  for (int i = 0 ; i < 1 ; ++i )
{
  Image meh(plop);
}
return 0;
}
$ g++ -fopenmp $(pkg-config --cflags --libs Magick++) bug.cc -o bug
$ ./bug
bug: ../../magick/image.c:1106: DestroyImageInfo: Assertion 
`image_info->signature == 0xabacadabUL' failed.

Aborted
$ ./bug
bug: ../../magick/image.c:1106: DestroyImageInfo: Assertion 
`image_info->signature == 0xabacadabUL' failed.

terminate called after throwing an instance of 'Magick::ErrorOption'
  what():  Magick: mutex lock failed (Invalid argument)
Aborted

crash may vary depending on which race is triggered.

Regards,
Guillaume






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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=locale: Cannot set LC_CTYPE 
to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmagick++-6.q16-5v5:amd64 depends on:
ii  libc6  2.23-4
ii  libgcc11:6.1.1-10
ii  libmagickcore-6.q16-2  8:6.8.9.9-7.2
ii  libmagickwand-6.q16-2  8:6.8.9.9-7.2
ii  libstdc++6 6.1.1-10

libmagick++-6.q16-5v5:amd64 recommends no packages.

libmagick++-6.q16-5v5:amd64 suggests no packages.

Bug#806606: basemap: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

On 08/12/2016 11:25 PM, Sandro Tosi wrote:
> please remove the upload, or move it to a longer wait queue, i'll deal
> with it this weekend

Thanks for the feedback, I've rescheduled the upload to DELAYED/5.

Kind Regards,

Bas

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

Bug#824990: Please update transmission to 2.92

2016-08-12 Thread Sandro Tosi

how did you manage the internal libraries? are they available in ubuntu?

On Fri, Aug 12, 2016 at 9:15 PM, Jeremy Bicha  wrote:
> I updated transmission in Ubuntu. I'm attaching a patch with the changes.
>
> Thanks,
> Jeremy Bicha



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#806606: basemap: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

2016-08-12 Thread Sandro Tosi

please remove the upload, or move it to a longer wait queue, i'll deal
with it this weekend

On Fri, Aug 12, 2016 at 10:24 PM, Sebastiaan Couwenberg
 wrote:
> Control: tags -1 pending
>
> Hi Sandro,
>
> On 08/02/2016 02:08 PM, Sebastiaan Couwenberg wrote:
>> Because this RC bug is threatening the removal of several reverse
>> dependencies I had a look at fixing it. The attached patch adds the
>> build-arch target to the build-indep target dependencies to have the
>> missing files built.
>
> Since there has been no activity on this RC bug, I've uploaded a 0-day
> NMU with the patch from my previous message.
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#833878: I suggest not packaging syncthing-inotify

2016-08-12 Thread Alexandre Viau

Hello,

syncthing-inotify is going to be merged into mainline Syncthing, so the
separate repository will be depracated.

See:
 - https://github.com/syncthing/syncthing/pull/3328

I would expect this PR to be merged before Stretch.

You can still package syncthing-inotify and then file a removal request
when the PR is merged if you want.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

2016-08-12 Thread Aurelien Jarno

control: retitle -1 libc6: support for non-compliant nameserver should be 
improved
control: severity -1 wishlist

On 2016-08-12 12:15, Vincent Lefevre wrote:
> On 2016-08-12 09:26:10 +0200, Aurelien Jarno wrote:
> > The libc does a first connection to the configured name server
> > (192.168.0.1) using UDP. Note the size of the packet, very close to
> > the 512 bytes limit without EDNS0 support. This very likely mean the
> > answer is marked as truncated (look at the number of entries in the
> > host answer).
> 
> According to tcpdump output below, there is no truncation: the number
> of A's and 's (10 for each) match what "host keys.gnupg.net"
> gives. BTW, even if there were a truncation, there shouldn't be a
> failure: using of the returned IP addresses would be sufficient to
> connect.

That a wrong assumption. The libc getaddrinfo interface is not to
connect to an IP, but rather to return *all* addresses corresponding to
a query. The returned IPs are not necessarily used for a connection
later. Not returning all addresses so might lead to data loss or
security issue. On example among other is the forward-confirmed reverse
DNS method used for example by some mail servers. Not returning all IPs
might lead to a rejected or a discarded mail depending on the policy.

The point is that the local resolver is supposed to be working
correctly. If it doesn't, one can easily setup a local recursive name
server like unbound.

> 11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
> keys.gnupg.net. (32)
> 11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
> keys.gnupg.net. (32)
> 11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
> 1.0.168.192.in-addr.arpa. (42)
> 11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 NXDomain* 
> 0/1/0 (94)
> 11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
> 6.0.168.192.in-addr.arpa. (42)
> 11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 CNAME 
> pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 78.46.223.54, A 
> 131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 209.135.211.141, A 
> 5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)

This tcpdump trace doesn't show the answer header, so we don't know if
the truncation flag is set. That said the 11/9/5 says that the answer
contains 11 answer records, 9 name server records and 5 additional
records. This clearly doesn't fit. A normal DNS server would just return
11 answers, so 11/0/0.

That said I just realized that the strace entry in your previous email
contains the beginning of the answer:

> 30419 recvfrom(4, 
> "'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
> {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 
> [16]) = 500

Converted into hexadecimal, this is:
  27 4a 83 80 00 01 00 0b 00 08 00 00 04 6b 65 79
  73 05 67 6e 75 70 67 03 6e 65 74 00 00 1c 00 01

274a is the identification. The flags are 8380 and corresponds to QR,
TC, RD, RA. Your name server clearly says that the answer is truncated.
On a working nameserver, the flags are 8180 for this query, so the same
without the truncation flag.

> > It therefore looks to me like a bug with your network setup, not a
> > libc one.
> 
> Well, though I didn't want that, this is quite a standard network
> setup: my machine just uses DHCP with some standard ADSL modem
> router. And given that many users have similar issues and there
> isn't any problem with Android, I suppose that there's some bug
> on the libc side (or libc can be improved).

Even if it is a quite standard setup, you have to admit it doesn't
behave according to the RFC. You should complain to the manufacturer
and try to get a firmware update.

Trying to workaround things on the libc side just gives even less value
to the RFCs, and encourage selling broken hardware.

> FYI, I also often get 5-second timeouts in name resolution whatever
> the host (you can see it above): I get the answer for A or , but
> sometimes, the other answer is lost. I have a DHCP hook that tests
> whether I'm using this router:
> 
> [...]
>   ping -n -c 1 -I "$interface" "$new_routers" > /dev/null
>   if grep -i -q $mac /proc/net/arp; then
> logger "Google Public DNS with TCP to avoid recurrent timeout"
> [...]

This show how broken is your name server. It probably has problem with
 requests. Note that the RFC explicitly allows to not support some
request types (including  ones), but in that case the router must
provide an answer that it doesn't support it and not simply drop it.
You might want to try to workaround this by using "options
single-request" or "options single-request-reopen" in etc/resolv.conf.

In short it cleary shows that the problem comes from the name server and
not the GNU libc:
- the nameserver set the truncation bit
- the nameserver doesn't answer on the TCP port
- the nameserver sometimes drop  queries

With such a

Bug#834189: php-common: php-maintscript-helper loses admin changes on package reinstall/upgrade

2016-08-12 Thread Felipe Sateler

Package: php-common
Version: 1:42
Severity: serious
Justification: Policy 10.7.3

Policy says: local changes must be preserved during a package upgrade.

And yet:

% ls -l /etc/php/7.0/cli/conf.d/20-xdebug.ini 
lrwxrwxrwx 1 root root 38 Aug 12 16:15 /etc/php/7.0/cli/conf.d/20-xdebug.ini -> 
/etc/php/7.0/mods-available/xdebug.ini

% sudo phpdismod -s cli xdebug

% ls -l /etc/php/7.0/cli/conf.d/20-xdebug.ini
ls: cannot access '/etc/php/7.0/cli/conf.d/20-xdebug.ini': No such file or 
directory

% sudo apt install --reinstall php-xdebug
 

% ls -l /etc/php/7.0/cli/conf.d/20-xdebug.ini
lrwxrwxrwx 1 root root 38 Aug 12 17:17 /etc/php/7.0/cli/conf.d/20-xdebug.ini -> 
/etc/php/7.0/mods-available/xdebug.ini


Turns out p-m-s unconditionally calls phpenmod, and thus overrides admin
configuration on upgrades.


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

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

Versions of packages php-common depends on:
ii  psmisc  22.21-2.1+b1
ii  sed 4.2.2-7.1

php-common recommends no packages.

php-common suggests no packages.

-- no debconf information

Bug#806606: basemap: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Control: tags -1 pending

Hi Sandro,

On 08/02/2016 02:08 PM, Sebastiaan Couwenberg wrote:
> Because this RC bug is threatening the removal of several reverse
> dependencies I had a look at fixing it. The attached patch adds the
> build-arch target to the build-indep target dependencies to have the
> missing files built.

Since there has been no activity on this RC bug, I've uploaded a 0-day
NMU with the patch from my previous message.

Kind Regards,

Bas

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

Bug#834187: libcereal: FTBFS: print_helper.hpp:47:5: error: static assertion failed: Type has to implement operator<< to be printable

Source: libcereal
Version: 1.1.2-4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

libcereal fails to build from source in unstable/amd64:

  [..]

  Scanning dependencies of target test_set
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu'
  make -f unittests/CMakeFiles/test_set.dir/build.make 
unittests/CMakeFiles/test_set.dir/build
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu'
  [ 40%] Building CXX object unittests/CMakeFiles/test_set.dir/set.cpp.o
  cd 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu/unittests
 && /usr/bin/c++   -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MODULE=test_set 
-I/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/./include
  -std=c++11 -Wall -Werror -g -Wextra -Wshadow -pedantic -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2-o CMakeFiles/test_set.dir/set.cpp.o -c 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/unittests/set.cpp
  [ 40%] Linking CXX executable test_basic_string
  cd 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu/unittests
 && /usr/bin/cmake -E cmake_link_script 
CMakeFiles/test_basic_string.dir/link.txt --verbose=1
  /usr/bin/c++   -std=c++11 -Wall -Werror -g -Wextra -Wshadow -pedantic -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2-Wl,-z,relro 
CMakeFiles/test_basic_string.dir/basic_string.cpp.o  -o test_basic_string 
-rdynamic -lboost_serialization -lboost_unit_test_framework 
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu'
  [ 40%] Built target test_basic_string
  make -f unittests/CMakeFiles/test_structs_specialized.dir/build.make 
unittests/CMakeFiles/test_structs_specialized.dir/depend
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu'
  cd 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu
 && /usr/bin/cmake -E cmake_depends "Unix Makefiles" 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/unittests
 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu
 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu/unittests
 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu/unittests/CMakeFiles/test_structs_specialized.dir/DependInfo.cmake
 --color=
  Scanning dependencies of target test_structs_specialized
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu'
  make -f unittests/CMakeFiles/test_structs_specialized.dir/build.make 
unittests/CMakeFiles/test_structs_specialized.dir/build
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu'
  [ 40%] Building CXX object 
unittests/CMakeFiles/test_structs_specialized.dir/structs_specialized.cpp.o
  cd 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu/unittests
 && /usr/bin/c++   -DBOOST_TEST_DYN_LINK 
-DBOOST_TEST_MODULE=test_structs_specialized 
-I/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/./include
  -std=c++11 -Wall -Werror -g -Wextra -Wshadow -pedantic -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2-o 
CMakeFiles/test_structs_specialized.dir/structs_specialized.cpp.o -c 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/unittests/structs_specialized.cpp
  [ 40%] Linking CXX executable test_priority_queue
  cd 
/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2/obj-x86_64-linux-gnu/unittests
 && /usr/bin/cmake -E cmake_link_script 
CMakeFiles/test_priority_queue.dir/link.txt --verbose=1
  /usr/bin/c++   -std=c++11 -Wall -Werror -g -Wextra -Wshadow -pedantic -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20160812213006.5DlrPPF43q.db.libcereal/libcereal-1.1.2=.
 -fstack-protector-strong

Bug#833760: cufflinks: please use the default boost version

2016-08-12 Thread Andreas Tille

Hi Mattia,

On Fri, Aug 12, 2016 at 07:33:06PM +, Mattia Rizzolo wrote:
> Hi Andreas! :)
> 
> On Mon, Aug 08, 2016 at 04:54:08PM +0200, Andreas Tille wrote:
> > Currently I can't upload since
> > cufflinks does not build.  If the new version of liblemon would not have
> > been rejected by ftpmaster for a reason others do not agree with[2] we
> > could have started to port cufflinks to the new liblemon library (which
> > is definitely not a trivial change but seems to me a promising way to
> > deal with the issue anyway - probably in connection with upstream).
> 
> Be aware that except from a package that is already being NMUed and
> digikam that regressed yesterday, this is actually the only package
> blocking the removal

Sorry, this does not help.  There is this large thread on
debian-devel[2] which I triggered and which IMHO goes totally in the
wrong direction nitpicking about copyrights inside binary packages which
is IMHO orthogonal to the interest of our users (would a user really
*copy* from binary results and if this really stupid intention is really
done would this person care about copyright at all? - may be I'll write
something in this thread but I'm afraid that's just a waste of time).

Cufflinks just does not build (neither with boost 1.60 nor 1.61 and
I have no chance to upload it.  Feel free to request the removal of
1.60 since it does not change the situation.

> > [2] https://lists.debian.org/debian-devel/2016/08/msg00099.html
> 
> /me does some lobbying for it.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#834188: qsapecng: FTBFS: type_traits/detail/has_binary_operator.hp:50: Parse error at "BOOST_JOIN"

Source: qsapecng
Version: 2.0.0-8
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

qsapecng fails to build from source in unstable/amd64:

  [..]

  Setting up libsm6:amd64 (2:1.2.2-1+b1) ...
  Setting up libxcb-dri3-0:amd64 (1.11.1-1.1) ...
  Setting up libxcb-glx0:amd64 (1.11.1-1.1) ...
  Setting up libxcb-randr0:amd64 (1.11.1-1.1) ...
  Setting up libxcb-xfixes0:amd64 (1.11.1-1.1) ...
  Setting up libxcb-render0:amd64 (1.11.1-1.1) ...
  Setting up libqt4-script:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libx11-6:amd64 (2:1.6.3-1) ...
  Setting up doxygen (1.8.11-3) ...
  Setting up qdbus (4:4.8.7+dfsg-8) ...
  Setting up libxcb-sync1:amd64 (1.11.1-1.1) ...
  Setting up libx11-xcb1:amd64 (2:1.6.3-1) ...
  Setting up libxt6:amd64 (1:1.1.5-1) ...
  Setting up libxcb-shape0:amd64 (1.11.1-1.1) ...
  Setting up libxrender1:amd64 (1:0.9.9-2) ...
  Setting up libqt4-dbus:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-network:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libaudio2:amd64 (1.9.4-5) ...
  Setting up fontconfig (2.11.0-6.5) ...
  Regenerating fonts cache... done.
  Setting up libxext6:amd64 (2:1.3.3-1) ...
  Setting up libxfixes3:amd64 (1:5.0.2-1) ...
  Setting up libqt4-xmlpatterns:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libxxf86vm1:amd64 (1:1.1.4-1) ...
  Setting up libqtgui4:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libxdamage1:amd64 (1:1.1.4-2+b1) ...
  Setting up libqt4-designer:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-help:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libgl1-mesa-glx:amd64 (11.2.2-1) ...
  Setting up libqt4-svg:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-scripttools:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-opengl:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-declarative:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-qt3support:amd64 (4:4.8.7+dfsg-8) ...
  Setting up libqt4-dev-bin (4:4.8.7+dfsg-8) ...
  Setting up libqwt6abi1 (6.1.2-5.2) ...
  Setting up libqt4-dev (4:4.8.7+dfsg-8) ...
  Setting up libqwt-dev (6.1.2-5.2) ...
  Setting up qsapecng-build-deps (2.0.0-8) ...
  Processing triggers for libc-bin (2.23-4) ...
  Processing triggers for systemd (231-1) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=c3b5ed5a2f12
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  PWD=/home/lamby/temp/cdt.20160812213535.Tol51km3Jh.db.qsapecng/qsapecng-2.0.0
  OLDPWD=/home/lamby/temp/cdt.20160812213535.Tol51km3Jh.db.qsapecng
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  GPG_KEY=1E953E27D4311E58
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building qsapecng 2.0.0-8 on amd64 
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package qsapecng
  dpkg-buildpackage: info: source version 2.0.0-8
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Simone Rossetto 

   dpkg-source --before-build qsapecng-2.0.0
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh clean 
 dh_testdir
 debian/rules override_dh_auto_clean
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160812213535.Tol51km3Jh.db.qsapecng/qsapecng-2.0.0'
  dh_auto_clean
  rm -fr doc/html doc/latex
  rm -f src/gui/qtsolutions/qtpropertyeditor/moc_*
  rm -f src/gui/qtsolutions/qtpropertyeditor/*.moc
  rm -f src/libqwt6_fix.h
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160812213535.Tol51km3Jh.db.qsapecng/qsapecng-2.0.0'
 dh_clean
   debian/rules build
  dh build 
 dh_testdir
 dh_update_autotools_config
 debian/rules override_dh_auto_configure
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160812213535.Tol51km3Jh.db.qsapecng/qsapecng-2.0.0'
  dh_auto_configure -- \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_EXE_LINKER_FLAGS="-Wl,-z,relro"
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None

Bug#828178: afl: FTBFS: clang error unknown argument -fdebug-prefix-map=/build/afl-2.16b=.'

2016-08-12 Thread Santiago Vila

On Fri, Aug 12, 2016 at 01:55:50PM -0400, Daniel Kahn Gillmor wrote:
> On Fri 2016-08-12 13:22:21 -0400, Santiago Vila wrote:
> > On Mon, 27 Jun 2016, Daniel Kahn Gillmor wrote:
> >> I think clang introduced -fdebug-prefix-map in 3.8.0 (see
> >> https://bugs.debian.org/819185) and afl build-depends on clang-3.7.
> >> 
> >> I assume that it's the reproducible-builds toolchain that's adding the
> >> -fdebug-prefix-map option to CFLAGS, right?  That's good -- it should
> >> help avoid variations in the generated binaries due to build path alone,
> >> so please keep it!  seems like the right fix here is either to build afl
> >> against a newer version of clang, or to resolve #819185 by backporting
> >> the option to clang-3.7.
> >
> > Actually, it's dpkg-buildflags who's adding -fdebug-prefix-map.
> >
> > So this bug was not really blocked by 819185. afl could well drop such
> > option from CFLAGS and friends, regardless of clang version used.
> 
> Sure, but we don't want that option dropped -- we want reproducible
> outputs regardless of the build path.  It'd be better to fix the
> toolchain (or to use a toolchain that's already fixed) than to mask the
> option and make sks unreproducible when the build path varies.

Let's see if I understood:

A. We want afl to build from source.
B. We want afl to build reproducibly.

What I said before is that A is not blocked by any bug in clang.

And your reply basically says that "A and B" is better than "only A".

Is this a state-the-obvious contest? :-)

Thanks.

Bug#834186: cpp-netlib: FTBFS: 94% tests passed, 1 tests failed out of 17

Source: cpp-netlib
Version: 0.11.2+dfsg1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

cpp-netlib fails to build from source in unstable/amd64:

  [..]

  /usr/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: 
#pragma message: NOTE: Use of this header (template_arity_spec.hpp) is 
deprecated
   # pragma message("NOTE: Use of this header (template_arity_spec.hpp) is 
deprecated")

  ^
  [ 90%] Linking CXX executable ../../../example/hello_world_server
  cd 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu/libs/network/example
 && /usr/bin/cmake -E cmake_link_script 
CMakeFiles/hello_world_server.dir/link.txt --verbose=1
  /usr/bin/c++   -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wall   -Wl,-z,relro 
CMakeFiles/hello_world_server.dir/http/hello_world_server.cpp.o  -o 
../../../example/hello_world_server -rdynamic -lboost_thread -lboost_system 
-lboost_date_time -lboost_regex -lboost_program_options -lboost_filesystem 
-lboost_chrono -lpthread -lssl -lcrypto -lrt 
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu'
  [ 90%] Built target hello_world_server
  make -f libs/network/example/CMakeFiles/hello_world_client.dir/build.make 
libs/network/example/CMakeFiles/hello_world_client.dir/depend
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu'
  cd 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu
 && /usr/bin/cmake -E cmake_depends "Unix Makefiles" 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1
 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/libs/network/example
 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu
 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu/libs/network/example
 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu/libs/network/example/CMakeFiles/hello_world_client.dir/DependInfo.cmake
 --color=
  Scanning dependencies of target hello_world_client
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu'
  make -f libs/network/example/CMakeFiles/hello_world_client.dir/build.make 
libs/network/example/CMakeFiles/hello_world_client.dir/build
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu'
  [ 92%] Building CXX object 
libs/network/example/CMakeFiles/hello_world_client.dir/http/hello_world_client.cpp.o
  cd 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/obj-x86_64-linux-gnu/libs/network/example
 && /usr/bin/c++   -DBOOST_NETWORK_ENABLE_HTTPS -DBOOST_TEST_DYN_LINK 
-I/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1
  -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wall   -o 
CMakeFiles/hello_world_client.dir/http/hello_world_client.cpp.o -c 
/home/lamby/temp/cdt.20160812211802.WL6OdPXgKR.db.cpp-netlib/cpp-netlib-0.11.2+dfsg1/libs/network/example/http/hello_world_client.cpp
  In file included from 
/usr/include/boost/iostreams/detail/is_dereferenceable.hpp:12:0,
   from /usr/include/boost/iostreams/detail/resolve.hpp:26,
   from /usr/include/boost/iostreams/detail/push.hpp:24,
   from 
/usr/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
   from /usr/include/boost/iostreams/stream_buffer.hpp:22,
   from /usr/include/boost/iostreams/stream.hpp:21,
   from 
/usr/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
   from /usr/include/boost/spirit/home/qi/stream/stream.hpp:16,
   from /usr/include/boost/spirit/home/qi/stream.hpp:15,
   from /usr/include/boost/spirit/home/qi.hpp:30,
   from /usr/include/boost/spirit/include/qi.hpp:16,
   from

Bug#827894: Segfault on start

2016-08-12 Thread Paul Gevers

Hi Enrico,

On Tue, 19 Jul 2016 21:06:33 +0200 Paul Gevers  wrote:
> Control: forwarded -1 https://github.com/lwindolf/liferea/issues/366

> On 22-06-16 10:00, Enrico Zini wrote:
> > I'll keep the original database around just in case.
> 
> Let's see if upstream wants to have a look at it.

Upstream is requesting a backtrace with debugging symbols (for now,
rather than having the database) because it can be shared publicly. Are
you in the position to create that? (If you are fine with it, please
follow-up directly in the upstream bug report).

Paul

signature.asc
Description: OpenPGP digital signature

Bug#834185: RFS: osmose-emulator/1.0-1 [ITP] -- Sega Master System and Game Gear console emulator

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "osmose-emulator"

 * Package name: osmose-emulator
   Version : 1.0-1
   Upstream Author : Bruno Vedder 
 * URL : http://bcz.asterope.fr/osmose.htm
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  osmose-emulator - Sega Master System and Game Gear console emulator

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

  https://mentors.debian.net/package/osmose-emulator


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

  dget -x https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose-
emulator_1.0-1.dsc

  More information about osmose-emulator can be obtained from
https://github.com/coringao/osmose-emulator.


  Regards,
   Carlos Donizete Froes



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

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

Bug#826300: Share knowledge on fpc and powerpc issue

2016-08-12 Thread Paul Gevers

Hi Adam,

During Debconf you found out what the issue was with fpc on powerpc
(glibc update related). We haven't seen a solution yet (I expect you are
too busy), but could you at least share your current knowledge such that
others could investigate further and e.g. check that upstream doesn't
already have a solution?

I fear all others involved so far don't have the skills to fix the issue.

If no solution to this issue is created soon, I think it is best to
acknowledge that we (all involved) can't practically fix the issue
(caused by lack of skills and/or time) and we'll need request removal of
the whole fpc stack in sid and stretch on powerpc.

There are multiple improvements pending for upload, but that doesn't
make much sense, because it won't migrate to stretch anyways. Also
already multiple updates of reverse dependent packages are blocked by
this issue.

Paul

P.S. yes I know I reset the auto-removal timer by writing this e-mail
but I promise to act before the original timer anyways and auto-removal
only solves a minor part of the issue.



signature.asc
Description: OpenPGP digital signature

Bug#834035: kdb5_util hangs forever

2016-08-12 Thread Benjamin Kaduk

On Thu, 11 Aug 2016, Greg Hudson wrote:

> I do not understand the kernel behavior reflected in this trace
> output.  For fd 3 (principal.ok), we see:

Yes, it would be good to get the kernel version from the reporter on the
affected machine (and the unaffected ones, too, for comparison).

(Using reportbug instead of manual mail to sub...@bugs.debian.org would
include that information automatically.)

(Including full text from Greg's message since it looks like it did not
make it to Michael originally.)

-Ben

> fcntl64(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, 
> l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
> fcntl64(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) 
> = 0
> fcntl64(3, F_OFD_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, 
> l_len=6950411022381350912}) = 0
> fcntl64(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, 
> l_len=6950411022381350912}
>
> So it tries to acquire an OFD lock and fails, then falls back to a POSIX
> lock.  When it releases the lock, releasing it as an OFD lock succeeds,
> so it doesn't fall back to releasing a POSIX lock.  It then tries to
> acquire an OFD lock and deadlocks against its POSIX lock.
>
> For fd 5 (kadm5.lock), it also falls back to acquiring a POSIX lock.
> Releasing the lock as an OFD lock fails, so it correctly falls back to
> releasing its POSIX lock:
>
> fcntl64(5, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, 
> l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
> fcntl64(5, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) 
> = 0
> fcntl64(5, F_OFD_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, 
> l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
> fcntl64(5, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) 
> = 0
>
> From the code, l_len should clearly be 0 (see lib/krb5/os/lock_file.c
> line 131), but strace is displaying a large number instead.  I don't
> know if this is an strace display bug or something else, and whether it
> is related to the EINVAL results.  The large value appears in both
> successful and failed F_OFD_SETLKW/F_UNLCK calls.
>
>

Bug#834184: RFS: osmose-emulator/1.0-1 [ITP] -- Sega Master System and Game Gear console emulator

Package: osmose-emulator
Severity: normal


  Dear mentors,

  I am looking for a sponsor for my package "osmose-emulator"

 * Package name: osmose-emulator
   Version : 1.0-1
   Upstream Author : Bruno Vedder 
 * URL : http://bcz.asterope.fr/osmose.htm
 * License : GPL-3+
   Section : games

  It builds those binary packages:

osmose-emulator - Sega Master System and Game Gear console emulator

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

  https://mentors.debian.net/package/osmose-emulator


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

  dget -x https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose-
emulator_1.0-1.dsc

  More information about osmose-emulator can be obtained from
https://github.com/coringao/osmose-emulator/wiki

  Changes since the last upload:

  https://github.com/coringao/osmose-emulator/blob/master/CHANGELOG


  Regards,
   Carlos Donizete Froes



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

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

Bug#834163: libmagick++: undefined behavior on concurrent access because mutex locking is poorly done

2016-08-12 Thread Bastien ROUCARIES

On Fri, Aug 12, 2016 at 6:16 PM, Guillaume Gimenez  wrote:
> Package: libmagick++-6.q16-5v5
> Version: 8:6.8.9.9-7.2
> Severity: important
> File: libmagick++
> Tags: patch
>
> Dear Maintainer,
>
> There is a bug in the locking implentation (RAII was the intended C++ idiom) 
> that has been fixed upstream.
>
> http://git.imagemagick.org/repos/ImageMagick/commit/5cbe21ed2728da0e611154d2f8e41bb63095a62c
>
> Unfortunately, the commit message is empty...
>
> In the unfixed code, the mutex acquisition has no effect and doesn't prevent 
> concurrent access to ref counters.
>
> This bug generates a lot of crashes when Magick++ is used with multi-threaded 
> applications

Do you have a small test case ?

If so it is a security bug. Could you ask for a CVE ?

Bastien
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=locale: Cannot set LC_CTYPE 
> to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libmagick++-6.q16-5v5:amd64 depends on:
> ii  libc6  2.23-4
> ii  libgcc11:6.1.1-10
> ii  libmagickcore-6.q16-2  8:6.8.9.9-7.2
> ii  libmagickwand-6.q16-2  8:6.8.9.9-7.2
> ii  libstdc++6 6.1.1-10
>
> libmagick++-6.q16-5v5:amd64 recommends no packages.
>
> libmagick++-6.q16-5v5:amd64 suggests no packages.
>

Bug#834183: Double free

2016-08-12 Thread Bastien ROUCARIES

Package: src:imagemagick
Version: 8:6.7.7.10-5
Severity: grave
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
forwarded: 
https://www.imagemagick.org/discourse-server/viewtopic.php?f=3=30245

Double free in pwp file.

Fixed by commit ecc03a2518c2b7dd375fde3a040fdae0bdf6a521

Bug#831908: Re-reading jurnal

2016-08-12 Thread SZALAY Attila

Hi,

I found an open issue in the upstream github repository which talks about a 
similar problem.

You should consider participating in this issue. 

https://github.com/balabit/syslog-ng/issues/1091

Bug#834182: scalapack: Please switch to openmpi for hppa architecture

2016-08-12 Thread Helge Deller

Package: scalapack
Version: 1.8.0-12.3
Severity: normal

Can you please upload a new version in which the hppa architecture is switched 
from mpich to openmpi ?
The original change to switch to openmpi for hppa in package mpi-defaults 
happened in:
  Bug#833425: mpi-defaults: switch to openmpi on hppa architecture

Thanks!
Helge

Bug#834181: blacs-mpi: Please switch to openmpi for hppa architecture

2016-08-12 Thread Helge Deller

Package: blacs-mpi
Version: 1.1-33.3
Severity: normal

Can you please upload a new version in which the hppa architecture is switched 
from mpich to openmpi ?
The original change to switch to openmpi in package mpi-defaults happened in:
  Bug#833425: mpi-defaults: switch to openmpi on hppa architecture

Thanks!
Helge

Bug#833707: libtasn1-6 FTCBFS: runs help2man on host architecture binaries

2016-08-12 Thread Helmut Grohne

Hi Andreas,

On Fri, Aug 12, 2016 at 07:10:23PM +0200, Andreas Metzler wrote:
> How about doing a simple
> 
> # cross-compiling
> if [ `dpkg-architecture -q DEB_BUILD_GNU_TYPE` != `dpkg-architecture -q 
> DEB_HOST_GNU_TYPE` ] ; then \
> touch `grep -l help2man doc/*.[1-8]` ; \
> fi

I generally prefer a builds-from-source experience over a
reuse-precompiled-stuff experience. For that reason, my proposed patch
actually runs help2man.

> in debian/rules's override_dh_auto_configure instead? Just looking at
> the results it has the same problem as the
> use-system-libtasn1-bin-approach, the shipped manpage does not
> necessarily match the built binaries. However it is not worse but
> guarantees that the upstream version matches.

I was trying to add the ability to say "Build-Depends: something (=
${source:Version})" to dpkg without success. Technically, the versions
can indeed mismatch. In a typical cross build scenario, they will always
match.

> Also this would be zero-maintainance instead of carrying a patch.
> Would this be an acceptable solution for the problem?

Your approach certainly works for me.

The preference stated above is a mild one and there are quite a few ways
to address help2man issues. We saw only two thus far. Others include:
 * Dropping manual pages in a  profile.
 * Splitting manual pages into an arch:all package.

Given that I wanted to provide a patch, I had to choose one. There
doesn't seem to be a universally best solution to this issue.

Bonus points if native builds validate that the help2man output matches
the shipped copies to ensure cross vs. native reproducibility. ;)

Helmut

Bug#834174: Removal of -Werror=security in GDAL rules is useless

On 08/12/2016 09:50 PM, Even Rouault wrote:
> Le vendredi 12 août 2016 21:39:26, Sebastiaan Couwenberg a écrit :
>> Due to the recent GCC 6/ICU 57/Boost 1.61 transitions there are large
>> number of changed C++ symbols which break the ABI. I am therefore
>> hesitant to upload a new GDAL revision now, I don't want any segfaulting
>> reverse dependencies because of undefined references to the old (now
>> missing) symbols. The change for the above is committed in git, and will
>> be included in the next upload. That will be for GDAL 2.1.2 or if GDAL
>> is rebuilt for another transition and the reverse dependencies are not
>> adversely affected or if they are and we do another transition for GDAL.
> 
> There's certainly no need to do a package rebuild for that. Was just to note 
> that some historical leftover was no longer needed.

A new build is not strictly required, no. The severity of this issue is
not high enough. But I don't like outstanding bugreports, and I won't be
able to close this one as soon as I'd like with a new upload.

Kind Regards,

Bas

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

Bug#834180: bristol: FTBFS: audioEngineJack.c:42:26: fatal error: alsa/iatomic.h: No such file or directory

Source: bristol
Version: 0.60.11-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

bristol fails to build from source in unstable/amd64:

[..]

libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:26: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms
are deprecated. For more info, see:
configure.ac:26:
http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:31: installing './compile'
configure.ac:26: installing './missing'
bin/Makefile.am: installing './depcomp'
debian/rules override_dh_auto_configure
make[1]: Entering directory
'/home/lamby/temp/cdt.20160812211734.6zaizKywgD.db.bristol/bristol-0.60.11'
dh_auto_configure -- --prefix=/usr --libdir=\${prefix}/lib/bristol \
--enable-jack-default-audio --enable-jack-default-midi
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --libdir=\${prefix}/lib/bristol
--enable-jack-default-audio --enable-jack-default-midi
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format...
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if

Bug#824990: Please update transmission to 2.92

2016-08-12 Thread Jeremy Bicha

I updated transmission in Ubuntu. I'm attaching a patch with the changes.

Thanks,
Jeremy Bicha


update-transmission-to-2.92.patch
Description: Binary data

Bug#559707: [terminator] middle click is interpreted in a weird way

2016-08-12 Thread Witold Baryluk

Package: terminator
Version: 0.98-1
Followup-For: Bug #559707

I am not sure if this is the same issue, but I do also have issues with
pasting via middle click recently.

Often pasting via middle click or Shift+Insert, will add a 0~ to the start
and 1~ to the end of selection. I.e. copied 'workqueue', it ends pasted as
0~workqueue1~.

What is strange, when I have multiple subterminals in terminator, not all of 
them
shows this behaviour. Usually calling 'reset' in the terminal, or opening new
one it will stop adding this weird characters. But otherwise I do not know why
some terminals shows this prolems and some doesn't.

My theory is that this have something to my use of midnight commander
file manager and text editor. If I open a new terminal, or do reset
everything works just fine with pasting. When I open mc or mcedit, and
exit without doing anything, the problem will start showing up, until I
do 'reset'.



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

Kernel: Linux 4.7.0-rc7-wc1-6-g63bab22 (SMP w/12 CPU cores; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages terminator depends on:
ii  gconf2  3.2.6-3
ii  python-dbus 1.2.4-1
ii  python-gobject  3.20.1-1
ii  python-gtk2 2.24.0-5
ii  python-vte  1:0.28.2-5+b1
pn  python:any  

Versions of packages terminator recommends:
ii  python-gnome2 2.28.1+dfsg-1.1
ii  python-keybinder  0.3.1-1
ii  python-notify 0.1.1-4
ii  xdg-utils 1.1.1-1

terminator suggests no packages.

-- no debconf information

Bug#745027: Status

2016-08-12 Thread Markus Unterwaditzer

On Fri, Aug 12, 2016 at 07:19:06PM +0200, Filip Pytloun wrote:
> Hello,
> 
> I have finally got some time to move this forward.
> 
> Packaged dependencies:
> 
>   python-atomicwrites
>   python-click-log
>   python-click-threading (waiting in NEW)
> 
> and almost finished vdirsyncer packaging to be under PAPT team, now
> waiting for review [1] and accept of python-click-threading.
> 
> [1] https://github.com/fpytloun/debian-vdirsyncer/tree/master/debian
> 
> Filip

Hello Filip,

First, thanks for your efforts! I really apprechiate your work.

I see that you have added a few patches to your Debian package.

> 0001-Do-not-require-setuptools-scm.patch

I couldn't find how you're getting the sourcecode, but this should not be
necessary if you're using the tarballs from PyPI. See
https://vdirsyncer.pimutils.org/en/stable/packaging.html#obtaining-the-source-code

It appears that python3-setuptools-scm is also available in Debian, so adding
it as build dependency (instead of runtime dependency) should be possible.

It seems that this is a bit unclear as I've discovered a similar patch in
Fedora. Please rather reach out and discuss things with me before doing this.
I'm saying this because I suspect that the metadata for the installed package
will be wrong (Python software can query the installed version of a package
with the `pkg_resources` module) because setup.py now doesn't contain any
version information.

> 0002-Don-t-use-subtest.patch

Fair enough, it is a pretty small package.

> 0003-Skip-ssl-tests.patch

This might be caused by the `HTTP_PROXY` and `HTTPS_PROXY` envvars. I'd try
unsetting them in the build environment.

> 0004-Include-license-from-copyright-file.patch

As far as I understand, this is including this file:
https://github.com/fpytloun/debian-vdirsyncer/blob/master/debian/copyright

However, the LICENSE file should be included in the PyPI package.

Please do reach out if you encounter problems.

Cheers,
Markus

signature.asc
Description: PGP signature

Bug#834179: ITP: osmose-emulator -- Sega Master System and Game Gear console emulator

Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: osmose-emulator
  Version : 1.0
  Upstream Author : Bruno Vedder 
* URL : http://bcz.asterope.fr/osmose.htm
* License : GPL-3+
  Programming Lang: C++
  Description : Sega Master System and Game Gear console emulator

 A multi-machine emulator for platforms of Sega consoles
 (Master System and Game Gear) and compatible for all games.
 .
 Simulates hardware extremely accurately which ensures that these
 classic games are represented exactly like they were on the real systems.
 .
 Osmose has a clean graphical user interface based on QT and a simplified setup
 process, and supports ROM archives in the SMS and GG formats.

Bug#834178: gdm3: Passwords are readable while typing

2016-08-12 Thread Evangelos Skarmoutsos

Package: gdm3
Version: 3.20.1-1
Severity: normal

Dear Maintainer,

once every 200-400 logouts, the next user can read his password while typing.

If login button is pressed using a wrong password, the next login attempt works
correctly (characters can not be read and are represented as dots).

I was expecting passwords to never be readable.



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

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

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.40-3
ii  adduser  3.115
ii  dconf-cli0.26.0-1
ii  dconf-gsettings-backend  0.26.0-1
ii  debconf [debconf-2.0]1.5.59
ii  gir1.2-gdm-1.0   3.20.1-1
ii  gnome-session [x-session-manager]3.20.2-1
ii  gnome-session-bin3.20.2-1
ii  gnome-session-flashback [x-session-manager]  3.20.2-1
ii  gnome-settings-daemon3.20.1-2
ii  gnome-shell  3.20.3-1+b1
ii  gnome-terminal [x-terminal-emulator] 3.20.2-2
ii  gsettings-desktop-schemas3.20.0-3
ii  libaccountsservice0  0.6.40-3
ii  libaudit11:2.6.5-1
ii  libc62.23-4
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgdm1  3.20.1-1
ii  libglib2.0-0 2.48.1-2
ii  libglib2.0-bin   2.48.1-2
ii  libgtk-3-0   3.20.7-1
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpam-systemd   230-7
ii  libpam0g 1.1.8-3.3
ii  librsvg2-common  2.40.16-1
ii  libselinux1  2.5-3
ii  libsystemd0  230-7
ii  libwrap0 7.6.q-25
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.2-1.1
ii  lsb-base 9.20160629
ii  metacity [x-window-manager]  1:3.20.2-1
ii  mutter [x-window-manager]3.20.3-2
ii  policykit-1  0.105-16
ii  ucf  3.0036
ii  x11-common   1:7.7+16
ii  x11-xserver-utils7.7+7

Versions of packages gdm3 recommends:
ii  at-spi2-core2.20.2-1
ii  desktop-base8.0.2
ii  x11-xkb-utils   7.7+3
ii  xserver-xephyr  2:1.18.4-1
ii  xserver-xorg1:7.7+16
ii  zenity  3.20.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.20.2-1
ii  libpam-gnome-keyring  3.20.0-1

-- Configuration Files:
/etc/gdm3/Init/Default changed:
PATH="/usr/bin:$PATH"
OLD_IFS=$IFS
gdmwhich () {
  COMMAND="$1"
  OUTPUT=
  IFS=:
  for dir in $PATH
  do
if test -x "$dir/$COMMAND" ; then
  if test "x$OUTPUT" = "x" ; then
OUTPUT="$dir/$COMMAND"
  fi
fi
  done
  IFS=$OLD_IFS
  echo "$OUTPUT"
}
sysresources=/etc/X11/Xresources
if [ -f "$sysresources" ]; then
xrdb -merge "$sysresources"
fi
sysmodmap=/etc/X11/Xmodmap
XMODMAP=`gdmwhich xmodmap`
if [ "x$XMODMAP" != "x" ] ; then
  if [ "x$GDM_PARENT_DISPLAY" = "x" ]; then
if [ -f $sysmodmap ]; then
  $XMODMAP $sysmodmap
fi
  else
( DISPLAY=$GDM_PARENT_DISPLAY XAUTHORITY=$GDM_PARENT_XAUTHORITY $XMODMAP 
-pke ) | $XMODMAP -
  fi
  #
  # Switch Sun's Alt and Meta mod mappings
  #
  UNAME=`gdmwhich uname`
  PROCESSOR=`$UNAME -p`
  if [ "x$PROCESSOR" = "xsparc" ]; then
if $XMODMAP | grep mod4 | grep Alt > /dev/null 2>/dev/null
then
  $XMODMAP -e "clear Mod1" \
   -e "clear Mod4" \
   -e "add Mod1 = Alt_L" \
   -e "add Mod1 = Alt_R" \
   -e "add Mod4 = Meta_L" \
   -e "add Mod4 = Meta_R"
fi
  fi
fi
SETXKBMAP=`gdmwhich setxkbmap`
if [ "x$SETXKBMAP" != "x" ] ; then
  # FIXME: is this all right?  Is this completely on crack?
  # What this does is move the xkb configuration from the GDM_PARENT_DISPLAY
  # FIXME: This should be done in code.  Or there must be an easier way ...
  if [ -n "$GDM_PARENT_DISPLAY" ]; then
XKBSETUP=`( DISPLAY=$GDM_PARENT_DISPLAY XAUTHORITY=$GDM_PARENT_XAUTHORITY

Bug#834174: Removal of -Werror=security in GDAL rules is useless

2016-08-12 Thread Even Rouault

Le vendredi 12 août 2016 21:39:26, Sebastiaan Couwenberg a écrit :
> Control: tags -1 pending
> 
> Hi Even,
> 
> Thanks for reporting this issue.
> 
> On 08/12/2016 08:13 PM, Even Rouault wrote:
> > The debian/rules file contains the following lines  :
> > """
> > # Remove -Werror=format-security, causes build failure on
> > ogrsxfdatasource.cpp CFLAGS   = $(shell dpkg-buildflags --get CFLAGS)
> > CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS)
> > 
> > CFLAGS   := $(filter-out -Werror=format-security, $(CFLAGS))
> > CXXFLAGS := $(filter-out -Werror=format-security, $(CXXFLAGS))
> > """
> > 
> > They are probably unneeded since GDAL 2.1.0
> 
> I've removed buildflags changes, and the build now indeed doesn't fail
> any more. Thanks for fixing that upstream!
> 
> Due to the recent GCC 6/ICU 57/Boost 1.61 transitions there are large
> number of changed C++ symbols which break the ABI. I am therefore
> hesitant to upload a new GDAL revision now, I don't want any segfaulting
> reverse dependencies because of undefined references to the old (now
> missing) symbols. The change for the above is committed in git, and will
> be included in the next upload. That will be for GDAL 2.1.2 or if GDAL
> is rebuilt for another transition and the reverse dependencies are not
> adversely affected or if they are and we do another transition for GDAL.

There's certainly no need to do a package rebuild for that. Was just to note 
that some historical leftover was no longer needed.

> 
> Kind Regards,
> 
> Bas

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

Bug#834174: Removal of -Werror=security in GDAL rules is useless