Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

2023-06-12 Thread Dirk Eddelbuettel 


On 12 June 2023 at 16:08, Steve Langasek wrote:
| On Mon, Jun 12, 2023 at 05:22:39PM -0500, Dirk Eddelbuettel wrote:
| >   edd@rob:~$ cat deb/bh/debian/control 
| >   Source: r-cran-bh
| >   Section: gnu-r
| >   Priority: optional
| >   Maintainer: Dirk Eddelbuettel 
| >   Build-Depends: debhelper-compat (= 11), r-base-dev (>= 4.1.1), dh-r
| >   Standards-Version: 4.6.0
| >   Vcs-Browser: https://salsa.debian.org/edd/r-cran-bh
| >   Vcs-Git: https://salsa.debian.org/edd/r-cran-bh.git
| >   Homepage: https://cran.r-project.org/package=BH
| 
| >   Package: r-cran-bh
| >   Architecture: all
| >   Multi-Arch: foreign
| >   Depends: ${misc:Depends}, libboost-dev (>= 1.74.0)
| >   Description: (Virtual) GNU R package to provide BH
| >The CRAN package BH provides a (large) subset of Boost.  This package 
tricks
| >R into believing BH is installed when we just depend on the 
distribution's
| >Boost packages.  The actual set of Boost libraries could get fine-tuned. 
In
| >short, we avoid doubling up the 140+ mb of the 'BH' package which are 
alredy
| >in libboost-dev.
| >   edd@rob:~$ 
| 
| > So it isn't "really" 1.74, that is simply the last time we edited the shell
| > that this provides.  Hence "no bumping".  We have to wait for 1.81.
| 
| boost1.81 is already available in Debian but is not yet the version pointed
| to by boost-defaults; this is what I meant by depending on libboost1.81-dev
| instead of libboost-dev - no need to duplicate the boost contents, just
| change the dependency.

I missed that. So I could just roll the virtual one. I like that.
 
| You would eventually want to change it back, of course, so that you aren't
| stuck on boost1.81 when something *newer* becomes the default in Debian.
| 
| And the boost1.81 transition already has a bug open for it:
| 
|   https://bugs.debian.org/1028489
| 
| For my part, I don't mind if fixing this waits until boost1.81 becomes the
| default.  I only wanted to point out the options.

No, that is slick. Thanks for pointing it out.

When do we re-open testing?  I have a few dozen uploads in experimental I
need to move too.

Dirk


-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

2023-06-12 Thread Steve Langasek 
On Mon, Jun 12, 2023 at 05:22:39PM -0500, Dirk Eddelbuettel wrote:
>   edd@rob:~$ cat deb/bh/debian/control 
>   Source: r-cran-bh
>   Section: gnu-r
>   Priority: optional
>   Maintainer: Dirk Eddelbuettel 
>   Build-Depends: debhelper-compat (= 11), r-base-dev (>= 4.1.1), dh-r
>   Standards-Version: 4.6.0
>   Vcs-Browser: https://salsa.debian.org/edd/r-cran-bh
>   Vcs-Git: https://salsa.debian.org/edd/r-cran-bh.git
>   Homepage: https://cran.r-project.org/package=BH

>   Package: r-cran-bh
>   Architecture: all
>   Multi-Arch: foreign
>   Depends: ${misc:Depends}, libboost-dev (>= 1.74.0)
>   Description: (Virtual) GNU R package to provide BH
>The CRAN package BH provides a (large) subset of Boost.  This package 
> tricks
>R into believing BH is installed when we just depend on the distribution's
>Boost packages.  The actual set of Boost libraries could get fine-tuned. In
>short, we avoid doubling up the 140+ mb of the 'BH' package which are 
> alredy
>in libboost-dev.
>   edd@rob:~$ 

> So it isn't "really" 1.74, that is simply the last time we edited the shell
> that this provides.  Hence "no bumping".  We have to wait for 1.81.

boost1.81 is already available in Debian but is not yet the version pointed
to by boost-defaults; this is what I meant by depending on libboost1.81-dev
instead of libboost-dev - no need to duplicate the boost contents, just
change the dependency.

You would eventually want to change it back, of course, so that you aren't
stuck on boost1.81 when something *newer* becomes the default in Debian.

And the boost1.81 transition already has a bug open for it:

  https://bugs.debian.org/1028489

For my part, I don't mind if fixing this waits until boost1.81 becomes the
default.  I only wanted to point out the options.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

2023-06-12 Thread Dirk Eddelbuettel 


Hi Steve,

On 12 June 2023 at 14:41, Steve Langasek wrote:
| Package: r-cran-bh
| Version: 1.74.0-2
| User: ubuntu-de...@lists.ubuntu.com
| Usertags: origin-ubuntu mantic
| Affects: r-cran-rstan/2.21.8-1
| 
| Hi Dirk,
| 
| r-cran-rstan 2.21.8-1 is failing to build from source in Debian and Ubuntu
| on 32-bit architectures because it exhausts the 32-bit virtual memory space.
| 
| The r-cran-rstan maintainer has reported this upstream at
| , where it's been noted that
| the module builds on 32-bit when using the upstream CRAN BH, which points to
| boost 1.81 headers whereas the r-cran-bh package in Debian is still at boost
| 1.74.
| 
| I've tested locally, and find that depending on libboost1.81-dev instead of
| libboost-dev (1.74) works.  The boost 1.74->1.81 transition will happen in
| the trixie cycle, but does it make sense to bump r-cran-bh ahead of time?

This is a hard problem.

For R, which is pretty good at 'abstracting the os layer' I maintain its
package BH (in the role of upstream author / "assembler") which expands to
about 156mb installed  as Boost is so big:

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

Way back when when I started with BH I used the sources of what what was in
Debian, that way they were in sync. And kept updating when Debian updated.
That drifted, and R users (via CRAN) wanted something newer.  Boost updates
three times a year (Apr + Aug + Dec) and for the last few years I updated
once in Dec.  So that is why CRAN is now ahead with 1.81 (upstream is at
1.82), and that is what (r)stan wants.

But we probably do not want BH in Debian because it is 'Yuge'. (We could
though, maybe worth discussing.)  So for the last few years _Debian's_
r-cran-bh was an empty virtual package dependending on what Debian has as
libboost* (particularly the headers only):

  edd@rob:~$ cat deb/bh/debian/control 
  Source: r-cran-bh
  Section: gnu-r
  Priority: optional
  Maintainer: Dirk Eddelbuettel 
  Build-Depends: debhelper-compat (= 11), r-base-dev (>= 4.1.1), dh-r
  Standards-Version: 4.6.0
  Vcs-Browser: https://salsa.debian.org/edd/r-cran-bh
  Vcs-Git: https://salsa.debian.org/edd/r-cran-bh.git
  Homepage: https://cran.r-project.org/package=BH
  
  Package: r-cran-bh
  Architecture: all
  Multi-Arch: foreign
  Depends: ${misc:Depends}, libboost-dev (>= 1.74.0)
  Description: (Virtual) GNU R package to provide BH
   The CRAN package BH provides a (large) subset of Boost.  This package tricks
   R into believing BH is installed when we just depend on the distribution's
   Boost packages.  The actual set of Boost libraries could get fine-tuned. In
   short, we avoid doubling up the 140+ mb of the 'BH' package which are alredy
   in libboost-dev.
  edd@rob:~$ 

So it isn't "really" 1.74, that is simply the last time we edited the shell
that this provides.  Hence "no bumping".  We have to wait for 1.81.

(Or we decide to pull the bandaid and inject 150mb of BH as r-cran-bh.  At
least it will be Architecture: all as a header-only package.)

Thoughts from your side? Is any of this making sense to you?  Happy to chat
more.

Thanks as always for looking after Debian and Ubuntu!

Best,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

2023-06-12 Thread Steve Langasek 
Package: r-cran-bh
Version: 1.74.0-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic
Affects: r-cran-rstan/2.21.8-1

Hi Dirk,

r-cran-rstan 2.21.8-1 is failing to build from source in Debian and Ubuntu
on 32-bit architectures because it exhausts the 32-bit virtual memory space.

The r-cran-rstan maintainer has reported this upstream at
, where it's been noted that
the module builds on 32-bit when using the upstream CRAN BH, which points to
boost 1.81 headers whereas the r-cran-bh package in Debian is still at boost
1.74.

I've tested locally, and find that depending on libboost1.81-dev instead of
libboost-dev (1.74) works.  The boost 1.74->1.81 transition will happen in
the trixie cycle, but does it make sense to bump r-cran-bh ahead of time?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature