On Wed, Aug 03, 2022 at 11:21:40PM +0000, RVP wrote: > Obviously, (most of) the checksums fail: > > $ printf '%s\n' *.xz | fgrep -f- SHA512 | sha1 -c > (SHA512) base.tar.xz: FAILED
I can reproduce this and will file an admin ticket. A good way to get more information is to use curl like this: curl -H "Fastly-Debug:1" -D /tmp/headers --output base.tar.xz https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/amd64/binary/sets/base.tar.xz and then check /tmp/headers for more detailed informations. Background: a CDN works like a multi level key/value cache, where the URL is the key. The "latest" directory in the build outputs is a symlink to the last full build for that branch (so whenever the build cluster completes uploading a build with 0 failures, see https://releng.netbsd.org/cgi-bin/builds.cgi, the "latest" symlink is switched over to that new build. This means: all URLs below that link are now stale, so the CDN is informed about this (and supposed to react with cache misses on next access to that URLs). Something there isn't working as designed. > See also this (possibly relevant) thread: > > https://mail-index.netbsd.org/netbsd-users/2022/07/31/msg028770.html I don't think this is related, it sounds like a plain fastly operations issue. Martin
