Processed: Re: [sparc64] undefined symbols in /lib64/libc.so.6
Processing commands for [EMAIL PROTECTED]: > severity 171778 important Bug#171778: [sparc64] undefined symbols in /lib64/libc.so.6 Severity set to `important'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#133336: Manpage is also buggy
At Fri, 27 Dec 2002 11:56:08 -0500,
H. S. Teoh <[EMAIL PROTECTED]> wrote:
> reassign 16 glibc-doc,manpages-dev
> thanks
>
> The manpage termios(3) also claims it returns int:
>
>int cfmakeraw(struct termios *termios_p);
>
> And /usr/include/termios.h (libc6-dev 2.3.1-3) still defines it as
> returning void. Neither the info page nor the manpage makes any mention of
> what exactly cfmakeraw() returns---indicative of possible oversight by
> whoever wrote the original docs.
>
> According to glibc-2.3.1/termios/cfmakeraw.c:
>
> void
> cfmakeraw (t)
> struct termios *t;
> {
> ...
> }
>
>
> So I submit that this is a documentation bug.
Thanks for your report. I think applying this patch is OK for glibc-doc.
--- manual/terminal.texi2002-10-11 02:50:16.0 +0900
+++ manual/terminal.texi.new2002-12-29 12:16:50.0 +0900
@@ -1617,7 +1617,7 @@
@comment termios.h
@comment BSD
[EMAIL PROTECTED] int cfmakeraw (struct termios [EMAIL PROTECTED])
[EMAIL PROTECTED] void cfmakeraw (struct termios [EMAIL PROTECTED])
This function provides an easy way to set up @[EMAIL PROTECTED] for
what has traditionally been called ``raw mode'' in BSD. This uses
noncanonical input, and turns off most processing to give an unmodified
-- gotom
Processed: Re: [sparc64] undefined symbols in /lib64/libc.so.6
Processing commands for [EMAIL PROTECTED]: > severity 171778 important Bug#171778: [sparc64] undefined symbols in /lib64/libc.so.6 Severity set to `important'. > 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#152962: marked as done (locale: dependency information in locale package. is it bug?)
Your message dated Sun, 29 Dec 2002 11:14:05 +0900 with message-id <[EMAIL PROTECTED]> and subject line Bug#152962: locales: powerpc build of locales depends on _glibc_, not libc6 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 14 Jul 2002 21:01:07 + >From [EMAIL PROTECTED] Sun Jul 14 16:01:07 2002 Return-path: <[EMAIL PROTECTED]> Received: from relay.porschenet.hu [213.163.3.2] by master.debian.org with smtp (Exim 3.12 1 (Debian)) id 17TqUM-00050m-00; Sun, 14 Jul 2002 16:01:07 -0500 Received: (qmail 10145 invoked from network); 14 Jul 2002 20:57:36 - Received: from unknown (HELO vega.digitel2002.hu) (213.163.0.181) by relay.porschenet.hu with SMTP; 14 Jul 2002 20:57:36 - Received: (qmail 21126 invoked by uid 1000); 14 Jul 2002 21:00:27 - Date: 14 Jul 2002 21:00:27 - Message-ID: <[EMAIL PROTECTED]> From: "Gábor" "Lénárt" <[EMAIL PROTECTED]> Subject: locale: dependency information in locale package. is it bug? To: [EMAIL PROTECTED] X-Mailer: bug 3.3.10.1 Delivered-To: [EMAIL PROTECTED] Package: locale Version: N/A Severity: normal Now I've tried to install package locales, and I got: locales: Depends: glibc-2.2.5-10.0 but it is not installable I think it's wrong, since libc6-2.2.5-10.0 _IS_ installed but not glibc. Maybe package maintainers should choose that they call libc6 (aka glibc2) as package libc6 _OR_ glibc finally. Or have I missed something? If so, please forgive me. thanx! -- System Information Debian Release: 3.0 Kernel Version: Linux vega 2.4.18 #2 Tue May 14 09:58:09 CEST 2002 i686 unknown unknown GNU/Linux --- Received: (at 152962-done) by bugs.debian.org; 29 Dec 2002 02:14:07 + >From [EMAIL PROTECTED] Sat Dec 28 20:14:07 2002 Return-path: <[EMAIL PROTECTED]> Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18SSxq-0007yB-00; Sat, 28 Dec 2002 20:14:07 -0600 Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73]) by oris.opensource.gr.jp (Postfix) with ESMTP id AC4E6C3495; Sun, 29 Dec 2002 11:14:05 +0900 (JST) Date: Sun, 29 Dec 2002 11:14:05 +0900 Message-ID: <[EMAIL PROTECTED]> From: GOTO Masanori <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#152962: locales: powerpc build of locales depends on _glibc_, not libc6 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-10.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT version=2.41 X-Spam-Level: At Sat, 28 Dec 2002 22:39:31 +0100 (CET), Michel Lanners wrote: > On 28 Dec, this message from GOTO Masanori echoed through cyberspace: > > At Fri, 27 Dec 2002 23:32:26 +0100, > > Michel Lanners wrote: > >> Versions of packages locales depends on: > >> ii debconf 1.0.32 Debian configuration > >> management sy > >> ii libc6 [glibc-2.3.1-5] 2.3.1-5GNU C Library: Shared > >> libraries an > >> > >> > >> See the dependency above? That changed with version 2.3.1-8, and now it > >> depends _only_ on glibc. Here's what I get on upgrading: > >> > >> Sorry, but the following packages have unmet dependencies: > >> locales: Depends: glibc-2.3.1-8 but it is not installable > > > > OK, so could I close this bug? > > Ehmm... if it is resolved, yes. But it is _not_ resolved in version > 2.3.1-8 for powerpc (i386 is OK). I never had that dpeendency problem so > far, but it appeared now with 2.3.1-8. It seems locales and libc6 package propagation problem... locales is "all" package, but libc6 is "architecture (powerpc)" package, and building powerpc packages need compilation time; so it may be inconsistent. Now there should be powerpc 2.3.1-8 libc6 package, so this problem does not occur. At least this bug can be closed, but we should think this propagation problem for not only libc6 but also all packages. > But I just double-checked, and it now works. > > So
Bug#172123: libc6: mysql should be restarted on upgrade
At Sat, 28 Dec 2002 20:52:30 +0100, Walter Hofmann wrote: > On Sun, 22 Dec 2002, GOTO Masanori wrote: > > > > > How to restart? > > > > > > I used "/etc/init.d/mysql restart" to restart it. Afterwards my PHP > > > script worked again. > > > > I don't know it's OK to restart mysql server during woody -> sid > > upgrade... If we can safely restart mysql everytime, we easily add > > such code in glibc postinst script. Please test "/etc/init.d/mysql > > restart" again, and tell us your MySQL/PHP system is still working or > > not. > > I tried and it is still working after "/etc/init.d/mysql restart". Thanks. I put "mysql-server" in libc6 postinst restarting service list. If someone gets problem, I remove it, so please tell us. Regards, -- gotom
cvs commit to glibc-package/debian/libc/DEBIAN by gotom
Repository: glibc-package/debian/libc/DEBIAN who:gotom time: Sat Dec 28 19:05:07 MST 2002 Log Message: - debian/libc/DEBIAN/postinst: add mysql-server in restarting service list. (Closes: #172123) Files: changed:postinst
cvs commit to glibc-package/debian by gotom
Repository: glibc-package/debian who:gotom time: Sat Dec 28 19:05:07 MST 2002 Log Message: - debian/libc/DEBIAN/postinst: add mysql-server in restarting service list. (Closes: #172123) Files: changed:changelog
Bug#133336: Manpage is also buggy
At Fri, 27 Dec 2002 11:56:08 -0500,
H. S. Teoh <[EMAIL PROTECTED]> wrote:
> reassign 16 glibc-doc,manpages-dev
> thanks
>
> The manpage termios(3) also claims it returns int:
>
>int cfmakeraw(struct termios *termios_p);
>
> And /usr/include/termios.h (libc6-dev 2.3.1-3) still defines it as
> returning void. Neither the info page nor the manpage makes any mention of
> what exactly cfmakeraw() returns---indicative of possible oversight by
> whoever wrote the original docs.
>
> According to glibc-2.3.1/termios/cfmakeraw.c:
>
> void
> cfmakeraw (t)
> struct termios *t;
> {
> ...
> }
>
>
> So I submit that this is a documentation bug.
Thanks for your report. I think applying this patch is OK for glibc-doc.
--- manual/terminal.texi2002-10-11 02:50:16.0 +0900
+++ manual/terminal.texi.new2002-12-29 12:16:50.0 +0900
@@ -1617,7 +1617,7 @@
@comment termios.h
@comment BSD
-@deftypefun int cfmakeraw (struct termios *@var{termios-p})
+@deftypefun void cfmakeraw (struct termios *@var{termios-p})
This function provides an easy way to set up @code{*@var{termios-p}} for
what has traditionally been called ``raw mode'' in BSD. This uses
noncanonical input, and turns off most processing to give an unmodified
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#119974: Bug confirmed
On Sat, Dec 28, 2002 at 08:03:40PM -0500, H. S. Teoh wrote: > On Sat, Dec 28, 2002 at 07:23:06PM -0500, Daniel Jacobowitz wrote: > [snip] > > It's guarded by: > > #if defined __USE_BSD || defined __USE_XOPEN > > > > _POSIX_SOURCE is: > >_POSIX_SOURCEIEEE Std 1003.1. > > i.e. not 1b. > > Ahh, that explains it. > > > On the other hand, given: > >_POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std > > 1003.2; > > if >=199309L, add IEEE Std 1003.1b-1993; > > if >=199506L, add IEEE Std 1003.1c-1995 > > > > but _POSIX_C_SOURCE=199309 is not enough to turn on the prototype of > > fsync... so there is a problem, but _POSIX_SOURCE is behaving as > > intended. > [snip] > > Wow, this is a messier tangle than I previously thought. :-) > > Is any of this documented anywhere? I think the original bug submitter > filed the bug because according to his understanding of the documentation, > fsync *should* be included when _POSIX_SOURCE is defined. The manpage > *does* mention POSIX.1b; so if what you describe above is actually > documented somewhere, then the submitter should be referred to it, and the > bug should be closed. Documented? Well, sort of. There's practical documentation in the source; please read /usr/include/features.h near the top, which is _extensively_ commented. Aha, I see that there is a "Feature Test Macros" in the info documentation also. I'm not sure if the bug should be closed; it depends exactly where fsync belongs. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#119974: Bug confirmed
On Sat, Dec 28, 2002 at 07:23:06PM -0500, Daniel Jacobowitz wrote: [snip] > It's guarded by: > #if defined __USE_BSD || defined __USE_XOPEN > > _POSIX_SOURCE is: >_POSIX_SOURCEIEEE Std 1003.1. > i.e. not 1b. Ahh, that explains it. > On the other hand, given: >_POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std > 1003.2; > if >=199309L, add IEEE Std 1003.1b-1993; > if >=199506L, add IEEE Std 1003.1c-1995 > > but _POSIX_C_SOURCE=199309 is not enough to turn on the prototype of > fsync... so there is a problem, but _POSIX_SOURCE is behaving as > intended. [snip] Wow, this is a messier tangle than I previously thought. :-) Is any of this documented anywhere? I think the original bug submitter filed the bug because according to his understanding of the documentation, fsync *should* be included when _POSIX_SOURCE is defined. The manpage *does* mention POSIX.1b; so if what you describe above is actually documented somewhere, then the submitter should be referred to it, and the bug should be closed. T -- Roasting my brains over a slow fire. Please do not interrupt this process.
Bug#119974: Bug confirmed
On Sat, Dec 28, 2002 at 12:07:14PM -0500, H. S. Teoh wrote: > Hi, I've just tested this bug, and observed something rather interesting: > > % cpp /usr/include/unistd.h |grep fsync > extern int fsync (int __fd) ; > % cpp -D_POSIX_SOURCE /usr/include/unistd.h | grep fsync > % > > So it gets included in the default header file, but not when _POSIX_SOURCE > is defined. Now according to a little online research[1], I've found out > that fsync() was actually NOT part of POSIX.1, but was introduced in > POSIX.1b. (There was apparently some controversy surrounding the exact > semantics of fsync(), which may have played a role in its late > introduction to POSIX.) It's guarded by: #if defined __USE_BSD || defined __USE_XOPEN _POSIX_SOURCE is: _POSIX_SOURCEIEEE Std 1003.1. i.e. not 1b. On the other hand, given: _POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2; if >=199309L, add IEEE Std 1003.1b-1993; if >=199506L, add IEEE Std 1003.1c-1995 but _POSIX_C_SOURCE=199309 is not enough to turn on the prototype of fsync... so there is a problem, but _POSIX_SOURCE is behaving as intended. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#28250: Ping ? (re libc lost output bug)
On Sat, Dec 28, 2002 at 06:29:46PM +, Ian Jackson wrote: > On the 10th of July I wrote: > > So, could you please apply it to the libc in unstable ? > > What more needs to happen before you apply this patch ? First of all, it got lost because Ben is no longer the glibc maintainer. Secondly, I will strongly oppose including a patch like this that has not been at least discussed on [EMAIL PROTECTED], which is what he told you to do. It's not as hard to get patches with merit accepted upstream as you seem to think it is; we've been doing it a lot lately. Something which changes the externally visible behavior of stdio has no business being in the Debian patches for something like glibc. Do it the way everyone else has to: propose it to the maintainers. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#152962: marked as done (locale: dependency information in locale package. is it bug?)
Your message dated Sun, 29 Dec 2002 11:14:05 +0900 with message-id <[EMAIL PROTECTED]> and subject line Bug#152962: locales: powerpc build of locales depends on _glibc_, not libc6 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 14 Jul 2002 21:01:07 + >From [EMAIL PROTECTED] Sun Jul 14 16:01:07 2002 Return-path: <[EMAIL PROTECTED]> Received: from relay.porschenet.hu [213.163.3.2] by master.debian.org with smtp (Exim 3.12 1 (Debian)) id 17TqUM-00050m-00; Sun, 14 Jul 2002 16:01:07 -0500 Received: (qmail 10145 invoked from network); 14 Jul 2002 20:57:36 - Received: from unknown (HELO vega.digitel2002.hu) (213.163.0.181) by relay.porschenet.hu with SMTP; 14 Jul 2002 20:57:36 - Received: (qmail 21126 invoked by uid 1000); 14 Jul 2002 21:00:27 - Date: 14 Jul 2002 21:00:27 - Message-ID: <[EMAIL PROTECTED]> From: "Gábor" "Lénárt" <[EMAIL PROTECTED]> Subject: locale: dependency information in locale package. is it bug? To: [EMAIL PROTECTED] X-Mailer: bug 3.3.10.1 Delivered-To: [EMAIL PROTECTED] Package: locale Version: N/A Severity: normal Now I've tried to install package locales, and I got: locales: Depends: glibc-2.2.5-10.0 but it is not installable I think it's wrong, since libc6-2.2.5-10.0 _IS_ installed but not glibc. Maybe package maintainers should choose that they call libc6 (aka glibc2) as package libc6 _OR_ glibc finally. Or have I missed something? If so, please forgive me. thanx! -- System Information Debian Release: 3.0 Kernel Version: Linux vega 2.4.18 #2 Tue May 14 09:58:09 CEST 2002 i686 unknown unknown GNU/Linux --- Received: (at 152962-done) by bugs.debian.org; 29 Dec 2002 02:14:07 + >From [EMAIL PROTECTED] Sat Dec 28 20:14:07 2002 Return-path: <[EMAIL PROTECTED]> Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18SSxq-0007yB-00; Sat, 28 Dec 2002 20:14:07 -0600 Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73]) by oris.opensource.gr.jp (Postfix) with ESMTP id AC4E6C3495; Sun, 29 Dec 2002 11:14:05 +0900 (JST) Date: Sun, 29 Dec 2002 11:14:05 +0900 Message-ID: <[EMAIL PROTECTED]> From: GOTO Masanori <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#152962: locales: powerpc build of locales depends on _glibc_, not libc6 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-10.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT version=2.41 X-Spam-Level: At Sat, 28 Dec 2002 22:39:31 +0100 (CET), Michel Lanners wrote: > On 28 Dec, this message from GOTO Masanori echoed through cyberspace: > > At Fri, 27 Dec 2002 23:32:26 +0100, > > Michel Lanners wrote: > >> Versions of packages locales depends on: > >> ii debconf 1.0.32 Debian configuration management sy > >> ii libc6 [glibc-2.3.1-5] 2.3.1-5GNU C Library: Shared libraries an > >> > >> > >> See the dependency above? That changed with version 2.3.1-8, and now it > >> depends _only_ on glibc. Here's what I get on upgrading: > >> > >> Sorry, but the following packages have unmet dependencies: > >> locales: Depends: glibc-2.3.1-8 but it is not installable > > > > OK, so could I close this bug? > > Ehmm... if it is resolved, yes. But it is _not_ resolved in version > 2.3.1-8 for powerpc (i386 is OK). I never had that dpeendency problem so > far, but it appeared now with 2.3.1-8. It seems locales and libc6 package propagation problem... locales is "all" package, but libc6 is "architecture (powerpc)" package, and building powerpc packages need compilation time; so it may be inconsistent. Now there should be powerpc 2.3.1-8 libc6 package, so this problem does not occur. At least this bug can be closed, but we should think this propagation problem for not only libc6 but also all packages. > But I just double-checked, and it now works. > > So yes, I think
Bug#172123: libc6: mysql should be restarted on upgrade
At Sat, 28 Dec 2002 20:52:30 +0100, Walter Hofmann wrote: > On Sun, 22 Dec 2002, GOTO Masanori wrote: > > > > > How to restart? > > > > > > I used "/etc/init.d/mysql restart" to restart it. Afterwards my PHP > > > script worked again. > > > > I don't know it's OK to restart mysql server during woody -> sid > > upgrade... If we can safely restart mysql everytime, we easily add > > such code in glibc postinst script. Please test "/etc/init.d/mysql > > restart" again, and tell us your MySQL/PHP system is still working or > > not. > > I tried and it is still working after "/etc/init.d/mysql restart". Thanks. I put "mysql-server" in libc6 postinst restarting service list. If someone gets problem, I remove it, so please tell us. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to glibc-package/debian/libc/DEBIAN by gotom
Repository: glibc-package/debian/libc/DEBIAN who:gotom time: Sat Dec 28 19:05:07 MST 2002 Log Message: - debian/libc/DEBIAN/postinst: add mysql-server in restarting service list. (Closes: #172123) Files: changed:postinst -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to glibc-package/debian by gotom
Repository: glibc-package/debian who:gotom time: Sat Dec 28 19:05:07 MST 2002 Log Message: - debian/libc/DEBIAN/postinst: add mysql-server in restarting service list. (Closes: #172123) Files: changed:changelog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#119974: Bug confirmed
On Sat, Dec 28, 2002 at 08:03:40PM -0500, H. S. Teoh wrote: > On Sat, Dec 28, 2002 at 07:23:06PM -0500, Daniel Jacobowitz wrote: > [snip] > > It's guarded by: > > #if defined __USE_BSD || defined __USE_XOPEN > > > > _POSIX_SOURCE is: > >_POSIX_SOURCEIEEE Std 1003.1. > > i.e. not 1b. > > Ahh, that explains it. > > > On the other hand, given: > >_POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2; > > if >=199309L, add IEEE Std 1003.1b-1993; > > if >=199506L, add IEEE Std 1003.1c-1995 > > > > but _POSIX_C_SOURCE=199309 is not enough to turn on the prototype of > > fsync... so there is a problem, but _POSIX_SOURCE is behaving as > > intended. > [snip] > > Wow, this is a messier tangle than I previously thought. :-) > > Is any of this documented anywhere? I think the original bug submitter > filed the bug because according to his understanding of the documentation, > fsync *should* be included when _POSIX_SOURCE is defined. The manpage > *does* mention POSIX.1b; so if what you describe above is actually > documented somewhere, then the submitter should be referred to it, and the > bug should be closed. Documented? Well, sort of. There's practical documentation in the source; please read /usr/include/features.h near the top, which is _extensively_ commented. Aha, I see that there is a "Feature Test Macros" in the info documentation also. I'm not sure if the bug should be closed; it depends exactly where fsync belongs. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#119974: Bug confirmed
On Sat, Dec 28, 2002 at 07:23:06PM -0500, Daniel Jacobowitz wrote: [snip] > It's guarded by: > #if defined __USE_BSD || defined __USE_XOPEN > > _POSIX_SOURCE is: >_POSIX_SOURCEIEEE Std 1003.1. > i.e. not 1b. Ahh, that explains it. > On the other hand, given: >_POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2; > if >=199309L, add IEEE Std 1003.1b-1993; > if >=199506L, add IEEE Std 1003.1c-1995 > > but _POSIX_C_SOURCE=199309 is not enough to turn on the prototype of > fsync... so there is a problem, but _POSIX_SOURCE is behaving as > intended. [snip] Wow, this is a messier tangle than I previously thought. :-) Is any of this documented anywhere? I think the original bug submitter filed the bug because according to his understanding of the documentation, fsync *should* be included when _POSIX_SOURCE is defined. The manpage *does* mention POSIX.1b; so if what you describe above is actually documented somewhere, then the submitter should be referred to it, and the bug should be closed. T -- Roasting my brains over a slow fire. Please do not interrupt this process. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#119974: Bug confirmed
On Sat, Dec 28, 2002 at 12:07:14PM -0500, H. S. Teoh wrote: > Hi, I've just tested this bug, and observed something rather interesting: > > % cpp /usr/include/unistd.h |grep fsync > extern int fsync (int __fd) ; > % cpp -D_POSIX_SOURCE /usr/include/unistd.h | grep fsync > % > > So it gets included in the default header file, but not when _POSIX_SOURCE > is defined. Now according to a little online research[1], I've found out > that fsync() was actually NOT part of POSIX.1, but was introduced in > POSIX.1b. (There was apparently some controversy surrounding the exact > semantics of fsync(), which may have played a role in its late > introduction to POSIX.) It's guarded by: #if defined __USE_BSD || defined __USE_XOPEN _POSIX_SOURCE is: _POSIX_SOURCEIEEE Std 1003.1. i.e. not 1b. On the other hand, given: _POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2; if >=199309L, add IEEE Std 1003.1b-1993; if >=199506L, add IEEE Std 1003.1c-1995 but _POSIX_C_SOURCE=199309 is not enough to turn on the prototype of fsync... so there is a problem, but _POSIX_SOURCE is behaving as intended. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#28250: Ping ? (re libc lost output bug)
On Sat, Dec 28, 2002 at 06:29:46PM +, Ian Jackson wrote: > On the 10th of July I wrote: > > So, could you please apply it to the libc in unstable ? > > What more needs to happen before you apply this patch ? First of all, it got lost because Ben is no longer the glibc maintainer. Secondly, I will strongly oppose including a patch like this that has not been at least discussed on [EMAIL PROTECTED], which is what he told you to do. It's not as hard to get patches with merit accepted upstream as you seem to think it is; we've been doing it a lot lately. Something which changes the externally visible behavior of stdio has no business being in the Debian patches for something like glibc. Do it the way everyone else has to: propose it to the maintainers. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#63658: marked as done (Regular Expressions)
Your message dated Sat, 28 Dec 2002 23:51:56 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#63658: No longer reproducible (#63658)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 6 May 2000 07:52:41 +
Received: (qmail 12242 invoked from network); 6 May 2000 07:52:41 -
Received: from unet.univie.ac.at (131.130.230.7)
by master.debian.org with SMTP; 6 May 2000 07:52:41 -
Received: from downhill.univie.ac.at ([EMAIL PROTECTED] [131.130.230.131])
by unet.univie.ac.at (8.9.3/8.9.3) with ESMTP id JAA102906
for <[EMAIL PROTECTED]>; Sat, 6 May 2000 09:52:38 +0200
Received: from ametzler by downhill.univie.ac.at with local (Exim 3.12 #1
(Debian))
id 12nzKu-0004lD-00
for <[EMAIL PROTECTED]>; Sat, 06 May 2000 09:49:16 +0200
Date: Sat, 6 May 2000 09:49:16 +0200
From: Andreas Metzler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Regular Expressions
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Package: mutt
Version: 1.0.1-9
There is a bug with expanding {m,k}-style Expressions.
I tried to highlight different quotelevels (color quoted1 does not
catch the leading quote-character - to colorful for me):
color body black green "^ {0,3}([|>:}#] ?){2}.*"
color body yellow blue "^ {0,3}([|>:}#] ?){3}.*"
This does not work. The second expression catches
>> blah fasel
although it should not. This was my whole .muttrc and I used "mutt -n"
I did some testing:
* The RedHat-package (6.2) suffers from this bug, too. Upstream?
* this is not matched by the second expression:
>>blah fasel
* If I do without {} and simply write the relating Expression more
times, everything works. (with and without the now useless () )
color body yellow blue "^ {0,3}[|>:}#] ?[|>:}#] ?.*"
color body black green "^ {0,3}[|>:}#] ?[|>:}#] ?[|>:}#] ?.*"
* I posted this to de.comm.software.mailreader.misc in thread
<[EMAIL PROTECTED]>, a german speaking maintainer
should read those articles instead of my horrible english.
Information about my system:
Potato May 5 Kernel 2.2.14 (i386)
libc6 2.1.3-10
libncurses55.0-6
mime-support 3.9-1
tia and cu andreas
--
Andreas Metzler, Wien |
[EMAIL PROTECTED] |
---
Received: (at 63658-done) by bugs.debian.org; 28 Dec 2002 14:52:05 +
>From [EMAIL PROTECTED] Sat Dec 28 08:52:04 2002
Return-path: <[EMAIL PROTECTED]>
Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73]
(postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18SIJn-00022r-00; Sat, 28 Dec 2002 08:52:04 -0600
Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73])
by oris.opensource.gr.jp (Postfix) with ESMTP
id 068D8C33C1; Sat, 28 Dec 2002 23:51:56 +0900 (JST)
Date: Sat, 28 Dec 2002 23:51:56 +0900
Message-ID: <[EMAIL PROTECTED]>
From: GOTO Masanori <[EMAIL PROTECTED]>
To: Andreas Metzler <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Cc: "H. S. Teoh" <[EMAIL PROTECTED]>
Subject: Re: Bug#63658: No longer reproducible (#63658)
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-10.6 required=5.0
tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,
USER_AGENT
version=2.41
X-Spam-Level:
At Thu, 26 Dec 2002 10:41:27 +0100,
Andreas Metzler wrote:
> H. S. Teoh schrieb:
> > Hi, I've also been unable to reproduce this bug. Currently, I have
> >
> > ii libc6 2.3.1-3GNU C Library: Shared libraries and
> > Timezone
> >
> > The test program and the input file are attached. Here are some test runs:
> [regex bug]
>
> Hello,
> Thanks for testing this. I had already planned to try it out myself once
> I had a sid-chroot (I am still running woody), because iirc the
> changelog talked about an overhauled regex engine.
> cu andreas
Teoh, thanks for your testing. I close this bug.
Andreas, if you find the problem, please reopen or resubmit this bug.
Thanks,
Bug#52373: marked as done (GNU libc messages don't distinguish EPIPE and SIGPIPE)
Your message dated Sun, 29 Dec 2002 01:32:17 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#52373: Wishlist bug?
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 9 Dec 1999 12:25:56 +
Received: (qmail 17041 invoked from network); 9 Dec 1999 12:25:56 -
Received: from chiark.greenend.org.uk ([EMAIL PROTECTED])
by master.debian.org with SMTP; 9 Dec 1999 12:25:56 -
Received: from owend by chiark.greenend.org.uk with local (Exim 2.05 #1)
id 11w2du-0005K2-00 (Debian); Thu, 9 Dec 1999 12:25:54 +
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 9 Dec 1999 12:25:53 + (GMT)
From: Owen Dunn <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: GNU libc messages don't distinguish EPIPE and SIGPIPE
X-Mailer: VM 6.62 under Emacs 19.34.1
Package: libc6
Version: 2.1.2-1
GNU libc emits the same message ("Broken pipe" in the C locale) for
both EPIPE and SIGPIPE, but it would be useful if it distinguished
between the two.
(S)
--
`Beware the Subjects bird, and shred / The serious Bandwidth!'
---
Received: (at 52373-done) by bugs.debian.org; 28 Dec 2002 16:32:23 +
>From [EMAIL PROTECTED] Sat Dec 28 10:32:22 2002
Return-path: <[EMAIL PROTECTED]>
Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73]
(postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18SJss-0002em-00; Sat, 28 Dec 2002 10:32:22 -0600
Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73])
by oris.opensource.gr.jp (Postfix) with ESMTP
id 0D6B7C33C6; Sun, 29 Dec 2002 01:32:17 +0900 (JST)
Date: Sun, 29 Dec 2002 01:32:17 +0900
Message-ID: <[EMAIL PROTECTED]>
From: GOTO Masanori <[EMAIL PROTECTED]>
To: "H. S. Teoh" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#52373: Wishlist bug?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-9.3 required=5.0
tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,
USER_AGENT
version=2.41
X-Spam-Level:
> GNU libc emits the same message ("Broken pipe" in the C locale) for
> both EPIPE and SIGPIPE, but it would be useful if it distinguished
> between the two.
At Thu, 26 Dec 2002 22:40:14 -0500,
H. S. Teoh <[EMAIL PROTECTED]> wrote:
> Should this bug be downgraded to wishlist? The bug submitter did say "it
> would be useful if ...". Moreover, according to glibc info docs:
>
> - Macro: int EPIPE
> Broken pipe; there is no process reading from the other end of a
> pipe. Every library function that returns this error code also
> generates a `SIGPIPE' signal; this signal terminates the program
> if not handled or blocked. Thus, your program will never actually
> see `EPIPE' unless it has handled or blocked `SIGPIPE'.
>
>
> So the two seems to be quite related to each other, and I don't see any
> compelling reason to distinguish between error messages generated by
> either one. Sounds very much like wishlist to me.
I agree.
SIGPIPE is one of signals, and EPIPE is one of error numbers. The
message "Broken pipe" is the result of SIGPIPE, and its error number.
I think there is no merit to distinguish them. Moreover, how to
change the message between the two? It's difficult.
So I think it's not bug, it's not wishlist item. I close this bug.
-- gotom
Bug#170507: missing SHMLBA from /usr/include/bits/shm.h on hppa again
> I took a closer look at hppa/bits/shm.h and saw that the patch was NOT > applied, at least not after the #define SHM_UNLOCK line which appears in > the preceding context of the patch. The relevant context of shm.h is as > follows: > > - > > /* Commands for `shmctl'. */ > #define SHM_LOCK 11 /* lock segment (root only) */ > #define SHM_UNLOCK12 /* unlock segment (root only) */ > > > /* Type to count number of attaches. */ > typedef unsigned long int shmatt_t; > > - > > As you can see, the patch lines are missing. The reason why this change is not applied is: cvs.dpatch is based on 2002-12-02 cvs, but SHMLBA change is introduced in 2002-12-03 cvs. I put only this part into debian-glibc cvs. -9 fixes this problem. -- gotom
Bug#152962: locales: powerpc build of locales depends on _glibc_, not libc6
At Fri, 27 Dec 2002 23:32:26 +0100, Michel Lanners wrote: > Versions of packages locales depends on: > ii debconf 1.0.32 Debian configuration management > sy > ii libc6 [glibc-2.3.1-5] 2.3.1-5GNU C Library: Shared libraries > an > > > See the dependency above? That changed with version 2.3.1-8, and now it > depends _only_ on glibc. Here's what I get on upgrading: > > Sorry, but the following packages have unmet dependencies: > locales: Depends: glibc-2.3.1-8 but it is not installable OK, so could I close this bug? -- gotom
Bug#146317: marked as done (Documentation error)
Your message dated Sun, 29 Dec 2002 02:09:29 +0900 with message-id <[EMAIL PROTECTED]> and subject line Bug#146317: Bug has been fixed has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 8 May 2002 23:00:54 + >From [EMAIL PROTECTED] Wed May 08 18:00:54 2002 Return-path: <[EMAIL PROTECTED]> Received: from stud3.tuwien.ac.at [193.170.75.13] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 175aQX-0006UW-00; Wed, 08 May 2002 18:00:53 -0500 Received: from there ([EMAIL PROTECTED] [212.186.138.99]) by stud3.tuwien.ac.at (8.9.3 (PHNE_24419)/8.9.3) with SMTP id BAA04960 for <[EMAIL PROTECTED]>; Thu, 9 May 2002 01:00:51 +0200 (METDST) Message-Id: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-15" From: Andreas Brandstetter <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Documentation error Date: Thu, 9 May 2002 01:00:51 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Delivered-To: [EMAIL PROTECTED] Package: glibc-doc Version: 2.2.5-4 The info pages explicitly state that tfind is declared thus: void * tfind (const void *KEY, void *const *ROOTP, comparison_fn_t COMPAR) However, both man page "tsearch" and header file say it is "**ROOTP". I originally found this bug on a non-debian box, so I guess it should be forwarded upstream, too. best regards, Andreas Brandstetter --- Received: (at 146317-done) by bugs.debian.org; 28 Dec 2002 17:09:31 + >From [EMAIL PROTECTED] Sat Dec 28 11:09:31 2002 Return-path: <[EMAIL PROTECTED]> Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18SKSo-00040h-00; Sat, 28 Dec 2002 11:09:31 -0600 Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73]) by oris.opensource.gr.jp (Postfix) with ESMTP id 8ADC3C33C1; Sun, 29 Dec 2002 02:09:29 +0900 (JST) Date: Sun, 29 Dec 2002 02:09:29 +0900 Message-ID: <[EMAIL PROTECTED]> From: GOTO Masanori <[EMAIL PROTECTED]> To: "H. S. Teoh" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Bug#146317: Bug has been fixed In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-10.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT version=2.41 X-Spam-Level: At Fri, 27 Dec 2002 11:14:53 -0500, H. S. Teoh <[EMAIL PROTECTED]> wrote: > Hi, this bug has been fixed: > > 1) The info pages state: > > - Function: void * tfind (const void *KEY, void *const *ROOTP, > comparison_fn_t COMPAR) > > 2) The man page states: > >void *tfind(const void *key, const void **rootp, >int(*compar)(const void *, const void *)); > > 3) The header file states: > > /* Search for an entry matching the given KEY in the tree pointed to >by *ROOTP. If no matching entry is available return NULL. */ > extern void *tfind (__const void *__key, void *__const *__rootp, > __compar_fn_t __compar); > > > The only thing still wrong is that the comments still refer to *ROOTP, but > I don't think that is an important issue. > > So I propose that this bug be closed. Thanks! > > FYI, the relevant packages on my system are: > ii libc6 2.3.1-3GNU C Library: Shared libraries and Timezone > ii libc6-dev 2.3.1-3GNU C Library: Development Libraries and Hea > ii glibc-doc 2.3.1-6GNU C Library: Documentation > ii manpages-dev 1.48-2 Manual pages about using GNU/Linux for devel Thanks for your investigation. I close this bug. Regards, -- gotom
Bug#138080: regexec() even fails when LANG and LC_ALL are disabled
On Wed, Oct 23, 2002 at 01:48:18PM +0200, Guus Sliepen wrote: > The following lets me believe the POSIX regex function breakage has > nothing to do with locales: [...] > [EMAIL PROTECTED]>LANG= LC_ALL= man -k syscall > afs_syscall (2) - unimplemented system calls > nfsservctl (2) - syscall interface to kernel nfs daemon > zsh: 11416 segmentation fault (core dumped) LANG= LC_ALL= man -k syscall That was a recent breakage in glibc 2.3.1, and (as far as I can tell) has nothing to do with the original bug report. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#174540: libc6-2.3.1-{7,8) breaks apt-get (and more) on mips
Package: libc6 Version: 2.3.1-8 Severity: important Tags: sid, mips After upgrading from 2.3.1-5, all programs linked with -lstdc++ fail like this: indy % apt-get apt-get: relocation error: /usr/lib/libstdc++-libc6.2-2.so.3: symbol \ sys_nerr, version GLIBC_2.3 not defined in file libc.so.6 with link \ time reference objdump shows that only GLIBC_2.0 and GLIBC_2.2 versions are defined indy % objdump -T /usr/lib/libstdc++-libc6.2-2.so.3 | grep sys_nerr DO *UND* 0004 GLIBC_2.3 sys_nerr indy % objdump -T /lib/libc.so.6 | grep sys_nerr ld .gnu.warning.sys_nerr 0016eb70 gDO .rodata0004 (GLIBC_2.0) _sys_nerr 0016eb6c gDO .rodata0004 GLIBC_2.2 sys_nerr 0016eb70 gDO .rodata0004 (GLIBC_2.0) sys_nerr 0016eb6c gDO .rodata0004 GLIBC_2.2 _sys_nerr while on i386 the GLIBC_2.3 version is defined. athlon % objdump -T /usr/lib/libstdc++-libc6.2-2.so.3 | grep sys_nerr DO *UND* 0004 GLIBC_2.3 sys_nerr athlon % objdump -T /lib/libc.so.6| grep sys_nerr ld .gnu.warning.sys_nerr 000fcce8 gDO .rodata0004 (GLIBC_2.1) _sys_nerr 000fcce8 gDO .rodata0004 (GLIBC_2.1) sys_nerr 000fcce4 gDO .rodata0004 (GLIBC_2.0) _sys_nerr 000fcce0 gDO .rodata0004 GLIBC_2.3 sys_nerr 000fcce0 gDO .rodata0004 GLIBC_2.3 _sys_nerr 000fcce4 gDO .rodata0004 (GLIBC_2.0) sys_nerr Downgrading to 2.3.1-7 doesn't help. Please drop me a note if you need further information thanks Siggy -- System Information: Debian Release: testing/unstable Architecture: mips Kernel: Linux peachum 2.4.19-r5k-ip22 #1 Fri Dec 13 00:16:08 CET 2002 mips Locale: LANG=C, LC_CTYPE=C Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information
Bug#31664: Bug should be closed?
At Thu, 26 Dec 2002 22:25:33 -0500, H. S. Teoh <[EMAIL PROTECTED]> wrote: > > Jeff Bailey wrote: > > The original bug seems to be for manpages not correctly documenting > > strsignal needs _GNU_SOURCE defined. That appears to now be > > corrected. > > Confirmed. It's OK for me. > > Is there still a bug here? > > IMHO, this bug should be closed. The other issues raised seems to be > fairly unanimously declined by various people who commented. The only open > question seems to be whether autoconf should detect if strsignal needs > _GNU_SOURCE. If glibc maintainers feel this still needs to be addressed, > this bug should be reassigned to autoconf. There are many GNU libc specific functions, they also needs _GNU_SOURCE. I don't know autoconf in detail, so I can't decide it should be needed to check strsignal(). BTW, autoconf has macro AC_GNU_SOURCE, programmer should use it? - Macro: AC_GNU_SOURCE If using the GNU C library, define `_GNU_SOURCE'. Allows the use of some GNU functions. Should be called before any macros that run the C compiler. -- gotom
Bug#119974: Bug confirmed
Hi, I've just tested this bug, and observed something rather interesting: % cpp /usr/include/unistd.h |grep fsync extern int fsync (int __fd) ; % cpp -D_POSIX_SOURCE /usr/include/unistd.h | grep fsync % So it gets included in the default header file, but not when _POSIX_SOURCE is defined. Now according to a little online research[1], I've found out that fsync() was actually NOT part of POSIX.1, but was introduced in POSIX.1b. (There was apparently some controversy surrounding the exact semantics of fsync(), which may have played a role in its late introduction to POSIX.) It may be that the fsync declaration in unistd.h was written before POSIX.1b, and so it would be excluded when _POSIX_SOURCE was defined. But I presume the manpages were written/updated after POSIX.1b, and hence they mark fsync as POSIX-compliant. Regardless, since fsync is now POSIX-compliant (specifically, POSIX.1b-compliant), should be fixed. The glibc maintainers should, of course, check the actual POSIX.1b spec to ensure that this is accurate. (Also, there may be an issue surrounding old code that expects _POSIX_SOURCE to refer only to POSIX.1 (as opposed to .1b) compliance, and so would expect fsync *not* to be defined; but I'm not well informed enough to know if this is the case or not.) Notes: [1] I was going to include it here, but it was getting a bit lengthy and perhaps not that relevant. But I'll provide it if anybody's interested. T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
Bug#121899: No wonder it segfaults
At Thu, 26 Dec 2002 18:01:10 -0500, H. S. Teoh <[EMAIL PROTECTED]> wrote: > At least, it's not surprising that the "minimal case" Branden provided in > BTS segfaults. It's nothing to do with getpt(); the code is using in > uninitialized pointer *pts. Yes. This test program is wrong. It needs to replace *pts to pts, or allocate *pts. > Barring that, however, I have just confirmed that on libc6 (2.3.1-3), > getpt() does not return an error if /dev/pts is chmod'd to 0, as Branden > suggested. I found that it was still successfully allocating a pty file > descriptor for the pty. However, ptsname() will return a NULL pointer, > because it won't have the permissions to read the pty. Your analisys is right. xterm needs to fix. > I'm not sure if this should be considered a bug, since getpt() *does* > allocate a new pty, even if it is unreadable. I have confirmed that a new > pty does appear in /dev/pts, and gets removed once the test program exits. > In other words, it *does* successfully allocate a pty and returns the file > descriptor, as described by the .info documentation. Yup. > Whether or not getpt() should check for the pty's readability is another > issue, and I don't think libc is "buggy" there either --- one really > should check the return value of ptsname() (or other pts-accessing calls), > which *is* returning NULL in this case when it can't read the pty. > > At any rate, I tried this with xterm, and got: > xterm: unable to access pty device: Permission denied > > I'm not sure if Branden worked around the problem in xterm, or upstream > has fixed the problem. Perhaps this bug should be closed. I also don't know it's already fixed, but at least I think it's not glibc bug. Branden, please check your latest X11, and could I close this bug? -- gotom
Bug#12411: [PATCH] A better Directory Lister example
H. S. Teoh writes ("Bug#12411: [PATCH] A better Directory Lister example"):
...
> I have declined to address this, since this example is mainly concerned
> with using the libc directory reading functions, not with handling stdout
> errors.
I actually think it's a libc bug, #28250.
> > * it prints the error message about failing to open the directory to
> > stdout instead of stderr;
>
> The current version of the info file uses perror(), which, as far as I
> know, print to stderr, not stdout.
I think some of the things I reported must have been fixed in the
meantime.
Thanks,
Ian.
Bug#172123: libc6: mysql should be restarted on upgrade
On Sun, 22 Dec 2002, GOTO Masanori wrote: > > > How to restart? > > > > I used "/etc/init.d/mysql restart" to restart it. Afterwards my PHP > > script worked again. > > I don't know it's OK to restart mysql server during woody -> sid > upgrade... If we can safely restart mysql everytime, we easily add > such code in glibc postinst script. Please test "/etc/init.d/mysql > restart" again, and tell us your MySQL/PHP system is still working or > not. I tried and it is still working after "/etc/init.d/mysql restart". Walter
Bug#28250: Ping ? (re libc lost output bug)
On the 10th of July I wrote: > So, could you please apply it to the libc in unstable ? What more needs to happen before you apply this patch ? Ian.
Processed: reassign bug from libstdc++ to glibc
Processing commands for [EMAIL PROTECTED]: > reassign 169161 glibc Bug#169161: libstdc++5: Questionable type usage in mangled names Bug reassigned from package `libstdc++5' to `glibc'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#63658: marked as done (Regular Expressions)
Your message dated Sat, 28 Dec 2002 23:51:56 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#63658: No longer reproducible (#63658)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 6 May 2000 07:52:41 +
Received: (qmail 12242 invoked from network); 6 May 2000 07:52:41 -
Received: from unet.univie.ac.at (131.130.230.7)
by master.debian.org with SMTP; 6 May 2000 07:52:41 -
Received: from downhill.univie.ac.at ([EMAIL PROTECTED] [131.130.230.131])
by unet.univie.ac.at (8.9.3/8.9.3) with ESMTP id JAA102906
for <[EMAIL PROTECTED]>; Sat, 6 May 2000 09:52:38 +0200
Received: from ametzler by downhill.univie.ac.at with local (Exim 3.12 #1 (Debian))
id 12nzKu-0004lD-00
for <[EMAIL PROTECTED]>; Sat, 06 May 2000 09:49:16 +0200
Date: Sat, 6 May 2000 09:49:16 +0200
From: Andreas Metzler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Regular Expressions
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Package: mutt
Version: 1.0.1-9
There is a bug with expanding {m,k}-style Expressions.
I tried to highlight different quotelevels (color quoted1 does not
catch the leading quote-character - to colorful for me):
color body black green "^ {0,3}([|>:}#] ?){2}.*"
color body yellow blue "^ {0,3}([|>:}#] ?){3}.*"
This does not work. The second expression catches
>> blah fasel
although it should not. This was my whole .muttrc and I used "mutt -n"
I did some testing:
* The RedHat-package (6.2) suffers from this bug, too. Upstream?
* this is not matched by the second expression:
>>blah fasel
* If I do without {} and simply write the relating Expression more
times, everything works. (with and without the now useless () )
color body yellow blue "^ {0,3}[|>:}#] ?[|>:}#] ?.*"
color body black green "^ {0,3}[|>:}#] ?[|>:}#] ?[|>:}#] ?.*"
* I posted this to de.comm.software.mailreader.misc in thread
<8emhr1$vm$[EMAIL PROTECTED]>, a german speaking maintainer
should read those articles instead of my horrible english.
Information about my system:
Potato May 5 Kernel 2.2.14 (i386)
libc6 2.1.3-10
libncurses55.0-6
mime-support 3.9-1
tia and cu andreas
--
Andreas Metzler, Wien |
[EMAIL PROTECTED] |
---
Received: (at 63658-done) by bugs.debian.org; 28 Dec 2002 14:52:05 +
>From [EMAIL PROTECTED] Sat Dec 28 08:52:04 2002
Return-path: <[EMAIL PROTECTED]>
Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18SIJn-00022r-00; Sat, 28 Dec 2002 08:52:04 -0600
Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73])
by oris.opensource.gr.jp (Postfix) with ESMTP
id 068D8C33C1; Sat, 28 Dec 2002 23:51:56 +0900 (JST)
Date: Sat, 28 Dec 2002 23:51:56 +0900
Message-ID: <[EMAIL PROTECTED]>
From: GOTO Masanori <[EMAIL PROTECTED]>
To: Andreas Metzler <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Cc: "H. S. Teoh" <[EMAIL PROTECTED]>
Subject: Re: Bug#63658: No longer reproducible (#63658)
In-Reply-To: <[EMAIL PROTECTED]>
References: <20021225200855.GA24846@crystal>
<[EMAIL PROTECTED]>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-10.6 required=5.0
tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,
USER_AGENT
version=2.41
X-Spam-Level:
At Thu, 26 Dec 2002 10:41:27 +0100,
Andreas Metzler wrote:
> H. S. Teoh schrieb:
> > Hi, I've also been unable to reproduce this bug. Currently, I have
> >
> > ii libc6 2.3.1-3GNU C Library: Shared libraries and Timezone
> >
> > The test program and the input file are attached. Here are some test runs:
> [regex bug]
>
> Hello,
> Thanks for testing this. I had already planned to try it out myself once
> I had a sid-chroot (I am still running woody), because iirc the
> changelog talked about an overhauled regex engine.
> cu andreas
Teoh, thanks for your testing. I close this bug.
Andreas, if you find the problem, please reopen or resubmit thi
Bug#52373: marked as done (GNU libc messages don't distinguish EPIPE and SIGPIPE)
Your message dated Sun, 29 Dec 2002 01:32:17 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#52373: Wishlist bug?
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 9 Dec 1999 12:25:56 +
Received: (qmail 17041 invoked from network); 9 Dec 1999 12:25:56 -
Received: from chiark.greenend.org.uk ([EMAIL PROTECTED])
by master.debian.org with SMTP; 9 Dec 1999 12:25:56 -
Received: from owend by chiark.greenend.org.uk with local (Exim 2.05 #1)
id 11w2du-0005K2-00 (Debian); Thu, 9 Dec 1999 12:25:54 +
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 9 Dec 1999 12:25:53 + (GMT)
From: Owen Dunn <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: GNU libc messages don't distinguish EPIPE and SIGPIPE
X-Mailer: VM 6.62 under Emacs 19.34.1
Package: libc6
Version: 2.1.2-1
GNU libc emits the same message ("Broken pipe" in the C locale) for
both EPIPE and SIGPIPE, but it would be useful if it distinguished
between the two.
(S)
--
`Beware the Subjects bird, and shred / The serious Bandwidth!'
---
Received: (at 52373-done) by bugs.debian.org; 28 Dec 2002 16:32:23 +
>From [EMAIL PROTECTED] Sat Dec 28 10:32:22 2002
Return-path: <[EMAIL PROTECTED]>
Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18SJss-0002em-00; Sat, 28 Dec 2002 10:32:22 -0600
Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73])
by oris.opensource.gr.jp (Postfix) with ESMTP
id 0D6B7C33C6; Sun, 29 Dec 2002 01:32:17 +0900 (JST)
Date: Sun, 29 Dec 2002 01:32:17 +0900
Message-ID: <[EMAIL PROTECTED]>
From: GOTO Masanori <[EMAIL PROTECTED]>
To: "H. S. Teoh" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#52373: Wishlist bug?
In-Reply-To: <20021227034014.GA21778@crystal>
References: <20021227034014.GA21778@crystal>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-9.3 required=5.0
tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,
USER_AGENT
version=2.41
X-Spam-Level:
> GNU libc emits the same message ("Broken pipe" in the C locale) for
> both EPIPE and SIGPIPE, but it would be useful if it distinguished
> between the two.
At Thu, 26 Dec 2002 22:40:14 -0500,
H. S. Teoh <[EMAIL PROTECTED]> wrote:
> Should this bug be downgraded to wishlist? The bug submitter did say "it
> would be useful if ...". Moreover, according to glibc info docs:
>
> - Macro: int EPIPE
> Broken pipe; there is no process reading from the other end of a
> pipe. Every library function that returns this error code also
> generates a `SIGPIPE' signal; this signal terminates the program
> if not handled or blocked. Thus, your program will never actually
> see `EPIPE' unless it has handled or blocked `SIGPIPE'.
>
>
> So the two seems to be quite related to each other, and I don't see any
> compelling reason to distinguish between error messages generated by
> either one. Sounds very much like wishlist to me.
I agree.
SIGPIPE is one of signals, and EPIPE is one of error numbers. The
message "Broken pipe" is the result of SIGPIPE, and its error number.
I think there is no merit to distinguish them. Moreover, how to
change the message between the two? It's difficult.
So I think it's not bug, it's not wishlist item. I close this bug.
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#170507: missing SHMLBA from /usr/include/bits/shm.h on hppa again
> I took a closer look at hppa/bits/shm.h and saw that the patch was NOT > applied, at least not after the #define SHM_UNLOCK line which appears in > the preceding context of the patch. The relevant context of shm.h is as > follows: > > - > > /* Commands for `shmctl'. */ > #define SHM_LOCK 11 /* lock segment (root only) */ > #define SHM_UNLOCK12 /* unlock segment (root only) */ > > > /* Type to count number of attaches. */ > typedef unsigned long int shmatt_t; > > - > > As you can see, the patch lines are missing. The reason why this change is not applied is: cvs.dpatch is based on 2002-12-02 cvs, but SHMLBA change is introduced in 2002-12-03 cvs. I put only this part into debian-glibc cvs. -9 fixes this problem. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#146317: marked as done (Documentation error)
Your message dated Sun, 29 Dec 2002 02:09:29 +0900 with message-id <[EMAIL PROTECTED]> and subject line Bug#146317: Bug has been fixed has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 8 May 2002 23:00:54 + >From [EMAIL PROTECTED] Wed May 08 18:00:54 2002 Return-path: <[EMAIL PROTECTED]> Received: from stud3.tuwien.ac.at [193.170.75.13] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 175aQX-0006UW-00; Wed, 08 May 2002 18:00:53 -0500 Received: from there ([EMAIL PROTECTED] [212.186.138.99]) by stud3.tuwien.ac.at (8.9.3 (PHNE_24419)/8.9.3) with SMTP id BAA04960 for <[EMAIL PROTECTED]>; Thu, 9 May 2002 01:00:51 +0200 (METDST) Message-Id: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-15" From: Andreas Brandstetter <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Documentation error Date: Thu, 9 May 2002 01:00:51 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Delivered-To: [EMAIL PROTECTED] Package: glibc-doc Version: 2.2.5-4 The info pages explicitly state that tfind is declared thus: void * tfind (const void *KEY, void *const *ROOTP, comparison_fn_t COMPAR) However, both man page "tsearch" and header file say it is "**ROOTP". I originally found this bug on a non-debian box, so I guess it should be forwarded upstream, too. best regards, Andreas Brandstetter --- Received: (at 146317-done) by bugs.debian.org; 28 Dec 2002 17:09:31 + >From [EMAIL PROTECTED] Sat Dec 28 11:09:31 2002 Return-path: <[EMAIL PROTECTED]> Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18SKSo-00040h-00; Sat, 28 Dec 2002 11:09:31 -0600 Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73]) by oris.opensource.gr.jp (Postfix) with ESMTP id 8ADC3C33C1; Sun, 29 Dec 2002 02:09:29 +0900 (JST) Date: Sun, 29 Dec 2002 02:09:29 +0900 Message-ID: <[EMAIL PROTECTED]> From: GOTO Masanori <[EMAIL PROTECTED]> To: "H. S. Teoh" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Bug#146317: Bug has been fixed In-Reply-To: <20021227161453.GA27752@crystal> References: <20021227161453.GA27752@crystal> User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-10.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT version=2.41 X-Spam-Level: At Fri, 27 Dec 2002 11:14:53 -0500, H. S. Teoh <[EMAIL PROTECTED]> wrote: > Hi, this bug has been fixed: > > 1) The info pages state: > > - Function: void * tfind (const void *KEY, void *const *ROOTP, > comparison_fn_t COMPAR) > > 2) The man page states: > >void *tfind(const void *key, const void **rootp, >int(*compar)(const void *, const void *)); > > 3) The header file states: > > /* Search for an entry matching the given KEY in the tree pointed to >by *ROOTP. If no matching entry is available return NULL. */ > extern void *tfind (__const void *__key, void *__const *__rootp, > __compar_fn_t __compar); > > > The only thing still wrong is that the comments still refer to *ROOTP, but > I don't think that is an important issue. > > So I propose that this bug be closed. Thanks! > > FYI, the relevant packages on my system are: > ii libc6 2.3.1-3GNU C Library: Shared libraries and Timezone > ii libc6-dev 2.3.1-3GNU C Library: Development Libraries and Hea > ii glibc-doc 2.3.1-6GNU C Library: Documentation > ii manpages-dev 1.48-2 Manual pages about using GNU/Linux for devel Thanks for your investigation. I close this bug. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#152962: locales: powerpc build of locales depends on _glibc_, not libc6
At Fri, 27 Dec 2002 23:32:26 +0100, Michel Lanners wrote: > Versions of packages locales depends on: > ii debconf 1.0.32 Debian configuration management sy > ii libc6 [glibc-2.3.1-5] 2.3.1-5GNU C Library: Shared libraries an > > > See the dependency above? That changed with version 2.3.1-8, and now it > depends _only_ on glibc. Here's what I get on upgrading: > > Sorry, but the following packages have unmet dependencies: > locales: Depends: glibc-2.3.1-8 but it is not installable OK, so could I close this bug? -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#138080: regexec() even fails when LANG and LC_ALL are disabled
On Wed, Oct 23, 2002 at 01:48:18PM +0200, Guus Sliepen wrote: > The following lets me believe the POSIX regex function breakage has > nothing to do with locales: [...] > [guus@haplo]~>LANG= LC_ALL= man -k syscall > afs_syscall (2) - unimplemented system calls > nfsservctl (2) - syscall interface to kernel nfs daemon > zsh: 11416 segmentation fault (core dumped) LANG= LC_ALL= man -k syscall That was a recent breakage in glibc 2.3.1, and (as far as I can tell) has nothing to do with the original bug report. Cheers, -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#174540: libc6-2.3.1-{7,8) breaks apt-get (and more) on mips
Package: libc6 Version: 2.3.1-8 Severity: important Tags: sid, mips After upgrading from 2.3.1-5, all programs linked with -lstdc++ fail like this: indy % apt-get apt-get: relocation error: /usr/lib/libstdc++-libc6.2-2.so.3: symbol \ sys_nerr, version GLIBC_2.3 not defined in file libc.so.6 with link \ time reference objdump shows that only GLIBC_2.0 and GLIBC_2.2 versions are defined indy % objdump -T /usr/lib/libstdc++-libc6.2-2.so.3 | grep sys_nerr DO *UND* 0004 GLIBC_2.3 sys_nerr indy % objdump -T /lib/libc.so.6 | grep sys_nerr ld .gnu.warning.sys_nerr 0016eb70 gDO .rodata0004 (GLIBC_2.0) _sys_nerr 0016eb6c gDO .rodata0004 GLIBC_2.2 sys_nerr 0016eb70 gDO .rodata0004 (GLIBC_2.0) sys_nerr 0016eb6c gDO .rodata0004 GLIBC_2.2 _sys_nerr while on i386 the GLIBC_2.3 version is defined. athlon % objdump -T /usr/lib/libstdc++-libc6.2-2.so.3 | grep sys_nerr DO *UND* 0004 GLIBC_2.3 sys_nerr athlon % objdump -T /lib/libc.so.6| grep sys_nerr ld .gnu.warning.sys_nerr 000fcce8 gDO .rodata0004 (GLIBC_2.1) _sys_nerr 000fcce8 gDO .rodata0004 (GLIBC_2.1) sys_nerr 000fcce4 gDO .rodata0004 (GLIBC_2.0) _sys_nerr 000fcce0 gDO .rodata0004 GLIBC_2.3 sys_nerr 000fcce0 gDO .rodata0004 GLIBC_2.3 _sys_nerr 000fcce4 gDO .rodata0004 (GLIBC_2.0) sys_nerr Downgrading to 2.3.1-7 doesn't help. Please drop me a note if you need further information thanks Siggy -- System Information: Debian Release: testing/unstable Architecture: mips Kernel: Linux peachum 2.4.19-r5k-ip22 #1 Fri Dec 13 00:16:08 CET 2002 mips Locale: LANG=C, LC_CTYPE=C Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#31664: Bug should be closed?
At Thu, 26 Dec 2002 22:25:33 -0500, H. S. Teoh <[EMAIL PROTECTED]> wrote: > > Jeff Bailey wrote: > > The original bug seems to be for manpages not correctly documenting > > strsignal needs _GNU_SOURCE defined. That appears to now be > > corrected. > > Confirmed. It's OK for me. > > Is there still a bug here? > > IMHO, this bug should be closed. The other issues raised seems to be > fairly unanimously declined by various people who commented. The only open > question seems to be whether autoconf should detect if strsignal needs > _GNU_SOURCE. If glibc maintainers feel this still needs to be addressed, > this bug should be reassigned to autoconf. There are many GNU libc specific functions, they also needs _GNU_SOURCE. I don't know autoconf in detail, so I can't decide it should be needed to check strsignal(). BTW, autoconf has macro AC_GNU_SOURCE, programmer should use it? - Macro: AC_GNU_SOURCE If using the GNU C library, define `_GNU_SOURCE'. Allows the use of some GNU functions. Should be called before any macros that run the C compiler. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#119974: Bug confirmed
Hi, I've just tested this bug, and observed something rather interesting: % cpp /usr/include/unistd.h |grep fsync extern int fsync (int __fd) ; % cpp -D_POSIX_SOURCE /usr/include/unistd.h | grep fsync % So it gets included in the default header file, but not when _POSIX_SOURCE is defined. Now according to a little online research[1], I've found out that fsync() was actually NOT part of POSIX.1, but was introduced in POSIX.1b. (There was apparently some controversy surrounding the exact semantics of fsync(), which may have played a role in its late introduction to POSIX.) It may be that the fsync declaration in unistd.h was written before POSIX.1b, and so it would be excluded when _POSIX_SOURCE was defined. But I presume the manpages were written/updated after POSIX.1b, and hence they mark fsync as POSIX-compliant. Regardless, since fsync is now POSIX-compliant (specifically, POSIX.1b-compliant), should be fixed. The glibc maintainers should, of course, check the actual POSIX.1b spec to ensure that this is accurate. (Also, there may be an issue surrounding old code that expects _POSIX_SOURCE to refer only to POSIX.1 (as opposed to .1b) compliance, and so would expect fsync *not* to be defined; but I'm not well informed enough to know if this is the case or not.) Notes: [1] I was going to include it here, but it was getting a bit lengthy and perhaps not that relevant. But I'll provide it if anybody's interested. T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#121899: No wonder it segfaults
At Thu, 26 Dec 2002 18:01:10 -0500, H. S. Teoh <[EMAIL PROTECTED]> wrote: > At least, it's not surprising that the "minimal case" Branden provided in > BTS segfaults. It's nothing to do with getpt(); the code is using in > uninitialized pointer *pts. Yes. This test program is wrong. It needs to replace *pts to pts, or allocate *pts. > Barring that, however, I have just confirmed that on libc6 (2.3.1-3), > getpt() does not return an error if /dev/pts is chmod'd to 0, as Branden > suggested. I found that it was still successfully allocating a pty file > descriptor for the pty. However, ptsname() will return a NULL pointer, > because it won't have the permissions to read the pty. Your analisys is right. xterm needs to fix. > I'm not sure if this should be considered a bug, since getpt() *does* > allocate a new pty, even if it is unreadable. I have confirmed that a new > pty does appear in /dev/pts, and gets removed once the test program exits. > In other words, it *does* successfully allocate a pty and returns the file > descriptor, as described by the .info documentation. Yup. > Whether or not getpt() should check for the pty's readability is another > issue, and I don't think libc is "buggy" there either --- one really > should check the return value of ptsname() (or other pts-accessing calls), > which *is* returning NULL in this case when it can't read the pty. > > At any rate, I tried this with xterm, and got: > xterm: unable to access pty device: Permission denied > > I'm not sure if Branden worked around the problem in xterm, or upstream > has fixed the problem. Perhaps this bug should be closed. I also don't know it's already fixed, but at least I think it's not glibc bug. Branden, please check your latest X11, and could I close this bug? -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#12411: [PATCH] A better Directory Lister example
H. S. Teoh writes ("Bug#12411: [PATCH] A better Directory Lister example"):
...
> I have declined to address this, since this example is mainly concerned
> with using the libc directory reading functions, not with handling stdout
> errors.
I actually think it's a libc bug, #28250.
> > * it prints the error message about failing to open the directory to
> > stdout instead of stderr;
>
> The current version of the info file uses perror(), which, as far as I
> know, print to stderr, not stdout.
I think some of the things I reported must have been fixed in the
meantime.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#172123: libc6: mysql should be restarted on upgrade
On Sun, 22 Dec 2002, GOTO Masanori wrote: > > > How to restart? > > > > I used "/etc/init.d/mysql restart" to restart it. Afterwards my PHP > > script worked again. > > I don't know it's OK to restart mysql server during woody -> sid > upgrade... If we can safely restart mysql everytime, we easily add > such code in glibc postinst script. Please test "/etc/init.d/mysql > restart" again, and tell us your MySQL/PHP system is still working or > not. I tried and it is still working after "/etc/init.d/mysql restart". Walter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#28250: Ping ? (re libc lost output bug)
On the 10th of July I wrote: > So, could you please apply it to the libc in unstable ? What more needs to happen before you apply this patch ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: reassign bug from libstdc++ to glibc
Processing commands for [EMAIL PROTECTED]: > reassign 169161 glibc Bug#169161: libstdc++5: Questionable type usage in mangled names Bug reassigned from package `libstdc++5' to `glibc'. > 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]
cvs commit to glibc-package/debian by gotom
Repository: glibc-package/debian who:gotom time: Sat Dec 28 07:33:51 MST 2002 Log Message: - debian/patches/glibc23-hppa-shmlba.dpatch: Applied hppa SHMLBA definition. (Closes: #170507) Files: changed:changelog
cvs commit to glibc-package/debian/patches by gotom
Repository: glibc-package/debian/patches who:gotom time: Sat Dec 28 07:33:51 MST 2002 Log Message: - debian/patches/glibc23-hppa-shmlba.dpatch: Applied hppa SHMLBA definition. (Closes: #170507) Files: changed:0list added: glibc23-hppa-shmlba.dpatch
Re: Regex update
At Fri, 27 Dec 2002 00:15:25 -0500, Daniel Jacobowitz wrote: > On Thu, Dec 26, 2002 at 09:58:34PM -0800, Jeff Bailey wrote: > > On Thu, Dec 26, 2002 at 09:35:30PM -0600, Anthony Towns wrote: > > > > > > Any objections? > > > > > Not an objection, but I'd *suggest* you don't do this; the most important > > > thing to do to glibc at this point is to *fix* it (#174267, #167909 and > > > arm building at least, afaict), and the easiest and most reliable way to > > > do that is to make the minimal changes needed, and leave it at that. > > > > The reason I mentioned that one is that it's another localised fix to > > the regex engine which solves an infinite loop problem. I suspect that > > if it winds up in testing, we'll probably see a critical bug filed about > > it. > > > > Daniel fixed 174267 already. The -9 upload will have the fix. > > > > Hmm. For some reason I have in my notes here that 167909 was fixed and > > should have been closed. > > > > The CVS ChangeLog has it: > > > > - debian/patches/cvs.dpatch: Update. > > (Closes: #171550, #170507, #167909) > > > > But the one that got committed doesn't for some reasons. I also hadn't > > noticed it in the build log because it seems that bugs with tags appear > > near the bottom of the page. I'll have to remember to look there, too. > > > > I seem to recall GOTO removing it as a result of some discussion...? Hmm... I forget this issue, and I wonder I joined the discussion about it... If 167909 is already fixed, I second to close it. Regards, -- gotom
cvs commit to glibc-package/debian by gotom
Repository: glibc-package/debian who:gotom time: Sat Dec 28 07:33:51 MST 2002 Log Message: - debian/patches/glibc23-hppa-shmlba.dpatch: Applied hppa SHMLBA definition. (Closes: #170507) Files: changed:changelog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to glibc-package/debian/patches by gotom
Repository: glibc-package/debian/patches who:gotom time: Sat Dec 28 07:33:51 MST 2002 Log Message: - debian/patches/glibc23-hppa-shmlba.dpatch: Applied hppa SHMLBA definition. (Closes: #170507) Files: changed:0list added: glibc23-hppa-shmlba.dpatch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regex update
At Fri, 27 Dec 2002 00:15:25 -0500, Daniel Jacobowitz wrote: > On Thu, Dec 26, 2002 at 09:58:34PM -0800, Jeff Bailey wrote: > > On Thu, Dec 26, 2002 at 09:35:30PM -0600, Anthony Towns wrote: > > > > > > Any objections? > > > > > Not an objection, but I'd *suggest* you don't do this; the most important > > > thing to do to glibc at this point is to *fix* it (#174267, #167909 and > > > arm building at least, afaict), and the easiest and most reliable way to > > > do that is to make the minimal changes needed, and leave it at that. > > > > The reason I mentioned that one is that it's another localised fix to > > the regex engine which solves an infinite loop problem. I suspect that > > if it winds up in testing, we'll probably see a critical bug filed about > > it. > > > > Daniel fixed 174267 already. The -9 upload will have the fix. > > > > Hmm. For some reason I have in my notes here that 167909 was fixed and > > should have been closed. > > > > The CVS ChangeLog has it: > > > > - debian/patches/cvs.dpatch: Update. > > (Closes: #171550, #170507, #167909) > > > > But the one that got committed doesn't for some reasons. I also hadn't > > noticed it in the build log because it seems that bugs with tags appear > > near the bottom of the page. I'll have to remember to look there, too. > > > > I seem to recall GOTO removing it as a result of some discussion...? Hmm... I forget this issue, and I wonder I joined the discussion about it... If 167909 is already fixed, I second to close it. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#174521: libc6: threads on ppc leave zombies when they terminate
On Fri, Dec 27, 2002 at 09:53:32PM -0700, Will Aoki wrote: > Package: libc6 > Version: 2.2.5-11.2 > Severity: important > > On powerpc, when threads terminate, they leave behind zombies. This > renders maradns and other programs that have "safety brakes" to keep > them from spawning too many threads unusable, limits the number of > threads that any process can create during its lifetime (even if it > never has more than a few at any one time), and can lead to a denial of > service when a long-running threaded process hits the process limit. > > I've observed this in mozilla, maradns, and xmms, always on powerpc and > never on other architectures (that I have access to). I'm not aware of > any pthreaded programs that don't do this, so I've concluded that it's > likely to be a libc bug, not a programming error in the various > programs. > > Ways to reproduce: > 1 - sample code below > 2 - run mozilla, open some new windows, then close them again > 3 - run xmms, play a file, hit stop > 4 - launch maradns, perform some recursive queries > > Here is some example code. On i386 and sparc, it dosen't cause zombies, > but on ppc, it generates zombies. (I'm not confident that my sample code > is completely correct, as I'm not familiar with pthreads, but it does > demonstrate the same problem I've seen in other programs.) Not on my PPC. This seems more likely to be a bug in the benh kernel you're running; I've never seen it, on glibc 2.2.5 or 2.3.1 on PPC. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
