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
6 months, 2 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
1 year, 1 month
Important changes to software license information in Fedora packages (SPDX and more!)
by Matthew Miller
On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!
New docs site for licensing and other legal topics
--------------------------------------------------
All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:
https://docs.fedoraproject.org/en-US/legal/
Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.
Fedora license information in a structured format
-------------------------------------------------
The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data
This data is then presented in easy tabular format in the
documentation, at:
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------
We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.
Updated licensing policies and processes
----------------------------------------
Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.
New guidance on “effective license” analysis
--------------------------------------------
Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.
When do these changes take effect?
----------------------------------
The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!
Thank you everyone!
-------------------
A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.
Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 year, 1 month
inclusion of kernel module sources in a package
by Zbigniew Jędrzejewski-Szmek
Hi,
this question is for https://bugzilla.redhat.com/show_bug.cgi?id=2099771:
'Review Request: wult - Tool for measuring Intel CPU C-state wake latency'.
The full project consists of user-space tooling and a kernel driver that is under
development. The package wants to include the kernel drivers sources to make it
easier for users to compile the driver on the end-user machine. Is this OK
according to our guidelines?
Zbyszek
1 year, 1 month
Fedora adoption of SPDX ids and changes to packaging guidelines
by Jilayne Lovejoy
Hi Fedora packaging committee,
I see that FESCO has approved the Change Proposal for the adoption of
SPDX ids, moving license lists off wiki to a data repo, and updating the
licensing documentation https://pagure.io/fesco/issue/2799
We are aiming to "go live" with the new Fedora-legal documentation on
Wednesday, July 27th. A key piece of that will be getting the PR to
update the packaging guidelines for license info merged
https://pagure.io/packaging-committee/pull-request/1142
Can someone merge that PR on Tuesday evening or Wednesday morning (US
time)? That way if there are formatting issues, typos, etc, we can try
to get them fixed so everything is live and pretty by Wednesday afternoon.
Thanks!
Jilayne
(sending this here, and made comment in PR)
1 year, 1 month
What way of opting out form a particular Python shebang flag do you prefer?
by Miro Hrončok
Hello Pythonistas, packagers.
In the context of this change:
https://fedoraproject.org/wiki/Changes/PythonSafePath
Python shebangs will have be:
#! /usr/bin/python3 -sP
In order to remove certain flags, packagers have the following tool:
# Unset -s on python shebang - ensure that extensions installed with pip
# to user locations are seen and properly loaded
%global py3_shebang_flags %(echo %py3_shebang_flags | sed s/s//)
Or:
# Don't add -P to Python shebang
# This package only works when /usr/bin is in sys.path
%global py3_shebang_flags %(echo %py3_shebang_flags | sed s/P//)
In the implementation PR, Maxwell suggested a different approach:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/141#com...
Basically, packagers would do something like this:
# Unset -s on python shebang - ensure that extensions installed with pip
# to user locations are seen and properly loaded
%global _python3_shebang_nousersite %{nil}
Or:
# Don't add -P to Python shebang
# This package only works when /usr/bin is in sys.path
%global _python3_shebang_safepath %{nil}
The macro names are not set in stone, it could even be %_python3_shebang_s and
%_python3_shebang_P.
The previous sed-based way would still work and packages that already use it
would not need to change immediately.
Do you consider the macro based approach better (worth it)? And if so, do you
prefer actual flag letters in the macro names, or the verbose names?
Thanks for your input.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 2 months
QEMU info
by Jilayne Lovejoy
Hi all,
As Richard and I go through the legal/licensing related wiki pages,
we've come across some info that is clearly not legal or licensing related.
The info on QEMU (pasted below) is one example. Seems like this would be
more appropriately suited for a page related to technical requirements
for packaging?
I'm not sure where that would be - could someone maybe take the info
below and make sure it gets to a proper location in packaging (or other)
docs??
Thanks!
Jilayne
"QEMU ROMs
Whenever possible, ROMS implementing BIOS or Firmware for QEMU system
targets must be built from source on the intended architecture. However,
in many situations, this is not practical or possible. As a special
exception for those situations where it is not practical or possible,
prebuilt binary ROMS implementing BIOS or Firmware for QEMU system
targets may be included in Fedora Packages, as long as the corresponding
source code is also included in the Source RPM package.?
1 year, 2 months
