Reprise du message précédent :
Garder l'exact raison de l'installation serait une bonne chose, trop souvent je vois installé pour un paquet, sans dire lequel... super! Il s'agit parfois de paquets nécessaires pour la compilation sur AUR, et donc si je les vire j'en aurais besoin encore plus tard.

Pour le passage de paquet vers AUR, j'imagine qu'il y a une ML pour et sinon pacman -Q peut aussi aider, je me suis fait un script pour que je lance de temps en temps pour nettoyer (en plus de Qmdtq).

Il serait peut-être intéressant d'intégrer dans pacman une option configurable "chercher les paquets orphelins tous les X mois pendant un pacman -Syu, et afficher un warning lorsque un paquet installé dans le passé n'est plus présent dans les dépôts stables, avec un décompte à la fin d'un pacman -Syu".

Il y a une liste des paquets absents d’AUR (et donc aussi des dépôts) et une des paquets marqués « orphelins » mais toujours au moins présents sur AUR avec Yay, donc ça devrait être faisable, en tout cas.

J'ai réglé le problème, j'ai installé Fedora Silverblue   Comme mon laptop est certifié RHEL, tout fonctionne direct avec Silverblue, sans casser le dual boot avec W11. Reste à prendre en main le coté immutable / flatpack / toolbox.
Bon, Arch me manque mais je peux toujours l'avoir avec toolbox visiblement.

Le gestionnaire de bugs d'archlinux a maintenant migré vers celui de gitlab :
https://archlinux.fr/accueil/migrat [...] b-terminee

il faudra avoir un compte gitlab :
https://gitlab.archlinux.org/

pour l'instant difficile d'en créer un :

il faudra aller sur le dépôt gitlab du paquet archlinux en question, puis aller dans la rubrique des tickets pour consulter la liste des bugs, exemple pour le paquet "kate" (éditeur de texte de kde-plasma) :
https://gitlab.archlinux.org/archli [...] e/-/issues

pour ajouter un nouveau bug il faut d'abord aller sur la page du paquet archlinux sur le site archlinux, puis cliquer sur le lien "add new bug".

Pas sûr que ce nouveau système soit adapté aux utilisateurs non techniciens et aux débutants, je préférais l'utilisation d'un logiciel "bug tracker" classique, type bugzilla.

https://fr.wikipedia.org/wiki/Bugzilla

Pour ceux qui ont des vieilles cartes graphiques comme les radeons HDxxxx : un bug dans la dernière version de mesa (1:23.3) fait que la lecture des vidéos H264 entraine une image complètement noire dans la dernière version de VLC, quand VDPAU est utilisé :

https://gitlab.freedesktop.org/mesa/mesa/-/issues/10267

Utilisant la sortie OpenGL qui n’a pas ce problème, j’aurais jamais su qu’il y avait ce bug si tu l’avais pas signalé.

J'ai pris l'habitude de laisser en "automatique" dans les réglages de VLC pour le choix de la sortie et du périphérique vidéo en plein écran, ce qui fait que VLC choisit VDPAU s'il est installé.

dans le rapport de bug il y a un moyen de contournement, il faut choisir le décodage "VAAPI via DRM" dans les options de décodage matériel de VLC :

comme paquets installés chez moi pour l'accélération vidéo dans la lecture vidéo :

et coté VAAPI :

le lecteur vidéo MPV n'a pas le souci de VLC, quand on active l'accélération VDPAU via l'option "hwdec=vdpau".

C'est assez bordélique le décodage matériel des vidéos dans linux (ainsi que le transcodage matériel), il y a plusieurs chapelles (VDPAU, VAAPI, AMF, NVDEC/NVENC, QuickSync), plus ou moins compatibles avec la marque de sa carte graphique (intel, amd, nvidia) et le type de pilote vidéo utilisé (radeon, radeonsi, amdgpu, pilote libre ou propriétaire, utilisation d'un backend) :
https://wiki.archlinux.org/title/Ha [...] celeration

vdpau c'est du vieux, maintenant on est censé utiliser vaapi pour AMD.

C'est peut-être vrai que pour les cartes AMD pas trop anciennes.

Je n'ai pas réussi à faire marcher VAAPI sur ma radeon HD4650, si je désinstalle VDPAU et que je laisse que VAAPI alors il y a un message d'erreur avec VLC.

Ça ne marche qu'avec le backend apporté par les paquets libva-vdpau-driver et libvdpau-va-gl.

La sortie de vainfo :

Ah c'est possible en effet.

