# [eeepc] Conseils pour utiliser gentoo

## amroth

Bonjour,

Je viens de m'acheter un eeepc, mais comme je peux plus me séparer de gentoo (quel bonheur de l'avoir essayé   :Very Happy:  )

j'aimerai avoir quelques conseils pour l'utiliser, car les temps de compilations risquent peut etre d'etre un peu longs non?

( 8gb ssd, 1GB DDR2, Intel Atom)

C'est faisable?

Merci pour vos réponses,

----------

## VikingB

Il y avait une distro spéciale appelée geeentoo, mais leur site ne répond plus : www.geeentoo.com

Tout un post intéressant sur le sujet ici :

http://www.blogeee.net/forum/viewtopic.php?f=23&t=957

En anglais , une install :

http://wiki.eeeuser.com/howto:installgentoo

----------

## YetiBarBar

Regarde du côté de distcc également. A condition d'avoir un autre PC sous linux (enfin, le mieux étant d'être sous gentoo!)...

----------

## ppg

C'est faisable, mais faut pas espérer compiler dessus.

Si t'as un pc sous Gentoo tu peux faire un serveur de binaires et récupérer les binaires de ton pc sur le eeepc.

Enfin c'est que j'aurais fait, si j'avais un processeur 32 bits sur mon desktop, mais j'ai la flemme de faire de la cross compile (je suis en 64 bits).

Bref bon courage, je suis très intéressé par un retour d'expérience si tu y arrive, mon eeepc étant sous debian pour la raison que je viens de citer…

----------

## kwenspc

distcc n'est clairement pas la solution, là encore emerge etc fait travailler le disque pas mal. amha le mieux c'est tout construit dans un chroot sur le desktop principal, stage4 hop sur la cible. Ensuite soit maj via des paquets binaires construit via le chroot soit rsync.

[edit] le cpu 64bits n'est pas un soucis (à moins que l'archi soit pas X86...), linux32 chroot est ton ami  :Wink:  [/edit]

----------

## bi3l

J'avais fait un tutoriel sur le wiki gentoo fr mais la base de données a été perdue. Il me reste mon doc de travail qui n'est sûrement plus très à jour mais qui reste une bonne base: http://docs.google.com/Doc?id=ddnvvh8x_236fvcd7hgt

----------

## Gaby

 *kwenspc wrote:*   

> distcc n'est clairement pas la solution, là encore emerge etc fait travailler le disque pas mal. amha le mieux c'est tout construit dans un chroot sur le desktop principal, stage4 hop sur la cible. Ensuite soit maj via des paquets binaires construit via le chroot soit rsync.
> 
> [edit] le cpu 64bits n'est pas un soucis (à moins que l'archi soit pas X86...), linux32 chroot est ton ami  [/edit]

 

Je met actuellement gentoo sur un vieux portable avec un Duron 1Ghz et 128Mo de ram via cette méthode et je suis bluffé (Merci Kwenspc pour tes scripts). De plus cette solution te permet d'éviter de surcharger ton disque avec portage et autre.

Et pas de soucis avec le 64bits je confirme.

Gaby

----------

## amroth

Merci beaucoup pour toutes vos réponses!

Je vais essayer avec le principe du stage 4 (pas tout de suite je dois récupérer ma clé usb d'abord...)

Je vous tiendrai au courant,

----------

## kwenspc

 *Gaby wrote:*   

> 
> 
> Je met actuellement gentoo sur un vieux portable avec un Duron 1Ghz et 128Mo de ram via cette méthode et je suis bluffé (Merci Kwenspc pour tes scripts). De plus cette solution te permet d'éviter de surcharger ton disque avec portage et autre.
> 
> 

 

Content que ça serve à d'autres qu'à moi!   :Surprised: 

Tu utilise seulement chenvr ou bien syndgen avec (ou sans en fait)? (faut d'ailleurs que je release la version 0.2   :Embarassed:   elle possède une fonction de création de liste d'exclusion automatique, suffit de lui filer les paquets qu'on veut exclure et hop. Très utile à mon avis si on souhaite faire un environnement pour cible à faible espace disque. Y a une fonction stage4 aussi. Faut, par contre, que je révise la synchronisation, c'est pas encore aussi simple que ce que je voudrais.)

----------

## xaviermiller

Et sur funtoo, il y a "metro", le "catalyst" de l'ancien fondateur de Gentoo  :Wink: 

----------

## Gaby

 *kwenspc wrote:*   

> 
> 
> Tu utilise seulement chenvr ou bien syndgen avec (ou sans en fait)? (faut d'ailleurs que je release la version 0.2    elle possède une fonction de création de liste d'exclusion automatique, suffit de lui filer les paquets qu'on veut exclure et hop. Très utile à mon avis si on souhaite faire un environnement pour cible à faible espace disque. Y a une fonction stage4 aussi. Faut, par contre, que je révise la synchronisation, c'est pas encore aussi simple que ce que je voudrais.)

 

J'utilise les 2 (en fait je ne sais même pas comment faire un chroot 32bit dans un environnement 64 alors chenvr me dépanne bien).

J'ai vu que tu avais fait une v0.2 et elle m'interesse pour les exclusions justement, pour l'instant j'ai bidouillé à la main pour exclure les paquets de base mais j'ai du être un peu bourrin car les pages man ne fonctionnent plus ....

Pour ce qui est de la synchronisation, j'ai constaté que celle-ci était uniquement un miroir du chroot et non une synchro bidirectionnelle (fonction backup en sus), c'est voulu de ta part ou rsync ne le permet pas (jamais utilisé précédemment).

N'hésite pas si tu veux des tests.

----------

## kwenspc

 *Gaby wrote:*   

> 
> 
> J'utilise les 2 (en fait je ne sais même pas comment faire un chroot 32bit dans un environnement 64 alors chenvr me dépanne bien).
> 
> J'ai vu que tu avais fait une v0.2 et elle m'interesse pour les exclusions justement, pour l'instant j'ai bidouillé à la main pour exclure les paquets de base mais j'ai du être un peu bourrin car les pages man ne fonctionnent plus ....
> ...

 

Ok donc faut que je me pousse à la sortir cette version!

Sinon oui c'est un miroir du chroot. J'ai en effet pas pensé à faire du bidirectionnel, amha c'est rien du tout à faire (rsync le permet oui), je vais me pencher dessus  :Wink: 

(dslé de pourrir le post sinon)

----------

## xaviermiller

non, tu ne pourris pas le post, kwenspc, ton outil est très utile  :Smile: 

----------

## Da_Risk

Je plussoie. je l'ai decouvert pour la meme raison et c'est vraiment une petite perle   :Very Happy:   Merci

----------

## kwenspc

Ce soir je release la version 0.2 

Je viens de tester ça fonctionne bien. Me reste à mettre à jour la doc.

Et en fait Gaby, pour la synchro bidirectionnelle, suffit de rien exclure et d'utiliser syndgen en alternant du serveur au client (en fait les 2 entités sont des copies conformes en tous points). Ensuite c'est juste une question de qui lance syndgen et qui lance le deploy. (server -> client, puis une fois que t'auras fait des trucs sur le client, on intervertit les rôles client -> serveur et hop.)

----------

## kwenspc

bon bah si vous êtes interessé c'est par ici --> http://tuna.lyua.org/syndgen (en ésperant que ça puisse être utile pour eeepc aussi)

----------

## Gaby

 :Very Happy:   Je teste ça ce weekend, merci pour la release.

Tu as au moins un changelog en attendant la doc ? histoire de ne pas se faire surprendre.

Pour la synchro bidirectionnelle, c'est une solution mais pas adapté pour mon cas. J'aimerai pouvoir changer des fichiers de conf depuis n'importe quel source. Si j'applique ta méthode, le 1er syndgen à entrer en action écrase le fichier modifié. Il faut que je regarde du coté de rsync si je trouve une solution, idéalement il faudrait un merge des fichiers modifiés mais la je demande beaucoup ...

Gaby

----------

## kwenspc

 *Gaby wrote:*   

>   Je teste ça ce weekend, merci pour la release.
> 
> Tu as au moins un changelog en attendant la doc ? histoire de ne pas se faire surprendre.
> 
> 

 

Arlg pas de changelog. J'aurais ptet dû... Globalement: ça ne fait qu'ajouter des features: l'option --exclude et le fichier d'exclusion pour deploy.sh

À ce sujet, LA grosse surprise c'est le --delete utilisé avec rsync dans deploy.sh, ça manquait. (par exemple une vielle lib .so que la source aurait écrasée après mise à jour du package apparenté, et bien sur la cible elle serait resté, c'est une erreur). Cependant on peut éviter que le sync écrases certains fichiers sur la cible et je vous conseilles à tous de bien réfléchir à ça avant de lancer deploy.sh  :Wink:  : il vous suffit de créer une liste d'exclusion sur la cible dans /root/syndgen.exclude Par exemple sur mon serveur le rep /home il "vit" de lui même et je veux pas l'écraser à chaque maj, du coup je l'exlut du rsync (ça évite que tous les fichiers qui ont été créés dedans, et qui n'existent pas sur la source qui ne me serte que d'envirronement de compilation/mise à jour de sécu, ne soient irrémédiablement écrasés)

Au pire si tu as, si vous avez des doutes, éditez deploy.sh et aux deux lignes rsync ajoutez -vn au première option: ça vous affichera tout ce que la synchro va faire, sans réelement le faire, pour vérifier donc.

J'espère que l'option --exclude vous sera utile  :Smile: 

 *Gaby wrote:*   

> 
> 
> Pour la synchro bidirectionnelle, c'est une solution mais pas adapté pour mon cas. J'aimerai pouvoir changer des fichiers de conf depuis n'importe quel source. Si j'applique ta méthode, le 1er syndgen à entrer en action écrase le fichier modifié. Il faut que je regarde du coté de rsync si je trouve une solution, idéalement il faudrait un merge des fichiers modifiés mais la je demande beaucoup ...
> 
> 

 

Ah oui là un peu chaud si il y a 2 versions concurrentes d'un même fichier. L'idéal serait en effet une gestion de confilt un peu comme sur les système de contrôle de version (cvs, svn, bzr, git...) mais ça serait coton à faire. (à moins bien sûr d'utiliser un tel soft en lieu et place de rsync... mais amha ça serait assez lourd à utiliser)

----------

## Gaby

 *Quote:*   

> À ce sujet, LA grosse surprise c'est le --delete utilisé avec rsync dans deploy.sh, ça manquait. (par exemple une vielle lib .so que la source aurait écrasée après mise à jour du package apparenté, et bien sur la cible elle serait resté, c'est une erreur). Cependant on peut éviter que le sync écrases certains fichiers sur la cible et je vous conseilles à tous de bien réfléchir à ça avant de lancer deploy.sh  : il vous suffit de créer une liste d'exclusion sur la cible dans /root/syndgen.exclude Par exemple sur mon serveur le rep /home il "vit" de lui même et je veux pas l'écraser à chaque maj, du coup je l'exlut du rsync (ça évite que tous les fichiers qui ont été créés dedans, et qui n'existent pas sur la source qui ne me serte que d'envirronement de compilation/mise à jour de sécu, ne soient irrémédiablement écrasés) 

 

Si j'ai bien compris l'option, --delete supprimera les fichiers qui ne sont plus sur le "serveur" (par opposition au client, celui qui ne compile pas) donc supprimera un fichier de conf créer sur le client et qui n'existerai pas sur le serveur sauf si celui-ci est inscrit au fichier /root/syndgen.exclude du client. Donc ton script consulte le syndgen.exclude client ET serveur avant le rsync ?

Ou dans ton exemple tu exclu ton home sur le serveur ce qui l'exclue sur le client.

Je veux être sur de ne pas comprendre de travers ...

Gaby

----------

## kwenspc

 *Gaby wrote:*   

> 
> 
> Si j'ai bien compris l'option, --delete supprimera les fichiers qui ne sont plus sur le "serveur" (par opposition au client, celui qui ne compile pas) donc supprimera un fichier de conf créer sur le client et qui n'existerai pas sur le serveur sauf si celui-ci est inscrit au fichier /root/syndgen.exclude du client. Donc ton script consulte le syndgen.exclude client ET serveur avant le rsync ?
> 
> Ou dans ton exemple tu exclu ton home sur le serveur ce qui l'exclue sur le client.
> ...

 

C'est bien la première option. /home est exclu dans syndgen.exclude sur le client (c'est pas le serveur qui l'exclue). Ce qui a pour effet d'annuler tout travail de rsync sur /home sur le client (ajout/suppression de fichiers)

Pour être plus détaillé: en fait le scrpti fait rien si ce n'est fournir le fichier exclude à rsync. Ce dernier, lors de la synchro prend ce que le serveur lui propose (qui lui même a peut-être des fichiers exclu, via rsynd.exclude généré par --exclude, de fait ces fichiers de sont pas proposés à la synchro, le client les voit pas du tout) tout en faisant bien attention d'annuler les synchros qui sont affectés par la liste d'exclusion. Par exemple si le serveur tente de synchroniser /home/truc/bidule, le client va voire que ça match avec l'exclusion /home, et va donc passé sur cette synchro.

C'est vrai que c'est un peu le boxon toutes ces listes d'exclusions/inclusions sur le serveur et sur le client... J'ai pas trouvé moyen de faire plus simple, je me plie à rsync donc sur ce coup là je crois pas pouvoir proposer mieux. C_est vrai que ça demande une certaine rigueur au moment de la config de tout ça. Une exclusion oubilé quelque part et ça peut être embêtant...

----------

## Gaby

 *kwenspc wrote:*   

> C'est vrai que c'est un peu le boxon toutes ces listes d'exclusions/inclusions sur le serveur et sur le client... J'ai pas trouvé moyen de faire plus simple, je me plie à rsync donc sur ce coup là je crois pas pouvoir proposer mieux. C_est vrai que ça demande une certaine rigueur au moment de la config de tout ça. Une exclusion oubilé quelque part et ça peut être embêtant...

 

Ok c'est plus clair.

Concernant les exclusions/inclusions je crois justement que j'ai été un peu brutal et j'ai quelque problème qui pourraient en découler. Je ne suis pas sûr des dossiers/fichiers à exclure pour une utilisation Desktop sans compile. 

Selon moi :

/

```
sys/*

/dev/*

/proc/*

/tmp/*

/var/db/*

/var/lib/portage/*

/var/tmp/*

/var/run/*

/var/cache/edb/*

/usr/include/*

/usr/lib/gcc/*

/usr/portage/*

/usr/locale

/etc/portage/*

/usr/src/*

/etc/make.conf

/etc/syndgen/*

/home/*
```

Gaby

----------

## kwenspc

Hum non ça a l'air bien.

Par contre pour gcc (automake, autoconf etc... tous ces outils utilisés que pour la compile), le mieux maintenant (avec la 0.2) c'est de passer par le fichier /etc/syndgen/package_exclude.list et d'y mettre:

```

sys-devel/gcc

sys-devel/make

sys-devel/automake

```

Ensuite tu génères le *vrai* fichier d'exclusion pour rsync: syndgen --exclude

/etc/syndgen/rsyncd.exclude est le résultat de la cocaténation de /etc/syndgen/common.exclude (celui que tu remplis à la main) et la liste générée via /etc/syndgen/package_exclude.list

Tu peux regarder dans /etc/syndgen/rsyncd.exclude pour te faire une idée.

Par contre, l'option --exclude en prenant les package dans package_exclude.list ne va pas faire de vérification de runtime dependencies. Donc faut que tu saches un minimum ce que tu enlèves, enfin faut savoir ce qu'on fait comme toujours avec Gentoo  :Wink: 

Ce qui pourrait être ajouté à syndgen serait une "synchro" par installation de paquet binaire. C'est ce que fait bi3l avec son tuto pour eepc mais à la main, ça serait amha le plus élégant pour la mise à jour d'un parc entier de pc. Ça doit être moins lourd en occupation réseau je pense.

----------

## Gaby

Comment expliquerais tu le problème suivant :

Sur le serveur, un man XXX me donne bien la page man en question mais sur le client cette commande ne fonctionne plus et me donne une erreur à base de error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

Mes connaissances en Gentoo et Linux en général sont encore trop limité mais j'ai cru comprendre que c'était un problème de pointage de librairie mais je ne vois pas pourquoi syndgen crée le problème ou ne le corrige pas si la source est bonne.

Pour le fichier package_exclude.list, comment en déduis tu la liste des fichiers à exclure, tu passe par equery ?

Gaby

----------

## kwenspc

 *Gaby wrote:*   

> 
> 
> Sur le serveur, un man XXX me donne bien la page man en question mais sur le client cette commande ne fonctionne plus et me donne une erreur à base de error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
> 
> 

 

Ça c'est dû à l'exclusion de gcc. C'est lui qui fournit cette lib. Dans ce cas précis faut mettre à la main les fichiers à inclure (par exemple l'exclusion de gcc va faire que /usr/lib/gcc va être exclut, or dans ce rep il y a libstd++.so.6. Il faut donc dire à rsync qu'il doit tout de même inclure ce fichier, hum genre ça ça doit marcher: 

```

*libstdc++.so*

```

Dans /etc/syndgen/deploy/common.include

Comme je te disais, la fonction vérifie pas les runtime dependancies, encore moins les dépendances au runtime sur un fichier en particulier d'un paquet (qui n'est noté nulle part dans un fichier). En fait, je vois pas du tout comment ça pourrait vérifier ça (enfin si j'ai une idée mais ça serait du lourd...) Ça reste à l'attention de l'utilisateur d'y faire attention. Je sais c'est pas ultra top m'enfin  :Neutral: 

 *Gaby wrote:*   

> 
> 
> Pour le fichier package_exclude.list, comment en déduis tu la liste des fichiers à exclure, tu passe par equery ?
> 
> 

 

Non je passe par une fonction perso, qui va regarder dans /var/db/pkg/<category>/<pkg>/CONTENTS et qui fait la concordance entre le système de fichier et le contenu de ce fichier pour savoir quels fichiers/répertoires enlever. 

Ça évite par exemple d'exclure un rep qui aurait d'autres fichiers d'autres paquets, ou bien encore d'exclure 1 par 1 un tas de fichier dans un rep alors que ce rep tout seul suffirait à exclure tous les fichiers d'un coup.

Il y a un manque par contre: les fichiers créé au runtime du paquet et qui de figurent pas dans CONTENTS, ça vaut pour les fichier python par exemple. Ça serait pas trop compliqué à fixer amha.

----------

## Gaby

Ah bin du coup tu viens de me résoudre mes problèmes avec slim au passage, c'était bien les excludes de GCC qui posaient problèmes.

Pour les exludes, je m'étais fait la même analyse vis à vis d'equery et je ne connaissais pas le coup de CONTENTS. Bon à savoir.

Gaby

----------

## Gaby

J'ai mis à jour Syndgen mais j'ai cette erreur :

```
sh-3.2# syndgen --exclude

Traceback (most recent call last):

  File "/usr/bin/syndgen", line 13, in <module>

    from syndgen.tasks.stage4 import Stage4

  File "/usr/lib/python2.5/site-packages/syndgen/tasks/stage4.py", line 15

    help="Create a stage4: a archive of the whole system."),
```

Gaby

----------

## kwenspc

opts = { ... } ça devrait pas etre des {} mais des [] dans le fichier stage4.py

Comment ce fait-ce que je n'ai pa vu ça? je n'ai pas eu l'erreur lors des test.   :Embarassed: 

----------

## porodzila

 *VikingB wrote:*   

> Il y avait une distro spéciale appelée geeentoo, mais leur site ne répond plus : www.geeentoo.com
> 
> Tout un post intéressant sur le sujet ici :
> 
> http://www.blogeee.net/forum/viewtopic.php?f=23&t=957
> ...

 

Merci.  Je chercherait info de gentoo pour eeepc depuis trois semaines en anglais.  Je ne parle pas francais bien mais le premier temp j'ai decide lire ici je trouve la chose que je veux.  Je suis desole pour ces phrases,  je ne parle pas francais depuis 3 ans.

----------

## Rvay

Bonjour tout le monde,

je profite de ce premier post pour me présenter en deux mots: je m'appelle Hervé, j'ai 23 ans et j'ai un an d'expérience Linux sur Ubuntu et plus récemment sur ArchLinux.  J'ai fait l'acquisition il y a quelque mois d'un eee pc 900. 

Voici ma question: j'ai longtemps regarder gentoo comme "the" distribution et parvenir à l'installer et à la configurer serait pour moi un véritable accomplissement. Seulement voilà, j'ai quelques appréhensions: 1° le temps d'installation sur l'eee pc (mais apparement il faut compiler sur une autre machine), 2° l'utilisation de vi (est-ce si compliqué que ce qu'on en dit ?) , 3° la réactivité de la communauté (j'ai vécu deux choses totalement différentes entre Ubuntu et arch   :Rolling Eyes:  ) et 4° j'ai surtout peur de faire une connerie et de manquer de connaissances. 

Est-ce que selon vous ces appréhensions sont fondées, vraisemblables, possibles, ...  ? Est-il possible pour un non informaticien d'installer gentoo sur un eee pc ? Et si je me lance pourrais-je compter sur la communauté (en cas d'incompréhension je précise, pas en cas de choses évidentes se trouvant dans la doc) ?

----------

## pititjo

 *Rvay wrote:*   

> Bonjour tout le monde,
> 
> je profite de ce premier post pour me présenter en deux mots: je m'appelle Hervé, j'ai 23 ans et j'ai un an d'expérience Linux sur Ubuntu et plus récemment sur ArchLinux.  J'ai fait l'acquisition il y a quelque mois d'un eee pc 900. 
> 
> Voici ma question: j'ai longtemps regarder gentoo comme "the" distribution et parvenir à l'installer et à la configurer serait pour moi un véritable accomplissement. Seulement voilà, j'ai quelques appréhensions: 1° le temps d'installation sur l'eee pc (mais apparement il faut compiler sur une autre machine), 2° l'utilisation de vi (est-ce si compliqué que ce qu'on en dit ?) , 3° la réactivité de la communauté (j'ai vécu deux choses totalement différentes entre Ubuntu et arch   ) et 4° j'ai surtout peur de faire une connerie et de manquer de connaissances. 
> ...

 

2° Il n'est jamais nécessaire d'utiliser vi. Dans tous les cas tu peux utiliser n'importe quel éditeur de texte et, en console, nano est tout ce qu'il y a de plus simple à utiliser.

3° La communauté est active sur ce forum, il suffit de regarder  :Smile: 

4° Si tu suis correctement la documentation tu aura les bases nécessaires. Si tu es passé par d'autres distribution comme ça semble être le cas, tu sais déjà des choses. Pour le reste, tu trouvera toujours une documentation, un sujet sur le forum ou, au pire, tu peux poser la question.

