elog – why it’s so important and why you must read it

That’s not the first post about elog, previously Gilles (eva) posted an excellent entry about that (he was a slightly angry probably :p). All these entries are published in order to warn users and they have its importance…So based on that fact it would be really nice if users start reading them πŸ˜€

Last week, I did read at least 4 bugs about a problem due the newer version of shared-mime-info (which includes a new database format)… If you as users would read your elogs, guess what? Yes you would find the solution in elog messages.

[b][size=15]Important…why ?[/size][/b]

When a developer has a important message to deliver to a set of users for a given package, usually he uses elog (elog is logged => no excuses..).
Consider the previous example with shared-mime-info, you will have a lot of problems when you try to open some files (typically gnome/kde startup) which would have not happened if you have a look at your logs.

[b][size=15]awesome… but how I can read them ?[/size][/b]

That’s seriously simple :
[*] If you’re a geek who loves GTK+ based applications (like me :p) have a look at elogviewer
[*] Use eread (c.f: man eread)

But for our sanity and peace in our souls “READ THEM” before you post a bug πŸ™‚ .
That will help us a lot, by implicitly reducing the number of useless bugs, and in this way, we will not have to repeat things 50 times.

have fun with gentoo πŸ˜‰

edit: many thanks to scarab for typos & grammar πŸ˜‰

