Paul,
On 9 July 2023 at 17:40, Paul Gevers wrote: | Did we already discuss that r-cran-ps also seems to be impacted by the | r-base change of the symbols thingy, as can be seen in r-cran-xopen [1]. Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.* to R 4.3.*. It was a change by some packages opting into different behavior. | In unstable r-cran-xopen works. If I take r-cran-ps, r-cran-xopen and | r-base from unstable and test in testing, r-cran-xopen works. If I only | take r-base and r-cran-ps from unstable and test in testing, | r-cran-xopen works. Can somebody with R understanding confirm? | | 33s Error in `not_null(.Call("psll_connections", p))`: DLL requires | the use of native symbols | 33s Backtrace: | 33s 1. testthat::test_that(...) | 33s at test.R:4:0 | 33s 2. testthat:::test_code(desc, code, env = parent.frame(), | reporter = reporter) | 33s 3. reporter$start_test(context = reporter$.context, test = test) | 33s 4. testthat:::o_apply(self$reporters, "start_test", context, test) | 33s 5. base::lapply(objects, f) | 33s 6. testthat (local) FUN(X[[i]], ...) | 33s 7. x$start_test(...) | 33s 8. ps::ps_connections(ps_handle()) | 33s 9. ps:::psl_connections(p) | 33s 10. ps:::not_null(.Call("psll_connections", p)) Tis would be a bug in r-cran-ps and I think a Breaks may be warranted. We are apparently between version 1.7.2 and 1.7.5 of package (r-cran-)ps but I see no smoking gun in https://github.com/r-lib/ps/blob/main/NEWS.md that would have caused this. Looking further, `git blame` indicates that the package had `registation=TRUE` for five years / all its existence, see line 2 here https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/R/ps.R It also used 'forceSymbols' for the same five years (lines 99 to 101 here https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/src/init.c So I think the issue here may not be coming from ps. I has not changed how it refers to its symbols. Same R API, same usage. As the last entry here is into the (unexported) ps:::not_null we can look into it. It just indexes with map_lgl which is a local function (from R/utils) and calls psll_connection, a local compiled function in the package. Given that ps always had 'native symbols', maybe testthat changed? However, it does not force symbols :-/ Lines 20 and 21 use the two required initialization but not the optional symbol forcing that eg ps has. https://github.com/r-lib/testthat/blob/main/src/init.c So I got nothing here. Cause is unclear to me. | Same for r-cran-fnn, which impacts r-cran-uwof [2]. | | I think what we should do is add a versioned Breaks in r-base on | <packages-involved-in:r-graphics-engine>, r-cran-ps, r-cran-tibble, | r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for I think it would be best to work out to corresponding package pairings and apply the Breaks to them. If we can. | bookworm to trixie upgrades (and current trixie to trixie with the new | r-base). Has anyone see other packages throwing that "DLL requires the | use of native symbols" error? I spotted the ones below [3, 4, 5, 6], but | I haven't identified which package brings in the issue. I first thought | it would be from the package itself, but for some (r-cran-spacetime and | r-cran-stars) their versions in unstable fail their own testsuite in For spacetime and stars I suspect (based on past experience) possible interaction from the underlying graphics libraries. | testing. Would it hint at the same problem for the packages, or just for | their tests? I suspect the former, then they should also need to be | added to the Breaks list. | | Paul | | [1] | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-xopen/35575366/log.gz | [2] | https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-uwot/35590669/log.gz | [3] | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-intervals/35575046/log.gz | [4] | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-maldiquant/35575320/log.gz | [5] | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-spacetime/35575371/log.gz | [6] | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-stars/35583884/log.gz If I am not mistaken all of these were already in the Excuses list before we made addition of the r-graphics-engine-* tag (which was taken care of for R 4.3.* already, having it may help if another change happens like that). So it short, the vast majority of R packages is now fine. A persistent subset is not under the testing regime of autopkgtest. Unfortunately I find the reports a little hard to read and am hence not very efficient at pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see no error in there :-/ Obviously, I too want my package r-base in testing and I will help. But I feel that pinning a large Breaks list on it seems a little inefficient / unfair if the package was not causing the change. We can do if there is (as we r-graphics-engine-*) an overwhelming feel "that we must". I hope some of this helped. I am sorry I cannot help much further, and I am equally sorry my package is held up in the middle of this -- a "cost" of having a mildly popular package I suppose. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org