Hey everybody,
we've recently deployed the changes needed to enable automatic RPM
release numbers and changelogs to Koji in staging, and now we want you
to throw things at it!
Detailed information is below, but the gist is: it looks like this will
be real sometime soon. This is the time to ensure we folks working on
it over the past weeks haven't left in any glaring errors.
We look forward to hearing from you!
Cheers,
Nils
---
Background--
In 2020, a prototype of rpmautospec was developed as feature for the
Koji build system to relieve Fedora contributors from manually
maintaining the release field and changelog of RPM packages. The
results were presented at Nest in August and were met with a positive
response.
FESCo accepted this feature to be implemented with changes to the
underlying release enumeration logic for the Fedora 35 release, and
subsequently a CPE team resumed work on the project in April 2021 to
bring the revised proposal to fruition. After about 6 weeks of
development, the team are pleased to announce that a first version of
rpmautospec based on the new logic is ready to be tested in staging.
Changed requirements in comparison to the prototype
---
FESCO asked the team to implement a simplified release enumeration
algorithm. It basically just considers the number of commits since the
last time the version was changed and avoids storing information about
historical builds in git tags.
What it does at this stage of development
-
* When building packages in Koji/staging, the release field and
changelog are maintained automatically from the commits and their
log entries (more specifically, their subject lines) in the git
repository. The contents of a changelog file, if present in the
repository, will override any older commit log information, to allow
correcting/amending changelog entries after the fact.
* For the release field, flags for pre-release versions,
snapshot/extra version information and release number offset exist
and are honoured. This isn’t yet implemented for changelog entries,
though, i.e. generated changelog entries will have the plain release
number in their header even for pre-release or snapshot versions.
* The new git history traversal code follows forks in order to support
merging branches. For changelog generation, this means it follows a
parent with the same tree to support git merge -s ours. Unresolvable
merges (with content from disparate branches) won’t fail a build,
but this problem will be flagged in the changelog (as the oldest
entry).
* An API function is provided allowing 3rd party users like fedpkg,
rpmdev-bumpspec to check if rpmautospec features are used and adapt
to it where necessary. Pull requests to use this have been submitted
to rpmdev-bumpspec and fedpkg/rpkg.
What’s yet to come
--
* Reflect flags to %autorelease in generated changelog entries.
* Have `fedpkg local`, `fedpkg mockbuild` (possibly `fedpkg srpm`)
support rpmautospec features, i.e. prepare the SRPM on the fly as
Koji would do it before building.
* Allow for uncommitted changes in local builds with fedpkg, i.e. bump
the release number by one and generate a boilerplate “- uncommitted
changes” RPM changelog entry.
* Up-to-date and more complete documentation (real soon now).
Testing Information
---
* Source code can be found here: https://pagure.io/fedora-
infra/rpmautospec
* Installable packages are available for all supported Fedora
versions,
from 33 onwards.
* Quick Start:
- The staging environment is separate from what you use day to day,
recent
changes to your account might not have made it there. Ensure you can
log
into your Fedora account on staging, and that it is part of the
necessary
groups (e.g. packager): https://accounts.stg.fedoraproject.org
If you have issues with your staging account, please log a ticket
with
Fedora Infrastructure here: https://pagure.io/fedora-
infrastructure/new_issue
- Clone the staging repository of a package: `fedpkg-stage clone ...`
- Move the existing changelog entries beneath %changelog in the spec
file
into a file named changelog in that same directory and add that file
to
be tracked by git.
- Enable automatic release number enumeration and changelog generation
in
the spec file:
... Release: %autorelease ... %changelog %autochangelog
- Commit these changes to git, push and build:
git commit -m "Use automatic release and changelog" git push
fedpkg-stage build
- If you want to use the Koji CLI tool, point it at staging this way:
koji --profile=stg ...
* We are interested in issues concerning using rpmautospec, if you
need help
but also where its behavior is unexpected or even disruptive, such
as:
- (How) Can I do …?
- My
