F28 Self Contained Change: Avoid /usr/bin/python in RPM build
by Jan Kurik
= Proposed Self Contained Change: Avoid /usr/bin/python in RPM build =
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build
Change owner(s):
* Petr Viktorin <python-devel at lists.fedoraproject.org>
* Miro Hrončok <python-devel at lists.fedoraproject.org>
Deprecate, and later disable, running /usr/bin/python (as opposed to
/usr/bin/python3 or /usr/bin/python2) during RPM build.
Changes will be driven by Python SIG, but a few packages may fail to
build (with the failure message providing an easy workaround).
== Detailed Description ==
=== Motivation ===
Currently in Fedora (package names, executable names, etc.), python
means Python 2.
We would like to change it to mean Python 3, but to do that, we need
to free it of the current meaning.
This means explicitly using either "python2" or "python3" throughout Fedora.
This is a multi-release effort tracked in Python SIG's "Finalizing
Fedora Switch to Python3" document.
This page describes a very focused subset of it.
Renaming packages (and associated changes to, for example, "Requires:"
directives) is relatively straightforward, but making all
Fedora-provided code avoid /usr/bin/python (as opposed to
/usr/bin/python2) is both harder to achieve and harder to keep track
of.
We would like to start deprecating /usr/bin/python (as opposed to
/usr/bin/python2) at RPM build time.
RPM build is a controlled environment: changes to it will not be felt
by end users, breakages are almost immediately visible, and output of
Koji builds can be nicely tracked and analyzed.
=== Specification ===
Python 2, when called as python or /usr/bin/python at RPM build time
(as identified by the RPM_BUILD_ROOT environment variable), will print
a deprecation warning to stderr. (Any program invoked during build
that invokes /usr/bin/python will cause this warning as well.)
A new Taskotron check will be implemented to look for this warning and
fail if it's found.
We will look at the Taskotron results and work with packagers to
switch to update the affected packages. (We'll look at the results to
determine if we'll use automated pull requests, mass bug filing, or
something else.)
The warning itself may cause some packages to fail to build, for
example if a test relies on exact stderr contents.
For these cases, it will be possible to turn the warning off using an
environment variable, but we ask packagers that use of this workaround
is tracked in Bugzilla. See Opt-Out below.
After all packages that BuildRequire python2 are re-built with this
check passing, python will be switched to fail after printing the
message.
The warning will not be effective if stderr output is hidden. So,
after switching /usr/bin/python to fail, some packages may start
failing to build. We will work with the packagers to fix these. (We'll
look at results from the "warnings phase" to see how proactive we'll
need to be here.)
The warning text will be:
DEPRECATION WARNING: python2 invoked with /usr/bin/python.
Use /usr/bin/python3 or /usr/bin/python2
/usr/bin/python will be removed or switched to Python 3 in the future.
If you cannot make the switch now, please follow instructions at
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#...
(Using the Wiki link allows us to easily revise the instructions.)
=== Quick Opt-Out ===
In case switching to /usr/bin/python2 or /usr/bin/python3 is
non-trivial, do these two things:
* Set the environment variable
DISABLE_AMBIGUOUS_PYTHON_VERSION_WARNING=1 when calling
/usr/bin/python
* File a Bugzilla, and make it block our tracking bug (XXX - link)
All such bugs will need to be fixed before we make /usr/bin/python fail hard.
== Scope ==
* Proposal owners:
Patch python2, write the Taskotron check, deal with warnings and failures.
* Other developers:
Switch to using /usr/bin/python3 or /usr/bin/python2 explicitly at RPM
build time (with help from Proposal owners if needed). Also tools that
are invoked during build time of other packages that themselves use
/usr/bin/python will need to be fixed.
* Release engineering:
#7257: https://pagure.io/releng/issue/7257
Note: Depending on the timing, separate targeted rebuilds may be
needed, but we can do these as Proven Packagers, no side-tags are
required
* List of deliverables:
N/A
* Policies and guidelines:
Already existing "packages in Fedora ... MUST call the proper
executable for the needed python major version directly, either
/usr/bin/python2 or /usr/bin/python3 as appropriate" from
Packaging:Python#Multiple_Python_Runtimes
* 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
Fedora 28 Change Checkpoint: Proposal submission deadline (Changes
requiring mass rebuild & system wide changes)
by Jan Kurik
Greetings!
Today, on 2018-Jan-09, we have reached Fedora 28 Change Checkpoint:
Proposal submission deadline (Changes requiring mass rebuild & system
wide changes) [1].
At this point, only Self Contained Changes will be accepted for Fedora
28. Any Change Proposal requiring mass rebuild or a System wide Change
should be scheduled for a later Fedora release.
Self Contained Changes are still accepted until 2018-Jan-30, as
published in the F28 schedule [1].
On 2018-Feb-20 is planned "Change Checkpoint Completion deadline
(testable)" where all Changes should be implemented and testable.
[1] https://fedoraproject.org/wiki/Releases/28/Schedule
Regards,
Jan
--
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: NIS switching to new libnsl to support IPv6
by Jan Kurik
= System Wide Change: NIS switching to new libnsl to support IPv6 =
https://fedoraproject.org/wiki/Changes/NISIPv6
Change owner(s):
* Matej Muzila <mmuzila AT redhat DOT com>
* Honza Horak <hhorak AT redhat DOT com>
This system-wide change covers the switch of NIS components to the new
client side implementation in order to support IPv6, while detaching
libnsl and nss_nis packages, previously bundled together with glibc.
== Detailed Description ==
glibc bundles the client part of NIS, while this implementation is not
compatible with IPv6, due to the way addresses are represented. NIS
upstream added NIS support for the server and client tools, but for
being able to use this feature, the libnsl and nss_nis needs to be
rebased to the new version. Since NIS has been part of glibc for long
time and it doesn't seem to be necessary (especially given the NIS is
an obsoleted technology for years), it is better to detach those two
packages and deliver them as a separate library.
This change is also related to Sun RPC Removal Change
[https://fedoraproject.org/wiki/Changes/SunRPCRemoval].
== Scope ==
* Proposal owners:
Provide the NIS client implementation as separate packages, and adjust
the glibc packaging to remove the nss_nis subpackage, the NIS header
files, and move libnsl to a new subpackage.
* Other developers:
Packages which used to depend on the libnsl library from glibc will
need to add BuildRequires: libnsl2-devel.
* Release engineering:
#7256: https://pagure.io/releng/issue/7256
* List of deliverables: N/A
* 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 System Wide Change: Replace glibc's libcrypt with libxcrypt
by Jan Kurik
= System Wide Change: Replace glibc's libcrypt with libxcrypt =
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s):
* Björn Esser <besser82 AT fedoraproject DOT org,>
* Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
== Detailed Description ==
Since there has been some discussion in the last time about removing
libcrypt from glibc in some time and splitting it out into a separate
project which can evolve quicker, Zack Weinberg and I put some work
into libxcrypt to make it a basically suitable replacement.
It comes with a set of extended interfaces pioneered by Openwall
Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and
crypt_gensalt_ra.
The crypt and gensalt functions are supporting all (except for
Crypt16, which was used on Ultrix and Tru64, only) widely used
password hashing algorithms, which before were specific to just some
operating system's implementations of libcrypt.
== Scope ==
* Proposal owners:
- Apply needed packaging changes to glibc
- Review, import and build libxcrypt for Fedora 28
* Other developers:
Test their applications using one of the following interfaces for
unexpected changes in functionality:
- crypt()
- crypt_r()
- encrypt()
- encrypt_r()
- fcrypt()
- setkey()
- setkey_r()
Release engineering:
#7160 https://pagure.io/releng/issue/7160
none expected
* 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 Self Contained Change: Anaconda modularization
by Jan Kurik
= Proposed Self Contained Change: Anaconda modularization =
https://fedoraproject.org/wiki/Changes/AnacondaModularization
Change owner(s):
* Jiří Konečný <jkonecny AT redhat DOT com>
Anaconda installer will be split into several modules that will
communicate over DBus using stable API.
== Detailed Description ==
Anaconda will be split into several modules that will communicate over
DBus. The goal is to introduce a stable way to interact with Anaconda
to support its customization, extensibility and testability. It will
be easier to monitor the installation, maintain an install class or an
addon, drop some modules or provide your own UI.
== Scope ==
* Proposal owners:
- Split Anaconda to modules with DBus API.
- Old UI must be modified to use new DBus API.
* Other developers:
Thanks to the nature of how addons work right now, we need a
cooperation from the Anaconda addon developers.
* Release engineering:
#7240: https://pagure.io/releng/issue/7240
* 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: OpenLDAP defaults to use only Shared System Certificates
by Jan Kurik
= System Wide Change: OpenLDAP defaults to use only Shared System Certificates =
https://fedoraproject.org/wiki/Changes/OpenLDAPdefaultSharedSystemCertifi...
Change owner(s):
* Matus Honek <mhonek AT redhat DOT com>
In order to go forward with adoption of SharedSystemCertificates [1]
after this change OpenLDAP clients and server will default to use only
the system-wide certificates store.
== Detailed Description ==
Currently, OpenLDAP defaults to trust CA certificates located in
/etc/openldap/certs. In order to comply with SharedSystemCertificates
[1] we will remove the default explicit configuration options that
point to /etc/openldap/certs. Therefore, OpenLDAP will let its crypto
library (OpenSSL) load the default CA certificates as described in the
SharedSystemCertificates [1] description. For a convenience, where
possible, configuration files will contain a commentary with an
explanation of the new behaviour.
== Scope ==
* Proposal owners:
change of default shipped configuration.
* Other developers:
check your application trusts whom you want it to trust
* Release engineering:
https://pagure.io/releng/issue/7252
* List of deliverables:
N/A
* Policies and guidelines:
None.
* Trademark approval:
None. (not needed for this Change).
[1] https://fedoraproject.org/wiki/Features/SharedSystemCertificates
--
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: OpenLDAP without Non-threaded Libraries
by Jan Kurik
= System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
Change owner(s):
* Matus Honek <mhonek AT redhat DOT com>
OpenLDAP will not ship non-threaded versions of its libraries.
Instead, it will link these to their threaded counterparts.
== Detailed Description ==
After this change the non-threaded versions of OpenLDAP libraries will
not be shipped any more. Instead, these file will rather symlink to
their threaded representatives (i.e. libldap -> libldap_r, etc.). This
has been previously discussed in [Bugzilla] and other distributions
where this change already happened. Upstream still supports
non-threaded versions of their libraries as these might be used on
processors where threads are not supported. However, when these two
versions happen to be loaded at the same time (as discussed about Curl
in the Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065])
symbol names overlap which may result in unpredictable behaviour. As
the most convenient solution arises the one proposed hereby.
== Scope ==
* Proposal owners:
update SPEC file so that some files are not shipped and replaced with
appropriate symlinks.
* Other developers:
None. Issues should not occur.
* Release engineering:
https://pagure.io/releng/issue/7253
* List of deliverables:
N/A
* Policies and guidelines:
None.
* 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: IBus Unicode Typing
by Jan Kurik
= System Wide Change: IBus Unicode Typing =
https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing
Change owner(s):
* Takao Fujiwara <fujiwara [at] redhat [dot] com>
IBus core provides an Emoji dialog which users can type emoji
annotations and output the emoji character using IBus (E.g. Typing
"football" shows U+26BD). The proposal is the dialog also supports to
type Unicode names (E.g. Typing "copyright sign" shows U+00A9).
== Detailed Description ==
IBus core provides an Emoji dialog and it can be launched with
Ctrl-Shift-e shortcut key in non-GNOME desktop and `ibus emoji`
command is available for GNOME desktop [1]. Users can select an emoji
in emoji lists on the emoji dialog or type an emoji annotation in an
input entry on the emoji dialog and output the selected emoji using
IBus.
The proposal is that emoji dialog also supports to type Unicode names
in the input entry and output the selected Unicode character.
E.g. Typing "copyright sign" shows U+00A9
[1] because gnome-shell has its owned keyboard indicator instead of
/usr/libexec/ibus-ui-gtk3 and GTK itself also has the similar emoji
dialog and the emoji implementation is under the consideration in
GNOME.
== Scope ==
* Proposal owners:
IBus core will include the dictionary of Unicode names
* Other developers:
N/A
* Release engineering:
https://pagure.io/releng/issue/7255
* 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
F28 System Wide Change: Fedora 28 Boost 1.66 upgrade
by Jan Kurik
= System Wide Change: Fedora 28 Boost 1.66 upgrade =
https://fedoraproject.org/wiki/Changes/F28Boost166
Change owner(s):
* Jonathan Wakely <jwakely AT fedoraproject DOT org>
This change brings Boost 1.66.0 to Fedora 28. This will mean F28 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 and Fedora
27 Change.
== Scope ==
* Proposal owners:
- Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
- Request a "f28-boost" build system tag (discussion):
https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost
- Build boost into that tag (take a look at the build #606493 for inspiration)
- 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:
#7254 https://pagure.io/releng/issue/7254
* 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
6 years, 3 months
F28 System Wide Change: Add-On Modularity
by Jan Kurik
= System Wide Change: Add-On Modularity =
https://fedoraproject.org/wiki/Changes/F28AddonModularity
Change owner(s):
* Stephen Gallagher <sgallagh AT redhat DOT com>
* Langdon White <langdon AT redhat DOT com>
== Detailed Description ==
Beginning in Fedora 28, Fedora will provide a new set of repositories
for software and updates with alternative versions from those shipped
in the default release.
Please see Modularity is Dead, Long Live Modularity!
[https://communityblog.fedoraproject.org/modularity-dead-long-live-modular...]
for an in-depth description of the plan.
== Scope ==
* Proposal owners
The feature owners need to provide a set of reference modules and
module-streams that can be composed into the new repository. The set
of available packages can and should increase over time as other
packagers start taking advantage of it.
* Other developers
- Developers who wish to offer multiple streams of software in Fedora
will need to update their packaging process to take advantage of the
new dist-git branching features to allow them to build the same
version across multiple releases of Fedora.
- Developers who are not interested in doing this at this time will
not need to make any changes. When co-maintainers of a packages have
different interests, they will need to coordinate.
- MirrorManager will need an update to know about the new modular repos.
* Release engineering
Ticket #7227 https://pagure.io/releng/issue/7227
This Change will require considerable interaction with Release
Engineering and the Factory 2.0 teams.
New Modular Repositories (one under release, one under updates, one
under updates-testing)
Stream Expansion from Factory 2.0
Automatic creation of basic modules https://pagure.io/modularity/issue/97
Default streams tagged into base
Work will be tracked in Taiga — links to specific items to come.
* List of deliverables
Affects several release blocking deliverables.
There will be an additional `fedora-repos-modular` package that will
be installed by default on some Editions/Spins (each WG or SIG will
need to make their own decision on whether to ship modules enabled by
default).
* Policies and guidelines
Yes.
Some guidelines are already available at
https://fedoraproject.org/wiki/Module:Guidelines, however we have
plans in place to vastly simplify the process, which should make
packagers' lives much easier.
* 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