What are the recommended ways to build an RPM package from source using autochangelog?

Occasionally, I need to build an RPM package from Fedora’s source repository, incorporating some of my local changes. I noticed that some RPM spec files include the %autochangelog macro, which generates a changelog from the git history. There’s also the %autorelease macro, which seems related.

What are the recommended steps for building a package with autochangelog? My usual process for building a package is as follows:

  1. To download the sources:
    $ spectool -g -R --define "_sourcedir $(pwd)" ./*.spec
    
  2. Optionally, I apply patches and modify the Release tag in the spec file.
  3. To create an SRPM:
    $ rpmbuild -bs --define "_sourcedir $(pwd)" --define "_srcrpmdir $(pwd)" ./*.spec
    
    After that, I can build the SRPM using either mock or rpmbuild.

It seems like the command $ rpmautospec generate-changelog can generate a changelog from the git history, but I’m unsure how to incorporate it into the steps above. How can I make this be properly integrated into the existing workflow?

1 Like

Did you find the Fedora Magazine article about it?: Use rpmautospec in Fedora Linux - Fedora Magazine

1 Like

I think I’m understanding how %autochangelog and %autorelease work. (These macros are replaced with the actual changelog and release number generated from the git history, respectively.) The question is how end-users, who want to build RPMs from source where the spec files include %autochangelog and %autorelease, can do this. Unfortunately, the links you mentioned don’t address this issue.

@zbyszek frequents this forum, and since he wrote that article, hopefully he won’t mind if I ping him for an answer to this question. :slightly_smiling_face:

Otherwise, there is a package-maintainers tag (or packages) that you might try adding to your original post to get the attention of some more knowledgeable people. I suspect the rpm tag might be more for questions about using the rpm command line tool.

(Maybe we need some documentation somewhere about how all these tags are expected to be used. It’s not always obvious.)

Thanks for pinging him who is an expert on this topic!
By the way, running export SOURCE_DATE_EPOCH=0 in the shell before executing rpmbuild is the solution (or workaround) for the issue, but honestly, I don’t know why it works.

Packages with %autorelease and %autochangelog generally are intended to be always used with the dist-git repo. My recommendation is to not bother with manual invocations of rpmbuild.

If you are in the dist-git repo:
fedpkg srpm → srpm
fedpkg local → native build
fedpkg build → mock build

--release fxx or --release rawhide can be added if fedpkg is confused about the branch.

4 Likes

It seems like fedpkg srpm handles various tasks, such as downloading source files, setting the appropriate SOURCE_DATE_EPOCH, and creating the SRPM. Thanks for sharing the information.

For those who modify the spec file for local changes and want to adjust the Release tag to differentiate their own version from Fedora’s, %autorelease offers several options to control versioning. The official documentation is available here:

https://docs.pagure.org/fedora-infra.rpmautospec/autorelease.html#traditional-versioning-with-part-of-the-upstream-version-information-in-the-release-field

I also found that the -b option is supported in the %autorelease macro. For example, when rebuilding a package where the Release is calculated as 1, I can use %autorelease -b 0 -e my to make the release 1.my. However, further investigation is needed to fully understand the purpose of the -b option.

As an additional hint: You can fedpkg clone -a PACKAGENAME a package anonymously (without being a packager) which gives you a dist-git checkout with all the info. I would recommend fedpkg mockbuild to build from there (after switching to the branch you want to build for) because that installs build dependencies in a mock chroot automatically: Your system installation remains unchanged, and you don’t have to take care of anything (neither dependencies nor source downloads).
If you apply changes to the spec and commit them (using git), rpmautospec will bump the package release automatically. (You know about the disttag already, good!)