Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to

2013-04-23 Thread viv...@gmail.com
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

2013-04-23 Thread Tobias Klausmann
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