Bug#67127: This bug should be closed

2013-10-16 Thread Santiago Vila 
On Tue, 15 Oct 2013, Stephen R. van den Berg wrote:

 This (locking problem) is not a bug in procmail, as it happens, locking over
 NFS is tricky to get right, and it is the responsibility of the system
 administrator to get it right using the correct statd/lockd
 settings/configuration when mounting the filesystems.
 
 Procmail tries to accomodate for sysadmins messing up here, but it can only do
 so if the said filesystems are available for testing at compile time.
 If you are using a precompiled procmail and use filesystems configured worse
 than the systems that were available during the compile time tests, procmail
 can both hang or simply fail to lock.
 
 This bug is not a bug in procmail and should be closed.

I have just closed this bug because the submitter said he could not
reproduce it anymore.

I just wanted to comment on your reply: IMHO, the idea that sysadmins
should build procmail and perform compile time tests may make sense in
a *general* way, but IMHO it does not fit very well with Debian spirit.

In Debian, it was determined a long time ago that the correct way to
perform locking was fcntl() + dot locking, which apparently is the thing
that works well (or the only thing that has some possibility to work)
with Linux.

This is also written in Debian policy:

http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-mail-transport-agents

 All Debian MUAs, MTAs, MDAs and other mailbox accessing programs (such
 as IMAP daemons) must lock the mailbox in an NFS-safe way. This means
 that fcntl() locking must be combined with dot locking. To avoid
 deadlocks, a program should use fcntl() first and dot locking after
 this, or alternatively implement the two locking methods in a non
 blocking way[100]. Using the functions maillock and mailunlock
 provided by the liblockfile*[101] packages is the recommended way to
 realize this.

For this reason, the Debian procmail package has LOCKINGTEST=100.
This should effectively make unnecessary that Debian users do any
build time tests.

In general, asking users that they should build their own packages is
contrary to Debian philosophy. Our job is precisely (among other things)
trying to avoid that.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#67127: This bug should be closed

2013-10-16 Thread Stephen R. van den Berg 
On Wed, Oct 16, 2013 at 11:52 AM, Santiago Vila sanv...@unex.es wrote:

 I just wanted to comment on your reply: IMHO, the idea that sysadmins
 should build procmail and perform compile time tests may make sense in
 a *general* way, but IMHO it does not fit very well with Debian spirit.


I understand that.  I am an avid user of Debian myself, since 1995.


 In Debian, it was determined a long time ago that the correct way to
 perform locking was fcntl() + dot locking, which apparently is the thing
 that works well (or the only thing that has some possibility to work)
 with Linux.


That is fine.  But then special care should be taken to correctly configure
NFS mounts to either simply work with fcntl locks, or fail without
hanging.  Once procmail has to lock, the fcntl can either succeed, fail or
hang indefinitely.  Once it hangs indefinitely, procmail has no means to
fix it.


 In general, asking users that they should build their own packages is
 contrary to Debian philosophy. Our job is precisely (among other things)
 trying to avoid that.


Well, I wasn't asking that, I was just remarking that after procmail has
been compiled, there is not a lot of leeway to fix things at runtime.
-- 
Stephen.

Bug#67127: This bug should be closed

2013-10-15 Thread Stephen R. van den Berg 
This (locking problem) is not a bug in procmail, as it happens, locking 
over NFS is tricky to get right, and it is the responsibility of the 
system administrator to get it right using the correct statd/lockd 
settings/configuration when mounting the filesystems.


Procmail tries to accomodate for sysadmins messing up here, but it can 
only do so if the said filesystems are available for testing at compile 
time.
If you are using a precompiled procmail and use filesystems configured 
worse than the systems that were available during the compile time 
tests, procmail can both hang or simply fail to lock.


This bug is not a bug in procmail and should be closed.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org