Bug 308437 – media-libs/libpng-1.4.1: re-enable PNG_READ_DITHER_SUPPORTED

• Product: Gentoo Linux
• Status: VERIFIED FIXED

[Description Samuli Suominen (RETIRED) 2010-03-08 10:54:36 UTC]

Patch to revert upstream change:

http://repos.archlinux.org/wsvn/packages/libpng/trunk/libpng14-enable-read-dither.patch

In libpng 1.4.0, PNG_READ_DITHER_SUPPORTED is turned off by default.  It seems that it wasn't working quite right and it had low usage:

http://sourceforge.net/mailarchive/forum.php?thread_name=e56ccc8f0812151445ybd95eb0i78eb9aef434a6e28%40mail.gmail.com&forum_name=png-mng-misc

Are there any objections in enabling it?

media-sound/timidity++:

../interface/libinterface.a(x_sherry.o): In function `sry_load_png':
x_sherry.c:(.text+0x997): undefined reference to `png_set_dither'
x_sherry.c:(.text+0xd58): undefined reference to `png_set_dither'
collect2: ld returned 1 exit status
make[2]: *** [timidity] Error 1

and likely same for xfix and transfig.

archlinux discussion:

http://www.mail-archive.com/[e-mail]/msg11600.html

[Comment 1 Samuli Suominen (RETIRED) 2010-03-08 10:57:32 UTC]

sorry, xfig, not xfix :)

[Comment 2 SpanKY 2010-03-09 00:27:11 UTC]

i'd point out that we'd be fiddling with the ABI and that's no fun ...

but either upstream doesnt reverse their decision and so we have to fix packages anyways, or upstream will re-enable the funcs and there's nothing for us to do.

considering the package is masked, screwing with the ABI isnt a big deal.  so perhaps add the patch like:
[[ -z ${KEYWORDS} ]] \
    && epatch ... \
    || die "review ABI change before unmasking #308437"

[Comment 3 Samuli Suominen (RETIRED) 2010-03-09 04:16:46 UTC]

(In reply to comment #2)
> i'd point out that we'd be fiddling with the ABI and that's no fun ...

nod

> considering the package is masked, screwing with the ABI isnt a big deal.  so
> perhaps add the patch like:
> [[ -z ${KEYWORDS} ]] \
>     && epatch ... \
>     || die "review ABI change before unmasking #308437"

timidity++ has several alternative guis, if this means letting go of one broken one, so be it.  transfig and xfig has long been in my radar for the imake crap wrt bug 289296, if needed be, they'll be masked

so... i'd prefer we skip that hack, and just don't do it at all to avoid futher delays in getting libpng keyworded, i've already checked and fixed 50% of gentoo-x86's libpng reverse deps, so keywording it shouldn't be too long away?

[Comment 4 SpanKY 2010-03-09 05:52:14 UTC]

libpng is owned by base-system because of its importance ... if it breaks, then an easy majority of a desktop stops rendering correctly (if it all).  i prefer to be a bit conservative with it.  so if that means once we get all known bugs fixed, i'd prefer we let it sit for a week or two to try and shake anything else out.

[Comment 5 Samuli Suominen (RETIRED) 2010-03-09 09:58:42 UTC]

Opened bugs for transfig/xfig here, bug 308617
And timidity++, bug 308619

Closing this as invalid per "i'd point out that we'd be fiddling with the ABI and that's no fun ...", got agreement there

[Comment 6 Samuli Suominen (RETIRED) 2010-05-03 21:10:33 UTC]

The function was restored in 1.4.2_rc5, upstream author/contributor/... mailed me. All timidity, xfig, transfig are back in action. :)

[Comment 7 Samuli Suominen (RETIRED) 2010-05-03 21:11:18 UTC]

*** Bug 308617 has been marked as a duplicate of this bug. ***

[Comment 8 Samuli Suominen (RETIRED) 2010-05-03 21:11:57 UTC]

*** Bug 308619 has been marked as a duplicate of this bug. ***

[Comment 9 Roby 2010-05-13 16:11:41 UTC]

It seems that in libpng-1.4.2 the png_set_dither function is disabled again

[Comment 10 Samuli Suominen (RETIRED) 2010-05-13 16:16:40 UTC]

(In reply to comment #9)
> It seems that in libpng-1.4.2 the png_set_dither function is disabled again
> 

no, it was renamed to "png_set_quantize" and "png_set_dither" was defined to it for backwards compability that will go away with libpng 1.5

so we are good for entire 1.4 series, transfix/xfig/timidity++ just needs to move to using png_set_quantize when libpng 1.5 is out... that's long in the future