Debian Bug report logs - #756689
octave: [hdf5 transition] please support hdf5 1.8.13 new packaging layout

[Message part 1 (text/plain, inline)]
Source: octave
Version: 3.8.1-3
Severity: important
Tags: patch
User: pini@debian.org
Usertags: HDF5-transition

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

The hdf5 1.8.13 package in experimental features a new layout for
headers and libraries, so that all the binary packages are now
co-installable.

Please find attached a patch proposal to support both the current
and the new layouts.

Because this bug is in the way of the hdf5 transition I intend to NMU
in a few days. I apologize for the urge, and I hope this approach won't
offend you. Please tell me otherwise.

Kind regards,

_g.

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

Kernel: Linux 3.14-1-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJT2sbvAAoJEO/obGx//s+Dj5sIAJsTeDsr95f3P6YzHPJIY8C6
Y0sLO3V8VzAYvXmXGZWW/cdVRR4M0cwuKcQ2Jb9NCvkwccI6kAFrJ7l9WR++r79T
aX6eJFc0U2ZhwfIj5WGwGGcJoOXY+46huYFjkdROwamSifQhVJkabvBrJ0NSuX0M
A1WQaSGbKa4p5Fvrgs6EJLyXCwfu4oTU7QV02yl3Y821WmOD0YJOBXa28YzNb/ty
fxlW6ZuTHnZpoQBvc+M6BpZVNG1EjSP6IfaMsO5JIRHMIqGyEhFVdyHui/fB0icB
y52w2vsMpNMYUB62YxlM/wS9EYRCXpKWS4u1LIGeCfoTsAMWTbpXKNTsA/ktJAk=
=xHe+
-----END PGP SIGNATURE-----

[octave-3.8.1-3.1.debdiff (text/x-diff, attachment)]
Hi Gilles, 

On Fri, Aug 01, 2014 at 12:45:03AM +0200, Gilles Filippini wrote:
> Source: octave
> Version: 3.8.1-3
> Severity: important
> Tags: patch
> User: pini@debian.org
> Usertags: HDF5-transition
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> The hdf5 1.8.13 package in experimental features a new layout for
> headers and libraries, so that all the binary packages are now
> co-installable.

Thanks for moving forward with this. Just some questions
1) Should hdf5-flags.patch ad hdf5-mkoctfile.patch be forwarded to upstream? How Debian-specific
are they?
2) My understanding of the changes to debian/rules is that we are going
with the serial HDF5 version here for Octave. What if one wants to use
the parallel version in a .oct file (a binary module for Octave)? Will
this be possible?

Best, 
Thomas

> diff -Nru octave-3.8.1/debian/rules octave-3.8.1/debian/rules
> --- octave-3.8.1/debian/rules	2014-05-10 10:40:01.000000000 +0200
> +++ octave-3.8.1/debian/rules	2014-07-31 11:17:00.000000000 +0200
> @@ -36,6 +36,12 @@
>  # libraries, for example the mesa graphics stack which also uses LLVM.
>  JIT_FLAG := --disable-jit
>  
> +# HDF5 paths
> +ifneq ($(wildcard /usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial/libhdf5.so),)
> +  HDF5_FLAGS := --with-hdf5-includedir=/usr/include/hdf5/serial \
> +	--with-hdf5-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial
> +endif
> +
>  %:
>  	dh $@ --with autoreconf --parallel
>  
> @@ -44,7 +50,7 @@
>  
>  # override normal dh_auto_configure call to pass OpenMP flag to it (#631831)
>  override_dh_auto_configure:
> -	dh_auto_configure -- --enable-openmp $(WITH_JAVA_FLAGS) $(JIT_FLAG)
> +	dh_auto_configure -- --enable-openmp $(WITH_JAVA_FLAGS) $(JIT_FLAG) $(HDF5_FLAGS)
>  
>  # dh_auto_test tries to run "make test", so override it
>  override_dh_auto_test:

> _______________________________________________
> Pkg-octave-devel mailing list
> Pkg-octave-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel

[Message part 1 (text/plain, inline)]
Hi Thomas,

Thomas Weber a écrit , Le 04/08/2014 13:09:
> On Fri, Aug 01, 2014 at 12:45:03AM +0200, Gilles Filippini wrote:
>> Source: octave
>> Version: 3.8.1-3
>> Severity: important
>> Tags: patch
>> User: pini@debian.org
>> Usertags: HDF5-transition
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi,
>>
>> The hdf5 1.8.13 package in experimental features a new layout for
>> headers and libraries, so that all the binary packages are now
>> co-installable.
> 
> Thanks for moving forward with this. Just some questions
> 1) Should hdf5-flags.patch ad hdf5-mkoctfile.patch be forwarded to upstream? How Debian-specific
> are they?

These patches aren't Debian-specific. They help when HDF5 is installed
into a non standard path.

> 2) My understanding of the changes to debian/rules is that we are going
> with the serial HDF5 version here for Octave. What if one wants to use
> the parallel version in a .oct file (a binary module for Octave)? Will
> this be possible?

I don't have any knowledge about octave modules. What I can say for sure
is that the octave binary packages will be tied to the serial version of
HDF5. But nothing should prevent you to link a module against a parallel
version of the library. Both instances can coexist into the same
application now.

Thanks,

_g.

[signature.asc (application/pgp-signature, attachment)]
On Mon, Aug 4, 2014 at 11:54:02 +0000, Gilles Filippini wrote:
> Hi Thomas,
>
> Thomas Weber a écrit , Le 04/08/2014 13:09:
>> On Fri, Aug 01, 2014 at 12:45:03AM +0200, Gilles Filippini wrote:
>>> Source: octave
>>> Version: 3.8.1-3
>>> Severity: important
>>> Tags: patch
>>> User: pini@debian.org
>>> Usertags: HDF5-transition
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Hi,
>>>
>>> The hdf5 1.8.13 package in experimental features a new layout for
>>> headers and libraries, so that all the binary packages are now
>>> co-installable.
>>
>> Thanks for moving forward with this. Just some questions
>> 1) Should hdf5-flags.patch ad hdf5-mkoctfile.patch be forwarded to upstream? How Debian-specific
>> are they?
>
> These patches aren't Debian-specific. They help when HDF5 is installed
> into a non standard path.

Some similar changes to support non-standard HDF5 install paths were
already made upstream some time ago but have not been verified nor
released yet. See upstream bug #38928 [1]. I plan on testing
upstream's development branch with the hdf5 experimental packages to
see whether it is sufficient or whether these patches are also needed.
I'll report back here and on the upstream bug report with my findings.

[1] http://savannah.gnu.org/bugs/?38928

>> 2) My understanding of the changes to debian/rules is that we are going
>> with the serial HDF5 version here for Octave. What if one wants to use
>> the parallel version in a .oct file (a binary module for Octave)? Will
>> this be possible?
>
> I don't have any knowledge about octave modules. What I can say for sure
> is that the octave binary packages will be tied to the serial version of
> HDF5. But nothing should prevent you to link a module against a parallel
> version of the library. Both instances can coexist into the same
> application now.

So installing a parallel version of the library will neither hurt nor
help Octave's use of HDF5? And -dev packages can be co-installed?
Sounds good to me. Has my patch to hdf5 to bypass the C++ MPI API been
reverted, it sounds like it is no longer needed (and was introduced in
the context of Octave).

-- 
mike

