does anyone use the xulrunner package? (and gecko-devel actually).
Mozilla does not maintain it any more and the XUL as technology is going
to be removed/deprecated. I'd like to remove the package from Fedora 24.
So far my idea of maintaining Fedora's iproute package was to do full
version updates only in Rawhide and backport patches selectively to
stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just
backported patches), there is an understandable amount of frustration
amongst users when the shiny new kernel that comes with e.g. F22
provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of
stable versions, I'm in a bit of a dilemma here: update to keep in sync
with the kernel or not update to not unnecessarily destabilize the
Any comments/advice are highly appreciated.
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
-- Those who don't understand recursion are doomed to repeat it
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.