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..._________________There is no spoon...

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?

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...

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.

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..._________________-- Woody2143

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??

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).

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.

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._________________No mail. No Plan.

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!_________________"Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions."
Terry Pratchett, The Truth

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 _________________only the paranoid survive

thx to Smooth and M104 for your advices, I've always been hunting for those colored stars in long emerge world._________________Appreciate Gentoo: Best Devs, Best Forums. YOU could help too: Help Answer

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.

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:

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

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?

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:

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.

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:

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._________________pihl