Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
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. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
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 -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
On 28 June 2023 at 17:39, Jeremy Bícha wrote: | Control: severity -1 serious | | On Wed, Jun 28, 2023 at 5:29 PM Dirk Eddelbuettel 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 Of course. That is just the mechanical 'how does one'. The actual problem is combining this with letting the packages get out of sync, or in the case of the API change, not yet having rebuilt. I just filed bug reports against (somewhat popular) packages r-cran-ragg (a graphics device) and r-cran-svglite (ditto). Once those are remade this self-inflicted autopkgtest "issue" will improve. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
Control: severity -1 serious On Wed, Jun 28, 2023 at 5:29 PM Dirk Eddelbuettel 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
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
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
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
On Wed, Jun 28, 2023 at 12:56 PM Dirk Eddelbuettel 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
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
severity 1039721 normal thanks Hi Jeremy, That is a false positive (more below) and a duplicate of #1039510; the discussion of the latter now continues on the debian-r list. On 28 June 2023 at 12:31, Jeremy Bícha wrote: | 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. | == 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 would be happy to schedule a quick chat (I am on Central time) but I already wrote a number of email messages on this, now mostly under the above bug number or on the debian-r list (off the usual Debian mailing list server). FWIW I also look after https://eddelbuettel.github.io/r2u/ which *all* of CRAN (and a few hundred BioConductor packages) as complete .deb binaries with full dependencies for Ubuntu 20.04 (focal) and 22.04 (jammy). There are no bugs, and there is no API issue. r2u is mesmerizing; just play with the rocker/r2u:22.04 container. The combination of a number of maintainer a) adding autopkgtest and at the same time b) letting some packages go stale creates this. It happens at each release, and it manifestly unfair to package r-base which I have been maintaining for 20+ years. Cheers, Dirk (Debian dev since 1995 or so R maintainer since 1998-2002 dependeing on how you count R Foundation Board member for a decade+ Author of 60+ CRAN packages) | | Thank you, | Jeremy Bícha -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
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
