# quietemerge -- provide pretty emerge output

## ppurka

Updates (reverse chronological order)

Do let me know if you find any bugs. This script is pretty much going into a maintenance stage since I can't think of any more features to add. Adding --jobs was the most difficult for me, but now that is done, and the script is stable. I would like to keep it stable which implies I should leave it as it is.

Note (15 Mar 2015): Google Code is dead. But this script has been on GitHub for quite a few years already. So, no worries  :Smile: 

20 Dec 2014: Version 20141220.Fix breakage due to changed emerge output.05 Feb 2014: Version 20140205.Small update to change the color of time taken.27 Apr 2013: Version 20130427.Small update for new make.conf location.13 Apr 2012: Version 20120413.Small update to catch new emerge message.06 Apr 2012: Version 20120406.Bugfix: Squash two rusty old bugs.29 Jan 2012: Update zsh-completion instructions.15 Jan 2012: Version 20120115.Bugfix: Reintroduce -q30 Dec 2011: Version 20111230.Bugfix: Fix an infinite recursion.24 Dec 2011: Version 20111224. Execute emerge directly on unsupported args. Fixed some bugs.27 Nov 2011: Version 20111127. Show additional total ETA without binary emerge.13 Nov 2011: Version 20111113. Remove -q from emerge command.27 Aug 2011: Version 20110827. Small bugfixes.26 Jun 2011: Version 20110617. Bugfix for --autounmask-write. Remove references to genlop on this post.11 Jun 2011: Version 20110611. Support for --autounmask-write.21 May 2011: Version 20110521. Mainly one bug fix when SHOW_MERGE_TIME=120 May 2011: Version 20110520. with --jobs support and some bug fixes. Updated screenshot and usage below30 Apr 2011: Update to version 20110430.Should detect --color=n in command line now. Also bug fix for --resume. Updated screenshot.22 Apr 2011: Version 20110422. Use own genlop function and remove genlop dependency.07 Apr 2010: Version 20100407. Support for a pre-command and a post-command.19 Jan 2010: Version 20100119. Support for multiple quietemerge instances.22 Dec 2009: Update to version 20091222  :Smile: 02 Dec 2009: Allow environment variable to override config file setting.21 Nov 2009: Some bug fixes and some security fixes.20 Nov 2009: Respect --ask in EMERGE_DEFAULT_OPTS.12 Nov 2009: Updated to version 20091112. Some bug fixes and some features  :Smile: 05 Nov 2009: Workaround the bug in genlop. Again.   :Confused: 02 Nov 2009: New config option. SHOW_MERGE_TIME. Set it to 1 to see the merge time for the package instead of "Done!"

Updated this version to workaround genlop bug.30 Oct 2009: One (not so obvious) bug fix.29 Oct 2009: Version 20091029; support for --keep-going; numerous other changes.26 Oct 2009: Include infon from a different script.23 Oct 2009: New version with compatibility with --ask option of emerge; updated screenshot17 Oct 2009: Added bash completion instruction. Updated zsh completion instruction.

Brief Description: 

I am providing this script on a request at the monthly screenshot thread. What this script does is provide a nice timer, while emerging packages. An example screenshot is present in http://oi51.tinypic.com/1ze820g.jpg

How it works: 

The script first checks if the emerge process will proceed properly, by doing a emerge --pretend. If the emerge process was successful, then the script launches emerge via 

```
emerge <rest of the command line options> 2>&1 > output_file &
```

Since --quiet-build is now the default in emerge, this script now doesn't launch emerge as emerge -q.

The program then repeatedly checks the output of emerge in output_file for updates and accordingly provides an updated terminal output.

Usage: 

The script should be run simply as if you were running emerge. To facilitate a nice output as shown in the screenshot, it is recommended to not use emerge options such as -c, -C, --sync. The script itself takes no arguments other than -h or --help and passes all the rest of the arguments to emerge. 

If the script detects any unsupported arguments, then it simply executes emerge directly, bypassing all the other setup in the script.

This is a bash script and its compatibility with other shells is unknown. It will definitely produce tons of errors if called as some other shell. So you can either make the script executable (chmod 755 quietemerge) and then just run it as quietemerge, or run it as bash quietemerge.

In order to temporarily override the settings present in the config file, prepend the variable with an underscore _ and provide it as an environment variable.

An example where I want to override the config file setting temporarily, and/or provide a temporary setting:

```
 _DELAY=2 _MOUNT_TMPFS=1 quietemerge -a eselect
```

Download: 

You can download the script from: https://github.com/ppurka/quietemerge/releases/download/20141220/quietemerge-20141220.tar.gz

You can copy the file quietemerge after extracting it from the tarball.

The files have also been added retroactively to a git repository: http://code.google.com/p/quietemerge/source/list

Installation: 

Copy the script to some directory which is in $PATH of root. Personally, I have it installed in /usr/local/sbin.

Dependencies: 

Till version 20100407: The script depends on app-portage/genlop.

From version 20110422: No dependency on genlop.

Configuration: 

The script creates a configuration file $HOME/.config/quietemerge.config. It is not mandatory to modify that file,- I have tried to keep the defaults sane. However, if you want to mount tmpfs on to /var/tmp/portage or run your favourite config update utility after emerge is over, I would suggest looking at the configuration file.

zsh completion configuration:

If you use zsh, then you can perform the following steps to enable command line autocompletion of quietemerge in zsh. 

New instructions for zsh completion:Install zsh-completion:

```
emerge zsh-completion
```

Add the following line to the beginning of your $HOME/.zshrc

```
[[ -f /etc/zsh/zprofile ]] && . /etc/zsh/zprofile
```

Enable completion by running these commands

```
echo "compdef quietemerge=emerge" >> $HOME/.zshrc

exec zsh
```

Old Instructions for zsh completion:

Install zsh-completion:

```
emerge zsh-completion
```

Add the following line to the beginning of your $HOME/.zshrc

```
[[ -f /etc/zsh/zprofile ]] && . /etc/zsh/zprofile
```

 Create a directory /etc/zsh/zsh-functions

 Enable this new zsh completion path:

```
echo "fpath=( /etc/zsh/zsh-functions \$fpath )" >> /etc/zsh/zprofile
```

 Download  _quietemerge and copy it to /etc/zsh/zsh-functions

 Run the commands

```
env-update

exec zsh
```

Bash completion configuration:

Command line completion of quietemerge in bash can be achieved by executing the following steps.Install and configure gentoo-bashcomp

```
emerge gentoo-bashcomp

eselect bashcomp enable --global base

eselect bashcomp enable --global gentoo
```

Add the following two lines to the end of your $HOME/.bashrc

```
[[ -f /etc/profile.d/bash-completion.sh ]] && source /etc/profile.d/bash-completion.sh

complete -o filenames -F _emerge quietemerge
```

Run the command

```
exec bash
```

Website: http://code.google.com/p/quietemerge/ ( needed some place to host the file  :Razz:  )

Git: 1. On Google Code.  2. On Github

README: 1. On Google Code. 2. On Github.

Version: 20141220

----------

## evert_

Thanks for all the work you've put into posting this  :Smile: . I'm going to test it tonight.

Used it for a few merges now and I'm very happy with it, no bugs yet  :Smile: . Altough there are a few 'features' i would love to see: see how many merges are going to happen. Also, it's in my opinion very scary to do 'the shot in the dark' emerge -uDN world, would it be possible to make it display first what packages with the --ask?  :Smile: .

----------

## ppurka

 *evert_ wrote:*   

> Thanks for all the work you've put into posting this . I'm going to test it tonight.
> 
> Used it for a few merges now and I'm very happy with it, no bugs yet . Altough there are a few 'features' i would love to see: see how many merges are going to happen. Also, it's in my opinion very scary to do 'the shot in the dark' emerge -uDN world, would it be possible to make it display first what packages with the --ask? .

 Interesting. I will give it some thought on how to introduce these features. Give me a couple of days. I will try to script it in the weekend.

My main objective is to have no arguments for the script itself (except -h). All the arguments should be exactly the same as you give to emerge.

EDIT: By the way, you do get the total number of merges, the current merge number and the total time left. Look at your terminal titlebar  :Wink: 

----------

## jprobichaud

Hi, 

Since this [great] tool relies on genlop, you might be interested to take a look at this bug.  I've submitted a patch so that "genlop -p" is faster at estimating the time emerging a large set of packages should take.

Cheers!

----------

## ppurka

 *jprobichaud wrote:*   

> Hi, 
> 
> Since this [great] tool relies on genlop, you might be interested to take a look at this bug.  I've submitted a patch so that "genlop -p" is faster at estimating the time emerging a large set of packages should take.
> 
> Cheers!

 Very nice  :Very Happy: 

I know that genlop -p takes significant time. That is why I don't call genlop -p everytime,- it is run only when a new package is being emerged and then it updates the terminal's window titlebar with the total estimated time left. What runs in a loop is genlop -c.

I hope your patch gets accepted. That way everyone will benefit  :Smile: 

This is one reason why I run emerge in the background. So, the emerge process runs independently of the time estimating process (genlop). After all, we also care about how quickly the emerge process finishes instead of just some pretty output. I am sure no one would want pretty output if it delayed emerge.  :Razz: 

PS: I completed writing the code to take care of --ask last weekend, but I didn't get the opportunity/time to test it completely. I will test it by this weekend and release it after that.

----------

## Bones McCracker

Nice work, ppurka.   :Smile: 

----------

## jprobichaud

 *ppurka wrote:*   

> 
> 
> PS: I completed writing the code to take care of --ask last weekend, but I didn't get the opportunity/time to test it completely. I will test it by this weekend and release it after that.

 

Will we see the actual estimated time before we can say "yes"?

----------

## ppurka

 *BoneKracker wrote:*   

> Nice work, ppurka.  

 Thank you  :Smile: 

 *jprobichaud wrote:*   

>  *ppurka wrote:*   
> 
> PS: I completed writing the code to take care of --ask last weekend, but I didn't get the opportunity/time to test it completely. I will test it by this weekend and release it after that. 
> 
> Will we see the actual estimated time before we can say "yes"?

 I hadn't thought of that! Good idea. I will include this too (It should be quite easy to provide this estimate). However, I think I will provide only the total time and not time for each package since the latter will be a complete beast.

----------

## jprobichaud

 *ppurka wrote:*   

> I think I will provide only the total time and not time for each package since the latter will be a complete beast.

 

Actually, if you take the patched version of genlop, you almost have it for free:

```

$ emerge $(eix -I -C kde --format "<category>/<name>\n" | grep -v Found) -pv --nodeps | genlop -pq

/* the emerge pretend output */

                       akonadi [     3m 35s]                                                                                                                     

                     akregator [     1m 55s]                                                                                                                     

                           ark [     1m  3s]                                                                                                                     

                       automoc [        16s]                                                                                                                     

                       dolphin [     1m 53s]                                                                                                                     

                  dragonplayer [        53s]                                                                                                                     

                       drkonqi [        54s]                                                                                                                     

                      gwenview [     1m 57s]                                                                                                                     

                           juk [     1m 45s]                                                                                                                     

                  kaddressbook [     3m 37s]                  

...

```

----------

## ppurka

Updated quietemerge to version 20091023. Updated screenshot available at http://omploader.org/vMmx0Zw

Changelog:Added compatibility with --ask. --verbose will also work (emerge itself takes care of this when it is piping to somewhere else).

Fixed bug with --resume ( fortunately, no one noticed  :Wink:  )

Total emerge time is given when --ask is used.As before, the script itself takes no options. All options are passed to emerge.

----------

## jprobichaud

oups, there is a little bug:

line 422, you have "infon ..." 

I guess that it should have been "info ...."

----------

## ppurka

 *jprobichaud wrote:*   

> oups, there is a little bug:
> 
> line 422, you have "infon ..." 
> 
> I guess that it should have been "info ...."

 Shoot! This is really bad! I forgot to include this function from my_bash_functions   :Evil or Very Mad: 

Updated version coming quickly.

----------

## ppurka

@jprobichaud Sorry I should have been more careful.

Update to version 20091026. Changelog:Include infon from a different script.

Now --pretend will also give you time remaining.

----------

## jprobichaud

The new version is pretty good.  

Thanks again ppurka for this great tool, it is really useful and even make emerge process enjoyable!

Cheers

----------

## jprobichaud

It seems that I'm hitting another potential bug:

```

  * Install  media-libs/speex-1.2_rc1.                                            Done!

  * Install  dev-perl/DBI-1.609.                                                  Done!

*** %n in writable segment detected *** Time left:             1 minute and 15 seconds.

  * Install  sys-apps/coreutils-7.5-r1.                                           Done!

  * Install  dev-perl/Locale-gettext-1.05-r1.                                     Done!

```

Any idea what this "%n in writable..." message means?

----------

## ppurka

 *jprobichaud wrote:*   

> It seems that I'm hitting another potential bug:
> 
> ```
> 
>   * Install  media-libs/speex-1.2_rc1.                                            Done!
> ...

 That is strange. I have no idea what that was   :Confused: 

I am using emerge and taking all stderr and stdout to /tmp/output.log. Can you check /tmp/output.log (if you still have it around) and check what is printing before the coreutils package? My script does not give any such output. 

It looks like some output from emerge perhaps overwrote the "Emerging <package>" region, just enough to keep the "Time left:" part alone. This must have happened with the coreutils package. Since emerge will spit out a newline and not erase the rest of the line (the "Time left:" part), my script will start printing from the next line. This makes it pretty certain that it is in the emerge of the coreutils package that that line is being printed. It also gives the time  :Wink: .. you had 1min and 15sec of coreutils emerge left. So, you can even run a normal emerge and see whether emerge spits out that line when around 1min and 15sec is left  :Very Happy:  Some command like this should suffice:

```
emerge -q coreutils 2>&1 > tmp.out
```

EDIT: I just tried it myself and I didn't get that output. So, it is specific to your system.

EDIT 2: Fix the emerge command redirection above. Saw the mistake after many hours  :Razz: 

----------

## jprobichaud

Sadly, I don't have the original /tmp/output/log, but I've follow your suggestion:

 *ppurka wrote:*   

>  Some command like this should suffice:
> 
> ```
> emerge -q coreutils 2>&1 > tmp.out
> ```
> ...

 

Which gives:

```

jrobicha@mt-gen-jprob ~ $ sudo emerge -q coreutils 2>&1 > tmp.out

*** %n in writable segment detected ***

jrobicha@mt-gen-jprob ~ $

```

If I don't redirect the output to tmp.out, I get:

```

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-apps/coreutils-7.5-r1

*** %n in writable segment detected ***

>>> Installing (1 of 1) sys-apps/coreutils-7.5-r1

 * Regenerating GNU info directory index...

 * Processed 181 info files.

```

I've removed the "-q" option to emerge and saved the Konsole output to see, within the entire emerge output, where that msg could come and I've found that it comes from the 'configure' section:

```

 26 ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --lo     calstatedir=/var/lib --libdir=/usr/lib64 --enable-install-program=arch --enable-no-install-program=groups,hostname,kill,su,uptime --enable-largefile --disable-libcap --enable     -nls --enable-acl --enable-xattr --without-gmp                                                                                                                                

  27 checking for a BSD-compatible install... /usr/bin/install -c

  28 checking whether build environment is sane... yes

  29 checking for a thread-safe mkdir -p... /bin/mkdir -p

  30 checking for gawk... gawk

  31 checking whether make sets $(MAKE)... yes

...

 340 checking whether printf supports the 'F' directive... yes

 341 checking whether printf supports the 'n' directive... *** %n in writable segment detected ***

 342 no

 343 checking whether printf supports the 'ls' directive... yes

 ...

```

I guess this isn't a bug with quietemerge  :Smile: 

----------

## ppurka

 *jprobichaud wrote:*   

> I guess this isn't a bug with quietemerge 

 Maybe it was. I am not sure.

New version 20091029. Changelog:Support for failed packages if --keep-going is used.

Change "Time Left" to "ETA",- it is shorter

Actually calculate the space required by the part after ETA:

Rewrite terminal title every $DELAY time, o/w emerge hijacks it

Use >& instead of 2>&1. Seem to get less overwrites (looks like my bash redirection understanding is flawed?)

Use separate tmp file for user and for root, and remove the file if emerge was successful.The --keep-going will look like this if a package failed:

```
-------------------------------- Starting emerge -------------------------------

  * Install  rox-base/rox-lib-2.0.5-r1.                                  Error! 

  * Skipped  rox-base/thumbs-0.1.4 due to --keep-going

  * Emerging app-admin/eselect-1.2.3. ETA:                                     
```

EDIT: Finally realised what I was doing wrong. I used emerge 2>&1 > output_file instead of emerge > output_file 2>&1. The order matters   :Exclamation:  Anyway, I am using the bashism emerge >& output_file in the latest version of the script. So it should be fine.   :Smile: 

----------

## ppurka

Version 20091030. Changelog: 

Just one bug fix: Remove the skipped package from tmp file so that the correct count and correct remaining time is given by genlop.

----------

## jw5801

Great script! I'm not sure if EWARN/ELOG and configuration file update messages are being handled nicely though? It looks to me as though a line has been dropped and the order rearranged a bit in the output below:

```
-------------------------------------------- Pretended emerge --------------------------------------------

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[ebuild     U ] dev-libs/apr-1.3.9 [1.3.8]

[ebuild     U ] app-admin/syslog-ng-3.0.4 [2.1.4] USE="pcre%* ssl%* -caps%" 

[ebuild     U ] net-mail/dovecot-1.2.6 [1.1.7-r1] USE="bzip2%* maildir%* zlib%* -caps% -cydir% -dbox% -sql

ite%" 

[ebuild     U ] dev-python/twisted-8.2.0-r2 [8.1.0]

[ebuild     U ] x11-libs/libgksu-2.0.12 [2.0.9]

                                           Total ETA: 8 minutes.                                          

  * Continue with the emerge process? ([Yes]|No): y

--------------------------------------------- Starting emerge --------------------------------------------

  * Install  dev-libs/apr-1.3.9.                                                                    Done! 

  * Install  app-admin/syslog-ng-3.0.4.                                                             Done! 

  * Install  net-mail/dovecot-1.2.6.                                                                Done! 

  * Install  dev-python/twisted-8.2.0-r2.                                                           Done! 

 * If you are upgrading from Dovecot 1.1, read 

 *  http://wiki.dovecot.org/Upgrading/1.2

  * Install  x11-libs/libgksu-2.0.12.                                                               Done! 

  * There are pending configuration updates:

 * manage the log files.  syslog-ng installs a file in /etc/logrotate.d

 * for logrotate to use.

 * Messages for package net-mail/dovecot-1.2.6:

 * GNU info directory index is up-to-date.

 * IMPORTANT: 4 config files in '/etc' need updating.

 * See the CONFIGURATION FILES section of the emerge

 * man page to learn how to update config files.

    See /tmp/output.log for more information.
```

The actual EWARN/ELOG messages for this upgrade were:

```
>>> Messages generated by process 6559 on 2009-10-31 14:06:19 EST for package app-admin/syslog-ng-3.0.4:

LOG: postinst

It is highly recommended that app-admin/logrotate be emerged to

manage the log files.  syslog-ng installs a file in /etc/logrotate.d

for logrotate to use.

>>> Messages generated by process 6559 on 2009-10-31 14:09:42 EST for package net-mail/dovecot-1.2.6:

WARN: install

If you are upgrading from Dovecot 1.1, read 

 http://wiki.dovecot.org/Upgrading/1.2
```

EDIT: Ah, I notice that /tmp/output.log contains the proper EWARN and ELOG messages.

EDIT2: Well, I wasn't using the latest version, I was using the 29th Oct version. I upgraded to the most recent version and emerged just syslog-ng to check what happens and it printed correctly, so either you fixed it in the update, or there were conflicts with having several messages to print in my earlier update.

```
----------------------------------------- Pretended emerge -----------------------------------------

These are the packages that would be merged, in order:

Calculating dependencies ... done!

[ebuild     U ] app-admin/syslog-ng-3.0.4 [2.1.4] USE="pcre%* ssl%* -caps%" 

                                   Total ETA: less than a minute.                                   

------------------------------------------ Starting emerge -----------------------------------------

  * Install  app-admin/syslog-ng-3.0.4.                                                       Done! 

  * There are pending configuration updates:

 * Messages for package app-admin/syslog-ng-3.0.4:

 * It is highly recommended that app-admin/logrotate be emerged to

 * manage the log files.  syslog-ng installs a file in /etc/logrotate.d

 * for logrotate to use.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 3 config files in '/etc' need updating.

 * See the CONFIGURATION FILES section of the emerge

 * man page to learn how to update config files.

    See /tmp/output.log for more information.
```

----------

## ppurka

 *jw5801 wrote:*   

> Great script! I'm not sure if EWARN/ELOG and configuration file update messages are being handled nicely though? It looks to me as though a line has been dropped and the order rearranged a bit in the output below:

 The fact is that I don't handle ewarn/elog at all! That is because emerge -q or emerge -qv does not output any ewarn or elog, as far as I could see. If it does output any ewarn/elogs, I think it outputs only a small subset. The output you are seeing (as you wrote under EDIT2) is actually simply the last 10 lines of /tmp/output.log. I output that just to let the user know that configuration updates are pending  :Razz: 

ewarn/elogs are better read by a different program such as elogv or elogviewer. 

About rearranging the order, it seems you were probably using the version from 26th Oct or earlier. This had the bug that jprobichaud mentions a few posts earlier. The bug was that stderr was not being redirected to the /tmp/output.log. The reason was that I had mistakenly put the 2>&1 before the output redirection (see just two posts earlier). This bug was fixed in the release of 29th Oct. The bug fix in the 30th Oct release is very different and really minor,- the terminal title would not have been updated correctly. One would have hit that bug only if one used --keep-going and if some package failed to merge.

I believe the 30th Oct release is bug free  :Wink:  If you can find bugs do let me know   :Very Happy: 

----------

## jw5801

 *ppurka wrote:*   

> The fact is that I don't handle ewarn/elog at all! That is because emerge -q or emerge -qv does not output any ewarn or elog, as far as I could see. If it does output any ewarn/elogs, I think it outputs only a small subset. The output you are seeing (as you wrote under EDIT2) is actually simply the last 10 lines of /tmp/output.log. I output that just to let the user know that configuration updates are pending 

 

Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'?

----------

## ppurka

 *jw5801 wrote:*   

>  *ppurka wrote:*   The fact is that I don't handle ewarn/elog at all! That is because emerge -q or emerge -qv does not output any ewarn or elog, as far as I could see. If it does output any ewarn/elogs, I think it outputs only a small subset. The output you are seeing (as you wrote under EDIT2) is actually simply the last 10 lines of /tmp/output.log. I output that just to let the user know that configuration updates are pending  
> 
> Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'?

 It should be possible and simple to do this. I will give it a try.

----------

## ppurka

 *jw5801 wrote:*   

> Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'?

 This is now available in version 20091102  :Very Happy: 

Changelog:Determine the PORTAGE_TMPDIR by portageq, and mount tmpfs on to PORTAGE_TMPDIR/portage (for people who do not compile in /var/tmp/portage)

Added a new config option: SHOW_MERGE_TIME. If it is 1, then time spent on the merge will be shown instead of "Done!". To set it to 1, do a

```
echo "SHOW_MERGE_TIME=1" >> ~/.config/quietemerge.config
```

Adding it was simple but I realised that the script was getting complex and repetitive in many places. I wanted to put some of the repetitive parts in a function. But it seems it will take a bit of time and may introduce unwanted bugs if not done properly, and I want the script to remain bug free. So, cleaning up the script is postponed for later.

----------

## ppurka

Ha! Bug in genlop!!

```
~> genlop -t "=dev-libs/apr-1.3.9" --date 2 minute ago

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1039, <_GEN_0> line 23512.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1040, <_GEN_0> line 23512.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1042, <_GEN_0> line 23512.

 * dev-libs/apr

     Tue Nov  3 00:01:33 2009 >>> dev-libs/apr-1.3.9

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1078, <_GEN_0> line 23512.

       merge time: 5 days, 5 hours, 1 minute and 33 seconds.

~> genlop -t "=dev-libs/apr-1.3.9"                    

 * dev-libs/apr

     Tue Nov  3 00:01:33 2009 >>> dev-libs/apr-1.3.9

       merge time: 1 minute and 31 seconds.
```

Updated Version 20091102 to work around genlop bug  :Exclamation: 

----------

## jw5801

 *ppurka wrote:*   

>  *jw5801 wrote:*   Ah, cool. No bugs, but a feature request: Would it be possible/simple to print the time taken to emerge each package where you're currently printing 'Done!'? This is now available in version 20091102 

 

Excellent, thanks very much! I'm getting a syntax error with the new version though, not a very helpful error though...

```
jw@Andornor ~/scripts $ bash quietemerge-20091102

quietemerge-20091102: line 673: syntax error: unexpected end of file
```

----------

## ppurka

 *jw5801 wrote:*   

> 
> 
> Excellent, thanks very much! I'm getting a syntax error with the new version though, not a very helpful error though...
> 
> ```
> ...

 I have no idea how that happened.   :Shocked:  The file quietemerge-20091102 that I uploaded to http://code.google.com/p/quietemerge/downloads/list does not have that error. On the other hand the file quietemerge has that error. Both of them should be the same file.

It is fixed now. It looks like in testing the script or just before uploading I might have pressed a key or something in gvim. That (unintentionally) altered some part of the script. Sorry for this. I hate bugs.   :Evil or Very Mad: 

----------

## jprobichaud

 *ppurka wrote:*   

> Ha! Bug in genlop!!
> 
> ```
> ~> genlop -t "=dev-libs/apr-1.3.9" --date 2 minute ago
> 
> ...

 

Which version of genlop do you have?  I have 0.30.8-r2 and I can't produce this bug...

----------

## jprobichaud

I spoke too soon...  I now have the issue myself, with the latest quietemerge ...

```

  * Install  app-emulation/emul-linux-x86-qtlibs-20081109.                                                                                                                              49 seconds.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1075, <_GEN_0> line 103950.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1076, <_GEN_0> line 103950.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1078, <_GEN_0> line 103950.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1114, <_GEN_0> line 103950.

  * Install  net-fs/samba-libs-3.4.3-r1.                                                                                                                6 days, 22 hours, 46 minutes and 3 seconds.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1075, <_GEN_0> line 103959.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1076, <_GEN_0> line 103959.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1078, <_GEN_0> line 103959.

Use of uninitialized value in subtraction (-) at /usr/bin/genlop line 1114, <_GEN_0> line 103959.

  * Install  net-fs/samba-server-3.4.3-r1.                                                                                                             6 days, 22 hours, 57 minutes and 57 seconds.

```

And obviously, the 6 days isn't real!

I'll try to check genlop to see if I could find the bug

----------

## ppurka

 *jprobichaud wrote:*   

> I spoke too soon...  I now have the issue myself, with the latest quietemerge ...
> 
> ```
> 
>   * Install  app-emulation/emul-linux-x86-qtlibs-20081109.                                                                                                                              49 seconds.
> ...

 Hi,

The problem is that genlop gives the correct estimate if I increase the time in 

