tag:blogger.com,1999:blog-84319749488200463362024-02-19T08:19:03.407-08:00pavbaranov Archpavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.comBlogger243125tag:blogger.com,1999:blog-8431974948820046336.post-34039890283359850342020-07-26T07:17:00.002-07:002020-07-26T07:17:47.942-07:00Ukryte sztuczki FirefoxOkazuje się, że Firefox ma ukryte funkcje. Nic dziwnego. Od dawna ma, czy miewa. Jedną z nich jest inny sposób renderingu. Nazywa się WebRendering i ponoć pomaga w niektórych przypadkach w przeglądaniu stron w sesji Waylanda. Domyślnie jest wyłączony. Oczywiście włączyć można prosto. W pasku wpisujemy <i>about:config</i> i zgadzamy się na to, że zepsujemy przeglądarkę. Odszukujemy wpis: <i>glx.webrender.all</i> i zmieniamy jego wartość z <i>false</i> na <i>true</i>.<br />
<br />
Źródło: <a href="https://pointieststick.com/2020/07/25/psa-try-turning-on-webrenderer-in-firefox/">https://pointieststick.com/2020/07/25/psa-try-turning-on-webrenderer-in-firefox/</a>pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-53971927784140096632020-06-17T06:26:00.002-07:002020-06-20T05:45:37.702-07:00Primum non facere! - czyli nie rób u kogoś w systemie burd*Nie pamiętam już jak długo jestem czynnym uczestnikiem różnego rodzaju forów internetowych dotyczących linuksa. W niektórych uczestniczę w istocie czynnie, inne jedynie przeglądam. Na jednych byłem, na innych jestem teraz. I... i bardzo bym chciał, by tym doradzającym przyświecała tytułowa, łacińska zasada. Medyczna przede wszystkim, ale chyba wszyscy winni sobie ją wziąć do serca i stosować w dowolnej dziedzinie, w której chcą komuś radzić.<br />
Do napisania mnie tego <i>felietonu</i> zainspirowały mnie farmazony znalezione w pewnym <a href="https://forum.manjaro.pl/t/instalowanie-tar-xz-pewnie-proste/1253/34">wątku na pewnym forum</a>. Kompletny brak zrozumienia podstaw używanego przez siebie systemu, kompletny brak zrozumienia jego odmienności od innego, spowodował, że <i>dobrą</i> :) poradą stało się dostarczenie systemowi repozytorium dla innego systemu. W tym przypadku jest to tzw. nieoficjalne repozytorium dla Archa, które ktoś proponuje używać w Manjaro, ale problem dotyczy również repozytoriów/paczek Ubuntu w Debianie (czy odwrotnie) itp. Można tych przykładów mnożyć.<br />
Zatem po pierwsze <b>rozwiązanie takie jest totalną głupotą!</b> I nie ma tu żadnego znaczenia, że coś takiego "u mnie działa" itp. Proponowanie zaś komuś zastosowania czegoś takiego jest natomiast przykładem skrajnej nieodpowiedzialności radzącego. Przy okazji pokazuje, że <i>doradzający </i>:) ma absolutnie małą wiedzę o systemie/-ach, a że zwykle taki człowiek jest stałym bywalcem jakiegoś forum, niejednokrotnie pełniąc tam jeszcze jakąś funkcję (np. moderatora), to osoby mało obeznane w systemie, dopiero co zaczynające z nim przygodę, traktują taką poradę jako wyrocznię. Cóż - równie dobrze i skutecznie można byłoby doradzić: skasuj sobie system, sformatuj dysk itp. oczywiście w jakiejś formie konsolowego polecenia, którego ów dopiero startujący raczej nie zrozumie.<br />
Dlaczego jestem tak kategoryczny? Bo inaczej być nie może.<br />
Skoro odnoszę się do tandemu Arch i Manjaro, to na tym przykładzie pokażę na czym głupota takich porad polega.<br />
Przede wszystkim należy sobie uświadomić jedną rzecz: wbrew idiotyzmom wciskanym przez <i>światłych znawców systemów linuksowych</i> - Manjaro to nie jest "Arch z ludzką twarzą". To nie jest "Arch dla każdego". To nie jest... i tu można wymienić cokolwiek, co wskazywałoby na to, że Manjaro "jest" Arch Linuksem. Nie jest. Podobnie jak Ubuntu nie jest Debianem. Fakt, że Manjaro używa paczek z Archa nie stanowi o tym, że jest Archem. Pomijając różne kwestie, z omawianego punktu widzenia istotne jest, że Manjaro oferuje paczki Archa przesunięte w czasie w stosunku do momentu, w którym pokazują się one w Archu. Niekiedy ten czas jest krótszy, niekiedy dłuższy - nie ma to znaczenia. Grunt, że stabilne wydanie Manjaro jest wobec stabilnego repozytorium Archa przesunięte w czasie.<br />
Repozytoria nieoficjalne dla Archa - jeśli są prawidłowo zarządzane - są przygotowywane z myślą o Archu. Oznacza to, że są one budowane na podstawie paczek w wersjach, w jakich w danym momencie znajdują się one w repozytoriach Archa. Ba, w niektórych przypadkach repozytoria te prowadzone są zarówno w sposób kompatybilny z repozytorium stabilnym, jak i testowym.<br />
Kiedyś już wspominałem przy innej okazji, że PKGBUILDy niezmiernie rzadko zawierają informacje o zależnościach w konkretnej wersji. Najczęściej posługują się jedynie nazwą paczki, albowiem zakładają, że system jest aktualizowany w całości i w sposób ciągły. Ba, zakładają, że instalacja jakiegoś oprogramowania również połączona jest z aktualizacją systemu. W przeciwnym przypadku dochodzi do tzw. częściowej aktualizacji, która nie jest w Archu (przez pacmana) wspierana. Innymi słowy, jeśli np. zależnością <i>kate </i>jest <i>ktexteditor</i>, to ta aplikacja jedynie wie, że ma korzystać z frameworka o owej drugiej nazwie. Nic więcej. Jednocześnie pierwsza paczka jest budowana w oparciu o drugą paczkę, która występuje w określonej wersji. Ba, w tym przypadku nawet plik, który buduje tę aplikację ma zadeklarowane w jakiej wersji ma znajdować się framework, na którym jest oparta i zbudowana. W konsekwencji może to powodować, że w systemie, w którym dostarczymy <i>kate</i> zbudowane na określonej wersji <i>ktexteditor</i> paczka będzie działać, ale wyłącznie wówczas, gdy znajdująca się w systemie <i>ktexteditor</i> odpowiada tej wersji, na której została zbudowana <i>kate</i>. Możemy sobie teraz wyobrazić, że owe <i>kate</i> będzie wykorzystywane jeszcze przez następną aplikację, a ta jeszcze przez następną itd.<br />
Przypuśćmy zatem, że takie <i>kate</i> zainstalowaliśmy sobie w Manjaro z nieoficjalnego repozytorium dla Archa. W Manjaro jest oczywiście <i>ktexteditor</i>, ale może on być w innej wersji niż ta, na której zostało zbudowane <i>kate</i> znajdujące się w owym nieoficjalnym repozytorium. W efekcie <i>kate</i> może działać w Manjaro (co będzie przypadkiem, a nie regułą), ale może wcale nie działać. Dodatkowo jeśli dostarczymy systemowi repozytorium, to niezależnie od jakiegokolwiek aurhelpera, będzie ono miało priorytet przed wszystkimi paczkami, jakie zbudowane mamy w systemie z AUR. Prawidłowo wykonana aktualizacja systemu doprowadzi zatem również do aktualizacji tych paczek (i pomijam sens instalacji paczek z AUR w Manjaro). Jeśli nie dokonamy tego od razu, to notyfikator tego typu jak zawarty w pamac za chwilę nas powiadomi.<br />
Czy już wystarczy dla zrozumienia proponowanej głupoty?<br />
Pół biedy jeśli instalowana paczka jest "na samej górze" zależności, jest aplikacją, której nie wykorzystuje jakakolwiek inna paczka itd. W tym przypadku po prostu aplikacja nie będzie działać prawidłowo, a najczęściej po prostu się nie uruchomi. Jeśli jednak dostarczając systemowi obce repozytorium, dostarczymy również w niewłaściwej w tym systemie wersji zależności jakiejś innej paczki, to do destabilizacji systemu bardzo niedaleko.<br />
Czy doprawdy tak trudno przyjąć sobie za nienaruszalną zasadę: <i>primum non facere</i>? I nawet jeśli jakieś rozwiązanie "u mnie działa", to jeśli nie jest ono zgodne z danym systemem, to po prostu wstrzymać się z idiotycznymi poradami: zainstaluj sobie obce dla systemu repozytorium.<br />
I proszę wybaczyć - nie wytrzymałem, bowiem głupoty znieść nie mogę.<br />
<br />
PS: I by nie było niedopowiedzeń. Powyższy tekst w żadnym przypadku nie jest jakąkolwiek krytyką Manjaro. Arch i Manjaro to tylko przykład. Równie dobrze mógłby dotyczyć jakichkolwiek innych dwu dystrybucji, w których można "skrzyżować" repozytoria. Przynajmniej na pierwszy rzut oka. Tekst jest - jak w tytule - o niefrasobliwości porad na forach. Dopisek zaś dla osób, które tego nie zrozumiały.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-30392068579631656442020-04-13T01:10:00.002-07:002020-04-13T01:10:32.505-07:00AUR dla Manjaro?
<style type="text/css">
p, li { white-space: pre-wrap; }
</style>
<br />
Załóżmy hipotetycznie, że opiekunowie paczek z AUR wywiązują się ze swoich (w dodatku przez samych siebie na siebie nałożonych) obowiązków w sposób celujący, a porzucone oprogramowanie w AUR nie istnieje. Załóżmy nawet, że dotyczy to wyłącznie tych paczek, które z AUR używamy. Przyjęcie takiego założenia oznacza, że nowe PKGBUILDy w AUR będą się pojawiać w przynajmniej dwu sytuacjach:<br />
- albo oprogramowanie pojawi się w nowszej wersji,<br />
- albo zaistnieje konieczność przebudowania oprogramowania niezależnie od wersji.<br />
Zastanówmy się teraz przez chwilę jak budowane jest jakiekolwiek oprogramowanie ze źródeł. Otóż oprócz nielicznych wyjątków (np. słynne update-grub, które jest po prostu plikiem wykonywalnym powłoki zasadniczo z jedną linijką polecenia), wszystkie inne mają jakieś zależności. W dodatku dwojakiej postaci. Jedne są to zależności służące wyłącznie do zbudowania paczki. W późniejszym działaniu programu nie są one konieczne. Drugie uczestniczą zarówno w budowie, jak i są wymagane następnie do działania programu. Są jeszcze trzecie - zależności opcjonalne, które również niekiedy są wymagane w procesie budowania paczki. Wszystkie one w chwili budowania tej paczki występują w jakichś wersjach, które aktualnie mamy w systemie. Nie wnikając w szczegóły - są tego typu programy, które zadowolą się niemal dowolną wersją owych zależności, albo też jakąś wersją minimalną, ale są też i takie, które po każdej zmianie (aktualizacji) zależności będą wymagać swej przebudowy. Inaczej działać nie będą. Ta druga sytuacja wymaga od opiekuna paczki w AUR, by po pojawieniu się w repozytorium Archa paczek, na których jest zbudowana dokonał odpowiednich zmian, które zasygnalizują jej użytkownikowi, że wymagana jest ponowna kompilacja paczki.<br />
Przy prawidłowo utrzymywanej instalacji Archa, powinniśmy go mieć aktualizowanego na bieżąco. Zatem paczki budowane z AUR winny być budowane na wersjach swych zależności takich, jakie są dostępne w repozytoriach Archa (i lokalnie w naszym systemie). Jeśli używamy paczek z AUR oznacza to również, że nasze, lokalnie budowane paczki będą dostosowane do aktualnych wersji oprogramowania, które zostało zainstalowane z repozytoriów Archa. Tak skonstruowany system winien działać prawidłowo. <br />
Paczka w AUR nie będzie również wymagać swej przebudowy tak długo, jak długo w repozytorium Archa nie pojawi się nowa wersja jej zależności, której konsekwencją będzie przebudowa. <br />
Ba, może okazać się, że jakaś paczka w AUR wymagać będzie wersji swojej zależności takiej, jaka jest w Archu (sporadycznie, ale zdarzają się takie sytuacje). <br />
Dla niemal wszystkich dystrybucji pochodnych od Archa, korzystanie z AUR jest bez żadnego wpływu. Dystrybucje te wykorzystują bowiem bezpośrednio repozytoria Archa, co najwyżej wprowadzając jakieś swoje, mało istotne z punktu spójności systemu, paczki do swoich repozytoriów (wyjątkiem był, a i to nie w całym zakresie, Antergos, ale ten już nie istnieje). Użytkownicy tych dystrybucji pochodnych mogą zatem korzystać w pełni z dobrodziejstw AUR, są powiadamiani o konieczności zmian, przebudowy paczek z AUR itd. itp.<br />
Spośród znanych mi dystrybucji pochodnych, jest tylko jedna, która dysponuje własnymi repozytoriami oraz umożliwia instalację paczek z AUR. To Manjaro. Ba, nawet ich sztandarowe narzędzie do zarządzania paczkami - pamac - rozszerzać może swe działanie również na AUR. Jednocześnie paczki - choć w bardzo dużej ilości bezpośrednio pochodzące z repozytoriów Archa - są w tym systemie opóźniane o jakiś czas. Od godzin, po tygodnie. <br />
I to wystarcza, by stwierdzić: AUR nie jest dla Manjaro. Niezależnie od tego jak osoby rozwijające Manjaro, czy jego użytkownicy będą zaklinać rzeczywistość - AUR nie nadaje się do stosowania wprost w tej dystrybucji. Oczywiście, że oprogramowanie zbudowane z AUR w tym systemie może działać, ale jeśli tak się dzieje, to jest to przypadek, a nie reguła. Zasadniczo też PKGBUILD paczki z AUR będzie mógł być zastosowany w Manjaro w tym sensie, że doprowadzi na tej dystrybucji do zbudowania paczki, która z nielicznymi wyjątkami będzie działać. Użytkownik Manjaro korzystający z AUR musi mieć jednak wiedzę o niebo większą od użytkownika Archa (i każdej innej jego pochodnej), albowiem będzie musiał wiedzieć kiedy ma dokonać przebudowy paczki i dlaczego. Żadnej pomocy ze strony opiekunów w AUR nie otrzyma, albowiem to repozytorium dostosowane jest do Archa, a nie do Manjaro. Ba, narzędzia dostępne w Manjaro, a zarządzające oprogramowaniem - w przypadku włączenia im obsługi AUR - będą go informować o konieczności przebudowy paczki pomimo tego, że w Manjaro akurat nie jest to wymagane. Gdy później w Manjaro zostaną zaktualizowane paczki w repozytoriach, które w istocie będą wymagać przebudowania paczki z AUR, to w żaden sposób nie zostanie on o tym poinformowany. Użytkownik taki jest zdany sam na siebie i to on musi wiedzieć, że określona paczka wymaga przebudowania i to pomimo tego, że system twierdzi, że jest aktualny.<br />
Wisienką na torcie jest deklaracja, że Manjaro jest adresowane do mniej obeznanych z systemem użytkowników niż użytkownicy Archa, wymaga nieco mniejszej wiedzy. pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-3532287013164074082020-03-28T10:52:00.000-07:002020-03-28T10:52:08.963-07:00Częsty "crash" balooNiestety, jak się wydaje, lmdb z którego korzysta baloo sprawia ostatnio sporo problemów i są zamysły by go w baloo porzucić. Owe problemy sprowadzają się do bardzo częstego wywalania się baloo i różnych jego modułów, które możemy zaobserwować już podczas startu systemu. Jeśli obserwujemy takie zjawisko u siebie, to do czasu, gdy baloo zostanie przebudowane przez KDE, być może pomocnym będzie następujące rozwiązanie.<br />
Otwieramy konsolę i wpisujemy:<br />
<blockquote class="tr_bq">
balooctl purge && balooctl enable</blockquote>
Jeśli baloo u Was działa prawidłowo, nie jest to konieczne. Pierwsze polecenie dokona usunięcia bazy danych indeksów, zaś drugie ponownie uruchomi baloo (bowiem najprawdopodobniej nie będzie działać).pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-77582832978225371922019-12-05T23:29:00.003-08:002019-12-05T23:29:40.920-08:00Przywracamy działanie drukarek w CUPS 2.3.0Co najmniej wraz z nastaniem CUPS 2.3.0 (choć problemy zgłaszane były już w późnych wersjach serii 2.2.x) część (i to spora) drukarek odmówiła współpracy. Nie było też możliwości ich zainstalowania. Problem związany był ze zmianą dokonaną w CUPS polegającą na tym, że przestał on "przyjmować" te PPD (czyli ogólnie sterowniki drukarek), które miały wpisane "Custom" w różnych deklaracjach. Obecnie CUPS przyjmował tam "Other", a "Custom" powodowało, że drukarki stawały się tańszą lub droższą, niemniej jednak wyłącznie ozdobą naszych biur i domów. <br />
Sama zmiana dokonana w CUPS nie była zachcianką jego deweloperów, a powodowana była chęcią uniknięcia sygnalizowanego innego błędu powodującego wykrzaczanie się cupsd. I wszystko dobrze, ale spowodowała unieruchomienie znacznej ilości urządzeń.<br />
Problem nie dotyczy wyłącznie Archa i jego pochodnych, ale dotknął niemal wszystkich w miarę świeżych dystrybucji.<br />
Oczywiście owe PPD winny zostać przerobione przez ich twórców, jednakże znakomita ich część w przypadku "wspierania" linuksa ogranicza się do wypuszczenia sterownika i zapomnienia o nim.<br />
Zasadniczo problemu by nie było, albowiem w tego typu sytuacjach często z pomocą przychodzi cofnięcie CUPS do poprzedniej wersji działającej. Tu jednak pojawił się kolejny problem, a mianowicie w takiej sytuacji koniecznym jest cofnięcie trzech paczek: <i>cups</i>, <i>libcups</i> oraz <i>cups-filters</i> - zasadniczo wszystkie muszą pochodzić z tego samego czasu (tj. być zbudowane w tym samym okresie). Tak przeprowadzona operacja kończyła się najczęściej jednak informacją "Filter failed", co sygnalizowało błąd z <i>cups-filters</i>. I słusznie, albowiem ta paczka wymaga przebudowy wraz z wprowadzeniem do systemu nowej wersji <i>poppler</i>, a ten się pojawił. I znów - w normalnych warunkach wystarczającym remedium powinno być przebudowanie <i>cups-filters</i> na nowym <i>poppler</i>. Niestety to się nie udawało. Cofnięcie <i>poppler</i> do wersji z okresu, w którym wyszły <i>cups-filters</i> nawet nie należało rozważać, albowiem pociągałoby to za sobą konieczność przebudowy znacznej ilości paczek (lub również ich cofnięcia), które muszą być budowane na określonej wersji <i>poppler</i>.<br />
Zatem totalny pat.<br />
Problem jednakże przeleciał różne fora, listy mailingowe. Proponowane rozwiązanie sprowadzało się do edycji pliku PPD i w zależności od porad bądź to usunięciu wszystkich deklaracji ze słowem "Custom" bądź jego zastąpienia słowem "Other'. W części przypadków rozwiązanie takie działało, ale w części drukarka nadal niczego nie była w stanie wydrukować. <br />
Ostatecznie pojawiła się łatka w CUPS, która wejdzie do wersji 2.3.1. Wraz z zespołem POLAUR i kolegów z naszego IRC udało się nam stworzyć PKGBUILD, który buduje <i>cups</i> oraz <i>libcups</i> z nałożoną łatką. CUPS działa prawidłowo, pozwala na instalację drukarek z "wadliwym" PPD oraz drukowanie na nich dokumentów.<br />
PKGBUILD zmienionego <i>cups</i>, jest dostępny w POLAUR pod adresem: <a href="https://github.com/polaur/repo-refreshed/tree/master/cups"><br />
</a>.<br />
Można go zainstalować ściągając, czy kopiując w dowolny sposób zawartość wszystkich plików, które tam są, a następnie budując paczkę z pomocą makepkg.<br />
Prościej można to wykonać z zastosowaniem naszego pak:<br />
<blockquote>
pak -P repo-refreshed/cups</blockquote>
Jak zwykle w przypadku PKGBUILDów umieszczanych w repo-refreshed, paczka nosi taki numer wersji, który spowoduje jej aktualizację, w przypadku pojawienia się nowej wersji w repozytorium Archa. W takim przypadku - w zależności od wprowadzonych zmian - albo nie będzie zachodzić już konieczność dalszej opieki nad naszą wersją, albo zostanie udostępniona nowa wersja PKBGUILD. Proszę śledzić wątek na naszym forum: <a href="https://forum.archlinux.org.pl/viewtopic.php?id=615"></a>.<br />
<br />
<span style="font-size: x-small;">W rozwiązaniu problemu chciałbym podziękować naszym kolegom, głównie sir_lucjan oraz arch-jest-super.</span>pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com1tag:blogger.com,1999:blog-8431974948820046336.post-81903070031893974032019-10-11T23:31:00.000-07:002019-10-11T23:31:19.955-07:00Nadchodzi Qt5.14 - nadchodzą kłopotyW repozytorium <i>kde-unstable</i> pojawiła się pierwsza beta Qt 5.14. Wstępne problemy z niewłaściwym wyświetlaniem elementów Plazmy zostały opanowane (jeśli ktoś używa, to należy bezwzględnie zaktualizować system z uwzględnieniem najnowszej wersji qt5-svg 5.14.0beta1-2). Pozostał jeszcze jeden problem, który wymaga ręcznej ingerencji. Otóż w przypadku, gdy pojawia się ekran blokady SDDM wpisanie hasła powoduje wyłącznie ponowne pojawienie się tego ekranu. Na całe szczęście można przejść do TTY by przynajmniej wyłączyć poprawnie komputer. Można, ale można też łatwo problem rozwiązać. Należy wykasować <i>cache</i> SDDM:<br />
<blockquote># rm -r /var/lib/sddm/.cache</blockquote>i od tej chwili znów można się cieszyć normalną funkcjonalnością blokadą ekranu.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-61767258849285212902019-05-31T02:03:00.000-07:002019-05-31T10:12:11.879-07:00Oprogramowanie 4kdownload w POLAUROd pewnego czasu w POLAUR dostępne są aplikacje rozprowadzane przez <a href="https://www.4kdownload.com/">4kdownload.com</a>. Są one również dostępne w AUR, ale w nieco innej wersji. Zdecydowałem się na taki ruch, by nieco ułatwić życie osobom, które tego programu używają. Zanim przejdę do informacji o tym, jaka jest zasadnicza różnica między aplikacjami w POLAUR, a w AUR, muszę coś wytłumaczyć.<br />
Otóż oprogramowanie 4kdownload.com jest rozprowadzane na <a href="https://www.4kdownload.com/agreement/">licencjach EULA</a> i nie posiada otwartych źródeł. W przypadku wersji dla linuksa dostępne jest ono w dwu paczkach binarek, obu deklarowanych jako budowanych dla Ubuntu w wersji 64 bitowej. Sama aplikacja (dowolna) pochodząca z 4kdownload.com jest swego rodzaju graficzną nakładką na <a href="https://ffmpeg.org/">ffmpeg</a>, korzystając ze porzuconej już gałęzi tego oprogramowania w wersji 2.8. FFMpeg jest dostarczany na licencji GPL3.<br />
Twórcy aplikacji 4kdownload.com, przygotowując swoje paczki dla Ubuntu dostarczają w tych paczkach biblioteki ffmpeg2.8, przy czym gdzieś mają to, że w ten sposób naruszają licencję tego oprogramowania (mogą oczywiście je dostarczać, ale zgodnie z GPL3 nie mogą im zmienić licencji na własnościową, a tak należałoby traktować postanowienia licencji oprogramowania z 4kdownload.com oraz mają obowiązek dostarczać również źródła użytego oprogramowania na licencji GPL3, czego nie robią). Niemniej jednak, budowana statycznie paczka aplikacji 4kdownload.com z wykorzystaniem bibliotek ffmpeg2.8 wbudowanych w te paczki działa i w przeciwieństwie do paczek <a href="https://aur.archlinux.org/packages/ffmpeg2.8">ffmpeg2.8 budowanych z AUR</a> nie wymaga okresowego jej przebudowania.<br />
Zasadnicza różnica budowanych paczek z POLAUR i AUR jest zatem taka, że w AUR mamy PKGBUILDy dla aplikacji 4kdownload.com zawierające same GUI (same aplikacje), zaś ich zależnością jest ffmpeg2.8, które należy oddzielnie zbudować z AUR (co na niezbyt wydajnych maszynach może sporo trwać). W przypadku paczek budowanych z POLAUR otrzymujemy zawsze dwie paczki: zasadniczą aplikację pochodzącą z 4kdownload.com oraz dostarczane wraz z tą paczką ffmpeg2.8, które nazywa się 4k-ffmpeg i nie jest budowane ze źródeł, lecz jak całość "konwertowane" z paczki dla Ubuntu na paczkę pacmana. Paczki aplikacji oraz 4k-ffmpeg mają inne numery wersji, bowiem aplikacja 4kdownload.com jest dostarczana w bieżącej wersji udostępnianej przez twórców, zaś ffmpeg2.8 w wersji 2.8 (prawdopodobnie odpowiadającej 2.8.15, ale nawet mi się nie chce zbyt zajmować tym z jakich źródeł budowane są te biblioteki, które są dostarczane w paczkach 4kdownload.com). Taki sposób budowania paczek uniemożliwia ich instalację poprzez wydanie polecenia <i>makepkg -i </i>(a i <a href="https://github.com/polaur/new-branded/tree/master/polaur">polaur</a> sobie z tym nie poradzi; zob. aktualizację wpisu, albowiem obecnie nie ma problemu z instalacją tych paczek z pomocą polaur)<i>. </i><br />
Dlatego też budując paczki 4kdownload.com z POLAUR musimy postąpić nieco inaczej niż zazwyczaj.<br />
Przede wszystkim musimy dokonać ściągnięcia źródeł niezbędnych do budowy paczki. Źródła te muszą być w formie "plain" - czystego tekstu. Możemy skorzystać np. z wget, możemy dokonać sklonowania całego repozytorium, ale najprościej będzie skorzystać z aplikacji <b>polaur</b>.<br />
<blockquote class="tr_bq">
polaur -L</blockquote>
wybieramy cyfrę, przy której widnieje wpis <b>aur-rebased</b> (obecnie to 1), następnie <b>d</b>, a następnie cyfrę odpowiadającą paczce, którą chcemy zbudować z widocznej listy. Jeśli nie dokonamy żadnych zmian, to przechodzimy do katalogu z pobranymi źródłami:<br />
<blockquote class="tr_bq">
cd ~/.cache/polaur/aur-rebased/nazwa_paczki</blockquote>
wykonujemy budowanie paczek:<br />
<blockquote class="tr_bq">
makepkg -src</blockquote>
oraz instalujemy z pomocą pacmana:<br />
<blockquote class="tr_bq">
pacman -U *.pkg.*</blockquote>
Jeśli którakolwiek aplikacja z 4kdownload.com jest już zainstalowana w systemie z POLAUR i chcemy doinstalować inną aplikację tego twórcy również z POLAUR, to za pomocą pacmana należy wówczas zainstalować wyłącznie paczkę aplikacji, a nie grupę zbudowanych paczek (co robi ostatnie z poleceń), a zatem:<br />
<blockquote class="tr_bq">
pacman -U nazwa_paczki</blockquote>
<h3>
AKTUALIZACJA</h3>
Dzięki Damianowi, od dzisiaj dostępny jest nowy skrypt polaur. Zatem jeśli mamy go zainstalowany wystarczy:<br />
<blockquote class="tr_bq">
polaur -L</blockquote>
wybór repozytorium aur-rebased, wybór <b>b</b> i wskazanie cyfry programu, który nas interesuje.<br />
<br />
<span style="font-weight: normal;"><span style="font-size: x-small;">PS: Tekst powstał z uwagi na niesamowite trudności, jakie komuś sprawia zbudowanie 4kvideodownloader i dyskusji, która prowadzi na manowce, ze stwierdzeniem, że w Manjaro nie da się zbudować tych paczek. Da się "zbudować", bowiem nie polega to na budowaniu i da się zainstalować, choć Manjaro nie jest w żaden sposób przez POLAUR wspierane.</span></span>pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com3tag:blogger.com,1999:blog-8431974948820046336.post-24936633142767924042019-01-29T13:19:00.000-08:002019-01-29T13:19:05.316-08:00Przywracanie dotychczasowego wyglądu kickoff w Plasma 5.15Nadchodzące wydanie Plasma 5.15 powita użytkowników wyglądem Kickoff w "starym" stylu, przypominającym nieco to, co niektórzy być może pamiętają z czasów KDE4. Jest to wynik zaakceptowania <a href="https://bugs.kde.org/show_bug.cgi?id=397581">zgłoszonego "błędu"</a>, który rzekomo powodował, że nowi użytkownicy gubili się w dotychczasowym, domyślnym jego wyglądzie.<br />
Obecnie w Plasma 5.14.90, oraz w nadchodzącym wydaniu będzie on zatem wyglądał tak:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh07pNs-8sTNWRXhrzBQuBhPieoasf1_CiE4Yf3WUgacpxhoDHCtG-p3160QCu9Nf1G5xWUp2pOIAW_t2V3w2uzypUdicyyKwxI6j-Lf2K-B54rdRCKM3FKIlwGc9UpZkAHRNX_6Hsxk8bG/s1600/Screenshot_20190129_215703.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="613" data-original-width="439" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh07pNs-8sTNWRXhrzBQuBhPieoasf1_CiE4Yf3WUgacpxhoDHCtG-p3160QCu9Nf1G5xWUp2pOIAW_t2V3w2uzypUdicyyKwxI6j-Lf2K-B54rdRCKM3FKIlwGc9UpZkAHRNX_6Hsxk8bG/s320/Screenshot_20190129_215703.png" width="229" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
Może się to podobać, niekoniecznie musi. Być może w istocie dla osób, które mają problemy z czytaniem, dotychczasowy mechanizm "Type to search", o czym zresztą sam Kickoff oznajmiał będzie to sporym ułatwieniem. Niemniej jednak mi się to kompletnie nie podoba i według mnie psuje dotychczasowy, estetyczny wygląd Kickoff. Nie tylko mi jak się okazuje. Dlatego też <i>filipwise</i> postanowił zachować dotychczasowy wygląd i udostępnił go w sklepie KDE pn. <a href="https://store.kde.org/p/1274927/">Unibody Kickoff</a>. W obecnej wersji wystarczy dodać plasmoid mechanizmem GHNS, dokonać restartu Plazmy i ponownie cieszyć się starym, sprawdzonym wyglądem Kickoff:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7c4Qoc54HfvUdQKnNO3WnNoUGwPtfBxrrtgn1P2gJppfXvxcGBLwJrFt3vXvw2VGVZKkliWszmn2Tf6m-df5MXK4eonvz2kVkXdVb_1BeU-c1DBaIab2TD2XNJszP9PjzaMwRNigjRCTK/s1600/Screenshot_20190129_215729.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="619" data-original-width="435" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7c4Qoc54HfvUdQKnNO3WnNoUGwPtfBxrrtgn1P2gJppfXvxcGBLwJrFt3vXvw2VGVZKkliWszmn2Tf6m-df5MXK4eonvz2kVkXdVb_1BeU-c1DBaIab2TD2XNJszP9PjzaMwRNigjRCTK/s320/Screenshot_20190129_215729.png" width="224" /></a></div>
Przy okazji, kod dostępny jest na <a href="https://github.com/flipwise/unibody-kickoff">github</a>, zaś w POLAUR dodałem PKGBUILD umożliwiający budowę plasma-dekstop zachowującą stary wygląd (występuje jako <a href="https://github.com/polaur/pkg-trunk/tree/master/plasma-desktop-legacy">plasma-desktop-legacy</a>).<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-55568114943127737382019-01-28T04:58:00.001-08:002019-01-28T04:58:54.401-08:00Przyspieszamy aktualizację ArchaJednym ze sposobów przyspieszenia aktualizacji oraz zmniejszenia wielkości danych ściąganych przy tej okazji z internetu jest użycie tzw. <a href="https://wiki.archlinux.org/index.php/Deltup">delta upgrade</a>. Niestety nie wszystkie serwery to oferują. Znając taki serwer można się jednak pokusić o wprowadzenie odpowiednich zmian.<br />
<br />
Przede wszystkim zaczynamy od serwera. W tej chwili znam jedynie takie <a href="https://www.archlinux.org/mirrors/allworldit.com/">dwa</a>, w tym jeden z dalekiego RPA. Zasadniczym krokiem jest zmiana pliku <i>/etc/pacman.d/mirrorlist</i> i dodanie na pierwszym miejscu serwera oferującego delta upgrades. Posiłkując się listą z powyższego odnośnika dodajemy zatem:<br />
<br />
<blockquote class="tr_bq">
<span style="color: #222222; font-size: 1em;">Server = http://archlinux.uk.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch</span></blockquote>
Można też dodać drugi serwer z RPA:<br />
<blockquote class="tr_bq">
<span style="color: #222222; font-size: 1em;">Server = http://archlinux.za.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch</span> </blockquote>
Dokonujemy zmian w pliku <i>/etc/pacman.conf </i>poprzez:<br />
1. usunięcie znaku <i>#</i> sprzed:<br />
- w sekcji [options]<br />
<blockquote class="tr_bq">
#UseDelta = 0.7</blockquote>
- w sekcji #Misc options<br />
<blockquote class="tr_bq">
#UseDelta</blockquote>
2. instalujemy paczkę <i>xdelta3</i><br />
I... w zasadzie cieszymy się nową funkcjonalnością.<br />
Niestety powyższe serwery nie oferują <i>delta upgrades</i> dla repozytoriów core, <i>extra </i>i <i>community. </i>Jeśli zatem korzystamy z innych repozytoriów musimy wprowadzić nieco inne zmiany. Plik <i>/etc/pacman.d/mirrorlist </i>pozostawiamy bez zmian. Dokonujemy edycji wyłącznie pliku <i>/etc/pacman.conf</i> i w sekcjach odpowiadających za repozytoria <i>core, extra, community</i> wprowadzamy powyżej istniejącego tam wpisu:<br />
<blockquote class="tr_bq">
Include = /etc/pacman.d/mirrorlist</blockquote>
wpis:<br />
<blockquote class="tr_bq">
Server = http://archlinux.uk.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch</blockquote>
Przy następnych aktualizacjach czy instalacjach powinniśmy odczuć zarówno szybszą instalację, jak i powinno pobierać się mniej informacji. To ostatnie szczególnie winno zadowolić posiadaczy łącz o limitowanej transmisji danych.<br />
Powyższe rozwiązanie ma jednak wadę, albowiem w żaden automatyczny sposób nie sprawdzimy czy serwer ten jest na bieżąco synchronizowany z głównym repozytorium Archa.<br />
<br />
Więcej na temat powyższych serwerów znajdziecie <a href="https://bbs.archlinux.org/viewtopic.php?id=243247">w wątku na BBS Archa</a>.<br />
<br />
<blockquote class="tr_bq">
</blockquote>
pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-77184790992533678012019-01-23T06:27:00.001-08:002019-01-23T06:27:48.626-08:00Konfiguracja gładzika w Plasma WaylandW sesji Plasma Wayland, za obsługę gładzika (tochpad) odpowiada libinput. Z <a href="https://wiki.archlinux.org/index.php/Libinput#Configuration">wiki Archa</a> dowiedzieć się możemy, że biblioteka ta w tej sesji nie posiada żadnych ustawień (z linii poleceń, pliku konfiguracyjnego), a całość obsługi tego urządzenia możemy przeprowadzić z narzędzi konfigurujących dostarczanych wraz ze środowiskiem.<br />
W przypadku Plazmy, takie narzędzie jest dostarczane i od wielu lat znajdziemy je pośród ustawień Urządzeń wejściowych w Ustawieniach systemowych. Dla wielu osób sporym zaskoczeniem może być jednak wejście w te ustawienia w Plazmie uruchomionej w sesji Wayland. Całość ustawień będzie poszarzała i żadne ustawienia nie będą dostępne. Błąd? Oczywiście. Jest nawet <a href="https://bugs.kde.org/show_bug.cgi?id=395351">zgłoszony</a> (a to jedno z kilku).<br />
Co ciekawe jednak wszelkie ustawienia gładzika są dostępne także w sesji Wayland. Trzeba jedynie moduł zarządzania tymi ustawieniami wywołać z konsoli:<br />
<blockquote class="tr_bq">
kcmshell5 kcm_touchpad</blockquote>
Korzystając z ustawień gładzika w taki sposób wszelkie opcje będą dostępne.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-32668330016797200392018-12-12T02:39:00.004-08:002019-01-04T05:58:07.061-08:00Firefox 64 i okna KDEUżytkownicy KDE od dosyć dawna narzekają na to, że aplikacje oparte o Gtk mają własne okna dialogowe. Mniejsza o to, które są "lepsze", a które "gorsze". To kwestia pewnych przyzwyczajeń. Jeśli 99% aplikacji zachowuje się w określony sposób, to ciężko przestawia się na inne zachowanie pozostałego procenta aplikacji. Zwłaszcza, że są to często wykonywane operacje, które "wchodzą" użytkownikowi w krew.<br />
Śpieszę zatem donieść, że przynajmniej Firefox w wersji 64 da się zmusić do używania natywnych okien KDE przy otwieraniu plików, czy też zapisywaniu pobieranych przez tę przeglądarkę treści. Ponoć prezentowana tu sztuczka działa również z niektórymi programami. Ponoć również, niektórym nie działa w ogóle (tu mam jednak wątpliwości, czy zostały spełnione wszystkie elementy, które umożliwiają takie zachowanie Firefox w Plasma).<br />
<br />
Wpierw musimy odpowiednio przygotować nasz system, w którym muszą być zainstalowane następujące paczki:<br />
<br />
<ol>
<li>firefox >=64.0</li>
<li>xdg-desktop-portal</li>
<li>xdg-desktop-portal-kde</li>
</ol>
<br />
W następnej kolejności musimy poinformować aplikacje Gtk (tu Firefox), aby używał okien natywnych KDE poprzez uruchomienie zmiennej:<br />
<blockquote class="tr_bq">
GTK_USE_PORTAL=1</blockquote>
Możemy to oczywiście zrobić globalnie dla wszystkich aplikacji, możemy z takim parametrem wywołać Firefox. Osobiście dodałem eksport tej zmiennej do pliku <i>~/.xprofile</i> i jak na razie Firefox zachowuje się zgodnie z oczekiwaniami, a nie dostrzegam jakichś innych, niepożądanych problemów.<br />
Stosowny plik winien zatem zawierać wpis:<br />
<blockquote class="tr_bq">
export GTK_USE_PORTAL=1</blockquote>
<br />
(SUPLEMENT)<br />
Powyższe rozwiązanie jest właściwe jednakże wyłącznie dla Plasma pracującej w sesji Xów. Plasma-Wayland nie "odczyta" ~/.xprofile. W tym przypadku, teoretycznie (dlaczego "teoretycznie" o tym za chwilę) powinniśmy dokonać edycji pliku <span style="background-color: #ebf1f5; color: #222222; white-space: pre-wrap;"><i>~/.config/environment.d/envvars.conf </i>i tutaj dodać</span><span style="color: #222222;"><span style="white-space: pre-wrap;">:</span></span><br />
<blockquote class="tr_bq">
<span style="color: #222222;"><span style="white-space: pre-wrap;">GTK_USE_PORTAL=1</span></span></blockquote>
W zasadzie tego typu rozwiązanie winno umożliwić również pracę z natywnymi oknami dialogowymi Plasmy w Firefox także w sesji Wayland.<br />
<br />
Napisałem wcześniej "teoretycznie", gdyż - znów teoretycznie dla Xów moglibyśmy stosowny wpis dodać do <i>~/.xinitrc</i>. Sprawdzałem - niekoniecznie to chce działać. I to nie tylko w moim przypadku. <a href="https://www.reddit.com/r/kde/comments/a5cxwk/firefox_v64_can_now_use_the_kde_file_selection/ebmemp1/">W sieci pojawiają się też pomysły na rozwiązanie sprawy poprzez stworzenie pliku firefox.desktop</a> dla danego użytkownika i dodanie odpowiednich wpisów. Znów -powiem: u mnie nie bardzo chce to działać i trudno mi powiedzieć dlaczego.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com1tag:blogger.com,1999:blog-8431974948820046336.post-71027841189415229242018-12-09T12:45:00.002-08:002019-08-18T14:23:13.159-07:00POLAUR - paczki KDE z łatkamiOd dłuższego czasu w POLAUR, w repozytorium repo-refreshed umieszczam PKGBUILDy dla różnych składników oprogramowania pochodzącego od KDE z tzw. bugfiksami. W największej części są to te, które były zgłaszane w <a href="https://bugs.kde.org/" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">bugs.kde.org</a>.<br />
Stosowane są przeze mnie (i jeśli ktoś chciałby również się dołączyć, to również prosiłbym o ich stosowanie) następujące zasady:<br />
<div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>1. Numeracja paczek</strong><br />
a. Paczki zawsze mają numer wersji (pkgver) takie jak paczka źródłowa, na którą patch jest nakładany.<br />
b. Paczki różnią się wersją "realizacji" (pkgrel), przy czym numer ten jest zawsze wyższy niż wersja w repozytorium, ale zawsze też niższy od wersji, która w repozytorium może się pojawić (np. wskutek koniecznego jej przebudowania ze względu na zmiany innych elementów, tego wymagających). Kolejne wersje z patchami mają zawsze nowy numer pkgrel z zachowaniem powyższej zasady.<br />
<span class="bbu" style="text-decoration-line: underline;">Przykład:</span></div><ul><li>jeśli paczka w repozytorium Archa ma numer np. 5.53.0-1, to pierwszy PKGBUILD z patchem będzie miał wersję 5.53.0-1.1, następny 5.53.0-1.2 itd.</li>
</ul>Taki sposób umożliwia aktualizację do wersji z repozytorium Archa, gdy nowe wersje paczek (także pkgrel) się pojawią.<br />
<div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><em>UWAGA: może się zdarzyć, że będzie tu jakiś "przeskok" wersji np. po pkgrel x-1.1 będzie x-1.3, a gdzieś "zgubiona" zostanie wersja x-1.2; proszę się nie obawiać, wynika to wyłącznie z faktu, że prawdopodobnie u siebie z jakichś przyczyn przebudowałem w międzyczasie paczkę i ona uzyskała "brakującą" numerację.</em></div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;">c. Jeśli w repozytorium Archa pojawi się nowa wersja paczki, która naprawia ten sam błąd, który wcześniej został poprawiony przeze mnie w PKGBUILDzie w POLAUR, to taki PKGBUILD jest z niego usuwany.<br />
d. Jeśli w repozytorium Archa pojawi się nowa wersja paczki, ale nie zawiera patchy, które wcześniej udostępniłem, to w POLAUR pojawi się nowa wersja paczki dostosowana do aktualnej numeracji wersji w repozytorium Archa z zachowaniem reguły z pkt. 1 a i b.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>Patche</strong><br />
a. Patche pochodzą z repozytorium <a href="https://cgit.kde.org/" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">GIT KDE</a>. Mogą pochodzić także z <a href="https://phabricator.kde.org/" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">phabricator.kde.org</a>. W każdym przypadku, podczas budowania paczki jesteście powiadamiani o tym jaki patch zostaje nałożony zgodnie z następującymi zasadami:<br />
- patch odnoszący się do bugs.kde.org oznaczony jest przez "KDEBUG numer_zgłoszenia"; jeśli patch naprawia więcej niż jedno zgłoszenie, najczęściej są podawane wszystkie, choć sama łatka może być jedna,<br />
- inne patche są oznakowane "Dnumer_phabricator".<br />
W pierwszym przypadku przeglądnąć tak zgłoszenie, jak i sam patch można poprzez wpisanie "numer_zgłoszenia" na stronie <a href="https://bugs.kde.org/" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">bugs.kde.org</a>. W drugim przypadku przez wpisanie Dnumer_phabricator na stronie <a href="https://phabricator.kde.org/" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">phabricator.kde.org</a>.<br />
- w nielicznych przypadkach stosuję opisowe oznaczenie łatki (jeśli - co niezmiernie rzadkie - nie będzie ona miała swojego odzwierciedlenia ani w bugs.kde.org ani w phabricator.kde.org).</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>Informacje o patchach</strong><br />
Podczas budowy paczek jesteście powiadamiani o tym jaki patch jest nakładany oraz - o ile wiem - w jakiej wersji oczekiwana jest jego implementacja. Ostatnią zasadę - tak wyraźną - wprowadziłem w tym tygodniu, a zatem nie wszystkie PKGBUILDy zostały jeszcze do tego dostosowane. Jeśli nie wiem w jakiej wersji zostanie patch uwzględniony, niekiedy opisuję to w PKGBUILDzie (kiedy jest spodziewany). Stosowna informacja podczas kompilacji paczki wygląda np. tak:<br />
<blockquote class="tr_bq">Add KDEBUG 123123 patch; fix in 5.15.0</blockquote></div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;">Oczywiście w ten sam sposób jest to opisane w PKGBUILDzie. W starszych wersjach opis odnoszący się do tego w jakiej wersji oczekiwane jest wdrożenie patcha występuje wyłącznie w PKGBUILDzie.<br />
Również z moich <a href="https://forum.archlinux.org.pl/viewtopic.php?id=615" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">ogłoszeniach</a> na forum pojawia się informacja o tym jakie łatki zostały uwzględnione. Przed budową paczki możecie sobie ocenić, czy warto.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>Konieczność budowy wszystkich paczek z POLAUR</strong><br />
Krótko: nie istnieje. Możecie budować wybrane. Jeśli będzie taka okoliczność istnieć to PKGBUILD zostanie tak przygotowany, że uniemożliwi budowę paczki, jeśli inny pakiet z POLAUR nie jest zbudowany i zainstalowany. Informacja o tym pojawi się również w <a href="https://forum.archlinux.org.pl/viewtopic.php?id=615" rel="nofollow" style="color: #2365b0; text-decoration-line: none;">ogłoszeniach</a>.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>Częstotliwość ukazywania się</strong><br />
Staram się dodawać łatki na bieżąco. Zwykle tuż przed pojawieniem się nowej wersji nie dodaję już nowych łatek do POLAUR. Mogłoby się tak zdarzyć wyjątkowo, gdyby błąd był poważny, a arojas z jakiegoś powodu nie zareagował.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>Rodzaje łatanych błędów</strong><br />
Staram się dodawać patche tylko na poważniejsze błędy. Moim zdaniem szkoda męczyć komputer tylko dlatego, że w kolejnym wydaniu np. jakieś okno będzie ładniej wyglądało. Jeśli ktoś jednak i takie łatki chciałby mieć nałożone - proszę zgłaszać w odpowiednim miejscu. Niektóre jednak z tego typu łatek powędrują do repozytorium pkg-trunk.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;"><strong>Testowanie paczek z nałożonymi łatkami</strong><br />
Wszystkie paczki są przeze mnie budowane i testowane. Bugfiksy z <a href="https://bugs.kde.org/">bugs.kde.org</a> przechodzą też testy deweloperskie. Bugfiksy z <a href="https://phabricator.kde.org/">phabricator.kde.org</a> również, ale mogą one nie być przetestowane przez deweloperów tak wnikliwie. Są one jednak zawsze przez nich zaakceptowane.<br />
Proszę jednakże zwrócić uwagę na to jaki ja mam system (jest zawsze w stopce), jakich repozytoriów używam oraz, że... mam jeden komputer. Nie mam zatem możliwości sprawdzenia jak się zachowuje taka paczka na każdej, możliwej konfiguracji sprzętowej.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;">W razie wątpliwości - wiecie gdzie mnie szukać.</div><div style="border: 0px; font-family: Verdana, Arial, Helvetica, sans-serif; padding: 7px 0px;">PS: <strong>UWAGA - O ile paczki z POLAUR nadają się dla Archa oraz jego bezpośrednich forków /czyt. takich, które korzystają z jego repozytoriów bezpośrednio/ to najprawdopodobniej nie będą właściwe dla Manjaro - proszę ich tu nie używać</strong>. Nie udzielam też absolutnie <strong>żadnego</strong> wsparcia użytkownikom Manjaro, którzy zbudują sobie paczki na podstawie moich PKGBUILDów.</div></div><div class="postsignature postmsg" style="border: 0px; color: #566579; font-size: 0.923em; margin: 0px; overflow-wrap: break-word; overflow: hidden; padding: 0px; width: 782px;"><br />
</div>pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-11140223950808705782018-12-04T12:05:00.000-08:002018-12-04T12:05:03.443-08:00Na prostej drodze do wysypania ManjaroDo napisania dzisiejszego wpisu zainspirował mnie jeden z <a href="https://manjaro.pl/forum/topic/blad-aktualizacji-spotify/">wątków na forum manjaro.pl</a>. 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 <a href="https://aur.archlinux.org/packages/spotify/">PKGBUILDu</a> 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.<br />
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.<br />
Inny forumowicz poleca zatem... dodanie repozytorium <a href="https://wiki.archlinux.org/index.php/Unofficial_user_repositories#nexus">nexus</a> do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.<br />
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, że przecież aktualną paczkę spotify dało się rozpakować i "działa jak portable".<br />
<br />
I w takim momencie ręce opadają.<br />
<br />
Po pierwsze - o ile istnieje jakaś możliwość w dodawaniu <a href="https://wiki.archlinux.org/index.php/Unofficial_user_repositories">repozytoriów nieoficjalnych</a> do Archa, albowiem są one budowane w oparciu o paczki z Archa, to dodawanie takiego repozytorium do Manjaro, szczególnie w wersji "stable" jest proszeniem się o kłopoty. To nic, że dodana paczka może nie pracować, ale doprowadzić to również może do podmiany paczek, które dostarczane są wraz z Manjaro i zbudowane (mam nadzieję) w oparciu o paczki dostępne w tej dystrybucji przez paczki z innej. Wiadomo również, że paczki udostępniane w repozytorium stable Manjaro są w stosunku do Archa opóźnione o jakiś czas (różny). Można oczywiście twierdzić, że przy rozważnym "gospodarowaniu" takim systemem z pomieszanymi repozytoriami nic się nie stanie. Problem jednakże w tym, że skoro jeden użytkownik innemu radzi bez zająknięcia tego typu operację, to oznacza wyłącznie, że poziom świadomości na temat używanego systemu niekoniecznie musi być wysoki.<br />
<br />
Po drugie - wprowadzanie do systemu obcych paczek przez ich rozpakowanie (mniejsza o to, czy to deb, czy rpm - bo to najczęściej stosowane "porady"). Dokonując prostego rozpakowania (ar) paczki deb, bądź też stosując do tego dpkg lub rpm (są takie kretyńskie porady dostępne w sieci) nie mamy żadnego wpływu na to jak one zostaną rozpakowane. Jeśli taka paczka zawiera jakiś plik o takiej samej nazwie i w takiej samej lokalizacji, jaką już mamy w systemie, to rozpakowane w ten sposób paczki deb, czy rpm po prostu dokonają nadpisania paczki systemowej przez tę, która z niej pochodzi. Zwróćmy teraz uwagę, że szczególnie paczki deb są bardzo często budowane w oparciu o bardzo stare komponenty w stosunku do tych, które są w Archu, czy nawet w Manjaro. Czym ryzykujemy - pomijam już inne kwestie i aby skrócić wpis napiszę wyłącznie - ot, choćby tym, że po "udanej" instalacji takiej paczki możemy być bardzo krótko zadowoleni. Do zrestartowania systemu, który może się już w ogóle nie obudzić.<br />
<br />
Będę to powtarzać jak mantrę, bo jak widzę roztropności w narodzie brak: <b>do instalacji jakichkolwiek programów w Archu (i pochodnych) służy wyłącznie pacman. Jeśli paczki nie ma należy ją zbudować na podstawie odpowiednio napisanego PKGBUILD</b>u (są nawet miejsca, gdzie można zgłaszać zapotrzebowanie). Każde inne działanie jest działaniem przeciwko własnemu systemowi. Nie liczcie, że potem ktokolwiek będzie Wam w stanie pomóc. Jedyne wyjątki od tej reguły, to instalacja paczek w tzw. uniwersalnych formatach.<br />
<br />
A najśmieszniejsze (o ile w ogóle komukolwiek do śmiechu) jest to, że napisanie poprawnego PKGBUILDu instalującego nową wersję spotify nie trwa dłużej niż kilkadziesiąt sekund.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-23739742749735757812018-11-09T23:40:00.001-08:002018-11-09T23:40:45.276-08:00A jak aliasWielu użytkowników linuksa narzeka na straszliwą konieczność pracy w konsoli. Na to, że wszystko tu trzeba wpisywać itd. itp. i bez tego ani rusz, a polecenia konsolowe to katorga dla "normalnego" człowieka. I kto by spamiętał to wszystko.<br />
Pomijam prawdziwość twierdzenia o konieczności wpisywania wszystkiego w konsoli. Obecne środowiska graficzne i programy dla nich, oferują spore możliwości praktycznie kompletnego pominięcia używania poleceń konsolowych. Niemniej jednak z różnych przyczyn może okazać się, że korzystanie z konsoli dla określonych zastosowań jest albo jedyną możliwością, albo po prostu bywa wygodniejsze.<br />
<br />
Niemniej jednak sam zauważam, że niektóre polecenia są zbyt długie, by je spamiętać. Ot, choćby:<br />
<blockquote class="tr_bq">
# reflector --verbose --country 'Poland' -l 5 -p http --sort rate --save /etc/pacman.d/mirrorlist</blockquote>
Oszczędźmy naszą pamięć. Z pomocą przychodzi nam "alias", dzięki któremu w swoim środowisku możemy przyporządkować w zasadzie dowolne ciągi znaków pod łatwiejszą do zapamiętania nazwę, w dodatku łatwo zawsze dostępną. Jeśli nie zdarzy się kataklizm, sami nie skasujemy takiego aliasu, to raz zdefiniowane będzie funkcjonować wiecznie.<br />
Zamiast zatem ww. ciągu możemy wstawić dowolną inną nazwę, np. <i>mirror</i> (to wyłącznie przykład). Wówczas po wpisaniu w konsoli wyrazu: <i>mirror</i>, system (a w zasadzie, to bash), sam podporządkuje przypisane mu polecenie i je wykona.<br />
Jak to zrobić?<br />
<br />
Zaczynamy od otwarcia w dowolnym edytorze tekstu plik <i>~/.bashrc </i>(jeśli korzystamy z bash) i dopisujemy ciąg, który ma postać:<br />
<blockquote class="tr_bq">
alias nazwa='polecenie'</blockquote>
Opierając się na przywołanym poleceniu reflectora, będzie to wyglądać następująco:<br />
<blockquote class="tr_bq">
alias mirror='sudo reflector --verbose --country 'Poland' -l 5 -p http --sort rate --save /etc/pacman.d/mirrorlist'</blockquote>
które po wpisaniu w konsoli polecenia: <i>mirror</i> - podmieni nam listę serwerów źródlanych udostępnionych w systemie na taką, która jest ograniczona do pięciu najbardziej aktualnych polskich serwerów (akurat pięciu serwerów w Polsce nie ma) i posortuje je w kolejności od oferowanej najwyższej szybkości transferu.<br />
<br />
Poprzedzające polecenie <i>reflector</i>, <i>sudo</i> pojawia się tutaj, z uwagi na to, że winno ono zostać wykonane z uprawnieniami administratora. Jeśli jakieś polecenie tego nie wymaga, to oczywiście je pomijamy.<br />
<br />
Po zapisaniu pliku <i>.bashrc</i> musimy jeszcze poinformować bash o wprowadzeniu zmian, co zrobimy poprzez wydanie w konsoli polecenia:<br />
<blockquote class="tr_bq">
source ~/.bashrc</blockquote>
W przeciwnym przypadku będzie ono dostępne dopiero od następnej sesji.<br />
<br />
Jak nam się polecenie znudzi, bądź uznamy, że inne będzie dla nas łatwiejsze do zapamiętania, to po prostu zmienimy alias w <i>~/.bashrc</i>.<br />
<br />
Zwracam jednak uwagę na jedną rzecz. Aliasem można zmienić domyślne działanie polecenia, o czym system nas nie poinformuje. Dla przykładu, jeśli z jakiegoś powodu chcielibyśmy dać taki alias:<br />
<blockquote class="tr_bq">
alias ls='sudo pacman -Syu'</blockquote>
to "stracimy" w systemie polecenie ls, a w jego miejsce pojawi się komenda, która zaktualizuje nam system. Z drugiej strony, w ten sposób możemy zmodyfikować domyślne działanie jakiegoś polecenia, o ile nam na tym zależy, czyli dla przykładu dodać kolorowanie do wyników poleceń (bo to akurat bezpieczne - nie zmieni nam działania programu, a jedynie uczyni go czytelniejszym).<br />
<br />
Tak czy inaczej - ostrożności nigdy za wiele.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-74095923745476676092018-11-09T08:41:00.001-08:002018-12-10T07:33:10.615-08:00Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacjiPośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?<br />
<br />
1. <b>Synchronizacja repozytoriów dla zabawy</b><br />
Zdarzyło się Wam wydać polecenie <i>pacman -Sy</i> bądź <i>pacman -Syy</i>, a za jakiś czas instalować program poprzez <i>pacman -S</i>? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.<br />
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.<br />
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekazywane są pacmanowi.<br />
Otóż zakładając, że paczki w repozytoriach budowane są prawidłowo, a nie mamy żadnej podstawy twierdzić inaczej, to w danym momencie, w repozytorium, które jest w 100% zsynchronizowane z głównym repozytorium Archa są paczki, które zostały zbudowane na podstawie swoich zależności, które są wymagane do poprawnej ich pracy. Z drugiej strony paczki - jeśli to nie jest bezwzględnie wymagane - nie zawierają informacji o tym w jakiej wersji ma być jakaś paczka, od której są zależne. Taka informacja nie jest też przekazywana pacmanowi w żaden sposób.<br />
Jeśli zatem wykonamy czynności, jakie opisałem na wstępie, to może się zdarzyć, że zostanie zainstalowana paczka w wersji, która wymaga swojej zależności również w określonej wersji. Jeśli owa zależność w systemie będzie już zainstalowana, to nie zostanie zaktualizowana. Efekt łatwy do przewidzenia - system będzie działać wadliwie.<br />
<br />
Prawidłowo zatem w każdym przypadku:<br />
<blockquote class="tr_bq">
pacman -Syu</blockquote>
<br />
2. <b>Instalacja paczki bez aktualizacji systemu</b><br />
Przeczytawszy poprzedni punkt już chyba wszystko wiadomo - instalacja paczki poprzez:<br />
<blockquote class="tr_bq">
<i>pacman -S paczka</i></blockquote>
nie ma żadnego sensu. Albo operacja taka się nie uda, albo wywoła skutek jak poprzednio, czyli dopuścimy się częściowej, a niewspieranej, aktualizacji systemu przy okazji instalacji jakiejś paczki. Oczywiście w niektórych przypadkach może się zdarzyć, że wszystko przebiegnie prawidłowo. To jednak przypadek.<br />
Zasadniczo w opisany wyżej sposób można instalować paczkę, jeśli jesteśmy pewni, że od ostatniej synchronizacji baz pacmana z repozytorium oraz aktualizacji systemu w repozytoriach nie pojawiły się nowe wersje paczek, które mamy już zainstalowane w systemie. Zdecydowanie lepszym sposobem, a już zawsze, gdy dość dawno nie dokonywaliśmy aktualizacji systemu jest:<br />
<blockquote class="tr_bq">
pacman -Syu paczka</blockquote>
<br />
3. <b>Aktualna lista serwerów źródłowych</b><br />
No właśnie, pacman wypisuje różne komunikaty, a bardzo często pozostają one bez żadnej reakcji. Zadowalamy się, że "aktualizacja się powiodła". W zakresie opisywanym jeden z częściej popełnianych błędów jest związany z aktualizowaniem paczki pacman-mirrorlist. Ta paczka jest <a href="https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/pacman-mirrorlist">dość często aktualizowana</a> i przynosi ze sobą wyłącznie jeden plik <i>mirrolist</i>, który zawiera aktualną na dzień wydania listę serwerów źródlanych Archa. Jeśli jednak w systemie istnieje już plik <i>/etc/pacman.d/mirrorlist</i>, to aktualizacja tej paczki powoduje jedynie wgranie do tej lokalizacji nowej listy, ale pod nazwą <i>mirrorlist.pacnew</i>, który to plik oczywiście nie jest "czytany" przez pacman podczas aktualizacji systemu. Jeśli zatem nie dokonamy zmiany nazwy tego pliku na <i>mirrorlist</i> to system nadal będzie się "aktualizował" z serwerów źródlanych, które mogą nie być już aktualne. Pamiętajmy przy tym, że pacman "czyta" listę udostępnionych mu serwerów w kolejności wskazanej w pliku <i>/etc/pacman.d/mirrorlist</i> i po nawiązaniu udanego połączenia z pierwszym serwerem z listy "zadowala się" nim i to z niego następuje aktualizacja, nawet jeśli serwery umieszczone poniżej są aktualniejsze.<br />
Pamiętajmy również, że sama zmiana nazwy <i>mirrorlist.pacnew</i> na <i>mirrorlist</i> nic nie da albowiem wszelkie serwery na tej liście są zakomentowane. Musimy usunąć znak "#" sprzed nazwy <i>Server.</i><br />
Osobiście dla odnawiania listy serwerów stosuję jednak program <a href="https://wiki.archlinux.org/index.php/Reflector">reflector</a> z taką listą poleceń:<br />
<blockquote class="tr_bq">
<span style="font-family: monospace;"><span style="background-color: white;">reflector --verbose --latest 5 --sort rate --save /etc/pacman.d/mirrorlist</span></span></blockquote>
W ten sposób dostarczanych mi jest do systemu pięć najświeższych serwerów posegregowanych od tego, który spośród nich oferuje najszybszy transfer do najwolniejszego. Oczywiście można sobie zrobić dla takiej komendy jakiś alias, bo będzie wygodniej.<br />
Oczywiście to nie jedyne sposoby, gdyż z pierwszej <a href="https://archlinux.org/">strony Archa</a> w sekcji Tools możemy znaleźć przydatne narzędzia do sprawdzania i generowania listy serwerów, a nadto są inne jeszcze narzędzia od reflectora.<br />
<br />
4. <b>Bezsensowne ignorowanie aktualizacji paczek</b><br />
Dość częstą praktyką jest dodawanie do <i>pacman.conf</i> jakichś paczek, bo nam się wydaje, że lepiej będzie tak działać. Oczywiście, że można, ba nawet niekiedy trzeba, ale... Zwróćmy uwagę na to jak są budowane paczki w Archu. W danym momencie, w repozytorium winny znajdować się paczki, które umożliwiają poprawną pracę w tym systemie. Oznacza to m.in., że te, które ze względu na jakieś swoje zależności wymagają przebudowania, zostały przebudowane po wprowadzeniu do repozytoriów nowej wersji swej zależności. Jeśli zatem z jakiegoś powodu do <i>IgnorePkg</i> dodamy którąkolwiek z tych paczek, to jesteśmy na dobrej drodze do spowodowania, że system będzie działać wadliwie. Jeśli zatem już umieszczamy coś w <i>IgnorePkg</i> to róbmy to z głową i na pewno nie umieszczajmy tu niczego ze względu na jakąś paczkę budowaną z AUR. To paczka z AUR ma być dostosowana do paczek systemowych, a nie odwrotnie.<br />
<br />
Krótko mówiąc - można wszystko, ale róbmy to z głową.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-71689980291571879022018-10-04T01:07:00.004-07:002018-10-04T01:07:40.522-07:00Jak uniknąć problemów z Antergosem<span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Przyglądając się problemom, jakie dostarcza Antergos wielu użytkownikom od kilku lat, spróbuję zestawić w punktach kilka porad, które zminimalizują najczęściej występujące z nim kłopoty.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;"><b>1. Usunięcie plików *-meta.</b></span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Niemal wszystkie instalacje (pierwsze) Antergosa odbywają się z użyciem tzw. meta paczek. To jeden ze sposobów instalacji zespołu większej ilości programów w Archu. Meta paczki nie zawierają żadnych binarek. Są to jedynie paczki niosące informacje o tym, że jakieś paczki mają zostać w systemie zainstalowane. Treść PKGBUILDów takich paczek zawiera w polu depends listę paczek do zainstalowania. Taka instalacja powoduje, że późniejsza próba odinstalowania jednej z paczek umieszczonych w depends pociągnąć za sobą może chęć odinstalowania "połowy" systemu, albo spotkamy się z informacją o tym, że odinstalowanie czegoś nie jest możliwe.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><strong style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Rozwiązanie</strong><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Po zainstalowaniu Antergosa, przeszukujemy system pod kątem zainstalowanych paczek z "meta" w nazwie. Ich nazwy wyglądają w następujący sposób "nazwa_czegoś-meta-dalsza_charakterystyka_paczki", ot choćby - instalując całą Plasmę w ten sposób mamy paczkę "plasma-meta".</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Wyszukujemy u siebie:</span><br />
<code class="bbc_code" style="background: rgb(255, 255, 255); border-bottom: 2px solid rgb(153, 153, 153); border-top: 2px solid rgb(153, 153, 153); color: #444444; display: block; font-family: "dejavu sans mono", monaco, "lucida console", "courier new", monospace; font-size: x-small; line-height: 1.5em; max-height: 24em; overflow: auto; padding: 3px 1em; white-space: nowrap;">pacman -Qs meta</code><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Teraz odinstalować należy każdą z tak znalezionych paczek.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><strong style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Uwaga</strong><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">W ten sposób pozbywamy się nałożonego nam kagańca, ale z drugiej strony istnieje łatwość odinstalowania paczek niezbędnych systemowi. O ile odinstalowanie jakiejś aplikacji, która wcześniej była w pliku "meta" nie stanowi już problemu i nie zrobi w systemie niczego złego, to już nad odinstalowaniem komponentów środowiska należy się zastanowić dwa razy i w razie wątpliwości spytać.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;"><b>2. LightDM</b></span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Antergos używa LigthDM jako menedżer logowania. Wymyślony niegdyś w Canonical DM nie jest obecnie intensywnie rozwijany (Ubuntu i pochodne z niego zrezygnowały), co powoduje, że niekiedy możemy się spotkać z problemami po aktualizacjach systemu (nie oznacza to, że z innym DM nie będzie). Dodatkowo LigthDM uniemożliwia sesję w Wayland tych DE, które już mają taką możliwość (np. GNOME, Plasma). Problematyczny jest również jego oparty o technologię webową greeter. Możecie zatem rozważyć sobie zmianę tego DM na inny. Jedyna zaleta, to efekt estetyczny dla domyślnych tematów środowisk wspieranych przez Antergosa.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Proponuję dla środowisk:</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">a. GNOME - GDM</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">b. Plasma, LXQt (inne oparte o Qt5, jak choćby Lumina) - SDDM</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">c. Xfce4, MATE, Cinnamon (inne oparte na Gtk) - LXDM</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Zmiana odbywa się w kilku ruchach:</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">1. Należy znaleźć odpowiedni DM w repozytorium i go zainstalować w systemie np.</span><br />
<code class="bbc_code" style="background: rgb(255, 255, 255); border-bottom: 2px solid rgb(153, 153, 153); border-top: 2px solid rgb(153, 153, 153); color: #444444; display: block; font-family: "dejavu sans mono", monaco, "lucida console", "courier new", monospace; font-size: x-small; line-height: 1.5em; max-height: 24em; overflow: auto; padding: 3px 1em; white-space: nowrap;">pacman -Syu sddm</code><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">2. Uruchamiamy nowy DM, np.:</span><br />
<code class="bbc_code" style="background: rgb(255, 255, 255); border-bottom: 2px solid rgb(153, 153, 153); border-top: 2px solid rgb(153, 153, 153); color: #444444; display: block; font-family: "dejavu sans mono", monaco, "lucida console", "courier new", monospace; font-size: x-small; line-height: 1.5em; max-height: 24em; overflow: auto; padding: 3px 1em; white-space: nowrap;">systemctl enable sddm -f</code><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">3. Restartujemy DM (uwaga nastąpi wylogowanie, zapiszcie co potrzebujecie) np.:</span><br />
<code class="bbc_code" style="background: rgb(255, 255, 255); border-bottom: 2px solid rgb(153, 153, 153); border-top: 2px solid rgb(153, 153, 153); color: #444444; display: block; font-family: "dejavu sans mono", monaco, "lucida console", "courier new", monospace; font-size: x-small; line-height: 1.5em; max-height: 24em; overflow: auto; padding: 3px 1em; white-space: nowrap;">systemctl stop lightdm</code><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">(w tym momencie winno nastąpić wylogowanie i system winien uruchomić się z wybranym, nowym DM).</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><b><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">3. Paczki z repozytorium Antergos</span></b><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">W repozytorium Antergosa od czasu do czasu znajdują się paczki, których nie ma w repozytoriach Archa (z których Antergos bezpośrednio korzysta), ale są w AUR. Często paczki tu oferowane są tak konstruowane, by tzw. aur-helpery nie chciały ich aktualizować z AUR. Niestety rozwiązania przyjęte w Antergos nie są najlepsze i najlepiej skorelowane z Archem i AUR w tym zakresie. Otóż, gdy paczka z AUR przejdzie do repozytorium Archa jest od tej chwili aktualizowana przez jego zespół. Nie ma znaczenia, czy ta paczka, wcześniej budowana z AUR w repozytoriach Antergosa jeszcze istnieje, czy też została już usunięta. W naszym systemie pozostajemy z paczką starszą niż dostępna, która jest jednocześnie widoczna jako nowsza (to użycie epoch w PKGBUILD, co dla Was nie ma znaczenia) - pacman takiej paczki nie zaktualizuje. Jeśli zatem zobaczycie w systemie coś takiego (przykład z innego wątku):</span><br />
<code class="bbc_code" style="background: rgb(255, 255, 255); border-bottom: 2px solid rgb(153, 153, 153); border-top: 2px solid rgb(153, 153, 153); color: #444444; display: block; font-family: "dejavu sans mono", monaco, "lucida console", "courier new", monospace; font-size: x-small; line-height: 1.5em; max-height: 24em; overflow: auto; padding: 3px 1em; white-space: nowrap;">ostrzeżenie: pepper-flash: local (1:26.0.0.137-1) jest nowsze niż extra (31.0.0.108-1)</code><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">to oznacza, że spotkaliście się z takim problemem. Ostrzeżenie musi mieć taką postać:</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">a. wskazywać, że lokalna (local) paczka jest nowsza niż w repozytorium (extra, core, community, multilib),</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">b. numer wersji paczki "nowszej" musi mieć postać "1:jakieś.liczby",</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">c. numer wersji paczki w repozytorium musi mieć postać "jakieś.liczby",</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">d. "jakieś.liczby" z paczki w repo muszą mieć wartość większą (>) niż "jakieś.liczby" paczki lokalnej.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Spełnienie łącznie powyższych warunków oznacza, że wbrew ostrzeżeniu (ważny jest ppkt. b), paczka w repozytorium jest nowsza niż lokalna.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Dokonujemy instalacji tej paczki:</span><br />
<code class="bbc_code" style="background: rgb(255, 255, 255); border-bottom: 2px solid rgb(153, 153, 153); border-top: 2px solid rgb(153, 153, 153); color: #444444; display: block; font-family: "dejavu sans mono", monaco, "lucida console", "courier new", monospace; font-size: x-small; line-height: 1.5em; max-height: 24em; overflow: auto; padding: 3px 1em; white-space: nowrap;">pacman -Syu paczka</code><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><b><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">4. Repozytoria Antergosa</span></b><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Tu już sobie sami mocno rozważcie. Osobiście uważam, że lepszym rozwiązaniem jest ich przeniesienie na koniec listy repozytoriów udostępnionych w /etc/pacman.conf. Twierdzę tak dlatego, że niekiedy twórcy Antergosa nie nadążają z aktualizacjami swoich paczek względem paczek w Archu. Stosując się do tej porady dalej będziecie mieć dostępne paczki (tam ich jest 5 na krzyż) z Antergosa, ale bez kłopotów z aktualizacją całego systemu z Archa. Jeśli takie kłopoty wówczas napotkacie, to diagnoza gdzie szukać jest prosta.</span><br style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;" /><span style="background-color: #f9f9f9; color: #444444; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11.7px;">Bezwzględnie to zalecam, jeśli Antergosowi udostępniliście repozytoria testowe Archa. </span>pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-56785749158542494172018-09-20T02:50:00.001-07:002018-09-20T02:50:21.852-07:00Przyciski OK i Anuluj aplikacji Gtk jak w QtPrzyciski potwierdzenia lub wycofania się z jakiejś operacji (OK/Anuluj) w oknach dialogowych aplikacji zbudowanych w oparciu o Gtk są zamienione miejscami w stosunku do standardowych okien w środowiskach korzystających z Qt. Oprócz pewnego dyskomfortu, kwestii estetyki, przede wszystkim skutkuje to gorszą organizacją pracy. Na całe szczęście można to w prosty sposób zmienić.<br />
Jeśli korzystamy z aplikacji zbudowanych na Gtk+2.x musimy dokonać edycji pliku <i>~/.gtkrc-2.0</i>, jeśli korzystamy z aplikacji zbudowanych na Gtk+3.x edytujemy plik <i>~/.config/gtk-3.0/settings.ini</i>, w obu przypadkach dodając linię: <b>gtk-alternative-button-order = 1</b>. To powinno wystarczyć, by we wszystkich aplikacjach wykorzystywanych w środowiskach zbudowanych na Qt (np. Plasma, LXQt, Lumina) miejsca przycisków OK oraz Anuluj były w tych samych miejscach.<br />
<br />
Na podstawie <a href="http://gtk-alternative-button-order%20%3D%201/">porady z BBS Arch Linux</a>.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-65198229825914094792018-09-04T12:44:00.001-07:002018-09-04T12:44:35.535-07:00Są manadynki i są truskawki - StrawberryZnany i lubiany odtwarzacz Clementine utknął od dwu lat na wersji 1.3.1, która sama w sobie nie jest zła, ale w dalszym ciągu oparta jest o Qt4. Wprawdzie rozwój nowej wersji na Qt5 trwa już dłuższy czas i jest ona raczej bezproblemowo używalna, to jednakże i tu niewiele się dzieje ostatnio, by przybliżyć wersję opartą o nowszy framework. Dla tych, którzy chcą się pozbyć w końcu Qt4 ze swoich systemów istnieje zatem opcja w postaci instalacji <a href="https://aur.archlinux.org/packages/clementine-qt5-git">clementine-qt5-git</a> (wraz z kilkoma odmianami, które już niekoniecznie są do znalezienia w AUR), albo...<br />
<br />
Od jakiegoś czasu współpracujący z projektem Clementine Player, Jonas Kvinge rozpoczął prace nad forkiem tej aplikacji, która od początku powstaje w oparciu o Qt5 - jest nią <a href="http://strawbs.org/">Strawberry</a>. I choć napisałem, że "truskawka", to jednak autor odwołuje się do inspiracji nazwą zespołu <a href="https://pl.wikipedia.org/wiki/The_Strawbs">The Strawbs</a> (mam nadzieję, że o ten zespół mu chodzi, a nie o inny, o takiej samej nazwie).<br />
<br />
Mamy zatem nowy, o niewielkich wymaganiach odtwarzacz Strawberry, którego wygląd jest bliźniaczy do Clementine/Amarok 1.4. Obecna wersja to 0.2.1 i raczej wskazuje na dość wczesny stan swego rozwoju. Niemniej jednak jest ona już w pełni funkcjonalna. Przynajmniej jako podstawowy odtwarzacz plików audio. Nie oferuje np. streamingu stacji internetowych. Jeśli zatem ktoś tego wymaga, to niestety tu jeszcze takiej funkcjonalności nie znajdzie. Aplikacja dostępna jest także wyłącznie w języku angielskim.<br />
<br />
Ci, którzy chcieliby wypróbować mają do wyboru wydanie <a href="https://aur.archlinux.org/packages/strawberry/">0.2.1</a> oraz dwie wersje rozwojowe: <a href="https://aur.archlinux.org/packages/strawberry-git/">"zwykłą"</a> oraz <a href="https://aur.archlinux.org/packages/strawberry-full-git/">"full"</a>. Różnice między tymi dwiema widać będzie praktycznie wyłącznie, gdy zbudujemy je na tzw. cleanchoocie lub gdy w systemie nie będziemy mieć xine i/lub vlc. Otóż Strawberry w pełni wykorzystuje jedynie silnik gstreamer, aczkolwiek możliwym jest również wykorzystanie xine oraz VLC. Budując na cleanchroot wersje 0.2.1 lub jej odpowiednik z GIT otrzymamy taką, która będzie bazować wyłącznie na gstreamer, podczas, gdy wersja "full" wykorzysta wszystkie możliwe. W wolnym czasie postaram się wrzucić do POLAUR inne wersje PKGBUILD, które lekko inaczej będą próbowały budować tę paczkę.<br />
<br />
A teraz zachęcam do testowania.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-15038578292406615022018-08-16T01:37:00.001-07:002018-08-16T01:37:49.161-07:00LibreOffice 6.1Z różnych powodów nowe wydanie chyba najpopularniejszego pakietu biurowego open source jest ważne. W wielu miejscach, nawet w popularnych serwisach, które nie zajmują się tematyką komputerową na co dzień, zostało to opisane. Czuję się zatem zwolniony z obowiązku opisywania tego po raz kolejny. Chętnych do zapoznania się ze zmianami odsyłam do <a href="https://wiki.documentfoundation.org/ReleaseNotes/6.1">ich listy</a>. Pozwalam sobie napisać o tej nowej wersji jednakże z innego powodu i z punktu widzenia osoby używającej Plasma 5 jako podstawowego środowiska graficznego w moim systemie. Otóż w końcu zaimplementowana została obsługa wtyczki VCL, która uwzględnia i współpracuje z Qt5. W przypadku wykrycia przez LO, że uruchomienie następuje w tym środowisku ładowana jest wtyczka gtk3_kde5, która oferuje pewien zakres wsparcia dla zintegrowania się pakietu w Plasma 5. Podstawowym VCL pozostaje gtk3 i na nim owa wtyczka jest oparta. Z częścią konsekwencji z niej wynikających. Otóż dzięki działaniu wtyczki, LO uzyskuje natywny dostęp do okien dialogowych Plazmy. Dla osób pracujących w tym środowisku to duże ułatwienie, bowiem okna dialogowe aplikacji Gtk+3 są zupełnie inne, co zwykle powoduje konieczność zmiany przyzwyczajeń dla jednego tylko programu. Z drugiej strony jednak, konsekwencją przyjętego rozwiązania jest to, że cały wystrój pakietu czerpany jest z ustawień Plazmy dla aplikacji Gtk3 (wyjątkiem są ikony, które można zmieniać wyłącznie dla tego pakietu). Również z jego konsekwencjami. Jeśli zatem ktoś korzysta z jakiegoś rozwiązania, które umożliwia jednolity wygląd aplikacji Gtk w Plazmie, to sprawa jest w pełni załatwiona. Standardowo z Plazmą dostarczane mogą być dwa wystroje dla aplikacji Gtk: Breeze i Breeze Dark. Również niektóre inne dostępne tematy oferują także odpowiednie pliki zapewniające jednolitość wystroju. Niestety ze względu na rozwiązania przyjęte w obozie GNOME, jakakolwiek ingerencja w kolorystykę wystroju Plazmy pozostanie bez żadnego wpływu na tę w aplikacjach Gtk+3 otwieranych w tym środowisku. Nie liczcie na to, że zaznaczenie opcji "Nałóż kolory na programy spoza Qt" przyniesie jakikolwiek efekt. <br />
Estetom pozostaje zatem albo pozostanie przy rozwiązaniu dostarczanemu wraz z Plazmą (wystrój Breeze/Breeze Dark dla Plazmy oraz aplikacji Gtk), albo znalezienie jakiegoś innego motywu, który zapewnia taki sam zestaw kolorów dla aplikacji Gtk, jaki oferuje dla Plazmy, albo sięgnięcie po jakiś motyw Gtk i wymuszenie go również dla samej Plazmy. Pozostali nie mają łatwo. Kiedyś jeszcze opiszę dokładnie jak narzucić wybraną przez siebie kolorystykę Plazmy dla aplikacji Gtk3. Dzisiaj tylko wspomnę, że kluczem sukcesu jest plik gtk.css, który można samemu "ujednolicić" z wybranym przez siebie schematem kolorystycznym. Rozwiązanie, które wydaje się być najmniej czasochłonnym (oprócz rozwiązań gotowych), to znalezienie takiego motywu dla Gtk3, który w największym stopniu kolorystycznie odpowiada naszym upodobaniom, skopiowanie wybranego przez siebie tematu dla aplikacji Gtk3 do ~/.local/share/themes i nadanie mu jakiejś własnej nazwy, przeniesienie pliku gtk.css w odpowiednie miejsce w tym katalogu, a następnie jego wybór dla aplikacji Gtk, otworzenie takiej aplikacji i skopiowanie kolorystyki do środowiska Plazmy. Ani to proste, ani nie daje 100% efektów, niemniej jednak lepsze niż napisanie całego gtk.css (no, chyba, że ktoś ma to perfekcyjnie opanowane), niemniej jednak daje efekt lepszy niż dysonans powodowany niechęcią współpracy aplikacji Gtk3 w jakimkolwiek innym środowisku.<br />
Zasadniczym jednak profitem udostępnienia wtyczki gtk3_kde5 jest możliwość rezygnacji z biblioteki kdelibs (wraz z jej zależnościami) o ile ta była utrzymywana w Plasma 5 wyłącznie dla zapewnienia jednolitego wyglądu oraz zachowania się LO w Plazma 5. Oczywiście o ile nie mamy w systemie jeszcze jakichś innych aplikacji rodem z KDE4. Prawdopodobnie również będziecie mogli wówczas uwolnić się od Qt4 (o ile również nie macie w systemie aplikacji zbudowanych na tym toolkicie). Tak kdelibs, jak i Qt4 przeszły już na zasłużoną emeryturę i to dłuższy czas temu. Przypominam również, że stosując VCL KDE4 mogliście dokonać zmian w celu wymuszenia działania tej wtyczki. Sprawdźcie sobie ustawienia w pliku /etc/profile.d/libreoffice-fresh.sh/csh i/lub w ustawieniach startujących wraz z Plazmą (np. takie rozwiązanie było preferowane w OpenSUSE i stało się w miarę powszechne), lub w innych jeszcze ustawieniach zmiennych środowiskowych.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-57363112775595475922018-08-16T00:56:00.002-07:002018-08-16T00:56:51.263-07:00POLAUR teraz dzięki polaurDzięki pracy naszego forumowicza <b>nycko123</b> nasze repozytorium dorobiło się prostego narzędzia umożliwiającego podstawowe nim zarządzanie. Narzędzie nazywa się... a jakże inaczej... polaur i dostępne jest <a href="https://github.com/polaur/new-branded/tree/master/polaur">w naszym repozytorium</a>. Tutaj znajduje się plik PKBGBUILD umożliwiający budowę paczki. Samo narzędzie to zaledwie jeden plik skryptu powłoki. Dzięki jego działaniu możliwe jest:<br />
- zapoznanie się z dostępnymi repozytoriami,<br />
- przeglądanie ich zawartości,<br />
- pobieranie wybranych źródeł paczek.<br />
Pobrane źródła znajdziecie w ~/.cache/polaur/nazwa_repozytorium/nazwa_paczki.<br />
I w zasadzie tyle, bowiem w przeciwnym razie tekst byłby dłuższy od skryptu.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-38205892647900063652018-08-16T00:50:00.001-07:002018-08-16T00:50:33.475-07:00Cudze chwalicie, swego nie znacie - pakDzięki pracy naszego forumowicza <b>nycko123</b> powstała (bo już jest) i powstaje (bo będzie lepsza) swego rodzaju nakładka na pacmana (a także asp) stanowiąca jednocześnie podstawowy tzw. AURhelper. Po co kolejna, skoro już tyle ich jest? O to spytajcie autora, jednakże ze swej strony mogę wyliczyć jej niewątpliwe zalety.<br />
Przede wszystkim jest to skrypt w czystym języku powłoki. Zaledwie jeden plik wykonywalny, jeden konfiguracyjny oraz spolszczenie. W porównaniu z wieloma innymi tego typu narzędziami nie wymaga on zatem instalacji w systemie dużej ilości zależności. Tam, gdzie to możliwe, posługuje się systemowymi narzędziami. W zakresie, w jakim stanowi on menedżer paczek wykorzystuje po prostu pacmana. Z całą jego składnią. Jednocześnie składnię tę rozszerza. Instalując bowiem opcjonalną zależność asp, umożliwia również proste ściągnięcie źródeł paczek z repozytoriów. Oficjalnych na pewno. Jeśli chodzi o nieoficjalne - tu gorzej, albowiem najczęściej tych źródeł po prostu nie ma, a jeśli nawet są, to asp ich nie obsługuje. Dodatkowo, w przeciwieństwie do asp źródła pobiera zgodnie z wyborem użytkownika albo do domyślnego katalogu (definiowany w pak.conf), albo do katalogu bieżącego, co jest dużym ułatwieniem w przypadku konieczności przebudowania znacznej ilości paczek, szczególnie, gdy ważna jest kolejność ich budowy (np. kf5). Można zatem stosunkowo łatwo zadbać o własną hierarchię katalogów, gdzie mają być budowane paczki.<br />
Z drugiej strony rozszerza możliwości pacmana o paczki w AUR dając możliwość jego przeglądania, ściągania źródeł, czy budowy paczek. Jak na razie warto jeszcze zainstalować opcjonalną zależność cower (z AUR), ale niebawem i to zostanie w zupełności wyeliminowane. Oczywiście możliwe jest przeglądanie i edycja PKGBUILDu, możliwe jest również przeglądanie komentarzy przed budową paczki, co jest cennym ułatwieniem i nie jest powszechnym rozwiązaniem pośród aurhelperów. Pak jednak nie stworzy automatycznie paczki z AUR, gdy jest ona zależna od innych, które również mają być z AUR zbudowane. Zamiast tego otrzymujecie stosowne powiadomienie o takiej potrzebie. Dla świadomych użytkowników, to wg mnie cenne rozwiązanie, albowiem hurtowa instalacja wielu paczek nie tylko rozleniwia, ale też powoduje, że użytkownik często sądzi, że z AUR to tak na prawdę ma zainstalowaną jedną paczkę, a nie kilka, czy kilkadziesiąt, które tej jednej stanowią zależności. Biorąc pod uwagę, że w przypadku instalacji paczek z AUR to użytkownik bierze odpowiedzialność za swój system, jest to rozsądne rozwiązanie. <br />
Szczerze polecam. U mnie zastąpił on praktycznie wszystkie inne rozwiązania, jakie stosowałem.<br />
Źródła programu dostępne są w <a href="https://gitlab.com/nycko123/pak">gitlabie</a>. Stosowny PKGBUILD umożliwiający budowę paczki dla Archa dostępny jest w <a href="https://github.com/polaur/new-branded/tree/master/pak">POLAUR</a>, a dzięki narzędziu opracowanemu również przez tego samego autora możliwość przeglądania i pobierania paczek z tego repozytorium stała się dużo łatwiejsza, ale o tym "w następnym odcinku".pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-62113877890706421022018-06-01T06:59:00.002-07:002018-06-01T06:59:50.417-07:00FFMpeg2.8 jako zależność jakichś paczek po aktualizacji x265Jeśli ktoś ostatnio aktualizował Archa, bądź ma to w zamiarze, a używa z jakichś powodów ffmpeg2.8 spotka się z komunikatem nierozwiązywalnych zależności:<br />
<blockquote>nie udało się rozwiązać zależności:<br />
instalacja x265(2.8-1) przerwanej zależność ‚li bx265.so=151-64’ wymaganych przez ffmpeg2.8</blockquote>To nie jest akurat problem, bowiem usunięcie niewspieranej już przez Archa wersji ffmpeg (2.8 jest obecnie w AUR) umożliwi dalszą instalację. Problemem może stać się fakt, że niektóre aplikacje wymagają właśnie tej wersji jako swej zależności. Gorzej, gdy kod takich aplikacji jest zamknięty (np. 4KVideoDownloader) i w zasadzie nic już więcej zrobić nie można, jak pogodzić się z koniecznością pożegnania się z taką aplikacją.<br />
Czyżby?<br />
Może jednak nie w każdym przypadku.<br />
Wpierw spróbujmy zainstalować ffmpeg2.8, ale nie z repozytoriów binarnych (np. aur-archlinux), ale budując go w systemie:<br />
<blockquote>git clone https://aur.archlinux.org/ffmpeg2.8 && cd ffmpeg2.8 && makepkg -sirc</blockquote>(pamiętajmy o dodaniu klucza GPG, albo o ominięciu jego sprawdzania przy budowaniu - czego oczywiście nie polecam).<br />
Budowa i instalacja winna przebiec bez problemów. Teraz możemy spróbować zainstalować aplikację, która korzysta jeszcze z już porzuconego ffmpeg2.8.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-36729572287678458932018-04-26T03:05:00.001-07:002018-04-26T03:05:48.940-07:00Przeczytano w sieci: umożliwiamy podmontowanie urządzenia z AndroidemJeśli wciąż masz problemy z podmontowaniem jakiegokolwiek urządzenia z Androidem, to wydaj na prawach administratora następujące polecenie:<br />
<blockquote>sed 's/ACTION/ACTION!="bind", ACTION/' /usr/lib/udev/rules.d/69-libmtp.rules | sudo tee /etc/udev/rules.d/69-libmtp.rules > /dev/null</blockquote>Dopisze ono regułę o treści: <i>ACTION!="bind", ACTION!="add" GOTO="libmtp_rules_end"</i> w miejsce <i>ACTION!="add" GOTO="libmtp_rules_end"</i> znajdującej się w pliku <i>/usr/lib/udev/rules.d/69-libmtp.rules</i>. Od tej chwili, po ponownym podłączeniu urządzenia z Androidem nie powinno być już z nim problemów. Jeśli są (bądź dla pewności) możecie jeszcze wydać polecenie:<br />
<blockquote>udevadm control --reload-rules</blockquote>(oczywiście na prawach administratora), które przeładuje reguły dla udev.<br />
Trzeba jeszcze pamiętać o tym, że powyższy plik należy do paczki libmtp i sprawdzać jak się zachowa nasz system po jej aktualizacji.<br />
Całość znaleziona na <a href="https://www.reddit.com/r/kde/comments/8escci/for_those_who_are_still_unable_to_mount_an/">reddicie</a>.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-87441315102901578952018-04-26T02:55:00.001-07:002018-04-26T02:55:37.681-07:00Przeczytano w sieci: poprawiamy wygląd czcionek w SystemSettingsKDE Frameworks 5.45 wprowadziło dużo dobrych zmian. Okazuje się jednak, że jedna z nich skutkuje <a href="https://imgur.com/Ojdelpt">wadliwym wyglądem czcionek</a> w Ustawieniach systemowych (a najprawdopodobniej też i innych, używających qqc2-desktop-style. Problem nie występuje zawsze i zależy od specyficznych ustawień określonych czcionek i ich wielkości. Okazuje się, że jest to pokłosiem commitu, który <a href="https://github.com/KDE/qqc2-desktop-style/commit/9a5f7d834f86f57e88c3993fbcf4c17d09a01e10">miał poprawić renderowanie czcionek</a>. Istnieją różne sposoby na poprawę tego wyglądu, jednakże niekoniecznie przynoszą one efekty. <a href="https://bugs.kde.org/show_bug.cgi?id=393202#c8">Autor commitu zaleca</a> tymczasowo dokonanie edycji pliku <i>/usr/lib/qt/qml/QtQuick/Controls.2/org.kde.desktop/Label.qml</i>, odnalezienie w nim linii zaczynającej się od <i>renderType:</i> i zakomentowanie jej, oraz dopisanie nowej o treści: <i>renderType: Text.QtRendering</i>. Ponowny start Ustawień systemowych winien odbyć się już bez problemów i to niezależnie od tego jak mamy ustawione czcionki w systemie.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0tag:blogger.com,1999:blog-8431974948820046336.post-16398742408374160842018-03-15T07:34:00.002-07:002018-03-15T07:34:28.221-07:00Wiadomości z POLAUR - repozytorium debugPowstało nowe repozytorium <a href="https://github.com/polaur/debug">debug</a>, w którym będziemy umieszczać PKGBUILDy umożliwiające budowę paczek z tzw. symbolami debugowania. Obecnie znajdują się tam PKGBUILDy paczek wchodzących w skład grup kf5, kf5-aids oraz plasma <b>bez żadnych innych zmian</b> w stosunku do oryginału w Arch z wyjątkiem dodania budowania owych symboli.<br />
Zbudowane z tego repozytorium paczki umożliwią Wam lepsze zgłaszanie błędów czy to w bugzilli Archa, czy - jak na razie - w KDE.<br />
Niebawem pewnie dodam również paczki przynajmniej głównych aplikacji składających się na grupę kde-applications. Być może znajdą się tam również paczki aplikacji budowanych w wersjach rozwojowych z innych naszych repozytoriów.<br />
Paczki będą aktualizowane wraz z ich aktualizacją w repozytorium Archa.pavbaranovhttp://www.blogger.com/profile/14652612344662027902noreply@blogger.com0