Opened 7 years ago

Closed 7 years ago

#54162 closed defect (fixed)

lz4 @1.7.5: File changed, checksum error, but no file version change - stealth update

Reported by: kencu (Ken) Owned by: mfeiri
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port: lz4

Description

lz4 file has slightly changed recently, by 8 bytes, for some reason:

$ ls -la
total 816
drwxr-xr-x    4 macports  admin     136 11 May 15:04 .
drwxr-xr-x  476 root      admin   16184 10 May 18:12 ..
-rw-r--r--    1 macports  admin  208048 11 May 15:04 lz4-1.7.5.tar.gz
-rw-r--r--    1 macports  admin  208040  2 Feb 19:03 lz4-1.7.5.tar.gz.old

so the checksum is wrong now. New checksum is

-checksums           rmd160  18d702aa7d517c9a9258508e9466527897c4f98d \
-                    sha256  14519a50ccc813b9fcd6170d61f104a531f52a75101b7c64497ef408502f0f54
+checksums           rmd160  2668d371730b9aa690158b1c0f71cb4f15293f74 \
+                    sha256  fd7db191ad70e6fa895a1f743b753dee1992282c09a694a101a84dc91d1579ad
 

This would appear to need the stealth-update procedure.

Change History (6)

comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign added; mfeiri@… removed
Owner: set to mfeiri@…
Status: newassigned
Summary: lz4. File changed, checksum error, but no file version change - stealth updatelz4 @1.7.5: File changed, checksum error, but no file version change - stealth update

I've put the old distfile on the mirror server.

The old distfile uses git commit 7bb64ff. The new file uses git commit a8dd86d. There's no difference in the contents however so there's no need to increase the revision.

I don't see why this change would be correct. 1.7.5 was released January 2, 2017 and is tagged at 7bb64ff. a8dd86d is master from May 2, 2017. Maybe this is a GitHub infrastructure bug? I can't really figure it out.

comment:2 Changed 7 years ago by raimue (Rainer Müller)

The lz4 repository contains both a tag and a branch with the exact same name "v1.7.5". It looks like the branch was created a few days ago. This seems to confuse GitHub. The URL https://github.com/lz4/lz4/tarball/v1.7.5 still uses the tag commit as the filename (in Content-Disposition) and also uses the tag for the content, but the top-level directory in the tarball refers to the branch head.

Definitely a bug at GitHub. I have contacted them about this problem.

comment:3 Changed 7 years ago by raimue (Rainer Müller)

In 32da2b5c639b0f130343d34a022154c9ed8b807f/macports-ports:

lz4: Apply temporary fetch workaround

The GitHub website creates a bogus tarball because v1.7.5 is an
ambiguous refname in the lz4 repository. The workaround is to use the
commit hash to uniquely identify the commit we want to fetch.

See: #54162

comment:4 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Reported to the developers: https://github.com/lz4/lz4/issues/364

comment:5 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

They've removed the branch. That should fix the problem.

comment:6 Changed 7 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: assignedclosed

In 106c3aabe4bab5de5fab6db7a77d9867e374fe9c/macports-ports:

Revert "lz4: Apply temporary fetch workaround"

The branch leading to the ambiguous refname was deleted upstream.
Reverting the workaround as it is no longer necessary.

This reverts commit 32da2b5c639b0f130343d34a022154c9ed8b807f.

Closes: #54162

Note: See TracTickets for help on using tickets.