Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)
Hi Paul, Am Mon, Nov 28, 2022 at 08:23:12PM +0100 schrieb Paul Gevers: > > I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to > > follow the transition status. I realised that debci picks old, not yet > > fixed package versions like: > > > >r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable > >r-bioc-biocsingular/1.12.0+ds-1 while 1.14.0+ds-2 is in unstable > >(I've just uploaded fixed r-bioc-bluster - lets see what will be picked) > >r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable > > It's not debci that picks them, but rather britney (our migration software) > that doesn't know from the information it uses that r-bioc-biocgenerics from > unstable makes r-bioc-biocfilecache from testing uninstallable. I haven't > checked but I suspect that this transition is declared via Provides and this > *might* mean that britney doesn't handle Provides ideally for this use case. > > > I wonder when debci will be run with the latest versions in unstable > > that are fixing the build issues. > > *Probably* when bugs in britney regarding this use of Provides are fixed. > For now, I'll schedule some tests manually with the Release Team > credentials. So you want to say, the fact that the current debci results that are listed on the r-bioc-biocgenerics page are based on packages that are replaced in unstable and the current packages that are fixed are not listed with recent debci results, is due to a bug in britney? Thanks for the manual triggers, hope this will help here Andreas. -- http://fam-tille.de
Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)
Hi Andreas, On 28-11-2022 13:22, Andreas Tille wrote: I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to follow the transition status. I realised that debci picks old, not yet fixed package versions like: r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable r-bioc-biocsingular/1.12.0+ds-1 while 1.14.0+ds-2 is in unstable (I've just uploaded fixed r-bioc-bluster - lets see what will be picked) r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable It's not debci that picks them, but rather britney (our migration software) that doesn't know from the information it uses that r-bioc-biocgenerics from unstable makes r-bioc-biocfilecache from testing uninstallable. I haven't checked but I suspect that this transition is declared via Provides and this *might* mean that britney doesn't handle Provides ideally for this use case. I wonder when debci will be run with the latest versions in unstable that are fixing the build issues. *Probably* when bugs in britney regarding this use of Provides are fixed. For now, I'll schedule some tests manually with the Release Team credentials. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)
Hi, I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to follow the transition status. I realised that debci picks old, not yet fixed package versions like: r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable r-bioc-biocsingular/1.12.0+ds-1 while 1.14.0+ds-2 is in unstable (I've just uploaded fixed r-bioc-bluster - lets see what will be picked) r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable I wonder when debci will be run with the latest versions in unstable that are fixing the build issues. Kind regards Andreas. PS: First round of new predependencies was done. I've fixed the remaining reasons for rejects. [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
Am Thu, Nov 24, 2022 at 08:46:31AM +0100 schrieb Sebastian Ramacher: > > >r-bioc-bitseq - should be removed from testing immediately bug just > > > filed) Bug #1024661 > > >r-bioc-multiassayexperiment #1024748 > > >r-bioc-demixt (bug #1024597 was just filed) > > >r-bioc-scater #1024751 > > >r-bioc-mofa (just due dependencies) Bug filed as well even if redundant since removal of r-bioc-multiassayexperiment should also remove this. > > > Do you want me to file RC bugs against r-bioc-multiassayexperiment, > > > r-bioc-scater and r-bioc-mofa. > > > > Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and > > r-bioc-singler[2] probably also these two packages need a RC bug to not > > block the transition. Bugs will be filed against r-bioc-bluster and r-bioc-singler once my 'only 5 reports per hour for submission' period is over (I'm frequently wondering whether this is a bit harsh constraint - I'm beaten by it two to four times per year by it) > > The test suite issue of r-bioc-structuralvariantannotation is discussed > > with upstream[4]. I'm fine to remove it from testing for the moment as > > well. > > > > Just let me know whether I should file the according bugs. > > Please do. Done (or about to do) - transition bug in CC. Thanks a lot for your patience Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-24 07:52:37 +0100, Andreas Tille wrote: > Am Tue, Nov 22, 2022 at 08:54:13PM +0100 schrieb Andreas Tille: > > If I understood that BioConductor packages should not block other > > transitions. I've just pinged ftpmaster on IRC to check packages > > r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. > > The following packages are blocked by the packages in new: > > > >r-bioc-bitseq - should be removed from testing immediately bug just > > filed) > >r-bioc-multiassayexperiment > >r-bioc-demixt (bug #1024597 was just filed) > >r-bioc-scater > >r-bioc-mofa (just due dependencies) > > > > Do you want me to file RC bugs against r-bioc-multiassayexperiment, > > r-bioc-scater and r-bioc-mofa. > > Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and > r-bioc-singler[2] probably also these two packages need a RC bug to not > block the transition. > > The test suite issue of r-bioc-structuralvariantannotation is discussed > with upstream[4]. I'm fine to remove it from testing for the moment as > well. > > Just let me know whether I should file the according bugs. Please do. Cheers -- Sebastian Ramacher
Bug#1023731: BioC Transition blocked by new dependencies
Am Tue, Nov 22, 2022 at 08:54:13PM +0100 schrieb Andreas Tille: > If I understood that BioConductor packages should not block other > transitions. I've just pinged ftpmaster on IRC to check packages > r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. > The following packages are blocked by the packages in new: > >r-bioc-bitseq - should be removed from testing immediately bug just filed) >r-bioc-multiassayexperiment >r-bioc-demixt (bug #1024597 was just filed) >r-bioc-scater >r-bioc-mofa (just due dependencies) > > Do you want me to file RC bugs against r-bioc-multiassayexperiment, > r-bioc-scater and r-bioc-mofa. Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and r-bioc-singler[2] probably also these two packages need a RC bug to not block the transition. The test suite issue of r-bioc-structuralvariantannotation is discussed with upstream[4]. I'm fine to remove it from testing for the moment as well. Just let me know whether I should file the according bugs. Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-bluster/28612583/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-singler/28612594/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-structuralvariantannotation/28615556/log.gz [4] https://lists.debian.org/debian-r/2022/11/msg00067.html -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
Control: block -1 by 1024582 Am Mon, Nov 21, 2022 at 07:16:14PM +0100 schrieb Sebastian Ramacher: > > However, to make us understand your suggestion better: Is there any > > drawback on your side if the transition of a closed set of packages if > > the transition is delayed by new processing? > > Some packages are also involved in other transitions. For example, > currently a hdf5 transition is prepared in experimental. While we could > now also start the hdf5 transition, completing hdf5 would not be > possible until this one is done. Thanks a lot for making me understand the problem. > Now replace the hdf5 transition with another lock-step transition such > as this one. Then we suddenly have two set of packages that can only > migrate together. Especially for lock-step transition a quick turn > around is thus greatly appreciated. If I understood that BioConductor packages should not block other transitions. I've just pinged ftpmaster on IRC to check packages r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. The following packages are blocked by the packages in new: r-bioc-bitseq - should be removed from testing immediately bug just filed) r-bioc-multiassayexperiment r-bioc-demixt (bug #1024597 was just filed) r-bioc-scater r-bioc-mofa (just due dependencies) Do you want me to file RC bugs against r-bioc-multiassayexperiment, r-bioc-scater and r-bioc-mofa. > I will remember for the next time that I'll ask you to stage everything > in experimental or to give me a list of packages that require NEW > dependencies so that we can get those removed early in the transition to > not hold of the transition by NEW delay. I agree that the BioC transition should not habe a negative effect on other transitions. If RC bugs against the blockers are a valid solution to prevent this I'd fully support this. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
Hi Nilesh, Le lun. 21 nov. 2022 à 18:29, Nilesh Patra a écrit : > > Lastly I also want to higlight that: while bioc transition is in theory a > transition (I agree) > but to my understanding, there is no _real_ API change. It is just the tool > taking the > API field from DESCRIPTION file into consideration, and causing FTBFS if it > does not match. > > In principle, building a package that has an older API value in DESCRIPTION > file with the newer > one does not break anything, it rather looks as updates of various packages > disguised as an API > change, and at least in debian land, to me it just appears as a broken tool > config and not a real > transition (like library transition, for example the recent onetbb one). > Before having this r-api-bioc virtual package, transitions were even worse. We had a lot of autopkgtest issues only because a mix of r-bioc pkgs installed from the old and from the new bioconductor releases. Issues which solved by themselves when the transition is over and of course, users were complaining about broken packages during the transition. We were losing a lot of time to investigate these issues. With this r-api-bioc mechanism, we don't allow this mixture of r-bioc pkgs and thus we limit these temporary issues. Adding this r-api-bioc virtual package has another consequence, now we can take advantage of the transition tracker and upload packages following levels. Before the order of the uploads were a bit random and again we lose of lot of time to figure out in which order we have to update them. Best, Dylan
Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-21 16:39:26 +0100, Andreas Tille wrote: > Hi Sebastian, > > Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: > > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > > > Control: block -1 by 1024563 > > > Control: block -1 by 1024565 > > > Control: block -1 by 1024567 > > > > > > Some of the BioConductor packages need new dependencies. > > > I have pushed these to new queue and set the ITP bugs as > > > blocker. > > > > As this is happening every r-bioc transition, could this be handled > > before starting the transition the next time? > > This is really hard to do, thought. The new packages are needing those > packages from the transition. I actually injected two packages from > higher levels manually to be able to build one of the new packages. So > we really need to upload the start of the transition and I do not see > any sense in not documenting what we are doing without the transition > tracker. Others have already answered this part. > However, to make us understand your suggestion better: Is there any > drawback on your side if the transition of a closed set of packages if > the transition is delayed by new processing? Some packages are also involved in other transitions. For example, currently a hdf5 transition is prepared in experimental. While we could now also start the hdf5 transition, completing hdf5 would not be possible until this one is done. Now replace the hdf5 transition with another lock-step transition such as this one. Then we suddenly have two set of packages that can only migrate together. Especially for lock-step transition a quick turn around is thus greatly appreciated. I will remember for the next time that I'll ask you to stage everything in experimental or to give me a list of packages that require NEW dependencies so that we can get those removed early in the transition to not hold of the transition by NEW delay. Cheers -- Sebastian Ramacher
Bug#1023731: BioC Transition blocked by new dependencies
On Mon, Nov 21, 2022 at 06:11:41PM +0100, Andreas Tille wrote: > Hi Adrian and others, > > Am Mon, Nov 21, 2022 at 06:33:52PM +0200 schrieb Adrian Bunk: > > > This is really hard to do, thought. The new packages are needing those > > > packages from the transition. I actually injected two packages from > > > higher levels manually to be able to build one of the new packages. So > > > we really need to upload the start of the transition and I do not see > > > any sense in not documenting what we are doing without the transition > > > tracker. > > >... > > > > Your transition is special because you are manually uploading every > > single package involved in the transition. > > > > You could upload everything to experimental, run a local ben tracker > > against experimental, and when the transition is complete in > > experimental contact the release team for the transition in unstable. > > > > The actual transition is then a batch of "Upload to unstable". > > Thanks for all helpful hints. I understand that with some effort over > the current workflow it is possible to do the transition differently. > The only thing which I did not yet understood is the actual drawback of > the current workflow. I do not think that it takes specifically longer > than other transition - we just have a different set of showstoppers to > get it done in 24 hours. Personal experience+opinion: I have been involved with quite a few bioc transitions and often times you and me were the _only_ people who did the entire transition. I have noticed several times that the NEW processing takes quite sometime, and the way forward (for me) has been to manually patch the DESCRIPTION file to patch it to be compatible with new r-bioc api until the dependency from new is accepted. The new processing time tends to create delay with respect to bioc packages migrating to testing and this creats a terrible amount of noise. And then what comes next is a bunch of workarounds to get things moving, and this takes a quite a lot of energy at my end which I'd like to spend somewhere else. I have not been entirely happy with the way it happens, and would like if we can do the transition differently with less friction, less days of wide-uninstallability. The advantage with a reprepo thing that Sebastian suggests is that everything (possibly) will migrate as soon as it is uploaded. Once you have stored the sources into a reprepo, all you need to do is run a script to do all the uploads. > In the past we got support by ftpmaster when > pinging them and explaining the transition issue. Which takes time as well, and at least my experience regarding transition new processing has not been quite same as you. Lastly I also want to higlight that: while bioc transition is in theory a transition (I agree) but to my understanding, there is no _real_ API change. It is just the tool taking the API field from DESCRIPTION file into consideration, and causing FTBFS if it does not match. In principle, building a package that has an older API value in DESCRIPTION file with the newer one does not break anything, it rather looks as updates of various packages disguised as an API change, and at least in debian land, to me it just appears as a broken tool config and not a real transition (like library transition, for example the recent onetbb one). -- Best, Nilesh signature.asc Description: PGP signature
Bug#1023731: BioC Transition blocked by new dependencies
Hi Adrian and others, Am Mon, Nov 21, 2022 at 06:33:52PM +0200 schrieb Adrian Bunk: > > This is really hard to do, thought. The new packages are needing those > > packages from the transition. I actually injected two packages from > > higher levels manually to be able to build one of the new packages. So > > we really need to upload the start of the transition and I do not see > > any sense in not documenting what we are doing without the transition > > tracker. > >... > > Your transition is special because you are manually uploading every > single package involved in the transition. > > You could upload everything to experimental, run a local ben tracker > against experimental, and when the transition is complete in > experimental contact the release team for the transition in unstable. > > The actual transition is then a batch of "Upload to unstable". Thanks for all helpful hints. I understand that with some effort over the current workflow it is possible to do the transition differently. The only thing which I did not yet understood is the actual drawback of the current workflow. I do not think that it takes specifically longer than other transition - we just have a different set of showstoppers to get it done in 24 hours. In the past we got support by ftpmaster when pinging them and explaining the transition issue. If I'm missing the point here I'm perfectly fine to enhance the procedure - I just fail to see the actual problem we want to solve by the suggested methods. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
On Mon, Nov 21, 2022 at 04:39:26PM +0100, Andreas Tille wrote: >... > Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: > > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > > > Control: block -1 by 1024563 > > > Control: block -1 by 1024565 > > > Control: block -1 by 1024567 > > > > > > Some of the BioConductor packages need new dependencies. > > > I have pushed these to new queue and set the ITP bugs as > > > blocker. > > > > As this is happening every r-bioc transition, could this be handled > > before starting the transition the next time? > > This is really hard to do, thought. The new packages are needing those > packages from the transition. I actually injected two packages from > higher levels manually to be able to build one of the new packages. So > we really need to upload the start of the transition and I do not see > any sense in not documenting what we are doing without the transition > tracker. >... Your transition is special because you are manually uploading every single package involved in the transition. You could upload everything to experimental, run a local ben tracker against experimental, and when the transition is complete in experimental contact the release team for the transition in unstable. The actual transition is then a batch of "Upload to unstable". > Kind regards > Andreas. cu Adrian Example for the status of the ongoing python3.11-add transition in experimental: $ cat tracker/python3.11-add.ben title = "Add Python 3.11 as supported version"; is_affected = .build-depends ~ /python3-all-dev|python3-all-dbg/ | .build-depends-arch ~ /python3-all-dev|python3-all-dbg/; is_good = .depends ~ /python3 \(<< 3\.12\)|python3.11|python3-dbg \(<< 3\.12\)|python3.11-dbg/; is_bad = .depends ~ /python3 \(<< 3\.11\)|python3-dbg \(<< 3\.11\)/ | .breaks ~ /python \(>= 3\.11\)|python-dbg \(>= 3\.11\)/; notes = "#1021984"; $ ben download --suite experimental --preferred-compression-format xz Downloading /home/bunk/Sources... Downloading /home/bunk/Packages_armhf... Downloading /home/bunk/Packages_amd64... Downloading /home/bunk/Packages_mips64el... Downloading /home/bunk/Packages_armel... Downloading /home/bunk/Packages_i386... Downloading /home/bunk/Packages_arm64... Downloading /home/bunk/Packages_mipsel... Downloading /home/bunk/Packages_ppc64el... Downloading /home/bunk/Packages_s390x... $ ben tracker -cd tracker Parsing /home/bunk/Sources... Parsing /home/bunk/Packages_amd64... Parsing /home/bunk/Packages_arm64... Parsing /home/bunk/Packages_armel... Parsing /home/bunk/Packages_armhf... Parsing /home/bunk/Packages_i386... Parsing /home/bunk/Packages_mips64el... Parsing /home/bunk/Packages_mipsel... Parsing /home/bunk/Packages_ppc64el... Parsing /home/bunk/Packages_s390x... Computing data for (unknown) python3.11-add Generating html/python3.11-add.html Generating ./export/packages.yaml Cleaning up... Generating index... $ cp -a /usr/share/ben/media html/ $ html/python3.11-add.html can then be viewed with any web broswer (or html/ copied to a public webserver like people.d.o). Different from the release team tracker, "ben download" above will get updated data only every 6 hours after dinstall.
Bug#1023731: BioC Transition blocked by new dependencies
On 11/21/22 17:21, Andreas Tille wrote: Am Mon, Nov 21, 2022 at 04:49:43PM +0100 schrieb Sebastiaan Couwenberg: This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. You can rebuild the packages that are already in the archive and include them in a local repo (e.g. managed with reprepro) and used by the chroot where the rebuilds are performed. Use that to prepare the NEW uploads to experimental, file the transition bugreport once all packages have passed NEW, and move those to unstable once the transition is ACKed. Well, probably everything is possible, but as I said the tracker comes pretty handy to know the dependency relation. I really would like to know what might be the real problem of the delay of the transition in this specific case. Making me understand this problem would increase the motivation to do something else than currently. To prepare for GIS transition sI run my own ben instance to generate the trackers (for testing, unstable, and experimental), it's relatively easy to setup. If you'd like help to setup a ben instance for the R team, let me know. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023731: BioC Transition blocked by new dependencies
Am Mon, Nov 21, 2022 at 04:49:43PM +0100 schrieb Sebastiaan Couwenberg: > > This is really hard to do, thought. The new packages are needing those > > packages from the transition. I actually injected two packages from > > higher levels manually to be able to build one of the new packages. So > > we really need to upload the start of the transition and I do not see > > any sense in not documenting what we are doing without the transition > > tracker. > > You can rebuild the packages that are already in the archive and include > them in a local repo (e.g. managed with reprepro) and used by the chroot > where the rebuilds are performed. Use that to prepare the NEW uploads to > experimental, file the transition bugreport once all packages have passed > NEW, and move those to unstable once the transition is ACKed. Well, probably everything is possible, but as I said the tracker comes pretty handy to know the dependency relation. I really would like to know what might be the real problem of the delay of the transition in this specific case. Making me understand this problem would increase the motivation to do something else than currently. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
On 11/21/22 16:39, Andreas Tille wrote: Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: Some of the BioConductor packages need new dependencies. I have pushed these to new queue and set the ITP bugs as blocker. As this is happening every r-bioc transition, could this be handled before starting the transition the next time? This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. You can rebuild the packages that are already in the archive and include them in a local repo (e.g. managed with reprepro) and used by the chroot where the rebuilds are performed. Use that to prepare the NEW uploads to experimental, file the transition bugreport once all packages have passed NEW, and move those to unstable once the transition is ACKed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023731: BioC Transition blocked by new dependencies
On 21 November 2022 at 16:39, Andreas Tille wrote: | Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: | > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: | > > Some of the BioConductor packages need new dependencies. | > > I have pushed these to new queue and set the ITP bugs as | > > blocker. | > | > As this is happening every r-bioc transition, could this be handled | > before starting the transition the next time? It could, resources and volunteers willing. BioConductor leads the upcoming release as 'devel' just like we do. There is no reason to wait apart from having to set up new processes. I now also look behind a complete r-cran-* set of 20k packages for the two Ubuntu LTS flavors (it's a longer story but it reuses RSPM / PPM packages from RStudio / posit). For that effort, I just rebuilt the 240 BioConductors pulled in from the CRAN package graph for both LTS variants. I got all that done in a few hours on Saturday (after mulling over the problem and working out a script to determine build order by number of r-bioc-* depends). "Formal packaging" in Debian proper is more work, but there is no reason not to run a test build in a container, or even upload to 'experiemental' a few weeks prior to the (well telegraphed) BioConductor release. If someone wants to run with this (and knows a little R) I would be happy to discuss my 'build order' setup script (bare and hackish at it is). Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1023731: BioC Transition blocked by new dependencies
Hi Sebastian, Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > > Control: block -1 by 1024563 > > Control: block -1 by 1024565 > > Control: block -1 by 1024567 > > > > Some of the BioConductor packages need new dependencies. > > I have pushed these to new queue and set the ITP bugs as > > blocker. > > As this is happening every r-bioc transition, could this be handled > before starting the transition the next time? This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. However, to make us understand your suggestion better: Is there any drawback on your side if the transition of a closed set of packages if the transition is delayed by new processing? Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > Control: block -1 by 1024563 > Control: block -1 by 1024565 > Control: block -1 by 1024567 > > Some of the BioConductor packages need new dependencies. > I have pushed these to new queue and set the ITP bugs as > blocker. As this is happening every r-bioc transition, could this be handled before starting the transition the next time? Cheers -- Sebastian Ramacher
Bug#1023731: BioC Transition blocked by new dependencies
Control: block -1 by 1024563 Control: block -1 by 1024565 Control: block -1 by 1024567 Some of the BioConductor packages need new dependencies. I have pushed these to new queue and set the ITP bugs as blocker. Kind regards Andreas. -- http://fam-tille.de
