On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote:
This is not properly fixable by the glibc. The attached patch fixes it
in linux, but I'm unsure if this will not break other things like
alternative libc.
No productive disagreement. It will be included with a changed guard:
#if
On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote:
If there's userspace code that wants to get the
kernel types under the standard posix names, why break that?
Please provide a less strict fix which works. Userspace code can only
use this definitions
On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote:
On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote:
Is there some specific reported issue that this change is intended to fix?
I haven't noticed any complaints about the current behavior.
#434040 and a hand full of
On Fri, Aug 24, 2007 at 01:14:17AM -0700, Steve Langasek wrote:
On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote:
#434040 and a hand full of packages on the buildd.
What packages?
Several. No further information available without manual checking. I
expect that several hundred
Hi folks
linux/types.h exports some POSIX types. It can be asked to stop this
with __KERNEL_STRICT_NAMES. features.h defines this. So currently
anything works if features.h is included before linux/types.h.
This is not properly fixable by the glibc. The attached patch fixes it
in linux, but I'm
On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote:
Is there some specific reported issue that this change is intended to fix?
I haven't noticed any complaints about the current behavior.
#434040 and a hand full of packages on the buildd.
Anyway, it's my understanding that
On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote:
linux/types.h exports some POSIX types. It can be asked to stop this
with __KERNEL_STRICT_NAMES. features.h defines this. So currently
anything works if features.h is included before linux/types.h.
This is not properly fixable by
7 matches
Mail list logo
