pavbaranov Arch

Kiedyś ten programik był w AUR. Obecnie go już nie ma. Jest użyteczny wyłącznie dla osób, które mają kernele z UKSM . Do takich należą np. linux-uksm czy linux-pf oraz... mój własny. Znów zatem krótko: PKGBUILD (tym razem to nie mój wynalazek, a oryginalny PKGBUILD, który niegdyś znajdował się w AUR) i wszystko jasne.

Postanowiłem prezentować małe, użyteczne narzędzia. Sporo takich znajdziecie w repozytoriach, czy w AUR, w tym cyklu skupię się jednak na tych, których tam nie ma i będę dawać do nich PKGBUILDy. Na pierwszy ogień - swapusage . Nazwa mówi wszystko. Programik, który sprawdzi co siedzi w swap i ile go zużywa, a nadto przekaże nam informację o numerze procesu takiej aplikacji. Proste? Banalnie. Zatem już wyłącznie PKGBUILD i możecie używać. Jeśli nie wiecie jednak co dalej z taką wiedzą robić - również proste: nie używać, chyba, że wyłącznie po to, by wiedzieć. PS: Co robić z PKGBUILDami, które tu prezentuję również już nie piszę. Pisałem wiele razy jak należy w takich przypadkach tworzyć i instalować paczkę.

KDE jest jedynie przykładem. Podany poniżej sposób można dostosować do dowolnego programu. Trzeba mieć jedynie źródła i odrobinę chęci. Niemniej jednak ostrzegam: PROPONOWANE ROZWIĄZANIE JEST PRZEZNACZONE WYŁĄCZNIE DLA ŚWIADOMYCH UŻYTKOWNIKÓW . Pozostałym proponuję skorzystać z oferowanej przez nas pomocy na forum . Truizmem jest stwierdzenie, że nie istnieje oprogramowanie pozbawione wad. Zawsze znajdzie się jakiś błąd. W przypadku Archa i KDE mamy komfortową sytuację, albowiem opiekunowie paczek napiętnowanych przez Qt są po prostu bardzo dobrzy. Oczywiście zdarzają się wpadki, jednakże są one często i to na poziomie testowania (repozytoria testing i kde-unstable) wychwytywane i naprawiane. Jeśli zatem chodzi o samą jakość paczek to jest tu po prostu przednio. Niemniej jednak urodą Archa jest to, że dostarcza on zasadniczo oprogramowanie najnowsze i to w miarę możliwości takie, jakim go widzi tzw. upstream. Przyjęcie tej zasady oznacza, że mniejsze lub większe błędy zostaną dostarczo

W AUR sporo jest skryptów umożliwiających budowę paczek w wersjach rozwojowych. Zwykle noszą one dodatkowe oznaczenia dev/devel, git, bzr, svn, cvs, hg itp. Odróżnijmy wpierw paczki *-dev/devel. Z takim rozszerzeniem winny pojawiać się takie wersje rozwojowe programów, które są w jakiś sposób "ustabilizowane" przez twórców. Innymi słowy - "numerowane" wersje rozwojowe. Przykładem takim niech będzie GIMP, który stosuje bardzo stary system oznaczania swoich wersji, gdzie pierwsza cyfra oznacza wersję, druga cyfra wskazuje na wydanie, a trzecia wskazuje na wersję poprawkową. Dodatkowo jeszcze wydania uważane za deweloperów za stabilne oznaczane są kolejną parzystą liczbą, zaś wydania rozwojowe, które prowadzą do następnych wydań stabilnych oznaczane są liczbą nieparzystą. Stąd GIMP 2.8.22, to ostatnia wersja stabilna (8) drugiego (2) wydania GIMPa, będąca dwudziestą drugą wersją poprawkową dla wydania 2.8. Niedawno ogłoszona wersja 2.9.8 jest rozwojową (9) wersją, któr

Oczywiście w repozytorium Archa są nawet dwie wersje LibreOffice (still i fresh). Są jeszcze różne wersje w AUR. Z różnych względów jednakże możemy chcieć mieć inną wersję niż ta, którą zainstalować możemy z repozytorium. Także taką, która będzie z nią koegzystować i nie naruszy nam naszego "produkcyjnego" pakietu. Oczywiście możliwą jest taka instalacja w przypadku wersji z repozytorium oraz niektórych z AUR. Możliwym jest też odpowiednie dostosowanie PKGBUILDów do swoich potrzeb. Proponuję jednakże inne, szybkie rozwiązanie, które umożliwi Wam na przykład testowanie przyszłych wersji, ewentualne włączenie się w rozwój tego pakietu czy też do jakichkolwiek innych celów będziecie chcieć to wykorzystać. Owe rozwiązanie to AppImage. Przede wszystkim muszę zaznaczyć, że w ogóle nic nie musicie robić. AppImage kilku wersji LO jest oferowane przez LibreOffice AppImage Package - wystarczy ściągnąć odpowiedni dla siebie plik, nadać mu uprawnienia wykonywalne i ma działać. Niemnie

Niezbyt wiele mamy aplikacji stanowiących GUI dla silników OCR w linuksie, zatem każdą z nich należy pielęgnować. W świecie oprogramowania opartego o Qt 5, spośród stale rozwijanych w zasadzie istnieje jedynie gImageReader. W AUR znajdziemy dwa PKGBUILDy: gimagereader oparty jeszcze o Qt 4 oraz gimagereader-qt5 oparty o Qt 5. Pierwszym nie będę się zajmować. Najwyższy czas, by dawno już porzucone Qt 4 odeszło w mroki dziejów. Niestety po psikusie, jakim było wprowadzenie enchant w wersji 2 do repozytorium (extra), aplikacja ta przestaje działać. Pominąwszy pewne perturbacje, jakie były w międzyczasie, dzisiaj już udaje się przywrócić możliwość działania gImageReaderowi. Niestety nie podam Wam co i jak należy zmienić w istniejących PKGBUILDach w AUR. Jeśli chcecie używać, to będziecie się musieli zdać na moje rozwiązanie. Zacznijmy od tego, że gImageReader wymaga do swojego działania i budowy qtspell, ten natomiast wymaga enchant. Obecna sytuacja w repozytoriach i w AUR jest następująca