Test failures on the (big-endian) s390x architecture #23
Comments
|
|
Maybe/probably related Blosc/c-blosc2#467, maybe I'll take a stab at it. |
Hmm, I think you’re right. Test failures are ignored on It looks like there’s no reason to believe there is anything wrong with your bindings, and no way to tell one way or another until the issues in I don’t think I have time to fix |
|
(On the other hand, if Blosc/c-blosc2@8b5ea6f is really the only part that is broken, maybe I can pull together a PR without spending too much time on it.) |
|
I'm not convinced it's that bit of code anymore, I've narrowed it down to something funky going on here: If one changes I'm testing these changes w/ Disregard, I see now that after |
|
@musicinmybrain if you can give main a go when you have time, I think/hope we're good here now. 🙏 |
|
I will look into it ASAP! It’s a little tricker for me since I am using an unbundled blosc2 C library, so I need to try building a patched copy of that first, but I will certainly give it a try when I have a little time. |
|
No rush at all, I'm not pressured to release anything. 👍 |
|
I just got around to testing this. I applied https://github.com/Blosc/c-blosc2/pull/606.patch to the 2.14.4 release of blosc2, rebuilt it, and test-built I am still seeing a bunch of failures on I’d like to provide more helpful feedback, but I’m not sure where to start… I was curious what would happen if I used the bundled |
|
That kinda looks like neither shared or static feature was set. I've only encountered that when neither feature was set. Outside of that, I'm not sure. |
I finally got back to this with fresh eyes. The segfaults, it turns out, were my fault. I was patching
The excellent news is that once I fixed this, the segfaults went away and the Now I need to see if I can get |
|
That's great! |
|
Ok, so if I [backport both I don’t think I missed anything – not sure what’s happening here. I think I’ll work on getting at least Rawhide updated with the latest release 2.15.1 of |
|
I see similar results with Not sure what to try next. Having a Skipping the tests and shipping a I’m curious, though, why this seems to be fixed for you but not for me. |
Ya, that's a mystery, but it's this workflow that works after doing those upstream changes. Although I think what blosc-2 package tests on that system is not what I was fixing, but was similar: Blosc/c-blosc2#467, which is a file-backed schunk; maybe that's what's continuing to fail? I'm not claiming all blosc2 tests pass for me, just the blosc2-rs tests. Which there, they pass on s390x as shown in that workflow. |
|
With that said though, I won't be too broken up about it to rip out blosc2 from cramjam (or just ship it default without); until someone really presses for it. People should probably use the official Python-Blosc2 package anyway maybe. |
While testing
blosc2-rsin COPR for Fedora, with thesrc/lib.rschanges from #22, I found that there are several test failures on thes390xarchitecture. 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
s390xhardware, but I can run any experiments I need to in the form of package builds. Also,is a convenient approach to debugging interactively in an emulated environment on a Fedora workstation. (If you haven’t used
mockbefore, you’ll need to install it, runsudo 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 text was updated successfully, but these errors were encountered: