-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote: > Le 2020-07-02 09:52, Florian Weimer a écrit : > > * Nicolas Mailhot via devel: > > > > > > How do I let rpm generate the changelog automatically? > > > > > > This feature is not changelog generation, just changelog bumping > > > on > > > build events. You still need some other method to put non-build > > > events > > > in the changelog. > > > > What is “changelog bumping”? Why is it needed? What about release > > bumping? > > Changelog bumping is the act of putting the actual release bump and > build time in the changelog. > > With the change, the spec is able to self-compute its next release if > the spec file evr is older or equal to the last build event. How does it know that "last build event"? > On build, it will both bump the release, without touching the spec > file > (that is release bumping) and commit the new build event timestamp in > the detached changelog file at %build time (that is changelog > bumping). > > > > The detached changelog is just one more file in SRPM sources, > > > which is > > > modified by rpmbuild at `%build` time with other files rpmbuild > > > modifies. The tricky part is to modify the source file as a > > > source > > > file > > > so rpmbuild adds the result to the produced SRPM (and, that does > > > not > > > work in mock right now, because mock serves the SRPM that existed > > > at > > > the start, not at the end of the build. Though it’s probably just > > > a > > > matter of getting mock to call again its SRPM creation method at > > > the > > > end of the build). > > > > > > The packager does not have to request the modification in his > > > spec, > > > it’s done as part of the various %auto_foo calls the change > > > introduced > > > > Can you list the relevant %auto macros explicitly somewhere? Is > > %autosetup included in the set of macros that trigger this > > behavior? > > %autosetup is not part of the new framework, all the new %auto entry > points have %auto_something name/ > > Auto release bumping and auto changelog bumping involve registering > some > processing in the preamble (to compute the next evr), in %sourcelist > (to > deal with the source files involved in saving state) in %build (to > commit the new data to disk once the build is ongoing) and in > %changelog > (to get rpmbuild to record the new changelog state in package > metadata) > > ie it registers processing in %auto_pkg, %auto_sources, %auto_build > and > %auto_changelog > > The bumping is done by the buildsys subsystem ie practically by > %new_package (called by %auto_pkg, directly or via %buildsys_pkg), by > %buildsys_sources (called by %auto_sources), %buildsys_build (called > by > %auto_build) and %buildsys_changelog (called by %auto_changelog). > > It’s done by the buildsys subsystem because the %buildsys subsystem > is > tasked with writing the SRPM header in the new %auto_call framework, > so > only it knows which of the various (sub)package epochs and versions > are > the ones that apply to the SRPM. > > This may seem a bit complex and convoluted, but that’s because > autobumping > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > is a small addition over the big %auto_macros change. > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > And it is small because the big change provides all the low-level > infra > to code such high level features easily. > > The big change was not done for autobumping. It’s only once I coded > it > for other packaging needs that I realized it made implementing > autobumping trivial (trivial to me after all the other changes, maybe > not so trivial for the average macro reviewer). > > Regards, > > -- > Nicolas Mailhot > _______________________________________________ > packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to > packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx - -- Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl79pwsACgkQEV1auJxc Hh5oixAAlyinJfmNKCVQcx/Kh11xb+MwW9UzGynhW1cTUAe1D8vslH0jtEJjJRRm nXMtIyNoj0ny5Uo+ddABdQ3V86qqh/U46K5XK2FbGPq9a0hmI254KgJDLt4hqtaT Dqw7+LK2jwbb63WBacsxJG6dGhvS9cOGxoxo+jMQ3uocLN1RrbTI/Du64i8d3Enk Jmu3v0YKm3V+VyRtal2O+BGphzANS0D0rodHMH/8zmcT50Mt41QMFl+16PPDBcsn qgyy/3tmruPmxUDCO5xFzJlA50qT5AMSWy8pOKqFdr+5hUaYW6rPkvXoC7uun08V FnW/XGVHHv7iwz2CUCqoLwzb6wlyKzOyjxh3RGTIt+FXz1AfQ2tZWSbSvlElBce9 eRMb+v5yoURHMYK4Iazy9HMZa2mp7lcXFWE7qkTxwVwClkQ1YuaCEeSIVpblFuFw l8w47QzcyGPwIi6GMqJyp5dpqLD15JetVIXQfF8/V5OCWMHNgqbbaef5Q9JNnc9K PQ31VyhsAc+/PGkX5vNM31GIFvJSS3BmJ8IXNxO4V+eTdESJVOQGHqsq8/UI35AC s5XDxb+AXUn5q2rREV7+EimE5CxV8ouRKMG+gJJ809KqwIr6jtML1zcQpO2ZkPNo e8MEPw0G5izmY1Cp5qQ8/WfRf8cDtRfsuxXU9Zm53AEGVLY9mGg= =DXfR -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
