Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
2 years, 1 month
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
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
2 years, 6 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, 7 months
Reliability test for hard drives and SSD
by Andrey Ponomarenko
Hi there!
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!
2 years, 8 months
Updates to mathematical software
by Jerry James
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.
Changes:
- 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
arm.
- 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
upstream.
- 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
upstream.
- 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
patch.
- 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
documentation.
- 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
goes wrong.
- 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.
Regards,
--
Jerry James
http://www.jamezone.org/
2 years, 8 months