```
genlop -t "=cat/pkg-ver"  --date 3 minute ago
```

This was set to 1 minute in an  earlier version of the script, and I noticed that increasing it to 3 minutes is good enough to stop that error from occuring in genlop; except it surely isn't good enough for all cases. 

I don't want to increase the time too much since then it would create a problem with my parsing of genlop's output, if you emerged the same package twice in a row within the same time limit. The other option is for me to implement a counter myself. But that is a really clumsy option, especially when genlop already does it.

----------

## jprobichaud

 *ppurka wrote:*   

> 
> 
> I don't want to increase the time too much since then it would create a problem with my parsing of genlop's output, if you emerged the same package twice in a row within the same time limit. The other option is for me to implement a counter myself. But that is a really clumsy option, especially when genlop already does it.

 

Ah, I understand.  What about doing:

```

jrobicha@localhost ~ $ genlop -t kde-base/kwrited --date 1 day ago | tail -n 3 | head -n 1

     Wed Nov  4 18:58:13 2009 >>> kde-base/kwrited-4.3.3

```

Actually, we can even skip the "--date ..." part.

----------

## ppurka

 *jprobichaud wrote:*   

>  *ppurka wrote:*   
> 
> I don't want to increase the time too much since then it would create a problem with my parsing of genlop's output, if you emerged the same package twice in a row within the same time limit. The other option is for me to implement a counter myself. But that is a really clumsy option, especially when genlop already does it. 
> 
> Ah, I understand.  What about doing:
> ...

 Yes, something like that would be an option. Not that I am happy about using a bunch of pipes.

I will update the script with something similar to this. Let's hope genlop doesn't fail me again.   :Rolling Eyes: 

I don't want to skip the --date part.  A simple thing like showing the merged time would be a highly inefficient operation if I don't give the --date part. I expect that genlop will take less time to parse emerge.log if I give it a date argument. If genlop still parses the whole emerge.log, then it is being really inefficient. Some people here have installations which are several years old and hence might have huge emerge.logs.

----------

## jw5801

 *ppurka wrote:*   

>  *jw5801 wrote:*   
> 
> Excellent, thanks very much! I'm getting a syntax error with the new version though, not a very helpful error though...
> 
> ```
> ...

 

Yeah, dunno what would make it give that error. Possibly some not properly encoded character somewhere. Anyway, all better now!

Cheers!

jw

----------

## jprobichaud

 *ppurka wrote:*   

> 
> 
> I don't want to skip the --date part.  A simple thing like showing the merged time would be a highly inefficient operation if I don't give the --date part. I expect that genlop will take less time to parse emerge.log if I give it a date argument. If genlop still parses the whole emerge.log, then it is being really inefficient. Some people here have installations which are several years old and hence might have huge emerge.logs.

 

shocking truth: genlop is 'really' inefficient.

I've ran these commands multiple times and I'm giving you the representative numbers:

With the date argument:

```

$  time genlop -t kde-base/kwrited --date 1 day ago | tail -n 3 | head -n 1

     Wed Nov  4 18:58:13 2009 >>> kde-base/kwrited-4.3.3

real    0m1.935s

user    0m1.803s

sys     0m0.045s

```

And without:

```

 $ time genlop -t kde-base/kwrited  | tail -n 3 | head -n 1

     Wed Nov  4 18:58:13 2009 >>> kde-base/kwrited-4.3.3

real    0m1.580s

user    0m1.348s

sys     0m0.033s

```

It's faster because it doesn't have to do date comparison all the time...

I know by experience, genlop is highly inefficient.  It's a really good tool that I like alot, but it is not coded in a way that is scalable.  I've submitted a patch to improve it but I didn't had an answer yet.  It's the 2nd time that I try to contribute to this tool, but to no avail...  Maybe I should just 'fork' it.

----------

## ppurka

 *jprobichaud wrote:*   

> shocking truth: genlop is 'really' inefficient.

 This is bad. Really bad  :Sad:  *Quote:*   

> I know by experience, genlop is highly inefficient.  It's a really good tool that I like alot, but it is not coded in a way that is scalable.  I've submitted a patch to improve it but I didn't had an answer yet.  It's the 2nd time that I try to contribute to this tool, but to no avail...  Maybe I should just 'fork' it.

 Maybe you can contact the author(s) directly by email? And point them to the bug reports perhaps?

----------

## ppurka

Update: Version 20091105. Changelog:

  * Work around the bug in genlop. Again.

  * Make "Enter" select "yes" at the prompt when --ask is used.

----------

## jw5801

 *ppurka wrote:*   

>  *jprobichaud wrote:*   shocking truth: genlop is 'really' inefficient. This is bad. Really bad  *Quote:*   I know by experience, genlop is highly inefficient.  It's a really good tool that I like alot, but it is not coded in a way that is scalable.  I've submitted a patch to improve it but I didn't had an answer yet.  It's the 2nd time that I try to contribute to this tool, but to no avail...  Maybe I should just 'fork' it. Maybe you can contact the author(s) directly by email? And point them to the bug reports perhaps?

 

Maybe as a rather hacky workaround you could create a second file with just the last however many lines you need to check from /var/log/emerge.log and get genlop to parse that?

```
jw@Andornor ~ $ time genlop qt-webkit

 * x11-libs/qt-webkit

     Thu Nov  5 16:10:39 2009 >>> x11-libs/qt-webkit-4.5.3

real    0m2.162s

user    0m0.762s

sys     0m0.038s

jw@Andornor ~ $ tail -n100 /var/log/emerge.log > /tmp/quietemerge-short-emerge.log && time genlop -f /tmp/quietemerge-short-emerge.log qt-webkit

using logfile /tmp/quietemerge-short-emerge.log

 * x11-libs/qt-webkit

     Thu Nov  5 16:10:39 2009 >>> x11-libs/qt-webkit-4.5.3

real    0m0.346s

user    0m0.151s

sys     0m0.025s
```

Seems to make a lot of difference. I'm currently compiling, so the real time is a bit skewed, but you can see the big drop in user time.

----------

## jprobichaud

 *ppurka wrote:*   

> Maybe you can contact the author(s) directly by email? And point them to the bug reports perhaps?

 

Every time the bug gets 'touched' they receive an email, maybe there will be some action at some point...

Cheers

----------

## ppurka

 *jw5801 wrote:*   

> Maybe as a rather hacky workaround you could create a second file with just the last however many lines you need to check from /var/log/emerge.log and get genlop to parse that?

 Interesting. I will keep this in mind for a later revision.

----------

## ppurka

Update to version 20091112. Changelog:Bug fix: ACCESS VIOLATION SUMMARY wasn't being caught. This might still be buggy :-/ 

Bug fix: Some packages would output many lines on the countdown.

Bug fix: --resume didn't use to update term title.

Show preserved libs found and do conf update even if some package has failed. 

Show the # of failed, # of skipped and # of packages left to emerge.

Thanks to jw5801 and jprobichaud for discussion and ideas regarding usage of genlop. genlop is slightly faster now in showing merge time.

Broke off all common portions of the script into their own functions. 

The failed packages, etc are shown like this:

```
-------------------------------- Starting emerge -------------------------------

  * Install  rox-base/rox-lib-2.0.5-r1.                                  Error! 

  * Skipped  rox-base/thumbs-0.1.4 due to --keep-going

  * Install  app-admin/eselect-1.2.3.                                11 seconds.

  * [ ERROR!! ] Emerge: 1 failed, 1 skipped, 0 left

    See /tmp/output.log.

    

  * Preserved libraries found: See /tmp/output.log
```

----------

## jw5801

Hmm... interesting point raised by Patrick Lauer in a blog post.

I've just discovered the EMERGE_DEFAULT_OPTS make.conf variable, which comes in handy (before I was creating an alias to emerge, so that --ask was the default), however I've noticed that your script doesn't handle --ask when it's passed via EMERGE_DEFAULT_OPTS. If you can work out a way to detect --ask being passed in this form, that would be awesome, otherwise it might be best to add "--ignore-default-opts" to the emerge calls in the script.

----------

## ppurka

 *jw5801 wrote:*   

> Hmm... interesting point raised by Patrick Lauer in a blog post.
> 
> I've just discovered the EMERGE_DEFAULT_OPTS make.conf variable, which comes in handy (before I was creating an alias to emerge, so that --ask was the default), however I've noticed that your script doesn't handle --ask when it's passed via EMERGE_DEFAULT_OPTS. If you can work out a way to detect --ask being passed in this form, that would be awesome, otherwise it might be best to add "--ignore-default-opts" to the emerge calls in the script.

 Does --pretend even work when you have --ask in your EMERGE_DEFAULT_OPTS?

 I think I can not even ignore the EMERGE_DEFAULT_OPTS since some people may have options other than --ask (for example --with-bdeps=y) which do not affect this script, and which will actually enhance/modify their emerge behaviour. If I ignore the default opts, then this script will not work as I intended it to,- that is, to be a simple way of showing what emerge is doing without interfering with emerge itself.

EDIT: -p seems to work even with --ask in EMERGE_DEFAULT_OPTS. But, I can see where the problem will be.  I will be backgrounding emerge by emerge -q pkg >& log_file and then emerge will wait for an answer. In fact, when I tried it out just now, the emerge process had stopped:

```

~>  EMERGE_DEFAULT_OPTS="--ask" emerge -q rox  >& /dev/null &

[1] 10673

~> 

[1]  + suspended (tty input)  EMERGE_DEFAULT_OPTS="--ask" emerge -q rox >&/dev/null

```

So, unless you foreground emerge you will not be able to pass any options to emerge. I think there may be other complications too. Best option would be to launch this script as EMERGE_DEFAULT_OPTS="" quietemerge <other options>. You can create an alias for this.

----------

## jw5801

 *ppurka wrote:*   

>  *jw5801 wrote:*   Hmm... interesting point raised by Patrick Lauer in a blog post.
> 
> I've just discovered the EMERGE_DEFAULT_OPTS make.conf variable, which comes in handy (before I was creating an alias to emerge, so that --ask was the default), however I've noticed that your script doesn't handle --ask when it's passed via EMERGE_DEFAULT_OPTS. If you can work out a way to detect --ask being passed in this form, that would be awesome, otherwise it might be best to add "--ignore-default-opts" to the emerge calls in the script. 
> 
> Does --pretend even work when you have --ask in your EMERGE_DEFAULT_OPTS?

 

Yeah, if you pass both --pretend and --ask to emerge, it ignores --ask.

 *Quote:*   

> I think I can not even ignore the EMERGE_DEFAULT_OPTS since some people may have options other than --ask (for example --with-bdeps=y) which do not affect this script, and which will actually enhance/modify their emerge behaviour. If I ignore the default opts, then this script will not work as I intended it to,- that is, to be a simple way of showing what emerge is doing without interfering with emerge itself.

 

Yeah, that's a very good point. I wonder if there's a way to specifically ignore --ask, using sed, or some such? I'll try and hack something together to parse EMERGE_DEFAULT_OPTS and post back.

----------

## ppurka

 *jw5801 wrote:*   

> Yeah, that's a very good point. I wonder if there's a way to specifically ignore --ask, using sed, or some such? I'll try and hack something together to parse EMERGE_DEFAULT_OPTS and post back.

 I am sorry, I just tried out some things and edited my earlier post. See the edit for why it is not a good idea to have --ask and background emerge.

BTW, you don't need to hack anything. My script already does all the necessary hacking when it parses the command line arguments. I won't need to rewrite much, but my above comments still hold.

----------

## jw5801

 *ppurka wrote:*   

> EDIT: -p seems to work even with --ask in EMERGE_DEFAULT_OPTS. But, I can see where the problem will be.  I will be backgrounding emerge by emerge -q pkg >& log_file and then emerge will wait for an answer. In fact, when I tried it out just now, the emerge process had stopped:
> 
> ```
> 
> ~>  EMERGE_DEFAULT_OPTS="--ask" emerge -q rox  >& /dev/null &
> ...

 

Yeah, that's essentially what I've done.

 *Quote:*   

> BTW, you don't need to hack anything. My script already does all the necessary hacking when it parses the command line arguments. I won't need to rewrite much, but my above comments still hold.

 

I was thinking perhaps something to read EMERGE_DEFAULT_OPTS, catch everything that isn't '--ask' and add it to the options passed on the command line, then run emerge with --ignore-default-opts and the options parsed from EMERGE_DEFAULT_OPTS as well as those read from stdin? Obviously if --ask is detected in EMERGE_DEFAULT_OPTS you'd then set e_opt_ask=1.

I guess that's probably similar to what you've done for parsing the command line arguments.

----------

## ppurka

 *jw5801 wrote:*   

> I was thinking perhaps something to read EMERGE_DEFAULT_OPTS, catch everything that isn't '--ask' and add it to the options passed on the command line, then run emerge with --ignore-default-opts and the options parsed from EMERGE_DEFAULT_OPTS as well as those read from stdin? Obviously if --ask is detected in EMERGE_DEFAULT_OPTS you'd then set e_opt_ask=1.
> 
> I guess that's probably similar to what you've done for parsing the command line arguments.

 Yes. I got another idea with not providing EMERGE_DEFAULT_OPTS in the emerge command line itself. I will try it out and update the script if it works. Otherwise I will use this method that you mention.

----------

## ppurka

Update to version 20091120: Changelog:

  * Respect --ask in EMERGE_DEFAULT_OPTS

@jw5801 My idea didn't work out   :Crying or Very sad:  I wanted to do emerge <<<'yes' > log_file &. But it didn't work for some reason. I can't be bothered to figure out why. Your method works just fine.

----------

## jw5801

 *ppurka wrote:*   

> Update to version 20091120: Changelog:
> 
>   * Respect --ask in EMERGE_DEFAULT_OPTS
> 
> @jw5801 My idea didn't work out   I wanted to do emerge <<<'yes' > log_file &. But it didn't work for some reason. I can't be bothered to figure out why. Your method works just fine.

 

Oo, that would be very neat, not sure why it isn't working though... apparently emerge thinks it isn't running in a terminal if you do it that way.

----------

## 0x4a47

hi,

just found and tried quietemerge (Version: 20091120). i think it doesn't handle fetch restriction packages well:

```

# quietemerge -u --deep --newuse world

------------------------------------------------------ Pretended emerge -------------------------------------------------------

These are the packages that would be merged, in order:

Calculating dependencies ... done!

[ebuild  N F  ] dev-java/ibm-jdk-bin-1.4.2.13  USE="X alsa -doc -examples -javacomm (-nsplugin)" 57,710 kB [0]

[ebuild   R   ] mail-client/claws-mail-3.7.3  USE="bogofilter crypt dbus dillo gnome gnutls imap ipv6 ldap nntp session smime spamassassin ssl xface -doc -pda -spell -startup-notification (-kde%*)" 0 kB [0=>1]                                             

Total: 2 packages (1 new, 1 reinstall), Size of downloads: 57,710 kB

Fetch Restriction: 1 package (1 unsatisfied)                        

Portage tree and overlays:                                          

 [0] /usr/portage                                                   

 [1] /usr/local/portage                                             

                                                     Total ETA: 4 minutes. 

------------------------------------------------------- Starting emerge -------------------------------------------------------

  * Install  dev-java/ibm-jdk-bin-1.4.2.13.                                                                              Done! 

```

of course nothing has been "done"  :Smile:  because the package couldn't be downloaded. the other reinstall of "claws-mail" didn't process either of course. if i set "SHOW_MERGE_TIME=1" then it just exits without any information (no "done") of what just happened (because ibm-jdk-bin is new and has never been installed).

the file /tmp/output.log shows the whole message of the ibm-jdk-bin package and where to download it though.

is there a way to make quietemerge more friendly with such packages?

another thing is security related, called "symlink attack" (e.g. see http://www.infosecwriters.com/texts.php?op=display&id=159 ). could you please change the hardcoded TMPFILE=/tmp/output.log in line 314 to TMPFILE=`mktemp`. for users being able to find the tmp file location for debug output you'd have to output the path somewhere while running quietemerge.

----------

## ppurka

 *0x4a47 wrote:*   

> hi,
> 
> just found and tried quietemerge (Version: 20091120). i think it doesn't handle fetch restriction packages well:
> 
> ```
> ...

 Very good! I think I don't have any fetch restricted files in my system which is why I never ran into this bug (I recently did a quietemerge -e world). I will update the script soon to catch such events. 

 *Quote:*   

> another thing is security related, called "symlink attack" (e.g. see http://www.infosecwriters.com/texts.php?op=display&id=159 ). could you please change the hardcoded TMPFILE=/tmp/output.log in line 314 to TMPFILE=`mktemp`. for users being able to find the tmp file location for debug output you'd have to output the path somewhere while running quietemerge.

 That is something I was unaware of. The TMPFILE I create is created with the id of root and uses default permissions which gives only read attribute to other users. If you have another malicious user with root privileges then it is really unfortunate. I am against changing this to mktemp since it will create a bunch of files (over time) in /tmp which I want to avoid. Secondly there is also the case that the users will have to remember to read my output carefully everytime. 

What I will do though is delete the file just before redirecting to it. That should mitigate any security concerns. There is a final security concern and that is what happens when your malicious root user changes the file during compilation. That is some vulnerability which can happen even with mktemp, so I don't think it is something which can be avoided.

I guess I can use mktemp for some other tmpfiles in the script. That I will do.

----------

## 0x4a47

 *ppurka wrote:*   

> 
> 
> Very good! I think I don't have any fetch restricted files in my system which is why I never ran into this bug (I recently did a quietemerge -e world). I will update the script soon to catch such events. 
> 
> 

 

thanks very much! another fetch restricted package i have e.g. is truecrypt if you need more test cases  :Smile: 

 *Quote:*   

> That is something I was unaware of. The TMPFILE I create is created with the id of root and uses default permissions which gives only read attribute to other users. If you have another malicious user with root privileges then it is really unfortunate. I am against changing this to mktemp since it will create a bunch of files (over time) in /tmp which I want to avoid. Secondly there is also the case that the users will have to remember to read my output carefully everytime. 

 

this has nothing to do with other root users but normal users doing mischief.  i know that it is unlikey for such an attack for standard setups but imagine a server where other people have access, but not root rights. a malicous user can point a symlink from /tmp/output.log to /etc/shadow or some other only by root accessible files. if root runs quietemerge, it will overwrite /etc/shadow and render the system unusable, so it mainly is a denial of service attack. if a user is able to (somehow) define the output of emerge or quietemerge it might be possible to create another user entry in /etc/shadow for that example. you can test this, but backup your files before  :Smile: 

another thing which makes the attack more hypothetical is that if the /tmp/output.log already exists, a normal user can't overwrite it, because you created it with correct permissions.

 *Quote:*   

> 
> 
> What I will do though is delete the file just before redirecting to it. That should mitigate any security concerns.
> 
> [...]
> ...

 

i don't think that your solution to delete the file everytime is a good one because it gives a potential attacker more opportunity to attack (although again unlikely, i know). what you could do (also mentioned in link i posted) is check whether the file exists and is a sym- or hardlink and if it is ok, then write to it.

----------

## ppurka

Update to version 20091121. ChangelogBug fix: Recognize failure due to fetch restriction

Bug fix: Check temporary files and delete them for security sake. (Thanks to 0x4a47 for pointing out the security risks). 

I have also changed the names of the temporary files so that they contain the name of the script.

Bug fix: If emerge fails on a package very early in the emerge process, the script fails to even recognize that such a package was being emerged. Changed the sleep to "sleep 1" in the first while loop.

@0x4a47: I am simply deleting the temporary files on a fresh run of the script. Even if they were symlinks or hard links, I don't care,- those will be wiped out. This helps me in two ways:

1. I don't have to care about earlier files

2. I can avoid mktemp and the consequent tons of temporary files in /tmp (accumulated over time) if the script is exited suddenly. This is taken care of to some extent at present if the files are not arbitrarily named as mktemp would do.

----------

## Gibbo_07

Great little tool you have here ppurka (&co)

Question however, I have been using a (2.5gb) tmpfs for /var/tmp/portage mounted at boot which this way I need to remember to unmount before merging kde, openoffice etc. With your tool here I decided to use the .config to mount my tmpfs and assumed it would unmount the tmpfs when done but apparently not? My ideal use of this would be for it to mount the tmpfs on start and unmount when finished. 

A feature suggestion perhaps would be to add a switch to disable the mounting of tmpfs when not wanted on the fly per emerge? Or if your preference is to leave the tmpfs mounted afterwards by default, add switch to unmount when done. Either way would be great  :Smile: 

Thanks!

----------

## ppurka

 *Gibbo_07 wrote:*   

> Great little tool you have here ppurka (&co)
> 
> Question however, I have been using a (2.5gb) tmpfs for /var/tmp/portage mounted at boot which this way I need to remember to unmount before merging kde, openoffice etc. With your tool here I decided to use the .config to mount my tmpfs and assumed it would unmount the tmpfs when done but apparently not? My ideal use of this would be for it to mount the tmpfs on start and unmount when finished. 

 That is not true. The script should unmount tmpfs when it is done. The only case when it doesn't unmount tmpfs is when there has been some error in emerge. The reason for not unmounting in that case is so that you can collect error information, etc and investigate further and/or submit a bug report.

Even if you have mounted tmpfs "manually", but have MOUNT_TMPFS=0, the script will not unmount tmpfs. If you have MOUNT_TMPFS=1 in this case, then the script will tell you " * tmpfs is already mounted" just before the emerge starts, and it will unmount the tmpfs after the emerge is successful.

 *Quote:*   

> A feature suggestion perhaps would be to add a switch to disable the mounting of tmpfs when not wanted on the fly per emerge? Or if your preference is to leave the tmpfs mounted afterwards by default, add switch to unmount when done. Either way would be great 
> 
> Thanks!

 Actually the opposite is possible right now  :Smile:   If you have not modified MOUNT_TMPFS in the config file (~/.config/quietemerge.config) then you can temporarily enable mounting of tmpfs by running quietemerge as

```
MOUNT_TMPFS=1 quietemerge <rest of the arguments>
```

EDIT: I hope you now have an understanding of how the script handles mounting/unmounting of tmpfs. If you are still having this problem could you identify some package which takes a few seconds to emerge (such as eselect) and run the following command:

```
bash -x quietemerge eselect
```

and then copy all the output in the terminal and provide me the output? Also, could you provide me the output of 

```
mount | grep tmpfs
```

 while the emerge is running!

----------

## Gibbo_07

 *ppurka wrote:*   

> 
> 
> That is not true. The script should unmount tmpfs when it is done. The only case when it doesn't unmount tmpfs is when there has been some error in emerge. The reason for not unmounting in that case is so that you can collect error information, etc and investigate further and/or submit a bug report.
> 
> Even if you have mounted tmpfs "manually", but have MOUNT_TMPFS=0, the script will not unmount tmpfs. If you have MOUNT_TMPFS=1 in this case, then the script will tell you " * tmpfs is already mounted" just before the emerge starts, and it will unmount the tmpfs after the emerge is successful.

 

That would make sense, the confusion lies in that this is not the behaviour I have observed  :Smile:  I have disabled my manual fstab entry for the portage tmpfs and instead have set the MOUNT_TMPFS=1. I have merged many packages (without error) and have always had the tmpfs stay mounted afterwards - I thought it was a "feature" hah. I umount /var/tmp/portage after each merge, watch it be remounted and used with your script, but never unmounted by itself.

 *Quote:*   

> Actually the opposite is possible right now   If you have not modified MOUNT_TMPFS in the config file (~/.config/quietemerge.config) then you can temporarily enable mounting of tmpfs by running quietemerge as
> 
> ```
> MOUNT_TMPFS=1 quietemerge <rest of the arguments>
> ```
> ...

 

Thanks makes sense now, I assume it is also possible to 

```
MOUNT_TMPFS=0 quietemerge <x>
```

 correct? Just what I need.

 *Quote:*   

> EDIT: I hope you now have an understanding of how the script handles mounting/unmounting of tmpfs. If you are still having this problem could you identify some package which takes a few seconds to emerge (such as eselect) and run the following command:
> 
> ```
> bash -x quietemerge eselect
> ```
> ...

 

So yes I am still having the problem so here's the info (using your example to keep it simple)  :Smile: 

```

gentoobox gibbo # bash -x quietemerge eselect

+ blue='\x1b[1;34m'                          

+ bold='\x1b[1m'                             

+ cyan='\x1b[1;36m'                          

+ green='\x1b[1;32m'                         

+ normal='\x1b[0m'                           

+ pink='\x1b[1;35m'                          

+ red='\x1b[1;31m'                           

+ reverse='\x1b[7m'                          

+ underline='\x1b[4m'                        

+ yellow='\x1b[1;33m'                        

+ config_dir=/root/.config                   

+ config_file=quietemerge.config             

+ [[ -z eselect ]]                           

+ [[ -z eselect ]]                           

+ [[ eselect = -h* ]]                        

+ [[ eselect = --h* ]]                       

+ [[ -f /root/.config/quietemerge.config ]]  

+ . /root/.config/quietemerge.config         

++ MOUNT_TMPFS=1                             

++ TMPFS_SIZE=60%                            

++ TXT_UPDATER=etc-update                    

++ GUI_UPDATER=etc-update                    

++ SHOW_MERGE_TIME=1                         

+ TMPFILE=/tmp/quietemerge.output.log        

+ tmpE=/tmp/quietemerge.tmpE.0               

+ tmpT=/tmp/quietemerge.tmpT                 

+ : 5                                        

+ : 1                                        

+ : 1                                        

+ _num=0                                     

+ cmdline=                                   

+ e_opt_ask=0                                

+ e_opt_pretend=0                            

+ e_opt_verbose=                             

+ eta=0                                      

+ exit_status=(0 0)                          

+ my_len=19                                  

+ PID=                                       

+ pkg=                                       

+ trap 'exit_prog 1' 1 2 5 15                

+ which genlop                               

+ [[ -z eselect ]]                           

+ case "$1" in                               

+ cmdline=' eselect'                         

+ shift                                      

+ [[ -z '' ]]                                

+ secure_file /tmp/quietemerge.tmpE.0        

+ [[ -e /tmp/quietemerge.tmpE.0 ]]           

+ centered_output dash ' Pretended emerge '  

++ tput cols                                 

+ local cols=104                             

++ echo ' Pretended emerge '                 

++ sed -e 's#\\x1[bB]\[[^m]\+m##g'           

+ local 'len= Pretended emerge '             

+ len=18                                     

+ [[ 18 -ge 104 ]]                           

+ printf -vBLANK %104s ''                    

+ local D_ASH=--------------------------------------------------------------------------------------------------------                                                                                          

+ local begin=43                                                                                        

+ local end=43                                                                                          

+ [[ -z  Pretended emerge  ]]                                                                           

+ [[ dash = \d\a\s\h ]]                                                                                 

+ echo -e '-------------------------------------------\x1b[7m Pretended emerge \x1b[0m-------------------------------------------'                                                                              

------------------------------------------- Pretended emerge -------------------------------------------

+ emerge --color=y -p eselect                                                                           

+ tee -i /tmp/quietemerge.tmpE.0                                                                        

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] app-admin/eselect-1.2.8 

+ status=0                              

+ sed -i -e 's/[[^m]*m//g' /tmp/quietemerge.tmpE.0

+ [[ 0 -eq 0 ]]                                   

+ echo                                            

+ infor 'Estimating total update time ...'

++ tput el                                

+ echo -ne '  \x1b[1;33m*\x1b[0m Estimating total update time ...\r'

++ cat /tmp/quietemerge.tmpE.0me ...

++ genlop -npq                      

++ sed -n -e '/Estimated update time/s/^.*: \(.*\)$/\1/p'

+ centered_output blank ' Total ETA: less than a minute. '

++ tput cols                                              

+ local cols=104                                          

++ echo ' Total ETA: less than a minute. '                

++ sed -e 's#\\x1[bB]\[[^m]\+m##g'                        

+ local 'len= Total ETA: less than a minute. '            

+ len=32                                                  

+ [[ 32 -ge 104 ]]                                        

+ printf -vBLANK %104s ''                                 

+ local D_ASH=--------------------------------------------------------------------------------------------------------                                                                                          

+ local begin=36                                                                                        

+ local end=36                                                                                          

+ [[ -z  Total ETA: less than a minute.  ]]                                                             

+ [[ blank = \d\a\s\h ]]                                                                                

+ echo -e '                                    \x1b[7m Total ETA: less than a minute. \x1b[0m                                    '                                                                              

                                     Total ETA: less than a minute.                                     

+ echo                                                                                                  

+ [[ 0 -eq 1 ]]

+ [[ 0 -eq 0 ]]

+ LC_ALL=C     

+ grep -q '^\[ebuild[ ]*I' /tmp/quietemerge.tmpE.0

+ LC_ALL=C                                        

+ grep -q '^\[blocks[ ]*B' /tmp/quietemerge.tmpE.0

+ LC_ALL=C                                        

+ grep -q '^\[blocks[ ]*b' /tmp/quietemerge.tmpE.0

+ LC_ALL=C                                        

+ grep -qE '^\[ebuild[^]]+F' /tmp/quietemerge.tmpE.0

+ [[ 0 -ne 0 ]]                                     

+ unset status                                      

+ sed -i -e '/^\[ebuild/!d' /tmp/quietemerge.tmpE.0 

+ fix_edo                                           

++ portageq envvar EMERGE_DEFAULT_OPTS              

+ local edo=                                        

+ local new_edo                                     

+ [[ -n '' ]]                                       

+ return                                            

+ [[ 0 -eq 1 ]]                                     

++ wc -l /tmp/quietemerge.tmpE.0                    

+ _total_num='1 /tmp/quietemerge.tmpE.0'            

+ _total_num=1                                      

+ mount_tmpfs                                       

+ [[ 1 -ne 1 ]]                                     

++ portageq envvar PORTAGE_TMPDIR                   

+ local var_tmp=/var/tmp/portage                    

+ mount                                             

+ grep -q -s -w 'tmpfs on /var/tmp/portage'         

+ [[ -n 60% ]]                                      

+ mount -t tmpfs -o size=60% tmpfs /var/tmp/portage 

+ [[ 0 -ne 0 ]]                                     

+ [[ 1 -eq 1 ]]                                     

+ secure_file /tmp/quietemerge.tmpT                 

+ [[ -e /tmp/quietemerge.tmpT ]]                    

+ secure_file /tmp/quietemerge.output.log           

+ [[ -e /tmp/quietemerge.output.log ]]              

+ rm -f /tmp/quietemerge.output.log                 

+ PID=24891                                         

+ echo                                              

+ emerge -q eselect

+ [[ '' = *--resume* ]]

+ centered_output dash ' Starting emerge '

++ tput cols                              

+ local cols=104                          

++ echo ' Starting emerge '               

++ sed -e 's#\\x1[bB]\[[^m]\+m##g'        

+ local 'len= Starting emerge '           

+ len=17                                  

+ [[ 17 -ge 104 ]]                        

+ printf -vBLANK %104s ''                 

+ local D_ASH=--------------------------------------------------------------------------------------------------------                                                                                          

+ local begin=44                                                                                        

+ local end=43                                                                                          

+ [[ -z  Starting emerge  ]]                                                                            

+ [[ dash = \d\a\s\h ]]                                                                                 

+ echo -e '--------------------------------------------\x1b[7m Starting emerge \x1b[0m-------------------------------------------'                                                                              

-------------------------------------------- Starting emerge -------------------------------------------

+ echo                                                                                                  

+ ps -p 24891

+ LC_ALL=C   

+ grep -qsE -m1 '(Emerging|Installing)' /tmp/quietemerge.output.log

+ sleep 1                                                          

+ ps -p 24891                                                      

+ LC_ALL=C                                                         

+ grep -qsE -m1 '(Emerging|Installing)' /tmp/quietemerge.output.log

+ sleep 1                                                          

+ ps -p 24891                                                      

+ LC_ALL=C                                                         

+ grep -qsE -m1 '(Emerging|Installing)' /tmp/quietemerge.output.log

+ ps -p 24891                                                      

++ tac /tmp/quietemerge.output.log                                 

++ LC_ALL=C                                                        

++ grep -E -m1 '(Emerging|Installing)'                             

+ tmp='>>> Emerging (1 of 1) app-admin/eselect-1.2.8'              

++ sed -n -e 's/.*) \([^ ]*\)[ ]\?.*$/\1/p'                        

++ echo '>>> Emerging (1 of 1) app-admin/eselect-1.2.8'            

+ pkg_tmp=app-admin/eselect-1.2.8                                  

+ [[ app-admin/eselect-1.2.8 != '' ]]                              

+ [[ -n '' ]]                                                      

+ pkg=app-admin/eselect-1.2.8                                      

+ len=23                                                           

+ update_term_title                                                

+ [[ -n :0 ]]                                                      

+ [[ -f /tmp/quietemerge.tmpE.0 ]]                                 

++ wc -l /tmp/quietemerge.tmpE.0                                   

+ _num='1 /tmp/quietemerge.tmpE.0'                                 

+ _num=1                                                           

++ cat /tmp/quietemerge.tmpE.0                                     

++ genlop -npq                                                     

++ sed -n -e '/Estimated update time/s/^.*: \(.*\)$/\1/p'          

+ eta='less than a minute.'                                        

+ echo -ne '\x1b]0;1/1: eselect-1.2.8, Total ETA: less than a minute.\007'

++ tput cols                                                              

+ cols=104                                                                

+ printf -vBLANK %104s ''                                                 

++ genlop -npq                                                            

++ sed -n -e '/Estimated update time/s/^.*: \(.*\)$/\1/p'                 

++ sed -n -e '/app-admin\/eselect-1.2.8/p' /tmp/quietemerge.tmpE.0        

+ pkg_tmp='less than a minute.'                                           

+ total_len=70                                                            

+ [[ >>> Emerging (1 of 1) app-admin/eselect-1.2.8 = *Emerging* ]]        

+ [[ 70 -lt 104 ]]                                                        

++ sed -n '/ETA: /s/^[ ]*ETA:[ ]*//p'                                     

++ genlop -nqc                                                            

+ tmp=                                                                    

+ infolr infor 'Emerging \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m. ETA:' ''

+ [[ -n '' ]]                                                              

++ tput el                                                                 

+ infor 'Emerging \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m. ETA:'

++ tput el                                                       

+ echo -ne '  \x1b[1;33m*\x1b[0m Emerging \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m. ETA:\r'

+ returnging app-admin/eselect-1.2.8. ETA:

+ [[ -n :0 ]]                             

+ echo -ne '\x1b]0;1/1: eselect-1.2.8, Total ETA: less than a minute.\007'

+ sleep 5                                                                 

+ ps -p 24891                                                             

++ LC_ALL=C                                                               

++ grep -E -m1 '(Emerging|Installing)'                                    

++ tac /tmp/quietemerge.output.log                                        

+ tmp='>>> Installing (1 of 1) app-admin/eselect-1.2.8'                   

++ echo '>>> Installing (1 of 1) app-admin/eselect-1.2.8'                 

++ sed -n -e 's/.*) \([^ ]*\)[ ]\?.*$/\1/p'                               

+ pkg_tmp=app-admin/eselect-1.2.8                                         

+ [[ app-admin/eselect-1.2.8 != \a\p\p\-\a\d\m\i\n\/\e\s\e\l\e\c\t\-\1\.\2\.\8 ]]

+ [[ >>> Installing (1 of 1) app-admin/eselect-1.2.8 = *Emerging* ]]             

++ tput el                                                                       

+ infor 'Installing \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m.'

++ tput el                                                    

+ echo -ne '  \x1b[1;33m*\x1b[0m Installing \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m.\r'

+ [[ -n :0 ]]g app-admin/eselect-1.2.8.

+ echo -ne '\x1b]0;1/1: eselect-1.2.8, Total ETA: less than a minute.\007'

+ sleep 5                                                                 

+ ps -p 24891                                                             

+ LC_ALL=C                                                                

+ grep -qi 'error.*app-admin/eselect-1.2.8 fail' /tmp/quietemerge.output.log

+ LC_ALL=C                                                                  

+ grep -q 'ACCESS VIOLATION SUMMARY' /tmp/quietemerge.output.log            

+ tail -n 25 /tmp/quietemerge.output.log                                    

+ LC_ALL=C                                                                  

+ grep -qiE '^\!\!\!.*(abort|error)'                                        

+ tail -n 25 /tmp/quietemerge.output.log                                    

+ LC_ALL=C                                                                  

+ grep -qiE 'fetch failed.*app-admin/eselect-1.2.8'                         

+ [[ 0 -ne 0 ]]                                                             

+ [[ -n 23 ]]                                                               

++ merge_time =app-admin/eselect-1.2.8                                      

++ [[ 1 -eq 1 ]]                                                            

++ tail -n 40 /var/log/emerge.log                                           

++ genlop -f /tmp/quietemerge.tmpT -nt =app-admin/eselect-1.2.8             

++ tail -n 1                                                                

++ sed -n '/merge time:/s/.*: \(.*\)$/\1/p'                                 

+ infolr info 'Install  \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m.' '\x1b[1;32m6 seconds.\x1b[0m'

+ [[ -n \x1b[1;32m6 seconds.\x1b[0m ]]                                                          

++ echo 'Install  \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m.'                                    

++ sed -e 's#\\x1[bB]\[[^m]\+m##g'                                                              

+ local 'left=Install  app-admin/eselect-1.2.8.'                                                

++ echo '\x1b[1;32m6 seconds.\x1b[0m'                                                           

++ sed -e 's#\\x1[bB]\[[^m]\+m##g'                                                              

+ local 'right=6 seconds.'                                                                      

+ local middle=57                                                                               

+ [[ 57 -le 0 ]]                                                                                

+ info 'Install  \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m.                                                         \x1b[1;32m6 seconds.\x1b[0m'                                                                 

+ echo -e '  \x1b[1;33m*\x1b[0m Install  \x1b[1;36mapp-admin/eselect-1.2.8\x1b[0m.                                                         \x1b[1;32m6 seconds.\x1b[0m'                                         

  * Install  app-admin/eselect-1.2.8.                                                         6 seconds.

+ tail /tmp/quietemerge.output.log                                                                      

+ LC_ALL=C                                                                                              

+ grep -qi preserved                                                                                    

+ [[ -n etc-update ]]                                                                                   

+ tail /tmp/quietemerge.output.log                                                                      

+ LC_ALL=C                                                                                              

+ grep -qEi -m1 'config.*updat'                                                                         

+ tail /tmp/quietemerge.output.log                                                                      

+ LC_ALL=C                                                                                              

+ grep -qEi -m1 'config.*updat'                                                                         

+ exit_prog 0                                                                                           

+ [[ -f /tmp/quietemerge.tmpE.0 ]]                                                                      

+ rm -f /tmp/quietemerge.tmpE.0                                                                         

+ [[ -f /tmp/quietemerge.tmpT ]]                                                                        

+ rm -f /tmp/quietemerge.tmpT                                                                           

+ echo                                                                                                  

+ [[ -n 24891 ]]

+ ps -p 24891   

+ [[ 0 -eq 0 ]] 

+ unmount_tmpfs 

+ [[ 1 -ne 1 ]] 

++ portageq envvar PORTAGE_TMPDIR

+ local var_tmp=/var/tmp/portage 

+ [[ 0 -eq 0 ]]                  

+ mount                          

+ grep -q -s -w 'tmpfs on /var/tmp/portage'

+ [[ 0 -ne 0 ]]                            

+ echo                                     

+ exit 0

[b]strait after[/b]

gentoobox gibbo # ls -l /var/tmp/portage

total 0

```

During the emerge (not that it matters when it's not being unmounted  :Wink: )

```

gentoobox / # mount | grep tmpfs

rc-svcdir on /lib64/rc/init.d type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755)

udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)

shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)

tmpfs on /mnt/rwstorage/var/tmp/portage type tmpfs (rw,size=60%)

```

Is definitely not being auto unmounted for me. Using the latest version (21112009). Thanks for your time ofcourse.

Edit: perhaps useful, I have /var on a separate partition with symlinks as per the gentoo guide... if this changes anything....

----------

## ppurka

 *Gibbo_07 wrote:*   

> Thanks makes sense now, I assume it is also possible to 
> 
> ```
> MOUNT_TMPFS=0 quietemerge <x>
> ```
> ...

 Unfortunately no   :Sad: 

This is because I kept the same variables in the config file. It occurred to me a few weeks after I released the script that I should have kept the names of the variables in the config file a bit different, so that command line environment variables would be always be given preference. 

I never fixed the config file since no one asked for this feature  :Wink:  *Quote:*   

> 
> 
> ```
> 
> gentoobox / # mount | grep tmpfs
> ...

 Exactly! You see, the tmpfs is being mounted on /mnt/rwstorage/var/tmp/portage. Now, if you want your /var/tmp directory to be in some other directory, you should set the variable PORTAGE_TMPDIR in your /etc/make.conf.  If you search my script for this variable, you will see that tmpfs is mounted/unmounted depending on the value of this variable. This is important since I definitely do not want to mount some other tmpfs directory. Someone may have multiple tmpfs mounted simultaneously.

To set your PORTAGE_TMPDIR, you should note that for regular portage, it is /var/tmp. For other directory, give the full directory name except for the last directory "portage". You can run 

```
portageq envvar PORTAGE_TMPDIR
```

 to determine what is the current value.

----------

## Gibbo_07

 *ppurka wrote:*   

> Unfortunately no  
> 
> This is because I kept the same variables in the config file. It occurred to me a few weeks after I released the script that I should have kept the names of the variables in the config file a bit different, so that command line environment variables would be always be given preference. 
> 
> I never fixed the config file since no one asked for this feature 

 

Pretty please? :d Or how possible would it be to have another sub option (eg. ASKTMPFSMOUNT) in the config file whereby if TMPFS is to be used then makes the script ask for y or n each time (just after the emerge --ask prompt) you perform an emerge whether to use the tmpfs or not? I wouldn't mind having to press 'y/n' again - and would actually make the user think hang on will this emerge fit in my tmpfs?  Seems classier than hacking up the cfg or exporting variables each time need to update kde/openoffice etc. I would code it myself if I had the skills  :Smile: 

 *Quote:*   

>  Now, if you want your /var/tmp directory to be in some other directory, you should set the variable PORTAGE_TMPDIR in your /etc/make.conf.  If you search my script for this variable, you will see that tmpfs is mounted/unmounted depending on the value of this variable. This is important since I definitely do not want to mount some other tmpfs directory. Someone may have multiple tmpfs mounted simultaneously.
> 
> To set your PORTAGE_TMPDIR, you should note that for regular portage, it is /var/tmp. For other directory, give the full directory name except for the last directory "portage". You can run 
> 
> ```
> ...

 

Thanks that was the trick. I do find it strange that the script can mount it using the symlink but not unmount it in the same fashion? If I do 

```
umount /var/tmp/portage
```

 it will unmount via the symlink - so is this a feature or? I don't see how the wrong tmpfs can be mounted/unmounted? for all purposes /var/tmp/portage points to my /mnt/rwstorage/var/tmp/portage - other programs have to follow this path in the background I just have a hard time understanding why this script could mount but not unmount without specifically defining it  :Smile: 

Well I had a bad experience the first time calling quietemerge after your advice with the path changed. One of those 'what the bleep is happening here' things that don't really make sense. To try explain, on near fresh boot I was testing the mount/unmount so called 

```
quietemerge -av k3b
```

 - it showed only the header and text saying calculating dependancies - then it crashed back to the prompt without actually bringing up the package name showing my use flags etc nor did it ask the yes|no just strait back to bash prompt. Happened 3 times in a row, and THEN it worked... however then half way through emerging the pkg my whole KDE crashed back to entranced!! ok strange... logged back in tried again, same thing! so I decided to alt+f1 to another terminal and check my logs. Used cat /var/log/messages and it was 'corrupt' as in random wingding style characters everywhere. Then my whole bash prompt was doing the same thing! Rebooted and now all seems to work fine. Just weird... not sure if it was the script or emerge or what but something funky went down that's for sure and there isn't anything useful in my logs about it that I can find. Will update if experience it again.

----------

## ppurka

 *Gibbo_07 wrote:*   

> 
> 
> Thanks that was the trick. I do find it strange that the script can mount it using the symlink but not unmount it in the same fashion? If I do 
> 
> ```
> ...

 You see.. you are assuming that you have a mounted tmpfs in /var/tmp/portage. The script doesn't know this. So, the script has to look at the output of mount. And there it sees:

```
tmpfs on /mnt/rwstorage/var/tmp/portage type tmpfs (rw,size=60%)
```

This does not correspond to /var/tmp/portage. The script has to check this, otherwise umount will fail with a nasty error. 

 *Quote:*   

> Well I had a bad experience the first time calling quietemerge after your advice with the path changed. One of those 'what the bleep is happening here' things that don't really make sense. To try explain, on near fresh boot I was testing the mount/unmount so called 
> 
> ```
> quietemerge -av k3b
> ```
> ...

 I don't know about this. The script runs only emerge, grep, sed, while, tail, mount, umount, echo. None of these commands should interfere with your graphical environment nor should they introduce anything in your system log files. And after the security concerns raised by 0x4a47, I believe I have fixed the last security loophole.

You should investigate what really happened there. I suspect you have a troublesome RAM, or did you run out of hard disk space?

----------

## Gibbo_07

Thanks for the explanation ppurka, makes sense now. 

As for the corruption before well no sign of it since so far albeit I havn't merged much since either but your right it's most likely nothing to do with the script, and even worse for me that I am 99% sure the ram is fine and had plenty of both hdd and tmpfs space left during. It definitely had something to do with the merge process itself, crashed during the build/make at the same spot twice in a row. Anyway dribbling on but thanks for the insight think I have to let this anomoly slide into the unsolved category.

Carry on  :Smile: 

edit: I am wondering how compatible with portage-2.2 this will be? do you plan to implement support for the new features like sets and concurrent merges etc? cheers

----------

## ppurka

 *Gibbo_07 wrote:*   

> Thanks for the explanation ppurka, makes sense now. 
> 
> As for the corruption before well no sign of it since so far albeit I havn't merged much since either but your right it's most likely nothing to do with the script, and even worse for me that I am 99% sure the ram is fine and had plenty of both hdd and tmpfs space left during. It definitely had something to do with the merge process itself, crashed during the build/make at the same spot twice in a row. Anyway dribbling on but thanks for the insight think I have to let this anomoly slide into the unsolved category.
> 
> Carry on 
> ...

 I am using portage-2.2 for several months. Sets are already supported (no special effort is needed on my part). --jobs is not supported since I have no idea how to display two simultaneous merges.

----------

## ppurka

Update to Version 20091202. Changelog:

  * Only one new feature: Allow command line environment variables to override config file variables.

In order to temporarily override the settings present in the config file, prepend the variable with an underscore _ and provide it as an environment variable.

An example where I want to override the config file setting temporarily, and/or provide a temporary setting:

```
 _DELAY=2 _MOUNT_TMPFS=1 quietemerge -a eselect
```

It is not necessary to update to this version if you do not want to temporarily override the config file variables. There are no other fixes or features. Also, I decided to change the script instead of the config file. Seemed simpler to handle.

----------

## doubleagent

Just noticed this.  Nice work.  :Very Happy: 

----------

## ppurka

 *doubleagent wrote:*   

> Just noticed this.  Nice work. 

 Thank you!  :Very Happy: 

----------

## ppurka

Update to version 20091222.  Changelog:Bug fix: Catching ACCESS VIOLATION should be less buggy now.

Genlop should be slightly faster now.

Change output during next iteration if terminal size changes during compile.

Happy holidays everyone!  :Very Happy: 

----------

## devsk

May I ask what font are you using in the terminal in that screenshot?

----------

## ppurka

 *devsk wrote:*   

> May I ask what font are you using in the terminal in that screenshot?

 It is monaco. There is a modified "linuxified" version on the net.

----------

## devsk

 *ppurka wrote:*   

> --jobs is not supported since I have no idea how to display two simultaneous merges.

 I was hoping you won't say that... :Sad:  I have a i7920 with HT ON, so --jobs is a must for large updates. There must be something we can do... :Smile: 

----------

## ppurka

 *devsk wrote:*   

>  *ppurka wrote:*   --jobs is not supported since I have no idea how to display two simultaneous merges. I was hoping you won't say that... I have a i7920 with HT ON, so --jobs is a must for large updates. There must be something we can do...

 Frankly speaking, I have no idea how to display simultaneous merges. I would have liked to do it too. 

Think about it: I will have to detect every $DELAY seconds how many concurrent emerge processes are running:

1. genlop will not give a correct output since genlop doesn't detect emerges while it is in "installing" phase

2. the emerge output is also not that suitable.

Then I have to update that many lines in the terminal. tput might help in the latter, but overall it is too much of a hassle  :Sad: 

----------

## ppurka

Update to version 20100119. Changelog:Support for simultaneous multiple quietemerge instances.

This is not the support for --jobs. It is the support for running more than one quietemerge simultaneously. This was strictly speaking not possible earlier since we need to ensure that different log and temporary files are used, and tmpfs (un)mounting works (i.e. one running instance does not by mistake unmount tmpfs, while the other is running). 

This also led me to uncover more bugs in genlop   :Evil or Very Mad:  So, be ready to see completely irrational genlop -c output if multiple quietemerge instances are running. However the emerges will still work just fine and  I believe the script output will remain more or less sane. What may not be sane is the "ETA"    :Rolling Eyes: 

----------

## Mekoryuk

I'm a little confused as to what constitutes proper behavior for the script. Since day one I've only ever seen "ETA" give an actual value on a handful of packages; most of the time ETA remains blank, and only ever mentions something when the build is almost finished ("any time now"). I've experimented with various values in the config file, but the result remains the same. I suppose it's because that genlop is attempting to calculate time remaining concurrently with the emerge, and that in most cases the emerge will finish long before genlop has a chance to figure it out, but even for large packages where one might expect genlop to figure it out, ETA still remains blank. Is this normal behavior?

----------

## ppurka

 *Mekoryuk wrote:*   

> I'm a little confused as to what constitutes proper behavior for the script. Since day one I've only ever seen "ETA" give an actual value on a handful of packages; most of the time ETA remains blank, and only ever mentions something when the build is almost finished ("any time now"). I've experimented with various values in the config file, but the result remains the same. I suppose it's because that genlop is attempting to calculate time remaining concurrently with the emerge, and that in most cases the emerge will finish long before genlop has a chance to figure it out, but even for large packages where one might expect genlop to figure it out, ETA still remains blank. Is this normal behavior?

 No, this is not normal behaviour.

The cases where you will see a decent ETA is when the package has a good compile time. If the compile time is almost negligible then ETA will remain blank. Cases where you may get blank ETA:

1. package is small, or package compiles very quickly.

2. package is large, but package has no compile time. The only thing that takes time is the unpacking of the package (For example if you try to emerge openoffice-bin). 

3. DELAY is set very large in the config script, so genlop output is not updated frequently enough. 

4. /var/log/emerge.log is very large. So, genlop takes a significant amount of time to update, and by then the package has already compiled.

----------

## gerard27

Thanks a lot ppurka.

Gerard.

----------

## ppurka

 *gerard82 wrote:*   

> Thanks a lot ppurka.
> 
> Gerard.

 I am glad it is of help  :Very Happy: 

----------

## JustJoe

ppurka,

Great script, it looks awesome.

Maybe you can implement cpu-scaling:

before merge

# the next line would change the cpu-governour, if available, to the highest frequency

[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ] && echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

[ -f /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor ] && echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

after merge

# and set the scheduler back to "ondemand"

[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ] && echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

[ -f /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor ] && echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

You probably need a routine to check how many cores there are on the system.

These lines are taken from the tmerge-script @ http://en.gentoo-wiki.com/wiki/Speeding_up_portage_with_tmpfs

It sure does make a difference in merge time: https://forums.gentoo.org/viewtopic-p-6233551.html#6233551

----------

## ppurka

 *JustJoe wrote:*   

> ppurka,
> 
> Great script, it looks awesome.
> 
> Maybe you can implement cpu-scaling:
> ...

 Hi, your proposal seems interesting. However, I don't think I will implement cpu-scaling. People have many different setups. Some people control the scaling using cpufreq, some people use their DE's and so on. It is very easy to go wrong when you mess with others' cpu-scaling.

These type of things are best left to the daemon/DE/manual control as the individual wants.

----------

## JustJoe

 *ppurka wrote:*   

> Hi, your proposal seems interesting. However, I don't think I will implement cpu-scaling. People have many different setups. Some people control the scaling using cpufreq, some people use their DE's and so on. It is very easy to go wrong when you mess with others' cpu-scaling.
> 
> These type of things are best left to the daemon/DE/manual control as the individual wants.

 

Fair enough.  :Cool: 

I added the performance bit on line 744, just below where mount_tmpfs is being called, and the ondemand bit is at line 901, just before 'exit_prog $exit_status'.

Seems to work fine like that. Any advise on the placement of these commands in quietemerge ?

----------

## ppurka

 *JustJoe wrote:*   

> 
> 
> Fair enough. 
> 
> I added the performance bit on line 744, just below where mount_tmpfs is being called,

 This placement is perfect. If you want to set your cpu frequency, then just before actual emerge makes good sense.   *Quote:*   

> and the ondemand bit is at line 901, just before 'exit_prog $exit_status'.
> 
> Seems to work fine like that. Any advise on the placement of these commands in quietemerge ?

 The ondemand bit is not really well placed. The script can exit even when you press Ctrl+C. The function exit_prog() handles those cases. 

So, a correct line in which to place this ondemand bit would be anywhere before unmount_tmpfs in the function exit_prog(). So, for example placing it just before line 412 would be a good option.

----------

## jw5801

 *ppurka wrote:*   

>  *JustJoe wrote:*   
> 
> Fair enough. 
> 
> I added the performance bit on line 744, just below where mount_tmpfs is being called, This placement is perfect. If you want to set your cpu frequency, then just before actual emerge makes good sense.   *Quote:*   and the ondemand bit is at line 901, just before 'exit_prog $exit_status'.
> ...

 

Hmm... how about a configuration file option to set pre and post merge commands? That could cover this usage scenario as well as a lot of other general situations.

----------

## ppurka

 *jw5801 wrote:*   

> Hmm... how about a configuration file option to set pre and post merge commands? That could cover this usage scenario as well as a lot of other general situations.

 That's a possibility. Give me a little time to figure it out.

I think something like this will take care of both scripts and commands:

```
# In config file:

precommand="something something"
```

In my code:

```
# If it is executable, then run it. Otherwise it is a command.

[[ -x "$( which "$precommand" )" ]] && "$precommand" || eval "$precommand"
```

Any comments or suggestions? Any cases where this may fail?

----------

## JustJoe

 *ppurka wrote:*   

> The ondemand bit is not really well placed. The script can exit even when you press Ctrl+C. The function exit_prog() handles those cases. 
> 
> So, a correct line in which to place this ondemand bit would be anywhere before unmount_tmpfs in the function exit_prog(). So, for example placing it just before line 412 would be a good option.

 

Doh @ self. The obvious exit_prog function.   :Embarassed: 

 *ppurka wrote:*   

>  *jw5801 wrote:*   Hmm... how about a configuration file option to set pre and post merge commands? That could cover this usage scenario as well as a lot of other general situations. That's a possibility. Give me a little time to figure it out.
> 
> I think something like this will take care of both scripts and commands:
> 
> ```
> ...

 

I'd like that. With this there's no need for editing quietemerge every time a new version get released. Good for the lazy.  :Smile: 

----------

## jw5801

 *ppurka wrote:*   

> I think something like this will take care of both scripts and commands:
> 
> ```
> # In config file:
> 
> ...

 

Looks good to me, no obvious points of failure spring to mind.

----------

## ppurka

Update: Version 20100407

Changelog:

  * Support for pre-commands and post-commands.

To enable this, add the variables PRE_CMD and POST_CMD to the config file in ~/.config. The variables may point to a command or to a script/program. 

If you want to migrate your current config to the new one, then it has to be done manually:

```
$ mv ~/.config/{quietemerge.config,quietemerge.config.backup}

$ quietemerge test   # This will create the new config file

$ <your favourite diff program> ~/.config/{quietemerge.config,quietemerge.config.backup}
```

----------

## JustJoe

ppurka,

Although the PRE_CMD and POST_CMD variables do work, they do not seem to appear in the config file by default, I had to add them manually.

----------

## ppurka

 *JustJoe wrote:*   

> ppurka,
> 
> Although the PRE_CMD and POST_CMD variables do work, they do not seem to appear in the config file by default, I had to add them manually.

 I don't have a mechanism of updating the config file. That's why I wrote that you need to migrate your old config file manually.

----------

## JustJoe

 *ppurka wrote:*   

>  *JustJoe wrote:*   ppurka,
> 
> Although the PRE_CMD and POST_CMD variables do work, they do not seem to appear in the config file by default, I had to add them manually. I don't have a mechanism of updating the config file. That's why I wrote that you need to migrate your old config file manually.

 

I understand about updating an existing config file, but shouldn't these vars appear in a newly created config file ?  (Looks like they don't atm.)

----------

## JustJoe

 *Mekoryuk wrote:*   

> I'm a little confused as to what constitutes proper behavior for the script. Since day one I've only ever seen "ETA" give an actual value on a handful of packages; most of the time ETA remains blank, and only ever mentions something when the build is almost finished ("any time now"). I've experimented with various values in the config file, but the result remains the same. I suppose it's because that genlop is attempting to calculate time remaining concurrently with the emerge, and that in most cases the emerge will finish long before genlop has a chance to figure it out, but even for large packages where one might expect genlop to figure it out, ETA still remains blank. Is this normal behavior?

 

I had the same problem. It was only when i ran emerge -p kopete|genlop -pq when i saw a message about genlop not knowing my CPU. It directed me here:

http://gentoo.linuxhowtos.org/compiletimeestimator/

Only a couple of days after i had send the info requested on that page i got a reply that my CPU was added to the database. Now my ETA's are ok (well, at least they're not blank anymore).

----------

## ppurka

 *JustJoe wrote:*   

> I understand about updating an existing config file, but shouldn't these vars appear in a newly created config file ?  (Looks like they don't atm.)

 You should follow the instructions I posted here. Don't create a new blank config file!! The script only checks if there is a config file or not. If it is there, even if blank, the script won't touch that file.

----------

## JustJoe

 *ppurka wrote:*   

>  *JustJoe wrote:*   I understand about updating an existing config file, but shouldn't these vars appear in a newly created config file ?  (Looks like they don't atm.) You should follow the instructions I posted here. Don't create a new blank config file!! The script only checks if there is a config file or not. If it is there, even if blank, the script won't touch that file.

 

Guess we're missing each other here a bit...

When quietemerge is run for the very first time -so no quietemerge.config file exists in ~/.config/ yet-, the default config file that gets created by quietemerge doesn't seem to contain the new PRE_CMD and POST_CMD variables.

Seems logical to me those variables should be in the default quietemerge.config that quietemerge creates on its first run. Looks like they're not:

```
joe@homebox ~ $ mv .config/quietemerge.config .config/quietemerge.config.bak

joe@homebox ~ $ quietemerge test

  * /home/joe/.config/quietemerge.config config file not found. Creating ...

                                                                                

  * Open /home/joe/.config/quietemerge.config and modify the settings       

    to your own liking.                                                         

                                                                                

joe@homebox ~ $ grep CMD .config/quietemerge.config                        

joe@homebox ~ $ 
```

----------

## ppurka

 *JustJoe wrote:*   

> 
> 
> Guess we're missing each other here a bit...
> 
> When quietemerge is run for the very first time -so no quietemerge.config file exists in ~/.config/ yet-, the default config file that gets created by quietemerge doesn't seem to contain the new PRE_CMD and POST_CMD variables.
> ...

 Well, then you simply have an old quietemerge script in your system!   :Razz:  Though, I wonder how you are able to run some *_CMD if you have an older script. I just downloaded the script from the google code website and it works fine in mine. Please ensure that you have the latest version:

```
~> grep -m1 Version $(which quietemerge)

        #   Version: 20100407                                       #

```

----------

## JustJoe

```
# grep -m1 Version $(which quietemerge)

        #   Version: 20100119                                       #
```

*crawls back under rock....  :Embarassed: 

Guess i totally forgot to actually move the 20100407 version into $PATH after downloading it.

The reason why 20100119 just runs my defined CMD's is not a mystery at all: i had those hard coded in it.

Sorry for the needless fuzz !

edit:

I edited line 447 and 769 from quietemerge to redirect which error msg to /dev/null :

```

line 447

[[ "$_POST_CMD" && -x "$( which "$_POST_CMD" 2> /dev/null )" ]] \

line 769

[[ "$_PRE_CMD" && -x "$( which "$_PRE_CMD" 2> /dev/null )" ]] \ 
```

This suppresses ugly which output like:

which: no scaling_governor in (./[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ] ....<snipped for forum readability>

As far as i know this will not cause any problems with the rest of your code.

----------

## ppurka

 *JustJoe wrote:*   

> 
> 
> I edited line 447 and 769 from quietemerge to redirect which error msg to /dev/null :
> 
> ```
> ...

 Yes. I should have done that. Well, the next (non-trivial) revision will include this fix  :Smile: 

----------

## ppurka

New version! 20110422  :Smile: 

Changelog:Use my own genlop function (now dependency on genlop is removed)

[A bug free genlop functionality will be required for future --jobs support]

Redirect error messages to /dev/null (as pointed out by JustJoe)

Handle -r resume switch (seems to be a new argument in emerge?)

Google didn't seem to handle my upload of similarly named files correctly this time. I have removed the "quietemerge" file from the download list (and lost all the statistics)  :Sad: 

New version can be downloaded from here: http://code.google.com/p/quietemerge/downloads/list

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110422

Please rename the file to quietemerge after downloading.

EDIT: Added reason for dropping genlop.

----------

## ppurka

Update: Version 20110430.

Changes:Recognize --color=n in command line and turn off all colors

Create config file only if user is root

Add option to show per-package ETA. It is config variable ETA_ALL

Add rudimentary detection of old config file

Bug fix: work around duplicate lines in emerge.log. Notable package is sys-apps/portage.

Bug fix: try to fix "any time now" showing up as "any time no"

Bug fix: Pass --resume on to emerge command

Make sure one tmp file ($tmpT) is deleted just before writing to it.

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110430

Please rename the file to quietemerge after downloading.

----------

## ppurka

There is something weird in this screenshot: http://i.imgur.com/pPufG.png

Can anyone spot it?   :Razz:   :Twisted Evil: 

----------

## gmargaro

 *ppurka wrote:*   

> There is something weird in this screenshot: http://i.imgur.com/pPufG.png
> 
> Can anyone spot it?   

 

The --jobs option ??

----------

## krinn

yep, your cpu has learn to count total ETA with scotty from the enterprise ship : because only him can says: "it will take 7 days to repair, so it will be ok in 2 days"

----------

## ppurka

 *gmargaro wrote:*   

>  *ppurka wrote:*   There is something weird in this screenshot: http://i.imgur.com/pPufG.png
> 
> Can anyone spot it?    
> 
> The --jobs option ??

 It sure is! I am currently planning on running a big uDNv world to test it. I held off updating the few kde apps (okular, digikam, etc) that I have (4.4->4.6) all this while, so that I get an incentive to complete this --jobs support  :Smile: 

----------

## gmargaro

Great !

I miss the --jobs option since i reinstalled quietemerge.

----------

## ppurka

 *krinn wrote:*   

> yep, your cpu has learn to count total ETA with scotty from the enterprise ship : because only him can says: "it will take 7 days to repair, so it will be ok in 2 days"

 What does that quote mean?   :Razz: 

----------

## krinn

that on left part it shown a per package eta of 12s, 6s, 9s, 26s, 23s, 18s and 11s and a total ETA of 49s

same for right side, same thing is seen. (it's even worst with a funky 15s)

----------

## ppurka

 *krinn wrote:*   

> that on left part it shown a per package eta of 12s, 6s, 9s, 26s, 23s, 18s and 11s and a total ETA of 49s
> 
> same for right side, same thing is seen. (it's even worst with a funky 15s)

 Ah yes. I fixed that bug a while ago.  :Smile:  I didn't realise until it gave me a 1min Total ETA for a total of 83 packages!

----------

## ppurka

Update: Version 20110520 "A midsummer night's dream release"

Changelog:Major rewrite with --jobs support!

Don't create a temp file ($tmpT) if emerge -p exited with an error

Bug fix: "_ETA_ALL=1 quietemerge" wasn't working, i.e. ETA_ALL in config wasn't over-ridden

Bug fix: Fix sed expression in my_genlop. ETA was incorrect if pkgs like rox and rox-lib were both installed. rox would have the wrong ETA since it would also add and compute ETA for rox-lib.

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110520

 Please rename the file to quietemerge after downloading.

EDIT Please let me know if you find any bugs. I am unsure how --keep-going works with --jobs (with respect to skipped packages), since I haven't been able to emulate that behavior. If you do find bugs in the update mechanism, please copy /tmp/quietemerge.output.log file since I might need them to debug the script. Thanks!  :Smile: 

----------

## ppurka

Update: Version 20110521

It seems I broke the display that results from SHOW_MERGE_TIME=1 in the config, in trying to fix another bug. This update fixes the SHOW_MERGE_TIME=1 display also.

Changelog:Bug fix: Revert sed expression for the case when SHOW_MERGE_TIME=1

Output the total time emerge took (at the end).

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110521

 Please rename the file to quietemerge after downloading.

----------

## ppurka

Update: Version 20110611

Changelog:Add support for --autounmask-write

export FEATURES="notitle" so that the term title can be updated less often

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110611

Please rename the file to quietemerge after downloading.

----------

## ppurka

Update: Version 20110617

It seems I forgot to upload these fixes from more than a week ago. Now, if you have configured config updater in the quietemerge.config file, then it will kick in after you run --autounmask-write the first time (unless you have /etc/portage in CONFIG_PROTECT_MASK).Bugfix: --autounmask-write in EMERGE_DEFAULT_OPTS wasn't being honored.Update the config update grep string to include config message from --autounmask-write 

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110617

Please rename the file to quietemerge after downloading.

----------

## Gordex

looks great, thanks for sharing   :Cool: 

----------

## ppurka

 *Gordex wrote:*   

> looks great, thanks for sharing  

 Thanks   :Very Happy: 

----------

## ppurka

Update: Version 20110827

Small bugfixes:Now, easier to detect currently merging pkgs

Bugfix: Correct <num>/<total> in term title.

Bugfix: Detect "binary" @ emerge -K output. 

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20110827

Please rename the file to quietemerge after downloading.

Do let me know if you find any bugs. This script is pretty much going into a maintenance stage since I can't think of any more features to add. Adding --jobs was the most difficult for me, but now that is done, and the script is stable. I would like to keep it stable which implies I should leave it as it is.  :Smile: 

----------

## ppurka

Trivial update: Version 20111113

 * Only change is the removal of -q option from emerge.

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20111113

Please rename the file to quietemerge after downloading.

The files have also been added retroactively to a git repository: http://code.google.com/p/quietemerge/source/list

----------

## Woofie

Hi, I noticed a small error when I try emerge my bin  package (migrating throught wine version) I call quietemerge like this

```
quietemerge -avk wine
```

and I get this 

```

------------------------------- Pretended emerge -------------------------------

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[binary   R   ~] app-emulation/wine-1.3.32  USE="X alsa cups dbus fontconfig gecko gnutls jpeg lcms ldap mp3 ncurses nls opengl oss perl png samba ssl threads truetype win32 xcomposite xinerama xml -capi -custom-cflags -gphoto2 -gsm -gstreamer -hardened -openal -opencl -scanner -test -v4l (-win64)" 

Total: 1 package (1 reinstall, 1 binary), Size of downloads: 0 kB

                                   Total ETA:                                   

  * Continue with the emerge process? ([Yes]|No): 

-------------------------------- Starting emerge -------------------------------

/usr/local/bin/quietemerge: line 768: 0 +  : syntax error: operand expected (error token is "+  ")

  * Installing app-emulation/wine-1.3.32.

/usr/local/bin/quietemerge: line 768: 0 +  : syntax error: operand expected (err

  * Install  app-emulation/wine-1.3.32.                                   Done! 

```

Seems it doesn't harm  :Smile:  only for info..

Maybe I missed something..

----------

## ppurka

```
/usr/local/bin/quietemerge: line 768: 0 +  : syntax error: operand expected (error token is "+  ")
```

Hi, what version of quietemerge are you using? You can get the version from the help quietemerge -h. In the latest version, line 768 is this:

```
        local p ptime
```

and there is no + operand on that line.

Version 20110617 has a + on that line. But in 20110827 I had put in some fixes to detect "binary" packages like this: [binary   R   ~]. So that might have fixed this + operand error.

 *Quote:*   

> Seems it doesn't harm  only for info.. 
> 
>  Maybe I missed something..

 As for not harming - that is how I have designed it to work  :Smile:  Emerge itself runs as a separate process and if the script messes up, nothing happens to emerge itself.

----------

## Woofie

Ah I foud what i missed  :Smile: 

It was the older version 20110617 now when I updated to newest version yesterday I forgot copy it into my $PATH 

Sorry, little mistake  :Smile: 

Tested new version and no error  :Smile:  keep up in this good work. 

Is it posible don't count ETA of binary package to total ETA to have a better view of merging time? Because if I start merge package ( for example wine ) it's wrote that ETA will be 33 min and start to countdown, but after several seconds skip to Installing phase.

----------

## ppurka

 *woofie wrote:*   

> Ah I foud what i missed 
> 
> It was the older version 20110617 now when I updated to newest version yesterday I forgot copy it into my $PATH 
> 
> Sorry, little mistake 
> ...

 

Good! Otherwise I would have to search for a bug  :Razz: 

 *Quote:*   

> Is it posible don't count ETA of binary package to total ETA to have a better view of merging time? Because if I start merge package ( for example wine ) it's wrote that ETA will be 33 min and start to countdown, but after several seconds skip to Installing phase.

 Actually you get the ETA also in your terminal title. So, after this binary package has been emerged, the ETA in the terminal titlebar will update and show you the correct ETA for the rest of the packages.

As for removing the count of binary packages, it is possible and small binary packages are emerged quickly. But larger binary packages will actually take quite some time to unpack and install. In that case, the Total ETA will show a gross underestimate of the time required. Is that desirable??

EDIT: Never mind. I will show both.

----------

## ppurka

Trivial update: Version 20111127

* Show (additional) Total ETA without binary emerges

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20111127

Please rename the file to quietemerge after downloading.

EDIT: Fixed a silly mistake in the code. New file is uploaded.

EDIT 2: Fix the fix. The original code was correct!!

----------

## Woofie

 *Quote:*   

> 
> 
> As for removing the count of binary packages, it is possible and small binary packages are emerged quickly. But larger binary packages will actually take quite some time to unpack and install. In that case, the Total ETA will show a gross underestimate of the time required. Is that desirable?? 
> 
> 

 

Good point I haven't consider that. Hardly say if it's desirebly then.. We'll see after some merges. 

but if you want to show two line with ETA isn't be more readeble if the ETA without binary line appears only if some binary package are going to merge or something like that?

----------

## ppurka

 *woofie wrote:*   

>  *Quote:*   
> 
> As for removing the count of binary packages, it is possible and small binary packages are emerged quickly. But larger binary packages will actually take quite some time to unpack and install. In that case, the Total ETA will show a gross underestimate of the time required. Is that desirable?? 
> 
>  
> ...

 Yes. Currently, the Total ETA is always shown. The ETA without binary is shown only if there is some binary emerge. So, you get the following behavior:

```
~> quietemerge -pk eet gvim

------------------------------- Pretended emerge -------------------------------

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[ebuild   R    ] app-editors/gvim-7.3.266 

[binary   R   *] dev-libs/eet-9999 

                                Total ETA: 4m 9s                                

                        Total ETA without binary: 3m 35s                        

~> quietemerge -p eet gvim 

------------------------------- Pretended emerge -------------------------------

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[ebuild   R    ] app-editors/gvim-7.3.266 

[ebuild   R   *] dev-libs/eet-9999 

                                Total ETA: 4m 9s                                

```

----------

## Woofie

Oh sorry  :Smile:  maybe I should test it first and ask later, my mistake  :Smile: 

----------

## ppurka

Update: Version 20111224 "The Holiday Release!"

Execute emerge directly if unsupported command is detected. All the script setup is bypassed. This should get this script one step closer to being a wrapper for emerge  :Very Happy: 

Show package name in terminal title if only number of jobs is 1.

Clean up help() function.

Bugfix: Get rid of "grep: Unmatched [ or [^"

Bugfix: Force --color=n on actual emerge.

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20111224

Please rename the file to quietemerge after downloading.

----------

## ppurka

Update: Version 20111230

Bugfix: Fix infinite recursion (for example with -1). This was an embarrassing bug  :Sad: 

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20111230

Please rename the file to quietemerge after downloading.

----------

## Woofie

Hi when I upgraded yesterday I got this error

 *Quote:*   

> 
> 
>   * Install  dev-python/pygobject-2.28.6-r51.            Done! 
> 
>   * Install  dev-python/pygobject-3.0.2.                    Done! 
> ...

 

but it seems that everything emerge ok. In quietemerge.output.log I foung only this section which should be connect to this

 *Quote:*   

> 
> 
> >>> Completed installing pygobject-3.0.2 into /home/fox/Build/portage/dev-python/pygobject-3.0.2/image/
> 
> strip: i686-pc-linux-gnu-strip --strip-unneeded -R .comment
> ...

 

Problem is maybe with interpret installing proces for Python modules or something like that  :Smile: 

----------

## ppurka

Unfortunately, I am unable to reproduce this here:

```
~> quietemerge -av --buildpkg "pygobject:3"

------------------------------- Pretended emerge -------------------------------

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[ebuild  NS    ] dev-python/pygobject-3.0.2 [2.28.6-r51] USE="cairo threads -examples -test" 0 kB

Total: 1 package (1 in new slot), Size of downloads: 0 kB

                                 Total ETA: 40s                                 

  * Continue with the emerge process? ([Yes]|No): 

-------------------------------- Starting emerge -------------------------------

  * Install  dev-python/pygobject-3.0.2.                                    34s 

```

The full build output is in http://paste.pocoo.org/show/535127

I don't see anything in your logs which can trigger that output you saw. The "Error!" string is shown only when some package failed, and no part of the output matches the strings I search for in my script. I also tried emerging farsight2 to see if the errors are triggered by that, but I didn't see any errors there either.

```
~ [1] > quietemerge farsight2 $QEMERGE

------------------------------- Pretended emerge -------------------------------

These are the packages that would be merged, in order:

Calculating dependencies  ... done!

[ebuild  N     ] net-libs/libnice-0.1.0  USE="gstreamer -upnp" 

[ebuild  N     ] media-libs/gst-plugins-bad-0.10.22  USE="orc" 

[ebuild  N     ] net-libs/farsight2-0.0.29  USE="-msn -python -upnp" 

                                Total ETA: 3m 33s                               

  * tmpfs is already mounted

-------------------------------- Starting emerge -------------------------------

  * Install  net-libs/libnice-0.1.0.                                        20s 

  * Install  media-libs/gst-plugins-bad-0.10.22.                         1m 36s 

  * Install  net-libs/farsight2-0.0.29.                                     33s 

                            Total time taken: 2m 14s                            
```

"$QEMERGE" is simply some extra emerge options that is set in my zshrc (I use this when I want to use --jobs): "QEMERGE='--jobs=2 --load-average=5 --keep-going'"

----------

## ppurka

woofie, thanks for the bug report! I have been able to reproduce the bug. I simply had to disable --jobs while emerging farsight2. The error stems from a string in the output in the build of farsight2 which matches an error string that I search for in my script.

It seems emerge is spewing out full build logs again (that is --quiet-build=y has been removed). I failed to notice that. I should re-enable the -q option to my emerge command. This will ensure that such incidents don't happen again.

----------

## ppurka

Update Version 20120115: Small bug fix for the problem faced by woofie. Just reintroducing -q to my emerge command is sufficient  :Smile: 

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20120115

Please rename the file to quietemerge after downloading.

----------

## Woofie

Oh sorry for my very lame bug report, but I'm still learning  :Smile:  I forgot to wrote that I don't use --jobs and so on.. 

I base it only on guessing. It's fine that you can reproduce it and find it there.

Keep up in this good work  :Smile: 

----------

## ppurka

 *woofie wrote:*   

> Oh sorry for my very lame bug report, but I'm still learning  I forgot to wrote that I don't use --jobs and so on.. 
> 
> I base it only on guessing. It's fine that you can reproduce it and find it there.
> 
> Keep up in this good work 

 No problems. You didn't need to mention that. It is evident from your logs that --jobs is not used.  :Smile: 

----------

## ppurka

Update Version 20120406: Two bug fixes:

 * Bugfix: Often term titlebar showed that more jobs were running than the actual number.

 * Bugfix: Sometimes skipped pkgs weren't being detected.

 * Added a README to the git repositories: On Google Code | On Github

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20120406

Please rename the file to quietemerge after downloading.

----------

## ppurka

Update Version 20120413: Only one simple update.

Update to new emerge message on running with --autounmask-write

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20120413

Please rename the file to quietemerge after downloading.

----------

## ppurka

Update Version 20130427: Small update for:

* Add new location of make.conf

* NOCOLOR wasn't working properly.

Direct file link: http://quietemerge.googlecode.com/files/quietemerge-20130427

Please rename the file to quietemerge after downloading.

----------

## yagami

using this very nice script for routine updates...

Could you please do two things:

* put the ETA=1 option with also the text "DONE!" before ... something like "DONE! in xx.xx minutes"

* create an ebuild for it and put it on the gentoo tree. Really, this should be there.

Thanks !

----------

## ppurka

 *yagami wrote:*   

> using this very nice script for routine updates...
> 
> Could you please do two things:
> 
> * put the ETA=1 option with also the text "DONE!" before ... something like "DONE! in xx.xx minutes"

 Is there a reason why you suggest this? Is it difficult to figure out which packages have finished and which are still ongoing?

 *Quote:*   

> * create an ebuild for it and put it on the gentoo tree. Really, this should be there.
> 
> Thanks !

 Thanks for trying it out  :Smile: 

About the ebuild.. no one has asked for it before! It is simply a single file with no packaging requirements. I can try to submit an ebuild to b.g.o. Then it is up to some dev to put it into the tree.

----------

## yagami

 *ppurka wrote:*   

>  *yagami wrote:*   using this very nice script for routine updates...
> 
> Could you please do two things:
> 
> * put the ETA=1 option with also the text "DONE!" before ... something like "DONE! in xx.xx minutes" Is there a reason why you suggest this? Is it difficult to figure out which packages have finished and which are still ongoing?
> ...

 

first point: yes and no ... its not hard really , but at quick glance , yes its a little hard. ( if its easy to do, please do it .. it would look much better ).

second point: I dont really understand why nobody ever asked. I guess is one of those things : not in tree, its not "public", not many people know of it and nobody asks.

Unless portage gets the feature of showing the ETA and TOTAL ETA/TIME of an emerge ... this script is a must  :Smile: 

----------

## ppurka

Would it help if I change the color to normal?

The problem with putting another "Done!" is that it eats up horizontal space. And so there might be cases where I can not make the whole sentence fit in the same line. It is not difficult to put it in. It is just that I tried to make sure that almost all packages can be written in one line (within 80 characters).

----------

## yagami

 *ppurka wrote:*   

> Would it help if I change the color to normal?
> 
> The problem with putting another "Done!" is that it eats up horizontal space. And so there might be cases where I can not make the whole sentence fit in the same line. It is not difficult to put it in. It is just that I tried to make sure that almost all packages can be written in one line (within 80 characters).

 

maybe changing color is enough  :Smile: 

----------

## ppurka

Thanks. The new version is up.

Changelog:

 * Change the color of time taken to normal.

Now, the problem is google code does not allow files to be released from there any more. So, I have to resort to github releases.

Please download the latest tarball from here: https://github.com/ppurka/quietemerge/releases/download/20140205/quietemerge-20140205.tar.gz

----------

## yagami

 *ppurka wrote:*   

> Thanks. The new version is up.
> 
> Changelog:
> 
>  * Change the color of time taken to normal.
> ...

 

thanks ... got the new version... as soon as i emerge something i will report some feedback

----------

## ppurka

I opened a bug report regarding the ebuild: https://bugs.gentoo.org/show_bug.cgi?id=500392 . Let's see if there is any interest in getting it into portage.

----------

## ppurka

New version 20141220. Changes since quietemerge-20140205

Fix breakage due to changing emerge outputs.

Download from https://github.com/ppurka/quietemerge/releases/tag/20141220

----------

## ppurka

Note (15 Mar 2015): Google Code is dead. But this script has been on GitHub for quite a few years already. So, no worries.  :Smile: 

----------

