Re: Bug#271673: librmagick-ruby1.8: librmagick-ruby unusable after upgrade to imagemagick-6.0.7.1
tag 271673 + sid
thanks
On Wed, Sep 15, 2004 at 07:06:32PM +0200, Daniel Kobras wrote:
> [ABI breakage in imagemagick] needs to be addressed urgently.
> Otherwise we end up with packages compiled against binary incompatible
> versions of imagemagick in the archive. I have therefore prepared an
> NMU roughly the same way I did last December when we faced a similar
> situation: I'll re-upload version 6.0.6.2 with a bumped epoch, based
> on the last known-good 6.0.6.2-1.2.
(...)
> It's important that the new upload makes it into sarge as soon as
> possible.
Unfortunately, getting the fixed imagemagick in is taking a few days
longer than I had been hoping[1]. I'm Ccing -release because we need to
watch out and re-upload each package that has meanwhile been built with
the broken imagemagick 6.0.7.1. Otherwise, those packages will most
likely contain subtle and hard to identify bugs. There's no simple,
automated way to tell whether a package was built with the buggy
version. We'll have to go by date, instead, so a delay of a few days
might matter. So far, Steve has identified only k3d as a package that
will need to be rebuilt. I'll start checking for others once the new
imagemagick finally makes sid on all archs. And hope that maintainers
hand-build their uploads on uptodate systems only... (If someone has
nifty scripts at hand to simplify the search, that would be very
welcome.)
Regards,
Daniel.
[1] Here's why: I've reverted imagemagick to an earlier upstream version
and included the old orig.tar.gz in the upload. The orig.tar.gz was
still present in the pool, though, so katie accepted the upload,
but discarded my orig.tar.gz. When the buildds tried to fetch the
sources, they failed because the orig.tar.gz is neither in incoming,
nor referenced in sid's Sources file. So imagemagick is stalled in
Needs_Build until the i386 upload is moved into the archive, and the
Sources file gets updated. Duh!
Summary: Emergency-reverting to the previous upstream version will
usually involve a one-day delay at least.
Reply to: