| 1 |
>>> the maintainer of media-gfx/imagemagick sekretarz is not responding to bugmail |
| 2 |
>>> and the package has two open security bugs. |
| 3 |
>>> |
| 4 |
>>> https://bugs.gentoo.org/show_bug.cgi?id=143533 |
| 5 |
>>> https://bugs.gentoo.org/show_bug.cgi?id=144091 |
| 6 |
>>> |
| 7 |
>>> Anyone willing to help take care of this package please CC yourself on the |
| 8 |
>>> bugs and provide a bump. |
| 9 |
>> Not to forget that one: |
| 10 |
>> https://bugs.gentoo.org/show_bug.cgi?id=121142 |
| 11 |
>> |
| 12 |
>> Well, it's not as important as security fixed, but well - if the new |
| 13 |
>> imagemagick-version, which became stabel recently, would have a new |
| 14 |
>> version for the libMagick.so, then users would have a broken perl-module |
| 15 |
>> again. |
| 16 |
> |
| 17 |
> Makes me wonder if we shouldn't just resurect the perlmagic ebuild again |
| 18 |
> and be done with it. |
| 19 |
|
| 20 |
The "Makefile.PL" gets recreated by ImageMagick's configure. Normally, |
| 21 |
it contains a huge list of libraries in the linker call. If lots of |
| 22 |
use-flags are turned off, we might run into problems if we simply use |
| 23 |
the Makefile.PL (which exists, but as i said, it _normally_ gets |
| 24 |
re-created when running configure). |
| 25 |
|
| 26 |
So before PerlMagick becomes independant of ImageMagick's configure, |
| 27 |
upstream must change a few things. |
Archives