Hi Steve, Thanks for following up. As I understand it, this is an issue with either h5py or libhdf5. We have not modified the behavior of these libraries, and are using them in a very basic manner; endianness is outside of our control here. It is possible the issue is related to ( https://github.com/h5py/h5py/issues/428) which appears to still be open.
Best, Daniel On Mon, Jul 11, 2016 at 11:42 AM, Steve Langasek <vor...@debian.org> wrote: > Hi folks, > > Please keep me on Cc:, the Debian BTS does not automatically cc: bug > submitters :) > > > Andreas, my read of the bug report suggests that the issue across > > architectures is h5py or hdf5. The access being made is to an attribute > > of an h5py object which happens within python and is a valid API > > operation; testing locally I'd expect a different KeyError to be thrown > > under normal operation. > > > Looking closer at one of the failing tests (offending call linked below), > > you can see that this is on read of a hdf5 table that ships with the > > biom-format project. > > > > https://github.com/biocore/biom-format/blob/master/tests/test_table.py#L527-528 > > > The implication is that this is happening when reading a table that ships > > as part of the test code, suggesting that h5py or hdf5 are unable to > > interact with the file as expected. My take is that the failure we're > > observing is a manifestation of a bug at a lower level. > > So it sounds like your test data is written in a little-endian format, but > hdf5 on big-endian architectures is trying to read it in a big-endian > format. Is it defined somewhere that hdf5 data should be in an > architecture-independent format (always little-endian)? > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer http://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org >
