Re: Debian R 4.2.2 packages
On 7 November 2022 at 18:43, Kurt Hornik wrote:
| >>>>> 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.
Yes. CRAN has a better / more current test setup as you have _all_ packages
current by construction. Here we do not -- and while we generally do not
trail that has often been the case and cause of issues (e.g. recent-ish with
the arguably not so well executed transition in recommended package Matrix
aka r-cran-matrix aka Debian source package rmatrix).
| 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)))
(To those less familiar with R internals and tricks. Kurt retrieves what
Debian knows via apt-cache and tranforms into a vector 'p'; 'z' retrieves similar
information from CRAN (via an extra-useful function I use all the time), then
constructs a 'Debian-named' packages vector and finds the difference:
packages we have but should not consider 'alive' as they are no longer on
CRAN and hence not in what CRAN_package_db() returns).
| 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.
Yes. We should be able to cache current packages (and maybe their upstream
versions) and them moderate test failures for packages that are no longer on
CRAN, or more current at CRAN.
Thanks for the follow-up, and for having raised this in the first place.
Dirk
| 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
--
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: