Reprise du message précédent :

Novembre dernier, donc ça date quand même un peu.

Ah ouais, ca ne doit pas etre le meme chose.

On a échangé nos claviers et pas de soucis avec son Logitech sans fil (different model et récepteur) donc j'imagine que ca vient bien de mon clavier.

Merci!

Il y a des périodes où le clavier sans fil du PC de mon père (un HP basique, mais avec touches multimédias, fourni avec l’ordi) a aussi ses mauvaises périodes (lettres qui ne s’affichent pas, plus rarement le coup des lettres en double, et parfois cesse complètement de répondre). En général, soit je sors et remets les piles, soit je le déplace légèrement sur le bureau (des fois que ce soit un problème de signal bloqué par un obstacle matériel, vu que le dongle est branché sur un port USB de l’arrière), et ça remarche.
 
Ce mardi, Pacman 6 est arrivé en stable. Et j’ai pu voir que le responsable du PKGBUILD de Yay avait aussi proposé une pseudo-MAJ (en fait, une recompilation du paquet), donc il a pas été cassé.

Et donc, pour Pacman 6, j’ai remarqué deux choses par rapport à mon usage habituel :

• Lancé depuis un Terminal en GUI, lorsqu’il affiche la liste des nouveaux paquets, les numéros de version sont en gris foncé (avec le thème « Noir sur blanc » par défaut). A priori, ce n’est pas le cas quand on le lance depuis une console TTY.
• Maintenant, lors des téléchargements, il y a une nouvelle ligne de progression en bas des autres qui indique la progression totale des téléchargements (et c’est pour moi le véritable changement, à l’usage).

Une amélioration serait que pacman ait une interface console à la memtest,

c'est à dire une interface toujours en mode texte mais qui a des éléments pseudo-fenêtrés (souvenez-vous des applications MS-DOS avec les menus, la gestion de la souris, le bloc-notes, l'éditeur de texte nano sous linux avec sa barre de menu, sa barre de tâche, sa zone de notifications, l'utilitaire "top", "htop" de linux avec son interface texte soignée),

des zones identifiées où les infos seraient placées de manière logique et ordonnée (au centre les paquets actuellement téléchargés/installés, en bas une zone qui affiche la barre de progression générale en cumulé, en haut une zone avec le récapitulatif statistique, l'heure, le temps écoulé, le temps restant, les infos de warning, d'erreur), des raccourcis/menus pour visualiser le journal de pacman sur une date particulière ou un logiciel particulier (recherche par filtres), quelque chose de moins frustre que le pacman actuel en terme d'affichage.

Et faire une déclinaison officielle de pacman en Qt ou gnome, soutenue officiellement par archlinux (pas un truc sur AUR qui risque de devenir orphelin ou de se casser lors d'un changement de version de l'API de pacman).

Si y a bien un truc constant sur ce topic c'est que je suis toujours en désaccord avec les "idées d'amélioration" et les "ce serait tellement bien si..." d'Elbarto
 
Une interface non-interactive comme on a aujourd'hui, très simple, qui va à l'essentiel je trouve ça parfait, j'espère que ça ne changera jamais.
Pas besoin d'usine à gaz pour mettre à jour des packages.

Pour le coup je suis d'accord avec ça

Tout de suite les grands mots

L'interface actuelle de pacman est interactive par défaut, dans la mesure où tu dois répondre aux questions posées de type oui/non, la simplicité d'usage est donc relative ici,

elle peut convenir si l'administration se réduit à lancer le bidule et à croiser les doigts pour que tout se passe bien,
de ce que j'ai vu depuis 8 ans que j'utilise archlinux c'est que cet outil ne permet pas une administration efficace de la distribution,
ainsi les messages de warning/info (interventions manuelles à faire, nouvelles dépendances facultatives, fichiers pacnew) de pacman sont noyés dans la masse quand tu as 400 paquets à mettre à jour, ça défile trop vite, et quand il y a trop de paquets alors quand tu remontes avec l'ascenseur le début peut disparaitre si le tampon d'affichage de konsole est dépassé (pas sûr du terme approprié).

Ça t'oblige à avoir des outils externes (parfois instables, dépot AUR) pour compenser la rusticité de pacman, ou bien à être fainéant en terme d'administration (les warnings, les pacnew ignorés, des mauvaises habitudes prises),

Rien n'empêcherait archlinux de fournir et de soutenir une version avancée de pacman, et de laisser en parallèle la version minimaliste de pacman pour ceux qui aiment se faire du mal,
le concept KISS a ses limites ici quand ça concerne l'efficacité de l'administration.

Même avec le paramètre « --noconfirm » ?
 

Coche la case « Défilement infini » dans les préférences de ton émulateur de terminal et tu pourras remonter jusqu’au début, même si ça a pris 5 000 lignes.
 
(Après, tu as toujours la possibilité de lire le fichier « /var/log/pacman.log », qui consigne tout ce que Pacman affiche après la fin des téléchargements)
 
EDIT : j’avais oublié, mais il paraît que Pamac (l’outil graphique de MAJ de Manjaro, porté sur Arch et utilisé par plusieurs distros dérivées) est cassé, avec Pacman 6. Et son principal développeur n’a pas le temps de s’en occuper tout de suite.

Exact, Pamac et yay ne fonctionnent plus, la maj de pacman à tout pété.

Quelle solution dans l’immédiat pour les paquets AUR ?

yay fonctionne très bien depuis la mise à jour de pacman chez moi (il s'est mis à jour également)

Chez moi il ne sait pas mis à jour en même temps, j'ai mis à jour avant hier  et j'avais vu un message d'avertissement que j'ai ignoré  

Mais je viens de trouver la solution : https://aur.archlinux.org/packages/yay/#pinned-808720

edit : plus qu'à attendre Pamac maintenant.

Je recommande plutôt « makepkg -sri », histoire de pas garder les 520 Mio de Go après la compilation (si c’est pas utile)…
 
Ça dépend comment tu as fait ta MAJ qui t’a mis Pacman 6 : ti tu avais fait un simple « yay », il te proposait la MAJ de Yay dans la foulée, et donc il ne se retrouvait pas cassé après.
Mais si tu es passé par un classique « pacman -Syu », qui ne va pas ensuite chercher les MAJ dispo sur AUR, c’était forcément une autre histoire…
 

Faudra patienter : le dev principal de Pamac n’a pas actuellement le temps de s’y coller. Donc, pour l’instant, aucune dérivée d’Arch en mode « rolling pure » (j’exclus Manjaro qui doit retarder la MAJ vers Pacman 6 tant que Pamac ne sera pas fonctionnel dessus, je suppose) ne peut utiliser le port sur AUR de Pamac.

J'avais fait ma maj avec Pamac comme d'hab. Je n'utilise pas yay et Pacman en temps normal), c'est ce qu'il y a de plus pratique je trouve, car ça demande moins de clics et de validations, et c'est plus joli

En nombre de clic, un sudo pacman -Syu dans un terminal c'est tout de même performant ( en ne tapant pas la commande à chaque fois bien sur, mais simplement un coup de flèche haut pour la faire réapparaître depuis l'historique )
 
J'aime bien Pamac mais il demande plus de clic de souris globalement.
 
edit : si je fais un inventaire précis il y a 5 étapes :
1) un clic sur le bureau, sur le lanceur du terminal
2) un coup de flèche haut pour récupérer la commande ( je ne tape quasiment que cette dernière )
3) touche entrée
4) taper le mot de passe sudo
5) touche entrée

oui mais pour les paquets aur ?
Il y a pas mal de validation à faire avec yay. Si tu en as plusieurs à la suite faut attendre chacun son tour et il y a 2-3 validation pour chaque.
Dans Pamac tu dis oui une fois au début et ça se termine tout seul.

Pour ma part je n'ai que 2 logiciels AUR :
molotov ( et ranafout des mises à jour )
cryptkeeper ( qui est archi obsolète donc idem pas traumatisé si il n'est pas à jour )
 
Bon après, si des dépendances de ces 2 programmes sont mises à jour, ça risque de foutre le boxon en effet.
 
edit : dans les faits je pense que cryptkeeper n'est plus vraiment maintenu dans AUR donc il ne bougera plus.

Tu as toujours le paramètre « --noconfirm », mais inutile de dire à quel point ça peut être risqué de tout valider par défaut…
 
Perso, à part pour des paquets légers comme inxi, je préfère faire la compilation des paquets AUR moi-même séparément après coup avec des « yay -G <nom-du-paquet> », puis « cd <nom-du-paquet> », puis « time makepkg -sr(i) ». Surtout qu’avec deux machines sous Arch, c’est quand même mieux de ne faire qu’une seule fois la compilation et l’installer ensuite sur l’autre avec « sudo pacman -U » que de faire l’opération séparément sur les deux.

Bof, ça me prend moins de temps de taper "yay" sur le clavier de mes deux machines, plutôt que de m'emmerder à compiler sur une machine pour copier ensuite sur l'autre (par USB ?), alors que j'ai la fibre.

Le seul cas où c'était intéressant pour moi, c'était la compilation de matlab..

Je n'attend rien du tout avec yay, je fais tout au debut et après ca se débrouille tout seul.

Toi, t’as pas deux PC achetés en 2009, avec un fixe qui a un Core 2 Quad, et un portable avec un Core 2 Duo. Tu aurais vite compris que, fibre ou pas (câble, dans mon cas), c’est préférable d’éviter de faire souffrir inutilement le Core 2 Duo quand tu as déjà tout fait faire par le Core 2 Quad (et ce, en moitié moins de temps à peu près que sur le C2Duo).
 
Et les copies, heu… Par réseau local via liaison SFTP, s’il te plaît.

 
Il est vrai que c'est rapide sur le Ryzen

Transition vers pipewire (et pipewire-pulse et pipewire-alsa) effectuée    
Pulseaudio server désinstallé.
C'est 100% transparent, tout marche nickel pour le moment.
Aucun problème rencontré
 

Si ça remplace sans bug, faut pas se plaindre  

Il y a des bogs et les mainteneurs ne sont pas super sympa quand je fais un rapport.

J’ai eu un truc bien bizarre, après avoir redémarré après avoir installé le noyau 5.12.9 : une fois XFCE chargé, j’ai voulu lancer Vivaldi, comme d’habitude, et… rien. Pas d’activité disque, rien qui ne s’affichait.
 
Dans le gestionnaire des tâches, je voyais bien les premiers processus ouverts (j’ai même essayé de l’ouvrir une deuxième fois : de nouveaux processus sont apparus, mais rien de plus). J’ai essayé de lancer Thunar : pareil : les processus apparaissent, mais la fenêtre ne s’affiche pas.
 
J’ai redémarré (à la sauvage : le PC était bloqué sur un écran noir avec curseur clignotant) sur le noyau LTS, et là, tout fonctionne. Pas réessayé sous le noyau 5.12.9 pour voir si c’était juste un « faux départ » (j’ai besoin du PC, en ce moment).
 
Bizarre. Vous avez eu des échos de tels problèmes, vous ? J’ai rien trouvé de concluant sur le site d’Arch (forum et bugtracker).
 
J’ai pas encore fait les MAJ sur le PC fixe (qui est donc toujours en 5.12.8).

Aucun soucis depuis passage au 5.12.9 sous XFCE (par contre je compile moi-même le noyau, j'utilise pas le package Arch).

Je suis toujours sur .11 car la dernière fois que j'ai tenté 12 ca pétait bcache.

Je viens de redémarrer sur le 5.12.9, et plus de problème. À croire que c’était un « faux départ », ou un bug totalement aléatoire qui ne se produit qu’une fois sur mille. Franchement, je préfère ça ! o/

EDIT : et RAS après avoir mis à jour et redémarré le PC fixe (qui subit toujours cette longue attente en écran noir avant de charger enfin le bureau de XFCE, mais bon, c’est une autre histoire ; au fait, vous croyez qu’avoir gardé le fichier « /etc/X11/20-nouveau.conf » peut jouer, vu que j’ai changé la CG pour une AMD en janvier et malgré avoir supprimé le paquet xf86-video-nouveau ?). Vraiment, c’était un bug purement aléatoire, dont je peux juste espérer qu’il ne se reproduira pas, ou pas de sitôt.

J'aimerais bien m'essayer au cache LVM pour mon NAS/serveur (juste pour m'amuser ) sous arch, mais je n'arrive pas à quantifier ce qu'il faut en SSD par rapport aux HDD traditionnels...  
Tu en as quel usage? Et tu as quel rapport SSD/HDD?
 

J'ai des grosses partitions btrfs qui mettent facilement une ou deux minutes a se monter, mais utiliser un vieux SSD en cache les fait monter en 1 seconde. Pour cela pas besoin de grand chose comme place sur le SSD, juste de quoi mettre en cache le système de fichiers.

Après j'utilise aussi bcache pour accélérer la lecture pour les gros jeux que je ne peux pas tous mettre sur mon NVME, ie mon SSD principal. La par contre pour que ca soit utile, il ne faut pas chambouler le cache LRU trop souvent, donc soit tu lances tout le temps le meme truc (qui doit pouvoir tenir dans le cache), soit tu as de la marge.

J'aurais bien aimé utiliser bcache comme cache en écriture tout autant qu'en lecture, mais ca c'est trop risqué donc je ne fais pas (impossible de monter la partition sans le cache, si le cache a un problème il est probable de perdre des données sur le HDD, etc.). C'est dommage, ca aurait grandement accéléré certaines operations (édition vidéo par exemple) mais bon...

Une grosse raison de l'utilisation en cache de ce SSD, c'est que c'était un échange SAV d'un SSD qui est mort et qui m'a coûté pas mal en perte de données (pas de sauvegarde a l'époque). Je n'ai jamais eu confiance a utiliser ce SSD après avoir lu que mon soucis n’était pas si rare que cela avec ce modèle, mais je l'avais tout de meme, donc un cache était un moyen de m'en servir sans mettre quoi que ce soit en danger.

Non : déplacer ce fichier ailleurs ne change rien de ce côté-là. Mais je m’y attendais…

moi je fais confiance  

Ah  
Chez moi il fait d'abord la mise à jour des paquets "normaux", ensuite une fois fini, il recherche les mises à jour des paquets aur et il faut répondre aux questions :
==> Paquets à exclure : (ex. "1 2 3", "1-3", "^4" ou nom du dépôt)
==> Afficher les diffs ?

Yay ca se configure pour un peu tout, t'as surement une config, fautive j'ai envie de dire.
 
Le souci avec ma config: un paquet AUR foire, tout le reste est zappé.

C’est la config par défaut, ce que décrit Berlo.

Ca ne veut pas dire qu'il faut la garder s'il n'aime pas ce comportement.

Je sais que c’est le TU d’Arch, mais si tu avais le temps de venir poster ça, tu avais bien celui d’indiquer comment régler le fichier de conf de Yay pour automatiser son fonctionnement, tu crois pas ?

Non je ne crois pas.
 
J'ai configuré YAY il n'y a je ne sais plus combien de temps et n'ai aucune idée de quelle config il s'agit maintenant. Tu trouveras l'option aussi rapidement que moi.

Un simple copier-coller du contenu de ton yay.conf sur Zerobin (au besoin en en supprimant les données trop identifiantes, comme le nom de ton répertoire utilisateur dans /home), c’est hors de ta portée ? Tu m’en diras tant…
 
Enfin, bon, puisque de toute façon, t’avais aucune intention d’aider…

La mise a jour de libxcrypt va revenir: