Hi Nicolas, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> writes: >> 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. > > 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). So essentially you store the changelog in a separate file (like it is done in openSUSE) and use that to calculate the next release field? Given the other replies to this thread (that this is all local only, unless koji does git commits), does that mean that it's still: dist-git commit = rebuild. The "only" difference to the current state of affairs being, that I don't have to specify the Release field myself? > > 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 Could you provide an example how this would look in practice? > >> And is this related to Piere/Pingou's work on the same topic that was >> deployed to koji staging? > > It’s a different implementation, at the rpm level, that does not tie > bumping to Fedora infra (koji included). Though, it is probably > complementary to what pingou did on the changelog alimentation front. > > IMHO the design mistake so far was to conflate bumping and non-build > event changelog filling. You need to do both of course but build event > should be a build event driven by the lowest common denominator > (rpmbuild) with koji/infra scrapping rpmbuild results as usual and > exposing them to users. This is a good point imho: not every rebuild warrants a changelog entry and having both separated appears sensible to me. What I am currently missing from this proposal though is: - How is this actually even implemented? - How will this look in practice? - Given that additional files would be put into dist-git, how do we roll this back in case things go wrong? (Having thousands of "remove %autorelease" commits by releng could be an option here, albeit not a pretty one). Cheers, Dan _______________________________________________ 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
