In http://sourceware.org/bugzilla/show_bug.cgi?id=11875#c10 one can read: " Of course this is a 333 dup. Don't ever file build problem reports in BZ. This is what mailing lists are for. ". So, the lead 'glibc' developer openly claims one can't get knowledge on how to build 'glibc' in places other than mailing list. I think that the logical place to look for such knowledge is the documentation which comes with the source. Just wondering - is the official RedHat policy ? I.e. does RedHat think that users of its software should look for info in mailing lists rather than in the documentation which comes with the software ?
Waiting for the submission of the documentation.
"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.
" 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.
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.