On Tue, Dec 30, 2025, at 8:34 AM, Paul Gevers wrote: > user [email protected] > usertag 1124260 s390x > thanks > > Hi, > > On 12/29/25 22:07, Debian Bug Tracking System wrote: >> Changes: >> rust-rust-decimal (1.39.0-3) unstable; urgency=medium >> . >> * Team upload. >> * Package rust_decimal 1.39.0 from crates.io using debcargo 2.7.11 >> * skip test case on s390x (Closes: #1124260) > > > I'm slightly surprised by this solution. Judging from the test name and > error message I expected the test to show a real issue on s390x. Maybe > the s390x porters are interested to have a look.
the test case tests: - that the Decimal struct is 16-bytes aligned (which passes, and is what the "align16" feature tested here is supposed to enable/do) - that it has the same alignment as i128/u128, under the assumption that that is 16 bytes as well on x86 (but without restricting it to targets with those alignment guarantees, which means it fails on those that have "smaller" alignment) see upstream commit introducing this feature, which explicitly calls out that the alignment only matches i128/u128 on x86 (which of course doesn't mean that there aren't other platforms with the same alignment, but already acknowledges that this isn't true everywhere): https://github.com/paupino/rust-decimal/commit/7d56d92acd3e6a951e07a7b78d96b3361d5dc0fc my debian changelog entry was probably not specific enough - the fix here was conditionalizing the i128/u128 part of the test to only run on x86(_64), while keeping the principal alignment test on all targets. IMHO this is a case of the test case being broken, not the code itself, and thus this is the correct course of action (the alternative being to make the test case more complex to account for the different alignment of 128bit integers on various platforms, but I am not even sure why upstream tests that in the first place to be honest). happy to be corrected though, in particular if porters disagree :)
