Debian Bug report logs - #507269
Providing compatibility -dev packages

version graph

Package: imagemagick; Maintainer for imagemagick is ImageMagick Packaging Team <pkg-gmagick-im-team@lists.alioth.debian.org>; Source for imagemagick is src:imagemagick.

Reported by: Loïc Minier <lool@dooz.org>

Date: Sat, 29 Nov 2008 16:06:02 UTC

Severity: wishlist

Found in version imagemagick/7:6.4.5.4.dfsg1-1

Fixed in version imagemagick/7:6.4.8.0-1

Done: naoliv@debian.org (Nelson A. de Oliveira)

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Sat, 29 Nov 2008 16:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
New Bug report received and forwarded. Copy sent to Luciano Bello <luciano@debian.org>. (Sat, 29 Nov 2008 16:06:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Providing compatibility -dev packages
Date: Sat, 29 Nov 2008 17:02:53 +0100
Package: imagemagick
Version: 7:6.4.5.4.dfsg1-1

        Hi there,

 I see you renamed imagemagick's -dev packages in experimental for the
 new upstream names of libs, .pc files, config programs and includes.

 I think this is going to be a painful transition if we move the
 packages as is to unstable.  It would make the transition much smoother
 if we provided compatibility libmagick++9-dev and libmagick9-dev
 packages.

 If we do this, we could use this occasion to also keep the
 compatibility binaries in the old package names to allow to get rid of
 them after the transition.

 These are my notes on the various header, libs, .pc files, and config
 programs:

old                     new                             new
-----------------------------------------------------------
libmagick9-dev          libmagickcore-dev               libmagickwand-dev
-------------------------------------------------------------------------
include/magick/
include/wand/
                        include/ImageMagick/magick
                                                        include/ImageMagick/wand

libMagick.so
libWand.so
                        libMagickCore.so
                                                        libMagickWand.so

Magick-config         D Magick-config
                      R MagickCore-config
Wand-config                                           D Wand-config
                                                      R MagickWand-config

ImageMagick.pc          ImageMagick.pc (D?)
                      N MagickCore.pc (R?)
Wand.pc                                                 Wand.pc (D?)
                                                      N MagickWand.pc (R?)

old                     new
---------------------------
libmagick++9-dev        libmagick++-dev
---------------------------------------

include/Magick++*
                        include/ImageMagick/Magick++*

libMagick++.so          libMagick++.so

Magick++-config         Magick++-config

ImageMagick++.pc        ImageMagick++.pc (D?)
                      N Magick++.pc (R?)

 N: NEW, D: DEPRECATED, R: REPLACEMENT


 I don't think we need to care about libs and headers, as .pc files
 should be used or in the worst case -config programs.  Therefore, I
 think it would make sense to:
 - readd libmagick++9-dev, deping on libmagick++-dev
 - move ImageMagick++.pc to libmagick++9-dev (not clear whether
   ImageMagick++.pc is truly deprecated)
 - readd libmagick9-dev, deping on libmagickcore-dev and
   libmagickwand-dev
 - move Wand-config, Magick-config, Wand.pc, ImageMagick.pc to
   libmagick9-dev (not sure whether the .pc files are truly deprecated)
 - change the Conflicts on libmagick9-dev and libmagick++9-dev to
   Replaces with << first version where libmagick++-dev,
   libmagickcore-dev, and libmagickwand-dev were introduced
 - add Replaces to libmagick++9-dev and libmagick9-dev on
   libmagickcore-dev, libmagickwand-dev, libmagick++-dev << version of
   this change

 What do you think?

   Bye
-- 
Loïc Minier




Severity set to `wishlist' from `normal' Request was from Nelson A. de Oliveira <naoliv@debian.org> to control@bugs.debian.org. (Mon, 01 Dec 2008 02:57:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Mon, 01 Dec 2008 04:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Nelson A. de Oliveira" <naoliv@gmail.com>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Mon, 01 Dec 2008 04:03:02 GMT) Full text and rfc822 format available.

Message #12 received at 507269@bugs.debian.org (full text, mbox):

From: "Nelson A. de Oliveira" <naoliv@gmail.com>
To: "Loïc Minier" <lool@dooz.org>, 507269@bugs.debian.org
Subject: Re: Bug#507269: Providing compatibility -dev packages
Date: Mon, 1 Dec 2008 01:58:51 -0200
Hi!

On Sat, Nov 29, 2008 at 2:02 PM, Loïc Minier <lool@dooz.org> wrote:
>  I think this is going to be a painful transition if we move the
>  packages as is to unstable.  It would make the transition much smoother
>  if we provided compatibility libmagick++9-dev and libmagick9-dev
>  packages.

While I understand [1], I said 3 months ago [2] that it wouldn't be an
"easy" transition.
Last time that I did a test, only some packages would FTBFS with the
new ImageMagick package. I have opened wishlist bugs against them and
provided patches with the fixes [3] (maybe not the correct fixes, but
they give the idea of what is necessary to change; from what I
remember, there are already 2 packages that are fixed in
experimental).

[1] https://bugs.edge.launchpad.net/ubuntu/+source/imagemagick/+bug/301618
[2] https://bugs.edge.launchpad.net/ubuntu/+source/imagemagick/+bug/188773/comments/4
[3] http://people.debian.org/~naoliv/misc/imagemagick/transition/

The transition is just a replace libmagick9-dev -> libmagickcore-dev
(and, if necessary, libmagickwand-dev too), libmagick++9-dev ->
libmagick++-dev, plus fixing the more or less 5 packages that will
FTBFS.

My intention is still wait for Lenny to be released, send a message
saying "I will upload the new imagemagick package to unstable in X
days, you need to do foo and bar and I will NMU your package in Y days
for the transition" to the maintainers that still didn't upload a
fixed package to experimental.

From my point of view, keeping a transitional libmagick++9-dev and
libmagick9-dev will only delay the problem for some time [see: Lenny
gets released; we upload the new imagemagick to unstable (with the
transitional packages) and Squeeze gets released with them; in Squeeze
+ 1 we remove the transitional packages. I am sure that there will be
packages still depending on libmagick++9-dev and libmagick9-dev at
this time and I don't want to have this work 2 releases away]. As I
said, my plan is to do the transition in Lenny + 1 (and without the
need of transitional packages).

I may be wrong and the other maintainers (Luciano and Daniel) may
disagree, but I don't want to think and work on the transitional
packages for a problem that just hits Ubuntu now.

Best regards,
Nelson




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Mon, 01 Dec 2008 10:18:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Mon, 01 Dec 2008 10:18:10 GMT) Full text and rfc822 format available.

Message #17 received at 507269@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: "Nelson A. de Oliveira" <naoliv@gmail.com>
Cc: 507269@bugs.debian.org
Subject: Re: Bug#507269: Providing compatibility -dev packages
Date: Mon, 1 Dec 2008 10:57:06 +0100
On Mon, Dec 01, 2008, Nelson A. de Oliveira wrote:
> My intention is still wait for Lenny to be released, send a message
> saying "I will upload the new imagemagick package to unstable in X
> days, you need to do foo and bar and I will NMU your package in Y days
> for the transition" to the maintainers that still didn't upload a
> fixed package to experimental.

 Ah, so you wanted to prepare the full transition in experimental and
 then have coordinated uploads; that mostly works, but it's not easy:
 not only to motivate people to upload to experimental, but also to
 coordinate the uploads to unstable when you push the new imagemagick.

> From my point of view, keeping a transitional libmagick++9-dev and
> libmagick9-dev will only delay the problem for some time [see: Lenny
> gets released; we upload the new imagemagick to unstable (with the
> transitional packages) and Squeeze gets released with them; in Squeeze
> + 1 we remove the transitional packages.

 No, I think you can remove them as soon as all rbdeps are using the new
 packages.

>                                          I am sure that there will be
> packages still depending on libmagick++9-dev and libmagick9-dev at
> this time and I don't want to have this work 2 releases away]. As I
> said, my plan is to do the transition in Lenny + 1 (and without the
> need of transitional packages).

 Why?  and even would there be, what's the harm?

 Of course it's up to you, but I think you should consider these two
 points:
 - if you provide transitional packages, you can upload imagemagick to
   unstable immediately after the lenny release.
 - if you provide transitional packages, imagemagick will be able to
   migrate to squeeze in its new version faster then if you don't.
 - virtual packages break versionned dependencies and cause subtle
   breakage; for instance graphicsmagick-libmagick-dev-compat provides
   libmagick++-dev and libmagick-dev and satisfies any build-dep on
   these.  Also, consider packages which aim at being backportable
   without any sourceful changes (with alternate build-deps which work
   in the previous release)

> I may be wrong and the other maintainers (Luciano and Daniel) may
> disagree, but I don't want to think and work on the transitional
> packages for a problem that just hits Ubuntu now.

 Sure, it only hits Ubuntu right now; I think it's going to be
 unnecessary pain for Debian as well.

-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Mon, 01 Dec 2008 12:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Nelson A. de Oliveira" <naoliv@gmail.com>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Mon, 01 Dec 2008 12:12:03 GMT) Full text and rfc822 format available.

Message #22 received at 507269@bugs.debian.org (full text, mbox):

From: "Nelson A. de Oliveira" <naoliv@gmail.com>
To: "Loïc Minier" <lool@dooz.org>
Cc: 507269@bugs.debian.org
Subject: Re: Bug#507269: Providing compatibility -dev packages
Date: Mon, 1 Dec 2008 10:07:58 -0200
Hi!

On Mon, Dec 1, 2008 at 7:57 AM, Loïc Minier <lool@dooz.org> wrote:
>> I may be wrong and the other maintainers (Luciano and Daniel) may
>> disagree, but I don't want to think and work on the transitional
>> packages for a problem that just hits Ubuntu now.
>
>  Sure, it only hits Ubuntu right now; I think it's going to be
>  unnecessary pain for Debian as well.

Probably it's looking that I don't want to cooperate, but I have a lot
of pending stuff to do in real life (paid job, to be more specific)
and also for Debian. I wish I had more time, but I just can't help
right now in a problem that doesn't directly affect Debian (and that
already has a plan for the future). Sorry.

Best regards,
Nelson




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Tue, 02 Dec 2008 20:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adeodato Simó <dato@net.com.org.es>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Tue, 02 Dec 2008 20:15:02 GMT) Full text and rfc822 format available.

Message #27 received at 507269@bugs.debian.org (full text, mbox):

From: Adeodato Simó <dato@net.com.org.es>
To: "Nelson A. de Oliveira" <naoliv@gmail.com>, 507269@bugs.debian.org
Cc: Loïc Minier <lool@dooz.org>, debian-release@lists.debian.org
Subject: Opinion of the Release Team on the ImageMagick transition
Date: Tue, 2 Dec 2008 21:13:35 +0100
Hello, Nelson. #507269 has been recently brought to our attention, and
I'd like to pop in because, unlike what you state in the bug report,
this issue affects Debian, so it should be addressed if possible,
independently of whether that benefits Ubuntu or not. Let's see if we
can agree on something.

I see you mailed the -release list a while ago about this transition,
but I think the fact that -dev packages were renamed was not mentioned
anywhere. In any case, here's, in a nutshell, the meat of I have to say:

    ** Library transitions that can possibly be handled without
       sourceful uploads, must be done that way. **

Traditionally, library transitions in Debian required sourceful uploads
of every package, to trigger a rebuilds in all architectures. Nowadays
we can trigger rebuilds automatically via wanna-build (binary NMUs).

In an ideal world, APIs never break backwards compatibility, so
automatic rebuilds are always possible. If upstreams break API
compatibility, well, we're out of luck. But the way I see it, the name
of the -dev packages in Debian is *part* of the API, and we should know
better and not break *our* API by changing those names gratuitously,
hence  making the transition harder for everybody (even if the library
maintainer would volunteer to make all the required sourceful uploads,
the transition would still be harder for the release team).

I understand very well, though, that sometimes cleanups in the packaging
are needed, and I agree with you that there should be no need to keep
the transitional packages until squeeze + 1. The important point is that
the time to throw away the transitional stuff should be decoupled from
the time when the transition is done: throwing away old stuff is a wish
from the maintainer, doing the transition is a need of the distribution,
and it involves several other parties (other maintainers and the release
team in particular).

Because of this, the way to move forward is always to do the transition
itself without breaking the "Debian API", and then if the maintainers so
wish, to file bugs around so that the maintainers of reverse
dependencies move to the new API (new names for the -dev packages, that
is, and possibly other bits). After a while, the library maintainers may
choose to NMU the remaining issues, and break the API then, with no need
to wait for squeeze + 1.

I think that there's always been a desire to couple the transition with
the cleanup of the Debian API becuase that's a warranty that it will get
done. But, as I said, that makes other people's job harder in order to
satisfy a personal goal, and there's no reason not to decouple them
(particularly if the message that NMUs for those changes are OK gets
transmitted well).

                                 * * *

So, because of all this, can we agree on some way that the transition
can be done without need of doing a sourceful upload of every involved
package?

Regarding the -dev package names, I'm personally OK if you don't
introduce transitional packages and just add Provides: fields, because
AFAICS only 2 packages in the archive have a versioned build-dependency
on imagemagick.

And regarding the .pc and -config stuff, something should be done so
that packages continue to build without any source change, until after
the transition is done.

Does this sound doable from your side? In particular, using Provides is
much easier than using transitional packages, so it should be less
effort for you. (Unless somebody has spotted that it won't work, in that
case please speak up!)

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                            Listening to: Vainica Doble - Cartas de amor





Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Wed, 03 Dec 2008 09:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Wed, 03 Dec 2008 09:12:06 GMT) Full text and rfc822 format available.

Message #32 received at 507269@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: "Nelson A. de Oliveira" <naoliv@gmail.com>, 507269@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Wed, 3 Dec 2008 10:08:40 +0100
On Tue, Dec 02, 2008, Adeodato Simó wrote:
> Regarding the -dev package names, I'm personally OK if you don't
> introduce transitional packages and just add Provides: fields, because
> AFAICS only 2 packages in the archive have a versioned build-dependency
> on imagemagick.

 Concerning Provides, I need to point a slightly related issue which is
 that libmagick++-dev is provided by graphicsmagick-libmagick-dev-compat
 in unstable and not in experimental.

 This means that graphicsmagick-libmagick-dev-compat and imagemagick
 need to move together into unstable and into testing.  (I don't think
 it's possible to install graphicsmagick-libmagick-dev-compat/unstable
 with imagemagick/experimental alone though.)

