Re: Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 | edd@debian.org
Reply to: