Après une réinstallation fraîche d'une Debian Bookworm et réutilisation du /home d'une Bookworm mais celle-ci mise à jour depuis un installation initiale de 2017, j'ai perdu mes keyrings.
En fait, le chemin a changé : il ne sont plus stockés dans ~/.gnome2/keyrings/ mais dans ~/.local/share/keyrings/. Solution : arrêt du service gnome-keyring-daemon (moi j'ai simplement déloggué et pris un TTY), restauration de ~/.local/share/keyrings/ vers ~/.gnome2/keyrings/, et c'est reparti.

Je n'ai par contre pas encore étudie ce qui définit ce chemin et pourquoi il n'est plus identique alors qu'à priori l'ensemble du /home a été restauré. Peut-être pour un futur édit.

ping can resolve .local domains, but e.g. host can't, which is annoying when trying to resolve the IP address of a mDNS host from a e.g. script.
Fortunately, there is avahi-resolve that can do that, and is easy enough to use in scripts.

The reason I needed that was to consolidate a setup where a network scanner provides a mDNS name, but it can't be used in the SANE device path, only the IP works. So, replace the IP field in the call with "$(avahi-resolve --name -4 NAME.local | awk '{print $2}')" and voila.

There's a lot of info on the web, but I never can find a complete canonical way of doing this when I need it, so here's mine:

On the source machine, dpkg --get-selections > my-selections (here, everybody agrees though)

On the target machine:

# apt update
# apt-cache dumpavail | dpkg --merge-avail
# dpkg --clear-selections  # that's dangerous if you don't set reasonable selections afterwards!
# dpkg --set-selections < my-selections
# apt-get -u dselect-upgrade

And voila.

Même si les explications liées ici sont un peu approximatives à priori, ça n'en reste pas moins mon problème et la solution : active le memory remapping.

Donc j'ai récemment upgradé un ordi avec une ASUS P5B d'occasion car la CM précédente n'avait que 2 solts DDR2 plus un problème (de contrôleur mémoire ?) si plus de 3Go étaient installés (OS instable + erreurs memtest). À y repenser en écrivant ça, peut-être aurais-je dû jouer avec les voltages si jamais l'option existe ? Je n'y connais pas des masses.
Mais bref, j'ai donc une P5B, tout marche bien, sauf que j'installe 5Go de RAM (2×2 + 1×1) mais le BIOS et Linux n'en voient que 4Go. Oui, 4, y'en a un qui a disparu. Je sais que mes barrettes sont bonnes, je les ai toutes testées séparément. On notera ici que j'ai bien 4Go, pas seulement les 3 l'adressage en dessous des 3Go. Et si j'en met 6 (je n'avais juste pas la barrette sous la main au premier montage, maintenant je suis à 2×2 + 2×1), je n'en vois que 5.
Bref, il semble que sans le memory remapping, le BIOS cache le 4ème Go. Si je comprends bien, c'est normal pour éviter des conflits d'adresse avec les périphériques PCI, même si pour le moment je ne me suis pas documenté plus avant et ça reste donc un peu vague dans mon esprit.

Mais bref, en résumé, activer le remapping découvre la plage du 4ème Go, quelle que soit la quantité de RAM effectivement installée.

If using the SP Flash Tool on your favorite desktop GNU/Linux distro you're experiencing upload failures, like if the communication was broken a few seconds after it started, it's probably ModemManager's fault.
SP Flash Tool is communicating with the smartphones using a USB-modem-like technique (involving cdc_acm), and doing so leads to ModemManager to think it has to do its thing, actually interfering with the communication, leading to errors like that:

cdc_acm 1-1.2:1.1: failed to set dtr/rts

Fixing this is trivial: just disable ModemManager while using SP Flash Tool, and you should be good to go.

When you change a swap partition (let's say you removed and added a new one because you wanted to change paritions layout on a non-LVM setup, and swap contents is not something to bother keeping), you'll have to update /etc/fstab; but that's not actually enough. With only this, initramfs will wait for a bit and complain that the resume partition couldn't be found. This is due to the setting in /etc/initramfs-tools/conf.d/resume which should match your preferred swap partition. Once updated, don't forget to re-run update-initramfs -u -k all.

$ dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n

Pour "corriger" les dépendances d'un paquet Debian un peu foireux, il y a plusieurs solutions. La plus maligne est sans doutes l'outil equivs qui permet de créer facilement des paquets virtuels qui fournissent des noms et/ou dépendent d'autre paquets.

Mais il y a des cas plus compliqués, par exemple avec les conflits : si on a un paquet A qui dépend du paquet B¹, mais que B² est installé et est en conflit avec B¹, on ne peut pas simplement créer le paquet virtuel B¹ qui dépend de B², puisque B² n'accepte pas que B¹ soit installé.

Mais on n'abandonne pas, et vu qu'à ce stade on est entrain de faire des gros hacks bien sales, éditons le .deb de A à la main pour le faire dépendre de B² à la place de B¹.

Pour ça, il faut connaître le format des paquets Debian, mais justement la page Wikipedia liée nous dit tout. Donc, allons-y :

$ # on va travailler dans un dossier temporaire
$ mkdir /tmp/debhack && cd /tmp/debhack
$ # on extrait les fichiers du .deb
$ ar x ~/paquet-version_arch.deb
$ # on extrait les fichiers de contrôle (ici tar.gz, mais peut être d'autre formats de tar)
$ tar xzvf control.tar.gz
$ # maintenant on s'amuse avec le fichier `control` nouvellement décompressé.  On peut faire ce qu'on veut, là on va juste changer les dépendances donc
$ sed -e 's/B¹/B²/g' -i control
$ # on en profite pour changer la version du paquet
$ sed -e 's/Version:.*$/&+local1/' -i control
$ # et à partir de là on recrée notre paquet
$ tar czvf control.tar.gz control md5sums
$ # attention, l'ordre de debian-binary est important !
$ ar cr …/paquet-version_arch+local1.deb debian-binary control.tar.gz data.tar.xz

Et voilà, on a un .deb mis à jour et tout frais.
On aurait pu aller plus loin et modifier le contenu du paquet, changer la description et je ne sais quoi. Attention cependant si vous changez le contenu du paquet (data.tar.xz), car il y a des sommes de contrôle pour chaque fichier dans le fichier md5sums de control.tar.gz, donc il faudra aussi les mettre à jour.

Vous vous souvenez peut-être de mon post blâmant journald qui polluait mes logs et remplissait /var/log ? (http://ban.netlib.re/shaarli/?RVgspw) Bon et bien j'avais assez tort, ce n'est pas directement la faute de systemd en fait (ça passe par lui, mais ce n'est pas sa faute).

Ce qui remplit /var/log c'est juste syslog, qui écrit les logs de journald sur le disque (et les écrit trois fois, je n'ai pas cherché pourquoi). Quoi qu'il en soit ça fait longtemps que syslog fait ça, mais ça n'a pas grande incidence car peu d'applications logguent via syslog.

Le vrai problème est que les développeurs de GDM ont imaginé que c'était une bonne idée que de logguer la sortie de la session X explicitement via journald au lieu du bon vieux .xsession-errors (ou de $XDG_CACHE_HOME/gdm/session.log dans les versions plus récentes de GDM). Ça a l'air gentillet dit comme ça, mais ça envoie beaucoup de choses dans jounrald, qui sous Debian les renvoie à syslog, qui les écrit sur le disque.

Bref, maintenant il faut attendre que ce problème soit corrigé dans Debian. Pour ça il y a probablement deux solutions :

1. Ne pas écrire dans journald les entrées de GDM. Ça a l'air assez simple, puisque GDM semble avoir une option de compilation pour ça, justement prévue pour les systèmes qui renvoient journald à syslog.
2. Ne pas écrire dans syslog les entrées que GDM écrit via journald. C'est peut-être malin (utiliser journald pour écrire un journal n'est peut-être pas idiot -- encore que, vu quel la sortie de la session X n'est pas vraiment un journal) mais requiert probablement une conf syslog ou journald spéciale que je ne connais pas.

(3. ne pas utiliser GDM. Là le problème est qu'avec par exemple lightdm certaines choses fonctionnent moins bien (au moins sous MATE, mais je pense que ce sera pareil sous GNOME), comme les mises en veilles/reboot/changement d'utilisateurs/délock depuis le DM, etc.)

Apparemment déjà quelqu'un s'est dit que c'était malin de mettre les logs de Xsession (donc que qu'on avait dans ~/.xsession-errors) dans /var/log/{messages,syslog,user.log}. Oui, les trois tant qu'à faire.
Enfin bref, déjà ça avait pas l'air super malin dit comme ça, mais quid de quand une application lancée par la session part en vrille et affiche tout un tas de bousin dans stderr ? Sans surprise, ces trois fichiers grossissent à vue d'œil.
Les miens ont atteint 320M chacun avant que je ne trouve et tue le programme incriminé (et encore, je m'en suis rendu compte dans la minute), ce qui m'a bouffé à peu de choses près 1G dans /var (je n'ai pas de /var, donc dans /). Et même si je n'ai pas vérifié, je pense que vu que le logger (journald) est un service système, il va avoir tous les droits pour utiliser les blocs réservés et donc remplir le FS à s'en rendre malade.
Ah le bon vieux temps où une telle chose n'aurait rempli "que" $HOME…

Enfin bref, le plus intéressant dans l'histoire est que si j'en crois la documentation de journald.conf, le comportement par défaut est de ne pas logguer les sessions avec le système. Mais ma conf de journald (celle par défaut dans Debian testing/unstable) est vide (tout est commenté) et devrait j'imagine utiliser les valeurs par défaut… enfin bref j'ai tenté de définir manuellement SplitMode=uid, on verra ce que ça donne.

Bref, je ne sais pas à qui revient vraiment la faute (journald tout pourri ou mauvaise conf dans Debian ?), mais le résultat est le même, mes logs on été pourris par une application bénigne en userspace qui est partie en vrille (comme le font et vont le faire les apps userspace). Et quid d'un petit malin qui fait ça exprès.

La suite (peut-être) au prochain numéro.

Et c'est corrigé :) https://git.gnome.org/browse/gdm/commit/?id=abaa3e6cd96ca80560848f17a6a314c8405735d6

[edit] lien à jour : https://gitlab.gnome.org/GNOME/gdm/-/commit/abaa3e6cd96ca80560848f17a6a314c8405735d6

SIGUSR1 dans est bloqué dans les sessions graphiques, merci GDM…