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
5 years, 1 month
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
5 years, 1 month
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
5 years, 5 months
Python3 will be in next major RHEL release, please adjust %if
statements accordingly
by Troy Dawson
Hello,
Python3 will be in the next major RHEL release. I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following
if 0%{?fedora}
%define with_python3 1
%endif
If you have something like that, please change it to something like this.
if 0%{?fedora} || 0%{?rhel} > 7
%define with_python3 1
%endif
Thank You
5 years, 5 months
Starting a Container SIG
by Clement Verna
Greeting all,
The container effort in Fedora has until now been looked after by the
Atomic WG, since this Working Group is now going to focus mostly on
Fedora CoreOS, I propose to create a new container SIG to regroup
people interested in the maintenance of application containers in
Fedora.
This SIG would look after the container guidelines [0], the container
review process [1] and also the release process and tooling.
Please Reply if you're interested with helping out making the
Container story great in Fedora. If there is a good response, I will
create a Container SIG wiki page, and I guess we can ask for
container-devel mailing list for SIG discussions.
Regards,
Clément
[0] - https://fedoraproject.org/wiki/Container:Guidelines
[1] - https://fedoraproject.org/wiki/Container:Review_Process
5 years, 7 months
kcov: code coverage for programs and python/shell scripts
by Dridi Boukelmoune
Greetings developers,
I just submitted a review request [1] for kcov [2] that I recently
discovered. It has no relation to Linux's kcov and is more akin to
lcov, except that all it needs is a binary with DWARF debuginfo
instead of requiring compile-time instrumentation.
I came across kcov when I was looking for a way to measure code
coverage in a Rust project and I'm impressed. It supposedly has a low
overhead, but so far I've been monitoring small single-threaded
programs so I can't really tell. I haven't tested python and shell
support, although I have cases where it would be relevant, but I don't
have time yet.
The package itself is simple, but it bundles javascript and doesn't
build on all main platforms so I may have to be granted an exception
from some group starting with an F. Been busy lately, I'm a little
behind on anything Fedora. If that's the case, please RTFM me a link
to the wiki, and if you want to take the review I'll gladly take one
in return.
Cheers,
Dridi
[1] https://bugzilla.redhat.com/show_bug.cgi?id=kcov
[2] https://simonkagstrom.github.io/kcov/index.html
5 years, 7 months
Intent to retire python-svg
by Julien Enselme
Hi all,
I intend to retire python-svg. Tests are failing on Python 3.7 for a
reason I cannot figure, there was no commit during the last year and
according to `repoquery --whatrequires python2-svgwrite` and `repoquery
--whatrequires python3-svgwrite` nothing uses it anymore.
If you want to maintain it, please step up.
Regards,
--
Julien Enselme
http://www.jujens.eu/
5 years, 7 months