Alexander Kanavin

I think the output from the test suite needs to be adjusted, specifically this bit: ``` regress: FAIL ../libevent-2.1.12-stable/test/regress_util.c:1478: assert(diff.tv_sec == 0): 1 vs 0util/monotonic_prc_fallback: [monotonic_prc_fallback FAILED] [RETRYING monotonic_prc_fallback (3)]...

@kraj can you please take a look at the comments - 2.5.2 is now out, and the patches that are carried in Yocto for 2.5.1 are difficult to forward-port. So...

@kraj can you please rebase and fix the conflicts again, so we can update to 2.5.3? Would be good to get this merged as well.

I'm not sure why this was closed without a comment, but I have reopened here: https://github.com/tianocore/edk2/pull/3870

SystemTime and libc crate aren't using musl correctly either. I got the following on a 32 bit musl system after setting the system clock to 2040. I didn't yet look...

Libc crate could check whether _TIME_BITS=64 is in CFLAGS (as prescribed by glibc), and then build with 64 bit time. Same as what happens via glibc header define magic in...

After some poking at musl code, I think it has the same ABI as as glibc: clock_gettime() is the 32 bit version, and if you want 64 bits, you must...

@snogge you can change the title of this issue, I suppose. It's the same on glibc and musl. 32 bit api in use on both :(

> @kanavin, switching musl to 64bit time_t is part of #1848 (PR #3068) and is also mentioned in #3248 . Thanks, I left a comment there. #3068 could serve as...

> There's also the problem here that Linux distributions are switching over to using `-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64` by default, e.g. Debian: https://wiki.debian.org/ReleaseGoals/64bit-time * > > This means that somehow the libc...