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 <e...@debian.org> 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
