Reprise du message précédent :

En passant directement par Pacman, qui ne tient pas compte d’AUR lors de ses consultations des dépôt pour voir s’il y a des MAJ ?
 
Sinon, quand Yay te demande si tu veux exclure des paquets, il t’indique que tu peux entrer les numéros de ce ou ces paquets de diverses manières, ou les noms des dépôts eux-mêmes (donc « aur », dans ce cas).
 
Mais mettre à jour les paquets d’AUR est quand même nécessaire.
 
Dernière chose : si ce sont toujours les mêmes paquets, tu peux les renseigner parmi ceux à ignorer dans « /etc/pacman.conf » (une ligne à décommenter et les paquets concerner à noter à la suite ; mais là aussi, ça ne peut pas être une solution de long-terme : ça ne doit être utilisé que si une MAJ de paquet s’avère bugguée, uniquement le temps qu’une version corrigée sorte).

Oui je peux passer par pacman, mais j'ai pas envie de taper "sudo pacman -Syu" quand "yay" suffit.
 
Et oui je sais que je peux exclure des paquets mais j'ai la flemme de le faire à chaque fois.
 
Et oui je sais qu'il faut mettre à jour les paquets AUR mais j'ai plein de paquets AUR qui échouent à compiler, donc en général je mets à jour les paquets classiques en premier, puis je mets à jour les AUR un par un. D'où ma question.

Je me fais toujours un sudo pacman -Syu et ensuite un paru, j'avoue que je sais que paru peut tout faire en une fois mais comme j'ai jamais eu de problème en faisant ça...
 
Par contre pour un PC de jeux sur la TV j'envisage le retour à Windows, impossible d'avoir un Steam Big Picture Fluide, et je n'ai que des ennuis avec mes manettes Xbox Series avec le stick microsoft en 2,4ghz.  
 
Il faut toujours chiopter pour réussir à appairer la manette, tirer le stick le changer de port et redémarrer la manette pour qu'elle soit vue. ça ne marche jamais au boot directement. C'est con car j'adore être sous Gnome avec Arch tout est fluide rapide intuitif. Mais bon je me dis pour un PC qui va booter direct en big picture...  
 
Un poil déçu et pas envie de me lancer dans des bazite, garuga ou je ne sais quoi, aucune idée si c'est vraiment stable  

Pour ça, je garde des commandes que je veux pouvoir retrouver facilement au début de mon « ~/.bash_history » (que je purge chaque semaine, à l’exception de ces commandes-là ; de toute façon, il n’enregistre que les 500 dernières commandes et efface les plus anciennes quand ce seuil est atteint, donc…), dont un « time yay » (parce que j’aime savoir combien de temps prend une commande qui dure un moment à d’effectuer).
 

En vrai, je fais pareil : je fais d’abord les MAJ des paquets des dépôts, et je compile les AUR dans un deuxième temps ou quand je peux prendre le temps de le faire (je compile sur des Core 2, pas des i3/5/7…). Et encore, ça ne concerne que ceux dont j’ai vraiment besoin ou qui sont nécessaires à d’autres paquets (ceux qui se retrouvent mis sur AUR parce que c’étaient d’anciennes dépendances qui ne sont plus nécessaires, dont je n’ai pas l’usage et qui ne sont plus requis par personne dégagent).

yay met d'abord à jour les paquets des dépôts, puis ensuite ceux de AUR, donc je fais tout en une seule fois par yay.
 
Quand la compilation d'un paquet AUR plante, je relance en l'excluant jusqu'à la prochaine mise à jour.
 
Jusqu'à maintenant je n'ai jamais eu de souci de mise à jour en faisant comme ça.

Ah, moi, je ne dis pas que ça ne marche pas avec Yay (ce serait malheureux : l’outil a été conçu dans le but de s’occuper tout seul d’AUR en plus des dépôts contenant des paquets précompilés !) ; seulement que, quitte à devoir me farcir de la compilation, j’ai fini par préférer m’en occuper de manière séparée, via « yay -G » et ensuite un bon « time makepkg -sri » (ou « -sr » si c’est pas pour installer de suite, ni sur l’ordi où est faite la compilation) des familles !

Faut dire qu’avec deux ordis ou plus, autant ne compiler qu’une fois sur le plus puissant et éviter de répéter l’opération sur les autres, pour lesquels ça va plus vite de copier le paquet déjà compilé et l’installer manuellement avec « sudo pacman -U ».

Mais je sais que laisser Yay le faire fonctionne, en général (sauf rares exceptions signalées où il semble étrangement que la compilation avec lui échoue, quand une faite manuellement réussit).

Version 128.3.0-1 livrée. A la mise à jour hebdo du dredi... Nommée 128.3.0esr dans l'à-propos de Thunderbird.

J'ai installé le dernier kernel, et là c'est le drame
 
Ca boot pas...
 
dans le KVM, j'ai SYSLINUX xx : no configuration file found
 
 
Comment je répare ça ?

Essaie de démarrer sur l'image ISO de l'installateur d'arch linux, puis une fois arrivé dans la console tu regardes si tu arrives à monter tes partitions,

normalement le fichier de configuration de syslinux est /boot/syslinux/syslinux.cfg, il faudrait voir si ce fichier est toujours là,

tu peux aussi faire un chroot pour pouvoir réinstaller le paquet syslinux, ou downgrader le paquet responsable du souci,

la procédure du chroot :
https://wiki.archlinux.org/title/Chroot_(Fran%C3%A7ais)
https://wiki.archlinux.org/title/Chroot

le downgradage de paquets :
https://wiki.archlinux.org/title/Do [...] %C3%A7ais)

la fiche arch linux sur syslinux :
https://wiki.archlinux.org/title/Syslinux

On utilise plutôt grub que syslinux pour les installations de distribution linux sur disque dur/SSD :
https://wiki.archlinux.org/title/GRUB

Possible que le problème ne vienne pas d'arch linux mais de ton fichier de machine virtuelle, s'il y a eu une corruption de données (secteur défectueux sur ton disque dur, SSD, barrette mémoire défectueuse, PC instable).

merci pour ces liens.
 
il s'agit d'un serveur dedibox donc je ne peux pas booter sur ce que je veux.
 
pour l'instant je démarre en mode rescue depuis une image Ubuntu 22.04 (il n'y a pas arch dans la liste des images)
 

 
j'arrive à monter  
/dev/sda3 dans /mnt
/dev/sda2 dans /mnt/boot
 
j'ai une partition /dev/sda1 de 1Mo qui ne se monte pas.
 
Il ne semble pas y avoir de /mnt/boot/syslinux/syslinux.cfg <-- ce qui fait que j'ai ce message d'erreur au boot.
 
j'ai tenté un chroot /mnt, puis un pacman -Suy mais ca merde car /mnt/dev est pas monté comme il faut.
 
Je regarderai ca demain. J'ai juste fais un pacman -Suy avant le reboot qui a été fatal...
 
Si j'ai bien compris j'ai syslinux et non GRUB ?

Il faudra que je chroot avec ca : https://wiki.archlinux.org/title/Ch [...] vec_chroot

J'ai chroot suivant la doc mentionnée dans mon message d'au dessus
 
Et j'ai juste eu à faire un
 

 
et mon fichier /boot/syslinux/syslinux.cfg a été recréé, et ca boot !
 
Merci pour les liens

J'ai un gros problème depuis que j'ai migré vers Plasma 6.2.1, SDDM ne fonctionne plus (core dump). Même en downgradant les paquets. J'ai du lancer GDM et Gnome car Plasma refuse de se lancer depuis GDM. Je n'ai aucune idée de comment faire refonctionner SDDM...

J'ai remis à jour les paquets, SDDM est toujours cassé mais au moins je peux maintenant lancer Plasma depuis GDM...

Même problème que toi ce matin, sddm bloque et ne veut lancer aucun session disponible (ni plasma X11 ou wayland, ni Hyprland que j'ai aussi).
 
Plus simple que d'installer GDM, tu peux démarrer ta session dans un tty avec startplasma-wayland une fois loggué avec ton user.
 
Ensuite après quelques recherche, il s'avère que c'est le thème Breeze qui est tout pété si tu y met une image perso en arrière plan, j'ai switché sur un autre thème (Maldives, en y mettant aussi une image d'arrière plan perso), et la session démarre correctement.
 
Si je reviens sur le thème Breeze, ça rebloque l'ouverture de session, et même si j'essaie de virer l'image d'arrière plan perso, celle-ci reste sur le thème, faut que je trouve pourquoi, ça devrait débloquer le problème avec ce thème.

J'ai testé plusieurs thèmes que j'avais d'installé, aucun ne se lance et SDDM bascule sur son thème par défaut immonde (mais au moins, il fonctionne ).

Y'a que les thèmes intégrés qui fonctionnent (Maldives, etc.), tout ce qui est thème installé ne fonctionne pas et affiche le thème défaut pas beau, oui

Arf, chez moi, les thèmes téléchargés/installés fonctionnent

KDE Neon ... chut

Il y a un ticket ouvert pour suivre ce bug ?

Comme souvent ce sont les utilisateurs de distributions rolling-release qui se ramassent les bugs non détectés par les auteurs du logiciel fautif (SDDM ou une de ses dépendances).

Moi je mets à jour arch linux qu'une fois par semaine, et je n'ai pas encore mis à jour, j'attends que cette histoire de SDDM cassé soit résolue.

Je viens de faire la mise à jour, pas de souci avec SDDM mais je n'utilise que le thème intégré breeze.

Une petite question car je ne trouve la réponse nulle part sur le Net... Actuellement, je fais de la documentation sous Latex (plus exactement, XeLaTeX) et j'utilise les icônes FontAwesome version 5 via le package texlive-fontsextra.
 
Le problème, c'est que j'aurais besoin de certaines icônes disponibles uniquement en FontAwesome version 6, mais texlive-fontsextra est limité à la version 5. Est-ce que quelqu'un ici saurait s'il est possible d'upgrader en version 6 ?

 
https://github.com/gvgramazio/latex-fontawesome6
 
Edit: faudrait voir à créer un PKGBUILD pour ca
 
Edit2: en se basant sur celui-ci par exemple: https://aur.archlinux.org/packages/ [...] ontawesome

Merci, j'étais tombé sur cette page mais je n'ai pas réussi à faire fonctionner le bazar.

Attention il y a un bug avec les dernières mises à jour d'arch linux :
 
- si vous utilisez plasma et que vous avez une carte graphique AMD alors le démarrage peut se solder par un écran noir, avec juste le curseur de souris qui bouge, ça pourrait venir du paquet mesa :
 
https://bbs.archlinux.org/viewtopic [...] 9#p2212829
https://gitlab.freedesktop.org/mesa [...] te_2688540
 
en downgradant le paquet mesa de la version 1:24.3.1-1 à la version 1:24.2.7-1 ça résout le problème.
 
Démarrer plasma en mode X11 au lieu de wayland peut aussi résoudre le problème.
 
La version 1:24.3.1-2 en testing pourrait résoudre le problème, le commit responsable du bug ayant été retiré dans cette version :
https://archlinux.org/packages/extr [...] 6_64/mesa/

XFCE avec X11 (vu que pas encore compatible Wayland, chose qui devrait arriver dans les semaines qui viennent avec la 4.20), donc pas de souci.
 
Mais j’en ai un autre que j’imputerais volontiers à Mesa : la 23.2.7 (et la 23.3.1 aussi) fait planter VLC quand je règle le rendu vidéo en OpenGL. Pas de souci en VDPAU, mais ça n’actualise pas l’image quand je fais un saut avant/arrière en mode pause.

Le paquet mesa a été mis à jour, en version mesa 1:24.3.1-2, qui résout le problème d'écran noir au démarrage quand le mode wayland est activé, le commit défectueux a probablement été retiré par le mainteneur arch-linux du paquet mesa.

Sinon j'ai remarqué un problème avec le logiciel QtCreator (un environnement de développement pour les projets Qt) :
https://fr.wikipedia.org/wiki/Qt_Creator

Quand on veut créer un projet de type Qt Quick (qui permet d'utiliser le langage QML pour la création de l'interface graphique), et que l'on active l'extension "QML Designer" alors l'utilisation de cette extension fait planter QtCreator (et parfois QtCreator ne se lance plus au prochain démarrage, tant qu'on a pas désactivé l'extension dans le fichier de configuration /home/<user>/.config/QtProject/QtCreator.ini) :

Sur un PC récent QtCreator ne démarre plus tant qu'on a pas désactivé l'extension "QML Designer", et sur un vieux PC (avec carte graphique AMD Radeon 4650 Pcie de 2009) ça ne plante pas si on lance Plasma en mode X11 (mais en mode wayland QML Designer finit toujours par planter lorsqu'on ajoute un item graphique de type TextBox sur la fenêtre).

Mais je pense que c'est plutôt un bug du logiciel, plutôt qu'un bug d'arch linux au niveau de la création du paquet QtCreator.

Je remarque que par défaut les auteurs de QtCreator ont désactivé l'extension QML Designer, ce qui laisse à penser qu'ils n'ont pas confiance en cette extension.
Il n'existe pas d'autre éditeur graphique pour QML sauf un produit payant "QML Design Studio" :
https://www.qt.io/product/ui-design-tools

La plupart des développeurs Qt vont donc devoir éditer à la main les fichiers QML, plutôt que de passer par un éditeur graphique.

Attention
 
Depuis la mise a jour de XFCE4 hier, j'ai perdu la capacité à me logger via LightDM. J'ai contourné en installant KDE et en le sélectionnant.
Je SAIS que ce sont les paquets XFCE4, car sur ma machine Artix, j'ai eu les mêmes paquets Python mais pas les paquets XFCE4 (et  donc pas de problème sur ma machine).

Pas de souci chez moi : j’ai fait la (grosse !) MAJ cette nuit en TTY (après avoir fermé ma session XFCE), et quand j’ai rallumé l’ordi vers 9h10, l’ouverture de session s’est bien passée (j’utilise aussi LightDM, forcément). Note que j’avais bien vérifié que j’étais en session X11, pas Wayland (celui-là étant seulement expérimental et partiellement pris en charge, je ne compte pas le tester de sitôt, surtout sur des bécanes datant de 2009).
 
J’ai dû relancer le service XScreenSaver qui était inactif. J’espère qu’il n’aura pas à être relancé à chaque fois et que c’était seulement dû à la mise à niveau du DE.
 
EDIT : j’ai potentiellement une mauvaise nouvelle concernant XScreenSaver, qui est qu’en ouvrant une session en plus d’une autre (donc sur l’affichage noté comme « :1 », et après avoir fait deux essais, le service ne ne lance pas non plus de lui-même. On dirait vraiment que quelque chose a cassé de ce côté avec XFCE 4.20. Pas encore pu tester avec une session unique en « :0 », mais je pense pas que ce sera différent…
 
Ça va vite devenir pénible, s’il faut le relancer à chaque fois à la main !

Il y a vraiment un truc qui a dû casser XScreenSaver avec la mise à jour vers XFCE 4.20 : même en créant un service systemd utilisateur censé le lancer au démarrage de la session (X11, hein) comme le préconise le guide officiel, il ne veut pas se lancer ; alors que la même ligne de commande fonctionne parfaitement depuis un Alt-F2 ou en le démarrant manuellement avec la ligne de commande « systemctl --user start », et que ça se lançait sans problème quand j’étais encore sous XFCE 4.18…
 

 
Même le créateur du logiciel n’a aucune idée (ni envie, et ça se comprend) de ce qui peut coincer.
 
Je vais tenter de mettre un lanceur dans « ~/.config/autostart », mais c’est le dernier moyen que je vois pour qu’il se lance automatiquement avec la session XFCE…
 
EDIT : je remercie kajoux de m’avoir signalé que ça vient en fait d’un commit datant de mai 2023 (mais XFCE 4.18 était sorti en décembre 2022), qui retire précisément le raccourci qu’ils avaient fait (en 2012, apparemment, d’après l’historique du fichier) et devait se loger dans le répertoire « /etc/xdg/autostart/ » (solution certainement préférable à celle de devoir rajouter manuellement un lanceur pour chaque utilisateur créé sur l’OS)… Bon, ben, je l’ai restauré, en espérant qu’il ne dégagera pas à la prochaine MAJ concernant XFCE (j’ai évidemment gardé une copie pour ce cas).

Je comprend rien à arch, son système de paquet et les paquets orphelins qui reviennent toujours tout le temps.
Je me demande si 99% des utilisateurs arch ne comprennent pas non plus

pacman -Rns $(pacman -Qdtq)

 
https://wiki.archlinux.org/title/Pa [...] %C3%A7ais)              paragraphe 1.6
Quant à ceux qui reviennent tout le temps, c'est qu'ils sont utilisés une seule fois pour une compil AUR, par exemple, et ne servent plus ensuite. Puis reviennent au grès des mises à jour.

Je rappelle mon pense-bête mentionné en FP du TU Manjaro…
 

et
 

Pour ceux qui utilisent arch linux sur des très vieux PC (type intel core 2 duo, core 2 quad, des CPU de la seconde partie des années 2000) :

- avez-vous remarqué un usage un peu plus important du swap disque, après une utilisation de plusieurs heures du PC, notamment après l'ouverture de plusieurs onglets dans Firefox ? (au dela de 30 onglets)

sur mon PC (qui a 8 Go de mémoire vive) je remarque parfois que le swap disque est utilisé fortement au bout de 8 heures de surf et d'une trentaine d'onglets ouverts, puis parfois le swap disque se déclenche pendant plusieurs secondes lorsque je ferme firefox, ce qui ralentit pendant 10 secondes le lancement d'autres programmes.

Il y a quelques mois une modification du noyau linux sur la gestion de la mémoire cache avait entraîné des mécontentements chez certains utilisateurs (même ceux qui avaient un PC récent), par défaut au démarrage de la session le noyau linux réservait de manière excessive beaucoup de mémoire vive, même lorsque peu de programmes étaient lancés, le développeur responsable de cette fonctionnalité avait ensuite fait machine arrière, il est possible qu'une nouvelle modification de la gestion de la mémoire cache ait été décidé il y a quelques semaines et que c'est passé un peu inaperçu.

En tout cas je remarque une certaine latence de mon vieux PC après plusieurs heures d'utilisation, avec le disque dur qui gratte un peu plus, ce n'est pas très gênant mais ça donne l'impression d'une mauvaise optimisation quelque part.

J'ai une plateforme assez récente (5800X3D), mais oui autour de 6.11 ou 6.12 j'ai remarqué que le swap avait tendance à beaucoup plus augmenter qu'auparavant.
Et ce, malgré une vm.swappiness très basse.
 

Tu as des liens là dessus ?

Je pense que c'était ça : https://bbs.archlinux.org/viewtopic.php?id=292086

Oui c'était bien ça.

OUI.
 
Comme le dit Make install : ça a dû arriver vers le 6.11.7, de mémoire. Ajoute à ça que ça fait depuis plus longtemps encore (le 6.5 ?) que, lorsque je vide le swap, ça prend des heures quand il en reste plus de 100 Mio alors que j’ai quitté tous les logiciels ouverts, quand ça ne prenait que quelques secondes avant ; et tu comprendras que je me tâtais (tant qu’on l’a encore…) de redémarrer sur le 6.6 LTS pour vérifier, mais si c’était pour confirmer mes soupçons, bon…
 
À noter que c’est pas spécifique aux Core 2 Duo : c’est pareil avec le Core 2 Quad du PC fixe (mais il est plus rapide à finir un « swapoff -a && swapon -a », lui). Ni à Firefox, puisque ça touche aussi Vivaldi et Floorp.
 
Ça ressemble au bug précédent des « hugepages », sauf que cette fois, l’OS ne semble pas ralenti. Mais ayant l’habitude d’écouter de la musique via MPV chaque soir, je te dis que ça fait des semaines que j’ai forcément plusieurs moments où celle-ci s’interrompt et saccade pendant quelques secondes, le temps de rajouter au moins 300 Mio de swap alors que je fais que consulter des galeries d’images JPEG toutes bêtes de seulement quelques centaines de kio ! Là, depuis 22h30, j’en ai accumulé 1 Gio (mais d’habitude, ça tourne autour des 500-700 Mio à cette heure). Beaucoup vont partir quand je vais tout quitter avant d’éteindre, mais je pense qu’il en restera dans les 250 Mio que je vais devoir virer moi-même si je veux pas prolonger inutilement la procédure d’extinction de l’ordi.
 
Bref, si ça pouvait redevenir comme avant, je serais vraiment pas contre !