Will attach log. Upstream version is at 1.7.14, but that doesn't compile either.
Created attachment 263561 [details] pngcrush compilation failure with libpng 1.5
Added 1.7.16 to the tree. Maybe it fares better?
>>> Compiling source in /var/tmp/portage/media-gfx/pngcrush-1.7.16/work/pngcrush-1.7.16-nolib ... make -j9 x86_64-pc-linux-gnu-gcc -march=core2 -mtune=generic -msse4.1 -msse4.2 -O2 -pipe -I. -Wall -DPNG_USE_PNGGCCRD -DPNG_iCCP_SUPPORTED -DPNG_iTXt_SUPPORTED -DPNG_USE_GLOBAL_ARRAYS -DGAS_VERSION="\"2.21.1\"" -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu pngcrush.c -lpng -lz -o pngcrush pngcrush.c:709:2: error: #error pngcrush-nolib requires libpng-1.4 or earlier make: *** [pngcrush] Error 1 * ERROR: media-gfx/pngcrush-1.7.16 failed (compile phase):
pngcrush-1.7.17 also doesn't work with libpng-1.5.
This really should be fixed... :/ Same here.
(In reply to comment #5) > This really should be fixed... :/ > > Same here. Um, patches welcome? Don't little the report with useless comments please.
18 Sep 2011; Samuli Suominen <ssuominen@gentoo.org> pngcrush-1.7.17.ebuild: Error out in pkg_setup() with media-libs/libpng >= 1.5. It will now print a error that has reference to this bug. And everyone reading this bug: media-gfx/optipng has workaround for this same issue, you might want to use optipng until this bug is resolved
Is there a reason why we don't simply block on libpng-1.5?
(In reply to comment #8) > Is there a reason why we don't simply block on libpng-1.5? Nothing is allowed to downgrade libpng in the same stabilization level, be it stable or ~arch. This would show up as 'dependency conflict' and/or users had recompile some 100 other packages against libpng15, just to see pngcrush downgrade it back to libpng14, just to rebuild all the 100 packages all over again? So no... If needed be, pngcrush will be lastrited instead of adding such block.
(In reply to comment #7) > media-gfx/optipng has workaround for this same issue, you might want to use > optipng until this bug is resolved A just as simple workaround for everyone who thinks pngcrush will stay alive, is echo -e '\n# Block libpng 1.5 until pngcrush becomes compatible again.\n=media-libs/libpng-1.5*' >> /etc/portage/package.mask/temp (In reply to comment #9) > This would show up as 'dependency conflict' and/or users had recompile some 100 > other packages against libpng15, just to see pngcrush downgrade it back to > libpng14, just to rebuild all the 100 packages all over again? Not for those who didn’t emerge @preserved-rebuild or revdep-rebuild before adding the above blockage. In fact it would save them from having to recompile those 100 packages at all. :) But everyone has to decide this for himself. Gentoo (and open-source software in general) has no “authorities”, no matter how much certain people say otherwise.
(In reply to comment #10) > (In reply to comment #7) > > media-gfx/optipng has workaround for this same issue, you might want to use > > optipng until this bug is resolved > > A just as simple workaround for everyone who thinks pngcrush will stay alive, > is > > echo -e '\n# Block libpng 1.5 until pngcrush becomes compatible > again.\n=media-libs/libpng-1.5*' >> /etc/portage/package.mask/temp This would break systems as =libpng-1.4.8-r2 would be out of scope from that mask, pulling only libpng14.so.14 from SLOT="1.4" as ABI compat, therefore not installing any headers or pkg-config file at all. So anyone: Don't do what Comment #10 says, and if you do, you are on your own.
Created attachment 289191 [details] pngcrush-1.7.17-r1.ebuild Please don't remove pngcrush, it's a valuable tool for many people. We can do it like we did with optipng: Use the bundled-library-version, which is upstream's default. A first shot for a bundled-libpng ebuild is attached, however upstream makefile seems to lack CFLAGS, CC and LDFLAGS-support. I'll see if I find time later to work on that. We had our own makefile in the past instead of improving upstream's one, which is probably a bad idea anyway.
It's not like this came as suprise, with bug dating back to 2011-02-22. I'm fine with switching to bundled libpng14 for now, but I'm not going to work on it either. Feel free to unmask once this is worked around, or solved. Then you just have to decide if you want 0day stabilization request for bug 384701 or leave it ~arch only.
committed -r1 with fix.
no... bundling libpng14 is not a fix
Also, why did you make pngcrush use bundled zlib? The zlib was never a problem, libpng is.
I masked the package once again. Using bundled libs is not a proper fix and your introduces a new problem by using the bundled zlib. Before unmasking contact qa@gentoo.org ( CC me on the email )
You're making this really complicated... I wasn't aware that it's also bundling zlib. Committed -r2 that bundles libpng and unbundles zlib. Okay now? (yes, I'm well aware that bundling is not a good solution - but removing an important package isn't either)
No it's not okay. libpng-1.4 could get another security issue and we'll be screwed. Have anybody even tried to contact upstream? If they are still alive they'll fix it. Otherwise this is still to be last-rited unless somebody cares to fix it. I can't believe it's so impossible to fix it...
Upstream is aware of the issue and alive. He seems to give this low priority as the bundled version is the default. As I said, I'm all aware of the issues with bundled libraries, but I think if libpng 1.4 has security issues, there will be libpng 1.4 fixes for it and we can apply them (and I volunteer to take care of that). As upstream is alive and active, he'll probably take care of them anyway. I know bundled libraries suck, but we have them in a lot of places, because upstreams don't care. It's exactly the same solution we have for optipng.
Upstream's reply, no big surprise: >For now use the full version (with the bundled libpng-1.5 and zlib), not >the "nolib" version. It uses libpng private functions and therefore won't >work with a DLL or shared library. I'll unmask pngcrush again tomorrow if nobody objects. If you object, please suggest a better solution. Removing an important app without an alternative is no solution.
(In reply to comment #21) > Upstream's reply, no big surprise: > > >For now use the full version (with the bundled libpng-1.5 and zlib), not > >the "nolib" version. It uses libpng private functions and therefore won't > >work with a DLL or shared library. > > I'll unmask pngcrush again tomorrow if nobody objects. If you object, please > suggest a better solution. Removing an important app without an alternative is > no solution. The package is NOT NOT NOT masked for removal but for proper fixing. I keep saying that over and over. So please don't unmask it cause we wont remove it anyway. I already state in the masking message (and in this bug a few comments above) to contact QA (and CC me) if you need to take any further action on this package
Thanks to upstream, this is now solved in 1.7.18. Like, _properly solved_.
