# [CONTRIB] portage-utils et les overlays(maj 05/04) testeurs?

## truc

EDIT 14/02 cd là => https://forums.gentoo.org/viewtopic-p-3908914.html#3908914

EDIT 28/01 cf ici => https://forums.gentoo.org/viewtopic-p-3871366.html#3871366

Edit 19/01 et non, finalement ici ah non là: https://forums.gentoo.org/viewtopic-p-3852844.html#3852844

Edit 18/01 ça se passe ici https://forums.gentoo.org/viewtopic-p-3852309.html#3852309

Edit de 08/07 : cf ici -> non là  :Razz:  : toi portagien, ne passe pas ton chemin, j'ai besoin aussi de ton aide pour tester tout ça, merci d'avance.. :Smile: 

edit du 22/11-> cf ici pour les news:)

[EDIT]Re, à la base j'avais fait ce post pour ajouter le support de paludis, mais qui dit ajouter support pour paludis dit ajouter suport pour es overlays, donc j'ai scindé le patch en deux, et fait en sorte que les overlays puisse fonctionner aussi avec portage, donc voici ce qui a changer:

Suite au passage sur BGO, on m'a conseillé de faire les modifs directement sur la version, cvs, donc, voici, les news:

Les utilisateurs de portage et ceux de paludis peuvent télécharger le même ebuild, à noter qu'il n'y a plus besoin de télécharger des patchs etc... l'ebuild devrait le faire pour vous..

Pour les utilisateurs de paludis, n'oubliez pas de rajouter paludis en use flag pour ce package.

sinon, voici un mini résumé de ce qu'on a:option --ls-overlays pour l'outil q de base, pour voir un peu quels sont les overlays que vous avez de configurés.

option --overlay pour n'effectuer que la dite action pour les applets qsearch, qgrep, et quse, (cf plus bas pour plus de détails) et ainsi que pour qlop pour les utilisateurs de paludis

option --show-path pour qsearch pour retrouver facilement un ebuild dans toute l'arborescence

et c'est à peu près tout.

Pour ceux qui ne l'ont pas encore lu, vous pouvez jeter un coup d'oeil sur ce même post il y a peut-être d'autres informations suceptibles de vous interesser

[edit de l'edit] ahhh, j'avais oublié le plus important, la variable ROOT est désormais supportée aussi (comme elle l'était avant les overlays) , donc, si vous voulez faire des recherches dans un autre système, vous pouvez faire ça:

```
ROOT=/mnt/autre_install q[applets] [options]
```

[/edit de l'edit]

[/EDIT]

Salut, 

Bon ça fait un moment qu'on n'a pas eu de contrib (Le BAC à sable ) ici, donc je me suis dit que j'allais me relancer dans l'aventure.

Voila, certains d'entre vous connaissent surement déjà paludis, on en parlait notamment ici

Les outils fournis avec paludis(adjutrix, et qualudis sont en constante amélioration, toutes fois, il me manque des outils simples et performants pour faire entre autres, des recherches de packages, de chemins, de variables etc.. Beaucoup de ces choses sont possibles avec paludis itself.. mais la manière de les obtenir n'est pas franchement toujours simple (c'est long à taper, etc..) bref, j'ai ressenti le besoin, comme d'autres, d'avoir quelque chose du style portage-utils mais pour paludis..

Bon voila, pour l'intro longue et pénible, j'ai plein de chose à dire, mais ça ne serait pas forcément interessant, donc j'essaierai d'aller à l'essentiel..

portage-utils, pour ceux qui ne connaissent pas encore "sont" (ou devrais-je dire c'est un outil de par la manière à laquelle il est conçu..) des outils bien pratiques pour tout utilisateur de gentoo/portage, malheureusement, ils ne sont pas  compatibles d'"emblée" avec paludis, et encore moins avec les overlays...

Vous trouverez donc ici un patch ( à mettre dans $[FILESDIR} ) pour les rendre compatibles (au maximum quoi...) ainsi que l'ebuild associé qui fera en sorte que le cache de l'outil soit réinitialisé automatiquement à chaque fin de --sync (comme c'était le cas par défaut quand on installait le portage-utils normal

(je ne ferai pas l'offense de renommer le package par contre.. :Smile:  )

Voici en bref les changements

général:

Support des overlays, le répértoire /etc/paludis/repositories, est visité, les overlays au "format = portage" sont gardés, et ajoutés à la liste des overlays (liste chainée simple), le nom de 

l'overlay est recupé dans  overlay/profiles/repo_name et si ce fichier n'existe pas alors le nom du répertoire de l'overlay qui est utilisé, préfixé de x- pour les utilisateurs de paludis (pour que ça soit conforme à son fonctionnement ).

Pour ceux que ça interesse, la syntaxe du fichier .ebuild.x a été légèrement modifiée pour mettre en évidence l'existence des overlays etc.. Donc pour ceux qui avait utilisaient déjà portage-utils, il faut reconstruire ce fichier: (en root) q --reinitialize

qatom :

RAS

qcache :

un outil qui a une option --stat très jolie. Nan plus franchement, adjutrix remplace cet outil normalement (c'est un outil fourni avec paludis) (d'autant plus qu'adjutrix fourni aussi tout un tas d'option très jolies:) )

qcheck :

RAS (on s'en sert pas souvent pourtant il est pourtant interessant;) )

qdepends :

RAS, celui la est bien pratique, par exemple, pour connaitre comment à été construit un certain paquet,en regardant dans la "VDB", on peut utiliser paludis:

```
paludis --environment-variable app-portage/portage-utils REPOSITORY

local
```

mais il faut noter que c'est long, (y'a pas de complétition ) et ça n'est pas très souple: nécessité de préciser la catégorie du package (ici app-portage) pour que ça fonctionne, avec le qdepends, voici ce que vous pouvez faire

```
qdepends -k REPOSITORY age-ut

app-portage/portage-utils-0.1.21: local
```

ok c'et pas grand chose mais c'est bien pratique..

qfile :

RAS

bon ok jusque là onse dit que j'ai vraiment rien foutu...  :Laughing: 

qgrep :

+ajout de la possibilité de ne 'greper' que dans un certain overlay (avec l'option --overlay. Je sais que je l'ai pas mal utilisé cet outil, pour connaitre la syntaxe de quelque chose dans un ebuild. alors pour accelerer les recherche onpeut desormais se limiter à un overlay:)

qlist :

Là encore, pas grand chose, si ce n'est qu'il est bien cet outil!

qlop :

+le premier que j'ai modifié, car c'était le plus simple, il fallait juste l'adapter à la syntaxe des logs de paludis, j'ai quand même rajouté l'option pour ne faire les recherche dans les logs que pour un overlay (avec l'option --overlay), mais bon, personnellement je ne passe pas mon temps dans les logs de paludis.. Mais ça peut toujours servir. 

Il faut noter qu'avec paludis les paquets installé "sont" dans un overlay installed et que quand on les désinstalle, on désinstalle un paquet de cet overlay, donc en parsant les logs, il n'est pas possible de dire si tel paquet désinstallé venait de tel ou tel overlay. (ok si c'est possible, mais le parsage se fait ligne par ligne donc non;) )

qpkg :

Je n'ai pas touché à celui-là, par contre, ça m'a fait penser que j'attends impatiemment que paludis supporte les "packages"? (vous savez avec quickpkg on pouvait les faire et tout.. :Smile:  Je suis incapable de leur donner un vrai nom..)

qpy :

RAS, désactivé par défaut à ce que je crois.

qsearch :

Vous avez du vous rendre compte, qu'il n'était pas vraiment possible de chercher avec paludis, chercher par le nom d'un package (à moins de le connaiter d'avance) ou même de chercher par la description, avec qsearch, ça va redevenir possible:) (c'était ma principale motivation au début, car aller sur le net pour chercher un package, ça va un peu, mais c'est une grosse perte de temps...) donc:

+Ajout du support des overlays! Ajout de la possibilité de ne chercher que dans un overlay donné(avec l'option --overlay), ça peut être très pratique ça je trouve, notamment pour se donné un rapide aperçu du contenu d'un nouvel overlay:

```
qsearch -a -o local

app-portage/portage-utils::local small and fast paludis helper tools written in C

dev-lang/tcl::local Tool Command Language

dev-lang/tk::local Tk Widget Set

dev-util/codeblocks::local free cross-platform C/C++ IDE

games-fps/ut2003-demo::local Unreal Tournament 2003 Demo

games-util/xqf::local A server browser for many FPS games (frontend for qstat)

media-sound/ncmpc::local A ncurses client for the Music Player Daemon (MPD) svn version

sys-apps/einit::local eINIT - an alternate /sbin/init
```

(le tout avec des jolies couleurs biensûr :Smile:  )

comme vous pouvez le voir, on peut voir maintenant dans quel overlay est trouvé tel ou tel package: (avec la syntaxe permettant de faire un joli copier coller pour l'installer directement avec paludis)

```
 qsearch -S paludis

sys-apps/paludis::gentoo paludis, the other package mangler

app-portage/portage-utils::local small and fast paludis helper tools written in C

sys-apps/paludis::paludis-overlay paludis, the other package mangler
```

+et sinon, ajout également de l'option --show-path bien pratique, c'est pour approcher l'option --ebuild d'esearch, personnelement j'm'en suis beaucoup servi, alors je sais c'est égoïste, mais j'ai rajouté l'option surtout pour moi, ça n'est pas parfait, mais c'est suffisant à mon gout:

```
qsearch esearch -p

app-portage/esearch::gentoo      /var/paludis/repositories/gentoo/app-portage/esearch/

app-portage/esearch::local      /var/paludis/repositories/local/app-portage/esearch/

app-vim/multiplesearch::gentoo   /var/paludis/repositories/gentoo/app-vim/multiplesearch/
```

Après ne vous reste plus qu'a jouer de votre touche TAB à noter qu'on peut encore une fois se servir de paludis, mais c'est plus contraignant

```
paludis --environment-variable app-portage/portage-utils EBUILD

/var/paludis/repositories/local/app-portage/portage-utils/portage-utils-0.1.21.ebuild
```

 (il faut avoir la catégorie etc..)

qsize :

RAS

qtbz2 :

RAS, jamais servi de cet outil!

quse :

+ Bon ajout du support des overlays, ajout de la possibilité de ne faire les recherches que dans un overlay donné, avec l'option --overlay, Option toujours bienvenue pour un rapide aperçu sur un overlay..

+support des overlays pour l'option --describe, bon ok sur celui là j'aimerai bien changer le monde mais bon.. je me lance: on voir souvent apparaitre des "use flags" étranges et pour le moins pas toujours très explicite dans les overlays, alors avec le support de l'overlay, les gentils mainteneur d'overlay vont gentillement ajouter une description de leur flags dans les fichiers profiles/use{,.local}desc, et même dans profiles/desc/* !  :Twisted Evil: 

Bon je ne sais pas si ça va les insiter à le faire (ils n'utilisent certainement pas tous paludis, et donc encore moi portage-utils pour paludis..) mais bon... onpeut rever:)

qxpak :

RAS, j'en ai jamais eu usage de celui-ci non plus

Voili-voilou, tous les commentaires sont les bienvenus, 

Il est à noter qu'en fait vu le travail effectuer, là ajouter le support des overlays pour le portage-utils vanilla n'est plus difficile du tout, je pense d'ailleur maintenant que j'aurai du faire  un patch générique pour portage-utils normal, et un autre pour paludis, comme ça tout le monde pourrait en profiter... Si j'ai le temps cette semaine je le ferai..

Voili-voilou..

----------

## boozo

[off] Quel boulot   :Shocked:  !  truc t'es parti pour être dev officiel gentoo fait gaffe   :Mr. Green: 

je n'ai pas le courage de me lancer avec paludis (encore trop bleeding edge pour moi ^^) mais je gage que Trevoke et d'autres dans la communauté ne manqueront pas d'apprécier ton travail à sa juste mesure et d'y adjoindre le leur   :Wink: 

Bonne continuation en tout cas   :Smile:   [/off]

----------

## truc

 *boozo wrote:*   

> [off] Quel boulot   !  truc t'es parti pour être dev officiel gentoo fait gaffe  
> 
> je n'ai pas le courage de me lancer avec paludis (encore trop bleeding edge pour moi ^^) mais je gage que Trevoke et d'autres dans la communauté ne manqueront pas d'apprécier ton travail à sa juste mesure et d'y adjoindre le leur  
> 
> Bonne continuation en tout cas    [/off]

 

Rhooo, merci boozo , mon fidèle casseur de monologue  :Laughing: 

----------

## CryoGen

Bon boulot ^_^ 

perso, j'ai essayé Paludis puis je suis revenu à notre bon vieux emerge. Les softs eix et portage-utils me manquaient trop  :Very Happy: 

----------

## truc

 *CryoGen wrote:*   

> Bon boulot ^_^ 
> 
> perso, j'ai essayé Paludis puis je suis revenu à notre bon vieux emerge. Les softs eix et portage-utils me manquaient trop 

 

bah voila alors, on est deux, sauf que j'ai insisté un peu plus:)  (mais dans les premières pages du thread paludis, j'avais quand même donné un astuce (une?) pour utiliser qsearch avec paludis:), mais ça n'était pas assez, je le conçois.

----------

## CryoGen

Je vais attendre que Paludis soit "fini" (ou presque) pour retenter l'experience  :Smile:  mais faudrait vraiment un support de eix  :Very Happy:  , j'adore ce soft ^_^

----------

## truc

 *CryoGen wrote:*   

> Je vais attendre que Paludis soit "fini" (ou presque) pour retenter l'experience  mais faudrait vraiment un support de eix  , j'adore ce soft ^_^

 

hormis la rapidité, que manque t'il à qsearch?

----------

## CryoGen

 *truc wrote:*   

>  *CryoGen wrote:*   Je vais attendre que Paludis soit "fini" (ou presque) pour retenter l'experience  mais faudrait vraiment un support de eix  , j'adore ce soft ^_^ 
> 
> hormis la rapidité, que manque t'il à qsearch?

 

Ben moi c'est la rapidité justement qui m'interresse  :Smile:  ...

Mais je n 'utilise pas beaucoup qsearch. De portage-utils j'utilise surtout qlop, qdepends

----------

## titoucha

 *CryoGen wrote:*   

> Bon boulot ^_^ 
> 
> perso, j'ai essayé Paludis puis je suis revenu à notre bon vieux emerge. Les softs eix et portage-utils me manquaient trop 

 

J'ai suivi exactement le même chemin.

@truc, beau travail, tout d'un coup paludis devient nettement plus intéressant.   :Very Happy: 

----------

## Bapt

Merci Truc, vivement que je récupère ma connexion Internet pour tester tout ça.

As tu contacter ciaranm ? peut être intègrera t il directement ton "paludis-utils", ou du moins le rajoutera t il dans les docs comme utilitaire très pratique pour paludis.

A noter aussi que paludis possède désormais un API ruby permettant de faire des script pour paludis en ruby, amis ruby-fan  :Smile: 

----------

## SanKuKai

Extra !   :Very Happy: 

Grand merci pour ton boulot truc.

Mais que reste-t-il à Portage ?   :Laughing:   :Wink: 

----------

## Temet

C'est sur que emerge a fait son temps... il est carrément trop lent pour gérer la taille actuelle de l'arbre portage.

Sur Fedora aussi ils ont réécrit yum (python > C) et la rapidité de certaines opérations passe de 30 secondes .... à 5 secondes.

... c'est mignon Python... m'enfin c'est mignon quoi.

J'espère que Paludis sera bientôt en remplaçant complet et fiable d'emerge et je te remercie pour ton boulot  :Wink: 

----------

## Bapt

La cause des lenteurs de emerge n'est pas le langage de programmation pkgcore qui est une autre alternative à portage (tout comme paludis) est écrit en python et à des performences nettement plus appréciables que emerge.

Après la vm de python reste lente malgré tout.

----------

## truc

salut, je fais un petit bump, juste pour dire que ça a pal mal bougé, le support des overlays est désormais disponible pour portage également, et le support de paludis se fera via l'ajout du useflag paludis  :Smile: 

correctifs: 

si un overlay existait mais qu'il n'existe plus, cela provoquera un regénération du fichier .ebuild.x, (si les droits sont suffisants, sinon ça passera juste au suivant..).

pour l'option --overlay il y'a maintenant un test qui vous préviens si le nom de l'overlay entré est correct ou nom ( overlay existe ou non)

cf premier post, j'ai edité un peu..

EDIT: j'ai oublié de préciser que vous pouvez également faire vos bidouilles pour un autre system, en changeant la racine ex ( ROOT=/mnt/autre_sytem qlop -l ) 

voili-voilou  :Smile: 

----------

## truc

iopipo, j'ai eu un peu de temps ce soir, alors, j'ai rajouté le support de l'option --current pour qlop pour paludis (je l'avais enlevé avant car j'n'avais pas pris le temps de le faire...) , d'ailleurs qu'elle est maintenant bien mieux que chez nos amis les portagiens  :Laughing:  , car maintenant, il y a non seulement le package qui est indiqué mais aussi, l'overlay depuis lequel il provient  :Smile: 

le nouvel ebuild, ebuild

A noté que je corrige également un petit bug pour quse  :Smile: .

voili-voilou

du style voila ce que les paludiens (paludistes?) auront:

```
$ qlop -c

 * gentoo::app-shells/bash-3.2_p5.ebuild

     started: Thu Nov 16 13:38:48 2006

     elapsed: 8 seconds

```

à la place de quelque chose comme ça:

```
$ qlop -c

 * bash-3.2_p5.ebuild

     started: Thu Nov 16 13:38:48 2006

     elapsed: 8 seconds
```

pour les portagiens..  :Smile: 

----------

## nemo13

 *truc wrote:*   

> nos amis les portagiens 

 

Bonsoir truc,

Avant que j'attrape le paludisme   :Rolling Eyes: 

est-que EIX marche avec palud car j'adore eix-sync -v pour mes actualisation de l'arbre et les sorties du type :

 *Quote:*   

> [I] sys-libs/glibc 
> 
> ................Available versions:  (2.2) [P]2.2.5-r10 [P]2.3.2-r12
> 
> ................2.3.3.20040420-r2 (~)2.3.4.20040619-r2 2.3.4.20040808-r1 2.3.4.20041102-r1 *2.3.4.20041102-r2
> ...

 

( j'ai changé le jaune en orange car sur le forum ce n'est pas tip-top )

eix -I me permet d'un coup d'oeil de voir :

les versions ( stables ou tildées )

la date de celle installée

les flags ( activés ou omis )

je t'avoue hésiter à lacher ces facilités pour de la rapidité.

A+:jlp

----------

## truc

tu m'as fait réessayer eix, et je me rends compte que ça faisait vraiment longtemps que je ne l'avais pas utilisé! Ca a tellement changé! (j'trouverais presque d'ailleurs qu'il y a maintenant trop de couleurs... mais bon, on doit s'y faire je suppose  :Wink:  )

bon, bref, comme ça d'emblée, c'est sans surpise, mais eix ne fonctionne pas, il se plaint de ne pas avoir le symlink /etc/make.profile (que toi, portagien tu dois avoir mais bon..) donc, j'n'ai pas très bien compris pourquoi il voulait ça mais bon je lui ai donc donné le symlink kivabien, puis, pour qu'eix sache un peu les overlays que j'ai, j'lui ai également créé un mini make.conf:

```
echo -e "PORTDIR=\"/var/paludis/repositories/gentoo\"\nPORTDIR_OVERLAY=\"/var/paludis/repositories/local /var/paludis/repositories/initng /var/paludis/repositories/einit /var/paludis/repositories/paludis-overlay\"" > /etc/make.conf
```

ensuite, j'ai fait un update-eix, et ça a fonctionné(dans le sens je peux faire des recherches etc...), maintenant, je ne vais pas utiliser eix-sync, car ça utilise tout simplement emerge.... mais bon, d'après ce que j'ai vu dans les man pages, il doit y avoir moyen de jouer avec les fichiers de cache de eix et de diff-eix, mais je le conçois c'est pas forcément très marrant... :S

bref, le bon coté des choses, c'est que contrairement a portage-utils, eix est déjà conçu pour supporté les overlays, donc le faire supporter paludis devrait être bien moins dur!

à titre d'exemple, (si je ne prends pas en compte la syntaxe des logs d'emerge et de paludis qui sont différents mais que de totues façons eix n'utilise pas) une fois que j'ai modifié portage-utils pour qu'il supporte les overlays j'avais donc une fonction initialize_overlays(), qui fait ce que sont nom indique. donc la différence entre la version de portage-utils pour portage et celle pour paludis est simplement cette fontion! car rien n'est 'rangé ' pareil, mais une fois qu'on a les infos, le déroulement reste le même.

Donc voila  :Smile: 

Et sinon pour ce qui est de la vitesse, il ne faut pas abuser non plus.. certes paludis est plus rapide, mais c'est surtout emerge qui est vraimeent très lent, il y a une nuance à bien saisir là.

EDIT: j'aimerais bien qu'on m'expique comment on utilise l'option --overlay pour eix d'ailleurs?  :Question: 

----------

## nemo13

>Truc 

merci pour tes infos

j'essayerai peut-être paludis , ... mais sur un autre boot.

A+

----------

## truc

resalut:)

cela (peut) concerner tout le monde, les gens de portage et les gens de paludis  :Smile: 

ebuild

juste un petit bump pour dire, qu'il y avait quelque chose j'aimais bien avec gentoolkit, c'était de visualiser la signification des use flags pour un package donné, j'ai rajouté quelque chose d'un peu similaire avec quse, si il y en a qui veulent essayer ils sont les bienvenus:)

(ça ne marche qu'avec le switch --all, puisque sinon, les arguments ont une autres signification)

exemple:

```
quse -a ludis-scm orrent-stats -vv 

gentoo::net-p2p/bittorrent-stats/bittorrent-stats-3.2.1b-r4.ebuild X 

 global:X: Adds support for X11

paludis-overlay::sys-apps/paludis/paludis-scm.ebuild doc pink selinux qa ruby glsa 

 global:doc: Adds extra documentation (API, Javadoc, etc)

 local:pink:sys-apps/paludis: Use a less boring colourscheme than the default

 global:selinux: !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur

 local:qa:sys-apps/paludis: Enable QA tools.

 global:ruby: Adds support/bindings for the Ruby language

 local:glsa:sys-apps/paludis: Enable parsing of GLSA files

```

si vous avez déjà l'ebuild, vous pouvez juste le renommer avec 20061122 à la place du précédent, sinon il se trouve ICI (vous n'avez qu'a sauvegarder l'ebuild, les patches seront téléchargés tout seul)

remarquez qu'il y a plusieurs niveaux de verbeuhchaipasqoua, verbosity ?

----------

## Mickael

Salut truc,

tu dis :

 *Quote:*   

> EDIT: j'aimerais bien qu'on m'expique comment on utilise l'option --overlay pour eix d'ailleurs? 

 

je vois pas trop ou tu peux rammer..   :Confused:  le man est pourtant très clair non?

je sais pas comme ça au hasard : 

```
eix -s --in-overlay

[I] media-sound/exaile [1]

     Available versions:  (~)0.2.5

     Installed versions:  0.2.5(12:54:52 15.11.2006)(aac fam flac ipod mp3 musepack trayicon)

     Homepage:            http://www.exaile.org/

     Description:         Exaile is a media player aiming to be similar to KDE's AmaroK, but for GTK

[1] /usr/local/portage

```

Mais il y a encore pas mal d'option avec overlay.

Au fait j'ai remarqué ce matin que paludis venait d'entrer dans portage (je suis en ~x86). Sans avoir fouiner, et si tu préfères répondre en mp no problem, il le voit comment les dev-portagiens ce projet paludis à long terme. (fusion, pas fusion, disparition de l'un ou l'autre...)

EDIT : merci Bapt, mais j'allais virer mon post et lui transmettre mes questions en mp afin de ne pas polluer le boulot de truc. tant pis.

----------

## Bapt

 *MickTux wrote:*   

> Au fait j'ai remarqué ce matin que paludis venait d'entrer dans portage (je suis en ~x86). Sans avoir fouiner, et si tu préfères répondre en mp no problem, il le voit comment les dev-portagiens ce projet paludis à long terme. (fusion, pas fusion, disparition de l'un ou l'autre...)

 

Il y est depuis le moi de mai (pour faire plaisir à ciranm l'arbre ne s'appelle pas portage le vrai nom dans le cvs c'est gentoo-x86 (nom absurde d'ailleur) moi je préfère arbre gentoo.

http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/sys-apps/paludis/ChangeLog

Concernant ta question, une glep à été pondu pour dire que l'arbre gentoo est indépendant de l'outil (actuellement portage) de la même manière que dpkg et apt sous debian, et que gentoo supporte uniquement portage officiellement pour le moment, mais si un autre atteint le même niveau fonctionnel (pas de regression par rapport à l'officiel du moment) alors il peut le remplacer. pour le moment paludis et pkgcore sont dans la course, mais paludis est largement plus en avance.

(grosso merdo c'est ce qui en ressort)

----------

## truc

Salut, j'déterre, juste pour dire que j'ai modifié un peu le port(age) de qlop pour paludis, car il y avait quelques trucs imparfaits. C'est maintenant arrangé, voici le nouvel ebuild:

portage-utils-20061219.ebuild

Comme d'hab rien à faire si ce n'est télécharger l'ebuild et le placer là où il faut.

PS: cette nouvelle version n'interessera pas les portagiens, puisqu'elle ne leur apportera rien du tout  :Smile: 

EDIT: passage de la version 1217 en 1219 car la 1217 ne prennait pas en compte le fait qu'un utilisateur puisse vouloir lancer deux install avec 'paludis' en même temps (et donc que les logs vont un peu se croiser etc..)

bref, normalement ça devrait être bon.

----------

## CryoGen

Faudrait voir avec l'equipe de dev s'ils ne pourraient pas intégrer ton ebuild à l'overlay paludis... ca serai sympa  :Smile: 

----------

## truc

iopiop, comment ça va bien?

Bon, j'ai fait pas mal de modifs encore, et avant de faire un joli changelog pour tout le monde(en), j'aimerais vous demander, si vous voyez des trucs qui clochent, anomalies, plantages, ou même (qui sait) une mauvaise gestion de la mémoire( segfault? pas de free? :/ )

Bref,  j'ai normalement déjà testé la chose, mais avec la quantité d'option de chaque outils, j'ai très bien pu faillir..  :Smile: 

Je ne demande donc rien de particuler, juste, si vous avez le temps, de tester la bete.

Donc voici, de mémoire et en désordre, ce qui a changé (j'suis pas chez moi, j'ai pas mon brouillon de changelog avec moi..):

Alors...

[*] Modification de qatom, pour lui faire supporter, les overlays: 

Du style, qatom cat/pkgname-version-rX::overlay vous renvera quelque chose comme ça -> cat pkgname version X overlay

Ainsi, si vous utilisiez déjà qatom dans des scripts ou quoique ce soit, ça ne devrait pas le rendre incompatible, puisque j'ajoute juste l'ovraly en fin de ligne.

Comme vous pouvez vous en douter, il n'y aura pas de classement entre les overalays, donc qatom -c cat/pkg-12-r7::un_overlay cat/pkg-12-r7::un_autre_overlay vous dira que c'est la même version (comme c'est étonnant...)

Qatom saura désormais gérer les version -scm, -svn, -cvs, -live qui sont toutes équivalent à 9999 (fallait bien choisir quelque chose...), il n'y a ps de support de -try, parce que, c'est pas utilisé à ma connaissance, et surtout parce que il faudrait réécrire qatom (plus précisément, atom_explode.c et atom_compare.c), ce qui ne m'interesse que moyennement.

[*] (uniquement paludis) rajout d'un niveau de verbosité pour qlist, et qfile, -v pour les version et -vv pour les version et les overlays

[*] une grande révolution(  :Razz:  ) est la possibilité d'utiliser le cache pour TOUT les overlays, si il est défini.

(portage n'a à ma connaissance pas de moyen de définir un cache par overlay, mais, si c'est possible, alors 2,3 modifs et les portagiens pourront profiter de ça également, jusque là, ils doivent se contenter du cache de l'arbre gentoo, uniquement.

Pourquoi, utiliser le cache? pour avoir des résultats plus fiable, car certains ebuilds, ne contiennent quasiment rien (ils reposent dans la quasi-totalité sur des eclass, et du coup, une recherche classique est faussée (exemple, pas de HOMEPAGE=, ni de DESCRIPTION= dedans.. (pour en avoir une idée, essayé de faire qsearch -S quake, et qsearch -Sc quake -> zavez vu?  :Razz: 

En plus quand on fait des recherches avec la description, ça va un peu plus vite... (mais bon, on utilise plus eix dans ces cas là...)

[*] j'ai du en oublié, mais la dernière grosse modif concerne encore qlop, qui tire profit (tout comme qsearch -c d'ailleurs..) du nouveau qatom.

On peut faire des recherches très précises maintenant, package version revision.

Mais c'est pas le plus fun:

On peut désormais faire tout un tas de recherche plus farfelues les unes que les autres, du style,

ajout en mode verbeux, du temps total écoulé, Ainsi vous pouvez voir le temps que vous avez passé à compiler des packages dans telle catégorie, tel ou tel overlay etc..

un truc comme ça de mémoire : qlop -tv sys-libs/  ou qlop -tv ::local ou encore une combinaisons des deux, etc...

J'trouve ça marrant, d'ailleurs rien que pour avoir ça je passerai  paludis..  :Razz: 

Il y a également maintenant une vraiment meilleure gestion de la lecture du log:

si plusieurs emerge ont lieu en même temps, qlop, continue à chercher la fin de l'installation du package EXACT (cat/pn-pvr::overlay) sur une vingtaine de ligne (c'est un nombre choisi tout à fait arbitrairement, si vous ne trouvez pas cette valeur convenable faites le moi savoir), si en parsant le log, l'installation de ce même package arrive, alors le premier début d'installation trouvé est considéré comme invalid (il a du être interrompu, ou a planté), le 'parsage continuera alors à la ligne suivante

Voili-voilou, j'ai essayé de ne pas mettre trop de détails inutils, dites moi, si c'est pas clair..  :Smile: 

En fait, hier, il y a eu des modifs sur le cvs de portage-utils, j'ai essayé d'agir en conséquence, mais je n'ai par exemple pas d'autre installation à tester (pas de chroot dispo là..) donc je ne peux pas tester les outils en changeant la racine (si ce n'est un bète ROOT="/./"  :Wink:  ) Donc voila, 

J'apprécierai un petit coup de main:)

Et sinon, pour ceux qui ont vraiment envie de faire quelque chose de bien, ça serait de revoir, les make -C tests/qatom ou quelque chose comme ça, car ça utilise python et portage, et bah, c'est moyen quoi... donc, j'ai désactivé le test dans l'ebuild directement...

TODO: apprendre à utiliser les puces :/

----------

## Bapt

Merci pour tout  :Smile: 

Un petit souci tout de même pour moi avec la nouvelle version (use paludis bien sûr) :

```
#qsearch portage-utils                                                                   <(11:51:31)>

search: qsearch_main(): (cache update pending) app-accessibility/SphinxTrain/SphinxTrain-0.9.1-r1.ebuild : Unknown overlay

```

par contre qsearch -c fonctionne parfaitement.

----------

## truc

en fait, c'est parce que j'ai changé (encore) la syntaxe de .ebuild.x et .metadata.x , donc à priori, soit tu resync, soit tu te refais un q -r, et ça devrait être bon.

(j'ai changé la syntaxe pour pouvoir l'exploiter avec qatom.)

Sinon, pour le cache, ça respècte normalement paludis:

si la clée cache est définie, alors on l'utilise, sinon, elle est mise à ${location}/metadata/cache, qui, si il existe est utilisé, sinon, on regarde la valeur de write_cache, si si elle est remplie on l'utilise, et enfin, sinon le cache est mis à /var/empty (y'en a pas)

ouf!  :Laughing: 

je crois avoir oublié de donner le lien dans mon post précédent:

portage-utils-20070107.ebuild

voili-voilou, merci d'avoir fait joujou  :Smile: 

EDIT: Juste une petite note, à propos des caches, pour l'instant, la clée write_cache de chaque repo, permet d'écrire, (comme son nom l'indique...) toute fois, si un package à été écrit sur le cache, et qu'il est enlevé de l'arbre,il reste présent dans le cache, apparemment(dixit #paludis), la gestion du cache (de paludis) devrait d'améliorer, donc je ne vais pas me lancer dans autre chose.. je vais attendre patiemment.

De même le cache n'est écrit que petit bout par petit bout, ce qui fait, que vous 'êtes pas sur d'avoir tous vos packages dedans, encore une fois, en attendant que la gestion s'améliore, vous pouvez faire joujou avec ça

```
paludis -q $(qsearch -CNa -o OverlayAvecWriteCache | tr '\n' ' ')
```

ça n'enlèvera rien, mais ça fera le cache déjà de tous les pkg de cet overlay  :Smile: 

----------

## Bapt

q -r ne fonctionnait pas, mais un nouveau paludis -s ok

Pour générer le cache je me suis fait un hook avec ta command paludis -q  :Smile: 

Merci pour tout c'est impeccable  :Smile: 

----------

## truc

 *Bapt wrote:*   

> q -r ne fonctionnait pas, mais un nouveau paludis -s ok

 

Ca vient du fait que par défaut si le fichier .ebuild.x existe, alors il ne se passe rien, j'ai envie d'enlever ce comportement car je ne vois pas trop l'utilité :/ (car normalement lr rsync va le supprimer, c'est pour ça que q -r marche après un --sync)

 *Quote:*   

> Pour générer le cache je me suis fait un hook avec ta command paludis -q 

 

J'avais pensé à ça, mais je ne savais pas trop comment m'y prendre pour faire un truc général sans trop se casser la tête, tu t'y es pris comment? tu as mis en dur les overlay que tu devais chercher (avec write_cache) ou tu le recherche dynamiquement? (et dans ce cas je suis interessé de savoir comme tu fais.. par ce que j'vais pas me faire un paludis -q bblabla::gentoo pour un cache déjà fait etc.. )  :Question: 

 *Quote:*   

> Merci pour tout c'est impeccable 

 

 :Very Happy:  au plaisir  :Smile:  merci.

EDIT: Bon alors y'a toujours pas de concours de celui qui a passé le plus de temps à compiler des fps par exemple? (qlop -tv games-fps/)  :Laughing: 

----------

## Bapt

En dur comme un gros cochon  :Smile: 

----------

## truc

 :Embarassed:  rhoo  :Razz: 

Bon, sinon,j'ai oublié de le dire mais, j'ai fait les modifs pour que portage-utils puisse fonctionner sans l'arbre gentoo (donc de manière indépendante), il ne reste plus qu'a trouver une place pour les fichier .ebuild.x (/var/paludis/repositories/.ebuild.x ? ) et .metadata.x (/var/cache/paludis/metadata/.metadata.x ?)

C'est fichier ne seront alors plus effacé automatiquement à chaque sync, d'où l'utilité d'enlever le comportement dont on parlait à l'instant (q -r sans effet si le fichier existe déjà).

Voili-voilou, qu'en pensez vous? emplacement OK? on pourrait également vouloir faire ce changement pour les portagiens, mais alors pour les emplacements, ce coup ci j'en ai aucune idée :/

----------

## Bapt

Pour moi /var/cache/paludis/.ebuild.x et /var/cache/paludis/.metadata.x

Car les deux me semblent être une sorte de cache, non ? maintenant les répertoire que tu proposes me semble très bien aussi  :Smile: 

----------

## truc

dans ton hook, après avoir écri le cache, il faut que tu regenère le cache avec q -m au fait, sinon, c'est inutile, (remarque pas tant que fichier .metadata.x est effacé automatiquement à chaque sync  :Wink: 

----------

## truc

salutt, bon voici encore une maj de portage-utils, elle améliorecertaines choses, par rapport à ce que j'vous avais dit à la dernière maj, il y a,

=> L'indépendance totale de portage-utils par rapport à l'arbre gentoo 

=> Les fichiers .ebuild.x et .metadata.x se trouve désormais là où l'avait suggéré bapt, c'est à dire dans /var/cache/paludis/ et /var/cache/paludis/metadata

je crois que c'est bien tout  :Smile: 

si vous voulez essayer, zxy  devrait bientôt l'integrer à son overlay pour paludis.. sinon voici l'ebuild : portage-utils-20070115 

EDIT: c'est bon, il est integré, donc si vous voulez, faites vous votre petit fichier de conf et mettez cette ligne pour la clée sync

```
sync = rsync://drzile.dyndns.org/paludis-extras
```

----------

## truc

 *Bapt wrote:*   

> Pour générer le cache je me suis fait un hook avec ta command paludis -q 

 

tu vas pouvoir, si tu le veux hein  :Wink:  , enlever ce hook, en voici un tout beau tout propre:

J'me sers de ça pour introduire le changelog de la dernière version en date...

 *changelog 20070118 wrote:*   

> * Quand vous ne cherchez dans la description mais dans son nom, vous pouvez désormais chercher par ctégories, nom et même des combinaisons d'overlay, il faut juste vous lacher grace au regexp:)
> 
> (remarque au passage: les regexp fonctionnent aussi pour une recherche dans les DESCRIPTIONs).
> 
> par exemple:
> ...

 

Si vous activé le flag 'purge', le hook de portage-utils fera donc par défaut un q --purge, à la place de q --metadata

Vous pouvez trouver cette dernière version dans l'overlay paludis-extras ( sync = rsync://drzile.dyndns.org/paludis-extras ) ou alors l'ebuild doit encore se balader quelque part ou je mettais ceux d'avant  :Wink: 

voili-voilou

EDIT: juste une note pour ceux qui ont suivi un peu la chose, vous pouviez faire qsearch -ao overlay, et maintenant vous pouvez également faire qsearch ::overlay. Mais... se servir de la première sytaxe accélère sensiblement les chose, par contre il requière de connaitre le nom exact de l'overlay, par contre la deuxième forme vous permet de faire des trucs du style qsearch ::[^gentoo] pour lister tout ce que vous avez en plus de l'arbre 'gentoo' officiel.

EDIT2: et pour tous ceux qui se demandent au final à quoi sert le cache? et bien en fait lorsque vous faites des recherches  sur la DESDRIPTION, rechercher avec le cache est plus fiable que de rechercher sans le cache, c'est tout:) (car certains ébuild sont fortement basé sur des eclass et n'ont même pas de DESCRIPTION dedans..  :Smile: 

----------

## CryoGen

 :Cool:  Merci pour ton boulot !

----------

## truc

 *CryoGen wrote:*   

>  Merci pour ton boulot !

 

Mais de rien  :Very Happy: 

C'est tout joli maintenant après le --sync  :Wink: 

Cela dit, on a vu un comportement non désiré: si l'utilisateur a voulu exclure une catégorie d'un de ses overlays, en se servant du fichier categories (il l'a juste enlevé de ce fichier) alors l'étape de l'écriture du cache ne se passait pas bien, car, vu que portage-utils ne se sert pas de se fichier il allait quand même visiter cette catégorie, mais paludis lui ne la voyait pas. 

Donc voila, j'suis donc en train de rajouter le support de ce fichier si il existe pour eviter ce genre de désagrément, et donner ainsi plus de liberté :Smile:  Voili-voilou, désolé pour les maj incessantes  :Sad:  après ça devrait être bon.

----------

## truc

okay, finalement, portage-utils considère également le fichier overlay/profiles/categories, (si il existe, sinon, portage scan tous l'overlay à la dure  :Laughing:  ). Lors de la regénération des caches portage-utils va donc se limiter aux catégories indiquées

Finalement, pour l'option purge j'ai aussi rajouté un ptit truc: si un cache d'ebuild est supprimer et qu'il était seul dans sa catégorie, alors la catégorie est également supprimée , voila c'est tout.

A vos --sync  :Wink: 

(apparemment zxy le rajoute à l'instant même du moment présent.)

----------

## truc

encore une petit changement:

Suite à la demande de bapt => Ticket 8 : default configuration for repositories, paludis sait gérer maintenant un fichier de configuration par défaut, pour les overlays.

Dans ce fichier vous pourriez avoir envie d'y mettre les distdir, eclassdirs, profiles, write_cache, format  par exemple, sachant que la clée définie dans le fichier de conf d'un overlay (si vous la définissez bien sûr..)  écrase la valeur par défaut.

Attention, car vous ne pouvez pas mettre des choses comme ça names_cache= ${location}/.cache/names, car ${location} n'est définie que dans le fichier de conf de l'overlay, et donc à la lecture de confdir/repository_defaults.conf, cette variable ne vaudra rien du tout... 

Voili-voilou, donc comme c'est une changement valant son pesant de cacahuetes, il fallait que portage-utils, puisse s'en sortir avec ça, donc voila, c'est bon, portage-utils peut récupérer dans ce fichier (s'il existe) les clées cache, write_cache,  et format. 

Voili-voilou, n'hésitez pas à dire si vous trouvez quelque chose de bizarre..

----------

## titoucha

J'ai voulu faire la mise à jour de mon système et j'ai l'erreur suivante 

```
Query error:

  * In program /usr/bin/paludis -ip paludis-hooks:

  * When performing install action from command line:

  * When executing install task:

  * When adding PackageDepAtom 'app-paludis/paludis-hooks':

  * All versions of 'app-paludis/paludis-hooks' are masked. Candidates are:

    * app-paludis/paludis-hooks-0.2.0::paludis-extras: Masked by EAPI ( UNKNOWN ) (probably a broken ebuild)

```

 je ne comprend pas trop ce EAPI.

----------

## Bapt

Il y a eu du mise à jour sur l'overlay en question. il faut que tu rajoute dans le fichier de conf un eclassdir : moncheminverslerepopaludis-extras/eclass

Je pense que ton erreur est là.

----------

## titoucha

C'est pas ça j'ai encore vérifié le chemin de mon eclass et c'est ok, je ne vois pas trop ce matin tout fonctionnait et je n'ai rien touché entre temps.

----------

## truc

si tu ouvres l'ebuild en question, y'a deux espaces en fin de ligne en trop, enfin, un espace en trop sur deux lignes, faut les enlever :/

en tout cas j'ai transmis:/ ça devrait être corrigé au plus tôt..

----------

## zxy

 *titoucha wrote:*   

> J'ai voulu faire la mise à jour de mon système et j'ai l'erreur suivante 
> 
> ```
> Query error:
> 
> ...

 

Sorry, i don't speak french, but I maintain the overlay. Today some changes were introduced, namely eclass folder with new paludis-hooks eclass. (that introduced changes in all of the paludis-hooks ebuilds) 

I just created metadata/news folder in the overlay  where the news about the recent (and future) updates will reside. They are now in English language, but hopefully they will be translated in French and other languages, too.

Sorry for the trouble, but I think no more big overlay changes will happen in the near future. 

To solve your error just add ${location}/eclass to the eclassdirs line in paludis-extras.conf. 

```
eclassdirs = ${ROOT}/usr/portage/eclass ${location}/eclass
```

Zxy

----------

## titoucha

Merci à vous deux en combinant vos réponses j'ai pu résoudre ce problème.

----------

## truc

salut! rho, j'vous ai même pas fait une petite description de ce qui a changé avec la dernière version... donc j'en profite pour le refaire avec celle ci:) (20070215 elle devrait arriver d'ici peu..)

=> ajout d'un nouveau niveau de "verbosité" pour qlop, du style vous avez des packages que vous vous apprettez à installer, disons par exemple ces deux packages  x11-proto/scrnsaverproto-1.1.0::gentoo et  x11-terms/rxvt-unicode-8.1::gentoo 

Donc vous avez envie de savoir combien de temps ça va vous prendre, vous lancez donc

```
qlop -tH x11-proto/scrnsaverproto-1.1.0::gentoo x11-terms/rxvt-unicode-8.2::gentoo -v

x11-proto/scrnsaverproto-1.1.0::gentoo : 5 seconds average for 1 merges

Total estimated time: 5 seconds

```

donc ouais, comme vous pouvez le voir il n'a pris en compte que le premier package car le package 

x11-terms/rxvt-unicode-8.2::gentoo n'a encore jamais été installé, donc il n'y a pas de trace de ce package dans paludis.log, mais tout n'est pas perdu!! j'en arrive au deuxième ajout pour cette nouvelle version de portage-utils:

=> L'ajout d'une nouvelle option (toujours pour qlop) : l'option --estimate (ou -e) qui ne va pas prendre en compte la version(ni l'overlay)  des packages lorsque qlop va chercher dans le log, ce qui nous donne:

```
qlop -tH x11-proto/scrnsaverproto-1.1.0::gentoo x11-terms/rxvt-unicode-8.2::gentoo -ve

x11-proto/scrnsaverproto : 5 seconds average for 1 merges

x11-terms/rxvt-unicode : 48 seconds average for 2 merges

Total estimated time: 53 seconds
```

(et si vous voulez voir quelles versions ont déjà été compilées, ajoutez simplement l'option -g (--gauge) à la liste d'option..)

jusque là vous devez vous dire, mouais, autant ne pas mettre la version dès le départ et c'est reglé, oui en effet, mais imaginez que vous êtes en train de compiler un packet:

un petit qlop --current vous donne le package en question

```
qlop -c

 * sys-devel/gcc-4.1.2.ebuild::gentoo

     started: Wed Feb 14 23:24:45 2007

     elapsed: 2 minutes, 15 seconds
```

Puis par un rapide copié&collé, vous faites

```
 qlop -t sys-devel/gcc-4.1.2.ebuild::gentoo -eH

sys-devel/gcc: 55 minutes, 37 seconds average for 2 merges
```

(vous avez rajouté l'option -e car vous en aviez envie, ou parce que vous saviez que vous n'avez encore jamais installé cette version..

mais ça n'est pas le seul cas possible... Vous vous appretez à réinstaller votre monde... (=> --dl-reinstall always), vous avez envie de savoir environ combien de temps ça va vous prendre, 

2 manières de le faire:

=> Se dire, qu'en gros cela revient à réinstaller les packages qui sont actuallement installés:

```
app-crypt/hashalot : not found

app-misc/ca-certificates : not found

dev-cpp/libebt : not found

dev-cpp/libwrapiter : not found

dev-lang/perl : not found

dev-libs/gmp : not found

dev-libs/libassuan : not found

dev-libs/libksba : not found

dev-libs/pth : not found

dev-python/python-fchksum : not found

dev-util/pkgconfig : not found

net-mail/mailbase : not found

sys-apps/diffutils : not found

sys-apps/hotplug-base : not found

sys-apps/less : not found

sys-apps/which : not found

sys-devel/libperl : not found

sys-devel/libtool : not found

sys-libs/pwdb : not found

virtual/libiconv : not found

virtual/libintl : not found

Total estimated time: 17 hours, 29 minutes, 41 seconds
```

etonnant non pour un tail -n 1? bah en fait, c'est tout simplement que je n'ai encore jamais fait de réinstall complète du système, donc ce sont des packages installé avec le stage3... et donc l'installation de ces packages n'apparait pas dans les log! (ça pourrait également être des packages installés avec emerge, mais ça n'est pas le cas ici.)

(et pour ceux qui se poserait encore la question: si ils apparaissent malgré le tail, c'est tout simplement parce que ces erreurs sont renvoyés sur stderr, donc à moins de jouer avec les redirections, tail ne s'en occupe pas. si toutes fois ça vous gène vous pouvez toujours ajouter --quiet aux options de qlop...)

(remarquez que vous pouvez ajouter le niveau de verbosité de qlist de 2 ( -vv ) pour prendre en compte,en plus, la version et l'overlay du package en question.. etc.. ça peut vous permettre d'avoir une estimation plus ou moins précise...

=> L'autre méthode se sert de paludis qui lui va vérifer que toutes les dépendances soient satisfaites etc... attention, c'est moins joli..

```
qlop -tvH $(paludis -ip --dl-reinstall always --log-level silent world | sed -e '/^\* .*::/!d' -e 's;^..\([^/]*/[^:]*::[^ ]* \).*;\1;') -e | tail -n 1
```

(j'ajoute l'option -e car, après tout, on a ainsi une moyenne, et à mon avis c'est plus précis.)

donc voila c'est à peu près tout si je n'm'abuse...

EDIT: et pour ceux que ça amuse de savoir combien de temps leur pc à passer à installer des trucs(avec paludis):

```
qlop -tvvH ::

 : 2 minutes, 14 seconds average for 1108 merges, for a total time of 1 day, 17 hours, 19 minutes, 54 seconds
```

et oui, mon install n'est pas très vielle, (toujorus pas fait de -e world d'ailleurs, comme je le disais plus haut...)

----------

## Jeremy_Z

Sympa, tu pourrais ajouter la date du premier event (depuis ...) et peut etre le pourcentage de temps passé à installer des packages  :Very Happy: 

Peut etre aussi un raccourci : 

qlop --current -evht pour avoir l'estimation du package courant.

Et une option --remaining pour les packages restants, combinable avec -evth.

La ca serait parfait  :Smile: 

----------

## CryoGen

C'est vrai qu'une option qui nous balance les packages restants à installer serait sympa ^_^

----------

## truc

Salut j'passe là en coupe vent, ahhh tiens des messages!  :Very Happy: 

 *Jeremy_Z wrote:*   

> Sympa, tu pourrais ajouter la date du premier event (depuis ...)

 Du premier packet que tu as (des)installé?  *Quote:*   

> et peut etre le pourcentage de temps passé à installer des packages 

 le pourcentage de temps en fonction de quoi? j'te suis pas? depuis le moment où tu a commencé à te servir de paludis jusqu'à maintenant en  comptant aussi le temps ou ton pc est éteint etc?  :Confused:  j'suis pas sur de te suivre là?

 *Quote:*   

> Peut etre aussi un raccourci : 
> 
> qlop --current -evht pour avoir l'estimation du package courant.

 Cette option pourrait effectivement être sympa, j'me pencherai sur la question à mon vrai retour:)

 *Quote:*   

> Et une option --remaining pour les packages restants, combinable avec -evth.
> 
> La ca serait parfait 

  *CryoGen wrote:*   

> C'est vrai qu'une option qui nous balance les packages restants à installer serait sympa ^_^

 

Pour ça, je suis d'accord que ça serait sympa, mais... il faudrait communiquer avec le "process de paludis" , et là comme ça, je ne vois pas trop :/ (quand vous faites un paludis -ia world par exemple, il n'y a pas du tout la liste des packets allant être installé dans les commande, donc c'est un peu ça la galère, mais j'oublie peut-être quelque chose d'évident, n'hésitez pas à me mettre sur le droit chemin  :Smile: 

----------

## Jeremy_Z

Salut,

Oui, "qlop -tvvH ::" done le temps total mais pas depuis quelle date (la premiere prise en compte pour le calcul, je pense la premiere install avec paludis)

Apres en pourcentage, ca serait today - 'cette date' / temps

Pour les packages en cours je ne sais pas, quand j'avais fait une progresse bar pour portage j'utilisais juste le nombre de packages restant. Peut etre est il possible de sortir la liste des package par un hook paludis ?

Par exemple install_all_pre ?

Je check si j'ai un peu de temps au boulot.

PS: rapidement j'ai fait un echo $TARGETS dans le hook, mais ca retourne "world", donc pas super utile. Sinon il faudrait voir directement avec les dev de paludis si c'est possible.

----------

## truc

 *Jeremy_Z wrote:*   

> Sympa, tu pourrais ajouter la date du premier event (depuis ...) et peut etre le pourcentage de temps passé à installer des packages 
> 
> Peut etre aussi un raccourci : 
> 
> qlop --current -evht pour avoir l'estimation du package courant.
> ...

 

Bon je ne sais pas si vous avez vu, mais désormais, lorsque vous faites qlop --currentça vous affichera en plus de ce que vous aviez déjà une ligne avg build time (nan, j'ai pas trouvé mieu comme phrase, mais si vous avez des propositions  :Razz:  ) qui tient pour average build time , pour ceux qui se posaient la question. 

J'ai regardé également pour obtenir la liste des paquets pendant une install, et bah, pour l'instant, ça ne semble pas encore possible, toutefois le grand manitou  de paludis, laissait sous entendre qu'il serait assez facile de créer une nouvelle "étape" pour les hooks, une étape se situant juste après que paludis aie "calculé" la liste des packages...  Mais bon, tout ça me laisse perplexe moua, donc faut que je trac  tout ça  :Wink: 

Si toute fois vous voyez ce qu'il faut faire n'hésitez pas à le faire, et à proposer le patch directement dans trac  :Smile: 

----------

## truc

salut, bon finalement, j'ai demandé sur le trac de paludis, un moyen d'obtenir la liste, mais, pour l'instant, ça ne tente guère les devs, (bon le dernier commentaire ne vaut rien, on s'est expliqué un peu plus après sur #paludis, et il semblerait que ce qu'on voudrait faire soit trop bizarre.. 

DOnc à moins que certains d'entre vous arrive* soit à convaincre que c'est pas si bizarre que ça

* soit à patcher eux même paludis, 

Et bien ça m'étonnerait que cette fonction (de prévoir le temps jusqu'à la fin de toute l'installation) se mette en place  :Sad: 

Vous pouvez toujours vous consoler en faisait un qlop -teHv liste_des_paquets_à_installer avant de commencer, puis de vous faire un petit compteur   :Twisted Evil: 

Enfin bon ,c'est pas grave non plus quoi... :Smile: 

Et pour ceux qui ont remarqué nous en somes à la vesion 20070318, cette version intègre (et modifie pour le support des overlays) les patchs de TGL des app-portage/portage-utils - add a -E/--eclass option to qgrep et app-portage/portage-utils - add a -s/--skip-comments option to qgrep

voili voilou

plus-plus

----------

## CryoGen

Comme d'habitude, merci pour ton boulot ^_^

----------

## truc

Salut, TGL à bombardé deux autres patches pour qgrep, un pour mettre en évidence l'expression recherchée (en rouge, comme quand on fait un grep normal), et un autre patch pour grep'er dans les ebuilds, des packets installés, se trouvant donc dans la VDB, c'est bien sympatique pour voir par exemple la tronche d'un ebuild installé (qgrep -Je . fvwm, par défaut si je ne précise pas fvwm, ça va scanner tous les ebuilds installé).

Bon sinon, j'ai refait mumuse avec qlop, voici maintenant deux nouvelles fonctionnalités* l'option --pipe (-p), vous vous doutez surement de son utilisation, car c'est à peu près là même chose que pour eix et genlop, mais forcément c'est mieu..  :Wink: 

```
x11-misc/beryl-settings-bindings : 36 seconds average for 1 merges

x11-misc/beryl-settings : 15 seconds average for 2 merges

x11-apps/xlsclients : 11 seconds average for 1 merges

x11-apps/xvinfo : 10 seconds average for 1 merges

x11-misc/beryl-manager : 17 seconds average for 2 merges

x11-wm/beryl : 5 seconds average for 2 merges

Total estimated time: 94 seconds (6 packages)
```

C'est plus facile que de faire les "one-liners" que j'avais donné avant   :Twisted Evil:  (vous pouvez estimer le temps pour une réinstall complète beaucoup plus simplement par exemple... paludis -ip world --dl-reinstall always --log-level silent | qlop -p ajoutez un niveau de verbosité et vous saurez d'un rapide coup d'oeil combien de package n'ont pas été trouvé dans les logs. 

```
...

Total estimated time: 17 hours, 44 minutes, 56 seconds (588 packages)

Missing time info for 20 packages
```

* l'autre amélioration concerne toujours qlop, plus précisément l'option --current, j'vous avais dit que j'avais demandé à avoir certaines informations disponible pour les hooks, mais on m'avait répondu non.. Il suffït donc que quelqu'un formule la demande différemment, et ce fut bon!  :Twisted Evil: 

Il est désormais possible d'estimer le temps restant avant la fin de toute une installe, et ce à chaque instant avec qlop! 

Vous l'aurez compris, il y a donc un hook en plus dans l'histoire, mais rien ne vous oblige de l'utiliser, il ne fait quasiment rien si ce n'est générer un fichier avec les packets restant à installer, voici rapidement ce que nous avons maintenant:

```
 * x11-misc/beryl-settings-bindings-0.2.1.ebuild::gentoo

     started: Thu Apr  5 11:59:25 2007

     elapsed: 2 seconds

     avg build time: 36 seconds
```

En un peu plus verbeu on à:

```
 * x11-misc/beryl-settings-bindings-0.2.1.ebuild::gentoo

     started: Thu Apr  5 11:59:25 2007

     elapsed: 4 seconds

     avg build time: 36 seconds

     estimated time left: 1 minute, 29 seconds (6 packages)
```

et si vous voulez voir un peu où vous en êtes vous pouvez même encore rajouter un niveau

```
 * x11-misc/beryl-settings-bindings-0.2.1.ebuild::gentoo

     started: Thu Apr  5 11:59:25 2007

     elapsed: 5 seconds

     avg build time: 36 seconds

     * x11-misc/beryl-settings-bindings-0.2.1::gentoo

     * x11-misc/beryl-settings-0.2.1::gentoo

     * x11-apps/xlsclients-1.0.1::gentoo

     * x11-apps/xvinfo-1.0.1::gentoo

     * x11-misc/beryl-manager-0.2.1::gentoo

     * x11-wm/beryl-0.2.1::gentoo

     estimated time left: 1 minute, 28 seconds (6 packages)
```

Voili-voilou, ça m'plait bien tout ça  :Smile: 

Mouais en disant ça à propos de qgrep j'me dis qu'un mini résumé s'impose:

Vous pouvez toujours restreindre vos recherches à un overlay avec l'option --overlay, mais c'est pas encore là ou je voulais en venir...

qgrep expr  => cherche l' expr dans tous les ebuilds de chaque overlay (exprpeut-être uen expression regulière (-e) ou même régulière étendue (-x))

qgrep expr pkg[-version]

qgrep expr cat/

qgrep expr ::overlay (pareil que qgrep expr -o overlay mais en moins efficace...)

ou une combinaison 

ex: qgrep expr cat/pkg[-version]

Vous permet de grep dans, respectivement les ebuild, des packets de nom pkg, dans la catégorie cat, dans l'overlay overlay, vous pouvez les combiner, ajouter la version etc... vous voyez le truc quoi?  :Smile: 

Vous pouvez en préciser plusieurs fois en même temps ex: qgrep  cherche_moi cat/pk1 pk2 pk3-2.3-r3 catB/::overlay1 ...

avec l'option --installed (-J), vous grep'ez les ebuild de la VDB

avec l'option --eclass (-E), vous grep'ez dans les eclasses (vous pouvez également restreindre les recherches avec les methode ci dessus)

bref...

----------

## CryoGen

 :Very Happy: 

ca ne rigole plus là   :Cool: 

bravo

----------

## truc

 *CryoGen wrote:*   

> 
> 
> ca ne rigole plus là  
> 
> bravo

 

merci:) Bah j'te dédicasse cette version!   :Laughing:  mon fidèle soutien/supporter!   :Razz: 

EDIT: mais en plus c'est vrai!

 *CryoGen wrote:*   

> C'est vrai qu'une option qui nous balance les packages restants à installer serait sympa ^_^

 

Bah voila!  :Wink: 

EDIT: En fait j'ai oublié de préciser que la regénération du cache n'est plus faite par défaut, ceci devrait avoir pour principal effef l'arret des pleurs et gémissements de sa majesté concepteur de paludis...  :Evil or Very Mad:  (mais rien ne vous empèche de la réactiver dans /etc/paludis/hooks/config/q-reinitialize.conf )

----------

## truc

youhou, j'viens juste de m'apercevoir qu'en fait, il vous faut attendre la prochaine version de paludis pour pouvoir profiter de la fonction --current revisitée... j'étais en scm, juste pour bidouiller avec ça, et hier, j'suis repassé en 0.22.2, et bam, le choc, ça ne marchait plus.. j'avais totalement zappé.

Donc voila, ne vous alarmez pas, il faut juste attendre encore un peu! mais curieusement c'est plus long que d'habitude..  :Razz: 

Voili-voilou, désolé de bump'er rien que pour ça..

----------

## truc

Iop tout le monde, ce thread [portage] Lister tous les ebuilds installés [résolu] m'a fait pensé qu'il y a un truc à modifier dans le hook pour qlop,. je l'ai déjà rappellé plusieurs fois à zxy, mais il semble trop occupé.. donc bref

dans le hook de qlop, (très probablement /usr/share/paludis/hooks/common/q-qlop.hook) dans la fonction hook_run_install_pre, il faut remplacer toute la ligne echo $RESUME_COMMAND par celle ci:

 *Quote:*   

> hook_run_install_pre() {
> 
>     find_pgid
> 
> echo $RESUME_COMMAND | sed "s/'//g; s/ /\n/g" | sed -n '/^package;=.*;P$/{ s/.*=// ; s/;.*//p}' > /var/tmp/${pgid}-paludis-resume
> ...

 

Ainsi, en plus du basique qlop -c, vous pourrez de nouveau profiter d'un qlop -cv et même d'un qlop -cvv.

C'est tout, c'est pas important, mais ça fait parti des gestes qui sauvent, "donc... voila"  :Wink: 

----------

