Package Details: rstudio-desktop 1.2.1335-1

Git Clone URL: (read-only)
Package Base: rstudio-desktop
Description: Open source and enterprise-ready professional software for the R community
Upstream URL:
Licenses: AGPL
Conflicts: rstudio-desktop-bin, rstudio-desktop-git, rstudio-desktop-preview-bin
Submitter: None
Maintainer: flying-sheep
Last Packager: flying-sheep
Votes: 43
Popularity: 0.043952
First Submitted: 2011-03-04 15:02
Last Updated: 2019-04-10 11:05

Required by (0)

Sources (4)

Pinned Comments

Xentec commented on 2019-07-08 01:13

Got same error...

make: *** [Makefile:152: all] Error 2

With a bit of backtracking...

BUILD FAILED /tmp/makepkg/rstudio-desktop/src/rstudio-rstudio-f1ac345/src/gwt/build.xml:98: Error running javac compiler

So my javac binary decided to disappear even with jdk-openjdk installed, huh? Turns out I still had wrong Java version set as default and after executing

# archlinux-java set java-8-openjdk

ant was finally willing to build gwt and the Rstudio installation was complete.

Latest Comments

« First ‹ Previous ... 4 5 6 7 8 9 10 Next › Last »

jelly commented on 2011-03-15 11:12


before ./configure, to fix the boost errors

jelly commented on 2011-03-15 11:01

did you notice GWT is in AUR?

Anonymous comment on 2011-03-14 21:07

I was working on a way to check for ant and java and the method reztho is what first occurred to me, but it doesn't quite work as expected since makepkg will now exit immediately upon an error. So if we test the exit code for an error and then output a message, makepkg will exit immediately upon the error and the message will never get printed. This is the compromise I think works well:

# Check if ant and java can be found
msg "Checking if java and ant are on the PATH...."
which ant > /dev/null
which java > /dev/null

This will output nothing if ant and java are found (stdout goes to /dev/null), but if they are not found an error message will be printed by "which" to stderr and then makepkg will exit as a result of which not returning 0.

Anonymous comment on 2011-03-14 19:42

The ant link was my fault :P It was a hack to get it working the first time, but I did not include it in my rstudio git pkbuild, I should have noted on the forum that it was a bad idea. The warning is a much more sane way to handle this, I only have a note in the comments of the git pkgbuild.

Anonymous comment on 2011-03-10 20:24

Thanks reztho, I've altered it and it'll be uploaded later when it's no longer peak time here. I did wonder about it, because it was included in the forum dedicated to this, but when I built the package manually first hand from source, the first time it worked I didn't do anything about ant.

reztho commented on 2011-03-10 17:21

# link apache ant?
if [ ! -e /usr/bin/ant ] ; then
msg "Creating a link so that make can find apache ant"
ln -s /usr/share/java/apache-ant/bin/ant /usr/bin/ant

For god's sake, do not do that. Makepkg isn't supposed to be run under a root account. And those people who do it are going to have an unmanaged symbolic link by pacman which can make problems in the future.

Instead just check ant is accesible and if it's not, throw a warning message to the user if you want to and exit gracefully. Something like this should work:
which ant &> /dev/null
if [ $? -gt 0 ]; then
msg "whatever"
exit 1

Apache-ant package comes with a bash script (/etc/profile.d/ which needs to be sourced before doing anything the first time is installed or the user just needs to relogin for it being sourced automatically.

Makepkg just fakes root perms; it doesn't make a chroot. AUR isn't supposed to be user friendly and it's your responsibility not to mess with people's filesystem, that's why there aren't any AUR helper in community.

Anonymous comment on 2011-03-09 05:19

As of boost v 1.46 it breaks the compile, suggesting some major compatibility issue between R-Studio and the latest boost, this has been raised on their support site.

Anonymous comment on 2011-03-08 18:01

I believe the current java-runtime dependency should work (i.e. jre or openjdk6 both should be fine). I think the issue you are having might be that the jre package does not put the 'java' executable on the path (I believe it puts it at /opt/java/jre/bin/java by default. You need to add this location to your path if you are using the jre package, otherwise cmake will not be able to find your java installation. The openjdk package however puts the executable right in /usr/bin which is on most everyone's path already, so things will work out of the box.

Anonymous comment on 2011-03-07 22:20

It is possible that openjdk6 is required, it is not listed as a dependency however in the PKGBUILD, as it is unclear from experience building it, whether it is required or not, and how it is required. Thus if you have issues, a first stop might be to look at installing openjdk6 if you don't already have it. At the next major version release, a neater tarball and source will make dependencies clearer.

Anonymous comment on 2011-03-05 03:48

Hi, I did origionally do this when I first tried to build the package for the first time - and then again with the PKGBUILD. Now downloading the tar, and trying to do it from source was unsuccessful, there would be errors trying to pull it from the net on my machine - and nobody else I asked on the forums regarding this package seemed to do it that way either, they would access the source from github. Then when I tried to use that file with the PKGBUILD, because of the awkward naming and version numbers of files etc. It meant many additional user defined variables, and ran into errors pulling it from the internet as well. I could try again if you like, and post a PKGBUILD on the relevant forum thread, in the AUR Discussion section of the forum when I have a minute. Alternatively if you try it and then we can comapre how it went. Unfortunately there has been a lot of disparity in success in getting this to build, either from PKGBUILD and from source without the aid of makepkg, for example sometime the scripts to install dependencies seem to be an issue, then one other time there seems to be an issue with on person with him not being a sudoer, even when he says he is. Looking at the support website, theres even issues with the pre-built binaries for Fedora, Ubuntu, Mac and Windows, so even installing isn't the end of the story. I contacted them about this method of getting the git from github, and then having scripts install dependencies is very awkward for such as the Arch build system to make our packages from source. I also asked them for a stable tarball, half-expecting them to point me towards the tarball you have just pointed out - and I already tried. However they did not, so I can't help but think there may be reason as to why not. However, they got back to me empaphising and assured me that a stable tarball for the source for a much smoother compile and package creation, is intended and will be looked into as soon as some other issues are fixed, to quote them, in the "near future". The fact it's still very much in development explains the fact it's only available from github. To save users from having to have an account with github and set a ssh key etc, I have done so, and made a small bash script that updates the git on my machine and puts it into a folder that can be downloaded. There is a PKGBUILD on the forum thread that uses the git clone method, bt as I said this requires an account and ssh keys setting up before hand. Eventually, with a stable tarball, I will be able to change this and everything will become a lot smoother.