[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)



Hi,

the last new precondition was accepted so all r-bioc-* packages are
uploaded and built meanwhile.  The only not-transitioned package is
r-bioc-bitseq where I filed a removal bug for[1].  So we have at least
all r-bioc-* packages in their current version.

[1] https://bugs.debian.org/1049359

Am Tue, Aug 01, 2023 at 01:06:41PM +0000 schrieb Graham Inggs:
> Hi Andreas
> 
> You should check on the package tracker pages for all the r-bioc-*
> uploads and make sure they are ready to migrate along with
> r-bioc-biocgenerics, e.g. r-bioc-cummerbund [1].
> 
> r-bioc-biocversion appears to break the autopkgtest of
> r-cran-biocmanager/1.30.21.1+dfsg-1 in testing.

We now have 1.30.22+dfsg-2 in unstable which passes its tests.  Do we
need to do some further action?
 
> At least the following packages are failing their own autopkgtests in
> unstable (list not complete):
> r-bioc-cummerbund
> r-bioc-decoupler
> r-bioc-monocle
> r-bioc-scran
> r-bioc-singler

Most of those packages have autopkgtests marked as
   Failed (not a regression)
Am I correct that we do not need to take any action regarding the
transition?  The only exception in this list (as far as I can see) is

  https://tracker.debian.org/pkg/r-bioc-scran

I'm about to verify the possibly rounding error for i386 which might be
fixed by relaxing the boundaries or ignoring this single test.  I'm
wondering about the issue with ppc64el where the log[2] says:

 43s   Broken autopkgtest-satdep:ppc64el Depends on r-bioc-scrnaseq:ppc64el < none @un H >
 43s   Considering r-bioc-scrnaseq:ppc64el 2 as a solution to autopkgtest-satdep:ppc64el -2
 43s   Removing autopkgtest-satdep:ppc64el rather than change r-bioc-scrnaseq:ppc64el

 
> r-bioc-dupradar has regressed from passing to neutral, apparently due
> to the use of 'skip-not-installable'.  Please don't use this
> restriction on all the autopkgtests in a package, otherwise there are
> no tests which are not superficial, and regressions can migrate to
> testing.

Could you please be more verbose about this hint (may be suggesting a
patch that implements your suggestion since I'm afraid I do not
understand this correctly)

Do you see any further blockers?

Kind regards
    Andreas.
 

[2] https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/r-bioc-scran/36185915/log.gz 

-- 
http://fam-tille.de


Reply to: