sobota, 17 lutego 2018

POLAUR - POL Arch User Repository

Miło mi poinformować, że od wczoraj zostało udostępnione repozytorium Polskiej społeczności Archa. Wespół z kolegami, będziemy tam oferować PKGBUILDy, które z jakichś powodów nie chcemy (choćby tymczasowo) umieszczać w AUR. Być może część z nich, kiedyś, zostanie udostępnione w AUR, ale część na pewno się nigdy tam nie znajdzie. Do korzystania z repozytorium nie zachęcamy, ale oddajemy je Wam. Możecie budować paczki, które są w poszczególnych repozytoriach. Zostały one przez nas zbudowane, zainstalowane i uruchomione. Każda z paczek przeszła proces walidacji co najmniej narzędziem namcap. Niemniej jednak, zwłaszcza paczki znajdujące się w dwu repozytoriach proszę traktować jako wysoce eksperymentalne i ich użytkowanie odradzam wszystkim, którzy nie czują się na siłach przynajmniej do przywrócenia systemu do stanu sprzed ewentualnej awarii i poznali tak elementarne czynności, jak uruchomienie systemu w konsoli, gdy nie podnosi się środowisko graficzne, nawiązanie połączenia sieciowego itd. itp. Są głównie dwa repozytoria, na które zwracam szczególną uwagę: repo-refreshed oraz pkg-trunk. To są repozytoria użyteczne wyłącznie dla osób, których poziom zaawansowania w obsłudze Archa jest co najmniej średniozaawansowany (to absolutne minimum!). Nadto drugie z nich jest repozytorium wyłącznie dla osób, które chcą się włączyć w testowanie oprogramowania. Osoby, które zdecydują się na korzystanie z tych repozytoriów, w przypadku zaistnienia jakichkolwiek problemów, przy ich zgłaszaniu są bezwzględnie proszone o wskazanie z których paczek zbudowanych z tych repozytoriów korzystają. Inaczej absolutnie nikt nie będzie w stanie im pomóc. Koniec straszenia ;) - teraz już o samych repozytoriach. Jest ich pięć i jak za chwilę przeczytacie są one adresowane do różnych użytkowników. Repozytoria adresowane do wszystkich użytkowników: 1. AUR-rebased W tym repozytorium będą umieszczane PKGBUILDy aplikacji, które znajdują się w AUR. Z jakichś jednakże przyczyn prezentujemy odmienne ich wersje. Trudno mi wyczerpująco wymienić jakie to zmiany. Przykładowo jednie mogę wskazać, że: * może to być inny sposób budowy paczki, * może to być paczka budowana z tzw. symbolami debugowania, * może być to inna wersja paczki (np. oparta o inny framework niż ten, na którym oparta jest paczka w AUR; przykładowo w AUR będzie paczka oparta o Qt4, a my będziemy oferować o Qt5), * może to być PKGBUILD umożliwiający budowę paczki z jakimiś dodatkami (np. nowe tematy), lokalizacją, wtyczkami itp. * może to być PKGBUILD umożliwiający budowę natywnej paczki dla danego typu procesora, * inne jeszcze, z których nawet możemy sobie obecnie nie zdawać sprawy. Na ile to możliwe, będziemy się starać, by zbudowana na podstawie tych PKGBUILDów paczka mogła koegzystować z "oryginalną". Niemniej jednak, gdy nie będzie to możliwe, to budowa "naszej" paczki dokona zamiany paczki z AUR. W zasadzie to repozytorium winno być uważane, jako bezpieczne dla każdego, zwykłego użytkownika. Spośród tych paczek najprawdopodobniej też najwięcej pojawi się w AUR. 2. new-branded To repozytorium przeznaczone dla aplikacji, których nie ma ani w repozytorium, ani w AUR. Podobnie jak poprzednie winno być uważane za bezpieczne dla każdego, zwykłego użytkownika i także te paczki mają równie duże szanse pojawić się w AUR. W odróżnieniu jednakże do poprzedniego repozytorium, gdzie taka sytuacja raczej nie powinna wystąpić, proszę zwrócić uwagę, że istnieje możliwość, że do budowy takiej aplikacji będzie wymagana jakaś zależność, której nie ma ani w repozytorium Archa, ani w AUR. Oczywiście taką zależność udostępnimy w POLAUR, jednakże będzie ona wymagała odrębnej budowy. 3. recompilated To repozytorium traktujemy jako repozytorium ostatniej szansy. Umieszczać tutaj będziemy PKGBUILDy, które umożliwiają zbudowanie paczki dla pacmana, jednakże nie budowaną ze źródeł, a z dostępnych paczek binarnych. Mogą się tutaj znaleźć PKGBUILDy dla oprogramowania własnościowego (oczywiście jeśli zgodnie z licencją taka przebudowa będzie dopuszczalna), mogą też znaleźć takie programy, które wprawdzie kod źródłowy oferują, jednakże uważamy, że ich budowa na "standardowej" maszynie trwać może wiecznie. Mogą się też znaleźć przebudowane paczki z innych dystrybucji, które z jakichś powodów nie chcą się budować w Archu, natomiast przebudowane działają prawidłowo. I dwa repozytoria dla bardzo odpowiedzialnych i obeznanych użytkowników 4. repo-refreshed Repozytorium będzie zawierać PKGBUILDy paczek, które dostępne są w oficjalnych repozytoriach Archa (i tylko tych, paczki dostępne w tzw. 3rd parties repository - jeśli będą przez nas zmieniane, to znajdą się w którymś z wyżej wymienionych repozytoriów). Różnica między oferowanymi przez nas tutaj PKGBUILDami, a oryginalnymi z Archa polegać będzie na dodaniu do nich jakichś patchy. Znowu trudno mi wymienić wszystkie możliwe, zatem przykładowo mogę wskazać na następujące możliwe zmiany: * zawierające łatki bezpieczeństwa (choć wątpię, byśmy zadziałali tu szybciej od opiekunów Archa), * zawierające łatki typu bugfix, dotyczące użyteczności, funkcjonalności jakichś programów, które przez ich twórców przeznaczone są dopiero do następnych wydań poprawkowych lub głównych, * zawierające jakieś łatki, które niekoniecznie są jeszcze zakwalifikowane do następnych wydań (i nie wiadomo nawet, czy się tam znajdą), ale poszerzające jakieś funkcjonalności. Dodatkowo tutaj mogą się znaleźć PKGBUILDy umożliwiające robienie paczek z oficjalnych repozytoriów, zawierające tzw. symbole debugowania. Ze względu na to, że ingerujemy tu w paczki, które są w oryginalnych repozytoriach, musimy zapewnić łatwą możliwość aktualizacji systemu. Stąd też paczki zbudowane z tego repozytorium będą miały oznaczenie numeru wersji, które w przypadku pojawienia się nowego wydania w repozytorium spowoduje ich aktualizację. Dotyczy to zarówno głównych wydań, jak i tylko zmieniających się wersji danego wydania. Skoro zagmatwałem, to opisowo. Paczki w Archu oznaczane są dwoma numerami (zasadniczo). Pierwszy to pkgver - numer wersji, który jest zasadniczo zgodny z numerem wydania przez twórców. Drugi to pkgrel - numer wydania, który dotyczy wyłącznie danej paczki, która niekiedy wymaga przebudowania, innym razem dostaje jakieś dodatki z jakichś powodów. Za przykład niech posłuży obecny kwin. Znajduje się on w wersji 5.12.1-2, co oznacza, że jest to kwin odpowiadający wersji 5.12.1 udostępnionej przez KDE, ale w drugim "wydaniu". Nasze paczki tu umieszczane będą nosić numer wydania rozdzielony kropką, czyli np. w tym przypadku byłby to numer 5.12.1-2.1. Pierwsza cyfra zawsze będzie odpowiadać numerowi wydania z Archa, druga niekoniecznie musi być zawsze jedynką, bowiem może się okazać, że z jakichś przyczyn będziemy musieli "podbić" numer naszej wersji. Wówczas będzie to numer np. 5.12.1-2.2 itd. Taka numeracja umożliwia ale i powoduje, że w przypadku pojawienia się w repozytorium Archa nowej wersji programu lub choćby wydania, to aktualizacja systemu spowoduje wgranie wersji z repozytorium w miejsce wersji zbudowanej z POLAUR. Jak już wspomniałem - tu trafiają "odmienione" paczki tego, co znajduje się w oficjalnych repozytoriach Archa, ale uzupełnione o coś. Będą to na przykład poprawki, które już są dostępne, ale przeznaczone do następnych wydań (poprawkowych lub głównych), a nawet uzupełniane o pewne funkcjonalności, które nie wiadomo, czy i kiedy trafią do wydania oficjalnego. W przypadku tych paczek proszę pamiętać, że numeracja przez nas stosowana będzie się różnić w stosunku do oficjalnej jedynie tzw. pkgrel, które w przypadku pojawienia się nowej wersji paczki w repozytorium Archa zawsze spowoduje aktualizację paczki z repo-refreshed do wersji z oficjalnych repozytoriów. (Np. znajdująca się tam wersja kwin ma numer 5.12.1-2.1 i w przypadku, gdy pojawi się zarówno wersja 5.12.1-3, jak i wersja 5.12.2 czy 5.13.0, to paczka zbudowana z tego repozytorium zostanie zaktualizowana do tych właśnie wersji). W takim przypadku w "naszym" repozytorium pojawi się nowa wersja, która - jeśli ktoś będzie chciał zachować poprzednią funkcjonalność - będzie musiała zostać znów zbudowana. Oczywiście nowe wersje pojawią się tu wyłącznie wówczas, gdy będzie to miało sens, czyli przede wszystkim, gdy nowa wersja dostępna w repozytoriach oficjalnych nie inkorporuje również patchy, które nakładamy. Nowe wersje pojawią się również tylko wówczas, jeśli będą dawały się jeszcze budować oraz - przynajmniej wg naszych testów (wszak mamy dość skromne możliwości ich przeprowadzania) - nie będą sprawiać problemów w systemie. Jeśli zatem nowa paczka w tym repozytorium nie pojawi się wkrótce po aktualizacji paczek z oficjalnego repozytorium, to najprawdopodobniej tak właśnie ma być (ale proszę ewentualnie pytać). Paczki budowane z repo-refreshed proszę traktować jako eksperymentalne. W żadnym wypadku nie wolno ich dodawać do paczek ignorowanych przy aktualizacji. Jeśli zastanawiacie się w ogóle po co tego typu paczki umieszczamy, to robimy to albo dlatego, że sami takich używamy, albo (i chyba przede wszystkim) bowiem ktoś na taką paczkę wyraził zapotrzebowanie. W niektórych przypadkach w ten sposób jest możliwe też usunięcie jakiegoś uciążliwego błędu wcześniej niż to będzie oficjalnie dostępne. Czytajcie PKGBUILDy, albowiem w nich jest opis nakładanych łatek. Niekiedy łatek będzie więcej niż jedna - w takim przypadku może się okazać, że komuś nie wszystkie są potrzebne. Wówczas do Was należy decyzja, czy instalować je wszystkie, czy nie. Jeśli nie wiecie - pytać! (poniżej będzie o tym jeszcze). 5. pkg-trunk To repozytorium wyłącznie dla osób testujących programy i wyłącznie dla osób, które wiedzą co robią. Muszą sobie umieć poradzić z jakimiś błędami, które mogą pojawić się w związku z ich używaniem (o tak podstawowych, jak choćby umiejętność przywrócenia oryginalnych wersji z repozytorium bez konieczności używania sesji graficznej, podłączenia do netu bez narzędzi GUI, ręczne podniesienie usług itp.). Paczki budowane z tego repozytorium należy traktować jako eksperymentalne. Będą tu umieszczane wczesne wersje (alpha, beta), wersje kandydujące (RC) itp. Tutaj też, a nie w repo-refreshed będziemy umieszczać PKGBUILDy paczek znajdujących się w takich repozytoriach Archa jak kde-unstable czy gnome-unstable uzupełnione o patche z GIT, które łatają jakieś problemy uwidocznione w fazie testowania tych programów. Dla ułatwienia diagnozowania problemów, z reguły będą to PKGBUILDy budujące programy z tzw. symbolami debugowania. Niektóre z nich (jak przykładowo kf5-rc1) będą składać się z wielu PKGBUILDów, które będą - niekiedy - musiały być budowane i instalowane w określonej kolejności. Niekiedy też będą one wymagać udostępnienia systemowi repozytoriów testing; zostaniecie o tym powiadomieni. Niekiedy też zbudowanie tych paczek będzie powodowało konieczność przebudowy innych paczek z dystrybucji. W przypadku korzystania z paczek z obu powyższych repozytoriów prosimy bezwzględnie informować nas o używaniu tego rodzaju oprogramowania w przypadku zgłaszania problemów w funkcjonowaniu systemu w ogóle. Podstawowym sposobem naprawy będzie zawsze przywrócenie oryginalnych wersji paczek z repozytorium. Paczki budowane z obu tych repozytoriów mogą powodować niestabilność niektórych elementów, jak i całości systemu. Mogą jednak również przynosić wymierne korzyści. Proszę o dużą rozwagę i olbrzymią świadomość w ich wykorzystywaniu. Są one w głównej mierze adresowane do osób, które chcą się przyczynić do rozwoju oprogramowania, choćby przez wdrożenie się do testów i sygnalizowanie błędów twórcom tych programów na wczesnych fazach ich rozwoju. Adresowane są - szczególnie z repozytorium pkg-trunk do zaawansowanych użytkowników. Nie ograniczamy się wyłącznie do umieszczania PKGBUILDów, które sami tworzymy na własne potrzeby, ale jesteśmy otwarci na Wasze propozycje, które prosimy umieszczać w wątku na polskim forum Archa lub w wersji anglojęzycznej. Możecie również skorzystać z opcji github "pull requests". Wszelkie uwagi do PKGBUILDów i działania paczek budowanych z tych repozytoriów prosimy zgłaszać na polskim forum Archa lub bezpośrednio na github w "Issues". Wszelkie paczki budowane z tych repozytoriów nie mają żadnego wsparcia ze strony Archa i jesteśmy wyłącznymi ich opiekunami i wyłącznie społeczność tego repozytorium za nie odpowiada oraz może udzielić jakiegokolwiek wsparcia. Raz jeszcze podkreślam - w przypadku zgłaszania jakichkolwiek problemów z systemem, w którym znajdować się będą paczki budowane w oparciu o PKGBUILDy z repozytoriów repo-refreshed oraz pkg-trunk proszę nas o tym informować. Informacje o dostępnych paczkach w tych repozytoriach, także z informacją o tym co zawierają oraz z ewentualnymi informacjami jak instalować, będą umieszczane w wątku na naszym forum. Na koniec informacja dla użytkowników Manjaro. Paczki oferowane w POLAUR są przetestowane na Archu. Nie dajemy absolutnie żadnej gwarancji i praktycznie nie oferujemy żadnego wsparcia użytkownikom Manjaro. Budowa paczek z repozytoriów repo-refreshed a już szczególnie z pkg-trunk w ogóle nie ma sensu na innej wersji Manjaro niż "Unstable". Proszę to wziąć pod uwagę.

piątek, 16 lutego 2018

Kameleonowe katalogi Breeze

Ot, taki sobie mały "ficzer". Przynajmniej część z nas ma "wysublimowany" gust estetyczny. Najczęściej objawia się to w tym, że nic takiej osobie nie pasuje w gotowych zestawach. To, kolor nie taki, to nie takie ikony. Zaczynamy szukać lub zmieniać we własnym zakresie. Na końcu prawie już ucieszeni swoim dziełem znów dochodzimy, że coś jest nie tak. Tym razem podobają nam się domyślne ikony Breeze w KDE. Ich wygląd nam się podoba. I kompletność. Zmieniwszy jednak schemat kolorystyczny Bryzy nie jesteśmy zachwyceni kolorami jakie przyjmują ikony katalogów. No gryzie się :) Wprawdzie można to żmudnie dostosować dzięki pewnym narzędziom, które w Plasmę zostały wbudowane. Jest jednak rozwiązanie prostrze. Otóż Andreas Kainz (o ile wiem, jeden z współtwórców zespołu VDG, albo osoba z nimi jakoś związana) stosunkowo niedawno udostępnił "odpad z produkcji" jakim jest Breeze Raibow Folders. Jak na razie nie jest planowane, by znalazł się on ponownie w master, albowiem jest "to cool for master" :) Czym jest ów zestaw ikon? Otóż przynosi on ze sobą ikony katalogów zgodne we wzornictwie z Breeze, ale odznaczające się ciekawą cechą. Przybierają one kolorystykę braną z aktualnego zestawu kolorystycznego Plasmy. Po ściągnięciu zestawu (choćby przez GHNS z Ustawienia systemowe -> Ikony -> Pobierz nowy zestaw), dokonujemy jego wyboru (pozostałe ikony Plasma czerpie z zestawu "Breeze"), jeszcze restart Plasmy i ewentualne przeczyszczenie katalogu ~/.cache w zakresie dotyczącym wystrojów i możemy się cieszyć "nowymi, starymi" ikonami Breeze, które jakoś teraz lepiej wyglądają. Oczywiście mogę przygotować PKGBUILD, ale czy istnieje taka potrzeba?

sobota, 3 lutego 2018

qStopMotion wersja Qt5

Niedawno pojawiło się nowe wydanie - wersja 2.4.0 - programu do przechwytywania zdjęć z kamer podłączonych do komputera (stopklatka) - qStopMotion. Nie wiem jak poprzednie, ale tę wersję można zbudować również w oparciu o Qt5. Nie wiem również z jakich powodów w AUR jest wersja budująca się jeszcze na Qt4. Ze względu na to, że nic nie stoi na przeszkodzie budowie programu opartego o nowszą wersję, a Qt4 odchodzi już powoli od nas, postanowiłem zrobić PKGBUILD właśnie dla programu w takiej wersji. Kilka uwag o tym PKGBUILDzie. Dla rozróżnienia wersji, proponowana przeze mnie paczka nazywana jest qstopmotion-qt5. Program zbudowany z mojego zastępuje wersję z AUR i jednocześnie dostarcza ten program (nie jest możliwa koegzystencja obu wersji). Program jest budowany z użyciem qt5-multimedia, stąd nie zawiera dwu sugerowanych zależności: gstreamer oraz ffmpeg - gdyby się z jakichś przyczyn okazało, że program nie działa w pełni funkcjonalnie, prawidłowo, to proszę zbudować ją wpierw z tymi zależnościami również.

