So this is likely the place where it fails:

https://pagure.io/zuul-distro-jobs/blob/master/f/roles/rpm-lint/tasks/main.yaml#_17-21

But where the {{ srpm }} variable comes from? It seems to contain the URL twice for some reason? Here it actually appears the URLs are already listed twice:

2024-07-10 10:20:19.095587 | TASK [rpm-artifact-url : Get srpm url]
2024-07-10 10:20:33.876145 | container | https://fedora.softwarefactory-project.io/logs/78/178/ca13a515893b6810288c9b589d6abb26438f757d/check/rpm-scratch-build/92208c7/repo/ruby-3.3.4-11.fc41.src.rpm
2024-07-10 10:20:33.912175 | container | https://fedora.softwarefactory-project.io/logs/78/178/ca13a515893b6810288c9b589d6abb26438f757d/check/rpm-scratch-build/92208c7/repo/ruby-3.3.4-11.fc41.src.rpm
2024-07-10 10:20:34.907596 | container | ok: Runtime: 0:00:10.241610

Can it be that yumdownloader from dnf-utils / dnf-plugins-core changed its output somehow? But what are the versions used? 🤷

I can not reproduce the problem, so I am trying to get some more info from the job in

https://src.fedoraproject.org/rpms/ruby/pull-request/179

using https://pagure.io/zuul-distro-jobs/pull-request/150

Thx. Meanwhile, I have rescheduled the Zuul job. Maybe it won't happen again 🤷

It seems that yum downloader returns duplicate lines for both rpms and srpms, we just don't see the issue with rpms because we treat the links for rpms as a list, while we expect only a single line for srpm.

I think we might have configured the custom repository with the change artifacts twice before running the test.

According to Zuul manifest, the change with the type repo is listed twice:

https://fedora.softwarefactory-project.io/zuul/build/39a0cb466c26461189a9f49e3c1ff5c2/log/zuul-info/inventory.yaml#68

Therefore it seems the repo is added twice by the next step:

https://pagure.io/zuul-distro-jobs/blob/master/f/roles/repo-setup/tasks/main.yaml

Now the question is why does it appear twice in the zuul variables..

It seems that yum downloader returns duplicate lines for both rpms and srpms

Yes, that is also my understanding. Please note that dnf-plugins-core (SRPM of the yumdownloader) was updated recently. At least more recently than https://pagure.io/zuul-distro-jobs/

According to Zuul manifest, the change with the type repo is listed twice:

https://fedora.softwarefactory-project.io/zuul/build/39a0cb466c26461189a9f49e3c1ff5c2/log/zuul-info/inventory.yaml#68

You have lost me here :D But I probably don't need to understand ...

Right, I mean when we add the repo in repo-setup role we do a for-loop through the zuul.artifacts list:

{% for artifact in zuul.artifacts|default([]) %}{% if artifact.name == 'repo' %} ...

And if zuul.artifacts contains duplicates, which it does, we get two duplicate repos.

Anyways, I have this hotfix https://pagure.io/zuul-distro-jobs/pull-request/151

You can add the line Depends-On: https://pagure.io/zuul-distro-jobs/pull-request/151 to your MR description to apply it. Or just wait a bit, and if it works on https://src.fedoraproject.org/rpms/ruby/pull-request/179 I'll merge it.

Or just wait a bit, and if it works on https://src.fedoraproject.org/rpms/ruby/pull-request/179 I'll merge it.

I have already merged my PR. So lets wait for yours.

I think it succeeded, in a sense that it did past the point and provided rpmlint resuts.

BTW I believe this is duplicate of #475. So now I can certainly rule out the recent update of yumdownloader

The fix proposed by @bookwar seems to workaround the duplicated lines returned by yumdownloader for both rpm-rpminspect and rpmlinter job.

both jobs run on a f38 container since a while so that's surprising the command output changes. We recently updated to a more recent Zuul version so perhaps that's related. Using the same container and command I cannot reproduce either. So we need for sure to get ride of the zuul-worker-f38 container and more to f40 container.