Bug#747672: Dropping patch

2016-06-22 Thread Sean Whitton 
Hello,

On Wed, Jun 22, 2016 at 12:48:11PM +0200, Svante Signell wrote:
> You did the right thing to remove that patch, and reopen the bug. GNU/Hurd 
> will
> soon have lockf support too. However, the testsuite fails, sometimes also with
> the lock.patch applied, ending with:
> Test 3
> Third backup/restore comparison, with changes
> Killing test server
> 
> Since the testsuite is run by scripts it is difficult to find out the cause
> using gdb. Is there some simple way to set a breakpoint to debug this issue?

I saw this on the buildds, but not when I fired up a Hurd VM locally, so
indeed, it would be good to track down the intermittent failure.

As you have probably figured out yourself, most of the tests happen in
the shell script test/test_main.  You could try modifying the arguments
it passes to burp to generate more verbose output.  Or you could have
the test suite call burp inside gdb.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#747672: Dropping patch

2016-06-22 Thread Svante Signell 
Hi Sean,

On Wed, 2016-06-22 at 14:32 +0900, Sean Whitton wrote:
> control: found -1 burp/1.4.40-1
> 
> Dear Svante,
> 
> Although the burp 1.4.40 test suite passes with this patch applied,
> upstream reports that the 2.0.x series test suite finds a problem.  The
> patch causes this problem when applied to burp 1.4.40, even though the
> older test suite passes.
> 
> Since this is an old bug, I am preparing a QA upload to drop the patch
> for now.
...
> > As you can see, get_lock() has three different return codes that mean
> > different things.
> > If you check 'man 2 flock', you will see that flock() will never set errno
> > to EACCES or EAGAIN. This means that get_lock() will never detect the
> > difference between a lock existing, or some error.
> Thanks to Graham for letting me reproduce this explanation.

Explanation understood and appreciated!

You did the right thing to remove that patch, and reopen the bug. GNU/Hurd will
soon have lockf support too. However, the testsuite fails, sometimes also with
the lock.patch applied, ending with:
Test 3
Third backup/restore comparison, with changes
Killing test server

Since the testsuite is run by scripts it is difficult to find out the cause
using gdb. Is there some simple way to set a breakpoint to debug this issue?

Thanks!

Bug#747672: Dropping patch

2016-06-21 Thread Sean Whitton 
control: found -1 burp/1.4.40-1

Dear Svante,

Although the burp 1.4.40 test suite passes with this patch applied,
upstream reports that the 2.0.x series test suite finds a problem.  The
patch causes this problem when applied to burp 1.4.40, even though the
older test suite passes.

Since this is an old bug, I am preparing a QA upload to drop the patch
for now.

Burp's author Graham Keeling explains:

> Here is the code in 1.4.40.
>
> // Return 0 for lock got, 1 for lock not got, -1 for error.
> int get_lock(const char *path)
> {
> ... some set up
> if(lockf(fdlock, F_TLOCK, 0))
> {
> if(errno==EACCES || errno==EAGAIN)
> return 1; // Lock not got.
> logp("Could not get lock %s: %s\n", path, strerror(errno));
> return -1; // Some other error.
> }
> ...some more code...
> return 0;
> }
>
>
> As you can see, get_lock() has three different return codes that mean
> different things.
> If you check 'man 2 flock', you will see that flock() will never set errno
> to EACCES or EAGAIN. This means that get_lock() will never detect the
> difference between a lock existing, or some error.

Thanks to Graham for letting me reproduce this explanation.

-- 
Sean Whitton


signature.asc
Description: PGP signature