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.
since last Monday or so, I have been able to run firefox over ssh
anymore. I thought it was my setup, but further investigation showed
that it is something specific to firefox.
My setup is a bit more convoluted than this, but I am able to do:
$ ssh -X localhost gnome-terminal
And it shows a terminal as expected
$ ssh -X localhost firefox
Without a firefox running will hang there forever, no output at all. I
tried doing strace of it, and see that is waiting for futexes. But
haven't been able to see what is happening.
Until last Tuesday or so (I am on F23) firefox worked over ssh without
any problems. I have been running it like that for something like a
Anyone has any suggestion? I tried also
$ ssh -Y localhost firefox
And it didn't helped at all (not that I am sure of the difference either).
PD. Really, what I normally do is run ssh to a virtual manchine in the
I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175
It's not a huge deal (and there are several workarounds, for git and for
other tools which default ot using 'gpg'), but it highlights the mismatch
between the default /usr/bin/gpg running gpg1, when other tools, like
gpg-agent, are tailored for gpg2.
RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in
I'm not saying we shouldn't continue to ship gnupg1, but can we at least
rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1
instead? This seems overdue. Is there any reason not to do this?
I am one of the maintainers of the ntl package, which is used by some
numeric applications (e.g., Macaulay2 and sagemath). Upstream
supports use of the PCLMUL instruction, the AVX instructions, and the
FMA instructions to speed up various computations. We can't use any
of those in Fedora, since we have to support a baseline x86_64.
Well, that's kind of a downer. I could advertise that people with
newer CPUs ought to rebuild the ntl package for their own CPUs, but
what's a distribution for if people have to rebuild packages? I've
been looking for a way to automatically support more recent CPUs.
Yesterday I sent a patch upstream that uses gcc's indirect function
support together with __attribute__((target ...)) to build vanilla
x86_64, PCLMUL-enabled, AVX-enabled, and FMA-enabled varieties of
several functions. Upstream was initially excited about this but
then, on further reflection, offered the opinion that this approach is
dangerous. The problem is that some of the types involved may change
ABI depending on the instruction set in use, and therefore it would be
necessary to build larger portions of the library for each supported
CPU variant. At that point, as upstream said, we might as well just
build the entire library for each variant. The problem then is how to
choose which version of the library to use at load time.
On some platforms, ld.so offers "hardware capabilities", such as sse2
on i386. By dropping a vanilla library into /usr/lib and an
SSE2-enabled build into /usr/lib/sse2, applications can get the
version of the library appropriate for the CPU in use. But there
don't seem to be any defined hardware capabilities for x86_64.
Has anybody already thought this through? What's the best approach to
take? For this package, the speedups are substantial, so this is
worth doing, if it can be done well.
= Proposed Self Contained Change: Replace UDisks2 by Storaged =
* Peter Hatina <phatina redhat com>
* Tomáš Smetana <tsmetana redhat com >
Storaged extends UDisks2 API by exporting several enterprise features
(in form of plugins), such as LVM2 and iSCSI. This project is a
drop-in replacement for UDisks2, either from D-Bus or binary point of
view. The main motivation of this change is to provide the unified
D-Bus API for all the clients who are willing to manage LVM2, iSCSI,
Btrfs, BCache, LSM and ZRam.
== Detailed Description ==
Aim of Storaged is to provide unified higher level management
interface for various clients who are willing to query and manage
storage bits of the system. We plan to replace UDisks2 by Storaged,
since the Storaged itself is the fork of UDisks2 and these 2 projects
in its core haven't diverged so much (Storaged got some improvements
which popped up while using it).
== Scope ==
Proposal owners: To implement this Change
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
List of deliverables: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide 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
With the 4.5 kernel out and the merge window for 4.6 opened up, we had
to make a decision on what the release kernel for F24 would be. The
decision has been made to ship F24 with the 4.5 kernel with 4.6
available as an update once it is ready. Timing wise, 4.6 *should*
release just before the final freeze for F24, but that is cutting it
insanely close. Should Fedora move on as scheduled, and 4.6 have some
delay due to a bug that impacts users, that would be unfortunate.
This means we have a good bit of time to make sure that everything is
working as intended with 4.5 in Fedora. It also means that any
installer critical fixes will need to be backported to 4.5.
We're wrapping up the first phase of the Fedora Docker Layered Image
Build Service and the time has come to start thinking about what we as a
Project need to do to formalize what it means to be shipping Docker Layered
Images once we are capable of building and distributing them.
These are effectively going to compliment their RPM counterpart at least
in the beginning since we as a Project have never shipped any build artifact
other than RPMs as a part of the distribution before. We can grow organically
from there if we want to extend beyond the initial offering for Docker
Layered Images but I thought following RPM as a guide in the beginning was a
reasonable goal to achieve. Some areas that seemed pertinant right off the
bat are below, for each of them I have alread created a Draft document that
I would appreciate feedback on.
Docker Layered Image "packaging" Guidelines 
Package Review Process with a Docker Containers section 
Docker Layered Images Naming Guildelines 
The Fedora Cloud SIG has done a first-pass review of these (thanks Cloud
SIG!) so hopefully there's a certainly level of sanity to them but I'm
absolutely open to new ideas and extending the content with more coverage.
Another point to note is that we need to determine how this should be handled
in BZ components for bug reporting as well as for filing review requests.
Something else what was brought up when I originally submitted these ideas to
FESCo (aside from the fact that this should go to devel list first) was
that it is probably a good idea to establish a Container-centric Guidelines
Committee much in the way there is a Fedora Packaging Committee (which focuses
on RPMs). My question to everyone on that topic is, would there be enough
interest to establish such a committee?
As a side note and just a matter of opinion but I think the idea of forming
a Committee to help shepherd these new types of deliverables through Fedora
will help to enable aspects of Fedora Modularization which ultimately will
be good for the whole of the Fedora Project.
I look forward to questions and feedback.
 - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
 - https://fedoraproject.org/wiki/PackagingDrafts/Containers
 - https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_wit...
 - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGu...
 - https://fedorahosted.org/fesco/ticket/1573
I'm pretty much stumped on a problem where freecad (really python-pivy)
segfaults on F24 but seems to run fine on F23 and I can't find any
substantive difference between any of the packages.
Strangely installing Coin3 from f23 on a f24 system seems to fix the
Any pointers/help would be appreciated.