[Bug libc/11878] 'glibc' build documentation is apparently incomplete

[Bug libc/11878] 'glibc' build documentation is apparently incomplete

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11878

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-05-16 13:51:46 UTC ---
Waiting for the submission of the documentation.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11878] 'glibc' build documentation is apparently incomplete

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11878

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-02-18 00:35:55 UTC ---
"incomplete" is not a useful bug report.  Feel free to file more specific bug
reports in the "manual" component that identify more specifically what is not
documented (for example, "the --enable-SOMETHING configure option is not
documented" or "the requirement that your processor support feature X is not
documented").

The bug you linked to, bug 11875, looks like it was a genuine configure bug
(rather than a doc bug) which was fixed by:

commit 84b9230c404aed4fd3a7bb3d045ca367043dde8c
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Mon Aug 23 07:51:49 2010 -0700

    Remove multiarch dirs when gnu indirect is not supported

In the course of fixing other problems, I have found that the installation
documentation is very out-of-date - documenting many things that are no longer
relevant or appropriate on current systems - and will be pruning the old
pieces.  Some of those were advice about particular circumstances that used to
be common but are no longer going to be seen - it's useful to add advice for
current circumstances, but that can only be done when we know the causes of
current build failures.  We do need to know about deficiencies in the
installation documentation.  But identifying such a deficiency from a build
failure requires that the person seeing the failure, with access to the system
on which it appears, debugs the failure so they can understand the underlying
cause.  That's what's meant by not filing build failures in Bugzilla: a build
failure by itself does not give enough information to be a useful problem
report, but information about the underlying causes of the failure can be a
useful report.  The libc-help@sourceware.org mailing list can provide help
debugging build failures and other problems to the point at which it is
possible to make a useful bug report, so please ask there if you have a failure
but do not have enough specific information about the underlying defect in
glibc.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11878] 'glibc' build documentation is apparently incomplete

[sergstesh at yahoo dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11878

Sergei Steshenko <sergstesh at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #3 from Sergei Steshenko <sergstesh at yahoo dot com> 2012-02-18 14:00:51 UTC ---
"
The bug you linked to, bug 11875, looks like it was a genuine configure bug
(rather than a doc bug) which was fixed by:

commit 84b9230c404aed4fd3a7bb3d045ca367043dde8c
" - how interesting. 

I.e. the build mechanism _does_ have bugs from time to time. But you, guys,
unlike in other FOSS project, do not accept bug reports against build mechanism
?

How outlandish. How discriminatory.


"
But identifying such a deficiency from a build
failure requires that the person seeing the failure, with access to the system
on which it appears, debugs the failure so they can understand the underlying
cause.  That's what's meant by not filing build failures in Bugzilla: a build
failure by itself does not give enough information to be a useful problem
report
" - sorry, I don't buy it.

I have filed "tons" of "'make' fails even though 'configure' is OK" bug reports
against various FOSS project, and in the vast majority of cases the bugs are
fixed.

Nobody had access to my computer; in most cases 'config.log' was sufficient for
the developers to fix the problems.

It looks like you guys at RedHat lack elementary debugging skills and
methodology.

In order to debug such failures remotely you need to tell the submitter which
'print' statements to insert into which files, and/or which debug tools to use
(for example, http://bashdb.sourceforge.net/remake/ helps quite a lot to debug
Makefiles).

So, guys, just don't try to sell us, the rest of the world, your discriminatory
attitude towards your own bugs in your own build mechanism.

It is against the very foundation of FOSS movements, whose one of the strongest
sale points is: (see, for example,
http://www.linuxplanet.com/linuxplanet/reports/7082/1/ ) :
"
By contrast, for most open source supporters, the licensing is a way to improve
the quality of software. The open source argument is that, because the source
code is available, bugs will be more easily discovered -- or, as Eric S.
Raymond put it, "with enough eyes, all bugs are shallow."
".

Thank you very much again for defeating the very purpose of FOSS by not
accepting bug reports (against build mechanism) and stonewalling any effort to
change the situation.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11878] 'glibc' build documentation is apparently incomplete

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11878

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-02-18 14:55:51 UTC ---
Whatever people may have said in the past, I would welcome reports of specific
build bugs in Bugzilla, presuming that they follow the instructions we provide
at

http://www.gnu.org/software/libc/bugs.html

about what should go in a bug report.  If there is difficulty in providing
"some way to replicate the problem", asking on libc-help is the way to go.  The
present report does not contain that information, and so is not a valid bug
report that can meaningfully be fixed.  The present report does not seem to be
describing any particular build failure at all.  Please file each separate
build problem in a separate well-defined bug report.

glibc is not a Red Hat project; it is a GNU project under the auspices of the
Free Software Foundation maintained and developed by a community of people most
of whom do not work for Red Hat.  I don't know why you are referring to Red Hat
here, but if you have problems with a Red Hat product please report them to Red
Hat.

We're planning to move the glibc FAQ to the wiki.  I'd be inclined to say we
should also close bug 333 at the same time, and officially say that build bug
reports in Bugzilla are fine if they have all the expected information - with
an explanation in the FAQ of what is relevant and of known build issues (such
as compilers defaulting to i386 rather than more recent x86; trying to build
for a ports architecture without the ports add-on; building with certain
distribution compilers that default to -fstack-protector; all of these should
of course be detected by configure, but the FAQ is the place for longer
explanations of how to fix them); the FAQ would also discuss how builds of
low-level system libraries such as glibc are intrinsically more complicated
than those of almost all other software.  But where build failures result from
old compilers, linkers etc., I think we should also be more active in
increasing the minimum versions required by configure (rather than trying to
work around deficiencies in older versions).  Roland, Carlos, Ryan - what do
you think?

Abuse of contributors is not acceptable in Bugzilla or elsewhere in glibc or
other free software development.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11878] 'glibc' build documentation is apparently incomplete

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11878

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.