#1142298 transition: imath

#1142298#5
Date:
2026-07-17 12:42:00 UTC
From:
To:
Hi,

I would like to request a transition slot for IMath, which had
a SOVERSION bump from libimath-3-1-29t64 to libimath-3-2-30.

The auto-generated transition overview [0] looks almost correct.
opencv is not mentioned in the transition tracker, however I did need to
rebuild it for gmic and openimageio to build correctly.

This is expected to be a simple transition, it seems that the reason it needs to
transition is [1]:

There are a lot of reverse-build-depends:

*   alembic-graphics rebuilds cleanly
*   openexr rebuilds cleanly
*   pink-pony rebuilds cleanly
*   calligra rebuilds cleanly
*   exactimage rebuilds cleanly
*   field3d rebuilds cleanly
*   opencv rebuilds cleanly
*   freeimage rebuilds cleanly
*   gmic rebuilds cleanly
*   gst-plugins-bad1.0 rebuilds cleanly
*   kf6-kimage-format rebuilds cleanly
*   krita rebuilds cleanly
*   libvigraimpex rebuilds cleanly
*   openvdb rebuilds cleanly
*   povray rebuilds cleanly
*   swayimg rebuilds cleanly
*   synfig rebuilds cleanly
*   darktable rebuilds cleanly
*   hugin rebuilds cleanly
*   opencolorio rebuilds cleanly
*   openimageio rebuilds cleanly
*   slic3r-prusa rebuilds cleanly
*   blender rebuilds cleanly

openimageio depends on opencolorio and opencolorio depends on openimageio.
So to test the build correctly I had to build one, then the other, then
the first one again.

Thanks!

Antoine

[0] https://release.debian.org/transitions/html/auto-imath.html
[1] https://github.com/AcademySoftwareFoundation/Imath/releases#release-v3.2.0

Ben file:

title = "imath";
is_affected = .depends ~ "libimath-3-1-29t64" | .depends ~ "libimath-3-2-30";
is_good = .depends ~ "libimath-3-2-30";
is_bad = .depends ~ "libimath-3-1-29t64";

#1142298#12
Date:
2026-08-03 14:04:58 UTC
From:
To:
Control: tags -1 confirmed

cimg probably needs a bug for its autopkgtest regression, can you take a look?
https://qa.debian.org/excuses.php?experimental=1&package=imath

Anyway let's go ahead.

Cheers,
Emilio

#1142298#21
Date:
2026-08-18 23:05:24 UTC
From:
To:
example breakage in other packages:

$ gimp
GEGL-Message: 23:03:00.011: Module '/usr/lib/i386-linux-gnu/gegl-0.4/exr-save.so' load error: /usr/lib/i386-linux-gnu/gegl-0.4/exr-save.so: undefined symbol: _ZN7Imf_3_414ChromaticitiesC1ERKN9Imath_3_14Vec2IfEES5_S5_S5_
GEGL-Message: 23:03:00.018: Module '/usr/lib/i386-linux-gnu/gegl-0.4/exr-load.so' load error: /usr/lib/i386-linux-gnu/gegl-0.4/exr-load.so: undefined symbol: _ZN7Imf_3_414ChromaticitiesC1ERKN9Imath_3_14Vec2IfEES5_S5_S5_
...
$ djxl
djxl: symbol lookup error: djxl: undefined symbol: _ZN7Imf_3_414ChromaticitiesC1ERKN9Imath_3_14Vec2IfEES5_S5_S5_
$

cu
Adrian

#1142298#26
Date:
2026-08-20 19:38:02 UTC
From:
To:
Tracker for the imath transition including openexr:
https://salsa.debian.org/release-team/transition-data/-/merge_requests/70
(yellow will need another binNMU with the updated openexr)

cu
Adrian

#1142298#31
Date:
2026-08-22 15:07:26 UTC
From:
To:
The tracker is yellow instead of green for fixed libopenexr-using
packages,[1] this is corrected with:
https://salsa.debian.org/release-team/transition-data/-/merge_requests/71

cu
Adrian

[1] on amd64 there was no build of the previous openexr due to #1144878,
    and some rdeps are now green there