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/arch-dev-public@archlinux.org/msg11600.html
sorry, xfig, not xfix :)
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"
(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?
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.
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
The function was restored in 1.4.2_rc5, upstream author/contributor/... mailed me. All timidity, xfig, transfig are back in action. :)
*** Bug 308617 has been marked as a duplicate of this bug. ***
*** Bug 308619 has been marked as a duplicate of this bug. ***
It seems that in libpng-1.4.2 the png_set_dither function is disabled again
(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
