Re: Debian R 4.2.2 packages
>>>>> Dirk Eddelbuettel writes:
> On 7 November 2022 at 18:15, Andreas Tille wrote:
> | Am Mon, Nov 07, 2022 at 04:02:13PM +0100 schrieb Kurt Hornik:
> | > > I admit if this issue is known upstream we can not really do much
> | > > from the Debian side, thought.
> | >
> | > Thanks. There is no way to manually override the non-regression to
> | > trigger the migration?
> There is, and you can find _numerous_ messages by Andreas in the archives of
> this mailing list doing just that because he had to to get things moving.
> I have been on record, without success, arguing that the autopkgtests for
> CRAN packages are (almost always) redundant and 'busy work'. However, in this
> case we can (as I usually suggest) go to the CRAN page
> https://cran.r-project.org/package=slider
> and then the status page and see
> https://cran.r-project.org/web/checks/check_results_slider.html
> that CRAN itself reports errors on three platforms! (And ignore the clang-15
> issues, that is just forward-looking to upcoming compilers; CRAN was on the
> gcc-10 changes before we were too.)
> | It would be possible to remove the two affected tests and I'm fine to do
> | so but I would love to hear the opinion of other, more knowledged team
> | members, than I am.
> My position is (generally) unchanged. I think we should remove or
> relax the autopkgtest requirement. But I do not expect to change any
> minds this time either.
Thanks.
I was about to raise this on behalf of the CRAN team: ideally, this
would be synced with the CRAN regular checks, and packages which
currently/already fail the Debian regular checks for r-release or
r-patched be excluded for possible regressions.
Btw, one more issue: it seems there is no active tracking of CRAN
archivals within the r-cran-* packages. Currently running
lines <- system("apt-cache search r-cran- | grep ^r-cran-",
intern = TRUE)
p <- sub(" .*", "", lines)
z <- tools::CRAN_package_db()
setdiff(p, paste0("r-cran-", tolower(z$Package)))
finds
[1] "r-cran-gregmisc" "r-cran-amore"
[3] "r-cran-cgdsr" "r-cran-conting"
[5] "r-cran-diagnosismed" "r-cran-discriminer"
[7] "r-cran-epicalc" "r-cran-ffield"
[9] "r-cran-fitcoach" "r-cran-freetypeharfbuzz"
[11] "r-cran-fts" "r-cran-genabel"
[13] "r-cran-genabel.data" "r-cran-gmaps"
[15] "r-cran-gwidgets" "r-cran-gwidgetstcltk"
[17] "r-cran-kedd" "r-cran-lasso2"
[19] "r-cran-manipulatewidgets" "r-cran-medadherence"
[21] "r-cran-parsetools" "r-cran-randomfields"
[23] "r-cran-rcppmlpack" "r-cran-rniftilib"
[25] "r-cran-rook-examples" "r-cran-sdmtools"
[27] "r-cran-seroincidence" "r-cran-sparql"
[29] "r-cran-tcr" "r-cran-testextra"
[31] "r-cran-treescape" "r-cran-unbalanced"
[33] "r-cran-zelig" "r-cran-zeligchoice"
[35] "r-cran-zeligei" "r-cran-zeligverse"
Clearly, these should also not be part of any regression testing.
Best
-k
> But in this case it may be time to talk to the actual package maintainer.
> Dirk
> --
> dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: