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 days, 1 hour
Rstudio
by Steve Grubb
Hello,
I like to have everything on my system in a package. So, I looked around and
found no recipe or rpm for Rstudio. This is really a shame because every
tutorial on R kinda tells you to install it. Even the Coursera classes in the
Data Science track make you install it and send a screenshot to prove it.
So, I spent some time getting it packaged and working. I am placing the spec
file and necessary patch here so that google finds it and saves other people the
trouble. I'm not wanting to submit the package to Fedora because its more work
than I have time for. If anyone else wants to take it from here and submit
and/or maintain it, feel free.
http://people.redhat.com/sgrubb/files/Rstudio/
Enjoy...
-Steve
5 months
SciDAVis and liborigin3 vs liborigin & liborigin2 - bundle or obsolete?
by Alexander Ploumistos
Hello,
Since its retirement from Fedora, SciDAVis[0] has undergone
significant development and I think it is ready to be re-included in
our package collection. After a few months of private builds that I
distributed among co-workers and friends, I set up a copr[1] and I've
been keeping up with the upstream project.
SciDAVis comes with a bundled copy of liborigin[2], which the upstream
developers helped me unbundle. Its version has been bumped to 3.0.0
internally, although there hasn't been a 3.0.0 release yet. In Fedora
we carry liborigin2 (code from the latest public release) and
liborigin (snapshot from 2008) which both help import different
versions of Origin project files. The new release will render them
both obsolete.
SciDAVis and liborigin share a number of contributors, but at the
moment their codebases have diverged; upstream liborigin trunk has
been adjusted to work with development versions of LabPlot 2.x, while
the copy bundled with SciDAVis is closer to that of a future
liborigin-3.0.0 release, but they are not interchangeable. I asked the
developers to clarify their plans and I was told[3] that the two
versions will merge back, though some API changes might come in the
meantime.
I have checked if there are any packages at the moment that require
liborigin* or liborigin*-devel and I have found none (though I'd be
grateful if someone who feels more at ease with dnf could
double-check). If not for this divergence, I would submit scidavis and
liborigin3 for review as separate packages, with Provides & Obsoletes
for the previous liborigin* and liborigin*-devel versions and be done
with it. However I would have to use the unbundled copy from SciDAVis
as source for liborigin3. Should I proceed with that anyway or should
I keep it bundled until such time as the two codebases have merged?
Best regards
Alex
0. https://sourceforge.net/projects/scidavis/
1. https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/
2. https://sourceforge.net/projects/liborigin/
3. https://sourceforge.net/p/scidavis/discussion/708155/thread/4c8da018/#cf6b
5 months, 1 week
Using devtoolset for EPEL builds
by Zuzana Svetlikova
Hi,
I need/want/would like to build new node 6 for EL6, but gcc is too old.
For that reason, I'd like to use devtoolset-4-gcc, but the build fails
(obviously) because the package doesn't exist.
So, is there a way to make that work somehow?
I am not sure about enabling external repos during build, maybe someone
will be wiser.
Here's the build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=15970697
Zuzka
5 months, 2 weeks
apitrace, bundled libbacktrace
by Sandro Mani
Hi,
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
request?
Thanks,
Sandro
6 months
F27 System Wide Change: NSS Default File Format SQL
by Jaroslav Reznik
= System Wide Change: NSS Default File Format SQL =
https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
Change owner(s):
* Kai Engert <kaie(a)redhat.com>
Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).
Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
storage.
Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".
As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
recovered.
By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.
The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.
== Scope ==
* Proposal owners:
A small downstream patch needs to be applied to the NSS library
package, which changes the library default.
* Other developers:
It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.
* Release engineering: [1]
No help should be necessary. No mass rebuild necessary.
* Policies and guidelines: N/A
* Trademark approval: N/A
[1] https://pagure.io/releng/issue/6883
Thanks,
Jaroslav
6 months, 4 weeks
CI projects in Copr
by Miroslav Suchý
Hi,
I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For
building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your
project?
Please let me know. Either here or via private reply.
It will help me to understand your use of Copr and to make Copr better.
Thanks in advance.
Miroslav Suchy
7 months, 2 weeks
Re: Is it possible atlas is linked wrongly by new binutils?
by Richard W.M. Jones
On Thu, Aug 10, 2017 at 11:21:30AM +0200, Jakub Martisko wrote:
>
>
> On 9.8.2017 11:37, Richard W.M. Jones wrote:
> >
> > ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
> > fails to link to atlas:
> >
> > + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
> > /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
> > collect2: error: ld returned 1 exit status
> >
> > However this only happens with the very latest atlas that was built by
> > binutils 2.29 (atlas-3.10.2-18.fc27.x86_64). It doesn't occur with
> > the previous version of atlas (atlas-3.10.2-16.fc26) even though there
> > seems to have been no change in atlas.
> >
> > $ nm -D /usr/lib64/atlas/libtatlas.so | grep larfy
> > U clarfy_
> > U dlarfy_
> > U slarfy_
> > U zlarfy_
> >
> > I looked in /usr/lib64 on my development machine which has atlas
> > installed but there is no .so* file that I can find which defines
> > these symbols. I also couldn't work out where in the atlas code
> > (which is a bit strange) these references are used.
> >
> > Hence the question: Is this breakage in atlas? binutils?
> >
> > Rich.
> >
>
> OK so it seems that according to git commit messages LAPACK
> has been rebased from 3.6.0 to 3.7.1 day before that mass
> rebuild [1][2]. Those "larfy" subroutines have been added to
> LAPACK in 3.7.0 and have not been present before[3]. I've
> tried to make a scratch build of atlas [4] and the missing
> symbols seem to be present...
>
> $ nm -D ./libtatlas.so.3|grep larfy
>
> T clarfy_
> T dlarfy_
> T slarfy_
> T zlarfy_
It looks as if you scratch build just changes ‘rm’ to ‘rm -f’ at one
point in the spec file. Is that change also needed?
I can do a bump and rebuild of atlas with or without that change - let
me know.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
7 months, 3 weeks
'No More Alphas': wiki revision drafts
by Adam Williamson
Hi, folks! So I've (finally) got ready an initial round of draft
changes to various wiki pages for the purpose of implementing the 'No
More Alphas' Change. You can find all the drafts in the NoMoreAlphas
category:
https://fedoraproject.org/wiki/Category:NoMoreAlpha
For each page I cloned the original text and saved it as the first
edit, so you can use the 'History' tab's diff feature to see the actual
changes to each page (just compare the current state to the first
edit).
To summarize the changes, at least as I remember them, and call out
some significant choices:
* Obviously, all Alpha-related points on the schedule template on the
Fedora Release Life Cycle page were removed. For schedule points that
were previously derived from Alpha points that got removed, I adjusted
them to derive from some other still-remaining point.
* My proposal for 'what do we do about release criteria / validation'
is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed
'Basic Release Criteria' (note: not versioned, I don't think it should
be), and we document that *all* composes - not just Beta and Final
candidate composes, but also Rawhide and Branched nightlies - will be
automatically tested for (and release of them gated on) compliance with
them. Which is more or less what's proposed in the Change. All external
references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is
what changed on the other criteria pages, and on the test matrix
template pages). Practically speaking, we currently have automated
testing for *most* of the existing Alpha criteria, but a few items
aren't covered. We can choose to move these to the Beta criteria, or
leave them on Basic and just accept that *actual* coverage doesn't
quite meet what we aspire to. I do *NOT* propose to have any kind of
blocker tracking bug for the Basic release criteria; it doesn't seem to
fit in the process, there is no Alpha release to block, and we can't
realistically block nightly composes on manual test results. So a
tracker bug wouldn't really have any reason to exist. In the case where
a violation of the Basic criteria makes it into composes despite the
automated testing, it should be marked as a Beta blocker.
* There is a problem with what to do about the Change schedule: our two
sources for it don't actually agree on what the schedule *is*. The
Changes Policy page - https://fedoraproject.org/wiki/Changes/Policy -
claims that the 'Completion deadline' "falls on the same day as the
Alpha milestone freeze", but the Fedora Release Life Cycle page -
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle - claims it
falls on the same day as the branch point, which is two weeks *before*
the Alpha freeze. Given this inconsistency I didn't really feel
confident proposing a draft for the Changes/Policy page yet; probably
it'd be good for FESCo(?) as owners of the Change process to decide
when they actually want the key dates of the Change process to be, In A
World Without Alphas. If FESCo wants to figure that out and let me
know, I can draft the changes.
Please do look these over and provide any kind of feedback! Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 months, 1 week
