Greetings!
Today, on 2017-Feb-28, we have reached Fedora 26 Change
Checkpoint:Completion deadline (testable) [1].
At this point, all accepted changes [2] should be substantially
complete, and testable. Additionally, if a change is to be enabled by
default, it must be enabled at Change Completion deadline as well.
Change tracking bug should be set to the MODIFIED state to indicate it
achieved completeness.
Incomplete and non testable Changes [3] will be reported to FESCo for
2017-Mar-03 meeting. Contingency plan for System Wide Changes, if
planned for Alpha (or in case of serious doubts regarding Change
completion), will be activated.
Side note: Currently we still have two Self-Contained Changes waiting
for FESco approval [4]. I am going to ask FESCo to consider postponing
of this Checkpoint for these two Changes if these are approved.
[1] https://fedoraproject.org/wiki/Releases/26/Schedule
[2] https://fedoraproject.org/wiki/Releases/26/ChangeSet
[3] http://red.ht/2ltXbqk
[4] https://pagure.io/fesco/issue/1635#comment-350632
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Greetings.
I've just finished setting up a new group of test machine instances for
package maintainers in the Fedora Infrastructure Private Cloud.
They now include ppc64 and ppc64le instances.
(We hope to add aarch64 before too long).
These instances should be faster and closer to repositories than
previous test instances, and require no special ssh config to use.
Please see:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintaine…
for more details and access information on all the available instances.
These instances can help maintainers duplicate problems or gather
information from Fedora versions they may not have handy.
Hope they help,
kevin
= Proposed Self Contained Change: Bodhi Non-RPM Artifacts =
https://fedoraproject.org/wiki/Changes/BodhiNonRPMArtifacts
Change owner(s):
* Randy Barlow <bowlofeggs AT fedoraproject DOT org>
Bodhi, the Fedora Updates System, should be able to process more than just RPMs.
== Detailed Description ==
As Fedora starts to deliver more than just RPMs and ISOs, we need a
way to handle delivering updates to these artifacts. Bodhi currently
handles this workflow for RPMs only, but we want to start using it for
other content, such as Docker containers, Flatpak apps, OSTrees, etc.
If it can be tagged in Koji, it should be accepted by Bodhi.
== Scope ==
* Proposal owners:
- Database model changes
- Masher modifications to the push process
- Web UI changes
- CLI modifications
- Unit tests
- Documentation
- Upstream tracker issue: https://github.com/fedora-infra/bodhi/issues/653
* Other developers:
- QA: Taskotron will need handle kicking off tests for non-RPM updates
- QA: Client-side updates-testing tools like fedora-easy-karma could
optionally be updated to detect these new artifacts
* Release engineering:
- We will need to ensure that the current signing process will work
with non-RPM content
- Ensure that the new content has a proper home in the directory structure.
- Releng ticket: #6660
- 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: Python 3 C.UTF-8 locale =
https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale
Change owner(s):
* Charalampos Stratakis <cstratak AT redhat DOT com>
* Nick Coghlan <ncoghlan AT redhat DOT com>
The standalone Python 3.6 binary will automatically attempt to coerce
the C locale to C.UTF-8, unless the new PYTHONALLOWLOCALE environment
variable is set to 1.
== Detailed Description ==
When run under the C locale, Python 3 doesn't work properly on systems
where UTF-8 is the correct encoding for interacting with the rest of
the system. This proposed change for Python 3 packaged in Fedora
assumes the current locale is misconfigured when it detects that
"LC_TYPE" refers to the "C" locale, and in that case, prints a
warnings to stderr and forces the use of the C.UTF-8 locale instead.
To avoid unintended side effects, this change takes effect *solely*
when Python 3 is invoked by the user—nothing changes in cases where
CPython is used as a dynamically linked library. Also, an "escape
hatch" environment variable is provided to revert to the old behavior.
The effects of the problem for a popular CLI construction library are
explained on Armin Ronacher's blog:
http://click.pocoo.org/5/python3/#python-3-surrogate-handling
The problem is described in detail in PEP (Python Enhancement
Proposal) 538: https://www.python.org/dev/peps/pep-0538/
The PEP has no strong opposition upstream, but acceptance is held back
by considerations for other systems (e.g. those that do not have a
C.UTF-8 locale). These considerations do not apply for Fedora. We are
commited to follow upstream conversation and recommendations around
PEP 538. Also, we hope that testing this in Fedora will help upstream
find remaining distro integration issues.
The current version of the PEP specifically encourages backporting to
Python 3.6.0: https://www.python.org/dev/peps/pep-0538/#backporting-to-python-3-6-0
Check the Change Page for an example of the behaviour:
https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale#Detailed_Desc…
== Scope ==
* Proposal owners:
A patch will be backported to Fedora's Python 3.6 from the upstream
PEP 538 which targets Python 3.7. The patch that will be backported is
explicitly targeting Fedora, as the upstream equivalent one will have
to be compatible with Windows, macOS, Solaris etc. The Fedora specific
patch is provided by Nick Coghlan, a Python core developer.
* Release engineering:
No impact with release engineering
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hi everyone!
Today is the submission deadline for Self contained Changes of Fedora
26 [1]. Please schedule your upcoming Changes (Self contained as well
as System wide) for the next (Fedora 27) release.
Alpha release of Fedora 26 is planned then on March 21th.
[1] https://fedoraproject.org/wiki/Releases/26/Schedule
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: Arm Support In FMW =
https://fedoraproject.org/wiki/Changes/ArmSupportInFmw
Change owner(s):
* Martin Bříza <mbriza AT redhat DOT com>
Fedora Media Writer will gain the ability to write ARM images to SD
cards and other portable media.
== Detailed Description ==
With ARM (ARMv7A) being one of the primary architectures of Fedora, we
should support writing the images to bootable media for devices with
this architecture.
This means Fedora Media Writer will have to list the ARM images, offer
their download and be able to unpack them reliably (as they're shipped
LZMA-compressed - .xz). Memory card support should be improved,
especially in terms of reading drive information - many SD card
drivers report wrong names, sizes and media presence.
This will come along with many more features in FMW, such as
fullscreen screenshot preview, automatic FMW update check on Windows
and Mac, better reliability and performance improvements.
== Scope ==
* Proposal owners:
Implementation of this Change
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
N/A
* 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: No More Alphas =
https://fedoraproject.org/wiki/Changes/NoMoreAlpha
Change owner(s):
* Dennis Gilmore <dennis AT ausil DOT us>
* Adam Williamson <awilliam AT redhat DOT com>
Fedora will no longer produce Alpha releases.
== Detailed Description ==
By gating Rawhide builds from landing in the compose and gating the
publication of composes on automated test results we will ensure
Rawhide will always be at Alpha quality. This will make it more
generally useful to people as a daily driver and development platform,
and mean we no longer need to go through the process of building,
testing and shipping Alpha releases. The initial testing will be
ensuring that a package is installable and that it does not break
existing packages installation. Over time we can enable extra testing
to gate the build going into rawhide. Builds will land in the
buildroot to be built against before they make it to the compose.
== Scope ==
* Proposal owners:
rearrange the koji tag and target structure, have the testing in
place, setup processes to move builds in koji when they meet gating
criteria. The changes would start to be implemented in rawhide shortly
after branching Fedora 26
* Other developers:
Pay attention to new notifications and act when necessary
* Release engineering:
https://pagure.io/releng/issue/6621
* List of deliverables:
This change removes a milestone and all associated deliverables
* Policies and guidelines:
As there is no more Alpha we will need to update the guidelines to
have changes be completed for Beta. We will likely want to add a new
checkpoint for change implementation that currently needs to be
checked at Alpha
* 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: Docker SDK for Python, version 2 =
https://fedoraproject.org/wiki/Changes/Docker_SDK_For_Python_Version_2
Change owner(s):
* Tomas Tomecek <ttomecek AT redhat DOT com>
Add new version of "Docker SDK for Python" to Fedora. This obsoletes
existing python-docker-py package.
== Detailed Description ==
On December 2016, upstream released a new version of python library
which communicates with Docker engine API. This new release is not
backwards compatible with previous 1.x series. As part of this
release, the upstream also renamed the package: it used to be named
docker-py on PyPI, now it's named docker.
We need to start a new review process and get the latest version of
the library to Fedora. Since the update will be backwards
incompatible, we need to make sure that all the software requiring
this library works with it.
== Scope ==
* Proposal owners:
-- Submit a review
-- Do a production build
-- Make sure that all the dependencies work with the updated package
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
N/A
* 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: The GNU C Library version 2.25 =
https://fedoraproject.org/wiki/Changes/GLIBC225
Change owner(s):
* Carlos O'Donell <carlos AT redhat DOT com>
Switch glibc in Fedora 26 to glibc version 2.25.
== Detailed Description ==
The GNU C Library version 2.25 will be released at the beginning of
February 2017; we have started closely tracking the glibc 2.25
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 26 will branch after the
GLIBC 2.25 upstream release.
== Scope ==
* Proposal owners:
Update glibc to 2.25 from tested upstream release.
* Other developers:
Aside from Carlos O'Donell <carlos(a)redhat.com>, DJ Delorie
<dj(a)redhat.com>, Florian Weimer <fweimer(a)redhat.com>, Torvald Riegel
<triegel(a)redhat.com>, Martin Sebor <msebor(a)redhat.com>, and Patsy
Franklin <pfrankli(a)redhat.com>, no other developers are required.
These developers need to ensure that rawhide is stable and ready for
the Fedora 26 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:
In general coordination with release engineering is not required. A
mass rebuild is not required.
* Policies and guidelines:
The policies and guidelines do not need to be updated.
--
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: Replace Coolkey with OpenSC =
https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC
Change owner(s):
* Jakub Jelen <jjelen AT redhat DOT com>
There are more PKCS#11 libraries supporting the same smart cards in
the system. For the next releases, we would like to promote OpenSC as
a default PKCS#11 provided in place where Coolkey driver is used these
days, which will extend a list of supported smart cards and make use
of the most of the OpenSC.
== Detailed Description ==
Currently, there are several PKCS#11 modules available in Fedora. Some
of them provide the same functionality as the others. Currently, the
majority of the work around smart cards is done in the OpenSC project
supporting all the major cards we are interested to have in Fedora. On
the other side, there is no significant development efforts in Coolkey
project, which is currently used by default in some applications
(NSS).
The provided libraries are dynamically loaded PKCS#11 libraries, so
existing applications should not depend directly on either package.
The transition should be smooth as the change of the path in the
configurations, if any. The only exceptions are NSS (Coolkey installs
its module to the NSS database), ESC and pesign (explicit requires
should be removed).
$ dnf repoquery --whatrequires coolkey
esc-0:1.1.0-30.fc25.x86_64
pesign-0:0.112-4.fc25.x86_64
We would like to:
* Get rid of explicit requires (pesign, esc)
* Switch the default PKCS#11 module in applications from Coolkey to
OpenSC (NSS, ESC, pesign, ...?)
* Retire the Coolkey package from Fedora (estimated in Fedora 27+)
During last months we worked with NSS to implement and test missing
features in OpenSC to follow CoolKey driver and specification
behavior.
== Scope ==
* Proposal owners:
-- For Fedora 26, we want to switch all applications to OpenSC and
leave Coolkey as a backup. We will unregister coolkey from NSS
database and register OpenSC instead.
-- For Fedora 27, we would like to retire coolkey package, if there
will not show up any problem with the transition in previous phase.
* Other developers:
The other packages using PKCS#11 should make sure they work with
OpenSC, if they were depending on coolkey directly for future releases
(will be communicated with affected package owners).
* Release engineering:
N/A
--
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: LDC 1.1.0 =
https://fedoraproject.org/wiki/Changes/LDC1.1.0
Change owner(s):
* Kalev Lember <klember AT redhat DOT com>
Update LDC to 1.1.0 in Fedora 26.
== Detailed Description ==
The LDC D compiler has been lagging behind upstream in Fedora, making
it difficult to build software that needs an up to date D compiler,
such as Terminix. With this update, LDC in Fedora gets bumped to the
latest upstream release, 1.1.0, and hopefully makes it easier for
projects using the D compiler to get into Fedora.
== Scope ==
* Proposal owners:
-- Update LDC to 1.1.0 [done]
-- Add an %{ldc_arches} RPM macro that dependant packages can use to
correctly set ExclusiveArch [done]
-- Rebuild packages depending on LDC [done]
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
N/A
* 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