On 01/11/2024 11:15, Johannes Schauer Marin Rodrigues wrote:
Hi Emilio,

Quoting Emilio Pozuelo Monfort (2024-11-01 10:12:30)
I scheduled the binNMUs. Unfortunately there's many packages that
build-depend on versioned imagemagick 6 -dev packages and so the resulting
binNMUs still build against the old imagemagick 6. This worries me as many of
this will likely FTBFS against imagemagick 7 and so the transition is
probably in a worse state than I thought.

this is indeed an oversight of the salsa build script. I'm working on a patch
which, instead of just running "apt-get source --build", first downloads and
unpacks the source and then modifies d/control with sed to upgrade the -dev
dependencies. That will then catch these issues... Sorry for the oversight.

Great, thanks.

Note that even if you change it to build against imagemagick 7, we still need RC bugs because packages need sourceful changes (whether just changing the build-dep, or that plus source code changes).

See php-imagick, pfstools, odr-padenc, kxstitch, gnustep-gui, drawtiming,
wmaker, photoqt

Please file bugs for those.

You are using this overview to find the FTBFS?

https://release.debian.org/transitions/html/auto-imagemagick.html

Yes.

I have trouble finding the build logs for some. For example, this comes out
empty:

https://buildd.debian.org/status/package.php?p=pfstools&suite=experimental

Why are you looking at suite=experimental ?

Also virtuoso-opensource is losing imagemagick support:

checking ImageMagick library usability... bad. Check config.log for details
configure: WARNING: The ImageMagick plugin will not be built

This also needs a bug.

The transition tracker lists virtuoso-opensource as "red". How do you find this
issue? I see the potential problem that a build might silently skip imagemagick
support but then build successfully with less features...

It's only red because in some architectures the package hasn't been rebuilt yet, and so it still depends on imagemagick 6 on those, making it "bad". Thus, the whole package is marked as bad. However, if you look closely, it's marked as "unknown" in various architectures. That's because it's neither good or bad, i.e. it doesn't match any of the .is_bad or .is_good regexes. If you inspect the build log, you'll find the configure error I posted above, which is causing imagemagick support (whatever that does) to not be built.

The way to caught all this would have been to check the resulting binaries of
the test rebuilds for /magick.*7/ dependencies.

Sorry, this was indeed an oversight. Thank you for catching it!

Cool, let's hope to get the transition back into track.

Cheers,
Emilio

Reply via email to