31 thoughts on “elog – why it’s so important and why you must read it”

  1. Never heard of eread, let me try…

    1203) app-admin:eselect-1.2.4:20091009-151319.log
    1204) kde-base:kdeplasma-addons-4.2.2:20090412-092007.log
    1205) dev-libs:wicked-9999:20090919-154603.log

    Oh boy.

  2. well, I did use the elogviewer but the message in shared-mime-info had a bunch of prblems:
    – it was just a notice, not a warning
    – the given paths in the message have been incorrect (/usr/local)

    And I keep asking myself why the ebuild didn’t just rebuild the database automagically…

  3. I believe that this is why we introduced news items in the first place, and that expecting users to read elog does not really work.

  4. Another really good option is to set /etc/make.conf:PORTAGE_ELOG_SYSTEM=”save mail”, and set the other PORTAGE_ELOG_MAIL* params. No silly gtk app needed, but (way) better than the atrocious eread.

    @jkt I think you need both types of notices (pre- and post-install), but if you don’t expect people to read elog, why would you expect them to read news? πŸ™‚ AIUI, unstable portage is more … forceful about shoving unread news items in the user’s face … maybe it should do something similar with (certain types of?) elog output, too. That’s really what the “win” is, of course: the policy change about requiring user acknowledgment of news vs. elog messages.

    It’s reall a shame the Handbook doesn’t even mention, let alone suggest, any of this stuff in the various sections it could be in. πŸ™

  5. It is quite easy to miss messages when there are 40+ updates to install.

    It would be better to remove some of the repeated messages that are the same all time and just display them when the message is ‘new’. Right now important information easily gets lost in a sea of information garbage that tells you for the umpteth how you should set up your applications.

    elog “(as root) # update-mime-database /usr/local/share/mime/”

    Isn’t that the system database?

    Couldn’t it be automated just by looping over all the users?

    for user in [ cat ‘/etc/passwd’ | cut -d ‘:’ -f1 ]; do
    if [ -f “~${user}/.local/share/mime/” ]; then
    update-mime-database “~${user}/.local/share/mime/”

    Just a general idea from an inexperienced fool… completely untested.

    Btw, are you blocking gmail addresses? Your validator kept calling it invalid…

  6. I do read the log file. I read it everytime after upgrade, it’s important.
    However, I’ve installed a fresh _minimal_ KDE Desktop recently and the size of the file became 100k. So I told myself .. f..k it, I’m not going to read it this time.

    As a side note, if I missed something in the log file, like I forgot to run revdep-rebuild -l lib.so and that old library is still in the system, how do I discover that old and forgot library?
    This is important if you’ve been asked to fix somebody else Gentoo installation.

  7. @Arc /usr/local directory is a system dir for all packages does not installed by portage (usually installed by hand from tarball, but it can be useful by some tools like layman for example, c.f devmanual πŸ™‚ )

    I was talking about that :
    pkg_postinst() {
    blah blah

    and the user specific update can’t be done

  8. Why should I bother reading elog when it contains ancient and rotting info in most of the cases? Puh-lease, most ebuilds just spam the log/output/einfo with ancient, rotting information that doesn’t partain anymore.

    Weeding out the useful “new” stuff from an ebuild is almost as much a headache as trying to find the cause of bugs afterwards without it. Perhaps more.

    The current system needs fixing to make the log output less egregiously annoying.

  9. Well, this would have been useful to know about long ago! Uh, some (many? most?) of us don’t use eTHIS or eTHAT becase we don’t know it exists or were never told what it is for. We’re not being lazy; we’re being uninformed.

    Thanks for telling us about the elog stuff. I will be using it, now that I know.

  10. “We’re not being lazy; we’re being uninformed.”

    you’re informed now πŸ™‚

    “Thanks for telling us about the elog stuff”

    you’re welcome, hehe that’s my job πŸ˜‰

  11. “What is the recommend PORTAGE_ELOG_CLASSES setting in make.conf? “

    have a look at /usr/share/portage/config/make.conf.example, you’re also able to send an e-mail to yourself when there are some elogs πŸ™‚

  12. Ok, elogviewer

    unticked INFO and LOG and clicked refresh.

    2 entries from sys-auth pambase – saying “LOG (postint)”. Actually, quite a lot of packages say this or something similar. Wow, most messages are this.

    Entry from qt saying I may have to recompile some packages, no real way of finding these, perhaps kdelibs, but nothing concrete. Guess if I’m having problems I can try this.

    Warning that libdrm has changed without a version number change. At least I have a list of packages to recompile, but I haven’t had any problems from this.

    Python warning about bsddb. I don’t know what this is, but apparently it’s now in a separate package. If another package needs it, shouldn’t it pull it in? I don’t use it myself, so what do I do? I’m going to ignore it.

    Warning from samba saying I need to restart clients. Not sure if I updated from the version it’s on about or not. I’m pretty sure I only use clients, not the server side. Actually I’m not entirely convinced if I need samba installed now. The only clients I have are mountpoints.

    nvidia-drivers, build fail. Yeah I remember that.

    xorg server going on about reduced blanking modelines and an old warning about updating from 1.5.

    xinit is giving me some nice helpful information about how to use startx. As a big red warning.

    Apparently websvn can’t find /.webapp … ok

    Ok, I’m bored and there’s a load more messages that I’m pretty sure at this point that I don’t care about. It’s taking a lot of energy to consistenly work out that they don’t apply to me.

    I’m not sure how many are left, but the scroll bar’s less than 1/4 of the way down. And I do remember running this a few weeks back.

    If I’m having trouble, then yes it’s a good idea to look in here, but I’m not going to look in here often, and to be honest, because I don’t regularly use it, I keep forgetting about it.

  13. @JimT then you should work it into your update process. You should review the messages that ebuilds provide to you every time you emerge, so you don’t have a huge glut of messages to get bored reading. If you update weekly, you maybe get 10 short messages to read; it’s not a big deal to stay on top of it.

    It’s like, “I’m bored following the medical advice my doctor gave me, I’m just going to stop taking these pills”. The builds go out of their way to provide you necessary instruction. Sometimes they provide too much and useless info, true, and that should be corrected. But the critical instructions are easy to find and follow.

  14. Yeah, I remember reduced blanking popping in for three years or more!.. It was a warning displaying on the terminal at first and then it keeps displaying in elog! All the time! WTF is reduced blanking? From what era is that setting? πŸ™‚

    Also, some packages say ‘you will need to recompile some packages’ or ‘you need to run revdep-rebuild now’ a lot of times for different packages. Why not display it once for one emerge run? In such a way that etc-update notice is displayed.

    Also, some packages (can’t remember now) keep telling me that ‘en (!) ru uk locales not supported’. What? Not a big deal. And I must read it from compile to compile…

    Also there are a lot messages about regarding upgrading packages from version x to version y, but it’s already version z for year or two or even three…

    Gentoo developers, pleeaaase clean up those messages of different irrelevant information garbage.

    P. S. Why don’t you like gmail addresses??

  15. @evadim
    Sounds awesome! Too bad it doesn’t appear to work with Gmail or at least it didn’t for me πŸ™
    Config instructions for those interested:


    /usr/local directory is a system dir for all packages does not installed by portage (usually installed by hand from tarball, but it can be useful by some tools like layman for example

    I have my own custom ebuilds and scripts there and use layman, so I know what /usr/local are there for, sort of.
    Doesn’t make me less puzzled as to why you would need two sets of databases though, with the ‘local’ one just being a set of empty files and directories :-/

    c.f devmanual

    At the time the comment box were more readily at hand πŸ˜›
    I’ve read the GNOME documentation ( http://library.gnome.org/admin/system-admin-guide/stable/mimetypes-database.html.en ) and glossed over the Freedesktop spec ( http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html ) if that’s what you meant with the devmanual… ← just as an FYI πŸ˜›


    Oops, didn’t notice that function for some reason.

    and the user specific update can’t be done

    _ I’m writing this out of curiosity and no other reason.
    _ Though, feel free to ignore this answear if it bothers you.
    ↑ Wrote the above because I’ve had… ‘problems’ in the past related to these ‘sorts of’ questions.

    I did some experimenting yesterday and it seems to work from that.

    * The database format has changed between 0.60 and 0.70.
    * Mime info databases will now be updated automatically.
    * Updating shared mime info database …
    * Updating ‘local’ shared mime info database…
    * Updating mime info database for /home/username
    * Updating mime info database for /root…
    * If a user is not listed above you will have to
    * manually update their database
    * $ update-mime-database ~/.local/share/mime/

    Though, this is on a machine with one normal user and an ‘SSH user’ (i.e. no mime database) so it’s not much of a test.
    Using the not so pretty code:


    if [ -d ‘/usr/local/share/mime/’ ]; then
    einfo “Updating ‘local’ shared mime info database…”
    update-mime-database ‘/usr/local/share/mime/’ || (
    ewarn ‘ Auto-update failed, run manually as root:’
    ewarn ‘ # update-mime-database /usr/local/share/mime/’ )

    for userhome in $( echo /home/* ) ‘/root’ ; do
    if [ -d “${userhome}/.local/share/mime/” ]; then
    einfo “Updating mime info database for ${userhome}…”
    export XDG_DATA_HOME=”${userhome}/.local/share”
    update-mime-database “${userhome}/.local/share/mime/” || (
    ewarn ‘ Auto-update failed, run manually:’
    ewarn ” $ update-mime-database ${userhome}/.local/share/mime/” )

    Of course, the files are owned by root but there seems to be no detrimental effect caused by that. But that’s easily fixed using chown.
    An interesting thing I noticed though is that running update-mime-database ~/.local/share/mime/ as username re-created the files with the ‘proper’ ownership, no questions asked, even though root is the only with the right to write…

  16. For me, elog is not satisfactory.

    I wrote a script to do:
    $ emerge -vO app-foo/bar &>
    and a script to view logs with bash completion for package names.

    I like to save output of emerge *per package*, but it forces to me to use -O option to achieve it. I’ll be glad a lot if elog supports my use..

  17. @Arc may be gmail not support non-ssl/non-tls connections (and it send garbage in resource), for “normal” XMPP accounts it work

  18. @Foofoo Barbar (in case you come back)…

    Take a look at the man page for emerge and “-O”; I’m pretty sure it does not do what you think it does.

    Instead, in /etc/make.conf, add:


    and per-package emerge output will be in /var/log/portage/{cat}:{PV}:{timestamp}.log

  19. There’s two messages in the queue so this might already be answered, but here goes anyway.

    @Foofoo Barbar
    Have a look at the /usr/share/portage/config/make.conf.example file as mentioned by Mr. Pouet earlier. Specifically, what I think you’re looking for are the PORTAGE_ELOG_SYSTEM setting. The default value for that is “save_summary echo” as seen in /etc/make.globals.
    For some reason there are no description in the manual (man make.conf) for this setting.

  20. @evadim
    It gets to and executes the row “client.send (message)” and debugging the script during emerge reveals that all the variables are set correctly. No exceptions are raised during execution either :-/

  21. Thanks, jsled and Arc. You’re right. I remember that last time I tested elog it somehow disappointed me. I don’t know why. (It was portage-, but seems that elog hasn’t changed since then. I missed something at that time?)

    > I’m pretty sure [-O] does not do what you think it does.
    First I try -vp, so no problem, if it’s what you mean. πŸ™‚ Thanks anyway.

Comments are closed.