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
Good news for all interested in hardware compatibility and reliability.
I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool!
The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors.
Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation.
Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and others who had made this work possible by contribution to the database!
Hello everyone. Months ago, I started working on updates to a couple of
our mathematical packages. But they, in turn, required other packages to
be updated, and those updates required other packages to be updated, and
the whole thing kind of snowballed. I believe that I have finally reached
a point of closure, where I can update the whole pile and have everything
still work afterwards.
I propose to do the following updates and builds in Rawhide in about a
week. If maintainers of any of these packages object, please let me know
the nature of your objection.
The only explicit soname bump in these updates is libntl.so.35 to
libntl.so.36. However, there are a few other libraries that changed ABI
without a corresponding soname bump (typically with an soname of
libfoo.so.0, sigh), so I will rebuild all consumers.
- arb: update from 2.11.1 to 2.13.0
- brial: update from 0.8.5 to 1.2.3. Build for both python 2 and 3.
Add a %check script.
- cbmc: rebuild for glpk 4.65
- coin-or-lemon: rebuild for glpk 4.65
- eclib: update from 20170815 to 20171002
- fflas-ffpack: update from 2.2.2 to 2.3.2. Drop all patches.
- flint: rebuild for ntl 11.0.0. Attempt to work around bz 1555151 on
- gap-pkg-float: rebuild for libfplll 5.2.1 and mpfi 1.5.3
- gfan: build libgfan as a shared library and distribute it in a new
subpackage, which obsoletes the erroneous gfanlib subpackage of Singular.
- giac: rebuild for libfplll 5.2.1 and mpfi 1.5.3
- givaro: update from 4.0.2 to 4.0.4
- glpk: update from 4.61 to 4.65. Add a patch slated for 4.66, needed
by sagemath. Build with ODBC and MariaDB support.
- latte-integrale: rebuild for ntl 11.0.0 and glpk 4.65
- libfplll: update from 5.1.0 to 5.2.1. Drop the rounding patch, fixed
- libgap: require the GAP default packages (silences startup warnings
about missing packages).
- linbox: update from 1.4.2 to 1.5.2. Drop upstreamed fplll patch. Add
gcc8 patch as recommended by upstream to fix a C++ issue.
- Macaulay2: update from 1.9.2 to 1.11. Drop upstreamed verbose_build,
givaro, pari, and endian patches.
- mpfi: update from 1.5.1 to 1.5.3. Drop the aarch64 patch, fixed
- normaliz: update from 3.4.0 to 3.5.4. Drop all patches.
- ntl: update from 10.5.0 to 11.0.0
- octave: rebuild for glpk 4.65
- openms: rebuild for glpk 4.65
- pari: backport ellratpoints and hyperellratpoints from pari 2.10
alpha, needed by sagemath. The alternative is to update pari to an alpha
version, which makes me very uncomfortable.
- polymake: update from 3.1 to 3.2r3. Drop upstreamed gcc7 patch.
- ppl: rebuild for glpk 4.65
- pynac: update from 0.7.8 to 0.7.16. Drop arch conditionals for giac,
which is now available on all supported arches.
- python-cvxopt: update from 1.1.9 to 1.2.0
- python-cypari2: update from 1.1.3 to 1.1.4. Drop upstreamed offbyone
- python-cysignals: update from 1.6.4 to 1.7.1
- python-flask-autoindex: update from 0.4.1 to 0.6. Drop upstreamed
tests patch. Build for both python 2 and 3. Build and package the
- python-flask-silk: update from 0.1.2 to 0.2. Do not bundle
flask-sphinx-themes. Build for both python 2 and 3. Build and package the
documentation. Add a %check script.
- python-fpylll: update from 0.2.4dev to 0.4.0dev for libfplll 5.2.1.
- python-gmpy2: update from 2.0.8 to 2.1.0a2. The alpha version has
some functions required by the latest sagemath. Since the only consumers
of this package currently in Fedora are sagemath and sympy, which is
consumed by sagemath, I figure that if the sagemath team is going to
require an alpha version, they are only hurting themselves if something
- sagemath: update from 8.0 to 8.2. Numerous changes were necessary to
make this work.
- shogun: rebuild for glpk 4.65. Add two patches to fix FTBFS. The
sources use some deprecated json-c macros, which are no longer defined by
default; the first patch includes the relevant header. The second patch
works around a bug in pybtex, which has already been reported to upstream
pybtex and fixed in git. If a new pybtex release is made soon, I will
build it and drop this patch.
- Singular: drop the mistakenly exposed gfanlib package; build with
libgfan instead. Rebuild for ntl 11.0.0 and polymake 3.2r2. Drop the
sequence-point patch, which patches the libgfan sources.
NOTE ON MPFR: There is an update to mpfr 4 in the works:
https://fedoraproject.org/wiki/Changes/mpfr-4.0.0. The above updates help
that effort in the following ways:
- The mpfi update brings in a version that is compatible with both mpfr
3 and 4, so when the time comes, simply rebuilding against mpfr 4 will work.
- The sagemath update brings in a version that wants mpfr 4. For now, I
will patch it to use the old mpfr 3 interface. Once we have mpfr 4
available, all we have to do is remove that patch and rebuild.
Let me know of any concerns you might have about this pile of updates. As
usual with this particular set of packages, some builds take many hours, so
the rebuilds will probably span multiple days. Expect broken deps reports
out of Rawhide while in the middle. They will disappear once the entire
stack has been built.
It's been noted a few times before that we have a release criterion
that requires *updating* packages (or, these days, 'software', to cover
things like modules) to work...but we don't have criteria covering
other basic software management tasks, notably installing and removing.
There is a possible justification for this: so long as update works,
bugs in installation and removal can be fixed with updates. But really,
it seems reasonable to me that we should require basic
installation/removal of packages (and modules, and anything else we may
choose to consider release critical now or in future, e.g. flatpaks,
Shell extensions...) to work on release.
So, I'm proposing we modify the existing Basic and Beta criteria that
cover only updates, to also cover installation and removal. I like this
a bit more than adding separate criteria as the footnotes would be very
similar, and combining allows the footnotes to be shared.
So, the Basic criterion would change from:
"The installed system must be able to download and install appropriate
updates with the default console tool for the relevant update type
(e.g. default console package manager)."
"The installed system must be able to install, remove, and install
appropriate updates for software with the default console tool for the
relevant software type (e.g. default console package manager). This
includes downloading of packages to be installed/updated."
the Beta criterion would similarly change from:
"The installed system must be able to download and install appropriate
updates with the default tool for the relevant update type in all
release-blocking desktops (e.g. default graphical package manager)."
"The installed system must be able to install, remove, and install
appropriate updates for software with the default tool for the relevant
update type in all release-blocking desktops (e.g. default graphical
package manager). This includes downloading of packages to be
the footnotes would be tweaked to refer more generically to 'software'
and stuff instead of 'updates', just kinda logical changes to reflect
the broadened criterion; I can go into detail on that if anyone wants.
Obviously if the criterion change is agreed upon, we will add test
cases to the test matrices.
Thoughts, comments, suggestions, acks and nacks? Thanks!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
= Proposed Self Contained Change: Deprecate YUM 3 =
* Daniel Mach <dmach at redhat dot com>
Remove yum (v3) and all related packages from Fedora.
== Detailed description ==
Remove packages from the distribution:
All these packages should no longer be used and all software using
them should be migrated to DNF.
== Scope ==
* Proposal owners:
Remove packages from the distribution: createrepo, yum, yum-langpacks,
yum-utils, yum-metadata-parser, python-urlgrabber
* Other developers:
Either remove packages from the distribution or switch them to DNF
* Release engineering:
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
* Trademark approval:
N/A (not needed for this Change)
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Fedora package maintainers,
FESCo approved an updated policy for packages which fail to build from
source during mass rebuilds (FTBFS) .
The updated policy is still at https://fedoraproject.org/wiki/Fails_to_build_from_source.
- packages which FTBFS are subject to orphaning if there is no
maintainer acknowledgement within 8 weeks
- packages which FTBFS in two consecutive mass rebuilds will be
retired soon after the second mass rebuild
The implementation of this policy hinges on improving the releng
scripts used to create and manage FTBFS bugs. There is approximately
two months until the next use of those scripts, so I'm hopeful we'll
get them working.
If your package wasn't successfully built for F28, please fix that!
Users of OpenSHift Origin require CRI-O 1.10 right now. But Kubernetes
users want to try out the latest packages for kubernetes 1.11 which
would require CRI-O 1.11. Origin might not be ready to move to
Kubernetes 1.11 for a while.
Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
releases in the same Fedora 28.
I believe this is what Modularity was designed to fix.
Can I do this with Modularity? If I can how do I use fedpkg to make
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded
python2 subpackages, or let us drop them for you" .
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
Here are the details.
The current maintainers of python2 would like to "orphan" the python2
package in 2020 (~ Fedora 30):
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.
Unlike most other orphanings, we have some thousands of dependent
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at .)
Of course, we're ready to make various compromises with interested
packagers, as long as there's an understanding that we won't just
support python2 forever.
If you are a maintainer of anything at  we ask you kindly to consider
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora >
29. (On the current schedule, Fedora 30 will be the first release still
supported after 2020-01-01.)
If no one steps up to maintain python2 after 2020, we're prepared to
package a "legacy" python27 package, similar to what we do for e.g.
python33 , to:
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time