Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
02-disable_delay_test | disable_delay_test | Steve McIntyre <93sam@debian.org> | no | 2023-08-09 | ||
0007-XFAIL-netlink_crypto.patch | XFAIL-netlink_crypto | Steve McIntyre <93sam@debian.org> | no | 2023-08-09 | ||
0008-XFAIL-nlattr_crypto_user_alg.patch | XFAIL-nlattr_crypto_user_alg | Steve McIntyre <93sam@debian.org> | no | 2023-08-09 | ||
03-fix-arm-time_t-ftbfs.patch | [PATCH] tests: fix LL->time_t->tv_sec conversion path Due to 64-bit time_t on armhf the initialization of some test cases that use the pattern of `...tv-sec = (time_t) = 0x1234LL` now fail. Example: tests/xselect.c:216:24: error: overflow in conversion from ‘long long int’ to ‘kernel_long_t’ {aka ‘long int’} changes value from ‘-3819351491602432273’ to ‘-559038737’ [-Werror=overflow] 216 | tv_in.tv_sec = (time_t) 0xcafef00ddeadbeefLL; Other places that used to cast from LL to time_t to assign to tv_sec have been changed in 2023 by 7178658e "tests: avoid libc definition for time_t in direct syscalls" - ts->tv_sec = (time_t) 0xcafef00ddeadbeefLL; + ts->tv_sec = (typeof(ts->tv_sec)) 0xcafef00ddeadbeefLL; That avoids the issue where time64 on 32-bit armhf leads to a mismatch. kernel_old_timespec.h determines as SIZEOF_KERNEL_LONG_T == 4 and thereby selecting `int` as type for tv_sec, but then time_t changed to 64-bit. Yet on the other hand tv_sec didn't change as it is a kernel type, so the assignment triggers an error. old: 64-bit -> explicit cast 32-bit -> assign 32-bit tv_sec new: 64-bit -> explicit cast 64-bit (time_t) -> assign 32-bit tv_sec The same pattern was yet unfixed in a few tests and hereby resolved the same way as in 7178658e. |
Christian Ehrhardt <christian.ehrhardt@canonical.com> | no | 2024-04-18 |