Hi Simon! Thank you for the detailed context regarding i386 vs armhf. I
was not aware of many of the intricacies you mentioned.
> You mentioned that m2.time_t_bits() exists, so that could be used as a
> way to select the correct format.
The patch I submitted on salsa [1] already accounts for that. On i386, the
code uses struct.pack("ii", ...), preserving 8-byte structure. On armhf, we
will switch to struct.pack("qq", ...)
Regarding formatting: I am using native "qq" rather than standard "=qq"
to ensure we respect any platform-specific C-struct alignment/padding
requirements for the syscall, though in practice, for timeval they are
likely
identical.
v
[1]
https://salsa.debian.org/python-team/packages/m2crypto/-/merge_requests/2
On Fri, 23 Jan 2026 at 17:42, Simon McVittie <[email protected]> wrote:
> On Fri, 23 Jan 2026 at 17:08:32 +0530, Ujjwal Sarswat wrote:
> >When running the test suite on 32-bit architectures that use 64-bit
> time_t (e.g., modern armhf/i386 for Y2038 compliance),
> test_server_simple_timeouts fails with OSError: [Errno 22] Invalid argument.
>
> i386 does not use 64-bit time_t by default, at least on Debian: this was
> agreed on as a way to avoid regressing legacy binary-only software
> (mostly games!), which is the main use-case for i386 in the 2020s, and
> would break if we changed the ABI of time_t. As far as I'm aware, both
> Debian and Ubuntu have followed the same policy on this.
>
> This is a special exception for i386 (possibly also hurd-i386, I'm not
> sure about the non-Linux ports). Other 32-bit architectures, such as
> armel, armhf and various -ports architectures, have done the ABI break
> and now use 64-bit time_t.
>
> Ubuntu doesn't compile most packages for i386, so in practice this
> subtlety probably doesn't matter on Ubuntu, but it does matter on
> Debian.
>
> Individual packages can force 64-bit time_t by adding -D_TIME_BITS=64 to
> their CPPFLAGS, but this must only be done if the package maintainer
> knows that it does not alter the library's external ABI. For example
> libsdl3 does this, as can be seen in the
>
> https://buildd.debian.org/status/fetch.php?pkg=libsdl3&arch=i386&ver=3.4.0%2Bds-1&stamp=1767281138&raw=0
> build log, because libsdl3 is careful not to use OS-defined types like
> time_t or struct stat in its ABI.
>
> >Proposed Fix: Change the packing format from "ll" to "qq" (long long).
> This forces 8-byte integers on all platforms, ensuring the structure is
> always 16 bytes when time_t is 64-bit.
>
> This would fix armhf, but might be wrong on i386, so it should be tested
> on both armhf and i386 before applying this change. It might be
> necessary to generate the correct format string dynamically, based on
> properties of the architecture.
>
> You mentioned that m2.time_t_bits() exists, so that could be used as a
> way to select the correct format.
>
> Strictly speaking, neither "ll" nor "qq" is guaranteed to be of a
> specific size in bits: "ll" with no special prefix is equivalent to
> "@ll", meaning two C `long` objects, whatever that means on the current
> platform, and similarly "qq" or "@qq" is two C `long long` objects
> (although in practice `long long` has a length of 64 bits on all Debian
> architectures). The format string for a pair of 64-bit integers,
> specifically, would be "=qq".
>
> smcv
>
