Reprise du message précédent :

C’est ce qui est arrivé en février dernier, donc sûrement aussi cette fois-ci.
 

C’est ce que tu avais dit l’année dernière, en gros. Parce que c’est vrai que, plus d’une fois, le noyau LTS m’a servi de roue de secours quand le normal me posait des problèmes (heureusement résolus ensuite). Mais si jamais j’avais des soucis toujours en cours avec le 5.15 et que je restais sur le 5.10 en attendant que ce soit résolu, ben, je serais marron si je faisais pas gaffe (d’ailleurs, ça s’est joué de peu que je ne le voie pas avant de confirmer le lancement du téléchargement, cette fois)…
 
C’est d’ailleurs pour ça qu’il faut se retenir de nettoyer trop vite le cache des paquets téléchargés (j’en connais qui font ça dès que l’opération de mise à jour est finie). Perso, je ne purge ce cache qu’une fois la partition / déclarée trop remplie.
 

IMO leur politique pour la version du lts devrait être "la dernière branche lts tant qu'elle est inférieure à la branche mainline"
Donc on devrait rester en 5.10.xx jusqu'à ce que le package linux mainline passe en 5.16.xx.
Et je parle bien du package, pas de la sortie officielle pour éviter effectivement que les utilisateurs qui voient le package lts comme une roue de secours se retrouvent avec deux fois la même version.

Pourquoi ne pas compiler votre propre noyau ou en récupérer un sur AUR, au cas où vous auriez un souci avec les kernel officiellement supportés ?

Je disais déjà, à l’époque, que les mainteneurs pourraient quand même se concerter un minimum, oui.
 

On peut et j’avais aussi parlé de ça, mais je ne me vois ni faire une compilation du noyau sur le Core 2 Quad du PC fixe (et encore moins le Core 2 Duo du portable), ni aller récupérer une version précompilée de celles d’AUR auprès d’un dépôt tiers, fût-il géré par un utilisateur de confiance.
 

Complètement!
Ca ne devrait pas être permis.
 
Je ne comprend pas comment on peut en être choqué, nous simple utilisateurs, et les devs eux rien...

En faisant un pacman -Syu j'ai ce message :
 

 
Quelle est la meilleure réponse à la question ici ?
 
 

Là, spontanément, je dirais : la version qui correspond le plus à ton DE.
 
Tu peux avoir plus d’infos sur la fiche de chaque déclinaison, sur le site :
https://archlinux.org/packages/?q=xdg-desktop-portal

J'ai sélectionné xdg-desktop-portal-kde, ça semble Ok, j'utilise plasma.

Sur un dell 13 récent depuis une MAJ j'ai une perte de son lors de la mise en veille
 
Je suis obligé de faire un rmmod snd_sof_pci_intel_tgl && modprobe
 

 
Y'a des gens qui ont le même problème .?

J’utilise pas la veille, mais les seules MAJ liées au son de ces derniers jours sont :

• jack2 (mise à jour du paquet)
• pipewire (idem).

J'ai eu une MAJ kernel aussi et c'est des erreurs de module.

Parlons-en, des modules…

Y a du changement, dans la gestion des firmwares : pour gagner de la place (dans les 600 Mio, quand même !), non seulement ceux-ci sont désormais compressés en XZ (algo LZMA, le même que celui du format 7z), mais le paquet « linux-firmware » est désormais séparé en plusieurs, notamment pour en extraire des firmwares assez lourds de matériels peu répandus (adaptateurs serveurs ou réseau 10 Gbps ; rien que je n’utilise sur mes bécanes) :

https://archlinux.org/news/linux-fi [...] splitting/

Et j’ai vu s’installer un nouveau paquet, « linux-firmware-whence », en complément de l’autre.

Ce qui fait qu’à la régénération des initramfs du nouveau noyau Linux 5.16.2, ce ne sont plus trois lignes indiquant des modules potentiellement manquants pour l’image fallback, mais sept !

(En 2014-2015, quand j’ai installé Arch pour les premières fois, il n’y avait que les wd719x et aic94xx qui manquaient ; au moment du passage au noyau 5.8, la ligne pour xhci_pci s’est rajoutée)

Voilà. RAS pour le reste : le redémarrage s’est fait sans encombres sur les deux ordis, donc tout va bien.

En gros pour être serein (la peur de manquer de firmwares) il faudrait installer tous les paquets de type "linux-firmware", en suivant l'adage du "mieux vaut en avoir trop que pas assez" ? :

Avec la taille des SSD qui augmente on peut maintenant voir très large pour la taille de la partition système qui héberge archlinux (chez moi la partition "/" fait 208 Go, elle est remplie à 28%).

Si on a compilé et installé des noyaux linux personnalisés alors il faut vérifier que cette option de configuration est bien activée dans la configuration du noyau :

Tu peux ouais, mais la probabilité d'avoir besoin des autres paquets est relativement faible je crois.

Je pense que je vais installer en additionnel :

- linux-firmware-marvell  : "marvell" c'est un nom que je vois souvent dans les articles de périphériques, même si j'en ai pas il est possible que je branche un jour en USB un truc qui se réfere à du marvell (contrôleur réseau, bluetooth, wifi etc...)

- linux-firmware-qlogic : idem, j'ai déjà vu quelque part le nom "qlogic", dans le doute je l'installe quand même

- linux-firmware-whence : pas d'infos sur ce paquet, mais dans le doute je l'installe quand même

 
Si tu étais sous windows, tu installerais tous les drivers que tu trouves, juste au cas où ?

Par défaut il me semble que les versions récentes de windows viennent déjà avec une grosse base de pilotes installée par défaut, pour garantir le "plug and play" pour beaucoup de périphériques .

Pour du matériel embarqué, nomade (rasperry pi, tablette) en effet il est préférable de ne pas trop charger la barque, l'espace de stockage pouvant être limité et de toutes façons les capacités d'extensions (carte PCI, ports USB) étant limités sur ce type de matos.

Mais sur un PC classique on peut je pense "se faire plaisir" avec des firmwares/pilotes qu'on garde sous le coude au cas où.

C'est sur, si tu te sens mieux avec je ne vois pas de soucis, quelques Mo de plus de nos jours ca ne va pas changer grand chose!

« / » fait 40 Gio sur le PC fixe et 20 Gio sur le portable (ouais, j’aurais dû la monter au moins à 40 lors de la réinstallation de 2016…). Mais non : si j’ai pas besoin de ça, je vais pas les installer pour rien. Et pour autant que je peux en dire, j’en ai justement pas du tout besoin.
 

C’est pas « dans le doute » : pour lui, t’as pas le choix, parce que c’est linux-firmware lui-même qui te l’impose. C’est le seul qui n’est pas facultatif, dans le lot. Et c’est vrai qu’ils sont assez avares en infos, pour celui-là.

 
Bonjour,
Je l'ai vu passer aussi lorsqu'il s'est installé et l'ai aussi sous Fedora. A priori contient les fichiers d'info de licences et de sources, si j'ai tout compris    L'arborescence des licences... Whence se traduit par "de quelle origine"  
https://reposcope.com/package/linux-firmware-whence
 
edit:
Pour les curieux allez voir /usr/share/licenses/linux-firmware-whence/WHENCE  
et si j'ai toujours bien compris sera mis à jour à chaque commit ou ajout d'un driver, ou pour refléter une modification de licence.

[HS]
Il me semble maintenant que Windows installe les pilotes via WU durant la post-installation et n'embarque au'une quantité modérée de pilotes pour mener à bien l'installation.
[/HS]

Et tu veux pas l'étendre ?

Si, c’est certainement faisable depuis un live GParted, mais il paraît que l’opération risque de prendre un certain temps (surtout sur un HDD avec une partition /home bien remplie, même si je peux largement la réduire de 20 Gio, puisque j’en ai encore 200 de libres actuellement), surtout à cause du déplacement de partition qu’il va falloir opérer…
 
Mon HDD (1 Tio) est organisé comme suit :

Mais bon, ça n’urge pas non plus : en ce moment, j’ai encore 3,8 Gio de libres sur /, et un « sudo pacman -Scc » me redonne de la tranquillité pour environ un ou deux mois, selon l’abondance et la taille des MAJ…

Je pense que le redimensionnement ira assez vite avec Gparted live CD, un peu moins d'une heure,
comme étapes dans Gparted Live Cd avec la souris :

