J'écris

export EDITOR="nano"

juste après le "with" (parce-qu'il me demande d'écrire tout de suite) ou bien je dois éditer un fichier /.bashrc

Là tu écris directement
nano
et après quand t'auras le temps tu fais l'export dans ton .bashrc.
Les export FOO=bar permettent de donner des informations aux applications. Par exemple, si tu avais déjà renseigné la variable $EDITOR dans ton shell, packer (et les autres applications qui en auraient eu besoin) auraient directement su que ton éditeur favori est nano; par conséquent t'aurais pas eu la question et packer se serait servi de nano quand il t'ouvrira des PKGBUILDs à éditer.
Ça marche avec des tas de variables, c'est toujours bon de prendre 5min et de les remplir.

Ok merci !

Là il vient de m'ouvrir avec nano le fichier PKGBUILD de packer (visiblement).

Je sais pas quoi en faire ? Je ferme ?

C'est un programme de code à exécuter, avec des conditions... je vois pas pourquoi il me l'a ouvert avec nano en fait... il aurait dû le lancer plutôt ? A moins que dois modifier le code

=> continue building package ? Y
=> Building package as root is dangerous.
Please run yaourt as a non-privileged user

=> ERROR: Cannot find the strip binary requiered for object file stripping.
=> ERROR: Makepkg was unable to build packer.
Restart building packer ? [y/N]

Je fais quoi ?

J'ai le même message d'erreur en faisant :

1. yaourt -S slim-unicode

Ah je viens de trouver : il fallait installer base-devel mais avec yaourt (et non pacman) pour avoir certaines dépendances, qui, j'imagine, n'étaient pas dans les dépôts.

J'ai fait :

1. yaourt -S base-devel

1. yaourt -S packer

Là c'est bon...

Je vais essayer de mettre slim-unicode maintenant...

slim-unicode est installé

Maintenant faut configurer ça

Comment t'as pu ne pas installer base-devel?
C'est pas proposé (même par défaut?) à l'installation?

Je l'avais bien installé... mais avec pacman.

Du coup il y a certains fichiers "binutils" faisant partie de AUR qui n'ont pas été compris dedans... en installant base-devel avec yaourt il y avait ces fichiers en plus, nécessaires au fonctionnement de packer et slim-unicode...

Enfin c'est comme ça que je l'ai compris en tout cas, parce-que sinon j'en sais rien

Yaourt t'a ouvert le fichier avec l'éditeur de texte pour que tu puisses vérifier le contenu du script d'installation (PKGBUILD). En effet, ces PKGBUILD peuvent être envoyés par n'importe qui pour faciliter l'installation à de logiciels qui ne sont pas présents dans les dépôts officiels. Mais il n'y a aucun contrôle ! N'importe qui peut envoyer un PKGBUILD et il se trouve quasi-instantanément sur l'AUR. Donc faut vérifier qu'il n'y aie pas d'entourloupe au cas où...

Ok Bacon_VIII !

Là je viens de configurer slim pour le clavier en français... mais je voudrais, au démarrage :

- Me connecter automatiquement en utilisateur
- Lancer xfce4

C'est quel fichier que je dois modifier pour ça, il est où

je viens de reboot, et j'ai un gros problème :

Impossible de me connecter, j'ai vérifier au niveau des touches/clavier c'est en anglais, mais quand je rentre le login et le pass il affiche :

"failed to execute login command"

Je suis toujours sur l'écran de connexion de slim

et ça marche ni avec root, ni avec l'utilisateur non-root

Passes en tty en utilisateur normal, et donnes le résultat de
cat ~/.xinitrc

ainsi que de
cat /etc/slim.conf | grep login_cmd

@Y0shey : Hé oui ! Ça a beau être écrit partout (Wiki, page d'accueil d'AUR, ...), la première fois que j'ai envoyé un PKGBUILD sur l'AUR et qu'il est apparu instantanément, ça m'a surpris aussi.

1. cat ~/.xinitrc

exec startxfce4

(je viens de le rajouter)

1. cat /etc/slim.conf | grep login_cmd

1. login_cmd exec /bin/sh - ~/.xinitrc %ession

login_cmd exec /bin/bash -login ~/.xinitrc %ession

voilà

ça marche

Merci !

@Y0shey (et @bidegalactic vu que tu as rejoint les Archers) : Oups pas fini de répondre. Oui il faut vérifier un minimum les PKGBUILD, ainsi que les divers fichiers inclus dans les sources. Si tu utilises namcap, saches que celui-ci ne fait que repérer les erreurs courantes de "bonne pratique" de packaging mais pas les manips pour vandaliser ton système.

Enfin bon c'est facile à vérifier : tu vérifies que le script ne lance pas de commandes qui peuvent vandaliser ton système ou qu'il ne fasse pas d'actions louches (genre aller récupérer un patch potentiellement craignos sur un serveur autre que celui du paquet source par exemple). En général il faut surtout se méfier des scripts peu téléchargés donc vérifiés par moins d'utilisateurs. Je ne suis jamais tombé sur un PKGBUILD dangereux mais ça ne m'empêche pas de baisser la garde

• mais il ne faut pas baisser la garde.