Hi Bastian, On Wed, Feb 10, 2021 at 06:55:57PM +0100, Bastian Blank wrote: > Control: retitle -2 r-cran-rcppparallel: generates broken load path for > libtbb and fails on several architectures
Thanks a lot for the bug report including explanation and patch. > - r-cran-rcppparallel trying to workaround the bug in dyn.load by > deducting the full path of libtbb from the architecture instead of the > correct multiarch setting and failing. I admit I was not really happy about my patch and I see now the issue more clearly. > This has nothing to do with r-cran-rstan or r-cran-rstanarm, but it > seems to be the first one to find out. I've attached patches to fix > both problems, properly re-assigned and adjusted the bugs. > > This behaviour of R dyn.load might even be considered a security > vulnerability, because loading libraries from the working directory is a > problem. > diff -Nru r-cran-rcppparallel-5.0.2+dfsg/debian/control > r-cran-rcppparallel-5.0.2+dfsg/debian/control > --- r-cran-rcppparallel-5.0.2+dfsg/debian/control 2020-09-30 > 13:39:50.000000000 +0000 > +++ r-cran-rcppparallel-5.0.2+dfsg/debian/control 2021-02-10 > 17:43:22.000000000 +0000 > @@ -7,7 +7,7 @@ > Priority: optional > Build-Depends: debhelper-compat (= 13), > dh-r, > - r-base-dev, > + r-base-dev (>= 4.0.3-1.1~), Seems I should set a block -1 by 982465 since your patch works only with a fixed r-base-dev and the r-base-dev maintainer seems to be not happy about your solution. Kind regards and thanks again Andreas. -- http://fam-tille.de