Phoronix recently release article 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
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?
Best regards / S pozdravem,
I just submitted a review request  for kcov  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.
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
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
While working on adding CI tests  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 .
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 . If you have any
questions or comments feel free to share them here or in the
pagure issue requesting the new namespace:
= System Wide Change: Replace glibc's libcrypt with libxcrypt =
* Björn Esser <besser82 AT fedoraproject DOT org,>
* Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
== Detailed Description ==
Since there has been some discussion in the last time about removing
libcrypt from glibc in some time and splitting it out into a separate
project which can evolve quicker, Zack Weinberg and I put some work
into libxcrypt to make it a basically suitable replacement.
It comes with a set of extended interfaces pioneered by Openwall
Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and
The crypt and gensalt functions are supporting all (except for
Crypt16, which was used on Ultrix and Tru64, only) widely used
password hashing algorithms, which before were specific to just some
operating system's implementations of libcrypt.
== Scope ==
* Proposal owners:
- Apply needed packaging changes to glibc
- Review, import and build libxcrypt for Fedora 28
* Other developers:
Test their applications using one of the following interfaces for
unexpected changes in functionality:
* Policies and guidelines:
N/A (not needed for this Change)
* Trademark approval:
N/A (not needed for this Change)
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols. Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time. (rhbz#1535422)
### Disable strict symbol checks in the link editor (ld)
By default, the link editor will refuse to link shared objects which
contain undefined symbols. In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected. In this case, you can
to the RPM spec file to disable these strict checks. Alternatively,
you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
command line). The latter needs binutils 2.29.1-12.fc28 or later.
This is also part of the build flags documentation at:
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
- 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
Good Morning Fedorans!
On Thursday, a new version of Bodhi was deployed that enabled Bodhi to
gate updates based on test results. You may notice a "Test Gating
Status" message in the right have side of the page.
One thing to know about this is that there is currently a confusing
issue where Bodhi will say that the tests have failed when the tests
haven't finished running. We are working on solving that issue, but
for now you can just wait a while and it should report the result once
all the tests have finished.
There are three tests that must pass in order for updates to go to stable:
0. dist.depcheck - to make sure the update's dependencies are available.
1. dist.abicheck - to make sure the update's ABI remains stable in a
given Fedora release.
2. AtomicCI pipeline - packages that are part of the Atomic Host *and* include
in their dist-git tests, must have these tests passed in the AtomicCI pipeline
This last requirement only concern packages that are in the Atomic Host while
the first two is enforced for all packages.
We are also working on another CI pipeline that will allow running tests stored
in dist-git for all packages without discrimination.
You are in control of these three tests. The first two can be fixed by
making changes in the spec file, and the latter test is controlled via
the tests in your repo.
Finally, if it turns out you need to push an update through despite of the test
results, you can do so using waiver-cli (dnf install waiverdb-cli). We are
working on integrating this into Bodhi itself, making this easier.
We have started a wiki page to store all of this information and that we will
keep up to date as improvements are done or for any frequent questions coming up:
Please accept my apology in the delay in writing this message. It should
have been sent last week when it was enabled, and it got lost.
Thanks for your attention,
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org