LibreOffice 6.0 a natywna wtyczka Qt5

Sporo zamieszania się zrobiło z nowym wydaniem LibreOffice 6.0 oraz istnieniu w tym wydaniu natywnej wtyczki Qt5, która polepszyłaby integrację tego pakietu w środowiskach opartych o ten framework. Dość, że pojawiły się nawet fake newsy o tym, że: "Użytkownicy KDE/Plazmy będą zadowoleni z nowej wtyczki dla Visual Components Library, która łączy się z biblioteką Qt5 i zapewnia pełne wsparcie dla funkcji tej biblioteki w LibreOffice, w tym obsługi wskaźnika myszy, kursorów i okien dialogowych". Przyznam, że nie wiem, gdzie autor tego tekstu widział ową wtyczkę, jak również skąd wziął informację, a tym bardziej, że zapewnia pełne wsparcie dla Qt 5 w LibreOffice 6.0. Dość powiedzieć, że obie oficjalnie paczkowane przez Document Foundation wersje LO6.0 (rpm oraz deb) nie są kompilowane z tą wtyczką. Nie zawiera ich też żadna z przeglądniętych przeze mnie paczek w dystrybucjach, które tę wersję już udostępniły (Arch, OpenSUSE Tumbleweed, czy nawet KaOS). Jedyna zapowiedź jaką znalazłem, to porzucenie przez zespół Debiana wsparcia dla vcl-kde4 i zastąpienie go hybrydową wtyczką vcl-gtk3_qt5, ale dopiero w wersji 6.1 (swoją drogą, to oficjalne wydanie deb z repozytorium daily LibreOffice datowane na 3.02.2018 r. w dalszym ciągu nie oferuje tej wtyczki). Wprawdzie kod dostarczany wraz z LibreOffice 6.0 zawiera już odpowiednią zawartość dla budowy także i tej wtyczki, ale problem jest taki, że nawet jeśli się ją uda zbudować (zob. błąd dotyczący kompilacji na Qt 5.9 i Qt 5.10) to i tak albo po prostu nie działa, albo działa źle. Jak przyznaje Jan-Marek Glogowski (a to chyba dość dobrze rozeznana w temacie osoba): it's still too buggy and not usable. Zwróćmy też uwagę, że informacja o wydaniu LO 6.0 słowem nie wspomina o tej wtyczce. Innymi słowy: wtyczki VCL_QT5 (obojętnie w jakiej formie) w LibreOffice 6.0 nie ma, nie było i w całym jego cyklu wydawniczym, raczej jej nie zobaczymy. W przypadku stanu prac w Archu możemy poszukać informacji w zgłoszeniu na bugzilli Archa ewentualnie śledzić wpisy na jego BBS jak również na bugzilli Document Foundation. Niemniej jednak, po prostu porzućcie nadzieję.

środa, 17 stycznia 2018

Transmission pozbawiony błędu CVE-2018-5702

Sieć przeszła informacja o dziurze w programie. Ba, nawet została okraszona informacją, że wstrętni twórcy tej aplikacji nie robią nic, a problem poważny, dotyczy bezpieczeństwa. Jak się okazuje problem został załatany. Fakt, w Archu (a zatem i w dystrybucjach pokrewnych) jeszcze nie ma nowej paczki z uwzględnieniem tego patcha. Problem został zgłoszony dzisiaj (17.01.2018), a zatem pewnie już niebawem zostanie poprawiony. Niemniej jednak używający transmission mogą się poczuć zaniepokojeni. Dla nich przygotowałem PKGBUILD, zbudowany w oparciu o tzw. nightly builds, które uwzględniają poprawkę bezpieczeństwa. PKGBUILD jest jedynie przebudowanym z oficjalnego repozytorium. Zmiany są następujące: - paczka źródłowa, na podstawie której budowana jest paczka dla Archa to "nighthly builds" (dokładnie uwzględniająca commit reb5d1a79cb, - usunięte zostały patche, które zostały nałożone w "nightly builds". Innych zmian nie dokonywałem.

wtorek, 16 stycznia 2018

Plasma 5.12 LTS Beta udostępniona

Z około dwutygodniowym opóźnieniem ukazała się wczoraj wersja Beta nowej odsłony środowiska graficznego Plasma. Oznaczona numerem 5.12 (w przypadku bety to 5.11.95) jest drugim wydaniem o przedłużonym wsparciu (18 miesięcy, o ile pamiętam). Oczekujący jakichś niesamowitych nowości muszą się poczuć zawiedzeni (choć nikt ich nie zapowiadał). Nowa Plasma nie jest bowiem niczym innym, jak po prostu kolejnym wydaniem poprawkowym dla całej serii Plasma 5. Usunięto część błędów, jakie pojawiały się w poprzednich wydaniach. Z rzeczy istotniejszych (bowiem owe błędy można naprawić nawet we własnym zakresie) wg zapowiedzi Plasma ma teraz jeszcze mniejszy apetyt na zasoby komputera. Jest to również pierwsze wydanie, gdzie możliwość pracy w sesji Wayland osiągnęło również status LTS. W tym ostatnim przypadku kilka informacji. Osoby, które używają kart graficznych NVidia nie uruchomią sesji Plasmy w Wayland na sterownikach zamkniętych. Część programów (choć to nie jest kwestia samego środowiska graficznego) ma też jakieś problemy w przypadku takiego korzystania (np. Kontact) i to nawet jeśli stosowne zmiany zostały już wprowadzone do kodu. Od wczorajszej nocy stosowne paczki trafiły już do repozytorium [kde-unstable] Archa. Możemy zatem je przetestować, zgłościć ewentualne błędy, tak by wydanie spodziewane w pierwszych dniach lutego (6.02. - także przesunięte o tydzień w stosunku do pierwotnego harmonogramu) było lepsze. Pamiętajmy, że paczki w [kde-unstable] są budowane na podstawie paczek z [testing]. Chcąc wypróbować to wydanie musimy zatem udostępnić również i to repozytorium. I jeszcze jedna uwaga - osoby, które zdecydują się na testowanie, winny raczej spróbować "czystej" sesji Plasma 5.12, a dopiero do niej "dokładać" swoje własne ustawienia, ulubione aplety. W ten tylko sposób będziecie wiedzieć czy ewentualny błąd leży w samej Plasma, czy też jest wynikiem działania jakiegoś apletu, widżetu, czy nawet niestandardowego wystroju. I jeszcze garść linków dla testerów: Ogólnymi wrażeniami z użytkowania można się podzielić w wątkach: na oficjalnym forum Archa oraz na naszym forum. Tutaj też uzyskacie (szczególnie na pierwszym) ewentualną informację odnośnie tego, czy błąd leży po stronie opiekunów Archa i coś zostało po prostu źle spaczkowane, czy też należy go zgłosić w KDE. Błędy należy zgłaszać: na bugzillach Archa poprzedzając informację przez dodanie [kde-unstable] (najlepiej) i/lub KDE. Pamiętajmy przy tym, że zgłoszenie błędu jako obserwacji zachowania najczęściej nic nie daje oraz o tym, że paczki Archa są budowane bez flagi Debug, która umożliwia "analizę przypadku". Najczęściej zatem trzeba będzie taką paczkę przekompilować, ale w tym zakresie otrzymacie już stosowną pomoc na obu forach.

czwartek, 28 grudnia 2017

Małe a cieszy: uksmstat

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.