Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Package: bitshuffle Followup-For: Bug #955456 Incidentally, Thorsten, another way of handling h5py and bitshuffle's build against hfd5-mpi is to explicitly access h5py-mpi. That is, patch out bitshuffle to replace import h5py with import h5py._debian_h5py_mpi as h5py (in bitshuffle/h5.pyx and in tests). In that case h5py-mpi gets loaded directly by bitshuffle, so will be active even in a serial process.
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-06 20:23, Gilles Filippini wrote: Drew Parsons a écrit le 06/04/2020 à 05:08 : Do we want to use this as a solution? Or would you prefer an environment variable that h5py can check to allow mpi invocation on a serial process? I let this decision up to you. I think it's reasonable to give h5py an environment variable to work with, since the same problem might occur for other applications (including user apps). It's conceivable some users might want their hdf5 (h5py) apps to build against mpi, even if also used in serial mode. Whatever you choose it deserve a bit fat note in README.Debian. Certainly. Note that this means bitshuffle as built now is expressly tied in with hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and debian/control, though the Build-Depends must be updated to python3-h5py-mpi). It's a separate question whether it's desirable to also support a hdf5-serial build of bitshuffle. Likewise we need to think about what we want to happen when bitshuffle is invoked in a serial process. I'll let that to the bitshuffle maintainer. More puzzles for Thorsten to spend the weekends on :) I'll propose a patch to fix the current FTBFS, sticking on the mpi flavour to be conservative vs bitshuffle's previous builds. Thanks for your help. Drew
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Control: tags -1 + patch
Gilles Filippini a écrit le 06/04/2020 à 14:23 :
> Drew Parsons a écrit le 06/04/2020 à 05:08 :
>> On 2020-04-06 09:56, Drew Parsons wrote:
>>> On 2020-04-06 01:48, Gilles Filippini wrote:
Drew Parsons a écrit le 05/04/2020 à 18:57 :
>
> Another option is to create an environment variable to force h5py to
> load the mpi version even when run in a serial environment without
> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
> -n 1 dh_auto_build" or a variation of that is viable. Maybe
> %:
> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:
I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13
But the HDF5 error is no more present with python3.7. So it seems a good
point.
>>>
>>>
>>> Strange again. I would have expected the same behaviour in python3.8
>>> and python3.7, whether successful or unsuccessful.
>>
>>
>> Putting dh into mpirun seems to be interfering with process spawning.
>> Once MPI is initialised (for the python3.7 test) it's not reinitialised
>> for the python3.8 and so it's in a bad state for the test. Something
>> like that.
>>
>> It's only in the tests where h5py is invoked that we get the problems.
>> This variant works, applying mpirun separately for each test run:
>>
>> override_dh_auto_test:
>> set -e; \
>> for py in `py3versions -s -v`; do \
>> mpirun -n 1 pybuild --test -i python{version} -p $$py; \
>> done
>>
>> (could use mpirun -n $(NPROC) for real mpi testing).
>
> Yes, it works! \o/
>
>> Do we want to use this as a solution? Or would you prefer an environment
>> variable that h5py can check to allow mpi invocation on a serial process?
>
> I let this decision up to you. Whatever you choose it deserve a bit fat
> note in README.Debian.
>
>> Note that this means bitshuffle as built now is expressly tied in with
>> hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
>> debian/control, though the Build-Depends must be updated to
>> python3-h5py-mpi). It's a separate question whether it's desirable to
>> also support a hdf5-serial build of bitshuffle. Likewise we need to
>> think about what we want to happen when bitshuffle is invoked in a
>> serial process.
>
> I'll let that to the bitshuffle maintainer. I'll propose a patch to fix
> the current FTBFS, sticking on the mpi flavour to be conservative vs
> bitshuffle's previous builds.
Here it is.
_g.
diff -Nru bitshuffle-0.3.5/debian/changelog bitshuffle-0.3.5/debian/changelog
--- bitshuffle-0.3.5/debian/changelog 2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/changelog 2020-04-06 14:47:10.0 +0200
@@ -1,3 +1,21 @@
+bitshuffle (0.3.5-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Drew Parsons , Gilles Filippini ]
+ * Closes: #955456
+- fix-deprecated.patch: fix test_h5filter.py and test_h5plugin.py
+ to open files with flag 'w' when required
+- Build-Depends: python3-h5py-mpi to force using the mpi flavour
+ of h5py
+- override_dh_auto_test:
+ - Run the tests via mpirun so that h5py knows it has to invoke its
+mpi implementation
+ - Launch the tests for each python version separatly to permit MPI
+initialization at each run
+
+ -- Gilles Filippini Mon, 06 Apr 2020 14:47:10 +0200
+
bitshuffle (0.3.5-3) unstable; urgency=medium
* don't use -march=native when building the package
diff -Nru bitshuffle-0.3.5/debian/control bitshuffle-0.3.5/debian/control
--- bitshuffle-0.3.5/debian/control 2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/control 2020-04-06 14:46:51.0 +0200
@@ -11,7 +11,7 @@
# , libopenmpi-dev
, openmpi-bin
, python3-setuptools
- , python3-h5py
+ , python3-h5py-mpi
, quilt
, cmake
, pkg-config
diff -Nru bitshuffle-0.3.5/debian/patches/fix-deprecated.patch
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Drew Parsons a écrit le 06/04/2020 à 05:08 :
> On 2020-04-06 09:56, Drew Parsons wrote:
>> On 2020-04-06 01:48, Gilles Filippini wrote:
>>> Drew Parsons a écrit le 05/04/2020 à 18:57 :
Another option is to create an environment variable to force h5py to
load the mpi version even when run in a serial environment without
mpirun. Easy enough to set up, though I'm interested to see if "mpirun
-n 1 dh_auto_build" or a variation of that is viable. Maybe
%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
>>>
>>> This, way the test cases run against python3.7 is OK, but it fails
>>> against python3.8 with:
>>>
>>> I: pybuild base:217: cd
>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>
>>> python3.8 -m unittest discover -v
>>> [pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
>>> line 112
>>> *** An error occurred in MPI_Init_thread
>>> *** on a NULL communicator
>>> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
>>> *** and potentially your MPI job)
>>> [pinibrem15:43725] Local abort before MPI_INIT completed completed
>>> successfully, but am not able to aggregate error messages, and not able
>>> to guarantee that all other processes were killed!
>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
>>> cd
>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>
>>> python3.8 -m unittest discover -v
>>> dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
>>> returned exit code 13
>>>
>>> But the HDF5 error is no more present with python3.7. So it seems a good
>>> point.
>>
>>
>> Strange again. I would have expected the same behaviour in python3.8
>> and python3.7, whether successful or unsuccessful.
>
>
> Putting dh into mpirun seems to be interfering with process spawning.
> Once MPI is initialised (for the python3.7 test) it's not reinitialised
> for the python3.8 and so it's in a bad state for the test. Something
> like that.
>
> It's only in the tests where h5py is invoked that we get the problems.
> This variant works, applying mpirun separately for each test run:
>
> override_dh_auto_test:
> set -e; \
> for py in `py3versions -s -v`; do \
> mpirun -n 1 pybuild --test -i python{version} -p $$py; \
> done
>
> (could use mpirun -n $(NPROC) for real mpi testing).
Yes, it works! \o/
> Do we want to use this as a solution? Or would you prefer an environment
> variable that h5py can check to allow mpi invocation on a serial process?
I let this decision up to you. Whatever you choose it deserve a bit fat
note in README.Debian.
> Note that this means bitshuffle as built now is expressly tied in with
> hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
> debian/control, though the Build-Depends must be updated to
> python3-h5py-mpi). It's a separate question whether it's desirable to
> also support a hdf5-serial build of bitshuffle. Likewise we need to
> think about what we want to happen when bitshuffle is invoked in a
> serial process.
I'll let that to the bitshuffle maintainer. I'll propose a patch to fix
the current FTBFS, sticking on the mpi flavour to be conservative vs
bitshuffle's previous builds.
> I think part of the confusion here is that bitshuffle (at least in the
> tests) is double-handling the HDF5 library, with direct calls on the one
> hand, but indirectly through h5py as well, on the other hand.
Thanks,
_g.
signature.asc
Description: OpenPGP digital signature
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-06 09:56, Drew Parsons wrote:
On 2020-04-06 01:48, Gilles Filippini wrote:
Drew Parsons a écrit le 05/04/2020 à 18:57 :
Another option is to create an environment variable to force h5py to
load the mpi version even when run in a serial environment without
mpirun. Easy enough to set up, though I'm interested to see if
"mpirun
-n 1 dh_auto_build" or a variation of that is viable. Maybe
%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:
I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now
abort,
***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not
able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit
code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13
But the HDF5 error is no more present with python3.7. So it seems a
good
point.
Strange again. I would have expected the same behaviour in python3.8
and python3.7, whether successful or unsuccessful.
Putting dh into mpirun seems to be interfering with process spawning.
Once MPI is initialised (for the python3.7 test) it's not reinitialised
for the python3.8 and so it's in a bad state for the test. Something
like that.
It's only in the tests where h5py is invoked that we get the problems.
This variant works, applying mpirun separately for each test run:
override_dh_auto_test:
set -e; \
for py in `py3versions -s -v`; do \
mpirun -n 1 pybuild --test -i python{version} -p $$py; \
done
(could use mpirun -n $(NPROC) for real mpi testing).
Do we want to use this as a solution? Or would you prefer an environment
variable that h5py can check to allow mpi invocation on a serial
process?
Note that this means bitshuffle as built now is expressly tied in with
hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
debian/control, though the Build-Depends must be updated to
python3-h5py-mpi). It's a separate question whether it's desirable to
also support a hdf5-serial build of bitshuffle. Likewise we need to
think about what we want to happen when bitshuffle is invoked in a
serial process.
I think part of the confusion here is that bitshuffle (at least in the
tests) is double-handling the HDF5 library, with direct calls on the one
hand, but indirectly through h5py as well, on the other hand.
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-06 01:48, Gilles Filippini wrote:
Drew Parsons a écrit le 05/04/2020 à 18:57 :
Another option is to create an environment variable to force h5py to
load the mpi version even when run in a serial environment without
mpirun. Easy enough to set up, though I'm interested to see if "mpirun
-n 1 dh_auto_build" or a variation of that is viable. Maybe
%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:
I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now
abort,
***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit
code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13
But the HDF5 error is no more present with python3.7. So it seems a
good
point.
Strange again. I would have expected the same behaviour in python3.8
and python3.7, whether successful or unsuccessful.
We'll keep digging!
Drew
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Drew Parsons a écrit le 05/04/2020 à 18:57 :
> On 2020-04-05 22:34, Gilles Filippini wrote:
>> I suspect a mismatch between mpi and serial build-depdencies:
>>
>> python3-h5py-serial + libhdf5-dev => OK
>> python3-h5py-serial + libhdf5-openmpi-dev => KO
>> python3-h5py-mpi + libhdf5-dev => KO
>> python3-h5py-mpi + libhdf5-openmpi-dev => KO(*)
>>
>> (*) because it fails to import h5py submodules when python3-h5py-serial
>> is not installed:
>> ImportError: cannot import name 'h5f' from 'h5py' (unknown location)
>>
>> With the 2.10.0-5 layout it seems impossible to build against the 'mpi'
>> flavour, while building against 'serial' flavour requires serial flavour
>> of libhdf5 -dev package as well.
>
>
> I've set up h5py so that the mpi build is only invoked when actually run
> with mpirun. In that sense the two builds are complementary rather than
> replacements (there was complaining that module loading was too slow
> when I had h5py built only against hdf5-mpi). It seemed to me that's
> desirable to allow both serial and mpi builds of h5py to be installable
> at the same time, just as libhdf_*.so is, so I didn't want
> python3-h5py-serial and python3-h5py-mpi to Replace and Conflicts with
> each other.
>
> Probably this is what's going on. bitshuffle is trying to make an mpi
> build, but running the build single processor so h5py accesses hdf5-serial.
>
> In that case, running the bitshuffle mpi build in mpi might help, as in
> "mpirun -n 1 python3 setup.py". Not sure if that would be easy to do,
> e.g. if it's as "simple" as
>
> override_dh_auto_build:
>
> mpirun -n 1 dh_auto_build
>
> Another option is to create an environment variable to force h5py to
> load the mpi version even when run in a serial environment without
> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
> -n 1 dh_auto_build" or a variation of that is viable. Maybe
> %:
> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:
I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13
But the HDF5 error is no more present with python3.7. So it seems a good
point.
_g.
signature.asc
Description: OpenPGP digital signature
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-05 22:34, Gilles Filippini wrote: I suspect a mismatch between mpi and serial build-depdencies: python3-h5py-serial + libhdf5-dev => OK python3-h5py-serial + libhdf5-openmpi-dev => KO python3-h5py-mpi + libhdf5-dev => KO python3-h5py-mpi + libhdf5-openmpi-dev => KO(*) (*) because it fails to import h5py submodules when python3-h5py-serial is not installed: ImportError: cannot import name 'h5f' from 'h5py' (unknown location) With the 2.10.0-5 layout it seems impossible to build against the 'mpi' flavour, while building against 'serial' flavour requires serial flavour of libhdf5 -dev package as well. I've set up h5py so that the mpi build is only invoked when actually run with mpirun. In that sense the two builds are complementary rather than replacements (there was complaining that module loading was too slow when I had h5py built only against hdf5-mpi). It seemed to me that's desirable to allow both serial and mpi builds of h5py to be installable at the same time, just as libhdf_*.so is, so I didn't want python3-h5py-serial and python3-h5py-mpi to Replace and Conflicts with each other. Probably this is what's going on. bitshuffle is trying to make an mpi build, but running the build single processor so h5py accesses hdf5-serial. In that case, running the bitshuffle mpi build in mpi might help, as in "mpirun -n 1 python3 setup.py". Not sure if that would be easy to do, e.g. if it's as "simple" as override_dh_auto_build: mpirun -n 1 dh_auto_build Another option is to create an environment variable to force h5py to load the mpi version even when run in a serial environment without mpirun. Easy enough to set up, though I'm interested to see if "mpirun -n 1 dh_auto_build" or a variation of that is viable. Maybe %: mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild to avoid overrides. Drew
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Drew Parsons a écrit le 05/04/2020 à 15:28 : > On 2020-04-05 20:38, Gilles Filippini wrote: >>> >>> But it must be something else from these new h5py upstream patches >>> that's leading to any other bitshuffle errors (the ones apart from the >>> file-not-found error). >> >> Nope. Seems related to the h5py 'serial' flavour only. It appears for >> the first time when you configure the build for both flavours. If I >> force the 'mpi' flavour installation *without* the 'serial' one, >> bitshuffle builds fine. >> > > A good clue. I've pushed a h5py without the patches, but looks like the > problem might remain. Strange if bitshuffle builds fine against h5py-mpi > but not against h5py-serial. You'd expect any problem to come the other > way around. I suspect a mismatch between mpi and serial build-depdencies: python3-h5py-serial + libhdf5-dev => OK python3-h5py-serial + libhdf5-openmpi-dev => KO python3-h5py-mpi + libhdf5-dev => KO python3-h5py-mpi + libhdf5-openmpi-dev => KO(*) (*) because it fails to import h5py submodules when python3-h5py-serial is not installed: ImportError: cannot import name 'h5f' from 'h5py' (unknown location) With the 2.10.0-5 layout it seems impossible to build against the 'mpi' flavour, while building against 'serial' flavour requires serial flavour of libhdf5 -dev package as well. _g. signature.asc Description: OpenPGP digital signature
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-05 20:38, Gilles Filippini wrote: But it must be something else from these new h5py upstream patches that's leading to any other bitshuffle errors (the ones apart from the file-not-found error). Nope. Seems related to the h5py 'serial' flavour only. It appears for the first time when you configure the build for both flavours. If I force the 'mpi' flavour installation *without* the 'serial' one, bitshuffle builds fine. A good clue. I've pushed a h5py without the patches, but looks like the problem might remain. Strange if bitshuffle builds fine against h5py-mpi but not against h5py-serial. You'd expect any problem to come the other way around. Drew
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Drew Parsons a écrit le 03/04/2020 à 15:08 : > On 2020-04-03 20:13, Gilles Filippini wrote: >> >> This is not related to the ongoing hdf5 transition, but to the recent >> uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've >> checked that bitshuffle builds successfully. It was against h5py >> 2.10.0-2 by then. > > > The change in behaviour comes from the h5py upstream patches applied in > h5py 2.10.0-3. > > file_default_read_5e71c49.patch in particular is the one that updates > the API, setting File() to mode='r' by default. I added the patch to > deal with the H5pyDeprecationWarning we were getting, since the change > was flagged as coming in from upstream anyway. In principle it just > means mode needs to be added explicitly as h5py.File(filename, mode), if > the required mode is not 'r'. > > But it must be something else from these new h5py upstream patches > that's leading to any other bitshuffle errors (the ones apart from the > file-not-found error). Nope. Seems related to the h5py 'serial' flavour only. It appears for the first time when you configure the build for both flavours. If I force the 'mpi' flavour installation *without* the 'serial' one, bitshuffle builds fine. _g. signature.asc Description: OpenPGP digital signature
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-03 20:13, Gilles Filippini wrote: This is not related to the ongoing hdf5 transition, but to the recent uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've checked that bitshuffle builds successfully. It was against h5py 2.10.0-2 by then. The change in behaviour comes from the h5py upstream patches applied in h5py 2.10.0-3. file_default_read_5e71c49.patch in particular is the one that updates the API, setting File() to mode='r' by default. I added the patch to deal with the H5pyDeprecationWarning we were getting, since the change was flagged as coming in from upstream anyway. In principle it just means mode needs to be added explicitly as h5py.File(filename, mode), if the required mode is not 'r'. But it must be something else from these new h5py upstream patches that's leading to any other bitshuffle errors (the ones apart from the file-not-found error). It's a pity the hdf5 transition and new h5py package structure came on at the same time, makes it a touch more angst-provoking working through the changes than it would otherwise be (h5py was in the NEW queue for a while, got accepted at the same time as the HDF5 transition). Drew
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Hi, On Wed, 01 Apr 2020 11:47:33 +0800 Drew Parsons wrote: > Package: bitshuffle > Version: 0.3.5-3 > Severity: serious > Justification: FTBFS > Control: block 954654 by -1 > > bitshuffle fails to build against hdf5: 1.10.6+repack-1, because > tmp_test_filters.h5 does not exist > > OSError: Unable to open file (unable to open file: name = > 'tmp_test_filters.h5', errno = 2, error message = 'No such file or > directory', flags = 0, o_flags = 0) > > > The test filename 'tmp_test_filters.h5' is hardcoded in l.26 of > bitshuffle/tests/test_h5filter.py This is not related to the ongoing hdf5 transition, but to the recent uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've checked that bitshuffle builds successfully. It was against h5py 2.10.0-2 by then. _g. signature.asc Description: OpenPGP digital signature
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Package: bitshuffle Version: 0.3.5-3 Severity: serious Justification: FTBFS Control: block 954654 by -1 bitshuffle fails to build against hdf5: 1.10.6+repack-1, because tmp_test_filters.h5 does not exist OSError: Unable to open file (unable to open file: name = 'tmp_test_filters.h5', errno = 2, error message = 'No such file or directory', flags = 0, o_flags = 0) The test filename 'tmp_test_filters.h5' is hardcoded in l.26 of bitshuffle/tests/test_h5filter.py -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bitshuffle depends on: ii cython30.29.14-0.1+b1 ii libc6 2.30-4 ii libgomp1 10-20200324-1 ii libhdf5-openmpi-1031.10.4+repack-11 ii python33.8.2-2 iu python3-h5py 2.10.0-5 ii python3-numpy 1:1.17.4-5 ii python3-pkg-resources 44.0.0-1 bitshuffle recommends no packages. bitshuffle suggests no packages.
