#time64 — Public Fediverse posts

Did I mention that #Gentoo has now #time64 stages for #x86?

Well, we have #Docker images now as well:

$ docker run gentoo/stage3:i686-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t
$ docker run gentoo/stage3:i686-ssemath-t64-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
2335219200.0

(there's only a "ssemath" variant, using "-mfpmath=sse" — the floating-point computations are done on 64-bit SSE registers rather than 80-bit x87 registers, giving more consistent results between 32-bit x86 and everything else)

A wspominałem, że mamy już w #Gentoo archiwa stage3 w wariancie #time64 dla #x86?

No to wspominam, że teraz mamy też obrazy Dockera:

$ docker run gentoo/stage3:i686-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t
$ docker run gentoo/stage3:i686-ssemath-t64-openrc python -c 'import datetime; print(datetime.datetime(2044, 1, 1).timestamp())'
2335219200.0

(robimy tylko wariant "ssemath", czyli z "-mfpmath=sse" — operacje zmiennoprzecinkowe wykonywane są przy pomocy 64-bitowych rejestrów SSE, a nie 80-bitowych x87, co daje mniejsze rozbieżności między 32-bitowych x86, a całą resztą architektur)

#Docker

Dziś kolejny krok naprzód — #GCC 14 i nowsze w #Gentoo doczekały się flagi "time64". Po załączeniu, sprawia ona, że kompilator domyślnie używa `-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64`. Flaga ta jest zamaskowana w standardowych profilach, i wymuszona w profilach #time64.

We've taken another step forward today — #GCC 14 and newer in #Gentoo new features a "time64" flag that enables passing `-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64` by default. This flag is masked in regular profiles, and forced in #time64 profiles.

Najnowsze wersje (rewizje) #Clang 18, 19 i 20 w #Gentoo obsługują teraz nowe krotki #time64. To jest, można dać:

clang --target=i686-pc-linux-gnut64

i dostanie się z automatu `-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64`. A co ważniejsze — clang 19+ zacznie działać na systemach z takim CHOST-em.

Istnieje jednak pewne ryzyko, że zmiany zostaną cofnięte, bo można postrzegać je jako zmianę ABI, jak zauważył to projekt #Zig (aczkolwiek oni zdecydowali się przestać polegać na pełnym dopasowaniu wszystkich wartości enumeracji).

https://discourse.llvm.org/t/potential-abi-break-in-19-1-3/82865

Teraz tylko ktoś musi zająć się zmianami po stronie GCC.

#LLVM

The latest versions (revisions) of #Clang 18, 19 and 20 in #Gentoo now support the new #time64 tuples. That is, if you run e.g.:

clang --target=i686-pc-linux-gnut64

you're going to get `-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64` automatically. But more importantly, clang 19+ will no longer refuse to run on systems with CHOST set to that value.

That said, there's some risk that the change may be reverted because it's debatably an ABI break, as noticed by #Zig (but they've decided to update their code not to rely on matching all enum values).

https://discourse.llvm.org/t/potential-abi-break-in-19-1-3/82865

Now someone finally needs to handle GCC.

#LLVM

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t

Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.

Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.

Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.

Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.

#32bit #time_t #y2k38

Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.

Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.

Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.

Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.

#32bit #time_t #y2k38

Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.

Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.

Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.

Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.

#32bit #time_t #y2k38

Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.

Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.

Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.

Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.

#32bit #time_t #y2k38

Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.

Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.

Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.

Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.

#32bit #time_t #y2k38

The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.

Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.

Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.

A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.

#32bit #time_t #y2k38

The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.

Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.

Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.

A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.

#32bit #time_t #y2k38

The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.

Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.

Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.

A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.

#32bit #time_t #y2k38

The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.

Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.

Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.

A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.

#32bit #time_t #y2k38

The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.

Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.

Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.

A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.

#32bit #time_t #y2k38

Another post on the blog, though this time it's more of a quick note: "Testing the safe time64 transition path"

"""
Recently I've been elaborating on the perils of transition to 64-bit #time_t, following the debate within #Gentoo. Within these deliberations, I have also envisioned potential solutions to ensure that production systems could be migrated safely.

My initial ideas involved treating #time64 as a completely new ABI, with a new libdir and forced incompatibility between binaries. This ambitious plan faced two disadvantages. Firstly, it required major modification to various toolchains, and secondly, it raised compatibility concerns between Gentoo (and other distributions that followed this plan) and distributions that switched before or were going to switch without making similar changes. Effectively, it would not only require a lot of effort from us, but also a lot of convincing other people, many of whom probably don't want to spend any more time on doing extra work for 32-bit architectures. This made me consider alternative ideas.

One of them was to limit the changes to the transition period — use a libt32 temporary library directory to prevent existing programs from breaking while rebuilds were performed, and then simply remove them, and be left with plain lib like other distributions that switched already. In this post, I'd like to elaborate how I went about testing the feasibility of this solution. Please note that this is not a migration guide — it includes steps that are meant to detect problems with the approach, and are not suitable for production systems.
"""

https://blogs.gentoo.org/mgorny/2024/10/04/testing-the-safe-time64-transition-path/

#y2k38 #32bit

Another post on the blog, though this time it's more of a quick note: "Testing the safe time64 transition path"

"""
Recently I've been elaborating on the perils of transition to 64-bit #time_t, following the debate within #Gentoo. Within these deliberations, I have also envisioned potential solutions to ensure that production systems could be migrated safely.

My initial ideas involved treating #time64 as a completely new ABI, with a new libdir and forced incompatibility between binaries. This ambitious plan faced two disadvantages. Firstly, it required major modification to various toolchains, and secondly, it raised compatibility concerns between Gentoo (and other distributions that followed this plan) and distributions that switched before or were going to switch without making similar changes. Effectively, it would not only require a lot of effort from us, but also a lot of convincing other people, many of whom probably don't want to spend any more time on doing extra work for 32-bit architectures. This made me consider alternative ideas.

One of them was to limit the changes to the transition period — use a libt32 temporary library directory to prevent existing programs from breaking while rebuilds were performed, and then simply remove them, and be left with plain lib like other distributions that switched already. In this post, I'd like to elaborate how I went about testing the feasibility of this solution. Please note that this is not a migration guide — it includes steps that are meant to detect problems with the approach, and are not suitable for production systems.
"""

https://blogs.gentoo.org/mgorny/2024/10/04/testing-the-safe-time64-transition-path/

#y2k38 #32bit