> Does this sound doable from your side? In particular, using Provides is
> much easier than using transitional packages, so it should be less
> effort for you. (Unless somebody has spotted that it won't work, in that
> case please speak up!)

 I don't like Provides because they break versionned deps, but you point
 that out already; I find real packages are much easier to get right and
 reserve less surprizes; but you point out that a small number of
 build-deps are actually versionned, so I guess that's fine.

 I didn't look into the specifics, but I think the backports people
 would appreciate it if it was possible to have build-dependencies which
 work in squeeze and lenny.


    Thanks,
-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Wed, 03 Dec 2008 11:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to 507269@bugs.debian.org, lool@dooz.org, debian-release@lists.debian.org, naoliv@gmail.com, dato@net.com.org.es:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Wed, 03 Dec 2008 11:18:03 GMT) Full text and rfc822 format available.

Message #37 received at 507269@bugs.debian.org (full text, mbox):

From: "Nelson A. de Oliveira" <naoliv@gmail.com>
To: Adeodato Simó <dato@net.com.org.es>
Cc: 507269@bugs.debian.org, Loïc Minier <lool@dooz.org>, debian-release@lists.debian.org
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Wed, 3 Dec 2008 09:15:37 -0200
Hi!

On Tue, 2 Dec 2008 21:13:35 +0100
Adeodato Simó <dato@net.com.org.es> wrote:

> Does this sound doable from your side? In particular, using Provides
> is much easier than using transitional packages, so it should be less
> effort for you. (Unless somebody has spotted that it won't work, in
> that case please speak up!)

OK. I left my machine rebuilding the reverse build dependencies this
night. The change that I did in Imagemagick is this:
http://people.debian.org/~naoliv/misc/imagemagick/507269/diff-control.txt
(libmagickcore-dev provides libmagick9-dev, libmagick++-dev provides
libmagick++9-dev)

=============
Already OK:

kallery - OK - already changed at experimental
labplot - OK (build-deps: libmagick9-dev | libmagickcore-dev)
rss-glx - OK (build-deps: libmagick9-dev | libmagickwand-dev)
dvdauthor - OK (build-deps: libmagick++9-dev | libmagick++-dev)

=============

Reverse build dependencies of libmagick9-dev, using libmagickcore-dev:

libfprint - OK
xine-lib - FTBFS (I think that it's not related with imagemagick)
vips - OK
ale - OK
autotrace - didn't test; it tries to pull libmagick9-dev via libpstoedit-dev
dx - OK
gnuift - OK
imview - OK
jmagick - OK
kismet - OK

=============
With problem:

librmagick-ruby - versioned depends on libmagick9-dev
human-icon-theme - versioned depends on libmagick9-dev
tangerine-icon-theme - versioned depends on libmagick9-dev

=============
With libmagickwand-dev (and thus need to update de build-deps),
libmagickcore-dev, libmagickcore1, libmagickwand1, all at version
7:6.4.6.8.dfsg1-1:

php-imagick - OK
nip2 - FTBFS

=============
With imagemagick, libmagickcore-dev, libmagickcore1, libmagickwand1,
all at version 7:6.4.6.8.dfsg1-1

tango-icon-theme - OK
oxine - OK


Rebuild of the reverse build dependencies of libmagick++9-dev, using
libmagick++-dev with the provides:

=============
With libmagick++-dev, libmagick++1, libmagickcore-dev, libmagickcore1,
libmagickwand-dev, libmagickwand1, all at version 7:6.4.6.8.dfsg1-1:

cimg - FTBFS
gnudatalanguage - FTBFS
inkscape - OK
k3d - OK
kxstitch - FTBFS (#485893)
labplot - didn't test; it tries to pull libmagick9-dev via libpstoedit-dev
libextractor - OK
pfstools - OK
player - OK
prestimel - OK
pstoedit - OK
pythonmagick - FTBFS
qbittorrent - OK
synfig - OK
zebra - OK


Note that an "OK" means just that the package has been built. There
might be problems with them, like with imview (it didn't detect
imagemagick).

Build logs can be found at
http://people.debian.org/~naoliv/misc/imagemagick/507269/logs/ 

If using the provides helps, I can upload the packages to experimental
as they are now. Otherwise, as I said, I can't promise that I will be
able to think and implement a fast solution.

Best regards,
Nelson




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Wed, 03 Dec 2008 11:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Paul Wise" <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Wed, 03 Dec 2008 11:24:02 GMT) Full text and rfc822 format available.

Message #42 received at 507269@bugs.debian.org (full text, mbox):

From: "Paul Wise" <pabs@debian.org>
To: 507269@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Wed, 3 Dec 2008 20:21:10 +0900
On Wed, Dec 3, 2008 at 8:15 PM, Nelson A. de Oliveira <naoliv@gmail.com> wrote:

> Rebuild of the reverse build dependencies of libmagick++9-dev, using
> libmagick++-dev with the provides:
>
> =============
> With libmagick++-dev, libmagick++1, libmagickcore-dev, libmagickcore1,
> libmagickwand-dev, libmagickwand1, all at version 7:6.4.6.8.dfsg1-1:
>...
> synfig - OK

synfig will need source changes to correctly detect and build against
the new imagemagick.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Wed, 03 Dec 2008 12:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Wed, 03 Dec 2008 12:39:03 GMT) Full text and rfc822 format available.

Message #47 received at 507269@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: 507269@bugs.debian.org, debian-release@lists.debian.org, naoliv@gmail.com, dato@net.com.org.es
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Wed, 3 Dec 2008 13:36:43 +0100
On Wed, Dec 03, 2008, Nelson A. de Oliveira wrote:
> http://people.debian.org/~naoliv/misc/imagemagick/507269/diff-control.txt

 Hmm why didn't you add the Provides to libmagickwand-dev (which depends
 on libmagickcore-dev and so pulls everything which used to be there)?

> xine-lib - FTBFS (I think that it's not related with imagemagick)

 The symptom for broken imagemagick (well Wand) handling in this case is
 that the build seems to go to the end, but it fails with some missing
 plugin during dh_install or something similar.  Looking at the build
 log you provided, it's exactly the output I've hit with the new
 imagemagick in Ubuntu (which I fixed by changing xine-lib's build-deps
 in Ubuntu).

> librmagick-ruby - versioned depends on libmagick9-dev
> human-icon-theme - versioned depends on libmagick9-dev
> tangerine-icon-theme - versioned depends on libmagick9-dev

 I've pushed tangerine-icon-theme/0.26.debian-3 with a "libmagickcore-dev
 | libmagick9-dev" (unversionned) build-dep; it relies on
 ImageMagick.pc and the "convert" program.  In fact it doesn't really
 the ImageMagick libs, it just needs the .pc file to check the version
 of IM.

 I've also pushed human-icon-theme/0.28.debian-3 with the exact same
 changes for the same reasons.

 Release team: could you please unblock these two?  Not critical for
 lenny, but gets things in shape.

> With libmagickwand-dev (and thus need to update de build-deps),
> libmagickcore-dev, libmagickcore1, libmagickwand1, all at version
> 7:6.4.6.8.dfsg1-1:
> 
> php-imagick - OK
> nip2 - FTBFS

 Ok, these would go away (and I would guess xine-lib as well, as it uses
 Wand) if you move the Provides to wand-dev.

> http://people.debian.org/~naoliv/misc/imagemagick/507269/logs/

 Thanks for these rebuilds and the diff,
-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Tue, 09 Dec 2008 19:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Luk Claes <luk@debian.org>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Tue, 09 Dec 2008 19:03:03 GMT) Full text and rfc822 format available.

Message #52 received at 507269@bugs.debian.org (full text, mbox):

From: Luk Claes <luk@debian.org>
To: 507269@bugs.debian.org, debian-release@lists.debian.org, naoliv@gmail.com, dato@net.com.org.es
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Tue, 09 Dec 2008 20:01:21 +0100
Loïc Minier wrote:
> On Wed, Dec 03, 2008, Nelson A. de Oliveira wrote:
>> http://people.debian.org/~naoliv/misc/imagemagick/507269/diff-control.txt
> 
>  Hmm why didn't you add the Provides to libmagickwand-dev (which depends
>  on libmagickcore-dev and so pulls everything which used to be there)?
> 
>> xine-lib - FTBFS (I think that it's not related with imagemagick)
> 
>  The symptom for broken imagemagick (well Wand) handling in this case is
>  that the build seems to go to the end, but it fails with some missing
>  plugin during dh_install or something similar.  Looking at the build
>  log you provided, it's exactly the output I've hit with the new
>  imagemagick in Ubuntu (which I fixed by changing xine-lib's build-deps
>  in Ubuntu).
> 
>> librmagick-ruby - versioned depends on libmagick9-dev
>> human-icon-theme - versioned depends on libmagick9-dev
>> tangerine-icon-theme - versioned depends on libmagick9-dev
> 
>  I've pushed tangerine-icon-theme/0.26.debian-3 with a "libmagickcore-dev
>  | libmagick9-dev" (unversionned) build-dep; it relies on
>  ImageMagick.pc and the "convert" program.  In fact it doesn't really
>  the ImageMagick libs, it just needs the .pc file to check the version
>  of IM.
> 
>  I've also pushed human-icon-theme/0.28.debian-3 with the exact same
>  changes for the same reasons.
> 
>  Release team: could you please unblock these two?  Not critical for
>  lenny, but gets things in shape.

both unblocked

cheers

Luk




Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Tue, 16 Dec 2008 23:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to 507269@bugs.debian.org, naoliv@gmail.com:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Tue, 16 Dec 2008 23:36:02 GMT) Full text and rfc822 format available.

