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, 2 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, 8 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
3 years
New "tests" namespace to share test code
by Petr Splichal
Hi!
While working on adding CI tests [0] using the Standard Test
Interface a need arose to have a shared git repository where tests
could be stored:
* A large number of test files makes a dist-git repository more
difficult to maintain
* Tests might follow a different branching pattern than the
dist-git repo, leading to code duplication
* Shared maintenance for tests sometimes benefits from different
access levels than the release dist-git repository
The plan is to create a new “tests” namespace in Fedora git/pagure
dedicated to storing the shared test code. To enable execution of
these tests by the CI pipeline, tests.yml file in dist-git will be
used to link the tests in the standard way as defined by the
Standard Test Interface [1].
This approach should help to efficiently maintain tests & minimize
test code duplication. Using a dedicated git repo for test code
also means to keep dist-git more as a place for storing metadata
only: Build metadata (spec file = how to build the package) and
test metadata (tests.yml = how to test the package) rather than
mixing spec files with test code itself.
Please note that this does not mean that all tests should now go
into this new namespace. You can still link tests directly from
upstream (like GitHub) or any other source. Also, for unit tests
it makes more sense to be kept directly with the project source
and executed there. Shared tests namespace in Fedora will be
suitable especially for functional and integration testing which
should help to continuously ensure the OS works as a whole.
For more detailed motivation and real-life examples see the Share
Test Code proposal on the Fedora CI list [2]. If you have any
questions or comments feel free to share them here or in the
pagure issue requesting the new namespace:
https://pagure.io/fedora-infrastructure/issue/6478
Thanks.
psss...
[0] https://fedoraproject.org/wiki/CI
[1] https://fedoraproject.org/wiki/Changes/InvokingTests
[2] https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/...
3 years, 1 month
Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot@laposte.net
Hi,
I am proposing for inclusion a set of rpm technical files aimed at automating the packaging of forge-hosted projects.
- Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
- https://pagure.io/packaging-committee/issue/734
- go-srpm-macros RFE with the technical files: https://bugzilla.redhat.com/show_bug.cgi?id=1526721
This proposal is integrated with and depends on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft
It builds on the hard work of the Go SIG and reuses the rpm automation of https://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and produces compatible packages.
What it does:
- drastically shorter spec files, up to 90% in some cases, often removing hundreds of lines per spec.
- simple, packager-friendly spec syntax
- automated package naming derived from the native identifier (import path). No more packages names without any relation with current upstream naming.
- working Go autoprovides. No forgotten provides anymore.
- working Go autorequires. No forgotten requires anymore.
- strict automated directory ownership (used by autorequires and autoprovides).
- centralized computation of source URLs (via Forge-hosted projects packaging automation). No more packages lacking guidelines. No more broken guidelines no one notices.
- easy switch between commits, tags and releases (via Forge-hosted projects packaging automation). No more packages stuck on commits when upstream starts releasing.
- guidelines-compliant automated snapshot naming, including snapshot timestamps (via Forge-hosted projects packaging automation). No more packages stuck in 2014.
- guidelines-compliant bootstraping.
- systematic use of the Go switches defined by the Go maintainer. Easy to do changes followed by a mass rebuild.
- flexibility, do the right thing transparently by default, leave room for special cases and overrides.
- no bundling (a.k.a. vendoring) due to the pain of packaging one more Go dependency.
- centralized Go macros that can be audited and enhanced over time.
- aggressive leverage of upstream unit tests to detect quickly broken code.
Please consult packaging draft for full information.
The proposal has been tested in Rawhide and EL7 over a set of ~ 140 Go packages. This set is a mix of current Fedora packages, bumped to a more recent version, rewrites of Fedora packages, and completely new packages.
I hope posting the second part of the automation will answer some questions people had on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft
Regards,
--
Nicolas Mailhot
3 years, 1 month
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
3 years, 1 month
package conflict with source package but not with binary package
by Till Hofmann
Hi all,
I'm preparing Bear [1] as a Fedora package. Unfortunately, the package
name bear is already taken by the bear engine [2], so I'm considering
the best way to resolve this. Ubuntu [3], Debian [4], Arch (AUR) [5],
and Mint [6] all package the compilation database (i.e., the package I'm
working on) as bear, while the game engine (the current bear in Fedora)
is usually packaged as bear-factory. IMHO, providing the compilation
database as bear would be very beneficial, and anything else might be
confusing for the users.
I noticed that bear does not actually provide a bear package, but only
bear-engine, bear-devel, and bear-factory.
So, I'm wondering:
1. Can I add "Provides: bear = %{version}-%{release}", as bear does not
provide a bear binary package? To me, this seems risky and confusing,
but it would solve the issue.
2. If not, would it make sense to rename the current bear (source)
package into something else, e.g., bear-factory, so we can use 'bear'
for the compilation database?
I also asked upstream about possible alternatives [7], and the best
answer seems to be buildear, but imho that's far from ideal.
Kind regards,
Till
[1] https://github.com/rizsotto/Bear
[2] https://src.fedoraproject.org/rpms/bear
[3] https://packages.ubuntu.com/trusty/devel/bear
[4] https://packages.debian.org/sid/bear
[5] https://aur.archlinux.org/packages/bear/
[6] https://community.linuxmint.com/software/view/bear
[7] https://github.com/rizsotto/Bear/issues/198
3 years, 2 months