Bug#1039721: r-base: 4.3 causes many autopkgtests to fail

[Jeremy Bícha]

Source: r-base
Version: 4.3.1-1
Severity: serious

I'm copying this from https://launchpad.net/bugs/2020799

==========
A bunch of R packages fail autopkgtests with 4.3.0-1, with errors
looking like this:

Error in `vectbl_assign(x[[j]], i, recycled_value[[j]])`: DLL requires
the use of native symbols

Looking into the upstream code and changelog, this appears to be
related to this change:

Attempting to use a character string naming a foreign function entry
point in a foreign function call in a package will now signal an error
if the packages has called R_forceSymbols to specify that symbols must
be used.
==========

Thank you,
Jeremy Bícha

[Jeremy Bícha]

On Wed, Jun 28, 2023 at 12:56 PM Dirk Eddelbuettel <e...@debian.org> wrote:
> This shoots the messenger. That is a bug in the vectors package, not in R
> 4.3.0 (or now R 4.3.1).

I encourage you to change the severity of this bug back to Serious.

r-base will not migrate from Unstable to Testing until the triggered
autopkgtests are all passing. That makes this de facto a Release
Critical issue regardless of whether a Serious bug is filed or not.

However, a Serious bug will show up at both
https://tracker.debian.org/pkg/r-base and
https://release.debian.org/britney/update_excuses.html#r-base which
allows others to easily see an explanation of the issue and the status
of fixing it.

The autopkgtest failures do indicate that there is a dependency issue
that could be resolved through either stricter dependency
relationships in the packages or by implementing the virtual API
package you mentioned on the mailing list and rebuilding affected
packages when the API changes.

I understand that you don't consider this temporary incompatibility to
be a high priority issue but the autopkgtest system allows for this to
be detected so that things run smoothly for those people who choose to
use these packages on Debian Testing.

Thank you,
Jeremy Bícha

[Dirk Eddelbuettel]

Feel free to change the severity back if you truly think it is that serious.

Some of the autopkgtests may be stumbling about the graphics API change and
may need a rebuild of packages interfacing it: svglite, ggplot2, ragg,
tikzdevice. As some of these are widely used the rest may be repercussions.
There is also the usual mess with the (bulk ?) update of BioConductor which
generally releases a few weeks after R and did so again.

I maintain that r-base is fine. I have no control over how other people use
my package, and if all other maintainers put breaking autopkgtests in well
yes then they do hold r-base hostage and it will take "forever" to migrate to
testing. We have been there before.

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

[Jeremy Bícha]

Control: severity -1 serious

On Wed, Jun 28, 2023 at 5:29 PM Dirk Eddelbuettel <e...@debian.org> wrote:
> Feel free to change the severity back if you truly think it is that serious.

Done.

Feel free to close the bug once r-base is ready to migrate to Testing.
This is mostly just a tracking bug that people may find easier than
browsing the mailing list.

> I maintain that r-base is fine. I have no control over how other people use
> my package, and if all other maintainers put breaking autopkgtests in well
> yes then they do hold r-base hostage and it will take "forever" to migrate to
> testing. We have been there before.

Some just set this field in debian/control:
Testsuite: autopkgtest-pkg-r

Thank you,
Jeremy Bícha

[Dirk Eddelbuettel]

Control: severity -1 normal

I am changing this back because

a) there is no general bug in R 4.3.1, and there newer was

there were a few packages requiring an update to the new graphics engine
version (as the packages choose to call R_GE_checkVersionOrDie, it is
coming from their side, not the R package imposing/causing a break)

filing bug reports against the affected package resolved the issue as
expected, if you look at
https://qa.debian.org/excuses.php?package=r-base
there is not a single graphics related issue

but I can argue this issue til I am blue in the face and not get
anywhere so the R package now provides r-graphics-engine-*

b) note that the remaining autopkgtest breaks have nothing to do with the
graphics engine version, and the change I was asked to make (and which I
accomodated) will not help

however, the error is not with R just like the one you posted in your
bug report was not:

Error in `vectbl_assign(x[[j]], i, recycled_value[[j]])`: DLL requires
the use of native symbols

this is almost surely intra-package and needs to be resolved by those
package

For both reasons the bug report should be closed but I am now only dialing it
down to 'normal'. r-base is a bystander here, and the messenger that is
being shot at.

We of course do use R 4.3.* just fine with 21,000 r-cran-* binary packages in
r2u. If one keeps the package current with CRAN all is well. It is not my
fault if some other maintainers claim they (and I paraphrase, but it is all
in the BTS) "have too many packages to keep them current". That is an issue
for which filing bugs again r-base does not, and cannot, help.

[Dirk Eddelbuettel]

Thanks for closing it.

I think in due course as you will see there

a) new tag does not help today (we already took care of the six packages needing a
rebuild because of the graphics engine constant changing) and

b) what is likely being the exact same sets of packages having issue with
each other as week ago, and the r-base 4.3.1-2 change does not affect
them as these are internal issue to the respective packages

c) hence there never a mass bug cause to be had.

So it was always a nothingburger, and I suspect the ongoing round two of the
transition will boil down to what I said at the outset: the packages with
woes (beside what the graphics engine change that we covered the standard
way) will be dealt with by their maintainer. We'll see how it goes.