I’m working on packaging these two crates for Fedora in order to support the latest libcramjam and the upcoming cramjam-python 2.8.4.

For distribution packaging purposes, my environment has some differences from the upstream development environment. In blosc2-sys:

• Cargo.toml is patched to make the bindgen and pkg-config dependencies non-optional.
• The static feature is hidden, and build.rs is patched (by adjusting the conditionals):
  • Always link the system shared library regardless of features
  • Always re-generate the bindings regardless of features
  • Don’t require the blosc2 version to exactly match the bundled one; Fedora 39, 40, and 41 have 2.10.5, 2.14.0, and 2.14.4, respectively.
  • Adjust the header path for bindgen to point at the system-wide header /usr/include/blosc2.h

There might be some further improvements suggested once I get this submitted for package review, but these downstream patches seem to be working as expected, and all the blosc2-sys tests pass. There is some discussion of the kind of patching we may need for -sys crates in https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_rust2rpm.

When I try to build a package for blosc2-rs using the rust-blosc2-sys package described above, I have exactly one test failure in tests::test_schunk_basic. All other tests (including doctests) pass. This happens in Fedora 39, 40, and 41, so it doesn’t appear to be due to differences in the version of the system blosc2 library.

---- tests::test_schunk_basic stdout ----   
thread 'tests::test_schunk_basic' panicked at src/lib.rs:1873:9:
assertion `left == right` failed
  left: 0
 right: 1
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::assert_failed_inner  
   3: core::panicking::assert_failed
             at /builddir/build/BUILD/rustc-1.77.2-src/library/core/src/panicking.rs:297:5
   4: blosc2::tests::test_schunk_basic
             at ./src/lib.rs:1873:9
   5: blosc2::tests::test_schunk_basic::{{closure}}
             at ./src/lib.rs:1864:31
   6: core::ops::function::FnOnce::call_once
             at /builddir/build/BUILD/rustc-1.77.2-src/library/core/src/ops/function.rs:250:5

I know that my configuration is a bit different from the one you are testing and explicitly supporting, but I would really appreciate any advice on understanding the root cause.

Depends on rust-lang/rust-bindgen#2179 it seems.

While testing blosc2-rs in COPR for Fedora, with the src/lib.rs changes from #22, I found that there are several test failures on the s390x architecture. Since this is the only big-endian primary architecture in Fedora, these are likely due to implicit assumptions about host endianness.

I don’t have easy interactive access to real s390x hardware, but I can run any experiments I need to in the form of package builds. Also,

sudo dnf install qemu-user-static
mock -r fedora-rawhide-s390x --dnf -i package1 package2 package3
mock -r fedora-rawhide-s390x --shell --enable-network

is a convenient approach to debugging interactively in an emulated environment on a Fedora workstation. (If you haven’t used mock before, you’ll need to install it, run sudo useradd -G mock -a $(whoami), and then log out and back in to pick up the new supplementary group.)

I will paste the full test output into a comment.

The MIT license states that the copyright notice, and permission notice must be reproduced in all source and binary distributions. Since no license text appears in this repository or in the released crate, it’s not possible to easily comply with the license stated in Cargo.toml for blosc2-rs or blosc2-sys:

Please add the necessary license text, preferably in a file called LICENSE, and add a symbolic link so that it appears in the blosc2-sys crate as well (cd blosc2-sys; ln -s ../LICENSE).

This should be important for all potential users; it’s important for me so I can package these crates in Fedora Linux without guessing at the correct license text.