flac dev - Feb 2017 - Re-release of version 1.3.2?

Hello,

The project I work on, the Clear Linux Project for Intel Architecture,
regularly scans for new releases of upstream packages. On January 1, the
scans detected a flac 1.3.2 release tarball. However, when a build was
attempted at a later date (January 10), a hash mismatch was detected
between the originally detected release tarball and the one currently
published at the download mirrors.

The original tarball detected had the following checksums:

MD5: 7c4f5cc85f953313a9134197b0db14ec
SHA1: 658d1acc9e39267de8ca377f2aa8ece677aee2cd
SHA256: e48764f0761beb791a69590f12826fe8cf302c42db2879849c5d10bc7c85db66

I also discovered that the Fedora 26 Rawhide source RPM contains this
same tarball that differs from the currently published one.

Comparing the two tarballs, there are many timestamp differences on
files, which might imply that the release tarball was regenerated at a
later time, and there is a very small diff in content. The diff is
attached.

Since this appears to have been a re-release of version 1.3.2, was this
an intentional re-release?

Regards,
-Patrick
-------------- next part --------------
diff -Nru flac-1.3.2-v1/doc/html/Makefile.in flac-1.3.2-v2/doc/html/Makefile.in
--- flac-1.3.2-v1/doc/html/Makefile.in	2016-12-31 17:48:15.797331121 -0800
+++ flac-1.3.2-v2/doc/html/Makefile.in	2016-12-31 19:46:48.889726465 -0800
@@ -664,9 +664,9 @@
 maintainer-clean-generic:
 	@echo "This command is intended for maintainers to use"
 	@echo "it deletes files that may require special tools to rebuild."
+ at FLaC__HAS_DOXYGEN_FALSE@distclean-local:
 @FLaC__HAS_DOXYGEN_FALSE at uninstall-local:
 @FLaC__HAS_DOXYGEN_FALSE at install-data-local:
- at FLaC__HAS_DOXYGEN_FALSE@distclean-local:
 clean: clean-recursive
 
 clean-am: clean-generic clean-libtool mostlyclean-am
diff -Nru flac-1.3.2-v1/test/metaflac-test-files/case07-expect.meta
flac-1.3.2-v2/test/metaflac-test-files/case07-expect.meta
--- flac-1.3.2-v1/test/metaflac-test-files/case07-expect.meta	2016-12-31
16:52:09.366371726 -0800
+++ flac-1.3.2-v2/test/metaflac-test-files/case07-expect.meta	2016-12-31
19:54:28.827304796 -0800
@@ -1,4 +1,4 @@
-reference libFLAC 1.3.1 20141125
+reference libFLAC 1.3.2 20170101
 ARTIST=The_artist_formerly_known_as_the_artist...
 ARTIST=Chuck_Woolery
 ARTIST=Vern

Patrick McCarty wrote:
> Since this appears to have been a re-release of version 1.3.2, was this
> an intentional re-release?
Yes it was. The bad tarball was on on the main upload site for
a couple of hours but problems with the mirroring meant that
the bad tarball lingered on some of the mirrors for much longer.

The reason the bad tarball was bad the bad date in one of the
test files.shown in the diff below.

Erik


diff -Nru flac-1.3.2-v1/test/metaflac-test-files/case07-expect.meta
flac-1.3.2-v2/test/metaflac-test-files/case07-expect.meta
--- flac-1.3.2-v1/test/metaflac-test-files/case07-expect.meta	2016-12-31
16:52:09.366371726 -0800
+++ flac-1.3.2-v2/test/metaflac-test-files/case07-expect.meta	2016-12-31
19:54:28.827304796 -0800
@@ -1,4 +1,4 @@
-reference libFLAC 1.3.1 20141125
+reference libFLAC 1.3.2 20170101
 ARTIST=The_artist_formerly_known_as_the_artist...
 ARTIST=Chuck_Woolery
 ARTIST=Vern



-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Hi Erik,

On 2017-02-07 at 18:20:36 +1100, Erik de Castro Lopo
wrote:
> Patrick McCarty wrote:
> 
> > Since this appears to have been a re-release of version 1.3.2, was
this
> > an intentional re-release?
> 
> Yes it was. The bad tarball was on on the main upload site for
> a couple of hours but problems with the mirroring meant that
> the bad tarball lingered on some of the mirrors for much longer.
> 
> The reason the bad tarball was bad the bad date in one of the
> test files.shown in the diff below.
Thanks for confirming that the re-release was intentional.

Might I recommend for the future that in case a bad tarball is ever
produced for a release, the version number be bumped when redoing the
release? In this case, leaving the bad tarball in place would be
sufficient, as well as announcing that users should not use that version
and upgrade to a later version with the fixed tarball.

Regards,
-Patrick