Log of emerge readable output produced somewhere?

Message

kcy29581 · Post by **kcy29581** » Sun May 15, 2005 11:05 pm

Genone wrote:
kcy29581 wrote:I can see why portlog-info is hard (or damn near impossible!) to break, as it does a simple thing: looks at portage's OWN logs and filters out certain key words/phrases.

However with enotice, how could it break portage or anything for that matter? I thought that it did a similar thing to portlog-info, but rather than looking at the logs, it looks at the direct output and juts makes easily-readable files. It can't actually delete anything right?
The point is that it's overriding internal functions (actually inherited from baselayout atm) and 2.1 a) doesn't allow that anymore and b) changes those functions for it's own logging. So it won't delete anything, but it won't work anymore and might cause some random problems.

Thanks for the info Genone! I'll have to remember that when portage-2.1 comes out...

Jeekay · Post by **Jeekay** » Sun May 29, 2005 11:15 am

# PORT_LOGDIR is the location where portage will store all the logs it
# creates from each individual merge. They are stored as YYMMDD-$PF.log

$ ls -l /var/log/portage
total 136
-rw-r--r-- 1 root portage 5346 May 29 12:05 3428-debianutils-2.13.1-r1.log
-rw-r--r-- 1 root portage 27598 May 29 12:07 3429-attr-2.4.19-r1.log

uh?

Post by **kallamej** » Sun May 29, 2005 5:56 pm

Jeekay wrote:# PORT_LOGDIR is the location where portage will store all the logs it
# creates from each individual merge. They are stored as YYMMDD-$PF.log

$ ls -l /var/log/portage
total 136
-rw-r--r-- 1 root portage 5346 May 29 12:05 3428-debianutils-2.13.1-r1.log
-rw-r--r-- 1 root portage 27598 May 29 12:07 3429-attr-2.4.19-r1.log

uh?

My /etc/make.conf.example (v 1.5.2.4 2005/02/15) says

# PORT_LOGDIR is the location where portage will store all the logs it
# creates from each individual merge. They are stored as NNNN-$PF.log

ozbird · Post by **ozbird** » Tue Jun 07, 2005 6:28 am

When installing some packages (e.g. postgresql), I've noticed that they sometimes include messages about what to do post-install to complete the installation. The problem is that these messages can be overlooked, particularly when doing an "emerge -e world". I've had a look through /var/log/emerge.log but the messages don't appear to be logged.

Is there a simple way to retrieve these messages without reinstalling the package?

I had considered writing a script to grep for einfo etc. in the ebuild, but I'm having trouble mapping the package name and version (e.g. dev-db/postgresql-8.0.2-r1) to the ebuild path (/usr/portage/dev-db/postgresql/postgresql-8.0.2-r1) as there isn't a consistent way to split the package name and version. Is there a reliable way to do this?

Broder1977 · Post by **Broder1977** » Tue Jun 07, 2005 6:42 am

I'm interested in this too. Emerging the packages step by step is no solution for me, but I won't miss the the tips given about important version changes and so on. It would make gentoo-ing much easier...

Bjoern

radfoj · Post by **radfoj** » Tue Jun 07, 2005 7:05 am

Log of emerge readable output produced somewhere?
Its the best thread I have found.

Maedhros · Post by **Maedhros** » Tue Jun 07, 2005 9:46 am

Previously duped, now merged from http://forums.gentoo.org/viewtopic-p-24 ... ml#2474467 to this thread.

Woody2143 · Post by **Woody2143** » Mon Jul 11, 2005 12:58 pm

kcy29581 wrote:I can see why portlog-info is hard (or damn near impossible!) to break, as it does a simple thing: looks at portage's OWN logs and filters out certain key words/phrases.

However with enotice, how could it break portage or anything for that matter? I thought that it did a similar thing to portlog-info, but rather than looking at the logs, it looks at the direct output and juts makes easily-readable files. It can't actually delete anything right?

For those of you who may have not seen it enotice has been updated. I too ran in to the "sandbox violation" errors and discontinued using it. Then the other day I took another look and found that the error was simple to resolve and the enotice script itself had been updated.

Go here to get it:
http://dev.gentoo.org/~eldad/

The problem seemed to be from where the notices were being stored. Sandbox didn't like it writing to "/var/enotice/" so it was changed to "/var/tmp/portage/enotice/". Becareful that you don't manually wipe it out or have a cleaner script that hits /var/tmp/portage until you've actually read all the notices... I just realized I could easily make that mistake myself...

Gentree · Post by **Gentree** » Mon Jul 11, 2005 7:48 pm

What versions are we refering to here?

Code: Select all

Calculating dependencies ...done!
[ebuild  N    ] sys-apps/sandbox-1.2.10  
[ebuild     U ] sys-apps/portage-2.0.51.22-r1 [2.0.51.19]

does enotice work with latest portage?

TIA

Zarhan · Post by **Zarhan** » Fri Jul 15, 2005 5:00 pm

Is there a schedule planned for portage 2.1 is release?

The roadmap at http://www.gentoo.org/proj/en/portage/index.xml is rather...terse (no dates anywhere, just "short term" and "long term" goals)

chashab · Post by **chashab** » Tue Jul 19, 2005 6:21 pm

something like this is needed badly and soon.

I was just emerging world and I heard a couple system beeps. I go to the term in question and hit scroll lock, the message:

PLEASE, PLEASE, PLEASE
Please run blah blah blah
ensure bad things won't happen.
blah blah blah

I go to run the program, accidently hit scroll lock again, and boom, message is off the frame buffer. And there is no log of it either. This is a production server I'm working on! How is one supposed to sanely admin gentoo boxes with no decent logging feature??

Zarhan · Post by **Zarhan** » Tue Jul 19, 2005 8:33 pm

I saw that too. However, I wouldn't take those too seriously, most of the reminders are just there to say "follow the standard updating procedure very meticulously".

(Standard upgrade: emerge sync && emerge -uvDaN world && emerge depclean && revdep-rebuild && dispatch-conf).

Most of the ebuild messages are usually just to the nature of "Do not forget to run revdep-rebuild" or "Do not forget to run etc-update/dispatch-conf". And yes, sometimes I forget some or all of those three last steps. Most of the time it's not that bad, but for occasional packages (like that one saying PLEASE PLEASE or whatever) revdep-rebuild is a must afterward.

When upgrading perl, it did notify me about perl-cleaner. That message has probably been around for at least a few perl versions, but this was the first time I noticed it. Nothing would probably been "broken", just in wrong directories if I hadn't noticed it.

(And that message did only say "use perl-cleaner"...perl-cleaner has quite a few options to try, so basically I guessed that "perl-cleaner all" is the correct option...they could be a bit more specific).

When is the planned release for 2.1?

username · Post by **username** » Thu Jul 21, 2005 8:50 am

chashab wrote:I go to run the program, accidently hit scroll lock again, and boom, message is off the frame buffer. And there is no log of it either.

I typically connect via ssh from a laptop our whole family shares so I always run my emerge sessions in a screen session. This allows me to detach, go to work, to bed, out shopping, or what-have-you freeing up the laptop for someone else. Screen also has a scroll-back buffer which has saved my butt a couple of times.

chashab · Post by **chashab** » Thu Jul 21, 2005 8:15 pm

Yes, I have switched to screen since then. Still the proper solution is logging. But I digress, it is being worked on...

-Smooth- · Post by **-Smooth-** » Sat Jul 23, 2005 3:22 am

There has to be a hundred ways to handle the output of an emerge...
(or any command with lots of output for that matter...)

If you don't want to lose any important messages, just log everything to a file.
You can make a directory such as /var/log/emerges to contain these.
# emerge package-name &>package-name.log

> redirects standard output
2> redirects standard error
&> redirects both

if you want to watch what's happening on the screen just run the emerge in the background (append a '&') and "tail --follow" the file
# emerge package-name &>package-name.log &
# tail -f emerge-package-name.log

...or you could try the "tee" command which redirects output to the screen and
a file simultaneously.
# emerge package-name 2>&1 | tee package-name.log

2>&1 redirects stderr to stdout

If you want smaller files, just use gzip. The compression
ratio on this kind of text output is always good. If you want a one-liner,
you can pipe to gzip like this...
# emerge package-name 2>&1 | gzip > package-name.gz

but it's probably safer memory-wise to just run it after the fact...
# emerge package-name &>package-name.log && gzip package-name.log

You can uncompress zipped logs on the fly and read them.
# gunzip -c package-name.gz | less

If you're looking for those notices, you can grep for the colored stars that
tend to accompany them. This regex seems to work.
# gunzip -c package-name.gz | grep "\*..0m"

You could filter the output through that before logging if you wanted.
# emerge package-name 2>&1 | grep "\*..0m" > package-name-notices.log

If this advice has come a little too late for you, you could always search
through the ebuild for ewarn and einfo messages.
# cat /usr/portage/category/package/package-name-1.2.3-r4.ebuild \
| grep '$ewarn\|einfo$ "' > ebuild-messages.txt

Of course I have to mention that the screen command is definitely worth learning as well.

Anyway, none of this stuff is all that advanced. Of course portage could use some improvement, but ultimately everyone's responsible for their own server. Before pointing fingers at the people who bring us this OS for free, and these tools for free, I think we should all try to use these brains we got for free and really learn how to use them. Most problems can be solved and automated with a good knowlege of bash scripting and a little hard work.

nmbrthry · Post by **nmbrthry** » Mon Jul 25, 2005 1:57 am

-Smooth- wrote: ...

You can uncompress zipped logs on the fly and read them.
# gunzip -c package-name.gz | less

If you're looking for those notices, you can grep for the colored stars that
tend to accompany them. This regex seems to work.
# gunzip -c package-name.gz | grep "\*..0m"

There are also nice commands like zgrep, zcat, zmore, zless, etc. which save you from having to pipe output from gunzip. For bzip2 users, try bz* on some of those same commands.

M104 · Post by **M104** » Sat Jul 30, 2005 6:26 am

Here's what I'm doing currently:

Create a portage log directory (if you don't have one already):

Code: Select all

comp ~ # echo "export PORT_LOGDIR=/root/portage/log" >> /root/.bashrc
comp ~ # source /root/.bashrc
comp ~ # mkdir -p $PORT_LOGDIR

Create portlog.sh:

Code: Select all

#!/bin/bash

[ -z "$1" ] || PATTERN="$1"

cd $PORT_LOGDIR

grep -c "\*..0m" * \
  | grep "$PATTERN" \
  | egrep -v ":0$" \
  | sed 's/^\(.*\):.*$/\1/' |
  while read FILE; do
    PKG=`echo "$FILE" | sed 's/^[0-9]*-\(.*\)\.log$/\1/'`
    echo "==> $PKG"
    grep "\*..0m" $FILE
    echo ""
  done

Emerge some stuff, then run portlog.sh! All it does is let you see what messages are associated with which packages, but it's fine for me right now. Maybe later I'll whip something up that's smarter, but hopefully this'll help someone. The best part is, you can do all of this even before starting a stage1 installation!

Edit: Fixed the script so that only files with interesting info are displayed.
Edit: Added a search term as the first argument. Try it and see!

ixion · Post by **ixion** » Fri Aug 26, 2005 5:03 pm

-Smooth- wrote: Anyway, none of this stuff is all that advanced. Of course portage could use some improvement, but ultimately everyone's responsible for their own server. Before pointing fingers at the people who bring us this OS for free, and these tools for free, I think we should all try to use these brains we got for free and really learn how to use them. Most problems can be solved and automated with a good knowlege of bash scripting and a little hard work.

Nicely put. Cheers for the advice

dundas · Post by **dundas** » Sun Nov 27, 2005 3:48 am

thx to Smooth and M104 for your advices, I've always been hunting for those colored stars in long emerge world.

nmbrthry · Post by **nmbrthry** » Sat Dec 17, 2005 6:29 pm

Portage 2.1-pre is now in Portage! (That sounds kind of funny...)

The new elog support does what we wanted: it creates a single file with all of the messages from the emerge, and you can set the minimum level of verbosity in make.conf (info, warn, error, log). There are other options instead of creating files, but this is the one I have tried.

linuxtuxhellsinki · Post by **linuxtuxhellsinki** » Tue Jan 03, 2006 12:09 am

I played a little bit with grep command in /var/log/portage-dir & I've got quite nice results with the next command pointed to the last (31*) hundred of emerge.logs

Code: Select all

portage # grep "\*..0m" 31* |grep -v "patch\|diff\|Running\|Building\|Purging\|Updating\|Moving\|Cleaning\|Fixing\|Skipping\|Removing"

Edit : Cut some words from the command cause it was widing the screen, so you can add these also

Code: Select all

\|Configuring\|Creating\|Replacing\|Generating\|Installing\|Setting\|Stripping\|Preparing\|Installing

You can of course direct the command to just for those logs you want like between [3050-3170]

And I did get this kind of output.

Code: Select all

3109-DirectFB-0.9.22.log: * Each DirectFB update in the 0.9.xx series
3109-DirectFB-0.9.22.log: * breaks DirectFB related applications.
3109-DirectFB-0.9.22.log: * Please run "revdep-rebuild" which can be
3109-DirectFB-0.9.22.log: * found by emerging the package 'gentoolkit'.
3109-DirectFB-0.9.22.log: *
3109-DirectFB-0.9.22.log: * If you have an ALPS touchpad, then you might
3109-DirectFB-0.9.22.log: * get your mouse unexpectedly set in absolute
3109-DirectFB-0.9.22.log: * mode in all DirectFB applications.
3109-DirectFB-0.9.22.log: * This can be fixed by removing linuxinput from
3109-DirectFB-0.9.22.log: * INPUT_DRIVERS.
3111-gettext-0.14.4.log: * Any package that linked against the previous version
3111-gettext-0.14.4.log: * of gettext will have to be rebuilt.
3111-gettext-0.14.4.log: * Please 'emerge gentoolkit' and run:
3111-gettext-0.14.4.log: * revdep-rebuild --soname libintl.so.2

___________________________________________________________________________________________

Edit : I've made alias for that command but I've one problem with it, when I try to change that 33* to $1 so I could add options to the command then it's not grepping anymore. So is there a way to make it work

Code: Select all

alias logrep="grep \"*..0m\" 33* |grep -v \"patch\|diff\|Running\|Building\|Purging\|Updating\|Moving\|Cleaning\|Fixing\|Skipping\|Removing
\|Configuring\|Creating\|Replacing\|Generating\|Installing\|Setting\|Stripping\|Preparing\|Installing\""

Paapaa · Post by **Paapaa** » Tue Jan 17, 2006 10:12 am

Zarhan wrote: When upgrading perl, it did notify me about perl-cleaner. That message has probably been around for at least a few perl versions, but this was the first time I noticed it. Nothing would probably been "broken", just in wrong directories if I hadn't noticed it.

Thanks for the tip! I also never noticed that one (and who knows how many other important messages I have missed). A few packages needed to be reemerged according to "perl-cleaner all ask". I still wonder what is the easiest way to see all this kind of important messages after doing "emerge -uD world". Maybe the next release will address this issue?

radio_flyer · Post by **radio_flyer** » Sat Mar 25, 2006 6:51 am

Thanks for the tip! I also never noticed that one (and who knows how many other important messages I have missed). A few packages needed to be reemerged according to "perl-cleaner all ask". I still wonder what is the easiest way to see all this kind of important messages after doing "emerge -uD world". Maybe the next release will address this issue?

It's low-tech, but I usually use the command:

Code: Select all

script world

and then do the emerge. (Use 'world' or any other filename you want.) When the emerge finishes, I hit CTRL-D to close the file. I then use less to browse the file and search for "omitted". That's a line output by portage when it starts installing the package over a previous revision. Just above this line will be the einfo output of the package that is being installed. It will be nice when emerge has the ability to filter these lines out to a file itself.

sonicbhoc · Post by **sonicbhoc** » Wed Apr 05, 2006 1:16 am

you could use kuroo (emerge -av kuroo) to emerge stuff, but I'm pretty sure we don't want that, so just fire up Nano and read the ebuild, the information is stored in there somewhere!

pgrdsl · Post by **pgrdsl** » Thu Apr 06, 2006 5:26 pm

nmbrthry wrote:The new elog support does what we wanted: it creates a single file with all of the messages from the emerge, and you can set the minimum level of verbosity in make.conf (info, warn, error, log). There are other options instead of creating files, but this is the one I have tried.

Indeed it does - I've just enabled it and it is vastly better than what has gone before. I've currently got:

Code: Select all

PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="mail"
PORTAGE_ELOG_MAILURI="root@localhost localhost"

in my /etc/make.conf.
I started off with "save" in the PORTAGE_ELOG_SYSTEM, but having the messages emailed to me is so much nicer than having to remember to look for files.

This is a great improvement and many thanks for it being implemented. I'm almost tempted to rebuild my system just to find out what messages I've missed in the past... or maybe not.

Log of emerge readable output produced somewhere?

Finding installation messages for existing packages?