Message #57 received at 507269@bugs.debian.org (full text, mbox):

From: "Nelson A. de Oliveira" <naoliv@gmail.com>
To: Loïc Minier <lool@dooz.org>
Cc: 507269@bugs.debian.org
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Tue, 16 Dec 2008 21:35:12 -0200
[Message part 1 (text/plain, inline)]
Hi Loïc!

(I have removed -release for now)

On Wed, 3 Dec 2008 13:36:43 +0100
Loïc Minier <lool@dooz.org> wrote:

> On Wed, Dec 03, 2008, Nelson A. de Oliveira wrote:
> > http://people.debian.org/~naoliv/misc/imagemagick/507269/diff-control.txt
> 
>  Hmm why didn't you add the Provides to libmagickwand-dev (which
> depends on libmagickcore-dev and so pulls everything which used to be
> there)?

Because the majority of the packages don't need to also have
libmagickwand-dev and libmagickwand1 installed to be built. I was
thinking on the unnecessary packages that would be downloaded/installed
to build them.

> > nip2 - FTBFS
> 
>  Ok, these would go away (and I would guess xine-lib as well, as it
> uses Wand) if you move the Provides to wand-dev.

Isn't it acceptable to fix these packages that FTBFS and keep the
provides only on libmagickcore-dev?

Thank you!

Best regards,
Nelson
[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Luciano Bello <luciano@debian.org>:
Bug#507269; Package imagemagick. (Wed, 17 Dec 2008 02:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Luciano Bello <luciano@debian.org>. (Wed, 17 Dec 2008 02:18:02 GMT) Full text and rfc822 format available.

Message #62 received at 507269@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: 507269@bugs.debian.org, naoliv@gmail.com
Subject: Re: Opinion of the Release Team on the ImageMagick transition
Date: Wed, 17 Dec 2008 03:15:30 +0100
On Tue, Dec 16, 2008, Nelson A. de Oliveira wrote:
> Because the majority of the packages don't need to also have
> libmagickwand-dev and libmagickwand1 installed to be built. I was
> thinking on the unnecessary packages that would be downloaded/installed
> to build them.

 Well I think our first order goal is to provide support for build-deps
 which haven't migrated yet; I don't think that we should consider these
 additional packages to download and install to be more important.

> > > nip2 - FTBFS
> >  Ok, these would go away (and I would guess xine-lib as well, as it
> > uses Wand) if you move the Provides to wand-dev.
> Isn't it acceptable to fix these packages that FTBFS and keep the
> provides only on libmagickcore-dev?

 Eventually we will fix all packages, but this would be trading human
 time against computer time; I'd rather have the provides pull
 everything for compatibility.

 I spent some time fixing a couple rbdeps I own; I'm happy to fix any
 other I can fix in Debian, and even help poking maintainers for some
 more, but I'd really like the transition to be as smooth as possible.

-- 
Loïc Minier




Tags added: pending Request was from Nelson A. de Oliveira <naoliv@debian.org> to control@bugs.debian.org. (Sun, 21 Dec 2008 19:54:02 GMT) Full text and rfc822 format available.

Reply sent to naoliv@debian.org (Nelson A. de Oliveira):
You have taken responsibility. (Tue, 23 Dec 2008 15:40:41 GMT) Full text and rfc822 format available.

Notification sent to Loïc Minier <lool@dooz.org>:
Bug acknowledged by developer. (Tue, 23 Dec 2008 15:40:44 GMT) Full text and rfc822 format available.

Message #69 received at 507269-close@bugs.debian.org (full text, mbox):

From: naoliv@debian.org (Nelson A. de Oliveira)
To: 507269-close@bugs.debian.org
Subject: Bug#507269: fixed in imagemagick 7:6.4.8.0-1
Date: Tue, 23 Dec 2008 15:17:13 +0000
Source: imagemagick
Source-Version: 7:6.4.8.0-1

We believe that the bug you reported is fixed in the latest version of
imagemagick, which is due to be installed in the Debian FTP archive:

imagemagick-dbg_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/imagemagick-dbg_6.4.8.0-1_i386.deb
imagemagick-doc_6.4.8.0-1_all.deb
  to pool/main/i/imagemagick/imagemagick-doc_6.4.8.0-1_all.deb
imagemagick_6.4.8.0-1.diff.gz
  to pool/main/i/imagemagick/imagemagick_6.4.8.0-1.diff.gz
imagemagick_6.4.8.0-1.dsc
  to pool/main/i/imagemagick/imagemagick_6.4.8.0-1.dsc
imagemagick_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/imagemagick_6.4.8.0-1_i386.deb
imagemagick_6.4.8.0.orig.tar.gz
  to pool/main/i/imagemagick/imagemagick_6.4.8.0.orig.tar.gz
libmagick++-dev_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/libmagick++-dev_6.4.8.0-1_i386.deb
libmagick++1_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/libmagick++1_6.4.8.0-1_i386.deb
libmagickcore-dev_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/libmagickcore-dev_6.4.8.0-1_i386.deb
libmagickcore1_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/libmagickcore1_6.4.8.0-1_i386.deb
libmagickwand-dev_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/libmagickwand-dev_6.4.8.0-1_i386.deb
libmagickwand1_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/libmagickwand1_6.4.8.0-1_i386.deb
perlmagick_6.4.8.0-1_i386.deb
  to pool/main/i/imagemagick/perlmagick_6.4.8.0-1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 507269@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nelson A. de Oliveira <naoliv@debian.org> (supplier of updated imagemagick package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 23 Dec 2008 11:39:06 -0200
Source: imagemagick
Binary: imagemagick imagemagick-dbg imagemagick-doc libmagickcore1 libmagickcore-dev libmagickwand1 libmagickwand-dev libmagick++1 libmagick++-dev perlmagick
Architecture: source i386 all
Version: 7:6.4.8.0-1
Distribution: experimental
Urgency: low
Maintainer: ImageMagick Packaging Team <pkg-gmagick-im-team@lists.alioth.debian.org>
Changed-By: Nelson A. de Oliveira <naoliv@debian.org>
Description: 
 imagemagick - image manipulation programs
 imagemagick-dbg - debugging symbols for ImageMagick
 imagemagick-doc - document files of ImageMagick
 libmagick++-dev - object-oriented C++ interface to ImageMagick - development files
 libmagick++1 - object-oriented C++ interface to ImageMagick
 libmagickcore-dev - low-level image manipulation library - development files
 libmagickcore1 - low-level image manipulation library
 libmagickwand-dev - image manipulation library - development files
 libmagickwand1 - image manipulation library
 perlmagick - Perl interface to the ImageMagick graphics routines
Closes: 350410 462759 475577 484059 507269
Changes: 
 imagemagick (7:6.4.8.0-1) experimental; urgency=low
 .
   * New upstream release;
   * Fix broken link in /usr/share/doc/imagemagick/index.html (Closes: #475577);
   * Include symbols files for libmagickcore1, libmagickwand1 and libmagick++1;
   * debian/control: libmagickwand-dev provides libmagick9-dev and
     libmagick++-dev provides libmagick++9-dev (Closes: #507269);
   * Remove debian/patches/readme-utf8.patch;
   * The ImageMagick logo has the same license as the ImageMagick distribution
     (thus we don't need to repackage and remove its logo from the tarball);
   * Remove debian/patches/add_dfsg_free_logo.patch;
   * Remove debian/patches/manpages.patch (applied upstream);
   * ImageMagick does not include a font object unless a label is specified on
     the command line (Closes: #484059);
   * Fix error message when trying to create a SVG file (Closes: #350410);
   * Fix negative offset in -geometry (Closes: #462759).
Checksums-Sha1: 
 7faa3001f663d9c65845269162da20a8a114bafc 1754 imagemagick_6.4.8.0-1.dsc
 248e9d9ffd5047d23dae2fd21d68d8edd77b80e0 11158230 imagemagick_6.4.8.0.orig.tar.gz
 027271e086ba0c53b557513a022b92a8d81b0c2c 57856 imagemagick_6.4.8.0-1.diff.gz
 a2e41cc103d08f60bc485ebca3ae0fec00e9fad9 88040 imagemagick_6.4.8.0-1_i386.deb
 f14129e3f8b61a2825f4593a4a6237fe652d362a 3311968 imagemagick-dbg_6.4.8.0-1_i386.deb
 781ff56cff05f49c1eb4a8d60964877a7be492e6 4125618 imagemagick-doc_6.4.8.0-1_all.deb
 45d6ec26c3c55359c498f118f7680cd53c529a96 1685410 libmagickcore1_6.4.8.0-1_i386.deb
 ad75bbd6e356d60a87796e49b59186d39a5d467b 3408306 libmagickcore-dev_6.4.8.0-1_i386.deb
 fc4a664fe780d112962a3cb9433a77f6522d627f 337970 libmagickwand1_6.4.8.0-1_i386.deb
 168c398b49469b3d830c06ccf99f878962cd1731 409784 libmagickwand-dev_6.4.8.0-1_i386.deb
 64c235852b7f57a643d75f6f93a47d2ef6c475b0 209018 libmagick++1_6.4.8.0-1_i386.deb
 726b0566c6939dae874a8542af93041bdecd4d2e 223430 libmagick++-dev_6.4.8.0-1_i386.deb
 bd866e7e2d487be020ec9a0248545747157f5411 195894 perlmagick_6.4.8.0-1_i386.deb
Checksums-Sha256: 
 1c54daa5d645757948ba31db76d2343206cb4f576d3261443c3cb0029e17b3de 1754 imagemagick_6.4.8.0-1.dsc
 c224dbfbfa4c335773d8f74316e7b1d1f8bd2ced576869f1d6e9196d40170481 11158230 imagemagick_6.4.8.0.orig.tar.gz
 a6132da554bca7b24ead5abd468d0170a20275a87dd7039821d0b453bac717c5 57856 imagemagick_6.4.8.0-1.diff.gz
 ced0044920316cbab209b4da980665b7248c0999b6f53b31839beb68efb661ce 88040 imagemagick_6.4.8.0-1_i386.deb
 e129615c32391e2f20c9cf2906c869497bcfd210186783d0d23e313071300a2a 3311968 imagemagick-dbg_6.4.8.0-1_i386.deb
 3d39e00ebb615dc3ab9fc83f8ac4223e0be4fa3876254685b7ddc887196ebd44 4125618 imagemagick-doc_6.4.8.0-1_all.deb
 5ca6881808231d2e13bca3b1a19944735aaa70533952422aa9004a4a0a059a49 1685410 libmagickcore1_6.4.8.0-1_i386.deb
 6a55593d3e8f2a9f705e7d2a553a0921a04ab012e87dcd2f2e945359fa8764ac 3408306 libmagickcore-dev_6.4.8.0-1_i386.deb
 a1a3dd1d20ae48499aac03f8e3e819dae386a9108bc7f1d0c159f8fe47165f80 337970 libmagickwand1_6.4.8.0-1_i386.deb
 98e94440b127316bed014edcdd237eb12e56b801ebf706576fdd7912241c3333 409784 libmagickwand-dev_6.4.8.0-1_i386.deb
 eb96fb453aece8c9ef4e4a9c3607e6912a7faa2bc406f640db907d6d010d2f4b 209018 libmagick++1_6.4.8.0-1_i386.deb
 074ffb5b93857f0ed13596509d486c7ee3bb5e4c448dbdcd6e44de87d66e2704 223430 libmagick++-dev_6.4.8.0-1_i386.deb
 ad4344a136519fde1c0cfa16bd1de37529fed6dbfd8989715932ee2f5ca3f37c 195894 perlmagick_6.4.8.0-1_i386.deb
Files: 
 b4c3172b94818ea89f3e7608a640fe95 1754 graphics optional imagemagick_6.4.8.0-1.dsc
 dd36dab5ef221ee80a757431455de270 11158230 graphics optional imagemagick_6.4.8.0.orig.tar.gz
 e7713e70dfe94643e0d6150cee598e90 57856 graphics optional imagemagick_6.4.8.0-1.diff.gz
 a7416cb5223b6c192036ab38377db7a6 88040 graphics optional imagemagick_6.4.8.0-1_i386.deb
 78a2640ee7d86988ac0194454b7faa79 3311968 libdevel extra imagemagick-dbg_6.4.8.0-1_i386.deb
 a3ba66d868d265f56cb2eab5aee2f5d8 4125618 doc optional imagemagick-doc_6.4.8.0-1_all.deb
 12201e0b1d77e2f8934a378724826645 1685410 libs optional libmagickcore1_6.4.8.0-1_i386.deb
 ebff5288006007022295c4d72e967e19 3408306 libdevel optional libmagickcore-dev_6.4.8.0-1_i386.deb
 8b613699770fb67d008aaa34b5cbacdd 337970 libs optional libmagickwand1_6.4.8.0-1_i386.deb
 0fdd99a51ff36810417e621ffbe19d69 409784 libdevel optional libmagickwand-dev_6.4.8.0-1_i386.deb
 29508c6f978dd873a2e763b871fc4878 209018 libs optional libmagick++1_6.4.8.0-1_i386.deb
 b143595746760912d8c51f182414851c 223430 libdevel optional libmagick++-dev_6.4.8.0-1_i386.deb
 2a589b0c96ad4aa2a0940d4e937e69a6 195894 perl optional perlmagick_6.4.8.0-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklQ8VIACgkQAQwuptkwlkRB7wCeIGzsjBqWJvNS9GZyEFssNIPS
OgEAoIPT+BGlXlmtvtBNmRQ3HrKOlxgs
=V7h0
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 01 Sep 2009 07:38:22 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 00:47:43 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.