Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26
Final Release Readiness Meeting meeting.
The meeting is going to be held on Thursday, July 6th, 2017 at 19:00
UTC. Please check the [1] link for your time zone.
We will meet to make sure we are coordinated and ready for the Final
release of Fedora 26. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.
You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.
For more information please check the [2] link.
As I will not be available for this meeting, Jaroslav Reznik <jreznik>
will be the moderator. Please contact Jaroslav in case of a need for
additional information.
[1] https://apps.fedoraproject.org/calendar/meeting/6285/
[2] https://fedoraproject.org/wiki/Release_Readiness_Meetings
Thank you for your support,
Regards, Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Samba AD =
https://fedoraproject.org/wiki/Changes/Samba_AD
Change owner(s):
* Alexander Bokovoy <abokovoy AT redhat DOT com>
* Andreas Schneider <asn AT redhat DOT com>
Samba AD is an open source implementation of an Active Directory set
of tools and protocols. It allows Windows clients to be enrolled and
managed using native Windows tools. In addition, Samba AD can serve as
a domain controller for Fedora workstations and servers utilizing
DCERPC, LDAP and Kerberos.
== Detailed Description ==
Samba AD is an implementation of an Active Directory set of tools and
protocols. It is developed and released as part of Samba suite.
Upcoming Samba 4.7 release will contain changes to allow Samba AD to
be built and used with MIT Kerberos. Prior to Samba 4.7 it was
impossible to compile Samba AD with MIT Kerberos. As result, Samba AD
was not packaged in Fedora.
== Scope ==
* Proposal owners:
Samba packages in Fedora already include a stub subpackage samba-dc
that is going to be replaced with a full Samba AD implementation.
Appropriate dependencies are already present in Fedora 27/Rawhide or
will be added together with Samba 4.7 update. This mostly concerns
upgrade of Samba-related libraries: libtevent, libldb, libtdb, and MIT
Kerberos update to support new APIs added to accommodate Samba AD
(already in Rawhide).
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
- https://pagure.io/releng/issue/6869
- We believe no impact to Release Engineering is needed for this change
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Remove SSH-1 from OpenSSH clients =
https://fedoraproject.org/wiki/Changes/Remove_SSH-1_from_OpenSSH
Change owner(s):
* Jakub Jelen <jjelen AT redhat DOT com>
Upstream removes support for SSH-1 protocol and we plan to do the same
in Fedora. The protocol is years obsolete and not even supported in
current default binaries (only in openssh-clients-ssh1 subpackage).
== Detailed Description ==
SSH-1 protocol was introduced more than 20 years ago and is no longer
considered secure. OpenSSH package in Fedora is built without SSH-1
protocol since 2015 (SSH-1 clients are available in
openssh-clients-ssh1 subpackage). OpenSSH upstream plans to remove the
code completely in next release, which prevents us from using this
technique further and remove the support completely (unless there will
be significant demand for compat package).
== Scope ==
* Proposal owners:
Remove subpackage openssh-clients-ssh1 and potentially create
compat-openssh-clients-7.5 package with clients supporting SSH-1
protocol.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
#6867 https://pagure.io/releng/issues/6867
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Modular Server =
https://fedoraproject.org/wiki/Changes/Modular_Server
Change owner(s):
* Langdon White <langdon AT fedoraproject DOT org>
The Modularity Working Group, Factory 2.0, Base Runtime, and Server
Working Group would like to propose using the modular infrastructure
for creating and delivering the Fedora Server Edition for Fedora 27.
While we are still working through some of the kinks leading up to the
release of Fedora 26, we believe that the changes to the
infrastructure and technology implementations will be available with
sufficient time to harden the components in time for the 27 release.
== Detailed Description ==
The modularity effort is fairly well known and significantly more
information may be found on the Modularity Website [
https://docs.pagure.org/modularity/ ] or the YouTube Channel [
https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ ]. In short,
modularity is attempting to disconnect the lifecycle of applications
from 1) each other 2) the operating system while still maintaining the
ease of use of a typical Linux Distro.
This change proposal is to promote the work done in the Boltron
Release (preview container image in advance of the F26 release) to
Fedora mainline through the Fedora Server Edition. We will also be
working with the community to complete the available content for
Fedora Server Edition as modules.
Other edition and spins will not change at this point; users who want
to create a Fedora server (as opposed to capital-S Fedora Server)
without Modularity can use one of these other spins, including the
Fedora Cloud Base image, or else use the "everything netinst".
== Scope ==
* Proposal owners:
The Modularity WG, Factory 2.0, Base Runtime, and Server WG teams all
have contributions to this effort. The work that each team is doing is
significant and wide ranging. We are hoping to:
- collect and incorporate feedback in to the system management
experience of using modules (through dnf)
- modularize a significant amount of the content available for Fedora
Server (focusing on current Server roles)
- define tools and best practices for implementing modules and keeping
them up to date
* Other developers:
- Packagers are already working on modularizing applications;
- the Modularity WG will provide like to support additional package
maintainers in modularizing their applications
* Release engineering:
See [[Changes/ModularRelease]] [
https://fedoraproject.org/wiki/Changes/ModularRelease ]
[ https://pagure.io/releng/issue/6852 ]
* List of deliverables:
This change replaces the Fedora 26 Server release-blocking
deliverables with exactly the same things (DVDs and netinst images)
but delivered via Modularity instead of the traditional process.
Although we want to enable changes to module lifecycles over time, it
is worth noting that this Change Proposal does NOT change the normal
13 month commitment for anything in the release.
* Policies and guidelines:
New guidelines are required, they are currently in Draft state and we
will be collecting feedback to them during the F26 lifecycle for
ratification prior to F27.
- Fedora_Packaging_Guidelines_for_Modules [
https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
]
- Container:Guidelines [ https://fedoraproject.org/wiki/Container:Guidelines ]
At this point there are no changes expected to existing guidelines
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Host and Platform =
https://fedoraproject.org/wiki/Changes/Host_and_Platform
Change owner(s):
* Petr Šabata <contyk AT redhat DOT com>
Host and Platform is an evolution of the Base Runtime module concept
introduced in Fedora 26 Boltron, splitting the minimal system further
into independent modules allowing for greater flexibility when
composing and maintaining the base system.
This change focuses on modular content structure;
[[Changes/ModularRelease]] [
https://fedoraproject.org/wiki/Changes/ModularRelease ] deals with
details regarding modular delivery.
== Detailed Description ==
The end goal of this change is to provide the modular base operating
system content in a way that allows for hardware enablement and
general userspace separation, enabling different update cadence and
life cycles for each of the two parts.
Being the successors of Base Runtime, the two new modules will include
all the content Base Runtime does as well as content from additional
Fedora 26 Boltron modules currently extending it. Additional system
configuration & management services and utilities are expected to be
part of the base system experience, making all the essential content
available for installation from the base level modules that are
enabled by default.
=== Implementation ===
The concept is defined by the following set of objectives and expectations:
* Host and Platform are built and composed as modules, benefiting from
all the modularity pipeline enhancements Factory 2.0 provides and are
distributed with useful module metadata
* The Host part should deliver hardware enablement components such as
the kernel, bootloaders, firmware, possibly additional device drivers
and components closely linked to these
* The Platform part defines the operating system release and includes
various base userspace components ranging from the C library and init
system to system management & deployment tools, container runtime and
possibly several services commonly considered to be part of the base
system experience
* The Host and Platform modules should be independent, making it
possible to run the same Host with different Platforms and vice versa
* Each of the two modules has its own life cycle, update cadence and
versioning scheme
* The Host can only be experienced through the Platform
* The Platform part provides all the content needed to produce
container base images; the Platform can therefore run without the Host
in that scenario
* Both modules are built in a shared, self-hosting buildroot (also
known as the Bootstrap module) providing all the build time
dependencies needed to build the Host and Platform as well as itself
* While independent on the source level, given the shared build
environment the modules' binaries are tightly coupled and the Host
part therefore needs to be built for every supported Platform it's
intended to be distributed with
* The Platform module provides the minimal build environment for
application level modules -- this means that modules built against a
certain version of Platform are built using the Platform compiler;
this doesn't affect what additional compilers are available to the end
users, for example via additional application level modules
=== Modules ===
At minimum the group is going to deliver three modules, one of which
being an implementation detail only that won't be part of the Host and
Platform compose.
* '''The Host''' includes the kernel, bootloaders, firmware, and
components tightly coupled with any of these
* '''The Platform''' includes the C standard library, the init system,
basic system tools, filesystem and networking utilities, system Python
runtime, system management and deployment tools such as dnf and
anaconda, container runtime(s) and possibly additional system services
and components necessary to provide a reasonable base system
environment
* '''The Bootstrap''' module includes a self-hosting package set
needed to build the Host and Platform modules. Host and Platform are
subsets of this module. The binaries are not part of the compose.
This module is also part of Fedora 26 Boltron, defining the buildroot
for Base Runtime and several other modules.
Host and Platform modules might be implemented as simple modules or
module stacks, depending on what provides more practical value. Given
that the content of each will be bound by the same life cycle and
update cadence, we don't expect to split them into sub-units unless
necessary.
The Host module might be a module stack from day one to simplify
packaging of the UEFI bootloader.
The Bootstrap module will be initially created by manually tagging
traditional Fedora binaries into a special purpose, module-like tag.
The module is self-hosting so that it can later rebuild itself, as
well as serve as a base for building future releases, spins, and
derived distributions. Unfortunately it's not possible to build the
new Bootstrap module using the Fedora 26 Boltron version due to the
introduction of a new architecture (s390x) and numerous FTBFS issues.
=== Differences from Base Runtime ===
[[File:Base_Runtime_becomes_Host_and_Platform.png|120px|thumb|right|Base
Runtime becomes Host and Platform]]
Fedora 26 Boltron Base Runtime module was created with a different set
of requirements in mind: it was meant to provide a minimal bootable
environment with hardware enablement, init system, basic system tools
and a minimal package manager. Unlike Host and Platform, Base Runtime
is usable on its own.
Base Runtime is both smaller and larger than Host and Platform -- it
provides the basic functionality of both but the Base Runtime
userspace package set is much smaller than that of the Platform.
== Scope ==
* Proposal owners:
Modularity WG will prepare both modules -- define the generic module
metadata, buildroots, profiles, components and API. The group will
also build the components and will deliver an installer boot image,
container base image and virtual machines built from the Host &
Platform content. The group will also create and maintain additional
modules needed to accomplish these tasks, such as a "self-hosting
buildroot package set" module similar to the one used for building
Base Runtime for Fedora 26 Boltron. The group will assist package
maintainers and release engineering with fixing packaging problems,
component build and module compose issues.
* Other developers:
Package maintainers are expected to fix packaging & build issues
affecting packages they maintain in a timely fashion.
* Release engineering:
#6815 [ https://pagure.io/releng/issue/6815 ]
* List of deliverables:
Modularity & modular compose will be affected.
* Policies and guidelines:
Not needed for this change.
* Trademark approval:
Not needed for this change
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Modular Release =
https://fedoraproject.org/wiki/Changes/ModularRelease
Change owner(s):
* Ralph Bean < rbean AT redhat DOT com >
The build, release, distribution, and update changes associated with
and required for the [Changes/Modular_Server] and
[Changes/Host_and_Platform] Changes.
== Detailed Description ==
=== Preamble ===
This change is intended to cover the workflow and technical tooling
aspects of a “modular” release for F27.
There are other Changes that are not part of the scope of this Change,
but which are related:
* [[Changes/Modular_Server]] is a proposal to replace the Fedora
Server edition with a modular release for F27.
* [[Changes/Host_and_Platform]] deals with the content of what goes
into the core of the modular release for Fedora Server (the Modular
Server) in F27.
This Change is about how we’re going to get those two other changes
through the infra/build/release tooling.
Client tooling is being worked on (I have seen some cool demos from
the May-June timeframe. Ask about them!), but client tooling is not
part of the scope of this Change proposal.
Note that there currently are no proposals to replace either Fedora
Workstation or Fedora Atomic with modular revisions. This means that
here we cannot move to replace existing workflows wholesale, but have
to look at maintaining the two flows (traditional and modular) in
tandem, for at very least the F27 release cycle.
(The [[Changes/ArbitraryBranching]] change is also related to this
proposal, but not covered in any further detail here.)
=== Builds ===
Module builds for the F27 cycle will look much like they did for the
F26 cycle. No major changes here.
See the F26 Change document for details here, [[Changes/ModuleBuildService]]
As soon as the FPC approves the [[Module:Guidelines]], we can open up
the MBS for use by the general packager group.
'''Dependencies:'''
* We need the Modularity team to take the module guidelines to the
FPC, work through them, and get an agreed-upon version approved.
* We are indirectly dependent on release engineering to create some
initial tags for bootstrapping the host and platform content. This
should be referenced in that Change proposal.
=== Automation ===
Ok, I lied. One thing about builds will change: we’re going to
automate rebuilds with [[Infrastructure/Factory2/Focus/Freshmaker]].
==== Module Rebuilds ====
For '''F26''', if a packager wanted to update an rpm in a module, they would:
* Patch the spec file of that rpm, commit, and push.
* Switch to a checkout of the module that included that rpm, and run
`mbs-build submit` which would kick off the appropriate builds.
* If another module included that same rpm stream, and the packager
forgot about it, then they’re just out of luck.
For '''F27''', we’re working on a system to automate this. The
workflow will be:
* Patch the spec file of an rpm, commit, and push.
* Watch the fireworks.
The freshmaker daemon will notice the commit, then look up all modules
that depend on that rpm stream. It will submit requests to the
module-build-service to build those modules.
We won’t have a nice UI for this for F27, but we will have a JSON API
provided by freshmaker to query and find the list of module builds
that were triggered as a result of your commit (or anyone else’s
commits to any other packages).
There are some exceptions here. We will have a site-wide policy
configured for freshmaker to not do automated rebuilds for a
blacklisted set of modules. This blacklist set must include the
bootstrap module. It includes many thousands of rpm streams and an
update to any one of them would cause a mass-rebuild of (nearly) every
other module. This is too much, so we’ll instead rely on the
bootstrap maintainers and release engineering to only request these
rebuilds via MBS by hand.
==== Container Rebuilds ====
We're approaching container rebuilds in two phases: for short hand,
we're calling them the "slow" flow and the "fast" flow. We'll do the
[https://m.rit.edu/default/video/index?feed=youtube-reporter&id=QPHUTRnWrP4
slow flow] first for F27. The fast flow is a stretch goal for F27,
but will more likely land in F28.
In the '''slow flow''', we automatically kick off rebuilds of
containers when rpms that previously went into those containers are
'''shipped to the updates repo in Bodhi'''. The lag time here can be
around a week to two weeks.
Freshmaker will watch on fedmsg to find when those rpms make it to the
master mirror and will kick off the appropriate builds. The container
rebuild process should already be pulling from that repo; so we should
be good to go.
In the '''fast flow''', we automatically kick off rebuilds of
containers when rpms that previously went into those containers are
'''first added to an update in Bodhi'''. The lag time here can be
quite fast. As soon as you make a specfile patch and the rpms get
built, the update can be created which in turns triggers freshmaker to
kick off container rebuilds.
'''fast flow''' container rebuilds require a yum repository with the
rpms to be available ''before'' they are mashed into the updates repo.
For this, we're building [[Infrastructure/Factory2/Focus/ODCS]]. This
"on demand compose service" will be used by freshmaker to produce
repos of rpm and module content for container rebuilds, as well as
taskotron test runs.
No further details on ODCS here, but it does require non-standard
write access to a subtree of /mnt/koji. We will need support from
Fedora Release Engineering and Fedora Infrastructure in the
request-for-resources ticket for this.
'''Dependencies''':
* We’ll need Fedora Infrastructure to kindly support us through the
request-for-resources process.
* We need Fedora Infrastructure to finish implement service-account
support for OpenID Connect (in ipsilon).
* After that, we need to be granted an OIDC service account so that
freshmaker can submit builds to the module-build service.
* The VM for ODCS will need non-standard write access to a subtree of
/mnt/koji (we don't need to write to the whole thing, just a new
/mnt/koji/compose/odcs/ directory where we can write out temporary
composes).
=== Composes ===
We will continue to do general composes with the same tool - pungi.
* For rawhide, the compose configuration should list the master
streams of all modules to be included in the rawhide compose. The
latest builds in those streams will be included in each nightly
compose: https://pagure.io/pungi-fedora/blob/master/f/variants-modular.xml
* For branched, the compose configuration should list f27 streams of
all modules to be included in the F27 server compose. The latest
builds in those streams will be included in each nightly compose.
* For the alpha and beta candidates, release engineering will need to
pin the versions of the module streams in the variants-module.xml file
in the f27 branch of the pungi-fedora repo. This will allow them to
stabilize the release and allow for systematic QA and go/no-go
decisions.
As mentioned in the automation section above, we're introducing a new
tool called the ODCS to generate temporary, throwaway composes for
automated testing and automated layered image creation.
'''Dependencies''':
* The image building work from F26. For F26 "Boltron", we wanted to
produce base images but ran into more issues than expected. Most all
of those are resolved now. Full completion of that work (being able
to produce base images in koji via pungi from modular content) is a
hard requirement for F27, where it was a soft requirement for F26.
* The variants files for F27. The Factory2 team will produce these
and submit them to release-engineering's pungi-fedora repo. Releng
will need to review and eventually merge.
* As the beta cycle unfolds, Release Engineering will need to freeze
the module versions in variants-modular.xml, adding in new versions
only to address blocker bugs (like how we do today with the
f26-compose tag).
=== Updates ===
Updates to the (modular) Fedora Server release will be managed by Bodhi.
Fun facts:
* The Bodhi database model now has multi-type (modular) support.
* The Bodhi API now has multi-type (modular) support.
* The Bodhi bindings and CLI and web UI now have multi-type (modular) support.
The only thing left to do is (take a deep breath) the masher.
See [[Infrastructure/Factory2/Focus/Bodhi]] for how to plan to handle
the '''code changes''' to Bodhi.
As for '''configuration''', we’re going to need to be able to mash
updates for traditional style Fedora Workstation and Fedora Atomic
while also mashing updates for (Modular) Fedora Server.
We will need:
* f27-updates, f27-updates-testing and all the normal associated
-pending and -candidate tags for Workstation and Atomic. The F27
“release” in Bodhi’s database will point at this tags, as per usual.
* f27-modular-updates, f27-modular-updates-testing, and similar kinds
of -pending and -candidate tags for Server. We will then need to
additionally create a separate Modular F27 “release” in Bodhi’s
database that points to those tags.
The masher will produce separate modular-updates and
modular-updates-testing repos alongside the traditional updates and
updates-testing repos.
Note - the work we've already done here paves the way for containers
in Bodhi, but a workflow that has layered image updates passing
through Bodhi is likely not in the cards for F27. Someone will have
to take it up for F28.
'''Dependencies''':
* We need the content generator flags enabled in koji for the MBS (see
https://pagure.io/releng/issue/6799 ).
* We need the tags hierarchy created for modular updates.
* We need the release created in the bodhi DB (for the modular repos)
at the same time that the traditional release is created.
* Release-engineering runs the push command. There will inevitably be
problems with the first iteration of our modularized bodhi masher.
Please work with the Factory2 team to solve them as we move forwards
with the release.
=== Mirrors ===
We don’t expect that mirroring this content will require any changes
to mirrormanager or mirrorlist.
We will be creating an extra compose and an extra set of updates
repos, but there are no fundamental changes to the mirroring process.
We will have an additive increase in load on mirrors, but no an
exponential one.
There has been lots of worry here. Let me explain. Once upon a time,
we thought that (with Modularity) we would distribute every version of
every module ever built. Users could switch between any of them, at
any time, since they would all be available on the mirrors. This
would explode our storage ask of the mirror volunteers.
But, this is not how our modularized bodhi masher will work. We will
distribute multiple streams of the same rpms, but we will not retain
or mirror multiple versions of the same stream. Only the latest
builds of a module stream will be included in the updates repo, not
every version we ever built.
The F27 server compose should go exactly where it would normally go in
the published tree.
The F27 modular-updates repos should sit right next to the traditional
updates and updates-testing repos.
== Scope ==
* Proposal owners:
We have to finish and deploy freshmaker, our bodhi changes, including
changes to pungi. We'll be actively working with the infrastructure
and releng teams on deployment and configuration.
* Other developers:
Is there any work required of other developers? No. They will still be
able to use the "traditional" workflow to build and ship content for
Fedora Workstation and Fedora Atomic. To participate in the
development of Fedora Server, they'll need to learn how to create new
modules (the module guidelines should cover this).
* Release engineering:
ticket #6852 [https://pagure.io/releng/issue/6852]
* List of deliverables:
I don't think anything on this list changes. See [[Changes/Modular_Server]].
* Policies and guidelines:
See [[Changes/Modular_Server]].
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
OVERVIEW
========
As the modularity work starts to enter Fedora with the Fedora 27
release, a typical Change Proposal did not seem to do justice on
capturing the moving parts and dependencies for the work to successfully
land. As a result, this document attempts to capture, at a high level,
the goals and deliverables for F27. We are also providing links to the
details to most aspects. Some of the details are still in progress and
will change over the F26 lifecycle (e.g. which modules will be included
for F27 Server).
THE GOAL
========
The Modularity and Server Working Groups plan, with the help of many
other groups in Fedora, to deliver a fully modularized version of the
Fedora Server Edition. As an equal and complementary goal, the tooling
for module creation/development, deployment and automatic testing will
be as simple and automated as possible.
[*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
CAVEATS
=======
- Although modularity allows for lifecycle changes, there is no plan
for anything besides the normal 13 month lifecycle at this point.
- Available content as modules will be less than a typical Server release
- Only components that are a part of a module will be available
- Any RPM that is a part of module will be available to be
installed directly or in addition to the “install profile” install of
the module
ASPECTS TRACKED
===============
- Infrastructure Changes/Improvements:
- Bodhi: changes to support updating & tracking modules:
[*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
- Arbitrary branching: enables modules to versions bound to
something other than Fedora release number:
[*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
- Bugzilla & ABRT module-awareness are still in progress
- COPR: support for building modules has been added and will be
improved over the F26 cycle
- Automation (Freshmaker)
- On Demand Compose Service (for testing and container rebuilds)
- Greenwave: for policy/gating in Bodhi. User interactions
take place in Bodhi.
- Installation & System Management
- Anaconda: still in progress
- DNF: Work underway to support modules, additional features need
to be added. Please report comments/features/bugs in the [*normal
manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
- Gnome Software: still in progress
- Host & Platform module(s): Base components that provide the
“operating system” aspects of Modular Fedora:
[*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
[*Content tracker*](https://github.com/fedora-modularity/hp)
- Application modules ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking))
- TBD language modules (1 or more versions each)
- TBD database modules (1 or more versions each)
- TBD web server modules (1 or more versions each)
- TBD utility server modules (1 or more versions each)
- Applications as System Containers ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking))
- TBD system integrated containers
- Module Guidelines and Processes:
[*Ticket*](https://pagure.io/Fedora-Council/tickets/issue/123)
- HowTos, Examples, and Tools for Modules:
[*Website*](https://docs.pagure.org/modularity/)
BENEFITS FOR USERS
==================
- Content available in multiple streams - good examples needed
- Software Collections done the right way - Languages, Databases
- No visible change to dnf/yum unless you want to select non-default
versions
FURTHER DETAILS
===============
- [*Bodhi
Milestone*](https://github.com/fedora-infra/bodhi/milestone/4) for
Modularity
- Bodhi Changes [*Focus
document*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Bod…
- Freshmaker Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker)
- ODCS Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS)
- Branching Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching)
Langdon White
Fedora Modularity Objective Lead
= Proposed Self Contained Change: Remove krb5-appl =
https://fedoraproject.org/wiki/Changes/Remove_krb5-appl
Change owner(s):
* Robbie Harwood (rharwood) <rharwood at f p dot o >
Remove src:krb5-appl (produces packages krb5-appl-clients and
krb5-appl-servers) from the distribution.
== Detailed Description ==
These packages will likely be officially deprecated upstream soon, and
probably should not be used in most cases anyway. It contains legacy
kerberized utilities, like rsh. There are no packages which depend
them. There have been no changes to this package in Fedora since 2013,
and no new capabilities upstream since 2010 when it branched from the
mainline krb5 distribution.
== Scope ==
* Proposal owners:
To implement this Change proposal.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/6854
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= System Wide Change: Golang 1.9 =
https://fedoraproject.org/wiki/Changes/golang1.9
Change owner(s):
* Jakub Čajka <jcajka AT redhat DOT com>
Rebase of Golang package to upcoming version 1.9 in Fedora 27,
including rebuild of all dependent packages(pre-release version of Go
will be used for mass rebuild).
== Detailed Description ==
Rebase of Golang package to upcoming version 1.9 in Fedora 27. Golang
1.9 is schedule to be released in Aug/Sep. Due to current nature of Go
packages, rebuild of dependent package will be required to pick up the
changes.
Along with the rebase I do propose to drop ppc64 from Go
architectures(effectively disabling build of all packages adhering to
draft Go packaging guidelines) as ppc64 port of "GC" is not feature
complete(never were) and with Go 1.9 "GC" will be supporting only
Power 8 and up. Due to limitation of the Go port impact should be
fairly limited. Possible alternative could be switch to gccgo, but it
is generally not used by upstreams and less tested than GC and move
will most probably require nontrivial amount of packaging/debugging
work.
== Scope ==
* Proposal owners:
Rebase golang package in f27, help with resolving possible issues
found during package rebuilds. Change Go packaging macros in way that
will drop ppc64 builds.
* Other developers:
fix possible issues with help from golang maintainers
* Release engineering:
As there is scheduled mass-rebuild ( #6853 ), nothing should be required.
* List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Fedora 27 Boost 1.64 upgrade =
https://fedoraproject.org/wiki/Changes/F27Boost164
Change owner(s):
* Jonathan Wakely <jwakely AT fedoraproject DOT org >
This change brings Boost 1.64.0 to Fedora 27. This will mean F27 ships
with a recent upstream Boost release.
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
The equivalent changes for previous releases were Fedora 22 Change and
Fedora 23 Change and Fedora 24 Change and Fedora 26 Change.
https://fedoraproject.org/wiki/Changes/F22Boost158https://fedoraproject.org/wiki/Changes/F23Boost159https://fedoraproject.org/wiki/Changes/F24Boost160https://fedoraproject.org/wiki/Changes/F26Boost163
== Scope ==
* Proposal owners:
- Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
- Request a "f27-boost" build system tag (discussion
http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
): https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost
- Build boost into that tag (take a look at the build #606493 for
inspiration) http://koji.fedoraproject.org/koji/buildinfo?buildID=606493
- Post a request for rebuilds to fedora-devel
- Work on rebuilding dependent packages in the tag.
- When most is done, re-tag all the packages to rawhide
- Watch fedora-devel and assist in rebuilding broken Boost clients (by
fixing the client, or Boost).
* Other developers:
Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: #6851 https://pagure.io/releng/issue/6851
** List of deliverables: All deliverables will include updated Boost packages
* Policies and guidelines:
Apart from scope, this is business as usual, so no policies, no guidelines.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
Change owner(s):
* Vratislav Podzimek <vpodzime AT redhat DOT com>
* Ondrej Kozina <okozina AT redhat DOT com>
Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.
== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.
We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.
For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.
Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.
For rotational devices the cost of enabled discard is negligible
== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.
* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.
* Release engineering:
N/A
* List of deliverables:
N/A
* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= System Wide Change: Separate Subpackage and Source Debuginfo =
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
Change owner(s):
* Mark Wielaard <mjw AT fedoraproject DOT org>
* Neal Gompa <ngompa13 AT gmail DOT com>
Allow to install just the debuginfo for a subpackage and/or without
the source files. The debuginfo packages are huge because they contain
debuginfo and all sources for all subpackages. Being able to install
only the debuginfo for the subpackage that is installed reduces the
size that needs to be downloaded to analyze, trace, profile or debug a
program or core file. Some tracing and profiling tools don't need the
actual source files to provide stack traces or insert probes. So
installing the debugsources should be optional.
== Detailed Description ==
Currently both the .debug files and the source files of all
subpackages are included in a debuginfo package. This creates huge
debuginfo packages with a lot of data that might not be relevant to
the user/developer. By splitting out the sources (found under
/usr/src/debug) and the .debug file for the separate binaries of the
subpackages (under /usr/lib/debug) the amount of data a developer/user
needs to install to trace, profile or debug will be greatly reduced.
Other distributions (notably Suse) already split their debuginfo
packages this way. We will take those patches
(https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsubp…)
and integrate them into rpm upstream. This will involve two steps: -
https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package…
- https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package…
This depends on some of the cleanups introduced by the
ParallelInstallableDebuginfo change.
We can either make this work with the current dnf debuginfo-install
plugin by providing a meta package that matches the main-debuginfo
package which depends on all sub- and source-debuginfo packages. Or we
work with the dnf hackers to make dnf debuginfo-install work with
sub-debuginfo packages.
A couple of packages already have hand-written sub-debuginfo packages
(notably the kernel, glibc and gcc). We will work with those packages
to adopt the new standard approach.
Release engineering needs to be involved to see if any changes are
necessary for adding the sub-debuginfo/debugsources packages to the
repodata.
== Scope ==
* Proposal owners:
Patches against rpm upstream need to be integrated as outlined in the
Detailed Description.
* Other developers:
Upstream rpm and dnf maintainers have to review the proposed patches.
If accepted the package maintainers will have to decide whether those
patches can be backported for the next fedora release. Packages that
now split their debuginfo packages by hand might want to change their
package to adopt the new (standard) approach. Once all changes are in
a package debuginfo needs to be regenerated before it becomes
sub-package/source split.
* Release engineering:
Needs to be discussed. In theory no changes apart from those listed
above are needed. But release engineering might know whether any
changes are necessary for adding the sub-debuginfo/debugsources
packages to the repodata.
* List of deliverables:
N/A (Still Unknown)
* Policies and guidelines:
No changes, the debuginfo related rpm macros won't change. They will
just start producing sub-package debuginfo and debugsources packages
once all changes are in place.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= System Wide Change: Parallel Installable Debuginfo =
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
Change owner(s):
* Mark Wielaard <mjw AT fedoraproject DOT org>
debuginfo packages can be installed in parallel to make it easier to
trace, profile and observe what programs are doing or to debug when
they have crashed. That way debugging, tracing or profiling programs
can be done independent of whether they are 32bit, 64bit, a slightly
newer or older version than currently installed or even from a
different architecture.
== Detailed Description ==
Currently only one version of a debuginfo package can be installed for
a given package. Even on a multi-lib system you cannot install the
64-bit and 32-bit versions of a debuginfo package in parallel
(technically you sometimes can, because of RPM file coloring, the
64bit version of the .debug files win over the 32bit version - causing
lots of confusion). But there are various situation where having
multiple versions of the debuginfo package installed help with
tracing, profiling, debugging and/or crash analysis (see the Benefit
to Fedora section below). There are various things provided by a
debuginfo file that might conflict preventing parallel installation of
different versions:
* build-id file /usr/lib/debug/.build-id/xx/yyyy...yyy which is a
symlink to the main ELF file.
* build-id.debug file /usr/lib/debug/.build-id/xx/yyyy...yyy.debug
which is a symlink to the .debug ELF file.
* The .debug files under /usr/lib/debug/ with file path names
mirroring the main ELF file paths under / with .debug added.
* The source files under /usr/src/debug/<name>-<version>/
They can be made non-conflicting in the following ways:
* The main build-id file should not be in the debuginfo file, but in
the main package (this was always a problem since the package and
debuginfo package installed might not match). If we want to make
usr/lib/debug/ a network resource then we will need to move the
symlink to another location (maybe /usr/lib/.build-id). Unfortunately
this means a change will be necessary for debuginfo consumers to that
depend on the old location. We could keep the old symlink and point it
to the new location to work around it. But I will audit the consumers
to see which depend on it and discuss if we can have a new standard
location.
* build-ids are globally unique identifiers. They will be different
across arches. But might match between minor releases if the exact
same ELF image is produced. The linker will get an option to hash in
the full nvr to make sure all build-ids are always fully unique.
* The .debug file names will be changed to main ELF file
name-vr.debug. This name will also be set in the .gnu_debuglink
section of the main file by changing the options given to eu-strip in
the rpm find-debuginfo.sh script.
* The source files will be moved under
/usr/src/debug/<name>-<version>-<release>.<arch>/. This needs changes
to the rpm debugedit program which rewrites the DWARF source file
information.
These changes will make all files in any debuginfo file unique so they
don't conflict when installed in parallel. There should be no changes
necessary to programs (gdb, perf, valgrind, systemtap,
systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids
or .gnu_debuglink to lookup DWARF debug information and source
references for tracing, profiling and debugging.
It would be good to tweak dnf debuginfo-install to know about parallel
installable debuginfo packages and maybe have an easy option to
install the debuginfo for a core file or for the packages running in a
container.
Alternative solutions currently rejected:
* Move main ELF image build-id file under
/usr/lib/.build-id/xx/yyyy...yyy when moving into main pages. Because
existing programs probably depend on the link being under
/usr/lib/debug/.
* Since when the build-id is identifical also the ELF file is
identical we could mark all build-id.debug files as replacable in the
rpm. It isn't clear that works for symlinks though (but we could
reverse the symlink direction from debug file to build-id file). And
currently you can identify the exact package nvr installed given just
one build-id. That would be impossible if multiple packages could
contain the same build-id/ELF image file.
* Do away with the old .gnu_debuglink way of accessing files under
/usr/lib/debug and just not install .debug files and only support
build-id based debug lookups. Because it isn't clear build-ids are
100% available and all programs work with build-id lookups instead
through .gnu_debuglink names.
* Move the .debug files under a subdir like the sources.
/usr/lib/debug/<name>-<version>-<release>.<arch>/. This cannot easily
be expressed in .gnu_debuglink, which officially only allows a
basename.
== Scope ==
* Proposal owners: Patches have been developed against rpm debugedit
to accept a hash value to seed the build-id calculation, rewrite
source paths (currently source paths can only be smaller, this change
might create larger paths) and the rpm find-debuginfo.sh script to
change the paths, symlinks and .gnu_debuglink names as outlined in the
Detailed Description. And the dnf debuginfo-install plugin might be
patches to provide subcommands for pulling in debuginfo packages found
by build-id in core files and/or programs running in containers.
* Other developers: Upstream rpm and dnf maintainers have to review
the proposed patches. If accepted the package maintainers will have to
decide whether those patches can be backported for the next fedora
release. Once all changes are in a package debuginfo needs to be
regenerated before it becomes parallel installable. (Note most of this
has been done already during the F25 cycle. Only one outstanding patch
is not yet ready.)
* Release engineering: Needs to be discussed. In theory no changes
apart from those listed above are needed. But if we want to support
installing cross-architectures (not just multi-lib arch) debuginfo
then some way needs to be found to get those in the right repodata.
* List of deliverables: N/A (Still Unknown)
* Policies and guidelines: No changes, the debuginfo related rpm
macros won't change. They will just start producing parallel
installable debuginfo packages once all changes are in place.
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
---------- Forwarded message ----------
From: Zuzana Svetlikova <zsvetlik(a)redhat.com>
Date: Mon, Jun 19, 2017 at 5:48 PM
Subject: Node.js v8.x in Fedora
To: devel(a)lists.fedoraproject.org
Cc: nodejs(a)lists.fedoraproject.org
Hi everyone,
as there is nothing stopping us now, the nodejs package in Rawhide will
soon be
updated to Node.js v8.x. It also comes with npm@5 and new V8.
Note that upstream has made a lot of changes and your projects/packages
might have
some issues.
I'll update nodejs in rawhide next week, if you wish to try it out sooner,
it's already built here:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-lts/
Zuzka
Greetings!
Today, on 2017-June-20, we have reached Fedora 27 Change Checkpoint:
Proposal submission deadline (Changes requiring mass rebuild) [1].
At this point, only Changes not requiring mass rebuild will be
accepted for Fedora 27. Any Change Proposal requiring mass rebuild
should be scheduled for a later Fedora release.
System Wide as well as Self Contained Changes not causing a need for
mass rebuild are still accepted according to the F27 schedule [1].
[1] https://fedoraproject.org/wiki/Releases/27/Schedule
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= System Wide Change: Kerberos KCM credential cache by default =
https://fedoraproject.org/wiki/Changes/KerberosKCMCache
Change owner(s):
* Jakub Hrozek <jhrozek AT redhat DOT com>
Default to a new Kerberos credential cache type called KCM which is
better suited for containerized environments and provides a better
user experience in the general case as well.
== Detailed Description ==
Over time, Fedora used different credential cache types to store
Kerberos credentials - going from a simple file-based storage (FILE:)
to a directory (DIR:) and most recently a kernel-keyring based cache
(KEYRING:).
Each of these caches has its own set of advantages and disadvantages.
The FILE ccache is very widely supported, but does not allow multiple
primary caches in a collection. The DIR cache does, but creating and
managing the directories including proper access control can be
tricky. The KEYRING cache is not well suited for cases where multiple
semi-isolated environments might share the same kernel. Managing
credential caches' life cycle is not well solved in neither of these
cache types automatically, only with the help of a daemon like SSSD.
The scope of this change is to introduce a new Kerberos credential
cache type called KCM and switch to using it by default.
With KCM, the Kerberos caches are not stored in a "passive" store, but
managed by a daemon. In this setup, the Kerberos library (typically
used through an application, like for example, kinit) is a "KCM
client" and the daemon is being referred to as a "KCM server". The KCM
server will be provided as a socket-activated service of the SSSD
deamon.
== Scope ==
* Proposal owners:
SSSD developers will implement a KCM server. The deamon along with a
krb5.conf snippet will be packaged in a subpackage called `sssd-krb5`.
The interested variants of Fedora that would wish to opt in would add
the `sssd-krb5` subpackage to their compose.
* Other developers:
None required
* Release engineering:
None required
* List of deliverables:
None affected
* Policies and guidelines:
None required
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
There will be an outage starting at 2017-06-20 21:00UTC, which will last
approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2017-06-20 21:00 UTC
Reason for outage:
We will be applying updates and rebooting servers into newer kernels.
Fedora build related services may be up or down during the outage window.
Affected Services:
pkgs.fedoraproject.org
koji
koshei
kojipkgs
pkgdb
bodhi / updates
mdapi service
Services not listed are not affected by this outage.
Contact Information:
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/6118
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
``
To reply, visit the link below or just reply to this email
https://pagure.io/fedora-infrastructure/issue/6119
= Proposed Self Contained Change: PHP 7.2 =
https://fedoraproject.org/wiki/Changes/php72
Change owner(s):
* Remi Collet < remi at fedoraproject dot org >
Update the PHP stack in Fedora to latest version 7.2.x
== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.2.x.
PHP 7.2.0 is planed for end of year, which seems compatible with
Fedora roadmap. [ https://wiki.php.net/todo/php72 ]
Compatibility for PHP code is very good.
== Scope ==
* Proposal owners:
- Check Koschei status. Test with latest version to ensure compatibility.
- Work with upstream on bug fixing.
- Needed mass rebuild (C extensions) done by change owner.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
RelEng ticket: https://pagure.io/releng/issue/6846
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: perl Package to Install Core Modules =
https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s):
* Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with
Perl upstream sources.
== Detailed Description ==
Upstream releases Perl interpreter together many Perl modules. This
set of modules is called core modules. Fedora splits the modules into
subpackages so that installing perl package results in stripped-down
set of modules. Fedora documents this as a feature and provides
perl-core to metapackage that allows installing all the core modules
as is intended by upstream.
Unfortunately this seems to be confusing to Perl users because Fedora
is the only distribution doing so.
To align Fedora's behaviour to upstream and other distributions this
change will rename perl package to perl-interpreter and perl-core
package to perl'. This will allow installing all core Perl modules
with dnf install perl while still retain the possibility to install
only a minimal perl interpreter (/usr/bin/perl) with dnf install
perl-interpreter.
This change will also update Fedora Packaging Guidelines for Perl to
all spec files that require perl to use perl-interpreter instead.
There is only 81 binary packages affected. They will rebuilt.
Otherwise no mass rebuild won't be necessary.
To ease sharing spec files with older Fedoras, perl-interpreter
provide will add to perl package there.
== Scope ==
* Proposal owners:
- Submit Fedora Packaging Guidelines for Perl update to Fedora
Packaging Committee.
- Update and rebuild perl source package.
- Add Provides: perl-interpreter to perl package in older Fedoras.
- Replace BuildRequires and Requires for perl with perl-interpreter in
all spec files.
- Rebuild packages with replaced Requires to propagate the change to
repositories.
- Replace perl-core with perl in compose groups definition.
* Other developers:
Get familiar with new Fedora Packaging Guidelines for Perl.
* Release engineering:
No action needed. Request to check of an impact with Release
Engineering: https://pagure.io/releng/issue/6842
* List of deliverables:
Anything what contains perl package
* Policies and guidelines:
Fedora Packaging Guidelines for Perl update request (
https://pagure.io/packaging-committee/issue/690 ) to use perl and
perl-interpreter instead of perl-core and perl.
Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hi everyone,
Our hotel discount code for Flock went live yesterday. It is... *drumroll* "FLOCK".
Here are the rates:
- A $139/night* rate per double, queen, or king room is available from August 27 to August 31. You will need to use the "Group Attendee" code "FLOCK" on the hotel reservation form to book your room at the Flock rate.
- A $169/night* double occupancy (under 18 free) discounted rate is available the weekend before and the weekend after (evenings of Fri Aug 25 and Sat Aug 26 + evenings of Fri Sep 1 and Sat Sep 2. The $139 rate is available Thu Aug 24 and Mon Sep 3.)
- If you are booking by phone, please state that you are attending the Flock 2017 Conference.
- July 26 is the cut-off for our reserved block. If reserving for yourself, please book before then!
*IF YOU ARE APPLYING FOR FUNDING DO NOT RESERVE YOUR ROOM.* We'll book it for you if you are funded. :)
The website is updated with this info.
Also, we're looking forward to reviewing your session proposals, which are due tomorrow! :)
For more frequent updates about Flock 2017, please subscribe to:
https://lists.fedoraproject.org/admin/lists/flock-attendees-2017.lists.fedo…
Cheers,
~m
The Fedora Project is pleased to announce the immediate availability
of Fedora 26 Beta, the next big step on our journey to the exciting
Fedora 26 release in July.
Download the prerelease from our Get Fedora site:
* Get Fedora 26 Beta Workstation
https://getfedora.org/workstation/prerelease/
* Get Fedora 26 Beta Server
https://getfedora.org/server/prerelease/
* Get Fedora 26 Pre-Release Atomic
https://getfedora.org/atomic/prerelease/
Looking for Fedora Cloud Base? This is replaced by Atomic as a Fedora
Edition for the container use case, but we still produce it for those
of you who want to build up your own cloud-computing environment in a
more traditional way from https://cloud.fedoraproject.org/.
Or, check out one of our popular variants, including KDE Plasma, Xfce,
and other desktop environments, as well as images for ARM devices
like the Raspberry Pi 2 and 3:
* Get Fedora 26 Beta Spins
https://spins.fedoraproject.org/prerelease
* Get Fedora 26 Beta Labs
https://labs.fedoraproject.org/prerelease
* Get Fedora 26 Beta ARM
https://arm.fedoraproject.org/prerelease
Fedora’s journey is not simply about updating one operating system
with the latest and greatest packages. It’s also about innovation for
the many different platforms represented in the Fedora Project:
Workstation, Server, Atomic, and the various Spins. Coordinating the
efforts across the many working groups is no small task, and serves
as a testament to the talent and professionalism found within the
Fedora community.
As we move into this Beta phase of the Fedora 26 release cycle, what
can users expect?
Fedora-Wide Changes
===================
Fedora, always in the path of innovation, will ship with the latest
version of the GNU Compiler Collection, also known as GCC, bringing
the latest language features and optimizations to users and to the
software we build. Also the Go Language is updated to the latest
version, 1.8, which includes 32-bits MIPS support and speed
improvements.
One of the most important changes is the addition of "blivet-gui" to
the installer. This provides a "building-blocks" style partitioning
GUI for sysadmins and enthusiast users who are familiar with the
details of storage systems.
Also, we've made and included many improvements in security, improving
user experience and reducing the risks of the digital life.
Fedora Editions
===============
The Workstation edition of Fedora 26 Beta features GNOME 3.24, which
includes important changes like Night Light, which changes the color
temperature of the display based on time of day. It will also
include the latest update of LibreOffice.
Our Atomic Host Edition also has a lot of improvements, including
more options to run containers, the latest version of the docker
container platform, the cockpit manager and the atomic CLI, improving
the way containers are managed, making being a sysadmin easier.
Spins and Labs
==============
The Fedora Project is proud to announce two new versions: The LXQt
Spin, a lightweight desktop supporting the latest version of the Qt
libraries; and the Python Classroom Lab, a new version focused in the
teaching and learning of the Python programming language. And, in the
Cinnamon Spin, the desktop is updated to the latest version.
Alternative Architectures
=========================
We are also simultaneously releasing 64-bit F26 Beta for ARM
(AArch64), Power (both little and big endian) and s390x
architectures. You'll also find minimal network installers and the
Fedora 26 Beta Cloud Base image here:
* Get Beta Alternative Architectures and Other Downloads.
https://alt.fedoraproject.org/prerelease/
What is the Beta Release?
=========================
A Beta release is code-complete and bears a very strong resemblance
to the third and final release. The final release of Fedora 26 is
expected in July. If you take the time to download and try out the
Beta, you can check and make sure the things that are important to
you are working. Every bug you find and report doesn’t just help you,
it improves the experience of millions of Fedora users worldwide!
Together, we can make Fedora rock-solid. We have a culture of
coordinating new features and pushing fixes upstream as much as we
can, and your feedback improves not only Fedora, but Linux and Free
software as a whole.
Issues and Details
==================
Since this is a Beta release, we expect that you may encounter bugs
or missing features. To report issues encountered during testing,
contact the Fedora QA team via the mailing list or in #fedora-qa on
Freenode. As testing progresses, common issues are tracked on the
Common F26 Bugs page. https://fedoraproject.org/wiki/Common_F26_bugs
For tips on reporting a bug effectively, read how to file a bug
report: https://fedoraproject.org/wiki/How_to_file_a_bug_report
More information
================
For more detailed information about what's new on Fedora 26 Beta
Release, you can consult our Talking Points and the F26 Change Set.
* https://fedoraproject.org/wiki/Fedora_26_talking_points
* https://fedoraproject.org/wiki/Releases/26/ChangeSet
They contain more technical information about the new packages and
improvements shipped with this release.
= Proposed Self Contained Change: Decouple system java setting from
java command setting =
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_ja…
Change owner(s):
* Michael Simacek <msimacek AT redhat DOT com>
* Mikolaj Izdebski <mizdebsk AT redhat DOT com>
Alternatives can be used to specify which Java installation should be
the default for the system. Currently, changing the default java
command causes not only a change to the /usr/bin/java symlink, but
also affects the which runtime is used for system installed Java
applications. We propose introduction of separate setting for
system-wide java applications.
== Detailed Description ==
Fedora allows parallel installation of multiple Java runtime
environments and it uses alternatives mechanism to allow the user to
switch between them. JDK packages provide a set of alternatives
symlinks for it's executables. The java symlink is used to determine
the java command (/usr/bin/java), but also determines which runtime
environment is used to run system-wide Java applications installed
from RPMs, such as maven or eclipse. While in theory different Java
runtime environments are drop-in replacements for each other, in
practice some of the applications may stop working properly. Users
usually install alternative JDKs in order to run their own
applications and don't expect that changing the java command will have
effect on the system applications. By introducing a separate setting
for system-wide java, we would avoid this problem. We propose
specifying default Java runtime for RPM-managed applications in
/etc/java/java.conf (this is already possible, but not currently
used). Administrators would still be able to override the system
default if they need to.
== Scope ==
* Proposal owners:
Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/6831
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic