[Box Backup-dev] Getting trunk ready for release

[Martin Ebourne]

On Thu, 2005-12-15 at 03:10 +0000, Jonathan Morton wrote:
> I'd like to see a fresh release with the merged code in it soon, if  
> possible.

<cheer>

> - Raidfile tests break horribly.  This is a regression from a day or  
> two ago, when merging the win32 port suddenly made them all work.

I've not seen these work since before the win32 stuff merged. 240
failures or something. Are you sure you saw them work after the win32
stuff?

I looked at this last night. The first failure for me was line 1298 in
RaidFileRead.cpp:

	// Lovely!
	length = stripe1LastData ^ parityLastData;
	// Convert to host byte order
	length = box_ntoh64(length);
	ASSERT(length <= (paritySize + stripe1Size));

Length has rubbish in it, presumably because one or both of the LastData
vars are wrong. I couldn't see why and didn't debug further, it was gone
1 am this morning. :)

> - Berkeley DB is still not detected by the autoconf scripts.  I think  
> this is because it's looking for libdb-1.so instead of libdb1.so.   
> But I don't know whether the other name appears on other platforms.

That's an easy fix, just look for both. Before release though I'd like
to get it detecting and using db4 if it is available.

> - One other test fails:  bbackupd, apparently in the "interrupted  
> restore" test.  This is probably a fault in the test script or the  
> front-end, without affecting actual operation, but best to fix it  
> either way.

Tried this one in debug mode and it failed to start bbackupd due to the
time assert I mailed about last night. Didn't get any further.

> - Compilation emits warnings in a few places.

Most of the warnings for me are due to 64 bit and printf. At some point
it needs to be ostreamed.

I think for the bug fixing it comes down simply to someone doing it. I
fixed one and found one last night and will continue to persevere when I
get chance, but there's no reason we can't all fix bugs.

It would be nice if Ben could take a look at the raidfile test because
he knows what the code should be doing at each point and is more likely
to spot the problem. Must be something fairly fundamental to get 240
failures!

Cheers,

Martin.