Bug#846353: FTBFS: ERROR: Test "ruby2.3" failed. Exiting.

[Gilles Filippini]

Sebastiaan Couwenberg a écrit le 02/12/2016 à 15:34 :
> On 12/02/2016 09:55 AM, Sebastiaan Couwenberg wrote:
>> On 12/01/2016 07:48 PM, Sebastiaan Couwenberg wrote:
>>> On Wed, 30 Nov 2016 15:10:03 + Iain Lane wrote:
 This package FTBFS on 32 bit arches (works on amd64 and other 64 bit
 arches), maybe due to the new hdf5
>>>
>>> Quite likely, since hdf-eos5 hasn't been rebuilt for the hdf5 transition
>>> yet. I suspect this issue to fix itself once that's done.
>>
>> It did not, but did only fail on 32-bit architectures.
> 
> Gilles, these failures seem to be caused by the hid_t type change from
> 32-bit to a 64-bit value. I'm not sure how to fix it for ruby-hdfeos5,
> can you maybe provide a patch?

Damn, I tested the build on amd64 only :/
I've tried fixing the 'incompatible pointer type' warning, but it
deosn't change anything wrt the test suite.
Is there a way to ensure first that hdf-eos5 works fine on 32 bit archs?

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#842817: fixed in yorick-hdf5 0.8.0-7

[Gilles Filippini]

Hi Thibaut,

On Thu, 03 Nov 2016 11:51:19 + Thibaut Paumard <thib...@debian.org>
wrote:
> Source: yorick-hdf5
> Source-Version: 0.8.0-7
> 
> We believe that the bug you reported is fixed in the latest version of
> yorick-hdf5, which is due to be installed in the Debian FTP archive.
[cut]
> Closes: 842817
> Changes:
>  yorick-hdf5 (0.8.0-7) experimental; urgency=medium
>  .
>* Bug fix: "FTBFS against HDF5 v1.10", thanks to Gilles Filippini
>  (Closes: #842817).
>* Check against Policy 3.9.8.

Could you upload this fix to unstable, now that HDF5-1.10 transition has
started?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#846541: h5py: FTBFS against hdf5 1.10 - Fail to detect HDF5 install dir

[Gilles Filippini]

Source: h5py
Version: 2.6.0-1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

h5py FTBFS against hdf5-1.10 with:
==
ERROR: test_force_swmr_mode_off_raises 
(h5py.tests.hl.test_dataset_swmr.TestDatasetSwmrRead)
Switching SWMR write mode off is only possible by closing the file.
- --
Traceback (most recent call last):
  File "h5py/tests/hl/test_dataset_swmr.py", line 58, in setUp
self.f = h5py.File(fname, 'r', swmr=True)
  File "h5py/_hl/files.py", line 272, in __init__
fid = make_fid(name, mode, userblock_size, fapl, swmr=swmr)
  File "h5py/_hl/files.py", line 91, in make_fid
flags |= h5f.ACC_SWMR_READ
AttributeError: 'module' object has no attribute 'ACC_SWMR_READ'
...
- --
Ran 423 tests in 1.568s

FAILED (errors=9, skipped=10, expected failures=7)

Previously in the buildlog there is:

   Summary of the h5py configuration

Path to HDF5: None
HDF5 Version: '1.8.4'
 MPI Enabled: False
Rebuild Required: False



Then I tried with HDF5_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial and this 
time the build was successful.

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

iQEcBAEBCAAGBQJYQLRjAAoJEO/obGx//s+DVjYH/i4LAEgv81YkUIXzuL3o4nkY
Szkv9beTJ/05HUPDvetXDNztTP3ECAZ8n9I0OzNEVm1jolVQpAiG9sMXkNag0vXi
/M+RTV0thtYh5nKkcF0tPXVKGnRsEikmgErc9LsVDFfW6HFaW83TK+QMXZQd3sXN
yO20C5editQa/LhFAeFNy+4MS5NEY9vTICTUr4KN6rGF9MQUZ8Gygz4UXZ1jBfhJ
73OFn0TobitVgLtIrc78V674COjhWyQaNL88vYkoV0RkdtQatd60eHSuKwurS9P0
oG6qY+lfBGE1iHQyAmb6Hja98RIhd/nCG6vbQlRKIBY8/NDzMwhJZjMjqWigyyU=
=Z5CO
-END PGP SIGNATURE-

Bug#842177: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit le 28/11/2016 à 10:05 :
> Emilio Pozuelo Monfort a écrit le 27/11/2016 à 23:52 :
>> On 27/11/16 23:21, Gilles Filippini wrote:
>>> Hi,
>>>
>>> Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>>>>> Yes, this is looking very good, so I'm acking it. But please don't 
>>>>>> upload just
>>>>>> yet, I'll give you the go in a few days when things are a bit calmer 
>>>>>> (there are
>>>>>> just too many transitions at the moment).
>>>
>>> Any news on this side? I'm waiting after the transition to upload a new
>>> release of the package which will have to go through the NEW queue
>>> because of new binary packages for the java bindings.
>>
>> Go ahead.
> 
> Release 1.10.0-patch1+docs-1 uploaded to unstable.

No binnmu so far. Is there anything preventing the transition?
I think there is no need to wait for sh4 and powerpcspe builds: they're
unsuccessful since release 1.8.16.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#846196: RM: sikuli -- ROM; replaced by sikulix

[Gilles Filippini]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The sikuli source package is supeseded by sikulix which has now landed into 
unstable.

Thanks,

_g.

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYPUhlAAoJEO/obGx//s+DVl8H/2RJxYXtFyhwYUFH3VdSJPHn
Wz77Y1XmHYDIUXHwkY6ajLtNJ1mfXTYtOaU96jrg8EdjlHTC/n2l7WJwbtko4W4n
EaRJqUWabdEDR/L9T6QyxDssbN6rrrksKA7fV2OeGou4ZVIUs00kz8zshZlKmNz6
TnpqPCTmE5Zel5tfBbKqK2gCuXzOle7xyn91LjtZYMNxPuAVAlmxm0M81IqGcj/1
5P4xOXAjdqvPa4Yo77Dz5v3NTdcvAAN9pHcCCT153q94F5BGxQUE1/WuzomVG0r8
uRy2yQ6FzwPGXXE4pDro6V1w8io+WNyUV62rAZESKE/r2io+CqWcFqGOTV7Pvvo=
=jWel
-END PGP SIGNATURE-

Bug#842177: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 27/11/2016 à 23:52 :
> On 27/11/16 23:21, Gilles Filippini wrote:
>> Hi,
>>
>> Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>>>> Yes, this is looking very good, so I'm acking it. But please don't upload 
>>>>> just
>>>>> yet, I'll give you the go in a few days when things are a bit calmer 
>>>>> (there are
>>>>> just too many transitions at the moment).
>>
>> Any news on this side? I'm waiting after the transition to upload a new
>> release of the package which will have to go through the NEW queue
>> because of new binary packages for the java bindings.
> 
> Go ahead.

Release 1.10.0-patch1+docs-1 uploaded to unstable.
Thanks!

_g.




signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Hi,

Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>> Yes, this is looking very good, so I'm acking it. But please don't upload 
>>> just
>>> yet, I'll give you the go in a few days when things are a bit calmer (there 
>>> are
>>> just too many transitions at the moment).

Any news on this side? I'm waiting after the transition to upload a new
release of the package which will have to go through the NEW queue
because of new binary packages for the java bindings.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#845270: jython: /usr/bin/jython sets broken python.home property

[Gilles Filippini]

On Tue, 22 Nov 2016 00:03:48 +0100 Gilles Filippini <p...@debian.org> wrote:
> Package: jython
> Version: 2.5.3-11
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> /usr/bin/jython should set python.home = '/usr/share/jython', but it uses 
> dirname(dirname($0)) instead, which returns '/usr'.
> 
> This setting comes from #705146, to support virtualenv. But it is incorrect 
> when jython is launched directly: it then fails to found its system-wide 
> registry at ${python.home}/registry.
> 
> A setting compatible with both use cases would be:
> * install the jython launcher into /usr/share/jython/bin
> * make /usr/bin/jython a symlink to /usr/share/jython/bin/jython
> * replace dirname(dirname($0)) with dirname(dirname(abs_path($0)))

I intend to team-upload this change in a few days if you don't object.
Please let me know.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#845360: jython: the default cachedir path should be set at the library intialization step

[Gilles Filippini]

Package: jython
Version: 2.5.3-11
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The jython launcher currently forces the cachedir to $HOME/.jython-cache. But 
when the library is used directly the cachedir is still set from the upstream 
default in src/org/python/core/PySystemState.java:
 protected static final String CACHEDIR_DEFAULT_NAME = "cachedir";
Which results in the non-writable path /usr/share/jython/cachedir.

I think it would be more consistent to change the default directly into the 
PySystemState class and drop the corresponding configuration from the launcher.

Please see the attached patch proposal. I'm willing to team-upload it in a few 
days, unless you object.

thanks,

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

Kernel: Linux 4.7.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-

iQEcBAEBCAAGBQJYNJlRAAoJEO/obGx//s+DjpgH/3cSm00TLH4+AhQ/Slv5PpGb
1nunZGfS/sBsKPezfGayNhezZCiWE+BFjUyi8ErL/Gb7hiHEGDGdBZYanJcAgQc8
XzyoIvXdVn3UuoZ0Uwlic5EMGNdgh/8uZNVs/ZhommZHs+VxuDDjATP0IAZ2pPhY
wH13hX4amZ7LVliTbKoCV6Wip4cookjdROyxvf5Q7sMVIpdZA6hWtc5RdczONF0j
cgXjnwWEc3aZEw6yEk12ZMcsEY40HmrE9lRtHL6AqPXj0ZUhvX+Lrt5HlgxfRf7m
QsFJz85HID0ZxCJCqCkIed13IuQ7xxWaHo1N9Hoeh/tU3Wok4FbK7vLwnxLrpb8=
=D7MZ
-END PGP SIGNATURE-
diff -Nru jython-2.5.3/debian/changelog jython-2.5.3/debian/changelog
--- jython-2.5.3/debian/changelog	2016-11-07 14:36:32.0 +0100
+++ jython-2.5.3/debian/changelog	2016-11-22 01:38:42.0 +0100
@@ -1,3 +1,12 @@
+jython (2.5.3-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch 03-default-cachedir.patch: the Debian default cachedir
+path is now set at the library intialization step, so that it works
+for every use case
+
+ -- Gilles Filippini <p...@debian.org>  Tue, 22 Nov 2016 00:34:43 +0100
+
 jython (2.5.3-11) unstable; urgency=medium
 
   * Team upload.
diff -Nru jython-2.5.3/debian/jython_perl jython-2.5.3/debian/jython_perl
--- jython-2.5.3/debian/jython_perl	2015-12-21 15:05:26.0 +0100
+++ jython-2.5.3/debian/jython_perl	2016-11-22 01:33:37.0 +0100
@@ -92,21 +92,6 @@
 # Decide upon the python path.
 my $jythonPath = "/usr/lib/site-python:/usr/share/jython/Lib";
 
-# Set up the cache directory.
-#
-my $cacheDir = "$home/.jython-cache";
-if (-e $cacheDir and ! -d $cacheDir) {
-	# The expected cache directory exists but is not a directory.
-	# Use a temporary directory instead.
-	$cacheDir = `mktemp -dt jython-cache.XX` or
-		bail("Could not create temporary cache directory.");
-	chomp $cacheDir;
-}
-if (! -e $cacheDir) {
-	# Create a new cache directory.
-	mkdir $cacheDir or bail("Could not create cache directory $cacheDir.");
-}
-
 # We will build up a JNI library path from various places.
 #
 my $jniPath = '';
@@ -160,7 +145,6 @@
 push @fullCommandLine, "-Dpython.home=$jythonHome";
 push @fullCommandLine, "-Dpython.path=$jythonPath";
 push @fullCommandLine, "-Dpython.executable=$0";
-push @fullCommandLine, "-Dpython.cachedir=$cacheDir";
 push @fullCommandLine, "-Dpython.console=org.python.util.ReadlineConsole";
 push @fullCommandLine, "-Dpython.console.readlinelib=Editline";
 $ENV{CALLED_FROM_JYTHONC} and
diff -Nru jython-2.5.3/debian/jython.README.Debian jython-2.5.3/debian/jython.README.Debian
--- jython-2.5.3/debian/jython.README.Debian	2015-07-23 14:00:44.0 +0200
+++ jython-2.5.3/debian/jython.README.Debian	2016-11-22 01:42:00.0 +0100
@@ -7,6 +7,9 @@
 Consult the jython(1) man page for details about invocation
 of the Jython interpreter.
 
+On Debian, the default jython cachedir path is set to
+${user.home}/.jython-cache instead of ${python.home}/cachedir.
+
 The Jython API is provided by the jython-doc package in
 /usr/share/doc/jython-doc.
 
diff -Nru jython-2.5.3/debian/patches/03-default-cachedir.patch jython-2.5.3/debian/patches/03-default-cachedir.patch
--- jython-2.5.3/debian/patches/03-default-cachedir.patch	1970-01-01 01:00:00.0 +0100
+++ jython-2.5.3/debian/patches/03-default-cachedir.patch	2016-11-22 19:30:04.0 +0100
@@ -0,0 +1,14 @@
+Index: jython-2.5.3/src/org/python/core/PySystemState.java
+===
+--- jython-2.5.3.orig/src/org/python/core/PySystemState.java
 jython-2.5.3/src/org/python/core/PySystemState.java
+@@ -46,7 +46,8 @@ public class PySystemState extends PyObj
+ public static final String PYTHON_CACHEDIR = "python.cachedir";
+ public static final String PYTHON_CACHEDIR_SKIP = "python.cachedir.skip";
+ public static final String PYTHON_CONSOLE_ENCODING 

Bug#845270: jython: /usr/bin/jython sets broken python.home property

[Gilles Filippini]

Package: jython
Version: 2.5.3-11
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

/usr/bin/jython should set python.home = '/usr/share/jython', but it uses 
dirname(dirname($0)) instead, which returns '/usr'.

This setting comes from #705146, to support virtualenv. But it is incorrect 
when jython is launched directly: it then fails to found its system-wide 
registry at ${python.home}/registry.

A setting compatible with both use cases would be:
* install the jython launcher into /usr/share/jython/bin
* make /usr/bin/jython a symlink to /usr/share/jython/bin/jython
* replace dirname(dirname($0)) with dirname(dirname(abs_path($0)))

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

Versions of packages jython depends on:
ii  antlr3.2 3.2-14
ii  default-jre-headless [java5-runtime-headless]2:1.8-57
ii  libasm3-java 3.3.2-3
ii  libguava-java19.0-1
ii  libjffi-java 1.2.7-10
ii  libjline-java1.0-2
ii  libjnr-constants-java0.8.6-8
ii  libjnr-netdb-java1.1.6-1
ii  libjnr-posix-java3.0.12-2
ii  libjnr-x86asm-java   1.0.2-5
ii  liblivetribe-jsr223-java 2.0.6-1
ii  libreadline-java 0.8.0.1+dfsg-4+b2
ii  openjdk-8-jre-headless [java5-runtime-headless]  8u111-b14-2
pn  python:any   

Versions of packages jython recommends:
ii  default-jdk2:1.8-57
ii  openjdk-8-jdk [java-compiler]  8u111-b14-2

Versions of packages jython suggests:
ii  jython-doc   2.5.3-11
pn  libmysql-java
pn  libpostgresql-jdbc-java  

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYM31KAAoJEO/obGx//s+D0PIH/37YT3SoxBmYdgKvIuE03z7N
CGtwNrFjR0jaUwj3gLtbPntK8NvKpeFbLAorMJi0owSvOZVRiFCFH3TSTjfOmN3x
gGm93OW/s/jyYWv5VR/5CxOJLg9evmU31/4w/Wii8tRm9mnvNgWiVbSfAXYZ/pd7
caj8LPsty7BqMn/bC9pL7Km0f3UKYuVtwusfYSDqeH1KNeM1Eyc+SQ0D8HPIx9IE
NpaXGNNAofgyZpIqLrH9xzQlcGo4TXSrAUkKksBOe1OpInM0jjVhlnzoP8s2wH6X
m5PkXoqtshM95/C+aeyYdVdxuqAtA+meUMonS0cONrD5gKX+nMDnqlnk6u9hD0M=
=8Na/
-END PGP SIGNATURE-

Bug#844760: fastqc: Please temporarily drop support for fast5 files

[Gilles Filippini]

Source: fastqc
Version: 0.11.5+dfsg-4
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

HDF5 1.10 is about to transition into unstable [1], and unfortunately a
FastQC build-dependency, libsis-jhdf5-java, doesn't support this new
release yet [2], and we have no information about its upstream schedule
wrt HDF5 1.10.

I've had a look at the FastQC code, and AFAIUI, libsis-jhdf5-java is
required only to support fast5 files from nanopore sequences.

Since these files can easily be converted to FastQ format using
poretools [3], I propose to temporarily drop fast5 support from FastQC
to avoid a removal from testing.

Please find attached a patch proposal to this end.

Thanks in advance,

_g.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842177#40
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842815
{3] https://bioinfoexpert.com/2016/06/15/minion-fast5-to-fastq/

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYL03KAAoJEO/obGx//s+D0uAH/3dDwjK+eAjV5lrCu7sa17rR
RFVYrJMhpnwwgH3q4cNHPvcHeyYZYwyC7WZMw++RWOIEDOlp04KeTkXNhW0/nlt+
FYlGwc1PjHnKUVVy3oyJBTeHnydHU0gP2qNkndvGtrxTjhsIT2toxU3gR+1Z86OI
iW7UAxmuhBoOF3rqYUb9pevRVQjOu8ikrG5ExS7Lg1Fk4TKu00IjaiqvppndoqPO
dsahyQkorSn+Rw0qQFxO4COBZVx5cMsFgIqa+QVvEhSw1Muw/x1S4m2NSfOsM9wQ
H2S3vIrbeDYuyI7ACZSfqHlOsuxVi8v6Y50kZqo0eGZM3km1z5r/cJHqalKt7hI=
=yCAp
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index aeba166..20d6f39 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+fastqc (0.11.5+dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch drop-fast5.patch to temporarily drop support for fast5
+file format. This way we can drop the build-dependency on
+libsis-jhdf5-java which doesn't support HDF5 1.10 yet (#842815).
+fast5 files can easily be converted to fastq using poretools.
+
+ -- Gilles Filippini <p...@debian.org>  Fri, 18 Nov 2016 19:03:15 +0100
+
 fastqc (0.11.5+dfsg-4) unstable; urgency=low
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 7fa5f02..9cd7223 100644
--- a/debian/control
+++ b/debian/control
@@ -11,8 +11,7 @@ Build-Depends: debhelper (>= 9),
ant,
libhtsjdk-java,
libjbzip2-java,
-   libcommons-math3-java,
-   libsis-jhdf5-java
+   libcommons-math3-java
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/fastqc.git
 Vcs-Git: https://anonscm.debian.org/git/debian-med/fastqc.git
diff --git a/debian/patches/drop-fast5.patch b/debian/patches/drop-fast5.patch
new file mode 100644
index 000..f9a0cf6
--- /dev/null
+++ b/debian/patches/drop-fast5.patch
@@ -0,0 +1,151 @@
+Index: fastqc/fastqc
+===
+--- fastqc.orig/fastqc
 fastqc/fastqc
+@@ -74,7 +74,6 @@ my $quiet;
+ my $nogroup;
+ my $expgroup;
+ my $casava;
+-my $nano;
+ my $nofilter;
+ my $kmer_size;
+ my $temp_directory;
+@@ -91,7 +90,6 @@ my $result = GetOptions('version' => \$v
+ 		'threads=i' => \$threads,
+ 		'kmers=i' => \$kmer_size,
+ 		'casava' => \$casava,
+-		'nano' => \$nano,
+ 		'nofilter' => \$nofilter,
+ 		'contaminants=s' => \$contaminant,
+ 		'adapters=s' => \$adapter,
+@@ -183,10 +181,6 @@ if ($casava) {
+ 	push @java_args ,"-Dfastqc.casava=true";		
+ }
+ 
+-if ($nano) {
+-	push @java_args ,"-Dfastqc.nano=true";		
+-}
+-
+ 
+ if ($nofilter) {
+ 	push @java_args ,"-Dfastqc.nofilter=true";		
+@@ -320,11 +314,6 @@ DESCRIPTION
+ (including being gzipped and ending with .gz) otherwise they
+ won't be grouped together correctly.
+ 
+---nano  Files come from naopore sequences and are in fast5 format. In
+-this mode you can pass in directories to process and the program
+-will take in all fast5 files within those directories and produce
+-a single output file from the sequences found in all files.
+-
+ --nofilter  If running with --casava then don't remove read flagged by
+ casava as poor quality when performing the QC analysis.
+
+Index: fastqc/uk/ac/babraham/FastQC/Sequence/SequenceFactory.java
+===
+--- fastqc.orig/uk/ac/babraham/FastQC/Sequence/SequenceFactory.java
 fastqc/uk/ac/babraham/FastQC/Sequence/SequenceFactory.java
+@@ -99,9 +99,6 @@ public class SequenceFactory {
+ 			// We default to using all reads
+ 			return new BAMFile(file,false);
+ 		}
+-		else if (file.getName().toLowerCase().endsWith(".fast5")) {
+-			return new Fast5File(file);
+-		}
+ 		else {
+ 			return new FastQFile(config,file);
+ 		}
+Index: fastqc/uk/ac/babraham/FastQC/Sequence/Fast5File.java
+==

Bug#842815: closed by Andreas Tille <ti...@debian.org> (Bug#842815: fixed in libsis-jhdf5-java 14.12.6-1)

[Gilles Filippini]

On Mon, 14 Nov 2016 22:15:18 +0100 Gilles Filippini <p...@debian.org> wrote:
> Control: reopen -1
> 
> Andreas Tille a écrit le 14/11/2016 à 21:15 :
> > Hi Gilles,
> > 
> > On Mon, Nov 14, 2016 at 07:32:04PM +0100, Gilles Filippini wrote:
> >> Debian Bug Tracking System a écrit le 14/11/2016 à 16:09 :
> >>> This is an automatic notification regarding your Bug report
> >>> which was filed against the src:libsis-jhdf5-java package:
> >>>
> >>> #842815: libsis-jhdf5-java: Please support HDF5 1.10
> >>>
> >>> It has been closed by Andreas Tille <ti...@debian.org>.
> >>>
> >>> Their explanation is attached below along with your original report.
> >>> If this explanation is unsatisfactory and you have not received a
> >>> better one in a separate message then please contact Andreas Tille 
> >>> <ti...@debian.org> by
> >>> replying to this email.
> >>
> >> Thank you for this upload. Have you tested the build against hdf5-1.10
> >> in experimental?
> > 
> > Hmmm, sorry, no - I just made sure that the *sid* pbuilder environment
> > is instaling hdf5-1.10.
> 
> Ah. The fact that HDF5 1.8.16 builds libhdf5-10 might be confusing. HDF5
> 1.10 builds libhdf5-100 and is still in experimental.
> 
> > If this is not sufficient please reopen ...
> > and please give some helping hint if the package might not build
> > properly.  Otherwise I have no idea what to do - patches are very
> > welcome.
> 
> There are at least 3 majors changes brought by HDF5 1.10:
> 1- The widely used hid_t datatype is now uint64_t (instead of int)
> 2- The java wrapper library is now part of the HDF5 source tree
> 3- HDF5Exception is now a checked exception.
> 
> (2) and (3) might be worked out with a new upload of hdf5, to ship the
> java wrapper library packages, patched to define HDF5Exception as an
> unchecked exception. I'd rather wait after the transition.
> 
> (1) Involves patching libsis-jhdf5-java.

I've spent some time trying to figure it out, and I'm afraid this is a
huge task I can't afford working on.

> The best option would be a new upstream release. Do you know their
> schedule wrt HDF5 1.10?

If there is a risk that libsis-jhdf5-java won't be ready for stretch,
then we could easily avoid the fastqc removal by disabling the fast5
file format support. It should be easy enough for anyone to convert
fast5 files to fastq using e.g. poretools.
What do you think?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842815: closed by Andreas Tille <ti...@debian.org> (Bug#842815: fixed in libsis-jhdf5-java 14.12.6-1)

[Gilles Filippini]

Control: reopen -1

Andreas Tille a écrit le 14/11/2016 à 21:15 :
> Hi Gilles,
> 
> On Mon, Nov 14, 2016 at 07:32:04PM +0100, Gilles Filippini wrote:
>> Debian Bug Tracking System a écrit le 14/11/2016 à 16:09 :
>>> This is an automatic notification regarding your Bug report
>>> which was filed against the src:libsis-jhdf5-java package:
>>>
>>> #842815: libsis-jhdf5-java: Please support HDF5 1.10
>>>
>>> It has been closed by Andreas Tille <ti...@debian.org>.
>>>
>>> Their explanation is attached below along with your original report.
>>> If this explanation is unsatisfactory and you have not received a
>>> better one in a separate message then please contact Andreas Tille 
>>> <ti...@debian.org> by
>>> replying to this email.
>>
>> Thank you for this upload. Have you tested the build against hdf5-1.10
>> in experimental?
> 
> Hmmm, sorry, no - I just made sure that the *sid* pbuilder environment
> is instaling hdf5-1.10.

Ah. The fact that HDF5 1.8.16 builds libhdf5-10 might be confusing. HDF5
1.10 builds libhdf5-100 and is still in experimental.

> If this is not sufficient please reopen ...
> and please give some helping hint if the package might not build
> properly.  Otherwise I have no idea what to do - patches are very
> welcome.

There are at least 3 majors changes brought by HDF5 1.10:
1- The widely used hid_t datatype is now uint64_t (instead of int)
2- The java wrapper library is now part of the HDF5 source tree
3- HDF5Exception is now a checked exception.

(2) and (3) might be worked out with a new upload of hdf5, to ship the
java wrapper library packages, patched to define HDF5Exception as an
unchecked exception. I'd rather wait after the transition.

(1) Involves patching libsis-jhdf5-java.

The best option would be a new upstream release. Do you know their
schedule wrt HDF5 1.10?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842815: closed by Andreas Tille <ti...@debian.org> (Bug#842815: fixed in libsis-jhdf5-java 14.12.6-1)

[Gilles Filippini]

Debian Bug Tracking System a écrit le 14/11/2016 à 16:09 :
> This is an automatic notification regarding your Bug report
> which was filed against the src:libsis-jhdf5-java package:
> 
> #842815: libsis-jhdf5-java: Please support HDF5 1.10
> 
> It has been closed by Andreas Tille .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Andreas Tille 
>  by
> replying to this email.

Hi Andreas,

Thank you for this upload. Have you tested the build against hdf5-1.10
in experimental?

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#843040: c-blosc: diff for NMU version 1.11.1+ds1-2.1

[Gilles Filippini]

Control: tags 8430040 + patch
Control: tags 8430040 + pending

Dear maintainer,

I've prepared an NMU for c-blosc (versioned as 1.11.1+ds1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -Nru c-blosc-1.11.1+ds1/debian/changelog
c-blosc-1.11.1+ds1/debian/changelog
--- c-blosc-1.11.1+ds1/debian/changelog 2016-09-04 13:08:55.0 +0200
+++ c-blosc-1.11.1+ds1/debian/changelog 2016-11-04 11:19:43.0 +0100
@@ -1,3 +1,11 @@
+c-blosc (1.11.1+ds1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch bigendian.patch: fix endianness issue in the bitshuffle
+filter (closes: #8430040)
+
+ -- Gilles Filippini <p...@debian.org>  Fri, 04 Nov 2016 11:19:43 +0100
+
 c-blosc (1.11.1+ds1-2) unstable; urgency=medium
* add preserve-cflags-from-environment.patch.
diff -Nru c-blosc-1.11.1+ds1/debian/patches/bigendian.patch
c-blosc-1.11.1+ds1/debian/patches/bigendian.patch
--- c-blosc-1.11.1+ds1/debian/patches/bigendian.patch   1970-01-01
01:00:00.0 +0100
+++ c-blosc-1.11.1+ds1/debian/patches/bigendian.patch   2016-11-04
02:57:31.0 +0100
@@ -0,0 +1,38 @@
+Index: c-blosc-1.11.1+ds1/blosc/bitshuffle-generic.h
+===
+--- c-blosc-1.11.1+ds1.orig/blosc/bitshuffle-generic.h
 c-blosc-1.11.1+ds1/blosc/bitshuffle-generic.h
+@@ -39,7 +39,14 @@ extern "C" {
+ + /* Transpose 8x8 bit array packed into a single quadword *x*.
+  * *t* is workspace. */
++#ifdef BSHUF_BIGENDIAN
++# include 
++# define BSWAP_64(x) x = bswap_64(x)
++#else
++# define BSWAP_64(x)
++#endif
+ #define TRANS_BIT_8X8(x, t) {
 \
++BSWAP_64(x)
 \
+ t = (x ^ (x >> 7)) & 0x00AA00AA00AA00AALL;
 \
+ x = x ^ t ^ (t << 7);
 \
+ t = (x ^ (x >> 14)) & 0xLL;
 \
+Index: c-blosc-1.11.1+ds1/blosc/CMakeLists.txt
+===
+--- c-blosc-1.11.1+ds1.orig/blosc/CMakeLists.txt
 c-blosc-1.11.1+ds1/blosc/CMakeLists.txt
+@@ -161,6 +161,14 @@ if(COMPILER_SUPPORT_AVX2)
+ APPEND PROPERTY COMPILE_DEFINITIONS SHUFFLE_AVX2_ENABLED)
+ endif(COMPILER_SUPPORT_AVX2)
+ ++INCLUDE(TestBigEndian)
++TEST_BIG_ENDIAN(BIGENDIAN)
++IF(BIGENDIAN)
++set_property(
++SOURCE bitshuffle-generic.c
++APPEND PROPERTY COMPILE_DEFINITIONS BSHUF_BIGENDIAN)
++ENDIF(BIGENDIAN)
++
+ # When the option has been selected to compile the test suite,
+ # compile an additional version of blosc_shared which exports
+ # some normally-hidden symbols (to facilitate unit testing).
diff -Nru c-blosc-1.11.1+ds1/debian/patches/series
c-blosc-1.11.1+ds1/debian/patches/series
--- c-blosc-1.11.1+ds1/debian/patches/series2016-09-04
12:56:02.0 +0200
+++ c-blosc-1.11.1+ds1/debian/patches/series2016-11-04
02:29:44.0 +0100
@@ -1 +1,2 @@
 preserve-cflags-from-environment.patch
+bigendian.patch



signature.asc
Description: OpenPGP digital signature

Bug#833457: hdf5: Please enable packaging of libhdf5-openmpi-dev on hppa arch

[Gilles Filippini]

Control: tags -1 confirmed

On Thu, 4 Aug 2016 17:33:58 +0200 Helge Deller  wrote:
> Package: hdf5
> Version: 1.8.16+docs-8
> Severity: normal
> 
> Can you please re-enable hppa as arch which builds libhdf5-openmpi-dev ?
> It breaks building other packages, and openmpi now builds on hppa (and m68k 
> and sh4).
> 
> The relevant lines in the debian/rules file are:
> ARCH_FLAG=-a
> # openmpi broken on archs hppa m68k sh4 (2016-02-24)
> OMPIARCHS?=any !hppa !m68k !sh4
> MPICHARCHS?=any

Will do after the upcoming hdf5-1.10 transition.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Control: block -1 by 843040 842815

Emilio Pozuelo Monfort a écrit le 05/11/2016 à 17:29 :
> Control: tags -1 confirmed
> 
> On 04/11/16 14:45, Gilles Filippini wrote:
>> Gilles Filippini a écrit le 02/11/2016 à 19:05 :
>>> Hi,
>>>
>>> Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
>>> remainder is:
>>> * shogun  FTBFS unrelated to hdf5 - not in testing - #809290
>>> * tessa   FTBFS unrelated to hdf5 - not in testing - #817690
>>> * aster   FTBFS unrelated to hdf5 - not in testing - #837915
>>> * deal.ii BD uninstallable - not in testing
>>> * odinFTBFS unrelated to hdf5 - not in testing - #835746
>>> * libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
>>>   will need some more time because part of this java wrapper library
>>>   is now shipped with the HDF5 source tree
>>> * yorick-hdf5 #842817 - temporary fix uploaded to experimental
>>> * pytablesalmost done - FTBFS on big endian arches
>>>
>>> IMO the only showstopper is now pytables, which will hopefully resolve
>>> in the coming days.
>>
>> Update:
>> * yorick-hdf5 #842817 - final fix uploaded to experimental
>> * pytablesAffected by #843040 - Tested patch pending
>>
>> There isn't any blocker left but libsis-jhdf5-java which has a very low
>> popcon and no reverse dependencies. Can we agree for a transition slot
>> before the freeze?
> 
> Yes, this is looking very good, so I'm acking it. But please don't upload just
> yet, I'll give you the go in a few days when things are a bit calmer (there 
> are
> just too many transitions at the moment).
> 
> And please mark any remaining bugs as blocking this one.

Done, excepted for the 'not in testing' ones. Unless you'd want these
marked as well?

Thx,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#841959: Problems with your ismrmrd/1.3.2-4.1 NMU

[Gilles Filippini]

On 2016-11-04 15:50, Ghislain Vaillant wrote:

Hi Gilles,

On 01/11/16 17:50, Gilles Filippini wrote:
Could you give me more insight of the compatibility problem with HDF5 
1.10?


The most important change in the HDF5 1.10 release is that the hid_t
type was changed from 'int' to 'long long' [1]. Assuming that hid_t is
int isn't true anymore. Thus the change to the ISMRMRD_Dataset
structure, because the fileid field is actually used as an hid_t. See
for example the ismrmrd_open_dataset() function in libsrc/dataset.c:

int ismrmrd_open_dataset(ISMRMRD_Dataset *dset, const bool
create_if_needed) {
/* TODO add a mode for clobbering the dataset if it exists. */
hid_t fileid;
...
fileid = H5Fopen(dset->filename, H5F_ACC_RDWR, H5P_DEFAULT);

if (fileid > 0) {
dset->fileid = fileid;
}
...


I submitted your patch to a PR upstream for review:

  https://github.com/ismrmrd/ismrmrd/pull/74

Since there were no DEP3 header attached to the patch, I used your
Debian name and email for the commit authorship. I hope this is ok.


No problem. Thank you for the follow up.

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit le 02/11/2016 à 19:05 :
> Hi,
> 
> Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
> remainder is:
> * shogun  FTBFS unrelated to hdf5 - not in testing - #809290
> * tessa   FTBFS unrelated to hdf5 - not in testing - #817690
> * aster   FTBFS unrelated to hdf5 - not in testing - #837915
> * deal.ii BD uninstallable - not in testing
> * odinFTBFS unrelated to hdf5 - not in testing - #835746
> * libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
>   will need some more time because part of this java wrapper library
>   is now shipped with the HDF5 source tree
> * yorick-hdf5 #842817 - temporary fix uploaded to experimental
> * pytablesalmost done - FTBFS on big endian arches
> 
> IMO the only showstopper is now pytables, which will hopefully resolve
> in the coming days.

Update:
* yorick-hdf5 #842817 - final fix uploaded to experimental
* pytablesAffected by #843040 - Tested patch pending

There isn't any blocker left but libsis-jhdf5-java which has a very low
popcon and no reverse dependencies. Can we agree for a transition slot
before the freeze?

Thanks in advance,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#843040: libblosc1: Bitshuffle problems on bigendian architectures

[Gilles Filippini]

Control: tag -1 patch

On Thu, 03 Nov 2016 11:31:07 + Antonio Valentino
<antonio.valent...@tiscali.it> wrote:
> Package: libblosc1
> Version: 1.11.1+ds1-2
> Severity: important
> 
> Dear Maintainer,
> it seems that the c-blosc library has some problems withthe bitshuffle filter 
> on big-endian architectures.
> The problem causes several test failures on the pytables package [1, 2,
> 3]
> when tests are run on mips, s390x and other architectures (all bigendian
> it seems).
> 
> The problem has been reported upstream [4, 5] and it is currently under
> investigation.
> If my understanding is correct a quick fix can be implememted by
> pproperly setting build flags but please refer to the upstream [4] for
> more details.
> 
> [1] https://tracker.debian.org/pkg/pytables
> [2] https://buildd.debian.org/status/package.php?p=pytables
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=pytables=mips=3.3.0-3=1478077059
> [4] https://github.com/Blosc/c-blosc/issues/181
> [5] https://github.com/PyTables/PyTables/issues/583

Please find attached a patch proposal from upsrtream ticket [1].

[1] https://github.com/Blosc/c-blosc/issues/181#issuecomment-258326947

Thanks,

_g.
diff -Nru c-blosc-1.11.1+ds1/debian/changelog 
c-blosc-1.11.1+ds1/debian/changelog
--- c-blosc-1.11.1+ds1/debian/changelog 2016-09-04 13:08:55.0 +0200
+++ c-blosc-1.11.1+ds1/debian/changelog 2016-11-04 11:19:43.0 +0100
@@ -1,3 +1,11 @@
+c-blosc (1.11.1+ds1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch bigendian.patch: fix endianness issue in the bitshuffle
+filter (closes: #8430040)
+
+ -- Gilles Filippini <p...@debian.org>  Fri, 04 Nov 2016 11:19:43 +0100
+
 c-blosc (1.11.1+ds1-2) unstable; urgency=medium
 
   * add preserve-cflags-from-environment.patch.
diff -Nru c-blosc-1.11.1+ds1/debian/patches/bigendian.patch 
c-blosc-1.11.1+ds1/debian/patches/bigendian.patch
--- c-blosc-1.11.1+ds1/debian/patches/bigendian.patch   1970-01-01 
01:00:00.0 +0100
+++ c-blosc-1.11.1+ds1/debian/patches/bigendian.patch   2016-11-04 
02:57:31.0 +0100
@@ -0,0 +1,38 @@
+Index: c-blosc-1.11.1+ds1/blosc/bitshuffle-generic.h
+===
+--- c-blosc-1.11.1+ds1.orig/blosc/bitshuffle-generic.h
 c-blosc-1.11.1+ds1/blosc/bitshuffle-generic.h
+@@ -39,7 +39,14 @@ extern "C" {
+ 
+ /* Transpose 8x8 bit array packed into a single quadword *x*.
+  * *t* is workspace. */
++#ifdef BSHUF_BIGENDIAN
++# include 
++# define BSWAP_64(x) x = bswap_64(x)
++#else
++# define BSWAP_64(x)
++#endif
+ #define TRANS_BIT_8X8(x, t) {   \
++BSWAP_64(x) \
+ t = (x ^ (x >> 7)) & 0x00AA00AA00AA00AALL;  \
+ x = x ^ t ^ (t << 7);   \
+ t = (x ^ (x >> 14)) & 0xLL; \
+Index: c-blosc-1.11.1+ds1/blosc/CMakeLists.txt
+===
+--- c-blosc-1.11.1+ds1.orig/blosc/CMakeLists.txt
 c-blosc-1.11.1+ds1/blosc/CMakeLists.txt
+@@ -161,6 +161,14 @@ if(COMPILER_SUPPORT_AVX2)
+ APPEND PROPERTY COMPILE_DEFINITIONS SHUFFLE_AVX2_ENABLED)
+ endif(COMPILER_SUPPORT_AVX2)
+ 
++INCLUDE(TestBigEndian)
++TEST_BIG_ENDIAN(BIGENDIAN)
++IF(BIGENDIAN)
++set_property(
++SOURCE bitshuffle-generic.c
++APPEND PROPERTY COMPILE_DEFINITIONS BSHUF_BIGENDIAN)
++ENDIF(BIGENDIAN)
++
+ # When the option has been selected to compile the test suite,
+ # compile an additional version of blosc_shared which exports
+ # some normally-hidden symbols (to facilitate unit testing).
diff -Nru c-blosc-1.11.1+ds1/debian/patches/series 
c-blosc-1.11.1+ds1/debian/patches/series
--- c-blosc-1.11.1+ds1/debian/patches/series2016-09-04 12:56:02.0 
+0200
+++ c-blosc-1.11.1+ds1/debian/patches/series2016-11-04 02:29:44.0 
+0100
@@ -1 +1,2 @@
 preserve-cflags-from-environment.patch
+bigendian.patch


signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Hi,

Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
remainder is:
* shogun  FTBFS unrelated to hdf5 - not in testing - #809290
* tessa   FTBFS unrelated to hdf5 - not in testing - #817690
* aster   FTBFS unrelated to hdf5 - not in testing - #837915
* deal.ii BD uninstallable - not in testing
* odinFTBFS unrelated to hdf5 - not in testing - #835746
* libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
  will need some more time because part of this java wrapper library
  is now shipped with the HDF5 source tree
* yorick-hdf5 #842817 - temporary fix uploaded to experimental
* pytablesalmost done - FTBFS on big endian arches

IMO the only showstopper is now pytables, which will hopefully resolve
in the coming days.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842817: yorick-hdf5: FTBFS against HDF5 v1.10

[Gilles Filippini]

On 2016-11-02 13:46, Thibaut Paumard wrote:

Le 02/11/2016 à 10:30, Gilles Filippini a écrit :



Yes, this plan (quick hack + temporarily disabling tests on other
archs) sounds sensible.


Dear Gilles,

I uploaded the hacked version(0.8.0-6) to experimental
(build-depending on hdf5-dev 1.10). It built successfully on several
architectures, include 64-bit and 32 bit ones.

I guess you can claim this package will not prevent the transition.
https://buildd.debian.org/status/package.php?p=yorick-hdf5=experim
ental

I also started working on the real fix.


Thanks a lot, Thibaut!

_g.

Bug#842817: yorick-hdf5: FTBFS against HDF5 v1.10

[Gilles Filippini]

Hi Thibaut,

On 2016-11-02 09:04, Thibaut Paumard wrote:

The "long" type is 64-bit on 64-bit arches. My quick hack works only
on these. The proper fix is more involving: I have to create a custom,
opaque data type that will hold the actual hid_t.

However, overloading the comparison operator for this custom type is
not easy, so I would have to provide an API to check for the validity
of an id, and use that in the interpreted part of the code instead of
"id>=0".

I guess you are targeting the transition freeze on Friday? I don't
think I can make it. I could upload the quick hack to get this fixed
for the 64-bit arches and disable the tests on the other arches (or
get yorick-hdf5 removed from them, but that would also require an
upload of Yorick, which has a meta package that depends on
yorick-hdf5). Then I would have more time to fix yorick-hdf5 before
the hard freeze.


Yes, this plan (quick hack + temporarily disabling tests on other archs) 
sounds sensible.


Thanks,

_g.

Bug#842817: yorick-hdf5: FTBFS against HDF5 v1.10

[Gilles Filippini]

Hi Thibaut,

Thibaut Paumard a écrit le 01/11/2016 à 22:51 :
> Thanks Gilles.
> 
> This is due to hid_t changing from 32bit to 64bit and mapping that to
> the correct integer type in Yorick.
> 
> I managed a quick fix, need a little more time to upload it.

Thanks for the follow-up. I'm curious how you fix it, because as I
understand it, yorick doesn't support 64 bits integers o_O

Regards,

_g.

> 
> Regards, Thibaut.
> 
> Le 01/11/2016 à 14:16, Gilles Filippini a écrit :
>> Source: yorick-hdf5
>> Version: 0.8.0-5
>> Severity: important
>>
>> Hi,
>>
>> yorick-hdf5 FTBFS againt HDF5 v1.10 currently in experimental:
>>
>>dh_auto_test
>> make -j1 check
>> make[1]: Entering directory '/<>'
>> /usr/lib/yorick/bin/yorick -batch check.i
>>  Creating data.h5 with data
>> ERROR (h5write) Unable to create group
>>   LINE: 785  FILE: /<>/hdf5.i
>> yorick: quitting on error in batch mode
>> /usr/lib/yorick/Makepkg:159: recipe for target 'check-dll' failed
>> make[1]: *** [check-dll] Error 1
>> make[1]: Leaving directory '/<>'
>> dh_auto_test: make -j1 check returned exit code 2
>> debian/rules:9: recipe for target 'build' failed
>> make: *** [build] Error 2
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>>
>> Full build log attached.
>>
>> 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.7.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)
>>
>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Bug#842881: libmpich12: extraneous - and possibly wrong - symbolic link: /usr/lib/libmpich.so.12 -> libmpi.so

[Gilles Filippini]

Package: libmpich12
Version: 3.2-7
Severity: serious
Justification: make other packages FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I've just experienced a weird FTBFS on hdf5 on my box, caused by an
extraneous symlink:
/usr/lib/libmpich.so.12 -> libmpi.so

Steps to reproduce:
1- Start from an unstable sbuild chroot
2- apt-get install libmpich-dev
3- apt-get install libopenmpi-dev

Result:
/usr/lib/libmpich.so.12 -> libmpi.so
/usr/lib/libmpi.so -> /etc/alternatives/libmpi.so
/etc/alternatives/libmpi.so -> /usr/lib/openmpi/lib/libmpi.so
/usr/lib/openmpi/lib/libmpi.so -> libmpi.so.20.0.1

In other words, /usr/lib/libmpich.so.12 is a symlink to
/usr/lib/openmpi/lib/libmpi.so.20.0.1 from libopenmpi2.

This link is created by ldconfig if and only if /usr/lib/libmpi.so
exists:
1- Start again from an unstable sbuild chroot
2- apt-get install libmpich12
   => no /usr/lib/libmpich.so.12 symlink
3- apt-get install libmpich-dev
   => still no /usr/lib/libmpich.so.12 symlink
4- ldconfig -v | grep changed
libmpich.so.12 -> libmpi.so (changed)
libmpichcxx.so.12 -> libmpicxx.so (changed)
libmpichfort.so.12 -> libmpif90.so (changed)

I have no idea how to solve this problem :/

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

iQEcBAEBCAAGBQJYGT3hAAoJEO/obGx//s+D5zQH/R9TUA/zyUMgmDugJr5sI36h
C4DMVbFuv4a6yOb9wR4x5w6JEpmOUrK9++bUWRcwUCQwRgZqjBx1mQL/7hzpHNcd
xb1rRl3et4WBxrPoHzZKqXlN6Hdg+NBGNG+bTpFN/D4vJV4wOJyoX94USp//UcnP
6pUO/GoRLR71aKbs21sf3VrENPPdyOBWLSGljPaQZsU8Uj3GozVX6HLSokz1rFU/
7PRY+I6tOpv53IhpbBLbn+1p/rSnpXYIgkZIHgnPiGxGU0qUjimH2SEwOpVO404g
tTIfosLClvRlNTo66JZH1KRjHdxBI7NYvvVIufKpnjh9PN7y8aBgqq3ER9n/hIQ=
=wGnc
-END PGP SIGNATURE-

Bug#841959: Problems with your ismrmrd/1.3.2-4.1 NMU

[Gilles Filippini]

Hi Ghislain,

Ghislain Vaillant a écrit le 01/11/2016 à 17:13 :
> Thanks for dealing with the HDF 1.10 compatibility for ismrmrd whilst I
> was away. I did not have the opportunity to look at your patch before
> your submission today. That's unfortunate, as there are a couple of
> problems with it.
> 
> First, you changed the API by modifying the ISMRMRD_Dataset structure,
> which upstream might not be so happy about.

Sorry about that. See below for the axplanation.

> Then, the introduction of hid_t and resulting dependency on the hdf5
> header was not reflected on the install dependencies of the
> libismrmrd-dev package, which broke the packaging CI testing. A trial
> build on debomatic would have probably caught it.

I've experienced repeated random failures using debomatic in the past.

> Could you give me more insight of the compatibility problem with HDF5 1.10?

The most important change in the HDF5 1.10 release is that the hid_t
type was changed from 'int' to 'long long' [1]. Assuming that hid_t is
int isn't true anymore. Thus the change to the ISMRMRD_Dataset
structure, because the fileid field is actually used as an hid_t. See
for example the ismrmrd_open_dataset() function in libsrc/dataset.c:

int ismrmrd_open_dataset(ISMRMRD_Dataset *dset, const bool
create_if_needed) {
/* TODO add a mode for clobbering the dataset if it exists. */
hid_t fileid;
...
fileid = H5Fopen(dset->filename, H5F_ACC_RDWR, H5P_DEFAULT);

if (fileid > 0) {
dset->fileid = fileid;
}
...

I can see two solutions:
1- make libismrmrd-dev depend on libhdf5-dev
2- set fileid as type long long to avoid including hdf5.h

What do you think?

[1]


Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842817: yorick-hdf5: FTBFS against HDF5 v1.10

[Gilles Filippini]

Source: yorick-hdf5
Version: 0.8.0-5
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

yorick-hdf5 FTBFS againt HDF5 v1.10 currently in experimental:

   dh_auto_test
make -j1 check
make[1]: Entering directory '/<>'
/usr/lib/yorick/bin/yorick -batch check.i
 Creating data.h5 with data
ERROR (h5write) Unable to create group
  LINE: 785  FILE: /<>/hdf5.i
yorick: quitting on error in batch mode
/usr/lib/yorick/Makepkg:159: recipe for target 'check-dll' failed
make[1]: *** [check-dll] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:9: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Full build log attached.

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

iQEcBAEBCAAGBQJYGJWQAAoJEO/obGx//s+D3EIIAJ7dIPUwPnsJYnGnTlEdrcSG
17N5/LC7PsDe88jlmdQdPC7ImLhXn+X1E1xVxoQerJMPDr8gZrX6z/KmoKPmbxsF
T/E7hkFy4twW1Fa5EU7uBm4y+TKy8MUmvOb48SvEYzEWH6ueFWkUDeyvBag21pJh
kyd5leL/L5r1MAayoOPnSX7bTzu0RI9BwvDuyJv28lVMozMCdjwqM7OiEurVQVzf
sfZvVHXCZLBnUHGjlPwv6ACf1GheWniQPlPoVRCbrzgNUrtyUgw0GA3iKvOT2prS
kvkay/ShRGbOzODt2gI9HpCp6wplvPPI4andyYB4X1U3Q0KrTDsSYpZ2042ApM0=
=/WU5
-END PGP SIGNATURE-


yorick-hdf5_0.8.0-5_amd64.build.gz
Description: application/gzip

Bug#842815: libsis-jhdf5-java: Please support HDF5 1.10

[Gilles Filippini]

Source: libsis-jhdf5-java
Version: 14.12.1-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

libsis-jhdf5-java FTBFS against hdf5-1.10 currently in experimental:

===
All
Total tests run: 309, Failures: 279, Skips: 6
===

[Utils] Attempting to create /<>/test-output/old/All/toc.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create /<>/test-output/old/All/All.properties
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create /<>/test-output/old/All/index.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create /<>/test-output/old/All/main.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create /<>/test-output/old/All/groups.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create /<>/test-output/old/All/classes.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create 
/<>/test-output/old/All/reporter-output.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create 
/<>/test-output/old/All/methods-not-run.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create 
/<>/test-output/old/All/testng.xml.html
[Utils]   Directory /<>/test-output/old/All exists: true
[Utils] Attempting to create test-output/old/index.html
[Utils]   Directory test-output/old exists: true
[TestNG] Time taken by org.testng.reporters.SuiteHTMLReporter@156643d4: 83 ms
[TestNG] Time taken by org.testng.reporters.EmailableReporter2@7d6f77cc: 37 ms
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.HDF5TimeDurationReaderTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.HDF5UtilsTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.h5ar.DirectoryIndexUpdaterTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.UnsignedIntUtilsTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.io.HDF5DataSetRandomAccessFileTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.HDF5RoundtripTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.BitSetConversionTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.HDF5TimeUnitTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.h5ar.UtilsTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.h5ar.ArchivingStrategyTest.xml
[Utils]   Directory test-output/junitreports exists: true
[Utils] Attempting to create 
test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.MatrixUtilsTest.xml
[Utils]   Directory test-output/junitreports exists: true
[TestNG] Time taken by org.testng.reporters.JUnitReportReporter@6f75e721: 44 ms
[Utils] Attempting to create test-output/testng-failed.xml
[Utils]   Directory test-output exists: true
[Utils] Attempting to create /<>/test-output/All/testng-failed.xml
[Utils]   Directory /<>/test-output/All exists: true
[TestNG] Time taken by [FailedReporter passed=0 failed=0 skipped=0]: 17 ms
[TestNG] Time taken by org.testng.reporters.XMLReporter@41a4555e: 65 ms
[TestNG] Time taken by org.testng.reporters.jq.Main@1175e2db: 62 ms
debian/rules:46: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 3
make[1]: Leaving directory '/<>'
debian/rules:16: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Full build log attached.

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

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-28 14:12, Gilles Filippini wrote:

Status update:
insighttoolkit4: hdf5 libmincpatch provided via #842342


And:
ants: hdf5 insighttoolkit4OK

There is only pytables remaining on the way now

Thanks,

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-26 19:12, Gilles Filippini wrote:

On 2016-10-26 19:03, Sebastiaan Couwenberg wrote:

On 10/26/2016 06:46 PM, Gilles Filippini wrote:
I've checked the build of every reverse dependencies. These few ones 
are of concern:

* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no 
reverse dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon 
about 300 - no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - 
rather low popcon
* ants : in progress; build depends on insighttoolkit4 - raher low 
popcon


From the above packages, the only real concern is pytables. A 
discussion is ongoing on debian-science@d.o, and I'm confident we'll 
find a solution before the Stretch freeze.


pytables does have several reverse dependencies, who in turn have
several reverse dependencies too. pytables in the dependency chain of
geopandas, having it removed from stretch would be very sad.


Ooops, sorry, I didn't noticed that. Actually I checked weeks ago and
didn't remember there were reverse depends. My bad.
But as said above, I'm confident we'll find a solution for pytables
before the Strtch freeze. It would be removed from testing only for a
while.


insighttoolkit4 is in the dependency chain of otb, and like pytables
having it removed from stretch would be very sad. Even more than 
pytables.


I've successfully tested today a full insighttoolkit4 build for
unstable on a stronger box than mine. I'll rebuild tomorrow against
hdf5-1.10. I'm rather confident about this one too.


Status update:
insighttoolkit4: hdf5 libmincpatch provided via #842342

Thanks,

_g.

Bug#842342: insighttoolkit4: Pease support building against HDF5 1.10

[Gilles Filippini]

Source: insighttoolkit4
Version: 4.10.1-dfsg1-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.
Upstream bug report: https://issues.itk.org/jira/browse/ITK-3484

Thanks,

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

Kernel: Linux 4.7.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-

iQEcBAEBCAAGBQJYExEgAAoJEO/obGx//s+DbxUH/3uCI1HADDL34Fb724BqkL5f
q8+nOpooNLuHg3fuFhFxzWrAI+UFItxacjXiZ77hb/UxpzDRjl2yKuMThtdB7fka
DHcWfEpZRGR2DkFKboKnt2ZSgHQxwCaD/GfN8Rzf7xE6niCKXO1eRrr+aO2Ob84y
XmRAh82S8NuDN94AqnseG3IVt77GPI+okPPzb9ZtVmAR2mHdOk23WvS+8TAJK7o8
S0C7SmCG+gIisVeuOEXopousHNTm4U8ZCy4ilfxRiPctBD2F8bWZvoHFZJTDM1DE
fyvFxixrZ+tFtjkUA49zGVbUHCHPxsNb4opGdE68xqynuZ0U15Wu6xH/JtXo3Pk=
=/vP0
-END PGP SIGNATURE-
diff -Nru insighttoolkit4-4.10.1-dfsg1/debian/changelog insighttoolkit4-4.10.1-dfsg1/debian/changelog
--- insighttoolkit4-4.10.1-dfsg1/debian/changelog	2016-10-12 13:42:21.0 +0200
+++ insighttoolkit4-4.10.1-dfsg1/debian/changelog	2016-10-28 10:13:14.0 +0200
@@ -1,3 +1,10 @@
+insighttoolkit4 (4.10.1-dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch to support HDF5 1.10
+
+ -- Gilles Filippini <p...@debian.org>  Fri, 28 Oct 2016 10:12:49 +0200
+
 insighttoolkit4 (4.10.1-dfsg1-1) unstable; urgency=medium
 
   * New upstream version 
diff -Nru insighttoolkit4-4.10.1-dfsg1/debian/patches/hdf5-1.10.patch insighttoolkit4-4.10.1-dfsg1/debian/patches/hdf5-1.10.patch
--- insighttoolkit4-4.10.1-dfsg1/debian/patches/hdf5-1.10.patch	1970-01-01 01:00:00.0 +0100
+++ insighttoolkit4-4.10.1-dfsg1/debian/patches/hdf5-1.10.patch	2016-10-28 10:11:47.0 +0200
@@ -0,0 +1,99 @@
+Index: insighttoolkit4-4.10.1-dfsg1/Modules/IO/HDF5/src/itkHDF5ImageIO.cxx
+===
+--- insighttoolkit4-4.10.1-dfsg1.orig/Modules/IO/HDF5/src/itkHDF5ImageIO.cxx
 insighttoolkit4-4.10.1-dfsg1/Modules/IO/HDF5/src/itkHDF5ImageIO.cxx
+@@ -305,6 +305,8 @@ HDF5ImageIO
+   hsize_t numScalars(1);
+   H5::DataSpace scalarSpace(1,);
+   H5::PredType scalarType =
++H5::PredType::NATIVE_INT;
++  H5::PredType attrType =
+ H5::PredType::NATIVE_HBOOL;
+   H5::DataSet scalarSet =
+ this->m_H5File->createDataSet(path,
+@@ -318,10 +320,10 @@ HDF5ImageIO
+   const std::string isLongName("isLong");
+   H5::Attribute isLong =
+ scalarSet.createAttribute(isLongName,
+-   scalarType,
++   attrType,
+scalarSpace);
+   bool trueVal(true);
+-  isLong.write(scalarType,);
++  isLong.write(attrType,);
+   isLong.close();
+   int tempVal = static_cast(value);
+   scalarSet.write(,scalarType);
+@@ -336,6 +338,8 @@ HDF5ImageIO
+   hsize_t numScalars(1);
+   H5::DataSpace scalarSpace(1,);
+   H5::PredType scalarType =
++H5::PredType::NATIVE_UINT;
++  H5::PredType attrType =
+ H5::PredType::NATIVE_HBOOL;
+   H5::DataSet scalarSet =
+ this->m_H5File->createDataSet(path,
+@@ -349,10 +353,10 @@ HDF5ImageIO
+   const std::string isUnsignedLongName("isUnsignedLong");
+   H5::Attribute isUnsignedLong =
+ scalarSet.createAttribute(isUnsignedLongName,
+-   scalarType,
++   attrType,
+scalarSpace);
+   bool trueVal(true);
+-  isUnsignedLong.write(scalarType,);
++  isUnsignedLong.write(attrType,);
+   isUnsignedLong.close();
+   int tempVal = static_cast(value);
+   scalarSet.write(,scalarType);
+@@ -840,10 +844,23 @@ HDF5ImageIO
+ }
+   else if(metaDataType == H5::PredType::NATIVE_UCHAR)
+ {
+-this->StoreMetaData(,
+-   localMetaDataName,
+-   name,
+-   metaDataDims[0]);
++if(doesAttrExist(metaDataSet,"isBool"))
++  {
++  // itk::Array apparently can't
++  // happen because vnl_vector isn't
++  // instantiated
++  bool val;
++  int tmpVal = this->ReadScalar(localMetaDataName);
++  val = tmpVal != 0;
++  EncapsulateMetaData(metaDict,name,val);
++  }
++else
++  {
++  this->StoreMetaData(,
++ localMetaDataName,
++ name,
++ metaDataDims[0]);
++  }
+ }
+

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-26 19:03, Sebastiaan Couwenberg wrote:

On 10/26/2016 06:46 PM, Gilles Filippini wrote:
I've checked the build of every reverse dependencies. These few ones 
are of concern:

* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no 
reverse dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon 
about 300 - no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - 
rather low popcon
* ants : in progress; build depends on insighttoolkit4 - raher low 
popcon


From the above packages, the only real concern is pytables. A 
discussion is ongoing on debian-science@d.o, and I'm confident we'll 
find a solution before the Stretch freeze.


pytables does have several reverse dependencies, who in turn have
several reverse dependencies too. pytables in the dependency chain of
geopandas, having it removed from stretch would be very sad.


Ooops, sorry, I didn't noticed that. Actually I checked weeks ago and 
didn't remember there were reverse depends. My bad.
But as said above, I'm confident we'll find a solution for pytables 
before the Strtch freeze. It would be removed from testing only for a 
while.



insighttoolkit4 is in the dependency chain of otb, and like pytables
having it removed from stretch would be very sad. Even more than 
pytables.


I've successfully tested today a full insighttoolkit4 build for unstable 
on a stronger box than mine. I'll rebuild tomorrow against hdf5-1.10. 
I'm rather confident about this one too.


Thanks,

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Release Team,

I hereby request a transition slot for hdf5 1.10 currently in experimental. 
This release ships major changes and has its soname bumped from 10 to 100.

Ben file:

title = "hdf5";
is_affected = .depends ~ /libhdf5.*-10([^0]|$)/ | .depends ~ /libhdf5.*-100/;
is_good = .depends ~ /libhdf5.*-100/;
is_bad = .depends ~ /libhdf5.*-10([^0]|$)/;


I've checked the build of every reverse dependencies. These few ones are of 
concern:
* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no reverse 
dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon about 300 
- no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - rather low 
popcon
* ants : in progress; build depends on insighttoolkit4 - raher low popcon

- From the above packages, the only real concern is pytables. A discussion is 
ongoing on debian-science@d.o, and I'm confident we'll find a solution before 
the Stretch freeze.


Full report:
===[ Dependency level 0 ]=
hdf5:   binnmu OK
nanopolish: binnmu OK
octave-communications:  binnmu OK
===[ Dependency level 1 ]=
chemps2: hdf5   patch provided via #841954
field3d: hdf5   binnmu OK
freefem++: hdf5 binnmu OK
h5py: hdf5  binnmu OK
h5utils: hdf5   binnmu OK
hdf-eos5: hdf5  binnmu OK
ismrmrd: hdf5   patch provided via #841959
jhdf: hdf5  binnmu OK
libcgns: hdf5   binnmu OK
libgpiv: hdf5   patch provided via #841962
libmatio: hdf5  binnmu OK
libmstoolkit: hdf5  binnmu OK
libpdl-io-hdf5-perl: hdf5   patch provided via #841963
libsis-jhdf5-java: hdf5 KO hard coded hid_t as jint all over 
the source; upstream site dead (http://wiki-bsse.ethz.ch/)
libvigraimpex: hdf5 binnmu OK
mapsembler2: hdf5   binnmu OK
med-fichier: hdf5   patch provided via #841964
meep: hdf5  binnmu OK
meep-lam4: hdf5 binnmu OK
meep-mpi-default: hdf5  binnmu OK
meep-mpich2: hdf5   binnmu OK
meep-openmpi: hdf5  binnmu OK
mpb: hdf5   binnmu OK
ncbi-vdb: hdf5  binnmu OK
netcdf: hdf5binnmu OK
nexus: hdf5 binnmu OK
octave: hdf5binnmu OK
opengm: hdf5binnmu OK
pbseqlib: hdf5  binnmu OK
pytables: hdf5  KO - doesn't support hdf5-1.10 yet
r-cran-hdf5: hdf5   binnmu OK
seer: hdf5  binnmu OK
shark: hdf5 binnmu OK
shogun: hdf5FTBFS unrelated to hdf5 - not in 
testing - #809290
silo-llnl: hdf5 binnmu OK
slurm-llnl: hdf5binnmu OK
stimfit: hdf5   binnmu OK
tessa: hdf5 FTBFS unrelated to hdf5 - not in 
testing - #817690
trilinos: hdf5  binnmu OK
xdmf: hdf5  binnmu OK
yorick-hdf5: hdf5   KO Yorick doesn't support 64bits 
integers (hid_t)
===[ Dependency level 2 ]=
adios: hdf5 netcdf  binnmu OK
aster: hdf5 med-fichier FTBFS unrelated to hdf5 - not in 
testing - #837915
blasr: hdf5 pbseqlibbinnmu OK
cmor: hdf5 netcdf   binnmu OK
code-saturne: hdf5 libcgns med-fichier  binnmu OK
comet-ms: libmstoolkit  binnmu OK
deal.ii: hdf5 netcdf trilinos   BD uninstallable - not in testing
gdal: hdf5 netcdf   binnmu OK
grads: hdf5 netcdf  binnmu OK
grib-api: hdf5 netcdf   binnmu OK
labplot: hdf5 netcdfbinnmu OK
libminc: hdf5 netcdfpatch provided via #841970
mathgl: hdf5 octave binnmu OK
nco: netcdf binnmu OK
ncview: netcdf  binnmu OK
netcdf4-python: hdf5 netcdf binnmu OK
octave-netcdf: netcdf   binnmu OK
ovito: hdf5 netcdf  binnmu OK
paraview: hdf5 netcdf xdmf  binnmu OK
psi4: chemps2 hdf5  binnmu OK
pygpiv: hdf5 libgpivbinnmu OK
python-shogun: hdf5 shogun 

Bug#841954: [Debichem-devel] Bug#841954: HDF5 1.10

[Gilles Filippini]

On 2016-10-25 12:12, Graham Inggs wrote:

Gilles, just to be clear, do you want us to upload chemps2 before or
after you upload HDF5 1.10?


Hi Graham,

Before. Then Release Team handle the necessary binnmus during the 
transition.


Thanks,

_g.

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 <p...@debian.org>  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 readCommo

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 <p...@debian.org>  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#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 <p...@debian.org>  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#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 <p...@debian.org>  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)
+ {
+ 

Bug#841967: adios: Please support building against HDF5 1.10

[Gilles Filippini]

Source: adios
Version: 1.9.0-12
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-

iQEcBAEBCAAGBQJYDnG6AAoJEO/obGx//s+D7aAIAKHKt9m2cb5EzrKApUBWGBty
qL0117O2FcXZfseegg1khAjY7nNi2mweuhk2RdI0JipQ/4mOoza9u+ZGUNN1bYYA
V5DdOadsU8DlbnO41xnebs2D1rTrUT23Mbt8N5NKnWdpxMrXesHL8gw3HdHn44b3
NvB9hniFTKVWuSP50TcFLGkFUaEAIIa5QTIVRSWM9oGLJ7aYqC8JJ5CM/TlvZPVL
oqJ4/4+969CxQ/snj1Zrnl5kLVA6b8U2mjqt76iM97IzbQ9n0W8d+KpcYxC5vCrI
mJ1mUuf1JIXRtNmE5Pz+F4FAqJiiQfQoLDVNGV1Mh92fylMJovEhGGVNK4XnVsQ=
=G1na
-END PGP SIGNATURE-
diff -Nru adios-1.9.0/debian/changelog adios-1.9.0/debian/changelog
--- adios-1.9.0/debian/changelog	2016-08-25 22:46:00.0 +0200
+++ adios-1.9.0/debian/changelog	2016-10-22 12:01:21.0 +0200
@@ -1,3 +1,10 @@
+adios (1.9.0-12.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New patch type-bool-already-defined.patch to fix FTBFS against HDF5 1.10
+
+ -- Gilles Filippini <p...@debian.org>  Sat, 22 Oct 2016 12:01:20 +0200
+
 adios (1.9.0-12) unstable; urgency=medium
 
   * Fix for gcc 6.2: Don't define 'bool', its provided.
diff -Nru adios-1.9.0/debian/patches/series adios-1.9.0/debian/patches/series
--- adios-1.9.0/debian/patches/series	2016-08-25 22:46:00.0 +0200
+++ adios-1.9.0/debian/patches/series	2016-10-22 12:01:46.0 +0200
@@ -16,3 +16,4 @@
 version-fix.patch
 libc-2.23-fixes.patch
 # gcc6-fixes.patch
+type-bool-already-defined.patch
diff -Nru adios-1.9.0/debian/patches/type-bool-already-defined.patch adios-1.9.0/debian/patches/type-bool-already-defined.patch
--- adios-1.9.0/debian/patches/type-bool-already-defined.patch	1970-01-01 01:00:00.0 +0100
+++ adios-1.9.0/debian/patches/type-bool-already-defined.patch	2016-10-22 12:03:21.0 +0200
@@ -0,0 +1,17 @@
+Description: HDF5 1.10 defines type bool
+Author: Gilles Filippini <p...@debian.org>
+Index: adios-1.9.0/utils/bp2h5/bp2h5.c
+===
+--- adios-1.9.0.orig/utils/bp2h5/bp2h5.c
 adios-1.9.0/utils/bp2h5/bp2h5.c
+@@ -43,7 +43,9 @@
+ #include "dmalloc.h"
+ #endif
+ 
+-typedef int bool;
++#ifndef bool
++typedef int bool;
++#endif
+ #define false 0
+ #define true  1
+ 

Bug#841966: xdmf: Please support building against HDF5 1.10

[Gilles Filippini]

Source: xdmf
Version: 2.1.dfsg.1-15
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-

iQEcBAEBCAAGBQJYDnD+AAoJEO/obGx//s+DXGAIAIrlN3xd/dPi+cYEy7+gm1UY
Pn/fJkHNvl8EEXntIYLkyF8SLHiWCzo2FmxtnnMShfBTu89u1z0QRG6QgpSzXFCT
RkUNE9R8YyZA1nkjngmQXgoloyDvE+UjyhLQ4ixVrBh3MkImG9DCbMjtcLbjvQrK
phcfHi3lIjFMygO547JdlPDqGVzl1S6lkhIUvH1uCi/WInqEVsourohKE3g7WB73
uI2JI9slksTJjFC37Pa70VZkJHX1vpwO47PpmD5+zgkVsFc15FWgA6iy0O1Mtpyr
koeMHc80J+29ELz6gVmqB/7JHiVKMwTIvvPhIx3of9X2VgymB/KMjCgq8Euw8Wk=
=TdSX
-END PGP SIGNATURE-
diff -Nru xdmf-2.1.dfsg.1/debian/changelog xdmf-2.1.dfsg.1/debian/changelog
--- xdmf-2.1.dfsg.1/debian/changelog	2016-04-03 15:25:50.0 +0200
+++ xdmf-2.1.dfsg.1/debian/changelog	2016-10-21 19:55:29.0 +0200
@@ -1,3 +1,10 @@
+xdmf (2.1.dfsg.1-15.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch hdf5-1.10.patch to fix FTBFS against HDF5 1.10
+
+ -- Gilles Filippini <p...@debian.org>  Sat, 23 Jul 2016 15:06:23 +0200
+
 xdmf (2.1.dfsg.1-15) unstable; urgency=medium
 
   * Fix Typo in depends lib*gz*stream-dev. Closes: 819872
diff -Nru xdmf-2.1.dfsg.1/debian/patches/hdf5-1.10.patch xdmf-2.1.dfsg.1/debian/patches/hdf5-1.10.patch
--- xdmf-2.1.dfsg.1/debian/patches/hdf5-1.10.patch	1970-01-01 01:00:00.0 +0100
+++ xdmf-2.1.dfsg.1/debian/patches/hdf5-1.10.patch	2016-10-21 19:55:29.0 +0200
@@ -0,0 +1,47 @@
+Index: xdmf-2.1.dfsg.1/libsrc/XdmfH5Driver.cxx
+===
+--- xdmf-2.1.dfsg.1.orig/libsrc/XdmfH5Driver.cxx
 xdmf-2.1.dfsg.1/libsrc/XdmfH5Driver.cxx
+@@ -133,14 +133,19 @@ static herr_t H5FD_dsm_close(H5FD_t *_fi
+ static herr_t H5FD_dsm_flush(H5FD_t *_file);
+ #endif
+ static int H5FD_dsm_cmp(const H5FD_t *_f1, const H5FD_t *_f2);
++#if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=10))
++static haddr_t H5FD_dsm_get_eof(const H5FD_t *_file, H5FD_mem_t type);
++#elif ((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=8))
++static haddr_t H5FD_dsm_get_eof(const H5FD_t *_file);
++#else
++static haddr_t H5FD_dsm_get_eof(H5FD_t *_file);
++#endif
+ #if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=8))
+ static haddr_t H5FD_dsm_get_eoa(const H5FD_t *_file, H5FD_mem_t type);
+ static herr_t H5FD_dsm_set_eoa(H5FD_t *_file, H5FD_mem_t type, haddr_t addr);
+-static haddr_t H5FD_dsm_get_eof(const H5FD_t *_file);
+ #else
+ static haddr_t H5FD_dsm_get_eoa(H5FD_t *_file);
+ static herr_t H5FD_dsm_set_eoa(H5FD_t *_file, haddr_t addr);
+-static haddr_t H5FD_dsm_get_eof(H5FD_t *_file);
+ #endif
+ static herr_t H5FD_dsm_read(H5FD_t *_file, H5FD_mem_t type, hid_t fapl_id, haddr_t addr,
+DSM_HSIZE_T size, void *buf);
+@@ -152,6 +157,9 @@ static const H5FD_class_t H5FD_dsm_g = {
+ "dsm",  /*name  */
+ MAXADDR,/*maxaddr   */
+ H5F_CLOSE_WEAK, /*fc_degree */
++#if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=10))
++NULL,   /* terminate*/
++#endif
+ NULL,   /*sb_size   */
+ NULL,   /*sb_encode */
+ NULL,   /*sb_decode */
+@@ -684,7 +692,9 @@ H5FD_dsm_set_eoa(H5FD_t *_file, haddr_t
+  *-
+  */
+ static haddr_t
+-#if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=8))
++#if (H5_VERS_MAJOR>1)||((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=10))
++H5FD_dsm_get_eof(const H5FD_t *_file, H5FD_mem_t type)
++#elif ((H5_VERS_MAJOR==1)&&(H5_VERS_MINOR>=8))
+ H5FD_dsm_get_eof(const H5FD_t *_file)
+ #else
+ H5FD_dsm_get_eof(H5FD_t *_file)
diff -Nru xdmf-2.1.dfsg.1/debian/patches/series xdmf-2.1.dfsg.1/debian/patches/series
--- xdmf-2.1.dfsg.1/debian/patches/series	2016-04-03 15:25:50.0 +0200
+++ xdmf-2.1.dfsg.1/debian/patches/series	2016-10-21 19:55:29.0 +0200
@@ -5,3 +5,4 @@
 c++11.patch
 gzstream.patch
 python-install-dir.patch
+hdf5-1.10.patch

Bug#841965: nexus: Please support building against HDF5-1.10

[Gilles Filippini]

Source: nexus
Version: 4.3.2-svn1921-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-

iQEcBAEBCAAGBQJYDm6iAAoJEO/obGx//s+DRe8H/3KH4KW19wWpbveKdv3r1pp4
jHtRWCyLVlIMwTXwuUHHugPl0hhKwJRvhUn11c5mH8bVtB35vc5gGbxDswCNbD7B
h+oit+pEWWD5GEkrIRQet/kytSWsA8CVteLXKJrPskoBcHm5p2634jHWUi8qhu0q
m0UxxijJgc28eSAO2bmWl3DYgrSbIv42INOaMMEpvQeYUf4nCrw0Kp6Dpwi4Bn2e
bFRS7JjhettnJC3n68iLpob3j9/n+Bw75yvoh72MOLWri7UGjDk4ce76jke3tSmX
cXHPKHQaPw5hhYYIDfxJw8fHx3z83MGHcE2e98CBvyLfz6Eao4yoxL0GQHWIFO0=
=5+JJ
-END PGP SIGNATURE-
diff -Nru nexus-4.3.2-svn1921/debian/changelog nexus-4.3.2-svn1921/debian/changelog
--- nexus-4.3.2-svn1921/debian/changelog	2015-12-14 00:09:11.0 +0100
+++ nexus-4.3.2-svn1921/debian/changelog	2016-10-21 00:25:42.0 +0200
@@ -1,3 +1,9 @@
+nexus (4.3.2-svn1921-4) unstable; urgency=medium
+
+  * Fix HDF5 1.10 detection
+
+ -- Gilles Filippini <p...@debian.org>  Fri, 22 Jul 2016 23:05:27 +0200
+
 nexus (4.3.2-svn1921-3) unstable; urgency=medium
 
   * QA upload.
diff -Nru nexus-4.3.2-svn1921/debian/patches/fix-hdf5-1-10-detection.patch nexus-4.3.2-svn1921/debian/patches/fix-hdf5-1-10-detection.patch
--- nexus-4.3.2-svn1921/debian/patches/fix-hdf5-1-10-detection.patch	1970-01-01 01:00:00.0 +0100
+++ nexus-4.3.2-svn1921/debian/patches/fix-hdf5-1-10-detection.patch	2016-10-21 00:25:42.0 +0200
@@ -0,0 +1,13 @@
+Index: nexus-4.3.2-svn1921/configure.ac
+===
+--- nexus-4.3.2-svn1921.orig/configure.ac
 nexus-4.3.2-svn1921/configure.ac
+@@ -610,7 +610,7 @@ HDF5_API_DEFS="-DH5Acreate_vers=2 -DH5Ai
+ if test "$H5ROOT"; then
+ H5VERSION=`grep H5_VERS_INFO ${H5ROOT}/include/H5public.h | cut -d '"' -f 2 | cut -d ' ' -f 4`
+ case $H5VERSION in
+-	1.[[89]]*)
++	1.[[89]].*|1.10.*)
+ 		HDF5_LDFLAGS=""
+ 		for j in lib lib64; do
+ 		if test -d $H5ROOT/$j; then 
diff -Nru nexus-4.3.2-svn1921/debian/patches/series nexus-4.3.2-svn1921/debian/patches/series
--- nexus-4.3.2-svn1921/debian/patches/series	2014-04-16 22:00:58.0 +0200
+++ nexus-4.3.2-svn1921/debian/patches/series	2016-10-21 00:25:42.0 +0200
@@ -1 +1,2 @@
 0001-these-days-nexus-without-hdf5-is-considered-broken.patch
+fix-hdf5-1-10-detection.patch

Bug#841964: med-fichier: 3.0.6-10

[Gilles Filippini]

Source: med-fichier
Version: 3.0.6-10
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-

iQEcBAEBCAAGBQJYDm30AAoJEO/obGx//s+DnnYIAIFKx50dblj+cIp9q+biyqz8
jAVu09CPLbX+odfY6Tpf7WEqvJsWARsgiWaaWCg+TL8J6TDorJPGRTTs5J2OyjKn
9X25TbNy2TiSzPCR4czJl9JpsE8TVhTkhIcDJSIuTtjK2AzwCH3MQ2POZsNnZvcl
9Erct+Y9pokgKeViwf6plamlPpDwuzJde8C1lNCX66prYRTfEIT8EmJu0aTGg2oP
Xzi/Him5GK45HobtO0qb0svrILsxh9ZL82YuxmQ5akfldTxY6S6F1os15YSKDmHf
uAZRrr7iLsjKjYE4+w0kfLFW14YFbNmJb42Skct4SlonqIgx6EgbxjSiDJz35nw=
=M6Y6
-END PGP SIGNATURE-
diff -Nru med-fichier-3.0.6/debian/changelog med-fichier-3.0.6/debian/changelog
--- med-fichier-3.0.6/debian/changelog	2016-09-04 20:06:34.0 +0200
+++ med-fichier-3.0.6/debian/changelog	2016-10-20 21:59:53.0 +0200
@@ -1,3 +1,11 @@
+med-fichier (3.0.6-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch fix-fid-type-in-medequivinfo.patch to fix FTBFS with
+HDF5 1.10
+
+ -- Gilles Filippini <p...@debian.org>  Thu, 20 Oct 2016 21:59:50 +0200
+
 med-fichier (3.0.6-10) unstable; urgency=medium
 
   * [f6af4e3] Fix autopkgtest.
diff -Nru med-fichier-3.0.6/debian/patches/fix-fid-type-in-medequivinfo.patch med-fichier-3.0.6/debian/patches/fix-fid-type-in-medequivinfo.patch
--- med-fichier-3.0.6/debian/patches/fix-fid-type-in-medequivinfo.patch	1970-01-01 01:00:00.0 +0100
+++ med-fichier-3.0.6/debian/patches/fix-fid-type-in-medequivinfo.patch	2016-10-20 21:58:54.0 +0200
@@ -0,0 +1,17 @@
+Description: fix wrong type for fid in MEDequivInfo
+ MEDequivInfo was previously declared in include/2.3.6/med_proto.h
+ with correct type for fid: med_idt.
+Author: Gilles Filippini <p...@debian.org>
+Index: med-fichier-3.0.6/src/2.3.6/ci/MEDequivInfo.c
+===
+--- med-fichier-3.0.6.orig/src/2.3.6/ci/MEDequivInfo.c
 med-fichier-3.0.6/src/2.3.6/ci/MEDequivInfo.c
+@@ -24,7 +24,7 @@
+ #include 
+ 
+ int
+-MEDequivInfo(int fid, char *maa, int ind, char *eq, char *des)
++MEDequivInfo(med_idt fid, char *maa, int ind, char *eq, char *des)
+ {
+   med_idt eqid;
+   med_err ret;
diff -Nru med-fichier-3.0.6/debian/patches/series med-fichier-3.0.6/debian/patches/series
--- med-fichier-3.0.6/debian/patches/series	2014-09-11 21:26:13.0 +0200
+++ med-fichier-3.0.6/debian/patches/series	2016-10-20 21:58:54.0 +0200
@@ -1,3 +1,4 @@
 ppc64el-support.patch
 hdf5_link.patch
 clang-ftbfs.diff
+fix-fid-type-in-medequivinfo.patch

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

[Gilles Filippini]

Source: libpdl-io-hdf5-perl
Version: 1:0.73-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-

iQEcBAEBCAAGBQJYDm0tAAoJEO/obGx//s+D5K8H/iDW/mGIAH3cqQ4k/NHJKNSC
FuGcTiCMfNfq7W6KMWch7rfzPYWSZiyn1Zje3i1snaDslji2JFqnAY6EGyujtTzb
Y87SSvVQrTIsv1Reh5sjD6mL852l/+AlOFjeWEvlkd/3arwGnJM+rlnoowwlM8Wk
bHKckcRhTJRYaORKCjNApT12E0+Lh9o8Czh9dXJO0gn2txEIsMwAuIaAIRnoqCwk
bi0rI70tocEh6i6ZeiCHx44rVUG+f8Jc51Ql5iL38szKyLlnTXfWl59bgfsGWrfF
tGHs4+bTi2WaK3jv9mbbAFEB/cSlLt6W02gsBSi/QVpFtNe1QES34iPe1xrOQJY=
=RDOr
-END PGP SIGNATURE-
diff -Nru libpdl-io-hdf5-perl-0.73/debian/changelog libpdl-io-hdf5-perl-0.73/debian/changelog
--- libpdl-io-hdf5-perl-0.73/debian/changelog	2016-07-03 00:53:33.0 +0200
+++ libpdl-io-hdf5-perl-0.73/debian/changelog	2016-10-20 19:19:16.0 +0200
@@ -1,3 +1,10 @@
+libpdl-io-hdf5-perl (1:0.73-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch for HDF5 1.10 support
+
+ -- Gilles Filippini <p...@debian.org>  Sun, 24 Jul 2016 08:34:49 +0200
+
 libpdl-io-hdf5-perl (1:0.73-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru libpdl-io-hdf5-perl-0.73/debian/patches/hdf5-1.10.patch libpdl-io-hdf5-perl-0.73/debian/patches/hdf5-1.10.patch
--- libpdl-io-hdf5-perl-0.73/debian/patches/hdf5-1.10.patch	1970-01-01 01:00:00.0 +0100
+++ libpdl-io-hdf5-perl-0.73/debian/patches/hdf5-1.10.patch	2016-10-20 19:19:16.0 +0200
@@ -0,0 +1,31 @@
+Index: libpdl-io-hdf5-perl-0.73/hdf5.pd
+===
+--- libpdl-io-hdf5-perl-0.73.orig/hdf5.pd
 libpdl-io-hdf5-perl-0.73/hdf5.pd
+@@ -1624,7 +1624,7 @@ char *s;
+ return -1;
+ }
+ 
+-double 
++hid_t 
+ constant(name, arg)
+ char *name;
+ int arg;
+@@ -2507,7 +2507,7 @@ EOXS
+ 
+ pp_addxs('',<<'EOXS');
+ 
+-double
++hid_t
+ constant(name,arg)
+ 	char *		name
+ 	int		arg
+@@ -2739,7 +2739,7 @@ OUTPUT:
+ 
+ # Sub to add the H5T_VARIABLE constant
+ #  This is added manually here, rather than regenerate the constant function above
+-size_t
++hid_t
+ H5T_VARIABLE()
+ CODE:
+ RETVAL = H5T_VARIABLE;
diff -Nru libpdl-io-hdf5-perl-0.73/debian/patches/series libpdl-io-hdf5-perl-0.73/debian/patches/series
--- libpdl-io-hdf5-perl-0.73/debian/patches/series	2016-07-03 00:47:53.0 +0200
+++ libpdl-io-hdf5-perl-0.73/debian/patches/series	2016-10-20 19:19:16.0 +0200
@@ -2,3 +2,4 @@
 clean_newFile_hd5.patch
 support-hdf5-1.8.13.patch
 reproducible_build.patch
+hdf5-1.10.patch

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 <p...@debian.org>  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 <p...@debian.org>
+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#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#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 <p...@debian.org>  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#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(li

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#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 <p...@debian.org>  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#841947: libboost-*1.61-dev: Please build static libs with -fPIC

[Gilles Filippini]

Source: boost1.61
Version: 1.61.0+dfsg-3
Severity: serious
Justification: make other packages FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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 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(tuple.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(str.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(from_python.o):
 relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a 
shared object; 

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

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The antlr package currently in unstable isn't built with -fPIC, leading to FTFS 
for some of its reverse dependencies, such as nco:
libtool: link: g++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o .libs/ncap2 Invoke.o ncap2.o ncap2_utl.o sdo_utl.o sym_cls.o 
fmc_cls.o fmc_all_cls.o fmc_gsl_cls.o prs_cls.o NcapVar.o NcapVarVector.o 
ncoLexer.o ncoParser.o ncoTree.o nco_gsl.o  -L../nco 
/<>/src/nco/.libs/libnco.so -lantlr -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5_hl -lhdf5 -lpthread -lsz -lz 
-ldl -lnetcdf /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -lgsl -lgslcblas -lm 
-ludunits2 -pthread -fopenmp -Wl,-rpath -Wl,/usr/lib/nco
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libantlr.a(ASTFactory.o): 
relocation R_X86_64_32S against symbol `_ZTVN5antlr10ASTFactoryE' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libantlr.a(BaseAST.o): 
relocation R_X86_64_32S against symbol `_ZNK5antlr7BaseAST13getFirstChildEv' 
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libantlr.a(BitSet.o): 
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
...

Binnmu-ing seems sufficient to fix that (tested localy on my box).

nmu antlr_2.7.7+dfsg-7 . ANY . unstable . -m "rebuild with -fPIC"

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-

iQEcBAEBCAAGBQJYDj76AAoJEO/obGx//s+Dar0IAJbQSE3DicxF9tGYOx8xgQKU
ZPqfLcdDMhHOZS6Q+MXrc1Ft3Ol24QuHKFrZNPGBI8sbNgQR1i32YykgaU9IkrOj
esmviFXXhEy+WnjcKyGEG8AL0CIc/atsTjV0U4M7aehTapkDVucRwzfHYEXcCCeY
sC5Xdhe60/iyOhL8TbmeeT1dExM7zAUNv7HJ6D4zFZq/fJxsqKoYdrkleG/PJ/5e
8JnF3UrhTH9au1MIZUHXZ5inCD5n5Kcb2nIprSfK1+TtfDTMRNxrnInYQvN7N0QL
XG1w0TftNCmIsVtxyaVdEyKmkwR4Oo+ko+81BzZt465h4OHHK1a2uU9Y/IRP9os=
=JPC4
-END PGP SIGNATURE-

Bug#841929: nmu: libctl_3.2.2-2

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

A rebuild of libctl seems sufficiant to fix #837568:
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libctlgeom.a(geom.o):
> relocation R_X86_64_32 against `.rodata.str1.1' can not be used when
> making a shared object; recompile with -fPIC

nmu libctl_3.2.2-2 . ANY . unstable . -m "Rebuild with -fPIC (closes: #837568)"

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-

iQEcBAEBCAAGBQJYDh1ZAAoJEO/obGx//s+D9XAH/3flPuyLSVyDEB2ZUlPvJJiR
qM3eET/9UWyX+uzQhiJ+mctP7FFiULTc81p5ifFSbjW69QL6XW7N0gxbnHSkZjGo
XKaq/m4Gn7wo9aIHgkfEgJr04DB/e2TxJ0M3lQcQHAZaofbnZNpsXD1gM/2S0JJx
6M2wZ11uzZmXOtTfqcZzT0OJXhZRVEMwtsjLCU7/Zd1MJxe23URFDEdheaTkk3nu
l0iaBhaL9aYlZHEf6hZgqb0te07Zn+1dQuYEFYqSbuzOdqD4Ira4YEB6X8L7s2Kn
aP/91GXWnGdcN5dvR5t8zdx7ZDE6vpJ9b+62ttAT7bZkfqcHmcP9VTZYmnJ6evY=
=MUbc
-END PGP SIGNATURE-

Bug#832634: sikuli-ide: new upstream version / upload of version 1.1.0 for unstable?

[Gilles Filippini]

Hi,

Michael Prokop a écrit le 28/07/2016 à 00:33 :
> Package: sikuli-ide
> Version: 1.1.0-1~exp3
> Severity: wishlist
> 
> Hi,
> 
> (Cc-ing intrigeri who kindly pointed me towards sikuli and it works
> fine so far for us, thx!)
> 
> In experimental I see sikuli version 1.1.0-1~exp3 dating back to
> 2016-03-18 (and was released by upstream on 2015-10-07 according to
> https://github.com/RaiMan/SikuliX-2014/releases), though there was
> no change since then regarding upload towards unstable or so.
> 
> In unstable and testing we currently have
> 1.0~x~rc3.tesseract3-dfsg1-12 which seems to date back to 2011-09-15
> upstream wise.
> 
> In terms of the upcoming stretch release it might be nice to clarify
> the situation WRT sikuli versions in Debian? Is there anything
> specific holding you back from uploading 1.1.0-1~exp3 towards
> unstable so it could end up in stretch?

Thanks for you interest in Sikuli. I was very enthusiastic when I
discovered it back in 2011.

But now I have some concerns about the way Sikuli (now SikuliX) is
maintained upstream, since the MIT orphaned their project. I can't see a
clear roadmap; some bugs just stage for months with no activity. I'm
afraid that SikuliX 1.1.0 might be of poor quality for now. That's why
I've been keeping it into experimental for so long.

BTW I'm not using it as much as I used to. If you think that release
1.1.0 is good enough for unstable, please tell me, I'll do the transition.

> BTW and JFYI (in case you aren't aware yet): "SikuliX version 2.0.0
> to be released end 2016": https://github.com/RaiMan/SikuliX2

SikuliX 1.1.0 was first expected some 2 years before its effective
release, then continuously drifted one month at a time with an announce
like "release by the end of this month".

And I fail to see any significant activity on SikuliX2 github
repository. That's understandable : there is a lot of work to do on
release 1.1.x yet.

> 
> Thanks for maintaining sikuli-ide!

Thank you!

_g.




signature.asc
Description: OpenPGP digital signature

Bug#832035: libfast5-dev: wrong type for file_type_id in hdf5_tools.hpp - should be hid_t instead of int

[Gilles Filippini]

Package: libfast5-dev
Version: 0~20150918-1
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Subject says it all.
This bug doesn't affect unstable currently because hid_t = int in hdf5 1.8.x.
But it breaks with hdf5 1.10 in experimental, where hid_t = long long.

PLease see the attached patch.

Thank,

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

Versions of packages libfast5-dev depends on:
ii  libhdf5-dev  1.8.16+docs-8
ii  libhdf5-openmpi-dev  1.8.16+docs-8

libfast5-dev recommends no packages.

libfast5-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJXkOv3AAoJEO/obGx//s+DkRsIAII7dK3+nhtTfCAwwMr7Wsd8
sM5ZXNX7CUkb5BzC1ip65Cx0S+njh7qQLHeOTBFhSqFX4AeXuo9gIePl1kL96uUy
vX2yEC54tsnu0WnblufvHIlkw40Rbbuw/YZsiMcboBg6doYcPzvy670YDsBhssF0
wkWHBFmsDotNRM0loQq2YVVe5JLRabTefsVGwGHw4RksGlQ6SnSJikUqckNZEfy2
cuXfcUs0lpyJNiXJuMxsUd7svzj8CfLZWFT1VcNVB6h9Ymm+njcbZZYFySPmlWLv
9N+gT0sJai0M7wt2584yRmJPTUojUw8w2uxFjWggMwlVrUk/5mqPvaclIkrpgDc=
=o3u1
-END PGP SIGNATURE-
diff -Nru fast5-0~20150918/debian/changelog fast5-0~20150918/debian/changelog
--- fast5-0~20150918/debian/changelog	2016-01-20 11:11:22.0 +0100
+++ fast5-0~20150918/debian/changelog	2016-07-21 17:12:12.0 +0200
@@ -1,3 +1,11 @@
+fast5 (0~20150918-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix wrong id type: should be hid_t instead of int, for hdf5 1.10
+compatibility.
+
+ -- Gilles Filippini <p...@debian.org>  Thu, 21 Jul 2016 17:06:57 +0200
+
 fast5 (0~20150918-1) unstable; urgency=low
 
   * Initial release - upstream git revision 0639cc5 (Closes: #811460)
diff -Nru fast5-0~20150918/debian/patches/fix-id-type.patch fast5-0~20150918/debian/patches/fix-id-type.patch
--- fast5-0~20150918/debian/patches/fix-id-type.patch	1970-01-01 01:00:00.0 +0100
+++ fast5-0~20150918/debian/patches/fix-id-type.patch	2016-07-21 17:09:43.0 +0200
@@ -0,0 +1,13 @@
+Index: fast5-0~20150918/src/hdf5_tools.hpp
+===
+--- fast5-0~20150918.orig/src/hdf5_tools.hpp
 fast5-0~20150918/src/hdf5_tools.hpp
+@@ -218,7 +218,7 @@ struct Extent_Atomic_Reader< std::string
+   const std::string& read_fcn_name, std::function< herr_t(hid_t, hid_t, void*) > read_fcn)
+ {
+ int status;
+-int file_type_id = get_type_fcn(obj_id);
++hid_t file_type_id = get_type_fcn(obj_id);
+ if (file_type_id < 0) throw Exception(loc_full_name + ": error in " + get_type_fcn_name);
+ int is_vlen_str = H5Tis_variable_str(file_type_id);
+ if (is_vlen_str < 0) throw Exception(loc_full_name + ": error in H5Tis_variable_str");
diff -Nru fast5-0~20150918/debian/patches/series fast5-0~20150918/debian/patches/series
--- fast5-0~20150918/debian/patches/series	2016-01-20 11:11:22.0 +0100
+++ fast5-0~20150918/debian/patches/series	2016-07-21 17:09:09.0 +0200
@@ -1,2 +1,3 @@
 relative-paths.patch
 revise-example.patch
+fix-id-type.patch

Bug#826522: Set the plugin directory

[Gilles Filippini]

Jerome BENOIT a écrit le 29/06/2016 à 08:32 :
> Hi,
> 
> On 29/06/16 07:16, PICCA Frederic-Emmanuel wrote:
>>> I've juste uploaded release 1.10.0-patch1+docs-1~exp3 to experimental,
>>> configured with:
>>> --with-default-plugindir=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/plugins
> 
> 
>> Just for information do we have this plugin directory available in the 
>> pkg-config file in order to setup
>> the plugging directory for a third-party plugging project ?
> 
> 
> Should be easy to do, I guess.
> 
> Otherwise, would it be possible to add local plugins folder ?
> Something as:
> 
> --with-default-plugindir=/usr/local/lib/$(DEB_HOST_MULTIARCH)/hdf5/plugins:/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/plugins

No need to clutter it up. There is the environment variable HDF5_PLUGIN_PATH. 
From the HDF5 filters doc [1]:
> The default path can be overwritten by a user with the HDF5_PLUGIN_PATH 
> environment variable. Several directories can be specified for the search 
> path using “:” as a path separator for UNIX-like systems and “;” for Windows.

[1] 
https://www.hdfgroup.org/HDF5/doc/Advanced/DynamicallyLoadedFilters/HDF5DynamicallyLoadedFilters.pdf

For now I'd rather stay with the above default configuration, until new real 
life cases are submitted.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#826522: Set the plugin directory

[Gilles Filippini]

Hi,

Jérôme Kieffer a écrit le 28/06/2016 à 09:16 :
> Dear HDF5 package maintainers,
> 
> Currently the debian build system does not enforce the plugin directory
> for HDF5 filters, defaulting to "/usr/local/hdf5/lib/plugin". I guess
> Debian would prefer something like:
> "/usr/share/hdf5/plugin" or even better:
> "/usr/lib/x86_64-linux-gnu/hdf5/plugins".
> 
> Would it be possible to specify the option 
> --with-default-plugindir=/usr/lib/x86_64-linux-gnu/hdf5/plugins
> to ./configure in order to re-locate those plugins and offer in
> external packages those plugins.
> 
> At synchrotrons, some of our detectors use LZ4 compression in HDF5
> files. Having plugins packaged and directly installable is real
> advantage compared to other operating systems.
> 
> Thanks for you comprehention.
> With my best regards,

I've juste uploaded release 1.10.0-patch1+docs-1~exp3 to experimental,
configured with:
--with-default-plugindir=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/plugins

Could you please give it a try?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#762892: switchsh: diff for NMU version 0~20070801-3.2

[Gilles Filippini]

Dear maintainer,

I've prepared an NMU for switchsh (versioned as 0~20070801-3.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -u switchsh-0~20070801/debian/changelog 
switchsh-0~20070801/debian/changelog
--- switchsh-0~20070801/debian/changelog
+++ switchsh-0~20070801/debian/changelog
@@ -1,3 +1,11 @@
+switchsh (0~20070801-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remount / with MS_SLAVE|MS_REC inside the CLONE_NEWNS namespace so
+that the bind mount doesn't affect the entire system (closes: #762892)
+
+ -- Gilles Filippini <p...@debian.org>  Wed, 25 May 2016 18:20:23 +0200
+
 switchsh (0~20070801-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u switchsh-0~20070801/debian/patches/series 
switchsh-0~20070801/debian/patches/series
--- switchsh-0~20070801/debian/patches/series
+++ switchsh-0~20070801/debian/patches/series
@@ -2,0 +3 @@
+remount_rootfs_rslave.patch
only in patch2:
unchanged:
--- switchsh-0~20070801.orig/debian/patches/remount_rootfs_rslave.patch
+++ switchsh-0~20070801/debian/patches/remount_rootfs_rslave.patch
@@ -0,0 +1,21 @@
+Description: When / is mounted as shared, unshare(CLONE_NEWNS) doesn't
+ prevent the bind mount to be system wide. Worse: it isn't unmounted
+ at exit.
+ Thus this patch wich remount / with --make-rslave.
+ See #739593 for more details.
+Author: Gilles Filippini <p...@debian.org>
+Bug-Debian: https://bugs.debian.org/762892
+Index: switchsh-0~20070801/switchsh.c
+===
+--- switchsh-0~20070801.orig/switchsh.c
 switchsh-0~20070801/switchsh.c
+@@ -105,7 +105,8 @@ int main(int argc, char *argv[])
+ }
+ #endif
+ 
+-if (mount("/bin/bash", "/bin/sh", NULL, MS_BIND, NULL) < 0) {
++if ((mount("", "/", NULL, MS_SLAVE|MS_REC, NULL) < 0) ||
++(mount("/bin/bash", "/bin/sh", NULL, MS_BIND, NULL) < 0)) {
+   if (errno == EPERM)
+   err_quit("This program must be setuid root!");
+   err_sys("mount");

Bug#762892: switchsh: Applies changes globally, at least with systemd

[Gilles Filippini]

Control: tag -1 + patch

On Thu, 25 Sep 2014 19:46:43 -0400 Matthew Gabeler-Lee
<chee...@fastcat.org> wrote:
> Package: switchsh
> Version: 0~20070801-3.1
> Severity: important
> Tags: upstream
> 
> The unshare() done by switchsh doesn't seem to work properly, at least with
> systemd "in effect".  However, on a system with sysvinit, it works fine.
> 
> The result is that, on the systemd system, the bind mount done by switchsh
> takes effect globally, and is never undone, except if the adminstrator
> notices it left around and fixes it.
> 
> And since it's never undone automatically, you can end up with a LOT of bind
> mounts created by it.

This is #739593. Here is a patch proposal based on the explanations there.

Thanks,

_g.
diff -u switchsh-0~20070801/debian/changelog 
switchsh-0~20070801/debian/changelog
--- switchsh-0~20070801/debian/changelog
+++ switchsh-0~20070801/debian/changelog
@@ -1,3 +1,11 @@
+switchsh (0~20070801-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remount / with MS_SLAVE|MS_REC inside the CLONE_NEWNS namespace so
+that the bind mount doesn't affect the entire system (closes: #762892)
+
+ -- Gilles Filippini <p...@debian.org>  Wed, 25 May 2016 18:20:23 +0200
+
 switchsh (0~20070801-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u switchsh-0~20070801/debian/patches/series 
switchsh-0~20070801/debian/patches/series
--- switchsh-0~20070801/debian/patches/series
+++ switchsh-0~20070801/debian/patches/series
@@ -2,0 +3 @@
+remount_rootfs_rslave.patch
only in patch2:
unchanged:
--- switchsh-0~20070801.orig/debian/patches/remount_rootfs_rslave.patch
+++ switchsh-0~20070801/debian/patches/remount_rootfs_rslave.patch
@@ -0,0 +1,21 @@
+Description: When / is mounted as shared, unshare(CLONE_NEWNS) doesn't
+ prevent the bind mount to be system wide. Worse: it isn't unmounted
+ at exit.
+ Thus this patch wich remount / with --make-rslave.
+ See #739593 for more details.
+Author: Gilles Filippini <p...@debian.org>
+Bug-Debian: https://bugs.debian.org/762892
+Index: switchsh-0~20070801/switchsh.c
+===
+--- switchsh-0~20070801.orig/switchsh.c
 switchsh-0~20070801/switchsh.c
+@@ -105,7 +105,8 @@ int main(int argc, char *argv[])
+ }
+ #endif
+ 
+-if (mount("/bin/bash", "/bin/sh", NULL, MS_BIND, NULL) < 0) {
++if ((mount("", "/", NULL, MS_SLAVE|MS_REC, NULL) < 0) ||
++(mount("/bin/bash", "/bin/sh", NULL, MS_BIND, NULL) < 0)) {
+   if (errno == EPERM)
+   err_quit("This program must be setuid root!");
+   err_sys("mount");


signature.asc
Description: OpenPGP digital signature

Bug#818909: Segfaults caused by new DT_MIPS_RLD_MAP_REL tag and RPATH removers

[Gilles Filippini]

Control: reopen -1

On Fri, 8 Apr 2016 13:34:04 +0200 Emilio Pozuelo Monfort
 wrote:
> On Fri, 8 Apr 2016 12:16:47 +0200 Alastair McKinstry
>  wrote:
> > 
> > >> OpenMPI maintainers (and anyone else affected):
> > >> One possible workaround is to use chrpath -r ""  on mips*
> > >> architectures until this is fixed since that command does not cause any
> > >> tags to be moved. It has a tiny performance penalty but should
> > >> otherwise work properly.
> > > Thanks for the workaround.
> > >
> > > Aurelien
> > >
> > Thanks.
> > I've tested this fix within openmpi on mips (works) and have uploaded a
> > new version with
> > the workaround.
> 
> Thanks! Unfortunately you forgot to apply this same workaround to mipsel and
> mips64el. Could you apply it in those architectures as well?

Reopening, until the problem is fixed for mipsel and mip64el.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#818909: libopenmpi-dev: [mips*] mpicc.openmpi unusable

[Gilles Filippini]

Package: libopenmpi-dev
Version: 1.10.2-11
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

hdf5 FTBFS on mips* [0][1][2] at the configure step of the openmpi build:

mips:
checking for mips-linux-gnu-gcc... mpicc.openmpi
checking whether the C compiler works... no
configure: error: in `/«BUILDDIR»/hdf5-1.8.16+docs/debian/build-openmpi':
configure: error: C compiler cannot create executables

mipsel:
checking for mipsel-linux-gnu-gcc... mpicc.openmpi
checking whether the C compiler works... no
configure: error: in `/«BUILDDIR»/hdf5-1.8.16+docs/debian/build-openmpi':
configure: error: C compiler cannot create executables

mips64el:
checking for mips64el-linux-gnuabi64-gcc... mpicc.openmpi
checking whether the C compiler works... no
configure: error: in `/«BUILDDIR»/hdf5-1.8.16+docs/debian/build-openmpi':
configure: error: C compiler cannot create executables

[0] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mips=1.8.16%2Bdocs-7=1458410051
[1] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mipsel=1.8.16%2Bdocs-7=1458408801
[2] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mips64el=1.8.16%2Bdocs-7=1458409194

Trying the mpicc.openmpi command on mips* porterboxes, it appears that
it segfault on mips and mipsel:

pini@etler:~/debian/hdf5$ schroot -r -c pini1
(sid_mipsel-dchroot)pini@etler:~/debian/hdf5$ /usr/bin/mpicc.openmpi --showme
[etler:10169] *** Process received signal ***
[etler:10169] Signal: Segmentation fault (11)
[etler:10169] Signal code: Address not mapped (1)
[etler:10169] Failing at address: 0x5a01f988
[etler:10169] *** End of error message ***
Segmentation fault

(sid_mips-dchroot)pini@minkus:~$ /usr/bin/mpicc.openmpi --showme
[minkus:23012] *** Process received signal ***
[minkus:23012] Signal: Segmentation fault (11)
[minkus:23012] Signal code: Address not mapped (1)
[minkus:23012] Failing at address: 0x17a4f448
[minkus:23012] *** End of error message ***
Segmentation fault

And it reports a configuration problem on mips64el:
(sid_mips64el-dchroot)pini@etler:~/debian/hdf5$ /usr/bin/mpicc.openmpi --showme
- --
No underlying compiler was specified in the wrapper compiler data file
(e.g., mpicc-wrapper-data.txt)
- --

Thanks,

_g.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJW8BkAAAoJEO/obGx//s+DoR4H/j9Yq+yXZBxB3r4riJinQldN
ysvmCLXgalUTsm41Fx39/jRycFKZOXcx2ZUomYuG5OmUjpZSYPjFP6j8k9SqEo9q
VKxw7XRb4jsfR618wA151U/PKqjma7lksh64q4+yb6RvYj0Quc9JrtAgQKUeE9ty
ESejb93jpjmR+aLDZ1dayMgadhA2LLcRRv+RInKVhkTsoPR6XgtdpiB7ri8dZNg+
gPY3XooysgDNqr3tkt6/9IZN+2kmswUN2C8NNZKn75xc40wJOd1y3bHukEBN7zLa
+HjphdLEbjnVma/PRWog1FH+ST2xgq7AcVMnNs/ualKbaZgaA85XVw6AL+WZ3rM=
=IREM
-END PGP SIGNATURE-

Bug#818632: RM: sikuli/experimental -- ROM; superseded by sikulix

[Gilles Filippini]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please remove sikuli 1.0.1-2 from experimental. The project name was changed to 
sikulix with release 1.1.0 now in experimental.

Thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJW7HrbAAoJEO/obGx//s+Dv0UH/2SO8yeB+NCsvRRd03cr+qWy
DvzaO/yyyNpOz2K64kNCcU6vtCIMvyZyFRrEZcqRtf9uJHNJz614VVtibyCnvY3N
oHu9krJENmvuzyEB2tov6XSt0dZrK2GN07h/luFz+4dysw2D5Wbp2X9hdUjep0oZ
iBWTe701ub8GY2FEgtMmyaQabgoScCbqIG86jRyA98q7Kqx/BBvjAjZwXlqrZhP/
aoWqi2qUc4EOIv3sNOiYzx9e+2MMbOLvF0OBGvepm+LQMNg4noAJntBZbe5g54c2
Xa/6dTeCHHIIUtNnf6OFrper4inyC93drsM79U8sDbtTaVXeAFCwP98eteimVp8=
=u4Zb
-END PGP SIGNATURE-

Bug#812573: nmu: libaec_0.3.2-1

[Gilles Filippini]

On Mon, 25 Jan 2016 09:27:14 +0100 Gilles Filippini <p...@debian.org> wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> 
> Despite successful buildlog [0], libaec binary packages are missing
> for arch x32. Please rebuild them.
> 
> [0] 
> https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417
> 
> nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing in 
> archive"

This is the case for archs ppc64 and sparc64 as well. Then this binnmu request 
becomes:

nmu libaec_0.3.2-1 . ppc64 sparc64 x32 . unstable . -m "rebuild for x32, ppc64, 
and sparc64 because missing in archive"

Thanks,
_g.

> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.3.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)
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#812686: RM: navit-graphics-qt-qpainter -- NBS; ROM

[Gilles Filippini]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package excluded from last upload because this plugin is unmaintained
and barely usable.

Thanks,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWppOlAAoJEO/obGx//s+DL2YH/iMggnTNXNrvB1+yaQIim9UI
d7ZfhX/VGRizcTdY9c47KAKp7h/6ZDeXlmrBh43HWUMBZ4kOLcLVJ9NHYKpHfkv1
KGDbnEL3YTswPq0bETD+vOaKeNbqj4tWkdUHK7W9nBTUo9TwD5utNndj9ASI6KLz
Ynp4un0VwOE93ZWh+JuC+FRO9z/dTMXY6pwtuoTwIROCEdz+kIMNxuP1j+03ESxB
J63TJJ5mVBtZgtrvDJba0lgClRIa0h0WNyV30zFwu99ORhpY3MyJN/giHP8sYM/R
uYSKeuz3+NocuMozDFHU25VXNNccFp9aLvxsgixeoi7xTieKHsRoA+7sa1pA8WU=
=EySI
-END PGP SIGNATURE-

Bug#812573: nmu: libaec_0.3.2-1

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Despite successful buildlog [0], libaec binary packages are missing
for arch x32. Please rebuild them.

[0] 
https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417

nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing in 
archive"

Thanks,

_g.

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

Kernel: Linux 4.3.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-
Version: GnuPG v1

iQEcBAEBCAAGBQJWpdxiAAoJEO/obGx//s+DguIH/2m9xf67xiBpRDD+bdD0Pt2R
K+OJZO/2H3l2WRs9mn+etSR+upIZGEBSjU27sd88J4Aauj2ozVEQcrtJmvqOKV11
YjTX4nrD/DztEdc84JEFWJDXbF5aDoqg4iuO46jdsZI+4bX/CfKcv5uxkM6qxPPd
Ptdzy87OZ7lURQ3IrhmrmaBN/SKcxgxrkJKbOkKebcB0saslOgPXY3E+DorME40+
ZE+KsvaPikN37VgCrpSodXlyQIWNGkcIZYT1mKsGXXsnv9uAI/OepuuiCCfswhdJ
ZqByzOJRPGZcas48G0uHhlgsdoBH6WmRNLG+FbcL4kS8YThGjCwlZWbuMAGeHOQ=
=YJPU
-END PGP SIGNATURE-

Bug#811093: hdf5: Please link against libaec-dev for libsz

[Gilles Filippini]

Dirk Eddelbuettel a écrit le 19/01/2016 19:34 :
> 
> On 19 January 2016 at 19:24, Gilles Filippini wrote:
> | Dirk Eddelbuettel a écrit le 19/01/2016 13:46 :
> | > 
> | > Hi Alastair,
> | > 
> | > On 15 January 2016 at 15:24, Alastair McKinstry wrote:
> | > | Source: hdf5
> | > | Severity: normal
> | > | 
> | > | libaec-dev has recently entered sid (and testing/backports). It is a 
> free implementation
> | > | of the SZLIB compression library, and provides a drop-in replacement 
> for the libsz library
> | > | used in HDF5, particularly for climate and weather data.
> | > 
> | > There is not a lot I can do in the _R_ package hdf5 (with source and 
> binary
> | > package r-cran-hdf5 within Debian, see [1] for both) which simply
> | > (build-)depends on libhdf5-dev/ 
> | > 
> | > Did you mean to file this against libhdf5-dev [2]?  Shall we reassign 
> this?
> | 
> | Erm... This is already assigned to the source package for libhdf5-dev, aka 
> hdf5 [3].
> | The source package for r-cran-hdf5 is... r-cran-hdf5, not hdf5 [4].
> 
> Which part of what I wrote in
> 
>_R_ package hdf5 (with source and binary package r-cran-hdf5 within
>Debian, see [1] for both)
> 
> was unclear?  We both say the same thing here.
> 
> But if the issue is question is assigned to the actual HDF5 library package,
> then we can simply close this.

Then I must admit I just don't understand what you're initial question
is about :/ Would you mind elaborating?

Thanks,

_g..

> 
> Dirk
> 
> | 
> | [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=hdf5
> | [4] https://packages.qa.debian.org/r/r-cran-hdf5.html
> | 
> | Thanks,
> | 
> | _g.
> | 
> | > 
> | > Dirk
> | > 
> | > [1] https://packages.debian.org/search?keywords=r-cran-hdf5
> | > 
> | > 
> | > | -- System Information:
> | > | Debian Release: 8.2
> | > |   APT prefers stable-updates
> | > |   APT policy: (500, 'stable-updates'), (500, 'stable')
> | > | Architecture: i386 (i686)
> | > | 
> | > | Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
> | > | Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) 
> (ignored: LC_ALL set to en_IE.UTF-8)
> | > | Shell: /bin/sh linked to /bin/dash
> | > | Init: systemd (via /run/systemd/system)
> | > | 
> | > 
> | 
> | 
> | [DELETED ATTACHMENT signature.asc, application/pgp-signature]
> 




signature.asc
Description: OpenPGP digital signature

Bug#811093: hdf5: Please link against libaec-dev for libsz

[Gilles Filippini]

Dirk Eddelbuettel a écrit le 19/01/2016 13:46 :
> 
> Hi Alastair,
> 
> On 15 January 2016 at 15:24, Alastair McKinstry wrote:
> | Source: hdf5
> | Severity: normal
> | 
> | libaec-dev has recently entered sid (and testing/backports). It is a free 
> implementation
> | of the SZLIB compression library, and provides a drop-in replacement for 
> the libsz library
> | used in HDF5, particularly for climate and weather data.
> 
> There is not a lot I can do in the _R_ package hdf5 (with source and binary
> package r-cran-hdf5 within Debian, see [1] for both) which simply
> (build-)depends on libhdf5-dev/ 
> 
> Did you mean to file this against libhdf5-dev [2]?  Shall we reassign this?

Erm... This is already assigned to the source package for libhdf5-dev, aka hdf5 
[3].
The source package for r-cran-hdf5 is... r-cran-hdf5, not hdf5 [4].

[3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=hdf5
[4] https://packages.qa.debian.org/r/r-cran-hdf5.html

Thanks,

_g.

> 
> Dirk
> 
> [1] https://packages.debian.org/search?keywords=r-cran-hdf5
> 
> 
> | -- System Information:
> | Debian Release: 8.2
> |   APT prefers stable-updates
> |   APT policy: (500, 'stable-updates'), (500, 'stable')
> | Architecture: i386 (i686)
> | 
> | Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
> | Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_IE.UTF-8)
> | Shell: /bin/sh linked to /bin/dash
> | Init: systemd (via /run/systemd/system)
> | 
> 




signature.asc
Description: OpenPGP digital signature

Bug#808936: libmpich-dev: miss /usr/bin/mpif90.mpich

[Gilles Filippini]

Package: libmpich-dev
Version: 3.2-1
Severity: grave
Justification: renders package unusable

Hi,

With this last release libmpich-dev doesn't provide
/usr/bin/mpif90.mpich anymore, causing FTBFSs (at least for hdf5).

Thanks,

_g.

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

Kernel: Linux 4.2.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)




signature.asc
Description: OpenPGP digital signature

Bug#601135: Cannot be fixed without an example file

[Gilles Filippini]

Hi Sebastian,

Sebastian Leske a écrit le 08/12/2015 01:40 :
> thanks for bringing up this bug report.
> 
> Unfortunately, I think as it stands this bug will need to be closed as
> unreproducible.
> Without having the file the bug reporter used, it's next to impossible
> to tell what the problem was - in particular because there are different
> versions / variations of the Garmin file format.
> 
> To test Navit's Garmin map driver, I just randomly grabbed a Garmin map
> file off the Internet - I used the file from
> http://www.miscjunk.org/mj/mp_mnohv.html , specifically
> http://www.miscjunk.org/mj/downloads/mnohv_install.exe .
> Running it (e.g. with wine) produces a file 8801.img , which can be
> loaded as a Navit map (map entry with type="garmin", enabled="yes",
> data="/path/to/8801.img").
> 
> Then moving to coordinates 47.4874N 92.4679W shows the streets of
> Gilbert, Minnesota.
> 
> So the Garmin map driver (still) works in principle. Thus without a
> reproducible test case (including a map file), I propose to close this
> bug.

I confirm that the bug is reproducible. Back in 2010 the OP gave me
access to such a map file coming from a garmin GPS device. But I failed
solving the problem.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#805825: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 24/11/2015 16:03 :
> Control: tags -1 confirmed
> 
> On 22/11/15 21:34, Gilles Filippini wrote:
>> With release 1.8.16 of hdf5 currently in experimental, the soname of
>> the C++ library was bumped:
>> libhdf5-cpp-10 -> libhdf5-cpp-11
>>
>> This triggers a mini-transition. There are only two rdepends on
>> libhdf5-cpp-10. I've tested a rebluid of both against libhdf5 1.8.16:
>> * blasr  binnmu OK
>> * insighttoolkit4binnmu OK (sid only)
> 
> Go ahead.

Release 1.8.16+docs-1 uploaded to unstable.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#805825: transition: hdf5

[Gilles Filippini]

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

Hi,

With release 1.8.16 of hdf5 currently in experimental, the soname of
the C++ library was bumped:
libhdf5-cpp-10 -> libhdf5-cpp-11

This triggers a mini-transition. There are only two rdepends on
libhdf5-cpp-10. I've tested a rebluid of both against libhdf5 1.8.16:
* blasr binnmu OK
* insighttoolkit4   binnmu OK (sid only)

Ben file:

title = "hdf5";
is_affected = .depends ~ "libhdf5-cpp-10" | .depends ~ "libhdf5-cpp-11";
is_good = .depends ~ "libhdf5-cpp-11";
is_bad = .depends ~ "libhdf5-cpp-10";

Thanks in advance,

_g.

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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)

Bug#760301: openjdk-8: Missing links to jawt_md.h and jni_md.h in /usr/lib/jvm/java-8-openjdk-amd64/include

[Gilles Filippini]

Hi Matthias,

On Tue, 09 Sep 2014 19:01:05 +0200 Matthias Klose  wrote:
> Control: tags -1 + wontfix
> 
> this is done by intent. These compat symlinks were wrong in openjdk-7.

For further reference, could you give your rationale about it? I've just been 
bitten by this:

[INFO] /usr/lib/jvm/java-8-openjdk-arm64/include/jni.h:45:20: fatal error: 
jni_md.h: No such file or directory

Thanks in advance,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#798652: scilab: scilab doesn't work on ppc64el: could not find the Java configuration for the model <>

[Gilles Filippini]

Hi Erwan,

On Fri, 11 Sep 2015 15:45:19 +0200 Erwan Prioul
 wrote:
> Package: scilab
> Version: 5.5.2-1
> Severity: normal
> 
> While scilab is available on ppc64el, it doesn't actually work:
> > $ /usr/bin/scilab
> > Could not find the Java configuration for the model . Please 
> > contact us on http://bugzilla.scilab.org
> > /usr/bin/scilab-bin: error while loading shared libraries: libjava.so: 
> > cannot open shared object file: No such file or directory
> 
> I apply this patch to get rid of the error:
> > --- scilab-5.5.2.orig/bin/scilab
> > +++ scilab-5.5.2/bin/scilab
> > @@ -528,7 +528,7 @@
> >  "ppc"|"powerpc")
> >  proc="ppc"
> >  ;;
> > -"ppc64"|"ppc64el")
> > +"ppc64"|"ppc64el"|"ppc64le")
> >  proc="ppc64"
> >  ;;
> >  "s390")
> 
> Unfortunately, we then get another error:
> > $ /usr/bin/scilab
> > Could not create a Scilab main class. Error:
> > Exception in thread "main" java.lang.ExceptionInInitializerError
> > at javax.media.opengl.GLProfile.(GLProfile.java:120)
> > at org.scilab.modules.gui.SwingView.(Unknown Source)
> > at org.scilab.modules.gui.SwingView.registerSwingView(Unknown Source)
> > at org.scilab.modules.core.Scilab.(Unknown Source)
> > Caused by: java.lang.RuntimeException: Please port CPU detection to your 
> > platform (linux/ppc64)
> > at 
> > jogamp.common.os.PlatformPropsImpl.getCPUTypeImpl(PlatformPropsImpl.java:304)
> > at 
> > jogamp.common.os.PlatformPropsImpl.(PlatformPropsImpl.java:134)
> > ... 4 more
> > 
> > Scilab cannot create Scilab Java Main-Class (we have not been able to find 
> > the main Scilab class. Check if the Scilab and thirdparty packages are 
> > available).

Could you please give a try at release 5.5.2-2~exp3 currently in
unstable? A lot of work was done to have libgluegen2 and libjogl2-java
functional on ppc64el (see #779482). Unfortunately I can't test the
resulting scilab build myself because I don"t have access to a baremetal
ppc64el machine. A test on a porter box with VNC makes the X server
segfault but that could be a driver issue.

Thanks in advance,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798652: scilab: scilab doesn't work on ppc64el: could not find the Java configuration for the model <>

[Gilles Filippini]

On Tue, 20 Oct 2015 19:14:30 +0200 Gilles Filippini <p...@debian.org> >
Could you please give a try at release 5.5.2-2~exp3 currently in
> unstable?

Oops. Please read *experimental*.

Thanks,
_g.



signature.asc
Description: OpenPGP digital signature

Bug#779482: severity of 779482 is grave

[Gilles Filippini]

On Wed, 07 Oct 2015 17:42:23 +0200 Markus Koschany <a...@gambaru.de> wrote:
> Control: forwarded -1 https://jogamp.org/bugzilla/show_bug.cgi?id=1246
> 
> On Tue, 06 Oct 2015 23:53:17 +0200 Gilles Filippini <p...@debian.org> wrote:
> > For the record, I've pinged upstream and proposed a patch for ppc64el.
> > The good news is they seem responsive [1].
> > 
> > [1] <https://jogamp.org/bugzilla/show_bug.cgi?id=1246>
> > 
> > Unfortunately I couldn't test the usability of my patch yet, because I
> > didn't succeed with remote X display on ppc64el porterboxes :/

The release 2.3.2-1 in experimental was finally tested on a baremetal
ppc64el machine, and it works [1]. Many thanks to Frédéric Bonnard.

[1] <https://lists.debian.org/debian-powerpc/2015/10/msg00035.html>

_g.



signature.asc
Description: OpenPGP digital signature

Bug#801129: RM: sciscipy [ppc64el] -- ANAIS; Depends on scilab which is unusable on ppc64el

[Gilles Filippini]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The scilab source package now FTBFS on ppc64el (#801060). Even if it
could build, the resulting package is unusable (#798652) because it
depends on a java library (bluegen2) with explicitely no upstream
support for ppc64el (#779482).

All this is in the way of the ongoing hdf5 transition (#798256).

In this context I've had a ack from RT (pochu) to request a removal of
scilab from ppc64el. As sciscipy depends on scilab it implies its
removal from ppc64el first.

As a sidenote sciscipy has a very low popcon score (~100).

Thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWE+gfAAoJEO/obGx//s+DMr8H/jZZqKr95TvzKKjwO9jpgsk3
FiunFaDqHDm1JLmbrjk1lRnfKzZD5mPT7YANrlPTJaf2tSu/bq3F3EIyOXNud8Vb
oG64zZOgibpYF8RFLnEjBiCLIciJWeRdkcYZ8CHeRFmJqxRs6jwAIHTJx5KnY+66
MsBqai75b40QAnM71HvP19U/XPHh8R18aXk+lCXiSpZHNPjemCaWxEQ4F+bZiGwa
iPv6vFXhJ0gPpiCLr5F1juygyz42ygbQwG3YiaqH7WSX9izsZ4xE7Bc5fwcOJ5oo
rHfGWvUz7WglV8TEQHKok57QIocFGVDK5+SE1+Is/8D6IXWrSU4bPqJofh6B4Pk=
=MXJk
-END PGP SIGNATURE-

Bug#801152: RM: scilab [ppc64el] -- ANAIS; FTBFS and anyway unusable on ppc64el

[Gilles Filippini]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 801129

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

As already explained in #801129:
> The scilab source package now FTBFS on ppc64el (#801060). Even if it
> could build, the resulting package is unusable (#798652) because it
> depends on a java library (bluegen2) with explicitely no upstream
> support for ppc64el (#779482).

> All this is in the way of the ongoing hdf5 transition (#798256).

> In this context I've had a ack from RT (pochu) to request a removal of
> scilab from ppc64el.

Scilab has no arch dependent rdepends in ppc64el, except sciscipy for
which I filled RM resquest #801129.

Thanks,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWFEUAAAoJEO/obGx//s+DgmsH/RK2txQaLykfuzbCpWV7i3fh
htbGafQIJ7IBNFEWMzASKuarthGgfFrGsGO4q/x0uaxulshk8JqWEyMH0H87idpf
4AySOWptdm2k6WVBTHorPhVusrps4e/+RxXAifNufXP8qVZo1d4MyUvV0w0lU6mh
07K3b4C7JktgouarrXysHdovT2eugeO4bvBCLPOkdttzzNFrNRkAkfDxo14bXo1M
z4yRuDITIUAfVE9wn1k8/fKW+Oizryuw0E23/nbxRaWLKhouMBlt+NQ2aLOtgohZ
DgM+1/ohTcgsTPD9F3wRNVzuXSkjK2byhbF9rqkysyKQldWAbIQGtMVd2+2AENo=
=/29x
-END PGP SIGNATURE-

Bug#779482: severity of 779482 is grave

[Gilles Filippini]

For the record, I've pinged upstream and proposed a patch for ppc64el.
The good news is they seem responsive [1].

[1] 

Unfortunately I couldn't test the usability of my patch yet, because I
didn't succeed with remote X display on ppc64el porterboxes :/

thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Le 2015-10-06 11:07, Emilio Pozuelo Monfort a écrit :

On 05/10/15 23:02, Gilles Filippini wrote:

Please tell me in case of anything left blocking the transition.


There's #801060.


This one is really annoying. Scilab could build on ppc64el, but it would 
be unusable anyway because of #798652, blocked by #779482.
Then I'm in favor of removing scilab from ppc64el rather than providing 
a useless fix. What do you think?


Thanks,

_g.

Bug#801060: Fwd: Re: Bug#798256: transition: hdf5

[Gilles Filippini]

CCing #801060 for the record.

 Courriel original 
Objet: Re: Bug#798256: transition: hdf5
Date: 2015-10-06 12:59
De: Gilles Filippini <p...@debian.org>
À: Emilio Pozuelo Monfort <po...@debian.org>
Cc: 798...@bugs.debian.org, Emilio Pozuelo Monfort <poch...@gmail.com>

Le 2015-10-06 11:07, Emilio Pozuelo Monfort a écrit :

On 05/10/15 23:02, Gilles Filippini wrote:

Please tell me in case of anything left blocking the transition.


There's #801060.


This one is really annoying. Scilab could build on ppc64el, but it would 
be unusable anyway because of #798652, blocked by #779482.
Then I'm in favor of removing scilab from ppc64el rather than providing 
a useless fix. What do you think?


Thanks,

_g.

Bug#798256: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 05/10/2015 17:59 :
> Control: tag 798256 791067 + pending
> 
> On 05/10/15 17:13, Gilles Filippini wrote:
>> Hi,
>>
>> On Wed, 30 Sep 2015 10:04:48 +0200 Gilles Filippini <p...@debian.org> wrote:
>>> Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
>>>> Control: tags -1 confirmed
>>>>
>>>> On 21/09/15 13:08, Gilles Filippini wrote:
>>>>> Ping.
>>>>
>>>> I think we can do this now. Go for it.
>>>
>>> Release 1.8.15-patch1+docs-4 upploaded to unstable.
>>
>> I have pending fixes for FTBFS on hppa, ppc64 and hurd-i386.
> 
> Looks like hppa and hurd built hdf5 a few hours ago.
> 
>> Should I
>> upload them now or do you think this isn't needed for the transition to
>> complete?
> 
> This isn't needed because those architectures aren't in testing. Note that 
> hdf5
> already migrated, but now we're waiting for the rest of the rdeps to migrate 
> so
> the old libhdf5-8 can get removed. Should happen in the next few days if there
> aren't any problems.

Great.
Please tell me in case of anything left blocking the transition.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#800900: hurd-i386: changeset from r6489 breaks SIGBUS handling

[Gilles Filippini]

Hi,

I've reduced the testcase to the attached H5detect.c.
The behavior is different depending on whether we link with "-lpthread":

pini@exodar:~/tmp$ /usr/bin/gcc -o H5detect H5detect.c
pini@exodar:~/tmp$ ./H5detect
verify_signal_handlers for signal 10 did 5 tries. Found 2 failures and 3
successes
Signal handler sigbus_handler for signal 10 failed
pini@exodar:~/tmp$ /usr/bin/gcc -o H5detect H5detect.c -lpthread
pini@exodar:~/tmp$ ./H5detect
Bus error


If I comment out the fprintf statement line 60, both builds run fine.
o_O

Thanks,

_g.
#include 
#include 
#include 

static int sigbus_handler_called_g = 0;	/* how many times called */
static int signal_handler_tested_g = 0;	/* how many times tested */
static int verify_signal_handlers(int signum, void (*handler)(int));
static jmp_buf jbuf_g;

/*-
 * Function:	sigbus_handler
 *
 * Purpose:	Handler for SIGBUS. We use signal() instead of sigaction()
 *		because it's more portable to non-Posix systems. Although
 *		it's not nearly as nice to work with, it does the job for
 *		this simple stuff.
 *
 * Return:	Returns via H5LONGJMP to jbuf_g.
 *
 * Programmer:	Robb Matzke
 *		Thursday, March 18, 1999
 *
 * Modifications:
 *
 *-
 */
static void
sigbus_handler(int signo)
{
/* Use sigprocmask to unblock the signal if sigsetjmp/siglongjmp are not */
/* supported. */
sigset_t set;

sigemptyset();
sigaddset(, SIGBUS);
sigprocmask(SIG_UNBLOCK, , NULL);

sigbus_handler_called_g++;
signal(SIGBUS, sigbus_handler);
longjmp(jbuf_g, SIGBUS);
}


/* Verify the signal handler for signal signum works correctly multiple times.
 * One possible cause of failure is that the signal handling is blocked or
 * changed to SIG_DFL after H5LONGJMP.
 * Return  0 for success, -1 for failure.
 */
static int verify_signal_handlers(int signum, void (*handler)(int))
{		  
void	(*save_handler)(int) = signal(signum, handler);
int i, val;
int ntries=5;
volatile int nfailures=0;
volatile int nsuccesses=0;
	  
for (i=0;i blah\n"); */
	if (val==0)
	{
	/* send self the signal to trigger the handler */
	signal_handler_tested_g++;
	raise(signum);
	/* Should not reach here. Record error. */
	nfailures++;
	}else{
	if (val==signum){ 
		/* return from signum handler. Record a sucess. */
		nsuccesses++;
	}else{
		fprintf(stderr, "Unknown return value (%d) from setjmp",
		val);
		nfailures++;
	}
	}
}
/* restore save handler, check results and report failures */
signal(signum, save_handler);
if (nfailures>0 || nsuccesses != ntries){
	fprintf(stderr, "verify_signal_handlers for signal %d did %d tries. "
	   "Found %d failures and %d successes\n",
	   signum, ntries, nfailures, nsuccesses);
	return(-1);
}else{
	/* all succeeded */
	return(0);
}
}

/*-
 * Function:	main
 *
 * Purpose:	Main entry point.
 *
 * Return:	Success:	exit(0)
 *
 *		Failure:	exit(1)
 *
 * Programmer:	Robb Matzke
 *		mat...@llnl.gov
 *		Jun 12, 1996
 *
 * Modifications:
 *	Albert Cheng, 2004/05/20
 *	Some compilers, e.g., Intel C v7.0, took a long time to compile
 *  with optimization when a module routine contains many code lines.
 *  Divide up all those types detections macros into subroutines, both
 *  to avoid the compiler optimization error and cleaner codes.
 *
 *-
 */
int
main(void)
{
/* verify the SIGBUS and SIGSEGV handlers work properly */
if (verify_signal_handlers(SIGBUS, sigbus_handler) != 0) {
fprintf(stderr, "Signal handler %s for signal %d failed\n",
"sigbus_handler", SIGBUS);
}
return 0;
}


signature.asc
Description: OpenPGP digital signature

Bug#779482: severity of 779482 is grave

[Gilles Filippini]

Markus Koschany a écrit le 05/10/2015 13:02 :
> Am 05.10.2015 um 12:48 schrieb Emmanuel Bourg:
>> Le 05/10/2015 12:18, Markus Koschany a écrit :
> I think it's ok to initially build with arch:any as long as there is
> sufficient support from upstream. However if it turns out that some
> arch-dependent packages are unusable and upstream does not intend to fix
> this, we should not claim that we can. I think restricting the build to
> supported architectures is sensible then.
> 
> Like I said I don't know if those architectures are supported now. Back
> in April Tony wrote that upstream has started to work on architecture
> support.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779482#21
> 
> Perhaps something has changed in the latest version?

Yes, support was added for some architectures. Unfortunately not for
ppc64el.

BTW building gluegen2 for unsupported architectures leads to bugs like
#798652. It is quite misleading for our users to see scilab available on
ppc64el while not functional at all.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Hi,

On Wed, 30 Sep 2015 10:04:48 +0200 Gilles Filippini <p...@debian.org> wrote:
> Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
> > Control: tags -1 confirmed
> > 
> > On 21/09/15 13:08, Gilles Filippini wrote:
> >> Ping.
> > 
> > I think we can do this now. Go for it.
> 
> Release 1.8.15-patch1+docs-4 upploaded to unstable.

I have pending fixes for FTBFS on hppa, ppc64 and hurd-i386. Should I
upload them now or do you think this isn't needed for the transition to
complete?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#779482: severity of 779482 is grave

[Gilles Filippini]

Control: severity -1 grave

On Fri, 18 Sep 2015 17:49:54 +0200 Emmanuel Bourg 
wrote:
> severity 779482 important
> thanks

Setting back severity to grave because ppc64el is an official
architecture since novembre 2014 and there is no point in providing
gluegen2 for ppc64el if it is unusable.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#800900: hurd-i386: changeset from r6489 breaks SIGBUS handling

[Gilles Filippini]

Package: libc0.3
Version: 2.19-22
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

hdf5 recently started to FTBFS on hurd-i386 [1] with no source code
change since the last successful build.

[1] 


The error message says:
LD_LIBRARY_PATH="$LD_LIBRARY_PATH`echo -Wl,-z,relro |  \
sed -e 's/-L/:/g' -e 's/ //g'`"   \
 ./H5detect > H5Tinit.c  ||   \
(test $HDF5_Make_Ignore && echo "*** Error ignored") ||  \
(rm -f H5Tinit.c ; exit 1)
/bin/bash: line 4: 15290 Bus error   
LD_LIBRARY_PATH="$LD_LIBRARY_PATH`echo -Wl,-z,relro |  
sed -e 's/-L/:/g' -e 's/ //g'`" ./H5detect > H5Tinit.c
make[3]: *** [H5Tinit.c] Error 1

The Bus error comes from the H5detect execution. Normally the bus error
signal is intercepted by an ad'hoc handler set by H5detect, but that
doesn't work anymore. See H5detect.c after line 63 [2].

[2] 

I think the cause of this bus error is the upgrade of glibc from
2.19-19 to 2.19-22 because building with libc0.3 from glibc 2.19-19 is
successful.

Using bisection on a porterbox I've found out that the guilty commit is
r6489 [3].

[3] 

Unfortunately I'm not able to go further understanding the problem.

Could you please revert r6489 or help me fixing H5detect.c in case you
think it's broken?

Many thanks in advance,

_g.

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

Kernel: Linux 4.1.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-
Version: GnuPG v1

iQEcBAEBCAAGBQJWEWZ3AAoJEO/obGx//s+Dk3UIAIiDSGV7C70Y4G9IMdzwVowQ
vtdxl01WZCnK703mbU8MF7JNTyjI6UTSY/E1nMd3M5eUk2a4liAdhW3TSH4Orbgv
zTdCX7eMrM/2HQl/zPPh4Jb9gIc5qyWhDuyeT83obdc5POl9ElJR1gP0tXsX5GcL
DzRz+a6aa7ZDp+oeqYwDt2gUg+JFiVrpBtvjjwj4F0uq9BHCu7t8cjyi05kJ1cOU
ImieCqGd3JL5pIo3T2eOV4HTGDrbEO4Ugdzt7JhuTAx3kz2JxzjjGdjY4dBLCSjv
4miOajCmOwDhW24quBxoMAFMMeBwyLBGnZjHx0jLS3/4HfoQlHgpV1TaiFpopkc=
=i+My
-END PGP SIGNATURE-

Bug#800900: hurd-i386: changeset from r6489 breaks SIGBUS handling

[Gilles Filippini]

Samuel Thibault a écrit le 04/10/2015 21:19 :
> Hello,
> 
> Gilles Filippini, le Sun 04 Oct 2015 19:48:51 +0200, a écrit :
>> I think the cause of this bus error is the upgrade of glibc from
>> 2.19-19 to 2.19-22 because building with libc0.3 from glibc 2.19-19 is
>> successful.
>>
>> Using bisection on a porterbox I've found out that the guilty commit is
>> r6489 [3].
> 
> Thanks for the investigation!
> 
> That change indeed changes the implementation of raise().  Actually it's
> even a fix, but apparently there are side effects, I'll have a look.

I've had a closer look at H5detect.c and from what I understand it
relies heavily on C macros such as H5_HAVE_SIGSETJMP and
H5_HAVE_SIGLONGJMP. And it happens that these macros aren't defined
anywhere when using the autotools build system, while they are taken
care of by the cmake alternative build system.

Setting these macros by hand, H5detect doesn't fail on Bus error anymore.

Thus I think part of the problem lies in the hdf5 build configuration.
But still there is this glibc fix side effect to understand :/

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#800900: hurd-i386: changeset from r6489 breaks SIGBUS handling

[Gilles Filippini]

Gilles Filippini a écrit le 04/10/2015 22:43 :
> Samuel Thibault a écrit le 04/10/2015 21:19 :
>> Hello,
>>
>> Gilles Filippini, le Sun 04 Oct 2015 19:48:51 +0200, a écrit :
>>> I think the cause of this bus error is the upgrade of glibc from
>>> 2.19-19 to 2.19-22 because building with libc0.3 from glibc 2.19-19 is
>>> successful.
>>>
>>> Using bisection on a porterbox I've found out that the guilty commit is
>>> r6489 [3].
>>
>> Thanks for the investigation!
>>
>> That change indeed changes the implementation of raise().  Actually it's
>> even a fix, but apparently there are side effects, I'll have a look.
> 
> I've had a closer look at H5detect.c and from what I understand it
> relies heavily on C macros such as H5_HAVE_SIGSETJMP and
> H5_HAVE_SIGLONGJMP. And it happens that these macros aren't defined
> anywhere when using the autotools build system, while they are taken
> care of by the cmake alternative build system.
> 
> Setting these macros by hand, H5detect doesn't fail on Bus error anymore.
> 
> Thus I think part of the problem lies in the hdf5 build configuration.

Actually no. It appears that H5_ prefixed macro are correctly defined
into src/H5pubconf.h. This file is created from src/H5config.h by a
configure snippet which prefixes each macro with H5_.

H5_HAVE_SIGSETJMP isn't defined because:

configure:25814: checking for sigsetjmp
configure:25814: /usr/bin/gcc -o conftest -g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-D_FILE_OFFSET_BITS=64   -D_FORTIFY_SOURCE=2  -Wl,-z,relro conftest.c
-lpthread -lz -ldl -lm  >&5
/tmp/ccEVZwR6.o: In function `main':
/home/pini/hdf5-1.8.15-patch1+docs/debian/build/conftest.c:160:
undefined reference to `sigsetjmp'
collect2: error: ld returned 1 exit status

It's weird that sigsetjmp isn't correctly detected but it's not the side
effect we are looking for, because successful build logs have "checking
for sigsetjmp... no" as well

Can't go further right now because exodar.debian.net tells me "Computer
bought the farm". I hope I'm not the cause of this system failure with
my repeated signal handling tests :/

Samuel Thibault a écrit le 05/10/2015 00:20 :> I'm building the newest
hdf5 against libc0.3 2.19-19+b1 so that the
> binNMUs can take place, but I'll continue investigating.

Thanks!

_g.





signature.asc
Description: OpenPGP digital signature

Bug#800632: scilab: diff for NMU version 5.5.2-1.1

[Gilles Filippini]

Control: tags 800632 + patch
Control: tags 800632 + pending

Dear maintainer,

I've prepared an NMU for scilab (versioned as 5.5.2-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -Nru scilab-5.5.2/debian/changelog scilab-5.5.2/debian/changelog
--- scilab-5.5.2/debian/changelog   2015-04-27 18:30:06.0 +0200
+++ scilab-5.5.2/debian/changelog   2015-10-03 10:06:56.0 +0200
@@ -1,3 +1,14 @@
+scilab (5.5.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Three new patches to cope with java libs API changes:
+- xmlgraphics-commons-2.0.diff
+- fop-2.0.diff
+- batik-1.8.diff
+(closes: #800632).
+
+ -- Gilles Filippini <p...@debian.org>  Sat, 03 Oct 2015 10:06:53 +0200
+
 scilab (5.5.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru scilab-5.5.2/debian/patches/batik-1.8.diff 
scilab-5.5.2/debian/patches/batik-1.8.diff
--- scilab-5.5.2/debian/patches/batik-1.8.diff  1970-01-01 01:00:00.0 
+0100
+++ scilab-5.5.2/debian/patches/batik-1.8.diff  2015-10-03 09:45:21.0 
+0200
@@ -0,0 +1,16 @@
+Description: adapt to batik 1.8 API
+ New path for class SAXSVGDocumentFactory.
+Author: Gilles Filippini <p...@debian.org>
+Index: 
scilab-5.5.2/modules/graph/src/java/org/scilab/modules/graph/utils/ScilabGraphUtils.java
+===
+--- 
scilab-5.5.2.orig/modules/graph/src/java/org/scilab/modules/graph/utils/ScilabGraphUtils.java
 
scilab-5.5.2/modules/graph/src/java/org/scilab/modules/graph/utils/ScilabGraphUtils.java
+@@ -28,7 +28,7 @@ import org.apache.batik.bridge.DocumentL
+ import org.apache.batik.bridge.GVTBuilder;
+ import org.apache.batik.bridge.UserAgent;
+ import org.apache.batik.bridge.UserAgentAdapter;
+-import org.apache.batik.dom.svg.SAXSVGDocumentFactory;
++import org.apache.batik.anim.dom.SAXSVGDocumentFactory;
+ import org.apache.batik.gvt.GraphicsNode;
+ import org.apache.batik.util.XMLResourceDescriptor;
+ import org.scilab.forge.jlatexmath.ParseException;
diff -Nru scilab-5.5.2/debian/patches/fop-2.0.diff 
scilab-5.5.2/debian/patches/fop-2.0.diff
--- scilab-5.5.2/debian/patches/fop-2.0.diff1970-01-01 01:00:00.0 
+0100
+++ scilab-5.5.2/debian/patches/fop-2.0.diff2015-10-03 12:22:59.0 
+0200
@@ -0,0 +1,57 @@
+Description: adapt to fop 2.0 API
+ New way to configure and create Fop. See rationals there:
+ <http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration>
+Author: Gilles Filippini <p...@debian.org>
+Index: 
scilab-5.5.2/modules/scinotes/src/java/org/scilab/modules/scinotes/utils/CodeExporter.java
+===
+--- 
scilab-5.5.2.orig/modules/scinotes/src/java/org/scilab/modules/scinotes/utils/CodeExporter.java
 
scilab-5.5.2/modules/scinotes/src/java/org/scilab/modules/scinotes/utils/CodeExporter.java
+@@ -36,6 +36,8 @@ import org.scilab.modules.helptools.scil
+ import org.scilab.modules.gui.messagebox.ScilabModalDialog;
+ 
+ import org.apache.fop.apps.FopFactory;
++import org.apache.fop.apps.FopFactoryBuilder;
++import org.apache.fop.apps.FopConfParser;
+ import org.apache.fop.apps.Fop;
+ import org.apache.fop.apps.FOUserAgent;
+ import org.apache.fop.apps.MimeConstants;
+@@ -114,11 +116,11 @@ public class CodeExporter extends FOCode
+  * @param format the page format
+  */
+ public void convert(String code, int[] lineNumberArray, String fileName, 
String type, String title, PageFormat format) {
+-FopFactory fopFactory = FopFactory.newInstance();
+ OutputStream out = null;
+ 
+ try {
+-fopFactory.setUserConfig(new File(ScilabConstants.SCI + 
"/modules/helptools/etc/fopconf.xml"));
++FopFactoryBuilder fopFactoryBuilder = new FopConfParser(new 
File(ScilabConstants.SCI + 
"/modules/helptools/etc/fopconf.xml")).getFopFactoryBuilder();
++FopFactory fopFactory = fopFactoryBuilder.build();
+ FOUserAgent userAgent = fopFactory.newFOUserAgent();
+ userAgent.setProducer(CREATOR);
+ userAgent.setTitle(title);
+Index: 
scilab-5.5.2/modules/helptools/src/java/org/scilab/modules/helptools/FopConverter.java
+===
+--- 
scilab-5.5.2.orig/modules/helptools/src/java/org/scilab/modules/helptools/FopConverter.java
 
scilab-5.5.2/modules/helptools/src/java/org/scilab/modules/helptools/FopConverter.java
+@@ -19,6 +19,8 @@ import javax.xml.transform.stream.Stream
+ import org.apache.fop.apps.FOPException;
+ import org.apache.fop.apps.Fop;
+ import org.apache.fop.apps.FopFactory;
++import org.apache.fop.apps.FopFactoryBuilder;
++import org.apache.fop.apps.FopConfParser;
+ import org.apache.fop.apps.FormattingResults;
+ import org.apache.fop.apps.MimeConstants;
+ import org.scilab.forge.jlatexmath.fop.JLaTeXMat

Bug#800632: scilab: diff for NMU version 5.5.2-1.1

[Gilles Filippini]

Sylvestre Ledru a écrit le 03/10/2015 13:28 :
> No, go ahead, no need to wait :)

Ack.
Rescheduling to 0-day.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798652: scilab: scilab doesn't work on ppc64el: could not find the Java configuration for the model <>

[Gilles Filippini]

On Fri, 11 Sep 2015 16:40:40 +0200 Sylvestre Ledru
 wrote:
> Jogl has to be updated too. I think there is a familiar patch for another 
> arch. 

No, this is gluegen2. And looking at the source I fail to see any
ppc64el support. Then, is there still a point for scilab to build on
ppc64el?

Thanks,

_g.

> 
> Le 11 septembre 2015 15:45:19 GMT+02:00, Erwan Prioul 
>  a écrit :
> >Package: scilab
> >Version: 5.5.2-1
> >Severity: normal
> >
> >While scilab is available on ppc64el, it doesn't actually work:
> >> $ /usr/bin/scilab
> >> Could not find the Java configuration for the model . Please
> >contact us on http://bugzilla.scilab.org
> >> /usr/bin/scilab-bin: error while loading shared libraries:
> >libjava.so: cannot open shared object file: No such file or directory
> >
> >I apply this patch to get rid of the error:
> >> --- scilab-5.5.2.orig/bin/scilab
> >> +++ scilab-5.5.2/bin/scilab
> >> @@ -528,7 +528,7 @@
> >>  "ppc"|"powerpc")
> >>  proc="ppc"
> >>  ;;
> >> -"ppc64"|"ppc64el")
> >> +"ppc64"|"ppc64el"|"ppc64le")
> >>  proc="ppc64"
> >>  ;;
> >>  "s390")
> >
> >Unfortunately, we then get another error:
> >> $ /usr/bin/scilab
> >> Could not create a Scilab main class. Error:
> >> Exception in thread "main" java.lang.ExceptionInInitializerError
> >>at javax.media.opengl.GLProfile.(GLProfile.java:120)
> >>at org.scilab.modules.gui.SwingView.(Unknown Source)
> >>at org.scilab.modules.gui.SwingView.registerSwingView(Unknown
> >Source)
> >>at org.scilab.modules.core.Scilab.(Unknown Source)
> >> Caused by: java.lang.RuntimeException: Please port CPU detection to
> >your platform (linux/ppc64)
> >>at
> >jogamp.common.os.PlatformPropsImpl.getCPUTypeImpl(PlatformPropsImpl.java:304)
> >>at
> >jogamp.common.os.PlatformPropsImpl.(PlatformPropsImpl.java:134)
> >>... 4 more
> >> 
> >> Scilab cannot create Scilab Java Main-Class (we have not been able to
> >find the main Scilab class. Check if the Scilab and thirdparty packages
> >are available).
> >
> >Thanks,
> >Erwan.
> >
> >-- 
> >debian-science-maintainers mailing list
> >debian-science-maintain...@lists.alioth.debian.org
> >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
> 
> -- 
> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.



signature.asc
Description: OpenPGP digital signature

Bug#800466: pytables: diff for NMU version 3.2.1-1.1

[Gilles Filippini]

Control: tags 800466 + patch
Control: tags 800466 + pending

[Replace XX with correct value]
Dear maintainer,

I've prepared an NMU for pytables (versioned as 3.2.1-1.1) and
uploaded it to DELAYED/XX. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -Nru pytables-3.2.1/debian/changelog pytables-3.2.1/debian/changelog
--- pytables-3.2.1/debian/changelog 2015-08-14 21:42:34.0 +0200
+++ pytables-3.2.1/debian/changelog 2015-10-02 20:01:14.0 +0200
@@ -1,3 +1,12 @@
+pytables (3.2.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch: 0006-Fix-upstream-issue-481.patch
+Fix test suite errors such as 'ValueError: could not broadcast
+input array from shape (2) into shape (0)' (closes: #800466).
+
+ -- Gilles Filippini <p...@debian.org>  Fri, 02 Oct 2015 20:01:01 +0200
+
 pytables (3.2.1-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru pytables-3.2.1/debian/patches/0006-Fix-upstream-issue-481.patch 
pytables-3.2.1/debian/patches/0006-Fix-upstream-issue-481.patch
--- pytables-3.2.1/debian/patches/0006-Fix-upstream-issue-481.patch 
1970-01-01 01:00:00.0 +0100
+++ pytables-3.2.1/debian/patches/0006-Fix-upstream-issue-481.patch 
2015-09-29 21:06:16.0 +0200
@@ -0,0 +1,40 @@
+From 44dba04d7d72f150a91553f4eb455684dfef0913 Mon Sep 17 00:00:00 2001
+From: Andrea Bedini <and...@andreabedini.com>
+Date: Wed, 12 Aug 2015 10:09:43 +1000
+Subject: [PATCH] Be careful with signs while interating backward.
+
+This is a quick and possibily partial fix for #481.
+
+It seems that C dictates that istopb - istartb - 1 is an unsigned
+expression (because istartb is unsigned and istopb is signed but not big
+enough to contain istartb).
+
+With this fix I am betting that 1 - istopb + istartb is non-negative. It seems
+to work but this function should be rewritten more clearly.
+---
+ tables/tableextension.pyx | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+Index: pytables-3.2.1/tables/tableextension.pyx
+===
+--- pytables-3.2.1.orig/tables/tableextension.pyx
 pytables-3.2.1/tables/tableextension.pyx
+@@ -1241,7 +1241,7 @@ cdef class Row:
+ istartb = (j+istep) % inrowsinbuf
+ inextelement = inextelement + istep
+ i = i + inrowsinbuf
+-elif 0 > istep:
++elif istep < 0:
+   inrowsinbuf = self.nrowsinbuf
+   #istartb = self.startb
+   istartb = self.nrowsinbuf - 1
+@@ -1258,7 +1258,8 @@ cdef class Row:
+   i = i - inrowsinbuf
+   continue
+ # Compute the end for this iteration
+-stopr = startr + ((istopb - istartb - 1) / istep)
++# (we know we are going backward so try to keep indices positive)
++stopr = startr + (1 - istopb + istartb) / (-istep)
+ # Read a chunk
+ inrowsread = inrowsread + self.table._read_records(i - inrowsinbuf + 
1,
+inrowsinbuf, 
self.iobuf)
diff -Nru pytables-3.2.1/debian/patches/series 
pytables-3.2.1/debian/patches/series
--- pytables-3.2.1/debian/patches/series2015-08-14 21:42:34.0 
+0200
+++ pytables-3.2.1/debian/patches/series2015-09-29 21:05:56.0 
+0200
@@ -3,3 +3,4 @@
 0003-Never-use-the-msse2-flag-explicitly.patch
 0004-Do-not-fetch-icons-for-external-web-sites.patch
 0005-Fix-setitem-return-value.patch
+0006-Fix-upstream-issue-481.patch

Bug#800466: pytables: diff for NMU version 3.2.1-1.1

[Gilles Filippini]

Scott Kitterman a écrit le 02/10/2015 23:48 :
> On Friday, October 02, 2015 08:52:47 PM Gilles Filippini wrote:
>> Control: tags 800466 + patch
>> Control: tags 800466 + pending
>>
>> [Replace XX with correct value]
>> Dear maintainer,
>>
>> I've prepared an NMU for pytables (versioned as 3.2.1-1.1) and
>> uploaded it to DELAYED/XX. Please feel free to tell me if I
>> should delay it longer.
> 
> I'm not sure what value of XX you used, but would you please reschedule for 
> DELAYED/1 so that it'll go in tomorrow.  That's when we'll want it for the 
> python3.5 transition.
> 
> Scott K
> 

Sorry about that. I had to retry several times sending the email with
nmudiff, and I eventually forgot to set the XX value :(

I used XX=2.
Rescheduling for DELAYED/1.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
> Control: tags -1 confirmed
> 
> On 21/09/15 13:08, Gilles Filippini wrote:
>> Ping.
> 
> I think we can do this now. Go for it.

Release 1.8.15-patch1+docs-4 upploaded to unstable.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#800466: FTBFS: 4 failed tests with ValueError: could not broadcast input array

[Gilles Filippini]

On Tue, 29 Sep 2015 20:46:42 +0200 Gilles Filippini <p...@debian.org> wrote:
> Source: pytables
> Version: 3.2.1-1
> Severity: serious
> Justification: FTBFS
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> pytables FTBFS on a clean amd64 sid chroot. 4 tests fail with similar
> error messages:
> ==
> ERROR: None (tables.tests.test_tables.RecArrayRangeTestCase)
> - --
> Traceback (most recent call last):
>   File 
> "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py",
>  line 2169, in test01a_range
> self.check_range()
>   File 
> "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py",
>  line 2042, in check_range
> recarray = table.read(self.start, self.stop, self.step)
>   File 
> "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/table.py", line 
> 1965, in read
> arr = self._read(start, stop, step, field, out)
>   File 
> "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-2.7/tables/table.py", line 
> 1887, in _read
> self.row._fill_col(result, start, stop, step, field)
>   File "tables/tableextension.pyx", line 1272, in 
> tables.tableextension.Row._fill_col (tables/tableextension.c:15021)
> ValueError: could not broadcast input array from shape (2) into shape (0)

This is upstream issue #481 [1] which was fixed by commit 44dba04 [2].

[1] <https://github.com/PyTables/PyTables/issues/481>
[2] 
<https://github.com/PyTables/PyTables/commit/44dba04d7d72f150a91553f4eb455684dfef0913.patch>

I've successfully tested this patch, but then a python3.5 related error occurs:

Ran 5734 tests in 147.360s

OK (skipped=42)
+ cd /tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5
+ env PYTHONPATH=. LOCPATH=/tmp/buildd/pytables-3.2.1/tmp-locales 
LC_ALL=en_US.UTF-8 python3.5 tables/tests/test_all.py -vvv
Traceback (most recent call last):
  File "tables/tests/test_all.py", line 10, in 
import tables
  File 
"/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5/tables/__init__.py", 
line 123, in 
from tables.file import File, open_file, copy_file, openFile, copyFile
  File "/tmp/buildd/pytables-3.2.1/build/lib.linux-x86_64-3.5/tables/file.py", 
line 31, in 
import numexpr
  File "/usr/lib/python3/dist-packages/numexpr/__init__.py", line 40, in 

from numexpr.expressions import E
  File "/usr/lib/python3/dist-packages/numexpr/expressions.py", line 45, in 

from numexpr import interpreter
ImportError: cannot import name 'interpreter'
debian/rules:58: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 1
make[1]: Leaving directory '/tmp/buildd/pytables-3.2.1'
debian/rules:26: recipe for target 'binary' failed
make: *** [binary] Error 2

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Ping.

Thanks,

_g.

On Mon, 07 Sep 2015 14:11:17 +0200 Gilles Filippini <p...@debian.org> wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> Now that the GCC-5 rebuilt hdf5 1.8.13 has made its way into testing I
> kindly request a transition slot for release 1.8.15 which comes with a
> soname bump (libhdf5-8 -> libhdf5-10).
> 
> hdf5 1.8.15 sits in experimental since june and was built against GCC-5.
> Out the 65+ affected packages reported by ben only 5 arent't binnmu
> ready:
> 
> fw4spl:
> #797475, #797481 - FTBFS unrelated to hdf5
> sid only
> 
> mapsembler2:
> #797526 - FTBFS with GCC-5
> Low popcon - no rdepends
> 
> gnudatalanguage:
> waiting for plplot - #789619
> sid only
> 
> feel++:
> #777848 - FTBFS with GCC-5
> sid only
> 
> insighttoolkit4:
> #797387 - FTBFS unrelated to HDF5
> sid only
> 
> 
> Ben file:
> 
> title = "hdf5";
> is_affected = .depends ~ /libhdf5.*-8/ | .depends ~ /libhdf5.*-10/;
> is_good = .depends ~ /libhdf5.*-10/;
> is_bad = .depends ~ /libhdf5.*-8/;
> 
> Thanks in advance,
> 
> _g.
> 
> 
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.1.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



signature.asc
Description: OpenPGP digital signature

Bug#797718: flann: transition may be needed for g++-5 ABIs

[Gilles Filippini]

Control: unblock -1 by 791067

On Tue, 1 Sep 2015 23:02:18 +0100 Simon McVittie  wrote:
> Source: flann
> Version: 1.8.4-4.1
> Severity: important
> Control: block -1 by 791067
> 
> Background[1]: libstdc++6 introduces a new ABI to conform to the
> C++11 standard, but keeps the old ABI to not break existing binaries.
> Packages which are built with g++-5 from experimental (not the one
> from testing/unstable) are using the new ABI.  Libraries built from
> this source package export some of the new __cxx11 or B5cxx11 symbols,
> dropping other symbols.  If these symbols are part of the API of
> the library, then this rebuild with g++-5 will trigger a transition
> for the library.
> 
> In the case of flann, std::string appears in header files that
> get installed, but it seems possible that all instances are inline
> (and hence do not affect the ABI). Someone who knows more C++ than me,
> such as the maintainer, should check whether a transition is needed.
> If in doubt, the safe option is to do the transition anyway (see
> 
> for justification).
> 
> The transition consists of renaming the affected library packages, adding a
> v5 suffix (libflann1.8v5). The SONAME should not be changed.
> 
> These follow-up transitions for libstdc++ are not going through exactly
> the normal transition procedure, because many entangled transitions are
> going on at the same time, and the usual ordered transition procedure
> does not scale that far. When all the C++ libraries on which this library
> depends have started their transitions in unstable if required, this
> library should do the same, closing this bug; the release team will deal
> with binNMUs as needed.
> 
> In the case of flann, if a transition is needed, it looks as though it
> will be necessary to wait for hdf5 (#791067).

No, it doesn't depend on the C++ API of HDF5.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#797718: flann: transition may be needed for g++-5 ABIs

[Gilles Filippini]

On Mon, 07 Sep 2015 08:44:46 +0200 Gilles Filippini <p...@debian.org> wrote:
> Control: unblock -1 by 791067
> 
> On Tue, 1 Sep 2015 23:02:18 +0100 Simon McVittie <s...@debian.org> wrote:
> > Source: flann
> > Version: 1.8.4-4.1
> > Severity: important
> > Control: block -1 by 791067
> > 
> > Background[1]: libstdc++6 introduces a new ABI to conform to the
> > C++11 standard, but keeps the old ABI to not break existing binaries.
> > Packages which are built with g++-5 from experimental (not the one
> > from testing/unstable) are using the new ABI.  Libraries built from
> > this source package export some of the new __cxx11 or B5cxx11 symbols,
> > dropping other symbols.  If these symbols are part of the API of
> > the library, then this rebuild with g++-5 will trigger a transition
> > for the library.
> > 
> > In the case of flann, std::string appears in header files that
> > get installed, but it seems possible that all instances are inline
> > (and hence do not affect the ABI). Someone who knows more C++ than me,
> > such as the maintainer, should check whether a transition is needed.
> > If in doubt, the safe option is to do the transition anyway (see
> > <https://lists.debian.org/debian-release/2015/08/msg00574.html>
> > for justification).

I've rebuilt flann locally with a .symbols file and it appears that
libflann1.8 does export cxx11 symbols.

> > 
> > The transition consists of renaming the affected library packages, adding a
> > v5 suffix (libflann1.8v5). The SONAME should not be changed.
> > 
> > These follow-up transitions for libstdc++ are not going through exactly
> > the normal transition procedure, because many entangled transitions are
> > going on at the same time, and the usual ordered transition procedure
> > does not scale that far. When all the C++ libraries on which this library
> > depends have started their transitions in unstable if required, this
> > library should do the same, closing this bug; the release team will deal
> > with binNMUs as needed.
> > 
> > In the case of flann, if a transition is needed, it looks as though it
> > will be necessary to wait for hdf5 (#791067).

The good news is that libflann1.8 doesn't have any reverse dependency. 4
packages (fcl, hugin, ompl, pcl) build-depends on libflann-dev but none
of the resulting binary packages actually depends on libflann1.8.

Then a binnmu for flann should suffice.

> No, it doesn't depend on the C++ API of HDF5.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Now that the GCC-5 rebuilt hdf5 1.8.13 has made its way into testing I
kindly request a transition slot for release 1.8.15 which comes with a
soname bump (libhdf5-8 -> libhdf5-10).

hdf5 1.8.15 sits in experimental since june and was built against GCC-5.
Out the 65+ affected packages reported by ben only 5 arent't binnmu
ready:

fw4spl:
#797475, #797481 - FTBFS unrelated to hdf5
sid only

mapsembler2:
#797526 - FTBFS with GCC-5
Low popcon - no rdepends

gnudatalanguage:
waiting for plplot - #789619
sid only

feel++:
#777848 - FTBFS with GCC-5
sid only

insighttoolkit4:
#797387 - FTBFS unrelated to HDF5
sid only


Ben file:

title = "hdf5";
is_affected = .depends ~ /libhdf5.*-8/ | .depends ~ /libhdf5.*-10/;
is_good = .depends ~ /libhdf5.*-10/;
is_bad = .depends ~ /libhdf5.*-8/;

Thanks in advance,

_g.


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

Kernel: Linux 4.1.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-
Version: GnuPG v1

iQEcBAEBCAAGBQJV7X7bAAoJEO/obGx//s+DYnMH/3aEhuC52YJETIDQHlgQGfOt
9rnup4O1a58is7U/SnrEjL9r3dB6Y7Qoj6/N+Kk0TB5UqPOeTVyfI9VqmJYxtwOo
SbR10NPngsvRUvDs/1So9y2Yyp98BSYAb9HiNw37Lzhhssh8TeMUcHMHDUIS61kL
WEzZ7dXd6HCCX15dAPux2BzYunTAjQuwMj8OEb+/Gp1pEaYISjuiagxI8h/rx8wi
UpdXAxS2F0ehLxFiEo+fgKtPEqb37Vk4q8mYX/ubBNGOomFDNL/dtNhHJO1tt9/c
g3oYoT7gLXqOb1P9f9t/WA5Puh2LJKTcNQQ+AyJ2s1FYG7WWwmgPzaGKM3sDKFU=
=aZzq
-END PGP SIGNATURE-

Bug#791067: hdf5: library transition may be needed when GCC 5 is the default

[Gilles Filippini]

Julien Cristau a écrit le 03/09/2015 07:26 :
> On Thu, Sep  3, 2015 at 01:26:35 +0200, Gilles Filippini wrote:
> 
>> So where does this 'MUST NOT' come from just now that all that work is over?
>>
> It comes from me wanting to get gcc-defaults migrated this week.  Which
> is incompatible with getting all hdf5 reverse depends rebuilt.  It would
> probably have been fine a month ago when this started, but not now.

One month ago was family vacation time. Anyway, if the gcc-default
transition is to take place this week I guess the libhdf5-10 transition
can wait.

Consider that hdf5 1.8.13 in unstable is GCC-5 ready since it has no
more C++ rdepends left in testing after your removal of fw4spl and
insighttoolkit4 yesterday.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#791067: hdf5: library transition may be needed when GCC 5 is the default

[Gilles Filippini]

Julien Cristau a écrit le 02/09/2015 17:56 :
> On Wed, Sep  2, 2015 at 14:49:18 +0200, Sebastiaan Couwenberg wrote:
> 
>> On 02-09-15 14:37, Gilles Filippini wrote:
>>> Gilles Filippini a écrit le 28/08/2015 00:12 :
>>>> Sebastiaan Couwenberg a écrit le 27/08/2015 10:17 :
>>>>> I suggest to reassign the hdf5 transition issue back to 
>>>>> release.debian.org, because I would also like to see a single
>>>>> hdf5 transition instead of two (I made the same decisions for
>>>>> netcdf & geos).
>>>>
>>>> Yes, I'll do that *after* having the rdeps checked to avoid
>>>> useless ping pong game. I've started tracking progress on
>>>> titanpad[1] in case anybody wants to help.
>>>>
>>>> [1] <https://titanpad.com/gpirV5ouad>
>>>
>>> I've tested a rebuild of all 68 rdepends reported on the auto-hdf5 
>>> transition page [1]. Only 5 of them aren't binnmu OK:
>>>
>>> [...]
>>>
>>> To me, HDF5 1.8.15 is now transition ready.
>>
>> Thanks for your work preparing the hdf5 transition, I'd say upload to
>> unstable as soon as possible. We should have done hdf5 before netcdf.
>>
> Does anything use the c++ hdf5 lib in Debian nowadays?  Last cycle it
> didn't have any rdeps.

AFAICS, there is only fw4spl and libinsighttoolkit4.7.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature