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.
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?
Over the past week, we've been dealing with a kernel bug 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 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 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.
I'll be updating gsl to 2.1 in Rawhide on Monday and rebuilding
dependent packages. See
https://bugzilla.redhat.com/show_bug.cgi?id=1276893 for some tracking
info. A fair amount of work was done to get everything ready for this
update, but there may be a couple stragglers.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
We're at the last stages of preparing the first major owncloud update in a
The current version of owncloud in Fedora is the fairly old stable 8.0
release (presently 8.0.10) which we want to bring back in line with the
current owncloud upstream release of 8.2.2.
Unfortunately it's not possible to migrate directly from 8.0.x to 8.2.x as
upstream only supports jumping in increments with no skipping of major
In order for a smooth transition to 8.2.x (and after that 9.0.x when it's
released) we'll be releasing 8.1.5 to F23 and F22 within the next couple of
We plan to leave this in updates-testing for a slightly longer period than
usual to allow for a wider test base for a major version jump. Please
remember your backups prior to the upgrade!
Once 8.1.5 is pushed to updates 8.2.2 will be pushed to updates-testing for
a similar extended period. It's imperative that the 8.1.5 update is applied
before the 8.2.2 update is pushed to updates.
If you want to assist in the testing and provide feedback or bug reports
please use the usual channels of bodhi and bugzilla - both easily
accessible from pkgdb:
Looks like it failed on armv7 with this error, but it was working before...
In file included from
../../dist/include/mozilla/Endian.h: In function 'void
swapFromNetworkOrderInPlace(T*, size_t) [with T = short unsigned
../../dist/include/mozilla/Endian.h:175:45: fatal error: You must
enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use
The glibc in Fedora rawhide and F24 is now split by
language packs. We have over 180 supported languages
in glibc, and those have been split into langpacks
for transparent install and support via dnf. This
greatly reduces the size of a glibc install from 130MB
down to a couple of megs. It drops support for the hacky
%_inst_langs feature, and relies entirely on langpack
support (it was one or the other).
Thanks to Mike Fabian for the great work!
Bug 1238406 - Glibc locale subpackaging
Changes/Glibc locale subpackaging
- If you don't use langpacks you won't get any locales
except C, POSIX and C.UTF-8.
- If you don't want to use langpacks just install the
glibc langpack you want manually.
e.g. dnf install glibc-langpack-en
- Anaconda should take care of everything for you via
- We missed the fact that for the F23->F24 transition
`dnf system-upgrade` should install glibc-all-langpacks
(meta package) to give F23 users a smooth transition
with all the locales they had before, but once in F24
the langpacks will be used.
Bug 1312103 - “dnf system-upgrade” needs to install
“glibc-all-langpacks” when upgrading from f23 to f24
I have unpushed from f24 and rawhide dnf-1.1.7-1 and revoked the requests for updates.
The main reason being that the api changed ina way that broke our ability to create install
lorax --product=Fedora --version=24 --release=24 --
--variant=Workstation --nomacboot --noupgrade --buildarch=athlon --volid=Fedora-
2016-02-25 16:46:06,909: Added 'lorax-repo-0':
2016-02-25 16:46:06,909: Fetching metadata...
repo: downloading from remote: lorax-repo-0, _Handle: metalnk: None, mlist: None, urls
repo: using cache for: lorax-repo-0
not found deltainfo for: lorax-repo-0
not found updateinfo for: lorax-repo-0
timer: sack setup: 31470 ms
Getting group metadata
Adding group file from repository: lorax-repo-0
timer: loading comps: 108 ms
2016-02-25 16:46:38,948: checking for root privileges
checking for root privileges
2016-02-25 16:46:38,948: checking the selinux mode
checking the selinux mode
2016-02-25 16:46:38,949: checking dnf base object
checking dnf base object
2016-02-25 16:46:38,949: setting up build architecture
setting up build architecture
Traceback (most recent call last):
File "/usr/sbin/lorax", line 353, in <module>
File "/usr/sbin/lorax", line 209, in main
File "/usr/lib/python3.5/site-packages/pylorax/__init__.py", line 252, in run
self.arch = ArchData(buildarch)
File "/usr/lib/python3.5/site-packages/pylorax/__init__.py", line 65, in __init__
self.basearch = dnf.arch.basearch(buildarch)
AttributeError: module 'dnf' has no attribute 'arch'
An API change like that is a point release is not acceptable, certainly not without working
With the users of the code to ensure that you do not break peoples code. Given where we
are in the Fedora 24 cycle where we need to be reliably composing the OS in order to have a
Alpha compose in a few short weeks.
I would like to work out ways to allow development to go forward but we need to ensure
that changes are syncronised with the users as we do so.