[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1060103: marked as done (transition: imagemagick7)

Your message dated Sun, 1 Dec 2024 23:42:33 +0100
with message-id <65c2a95d-0192-4e94-9565-fa388e02c5a9@debian.org>
and subject line Re: Bug#1060103: New of imagemagick7
has caused the Debian Bug report #1060103,
regarding transition: imagemagick7
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1060103: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060103
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: important
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-CC: ftpmaster@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

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
--- Begin Message --- 
On 29/11/2024 09:05, Emilio Pozuelo Monfort wrote:

On 07/11/2024 12:30, Emilio Pozuelo Monfort wrote:

On 01/11/2024 10:12, Emilio Pozuelo Monfort wrote:

On 30/10/2024 17:44, Bastien Roucariès wrote:

Le mercredi 23 octobre 2024, 12:03:21 UTC Emilio Pozuelo Monfort a écrit :
Hi,


Control: tags -1 confirmed

On 20/10/2024 11:04, Bastien Roucariès wrote:
Le jeudi 17 octobre 2024, 20:02:56 UTC Johannes Schauer Marin Rodrigues a écrit : 
Hi,
On Tue, 24 Sep 2024 12:58:48 +0000 Bastien =?ISO-8859-1?Q?Roucari=E8s?= <rouca@debian.org> wrote: 
Le mardi 20 août 2024, 07:11:13 UTC Emilio Pozuelo Monfort a écrit :

On 28/07/2024 20:56, Bastien Roucariès wrote:

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


Nice pipeline, and thanks for the wiki page.
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

Fixed in last salsa

   - 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?


fixed in last salsa




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!


Things are looking good. Let's go ahead.


Go ahead two day ago forget to mention here
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.
See php-imagick, pfstools, odr-padenc, kxstitch, gnustep-gui, drawtiming, wmaker, photoqt 

Please file bugs for those.
I filed bugs for: jhead drawtiming dx kxstitch libopenshot odr-padenc pfstools php-imagick synfig wand wmaker photoqt.
The autopkgtests for php-imagick and especially vips (which is a key package) are blocking imagemagick's transition to testing. Can you take a look at them? See: 

   https://tracker.debian.org/pkg/php-imagick
   https://tracker.debian.org/pkg/vips
With some NMUs and maintainer uploads, and a few hints, imagemagick is now in testing. Thanks for your work on it! 

Cheers,
Emilio

--- End Message ---
Reply to: