Hi Dirk,

On 02-01-2024 20:42, Dirk Eddelbuettel wrote:
| The Release Team considers packages that are out-of-sync between testing
| and unstable for more than 30 days as having a Release Critical bug in

I noticed that too over the last few weeks as I tend to keep an eye on my
aggregation at https://qa.debian.org/developer.php?login=e...@debian.org

Nice. I wish every DD did that.

| This bug will trigger auto-removal when appropriate. As with all new
| bugs, there will be at least 30 days before the package is auto-removed.

Sure. Though that might be harsh / might affect other packages.

They will be notified of the autoremoval automatically and can help you fix the situation. If there's work in progress, you can delay the autoremoval by pinging this bug, that resets the timer.

We may want to consider exempting i386 as a build arch if that is possible.

Well, if you really can't support i386 anymore (we expect from DD to support as many architectures as is *reasonably* possible), you should arrange for the removal of the i386 package, including all reverse i386 dependencies. It would be good to coordinate this with your reverse dependencies (at least inform them). In the end removal happens by filing appropriate RM bugs against the ftp.debian.org pseudo package.

| If you believe your package is unable to migrate to testing due to
| issues beyond your control, don't hesitate to contact the Release Team.

:wave:

FTBFS of your own package is what I consider to be in your control (this text is part of the template I use). Either you fix the issue, or you decide to no long support i386 with your package, but you'll need to coordinate with your reverse dependencies. The removal happens by ftp-master once you file the appropriate bugs.

This is an R package, and R no longer releases on i386 meaning upstream may
not have checked / may not be receptive. See eg [1] for the CRAN state of the
package. No i386 there.

I am not sure what else to do besides simply saying 'no longer builds on i386'.

Maybe contact i386 porters for help creating a patch? (We have one: Adrian Bunk).

Having said all that, most of our upstreams don't support (for some value of support) all the architectures that we support. Still we expect from DD to put in *reasonable* effort to support their packages on our architectures. So, the call to drop an architecture from the supported list is yours to make as a maintainer.

Paul

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to