Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Sat, 21 Jan 2023 at 19:59, Graham Inggs wrote: > I noticed there was an upload of opm-common 2022.10+ds-3, but it also > FTBFS on armhf. I trust this is on your radar. It turns opm-common was blocked by python3-defaults and python3-defaults was blocked by opm-common's FTBFS on armhf. To break out of the Catch-22, I temporarily removed opm-* from testing and dune-* migrated together. opm-* will be able to migrate once the armhf build is fixed, or opm-common stops building for that architecture. Regards Graham
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Wed, 18 Jan 2023 at 20:48, Graham Inggs wrote: > Almost there, the excuses [1] for dune-common shows: > > Migration status: Blocked. Can't migrate due to a non-migratable > dependency. Check status below. > Blocked by: opm-simulators/ppc64el > >I don't think any action is required, just some waiting. My apologies, I knew the ppc64el buildd infrastructure was a bit behind, so didn't look at this closely. Upon further investigation, I found that the dune-common transition is entangled with the Python 3.11 transition through opm-simulators. We will either wait for Python 3.11, or find a way to disentangle them. > By the way, excuses [2] for opm-common shows: > > Issues preventing migration: > missing build on armhf I noticed there was an upload of opm-common 2022.10+ds-3, but it also FTBFS on armhf. I trust this is on your radar. Regards Graham
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Wed, 18 Jan 2023 at 09:59, Markus Blatt wrote: > Thanks a lot Graham. That really worked like a charm and seem to finished. > Cool.These processes > and the tools in Debian are really great. Almost there, the excuses [1] for dune-common shows: Migration status: Blocked. Can't migrate due to a non-migratable dependency. Check status below. Blocked by: opm-simulators/ppc64el I don't think any action is required, just some waiting. > Next time I will try to do that myself to avoid confusion. > Is the upload to NEW for dune-common optional as the package name stays the > same? That's correct. By the way, excuses [2] for opm-common shows: Issues preventing migration: missing build on armhf Regards Graham [1] https://tracker.debian.org/pkg/dune-common [2] https://tracker.debian.org/pkg/opm-common
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Dear Graham, Am Sun, Jan 15, 2023 at 04:25:04PM +0200 schrieb Graham Inggs: Hi Markus On Tue, 3 Jan 2023 at 02:46, Markus Blatt wrote: Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and opm-upscaling will need to be rebuild for the mini-transition. Otherwise they won't work correctly I found out about this transition after an Ubuntu developer asked me to schedule binNMUs for some opm-* packages. In future, you can follow steps described [1] and file a transition bug against release.debian.org. For now, I have scheduled binNMUs for opm-grid, opm-material, opm-models, opm-simulators, and opm-upscaling. I've also set up a transition tracker [2], with the following ben file: [2] https://release.debian.org/transitions/html/dune-common-2.9.0.html Thanks a lot Graham. That really worked like a charm and seem to finished. Cool.These processes and the tools in Debian are really great. Next time I will try to do that myself to avoid confusion. Is the upload to NEW for dune-common optional as the package name stays the same? Cheers, Markus -- Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de Pedettistr. 38, 85072 Eichstätt, Germany, USt-Id: DE279960836 Tel.: +49 (0) 160 97590858
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Tue, 3 Jan 2023 at 02:46, Markus Blatt wrote: > Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and > opm-upscaling will > need to be rebuild for the mini-transition. Otherwise they won't work > correctly > > If it is possible to give me upload rights for the DUNE packages, then I > could do the > upload/transition work myself, too. But I would still require some guidance > (next steps, etc.) > and don't want to step on other people's toes. I found out about this transition after an Ubuntu developer asked me to schedule binNMUs for some opm-* packages. In future, you can follow steps described [1] and file a transition bug against release.debian.org. For now, I have scheduled binNMUs for opm-grid, opm-material, opm-models, opm-simulators, and opm-upscaling. I've also set up a transition tracker [2], with the following ben file: title = "dune-common-2.9.0"; is_affected = .depends ~ /libdune-common-2/; is_good = .depends ~ /libdune-common-2\.9/; is_bad = .depends ~ /libdune-common-2\.8/; notes = "https://lists.debian.org/debian-science/2023/01/msg1.html;; export = false; Please let us know if anything else is needed. Regards Graham [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions [2] https://release.debian.org/transitions/html/dune-common-2.9.0.html
Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi, happy new year to everyone. There has been a new upstream version of DUNE for some time. As Ansgar is burried in work, I have prepared changes and merge requests for the Debian packages tob bring DUNE 2.9.0 into Debian. Those changes are based on the upstream tag v2.9.0 of each upstream repository (use dune-common/debian/get-orig-source dune-module 2.9.0 v2.9.0" to create the tarballs). As I am just a DM with no upload rights for DUNE I cannot do more at the moment. Hope somebody else take over the upload (to experimental?). Maybe Ansgar or somebody can find some time? I have tested these changed in experimental (from Christmas) together with the OPM packages that depend on DUNE and that I maintain. This worked. For current experimental there seems to be an issue for dune-grid because the dependency on python3 (via python3-vtk9) is not resolvable due to an ongoing transition (Make python-3.11 the default). Note that because OPM depends on DUNE this seems to be a Mini-transition. Unfortunately, I have no experience with this. You can find the merge request for DUNE at: - dune-common: https://salsa.debian.org/science-team/dune-common/-/merge_requests/4 - dune-geometry: https://salsa.debian.org/science-team/dune-geometry/-/merge_requests/5 - dune-grid: https://salsa.debian.org/science-team/dune-grid/-/merge_requests/3 - dune-istl: https://salsa.debian.org/science-team/dune-istl/-/merge_requests/3 - dune-tyeptree: https://salsa.debian.org/science-team/dune-typetree/-/merge_requests/4 - dune-localfunctions: https://salsa.debian.org/science-team/dune-localfunctions/-/merge_requests/4 - dune-functions: https://salsa.debian.org/science-team/dune-functions/-/merge_requests/3 - dune-grid-glue: https://salsa.debian.org/science-team/dune-grid-glue/-/merge_requests/2 The changes needed for OPM to work with the new version were not to many. Only one package needed changes in the packaging: - opm-common: https://salsa.debian.org/science-team/opm-common/-/merge_requests/2 Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and opm-upscaling will need to be rebuild for the mini-transition. Otherwise they won't work correctly If it is possible to give me upload rights for the DUNE packages, then I could do the upload/transition work myself, too. But I would still require some guidance (next steps, etc.) and don't want to step on other people's toes. Thanks a lot for the help. Cheers, Markus