[Message part 1 (text/plain, inline)]
Mike Miller a écrit , Le 04/08/2014 16:40:
> On Mon, Aug 4, 2014 at 11:54:02 +0000, Gilles Filippini wrote:
>> Hi Thomas,
>>
>> Thomas Weber a écrit , Le 04/08/2014 13:09:
>>> On Fri, Aug 01, 2014 at 12:45:03AM +0200, Gilles Filippini wrote:
>>>> Source: octave
>>>> Version: 3.8.1-3
>>>> Severity: important
>>>> Tags: patch
>>>> User: pini@debian.org
>>>> Usertags: HDF5-transition
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> Hi,
>>>>
>>>> The hdf5 1.8.13 package in experimental features a new layout for
>>>> headers and libraries, so that all the binary packages are now
>>>> co-installable.
>>>
>>> Thanks for moving forward with this. Just some questions
>>> 1) Should hdf5-flags.patch ad hdf5-mkoctfile.patch be forwarded to upstream? How Debian-specific
>>> are they?
>>
>> These patches aren't Debian-specific. They help when HDF5 is installed
>> into a non standard path.
> 
> Some similar changes to support non-standard HDF5 install paths were
> already made upstream some time ago but have not been verified nor
> released yet. See upstream bug #38928 [1]. I plan on testing
> upstream's development branch with the hdf5 experimental packages to
> see whether it is sufficient or whether these patches are also needed.
> I'll report back here and on the upstream bug report with my findings.
> 
> [1] http://savannah.gnu.org/bugs/?38928
> 
>>> 2) My understanding of the changes to debian/rules is that we are going
>>> with the serial HDF5 version here for Octave. What if one wants to use
>>> the parallel version in a .oct file (a binary module for Octave)? Will
>>> this be possible?
>>
>> I don't have any knowledge about octave modules. What I can say for sure
>> is that the octave binary packages will be tied to the serial version of
>> HDF5. But nothing should prevent you to link a module against a parallel
>> version of the library. Both instances can coexist into the same
>> application now.
> 
> So installing a parallel version of the library will neither hurt nor
> help Octave's use of HDF5?

Indeed.

> And -dev packages can be co-installed?

Yes. This is why the headers and libraries paths changed.

> Sounds good to me. Has my patch to hdf5 to bypass the C++ MPI API been
> reverted, it sounds like it is no longer needed (and was introduced in
> the context of Octave).

Yes, I dropped that patch.

Thanks,

_g.

[signature.asc (application/pgp-signature, attachment)]
On Mon, Aug 4, 2014 at 10:40:52 -0400, Mike Miller wrote:
> On Mon, Aug 4, 2014 at 11:54:02 +0000, Gilles Filippini wrote:
>> These patches aren't Debian-specific. They help when HDF5 is installed
>> into a non standard path.
>
> Some similar changes to support non-standard HDF5 install paths were
> already made upstream some time ago but have not been verified nor
> released yet. See upstream bug #38928 [1]. I plan on testing
> upstream's development branch with the hdf5 experimental packages to
> see whether it is sufficient or whether these patches are also needed.
> I'll report back here and on the upstream bug report with my findings.

I have started testing upstream with the new hdf5 packages. These or
similar changes will indeed need to be applied upstream, I have
reopened and commented on the upstream bug report and forwarded your
suggested patches there.

-- 
mike

[Message part 1 (text/plain, inline)]
Hi Mike,

Mike Miller a écrit , Le 06/08/2014 04:23:
> On Mon, Aug 4, 2014 at 10:40:52 -0400, Mike Miller wrote:
>> On Mon, Aug 4, 2014 at 11:54:02 +0000, Gilles Filippini wrote:
>>> These patches aren't Debian-specific. They help when HDF5 is installed
>>> into a non standard path.
>>
>> Some similar changes to support non-standard HDF5 install paths were
>> already made upstream some time ago but have not been verified nor
>> released yet. See upstream bug #38928 [1]. I plan on testing
>> upstream's development branch with the hdf5 experimental packages to
>> see whether it is sufficient or whether these patches are also needed.
>> I'll report back here and on the upstream bug report with my findings.
> 
> I have started testing upstream with the new hdf5 packages. These or
> similar changes will indeed need to be applied upstream, I have
> reopened and commented on the upstream bug report and forwarded your
> suggested patches there.

Thanks for that. In the mean time is it possible for you to upload a
fixed octave package to unstable to ease the transition?

Thanks in advance,

_g.

[signature.asc (application/pgp-signature, attachment)]
On Wed, Aug 6, 2014 at 08:03:14 +0200, Gilles Filippini wrote:
> Thanks for that. In the mean time is it possible for you to upload a
> fixed octave package to unstable to ease the transition?

