R SIG Debian - Apr 2017 - R-3.4.0 and recommended packages

Am Dienstag, 25. April 2017, 11:21:31 schrieb Dirk
Eddelbuettel:
> On 25 April 2017 at 16:11, Johannes Ranke wrote:
> | This looks similar to what I got this morning when I tested my
> | (unreleased)
> | backport of R 3.4.0 to Debian jessie. My test was
> | 
> | library(MASS)
> | example(rlm)
> | 
> | and there was an object that was not found. I am on a train on the way to
> | a
> | meeting right now, so I can not look into it at the moment. Maybe a side
> | effect of the new registration requirements for compiled objects?
> 
> I doubt that as it works for me under R 3.4.0 on a current-ish Ubuntu 16.10
> box.
This is because the version of MASS in sid (r-cran-mass) was released on 21 
April

https://packages.qa.debian.org/r/r-cran-mass.html

which is the same day when r-base was released for R 3.4.0, so MASS was 
obviously built against the current version.

I just tried r-cran-spatial on a **fresh Debian sid chroot**, and get
> library(spatial)
> example(surf.gls)
srf.gl> library(MASS)  # for eqscplot

srf.gl> data(topo, package="MASS")

srf.gl> topo.kr <- surf.gls(2, expcov, topo, d=0.7)
Error in surf.gls(2, expcov, topo, d = 0.7) : object 'VR_frset' not
found

so it seems to me this must affect all packages in Debian sid that were built 
before the release of R 3.4.0!

And in fact, nlme, is affected as well:
> library(nlme)
> example(nlme)
nlme> fm1 <- nlme(height ~ SSasymp(age, Asym, R0, lrc),
nlme+             data = Loblolly,
nlme+             fixed = Asym + R0 + lrc ~ 1,
nlme+             random = Asym ~ 1,
nlme+             start = c(Asym = 103, R0 = -8.5, lrc = -3.3))
Error in pdFactor.pdLogChol(X[[i]], ...) : object 'logChol_pd' not found

So before I start spamming the Debian BTS, what would be the right way to deal 
with this? Do we need r-api-x here?

Cheers,

Johannes

P.S.: Sorry of the other post, I pressed send before typing and even before 
thinking ...

> so it seems to me this must affect all packages in Debian sid that were
> built before the release of R 3.4.0!
or rather before 14 April 2017, which is when R from revision r72510 was 
uploaded to sid as pre-release candidate.

Johannes

On 27 April 2017 at 12:01, Johannes Ranke wrote:
| 
| > so it seems to me this must affect all packages in Debian sid that were
| > built before the release of R 3.4.0!
| 
| or rather before 14 April 2017, which is when R from revision r72510 was 
| uploaded to sid as pre-release candidate.

Another example with KernSmooth:

   > library(KernSmooth)
   KernSmooth 2.23 loaded
   Copyright M. P. Wand 1997-2009
   >
   > example(bkde)
   
   bkde> data(geyser, package="MASS")
   
   bkde> x <- geyser$duration
   
   bkde> est <- bkde(x, bandwidth=0.25)
   Error in linbin(x, gpoints, truncate) : object 'F_linbin' not found
   > 

Maybe this part of NEWS is what matters:

    * Packages which register native routines for .C or .Fortran need
      to be re-installed for this version (unless installed with
      R-devel SVN revision r72375 or later).

KernSmooth surely has .Fortran. Your spatial example had VR_frset failing,
and that too is called by the old .C.

A counter-example is eg my RcppEigen package -- I can load it and run
example(fastLm) just fine as that uses .Call rather than .C or .Fortran.

I think you are

 -- correct in that we need rebuilds
 -- but only for packages using .C and .Fortran calls to compiled

This may be a use case for r-api-4. Or not as it doesn't break _all_
packages
so I am not sure we should force _all_ packages to be rebuilt.

Can we not find the ones that use .C and .Fortran ?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org