Reprise du message précédent :

pacman -Scc --noconfirm
déjà effectué, si tu parles de ça.

J’imagines que c’est parce que mes locales sont en français. Mais je crois bien que j’installes à partir de core.

Je parlais juste de supprimer le paquet en question sous /var, mais ca marche aussi
y a plus qu'a attendre alors (en espérant que tout le monde ne se dise pas ça )

Solution donnée par Arcaik sur arch-fr-off@irc.freenode.net

1/ Faire confiance aux créateurs des paquets

2/ Y aller façon bourrin
Ajouter
SigLevel = Optional TrustAll
dans le /etc/pacman.conf

Pour le moment, ça passe.

Et pour ceux dont Yaourt est cassé suite au passage à Pacman 4.0, yaourt-git de AUR le gère déjà

mais pas pacman-color

Oué je bloque aussi sur package-query
 

Faut virer yaourt en attendant une version compatible (ou passer à la version git pour les plus courageux)

package-query-git

 
ou bien se contenter de pacman pour faire les mises à jour et l'installation de logiciels
 
concrètement ça apporte quels avantages d'utiliser "yahourt" pour un utilisateur lambda par rapport à pacman ?
 
je débute sous archlinux et je n'arrive pas à voir l’intérêt de cette surcouche à pacman, ça semble un peu contradictoire par rapport au concept "kiss" d'archlinux

 
La gestion d'AUR sans se prendre la tête  

je viens de mettre à jour archlinux ( installé sous virtualbox ) via la commande pacman -Syu ( je le fais toutes les semaines ),
 
ça a mis à jour xserver,
 
mais je ne peux plus démarrer kde via la commande startx, j'ai ce message d'erreur:
 

 
avant la mise à jour tout fonctionnait très bien, comment résoudre ce problème ?

 
Downgrader Xorg (il y a un dépôt xorg110 prévu pour les pilotes ati à la base), ou mettre à jour les vbox guest additions si possible.

il faut surtout recompiler le modules en question pour le nouveau serveur X.

j'ai résolu le problème en installant une nouvelle version des "VBoxGuestAdditions" qui contient un pilote vboxvideo compatible avec la dernière version de xorg-server, merci pour vos réponses

J'ai le même message en passant par Pacman :  

 
Installe package-query-git puis yaourt-git de AUR

Tu as pas supprimé yaourt et ses dépendances

Je comprends pas, je viens de faire une update et j'ai pas tous vos soucis, pas d'update de pacman et yaourt fonctionne toujours.
vous utilisez un depot particulier ou une version git?

Testing

ah oki, tout s'explique

j'utilise la configuration par défaut, pas de yaourt, aucune modif des dépots de pacman, installation depuis un cd netinstall,

mais ça n'empêche pas les soucis

des merdes aussi avec virtualbox où arch linux est installé ( pas d'automount avec le lecteur CD )

oui mais toi c'est un autre souci, je parlais des problemes avec pacman et yaourt

Si il y a des utilisateurs de Puppet ici (je pense)...
 
Ma machine sous Arch tiens le rôle du puppetmaster. J'ai Ruby 1.9.1 installé et j'ai calé Puppet en passant par l'AUR : http://aur.archlinux.org/packages.php?ID=15496
 
Pas de soucis lors de l'install, mais le démon puppetmaster refuse de se lancer :
 

 
Des idées ? Y'a quand même pas un Ruby pas compatible avec le Puppet Master de l'AUR non ?

 
Tu as essayé en passant par les gems ?  
https://rubygems.org/gems/puppet

Bonne piste, à laquelle je n'avais pas pensé, merci !
 
Malheureusement, l'erreur est absolument identique. J'ai poussé les recherches, et apparemment, Puppet n'est plus supporté pour Ruby 1.9.x. Dommage que l'AUR ne précise pas.
 
Voir https://bbs.archlinux.org/viewtopic.php?id=94838
 
Je vais tenter avec Ruby 1.8. Merci pour ta piste en tout cas.

 
   
 
Ce temps perdu sur des conneries. Donc marche pas non plus avec 1.8, ce qui me fait dire qu'il manque certainement une dépendance (plutôt que version de Ruby foireuse). Une idée ?

MOUAHAHAHAHA §§§

Alors on s'accroche, le problème viens de Facter, qui ne sait pas résoudre "hostname", ce depuis certainement sa déprécation dans net-tools. En installant inetutils, ça passe !

Bon puppetmasterd passe, mais puppet renvoi un joli

On s'accroche

Edit : pour le puppet sans argument, bug connu de la 2.7.5, résolu en 2.7.6rc1 http://projects.puppetlabs.com/issues/9458
On va dire que ça clos le sujet...

Avant de clore le sujet, il fait quoi PuppetMaster ?

oui moi aussi je ne connais pas cette application "puppet master", "facter" aussi,

dans le pire des cas si ça bloque faut switcher vers une alternative moins prise de tête au niveau des dépendances,

ou alors faut compiler depuis le code source avec les prérequis pour les dépendances, un petit coup de ./configure, make, make install et tu n'auras plus de problème de conflit de version de lib

C'est un composant de Puppet : un système de gestion de configuration.  
 
Ca te permet d'écrire des recettes pour configurer tes serveurs dans un langage déclaratif de très haut niveau. Ca abstrait la configuration technique, et si on se débrouille bien, on peut écrire de la configuration totalement portable entre distros linux.
C'est juste énormissime si tu as un gros parcs de machines à gérer.
Par exemple, là j'ai écrit un module pour faire un miroir Debian. Dans la conf de la node, j'ai juste à écrire ça :  
 

 
Et ça me fait un miroir debian pour l'arch amd64, ça installe un script kivabien, crée les répertoires, le cronjob, etc. Si je veux désinstaller totalement, je passe ensure à absent et zou ! Je peux répéter cette déclaration pour debian-security par exemple.
Je peux ensuite coupler avec un module apache, et dire de créer un virtualhost sur le répertoire du miroir que je viens de créer en utilisant une définition.
 
Si tu prends le temps, tu codes des modules qui font tout, et tu écris toute ta configuration dans le langage Puppet. Tu ne touches plus à la config, tu ne tapes plus de commandes autres que celles de puppet.  
Le soucis, c'est que ça demande du temps pour apprendre, et que fatalement, ça demande d'avoir de l'expérience sur ce que l'on manipule. Par contre, dès que tu as codé tout ce dont tu as besoin, tu peux gérer beaucoup de serveurs sans soucis (genre plusieurs centaines à plusieurs milliers, en couplant avec d'autres outils comme git avec un bon workflow, ldap et une bonne gestion d'environnement test / prod).  
Je peux en dire plus par mp, j'utilise puppet dans mon taff et je suis en train d'apprendre
 
Sinon pour en revenir à puppetmaster, j'utilise toujours les paquets Debian, c'est plus stable.  
En fait, puppetmaster, c'est le serveur qui distribue la config, facter, ça permet de remonter des facts, des variables qui dépendent de l'environnement du serveur (par exemple, is_virtual pour savoir si un serveur est physique ou virtuel) et t'en servir dans ta configuration.

OK, merci pour les explications Intéressant sur le principe, mais pas d'utilité pour moi.

En complément, j'ajouterais que ça permet de garder ton parc à jour en permanence, à la moindre modif, ça autorise des rollbacks rapides et que tu remonte une machine complète (un Node) en moins de temps qu'il n'en faut pour le dire.

Bref, pas question de trouver une alternative mais effectivement, je suis un peu surpris du manque de support par Arch (je ne m'attendais pas à le trouver dans l'AUR), d'autant que facter n'a plus l'air maintenu sur l'AUR, d'où mon erreur. Dommage.

Edit : en réponse à BlockDevice, cette installe d'un puppetmaster viens justement pour gérer des Debians je me suis récemment monté une petite machine de dev sous Arch, je trouvais ça bête de pas en profiter. je vais essayer de suivre d'un œil l'évolution du package.

j'ai un p'ti pb à résoudre, bon déjà pour commencer :
ça fait un archlinux de plus à la maison sur base de ctkarch7  
 
par contre, ça serait plus une utilisation de routeur (iptables...) :
j'aimerais savoir s'il est possible avec wicd de maintenir 2 connections? une filaire et une wifi.
 
apparemment, il ne sait switcher qu'entre l'une et l'autre. il faudrait que la connection filaire
soit ip statique et de suite up sans être controlée par wicd. j'ai bien renseigné le rc.conf,
'fin me semble t'il mais wicd reste le maître à bord. il me down la rj45 dès que je up la wifi.  
ai je oublié quelquechose?

si tu veux convertir un vieux PC en routeur/firewall le mieux c'est d'utiliser une distribution linux spécialement conçue pour cette tache, comme par exemple pfsense ( qui se base sur FreeBSD ) :

http://www.pfsense.org/

le truc est optimisé rien que pour cette tâche, pas d'interface KDE ou Gnome ou de gadget, pas de prise de tête pour trouver les paquets ou configurer des fichiers de conf, c'est intuitif/fonctionnel et il y a une interface d'administration dédiée à cette tâche similaire aux routeurs/firewall matériel vendus à des milliers d'euros,

moi archlinux à la base je le vois comme une distribution orientée "desktop" pour l'utilisateur à la maison qui veut tout le temps avoir les dernières versions de logiciel et expérimenter des choses quitte à casser le système

pour un truc orienté production/utilitaire il vaut mieux viser une distribution spécialisée ou une debian

ipcop, c'pas mal aussi

la partie routeur n'est qu'une partie de ce que je veux obtenir.
 

je me repond à moi même :
on peut demarrer network dans le rc.conf et ne pas renseigner l'interface (permanente) concernée dans wicd.
on peut ainsi se connecter en wifi pendant que l'interface rj45 reste operationnelle.
par contre il ne faut pas mettre de route par default au boot (enfin le wan etant mon wifi ceci implique cela).

Des nouvelles de ArchServer :
 
Avis de décès du projet le 16 septembre dernier : http://www.archserver.org/index.ph [...] eturnid=22
 
Annonce de la reprise du projet par un nouveau leader hier : http://www.archserver.org/index.ph [...] eturnid=22

je viens de faire le "pacman -Syu" hebdomadaire et il y a un message d'erreur :

j'ai donc renommé le fichier "locale.sh" ( qui ne contenait qu'une seule ligne: lang= fr_utf8 ) en locale.sh.back et relancé la mise à jour qui est allée jusqu'au bout ( des nouvelles versions du kernel linux, gtk, kdelibs se sont installées ), au redemarrage tout semble ok, kde se lance bien et tout reste en français,

vous pensez qu'il faut que je remette le fichier locale.sh qu'il y avait avant la mise à jour ?

le contenu du nouveau fichier locale.sh installé par les mises à jour :

le fichier rc.conf a aussi été modifié par les mises à jour et l'ancien a été renommé en rc.conf.pacnew,

sinon une dernière question:

comment connaitre exactement la version du noyau linux utilisé ?

car un "uname -a" renvoie tout le temps la version "3.0" sans plus de détails alors que normalement le noyau linux a une version de type "3.0.x.x", voilà ce que j'ai dans la console quand je tape "uname -a" :

Perso j'ai créé un fichier /etc/locale.conf contenant :  

C'est "normal" http://www.archlinux.org/news/init [...] -required/