On 16 May 2023 at 15:01, Andreas Tille wrote: | Hi, | | when fixing bug #1035428 I realised test suite issues with | | r-cran-thematic [1] | -> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | always_valid)`: Graphics API version mismatch | | r-cran-treescape [2] | r-cran-treespace [3] | -> error is given if lambda is outside of [0,1] --- | `medTree(trees, -1)` did not throw an error. | | As far as I can guess at least the first type of error (Graphics API | version mismatch) is caused by the fact that a new upstream version of | r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | experimental so it seems by accident).
Yes. It was very much by accident, and my bad. When the freeze hardened and I switched uploading from unstable to experimental (on March 15 per my mail folder of installer replies, and coincidentally with the R 4.2.3-1 upload), I managed to update the distribution field (often using 'C-x d' in the handy Emacs mode) in the debian/changelog file each and every time --- with the one exception of the next update of r-base to the 4.3.0 release :-/ | I wonder what might be the most sensible strategy to fix this. Since | an epoch is considered ugly I've seen some kind of | 4.3.0+really+4.2.2.20221110 | version number. However, in case of R it might not be the best idea | to use this kind of fake version in a stable release. I think we shouldn't. Apart from this test issue, the binary sits in unstable and will remain in unstable. The change is graphics format is a repeat of previous micro-API changes from upstream where Paul Murrell (who is the one taking care of the graphics device) enhances its capabilities (often in quite meaningful ways). The R Core team does not consider this a breaking change, and does recommend or mandate rebuilds of the nearly 20k CRAN packages. I happen to concur. However, when a package built with such a graphics api version 'A' is loaded by R of version 'B' (and it usually happens to us the other way) the package load simply errors out with a message. This is not fatal -- it is just a hint to rebuild the package under the R version used. I have always been of the pragmatic view that is indeed good enough. (Johannes of the back-porters team disagrees, he reminded me of a simple search for the one code line doing the check. Running that at the GitHub mirror of CRAN (which is a superset as it includes packages that once were on CRAN but are no longer) I identified ten packages of which about half or more are no longer on CRAN. For us it is likely `ragg` and `svglite`. I can dig out the details from my reply to Johannes.) Note that none of this affects the release. My recommendation is temporarily suspend the autopkgtest in those affected packages. They did their job and found the mismatch with the R 4.3.0 in unstable that shouldn't have been uploaded there. Out the about fifty package uploads I made since I switched to experimental, one went to wrong repo. That was not intentional but I think we can manage. Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
