Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé quand je suis passé à Bookworm (Debian 12). (Oui, cet article est en retard, mais, finalement, ça ne fait qu'un an que je suis passé à Debian 12, qui avait alors huit mois.)
Pour effectuer la mise à jour, on suit la doc'.
Peu de changements sur les logiciels serveurs que j'utilise.
Les directives de configuration additional-from-auth
et additional-from-cache
n'existent plus.
En permanence, deluge consigne ce qui suit dans ~/.xsession-errors
:
[CRITICAL][twisted :147 ] Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/gtkui.py", line 246, in start
reactor.run()
File "/usr/lib/python3/dist-packages/twisted/internet/_glibbase.py", line 277, in run
self._run()
File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 1689, in main
return _Gtk_main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/twisted/internet/_glibbase.py", line 308, in _simulate
self.runUntilCurrent()
--- <exception caught here\> ---
File "/usr/lib/python3/dist-packages/twisted/internet/base.py", line 991, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/usr/lib/python3/dist-packages/deluge/core/core.py", line 345, in _on_alert_session_stats
self._update_session_cache_hit_ratio()
File "/usr/lib/python3/dist-packages/deluge/core/core.py", line 361, in _update_session_cache_hit_ratio
self.session_status['disk.num_blocks_cache_hits'] / blocks_read
builtins.KeyError: 'disk.num_blocks_cache_hits'
Il faut appliquer le patch suivant au fichier /usr/lib/python3/dist-packages/deluge/core/core.py
.
dhclient
, du paquet isc-dhcp-client
n'est plus maintenu depuis 2022, tout comme le relai DCHP de l'ISC. apt-listchanges
nous expose qu'il sera donc supprimé après la version actuelle (4.4.3), mais il est toujours dans testing, donc bon, ça risque de traîner.
NetworkManager de GNOME / Mate utilise sa propre implémentation (sudo grep dhcp /var/log/syslog
: « dhcp: init: Using DHCP client 'internal' »). (On peut lui faire utiliser dhclient.) J'imagine qu'il en va de même de systemd-networkd
. Du coup, ça ne pose pas de souci, sauf pour un client en ligne de commande dans un environnement restreint (sans systemd, quoi).
apt-listchanges
nous expose qu'il existe un paquet additionnel, cryptsetup-suspend
, qui permet de retirer la clé de déchiffrement du support de stockage d'un système intégralement chiffré avant de suspend-to-ram ou suspend-to-disk (deux modes d'hibernation). J'étais hyper sceptique. J'ai lu cet article. J'ai testé (il suffit juste d'installer le paquet précité). Ça fonctionne au poil avec mon suspend-to-ram usuel.
Ça ne démonte pas les supports de stockage externes chiffrés.
L'article sus-pointé expose que systemd-homed
permet de gérer les répertoires personnels des utilisateurs, y compris en les chiffrant, et, qu'alors, il officie comme cryptsetup-suspend
mais uniquement à leur égard.
Je n'ai pas un modèle de menace qui exige l'utilisation de cryptsetup-suspend
(sinon, j'aurais éteint mon ordi toutes ces années au lieu de le mettre en hibernation), donc je l'ai désinstallé.
Johndescs m'avait prévenu que la nouvelle interface est kikoo-moderne, reprenant l'apparence (et la non-ergonomie) des applis de messagerie "modernes" pour smartphone (messages groupés, workspace, navigation au clavier dans les onglets imprédictible car le point de départ est la dernière convers active, etc.). Donc, avant de mettre à jour mon système, j'avais gelé les paquets de Gajim ('apt-mark hold`). Néanmoins, l'ancienne version refuse de se lancer sur Debian 12 (« err (org.gajim.Gajim:2828): libsoup-ERROR **: 23:18:06.243: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported. Trappe pour point d'arrêt et de trace »). libsoup, version 2 ou 3, ne peut pas être désinstallée, car MATE et d'autres logiciels dépendent d'elle. Du coup, j'ai dû mettre à jour Gajim.
L'historique de conservation se trouve dans le menu d'une conservation (bouton tout en bas à droite). Le champ permet de rechercher par mots-clés. Pour avoir l'historique pour un jour donné, il faut cliquer sur l'icône calendrier en haut à droite.
Néanmoins, il y a le même bug qu'avec RocketChat : t'es dans l'historique à la ligne X puis pouf, à la ligne X+1 tu reviens sur le jour en cours ou sur le lendemain d'où tu étais… sans que la suite de la conversation archivée ne soit affichée. Bref, tu n'obtiens qu'une partie, aléatoire, de l'historique…
Il est possible d'exporter tout l'historique (et tous les historiques) depuis le menu comptes, modifier le compte, choisir le compte, onglet confidentialité, exporter l'historique de discussion. On obtient un fichier texte par contact. Attention avec grep
: l'heure n'étant plus affichée au début de chaque message (comme dans une appli de messagerie kikoo-moderne qui groupe les messages), un message multilignes sera tronqué lors d'une recherche par date.
Pour copier-coller plusieurs messages depuis une fenêtre de conversation, il ne suffit pas, comme avant, de les surligner à la souris (ça permet d'obtenir un seul message à la fois, appli kikoo-moderne one more time…), il faut passer la souris sur un message, cliquer sur l'icône « … » à droite du message, puis select messages, et de cliquer sur chaque message…
À cause du thème de mon environnement de bureau, indirectement, le champ de saisie est blanc et la couleur du texte… blanche. Bref, c'est inutilisable. J'ai essayé de personnaliser les couleurs dans les paramètres avancés de Gajim, mais rien ne concerne le champ de saisie. Au final, j'ai utilisé un autre thème sombre de MATE et j'ai fini par m'y habituer (d'ailleurs, il y a probablement de la config foireuse ou des paquets manquants à ce niveau-là puisque en fonction du thème choisi, mon environnement de bureau crashe, mais ce n'est pas la faute de Gajim).
Autre bug : parfois, un alt+tab (y compris à la souris) vers Gajim rame à mort, il faut plus de 5 secondes avant de pouvoir écrire en ayant le retour de ce qu'on écrit. On dirait un bug de rafraîchissement de la fenêtre. Il suffit de fermer et de re-ouvrir Gajim pour corriger temporairement ce problème. J'ai trouvé un signalement similaire dans le bugtracker de Gajim. A priori, ça sent le bug GTK ou plus loin. Dans mate-tweak
, onglet fenêtres, j'ai essayé de changer le gestionnaire de fenêtres (avec ou sans composition, etc.), sans succès (sur le moment, ça semble améliorer les choses, mais non, et ce n'est pas reproductible).
Un bug n'est toujours pas corrigé : j'ai configuré Gajim pour ne pas changer d'état (absent, pas dispo) automatiquement et pour ne pas le transmettre à mes interlocuteurs. Je ne change jamais mon état manuellement. Pourtant, mes contacts voit « Guigui est maintenant en ligne » alors que je l'étais déjà, et ça correspond bien à mon inactivité sur l'ordi…
Ce paquet fournit les scripts tlsa, sshfp et openpgpkey.
Comme dans une version de Debian sur deux, soit il n'est pas empaqueté, soit ça déconne (cette fois-ci, c'est le cas de sshfp).
J'ai récupéré les scripts dans le dépôt git du projet et les ai mis dans /usr/local/bin
. Fin de chantier.
Il disparaît des dépôts logiciels officiels de Debian. On avait été informé lors du passage à Debian 11.
Dans mon cas, mate-sensors-applet
utilise udisks2
et ça fonctionne, donc je n'ai pas besoin d'aller plus loin. Sinon, il est possible d'utiliser le module noyau « drivetemps » (il faut le charger soi-même).
Désormais, il comporte un onglet « I/O » qui ne dépend même pas d'iotop
.
Éditeur de la carte géographique OpenStreetMap.
À son lancement, j'ai l'erreur suivante :
Using /usr/lib/jvm/java-17-openjdk-amd64/bin/java to execute josm.
Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.web not found
Solution : apt install openjfx
. Simple.
Simplifie l'installation de la libdvdcss qui permet de lire des DVD (avec VLC, par ex.).
Ça télécharge la lib, puis :
libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: Réussi
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
Sur le moment, puisque je ne mate pas de DVD, je n'avais pas de temps à perdre, donc j'avais apt remove libdvd-pkg
. Basique. Cependant, aujourd'hui, un an plus tard, je constate que apt install libdvd-pkg
fonctionne parfaitement. Il s'agissait donc d'une erreur temporaire côté VLC (qui héberge la libdvdcss).
Permet de lire et supprimer les métadonnées d'une palanquée de types de documents.
Il me crache l'erreur : « no module named libmat2 ».
Solution : apt install --reinstall mat2
. Simple.
The packages nginx-core, nginx-full, nginx-light, nginx-extras are deprecated. Packages no longer distribute the nginx binary and are replaced by a metapackage to keep upgrades smooth.
Please simply install 'nginx' and 'libnginx-mod-...' modules You need instead of these packages.
Un client RDAP pour interroger les bases de données publiques visant les objets d'Internet (adresses IP, noms de domaine, numéros d'AS).
Il m'affiche l'erreur « bash: /usr/local/bin/nicinfo : ne peut exécuter : le fichier requis n'a pas été trouvé ».
/usr/local/bin/nicinfo est un programme Ruby. Il énonce :
# The application 'nicinfo' is installed as part of a gem, and
# this file is here to facilitate running it.
Il serait distribué sous forme de gem (un paquet Ruby, quoi). Or, gem list | grep nicinfo
retourne une liste vide.
Solution : sudo gem install nicinfo
. Basique.
Un nouveau composant (une section) dans les dépôts logiciels officiels qui contient juste les firmwares non-libres (alors que non-free contient en sus des logiciels privateurs).
Après vérification, j'ai toujours besoin de firmware-iwlwifi
pour ma carte Wi-Fi Intel commercialisée en 2013…
La suite de logiciels NTP (ntpd, ntpq, ntpdate, etc.) n'est plus celle de ntp.org, mais du fork ntpsec.org. Source.
Désormais, le fichier de conf' est /etc/ntpsec/ntp.conf
, donc je supprime /etc/ntp.conf
et /etc/cron.daily/ntp
(purge des statistiques que je ne gènère pas). Je stocke désormais le décalage de l'horloge (driftfile) dans /var/lib/ntpsec/
. Pour éviter l'écriture, dans son journal, d'une erreur non bloquante « statistics directory /var/log/ntpsec/ does not exist or is unwriteable, error No such file or directory » alors que je n'utilise pas les stats (je n'ai positionné aucune directive de configuration en ce sens), j'ai ajouté statsdir /var/lib/ntpsec/
dans ma config.
systemctl <action> ntp
continue de fonctionner grâce à un alias fourni par l'unit ntpsec. Le processus se nomme toujours ntpd.
On peut donc effacer /etc/ntp.conf
et /var/lib/ntp
.
D'une part, SSH désactive l'algorithme ssh-rsa, car il utilise SHA-1. C'était déjà le cas dans Ubuntu 22.04 (puisqu'une nouvelle version d'Ubuntu sort plus fréquemment que Debian).
D'autre part, j'utilise des enregistrements DNS de type SSHFP. Sur mes serveurs dont le support de stockage est intégralement chiffré, j'ai deux enregistrement SSHFP : l'un pour le système régulier, l'autre pour l'initramfs qui me permet de déverrouiller mon système chiffré.
Or, depuis sa version 8.7, OpenSSH n'accepte plus qu'un seul SSHFP par machine :
debug3: verify_host_key_dns
debug1: found 2 secure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 1 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 1 fptype 2
debug3: verify_host_key_dns: checking SSHFP type 1 fptype 2
debug1: verify_host_key_dns: failed SSHFP type 1 fptype 2
debug1: mismatching host key fingerprint found in DNS
À regret, j'utilise la même paire de clés pour mon système et son initrd…
Passage à la version 3. Depuis cette version, le SECLEVEL 1 désactive SHA-1, qui est nécessaire pour utiliser TLS 1.0 et TLS 1.1. Donc, sur les bouses, il faudra diminuer le niveau de sécurité (SECLEVEL 0) dans le fichier de config' d'OpenSSL ou du logiciel… voire le recompiler.
D'une part, OpenVPN est adossé à OpenSSL, qui, comme dit supra, désactive plusieurs vieux algorithmes de condensation et de chiffrement, les clés < 1024 bits, TLS < 1.2, etc. Si la négociation des algos entre serveur et clients n'est pas activée et que l'un des deux utilise des algos abandonnés, le VPN ne sera pas établi.
D'autre part, c'est l'arrivée, dans Debian, du Data Channel Offload (DCO). OpenVPN tourne à la fois dans l'espace noyau (kernel-land) et dans l'espace utilisateur (userland) en fonction de la fonctionnalité (ex. : le réseau, les interfaces de type TUN, relèvent de l'espace noyau, alors qu'OpenVPN lui-même tourne en espace utilisateur). Il y a donc de nombreux transferts, en RAM, entre ces deux espaces. Cela ralentit les performances, et donc le débit, d'un tunnel OpenVPN. DCO est un module pour Linux qui fait remonter l'essentiel des opérations dans le noyau (pas uniquement la cryptographie, contrairement à ce qu'expose apt-listchange
). Notons que le concurrent, Wireguard, tourne essentiellement dans l'espace noyau.
Pour l'instant, DCO repose sur DKMS donc c'est pas optimal (il faut les entêtes de programmation du noyau, compiler le noyau, DKMS = hooks apt, etc.).
Mise en place : sudo apt install linux-headers-$(uname -r) openvpn-dco-dkms
. Puis redémarrer le serveur ou le client.
Dans le journal d'OpenVPN :
Avant : « Note: Kernel support for ovpn-dco missing, disabling data channel offload. »
Après : « DCO version: 0.0+git20231103 »
On voit également DCO dans ip -d l
(dernière ligne) :
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none promiscuity 0 allmulti 0 minmtu 68 maxmtu 65463
ovpn-dco addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536
Le passage de PHP 7.4 à 8.2 pique…
create_function()
n'existe plus pour créer une fonction anonyme… On peut soit déclarer directement une fonction anonyme (ça devient illisible), soit utiliser une fonction nommée standard. Exemple :
# add_filter('login_errors',create_function('$a', 'return null;'));
$nologinfo = function ($a) {
return null;
};
add_filter('login_errors', $nologinfo);
WordPress crache « PHP Warning: Constant FORCE_SSL_ADMIN already defined » ? Solution ici.
La fonction strftime() est obsolète, donc PHP affiche une notice de dépréciation. Shaarli l'utilise dans les templates, ce qui complique sa substitution…
Une méthode d'une classe qui implémente une interface doit avoir le même type de retour que dans l'interface (logique…). Sinon, une notice de dépréciation est affichée. Il est possible d'ajouter « #[\ReturnTypeWillChange] » avant la méthode en question pour que PHP n'émette pas la notice. Dans shaarli, c'est la classe de stockage des liens (LinkDB), qui est centrale, qui est impactée, ce qui signifie que, tôt ou tard (on évoque PHP 9), ma version de shaarli ne pourra plus fonctionner sur un PHP à jour.
En production, j'aime bien avoir des journaux verbeux afin de détecter les problèmes et les corriger. Mais, en l'état, je ne peux rien corriger, et mon shaarli génère 22 Mo de journal par tranche de 12 h, ce qui n'est pas tenable (je pourrais stocker 1,3 Go par mois, ce n'est pas la question, mais ça noie les autres erreurs).
A priori, il existe une version de shaarli qui, à la fois, n'utilise plus LinkDB, et n'utilise pas encore composer. En attendant d'y réfléchir, dans index.php de Shaarli, je remplace la ligne « error_reporting[…] » par error_reporting(E_ALL^E_DEPRECATED);
afin de tout consigner, sauf les dépréciations.
ERROR Fatal Error 8192: Creation of dynamic property YoutubeBridge::$request is deprecated in bridges/YoutubeBridge.php line 321
Hé oui, il n'est plus possible d'affecter un membre à une classe qui ne le déclare pas (logique, encore)… Solution : utiliser YouTubeCommunityTabBridge à la place de YouTubeBridge.
PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function ttrss_error_handler()
Ben oui, PHP devient un peu exigeant sur l'ordre des paramètres, entre ceux obligatoires ou facultatifs, quitte à utiliser les paramètres nommés.
Je décide de mettre à jour ttrss tout en sachant que, comme d'habitude, ça va être douloureux (l'absurdité de considérer que la branche master d'un dépôt git constitue une version stable d'un logiciel)…
Premier problème : « Exception while creating PDO object:could not find driver ». La syntaxe du fichier config.php a changé. Désormais, il faut utiliser « PUTENV() »…
Deuxième problème : sur l'interface web, j'ai l'erreur « Vous n’avez pas les permissions nécessaires pour exécuter ce script. ». OK, comme d'hab, ça essaye de mettre à jour la base de données alors que je suis connecté, sur l'interface web de ttrss, avec un compte utilisateur standard (!= administrateur de ttrss).
Troisième problème : comme d'hab avec ttrss, le script de mise à jour échoue. Je dois jouer à la main la modification de la BDD de chaque version : mysql -u <nom_utilisateur> -p <nom_BDD> < /chemin/vers/ttrss/sql/mysql/migrations/140.sql
puis 141.sql puis…
Quatrième problème : les fichiers SQL précités, à partir du 143 (jusqu'au dernier, 147), ne met plus à jour, dans la BDD, la version du schéma de la BDD. Donc l'installateur veut toujours effectuer une mise à jour de la BDD (alors qu'elle est bien à la dernière version)… (Tu sens le problème de qualité du code ?) Je n'ai plus qu'à le faire moi-même : echo 'update ttrss_version set schema_version = 147;' | mysql -u <nom_utilisateur> -p <nom_BDD>
.
Cinquième problème : les favicons des sites suivis en RSS sont désormais stockés dans cache/feed-icons (au lieu de feed-icons), ce qui est une bonne chose. Néanmoins, le script qui met à jour les flux (update_daemon2.php
) est lancé, par systemd, avec un utilisateur différent, qui n'a pas la permission d'écrire ici, donc aucune icône n'apparaît dans la liste des flux suivis dans l'interface web de ttrss. Je corrige ça avec un chmod
classique.
Sixième problème : sur certains flux RSS en erreur, le script de mise à jour des flux reçoit une erreur de la BDD : « Exception while updating feed 80: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'last_error' at row 1 ». Forcément, le flux RSS est en erreur HTTP 404, ce qui déclenche une exception dans le script de mise à jour, qui essaye de stocker toute la stacktrace dans un varchar de taille 250… Contournement : dans classes/RSSUtils.php
, j'ai remplacé la ligne « 'last_error' => $error_message, » par « 'last_error' => mb_substr($error_message, 0, 250), ».
J'utilise yt-dlp
pour récupérer des vidéos YouTube ou autres. Comme YouTube change des bricoles tous les quatre matins pour entraver toute rétro-ingénierie, je l'installe et le mets à jour avec pip3
. Bien que je sois le seul utilisateur de mon ordi, je l'installe « system-wide », pour tous les utilisateurs, dans /usr/local/bin
.
Après mon passage à Debian 12, je tente de mettre à jour yt-dlp avec pip3
et… c'est le drame :
$ sudo pip3 install -U yt-dlp
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install.
If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
Ben oui, apt-listchanges nous avait prévenu :
python-pip (23.0+dfsg-2) unstable; urgency=medium
This version of pip introduces PEP 668 support. Debian's python3.11 interpreter will soon (>= 3.11.2-3) declare the installation to be EXTERNALLY-MANAGED, instructing pip to disallow package installation outside virtualenvs.
See: https://peps.python.org/pep-0668/
Practically, this means that you can't use pip to install packages outside a virtualenv, on Debian's Python interpreter by default, any more.
You can override this behaviour by passing --break-system-packages to pip install, but be aware that if you are running pip as root, doing so can break your system.
See /usr/share/doc/python3.11/README.venv for more details.
Version courte : pour éviter les conflits (de bibliothèques de fonctions, etc.), notamment avec apt
, désormais chaque logiciel Python est dans un conteneur (venv) qui lui est dédié.
Rien n'empêche de créer un venv dédié à un logiciel dans /usr/local, avec un lien symbolique dans /usr/local/bin.
Pour se simplifier la vie, /usr/share/doc/python3.11/README.venv
recommande d'utiliser pipx
qui est empaqueté dans les dépôts officiels Debian.
Mais, que l'on soit simple utilisateur ou root, pipx
crée les venvs dans le répertoire personnel de l'utilisateur qui l'appelle… tout en prétendant que le logiciel est disponible globalement (tout en ayant un doute sur le PATH)… :
$ sudo pipx install yt-dlp
⚠️ Note: yt-dlp was already on your PATH at /usr/local/bin/yt-dlp
installed package yt-dlp 2023.12.30, installed using Python 3.11.2
These apps are now globally available
- yt-dlp
⚠️ Note: '/root/.local/bin' is not on your PATH environment variable. These apps will not be globally accessible until your PATH is updated. Run `pipx ensurepath` to
automatically add it, or manually modify your PATH in your shell's config file (i.e. ~/.bashrc).
done! ✨ 🌟 ✨
Pour rendre un logiciel Python disponible pour tous les utilisateurs (globalement), il existe l'option --global
de pipx
… qui n'est pas dispo avant sa version 1.5, alors que Debian 12 embarque sa version 1.1… Il est possible de passer des variables pour contourner ça.
En résumé, voici ce que j'ai fait pour avoir un yt-dlp
accessible à tous les utilisateurs de ma machine (le bazar est rangé dans /opt/pipx
, un lien symbolique est créé dans /usr/local/bin
qui est dans le PATH, et le manuel est déposé au bon endroit) :
$ sudo mkdir /opt/pipx
$ sudo PIPX_HOME=/opt/pipx PIPX_BIN_DIR=/usr/local/bin PIPX_MAN_DIR=/usr/local/share/man pipx install yt-dlp
L'ennui, c'est qu'il faut rappeler ces variables d'environnement lorsque l'on veut mettre à jour yt-dlp : sudo PIPX_HOME=/opt/pipx PIPX_BIN_DIR=/usr/local/bin PIPX_MAN_DIR=/usr/local/share/man pipx upgrade yt-dlp
. Vivement le --global
.
Je n'ai plus de son dans VLC, sur PeerTube, etc. VLC met trois plombes à se lancer, il ne lit pas les fichiers multimédias, comme s'il était en IO wait.
PipeWire devient le serveur de son par défaut dans un environnement MATE. J'ai installé le paquet suivant sans trop savoir pourquoi puis j'ai redémarré mon ordi (je n'ai pas trouvé quel service redémarrer, et la réouverture de ma session graphique n'a produit aucun effet) : apt install wireplumber
.
Pour l'instant, j'utilise PipeWire en duo avec PulseAudio (via pipewire-pulse
) sans trop savoir comment ça ils articulent, et avec pavucontrol
pour régler le volume (il faudra que j'étudie comment on fait avec PipeWire).
Permet de diffuser / enregistrer l'écran d'un ordiphone Android sur son ordi et d'interagir avec ledit smartphone depuis un ordi.
Il est pas disponible dans les dépôts officiels de Bookworm. :( Mais il est dans unstable, donc il va peut-être revenir à la prochaine version stable.
Je pensais que la grande transition /{bin,lib,sbin} vers /usr/{bin,lib,sbin} avait eu lieu lors de mon passage à Debian 10, mais a priori, non.
J'ai eu un message d'erreur, uniquement sur mon ordi de travail, pas sur mes serveurs :
Paramétrage de usrmerge (35) ...
FATAL ERROR:
Both /bin/open and /usr/bin/open exist.
You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.
E: usrmerge failed.
dpkg: erreur de traitement du paquet usrmerge (--configure) :
le sous-processus paquet usrmerge script post-installation installé a renvoyé un état de sortie d'erreur 1
Des erreurs ont été rencontrées pendant l'exécution :
usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)
Flemme de chercher la cause, donc apt install --fix-broken
. Nouvelle erreur :
Paramétrage de usrmerge (35) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libmnl.so.0 and /usr/lib/x86_64-linux-gnu/libmnl.so.0 exist.
You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.
E: usrmerge failed.
dpkg: erreur de traitement du paquet usrmerge (--configure) :
le sous-processus paquet usrmerge script post-installation installé a renvoyé un état de sortie d'erreur 1
Hum… /lib/x86_64-linux-gnu/libmnl.so.0 est un lien vers /lib/x86_64-linux-gnu/libmnl.so.0.1.0 qui est un lien vers /usr/lib/x86_64-linux-gnu/libmnl.so.0.1.0… Donc c'est plutôt bien… Je supprime /lib/x86_64-linux-gnu/libmnl.so.0.
Paramétrage de usrmerge (35) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libfuse.so.2 and /usr/lib/x86_64-linux-gnu/libfuse.so.2 exist.
You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.
E: usrmerge failed.
dpkg: erreur de traitement du paquet usrmerge (--configure) :
le sous-processus paquet usrmerge script post-installation installé a renvoyé un état de sortie d'erreur 1
Des erreurs ont été rencontrées pendant l'exécution :
usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)
Hum… /lib/x86_64-linux-gnu/libfuse.so.2 est un lien vers /lib/x86_64-linux-gnu/libfuse.so.2.9.9, et /usr/lib/x86_64-linux-gnu/libfuse.so.2 est un lien vers /usr/lib/x86_64-linux-gnu/libfuse.so.2.9.7. Attention, il y a une différence de version. Je supprime /usr/lib/x86_64-linux-gnu/libfuse.so.2 et /usr/lib/x86_64-linux-gnu/libfuse.so.2.9.7 (ancienne version).
update-alternatives --config open` + valider l'existant (/usr/bin/run-mailcap)
apt install --fix-broken
apt install --reinstall libmnl0 libfuse2
Fin de chantier.
(Après avoir corrigé le problème PulseAudio / PipeWire rapporté supra.)
Le nombre d'images par seconde semble inférieur à 25, je sens une latence permanente. J'ai une bande noire en bas de certaines vidéos. VLC n'arrive pas à décoder certaines images, je vois une bouillie de pixels, il affiche ce qui suit sur la console et, si je reviens en arrière dans la vidéo, au bout d'un moment, les images ne sont plus de la bouillie.
libvdpau-va-gl: Decoder::Render_h264(): no surfaces left in buffer
libvdpau-va-gl: Decoder::Render_h264(): no surfaces left in buffer
libvdpau-va-gl: Decoder::Render_h264(): no surfaces left in buffer
libvdpau-va-gl: Decoder::Render_h264(): no surfaces left in buffer
libvdpau-va-gl: Decoder::Render_h264(): no surfaces left in buffer
libvdpau-va-gl: Decoder::Render_h264(): no surfaces left in buffer
VDPAU est le machin de NVIDIA pour décoder les vidéos sur le GPU. Je n'ai pas besoin de ça, mon CPU est largement assez puissant. Je le désactive : dans le menu outils de VLC, préférences, entrée/codecs, passer le « décodage matériel » de « automatique » à « désactiver ». Problème résolu.
Sur l'une de mes machines virtuelles distantes, rien ne s'affiche sur le VNC après l'initrd (pas de demande de login, pas de console, rien). Si j'envoie ctrl+alt+F5 ou F3 ou F2, etc., je vois bien, en SSH, des processus agetty apparaître. Évidemment, je pense avoir la même conf' GRUB & co que sur mes autres machines distantes.
Johndescs pense à un sous-système, genre DRM ou KMS, qui fait le malin, qui tente de changer la résolution ou autre paramètre de la carte graphique virtuelle, et se vautre.
Sur la machine en question, lspci -v | grep -i vga
ne renvoie rien… car il ne parvient pas à identifier les périphériques et m'affiche uniquement leur identifiant. La table de correspondance /usr/share/misc/pci.ids
est absente. sudo apt install pci.ids
. La commande précitée affiche désormais « VMware SVGA II Adapter ». Voilà une différence avec mon autre machine virtuelle distante qui, elle, affiche « Cirrus Logic GD 5446 ».
En cherchant « vga » et « vmwgfx » (nom du pilote graphique de VMware) dans kern.log :
kernel: [ 40.962977] vmwgfx 0000:00:02.0: vgaarb: deactivate vga console
kernel: [ 41.040496] vmwgfx 0000:00:02.0: [drm] Running on SVGA version 2.
kernel: [ 41.040678] vmwgfx 0000:00:02.0: [drm] MOB limits: max mob size = 0 kB, max mob pages = 0
kernel: [ 41.040693] vmwgfx 0000:00:02.0: [drm] Maximum display memory size is 16384 kiB
kernel: [ 41.040696] [drm:vmw_probe.cold [vmwgfx]] *ERROR* Hardware has no pitchlock
kernel: [ 41.045327] vmwgfx: probe of 0000:00:02.0 failed with error -38
L'hypothèse de Johndescs se confirme…
J'ai décidé d'empêcher le chargement du pilote vmwgfx en ajoutant ce qui suit dans /etc/modprobe.d/blacklist.conf
:
blacklist vmwgfx
install vmwgfx /bin/true
Fin de chantier.
#Debian 11 à Debian 12