Automatic virtual provides for RPM macros?
by Miro Hrončok
Hello,
today at Nest, somebody said "unfortunately, there is no way to tell what
package to install to get a particular RPM macro".
I think that having an RPM provides generator for "rpm-macro(__python3)" or
similar should be a fairly simple exercise.
Would you folks consider that useful?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 months, 4 weeks
RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel...
== 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-aut...
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_mac...
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
9 months, 3 weeks
Thoughts on pyproject-rpm-macros and license files?
by Ben Beasley
I’m aware that pyproject-rpm-macros can handle license files in many
cases[1]:
> %pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-Field field are detected. PEP 639 is still a draft and can be changed in the future.
(I also know that there are some packages where no license file is
marked, or where additional license files are needed, and it’s best to
verify with “rpm -qL -p …” before relying on this feature. That’s not at
issue here.)
In a package review, it was suggested that, even when pyproject_files
includes a license file installed in the dist-info directory and marked
with %license, an explicit installation of the license file with a
relative path, such as
> %license LICENSE.txt
might still be needed—under the theory that the license file is supposed
to be installed in /usr/share/licenses.
The Licensing Guidelines simply say that %license must be used, and
don’t mention /usr/share/licenses[2].
I’m wondering if this question has come up before and if anyone has
insight into whether or not pyproject-rpm-macros’s license file support
is intended to replace manual license file handling.
– Ben Beasley
[1] https://src.fedoraproject.org/rpms/pyproject-rpm-macros
[2]
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
1 year, 5 months
Revisiting header-only packages and noarch
by Ben Beasley
Currently, the packaging guidelines say the following[1] regarding
header-only libraries:
Do not use noarch
It may be tempting to make the header library package noarch, since
the header files themselves are simply text. However, a library should
have tests which should be run on all architectures. Also, the install
process may modify the installed headers depending on the build
architecture. For these reasons, header-only packages must not be
marked noarch.
I’d like to collect feedback on the idea of revising this guidance to
clarify that the *base* package, which in a header-only library package
typically has no %files section and does not produce a binary RPM, must
be arched, but that any subpackages, specifically including the -devel
package, may be noarch.
This would address both of the justifications for the general
prohibition in the guidelines:
- The package will still be built, and any tests executed, on all
architectures so long as the base package is not noarch
- Differences in the installed headers depending on the build
architecture would be detected by koji[2], failing the build
(and thereby indicating the need to drop “noarch”)
However, it would confer the following benefits:
- The vast majority of header-only packages could produce noarch
binary rpms. This would:
* save storage and bandwidth
* be less surprising and confusing to packagers and users, who
normally expect arch-independent content to appear in noarch
packages
I have created a PR[3] on the “atomic-queue” package as an example. In
the associated scratch build, you can see that builds occur on all
architectures, but only a single noarch RPM is produced.
If feedback here is positive, I’ll open a Packaging Draft[4] with
specific proposed text.
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_do_not_use_no...
[2] https://docs.pagure.org/koji/misc/#how-noarch-sub-packages-are-built
[3] https://src.fedoraproject.org/rpms/atomic-queue/pull-request/1
[4]
https://fedoraproject.org/wiki/Packaging_Committee#Step_One:_Draft_Guidel...
1 year, 5 months
Summary/Minutes from today's FPC Meeting (2021-12-09-17 17:00 - 17:55 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 17:00:25 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-12-09/fpc.2021-12...
.
Meeting summary
---------------
* Roll Call (geppetto, 17:00:25)
* Schedule (geppetto, 17:06:41)
*
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
(geppetto, 17:06:44)
* #1132 Mark comments as scriplets for Sources, for automation
(geppetto, 17:07:30)
* LINK: https://pagure.io/packaging-committee/issue/1132 (geppetto,
17:07:31)
* LINK:
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when...
is what we have (tibbs, 17:14:28)
* LINK:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2021-12-02/
(geppetto, 17:35:34)
* Open Floor (geppetto, 17:36:06)
Meeting ended at 17:55:03 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* geppetto (48)
* tibbs (32)
* GwynCieslasheher (16)
* zodbot (12)
* carlwgeorge (10)
* decathorpe (6)
* tstellar (5)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
1 year, 5 months
