The types defined in <utmp.h> and <utmpx.h> contain seconds-since-epoch fields. Historically, those fields are 32 bits wide. There are two issues with that: 1. The field width incorrectly changed to 64 bits on i686 when building with _TIME_BITS == 64 (an unusual configuration for Fedora builds). This is wrong because these files describe on-disk data structures. This has been fixed for glibc 2.40 upstream, and I'm working on backports all the way to glibc 2.34 (which will eventually land in all supported Fedora releases). 2. 31 bits aren't enough for some downstream distributions. We can recover one bit if we make the types unsigned. Such a change will be part of glibc 2.40, and it has already landed in rawhide. I do not plan to backport this change upstream, but for downstream use cases, we have to backport it into Fedora 40. (I plan to stop there, and not update 39 and 38.) I did a mass-rebuild rebuild of all packages that use the utmp functions, and at least there weren't any build failures. With just glibc rebuilt, the graphical desktop appears to work just fine (which isn't unexpected, given that glibc treats these timestamps as opaque). Long term, we expect that applications switch away from these interfaces, and use session information from systemd. It's not just that the fields have the wrong size, the whole facility is designed for a fixed number of terminals. It is not really compatible with a large (effective unbounded) number of pseudo-terminals, or more generally, client sessions. It is also not possible to correctly implement utmp file locking without help from a daemon. Thorsten Kukuk is leading the migration, and has submitted patches to many upstream projects: Y2038, glibc and utmp/utmpx on 64bit architectures <https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/> Thanks, Florian -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue