Naprawiamy błąd w KDE

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ą dostarczone wraz z jakąś aktualizacją, nawet jeśli paczkujący są świadomi takich błędów. Ot, nie tak dawno mieliśmy do czynienia z wprowadzeniem Qt 5.10, które powodowało, że kliknięcie w tzw. widoku folderu na jakąkolwiek ikonę prawym klawiszem myszy wyświetlało dwa, zamiast jednego okna menu. Oczywiście w takim przypadku można cofnąć odpowiednie paczki do poprzedniej wersji, można też - o ile są już zrobione - spróbować nałożyć łatkę, która błąd winna usunąć. I tym ostatnim rozwiązaniem się zajmiemy. Przygotujmy zatem nasz stół pracy. Przede wszystkim źródła wiedzy. Cóż, oprócz różnych list mailingowych, kanałów IRC, czy forów internetowych, zasadniczo mamy dwa źródła w takim przypadku. Pierwszym jest strona raportowania błędów w oprogramowaniu KDE, drugim to strona, na której przedstawiane są prace nad rozwojem dystrybucji. Dodatkową jest repozytorium kodu KDE. Z pierwszego i drugiego dowiemy się, czy uciążliwy dla nas błąd został naprawiony. Z drugiego, a przede wszystkim z trzeciego ściągniemy odpowiednią łatkę, choć zdarza się, że pojawiają się one też na pierwszym. Musimy zatem ustalić błąd, ustalić łatkę, pobrać ją i nałożyć. Proste? Oczywiście, ale jak to zrobić? Oczywiście możemy poprosić opiekunów paczek w Archu o dodanie łatki. Niekiedy w istocie są one nakładane bez naszych próśb (tak było z łatką na wyżej opisany błąd). Nawet jednak, gdy poprosimy, to nie wymagajmy od nich, by nasza prośba została od razu wysłuchana. To społecznościowa dystrybucja, gdzie każdy oprócz dbania o paczki, które ma pod swoją opieką ma jeszcze tuzin innych spraw na głowie. Co najmniej. Możemy zatem również zrobić to samo, co zrobiłby opiekun, tyle, że we własnym zakresie. Tworzenie PKGBUILDów (czy ich - jak w tym przypadku zmiana) to nie żadne voodoo nie do pojęcia, żadna czarna magia. Stworzenie paczki nie spowoduje awarii elektrowni, a i w domu korki nie wyskoczą. Ręczę. Skoro będziemy zmieniać PKGBUILD to jest on nam konieczny. Najprościej posłużyć się tu asp (choć np. popularny yaourt też sobie z tym poradzi). Ostatecznie możemy ściągnąć ręcznie. Ja opiszę pierwszy sposób. Zaczynamy od aktualizacji bazy asp oraz zaimportowania na lokalny komputer interesujących nas źródeł paczek - w moim przypadku będzie to KIO - oraz do przejścia do katalogu, który zostanie utworzony:
asp update && apt export kio && cd kio
Mamy już źródła, teraz czas je zmieniać. Na podanych przeze mnie wyżej stronach źródeł odszukujemy to co nas interesuje. Powiedzmy, że chodzi taki błąd. Jak widzimy na stronie bugs.kde.org, istnieje dla niego jakieś rozwiązanie. Możemy przeglądnąć również prace nad tym błędem i ich testowanie na phabricator.kde.org. My przechodzimy jednak do repozytorium KIO (oczywiście klikając w odnośnik do commitu), która przenosi nas w świat tajemniczego kodu źródłowego. Dla nas istotna jest informacja, że łatka (patch) jest i w formie, z której będziemy chcieli skorzystać (plain) możemy ją odkryć pod... uwaga... tajemniczym odnośnikiem patch. Mamy już zatem indywidualny adres łatki, to owe https://cgit.kde.org/kio.git/patch/?id=TUTAJ_CIĄG_CYFR_I_LITER. Możemy ten adres skrócić do pierwszych ośmiu cyfr. Zidentyfikuje nam tę samą łatkę. Powracamy w tym momencie do pobranych wcześniej źródeł paczki Archa i dokonujemy edycji PKGBUILDu. Interesować nas będą wyłącznie następujące pozycje: pkgrel, sources oraz sekcja prepare (jeśli jej nie ma, to będziemy musieli stworzyć; w przypadku oprogramowania KDE najczęściej istnieje, albowiem w niej zakładany jest katalog build). Pierwszą pozycję (pkgrel) możemy jakoś zmienić, by odróżnić swoją paczkę od paczki oryginalnej. Nie jest to jednak konieczne. Pamiętajmy jednakże, że nadanie "wyższego" numeru spowoduje, że gdy znajdzie się taka paczka w repozytorium, to nie zostanie ta paczka zaktualizowana, nadanie jakiegokolwiek numeru "połówkowego", czy niezmienienie go w ogóle spowoduje, że nowa wersja tej paczki zostanie wgrana w miejsce przez nas stworzonej. Tak, źle i tak nie dobrze? Nie! Ingerujecie w system, a zatem od tej chwili odpowiedzialność za niego przechodzi na Was. Musicie o niego zadbać, przy aktualizacji sprawdzać co, jak i dlaczego ulega zmianie i w zależności od tej wiedzy dostosować swoje działania. Druga pozycja (sources) jest ważniejsza. Tutaj bowiem poinformujemy, że do dotychczasowych źródeł chcemy coś dodać. Posiłkując się przykładem KIO, obecne źródła aktualnej paczki 5.41.0-1 wyglądają tak:
source=("https://download.kde.org/stable/frameworks/${pkgver%.*}/${pkgname}-${pkgver}.tar.xz"{,.sig})
My chcemy do niego dodać patch na błąd 386364. Musimy zatem w tych źródłach poinformować makepkg, że oprócz nich ściągnąć ma jeszcze patch, który zidentyfikowaliśmy wcześniej. Dopisujemy zatem do źródeł https://commits.kde.org/kio/ca2364d9. Osobiście polecam nazwać tak ściągnięty patch w jakikolwiek sposób, który byłby dla nas czytelny, np. kdebug-386364.patch. Źródła patcha przyjmą zatem postać:
kdebug-386364.patch::https://commits.kde.org/kio/ca2364d9
Cała sekcja sources wyglądać winna w tym momencie tak:
source=("https://download.kde.org/stable/frameworks/${pkgver%.*}/${pkgname}-${pkgver}.tar.xz"{,.sig} "kdebug-386364.patch::https://commits.kde.org/kio/ca2364d9")
Jak na razie poinformowaliśmy makepkg, by jedynie dodatkowe źródła zostały ściągnięte. Musimy jeszcze poinformować go, by przed rozpoczęciem budowy paczki nałożył patch. Przechodzimy do sekcji prepare i dodajemy w niej
patch -p1 -i ../kdebug-386364.patch
Wcześniej musimy jednak poinformować skąd ów patch ma być nałożony. W tej samej sekcji musimy zatem zmienić katalog:
cd $pkgname-$pkgver
Cała sekcja od tej chwili wyglądać winna tak:
prepare() { mkdir -p build cd $pkgname-$pkgver patch -p1 -i ../kdebug-386264.patch patch -p1 -i ../kdebug-386364.patch }
Zamykamy edycję PKGBUILDu zapisując go i wydajemy jeszcze polecenie do aktualizacji sum kontrolnych:
updpkgsums
Teraz już możemy zbudować paczkę. Jeśli wierzymy w swoje umiejętności możemy również ją od razu zainstalować, odinstalować wszelkie zależności służące do budowy paczki oraz skasować katalogi, w których nastąpiło budowanie i tworzenie paczki. Jednym poleceniem:
makepkg -sirc
Polecam jednakże weryfikację zbudowanej paczki (a wcześniej PKGBUILDu) poleceniem namcap. Proste? Powiedzmy, że tak. Teraz jednak przyszedł czas na kubeł zimnej wody. Nikt nikomu nie gwarantuje, że taka łatka w istocie poprawi działanie. Może poprawić jeden element, może popsuć inny. Wszak to jest jak zespół naczyń połączonych. Patchowanie wymaga pewnej wiedzy i pewnej staranności od tego, kto to robi. Przede wszystkim jednak od tego momentu - powtórzę - dokonaliście ingerencji w system, którego używacie. Musicie nad nim zatem przejąć pełniejszą kontrolę oraz sami o niego dbać. W przypadku zgłaszania jakichkolwiek błędów w KDE, czy też szukając pomocy na forach musicie poinformować o tym, że Wasz system w jakiś sposób odbiega od oczekiwanego oryginału.

Komentarze

Popularne posty z tego bloga

Brak możliwości aktualizacji lub instalacji pakietów - zablokowana baza

Radzimy sobie z: GPG: odbiór z serwera kluczy nie powiódł się: brak dirmngr

Ukryte sztuczki Firefox