# [Utilitaire] Déterminer le temps de compilation (résolu)

## razer

Bonjour,

Qqu'un aurait il l'amabilité de me rappeler le nom de l'utilitaire permettant d'afficher le temps de compilation d'un programme ?Last edited by razer on Thu Jul 13, 2006 9:51 am; edited 1 time in total

----------

## netfab

Salut,

```

# eix genlop

* app-portage/genlop

     Available versions:  0.30.2 0.30.3 0.30.5

     Installed:           0.30.5

     Homepage:            http://pollycoke.org/genlop.html

     Description:         A nice emerge.log parser

# genlop -t mozilla-firefox

     Mon Jun  5 19:48:35 2006 >>> www-client/mozilla-firefox-1.5.0.4

       merge time: 1 hour, 35 seconds.

```

----------

## Il turisto

Mais cela c'est pour après avoir compilé mozilla-firefox.

Je pense que lu voulait pouvoir prévoir le temps de compilation non ?

----------

## -KuRGaN-

En effet:

 *Quote:*   

> genlop is a small Perl script which shows you, in a nice colored output, useful information about your previously-emerged packages by looking into /var/log/emerge.log. genlop is for Gentoo/portage users only.

 

Mais il n'y avais pas un projet de ce genre avec une base de données regroupant les différents temps de compilation suivant l'architecture et les Useflags utilisés??

----------

## Il turisto

il me semble avoir vu que le gui over portage (dont je ne me souviens pas du nom) donnait les temps de compilation estimé, ...

----------

## razer

 *Il turisto wrote:*   

> Mais cela c'est pour après avoir compilé mozilla-firefox.
> 
> Je pense que lu voulait pouvoir prévoir le temps de compilation non ?

 

Non, Netlab a visé juste, c'est exactement le programme que je recherchais

Merci beaucoup

----------

## Il turisto

Bon alors je détourne ton post (si cela ne te dérange pas) et demande :

est il possible de prévoir le temps de compilation???

----------

## razer

 *Il turisto wrote:*   

> Bon alors je détourne ton post (si cela ne te dérange pas) et demande :
> 
> est il possible de prévoir le temps de compilation???

 

Sauf en faisant appel à Paco Rabane, techniquement je ne vois pas comment c'est possible, à moins de construire une base de données en fonction de la puissance des machines sur les temps moyens de compilation des programmes.

Par contre, genlop propose l'historique des compilations précédentes, donc sur un paquet ayant déjà été compilé on peut quand même avoir une idée

----------

## Babali

A savoir que kuroo te donne le temps restant, et te fait des belles barres de progressions  :Smile: 

----------

## UB|K

 *razer wrote:*   

> à moins de construire une base de données en fonction de la puissance des machines sur les temps moyens de compilation des programmes.

 

ça existait ce truc: un petit utilitaire du nom de basc mais le gars responsable du projet s'est fâché avec des devs gentoo et a suicidé son projet... le site est toujours là (www.gentoo-stats.org) mais ça n'a plus grand chose à voir avec ce qui ce faisait avant (ouaip, c'était mieux avant).

----------

## Il turisto

 *Babali wrote:*   

> A savoir que kuroo te donne le temps restant, et te fait des belles barres de progressions 

 

C'est de ce programme la que je parlais ...

Peut être devrions nous refaire un projet comme basc ...

L'idée me tente mais je manque de temps en ce moment.

----------

## terminou

ce serait super pratique de savoir combien de temps environ cela va prendre de compiler. surtout quand le pc est dans la chambre. parfois c'est bon de savoir si on a le temps de lancer une dernier compile avant de se coucher (si le bruit du PC dérange il faut bie nl'eteindre)   :Very Happy: 

----------

## Il turisto

Je vais y réfléchir à ce projet. Si j'arrive à trouver du temps je me lance.

Dois je savoir qqch avant de me lancer dans un tel projet?

----------

## kaworu

 *Il turisto wrote:*   

> Je vais y réfléchir à ce projet. Si j'arrive à trouver du temps je me lance.
> 
> Dois je savoir qqch avant de me lancer dans un tel projet?

 

Il faudrai que tu sois capable d'analyser des 

```

genlop -tl

```

comme ça chaque utilisateur te donne son [b]emerge --info && genlop -lt [/code] et à toi de gerer ^____^

----------

## Il turisto

Ouais mais ca c pas trop dur.

Je me demandais comment procéder ...

Est ce que la version du kernel influe sur la vitesse de compilation?

Est ce que je devrais faire un script côté client qui récolte les infos et me les envoie? Si oui de quelle façon devrait je les envoyer? Dans une url (genre : wget www.lesite.org/recolt.php?info....), par ftp? scp ?

Bref pour l'envoi des envois si vous pouviez m'aiguiller ce serait bien. Pour le reste je me débrouille.

Mais pour être sur :

ce qui influe le temps de compilation/catégorie :

CBUILD

CFLAG

CHOST

CXXFLAGS

USE

Dans emerge --info il ne me semble pas qu'il y aie le cpu. Il me faudrais donc aussi le résultat d'un cat /proc/cpuinfo.

Dois je prendre en comple le MAKEOPTS?

Ou puis je me procurer (ou comment puis je construire) une liste complète des use des packages. Car je dois pouvoir faire le rapport entre la varibale USE de la personne et les USE pris en compte par les paquets.

Devrais-je tenir compte des use explicite des dévellopeurs? Si oui cela implique de parser tout les .ebuild de portage. D'un autre côté cela me permettrais de purger ma base des packages obsolètes.

----------

## -KuRGaN-

Peut-être peux tu commencer par contacter le developpeur de basc pour avoir déja quelques astuces pour commencer.

----------

## Temet

Moi je suis partant pour balancer mes infos de compils.

Je serai pas la Sept/Oct/Nov car en Italie, sans doute suivi d'un déménagement mais après si je peux contribuer à remplir la base.

Encore que je compte faire du distcc entre le laptop et le desktop ... arf, tu feras un thread ou tu expliques ce que tu veux pis je verrai si je peux aider  :Wink: 

----------

## Il turisto

Je lui ai écrit mais si le mec à arrété son projet suite à une dispute il y a peu de chance qu'il veuille m'aider.

Quoi qu'il en soit je suis motivé pour faire cela mais je ne sais pas ou je vais trouver le temps.

Sinon pour mes réflexions d'au dessus vous en pensez quoi?

----------

## Temet

Ben je rajouterais le CCACHE  :Wink: 

----------

## Il turisto

hmmm comment se présente le ccache. Perso je en 'lai jamais utilisé et chez moi j'ai :

dev-util/ccache:     [Not Present]

dans mon emerge --info.

Mais si mes souvenirs sont bons le ccache n'aide que lors de recompilation. ou alors lors de mise a jours de style rXX.

----------

## -KuRGaN-

Moi étant une bille en développement, je veux bien contribuer en tant que béta testeur.

Et si il te faut une machine de test à distance un peu différente de la tienne, je peux te fournir un serveur virtuel avec un compte root si ça t'intéresse.

Voilà ma maigre pierre à l'édifice   :Crying or Very sad: 

----------

## geekounet

Je dirai que c'est pas trop possible de faire des stats correctes, parce que ça dépend de l'activité de la machine pendant que ça compile. En ce qui me concerne, je surfe souvent pendant que ça compile (et firefox ça consomme), ça m'arrive de jouer ou de matter un film, de plus ça swap pas mal (déjà que ma ram est parfois saturée sans pour autant compiler en même temps), et aussi l'activité du disque varie beaucoup selon ce que je fais (et c'est un HDD de portable, donc lent). Mes temps de compilations peuvent parfois doubler entre quand ya rien qui tourne et quand je l'utilise.

Donc je ne pense pas qu'on puisse produire des stats utilisables.

----------

## -KuRGaN-

Ben alors faudrait que le soft envoie les infos seulement lorsque il n'y a pas d'autre processes qui bouffent enormément à coté, genre fixé une limite suivant le pourcentage du cpu.

----------

## kaworu

autrement j'ai une idée simple :

on peut utiliser le SBU

l'idée c'est de calculer le temps de compil des ses paquets en SBU, et non pas en temps.

après le résultat est une fourchette de SBU par architecture.

De toute façon on aura jamais un résultat hyper précis (trop de paramètres rentrent en compte dans le calcul), mais avec beaucoups de résultats comme base de donnée ça peut donner un résultat raisonnable, donc on classe comme ça :

architecture/paquet : résultat en SBU

L'utilisateur n'as qu'a comparer avec son temps de build pour binutils (avec un script simple)

qu'en pensez vous?

EDIT : Il faudrait biensur que CCACHE ne soit pas dans le coups  :Wink: 

----------

## Il turisto

sauf que les infos sont prises dans le emerge.log et que la on ne sais pas si le mec utilise son cpu ou pas.

Mais cela n'est pas grave je pense. Car si on a plusieus fois les même infos pour le même pacckage avec la même machine on peut en déduire une moyenne qui approxime l'histoire. Le but étant d'avoir une idée de la chose et pas un chiffre précis.

----------

## Temet

Pour le CCACHE, m'en suis encore jamais servi! J'ai vu passer ça sur un topic et ça fait partie des trucs à expérimenter à mon retour en France. T'as une tite page dans le wiki francais  :Wink: 

Sinon, pas con le truc des SBU.

Après si un mec arrive à faire un script qui peut évaluer une durée à partir de la config et des SBUs, ce serait encore mieux  :Wink: 

----------

## Il turisto

Peux tu détailler plus le SBU stp?

Voici la réponse du gars de basc :

```

I'm really sorry and maybe you want to call me an a**hole, but I'm planning

to revive the whole gentoo-project basc with its buildtime database on

linux-stats.org and so I really don't see the sense in creating a new

project which does the same thing.

Sorry, I can't help you with this.

> Thanks a lot.

dma147

```

----------

## kaworu

Pour le SBU y'a un lien dans mon 1er post.

en gros l'idée c'est de dire : le temps pour compiler le paquet sys-devel/binutils c'est 1 SBU.

pour moi 1 SBU ~=  4m14s = 254 secondes

```

$ genlop -c

 * sys-devel/binutils-2.17

       current merge time: 1 seconds.

       ETA: 4 minutes and 13 seconds.

```

donc pour Wine (par exemple) :

```

$ genlop -c

 * app-emulation/wine-0.9.17

       current merge time: 3 seconds.

       ETA: 28 minutes and 12 seconds.

```

Wine = 28 mins 15 sec = 1695 secondes = 6.9183673469387754 SBU ~= 7 SBU

Si maitenant qqn arrive avec une config qui n'as rien à voir avec la mienne, elle calcul son propre t/SBU (disont 5minutes = 300sec) et peut donc déduire que compiler Wine lui prendra ~ SBUWine x t/SBU = 7 x 300 = 2100 secondes = 35 minutes.

Le but serai de faire un programme qui :

- calcule le t/SBU de la machine hôte

- a une base de donnée de SBU par paquet

- calcule (prédis?) le temps de compilation d'un paquet.

donnez le SBU de Firefox pour faire une comparaison ^_____^

chez moi :

firefox : 33m52s = 2032secondes = 8 SBU

----------

## Il turisto

et le sbu tu le calcule comment?

un truc bidon genre tu fais une mega boucle qui pompe tout le cpu et tu en ressore le temps?

----------

## kaworu

tu peux le calculer soit en te basant sur genlop (moyenne du temps de compil en prenant chaques fois que t'as compilé binutils), les logs de portage,  ou alors compiler une fois (voir 3fois) binutils pour te créer une idée du t/SBU.

----------

## Temet

 *Il turisto wrote:*   

> et le sbu tu le calcule comment?
> 
> un truc bidon genre tu fais une mega boucle qui pompe tout le cpu et tu en ressore le temps?

 

T'as lu le post précédent trop vite, c'est tout bien expliqué dedans  :Wink: 

C'est pas con du tout comme idée ... un paquet "test" quoi.

----------

## geekounet

A la base, c'était calculé par rapport à la compilation de bash  :Smile: 

----------

## kaworu

 *pierreg wrote:*   

> A la base, c'était calculé par rapport à la compilation de bash 

 

pourquoi pas, mais bash a un temps trop court de compilation (0.25 SBU chez moi) ce qui peut donner des comparaisons moins fiables. On peut soit utiliser le SBU, soit un autre paquet qui répond à 2 conditions :

- temps de compilation entre 5 et 10 mins

- fait parti du système de base.

----------

## Il turisto

 *Temet wrote:*   

>  *Il turisto wrote:*   et le sbu tu le calcule comment?
> 
> un truc bidon genre tu fais une mega boucle qui pompe tout le cpu et tu en ressore le temps? 
> 
> T'as lu le post précédent trop vite, c'est tout bien expliqué dedans 
> ...

 

Oui c vrai mais je devais partir.

donc on se baserait sur :

1 bsu = time emerge --nodeps binutils.

Mais seulement il faudrait être sur que l'utilisateur ne fais rien pendant ce temps la.

Bon je suis tjs partant pour cela mais que pensez vous du message du mec de basc?

edit : pour le bsu il ne faut pas de ccache et évidemment pas de distcc ...

sinon pq pensez vous que le bsu est mieux qu'un temps en secondes? Simplement car cela permet de croiser des comparatifs entre cpu, ... ?

Exemple : j'ai un p4 2 giga et mon bsu est de 4 minutes et d'un autre cote un amd xp 2000+ et mon temps est aussi de 4 minutes alors je peux utiliser les résultats du p4?

Mais dans ce cas un temps serait tout aussi clair.

Aussi que nous apporte le bsu?

----------

## man in the hill

 *Il turisto wrote:*   

> sinon pq pensez vous que le bsu est mieux qu'un temps en secondes? Simplement car cela permet de croiser des comparatifs entre cpu, ... ?
> 
> Exemple : j'ai un p4 2 giga et mon bsu est de 4 minutes et d'un autre cote un amd xp 2000+ et mon temps est aussi de 4 minutes alors je peux utiliser les résultats du p4?
> 
> Mais dans ce cas un temps serait tout aussi clair.
> ...

 

A mon avis le sbu n'apporte rien du tout puisque  l'on veut des temps, peut-être une variable ds ton script ...de toute façon , tu es obligé de le traduire en temps pour chaque paquet  sinon cela ne veux pas dire grand chose donc autant bosser avec le time (comparer le temps des paquets est plus parlant que le sbu...) ...

Ensuite avec une grosse base de données, tu pourras sortir de bonnes stats en fonction de l'arch/cpu (comparaisons intéressante amd/intel !) , des flags/ldflags/version-gcc , tour ou portable, etc...Tu fais un site à la jhbuild  http://jhbuild.bxlug.be/   qui propose un script en python qui lui renvoit des infos sur la compile de gnome-cvs.

                                                                                        @+

----------

## PabOu

Je suis également d'accord de fournir mes infos de compilation...

Mais je suis tres sceptique sur leur utilité... vraiment trop de paramètres entrent en compte (je liste ceux auquels je pense même si déjà dit) :

Disque dur, avec vitesse qui diffère selon l'utilisation d'un utilisateur, mais aussi selon l'endroit ou on travaille physiquement sur le disque, .. mais aussi paramètres hdparm, performances du chipset et de son module dans le kernel, ... et puis si on travaille sur un partage distant (par réseau) ?

 Filesystem utilisé.. sur certains fichiers, un FS sera peut-etre plus rapide et cela peut fausser les SBU (mais j'ai vraiment pas l'impression que c'est ca qui va faire tout basculer)

 Les useflags peuvent modifier les trucs à compiler

 Utilisation ccache et/ou distcc

 version de gcc (ou autre) , glibc, et toute la clique

 kernel (et patchset) utilisé... Ca fait varier les performances.

 Le(s) CPU(s)... On à déjà vu des CPU qui réduisent leur vitesse automatiquement quand ils chauffent de trop... ou bien que l'utilisateur ait volontairement changé la vitesse du CPU et à oublié de remettre en place avant de faire son emerge..

 La ram.. vitesse et taille. Et si ca swappe PAS pour le programme test qui va servir à étalonner le SBU.. Mais que pour un programme plus gros ca swappe ?

 Le temps de téléchargement des sources... Oui oui, si il ne faut pas les redownloader, le temps donné par genlop sera plus court !

 PORTAGE_NICENESS

 Comme déjà dit, utilisation de la machine à coté de l'emerge (surf, film, mp3, jeu,.. ou même quelqu'un qui travaille.. si si, ca arrive :-P). Peut-etre que certaines activitées sont vraiment très légères pour la charge système, mais d'autres peuvent être assez lourdes (azureus + emerge = swap chez moi).

 Moi, ca m'arrive souvent de faire plusieurs emerge en parrallèle, même si c'est pas recommandé.. voilà encore qui fausse les résultats de genlop...

Un emerge incomplet (erreur de compilation par exemple), comment apparait-il avec genlop ?

Et je suis certain que j'en oublie plein ;)

PS : drôle de question, mais en tapant, je me suis pris à mettre "émerge". Et donc, ma question m'est naturellement venue à l'esprit : on dit éééémerge ou iiiiimerge (à l'english) ?

----------

## titoucha

Je veux bien aussi fournir mes infos, même si je suis très septique sur la possibilité de faire quelque chose d'utilisable vu que sur ma propre machine entre deux compilation du même programe les temps que genlop me donne ne correspondent pas à la réalité, alors sur une autre machine !

----------

## kaworu

C'est à dire que si je dis : firefox ~= 8 SBU

c'est plus clair (AMHA) que 35mins avec un centrino 1.73Ghz.

Pour qqn qui doit compiler sur une autre arch (genre dual core 2x plus puissant)

ça sera plus parlant pour lui d'avoir le SBU.

Comment savoir si une archi 2x plus puissante compile 2x plus vite? où est-ce exponentiel? ou le ./configure ralenti le tout?

si je te dis : firefox 35 mins sur centrino 1.73Ghz comment calcul-tu pour un celeron 400Mhz? et pour un AtlhonX2 ?

Si on doit avoir des stat par puissance et processeur, on s'en sort jamais non?

----------

## Il turisto

 *PabOu wrote:*   

> Je suis également d'accord de fournir mes infos de compilation...
> 
> Mais je suis tres sceptique sur leur utilité... vraiment trop de paramètres entrent en compte (je liste ceux auquels je pense même si déjà dit) :
> 
> Disque dur, avec vitesse qui diffère selon l'utilisation d'un utilisateur, mais aussi selon l'endroit ou on travaille physiquement sur le disque, .. mais aussi paramètres hdparm, performances du chipset et de son module dans le kernel, ... et puis si on travaille sur un partage distant (par réseau) ?
> ...

 

Evidemment ici on parle d'un temps moyen... une approximation.

Je pense qu'il faille exclure les distcc car de ce côté on ne peut rien savoir.

Euh je ne sais plus qui a parlé de script en python et malheureusement c'est un language que je ne maîtrise pas. Je pensais faire cela en bash tout simplement.

Mais bon si je me lance la dedans et qu'un codeur python veut aider il est le bienvenu  :Smile:  .Last edited by Il turisto on Fri Jul 14, 2006 9:33 am; edited 1 time in total

----------

## titoucha

Alors tu seras obliger d'utiliser une référence (SBU) comme le proposait @kaworu car sinon c'est absolument impossible à calibrer vu le nombre de paramètres à prendre en compte.

Je pense pour ma part que c'est la seul solution valable.

----------

## Temet

Je le pense aussi, ça donne une unité indépendante (plus ou moins) de la puissance de la machine.

----------

## titoucha

Exacte et comme dit plus haut ensuite tu calcule combient vaut cette référence pour ta machine et tu peut avec celle-ci calculer tous les autre temps.

Il y aurrait bien la méthode statistique qui fonctionnerait aussi, mais elle demmande beaucoup trop de données de départ pour avoir une approximation fiable, donc pour moi elle n'est pas réaliste dans notre cas.

----------

## Il turisto

Ce week-end je n'aurait pas beaucoup de temps a moi car madame me réclame tout plein pour sortir  :Smile: .

Aussi je vais y réfléchir et lundi (si je n'oublie pas) je vous expose ce que je pense faire. Après on en cause et puis je me lance.

----------

## Magic Banana

N'existe-t-il pas une commande bas niveau qui permet d'avoir le temps de vie d'un thread indÃ©pendemment des autres.

AprÃ¨s tout, les diffÃ©rents threads sont ordonnancÃ©s par le kernel et il est possible de connaitre l'Ã©tat d'un thread (suspendu, en cours, etc.). Certes, je m'Ã©loigne grandement de votre projet puisque cela reviendrait Ã  lancer un petit programme avant chaque emerge qui discuterait avec l'ordonnanceur pour obtenir les vÃ©ritables temps de compilation (indÃ©pendamment des autres applications) contrairement Ã  ce qui est loggÃ© par emerge...

Sinon, tu devrais essayer d'insister auprÃ¨s de dma147 (fait gaffe il est du genre succeptibles ce qui explique, mais n'excuse pas, que des dÃ©veloppeurs se sont amusÃ©s Ã  le faire craquer...   :Rolling Eyes:  ). Tu pourrais rÃ©cupÃ©rrer son code et lui demander une collaboration pour t'aider Ã  le comprendre et l'amÃ©liorer. Je le rejoins sur le fait qu'il est peu constructif  (bien que plus excitant) de commencer de rien un logiciel qui a dÃ©jÃ  Ã©tÃ© fait.

----------

## Il turisto

Euh magic banana n'aurait tu pas des problèmes d'utf8?

Bref j'ai déjà réécrit a dma147 et ce sans réponses. Je ne peut le forcer à nous aider.

Sinon pour calculer le temps d'éxécution réel d'un processus dans le cpu on peut utiliser time.

Je viens de faire un man time et je crois que ce qui m'intéresserait serait le truc suivant :

time -f %S emerge binutils

pouvez vous m'éclairer sur l'utilisation des arguments avec time? Pensez vous que ceci serait une bonne idée?

----------

## kaworu

Oui faire un truc style time emerge -1 binutils serait pas mal. Le top serait tout de même de se baser sur les logs de portage (comme le fait genlop) pour avoir des infos sur combiens de temps met binutils pour être compilé (je l'ai déjà compilé plus de 5x, ça fait une moyenne fiable) -- et après seulement, si il n'y pas de logs d'emerge de binutils, on peut tenter un time emerge -1 binutils mais je n'aime pas bcp cette solution car elle demande d'être en root, elle reemerge binutils, et c'est moins fiable qu'une moyenne de logs qui sera déjà surement présente.

----------

## Ey

 *kaworu wrote:*   

> donnez le SBU de Firefox pour faire une comparaison ^_____^
> 
> chez moi :
> 
> firefox : 33m52s = 2032secondes = 8 SBU

 

J'ai un SBU de 8,4 pour firefox 1.5.0.4

----------

## titoucha

J'ai décider de faire le cheminement inverse je connais la référence le paquet  sys-devel/binutils et je sais que firefox prend comme temps pour compiler 8 SBU.

Je calcule en premier ma SBU, pour cela j'ai fais la moyenne des 5 dernières compilations de binutils et j'arrive à 3m20s = 1SBU pour moi. 

Sachant que le temps pour compiler firefox c'est 8 SBU je devrais trouver 8x3m20s ou 8x200s=1600s.

J'ai trouvé sur une moyenne de 4 compilations 1557secondes, je ne sais pas si c'est de la chance ou quoi mais la précision dans ce cas est excellente.

----------

## kaworu

@titoucha effectivement ça à l'air pas mal ^______^ (waaa t'es de genève! où ça ???)

En gros si y'a une marge d'erreur de SBU d'environ 10% , ça nous permettra de faire de bonnes stats.

----------

## At0m3

Arf, va falloir réviser ses cours de terminale de probabilité, pour calculer le nombre d'emerge à faire sur tel paquet, afin d'obtenir une probabilité se rapprochant le plus possible de la réalité... Mais si, souvenez vous, Bernouilli tous ça   :Very Happy:  !

----------

## Ey

Bof, en fait ce qui compte c'est plutot la plus petite valeur (celle que tu obtiens quand tu n'es pas en train de jouer a q3 en même temps par exemple). Après il faudrait juste faire entrer en compte le load average des 5 dernières minutes pour estimer combien de puissance CPU sera dispo pour l'emerge et on doit obtenir un truc a peu près correct... Enfin tout dépend encore une fois de ce que l'on fait pendant l'emerge...

EDIT : moi par exemple j'ai mis PORTAGE_NICENESS à 19 et ça a pour conséquence que dans mon genlop -t j'ai des disparitées énormes entre 2 merge du même paquet (même version, même use flags).

----------

## man in the hill

 *kaworu wrote:*   

> C'est à dire que si je dis : firefox ~= 8 SBU
> 
> c'est plus clair (AMHA) que 35mins avec un centrino 1.73Ghz.
> 
> Pour qqn qui doit compiler sur une autre arch (genre dual core 2x plus puissant)
> ...

 

Moi, je pensais que l'utilisateur lambda n'avait pas à jouer avec le sbu qui peut-êre utilisé de manière transparente ds un script...Je pars du principe qu'une bonne base de données a dèjà été récupérées, si un utilisateur veux installer une gentoo et que ce script est présent sur le cd d'install, il a chrooté et est prêt pour l'install...Il n'a pas encore compilé binutils qui est la référence sous la variable sbu ds le script...Il veut donc savoir combien de temps va prendre gcc pour compiler... Il tape la commande du script :

```
nom_du_script   <option>  gcc
```

comme binutils n'a pas encore été compilé , les infos sortirons de la base de donnée + de infos de son proc...ensuite des que binutils est compilé , le script ira chercher ds les log d'émerge pour de infos plus précises...En gros, c'est ce que je voyais...

                                                                @+

----------

## titoucha

 *man in the hill wrote:*   

> 
> 
> comme binutils n'a pas encore été compilé , les infos sortirons de la base de donnée + de infos de son proc...ensuite des que binutils est compilé , le script ira chercher ds les log d'émerge pour de infos plus précises...En gros, c'est ce que je voyais...

 

Je vois pas trop comment tu veux avoir le SBU de la machine sans compiler au moin une fois binutils, car les info du proc c'est pas vraiment suffisant pour faire une approximation, il y a entre autre la quantité de mémoire et le disque dur qui entre en ligne de compte, je ne pense pas que le même cpu avec 128Mb et un vieux 4200tm ou le même avec 2Gb et 2 raptors en raid0 vont compiler à la même vitesse.

@kaworu je suis près de l'ONU et toi ?

----------

## Il turisto

Mais même si on prend comme référence le sbu on dois quand même tenir comptes des USE flags ...

Parce que vlc avec le support du mp3, ac52, et tout le toutim est surement plus long à compiler que sans tout ces supports ...

----------

## Magic Banana

LA question est : "Est-ce que le log d'emerge est fait en utilisant time ?" Si c'est le cas, moins de problÃ¨mes de charge de machine (dans les limites de la RAM).

Sinon, en faisant tout des petiits calculs statistiques ce doit etre possible de ne pas se baser sur 1 compilation rÃ©fÃ©rence mais sur toutes les compilations faites sur le systÃ¨me (en comparant la base de donnÃ©e propre Ã  l'utilisateur et celles de la communautÃ© entiÃ¨re). Cela Ã©viterait qu'une compilation Ã©trangement plus lente (ou plus rapide) de binutils ne se ressente trop sur les estimations futures. Si vous voulez que je vous sorte une formule (voire un algo) je peux m'y pencher dessus...

Sinon pour dma147, tu dois pouvoir rÃ©cupÃ©rer son code (je suppose qu'il est sous licence GPL). Bon, c'est sur, que si c'est codÃ© de facon crade dans un langage exotique ca va etre difficile d'en faire quelquechose...

PS : Pour les accents je suis dÃ©solÃ©. Je suis au labo sur une vieille Red Hat 9 avec Mozilla 1.2.1, un clavier italien et pas les droits d'administration...

----------

## yoyo

 *Il turisto wrote:*   

> Mais même si on prend comme référence le sbu on dois quand même tenir comptes des USE flags ...
> 
> Parce que vlc avec le support du mp3, ac52, et tout le toutim est surement plus long à compiler que sans tout ces supports ...

 Alors il suffit de rappeler que le nombre de SBU correspond au paquet seul (emerge -1 --nodeps paquet) pour la base de donnée.

Mes 0.02 cents.

----------

## sireyessire

 *yoyo wrote:*   

>  *Il turisto wrote:*   Mais même si on prend comme référence le sbu on dois quand même tenir comptes des USE flags ...
> 
> Parce que vlc avec le support du mp3, ac52, et tout le toutim est surement plus long à compiler que sans tout ces supports ... Alors il suffit de rappeler que le nombre de SBU correspond au paquet seul (emerge -1 --nodeps paquet) pour la base de donnée.
> 
> Mes 0.02 cents.

 

il y a pas que les dependances qui vont intervenir. Si tu veux le support de ce truc là, il va y avoir le module correspondant qui sera compilé dans ton paquet pour que l'interfaçage soit possible.

----------

## Enlight

Ben déjà le plus basique de chez basique ce serait un système à la SBU comme LFS, après sans même penser à l'activité de l'ordi, faut penser au nombre d'objets (.o) crées car le temps va varier en fonction du MAKEOPT tandis que le temps de linkage n'est pas affecté. La partie ./configure elle varie selon le nombre de CPU's car pas mal de process sont crées, le filesystem et les perfs disque jouent beaucoup également...

----------

## titoucha

Je pense que si la LSF à choisi la SBU c'est pas pour rien car il y a vraiment énormément de variablesà prendre en compte si on veut être précis alors autant faire quelque chose d'indicatif et après une ou deux compilations l'utilisateur va avoir une pas trop mauvaise aproximation du temps de compilation.

----------

## Il turisto

 *yoyo wrote:*   

>  *Il turisto wrote:*   Mais même si on prend comme référence le sbu on dois quand même tenir comptes des USE flags ...
> 
> Parce que vlc avec le support du mp3, ac52, et tout le toutim est surement plus long à compiler que sans tout ces supports ... Alors il suffit de rappeler que le nombre de SBU correspond au paquet seul (emerge -1 --nodeps paquet) pour la base de donnée.
> 
> Mes 0.02 cents.

 

Bien sur on parle du paquet seul mais vlc avec le supprot de l'ac52 vient seul. Il n'y a pas de dépendence pour cela seulement des modules interne au paquet de vlc. Comme un kernel compilé avec le minimum prendra bcp moins de temps que compilé avec tout. 

Je parle de kernel à titre indicatif afin de préciser l'idée du temps de compilation des modules sans même parler de dépendances.

----------

## yoyo

Au temps pour moi. Mais cette différence est-elle significative ?? Je veux bien croire qu'elle le soit pour un kernel mais pour un paquet type vlc, l'ajout d'un USE ne doit pas tant déstabiliser la moyenne que ça si ?? Et en prenant en référence les USE par défaut pour chaque architecture, on devrait avoir une bonne approximation pour la plupart des utilisateurs.

Enfin, le nombre de paquets où les USE influent directement sur le temps de compilation (hors dépendances) ne doit pas être très important ...

----------

## man in the hill

 *titoucha wrote:*   

>  *man in the hill wrote:*   
> 
> comme binutils n'a pas encore été compilé , les infos sortirons de la base de donnée + de infos de son proc...ensuite des que binutils est compilé , le script ira chercher ds les log d'émerge pour de infos plus précises...En gros, c'est ce que je voyais... 
> 
> Je vois pas trop comment tu veux avoir le SBU de la machine sans compiler au moin une fois binutils, car les info du proc c'est pas vraiment suffisant pour faire une approximation, il y a entre autre la quantité de mémoire et le disque dur qui entre en ligne de compte, je ne pense pas que le même cpu avec 128Mb et un vieux 4200tm ou le même avec 2Gb et 2 raptors en raid0 vont compiler à la même vitesse.

 

Bien sûr on prend cette info ds une base de donnée qui existe au préalable, il faut une base de donnéés à jour et assez conséquentes (en espérant que les gentooistes utilisent toutes sortes de matos)...Le but étant de donner  une première approximation , ensuite le sbu de la machine hôte sera utilisé, sinon tu peux tjrs lui sortir  ("Vôtre matériel n'est pas encore répertorié ! Il le sera après la compilation de  binutils alors vous pourrez rééssayer..."). Le script devrait aussi pouvoir demander aux utilisateurs s'ils veulent te renvoyer des infos...

                                                                               @+

----------

## Il turisto

donc on partirais sur l'idée du sbu.

Le mec compile binutils ca lui dis : tu as un sbu de 2 minutes.

Il envoie ca sur le serv et le serv lui dis : si ton sbu est de 2 minutes alors firefox se compilera en +/- 30 minutes.

Mais pour cela de quoi devrais je tenir compte?

use flags? ram? type de hdd?

Pour moi les hdd n'influent pas vu qu'ils sont pris en compte dans le sbu. la ram +/- pareil.

Bon si le mec a une vieille install trouver son sbu dans le log c facile.

Maintenant si l'install est fraiche on se base simplement sur la seule compilation de binutils qu'il a faite en sachant qu'elle a peut etre été ralentie par autre chose ou on fait un : time emerge -1 binutils ???

question subsidiaire : comment on utilise les paramètre de time comme le -f ???

----------

## Enlight

 *yoyo wrote:*   

> Au temps pour moi. Mais cette différence est-elle significative ?? Je veux bien croire qu'elle le soit pour un kernel mais pour un paquet type vlc, l'ajout d'un USE ne doit pas tant déstabiliser la moyenne que ça si ?? Et en prenant en référence les USE par défaut pour chaque architecture, on devrait avoir une bonne approximation pour la plupart des utilisateurs.
> 
> Enfin, le nombre de paquets où les USE influent directement sur le temps de compilation (hors dépendances) ne doit pas être très important ...

 

en général je pense que tu as raison, mais je vois une exception avec glibc-omitfp qui devrait si j'ai bien compris doubler le temps de compilation (une glibc sans frame pointers et une avec au cas où...) idem pour les histoires de NPTL-pas-only.

----------

## kaworu

@titoucha : au Paquis, juste en dessous ! (MP!)

je pense que le but c'est vraiment d'avoir une approximation, et pas un temps à la secondes près. C'est plutôt du genre, est-ce que je dois me faire un café ou un partie de bridge durant la compile du paquet X...

du coup il suffit d'avoir le SBU de la machine, une base de donnée sur les paquets, et un script qui fait le calcul.

----------

## titoucha

+1 pour les deux propositions.

----------

## Il turisto

voici le résultat de genlop pour moi :

```

genlop -t binutils

 * sys-devel/binutils

     Fri Jun  2 22:47:39 2006 >>> sys-devel/binutils-2.16.1-r2

       merge time: 4 minutes and 53 seconds.

     Sat Jul  1 16:17:15 2006 >>> sys-devel/binutils-2.16.1-r3

       merge time: 11 minutes and 41 seconds.

     Sat Jul  1 17:46:03 2006 >>> sys-devel/binutils-2.16.1-r3

       merge time: 10 minutes and 50 seconds.

```

Pensez-vous que se baser sur ce package est une bonne idée ou qu'il vaille meiux que je parle le log par moi même?

Mais on en revient au fait que le code en c,bash,php, et un tas d'autres trucs mais pas python ...

----------

## Il turisto

sorry pour le double post mais hier j'ai commencé l'appli en bash et je me demandais :

pour le temps du sbu je prend le temps moyen de toutes les compilation de binutils ou uniquement le temps minimum?

Sachant que le temps minimum donne une valeur de compilation si on ne fais rien avec la machine et le temps moyen une estimation de la machine utilisée.

Je devrais peut-être faire les deux ainsi je pourrais dire : si vous n'utilisez pas le pc la compilation devrait prendre x min et si vous l'utilisez ca devrait prendre xx min ...

Edit : ca n'intéresse plus personne? Bon le script étant presque fini je me demande : avec le sbu est il besoin de tenir compte de l'architecture? du processeur?

J'ai laissé tomber les flags et je pense que ni l'architecture ni le cpu influent dans le sbu. Ce que je veux dire c que si le mec a un p4 et un sbu de 3minutes et que de l'autre cote on a un ppc avec le meme sbu les 2 devraient compiler firefox sur le meme temps (+/-). Est ce que je me trompe?

----------

## man in the hill

 *Il turisto wrote:*   

> sorry pour le double post mais hier j'ai commencé l'appli en bash et je me demandais :
> 
> pour le temps du sbu je prend le temps moyen de toutes les compilation de binutils ou uniquement le temps minimum?
> 
> Sachant que le temps minimum donne une valeur de compilation si on ne fais rien avec la machine et le temps moyen une estimation de la machine utilisée.
> ...

 

Salut,

Les infos du arch/proc/ te servirons ultérieurement au fur et à mesure que ta base de données va  gonfler pour donner de infos par ex à un mec qui va installer gentoo pour la première fois sans que binutils soit déjà compilé...(regarde mes précédent post qui parlait de ce point précis) , sinon cela n'a pas d'incidence à mon avis si le sbu est identique...

j'enlève mon niceness et je file des infos...

[EDIT] Voici mon SBU  pour un portable HP zv pavilion AMD64 Sempron 3200+ avec des flags basique "-march=k8 -O2 -pipe"

```
 Tue Jul 18 10:43:27 2006 >>> sys-devel/binutils-2.17

       merge time: 4 minutes and 48 seconds.

     Tue Jul 18 10:48:36 2006 >>> sys-devel/binutils-2.17

       merge time: 4 minutes and 48 seconds.

     Tue Jul 18 10:53:42 2006 >>> sys-devel/binutils-2.17

       merge time: 4 minutes and 45 seconds.

     Tue Jul 18 11:00:36 2006 >>> sys-devel/binutils-2.17

       merge time: 4 minutes and 50 seconds.

```

Tu devrais ouvrir un post pour récolter des infos /cpu/emerge --info/make.conf/sbu

[/EDIT]

                                                                                                   @+

----------

## Magic Banana

Personellement je prendrais le temps minimum obtenu lors des différentes compilations... En effet, pour moi, le but est de savoir si je reste devant son ordi (compilation de moins de 10 minutes), si je me fait une bouffe (compilation de moins d'un heure) ou un monopoly (une heure et plus) !  :Laughing: 

À part dans le premier cas, qui quelque part est le moins intéressant (j'aime la bouffe et le Monopoly moa  :Very Happy:  ), l'ordinateur est peu utilisé.

Maintenant ca dépend du comportement d'utilisation de son nordi : Un petit thread sondage "Que faites-vous pendant les compilations ?"  :Very Happy: 

----------

## idodesuke

Soit je matte un film avec mplayer, soit je surf sur le web soit je vais coucher mais je peux faire joujou avec vim et python ou perl aussi etc... bref y a des chances que j'utilise ma bécanne même si elle compile.

----------

## S_Oz

 *Magic Banana wrote:*   

> Maintenant ca dépend du comportement d'utilisation de son nordi : Un petit thread sondage "Que faites-vous pendant les compilations ?" 

 

Je joue à Enemy Territory pendant une compilation en "-j1" car j'ai un double core.  :Very Happy:   :Arrow: 

----------

## titoucha

 *Il turisto wrote:*   

> 
> 
> Edit : ca n'intéresse plus personne? Bon le script étant presque fini je me demande : avec le sbu est il besoin de tenir compte de l'architecture? du processeur?
> 
> J'ai laissé tomber les flags et je pense que ni l'architecture ni le cpu influent dans le sbu. Ce que je veux dire c que si le mec a un p4 et un sbu de 3minutes et que de l'autre cote on a un ppc avec le meme sbu les 2 devraient compiler firefox sur le meme temps (+/-). Est ce que je me trompe?

 

Oui en tout cas moi je suis toujour intéressé.

Pour ta deuxième remarque oui si deux machine on la même SBU elle vont compiler un programme donné dans le meme laps de temps.

----------

## Il turisto

 *man in the hill wrote:*   

> 
> 
> Salut,
> 
> Les infos du arch/proc/ te servirons ultérieurement au fur et à mesure que ta base de données va  gonfler pour donner de infos par ex à un mec qui va installer gentoo pour la première fois sans que binutils soit déjà compilé...(regarde mes précédent post qui parlait de ce point précis) , sinon cela n'a pas d'incidence à mon avis si le sbu est identique...
> ...

 

je vais en effet ouvrir un post sous peu mais pas pour récolter des infos. Mon script me permettra de les récolter automatiquement (si le user le désire).

Pour le moment le script : prend le sbu dans les logs. Détermine la valeur min,max et moyenne et l'envoie sur le serv (pour binutils). Si binutils n'a jamais été compilé il propose de le faire pour trouver une valeur.

To do : 

permettre à l'utilisateur d'interroger la base de donnée pour un paquet précis.

Parser entièrement le log de compilation pour remplir la base de donnée

Créer une table d'architecture afin de stocker les type de cpu, ... du user

Vous voyez d'autre chose qui seraient utiles dans la version 0.1?

----------

## PabOu

pour la ram, il s'agit vraiment d'un problème important..

Je vais donner un exmple avec des chiffres (qui sont pas du tout réels, c'est juste histoire d'être plus visuels.. en réalité je sais pas combien de MB il faut pour chaque paquet)

La personne qui va crééer la base de données à 512MB de ram.

Elle va compiler binutils et trouver son propre SBU.

A partir de ce SBU, elle va crééer le SBU pour firefox par exemple.

Admettons que pour firefox, les 512MB sont suffisant et le système n'a pas besoin de swapper.

Maintenant, je prends une autre personne qui à 128MB de ram.

Ces 128Mo de ram sont suffisants pour compiler binutils sans swapper, et donc le SBU va être déterminé.

Mais lors de la compilation de firefox, 128MB ne sont plus suffisant, et le système swappe beaucoup.

Le SBU donné par la base de données pour firefox ne correspondra donc pas du tout.

J'espère que vous avez compris ?

Autre problème, certains ebuilds masquent ou remplacent les CFLAGS et compagnie.

Un exemple :

La personne qui fait la base de données n'a aucune optimisation spéciale (du genre un simple -march=athlon-xp -O2 -fomit-frame-pointer) et donc tous les SBUs seront valable pour la même base.. en effet rien ne sera filtré

Elle va donc crééer le SBU pour binutils et puis aussi pour des autres programmes.

Une autre personne à des optimisations qui permettent de réduire le temps de compilation (bien que je ne sais pas si ca existe vraiment et dans quelle mesure c'est bénéfique)... 2 cas possibles

1)Pour binutils, les cflags sont filtrés et donc le SBU de base n'est pas calculé correctement pour sa machine et ses optimisations.. les ebuilds qui ne filtrent pas les options de compilation auront donc des temps éronnés.

2) Binutils n'est pas filtré, et on obtient un SBU équivalent à un plus petit temps. Pour les applications filtrées (mplayer peut-etre ? openoffice, ...), le temps sera plus long que prévu avec le SBU.

Pour le disque dur, les fichiers sources et les fichiers créés peuvent être totallement différents sur leur taille, etc... (exemple, un paquet avec des centaines de petits fichiers, et un paquet avec de tres gros fichiers, mais pas beaucoup)... et selon le filesystem, cela va fausser le SBU... il faut voir dans quelle mesure cela va faire impact.

----------

## Il turisto

Je suis pas sur que le disque dur change quelque chose car lors d'une compilation le compilateur est tjs en attente de cpu et pas de disque dur.

Sauf au moment de copier les fichiers mais à ce moment la c'est fini ...

Donc du coup je ne sais pas si la ram change qqch. Perso sur mon portable je suis passé de 256mo de ram à 1024 et cela n'a pas changé grand chose au niveau compilation voir même rien du tout.

Et pourtant a 256 mo la machine swappait à mort.

Enfin on peut tenir compte de la ram dans les résulats.

Pour les flags on a dis qu'on en tenait pas compte.

Si maintenant on veut en tenir compte il faut fair un script qui parse tout les ebuilds pour connaitre les flags filtrés mais je ne pense pas que ce soit utile.

----------

## titoucha

Je sens que l'on ne va pas être d'accord sur l'influence de la mémoire et du disque dur sur la conpilation, j'ai deux machines avec le même cpu mais pas la même quantité de mémoire l'une doit swapper pour compiler certains programmes et son disque est un 5400tours, je peux te garantir que la compilation de programme qui demande beaucoup de resources et font swapper la deuxième machine ne se compile pas dans le même laps de temps.

----------

## PabOu

il suffit de voir qu'une simple copie de fichiers (une utilisation du disque quoi) fait grimper la charge... alors si ca doit compiler en plus à coté :\

----------

## Il turisto

bon donc je tiens compte de la ram en + de l'architecture. Autre  chose?

Pensez vous qu'il soit important de tenir compte de la version du soft?

genre binutils-2.16.1-r3 et binutils-2.16.1-r2 ou alors je fais binutils?

Ou encore on ne tiens compte que des versions majeures ...

Je dirais que sans tenir compte de la version ca fais une moyenne et ca fais que je n'aurais pas besoin de nettoyer la base. mais avec le numero c plus précis. 

Qu'en pensez vous?

----------

## kaworu

perso, je pense qu'il faut prendre uniquement les archi. (pas la RAM, ni les versions).

pk ?

parce que je ne pense pas que c'est rentable de compatibiliser la RAM, les versions. à ce moment faut tenir compte de la vitesse du proc, des uses, des cflags, du portage niceness, le ./configure, la vitesse du disque dur... et après ça on aura des résultat qui seront toujours approximatifs. Je veux dire, dans l'idée, le but c'est de répondre à la question : café , pizza, ou monopoly non?

Les résultat seront toujours assez satisfaisant avec uniquement les archi, et cela simplifiera bcp le script.

mes 2 cents..

----------

## Il turisto

au pire on peut commencer light comme ca et évoluer si la demande se fait.

Le script light comme cela est déjà fonctionnel. Pas assez rapide à mon goût mais fonctionnel.

Dites moi : j'ai un problème moral a résoudre. Je voudrais mettre cela sous licence. Je veux que les gens puissent l'utiliser gratos, le modifier a condition de publier les modifs (au moins à moi pour les répercuter) mais ne puissent pas faire d'argent avec.

Quelqu'un s'y connait?

----------

## Magic Banana

GPL...

----------

## epsy

nan la gpl n'oblige pas à publier les fichiers et on peut faire de l'argent avec

ps: si tu les obliges à publier les modifs...alors ce n'est plus une license libre  :Exclamation: 

(voir le cas de l'apsl < 2.0)

----------

## ghoti

 *epsy wrote:*   

> ps: si tu les obliges à publier les modifs...alors ce n'est plus une license libre  

 

Hu ? Les trolls se réveillent ?

Suivant ton raisonnement, la GPL n'est donc pas une licence libre ?

----------

## epsy

non, je ne sort pas de ma caverne  :Wink: 

==> http://www.gnu.org/philosophy/historical-apsl.fr.html

(cela ne vaut pas pour les version de l'apsl 2 et supérieures)

la gpl, à ce que je sache n'oblige en rien à publier quoi que ce soit

----------

## ghoti

 *epsy wrote:*   

> la gpl, à ce que je sache n'oblige en rien à publier quoi que ce soit

 

Peut-être mais il y a peu de sens à placer un programme sous GPL si ce n'est pas pour le distribuer !

Et en cas de distribution sous GPL, les sources doivent être accessibles en vertu de son article 3.

----------

## titoucha

Aucune licence ne peut obliger quelqu'un à publier les sources d'un programme qu'il à fait ou modifier pour son usage personnel, comment on peut vérifier, mais du moment qu'il le distribue la GPL me semple pas mal, je ne suis pas un expert mais comme dit plus haut à ce moment il doit y avoir publication des sources.

----------

## kaworu

à ce que comprend Il turisto veut obliger ceux qui font des modification dans le code de les publier. à ce moment je trouve aussi que ce n'est plus vraiment une licence libre..

GPL +1

 *wikipédia wrote:*   

> 
> 
> L'objectif de la licence GNU GPL, selon ses créateurs est de garantir à l'utilisateur les droits suivants (appelés libertés) sur un programme informatique :
> 
> la liberté d'exécuter le logiciel, pour n'importe quel usage ;
> ...

 

Il faut aussi ajouter qu'un logiciel sous GPL est toujours redistribué sous GPL (il reste libre) et qu'un logiciel dans lequel on inclu du code GPL doit etre distribué sous GPL.

[url]http://fr.wikipedia.org/wiki/Licence_publique_générale_GNU

http://www.gnu.org/licenses/gpl.html[/url]

----------

## Il turisto

Bon ok alors on oublie ce point.

Ce que je veux vraiment c que personne ne fasse d'argent avec mon script (aussi minable soit-il).

Je pourrais vous faire un long débat sur le pourquoi je ne veux pas cela mais ca ne servirais à rien.

Pour résumer en un mot je dirais : je fournit ce travail pour la communauté, je n'ai pas l'intention de gagner de l'argent avec (évidemment si on m'en offre je le prend  :Smile: ) et je ne veux pas qu'on gagne d'argent sur mon dos (mes patrons sont la pour ça  :Wink: )

----------

## kaworu

On comprend tout à fait tes raisons ^___^

la GPL "garanti" qu'on ne peut faire d'argent, car par exemple si je le redistribue en demandant rémunération, le client va se tourner vers qqn (par exemple toi) qui le redistribue gratuitement.

Mais si je le modifie, puis dis que c'est une version améliorée, comme je suis le seul détenteur du produit, je peux le vendre. (après surement qu'un client va le redistribué gratuitement et mon petit commerce est foutu, donc c'est pas viable).

----------

## Il turisto

Donc pour vous le gpl serait ce que je recherche?

Du coup seconde question : pour être sous gpl il suffit de dire : je suis sous gpl et je distribue la licence avec mon soft ou il faut s'enregistrer quelque part?

----------

## kaworu

Il suffit de mettre dans l'en-tête de ton soft la licence, ça ressemble à ça :

```

 This program is free software; you can redistribute it and/or          

 modify it under the terms of the GNU General Public License           

 as published by the Free Software Foundation; either version 2

 of the License, or (at your option) any later version.                 

                                                                        

 This program is distributed in the hope that it will be useful,        

 but WITHOUT ANY WARRANTY; without even the implied warranty of         

 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the          

 GNU General Public License for more details.                           

                                                                        

 You should have received a copy of the GNU General Public License      

 along with this program; if not, write to the Free Software            

 Foundation, Inc., 51 Franklin Street, Fifth Floor,                     

 Boston, MA  02110-1301, USA.   

```

Si c'est un script, tu met ça dans l'en-tête, si c'est un projet, tu met un fichier LISENCE avec la GPL complète (ou ça) et une note dans le README par rapport à la licence. (ou directement dans le README).

mes 2 cents.

----------

## man in the hill

Salut,

Le mieux est tu contacts le FSF  france http://fsffrance.org/contact.fr.html et que tu demandes des précisions et qques conseils (chacun son boulot   :Very Happy: ... ).

                                                                          @+

----------

## ghoti

 *kaworu wrote:*   

> la GPL "garanti" qu'on ne peut faire d'argent, car par exemple si je le redistribue en demandant rémunération, le client va se tourner vers qqn (par exemple toi) qui le redistribue gratuitement.

 

Au contraire, la GPL n'interdit pas de faire de l'argent (Cite-moi un texte qui prouverait cette interdiction !).

En pratique, tu as cependant raison : pourquoi payer alors qu'on peut l'avoir gratuit chez le gars d'à côté et de manière tout-à-fait légale ...

Il n'en reste pas moins que si je vends le logiciel de il turisto publié sous gpl, celà restera parfaitement légal !

Si il turisto veut interdire qu'on fasse de l'argent avec son logiciel, il doit passer par une licence propriétaire (ou bien créer sa "propre" licence libre ... )

Mais utiliser la GPL dans ce cas-là serait une erreur !

http://www.linux-france.org/article/these/gpl.html : 

 *GPL - Préambule wrote:*   

> Liberté des logiciels ne signifie pas nécessairement gratuité. Notre Licence est conçue pour vous assurer la liberté de distribuer des copies des programmes, gratuitement ou non, de recevoir le code source ou de pouvoir l'obtenir, de modifier les programmes ou d'en utiliser des éléments dans de nouveaux programmes libres, en sachant que vous y êtes autorisé.

 

(Quand je vous disais que les trolls se réveillaient !  :Laughing: )

----------

## titoucha

Chut ne le réveille pas il est bien ou il est.

Pour recentrer le sujet, c'est pour quand la phase de béta test du script   :Very Happy: 

----------

## Il turisto

Ah c'est pas trop loin je pense.

Ce matin dans le train j'ai finit de débugguer une partie qui déconnait dans le site.

Il va falloir que je modifie encore un peu côté web et je pense que l'on arrivera à quelque chose de presque potable (une version 0.0.1 pre alpha  :Smile:  ).

Bon pour ma licence je n'ai pas eu de réponses de fsffrance

----------

## kaworu

@ gothi :

t'as tout à fait raison. je voulais juste dire qu'en pratique, c'est quand même difficile..

@ Il turisto :

Si t'as besoin d'aide, chuis en vacances ^____^

----------

## Il turisto

C'est bien gentil Kaworu mais jusque la ca va.

Le seul prob que je rencontre c'est la licence. C'est ce qui va ralentir le plus la version 0.1.

Peut être pourrais tu y regarder?

----------

## PabOu

petite découverte :

```
pabou@chocolat ~ $ time qlop -t baselayout

baselayout: 51 seconds average for 26 merges

real    0m0.041s

user    0m0.019s

sys     0m0.006s

pabou@chocolat ~ $ time qlop -g baselayout

baselayout: Thu Apr 21 04:49:03 2005: 41 seconds

baselayout: Mon Apr 25 06:48:01 2005: 60 seconds

baselayout: Thu Apr 28 01:12:30 2005: 41 seconds

baselayout: Mon May  2 22:22:36 2005: 44 seconds

baselayout: Fri Jun 24 08:07:24 2005: 38 seconds

baselayout: Mon Sep 19 07:21:29 2005: 109 seconds

baselayout: Thu Oct 27 20:32:35 2005: 47 seconds

baselayout: Wed Nov  9 07:48:15 2005: 146 seconds

baselayout: Sun Dec 25 03:09:46 2005: 96 seconds

baselayout: Sun Jan  8 20:01:58 2006: 89 seconds

baselayout: Wed Jan 18 16:36:45 2006: 74 seconds

baselayout: Wed Feb  1 01:00:06 2006: 33 seconds

baselayout: Thu Feb 23 12:50:33 2006: 32 seconds

baselayout: Tue Mar  7 00:39:20 2006: 71 seconds

baselayout: Sun Apr  9 04:56:28 2006: 23 seconds

baselayout: Tue Apr 11 12:00:17 2006: 26 seconds

baselayout: Wed Apr 12 11:59:00 2006: 34 seconds

baselayout: Thu Apr 13 09:31:37 2006: 35 seconds

baselayout: Sun Apr 23 02:00:16 2006: 52 seconds

baselayout: Tue May  2 13:40:58 2006: 37 seconds

baselayout: Wed May  3 18:16:54 2006: 82 seconds

baselayout: Tue May  9 22:50:49 2006: 32 seconds

baselayout: Sun May 28 20:05:52 2006: 27 seconds

baselayout: Wed Jul  5 20:10:17 2006: 33 seconds

baselayout: Thu Jul  6 02:31:09 2006: 25 seconds

baselayout: Thu Jul  6 20:00:26 2006: 17 seconds

baselayout: 26 times

real    0m0.187s

user    0m0.023s

sys     0m0.005s

```

qlop fait partie du paquet : 

```
pabou@chocolat ~ $ qfile qlop

app-portage/portage-utils (/usr/bin/qlop)

```

----------

## Il turisto

Sympa qlop. Pour le moment je me base sur genlop et j'ai fais le truc en bash mais je me disais que je le recoderais bien en c pour gagner en performances ...

----------

## mornik

Très interressant ton sujet. Perso je suis pas totalement d'accord avec vous sur certains points (et donc totalement en phase sur d'autres points  :Wink:   )

Pour moi il faut isoler 3 types de machines :

portable

bureau

server

Car dans les 3 cas l'architecture (enfin les pieces) changent beaucoup et les perfs sont très influencées.

Ensuite pour chaque catégorie il faut, à mon avis, définir des profils par version de gcc (je parle de versions majeures, pas des rc)

Et enfin on peut faire par cpu. (voir par quantité de ram, mais je suis pas sur de l'interet, à mesurer)

Chaque personne peut donner des chiffres selon ces critères.

Ensuite on fait un bete calcul statistiques et on a une moyenne. Plus il y aura de participants plus le chiffre sera fiable. (voir la droite de regression linéaire dans un nuage de point).

On pourrait utiliser un simple fichier pour paramétrer le script.

Enfin c'est juste une idée, j'espère ne pas avoir redit trop de choses déjà vues, ni casser le moral de l'initiateur du projet avec mes réflexions à la c..n.

----------

## Il turisto

Casser le moral c'est pas possible.

Ca ne fais qu'augmenter mon envie de la faire.

Pour le moment étant un script bash les options sont définies en haut de script.

Je me base sur genlop mais celui à des problèmes.

Exemple :

Faites chez vous :

genlop xterm

genlop xterm-207

genlop x11-terms/xterm-207

Si vous avez ce xterm (je pense que oui) vous verrez que genlop réagit parfois bizarrement et cela pose des problèmes que j'ai contounré mais cela n'est pas assez propre pour me plaire.

Alors je ne sais pas encore quoi faire.

Sinon niveau licence je n'ai de news de personnes  :Sad: .

Que pensez vous de l'idée de mornik?

Selon moi : les serveurs n'ont pas toujours du matériel spécifique et quand bien même ce serait le cas ... on parle ici de sbu. 1 sbu de 1 minute = 1 sbu de 1 minute et cela qu'elle que soit l'architecture et/ou le matériel.

Certe un programme 64bits doit etre plus long/court a compiler qu'un 32 mais est ce que cela gêne notre approximation?

Sinon pour le nom du programme j'ai lu qu'on ne pouvait pas utiliser le nom de gentoo dans son nom. Qu'en est il du mot emerge?

----------

## mornik

Vivement que je puisse l'essayer   :Laughing: 

Dans tout les cas d'ici 1heure je regarde ce truc de genlop.

----------

## Il turisto

Comme je l'ai dis dès que j'ai la licence je release la 1ère version. Actuellement en bash et surement bugguée.  :Smile: 

----------

## Magic Banana

Je ne comprends pas ton problème avec la GPL. Du moment que toi tu donneras gratuitement le logiciel, personne ne va le vendre (faut etre tordu pour aller prendre un logiciel à quelqu'un qui n'en ai pas l'auteur et qui veut le faire payer alors qu'il est disponible gratuitement auprès de son auteur).

De plus, quiconque apportera des modifications au logiciel sera obligé, pour le publier (mais tu ne peux pas l'obliger à publier), de garder la licence GPL. Donc pas de problème pour aller récupérer ses sources modifiées et les donner gratuitement.

----------

## man in the hill

 *Il turisto wrote:*   

> Pour le moment étant un script bash les options sont définies en haut de script.
> 
> Je me base sur genlop mais celui à des problèmes.
> 
> Exemple :
> ...

 

Je ne vois pas ce que tu veux dire car si tu utilises genlop sans l'option  -t , tu n'as pas les temps...donc développe un peu...

 *Il turisto wrote:*   

> Que pensez vous de l'idée de mornik?
> 
> Selon moi : les serveurs n'ont pas toujours du matériel spécifique et quand bien même ce serait le cas ... on parle ici de sbu. 1 sbu de 1 minute = 1 sbu de 1 minute et cela qu'elle que soit l'architecture et/ou le matériel.
> 
> Certe un programme 64bits doit etre plus long/court a compiler qu'un 32 mais est ce que cela gêne notre approximation?

 

Pour moi, c'est le sbu qui compte et permet de donner le temps ds autres apps...Par contre le problème de mémoire soulevé par PaBOu reste ne suspend  en fonction des tests qu'il faudra effectuer pour être sûr de ce côté...

 *Il turisto wrote:*   

> Sinon pour le nom du programme j'ai lu qu'on ne pouvait pas utiliser le nom de gentoo dans son nom. Qu'en est il du mot emerge?

 

Tu n'as qu'a l'appeller timeto (sous entendu "time to emerge paquet", c'est sûr que cela ne sonne pa terrible en fr mais en english  ça le fait...

                                                                                      @+

----------

## _Seth_

Est ce que vous avez vu qu'un des "étudiants" du google summer of code de chez Gentoo travaille sur la mise en place d'un nouveau gentoo-stats ?

Apparemment, il se concentre plus sur la mise en place d'une pateforme qui permettrai de savoir combien de personnes ont testé un paquet (donc améliorer la fiabilité des tests et étendre le nombre de testeurs). Blog sur Planet-Gentoo : appel à testeur pour sa plateforme.

Le point commun avec ce thread, c'est que l'ancien gentoo-stat proposait justement une évaluation du temps d'emerge de chaque paquet (je crois que ça a été signalé au début de cette discussion). Donc cela pourrait peut être intéresser le dev qui s'en occupe (Marius Mauch) d'integrer ce genre de calculs probabilistes   :Smile:   sur gentoo-stats.

----------

## Il turisto

[quote="man in the hill"] *Il turisto wrote:*   

> Pour le moment étant un script bash les options sont définies en haut de script.
> 
> Je me base sur genlop mais celui à des problèmes.
> 
> Exemple :
> ...

 

Je sais que sans le -t on a pas le temps. Mais essaye les commandes du dessus. Tu verras.

----------

## ghoti

 *Il turisto wrote:*   

> Pour le moment étant un script bash les options sont définies en haut de script.
> 
> Je me base sur genlop mais celui à des problèmes.
> 
> Exemple :
> ...

 

Et quels problèmes vois-tu ?

Si tu parles de l'erreur renvoyée par la seconde ligne, c'est absolument normal : elle n'obéit pas à la syntaxe de genlop :

 *man genlop wrote:*   

> SYNTAX
> 
>        name is the name of a gentoo ebuild, it may be supplied in the form of:
> 
>               ebuild (eg. genlop)
> ...

 

Tu ne peux pas indiquer la version du package sans renseigner la catégorie.

----------

## Il turisto

Oui c'est la syntaxe mais dans mon script cela pose un problème mais ce n'est pas grave.

Je dois avoir attaqué le problème du mauvais côté.

En fait je demande a gelop la liste des packages installés (enfin présent dans le log).

Et après j'enlève le numéro de version et pour chaque paquet je lui demande les temps de compilo...

----------

## Il turisto

J'ai une question la :

Quand on fais un emerge world emerge se sert de ce fichier : /var/lib/portage/world

Mais ou va t'il chercher les autres paquets?

En gros dans quels fichiers puis-je trouver le liste de tout les paquets installés?

----------

## mornik

Les paquets qui ne sont pas dans le world sont retrouvés par dépendance non ?

----------

## Magic Banana

Oui, il me semble. D'ailleurs une faÃ§on de voir tous les paquets installÃ©s sur ton ordinateur (tout du moins avec une usage "normal" de portage) est de rentrer cette commande :

```
emerge --pretend --empty-tree world
```

Je crois que cette commande va voir dans /var/lib/portage/world les paquets installÃ©s et, supposant que rien n'est installÃ©, te donne toutes les dernier logiciels (dÃ©pendances incluses) pour avoir ce world (en fonction bien sur des USE, package.mask & co.). Si tu as fait un "emerge -uDN world" juste avant, il s'agit donc exactement de ce qui installÃ© sur ton nordi.

----------

## Il turisto

oui je connaissais le emerge -pe world

mais le soucis c'est qu'il renvoie les numéros de versions avec :

```

[ebuild  N    ] dev-cpp/gtkmm-2.8.3

[ebuild  N    ] dev-cpp/libglademm-2.6.2

[ebuild  N    ] dev-cpp/gconfmm-2.12.0

```

Mais bon c pas grave je vais faire avec.

Sinon pour qlop pour certains paquets il ne me renvoie pas le même résultats que genlop.

Par exemple genlop vois 5 compilations de eclipse-sdk ce qui est correct.

qlop n'en voit que 4.

----------

## yoyo

Perso, j'utiliserai "qlist" du paquet "app-portage/portage-utils" :

```
qlist

Usage: qlist <pkgname> : list files owned by pkgname

Options: -[ISUDeadosvqChV]

  -I, --installed      * Just show installed packages

  -S, --slots          * Display installed packages with slots

  -U, --umap           * Display installed packages with flags used

  -D, --dups           * Only show package dups

  -e, --exact          * Exact match (only CAT/PN or PN without PV)

  -a, --all            * Show every installed package

  -d, --dir            * Only show directories

  -o, --obj            * Only show objects

  -s, --sym            * Only show symlinks

  -v, --verbose        * Make a lot of noise

  -q, --quiet          * Tighter output; suppress warnings

  -C, --nocolor        * Don't output color

  -h, --help           * Print this help and exit

  -V, --version        * Print version and exit
```

Avec l'argument "-I" le résultat est instantané (contrairement au emerge --pretend --empty-tree world) car il utilise le cache de portage (il me semble) mais sans avoir les versions.

Mes 0.02 cents

PS : il y a plein d'outils puissants et pratiques dans "app-portage/portage-utils".

----------

## Il turisto

qlist est exactement ce que je cherchais. 

Merci bcp  :Smile: 

Tes 0.02 cents valent bcp à mes yeux sur ce coup la.

----------

## PabOu

tu peux retrouver tous les paquets installés dans /var/db/pkg

----------

## Il turisto

oui cela je l'avais vu.

Je fais m'en tenir a qlist.

C rapide et précis  :Smile: .

Bon je pars dans une réécriture complète du script car le premier coup d'essai n'est pas terrible.

Sinon tjs rien pour une licence possible? Les autres progs de gentoo ne sont pas tous en gpl. Y'a aussi as-is, ...?

----------

## Il turisto

Bon le script avance toujours et est presque prêt pour une première beta.

Alors ma question est la suivante : je pense que la licence qui correspondrait le mieux est la cc nc (creative commons non commercial) mais est ce que cette licence est applicable à un soft?

Est ce toujours dans la philosophie gentoo?

edit : http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

edit2 : je pense être prêt pour une beta. reste tjs la licence ...

----------

## Il turisto

Est ce qu'un modo pourrait locker ce post svp ???

La suite se trouve ici :

https://forums.gentoo.org/viewtopic-p-3487907.html#3487907

----------

