Arch Linux User Repository

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.

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.

@JstKddng,

could you remove this line from the PKGBUILD?
yarn config set ignore-engines true
as that line is not compatible with yarn berry (3.x)
this compiles correctly with that line

Hmm... I couldn't find [yet?] yarn berry neither in standard Arch repos nor in AUR. Have you installed it manually (custom repository, source)? Effectively, I'm not sure how to run test build for checking if there are no any other issues with it.

Anyway, mentioned line is still appeared in upstream build script so I would rather keep it for compatibility with current yarn version (I guess most of users have it installed now).

pacman -Qi yarn
Name            : yarn
Version         : 1.22.19-1
..........

@slackline, I've just tested build on two different machines - all runs OK. Please check if you have not accidentally broken r package.

What ldconfig says about your libR?

ldconfig -p | grep libR.so
libR.so (libc6,x86-64) => /usr/lib/R/lib/libR.so

Are there any broken dependencies?

ldd /usr/lib/R/lib/libR.so 
linux-vdso.so.1 (0x00007ffea3f7f000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f57a2300000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f57a1d18000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007f57a1cc1000)
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f57a1c26000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f57a1bf3000)
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f57a22ed000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f57a1bd9000)
libtirpc.so.3 => /usr/lib/libtirpc.so.3 (0x00007f57a1bac000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007f57a1800000)
libicui18n.so.72 => /usr/lib/libicui18n.so.72 (0x00007f57a1400000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f57a1b63000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57a1b43000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f57a1219000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f57a23a5000)
libgfortran.so.5 => /usr/lib/libgfortran.so.5 (0x00007f57a0e00000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f57a1acf000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f57a1a7b000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007f579f000000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f579ec00000)
libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x00007f57a1a32000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f57a1141000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f57a1a04000)
libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007f57a22e1000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f57a17f2000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f57a22d8000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f57a17e0000)

Might you have $R_HOME variable defined somewhere?