Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270736 > unrolled thread

Bug#1120975: Please let r-base migrate by removing blocking packages

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1120975: Please let r-base migrate by removing blocking packages Charles Plessy <plessy@debian.org> - 2025-11-19 02:10 +0100
    Bug#1120975: Please let r-base migrate by removing blocking packages Graham Inggs <ginggs@debian.org> - 2025-11-19 12:50 +0100
      Bug#1120975: Please let r-base migrate by removing blocking packages Dirk Eddelbuettel <edd@debian.org> - 2025-11-19 13:10 +0100
        Bug#1120975: Please let r-base migrate by removing blocking packages Graham Inggs <ginggs@debian.org> - 2025-11-19 15:20 +0100
          Bug#1120975: Please let r-base migrate by removing blocking packages Adrian Bunk <bunk@debian.org> - 2025-11-19 16:00 +0100
            Bug#1120975: Please let r-base migrate by removing blocking packages Dirk Eddelbuettel <edd@debian.org> - 2025-11-19 18:00 +0100

#1270736 — Bug#1120975: Please let r-base migrate by removing blocking packages

Package: release.debian.org
X-Debbugs-Cc: debian-r@lists.debian.org

Dear Release team,

The r-base package maintained by Dirk is blocked from testing migration by
three to six r-cran-* packages maintained by us (Debian R Packages Mainainers
team).  The issue is problematic autopktests on i386, which is not supported
upstream.

    https://qa.debian.org/excuses.php?package=r-base

Can you let r-base migrate by removing them from Testing?

urgent r-base/4.5.2-1
remove r-cran-bayestestr/0.15.2-1
remove r-cran-bit64/4.6.0-1-4
remove r-cran-blme/1.0-6-1
remove r-cran-freetypeharfbuzz/0.2.6+dfsg-3
remove r-cran-grimport2/0.3-3-1
remove r-cran-projpred/2.8.0+dfsg-1

If that removes more packages from the Debian R Packages Maintainers team, the
Debian Med team or the Debian Science team, that is fine; we are planning to
remove these packages from from i386 anyway, by build-depending on
architecture-is-64-bit in a later upload.

Thanks a lot for your help!

Have a nice day,

Charles

-- 
Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team         http://www.debian.org/devel/debian-med
Tooting from home                  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

[toc] | [next] | [standalone]

#1270780

Hi Charles

On Wed, 19 Nov 2025 at 00:09, Charles Plessy <plessy@debian.org> wrote:
> The r-base package maintained by Dirk is blocked from testing migration by
> three to six r-cran-* packages maintained by us (Debian R Packages Mainainers
> team).  The issue is problematic autopktests on i386, which is not supported
> upstream.
>
>     https://qa.debian.org/excuses.php?package=r-base
>
> Can you let r-base migrate by removing them from Testing?
>
> urgent r-base/4.5.2-1
> remove r-cran-bayestestr/0.15.2-1
> remove r-cran-bit64/4.6.0-1-4
> remove r-cran-blme/1.0-6-1
> remove r-cran-freetypeharfbuzz/0.2.6+dfsg-3
> remove r-cran-grimport2/0.3-3-1
> remove r-cran-projpred/2.8.0+dfsg-1

I didn't find any RC bugs filed against any of these packages that
would prevent them from migrating straight back to testing after
removal.

Looking at the excuses page you linked to above, only r-cran-bit64,
r-cran-freetypeharfbuzz and r-cran-grimport are blocking the migration
of r-base, the remainder have "failure will be ignored".

I have filed bugs for r-cran-bit64 [1], r-cran-freetypeharfbuzz [2]
and r-cran-grimport [3].

I have added removal hints for r-cran-freetypeharfbuzz and r-cran-grimport.

> If that removes more packages from the Debian R Packages Maintainers team, the
> Debian Med team or the Debian Science team, that is fine; we are planning to
> remove these packages from from i386 anyway, by build-depending on
> architecture-is-64-bit in a later upload.

That cannot remove more packages.  The reverse-dependencies of
cran-bit64 would need to be calculated and manually removed.

In the meantime, I've added a hint to allow r-base to migrate
regardless.  We can allow r-cran-bit64 to regress on i386 and it now
has an RC bug filed against it.  I don't think any further action is
required here, but I'll confirm that r-base has migrated before
closing.

Regards
Graham

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120994
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120995
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120997

[toc] | [prev] | [next] | [standalone]

#1270785

On 19 November 2025 at 10:43, Graham Inggs wrote:
| Hi Charles
| 
| On Wed, 19 Nov 2025 at 00:09, Charles Plessy <plessy@debian.org> wrote:
| > The r-base package maintained by Dirk is blocked from testing migration by
| > three to six r-cran-* packages maintained by us (Debian R Packages Mainainers
| > team).  The issue is problematic autopktests on i386, which is not supported
| > upstream.
| >
| >     https://qa.debian.org/excuses.php?package=r-base
| >
| > Can you let r-base migrate by removing them from Testing?
| >
| > urgent r-base/4.5.2-1
| > remove r-cran-bayestestr/0.15.2-1
| > remove r-cran-bit64/4.6.0-1-4
| > remove r-cran-blme/1.0-6-1
| > remove r-cran-freetypeharfbuzz/0.2.6+dfsg-3
| > remove r-cran-grimport2/0.3-3-1
| > remove r-cran-projpred/2.8.0+dfsg-1
| 
| I didn't find any RC bugs filed against any of these packages that
| would prevent them from migrating straight back to testing after
| removal.
| 
| Looking at the excuses page you linked to above, only r-cran-bit64,
| r-cran-freetypeharfbuzz and r-cran-grimport are blocking the migration
| of r-base, the remainder have "failure will be ignored".

Out of curiousity, and as I of course saw that too on the excuses page, which
'state variable' governs this, and how can one set / unset it?
 
| I have filed bugs for r-cran-bit64 [1], r-cran-freetypeharfbuzz [2]
| and r-cran-grimport [3].

Thanks!

| I have added removal hints for r-cran-freetypeharfbuzz and r-cran-grimport.
| 
| > If that removes more packages from the Debian R Packages Maintainers team, the
| > Debian Med team or the Debian Science team, that is fine; we are planning to
| > remove these packages from from i386 anyway, by build-depending on
| > architecture-is-64-bit in a later upload.
| 
| That cannot remove more packages.  The reverse-dependencies of
| cran-bit64 would need to be calculated and manually removed.

bit64 is quite widely used as it provides an important 'workaround' trick to
offer int64_t use inside a double (with a lot of careful casting, been in use
10 or 15 years) so yes it is widely used. New upstream maintainer too (a
Googler) but the real issue here is that nobody looks at i386 anymore so we
should not let it block us either.

| In the meantime, I've added a hint to allow r-base to migrate
| regardless.  We can allow r-cran-bit64 to regress on i386 and it now
| has an RC bug filed against it.  I don't think any further action is
| required here, but I'll confirm that r-base has migrated before
| closing.

Much appreciated!

Cheers, Dirk
 
| Regards
| Graham
| 
| [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120994
| [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120995
| [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120997
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

[toc] | [prev] | [next] | [standalone]

#1270805

Hi Dirk

On Wed, 19 Nov 2025 at 11:01, Dirk Eddelbuettel <edd@debian.org> wrote:
> | Looking at the excuses page you linked to above, only r-cran-bit64,
> | r-cran-freetypeharfbuzz and r-cran-grimport are blocking the migration
> | of r-base, the remainder have "failure will be ignored".
>
> Out of curiousity, and as I of course saw that too on the excuses page, which
> 'state variable' governs this, and how can one set / unset it?

In general, it is the state of a package's autopkgtests in the testing
suite that governs this.
e.g. r-cran-bayestestr is red [1] and r-cran-bit64 is green [2] (as of
2025-11-08 09:13:11 UTC)

One way to reset the state is to trigger the autopkgtests with the
fake 'migration-reference/0' package.  If the autopkgtest is already
failing in testing and the 'migration-reference/0' result turns red,
then migration will no longer be blocked.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-bayestestr/testing/i386/
[2] https://ci.debian.net/packages/r/r-cran-bit64/testing/i386/

[toc] | [prev] | [next] | [standalone]

#1270806

On Wed, Nov 19, 2025 at 01:14:09PM -0100, Graham Inggs wrote:
> Hi Dirk
> 
> On Wed, 19 Nov 2025 at 11:01, Dirk Eddelbuettel <edd@debian.org> wrote:
> > | Looking at the excuses page you linked to above, only r-cran-bit64,
> > | r-cran-freetypeharfbuzz and r-cran-grimport are blocking the migration
> > | of r-base, the remainder have "failure will be ignored".
> >
> > Out of curiousity, and as I of course saw that too on the excuses page, which
> > 'state variable' governs this, and how can one set / unset it?
> 
> In general, it is the state of a package's autopkgtests in the testing
> suite that governs this.
> e.g. r-cran-bayestestr is red [1] and r-cran-bit64 is green [2] (as of
> 2025-11-08 09:13:11 UTC)
> 
> One way to reset the state is to trigger the autopkgtests with the
> fake 'migration-reference/0' package.  If the autopkgtest is already
> failing in testing and the 'migration-reference/0' result turns red,
> then migration will no longer be blocked.

The easiest way to do the latter:

https://tracker.debian.org/pkg/r-base
∙ ∙ Autopkgtest for r-cran-bit64/4.6.0-1-4: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, riscv64: Pass, s390x: Pass

Clicking on the recycle symbol ♻ after "reference" goes to a page with
a Retry button for the migration reference test.

> Regards
> Graham
>...

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1270822

On 19 November 2025 at 16:53, Adrian Bunk wrote:
| On Wed, Nov 19, 2025 at 01:14:09PM -0100, Graham Inggs wrote:
| > Hi Dirk
| > 
| > On Wed, 19 Nov 2025 at 11:01, Dirk Eddelbuettel <edd@debian.org> wrote:
| > > | Looking at the excuses page you linked to above, only r-cran-bit64,
| > > | r-cran-freetypeharfbuzz and r-cran-grimport are blocking the migration
| > > | of r-base, the remainder have "failure will be ignored".
| > >
| > > Out of curiousity, and as I of course saw that too on the excuses page, which
| > > 'state variable' governs this, and how can one set / unset it?
| > 
| > In general, it is the state of a package's autopkgtests in the testing
| > suite that governs this.
| > e.g. r-cran-bayestestr is red [1] and r-cran-bit64 is green [2] (as of
| > 2025-11-08 09:13:11 UTC)
| > 
| > One way to reset the state is to trigger the autopkgtests with the
| > fake 'migration-reference/0' package.  If the autopkgtest is already
| > failing in testing and the 'migration-reference/0' result turns red,
| > then migration will no longer be blocked.
| 
| The easiest way to do the latter:
| 
| https://tracker.debian.org/pkg/r-base
| ∙ ∙ Autopkgtest for r-cran-bit64/4.6.0-1-4: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, riscv64: Pass, s390x: Pass
| 
| Clicking on the recycle symbol ♻ after "reference" goes to a page with
| a Retry button for the migration reference test.

And clicking 'retry' adds a fake package 'migration-reference/0' ? That seems odd.

Dirk

| > Regards
| > Graham
| >...
| 
| cu
| Adrian

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web