Hi,
> In JSPWiki, we have a .graffle file, too. Although this is XML, I consider > this a binary file, just like a JPEG image for example. It's the document > format of Graffle, a graphics software for Mac OS X. > In the Celix case the file can/should be removed. But otherwise, it being a file created by a tool, a NOTE or README file can be used to "set" the license. Celix uses this to clearify the license information on some input files which are processed during the build. > > > I agree that the download problem is not a blocker for the release. > Until it is fixed, I suggest adding a note to any vote e-mails to warn > reviewers about the problen. > > Using wget, I was able to download the archive, sig and hashes. > > The problem underneath is: When the browser tells "Accept-Encoding gzip" > in its HTTP request header, it can be that a .gz download gets gzipped > again. Although the server correctly responses with "Content-Encoding > gzip", the browser may not handle this download correctly and save it > double gzipped to disk. So you end up with a file .tar.gz which in fact is > a .tar.gz.gz format. Gunzipping this manually leads to the correct data. > So, > * there isn't any real data corruption and > * it seems to be at least not only the server part which is to blame here > This is what I noticed as well. It seems more likely that the browser does something wrong here. Looking at the headers I couldn't find anything strange. Funny thing is, for Chrome a bug has been solved to strip an extra gz from downloaded files: [1] [1]: http://code.google.com/p/chromium/issues/detail?id=58168 -- Met vriendelijke groet, Alexander Broekhuis
