Opened 9 months ago
Last modified 7 months ago
#69395 assigned defect
codeberg projects (star smake cl-nodgui cdrtools): checksum mismatch
Reported by: | mrkapqa | Owned by: | RobK88 |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.1 |
Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt), catap (Kirill A. Korinsky), TonyCrawford, RobK88 | |
Port: | star smake cl-nodgui cdrtools |
Description
Hello ,
on MacOS Monterey the following error for Cdrtools
---> Fetching distfiles for cdrtools ---> Attempting to fetch 2023-09-28.tar.gz from https://codeberg.org/schilytools/schilytools/archive ---> Verifying checksums for cdrtools Error: Checksum (rmd160) mismatch for 2023-09-28.tar.gz Error: Checksum (sha256) mismatch for 2023-09-28.tar.gz Error: Checksum (size) mismatch for 2023-09-28.tar.gz Error: Failed to checksum cdrtools: Unable to verify file checksums Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_cdrtools/cdrtools/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port cdrtools failed
thanks alot.
Attachments (4)
Change History (28)
Changed 9 months ago by mrkapqa
Attachment: | cdrtools.log added |
---|
comment:1 Changed 9 months ago by jmroot (Joshua Root)
Keywords: | cdrtools mkisofs removed |
---|---|
Owner: | set to RobK88 |
Port: | cdrtools added |
Status: | new → assigned |
Summary: | (cdrtools) checksum mismatch for cdrtools → cdrtools @3.02-2023-09-28_1 checksum mismatch |
comment:2 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign catap added |
---|---|
Port: | star smake cl-nodgui added |
Summary: | cdrtools @3.02-2023-09-28_1 checksum mismatch → codeberg projects (star smake cl-nodgui cdrtools): checksum mismatch |
comment:3 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)
I am not sure why soundtouch, mz-cmaketools, newsraft, and snac appear to be unaffected.
We probably have to contact codeberg to find out what's going on.
Looks like others already did so. Here is the upstream issue:
https://codeberg.org/Codeberg/Community/issues/1366
according to which:
- archives downloaded before November 12th 2023 (the date we deployed the new Git version which introduced the problem): They have the same checksum as today
- archives downloaded between November 12th 2023 and Jan 12 2024: The checksums might have changed between the initial download and today, because of the initial problem and our attempt to fix it; archives from older commits downloaded during this time might also have changed checksums. But they should be back to the initial checksums now.
- archives downloaded after Jan 12 2024: Our patch has made checksums deterministic depending on the date of the commit.
% for url in $(port distfiles star soundtouch mz-cmaketools smake cl-nodgui newsraft snac cdrtools | grep 'https://distfiles\.macports\.org'); do echo $url; curl -sI $url | grep -i ^last-modified; done https://distfiles.macports.org/star/2023-09-28.tar.gz last-modified: Mon, 13 Nov 2023 20:17:55 GMT https://distfiles.macports.org/soundtouch/2.3.2.tar.gz last-modified: Sun, 21 May 2023 10:54:01 GMT https://distfiles.macports.org/mz-cmaketools/c3852c301586c53fed76d9201b8cb62377597650.tar.gz last-modified: Sat, 23 Dec 2023 16:02:03 GMT https://distfiles.macports.org/smake/2023-09-28.tar.gz last-modified: Mon, 13 Nov 2023 19:43:34 GMT https://distfiles.macports.org/nodgui/96af1af4a0205ea6f7f0af8b6d9da5f180b39d2a.tar.gz last-modified: Tue, 19 Dec 2023 19:54:41 GMT https://distfiles.macports.org/newsraft/newsraft-0.23.tar.gz last-modified: Fri, 02 Feb 2024 15:42:07 GMT https://distfiles.macports.org/snac2/2.47.tar.gz last-modified: Mon, 12 Feb 2024 23:01:13 GMT https://distfiles.macports.org/cdrtools/2023-09-28.tar.gz last-modified: Mon, 13 Nov 2023 17:14:46 GMT %
The first bullet point explains why soundtouch is unaffected: we fetched it before November 12 2023.
The third bullet point explains why newsraft and snac2 are unaffected: we fetched them after January 12 2024.
The second bullet point must be the explanation for why star, smake, cl-nodgui, and cdrtools are affected and mz-cmaketools is not: we fetched them between November 12 2023 and January 12 2024.
So we need to fix star, smake, cl-nodgui, and cdrtools either by updating them to new versions or by following the stealth update recipe.
comment:4 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)
It's the same issue that GitHub had in early 2023 which affected us at the time as well.
comment:5 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)
Robert, Kirill, what's the plan? Do these four ports need updates, or do we handle it as a stealth update, or do we ignore the stealth update by setting master_sites macports_distfiles
?
comment:6 Changed 7 months ago by TonyCrawford
Bump!
Simple user here, five weeks down the road, trying to get cdrtools.
---> Verifying checksums for cdrtools Error: Checksum (rmd160) mismatch for 2023-09-28.tar.gz Error: Checksum (sha256) mismatch for 2023-09-28.tar.gz Error: Checksum (size) mismatch for 2023-09-28.tar.gz Error: Failed to checksum cdrtools: Unable to verify file checksums
comment:7 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | TonyCrawford added |
---|
Until this is solved, you can work around the problem by downloading the right file from e.g. https://distfiles.macports.org/cdrtools/ and putting it where MacPorts expects it to be.
comment:8 Changed 7 months ago by RobK88
In the next few days, I will fix the ports.
@Ryan - I do not think it will make any difference which way we go. But I prefer the stealth update approach.
comment:9 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
The stealth update recipe is intended for the situation where upstream has re-released a tarball containing new contents, and we have determined that those changes are good and we would like to mirror those new files and push those changes out to users.
In this case, the tarball has changed, but only due to infrastructure changes at codeberg. The contents of the archives have not changed so there is no value in mirroring the new files and pushing the (nonexistent) changes out to users.
For each of the affected ports, if there is a new version or commit available that we want to update to, we should update as usual. If there is no new version or commit that we want to update to, setting master_sites macports_distfiles
is the most straightforward way to prevent users from getting the new files that have the mismatching checksums.
comment:10 Changed 7 months ago by RobK88
@ryandesign -- No problem. I will use master_sites macports_distfiles
in the portfile instead. I plan to work on it this weekend.
comment:11 Changed 7 months ago by RobK88
@ryandesign - I did not need to use master_sites macports_distfiles
afterall since there was an update to the source for smake
, star
, and cdrtools
.
I have submitted Pull Requests (PRs):
smake: https://github.com/macports/macports-ports/pull/23652
star: https://github.com/macports/macports-ports/pull/23653
cdrtools: https://github.com/macports/macports-ports/pull/23654
smake
passed all the tests.
star
and cdrtools
passed all the tests except for macOS-14.
It looks like the dependencies for star
and cdrtools
are not properly installed on macOS-14. I do not have a Mac running macOS-14. I would appreciate it if someone could try to build star
and cdrtools
on a Mac running macOS-14 and let me know what they see.
I also tried to update cl-nodgui
since new updates from the developer are available. But I could not build the most recent version of cl-nodgui
. I see thse errors:
40: (SB-IMPL::TOPLEVEL-INIT) 41: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP)) 42: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP)) 43: (SB-IMPL::%START-LISP) unhandled condition in --disable-debugger mode, quitting Command failed: /opt/local/bin/sbcl --no-sysinit --no-userinit --non-interactive --eval '(require "asdf")' --eval '(setf asdf:*central-registry* (list* (quote *default-pathname-defaults*) #p"/opt/local/var/macports/build/_Users_grinch_Development_MacPorts_local-repo_ports_lisp_cl-nodgui/cl-nodgui/work/build/system/" #p"/opt/local/share/common-lisp/system/" asdf:*central-registry*))' --eval '(asdf:operate (quote asdf:build-op) (quote nodgui))' 2>&1 Exit code: 1 Error: Failed to build cl-nodgui: asdf:build-op cannot be executed Error: See /opt/local/var/macports/logs/_Users_grinch_Development_MacPorts_local-repo_ports_lisp_cl-nodgui/cl-nodgui/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port cl-nodgui failed
I am not a LISP programmer so I cannot easily fix cl-nodgui
. I suspect there is a missing dependency.
@catap -- any ideas?
comment:12 Changed 7 months ago by catap (Kirill A. Korinsky)
RobK88, if you scroll up to the actual issue, I may say something. Right now the error is truncated and here only the tail.
comment:13 Changed 7 months ago by RobK88
Cc: | RobK88 added |
---|
comment:16 Changed 7 months ago by catap (Kirill A. Korinsky)
1773 :info:build Unhandled ASDF/FIND-COMPONENT:MISSING-DEPENDENCY in thread #<SB-THREAD:THREAD "main thread" RUNNING 1772 :info:build {1001AC80A3}>: 1773 :info:build Component :ZPNG not found, required by #<SYSTEM "nodgui"> 1774 :info:build Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1001AC80A3}> 1775 :info:build 0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK Component :ZPNG not found, required by #<SYSTEM "nodgui"> #<unused argument> :QUIT T) 1776 :info:build 1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* Component :ZPNG not found, required by #<SYSTEM "nodgui">)
You need to add cl-zpng into dependencies
comment:17 Changed 7 months ago by RobK88
comment:18 Changed 7 months ago by RobK88
@catap - Thanks for identifying the missing dependency. I added it. But the build still fails. See attached main.log
It looks like we are missing the sdl2
component. So I tried adding cl-sdl2
as a dependency but cl-sdl2
does not exist.
Any ideas?
Changed 7 months ago by RobK88
Attachment: | main.2.log added |
---|
Second attempt to build cl-nodgui after adding cl-zpng
comment:20 Changed 7 months ago by RobK88
@catap - Thanks. Well I am not a LISP programmer. :-(
I hope someone can create cl-sdl2
port. Alternatively, we can use an earlier version of cl-nodgui
that does not use sdl2
.
comment:21 Changed 7 months ago by RobK88
FYI -- @ryandesign pointed out that it looks like Apple forgot to add yacc
in CLT 15.3 used in macOS-14. So I added bison
as a build dependency for star
and cdrtools
. Now star
and cdtools
are building fine on macOS -14 (as well as on macOS 11 to macOS-13) according to the buildbots.
star
and cdrtools
are ready to be merged.
comment:22 Changed 7 months ago by RobK88
comment:23 Changed 7 months ago by RobK88
comment:24 Changed 7 months ago by RobK88
I see that there is a common LISP library for sdl2
called cl-sdl2
.
See https://github.com/lispgames/cl-sdl2
When I have time in a couple of weeks, I will create a port for it and then add it as a dependency to cl-nodgui
If someone wants to do it sooner, please go ahead!
Analyzing the file currently available from codeberg and the one we mirrored in November, the .tar.gz files differ but the .tar files inside are identical, so their contents are identical too.
gzip files can store the original filename and its timestamp which can lead to gzip files generated at different times differing despite identical contents, but that's not the case here. These .tar.gz files store no original filename or timestamp.
I recompressed the .tar file with various compression levels and discovered that the checksums of the file we mirrored in November match those produced by Apple gzip on macOS 12.7.2 when using compression level 6 (the default) while the checksums of the file available from codeberg now match those produced by GNU gzip when using compression level 6. So I suspect that sometime between November and now, codeberg changed their servers from using BSD gzip to using GNU gzip. This could affect every port that uses automatically-generated tarballs from codeberg. Checking…
I am not sure why soundtouch, mz-cmaketools, newsraft, and snac appear to be unaffected. I hope it is not the case that some of codeberg's servers use GNU gzip and others use BSD gzip and that they are part of a single server pool. If that's what's happening, then we don't know which file we'll get when we fetch which would make codeberg an unsuitable choice for master_sites. We probably have to contact codeberg to find out what's going on.