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à

Bon ... j'ai une *ouille dans le potage :  
 
CachyOS / mode BIOS / Athlon FX8350 .... noyau bloqué en 7.0.11 avec au mieux  le 7.1-rc6.
ça vient de quoi ?  
 
Lors de mes tests sous virtualbox (mode UEFI / ryzen 7 7840u), j'avais le dernier 7.1 et le 7.2 en rc.
serait ces histoires de x86-64-v3 ou v4  ? Cf »ICI«

c'est tres possible. ton fx8350 n'est plus tout jeune (2012)
et je ne sais pas quelle archi v2/3/4 il supporte.
normalement cachy le detecte et te propose en fonction.

Bref, j'suis bon pour une compil en local

Je t'avais dit d'installer Arch et pas CachyOS

tiens, si ca peut t'aider:
https://www.yinfor.com/2023/06/how- [...] ox-ve.html
un article qui montre comment detecter quelle archi ton cpu utilise

Le FX8350 ressort en V2 ... bon ben demain compil !

T'as un kernel manager sur cachy, peut être regarder là de dedans avant  

 
C'est justement lui qui a déclenché mon message initial

C'est quoi le lien entre la version de l'archi v2/3/4 et la version du noyau ? Je ne vois pas ce qui impliquerait une dépendance de l'un vers l'autre  

incubusss : si un paquet est compilé avec certaines instructions, le processeur doit être compatible, ie avoir ces instructions en natif.
 
TNZ : sur Gentoo, si l'on utilise des binaires, il y a aussi ce souci d'abandon de la vesion v2 (du FX-8350 donc).
Mais, bon, pour les gros paquets, ça me va .
 
 
edit : il est sympa ce ghc ...

Il faut vraiment de la place et de la ram pour maintenir une Gentoo de nos jours, genre avec 16Go, je dois quelques fois descendre à 3 threads pour ne pas saturer la mémoire .
Alors, pour16 threads, le minimum est de 48Go, sans compter l'espace disque.
 
Bref, c'est plutôt une distribution d'homme (on dirait du Audiard).

 
Oui je comprends bien, mais je parlais de versions de noyau. La version 7.2 du noyau devrait pouvoir couvrir toutes les versions d'archi (modulo les archis préhistoriques supprimées, mais on ets pas dans ce cas ici), il n'y a pas raison de limiter la version du noyau pour une archi précise.

On peut en effet compiler plusieurs versions du noyau et tu prends celle qui te convient, mais :  
1/ ça prend plus de temps et d'espace
2/ il faut voir si certaines versions sont "suffisamment" utilisées pour "mériter" le 1/
 
Bref, cette limitation est le fait du mainteneur (qui vise à optimiser son temps comme tout un chacun).
 
 
edit : ces nouveaux profils (v3-v4) sont utiles aux derniers processeurs, et, c'est dommage de ne prendre que la v1 pour ceux-ci ... bref, c'est l'évolution.
Sinon, tu prends Debian, et tout est en v1 .

Faut aussi trouver des mainteneurs pour ce genre de paquets.