L’observatoire des dysfonctionnements de ma Debian Sid (MAJ : 18/04/2019)

Météo de la période

Météo de ma Debian Sid (02/04/2019 ➤ 18/04/2019) : 🔆
(🔆 ⛅ ☔ ⚡ 💥)

Résumé des changements :

– 🔆 CAJA : Je passe du « ⛅ » au « 🔆 » car le plantage de Caja à la copie d’un répertoire est résolu.

– ☔ Nouveau plantage sérieux de mon OS le 15/04/2019. Les symptômes sont les mêmes (glitchs puis freeze complet). Mais je suis à présent persuadé que le problème venait à la fois d’un faux contact de la prise électrique raccordant 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, une GeForce GTX 260 vs GeForce GTX 275). Le précédent plantage remontait au 10/03/2019.

Et comme je suis persuadé (l’avenir me le confirmera) d’avoir résolu le problème, et surtout que ceci n’a rien à voir avec Linux, la météo passe au « 🔆 »

– je termine par un benchmarking de quelques lecteurs RSS pour mon projet de base de données de liens RSS vers les jeux Linux.

(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 pour cette même version Debian Sid (même s’ils rencontrent eux aussi des bugs réguliers – c’est une version de développement, ne l’oublions pas). J’ai acquis une grande confiance en ces derniers à l’usage.
Bravo aux Américains !

Pour rappel, le contenu exhaustif (pas une ligne de plus) de mon fichier /etc/apt/sources.list :
deb http://ftp.us.debian.org/debian/ sid 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 Sid.
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 Sid 64-bit.

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 Sid (dépôt US) – mise à jour de tous les paquets quotidiennement : 2 ans +14 mois sans plantage (depuis le 01/06/16).

Préambule :

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 pourrait clore la comptabilisation effectuée sur la période précédente (2 ans et 4.5 mois sans plantage sérieux), mais j’ai décidé de poursuivre ce suivi, parce que cet historique me semble intéressant (cela me semble un bon panel, non exhaustif, 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é.
  • 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) la veille :
    • 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, gros plantage de mon système Debian : glitchs sous MATE, et perte du contrôle même avec Ctrl Alt F1, 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. Difficile d’identifier formellement l’origine du problème (matériel ou logiciel), d’autant que j’ai continué à mettre à jour mon système les jours suivants (ma priorité était de retrouver un système fiable au plus vite).
  • le 15/04/2019, nouveau plantage sérieux de mon système Debian, avec les mêmes symptômes : glitchs puis freeze complet. Sauf que là je suis à présent intimement persuadé que le problème 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).

Mon seuil de tolérance : dysfonctionnements éventuels (en Debian Sid 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 2 avril 2019 au 18 avril 2019 :

Pas d’autres dysfonctionnements dans la période.
 

Les points positifs (dysfonctionnements résolus, nouveautés) dans la période du 2 avril 2019 au 18 avril 2019 :

(RÉSOLU) Nouveau plantage sérieux de mon OS le 15/04/2019
Les symptômes sont les mêmes (glitchs puis freeze complet) que ceux du 10/03/2019. Sauf que je suis à présent intimement persuadé que le problème 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, une GeForce GTX 260 vs GeForce GTX 275).

Pour le symptôme de l’écran qui ne s’allume plus : comme l’écran ne s’allumait plus, j’ai voulu tester l’affichage avec l’écran de mon autre PC, et en le branchant je me suis aperçu que la prise le reliant à l’onduleur (UPS) ne tenait pas très bien dans son logement sur l’onduleur. Et effectivement le 10/03/2019 j’avais eut à peu près les mêmes gestes (pour examiner mon PC il me faut l’enlever de son logement et déplacer ses câbles, ce qui a dû avoir pour effet de le bouger et de le déconnecter. Pas terrible ce jeu sur un onduleur) et machinalement j’avais rappuyé sur les prises reliées à l’onduleur.

Pour le symptôme des glitchs : le faux contact n’explique pas à lui seul ces glitchs et freeze du système en cours d’utilisation. C’est pourquoi j’ai changé sa carte graphique : l’ancienne a donc repris du service et jusqu’à présent elle fonctionne parfaitement. Il n’est pas exclu que je teste à nouveau la précédente un de ces quatre.
En attendant, je pense raisonnablement pouvoir dédouaner mon système Linux (car le même jour, le 15/04/19) avait lieu la mise à jour vers :
glx-alternative-mesa (0.9.1) to 1.0.0
glx-alternative-nvidia (0.9.1) to 1.0.0
glx-diversions (0.9.1) to 1.0.0
update-glx (0.9.1) to 1.0.0
Mais tout marche 🙂

(RÉSOLU) Le gestionnaire de fichier Caja plante lorsque l’on tente de copier un fichier par Ctr C + Ctrl V, depuis le 21/01/2018

Depuis le 21/01/2018 (mais peut-être 1 jour ou 2 avant, car je ne l’avais pas remarqué), à chaque fois que je tente de copier un fichier sous Caja par un Ctrl C, le Ctrl V le fait planter (sans message d’erreur en console). La même opération sous Nautilus fonctionne bien (mais je n’aime pas Nautilus : bien qu’il soit assez joli, je trouve ses menus/fonctionnalités d’un autre âge).
J’ai tenté de le lancer à partir d’une console, mais il rend la main (il ne plante pas, mais le curseur est à nouveau disponible) dès qu’on le lance et quand il plante il n’affiche aucun message.

Quelques précisions :
À noter qu’il ne plante pas à la copie d’un fichier mais plante à la copie d’un répertoire.

Dans ~.xsession-errors je trouve (entre autres messages) :

Après un 1er plantage de caja :
(caja:2723): GLib-GIO-CRITICAL **: 16:29:37.297: g_file_query_info: assertion ‘G_IS_FILE (file)’ failed

(caja:2723): GLib-GIO-CRITICAL **: 16:29:37.297: g_file_get_basename: assertion ‘G_IS_FILE (file)’ failed
Initializing caja-image-converter extension
Initializing caja-xattr-tags extension
Initializing caja-open-terminal extension
RuntimeError: object at 0x7f586efa28c0 of type RenameMenu is not initialized
RuntimeError: object at 0x7f586efa28c0 of type RenameMenu is not initialized
kdeinit5: PID 2376 terminated.
RuntimeError: object at 0x7f586efa28c0 of type RenameMenu is not initialized
RuntimeError: object at 0x7f586efa28c0 of type RenameMenu is not initialized
RuntimeError: object at 0x7f586efa28c0 of type RenameMenu is not initialized

après un autre plantage :
(caja:2885): GLib-GIO-CRITICAL **: 16:42:57.706: g_file_query_info: assertion ‘G_IS_FILE (file)’ failed

(caja:2885): GLib-GIO-CRITICAL **: 16:42:57.707: g_file_get_basename: assertion ‘G_IS_FILE (file)’ failed
Initializing caja-image-converter extension
Initializing caja-xattr-tags extension
Initializing caja-open-terminal extension
RuntimeError: object at 0x7f912e5a28c0 of type RenameMenu is not initialized
RuntimeError: object at 0x7f912e5a28c0 of type RenameMenu is not initialized
➯ Le 16/04/2019 : le problème a été résolu dans la période, mais je n’ai pas du tout suivi cela. En tout cas à présent ça marche et c’est le plus important (il était agaçant ce souci là).

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

Quelques applications sympas testées dans la période du 2 avril 2019 au 18 avril 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.

J’ai besoin d’un lecteur RSS puissant et rapide pour mon projet de base de données de liens RSS vers les jeux Linux.
Donc un peu de veille techno s’impose.

Je connaissais déjà Akregator et Liferea pour les avoir utilisé par le passé, mais l’idée était de voir comment ils se comporteraient avec quelques exemples, et aussi de voir si d’autres produits tout aussi puissants étaient à présent disponibles.
J’ai donc initié ma base avec quelques liens et répertoires pour un test en charge.

Pour mes tests je suis parti de cet article sur le site TecMint : 14 Best RSS Feed Readers for Linux in 2018.

J’en ai examiné ou testé quelques-uns, je ne les liste pas tous (moins d’une dizaine), l’idée n’est pas de faire une nième revue des lecteurs RSS, mais de faire un petit bilan rapide de ceux qui pourraient correspondre à mes besoins.

J’ai testé en priorité les lecteurs les plus faciles à mettre en œuvre pour moi, c’est à dire ceux présents dans les dépôts Debian, et notamment :

Akregator (v.5.9.3) : En dépôts Debian. Très simple à installer et à utiliser, joli et rapide (mais moins que QuiteRSS).
Quelques plantages de temps en temps (dans certains cas lorsqu’il ne trouve pas le flux RSS). Un bon candidat.

Liferea (v.1.12.6) : En dépôts Debian. Assez joli, bien intégré graphiquement au bureau Gnome, mais rédhibitoirement lent à télécharger ses news. Tant pis.

QuiteRSS (v.0.18.12) : En dépôts Debian. Pas très joli (c’est une affaire de goûts, mais c’est ce qui m’avait initialement rebuté à le tester), bien intégré (j’aime bien le fait qu’il affiche le nombre de News non lues dans la barre de notification, il émet aussi un sifflement lorsqu’il y a des News), extrêmement rapide (le plus rapide de tous), énormément de possibilités, et il fait le job à la perfection.
Je pense en effet que le candidat idéal doit être un lecteur puissant et rapide car la liste des sites va être longue, très très longue … et il faut donc un outil qui si possible ne s’essouffle pas après 1000 sites.
Il figure à ce jour en tête de liste de mon classement.

FeedReader (v.2.7.1) : en dépôts Debian. Magnifique (le plus beau de tous), ergonomique, rapide, et stable.
Inconvénient : il est encore un peu jeune (2015 à priori) car il lui manque encore des fonctionnalités importantes à mes yeux (voir ci-après) et il est encore loin de celles de QuiteRSS (mais ceci va probablement évoluer).

Notamment à la version 2.7.1 :
il renomme le flux avec le nom du site (au lieu de « The Away Team: Lost Exodus » je trouve « itch.io ») : résolu si l’on sélectionne le service « Local RSS » au démarrage.
– contrairement aux autres lecteurs RSS, il n’affiche pas le nombre d’articles non lus sur tous les niveaux des répertoires, mais uniquement sur le 1er niveau (pour un jeu classé dans le répertoire Adventure & Action ➜ Hack & Slash ➜ Dungeon Crawl, on ne voit le nombre de flux que sur le répertoire Dungeon Crawl), donc lorsque les répertoires sont repliés on ne vois pas le nombre de flux par catégorie, alors que justement l’idée pour moi était de les classer en reprenant la découpe du Bottin.
– pas de possibilité d’export de flux (indispensable si je veux les partager), donc impossible pour moi de le retenir pour l’instant. Et de toute façon je ne conçois pas d’utiliser un outil qui ne me permette pas de sauvegarder mon travail / mes liens.

Il y en a plein d’autres, mais dès qu’il faut installer un serveur (voir à configurer un fichier texte), passer par le Cloud, ou par un navigateur internet (le mien est déjà saturé d’onglets ouverts), ça me rebute. Mais tous les goûts sont dans la nature.

Quant au réglage le plus important : une seule mise à jour des liens RSS à l’ouverture de l’application ou à la demande. Ca ne sert à rien de saturer bêtement le Web à vouloir tout mettre à jour plus souvent.

(pas d’autre / de nouveau test)

 


Dysfonctionnements toujours d’actualité

(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 02/04/2019 : pas d’amélioration (pas de nouvelle version, ni de l’un, ni de l’autre).
➯ Le 18/04/2019 : 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.
➯ Le 18/04/2019 : pas de nouveau test dans la période

(PEU IMPORTANT) 2 écrans détectés alors que je n’en ai qu’un seul (1 écran HP LP3065 nécessitant 2 prises HDMI), depuis le 01/01/2019

J’ai changé d’écran dans la période : je n’ai plus 2 écrans de 22″, mais un unique écran de 30″ (en 2560×1600, requérant la connexion de 2 prises HDMI sur ses entrées) : je ne pourrais donc plus tester le fonctionnement des applications sur 2 écrans. Mais ceci n’a à présent plus d’intérêt car il n’y a plus de problème de gestion de l’affichage avec 2 écrans sous Linux, ça fonctionne très bien.

Par contre l’utilisation de cet écran particulier avec ses 2 prises HDMI (un HP LP3065) m’a fait découvrir un nouveau (petit) dysfonctionnement : Debian détecte 2 écrans de 30″.

Ça se traduit par :

– certains gestionnaires de démarrage ne sont plus opérationnels : lightdm fonctionne bien (car il affiche le gestionnaire de connexion sur l’écran où se trouve le curseur, donc ça ne se voit pas) et sddm aussi, mais les autres ne fonctionnent pas / plus (gdm3, slim, wdm) (kdm n’est plus en dépôts, remplacé par sddm).
Personnellement je trouve que lightdm dans sa version de base, est moche et pas pratique, c’est une usine à gaz (il est censé se paramétrer dans /etc/lightdm mais je n’y suis pas parvenu) et il est pénible de saisir à chaque fois son identifiant. L’installation des paquets de thèmes complémentaires ne change rien. Il y a un début d’intégration sous MATE (dans le Centre de Contrôle) mais çà ne fonctionne pas sur mon installation.
Côté sddm (orienté KDE), c’est pas mieux, la version de base est également moche, et il n’est pas intégré au Centre de Contrôle, mais il dispose lui aussi de plein de thèmes en dépôts et je suis parvenu à changer son thème initial pour un thème bien plus sympathique. J’utilise le thème breeze, très joli (ne me demandez pas comment je suis arrivé à le sélectionner, j’ai essayé plein de trucs qui ont plus ou moins plantés et finalement ce thème est installé et fonctionne bien, ça me suffit). Je n’ai plus besoin de saisir mon identifiant (je n’ai pas besoin d’un système aussi sécurisé, je ne suis pas dans un open space).

– dans le Centre de contrôle ➜ Affichage : je vois 2 écrans : j’ai déclaré le 2nd écran comme « éteint » pour éviter qu’il affiche des applications dessus, que je ne pourrai pas voir.
Je pensais résoudre le problème en modifiant le fichier /etc/X11/xorg.conf, mais j’ai un (dix ?) train(s) de retard : ça fait longtemps que ce fichier n’existe plus et qu’il est remplacé par un mécanisme de détection automatique du matériel (bien plus moderne et pratique).
D’après mes lectures sur la toile, on peut encore configurer manuellement Xorg (et le fichier créé sera prioritaire sur le mécanisme de détection), mais :
1. j’ai la flemme de le faire (rechercher où il faut le mettre, le paramétrer correctement avec les risques qu’une nouvelle mise à jour casse encore tout ça),
2. j’aurais préféré que mon OS détecte tout seul qu’il n’y a qu’un seul écran et pas 2.

Donc peut-être qu’un jour je le ferai mais pour l’instant, j’arrive à me débrouiller, je laisse comme ça.

➯ Le 02/03/2019 : pas de nouveau test dans la période.
➯ Le 02/04/2019 : pas d’amélioration (c’est général sous tous les gestionnaires de fenêtres et l’écran de sélection).
➯ Le 18/04/2019 : 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.

(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é.
➯ 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.

Comments are closed.