[Debian-med-packaging] Bug#842815: Re-opening: Please support HDF5 1.10

[Andreas Tille]

Hi Bernd,

I'm hereby forwarding the main parts of the discussion of the bug report
which might contain hints what to do to make jhdf5 compliant with hdf5
version 1.10.

It would be nice if you could give us a hint if you were able to fix this.

Kind regards

      Andreas.

On Tue, Nov 15, 2016 at 12:37:20AM +0100, Gilles Filippini wrote:
> > >> 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?


-- 
http://fam-tille.de