Zde je pro vás zajímavý problém. Pamatujete si můj Asus Vivobook s duálním spouštěním Windows 8 a Ubuntu? Stroj jsem nechal upgradovat z Trusty na Bionic a v průběhu dalších cvičení jsem do systému nainstaloval i Plasmu. Všechno bylo v pořádku, ale kdykoli jsem spustil Discover, všiml jsem si zprávy, která by tam neměla být.
Ve spodní části hlavní obrazovky Discover by to stálo:kdenlive_projectprofiles.knsrc" "Načítání poskytovatelů ze souboru:https://kdenlive.org/data/mltprofilesources.xml selhalo". Zvláštní. Kromě toho, že se to párkrát objevilo sekund, vše fungovalo dobře. Byl jsem schopen vyhledat aplikace přes Discover a nainstalovat je, Kdenlive fungovalo podle očekávání. Ale moji démoni OCD to nenechali odpočívat. Tak to pojďme napravit, ano.
Problém podrobněji
Samozřejmě jsem klikl na intertubez, abych zjistil, co dává, a zjistil jsem, že spousta lidí si na to během posledních čtyř nebo pěti let stěžovalo s tou či onou aplikací. Někteří by také zažili širší problémy, protože by nebyli schopni nainstalovat software a podobně. Pro mě byl problém omezen na falešnou zprávu.
Abych se dozvěděl více, spustil jsem KDE Discover (plasma-discover) z příkazového řádku. To znamenalo možnost zobrazit chyby podrobněji, včetně úplných cest ke všem konfiguracím nebo souborům, které by mohly být ovlivněny. Výstup nebyl čistý a bylo tam několik varování pro spoustu věcí. Ale ten, který je opravdu zajímavý, je tento:
plasma-discover
...
org.kde.knewstuff.core:"Chyba při přenosu https://kdenlive.org/data/mltprofilesources.xml - server odpověděl:Nenalezeno"
kns error "/etc/xdg/kdenlive_projectprofiles.knsrc" "Načítání poskytovatelů ze souboru:https://kdenlive.org/data/mltprofilesources.xml selhalo"
qml:zpráva:kdenlive_projectprofiles.knsrc:Načítání poskytovatelů ze souboru :https://kdenlive.org/data/mltprofilesources.xml se nezdařilo
chyba:"Očekáváno '#' nebo '[a-zA-Z]', ale dostal '&'." v QUrl("https://kdenlive.org/data/mltprofilesources.xml")
Abych ověřil, zda se jedná o problém s plazmou nebo o problém Kdenlive, zkontroloval jsem uvedenou adresu URL a skutečně vracelo 404. Takže Discover zde nebyl na vině, něco chybělo na straně aplikace. To mi také umožnilo zúžit vyhledávání.
Řešení
Brzy jsem našel tuto chybu KDE - která měla problém vyřešit, a ve skutečnosti jsem tento problém neměl zažít. Ale tady je zásadní důkaz, vzhledem k tomu, že jsem aktualizoval distro z Trusty na Bionic a posunul se zhruba o čtyři roky v čase za jedno odpoledne, konfigurace z mého nastavení byla přenesena a zastaralé kousky a kousky nebyly skutečně řádně vyčištěny.
Pokud rozumím problému, soubory knsrc mají být umístěny v /usr/share a soubory v /etc nejsou automaticky odstraněny (kvůli chybě). Pokud tedy máte staré konfigurace, mohou odkazovat na online zdroje nebo adresy URL, které již neexistují (nebo se změnily), což je docela pravděpodobné, když mluvíme o velkých aktualizacích distribuce. A s těmito konfiguracemi způsobí Discover chyby.
Ve skutečnosti byly v /etc/xdg/kdenlive všechny soubory relativně aktuální (2018), kromě toho, na který se odkazuje v chybách kdenlive_projectprofiles.knsrc, který byl naposledy změněn v roce 2016. A proto je řešením toto odstranit soubor ručně.
-rw-r--r-- 1 kořenový kořen 244 10. března 2016 kdenlive_projectprofiles.knsrc
-rw-r--r-- 1 kořenový kořen 1124 2. března 2018 kdenlive_wipes.knsrc
-rw-r --r-- 1 kořenový adresář 1133 2. března 2018 kdenlive_titles.knsrc
-rw-r--r-- 1 kořenový adresář 1197 2. března 2018 kdenlive_renderprofiles.knsrc
-rw-r--r- - 1 kořenový kořen 48. března 2 2018 kdenlive.categories
Což jsem elegantně udělal (vlastně jsem to přesunul, takže bych měl zálohu):
sudo mv /etc/xdg/kdenlive_projectprofiles.knsrc ~/backup/
A KDE Discover nyní běželo bez chyb. Myslím si však, že správným řešením by měla být transparentní změna na systémové úrovni bez jakékoli interakce uživatele. Celá věc potřebuje lepší zpracování chyb. Jsem si také jistý, že tato akce nemá žádné vedlejší účinky, a přesto není odstranění konfiguračních souborů nikdy triviální, že. A konečně, chyba uživatelského rozhraní není užitečná, protože nemá úplnou cestu a prezentované informace pouze matou uživatele. Pokud potřebujete příkazový řádek k zobrazení skutečného souboru, o kterém se jedná, pak by se chyba neměla zobrazovat v Discover.
Závěr
Tam jedeme. Teď si můžu zase odpočinout, protože systém je bez chyb. Myslím, že to bylo docela užitečné cvičení, protože se zabývá duchem po upgradu, který není okamžitě patrný - a který by tam neměl být, povšimněte si. Normálně používám k instalaci softwaru rozhraní příkazového řádku, takže mi chvíli trvalo, než jsem to našel. A bez jakýchkoliv zdánlivě nemocných příznaků je tento problém problematický, protože si nemůžete být 100% jisti, že řešení v určitém okamžiku nezavede budoucí duchy.
Ale pokud se potýkáte s problémy podobného druhu, spusťte Discover z příkazového řádku, pokuste se určit chybu a poté pečlivě prozkoumejte informace, abyste zjistili, zda se jedná o problémové řádky ve správci balíčků nebo o odkazované soubory (a vzdálené zdroje). Jakmile izolujete viníka, zjistěte, zda pomůže odstranění nebo vyčištění, ale ujistěte se, že máte zálohu, abyste se mohli snadno vrátit. A myslím, že to by bylo pro tento článek o plazmě vše.