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:rkward has been trying to migrate for 31
days [2], hence this bug report. The current output of the migration
software for this package is copied to the bottom of this report and
should list the reason why the package is blocked.

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.

This bug submission immediately closes the bug with the version in
unstable, so if that version or a later version migrates, this bug will
no longer affect testing. This bug is also tagged 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.

This bug report has been automatically generated and has only been sent
manually. If you have any comments with regards to the content or the
process, please reach out to me.

Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg00001.html
[2] https://qa.debian.org/excuses.php?package=rkward

Current text from [2]:
Migration status for rkward (0.8.0-3 to 0.8.0-4): BLOCKED:
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
∙ ∙ Updating rkward would introduce bugs in testing: #1103204
Additional info:
∙ ∙ Piuparts tested OK -
https://piuparts.debian.org/sid/source/r/rkward.html
∙ ∙ Waiting for reproducibility test results on armhf - info ♻ ∙ ∙ 31
days old (needed 10 days)

Hello.

This package should propagate to testing to fix RC bug #1103204.

However, it has r-base-core (>= 4.5.1-1) in its Depends line, while
r-base-core in trixie is at version 4.5.0-3, so the migration
will not happen in a natural way.

After asking Dirk (maintainer of R packages, in CC) for advice about
this, it seems there are basically two ways to deal with this.

A) Make an upload for trixie-proposed-updates. This would put the
package directly in trixie with >= trixie-version.

B) Hardcode (>= 4.5.0-3) (or maybe 4.5.0-3~ or just 4.5.0) in the
control line, only for trixie, and only as a one-time thing. Dirk
tells me that in cases like this one, this would be ok, as R does not
really care about such minor versioning.

Please indicate if you (maintainers of rkward) are available to fix
this, because otherwise Dirk tells me he would be willing to NMU
the package to handle the issue.

Thanks.

On 25 July 2025 at 01:18, Santiago Vila wrote:
| Hello.
|
| This package should propagate to testing to fix RC bug #1103204.
|
| However, it has r-base-core (>= 4.5.1-1) in its Depends line, while
| r-base-core in trixie is at version 4.5.0-3, so the migration
| will not happen in a natural way.
|
| After asking Dirk (maintainer of R packages, in CC) for advice about
| this, it seems there are basically two ways to deal with this.
|
| A) Make an upload for trixie-proposed-updates. This would put the
| package directly in trixie with >= trixie-version.
|
| B) Hardcode (>= 4.5.0-3) (or maybe 4.5.0-3~ or just 4.5.0) in the
| control line, only for trixie, and only as a one-time thing. Dirk
| tells me that in cases like this one, this would be ok, as R does not
| really care about such minor versioning.

For added colour: I am aware of breakage with other applications built
against R 4.4.* and linking to it now falling over of a missing symbol under
R 4.5.* -- this happened famously with rstudio (outside of Debian).

Changes within a minor version are known-compatible so compiling under R
4.5.1 but allowing R 4.5.0 as a runtime will work, and I offered Santiago to
help with a NMU.

Obviously not trying to either 'jump a gun' or stepping onto somebody's toes
so if any of you as group maintainers want to deal with it I will merrily
defer. Else I am happy to step in an help with a quick one-time override to
debian/control depending on 'R (>= 4.5.0)' as opposed to the automagic
fill-in from $rvers which will get us 4.5.1 which is only in unstable and not
in testing.

Cheers,  Dirk

| Please indicate if you (maintainers of rkward) are available to fix
| this, because otherwise Dirk tells me he would be willing to NMU
| the package to handle the issue.
|
| Thanks.