Il est tout à fait possible à un non informatitien d'installer gentoo. Après, je ne connais pas les contraintes liées à l'eeepc, mon 701 est toujours sous xandros.

----------

## porodzila

Est-ce que Xandros marche bien pour le 701?  Mon 901 sous Xandros est tres instable.

----------

## xaviermiller

On est dans un forum Gentoo   :Shocked: 

----------

## porodzila

 *XavierMiller wrote:*   

> On est dans un forum Gentoo  

 

OkOk,  Je n'ai jamais ecrive ici.  Les autres forums ne'ont pas info des eepcs.

----------

## kwenspc

 *porodzila wrote:*   

> Est-ce que Xandros marche bien pour le 701?  Mon 901 sous Xandros est tres instable.

 

Toutes mes connaissances autour de moi qui ont acheté un eeepc toute versions confondues, ont été TRÈS content de se débarasser de Xandros (pour Debian/Ubuntu en majorité sinon d'autres distros)

----------

## Rvay

Ok, je vais lire la doc et je reviendrais vers vous avec une petite feuille de route, histoire de savoir si ce que je compte faire est correct. 

Tiens, en passant, est-ce que ça aurait une utilité de faire un backup complet de ma machine qui tourne actuellement sur ubuntu-eee (pour récupérer certains fichiers de configuration par exemple) ?

----------

## pititjo

 *Rvay wrote:*   

> Ok, je vais lire la doc et je reviendrais vers vous avec une petite feuille de route, histoire de savoir si ce que je compte faire est correct. 
> 
> Tiens, en passant, est-ce que ça aurait une utilité de faire un backup complet de ma machine qui tourne actuellement sur ubuntu-eee (pour récupérer certains fichiers de configuration par exemple) ?

 

Au pire ça peut pas faire de mal.

----------

## porodzila

 *kwenspc wrote:*   

> 
> 
> Toutes mes connaissances autour de moi qui ont acheté un eeepc toute versions confondues, ont été TRÈS content de se débarasser de Xandros (pour Debian/Ubuntu en majorité sinon d'autres distros)

 

Merci! Je vais essayer Gentoo.  Les eeePCs ne sont pas bien savus a USA.  J'estudera plus de francais.  :Very Happy: 

----------

## kwenspc

 *porodzila wrote:*   

> 
> 
> Merci! Je vais essayer Gentoo.  Les eeePCs ne sont pas bien savus a USA.  J'estudera plus de francais. 

 

Ok in that case just try to follow bi3l's tutorial http://docs.google.com/Doc?id=ddnvvh8x_236fvcd7hgt

It will let you know how to avoid compiling all the stuff on eeepc, via your desktop. (softs I made called chanvr and syndgen might help you also if you need it but it is not mandatory ^^ I am just advertising)

----------

## bi3l

An updated version of the tutorial is available on the french wiki: http://fr.gentoo-wiki.com/wiki/Asus-Eee_PC_4G

----------

## xaviermiller

OK, thank you fellows ! What about to speak dutch ?  :Wink:   :Laughing: 

----------

## Rvay

Je suis d'accord avec le fait que la compilation doit se faire sur une autre machine mais est-ce que cette phrase est toujours vrai sur l'eee pc 900 qui a 12 G et non 4 G d'espace de stockage:

 *Quote:*   

> L'arbre portage est trop gros, il doit être déporté ou compressé.

 

?

----------

## pititjo

Si la compilation se fait sur une autre machine, je ne vois pas tellement l'intérêt de garder l'arbre portage sur le eeepc. Autant le déporter même si le disque avait été encore plus gros.

----------

## Rvay

Je précise ma question.

Personnellement je n'aurais accès à une machine plus puissante que le temps de la première compilation. Cela veut dire que je devrais faire les mises à jour sur l'eee pc   :Shocked: 

Si j'ai bien compris l'arbre de portage est nécessaire pour les mises à jour, non ?

----------

## kwenspc

 *Rvay wrote:*   

> 
> 
> Si j'ai bien compris l'arbre de portage est nécessaire pour les mises à jour, non ?

 

Oui bien entendu, portage et son arbre son indissociables pour pouvoir fonctionner.

Si tu n'as pas accès à de machine plus puissante pour les maj de ton eepc alors je te déconseille Gentoo. Enfin c'est mon avis.

----------

## boozo

Une autre chose est que si tu n'a pas de toolchain dessus, stocker l'arbre portage est vraiment sans objet  :Smile: 

Le problème n'est pas tant la dimension de stockage disponible mais plus le cache L1,2 et la ram de la bestiole et là face à un desktop... y'a indubitablement aucun intérêt à vouloir compiler avec çà ! D'où l'usage abondant que nous fais(i)ons de distcc - un peu tombé dans l'oubli (pour les nouveaux venus) depuis l'arrivée des C2D.

----------

## Rvay

Réflexion: C'est pas un peu contradictoire de faire une distribution qui optimise les performances d'une machine et de ne laisser cete optimisation qu'aux pc les plus puissants ?

Question: combien de temps peut-on se passer des MAJ sans risque sérieux pour la sécurité de la machine ?

Merci   :Wink: 

----------

## guilc

Tant que "glsa-check -l" ne te remonte pas d'alertes sur ce qui est installé sur ton système, c'est pas la peine de mettre à jour pour raison de faille sécurité !

Il faut peut-être aussi regarder du côté du nouveau set @security sur les version récentes de portage (mais j'ai jamais utilisé)

----------

## kwenspc

 *Rvay wrote:*   

> Réflexion: C'est pas un peu contradictoire de faire une distribution qui optimise les performances d'une machine et de ne laisser cete optimisation qu'aux pc les plus puissants ?
> 
> 

 

Hum non tu peux installer Gentoo sur ce que tu veux, un 486 dx 4x100 avec 64Mo de ram est la limite basse il me semble. Le soucis c'est le facteur temps et dans ton cas le disque flash du eeepc: les compiles ça crée/détruit un tas de milliers petits fichiers, c'est pas génial pour ce genre de disque. 

Libre à toi d'installer Gentoo dessus, c'est juste un conseil qu'on te donne, tu peux ne pas le suivre.  :Wink: 

----------

## Rvay

Oki, je comprends bien vos points de vue. Dès lors, il me semble que la seule solution dans mon ca soit des mises à jour moins fréquentes sauf si: 

 *Quote:*   

> Oui bien entendu, portage et son arbre son indissociables pour pouvoir fonctionner.

 

est-ce que cela veut dire qu'il n'y a plus moyen d'installer aucun logiciel par la suite ? (désolé, n'ayant pas encore instalé gentoo, je n'ai pas encore saisi tous les aspects de portage...)

----------

## boozo

 *Rvay wrote:*   

> 
> 
> Réflexion: C'est pas un peu contradictoire de faire une distribution qui optimise les performances d'une machine et de ne laisser cete optimisation qu'aux pc les plus puissants ?
> 
> Question: combien de temps peut-on se passer des MAJ sans risque sérieux pour la sécurité de la machine ?
> ...

 

Non c'est une erreur de sens. L'optimisation concerne la cible ; en l'occurrence ton bidule qui n'est pas taillé pour compiler. Donc tu dédie cette charge à ton desktop qui lui l'est - mais tu précise à ta bête de course que les produits qu'il doit fabriquer il doit les faire en considérant les optimisations d'usage pour la cible seulement et non celles qu'il devrait prendre pour lui-même. (c'est le même principe que pour la cross compilation du reste ^^ )  

Pour ce qui est de la fréquence des màj là, c'est très personnel et ça dépend surtout de l'usage de la machine en question. Pour un serveur par exemple, on met à jour seulement pour combler des failles de sécurités ou pour faire une mise à niveau en cas de compatibilité ascendante brisée par un soft... changement d'ABI etc, ou un ajout de fonctionnalité. Pour un desktop c'est plus selon la sensibilité de l'utilisateur - hormis la considération "sécurité" qui s'applique également ici, d'expérience : 1 x par semaine ou tous les 15 jours voire 1 x par mois c'est largement suffisant pour pas se prendre trop la tête  :Wink: 

 *Rvay wrote:*   

> Oki, je comprends bien vos points de vue. Dès lors, il me semble que la seule solution dans mon ca soit des mises à jour moins fréquentes sauf si: 
> 
>  *Quote:*   Oui bien entendu, portage et son arbre son indissociables pour pouvoir fonctionner. 
> 
> est-ce que cela veut dire qu'il n'y a plus moyen d'installer aucun logiciel par la suite ? (désolé, n'ayant pas encore instalé gentoo, je n'ai pas encore saisi tous les aspects de portage...)

 

Là encore le taf c'est pour le desktop : si tu veux des fonctionnalités supplémentaires pour ton bidule, tu dis au desktop ce que tu veux, il fait le job et tu en profite lors de la màj

----------

## Rvay

Merci Boozo pour cette explication, c'est vraiment limpide expliqué comme cela. 

Malheureusement, je pars en échange étudiant pendant 5 mois, je n'aurais donc pas accès à mon PC desktop pendant ce temps-là. Je vais donc me réorienter vers une autre distribution plus adaptée aux contraintes que j'ai. 

Un tout grand merci en tout cas, je retiendrai de ces petits échanges que la communauté gentoo est très réactive et très amicale. 

Bonne continuation à vous tous !

Tschuss

----------

## Rvay

A y réflechir, j'ai peut-être jeter l'éponge un peu trop tôt.

Ne serait-il pas possible de prendre contrôle de mon pc desktop avec l'eee de lancer la compilation des mises à jour sur le desktop et de les récupérer via le net ?

Merci   :Wink: 

----------

## boozo

hé hé je n'ai pas osé le proposer bien que cela m'a traversé immédiatement l'esprit à l'instant ou j'ai lu ton post   :Razz: 

Dsl mais c'est trop tard ! Je crois que tu es mûr pour gentoo sur l'eeepc   :Mr. Green: 

Plus raisonnablement : tu t'exposes à des risques sérieux mais si tu prépares bien ton coup à l'avance c'est peut-être jouable - mais faudra te faire une vrai doc propre et vraiment tester des dépoiements avant de partir.

Après tu peux aussi très bien passer 5 mois sans màj et rentrer pour un upgrade général (d'autres ici l'ont fait) ; peut être juste contrôler les failles de sécu de temps à autres et pour peu que tu n'ais pas besoin de tout plein de soft en sus en cours de route.

Et pis si tu as 12Go... y'a moyen d'avoir une roue de secours en cas de pépin ^^

Edit: ajout d'une once de raison pour éviter les catas à 2000km en veille d'examen

----------

## Rvay

Thanks   :Wink: 

Pour les softs, j'ai rédigé une liste de ce dont j'avais besoin. Cependant, j'ai quelques trous car je voudrais utiliser compiz en WM indépendant ... 

Mon problème se place principalement au niveau du son (sur ubuntu, un gars avait pas mal de prob et il a installé un serveur jack. J'espère cependant ne pas devoir en arriver là) et du réseau sans fil (j'aimerais gérer mes réseaux sans gnome-network-manager. Je pensais à netcfg mais le problème reste la découverte des réseaux). Si quelqu'un a une suggestion, je suis preneur !

----------

## boozo

Oulàla y'a déjà trois termes qui sortent de mon univers : compiz, wifi et (Arghl!) gnome - je suis navré mais je ne te serais pas d'une grande utilité pour la suite ; suis plus sans bling-bling et autres farces et attrapes - les vieux faut pas trop leur changer leurs habitudes : sorti du shell et du rj45...  :Laughing: 

Au plaisir de lire le retour d'expérience dans 5 mois alors    :Wink: 

----------

## ppg

Sur mon eeepc 1000 le son n'a pas trop été un problème : seul les micro (2 micros en dessous de l'écran) ne fonctionnaient pas correctement, avec alsa < 1.0.18.

Par contre compiz sur le chip' du eeepc c'est pas la joie, j'ai abandonné cette idée.

Sur le eeepc 1000 le ventillo tournait à fond, la faute à je ne sais plus quel script… le problème est réglé en éxécutant un script qui régule la vitesse du ventillo toute les 10 secondes [1].

Voilà mon mini retour d'expérience eeepc : normalement tout fonctionne correctement, le micro, le wifi et la vitesse du ventillo demandent quelques réglages pour fonctionner correctement. Je peux rien dire sur le bluetooth : j'ai pas tester, et je l'ai désactiver dans le bios pour gagner un peu de batterie.

Voilà, bon courage   :Wink:  .

PS : sinon le coup du desktop piloté depuis l'étranger c'est plutôt risqué, surtout si tu n'as pas le temps de sécuriser ton pc et/ou de faire les mises à jour de sécurité. Je ne tenterai pas le diable à ta place.Last edited by ppg on Thu Dec 18, 2008 9:39 am; edited 1 time in total

----------

## kwenspc

C'est pas une intel la CG sur eeepc? AIXGLX devrait tourner sans problème, donc compiz aussi. Un soucis de réglage non?

----------

## ppg

 *kwenspc wrote:*   

> C'est pas une intel la CG sur eeepc? AIXGLX devrait tourner sans problème, donc compiz aussi. Un soucis de réglage non?

 

Surement, j'ai pas vraiment regardé pourquoi ça fonctionne mal,  mais ce chip' fonctionne sans problème vu qu'on peut jouer à xmoto  :Razz: 

----------

## Rvay

Hello ppg, 

en fait j'ai p-e mal expliqué ce que je voulais faire: je veux me servir de compiz uniquement, un peu dans le style e17 & co. Je n'installerais donc aucun gnome, Kde ou xfce. Une personne sur ubuntu a déjà fait ce type de configuration en passant par xinitrc et il a gagné pas mal en fluidité. Seulement n'ayant pas installé une "suite tout en un", il a eu quelque problème de son (et il a installé un serveur jack..). 

Sinon c'est bizarre pour compiz, j'ai l'eee 900 et il gère compiz sans problème (sous archlinux et ubuntu). 

 *Quote:*   

>  PS : sinon le coup du desktop piloté depuis l'étranger c'est plutôt risqué, surtout si tu n'as pas le temps de sécuriser ton pc et/ou de faire les mises à jour de sécurité. Je ne tenterai pas le diable à ta place.

 

j'ai en effet réfléchi un peu plus à la chose et me suis rendu compte que je me compliquais la vie pour rien   :Shocked:   J'ai listé tout ce dont j'avais besoin sur l'eee. De plus, je vais mettre un kubuntu-eee sur une carte sd externe. Ca permettra de me dépanner en cas de pépin ou d'oubli et il ne restera plus qu'à corriger tout cela à mon retour. 

En poussant un pas plus loin le raisonnement, serait-il possible d'installer une machine virtuelle qui me permette de lancer Kubuntu (carte sd externe) sur gentoo   :Question: 

----------

## boozo

 *Rvay wrote:*   

> (snip)
> 
>  *ppg wrote:*    PS : sinon le coup du desktop piloté depuis l'étranger c'est plutôt risqué, surtout si tu n'as pas le temps de sécuriser ton pc et/ou de faire les mises à jour de sécurité. Je ne tenterai pas le diable à ta place. 
> 
> j'ai en effet réfléchi un peu plus à la chose et me suis rendu compte que je me compliquais la vie pour rien    J'ai listé tout ce dont j'avais besoin sur l'eee.
> ...

 

Oui et non... c'est quand même jouable sans trop galérer i.e :

→ avoir portage d'installé sur l'eeepc (hors l'arbre lui-même)

→ avoir qq'un qui vous allume le desktop sur demande (tel./mail par exemple) et que cette personne vous donne l'ip pour attaquer la machine en ssh

→ se logger sur le desktop, faire un screen, lancer le sync du desktop vérifier les glsa toussa...

→ controler si on est affecté sur le eeepc :

si non, on ferme tout et la personne éteind le desktop jusqu'au mois prochain

si oui, faire un package binaire du soft affecté ; télécharger le tarball sur le client et faire un emerge -k sur l'eeepc

; et fermet le reste jusq'au mois prochain

 :Wink: 

----------

## bi3l

 *boozo wrote:*   

> → controler si on est affecté sur le eeepc :
> 
> si non, on ferme tout et la personne éteind le desktop jusqu'au mois prochain
> 
> si oui, faire un package binaire du soft affecté ; télécharger le tarball sur le client et faire un emerge -k sur l'eeepc

 

Il faut l'arbre portage pour faire un emerge -k.

----------

## kwenspc

 *boozo wrote:*   

> 
> 
> → avoir qq'un qui vous allume le desktop sur demande (tel./mail par exemple) et que cette personne vous donne l'ip pour attaquer la machine en ssh
> 
> 

 

un ptit dynamic dns.  :Wink: 

----------

## kwenspc

 *bi3l wrote:*   

>  *boozo wrote:*   → controler si on est affecté sur le eeepc :
> 
> si non, on ferme tout et la personne éteind le desktop jusqu'au mois prochain
> 
> si oui, faire un package binaire du soft affecté ; télécharger le tarball sur le client et faire un emerge -k sur l'eeepc 
> ...

 

En effet, faudrait alors monter l'arbre sur le eeepc en distant: un ptit sshfs genre. (ça risque d'être un poil mou par contre non?)

----------

## Gaby

 *boozo wrote:*   

> Oui et non... c'est quand même jouable sans trop galérer i.e : 
> 
> → avoir portage d'installé sur l'eeepc (hors l'arbre lui-même) 
> 
> → avoir qq'un qui vous allume le desktop sur demande (tel./mail par exemple) et que cette personne vous donne l'ip pour attaquer la machine en ssh 
> ...

 

Cette solution fonctionne à partir d'un desktop Gentoo ce qui n'a pas l'air d'être son cas, cf son 1er post.

Perso je met en place le même fonctionnement sauf que j'aurai la main sur le desktop (je prépare le portable pour ma soeur), je prévois le fonctionnement suivant :

Prérequis :

- Linux installé sur le desktop (peu importe la distrib)

- Faire un chroot Gentoo configurer pour le portable sur le Desktop (via chenvr par exemple)

- Installer Syndgen dans le chroot

Fonctionnement :

- Allumer ou faire allumer le desktop

- Entrer dans le chroot

- Mettre à jour le chroot

- Lancer le script de mise à jour sur le portable

- Couper le desktop

Pas besoin de emerge et portage sur le portable.

----------

## boozo

@All : Ouiii bon çà vaaa... c'était pas une checklist ce que j'ai mis, c'était juste donner l'idée   :Laughing: 

btw: j'ai jamais essayé d'utiliser portage sans l'arbre à vrai dire, mais le onlypkg vous êtes sûr qu'il fait vraiment un check du porttree avant ?! on peut pas passer par le metadata juste et faire une màj du bintree ?

Edit: @Gaby

Arf! Mais c'est vrai çà j'ai zappé le point dans l'histoire   :Sad: 

Dans ce cas il n'y a plus que la solution distcc avec 0% sur le client alors... ce qui explique mieux certaines remarques du fait... mais alors autant là je n'ai plus de doutes sur le temps de traitement occasionné (vu la connexion ; qu'il y a un desktop derrière ; etc)

 /me se souvient très bien des joies de la compil distribuée en ssh rhàaa la grande époque  snirf!

----------

## bi3l

 *boozo wrote:*   

> btw: j'ai jamais essayé d'utiliser portage sans l'arbre à vrai dire, mais le onlypkg vous êtes sûr qu'il fait vraiment un check du porttree avant ?! on peut pas passer par le metadata juste et faire une màj du bintree ?

 

Il faut l'arbre parce que même une installation binaire doit effectuer certaines fonctions des ebuilds genre pkg_config.

----------

## Gaby

 *boozo wrote:*   

> 
> 
> Dans ce cas il n'y a plus que la solution distcc avec 0% sur le client alors... ce qui explique mieux certaines remarques du fait... mais alors autant là je n'ai plus de doutes sur le temps de traitement occasionné (vu la connexion ; qu'il y a un desktop derrière ; etc)
> 
>  /me se souvient très bien des joies de la compil distribuée en ssh rhàaa la grande époque  snirf!

 

Au risque de me répéter

Ou utiliser un chroot et tout faire dessus .... Kwenspc nous fait des scripts qui fontionnent très bien c'est pour s'en servir.

----------

## boozo

heuu... comme tu l'a dit, si le desktop n'est pas aussi sous gentoo je ne vois pas en quoi ça aide   :Shocked: 

Edit: hann j'ai relu ton post ok dsl non mais là je vois pas l'intérêt d'une config pareille sur le desktop autant être directement sur gentoo si vous voulez mon avis   :Rolling Eyes: 

----------

## Rvay

Hello tout le monde, 

si cela est vraiment problématique pour la mise en place, je peux également prévoir un dualboot sur mon desktop (gentoo/ windows car je ne suis pas le seul à utiliser ce pc ... ) !?

Je m'en remets à vos conseils car j'avoue ne pas avoir suffisament de connaissances pour déterminer la meilleure méthode...

----------

## Gaby

@Rvay : Qu'est ce que tu as comme OS sur ton desktop actuellement ?

Si tu as un Linux :

Garde le et il faudra installer Gentoo dans un chroot

Si tu n'as que Windows :

Installe Gentoo ou une autre distrib et il faudra de tte façon installer Gentoo dans un chroot

Dans les 2 cas, la Gentoo du chroot sera configuré pour le eeepc au lieu du Desktop.

----------

## boozo

*joke* Vous verrez que çà va finir avec un wmvare/virtualbox sous win$ avec un gest linux qui héberge une gentoo en chroot et qui... c'est beau le KISS  :Mr. Green: 

----------

## Rvay

Pour l'instant, il n'y a que windows sur le desktop. 

Je pense qu'il serait mieux que je mette gentoo pour le dualboot (mais si vous pensez que j'ai tort, je suis ouvert à une autre solution...): 

1° pour me familiariser avec la distribution et faire une première install "plus classique"

2° n'est-ce pas plus compliqué de faire un sous-système via chroot sur une autre distribution !?

@boozo: reste plus qu'à trouver un nom au principe qui exprime le fait de tout compliquer ...

 windows ? 

----------

## Gaby

 *Rvay wrote:*   

> 
> 
> 2° n'est-ce pas plus compliqué de faire un sous-système via chroot sur une autre distribution !?
> 
> 

 

Chroot n'étant pas lié à Gentoo je ne vois pas où pourrait être le problème. 

+1 pour l'insallation de gentoo en dual boot, tu te fera la main sur les fichiers de conf et portage avant de passer au chroot.

@boozo : Pourquoi faire simple quand on peut faire compliquer ?

----------

## kwenspc

 *Gaby wrote:*   

> 
> 
> Chroot n'étant pas lié à Gentoo je ne vois pas où pourrait être le problème. 
> 
> 

 

Justement pour chenvr il y a un tout ptit soucis: il tente de monter /usr/portage ceci dit, ça va fonctionner quand même, il v a juste y avoir un message d'erreur comme quoi il a pas réussis à monter le rep.

----------

## Gaby

 *kwenspc wrote:*   

>  *Gaby wrote:*   
> 
> Chroot n'étant pas lié à Gentoo je ne vois pas où pourrait être le problème. 
> 
>  
> ...

 

Arf ca veut dire que c'est pas la peine de faire un sync dans le chroot alors ?

/me se flagelle d'avoir saturé les serveurs pour rien

----------

## kwenspc

 *Gaby wrote:*   

> 
> 
> Arf ca veut dire que c'est pas la peine de faire un sync dans le chroot alors ?
> 
> /me se flagelle d'avoir saturé les serveurs pour rien

 

Argl, faut dire que c'est pas vraiment super documenté, encore un dev feignant qui  fait ça  :Laughing: 

----------

## Rvay

Désolé de vous demander ça, mais vous pourriez expliquer un peu ce qui a été dit sur chenvr. 

Je n'ai trouvé que cela sur le net et ça ne m'a pas vraiment éclairé   :Confused: 

 *Quote:*   

> Chenvr is a tool helping users to create chrooted Gentoo environment on x86 compatible machines. It handles 32 and 64 bits environments on a x86_64 machine (ARCH amd64). On a x86 machine it, of course, only supports 32bits environment. Since it uses chroot command, chenvr is a root user tool.
> 
> Chroot generally creates and handles what is called target. A target is a directory which contains the Gentoo installation which will be chrooted. A target owns its configuration in <path_to_target>/target>/.chenvr directory.
> 
> Chenvr allows the user to customize some scripts as well which are ran before entering the chroot, inside the chroot and after exiting the chroot. These scripts are called: prepare.sh, inside.sh and clean.sh and are located in the .chenvr directory of the target

 

----------

## kwenspc

 :Laughing: 

Eh oui je sais (Et pour cause...) c'est pas très clair tout ça... ahem.

Tu connais la commande chroot? Si oui et bien chenvr simplife enormément la mise en place d'un environnement Gentoo dans un chroot. (ce qu'on fait finalement à l'installation de Gentoo d'ailleurs).

Si tu connais pas hum, comment t'expliquer de manière simple: chroot permet de restreindre l'environnement courant à un repertoire donné, qui deviendra alors la racine dans l'environnement du chroot.

Ce qui est bien quand tu es en 64 bits c'est que tu peux lancer des binaires 32bits aussi (via la commande linux32). Au départ des gentoo 64bits, on se retrouvaient à être limité sur certaines applis qui ne tournait qu'en 32bits. Le seul moyen de les avoir c'était de ler lancer dans un environement 32bits. Quoi de mieux alors que de prendre un stage3 de gentoo 32bits, de le décompresser dans un rep et de chrooter se rep en 32bits pour y installer l'appli, la lancer ensuite?

chenvr simplifie toute les manips pour créer un tel envirronement. C'est un script shell en fait. Il gère de "cibles": des répertoires dans lequel il y a un "envirronement" (une install gentoo). 

ça me sert par exemple à pouvoir lancer epsxe (qui ne tourne qu'en 32bits) et d'autres applis dans un envirronement 32bits alors qu'en fait je tourne en natif en 64bits. Ça me sert aussi à mettre à jour mon serveur (que je synchronise ensuite avec syndgen) pour pouvoir utiliser la puissance de calcul de mon desktop plutôt que de tout faire sur ce vieux serveur. Les applications de chenvr dépendent des besoins de l'utilisateur.

l'idée là c'est que dans une cible chenvr tu gèrerais ton environnement pour eeepc (installations de softs, mise à jour) sur ton desktop (comme ça c'est pas ton eeepc qui bosse). Une fois que c'est fait tu synchronise ton eeepc avec syndgen si tu veux (où tu fais comme boozo disais: tu génères des paquets binaires que tu installes ensuite sur ton eeepc.

Si t'as des questions hésites pas

[edit] bon en fait je viens de me relire, je crois que c'est pas clair du tout mes explications ^^' [/size]

----------

## Rvay

Si si c'est très clair   :Very Happy: 

Mais par contre, je ne comprends ce que tu veux dire par:

 *Quote:*   

> Justement pour chenvr il y a un tout ptit soucis: il tente de monter /usr/portage ceci dit, ça va fonctionner quand même, il v a juste y avoir un message d'erreur comme quoi il a pas réussis à monter le rep.

 

Tu parlais d'un chroot de gentoo sur une autre distribution ou d'un chroot de gentoo sur gentoo ?

----------

## kwenspc

chenvr est prévu pour créer des envirronement Gentoo chrooté sous Gentoo, donc plutôt que d'avoir un second arbre portage dans l'environement chrooté, autant prendre celui de l'hôte. chenvr monte donc le rep /usr/portage de l'hôte sur le /usr/portage de la cible. 

Sur une autre distrib tu n'auras pas l'arbre portage sur l'hôte, donc ce montage va échoué. Mais c'est pas grave, t'auras juste un message d'erreur mais c'est tout.

----------

## Rvay

OK. I got it all! Merci beaucoup ! 

Je vais pouvoir faire la première installation sur le desktop. 

Dernière question (qui va sans doute me faire passer pour un inculte à vos yeux) avant d'éplucher la doc: 

Les différents stage correspondent si j'ai bien compris à des degrés différents de compilation.  J'ai vu dans la doc qu'avec le live cd on partait d'un stage 3. En parcourant la doc, j'ai vu que d'autres partaient de stage 1 (je vous rassure, je ne compte pas me lancer là dedans pour commencer   :Wink:  ). Concrètement, ça change quoi de passer par un stage 1 ?

----------

## Gaby

[joke]

 *kwenspc wrote:*   

>  *Gaby wrote:*   
> 
> Arf ca veut dire que c'est pas la peine de faire un sync dans le chroot alors ?
> 
> /me se flagelle d'avoir saturé les serveurs pour rien 
> ...

 

```
gaby@Shogun ~ $ man chenvr

Il n'y a pas de page de manuel pour chenvr.

```

  :Twisted Evil: 

[/joke]

----------

## kwenspc

 *Rvay wrote:*   

> 
> 
> Les différents stage correspondent si j'ai bien compris à des degrés différents de compilation.  J'ai vu dans la doc qu'avec le live cd on partait d'un stage 3. En parcourant la doc, j'ai vu que d'autres partaient de stage 1 (je vous rassure, je ne compte pas me lancer là dedans pour commencer   ). Concrètement, ça change quoi de passer par un stage 1 ?

 

Concrètement: tu vas passer encore plus de temps à tout compiler  :Laughing: 

En fait débuter en stage te permet de compiler avec tes CFLAGS persos tout le système de base (les paquets système sont les paquets obligatoire à Gentoo). Alors qu'en stage3 ça se fait ensuite petit à petit après les mises à jour (si des paquets du système ont besoin d'être mis à jour). Ça a un intérêt que très limité, en fait c'est vraiment si tu configures des CFLAGS vraiment exotiques, que tu veux jouer au "tuning" gentoo dès l'install. Je crois pas que beaucoup installent leur Gentoo à partir d'un stage1 de nos jour, puisqu'avec les mises à jour au bout de 6mois un 1 le système d'un stage3 est mis à jour complètement donc on en vient au même.

----------

## dapsaille

 *kwenspc wrote:*   

>  *Rvay wrote:*   
> 
> Les différents stage correspondent si j'ai bien compris à des degrés différents de compilation.  J'ai vu dans la doc qu'avec le live cd on partait d'un stage 3. En parcourant la doc, j'ai vu que d'autres partaient de stage 1 (je vous rassure, je ne compte pas me lancer là dedans pour commencer   ). Concrètement, ça change quoi de passer par un stage 1 ? 
> 
> Concrètement: tu vas passer encore plus de temps à tout compiler 
> ...

 

Ou alors 

emerge system -e && emerge system -e && emerge system -e && emerge world -e && emerge world -e && emerge world -e

 Quoi ??? c'est vendredi je me lache   :Wink: 

----------

## kwenspc

hum system est inclus dans world non? On est vendredi on en tiendra pas rigueur ^^

----------

## Enlight

Hormis la toolchain, je vois pas ce qui peut nécessiter plus d'une compile...

----------

