There is currently a problem with the networking of various systems in
our Phoenix data-center which houses most of our build systems. The
problem has knocked off most of our x86_64 build systems and several
of our aarch64/arm systems. Builds will take longer to process during
this time and may queue up for the remaining builders.
There is currently no ETA for when recovery will happen but due to end
of the year schedules, it will not happen until early January. If
things worsen we will see what escalation paths or changes can be
Stephen J Smoogen.
I worked with FPL Matthew Miller and our engineering manager Jim
Perrin, among others, to define the various problems we want to solve
in diversifying the Fedora lifecycle. We're seeking review and
feedback from community members. The most salient feedback will be
from those involved in the efforts we describe, but we welcome all
Here's the summary from the page, which proposes we pause the release
after F30 for these efforts:
* * *
Fedora’s singular lifecycle has been in place for almost a decade and
a half. During that time, technology users have changed how they
consume platform and applications. Fedora needs to be more toward the
forefront of these changes. But more importantly, Fedora needs to be
more hospitable to community management of lifecycle.
Currently Fedora can’t scale for more community ownership of the
things we release: (1) Only a few people can build and push out
releases; and (2) we manage releases largely based on that staffing.
The Fedora community should be able to run releases of content
themselves, using tools that work well, with only minimal oversight,
and determine their own schedule for doing so.
This implies a great deal of both redesign and reworking of tools and
processes. To unblock the community, several things need to happen. We
need a faster, more scalable compose to enable CI/CD operations; we
need to automate more testing and quality measures; and we need to
update our delivery tools and processes. We also need to track and
coordinate this work across teams, since it involves collaboration
among Fedora infrastructure, QA, applications, release engineering,
CentOS CI, maintainers, and more.
We should skip the F31 release cycle and leave F30 in place longer in
order to focus on improving the tooling and testing changes. These
tooling changes will improve the overall reliability of Fedora, and
will decrease the manual effort and complexities involved in producing
the distribution artifacts. Although we’ve done this before to make
“editions” happen, the intent is to track this multi-team effort more
actively so we can (1) use the time as well as possible, and (2) give
the work maximum transparency.
* * *
The full page is here, with a set of problems, solutions, and actions
proposed. I invite you to take time to read it in detail:
I also attached that page to the main Lifecycle objective page here,
which was previously approved by the Council:
Rather than try to spin this one email into a thread of doom that
people will give up on reading, I encourage those with feedback to
open a thread for any particular topic. That way the community
discussion should be more useful for all.
I'll collect input and use it both for responses and to help tweak
plans for (hopefully) optimal results. I'm on vacation next week, for
which timing I apologize. But I'll try to look at mail here from time
to time and when I return.
I'm new to the Fedora-project, here is a short introduction. I am a
residing in Finland and a long time Fedore user, since Fedore Core 5. I
Fedora project to package Clojure and Java libraries and programs.
I would like to become a owner of a retired package,
and then package libraries (clojure-spec-alpha, clojure-core-specs-alpha
and clojure-pom-contrib) required to update Clojure to the latest
Apparently, the email that I sent (below) was mis-directed. Sorry for
the mistake. I was advised to send this email to you.
I posted a query to https://ask.fedoraproject.en asking how to communicate
a feature request to the Fedora developers. I was told to send this
email. I have included the detailed request as an attachment to this email.
If this email is misdirected, and you want me use an alternate
communication channel, please email me. Also, if you have any questions,
or if anyone wishes to engage me in a challenging discussion, you are also
welcome to email me.
== Summary ==
The change switches Fedora system default metadata format for full
disk encryption from LUKS1 to LUKS2. It mostly involves cryptsetup
package and Anaconda installer so that both creates new LUKS2
containers by default.
== Owner ==
* Name: [[User:Okozina| Ondřej Kozina]] and [[User:Vponcova | Vendula Poncova]]
* Email: okozina AT redhat DOT com, vponcova AT redhat DOT com
== Detailed Description ==
The LUKS2 is evolution of current LUKS standard for software full disk
encryption. It's enabler for new features: introduces new Argon2 kdf
(alongside current PBKDF2) for keyslots, better support for
auto-activation, support for wrapped key ciphers (paes cipher),
experimental authenticated encryption. Plus coming new features
The LUKS2 format is available and supported since cryptsetup release
2.0.0 (included in Fedora 28).
== Scope ==
* Proposal owners:
Ensure LUKS2 is declared default in upstream (owner is involved in
upstream development). Currently upstream aims for LUKS2 being default
in cryptsetup-2.1 (next release). We can switch it even before
cryptsetup 2.1 release by overriding the default via configuration
switch, but owner would prefer upstream default way.
* Other developers:
Installer (Anaconda & co) should adapt to the change (and create new
LUKS2 containers by default if user selects "encrypted storage" during
* Release engineering: [https://pagure.io/releng/issue/8028 #8028]
** List of deliverables: N/A
* Policies and guidelines:
* Trademark approval: N/A
== Upgrade/compatibility impact ==
There should be none with regard to currently supported Fedora
distributions. Both Fedora 28 and 29 provides cryptsetup-2.0.6 (at
least via updates streams) that is fully compatible with LUKS2 format.
LUKS1 stays to be fully supported even with LUKS2 being new default.
== How To Test ==
Basically there will be two areas to test:
* cryptsetup luksFormat command creates LUKS2 devices by default
* Anaconda installs on LUKS2 devices by default when users selects
"encrypted storage" option.
In general this test plan should not cover bugs related to LUKS2
format itself. Those bugs should be covered by development testsuite
shipped with cryptsetup package.
== User Experience ==
The everyday experience should not be affected by the change in any
way. The basic LUKS2 operations (open, close, add new keyslots, remove
keyslot) is handled via same CLI.
More experienced users gain access to new features with default
installation as stated in detailed description.
== Dependencies ==
Currently only Anaconda installer. It would be inconvenient to install
Fedora (encrypted storage) using different LUKS format by default if
cryptsetup used LUKS2. The contact person is listed among Owners of
== Contingency Plan ==
* Contingency mechanism: Stay with LUKS1 format as default
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? N/A
= Documentation ==
LUKS2 specification document]
Fedora Program Manager