Question and (pre)proposal:
Can Fedora converge on a single swap-on-ZRAM implementation, and if
so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by
default in Fedora 33, and the working group needs to pick something
I think it should be zram-generator. It's the most lightweight, can be
included by default distro wide. Without a configuration file, it
doesn't run. Thus, each edition/spin, and even the install
environment, can have their own configuration file, to setup it up
however they want, or not set it up.
I also suspect it's the only one that could be upstreamed to systemd
proper, and just included like many other generators.
Background story and references:
Fedora IoT enables swap-on-ZRAM by default for a long time, and have
no issues. Fedora Workstation WG has been evaluating it for some time,
and wants to enable it by default in Fedora 33. Prior discussions 
(Details will be in a future feature proposal.)
Swap is a basic function, and swap-on-ZRAM is an optimization of a
basic function. Basic things should be understandable by users,
without having different configuration files, and systemd units to
look for, depending on what edition/spin they use, or whether they're
booting installation media, or an installed system. It's confusing.
And they don't co-exist gracefully.
There are three implementations in Fedora . Installation media
(DVD, netinstall, Live) use Anaconda's when the install media is
booted; Live installations include it, but it's disabled. Fedora IoT
has its own variant enabled by default, similar in design and function
to Anaconda's, but differently named systemd unit, configuration file,
and bash scripts used by the systemd unit. There's nothing wrong with
these, but in my estimation they have no chance of being upstreamed to
And there's zram-generator. It works much like any other of the basic
generators for this sort of thing: the gpt-auto-generator, the
fstab-generator, and the cryptsetup-generator. I'm not sure who would
argue we need multiple implementations of these things, with separate
configuration files, in the same distribution.
Hello, Fedora has an approved security policy since September 2018 :
> If a CRITICAL or IMPORTANT security issue is currently open
> against a package, or a security issue of lower severity has been
> open for at least 6 months, four weeks before the branch point a
> procedure similar to long-standing FTBFS will be triggered
> immediately, with 8 weeks of weekly notifications to maintainers and
> subsequent orphaning and then subsequent removal from distribution.
> This applies to all packages, not just leaf.
I have decided to have a look into this, since this has been approved more than
a year ago and nothing ever happened since. Fedora has a very big pile of open
CVE bugzillas .
There are several things I'd like us to consider based on the experience from
the FTBFS policy adjustments  before I go implement stuff:
A. It's easier to **orphan** packages soon, retire later -- this allows the
dependent package owners to notice the breakage and possibly adopt the packages
themselves if needed while gives very little room for "cheating".
B. Getting this done on a certain point in the release schedule is complicated
and requires a lot of planning and focus -- if we miss the window, nothing can
change until the next release. We have missed the window 3 times already.
C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues
have no response time, if you get a new one at a certain point, the package is
immediately treated as problematic, while getting it 1 day later, there is a 6
month period where no action is required.
I'd like to adjust the policy before I go implement some tooling around this.
This is vague proposal of what I think would work easier for both "the
executioner" and the affected maintainers:
1. We automatically send reminders to NEW security bugzillas (as with FTBFS)
2. BZs that remain in NEW state for X reminders: pkg is orphaned
3. BZs that remain not CLOSED for Y months: pkg is retired (with notifications)
Point 2 makes it so that only a couple remaining packages actually need to
survive unfixed to point 3. Hence, point 3 can happen at a certain point in the
schedule with less severe impact of points B and C -- and if we miss the window,
we still have point 1 happening.
The bugzilla reminders are sent every third calendar week (every week is too
Here is an initial (albeit randomly generated) proposal of X and Y:
severity CRITICAL/HIGH MEDIUM LOW
X 2 4 6
Y 2 4 6
Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means
anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan packages
after just 1 reminder.
I've made it so that X always equals to Y and every lower level is +2, to make
it easier to document, understand and remember, however this is not required.
For this example a critical/high CVE would get a reminder every third calendar
week. After two reminders (that is after 3-6 weeks), if still in NEW state,
package is orphaned. The maintainer (and others) still have extra 6 weeks to
If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2
months, but that only happens regularly at a certain point in the schedule.
Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4
reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 months.
With low severity, that is 6 reminders (after 15-18 weeks), retired at a point
if still not CLOSED after 6 months (similarly to the current policy).
Please share your feedback, before I proceed with this to FESCo.
If somebody would be interested in maintaining this procedure, I'd be happy to
hand over that responsibility to anybody who is willing to help.
The idea is to start with semi-automation and have something -- currently we had
hoped for fully automated and we have nothing.
In today's FESCo meeting (03-Feb-2020), we discussed this change proposal.
Being the engineering steering committee, we all had our own ideas and
opinions about what the problem is and how best to approach it. After
discussion, we agreed there are different goals related to this change
proposal and we as a community should agree on the goals and their priorities
before moving on to the implementation details.
The goals identified:
1) Reduce the ISO image size.
2) Improve installation time.
3) Improve image composition time.
We want input from the community on what the main goal should be and
prioritize the rest. For example, is ISO reduction size more important than
improving installation time, for instance? If so, why?
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
In Rust world we package all crates as source code in -devel packages.
Then we use them to build the real applications.
Some time ago, someone noticed that we don't put licenses of those
-devel packages into a resulting RPM with app which is fair.
However, I'm not entirely sure how to properly write the License tag.
What should be there if -devel packages have:
* ASL 2.0
* ASL 2.0 or Boost
* ASL 2.0 or MIT
* (MIT or ASL 2.0) and BSD
* Unlicense or MIT
Is it correct to put License: ISC and MIT and ASL 2.0 and BSD?
So I have several FTBFS bugs most likely from the new gcc being more
pedantic. I understand the bug at a high level but I think it would be nice
if someone who really understood it could perhaps document strategies for
figuring out how to find the right file that needs to be updated and how.
Perhaps a Fedora wiki page for gcc?
For now I don't have a lot of time to deal with it so I'm going to either
have to change the bugs to assigned or let the packages get retired due to
| GenericError: Build already in progress (task 41519706)
I already started "fedpkg build", but it said
Watching tasks (this may be safely interrupted)...
so i interrupted it and restarted "fedpkg build"
What to do ?
COPR builds from SCM are still failing with no visible errors. Does
anyone know how to fix this?
Full build log:
P.S. I cannot even upload SRPM due to its size. COPR throw HTTP 500
error when trying to upload SRPM file >500M.
Vitaly Zaitsev (vitaly(a)easycoding.org)
I've just orphaned rome (Java rss library). Couple of its dependencies have
been removed and I don't have neither the time nor the need to maintain it
Red Hat Eclipse Team