Discussion:
Bug#973294: transition: scotch mumps petsc slepc
(too old to reply)
Drew Parsons
2020-10-28 12:40:02 UTC
Permalink
Package: release.debian.org
Severity: normal
User: ***@packages.debian.org
Usertags: transition

I had an oopsie uploading petsc4py 3.14.0-1 to unstable instead of
experimental, and it got accepted immediately from the NEW queue
before the message on IRC was read to reject it.

I'd therefore like to proceed with the transition of the scientific
numerical library stack to get the packages back into consistent
versions.

The source packages are:

scotch
mumps
petsc (and petsc4py)
slepc (and slepc4py)


The auto transitions are

https://release.debian.org/transitions/html/auto-scotch.html
https://release.debian.org/transitions/html/auto-mumps.html
https://release.debian.org/transitions/html/auto-petsc.html
https://release.debian.org/transitions/html/auto-slepc.html


The mumps transition is not a "true" transition, it's just simplifying
the ABI version to the minor version 3.13 instead of 3.13.4. So future
mumps upgrades will be simpler.


Ben file:

title = "scotch mumps petsc slepc";
is_affected = .depends ~ "libpetsc-real3.13" | .depends ~ "libpetsc-real3.14";
is_good = .depends ~ "libpetsc-real3.14";
is_bad = .depends ~ "libpetsc-real3.13";


-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Sebastian Ramacher
2020-10-28 13:40:02 UTC
Permalink
Control: tags -1 + confirmed
Post by Drew Parsons
Package: release.debian.org
Severity: normal
Usertags: transition
I had an oopsie uploading petsc4py 3.14.0-1 to unstable instead of
experimental, and it got accepted immediately from the NEW queue
before the message on IRC was read to reject it.
I'd therefore like to proceed with the transition of the scientific
numerical library stack to get the packages back into consistent
versions.
scotch
mumps
petsc (and petsc4py)
slepc (and slepc4py)
The auto transitions are
https://release.debian.org/transitions/html/auto-scotch.html
https://release.debian.org/transitions/html/auto-mumps.html
https://release.debian.org/transitions/html/auto-petsc.html
https://release.debian.org/transitions/html/auto-slepc.html
The mumps transition is not a "true" transition, it's just simplifying
the ABI version to the minor version 3.13 instead of 3.13.4. So future
mumps upgrades will be simpler.
Except siconos which currently FTBFS anyway, there are no collisions
with other ongoing transitions. If you are going to take care of any
build failures, please go ahead.

Cheers
Post by Drew Parsons
title = "scotch mumps petsc slepc";
is_affected = .depends ~ "libpetsc-real3.13" | .depends ~ "libpetsc-real3.14";
is_good = .depends ~ "libpetsc-real3.14";
is_bad = .depends ~ "libpetsc-real3.13";
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
Sebastian Ramacher
Drew Parsons
2020-10-28 15:00:01 UTC
Permalink
Thanks Sebastian, proceeding.
Post by Sebastian Ramacher
Control: tags -1 + confirmed
Post by Drew Parsons
Package: release.debian.org
Severity: normal
Usertags: transition
I had an oopsie uploading petsc4py 3.14.0-1 to unstable instead of
experimental, and it got accepted immediately from the NEW queue
before the message on IRC was read to reject it.
I'd therefore like to proceed with the transition of the scientific
numerical library stack to get the packages back into consistent
versions.
...
Post by Sebastian Ramacher
Except siconos which currently FTBFS anyway, there are no collisions
with other ongoing transitions. If you are going to take care of any
build failures, please go ahead.
Drew Parsons
2020-11-09 18:00:01 UTC
Permalink
Post by Sebastian Ramacher
Control: tags -1 + confirmed
...
Post by Sebastian Ramacher
Post by Drew Parsons
I'd therefore like to proceed with the transition of the scientific
numerical library stack to get the packages back into consistent
versions.
scotch
mumps
petsc (and petsc4py)
slepc (and slepc4py)
...
Post by Sebastian Ramacher
Except siconos which currently FTBFS anyway, there are no collisions
with other ongoing transitions. If you are going to take care of any
build failures, please go ahead.
The upgraded libraries are now built.

Waiting for dolfin to rebuild on mips64el.

There seems to be some regression there: the mips64el error "error
adding symbols: bad value" was dealt with previously,
https://lists.debian.org/debian-mips/2020/09/msg00000.html

Workaround is in patch pybind11_lto_mips64el.patch
which instructs setup.py to add a -fno-lto flag for cmake to process
when building python extensions.

You can see it got applied in the last successful mips64el build,
https://buildd.debian.org/status/fetch.php?pkg=dolfin&arch=mips64el&ver=2019.2.0%7Egit20200629.946dbd3-3%2Bb1&stamp=1602966952&raw=0
but in the current rebuild is now missing.

python/cmake handling of HAS_FLTO and pybind11 has shifted. Need to
determine if the recent upgrade to pybind11 2.6 is involved.
Adrian Bunk
2020-11-09 19:40:02 UTC
Permalink
...
You can see it got applied in the last successful mips64el build, https://buildd.debian.org/status/fetch.php?pkg=dolfin&arch=mips64el&ver=2019.2.0%7Egit20200629.946dbd3-3%2Bb1&stamp=1602966952&raw=0
but in the current rebuild is now missing.
python/cmake handling of HAS_FLTO and pybind11 has shifted. Need to
determine if the recent upgrade to pybind11 2.6 is involved.
I have some ideas how this could be addressed,
if you give me a day to test whether any works.

cu
Adrian
Drew Parsons
2020-11-10 02:10:01 UTC
Permalink
Post by Adrian Bunk
Post by Drew Parsons
...
You can see it got applied in the last successful mips64el build,
https://buildd.debian.org/status/fetch.php?pkg=dolfin&arch=mips64el&ver=2019.2.0%7Egit20200629.946dbd3-3%2Bb1&stamp=1602966952&raw=0
but in the current rebuild is now missing.
python/cmake handling of HAS_FLTO and pybind11 has shifted. Need to
determine if the recent upgrade to pybind11 2.6 is involved.
I have some ideas how this could be addressed,
if you give me a day to test whether any works.
Thanks Adrian.

D.

Loading...