Debian Bug report logs - #280213
exim4: Thinks it's always out of spool space

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: exim4: Thinks it's always out of spool space

Date: Sun, 07 Nov 2004 22:55:20 -0600

Package: exim4
Version: 4.34-6
Severity: grave
Justification: renders package unusable

exim4 is giving 452 errors to all clients.  From its log:

2004-11-07 22:30:33 spool directory space check failed: space=0
inodes=4096

Yet:

erwin:/etc/exim4# df -h /var/spool/exim4
Filesystem            Size  Used Avail Use% Mounted on
/dev/hdc5             1.2G  905M  240M  80% /var
erwin:/etc/exim4# df -i /var/spool/exim4
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hdc5                  0       0       0    -  /var

This is a reiser FS.

This makes Exim completely unusable on this system, since it absolutely
refuses to store any new mail.

Enabling debugging showed:

22:42:43 19164 SMTP<< MAIL FROM:<jgoerzen@complete.org> SIZE=1667
22:42:43 19164 ---0 Rst 0x1200e1618    **      smtp_in.c  785 32832
22:42:43 19164 ---0 Get 0x1200e1618    24        parse.c  625
22:42:43 19164 spool directory /var/spool/exim4 space = 0 blocks; inodes
= 4096; check_space = 0K (0 blocks); inodes = 0; msg_size = 6667 (1
blocks)
22:42:43 19164 LOG: MAIN
22:42:43 19164   spool directory space check failed: space=0 inodes=4096
22:42:43 19164 SMTP>> 452 Space shortage, please try later

So you can see there is an issue.

This may be of interest, from Python:

s.statvfs('/var/spool/exim4')
>>> x.f_bavail
343762L
>>> x.f_bfree
343762L
>>> x.f_blocks
509885L
>>> x.f_bsize
4096
>>> x.f_favail
2760788L
>>> x.f_ffree
2760788L
>>> x.f_files
2770848L
>>> x.f_flag
0
>>> x.f_frsize
4096

So, you can see statvfs() is not at fault here.

-- Package-specific info:
Exim version 4.34 #1 built 11-Sep-2004 11:31:20
Copyright (c) University of Cambridge 2004
Berkeley DB: Sleepycat Software: Berkeley DB 3.2.9: (June  3, 2004)
Support for: iconv() IPv6 GnuTLS
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: alpha
Kernel: Linux 2.6.4-rc2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages exim4 depends on:
ii  exim4-base                    4.34-6     EXperimental Internal Mailer -- a 
ii  exim4-daemon-light            4.34-6     Lightweight version of the Exim (v

-- no debconf information

Message #10 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@debian.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 09:25:56 +0100

# matches "not completely unusable to everyone" (important) a lot
# better than grave, let's keep rc for the time being, though.
severity 280213 serious
tags 280213 unreproducible
thanks

On 2004-11-08 John Goerzen <jgoerzen@complete.org> wrote:
[...]
> 2004-11-07 22:30:33 spool directory space check failed: space=0
> inodes=4096

> Yet:

> erwin:/etc/exim4# df -h /var/spool/exim4
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/hdc5             1.2G  905M  240M  80% /var
> erwin:/etc/exim4# df -i /var/spool/exim4
> Filesystem            Inodes   IUsed   IFree IUse% Mounted on
> /dev/hdc5                  0       0       0    -  /var

> This is a reiser FS.
[...]
> 22:42:43 19164 spool directory /var/spool/exim4 space = 0 blocks; inodes
> = 4096; check_space = 0K (0 blocks); inodes = 0; msg_size = 6667 (1
> blocks)
> 22:42:43 19164 LOG: MAIN
> 22:42:43 19164   spool directory space check failed: space=0 inodes=4096
> 22:42:43 19164 SMTP>> 452 Space shortage, please try later

> So you can see there is an issue.
[...]
> Architecture: alpha
> Kernel: Linux 2.6.4-rc2
[...]

I cannot reproduce this here (2.6.7, ix86, spool on Reiser for
testing) and this just looks extremely strange, your df (and stat) and
exim debuglog do not match. - exim ran statfs (actually statfs64) on
/var/spool/exim4 and came up with
f_bavail=0
f_ffree=4096
which does not match your df and stat-info.

Please stop exim, and run
strace -o /tmp/straceout -vf -s 132 exim4 -d -bd 2>&1 |\
   tee /tmp/exim.debug

as root, connect as user:

{ sleep 1 ; echo EHLO localhost ; sleep 1 ; \
  echo 'MAIL FROM:<ametzler@downhill.univie.ac.at> SIZE=10000000' ; \
  sleep 1 ; echo quit ; } |\
 telnet localhost smtp

kill the exim running as root with <Ctrl>-C and send this info:
1) The output of 
   grep -2 -E 'stat.*/var/spool/exim4' /tmp/straceout
2) The corresponding "spool directory /var/spool/exim4 space..."-line
in /tmp/exim.debug

3) The output of "stat -f /var/spool/exim4".
        thanks, cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #19 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Andreas Metzler <ametzler@debian.org>

Cc: 280213@bugs.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 09:05:13 -0600

On Mon, Nov 08, 2004 at 09:25:56AM +0100, Andreas Metzler wrote:
> I cannot reproduce this here (2.6.7, ix86, spool on Reiser for
> testing) and this just looks extremely strange, your df (and stat) and

Yes, I'm thinking exactly the same thing.  I wonder if it has something
to do with casts, but who knows...

[ snip instructions ]

Done.

> kill the exim running as root with <Ctrl>-C and send this info:
> 1) The output of 
>    grep -2 -E 'stat.*/var/spool/exim4' /tmp/straceout

That produced no results.  It seems that the strace didn't follow the
fork.  Hmm....

When I ran it with -ff, it produced a zero-byte file for the client.
I'm not sure what is going on there.  I'm going to investigate some more
and get back to you.

> 2) The corresponding "spool directory /var/spool/exim4 space..."-line
> in /tmp/exim.debug

I'll get back to you on that once I figure out what stat is up to.

> 3) The output of "stat -f /var/spool/exim4".
>         thanks, cu andreas

$ stat -f /var/spool/exim4
  File: "/var/spool/exim4"
    ID: 0        Namelen: 255     Type: reiserfs
Blocks: Total: 293066     Free: 57315      Available: 57315      Size:
4096
Inodes: Total: 0          Free: 0

Message #24 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Cc: Andreas Metzler <ametzler@debian.org>

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 11:22:34 -0500

[Message part 1 (text/plain, inline)]

This one time, at band camp, John Goerzen said:
> On Mon, Nov 08, 2004 at 09:25:56AM +0100, Andreas Metzler wrote:
> 
> > 3) The output of "stat -f /var/spool/exim4".
> >         thanks, cu andreas
> 
> $ stat -f /var/spool/exim4
>   File: "/var/spool/exim4"
>     ID: 0        Namelen: 255     Type: reiserfs
> Blocks: Total: 293066     Free: 57315      Available: 57315      Size:
> 4096
> Inodes: Total: 0          Free: 0
          ^^^^^^^^^^^^^^^^^^^^^^^^^

That might be the problem.  Andreas, I vaguely remember some discussion
of ReiserFS bug WRT inode count with exim?  Can't remember what version
this was fixed in.  OTOH, the OP may just be out of inodes.
-- 
 -----------------------------------------------------------------
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |
 -----------------------------------------------------------------

[Message part 2 (application/pgp-signature, inline)]

Message #29 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Stephen Gran <sgran@debian.org>

Cc: 280213@bugs.debian.org, Andreas Metzler <ametzler@debian.org>

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 10:37:44 -0600

On Mon, Nov 08, 2004 at 11:22:34AM -0500, Stephen Gran wrote:
> > > 3) The output of "stat -f /var/spool/exim4".
> > >         thanks, cu andreas
> > 
> > $ stat -f /var/spool/exim4
> >   File: "/var/spool/exim4"
> >     ID: 0        Namelen: 255     Type: reiserfs
> > Blocks: Total: 293066     Free: 57315      Available: 57315      Size:
> > 4096
> > Inodes: Total: 0          Free: 0
>           ^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> That might be the problem.  Andreas, I vaguely remember some discussion
> of ReiserFS bug WRT inode count with exim?  Can't remember what version
> this was fixed in.  OTOH, the OP may just be out of inodes.

No, it's not out of inodes.  This is normal for ReiserFS since it has no
fixed pool of inodes.  AFAIK, you can't be out of inodes on Reiser.

-- John

Message #34 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: John Goerzen <jgoerzen@complete.org>

Cc: 280213@bugs.debian.org, Andreas Metzler <ametzler@debian.org>

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 11:49:58 -0500

[Message part 1 (text/plain, inline)]

This one time, at band camp, John Goerzen said:
> On Mon, Nov 08, 2004 at 11:22:34AM -0500, Stephen Gran wrote:
> > > > 3) The output of "stat -f /var/spool/exim4".
> > > >         thanks, cu andreas
> > > 
> > > $ stat -f /var/spool/exim4
> > >   File: "/var/spool/exim4"
> > >     ID: 0        Namelen: 255     Type: reiserfs
> > > Blocks: Total: 293066     Free: 57315      Available: 57315      Size:
> > > 4096
> > > Inodes: Total: 0          Free: 0
> >           ^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > That might be the problem.  Andreas, I vaguely remember some discussion
> > of ReiserFS bug WRT inode count with exim?  Can't remember what version
> > this was fixed in.  OTOH, the OP may just be out of inodes.
> 
> No, it's not out of inodes.  This is normal for ReiserFS since it has no
> fixed pool of inodes.  AFAIK, you can't be out of inodes on Reiser.

Then it may be that it is indeed a bug with exim and inode counting.
Let me see if I can dig up the discussion . . . ah, try here:
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040223/067210.html

Does that seem similar?
-- 
 -----------------------------------------------------------------
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |
 -----------------------------------------------------------------

[Message part 2 (application/pgp-signature, inline)]

Message #39 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Stephen Gran <sgran@debian.org>

Cc: 280213@bugs.debian.org, Andreas Metzler <ametzler@debian.org>

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 11:03:50 -0600

On Mon, Nov 08, 2004 at 11:49:58AM -0500, Stephen Gran wrote:
> > No, it's not out of inodes.  This is normal for ReiserFS since it has no
> > fixed pool of inodes.  AFAIK, you can't be out of inodes on Reiser.
> 
> Then it may be that it is indeed a bug with exim and inode counting.
> Let me see if I can dig up the discussion . . . ah, try here:
> http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040223/067210.html
> 
> Does that seem similar?

It does.  However:

1. It happens for me even when there is no check_spool_inodes value set,
   or when that value is set to 0.

2. According to the log data I posted when I submitted this bug, it
   appears that Exim thinks 4096 inodes are free but there is no disk
   space free.  That is a different bug.

3. Also, on looking at that now, it seems odd that it thinks a 6K
   message would use only 1 block on a 4K block FS.

-- John

Message #44 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@logic.univie.ac.at>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Cc: Stephen Gran <sgran@debian.org>

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 18:15:07 +0100

On Mon, Nov 08, 2004 at 11:22:34AM -0500, Stephen Gran wrote:
> This one time, at band camp, John Goerzen said:
[...]
> > Inodes: Total: 0          Free: 0
>           ^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> That might be the problem.  Andreas, I vaguely remember some discussion
> of ReiserFS bug WRT inode count with exim?  Can't remember what version
> this was fixed in.

John's version of exim can deal with that (I've verified it in my own
initial test), the problem is space=0.

Exim version 4.31
-----------------
57. It seems that at least some releases of Reiserfs (which does not
have the concept of a fixed number of inodes) returns zero and not -1
for the number of available inodes. This interacted badly with
check_spool_inodes, which assumed that -1 was the "no such thing"
setting. What I have done is to check that the total number of inodes is
greater than zero before doing the test of how many are available.

            thanks, cu andreas

Message #49 received at 280213@bugs.debian.org (full text, mbox, reply):

From: "Adam D. Barratt" <debian-bts@adam-barratt.org.uk>

To: "Stephen Gran" <sgran@debian.org>, <280213@bugs.debian.org>

Cc: <280213-submitter@bugs.debian.org>

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 17:16:27 -0000

Stephen Gran wrote, on Monday, November 08, 2004 4:22 PM :

> This one time, at band camp, John Goerzen said:
>> On Mon, Nov 08, 2004 at 09:25:56AM +0100, Andreas Metzler wrote:
>>
>> > 3) The output of "stat -f /var/spool/exim4".
>> >         thanks, cu andreas
>>
>> $ stat -f /var/spool/exim4
>>   File: "/var/spool/exim4"
>>     ID: 0        Namelen: 255     Type: reiserfs
>> Blocks: Total: 293066     Free: 57315      Available: 57315      Size:
>> 4096
>> Inodes: Total: 0          Free: 0
          ^^^^^^^^^^^^^^^^^^^^^^^^^

> That might be the problem.  Andreas, I vaguely remember some discussion
> of ReiserFS bug WRT inode count with exim?  Can't remember what version
> this was fixed in.  OTOH, the OP may just be out of inodes.

I suspect you're thinking of the discussion beginning at
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20040223/msg00149.h
tml

Regards,

Adam

Message #57 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Andreas Metzler <ametzler@debian.org>

Cc: 280213@bugs.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 12:21:38 -0600

On Mon, Nov 08, 2004 at 09:25:56AM +0100, Andreas Metzler wrote:
> > So you can see there is an issue.
> [...]
> > Architecture: alpha
> > Kernel: Linux 2.6.4-rc2

I have upgraded my kernel to 2.6.9 and will try it again.

> Please stop exim, and run
> strace -o /tmp/straceout -vf -s 132 exim4 -d -bd 2>&1 |\
>    tee /tmp/exim.debug

I still don't know why, but it is definately not traversing the fork
here.  I have no clue why not.  And since it isn't, we aren't getting
useful information back.

> 1) The output of 
>    grep -2 -E 'stat.*/var/spool/exim4' /tmp/straceout
> 2) The corresponding "spool directory /var/spool/exim4 space..."-line
> in /tmp/exim.debug

 3495 spool directory /var/spool/exim4 space = 0 blocks; inodes = 4096;
 check_sp
 ace = 0K (0 blocks); inodes = 0; msg_size = 10005000 (2442 blocks)
  3495 LOG: MAIN
   3495   spool directory space check failed: space=0 inodes=4096

-- John

Message #62 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Andreas Metzler <ametzler@debian.org>

Cc: 280213@bugs.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Mon, 8 Nov 2004 13:35:15 -0600

On Mon, Nov 08, 2004 at 09:25:56AM +0100, Andreas Metzler wrote:
> > So you can see there is an issue.
> [...]
> > Architecture: alpha
> > Kernel: Linux 2.6.4-rc2
> [...]

I tried this on an i386 machine and did not see a problem.  So I dove
into the source and found that receive.c consistently is casting stuff
in the statvfs() structure (yes, this code uses statvfs(), NOT
statfs()).

Now, on Linux, this structure is defined as:

         struct statvfs {
           unsigned long  f_bsize;    /* file system block size */
           unsigned long  f_frsize;   /* fragment size */
           fsblkcnt_t     f_blocks;   /* size of fs in f_frsize units */
           fsblkcnt_t     f_bfree;    /* # free blocks */
           fsblkcnt_t     f_bavail;   /* # free blocks for non-root */
           fsfilcnt_t     f_files;    /* # inodes */
           fsfilcnt_t     f_ffree;    /* # free inodes */
           fsfilcnt_t     f_favail;   /* # free inodes for non-root */
           unsigned long  f_fsid;     /* file system id */
           unsigned long  f_flag;     /* mount flags */
           unsigned long  f_namemax;  /* maximum filename length */
         };

fsblkcnt_t is a 32-bit signed value, and fsfilcnt_t is a 32-bit unsigned
value (unless large files are in use, in which case they are both 64-bit
values).  

Consider this:

Type      | Size i386 | Size Alpha
----------+-----------+-----------
int       | 32 bits   | 32 bits
long      | 32 bits   | 64 bits
long long | 64 bits   | 64 bits

Now, in received.c, there is code such as:

  if (statbuf.F_BAVAIL < (unsigned long)
        ((((double)check_spool_space) * 1024.0 + (double)msg_size) /
            (double)statbuf.F_FRSIZE)
       ||

This could would break without long files enabled (32-bit value, 64-bit
unsigned long test)?

    debug_printf("spool directory %s space = %d blocks; inodes = %d; "
      "check_space = %dK (%d blocks); inodes = %d; msg_size = %d (%d blocks)\n",
      spool_directory, (int)statbuf.F_BAVAIL, (int)statbuf.F_FAVAIL,
      check_spool_space,
      (int)(((double)check_spool_space * 1024.0) / (double)statbuf.F_FRSIZE),
      check_spool_inodes, msg_size, (int)(msg_size / statbuf.F_FRSIZE));

Here we are casing statbuf.F_BAVAIL to an int, which could break *with*
long files enabled (converting a 64-bit value to a 32-bit one.)  I
wonder if the problem is not here necessarily.

However, my theory may not be right, since no manner of changes here
made the statvfs() call actually print out the right stuff.  So I'm
confused.

> Please stop exim, and run
> strace -o /tmp/straceout -vf -s 132 exim4 -d -bd 2>&1 |\
>    tee /tmp/exim.debug

That never worked, but I connected manually and attached strace to the
new process with -p.  Get this:

> kill the exim running as root with <Ctrl>-C and send this info:
> 1) The output of 
>    grep -2 -E 'stat.*/var/spool/exim4' /tmp/straceout

erwin:~# grep -2 -E 'stat.*/var/spool/exim4' /tmp/traceout
getxpid()                               = 18039
write(2, "18039 SMTP<< MAIL FROM:<jgoerzen"..., 60) = 60
statfs("/var/spool/exim4", {f_type="REISERFS_SUPER_MAGIC",
f_fbsize=4096, f_blocks=293066, f_bfree=55410, f_bavail=55410,
f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
getxpid()                               = 18039
write(2, "18039 spool directory /var/spool"..., 145) = 145

> 2) The corresponding "spool directory /var/spool/exim4 space..."-line
> in /tmp/exim.debug

18039 spool directory /var/spool/exim4 space = 0 blocks; inodes = 4096;
check_space = 0K (0 blocks); inodes = 0; msg_size = 1005000 (245 blocks)
18039   spool directory space check failed: space=0 inodes=4096

How's that for weird?

And again, in Python (which calls statvfs too), it all worked fine.

I'm extremely puzzled.

-- John

Message #67 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: debian-alpha@lists.debian.org

Cc: 280213@bugs.debian.org

Subject: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 14:52:36 -0600

Hi everyone,

Please take a look at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280213

For some reason, exim4 thinks my /var is always out of space, even
though it isn't.  I'm not sure why this is happening, and I think it's a
64-bit issue, but I can't quite pin it down.

Any help would be appreciated.

-- John

Message #72 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: 280213@bugs.debian.org

Subject: More info

Date: Mon, 8 Nov 2004 15:23:05 -0600

[Message part 1 (text/plain, inline)]

The attached patch is a *work around* for this.  THIS IS NOT A FIX.

Note that there is another bug here: according to the spec, space isn't
checked if the space check value is set to 0, but it is checking it
here.

Note that the unsigned int/%ld changes didn't help anything.  I just
didn't back them out.

-- John

[receive.diff (text/plain, attachment)]

Message #77 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: John Goerzen <jgoerzen@complete.org>

Cc: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 13:44:43 -0800

[Message part 1 (text/plain, inline)]

On Mon, Nov 08, 2004 at 02:52:36PM -0600, John Goerzen wrote:
> Please take a look at:

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280213

> For some reason, exim4 thinks my /var is always out of space, even
> though it isn't.  I'm not sure why this is happening, and I think it's a
> 64-bit issue, but I can't quite pin it down.

> Any help would be appreciated.

A quick glance at the build logs for exim4 show a large number of warnings
about incorrect integer<->pointer casts.  Have you tried fixing those to see
if the problem is in there somewhere?

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #82 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 15:54:59 -0600

On Mon, Nov 08, 2004 at 01:44:43PM -0800, Steve Langasek wrote:
> On Mon, Nov 08, 2004 at 02:52:36PM -0600, John Goerzen wrote:
> > Any help would be appreciated.
> 
> A quick glance at the build logs for exim4 show a large number of warnings
> about incorrect integer<->pointer casts.  Have you tried fixing those to see
> if the problem is in there somewhere?

Yes, but not in receive.c, which is the file that has the relevant code
-- which also doesn't call out to any other Exim stuff.

-- John

Message #87 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: John Goerzen <jgoerzen@complete.org>

Cc: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 14:37:48 -0800

[Message part 1 (text/plain, inline)]

On Mon, Nov 08, 2004 at 03:54:59PM -0600, John Goerzen wrote:
> On Mon, Nov 08, 2004 at 01:44:43PM -0800, Steve Langasek wrote:
> > On Mon, Nov 08, 2004 at 02:52:36PM -0600, John Goerzen wrote:
> > > Any help would be appreciated.
> > 
> > A quick glance at the build logs for exim4 show a large number of warnings
> > about incorrect integer<->pointer casts.  Have you tried fixing those to see
> > if the problem is in there somewhere?

> Yes, but not in receive.c, which is the file that has the relevant code
> -- which also doesn't call out to any other Exim stuff.

I see from your bug report that this is a reiserfs filesystem.  I've been
told that reiserfs is not considered stable on alpha; it has actually been
disabled in the sarge installer for this architecture over corruption
concerns.  This may or may not be related, but I figured it was worth
pointing out.

The other factor at work here is probably that df is using the statfs()
function from glibc, whereas exim4 is using statfs64() due to the CFLAGS
settings -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE.  We may be looking at a
broken implementation of the statfs64() libc call on alpha, or a broken
statfs64() syscall (either when pointing at reiserfs, or in general).

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #92 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 18:30:41 -0600

On Mon, Nov 08, 2004 at 02:37:48PM -0800, Steve Langasek wrote:
> On Mon, Nov 08, 2004 at 03:54:59PM -0600, John Goerzen wrote:
> I see from your bug report that this is a reiserfs filesystem.  I've been
> told that reiserfs is not considered stable on alpha; it has actually been
> disabled in the sarge installer for this architecture over corruption
> concerns.  This may or may not be related, but I figured it was worth
> pointing out.

Hmm.  I've been running it for a year or two, 24/7, with no real
problems.  I've heard that JFS is not workable on Alpha.  What modern
FSs actually work?

> The other factor at work here is probably that df is using the statfs()
> function from glibc, whereas exim4 is using statfs64() due to the CFLAGS
> settings -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE.  We may be looking at a
> broken implementation of the statfs64() libc call on alpha, or a broken
> statfs64() syscall (either when pointing at reiserfs, or in general).

You might look at the strace info in the bug report -- the statfs
syscall returned the correct info, so I think we can rule out the kernel
here.

-- John

Message #97 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 20:34:40 -0600

On Mon, Nov 08, 2004 at 02:37:48PM -0800, Steve Langasek wrote:
> The other factor at work here is probably that df is using the statfs()
> function from glibc, whereas exim4 is using statfs64() due to the CFLAGS
> settings -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE.  We may be looking at a
> broken implementation of the statfs64() libc call on alpha, or a broken
> statfs64() syscall (either when pointing at reiserfs, or in
> general).

OK, I'm going to try to weed out this.

Here is my test program:

$ cat test.c
#include <stdio.h>
#include <sys/statvfs.h>

void main(void) {
  struct statvfs buf;

  if (statvfs("/var/spool/exim4", &buf) == -1) {
    perror("statvfs");
    exit(1);
  }
  printf("f_bsize = %lu\n", buf.f_bsize);
  printf("f_rsize = %lu\n", buf.f_frsize);
  printf("f_blocks = %ld\n", (long) buf.f_blocks);
  printf("f_bfree = %ld\n", (long) buf.f_bfree);
  printf("f_bavail = %ld\n", (long) buf.f_bavail);
  printf("f_files = %lu\n", (unsigned long) buf.f_files);
  printf("f_ffree = %lu\n", (unsigned long) buf.f_ffree);
  printf("f_favail = %lu\n", (unsigned long) buf.f_favail);
  printf("f_fsid = %lu\n", buf.f_fsid);
  printf("f_flag = %lu\n", buf.f_flag);
  printf("f_namemax = %lu\n", buf.f_namemax);
}

Now, looking at things without largefile:

erwin ~/scratch/porting$ gcc -Wall -o test test.c
test.c:4: warning: return type of `main' is not `int'
test.c: In function `main':
test.c:9: warning: implicit declaration of function `exit'
erwin ~/scratch/porting$ ./test
f_bsize = 4096
f_rsize = 4096
f_blocks = 293066
f_bfree = 51914
f_bavail = 51914
f_files = 0
f_ffree = 0
f_favail = 0
f_fsid = 0
f_flag = 0
f_namemax = 255

Everything looks normal.

And:

erwin ~/scratch/porting$ gcc -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o test test.c
test.c:4: warning: return type of `main' is not `int'
test.c: In function `main':
test.c:9: warning: implicit declaration of function `exit'
erwin ~/scratch/porting$ ./test
f_bsize = 4096
f_rsize = 4096
f_blocks = 293066
f_bfree = 51914
f_bavail = 51914
f_files = 0
f_ffree = 0
f_favail = 0
f_fsid = 0
f_flag = 0
f_namemax = 255

Looks good there too.

So it looks like the kernel and libc are OK in this instance.

Thanks for the suggestions.  Keep them coming :-)

