Package: libc6-dev
Version: 2.10.1-5
Severity: important
Any glibc since introduction of preadv/pwritev can corrupt data on 32bit
systems when a program is compiled with -D_FILE_OFFSET_BITS=64. This is most
important for qemu/kvm for which this system call was introduces, leading to
massive data
On Sun, Nov 20, 2005 at 12:17:26PM -0500, Daniel Jacobowitz wrote:
It's only less effort all around because you wouldn't have to do any
of it. Don't you think that someone would have fixed this
well-documented limitation in the last eight or so years if there was a
practical fix? There
On Thu, Aug 18, 2005 at 07:51:45PM +0900, GOTO Masanori wrote:
BTW, if we move to glibc 2.4 series in future, at that time we may
need to drop LT support. It means the traditional pre sparcv9 system
will be also dropped. Is that acceptable direction for sparc users?
(Note that dropping LT is
On Thu, Aug 18, 2005 at 08:59:17PM +0900, GOTO Masanori wrote:
- if (errno != ENOMEM) /* Unexpected failure mode. */
+ if (errno != (ENOMEM | EFAULT)) /* Unexpected failure
mode. */
I don't think errno will ever have the value of (ENOMEM | EFAULT).
Should
On Thu, Aug 11, 2005 at 04:14:55AM -0400, Nathanael Nerode wrote:
PPC libc6 should be built with TLS and NPTL
We have new enough GCC now, and new glibc. Is this fixed in the current
glibc version in unstable?
glibc in sid doesn't seem to provide NTPL yet on ppc.
--
To UNSUBSCRIBE, email
On Mon, Aug 08, 2005 at 03:59:25PM -0400, Daniel Jacobowitz wrote:
I've got no idea what you mean here, Christoph, which is funny
since I built the kernel headers packages that Debian's using in the
first place. We don't use glibc-kernheaders. We use a package called
linux-kernel-headers,
On Mon, Aug 08, 2005 at 04:12:28PM +0200, Andreas Jochens wrote:
Package: linux-kernel-headers
Version: 2.6.13+0rc3-1.1
Severity: wishlist
Tags: patch
Please install the 32-bit 'ppc' kernel headers on the ppc64 architecture.
There's no ppc64 architecture in debian (yet). Besides that you
On Mon, Aug 08, 2005 at 05:30:48PM +0200, Andreas Jochens wrote:
never use kernel headers from userland. Use glibc-kerneheaders which in
already does the proper redirecting of /usr/include/asm/ to 32 or 64 bit
versions depending on whether you're compiling with -m64 or not.
How does this
On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote:
timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or
should i rely on the ubuntu toolchain, and use that to upload kernels to sid
in the near future ? Together with a statically built procps naturally ?
The sid
On Fri, Jun 10, 2005 at 07:36:08PM +0200, Sven Luther wrote:
On Fri, Jun 10, 2005 at 07:16:02PM +0200, Christoph Hellwig wrote:
On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote:
timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or
should i rely
On Thu, Dec 09, 2004 at 01:52:03PM -0800, Randolph Chung wrote:
tag 284449 +patch
thanks
This patch fixes the utimes() problem on hppa -- the cvs patch applied
to debian's glibc has a bug in it. tested against 2.3.2.ds1-19
And while you're at it - what about submitting a kernel patch to add
On Mon, Sep 27, 2004 at 09:47:25PM +1200, Matthew Gregan wrote:
Package: libc6
Version: 2.3.2.ds1-16
Severity: wishlist
Recent versions of SuSE (e.g. SuSE 9.1, SLES 9) and Red Hat (RHEL 3AS,
Fedora Core = 1) distributions provide a support library with glibc to
allow users to make use of
On Mon, Aug 23, 2004 at 05:01:12PM +0900, GOTO Masanori wrote:
The C standard does not require this, nor does any cpp in the real
world for 10 years, so IMHO you should rather fix makedepend.
Correct. ISO C99 6.10 Preprocessing directives, Description:
A preprocessing directive
On Fri, Jul 23, 2004 at 07:05:35PM +0900, GOTO Masanori wrote:
I don't understand why you think it's bad idea. Until glibc included
mqueue, it was existed as separated library. AFAIK, there is no
application that use mqueue library in main. This means user links
mqueue library with his
On Fri, Jul 23, 2004 at 07:05:35PM +0900, GOTO Masanori wrote:
I don't understand why you think it's bad idea. Until glibc included
mqueue, it was existed as separated library. AFAIK, there is no
application that use mqueue library in main. This means user links
mqueue library with his
On Fri, Mar 26, 2004 at 07:54:45PM +0100, Martin Schulze wrote:
Hence, I believe that an upgrade directory is the way to go. The
kernel package should be maintained until sarge is released and
security patches added.
Can you patch the i48 instruction emulator into a 2.4.19 kernel?
It doesn't
On Wed, Mar 24, 2004 at 01:00:38AM +0100, Marco d'Itri wrote:
I forgot a crucial detail about mounting the kernel file systems early
in the boot process: /dev/pts must be mounted after udev has mounted its
own ramfs over /dev, so we will still need two different init script
even after
On Wed, Mar 24, 2004 at 09:56:52AM +0100, Marco d'Itri wrote:
On Mar 24, Christoph Hellwig [EMAIL PROTECTED] wrote:
Umm, why does you udev package mount a ramfs over /dev? The whole point
Because this makes the package a lot more robust, as there are no risks
of breaking the original /dev
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote:
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
sys/user.h is not part of ANSI C/C++ so this is a broken assumption.
Really guys, there's seldomly a reason to use -ansi as you're most
probably
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote:
Noticed that ksysguardd includes sys/user.h only to
get PAGE_SIZE.
other apps seem to use asm/page.h for that? Is using that
ansi safe on all platforms?
Both are wrong. Use sysconf(_SC_PAGESIZE) instead.
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote:
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
sys/user.h is not part of ANSI C/C++ so this is a broken assumption.
Really guys, there's seldomly a reason to use -ansi as you're most
probably
On Tue, Jan 06, 2004 at 07:34:26PM -0500, Nathanael Nerode wrote:
Package: linux-kernel-headers
Severity: serious
Version: 2.5.999-test7-bk-13
http://buildd.debian.org/fetch.php?pkg=linux-kernel-headersver=2.5.999-test7-bk-13arch=hppastamp=1073277157file=logas=raw
Yes, exciting! It's a
renamed to kfreebsd-gnu in config.guess to distinguish FreeBSD's kernel
The k stands for kernel of; I also tend to use KFreeBSD informally
Who came up with that?
Richard Stallman.
Oh fsck. So the GNU/Linux brainwashing is now switching to the
even more stupid GNU/KLinux?
--
On Mon, Aug 11, 2003 at 09:09:14AM +0200, Robert Lindgren wrote:
If you say it's not supposed to work on Debian, why does win4lin work on Gentoo?
They have been running 2.3.2 far longer than Debian.
2.3.2-2 is not glibc 2.3.2 but more like current CVS. Does it work
with Red Hat rawhide?
--
On Sun, Aug 10, 2003 at 02:44:59PM +0200, Rainer Ellinger wrote:
Same with compupic [1] (a static app and probably good choice to try
with) and apparently citrix iac clients [2]. Going back to 2.3.1-17
solved it for compupic.
glibc does not claim binary compatiblity for statically linked
On Fri, Jun 06, 2003 at 08:40:29AM -0400, Ben Collins wrote:
You have to check the kernel version in this case. There's no way around
it.
Or just mount devpts always..
On Tue, Jun 03, 2003 at 06:19:01PM -0500, Chris Cheney wrote:
Package: libc6-dev
Version: 2.3.1-17
Severity: serious
On hppa there appears to be a bug in /usr/include/asm/byteorder.h
It causes kdemultimedia to fail to build with the following output. This
same code in kdemultimedia
27 matches
Mail list logo
