https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
== Owner == * Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec| The spec file contains: <pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre> Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }}
Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section.
== Benefit to Fedora == Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates * packagers describe changes just once in the git commit message, the `%changelog` entry is autogenerated * patches to the spec file can be cherry-picked between branches without trivial conflicts * pull requests on src.fedoraproject.org can be merged without trivial conflicts * in workflows that regenerate the spec file (rust2rpm, pip2rpm, …) `%changelog` section doesn't need to be copied over
== Scope == * Proposal owners: ** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... 0.3.1 was released on November 17th, and should be deployed to production in about two weeks])
* Other developers: ** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?)
* Somebody (TBD): ** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented.
* Related work ** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated ** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning ** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_...
* Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A
== Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway.
== How To Test == * Convert an existing package: `rpmautospec convert`. Ideally this step is done right before a version bump so that the release numbers restart at `-1`. * Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`). * Do builds in koji. Verify correctness of version-release and the changelog.
* For new packages, use `%autorelease`+`%autochangelog`. Repeat all the tests listed above.
* Assume you are a newbie packager. Read the packaging docs and check that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly.
== User Experience == No changes visible to end users.
== Dependencies == None.
== Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation.
* Contingency mechanism: Revert changes to documentation by reverting the appropriate commits. This can be done easily by FPC. * Contingency deadline: Any time. * Blocks release? No.
== Documentation == This page and any changes to Packaging Guidelines and other documents.
== Release Notes == Not needed.
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
== Owner ==
- Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
- Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec| The spec file contains:
<pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre>
Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }}
Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.)
== Feedback ==
- Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section.
== Benefit to Fedora == Various packaging workflows become smoother for packagers and contributors:
- packagers don't need to touch the `Release` field on updates
- packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
- patches to the spec file can be cherry-picked between branches
without trivial conflicts
- pull requests on src.fedoraproject.org can be merged without trivial conflicts
- in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
- Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... 0.3.1 was released on November 17th, and should be deployed to production in about two weeks])
- Other developers:
** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?)
- Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented.
- Related work
** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning ** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_...
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway.
== How To Test ==
- Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers restart at `-1`.
- Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`).
Do builds in koji. Verify correctness of version-release and the changelog.
For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
- Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly.
== User Experience == No changes visible to end users.
== Dependencies == None.
== Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation.
- Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
- Contingency deadline: Any time.
- Blocks release? No.
== Documentation == This page and any changes to Packaging Guidelines and other documents.
== Release Notes == Not needed.
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Dec 30, 2022 at 08:46:46PM -0000, Leigh Scott wrote:
-1 for this change. I will ignore it if it's accepted.
That's OK, the idea is to make this opt-in. Without any specific concerns, that's all I can say.
Zbyszek
On Fri, Dec 30, 2022 at 9:50 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 08:46:46PM -0000, Leigh Scott wrote:
-1 for this change. I will ignore it if it's accepted.
That's OK, the idea is to make this opt-in.
So if the change is opt-in how is this an actual change to the process we already have?
On Sat, Dec 31, 2022 at 12:49:57AM +0000, Peter Robinson wrote:
On Fri, Dec 30, 2022 at 9:50 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 08:46:46PM -0000, Leigh Scott wrote:
-1 for this change. I will ignore it if it's accepted.
That's OK, the idea is to make this opt-in.
So if the change is opt-in how is this an actual change to the process we already have?
It is a change of the recommended default approach. Not planned: automatic conversion of existing packages, removal of the old mechanism, or requirement to use the new mechanism in new packages.
Zbyszek
On Fri, Dec 30, 2022 at 4:50 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 08:46:46PM -0000, Leigh Scott wrote:
-1 for this change. I will ignore it if it's accepted.
That's OK, the idea is to make this opt-in. Without any specific concerns, that's all I can say.
This Change seems to be about flipping the defaults to make people opt-out. If it's opt-in, this Change is null, since that's the status quo.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Dec 30, 2022 at 07:56:05PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 4:50 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 08:46:46PM -0000, Leigh Scott wrote:
-1 for this change. I will ignore it if it's accepted.
That's OK, the idea is to make this opt-in. Without any specific concerns, that's all I can say.
This Change seems to be about flipping the defaults to make people opt-out. If it's opt-in, this Change is null, since that's the status quo.
I guess we can split the difference: it's opt-in for existing packages, and opt-out for new packages.
Zbyszek
On 30/12/2022 22:49, Zbigniew Jędrzejewski-Szmek wrote:
That's OK, the idea is to make this opt-in.
It is already opt-in. Some packages switched to rpmautospec when it was introduced.
I've done this too for some of my packages and due to known issues reverted back to classic behavior due to the bogus auto-generated %changelog.
If anyone wants to debug, feel free to check out the aircrack-ng package.
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
Zbyszek
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
josh
On Sat, Dec 31, 2022 at 9:07 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
Then we should not change the defaults and not recommend rpmautospec, especially for packages that Red Hat forks for CentOS/RHEL.
On 31. 12. 22 15:07, Josh Boyer wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
Are the packages imported on SRPM level with the changelogs rendered?
On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok mhroncok@redhat.com wrote:
On 31. 12. 22 15:07, Josh Boyer wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
Are the packages imported on SRPM level with the changelogs rendered?
They are not. It's done using distrobaker[1], which syncs Git content and lookaside data.
Example commit: https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecac...
[1]: https://github.com/fedora-eln/distrobaker
-- 真実はいつも一つ！/ Always, there's only one truth!
On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok mhroncok@redhat.com wrote:
On 31. 12. 22 15:07, Josh Boyer wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote: > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
Are the packages imported on SRPM level with the changelogs rendered?
They are not. It's done using distrobaker[1], which syncs Git content and lookaside data.
Example commit: https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecac...
I don't think that changes in Fedora should be held hostage by some downstream utils. We know that the problem is solvable and in fact not hard at all. We certainly can notify RHEL maintainers about this, which I did right now [1], but actual implementation is something that we have no control of from the Fedora side.
[1] https://github.com/fedora-eln/distrobaker/issues/12
Zbyszek
On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok mhroncok@redhat.com wrote:
On 31. 12. 22 15:07, Josh Boyer wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote: > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote: >> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default > Have we made sure that when Red Hat forks Fedora packages for RHEL > that they don't truncate or eliminate the Git history anymore? Because I would > personally be very displeased if my historical attribution went away > because of broken processes like the one used to fork all the Fedora > Linux 34 packages for CentOS Stream 9.
I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer.
Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem.
At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section.
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
Are the packages imported on SRPM level with the changelogs rendered?
They are not. It's done using distrobaker[1], which syncs Git content and lookaside data.
Example commit: https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecac...
I don't think that changes in Fedora should be held hostage by some downstream utils. We know that the problem is solvable and in fact not hard at all. We certainly can notify RHEL maintainers about this, which I did right now [1], but actual implementation is something that we have no control of from the Fedora side.
I think it's absolutely reasonable to consider the effects of people forking the packages in a way where attribution is lost. Losing attribution and correct package history is just not acceptable to me.
In many respects, this is *extremely* personal to me, because all I *have* is that attribution. I don't make any money on my work in Fedora. Nobody pays me to do it. The absolute *least* anyone can do is respect my copyright and preserve the attribution and history.
I am insulted that you think that's an issue that can be hand-waved away. This is a hill I will die on.
Fix it. And that means fundamentally changing how distrobaker works. Either preserve the whole Git history or always eliminate rpmautospec and expand the changelog when importing into RHEL. The current situation is simply not acceptable.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Sun, Jan 01, 2023 at 12:06:51PM -0500, Neal Gompa wrote:
On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote:
On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok mhroncok@redhat.com wrote:
On 31. 12. 22 15:07, Josh Boyer wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote: > > On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote: >> On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton bcotton@redhat.com wrote: >>> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default >> Have we made sure that when Red Hat forks Fedora packages for RHEL >> that they don't truncate or eliminate the Git history anymore? Because I would >> personally be very displeased if my historical attribution went away >> because of broken processes like the one used to fork all the Fedora >> Linux 34 packages for CentOS Stream 9. > > I can't speak for the RH folks who do the forking… It'd be great if > somebody who knows how that's done could answer. > > Fedora is already using rpmautospec widely enough that (if it was to > be problem at all), it must already be a problem. > > At the level of specific solutions, obviously the obvious answer is to > keep the git history. It's in general a great of source of information > and discarding that is just an error. But if somebody were really to do that, > it's fairly trivial to undo the conversion and get a static changelog > again by inserting the output of 'rpmautospec changelog' in the %changelog > section. >
As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults.
At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history.
We can look into it, but at the moment this is unlikely to change on the CentOS Stream/RHEL side.
Are the packages imported on SRPM level with the changelogs rendered?
They are not. It's done using distrobaker[1], which syncs Git content and lookaside data.
Example commit: https://gitlab.com/redhat/centos-stream/rpms/pipewire/-/commit/67142e715ecac...
I don't think that changes in Fedora should be held hostage by some downstream utils. We know that the problem is solvable and in fact not hard at all. We certainly can notify RHEL maintainers about this, which I did right now [1], but actual implementation is something that we have no control of from the Fedora side.
I think it's absolutely reasonable to consider the effects of people forking the packages in a way where attribution is lost. Losing attribution and correct package history is just not acceptable to me.
In many respects, this is *extremely* personal to me, because all I *have* is that attribution. I don't make any money on my work in Fedora. Nobody pays me to do it. The absolute *least* anyone can do is respect my copyright and preserve the attribution and history.
I am insulted that you think that's an issue that can be hand-waved away. This is a hill I will die on.
Fix it. And that means fundamentally changing how distrobaker works. Either preserve the whole Git history or always eliminate rpmautospec and expand the changelog when importing into RHEL. The current situation is simply not acceptable.
I fully support what you are saying. I do a lot of work in Fedora on my free time too, and I would very much like for it to be attributed properly. I also agree with the solutions you propose: I wrote the very same suggestions in the issue I linked above. (I also think that the problem already exists, *right now*, because rpmautospec is being used fairly widely, and if attributions are stripped, this is not nice to those maintainers and also deprives downstream users of useful information.) I just don't think that we should ask Fedora contributors to make plans or promises for a downstream distro. You are sending your complaints not to the people who can fix the issue.
Zbyszek
V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
It's not only about loosing attributions. There will be NEVRA discrepancies in RHEL:
Different number of commits will mean different release numbers. That will break package interdependencies which requires a specific release number. E.g foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo will strengthen the dependency with "Requires: bar >= 1-2". However, after importing to RHEL, bar will become bar-1-1. The dependency from foo will break.
Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL maintainers to revert rpmautospec to manual numbering for minor RHEL updates.
None of these issues are Fedora issues. But considering the ecosystems wholistically, the proposed rpmautospec propotion will add a friction.
-- Petr
On 03/01/2023 09:30, Petr Pisar wrote:
Different number of commits will mean different release numbers. That will break package interdependencies which requires a specific release number. E.g foo requires bar.
Good point. Hard-coded release numbers are a serious problem even in Fedora.
We have a serious issue with mesa vs. mesa-freeworld synchronization, because Fedora's mesa package has a strict EVR dependency requirement. RPM Fusion maintainers can't even bump Release, otherwise the package can't be installed due to conflict[1].
[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426
On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
It's not only about loosing attributions. There will be NEVRA discrepancies in RHEL:
Different number of commits will mean different release numbers. That will break package interdependencies which requires a specific release number. E.g foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo will strengthen the dependency with "Requires: bar >= 1-2". However, after importing to RHEL, bar will become bar-1-1. The dependency from foo will break.
That's a good point. The design works well within a single, continuous development environment such as Fedora's but any usage of the sources outside of that, either by importing SRPMs or by importing subsets of dist-git, seems like it would struggle. Does something like OBS suffer from the same issue? Seems it would, but I don't know much about how OBS works.
Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL maintainers to revert rpmautospec to manual numbering for minor RHEL updates.
Or automation grows the ability to support that kind of versioning, if it were to be used in RHEL.
None of these issues are Fedora issues. But considering the ecosystems wholistically, the proposed rpmautospec propotion will add a friction.
Nothing is free, that's for sure :)
josh
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
It's not only about loosing attributions. There will be NEVRA discrepancies in RHEL:
Different number of commits will mean different release numbers. That will break package interdependencies which requires a specific release number. E.g foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo will strengthen the dependency with "Requires: bar >= 1-2". However, after importing to RHEL, bar will become bar-1-1. The dependency from foo will break.
That's a good point. The design works well within a single, continuous development environment such as Fedora's but any usage of the sources outside of that, either by importing SRPMs or by importing subsets of dist-git, seems like it would struggle. Does something like OBS suffer from the same issue? Seems it would, but I don't know much about how OBS works.
OBS parses the spec file on import and sets the Release value auto increment based on the value of the Release field at import time. Then when you do a version bump, it resets the Release field back to 1.
OBS does not (by default) let you control the Release field, though a project/instance admin can change these defaults. By default, OBS overrides the Release value and does its own increments with a commit counter and a build counter, formatted as such: <CI_CNT>.<B_CNT>
If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first build. Any triggered rebuilds will bump the build counter. When you bump to foo-6, then the new build will be foo-6-1.1.
If you want to tweak OBS to retain the spec file Release value, you can configure the project or the instance entirely to use another scheme. For example, for the OBS project that obsctl is released to[1], the scheme is <SPEC_REL>+obs<CI_CNT>.<B_CNT>. That allows the original spec file's Release value to remain, while allowing OBS' generated data to be appended. You can see this in motion with a build of obsctl[2], where you can see that we've done the 6th rebuild of the 11th checkin of commit b6e1e99.
[1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf [2]: https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainl...
On Tue, Jan 3, 2023 at 5:11 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
It's not only about loosing attributions. There will be NEVRA discrepancies in RHEL:
Different number of commits will mean different release numbers. That will break package interdependencies which requires a specific release number. E.g foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo will strengthen the dependency with "Requires: bar >= 1-2". However, after importing to RHEL, bar will become bar-1-1. The dependency from foo will break.
That's a good point. The design works well within a single, continuous development environment such as Fedora's but any usage of the sources outside of that, either by importing SRPMs or by importing subsets of dist-git, seems like it would struggle. Does something like OBS suffer from the same issue? Seems it would, but I don't know much about how OBS works.
OBS parses the spec file on import and sets the Release value auto increment based on the value of the Release field at import time. Then when you do a version bump, it resets the Release field back to 1.
OBS does not (by default) let you control the Release field, though a project/instance admin can change these defaults. By default, OBS overrides the Release value and does its own increments with a commit counter and a build counter, formatted as such: <CI_CNT>.<B_CNT>
Thank you!
josh
If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first build. Any triggered rebuilds will bump the build counter. When you bump to foo-6, then the new build will be foo-6-1.1.
If you want to tweak OBS to retain the spec file Release value, you can configure the project or the instance entirely to use another scheme. For example, for the OBS project that obsctl is released to[1], the scheme is <SPEC_REL>+obs<CI_CNT>.<B_CNT>. That allows the original spec file's Release value to remain, while allowing OBS' generated data to be appended. You can see this in motion with a build of obsctl[2], where you can see that we've done the 6th rebuild of the 11th checkin of commit b6e1e99.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 3, 2023 at 5:10 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
Have we made sure that when Red Hat forks Fedora packages for RHEL that they don't truncate or eliminate the Git history anymore? Because I would personally be very displeased if my historical attribution went away because of broken processes like the one used to fork all the Fedora Linux 34 packages for CentOS Stream 9.
It's not only about loosing attributions. There will be NEVRA discrepancies in RHEL:
Different number of commits will mean different release numbers. That will break package interdependencies which requires a specific release number. E.g foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo will strengthen the dependency with "Requires: bar >= 1-2". However, after importing to RHEL, bar will become bar-1-1. The dependency from foo will break.
That's a good point. The design works well within a single, continuous development environment such as Fedora's but any usage of the sources outside of that, either by importing SRPMs or by importing subsets of dist-git, seems like it would struggle. Does something like OBS suffer from the same issue? Seems it would, but I don't know much about how OBS works.
OBS parses the spec file on import and sets the Release value auto increment based on the value of the Release field at import time. Then when you do a version bump, it resets the Release field back to 1.
OBS does not (by default) let you control the Release field, though a project/instance admin can change these defaults. By default, OBS overrides the Release value and does its own increments with a commit counter and a build counter, formatted as such: <CI_CNT>.<B_CNT>
If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first build. Any triggered rebuilds will bump the build counter. When you bump to foo-6, then the new build will be foo-6-1.1.
If you want to tweak OBS to retain the spec file Release value, you can configure the project or the instance entirely to use another scheme. For example, for the OBS project that obsctl is released to[1], the scheme is <SPEC_REL>+obs<CI_CNT>.<B_CNT>. That allows the original spec file's Release value to remain, while allowing OBS' generated data to be appended. You can see this in motion with a build of obsctl[2], where you can see that we've done the 6th rebuild of the 11th checkin of commit b6e1e99.
I should clarify here a bit, this is the 11th checkin into the OBS SCM, not the 11th checkin of the Git commit: https://build.opensuse.org/package/revisions/isv:Datto:Utilities:OBSCtl:Main...
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
-1 to this proposal.
As I had already written when this was first introduced, autogenerating the changelog from git history is a bad idea, especially in Fedora dist-git where published git history cannot ever be rewritten, so it is impossible to fix typos in the changelog, hide fixup commits if they did not use the proper fixup markup (or even avoid them altogether by amending the previously pushed commit), etc., which all requires to at least be able to edit commit messages, which unfortunately in git means you need to be able to amend the commit altogether and force-push. As long as such force-pushes are by design not allowed in Fedora dist-git, its (effectively immutable) metadata is not a suitable place to maintain the changelog in.
In addition, it assumes that the commits in git use the correct format for %autochangelog. In my current commits, I paste the full changelog entry with date and all into the commit details field and add a one-line summary as the commit summary. (Git-Cola automatically turns this into a commit message in the conventional git format summary + blank line (i.e., 2 newlines) + details.) Obviously, I do not want the date line to be pasted back into the changelog below an automatically generated one. (My older commits from pre- git times even had only the full changelog entry pasted with no summary line.) In addition, sometimes, I add details to the git commit message that are too long for the RPM changelog and hence are deliberately only in the git commit message. (More precisely, I append to the pasted changelog entry a blank line and one or more freeform paragraphs with the extra details.) I do not want those to ever be automatically added to the RPM changelog either.
Kevin Kofler
On Sat, Dec 31, 2022 at 01:09:54AM +0100, Kevin Kofler via devel wrote:
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
-1 to this proposal.
As I had already written when this was first introduced,
Rpmautospec is not the same now as it was two years ago. Your reseverations are mostly solved. See below.
autogenerating the changelog from git history is a bad idea, especially in Fedora dist-git where published git history cannot ever be rewritten, so it is impossible to fix typos in the changelog, hide fixup commits if they did not use the proper fixup markup (or even avoid them altogether by amending the previously pushed commit), etc., which all requires to at least be able to edit commit messages
tl;dr: you want to fix changelog entries. That's supported by saving the generated changelog to 'changelog' file and doing whatever edits you want there.
With that approach, you can do arbitrary formatting and fixups. The advantage compared to status quo (non-autochangelog) is that you only need to do it if the autogenerated changelog is deficient for whatever reasons. In the default case you can use autochangelog, and fall back to the manual version when necessary.
In addition, it assumes that the commits in git use the correct format for %autochangelog.
[snip long description of some very specific workflow]
Rpmautospec allows you to have a part or parts of a commit message that end up in the changelog, and parts that do not, see https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelo...
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
tl;dr: you want to fix changelog entries. That's supported by saving the generated changelog to 'changelog' file and doing whatever edits you want there.
With that approach, you can do arbitrary formatting and fixups. The advantage compared to status quo (non-autochangelog) is that you only need to do it if the autogenerated changelog is deficient for whatever reasons. In the default case you can use autochangelog, and fall back to the manual version when necessary.
[snip]
Rpmautospec allows you to have a part or parts of a commit message that end up in the changelog, and parts that do not, see https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelo...
All in all a very complicated and error-prone process just to save some extremely lazy packagers a 5-second copy&paste. I really do not see why that should be the default and recommended process.
The rules how to format the commit message are error-prone, and if you get them wrong, you usually only notice when it is too late to fix it (because force-pushes are not allowed). Yes, you can manually run "rpmautospec generate-changelog", but that is actually no less effort than just taking care of the changelog manually to begin with.
Kevin Kofler
On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
Zbigniew Jędrzejewski-Szmek wrote:
tl;dr: you want to fix changelog entries. That's supported by saving the generated changelog to 'changelog' file and doing whatever edits you want there.
With that approach, you can do arbitrary formatting and fixups. The advantage compared to status quo (non-autochangelog) is that you only
need
to do it if the autogenerated changelog is deficient for whatever
reasons.
In the default case you can use autochangelog, and fall back to the
manual
version when necessary.
[snip]
Rpmautospec allows you to have a part or parts of a commit message that end up in the changelog, and parts that do not, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelo...
All in all a very complicated and error-prone process just to save some extremely lazy packagers a 5-second copy&paste. I really do not see why that should be the default and recommended process.
The rules how to format the commit message are error-prone, and if you get them wrong, you usually only notice when it is too late to fix it (because force-pushes are not allowed). Yes, you can manually run "rpmautospec generate-changelog", but that is actually no less effort than just taking care of the changelog manually to begin with.
My main questions are what is this supposed to fix long term?
I have guessed that it has to do with automation, the shrinking number of active packagers in operating systems, and the exploding number of packages in requested languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say "HOW" this gets to dealing with this long term. It also isn't clear what the underlying remaining active packagers want to be part of.
On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen ssmoogen@redhat.com wrote:
My main questions are what is this supposed to fix long term?
I have guessed that it has to do with automation, the shrinking number of active packagers in operating systems, and the exploding number of packages in requested languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say "HOW" this gets to dealing with this long term. It also isn't clear what the underlying remaining active packagers want to be part of.
Speaking for myself: Using rpmautospec has massively reduced the maintenance burden for the Rust stack, and also for other packages that I maintain.
Due to the way optional dependencies / features are mapped to RPM subpackages (this works like with "extra" dependencies in Python packages, so this is not unique to Rust), you really should regenerate the entire spec file with rust2rpm for every new version (and every time when touching a patch that modifies features / optional dependencies in Rust crate metadata).
Previously, this meant arduously copying the old changelog contents somewhere, regenerating the spec file with rust2rpm, copying the old changelog back, set the Release count to "0", run "rpmdev-bumpspec" for the latest change, and commit the changes (usually with a useless duplicate of the changelog entry as commit message).
With rpmautospec, all steps except "regenerate the spec file with rust2rpm" and "git commit -c 'changelog contents'" are eliminated, which makes updating packages *much* easier, faster, and less error-prone.
Additionally, not having Release counter and changelog in the .spec file means that you can usually freely cherry-pick or merge bug-fix commits across different dist-git branches. This wasn't possible without rpmautospec due to merge conflicts caused by different Release counter or changelog contents.
Fabio
Fabio Valentini wrote:
Speaking for myself: Using rpmautospec has massively reduced the maintenance burden for the Rust stack, and also for other packages that I maintain.
Due to the way optional dependencies / features are mapped to RPM subpackages (this works like with "extra" dependencies in Python packages, so this is not unique to Rust), you really should regenerate the entire spec file with rust2rpm for every new version (and every time when touching a patch that modifies features / optional dependencies in Rust crate metadata).
Previously, this meant arduously copying the old changelog contents somewhere, regenerating the spec file with rust2rpm, copying the old changelog back, set the Release count to "0", run "rpmdev-bumpspec" for the latest change, and commit the changes (usually with a useless duplicate of the changelog entry as commit message).
With rpmautospec, all steps except "regenerate the spec file with rust2rpm" and "git commit -c 'changelog contents'" are eliminated, which makes updating packages *much* easier, faster, and less error-prone.
So it looks like in this case, it helps. That does not mean it needs to be the default for packages which are not autogenerated though.
Additionally, not having Release counter and changelog in the .spec file means that you can usually freely cherry-pick or merge bug-fix commits across different dist-git branches. This wasn't possible without rpmautospec due to merge conflicts caused by different Release counter or changelog contents.
If I have a package that I upgrade in stable releases, I keep Release in sync, and the changelog only really reflects Rawhide. I just fast-forward Rawhide to the release branch, and the Release tag and the changelog go along with it. If that includes some "Rebuild for Fnn mass rebuild" entries that do not really apply to the release branch, so be it. At least it explains why the Release number is as high as it is.
Kevin Kofler
On Sunday, 01 January 2022 at 20:51, Fabio Valentini wrote: [...]
Additionally, not having Release counter and changelog in the .spec file means that you can usually freely cherry-pick or merge bug-fix commits across different dist-git branches. This wasn't possible without rpmautospec due to merge conflicts caused by different Release counter or changelog contents.
Personally, I use the kernel's recommended commit to the oldest supported branch and merge upwards workflow and I've learned not to be afraid of merge commits. If any branch needs some specific fixes, I just apply them there and only there, without using spec conditionals. This keeps the specfiles clean and readable, even if they differ between branches. Obviously, this can't be (easily) automated and doesn't scale to hundreds or thousands of packages, but it works well for leaf packages.
rpmautospec doesn't work with the above workflow as it breaks on those merge commits, produces bogus changelog messages and artificially inflates Release counters.
Regards, Dominik
Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
produces bogus changelog messages and artificially inflates Release counters.
I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :)
Or it is my origin in BASIC that I am not afraid of that? We numbered the lines as a multiply of 5 or 10. :)
Miroslav
On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
produces bogus changelog messages and artificially inflates Release counters.
I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :)
The release number shows how many builds of the same version have been made. A high release is also baseline indicator that a package/project is stale downstream and/or upstream. When the first build of foo v1.5.0 is foo-1.5.0-6 because the author took the time to split up logical changes into separate commits, the value of that release number is lost.
-- Maxwell G (@gotmax23) Pronouns: He/Him/His
On Mon, Jan 2, 2023 at 4:43 AM Maxwell G via devel devel@lists.fedoraproject.org wrote:
On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
produces bogus changelog messages and artificially inflates Release counters.
I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :)
The release number shows how many builds of the same version have been made. A high release is also baseline indicator that a package/project is stale downstream and/or upstream. When the first build of foo v1.5.0 is foo-1.5.0-6 because the author took the time to split up logical changes into separate commits, the value of that release number is lost.
The heuristics you are describing are assumptions, not facts. They are decent assumptions in the context of the Fedora project, but they don't necessarily actually apply equally across the package set.
Personally, I think we should avoid tying any assumption to the Release value and simply realize that it is the mechanism used to present an update to a system. Guessing what foo-1.5.0-6 vs. foo-1.5.0-560 means based on what we think Release denotes is kind of dangerous.
josh
On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
produces bogus changelog messages and artificially inflates Release counters.
I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :)
Gaps in release numbering are just not neat. To me, they create an unnecessary confusion. Each bump in Release field should have a corresponding build in koji and it makes me wonder why if it doesn't.
Or it is my origin in BASIC that I am not afraid of that? We numbered the lines as a multiply of 5 or 10. :)
I've written code in BASIC back in the day. This comment is irrelevant to the issue at hand.
Regards, Dominik
On Mon, Jan 2, 2023 at 5:56 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
produces bogus changelog messages and artificially inflates Release counters.
I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :)
Gaps in release numbering are just not neat. To me, they create an unnecessary confusion. Each bump in Release field should have a corresponding build in koji and it makes me wonder why if it doesn't.
Which means you go and investigate and learn why, which is a sane thing to do if you want to know that information.
Equating Release values with builds is folly unless the build system automatically does a build for every commit. If it did, it could autogenerate the Release value and probably the changelog.... oh wait :)
josh
Or it is my origin in BASIC that I am not afraid of that? We numbered the lines as a multiply of 5 or 10. :)
I've written code in BASIC back in the day. This comment is irrelevant to the issue at hand.
Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dominik 'Rathann' Mierzejewski wrote:
Personally, I use the kernel's recommended commit to the oldest supported branch and merge upwards workflow and I've learned not to be afraid of merge commits. If any branch needs some specific fixes, I just apply them there and only there, without using spec conditionals. This keeps the specfiles clean and readable, even if they differ between branches. Obviously, this can't be (easily) automated and doesn't scale to hundreds or thousands of packages, but it works well for leaf packages.
rpmautospec doesn't work with the above workflow as it breaks on those merge commits, produces bogus changelog messages and artificially inflates Release counters.
This (the failure to handle merge commits) is a serious limitation because this is one of the workflows where an autochangelog would be most useful, in order to avoid the merge conflicts on the changelog.
If you work the way I do, avoiding merge commits in favor of fast forwards and specfile conditionals, then rpmautospec can in principle generate the autochangelog, but in that case, I do not really need it because my manual changelog fast-forwards just fine along with the rest of the commit.
Kevin Kofler
Similar situation happens if you have spec file in upstream. The problem is that mass rebuilds are adding entries to dowstream spec file only, so you have to manually merge the upstream and downstream or ideally do a backport upstream before realese. This is nice and easy solution for the issue.
Even though, we solved that by using Packit for releasing.
Jirka
Dne 01. 01. 23 v 20:51 Fabio Valentini napsal(a):
On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen ssmoogen@redhat.com wrote:
My main questions are what is this supposed to fix long term?
I have guessed that it has to do with automation, the shrinking number of active packagers in operating systems, and the exploding number of packages in requested languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say "HOW" this gets to dealing with this long term. It also isn't clear what the underlying remaining active packagers want to be part of.
Speaking for myself: Using rpmautospec has massively reduced the maintenance burden for the Rust stack, and also for other packages that I maintain.
Due to the way optional dependencies / features are mapped to RPM subpackages (this works like with "extra" dependencies in Python packages, so this is not unique to Rust), you really should regenerate the entire spec file with rust2rpm for every new version (and every time when touching a patch that modifies features / optional dependencies in Rust crate metadata).
Previously, this meant arduously copying the old changelog contents somewhere, regenerating the spec file with rust2rpm, copying the old changelog back, set the Release count to "0", run "rpmdev-bumpspec" for the latest change, and commit the changes (usually with a useless duplicate of the changelog entry as commit message).
With rpmautospec, all steps except "regenerate the spec file with rust2rpm" and "git commit -c 'changelog contents'" are eliminated, which makes updating packages *much* easier, faster, and less error-prone.
Additionally, not having Release counter and changelog in the .spec file means that you can usually freely cherry-pick or merge bug-fix commits across different dist-git branches. This wasn't possible without rpmautospec due to merge conflicts caused by different Release counter or changelog contents.
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sat, Dec 31, 2022 at 03:37:34PM -0500, Stephen Smoogen wrote:
On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel <
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelo...
All in all a very complicated and error-prone process just to save some extremely lazy packagers a 5-second copy&paste. I really do not see why that should be the default and recommended process.
The rules how to format the commit message are error-prone, and if you get them wrong, you usually only notice when it is too late to fix it (because force-pushes are not allowed). Yes, you can manually run "rpmautospec generate-changelog", but that is actually no less effort than just taking care of the changelog manually to begin with.
My main questions are what is this supposed to fix long term?
My understanding is that the main thing rpmautospec is supposed to address is to decouple changelog and release values from specific changes. This for example makes pull requests much easier.
Without it, pull requests either have to specifically tie a change to a release/changelog entry or leave that to the maintainer. With it, PR's can be applied in any order or after some other unrelated changes without a bunch of back and forth to adjust the release/changelog to match unrelated changes.
I think moving more things to it makes a lot of sense as long as we are moving to a more pull request flow. I can't speak for others, but I have indeed noticed a increase in PR's on packages I maintain over the last few years.
kevin
On 30/12/2022 20:01, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
-1 until these known issues[1] are fixed, especially with changelogs and using rpmautospec in COPR or mock.
[1]: https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-co...
* Vitaly Zaitsev via devel:
On 30/12/2022 20:01, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
-1 until these known issues[1] are fixed, especially with changelogs and using rpmautospec in COPR or mock.
The page doesnt discuss COPR/mock?
COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git).
A quick check suggests that rpmautospec does the right thing and produces a portable source RPM that doesn't depend on rpmautospec anymore. As a result, the compatibility impact won't be too severe, I hope.
Thanks, Florian
On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
- Vitaly Zaitsev via devel:
On 30/12/2022 20:01, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
-1 until these known issues[1] are fixed, especially with changelogs and using rpmautospec in COPR or mock.
The page doesnt discuss COPR/mock?
COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git).
A quick check suggests that rpmautospec does the right thing and produces a portable source RPM that doesn't depend on rpmautospec anymore. As a result, the compatibility impact won't be too severe, I hope.
Also mock builds seem fine. I tested this now on F37 with a few different scenarios: - fedpkg mockbuild - git commit --allow-empty -m Rebuild && fedpkg mockbuild - fedpkg srpm && mock *.src.rpm seem to generate the expected versions numbers and changelogs.
Zbyszek
On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
- Vitaly Zaitsev via devel:
On 30/12/2022 20:01, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
-1 until these known issues[1] are fixed, especially with changelogs and using rpmautospec in COPR or mock.
[1]:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-co...
The page doesnt discuss COPR/mock?
COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git).
A quick check suggests that rpmautospec does the right thing and produces a portable source RPM that doesn't depend on rpmautospec anymore. As a result, the compatibility impact won't be too severe, I hope.
Also mock builds seem fine. I tested this now on F37 with a few different scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.
This is my problem with the proposal. Our tools haven't been fully integrated. For a typical update I do not need to run git directly, but for this workflow I do.
For a typical bump all I need is:
rpmdev-bumpspec -c "Change here" fedpkg commit -c -p fedpkg build
Our tools need to handle this automagically. I shouldn't have to know I need to add "--allow-empty". It should just work.
Thanks, Richard
On Mon, Jan 02, 2023 at 03:01:16PM -0600, Richard Shaw wrote:
On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
- Vitaly Zaitsev via devel:
On 30/12/2022 20:01, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
-1 until these known issues[1] are fixed, especially with changelogs and using rpmautospec in COPR or mock.
[1]:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-co...
The page doesnt discuss COPR/mock?
COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git).
A quick check suggests that rpmautospec does the right thing and produces a portable source RPM that doesn't depend on rpmautospec anymore. As a result, the compatibility impact won't be too severe, I hope.
Also mock builds seem fine. I tested this now on F37 with a few different scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.
This is my problem with the proposal. Our tools haven't been fully integrated. For a typical update I do not need to run git directly, but for this workflow I do.
For a typical bump all I need is:
rpmdev-bumpspec -c "Change here" fedpkg commit -c -p fedpkg build
Our tools need to handle this automagically. I shouldn't have to know I need to add "--allow-empty". It should just work.
Yes, it'd be nice if 'fedpkg' handled this natively more nicely. There is nothing to do for rpmdev-bumpspec in this case. The first two steps should/could be replaced by one command:
fedpkg commit -m 'Change here' -p
I filed https://pagure.io/fedpkg/issue/494 asking for this. I'll add this to the Scope section of the proposal so we don't lose track.
Zbyszek
Dne 02. 01. 23 v 22:01 Richard Shaw napsal(a):
Also mock builds seem fine. I tested this now on F37 with a few different scenarios: - fedpkg mockbuild - git commit --allow-empty -m Rebuild && fedpkg mockbuild - fedpkg srpm && mock *.src.rpm seem to generate the expected versions numbers and changelogs.This is my problem with the proposal. Our tools haven't been fully integrated. For a typical update I do not need to run git directly, but for this workflow I do.
For a typical bump all I need is:
rpmdev-bumpspec -c "Change here" fedpkg commit -c -p fedpkg build
Our tools need to handle this automagically. I shouldn't have to know I need to add "--allow-empty". It should just work.
https://pagure.io/rpkg/pull-request/644
You are welcome.
Miroslav
Zbigniew Jędrzejewski-Szmek kirjoitti 2.1.2023 klo 22.44:
On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
- Vitaly Zaitsev via devel:
On 30/12/2022 20:01, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
-1 until these known issues[1] are fixed, especially with changelogs and using rpmautospec in COPR or mock.
The page doesnt discuss COPR/mock?
COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git).
A quick check suggests that rpmautospec does the right thing and produces a portable source RPM that doesn't depend on rpmautospec anymore. As a result, the compatibility impact won't be too severe, I hope.
Also mock builds seem fine. I tested this now on F37 with a few different scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.
All these examples work because 'fedpkg srpm' does the rpmautospec conversion, and all the used fedpkg commands imply 'fedpkg srpm'.
If you generate an srpm which still contains %autorelease and %autochangelog with 'rpmbuild -bs', mock will not convert them by itself. Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly meant mock should support such usage?
But I wonder, if that is really necessary? In many cases like local test builds, the default values for uncoverted %autorelease and %autochangelog are just fine, and if the real values are needed, 'fedpkg srpm' can be called before invoking mock.
Dne 02. 01. 23 v 22:39 Otto Liljalaakso napsal(a):
Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly meant mock should support such usage?
Mock cannot add such support, because Mock rarely operate on top of dist-git (or even git). So there is no way how to retrieve git log.
Miroslav
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Zbyszek
On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Yes, I would say that as well. It's just a low level tool and can never have all the integration with git that fedpkg has.
We might need to update package maintainer documents to be clear about this though, so that people know that they should use 'fedpkg srpm' and not 'rpmbuild -bs'.
Kalev Lember kirjoitti 3.1.2023 klo 11.19:
On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Yes, I would say that as well. It's just a low level tool and can never have all the integration with git that fedpkg has.
We might need to update package maintainer documents to be clear about this though, so that people know that they should use 'fedpkg srpm' and not 'rpmbuild -bs'.
In Package Maintainer Docs, we have just a single instance of rpmbuild usage, at Using the Koji Build System — Scratch Builds [1]. Everything else is fedpkg based already. I made a pull request to get rid of that single outlier [2].
Did you have some other source of documentation in mind that would need more work?
[1]: https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Buil... [2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101
On Tue, Jan 3, 2023 at 10:27 PM Otto Liljalaakso otto.liljalaakso@iki.fi wrote:
Kalev Lember kirjoitti 3.1.2023 klo 11.19:
We might need to update package maintainer documents to be clear about
this
though, so that people know that they should use 'fedpkg srpm' and not 'rpmbuild -bs'.
In Package Maintainer Docs, we have just a single instance of rpmbuild usage, at Using the Koji Build System — Scratch Builds [1]. Everything else is fedpkg based already. I made a pull request to get rid of that single outlier [2].
Did you have some other source of documentation in mind that would need more work?
[1]:
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Buil... [2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101
Awesome, thanks for doing that! No, I didn't have anything specific in mind, so hopefully that was all there was to fix :)
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec (because it's implemented on top of RPM instead of *in* RPM), but it will still produce a valid SRPM file, just with default fallback values for both %autorelease (i.e. 1%{?dist}) and %autochangelog (i.e. empty). I even still recommend "rpmbuild -bs" to "new packagers" for building an SRPM outside a dist-git repository (for example, for submitting it for package review). But for building an SRPM in a dist-git repo, "fedpkg srpm" is absolutely the better choice.
Fabio
Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec (because it's implemented on top of RPM instead of *in* RPM),
Oh, it does not know about more things, e.g.:
~~~
$ rpmbuild -bs ruby.spec error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby 0< (%load) ~~~
So it does not handle more scenarios then just rpmautospec.
but it will still produce a valid SRPM file, just with default fallback values for both %autorelease (i.e. 1%{?dist}) and %autochangelog (i.e. empty). I even still recommend "rpmbuild -bs" to "new packagers" for building an SRPM outside a dist-git repository (for example, for submitting it for package review).
IMHO, it would be much better to recommend:
~~~
$ touch sources
$ fedpkg --release f38 srpm
~~~
instead.
Vít
But for building an SRPM in a dist-git repo, "fedpkg srpm" is absolutely the better choice.
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec (because it's implemented on top of RPM instead of *in* RPM),
Oh, it does not know about more things, e.g.:
$ rpmbuild -bs ruby.spec error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby 0< (%load)
Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
So it does not handle more scenarios then just rpmautospec.
IMHO, it would be much better to recommend:
$ touch sources $ fedpkg --release f38 srpm
Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically. It would just make everyone's life easier.
Zbyszek
On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote: > - fedpkg mockbuild But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec (because it's implemented on top of RPM instead of *in* RPM),
Oh, it does not know about more things, e.g.:
$ rpmbuild -bs ruby.spec error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby 0< (%load)Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
So it does not handle more scenarios then just rpmautospec.
IMHO, it would be much better to recommend:
$ touch sources $ fedpkg --release f38 srpm
Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically. It would just make everyone's life easier.
It already does. I use it for packaging I have in Git repos on pagure.io.
-- 真実はいつも一つ！/ Always, there's only one truth!
Dne 03. 01. 23 v 16:24 Neal Gompa napsal(a):
On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote: > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote: >> - fedpkg mockbuild > But it doesn't work correctly (will always use Release: 1) if you run > "rpmbuild -bs foo-bar.spec" which is a very common scenario. "Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec (because it's implemented on top of RPM instead of *in* RPM),
Oh, it does not know about more things, e.g.:
$ rpmbuild -bs ruby.spec error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby 0< (%load)Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
So it does not handle more scenarios then just rpmautospec. IMHO, it would be much better to recommend:
$ touch sources $ fedpkg --release f38 srpm
Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically. It would just make everyone's life easier.
It already does. I use it for packaging I have in Git repos on pagure.io.
Oh really? Very nice. Have not noticed it yet. Thx for heads up.
Vít
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Zbigniew Jędrzejewski-Szmek wrote:
Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
I've used the following in ~/.rpmmacros for many years to have rpmbuild keep package files together, as rpkg/fedpkg do:
%_sourcedir %{_topdir}/%{?name:%name} %_specdir %{_sourcedir} %_builddir %{_sourcedir} %_srcrpmdir %{_sourcedir} %_rpmdir %{_sourcedir}
That doesn't address the deeper issues with respect to rpmautospec compatibility, but it does make rpmbuild much more comfortable to use, at least for me.
Dne 03. 01. 23 v 19:03 Todd Zullinger napsal(a):
Zbigniew Jędrzejewski-Szmek wrote:
Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
I've used the following in ~/.rpmmacros for many years to have rpmbuild keep package files together, as rpkg/fedpkg do:
%_sourcedir %{_topdir}/%{?name:%name} %_specdir %{_sourcedir} %_builddir %{_sourcedir} %_srcrpmdir %{_sourcedir} %_rpmdir %{_sourcedir}
Change to the dist-git layout is tracked upstream [1], so maybe the default will change one day. But shouldn't we suggest this configuration somewhere in Fedora documentation? Maybe we could speed up the transition ...
Vít
[1] https://github.com/rpm-software-management/rpm/issues/1171
That doesn't address the deeper issues with respect to rpmautospec compatibility, but it does make rpmbuild much more comfortable to use, at least for me.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Jan 04, 2023 at 03:04:02PM +0100, Vít Ondruch wrote:
Dne 03. 01. 23 v 19:03 Todd Zullinger napsal(a):
Zbigniew Jędrzejewski-Szmek wrote:
Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
I've used the following in ~/.rpmmacros for many years to have rpmbuild keep package files together, as rpkg/fedpkg do:
%_sourcedir %{_topdir}/%{?name:%name} %_specdir %{_sourcedir} %_builddir %{_sourcedir} %_srcrpmdir %{_sourcedir} %_rpmdir %{_sourcedir}Change to the dist-git layout is tracked upstream [1], so maybe the default will change one day. But shouldn't we suggest this configuration somewhere in Fedora documentation? Maybe we could speed up the transition ...
There is rpmdev-setuptree in the rpmdevtools package, which itself is required by fedora-packager. It creates the following:
$ cat .rpmmacros
%_topdir %(echo $HOME)/rpmbuild
%__arch_install_post \ [ "%{buildarch}" = "noarch" ] || QA_CHECK_RPATHS=1 ; \ case "${QA_CHECK_RPATHS:-}" in [1yY]*) /usr/lib/rpm/check-rpaths ;; esac \ /usr/lib/rpm/check-buildroot
$ find rpmbuild rpmbuild/ rpmbuild/RPMS rpmbuild/SOURCES rpmbuild/SPECS rpmbuild/SRPMS rpmbuild/BUILD
Perhaps this can be modified to create a layout that matches dist-git?
On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson cra@fea.st wrote:
On Wed, Jan 04, 2023 at 03:04:02PM +0100, Vít Ondruch wrote:
Dne 03. 01. 23 v 19:03 Todd Zullinger napsal(a):
Zbigniew Jędrzejewski-Szmek wrote:
Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
I've used the following in ~/.rpmmacros for many years to have rpmbuild keep package files together, as rpkg/fedpkg do:
%_sourcedir %{_topdir}/%{?name:%name} %_specdir %{_sourcedir} %_builddir %{_sourcedir} %_srcrpmdir %{_sourcedir} %_rpmdir %{_sourcedir}Change to the dist-git layout is tracked upstream [1], so maybe the default will change one day. But shouldn't we suggest this configuration somewhere in Fedora documentation? Maybe we could speed up the transition ...
There is rpmdev-setuptree in the rpmdevtools package, which itself is required by fedora-packager. It creates the following:
$ cat .rpmmacros
%_topdir %(echo $HOME)/rpmbuild
%__arch_install_post \ [ "%{buildarch}" = "noarch" ] || QA_CHECK_RPATHS=1 ; \ case "${QA_CHECK_RPATHS:-}" in [1yY]*) /usr/lib/rpm/check-rpaths ;; esac \ /usr/lib/rpm/check-buildroot
$ find rpmbuild rpmbuild/ rpmbuild/RPMS rpmbuild/SOURCES rpmbuild/SPECS rpmbuild/SRPMS rpmbuild/BUILD
Perhaps this can be modified to create a layout that matches dist-git?
Probably not, because Dist-Git is a Fedora-specific thing, so I wouldn't accept such a change in rpmdevtools upstream.
Hi
On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson cra@fea.st wrote:
Perhaps this can be modified to create a layout that matches dist-git?
Probably not, because Dist-Git is a Fedora-specific thing, so I wouldn't accept such a change in rpmdevtools upstream.
You can add it with a --distro flag
Rahul
On Wed, Jan 4, 2023 at 10:51 AM Rahul Sundaram metherid@gmail.com wrote:
Hi
On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson cra@fea.st wrote:
Perhaps this can be modified to create a layout that matches dist-git?
Probably not, because Dist-Git is a Fedora-specific thing, so I wouldn't accept such a change in rpmdevtools upstream.
You can add it with a --distro flag
Well, more specifically, it's a Fedora build system specific thing. Building Fedora packages in other systems doesn't necessarily work that way.
If you want something like this, it probably makes sense to be in fedpkg(1) itself.
Neal Gompa kirjoitti 4.1.2023 klo 18.02:
On Wed, Jan 4, 2023 at 10:51 AM Rahul Sundaram metherid@gmail.com wrote:
On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson cra@fea.st wrote:
Perhaps this can be modified to create a layout that matches dist-git?
Probably not, because Dist-Git is a Fedora-specific thing, so I wouldn't accept such a change in rpmdevtools upstream.
You can add it with a --distro flag
Well, more specifically, it's a Fedora build system specific thing. Building Fedora packages in other systems doesn't necessarily work that way.
If you want something like this, it probably makes sense to be in fedpkg(1) itself.
That is exactly what fedpkg does. It calls rpmbuild with a config that is compatible with the dist-git layout.
Regarding documenting the configuration that rpmbuild needs, I have proposed earlier [1] that people who want to promote rpmbuild usage write a tutorial for that. It could create the same package that current GNU Hello tutorial creates, just using an alternative toolset.
A lighter way would be to just add a new section to "Installing Package Tools" [2], explaining what needs to be configured so that rpmbuild can be invoked directly.
Personally, I would prefer that contributions to Package Maintainer Docs would either fix parts that are wrong, outdated or unclear, or add material that is completely missing, instead of adding alternatives for topics that are already well covered. But these docs are under shared ownership of all Fedora packagers, so if somebody thinks it is important and is willing to work on it, pull requests are welcome!
[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/88#commen... [2]: https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager...
Now I'm getting bit by the rpmautospec and COPR issue.
I'm trying to test rebuilds of all dependent packages for a new OpenColorIO release, but usd uses rpmautospec and in Fedora it's usd-<version>-16 but COPR is calculating it as usd-<version>-9 so the Fedora version has a higher NEVR.
Now what am I supposed to do?
Thanks, Richard
On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote:
Now I'm getting bit by the rpmautospec and COPR issue.
Please be more precise. How are you building the rpms?
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
I'm trying to test rebuilds of all dependent packages for a new OpenColorIO release, but usd uses rpmautospec and in Fedora it's usd-<version>-16 but COPR is calculating it as usd-<version>-9 so the Fedora version has a higher NEVR.
First of all, if you e.g. want to test the rebuilt packages on your system, you can always install a lower version than the one currently released. Dnf allows both downgrades and installations of a specific package and a specific package version.
Second, how exactly are you building the package? Looking at [1], you used "Source Type: SRPM or .spec file upload". How was it generated?
[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/
Both 'fedpkg srpm' and uploading that to copr, and letting copr build from dist-git should result in the expected release. (Though without other steps it'll still be the same as the version in Fedora release, so you'll need to tell dnf to install that specific build.)
Zbyszek
On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
Steps to reproduce:
1. Create a new COPR project. 2. Add a new COPR package with building from SCM: - Type - Git - Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you can choose any other package with rpmautospec) - Commithash: rawhide - Spec File: protobuf-c.spec - How to build SRPM - rpkg (default choice) 3. Press Save and Rebuild. 4. Wait for the results. Check the final RPM. It will have Release: 1 and an empty %changelog.
Dne 10. 01. 23 v 9:29 Vitaly Zaitsev via devel napsal(a):
On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
Steps to reproduce:
- Create a new COPR project.
- Add a new COPR package with building from SCM:
- Type - Git - Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you can choose any other package with rpmautospec) - Commithash: rawhide - Spec File: protobuf-c.spec - How to build SRPM - rpkg (default choice) 3. Press Save and Rebuild. 4. Wait for the results. Check the final RPM. It will have Release: 1 and an empty %changelog.
rpmautospec should work with plain git - I will leave the defending for others.
But in your case you should rather use DistGit instead of SCM method (the first row of tabs):
https://docs.pagure.org/copr.copr/user_documentation.html#distgit
And it should start working.
Miroslav
On 10/01/2023 10:38, Miroslav Suchý wrote:
But in your case you should rather use DistGit instead of SCM method (the first row of tabs): https://docs.pagure.org/copr.copr/user_documentation.html#distgit
Looks interesting. Thank you very much for the info. I will use it in the future.
On Tue, Jan 10, 2023 at 4:39 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 10. 01. 23 v 9:29 Vitaly Zaitsev via devel napsal(a):
On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
Steps to reproduce:
- Create a new COPR project.
- Add a new COPR package with building from SCM:
- Type - Git
- Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you can choose any other package with rpmautospec)
- Commithash: rawhide
- Spec File: protobuf-c.spec
- How to build SRPM - rpkg (default choice)
- Press Save and Rebuild.
- Wait for the results. Check the final RPM. It will have Release: 1 and an empty %changelog.
rpmautospec should work with plain git - I will leave the defending for others.
But in your case you should rather use DistGit instead of SCM method (the first row of tabs):
https://docs.pagure.org/copr.copr/user_documentation.html#distgit
And it should start working.
Admittedly, I have a weird case here, but I'm forking a Fedora package and putting it outside of DistGit. It uses RPMAutoSpec and I'm trying to build this in COPR, but because I can't use it through the DistGit method, the NVR is broken.
Example: * Git: https://pagure.io/fedora-asahi/asahi-fedora-remix-release * Package: https://copr.fedorainfracloud.org/coprs/g/asahi/fedora-remix-branding/build/...
* Vitaly Zaitsev via devel:
On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote:
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
Steps to reproduce:
- Create a new COPR project.
- Add a new COPR package with building from SCM:
- Type - Git
- Clone URL: https://src.fedoraproject.org/rpms/protobuf-c.git (you can choose any other package with rpmautospec)
- Commithash: rawhide
- Spec File: protobuf-c.spec
- How to build SRPM - rpkg (default choice)
- Press Save and Rebuild.
- Wait for the results. Check the final RPM. It will have Release: 1
and an empty %changelog.
rpmautospec only works for type Build from DistGit, I think.
Thanks, Florian
I have a roundabout way to make COPR and rpmautospec work with any git repo :)
1. Create a new COPR project 2. Add a new COPR package with source type Custom - Script #! /bin/sh -x git clone <url> <name> cd <name> spectool -g <specfile_path> #other stuff you need to prepare rpmautospec process-distgit <specfile_path> <specfile_path> - Build dependencies: git rpmdevtools rpmautospec - Result directory: <name> 3. Press Save and Rebuild 4. Wait for the results. Release and changelogs should work as expected
On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote:
Now I'm getting bit by the rpmautospec and COPR issue.
Please be more precise. How are you building the rpms?
The SRPMS? I'm using "rpkg build <PROJECT>"
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
I'm trying to test rebuilds of all dependent packages for a new
OpenColorIO
release, but usd uses rpmautospec and in Fedora it's usd-<version>-16 but COPR is calculating it as usd-<version>-9 so the Fedora version has a higher NEVR.
First of all, if you e.g. want to test the rebuilt packages on your system, you can always install a lower version than the one currently released. Dnf allows both downgrades and installations of a specific package and a specific package version.
I don't want to test the packages per say, I just need COPR to pull in the rebuilt package instead of the one in Fedora, otherwise I get dnf conflicts:
Problem: package usd-libs-22.05b-16.fc38.x86_64 requires libOpenColorIO.so.2.1()(64bit), but none of the providers can be installed - cannot install both OpenColorIO-2.1.2-5.fc38.1.x86_64 and OpenColorIO-2.2.0-1.fc38.x86_64 - package usd-devel-22.05b-16.fc38.x86_64 requires usd-libs(x86-64) = 22.05b-16.fc38, but none of the providers can be installed - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires libOpenColorIO.so.2.2()(64bit), but none of the providers can be installed - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires OpenColorIO(x86-64) = 2.2.0-1.fc38, but none of the providers can be installed
- cannot install the best candidate for the job
Second, how exactly are you building the package? Looking at [1], you used "Source Type: SRPM or .spec file upload". How was it generated?
[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/
Both 'fedpkg srpm' and uploading that to copr, and letting copr build from dist-git should result in the expected release. (Though without other steps it'll still be the same as the version in Fedora release, so you'll need to tell dnf to install that specific build.)
Looks like the problem is using `rpkg` but that's the easiest method and has worked great until now...
Thanks, Richard
On 10. 01. 23 13:52, Richard Shaw wrote:
Second, how exactly are you building the package? Looking at [1], you used "Source Type: SRPM or .spec file upload". How was it generated? [1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/ <https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/> Both 'fedpkg srpm' and uploading that to copr, and letting copr build from dist-git should result in the expected release. (Though without other steps it'll still be the same as the version in Fedora release, so you'll need to tell dnf to install that specific build.)Looks like the problem is using `rpkg` but that's the easiest method and has worked great until now...
For the record I've reported several issues with the rpkg method over the years. The distgit method was partially a response for those. tl;dr rpkg "works great" until it doesn't because it does not work like fedpkg, but instead it is a pre-processor for templated spec files that happens to work in most of the cases with bare spec files as well.
Examples:
https://pagure.io/copr/copr/issue/1703 https://pagure.io/copr/copr/issue/798 https://pagure.io/copr/copr/issue/1219
Umbrella issue: https://pagure.io/copr/copr/issue/529
On Tue, Jan 10, 2023 at 11:48 AM Miro Hrončok mhroncok@redhat.com wrote:
On 10. 01. 23 13:52, Richard Shaw wrote:
Second, how exactly are you building the package? Looking at [1], you used "Source Type: SRPM or .spec file upload". How was it generated? [1]https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/
<https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/%3E
Both 'fedpkg srpm' and uploading that to copr, and letting coprbuild from
dist-git should result in the expected release. (Though withoutother steps
it'll still be the same as the version in Fedora release, so you'llneed
to tell dnf to install that specific build.)Looks like the problem is using `rpkg` but that's the easiest method and
has
worked great until now...
For the record I've reported several issues with the rpkg method over the years. The distgit method was partially a response for those. tl;dr rpkg "works great" until it doesn't because it does not work like fedpkg, but instead it is a pre-processor for templated spec files that happens to work in most of the cases with bare spec files as well.
I didn't realize the fedpkg had grown the ability to do COPR builds. I will use that from now on.
Thanks, Richard
On Tue, Jan 10, 2023 at 1:53 PM Richard Shaw hobbes1069@gmail.com wrote:
On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote:
Now I'm getting bit by the rpmautospec and COPR issue.
Please be more precise. How are you building the rpms?
The SRPMS? I'm using "rpkg build <PROJECT>"
If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji.
I'm trying to test rebuilds of all dependent packages for a new OpenColorIO release, but usd uses rpmautospec and in Fedora it's usd-<version>-16 but COPR is calculating it as usd-<version>-9 so the Fedora version has a higher NEVR.
First of all, if you e.g. want to test the rebuilt packages on your system, you can always install a lower version than the one currently released. Dnf allows both downgrades and installations of a specific package and a specific package version.
I don't want to test the packages per say, I just need COPR to pull in the rebuilt package instead of the one in Fedora, otherwise I get dnf conflicts:
Problem: package usd-libs-22.05b-16.fc38.x86_64 requires libOpenColorIO.so.2.1()(64bit), but none of the providers can be installed
cannot install both OpenColorIO-2.1.2-5.fc38.1.x86_64 and OpenColorIO-2.2.0-1.fc38.x86_64
package usd-devel-22.05b-16.fc38.x86_64 requires usd-libs(x86-64) = 22.05b-16.fc38, but none of the providers can be installed
package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires libOpenColorIO.so.2.2()(64bit), but none of the providers can be installed
package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires OpenColorIO(x86-64) = 2.2.0-1.fc38, but none of the providers can be installed
cannot install the best candidate for the job
Second, how exactly are you building the package? Looking at [1], you used "Source Type: SRPM or .spec file upload". How was it generated?
[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/
Both 'fedpkg srpm' and uploading that to copr, and letting copr build from dist-git should result in the expected release. (Though without other steps it'll still be the same as the version in Fedora release, so you'll need to tell dnf to install that specific build.)
Looks like the problem is using `rpkg` but that's the easiest method and has worked great until now...
Well, it was only a matter of time until rpkg stopped working. It was abandoned a while ago and was officially marked as "no longer maintained" last year: https://pagure.io/rpkg-util
Fabio
Dne 04. 01. 23 v 16:24 Chuck Anderson napsal(a):
On Wed, Jan 04, 2023 at 03:04:02PM +0100, Vít Ondruch wrote:
Dne 03. 01. 23 v 19:03 Todd Zullinger napsal(a):
Zbigniew Jędrzejewski-Szmek wrote:
Yes, this is what I was talking about too. Because rpmbuild does not set %_sourcedir, it may fail to load some files. Even worse, it may load *wrong* versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/. Personally, I have dozens of stray files there from old rpm builds there…
I've used the following in ~/.rpmmacros for many years to have rpmbuild keep package files together, as rpkg/fedpkg do:
%_sourcedir %{_topdir}/%{?name:%name} %_specdir %{_sourcedir} %_builddir %{_sourcedir} %_srcrpmdir %{_sourcedir} %_rpmdir %{_sourcedir}Change to the dist-git layout is tracked upstream [1], so maybe the default will change one day. But shouldn't we suggest this configuration somewhere in Fedora documentation? Maybe we could speed up the transition ...
There is rpmdev-setuptree in the rpmdevtools package, which itself is required by fedora-packager. It creates the following:
$ cat .rpmmacros
%_topdir %(echo $HOME)/rpmbuild
%__arch_install_post \ [ "%{buildarch}" = "noarch" ] || QA_CHECK_RPATHS=1 ; \ case "${QA_CHECK_RPATHS:-}" in [1yY]*) /usr/lib/rpm/check-rpaths ;; esac \ /usr/lib/rpm/check-buildroot
$ find rpmbuild rpmbuild/ rpmbuild/RPMS rpmbuild/SOURCES rpmbuild/SPECS rpmbuild/SRPMS rpmbuild/BUILD
Perhaps this can be modified to create a layout that matches dist-git?
But the point is that for dist-git layout, this command should not be needed ...
Vít
On Tue, 3 Jan 2023 08:14:04 -0500 Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
I wonder whether we should start recommending "rpkg" instead of plain "rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it quite useful/powerful.
Dan
On Tue, Jan 3, 2023 at 8:24 AM Dan Horák dan@danny.cz wrote:
On Tue, 3 Jan 2023 08:14:04 -0500 Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
I wonder whether we should start recommending "rpkg" instead of plain "rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it quite useful/powerful.
As I understand it, rpkg is not maintained, so that would be a poor choice.
-- 真実はいつも一つ！/ Always, there's only one truth!
Dan Horák kirjoitti 3.1.2023 klo 15.23:
On Tue, 3 Jan 2023 08:14:04 -0500 Stephen Smoogen ssmoogen@redhat.com wrote:
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
I wonder whether we should start recommending "rpkg" instead of plain "rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it quite useful/powerful.
Perhaps we have other places that still recommend rpmbuild for this, but at least our "GNU Hello" packaging tutorial [1] currently uses fedpkg for this.
The instructions given in the tutorial do work. Unlike Stephen implies, fedpkg can be used outside of Git repository for this and other tasks.
This Change will make that tutorial use also rpmautospec. I have a pull request ready for that [2].
[1]: https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_... [2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/102
* Stephen Smoogen:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken?
It's never been a reliable way to create a source RPM from a dist-git checkout. For example, it does not ensure that all the necessary dependencies are installed, or that all the RPM macros are set up correctly.
Thanks, Florian
On Tue, 3 Jan 2023 at 08:14, Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
- fedpkg mockbuild
But it doesn't work correctly (will always use Release: 1) if you run "rpmbuild -bs foo-bar.spec" which is a very common scenario.
"Doctor, it hurts when I do that."
'rpmbuild -bs' is broken. Don't use it.
Could you please elucidate why the command that people have used for nearly 30 years and is the most documented on how to build rpms is broken? And how people should use instead when they may be dealing with an environment which doesn't allow fedpkg to work? [AKA I am working on a package which I want to submit for review so I need to build a @$@$% src RPM somehow and I am being told I can't use the built in command to do so]
OK I have started off the year with a cranky email. My apologies for that as I should have gone back to read the context which this was being said in. [I am usually all for removing extra stuff from an email to make it short and sweet, and then go read what I might have missed.. however in this case I didn't and just barked like a mad dog.]
-- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
On 01/01/2023 15:10, Florian Weimer wrote:
COPR seems to work in some cases, specifically with the dist-git build (but not just building from dist-git).
Run "rpmbuild -bs foo-bar.spec", upload it to COPR and it will use Release: 1.
I also need to figure out if it works with building from SCM without uploading rendered SRPM.
Il 30/12/22 20:01, Ben Cotton ha scritto:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
I'm lazy, so I usually just 'git merge rawhide' in other branches... what's the support status of rpmautospec for EPEL? Last time I tried, it wasn't working in EPEL8.
Mattia
On Fri, 30 Dec 2022 at 19:02, Ben Cotton bcotton@redhat.com wrote:
Version: 1.2.3 Release: %autorelease %autochangelog
I tied this on a package this morning and got:
BuildError: Error running GIT command "git clone -n https://src.fedoraproject.org/rpms/fwupd.git /var/lib/mock/f38-build-40111175-4953952/root/chroot_tmpdir/scmroot/fwupd", see checkout.log for details
The page is here if that helps: https://koji.fedoraproject.org/koji/taskinfo?taskID=95738071 -- this is from a "git push && fedpkg build" from the main branch. Any ideas?
Richard.
* Richard Hughes:
On Fri, 30 Dec 2022 at 19:02, Ben Cotton bcotton@redhat.com wrote:
Version: 1.2.3 Release: %autorelease %autochangelog
I tied this on a package this morning and got:
BuildError: Error running GIT command "git clone -n https://src.fedoraproject.org/rpms/fwupd.git /var/lib/mock/f38-build-40111175-4953952/root/chroot_tmpdir/scmroot/fwupd", see checkout.log for details
That log says:
| $ git clone -n https://src.fedoraproject.org/rpms/fwupd.git /var/lib/mock/f38-build-40111175-4953952/root/chroot_tmpdir/scmroot/fwupd | Cloning into '/var/lib/mock/f38-build-40111175-4953952/root/chroot_tmpdir/scmroot/fwupd'... | error: RPC failed; curl 16 Error in the HTTP2 framing layer | fatal: the remote end hung up unexpectedly
So maybe an unrelated issue? I mean, at this point the system won't even know that the package uses rpmautospec.
Thanks, Florian
On Tue, 3 Jan 2023 at 13:46, Florian Weimer fweimer@redhat.com wrote:
BuildError: Error running GIT command "git clone -n https://src.fedoraproject.org/rpms/fwupd.git /var/lib/mock/f38-build-40111175-4953952/root/chroot_tmpdir/scmroot/fwupd", see checkout.log for details
| fatal: the remote end hung up unexpectedly So maybe an unrelated issue? I mean, at this point the system won't even know that the package uses rpmautospec.
You're correct indeed, thanks. It seems to be a spurious error. The package is building happily now.
Richard.
I have just realized, that the rpmautospec is not documented in the guidelines (unless my search-fu is failing me). Therefore I consider it strange that we should go from "no documentation at all" to "use it by default". I don't think this is right.
IOW why is it not documented yet as an optional feature?
Vít
Dne 30. 12. 22 v 20:01 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
== Owner ==
- Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
- Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec| The spec file contains:
<pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre>
Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }}
Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.)
== Feedback ==
- Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section.
== Benefit to Fedora == Various packaging workflows become smoother for packagers and contributors:
- packagers don't need to touch the `Release` field on updates
- packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
- patches to the spec file can be cherry-picked between branches
without trivial conflicts
- pull requests on src.fedoraproject.org can be merged without trivial conflicts
- in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
- Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... 0.3.1 was released on November 17th, and should be deployed to production in about two weeks])
- Other developers:
** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?)
- Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented.
- Related work
** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning ** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_...
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway.
== How To Test ==
- Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers restart at `-1`.
- Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`).
Do builds in koji. Verify correctness of version-release and the changelog.
For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
- Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly.
== User Experience == No changes visible to end users.
== Dependencies == None.
== Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation.
- Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
- Contingency deadline: Any time.
- Blocks release? No.
== Documentation == This page and any changes to Packaging Guidelines and other documents.
== Release Notes == Not needed.
On Fri, Feb 3, 2023 at 6:27 PM Vít Ondruch vondruch@redhat.com wrote:
I have just realized, that the rpmautospec is not documented in the guidelines (unless my search-fu is failing me). Therefore I consider it strange that we should go from "no documentation at all" to "use it by default". I don't think this is right.
IOW why is it not documented yet as an optional feature?
Well ... because nobody has submitted any proposal of documenting this to the Packaging Guidelines?
I put it on my TODO list to write up rpmautospec documentation for the Packaging Guidelines a while ago ... but TODO list keeps growing and less important things keep getting pushed to the bottom of the list. :)
Fabio
I have just learned the hard way that `fedpkg import` does not work with `rpmautospec` and that is show stopper for me. I have reported ticket here:
https://pagure.io/rpkg/issue/655
And won't try rpmautospec again until this is resolved.
Vít
Dne 30. 12. 22 v 20:01 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
== Owner ==
- Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
- Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec| The spec file contains:
<pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre>
Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }}
Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.)
== Feedback ==
- Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section.
== Benefit to Fedora == Various packaging workflows become smoother for packagers and contributors:
- packagers don't need to touch the `Release` field on updates
- packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
- patches to the spec file can be cherry-picked between branches
without trivial conflicts
- pull requests on src.fedoraproject.org can be merged without trivial conflicts
- in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
- Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... 0.3.1 was released on November 17th, and should be deployed to production in about two weeks])
- Other developers:
** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?)
- Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented.
- Related work
** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning ** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_...
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway.
== How To Test ==
- Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers restart at `-1`.
- Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`).
Do builds in koji. Verify correctness of version-release and the changelog.
For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
- Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly.
== User Experience == No changes visible to end users.
== Dependencies == None.
== Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation.
- Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
- Contingency deadline: Any time.
- Blocks release? No.
== Documentation == This page and any changes to Packaging Guidelines and other documents.
== Release Notes == Not needed.
On Mon, Feb 6, 2023, 12:44 Vít Ondruch vondruch@redhat.com wrote:
I have just learned the hard way that `fedpkg import` does not work with `rpmautospec` and that is show stopper for me. I have reported ticket here:
I ran into this myself and found its a bit less of an issue than it seems. If you build the srpm with mock, the srpm will work with fedpkg import.
Confusingly, srpms resulting from fedpkg mockbuild are not built with mock, but with rpmbuild directly, which results in this error.
And won't try rpmautospec again until this is resolved.
Vít
Dne 30. 12. 22 v 20:01 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
== Owner ==
- Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
- Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec| The spec file contains:
<pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre>
Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }}
Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.)
== Feedback ==
- Thread on fedora-devel in August 2022:
[
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section.
== Benefit to Fedora == Various packaging workflows become smoother for packagers and
contributors:
- packagers don't need to touch the `Release` field on updates
- packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
- patches to the spec file can be cherry-picked between branches
without trivial conflicts
- pull requests on src.fedoraproject.org can be merged without trivial
conflicts
- in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
- Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
0.3.1 was released on November 17th, and should be deployed to production in about two weeks])
- Other developers:
** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?)
- Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented.
- Related work
** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
- Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
- Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning **
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_...
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
== Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway.
== How To Test ==
- Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers restart at `-1`.
- Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`).
- Do builds in koji. Verify correctness of version-release and the
changelog.
- For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
- Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly.
== User Experience == No changes visible to end users.
== Dependencies == None.
== Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation.
- Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
- Contingency deadline: Any time.
- Blocks release? No.
== Documentation == This page and any changes to Packaging Guidelines and other documents.
== Release Notes == Not needed.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On pátek 30. prosince 2022 20:01:55 CEST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
While on it, could we please make %changelog optional?
Packaging become an automatized task, and maintainers don't pay attention to %changelog beauty so they simply generate it from git-log (but I'd claim that git-log != %changelog). Seems that %changelog become one of the most painful maintainers' headache :)
What do you think about a static changelog like:
%changelog * See https://src.fedoraproject.org/rpms/<PKG>/commits/rawhide
Aren't we ready to admit (something like) this is enough?
Pavel
On úterý 24. října 2023 0:31:49 CEST Pavel Raiskup wrote:
On pátek 30. prosince 2022 20:01:55 CEST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
While on it, could we please make %changelog optional?
Whooops! My INBOX got reordered, and it is obvious it is too late for me :-) sorry for bumping this old thread (I have just been dealing with autospec on multiple levels recently so I thought this thread was also relevant).
Packaging become an automatized task, and maintainers don't pay attention to %changelog beauty so they simply generate it from git-log (but I'd claim that git-log != %changelog). Seems that %changelog become one of the most painful maintainers' headache :)
What do you think about a static changelog like:
%changelog * See https://src.fedoraproject.org/rpms/<PKG>/commits/rawhideAren't we ready to admit (something like) this is enough?
Pavel
I'll bite :). I changed the subject accordingly.
On Tue Oct 24, 2023 at 00:31 +0200, Pavel Raiskup wrote:
Packaging become an automatized task, and maintainers don't pay attention to %changelog beauty so they simply generate it from git-log (but I'd claim that git-log != %changelog).
I tend to agree. A package's git log and %changelog have different purposes and cater to different audiences. The former focusses on developers. Each commit should each contain a single logical change to the code in distgit (specfile/patches/sources) with body text to justify the change as appropriate. The %changelog is a user-visible summary that should only mention user-visible changes and not have extra information related to the development itself. For simpler packages, combining these two logs via rpmautospec (with the ability to [skip changelog] commits) can work well, but in other cases, including every single commit message can create a %changelog full of garbage or otherwise confuse packagers.
%changelog become one of the most painful maintainers' headache :)
What do you think about a static changelog like:
%changelog * See https://src.fedoraproject.org/rpms/<PKG>/commits/rawhideAren't we ready to admit (something like) this is enough?
The %changelog is supposed to follow a specific format, as per the guidelines, and the datestamps are used to set $SOURCE_DATE_EPOCH. Replacing the entire changelog with this type of text would break that, and I think having a (potentially flawed) %changelog generated from the git log is better than none at all.
On Mon, Oct 23, 2023 at 11:05 PM Maxwell G maxwell@gtmx.me wrote:
I'll bite :). I changed the subject accordingly.
On Tue Oct 24, 2023 at 00:31 +0200, Pavel Raiskup wrote:
Packaging become an automatized task, and maintainers don't pay attention to %changelog beauty so they simply generate it from git-log (but I'd claim that git-log != %changelog).
I tend to agree. A package's git log and %changelog have different purposes and cater to different audiences. The former focusses on developers. Each commit should each contain a single logical change to the code in distgit (specfile/patches/sources) with body text to justify the change as appropriate. The %changelog is a user-visible summary that should only mention user-visible changes and not have extra information related to the development itself. For simpler packages, combining these two logs via rpmautospec (with the ability to [skip changelog] commits) can work well, but in other cases, including every single commit message can create a %changelog full of garbage or otherwise confuse packagers.
%changelog become one of the most painful maintainers' headache :)
What do you think about a static changelog like:
%changelog * See https://src.fedoraproject.org/rpms/<PKG>/commits/rawhideAren't we ready to admit (something like) this is enough?
The %changelog is supposed to follow a specific format, as per the guidelines, and the datestamps are used to set $SOURCE_DATE_EPOCH. Replacing the entire changelog with this type of text would break that, and I think having a (potentially flawed) %changelog generated from the git log is better than none at all.
I'm also generally opposed to dropping the changelog since it is the main method of providing attribution to all contributors past and present to a package when it is redistributed, especially over the mirror networks, ISOs, etc.
Remember that our version control system *does not matter* because it's not how sources are *actually* delivered. That's the SRPMs that are built and shipped alongside the binary packages.
-- 真実はいつも一つ！/ Always, there's only one truth!
-
Ben Cotton -
Chuck Anderson -
Dan Horák -
Diego Herrera -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Florian Weimer -
Jiri Konecny -
Josh Boyer -
Kalev Lember -
Kevin Fenzi -
Kevin Kofler -
Leigh Scott -
Mattia Verga -
Maxwell G -
Maxwell G -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Neil Hanlon -
Otto Liljalaakso -
Pavel Raiskup -
Peter Robinson -
Petr Pisar -
Rahul Sundaram -
Richard Hughes -
Richard Shaw -
Stephen Smoogen -
Todd Zullinger -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek