[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]


I'm sending this mail because libc maintainer seems to have closed
the bug I've issued without doing any investigation on his own.

Here's my original message


        libc6-dev: PTHREAD_ERRORCHECK_INITIALIZER_NP not defined as claimed in docs
        Wed, 03 May 2000 22:03:20 +0300
        Eray Ozkural <erayo@cs.bilkent.edu.tr>

Package: libc6-dev
Version: 2.1.3-8
Severity: normal

The preprocessor macro seems to be undefined. There are also other
subtleties while using pthread lib, such as the __USE_UNIX_98 stuff,
which I really don't know (I only use c++, and UNIX_98 sections don't
seem to come along. Why is that?)

Thanks a bunch,


Now, I think what I say is fairly obvious but the package maintainer
dismisses this bug like this with a changelog entry:

* No reference to which docs, nor is there a test case, so: closes: #63511

The maintainer might have a lot of things to do, the package might
have too many bugs open, and in the course of eliminating bugs he might
have been too quick in his assessment. I DON'T CARE. If he hasn't the
time/energy/mood to cope with a clear bug report like this (only the
subject line is enough, the body is just comments) then I think more than
one developer must work on libc maintenance; I don't know how many
maintainers it currently has...

Anyway, here is the _explanation_ for the bug report.

  There's a preprocessor symbol in posix threads. It's called
PTHREAD_ERRORCHECK_INITIALIZER_NP. I claim that it has not been
defined although it is said to be defined in the docs. Which
docs? Obviously, the info manual since there is only *one*
freakin' manual. Where in that manual? Any luser with a
info browser that can search would find it:

File: libc.info,  Node: Mutexes,  Next: Condition Variables,  Prev: Cleanup Handlers,  Up: POSIX Threads


     Variables of type `pthread_mutex_t' can also be initialized
     statically, using the constants `PTHREAD_MUTEX_INITIALIZER' (for
     recursive mutexes), `PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP' (for
     fast mutexes(, and `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP' (for
     error checking mutexes).

So. That's where I say it is.

Also I'm saying that I was using the lib from C++, so might this be
causing my problem? And I pointed out that there might be some
other problems with the preprocessor symbol _USE_UNIX_98.

Of course, as the mighty maintainer of libc, Ben *does* know about
UNIX 98 I presume. And that UNIX 98 *is* supported in libc, while
in that version of the package it seemed to be *unsupported*.

  * re-open the bug
  * learn about pthread, learn about preprocessor symbols
in pthread, learn about UNIX 98, learn about info browsers.
  * find the corresponding node in the info manual.
  * find out if it is defined or not.
  * if it is not defined
    * investigate why not.
    * see if this has any relation with _USE_UNIX_98 as hinted
in the bug report
    * fix it
  * else
    * request submitter to replicate the bug
    * investigate further

If bug submitters did all the maintenance work themselves, then
there would be little need for the maintainer(s). I don't have
to submit a test program for a bug as obvious as this one, neither
do I have to submit a patch. That's maintainer's responsibility.
I've just reported what I had thought, some many many months ago,
to be a problem. Of course, the maintainer has not done anything
about this report for 7 months, and then he closes it like that.
Not good.


Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo
--- Begin Message ---
This is an automatic notification regarding your Bug report
#63511: libc6-dev: PTHREAD_ERRORCHECK_INITIALIZER_NP not defined as claimed in docs,
which was filed against the libc6-dev package.

It has been closed by one of the developers, namely
Ben Collins <bcollins@debian.org>.

Their explanation is attached below.  If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact the developer directly, or email
63511@bugs.debian.org or me.

Darren Benham
(administrator, Debian Bugs database)

Received: (at 63511-close) by bugs.debian.org; 29 Dec 2000 20:17:00 +0000
>From troup@auric.debian.org Fri Dec 29 14:17:00 2000
Return-path: <troup@auric.debian.org>
Received: from auric.debian.org [] (mail)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14C5xU-0005hm-00; Fri, 29 Dec 2000 14:17:00 -0600
Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian))
	id 14C5cZ-0002Op-00; Fri, 29 Dec 2000 14:55:23 -0500
From: Ben Collins <bcollins@debian.org>
To: 63511-close@bugs.debian.org
Subject: Bug#63511: fixed in glibc 2.2-7
Message-Id: <E14C5cZ-0002Op-00@auric.debian.org>
Sender: James Troup <troup@auric.debian.org>
Date: Fri, 29 Dec 2000 14:55:23 -0500
Delivered-To: 63511-close@bugs.debian.org

We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:

  to pool/main/g/glibc/locales_2.2-7_all.deb
  to pool/main/g/glibc/libc6-dbg_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-i686_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-i586_2.2-7_i386.deb
  to pool/main/g/glibc/libc6_2.2-7_sparc.deb
  to pool/main/g/glibc/glibc_2.2-7.dsc
  to pool/main/g/glibc/i18ndata_2.2-7_all.deb
  to pool/main/g/glibc/nscd_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-prof_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-dev_2.2-7_powerpc.deb
  to pool/main/g/glibc/nscd_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-v9_2.2-7_sparc.deb
  to pool/main/g/glibc/nscd_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-prof_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-prof_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-dbg_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-pic_2.2-7_i386.deb
  to pool/main/g/glibc/glibc_2.2-7.diff.gz
  to pool/main/g/glibc/glibc-doc_2.2-7_all.deb
  to pool/main/g/glibc/libc6_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.2-7_powerpc.deb
A summary of the changes between this version and the previous one is

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 63511@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
Ben Collins <bcollins@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)

Hash: SHA1

Format: 1.7
Date: Mon, 25 Dec 2000 08:42:49 -0500
Source: glibc
Binary: locales libc0.2-dbg glibc-doc nscd libc6-i586 libc6.1-dbg libc6-i686 libc0.2 libc6-dbg libc6-v9 libc0.2-prof libc6.1 libc6 libc0.2-pic libc6.1-prof libc6-prof libc0.2-dev libc6.1-pic libc6-pic i18ndata libc6.1-dev libc6-dev
Architecture: source all sparc i386 powerpc
Version: 2.2-7
Distribution: unstable
Urgency: low
Maintainer: Ben Collins <bcollins@debian.org>
Changed-By: Ben Collins <bcollins@debian.org>
 glibc-doc  - GNU C Library: Documentation
 i18ndata   - GNU C Library: National Language (locale) data [source]
 libc6      - GNU C Library: Shared libraries and Timezone data
 libc6-dbg  - GNU C Library: Libraries with debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files.
 libc6-pic  - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries.
 libc6-v9   - GNU C Library: Shared libraries [v9 optimized]
 locales    - GNU C Library: National Language (locale) data [support]
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 9888 10358 10686 11839 12207 13800 19646 24090 24949 25879 27146 27516 27544 28250 28251 29619 30054 30683 31415 31983 32468 32792 32801 33686 34110 34452 34538 34550 34699 34702 34729 34793 34816 34940 35094 35113 35131 35250 35334 35389 35497 35694 35948 36075 36076 36080 36212 36578 36621 36655 36762 36932 36933 36952 37014 37154 37162 37307 37604 37902 38392 38556 38897 39071 39440 39584 39594 39648 39762 40768 40870 41388 42155 42490 42726 42727 42850 42867 43105 43530 43659 43729 43950 44093 44619 45041 45693 45848 47289 47457 48371 48716 50261 52455 53530 53786 53894 54051 54096 54156 55367 56195 57026 57297 58226 58270 58367 58586 58954 59110 59316 59800 60034 60099 60113 60255 60320 61163 61257 61746 61963 62173 62397 62511 62803 62826 62990 63511 63569 64327 64906 65132 65510 66769 66803 66913 67204 67205 67296 68424 68873 68923 69172 69544 71928 73018 74611 75334 75349 76246 76678 77416 78585 79043 79666 79830 79926 80453 80454
 glibc (2.2-7) unstable; urgency=low
   * Synced to CVS as of 2000-12-25
   * Patches sent upstream, closes: #75334, #34550, #71928, #11839, #75349
     closes: #38392, #68923, #77416, #39440
   * TCPOPT_EOL, TCPOPT_NOP, TCPOPT_MAXSEG: not declared in glibc (was a
     libc5 thing), so they don't need to be documented, closes: #9888
   * Use texi2html for .html output, which actually does split the file,
     closes: #61257, #76678
   * Hmm, not sure I can fix hamm->slink upgrades for libc6-doc->glibc-doc,
     closes: #32792, #32801
   * Fixed by upstream, closes: #62173, #10686, #37014, #54051, #57297
     closes: #53786, #74611, #37162, #41388, #60255, #63569, #67204
     closes: #67205, #60034, #42850, #60320, #39594, #59800, #48371
     closes: #66803
   * Could not reproduce. My test program showed that it resolved the
     libpthread properly. I am going to assume user error, or some
     funkiness on the user's system. closes: #78585
   * This is reported as a kernel issue, and the submitter was asked to try
     a newer kernel, but never replied. I'm closing on the grounds that I
     believe it was a kernel issue, closes: #45693
   * The iconv test program seems to work as expected in glibc 2.2,
     closes: #39762
   * lt_LT uses ISO-8859-13 now, closes: #10358
   * Things relying on sort to work correctly, should set LANG=C to get
     expected behavior, closes: #56195, #61746, #69544
   * Fixed long long ago, closes: #58226, #58586, #35948, #76246, #53530
     closes: #39584, #13800, #34452, #53894, #54096, #42490, #30683, #32468
     closes: #29619, #34816, #35113, #39071, #35334, #35497, #42867, #36212
     closes: #59316, #62826, #35131, #36952, #43659, #24090, #36076, #45041
     closes: #54156, #37307, #27146, #34729, #47457, #34699, #35250, #34538
     closes: #30054, #35389, #36655, #36762, #36932, #36933, #61163, #58954
   * We no longer build locales at build time, but at install time, closes: #69172
   * I don't see the problem in this testcase, works for me, closes: #73018
   * debian/control.in/main: Show in description that nscd also handles
     host lookups, closes: #48716
   * Unreproducable, probably fixed in 2.2, closes: #57026, #42726, #40768
     closes: #45848, #58367, #62990, #40870, #67296, #38897, #60099, #66769
   * nscd now has a --invalidate option, closes: #42727, #43729
   * adduser now calls nscd -i, so works correctly, closes: #36080
   * Hey, it's one of my bugs, and it isn't any good! closes: #34940
   * Yeah, I agree with the bug report. If you don't want nscd to run on a
     particular system, just uh, don't install it, closes: #36621
   * Setting Fixed to, closes: #47289
   * Do not use UNIX_PATH_MAX, use SUN_LEN(ptr) (defined in sys/un.h),
     closes: #61963
   * _PATH_DEFPATH is the bare minimum for linux. If you want more, use the
     PATH env, closes: #31983
   * The man page is wrong. dlerror.c, and dlfnc.h both show that the
     return string is allocated, so it is not const. closes: #35694
   * All together now, "Using kernel headers in userspace is BAD",
     closes: #12207, #19646, #43105
   * Ran the test case with -O0, -O2, -O3, -O6 on sparc and i386, and did
     not see the problem reported, closes: #37154, #27516
   * Seems perl has worked around this (or libc has), since perl modules
     are building fine, AFAICT, closes: #34110
   * Linus does not suggest doing /usr/include/{linux,asm} symlinks
     anymore. closes: #24949
   * This isn't a glibc bug, it was a gdb bug that is now fixed. closes: #27544
   * lrint is defined with -D_ISOC99_SOURCE, closes: #43530
   * No reference to which docs, nor is there a test case, so: closes: #63511
   * Doh, this was already fixed by me in 2.2-6! closes: #79666
   * User malfunction, not a bug. closes: #39648, #50261, #36075
   * Including stdio.h only ensures that getline will work, it does not
     guarantee you that it's return type is defined, which you must do
     yourself. closes: #62511
   * O_LARGEFILE is only usable when compiling with -D_LARGEFILE64_SOURCE,
     closes: #68873, #52455
   * Ok, strcoll doesn't seem as slow now as shown in the bug report when
     LANG is set. The thing is, this function will always be slower when it
     has to take localization into account. closes: #62803
   * Re bug #44093
     a) I'm pretty sure there is no problem with libc translating errno
        from the kernel, else we'de have some serious problems.
     b) The ioctl() manpage cannot document all returns (and in fact it
        says that it does not document all ioctl types).
     c) I'm pretty sure the EIO return on this particular case is generated
        by the kernel.
     closes: #44093
   * Tested this, and I was able to get 1022 temp files from mkstemp on a
     single run, using the same template, closes: #31415
   * Ulrich Drepper, Re: sortlist in libresolv:
      >It never was and in general is not wanted.  Beside, it is another poor
      >DNS feature which doesn't work with IPv6.  Finally, the NSS gethost*()
      >functions don't have the supporting code.
     closes: #64327
   * lpd should not be using internal glibc functions. closes: #33686
   * makedb -V has no translation now, closes: #34702
   * Checking printf returns is left to the programmer, closes: #28250
   * Ok, the 51 pages of flaming in tis bug report leads me to believe that
     this will never be resolved in glibc. IMO, it is up to the programmer
     to be smart enough to check these things (where it matters). I am
     closing this bug report on the precedence that it is not really a bug
     because current functionality meets specs (and this bug report would
     break that compatibility). This entire bug report should be archived
     all on it's own. Hell, it should have it's own BTS just to track the
     conversation. closes: #28251
   * mkstemp complies with SUSv2 and BSD 4.3. Changing it's bahvior would
     cause portability problems. closes: #34793
   * Downgrading is not supported, closes: #36578
   * The test case did not use pthread_detach(), which resolved the issue.
     closes: #25879
   * Fix devpts regex for when to mount devfs. closes: #79830
   * I believe Wichert found out that base-passwd did have a bug that was
     causing this, and fixed it. closes: #55367, #79043
   * First of all, I do think tzconfig manpage needs to be in section 8.
     However, changing the execute permissions does very little. In fact it
     does nothing. Since normal users don't have perms to change the system
     tz, it doesn't matter if they can execute tzconfig. closes: #62397
   * Added autofs to the services that need to be restarted.
     closes: #80453, #79926
   * Use neat dpkg/awk one-liner from Adam Heath to get list of installed
     services for the daemon check. closes: #80454
   * tzconfig allows you to choose UTC now. Just go to "12" (none of the
     above), and then choose UTC. closes: #38556, #35094
   * Ok, my opinion on this is that you should check dlopen's return every
     time. The example program shows that they did not do this. closes: #37604
   * Looks like a bug in haskell to me. closes: #37902
   * IIRC, all the BSD code is gone. closes: #58270
   * Bug report claims it is not a bug. closes: #42155
   * We have optimized libs now, so that should solve this. closes: #44619
   * I'm pretty sure this "large" wtmp file with only 3 entries is a sparse
     file (check with du). closes: #43950
   * I seriously doubt that ld.so's LD_LIBRARY_PATH stopped working.
     closes: #59110
   * I don't think this is a glibc bug. Sounds more like a cross-compiler
     bug. closes: #68424
   * In Debian, 2.1.2 and 2.1.3 are binary compatible. closes: #60113
   * To get i18n/charmaps, you need to install i18ndata. closes: #65132
   * We don't need to mount shmfs anymore, closes: #65510
   * Fixed by dpkg, closes: #66913, #64906
 2c6b8041463925c5819140fbfde39f8d 1080 libs required glibc_2.2-7.dsc
 5e7f511f0d4a769a5e7e3a708c545ca0 579310 libs required glibc_2.2-7.diff.gz
 2dc906137a71c3fe05c2dbaad69710c0 3408370 base required libc6_2.2-7_sparc.deb
 be65e1207f159a1c0de4b522ca890998 2357926 devel standard libc6-dev_2.2-7_sparc.deb
 d408fdc516406da73a32cfe41295d75f 974116 devel extra libc6-prof_2.2-7_sparc.deb
 ed2cde77a2091b4669cba5d6e4e7da66 2830602 devel extra libc6-dbg_2.2-7_sparc.deb
 3c9d62ed20df5577d3d15ab2adeeab31 853218 devel extra libc6-pic_2.2-7_sparc.deb
 c77391cd251716171030c5502089f9d3 902470 libs extra libc6-v9_2.2-7_sparc.deb
 39c009e88cb76c496fd48e61352b685d 44036 admin optional nscd_2.2-7_sparc.deb
 43e1a1d449db74cc0a149f3944832c58 579784 admin standard locales_2.2-7_all.deb
 2722aa8155244428007d74574e8f866d 2403304 admin extra i18ndata_2.2-7_all.deb
 6a991ca646a50f39cbfb5d156857d1f2 2404280 doc optional glibc-doc_2.2-7_all.deb
 e4e01616d56c804123e2877c8bd1fcd8 3541120 base required libc6_2.2-7_powerpc.deb
 b9b8fd1ebf978c36a8a701f651b9ca04 2165342 devel standard libc6-dev_2.2-7_powerpc.deb
 782e915a7cd860064babe7095b04dbd5 1055316 devel extra libc6-prof_2.2-7_powerpc.deb
 66ac67e157da5ee762008243a63cfaba 2874068 devel extra libc6-dbg_2.2-7_powerpc.deb
 0daac6ac1eac7e37e7ff14c9ce9057b5 869790 devel extra libc6-pic_2.2-7_powerpc.deb
 b57af581e717ac605228037e180c6ce8 44742 admin optional nscd_2.2-7_powerpc.deb
 d87c61924b0c6e2c752f7847e51741d6 3061310 base required libc6_2.2-7_i386.deb
 e165eb4a8d76891cdc9346cdc253a090 2177924 devel standard libc6-dev_2.2-7_i386.deb
 3818fe4d108c1b1158ebc6bf128af226 886284 devel extra libc6-prof_2.2-7_i386.deb
 5c0f13afbd6d3fe89da72bbc004fc8fe 2581148 devel extra libc6-dbg_2.2-7_i386.deb
 32622fdf2549901db5c63dc0133f748e 783420 devel extra libc6-pic_2.2-7_i386.deb
 7db1741c0576df260c7472edf2fd4d00 916414 libs extra libc6-i586_2.2-7_i386.deb
 f463a920ab4e17ddefb69ba6d92beb2b 915618 libs extra libc6-i686_2.2-7_i386.deb
 55118a639282a995b06097d38b1e3d5c 43842 admin optional nscd_2.2-7_i386.deb

Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Ben Collins <bcollins@debian.org>


--- End Message ---

Reply to: