There will never be a shortage of things to do on the new FATE Server. I didn’t succeed in much tonight but I did modify one minor detail: Rather than reporting the build record times as absolute UTC timestamps, the system now reports that a build record was logged, e.g., 8h45m ago. I think it’s a little more useful. It even correctly reports that the last x86_32 for gcc 2.95.3 occurred 8 days ago (at the time of this writing), which leads me to the next item…

The problem with the 2.95.3, as mentioned in a previous post, is that the build produces an extraordinary number of warnings, upwards of 900K. Don’t worry about the storage implications because A) I have tons of space; and B) I am storing build stdout/stderr text compressed using MySQL’s COMPRESS() and UNCOMPRESS() functions. When the client script tries to send over the 900K of text data, something goes bad (server hangs and eventually times out).

So, why not compress the data on the client side before sending it to the server? I’ll tell you why– because MySQL’s UNCOMPRESS() function doesn’t like the data if it is compressed by either Python’s internal zlib module or if it’s compressed by command line gzip. Other solutions? Perhaps having MySQL installed on the client machine so that the script can process the data through MySQL locally before feeding it to the server?

A little googling turns up this recent blog post discussing the matter. It seems that MySQL prepends standard zlib data with a 30-bit “decompressed-length” field (4 bytes with 2 bits masked). When I am more awake, I may try to add those bytes manually to the compressed string.

Manipulating binary data in very high level languages always frightens me.

Update: If you would like to see a solution to this problem in Python, see Clientside MySQL Compression.