1:01 p.m.
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.o...
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.o...
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_Tutori...
* 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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1:10 p.m.
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton <bcotton(a)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.o...
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.o...
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_Tutori...
* 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!
3:48 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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
3:49 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
4:16 p.m.
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)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!
6:09 p.m.
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
6:49 p.m.
On Fri, Dec 30, 2022 at 9:50 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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?
6:56 p.m.
On Fri, Dec 30, 2022 at 4:50 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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!
2:24 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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...
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:26 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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
2:28 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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
2:29 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:45 a.m.
Il 30/12/22 20:01, Ben Cotton ha scritto:
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
8:07 a.m.
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)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
9:09 a.m.
On Sat, Dec 31, 2022 at 9:07 AM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)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(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
10:16 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
On 31. 12. 22 15:07, Josh Boyer wrote:
On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)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(a)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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:23 a.m.
On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 31. 12. 22 15:07, Josh Boyer wrote:
> On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
>> <zbyszek(a)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(a)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/67142e715e...
[1]: https://github.com/fedora-eln/distrobaker
--
真実はいつも一つ！/ Always, there's only one truth!
10:35 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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#chang...
Zbyszek
10:44 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)redhat.com> wrote:
>
> On 31. 12. 22 15:07, Josh Boyer wrote:
> > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >>
> >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> >> <zbyszek(a)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(a)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/67142e715e...
[1]: https://github.com/fedora-eln/distrobaker
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
12:33 p.m.
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#chang...
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
2:37 p.m.
On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel <
devel(a)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#chang...
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.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
8:10 a.m.
* 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...
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
11:06 a.m.
On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)redhat.com> wrote:
> >
> > On 31. 12. 22 15:07, Josh Boyer wrote:
> > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com>
wrote:
> > >>
> > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> > >> <zbyszek(a)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(a)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/67142e715e...
>
> [1]: https://github.com/fedora-eln/distrobaker
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
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!
1:51 p.m.
On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen <ssmoogen(a)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
2:26 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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#chang...
>
> 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
7:04 p.m.
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
2:38 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
--
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
2:57 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
3:42 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
4:52 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
4:55 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
--
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
6:11 a.m.
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
2:44 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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...
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
3:01 p.m.
On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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...
>
> 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
3:08 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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(a)redhat.com>
wrote:
> > >
> > > On 31. 12. 22 15:07, Josh Boyer wrote:
> > > > On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com>
wrote:
> > > >>
> > > >> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
> > > >> <zbyszek(a)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(a)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/67142e715e...
> >
> > [1]: https://github.com/fedora-eln/distrobaker
>
> 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
>
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
3:28 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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...
> >
> > 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
3:32 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
3:39 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
>>
>> [1]:
>>
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known...
>
> 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.
12:16 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
2:30 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
2:32 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:35 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:49 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:12 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
3:19 a.m.
On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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
6:59 a.m.
On Fri, 30 Dec 2022 at 19:02, Ben Cotton <bcotton(a)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.
7:14 a.m.
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <zbyszek(a)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]
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
7:20 a.m.
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <zbyszek(a)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
7:23 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
7:26 a.m.
On Tue, Jan 3, 2023 at 8:24 AM Dan Horák <dan(a)danny.cz> wrote:
On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <zbyszek(a)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!
7:44 a.m.
* Stephen Smoogen:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
7:46 a.m.
* Richard Hughes:
On Fri, 30 Dec 2022 at 19:02, Ben Cotton <bcotton(a)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
7:56 a.m.
On Tue, 3 Jan 2023 at 08:14, Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
8:11 a.m.
On Tue, 3 Jan 2023 at 13:46, Florian Weimer <fweimer(a)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.
8:50 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen
<ssmoogen(a)redhat.com> wrote:
>
>
> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <zbyszek(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
9:21 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)redhat.com> wrote:
> >
> >
> > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
9:24 a.m.
On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)redhat.com>
wrote:
> > >
> > >
> > > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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!
9:50 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)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(a)redhat.com>
wrote:
>>>>
>>>> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
12:03 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
--
Todd
2:52 p.m.
On Mon, Jan 2, 2023 at 4:43 AM Maxwell G via devel
<devel(a)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
2:54 p.m.
On Mon, Jan 2, 2023 at 5:56 AM Dominik 'Rathann' Mierzejewski
<dominik(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
3:02 p.m.
On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar(a)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
3:27 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
Kalev Lember kirjoitti 3.1.2023 klo 11.19:
On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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_B...
[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101
3:34 p.m.
On Tue, Jan 3, 2023 at 10:27 PM Otto Liljalaakso <otto.liljalaakso(a)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_B...
[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 :)
--
Kalev
4:10 p.m.
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar(a)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:Ma...
--
真実はいつも一つ！/ Always, there's only one truth!
4:15 p.m.
On Tue, Jan 3, 2023 at 5:11 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar(a)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.
>
> [1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf
> [2]:
https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Ma...
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
4:18 p.m.
On Tue, Jan 3, 2023 at 5:10 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar(a)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:M...
--
真実はいつも一つ！/ Always, there's only one truth!
4:34 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
Dan Horák kirjoitti 3.1.2023 klo 15.23:
On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen <ssmoogen(a)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_Tutori...
[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/102
8:04 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
9:24 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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?
9:37 a.m.
On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson <cra(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
9:50 a.m.
Hi
On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson <cra(a)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
10:02 a.m.
On Wed, Jan 4, 2023 at 10:51 AM Rahul Sundaram <metherid(a)gmail.com> wrote:
Hi
On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson <cra(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
10:53 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
1:55 p.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
Neal Gompa kirjoitti 4.1.2023 klo 18.02:
On Wed, Jan 4, 2023 at 10:51 AM Rahul Sundaram
<metherid(a)gmail.com> wrote:
>
> On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson <cra(a)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#com...
[2]:
https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packa...
9:37 p.m.
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
1:16 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
2:29 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:38 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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:
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.
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
3:42 a.m.
* 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:
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.
rpmautospec only works for type Build from DistGit, I think.
Thanks,
Florian
5:55 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:35 a.m.
On Tue, Jan 10, 2023 at 4:39 AM Miroslav Suchý <msuchy(a)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:
>
> 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.
>
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/bui...
--
真実はいつも一つ！/ Always, there's only one truth!
6:52 a.m.
On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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
9:11 a.m.
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
11:47 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:20 p.m.
On Tue, Jan 10, 2023 at 11:48 AM Miro Hrončok <mhroncok(a)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/>
>
> 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.
I didn't realize the fedpkg had grown the ability to do COPR builds. I will
use that from now on.
Thanks,
Richard
11:26 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.o...
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.o...
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_Tutori...
* 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.
11:35 a.m.
On Tue, Jan 10, 2023 at 1:53 PM Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek <zbyszek(a)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
11:37 a.m.
On Fri, Feb 3, 2023 at 6:27 PM Vít Ondruch <vondruch(a)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
5:43 a.m.
New subject: F38 proposal: Rpmautospec by Default (System-Wide Change
proposal)
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.o...
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.o...
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_Tutori...
* 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.
7:26 a.m.
On Mon, Feb 6, 2023, 12:44 Vít Ondruch <vondruch(a)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:
https://pagure.io/rpkg/issue/655
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.o...
> 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.o...
> 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_Tutori...
>
> * 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
5:31 p.m.
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
5:38 p.m.
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/rawhide
Aren't we ready to admit (something like) this is enough?
Pavel
10:05 p.m.
New subject: Optional %changelog (was: F38 proposal: Rpmautospec by Default
(System-Wide Change proposal))
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/rawhide
Aren'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.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
12:09 a.m.
New subject: Optional %changelog (was: F38 proposal: Rpmautospec by Default
(System-Wide Change proposal))
On Mon, Oct 23, 2023 at 11:05 PM Maxwell G <maxwell(a)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/rawhide
>
> Aren'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!
184
days inactive
482
days old
95 comments
32 participants
participants (32)
-
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