Hi Charles, Hi Paul,
On 13 February 2026 at 22:13, Paul Gevers wrote: | On 2/11/26 02:52, Charles Plessy wrote: | > If there were a system empowering me to remove r-cran-rncl from the way, | > I would surely use it, but I am not aware of such a tool. | | I don't recall I've seen one removal bug from you for an r-cran-* | package for your 32-bit/big-endian uploads. I recognize that you don't | like them, but that is the current system to deal with this. Filing RC | bugs to your own packages will have them removed from testing, which | means they are not in the way of other packages, but that's obviously | less nice. | | The ftp team can be asked to speed up processing a removal bug if it | blocks other things and they respond typically quickly to requests like | that (on irc). Needless to say, as the one on the receiving end with a package blocked that is a pure bystander here: I would of course be in favour of such a resolution. I just got another bunch of mass-removal, in my case for 31 (!!) packages, and this appears once again from unbuildable package/arch combination once again involving i386 (and armhf and s390x) -- architectures where CRAN does not test, cannot help and we are on our own. Which what may be limited maintainer firepower. Cheers, Dirk PS At the risk of repeating myself, I do maintain all of CRAN as binaries in my Ubuntu add-on repo 'r2u' for two LTS releases one of which has two architectures now. All via GitHub Actions now. One can automate all of this; it is compelling to have 23,000 r-cran-* binaries and 500 r-bioc-* binaries. -- dirk.eddelbuettel.com | @eddelbuettel | [email protected]
