On Fri, May 29, 2020 at 05:42:06PM -0700, Tianon Gravi wrote: > On Fri, 29 May 2020 at 17:36, William Lallemand <[email protected]> > wrote: > > Indeed the tarball was regenerated by accident. As lots of build system > > out there checks the previous checksum I'm going to reupload the > > previous one. > > > > ... > > > > The content of the tarball didn't changed, only the metadata. > > > > I'm reuploading the old one as well as the .md5 and .sha256. > > > > Thanks for the report and sorry for the trouble! > > No trouble at all, it's a pretty honest mistake, and of the type I'm > sure we've all made at some point (I sure have); no harm done. <3
FWIW I took great care of producing reproducible archives, but you know how it is, they are reproducible until you figure they're not! I've just changed the gzip arguments in the publish-release script to add "-n" to drop the timestamp, and I could verify that we now produce the exact same tar.gz each time. Of course this could still change after a system upgrade but at least it will improve the situation for the rare cases where we need to rebuild a release. And for those who would wonder why we don't prevent against doing so, well, that was the original behavior and it was a real pain, because it's not uncommon to fail a release for various reasons (permissions, space on disk, ctrl-c during the operation to change something etc). And I found over time that cleaning all the mess by hand is much less reproducible than letting the script try to perform an idempotent operation and converge towards a working release. Thanks Tianon for reporting and for watching! For all those involved in the release process, it's relieving to know that occasional mistakes are quickly spotted, because there are a few hours after a release during which you can't help but think "did I do this, did I do that?". Knowing that no comment implies a good release is pleasant :-) Cheers, Willy
