Bug#1060103: transition: imagemagick7

[Bastien Roucariès]

Package: release.debian.org
Severity: important
User: ***@packages.debian.org
Usertags: transition
X-Debbugs-CC: ***@debian.org

Imagemagick will need a new major bump

I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).

Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.
- upload to experimental a version with perl and without legacy name
- migrate perl and versioned package
- add to experimental libmakickgwand-dev libmagick++-dev libmagickcore-dev
- migrate package that depends on libmakickgwand-dev libmagick++-dev
libmagickcore-dev (every thing that build against imagemagick) to imagemagick7
- add to experimental imagemagick package
- migrate imagemagick package to unstable

What do you think of this plan ? From a security point of view it is better to
go to imagemagick7 (so important severity)

I expect breakage only on the last step. See
https://imagemagick.org/script/porting.php

ftpmaster it need more work because it will need three manual step.

Bastien

* perlmagick, libmagickcore-dev, libmakickgwand-dev libmagick++-dev,
imagemagick, libimage-magick-perl libimage-magick-q16-perl libimage-
magick-q16hdri-perl

[Bastien Roucariès]

Hi,

A gentle remainder about imagemagick7 transition plan.

Many thanks for santiago to review partially it, but I need green light from release team.

Bastien

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Bastien

Post by Bastien Roucariès
Package: release.debian.org
Severity: important
Usertags: transition
Imagemagick will need a new major bump
I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).
Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.

Why does this migration require co-instabillity with the old version?
This makes the transition overly complicated. Do you expect major
changes required in reverse dependencies of imagemagick's shared
library?

PS: Before the time_t transition is done, we will not process other
transitions.

Cheers

[Bastien Roucariès]

Post by Sebastian Ramacher
Control: tags -1 moreinfo
Hi Bastien

Post by Bastien Roucariès
Package: release.debian.org
Severity: important
Usertags: transition
Imagemagick will need a new major bump
I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).
Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.

Why does this migration require co-instabillity with the old version?
This makes the transition overly complicated. Do you expect major
changes required in reverse dependencies of imagemagick's shared
library?

The problem is not the library but the command line interface that may need change.

Librarry will break (I think here about php module that will need a update), but it is treatable.

convert6 is not fully compatible with convert7

convert6 will be co installable with convert7 in order to test, and convert will be provided by alternative system.

We avoid a flag day, but we need co installable library.

Bastien

Post by Sebastian Ramacher
PS: Before the time_t transition is done, we will not process other
transitions.

Not a problem, but I will like to upload work on experimental in order to test other arch than i386/amd64/arm that I could test

Bastien

Post by Sebastian Ramacher
Cheers

[Sebastian Ramacher]

Post by Bastien Roucariès

Post by Sebastian Ramacher
Control: tags -1 moreinfo
Hi Bastien

Post by Bastien Roucariès
Package: release.debian.org
Severity: important
Usertags: transition
Imagemagick will need a new major bump
I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).
Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.

Why does this migration require co-instabillity with the old version?
This makes the transition overly complicated. Do you expect major
changes required in reverse dependencies of imagemagick's shared
library?

The problem is not the library but the command line interface that may need change.
Librarry will break (I think here about php module that will need a update), but it is treatable.
convert6 is not fully compatible with convert7
convert6 will be co installable with convert7 in order to test, and convert will be provided by alternative system.

If they are not fully compatible, then alternatives are not an option.
How many packages are we talking about? Have bugs been filed for
packages thar are not compatible with convert7?

Cheers

[Bastien Roucariès]

Post by Sebastian Ramacher

Post by Bastien Roucariès

Post by Sebastian Ramacher
Control: tags -1 moreinfo
Hi Bastien

Post by Bastien Roucariès
Package: release.debian.org
Severity: important
Usertags: transition
Imagemagick will need a new major bump
I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).
Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.

Why does this migration require co-instabillity with the old version?
This makes the transition overly complicated. Do you expect major
changes required in reverse dependencies of imagemagick's shared
library?

The problem is not the library but the command line interface that may need change.
Librarry will break (I think here about php module that will need a update), but it is treatable.
convert6 is not fully compatible with convert7
convert6 will be co installable with convert7 in order to test, and convert will be provided by alternative system.

If they are not fully compatible, then alternatives are not an option.

They are 95% compatible

Post by Sebastian Ramacher
How many packages are we talking about? Have bugs been filed for
packages thar are not compatible with convert7?

The problem is chicken and eggs problem. If you could not test then you could not report bug.
A least both should be in experimental for running a full archive rebuild

Not also that imagemagick6 is supported upstream only until 2027... So we should migrate to 7.

That why I think my way is a good way.

Suse and redhat transitionned see https://fedoraproject.org/wiki/Changes/ImageMagick7

Discussion point to a least broken on redhat
* autotrace - plan to notify upstream
* dvdauthor - point to GraphicsMagick or IM6, plan to notify upstream
* q - dead upstream, planned to point to IM6
* vdr-skinnopacity - current upstream dead, plan to notify new upstream
* vdr-tvguide - plan to notify upstream

We could also drop imagemagick6 and use graphickmagick if needed but it introduce other problem

Thanks

Bastien

Post by Sebastian Ramacher
Cheers

[Bastien Roucariès]

control: tags -1 - moreinfo

Hi,

Last reverse deps of lib magick pipeline is not really bad
https://salsa.debian.org/debian/imagemagick/-/pipelines/708187

A lot of failure are due to broken package or does not use pkgconfig

I suppose we could go to experimental

Bastien

[Bastien Roucariès]

Post by Bastien Roucariès
control: tags -1 - moreinfo
Hi,
Last reverse deps of lib magick pipeline is not really bad
https://salsa.debian.org/debian/imagemagick/-/pipelines/708187
A lot of failure are due to broken package or does not use pkgconfig
I suppose we could go to experimental

Yes, uploading to experimental would be the first step, as I said on my previous
email. Then we would need bug reports for packages that fail to build against
imagemagick 7. Make those bugs block this one and use some usertag to ease tracking.
If you want this to be done for trixie, we need to move fast.

Ok will go this night

Cheers,
Emilio

[Bastien Roucariès]

Post by Bastien Roucariès

Post by Bastien Roucariès
control: tags -1 - moreinfo
Hi,
Last reverse deps of lib magick pipeline is not really bad
https://salsa.debian.org/debian/imagemagick/-/pipelines/708187
A lot of failure are due to broken package or does not use pkgconfig
I suppose we could go to experimental

Yes, uploading to experimental would be the first step, as I said on my previous
email. Then we would need bug reports for packages that fail to build against
imagemagick 7. Make those bugs block this one and use some usertag to ease tracking.
If you want this to be done for trixie, we need to move fast.

Ok will go this night

Just push to NEWS

Post by Bastien Roucariès

Cheers,
Emilio

[Bastien Roucariès]

Hi,

Post by Bastien Roucariès

Post by Bastien Roucariès

Post by Bastien Roucariès
control: tags -1 - moreinfo
Hi,
Last reverse deps of lib magick pipeline is not really bad
https://salsa.debian.org/debian/imagemagick/-/pipelines/708187
A lot of failure are due to broken package or does not use pkgconfig
I suppose we could go to experimental

Yes, uploading to experimental would be the first step, as I said on my previous
email. Then we would need bug reports for packages that fail to build against
imagemagick 7. Make those bugs block this one and use some usertag to ease tracking.
If you want this to be done for trixie, we need to move fast.

I have just tested and linked FTBFS package to this bug

Post by Bastien Roucariès

Post by Bastien Roucariès
Ok will go this night

Just push to NEWS

Post by Bastien Roucariès

Cheers,
Emilio

[Bastien Roucariès]

Post by Bastien Roucariès
control: tags -1 - moreinfo
Hi,
Last reverse deps of lib magick pipeline is not really bad
https://salsa.debian.org/debian/imagemagick/-/pipelines/708187
A lot of failure are due to broken package or does not use pkgconfig
I suppose we could go to experimental

Yes, uploading to experimental would be the first step, as I said on my previous
email. Then we would need bug reports for packages that fail to build against
imagemagick 7. Make those bugs block this one and use some usertag to ease tracking.
If you want this to be done for trixie, we need to move fast.

Could we began with transition ?

I have fixed a few package and I think it is ok.

I am working with java team to fix jamagick

bastien

Cheers,
Emilio

[Johannes Schauer Marin Rodrigues]

Hi,

Post by Bastien Roucariès

Post by Bastien Roucariès
control: tags -1 - moreinfo
Hi,
Last reverse deps of lib magick pipeline is not really bad
https://salsa.debian.org/debian/imagemagick/-/pipelines/708187
A lot of failure are due to broken package or does not use pkgconfig
I suppose we could go to experimental

Yes, uploading to experimental would be the first step, as I said on my previous
email. Then we would need bug reports for packages that fail to build against
imagemagick 7. Make those bugs block this one and use some usertag to ease tracking.
If you want this to be done for trixie, we need to move fast.

Could we began with transition ?
I have fixed a few package and I think it is ok.
I am working with java team to fix jamagick

to support Bastien's request, I created a wiki page as an overview of the
current status:

https://wiki.debian.org/ImageMagick7

This page includes those source packages which FTBFS in the salsa-ci pipeline
that Bastien set up to test reverse dependencies of imagemagick:

https://salsa.debian.org/debian/imagemagick/-/pipelines/746158/builds

Most of the remaining failures are packages which FTBFS for other reasons than
imagemagick 7. I have linked the respective FTBFS bugs behind the "other FTBFS"
links. The remaining packages fall into either of the following categories:

- not in main
- popcon below 10
- has a bug filed blocking this bug
- dune-* (i believe those are false positives as i cannot reproduce them
locally)

There are only two exceptions with which I need Bastien's help:

- src:dx has not seen a new upstream release in 16 years and can be built
without imagemagick by running ./configure --without-magick
- src:digikam FTBFS with "MagickCore/magick-config.h:25:10: fatal error:
MagickCore/magick-baseconfig.h: No such file or directory" -- is that a
missing dependency of src:digikam on libmagickcore-dev (which pulls in
libmagickcore-7-arch-config) or should libmagick++-dev gain a dependency on
libmagickcore-dev?

Should I be looking into the FTBFS issues in contrib and non-free as well?

Bastien, I also created a MR against imagemagick's salsa repo which refactors
your rdep building construct, turning it from a manual selection of rdeps into
an automatic computation using build-rdeps from devscripts. You can have a look
if you like but it needs a bit more work and unfortunately, salsa does still
seem to be stuck, so my work on that is stalled:

https://salsa.debian.org/debian/imagemagick/-/merge_requests/1

Thanks!

cheers, josch