Reprise du message précédent :
j'imagine qu'il est obligé d'utiliser yaourt parce qu'il en a besoin pour suivre les mises à jour venant du dépôt AUR  
 
si c'est pas le cas alors en effet il y a une énigme

Même... Ça pue.
Tu fais ton -Syu avec pacman et après si les dépendances de tes paquets AUR sont cassées ou qu'ils sont obsolètes, tu les recompiles au cas par cas avec l'aide de cower ou n'importe quel helper, éventuellement même yaourt (quand on sait ce qu'on fait pourquoi pas).
 
De toute façon je doute que yaourt -Syua recompile les paquets AUR si jamais les soname requis sont cassé ni même fonctionne tout simplement si un des paquets AUR a une dépendance forte sur une version qui va être supprimée par la mise à jour...
 
Dans tous les cas tu vas devoir désinstaller puis recompiler.
 
Yaourt, c'est pour les linuxiens bricolos du dimanche    

 
Je suis pas obligé, c'est juste plus pratique.
 

 
Voilà, je sais ce que je fais    
 

 
Dans ce cas, le mainteneur sur aur peut incrémenter le pkgrel  
 

 
Alors que si tu utilises cower sous arch, tu es corporate ready.

  Goret style

 
AUR, c'est déjà un truc de goret en lui-même, on n'est plus à ça près  

la seule chose que j'utilise de AUR c'est un pilote pour imprimante canon,
 
pour les rares paquets que je ne trouve pas sur les dépôts officiels je préfère les créer moi-même avec makepkg

attention comme c'est les vacances ( bientôt le terrible blackout du 15 août ) le préposé aux news du site archlinux a oublié de poster une news concernant les gestionnaires de boot :
 
https://bbs.archlinux.org/viewtopic [...] 167153&p=1
 
vous risquez d'avoir un warning très rapide au boot de systemd après avoir fait un "pacman -Syu" :
 

 
la faute à un paramètre "ro" qu'il faut remplacer par "rw" dans le fichier de configuration de votre gestionnaire de boot ( syslinux ou grub peu importe ),
 
la solution c'est de relancer la création du fichier de configuration, par exemple avec grub il faut relancer la création du fichier grub.cfg via le script adapté ( un nouveau paquet grub faisant partie de la dernière livraison du "pacman -Syu" )
 

 
 
à noter aussi de grosses suspicions sur le paquet firefox 23, je note beaucoup d'instabilités depuis que je suis passé à la version 23 de firefox ( architecture i686 ), le navigateur se freeze parfois, impossible de tuer la tâche firefox via un "kill" ou même un "killall", la dernière fois que j'ai vu ça cela avait été corrigé rapidement par une nouvelle recompilation du paquet, visiblement un problème avec gcc qui générait un binaire instable

Mais c'est comme ça que ça s'utilise justement    
 
 

Ah oui tiens merci. J'ai ce warning depuis 2 semaines maintenant je sais pourquoi

 
sauf que tu as des gens qui au contraire utilisent AUR de manière quasi industrielle, des tas de paquets installés sur leur système provenant de ce satané dépôt AUR, ce qui fait qu'au bout d'un certain temps ils ont des soucis et des bugs ( parce que le paquet n'est plus mis à jour ou que l'auteur s'y est mal pris ) que n'auraient pas un forumeur qui se serait tenu à l'écart de AUR
 
l'interêt que je reconnais à ce dépôt c'est le coté didactique pour apprendre à construire un paquet, un petit coup d’œil sur le fichier pkgbuild pour s'en inspirer pour ses propres paquets,
 
mais dans l'idéal un utilisateur d'archlinux devrait se méfier comme de la peste de ce dépôt AUR, et chercher plutôt des alternatives sur les dépôts officiels ou idéalement construire lui-même son paquet ( et l'installer dans des répertoires de type /opt pour être sûr de ne pas créer d'effet de bord dans /usr/lib ou /usr/bin )

C'est pour ça que j'en ai des frissons quand je vois du yaourt à tout bout de champs...  
Mais AUR, bien utilisé, est très utile !
Je dois avoir grand max 10 paquets compilés sur un script AUR et ça marche très bien.

J'ai 70 packages en provenance d'AUR sur mon système  
Et probablement une vingtaine d'autres venant de dépots tiers (donc pas plus sûr que AUR), entre autres, archlinuxfr, repo-ck, catalyst-repo avec des build de Xorg spécifiques, etc...  
Donc oui, arch niveau sécurité, ça craint un peu à la base et il n'y a pas encore de vraies solutions  
 
Déjà il y a des gros prob de sécurité avec AUR, déjà les md5sums au lieu de sha512 dans les PKGBUILD, le fait de ne pas systématiquement utiliser https pour télécharger les sources, les paquets sont non signés, etc.
 
Chez Debian, les paquets binaires _et_ les sources sont sur les dépôts et signés. Quand on installe un paquet sur AUR, on doit faire confiance au mainteneur, à l'intégrité des serveurs AUR et à l'intégrité des serveurs qui hébergent les sources. C'est légèrement facile de trouer les systèmes de tous les utilisateurs d'AUR en mode automatique...

Je te l'accorde c'est forcément moins sécurisé que des packages officiels...
 
Tu compares AUR à apt-get source; je ne suis pas d'accord.
Je comparerais plus apt-get source et ABS. Mais même à ce niveau ABS est moins sécurisé, c'est vrai.
Mais le but justement c'est de n'avoir aucun contrôle pour permettre à n'importe quel utilisateur d'uploader son PKGBUILD. On ne peut pas avoir ce mécanisme et en même temps une méga couche de sécurité, ça ne marcherait pas, et on n'aurait pas cette diversité de packages disponibles.
 
Par contre les md5sum c'est du pinaillage

à mon avis il faudrait aussi que l'utilisateur fasse un audit des alternatives pour éviter de se retrouver avec trop de paquets AUR, dans le tas il y a peut-être des paquets obsolètes ou peu pertinents

 
Bah perso, j'ai packagé tout l'environnement de travail de mon taff pour pouvoir utiliser archlinux, donc j'ai un peu uploadé sur aur   D'où mes 70 PKGBUILD sur aur.
 

 
C'est pas faux
 

 
Non, md5 est carrément obsolète depuis plusieurs années, avec des articles de ce genre de 2007:
http://it.slashdot.org/story/07/12 [...] signatures
 
Je pense qu'en se donnant un peu de mal, on pourrait remplacer les sources d'un PKGBUILD sans déclencher l'erreur de verif de checksum...

 
Même si le MD5 est devenu moins fiable, caller une collision en remplaçant un fichier par un autre dans le PKGBUILD c'est ttrrrèèèsss loin d'être gagné. C'est surtout dans la vérification des fichier de très gros volume pouvant posséder des "parties creuses" (une ISO par exemple) donc malléables que le MD5 est bien plus incertain.

concernant la sécurité des paquets AUR il y aurait moyen de limiter les dégâts en s'assurant que le pkgbuild fait bien appel au site web d'origine qui héberge le code source du logiciel en question ( sourceforge.net, github ),
 
au pire si on a un doute on peut modifier le pkgbuild en mettant des liens en dur après avoir téléchargé soi-même le code source du logiciel,  
 
en fait ça revient à ne pas faire confiance à l'auteur , on se sert uniquement de son pkgbuild comme modèle de départ et ensuite on le customise, on vire certaines choses,
 
souvent c'est comme ça que je fais, je regarde ce qu'a foutu le mec sur AUR, si son pkgbuild est illisible alors je laisse tomber et je compile à la main ( le ./configure and co ) et j'installe sur un repertoire type /opt pour les tests, si c'est ok alors je crée un pkgbuild à partir d'un modèle standard que j'adapte ( en foutant dedans les commandes qui m'ont permis de compiler manuellement le logiciel )
 

C'est impossible en pratique ça  

Attention : il semble qu'il y ait un bug avec le noyau 3.10.3 (et suivants). J'ai une clé usb que je ne peux plus lire  
Et c'est sur un port usb 2...
Voir rapport : https://bugs.archlinux.org/task/36296  
 
Bref, vaut peut-être mieux attendre avant de mettre à jour.

 
Problème évoqué sur le forum francophone par Mélodie. Passer en -lts règle le problème. Il a également été conclu que ça n’affectait pas TOUTES les clefs. Ça à l’air de dépendre du firmware apparemment. De plus, un patch est dispo.

Effectivement. Je souhaitais juste prévenir les hfriens qu'il n'était peut-être pas judicieux de mettre à jour le noyau maintenant (j'imagine que le patch finira par être inclus dans le noyau (il ne l'est pas dans la 3.10.6).
 
edit : le bug est corrigé dans le 3.10.6-2.

est-ce que ces problèmes ne concernent que les propriétaires de carte mère ayant des ports USB 3.0 ?

Non. La mienne n'en a pas.

Ahhh , honte a moi j'ai fait une boulette .
 
Pacman était bloqué et au lieu de virer /var/lib/pacman/db.lck j'ai viré /var/lib/pacman...
 
Il y a un moyen pour récup cette boulette ou j'ai tout pété ? .
Pour la peine : erreur : l’initialisation de la bibliothèque alpm a échoué (trouver ou lire le répertoire a échoué)
 

peut-être un chroot via le live cd et réinstaller pacman,
 
ton incident c'est le prix à payer dès qu'on veut manipuler à la main les fichiers systèmes, l'erreur humaine est toujours possible,
 
pour limiter les dégâts on conseille d'ajouter le commutateur "-i" à rm pour avoir systématiquement une confirmation avant suppression, ce qui permet de voir tout de suite si on a fait une erreur,
 
certaines distributions configurent aussi le lien vers rm de manière à ce que le commutateur -i soit appelé

J'ai toujours /var/log/pacman.log
 
Le problème , c'est que les lib c'est un truc mais ca a du effacer aussi la database :s

regarde s'il existe un utilitaire permettant de restaurer un fichier effacé par erreur sous linux,

comme par exemple foremost et Extundelete :

https://wiki.archlinux.org/index.ph [...] y#Foremost

idéalement quelque chose en livecd, tu montes ensuite ta partition sur-laquelle tu veux récuperer des fichiers effacés par accident

autre solution : en déduire les paquets installés grâce au contenu du fichier pacman.log ( un script qui ferait ce boulot ), une fois la liste des paquets installés extraite alors tu réinstalles tous ces paquets

snif :  
extundelete /dev/sda6 --restore-directory /var/lib/pacman
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates  
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)  
y
Loading filesystem metadata ... 157 groups loaded.
Loading journal descriptors ... 28782 descriptors loaded.
Searching for recoverable inodes in directory /var/lib/pacman ...  
5583 recoverable inodes found.
Looking through the directory structure for deleted files ...  
Unable to restore inode 130685 (var/lib/pacman/local): Space has been reallocated.
5572 recoverable inodes still lost.
 
Je crois que pour la récupération c'est mort . La je me suis regravé l'iso d'arch... Mais bon si il y avait un moyen de réinstaller pacman et ensuite de le remettre à neuf avec sa database avec le log , je suis preneur...

pas de panique, tant que tu as le fichier pacman.log tu peux restaurer les bases de données, grâce à ce script :
 
https://wiki.archlinux.org/index.ph [...] l_database
 
pacrecover
 

 
ensuite tu tapes les commandes indiquées dans la page du wiki

Sauf que comme pacman est complètement out , ca bloque  :
 
[root@Mithril damien]# paclog-pkglist /var/log/pacman.log | ./pacrecover >files.list 2>pkglist.orig
[root@Mithril damien]# { cat pkglist.orig; pacman -Slq; } | sort | uniq -d > pkglist
erreur : l’initialisation de la bibliothèque alpm a échoué (trouver ou lire le répertoire a échoué)
 
Il faut d'abord le remettre sur pied (au niveau des lib) pour ensuite refaire la database

déjà sauvegarde sur un autre média ( clé usb ) ton fichier pacman.log, il est très précieux,
 
ensuite il suffit de réinstaller pacman,
 

 
https://wiki.archlinux.org/index.ph [...] tall_it.3F
 
une fois pacman réinstallé tu réinjectes ton fichier pacman.log sauvegardé, et tu relances la manip pour restaurer la base de données

Ok , j'ai repris dans l'archive le /var/lib/pacman  
 
Je tente les commandes et à chaque fois j'ai cet avertissement :
avertissement : database file for 'core' does not exist
avertissement : database file for 'extra' does not exist
avertissement : database file for 'community' does not exist
avertissement : database file for 'multilib' does not exist
avertissement : database file for 'archlinuxfr' does not exist
 
Il y a pas un truc à faire la pour récuperer les repos ou je continue la manip?
 
[root@Mithril lib]# { cat pkglist.orig; pacman -Slq; } | sort | uniq -d > pkglist
avertissement : database file for 'core' does not exist
avertissement : database file for 'extra' does not exist
avertissement : database file for 'community' does not exist
avertissement : database file for 'multilib' does not exist
avertissement : database file for 'archlinuxfr' does not exist
[root@Mithril lib]# comm -23 <(pacman -Sgq base) pkglist.orig >> pkglist
avertissement : database file for 'core' does not exist
avertissement : database file for 'extra' does not exist
avertissement : database file for 'community' does not exist
avertissement : database file for 'multilib' does not exist
avertissement : database file for 'archlinuxfr' does not exist
[root@Mithril lib]#

tu as ce topic où il y a un script pour la réinstallation de pacman :
 

 
https://bbs.archlinux.org/viewtopic.php?id=95007
 
pense bien à mettre à l'abri ton fichier d'origine pacman.log car il sera probablement écrasé par la nouvelle installation de pacman

Bah là je crois que pacman est installé , par contre je n'ai plus les repos et la database toujours kaput . et oui j'ai sauvegardé le pacman.log ( double boulette sinon )

 
tu as suivi toutes les étapes du tutoriel ? ( étapes "Generating the package recovery list" et "Performing the recovery" )  
 
regarde ce qu'il se passe maintenant si tu fais un pacman -Q, ça devrait t'afficher les paquets installés

Bon visiblement c'est bon... Mon pacman -Q fonctionne et j'ai pu faire une mise à jour

alerte pour les utilisateurs de la version i686 d'archlinux    
 
suite à un "pacman -Syu" effectué dans la nuit du 19 au 20 août KDE 4.11 a été mis à jour, glibc vers la version 2.18-2,
 
j'ai ensuite redemarré et là c'est la catastrophe :
 
--> j'arrive à me connecter avec KDM, mais KDE 4.11 est incapable de démarrer, car plasma-desktop plante avec un erreur de segmentation, du coup impossible de continuer, impossible de cliquer sur quoi que ce soit car l'erreur de segmentation réapparait à chaque fois avec un backtrace :
 

 
j'ai renommé mon profil ".kde4" pour qu'il récrée un profil vierge mais j'ai toujours la même erreur,  
 
la même erreur apparait aussi sur une autre installation d'archlinux, ça semble donc vraiment un bug, peut-être une incompatibilité avec glibc 2.18-2,
 
première fois que j'ai un bug aussi bloquant sous archlinux, on dirait que ces paquets n'ont pas été testés et qu'ils ont atterri directement dans les dépots officiels stables,
 
j'ai crée un rapport de bug et un topic dans le forum anglais d'archlinux, on va voir s'ils sont réactifs,
 
en attendant mes 2 installations d'archlinux sont HS, du moins au niveau du bureau KDE, seul le mode console ( recovery ) fonctionne mais je ne peux pas faire grand chose dans ce mode

une solution de secours pour contourner le bug :
 
éditer le fichier /usr/share/autostart/plasma-desktop.desktop
 
et remplacer la ligne :
 

 
par ceci :
 

 
le bug disparait alors et KDE 4.11 peut enfin démarrer normalement quand on a une installation i686 d'archlinux,
 
la solution provient du forum gentoo :
 
http://forums.gentoo.org/viewtopic-t-967222.html

Faux. Les betas de KDE 4.11 sans dans [kde-unstable] depuis 2 mois Et la release finale a été environ 1 semaine dans [testing].
Ils ont été testés, mais à quelle échelle ? Moi je les utilise depuis la beta1 et je n'ai jamais eu ce problème.  
Prochaine fois t'as qu'à tester aussi (Installation secondaire ou il me semble qu'il y a des ISO live des betas)
 
Le problème ici c'est que personne utilise i686, et de ce côté oui les tests sont maigres. Les TU et devs l'ont dit, ils sont tous sur x86_64 et personne ne teste le i686.
 
Merci quand même de prévenir les autres et d'avoir remonté le bug

C'est surtout aussi quand tu vois qu'il y a le problème sur Gentoo et même OpenSuSE (d'ailleurs le fix vient de la bas), on peut pas trop blâmer la Arch cette fois.

 
c'est assez dommage comme situation car les PC i686 sont encore loin d'avoir disparus, il y a encore beaucoup de portables et de PC à base de CPU i686, les pentium 4, les athlon XP, ça tourne encore très bien sous linux,  
 
et souvent c'est linux et sa légèreté qui permet de redonner une seconde jeunesse à ces vieilles machines, une sorte de remède à l'obsolescence programmée
 
est-ce qu'on connait la part en pourcentage d'utilisation de la version i686 d'archlinux dans le monde ? ( ou même avec une autre version d'OS, linux/windows confondus )
 
il va falloir recruter des testeurs i686, malheureusement je ne peux pas me permettre d'utiliser des paquets testing, mon portable devant être fonctionnel en permanence,
 
tout ce que je peux faire c'est remonter le moindre bug le plus tôt possible lorsque le paquet atterrit dans le dépôt stable

 
En fait, les derniers pc en 32 bits encore massivement produits ont été tous les trucs à base d'intel atom.
A part ça, j'ai eu du 64 bits partout depuis 2005. Et ce qui date d'avant 2005 est en train de partir à la poubelle par palettes (les amd K7, les p4, la sdram, la ddr pc 3200, les écrans cathodiques et même les lcd 15" ).
On m'a proposé de récup des p4, des amd k7, etc. Mais sachant que pour 70€, on trouve une tour avec de l'amd64 et au moins 1Go de ram sur leboncoin, quelle est l'utilité...