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
1 year, 11 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
2 years, 4 months
[RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
by Björn 'besser82' Esser
Hello everyone,
since there has been some discussion in the last time about removing
libcrypt from glibc in some time [1,2,3,4] and splitting it out into a
separate project which can evolve quicker, I'd like to hear your
oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora
29 (or 30).
libxcrypt will be fully binary compatible with software linked against
glibc's libcrypt and does not require any rebuilds. However, the
converse is not true: programs linked against libxcrypt will not work
with glibc's libcrypt. It comes with a set of extended interfaces
pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt,
crypt_gensalt_rn, and crypt_gensalt_ra. Also, programs that use
certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r,
setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
The crypt and gensalt functions are supporting all (except for Crypt16,
which was used on Ultrix and Tru64, only) widely used password hashing
algorithms [6], which before were specific to just some operating
system's implementations of libcrypt [7].
There are preperations to add password hashing with PBKDF2 using HMAC-
SHA3-512 to libxcrypt as well.
Anyways, before this can happen, there is still some work to be done
with libxcrypt, like adding a FIPS mode or FIPS compliance in a
different way.
Cheers,
Björn
[1] https://sourceware.org/ml/libc-alpha/2017-06/msg00055.html
[2] https://sourceware.org/ml/libc-alpha/2017-06/msg00079.html
[3] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
[4] https://sourceware.org/ml/libc-alpha/2017-08/msg01408.html
[5] https://github.com/besser82/libxcrypt
[6] https://en.wikipedia.org/wiki/Crypt_(C)#Key_derivation_functions_s
upported_by_crypt
[7] https://en.wikipedia.org/wiki/Crypt_(C)#Support_in_operating_syste
ms
2 years, 9 months
CUPS will change license since 2.3 version - now incompatible with
GPLv2
by Zdenek Dohnal
Hi,
CUPS upstream changed license of project to Apache license 2.0, which is
now incompatible with GPLv2. This change will be in new minor release of
CUPS - 2.3.0, which is currently in developing phase (not in Fedora for
now). If someone takes code of CUPS and has its project under GPLv2,
please change it to GPLv3 (which should be compatible according
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
) or try to argument with CUPS developers against this change on their
mailing list cups(a)cups.org .
Is there someone who is influenced by this change?
--
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C
2 years, 10 months
Package review requests: Splitting the "sustmi" GNOME Shell
extensions into separate packages
by Andrew Toskin
I'm the RPM package maintainer for these two GNOME Shell extensions:
* gnome-shell-extension-sustmi-windowoverlay-icons
* gnome-shell-extension-sustmi-historymanager-prefix-search
They're both currently subpackages of the main "sustmi" package, because upstream had been developing them in a single git repository. The two shell extensions have nothing to do with each other, though, and upstream finally decided to split them into separate repositories. So I think it now makes sense to also split them into separate packages.
I'm not entirely clear on the procedure. This wiki page
https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitt...
talks at first about *font* packages, but otherwise seems relevant. So, I've started by splitting and updating the spec files, and creating these review requests. As I understand it, because the packages were already accepted into Fedora, and the extension code hasn't changed, just the packaging, I think all a reviewer should really need to check is whether the upgrade path is sane and works properly.
* HistoryManager Prefix Search -- https://bugzilla.redhat.com/show_bug.cgi?id=1506428
* WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
Please take a look, and let me know if I've missed anything.
Thanks,
~ Andrew / terrycloth
2 years, 11 months
F28 System Wide Change: Annobin
by Jan Kurik
= Proposed System Wide Change: Annobin =
https://fedoraproject.org/wiki/Changes/Annobin
Change owner(s):
* Nick Clifton <nickc AT redhat DOT com>
This change causes extra information to be stored in binary files
compiled by gcc. This information can be used by scripts to check on
various features of the file, such as the hardening options used of
potential ABI conflicts.
== Detailed Description ==
The plan is to use a plugin to gcc to record extra information in the
object files it creates. This information can then be examined by
static analysis tools. The information is recorded in a compact,
extensible format, described here:
https://fedoraproject.org/wiki/Toolchain/Watermark
The Fedora annobin package is an implementation of the plugin for gcc.
It also includes some example scripts that demonstrate how the
recorded information can be used to, for example, check that an
executable has been compiled with the correct hardening options, or
detect if any conflicting ABI options have been used when compiling
various parts of the executable.
To enable this change it is proposed that the redhat-rpm-config
package should be extended to add the "-fplugin=annobin" option to the
__global_compiler-flags macro. In theory such a change will be
completely invisible to Fedora users but should prove to be very
helpful to Fedora Release Management, assuming that they like the idea
of these annotated binaries.
== Scope ==
* Proposal owners:
Make sure the annobin plugin is ready.
* Other developers:
An update is needed to the redhat-rpm-config package in order for the
plugin to be invoked when gcc is used to compile programs, and to add
a dependency upon the annobin package.
* Release engineering: https://pagure.io/releng/issue/7069
- Coordination with release engineering is needed.
- A mass rebuild will be required.
* List of deliverables:
All delivered images are affected, however there no changes to the list it self.
* Policies and guidelines:
No updates needed
* 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
2 years, 11 months
Rstudio
by Steve Grubb
Hello,
I like to have everything on my system in a package. So, I looked around and
found no recipe or rpm for Rstudio. This is really a shame because every
tutorial on R kinda tells you to install it. Even the Coursera classes in the
Data Science track make you install it and send a screenshot to prove it.
So, I spent some time getting it packaged and working. I am placing the spec
file and necessary patch here so that google finds it and saves other people the
trouble. I'm not wanting to submit the package to Fedora because its more work
than I have time for. If anyone else wants to take it from here and submit
and/or maintain it, feel free.
http://people.redhat.com/sgrubb/files/Rstudio/
Enjoy...
-Steve
2 years, 12 months