I think one of us will get to uploading a fixed octave package soon,
there are other pending changes in git, and we don't want to hold up
the transition.

I haven't tested building octave rdeps with these patches, but I
assume that's the reason for hdf5-mkoctfile.patch right?. I'm curious
if the change to LDFLAGS is really necessary in the general case, or
is it only there for the one or two packages that intentionally link
to hdf5 themselves? I would think only the include path would be
required for almost all uses of mkoctfile, in which case it could look
more like mkoctfile-mpi.diff (which I think we can actually drop once
the hdf5 transition is done).

Thanks for your patience and your work on this transition,

-- 
mike

[Message part 1 (text/plain, inline)]
Hi Mike,

Sorry about the late answer. Connectivity is flaky on my holidays place.

Mike Miller a écrit , Le 08/08/2014 16:22:
> On Wed, Aug 6, 2014 at 08:03:14 +0200, Gilles Filippini wrote:
>> Thanks for that. In the mean time is it possible for you to upload a
>> fixed octave package to unstable to ease the transition?
> 
> I think one of us will get to uploading a fixed octave package soon,
> there are other pending changes in git, and we don't want to hold up
> the transition.
> 
> I haven't tested building octave rdeps with these patches, but I
> assume that's the reason for hdf5-mkoctfile.patch right?. I'm curious
> if the change to LDFLAGS is really necessary in the general case, or
> is it only there for the one or two packages that intentionally link
> to hdf5 themselves? I would think only the include path would be
> required for almost all uses of mkoctfile, in which case it could look
> more like mkoctfile-mpi.diff (which I think we can actually drop once
> the hdf5 transition is done).

Thanks for this feedback. I think you're right because I've had to set
CPPFLAGS only to build octave rdeps against an unpatched octave. I'll
test this ASAP and tell you.

> Thanks for your patience and your work on this transition,

Thanks,

_g.

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Gilles Filippini a écrit , Le 09/08/2014 17:57:
> Hi Mike,
> 
> Sorry about the late answer. Connectivity is flaky on my holidays place.
> 
> Mike Miller a écrit , Le 08/08/2014 16:22:
>> On Wed, Aug 6, 2014 at 08:03:14 +0200, Gilles Filippini wrote:
>>> Thanks for that. In the mean time is it possible for you to upload a
>>> fixed octave package to unstable to ease the transition?
>>
>> I think one of us will get to uploading a fixed octave package soon,
>> there are other pending changes in git, and we don't want to hold up
>> the transition.
>>
>> I haven't tested building octave rdeps with these patches, but I
>> assume that's the reason for hdf5-mkoctfile.patch right?. I'm curious
>> if the change to LDFLAGS is really necessary in the general case, or
>> is it only there for the one or two packages that intentionally link
>> to hdf5 themselves? I would think only the include path would be
>> required for almost all uses of mkoctfile, in which case it could look
>> more like mkoctfile-mpi.diff (which I think we can actually drop once
>> the hdf5 transition is done).
> 
> Thanks for this feedback. I think you're right because I've had to set
> CPPFLAGS only to build octave rdeps against an unpatched octave. I'll
> test this ASAP and tell you.

You were right. I've have to update hdf5-mkoctfile.patch to use INCFLAGS
instead of CPPFLAGS because the latter is superseded by existing
CPPFLAGS environment variable.

Please find attached an updated version of hdf5-mkoctfile.patch. I've
tested it against the build of dynare which is a rdep of liboctave-dev.

Thanks,

_g.

[hdf5-mkoctfile.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Gilles Filippini a écrit , Le 10/08/2014 10:37:
> Gilles Filippini a écrit , Le 09/08/2014 17:57:
>> Hi Mike,
>>
>> Sorry about the late answer. Connectivity is flaky on my holidays place.
>>
>> Mike Miller a écrit , Le 08/08/2014 16:22:
>>> On Wed, Aug 6, 2014 at 08:03:14 +0200, Gilles Filippini wrote:
>>>> Thanks for that. In the mean time is it possible for you to upload a
>>>> fixed octave package to unstable to ease the transition?
>>>
>>> I think one of us will get to uploading a fixed octave package soon,
>>> there are other pending changes in git, and we don't want to hold up
>>> the transition.
>>>
>>> I haven't tested building octave rdeps with these patches, but I
>>> assume that's the reason for hdf5-mkoctfile.patch right?. I'm curious
>>> if the change to LDFLAGS is really necessary in the general case, or
>>> is it only there for the one or two packages that intentionally link
>>> to hdf5 themselves? I would think only the include path would be
>>> required for almost all uses of mkoctfile, in which case it could look
>>> more like mkoctfile-mpi.diff (which I think we can actually drop once
>>> the hdf5 transition is done).
>>
>> Thanks for this feedback. I think you're right because I've had to set
>> CPPFLAGS only to build octave rdeps against an unpatched octave. I'll
>> test this ASAP and tell you.
> 
> You were right. I've have to update hdf5-mkoctfile.patch to use INCFLAGS
> instead of CPPFLAGS because the latter is superseded by existing
> CPPFLAGS environment variable.
> 
> Please find attached an updated version of hdf5-mkoctfile.patch. I've
> tested it against the build of dynare which is a rdep of liboctave-dev.

Updated debdiff attached.

I'd appreciate if you could upload these fixes very soon: octave is now
the last package in the way of the transition. The others are to hit
unstable by tomorrow.

If you prefer I upload an NMU please tell me.

Thanks,

_g.

[octave-3.8.1-3.1.debdiff (text/plain, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Le lundi 11 août 2014 à 10:56 +0200, Gilles Filippini a écrit :
> Gilles Filippini a écrit , Le 10/08/2014 10:37:
> > Gilles Filippini a écrit , Le 09/08/2014 17:57:
> >> Mike Miller a écrit , Le 08/08/2014 16:22:
> >>> On Wed, Aug 6, 2014 at 08:03:14 +0200, Gilles Filippini wrote:
> >>>> Thanks for that. In the mean time is it possible for you to upload a
> >>>> fixed octave package to unstable to ease the transition?
> >>>
> >>> I think one of us will get to uploading a fixed octave package soon,
> >>> there are other pending changes in git, and we don't want to hold up
> >>> the transition.
> >>>
> >>> I haven't tested building octave rdeps with these patches, but I
> >>> assume that's the reason for hdf5-mkoctfile.patch right?. I'm curious
> >>> if the change to LDFLAGS is really necessary in the general case, or
> >>> is it only there for the one or two packages that intentionally link
> >>> to hdf5 themselves? I would think only the include path would be
> >>> required for almost all uses of mkoctfile, in which case it could look
> >>> more like mkoctfile-mpi.diff (which I think we can actually drop once
> >>> the hdf5 transition is done).
> >>
> >> Thanks for this feedback. I think you're right because I've had to set
> >> CPPFLAGS only to build octave rdeps against an unpatched octave. I'll
> >> test this ASAP and tell you.
> > 
> > You were right. I've have to update hdf5-mkoctfile.patch to use INCFLAGS
> > instead of CPPFLAGS because the latter is superseded by existing
> > CPPFLAGS environment variable.
> > 
> > Please find attached an updated version of hdf5-mkoctfile.patch. I've
> > tested it against the build of dynare which is a rdep of liboctave-dev.
> 
> Updated debdiff attached.
> 
> I'd appreciate if you could upload these fixes very soon: octave is now
> the last package in the way of the transition. The others are to hit
> unstable by tomorrow.
> 
> If you prefer I upload an NMU please tell me.

Thanks for taking care of this transition.

I will upload the patch, but ideally I would like it to wait for the
next upstream release. The 3.8.2 release should come very soon, since it
is already tagged in upstream VCS. Whatever happens, I commit to
uploading your patch before the end of the week.

Best,	

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

tag 756689 pending
thanks

Date: Thu Aug 14 12:10:05 2014 +0200
Author: Gilles Filippini <pini@debian.org>
Commit ID: bbe9c8656e0691a89978ef41ac6ef1b4e5f70134
Commit URL: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff;h=bbe9c8656e0691a89978ef41ac6ef1b4e5f70134
Patch URL: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff_plain;h=bbe9c8656e0691a89978ef41ac6ef1b4e5f70134

    Support hdf5 1.8.13 new packaging layout.

    New patches:
     - hdf5-flags.patch to fix a couple of makefiles regarding
       new paths;
     - hdf5-mkoctfile.patch to fix hdf5 path when building octave
       modules.

    Closes: #756689
    Git-Dch: Full

Source: octave
Source-Version: 3.8.2-1

We believe that the bug you reported is fixed in the latest version of
octave, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 756689@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sébastien Villemot <sebastien@debian.org> (supplier of updated octave package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 14 Aug 2014 12:19:21 +0200
Source: octave
Binary: octave octave-dbg octave-common octave-doc octave-htmldoc octave-info liboctave2 liboctave-dev
Architecture: source all
Version: 3.8.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Octave Group <pkg-octave-devel@lists.alioth.debian.org>
Changed-By: Sébastien Villemot <sebastien@debian.org>
Description:
 liboctave-dev - Development files for the GNU Octave language
 liboctave2 - Shared libraries of the GNU Octave language
 octave     - GNU Octave language for numerical computations
 octave-common - architecture-independent files for octave
 octave-dbg - Debug symbols for octave
 octave-doc - PDF documentation on the GNU Octave language
 octave-htmldoc - HTML documentation on the GNU Octave language
 octave-info - GNU Info documentation on the GNU Octave language
Closes: 746924 755882 756689 757237
Changes:
 octave (3.8.2-1) unstable; urgency=medium
 .
   [ Sébastien Villemot ]
   * Imported Upstream version 3.8.2
     - statistics() function adapted to new signature of kurtosis() and
       skewness() functions. (Closes: #755882)
     - no longer pass -mieee flag to moc-qt4, should fix FTBFS on alpha.
       (Closes: #746924)
   * debian/copyright: reflect upstream changes.
   * Remove Thomas Weber from Uploaders. Thanks Thomas for your work!
   * Recommend OpenBLAS over ATLAS as the optimized BLAS library.
     OpenBLAS is a better default because its generic binary is able to
     dynamically select the kernel specialized for the current CPU, while ATLAS
     needs to be recompiled. However, OpenBLAS is not present on some
     architectures, so ATLAS will remain the default on those.
   * Allow virtual packages liblapack.so and libblas.so to satisfy dependencies
     of liboctave-dev. (Closes: #757237)
 .
   [ Gilles Filippini ]
   * Support hdf5 1.8.13 new packaging layout. (Closes: #756689)
     New patches:
     - hdf5-flags.patch to fix a couple of makefiles regarding
       new paths;
     - hdf5-mkoctfile.patch to fix hdf5 path when building octave
       modules.
Checksums-Sha1:
 2d189d00a2f20a96dce163ca072ea6c2ad3c98f3 2952 octave_3.8.2-1.dsc
 02c38e0f69bce4e6dd7be7d301898347085d9c2d 17834980 octave_3.8.2.orig.tar.bz2
 f7f524cf1a6b083c3c5d33295a71779059599448 58612 octave_3.8.2-1.debian.tar.xz
 84d2b604d975fef66265ff9c31fff84b4f3b0607 1379570 octave-common_3.8.2-1_all.deb
 6deda309e7c1bdfb4605b876acfa22a42918b5f7 3897982 octave-doc_3.8.2-1_all.deb
 acafcb9c20809ec7a279e7576e7c8c698c575b32 1749148 octave-htmldoc_3.8.2-1_all.deb
 0c5a99c3b49a2f77f6756d7414360cf5be767361 1070264 octave-info_3.8.2-1_all.deb
Checksums-Sha256:
 2521c21a3b56dd907e90e9ed6ff81218bf41cc4c42d28fca20aac0e1cf4af33f 2952 octave_3.8.2-1.dsc
 83bbd701aab04e7e57d0d5b8373dd54719bebb64ce0a850e69bf3d7454f33bae 17834980 octave_3.8.2.orig.tar.bz2
 91ced5bc569cfb4c8cfe1f2ba8fcfbe55693057bb554a7dbab68a295cdf4095b 58612 octave_3.8.2-1.debian.tar.xz
 2665b815fc841145b2740ea4a26acf917293f9a1e85933b6d9ba051eb45c65bc 1379570 octave-common_3.8.2-1_all.deb
 8a293b5c9019d9421580f143e5fab8de03c9911f252a0e2b40aa91db557a1818 3897982 octave-doc_3.8.2-1_all.deb
 5042a701e022ec51cd38181d1798b30280a4933f787cfeede8a72d0fd3e70e85 1749148 octave-htmldoc_3.8.2-1_all.deb
 61c377c6e922506d7ee51942c632569ae858e2aa74381466e93e92d960d38141 1070264 octave-info_3.8.2-1_all.deb
Files:
 4cb8030a385f3ad8576aeb328451d867 1379570 math optional octave-common_3.8.2-1_all.deb
 cffe1ab8b10a39b3a2955d1ca61be0cd 3897982 doc optional octave-doc_3.8.2-1_all.deb
 3807abea391ef61187007e43bce38db0 1749148 doc optional octave-htmldoc_3.8.2-1_all.deb
 43bc372e9561e7762cd4b331b268f6cd 1070264 doc optional octave-info_3.8.2-1_all.deb
 a93dee1ab7278e83c0550f2d97e8ca62 2952 math optional octave_3.8.2-1.dsc
 188bd97e22054f9c62701ee0e6800dc1 17834980 math optional octave_3.8.2.orig.tar.bz2
 7aca82671224b236623ad530862c57b7 58612 math optional octave_3.8.2-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJT7KJwAAoJECzs6TUOzr5KMAkQAJepewcaRUjxtAtKnP//hj9Q
Li7VWGSFG4uXUkURBeZMb8EdlSOUp/IrFaYNOzA9DOfKPu8/06xE2K/LDkrnnvAP
ubHJbzxm2wBc5OgZ0MgdEPOl7V8PcaO/MhSOjTFcdqwAUHfczDK8d2XviLNvgvbZ
lxI8Proc2b7BqwUGkhrv3tk8qyz/yqL1YsVVXr7pcAQDCJodMRDKylNnSH5R7/6W
03yYcWOzjHmrhwGX+pYktmHPjNFeK2H6YYCTzeGvhI/w/6CwloZ+KcbEkFUlgSd0
PEjmWAttY/+GiX6vO9rUpSrf3joTJd9w072IzdoXi8ykOMEElD7+SgfeEKCTQ8Jj
Z4ixYxjjVT81uACHhMA2HGkSEEsV64U32wtS8kGLAlj8I0OuSzAWc9ThrGvGmCeg
O2BhaYCsvSYT3q04Bt5tE9nxAvbuTfZ++xKgOIM6oo4QK2L0d+GT62YYLfBCHJ4J
VVRobGF6DxMcIwxHjWlGE/9CuDBpd8nEn78Si8uAlct9lznmSyU2avm4gaF6SJxA
CtSjkTxZlJJbBDWFxTLmlzTev/jlc0jnPoGsTGSzSRis1NE2tu+qNiXuJNjpSnvA
MQ7lwwyaZPpyojL7rZkQ2WUUkLBc17DgYcaKXky9xKlPfNWgelbMPVhlXC4hOiLX
uoLMnXCTPP3AcWVWXNr1
=Npir
-----END PGP SIGNATURE-----

Debian Bug report logs - #756689 octave: [hdf5 transition] please support hdf5 1.8.13 new packaging layout

Debian Bug report logs - #756689
octave: [hdf5 transition] please support hdf5 1.8.13 new packaging layout