i unpacked roundup 0.5.1 and run 'python ./run_tests' in 
the source code directory, giving following error 
message:

packing up templates in roundup/templates/classic
packing up templates in roundup/templates/minimal
......................F.........................................................
...
=========================================
=============================
FAIL: test_basics (test.test_locking.LockingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test/test_locking.py", line 39, in test_basics
    raise AssertionError, 'no exception'
AssertionError: no exception

----------------------------------------------------------------------
Ran 83 tests in 49.982s

FAILED (failures=1)

anyone has anyidea?

Logged In: YES 
user_id=6405

This is a known bug on Solaris, unfortunately. 
 
In a nutshell, it doesn't block when acquiring locks, and I don't know why. 
 

Logged In: YES 
user_id=663727

We get the same test failure with roundup-0.5.2 on Irix
6.5.5.

test/test_locking.py appears to expect that
    acquire_lock(path)
    acquire_lock(path,block=0)
should raise an exception, which (via
roundup.backends.locking and
roundup.backends.portalocker) boils down to expecting that
    file1 = open(path,'w')
    fcntl.flock( file1.fileno(), fcntl.LOCK_EX )
    file2 = open(path,'w')
    fcntl.flock( file2.fileno(), fcntl.LOCK_EX |
fcntl.LOCK_NB )
will raise an exception (presumably IOError).

On Linux (2.4.2-2 i686), it does. On Irix, it doesn't.

It's not clear to me that there is a correct behaviour
here.  If the
same process asks for an exclusive lock on the same file a
second time,should the OS respond:
(a) "No, there is already an exclusive lock on that file
(even though
    you are the process holding that lock)."
or
(b) "Sure, you can have the lock. In fact, you already had
it."

(Interestingly, if you change the code to:
    file1 = open(path,'w')
    fcntl.flock( file1.fileno(), fcntl.LOCK_EX )
    fcntl.flock( file1.fileno(), fcntl.LOCK_EX |
fcntl.LOCK_NB )
then neither Linux or Irix raise an exception. That is, when
the same
process re-requests a lock on the same file, Linux makes a
distinction
based on whether the request is made via the same file
descriptor or
not. This seems very odd to me, since locks are on files,
not file
descriptors.)

Anyway, I'm wondering if roundup actually relies on the
behaviour that
this test case expects. That is, might a roundup process
actually try
to obtain multiple locks on the same file?

(My suspicion is that roundup only requires that *different*
processes
can't both acquire exclusive locks on the same file. *That*
works on
both Linux and Irix, but it isn't what the test case is
testing.)

Logged In: YES 
user_id=6405

Yes, the actual situation we're testing is for separate processes trying to  
access the same resource. The unit test is somewhat flawed in that respect  
- though as you say, it works on Linux, which is my development platform. 
 
IIRC, I couldn't get Solaris to block in a separate process - so it didn't work in 
either situation. 
 

Logged In: YES 
user_id=6405

I've disabled the locking test.