Re: Seems we need a transition for r-base instead of lots of single bugs against single packages (Was: Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1))
Hi Dirk,
Am Wed, Jun 28, 2023 at 10:33:43AM -0500 schrieb Dirk Eddelbuettel:
> | | GRAPHICS:
> | | • The graphics engine version, R_GE_version, has been bumped to 16 and so packages
> | | that provide graphics devices should be reinstalled.
> |
> | This is a good indication that packages in debian that use graphics API
> | (like cairo or ggplot) which are compiled against 4.2 would not work
> | with the new 4.3, which is also confirmed from the autopkgtest failures
> | for the same.
>
> That is correct, and someone (on one of the R lists) posted a search query eg
> for GitHub's 'cran' org which is de facto a mirror of CRAN (and a superset as
> CRAN retires packages but that org does not delete them). If we can batch
> search our git repo you can find them too.
This query would be helpful. Do you have any link.
> | I agree that doing binNMU for arch:any packages that need re-building
> | makes sense. However, in a few cases these packages also have a new
> | upstream release, which is compatible with a new r-base release.
> | Hence, we have to go ahead and update then anyway.
>
> That has always been my pragmatic take. Given the freeze many packages need
> either a catch up if they lag, or a rebuild from experimental. I did that for
> mine.
As the bug reports show not only outdated packages are affected. We
have also bug reports with race conditions between the actual upload and
the bug filed. You can take for granted that I'm busy with the post
release upgrade. BioC transition is pending as well but I wanted to
cleanup CRAN first - just with the speed I can approach for the amount
of work (@Nilesh and others help is welcome as always).
Thanks for becoming constructive again. I'd be happy if you could skip
the offenses in your initial response in the future.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: