F28 System Wide Change: GCC8
by Jan Kurik
= System Wide Change: GCC8 =
https://fedoraproject.org/wiki/Changes/GCC8
Change owner(s):
* Jakub Jelínek <jakub AT redhat DOT com>
Switch GCC in Fedora 28 to 8.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 29.
== Detailed Description ==
GCC 8 is currently in stage3, will move to stage4 on January 14th, in
prerelease state with only regression bugfixes and documentation fixes
allowed. The release will happen probably in the middle of April. We
are working on scratch gcc rpms and will perform a test mass rebuild.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f28, or,
if there is not enough time for that, just all packages built after
the new gcc hits the buildroots.
* Proposal owners:
Build gcc in f28, rebuild packages that have direct dependencies on
exact gcc version (libtool, llvm, gcc-python-plugin, odb).
* Other developers:
First few days/weeks just voluntary rebuilds using the new system gcc,
if things fail, look at http://gcc.gnu.org/gcc-8/porting_to.html and
fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.
* Release engineering:
PR#7249: https://pagure.io/releng/issue/7249
Mass rebuild requested for F28.
* Policies and guidelines:
No policies need to be changed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 3 months
F28 System Wide Change: The GNU C Library version 2.27
by Jan Kurik
= System Wide Change: The GNU C Library version 2.27 =
https://fedoraproject.org/wiki/Changes/GLIBC227
Change owner(s):
* Carlos O'Donell <carlos AT redhat DOT com>
Switch glibc in Fedora 28 to glibc version 2.27.
== Detailed Description ==
The GNU C Library version 2.27 will be released at the beginning of
February 2018; we have started closely tracking the glibc 2.27
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 28 will branch after the
GLIBC 2.27 upstream release. However, the mass rebuild schedule means
Fedora 28 will mass rebuild (if required) just after GLIBC 2.27
upstream freezes ABI for release, so careful attention must be paid to
any last minute ABI changes.
This change also includes the following changes:
* glibc collation update and sync with cldr
https://fedoraproject.org/wiki/Changes/Glibc_collation_update_and_sync_wi...
* SunRPC Removal https://fedoraproject.org/wiki/Changes/SunRPCRemoval
== Scope ==
* Proposal owners:
Update glibc to 2.27 from tested upstream release.
* Other developers:
Developers need to ensure that rawhide is stable and ready for the
Fedora 28 branch. Given that glibc is backwards compatible and we have
been testing the new glibc in rawhide it should make very little
impact when updated.
* Release engineering:
#7249 : https://pagure.io/releng/issue/7249
The Fedora Toolchain team is responsible for ensuring that Fedora
Rawhide stabilizes ABI before a Fedora release, or that after the
branch that the Fedora release is rebased (a very small rebase) to the
final released version. This is a requirement for Fedora to inherit
the ABI and API guarantees provided by upstream. If a mass rebuild is
required by glibc or other components, the Fedora Toolcahin team will
ensure coordination with release engineering such that a mass rebuild
uses the released version of glibc to fix any last minute ABI changes.
A mass rebuild has been requested.
* List of deliverables: NA
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* 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
6 years, 3 months
F28 System Wide Change: Binutils version 2.29.1
by Jan Kurik
= System Wide Change: Binutils version 2.29.1 =
https://fedoraproject.org/wiki/Changes/BINUTILS2291
Change owner(s):
* Nick Clifton <nickc AT redhat DOT com>
Rebase the binutils package from version 2.29 to version 2.29.1. This
will bring in the bug-fixes from the 2.29.1 point release, but not add
any new features.
== Detailed Description ==
Switch the binutils package from being based on the 2.29 release of
the FSF binutils to being based on the 2.29.1 release. This release
was a collection of important bug fixes over the 2.29 release, but no
new features were introduced.
== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
* Other developers:
In theory none - the change should be completely transparent. In
practice since the binutils are part of the C/C++ compiler toolchain
there is the possibility that the change introduces a new bug which
affects other packages.
* Release engineering:
https://pagure.io/releng/issue/7251
* List of deliverables:
Just the binutils packages.
* Policies and guidelines:
No updates needed.
* 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
6 years, 3 months
Intent to retire jenkins.fedorainfracloud.org
by Pierre-Yves Chibon
Dear all,
The Fedora Infrastructure team has had a jenkins instance running at
jenkins.fedorainfracloud.org for a little while now. This instance was
maintained on a best-effort basis though and we often had outage and issues when
upgrading it.
Originally the jenkins master was running on RHEL using the RPMs provided by
upstream jenkins. When jenkins became available in Fedora, we switched our
master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins is no
longer packaged for Fedora, our jenkins master is therefore outdated.
On the other side of the fence, with our dear friends from CentOS, is a brand
new, shiny and well supported Jenkins instance.
So we thought it may be good to leverage the CentOS infrastructure to alleviate
our infrastructure and maintenance.
We are currently working on setting up a Jenkins master in ci.centos.org that
would be dedicated to projects ran in pagure.io.
It needs a small change to pagure.io and some work on the CentOS side but
nothing hard and we expect to be able to migrate the first volunteer projects by
early next week.
Once the first migrations have happened and the first rough edges have been
smoothed we will be announcing an official retirement date for
jenkins.fedorainfracloud.org and migrate all the projects hosted there to
ci.centos.org, and of course help with the potential questions raising from
this.
Thanks for your understanding,
Pierre
- For the Fedora Infrastructure Team
Brian Stinson
- For the Ci.CentOS.org Team
6 years, 3 months
F28 System Wide Change: mpfr-4.0.0
by Jan Kurik
= System Wide Change: mpfr-4.0.0 =
https://fedoraproject.org/wiki/Changes/mpfr-4.0.0
Change owner(s):
* James Paul Turner <jamesturner246 AT fedoraproject DOT org>
Update the MPFR package to version 4.0.0.
== Detailed Description ==
The purpose of this change is to update the Fedora MPFR package to the
latest version (4.0.0), released on the 25th December 2017. Due to a
soname bump, this change will rebuild all packages that depend on
MPFR.
== Scope ==
* Proposal owners:
- Rebuild of packages that depend on MPFR
- Minor specfile corrections and testing
* Other developers:
Testing and/or minor fixes of dependant packages
* Release engineering:
Separate Koji tag for package rebuild will be needed.
#7247: https://pagure.io/releng/issue/7247
* List of deliverables:
N/A (not needed for this Change)
* Policies and guidelines:
N/A (not needed for this 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
6 years, 3 months
F28 System Wide Change: AArch64 Server Promotion
by Jan Kurik
= System Wide Change: AArch64 Server Promotion =
https://fedoraproject.org/wiki/Changes/AArch64_Server_Promotion
Change owner(s):
* Peter Robinson <pbrobinson AT fedoraproject DOT org>
* Paul Whalen <pwhalen AT fedoraproject DOT org>
Promote Aarch64 server technologies to Primary Architecture status.
This would include the Server installer, the DVD installer ISOs, the
Cloud (qcow2 images) and Docker base images to the same status as
other primary Server architectures. This would NOT currently include
other components such as Workstation images/installs, any of the
various spins, or Fedora Atomic components.
== Detailed Description ==
The AArch64 Architecture in the server space is a mature product with
numerous platforms widely available for testing. We support both SBSA
Enterprise Haware as well as a number of Single Board Computers,
initially officially supported in Fedora 27 with the aarch64 SBC
Feature, with new device support being added all the time and more
widely available and affordable hardware.
The changes is actually a minor one as we already produce all the
deliverables as an Alternate Architecture, this primarily be a change
of where the output of the artifacts are delivered on the mirrors and
making the architecture a release blocking architecture.
This would NOT currently include other components such as Workstation
images/installs, any of the various spins, or Fedora Atomic
components.
== Scope ==
* Proposal owners:
The general AArch64 support is already in place and is widely and
actively supported by the Fedora ARM SIG and numerous ARM vendors and
third parties in Fedora. There will be further and wider support,
hardware enablement, polish and general improvements.
* Other developers:
N/A: There's no work required for other developers, the aarch64
architecture is already widely supported as an Alternate Architecture.
* Release engineering:
Needs approval from release engineering as a primary architecture as
well as pungi configuration changes to output artifacts to new
location on the primary mirror.
rel-eng ticket #7243: https://pagure.io/releng/issue/7243
* Policies and guidelines:
Updates to the primary architectures and release blocking details will
need to be updated to reflect that the AArch64 Server/Cloud/Docker
components are now considered primary.
* 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
6 years, 3 months
F28 System Wide Change: Make authselect default tool instead of authconfig
by Jan Kurik
= System Wide Change: Make authselect default tool instead of authconfig =
https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Change owner(s):
* Pavel Březina <pbrezina AT redhat DOT com>
Replace authconfig with authselect and make authselect a default tool
to configure PAM and nsswitch.conf. A compatibility tool will help
with transition period from authconfig to authselect.
Authselect is a tool to select system authentication and identity
sources from a list of supported profiles and it is available to users
since Fedora 27. Authselect is designed to be a replacement for
authconfig but it takes a different approach to configure the system.
Instead of letting the administrator build the pam stack with a tool
(which may potentially end up with a broken configuration), it ships
several tested stacks (profiles) that solve primary supported use
cases and are well tested and supported. At the same time, some
obsolete features of authconfig are not supported by authselect.
Additionally, authselect is written in C and has a small footprint
which allows it to be also part of minimal installations.
== Detailed Description ==
Authselect allows the administrator to choose one of the supported
profiles. A profile provides description of how the resulting pam and
nsswitch configuration looks like. The tool is packaged with a default
profile set that is fully supported. If an administrator has different
needs they can create a custom profile and make it accessible in
authselect by dropping it in the tool specific directory.
The authentication and identity configuration is hardcoded within the
profile. However each profile is also allowed to contain some
conditional modules that can be either enabled or disabled to allow
the administrator to enable some optional behaviour such as account
locking or ecryptfs support.
Authselect does not configure daemons that provide the selected
identity and authentication services such as SSSD or winbind, it only
configures PAM and nsswitch. Daemons must be configured manually or
through other system tools like realmd or ipa-client-install that are
better suited for this task.
The default profile set contains the following profiles:
* Local users + SSSD -- local users and remote users are handled by sssd
* With optional smartcard or fingerprint authentication
* Local users + winbind -- local users are handled by files and remote
users by winbind
* With optional fingerprint authentication
There is no need for a separate local users profile without SSSD
because the SSSD module is not called for local users and it also
gracefully detect when the daemon is not running.
Since authselect is very different from the authconfig, we will
provide a compatibility tool that will mimic most but not all options
of authconfig and translate those operations into an authselect call
and configuration changes so we do not break users scripts.
== Scope ==
* Proposal owners:
Authselect is already ready and shipped with Fedora. Owners will
provide compatibility tool to help with the transition.
* Other developers:
anaconda-core, fprintd-pam, freeipa-client and realmd are packages
that depends on authconfig. We will coordinate efforts to either
switch those packages to authselect or make sure that the
compatibility tool is sufficient to cover their needs.
* Release engineering:
#7241: https://pagure.io/releng/issue/7241
* List of deliverables: all
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* 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
6 years, 3 months
F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
by Jan Kurik
= System Wide Change:Removal of Sun RPC Interfaces From glibc =
https://fedoraproject.org/wiki/Changes/SunRPCRemoval
Change owner(s):
* Florian Weimer fweimer AT redhat DOT com>
This system-wide change covers the removal of interfaces related to
Sun RPC from glibc.
== Detailed Description ==
glibc bundles an implementation of Sun RPC (including XDR support, on
which Sun RPC is based). This implementation is not compatible with
IPv6, and due to the way addresses are represented, adding IPv6
support would need an ABI bump. As a result, upstream decided to move
Sun RPC support to a separate library, libtrpc, which has been
packaged since Fedora 7.
== Scope ==
* Proposal owners:
Remove the interfaces from glibc and adjust the glibc packaging to
remove the nss_nis subpackage.
* Other developers:
Packages which still use the built-in Sun RPC support need to switch
to libtirpc. NIS packages need to switch to the separate libnsl
package.
* Release engineering:
#7239: https://pagure.io/releng/issue/7239
* List of deliverables:
Not affected
* Policies and guidelines:
N/A (not needed for this Change; covered by the existing Packaging 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
6 years, 3 months
F28 Self Contained Change: Thunderbolt Enablement
by Jan Kurik
= Proposed Self Contained Change: Thunderbolt Enablement =
https://fedoraproject.org/wiki/Changes/ThunderboltEnablement
Change owner(s):
* Christian Kellner <ckellner AT redhat DOT com>
Support Thunderbolt 3 peripherals in a secure way hardware out of the box.
== Detailed Description ==
Thunderbolt™ is the brand name of a hardware interface developed by
Intel® that allows the connection of external peripherals to a
computer.
Devices connected via Thunderbolt can be DMA masters and thus read
system memory without interference of the operating system (or even
the CPU). Version 3 of the interface provides 4 different security
levels, in order to mitigate the aforementioned security risk that
connected devices pose to the system. The security level is set by the
system firmware.
The four security levels are:
* none: Security disabled, all devices will fully functional on connect.
* dponly: Only pass the display-port stream through to the connected device.
* user: Connected devices need to be manually authorized by the user.
* secure: As 'user', but also challenge the device with a secret key
to verify its identity.
The Linux kernel, starting with version 4.13, provides an interface
via sysfs that enables userspace query the security level, the status
of connected devices and, most importantly, to authorize devices, if
the security level demands it.
The active security level can normally be selected prior boot via a
BIOS option, but it is interesting to note that in the future the none
option is likely to go away. This of course means connected
thunderbolt devices wont work at all unless they are authorized by the
user from with the running operating system.
The solution to automatically enable thunderbolt 3 devices to work
with Fedora without compromising the security of the computer consists
of two user space compoments: a system daemon (boltd) and a component
in GNOME shell. For new devices the shell will automatically enroll (=
authorize and store in the database) new devices via the daemon if
(and only if) the current user is a system administrator and the
session is unlocked. On subsequent connections of the same device the
daemon will then automatically authorize the device.
== Scope ==
* Proposal owners:
Stablize bolt and integrate the current GNOME Shell extension
proof-of-concept into GNOME Shell upstream.
* Other developers:
Nothing
* Release engineering:
#7238: https://pagure.io/releng/issue/7238
* 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
6 years, 3 months
F28 System Wide Change: Kerberos in Python modernization
by Jan Kurik
= System Wide Change: Kerberos in Python modernization =
https://fedoraproject.org/wiki/Changes/kerberos-in-python-modernization
Change owner(s):
* Robbie Harwood <rharwood at fp dot o>
Replace usage of python-krbV and pykerberos with python-gssapi in all
Fedora packages to enable their removal from Fedora. rharwood will
author all necessary code changes; no new code from maintainers is
required.
== Detailed Description ==
Replace older, clunkier, less user-friendly python interfaces to
Kerberos with python-gssapi. python-gssapi uses the GSSAPI interface,
which is widely standardized, implemented by both MIT and Heimdal
Kerberos, and much more user-friendly.
As part of this effort, python-requests-gssapi will be introduced to
fedora to enable transition off of python-requests-kerberos (which
requires pykerberos). Its package review (completed as of 2018-01-03)
was rhbz#1527682
Please note that I will be providing all patches necessary to all
affected components; no work is expected from other maintainers, other
than normal review and backport handling.
== Scope ==
* Proposal owners:
rharwood (responsible for providing patches and new package)
* Other developers:
maintainers of affected packages are expected to perform code review
* Release engineering:
#7219: https://pagure.io/releng/issue/7219
* 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
6 years, 3 months