- réduire le /home vers la droite, en déplaçant la borne de début de la partition
- augmenter la taille de / (pour être tranquille pendant encore plusieurs années : un / de 80 Go)
- cliquer sur le bouton de confirmation, les 2 étapes s’enchaîneront alors

avant de redimensionner : sauvegarder les fichiers les plus importants, bien recharger la batterie du portable (en cas de coupure de courant), ou bien utiliser un onduleur.

Si tu as peur de tout foirer (et que tu as 86 euros ) alors il existe une méthode qui ne touche pas au HDD :
 
- acheter un SSD de 1 To
- sortir le HDD du portable
- mettre le SSD à la place
- avec CloneZilla : tu clones le contenu du HDD vers le SSD
- refaire la taille des partitions du SSD avec Gparted Live CD (possible que CloneZilla donne aussi la possibilité de redimensionner)

Sa machine est assez ancienne (Core2Duo). Perso, je ne ferrais pas cet investissement, sauf si une utilisation ultérieure est possible en cas de décès de cette dernière.

Oui c'est pas faux,

ceci dit le disque dur mécanique c'est le plus gros goulot d'étranglement sur un PC (avec le manque de mémoire vive), en passant au SSD il aura l'impression d'avoir acheté un nouveau PC, le boot ultra-rapide, les programmes qui se chargent en un éclair, le "pacman -Syu" bien plus rapide (pour les phases de début quand il scanne ce qui est installé comme paquets).

Sur mon PC je tourne encore avec un core 2 duo (version quad, Q9650 3 Ghz), avec 8 Go de ram et un SSD, hormis le cas de la vidéo 4K, des jeux récents ça tient encore la route.

J’aurais pu mettre un SSD… Mais quand j’ai voulu installer Arch en dur, en avril 2015 (après avoir fait joujou dans une VM VirtualBox depuis le mois d’août précédent), j’ai pas osé parce que j’étais pas sûr que cette machine accepterait un SSD.
 
Cela dit, même avec un disque dur mécanique, j’ai bien senti une différence de performances et de vitesse d’exécution par rapport à ce que j’avais avec Windows (surtout dans les phases de démarrage et arrêt, et encore plus depuis que Windows 10 est sorti) !
Le passage à Arch en dur, ça, ça a été sa deuxième vie ! Et le plus beau, c’est que ça tourne toujours aussi bien que depuis bientôt 7 ans d’usage quotidien (si on oublie que j’ai dû changer le DD qui est tombé en panne en juillet 2016, après seulement 1 an et quelques mois…).
(D’ailleurs, je me rends compte que cet ordi portable a désormais passé plus de temps à tourner sous Linux que sous Windows, quelle que soit la version de ce dernier à avoir été installée dessus)
 
Le démarrage met environ 30 secondes (du chargement du noyau à l’apparition de l’écran de connexion de LightDM), et entre 5 et 10 pour l’extinction (c’est plus long quand je l’éteins pour la nuit après 0h, et je purge pourtant le swap avant de lancer l’arrêt !).
À comparer avec Windows 10, qui met sur cet ordi au moins 3 minutes avant d’afficher enfin le Bureau (un seul compte, ouvert automatiquement), et peut mettre encore plus de temps avant d’enfin bien vouloir s’arrêter…
 
Ayant connu l’Amstrad PC-1512 (t’as jamais ouvert le répertoire C:\Gemapps dans GEM sur cette machine ? Il mettait au moins deux minutes à afficher son contenu !), puis les « vrais » PC avec un 486SX à 25 MHz pour commencer, le fait d’attendre un peu pour avoir XFCE qui se charge¹, ou les logiciels que j’utilise quand c’est la première fois depuis le (re)démarrage ne me dérange pas. Je suis pas pressé à ce point (même si je ne nie pas que les promesses des SSD et notamment les nVME sont bien alléchantes).
 
¹ … Oui, bon, le PC fixe qui met en moyenne 2 minutes pour ça à chaque ouverture de session, c’est abusé ! Mais je ne parviens pas à trouver la cause de ce phénomène, et j’ai plus envie de chercher, surtout qu’il est hors de question de risquer une fausse manip qui aggraverait la situation sur cet ordi.
 
