Bug#1006836: transition: python3.10 as default

[Matthias Klose]

Package: release.debian.org
Severity: normal
User: release.d...@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian...@lists.debian.org

Please setup a transition window for python 3.10 as the default python3 version.
A tracker is setup at

https://release.debian.org/transitions/html/python3.10-default.html

Thanks to many Debian and Ubuntu developers, this transition is now finished for
Ubuntu, and outstanding bug reports should be filed as
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.10;users=debian...@lists.debian.org

We had to remove at least numba from testing/release, as it requires updated
dependencies as well, which are not yet in unstable.

[Graham Inggs]

Control: tags -1 confirmed

On Sun, 6 Mar 2022 at 15:03, Matthias Klose <do...@debian.org> wrote:
> Please setup a transition window for python 3.10 as the default python3 version.
> A tracker is setup at
>
> https://release.debian.org/transitions/html/python3.10-default.html
>
> Thanks to many Debian and Ubuntu developers, this transition is now finished for
> Ubuntu, and outstanding bug reports should be filed as
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.10;users=debian...@lists.debian.org
>
> We had to remove at least numba from testing/release, as it requires updated
> dependencies as well, which are not yet in unstable.

We've removed numba in Debian as well now.

Please go ahead.

[Markus Blatt]

Hi,

I just took a look at the tracker and noticed that opm-common is level 3 and
opm-simulators is level 2. If build attempts for level 3 come after level 2
that migth explain the failure in the logs [1] and opm-common should be in a
level before opm-simulators.

If there is anything that I need to do on my side as a maintainer then please let me know.

Cheers,

Markus

[1] https://buildd.debian.org/status/fetch.php?pkg=opm-simulators&arch=amd64&ver=2021.10-4%2Bb1&stamp=1648476056&raw=0

[Graham Inggs]

Hi Markus

On Mon, 28 Mar 2022 at 17:30, Markus Blatt <mar...@dr-blatt.de> wrote:
> I just took a look at the tracker and noticed that opm-common is level 3 and
> opm-simulators is level 2. If build attempts for level 3 come after level 2
> that migth explain the failure in the logs [1] and opm-common should be in a
> level before opm-simulators.

If opm-common should be in a level before opm-simulators, then I think
opm-simulators needs a Build-Depends on one of opm-common's binary
packages. This should help Ben figure out the dependency levels for
future transitions.

> If there is anything that I need to do on my side as a maintainer then please let me know.

I don't think anything is needed right now, thanks. I will schedule a
rebuild of opm-common once graphviz has built, and then retry
opm-simulators.

Regards
Graham

[Graham Inggs]

Hi Markus

On Mon, 28 Mar 2022 at 20:01, Graham Inggs <gin...@debian.org> wrote:
> I don't think anything is needed right now, thanks. I will schedule a
> rebuild of opm-common once graphviz has built, and then retry
> opm-simulators.

It seems opm-simulators FTBFS in much the same way now after
opm-common has been rebuilt.

Regards
Graham

[Markus Blatt]

Hi,

Am Tue, Mar 29, 2022 at 09:28:22PM +0200 schrieb Graham Inggs:
>It seems opm-simulators FTBFS in much the same way now after
>opm-common has been rebuilt.
>

I will take a look and try to fix it. It seems there is a reference to libpython3.9.so.

Markus

[Markus Blatt]

Hi,

I think I figured out what the issue is. The cmake configuration files of all opm modules
have an explicit list of libraries that need to be linked with the library of the module and
this is always used for linking. This list is only updated if the module/package is rebuilt.
All modules built before the transition have a reference to
/usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake configuration file of opm-common
when they where built. The only way to get rid of them seems to be rebuilding all. Hence one
would need to change the dependencies along the following lines

dependency level 3: opm-grid, opm-material,
dependency level 4: opm-models, opm-uscaling
dependency level 5: opm-simulators (currently level 3)

Note that opm-upscaling is only needed because: if a user searches for it in its project,
then compilation will fail in the same manner as opm-simulators is failing currently.

Explanation why it is the way it is:
It is the way OPM uses CMake, these scripts date back to an old Cmake version (without support
for targets). At that time this approach was (or seemed to be) needed for static libraries. Otherwise
there would have been linker errors, because we use embedded python in opm-common. Updating to modern
CMake targets would have prevented this issue.

Sorry for the trouble and HTH.

Cheers,

Markus

[Markus Blatt]

Hi,

Am Wed, Mar 30, 2022 at 12:22:29PM +0200 schrieb Markus Blatt:
>I think I figured out what the issue is. The cmake configuration files of all opm modules
>have an explicit list of libraries that need to be linked with the library of the module and
>this is always used for linking. This list is only updated if the module/package is rebuilt.
>All modules built before the transition have a reference to
>/usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake
>configuration file of opm-common
>when they where built. The only way to get rid of them seems to be rebuilding all. Hence one
>would need to change the dependencies along the following lines
>
>dependency level 3: opm-grid, opm-material, dependency level 4:
>opm-models, opm-uscaling
>dependency level 5: opm-simulators (currently level 3)
>

As there were some packaging improvements lying aroud anyway, I pushed new
releases for opm-grid, opm-material, opm-models, opm-upscaling. They did
build fine and are now installed in sid. I think this should fix the problem
for opm-simulators, once you trigger a rebuild. (At least it work in the salsa-ci).

HTH,

Markus