A few small fixes have been applied to the RE24 branch for a 2.4.25 release. Please test and report.
Thanks!
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Friday, March 25, 2011 11:17 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
A few small fixes have been applied to the RE24 branch for a 2.4.25 release. Please test and report.
All tests pass for me on Fedora 11 64-bit (linux 2.6)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Tests succeeded on FreeBSD/amd64 9-CURRENT.
By the way, can we consider releasing the tarball with some modern compressor, for example xz or bzip2?
I have done some test on FreeBSD, with a simple gunzip/xz -9e cycle, the size reduced from 5240643 to 3439792 (34% smaller).
A gunzip/bzip -9 cycle would reduce the file to 4227655 bytes (20% smaller).
It seems to be worthy for the 20% (if we use bzip2) or 34% (if we use xz) bandwidth saving I think.
Cheers, - -- Xin LI delphij@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die
On Mar 25, 2011, at 1:01 PM, Xin LI wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Tests succeeded on FreeBSD/amd64 9-CURRENT.
By the way, can we consider releasing the tarball with some modern compressor, for example xz or bzip2?
First, the best time to choose a compressor is at the first release of the package. The longer a package been in distribution, the more risk of there is due to breakage of reliance of release conventions. Switching, I think, would be a really bad idea (I'm not sure you were suggesting this, I'd guess you were suggesting adding an additional compressor). But even adding a new compressor (as opposed to switching compressors) can lead to breakage in various download, verify, and/or extract scripts.
If I were to select a compressor anew for some new package, I might select bzip2 over gzip. However, I would be concerned that it's marginal compression gains come at significant computing resource consumption during compression and decompression. As I find it easier to obtain donations of bandwith than computing resources, I'm more apt to favor gzip over bzip2 even today for source releases.
I also feel that gzip has better proven portability than bzip2 and that bzip2 has better proven portability over xz. I also note that xz is not available in the default install in all modern UNIX systems, nor is it widely integrated in tar(1) compatible extractors.
I would, in making such a choice for a new package, or subsequently (as with OpenLDAP packages), avoid having multiple compressors if I could because that effectively doubles backup storage/bandwidth requirements for the tarballs.
Lastly, if one could actually reduce bandwidth enough to allow someone to order a smaller pipe, that would be significant. But 20% or 34% of OpenLDAP tarball bandwidth is not significant to allow any such reduction. Hell, I doubt our service provider (the ISC, thanks!) would even notice such a reduction. It's a small percentage of our overall bandwidth usage, and our total a very small amount of their pipe. At official mirrors, I'm sure we're also in the noise. And at the downloader, it's only 5MB a pop.
While one can argue that all those 1MB add up, I argue they don't add up to much.
-- Kurt
Am Fri, 25 Mar 2011 11:17:17 -0700 schrieb Quanah Gibson-Mount quanah@zimbra.com:
A few small fixes have been applied to the RE24 branch for a 2.4.25 release. Please test and report.
OK openSUSE-11.3 x86_64
-Dieter