Debian Patches
Status for h5py/3.16.0-8
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| No-rpath.patch | No rpath | Ghislain Antony Vaillant <ghisvail@gmail.com> | no | 2016-02-02 | ||
| No-intersphinx.patch | No intersphinx | Ghislain Antony Vaillant <ghisvail@gmail.com> | no | 2017-09-03 | ||
| build_flavour.patch | =================================================================== | no | ||||
| stop_circular_dep.patch | =================================================================== | no | ||||
| tests_as_local_build.patch | =================================================================== | no | ||||
| use_system_lzf.patch | =================================================================== | no | ||||
| skip_test_selection_assertion.patch | =================================================================== | no | ||||
| relax_hdf5_version_test.patch | =================================================================== | no | ||||
| doc_local_mathjax.patch | =================================================================== | no | ||||
| ppc-float128.patch | fix build after migration to IEEE 128-bit long double on ppc64le =================================================================== |
Dan Horák <dan@danny.cz> | no | fedora, https://src.fedoraproject.org/rpms/h5py/c/4578df64e4c923d1c3edf1213a209500e7caf453 | 2022-06-15 | |
| dtype_bitfield_test_endian_PR2818.patch | TST: avoid using native endianess in a little-endian specific test | Clément Robert <cr52@protonmail.com> | no | 2026-03-12 | ||
| abi_compatible_PR2955.patch | Don't warn about ABI-compatible HDF5 versions from 2.0 onwards <details><summary>Claude's draft</summary> h5py warned on import whenever the runtime HDF5 version differed at all from the one it was built against. From HDF5 2.0.0 onwards the HDF Group guarantees ABI backwards compatibility within a major version: an application linked against X.Y.Z must run without recompilation against any later X.A.B. See https://github.com/HDFGroup/hdf5/wiki/HDF5-Version-Numbers-and-Branch-Strategy So a build against HDF5 2.1.0 running on 2.2.0 is fine, and the warning is just noise for anyone whose HDF5 is updated independently of h5py (conda-forge, distro packages, ...). Add `version._hdf5_abi_compatible()` and only warn when the versions really may be incompatible: * the major versions differ, or * the running library is older than the one built against (it may be missing symbols and features), or * the versions are 1.x and not identical -- 1.x predates the guarantee, its minor number played the role the major number plays now, and the ABI was known to change even between maintenance releases (H5Oget_info* in 1.10.4). The 1.x behaviour is therefore unchanged. Resume this Claude session: ``` cd /home/mark/git claude --resume 782c702d-bf0e-47af-a893-1c9be46936a1 ``` </details> |
Mark Harfouche <mark.harfouche@gmail.com> | no | 2026-08-09 | ||
| vlen_compound_alignment.patch | Fix bus error on strict-alignment architectures when reading/writing compound datatypes containing variable-length fields . HDF5 packs compound elements tightly, one after another at the datatype's size. For compounds containing variable-length fields (hvl_t), that size is not in general a multiple of the alignment of the pointer-sized hvl_t fields. With such a type every element after the first lands at a misaligned address, and dereferencing the members (h5py's own converters, but also HDF5's H5Dvlen_reclaim) raises a fatal "Bus error" on architectures that require aligned access (e.g. armhf and sparc64), breaking tests such as test_compound_vlen_bool. It appears with h5py 3.16 because that is the first version built against HDF5 2.x in Debian/Ubuntu. . Fix the vlen converters to copy hvl_t / PyObject* values to and from the (packed) conversion buffer with memcpy, and pad the size of the compound types used for the temporary conversion buffers up to a multiple of sizeof(void*) so that each packed element is aligned. Only the temporary in-memory conversion types are affected; types stored in files are unchanged. |
Bastian Germann <bage@debian.org> | no | 2026-10-26 |