Roger Leigh rle...@codelibre.net writes:
On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote:
Maybe we need a mass bug filing for programs not using 64bit file
offsets.
I think that would be appropriate. At this point, I can't see a
valid reason for any package to not
On Thu, Feb 26, 2009 at 10:48:35AM +, Roger Leigh wrote:
Agreed. If we can identify all libraries (perhaps with a simple grep over
the lintian lab?) containing these types, and make sure LFS is enabled in
all of them, it should then be possible to switch once all dependencies
are
Ron Johnson ron.l.john...@cox.net writes:
On 02/09/2009 08:04 AM, Ron Johnson wrote:
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk
wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load
Goswin von Brederlow, le Wed 25 Feb 2009 16:16:53 +0100, a écrit :
Anyone up for hacking libc to always fail on the 32bit wrappers for
seek, stat, ...?
Or looking for binaries with a U lseek ?
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote:
Maybe we need a mass bug filing for programs not using 64bit file
offsets.
I think that would be appropriate. At this point, I can't see a
valid reason for any package to not have LFS enabled.
Anyone up for hacking libc
On Wed, Feb 25, 2009 at 10:52:30PM +, Roger Leigh wrote:
Personally, I would prefer the glibc headers to just set the LFS
macros to the 64 bit versions by default, so that rather than
taking extra steps to enable LFS, LFS would be the default and you
would then need to take extra steps to
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will be only the first of
On 02/09/2009 08:04 AM, Ron Johnson wrote:
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk
wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fixed
by
On Sun, Feb 08, 2009 at 10:46:42AM +, Jörg Sommer wrote:
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. (...) The error can be fixed by compiling
Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all
32‐bit builds or does it have
hi,
On Sun, Feb 08, 2009 at 12:58:43PM +0100, Lionel Elie Mamane wrote:
I'd think you should enable it for all 32 bit builds; it is, I think,
a step in having support for large files (files bigger than 2 or 4
gigabytes), something we wanted to have for... woody.
more specifically, what i
On 02/08/2009 04:46 AM, Jörg Sommer wrote:
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a
On Sun, 2009-02-08 at 10:46 +, Jörg Sommer wrote:
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will be only the first of its problems.
Old vi was able to work with files
14 matches
Mail list logo
