On 31 January 2021 at 09:20, Graham Inggs wrote: | Control: reopen -1 | | Hi Dirk | | Paul's test results showed that the run-unit-test autopkgtest still | fails with the same errors ( | Error: gradient function must return a numeric vector of length...) as | in my original report. | | | The "Package version inconsistency detected" warning is now gone (due | to #980902). | | You can now see the same result on ci.debian.net [1] in the test run | at 2021-01-31 02:58:21 UTC.
¯\_(ツ)_/¯ When I look at the log I only see as relevant this tail part at the end: autopkgtest [21:58:17]: test pkg-r-autopkgtest: -----------------------] pkg-r-autopkgtest PASS autopkgtest [21:58:17]: test pkg-r-autopkgtest: - - - - - - - - - - results - - - - - - - - - - autopkgtest [21:58:17]: @@@@@@@@@@@@@@@@@@@@ summary run-unit-test FAIL non-zero exit status 1 pkg-r-autopkgtest PASS which shows no influence of Matrix. Matrix is a core R package (part of the "recommended" set) and has been there since forever. This is a bug in glmmTMB. All the 'gradient function must ...' errors are from its tests and points to me to a recent change in R (where boolean comparisons can now check if the compared vector is corre. The Matrix change may simply be the trigger. In any event, all these errors also have backtrace: -- 1. Error (test-VarCorr.R:11:1): (code run outside of `test_that()`) --------- Error: gradient function must return a numeric vector of length 6 Backtrace: 1. glmmTMB::glmmTMB(distance ~ age + (age | Subject), data = Orthodont) test-VarCorr.R:11:0 2. glmmTMB::fitTMB(TMBStruc) 4. glmmTMB:::optfun() 6. base::with.default(...) 7. [ base::eval(...) ] with 1 more call No Matrix here. Can you please talk to glmmTMB? Their GH seems active (https://github.com/glmmTMB/glmmTMB/commits/master) Dirk | Regards | Graham | | | [1] https://ci.debian.net/packages/r/r-cran-glmmtmb/unstable/s390x/ -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
