6:18 a.m.
Hello everybody,
it's been almost a year that rpmautospec was released in production on
Koji builders and its about time for an update. Last week I released
version 0.2.6 as a Fedora package and deployed it to Koji in staging
infra for testing meanwhile.
So, if you use rpmautospec in your package, please test this new
release extensively before we put it into production, using the staging
package repositories and `fedpkg-stage`. I want to catch any
regressions that this new release might have introduced – some of the
changes required substantial refactoring of how changelogs are
generated, and while everything held up well in my own tests, I'll feel
safer deploying into production if a couple more people put this to the
test with their own packages. Thanks!
Here are the highlights of this new release, I'll link the
corresponding tickets because they contain much detail that doesn't fit
into this mail.
* Affecting Koji builds
* Enable longer changelog entries.
https://pagure.io/fedora-infra/rpmautospec/issue/189
https://pagure.io/fedora-infra/rpmautospec/issue/224
Previously, only the subject line of a git commit log was used for the
RPM changelog as one bullet point. Now you can continue this bullet
point in the body by starting it with an ellipsis ("…", "...")
and/or
add more bullet points simply by prefixing them with a dash.
E.g. this git commit log …:
--- 8< ---
This is a pretty detailed entry, therefore it
... won't fit into the 50 characters of a commit subject.
- And here's another bullet point.
Some details that will be ignored.
Signed-off-by: Nils Philippsen <nils(a)redhat.com>
--- >8 ---
… would become this RPM changelog:
--- 8< ---
* Fri May 13 2022 Nils Philippsen <nils(a)redhat.com>
- This is a pretty detailed entry, therefore it won't fit into the 50
characters of a commit subject.
- And here's another bullet point.
--- >8 ---
This can be tested by building a package with such normally using the
`fedpk
* Handle removed changelog file better (e.g. when bringing a package
back from retirement).
https://pagure.io/fedora-infra/rpmautospec/issue/210
* Don’t trip over gaps in epoch-versions (e.g. if the spec file is
missing or can’t be parsed).
https://pagure.io/fedora-infra/rpmautospec/issue/237
* Relevant for local use (i.e. doesn't need deployment into production,
only the 0.2.6 version installed locally)
* Add rpmautospec convert command which converts a package repository
to using %autorelease and %autochangelog (thanks to Elliott Sales de
Andrade).
https://pagure.io/fedora-infra/rpmautospec/issue/201
* Don't use localized dates in changelog entries.
https://pagure.io/fedora-infra/rpmautospec/issue/104
* Cope better with spec files outside of git repositories.
https://pagure.io/fedora-infra/rpmautospec/issue/214
Cheers,
Nils
--
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
7:26 a.m.
It works for me and really like this new approach. Switched couple of my packages and no
issue so far with rpmautospec itself. But some 3rd-party tools requires some work and
adaption. For example if you already switched to rpmautospec format and try to:
$ fedpkg import foo.fc36.src.rpm
then your changlog file will be removed:
Removing no longer used file: changelog
9:14 a.m.
On Fri, May 13, 2022, at 06:18, Nils Philippsen wrote:
* Relevant for local use (i.e. doesn't need deployment into
production,
only the 0.2.6 version installed locally)
* Add rpmautospec convert command which converts a package repository
to using %autorelease and %autochangelog (thanks to Elliott Sales de
Andrade).
https://pagure.io/fedora-infra/rpmautospec/issue/201
* Don't use localized dates in changelog entries.
https://pagure.io/fedora-infra/rpmautospec/issue/104
* Cope better with spec files outside of git repositories.
https://pagure.io/fedora-infra/rpmautospec/issue/214
These are really handy for me. Thank you! 🎉
--
Major Hayden
3:34 p.m.
On Friday, May 13, 2022 10:45:55 AM CDT Artem Tim wrote:
Does rpmautospec compatible with EPEL-9, EPEL-8 branches?
Not currently. There has been an effort[0] to get it branched for epel9, but it has
stalled. I submitted a PR[1] to make it work, but it has not yet been reviewed.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=2031940
[1]: https://src.fedoraproject.org/rpms/python-rpmautospec/pull-request/1
I don't think there has been any work to get it on epel8. I tried building it[2] and
there were test failures.
[2]: https://koji.fedoraproject.org/koji/taskinfo?taskID=87008299
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
6:49 a.m.
Hi,
On Fri, 2022-05-13 at 15:45 +0000, Artem Tim wrote:
Does rpmautospec compatible with EPEL-9, EPEL-8 branches?
do you mean if you can use rpmautospec features on packages with
epel8/9 branches, or if you can use the command line tool?
You can definitely use %autorelease/%autochangelog in whatever package
you build in Fedora Koji (right now the new features and fixes aren't
installed in prod instances though). It doesn't matter what branch you
build for, only that the builder itself has the rpmautospec plugin
installed and set up.
Rpmautospec isn't compatible with the version of pygit2 currently
available in EPEL8, and I haven't gotten around to fixing that yet (I
seem to recall I had green lights on bumping that though, but that's
not something I'll attempt on a Sunday before having had lunch without
verifying it first!). The only thing blocking a build for EPEL9 was the
unavailability of python-pytest-xdist, and that's only an optional BR
(which will speed up tests if available and used). I've dropped that BR
there and packages are building at the moment.
Hope that helps,
Nils
--
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
7:06 a.m.
Hi!
On Fri, 2022-05-13 at 15:34 -0500, Maxwell G via devel wrote:
On Friday, May 13, 2022 10:45:55 AM CDT Artem Tim wrote:
> Does rpmautospec compatible with EPEL-9, EPEL-8 branches?
Not currently.
This may be wrong, depending on how the question is meant. 🙂
You can use %autorelease/%autochangelog in any packages built on Fedora
Koji (the new features/fixes haven't hit the prod instances yet). It
only matters that the package is available and installed on the build
machines, not in the build roots.
There has been an effort[0] to get it branched for epel9, but it has
stalled. I submitted a PR[1] to make it work, but it has not yet been
reviewed.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=2031940
[1]:
https://src.fedoraproject.org/rpms/python-rpmautospec/pull-request/1
I've unfortunately had little, only spotty capacity for working on
rpmautospec in the past months, sorry! I've fixed the build for
EPEL9[0] …
I don't think there has been any work to get it on epel8. I
tried
building it[2] and there were test failures.
[2]: https://koji.fedoraproject.org/koji/taskinfo?taskID=87008299
… and having it in EPEL8 could be possible if we can get pygit2 bumped
to a current version (which I think we can but will have to verify
beforehand, but not on a Sunday 😉).
Cheers,
Nils
[0]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3c4efd0b6a
--
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
1:57 a.m.
do you mean if you can use rpmautospec features on packages with
epel8/9 branches, or if you can use the command line tool?
You can definitely use %autorelease/%autochangelog in whatever
package you build in Fedora Koji
I had to clarify this, yes i mean can i build packages with rpmautospec features for such
branches. So even building for EPEL-7 in Koji possible. Great. Thanks for answer!
2:06 a.m.
May 15, 2022 7:06:51 AM Nils Philippsen <nils(a)redhat.com>:
It
only matters that the package is available and installed on the build
machines, not in the build roots.
Yeah, I'm aware. I just wasn't sure about
local builds. I know it won't work at all on an EL host, but what about EPEL
mockbuilds run on a Fedora host?
--
Maxwell G
Pronouns: He/Him/His
gotmax(a)e.email
3:59 a.m.
On Mon, 2022-05-16 at 07:06 +0000, Maxwell G via devel wrote:
May 15, 2022 7:06:51 AM Nils Philippsen <nils(a)redhat.com>:
> It
> only matters that the package is available and installed on the
> build
> machines, not in the build roots.
Yeah, I'm aware. I just wasn't sure about local builds. I know it
won't work at all on an EL host, but what about EPEL mockbuilds run
on a Fedora host?
`fedpkg mockbuild` builds an SRPM on the host before building the
package in the mock buildroot, that's supposed to work regardless of
the target.
Nils
--
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
5:47 a.m.
On Fri, 2022-05-13 at 12:26 +0000, Artem Tim wrote:
It works for me and really like this new approach. Switched couple
of
my packages and no issue so far with rpmautospec itself. But some
3rd-party tools requires some work and adaption. For example if you
already switched to rpmautospec format and try to:
$ fedpkg import foo.fc36.src.rpm
then your changlog file will be removed:
Removing no longer used file: changelog
I haven't seen the SRPM in question but have a hunch what happens –
assuming you created the SRPM using `fedpkg srpm`, then attempted to
import it into the same package repository. If that's the case, then
this is – while unintuitive – “working as designed”:
Running `fedpkg srpm` makes a SRPM which is buildable by plain RPM (no
need for rpmautospec) out of the spec file, patches, etc. This adds a
header to the spec file and replaces %autorelease/%autochangelog so
they expand to their final values and doesn't contain the changelog
file (which would be useless at this point)… and this is what gets
imported into the repository _replacing_ all the files already in there
(including `changelog`).
Makes sense?
Nils
--
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
726
days inactive
729
days old
10 comments
4 participants
participants (4)
-
Artem Tim -
Major Hayden -
Maxwell G -
Nils Philippsen