https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog…
== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
technical level
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-…
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
accordingly.
To get beautiful changelogs, you also need to add
<pre>
%buildsys_name Your name
%buildsys_email Your email
</pre>
in ~/.rpmmacros
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macro…
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net.
Local time information (via. uitime):
================= Day: Thursday ==================
2019-08-15 09:00 PDT US/Pacific
2019-08-15 12:00 EDT --> US/Eastern <--
2019-08-15 16:00 UTC UTC
2019-08-15 17:00 BST Europe/London
2019-08-15 18:00 CEST Europe/Berlin
2019-08-15 18:00 CEST Europe/Paris
2019-08-15 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2019-08-16 00:00 HKT Asia/Hong_Kong
2019-08-16 00:00 +08 Asia/Singapore
2019-08-16 01:00 JST Asia/Tokyo
2019-08-16 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
= Followups =
#topic #902 Cleanup & enhance spec files
.fpc 902
https://pagure.io/packaging-committee/issue/902
#topic #904 Caret versioning
.fpc 904
https://pagure.io/packaging-committee/issue/904
#topic #907 Which %__foo macros for executables are acceptable?
.fpc 907
https://pagure.io/packaging-committee/issue/907
#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909
#topic #914 Automatic R runtime dependencies
.fpc 914
https://pagure.io/packaging-committee/issue/914
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
Hello,
I'm having a problem I don't understand how to fix, and I would
appreciate some guidance. I'm maintaining nagios-plugins, which bundles
a number of different "check" plugins and has some metapackages that
include different subsets of those check plugins.
In the EL 8.2 release cycle, one of the dependencies of one of those
plugins was moved from EPEL into EL proper, which broke new installs of
that plugin and the -all metapackage. A user filed a bug, so as a
temporary workaround, I stopped building the plugin package with that
dependency (nagios-plugins-ssl_validity, and had that version
(nagios-plugins-2.3.3-3) obsolete the ssl_validity plugin, since leaving
it around caused it to want to keep the base package in conflict with
other packages that were upgrading.
Now that CentOS 8.2 is released, and the dependency is available, I've
issued an update
(https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-70bcfe5382)
that builds ssl_validity again, and also adds it back to the -all
subpackage. I can upgrade it sucessfully (which installs the
ssl_validity plugin again, as expected), but subsequent calls to dnf
upgrade give this error:
Obsoleting Packages
nagios-plugins.x86_64 2.3.3-3.el8 epel
nagios-plugins-ssl_validity.x86_64 2.3.3-4.el8 @epel-testing
nagios-plugins 2.3.3-3 is not installed anymore, and there are no
explicit Obsoletes: in the ssl_validity package. I'm not sure what
needs to be done here, but whatever it is I'm willing to make the
change. Also wondering if this is expected behavior.
Thanks,
Marty
Hi,
I want to pass a runtime argument while installing a rpm .
say like rpm -ivh sample. rpm "hello".
I want to read the argument and make use of it while installing it.
Any help would be appreciated.
Regards,
Mohan
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macro…
== Summary ==
redhat-rpm-config will be updated to add patching support to forge
macros, a plug-able framework to register macros to execute in
specific sections, and rpm changelogs in detached files.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (users of forge, fonts and go macros).
It was driven first, by the need to make the underlying macro
infrastructure robust enough to package Go modules, and second, by an
unfortunate rpm 4.15 regression that proved it was foolish to depend
on rpmbuild to parse Tags in anything except canonical order.
=== Forge ===
* forge macro now process patches, including in multi-source spec
files, in a natural way
* all dependencies on source/patch numbering were eradicated, you can
write a whole multi-source/multi-patch spec without worrying about
source or patch numbers
* zero suffix is no longer special (à la Source/Source0 way), you can
declare forge blocks starting at 42 if that‘s your preference
=== Fully automated packaging ===
A framework was added so macro subsystems can register execution
blocks in specific parts or the spec file. Execution blocks are
orchestrated (using KISS rules) so for example the forge part of %prep
is executed before the go parts that depend on forge archives being
unpacked and patched, and macros that want to create srpm headers are
executed before macros that want to create subpackage headers.
Such a framework is a requirement to control the generation order
within the spec file and make sure rpm maintainers are not cross with
you.
That means a spec with no special custom processing is reduced to a
set of %global control variables that activate specific execution
blocks, and everything bellow those control variable is short and
unchanging boilerplate.
A packager that needs custom processing can add custom code above or
bellow the various `%auto_foo` calls, and check with `rpmspec -P` that
the result does what he wants it to do. For obvious reliability
reasons injecting custom code in the middle of an `%auto_foo` sequence
is not allowed.
<pre>
%global source_name …
%global source_release …
%global source_post_release …
%global forge_url0 …
%global forge_commit0 …
%global forge_url1 …
%global forge_tag1 …
%global go_module33 …
%global go_description33 …
%global font_family22 …
%global font_conf22 …
%auto_init
%auto_pkg
%sourcelist
%auto_sources
%patchlist
%auto_patches
%prep
%auto_prep
%generate_buildrequires
%auto_generate_buildrequires
%build
%auto_build
%install
%auto_install
%check
%auto_check
%auto_files
%changelog
%auto_changelog
</pre>
=== Detached changelogs ===
This framework was used to implement detached rpm changelogs in a reliable way.
=== Generic -doc creation ===
This framework was used to implement automated -doc subpackage
creation, because creating them by hand gets annoying after the nth
upstream that wants you do distribute heavy PDF documentation files.
=== Huge refactoring and fleshing out of the lua library ===
Writing high-level features like the above required defining a library
of lua routines like an expand that expands fully, an unset that
actually undefines, a read that tells you if a variable exists or is
set to "", a `fedora.echo()` wrapper around
`rpm.expand("%{echo:%{expand:" .. text .. "}}")`, etc. Those are now
available for others to use should they want to.
My coding skills are not up to navigating the upstream low level rpm
lua API without blowing up on the landmines it is littered with.
Therefore, I abstracted landmine avoidance in a single place.
=== Drawbacks ===
Nothing is free, and a higher level of automation required using rigid
naming for control variables. Because software is a lot less tolerant
of fuzzy naming than human beings.
So, all forge control variables are renamed, fonts control variables
have been renamed too, and go control variables will need renaming (in
that last case, that’s not a problem because moving to go modules
requires reworking variables anyway, so it will be done as part of the
module effort in F34).
To ease the transition a compatibility layer was added to forge macros
so old variables and new variables are aliased both ways (this will
eventually go away because it’s quite a lot of compatibility code to
maintain). Mixing syntaxes (old and new) is not supported, you need to
convert your spec file to new forge variables or not at all (if not at
all, do not try to use new features like patching).
== Benefit to Fedora ==
Spec files that do more with less manual expensive to maintain spec code.
Without this productivity win, complex efforts like converting Fedora
Go packages to Go modules, or draining the Font packages swamp given
that legacy formats are no longer supported by apps, are not possible
with the current level of Fedora manpower.
== Scope ==
* Proposal owners:
The core of the feature is done and tested (and retested). It may
evolve during the redhat-rpm-config merge process.
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95
* Other developers:
The way current forge macros call forge macros will need a little
patching once the change lands. For other packagers, there should be
no change except a warning in rpm build logs to switch to the new
syntax before the compatibility layer is removed.
* Release engineering: https://pagure.io/releng/issue/9565
* FPC: https://pagure.io/packaging-committee/issue/997
* Policies and guidelines:
Forge guidelines will need some rework (mostly simplification,
because the new syntax is both more powerful and more regular).
For the average packager, the new syntax is the same old syntax with
little naming adjustments (for example, %{forgeurl} becomes
%{forge_url}, %forgemeta is subsumed into %auto_init, etc)
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it
is a new Spin), file a ticket ( https://fedorahosted.org/council/ )
requesting trademark approval from the Fedora Council. This approval
will be done via the Council's consensus-based process. -->
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-…
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change depends on a redhat-rpm-config merge by redhat-rpm-config maintainers
== Contingency Plan ==
There is no contingency plan because the redhat-rpm-config merge will
happen or not. If it does not happen, i18n, fonts and Go Changes that
are/were envisioned for F33 or F34 will be postponed indefinitely.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis