Dear maintainer(s), 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 testing [1]. Your package src:rjava has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on i386. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. 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. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. 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. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg00001.html [2] https://qa.debian.org/excuses.php?package=rjava
On 2 January 2024 at 20:07, Paul Gevers wrote: | Source: rjava | Version: 1.0-6-1 | Severity: serious | Control: close -1 1.0-10-1 | Tags: sid trixie ftbfs | User: release.debian.org@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | 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=edd@debian.org | testing [1]. Your package src:rjava has been trying to migrate for 31 | days [2]. Hence, I am filing this bug. The version in unstable failed to | build on i386. | | If a package is out of sync between unstable and testing for a longer | period, this usually means that bugs in the package in testing cannot be | fixed via unstable. Additionally, blocked packages can have impact on | other packages, which makes preparing for the release more difficult. | Finally, it often exposes issues with the package and/or | its (reverse-)dependencies. We expect maintainers to fix issues that | hamper the migration of their package in a timely manner. | | 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. We may want to consider exempting i386 as a build arch if that is possible. | I have immediately closed this bug with the version in unstable, so if | that version or a later version migrates, this bug will no longer affect | testing. I have also tagged this bug to only affect sid and trixie, so | it doesn't affect (old-)stable. | | 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: 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'. Dirk [1] https://cran.r-project.org/web/checks/check_results_rJava.html | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg00001.html | [2] https://qa.debian.org/excuses.php?package=rjava | | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature]
Hi Dirk, Nice. I wish every DD did that. 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. 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. 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. 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
(Adrian: Added you to CCs per suggestion of Paul.) Hi Paul, On 2 January 2024 at 21:00, Paul Gevers wrote: | 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=edd@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. Ok. I can do that. I just look at 'rdepends' for r-cran-rjava and it is only five packages. That seems fair. | > | 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). Good idea. Have CC'ed Adrian to see if he wants to jump in. | 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. It is not easy to strike the right balance, ie for m68k we 'hang on' for a long time as we had motivated maintainers / porters / developers. Not sure we had users :) For i386 we have been patient too. The hardware has been EOL for some time and most projects have ceased explicit support. That is a fair sign. If someone wants to help, I am happy to play along. But if not, I think for a 'somewhat marginal leaf-alike' dependency such as rJava aka r-cran-rjava removing i386 support is defensible. We only support approx 1k out 20k CRAN packages so users are accustomed to having to go elsewhere anyway. I packaged rJava nearly 20 years ago because it is a 'difficult' package for many users and our integration helps. I still maintain it for the same reason, even if Java is also way more marginal within R now. So for i386 the end may be coming. Cheers, Dirk | Paul | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature]
The rJava package (source package 'rjava', binary package r-cran-rjava) no
longer builds on i386 as most of the world, including R and its CRAN network,
have moved on from i386.
So I am requesting the removal of the i386 builds from testing so that the
package can migrate; it works and tests fine everywhere else.
Four packages are listed as reverse depends (see below). I will have to
presumably 'climb the tree' and request removal of each of these and will
likely dues so in due course. For now, I am CCing the packages in question,
as well as the initial bug report #1059875.
Dirk
$ ssh mirror.ftp-master.debian.org "dak rm -Rn rjava"
Will remove the following packages from unstable:
r-cran-rjava | 1.0-6-1+b1 | i386
r-cran-rjava | 1.0-10-1 | amd64, arm64, armel, armhf, mips64el, ppc64el, riscv64, s390x
rjava | 1.0-6-1 | source
rjava | 1.0-10-1 | source
Maintainer: Dirk Eddelbuettel <edd@debian.org>
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
libgoby-java: goby-java
r-cran-rcdk: r-cran-rcdk
r-cran-rcdklibs: r-cran-rcdklibs
# Broken Build-Depends:
beast-mcmc: r-cran-rjava
libgoby-java: r-cran-rjava
r-cran-rcdk: r-cran-rjava
r-cran-rcdklibs: r-cran-rjava
Dependency problem found.
$
( Resending to now correctly-typed package r-cran-rcdklibs -- Dirk ) On 11 January 2024 at 07:09, Dirk Eddelbuettel wrote: | | Package: ftp.debian.org | Severity: normal | | The rJava package (source package 'rjava', binary package r-cran-rjava) no | longer builds on i386 as most of the world, including R and its CRAN network, | have moved on from i386. | | So I am requesting the removal of the i386 builds from testing so that the | package can migrate; it works and tests fine everywhere else. | | Four packages are listed as reverse depends (see below). I will have to | presumably 'climb the tree' and request removal of each of these and will | likely dues so in due course. For now, I am CCing the packages in question, | as well as the initial bug report #1059875. | | Dirk | | | $ ssh mirror.ftp-master.debian.org "dak rm -Rn rjava" | Will remove the following packages from unstable: | | r-cran-rjava | 1.0-6-1+b1 | i386 | r-cran-rjava | 1.0-10-1 | amd64, arm64, armel, armhf, mips64el, ppc64el, riscv64, s390x | rjava | 1.0-6-1 | source | rjava | 1.0-10-1 | source | | Maintainer: Dirk Eddelbuettel <edd@debian.org> | | ------------------- Reason ------------------- | | ---------------------------------------------- | | Checking reverse dependencies... | # Broken Depends: | libgoby-java: goby-java | r-cran-rcdk: r-cran-rcdk | r-cran-rcdklibs: r-cran-rcdklibs | | # Broken Build-Depends: | beast-mcmc: r-cran-rjava | libgoby-java: r-cran-rjava | r-cran-rcdk: r-cran-rjava | r-cran-rcdklibs: r-cran-rjava | | Dependency problem found. | | $ | | | -- | dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org