#time64 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #time64, aggregated by home.social.
-
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…
-
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…
-
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.
-
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.
-
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.
-
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.
-
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/