Support fetching sources from spec + sources file to build SRPM

[qsuscs]

Currently, COPR supports three methods to build an SRPM from SCM sources: rpkg¹, tito (and tito test), and make srpm. For a repository built like the Fedora standard (spec file with URLs in the SourceN fields, sources file with checksums), there is no direct way to let COPR handle the SRPM.

While rpkg supports getting the source files and building SRPMs, it can only fetch from DistGit, not upstream. COPR uses DistGit internally, and this works for subsequent builds, but users do not seem to have write access there and thus cannot use e. g. fedpkg new-sources.

I still have not understood if tito is suitable for packaging an “external project”, i. e., the maintainer of the RPM and upstream are different entities and the packaging repository is distinct. But again, not COPR’s fault.

This leaves make srpm. I have done this in the past, with the Makefile below as .copr/Makefile, invoking spectool manually to download the sources, sha512sum to verify them, and rpmbuild to build the SRPM. For something I would consider a standard and trivial case, this is needlessly complicated.

I do not (yet) maintain any package in Fedora itself, so I do not know the process there exactly, but from the documentation, it seems like COPR works differently in this aspect. This is annoying and confusing, especially when one is planning to submit a package to Fedora eventually and uses COPR as a sort of test environment.

TL;DR: Please add support to automatically fetch source tarballs and build SRPMs from spec files with SourceN: https://… lines and sources files with checksums (like in Fedora package Git repositories) and/or allow backend DistGit access to the user.

---

spec ?= btop.spec
outdir ?= $(CURDIR)
sourcedir = $(shell rpmbuild -E '%_sourcedir')

srpm:
	dnf -y install rpmdevtools
	spectool -R -g $(spec)
	env -C $(sourcedir) \
		sha512sum -c $(CURDIR)/sources || \
		(find $(sourcedir) -type f -delete; exit 1)
	rpmbuild -D "_srcrpmdir $(outdir)" -bs $(spec)

Footnotes

1. Wrong place to complain about this, but it was and is really confusing for me that rpkg ≠ rpkg-util, that COPR uses the latter (I guess?) but calls it rpkg, and that it is “no longer developed” as per https://pagure.io/rpkg-util. ↩

[FrostyX]

TL;DR: Please add support to automatically fetch source tarballs and build SRPMs from spec files with SourceN: https://… lines and sources files with checksums (like in Fedora package Git repositories) and/or allow backend DistGit access to the user.

@qsuscs If I understand correctly, there may be a simple workaround. Submitting a build via URL allows not only linking SRPM also a specfile. When all Sources are URLs, then they are automatically downloaded.

Can you maybe use the RAW URL for your spec file in your github/gitlab/pagure repository?

[FrostyX]

I got an email notification from GitHub about @azrdev replying to this conversation but no comment here. I don't understand why.

When all Sources are URLs, then they are automatically downloaded.
Can you maybe use the RAW URL for your spec file in your github/gitlab/pagure repository?

@azrdev - That would require putting URLs as Source:, correct? sounds inelegant to me, but might work

I think you are correct. To be sure, let me give an example. Something like:

Source: https://github.com/haikarainen/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz

or

Source: %{URL}/archive/v%{version}/%{name}-%{version}.tar.gz

For example, here is one of my packages:
https://src.fedoraproject.org/rpms/light/raw/rawhide/f/light.spec
I can use URL for this specfile, submit it to Copr, and it will build successfully. No SRPM is needed.

sounds inelegant to me

AFAIK it is a standard practise to include the full URL
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/

[azrdev]

I got an email notification from GitHub about @azrdev replying to this conversation but no comment here. I don't understand why.

I think I removed my comment when I noticed the original issue already answered the question with the line

spec file with URLs in the SourceN fields

AFAIK it is a standard practise to include the full URL

I agree with you concerning upstream sources, but I was thinking about patches or other files included with the spec file, not upstream.