Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas On Wed, 16 Aug 2023 at 11:24, Andreas Tille wrote: > Am Tue, Aug 01, 2023 at 01:06:41PM + schrieb Graham Inggs: > > 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? Well, it means those autopkgtests already regressed in testing, but they do not block migration. Now that r-bioc-biocgenerics has migrated, you can see that at least r-bioc-cummerbund, r-bioc-scran and r-bioc-singler are still blocked by other packages which need attention. > > 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) --- a/debian/tests/autopkgtest-pkg-r.conf +++ b/debian/tests/autopkgtest-pkg-r.conf @@ -2,4 +2,3 @@ r-cran-knitr, \ r-cran-rmarkdown, \ r-bioc-annotationhub -extra_restrictions=skip-not-installable In general, skip-not-installable is no good as it does not catch when packages are non-installable, and during that time, it can hide other regressions and allow them to migrate. It may have some special use cases; e.g. a test depending on a package that is only available in unstable (virtualbox or openjdk-8), but skip-not-installable should not be applied to a package's only autopkgtest, or all of them, only the one that actually requires it. On Fri, 18 Aug 2023 at 10:40, Andreas Tille wrote: > I've fixed r-bioc-decoupler manually to remove this blocker quickly > (instead of working around invalid version specifications by detecting > these in dh-r) Thanks! elbrus marked r-bioc-decoupler urgent, and rather than being blocked by the autopkgtest regression of r-bioc-metagenomeseq, I removed 1.40.0-1 from testing (previously removed on 2023-07-16, but somehow migrated again) to allow r-bioc-biocgenerics to migrate. > Do you see any other blocker? Besides those packages mentioned above, there are others still needing attention. These can be seen on the team's DDPO page [1], just search for 'Excuse' there. Regards Graham [1] https://qa.debian.org/developer.php?email=r-pkg-team%40alioth-lists.debian.net
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Graham, Am Wed, Aug 16, 2023 at 09:23:00PM + schrieb Graham Inggs: > tracker.d.o. is having some issues (see #1043546), but you can still > access up-to-date excuses here: > https://qa.debian.org/excuses.php?package=r-bioc-biocgenerics > > The current blocker I see is: > Implicit dependency: r-bioc-biocgenerics r-bioc-decoupler (not considered) I've fixed r-bioc-decoupler manually to remove this blocker quickly (instead of working around invalid version specifications by detecting these in dh-r) Do you see any other blocker? Kind regards Andreas. -- http://fam-tille.de
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas Sorry for the incomplete reply. I'll respond to the other points when I have more time. On Wed, 16 Aug 2023 at 11:24, Andreas Tille wrote: > Do you see any further blockers? tracker.d.o. is having some issues (see #1043546), but you can still access up-to-date excuses here: https://qa.debian.org/excuses.php?package=r-bioc-biocgenerics The current blocker I see is: Implicit dependency: r-bioc-biocgenerics r-bioc-decoupler (not considered) Regards Graham
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 + 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
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
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. 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 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. Regards Graham [1] https://tracker.debian.org/pkg/r-bioc-cummerbund
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas, On 29-07-2023 21:52, Andreas Tille wrote: IT can't be uploaded since the new version will not build due to the missing dependencies that need to clear new. As I understand it, you don't need to wait with *uploading*, the buildd's will just wait building until the build dependencies cleared NEW. So, just upload and forget about it (unless you're worried about "using" the version number already, but that was not your argument). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Paul, Am Sat, Jul 29, 2023 at 07:44:32PM +0200 schrieb Paul Gevers: > > Well, I didn't check everything yet (hint is at [1]) Thanks for the hint - this was the point I wanted to make with my mail. > but at least the > autopkgtest regression in r-bioc-rhdf5filters (see [2] to find that in > unstable it fails too) should really be solved.. Thanks to Nilesh for fixing it. > For several of the other > packages, you see that the right versioned (test) dependencies aren't > declared, so the test pass in unstable, but fails to pull in the right > dependencies when tested in the migration scenario. I enhanced dh-r to inject the versioned Depends declared by upstream as long as these are packaged. That's no guarantee that our tests will work but hopefully a first step to enhance the situation. > Also, but that's more my > fault than yours, there are a bunch of packages in testing that fail their > tests there because their *test* dependencies aren't in testing. Those > should be pulled in by the migration scenario, but I hope none of the three > packages mentioned above are needed for other tests, because then the tests > will keep failing until NEW is cleared. > > > If you agree it might make sense to not touch r-bioc-* packages to let > > the testing migration happen. > > Well, any fix for triggered autopkgtest failure due to the lack of the right > constraints (versioned (test) dependencies and/or breaks) might actually > help speed up the process, because it will need less hand-holding. I'm just hoping for the team since I'm busy with real life and will be absolutely offline from tomorrow noon for at least 24 hours. > PS: I'm not seeing the uploads of r-bioc-isoformswitchanalyzer and > r-bioc-scater yet IT can't be uploaded since the new version will not build due to the missing dependencies that need to clear new. I see no sense in rebuilding the old versions since they do not fit the bioconductor version of all other r-bioc-* packages. I intended to express with my mail that those packages are not and can not be uploaded. Kind regards Andreas. > [1] https://people.debian.org/~elbrus/ci/regressions.html (grey is only in > unstable) > [2] https://ci.debian.net/packages/r/r-bioc-rhdf5filters/ -- http://fam-tille.de
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
On Sat, Jul 29, 2023 at 07:44:32PM +0200, Paul Gevers wrote: > Well, I didn't check everything yet (hint is at [1]) but at least the > autopkgtest regression in r-bioc-rhdf5filters (see [2] to find that in > unstable it fails too) should really be solved. I've fixed hdf5filters and uploaded to unstable. This was a fallout with the patch I had supplied earlier. Thanks for pointing it out. Best, Nilesh signature.asc Description: PGP signature
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas, On 29-07-2023 12:51, Andreas Tille wrote: all r-bioc-* packages except r-bioc-bitseq which is not maintained upstream and should probably be removed (as in the last transition) and r-bioc-scater r-bioc-deseq r-bioc-isoformswitchanalyzer are uploaded. The latter three have new dependencies which are uploaded to new. Since all four exceptions are in sid only we could consider the transition done and the majority of r-bioc-* packages can migrate to testing. We can wait for new processing for those three remaining packages which does not really affect all other r-bioc-* packages. Well, I didn't check everything yet (hint is at [1]) but at least the autopkgtest regression in r-bioc-rhdf5filters (see [2] to find that in unstable it fails too) should really be solved. For several of the other packages, you see that the right versioned (test) dependencies aren't declared, so the test pass in unstable, but fails to pull in the right dependencies when tested in the migration scenario. Also, but that's more my fault than yours, there are a bunch of packages in testing that fail their tests there because their *test* dependencies aren't in testing. Those should be pulled in by the migration scenario, but I hope none of the three packages mentioned above are needed for other tests, because then the tests will keep failing until NEW is cleared. > If you agree it might make sense to not touch r-bioc-* packages to let > the testing migration happen. Well, any fix for triggered autopkgtest failure due to the lack of the right constraints (versioned (test) dependencies and/or breaks) might actually help speed up the process, because it will need less hand-holding. Paul PS: I'm not seeing the uploads of r-bioc-isoformswitchanalyzer and r-bioc-scater yet [1] https://people.debian.org/~elbrus/ci/regressions.html (grey is only in unstable) [2] https://ci.debian.net/packages/r/r-bioc-rhdf5filters/ OpenPGP_signature Description: OpenPGP digital signature
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi, all r-bioc-* packages except r-bioc-bitseq which is not maintained upstream and should probably be removed (as in the last transition) and r-bioc-scater r-bioc-deseq r-bioc-isoformswitchanalyzer are uploaded. The latter three have new dependencies which are uploaded to new. Since all four exceptions are in sid only we could consider the transition done and the majority of r-bioc-* packages can migrate to testing. We can wait for new processing for those three remaining packages which does not really affect all other r-bioc-* packages. If you agree it might make sense to not touch r-bioc-* packages to let the testing migration happen. Kind regards Andreas. -- http://fam-tille.de
