Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Emerge] mode silencieux
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
E11
l33t
l33t


Joined: 24 Feb 2004
Posts: 764
Location: Bruxelles

PostPosted: Fri Oct 27, 2006 10:01 pm    Post subject: [Emerge] mode silencieux Reply with quote

Bonjour,

Mon anglais n'étant pas très bon, j'ai décidé de m'exprimer en français.

Ayant de plus en plus l'habitude de voir des textes ordonnés sous gentoo - comme quand mon ordinateur démarre ou qu'il compile un kernel 2.6 -, je me suis demandé si ce ne serait pas plus agréable/confortable d'avoir la même chose avec emerge.

En effet, je proposerais qu'emerge se voie de cette façon quand on installerait un programme :

Code:
 >~ emerge xxxxx
Calculating dependencies  [ ok ]
Downloading xxxxx.tar.gz
    [======>                    ]   {Size-Speed-Time-...} [ ok ]
Checking xxxxxxx    [ ok ]
Unpacking source    [ ok ]
Compiling    [ \ ] (it is busy - like for calculating depencies) and [ ok ] when it's done.
...
xxxx is succesfully installed on your computer
Avec tous les [ ok ] sur la droite de l'écran (comme au démarrage).

Ce n'est évidement qu'un exemple et ceci pourrait n'être qu'une option dans emerge.

Pour la compilation, on pourrait aussi avoir une barre de progression, mais vu la complexité de la chose, je crois que ça n'apporterait que peu d'avantage.

Voilà, ce n'est qu'une proposition et vos avis sont évidements les bien venus !

E-11
Back to top
View user's profile Send private message
kopp
Advocate
Advocate


Joined: 09 Apr 2004
Posts: 2885
Location: Grenoble, France

PostPosted: Fri Oct 27, 2006 10:40 pm    Post subject: Reply with quote

Salut E11 !
Tu fais remarquer quelque chose, je viens effectivement de regarder la sortie d'un emerge --quiet, et bien, je le trouve plutôt bavard l'emerge :)
Pour ce qui est de ta proposition, ça semble une bonne idée et plutot réalisable. Je pense que rediriger la sortie de portage vers un fichier pourrait aider pas mal, tout en permettant de récuperer l'erreur si la compilation plante. Maintenant je ne connais pas en détail le fonctionnement de portage, il faut voir s'il peut rediriger autant de truc et afficher les nouvelles informations proposées.
Il faut aussi déterminer comment on traite les messages d'emerge, comme les conseils d'utilisation etc (affichés avec une asterisque verte ou jaune selon la nature du message) On les redirige vers un fichier aussi ? ou bien vers la sortie, ce qui _salit_ la belle présentation.
Pour l'estimation du temps, le probleme, c'est que c'est plutot difficile à estimer car même au noombres de fichiers compilés, ça n'a pas de réelle signification. La possibilité d'utiliser les temps des compilations précédentes serait une idée, avec l'utilisation de genlop (qui imposerait soit une dépendance à portage, soit une vérification de présence à chaque fois.) mais la précision reste assez foireuse, il suffit d'une recompilation du même paquet pour faire chuter la moyenne.
Il reste à voir ce qu'en pense les développeurs, et les propositions des autres utilisateurs quant aux problèmes évoqués.

OK, here is a quick sum up.
E11 stated that even the --quiet mode of emerge pulls out a lot of text output, and he'd like to have an emerge output in the likes of others system output like the init scripts output, as shown in his example. The second point is adding an ETA of the merge.
My answer is: the idea is good, and sounds feasible to my programmation agnostic eyes. Doing the additional output should be easy, I think. But there are some things we must consider. First, we can redirect the output of ./configure and make etc, but we must keep it easily accessible in the case the build fails. So maybe redirecting the output to a file. Then we must consider Portage messages/informations (I think it's the elog things in ebuild) : what to with it ? Cutting them off would surely have desastrous effects, but displaying them would ruin all the new output idea. Those points must be defined.
Concerning the ETA, the fact is there are no way to guess the time needed. The only way is to guess it based on previous build times, but it eithers requires to mod portage to do what genlop does, which implies a dependency on genlop or a check for genlop at each build. It may prove quite painful.
So, what's your take on it ?

EDIT : I just want to add this: feel free to participate in english or french, I can make translations so the discussion can be enjoyed by both french and english speaking people.
Back to top
View user's profile Send private message
nico_calais
l33t
l33t


Joined: 09 Jun 2005
Posts: 628
Location: Saint Julien en Genevois

PostPosted: Tue Nov 14, 2006 3:53 pm    Post subject: Reply with quote

Quote:
Pour l'estimation du temps, le probleme, c'est que c'est plutot difficile à estimer car même au noombres de fichiers compilés, ça n'a pas de réelle signification. La possibilité d'utiliser les temps des compilations précédentes serait une idée, avec l'utilisation de genlop (qui imposerait soit une dépendance à portage, soit une vérification de présence à chaque fois.) mais la précision reste assez foireuse, il suffit d'une recompilation du même paquet pour faire chuter la moyenne.
Il reste à voir ce qu'en pense les développeurs, et les propositions des autres utilisateurs quant aux problèmes évoqués.



Here's an exemple of a genlop

Code:
Fri Sep  1 05:02:21 2006 >>> sys-libs/glibc-2.4-r3
       merge time: 1 hour, 30 minutes and 49 seconds.

     Fri Sep 29 23:26:16 2006 >>> sys-libs/glibc-2.4-r3
       merge time: 1 hour, 28 minutes and 15 seconds.

     Thu Oct 26 11:57:20 2006 >>> sys-libs/glibc-2.4-r3
       merge time: 1 hour, 47 minutes and 33 seconds.


As you can see, it definitely can't be used to estimate the compile time.
_________________
"Unix IS user friendly... It's just selective about who its friends are." — Tollef Fog Heen tollef@add.no
Back to top
View user's profile Send private message
kopp
Advocate
Advocate


Joined: 09 Apr 2004
Posts: 2885
Location: Grenoble, France

PostPosted: Tue Nov 14, 2006 4:20 pm    Post subject: Reply with quote

It can be used to estimate using the mean compile time and give some hints, like: it's going to take 5 minutes, or it's going to take at least one and a half hour, just as genlop -c does. But I agree estimates might be quite wrong depending on previous compil times.
For example : rebuilding a package changing some useflag :
Code:
     Fri Oct 20 14:28:34 2006 >>> www-client/mozilla-firefox-1.5.0.7
       merge time: 19 minutes and 15 seconds.

     Sat Nov  4 11:42:46 2006 >>> www-client/mozilla-firefox-2.0
       merge time: 19 minutes and 49 seconds.

     Sat Nov  4 12:20:51 2006 >>> www-client/mozilla-firefox-2.0
       merge time: 7 minutes and 19 seconds.


As you can see, between 1.5.0.7 and 2.0, compil time is almost the same, but on the recompilation of 2.0, it becomes less than half the time.
Maybe filtering times to have a small variance...
Back to top
View user's profile Send private message
richfish
Apprentice
Apprentice


Joined: 03 Mar 2006
Posts: 202
Location: Phoenix, AZ

PostPosted: Thu Nov 16, 2006 4:32 am    Post subject: Reply with quote

I *really* like the idea of having just "Emerging cate-gory/package ..... [ok]" style output. That just sounds sexy!

As far as the ebuild output goes, it can all be redirected to $PORTAGE_TMPDIR/cate-gory/package/emerge-output.txt IMO. Most users don't have much of a clue what any of that means anyway. The ELOG features can already redirect the most important instructions/messages to other locations, such as /var/log/portage/elog/. It might be nice to rework things a bit to dump it after each package gets merged, so something like:
Code:
Emerging cate-gory/package1-v.ers.ion....[ok]
>>> some important instructions here
>>> probably involving a revdep-rebuild
>>> and maybe a service restart.
Emerging cate-gory/package2-ve.rs.ion...[ok]
Emerging cate-gory/package3-ver.sion...[failed]
>>> emerge failed, see /var/tmp/portage/cate-gory/package3/emerge-output.txt


kopp wrote:

Concerning the ETA, the fact is there are no way to guess the time needed. The only way is to guess it based on previous build times, but it eithers requires to mod portage to do what genlop does, which implies a dependency on genlop or a check for genlop at each build. It may prove quite painful.


CMake builds (like KDE4) will include a build progress indicator in the output. It seems like it should be possible to parse this output to estimate the time remaining based on the elapsed time and the percentage complete. But otherwise, yeah, I think a generalized solution would be nigh impossible, especially considering the effects of USE, CFLAG, and MAKEOPTS changes on compile times.
Back to top
View user's profile Send private message
E11
l33t
l33t


Joined: 24 Feb 2004
Posts: 764
Location: Bruxelles

PostPosted: Sat Nov 18, 2006 5:05 pm    Post subject: Reply with quote

richfish wrote:
I *really* like the idea of having just "Emerging cate-gory/package ..... [ok]" style output. That just sounds sexy!

:-)

richfish wrote:
CMake builds (like KDE4) will include a build progress indicator in the output. It seems like it should be possible to parse this output to estimate the time remaining based on the elapsed time and the percentage complete. But otherwise, yeah, I think a generalized solution would be nigh impossible, especially considering the effects of USE, CFLAG, and MAKEOPTS changes on compile times.


I think a simple progress bar would be really good even if we don't know the ETA explicitly, because we could know which stage of the installation emerge is at. Indeed if we read emerge is at 10% after one houres we know the installation will be long... but if we read 87% after the same time, we know that the end is soon... and it can be very useful !
For example I often had to stop emerge because I needed all the ressources of my computer. But if I knew that emerge was at 90% I would wait the time emerge needed to finish... but like I don't know it I stop it and have to emerge it again later...

PS : sorry for my english... I'm still a noob to write it...


Last edited by E11 on Sat Nov 18, 2006 7:23 pm; edited 1 time in total
Back to top
View user's profile Send private message
kopp
Advocate
Advocate


Joined: 09 Apr 2004
Posts: 2885
Location: Grenoble, France

PostPosted: Sat Nov 18, 2006 6:56 pm    Post subject: Reply with quote

Ok, your english is not so bad.
Clearly, a progress bar will help, give some hints about progression. We just have to wait for CMake to become mainstream, which is unlikely to happen so soon.
As for stopping emerge when you need all system ressources, you can go with ctrl-z to pause it, then use fg to start it again.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Sep 02, 2007 7:36 am    Post subject: Reply with quote

richfish wrote:
I *really* like the idea of having just "Emerging cate-gory/package ..... [ok]" style output. That just sounds sexy!

Ah go on, try update ;)

Edit: re: timing we were thinking to add qlop -Ht output. (emerge portage-utils) Real problem is that it includes times from failed emerges too.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum