3.7.1 release content updated in place?

[Apteryks]

Hello,

The sha256 hash of the lapack-3.7.1.tgz tarball offered at http://www.netlib.org/lapack/ seems to have changed from 0yavf6m9l78pwlnk5g61cg8x28mr30j0g8gkai0jrdqfjjmf3whs to 1j51r7n5w4k7r3lrvy7710xrpkg40wf4rqnmngfz6ck9ypckzign some time between June 26 and now.

Diffing between the two versions shows that many files were removed from the more recent one:

diff -ur lapack-3.7.1-guix/ lapack-3.7.1-upstream/
Only in lapack-3.7.1-guix/: ._lapack-3.7.1
Only in lapack-3.7.1-guix/lapack-3.7.1: ._appveyor.yml
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS: ._blas.pc.in
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS: ._CMakeLists.txt
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS: ._Makefile
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS/SRC: ._caxpy.f
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS/SRC: ._ccopy.f
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS/SRC: ._cdotc.f
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS/SRC: ._cdotu.f
Only in lapack-3.7.1-guix/lapack-3.7.1/BLAS/SRC: ._cgbmv.f

[...]

Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._zgbal.in
Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._zgd.in
Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._zgg.in
Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._zsb.in
Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._zsg.in
Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._ztest.in
Only in lapack-3.7.1-guix/lapack-3.7.1/TESTING: ._ztest_rfp.in
Only in lapack-3.7.1-guix/lapack-3.7.1: ._TESTING
Only in lapack-3.7.1-guix/lapack-3.7.1: ._.travis.ym

While those files seem harmless to the execution of the software, it would be nicer if the content of a version would be static and not mutating in time.

Perhaps using read only tags to firm version numbers instead of branches would help in this regard.

Thanks.

[AsavarTzeth]

A few days ago (at most) it changed again from sha256sum: 1af2e1aa940eb72c4154f3a1072418b922d1d163c1bc322de5171d9aaa715b79 to f6c53fd9f56932f3ddb3d5e24c1c07e4cd9b3b08e7f89de9c867125eecc9a1c8

This makes packaging a lot more tedious to me, since the file is served without TLS but I still have to verify that nothing malicious was put in there.

[langou]

To be clear, are you complaining about this tarball: http://www.netlib.org/lapack/lapack-3.7.1.tgz ?

A few days ago we had this commit on GitHub: https://github.com/Reference-LAPACK/lapack/commit/7438212bb72f56f4ef69a7a4ec1d127b703ac6cd

But I do not see how this can be related.

No idea what is going on on my end.

Julien.

[AsavarTzeth]

@langou Yes that is the file I, and most probably @Apteryks as well, is referring to.

I don't think https://github.com/Reference-LAPACK/lapack/commit/7438212bb72f56f4ef69a7a4ec1d127b703ac6cd is related though. In my case this is the diff:

diff -ru lapack-3.7.1_old/ lapack-3.7.1

Only in lapack-3.7.1_old/: CMakeCache.txt
Only in lapack-3.7.1_old/: CMakeFiles
Only in lapack-3.7.1_old/: myfile.txt

Diffing the files individually reveals minor changes to the build system. That seems to have triggered a rebuild of the tarball.

The problem is that it keeps the same version number and filename which in my case results in the build system detecting the change and complaining about a checksum mismatch, preventing the build from continuing. I then have to inspect all changes manually before I update the expected checksum.

[langou]

Thanks for clarifying. I am not sure what happened. Yes I understand this is a problem for you. I am pretty sure this is not me because my netlib.org account is deactivated for now. :)

[AsavarTzeth]

Oh well, thank you anyhow.

So I was wondering, would there be any issue in using this release repository as the source? Most importantly, are branches added once and then never changed? i.e. you use branches as if they were tags.

If so, that could be a solution to my problems for now. You see, I need that guarantee that each release is static.

[langou]

I think this is the idea. We create a branch, and then it is supposed to be static indeed.