ICU4J is now covered by the Unicode License (with MIT and BSD licensed
contributed parts.)
The Unicode license is very similar to the previous MIT-style ICU license.
--
Mat Booth
http://fedoraproject.org/get-fedora
= Proposed System Wide Change: CJK Default Fonts To Noto =
https://fedoraproject.org/wiki/Changes/CJKDefaultFontsToNoto
Owner(s):
* Akira TAGOH <tagoh at redhat dot com>
* Peng Wu <pwu at redhat dot com>
Changes the default fonts for Chinese, Japanese, and Korean (CJK)
languages to Google Noto.
== Detailed description ==
This proposal is to change the default fonts for CJK languages to
Google Noto and adopts OpenType Collection format to suppress disk
space increase as far as possible. Typefaces mapping will change as
described on the Change Proposal wiki page (Change wrangler note: the
description contains tables which are not easily convertible to text,
so please follow this link to check it:
https://fedoraproject.org/wiki/Changes/CJKDefaultFontsToNoto#Detailed_Descr…
):
== Scope ==
* Proposal owners:
** Update CJK fonts packages with the proper priority of fontconfig config files
** Update fonts group in comps [done]
* Other developers:
** For application package maintainers:
*** Any GUI applications that don't support TTC or OTC, would need to be fixed.
* Release engineering:
#7592 [https://pagure.io/releng/issue/7592]
** List of deliverables:
All of the installable images should be affected
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Deprecate YUM 3 =
https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3
Owner(s):
* Daniel Mach <dmach at redhat dot com>
Remove yum (v3) and all related packages from Fedora.
== Detailed description ==
Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils,
* yum-metadata-parser
* python-urlgrabber
All these packages should no longer be used and all software using
them should be migrated to DNF.
== Scope ==
* Proposal owners:
Remove packages from the distribution: createrepo, yum, yum-langpacks,
yum-utils, yum-metadata-parser, python-urlgrabber
* Other developers:
Either remove packages from the distribution or switch them to DNF
* Release engineering:
#7588 [https://pagure.io/releng/issue/7588]
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Minishift Spin =
https://fedoraproject.org/wiki/Changes/Minishift_Spin
Owner(s):
* Praveen Kumar <kumarpraveen dot nitdgp at gmail dot com>
* Gerard Braad <me at gbraad dot nl>
A Fedora Spin providing an easy way for minishift users to consume
fedora as an ISO.
== Detailed description ==
Minishift [https://github.com/MiniShift/minishift] provides an easy
way to create a single node Openshift cluster for developers and as of
now, we have only CentOS and b2d ISO support. It would be great if we
can have Fedora ISO support for this project so developers can have
latest and greatest container related packages.
== Scope ==
* Proposal owners:
Implement this Change.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
- Add spin to spin-kickstarts, ensure spin has been tested, and
release with rest of spins
- Ticket: #7584 [https://pagure.io/releng/issue/7584]
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Red Hat is planning on upgrading Bugzilla to BZ5 in September. There's
a test instance running now at http://bugzilla5.redhat.com/
Since Fedora is a major user and stakeholder here, it'd be helpful if
we make sure everything works for us. If you find any bugs, report at
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=5.0
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
= Proposed System Wide Change: IBus 1.5.19 =
https://fedoraproject.org/wiki/Changes/IBus_1.5.19
Owner(s):
* Takao Fujiwara <fujiwara at redhat dot com>
IBus 1.5.19 will have two features.
# Move the input entry on IBus emoji dialog to the input entry on each
application using IBus pre-edit text so that the focus event is not
changed when the emoji typing is enabled# Ctrl-Shift-u feature of
typing Unicode code points is separated from Ctrl-Shift-e feature so
that neither an additional dialog or popup window is needed.
# Typing compose keys will have a pre-edit text
== Detailed description ==
Currently Ctrl-Shift-e launches an IBus emoji dialog and users type
emoji annotations in an input entry on the dialog and the input entry
can convert the muti-byte annotation to an emoji character, besides
ASCII annotation. However the dialog takes the current input focus in
any desktop environments and also the dialog position cannot
determined in Wayland because the dialog has no parent windows.
IBus 1.5.19 will move the input entry on the emoji dialog to the
current input context on each applications using IBus pre-edit
feature. Users type emoji annotations on the pre-edit text after they
type Ctrl-Shift-e and typing space key launches a lookup window to
show emoji candidates.
Currently Ctrl-Shift-u feature of typing Unicode code point is
consolidated in the emoji dialog because one shortcut key of
Ctrl-Shift-e can cover the feature but the code point feature would
not need to launch the dialog because the candidate character is only
one so IBus 1.5.19 will separate the Ctrl-Shift-u feature from
Ctrl-Shift-e one and both keybindings can be customizable with
ibus-setup.
Currently IBus compose feature does not show anything until the output
character is determined. IBus 1.5.9 will shows the pre-edit text
during users compose a sequence.
E.g. Multi_key-apostrophe-e outputs 'é' and shows the apostrophe as a
character on the pre-edit until 'e' is typed.
== Scope ==
* Proposal owners:
IBusEngine class will be changed in ibus-libs package to handle
Ctrl-Shift-e and Ctrl-Shift-u and it will effects all IBus engines.
* Other developers:
N/A
* Release engineering:
#7582 [https://pagure.io/releng/issue/7582]
** List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Modules for Everyone =
https://fedoraproject.org/wiki/Changes/ModulesForEveryone
Owner(s):
* Stephen Gallagher <sgallagh at fedoraproject dot org>
* Langdon White <langdon at fedoraproject dot org>
All Fedora installations will have modular repositories enabled by default,
previously available, by default, only to Server Edition.
== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality,
allowing end-users access to alternative versions of popular software. Due
to technical limitations with package-management software, it was not
available for non-Server deployments of Fedora. Beginning with Fedora 29,
all installations of Fedora will have modules available for installation
and update. This will be done by merging the `fedora-repos-modular`
sub-package back into the `fedora-repos` package.
== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and
release-engineering to make sure that the repo subpackage merge only
happens once the libdnf enhancements are stable. We will also need to
prepare and run a Fedora Test Day with the QA team.
* Other developers:
The DNF team is already committed to providing the necessary changes for
libdnf in Fedora 29.
* Release engineering:
#7561 [https://pagure.io/releng/issue/7561]
** List of deliverables:
All Fedora installations
* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this
change
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Origin 3.10 =
https://fedoraproject.org/wiki/Changes/origin3.10
Owner(s):
* Jakub Čajka <jcajka at redhat dot com>
Rebase of the Openshift Origin package to the latest upstream version,
along with introduction of necessary infrastructure container images.
== Detailed description ==
Rebase of the Origin package to the latest upstream release. To note
upgrade path from previous version (3.9) will not be covered by this
change(dnf update origin, will most certainly be unable to cleanly
update Origin cluster), any one interested in helping out with the
supportable update path please reach out to the change owner or any
origin maintainer. Upstream provided update ansible playbooks are
located at https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/op…
== Scope ==
* Proposal owners:
rebase of the package, creation of the missing infrastructure container images
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
None
https://pagure.io/releng/issue/7581
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
None (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: New 128-bit IEEE long double ABI for
IBM 64-bit POWER LE =
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
Owner(s):
* Carlos O'Donell <carlos at redhat dot com>
Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI.
== Detailed description ==
IBM has designed a new long double ABI that adheres to the 128-bit
IEEE format. This format is more standard than the existing AIX
double-double or IBM long double (2 grouped 64-bit doubles) which has
discontinuous mantissas and is difficult for developers to use. In
Fedora 29 the plan is to switch to the new ABI for long double, while
still supporting old applications via compatibility symbols. Newly
compiled applications use either the old or new ABI but not a mix of
both. Changes are required in the core C libraries, and the compiler
and the compiler runtimes including the C++ standard libraries.
Therefore there is coordination required across the core toolchain
componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).
== Scope ==
The change is relatively limited in that not many packages use the
long double floating point ABI. The double floating point ABI is much
more used, but not long double. It is estimated that few packages use
long double directly, and those packages will need to be rebuilt in
order to use the new ABI. This rebuilding can be targetted by
analyzing which packages have long double usage in their debug
information and rebuilding just those packages. However, we plan to
just use the existing mass rebuild for glibc 2.28 to handle this
issue.
* Proposal owners:
Transition glibc to float128 format for long double for IBM ppc64le.
Transition gcc to the default for long double. Ensure gdb can handle
the new types.
* Other developers:
Developers need to ensure that rawhide is stable and ready for the
Fedora 29 branch.
* Release engineering:
A mass rebuild request has been filed for the parent system-wide
change to upgrade glibc to 2.28
#7475 [https://pagure.io/releng/issue/7475]
** List of deliverables
[https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fe…]
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* Trademark approval:
Not needed for this change
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: The GNU C Library version 2.28 =
https://fedoraproject.org/wiki/Changes/GLIBC228
Owner(s):
* Carlos O'Donell <carlos at redhat dot com>
Switch glibc in Fedora 29 to glibc version 2.28.
== Detailed description ==
The GNU C Library version 2.28 will be released at the beginning of
August 2018; we have started closely tracking the glibc 2.28
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 29 will branch after the
GLIBC 2.28 upstream release. However, the mass rebuild schedule means
Fedora 29 will mass rebuild (if required) just after GLIBC 2.28
upstream freezes ABI for release, so careful attention must be paid to
any last minute ABI changes.
This change also includes the following changes:
* IBM POWER LE transition to Float128 for long double.
[https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition]
== Scope ==
* Proposal owners:
Update glibc to 2.28 from tested upstream release.
* Other developers:
Developers need to ensure that rawhide is stable and ready for the
Fedora 29 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:
#7475 [https://pagure.io/releng/issue/7475] 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 is not
required and this is communicated to release engineering.
** List of deliverables:
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* Trademark approval:
Not needed for this change
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hi everyone!
The submission deadline for Changes of Fedora 29 [1], requiring mass
rebuild, takes effect today (on June 19th). All the Changes requiring
mass rebuild sent for review are going to be moved to Fedora 30
release.
The mass rebuild it self is planned on July 11th.
In case you'll need any help with your Change proposals, feel free to
contact me.
[1] https://fedoraproject.org/wiki/Releases/29/Schedule
Best Regards,
Jan
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Rename Atomic Workstation to Silverblue =
https://fedoraproject.org/wiki/Changes/Silverblue
Owner(s):
* Matthias Clasen <mclasen at redhat dot com>
The Atomic Workstation variant is being renamed to Fedora Silverblue.
== Detailed description ==
The Atomic Workstation is being rebranded as Fedora Silverblue, to
give this project more visibility and realize its full potential for
bringing new users to Fedora. There is new website,
www.teamsilverblue.org, which is gathering information and resources
around this effort.
== Scope ==
Concrete suggested changes:
** Change ostree repo branch name to fedora/29/x86_64/silverblue
** Change /etc/os-release to say Silverblue in the appropriate places
** Provide branding in fedora-logos package that says Silverblue
** Change install media name to Fedora-Silverblue-ostree-...
* Proposal owners:
** Provide patches for /etc/os-release and fedora-logos
* Other developers:
** Change lorax templates to refer to new branch name
** Change anaconda install media:
https://github.com/rhinstaller/anaconda/issues/1504
** Create a Silverblue install class in anaconda:
https://github.com/rhinstaller/anaconda/issues/1505
** Make necessary changes in pungi: https://pagure.io/pungi/issue/982
* Release engineering:
#7579 [https://pagure.io/releng/issue/7579]
** List of deliverables:
*** The Fedora Atomic Workstation iso will be renamed to
Fedora-Silverblue-x86_64...
*** The getfedora.org webpage will need corresponding adjustments
* Policies and guidelines:
No changes
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: glibc 32 Build Adjustments =
https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments
Owner(s):
* Florian Weimer <fweimer at redhat dot com>
The glibc32 package is a special package used by gcc and a few other
packages to work around the lack of RPM multilib repository support in
Koji [https://pagure.io/koji/issue/273] It is difficult to maintain,
and the current approach raises questions regarding (L)GPL compliance.
== Detailed description ==
Some packages build non-64-bit code on 64-bit architectures, using GCC
switches such as "-m32" and "-m31". Those that do not use "-nostdlib"
at the same time need a non-64-bit glibc as well. However, Koji cannot
currently provide such multilib RPMs; all RPM packages are either of
the build architecture or noarch packages.
In particular, GCC has a dependency on the non-64-bit (32-bit or
31-bit) glibc library.
The current hack to support GCC's need (and a few other packages) is
that a separate package, glibc32, contains pre-built 32-bit/31-bit
binaries extracted from RPMs built in Fedora some time in the past.
Since these binaries are pre-built, they can be built (actually copied
around) on any architecture, including the relevant 64-bit
architectures.
This primarily affects the x86_64 architecture and its i686 multilib
RPMs. Historically, the same problem occurred on ppc64 (with ppc as
the multilib architecture) and s390x (with s390). However, Fedora no
longer builds non-64-bit RPM packages on these architectures. This
also means that the ppc and s390 binaries in the glibc32 package can
no longer be recreated within Fedora, which is not sustainable. At
the very least, these two sets of binaries would have to be removed,
effectively making the glibc32 package specific to the x86_64
architecture.
It appears that on ppc64 we still need to build GCC in such a way that
the "-m32" option is supported. This means that some cross-package
coordination is necessary. (A first check showed that the s390x boot
loader support is built as 64-bit binary, so "-m31" support in glibc
does not seem to be necessary for bootloader purposes.)
There are two ways to address these problems:
* Continue the current copy-based approach. It is simplified somewhat
due to the switch to libxcrypt. Modify the (fully manual) extraction
procedure so that the source RPM of the binary files is included as
well, to provide airtight LGPL compliance.
* Build glibc32 and libgcc32 subpackages from the glibc and gcc
packages, which are then filtered by pungi from all composes
[https://pagure.io/releng/issue/7576] (Currently, the buildroot-only
nature of glibc32 is achieved by tagging builds appropriately in Koji,
which is rather fragile.) The big advantage of this approach is that
the glibc32 package will always be in sync with the actual 64-bit
library.
== Scope ==
* Proposal owners:
** Drop ppc and s390 RPM contents from glibc32. Adapt the build
procedure as agreed.
* Other developers:
** Fedora GCC developers will need to drop the build dependency on
`/usr/lib/libc.so` on ppc64 and s390x. It may be necessary to
configure GCC with "--enable-targets=all", to support "-m32" for
building boot loaders and other freestanding code.
** The compat-gcc-* and ghdl packages may need similar adjustments.
** Other packages with a "/usr/lib/libc.so.6" build dependency
(chromium, systemtap, valgrind) appear to restricted to x86_64
already.
** If the filtered subpackage approach is chosen for Fedora 29, the
gcc package will need to be updated to build a new subpackage,
libgcc32, that contains the multilib libraries. These will be
required for building glibc32 as a subpackage.
* Release engineering:
#7578 [https://pagure.io/releng/issue/7578]
** 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
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This message is directed at anyone who maintains a Node.js package in Fedora.
On Friday, FESCo approved the Fedora 29 System-Wide Change to move the default
Node.js interpreter to the 10.x LTS stream. This means that we will need to
ensure that any NPM packages that are present in Rawhide must work on 10.x.
What you need to do if
== ... your current package works fine with both Node.js 8.x and 10.x ==
No action required.
== ... your current package doesn't work with 10.x ==
A) It has an upstream release that does (or you can patch it to work)
- - Prepare the upstream package and build it in Rawhide during the week of June
25th through the 29th. I will update the Node.js interpreter in Rawhide
sometime on Friday, June 22nd so it will be in the buildroot.
B) It cannot be made to work with Node.js 10.x at all
- - If this package is still valuable to have when people are using the 8.x
module stream, contact me directly and we will coordinate including it in the
module.
- - If this package is no longer useful, retire it by June 29th.
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com
wkYEAREIABAFAlsnm1oJEHolVWI2uqOjAAB7nQCgiuZkpu2fDDHM6F47I8GN
nD81quEAoIJtHaqfWscpZ/ZfjVRobMa3/NM4
=F1U7
-----END PGP SIGNATURE-----
= Proposed System Wide Change: Build non-RELRO ELF binaries with
.plt.got isolation =
https://fedoraproject.org/wiki/Changes/.plt.got_Isolation
Owner(s):
* Florian Weimer <fweimer at redhat dot com>
Fedora 23 enabled hardening for all packages. However, some ELF
binaries still use lazy binding. This change proposes additional
hardening for them.
== Detailed description ==
With the RELRO and BIND_NOW dynamic linker features, it is possible to
make the array of function pointers which is used to implement dynamic
linking (the GOT) read-only at run time. This makes it harder for
exploit writers to overwrite these function pointers and redirect
execution.
However, some ELF binaries are still built and linked without these
hardening features. Sometimes, this is due to package maintainer
preferences. Sometimes, there are technical reasons which preclude the
use of BIND_NOW because the way the application is written, it relies
on lazy binding.
This change proposes to link ELF binaries in such a way that the
<code>.plt.got</code> section is loaded as a separated page at run
time. As a result, it is possible to use a kernel feature called
[http://man7.org/linux/man-pages/man7/pkeys.7.html memory protection
keys] to make the GOT with its function pointer array read-only most
of the time. When the dynamic linker needs to perform a function
symbol binding, it can make the GOT temporarily writable, for the
current thread only.
Memory protection keys are currently available with the POWER
architecture (starting with POWER7), and on select Intel server CPUs.
At this time, only a subset of Fedora systems will benefit from this
hardening, so the recommendation to link with RELRO/BIND_NOW remains.
== Scope ==
* Proposal owners:
** We will work with the binutils maintainer to implement this change
in the linker, and enable it by default. (RELRO/BIND_NOW will
automatically disable it because it is not needed there.)
** The glibc dynamic linker will be updated to use this new feature.
This feature will likely arrive after the glibc 2.28 upstream release,
but it can be backported to Fedora because there is no ABI impact.
* Other developers:
In the unlikely case that an application relies on GOT patching, it
will have to specify a linker flag to disable this security hardening.
* Release engineering:
https://pagure.io/releng/issue/7575 #7575
(no release engineering impact is expected)
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
The packaging guidelines regarding build flags will not be updated.
RELRO/BIND_NOW remains the recommended approach.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
At today's FESCo meeting, we selected a new meeting time to accommodate the
schedules of the newly-elected members. As such, FESCo meetings for the next
cycle will be taking place on Mondays at 1500 UTC (1100 EDT, 1700 CEST).
However, in the interest of having shorter and possibly less-frequent
meetings, FESCo has opted to change its policy regarding ticket-handling,
effective immediately. The new policy is as follows:
* Most FESCo votes will be performed in the tickets. FESCo members will have
one week[1] from the creation of the ticket to vote. So long as at least three
members have voted, the majority of votes at the end of that week will be
counted as the result. If three votes are not received in the first week,
voting will be extended by one additional week and the minimum required
responses reduced to a single vote. If by the end of that second week no votes
have been counted, it will be treated as a vote *against* any change requested
by the reporter, thus preserving the current status however it stands. We do
not expect this clause to ever be invoked.
* Within the voting period, any FESCo member may add the 'meeting' keyword if
they believe that a proper decision will require in-person discussion in a
meeting. That topic will then be added to the agenda for the next regularly
scheduled meeting. No meeting will be held if there are no agenda items listed
by noon UTC of the preceding business day.
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com
wkYEAREIABAFAlsj8jYJEHolVWI2uqOjAACxgwCfY/59iYVCDUmPgZKShaz8
d9ikSpQAn3m1b6IPrsaWTUNeB3PoWL+t+Zsl
=BdWE
-----END PGP SIGNATURE-----
Here are the recent changes to the packaging guidelines.
-----
In Fedora 28 (and rawhide), the texinfo scriptlets (which call
install-info) are no longer necessary and should be removed or, for
cross-release specfiles, wrapped in conditionals. Note that there are
nearly 300 specs currently calling install-info in scriptlets; lists of
these packages will be posted separately to the devel list.
* https://fedoraproject.org/wiki/Packaging:Scriptlets#Texinfo
* https://pagure.io/packaging-committee/issue/773
-----
The section of the Python packaging appendix relating to manual byte
compilation has been amended with a new section applying to Fedora 29
and newer only. Because this is a rarely-trafficked section of the
guidelines and the change mandates modifications to a number of
packages, I will summarize here:
If your package installs files with names ending in ".py" outside of the
standard directories for python files (/usr/lib(64)?/python\d.\d) then
in rawhide you must disable automatic byte compilation of files outside
of these directories by adding "%global _python_bytecompile_extra 0" to
your spec and then, if necessary, manually byte-compile those files with
a specific python version using the %py_byte_compile macro.
There are 479 packages which will need attention to fix this before the
default value of %_python_bytecompile_extra becomes 0 (and potentially
breaks many of those packages) in a future release. Lists of these
packages will be posted separately on the devel list.
* https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compil…
* https://pagure.io/packaging-committee/issue/772
-----
A new guideline page relating to package deprecation has been added, and both the main guidelines and review guidelines have been updated to reference it.
* https://fedoraproject.org/wiki/Packaging:Deprecating_Packages
* https://fedoraproject.org/wiki/Packaging:Guidelines#Deprecating_Packages
* https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Things_To_Check_O…
* https://pagure.io/packaging-committee/issue/723
= Proposed System Wide Change: Binutils 2.31 =
https://fedoraproject.org/wiki/Changes/BINUTILS231
Owner(s):
* Nick Clifton <nickc at redhat dot com>
Rebase the binutils package from version 2.30 to version 2.31.
== Detailed description ==
Switch the binutils package from being based on the 2.30 release of
the FSF binutils to being based on the 2.31 release. This release
will bring in numerous bug fixes, as well as the following new
features:
The linker can now put all code and read-only data sections into a
separate segment with only READ and EXECUTE permissions. All writable
data can be placed into a separate segment with READ and WRITE
permissions. This makes programs larger, but safer. The linker's
behaviour can be controlled via a command line option, and the default
set by a configure option.
The assembler can generate build notes for any input files which do
not contain their own notes. Again this is controlled via a command
line option whose default is set by a configure option.
The x86 assembler supports a new -O[2|s] command-line option to enable
alternate, shorter instruction encoding. It also supports a ,nop
pseudo-op to simplify the insertion of NOP instruction sequences.
The AArch64 assembler will now warn a combintation of an instruction
and a register name are invalid. The AArch64 disassembler will now
also flag inconsistent instruction encodings.
The "ar" program will now accept an "O" modifier to its command line,
which causes the offsets of members within the archive to be displayed
alongside the other information.
== 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.This should be followed by a mass rebuild in order for the
changes to be noticed across the system.
* Other developers:
No other work should be necessary. Once the rebase is in place and
the buildroot contains the new binutils its use should be automatic.It
is possible that the new linker feature might prove to be problematic
forsome packages, although no such problems are anticipated. If this
doeshappen however the package maintainers can add a command line
optionto disable the new linker feature.
* Release engineering:
https://pagure.io/releng/issue/7573
** List of deliverables:
Just the binutils package.
* Policies and guidelines:
No updates needed.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Make BootLoaderSpec the default =
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
Owner(s):
* Javier Martinez Canillas <javierm at redhat dot com>
* Peter Jones <pjones at redhat dot com>
Use BootLoaderSpec fragment files by default to populate the
bootloaders boot menu entries.
== Detailed description ==
The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
Boot Loader Specification (BLS)] defines a scheme and file format to
manage boot loader configuration for each boot option in a drop-in
directory, without the need to manipulate bootloader configuration
files. These drop-in directories are the standard on Linux nowadays,
so the goal is to also extend this concept for boot menu entries.
This is especially important in Fedora because the same bootloader is
not used in all architectures. GRUB 2 is used in most of them, but
there are others such as zipl for s390x and Petitboot for ppc64le. Not
all bootloaders have the same configuration file format, so there is a
need for an indirection level and per bootloader specific logic to
edit these configuration files, when adding or removing a boot entry.
The current component that does this work is grubby, that has support
for all the different bootloader configuration file formats and
manipulates them on kernel installation or uninstallation. Besides
manipulating the bootloader configuration files, grubby also does
other things like running dracut to create an initial ramdisk image.
Fedora already has a lot of infrastructure in place to not require
modifying bootloader configuration files for boot menu entries. The
BootLoaderSpec and drop-in BLS fragments can be used instead, and the
kernel-install script can do any additional task that is currently
done by grubby. The kernel-install script has a pluggable design that
uses a drop-in directory for scripts to extend its functionality. So
if needed, any bootloader specific logic can be implemented as
kernel-install scripts.
With this setup the bootloader configuration could be static and not
modified after installation.
The missing piece was the lack of BLS support on all the supported
bootloaders, but all of them have support to parse BLS fragments now.
So we can default to install BLS files on kernel installation and drop
grubby.
== Scope ==
* Proposal owners:
** Generate BLS snippets at kernel build time and ship in the kernel packages.
** Make kernel-install scripts to copy the BLS, kernel and initramfs
images and do any architecture specific task.
** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot
menu entries from the information in BLS files.
** Have a grubby wrapper for backward compatbility that manipulates BLS files.
** Modify packages that use grubby to instead install BLS fragments
(memtest86+, tuned).
** Make sure this is all properly documented in release-notes, etc.
* Other developers:
** The anaconda developers will need to review and merge the patches
to change the default to BLS.
** Test and watch for regressions.
* Release engineering:
RelEng review ticket: https://pagure.io/releng/issue/7572
** List of deliverables:
N/A
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* Trademark approval:
No changes needed.
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Greetings, all!
The elections for FESCo - May 2018 have concluded, and the results
are shown below.
FESCo is electing 4 seats this time. A total of 86 ballots were cast,
meaning a candidate could accumulate up to 430 votes (86 * 5).
The results for the elections are as follows:
# votes | name
- --------+----------------------
290 | Till Maas (till/tyll)
286 | Stephen Gallagher (sgallagh)
254 | Randy Barlow (bowlofeggs)
234 | Petr Šabata (contyk/psabata)
- --------+----------------------
231 | Justin Forbes (jforbes)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
For more information please check the Voting App:
https://admin.fedoraproject.org/voting/about/fesco-may-2018
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Some Eclipse Foundation plug-ins have already made the switch from EPL to
EPL-2.0 and I have updated the licence field in the corresponding Rawhide
RPMs where I am aware of the change.
I expect that most plug-ins from the Foundation and the Eclipse Platform
itself will make the switch over the coming year. I don't plan to announce
each change individually so if you are interested in Eclipse Platform or
plug-in licensing, please pay special attention going forward.
Thanks
--
Mat Booth
http://fedoraproject.org/get-fedora
= Proposed System Wide Change: Golang 1.11 =
https://fedoraproject.org/wiki/Changes/golang1.11
Owner(s):
* Jakub Čajka <jcajka at redhat dot com>
Rebase of Golang package to upcoming version 1.11 in Fedora 29,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time).
== Detailed description ==
Rebase of Golang package to upcoming version 1.11 in Fedora 29. Golang
1.11 is schedule to be released in Aug.
Due to current nature of Go packages, rebuild of dependent package
will be required to pick up the changes.
== Scope ==
* Proposal owners:
Rebase golang package in f29, help with resolving possible issues
found during package rebuilds.
* Other developers:
fix possible issues with help from golang maintainers
* Release engineering:
Rebuild of dependent packages in side tag.
RelEng tracking issue https://pagure.io/releng/issue/7569
** List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: User PATH Prioritization =
https://fedoraproject.org/wiki/Changes/UserPathPrioritization
Owner(s):
* Sorin Sbarnea <ssbarnea at redhat dot com>
* Till Maas <opensource at till dot name>
* Miro Hrončok <mhroncok at redhat dot com>
Changing user PATH '''~/.local/bin''' to be moved to the top of the
PATH list instead of the end. This will bring Fedora in sync with
other distributions which already fixed this issues (Debian/Ubuntu)
and will allow users to install and use their own command line tools,
also fixing multiple bugs where user installed tools cannot be
accessed because the system installed ones took precedence.
== Detailed description ==
Currently if user is installing his own tools with installers like
(pip), they will be installed inside ~/.local/bin but if the same CLI
tools are installed at system level the user would not be able to use
his own tools because the system one would be picked instead. This
happens because .bashrc file adds user PATH to the end instead of the
top of PATH list variable.
Same problem was happening with other distributions but they fixed it
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155 Debian bug)
Example: "pip install --user virtualenv" would install virtualenv at
user level, adding ~/.local/bin/virtualenv executable. Still, if
virtualenv happens to be installed at system level, this would
currently be used instead of user installed one. On the other hand,
python itself already knows to prefer user installed modules which
means that "python -m virtualenv" will call user installed module
instead of the system one.
This may result in undefined behavior, where user installs foo, than
run foo, but /usr/bin/foo is run and that import from Python modules
in home. Those modules might have different API.
If we change the order and to assure the user folders do take
precedence, we would assure that python modules and shell scripts
would use the same modules, avoiding weird bugs where what you call is
not what you installed.
The issue is not unique to pip installed and applies to any tools that
are installed in de facto default XDG folder locations.
There should be '''no security concerns''' due to this change because
any user is already able to add executables and to alter its own PATH,
which means that if someone wants to trick a user to use another
executable, they are already able to do that. This has already been
proved several times in the
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
initial discussions about this change.
The change itself technically is in /etc/skel/.bash_profile from bash.
Currently:
PATH=$PATH:$HOME/.local/bin:$HOME/bin
After the change:
PATH=$HOME/.local/bin:$HOME/bin:$PATH
(Note that whether we move $HOME/bin or not has not yet been decided.)
Note that this change will only affect new user accounts, we cannot
change PATH for already existing accounts without crazy and undesired
hacks.
== Scope ==
* Proposal owners:
change /etc/skel/.bash_profile to have local folders before the system
ones in default PATH
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/7554 #7554
** 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
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Greetings, all!
The elections for Mindshare - May 2018 [1] have concluded, and the
results are shown below.
Mindshare committee is electing 1 seat this time.
A total of 107 ballots were cast, meaning a candidate could accumulate
up to 321 votes (107 * 3).
The results for the elections are as follows:
# votes | name
- --------+----------------------
205 | Sumantro Mukherjee (sumantrom)
- --------+----------------------
188 | Nick Bebout (nb)
114 | Itamar Peixoto (itamarjp)
Congratulations to the winning candidate, and thank you all candidates
for running this elections!
[1] https://admin.fedoraproject.org/voting/about/mindshare-may-2018
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Greetings, all!
The elections for Council - May 2018 [1] have concluded, and the
results are shown below.
Fedora Council is electing 1 seat this time.
A total of 110 ballots were cast, meaning a candidate could accumulate
up to 220 votes (110 * 2).
The results for the elections are as follows:
# votes | name
- --------+----------------------
164 | Till Maas (till)
- --------+----------------------
115 | Nick Bebout (nb)
Congratulations to the winning candidate, and thank you all candidates
for running this elections!
[1] https://admin.fedoraproject.org/voting/about/council-may-2018
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Changes/Update festival to 2.5 =
https://fedoraproject.org/wiki/Changes/Update_festival_to_2.5
Owner(s):
* Lukáš Tyrychtr <lukastyrychtr at gmail dot com>
Update the packaged festival speech synthesis system to the latest
upstream version. And just as a bonus make it actually work.
== Detailed description ==
Festival provides capabilities for speech synthesis and a framework
for synthetic voice creation. It generally provides higher quality
voices than Espeak.
== Scope ==
* Proposal owners:
Actually do the package updates (almost done) and get them in to Fedora.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/7551 #7551
** 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
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: NSS load p11-kit modules by default =
https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules
Owner(s):
* Daiki Ueno <dueno at redhat dot com>
When NSS database is created, PKCS#11 modules configured in the
system's p11-kit will be automatically registered and visible to NSS
applications.
== Detailed description ==
Fedora provides a mechanism to configure PKCS#11 modules system wide,
allowing the crypto libraries (GnuTLS and OpenSSL) to use PKCS#11
modules in a consistent manner. Until now NSS applications haven't
benefit from it as NSS uses a different configuration mechanism which
requires users to register PKCS#11 modules in NSS databases. This
change makes the manual procedure unnecessary, by registering the
p11-kit-proxy module (the aggregator of the system PKCS#11 modules) in
NSS databases with the default configuration.
See also:
* https://bugzilla.redhat.com/show_bug.cgi?id=1173577
== Scope ==
* Proposal owners:
** Enable p11-kit-proxy in the newly created NSS database, through the
crypto-policies package.
** Modify the opensc package not to register itself to the NSS
database upon installation.
* Other developers:
** Make sure that this change doesn't cause any regression with the
existing applications.
* Release engineering:
[https://pagure.io/releng/issue/7548 #7548]
** List of deliverables: N/A
* Policies and guidelines:
PackageMaintainers/PKCS11 needs changes basically to eliminate NSS
specific stuff
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: i686 Is For x86-64 =
https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
Owner(s):
* Florian Weimer <fweimer at redhat dot com>
Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
== Detailed description ==
Currently, the i686 RPM packages are built in such a way that they are
compatible with very old i686 systems, such as the Pentium III. The
only addition over the i686/Pentium Pro baseline is a requirement to
support long NOPs, for Intel CET. However, the majority of
installations of i686 packages is for use on x86_64 systems, as
multi-lib RPMs. Furthermore, there are reports that the i686 kernel
does not run stable on old hardware which is not x86-64-capable (
https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/t…
).
This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.
== Scope ==
* Proposal owners:
Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
new compiler flags. Except for mstackrealign, there is substantial
experience with this configuration downstream.
* Other developers:
Other developers can enable SSE2 optimization in their packages if
they want, where this has been a compile-time option only.
* Release engineering:
https://pagure.io/releng/issues/7543 #7543
** List of deliverables: TBD
* Policies and guidelines:
i686 is no longer a primary architecture. The Packaging Guidelines do
not currently require support for non-SSE2 x86 systems, so no change
is required there.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Strong crypto settings: phase 2 =
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Owner(s):
* Tomáš Mráz <tmraz at redhat dot com>
We update the current system-wide crypto policy to further disable
legacy cryptographic protocols (TLS 1.0 and TLS 1.1) and weak
Diffie-Hellman key exchange sizes (1024 bit)
== Detailed description ==
Fedora includes several cryptographic components who's security
doesn't remain constant over time. Algorithms such as (cryptographic)
hashing and encryption typically have a lifetime after which they are
considered either too risky to use or plain insecure. That would mean
we need to phase out such algorithms from the default settings, or
completely disable if they could cause irreparable issue.
While in the past we did not disable algorithms in a consistent way
(different applications utilized different policies), today we have a
system-wide policy followed by a large part of Fedora components. That
allows us to move consistently and deprecate algorithms system-wide.
For rationale see RFC 7457 for a more complete list of attacks taking
advantage of legacy crypto algorithms.
The changes for default policy are:
* Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols
and move the TLS 1.x, x<=1 to legacy level.
* Require finite field parameters (RSA, Diffie-Hellman) of 2048 and
more in the default settings
That is a policy of:
LEGACY
MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 255 bits (including bernstein curves)
Signature algorithms: SHA-1 hash or better (not RIPEMD)
Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES)
key exchange: ECDHE, RSA, DHE
DH params size: >=1023
RSA params size: >=1023
TLS protocols: TLS >= 1.0
DEFAULT
MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 255 bits (including bernstein curves)
Signature algorithms: with SHA-1 hash or better (not DSA)
Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20,
including aes-cbc)
key exchange: ECDHE, RSA, DHE
DH params size: >= 2048
RSA params size: >= 2048
TLS protocols: TLS >= 1.2
FUTURE
MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 384 bits (including bernstein curves)
Signature algorithms: SHA-384 hash or better (not DSA)
Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
key exchange: ECDHE, DHE
DH params size: >= 3072
RSA params size: >= 3072
TLS protocols: TLS >= 1.2
== Scope ==
* Proposal owners:
The policies include in crypto-policies package need to be updated.
* Other developers:
* Crypto policies are updated to the settings above
* https://bugzilla.redhat.com/show_bug.cgi?id=1487607 OpenSSL is
updated to allow setting policies for TLS versions
* Release engineering:
Copied from F28 change - no impact
https://pagure.io/releng/issue/7235 #7235
** List of deliverables:
* Crypto policies are updated to the settings above
* OpenSSL, NSS, GnuTLS and all applications covered under the Fedora
Crypto Policies follow the new crypto settings.
* Policies and guidelines:
No changes to packaging or other guidelines is needed.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic