Hi,

it feels like r-cran-bh on Debian/bookworm seems to be broken hard?
At least it's always failing hard for me, with:

| Error in stan_model(model_code = stancode, verbose = TRUE) :
|   Boost not found; call install.packages('BH')

Minimal steps to reproduce:

% cat > demo.r << EOF
example(stan_model, package = "rstan", run.dontrun = TRUE, verbose = TRUE)
EOF
% podman run --pull=always --rm -i -t -v $(pwd)/:/code:rw debian:bookworm bash

Inside the podman container (or on any Debian/bookworm system of course):

  apt update
  apt install -y dpkg-dev  # dpkg-architecture is needed
  apt install -y r-cran-rstan --no-install-recommends

Executing `r /code/demo.r` then triggers the failure mentioned above.

FTR: There's no change, if one drops the `--no-install-recommends`
from the package installation of `r-cran-rstan` above, but disabling
recommends reduces the package installation from ~2GB to ~450MB.

FYI: r-cran-rstan v2.32.7-1 with r-cran-bh v1.84.0-1 on current
Debian/testing AKA trixie seems to work fine and doesn't behave like
that.

Thanks for maintaining r-cran in Debian!

regards
-mika-

reassign -1 r-cran-rstan
thanks

On 20 June 2025 at 10:00, Michael Prokop wrote:
| Package: r-cran-bh
| Version: 1.74.0-2
| Severity: important
|
| Hi,
|
| it feels like r-cran-bh on Debian/bookworm seems to be broken hard?
| At least it's always failing hard for me, with:
|
| | Error in stan_model(model_code = stancode, verbose = TRUE) :
| |   Boost not found; call install.packages('BH')
|
| Minimal steps to reproduce:
|
| % cat > demo.r << EOF
| example(stan_model, package = "rstan", run.dontrun = TRUE, verbose = TRUE)
| EOF
| % podman run --pull=always --rm -i -t -v $(pwd)/:/code:rw debian:bookworm bash
|
| Inside the podman container (or on any Debian/bookworm system of course):
|
|   apt update
|   apt install -y dpkg-dev  # dpkg-architecture is needed
|   apt install -y r-cran-rstan --no-install-recommends
|
| Executing `r /code/demo.r` then triggers the failure mentioned above.
|
| FTR: There's no change, if one drops the `--no-install-recommends`
| from the package installation of `r-cran-rstan` above, but disabling
| recommends reduces the package installation from ~2GB to ~450MB.
|
| FYI: r-cran-rstan v2.32.7-1 with r-cran-bh v1.84.0-1 on current
| Debian/testing AKA trixie seems to work fine and doesn't behave like
| that.
|
| Thanks for maintaining r-cran in Debian!

You may be aware that the CRAN package BH, for which I am also the upstream
author / maintainer, is 'tricky' in the sense that it is rather large.

On the system on which I writing this

   edd@rob:~$ du -csh /usr/local/lib/R/site-library/BH/
   155M    /usr/local/lib/R/site-library/BH/
   155M    tota
   edd@rob:~$

As you also know, Debian has a (strong) preference to not 'doubly use'
included libraries so the package r-cran-bh, on Debian only, 'cheats' by
farming out to the _distribution packages_ liboost* to keep this package
small. (This can create issues for the CRAN packages, so as Debian maintainer
I have refused to do the same for RcppArmadillo, RcppEigen, ... to ensure
they behave as they do at CRAN.  But with BH so large I accommodated.)

On a Debian testing system (in a container, using the r-base container I
maintain as well)

   root@9102734208c4:/# apt-cache show r-cran-bh | grep Installed-Size
   Installed-Size: 29
   root@9102734208c4:/# apt-cache show r-cran-bh | grep Depends
   Depends: r-api-4.0, libboost-dev (>= 1.83.0)
   root@9102734208c4:/#

Now, for bookworm:

   root@fdb0d987d5e7:/# apt-cache show r-cran-bh | grep Installed-Size
   Installed-Size: 30
   root@fdb0d987d5e7:/# apt-cache show r-cran-bh | grep Depends
   Depends: libboost-dev (>= 1.74.0)
   root@fdb0d987d5e7:/#

As Boost 1.74 _does_ get installed, the error is possibly with rstan.

A quick reconstruction confirms that. I would therefore recommend to get a
newer rstan. If I run

   root@fdb0d987d5e7:/# Rscript -e 'install.packages("rstan")

(which is 'expensive' in brining RcppEigen, BH, and more in) ... it fails
over TBB in StanHeaders. [ The demo.R script now runs though ... ]

So maybe your solution is to pick a different rstan: between the version in
bookworm (2.21.7-1, ie upstream 2.21.7) and the current upstream 2.32.7.
There seem to be quite a few looking at archive/:

	rstan_2.21.7.tar.gz	2022-09-08 13:00	1.1M
	rstan_2.21.8.tar.gz	2023-01-17 13:40	1.1M
	rstan_2.26.23.tar.gz	2023-09-08 12:30	1.3M
	rstan_2.32.3.tar.gz	2023-10-15 07:00	1.5M
	rstan_2.32.5.tar.gz	2024-01-10 21:20	1.1M
	rstan_2.32.6.tar.gz	2024-03-05 18:00	1.5M

I know this is frustrating but you and I both know that CRAN is moving object
where 'everything current' works yet Debian stable wants to preserve a point
in time from when the release was cut / packages made.

The issue here is clearly one with rstan. It checks for an actual package BH.

If I put my 'root' hat on in the container and remove the installed packages
QuickJSR, RcppEigen, StanHeaders the demo again works:

    root@fdb0d987d5e7:/usr/local/lib/R/site-library# Rscript /tmp/demo.r 2>&1 | head -10
    Found file = '/usr/lib/R/site-library/rstan/help/stan_model'
    Loading required package: ggplot2
    code for methods in class "Rcpp_model_base" was not checked for suspicious field assignments (recommended package 'codetools' not available?)
    code for methods in class "Rcpp_model_base" was not checked for suspicious field assignments (recommended package 'codetools' not available?)
    code for methods in class "Rcpp_stan_fit" was not checked for suspicious field assignments (recommended package 'codetools' not available?)
    code for methods in class "Rcpp_stan_fit" was not checked for suspicious field assignments (recommended package 'codetools' not available?)
    rstan (Version 2.21.7, GitRev: 2e1f913d3ca3)
    For execution on a local, multicore CPU with excess RAM we recommend calling
    options(mc.cores = parallel::detectCores()).
    To avoid recompilation of unchanged Stan programs, we recommend calling
    root@fdb0d987d5e7:/usr/local/lib/R/site-library#

so this really is an rstan issue: the package in stable needs to change its
test for BH to a test for 'CRAN package BH, or if on Debian, Boost headers'.

So I am reassigning the bug to Debian package r-cran-rstan.  But overall it
is a tricky issue. We try to accommodate, you ran into a corner, easiest fix
may be for you to accommodate the corner situation.

Dirk

| regards
| -mika-

reassign 1108078 r-cran-rstan
thanks

Previous attempt using -1 failed, resending.

Dirk

Hi,

* Michael Prokop [Fri Jun 20, 2025 at 10:00:37AM +0200]:
again!), we managed to find a workaround for this issue, see
attached patch file.

Note: this fix is relevant for stable/bookworm only (not relevant
nor necessary for Debian/testing AKA trixie!). There might be even
better ways to fix this, but a) it's working, b) minimal change and
c) still follows the initial idea, that we already have libboost-dev
available and want to have rstan cooperate with an "empty" BH
package.

Given that r-cran-bh doesn't seem to be working in Debian/bookworm
at all, this might possibly even warrant a fix via proposed-updates
to reach the next bookworm Debian point release?

regards
-mika-

Thanks Michael and Dirk for the fix,

Just a quick comment for users who might be impacted before the stable
update:

Le Fri, Jun 20, 2025 at 07:51:17PM +0200, Michael Prokop a écrit :

So setting `boost_lib` at runtime to an arbitrary existing file or path
also prevents rstan from stopping, like with:

     rstan_options("boost_lib" = '.')

It is surprising that rstan never worked and we never noticed until this
week.  It is possible that we ship it merly because it is listed in the
Suggest field of the DESCRIPTION file of other R packages.  Often this
is because it is needed in the other package's unit tests, which makes
it strictly required for us, but sometimes it is only because some
optional support for it is provided by the other package, leading to
cases like this one.

Have a nice day,

Charles

On 21 June 2025 at 07:26, Charles Plessy wrote:
| Control: retitle -1  r-cran-rstan: fails hard with 'Boost not found'
| Control: tag -1 + patch
|
| Thanks Michael and Dirk for the fix,
|
| Just a quick comment for users who might be impacted before the stable
| update:
|
| Le Fri, Jun 20, 2025 at 07:51:17PM +0200, Michael Prokop a écrit :
| >+-  if (!file.exists(rstan_options("boost_lib")))
| >+-    stop("Boost not found; call install.packages('BH')")
| >++# if (!file.exists(rstan_options("boost_lib")))
| >++#   stop("Boost not found; call install.packages('BH')")
|
| So setting `boost_lib` at runtime to an arbitrary existing file or path
| also prevents rstan from stopping, like with:
|
|      rstan_options("boost_lib" = '.')
|
| It is surprising that rstan never worked and we never noticed until this
| week.  It is possible that we ship it merly because it is listed in the
| Suggest field of the DESCRIPTION file of other R packages.  Often this
| is because it is needed in the other package's unit tests, which makes
| it strictly required for us, but sometimes it is only because some
| optional support for it is provided by the other package, leading to
| cases like this one.

The key issue here, I suspect, is a really a mismatch between 'Build-Depends'
and 'Depends' (which we have, but CRAN doesn't) and actual run-time
dependencies.

rstan builds compiled programs for its MCMC etc use, that is different from
eg my package anytime needing Boost headers only at _build-time_ and not
thereafter.

What Mika found here (in the original bug report) is that only Debian stable
has a failing rstan. The newer ones work. We (ie Debian) "trick" rstan via
our r-cran-bh, it thinks it has a full BH (120+ mb on disk...) and constructs
and _explicit_ include path via system.file(). I think I could soften the
blow by adding an (empty) includes/ dir in the (virtual) package r-cran-bh.
In any event, the little patch avoids the failure seen on Debian stable where

   system.file("include", package="BH")

otherwise fails due our r-cran-bh actually relying on our libboost-dev.

Makes sense?

Dirk

Hi Everyone

I would have hoped that r-cran-rstan's autopkgtests would have caught
this, but looking at the output of a recent test in trixie [1] below,
it seems the autopkgtest is missing a dependency on at least gcc, and
despite the large WARNING, the test is not considered a FAIL.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-rstan/testing/amd64/


64s rstan version 2.32.7 (Stan version 2.32.2)
64s
64s For execution on a local, multicore CPU with excess RAM we recommend calling
64s options(mc.cores = parallel::detectCores()).
64s To avoid recompilation of unchanged Stan programs, we recommend calling
64s rstan_options(auto_write = TRUE)
64s For within-chain threading using `reduce_sum()` or `map_rect()`
Stan functions,
64s change `threads_per_chain` option:
64s rstan_options(threads_per_chain = 1)
64s
64s >
64s > test_check("rstan")
64s Read 34 items
64s Read 34 items
65s Trying to compile a simple C file
65s Running /usr/lib/R/bin/R CMD SHLIB foo.c
65s sh: 1: gcc: not found
65s gcc -std=gnu23 -I"/usr/share/R/include" -DNDEBUG -fpic -g -O2
-ffile-prefix-map=/build/reproducible-path/r-base-4.5.0=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -c foo.c -o foo.o
65s /bin/bash: line 1: gcc: command not found
65s make: *** [/usr/lib/R/etc/Makeconf:202: foo.o] Error 127
66s
66s WARNING: The tools required to build C++ code for R were not found.
66s
66s Please install GNU development tools including a C++ compiler.
66s
66s Loading required namespace: Matrix
68s [ FAIL 0 | WARN 0 | SKIP 25 | PASS 149 ]