Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
On 04/22/13 13:03, Tobias Klausmann wrote: Hi! Since we probably will have to fix the files coming out of tarballs until the various upstreams have fixed them, I propose running a PNG fixer during or after the install phase. Since having pngcrush as dep for everything is not exactly lightweight, I hacked together a PNG file fixer in pure(ish, see below) Python: No please, this real should stay really far from any package manager. There are only two sane options: 1) fix libpng to be backward compatible 2) fix the package, and re-package / add a package for broken images But please don't push on all our user systems something like this. http://git.schwarzvogel.de/?p=pngfixer;a=summary Feel free to send patches Note that all I wrote is the mind-numbingly simple pngfixer.py script. The rest of the Python code is excised from PIL (http://www.pythonware.com/products/pil/index.htm). I didn't have to change anything there. Also note that it is not _strictly_ pure Python I'm using: the PIL components use Python's zlib.so and therefore are subject to bugs in _that_ code. Thanks for taking the time to write this it could be useful for developers, but hopefully not as initially intended ;-) Still needed: - How do we ship this? - How do we run it for every ebuild? (probably something like find /var/tmp/portage/.../image/ -iname \*.png -exec {...}\;) Regards, Tobias Regards, Francesco
Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
Hi! On Tue, 23 Apr 2013, Ulrich Mueller wrote: I appericiate the work done by Tobias utmost too but I have to agree this is not something I want to see running automatically, or even from within ebuilds. +1 In Tobias's list, I count some 80 packages that need fixing. That's way too few to merit a general solution. Also this number will decrease when files are fixed upstream. I see two problems with this approach: - What do we do with unresponsive-yet-not-dead upstreams? - What about future packages that ship broken files? I mean not just existing packages that keep issuing broken PNGs but also future packages that we just didn't cover now? The former has two and a half solutions: - Wait until itmagically fixes itself or upstream comes around. This is only 1/2 a solution, IMO. - Add a separate tarball or the like that the Gentoo maintainer generates from the broken PNGs. Use this tarball to overwrite the broken results of equivalent_of(make install). - Have a convenience function that can be used for known-bad packages to fix broken IDATs. Basically calling my script or the binary Samuli mentioned. The second problem, however, is trickier. We can rely on people noticing the error messages/broken packages and hope they file bugs. The other option is to have a QA-like check for it, again using the simplest possible binary to do so. Regards, Tobias