Bonjour,
J'ai rencontré un bug lors d'une mise à jour 31/12 16h.
libva-mesa-driver, mesa, mesa-vdpau (1:23.3.1-1 -> 1:23.3.2-1). Pas d’accès à la session graphique, écran noir? Je suis sous Xorg.
Pas fait de recherche pour ce problème, je suis revenu rapidement à l'état antérieur à la mise à jour grâce à un snapshoot btrsf. On verra ça l'année prochaine..
Attention à la casse de votre coté.

Par précaution, j’ai récupéré les versions du 14 décembre des paquets « lib32-mesa » et « msa » (j’ai pas les autres sur mon ordi) dans les archives d’Arch.
 
C’est quoi, ta CG ?
 
Ah, ça vient d’être signalé, et ça buggue autant sur GPU Nvidia qu’Intel… Bon, j’ai rétrogradé et bloqué les MAJ des paquets dans « /etc/pacman.conf », en attendant.

Bonjour Trit'
IGPU Intel  -Driver version: Intel i965 driver for Intel(R) Haswell Desktop - 2.4.1-
J'avais rapidement fait une recherche hier, sans rien trouver. Le 31/12, les gens ont d'autres choses à faire   . J'ai aussi bloqué ces mises à jour.

Commit problématique identifié, voir lien donné par Trit' au dessus.
Viendrai du commit d'un dev M.crosoft. Sabotage!  

Pour Intel, ce serait dû à l’ancienneté du système et il faudrait passer par le paquet « mesa-amber » et non « mesa » tout court.
 
Sinon, le problème ne toucherait que les CG Nvidia, pas les AMD. Je vais donc tenter la MAJ sur mes PC qui n’ont que des CG ATI/AMD et on verra. Au pire, j’ai gardé les paquets 23.3.1-1, ils seront donc faciles à réinstaller.
 
Solution donnée sur le forum et aussi par quelqu’un sur le Fediverse : passer le paramètre « nvidia_drm.modeset=1 » dans les options de démarrage du noyau (et pas dans « /etc/modprobe.d/nvidia.conf » !) et ça devrait refonctionner.

Done! Merci Trit'
 
https://docs.mesa3d.org/amber.html  pour plus de détail sur Amber branch.
"...After Mesa 21.3, all non-Gallium DRI drivers were removed from the Mesa source-tree. These drivers are still being maintained to some degree, but only on the amber branch, and only for critical fixes.
These drivers include:   Radeon , r200 , i915, i965, Nouveau (the DRI driver for NV04-NV20)... "
 
pfff, ancien un i5-4670K d'à peine 10 ans et qui ronronne... Et dire que j'ai un i5-2500K a passer sous Linux à la fin du support W10.

J'ai eut le soucis aussi, avec un i7 6600u et Intel intégré. Un downgrade de mesa n'a pas résolu le soucis bizarrement. En plus de ça j'ai viré le driver

et ajouter

dans les HOOKS de

, puis

et c'est rentré dans l'ordre (ma config multi-écran a sauté mais c'est pas très grave).

Le retour de la blague annuelle !
 
Depuis ce mercredi :
– Linux LTS : 6.6.10
– Linux pas LTS : 6.6.10
 
Toujours très cool pour qui aurait voulu passer sur le noyau LTS pour voir si tel bug de la branche pas LTS s’y produisait aussi…
 
Sinon, y a aussi eu du changement côté D-Bus : c’est maintenant la variante « dbus-broker » qui est la nouvelle variante par défaut (l’ancienne variante « dbus-daemon » reste maintenue jusqu’à nouvel ordre, mais on est quand même encouragés à basculer sur la nouvelle).

Des infos sur les avantages supposés de dbus-broker :
 

La blague se poursuit (sinon, ce serait pas drôle ) ! Aujourd’hui :
 
– Linux LTS : 6.6.11
– Linux pas LTS : 6.6.10
 
Bah, tant que le 6.7.1 ne sort pas, Arch ne passera pas à la branche 6.7…

Finalement, on n’aura pas eu à attendre le 6.7.1 (qui se fait justement attendre…). Mais il arrive pas sans mauvaises surprises, ce premier noyau 6.7.x…
 

Un des vrais tests d’endurance va être ce soir (quand je fais la tournée des imageboards manga-anime-jeu vidéo) et surtout jeudi soir (avec le live de Marcus sur Twitch, même si lu depuis MPV en 480p)… Étant donné que j’ai pas d’OOM actif, j’ai pas envie que ça se transforme une nouvelle fois en saturation totale des ressources (c’est arrivé il y a quelques semaines, j’ai mis un moment à reprendre enfin le contrôle sans devoir arrêter sauvagement).

Tu peux taper la commande "free -mh" pour voir précisement quelle est la part du cache dans la mémoire utilisée.

Avec le noyau 6.6.10-arch1-1 et 8 Go de mémoire vive, avec plasma comme environnement de bureau et au bout de 30 minutes de surf avec firefox j'ai ça :

Je n'ai pas encore mis à jour vers le dernier noyau linux.

Dans le doute tu peux downgrader le noyau linux vers la version précédente, pour voir la différence, ça vient peut-être d'un autre paquet que tu aurais mis à jour en même temps que le noyau.

J’avais fait un « free -m » qui confirmait que juste après avoir lancé Vivaldi (mais sans charger de site, juste avec un onglet « Speed Dial »), j’étais à 3 Gio utilisés (contre 1,8 Gio avant dans les mêmes conditions). Le cache, j’ai pas trop regardé, car je venais tout juste de redémarrer (il devait donc être vide).
 

Vu ce qu’étaient les autres paquets, ça risquait pas d’être autre chose :

Mais j’ai posté sur le fil des « uname » un message qui confirme que c’est bien le noyau qui est fautif, vu que tout est normal quand je démarre sur le LTS (qui est en 6.6.11 ; donc pas besoin de downgrader, vu que ça revient au même).
 

Tu as un lien vers un rapport de bug qui parle de ce problème de consommation mémoire excessive du noyau 6.7.x ?

J’en ai pas vu. Et comme il faut leur redemander exprès de nous recréer un compte sur leur GitLab pour envoyer des rapports de bugs…
 
Sinon, attention à ceux qui utilisent le paquet d’AUR « vlc-plugin-fluidsynth-bin » pour rajouter la prise en charge du MIDI dans VLC : c’est désormais inclus d’office dans la dernière version du paquet « vlc » et ça cause un conflit de fichiers sur « /usr/lib/vlc/plugins/codec/libfluidsynth_plugin.so » lors de la mise à jour.
 
Il faut donc désinstaller « vlc-plugin-fluidsynth-bin » avant de procéder à la MAJ du système (« sudo pacman -Rs vlc-plugin-fluidsynth-bin && time yay », par exemple).

Bonjour,
Je n'ai pas trouvé de rapport de bug non plus. Cependant, un des premiers commits du noyau 7.1 me semble concerner le mappage de la mémoire. (Voir le lien de l'avant dernier post de TNZ dans le topic des uname -a https://cdn.kernel.org/pub/linux/ke [...] eLog-6.7.1).
Commenter ce commit dépasse laaaaaargement mes compétences. Un peu de patience et nous seront fixé.
 
1661 MiB (6.6.10) --> 2295 MiB (6.7.0) . Pour être plus précis, ces valeurs sont donné avec un onglet Firefox ouvert sur la page du forum, et gnome terminal. Ce qui me fait dire, en comparant avec les résultats de Trit', que Cinnamon et Xfce ont une consommation mémoire similaire.

https://gitlab.archlinux.org/archli [...] /issues/23

Tu parles du commit 54a298fa028c8d8072532f19fbb54599c3492bc8 ? Si ça corrige ce bug sur le 6.7.1, ce sera une bonne nouvelle !

J'ai tourné pendant de longues années avec des paquets de dev type mesa-git, en utilisant les repos testing, etc. mais je n'ai plus confiance en un nouveau noyau alors j'attend toujours au moins .1 avant de m'y embarquer. Je vous le conseille aussi.

Eh ben… Ce fichu bug aura été pour le moins traqué ! Ça aura pris deux jours et plein de compilations et de tests, mais il semblerait qu’on ait trouvé le commit coupable : efa7df3e3bb5da8e6abbe37727417f32a37fba47 !
 
« mm: align larger anonymous mappings on THP boundaries »
 
Une astuce donnée était aussi de démarrer avec le paramètre noyau « transparent_hugepage=never ».
 
Enfin, il se pourrait qu’on puisse bientôt refaire tourner nos machines sur le noyau pas LTS, yay !

Le bug de la RAM utilisée en excès n’est toujours pas corrigé sur le 6.7.1 sur Arch → retour en 6.6.13 LTS en attendant.
 
Je croyais que le commit fautif avait été identifié… On attend donc le 6.7.2 pour qu’il soit enfin corrigé ?
 
EDIT : sur le forum d’Arch, ils préconisent d’ajouter le paramètre noyau « transparent_hugepage=never ». Je viens de tester sur mon portable, et ça semble fonctionner (même mieux qu’avec le LTS seul) : je suis à 570 Mio de RAM occupés au démarrage avec XFCE, contre 1 Gio avec le 6.7.x sans ce paramètre, et 780 Mio sans le paramètre et le noyau LTS. À voir à l’usage si ça ne cause pas d’autres problèmes (souhaitons que non), même si j’aime pas trop devoir bidouiller les conditions de démarrage du noyau comme ça (je dois déjà forcer la clocksource sur « hpet » sur le portable qui n’aime pas la « tsc » depuis la branche 4.8…).

Le noyau 6.7.2.arch1-1 est disponible sur le dépôt Core-Testing, à voir s'il résout ce problème de consommation mémoire.

Vu ce que Seth m’a répondu (voir mon lien) et le fait que le bugreport a été fermé (puisque « résolu » par ce contournement de la désactivation des « hugepages »), ça m’étonnerait très fort. Surtout qu’il est même pas résolu en amont.

Je viens d'installer le noyau linux 6.7.x, il y a en effet une hausse de la consommation mémoire, au démarrage j'ai ça :
 
noyau 6.6.10 :

 
noyau 6.7.2 :

 
Quelqu'un conseille d'utiliser l'option de noyau linux "transparent_hugepage=madvise" plutôt que "transparent_hugepage=never" :
 

 
Il semblerait que personne n'ait fait de rapport de bug sur le bugzilla du noyau linux, pas sûr que ça soit un bug, car il serait étonnant que les développeurs linux aient laissé passer un tel bug, l'essentiel c'est qu'l n'y ait pas de fuite mémoire (il faut que le noyau rende la mémoire qu'il a mis en cache si d'autres applications réclament de la mémoire et qu'on commence à être à sec).
 
Des infos sur cette fonctionnalité "transparent hugepage" :
 
https://www.percona.com/blog/transp [...] refresher/
https://www.kernel.org/doc/html/nex [...] shuge.html

En lisant un peu, ce n'est pas exactement cela:

Les devs d'Arch ont fermé le rapport car ce n'est pas un bug d'Arch et qu'il faut voir avec les devs de Linux.

Gaël a décidé de ne pas faire un rapport en amont, se disant que ce n'est probablement pas un bog mais un effet désiré. Je ne comprend pas exactement le message du commit `fautif', mais en C il n'est pas anormal d'aligner une structure de type union sur le bus du CPU, cela occupera plus de mémoire mais le CPU sera plus efficace avec cette structure; si j'ai bien compris c'est un peu le meme truc qu'ils ont fait ici. Après c'est peut-être plus intéressant pour les serveurs que les PCs personnels... aucune idée.

Aussi, la gestion de la mémoire sous Linux est un peu particulière (il y a possibilité d'allouer plus de mémoire que disponible par example), donc la mémoire libre a un instant I n'est pas forcement le plus interessant, ce qui compte c'est comment la machine se comporte quand elle travaille.

Je pense qu'il faut commencer à s’inquiéter lorsqu'on remarque que ce commit déclenche des fuites mémoires, des "OOM",
avec le PC qui swap à fond (et si le swap est sur un disque dur alors c'est comme si la machine était gelée, plus rien ne répond niveau clavier/souris, ou alors avec une grosse latence).

Pour l'instant je n'ai pas encore eu ce cas de figure avec ce noyau 6.7.2 et mes 8 Go de mémoire vive (mais je l'ai eu il y a quelques mois avec un firefox qui avait des dizaines d'onglets ouverts).

J'ai fait un test rapide en lançant plusieurs applications : firefox avec plein d'onglets ouverts, eclipse, une machine virtuelle qemu, openoffice, gimp, lecture de vidéos youtube, à un moment la quantité de mémoire disponible est tombée à 200 Mo, puis est remonté dans la foulée à 1.5 Go.

Alors, ça, c’est pas quand ça commence à consommer du swap que ça m’arrive, mais quand RAM et swap arrivent tous deux à saturation. La dernière fois que j’y ai eu droit, il m’a bien fallu attendre une dizaine de minutes avant de pouvoir fermer les éléments fautifs et retrouver le contrôle de l’ordi.
 

J’espère que ton clavier a fourché et que tu voulais dire « LibreOffice », parce que ce serait de la nécrophilie logicielle, sinon !

OpenOffice existe toujours chez Apache avec la dernière version en Decembre 2023 donc pas bien loin.

Sinon niveau soucis OOM, earlyoom fonctionne bien pour cela ici mais je ne sais pas si ca reste nécessaire avec MGLRU.

C’est un zombie : un logiciel mort (depuis 10 ans, quand même !) qui bouge juste suffisamment (une petite MAJ de pure maintenance de temps à autres, mais très partielle) pour faire illusion, mais ça reste fondamentalement un cadavre logiciel. La dernière vraie version date de 2014, et il n’y a plus eu la moindre évolution fonctionnelle depuis.
 
Paix à ses octets, comme dit « tonton »…