Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
1 year, 12 months
F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
Owner(s):
* Matus Honek <mhonek at redhat dot com>
OpenLDAP will not ship non-threaded version of libldap. Instead,
libldap will be built with the same threading support as libldap_r.
== Detailed description ==
After this change the non-threaded version of libldap will not be
shipped any more. Instead, this library will rather be built the same
way as the threaded libldap_r. This has been previously discussed in
Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and
other distributions where this change already happened. Upstream still
supports non-threaded version of their library as it 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) symbol names overlap which may result in
unpredictable behaviour. Immediate solution would be to symlink
libldap to libldap_r, however SONAME of the library would be the same,
hence breaking dependencies of other packages. For that reason the
solution hereby proposed should be the most convenient one.
== Scope ==
* Proposal owners:
update SPEC file so that non-threaded libldap is replaced with threaded one.
* 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
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
2 years
F29 System Wide Change: Remove Excessive Linking
by Jan Kurik
Note from Change Wrangler: This Change Proposal requires mass rebuild.
However, two weeks ago (June 19th), we have already passed the
deadline for Change proposals requiring mass rebuild. I will leave the
decision whether this Change proposal is accepted or not to RelEng and
FESCo teams.
= Proposed System Wide Change: Remove Excessive Linking =
https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
Owner(s):
* Igor Gnatenko <ignatenkobrain at fedoraproject dot org>
* Neal Gompa <ngompa13 at gmail dot com>
Pass "--as-needed" flag the linker through default system-wide LDFLAGS.
== Detailed description ==
The flag ("--as-needed") tells the linker to link in the produced
binary only the libraries containing symbols actually used by the
binary itself. This binary can be either a final executale or another
library.
The use of the "--as-needed" flag allows the linker to avoid linking
extra libraries in a binary. This not only improves startup times (as
the loader does not have to load all the libraries for every step) but
might avoid the full initialization of big frameworks.
== Scope ==
* Proposal owners:
Add "-Wl,--as-needed" into RPM_LD_FLAGS (in redhat-rpm-config).
* Other developers:
Nothing should break, but immediate work-around would be to disable
this flag (will be provided in redhat-rpm-config) and fix real issue
later.
* Release engineering:
#7604 [https://pagure.io/releng/issue/7604] (mass rebuild is desired
after this change).
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
Add information how to turn it off (TODO link to FPC ticket).
* 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
2 years
Intel's Clear Linux optimizations
by František Zatloukal
Hi,
Phoronix recently release article[1] about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
settings.
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
[1]
http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1
--
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
2 years
F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
by Ben Cotton
== Summary ==
This change enables TLS 1.3 (draft28) support on the gnutls crypto library.
== Owner ==
* Name: Nikos Mavrogiannopoulos
== Detailed Description ==
This change will enable the TLS 1.3 protocol (draft28) on the gnutls
library. TLS 1.3 is the latest version of the TLS protocol which
addresses few shortcomings of the previous versions. The protocol has
already been approved by IETF and is on its final publication stage,
with only minor editorial changes expected. The change for gnutls
depending is transparent to existing applications.
More information for applications using gnutls:
* https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html
== Benefit to Fedora ==
* This brings the latest TLS protocol support to applications
depending on gnutls, when crypto policies are updated for TLS1.3.
== Scope ==
* Proposal owners:
* Other developers: N/A (not a System Wide Change)
== Upgrade/compatibility impact ==
That change should have no impact on upgrade or compatibility. The TLS
1.3 protocol is designed in a way that does not cause incompatibility
issues with existing (and even broken) implementations.
== How To Test ==
* Existing work-flows which include secure communications should be tested
* Command line applications which use TLS (e.g., wget, lftp), should
be tested against web-sites using TLS 1.3 (e.g., www.google.com)
== User Experience ==
That change should not be noticeable by users except for applications
which report the connected protocol. Other things users will notice
- Latency on TLS sessions will be reduced
- Performance of establishment of TLS sessions will be improved due
to ed25519/x25519 support
- Privacy of TLS sessions will be improved from the perspective of
passive eavesdroppers; no client certificate will be sent in the clear
- Transparent rekey of long-running sessions
== Dependencies ==
GNOME, samba, rsyslog, wget, lftp, ...
== Contingency Plan ==
If the expected transparent addition of TLS 1.3 cannot be assured
(e.g., important issues are reported), the enablement of TLS1.3
protocol will be postponed for the next fedora release.
* Contingency mechanism: The gnutls maintainer will not enable TLS1.3
by default in the build
* Contingency deadline: Fedora 29 beta
* Blocks release? No; the contingency plan is sufficient and can avoid
a release block
== Documentation ==
* https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html
* https://www.gnutls.org/manual/gnutls.html#Upgrading-from-previous-versions
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
2 years, 5 months