Et puisque tu parles de Pacman… Celui-ci semble ne pas aimer les CPU double cœur : la recherche des dépendances met bien 10 secondes sur le portable, quand elle en met juste une ou deux sur le fixe (qui, lui, à un Core 2 Quad, donc un quadruple cœur, mais plus ancien !)…

Bon je vais ressayé de repassé sur wayland en virant xorg-server et sddm (qui ne supporte pas wayland en natif) ca doit bien faire 1 ans là depuis la derniere tentative
 

Bon, Wayland semble maintenant à peu près stable sur mon laptop, j'ai pas rencontré de gros crash mais il faut quand même bien bataillé au niveau des réglages et divers bugs.
Écrit comme ça ça semble simple mais ça à demandé pas mal de temps, d'essais et de recherches
 
 
Déjà le petit script de démarrage étant donné que le but était de virer SDDM qui pour le moment utilise toujours XORG :

 
Firefox
 
1. CONF : Il faut définir la variable d'environnement : MOZ_ENABLE_WAYLAND=1
2. CONF : Il est conseillé de faire quelques tweaks :  
 

3. BUG :  
La taille est la position des fenêtres ne sont pas retenues, à chaque nouvelle fenêtre, celle-ci est minuscule    :
Le problème viens de resistFingerprinting s'il est activé donc  
 
- soit on désactive l'option :

- soit on garde resistFingerprinting activé et il faut démarrer sur une page vide (chelou quand même...):

 
LibreOffice
 
BUG : LibreOffice crash lamentablement à chaque démarrages,  
Il faut définir la variable d'environnement : SAL_USE_VCLPLUGIN=kf5
 
 
VSCode / Chromium
 
Pour le support Wayland, créer les fichiers :
~/.config/electron-flags.conf
~/.config/electron13-flags.conf
 
avec comme contenu :

 
Le Dual Screen :
Ecran Laptop : 1080x1920
Ecran HDMI   : 1200x1920
 
Sur l’écran externe (HDMI), avec KDE Plasma, le curseur à un décalage vertical de ~4cm entre l'endroit ou il ce trouve ou ou le clic/survol ce réalise. (pfffff..   )
Après avoir biiiien galéré à trouver l'origine du problème, En fait Plasma ce croix fonctionner en 1200x1920 alors que l'on est en 1080x1920.
Pour résoudre ça il faut forcer la résolution au boot dans les paramètres du noyaux :
 

Après ça c'est bon, SAUF que maintenant l'écran externe se prends pour le moniteur principale d'un coup mon bureau (icônes/menu) est inversé...
Vu qu'il n'y à pas de notion moniteur primaire/secondaire avec Plasma est Wayland, j'ai refait tout mon bureau. J’espère que ça va tenir comme ça.
 
 
Maintenant ça semble enfin pas trop mal

Et il y a des aspects positifs ? ou utiles ? J'avais testé sans trop de succès mais ça fait quelques années

 
D'un point de vue purement end-user non, ça va pas plus vite est mon wallpaper est pas plus jolie.   Après bein Xorg, bien que ça marche encore c'est un abandonware, ça tourne en root et ça brille pas niveau sécurité.
Faudra bien passé un jour ou l'autre à Wayland pour le meilleur ou pour le pire, là j'ai changé de SSD c'était l’occasion.

Arch a maintenant certains fichier debog avec debuginfod (cf https://debuginfod.archlinux.org/ ).
 
Et ca discute de nouveau a propos de x64_v3, mais des que quelqu'un veut ne faire que cela c'est refusé de suite donc pas d'inquiétude de ce coté la je pense.

 
J'ai vu des news plusieurs fois là dessus ou tout le monde semble hyper entousiaste mais j'ai du mal à saisir le truc.
Ca sert à harmoniser les rapports de crash ? À les rendres plus lisibles pour les humains ? À les centraliser sur un serveur online ?
 
Vu que c'est au niveau de la distrib, ca s'adresse plutot à des bugs d'mpaquetages foireux et des soucies de dependances ?

Ca sert a pouvoir utiliser gdb et compagnie avec les paquets standards d'Arch, pour donner aux développeurs plus d'informations utiles quand il y a un soucis. Jusqu’à present pour obtenir ce genre d'information sous Arch il fallait recompiler le paquet.

Le fait de passer par debuginfod est pour éviter de continuellement télécharger les informations nécessaires alors qu'il n'y a aura qu'un rare usage ponctuel, donc tu ne prends que ce dont tu as besoin a ce moment.

C'est pas clair :
 
- est-ce qu'il y a un processus spécifique (un programme maison crée par archlinux) en arrière plan qui est lancé, afin de faire le débogage et d'envoyer automatiquement la sortie de gdb via internet ?
 
edit : des infos ici :
https://sourceware.org/elfutils/Debuginfod.html
https://www.mankier.com/8/debuginfod
 

Il me semble que c'est juste pour récupérer les informations utiles a un débogger, comme si le paquet était compilé avec -g (je ne sais pas a quel niveau), rien de plus.
Le débogger sait comment demander ces informations par le réseau si cette variable est remplie.

La dernière MAJ de Fontconfig (en fait, l’avant-dernière, puisque ça concerne la version 2.13.95 et que la 2.13.96 a été mise en ligne quelques heures plus tard) s’accompagne d’un petit changement (mais qui sautera aux yeux des gens qui ont le sens du détail, comme moi) : les polices par défaut pour les pseudo-polices « Sans », « Serif » et « Monospace » sont désormais les polices Noto au lieu des DejaVu (si elles sont installées).
 
Extrait du changelog :
 

On peut retrouver ce fichier dans « /usr/share/fontconfig/conf.avail/60-latin.conf », si on veut le modifier.
 
Par défaut, il ressemble désormais à ça :
 

Comme on peut voir sur le GitLab, ils n’ont fait qu’y ajouter les références à Noto.
 
Voilà, c’était pour vous dire que si vous constatez un changement dans l’apparence de votre DE ou gestionnaire de connexion GUI, c’est normal (après tout, je pense que beaucoup de gens utilisaient encore DejaVu comme police par défaut, au moins pour LightDM).

Merci pour l'info, je suis repassé en DejaVu où j'ai pu manuellement.
La Noto Sans Mono est infâme
 

J'imagine qu'on peut créer ce fichier en local pour le surcharger, ce qui est plus pérenne.

En supprimant les nouvelles lignes ajoutées ? Je suppose que modifier ce fichier déclenche une réinitialisation du cache de Fontconfig…

Le R minuscule est bizarre, oui, mais elle a l’avantage de bien différencier le O majuscule et le zéro, qui est barré (alors que sa quasi-copie, Droid Sans Mono, ne le fait pas : le zéro est juste plus étroit que le O).

Dans « ~/.config/fontconfig/fonts.conf », tu dois pouvoir, oui. Mais ça ne vaut que pour la session utilisateur. Il devrait suffire de recopier les lignes avec les balises « <prefer> » que l’on veut, comme ça :

Merci Trit pour les nouvelles lignes du fichier fonts.conf, ça semble résoudre le problème.

Dans mon fichier fonts.conf je vois qu'il y a parfois du binding="same" pour la balise alias :

quelle est la signification du binding="same" ?

Peut-être qu'il faudrait rajouter ce type d'option pour la balise alias concernant la police DejaVu.

Je confirme que les changements de rendu de police (sans demander l'avis à l'utilisateur) lors des mises à jour de fontconfig sont très agaçants, si la même chose était faite du coté de l'univers windows à chaque mise à jour alors ça gueulerait aussi je pense.

En voulant faire un "pacman -Syu" j'ai cette erreur :
 

 
les paquets kde-cli-tools et kdebase-runtime sont en conflit, comment résoudre ce problème ?
 
Ces 2 paquets sont installés chez moi, mais la nouvelle version de kde-cli-tools ne veut pas se mettre à jour sur mon système.

Indice : le paquet « kde-cli-tools » existe dans les dépôts, mais « kdebase-runtime » non.
La seule référence que je vois pour ce dernier est un paquet nommé « kdebase-runtime-plasma4extras » sur AUR, mais il n’a plus de mainteneur et n’a jamais été mis à jour après sa publication initiale en février 2018.
 
Je pense que tu peux dégager « kdebase-runtime », parce qu’il n’existe plus et que c’est donc lui, la cause de ton problème de mise à jour.