-- John

Message #102 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: 280213@bugs.debian.org, control@bugs.debian.org

Cc: debian-alpha@lists.debian.org

Subject: Exim4 problem 1-line fix

Date: Mon, 8 Nov 2004 21:02:00 -0600

tags 280213 patch
thanks

This fixes it:

--- /tmp/os.h-Linux     2004-11-08 21:00:10.000000000 -0600
+++ os.h-Linux  2004-11-08 20:45:20.000000000 -0600
@@ -7,6 +7,7 @@
 #define NO_IP_VAR_H
 #define SIOCGIFCONF_GIVES_ADDR
 #define SIG_IGN_WORKS
+#define HAVE_SYS_STATVFS_H

 /* Some versions of Linux need explicit sync-ing of directories as well as
 files. This setting requests that. If the directory is on NFS, it may not

I have no idea why it was broken before, or why it doesn't look for
statvfs() already.  But using it makes everything magically happy.

This should probably go upstream.

-- John

Message #109 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: John Goerzen <jgoerzen@complete.org>

Cc: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Mon, 8 Nov 2004 19:44:41 -0800

[Message part 1 (text/plain, inline)]

On Mon, Nov 08, 2004 at 08:34:40PM -0600, John Goerzen wrote:
> On Mon, Nov 08, 2004 at 02:37:48PM -0800, Steve Langasek wrote:
> > The other factor at work here is probably that df is using the statfs()
> > function from glibc, whereas exim4 is using statfs64() due to the CFLAGS
> > settings -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE.  We may be looking at a
> > broken implementation of the statfs64() libc call on alpha, or a broken
> > statfs64() syscall (either when pointing at reiserfs, or in
> > general).

> OK, I'm going to try to weed out this.

> Here is my test program:

FWIW, my reading of the exim4 sources shows that it calls statfs() on Linux,
not statvfs(), because the OS include file only defines HAVE_SYS_VFS_H and
not HAVE_SYS_STATVFS_H (in spite of this header's existence on Debian
systems).

> $ cat test.c
> #include <stdio.h>
> #include <sys/statvfs.h>

> void main(void) {
>   struct statvfs buf;

>   if (statvfs("/var/spool/exim4", &buf) == -1) {
>     perror("statvfs");
>     exit(1);
>   }
>   printf("f_bsize = %lu\n", buf.f_bsize);
>   printf("f_rsize = %lu\n", buf.f_frsize);
>   printf("f_blocks = %ld\n", (long) buf.f_blocks);
>   printf("f_bfree = %ld\n", (long) buf.f_bfree);
>   printf("f_bavail = %ld\n", (long) buf.f_bavail);
>   printf("f_files = %lu\n", (unsigned long) buf.f_files);
>   printf("f_ffree = %lu\n", (unsigned long) buf.f_ffree);
>   printf("f_favail = %lu\n", (unsigned long) buf.f_favail);
>   printf("f_fsid = %lu\n", buf.f_fsid);
>   printf("f_flag = %lu\n", buf.f_flag);
>   printf("f_namemax = %lu\n", buf.f_namemax);
> }

> So it looks like the kernel and libc are OK in this instance.

> Thanks for the suggestions.  Keep them coming :-)

I'm interested to know if you get the same results with statfs() instead.
FWIW, I just built an LFS version of coreutils on my alpha, and this is what
I get from df -h:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             636P  282P   80M 100% /
/dev/hda4             1.3E  -64Z   13P 101% /usr
/dev/sda5             121P -128Z   65P 101% /var
/usr/home             1.3E  -64Z   13P 101% /home
/dev/sda4             1.2E -128Z   65P 101% /mnt
/dev/sda2             545T  -16Z  3.9M 101% /realboot
tmpfs                 751P     0  188M   0% /dev/shm

Needless to say, I do not have a 751PB tmpfs. ;)  This may point to a general
problem with coreutils itself not being 64-bit clean, however, rather than
to a glibc problem.

It might be instructive to take a look at the preprocessed source from
receive.c, as well, to confirm that the various defines floating around all
end up pointing at statfs64, instead of ending up out of order and resulting
in broken struct casts.

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #114 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Subject: Re: Bug#280213: More info

Date: Tue, 9 Nov 2004 08:59:17 +0100

Hello,
Thankyou John, for doing all the hard work on this bug.

On 2004-11-08 John Goerzen <jgoerzen@complete.org> wrote:
[...]
> Note that there is another bug here: according to the spec, space isn't
> checked if the space check value is set to 0, but it is checking it
> here.
[...]

That is no bug, that is documented behavior.

 If ESMTP is in use and there was a SIZE parameter on the MAIL
 command, its value is added to the "check_spool_space" value, and the
 check is performed even if "check_spool_space" is zero, unless
 "no_smtp_check_spool_space" is set.

                   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #119 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Cc: debian-alpha@lists.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Tue, 9 Nov 2004 10:03:20 +0100

On 2004-11-08 John Goerzen <jgoerzen@complete.org> wrote:
[...]
> erwin:~# grep -2 -E 'stat.*/var/spool/exim4' /tmp/traceout
> getxpid()                               = 18039
> write(2, "18039 SMTP<< MAIL FROM:<jgoerzen"..., 60) = 60
> statfs("/var/spool/exim4", {f_type="REISERFS_SUPER_MAGIC",
> f_fbsize=4096, f_blocks=293066, f_bfree=55410, f_bavail=55410,
> f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
> getxpid()                               = 18039
[...]

Hmm, strange, why doesn't it use statfs64? Is there some special magic
on alpha to disable the effects of "-D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE"? (It does use stafs64 on ix86)
                  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #124 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Andreas Metzler <ametzler@downhill.at.eu.org>

Cc: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Tue, 9 Nov 2004 02:01:15 -0800

[Message part 1 (text/plain, inline)]

On Tue, Nov 09, 2004 at 10:03:20AM +0100, Andreas Metzler wrote:
> On 2004-11-08 John Goerzen <jgoerzen@complete.org> wrote:
> [...]
> > erwin:~# grep -2 -E 'stat.*/var/spool/exim4' /tmp/traceout
> > getxpid()                               = 18039
> > write(2, "18039 SMTP<< MAIL FROM:<jgoerzen"..., 60) = 60
> > statfs("/var/spool/exim4", {f_type="REISERFS_SUPER_MAGIC",
> > f_fbsize=4096, f_blocks=293066, f_bfree=55410, f_bavail=55410,
> > f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
> > getxpid()                               = 18039
> [...]

> Hmm, strange, why doesn't it use statfs64? Is there some special magic
> on alpha to disable the effects of "-D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE"? (It does use stafs64 on ix86)

Some syscalls on alpha simply don't have "foo64" counterparts, because they
already operate on 64-bit types (aka, "long"/"unsigned long") by default on
that architecture.

However, this doesn't guarantee that libc's exposes the same behavior to
userspace apps with and without the LFS defines.

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #129 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Tue, 9 Nov 2004 14:16:54 +0100

On 2004-11-09 Steve Langasek <vorlon@debian.org> wrote:
> On Tue, Nov 09, 2004 at 10:03:20AM +0100, Andreas Metzler wrote:
[...]
> > Hmm, strange, why doesn't it use statfs64? Is there some special magic
> > on alpha to disable the effects of "-D_FILE_OFFSET_BITS=64
> > -D_LARGEFILE_SOURCE"? (It does use stafs64 on ix86)

> Some syscalls on alpha simply don't have "foo64" counterparts, because they
> already operate on 64-bit types (aka, "long"/"unsigned long") by default on
> that architecture.

> However, this doesn't guarantee that libc's exposes the same behavior to
> userspace apps with and without the LFS defines.

Hello,
Hmm, statfs with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE seems to
be completely broken on alpha.

----------------------------
ametzler@spe142:/tmp/ametz$ cat statfstest.c
#include <stdio.h>
#include <sys/statvfs.h>
#include <sys/vfs.h>

int main(void) {
  struct statvfs buf;
  struct statfs buf2;

  if (statvfs("/var/spool", &buf) == -1) {
    perror("statvfs");
    return 1;
  }
  if (statfs("/var/spool", &buf2) == -1) {
    perror("statfs");
    return 1;
  }

  printf("            statvfs     statfs\n");
  printf("f_blocks:%10ld %10ld\n", buf.f_blocks,
                  buf2.f_blocks);
  printf("f_bfree: %10ld %10ld\n", buf.f_bfree, buf2.f_bfree);
  return 0;
}
ametzler@spe142:/tmp/ametz$ gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE  -o statfstest -Wall statfstest.c
ametzler@spe142:/tmp/ametz$ ./statfstest
            statvfs     statfs
f_blocks:    130445 410500089380237
f_bfree:      95577 285185828543351
ametzler@spe142:/tmp/ametz$ gcc -o statfstest -Wall statfstest.c
statfstest.c: In function `main':
statfstest.c:20: warning: long int format, different type arg (arg 2)
statfstest.c:20: warning: long int format, different type arg (arg 3)
statfstest.c:21: warning: long int format, different type arg (arg 2)
statfstest.c:21: warning: long int format, different type arg (arg 3)
ametzler@spe142:/tmp/ametz$ ./statfstest
            statvfs     statfs
f_blocks:    130445     130445
f_bfree:      95577      95577
----------------------------
This is spe142.testdrive.hp.com, running Debian stable.

statvfs works, as John has already noted, however I wonder whether the
proper fix is not to force usage of statvfs but to change compilation
flags and use $(getconf LFS_CFLAGS) instead of
"-D_FILE_OFFSET_BITS=64"? - There might be more similar breakage.
               cu andreas

-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #134 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: debian-alpha@lists.debian.org, 280213@bugs.debian.org

Subject: Re: Strange Exim Problem on Alpha

Date: Tue, 9 Nov 2004 08:07:26 -0600

On Mon, Nov 08, 2004 at 07:44:41PM -0800, Steve Langasek wrote:
> On Mon, Nov 08, 2004 at 08:34:40PM -0600, John Goerzen wrote:
> > OK, I'm going to try to weed out this.
> 
> > Here is my test program:
> 
> FWIW, my reading of the exim4 sources shows that it calls statfs() on Linux,
> not statvfs(), because the OS include file only defines HAVE_SYS_VFS_H and
> not HAVE_SYS_STATVFS_H (in spite of this header's existence on Debian
> systems).

You're right, and I didn't even bother to check that until later.  I
just assumed that it would be defined since we have it.  Sigh.  That's
why my 1-line patch fixes it.

I saw similar strange breakage with statfs().  However, I was not sure
whether it was my own fault for putting wrong format strings in my
printf's, since I wasn't sure exactly what data type the data would
arrive in.  According to the manpage, all the records are long, but that
doesn't make sense in the context of largefile support on 32-bit
systems, so I suspect the manpage is out of date.  But I haven't
investigated.

-- John

Message #139 received at 280213@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Andreas Metzler <ametzler@downhill.at.eu.org>

Cc: 280213@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Tue, 9 Nov 2004 08:31:55 -0600

On Tue, Nov 09, 2004 at 02:16:54PM +0100, Andreas Metzler wrote:
> Hello,
> Hmm, statfs with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE seems to
> be completely broken on alpha.

Are you sure, given these warnings?

> ametzler@spe142:/tmp/ametz$ gcc -o statfstest -Wall statfstest.c
> statfstest.c: In function `main':
> statfstest.c:20: warning: long int format, different type arg (arg 2)
> statfstest.c:20: warning: long int format, different type arg (arg 3)
> statfstest.c:21: warning: long int format, different type arg (arg 2)
> statfstest.c:21: warning: long int format, different type arg (arg 3)

-- John

Message #144 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Cc: debian-alpha@lists.debian.org

Subject: Re: Bug#280213: exim4: Thinks it's always out of spool space

Date: Tue, 9 Nov 2004 16:21:54 +0100

On 2004-11-09 John Goerzen <jgoerzen@complete.org> wrote:
> On Tue, Nov 09, 2004 at 02:16:54PM +0100, Andreas Metzler wrote:
> > Hmm, statfs with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE seems to
> > be completely broken on alpha.

> Are you sure, given these warnings?

> > ametzler@spe142:/tmp/ametz$ gcc -o statfstest -Wall statfstest.c
> > statfstest.c: In function `main':
> > statfstest.c:20: warning: long int format, different type arg (arg 2)
[...]

As can be seen from the typescript I only got these warning when
building *without* -D_FILE_OFFSET_BITS=64. gcc -Wall did not find
anything to worry about with -D_FILE_OFFSET_BITS=64, i.e. the printf
types were correct for this case.
                   cu andreas

Message #149 received at 280213@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: John Goerzen <jgoerzen@complete.org>, 280213@bugs.debian.org

Cc: debian-alpha@lists.debian.org

Subject: Re: Bug#280213: Exim4 problem 1-line fix

Date: Tue, 9 Nov 2004 18:56:36 +0100

On 2004-11-09 John Goerzen <jgoerzen@complete.org> wrote:
[...]
> --- /tmp/os.h-Linux     2004-11-08 21:00:10.000000000 -0600
[...]
> +#define HAVE_SYS_STATVFS_H
[...]
> I have no idea why it was broken before, or why it doesn't look for
> statvfs() already.  But using it makes everything magically happy.
[...]

Hello,
Is using statfs() really wrong?

Afaict from a little bit of surfing the native interface on Linux is
statfs(), support for statvfs() was a more recent addition (although
LSB requires it and discourages its use).

Anyway, I think the source is bug to be funky errors on alpha with
-D_FILE_OFFSET_BITS=64 and if I am going to sidestep this I'd rather
do it properly than by using a function that is not broken by this
issue. - Can you please test whether this patch fixes the issue for
you?

--------------
--- debian/rules.old	2004-08-01 12:28:49.000000000 +0200
+++ debian/rules	2004-11-09 18:39:47.000000000 +0100
@@ -16,7 +16,7 @@
 
 DEBIAN:=$(shell pwd)/debian
 
-CFLAGS = -g -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing
+CFLAGS := -g -Wall $(shell getconf LFS_CFLAGS) -D_LARGEFILE_SOURCE -fno-strict-aliasing
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 CFLAGS += -O0
--------------

        thanks, cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #154 received at 280213-close@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@debian.org>

To: 280213-close@bugs.debian.org

Subject: Bug#280213: fixed in exim4 4.34-8

Date: Sat, 20 Nov 2004 06:17:06 -0500

Source: exim4
Source-Version: 4.34-8

We believe that the bug you reported is fixed in the latest version of
exim4, which is due to be installed in the Debian FTP archive:

exim4-base_4.34-8_i386.deb
  to pool/main/e/exim4/exim4-base_4.34-8_i386.deb
exim4-config_4.34-8_all.deb
  to pool/main/e/exim4/exim4-config_4.34-8_all.deb
exim4-daemon-heavy_4.34-8_i386.deb
  to pool/main/e/exim4/exim4-daemon-heavy_4.34-8_i386.deb
exim4-daemon-light_4.34-8_i386.deb
  to pool/main/e/exim4/exim4-daemon-light_4.34-8_i386.deb
exim4_4.34-8.diff.gz
  to pool/main/e/exim4/exim4_4.34-8.diff.gz
exim4_4.34-8.dsc
  to pool/main/e/exim4/exim4_4.34-8.dsc
exim4_4.34-8_all.deb
  to pool/main/e/exim4/exim4_4.34-8_all.deb
eximon4_4.34-8_i386.deb
  to pool/main/e/exim4/eximon4_4.34-8_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 280213@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Metzler <ametzler@debian.org> (supplier of updated exim4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 20 Nov 2004 10:52:18 +0100
Source: exim4
Binary: eximon4 exim4-daemon-custom exim4-daemon-heavy exim4-base exim4 exim4-daemon-light exim4-config
Architecture: source i386 all
Version: 4.34-8
Distribution: unstable
Urgency: medium
Maintainer: Exim4 Maintainers <pkg-exim4-maintainers@lists.alioth.debian.org>
Changed-By: Andreas Metzler <ametzler@debian.org>
Description: 
 exim4      - An MTA (Mail Transport Agent)
 exim4-base - EXperimental Internal Mailer -- a Mail Transport Agent
 exim4-config - Debian configuration for exim4
 exim4-daemon-heavy - Exim (v4) with extended features, including exiscan-acl
 exim4-daemon-light - Lightweight version of the Exim (v4) MTA
 eximon4    - X monitor for the Exim (v4) mail transport agent
Closes: 280213 280647 281840
Changes: 
 exim4 (4.34-8) unstable; urgency=medium
 .
   * The real-life-takes-its-toll-release.
   * Use statvsf() instead of statfs(), fixing complete breakage on
     alpha/ReiserFS (Closes: #280213). Thanks to John Goerzen for finding and
     debugging this.
   * Use getconf LFS_CFLAGS instead of hardcoding -D_FILE_OFFSET_BITS=64 to
     prevent similar bugs.
   * Translation updates:
     - tr (Turkish) by Recai Oktas (Closes: #281840)
   * new patch 63_nomorecrashongnutlserror pulled from 4.40: "If a server
     dropped the connection unexpectedly when an Exim client was using GnuTLS
     and trying to read a response, the client delivery process crashed while
     trying to generate an error log message." (Closes: #280647)
Files: 
 313787cc14eea300391d6beb71243fdb 1062 mail important exim4_4.34-8.dsc
 fcdbe6f42435b880ac7c91f0a8939063 519540 mail important exim4_4.34-8.diff.gz
 8c2e461b5b6d65e44e6a9eb807c2728e 790016 mail important exim4-base_4.34-8_i386.deb
 8eabe822ded36f8aa1a2afac49d55485 347198 mail important exim4-daemon-light_4.34-8_i386.deb
 e2b6cb300a7a30d9bd9b29e7e1250177 70740 mail optional eximon4_4.34-8_i386.deb
 ecf2e3710c18815354e89fcfb84bb6c8 416382 mail optional exim4-daemon-heavy_4.34-8_i386.deb
 c24a508a82e33e42816e71d0c6b68148 201958 mail important exim4-config_4.34-8_all.deb
 041f7bacee3a30798a9648189f6b9347 1202 mail important exim4_4.34-8_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBnyC8HTOcZYuNdmMRAqCTAJ4x6YFmeLtKyUnXw3k++IFzSknnWwCfcIBb
SZMZCc2zVzy1/VKDPSCoGkc=
=h84i
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.