Re: [Jackit-devel] Re: Re: little NPTL SCHED_FIFO test program
Daniel Jacobowitz wrote (August 21, 2004 - half a year ago): If not now, then when do you expect this to be in unstable? Personal judgement: With about 90% probability after the first release of sarge. I was looking for a timeframe. Weeks, months, years? The debian release cycle is notoriously slow. You could exert a little effort to find out before insulting the maintainers. The release is optimistically scheduled for the middle of September. optimistically scheduled - indeed ... Cheers, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Jackit-devel] Re: Re: little NPTL SCHED_FIFO test program
On Sun, 2005-02-27 at 17:04 +0100, Andreas Kuckartz wrote: Daniel Jacobowitz wrote (August 21, 2004 - half a year ago): If not now, then when do you expect this to be in unstable? Personal judgement: With about 90% probability after the first release of sarge. I was looking for a timeframe. Weeks, months, years? The debian release cycle is notoriously slow. You could exert a little effort to find out before insulting the maintainers. The release is optimistically scheduled for the middle of September. optimistically scheduled - indeed ... If current trends continue, this graph implies the next release will be around August. http://bugs.debian.org/release-critical/ Lee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Short question(s)
At Thu, 24 Feb 2005 11:50:48 +0100, Daniele Cruciani wrote: I do want to build glibc setting kernel minimal version to 2.4.0 (2.4.22 .. does matter last digit??), and compile it with flags for my machine (PIII). (I actually use kernel 2.6.10) Will I fall in any trouble? It depends on your architecture. At least i386 should work with 2.4.x, but we don't test it. Note that tls and i686 are complied with 2.6.0. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
At Sat, 26 Feb 2005 14:40:33 +0100, Goswin Brederlow wrote: Package: linux-kernel-headers Version: 2.5.999-test7-bk-17 Severity: critical File: linux-kernel-header Justification: breaks the whole system Hi, when one tries to run pvmove or lvsnapshot on / the lvm will deadlock itself due to atime updates on /dev/ being blocked while the LVM is locked. Sine any read/write access to / will be blocked the system breaks. To prevent this lvm uses O_NOATIME where available, which is still not the case in current linux-kernel-headers. I couldn't understand why this problem is occured. O_NOATIME was introduced in 2.6.7. Is the root of problem to upgrading lvm package? Bastian's patch adds only O_NOATIME flag - this means that lvm can fix using O_NOATIME in your new package. In other words, lvm is severity: critical, but glibc is not. lvm is kernel related package, so depending on libc6 header sometimes causes problems. So I recommend that lvm should use O_NOATIME definition in your package for a while. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292673: additional info
At Thu, 24 Feb 2005 14:17:44 -0800, David Mosberger wrote: While there hasn't been any discussion for glibc bugzilla report #685 [1], private communication with one of the glibc maintainers indicates that this issue is not considered to be a glibc bug because, officially, glibc supports only one thread library at a time: LinuxThreads _or_ NPTL, but not both at the same time. Of course, every distro I know of ships both NPTL and LinuxThreads and the apparently accepted workaround appears to be to use the ld.so that was built for NPTL rather than the one that was built for LinuxThreads (more precisely, the ld.so should be used which uses larger thread descriptors). Thus, I strongly suspect Debian should do the same. Since this bug results in memory corruption that can be very hard to track down, I hope this can be fixed quickly. As a temporary workaround, just doing: David, does this problem only occurs on ia64? Or i686? To be honest, I have concerned this kind of problem - the incompatibility between nptl and linuxthreads. # mv /lib/tls/ld-2.3.2.so /lib/ should cure the problem. I'm hard to decide to introduce this kind of workaround into the package. We have two choices - (1) increasing the size of linuxthreads' thread descriptors (2) we don't load nptl library using /lib/ld.so. Taking choice (1) is nice idea - because (2) needs another consideration about the kernel version capability. Some distributions (ex: SuSE/FC) provides the fixed kernel version - OTOH, debian has two kernel version series - 2.4 (linuxthreads) and 2.6 (nptl). If we can fix this problem with (1), we don't need to be care about (2) modifications. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296490: marked as done (libc6: getgrnam segfault (using __nscd_getgrnam_r))
Your message dated Mon, 28 Feb 2005 09:40:44 +0900
with message-id [EMAIL PROTECTED]
and subject line Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r)
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; 22 Feb 2005 18:52:31 +
From [EMAIL PROTECTED] Tue Feb 22 10:52:31 2005
Return-path: [EMAIL PROTECTED]
Received: from master.debian.org [146.82.138.7]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1D3f94-0008Qx-00; Tue, 22 Feb 2005 10:52:30 -0800
Received: from x108040.its-m.tudelft.nl (localhost.localdomain) [145.94.108.40]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1D3f94-0004ut-00; Tue, 22 Feb 2005 12:52:30 -0600
Content-Type: multipart/mixed; boundary1922799435==
MIME-Version: 1.0
From: Tom Parker [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: libc6: getgrnam segfault (using __nscd_getgrnam_r)
X-Mailer: reportbug 3.8
Date: Tue, 22 Feb 2005 19:52:28 +0100
X-Debbugs-Cc: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-9.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
OUR_MTA_MSGID,X_DEBBUGS_CC autolearn=ham
version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
This is a multi-part MIME message sent by reportbug.
--===1922799435==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Package: libc6
Version: 2.3.2.ds1-20
Severity: normal
Tags: patch
Calling getgrnam() with a NULL argument, with group in /etc/nsswitch.conf set
to 'compat' can cause a segfault
in __nscd_getgrnam_r due to a lack of a check for a NULL string before doing
strlen(). I've attached a patch,
but this is untested due to the amount of time (+amount of percieved risk) of
replacing libc6 with a
self-modified version. However, it's a two-line fix, so *should* be ok.
-- System Information:
Debian Release: 3.0
APT prefers testing
APT policy: (103, 'testing'), (102, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
--===1922799435==
Content-Type: text/x-c; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=__nscd_getgrnam_r.patch
--- nscd/nscd_getgr_r.c Tue Feb 22 19:45:06 2005
+++ nscd/nscd_getgr_r.c.fixed Tue Feb 22 19:44:33 2005
@@ -42,6 +42,8 @@
__nscd_getgrnam_r (const char *name, struct group *resultbuf, char *buffer,
size_t buflen)
{
+ if (name == NULL)
+ return NULL;
return nscd_getgr_r (name, strlen (name) + 1, GETGRBYNAME, resultbuf,
buffer, buflen);
}
--===1922799435==--
---
Received: (at 296490-done) by bugs.debian.org; 28 Feb 2005 00:40:45 +
From [EMAIL PROTECTED] Sun Feb 27 16:40:45 2005
Return-path: [EMAIL PROTECTED]
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1D5Yxp-0004On-00; Sun, 27 Feb 2005 16:40:45 -0800
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id 8A151DEB1B; Mon, 28 Feb 2005 09:40:44 +0900 (JST)
Date: Mon, 28 Feb 2005 09:40:44 +0900
Message-ID: [EMAIL PROTECTED]
From: GOTO Masanori [EMAIL PROTECTED]
To: Daniel Jacobowitz [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: Tom Parker [EMAIL PROTECTED], Florian Weimer [EMAIL PROTECTED]
Subject: Re: Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r)
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[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-Checker-Version: SpamAssassin
Processed: Re: Bug#295618: broken /etc/init.d/devpts.sh script won't work
Processing commands for [EMAIL PROTECTED]: tags 295618 woody Bug#295618: broken /etc/init.d/devpts.sh script won't work There were no tags set. Tags added: woody 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#295618: broken /etc/init.d/devpts.sh script won't work
tags 295618 woody thanks At Thu, 17 Feb 2005 12:52:10 +1300, John R. McPherson [EMAIL PROTECTED] wrote: (Debian stable, with 2.6 kernel) /etc/init.d/devpts.sh contains the following: ## devpts_avail=`grep -qci '[[:space:]]devpts' /proc/filesystems || true` devpts_mounted=`grep -qci '/dev/pts' /proc/mounts || true` devfs_mounted=`grep -qci '[[:space:]]/dev[[:space:]].*devfs' /proc/mounts || true` if [ $devfs_mounted = 0 ] [ $devpts_avail != 0 ] then ## However, surely this is wrong, as `` backticks are used for recording the stdout of the command, not the return value. because grep -q || true doesn't print anything, this variable is assigned an empty string. bash then complains with [: =: unary operator expected because it tries to do if [ = 0 ] which is a syntax error. The end result is my devpts isn't mounted and I can't run programs that want a pts like screen. Furthermore, adding || true to each of those tests seems to make the tests redundant, since ` anything || true ` will return 0 (true). I think you probably want something like grep -qci '[[:space:]]devpts' /proc/filesystems devpts_avail=$? (etc) Yes, IIRC, this problem was reported and fixed during the development of the sarge's glibc. Please check /etc/init.d/mountkernfs file in the latest sarge. I tagged it as woody. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295573: Bug#233308: Esperanto translations?
At Thu, 17 Feb 2005 14:30:23 +0100, Christian Perrier wrote: Quoting Edmund GRIMLEY EVANS ([EMAIL PROTECTED]): While I'm at it, something VERY important that slept out in this discussion: the list of supported languages for sarge is *closed*. For size constraints, and for being sure that we don't induce problems with initrd size for D-I RC2 and now RC3, Joey Hess has requested that we stop adding languages to sarge-targeted D-I. It would still be nice to have the Esperanto locale in sarge, if that can be arranged. Sure. gotom and locales/glibc maintainers, any status about this old bug? Is it delayed post-sarge, ignored (if so, it should be tagged wontfix, imho) or possible to be included in sarge? There's a chance that a translation begins for Esperanto in Debian Installer and we at least to have some visibility about the locale name. I personnally tend to favour eo_XX. Edmind has suggested eo_AQ (Antarctica), based on the special status of this territory as part of mankind's patrimonium. Others (in -esperanto) have suggested eo_EU which I don't think is appropriate for a universal language... Paul Eggert suggested to use eo: http://sources.redhat.com/ml/libc-alpha/2002-07/msg00147.html I think eo is the nice choice instead of eo_XX because AA_BB means AA: langugage, BB: region. If we want to use the regional information with eo locale, we can override it with LC_* (ex: LC_MONETARY and so on) over LANG environment variable. How about this idea? Regards, -- gotom
Bug#292673: additional info
On Thu, Feb 24, 2005 at 02:17:44PM -0800, David Mosberger wrote: While there hasn't been any discussion for glibc bugzilla report #685 [1], private communication with one of the glibc maintainers indicates that this issue is not considered to be a glibc bug because, officially, glibc supports only one thread library at a time: LinuxThreads _or_ NPTL, but not both at the same time. Of course, every distro I know of ships both NPTL and LinuxThreads and the apparently accepted workaround appears to be to use the ld.so that was built for NPTL rather than the one that was built for LinuxThreads (more precisely, the ld.so should be used which uses larger thread descriptors). Thus, I strongly suspect Debian should do the same. Since this bug results in memory corruption that can be very hard to track down, I hope this can be fixed quickly. As a temporary workaround, just doing: # mv /lib/tls/ld-2.3.2.so /lib/ should cure the problem. ISTR that Red Hat has a patch for this in their glibc RPMs already. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
At Thu, 17 Feb 2005 13:37:25 +0100, Vincent Lefevre wrote: The getgrname(3) man page says: The getgrnam() function returns a pointer to a structure containing the group information from /etc/group for the entry that matches the group name name. But here, the getgrname function returns a result that doesn't belong to /etc/group, which seems to lead by side effects to a security hole (more details below). Does this manpage say correctly? i.e. Is getgrnam tightly coupled with /etc/group? It gives here, where slocate is group 21 in NIS: $ ./grname slocate 21 (slocate) $ grep slocate /etc/group zsh: exit 1 grep slocate /etc/group $ grep 21 /etc/group fax:x:21: As a consequence: # touch blah # chown root.slocate blah # ls -l blah -rw-r--r-- 1 root fax 0 2005-02-17 13:30:13 blah ^^^ This could also explain why groupadd (to add a group to /etc/group) fails if a group with the same name exists via NIS. I guess you specify in /etc/nsswitch.conf that nis is prior than files for group lookup. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#274852: Bug #274852: But in which upstream version?
At Wed, 16 Feb 2005 12:36:23 +0100, David Martnez Moreno wrote: [EMAIL PROTECTED]:~$ xmms libmikmod.so.2: cannot open shared object file: No such file or directory Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed! GOTO, in your last message to this bug you state that the next libc6 release you will include a fix for this, but I have the latest (-20) from Dec and I have this problem. I'm sorry that my previous statement was in accurate - the next glibc update means we use the new upstream version - ex: glibc-2.3.4. So I tagged it as fixed-upstream. Also, the bug says that is fixed upstream. If, as Daniel says in #207872, the patch was rejected upstream, you should remove the tag. I guess upstream did the another way to fix this issue. Daniel, did you know about it more? Regards, -- gotom
Bug#274852: Bug #274852: But in which upstream version?
On Mon, Feb 28, 2005 at 10:23:14AM +0900, GOTO Masanori wrote: At Wed, 16 Feb 2005 12:36:23 +0100, David Mart?nez Moreno wrote: [EMAIL PROTECTED]:~$ xmms libmikmod.so.2: cannot open shared object file: No such file or directory Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed! GOTO, in your last message to this bug you state that the next libc6 release you will include a fix for this, but I have the latest (-20) from Dec and I have this problem. I'm sorry that my previous statement was in accurate - the next glibc update means we use the new upstream version - ex: glibc-2.3.4. So I tagged it as fixed-upstream. Also, the bug says that is fixed upstream. If, as Daniel says in #207872, the patch was rejected upstream, you should remove the tag. I guess upstream did the another way to fix this issue. Daniel, did you know about it more? No, sorry - I don't know if or how it was fixed. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#274852: Bug #274852: But in which upstream version?
El Lunes, 28 de Febrero de 2005 02:23, GOTO Masanori escribi: At Wed, 16 Feb 2005 12:36:23 +0100, David Martnez Moreno wrote: [EMAIL PROTECTED]:~$ xmms libmikmod.so.2: cannot open shared object file: No such file or directory Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed! GOTO, in your last message to this bug you state that the next libc6 release you will include a fix for this, but I have the latest (-20) from Dec and I have this problem. Hello, GOTO. I'm sorry that my previous statement was in accurate - the next glibc update means we use the new upstream version - ex: glibc-2.3.4. So I tagged it as fixed-upstream. Oh, *that* glibc update. :-) Also, the bug says that is fixed upstream. If, as Daniel says in #207872, the patch was rejected upstream, you should remove the tag. I guess upstream did the another way to fix this issue. Daniel, did you know about it more? Yes, please. Because if upstream fixed this, we could backport the changes to current glibc, because I do not think that this problem of not being able to run certain programs is very desirable for sarge. I will wait for Daniel's answer. Thank you very much for your reply- Best regards, Ender. -- Network engineer Debian Developer pgpzrqto2MDjU.pgp Description: PGP signature
Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
GOTO Masanori [EMAIL PROTECTED] writes: At Sat, 26 Feb 2005 14:40:33 +0100, Goswin Brederlow wrote: Package: linux-kernel-headers Version: 2.5.999-test7-bk-17 Severity: critical File: linux-kernel-header Justification: breaks the whole system Hi, when one tries to run pvmove or lvsnapshot on / the lvm will deadlock itself due to atime updates on /dev/ being blocked while the LVM is locked. Sine any read/write access to / will be blocked the system breaks. To prevent this lvm uses O_NOATIME where available, which is still not the case in current linux-kernel-headers. I couldn't understand why this problem is occured. O_NOATIME was introduced in 2.6.7. Is the root of problem to upgrading lvm package? Bastian's patch adds only O_NOATIME flag - this means that lvm can fix using O_NOATIME in your new package. In other words, lvm is severity: critical, but glibc is not. lvm is kernel related package, so depending on libc6 header sometimes causes problems. The docs (man 2 open) document O_NOATIME but the headers are lacking behind in carrying the implementation. So you got stuck with it as primary package. Notice that lvm2 is secondary. If lvm adds a workaround the priority drops but you are still missing documented behaviour, behaviour the sarge kernel (2.6.8) has. Bastian's patch is just a workaround around the bug not its solution. So I recommend that lvm should use O_NOATIME definition in your package for a while. The while is getting realy long, I mentioned this issue several month ago already and it is still not fixed. Regards, -- gotom MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-02-28 10:12:14 +0900, GOTO Masanori wrote: At Thu, 17 Feb 2005 13:37:25 +0100, Vincent Lefevre wrote: The getgrname(3) man page says: The getgrnam() function returns a pointer to a structure containing the group information from /etc/group for the entry that matches the group name name. But here, the getgrname function returns a result that doesn't belong to /etc/group, which seems to lead by side effects to a security hole (more details below). Does this manpage say correctly? i.e. Is getgrnam tightly coupled with /etc/group? What do you mean? It gives here, where slocate is group 21 in NIS: $ ./grname slocate 21 (slocate) $ grep slocate /etc/group zsh: exit 1 grep slocate /etc/group $ grep 21 /etc/group fax:x:21: As a consequence: # touch blah # chown root.slocate blah # ls -l blah -rw-r--r-- 1 root fax 0 2005-02-17 13:30:13 blah ^^^ This could also explain why groupadd (to add a group to /etc/group) fails if a group with the same name exists via NIS. I guess you specify in /etc/nsswitch.conf that nis is prior than files for group lookup. My /etc/nsswitch.conf contains: group: files nis -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
