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 week, 2 days
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
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 months, 4 weeks
RANT: Packaging is changing too fast and is not well documented
by Richard Shaw
<RANT>
So I went to request a new branch of an existing package only to find out
fedrepo-req-branch, which hasn't been around that long is already
depreceated and the facility brought into fedpkg... so:
$ fedpkg request-branch <branch>
Could not execute request_branch: The "token" value must be set under the
"fedpkg.pagure" section in your "fedpkg" user configuration
Ok, so where does that get stored?
$ man fedpkg
(not in there...)
$ vi /usr/share/doc/fedpkg/README
(not in there...)
I figured out somewhere else that the default config is in
/etc/rpkg/fedpkg.conf (In /etc/rpkg? That's intuitive!) but I didn't want
to add my token to the site wide config so the search continues...
$ rpm -ql fedpkg
(pokes around)
$ vi /usr/lib/python2.7/site-packages/fedpkg/__main__.py
...
def main():
default_user_config_path = os.path.join(
os.path.expanduser('~'), '.config', 'rpkg', '%s.conf' % cli_name)
...
Found it!
Now which token do I need? The one from the src.fedoraproject.org pagure or
pagure.io?
Oh and the tokens expire all the time and don't seem to have any helper
scripts to automate updating of the tokens so I have to remember where they
all are and manually edit them every time...
</RANT>
Not coming from a programming background I found the learning curve pretty
steep when I first tried to become a packager, I'm not sure I wouldn't have
given up if I had to do it now.
Thanks,
Richard
9 months, 2 weeks
[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
10 months, 3 weeks
Orphaning ofono
by Rex Dieter
I will be orphaning the ofono package today. I'd primarily packaged it with
the the intention that it may become a new dependency of pulseaudio (which
never happened), and I've not been able to give it the time it needs.
Recently updated to latest 1.22 release which fixed a long-standing FTBFS
issue, so at least it is in good shape for anyone interested in picking it
up.
-- Rex
10 months, 3 weeks
COPR src.fp.o auto-rebuilds
by Michal Novotny
Hello,
you can now very easily setup auto-rebuilds for your src.fp.o package:
1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork
(please, use the https:// cloning option)
2) make sure "Webhook Rebuild" checkbox is checked when you are creating
the package
3) Go to settings for your package at src.fp.o and almost at the bottom in
Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update"
button.
If your package is a main package (not a fork), then you can omit step 3.
See https://pagure.io/copr/copr/issue/142 for more info.
COPR team
11 months
[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.
Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies
The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.
If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.
Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).
List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-----END PGP SIGNATURE-----
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
11 months
