L’observatoire du fonctionnement de ma Debian Testing (MàJ: 24 octobre 2020)

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 (gestion du RAID logiciel) 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).
• Depuis lors, 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

• Et le 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 (20/10/2020 ➤ 24/10/2020) : ☔
(🔆 ⛅ ☔ 💥)

Résumé des changements :

– ☔ Plus aucun noyau récent ne fonctionne sur mon PC, ça en devient inquiétant (testé dans la période : le noyau linux-image-5.9.0-1-amd64 : même comportement, le démarrage se fige).

– ⛅ La navigation sous Tellico est toujours très lente depuis cet été (15/07/20) après la mise à jour de Qt (v.5.12 à 5.14, problème signalé seulement maintenant, mais ça ne s’est pas amélioré).

– 🔆 Peu/Pas de changements 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.

(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 a été publiée début Juillet 2019, au moins pour quelques mois (années ?) il me semble pertinent de ne pas tout mettre à jour sans un bénéfice certain et de passer à Debian testing. Je maintien une mise à jour quotidienne sous Synaptic mais uniquement des paquets de la section « Nouvelle version amont du logiciel » (que l’on trouve en cliquant sur le bouton « Filtres personnalisés »).

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 (et dans un idéal, 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 quotidienne sous Synaptic des paquets de la section « Nouvelle version amont du logiciel » (que l’on trouve en cliquant sur le bouton « Filtres personnalisés ») : 1 année et env. 3 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).
  • Pour ne pas encombrer davantage cette page, j’ai regroupé cet historique ici : Historique du fonctionnement de ma Debian Testing

    Bilan de la période

    Les points positifs (dysfonctionnements résolus, nouveautés) dans la période du 20 octobre 2020 au 24 octobre 2020 :

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

    Les points négatifs (dysfonctionnements) dans la période du 20 octobre 2020 au 24 octobre 2020 :

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

    Quelques applications sympas testées dans la période du 20 octobre 2020 au 24 octobre 2020 :

    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 dans la période.

     


    Dysfonctionnements toujours d’actualité

    (GÊNANT) La navigation sous Tellico est devenue très lente depuis cet été après des mises à jour de Qt (v.5.12 à 5.14), constaté le 15/07/2020.
    La navigation sous Tellico est devenue très lente depuis cet été après une mise à jour de Qt (problème signalé seulement maintenant, mais ça ne s’est pas amélioré).
    J’ai pensé que le problème allait être corrigé dans les jours / semaines à venir, mais ça n’a pas été le cas. À la longue la navigation sous Tellico est rendue assez pénible. Alors qu’avant cette mise à jour elle était agréable et rapide (je suis certain que ce n’est pas un souci physique avec mon SSD / temps de chargement des images lié à la taille de la base, mais bien d’un souci lié à Qt).

    Ce qui a été mis à jour :

    Commit Log for Wed Jul 15 09:23:41 2020

    Les paquets suivants ont été mis à jour :
    dde-qt5integration (5.0.0-1+b1) to 5.0.0-2+b1
    desktop-file-utils (0.24-1) to 0.26-1
    hedgewars (1.0.0-4+b2) to 1.0.0-8
    kwin-common (4:5.17.5-2) to 4:5.17.5-2+b1
    kwin-x11 (4:5.17.5-2) to 4:5.17.5-2+b1
    libdtkwidget2 (2.1.1-1+b1) to 2.1.1-1+b2
    libfm-qt6 (0.14.1-12) to 0.14.1-12+b1
    libkf5xmlgui5 (5.70.0-1) to 5.70.0-1+b1
    libkwin4-effect-builtins1 (4:5.17.5-2) to 4:5.17.5-2+b1
    libkwineffects12 (4:5.17.5-2) to 4:5.17.5-2+b1
    libkwinglutils12 (4:5.17.5-2) to 4:5.17.5-2+b1
    libkwinxrenderutils12 (4:5.17.5-2) to 4:5.17.5-2+b1
    libqt5concurrent5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5core5a (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5dbus5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5designer5 (5.12.5-2+b2) to 5.14.2-2
    libqt5gui5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5help5 (5.12.5-2+b2) to 5.14.2-2
    libqt5multimedia5 (5.12.5-1+b1) to 5.14.2-2
    libqt5multimedia5-plugins (5.12.5-1+b1) to 5.14.2-2
    libqt5multimediagsttools5 (5.12.5-1+b1) to 5.14.2-2
    libqt5multimediawidgets5 (5.12.5-1+b1) to 5.14.2-2
    libqt5network5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5networkauth5 (5.12.5-1) to 5.14.2-2
    libqt5opengl5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5opengl5-dev (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5positioning5 (5.12.5+dfsg-5) to 5.14.2+dfsg-2
    libqt5printsupport5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5qml5 (5.12.5-5) to 5.14.2+dfsg-2
    libqt5quick5 (5.12.5-5) to 5.14.2+dfsg-2
    libqt5quickcontrols2-5 (5.12.5+dfsg-2+b1) to 5.14.2+dfsg-2
    libqt5quickshapes5 (5.12.5-5) to 5.14.2+dfsg-2
    libqt5quicktemplates2-5 (5.12.5+dfsg-2+b1) to 5.14.2+dfsg-2
    libqt5quickwidgets5 (5.12.5-5) to 5.14.2+dfsg-2
    libqt5script5 (5.12.5+dfsg-2) to 5.14.2+dfsg-2
    libqt5scripttools5 (5.12.5+dfsg-2) to 5.14.2+dfsg-2
    libqt5sensors5 (5.12.5-2+b1) to 5.14.2-2
    libqt5serialport5 (5.12.5-1) to 5.14.2-2
    libqt5sql5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5sql5-mysql (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5sql5-sqlite (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5svg5 (5.12.5-2) to 5.14.2-2
    libqt5test5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5texttospeech5 (5.12.5-1) to 5.14.2-2
    libqt5virtualkeyboard5 (5.12.5+dfsg-2) to 5.14.2+dfsg-2
    libqt5waylandclient5 (5.12.5-2+b1) to 5.14.2-2
    libqt5waylandcompositor5 (5.12.5-2+b1) to 5.14.2-2
    libqt5webchannel5 (5.12.5-2) to 5.14.2-2
    libqt5webengine-data (5.12.5+dfsg-7) to 5.14.2+dfsg1-2
    libqt5webengine5 (5.12.5+dfsg-7+b1) to 5.14.2+dfsg1-2
    libqt5webenginecore5 (5.12.5+dfsg-7+b1) to 5.14.2+dfsg1-2
    libqt5webenginewidgets5 (5.12.5+dfsg-7+b1) to 5.14.2+dfsg1-2
    libqt5webkit5 (5.212.0~alpha4-1) to 5.212.0~alpha4-4
    libqt5widgets5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5xdg3 (3.4.0-1) to 3.4.0-1+b1
    libqt5xdgiconloader3 (3.4.0-1) to 3.4.0-1+b1
    libqt5xml5 (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    libqt5xmlpatterns5 (5.12.5-1) to 5.14.2-2
    lxqt-qtplugin (0.14.0-3+b1) to 0.14.0-3+b2
    plasma-integration (5.17.5-2) to 5.17.5-2+b1
    python3-pyqt5 (5.15.0+dfsg-1) to 5.15.0+dfsg-1+b1
    python3-pyqt5.qtsvg (5.15.0+dfsg-1) to 5.15.0+dfsg-1+b1
    qdbus-qt5 (5.12.5-2+b2) to 5.14.2-2
    qml-module-org-kde-analitza (4:20.04.2-1) to 4:20.04.2-1+b1
    qml-module-qtgraphicaleffects (5.12.5-2+b1) to 5.14.2-2
    qml-module-qtqml-models2 (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qtquick-controls (5.12.5-1+b1) to 5.14.2-2
    qml-module-qtquick-controls2 (5.12.5+dfsg-2+b1) to 5.14.2+dfsg-2
    qml-module-qtquick-dialogs (5.12.5-1+b1) to 5.14.2-2
    qml-module-qtquick-extras (5.12.5-1+b1) to 5.14.2-2
    qml-module-qtquick-layouts (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qtquick-privatewidgets (5.12.5-1+b1) to 5.14.2-2
    qml-module-qtquick-shapes (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qtquick-templates2 (5.12.5+dfsg-2+b1) to 5.14.2+dfsg-2
    qml-module-qtquick-window2 (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qtquick2 (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qtwebengine (5.12.5+dfsg-7+b1) to 5.14.2+dfsg1-2
    qml-module-qtwebkit (5.212.0~alpha4-1) to 5.212.0~alpha4-4
    qt5-default (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    qt5-gtk-platformtheme (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    qt5-gtk2-platformtheme (5.0.0+git23.g335dbec-3+b3) to 5.0.0+git23.g335dbec-3+b4
    qt5-qmake (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    qt5-qmake-bin (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    qt5-style-plugin-cleanlooks (5.0.0+git23.g335dbec-3+b3) to 5.0.0+git23.g335dbec-3+b4
    qt5-style-plugin-motif (5.0.0+git23.g335dbec-3+b3) to 5.0.0+git23.g335dbec-3+b4
    qt5-style-plugin-plastique (5.0.0+git23.g335dbec-3+b3) to 5.0.0+git23.g335dbec-3+b4
    qt5-style-plugins (5.0.0+git23.g335dbec-3+b3) to 5.0.0+git23.g335dbec-3+b4
    qt5dxcb-plugin (5.0.1-3) to 5.0.1-3.1+b1
    qtbase5-dev (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    qtbase5-dev-tools (5.12.5+dfsg-9) to 5.14.2+dfsg-4
    qtscript5-dev (5.12.5+dfsg-2) to 5.14.2+dfsg-2
    qtwayland5 (5.12.5-2+b1) to 5.14.2-2
    xterm (356-1) to 357-1

    Les paquets suivants ont été installés :
    libmd4c0 (0.4.4-1+b1)
    libqt5qmlmodels5 (5.14.2+dfsg-2)
    libqt5qmlworkerscript5 (5.14.2+dfsg-2)
    qml-module-qtqml (5.14.2+dfsg-2)

    puis :
    Commit Log for Wed Jul 15 09:30:19 2020

    Les paquets suivants ont été mis à jour :
    libqt5charts5 (5.12.5-2+b1) to 5.14.2-2
    libqt5multimediaquick5 (5.12.5-1+b1) to 5.14.2-2
    libqt5x11extras5 (5.12.5-1) to 5.14.2-2
    qml-module-qt-labs-folderlistmodel (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qt-labs-settings (5.12.5-5) to 5.14.2+dfsg-2
    qml-module-qtmultimedia (5.12.5-1+b1) to 5.14.2-2
    qml-module-qtquick-virtualkeyboard (5.12.5+dfsg-2) to 5.14.2+dfsg-2
    qt5-image-formats-plugins (5.12.5-1) to 5.14.2-2
    qtspeech5-flite-plugin (5.12.5-1) to 5.14.2-2
    qttranslations5-l10n (5.12.5-1) to 5.14.2-2
    ↪ Pas d’amélioration dans la période.

    (INQUIÉTANT) Les derniers noyaux 64-bit disponible en dépôt (le 5.7 puis le 5.8, et le 5.9) ne fonctionnent pas sur mon PC le plus récent (il se fige au démarrage)., constaté le 15/07/2020 (environ, de mémoire approximative).
    Le noyau 5.7 64-bit ne fonctionne toujours pas sur mon PC (il se fige au démarrage).
    Versions testées :
    – linux-image-5.7.0-2-amd64, version 5.7.10-1
    – linux-image-5.7.0-3-amd64, version 5.7.17-1
    – linux-image-5.8.0-1-amd64, version 5.8.7-1
    – linux-image-5.9.0-1-amd64, version 5.9.1-1

    Au démarrage du noyau le dernier message affiché est le suivant :
    (…)
    sp5100-tco: watchdog hardware is disabled
    iwlwifi 0000:17:00.0: firmware: failed ti load iwl-debug-yoyo.bin (-2)
    firmware_class: see https://wiki.debian.org/firmware for information about missing firmware »
    Un firmware nécessaire au démarrage de mon PC n’a visiblement pas été sélectionné par le mainteneur Debian du paquet du noyau (je connais un peu le problème pour avoir moi-même compilé mes noyaux il y a quelques années. Et là la difficulté est encore plus grande car il faut trouver une configuration qui convienne à la majorité des PC).

    Un bug est ouvert « firmware: failed to load iwl-debug-yoyo.bin (-2) » mais il ne semble pas être bloquant pour le démarrage. Je ne comprend pas ce qui bloque…

    Ce dysfonctionnement ne m’empêche pas pour l’instant de démarrer mon PC car le noyau 5.6 fonctionne bien, néanmoins plus aucun noyau récent ne fonctionnant sur mon PC, ça en devient inquiétant.
    ↪ Testé dans la période : le noyau linux-image-5.9.0-1-amd64 : même comportement, le démarrage se fige, avec les messages ci-dessus, et un petit rectangle blanc apparaît après une trentaine de secondes. Mais que fait le mainteneur Debian du noyau ? :(

    (PEU IMPORTANT) Le filtre « Nouvelle version amont du logiciel » sous Synaptic affiche aussi les paquets bloqués, constaté le 01/07/2020 (et même bien avant).

    J’utilise le filtre « Nouvelle version amont du logiciel » sous Synaptic pour ne mettre à jour que les logiciels ayant une version officielle mise à jour. Je sélectionne quotidiennement tous les paquets de ce filtre (par un Ctrl « A ») et je lance la mise à jour.
    Problème, le filtre affiche aussi les paquets bloqués, qui se trouvent ainsi mis à jour avec cette opération.
    Les paquets bloqués ne devraient pas apparaître dans ce filtre.
    Puisqu’on a bloqué ces paquets, le comportement attendu est qu’ils soient ignorés par les filtres, même si une mise à jour est disponible (parce que l’on sait qu’une mise à jour est disponible et qu’elle est bugée).
    ↪ Pas de changement dans la période.

    (PEU IMPORTANT) La zone de notification du bureau MATE v.1.24.0 n’affiche pas certaines applications, constaté le 01/07/2020 (et même bien avant).

    En testant KDE, je constate que toutes les applications s’affichent correctement dans la zone de notification des applications, alors que ce n’est pas le cas sous MATE, notamment pour les applications : Clémentine et QuiteRSS.
    ↪ Pas de changement dans la période.

    (IMPORTANT) Un seul noyau fonctionnel (le 4.9.0-12-amd64 avec le pilote du site nvidia v.340.108, et aucun avec le pilote propriétaire des dépôts v.340.108-5) pour l’accélération graphique sur le PC Internet depuis le 26/04/20.

    Configuration : CPU Intel i7 920 et carte graphique nVidia GTX 275

    Le PC Internet (je l’appelle ainsi parce qu’il me sert de passerelle) ayant rendu l’âme (encéphalogramme plat, un matin il a décidé de ne plus démarrer alors qu’il fonctionnait jusque là, seule une petite led s’allumait sur la carte mère, me signalant qu’elle recevait au moins un peu d’alimentation), j’ai remplacé la plupart de ses composants par d’autres plus récents (carte mère avec CPU Intel i7 920 + 6GB, carte graphique nVidia GTX 275, alim & écran, provenant tous anciennement du PC du Bottin, boîtier provenant de mon ancien 3ème PC qui n’existe plus), ne conservant que les disques (et encore j’ai fini par les remplacer par un seul d’1 To, et j’ai aussi fini par upgrader la mémoire à 16GB).

    Problème, je me suis rendu compte que l’accélération graphique ne fonctionnait pas correctement avec le driver des dépôts (v.340.108-5, Spring Zero-K tournait à 3-4 FPS). J’ai donc installé le driver propriétaire du site NVidia (v.340.108). Mais là grosse difficulté pour associer ce driver avec un noyau fonctionnel. J’ai testé le 4.19.0-8-amd64, le 5.5.0-2-amd64, le 5.6.0.1-amd64 et aucun ne fonctionne, j’ai des erreurs, le pilote plante. Le seul qui ait accepté de fonctionner est le 4.9.0-12-amd64 (ouf). J’ai ré-essayé d’installer le pilote des dépôts avec le noyau 5.6.0.1-amd64, et j’ai bien cru qu’il allait fonctionner, car il me permet d’avoir un bureau fonctionnel, mais là aussi il est décevant, il fait planter glxgears (qui affiche un problème de fenêtre). Donc je suis revenu au noyau 4.9.0-12-amd64 et le pilote du site Nvidia. Mais j’aimerai bien avoir plus d’un noyau fonctionnel sur ce PC, avec un noyau plus récent si possible. Il m’est déjà arrivé en effet qu’après une mise à jour, le noyau précédent qui fonctionnait refuse de fonctionner.

    Pour info, sur le PC du Bottin (avec sa nvidia RTX 2070, et non pas le PC Internet) j’ai testé le noyau 5.6.0-1-amd64 (tout récent dans les dépôts Debian Testing) avec le driver Nvidia v.440.31, ce dernier ne parvient pas à compiler le driver (ce qui confirme des changements incompatibles avec les anciens drivers). Ensuite j’ai testé ce même noyau avec le dernier driver téléchargé à l’instant : le driver Nvidia v.440.82 se compile bien avec ce noyau !

    Ça ne résout pas le problème sur le PC Internet, mais ça me confirme que des changements récents nécessitent de nouveaux drivers Nvidia qui ne sont pas encore disponibles pour les anciennes cartes graphiques (donc un driver > v.340.108 dans la série des 340.xx).

    ➯ Nouveau test le 21/05/2020 : le noyau 4.19.0-9-amd64 semble fonctionner sans trop d’erreurs sur ce PC (les autres noyaux généraient 2-3 messages d’erreurs bizarres au démarrage).
    Malheureusement :
    – le pilote nvidia v.340.108 refuse toujours de se compiler avec ce noyau 4.19.0-9-amd64,
    – le mainteneur Debian des noyaux s’obstine à compiler ses noyaux avec gcc/g++ v.8.3, alors que la version installée par défaut est la v.8.4 (ce qui oblige à lancer la commande : # apt install gcc-8=8.3.0-6 cpp-8=8.3.0-6 gcc-8-base=8.3.0-6 libgcc-8-dev=8.3.0-6 libmpx2=8.3.0-6). On en vient à espérer qu’il se décide à passer à un gcc plus récent, ou qu’il maintienne la bonne version de gcc installée par défaut (l’impression actuelle est celle d’avoir 2 jambes dont chacune fait ce qu’elle veut : pas facile d’avancer).
    J’attend la mise à jour du pilote nvidia 340.xx en version >340.108 (depuis le 26/04/20).
    ↪ Pas de nouveau test dans la période.

    (PEU IMPORTANT) Dysfonctionnement du curseur de la souris lors du déplacement d’une fenêtre d’un écran à l’autre, au démarrage du bureau, sous MATE v.1.24.0/Marco depuis le 01/01/2019 (et même avant).

    Je ne sais pas situer la date d’observation de ce dysfonctionnement. Ce qui est sûr c’est qu’il est ancien. Je ne l’avais pas signalé parce qu’il y avait d’autres dysfonctionnements bien plus gênants.
    De plus il ne se produit qu’au démarrage du bureau, et uniquement sous MATE (voir ci-après), pendant quelques minutes. Ce qui semble indiquer qu’il est en lien avec la dynamique de démarrage des applications (saturation des communication d-bus faisant perdre l’acquisition du déplacement de la souris ?).

    Après avoir testé KDE (en Juin 2020), je constate que le bug est spécifique à MATE v.1.24.0, car sous KDE il n’y a pas ce souci.

    Descriptif :
    Lorsque l’on déplace (drag&drop) plus ou moins rapidement une fenêtre d’un écran à l’autre avec la souris (ce que j’effectue tous les jours car les fenêtres sont systématiquement en désordre) au démarrage du bureau, le curseur de la souris prend de l’avance (alors qu’il se trouvait sur le bord de l’interface, il glisse vers la droite d’1/2 écran – si le déplacement s’effectue vers l’écran droit) et en venant sur le bord de l’écran déclenche le passage de la fenêtre en pleine hauteur.
    ↪ Pas d’amélioration dans la période.

    (PEU IMPORTANT) Le bureau MATE v.1.24.0 mémorise mal l’emplacement et la taille de certaines fenêtres lorsque l’on quitte le bureau depuis le 01/01/2019 (et même avant).

    Là aussi, je ne sais pas situer la date d’observation de ce dysfonctionnement. Ce qui est sûr c’est qu’il est ancien. Je ne l’avais pas signalé parce qu’il y avait d’autres dysfonctionnements bien plus gênants.

    Avec l’augmentation de la taille et du nombre d’écrans, on prend vite l’habitude d’utiliser l’un des écrans pour afficher nos applications préférées, et l’autre pour une activité plus variée.
    Dans le Centre de contrôle puis « Applications au démarrage » j’ai sélectionné un certain nombre d’application que je souhaite démarrer systématiquement à l’ouverture du bureau MATE.

    Le comportement attendu lorsque l’on quitte le bureau, est que le gestionnaire de fenêtre prenne en charge la sauvegarde de l’emplacement et de la taille des applications en cours afin qu’au démarrage suivant elles s’ouvrent dans les mêmes conditions (taille et disposition).

    Le comportement observé est que certaines applications sont correctement mémorisées (Firefox, Qps, Gkrellm), mais la plupart ne le sont pas ou partiellement (parfois la taille mais pas la position) : Caja, Gedit, Tootle, Stacer, Tilix, PulseEffects,…

    Le fait de cocher ou non « Se souvenir automatiquement des applications en cours d’exécution lors de la déconnexion » dans le Centre de Contrôle puis « Applications au démarrage » puis onglet « Options », ne change rien à ce problème : cela déclenche effectivement la mémorisation des applications lancées, mais pas la disposition des fenêtres.

    Ce n’est qu’un petit dysfonctionnement, mais il se produit à chaque démarrage, ce qui le rend ennuyeux à la longue.
    ↪ Pas d’amélioration dans la période.

    (PEU IMPORTANT) L’utilitaire de recherche dynamique de paquets (apt-xapian-index v. 0.50) sous Synaptic n’est pas fiable, constaté le 29/02/2020 (et même bien avant).

    Là aussi, cela fait déjà pas mal de temps que je constate ce dysfonctionnement mais ne le signale que maintenant.
    Il y a quelques mois je me souviens que je me plaignais que Synaptic mobilisait énormément le disque dur de mon PC pour mettre à jour sa liste de paquets. À présent il ne mobilise plus le disque dur de mon PC mais il n’est plus fiable.

    Lorsque j’effectue des recherches de paquets (cela m’arrive assez souvent) sous l’interface de Synaptic, il est fréquent qu’apt-xapian-index ne les trouve pas. Après vérification je constate qu’ils sont bien là mais qu’apt-xapian-index ne les a tout simplement pas trouvé.
    ➯ Le 21/03/2020 : pas de nouveau test dans la période (j’ai utilisé synaptic à de nombreuses reprises, mais n’ai pas effectué de test sur cette fonctionnalité)
    ➯ Le 10/05/2020 : même constat. Je fais une recherche de noyau en filtrant sur « linux- » ça fonctionne, et puis je modifie légèrement le filtre et il ne trouve plus rien. Néanmoins ce n’est pas systématique, j’ai parfois du mal à reproduire le bug.
    ↪ Pas de nouveau test dans la période.

    (PEU IMPORTANT) « Plan de sauvegarde à 5 min » sous Kup corrompu (kup-backup 0.7.1+dfsg-1+b2 des dépôts Debian), constaté le 21/12/2019.
    Depuis mes soucis (et la complexité d’utilisation) avec le RAID logiciel (mdadm) j’utilise Kup pour la sauvegarde de mes données (voir le WIKI du Bottin, je l’ai largement décris et testé).
    Dans mon « plan de sauvegarde à 5min » (une sauvegarde de quelques répertoires spécifiques à 5 min d’intervalle), je sauvegarde notamment le répertoire ~./mozilla. Ce matin je constate que Firefox a encore perdu ses onglets au démarrage.
    Je tente de récupérer une précédente sauvegarde du répertoire de Firefox avec Kup mais constate que celui-ci ne parvient plus à lire ce plan de sauvegarde à 5 min (l’interface plante au démarrage). Ce plan de sauvegarde étant incrémental, il nécessite une interface spécifique pour être lu. J’ai essayé différentes choses, mais le constat est que je ne peux pas lire ces sauvegardes et qu’elles sont perdues.

    Les messages :
    org.kde.kcoreaddons: Failed to establish shared memory mapping, will fallback to private memory -- memory usage will increase
    Icon theme "eSuru++" not found.
    Fontconfig error: Cannot load default config file
    kf5.kconfig.core: couldn't lock local file

    Je n’ai finalement rien perdu car Kup est parvenu à lire l’autre plan de sauvegarde à 3j (donc nettement moins récent) et j’ai ainsi pu récupérer mes onglets (avec quelques pertes, mais vites reconstituées).

    Autre bug constaté : si l’on duplique le plan de sauvegarde, l’idée est donc de récupérer le paramétrage précédent et l’on pense donc que celui-ci est totalement indépendant. Sauf que (surprise) si l’on supprime le plan initial on perd aussi la copie au démarrage suivant !
    Vous pouvez donc dupliquer un plan de sauvegarde mais pas le supprimer sans perdre aussi les plans de sauvegarde fils/filles.

    Conclusion :
    – éviter de créer les plans de sauvegarde par duplication, car si vous supprimez le plan original (à l’occasion d’une réorganisation de plan par exemple) les autres plans fils/filles seront également supprimés
    – il faut vérifier manuellement de temps en temps que ces plans de sauvegarde ne sont pas corrompus (j’avais pourtant activé la vérification automatique mais visiblement ça ne suffit pas).
    – j’ai rapproché mon « plan de sauvegarde à 3j » en « plan de sauvegarde à 2j »
    – j’ai ajouté un 3ème plan de sauvegarde à 1h d’utilisation, et en clair (copie conforme sans incrément), avec demande de validation de la sauvegarde. Cette sauvegarde est non incrémentale, ce qui fait que Kup écrasera sa précédente sauvegarde spécifique à ce plan (dans un répertoire séparé) après 1h d’utilisation, mais cette sauvegarde est sous condition de validation de ma part (donc si je constate quelque-chose d’anormal, j’ai une chance d’éviter d’écraser la précédente sauvegarde).
    – j’ai ajouté une sauvegarde via Kbackup sur le même périmètre à 1j d’intervalle.
    J’espère ainsi sécuriser davantage mes données.

    L’erreur s’est produite plusieurs fois dans la période (du 21 au 31 décembre 2019). Je me demande si ce qui la déclenche ne serait pas des opérations de copie / modification de fichiers simultanément au backup en cours.
    Il est vrai que cela représente pas mal de copies : le PC restant allumé la journée quand je suis chez moi, chaque jour représente près d’une (8hx60/5=) centaine de copie rien que pour ce plan de sauvegarde. Difficile pour l’instant d’isoler le problème.

    Voici les messages :
    Kup is starting bup backup job at mardi 31 décembre 2019 18:50:15 CET

    bup "-d" "/mnt/Svg1/Kup/Kup5min" "init"
    bup "-d" "/mnt/Svg1/Kup/Kup5min" "fsck" "--quick"
    bup "-d" "/mnt/Svg1/Kup/Kup5min" "index" "-u" "--exclude" (...)
    bup "-d" "/mnt/Svg1/Kup/Kup5min" "save" "-n" "kup" "-vv" "/home/goupil2/.mozilla" (...)
    Traceback (most recent call last):
    File "/usr/lib/bup/cmd/bup-save", line 377, in
    meta.hardlink_target = find_hardlink_target(hlink_db, ent)
    AttributeError: 'NoneType' object has no attribute 'hardlink_target'

    Kup did not successfully complete the bup backup job: failed to save everything.

    J’ai aussi eut ce type de messages le lendemain (pour le plan de sauvegarde 1h déclenché peu de temps après (1 min?) le démarrage du bureau (effectivement, il est probable que Firefox n’était pas encore stabilisé dans son démarrage, mais ça ne me semble pas une raison valable pour planter sa sauvegarde) :

    (...)
    file has vanished: "/home/goupil2/.mozilla/firefox/fhsilo00.default/storage/default/moz-extension+++8fd4d539-c0c1-4ceb-9848-7e87316f11fc^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal"

    file has vanished: "/home/goupil2/.mozilla/firefox/fhsilo00.default/storage/default/moz-extension+++dab33424-0f0c-416d-9fe4-558ce21ce909^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal"

    file has vanished: "/home/goupil2/.mozilla/firefox/fhsilo00.default/storage/permanent/chrome/idb/1657114595AmcateirvtiSty.sqlite-wal"
    rsync warning: some files vanished before they could be transferred (code 24) at main.c(1207) [sender=3.1.3]

    Kup did not successfully complete the rsync backup job.

    Ma manœuvre de contournement a jusqu’ici consisté à dupliquer le plan de sauvegarde, en choisissant pour cette copie le même répertoire de sauvegarde que l’original et ça a fonctionné x fois !
    Mais ce soir ça ne fonctionne plus (???). J’ai recréé un nouveau plan de sauvegarde (après avoir perdu la programmation du 1er, voir plus haut) auquel j’ai donné un autre répertoire : ça fonctionne à nouveau (mais ça ne me satisfait pas sur la durée).

    ➯ Le 15/01/2020 : je suis parvenu à atténuer le problème :
    – en décalant le démarrage de Kup. En effet je démarre Kup depuis MATE et il démarrait peu de temps après firefox. Or le souci vient la plupart du temps (tout le temps ?) du fait qu’au démarrage Firefox supprime des fichiers de travail que Kup avait eut le temps d’identifier. Comme j’ai activé son option de vérification de la sauvegarde, il voit que la sauvegarde est en écart par rapport à l’original et s’arrête / se bloque / plante (ce qui n’est pas un bon comportement : il devrait se contenter de signaler le problème et poursuivre). Sous MATE, dans le Centre de Contrôle ➜ Applications au démarrage, pour le démarrage de Kup, j’ai retenu un délai de 100 secondes (le maxi). Après cela les plantages sont beaucoup plus rares.
    – en changeant de temps en temps de répertoire de sauvegarde (alternativement Kup5min/ puis Kup5minSuite/)

    ➯ Le 31/01/2020 : pas d’amélioration significative dans la période (il n’y a pas eu de mise à jour de Kup dans la période non plus). De temps en temps il plante, du coup je n’ai pas une confiance très grande dans ce système. J’augmente la fiabilité en dédoublant les sauvegardes, mais ça augmente l’utilisation des disques. Je fais avec, dans l’attente d’une amélioration ou d’une autre solution plus fiable.
    ➯ Le 29/02/2020 : étonnant, je n’ai pas constaté (de mémoire) de signalisation de plantage de Kup dans la période. Pourtant il poursuit ses sauvegardes quotidiennes. Mais lorsque je souhaite consulter les sauvegardes, je constate qu’il est planté, il ne les affiche pas et en console j’ai le message « kf5.kconfig.core: couldn’t lock local file ». Il n’est vraiment pas fiable …
    ➯ Le 16/03/2020 : après un plantage des onglets de Firefox suite à son upgrade, j’ai eut besoin des sauvegardes de Kup. Force est de constater leur inefficacité : alors que j’avais plusieurs plans de sauvegardes plus ou moins rapprochés, la plupart étaient plantés (la fenêtre s’ouvre mais rien ne s’affiche dedans). Une calamité. La seule qui était viable était une sauvegarde en clair, mais elle datait, et curieusement (changement de version de Firefox entre deux) Firefox n’en voulait aucune, à chaque essai, Firefox démarrait sans aucun onglet sauvegardé. Finalement je n’ai dû ma bouée de sauvetage qu’à une copie manuelle du répertoire qui datait un peu (encore un coup de bol). J’ai quand-même encore perdu quelques entrées de jeu à venir dans le Bottin.
    ➯ Le 28/03/2020 : j’ai désactivé Kup parcequ’il m’énerve, en me signalant tout le temps qu’il ne parvient pas à faire ses sauvegardes, et même quand il ne dit rien, le constat est que ses sauvegardes ne sont pas fiables, en version incrémentales elles finissent par devenir inaccessibles avec son outil de consultation. Bref, beaucoup de consommation disque pour un résultat minable, j’abandonne cet outil pour l’instant (dans cette version 0.7.1). J’y reviendrai probablement dans une version ultérieure s’il fait des progrès significatifs en devenant fiable.
    Là aussi j’ai mis le WIKI à jour.
    ↪ Pas de nouveau test dans la période (je ne l’utilise plus).

    (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 bugé, 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.

    (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.
    ➯ Le paquet unattended-upgrades est passé en version 1.15, il faudra que je fasse un nouveau test (pour l’instant j’ai un nouveau système, les anciens paquets bloqués ne le sont plus).
    ➯ Le 26/11/2019 : j’ai constaté que le paquet unattended-upgrades était installé (par erreur, car non souhaité) sur ma distribution après un plantage de l’accélération graphique.
    unattended-upgrades avait en effet provoqué l’installation d’un nouveau noyau sans son fichier d’entête (header), et sans qu’il s’en suive la compilation d’un nouveau pilote graphique (nvidia propriétaire, dans mon cas). De toute façon, même si la compilation d’un nouveau pilote graphique avait été déclenché, ça n’aurait pas fonctionné car le nouveau noyau requérait le changement de la version gcc utilisée par défaut (le précédent requérait gcc-6, le nouveau 5.3.0-2-amd64 requiert gcc-9, ce qui n’avait pas été fait par les scripts d’installation).
    Tout ceci fonctionnera peut-être un jour, mais pour l’instant (en Décembre 2019), ces mises à jour en automatique me semblent prématurées (par manque de maturité de l’installation des noyaux et des pilotes graphiques) : l’installation du pilote nvidia par les paquets des dépôts Debian ne fonctionne plus pour moi (c’est la raison pour laquelle j’utilise le pilote du site nvidia) et ce pilote des dépôts Debian est franchement d’un niveau moindre que celui d’nvidia (peu verbeux pour expliquer ce qu’il manque quand il ne parvient pas à compiler, on a clairement pas envie d’aller voir un fichier de log dans le sombre recoin d’un sous-répertoire, on veut des messages simples à l’écran, on veut aussi qu’il se débrouille pour trouver – voir installer, la version de gcc nécessaire, de plus il est moche avec tous ses messages illisibles qui défilent, il suffirait dans un premier temps de copier le comportement de celui d’nvidia – qui pourtant lui aussi est en mode texte, et de l’améliorer encore, mais rien n’est fait).
    Donc pour l’instant, je préfère mettre à jour mes paquets Debian moi-même, et contrôler que l’installation du noyau se passe bien (parfois avec Grub ça peut très mal se passer et vous laisser avec un système qui ne démarre plus si vous ne réagissez pas dès les messages d’anomalies constatés). Donc je laisse unattended-upgrades désinstallé.
    ↪ 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 d’amélioration dans la période (au 23/11/2019).
    ➯ Pas de nouveau test dans la période.
    ➯ Même comportement le 10/05/2020.
    ↪ Pas de nouveau test dans la période.

    (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 (Johnny Castaway : sur Clubic, vidéo :).
    ➯ 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.
    ➯ Depuis le 23/11/2019 j’ai installé le paquet d’économiseurs OpenGL rss-glx et l’ai lancé plusieurs fois sans observer de nouveaux plantages. Je n’ai pas installé pour l’instant le paquet xscreensaver-gl. Test à poursuivre. Idem le 15/01/2020.
    ➯ Le 31/01/2020 : je constate le plantage du bureau lorsque je verrouille l’écran plusieurs heures. L’économiseurs d’écran Skyrocket (qui s’active lorsque je verrouille cet écran) en est clairement à l’origine, plus de doute là-dessus (lorsque je le désactive le problème disparait). Pour l’instant j’ai donc désactivé les économiseurs d’écran en sélectionnant « Écran vide » dans les thèmes d’économiseur (ce qui supprime ce temps de latence).
    ➯ Je n’ai plus de souci de freeze de mon bureau après une période prolongée d’inactivité depuis que j’ai désactivé cet économiseur d’écran, mais je ne pense pas que le souci des économiseurs soit résolu pour autant. Je maintien donc ce signalement.
    ↪ 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.