Przejdź do głównej zawartości

Koniec 32 bitowych paczek w Arch Linux

Stało się. Po wcześniejszej zapowiedzi, ostatecznie 8.11.2017 r. 32-bitowe paczki straciły wsparcie w Arch Linux. Do końca listopada paczki tego typu będą sukcesywnie wycofywane z repozytoriów, a potem nawet z archiwów. Pozostają paczki multilib. Wprawdzie jeszcze do repozytoriów wchodzą nowe paczki 32-bitowe, ale nie ma już takiego obowiązku. Dla użytkowników Archa w wersji 32-bit pozostają zatem trzy rozwiązania: - jeśli mogą, albowiem sprzęt ich na to pozwala, powinni zmienić wersję na 64-bitową, - jeśli rozwiązanie to nie jest możliwe, albowiem posiadają 32-bitowe maszyny, mogą sięgnąć po społecznościową kontynuację 32-bitowego Archa, które nazywa się ArchLinux32, - trzecia jest ostatecznością - zmiana dystrybucji. W przypadku kontynuacji Archa jako ArchLinux32, należy dotychczasową listę mirrorów w /etc/pacman.d/mirrorlist zamienić na dostępne obecnie mirrory ArchLinux32, następnie zainstalować paczkę archlinux32-keyring-transition i dokonać aktualizacji systemu, czyli: 1. Zmiana /etc/pacman.d/mirrorlist
sudo rm /etc/pacman.d/mirrorlist && sudo nano /etc/pacman.d/mirrorlist
z treścią:
Server = http://arch32.mirrors.simplysam.us/$arch/$repo Server = https://archlinux32.mirror.roelf.org/$arch/$repo Server = https://mirror.archlinux32.org/$arch/$repo Server = https://32.arlm.tyzoid.com/$arch/$repo
2. Instalacja paczek "transformacji" (m.in. klucze)
sudo pacman -Syy archlinux32-keyring-transition
3. Aktualizacja systemu
sudo pacman -Syuu
Niestety, obecnie niektóre paczki w tych repozytoriach są w starszych wersjach niż w repozytorium Archa. Wykonanie powyższych komend cofnie zatem je do wersji z archlinux32 (prawdopodobnie można by to obejść rezygnując w ostatnim poleceniu z "drugiego" -u, jednakże - jak zwykle nie polecam takich rozwiązań). Również paczki znajdujące się w cache pacmana, w przypadku aktualizacji, ponownej instalacji, będą instalowane stamtąd, a nie z nowych repozytoriów. Celowym wydaje się ich usunięcie poprzez pacman -Sc (czy nawet pacman -Scc). Osoby wybierające pierwsze rozwiązanie nie będą miały lekko. Nie istnieje bowiem żadne narzędzie zmiany architektury systemu, automatyzujące ten proces i nie wymagające jego reinstalacji. Pomijając bowiem paczki "any", pozostałe muszą być zamienione swoimi 64-bitowymi odpowiednikami. Szerzej proces migracji został opisany w wiki Archa oraz na jego forum. Sam tego nie robiłem, zatem odsyłam do wiedzy osób, które mają tu doświadczenie. Przypominam jedynie, że jeśli pośród programów (i sterowników!) dotychczas wykorzystywanych są takie, które występują wyłącznie w architekturze 32-bitowej, wówczas koniecznym będzie dołączenie do listy repozytoriów tzw. [multilib] oraz instalacja odpowiednich paczek lib32-*.

Komentarze

Popularne posty z tego bloga

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl. Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia.
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.
Inny forumowicz poleca zatem... dodanie repozytorium nexus do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, ż…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…