Bug#841908: pyzor: discover subcommand seemingly gone

[Jonas Smedegaard]

Source: pyzor
Version: 1:1.0.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

README.Debian instructs to run "pyzor discover".

This worked in version 0.5, but now fails with "CRITICAL Unknown command: 
discover".

 - Jonas

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYDeymAAoJECx8MUbBoAEhUSkQAJ8gADivFnwQUqATNJHbiAOy
PqUwiaAORhGPRr/zuZjMH/gO5hYFU5ZyDSOyY5R/2Gu9iw+qq4pBlqKkNqqDlMAo
yVvOGZHt5jDlnS55CnMFpHG7k5n1qnkGuVhJN7GEkXeTVtDwLQ23sDopjttsoXV0
DJHw2mKpv/DZezA2Z45DJtnTo0IiPYDyp2voEu5G2/zt8bd4GR3s52XRs4RQpcht
9+vaCtnc9QrDI2p7Q8KywH7BqxtgTstv7ReErgu32k5ifrNuLjIZCBkEhYhWzlTj
gTpOzXaMNNON9VosLFYrzZFOHCGiLXJAormoHmCuThOBTXAjZBF4oYIRfntyIfdq
FXCV9bUVdPYSH2U60OzUpxuGxvTy7yoLDD4dI8PRz6/Xs7M6PPZBBNQjiIgi/QDo
gakcQJT/bLVFGGhU/TEE+dgsLX2hMBupNydnONOqVn+orA/GS5K1qrJ5v1RQM7ls
IXCiYbAXi4jxkmwxqjEP+DFiD+kkEUoOF8WR9y2RaBgdy93qkIR+IVUVSEjTA4m2
7yqziUC4GeH9INOSfXMQrO24ypKMHjlhc5E9rkmMbr3Wq0Z0f9Z1UBr3AJgBFtFE
Fz1cSgR22lA05MIlkwqvfQgg41IOLHlwbgQs1OyUYWGbhv7UCRdegAt39gEiJH2Z
IKpU9kJkX8avjuap4ZZE
=1w2P
-END PGP SIGNATURE-

Bug#841098: not fixed in rygel 0.32.1-1

[Andreas Henriksson]

Hello Santiago Vila.

Thanks for the backtrace, it's helpful.

On Fri, Oct 21, 2016 at 01:16:20PM +0200, Santiago Vila wrote:
> The package FTBFS (sometimes) because rygel-media-engine-test segfaults.
> 
> Here is a backtrace:
> 
> (gdb) bt
> #0  0x7f1a1a4b3fdf in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f1a1a4b540a in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x7f1a1af8a4f5 in g_assertion_message () from 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0

This is not a segfault though, but an assertion failure.

> #3  0x7f1a1af8a58a in g_assertion_message_expr () from 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #4  0x55597c5578bd in __lambda19_ (_data3_=) at 
> rygel-media-engine-test.c:2035
[...]

^^^ hint on where the failing assertion can be found.

(Please note that the source is vala so you'll need to translate this to
the applicable lambda in the vala source.)

> #5  ___lambda19__gsource_func (self=0x7f19f4001410) at 
> rygel-media-engine-test.c:2047
> #6  0x7f1a1af6368a in g_main_context_dispatch () from 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #7  0x7f1a1af63a40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #8  0x7f1a1af63d62 in g_main_loop_run () from 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #9  0x55597c559688 in rygel_data_source_test_test_stop_start 
> (error=0x7ffe67fae238, self=0x55597df7e4e0)
> at rygel-media-engine-test.c:2116
> #10 rygel_data_source_test_run (self=0x55597df7e4e0) at 
> rygel-media-engine-test.c:2717
> #11 0x55597c55a310 in rygel_data_source_test_main (args=, 
> args_length1=)
> at rygel-media-engine-test.c:2996
> #12 0x7f1a1a4a12b1 in __libc_start_main () from 
> /lib/x86_64-linux-gnu/libc.so.6
> #13 0x55597c556f4a in _start ()
> 
> It could be, of course, that my autobuilder is misconfigured, but the
> same segfault happened several times in buildd.debian.org in the past.

You're more than welcome to dive deep into this issue. Patches are
always welcome.

Claiming this is RC is a bit over the top though. If you're only out
to ride the policy train without actually wanting to debug it yourself
then I'll be forced to simply disable the testsuite. In my opinion
the testsuite exists to raise the quality of what we produce and
to *save* us time. If it becomes to time-consuming to maintain I'll
do without it. Disabling failing tests-suites is something I know
from personal experience that several release team members have
a strong opinion against. Disabling it for a extremely rare occational
failure is something I imagine they would be even more opposed to.

If you're strongly attached to (cluttering up my maintainer view and)
tracking every issue in the debian bug tracking system (I'd instead
recommend you use the upstream bug tracker), then I'd welcome
a bug report with severity minor. Minor is in my opinion the correct
severity for such an issue.

Regards,
Andreas Henriksson

Bug#841911: transition: pari

[Bill Allombert]

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

Dear release team, I would like to upgrade PARI to the upcoming 2.9.0
stable version, which bump the soname of libpari-gmp-tls4 to
libpari-gmp-tls5.

libpari-gmp-tls5 is in the NEW queue.

There are very few packages that build against libpari (I found only
two: lcalc and eclib).

Ben file:

title = "pari";
is_affected = .depends ~ "libpari-gmp-tls4" | .depends ~ "libpari-gmp-tls5";
is_good = .depends ~ "libpari-gmp-tls5";
is_bad = .depends ~ "libpari-gmp-tls4";

-- System Information:
Debian Release: 8.6
  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/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Bill. 

Imagine a large red swirl here. 

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

On Sun, Oct 23, 2016 at 02:06:29AM +0200, Marco d'Itri wrote:
> On Oct 23, Mark Brown  wrote:

> > I'd have expected to at least have seen something going round saying
> > that the transition was mostly complete and that there were only a few
> > packages blocking it prior to just dumping a new version of deboostrap
> > in unstable and rendering everything instabuggy.  Most similar

> I did this in *february* for the other packages, but not this one since 
> you had recently suggested that it was not ready anyway.

Telling other package maintainers doesn't help me know that this is a
transition that's actually happening, and one of the things that would
tell me that there might be some sense of urgency would be an indication
that the transition was actually happening.  I do remember you asking me
about my plans to fix it but there was no context that this was anything
more than a "hey, it'd be nice sometime".  For things like this even if
people aren't working on something now if there's a bigger picture it's
good to tell people about it, something like "OK, but please note that
we're actively working on this transition and expect it to be done for
stretch" would've really helped here in avoiding surprise with sudden RC
bugs out of nowhere.

> > I didn't ask for help because I just don't care about this transition,
> > in part because as I indicated there's no way to really use yp-tools at
> > present so it's the least of anyone's worries so when I'm spending time

> Maybe then the package should not be in testing anyway?

It's not impossible that someone could use it, it's just not as useful
as it could be.


signature.asc
Description: PGP signature

Bug#841919: acme-tiny: Please provide a backport for jessie

[Elena ``of Valhalla'']

Source: acme-tiny
Severity: wishlist

Dear Maintainer,

It would be nice to have a backported package of acme-tiny for Jessie.

If there are no unexpected issues, it is quite likely to be just a
simple rebuild, since there are no significant dependencies, and this is
the kind of program that is especially useful on a stable machine.

Thanks in advance.

Bug#841920: ITP: gnome-shell-extension-hide-activities -- gnome shell extension that hides the activities button

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-hide-activities
  Version : 0.00~git20131024.1.6574986-1
  Upstream Author : Shay Elkin
* URL : https://github.com/shayel/gnome-hide-activities
* License : PD
  Programming Lang: Javascript
  Description : gnome shell extension that hides the activities button

This extension hides the Acitivies text and button on the top left
corner of GNOME shell, making the appearance simpler and the panel
less cluttered.

Bug#841856: Correction of CVE-2016-7543 is incomplete

[Ola Lundqvist]

Hi

Thank you for the information. Good to know that I'm not the only one that
have seen this problem.

One can of course argue that the attack vector is a little odd. That is a
setuid binary making system. I thought system was safe enough, but now I
have learnt otherwise.

Anyway I do not think disabling PS4 variable would hurt much. Or do anyone
see that it is useful to set to something else than +?
Maybe we can allow PS4 to be expanded to some extent, but not allow it to
be expanded to execute commands?

// Ola

On 24 October 2016 at 18:37,  wrote:

> Quoting "Ola Lundqvist" :
>
> This is known.
>
> I "complained" at the time, as it can be seen here:
> https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00112.html
>
>
>
> Version: all (see note below)
>> Hardware: all
>> Operating system: Debian GNU Linux (but all should be affected)
>> Compiler: gcc
>>
>> Hi
>>
>> In CVE-2016-7543 a problem was reported that it is possible to privilege
>> escalate to root.
>> The correction as seen here
>> http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html
>> is not complete. Well it do prevent privilege escalation to root, but it
>> is
>> possible to escalate to any other user and that may be bad too.
>>
>> The problem has also been reported (by me) in Debian as you can see here:
>> http://bugs.debian.org/841856
>>
>> I have attached a tar file with exploit code. The exploit code is used
>> like
>> this:
>> make
>> sudo make root
>> make test
>>
>> Test 1 is the exploit for CVE-2016-7543
>> Test 2 is the exploit for this problem
>> Test 3 is just a reference test.
>>
>> The proposed patch essentially disable the whole PS4 variable support for
>> all users (not only root as the patch was for CVE-2016-7543. Please let me
>> know if you have a better idea on how to handle this.
>>
>> Version note: The attached correction is made on a 4.2 system with a patch
>> for CVE-2016-7543.
>> However it should apply on 4.4 as well.
>>
>> Let me know if you need any further details.
>>
>> Best regards
>>
>> // Ola
>>
>> --
>>  --- Inguza Technology AB --- MSc in Information Technology 
>> /  o...@inguza.comFolkebogatan 26\
>> |  o...@debian.org   654 68 KARLSTAD|
>> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>>  ---
>>
>>
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#841959: ismrmrd: Please support building against HDF5 1.10

[Gilles Filippini]

Source: ismrmrd
Version: 1.3.2-4
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. I intend to request a transition slot this week, and will NMU if 
need be.

Thanks,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmf1AAoJEO/obGx//s+D/JAH/jwCQJNrSWFti0S08UeFPbWb
vg5A89PYlsHqNfJpK0cI57RVIUYv936nzS2xTXagignRSCq4OR5c5FoyZIZplbm7
4jD8XWXsFDEAwfHNOye/s05vk21rKGuDi23KvHTPbtoU61Z7tuQvHUROtt8IeJQS
Wd0Lom6T3mCD3/f5C1lOoEMhy74Lb+9CfRXS+cYYw9DgAfJOPb0ahhyPCnZ6pY7U
uCGSwUx7XQ40kilOjp9Hlf7NFs3t1gcnvj0GFjJHZjzNsoGZwQo5RK5gZhn+u2c/
7a+8C/qvC2/2FH3IZfb+faDBTA+P8jh8wuKkbw2w1txpeF4R9c1iiPQ0bQeKbSg=
=Vhu8
-END PGP SIGNATURE-
diff -Nru ismrmrd-1.3.2/debian/changelog ismrmrd-1.3.2/debian/changelog
--- ismrmrd-1.3.2/debian/changelog	2016-09-02 12:27:37.0 +0200
+++ ismrmrd-1.3.2/debian/changelog	2016-10-19 00:59:02.0 +0200
@@ -1,3 +1,10 @@
+ismrmrd (1.3.2-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch to support HDF5 1.10
+
+ -- Gilles Filippini   Wed, 19 Oct 2016 00:58:32 +0200
+
 ismrmrd (1.3.2-4) unstable; urgency=medium
 
   * Fix FTBFS due to buggy HDF5 detection with CMake 3.6.
diff -Nru ismrmrd-1.3.2/debian/patches/hdf5-1.10.patch ismrmrd-1.3.2/debian/patches/hdf5-1.10.patch
--- ismrmrd-1.3.2/debian/patches/hdf5-1.10.patch	1970-01-01 01:00:00.0 +0100
+++ ismrmrd-1.3.2/debian/patches/hdf5-1.10.patch	2016-10-19 00:58:21.0 +0200
@@ -0,0 +1,21 @@
+Index: ismrmrd-1.3.2/include/ismrmrd/dataset.h
+===
+--- ismrmrd-1.3.2.orig/include/ismrmrd/dataset.h
 ismrmrd-1.3.2/include/ismrmrd/dataset.h
+@@ -9,6 +9,7 @@
+ #define ISMRMRD_DATASET_H
+ 
+ #include "ismrmrd/ismrmrd.h"
++#include 
+ 
+ #ifdef __cplusplus
+ #include 
+@@ -28,7 +29,7 @@ extern "C" {
+ typedef struct ISMRMRD_Dataset {
+ char *filename;
+ char *groupname;
+-int fileid;
++hid_t fileid;
+ } ISMRMRD_Dataset;
+ 
+ /**
diff -Nru ismrmrd-1.3.2/debian/patches/series ismrmrd-1.3.2/debian/patches/series
--- ismrmrd-1.3.2/debian/patches/series	2016-09-02 12:27:37.0 +0200
+++ ismrmrd-1.3.2/debian/patches/series	2016-10-19 00:56:47.0 +0200
@@ -3,3 +3,4 @@
 Use-explicit-64-bit-shifts-in-testsuite.patch
 Use-Debian-CMake-find-module-location.patch
 Fix-HDF5-detection-with-CMake-3.6.patch
+hdf5-1.10.patch

Bug#841917: RFS: gnome-shell-extensions-refresh-wifi/6-1, ITP: 841913 -- keep wifi access point list current in GNOME shell

[Tobias Frost]

Control: owner -1 !

Hi Jonathan,

Am Montag, den 24.10.2016, 14:49 +0200 schrieb Jonathan Carter
(highvoltage):
> 
> * Package name    : gnome-shell-extensions-refresh-wifi
>   Version : 6-1
>   Upstream Author : Gopi Sankar Karmegam
> * URL : https://github.com/kgshank/gse-refresh-wifi
> * License : GPL-3
>   Programming Lang: Javascript
>   Description : keep wifi access point list current in GNOME
> shell

can you add a gnome-shell dependency to the binary package?

Otherwise it is fine and I'll upload it then.

--
tobi

Bug#831562: ftp.debian.org: Allow source-only uploads to NEW when caused by minor changes in binary packaging

[Daniel Kahn Gillmor]

On Sun 2016-07-17 06:46:07 -0400, Ximin Luo wrote:
> I am trying to do a source-only upload [1] of the new rustc. I prefer to do
> source-only uploads because I like to have the buildds rebuild my amd64
> packages, for safety and security. Other reasons are documented on that page.
>
> With every new version of rustc, we have a new libstd-rust-$version binary
> package. This causes every upload to be added to NEW, which triggers the "no
> source-only uploads" rule, causing my upload to be REJECTED. IMO this is a bit
> pointless - the binary:NEW is not really a significant change, and if I wanted
> to "game the system" there are plenty of things I could do whilst keeping the
> binary package names the same. I can understand ftp-master wanting to do a
> manual audit regardless, but to turn this into an automatic REJECT simply
> because I didn't supply binary packages that I built myself, is inconvenient
> and defeats the purpose of the SourceOnlyUpload feature.

I'd like source-only uploads to NEW in general, not just for minor
changes in binary packaging.  

Looks like it might just be a configuration change
(Dinstall::AllowSourceOnlyNew) in modern versions of DAK:

https://anonscm.debian.org/git/mirror/dak.git/tree/daklib/checks.py#n706

Could we get this for debian's NEW queue?

  --dkg

Bug#841960: spamassassin: should suggest libgeo-ip-perl for Mail::SpamAssassin::Plugin::URILocalBL

[Jonas Smedegaard]

Source: spamassassin
Version: 3.4.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

SpamAssassin 3.4.1 introduced a few new plugins, including
Mail::SpamAssassin::Plugin::URILocalBL which requires Geo::IP.

The plugin is disabled by default, so only suggesting libgeo-ip-perl
should be adequate.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYDmqsAAoJECx8MUbBoAEhXxcP/0fN+bdhNsBEzLUc9OJv1sxi
owuysaA1KmCxNokdTLtrmnuA160BUo7iNGN89uzYpsvMiCO2faU9Yr8aCoklqkIv
fYAviG66HIV8MYxzJG3RsqWiOS6HJap7O91I2esFzYue6X/9q1gNythdTKQyIP2H
klAoOkXlDHdAd2OKF0idLWE6SPX4EpcT/KvcdpXwjFV4ThvxY1qfU0e+pSnPrNfr
pDu5ZvZo7yR4/UcItQJdBI85NfFOblw3Ga2wgFft755g8JP1DQSnYlr2J62koAip
4Ov65EiATS6T8pql3nAFVi559UVHSTwXpGnt9Lin3Ix5lbdjyJJRavIHxB5JwYv6
0TMmuHhycpC+wcr2OTl8+PVVPbuYJX2Yd85eJClp4zFHhXUXFVHpaG5ouQJHJdDV
Ipem0/E1VMefDNnaE7txPEc5YHL6zOj7utTMw+4385nOHS7veR3B04MOvvMazq5Y
Xzp4xQXUXJTMCQi2fLCY9xeGvrwl2tp5ZQxqrRm7h/lgGjH+YidSYlESGGjfPQYm
A+jMwG0QLsQFEJV1RbxH6JLkQzhn0VzP7FTlwgHnbFcQVoaUQLTIyNvNmW45ZVQb
CfHxrbEeboTP8/T1X0GJtz7V+Bd5phcoT0r5ylYex+3MF3u/BMFh+Re9WLz227af
/Q6pIT9jfAy2fjRZKBXV
=Qrxi
-END PGP SIGNATURE-

Bug#841961: nmu: ocaml_4.02.3-7

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please rebuild ocaml against the pie-enabled compiler chain, to fix an FTBFS of 
scilab package:

ocamlopt -o modelicac -I ./src/modelica_compiler -I ./src/xml2modelica  
nums.cmxa ./src/modelica_compiler/parseTree.cmx ./src/modelica_compiler/linenu
m.cmx ./src/modelica_compiler/parser.cmx ./src/modelica_compiler/lexer.cmx 
./src/modelica_compiler/precompilation.cmx ./src/modelica_compiler/compilat
ion.cmx ./src/modelica_compiler/instantiation.cmx 
./src/modelica_compiler/graphNodeSet.cmx 
./src/modelica_compiler/symbolicExpression.cmx ./src/modeli
ca_compiler/squareSparseMatrix.cmx ./src/modelica_compiler/bipartiteGraph.cmx 
./src/modelica_compiler/hungarianMethod.cmx ./src/modelica_compiler/caus
alityGraph.cmx ./src/modelica_compiler/optimization.cmx 
./src/modelica_compiler/xMLCodeGeneration.cmx 
./src/modelica_compiler/optimizingCompiler.cmx .
/src/modelica_compiler/scicosCodeGeneration.cmx 
./src/modelica_compiler/scicosOptimizingCompiler.cmx
/usr/bin/ld: /usr/lib/ocaml/libasmrun.a(fail.o): relocation R_X86_64_32 against 
symbol `caml_exn_Failure' can not be used when making a shared object;
 recompile with -fPIC
/usr/bin/ld: /usr/lib/ocaml/libasmrun.a(roots.o): relocation R_X86_64_32 
against symbol `caml_frametable' can not be used when making a shared object;
 recompile with -fPIC
...

nmu ocaml_4.02.3-7 . ANY . unstable . -m "rebuild with pie-enabled compiler 
chain"

Thanks in advance,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmoGAAoJEO/obGx//s+DxK0H/jgiHLrcx0gT0N6hfGuwrMO2
mvHmCcLGZKnLmDrkZzgIq+pPtC3qjjlPtBeR+VhvkCc3uPTVpHqZDil2lXmDA8sN
m+klsGk5pWiF1mxeMM37+/ts8JY6Dk+VQXzahBilNH13t21MXZnx3dfygLH/1bDq
3qQLvt8aKQ5UuhvzT/Fr/COXfuNGXsRL0sStUYlFOpg7raJNysQ6mZFXZqexlI+Y
IoUur2okpt57OJP5P7SrK1O8ciAHXb2JnhET2lxj2VmavHMmX0hfTAArsDwYMA0R
gSXyO4GaLZRXjcSazV69P/5MyGHg10yKevSSGI4JBKUAKt9g36/SBo5KW40nSks=
=4TOF
-END PGP SIGNATURE-

Bug#841962: libgpiv: Please support building against HDF5 1.10

[Gilles Filippini]

Source: libgpiv
Version: 0.6.1-4.3
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. I intend to request a transition slot this week, and will NMU if 
need be.

Thanks,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmx3AAoJEO/obGx//s+DgUcIAK8uMp4nysGG/iGBaUXNRSyP
cYfsv7ckfdOYO+nwal7SD+lhNL3eG908Qtf+UrfZ2ZjVAoEJLb9rWQGnm5k3G81C
+gGm+X09Xd6gf1gTI7MCVLXYO2Ik4Rle1k4D+fhu4lW6PLZp3V52Wz6Dgila8t5s
2Ttu55pb6LyEEjqT8znGd/1eZohGp00InOm+hXaiLIFnRWGL8OdK0QNgtScCKq0z
hmBCVpoIcU/jnpY8mjB8m7LBERnW6F0K/wxWAmbbgR4W+Mwt5uBRgJlVB0SqWb4l
YEjFz/9/4w+d3/symJpAUHd/NU8pWiEKQzkM94xrCPHXjTVKrgmCrPCONk9eCjk=
=5Iz5
-END PGP SIGNATURE-
diff -u libgpiv-0.6.1/debian/changelog libgpiv-0.6.1/debian/changelog
--- libgpiv-0.6.1/debian/changelog
+++ libgpiv-0.6.1/debian/changelog
@@ -1,3 +1,10 @@
+libgpiv (0.6.1-4.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch 04-avoid-bool-keyword.diff to fix FTBFS against HDF5 1.10.
+
+ -- Gilles Filippini   Fri, 22 Jul 2016 14:05:02 +0200
+
 libgpiv (0.6.1-4.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libgpiv-0.6.1/debian/patches/series libgpiv-0.6.1/debian/patches/series
--- libgpiv-0.6.1/debian/patches/series
+++ libgpiv-0.6.1/debian/patches/series
@@ -3,0 +4 @@
+04-avoid-bool-keyword.diff
only in patch2:
unchanged:
--- libgpiv-0.6.1.orig/debian/patches/04-avoid-bool-keyword.diff
+++ libgpiv-0.6.1/debian/patches/04-avoid-bool-keyword.diff
@@ -0,0 +1,16 @@
+Description: the 'bool' keyword defines a type with HDF5 1.10
+ An by the way, this variable is unused.
+Author: Gilles Filippini 
+Index: libgpiv-0.6.1/lib/io.c
+===
+--- libgpiv-0.6.1.orig/lib/io.c
 libgpiv-0.6.1/lib/io.c
+@@ -1569,8 +1569,6 @@ read_pivdata_from_stdin (gboolean fastx
+ gfloat dat_x = -10.0e5, dat_y = -10.0e5;
+ gint line_nr = 0; 
+ 
+-gboolean bool = FALSE;
+-
+ 
+ /* 
+  * Count nx, ny, similar to count_asciidata

Bug#841954: HDF5 1.10

[Sebastian Wouters]

Hi Gilles,

I've added your changes to the git repo:
https://anonscm.debian.org/cgit/debichem/packages/chemps2.git

I'm fine with NMU.

Best wishes,
Seb

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ron]

On Mon, Oct 24, 2016 at 12:48:10PM -0500, Don Armstrong wrote:
> On Sun, 23 Oct 2016, Tollef Fog Heen wrote:
> > Maybe the question we should ask is less «who/how many people use
> > htags?» and more «what value does htags provide?». I'm no big fan of
> > arbitrarily breaking people's workflows, which we might be the result
> > if we remove htags.
> 
> It sure looks like upstream has removed the CGI generation option from
> ctags itself, and no longer supports the --system-cgi option. Htags
> appear to now just be generated statically, with the possibility of a
> generated CGI as well [which seems to just set appropriate paths.]
> 
> It's quite possible that I've totally missed something (the upstream
> manual is a bit impenetrable), but maybe this will obviate the need to
> answer this question?

Only half-missed :)  That removes any trace of the ability to generate
a _static_ CGI that can be audited and installed to a system path.
Which basically takes us back to the original situation from the 90's
again, where the CGI is generated dynamically for each source repo,
and is expected to be allowed to execute from the same tree as the
static html content.

It is possible to generate html that doesn't use a CGI at all, but
that completely removes the ability to search the gtags database
(which is what the CGI is needed to do) - which makes htags fairly
useless, since the whole point of global is the tag search function,
and you really would be far better off using something like doxygen
instead which provides client side search functionality.


The evolution was basically:

 - 1999 I added the ability to generate static CGI and use it securely.
   It was then suitable for use as a distro package, and uploaded to
   Debian.

   Upstream was sensitive about accepting major contributions that
   might mean he couldn't relicence it without permission from other
   authors, so he wanted the major parts of that kept separate, and
   we added only the hooks needed to support it to the main body of
   his code.  (at some point after that he did change the licence
   from BSD to GPL).

 - 2010 Upstream proposed replacing that with a mechanism that was
   part of the 'upstream' code, and approached me privately to
   review his proposed changes.  This was the "run a generated script
   as root and/or chmod 777 the privileged directory" option.

   He then wasn't interested in anything but a rubberstamp acceptance
   of that, and I couldn't convince him why that would be Troublesome.
   At that point he also deliberately removed the old interfaces that
   were necessary to support what we had, and the stalemate began.

 - At some point more recently, he broke that mechanism too, then
   dropped it completely (which is the change you were looking at).

   So now we're back to the pre-1999 option of only having it generated
   dynamically, hardcoded to be in the same tree as the static html.
   Which was already a fairly strongly condemned practice in the 90's.


So basically, you've now got a choice of "Something worse than doxygen
with no search functionality", or something that's a PITA to make work
at best (you need to let your web server execute CGIs from arbitrary
paths), and a security hole waiting for people to walk through at worst,
and potentially still worse than what you'd get from doxygen anyway.

I haven't audited the most recent code in detail yet, but the older
code and docs used to be full of warnings along the lines of "if you
put this on the public internet, you lose.  Don't do that.".

Which doesn't seem like something we really want in a distro package.


That's basically why "just nuke htags now" is starting to look like
a viable, and even sensible, option.  But it's tricky to know who
might be upset by that - and we don't have a clear idea of exactly
what we'd really gain elsewhere from that tradeoff, since most of
the people saying "I need a new upstream" haven't actually been
telling us what the real problem is which that fixes, even when I
asked.

It's quite possible that some of those would just need a trivial
patch to what we currently have - but with these latest changes to
htags, I am feeling more and more like the writing is on the wall
for its ultimate demise now - even if upstream isn't accepting
that yet.


But I haven't forgotten the hatemail I got for finally killing off
svgatextmode, a whole decade after its upstream declared it an
obsolete solution, when kms finally made it impossible to keep it
working - so I don't underestimate what some people might cling to.


  Cheers,
  Ron

Bug#838242: transition: imagemagick

[roucaries bastien]

On Fri, Oct 21, 2016 at 10:46 AM, Emilio Pozuelo Monfort
 wrote:
> On 13/10/16 09:45, Emilio Pozuelo Monfort wrote:
>> On 12/10/16 17:13, roucaries bastien wrote:
>>> Uploaded new version waiting for green light
>>
>> Go ahead.
>
> Can you look at pythonmagick? That is the last blocker.

I think we should drop pythonmagick:
1. it is an upstream bug
https://github.com/ImageMagick/PythonMagick/issues/5. I will fix ASAP
when a new upstream is ready
2. They are three new security bugs with CVE in imagemagick.

Bastien


> Cheers,
> Emilio

Bug#841846: meson: breaks DT_MIPS_RLD_MAP_REL elf entry when removing RPATH entry

[Jussi Pakkanen]

> The strategy adopted by meson is the same than the one adopted by
> chrpath, and chrpath also adjusts the value of DT_MIPS_RLD_MAP_REL.
> I don't know if there is another way to do that, at least I don't
> think there is another obvious way to do it.

Ok, thanks. Committed to master and will be in the next release which
will be in a week or two.

Bug#841607: mydumper: FTBFS: dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/

[Mateusz Kijowski]

Hi,


The relevant part seems to be:

CMake Error: The following variables are used in this project, but
they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
MYSQL_LIBRARIES_atomic
linked by target "mydumper" in directory /<>
linked by target "myloader" in directory /<>

-- Configuring incomplete, errors occurred!

It turns out that mysql_config returns as a necessary lib on amd64 in
sid. libatomic1 package is properly installed as a dependancy, but it
installs atomic.so.1 library symlink which isn't detected by cmake. I
am not sure if this is the desired behaviour, but I would assume so,
since atomic.so (which seems to be required for cmake detection to
work) is part of libgcc-{5,6}-dev packages. So possible solutions are:

a) patch cmake/modules/FindMySQL.cmake to find atomic.so.1
b) add proper libgcc-{5,6}-dev package dependancy

I am not quite sure how to determine which libgcc-dev version I should
use, also I think that this dependancy is not required on i386 (and
possibly other architectures as well). Will update this bug after I
find some more info.

Bug#841851: Bug#841852: Bug#841851: ITP: bind-key -- simple way to manage personal keybindings

[Sean Whitton]

Hello Lev,

On Mon, Oct 24, 2016 at 10:38:50PM +0500, Lev Lamberov wrote:
> 24.10.2016 22:27, Sean Whitton пишет:
> > Dear Lev,
> >
> > On Mon, Oct 24, 2016 at 09:55:50AM +0500, Lev Lamberov wrote:
> >> (3) users will rather see their elpa-{bind-key,use-package}
> >> counterparts
> > I don't understand this reasoning.
> 
> I don't get what you don't understand.

There is team convention for source package names, and there is a team
policy for binary package names.  These are completely disconnected: the
team convention for source package names makes no reference to the
binary package name.  So there is no room to argue that the choice of
binary package name should influence the choice of source package name,
except by arguing that the team convention for source package names is
wrong.

Anyway, this is bikeshedding.  There is no need to do another upload.

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#841957: libgs9-common: URW fonts: Missing glyphs for uk language

[v_2e]

Package: libgs9-common 
Version: 9.06~dfsg-2+deb8u3 
Severity: normal 

Dear Maintainer, 

In ghostscript-9.06 present in Jessie repository there are no Ukrainian and 
Russian glyphs in a number of fonts. Namely, in all the URW family. 

These fonts are invisible in LibreOffice, for example. 

I checked it using the following command: 

$ fc-validate -l uk /usr/share/ghostscript/9.06/Resource/Font/URWBookmanL-Ligh 
/usr/share/ghostscript/9.06/Resource/Font/URWBookmanL-Ligh:0 Missing 72 
glyph(s) to satisfy the coverage for uk language 

$ fc-validate -l ru /usr/share/ghostscript/9.06/Resource/Font/URWBookmanL-Ligh 
/usr/share/ghostscript/9.06/Resource/Font/URWBookmanL-Ligh:0 Missing 66 
glyph(s) to satisfy the coverage for ru language 

I reported this bug upstream: 
http://bugs.ghostscript.com/show_bug.cgi?id=697224 

however, they answered that everything is allright in the newer Ghostscript 
version, and the only way to get this working is to upgrade to the lates 
version. 




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

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

libgs9-common depends on no packages. 

Versions of packages libgs9-common recommends: 
ii  fonts-droid  1:4.4.4r2-6 

libgs9-common suggests no packages. 

-- no debconf information 

Bug#841952: linux-image-4.7.0-1-amd64: lots of kernel messages about missed HPET interrupts

[Simon Richter]

Package: src:linux
Version: 4.7.8-1
Severity: normal

Hi,

I've just updated my kernel, and get a lot of kernel messages about lost
HPET RTC interrupts. The 3.16.0 kernel from stable didn't do this. I have
no idea where to start debugging this, so if you need more info, please
ask.

   Simon

-- Package-specific info:
** Version:
Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.7.8-1 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.7.0-1-amd64 root=/dev/mapper/kiwi-root ro irqpoll

** Not tainted

** Kernel log:
[ 2729.525397] hpet1: lost 602 rtc interrupts
[ 2734.533457] hpet1: lost 319 rtc interrupts
[ 2739.541261] hpet1: lost 319 rtc interrupts
[ 2749.557622] hpet1: lost 563 rtc interrupts
[ 2759.573769] hpet1: lost 640 rtc interrupts
[ 2761.845245] hpet1: lost 118 rtc interrupts
[ 2764.581257] hpet1: lost 174 rtc interrupts
[ 2769.589498] hpet1: lost 320 rtc interrupts
[ 2779.605879] hpet1: lost 630 rtc interrupts
[ 2784.629697] hpet1: lost 190 rtc interrupts
[ 2789.637689] hpet1: lost 317 rtc interrupts
[ 2794.645637] hpet1: lost 310 rtc interrupts
[ 2799.654012] hpet1: lost 320 rtc interrupts
[ 2809.670101] hpet1: lost 607 rtc interrupts
[ 2819.686237] hpet1: lost 634 rtc interrupts
[ 2824.709879] hpet1: lost 237 rtc interrupts
[ 2829.718054] hpet1: lost 319 rtc interrupts
[ 2834.838009] hpet1: lost 325 rtc interrupts
[ 2839.734211] hpet1: lost 313 rtc interrupts
[ 2849.750459] hpet1: lost 597 rtc interrupts
[ 2851.846181] hpet1: lost 132 rtc interrupts
[ 2854.758172] hpet1: lost 185 rtc interrupts
[ 2859.766298] hpet1: lost 319 rtc interrupts
[ 2869.798516] hpet1: lost 499 rtc interrupts
[ 2871.846545] hpet1: lost 114 rtc interrupts
[ 2879.814628] hpet1: lost 509 rtc interrupts
[ 2884.822603] hpet1: lost 298 rtc interrupts
[ 2889.830592] hpet1: lost 318 rtc interrupts
[ 2899.846917] hpet1: lost 634 rtc interrupts
[ 2909.878898] hpet1: lost 569 rtc interrupts
[ 2914.886897] hpet1: lost 309 rtc interrupts
[ 2919.894848] hpet1: lost 319 rtc interrupts
[ 2924.903031] hpet1: lost 273 rtc interrupts
[ 2929.911131] hpet1: lost 319 rtc interrupts
[ 2939.927257] hpet1: lost 634 rtc interrupts
[ 2944.950899] hpet1: lost 208 rtc interrupts
[ 2946.708957] hpet1: lost 111 rtc interrupts
[ 2949.959012] hpet1: lost 207 rtc interrupts
[ 2959.975436] hpet1: lost 635 rtc interrupts
[ 2969.991536] hpet1: lost 632 rtc interrupts
[ 2974.999201] hpet1: lost 319 rtc interrupts
[ 2980.007296] hpet1: lost 319 rtc interrupts
[ 2985.031361] hpet1: lost 128 rtc interrupts
[ 2990.039377] hpet1: lost 318 rtc interrupts
[ 3000.056177] hpet1: lost 630 rtc interrupts
[ 3005.063652] hpet1: lost 283 rtc interrupts
[ 3006.725942] hpet1: lost 105 rtc interrupts
[ 3010.071762] hpet1: lost 214 rtc interrupts
[ 3015.079778] hpet1: lost 313 rtc interrupts
[ 3020.088076] hpet1: lost 319 rtc interrupts
[ 3030.120080] hpet1: lost 569 rtc interrupts
[ 3035.127716] hpet1: lost 318 rtc interrupts
[ 3040.135837] hpet1: lost 320 rtc interrupts
[ 3050.152182] hpet1: lost 620 rtc interrupts
[ 3060.168326] hpet1: lost 639 rtc interrupts
[ 3065.192219] hpet1: lost 196 rtc interrupts
[ 3070.200096] hpet1: lost 320 rtc interrupts
[ 3080.216747] hpet1: lost 628 rtc interrupts
[ 3085.224435] hpet1: lost 283 rtc interrupts
[ 3090.232533] hpet1: lost 319 rtc interrupts
[ 3092.041857] hpet1: lost 113 rtc interrupts
[ 3092.378356] hpet1: lost 20 rtc interrupts
[ 3092.668790] hpet1: lost 18 rtc interrupts
[ 3093.158994] hpet1: lost 30 rtc interrupts
[ 3093.252189] hpet1: lost 5 rtc interrupts
[ 3093.285850] hpet1: lost 1 rtc interrupts
[ 3093.362174] hpet1: lost 4 rtc interrupts
[ 3093.415513] hpet1: lost 2 rtc interrupts
[ 3093.485238] hpet1: lost 3 rtc interrupts
[ 3095.240174] hpet_rtc_timer_reinit: 5 callbacks suppressed
[ 3095.240208] hpet1: lost 75 rtc interrupts
[ 3100.248385] hpet1: lost 320 rtc interrupts
[ 3109.960439] hpet1: lost 568 rtc interrupts
[ 3110.060462] hpet1: lost 6 rtc interrupts
[ 3110.361112] hpet1: lost 4 rtc interrupts
[ 3119.608845] hpet1: lost 582 rtc interrupts
[ 3119.864198] hpet1: lost 14 rtc interrupts
[ 3120.296293] hpet1: lost 27 rtc interrupts
[ 3121.775019] hpet1: lost 52 rtc interrupts
[ 3121.942494] hpet1: lost 5 rtc interrupts
[ 3121.986995] hpet1: lost 1 rtc interrupts
[ 3125.313599] hpet1: lost 210 rtc interrupts
[ 3125.358011] hpet1: lost 2 rtc interrupts
[ 3125.563234] hpet1: lost 12 rtc interrupts
[ 3125.744238] hpet1: lost 11 rtc interrupts
[ 3125.806750] hpet1: lost 3 rtc interrupts
[ 3126.088284] hpet1: lost 17 rtc interrupts
[ 3126.131092] hpet1: lost 1 rtc interrupts
[ 3126.657393] hpet1: lost 33 rtc interrupts
[ 3126.789981] hpet1: lost 7 rtc interrupts
[ 3126.859837] hpet1: lost 3 rtc interrupts
[ 3132.856419] hpet_rtc_timer_reinit: 7 callbacks suppressed
[ 3132.856451] hpet1: lost 158 rtc interrupts
[ 3140.328935] hpet1: lost 477 rtc interrupts
[ 3142.840472] hpet1: lost 33 rtc interrupts
[ 3150.361254] hpet1: lost 480 rtc 

Bug#841953: libvirt0: virt-install generates "No bootable device" error when using --location option

[Bruno Ramos]

Package: libvirt0
Version: 2.3.0-3
Severity: normal

Dear Maintainer,

detected after the upgrade to version 2.3 on sid that the virt-install command
generates "No bootable device" error when using --location option.

The exact same command is working ok in jessie completely up to date
system as of 2016-10-24).

Command (ok in jessie, failing in sid):

virt-install -v --connect qemu:///system \
--os-type linux --os-variant debianwheezy \
--name foo --disk size=4 --ram 512 \
--location http://ftp.be.debian.org/debian/dists/stable/main/installer-amd64

Installation works ok if I download the installer iso for example with this
command:

Command (ok in jessie, ok in sid):

virt-install -v --connect qemu:///system \
--os-type linux --os-variant debianwheezy \
--name foo --disk size=4 --ram 512 \
--cdrom /tmp/debian-8.6.0-amd64-netinst.iso


Best regards,

Bruno Ramos



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 libvirt0 depends on:
ii  libapparmor12.10.95-5
ii  libaudit1   1:2.6.7-1
ii  libavahi-client30.6.32-1
ii  libavahi-common30.6.32-1
ii  libc6   2.24-5
ii  libcap-ng0  0.7.7-3
ii  libdbus-1-3 1.10.12-1
ii  libdevmapper1.02.1  2:1.02.133-1
ii  libgnutls30 3.5.5-2
ii  libnl-3-200 3.2.27-1
ii  libnl-route-3-200   3.2.27-1
ii  libnuma12.0.11-1
ii  libsasl2-2  2.1.26.dfsg1-15
ii  libselinux1 2.5-3
ii  libssh2-1   1.7.0-1
ii  libxen-4.6  4.6.0-1+nmu2
ii  libxml2 2.9.4+dfsg1-2
ii  libyajl22.1.0-2

Versions of packages libvirt0 recommends:
ii  lvm2  2.02.164-1

libvirt0 suggests no packages.

-- no debconf information

Bug#840428: Forwarded

[Bastien ROUCARIÈS]

control: forwarded -1 https://github.com/ImageMagick/PythonMagick/issues/5



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

Bug#841954: chemps2: Please support building against HDF5 1.10

[Gilles Filippini]

Source: chemps2
Version: 1.8-2
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. I intend to request a transition slot this week, and will NMU if 
need be.

Thanks,

_g.


- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmITAAoJEO/obGx//s+De0EH/0haD0E68suaSv0Bev5dAO78
US89qsk0xsAU1eNY/9gaU92AUyXAqZikBOeEMdSsY0bCOdM+e19fZzEcyH6S3ysT
ZhAAQC1JbmrqjJKAsS6lxyovGTqxGz1AgY8kzaUvor1UMdi02UQY47qNp/VB63OY
kIUWOypwyuxbWZZwrHdrWWCdp/lN3ZqUXMlj8RBSWbn+05thdCBIdn8sq1sxmWN3
0qG5AmN2BOTVPOXY2q7Zg1kaDzdezTK0FnCP8SDqWuhtdIQ6kkfnzkFTu4ZOBuAH
LPo9UWVTXW5jU9bS4FKJQ9vvwVYc70eH/MnBSx1keVfbL7BVwWZ1cfGjDmXBPW8=
=1UeU
-END PGP SIGNATURE-
diff -Nru chemps2-1.8/debian/changelog chemps2-1.8/debian/changelog
--- chemps2-1.8/debian/changelog	2016-09-09 15:49:00.0 +0200
+++ chemps2-1.8/debian/changelog	2016-10-18 23:48:20.0 +0200
@@ -1,3 +1,10 @@
+chemps2 (1.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Update symbols file to support HDF5 1.10
+
+ -- Gilles Filippini   Tue, 18 Oct 2016 23:46:53 +0200
+
 chemps2 (1.8-2) unstable; urgency=medium
 
* Fix overwriting chemps2.1.gz libchemps2-1 (Closes: #808312)
diff -Nru chemps2-1.8/debian/libchemps2-2.symbols chemps2-1.8/debian/libchemps2-2.symbols
--- chemps2-1.8/debian/libchemps2-2.symbols	2016-08-24 11:15:00.0 +0200
+++ chemps2-1.8/debian/libchemps2-2.symbols	2016-10-19 00:36:24.0 +0200
@@ -142,8 +142,10 @@
  _ZN7CheMPS216DMRGSCFintegralsD0Ev@Base 1.7
  _ZN7CheMPS216DMRGSCFintegralsD1Ev@Base 1.7
  _ZN7CheMPS216DMRGSCFintegralsD2Ev@Base 1.7
- _ZN7CheMPS216DMRGSCFrotations10close_fileEiii@Base 1.7
- _ZN7CheMPS216DMRGSCFrotations10write_fileEiiPdiii@Base 1.7
+ (optional)ZN7CheMPS216DMRGSCFrotations10close_fileEiii@Base 1.7
+ (optional)_ZN7CheMPS216DMRGSCFrotations10close_fileElll@Base 1.8
+ (optional)_ZN7CheMPS216DMRGSCFrotations10write_fileEiiPdiii@Base 1.7
+ (optional)_ZN7CheMPS216DMRGSCFrotations10write_fileEllPdiii@Base 1.8
  _ZN7CheMPS216DMRGSCFrotations13package_firstEPdS1_iii@Base 1.7
  _ZN7CheMPS216DMRGSCFrotations15blockwise_firstEPdS1_iiiS1_ii@Base 1.7
  _ZN7CheMPS216DMRGSCFrotations15blockwise_thirdEPdS1_iiiS1_ii@Base 1.7
@@ -155,8 +157,10 @@
  _ZN7CheMPS216DMRGSCFrotations5writeEPdPNS_9FourIndexEPNS_16DMRGSCFintegralsEPNS_14DMRGSCFindicesEiib@Base 1.7
  _ZN7CheMPS216DMRGSCFrotations6rotateEPKNS_9FourIndexEPS1_PNS_16DMRGSCFintegralsEPNS_14DMRGSCFindicesEPNS_14DMRGSCFunitaryEPdSB_iNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
  _ZN7CheMPS216DMRGSCFrotations9dimensionEPNS_14DMRGSCFindicesEic@Base 1.7
- _ZN7CheMPS216DMRGSCFrotations9open_fileEPiS1_S1_iiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
- _ZN7CheMPS216DMRGSCFrotations9read_fileEiiPdiii@Base 1.7
+ (optional)_ZN7CheMPS216DMRGSCFrotations9open_fileEPiS1_S1_iiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
+ (optional)_ZN7CheMPS216DMRGSCFrotations9open_fileEPlS1_S1_iiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.8
+ (optional)_ZN7CheMPS216DMRGSCFrotations9read_fileEiiPdiii@Base 1.7
+ (optional)_ZN7CheMPS216DMRGSCFrotations9read_fileEllPdiii@Base 1.8
  _ZN7CheMPS217ConjugateGradient12apply_preconEPd@Base 1.7
  _ZN7CheMPS217ConjugateGradient12apply_preconEPdS1_@Base 1.7
  _ZN7CheMPS217ConjugateGradient4stepEPPd@Base 1.7
@@ -235,8 +239,10 @@
  _ZN7CheMPS24DMRG16symm_4rdm_helperEPdiiddbd@Base 1.7
  _ZN7CheMPS24DMRG16updateMovingLeftEi@Base 1.7
  _ZN7CheMPS24DMRG17updateMovingRightEi@Base 1.7
- _ZN7CheMPS24DMRG18MY_HDF5_READ_BATCHEiiPPNS_6TensorExNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
- _ZN7CheMPS24DMRG19MY_HDF5_WRITE_BATCHEiiPPNS_6TensorExNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
+ (optional)_ZN7CheMPS24DMRG18MY_HDF5_READ_BATCHEiiPPNS_6TensorExNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
+ (optional)_ZN7CheMPS24DMRG18MY_HDF5_READ_BATCHEliPPNS_6TensorExNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.8
+ (optional)_ZN7CheMPS24DMRG19MY_HDF5_WRITE_BATCHEiiPPNS_6TensorExNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.7
+ (optional)_ZN7CheMPS24DMRG19MY_HDF5_WRITE_BATCHEliPPNS_6TensorExNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.8
  _ZN7CheMPS24DMRG19activateExcitationsEi@Base 1.7
  _ZN7CheMPS24DMRG19prepare_excitationsEPNS_7SobjectE@Base 1.7
  _ZN7CheMPS24DMRG20updateMovingLeftSafeEi@Base 1.7

Bug#841955: qemu: CVE-2016-8910: net: rtl8139: infinite loop while transmit in C+ mode

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.7+dfsg-1
Severity: normal
Tags: security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2016-8910[0]:
net: rtl8139: infinite loop while transmit in C+ mode

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-8910
[1] https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg05495.html

Please adjust the affected versions in the BTS as needed. Only
unstable source has been checked so far.

Regards,
Salvatore

Bug#841065: RFS: gnome-shell-extensions-dashtodock/55-1, ITP: 829185 -- dash-to-dock extension for GNOME shell

[Tobias Frost]

Am Montag, den 24.10.2016, 11:31 +0200 schrieb Jonathan Carter
(highvoltage):
> On 22/10/2016 16:28, Tobias Frost wrote:
> > - translators copyright should be also recorded in d/copyright.
> 
> I added the translations with copyright assertions in d/copyright:
> 
> https://gitlab.com/highvoltage/gnome-shell-extension-dashtodock-packa
> ging/commit/e446de895987a1a271c9e3fe7232ed853fc772ea
> 
> It looks right to me but it seems like it parses differently than I
> understand:
> 
> I: gnome-shell-extension-dashtodock source:
> wildcard-matches-nothing-in-dep5-copyright po/BR.po (paragraph at
> line 31)
> N:
> N:The wildcard that was specified matches no file in the source
> tree. This
> N:either indicates that you should fix the wildcard so that it
> matches the
> N:intended file or that you can remove the wildcard. Notice that
> in
> N:contrast to shell globs, the "*" (star or asterisk) matches
> slashes and
> N:leading dots.
> N:
> N:Refer to
> N:https://www.debian.org/doc/packaging-manuals/copyright-format/1
> .0/ for
> N:details.
> N:
> N:Severity: minor, Certainty: possible
> N:
> N:Check: source-copyright, Type: source
> N:
> I: gnome-shell-extension-dashtodock source:
> unused-file-paragraph-in-dep5-copyright paragraph at line 31
> N:
> N:The Files paragraph in debian/copyright is superfluous as it is
> never
> N:used to match any files. You should be able to safely remove
> it.
> N:
> N:Refer to
> N:https://www.debian.org/doc/packaging-manuals/copyright-format/1
> .0/ for
> N:details.
> N:
> N:Severity: minor, Certainty: possible
> N:
> N:Check: source-copyright, Type: source
> 
> Could you perhaps give me a pointer theregnome-shell-extension-
> dashtodock?

There is no po/BR directory in the source. ;)


> thanks!
> -Jonathan

Bug#841956: nmu: boost1.61_1.61.0+dfsg-3

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please rebuild boost1.61 against the pie-enabled compiler chain, to fix this 
FTBFS of psi4 package:

[100%] Linking CXX executable ../../../bin/psi4
cd /<>/builddir/src/bin/psi4 && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/psi4.dir/link.txt --verbose=1
/usr/bin/c++   -DRESTRICT=__restrict__ -Xlinker -export-dynamic -fPIC 
-std=c++11 -fopenmp -O2 -g -DNDEBUG   
CMakeFiles/psi4_objlib.dir/export_psio.cc.o 
CMakeFiles/psi4_objlib.dir/export_mints.cc.o 
CMakeFiles/psi4_objlib.dir/psi_stop.cc.o 
CMakeFiles/psi4_objlib.dir/export_functional.cc.o 
CMakeFiles/psi4_objlib.dir/export_oeprop.cc.o 
CMakeFiles/psi4_objlib.dir/export_plugins.cc.o 
CMakeFiles/psi4_objlib.dir/export_blas_lapack.cc.o 
CMakeFiles/psi4_objlib.dir/export_benchmarks.cc.o 
CMakeFiles/psi4_objlib.dir/export_efp.cc.o 
CMakeFiles/psi4_objlib.dir/export_cubeprop.cc.o 
CMakeFiles/psi4_objlib.dir/clean.cc.o 
CMakeFiles/psi4_objlib.dir/create_new_plugin.cc.o 
CMakeFiles/psi4_objlib.dir/script.cc.o 
CMakeFiles/psi4_objlib.dir/set_memory.cc.o 
CMakeFiles/psi4_objlib.dir/read_options.cc.o 
CMakeFiles/psi4_objlib.dir/export_libparallel.cc.o 
CMakeFiles/versioned_code.dir/version.cc.o 
CMakeFiles/versioned_code.dir/python.cc.o 
CMakeFiles/versioned_code.dir/psi_start.cc.o CMakeFiles/versioned_code.dir
 /psi4.cc.o  -o ../../../bin/psi4 -rdynamic -lutil -lm -lrt -ldl -lpython2.7 
-Wl,--whole-archive ../../../lib/libadc.a ../../../lib/libccdensity.a 
../../../lib/libccenergy.a ../../../lib/libcceom.a ../../../lib/libcchbar.a 
../../../lib/libcclambda.a ../../../lib/libccresponse.a 
../../../lib/libccsort.a ../../../lib/libcctransort.a 
../../../lib/libcctriples.a ../../../lib/libdcft.a ../../../lib/libdetci.a 
../../../lib/libdfmp2.a ../../../lib/libdfocc.a ../../../lib/libefp.a 
../../../lib/libfindif.a ../../../lib/libfisapt.a ../../../lib/libfnocc.a 
../../../lib/libmcscf.a ../../../lib/libmints_wrapper.a ../../../lib/libmrcc.a 
../../../lib/libocc.a ../../../lib/liboptking.a ../../../lib/libpsimrcc.a 
../../../lib/libsapt.a ../../../lib/libscf.a ../../../lib/libscfgrad.a 
../../../lib/libthermo.a ../../../lib/libtransqt2.a ../../../lib/libdmrg.a 
../../../lib/lib3index.a ../../../lib/libciomr.a ../../../lib/libdiis.a 
../../../lib/libdisp.a ../../../lib/libdpd.a ../../../lib/libefp_solver.a .
 ./../../lib/libfock.a ../../../lib/libfunctional.a -Wl,--whole-archive 
../../../lib/libiwl.a -Wl,--no-whole-archive ../../../lib/libmints.a 
../../../lib/libmoinfo.a ../../../lib/liboptions.a ../../../lib/libparallel.a 
../../../lib/libparallel2.a ../../../lib/libplugin.a 
../../../lib/libsapt_solver.a ../../../lib/libscf_solver.a 
../../../lib/libthce.a ../../../lib/libtrans.a ../../../lib/libpsi4util.a 
../../../lib/libpsio.a ../../../lib/libPsiUtil.a ../../../lib/libqt.a 
../../../lib/libcubeprop.a ../../../lib/libinterface_libefp.a 
-Wl,--no-whole-archive -Wl,-Bstatic -lboost_filesystem -lboost_python 
-lboost_regex -lboost_serialization -lboost_system -lboost_timer -lboost_chrono 
-lboost_thread -lboost_date_time -lboost_atomic -Wl,-Bdynamic -lpthread 
-llapack -lblas -lpython2.7 -lblas -llapack -lint -lderiv -lutil -ldl -lrt -lm 
/usr/lib/x86_64-linux-gnu/libchemps2.so -lchemps2 
/usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5.so -lsz -lz -lpthread -lm 
-lpython2.7 -ldl -Wl,-rpath,/usr/l
 ib/x86_64-linux-gnu/hdf5/serial/lib 
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(operations.o):
 relocation R_X86_64_32S against symbol 
`_ZN5boost6detail15sp_counted_base7destroyEv' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(path.o):
 relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(list.o):
 relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(dict.o):
 relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
...

nmu boost1.61_1.61.0+dfsg-3 . ANY . unstable . -m "Rebuild with the pie-enabled 
compiler chain"

Thanks in advance,

_g.
- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmTGAAoJEO/obGx//s+D7rMIAKhXQ/RkLEhaVqksNirXeoKt

Bug#841885: gerris: autopkgtests fail with openmpi2

[Anton Gladky]

tags 841885 +pending +patch
thanks

Hi Graham,

thanks for your fix. I have committed it and it will be fixed by the next
upload. Regarding your question of including those packages into
Depends section of gerris. As far as I know, it is possible to use
gerris without compiler and in a serial mode, so in this case those
packages are not really needed.

I may be wrong, CC-ing upstream author for a more qualified answer.

Thanks

Anton


2016-10-24 9:02 GMT+02:00 Graham Inggs :
> Source: gerris
> Version: 20131206+dfsg-9
>
> Hi Maintainer
>
> Since the transition to openmpi2, gerris' autopkgtests have been
> failing with the following error:
>
> orte_ess_init failed
> --> Returned value A system-required executable either could not be
> found or was not executable by this user (-126) instead of
> ORTE_SUCCESS
>
> I solved this by adding mpi-default-bin to debian/tests/control as follows:
>
> --- a/debian/tests/control
> +++ b/debian/tests/control
> @@ -1,2 +1,2 @@
>  Tests: testHydro testKinetic testPlate testQuadr
> -Depends: gerris, libgfs-dev, build-essential, pkg-config, mpi-default-dev
> +Depends: gerris, libgfs-dev, build-essential, pkg-config,
> mpi-default-dev, mpi-default-bin
>
> However, if the dependencies libgfs-dev, build-essential, pkg-config,
> mpi-default-dev and mpi-default-bin are actually needed for normal
> usage of gerris, then maybe they should rather be added to the gerris
> package's Depends in debian/control.
>
> Regards
> Graham
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#799226: linux-image-4.1.0-2-amd64: Not able to mount LVM RAID1 file system at boot

[Simon Richter]

Source: linux
Version: 3.16.36-1+deb8u2
Followup-For: Bug #799226

Hi,

this bug is also in the stable kernel, and the one currently in testing.

It is caused by the kernel not writing the bitmap information to the meta
LV.

I can reproduce this here with an Areca RAID controller, but not with loop
devices, so it might be related to the SCSI subsystem.

IMO, this is an indication of a fairly serious problem.

   Simon

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#841958: RFP: teamviewer -- free for non-comertial use, remote support, remote acces, meeting online. Most popular on the web remote acces programm

[Szymon Scholz]

Package: wnpp
Severity: wishlist

  Package name: teamviewer
  Version : 11.0.67687
  Upstream Author : Szymon Scholz 
  URL : www.teamviewer.com
  License : custom - 
https://www.teamviewer.com/pl/help/cat18-Licensing.aspx
  Programming Lang: unknown, C must there be, but i do not know
  Description : free for non-comertial use, remote support, remote acces, 
meeting online. Most popular on the web remote acces programm

Long Desc:

TeamViewer is a proprietary computer software package for remote 
control, desktop sharing, online meetings, web conferencing and file transfer 
between computers

easy to use and working on verry old software, its generally desktop 
sharing programm with remote control

its free for personal or non-commercial use, for commercial use you 
need to pay them.

Supported OS: Windows, macOS, Linux, Chrome OS, Android, iOS, Windows 
Phone, Windows Mobile, BlackBerry, Raspberry Pi

The last reason it's cos people (newbies, not an linux fans, but an guy 
who need PC for watch TV / banking / play games) usually use windows (i too 
hate it)
also teamviewer is well oriented app in look and feel

About me:
I am not a maintainer, im not planning to maintain this 
program. But i am interesting in maintaining
 in future, learn some skills, also learn programming as well. 
If you have an easier job what i can do, i will do it

Bug#841886: Please upgrade babeltrace to the 1.5 series for Stretch

[Sebastian Andrzej Siewior]

On 2016-10-24 14:35:46 [-0400], Michael Jeanson wrote:
> After discussing it with Jérémie the rc1 was officially released, I've
> just pushed it to Debian, should be available in unstable tomorrow.

So I tried to build the perf ctf I noticed that I need

diff --git a/debian/libbabeltrace-ctf-dev.install 
b/debian/libbabeltrace-ctf-dev.install
--- a/debian/libbabeltrace-ctf-dev.install
+++ b/debian/libbabeltrace-ctf-dev.install
@@ -1,4 +1,5 @@
 usr/include/babeltrace/ctf/*
+usr/include/babeltrace/ctf-ir/*
 usr/lib/*/libbabeltrace-ctf.a
 usr/lib/*/libbabeltrace-ctf.so
 usr/lib/*/libbabeltrace-ctf-text.a

to get it compiled & linked. The resulting binary was able to covert a
stream so it looks good.

> Cheers,
> 
> Michael
> 
> On 2016-10-24 11:06, Michael Jeanson wrote:
> > Hi,
> > 
> > I'm not too keen on packaging something that is not even in RC yet, I've
> > taken a look at the state of this branch and it currently only adds
> > symbols to libabeltrace1 which by my understanding would not require a
> > transition. So I guess we don't have to worry about the November fifth
> > freeze.

Yes, it adds symbols but I haven't checked if some structs are modified.
If some of them are changed and publicly exposed then we would have to
have transistion.

Sebastian

Bug#839230: same issue found in testing

[Sharuzzaman Ahmat Raslan]

found 839230 1.8.10-2

error message:

sharuzzaman@debian:~$ poedit
03:48:18: Warning: Mismatch between the program and library build versions
detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
containers,compatible with 2.8).
Debug: Failed to connect to session manager: SESSION_MANAGER environment
variable not defined
Segmentation fault

Window manager: LXDE


-- 
Sharuzzaman Ahmat Raslan

Bug#841947: [pkg-boost-devel] Bug#841947: libboost-*1.61-dev: Please build static libs with -fPIC

[Gilles Filippini]

Control: block -1 by 841956

Steve M. Robbins a écrit le 24/10/2016 à 20:28 :
> My understanding is that you have to first build boost with the
> pie-enabled compiler chain, then build your package with the new
> boost.
> 
> c.f. https://wiki.ubuntu.com/SecurityTeam/PIE
> 
> 
> Note that using -fPIC on static libs is against current Debian Policy.

You're right. I've just tested building psi4 against a fresh build of
boost1.61, and it works. I've submitted a binnmu request accordingly.

Thanks,

_g.

> 
> On Mon, Oct 24, 2016 at 08:19:13PM +0200, Gilles Filippini wrote:
>> Source: boost1.61
>> Version: 1.61.0+dfsg-3
>> Severity: serious
>> Justification: make other packages FTBFS
>>
> Hi,
> 
> When rebuilding the psi4 package on amd6', it FTBFS with:
> 
> [100%] Linking CXX executable ../../../bin/psi4
> cd /<>/builddir/src/bin/psi4 && /usr/bin/cmake -E 
> cmake_link_script CMakeFiles/psi4.dir/link.txt --verbose=1
> /usr/bin/c++   -DRESTRICT=__restrict__ -Xlinker -export-dynamic -fPIC 
> -std=c++11 -fopenmp -O2 -g -DNDEBUG   
> CMakeFiles/psi4_objlib.dir/export_psio.cc.o 
> CMakeFiles/psi4_objlib.dir/export_mints.cc.o 
> CMakeFiles/psi4_objlib.dir/psi_stop.cc.o 
> CMakeFiles/psi4_objlib.dir/export_functional.cc.o 
> CMakeFiles/psi4_objlib.dir/export_oeprop.cc.o 
> CMakeFiles/psi4_objlib.dir/export_plugins.cc.o 
> CMakeFiles/psi4_objlib.dir/export_blas_lapack.cc.o 
> CMakeFiles/psi4_objlib.dir/export_benchmarks.cc.o 
> CMakeFiles/psi4_objlib.dir/export_efp.cc.o 
> CMakeFiles/psi4_objlib.dir/export_cubeprop.cc.o 
> CMakeFiles/psi4_objlib.dir/clean.cc.o 
> CMakeFiles/psi4_objlib.dir/create_new_plugin.cc.o 
> CMakeFiles/psi4_objlib.dir/script.cc.o 
> CMakeFiles/psi4_objlib.dir/set_memory.cc.o 
> CMakeFiles/psi4_objlib.dir/read_options.cc.o 
> CMakeFiles/psi4_objlib.dir/export_libparallel.cc.o 
> CMakeFiles/versioned_code.dir/version.cc.o 
> CMakeFiles/versioned_code.dir/python.cc.o 
> CMakeFiles/versioned_code.dir/psi_start.cc.o CMakeFiles/versioned_code.dir
>  /psi4.cc.o  -o ../../../bin/psi4 -rdynamic -lutil -lm -lrt -ldl -lpython2.7 
> -Wl,--whole-archive ../../../lib/libadc.a ../../../lib/libccdensity.a 
> ../../../lib/libccenergy.a ../../../lib/libcceom.a ../../../lib/libcchbar.a 
> ../../../lib/libcclambda.a ../../../lib/libccresponse.a 
> ../../../lib/libccsort.a ../../../lib/libcctransort.a 
> ../../../lib/libcctriples.a ../../../lib/libdcft.a ../../../lib/libdetci.a 
> ../../../lib/libdfmp2.a ../../../lib/libdfocc.a ../../../lib/libefp.a 
> ../../../lib/libfindif.a ../../../lib/libfisapt.a ../../../lib/libfnocc.a 
> ../../../lib/libmcscf.a ../../../lib/libmints_wrapper.a 
> ../../../lib/libmrcc.a ../../../lib/libocc.a ../../../lib/liboptking.a 
> ../../../lib/libpsimrcc.a ../../../lib/libsapt.a ../../../lib/libscf.a 
> ../../../lib/libscfgrad.a ../../../lib/libthermo.a ../../../lib/libtransqt2.a 
> ../../../lib/libdmrg.a ../../../lib/lib3index.a ../../../lib/libciomr.a 
> ../../../lib/libdiis.a ../../../lib/libdisp.a ../../../lib/libdpd.a 
> ../../../lib/libefp_solver.a .
>  ./../../lib/libfock.a ../../../lib/libfunctional.a -Wl,--whole-archive 
> ../../../lib/libiwl.a -Wl,--no-whole-archive ../../../lib/libmints.a 
> ../../../lib/libmoinfo.a ../../../lib/liboptions.a ../../../lib/libparallel.a 
> ../../../lib/libparallel2.a ../../../lib/libplugin.a 
> ../../../lib/libsapt_solver.a ../../../lib/libscf_solver.a 
> ../../../lib/libthce.a ../../../lib/libtrans.a ../../../lib/libpsi4util.a 
> ../../../lib/libpsio.a ../../../lib/libPsiUtil.a ../../../lib/libqt.a 
> ../../../lib/libcubeprop.a ../../../lib/libinterface_libefp.a 
> -Wl,--no-whole-archive -Wl,-Bstatic -lboost_filesystem -lboost_python 
> -lboost_regex -lboost_serialization -lboost_system -lboost_timer 
> -lboost_chrono -lboost_thread -lboost_date_time -lboost_atomic -Wl,-Bdynamic 
> -lpthread -llapack -lblas -lpython2.7 -lblas -llapack -lint -lderiv -lutil 
> -ldl -lrt -lm /usr/lib/x86_64-linux-gnu/libchemps2.so -lchemps2 
> /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5.so -lsz -lz -lpthread -lm 
> -lpython2.7 -ldl -Wl,-rpath,/usr/l
>  ib/x86_64-linux-gnu/hdf5/serial/lib 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(operations.o):
>  relocation R_X86_64_32S against symbol 
> `_ZN5boost6detail15sp_counted_base7destroyEv' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(path.o):
>  relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(list.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(dict.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can 

Bug#841968: libleptonica-dev: please move lept.pc to a multiarch location

[Andreas Cadhalpun]

Package: libleptonica-dev
Version: 1.73-5+b1
Tags: patch
Control: affects -1 + src:ffmpeg

Dear Maintainer,

lept.pc is installed into /usr/lib/pkgconfig. That directory is not
searched by pkg-config during cross compilation and thus makes ffmpeg
fail to cross build, since it uses tesseract.pc, which requires lept.pc.
Please move tesseract.pc to a multiarch location.
Consider applying the attached patch.

Best regards,
Andreas
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-5
+10
--- a/debian/liblept5.dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib
--- a/debian/liblept5.install
+++ b/debian/liblept5.install
@@ -1 +1 @@
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
--- a/debian/libleptonica-dev.dirs
+++ /dev/null
@@ -1,2 +0,0 @@
-usr/lib
-usr/include
--- a/debian/libleptonica-dev.install
+++ b/debian/libleptonica-dev.install
@@ -1,4 +1,4 @@
 usr/include/*
-usr/lib/lib*.a
-usr/lib/lib*.so
-usr/lib/pkgconfig/*
+usr/lib/*/lib*.a
+usr/lib/*/lib*.so
+usr/lib/*/pkgconfig/*
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ build-stamp:
 	dh_testdir
 	dh_autoreconf
 	# Add here commands to compile the package.
-	./configure --prefix=/usr $(shell dpkg-buildflags --export=configure)
+	dh_auto_configure
 	$(MAKE)
 	touch build-stamp
 

Bug#841963: libpdl-io-hdf5-perl: Please support building against HDF5-1.10

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Gilles,

Thanks for the patch.

On 10/24/2016 10:21 PM, Gilles Filippini wrote:
> Please find attached a patch to support building against HDF5-1.10 currently 
> in experimental. I intend to request a transition slot this week, and will 
> NMU if need be.

I've added the patch in git, and a new upload to unstable will follow
shortly.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#841969: /usr/share/man/de/man8/apt-get.8.gz: German man page confusion in apt-get source subcommand

[Dominik George]

Package: apt
Version: 1.3
Severity: normal
File: /usr/share/man/de/man8/apt-get.8.gz
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The German man page has a mistake in the section for the source command.

The English text says:

   A specific source version can be retrieved by postfixing the
   source name with an equals and then the version to fetch,

The German text says:

   Eine bestimmte Quellversion kann durch Voranstellen eines
   Gleichheitszeichens vor den Paketnamen und dann der Version zum
   Herunterladen erhalten werde,

Now, "Voranstellen" means "prefixing", which is quite the contrary of the
English text (and the actual syntax) ;).

Fix:

   Eine bestimmte Quellversion kann durch Anhängen eines
   Gleichheitszeichens an den Paketnamen und dann der Version zum
   Herunterladen erhalten werden,

Mind that I also added an -n to the last word while at it.

Cheers,
Nik

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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2014.3
ii  gpgv2.1.15-3
ii  init-system-helpers 1.45
ii  libapt-pkg5.0   1.3
ii  libc6   2.24-3
ii  libgcc1 1:6.2.0-5
ii  libstdc++6  6.2.0-5

Versions of packages apt recommends:
ii  gnupg   2.1.15-3
ii  gnupg1  1.4.21-1
ii  gnupg2  2.1.15-3

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.3-1+b1
ii  dpkg-dev1.18.10
ii  powermgmt-base  1.31+nmu1
ii  python-apt  1.1.0~beta5

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJYDnOoMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
9yMQAJgfEG8bCMGmRVJAiV1zj5Dr4/u1odnOTvwj4FX3rgzP6ASa6Ta88b5uAjUD
U430xGln83u0Ey3kqPRycduPgQPEUi9pgMqswGOkC4APSXng3dfsmkxv3QidhgHn
VxdlCrJY3Wlq7cg830vTePLZqjSHG/GyhlpCp/dAO89uxv93WGtuTwWAxX7pgP/4
SAaBAaC14ePVv6RNGjhh0QWSSWWU5ReHwOCSfqvHuhWetCB2A+pZPQnkE1oftbcI
1n2Vc5kQjdO2jCEPe3to7xsD6TwB3uibLqd6fteYTPSoJEg1xkSFgVrLl8jeFXfF
AyNqHtYUm5S1iioItUoY+zUXsrDmzrivxx52dZEIKfw8iy8xv7DoLaR3cwLgVgS8
zV0frtGEdcrslF/1IEktPxsJ3OACOGEtsN59RVQ63DTNpzgryiQyUyxHfC+wWYNq
Cd61n9veKGeylNa0JquhJPybZaPB4gkoNPPKIme4EY8ArkqDFnoCjQTPRovE2v5K
5f+/aBrzrDdpaNbwvtS1XrDtgtLFexP4VntivWcRfwGNhzCWWtR3KNKOH562bTQj
QiOA5cE8ffME2VWY3UQi/f99PindpXU4VrYWH1dVVE7RvSYpsahL4ahk0bql7t+B
RqF7Z0njhEbbJCAVyzgj8UY/1tsUP0651GwmzQhP9B/1us2D
=C8ZW
-END PGP SIGNATURE-

Bug#841970: libminc: Please support building against HDF5 1.10

[Gilles Filippini]

Source: libminc
Version: 2.3.00-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. This patch is a backport of two upstream commits related to 
hdf5-1.10 support. Please see upstream ticket #74 [1].

[1] https://github.com/BIC-MNI/libminc/issues/74

I intend to request a transition slot this week, and will NMU if need be.

Thanks,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDnQdAAoJEO/obGx//s+DMucIAKfPWkyHBDzPJIaB4OCqp6dk
kwZPq8YbvikQL+y71IXLDNncxytiqQpakbLHhcokK/+DqZu6c5j1tNOnQTRvgaXc
oCfLd4Fh5/bYtAGs1TtnCw0FEje3qUtA4in4TEy9lKcuXwVHYrrFOxqiv1N4Xznj
GbpvIEjM1nR4IIP2s4zs0ZM0Q437bEV6rZejWnKypB9AlHAQafx2Cf/zG82oYlHX
AlqnjUJW3Uoc0IBe6RvOFvt8LHG1vm8HSy+zQBeLGGCoC8b5qc7xiCQVu01G5+sR
eocifRf60srli2i4sB0uUsDE1EpE6D+jBRQY/Kw6QNSqbO2g7x5dNvT8BC2zgoA=
=JOhL
-END PGP SIGNATURE-
diff -Nru libminc-2.3.00/debian/changelog libminc-2.3.00/debian/changelog
--- libminc-2.3.00/debian/changelog	2016-09-02 09:40:37.0 +0200
+++ libminc-2.3.00/debian/changelog	2016-10-20 19:31:12.0 +0200
@@ -1,3 +1,10 @@
+libminc (2.3.00-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch to support HDF5 1.10
+
+ -- Gilles Filippini   Thu, 20 Oct 2016 19:31:10 +0200
+
 libminc (2.3.00-3) unstable; urgency=medium
 
   * Wrote watch file
diff -Nru libminc-2.3.00/debian/patches/hdf5-1.10-support.patch libminc-2.3.00/debian/patches/hdf5-1.10-support.patch
--- libminc-2.3.00/debian/patches/hdf5-1.10-support.patch	1970-01-01 01:00:00.0 +0100
+++ libminc-2.3.00/debian/patches/hdf5-1.10-support.patch	2016-10-20 20:37:42.0 +0200
@@ -0,0 +1,451 @@
+Description: don't assume hid_t === int since this is no longer true
+ in HDF5 1.10.
+ This is a backport of upstream commits d99dd01 and 92ba4fa related
+ to issue #74 [1].
+ .
+ [1] https://github.com/BIC-MNI/libminc/issues/74
+Index: libminc-2.3.00/libsrc/hdf_convenience.c
+===
+--- libminc-2.3.00.orig/libsrc/hdf_convenience.c
 libminc-2.3.00/libsrc/hdf_convenience.c
+@@ -45,7 +45,8 @@ struct m2_dim {
+ 
+ static struct m2_file {
+ struct m2_file *link;
+-hid_t fd;
++int   fd;   /* our fake file id */
++hid_t file_id;  /* actual hdf5 file id */
+ int wr_ok;  /* non-zero if write OK */
+ int resolution;		/* Resolution setting. */
+ int nvars;
+@@ -74,18 +75,20 @@ hdf_id_check(int fd)
+ }
+ 
+ static struct m2_file *
+-hdf_id_add(int fd)
++hdf_id_add(hid_t file_id)
+ {
+ struct m2_file *new;
++static unsigned short _id = 0;   /* at most 2^16 id's */
+ 
+ new = (struct m2_file *) malloc(sizeof (struct m2_file));
+ if (new != NULL) {
+-	new->fd = fd;
++new->fd = HDF5_ID_MIN + _id++;
++new->file_id = file_id;
+ 	new->resolution = 0;
+ 	new->nvars = 0;
+ 	new->ndims = 0;
+ 	new->link =_m2_list;
+-new->grp_id = H5Gopen1(fd, MI2_GRPNAME);
++new->grp_id = H5Gopen1(file_id, MI2_GRPNAME);
+ new->comp_type = MI2_COMP_UNKNOWN;
+ new->comp_param = 0;
+ new->chunk_type = MI2_CHUNK_UNKNOWN;
+@@ -99,7 +102,7 @@ hdf_id_add(int fd)
+ return (new);
+ }
+ 
+-static int 
++static int
+ hdf_id_del(int fd)
+ {
+ struct m2_file *curr, *prev;
+@@ -142,6 +145,7 @@ hdf_id_del(int fd)
+ 	}
+ 
+ H5Gclose(curr->grp_id);
++H5Fclose(curr->file_id);
+ 	free(curr);
+ 	return (MI_NOERROR);
+ 	}
+@@ -187,7 +191,7 @@ hdf_var_add(struct m2_file *file, const
+   strncpy(new->name, name, NC_MAX_NAME - 1);
+   strncpy(new->path, path, NC_MAX_NAME - 1);
+   new->is_cmpd = 0;
+-  new->dset_id = H5Dopen1(file->fd, path);
++  new->dset_id = H5Dopen1(file->file_id, path);
+   new->ftyp_id = H5Dget_type(new->dset_id);
+   new->mtyp_id = H5Tget_native_type(new->ftyp_id, H5T_DIR_ASCEND);
+   new->fspc_id = H5Dget_space(new->dset_id);
+@@ -490,7 +494,7 @@ hdf_attinq(int fd, int varid, const char
+   return (MI_ERROR);
+   }
+ 
+-  if (varid == NC_GLOBAL) {
++  if (varid == NC_GLOBAL || varid == MI_ROOTVARIABLE_ID) {
+   var = NULL;
+   loc_id = file->grp_id;
+   } 
+@@ -591,7 +595,7 @@ hdf_attinq(int fd, int varid, const char
+ }
+ 
+ static int
+-hdf_put_dimorder(struct m2_file *file, int dst_id, int ndims, 
++hdf_put_dimorder(struct m2_file *file, hid_t dst_id, int ndims, 
+ 		 const int *dims_ptr)
+ {
+ int i;
+@@ -626,6 +630,9 @@ hdf_put_dimorder(struct m2_file *file, i
+ if (att_id >= 0) {
+ 	

Bug#841971: gnudatalanguage: Please support building against HDF5 1.10

[Gilles Filippini]

Source: gnudatalanguage
Version: 0.9.6v2-3
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. I intend to request a transition slot this week, and will NMU if 
need be.

Thanks,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDnUAAAoJEO/obGx//s+DJ1sH/1B7PVhHiOo51F6H46HSvg4M
DjxpTTZc3vqgg8hJ9qCRIay1MMslThFiuPHpaBKBlVxW+8UZlNPLU8Lcqk1UVkyM
KFsmxhR+RwJGxFnPpMJp9AcNk4vGQiZohQcP+nP6iHIc/gl2+D87g6xziyDZh9M6
oVNsbhEtyMU5m/jn0oSYyTjIfb2lCJ9ubbssf7T5Tcj9TtebhC1v2nmQyr7H5kFB
6+GX06AetA2gDIjBds80gWq3zuJAZK7FDoG8QALveCNOA3XXLSYxZIy0Q393gz9n
qPd6ywciIDsY/YT9Spsu4LYfWnYYLWbHLzyq9Re+YSZkLUlkzGd20Wtxkweh3rU=
=+ZUL
-END PGP SIGNATURE-
diff -Nru gnudatalanguage-0.9.6v2/debian/changelog gnudatalanguage-0.9.6v2/debian/changelog
--- gnudatalanguage-0.9.6v2/debian/changelog	2016-07-01 13:20:18.0 +0200
+++ gnudatalanguage-0.9.6v2/debian/changelog	2016-10-22 13:07:12.0 +0200
@@ -1,3 +1,10 @@
+gnudatalanguage (0.9.6v2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch to support HDF5 1.10
+
+ -- Gilles Filippini   Sat, 23 Jul 2016 18:34:25 +0200
+
 gnudatalanguage (0.9.6v2-3) unstable; urgency=medium
 
   * Another patch for gcc-6 compatibility
diff -Nru gnudatalanguage-0.9.6v2/debian/patches/hdf5-1.10.patch gnudatalanguage-0.9.6v2/debian/patches/hdf5-1.10.patch
--- gnudatalanguage-0.9.6v2/debian/patches/hdf5-1.10.patch	1970-01-01 01:00:00.0 +0100
+++ gnudatalanguage-0.9.6v2/debian/patches/hdf5-1.10.patch	2016-10-22 13:07:12.0 +0200
@@ -0,0 +1,28 @@
+Index: gnudatalanguage-0.9.6v2/src/hdf5_fun.cpp
+===
+--- gnudatalanguage-0.9.6v2.orig/src/hdf5_fun.cpp
 gnudatalanguage-0.9.6v2/src/hdf5_fun.cpp
+@@ -349,7 +349,11 @@ namespace lib {
+ hsize_t dims_out[MAXRANK];
+ 
+ hid_t h5a_id;
++#if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=10))
++e->AssureLongScalarPar(0, (DLong64&)h5a_id);
++#else
+ e->AssureLongScalarPar(0, h5a_id);
++#endif
+ 
+ hid_t h5s_id = H5Aget_space(h5a_id);
+ if (h5s_id < 0) { string msg; e->Throw(hdf5_error_message(msg)); }
+@@ -403,7 +407,11 @@ namespace lib {
+ hsize_t dims_out[MAXRANK];
+ 
+ hid_t h5d_id;
++#if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=10))
++e->AssureLongScalarPar(0, (DLong64&)h5d_id);
++#else
+ e->AssureLongScalarPar(0, h5d_id);
++#endif
+ 
+ hid_t h5s_id = H5Dget_space(h5d_id);
+ if (h5s_id < 0) { string msg; e->Throw(hdf5_error_message(msg)); }
diff -Nru gnudatalanguage-0.9.6v2/debian/patches/series gnudatalanguage-0.9.6v2/debian/patches/series
--- gnudatalanguage-0.9.6v2/debian/patches/series	2016-07-01 13:15:09.0 +0200
+++ gnudatalanguage-0.9.6v2/debian/patches/series	2016-10-22 13:07:12.0 +0200
@@ -12,3 +12,4 @@
 fix-file_move
 gdl-template.patch
 fix_return.patch
+hdf5-1.10.patch

Bug#841963: Pending fixes for bugs in the libpdl-io-hdf5-perl package

[pkg-perl-maintainers]

tag 841963 + pending
thanks

Some bugs in the libpdl-io-hdf5-perl package are closed in revision
28b918949587cce0d4e667bd02da26def7593183 in branch 'master' by Bas
Couwenberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libpdl-io-hdf5-perl.git/commit/?id=28b9189

Commit message:

New patch for HDF5 1.10 support. (closes: #841963)

Bug#841972: minc-tools: Please support building against HDF5 1.10

[Gilles Filippini]

Source: minc-tools
Version: 2.3.00+dfsg-1
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. I intend to request a transition slot this week, and will NMU if 
need be.

Thanks,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDnWSAAoJEO/obGx//s+DeTAIAJiy+M3OXRCYLVCjHa4y10+n
oMp7jFTzO2CEZfdC8V9+ZC9eLgScgU8RxFy0LL/H1Ijkhgsfo3B/DoZ4GuUvC0KD
LrecFw6sJvjUiZ6sREkbm50KC1K/R7XuPZhTpLjilJYyu63Ix9WMMvh2CEDej/ok
xOxuk/bSsXG1FkXwsKnoWTIIb8OA/yg2KsIoryr1++xBcmPGvtjDQJC8mIWbR+X0
owme5/vjt+HATxBCBkj1nOVnFjlcmBDdtYBp+9I/TlEg2enwqFz83ONgk20OVkLR
/LioK8XMzDg4ETvhJqBzvFRpfDdmt43R9IvuOfH1a+sptWLlIaLBU63A73a7xeo=
=2iCi
-END PGP SIGNATURE-
diff -Nru minc-tools-2.3.00+dfsg/debian/changelog minc-tools-2.3.00+dfsg/debian/changelog
--- minc-tools-2.3.00+dfsg/debian/changelog	2015-09-27 04:52:23.0 +0200
+++ minc-tools-2.3.00+dfsg/debian/changelog	2016-10-20 20:52:54.0 +0200
@@ -1,3 +1,10 @@
+minc-tools (2.3.00+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch to support HDF5-1.10.
+
+ -- Gilles Filippini   Thu, 20 Oct 2016 20:52:19 +0200
+
 minc-tools (2.3.00+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru minc-tools-2.3.00+dfsg/debian/patches/hdf5-1.10-support.patch minc-tools-2.3.00+dfsg/debian/patches/hdf5-1.10-support.patch
--- minc-tools-2.3.00+dfsg/debian/patches/hdf5-1.10-support.patch	1970-01-01 01:00:00.0 +0100
+++ minc-tools-2.3.00+dfsg/debian/patches/hdf5-1.10-support.patch	2016-10-20 20:52:13.0 +0200
@@ -0,0 +1,14 @@
+Index: minc-tools-2.3.00+dfsg/progs/mincdump/mincdump.h
+===
+--- minc-tools-2.3.00+dfsg.orig/progs/mincdump/mincdump.h
 minc-tools-2.3.00+dfsg/progs/mincdump/mincdump.h
+@@ -15,7 +15,9 @@
+ #define  Printf  (void) printf
+ 
+ typedef int boolean;
++#ifndef false
+ enum {false=0, true=1};
++#endif
+ 
+ struct ncdim {			/* dimension */
+ char name[NC_MAX_NAME];
diff -Nru minc-tools-2.3.00+dfsg/debian/patches/series minc-tools-2.3.00+dfsg/debian/patches/series
--- minc-tools-2.3.00+dfsg/debian/patches/series	2015-09-13 03:26:33.0 +0200
+++ minc-tools-2.3.00+dfsg/debian/patches/series	2016-10-20 20:51:44.0 +0200
@@ -1,2 +1,3 @@
 01_mincedit-sensible-viewer.diff
 build-with-libnifti
+hdf5-1.10-support.patch

Bug#841827: liborc-0.4-dev: cannot run orcc during cross compilation of reverse dependencies

[Andreas Cadhalpun]

Hi Helmut,

On 23.10.2016 21:25, Helmut Grohne wrote:
> Control: affects -1 = src:pulseaudio
> 
> On Sun, Oct 23, 2016 at 09:03:46PM +0200, Andreas Cadhalpun wrote:
>> Are you sure this affects ffmpeg?
> 
> Actually, no. I only managed to reproduce it for pulseaudio now, though
> I vaguely remember another practical reproducer.
> 
>> As far as I can tell its build doesn't execute orcc.
>> The cross-build currently fails due to:
>> ERROR: tesseract not found using pkg-config
> 
> Yes, that's #841845.

I see. With the patch from that bug it still doesn't work, because
tesseract.pc requires lept.pc, which is also not in the multi-arch
location. I've filed #841968 about that.
With both these fixed, ffmpeg can be cross-built successfully,
so it is definitely not affected by #841827.

By the way, thanks for all your work on cross-build support!

Best regards,
Andreas

Bug#841974: libguestfs-tools: Appliance get stuck

[Laurent Bigonville]

Package: libguestfs-tools
Version: 1:1.32.7-1+b2
Severity: grave
Justification: renders package unusable

Hi,

When running libguestfs-test-tool (and also from virt-manager) the
appliance get stuck at some point.

The first problem seems that there is no explicit dependency against
sgabios.

After installing sgabios, the appliance complains about "No bootable
device."

On my machine I've a linuxboot.bin file (from sgabios package) but this
is not enough apparently, if I'm creating a linuxboot_dma.bin symlink
to that file in /usr/share/seabios then the appliance starts as
expected (see the 3rd attached log file).

Laurent Bigonville

-- 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.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libguestfs-tools depends on:
ii  curl   7.50.1-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-5
ii  libcairo2  1.14.6-1+b1
ii  libconfig9 1.5-0.2
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libfuse2   2.9.7-1
ii  libgdk-pixbuf2.0-0 2.36.0-1
ii  libglib2.0-0   2.50.1-1
ii  libgtk2.0-02.24.31-1
ii  libguestfs-perl1:1.32.7-1+b2
ii  libguestfs01:1.32.7-1+b2
ii  libintl-perl   1.26-2
ii  liblzma5   5.2.2-1.2
ii  libncurses56.0+20160917-1
ii  libpango-1.0-0 1.40.3-2
ii  libpangocairo-1.0-01.40.3-2
ii  libpangoft2-1.0-0  1.40.3-2
ii  libpcre3   2:8.39-2
ii  libreadline7   7.0-1
ii  libstring-shellquote-perl  1.03-1.2
ii  libsys-virt-perl   2.3.0-1
ii  libtinfo5  6.0+20160917-1
ii  libvirt0   2.3.0-3
ii  libwin-hivex-perl  1.3.13-2+b2
ii  libxml22.9.4+dfsg1-2
ii  libyajl2   2.1.0-2

Versions of packages libguestfs-tools recommends:
ii  gnupg  2.1.15-4

libguestfs-tools suggests no packages.

-- no debconf information
 
 *IMPORTANT NOTICE
 *
 * When reporting bugs, include the COMPLETE, UNEDITED
 * output below in your bug report.
 *
 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
SELinux: sh: 1: getenforce: not found
guestfs_get_append: (null)
guestfs_get_autosync: 1
guestfs_get_backend: direct
guestfs_get_backend_settings: []
guestfs_get_cachedir: /var/tmp
guestfs_get_direct: 0
guestfs_get_hv: /usr/bin/qemu-system-x86_64
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib/x86_64-linux-gnu/guestfs
guestfs_get_pgroup: 0
guestfs_get_program: libguestfs-test-tool
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_tmpdir: /tmp
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: launch: program=libguestfs-test-tool
libguestfs: launch: version=1.32.7
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfsCF9TMu
libguestfs: launch: umask=0022
libguestfs: launch: euid=1000
libguestfs: [0ms] begin building supermin appliance
libguestfs: [0ms] run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /var/tmp/.guestfs-1000/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-1000/appliance.d
supermin: version: 5.1.16
supermin: package handler: debian/dpkg
supermin: acquiring lock on /var/tmp/.guestfs-1000/lock
supermin: if-newer: output does not need rebuilding
libguestfs: [7ms] finished building supermin appliance
libguestfs: [7ms] begin testing qemu features
libguestfs: command: run: /usr/bin/qemu-system-x86_64
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -help
libguestfs: command: run: /usr/bin/qemu-system-x86_64
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -version
libguestfs: qemu version 2.7
libguestfs: command: run: /usr/bin/qemu-system-x86_64
libguestfs: command: run: \ 

Bug#841973: libastro-fits-cfitsio-perl: test suite failure in autopkgtest

[Niko Tyni]

Package: libastro-fits-cfitsio-perl
Version: 1.11-1
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package recently introduced a Testsuite header (probably
accidentally, in commit 21bb2bfc0b without a mention in the commit
message) declaring autopkgtest-pkg-perl compatibility, but it fails its
autopkgtest checks on ci.debian.net.

 
https://anonscm.debian.org/cgit/pkg-perl/packages/libastro-fits-cfitsio-perl.git/commit/?id=21bb2bfc0b4d4258afa0013ffbd464b4d8139758

 http://ci.debian.net/packages/liba/libastro-fits-cfitsio-perl/unstable/amd64/

  ffibin.not ok
  ffghps.not ok
  ffhdef/ffghsp..not ok
  ffptdm/ffgtdm..not ok
  ffpclX/ffpcnX..not ok
  ffgcno/ffgcnn..Killed
  adt-run [18:39:33]: test command1: ---]
  adt-run [18:39:33]: test command1:  - - - - - - - - - - results - - - - - - - 
- - -
  command1 FAIL non-zero exit status 137
 
-- 
Niko Tyni   nt...@debian.org

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Wei Liu]

On Tue, 25 Oct 2016 05:47:27 +1030 Ron  wrote:
[...]
> That's basically why "just nuke htags now" is starting to look like
> a viable, and even sensible, option.  But it's tricky to know who
> might be upset by that - and we don't have a clear idea of exactly
> what we'd really gain elsewhere from that tradeoff, since most of
> the people saying "I need a new upstream" haven't actually been
> telling us what the real problem is which that fixes, even when I
> asked.

Gtags in Debian doesn't work with modern code base. Last time I tried (several
years ago), it segfault'ed while trying to index Linux kernel.

Here is my two cents on the issue of whether Debian should update global to a
newer version and nuke htags:

While I can't provide concrete numbers on how many people care or don't care
about htags, there are some proxies that can help with this:

1. Most if not all the bug reporters for global package don't use htags.
2. Other distros' maintainers / users don't seem to care about htags or its
   implications.
3. The Debian users of global, according to popcon, is declining, which means
   less and less people care about current package (hence htags, for that
   matter).

The core functionality of global is code indexing. As it stands, the current
version is buggy and chokes on modern code base. The usability of the current
package is only going to be less and less. No matter how secured the current
package is, Debian users won't be able to use it because it can't generate
index files in the first place.  Eventually no-one will use this package. All
in all, I think it is a disservice to Debian users to keep the status quo.  I
believe you've exhausted all venues to communicate with upstream your concern
about CGI scripts. It is unfortunate that no progress was made in the last 8+
years. Under such circumstance,  sacrificing a non-core functionality (htags)
to serve the greater good seems to be a good trade-off to me.

Wei.

Bug#841961: nmu: ocaml_4.02.3-7

[Adam D. Barratt]

Control: forcemerge 841938 -1

On Mon, 2016-10-24 at 22:07 +0200, Gilles Filippini wrote:
> Please rebuild ocaml against the pie-enabled compiler chain, to fix an FTBFS 
> of scilab package:

Please don't file duplicate requests.

Regards,

Adam

Bug#841462: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016h

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-10-22 at 14:45 +0200, gregor herrmann wrote:
> On Sat, 22 Oct 2016 11:42:39 +0100, Adam D. Barratt wrote:
> 
> > > Another month, another tzdata update.
> > > As usual, I've added a quilt patch for the Olson db, this time 2016h,
> > > to libdatetime-timezone-perl.
> > 
> > Please go ahead.
> 
> Thanks; uploaded.

Flagged for acceptance.

I'll try and get the SUAs for this and tzdata sorted out later in the
week.

Regards,

Adam

Bug#841975: src:scilab: Please support building with HDF5 1.10

[Gilles Filippini]

Package: src:scilab
Version: 5.5.2-2
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please find attached a patch to support building against HDF5-1.10 currently in 
experimental. This patch partly comes from upstream ticket #14539 [1].

[1] https://bugzilla.scilab.org/show_bug.cgi?id=14539

I intend to request a transition slot this week, and will upload if need be, as 
member of the Debian Science team.

Thanks,

_g.

- -- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDnitAAoJEO/obGx//s+DO0wIALLEK4eTLTT0hK1wVPA9p/Hx
bBWmn79jYXyyic83vN7C3ZlQ7WHBmXU+bLNFQGw+DwIn5dKmd/a5/55jqcp5BFoG
7zhOsU4tb0ro21zvbNcMjgJbt/Ilvf3xPq6fN6QNpQqDmtuIuGX8vVVbbMFp3y7i
PBIX+bE7xfwWRzhhjXMGRRdoZ6wKHyxIEmp92OLBKkr8EvOft4Dmj2Z2BvmOyi0/
Uc6xVOEC+TlAguVtSevewX+gBACbEiBQyf05snIRQV1DA5ntRKMhiZy5iGZLE4gP
zzdMiRZInBYUCo7oNa1xVl+czE+qyL0F+/HpWQPD9qik4l45297NVGmsdgnohrY=
=T6xH
-END PGP SIGNATURE-
diff -Nru scilab-5.5.2/debian/changelog scilab-5.5.2/debian/changelog
--- scilab-5.5.2/debian/changelog	2015-10-30 10:22:41.0 +0100
+++ scilab-5.5.2/debian/changelog	2016-10-22 15:54:38.0 +0200
@@ -1,3 +1,9 @@
+scilab (5.5.2-3) unstable; urgency=medium
+
+  * New patch to support HDF5-1.10
+
+ -- Gilles Filippini   Sat, 22 Oct 2016 15:54:20 +0200
+
 scilab (5.5.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru scilab-5.5.2/debian/patches/hdf5-1.10-api.patch scilab-5.5.2/debian/patches/hdf5-1.10-api.patch
--- scilab-5.5.2/debian/patches/hdf5-1.10-api.patch	1970-01-01 01:00:00.0 +0100
+++ scilab-5.5.2/debian/patches/hdf5-1.10-api.patch	2016-10-24 21:14:57.0 +0200
@@ -0,0 +1,331 @@
+Index: scilab-5.5.2/m4/hdf5.m4
+===
+--- scilab-5.5.2.orig/m4/hdf5.m4
 scilab-5.5.2/m4/hdf5.m4
+@@ -65,6 +65,11 @@ if test "x$with_hdf5_library" != "xyes";
+ [AC_MSG_ERROR([libhdf5 or libhdf5_hl: library missing. (Cannot find symbol H5Fopen) in $with_hdf5_library. Check if libhdf5 is installed and if the version is correct])],
+ [-lz]
+ )
++AC_CHECK_LIB([hdf5], [H5Rdereference2],
++[FORCE_HDF_1_10_API="-DH5Rdereference_vers=2"],
++[],
++[-lz]
++)
+ else
+ if $WITH_DEVTOOLS; then # Scilab thirparties
+ HDF5_LIBS="-L$DEVTOOLS_LIBDIR -lhdf5 -lhdf5_hl"
+@@ -93,6 +98,7 @@ LIBS="$save_LIBS"
+ 
+ AC_SUBST(HDF5_LIBS)
+ AC_SUBST(HDF5_CFLAGS)
++AC_SUBST(FORCE_HDF_1_10_API)
+ 
+ AC_DEFINE([WITH_HDF5], [], [With the HDF5 library])
+ 
+Index: scilab-5.5.2/modules/hdf5/Makefile.am
+===
+--- scilab-5.5.2.orig/modules/hdf5/Makefile.am
 scilab-5.5.2/modules/hdf5/Makefile.am
+@@ -86,6 +86,8 @@ FORCE_HDF_1.8_API =  -DH5Dopen_vers=2 -D
+  -DH5Gcreate_vers=2 -DH5Gopen_vers=2 -DH5Tget_array_dims_vers=2 \
+  -DH5Acreate_vers=2 -DNO_DEPRECATED_SYMBOLS
+ 
++FORCE_HDF_1.10_API = @FORCE_HDF_1_10_API@
++
+ libscihdf5_la_CPPFLAGS = -I$(srcdir)/includes/ \
+ -I$(srcdir)/src/c/ \
+ -I$(srcdir)/src/cpp/ \
+@@ -98,7 +100,8 @@ libscihdf5_la_CPPFLAGS = -I$(srcdir)/inc
+ $(JAVA_JNI_INCLUDE) \
+ $(HDF5_CFLAGS) \
+ $(AM_CPPFLAGS) \
+-$(FORCE_HDF_1.8_API)
++$(FORCE_HDF_1.8_API) \
++$(FORCE_HDF_1.10_API)
+ 
+ 
+ 
+Index: scilab-5.5.2/modules/hdf5/src/c/h5_readDataFromFile.c
+===
+--- scilab-5.5.2.orig/modules/hdf5/src/c/h5_readDataFromFile.c
 scilab-5.5.2/modules/hdf5/src/c/h5_readDataFromFile.c
+@@ -716,7 +716,11 @@ int readCommonPolyMatrix(int _iDatasetId
+ /*
+  * Open the referenced object, get its name and type.
+  */
+-obj = H5Rdereference(_iDatasetId, H5R_OBJECT, [i]);
++obj = H5Rdereference(_iDatasetId,
++#if H5_VERSION_GE(1,10,0)
++ H5P_DATASET_ACCESS_DEFAULT,
++#endif
++ H5R_OBJECT, [i]);
+ if (_iComplex)
+ {
+ status = readComplexPoly(obj, &_piNbCoef[i], &_pdblReal[i], &_pdblImg[i]);
+@@ -950,7 +954,11 @@ int readCommonSparseComplexMatrix(int _i
+ }
+ 
+ //read Row data
+-obj = H5Rdereference(_iDatasetId, H5R_OBJECT, [0]);
++obj = H5Rdereference(_iDatasetId,
++#if H5_VERSION_GE(1,10,0)
++ H5P_DATASET_ACCESS_DEFAULT,
++#endif
++ H5R_OBJECT, [0]);
+ status = readInteger32Matrix(obj, _piNbItemRow);
+ if (status < 0)
+ {
+@@ -958,7 +966,11 @@ int readCommonSparseComplexMatrix(int _i
+ }
+ 
+ //read cols data
+-obj 

Bug#610979: change of tags / fixed-upstream

[Jari Aalto]

tags 610979 + fixed-upstream
thanks

https://github.com/wojtekka/6tunnel/commit/fc9e10fde74eb6dd89d7196234a18d42035cb4d6

Bug#841681: jessie-pu: package ark/4:4.14.2-2

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-10-22 at 11:41 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2016-10-22 at 10:22 +0200, Maximiliano Curia wrote:
> > I would like to fix the bugs #800021 and #770840 of the ark package in 
> > stable.
> > 
> > The current behaviour is that the version of ark in stable crashes when 
> > working on nested files, and it also crashes on exit when there is an open 
> > file.
> > 
> > The patch for fixing this was provided by upstream, backporting the fix to 
> > the 
> > 4.14 branch.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#841415: mopidy: default local config includes data_dir entry

[Stein Magnus Jodal]

On Thu, Oct 20, 2016 at 11:16:58AM +0100, Tim Small wrote:
> The package ships with a default config which includes:
> 
> [local]
> data_dir = /var/lib/mopidy/local
> 
> and also creates a corresponding directory.  However the data_dir config
> entry is marked "Deprecated" in
> 
> /usr/lib/python2.7/dist-packages/mopidy/local/__init__.py
> 
> "Used for ignoring old config values that are no longer in use"
> according to the API docs.
> 
> This default config file entry seems a bit misleading to new users, and
> should be removed I think.

Thanks for the bug report. This will be fixed in the next upload.

-- 
Stein Magnus Jodal
jo...@debian.org


signature.asc
Description: PGP signature

Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-10-23 at 18:47 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2016-10-23 at 19:45 +0200, Samuel Thibault wrote:
> > Control: tags -1 - confirmed
> > 
> > > On Sun, 2016-10-23 at 15:10 +0200, Samuel Thibault wrote:
> > > > Hello,
> > > > 
> > > > Samuel Thibault, on Sun 23 Oct 2016 12:47:37 +0200, wrote:
> > > > > As reported in #841714, a user couldn't use ebook-speaker to read a
> > > > > .html file, because ebook-speaker was requesting the user to install
> > > > > "the xml2 package" to be able to achieve this, and the user had it
> > > > > installed already. ebook-speaker actually needed the html2text 
> > > > > package.
> > > > > In the changes proposed here, I just fixed the text of the hint (and
> > > > > fixed the translations accordingly), is it OK for a Jessie upload?
> > > > 
> > > > I forgot to mention that this bug doesn't affect the Stretch version,
> > > > which doesn't use html2text any more.
> > > 
> > > It does, however, still have a Suggests for the package and mention it
> > > as being required in the readme.
> > 
> > Oh, that makes me realize that we should actually add the suggest in
> > Jessie (and we can drop it from the Stretch version). So that'd add the
> > attached change, is it OK?
> 
> Sure (as the Suggests has no practical impact on dependency chains
> etc.).

Uploaded and flagged for acceptance.

Regards,

Adam