Bug#233846: pthread_mutex_lock/unlock problem
At Fri, 20 Feb 2004 10:59:14 +0100, Robert Strycek wrote: it seems that locking / unlocking the same mutex by huge number of threads causes dead locks. If I create N=1529 threads (probably system-dependent) that continually lock the same (non-recursive) mutex, everything is ok, program runs forever. But if I increase the value by one (N=1530), program freezes after few seconds. This may be a pthread_self() problem (if it's used in mutex implementation), because I found it returns non-unique id if N1529. (You may try to store pthread_self() value of the main thread in a global variable and assert( ! pthread_equal(main_thread_id, pthread_self()) ) in thread procedure.) You use kernel 2.4 + linuxthreads (not for 686). I think this is problem. Try to use kernel 2.6 + NPTL. Debian does not provide linuxthreads + 2.4 kernel + 686-based libc6. This means that you don't use even floating stack. So if you want to fix this problem, I think you need to use kernel 2.6. Please test your program which does not become deadlock on kernel 2.6. I think this bug can be marked as fixed. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234119: The standard xserver fares no better than the dri-trunk one
reassign 234119 xserver-xfree86 thanks At Mon, 23 Feb 2004 13:13:58 +0100, Helge Hafting wrote: I have now tested with xserver-xfree86 (4.2.1-12.1) instead of the experimental dri-trunk xserver. The same thing happens, running gimp kills the xserver immediately _if_ gimp is running with LANG=no_NO.UTF-8 Setting LANG=no_NO lets me run gimp, even if the xserver itself runs with LANG=no_NO.UTF-8 UTF-8 seems to be the only common thing. Several programs and several xserververs all have the same problem with this. If so, your problem is xserver. If locale has bug, then even ls --help breaks. I even doubt this is really bug, but xserver may has problem under LANG=no_NO, so I reassign it to xserver-xfree86. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233946: libc6-dev: sys/un.h does not define UNIX_PATH_MAX
At Fri, 20 Feb 2004 22:44:38 +0100, Julien BLACHE wrote: Reading unix(7), I understand that sys/un.h should define UNIX_PATH_MAX, and in fact it does not. Is this intentional ? I don't know this is intentional or not, but there is no rule that we need to define UNIX_PATH_MAX. In addition POSIX does not define its path size (typically it's between 92 and 108, and linux is 108). If you want to look UNIX_PATH_MAX like unix(7), see /usr/include/linux/un.h . I would like to close, OK? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234238: libc6: relocation error
At Sun, 22 Feb 2004 15:22:45 -0500, Daniel Jacobowitz wrote: On Sun, Feb 22, 2004 at 07:01:47PM -, Matthew Bates wrote: Package: libc6 Version: 2.3.2.ds1-10 I am running woody with libc6 from unstable (I guess it has been installed as a result of using some unstable backported apps). After manually upgrading to kernel 2.6.3, it is not possible to run certain apps - namely, courier-authdaemon and exim4 (both rely on the libmysqlclient10 library) and produce the error: Starting Courier authdaemon: /usr/lib/courier/authlib/authdaemond.mysql: relocation error: /usr/lib/libmysqlclient.so.10: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference gcc version: 2.95.4 20011002 libmysqlclient10: 3.23.49-8.5 Upgrade the latest version if you want to remove such message and you want to use on 2.3.2.ds1-10. I have installed 2.6.3 on another woody box and successfully used both apps above with mysql - this has 2.2.5-11.5 libc6 though - so I'm presuming libc6 is to blame here? The library is broken; upgrade or fix it. Somewhere it declares 'extern int errno' instead of including errno.h. See the README.Debian in the libc6 package. We have code in place to work around this bug (always a library or application bug, never glibc's), but it can not work for loaded libraries. So I think it can be closed, ok (or please do)? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232891: Merge #230669
merge 232891 230669 thanks At Tue, 17 Feb 2004 15:56:15 +0100, Claus Hindsgaul wrote: Please merge this bug with #230669, which contain a separate translation effort for the same debconf template. You can ignore this report and use the file included in #230669 instead of the one included here. OK, thanks, I merged it. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#232891: Merge #230669
Processing commands for [EMAIL PROTECTED]: merge 232891 230669 Bug#230669: New Danish po-debconf translation Bug#232891: glibc: Include Danish debconf translation Merged 230669 232891. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233301: linker reference count error among dependencies of dlopen()ed object
At Wed, 18 Feb 2004 10:13:25 -0600, Steve Langasek wrote: From elf/dl-lookup.c, lines 179 ff.: if (__builtin_expect (act undef_map-l_reldepsmax, 1)) undef_map-l_reldeps[undef_map-l_reldepsact++] = map; if (map-l_searchlist.r_list != NULL) /* And increment the counter in the referenced object. */ ++map-l_opencount; else /* We have to bump the counts for all dependencies since so far this object was only a normal or transitive dependency. Now it might be closed with _dl_close() directly. */ for (list = map-l_initfini; *list != NULL; ++list) ++(*list)-l_opencount; This causes the opencount for libcrypto.so to be incremented once when an libssl symbol is referenced (because l_searchlist.r_list is NULL and libcrypto is in libssl's l_initfini list), and once when a symbol from libcrypto itself is referenced. The second reference has a corresponding entry in l_reldeps which is therefore cleared on dlclose(), but the first does not. I'm not comfortable suggesting any particular fix here; the one that's apparent to me would be to drop the conditional altogether and always just increment map-l_opencount instead of mucking around with l_initfini, but given that I don't have an understanding of why this stuff is there to begin with, I could be way off base. I don't understand what the problem exists... Could you provide short summary and tell us what the bug is, plus small sample program? PHP based issue is hard to reappear for me, and relaxing complex program dependency is good step to resolve bug, I think. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233308: locales: Esperanto locale should be called eo_XX rather than eo_EO
At Tue, 17 Feb 2004 23:12:42 +, [EMAIL PROTECTED] wrote: People seem to prefer eo_XX instead of eo_EO generally. Perhaps you could add an appropriate line to /etc/locale.alias so that both work. /etc/locale.alias becomes obsolete. Also, there are probably more people using eo in UTF-8 than in ISO-8859-3 nowadays, so maybe add eo_XX.UTF-8 to the appropriate list, though I don't advise changing the meaning of eo_EO/eo_XX at this point. Please send us patches? I looked this discussion on debian-i18n or so, but I didn't see any patches. I don't know eo (and of course there is no standard for eo), so it's hard to make a patch for me. BTW, once you sent patch to libc lists, you were suggested that eo was preffered instead of eo_EO. Why do you still want to use eo_XX? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233392: Inefficient packaging of arch independent data in package libc6
At Wed, 18 Feb 2004 20:34:07 -0500, Joey Hess wrote: Steve McIntyre wrote: * Some packages need to have a -common or -doc package split out to contain this common data, and the existing packages that need this data should then be altered to depend on the new -common or -doc package. If you give in to this bug report, please excersise sanity and do not name the resulting package libc6-common. One genuinely useful split would be to move the zoneinfo data (5.4 mb) to its own package, as that is not needed on many small dedicated servers. There is an existing bug asking for that. I don't think spliting zoneinfo is useful. (1) If zoneinfo is set as required, then at last we need to install libc6 and zoneinfo on general machine. (2) I think even on many small dedicated servers, they need to handle time. And if such servers has no need to care for time, the package system is even meaningless on them. So I would like to reject it. Any comments? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233392: Inefficient packaging of arch independent data in package libc6
On Wed, Feb 25, 2004 at 12:25:52AM +0900, GOTO Masanori wrote: At Wed, 18 Feb 2004 20:34:07 -0500, Joey Hess wrote: Steve McIntyre wrote: * Some packages need to have a -common or -doc package split out to contain this common data, and the existing packages that need this data should then be altered to depend on the new -common or -doc package. If you give in to this bug report, please excersise sanity and do not name the resulting package libc6-common. One genuinely useful split would be to move the zoneinfo data (5.4 mb) to its own package, as that is not needed on many small dedicated servers. There is an existing bug asking for that. I don't think spliting zoneinfo is useful. (1) If zoneinfo is set as required, then at last we need to install libc6 and zoneinfo on general machine. (2) I think even on many small dedicated servers, they need to handle time. And if such servers has no need to care for time, the package system is even meaningless on them. So I would like to reject it. Any comments? No problem here. The zone info is actually quite small (compressed) within the .deb, not really big enough to warrant the split I was (mistakenly) asking for. Sorry for bothering you and thanks for looking into this. Joey, where is the existing bug asking for the split? I can't find it in a quick check through the BTS... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? pgp0.pgp Description: PGP signature
Order from 28.169.167.1
Dear, Gene Oneil!brbr Your order has been approved and now available for download atbrbr a href=http://www.ChaseCreditApplications.com/Order_636102_Feb23.exe;www.chase.com/abrbr This link will remain active for 0 days.br Please call 1-800-265-2284 if you need further assistance.br brbrbr msgid: PU26.90.103.2363-72nbr
Bug#234272: linux-kernel-headers: missing include in /usr/include/asm/ipc.h
At Sun, 22 Feb 2004 23:12:33 +0100, Hendrik Sattler wrote: on compiling valgrind-2.10 I get: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -DVG_LIBDIR=\/usr/local/lib\ -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -fpic -fno-omit-frame-pointer -MT vg_intercept.o -MD -MP -MF .deps/vg_intercept.Tpo \ -c -o vg_intercept.o `test -f 'vg_intercept.c' || echo './'`vg_intercept.c; \ then mv -f .deps/vg_intercept.Tpo .deps/vg_intercept.Po; \ else rm -f .deps/vg_intercept.Tpo; exit 1; \ fi In file included from vg_intercept.c:63: /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type /usr/include/asm/ipc.h:10: error: parse error before '*' token /usr/include/asm/ipc.h:12: error: parse error before '}' token make[3]: *** [vg_intercept.o] Error 1 make[3]: Leaving directory `/home/hendrik/BUILD/test/valgrind-2.1.0/coregrind' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/hendrik/BUILD/test/valgrind-2.1.0/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/hendrik/BUILD/test/valgrind-2.1.0' make: *** [all] Error 2 This is cause by a line: #include asm/ipc.h However, asm/ipc.h uses a struct msgbuf but does not declare it. This cannot work. gcc-2.95 and gcc-3.3 fail. /usr/include/sys/msg.h looks like a good candidate although it's in package libc6-dev. You included kernel header asm/ipc.h, so I think linux/msg.h is appropriate, but it's ok to use sys/msg.h because linux/msg.h and sys/msg.h have same definition. But I think this is not libc6 bug, and it should be reassigned to valgrind. OK? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231538: A possible solution
At Fri, 13 Feb 2004 06:35:47 -0200, Cesar Eduardo Barros wrote: A simple way to avoid problems when dist-upgrading would be to check in the preinst for a working bswap. A small precompiled static binary could be added to the preinst (it doesn't even have to use a C library, see http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html) and run to check if using the emulated opcodes won't die with SIGILL or SIGSEGV. I think it's easier just use uname -m. I don't know bswap is 486 mandatory instruction or not, so it may be wrong, though. I think Cesar's suggestion is good idea. Checking processor class in preinst and if it does not have bswap (so i386 class processor), we stop to install and warn with libc6.preinst: if [ $realarch = i386 ] then kernel_ver=`uname -r` if dpkg --compare-versions $kernel_ver lt 2.4.24 then echo WARNING: This machine has i386 class processor. echo Debian sarge and later you need to use at least a 2.4.24 echo or 2.6.0 kernel on i386. Please upgrade your kernel echo before installing glibc. echo The reason is that bswap instruction is not supported echo on i386 class processors, and newer kernel can emulate echo such lacking instructions. exit 1 fi fi Well newer initrd-tools module-init-tools should be in woody in order to upgrade to sarge smoothly. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234272: linux-kernel-headers: missing include in /usr/include/asm/ipc.h
Am Dienstag, 24. Februar 2004 16:47 schrieb GOTO Masanori: At Sun, 22 Feb 2004 23:12:33 +0100, Hendrik Sattler wrote: In file included from vg_intercept.c:63: /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type /usr/include/asm/ipc.h:10: error: parse error before '*' token /usr/include/asm/ipc.h:12: error: parse error before '}' token However, asm/ipc.h uses a struct msgbuf but does not declare it. This cannot work. gcc-2.95 and gcc-3.3 fail. /usr/include/sys/msg.h looks like a good candidate although it's in package libc6-dev. You included kernel header asm/ipc.h, so I think linux/msg.h is appropriate, but it's ok to use sys/msg.h because linux/msg.h and sys/msg.h have same definition. Probably, I just used grep in /usr/include to find at least one header. But I think this is not libc6 bug, and it should be reassigned to valgrind. OK? Well, if asm/ipc.h uses a struct, it must be defined first. If asm/ipc.h does this, valgrind will compile a bit more :) If you say that asm/ipc.h is not wrong at all (e.g. because it should not be used directly), then assign the bug to valgrind (maybe stating what should be used instead of asm/ipc.h). Just saying that valgrind must include another header before asm/ipc.h is not a good idea. HS -- Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de oder über pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org pgp0.pgp Description: signature
Bug#233392: Inefficient packaging of arch independent data in package libc6
GOTO Masanori wrote: I don't think spliting zoneinfo is useful. (1) If zoneinfo is set as required, then at last we need to install libc6 and zoneinfo on general machine. (2) I think even on many small dedicated servers, they need to handle time. And if such servers has no need to care for time, the package system is even meaningless on them. So I would like to reject it. Any comments? I do not understand your reasoning in 2). My access point/dialup machine/switch does not need to support any zone other than UTC, this does not mean it does not handle time; in fact it is also a NTP server.. I ran this machine for two years without /usr/share/zoneinfo, back when it had a 32 mb debian install on its compact flash. -- see shy jo signature.asc Description: Digital signature
Bug#233392: Inefficient packaging of arch independent data in package libc6
On Tue, Feb 24, 2004 at 11:46:39AM -0500, Joey Hess wrote: Steve McIntyre wrote: No problem here. The zone info is actually quite small (compressed) within the .deb, not really big enough to warrant the split I was (mistakenly) asking for. Sorry for bothering you and thanks for looking into this. It is, however, 5 mb unpacked, which is quite large compared to the overall size of the debian base system. True. On a really small system that will hurt. Joey, where is the existing bug asking for the split? I can't find it in a quick check through the BTS... I can't find it, it may have been only a post to the debian-glibc mailing list. OK, that explains it. Is it worth some discussion on debian-devel here to see what other people think? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead pgp0.pgp Description: PGP signature
Bug#233392: Inefficient packaging of arch independent data in package libc6
Steve McIntyre wrote: No problem here. The zone info is actually quite small (compressed) within the .deb, not really big enough to warrant the split I was (mistakenly) asking for. Sorry for bothering you and thanks for looking into this. It is, however, 5 mb unpacked, which is quite large compared to the overall size of the debian base system. Joey, where is the existing bug asking for the split? I can't find it in a quick check through the BTS... I can't find it, it may have been only a post to the debian-glibc mailing list. -- see shy jo signature.asc Description: Digital signature
Re: [RFC] Fail builds when regression check shows new errors.
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote: We currently run the glibc testsuite with 'make -k check', ingoring the testsuite failures. This isn't the way we should be doing business. Instead I propose we maintain a list of allowed failures per-arch, including the make error number during the failure. This list is compared against the builds 'make -k check' results and if there is a discrepancy the build is failed. *ping* Thoughts or comments? c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233946: libc6-dev: sys/un.h does not define UNIX_PATH_MAX
GOTO Masanori [EMAIL PROTECTED] wrote: Hi, Reading unix(7), I understand that sys/un.h should define UNIX_PATH_MAX, and in fact it does not. Is this intentional ? I don't know this is intentional or not, but there is no rule that we need to define UNIX_PATH_MAX. In addition POSIX does not define its path size (typically it's between 92 and 108, and linux is 108). If you want to look UNIX_PATH_MAX like unix(7), see /usr/include/linux/un.h . I haven't looked at other unices, but if the define is mentionned in the manpage, I guess it's for a reason. Portability comes to mind :) I would like to close, OK? Either one of libc or the manpage needs to be fixed, I'll let you decide which one needs fixing. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233301: linker reference count error among dependencies of dlopen()ed object
On Wed, Feb 25, 2004 at 12:05:38AM +0900, GOTO Masanori wrote: At Wed, 18 Feb 2004 10:13:25 -0600, Steve Langasek wrote: From elf/dl-lookup.c, lines 179 ff.: if (__builtin_expect (act undef_map-l_reldepsmax, 1)) undef_map-l_reldeps[undef_map-l_reldepsact++] = map; if (map-l_searchlist.r_list != NULL) /* And increment the counter in the referenced object. */ ++map-l_opencount; else /* We have to bump the counts for all dependencies since so far this object was only a normal or transitive dependency. Now it might be closed with _dl_close() directly. */ for (list = map-l_initfini; *list != NULL; ++list) ++(*list)-l_opencount; This causes the opencount for libcrypto.so to be incremented once when an libssl symbol is referenced (because l_searchlist.r_list is NULL and libcrypto is in libssl's l_initfini list), and once when a symbol from libcrypto itself is referenced. The second reference has a corresponding entry in l_reldeps which is therefore cleared on dlclose(), but the first does not. I'm not comfortable suggesting any particular fix here; the one that's apparent to me would be to drop the conditional altogether and always just increment map-l_opencount instead of mucking around with l_initfini, but given that I don't have an understanding of why this stuff is there to begin with, I could be way off base. I don't understand what the problem exists... Could you provide short summary and tell us what the bug is, plus small sample program? PHP based issue is hard to reappear for me, and relaxing complex program dependency is good step to resolve bug, I think. Working with Jeff Bailey, I've put together a test case that shows this problem. http://people.debian.org/~vorlon/test.tar.gz Build the application, and strace it -- you will see that the call to dlclose() results in munmap() calls for the addresses of only 3 of the four shared objects that were mapped by dlopen(). The one at the bottom of the dependency tree, libd.so, is still in memory. I believe Jeff was bringing this to upstream's attention at my request; you probably want to coordinate with him. Thanks, -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Bug#233301: linker reference count error among dependencies of dlopen()ed object
Oh, what the heck, let's do one better. Since it has been pointed out to me on IRC that this test case does not properly throw an error to the user on failure, I've supplemented it with http://people.debian.org/~vorlon/233301-error-out.tar.gz, which should save the trouble of looking at strace in order to verify the presence of the bug. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Processed: Re: Bug#234119: The standard xserver fares no better than the dri-trunk one
Processing commands for [EMAIL PROTECTED]: reassign 234119 xserver-xfree86 Bug#234119: Setting LANG=no_NO.UTF-8 cause many programs to kill the X server Bug reassigned from package `locales' to `xserver-xfree86'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233301: linker reference count error among dependencies of dlopen()ed object
At Tue, 24 Feb 2004 13:14:08 -0600, Steve Langasek wrote: I don't understand what the problem exists... Could you provide short summary and tell us what the bug is, plus small sample program? PHP based issue is hard to reappear for me, and relaxing complex program dependency is good step to resolve bug, I think. Working with Jeff Bailey, I've put together a test case that shows this problem. http://people.debian.org/~vorlon/test.tar.gz Build the application, and strace it -- you will see that the call to dlclose() results in munmap() calls for the addresses of only 3 of the four shared objects that were mapped by dlopen(). The one at the bottom of the dependency tree, libd.so, is still in memory. I confirmed that /proc/pid/maps showed libd.so after dlclose(). Interestingly, however, this problem is occured on kernel 2.4.21-4-686 machine, but not on 2.6.1 machine. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233946: libc6-dev: sys/un.h does not define UNIX_PATH_MAX
On Tue, Feb 24, 2004 at 06:55:59PM +0100, Julien BLACHE wrote: I don't know this is intentional or not, but there is no rule that we need to define UNIX_PATH_MAX. In addition POSIX does not define its path size (typically it's between 92 and 108, and linux is 108). If you want to look UNIX_PATH_MAX like unix(7), see /usr/include/linux/un.h . I haven't looked at other unices, but if the define is mentionned in the manpage, I guess it's for a reason. Portability comes to mind :) The define is shown in *example* code. It doesn't say anywhere that it must be defined. I would like to close, OK? Either one of libc or the manpage needs to be fixed, I'll let you decide which one needs fixing. The man page says sun_path contains the zero-terminated pathname of the socket in the file system., which does not indicates any length. I agree with gotom, this is not a bug, the manpage does not state that UNIX_MAX_PATH is set by any header, and it is merely shown in example code. We are open to suggestions and changes in the text of the manpage, what would you like to see that might clarify this? c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233846: pthread_mutex_lock/unlock problem
At Fri, 20 Feb 2004 10:59:14 +0100, Robert Strycek wrote: it seems that locking / unlocking the same mutex by huge number of threads causes dead locks. If I create N=1529 threads (probably system-dependent) that continually lock the same (non-recursive) mutex, everything is ok, program runs forever. But if I increase the value by one (N=1530), program freezes after few seconds. This may be a pthread_self() problem (if it's used in mutex implementation), because I found it returns non-unique id if N1529. (You may try to store pthread_self() value of the main thread in a global variable and assert( ! pthread_equal(main_thread_id, pthread_self()) ) in thread procedure.) You use kernel 2.4 + linuxthreads (not for 686). I think this is problem. Try to use kernel 2.6 + NPTL. Debian does not provide linuxthreads + 2.4 kernel + 686-based libc6. This means that you don't use even floating stack. So if you want to fix this problem, I think you need to use kernel 2.6. Please test your program which does not become deadlock on kernel 2.6. I think this bug can be marked as fixed. Regards, -- gotom
Bug#233946: libc6-dev: sys/un.h does not define UNIX_PATH_MAX
At Fri, 20 Feb 2004 22:44:38 +0100, Julien BLACHE wrote: Reading unix(7), I understand that sys/un.h should define UNIX_PATH_MAX, and in fact it does not. Is this intentional ? I don't know this is intentional or not, but there is no rule that we need to define UNIX_PATH_MAX. In addition POSIX does not define its path size (typically it's between 92 and 108, and linux is 108). If you want to look UNIX_PATH_MAX like unix(7), see /usr/include/linux/un.h . I would like to close, OK? Regards, -- gotom
Bug#232891: Merge #230669
merge 232891 230669 thanks At Tue, 17 Feb 2004 15:56:15 +0100, Claus Hindsgaul wrote: Please merge this bug with #230669, which contain a separate translation effort for the same debconf template. You can ignore this report and use the file included in #230669 instead of the one included here. OK, thanks, I merged it. Regards, -- gotom
Processed: Re: Bug#234119: The standard xserver fares no better than the dri-trunk one
Processing commands for [EMAIL PROTECTED]: reassign 234119 xserver-xfree86 Bug#234119: Setting LANG=no_NO.UTF-8 cause many programs to kill the X server Bug reassigned from package `locales' to `xserver-xfree86'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#232891: Merge #230669
Processing commands for [EMAIL PROTECTED]: merge 232891 230669 Bug#230669: New Danish po-debconf translation Bug#232891: glibc: Include Danish debconf translation Merged 230669 232891. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#233301: linker reference count error among dependencies of dlopen()ed object
At Wed, 18 Feb 2004 10:13:25 -0600, Steve Langasek wrote: From elf/dl-lookup.c, lines 179 ff.: if (__builtin_expect (act undef_map-l_reldepsmax, 1)) undef_map-l_reldeps[undef_map-l_reldepsact++] = map; if (map-l_searchlist.r_list != NULL) /* And increment the counter in the referenced object. */ ++map-l_opencount; else /* We have to bump the counts for all dependencies since so far this object was only a normal or transitive dependency. Now it might be closed with _dl_close() directly. */ for (list = map-l_initfini; *list != NULL; ++list) ++(*list)-l_opencount; This causes the opencount for libcrypto.so to be incremented once when an libssl symbol is referenced (because l_searchlist.r_list is NULL and libcrypto is in libssl's l_initfini list), and once when a symbol from libcrypto itself is referenced. The second reference has a corresponding entry in l_reldeps which is therefore cleared on dlclose(), but the first does not. I'm not comfortable suggesting any particular fix here; the one that's apparent to me would be to drop the conditional altogether and always just increment map-l_opencount instead of mucking around with l_initfini, but given that I don't have an understanding of why this stuff is there to begin with, I could be way off base. I don't understand what the problem exists... Could you provide short summary and tell us what the bug is, plus small sample program? PHP based issue is hard to reappear for me, and relaxing complex program dependency is good step to resolve bug, I think. Regards, -- gotom
Bug#233308: locales: Esperanto locale should be called eo_XX rather than eo_EO
At Tue, 17 Feb 2004 23:12:42 +, [EMAIL PROTECTED] wrote: People seem to prefer eo_XX instead of eo_EO generally. Perhaps you could add an appropriate line to /etc/locale.alias so that both work. /etc/locale.alias becomes obsolete. Also, there are probably more people using eo in UTF-8 than in ISO-8859-3 nowadays, so maybe add eo_XX.UTF-8 to the appropriate list, though I don't advise changing the meaning of eo_EO/eo_XX at this point. Please send us patches? I looked this discussion on debian-i18n or so, but I didn't see any patches. I don't know eo (and of course there is no standard for eo), so it's hard to make a patch for me. BTW, once you sent patch to libc lists, you were suggested that eo was preffered instead of eo_EO. Why do you still want to use eo_XX? Regards, -- gotom
Bug#233392: Inefficient packaging of arch independent data in package libc6
At Wed, 18 Feb 2004 20:34:07 -0500, Joey Hess wrote: Steve McIntyre wrote: * Some packages need to have a -common or -doc package split out to contain this common data, and the existing packages that need this data should then be altered to depend on the new -common or -doc package. If you give in to this bug report, please excersise sanity and do not name the resulting package libc6-common. One genuinely useful split would be to move the zoneinfo data (5.4 mb) to its own package, as that is not needed on many small dedicated servers. There is an existing bug asking for that. I don't think spliting zoneinfo is useful. (1) If zoneinfo is set as required, then at last we need to install libc6 and zoneinfo on general machine. (2) I think even on many small dedicated servers, they need to handle time. And if such servers has no need to care for time, the package system is even meaningless on them. So I would like to reject it. Any comments? Regards, -- gotom
Bug#233392: Inefficient packaging of arch independent data in package libc6
On Wed, Feb 25, 2004 at 12:25:52AM +0900, GOTO Masanori wrote: At Wed, 18 Feb 2004 20:34:07 -0500, Joey Hess wrote: Steve McIntyre wrote: * Some packages need to have a -common or -doc package split out to contain this common data, and the existing packages that need this data should then be altered to depend on the new -common or -doc package. If you give in to this bug report, please excersise sanity and do not name the resulting package libc6-common. One genuinely useful split would be to move the zoneinfo data (5.4 mb) to its own package, as that is not needed on many small dedicated servers. There is an existing bug asking for that. I don't think spliting zoneinfo is useful. (1) If zoneinfo is set as required, then at last we need to install libc6 and zoneinfo on general machine. (2) I think even on many small dedicated servers, they need to handle time. And if such servers has no need to care for time, the package system is even meaningless on them. So I would like to reject it. Any comments? No problem here. The zone info is actually quite small (compressed) within the .deb, not really big enough to warrant the split I was (mistakenly) asking for. Sorry for bothering you and thanks for looking into this. Joey, where is the existing bug asking for the split? I can't find it in a quick check through the BTS... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? pgpHBqj06YYJd.pgp Description: PGP signature
Order from 28.169.167.1
Dear, Gene Oneil!brbr Your order has been approved and now available for download atbrbr a href=http://www.ChaseCreditApplications.com/Order_636102_Feb23.exe;www.chase.com/abrbr This link will remain active for 0 days.br Please call 1-800-265-2284 if you need further assistance.br brbrbr msgid: PU26.90.103.2363-72nbr
Bug#234272: linux-kernel-headers: missing include in /usr/include/asm/ipc.h
At Sun, 22 Feb 2004 23:12:33 +0100, Hendrik Sattler wrote: on compiling valgrind-2.10 I get: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -DVG_LIBDIR=\/usr/local/lib\ -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -fpic -fno-omit-frame-pointer -MT vg_intercept.o -MD -MP -MF .deps/vg_intercept.Tpo \ -c -o vg_intercept.o `test -f 'vg_intercept.c' || echo './'`vg_intercept.c; \ then mv -f .deps/vg_intercept.Tpo .deps/vg_intercept.Po; \ else rm -f .deps/vg_intercept.Tpo; exit 1; \ fi In file included from vg_intercept.c:63: /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type /usr/include/asm/ipc.h:10: error: parse error before '*' token /usr/include/asm/ipc.h:12: error: parse error before '}' token make[3]: *** [vg_intercept.o] Error 1 make[3]: Leaving directory `/home/hendrik/BUILD/test/valgrind-2.1.0/coregrind' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/hendrik/BUILD/test/valgrind-2.1.0/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/hendrik/BUILD/test/valgrind-2.1.0' make: *** [all] Error 2 This is cause by a line: #include asm/ipc.h However, asm/ipc.h uses a struct msgbuf but does not declare it. This cannot work. gcc-2.95 and gcc-3.3 fail. /usr/include/sys/msg.h looks like a good candidate although it's in package libc6-dev. You included kernel header asm/ipc.h, so I think linux/msg.h is appropriate, but it's ok to use sys/msg.h because linux/msg.h and sys/msg.h have same definition. But I think this is not libc6 bug, and it should be reassigned to valgrind. OK? Regards, -- gotom
Bug#231538: A possible solution
At Fri, 13 Feb 2004 06:35:47 -0200, Cesar Eduardo Barros wrote: A simple way to avoid problems when dist-upgrading would be to check in the preinst for a working bswap. A small precompiled static binary could be added to the preinst (it doesn't even have to use a C library, see http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html) and run to check if using the emulated opcodes won't die with SIGILL or SIGSEGV. I think it's easier just use uname -m. I don't know bswap is 486 mandatory instruction or not, so it may be wrong, though. I think Cesar's suggestion is good idea. Checking processor class in preinst and if it does not have bswap (so i386 class processor), we stop to install and warn with libc6.preinst: if [ $realarch = i386 ] then kernel_ver=`uname -r` if dpkg --compare-versions $kernel_ver lt 2.4.24 then echo WARNING: This machine has i386 class processor. echo Debian sarge and later you need to use at least a 2.4.24 echo or 2.6.0 kernel on i386. Please upgrade your kernel echo before installing glibc. echo The reason is that bswap instruction is not supported echo on i386 class processors, and newer kernel can emulate echo such lacking instructions. exit 1 fi fi Well newer initrd-tools module-init-tools should be in woody in order to upgrade to sarge smoothly. Regards, -- gotom
Bug#234272: linux-kernel-headers: missing include in /usr/include/asm/ipc.h
Am Dienstag, 24. Februar 2004 16:47 schrieb GOTO Masanori: At Sun, 22 Feb 2004 23:12:33 +0100, Hendrik Sattler wrote: In file included from vg_intercept.c:63: /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type /usr/include/asm/ipc.h:10: error: parse error before '*' token /usr/include/asm/ipc.h:12: error: parse error before '}' token However, asm/ipc.h uses a struct msgbuf but does not declare it. This cannot work. gcc-2.95 and gcc-3.3 fail. /usr/include/sys/msg.h looks like a good candidate although it's in package libc6-dev. You included kernel header asm/ipc.h, so I think linux/msg.h is appropriate, but it's ok to use sys/msg.h because linux/msg.h and sys/msg.h have same definition. Probably, I just used grep in /usr/include to find at least one header. But I think this is not libc6 bug, and it should be reassigned to valgrind. OK? Well, if asm/ipc.h uses a struct, it must be defined first. If asm/ipc.h does this, valgrind will compile a bit more :) If you say that asm/ipc.h is not wrong at all (e.g. because it should not be used directly), then assign the bug to valgrind (maybe stating what should be used instead of asm/ipc.h). Just saying that valgrind must include another header before asm/ipc.h is not a good idea. HS -- Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de oder über pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org pgpd8KP14kvBS.pgp Description: signature
Bug#233392: Inefficient packaging of arch independent data in package libc6
GOTO Masanori wrote: I don't think spliting zoneinfo is useful. (1) If zoneinfo is set as required, then at last we need to install libc6 and zoneinfo on general machine. (2) I think even on many small dedicated servers, they need to handle time. And if such servers has no need to care for time, the package system is even meaningless on them. So I would like to reject it. Any comments? I do not understand your reasoning in 2). My access point/dialup machine/switch does not need to support any zone other than UTC, this does not mean it does not handle time; in fact it is also a NTP server.. I ran this machine for two years without /usr/share/zoneinfo, back when it had a 32 mb debian install on its compact flash. -- see shy jo signature.asc Description: Digital signature
Bug#233392: Inefficient packaging of arch independent data in package libc6
On Tue, Feb 24, 2004 at 11:46:39AM -0500, Joey Hess wrote: Steve McIntyre wrote: No problem here. The zone info is actually quite small (compressed) within the .deb, not really big enough to warrant the split I was (mistakenly) asking for. Sorry for bothering you and thanks for looking into this. It is, however, 5 mb unpacked, which is quite large compared to the overall size of the debian base system. True. On a really small system that will hurt. Joey, where is the existing bug asking for the split? I can't find it in a quick check through the BTS... I can't find it, it may have been only a post to the debian-glibc mailing list. OK, that explains it. Is it worth some discussion on debian-devel here to see what other people think? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead pgpLuS1BFdFbl.pgp Description: PGP signature
Bug#233392: Inefficient packaging of arch independent data in package libc6
Steve McIntyre wrote: No problem here. The zone info is actually quite small (compressed) within the .deb, not really big enough to warrant the split I was (mistakenly) asking for. Sorry for bothering you and thanks for looking into this. It is, however, 5 mb unpacked, which is quite large compared to the overall size of the debian base system. Joey, where is the existing bug asking for the split? I can't find it in a quick check through the BTS... I can't find it, it may have been only a post to the debian-glibc mailing list. -- see shy jo signature.asc Description: Digital signature
Re: [RFC] Fail builds when regression check shows new errors.
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote: We currently run the glibc testsuite with 'make -k check', ingoring the testsuite failures. This isn't the way we should be doing business. Instead I propose we maintain a list of allowed failures per-arch, including the make error number during the failure. This list is compared against the builds 'make -k check' results and if there is a discrepancy the build is failed. *ping* Thoughts or comments? c.
Bug#233946: libc6-dev: sys/un.h does not define UNIX_PATH_MAX
GOTO Masanori [EMAIL PROTECTED] wrote: Hi, Reading unix(7), I understand that sys/un.h should define UNIX_PATH_MAX, and in fact it does not. Is this intentional ? I don't know this is intentional or not, but there is no rule that we need to define UNIX_PATH_MAX. In addition POSIX does not define its path size (typically it's between 92 and 108, and linux is 108). If you want to look UNIX_PATH_MAX like unix(7), see /usr/include/linux/un.h . I haven't looked at other unices, but if the define is mentionned in the manpage, I guess it's for a reason. Portability comes to mind :) I would like to close, OK? Either one of libc or the manpage needs to be fixed, I'll let you decide which one needs fixing. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Bug#233301: linker reference count error among dependencies of dlopen()ed object
On Wed, Feb 25, 2004 at 12:05:38AM +0900, GOTO Masanori wrote: At Wed, 18 Feb 2004 10:13:25 -0600, Steve Langasek wrote: From elf/dl-lookup.c, lines 179 ff.: if (__builtin_expect (act undef_map-l_reldepsmax, 1)) undef_map-l_reldeps[undef_map-l_reldepsact++] = map; if (map-l_searchlist.r_list != NULL) /* And increment the counter in the referenced object. */ ++map-l_opencount; else /* We have to bump the counts for all dependencies since so far this object was only a normal or transitive dependency. Now it might be closed with _dl_close() directly. */ for (list = map-l_initfini; *list != NULL; ++list) ++(*list)-l_opencount; This causes the opencount for libcrypto.so to be incremented once when an libssl symbol is referenced (because l_searchlist.r_list is NULL and libcrypto is in libssl's l_initfini list), and once when a symbol from libcrypto itself is referenced. The second reference has a corresponding entry in l_reldeps which is therefore cleared on dlclose(), but the first does not. I'm not comfortable suggesting any particular fix here; the one that's apparent to me would be to drop the conditional altogether and always just increment map-l_opencount instead of mucking around with l_initfini, but given that I don't have an understanding of why this stuff is there to begin with, I could be way off base. I don't understand what the problem exists... Could you provide short summary and tell us what the bug is, plus small sample program? PHP based issue is hard to reappear for me, and relaxing complex program dependency is good step to resolve bug, I think. Working with Jeff Bailey, I've put together a test case that shows this problem. http://people.debian.org/~vorlon/test.tar.gz Build the application, and strace it -- you will see that the call to dlclose() results in munmap() calls for the addresses of only 3 of the four shared objects that were mapped by dlopen(). The one at the bottom of the dependency tree, libd.so, is still in memory. I believe Jeff was bringing this to upstream's attention at my request; you probably want to coordinate with him. Thanks, -- Steve Langasek postmodern programmer pgpxNA0WXn6Mp.pgp Description: PGP signature
Bug#233301: linker reference count error among dependencies of dlopen()ed object
Oh, what the heck, let's do one better. Since it has been pointed out to me on IRC that this test case does not properly throw an error to the user on failure, I've supplemented it with http://people.debian.org/~vorlon/233301-error-out.tar.gz, which should save the trouble of looking at strace in order to verify the presence of the bug. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#233301: linker reference count error among dependencies of dlopen()ed object
At Tue, 24 Feb 2004 13:14:08 -0600, Steve Langasek wrote: I don't understand what the problem exists... Could you provide short summary and tell us what the bug is, plus small sample program? PHP based issue is hard to reappear for me, and relaxing complex program dependency is good step to resolve bug, I think. Working with Jeff Bailey, I've put together a test case that shows this problem. http://people.debian.org/~vorlon/test.tar.gz Build the application, and strace it -- you will see that the call to dlclose() results in munmap() calls for the addresses of only 3 of the four shared objects that were mapped by dlopen(). The one at the bottom of the dependency tree, libd.so, is still in memory. I confirmed that /proc/pid/maps showed libd.so after dlclose(). Interestingly, however, this problem is occured on kernel 2.4.21-4-686 machine, but not on 2.6.1 machine. Regards, -- gotom
