Reprise du message précédent :
1937 paquets infectés. Il y en a qui s'amusent bien.  

Ce que je comprends pas, c’est que le mainteneur incriminé est un mainteneur de longue date qui avait cependant tendance à, ponctuellement, abandonner du jour au lendemain la gestion de plein de paquets (comme Celestia, VidCutter ou encore Stellarium, qui sont de vrais bonheurs à recompiler…) et les balancer sur AUR. Je vois mal pourquoi il se serait soudainement mis à vouloir pourrir les paquets dont il s’occupait jadis… À moins qu’il ne se soit fait pirater son compte ?

Arch ne devrait-elle pas se désengager complètement de AUR ?

ben ce n'est qu'un outil à dispo de la communauté, la distro ne repose pas dessus et met bien en garde sur leur utilisation dans le wiki.

Y'a des trucs similaires sur Ubuntu (PPA), Fedora, Void et peut-être d'autres, je sais pas...
Ce qui fait la popularité des AUR c'est peut-être leur nbr, plus de 100k je crois.

Ce qui me fait flipper c'est que parmi les données ciblées ces derniers temps il y a des token Github donc ça pourrait permettre de véroler directement des sources si ils arrivent à choper le compte d'un dev.

Il y en a déjà eu des cas de piratages audacieux et extrêmement sérieux.  
https://fr.wikipedia.org/wiki/Attaq [...] rob%C3%A9e
 
Sinon, oui il y a environ 110K PKGbuild sur AUR. Il y a de quoi faire.

 
Je pensais à une séparation franche, un abandon complet de l'outil à la communauté, avec un lien qui ressemblerait un peu à celui de packman pour Opensuse ou rpmfusion pour Fedora.
 
Enfin ça me parait compliqué de rester dans la situation actuelle.

Sinon, il y a https://aur.chaotic.cx/
Jamais utilisé.

Wiki qui dirige parfois vers des paquets dispos sur AUR, notamment quand on veut personnaliser son installation.
 
Et c’est oublier qu’il y a des échanges dans les deux sens : certains paquets dispos sur AUR, une fois qu’ils obtiennent assez de votes, passent ensuite dans les dépôts officiels (ce qui évite alors d’avoir à les compiler). À l’inverse, certains paquets, devenus obsolètes ou pour d’autres raisons, sont sortis des dépôts officiels et se retrouvent sur AUR (et il faut donc désormais les compiler lorsqu’ils sont mis à jour ou nécessitent de l’être, comme lors des montées en version de Python qui nécessitent une recompilation de tout ce qui en dépend…).
Ce qui fait que si on fait durer une installation assez longtemps, même si on n’avait rien installé d’AUR, on finit immanquablement par se retrouver avec des paquets qui devront être mis à jour… depuis AUR, où ils auront été relégués dans l’intervalle.
 
Enfin, si on veut utiliser les polices de base que sont celles de MS (Arial, Courier, Times New Roman, Trebuchet, Verdana), il faut le paquet « ttf-ms-fonts »  et il n’existe que sur AUR. Même chose pour la police Ubuntu.
 

Comme d’autres dépôts tiers (qu’ils soient personnels ou propres à certaines distributions dérivées d’Arch), Chaotic-aur précompile des paquets d’AUR pour éviter d’avoir à se farcir soi-même leur compilation. Pour cette affaire de compromissions de paquets, ça aurait plutôt eu tendance à aggraver la situation qu’autre chose, puisqu’il aurait proposé des versions prêtes à installer de paquets vérolés.

Merci pour ces précisions, en effet y'a plus de "perméabilité" que je ne le pensais  

Toute cette histoire ça me fait penser : il ne pourrait pas y avoir des thèmes infectés sur https://www.opendesktop.org/ ?
Finalement qui contrôle ?

Je l'ai mis depuis 2 ans et je prends sur chaotic-aur plutôt que aur.
Pas de compilation, ça va plus vite, c'est les gens de Garuda linux derrière.

+ reflector pour les autres dépôts, ça marche bien et c'est rapide.

je n'ai plus que 10 paquets aur, dont les pilotes pour mon imprimante qui n'existe que sur aur.

Après, si les PKGbuild sont contrôlés sur chaotic-Aur. C'est un plus, non négligeable.  
En tout cas, le logiciel dont j'ai parlé au-dessus ne semble pas y être.

En mettant à jour les paquets j'ai eu une erreur sur une clé d'un développeur archlinux.org qui est considérée par pacman comme de confiance mitigée :
 

 
Si vous avez eu le même souci alors la solution est de mettre à jour d'abord le paquet archlinux-keyring :
 

 
On remarque ici que pacman donne un mauvais conseil avec le "Voulez-vous le supprimer ? [O/n]", il ne faut pas supprimer le paquet arm-none-eabi-binutils, il faut juste mettre à jour le paquet archlinux-keyring avant de faire le "pacman -Syu".
Ensuite le paquet arm-none-eabi-binutils pourra se mettre à jour.
 
C'est un des points faibles de pacman cette gestion un peu chaotique des signatures PGP, il n'y a pas ce souci avec les autres distributions comme Ubuntu où l'utilisateur tape une commande de mise à jour des paquets et n'a pas à se soucier de la fraîcheur de la base des clés, c'est fait en sous-main par le système.
 
Idéalement il faudrait que pacman mette à jour automatiquement le paquet archlinux-keyring avant d'essayer de mettre à jour les autres paquets, la doc wiki pour l'instant oblige à enchainer 2 commandes :
 

 
Et s'il y a un souci avec la base des clés alors il y a ces commandes pour tout réinitialiser :
 

 
Certains utilisateurs aimeraient un système plus simple :  
https://www.reddit.com/r/archlinux/ [...] ng_issues/

Non, j'ai cherché dans pamac, il n'y a pas sigma sur chaotic-aur.

 
Tu peux installer l'appimage ou le flatpak  
 
Quand tu vois le peu de popularité du paquet AUR, je pense que c'est préférable : https://aur.archlinux.org/packages?O=0&K=sigma

c'était juste un exemple pour pour un ami

tiens j'ai tapé man memcpy et ca me retourne rien. Y a quoi à installer pour avoir le manuel  ?

Regarde si tu as installé les paquets man-pages, man-db, linux-docs.

Cool merci ça fonctionne au poil !

KDE 6.7 dispo dans le repo stable Extra.

o/
ceux qui ont un gpu nvidia, pourriez vous svp vérifier que le fichier
/proc/driver/nvidia/suspend
existe ou non ?
ainsi que votre versoin de drivier nvidia ?
 
ici avec le dernier driver, 610.43.02-3, ce fichier n'existe pas.
donc le suspend / resume foire
et au reveil, écran noir.
 
avec le précédent, v580, yavait pas ce probleme.
bizarre..  

J'ai la 610.43.02-4 chez moi
Mais pas de fichier suspend non plus.

J'utilise pas le suspend donc je pourrai pas dire si ça a cassé récemment.

610.43.02-2 et pas de suspend mais je ne l'utilise pas.

oké merci. je vois que le suspend n'est pas tendance
c'est quand meme bien pratique pour ne quasi pas consommer quand la machine est en veille.
 
en attendant, j'ai la solution:
ecrire/rajouter dans /etc/modprobe.d/nvidia.conf

 
apres un reboot, /proc/driver/nvidia/suspend apparait et on peut l'utiliser

On peut pas seeder pendant le suspend
Mais tant mieux si t'as trouvé la solution

Ah bah tiens, c'est peut-être un truc comme ça qui me fait consommer en veille ...

haha c'est sur. tu preferes juste avoir le moniteur en veille pour laisser travailler la machine
ici sous KDE, on peut facilement et individuellement regler la mise en veille du moniteur, et de l'os, dans settings > power management

Je m'embête même plus à régler un timer pour l'écran (il s'est déjà éteint quand je voulais pas à cause de ça ). Quand j'ai fini, j'éteins l'écran à la main et puis voilà