Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi On 18-12-2023 10:07, Andreas Tille wrote: https://tracker.debian.org/pkg/r-bioc-megadepth d/tests/control has Architecture: !s390x Why is it considered failing on s390x anyway? The log has this at the end: 127s run-unit-testSKIP Test declares architecture as not supported: s390x 127s run-unit-testSKIP Test declares architecture as not supported: s390x 127s pkg-r-autopkgtestFAIL non-zero exit status 1 pkg-r-autopkgtest comes from autodep8. You didn't tell autodep8 that you wanted s390x to be excluded also from that test. https://tracker.debian.org/pkg/r-bioc-scater While this is an Architecture:all package it Depends from r-bioc-densvis which exists only on amd64 and arm64 due to the Build-Depends: r-bioc-basiklisk. Thus tests on other architectures are failing since r-bioc-densvis is not installable. What solution do you suggest in this case? Well, mark the test as amd64 and arm64 only? Were this due to Depends (and thus the package not installable) the test would *automatically* not be scheduled if I'm correct, but it works differently for test dependencies. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Graham, Am Sun, Dec 17, 2023 at 02:11:47PM -0100 schrieb Graham Inggs: > There are some packages that have still not migrated since the > previous r-api-bioc-3.17 transition in July 2023. > > Links to their tracker pages, which should tell you what is needed, follow: > > https://tracker.debian.org/pkg/r-bioc-cner Fixed. > https://tracker.debian.org/pkg/r-bioc-dada2 > https://tracker.debian.org/pkg/r-bioc-edaseq > https://tracker.debian.org/pkg/r-bioc-ioniser Due to shortread. > https://tracker.debian.org/pkg/r-bioc-megadepth d/tests/control has Architecture: !s390x Why is it considered failing on s390x anyway? > https://tracker.debian.org/pkg/r-bioc-scater While this is an Architecture:all package it Depends from r-bioc-densvis which exists only on amd64 and arm64 due to the Build-Depends: r-bioc-basiklisk. Thus tests on other architectures are failing since r-bioc-densvis is not installable. What solution do you suggest in this case? > https://tracker.debian.org/pkg/r-bioc-shortread Fixed. > https://tracker.debian.org/pkg/r-bioc-tcgabiolinks Reported upstream ( https://github.com/BioinformaticsFMRP/TCGAbiolinks/issues/612 ) > https://tracker.debian.org/pkg/r-bioc-tfbstools Due to cner which is fixed. > As a bonus, here's another, not related to the transition, but from a > similar time: > https://tracker.debian.org/pkg/r-cran-dials Forgot source-only upload - done. Thanks a lot for the links Andreas. -- http://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Andreas There are some packages that have still not migrated since the previous r-api-bioc-3.17 transition in July 2023. Links to their tracker pages, which should tell you what is needed, follow: https://tracker.debian.org/pkg/r-bioc-cner https://tracker.debian.org/pkg/r-bioc-dada2 https://tracker.debian.org/pkg/r-bioc-edaseq https://tracker.debian.org/pkg/r-bioc-ioniser https://tracker.debian.org/pkg/r-bioc-megadepth https://tracker.debian.org/pkg/r-bioc-scater https://tracker.debian.org/pkg/r-bioc-shortread https://tracker.debian.org/pkg/r-bioc-tcgabiolinks https://tracker.debian.org/pkg/r-bioc-tfbstools As a bonus, here's another, not related to the transition, but from a similar time: https://tracker.debian.org/pkg/r-cran-dials Regards Graham
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Paul, Am Wed, Dec 13, 2023 at 09:56:14PM +0100 schrieb Paul Gevers: > > > Not built on buildd: arch all binaries uploaded by tille, a new > > > source-only upload is needed to allow migration > > > > I do not understand this line. What exact package needs a source-only > > upload? > > You uploaded binaries together with the source. Because this is an arch:all > binary we can't binNMU in a meaningful way and we don't accept uploader > built binaries in testing anymore. Currently the only way to solve this is > by doing a source-only (so, no binaries) upload (of r-bioc-biocgenerics). This must have been by pure accident since I never do so except for packages targeting new. I did a source-only upload for r-bioc-biocgenerics. > > Please let me know if I > > can do something to fix the situation, but for the moment I have no idea > > what to do. > > Patches for britney2 please ;). I'm using this chance to thank you for all your work in the release team and patchinbg britney2 at least to the current state. > I'll try to do some manual triggering of tests tonight/tomorrow, but after a > quick glance, that might be too much to handle manually. > > Paul > > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics > [tracker] https://tracker.debian.org/teams/r-pkg-team/ the piece below > Packages with test failures: if it goes from passing in testing to fail in > unstable there is potentially a problem This tracker page was new to me and is extremely helpful! Thanks to whoever this thanks deserves. Very helpful also for other teams I'm working in. > [excuses] https://release.debian.org/britney/update_excuses.html > [yaml] https://release.debian.org/britney/excuses.yaml.gz Well, it also points to several pandoc related issues which I can't do anything about. > [britney2] > https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py#L622 > until line 743 Please let me know when I (realistically) can do more than just that source-only upload mentioned above. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi, On 13-12-2023 17:08, Andreas Tille wrote: Not built on buildd: arch all binaries uploaded by tille, a new source-only upload is needed to allow migration I do not understand this line. What exact package needs a source-only upload? You uploaded binaries together with the source. Because this is an arch:all binary we can't binNMU in a meaningful way and we don't accept uploader built binaries in testing anymore. Currently the only way to solve this is by doing a source-only (so, no binaries) upload (of r-bioc-biocgenerics). Remember, all r-bioc-* packages need to migrate together, so all of your uploads need to be ready before r-bioc-biocgenerics can migrate. I checked only the first few "Migrates after" links from [1], and found at least these packages still show autopkgtest regressions [2][3][4][5][6]. Thank you for these links. Could you please explain how I can obtain these myself? Is there any page I could look at for some kind of summary? I read in Graham's message that he started at [1] and just clicked the links. I don't think there's a great web site yet ([tracker] comes close), except udd has all the information which can be queried and *all* excuses can be viewed too [excuses] (or processed [yaml]). [2] https://tracker.debian.org/pkg/r-bioc-beachmat This shows: autopkgtest for r-bioc-biocsingular/1.16.0+ds-1: amd64: Regression or new test... but that version of r-bioc-biocsingular is in testing and bound to fail. Version 1.18.0+ds matches to BioC API 3.18. I wonder if it might be that britney2 doesn't notice that if it needs to take r-bioc-biocgenerics from unstable to run a test, that r-api-bioc-3.17 is no longer provided and hence also the test needs to come from unstable. Obviously there's room for improvement there, but the amount of code to determine the set of pinned packages from unstable is already rather long. [britney2] I admit I have no idea what to do. If the migration issues are caused by running tests against versions in testing which can't pass something is broken. They *should* be scheduled with the test from unstable, as the binaries depend on r-api-bioc-3.17 which will no longer be available when r-bioc-biocgenerics is used from unstable. Please let me know if I can do something to fix the situation, but for the moment I have no idea what to do. Patches for britney2 please ;). I'll try to do some manual triggering of tests tonight/tomorrow, but after a quick glance, that might be too much to handle manually. Paul [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [tracker] https://tracker.debian.org/teams/r-pkg-team/ the piece below Packages with test failures: if it goes from passing in testing to fail in unstable there is potentially a problem [excuses] https://release.debian.org/britney/update_excuses.html [yaml] https://release.debian.org/britney/excuses.yaml.gz [britney2] https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py#L622 until line 743 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Graham, Am Wed, Dec 13, 2023 at 12:13:54PM -0100 schrieb Graham Inggs: > I've added removal hints for r-bioc-dss and r-bioc-demixt. Please > file an RC bug for r-bioc-dss to prevent it from migrating straight > back (r-bioc-demixt already has #1058278). Done for r-bioc-dss. > One problem I see at [1]: > > Not built on buildd: arch all binaries uploaded by tille, a new > source-only upload is needed to allow migration I do not understand this line. What exact package needs a source-only upload? > Remember, all r-bioc-* packages need to migrate together, so all of > your uploads need to be ready before r-bioc-biocgenerics can migrate. > I checked only the first few "Migrates after" links from [1], and > found at least these packages still show autopkgtest regressions > [2][3][4][5][6]. Thank you for these links. Could you please explain how I can obtain these myself? Is there any page I could look at for some kind of summary? Now to these links: > > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics OK, no idea what source-only upload is needed (see above). > [2] https://tracker.debian.org/pkg/r-bioc-beachmat This shows: autopkgtest for r-bioc-biocsingular/1.16.0+ds-1: amd64: Regression or new test... but that version of r-bioc-biocsingular is in testing and bound to fail. Version 1.18.0+ds matches to BioC API 3.18. Autopkgtest in Salsa CI works as expected. When looking in debci (https://ci.debian.net/packages/r/r-bioc-biocsingular/unstable/amd64/40579344/) the test suite error is caused by pandoc. > [3] https://tracker.debian.org/pkg/r-bioc-biobase Same here: autopkgtest for r-bioc-degreport/1.36.0+dfsg-1: amd64: Regression or new test... we have r-bioc-degreport 1.38.3+dfsg-1 in unstable matching BioC API 3.18. Failures with any former version is bound to fail. Similarly: autopkgtest for r-bioc-multiassayexperiment/1.26.0+dfsg-1: amd64: Regression or new test... version in testing not unstable > [4] https://tracker.debian.org/pkg/r-bioc-biocbaseutils See above autopkgtest for r-bioc-multiassayexperiment/1.26.0+dfsg-1: amd64: Regression or new test... > [5] https://tracker.debian.org/pkg/r-bioc-biocio > [6] https://tracker.debian.org/pkg/r-bioc-biostrings Same problem as above autopkgtest for r-bioc-bsgenome/1.68.0-1: amd64: Regression or new test... in both cases. I admit I have no idea what to do. If the migration issues are caused by running tests against versions in testing which can't pass something is broken. As you wrote above > Remember, all r-bioc-* packages need to migrate together, ... yes, that's why running debci tests is not needed - at least as far as I understood the purpose of a transition. Please let me know if I can do something to fix the situation, but for the moment I have no idea what to do. Sorry if I'm a bit slow to catch on. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Andreas On Wed, 13 Dec 2023 at 09:45, Andreas Tille wrote: > as you might have noticed the upstream source for r-bioc-dss and > r-bioc-demixt are missing and upstream did not answered two mails about > this. Since the transition looks clean for me so far[1] after I fixed > two autopkgtest issues yesterday I (naively) think we could remove > r-bioc-dss and r-bioc-demixt from testing and all other packages can > migrate to finish the transition from r-bioc perspective. I've added removal hints for r-bioc-dss and r-bioc-demixt. Please file an RC bug for r-bioc-dss to prevent it from migrating straight back (r-bioc-demixt already has #1058278). One problem I see at [1]: Not built on buildd: arch all binaries uploaded by tille, a new source-only upload is needed to allow migration Remember, all r-bioc-* packages need to migrate together, so all of your uploads need to be ready before r-bioc-biocgenerics can migrate. I checked only the first few "Migrates after" links from [1], and found at least these packages still show autopkgtest regressions [2][3][4][5][6]. Regards Graham > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [2] https://tracker.debian.org/pkg/r-bioc-beachmat [3] https://tracker.debian.org/pkg/r-bioc-biobase [4] https://tracker.debian.org/pkg/r-bioc-biocbaseutils [5] https://tracker.debian.org/pkg/r-bioc-biocio [6] https://tracker.debian.org/pkg/r-bioc-biostrings
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
On Wed, Dec 13, 2023 at 11:43:56AM +0100, Andreas Tille wrote: >... > I'm worried > about issues in r-rcan-rmarkdown[3] and r-cran-flextable[4] which are > caused by pandoc errors on ppc64el architecture *only*. That's really > strange and might mean that pandoc on this architecture is broken? >... ppc64el has Lua support disabled[1] due to [2] (#1057857), AFAIK that's the last non-trivial issue of the Haskell transition. I haven't confirmed that this is related, but that would be my first guess for the ppc64el-only [3] in pandoc. > Kind regards > Andreas. >... cu Adrian [1] https://tracker.debian.org/media/packages/p/pandoc/control-3.0.1ds-3 [2] https://buildd.debian.org/status/package.php?p=haskell-lua [3] https://tracker.debian.org/pkg/pandoc
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi, as you might have noticed the upstream source for r-bioc-dss and r-bioc-demixt are missing and upstream did not answered two mails about this. Since the transition looks clean for me so far[1] after I fixed two autopkgtest issues yesterday I (naively) think we could remove r-bioc-dss and r-bioc-demixt from testing and all other packages can migrate to finish the transition from r-bioc perspective. I'm wondering what I can do in some cases that are caused by the pandoc issue like shortread[2] which should be solved in principle. I'm worried about issues in r-rcan-rmarkdown[3] and r-cran-flextable[4] which are caused by pandoc errors on ppc64el architecture *only*. That's really strange and might mean that pandoc on this architecture is broken? Regarding pandoc I've just uploaded a fix for pypandoc (fixing bugs #1057946 and #1058153) I have neither any clue nor any time to check nbconvert. Kind regards Andreas. [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [2] https://tracker.debian.org/pkg/r-bioc-shortread [3] https://ci.debian.net/packages/r/r-cran-rmarkdown/testing/ppc64el/40945637/ [4] https://ci.debian.net/packages/r/r-cran-flextable/testing/ppc64el/40945625/ -- http://fam-tille.de
