Skip to content

dist-git: Regression causing persistent checksum mismatches on source downloads from lookaside cache #4129

@pgnd

Description

@pgnd

all my online COPR builds of submitted, locally-built SRPMS today are failing at checksums:

"ERROR: Check-sum xxx...xxx is wrong, expected: yyy...yyy"

local "reproduce this build" copr-rpmbuilds, locally, are also failing with same error.

local mock builds are OK -- no error, no build issues

all @copr builds of the same spec/srpms ~ 1-2 weeks ago were just fine.

seems something's changed in checksumming?

here's an example FAILed build log:

https://download.copr.fedorainfracloud.org/results/pgfed/virtnbdbackup-TEST/fedora-43-x86_64/10033252-virtnbdbackup/builder-live.log.gz

noting,

...
Running: dist-git-client sources

cmd: ['dist-git-client', 'sources']
cwd: /var/lib/copr-rpmbuild/workspace/workdir-qh0oal4u/virtnbdbackup
rc: 1
stdout:
stderr: INFO: Reading stdout from command: git rev-parse --abbrev-ref HEAD
INFO: Reading stdout from command: git rev-parse HEAD
INFO: Reading sources specification file: sources
INFO: Downloading c26ece66c915643602eed6f4b048a6546a5f8e75
INFO: Reading stdout from command: curl --help all
INFO: Calling: curl -H Pragma: -o c26ece66c915643602eed6f4b048a6546a5f8e75 --location --connect-timeout 60 --retry 3 --retry-delay 10 --remote-time --show-error --fail --retry-all-errors https://copr-dist-git.fedorainfracloud.org/repo/pkgs/pgfed/virtnbdbackup-TEST/virtnbdbackup/c26ece66c915643602eed6f4b048a6546a5f8e75/md5/a2a80ee1b303868aafe9499663667d44/c26ece66c915643602eed6f4b048a6546a5f8e75
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 3770k    0 3770k    0     0  50.6M      0 --:--:-- --:--:-- --:--:-- 51.1M
INFO: Reading stdout from command: md5sum c26ece66c915643602eed6f4b048a6546a5f8e75
ERROR: Check-sum 74653a51164ea731728207383a7c298a is wrong, expected: a2a80ee1b303868aafe9499663667d44
...

this issue occurs/persists with a new repo/build.

each new submitted build spec gets a unique timestamp -- so SRPMS' content has new/unique checksum; shouldn't be a simple client-side or stale cache issue

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions