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
6 days, 22 hours
Automating Package Review (Was: fedora-review -- do we have a maintainer?)
by Stephen Gallagher
On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote:
> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>
>> f-r currently fails to build (#1603956), it has a bunch of bugs open [1]
>> and many issues and unhandled pull requests in the upstream repo [2, 3].
>> The last upstream commit was 2 years ago.
>>
>> f-r has is annoyingly outdated and gives often outright bad advice
>> (for example about BR:gcc or BR:g++). The situation would be
>> significantly
>> improved if the outstanding PRs were merged.
>>
>> f-r is also python2-only now, which will be a problem soon since
>> support for python2 is waning [4].
>>
>> Is there any hope of upstream and downstream activity on f-r?
>>
>
> I was thinking about getting the fedora-review checks rewritten into the
> standard Test interface
> (
> https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-inter...)
> so that they
> can be run in Taskotron. We can also just probably run one big
> fedora-review check from
> a taskotron test, well, this just came to my mind recently, getting the
> actual solution ready
> might take a little bit of time.
> '
>
I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you pass a
URL to an SRPM plus authenticate with your FAS account and it will perform
all of the validity checks and if they all pass would go ahead and request
the branches for you and import the SRPM.
Once this is fully automated, we can then *also* add the same checks to CI
(taskotron, OSCI or whatever) so that on each build it gets rerun, which
will allow us to help reduce the rate of packages falling out of compliance
(as well as being updated whenever the checks get made more comprehensive).
Historically, we've had human review mainly to protect against two things,
bundling and unacceptable licenses. In both of these cases, I'd like for us
to move towards a culture of assuming goodwill on behalf of our packagers.
Most of the packagers in Fedora have been doing it for a long time and know
what is and is not acceptable. Optimizing for the minority case is
wasteful, especially when it adds hurdles and delays to getting software
delivered.
I think what we should instead do is allow things through immediately
following automated review and just assume that those few cases that slip
through that should not will get handled after the fact as soon as they are
noticed (either by someone noticing or an improvement in the automated tool
discovering the problem).
I feel strongly that automated, continuous review would be of far greater
value to Fedora than front-loading the review process the way we have been
doing (which serves mostly to discourage people from even starting).
1 month, 4 weeks
Orphaning nitroshare
by Raphael Groner
Hi,
I'll orphan nitroshare. There are no dependencies except the subpackages.
Reasons for my decision: Upstream did no release since monthes and claims instable branch for master in the documentation.
There are some other good alternatives like KDE Connect or TotalCommander with WebDAV.
Regards, Raphael
4 months, 1 week
poppler soname bump in rawhide
by Marek Kasik
Hi,
I'm going to rebase poppler in rawhide to poppler-0.67.0 now.
There are several API changes and soname bump of the base library
libpoppler.so.*.
I've checked all packages which depend on the libpoppler.so.* and have
backported/prepared fixes to reflect poppler's API changes.
Unfortunately, libreoffice does not build currently (#1615616). But I've
decided to push the rebase though because branching will happen today
and I could not do chain build after that for F29.
Btw, if your package use the unstable API (headers from poppler-devel),
could you consider to change it to use a stable API (glib, qt, C++)?
Regards
Marek
4 months, 1 week
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
4 months, 1 week
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
4 months, 2 weeks
Changes in packages workflow vs. modular Fedora
by Miro Hrončok
Hi,
I was thinking about this for a while and I got the impression that this
is something I don't know the answer for. The question is a bit harder
to formulate simply, so let put it in examples:
a) A need packaging guideline is about to be discussed. A member of FPC
wants to know how many packages would be affected so they run a quick
grep query over all the rawhide specfiles at [0].
b) A CVE is found in a web framework, so bugz are filled for the
"framewrok" package to be fixed in Fedora 27, because newer Fedoras have
newer version of the framework where the CVE is not applicable.
c) A new version of interpreted language lands in rawhide. All packages
depending on the interpeter need mass rebuild in a side tag.
d) A packager decides to retire a library and they check nothing in
Fedora requires it.
I wonder how are such situations meant to be handled with modules?
Do we build modules for rawhide? If so, should Fedora changes (such as,
but not limited to, "the Changes") somehow handle all the modules, or is
it the modular maintainer responsibility to make sure their module works
on the next Fedora version?
For the above examples, here are some more specific situations with more
specific questions:
a) I was planning to propose a more strict "No more automagic Python
bytecompilation" [1] change for Fedora 30 where we would query all
packages that depend on the old behavior and mass add "%global
_python_bytecompile_extra 1" to all of them, so we could switch the
default to be 0. Normally, we would do it in Rawhide only. But how do I
handle modules? How do I find out what modular packages rely on the old
behavior?
b) A CVE was filled for Django [2]. How does the security team
responsible for tracking CVEs figure out we have Django 1.6 in modular
Fedora? How is a bugzilla filled against a modular package anyway?
c) When we recently mass rebuilt Python 3 packages for Python 3.7,
should we go and seek for modules that use Python 3 (how do I do that?)
and rebuild the packages in the modules (or even the modules?)?
d) (this example is not real (yet)) We decide to retire (remove)
python2-sphinx because upstream Sphinx no longer supports Python 2. We
make sure that nothing in Fedora requires or buildrequires it, as all
Fedora's Python packages use python3-sphinx or no Sphinx at all. However
there is a Django 1.6 module where python-django uses python2-sphinx to
build the docs, while python2-sphinx is not part of the module itself.
How do we find out about this and is it our reprehensibility to keep it
in rawhide or add it to the module?
Sorry if those things are obvious, yet I don't know the answers. There
might be even more examples where traditionally we would only think
rawhide, but now with modules the problem seems more complex.
[0] http://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz
[1]
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompi...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1609031
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 months, 3 weeks
