<utmp.h>, <utmpx.h> glibc ABI updates coming to Fedora releases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux