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.