Catégorie : Bugs Debian

L’observatoire des dysfonctionnements de ma Debian Sid (MAJ : 23/02/2018)
L’observatoire des dysfonctionnements de ma Debian Sid (MAJ : 23/02/2018) avatar

Récapitulatif du 01 février au 23 février 2018.
(les paragraphes notés comme « RESOLU » sont effacés sur la session suivante)

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 !

Je suis 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 général de l’utilisateur (en l’occurrence moi dans mon coin) lorsqu’il utilise une distribution Linux Debian Sid.
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.

  • Debian Sid (dépôt US) – mise à jour de tous les paquets quotidiennement : 20.5 mois sans plantage (depuis le 01/06/16).
    Dysfonctionnements sérieux dans la période ci-dessus :
    • 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 (grosse mis à jour) 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.

    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.

    Pour rappel, le contenu exhaustif (pas une ligne de plus) de mon fichier /etc/apt/sources.list.d/sources.list :
    deb http://ftp.us.debian.org/debian/ sid main contrib non-free
    deb http://archive.getdeb.net/ubuntu yakkety-getdeb games
    deb http://archive.getdeb.net/ubuntu zesty-getdeb games

    À noter que sur mon autre PC (le PC internet) il ne trouve aucun paquet sur yakkety, mais trouve ses paquets sur Wily (???)
    (deb http://archive.getdeb.net/ubuntu wily-getdeb games)

  • Les points négatifs : dysfonctionnements / changements dans la période 01 février 2018 au 23 février 2018 :

    (changement le 23/02/2018 : un nouveau message de Bálint (mainteneur du paquet unattended-upgrades) m’informant qu’après réflexion, il allait modifier le logiciel unattended-upgrades (message classé côté « Le blocage des paquets sous Synaptic est rendu inopérant (…) ci-dessous)

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

    J’avais signalé un bug 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.
    Finalement 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 à 2 bugs (#597061 et #787945).
    Le mainteneur du paquet unattended-upgrades m’avait alors indiqué que pour bloquer la mise à jour d’un paquet il fallait utiliser la commande : # apt-mark hold (package name).
    Je me suis donc décidé à rédiger un rapport de bug pour Synaptic (pas normal d’avoir une fonction de blocage de paquet qui ne soit pas « waterproof »).

    Finalement il existe déjà un rapport de bug n°#276655 intitulé « synaptic: ‘lock version’ harmful; replace with dpkg holds, dont le statut est confirmé. Je vais voir si je peux apporter ma pierre à l’édifice.

    Visiblement c’est un bug qui a 10 ans 🙂
    (Thanks for looking into this almost 10 year old bug 🙂 d’après monsta@inbox.ru

    Ah, je vois aussi qu’il y a un bug (il y en a un paquet !) : « synaptic: Synaptic starts the firefox with root priviligation by clicking on « Visit Hompage ». Je comprends pourquoi à présent lorsque l’on clique sur un lien HomePage sous Synaptic, il ne se passe plus rien : ils ont dû désactiver provisoirement la fonctionnalité pour éviter cela.

    Voilà donc mon ajout / ma proposition au rapport de bug n°#276655 :

    Re: synaptic: ‘lock version’ harmful; another suggestion : replace with apt-mark hold (package name)

    I have reported the bug #890668 about unattended-upgrades package
    In it’s recent version (0.99), this package upgrade all Debian packages (not only security packages) even if they are blocked on Synaptic.

    The maintainer of this package tells me to use :
    apt-mark hold (package name)
    to hold a package.

    I suggest to use this function on Synaptic

    Super Nouvelle, j’ai reçu un nouveau message de Bálint (le mainteneur du paquet unattended-upgrades) ce jour, le 23/02/2018 :

    I see you found the relevant bug, #276655 in synaptic.

    Your email made me look at u-u code to check if it really honors the hold marker and noticed that blacklist and whitelist was not honored in auto-removal. The next upload will fix that.

    Cheers,
    Balint

    Je n’ai pas repéré de nouveaux dysfonctionnements dans la période.

  • Les points positifs : dysfonctionnements résolus et/ou Nouveautés dans la période :

    ☑ (RESOLU ET IMPORTANT) Gnome-software 3.26.5-1 (non) Synaptic 0.84-2 (et apt 1.6~alpha 7) (non plus) unattended-upgrades a mis à jour (sans que je n’ai rien demandé) des paquets que j’avais bloqué à la mise à jour, constaté le 12/02/2018.

    Finalement ce n’est pas à proprement parlé un bug, mais un changement de comportement réalisé sciemment à sa version 0.99, afin de répondre à 2 bugs (#597061 et #787945) : unattended-upgrades ne se contente plus de mettre à jour les paquets relatifs à la sécurité, mais il met à présent à jour tous les paquets. Donc il mettait déjà à jour tous les paquets relatifs à la sécurité avant cette version, sans me demander mon avis (un popup aurais été bien accueilli), mais je ne m’en étais pas aperçu.
    D’autre-part il ne tient absolument pas compte du blocage des paquets sous Synaptic. Pour bloquer la mise à jour d’un paquet il faut utiliser la commande : # apt-mark hold (package name).

    L’historique du problème :

    J’ai d’abord cru à un bug de Gnome-software 3.26.5-1, mais après l’avoir désinstallé, force est de constater que le problème est toujours là.
    Ensuite j’ai suspecté Synaptic / APT, mais finalement c’était le paquet unattended-upgrades.

    Les faits :
    – Le 15/01/2018 je constate que Tellico 3.1.1-0.1 des dépôts Debian est bugué (voir plus bas). J’ai donc aussitôt réinstallé la version antérieure (la 3.1-0.3) qui fonctionne bien, et bloqué cette version via Synaptic (je sélectionne les paquets, puis ➜ Menu Paquet ➜ Bloquer la version) pour éviter qu’elle ne soit mise à jour à chaque fois que je clique sur le bouton pour mettre à jour tous les paquets (non bloqués) (sous Synaptic, icône « Sélectionner l’ensemble des mises à jour disponibles »).
    – Le logiciel Gnome-software est installé et s’active à chaque démarrage de mon gestionnaire de fenêtre Budgie (pas trop le choix, tout d’abord il fait partie de GNOME et ses dépendances font que sa désinstallation désinstalle aussi le métapaquet GNOME, ensuite un bug de Budgie fait que certains logiciels sont difficiles à enlever de la liste des logiciels lancés au démarrage : même en les enlevant parfois au démarrage suivant ils sont de retour).
    – Le 12/02/2018 je constate que Tellico est bugué, et je constate que c’est parce que la version 3.1.1-0.1 a été ré-installé sans que je l’ai demandé. Sur le coup je (reste dubitatif, mais) pense à une éventuelle mauvaise manipulation de ma part. Je ré-installe Tellico 3.1-0.3. Il me semble (de mémoire) avoir déjà eut un doute sur Gnome-software (mais je ne me souviens plus si j’ai tenté de le désactiver ou non).
    – Le 13/02/2018 je n’ai pas constaté d’anomalie (visiblement Tellico est resté en version 3.1-0.3 malgré une mise à jour sous Synaptic).
    – Le 14/02/2018, Tellico en version 3.1.1-0.1 a de nouveau été ré-installé sans que je l’ai demandé. Sur ce constat, j’ai à nouveau ré-installé sa version 3.1-0.3.
    Précisions : je n’ai pas installé de paquets en console (autre que Tellico 3.1-0.3 via gdebi ou dpkg) ni lancé d’upgrade en console, et l’historique des installations sous Synaptic (menu Fichier ➜ Historique des opérations) ne mentionne à aucun moment l’installation de Tellico en version 3.1.1-0.1 (je ne vois que les désinstallations que j’ai effectué pour pouvoir réinstaller Tellico en version antérieure via gdebi ou dpkg).
    Cette dernière observation m’avait amené à conclure (à tort) que le « fautif » était Gnome-software 3.26.5-1.
    Conséquence de ceci : ce même jour (14/02/2018) j’ai désinstallé Gnome-software 3.26.5-1, ses plugins (gnome-software-plugin-flatpak et gnome-software-plugin-limba) et ses dépendances (par la force des choses, gnome et gnome-core). Ce qui m’embête beaucoup pour GNOME.
    – Le 15/02/2018 : j’ai mis à jour mon système Debian comme d’habitude et n’ai rien constaté d’anormal. Tellico fonctionnait bien dans sa version précédente, la 3.1-0.3 (reconnaissable au premier coup d’œil dès son démarrage car dans la 3.1.1-0.1 les copies d’écrans affichées dans la zone de liste sont minuscules).
    – (Le 16/02/2018 j’ai démarré mes PC, mais ne me suis pas connecté)
    – Le 17/02/2018 : je lance Tellico, et je constate que la version 3.1.1-0.1 est de nouveau installée ! Je regarde sous Synaptic : la version 3.1.1-0.1 est installée et bloquée en 3.1.1-0.1 ! (rappel : je l’avais bloqué en 3.1-0.3). Gros bug.

    Donc il semble que soit Synaptic dans sa version 0.84-2, ou APT dans sa version 1.6~alpha 7, ne bloque plus les paquets et les installe en même temps que les autres (lorsque l’on lance la mise à jour de tous les paquets via le bouton / icône « Sélectionner l’ensemble des mises à jour disponibles »).
    Heureusement que ce n’était pas un noyau Linux bugué par exemple (ou des bibliothèques buguées qui planteraient le démarrage).

    Il y a cependant un truc qui ne colle pas : l’historique de mise à jour des paquets sous Synaptic.
    Cet historique me liste les paquets mis à jour via Synaptic (mais pas les mises à jour en dehors de Synaptic, en console avec apt ou gdebi par exemple) depuis le 13/11/2017 (j’avais dû probablement effacer l’historique avant).
    Lorsque je fais une recherche sur le paquet « Synaptic », il ne le trouve pas (ce qui veut dire que sa version 0.84-2 date d’avant le 13/11/2017).
    Lorsque je fais une recherche sur le paquet « apt », (apt 1.6~alpha6 to 1.6~alpha7), il a été mis à jour le 19/01/2018.
    Or, je ne constate le dysfonctionnement ci-dessus que le 12 février 2018 alors que j’utilise Tellico tous les jours et Synaptic / apt aussi …

    Une piste serait de regarder ce qui a été installé et supprimé les 10 et 11/02/2018, mais la liste est longue 🙁
    Je les liste ci-après pour mémo (j’effacerai la liste plus tard) au cas où cela me permette plus tard d’identifier le paquet incriminé, mais je ne vois rien en rapport avec la mise à jour des paquets.
    Je sèche là. Elle est bizarre cette histoire.
    J’avais pensé éventuellement faire un rapport de bug, mais là je ne suis même pas sûr que le problème vienne de Synaptic ou d’APT.

    Tiens, un nouveau venu dans la liste ds suspects potentiels 🙂 :
    gnome-packagekit : PackageKit allows performing simple software management tasks over a DBus interface e.g. refreshing the cache, updating, installing and removing software packages or searching for multimedia codecs and file handlers.
    Il est encore installé. Allez, on désinstalle pour voir 🙂
    (je verrai si Tellico revient dans sa nouvelle version)

    Il en reste d’autres :
    – gdebi : je l’ai utilisé à plusieurs reprises dans la période. Je l’écarte provisoirement.
    – unattended-upgrades : « Ce paquet peut télécharger et installer les mises à jour de sécurité automatiquement sans intervention, en se basant uniquement sur les paquets installés depuis les sources APT configurées, et en vérifiant les changements de fichiers de configuration par dpkg ».
    Et il se trouve qu’il a été mis à jour (unattended-upgrades (0.98) to 0.99) le 10/02/2018 !
    Reste à savoir s’il lui est possible de mettre à jour Tellico.
    Le contenu de mon fichier /etc/apt/apt.conf.d/10periodic :
    APT::Periodic::Update-Package-Lists « 0 »;
    APT::Periodic::Unattended-Upgrade « 1 »;
    APT::Periodic::Download-Upgradeable-Packages « 1 »;
    APT::Periodic::AutocleanInterval « 0 »;
    Si j’interprète correctement le wiki Debian : la mise à jour de la liste des paquets est désactivée (Update-Package-Lists « 0 » = apt-get update) et le téléchargement automatique (mais sans installation) est activé (Download-Upgradeable-Packages « 1 » = « apt-get upgrade –download-only »)
    Je le lance en console par un : # unattended-upgrades
    et effectivement il se lance dans des téléchargements importants (mais je ne sais pas quoi), puis il s’arrête (sans erreur).
    Dans /var/log/unattended-upgrades je trouve :

    2018-02-17 10:31:16,496 INFO Paquets mis à niveau: appmenu-gtk-module-common appmenu-gtk2-module appmenu-gtk3-module budgie-appmenu-applet console-setup console-setup-linux exo-utils flex fonts-lindenhill fonts-ocr-a gnome-tweak-tool gnome-tweaks keyboard-configuration libappmenu-gtk2-parser0 libappmenu-gtk3-parser0 libc-ares2 libcpupower1 libegl-mesa0 libegl1-mesa libegl1-mesa-dev libexo-1-0 libexo-common libexo-helpers libfl-dev libgbm-dev libgbm1 libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles2-mesa libgles2-mesa-dev libglx-mesa0 libgnutls-dane0 libgnutls-openssl27 libgnutls28-dev libgnutls30 libgnutlsxx28 libinput-bin libinput-dev libinput10 libio-socket-ssl-perl liblept5 libosmesa6 libparse-recdescent-perl libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 libqt5sql5 libqt5sql5-mysql libqt5sql5-psql libqt5sql5-sqlite libqt5test5 libqt5widgets5 libqt5xml5 librhash-dev librhash0 libservlet3.1-java libthai-data libthai-dev libthai0 libvalapanel0 libwayland-egl1-mesa linux-compiler-gcc-7-x86 linux-headers-4.14.0-3-686-pae linux-headers-4.14.0-3-common linux-image-4.14.0-3-686-pae linux-kbuild-4.14 linux-libc-dev mate-tweak mesa-common-dev mesa-va-drivers numix-icon-theme openclonk openclonk-data qt5-default qt5-gtk-platformtheme qt5-qmake qt5-qmake-bin qtbase5-dev qtbase5-dev-tools qtbase5-doc qtbase5-private-dev rhash s-nail ucf vala-panel vala-panel-appmenu vala-panel-appmenu-common vala-panel-appmenu-registrar vala-panel-common vala-panel-plugins-base vala-panel-plugins-wnck xdg-desktop-portal-gtk
    2018-02-17 10:31:16,497 INFO Écriture du journal de dpkg dans « /var/log/unattended-upgrades/unattended-upgrades-dpkg.log »
    2018-02-17 10:41:44,379 INFO Toutes les mises à niveau ont été installées
    2018-02-17 10:41:51,766 INFO Suppression automatique des paquets: limba
    2018-02-17 10:42:56,464 INFO Ces packets ont été correctement supprimés

    Et cerise sur le gâteau, un peu plus haut je trouve :
    2018-02-17 08:21:24,977 INFO Paquets initialement sur la liste noire:
    2018-02-17 08:21:24,997 INFO Paquets initialement sur la liste blanche:
    2018-02-17 08:21:24,997 INFO Démarrage du script de mise à niveau automatique
    2018-02-17 08:21:24,997 INFO Les origines permises sont: [‘origin=Debian,codename=sid,label=Debian’, ‘origin=Debian,codename=sid,label=Debian-Security’]
    2018-02-17 08:21:46,799 INFO Paquets initialement sur la liste noire:
    2018-02-17 08:21:46,800 INFO Paquets initialement sur la liste blanche:
    2018-02-17 08:21:46,800 INFO Démarrage du script de mise à niveau automatique
    2018-02-17 08:21:46,801 INFO Les origines permises sont: [‘origin=Debian,codename=sid,label=Debian’, ‘origin=Debian,codename=sid,label=Debian-Security’]
    2018-02-17 08:21:57,915 INFO Paquets mis à niveau: tellico tellico-data tellico-doc tellico-scripts
    2018-02-17 08:21:57,915 INFO Écriture du journal de dpkg dans « /var/log/unattended-upgrades/unattended-upgrades-dpkg.log »
    2018-02-17 08:25:11,516 INFO Toutes les mises à niveau ont été installées
    2018-02-17 10:21:42,929 INFO Paquets initialement sur la liste noire:
    2018-02-17 10:21:42,930 INFO Paquets initialement sur la liste blanche:
    2018-02-17 10:21:42,930 INFO Démarrage du script de mise à niveau automatique
    2018-02-17 10:21:42,930 INFO Les origines permises sont: [‘origin=Debian,codename=sid,label=Debian’, ‘origin=Debian,codename=sid,label=Debian-Security’]
    2018-02-17 10:21:42,931 ERROR Verrouillage impossible (y a-t-il un autre gestionnaire de paquets en cours d’exécution ?)
    2018-02-17 10:21:57,297 INFO Paquets initialement sur la liste noire:
    2018-02-17 10:21:57,298 INFO Paquets initialement sur la liste blanche:
    2018-02-17 10:21:57,298 INFO Démarrage du script de mise à niveau automatique
    2018-02-17 10:21:57,299 INFO Les origines permises sont: [‘origin=Debian,codename=sid,label=Debian’, ‘origin=Debian,codename=sid,label=Debian-Security’]

    C’est lui le coupable 🙂 Dès le démarrage de mon système il m’a mis à jour Tellico alors qu’il était bloqué !
    Dans ce même fichier log je trouve aussi :
    2018-02-12 17:30:45,179 INFO Paquets mis à niveau: corebird tellico tellico-data tellico-doc tellico-scripts
    (…)
    2018-02-14 17:56:53,341 INFO Paquets mis à niveau: tellico tellico-data tellico-doc tellico-scripts
    (…)
    2018-02-16 17:55:52,918 ERROR Échec du téléchargement à l’URI « http://ftp.us.debian.org/debian/pool/main/t/tellico/tellico_3.1.1-0.1_i386.deb », abandon
    (çà tombait bien, il n’y avait pas de réseau 🙂 Normal, il faut souvent que je reboot plusieurs fois ce PC pour avoir du réseau)

    Je viens de reporter le bug via l’outil : $ reportbug
    (paquet du même nom)
    C’est mon 1er report de bug chez Debian. J’espère que çà va marcher, car çà a été un peu laborieux.
    Au lieu d’utiliser un système de report de bug via le navigateur (comme pour GitHub), Debian le fait par mail via un outil (paquet reportbug) avec une interface graphique.
    Ce système est très bien aussi, mais çà complique un peu les choses pour l’utilisateur lambda, la 1ere fois qu’il l’utilise.
    Gros avantage : elle récupère automatiquement des informations utiles pour le déboguage et les affiche dans le rapport de bug.
    J’avais donné mon adresse SMTP pour goupilcom@gmail.com, et j’ai accepté la connexion sécurisée (SSL/TLS à priori), sauf qu’a aucun moment elle ne me demande de mot de passe de connexion pour pouvoir envoyer des mails à ma place (d’un autre côté je n’étais pas très chaud pour cela).
    Donc en fin de report de bug il n’arrive pas à envoyer le rapport de bug et un message laconique me propose d’interrompre le processus OUI ou NON. Forcément je n’ai pas choisi la bonne réponse et l’interface s’est refermée avant que je n’ai eut le temps de dire zut 🙂 (version édulcorée de ma pensée à ce moment là)
    Heureusement j’avais prévu cette alternative (habitué aux logiciels ergonomiques 🙂 ) et avais sauvegardé mes réponses au fur et à mesure dans un fichier texte.
    En fait dans le paramétrage de reportbug ($ reportbug –configure), il est plus simple de répondre que l’on souhaite laisser Debian envoyer le mail lui-même (tout en précisant son adresse mail, mais sans utiliser SMTP).
    Si tout va bien, je pense que mon rapport de bug devrait apparaître ici : Debian Bug report logs

    Yes, çà marche, j’ai le bug n°#890668
    (mon 1er bug Debian, je fête çà ce soir 🙂 )

    Dans l’attente de la correction du bug, j’ai désinstallé provisoirement le paquet unattended-upgrades (et réinstallé les autres précédemment désinstallés).

    Voici la réponse reçue :

    Le 21/02/2018 à 18:41, Bálint Réczey a écrit :
    Control: tags -1 moreinfo

    Dear Serge,

    2018-02-17 22:20 GMT+07:00 Serge Le Tyrant (goupilcom@gmail.com):
    Package: unattended-upgrades
    Version: 0.99
    Severity: important
    Tags: d-i

    With unattended-upgrades 0.99: All Debian packages are updated (not only Debian-Security) including blocked packages

    ➜ Yes, this is a result of a recent intentional change to fix #597061 and #787945.

    I don’t wan’t to upgrade Tellico 3.1-0.3, because the last version (3.1.1-0.1) has an annoying bug (sorry i don’t report it). So i have blocked this 3.1-0.3 version on Synaptic.

    ➜ Unfortunately this ‘locking’ affect’s only Synaptic. To hold a package for most package management interfaces please use:
    apt-mark hold

    I hadn’t this probleme before this 0.99 version (upgraded on the 02.10.2018)

    ➜ Yes, the change took place in 0.99.

    /etc/apt/apt.conf.d/10periodic (i never edited it) :
    APT::Periodic::Update-Package-Lists « 0 »;
    APT::Periodic::Unattended-Upgrade « 1 »;
    APT::Periodic::Download-Upgradeable-Packages « 1 »;
    APT::Periodic::AutocleanInterval « 0 »;

    If i understand Debian Wiki correctly :
    APT::Periodic::Download-Upgradeable-Packages « 1 » mean Do « apt-get upgrade –download-only » so unattended-upgrades must only download upgradable packages, and not to update all the system, and let alone update blocked packets.

    ➜ No, this option is documented in /usr/lib/apt/apt.systemd.daily and controls only the interval packages are downloaded.

    This can cause a severe malfunction of my system if I dont want to update a kernel or a library whose top version does not work

    ➜ Please use the apt-mark hold (/package)(package name) command to lock packages and u-u will honor that.
    You can also choose set Unattended-Upgrade::Package-Blacklist, but that affects unattended-upgrades only and not for example apt-get dselect-upgrade.

    Cheers,
    Balint

    Ma réponse ce jour :

    Dear Bálint,

    Sorry, i wasn’t informed of thoses changes and i did not know this command (apt-mark hold (/package)(package name)).
    This modification affect the behavior of Synaptic whose ‘locking’ functionality is no longer operational when this package is installed.

    I’m going to make a bug report about synaptic.

    This issue is solved.

    Thank you very much for your time and your answer, and sorry for the inconvenience.

    Cheers,

    Serge Le Tyrant.

    C’est (partiellement) réglé (le problème se déporte sur Synaptic, mais Bálint fait parfaitement son job). Là aussi un professionnel. Chapeau bas.

    ☑ (RESOLU) (Problème avec un ancien driver sur mon installation) Le driver nvidia pour l’accélération graphique ne se compile pas avec le noyau linux-image-4.15.0-1-686-pae (version Debian : 4.15.4-1), constaté le 18/02/2018.

    Le problème a été résolu, ce n’était pas un bug, mais un souci avec un ancien driver nvidia (version 195.36.24, situé dans /var/lib/dkms/nvidia/195.36.24/) qui s’installait en lieu et place du driver actuel (version 340.106-2). Il aura suffit de déplacer (ou d’effacer ce répertoire pour résoudre le problème).
    L’histoire ne dit pas pourquoi tout d’un coup dkms s’est mis à utiliser ce driver plutôt que le plus récent alors que j’ai installé de nombreux noyaux depuis (dont le 4.14 qui n’a posé aucun souci).

    Voici l’historique du problème :

    J’ai souhaité tester le noyau linux-image-4.15.0-1-686-pae arrivé ce jour dans les dépôts Debian.
    Il démarre bien, et ne semble (je n’ai pas pu le tester assez longtemps car pas d’accélération graphique) pas poser de problème.
    Malheureusement la compilation du driver nvidia pour obtenir l’accélération graphique plante sur une erreur d’entête absente (avec un message dkms).
    Désolé pour l’imprécision de ce « rapport », j’ai oublié de noter

    Le contenu de /var/lib/dkms/nvidia/195.36.24/build/make.log :
    DKMS make.log for nvidia-195.36.24 for kernel 4.15.0-1-686-pae (i686)
    dimanche 18 février 2018, 17:58:56 (UTC+0100)
    make : on entre dans le répertoire « /var/lib/dkms/nvidia/195.36.24/build »
    make -C /lib/modules/4.15.0-1-686-pae/build M=`/bin/pwd` modules
    make[1] : on entre dans le répertoire « /usr/src/linux-headers-4.15.0-1-686-pae »
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/nv_gvi.o
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/nv-vm.o
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/os-agp.o
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/os-interface.o
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/os-registry.o
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/nv-i2c.o
    CC [M] /var/lib/dkms/nvidia/195.36.24/build/nvacpi.o
    In file included from /var/lib/dkms/nvidia/195.36.24/build/nv_gvi.c:15:0:
    /var/lib/dkms/nvidia/195.36.24/build/nv-linux.h:22:10: fatal error: linux/autoconf.h: Aucun fichier ou dossier de ce type
    #include (linux /autoconf.h)
    ^~~~~~~~~~~~~~~~~~
    compilation terminated.
    /usr/src/linux-headers-4.15.0-1-common/scripts/Makefile.build:321 : la recette pour la cible « /var/lib/dkms/nvidia/195.36.24/build/nv_gvi.o » a échouée
    make[4]: *** [/var/lib/dkms/nvidia/195.36.24/build/nv_gvi.o] Erreur 1
    make[4]: *** Attente des tâches non terminées….
    In file included from /var/lib/dkms/nvidia/195.36.24/build/nv-vm.c:14:0:
    /var/lib/dkms/nvidia/195.36.24/build/nv-linux.h:22:10: fatal error: linux/autoconf.h: Aucun fichier ou dossier de ce type
    #include (/linux)(linux /autoconf.h)
    ^~~~~~~~~~~~~~~~~~
    In file included from /var/lib/dkms/nvidia/195.36.24/build/os-agp.c:24:0:
    /var/lib/dkms/nvidia/195.36.24/build/nv-linux.h:22:10: fatal error: linux/autoconf.h: Aucun fichier ou dossier de ce type
    #include (/linux)(linux /autoconf.h)
    ^~~~~~~~~~~~~~~~~~
    compilation terminated.
    compilation terminated.
    /usr/src/linux-headers-4.15.0-1-common/scripts/Makefile.build:321 : la recette pour la cible « /var/lib/dkms/nvidia/195.36.24/build/nv-vm.o » a échouée
    make[4]: *** [/var/lib/dkms/nvidia/195.36.24/build/nv-vm.o] Erreur 1
    /usr/src/linux-headers-4.15.0-1-common/scripts/Makefile.build:321 : la recette pour la cible « /var/lib/dkms/nvidia/195.36.24/build/os-agp.o » a échouée
    make[4]: *** [/var/lib/dkms/nvidia/195.36.24/build/os-agp.o] Erreur 1
    In file included from /var/lib/dkms/nvidia/195.36.24/build/os-interface.c:26:0:
    /var/lib/dkms/nvidia/195.36.24/build/nv-linux.h:22:10: fatal error: linux/autoconf.h: Aucun fichier ou dossier de ce type
    #include (/linux)(linux /autoconf.h)

    Et hop, c’est parti pour un 2nd report de bug via : $ reportbug
    et c’est par ici : Bug#890775
    (maintenant que je l’ai paramétré, c’est nettement plus rapide et efficace)

    Effectivement, je constate l’efficacité de leur interface de report de bugs : les infos transmises automatiquement et en même temps que mon rapport sont très pertinentes. Il est génial cet outil !
    Ca donne envie de faire plein de rapports 🙂
    (non, je plaisante)

    Le seul hic ici, c’est que pour faire mon rapport de bug j’ai dû redémarrer sur mon ancien noyau afin d’avoir une interface graphique facilitant le report, et du coup les informations recueillies concernent l’ancien noyau et le driver compilé pour lui.

    Réponse du mainteneur :
    Hi,

    Are you sure you are using the right command/package? The log shows that it’s trying to build the 195.xx series, which is deprecated.
    340.xx works fine, just tested on Sid, both with module-assisant and with dkms.

    (traduction) il me fait remarquer à juste titre que d’après les logs, le driver nvidia compilé est un ancien driver de la série 195.xx, et qu’il vaut mieux utiliser un driver 340xx (plus récent et fonctionnel) et me demande si je suis sûr d’avoir lancé la bonne commande.

    Ma réponse :
    (par contre je lui ai répondu en retour de mail, après réflexion je pense que j’aurai dû utiliser l’outil de report de bug pour répondre, mais je ne sais pas comment, car du coup la démarche de recherche du problème devient confidentielle, alors qu’il me semble intéressant de la partager)

    Hi,

    Thank you.

    I didn’t notice it was compiling this 195.xx driver. I don’t know why it compile this old driver, and not a 340.xx
    The command i had lauched is : # m-a a-i nvidia-legacy-340xx-kernel-source

    Perhaps i have made a mistake, but i don’t understand, because i don’t see any 195.xx driver on Synaptic, and i haven’t download any external
    nvidia driver. I’ll do another test tomorrow and I will send you the result

    Traduction :

    Je n’ai pas remarqué qu’il compilait ce pilote 195.xx. Je ne sais pas pourquoi il a compilé ce vieux pilote, et pas un 340.xx
    La commande que j’ai lancée est: # m-a-i nvidia-legacy-340xx-kernel-source

    Peut-être que j’ai fait une erreur, mais je ne comprends pas, parce que je ne vois pas de pilote 195.xx sur Synaptic, et je n’ai pas téléchargé de pilote externe nvidia. Je ferai un autre test demain et je vous enverrai le résultat

    Puis j’ai réinstallé pour voir le noyau 4.15.0-1-686-pae, ai noté les messages et lui ai ré-écris :

    I have tried to installed another time the linux-image-4.15.0-1-686-pae kernel and i recieved the messages below on Synaptic :

    Sélection du paquet linux-image-4.15.0-1-686-pae précédemment désélectionné.
    (Lecture de la base de données… 1172298 fichiers et répertoires déjà installés.)
    Préparation du dépaquetage de …/linux-image-4.15.0-1-686-pae_4.15.4-1_i386.deb …
    Dépaquetage de linux-image-4.15.0-1-686-pae (4.15.4-1) …
    Paramétrage de linux-image-4.15.0-1-686-pae (4.15.4-1) …
    /etc/kernel-img.conf:4: W: ignoring unknown parameter relative_links
    /etc/kernel-img.conf:6: W: ignoring unknown parameter do_bootfloppy
    I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.14.0-3-686-pae
    I: /initrd.img.old is now a symlink to boot/initrd.img-4.14.0-3-686-pae
    I: /vmlinuz is now a symlink to boot/vmlinuz-4.15.0-1-686-pae
    I: /initrd.img is now a symlink to boot/initrd.img-4.15.0-1-686-pae
    /etc/kernel/postinst.d/dkms:
    Error! Bad return status for module build on kernel: 4.15.0-1-686-pae (i686)
    Consult /var/lib/dkms/nvidia/195.36.24/build/make.log for more information.
    /etc/kernel/postinst.d/initramfs-tools:
    update-initramfs: Generating /boot/initrd.img-4.15.0-1-686-pae
    I: The initramfs will attempt to resume from /dev/md0
    I: (UUID=92dd207d-8fbb-4224-a70d-ca73e0594d8d)
    I: Set the RESUME variable to override this.
    /etc/kernel/postinst.d/zz-update-grub:
    Création du fichier de configuration GRUB…
    Found background image: /usr/share/images/desktop-base/desktop-grub.png
    Image Linux trouvée : /boot/vmlinuz-4.15.0-1-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.15.0-1-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.14.0-3-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.14.0-3-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.14.0-2-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.14.0-2-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.13.0-1-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.13.0-1-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.12.0-1-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.12.0-1-686-pae
    Image Linux trouvée : /boot/vmlinuz-3.2.0-4-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-3.2.0-4-686-pae
    fait

    So when i installed this kernel it try to compile automatically a 195.xx.xx nvidia driver.
    Why ? I don’t understand.
    With others kernel i had installed in the same manner on Synaptic (for example the linux-image-4.14.0-2-686-pae) i didn’t have this problem, it compile automatically the good 340.xx series of nvidia driver.
    And it seems to me there is no 195.xx.xx nvidia driver in Sid Debian repositories

    Traduction :

    Donc quand j’ai installé ce noyau, il essaie de compiler automatiquement un pilote nvidia 195.xx.xx.
    Pourquoi ? Je ne comprends pas.
    Avec d’autres noyaux que j’avais installé de la même manière sur Synaptic (par exemple le linux-image-4.14.0-2-686-pae) je n’ai pas eu ce problème, il compile automatiquement la bonne série 340.xx du driver nvidia .
    Et il me semble qu’il n’y a pas de pilote nvidia 195.xx.xx dans les dépôts Sid Debian

    Le 20/12/2018 :

    Réponse du mainteneur :

    You probably have leftovers from old or manual installations. If it’s packages you’ll see them with dpkg -l | grep nvidia – If it’s the Nvidia installer you need to clean them up manually. Check out the http s://packages.debian.org/sid/nvidia-installer-cleanup package.

    Traduction : Vous avez probablement des restes d’installations anciennes ou manuelles.
    Si c’est des paquets, vous les verrez avec dpkg -l | grep nvidia
    Si c’est l’installateur Nvidia, vous devez les nettoyer manuellement.
    Consultez le package http s: //packages.debian.org/sid/nvidia-installer-cleanup.

    Ma réponse :

    The result of this command :

    # dpkg -l | grep nvidia
    ii glx-alternative-nvidia 0.8.3 i386 allows the selection of NVIDIA as GLX provider
    ii libegl1-nvidia-legacy-340xx:i386 340.106-2 i386 NVIDIA binary EGL library (340xx legacy version)
    ii libgl1-nvidia-legacy-340xx-glx:i386 340.106-2 i386 NVIDIA binary OpenGL/GLX library (340xx legacy version)
    ii libgles1-nvidia-legacy-340xx:i386 340.106-2 i386 NVIDIA binary OpenGL|ES 1.x library (340xx legacy version)
    ii libgles2-nvidia-legacy-340xx:i386 340.106-2 i386 NVIDIA binary OpenGL|ES 2.x library (340xx legacy version)
    ii libnvidia-legacy-340xx-cfg1:i386 340.106-2 i386 NVIDIA binary OpenGL/GLX configuration library (340xx legacy version)
    ii libnvidia-legacy-340xx-eglcore:i386 340.106-2 i386 NVIDIA binary EGL core libraries (340xx legacy version)
    ii libnvidia-legacy-340xx-glcore:i386 340.106-2 i386 NVIDIA binary OpenGL/GLX core libraries (340xx legacy version)
    ii libnvidia-legacy-340xx-ml1:i386 340.106-2 i386 NVIDIA Management Library (NVML) runtime library (340xx legacy version)
    ii mate-sensors-applet-nvidia 1.20.0-1 i386 Display readings from hardware sensors in your MATE panel (NVIDIA sensors)
    ii nvidia-installer-cleanup 20151021+7 i386 cleanup after driver installation with the nvidia-installer
    ii nvidia-kernel-common 20151021+7 i386 NVIDIA binary kernel module support files
    ii nvidia-legacy-340xx-alternative 340.106-2 i386 allows the selection of NVIDIA as GLX provider (340xx legacy version)
    ii nvidia-legacy-340xx-driver 340.106-2 i386 NVIDIA metapackage (340xx legacy version)
    ii nvidia-legacy-340xx-driver-bin 340.106-2 i386 NVIDIA driver support binaries (340xx legacy version)
    ii nvidia-legacy-340xx-driver-libs:i386 340.106-2 i386 NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) (340xx legacy version)
    ii nvidia-legacy-340xx-driver-libs-i386 340.106-2 i386 NVIDIA metapackage (OpenGL/GLX/EGL/GLES 32-bit libraries) (340xx legacy)
    rc nvidia-legacy-340xx-kernel-4.12.0-1-686-pae 340.104-3+4.12.6-1 i386 NVIDIA binary kernel module for Linux 4.12.0-1-686-pae
    ii nvidia-legacy-340xx-kernel-4.14.0-3-686-pae 340.106-2+4.14.17-1 i386 NVIDIA binary kernel module for Linux 4.14.0-3-686-pae
    rc nvidia-legacy-340xx-kernel-4.15.0-1-686-pae 340.106-2+4.15.4-1 i386 NVIDIA binary kernel module for Linux 4.15.0-1-686-pae
    ii nvidia-legacy-340xx-kernel-dkms 340.106-2 i386 NVIDIA binary kernel module DKMS source (340xx legacy version)
    ii nvidia-legacy-340xx-kernel-source 340.106-2 i386 NVIDIA binary kernel module source (340xx legacy version)
    ii nvidia-legacy-340xx-kernel-support 340.106-2 i386 NVIDIA binary kernel module support files (340xx legacy version)
    ii nvidia-legacy-340xx-vdpau-driver:i386 340.106-2 i386 Video Decode and Presentation API for Unix – NVIDIA driver (340xx legacy)
    ii nvidia-modprobe 384.111-1 i386 utility to load NVIDIA kernel modules and create device nodes
    ii nvidia-persistenced 384.111-1 i386 daemon to maintain persistent software state in the NVIDIA driver
    ii nvidia-settings-legacy-340xx 340.104-1 i386 tool for configuring the NVIDIA graphics driver (340xx legacy version)
    ii nvidia-support 20151021+7 i386 NVIDIA binary graphics driver support files
    ii xserver-xorg-video-nvidia-legacy-340xx 340.106-2 i386 NVIDIA binary Xorg driver (340xx legacy version)

    It’s weird, i don’t see any 195.xx.xx version.

    I don’t know if its relevant, some others informations :

    # /usr/lib/nvidia/check-for-conflicting-opengl-libraries
    ERROR: DPKG_MAINTSCRIPT_PACKAGE is not set, usually a bug in dpkg-reconfigure

    # /usr/lib/nvidia/check-for-mismatching-nvidia-module
    #
    (no information in console)

    In /var/lib/dkms/
    I have :
    /var/lib/dkms/nvidia/195.36.24/ with oldkernels
    and :
    /var/lib/dkms/nvidia-legacy-340xx with 4.14.0-3-686-pae

    For the test i move this /var/lib/dkms/nvidia/ directory elsewhere

    And then installed linux-image-4.15.0-1-686-pae package, and below is the result on synaptic:

    Sélection du paquet linux-image-4.15.0-1-686-pae précédemment désélectionné.
    (Lecture de la base de données… 1172298 fichiers et répertoires déjà installés.)
    Préparation du dépaquetage de …/linux-image-4.15.0-1-686-pae_4.15.4-1_i386.deb …
    Dépaquetage de linux-image-4.15.0-1-686-pae (4.15.4-1) …
    Paramétrage de linux-image-4.15.0-1-686-pae (4.15.4-1) …
    /etc/kernel-img.conf:4: W: ignoring unknown parameter relative_links
    /etc/kernel-img.conf:6: W: ignoring unknown parameter do_bootfloppy
    I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.14.0-3-686-pae
    I: /initrd.img.old is now a symlink to boot/initrd.img-4.14.0-3-686-pae
    I: /vmlinuz is now a symlink to boot/vmlinuz-4.15.0-1-686-pae
    I: /initrd.img is now a symlink to boot/initrd.img-4.15.0-1-686-pae
    /etc/kernel/postinst.d/initramfs-tools:
    update-initramfs: Generating /boot/initrd.img-4.15.0-1-686-pae
    I: The initramfs will attempt to resume from /dev/md0
    I: (UUID=92dd207d-8fbb-4224-a70d-ca73e0594d8d)
    I: Set the RESUME variable to override this.
    /etc/kernel/postinst.d/zz-update-grub:
    Création du fichier de configuration GRUB…
    Found background image: /usr/share/images/desktop-base/desktop-grub.png
    Image Linux trouvée : /boot/vmlinuz-4.15.0-1-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.15.0-1-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.14.0-3-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.14.0-3-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.14.0-2-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.14.0-2-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.13.0-1-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.13.0-1-686-pae
    Image Linux trouvée : /boot/vmlinuz-4.12.0-1-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-4.12.0-1-686-pae
    Image Linux trouvée : /boot/vmlinuz-3.2.0-4-686-pae
    Image mémoire initiale trouvée : /boot/initrd.img-3.2.0-4-686-pae
    fait

    I don’t see above the installation of nvidia driver, but it works, i reboot my PC on this 4.15.0-1-686-pae kernel and dri is installed :

    $ uname -a
    Linux goup2net 4.15.0-1-686-pae #1 SMP Debian 4.15.4-1 (2018-02-18) i686 GNU/Linux

    $ glxinfo
    name of display: :0.0
    display: :0 screen: 0
    direct rendering: Yes
    server glx vendor string: NVIDIA Corporation
    server glx version string: 1.4
    (..)

    This issue is solved.

    Thank you very much for your help and sorry for the inconvenience

    Serge Le Tyrant

    Donc son indication m’a permis de résoudre le problème. Je n’y suis pas parvenu par des moyens « propres » (avec le paquet nvidia-installer-cleanup), néanmoins déplacer le répertoire /var/lib/dkms/nvidia/195.36.24/ contenant l’ancien driver (un résidu d’une ancienne installation) puis réinstaller le noyau 4.15 a permis de résoudre le problème.

    Sa réponse :

    Ok great, closing then.


    Kind regards,
    Luca Boccassi

    Puis :

    This is an automatic notification regarding your Bug report which was filed against the nvidia-legacy-340xx-kernel-source package:

    #890775: nvidia-legacy-340xx-kernel-source: v.340.106-2 doesn’t compile with linux-image-4.15.0-1-686-pae (v. 4.15.4-1)

    It has been closed by Luca Boccassi (bluca @debian.org).

    Their explanation is attached below along with your original report.
    If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Luca Boccassi (bluca @debian.org) by replying to this email.

    Puis :

    Thank you for the additional information you have supplied regarding this Bug report.

    This is an automatically generated reply to let you know your message has been received.

    Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course.

    Your message has been sent to the package maintainer(s):
    Debian NVIDIA Maintainers (pkg -nvidia-devel@lists.alioth.debian.org)

    If you wish to submit further information on this problem, please send it to 890775@bugs.debian.org.

    Please do not send mail to owner@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.


    890775: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890775
    Debian Bug Tracking System
    Contact owner@bugs.debian.org with problems

    C’est réglé. Un professionnel. Chapeau bas.

    ☑ (INFO) Le bureau MATE v.1.20.0 est cool, constaté le 18/02/2018.
    Voilà 1.5 mois que j’avais délaissé MATE pour le bureau Budgie (très bien aussi).
    Récemment une nouvelle version (v.1.20.0) est sortie et j’ai eut envie de la tester.
    Au premier coup d’œil les changements ne sont pas flagrant, je ne vois pas ce qu’ils ont amélioré.
    Néanmoins je profite de ce changement récent de mon environnement de bureau (mais pas définitif) pour noter ci-après les différences entre MATE v.20.0 et Budgie 10.4 qui me sautent aux yeux.

    Les « + » de MATE v.1.20.0 par rapport à Budgie 10.4 :
    • les bordures de fenêtre ont un effet métallique très réussi (sous Budgie il n’y a pas beaucoup de choix dans l’habillage des fenêtres car beaucoup ne fonctionnent pas)
    • j’ai enfin un menu de démarrage cohérent (dysfonctionnement de ce menu sous Budgie, sur le PC du Bottin alors qu’il fonctionne sur le PC internet)
    • le gestionnaire des applications lancées au démarrage fonctionne bien (sous Budgie il n’est pas super fiable : des applications supprimées réapparaissent parfois, et l’on ne peux pas désactiver temporairement le lancement d’une application, soit on la laisse activée soit on la supprime).
    • le lanceur d’application (par Alt F2) est de bien meilleur qualité sous MATE (celui de Budgie tient sur une ligne et ne permet de lancer que des applications avec lanceur : je ne peux pas lancer « gdebi caja » pour l’avoir en root par exemple, je suis obligé de lancer cette commande en console).
    • le fond d’écran peux s’afficher sur 2 écrans simultanément (un seul fond sur 2 écrans, et pas la reproduction du même fond sur 2 écrans).

    Les « – » :
    • Pas d’effet de transparence pour le menu en haut de l’écran (sous Budgie c’est plus beau)
    • Pas de menu de paramétrage de ma tablette graphique WACOM Intuos 3 (sous Budgie, c’est intégré au Centre de configuration)
    • Pas de paramétrage du joystick dans le Centre de Configuration (pas dans Budgie non plus, mais c’est dommage que personne n’intègre l’utilitaire « jstest-gtk » en dépôt qui est génial).
    • A voir s’il y a toujours les problèmes d’économiseur d’écran intempestif sous MATE (que l’on ne pouvait pas désactiver).

    Un coup d’œil au changelog montre effectivement que la majorité des changements ne se voient pas forcément, mais sont des améliorations de fonctionnement.

    Pas d’autres dysfonctionnements résolus dans la période.
    Rien de neuf, beaucoup de redite (peu d’évolutions dans les dépôts), ne perdez pas votre temps à lire ce qui suit.

  • Dysfonctionnements récurrents / précédents (et toujours d’actualité) :

    ☑ (PEU IMPORTANT) Quelques dysfonctionnements constatés sur le gestionnaire de fenêtre Budgie 10.4, constaté le 05/01/2018.
    j’ai testé un nouveau gestionnaire de fenêtre, Budgie (en dépôt Debian, site , GitHub), que j’utilise à présent quotidiennement en remplacement de MATE (que j’aime aussi beaucoup).
    Budgie est extrêmement bien pensé (ça sent le REX), beau, moderne, intuitif, rapide (peut-être même plus que MATE). En un mot : Génial.

    Pour l’instant je le trouve supérieur à MATE, avec quelques exceptions que je découvre au fil de mon utilisation :
    • (gênant) le lanceur d’applications de Budgie semble bugué sur l’un de mes PC :
    – sur mon PC goup2net, son menu est séparé en deux, avec d’un côté ce qui ressemble à un historique (inutilisable) d’utilisation de répertoires d’applications (dont nombreux n’existent même plus sur mon PC), et de l’autre il y a tout un tas d’icônes en vrac. Il y a peut être un moyen de changer cela, mais je n’ai pas trouvé (j’y ai passé beaucoup de temps).
    – sur mon autre PC (goup3) son fonctionnement me semble cohérent : son menu est constitué de répertoires avec des icônes.
    • (peu important) il y a moins de personnalisation de bordures de fenêtres (il y en a plein, mais beaucoup ne fonctionnent pas).
    • (peu important) Le paramétrage de l’Arrière-plan du bureau me semble perfectible :
    ⚬ le fond d’écran pour « Écran verrouillé » ne semble pas fonctionner (malgré mes changements, il affiche toujours le fond standard Debian, je me demande si ce n’est pas un logiciel de verrouillage externe qui s’affiche à la place).
    ⚬ sélection de l’arrière-plan :
    – je ne suis pas parvenu à afficher le même fond d’écran (en 3840×1200) sur les 2 écrans à la fois (j’ai 2 écrans de résolution 1920×1200 disposés côte à côte, sous Budgie il affiche donc 2 fois le même fond, alors que sous MATE je pouvais afficher un seul fond d’écran qui s’affichait dans la continuité sur les 2 écrans : l’effet était nettement plus réussi),
    – il n’est pour l’instant pas possible de choisir un autre dossier que ~/Images (or mon HOME est déjà bien rempli, je n’ai pas envie de l’encombrer davantage avec des images en nombre et taille importants).
    – le papier peint automatique (évolue au cours de la journée) ne semble pas fonctionner (il affiche un écran bleu) ou alors il faut peut être attendre très longtemps.
    • (peu important) le gestionnaire d’applications lancées au démarrage ne me semble pas très fiable : des applications désactivées lors d’une session réapparaissent parfois à la session suivante.
    • (peu important) le lanceur d’application (par Alt F2) est de qualité médiocre, il tient sur une ligne et ne permet de lancer que des applications avec lanceur (je ne peux pas lancer « gdebi caja » pour l’avoir en root par exemple, je suis obligé de lancer cette commande en console).

    Je continue à utiliser Caja (pour le gestionnaire de fichier, bien plus convivial que le vieux Nautilus dont il est dérivé) et Gedit (éditeur, au lieu de Pluma, car j’ai parfois constaté des problèmes avec son ascenseur).
    ➯ Pas d’amélioration le 01/02/2018. Pour l’instant, la version des dépôts Debian (10.4) est la dernière version sortie (du 15/08/2017). Malheureusement la version 11 à venir est prévue pour sortir en Qt, donc il est probable que je revienne sous MATE. On verra.

    ☑ (PEU IMPORTANT) Tellico 3.1.1-0.1 des dépôts Debian est bugué, constaté le 15/01/2018.
    À la mise à jour de Tellico de 3.1-0.3 (grosse et superbe mise à jour) vers 3.1.1-0.1, j’ai constaté l’apparition de nouveaux dysfonctionnements, sans constater d’améliorations visibles.
    – L’interface n’accepte pas le 29 février (29/02/AAAA) : elle efface la date et refuse toute entrée
    – Il y a un problème de synchronisation très agaçant entre la fenêtre de saisie et la fenêtre principale de Tellico. Lorsque l’on entre une modification sur une fiche et que l’on enregistre, si l’on souhaite examiner une autre fiche, la fenêtre de saisie reste bloquée sur la dernière fiche modifiée.
    J’ai donc désinstallé la version 3.1.1-0.1, réinstallé la 3.1-0.3 (qui est très très bien, très stable) et bloqué provisoirement cette version sous Synaptic (je n’ai pour l’instant pas le temps de faire un rapport de bug et de passer du temps là-dessus, j’y reviendrai lorsque j’aurais un peu plus de temps).
    ➯ Cette version est buguée et n’a toujours pas été remplacée en dépôt le 15/02/2018

    ☑ (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 »).
    ➯ Pas d’amélioration le 01/02/2018
    ➯ Pas de nouveau test le 15/02/2018

    ☑ (PEU IMPORTANT) Problème d’affichage de la prévisualisation de la police « Droid Sans Fallback » sous MATE depuis le 02/07/17.
    J’utilise 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ère la « Terminus Regular 10 ». Elle 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. »). C’est aussi le cas pour un certain nombre d’autres polices de caractère (environ 30% d’entre-elles).
    ➯ Pas d’amélioration le 16/09/2017
    ➯ Pas de nouveau test dans la période (je n’ai plus accès à MATE du fait d’un bug, voir plus haut).
    ➯ Pas d’amélioration le 31/12/2017
    ➯ Stand-by de ce signalement, car je n’utilise pour l’instant plus MATE.

    ☑ (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 avantage, çà me coûte moins chère en cartouches d’encre qui sèchent même si je ne les utilise pas. 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 …

    ☑ (PEU IMPORTANT) La distribution d’internet de l’un de mes PC vers l’autre n’est plus fiable (problème de service DNS), depuis le 01/01/2016
    Depuis début 2016 j’ai des soucis de DNS sur le PC du Bottin qui me font perdre des heures (selon les périodes).
    Au démarrage de celui-ci, la distribution d’internet depuis l’autre PC relié à ma Box (que je nomme « PC Internet ») n’est plus fiable (alors qu’elle l’était auparavant).
    Je ne sais pas pourquoi et je n’arrive pas à reproduire le problème de manière fiable.
    Il arrive relativement fréquemment que l’internet fonctionne correctement sur les 2 PC dès le démarrage et d’autres (1 fois sur 3 ou 4, c’est variable suivant les périodes) le PC du Bottin ne parvient pas à se connecter à internet.
    A noter aussi que je rencontre nettement moins de problèmes de connexions si je (re)démarre le PC Internet un peu avant le PC du Bottin.

    Lorsque cela ne fonctionne pas (plus d’internet disponible sur le PC du Bottin) :
    Le ping sur le PC du Bottin vers le PC Internet (et inversement) fonctionne bien, donc la liaison entre les 2 PC fonctionne (cela ne me semble donc pas être un problème de hardware, mais plutôt un problème de software).
    Le PC Internet a bien de l’internet, mais pas celui du Bottin.
    Les fichiers de paramétrage des adresses DNS (/etc/resolv.conf) sont correctement et identiquement paramétrés (mêmes adresses DNS) sur les 2 PC (test inutile si çà marche de temps en temps sans rien modifier, mais çà conforte).
    Depuis le PC du Bottin un « $ ping yahoo.net » (ou un « $ ping 77.238.184.150 », l’adresse de Yahoo.net) n’aboutit pas.
    ➯ Problème de passage en IPv6 ?
    Je ne pense pas car les 2 PC sont en IPv4 et l’internet fonctionne bien sur le PC Internet.
    ➯ Problème de translation de port ou d’adresse IP ?
    Je ne pense pas non plus, çà ressemble davantage à un souci d’initialisation du matériel (lié au matériel lui-même ou plutôt à son initialisation par le système d’exploitation), d’autant que si c’était un problème de configuration de fichier çà ne fonctionnerait pas de manière intermittente.

    Les 2 fichiers (sur le PC Internet et le PC du Bottin) /etc/network sont (en l’état de mes connaissances) configurés pour l’IPv4 et non pour l’IPv6 :
    allow-hotplug ethx
    iface ethx inet static
    (et non pas : iface ethx inet6 static)
    (x=0 sur le PC Internet et x=2 sur le PC du Bottin)

    Sur le PC Internet j’ai relevé il y a quelques temps les messages suivant au démarrage :
    8139too 0000:08:06.0 eth2: link down
    IPv6: ADDRCONF (NETDEV_UP): eth2: link is not ready
    En fonction des démarrages, je vois aussi les messages :
    eth0: no IPv6 routers present
    eth1: no IPv6 routers present

    eth2 = interface non reliée lors de ce message, elle n’est utilisée que pour une connexion occasionnelle du portable de Louis.
    Donc – contrairement à ce que j’ai suspecté sur l’instant (j’ai cru qu’ils concernaient le PC du Bottin), ces messages sont cohérents.

    Ce qui est étonnant est que si je met ce PC du Bottin en veille (je sélectionne un arrêt par le bouton « Mettre en veille ») après qu’il soit parvenu à se connecter à l’internet, au démarrage suivant j’ai de l’internet de manière fiable (mais c’est une situation que j’évite à cause des mises à jour quotidiennes de ce PC).
    Néanmoins si j’effectue un reboot du PC du Bottin sans aussi rebooter celui distribuant internet, il est fréquent que je n’ai plus accès à cette liaison internet au démarrage suivant.
    ➯ Le 3 novembre 2016 : 6 démarrages complets (reboot jusqu’à l’interface de MATE) nécessaires pour obtenir l’accès à internet.
    ➯ Suivants : le 26 novembre 2016 : 5, le 27 novembre 2016 : 3, le 30 novembre 2016 : 4, le 1er décembre 2016 : 4, le 4 décembre 2016 : 3, entre le 4 et le 14 décembre 2016 : en moyenne 2 à 3 démarrages, le 14 décembre : 4 démarrages.
    ➯ du 15/12/16 au 31/12/16 : la connexion a globalement été assez fiable. À noter la mise à jour de net-tools (en 1.60+git20161116.90da8a0-1), de netbase (5.3 to 5.4), scdaemon (2.1.16-3 to 2.1.17-2), tcpd (7.6.q-25 to 7.6.q-26). Ces paquets ont été mis à jour sur le PC du Bottin mais pas encore sur le PC relié à internet. Un test sera réalisé sur la prochaine quinzaine.
    ➯ Le 16/01/2017 : pas d’amélioration significative. Si je ne reboot pas le PC internet quelques secondes avant celui du Bottin, il est très difficile d’obtenir du réseau sur celui-ci (testé tout à l’heure : même après 8 ou 9 redémarrages pas de réseau sans rebooter/éteindre le PC Internet un peu avant celui du Bottin). Les 2 PC sont à jour en Debian Sid.
    ➯ Le 21/02/2017 : Là aussi c’est mieux, mais si je ne démarre pas les PC dans un ordre précis et rapprochés (d’abord le PC Internet puis quelques secondes après le PC du Bottin), çà ne fonctionne pas (ce qui est le cas par exemple lorsque le PC du Bottin se met à vérifier ses disques durs : à l’issue de la vérification il a pris du retard sur le démarrage de l’autre et il n’y a pas de réseau).
    ➯ Le 18/03/2017, le 02/04/2017 : pas d’amélioration, parfois jusqu’à 3 ou 4 démarrages sont nécessaires pour obtenir l’internet sur le PC du Bottin.
    ➯ Le 30/04/2017 : pas de gros soucis dans la période, globalement çà a fonctionné du 1er coup, mais je ne suis pas sûr que çà soit résolu pour autant. À suivre.
    ➯ Pas de changement le 02/06/2017
    ➯ Le 16/07/2017 : le réseau a nettement mieux fonctionné dans la période, sans être fiable à 100% (quelques problèmes de connexion certains jours).
    ➯ Pas d’amélioration le 07/11/2017
    ➯ Le 9/12/2017 : çà semble nettement mieux fonctionner depuis quelques jours. Néanmoins il faut encore souvent redémarrer une 2ème fois ce PC pour que l’internet fonctionne. Je vais encore attendre une quinzaine de jours pour décider si j’enlève ou non ce signalement.
    ➯ Le 1/1/2018 : aujourd’hui la connexion s’est bien faite, mais les jours précédents ont été un véritable calvaire (m’obligeant parfois à redémarrer le système jusqu’à 5 fois de suite avant qu’il n’y parvienne).
    ➯ Le 20/1/2018 : pas d’amélioration (pénible), parfois jusqu’à 3 ou 4 démarrages sont nécessaires pour obtenir l’internet sur le PC du Bottin.
    ➯ Pas d’amélioration le 15/02/2018

    ☑ (PEU IMPORTANT) Impossible de désactiver l’économiseur d’écran sous MATE, depuis l’existence de MATE vraisemblablement.
    Pas important mais très agaçant. J’aime bien jeter un oeil de temps en temps sur les paramètres du PC distribuant l’internet (occupation du réseau et du processeur), or l’économiseur se déclenche après 10-15 min. J’ai à peu près tout essayé (désactivé sous le Centre de Contrôle, désinstallé complètement les économiseurs d’écrans, sous dconf désactivé l’économiseur à la fois pour Gnome et MATE), mais rien n’y fait, il continue à s’activer. J’ai testé sous Gnome (je commençais à suspecter mon écran) : je parviens bien à le désactiver sans problème.
    Il s’agit donc bien d’un bug du bureau MATE (confirmé par mes lectures de forums).
    ➯ Pas de nouveau test dans la période, car je souhaiterai réinstaller les économiseurs d’écrans et les désactiver sous leur interface, mais Synaptic ne fonctionne plus sur ce PC.
    De toute façon MATE n’est plus mis à jour depuis quelques mois (à part un paquet il y a quelques jours).
    ➯ À noter la mise à jour de xscreensaver (5.34-2 to 5.36-1) sur le PC du Bottin. Le PC internet n’a pas été mis à jour dans la période. Je tenterai une mise à jour dans la prochaine quinzaine (début Janvier).
    ➯ Le 03/01/2017 : Mise à jour complète du PC et réinstallation de paquets relatifs aux économiseurs d’écran. J’ai réglé le déclenchement de l’économiseur d’écran sur 2 heures d’inactivité. Çà ne change rien. Dysfonctionnement non résolu.
    ➯ Le 16/01/2017 : j’ai à présent sélectionné par défaut le gestionnaire Gnome en remplacement de MATE (sans avoir désinstallé ce dernier). Avec Gnome je n’ai plus de soucis d’économiseur sur ce PC Internet. Lorsqu’une nouvelle version de MATE (la 1.18 à venir) verra le jour, il est probable que j’effectuerai un nouveau test sous MATE.
    ➯ Le 02/04/2017 : je suis finalement revenu à MATE parce que GNOME m’embête avec mes raccourcis (voir ci-après). À voir sur la durée si finalement je ne vais pas revenir à GNOME parce que cet économiseur est vraiment très très agaçant.
    ➯ Le 30/04/2017 : toujours pas d’amélioration.
    ➯ Pas de changement le 02/06/2017
    ➯ Pas de nouveau test sur ce PC tant que GKrellm ne fonctionnera pas (je l’utilise sur le PC Internet, j’aime bien l’avoir à l’écran).
    ➯ J’ai mis à jour le PC internet le 7/12/2017 : il est à présent sous Debian Sid. Mais ce dysfonctionnement n’est toujours pas résolu, impossible de désactiver ce mode d’économie d’énergie forcé.
    ➯ Pas d’amélioration le 31/12/2017
    ➯ Stand-by de ce signalement, car je n’utilise pour l’instant plus MATE sur aucun de mes PC. Budgie a ma préférence (mais j’utilise le gestionnaire de fichier Caja, qui est celui de MATE).

  • 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.