Arch Linux User Repository

A note for users.

This package is quite complex. It MAY not be built because of OTHER issues. I always build, install and test it on at least two different machines. Only after that I would push a new version to AUR.

Please try some generic solutions before reporting of build problems:

1) Update all other packages (sudo pacman -Syu),

2) Clean up yay and/or makepkg caches ('yay -Sc', 'rm -rf /var/tmp/makepkg'),

3) Be sure you've got enough RAM (8 GB or more is highly recommended) and space on disk (at least 3 GB).

4) Is your Internet connection is stable, fast and not blocked somewhere?

PLEASE READ THIS MESSAGE BEFORE COMPLAINING FOR LIBBOOST

When boost is updated to a new version and you see an error message about missing libboost*.so, you will need to rebuild and reinstall the rstudio-desktop package.

Build logic is slightly changed due to changes in upstream. As they've introduced new project format (quarto), it contradicted with standard Arch package base. In brief, quarto contains pandoc as part of itself, so it's pretty hard to keep together system pandoc and embedded quarto.

So I've "resolved" it such way: if there is "quarto*" package installed, then rstudio-desktop will pick it up and use. Otherwise (not installed), quarto support in rstudio will be disabled.

'quarto' is added as optional dependency.

I don't use this package. It builds on a server, and someone else noticed it doesn't work with quarto. So I'm trying to "fix" the package on the server. If it's too complicated, I'll just leave it alone.

Yes, if it was built without quarto, it couldn't recognize quarto projects.

If the package is built with quarto-cli-bin quarto still optional, or does it become a runtime dependency?

In short, if quarto is detected at configuration time, several extra menus, options and dialogs are added to RStudio binary. Runtime dependency is still optional: you can remove quarto package after, however RStudio will run OK. User may have got an error message in R console if try to open and render quarto project, though.

I don't use this package. It builds on a server, and someone else noticed it doesn't work with quarto. So I'm trying to "fix" the package on the server. If it's too complicated, I'll just leave it alone.

If the package is built with quarto-cli-bin is quarto still optional, or does it become a runtime dependency?

Is it possible to build the quarto modules separately, as an addon package??

Is there a way to "support" quarto without having to build this package with it?

I afraid, no. Quarto must be explicitly included or excluded at configuration time. If you include it, quarto will be called to create several internal RStudio modules and libraries during the build process.

I thought a bit of forking rstudio-desktop to e.g. rstudio-desktop-full and rstudio-desktop-no-quarto, but ended up with current "solution".

At least I can see some logic here: configure => check module => available => include it : not available => not include.

P.S. If you believe you can make it better, you're welcome to adopt this package (but don't forget to take quarto-cli, quarto-cli-pre-release and quarto-cli-git as well)

:)

Didn't realize I was stumbling into a years-old issue... Is there a way to "support" quarto without having to build this package with it?

When using a clean chroot, quarto is not installed while building this package. From what I can tell, the resulting package will not support quarto, even when quarto is installed. If this is the case, should quarto be added to makedepends?

@xiota, this is kind of issue with no good solution. Quarto itself is not an example of solid and stable software. Some users do not want to build RStudio with it due to dependency problems.

On the other hand there are people who are not happy with binary Quarto package (quarto-bin). At the moment Quarto doesn't build with esbuild>=0.18 (I had to roll back esbuild to 0.17 in dependencies of quarto-cli-pre-release until they fix the issue in upstream).

If I add quarto as makedepends, building of RStudio will become much harder than now.

After some discussion here few years ago I ended up with adding quarto as optional dependency.

As an override you might build or download quarto package and then feed the chroot with it:

CHROOT=$HOME/src/chroot
QUARTO_PKG=quarto-cli-pre-release-1.4.161-1-x86_64.pkg.tar.zst
makechrootpkg -c -r $CHROOT -I $QUARTO_PKG

When using a clean chroot, quarto is not installed while building this package. From what I can tell, the resulting package will not support quarto, even when quarto is installed. If this is the case, should quarto be added to makedepends?

@nunonun, yep, that's kind of known "feauture" of github. Fixed by skipping of archive checksum.

When trying to update RStudio, I get the following errors:

:: Downloading PKGBUILDs...
PKGBUILDs up to date
fetching devel info...
==> Making package: rstudio-desktop 2023.03.2.454-1 (Wed 07 Jun 2023 20:00:50)
==> Retrieving sources...
-> Found rstudio-2023.03.2.454.tar.gz
-> Found rstudio-cherry-blossom.zip
-> Found node-v16.14.0-linux-x64.tar.gz
-> Found qt.conf
-> Found pandoc_version.patch
==> Validating source files with sha256sums...
rstudio-2023.03.2.454.tar.gz ... Passed
rstudio-cherry-blossom.zip ... FAILED
node-v16.14.0-linux-x64.tar.gz ... Passed
qt.conf ... Passed
pandoc_version.patch ... Passed
==> ERROR: One or more files did not pass the validity check!
error: failed to download sources for 'rstudio-desktop-2023.03.2.454-1':
error: packages failed to build: rstudio-desktop-2023.03.2.454-1

It seems that rstudio-cherry-blossom.zip is failing to validate. How can we solve this?

Thanks for the quick response @trap000d

First thing I tried was reinstalling R and the problem persisted.

As user (account when installing)...

❱ ldconfig -p | grep libR.so
    libR.so (libc6,x86-64) => /usr/lib/R/lib/libR.so
❱ ldd /usr/lib/R/lib/libR.so
    linux-vdso.so.1 (0x00007ffd481e4000)
    libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fdcd71aa000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007fdcd70c2000)
    libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007fdcd706b000)
    libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007fdcd6fd0000)
    liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fdcd6f9d000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fdcd76eb000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007fdcd6f83000)
    libtirpc.so.3 => /usr/lib/libtirpc.so.3 (0x00007fdcd6f56000)
    libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007fdcd6c00000)
    libicui18n.so.72 => /usr/lib/libicui18n.so.72 (0x00007fdcd6800000)
    libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007fdcd6f0d000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fdcd6eed000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fdcd6619000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x00007fdcd7721000)
    libgfortran.so.5 => /usr/lib/libgfortran.so.5 (0x00007fdcd6200000)
    libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007fdcd6e79000)
    libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007fdcd6e25000)
    libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007fdcd4400000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fdcd4000000)
    libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x00007fdcd6bb7000)
    libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007fdcd6541000)
    libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007fdcd6b89000)
    libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007fdcd76df000)
    libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007fdcd6e17000)
    libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007fdcd76d6000)
    libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007fdcd6e05000)

And these are identical as root so it doesn't look like anything is broken in the dynamically linked libraries.

$R_HOME isn't defined though either as user or root, I tried setting this to export R_HOME="/usr/bin/R" in both the user and root account (by adding to ~/.bashrc so its defined if a new shell is started as either user during install) no joy. Fired up R and checked the value returned by R.home()...

> R.home()
[1] "/usr/lib64/R"

...so I tried setting export R_HOME="/usr/lib64/R" under both user and root account (again by adding to ~/.bashrc so that it is sourced if a new shell is started as either user during install), still no joy and errors out with -- Could not find libR shared library.

To get yarn berry under arch I configured the npm prefix for global packages. After that install corepack globally.

$ export PATH="$HOME/.local/bin:$PATH"
$ export npm_config_prefix="$HOME/.local"
$ npm i -g corepack

Then set up yarn berry

$ corepack enable
$ corepack prepare yarn@stable --activate
$ yarn -v
3.3.1

Another option would be to use /usr/bin/yarn instead of just yarn, to ensure everyone is using the same version.