Re: R 4.4.0 coming April 24
On 21/04/2024 15:32, Dirk Eddelbuettel wrote: On 21 April 2024 at 15:25, Sebastiaan Couwenberg wrote: | On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: | > R upstream no longer releases or tests for 32 bits (and has not since the R | > 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the | > release team may need to override this to unblock. | | Wouldn't it be better then to add architecture-is-64-bit to the r-base | build dependencies to prevent it from building on 32bit architectures | and then file partial RM bugreports for r-base and its rdeps to get them | removed from the 32bit architectures? Yes!! I actually grep'ed among all my (100+) packages but did not see an example. I may be missing the best way to do this: so is this (new to me) 'architecture-is-64-bit' the way to do it? A quick 'apt-cache search' leads me to 'architecture-properties'. I would be in favor. So thanks for the suggestion! Are there concerns or side effects or our desire to build for as many platforms as possible etc? Building for more platforms is desirable in Debian, even if upstream doesn't officially support it. So removal from 32-bit architectures should be a last resort, only to be done if there's no other choice. Cheers, Emilio
Re: R 4.4.0 coming April 24
On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: R upstream no longer releases or tests for 32 bits (and has not since the R 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the release team may need to override this to unblock. Wouldn't it be better then to add architecture-is-64-bit to the r-base build dependencies to prevent it from building on 32bit architectures and then file partial RM bugreports for r-base and its rdeps to get them removed from the 32bit architectures? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: R 4.4.0 coming April 24
On 21 April 2024 at 15:25, Sebastiaan Couwenberg wrote: | On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: | > R upstream no longer releases or tests for 32 bits (and has not since the R | > 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the | > release team may need to override this to unblock. | | Wouldn't it be better then to add architecture-is-64-bit to the r-base | build dependencies to prevent it from building on 32bit architectures | and then file partial RM bugreports for r-base and its rdeps to get them | removed from the 32bit architectures? Yes!! I actually grep'ed among all my (100+) packages but did not see an example. I may be missing the best way to do this: so is this (new to me) 'architecture-is-64-bit' the way to do it? A quick 'apt-cache search' leads me to 'architecture-properties'. I would be in favor. So thanks for the suggestion! Are there concerns or side effects or our desire to build for as many platforms as possible etc? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Graham, Hi Release Team, On 21 April 2024 at 13:37, Graham Inggs wrote: | On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote: | > Right now it now only shows 'all reports (re-)running'. | | That was because of the new upload, but I see the results there now. | | The packages with failing autopkgtests are: | | r-bioc-iranges/2.36.0-1 | r-bioc-mutationalpatterns/3.12.0+dfsg-1 | r-bioc-s4vectors/0.40.2+dfsg-1 | r-cran-data.table/1.14.10+dfsg-1 | r-cran-ff/4.0.12+ds-1 I checked these five just now: four of them are current so I may have to leave this with their maintainer. But r-cran-data.table is quite badly behind (the once again very active upstream) and the current release is 1.15.4. I use package a lot myself and keep an eye out on their upstream work, there were some minor CRAN required updates so an update could cure that for us too. And given how widely data.table is used (i.e. by r-bioc-s4vectors which itself is used by r-bioc-iranges and r-bioc-mutationalpatterns) we quite possibly have one package causing four hickups. | > But package r-base | > has had the usual issues in unstable for a few weeks now because 'some | > people' insist on adding autopkg tests including for architectures / build | > sizes no longer supported upstream -- R stopped 32 bit support over a year | > and release ago | | For the pseudo-excuses in experimental only amd64 and arm64 are | tested, no 32-bit architectures. Ah. I expect more skirmish then. R upstream no longer releases or tests for 32 bits (and has not since the R 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the release team may need to override this to unblock. R 4.4.0 itself is fine. I decided to also eat my own dogfood and sent the same package I sent to experimental to launchpad for Ubuntu 23.10 (my daily driver here), and I am running it now for a over a day. "Everything works", I have hourly cronjobs for R too and there is no issue. So I plan to proceed with R 4.4.0. | > -- as well continually letting dependencies slip so that the | > autopkg tests involve old and outdated package releases combined with the | > fact that BioConductor has _very_ specific release cycles yet they throw | > r-bioc-* package in too) so there is little I can do on the end of package | > r-base. Briefly, I am being put into a bad corner by other maintainers here, | > and I no longer have the energy to discuss that with them. We have been at | > this for years. | | I think "discuss" was probably not the best word for Paul to suggest here. | | You only need to inform the maintainers of the affected packages, and | that can be done by filing RC bugs against the affected versions. If | the packages don't get updated, auto-removal will take care of them. | The sooner this is done, the better. Well when r-base 4.3.3-3 was being held back by what I consider autopkg overuse and a 100+ packages failed on two of the non-release-for-R 32-bit arches. I was not exactly in the mood to deal with 100+ RC bugs manually. _My package_ is fine and I take care of it. But I presume you guys have scripts for this while I do not. Some help and coordination may be useful and appreciated. One more thing: I forgot / failed to follow-up on what I had emailed about earlier. The Matrix package (aka "r-cran-matrix") update affecting the handful of packages _compiling against the Matrix header files_. That is just a few among hundreds using Matrix just as an R package (and which remain unaffected from the exported header API update which is shielded for normal use). CRAN and the Matrix team decided to wait for R 4.4.0 so Matrix will follow shortly after R 4.4.0 and I think I can handle that manually. Either n-day NMUs or simply initial bug reports requesting a rebuild. Cheers, and thanks as always for all you all on the release team do. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Dirk On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote: > Right now it now only shows 'all reports (re-)running'. That was because of the new upload, but I see the results there now. The packages with failing autopkgtests are: r-bioc-iranges/2.36.0-1 r-bioc-mutationalpatterns/3.12.0+dfsg-1 r-bioc-s4vectors/0.40.2+dfsg-1 r-cran-data.table/1.14.10+dfsg-1 r-cran-ff/4.0.12+ds-1 > But package r-base > has had the usual issues in unstable for a few weeks now because 'some > people' insist on adding autopkg tests including for architectures / build > sizes no longer supported upstream -- R stopped 32 bit support over a year > and release ago For the pseudo-excuses in experimental only amd64 and arm64 are tested, no 32-bit architectures. > -- as well continually letting dependencies slip so that the > autopkg tests involve old and outdated package releases combined with the > fact that BioConductor has _very_ specific release cycles yet they throw > r-bioc-* package in too) so there is little I can do on the end of package > r-base. Briefly, I am being put into a bad corner by other maintainers here, > and I no longer have the energy to discuss that with them. We have been at > this for years. I think "discuss" was probably not the best word for Paul to suggest here. You only need to inform the maintainers of the affected packages, and that can be done by filing RC bugs against the affected versions. If the packages don't get updated, auto-removal will take care of them. The sooner this is done, the better. Regards Graham
Re: R 4.4.0 coming April 24
Hi Paul, On 18 April 2024 at 11:50, Paul Gevers wrote: | Hi Dirk, | | On 18-04-2024 4:41 a.m., Dirk Eddelbuettel wrote: | > I uploaded a first | > beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just | > followed up with a rc release r-base_4.3.3.20240416-1. | | Thanks for preparing in experimental, as that triggers some QA. | | > Given these non-changes, I do not think we need a formal transition. If the | > release teams thinks otherwise, please let me know, ideally before April 24. | | https://qa.debian.org/excuses.php?experimental=1=r-base shows | there are 5 reverse (test) dependencies who's autopkgtest fail with the | latest r-base in experimental. You'll want to discuss with the | maintainers of those packages what that means for either r-base or their | packages (ideally by filing bug reports to track the discussion). Right now it now only shows 'all reports (re-)running'. But package r-base has had the usual issues in unstable for a few weeks now because 'some people' insist on adding autopkg tests including for architectures / build sizes no longer supported upstream -- R stopped 32 bit support over a year and release ago -- as well continually letting dependencies slip so that the autopkg tests involve old and outdated package releases combined with the fact that BioConductor has _very_ specific release cycles yet they throw r-bioc-* package in too) so there is little I can do on the end of package r-base. Briefly, I am being put into a bad corner by other maintainers here, and I no longer have the energy to discuss that with them. We have been at this for years. The r-base package itself is fine in unstable, as well as with eg the packages I maintain. It is also fine in Ubuntu (and Debian, both also via backports we coordinate at the R mirror network CRAN) and I run an add-on project [1] where *every* CRAN package (and 400+ BioConductor packages) is turned into .deb packages access from R via install.packages() (for the two most recent LTS releases). I know this stuff, I have been using and contributing to R for 25 years, I am in close contact with upstream, and I happen to sit on the R Foundation board. Cheers, Dirk [1] https://eddelbuettel.github.io/r2u | Paul | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Dirk, On 18-04-2024 4:41 a.m., Dirk Eddelbuettel wrote: I uploaded a first beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just followed up with a rc release r-base_4.3.3.20240416-1. Thanks for preparing in experimental, as that triggers some QA. Given these non-changes, I do not think we need a formal transition. If the release teams thinks otherwise, please let me know, ideally before April 24. https://qa.debian.org/excuses.php?experimental=1=r-base shows there are 5 reverse (test) dependencies who's autopkgtest fail with the latest r-base in experimental. You'll want to discuss with the maintainers of those packages what that means for either r-base or their packages (ideally by filing bug reports to track the discussion). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
R 4.4.0 coming April 24
R 4.4.0 will be released on April 24 (following the long established pattern of annual 'a.b.0' releases). As is common, nightlies (as alpha, betas, rc) have been made available for four weeks leading up to it. I uploaded a first beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just followed up with a rc release r-base_4.3.3.20240416-1. (The date is the commit date, the tar.gz sources are updated nightly.) There is no documented (or anticipated) API change (see the doc/NEWS file, I also followed up with upstream to double-check) so the virtual tag can stay at r-api-4.0, the tag we have used since R 4.0.0. The graphics API (affecting graphics devices) also did not change and remains at 16 so the (auto-generated) tag remains at r-graphics-engine-16. Given these non-changes, I do not think we need a formal transition. If the release teams thinks otherwise, please let me know, ideally before April 24. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
