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
1 year, 4 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
1 year, 6 months
Xulrunner - intent to remove from Fedora 24
by Martin Stransky
Hi,
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.
ma.
1 year, 11 months
iproute package update policy
by Phil Sutter
Hi,
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
system?
Any comments/advice are highly appreciated.
Thanks, Phil
2 years, 3 months
whatever happened to yum + btrfs snapshotting?
by Neal Becker
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
2 years, 3 months
Firefox not working anymore over ssh?
by Juan Quintela
Hi
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
year.
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).
Later, Juan.
PD. Really, what I normally do is run ssh to a virtual manchine in the
same host.
2 years, 11 months
GPG2 as default /usr/bin/gpg
by Christopher
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
RHEL6.
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?
2 years, 11 months
Kernel plans for Fedora 24
by Justin Forbes
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.
Thanks,
Justin
3 years, 1 month
osgaudio packaging (bundles/provides openalpp)
by François Cami
Hi,
I'd like to package osgaudio, which is an OpenSceneGraph-like frontend
to OpenAL.
It is currently maintained by OpenSceneGraph's main author at:
https://github.com/robertosfield/osgaudio/
It requires and contains openalpp, a C++ frontend for OpenAL.
We haven't shipped openalpp since Fedora 7.
The original project for openalpp hasn't been updated since 2005 or so.
I've searched for a better fork of openalpp and haven't found any.
My proposal is to install openalpp alongside osgaudio, in separate
subpackages with appropriate Requires. That way, we provide a choice
between a C++ interface to OpenAL or a SceneGraph approach to 3D
sound.
I believe this approach is not in violation of:
https://fedoraproject.org/wiki/Bundled_Software_policy
as osgaudio and openalpp would live in separate packages (built from
the same srpm), in effect both becoming system libraries.
Any comment very much welcome.
François
3 years, 1 month
Validity of i686 as a release blocker
by Josh Boyer
Hello,
Over the past week, we've been dealing with a kernel bug[1] that
prevents i686 machines from booting. Help was requested and given,
and it has been excellent and most welcome. This email has no
reflection on that, and is instead focused on the reality of where
i686 stands today.
In February[2] we sent out an email highlighting that the kernel team
was not going to treat i686 bugs as a priority. Since that time, we
have held true to our word and have not focused on fixing i686 bugs at
all. It seems that the wider community is also treating i686
similarly. The kernel bug that was made automatic blocker because of
existing criteria was present in Fedora since the 4.1-rc6 kernel,
which was released May 31. It has been in every boot.iso created
since that date. Not a single person reported this issue until last
week. That is a timespan of two months.
The kernel team has autotesting for i686 kernels, but the environment
there does not utilize boot.iso so it did not detect this. The QA
team has automated testing for some of this, but nothing for the i686
architecture at all. It is not a priority there either.
Perhaps it is time that we evaluate where i686 stands in Fedora more
closely. For a starting suggestion, I would recommend that we do not
treat it as a release blocking architecture. This is not the same as
demotion to secondary architecture status. That has broader
implications in both buildsys and ecosystem. My suggestion is
narrowly focused so that builds still proceed as today, but if there
is something broken for i686 it does not block the release of whatever
milestone we are pursuing.
(To be clear, I would support a move to secondary arch status for
i686, but I am not suggesting it at this time.)
Making i686 non-release blocking would actually match reality. None
of the Fedora Editions appear at all concerned with i686. Cloud is
demoting[3] i686 from its offering. Workstation has been fairly
ambivalent about it and recommends x86_64. Server does the same.
Given the lack of focus on it, and the fact that the broader community
is not testing the development releases for i686, I believe this would
be a good first step.
josh
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382
[2] https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
[3] https://fedorahosted.org/cloud/ticket/106
3 years, 1 month
