Created attachment 1829211 [details] Parse spec PatchNN: as a source type directive when enumerating the package source file names Description of problem: spec file parser do not consider patches as sources, which breaks the workflow if a patch is added as a source in fedpkg Version-Release number of selected component (if applicable): python3-rpkg-1.63-2.fc34.noarch How reproducible: Always Steps to Reproduce: 1. fedpkg clone xsane 2. fedpkg prep 3. Actual results: Fails due do one of the source files not downloaded. Expected results: Should pick up all source or patch files in the spec as potential source files, and download any untracked file not already downloaded. Additional info: Changing the spec parsing regex to include patch as a source type directive solves this
Thank you for the report. I am sorry for the trouble, the specfile parser is written by me, and this is not even the first regression caused by it. I did not realize that also patch files can be uploaded to the lookaside cache. Since you have already found a cure for this, I will create a pull request for rpkg right away.
The fix: https://pagure.io/rpkg/pull-request/581 Running the Python 3.10 test suite had many failures, but could be made to pass by just editing tox.ini. I assume this is a test configuration issue rather than something wrong with the fix, so logged it as a separate issue: https://pagure.io/rpkg/issue/582
FEDORA-2022-fdc9661b8e has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fdc9661b8e
FEDORA-2022-fdc9661b8e has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-c17a63bb83 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c17a63bb83
FEDORA-2022-c17a63bb83 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.