On 27 April 2017 at 13:58, Johannes Ranke wrote:
| Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel:
| > 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).
|
| Yes, that is what Martin M?chler referred to in the answer to Bj?ran's
call
| for help on r-help.
|
| > 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
|
| Yes.
Here is a quick script snippet. Looks like about 1/3 of my r-cran-* packages
use .C() or .Fortran() and need a rebuild for R 3.4.0 (which some may already
have gotten as some upstream packages got updates):
-----------------------------------------------------------------------------
#!/bin/bash
## source directories are all named foo-1.2.3
dirs=$(find . -maxdepth 1 -type d -name \*-\* | sort)
for d in ${dirs}; do
if test -d ${d}/src; then
if grep -q -r \\.Fortran\( ${d}/R; then
echo ".Fortran in ${d}"
fi
if grep -q -r \\.C\( ${d}/R; then
echo ".C in ${d}"
fi
fi
done
-----------------------------------------------------------------------------
|
| > 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 ?
|
| I do not understand how the use of r-api-x works, but my feeling is that it
| will not allow to differentiate between packages using .C and .Fortan and the
| rest.
Right. And therefore cast too wide a net.
| I am surprised that I did not see a related bug report in the Debian BTS yet,
| did I overlook something? I only looked for r-base.
They may not know yet. I should write to debian-devel.
Any debian-med or debian-science readers here?
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> | I am surprised that I did not see a related bug report in the Debian BTS > | yet, did I overlook something? I only looked for r-base. > > They may not know yet. I should write to debian-devel.I have just submitted a bug report so the further discussion gets archived in the right place: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
Le Thu, Apr 27, 2017 at 07:24:18AM -0500, Dirk Eddelbuettel a ?crit :> > On 27 April 2017 at 13:58, Johannes Ranke wrote: > | Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel: > | > On 27 April 2017 at 12:01, Johannes Ranke wrote: > | > | > 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 ? > | > | I do not understand how the use of r-api-x works, but my feeling is that it > | will not allow to differentiate between packages using .C and .Fortan and the > | rest. > > Right. And therefore cast too wide a net. > > | I am surprised that I did not see a related bug report in the Debian BTS yet, > | did I overlook something? I only looked for r-base. > > They may not know yet. I should write to debian-devel. > > Any debian-med or debian-science readers here?Yes I am here :) I spotted the breakage caused by R 3.4.0 when seeing regression tests failing on ci.debian.net. But I did not report them yet as I am still busy with the breakage caused by R 3.3.3 (mostly on Bioconductor packages). In the case of R 3.3.3 it was a bit tedious to identify which packages were to rebuild because some test failures were only indirect consequences, and a pacakge responsible for the failures had its own tests passing because their coverage was shallow... Hence for 3.4.0 I would say that in doubt, let's rebuild everything. If r-base starts to provide r-api-4 instead of r-api-3 then it will not be co-installable with the r-cran/bioc/other-* packages until they have been rebuilt. - The benefit is that it will prevent people doing partial upgrades from Stable, that would break their packages. - The drawback is the extra work of rebuilding the packages that do not use .C and .Fortran. Within the Debian infrastructure, the architecture-dependant packages can be easily rebuilt by binNMUs. The architecture-independant packages are easier to rebuild than before, because it is now possible to do source-only uploads. Also, it may be worth asking on debian-devel if binNMUs of arch-independant packages will become possible (since we now have autobuilders that can handle them). For the Debian packages provided on CRAN, I am not familiar on build is trigger, so I can not comment on the ease of rebuilding. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
On 27 April 2017 at 23:41, Charles Plessy wrote: | Le Thu, Apr 27, 2017 at 07:24:18AM -0500, Dirk Eddelbuettel a ?crit : | > | > On 27 April 2017 at 13:58, Johannes Ranke wrote: | > | Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel: | > | > On 27 April 2017 at 12:01, Johannes Ranke wrote: | > | | > | > 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 ? | > | | > | I do not understand how the use of r-api-x works, but my feeling is that it | > | will not allow to differentiate between packages using .C and .Fortan and the | > | rest. | > | > Right. And therefore cast too wide a net. | > | > | I am surprised that I did not see a related bug report in the Debian BTS yet, | > | did I overlook something? I only looked for r-base. | > | > They may not know yet. I should write to debian-devel. | > | > Any debian-med or debian-science readers here? | | Yes I am here :) :) | I spotted the breakage caused by R 3.4.0 when seeing regression tests | failing on ci.debian.net. But I did not report them yet as I am still | busy with the breakage caused by R 3.3.3 (mostly on Bioconductor packages). | In the case of R 3.3.3 it was a bit tedious to identify which packages were | to rebuild because some test failures were only indirect consequences, and | a pacakge responsible for the failures had its own tests passing because | their coverage was shallow... Hence for 3.4.0 I would say that in doubt, | let's rebuild everything. Could you fill me in about what broke with BioC and what caused it? I am not (yet?) on board with recommending a point-blank rebuild of all. | If r-base starts to provide r-api-4 instead of r-api-3 then it will not be | co-installable with the r-cran/bioc/other-* packages until they have been | rebuilt. | | - The benefit is that it will prevent people doing partial upgrades | from Stable, that would break their packages. I am not sure I understand why people would want to do partial upgrades. Debian stable is support. Debian testing is supported. Hybrid mixes of the two are risque. | - The drawback is the extra work of rebuilding the packages that do not | use .C and .Fortran. | | Within the Debian infrastructure, the architecture-dependant packages can be | easily rebuilt by binNMUs. The architecture-independant packages are easier to | rebuild than before, because it is now possible to do source-only uploads. | Also, it may be worth asking on debian-devel if binNMUs of arch-independant | packages will become possible (since we now have autobuilders that can handle | them). It sure would help. | For the Debian packages provided on CRAN, I am not familiar on build is | trigger, so I can not comment on the ease of rebuilding. I think that is a different topic for which we may want a different discussion. Dirk | Have a nice day, | | -- | Charles Plessy | Debian Med packaging team, | http://www.debian.org/devel/debian-med | Tsurumi, Kanagawa, Japan -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org