Catégorie : Bugs Debian

L’observatoire du fonctionnement de ma Debian Testing (MAJ : 15/10/2019)

Préambule

J’ai suivi Debian Sid pendant 3 ans durant lesquels j’ai été confronté à des petits bugs réguliers et à quelques bugs plus sérieux (listé ci-après), mais pas insurmontables au point de devoir tout réinstaller.

Et puis le 1er aout 2019, un gros plantage de Grub et des soucis avec mdadm ont été les soucis de trop. J’ai choisi d’être plus prudent dans mes mises à jour. Même si je serai inévitablement confronté à d’autres bugs, j’espère espacer davantage ces problèmes et passer plus de temps sur les mises à jour du Bottin.

Debian Sid a terminé sa période de gel des paquets avant publication, pour sa nouvelle mouture (Debian 10) publiée le 6 Juillet 2019. Après cette date les vannes ont été rouvertes et de nombreuses mises à jour de paquets sont à nouveau proposées pour l’incubation de la prochaine version majeure qui sortira vraisemblablement dans 2 ans (mi-2021).

Quelques constats :
• En Juillet 2019 Debian 10 vient d’être publiée, elle est donc récente (pour mes compilations de jeux, il est peu probable que je rencontre des soucis de nouvelles bibliothèques / versions absentes des dépôts).
• En ce moment on retrouve en dépôts beaucoup de versions beta ou versions internes à Debian – qui n’offrirons vraisemblablement qu’un bénéfice faible (nouvelles fonctionnalités ou améliorations de performances) en regard des risques potentiels de bugs.

Donc, au moins pour quelques mois (6-12 mois, et voir vraisemblablement davantage), il me semble nettement plus pertinent :
• de passer et rester sur une Debian testing (= paquets issus de Debian Sid, sans report de bug pendant 2 semaines), qui offre un excellent compromis stabilité / nouveautés
• de ne mettre à jour que les changements significatifs de versions (saut d’1 à 2 versions) et si possible, dans une version stable (pas de paquets en version beta).

• Autre constat : plus de bugs constatés (ou presque), c’est devenu un poil rasoir, mais plus rassurant tout en étant à jour

Météo de la période

Météo de ma Debian Sid (01/10/2019 ➤ 15/10/2019) : 🔆
(🔆 ⛅ ☔ ⚡ 💥)

Résumé des changements :

– 🔆 Steam (32-bit) fonctionne à présent sur ma Debian 64-bit grâce au paquet FlatPak ! (Je n’y arrivais pas depuis les dépôts classiques).
– 🔆 Flatpak fonctionne bien et apporte quelques binaires supplémentaires de grand intérêt (Steam notamment). De plus la résolution du bug (le paquet Debian v. 1.4.3-1 est bugué, voir plus bas) m’a donné un indice pour reprendre (ultérieurement) mon test de snap.
– 🔆 Pour le reste pas de changement dans la période, c’est très calme, globalement mon système fonctionne très bien. Ne perdez pas votre temps à lire ce qui suit : toujours pas de changement.

(Ci-après : les paragraphes notés comme « RÉSOLU » sont effacés sur la session suivante)


Pourquoi cette page ?

Ma conclusion est que les dépôts Européens de Debian Sid (que j’utilisais depuis de nombreuses années) ne sont pas utilisables en production (dysfonctionnements répétés de paquets importants pouvant conduire à des plantages sérieux). J’ai aussi rencontré des problèmes sérieux (mais plus rares) sur ces mêmes dépôts en version stable.

Les dépôts Américains sont bien plus fiables (mais pas totalement dénués de bugs sérieux) pour cette même version Debian Sid (même s’ils rencontrent eux aussi des bugs réguliers, et certains importants – c’est une version de développement, ne l’oublions pas).

Debian 10 venant d’être publiée début Juillet 2019, au moins pour quelques mois il me semble pertinent de ne pas tout mettre à jour sans un bénéfice certain et de passer à Debian testing. En terme de sécurité, j’y ajoute une mise à jour au cas par cas : pour un paquet donné, 1 ou 2 versions (stable, pas de beta) d’écart par rapport à la version courante.

Aujourd’hui, le contenu exhaustif (pas une ligne de plus) de mon fichier /etc/apt/sources.list :

# Peu sûr (↪ désactivé pour l’instant) :
# deb http://ftp.us.debian.org/debian/ sid main contrib non-free

# Plus sûr (Packages arrive into testing after they have been sufficiently tested on sid, specifically, two weeks without any outstanding bug reports) :
deb http://ftp.us.debian.org/debian/ testing main contrib non-free

# Sûr :
deb http://ftp.us.debian.org/debian/ stable main contrib non-free

Je suis – d’une manière générale et sur la durée, satisfait de ces dépôts et de ma distribution Debian.
Néanmoins cela n’empêche pas des dysfonctionnements ponctuels et/ou récurrents, tout à fait supportables. Je me suis décidé à les lister, dans l’espoir que çà puisse servir à quelqu’un (au moins pour alerter les développeurs et conforter éventuellement certains utilisateurs dans leurs doutes).
J’ai ajouté les dates de survenue de ces dysfonctionnements, car je pense que la durée de leur résolution est aussi un paramètre entrant en compte dans le degré d’insatisfaction de l’utilisateur.
Notez que je fais ici volontairement l’amalgame entre les dysfonctionnements liés directement à la distribution Debian (démarrage, packaging, configuration) et ceux liés à d’autres projets externes (CUPS, SANE, MATE, …).

L’idée est d’exprimer le ressenti de l’utilisateur (en l’occurrence moi dans mon coin) lorsqu’il utilise une distribution Linux Debian 64-bit Sid / Testing (depuis le 01/08/19).

J’utilise le terme « dysfonctionnement » plutôt que « bug » pour englober également d’éventuels problèmes de paramétrages.

J’ai donc créé cette page au titre un peu pompeux, mais qui traduit une volonté de transparence pour tenter d’améliorer les choses (ma modeste contribution). Et puis j’aime quand çà marche.


Historique des dysfonctionnements importants survenus

  • Debian Testing (dépôt US) – mise à jour de tous les paquets 1 à 2 fois par semaine : 0 année et env. 2 mois sans plantage sérieux (depuis le 01/08/19).
  • Historique précédent (sous Debian Sid, mise à jour de tous les paquets quotidiennement) : 3 ans sans plantage sérieux (01/06/16➜17/06/19).
  • Historique :

    Le 13/10/2018, après avoir reçu de nouveaux disques durs de capacité plus élevée, j’en ai profité pour migrer ma distribution en 64-bit (elle était en 32-bit). J’ai donc opté pour une ré-installation complète d’une Debian Sid 64-bit sur ces disques vierges.

    Cette réinstallation aurait pu clore la comptabilisation effectuée sur la période précédente (2 ans et 4.5 mois sans plantage sérieux), néanmoins j’ai poursuivi le suivi, parce que cet historique me semblait un échantillonnage intéressant des possibilités de pannes à la mise à jour. Il est vraisemblable qu’un jour tout ceci appartiendra au passé et que j’effacerai cet historique.

    Dysfonctionnements sérieux dans la période ci-dessus :

    Debian 32-bit :

    • j’ai évité de peu un gros plantage avec udev 232-1 le 4 novembre 2016, mais le dysfonctionnement du paquet était signalé par une erreur à l’installation
    • j’ai évité de peu un gros plantage à la mise à jour (mise à jour importante) de mon PC relié à internet le 7 décembre 2017 suite au plantage de Synaptic. Après la mise à jour de nombreux paquets (vraisemblablement une centaine, voir davantage) sur ce PC, synaptic était devenu complètement léthargique. Dans la liste il y avait des paquets importants tel que libc6. Je l’ai laissé poursuivre une nuit complète et l’ai retrouvé dans le même état le lendemain. La solution aura été de fermer brutalement Synaptic (par un kill -9 en console) et de lancer en console un « # dpkg –configure -a », suivi d’un « # apt-get -f install » pour terminer manuellement la configuration avant de redémarrer. Le redémarrage suivant a très bien fonctionné. Cela m’a servi de leçon, et aujourd’hui je ne lance plus de très grosses mises à jour avec Synaptic (par exemple avec un système pas mis à jour depuis quelques mois) : il est bien plus fiable de lancer en console un « # apt update » suivi d’un « # apt upgrade ». J’utilise Synaptic tous les jours, mais pour de petites à moyennes mises à jour (quelques dizaines de paquets au maximum).
    • j’ai évité de peu (par chance) un gros plantage le 5 Janvier 2018, suite à un dysfonctionnement probable de la création des ramdisks (fichiers /boot/initrd.img-version_noyau) après la mise à jour de bibliothèques (e2fslibs, e2fsprogs, libc-bin, libc-dev-bin, libc6, libc6-x32, multiarch-support), ce qui s’est traduit de la manière suivante :
      • le noyaux Linux 4.13.0-1-686-pae ne démarre plus (« kernel panic » au démarrage du système, alors qu’il fonctionnait jusque là, et que son fichier /boot/initrd.img viens d’être mis à jour) le 4.14.0-2-686-pae (fraîchement installé) ne fonctionne pas non plus (même message).
      • par chance, le noyau 4.12.0-1-686-pae fonctionne encore (son fichier /boot/initrd.img n’a heureusement pas été mis à jour).
      • le 7/1/2018, mise à jour de binutils & dérivés et du noyau linux en version linux-image-4.14.0-3-686-pae : ne marche toujours pas.
      • le 31/01/2018, mise à jour des paquets : binutils, binutils-common, binutils-dev, binutils-i686-linux-gnu, binutils-multiarch, libbinutils, libdbus-glib-1-2, libevdev2, libnss-systemd, libpam-systemd, libsystemd0, libudev1, systemd, systemd-sysv, udev.
        et là le noyau linux-image-4.14.0-3-686-pae fonctionne (ainsi que le noyau 4.12.0-1-686-pae), mais toujours pas le 4.13.0-1-686-pae.
    • le 16/05/2018, perte de la synchronisation des montages RAID de mes disques durs après la mise à jour de mdadm (en version 4.1~rc1-1) et dans le même temps, mise à jour automatique de Grub, et ce dernier ne trouve plus les montages RAID et ne parvient donc plus à mettre à jour son fichier de configuration. Là encore j’ai frisé la galère de me retrouver avec un système qui ne démarre plus (j’avais heureusement remarqué le message d’anomalie de Grub, noyé au milieu de nombreux autres messages informatifs, et ai donc pu agir avant le redémarrage de ma distribution).

    Précisions : pour diminuer la fréquence des bugs liés aux mises à jour, j’avais bloqué (sous Synaptic) la mise à jour de certains paquets, préférant contrôler moi-même leur installation, quand je l’estime opportun. J’ai ainsi bloqué les paquets suivants : le dernier noyau linux fonctionnel avec les paquets annexes de la même version (car il n’est pas si rare qu’une mise à jour désinstalle une version fonctionnelle pour installer une version mineure buguée, donc quand ça marche je bloque, « le mieux est souvent l’ennemi du bien »), mdadm (inutile de risquer une désynchronisation des disques pour une version mineure), tellico (la 3.1-0.3 fonctionne très bien et les mises à jour apportent peu de nouvelles fonctionnalités) et timidity (la dernière mise à jour avait coupé le son de ma Debian).

    Debian 64-bit :

    • le 13/10/2018, après avoir installé une version minimaliste (netinstall à partir d’une clé USB) de la Debian Stable 9.5.0 sur des disques vierges, j’ai changé (avec l’éditeur nano) l’adresse des dépôts (dans /etc/apt/sources.list) pour que ma distribution puisse accéder aux paquets de la Debian Sid (l’idée était de ne pas perdre de temps à télécharger inutilement de nombreux paquets de la Stable pour les passer ensuite en Sid). Ensuite j’ai lancé la grosse cavalerie : l’installation de xserver-xorg, kde, gnome, mate, lxde, … et après 2-3h tout s’est terminé sans erreur affichée. Mais j’ai constaté que la commande apt ne fonctionnait plus (plutôt gênant sous Debian :). Le problème venait d’apt, utilisé pour la mise à jour, il était resté dans son ancienne version (en 1.4.8), au lieu de migrer lui-aussi dans sa version la plus récente (en 1.7.0). De ce fait, il ne parvenait plus à communiquer avec libapt-pkg5.0 (en 1.7.0).
    • le 10/03/2019 puis le 15/04/2019, gros plantage de mon système Debian : glitchs sous MATE puis freeze complet, même avec Ctrl Alt F1 impossible de le récupérer, boot du système (sans que je n’intervienne), avec perte de l’affichage aux démarrages suivants. J’ai fini par éteindre mon PC, l’ai laissé reposer (1/2h ?) puis plus tard je l’ai redémarré et l’affichage est revenu. Le problème était matériel, il venait à la fois d’un faux contact de la prise électrique reliant mon écran à l’onduleur (dont la batterie est hors d’usage, il ne me sert plus) doublé d’un souci avec ma carte graphique (mon ancienne carte graphique à repris du service).
    • le 17/06/2019, après un changement de matériel (carte graphique, carte mère, mémoire, processeur, mais j’ai conservé le reste, dont les disques durs), je tente de redémarrer sur mes anciens disques durs : ça ne démarre pas (j’espérais au moins voir démarrer le noyau Linux), le noyau ne trouve pas mes disques RAID (je pensais que les UUID lui permettrai de les retrouver efficacement mais ça n’a pas été le cas). Après différentes tentatives de démarrage du RAID et d’insertions de clés USB, je me rend compte que l’un de mes disques est vide et que l’autre (RAID) est visiblement en train de s’aligner dessus : j’ai perdu mon disque principal. Même si mon OS n’est vraisemblablement pas entièrement responsable, je considère qu’il en est à l’origine puisqu’il n’a pas été capable de retrouver seul les disques malgré leur numérotation en UUID et qu’ensuite il a été à l’origine de la suppression du disque de sauvegarde. Mais j’avoue que les circonstances exactes ne sont pas claires pour moi.
    • le 10/07/2019, mise à jour de Grub. Après un reboot, mon PC plante dès le démarrage sur « error: symbol ‘grub_file_filters’ not found. ». Même un chroot ne fonctionne pas, et les commandes basiques « ls » ou « mount » me renvoient un message de type « ls: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory ». Pas moyen non plus de réinstaller le MBR avec un netinstall (il plantait). Finalement le souci a été résolu en écrasant le répertoire /boot/ par une sauvegarde. J’ai d’abord suspecté la dernière version de Grub, mais il se pourrait que le souci provienne de l’installation du MBR sur la partition /sda1 au lieu de /dev/sda (je l’ai ensuite copié aussi sur /dev/sda), ce qui peut dans certain cas particulier empêcher le système de trouver ce MBR (j’ai lu ça quelque-part). Mais dans ce cas, comment la simple copie du répertoire /boot/ a-t-elle résolue mon problème ? (là non plus c’est pas très clair :)). Tout ceci a sérieusement ébréché ma confiance dans Debian Sid.
    • le 01/08/2019 je suis passé à Debian Testing et ne met pas à jour tous les paquets – seulement ceux qui ont à minima 1 ou 2 versions d’écart.

    Mon seuil de tolérance : dysfonctionnements éventuels (en Debian Sid/Testing c’est normal) et éventuellement plus d’interface graphique mais à minima le système démarre (au besoin sur un ancien noyau – qu’il faut toujours garder en réserve sous Grub), permet la saisie de commandes, l’accès aux données et à internet.


    Bilan de la période

    Les points négatifs (dysfonctionnements) dans la période du 1er octobre 2019 au 15 octobre 2019 :

    Pas d’autres dysfonctionnements dans la période.
     

    Les points positifs (dysfonctionnements résolus, nouveautés) dans la période du 1er octobre 2019 au 15 octobre 2019 :

    (RÉSOLU) (PEU IMPORTANT) Le système de paquet FlatPak plante au démarrage (sur « Could not initialize GLX »), constaté le 12/10/2019

    Lors de mon test de l’interface Athenaeum (voir sa section « Test » dans le Bottin), j’ai constaté que le paquet FlatPak (lui-même) plantait au démarrage sur le message « Could not initialize GLX ».
    Finalement le problème a été résolu en le mettant à jour en console avec la commande : $ flatpak update
    Visiblement le paquet Debian v. 1.4.3-1 est bugué (car la version opérationnelle porte le même numéro).
    Comme le symptôme semble assez proche de celui constaté avec snap, il est possible qu’il se résolve de la même manière (snap à tester à nouveau ultérieurement).

    Pas d’autres dysfonctionnements résolus dans la période.
     

    Quelques applications sympas testées dans la période du 1er octobre 2019 au 15 octobre 2019 :

    Ne pouvant me résoudre à supprimer les informations de cette rubrique une fois la période écoulée, j’ai créé une page sur le WIKI du Bottin pour les rassembler.

    (pas d’autre / de nouveau test)

     


    Dysfonctionnements toujours d’actualité

    (AGACANT) Ralentissement de mon PC par le processus « python3 /~-update -q ») déclenché à chaque démarrage de synaptic, constaté le 26/08/2019
    J’ai des ralentissements intempestifs de mon PC dû à une utilisation intensive du disque dur par un processus qui se déclenche périodiquement et lance la commande : python3 /~-update -q
    En fait j’avais remarqué ce dysfonctionnement quasiment depuis ma dernière installation Debian en Juin 2019 mais je n’étais pas parvenu à l’isoler, et comme ça n’arrivais que de temps en temps puis cela s’arrêtait, j’avais laissé de côté. Mais là ça commence à m’agacer et j’ai trouvé un message analogue ici : Linux MINT (Hard drive has heavy access daily for roughly 20 minutes.)

    Sauf que dans mon cas, ni timeshift, ni mlocate, ne sont installés.

    Je cherche dans /etc/cron, mais je ne trouve pas le fautif. Il faut dire que mes répertoires /etc/cron sont très réduits car j’y ai fais du ménage : je ne supporte pas ces trucs qui se lancent de manière intempestive, qui ne disent pas ce qu’ils font (il manque une info quelque-part – à la manière de la zone de notification, qui informe l’utilisateur de ce que fait le système lorsque des processus assez lourds sont lancés) et ralentissent mon PC pour une plus-value parfois discutable (j’aimerai pouvoir désactiver ces processus ou au moins les reporter à un moment plus opportun d’un clic sur une boite de dialogue sur le bureau).

    Voilà une exemple d’idée qui permettrait de démarquer une fois de plus Linux de Windows : le respect du souhait de ses utilisateurs par une boîte de dialogue dans la zone de notification (pour être facilement accessible) permettant de reporter des actions lourdes requises par le système : un vrai dialogue entre la machine et son utilisateur.

    On pourrait y mettre :
    – les mises à jour (de paquets sûrs) du système
    – les mises à jour de bases de données
    – le déclenchement de sauvegardes de données
    – etc…

    À mon avis ce processus « python3 /~-update -q » est lançé ailleurs que dans /etc/cron mais je ne sais pas où.
    ➯ Finalement j’ai fini par trouver que c’est synaptic qui lance cette commande. En effet, après avoir tué le processus, celui-ci ne revient que si je lance synaptic (environ 20 à 30 secondes plus tard). Donc à chaque lancement de synaptic je me trouve avec ce processus qui génère de forts ralentissements de mon PC (il affiche un IO en moyenne de 99.99%).

    Comme je ne sais pas quel est le motif sérieux du lancement de cette commande, que je n’aime pas l’idée que l’on puisse scruter mes disques durs sans une excellente raison, et qu’en plus elle ralenti significativement le fonctionnement de mon PC, à chaque démarrage de synaptic je commence par repérer le n° du processus lancé et je le tue manuellement (c’est quand même pénible à la longue).
    ➯ Le 15/10/2019 : pas d’amélioration

    (PEU IMPORTANT) Les paquets SNAP (snapd v.2.37.4) ne fonctionnent pas, constaté le 15/05/2019
    Constaté lors de ma tentative d’installation de l’émulateur Anbox, mais aussi avec le jeu « Shattered Pixel Dungeon ».
    Le souci vient du fait que Snap ne trouve pas l’accélération graphique alors qu’elle est fonctionnelle :
    (…)
    libGL error: No matching fbConfigs or visuals found
    libGL error: failed to load driver: swrast
    (…)
    ➯ J’ai pour l’instant désinstallé snapd, j’y reviendrai plus tard (ça me semble compliqué et lourd par rapport à AppImage).
    Petite nouveauté le 15/10/19 : j’ai testé FlatPak dans la période et ai constaté le même type d’anomalie (« Could not initialize GLX »). Le problème a été résolu en le mettant à jour lui-même en console (le paquet Debian était bugué, voir le test de l’interface Athenaeum dans le Bottin). Du coup ça m’a donné l’idée de lancer le même type de test avec snap : lorsque je trouverai un moment…

    (PEU IMPORTANT) Dans le Centre de contrôle ➜ Apparence ➜ icône “Fenêtres” ➜ onglet “Comportement”, l’option “Sélectionner la fenêtre lorsque la souris est au dessus” est bugué, constaté le 29/07/2019
    Dans le Centre de contrôle ➜ Apparence ➜ icône “Fenêtres” ➜ onglet “Comportement” : ne pas activer l’option “Sélectionner la fenêtre lorsque la souris est au dessus” : car cette option génère des bugs de copie lorsque l’on tente notamment de copier une adresse URL de Firefox vers une autre application (la copie effectuée n’est pas la bonne, n’enregistre pas le Ctrl C courant).
    ➯ Pas de nouveau test dans la période

    (GENANT) Le client Steam ne fonctionne pas, constaté le 17/05/2019
    Le client Linux de Steam est toujours en 32-bit (en version Beta depuis 2002, cf Wikipedia [en])

    Ma configuration:
    Debian Sid 64-bit
    CPU : Intel Core I7
    Carte graphique : GeForce GTX 275 GeForce GTX 260
    RAM : 6Go

    Je n’avais aucun souci à utiliser Steam lorsque ma distribution était encore en 32-bit (sauf que j’avais acheté des jeux en 64-bit :)). Je suis à présent passé en 64-bit et je ne parviens plus à faire fonctionner Steam (c’est ballot).
    J’ai lu plusieurs articles et ai donc installé un certain nombre de bibliothèques 32-bit. Le mieux que j’ai obtenu est le message : « glXChooseVisual failed ».

    Et puis j’ai tenté d’installer une bibliothèque nVidia 32-bit, ce qui a eut pour effet (par le jeu des dépendances) d’installer des tonnes de paquets nvidia (j’ai vu et ai laissé faire, sur un coup de poker) et de casser l’accélération graphique. Je me suis retrouvé en console à désinstaller des dizaines de paquets nvidia un à un (avec des noms à rallonge) et à passer un temps fou en de nombreuses tentatives pour relancer l’accélération graphique car l’installateur plantait (vraisemblablement à cause de conflits avec ces nouveaux paquets nvidia dont certains ne voulaient plus se désinstaller sans désinstaller de nombreux paquets que j’utilise). Bref une horreur pour tout remettre en état, ce qui m’a bien vacciné, je ne suis pas prêt de recommencer.
    J’attends que Steam passe en 64-bit (en quelle année ?).
    Nouveauté le 15/10/19 : j’ai testé le FlatPak de Steam (toujours en 32-bit) et il fonctionne bien ! Il faudra que je teste à nouveau tout ça (Steam sans Flatpak).

    (PEU IMPORTANT) Tootle (le client Mastodon) 0.2.0 plante avec libgranite 5.2.3 lors de son initialisation, depuis le 02/03/2019
    Tootle (le client Mastodon) plante à nouveau sur une erreur « [GLib-GIO] Settings schema ‘io.elementary.desktop.wingpanel.datetime’ is not installed
    Trappe pour point d’arrêt et de trace »

    Un rapport de bug avait été ouvert, l’Issue n°107, qui elle-même semble avoir été mergée avec l’Issue 222 (pour le format d’heure).
    Pour l’instant j’attends en espérant qu’ils résolvent le problème.

    Trouvé le 07/03/19 : c’est encore un coup de la bibliothèque granite.
    Elle a été mise à jour la veille du dysfonctionnement de Tootle.
    Le 01/03/2019 :
    gir1.2-granite-1.0 (5.2.2-1) to 5.2.3-1
    libgranite-common (5.2.2-1) to 5.2.3-1
    libgranite-dev (5.2.2-1) to 5.2.3-1
    libgranite5 (5.2.2-1) to 5.2.3-1

    Pour résoudre cela :
    – téléchargez sur Debian (choisir la version « buster » pour obtenir les paquets dans leur version précédente, en 5.2.2-1) les paquets ci-dessus.
    – lancez en console dans cet ordre (à cause des dépendances), dans le répertoire où vous avez copié les paquets :
    # dpkg -i –force-overwrite libgranite-common_5.2.2-1_all.deb
    # dpkg -i –force-overwrite gir1.2-granite-1.0_5.2.2-1_amd64.deb
    # dpkg -i –force-overwrite libgranite5_5.2.2-1_amd64.deb
    # dpkg -i –force-overwrite libgranite-dev_5.2.2-1_amd64.deb
    Et ça marche !
    Ensuite vous bloquez leur mise à jour pour un moment sous Synaptic :
    Vous filtrez les paquets sur « granite »,
    vous sélectionnez ces 4 paquets,
    Menu Paquet ➜ Bloquer la version
    ➯ Le 31/05/2019 : pas d’amélioration (la nouvelle version 5.2.3 fait toujours planter Tootle).
    ➯ Pas de nouveau test dans la période

    (PEU IMPORTANT) Le COPIER-COLLER ne fonctionne pas sous le gestionnaire de fenêtre Budgie 10.4, constaté le 12/03/2019.

    J’ai de nouveau testé Budgie le 12/03/2019 et ai même failli l’adopter à nouveau en remplaçant de MATE (que j’aime beaucoup), l’histoire de changer un peu, et parce qu’il est vraiment très beau.
    J’avais commencé à le remettre à mon goût.
    Et puis finalement je me suis ravisé parce que pas moyen de faire un COPIER-COLLER, ni par le Ctrl C + Ctrl V ni par la sélection à la souris et le collage par la molette centrale.
    ➯ Pas de nouveau test dans la période

    (IMPORTANT) Le blocage des paquets sous Synaptic v. 0.84-2 est rendu inopérant avec unattended-upgrades v. 0.99, constaté le 12/02/2018.

    J’avais émis un rapport de bug n°#890668 sur le paquet unattended-upgrades v. 0.99, du fait qu’il mettait à jour tous les paquets Debian – y compris les paquets importants et ceux qui étaient bloqués sous Synaptic. Le mainteneur du paquet m’avait alors répondu que ce n’était pas à proprement parlé un bug de unattended-upgrades, mais un changement de comportement réalisé sciemment à sa version 0.99, afin de répondre aux bugs #597061 et
    #787945. Il m’avait aussi précisé que pour bloquer la mise à jour d’un paquet il fallait utiliser la commande : # apt-mark hold (package name).

    M’apprêtant à rédiger un rapport de bug pour Synaptic (pas normal d’avoir une fonction de blocage de paquet qui ne soit pas « waterproof »), j’ai
    constaté qu’un rapport de bug (le n°#276655) intitulé « synaptic: ‘lock version’ harmful; replace with dpkg holds, existait déjà, avec un statut confirmé, et que de plus il n’était pas tout jeune, puisqu’il atteignait l’âge canonique de 10 ans (Thanks for looking into this almost 10 year old bug d’après monsta@inbox.ru).

    Je l’ai donc amandé par une proposition. Pour faire simple, je reprend l’idée qui m’avait été suggérée par le mainteneur du paquet unattended-upgrades en l’appliquant à Synaptic (faire appel à la fonction « apt-mark hold (package name) » pour bloquer les paquets, ce qui permettra d’éviter qu’il ne soient mis à jour par le paquet unattended-upgrades). Malheureusement je ne suis pas sûr que ma suggestion soit audible, vu le nombre de messages avant le mien et l’âge du bug. Je laisse donc ici ce paragraphe et me prépare à ce qu’il reste un bon bout de temps (jusqu’à ce que mort s’en suive :))
    Dans l’attente, j’ai désinstallé le paquet unattended-upgrades. Le responsable de ce paquet m’avait indiqué qu’il essaierait de faire
    quelque-chose pour ce problème (mise à jour d’unattended-upgrades). Donc c’est un point que je regarderais aussi.
    ➯ Le 03/11/2018 j’ai tenté de ré-installer unattended-upgrades dans sa dernière version, mais il me signale :
    bogues de gravité serious sur unattended-upgrades (→ 1.6)
    b1 – #905877 – regression in 1.4: upgrades random packages from testing to experimental (doesn’t respect pinning?)
    b2 – #910874 – unattended-upgrades removes packages even if
    Résumé :
    unattended-upgrades(2 bogues)
    Êtes-vous certain(e) de vouloir installer/mettre à jour les paquets ci-dessus ? [Y/n/?/…] n
    ➯ Le 02/03/2019 : même message avec unattended-upgrades (→ 1.10) le souci est toujours en attente de résolution.
    ➯ Pas de nouveau test dans la période.

    (PEU IMPORTANT) Affichage incomplet du nom des fichiers dans certains répertoires avec Caja et Nautilus, constaté le 01/12/2016.

    Lorsque je visualise le contenu du répertoire /usr/share/applications/ sous Caja ou sous Nautilus, certains fichiers apparaissent en 2, 3 voir 4 exemplaires, ce qui n’est absolument pas le reflet de la réalité.
    Visiblement il s’agit d’un problème d’affichage du raccourci (les noms sont tronqués).
    Exemple des raccourcis Banshee :
    Lorsque je lance en console la commande suivante :
    $ cd /usr/share/applications
    $ ls – l
    (…)
    -rw-r–r– 1 root root 166 juil. 12 2014 bambam.desktop
    -rw-r–r– 1 root root 8842 déc. 10 15:55 banshee-audiocd.desktop
    -rw-r–r– 1 root root 10647 déc. 10 15:55 banshee.desktop
    -rw-r–r– 1 root root 8839 déc. 10 15:55 banshee-media-player.desktop
    -rw-r–r– 1 root root 1792 déc. 22 2015 bareftp.desktop
    (…)
    Il y a 3 raccourcis différents correspondant à banshee. Lorsque je visualise ces raccourcis sous Nautilus ou Caja, il affiche 3 fois de suite le raccourci « Banshee » (il n’affiche pas « -audiocd » ni « -media-player »).
    Voilà un bug mineur parti lui aussi pour fêter ses 10 ans 🙂
    ➯ Pas de nouveau test dans la période.

    (PEU IMPORTANT) L’impression avec CUPS n’est pas fiable sur mon installation, depuis des années (10 ans ?)
    J’ai une imprimante-scanner multifonction EPSON Stylus SX235W. Par périodes tout fonctionne bien, et d’autres – comme en ce moment, je
    lance une impression et rien ne se passe. La technique généralement efficace est de désinstaller l’imprimante sous mon navigateur internet
    (http://localhost:631) : c’est pénible, mon ressenti en tant qu’utilisateur est que je n’arrive jamais à utiliser mon imprimante quand j’en ai besoin.
    SCOOP : En fait la meilleur technique que j’ai trouvé, est de ne plus utiliser mon imprimante 🙂 .
    Gros avantages, çà me coûte moins chère en cartouches d’encre qui sèchent même si je ne les utilise pas, et c’est certainement meilleur pour la planète. Mais il est vrai que c’est agaçant d’avoir un matériel non fonctionnel.

    Déroulement du test (le 01/08/2016, retesté le 26 octobre) : sous Pluma je saisi un petit texte sur le PC du Bottin internet (pour être au plus prêt de l’imprimante), démarre mon imprimante à jet d’encre sur le PC internet, son voyant de fonctionnement clignote puis passe au vert fixe, je lance l’impression, le voyant clignote à nouveau – m’indiquant qu’il a bien reçu les commandes d’impression, mais reste clignotant, il ne se passe rien et aucun message n’est affiché nulle part.
    ➯ Problème confirmé le 12 novembre (PC mis à jour sans Synaptic, via « # apt update » et « # apt upgrade »).
    ➯ Problème confirmé le 3 janvier 2017 : Synaptic est à présent fonctionnel sur ce PC. Pour effectuer un test complet, j’ai renommé le répertoire /etc/cups, réinstallé tous les paquets en rapport avec CUPS sous Synaptic, puis est créé une nouvelle imprimante EPSON Stylus SX 235
    via mon navigateur internet (le fait de réinstaller les paquets et de renommer le répertoire l’avait fait disparaître) à l’adresse http://localhost:631/. Tout semble se dérouler correctement, et pourtant lorsque j’imprime mon fichier de test ou une page de test (Printers>Maintenance>Print test Page), le voyant de l’imprimante clignotte mais rien ne se passe. Sous CUPS l’imprimante apparaît en « Pause, Accepting Jobs, Not Shared » et le job apparaît en « pending since … » et en reste là.
    ➯ Pas de nouveau test dans la période. Néanmoins j’envisage de remplacer les cartouches d’encre car un voyant me signale qu’il faudrait les remplacer. C’est une imprimante à bas coût (quelques dizaines d’euros) : l’affichage est minimaliste, juste des leds. Ce pourrait-il que le manque d’encre bloque l’impression ? A suivre …
    ➯ Pas de nouveau test dans la période (j’ai la flemme de m’y remettre).

    (PEU IMPORTANT) Problème de prévisualisation de plusieurs polices dans le Centre de Contrôle de MATE depuis le 02/07/17.

    J’avais d’abord relevé ce problème avec la police « Droid Sans Fallback », car j’utilisais cette police en taille 10 pour tout l’affichage (Police des applications, Police des documents, …) sous mon gestionnaire de fenêtre (sauf pour la Police à chasse fixe, pour laquelle je lui préférais la « Terminus Regular 10 ».
    Constat : la police « Droid Sans Fallback » s’affiche correctement, mais lorsqu’on la sélectionne dans le menu (« Centre de Contrôle » puis « Apparence » puis onglet « Polices » puis « Police des applications : » puis vous cliquez sur la police en cours pour sélectionner une autre police) « Choisissez une police », des signes cabalistiques s’affichent à la place de la prévisualisation de la police (lors de la présentation de l’exemple de texte « Voix ambiguë d’un cœur qui, au zéphyr, préfère les jattes de kiwis. »).

    Mais le problème apparait aussi avec bien d’autres polices : Linux Libertine Initials, MathJax, Noto Naskh Arabic, Noto Sans xxx, OpenSymbol, PowerlineSymbols, Standard Symbols, Unifont, …
    Je ne les utilise pas directement, mais elles sont installées par des jeux ou utilitaires que j’utilise.

    Pour le cas de la police « Droid Sans Fallback » par exemple, celle-ci est livrée avec le paquet « fonts-droid-fallback ». Il s’agit visiblement d’une police pour périphérique portable, issue de Google Android.
    À présent je ne l’utilise plus (j’utilise la police « Cantarell » installée par défaut et satisfaisante), mais elle reste utilisée et installée par Wesnoth et Minetest.
    C’est aussi le cas pour les polices de caractère citées ci-avant.
    Elles sont installées via des paquets que l’on ne peux désinstaller sans désinstaller également les jeux et utilitaires qui en dépendent.
    ➯ Pas de nouveau test dans la période.

    (PEU IMPORTANT) Problème de fiabilité des économiseurs d’écran sous Linux (ils ont tendance à tout faire planter), depuis l’existence d’Xorg vraisemblablement.

    Pas important mais dommage. J’aime beaucoup les économiseurs d’écrans (il y en a quelques-uns assez sympa, même s’ils ne valent pas ceux de Windows, je me souviens d’un, que j’adorais, avec un graphisme tout mimi, façon dessin animé, dans lequel un gars sur son île déserte pêchait des chaussures et dormait sur son hamac lorsqu’un bateau passait au large, et plein d’autres trucs amusants que je ne me lassais pas de regarder :).
    ➯ Le 14/10/2018 j’ai testé les économiseurs d’écran sous Debian 64-bit et MATE : les économiseurs OpenGL ont tendance à tout faire planter (j’ai retrouvé le système bloqué à plusieurs reprises, m’obligeant à redémarrer). Je pense qu’il y aurait besoin d’un bon coup de ménage dans ces économiseurs. Pour l’instant je les ai désactivé.
    ➯ Le 26/05/2019 Idem sur le PC Internet en 32bit. Je n’arrive même plus à désactiver l’économiseur en cours car à chaque fois que je vais dans le Centre de configuration et lance l’appli correspondante, l’économiseur s’affiche et fait planter l’appli (elle reste figée).
    ➯ Pas de nouveau test dans la période.

    Il reste encore quelques bugs – plus ou moins agaçants, mais, terminons sur une note positive : le plus important fonctionne. Un grand merci pour cela.