Using the %autochangelog Macro

rpmautospec combines two sources of information to generate a changelog which is inserted in the spec file where the %autochangelog macro is set.

These two sources of information are:

  • An optional changelog file in the dist-git repository of the package. If this file is present, it is included as is in the spec file. It should be formatted according to the rules required for the changelog text, but without the escaping of rpm macros that would be needed if it was part of the spec file.

  • The git history of the package between the most recent commit touching changelog and the latest commit made to the package.

Changelog entries generated from commit messages

In the simplest case, the commit summary (the first line) becomes the changelog entry. rpmautospec will automatically add the line with information about authorship and date based on the commit authorship and timestamp. It will also add appropriate indentation and the dash (“-“), so those should not be included in the commit summary.

Commit message:

Update to version 2.3.4 (rhbz#666)

This also fixes build issues on arm64.

… results in the following changelog entry:

* Mon Nov 25 2019 Foo Bar <foo@bar.com> 2.3.4-1
- Update to version 2.3.4 (rhbz#666)

It is possible to generate a longer changelog entry. If the first line of the commit message body starts with an ellipsis (three dots “…” or the equivalent Unicode character “…”), the subsequent text will be appended to the first item of a changelog entry. Dashed list items following the first item (without blank lines in between) will be added as separate (dashed) changelog entries:

Update to version 2.3.5

... (rhbz#667, rhbz#123, and a few other nasty bugs)
- Fixes build issues on s390 (rhbz#668)

(Text without a dash is ignored.)

… results in the following changelog entry:

* Mon Nov 26 2019 Foo Bar <foo@bar.com> 2.3.5-1
- Update to version 2.3.5 (rhbz#667, rhbz#123, and a few other nasty bugs)
- Fixes build issues on s390 (rhbz#668)

Note

These examples use “rhbz#nnn” to refer to RedHat Bugzilla bug number nnn. This convention is understood by bodhi, which may automatically associate an update with this build with that bug and e.g. close the bug when the update goes to stable.

If you don’t want bodhi to add the bug to the update, a different syntax must be used, e.g. “rhbz #nnn” (note the space between “rhbz” and “#”).

Skipping changelog entries

A commit will result in no changelog entry if it contains:

[skip changelog]

as a separate line. This is useful in those cases where the commit is not interesting for the user, for example because it does cleanup or fixes an error in a previous commit or a build failure, and when reverting commits.

Note that release suffix produced by the %autorelease macro is still bumped for such commits.

Examples

Only Commits

If a package has no changelog file, rpmautospec will only use the git history to generate the changelog.

Thus if the history looks like:

F:  Update to 2.3.4
|
E:  Fix build on arm64
|
|   Fixes bug introduced in previous commit.
|   [skip changelog]
|
D:  Fix building on armv7 with gcc10
|
|   ... (required for the mass rebuild).
|
C:  Update to 1.5
|
B:  Update to 1.0
|
A:  Initial import

The automatically generated changelog will look like:

* Wed Jul 25 2018 Foo Bar <foo@bar.com> - 2.3.4-1
- Update to 2.3.4

* Thu Feb 06 2020 John Doe <john@doe.com> - 1.5-2
- Fix building for armv7 with gcc10 (required for the mass rebuild)

* Thu Feb 06 2020 Foo Bar <foo@bar.com> - 1.5-1
- Update to 1.5

* Sat Jul 14 2018 Jane Smith <jane@smith.com> - 1.0-1
- Update to 1.0

* Mon Jun 18 2018 Jane Smith <jane@smith.com> - 0.9-1
- Initial import

Commits and Changelog

If a package has a changelog file, rpmautospec will only generate entries from the commits after its last change and then append its contents verbatim.

So if the changelog file looks like:

* Mon Nov 25 2019 Foo Bar <foo@bar.com> 2.3.5-1
- Update to 2.3.5

* Wed Jul 25 2018 Foo Bar <foo@bar.com> 2.3.4-1
- Fix building for armv7 with gcc10 (required for the mass rebuild)

* Thu Feb 06 2020 John Doe <john@doe.com> - 1.5-2
- Fix building for armv7 with gcc10

* Thu Feb 06 2020 Foo Bar <foo@bar.com> - 1.5-1
- Update to 1.5

* Sat Jul 14 2018 Jane Smith <jane@smith.com> - 1.0-1
- Update to 1.0

* Mon Jun 18 2018 Jane Smith <jane@smith.com> - 0.9-1
- Initial import

(Note the lack - between the email and version-release in the entries from “Foo Bar”.)

And the history looks like:

K:  Fix build on s390x
|
|   [skip changelog]
|
J:  Update to 2.4
|
I:  Fix typo in the changelog file
|
H:  Fix typo in patch001
|
G:  Move changelog to ``changelog`` and fix typo
|
F:  Update to 2.3.5
|
E:  Update to 2.3.4
|
D:  Fix building on armv7 with gcc10
|
C:  Update to 1.5
|
B:  Update to 1.0
|
A:  Initial import

The automatically generated changelog will look like:

* Mon Mar 02 2020 Jane Smith <jane@smith.com> - 2.4-1
- Update to 2.4

* Mon Nov 25 2019 Foo Bar <foo@bar.com> 2.3.5-1
- Update to 2.3.5

* Wed Jul 25 2018 Foo Bar <foo@bar.com> 2.3.4-1
- Update to 2.3.4

* Thu Feb 06 2020 John Doe <john@doe.com> - 1.5-2
- Fix building for armv7 with gcc10 (required for the mass rebuild)

* Thu Feb 06 2020 Foo Bar <foo@bar.com> - 1.5-1
- Update to 1.5

* Sat Jul 14 2018 Jane Smith <jane@smith.com> - 1.0-1
- Update to 1.0

* Mon Jun 18 2018 Jane Smith <jane@smith.com> - 0.9-1
- Initial import

As you can see, the two entries from Foo Bar are still missing their - between the email and the version-release which is expected since the content of the changelog file is included as is.

In addition, we can see that the commits G, H and I are not shown in the generated changelog since they were made before the most recent commit changing the changelog file, and K is skipped because of the [skip changelog] annotation.

Note

At any time, rpmautospec generate-changelog can be used to preview how the generated changelog will look.