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
1 year, 5 months
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
2 years, 5 months
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
2 years, 6 months
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
2 years, 6 months
PkgDB and the ArbitraryBranching Change
by Ralph Bean
Hello,
As part of the Factory 2.0 and Modularity efforts[1], we’ve been
developing a plan to migrate to an “arbitrary” branching model from
our current model of one branch per release (as had been discussed at
Flock and DevConf[2]).
The main motivation behind this is to enable functionality required by
Modularity[3] and to ultimately reduce some package maintenance
burden. For some packages, it makes sense to have only a single branch
that feeds into multiple releases. For other packages, it makes sense
to have multiple branches which correlate with multiple upstream minor
releases. Today, our source branches are tied to the distro release,
via PkgDB. We want to decouple that and use modules to put it all
back together again.
To make this happen requires significant infrastructure changes. Our
proposed plan[4] is to decommission PkgDB entirely and to replace it
with a combination of PDC[5] and pagure over dist-git. (Tangentially,
getting pagure over dist-git to play nicely with PkgDB was a
challenge. This route gets us to a pull-request interface for spec
files quicker.)
We have brought this Change to FESCo[6][7][8] who expressed general
agreement on the project but also concern that the community may be
caught by off guard by the removal of PkgDB. As part of this change,
we have proposed a timeline[9] that outlines the steps we plan to take
to actually proceed with the migration. Please review that if you have
time and provide feedback. We are most concerned with missing
scripts/tools that may rely on PkgDB’s API. If you can think of any
that we may have overlooked, please let us know and we will add it to
the timeline!
We are meeting again with FESCo next Friday, June 2nd, where a
decision will be made on the Change. Any feedback before that would be
greatly appreciated.
Ralph and Matt,
From the so-called Factory 2.0 team
[1] https://fedoraproject.org/wiki/Infrastructure/Factory2
[2] https://youtu.be/5gqccjyjwFk?t=26m27s
[3] https://docs.pagure.org/modularity/
[4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBra...
[5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
[6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching
[7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html
[8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html
[9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
2 years, 10 months
Two more concrete ideas for what a once-yearly+update schedule would
look like
by Matthew Miller
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".
Option 1: Big batched update
1. Release F26 according to schedule
https://fedoraproject.org/wiki/Releases/26/Schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
even.
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
release.
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
press push).
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 11 months
