Mailing List Archive

Re: Digest of issue 367 (13009-13035)
On Tue, 2011-07-05 at 13:02 +0000,
> On Thu, 30 Jun 2011 21:36:38 -0700
> Mark Knecht <> wrote:
> >
> > I think it's completely appropriate for this list. This
> distro expects
> > that we put CFLAG options in make.conf so I need to hear
> about this
> > stuff even if I don't have to background to completely
> understand
> > what's really causing the problem.
> >
> In this case, or in the case of any program where
> "-fno-strict-aliasing"
> could make a difference, the maintainer of the program would
> include
> the option in the ebuild. The user would not have to worry
> too much
> about it.
> But yes, it is always good to know about the compiler flags.
> To see exactly what compile flags are being used in your
> programs, here
> is a neat method I picked up from somewhere. Just open a
> terminal and
> enter the following command:
> echo 'int main(){return 0;}' > test.c && gcc -v -Q $CFLAGS
> test.c -o test && rm test.c test
> In place of $CFLAGS just substitute any option of interest.
> There will
> be a flood of output, but just scroll back a few lines to find
> the "options
> passed:" and "options enabled:" sections.
> For example, using "-O2" for $CFLAGS indicates that
> "-fstrict-aliasing" is
> used, but it is not used with "-O1."
> It also shows that with "-O2" the option "-mno-sse4" is used,
> and so if
> you want to use SSE4 for certain programs (e.g. video, audio)
> you will
> need to specifically enable it.
> There may be an even slicker way to reveal the flags, but this
> is the
> only way I know.
> Frank Peters

An example of the issue discussed

see in particular comment #3 they are understaffed and have a ton to do
but in the norm don't care to here it.

Is a discussion/flame about the report upstream qa messages.
Help me out here guys and weigh in. (dons flame suit)

Further on the conversations wandered-to in the topic 'optimization'
in the kernel config menu under the heading 'General Setup' lies
[*] Optimize trace point call sites


If it is detected that the compiler has support for "asm goto", the
kernel will compile trace point locations with just a nop instruction.
When trace points are enabled, the nop will be converted to a jump to
the trace function. This technique lowers overhead and stress on the
branch prediction of the processor.

I've had this checked for a good deal of time and see no issues because
of it.

David J Cozatt
aka user99
Re: Digest of issue 367 (13009-13035) [ In reply to ]
DJ Cozatt posted on Fri, 08 Jul 2011 16:46:38 -0400 as excerpted:

> Is a discussion/flame about the report upstream qa messages.
> Help me out here guys and weigh in. (dons flame suit)

FWIW, glad to see someone dealing with those QA warnings, but one picks
their battles based on time and skillset available, and that's one I've
deliberately chosen to ignore.

My feeling is, the gentoo maintainers obviously see the warnings when
they test for version bumps, etc, so they know about them. Since they
already do know about them, it does nothing but irritate them to file
bugs about them, especially when one doesn't really have the coding
skills to help much, and the package in general remains working.
Meanwhile I've picked the upstreams I'm involved with and try not to
think too much about the others, as there simply isn't time for all of

So mostly I just ignore the QA warnings unless something actually breaks,
figuring the gentoo folks already know about them, and unless it's on the
list of upstreams I'm already involved with or something is really
broken, given I don't generally have the skills to provide a fix in any
case, it simply falls off the bottom of my priority scale.

That said, why are the QA notices there if the general user isn't
equipped to deal with them? Remove them?

I'd say no. At a minimum, they serve a shaming function. Ideally, the
issues would be fixed right away, most ideally in testing, before the
package is ever unmasked in-tree, but if that doesn't happen, and in the
real world it obviously doesn't all the time or we'd not be seeing the
warnings (devs have time issues too), the warnings do serve as a gentle
prod and reminder that there are issues that need dealt with. And over
time, hopefully, the brown-bag (embarrassment, the reference is to
someone so embarrassed that they wish to cover their head with a bag so
as to remain anonymous) factor of having so many warnings in one's
packages gets big enough to bump them on a devs priority list, and they
get fixed. If those warnings were to disappear except when activated by
some developer flag, the brown-bag factor would be far lower, and perhaps
fewer of them would be fixed.

I believe that shaming function is a big part of why those QA warnings
are there in the first place. Removing them is thus not a good idea.

Plus, they motivate users (like you) who DO have the skills and time to
help out, occasionally. That's not a bad thing. =:^) Certainly not, for
an all-volunteer distro that's chronically understaffed. =:^\

But as I said, for me, I pick my battles, and that's not one I've picked.

Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: Digest of issue 367 (13009-13035) [ In reply to ]
On Fri, 08 Jul 2011 16:46:38 -0400
DJ Cozatt <> wrote:

> Is a discussion/flame about the report upstream qa messages.
> Help me out here guys and weigh in. (dons flame suit)

To be honest, I am still quite surprised at the fact that distribution
maintainers even waste time fixing obvious bugs, let alone QA
issues. If anything, outright bugs should be the responsibility
of the upstream developers and only of the upstream developers.
Yet there seems to be this many-tiered approach to reporting and
fixing bugs, with each distribution maintaining its own independent
set of reports and patches. This makes little sense. For example,
there are patches available on Gentoo (and other distributions as well)
that are needed to fix certain software bugs but these same patches
are not included in the original source code. The way I see it,
there is much manpower being wasted by having all of this duplicated

Upstream developers should be very accommodating when it comes
to bug reports. After all, the software is *their* creation and
their sense of pride -- if nothing else -- should impel them
to release the best possible code.

But upstream developers are known to sometimes be less than
enthusiastic about bugs. I experienced an issue recently with
the login program and thought it best to make a report to
upstream only (
After a long period with no significant response I decided to file
a report with Gentoo (
The Gentoo developers tackled the problem and found the source
of the error. I reported these results back to upstream where
hopefully the bug will be fixed, but there should not have been
the need to approach both parties.

As far as QA issues, this should definitely be only the concern
of upstream developers. The only way to improve code for every user
is to put pressure, in the form of constructive criticism, on upstream
to adhere to good coding practice.

> Further on the conversations wandered-to in the topic 'optimization'
> in the kernel config menu under the heading 'General Setup' lies
> [*] Optimize trace point call sites

Is This option for debugging purposes? If so then there is no
need for it with ordinary user builds.

Frank Peters