Processed: Re: Bug#336843: adduser: removes user from group if /etc/group file ends with ":"
Processing commands for [EMAIL PROTECTED]: > tags 336843 wontfix Bug#336843: getgrnam returns trailing ":" in user name There were no tags set. Tags added: wontfix > 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]
Processed: More information needed
Processing commands for [EMAIL PROTECTED]: > tag 310445 moreinfo Bug#310445: libc6: static binary fails with assertion "bad dynamic tag" Tags were: experimental Tags added: moreinfo > severity 310445 normal Bug#310445: libc6: static binary fails with assertion "bad dynamic tag" Severity set to `normal' from `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#286825: fixed in experimental
tags 286825 = fixed-in-experimental thanks This bug seems to be fixed in experimental. Helmut Grohne signature.asc Description: Digital signature
Bug#310445: More information needed
tag 310445 moreinfo severity 310445 normal thanks There are new versions of glibc available. Could you perhaps recheck whether this bug is reproducible? Furthermore the source for that binary would be helpful if available. Helmut Grohne signature.asc Description: Digital signature
Bug#336843: adduser: removes user from group if /etc/group file ends with ":"
tags 336843 wontfix thanks > >Judged that ":" is the field separator in /etc/group, and that > >/etc/group might change its format to include more fields, and that a > >colon is not a valid character in a user name (it would wreck havoc in > >/etc/passwd), I would expect that perl would consider the ":" a > >delimiter here and not return it as part of the group name. > perl doesn't parse /etc/group directly, it just calls libc's getgrname, > which returns a list as gr_mem (the last entry of which has a trailing > colon in this case). There is specified behaviour on invalid passwd files, so whatever glibc does here is within the specs. The function could also segfault at that point. This could maybe reported to the upstream but they'll probably think the same way. Helmut Grohne signature.asc Description: Digital signature
Processed: Re: getopt optional arg does not work as documented
Processing commands for [EMAIL PROTECTED]: > tag 352139 -wontfix Bug#352139: getopt optional arg does not work as documented Tags were: wontfix Tags removed: wontfix > reassign 352139 manpages-dev Bug#352139: getopt optional arg does not work as documented Bug reassigned from package `glibc' to `manpages-dev'. > 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]
Processed: fixed in experimental
Processing commands for [EMAIL PROTECTED]: > tags 286825 = fixed-in-experimental Bug#286825: glibc: nice() should set errno=EPERM not EACCES on error Tags were: wontfix moreinfo Tags set to: fixed-in-experimental > 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]
Processed: Re: Bug#331405: Accidential activation of nscd is too simple
Processing commands for [EMAIL PROTECTED]: > reassign 331405 libpam-ldap Bug#331405: Accidential activation of nscd is too simple Bug reassigned from package `nscd' to `libpam-ldap'. > tags 331405 patch Bug#331405: Accidential activation of nscd is too simple There were no tags set. Tags added: patch > 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#331405: Accidential activation of nscd is too simple
reassign 331405 libpam-ldap tags 331405 patch thanks > It would be libpam-ldap which suggests libnss-ldap in my case. But > running apt-rdepends and analyzing it's output suggests that there are > 35 packages which depends on nscd in etch today. That's depends as in > any of the relationships that drags a package along, either directly or > as a consequence of a second or higer order dependency. The package description of nscd clearly states when nscd should be installed. A "wrong" dependency on nscd is no bug with nscd, but with the software depending on it. Most packages seem to have changed their behaviour since there are only 5 packages in apt-cache rdepends nscd of which at least one is a conflict. So maybe libpam-ldap could suggest nscd instead of recommending it. Otherwise this bug should be tagged wontfix. Helmut Grohne signature.asc Description: Digital signature
Bug#352139: getopt optional arg does not work as documented
tag 352139 -wontfix reassign 352139 manpages-dev thanks > Now. This case is difficult. The string "hello" could also be just a > normal filename argument. I think the glibc handles this case correctly > and thus mark the bug as wontfix. Actually it would be even better if the documentation could be adapted. Thanks to Aurelien Jarno for pointing this out. Helmut Grohne signature.asc Description: Digital signature
Processed: Re: ioctls.h: ioctls.h does not define _IOT__IOTBASE_void on Hurd
Processing commands for [EMAIL PROTECTED]: > clone 288105 -1 Bug#288105: ioctls.h: ioctls.h does not define _IOT__IOTBASE_void on Hurd Bug 288105 cloned as bug 413734. > retitle -1 Hurd doesn't permit non-constant structures as ioctl parameter Bug#413734: ioctls.h: ioctls.h does not define _IOT__IOTBASE_void on Hurd Changed Bug title. > tags 288105 wontfix Bug#288105: ioctls.h: ioctls.h does not define _IOT__IOTBASE_void on Hurd There were no tags set. Tags added: wontfix > 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#288105: ioctls.h: ioctls.h does not define _IOT__IOTBASE_void on Hurd
clone 288105 -1
retitle -1 Hurd doesn't permit non-constant structures as ioctl parameter
tags 288105 wontfix
thanks
Hi,
Jonathan Hogg, le Sat 01 Jan 2005 16:04:39 +, a écrit :
> when attempting to compile package heimdal and applying the patch to
> debian bug #113317 for said package, compile breaks for file
> build-tree/heimdal-0.6.3/lib/kafs/afssys.c of that package, with reason
> _IOT__IOTBASE_void undeclared. Its expanding the macro:
> #define VIOC_SYSCALL _IOW('C', 1, void *)
Mmm, the problem is that defining _IOT__IOTBASE_void doesn't make sense:
here void means that the parameter is not a constant structure, and the
mig-based way that the Hurd uses to perform ioctls _requires_ constant
structures... So there's no way to fix it, hence tagging wontfix so
that people know that defining _IOT__IOTBASE_void is _not_ the proper
way.
Of course, the real bug (which is not only about void*) is: how to pass
non-constant structures as ioctl parameters on the Hurd (poses problem
for OSS stuff too), hence cloning.
About the original problem (compiling heimdal), it looks like it was
patched and is now compiled for hurd-i386.
Samuel
Bug#300640: glibc: select() buggy on Hurd
Hi,
Bastian Blank, le Mon 21 Mar 2005 10:16:26 +0100, a écrit :
> On Sun, Mar 20, 2005 at 11:23:27PM +0100, Marc Dequènes wrote:
> > while ((ret = poll(pfd, 1, 10)) >= 0)
> > {
> > if (ret == 0)
> > continue;
> > if (pfd[0].revents & POLLERR)
> > break;
> > if (pfd[0].revents & POLLIN)
> > {
> > printf("DATA !\n");
> > read(fd, &c, 1);
> > }
> > }
>
> > Result on linux :
> > I've got 1 "DATA !" per character (including "\n").
>
> Yes, linux sets POLLERR if the fifo is not readable.
>
> > Result on Hurd :
> > I've got an infinite number of "DATA !".
>
> You miss the test for EOF.
>
> > It is like if the select state is not reset after reading.
>
> No, it is just a difference in the implementation. Both behaviours are
> okay.
>
> > I tried to find the bug but i need help, this software is not an easy peace.
>
> As it lacks checks of return values, it can't be easy.
Should we really keep this bug opened? I agree with Bastian Blank that
the program should check the result of read() so as to discover end of
file.
Samuel
Bug#300640: marked as done (glibc: select() buggy on Hurd)
Your message dated Tue, 6 Mar 2007 22:28:37 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#300640: glibc: select() buggy on Hurd
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)
--- Begin Message ---
Package: glibc
Version: 2.3.2.ds1-20
Coin,
Here is a simple poll() test case :
(hurd poll() directly uses hurd_select())
#include
#include
#include
#include
#include
#include
int main(void)
{
struct pollfd pfd[1];
int fd, ret;
charc;
fd = open("zzz", O_RDONLY);
pfd[0].fd = fd;
pfd[0].events = POLLIN;
while ((ret = poll(pfd, 1, 10)) >= 0)
{
if (ret == 0)
continue;
if (pfd[0].revents & POLLERR)
break;
if (pfd[0].revents & POLLIN)
{
printf("DATA !\n");
read(fd, &c, 1);
}
}
return 0;
}
Test :
mkfifo zzz
./poll &
echo "coin" >zzz
Result on linux :
DATA !
DATA !
DATA !
DATA !
DATA !
I've got 1 "DATA !" per character (including "\n").
Result on Hurd :
DATA !
DATA !
DATA !
DATA !
DATA !
DATA !
DATA !
[...]
I've got an infinite number of "DATA !".
It is like if the select state is not reset after reading.
I tried to find the bug but i need help, this software is not an easy peace.
Thanks.
--
Marc Dequènes (Duck)
pgpxeIPvC9XUY.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Tue, Mar 06, 2007 at 10:00:52PM +0100, Samuel Thibault wrote:
> Should we really keep this bug opened? I agree with Bastian Blank that
> the program should check the result of read() so as to discover end of
> file.
No. It is no bug. I'm just closing it therefor.
Bastian
--
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9
signature.asc
Description: Digital signature
--- End Message ---
Bug#413744: glibc - uses more than one cpu without asking
Package: glibc Version: 2.3.6.ds1-13 glibc uses all cpus without asking. One of the s390 buildds, lxdebian, have two cpus online but is only allowed to use one full. This is followed by a make call without -j. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4 signature.asc Description: Digital signature
Processed: block 413744 with 209008
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.27 > block 413744 with 209008 Bug#413744: glibc - uses more than one cpu without asking Was not blocked by any bugs. Blocking bugs of 413744 added: 209008 > End of message, 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#413787: libc0.3: TLS patch
Package: libc0.3
Version: 2.5exp6
Severity: normal
Tags: patch
Hi,
Thanks to Barry's long glibc builds, here is at last a patch that builds
a tls/__thread -enabled and working glibc.
The attached patch may be applied as soon as now, but do _not_ drop
--without-tls and --without-__thread yet, because hurd's libpthread.so
doesn't initialize TLS yet, and hence that would break all multithreaded
applications. I'm now working on the Hurd part, I'll mail the bug when
it is uploaded.
Samuel
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-xen
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
diff -urN glibc-2.5-orig/include/errno.h glibc-2.5/include/errno.h
--- glibc-2.5-orig/include/errno.h 2006-02-02 09:37:58.0 +
+++ glibc-2.5/include/errno.h 2007-03-04 15:53:25.0 +
@@ -21,7 +21,7 @@
# include /* Defines USE_TLS. */
-# if USE___THREAD
+# if USE___THREAD && !defined(__GNU__)
# undef errno
# ifndef NOT_IN_libc
#define errno __libc_errno
diff -urN glibc-2.5-orig/sysdeps/mach/i386/sysdep.h
glibc-2.5/sysdeps/mach/i386/sysdep.h
--- glibc-2.5-orig/sysdeps/mach/i386/sysdep.h 2001-07-06 04:56:00.0
+
+++ glibc-2.5/sysdeps/mach/i386/sysdep.h2007-03-01 20:23:59.0
+
@@ -16,6 +16,9 @@
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
+#include
+#include
+
#define LOSE asm volatile ("hlt")
#define SNARF_ARGS(entry_sp, argc, argv, envp) \
