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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Needs triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions