public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Cc: Tanstaafl <tanstaafl@libertytrek.org>
Subject: Re: [gentoo-user] emerge -e system - output info/errors to log
Date: Sun, 18 Apr 2010 19:56:46 +0200	[thread overview]
Message-ID: <201004181956.46928.alan.mckinnon@gmail.com> (raw)
In-Reply-To: <4BCB4364.1000402@libertytrek.org>

On Sunday 18 April 2010 19:37:40 Tanstaafl wrote:
> On 2010-04-18 1:05 PM, Alan McKinnon wrote:
> > On Sunday 18 April 2010 17:38:19 Tanstaafl wrote:
> >> I must be missing something obvious...
> >> 
> >> When updating gcc, and thus emerging -e both system and world
> > 
> > Why are you doing that?
> 
> Because it wasn't a minor bugfix update? I'm going from 4.1.2 to 4.3.4.

So what?

Is there an ABI change between 4.1.2 to 4.3.4 that causes apps built with 
4.1.2 to break on 4.3.4?

> > > Have you verified that you have in fact updated gcc from one version
> > to another with an incompatible ABI?
> 
> Since the GCC upgrade guide doesn't mention a way to do this, no, I
> haven't... so how does one verify this, Obi-Wan? ;)

Understand what the gcc upgrade guide is:

a quick simple guide for user who don't know tool chains inside out, that give 
the minimal sequence of commands that is GUARANTEED to NOT leave the user in 
the lurch. It's not the minimum possible sequence of commands to do the 
upgrade, because most users don't know how to tell the difference. Here's the 
logic:

"If we imply that you should merge -e world with a gcc upgrade, my inbox will 
not fill with bugs from users who don't know the inner guts of the toolchain".

The Guide is not the best possible guide that can be. It is the guide that 
causes the least support questions from users.

> > There is a false idea floating about that gcc updates require
> > updating -e world.
> > 
> > This is not true.
> 
> I've heard this before, but could never get a definitive answer on how
> to know for sure when you do and don't need to...

When the gcc devs release a new version, they will announce that there is an 
ABI break, and what it applies to. It doesn't happen often, but when it does,
the gentoo maintainer ought to put a note in the ebuild.

They are quite diligent about this, much like the KDE/Qt devs do the same 
thing when Nokia breaks Qt compatibility.
 
> >> where are the info/warn/errors logged? I see a whole bunch of
> >> separate/individual logs ion /var/log/portage/elog, but what I'm
> >> looking for is a single, easily readable log of all of the result
> >> info/warn/errors for each package.
> > 
> > Configure it in /etc/make.conf, mine looks like so:
> > 
> > PORT_LOGDIR=/var/log/portage
> > PORTAGE_ELOG_CLASSES="warn error log qa"
> > PORTAGE_ELOG_SYSTEM="save"
> 
> I have the last two, but didn't have the first - just added it...

I think that's the default. I have it just to be explicit.

> 
> So, does adding the first entry provide an overall emerge.log with just
> all of the messages in it that I can review?
> 
> > Adapt to you own needs.
> > 
> > If you don't have this configured, then the logs are not stored. To
> > see them again, read the ebuilds or re-run emrge
> 
> Like I said, I have a bunch of *individual* logs (for individual
> ebuilds)... I was hoping for something a little easier to manage/read,
> all in one file...

for I in $(ls -1rt /path/to/emerge/logs/*) ; do cat ${I} >> some_log_file ; 
done
 
-- 
alan dot mckinnon at gmail dot com



  reply	other threads:[~2010-04-18 18:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-18 15:38 [gentoo-user] emerge -e system - output info/errors to log Tanstaafl
2010-04-18 15:41 ` Tanstaafl
2010-04-18 17:40   ` Dale
2010-04-18 17:05 ` Alan McKinnon
2010-04-18 17:37   ` Tanstaafl
2010-04-18 17:56     ` Alan McKinnon [this message]
2010-04-18 18:10       ` Neil Bothwick
2010-04-28 17:38       ` Tanstaafl
2010-04-28 21:02         ` Dale
2010-04-18 18:05     ` Neil Bothwick
2010-04-28 17:47       ` Tanstaafl
2010-05-06 13:04       ` Tanstaafl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201004181956.46928.alan.mckinnon@gmail.com \
    --to=alan.mckinnon@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    --cc=tanstaafl@libertytrek.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox