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
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:
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.
== 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
* 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
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
To get beautiful changelogs, you also need to add
%buildsys_name Your name
%buildsys_email Your email
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
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
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
I think the process for becoming a packager is really rusty. We currently require to submit a valid package review submission AND to find a sponsor AND to prove them you're able "to convince an existing sponsor-level member that you understand and follow the project's guidelines and processes".
The latest part seems quite subjective to me. Moreover, it's becoming harder and harder for the few sponsors to follow all the requests: look at the approved package submissions list  where a lot of those are stuck waiting for a sponsor.
So, what about moving the sponsorship part to use an entry test? We could setup a standard test with a bunch of questions about the packaging process, the package maintaining process and some flawed .spec files that the applicant should fix.
I don't think we would need an app to run this, just a place from where the applicant can download the test and maybe an email address with limited access to sponsors where the applicant submits their answers.
What do you think?
This is a heads-up that I'm orphaning python-blindspin:
The project is a fork of python-click-spinner, which has recently been
approved: https://src.fedoraproject.org/rpms/python-click-spinner (but
somehow not yet imported)
The fork had very little traction and didn't seem to enhance the upstream
project significantly. Also, it's not used by anything:
[amender@localhost SPECS]$ rpm -q --whatrequires python3-blindspin
no package requires python3-blindspin
The document "What can be packaged" from "Fedora Packaging
Guidelines", in the section "Only one kernel package" , states that
"Fedora allows only a single kernel package; packages containing
alternate kernels are not allowed in the distribution."
While not explicitly stated there, I suspect (please correct me if I'm
wrong) that statement was written with the idea of preventing
alternate kernels that could be used to boot the system. With this
premise in mind, I was wondering if packaging non-bootable kernels
(that is, kernels is a binary format that's not accepted by a
conventional boot loader) would be accepted for packaging.
I'm asking this because I would like to package "libkrunfw" , a
dynamic library that bundles an slightly modified minimalist Linux
kernel. The library doesn't really link against the kernel (in the
sense that it doesn't resolve any symbols nor calls to any of its
code), it just bundles it in a binary format that allows it to be
directly injected in a KVM memory region, so it's quite similar to a
compressed image format, but for a different use case.
"libkrunfw" is consumed by "libkrun" , another dynamic library that
allows programs to acquire virtualization-based process isolation
capabilites. The main user of "libkrun" is "crun", when built with
"--with-libkrun", an OCI runtime used by "podman". When all pieces are
in place, users can easily run containers with virtualization-based
isolation by adding some additional flags to the "podman" command
line. I have a COPR repository with pre-built alternative packages as
a demonstration .
There are a number of reasons why we can't use the kernel that ships
- We carry a small number of patches with minor changes that modify
the behavior of the kernel for this particular use case. Without
them, we can't provide an streamlined UX for running isolated
- We need an aggressive minimalist configuration to reduce the memory
footprint of each container/isolated process.
- We need it to be bundled in a dynamic library, so their contents
are mapped into the process memory, enabling programs to switch
between namespaces without the need to carry the kernel binary with
them. The binary object also needs to be properly aligned to allow
direct injection into the KVM memory region without additional
Given that "libkrunfw" bundles a kernel image that can't be used for
booting the system, would it be acceptable to package it in Fedora?
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-11-12 17:00 UTC in #fedora-meeting-1 on
Local time information (via. uitime):
================= Day: Thursday ==================
2020-11-12 09:00 PST US/Pacific
2020-11-12 12:00 EST --> US/Eastern <--
2020-11-12 17:00 GMT Europe/London
2020-11-12 17:00 UTC UTC
2020-11-12 18:00 CET Europe/Berlin
2020-11-12 18:00 CET Europe/Paris
2020-11-12 22:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2020-11-13 01:00 HKT Asia/Hong_Kong
2020-11-13 01:00 +08 Asia/Singapore
2020-11-13 02:00 JST Asia/Tokyo
2020-11-13 03:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
= Followup Actions =
talk to copr to get config. turned on
talk to releng to get config. turned on
talk to authors again, having a working example might help a lot
#topic Open Floor
look through non-meeting tickets, see if any are stuck/need to be discussed
= Followup Issues =
#topic #907 Which %__foo macros for executables are acceptable?
= Followup Pull Requests =
#topic #pr-814 Add SELinux Independent Policy Guidelines.
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
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.