Cinq mois après mes mésaventures suites à une mise à jour Debian/KDE testing, rebelote, j’ai à nouveau un problème suite à une mise à jour classique. Ce qui n’est pas si étonnant quand on utilise testing, surtout que testing a switché assez récemment sur bookworm.

Les symptômes très classiques : la page de login s’affiche, je m’authentifie, la page de chargement de Plasma KDE s’affiche, le loader tourne puis s’arrête au bout de quelques secondes et… voilà ! J’ai la souris, mais pour le reste c’est figé sur l’écran de chargement.

J’ai fini par trouver quel était le problème (incompatibilité temporaire entre kwin et kdecorator), mais voici les étapes par lesquels j’ai dû passer, pour finalement trouver la réponse sur un rapport de bug dans une mailing list Debian. J’en sais désormais d’avantage sur SDDM, X11, Kwin et le montage du bureau.

Au delà de l’analyse de sa machine, le bon réflexe à avoir c’est de regarder la liste des bugs en cours sur Debian : le portail des bugs et son moteur de recherche.

Sur ma Debian KDE bulleyes, j’ai récemment remarqué qu’Akonadi utilisait plus de 15 go d’espace disque ! Akonadi, c’est ce mécanisme de base de données partagées que peuvent utiliser les applications Linux pour faciliter l’accès aux données de l’utilisateur : email, agenda, rappels, etc. C’est principalement utilisé par de plus en plus d’applications KDE comme KMail, KOrganizer, etc.

Pourtant, il ne me semble pas utiliser particulièrement ces applications… J’utilise Thunderbird et je m’en porte très bien ! Akonadi est normalement coupé par défaut, et activé dès qu’une application le nécessite. Il semblerait que l’horloge KDE puisse l’activer (eh oui, elle peut afficher un agenda), mais à part ça, mystère.

Mon hypothèse c’est que j’ai dû tester un jour KMail, puis le désinstaller, et Akonadi s’est ainsi retrouvée avec 15 go d’emails dans sa base de données.

J’ai cherché, et je n’ai pas trouvé comment savoir si ces données étaient vraiment utiliser, ni comment purger. Alors j’ai suivi les conseils de ce thread KDE : couper Akonadi, tout supprimer, relancer Akonadi. Oui.

Plasma crashe au boot à cause d’EventCalendar

Pour ceux qui sont sous Debian Testing Bulleyes (so 2020), si jamais vous avez le même problème que moi (j’ai juste ouvert mon ordi pour rien d’important, et pof écran noir, juste la souris, même après le reboot, bref galère) :

Je ne sais pas qui est la cause de quoi, mais il s’avère que le plugin qui affiche l’heure EventCalendar s’est aussi mis à crasher et le résultat c’est que Plasma crash au démarrage et affiche un écran noir. Le plus simple c’est de sauvegarder puis supprimer `.config/plasma-org.kde.plasma.desktop-appletsrc` puis de reboot (Donc `Alt+F2` pour afficher un terminal, ou bien `Ctrl+Alt+F2`). ça recréera une config par défaut. J’ai pu comparer les 2, faire des tests, détecter le pb d’affichage de l’heure par hasard, et du coup remettre ma config d’origine corrigée.
Plasma s’affichait bien, mais pas le décorateur de fenêtre (pas possible de déplacer, fermer des fenêtres, alt+tab marchait pas).

EventCalendar est toujours planté aujourd’hui, donc je ne l’utilise plus. Lorsque j’ai eu ce problème, j’avais probablement un double bug EventCalendar + kwin. C’est peut-être dû à la dernière mise à jour que j’ai faite, soit ça a cassé mon kwin (le « window decorator »), soit ça a introduit un bug dans kwin. Bref, dans la soirée une nouvelle version de kwin est apparu et cela a réglé le souci. J’ai cherché à savoir si c’était ma config ou un bug, mais je n’ai pas trouvé.

Au moins, je sais maintenant où trouver la config de Plasma, et je sais ce qu’est un window decorator 😀

Redémarrage live de Plasma

La commande pour redémarrer plasma c’est : `killall plasmasheel` (pour tuer l’ancien) puis tout simplement `plasmashell &`.