Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

FYI: libpng16 won't be able to show some broken icons libpng15 was still able to

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


ssuominen at gentoo

Apr 18, 2013, 11:24 AM

Post #1 of 14 (1320 views)
Permalink
FYI: libpng16 won't be able to show some broken icons libpng15 was still able to

Short version:

If you see "PNG IDAT errors" like:

program: IDAT: invalid distance too far back `test1.png' @

WARNING **: Icon test1 missing: (0) Fatal error reading PNG image file:
Decompression error in IDAT

Then you should use >=media-gfx/pngcrush-1.7.57 built with
USE="-system-libs" to it's using libpng 1.5.15 to correct the IDAT in
the .png files using command:

$ pngcrush -fix -force old.png new.png

These bogus images were visible with libpng15 and earlier but now that
improved code was committed these bogus files stopped showing as a
side-effect. If I understood correct this is not going to be fixed in
the library itself. Caused by slightly bad combination of libpng and
zlib and some tool.

Long version:

http://bugs.gentoo.org/466190
http://bugzilla.gnome.org/show_bug.cgi?id=698286
+ the ML links mentioned in the bugs

Figured this is useful for every maintainer to know.


axs at gentoo

Apr 18, 2013, 11:38 AM

Post #2 of 14 (1293 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/04/13 02:24 PM, Samuli Suominen wrote:
> Short version:
>
> If you see "PNG IDAT errors" like:
>
> program: IDAT: invalid distance too far back `test1.png' @
>
> WARNING **: Icon test1 missing: (0) Fatal error reading PNG image
> file: Decompression error in IDAT
>
> Then you should use >=media-gfx/pngcrush-1.7.57 built with
> USE="-system-libs" to it's using libpng 1.5.15 to correct the IDAT
> in the .png files using command:
>
> $ pngcrush -fix -force old.png new.png
>
> These bogus images were visible with libpng15 and earlier but now
> that improved code was committed these bogus files stopped showing
> as a side-effect. If I understood correct this is not going to be
> fixed in the library itself. Caused by slightly bad combination of
> libpng and zlib and some tool.
>
> Long version:
>
> http://bugs.gentoo.org/466190
> http://bugzilla.gnome.org/show_bug.cgi?id=698286 + the ML links
> mentioned in the bugs
>
> Figured this is useful for every maintainer to know.
>


Is this related to the mozilla issue too? ie, should the mozilla herd
just fix and supply a 'loading' icon until upstream updates theirs?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlFwPbcACgkQ2ugaI38ACPBmfwD7BIgai/x6GWiGC9KWY7cidnLW
jqwc4BbEnYsHfq7DiAIA/Rny5+nmqiszE6GVYmpX17VP6G6RRsg7hzKRLvW7luIJ
=pr0x
-----END PGP SIGNATURE-----


realnc at gmail

Apr 18, 2013, 11:53 PM

Post #3 of 14 (1277 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

On 18/04/13 21:24, Samuli Suominen wrote:
> Short version:
>
> If you see "PNG IDAT errors" like:
>
> program: IDAT: invalid distance too far back `test1.png' @
>
> WARNING **: Icon test1 missing: (0) Fatal error reading PNG image file:
> Decompression error in IDAT

Many of the KDE icons won't display anymore here (for example running
SMPlayer results in many icons missing from the default interface.) I
suppose there's no workaround other than downgrading libpng?


ssuominen at gentoo

Apr 18, 2013, 11:58 PM

Post #4 of 14 (1279 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

On 18/04/13 21:38, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 18/04/13 02:24 PM, Samuli Suominen wrote:
>> Short version:
>>
>> If you see "PNG IDAT errors" like:
>>
>> program: IDAT: invalid distance too far back `test1.png' @
>>
>> WARNING **: Icon test1 missing: (0) Fatal error reading PNG image
>> file: Decompression error in IDAT
>>
>> Then you should use >=media-gfx/pngcrush-1.7.57 built with
>> USE="-system-libs" to it's using libpng 1.5.15 to correct the IDAT
>> in the .png files using command:
>>
>> $ pngcrush -fix -force old.png new.png
>>
>> These bogus images were visible with libpng15 and earlier but now
>> that improved code was committed these bogus files stopped showing
>> as a side-effect. If I understood correct this is not going to be
>> fixed in the library itself. Caused by slightly bad combination of
>> libpng and zlib and some tool.
>>
>> Long version:
>>
>> http://bugs.gentoo.org/466190
>> http://bugzilla.gnome.org/show_bug.cgi?id=698286 + the ML links
>> mentioned in the bugs
>>
>> Figured this is useful for every maintainer to know.
>>
>
>
> Is this related to the mozilla issue too? ie, should the mozilla herd
> just fix and supply a 'loading' icon until upstream updates theirs?

nope, that is different problem and will be fixed (AFAICS)


ssuominen at gentoo

Apr 19, 2013, 5:35 AM

Post #5 of 14 (1276 views)
Permalink
Re: Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

On 19/04/13 09:53, Nikos Chantziaras wrote:
> On 18/04/13 21:24, Samuli Suominen wrote:
>> Short version:
>>
>> If you see "PNG IDAT errors" like:
>>
>> program: IDAT: invalid distance too far back `test1.png' @
>>
>> WARNING **: Icon test1 missing: (0) Fatal error reading PNG image file:
>> Decompression error in IDAT
>
> Many of the KDE icons won't display anymore here (for example running
> SMPlayer results in many icons missing from the default interface.) I
> suppose there's no workaround other than downgrading libpng?
>
>

Nope, but it's not clear from your post if we are even discussing the
same problem...

Identify the file(s), match the files to package(s), and file a bug

- Samuli


1i5t5.duncan at cox

Apr 19, 2013, 2:00 PM

Post #6 of 14 (1282 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

Nikos Chantziaras posted on Fri, 19 Apr 2013 09:53:12 +0300 as excerpted:

> On 18/04/13 21:24, Samuli Suominen wrote:
>> Short version:
>>
>> If you see "PNG IDAT errors" like:
>>
>> program: IDAT: invalid distance too far back `test1.png' @
>>
>> WARNING **: Icon test1 missing: (0) Fatal error reading PNG image file:
>> Decompression error in IDAT
>
> Many of the KDE icons won't display anymore here (for example running
> SMPlayer results in many icons missing from the default interface.) I
> suppose there's no workaround other than downgrading libpng?

Hmm. smplayer2 works/looks fine here. (smplayer2, not smplayer, here.)

I think I've seen the error a couple times in konsole (stdout/stderr)
output, but as anyone who often runs kde apps from konsole surely knows,
kde apps tend to be incredibly noisy on stdout/stderr anyway, and that
was before this whole thread, so I just though it was kde being kde.

But I certainly haven't noticed a problem on ~arch, running kde
4.10.49.9999 (live-4.10-branch, updated a couple times a week) from the
gentoo/kde overlay, along with libpng-1.6.1-r1, according to equery.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman


klausman at gentoo

Apr 22, 2013, 4:03 AM

Post #7 of 14 (1260 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

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:

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.

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


vivo75 at gmail

Apr 23, 2013, 3:24 AM

Post #8 of 14 (1251 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply 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


ssuominen at gentoo

Apr 23, 2013, 3:33 AM

Post #9 of 14 (1255 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

On 23/04/13 13:24, vivo75 [at] gmail wrote:
> 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.

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.

Perhaps if upstream writes the minimalized C version with no
dependencies (or with only libpng dependency), we could add custom
fix_IDAT() function but even then I'd prefer we fix the packages instead
for SRC_URI=

Trying to push time for going through some of the packages at:
https://bugs.gentoo.org/show_bug.cgi?id=466190#c12

But help is needed and I bet some maintainers don't want others messing
with their packages in the first place.
The fix is the mentioned script OR pngcrush with USE="-system-libs" and
`pngcrush -fix -force`

>
>>
>> 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 ;-)

+1+1+1

Thanks everyone,

- Samuli


ulm at gentoo

Apr 23, 2013, 3:53 AM

Post #10 of 14 (1253 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

>>>>> On Tue, 23 Apr 2013, Samuli Suominen 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.

Ulrich


klausman at gentoo

Apr 23, 2013, 4:19 AM

Post #11 of 14 (1253 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply 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


ssuominen at gentoo

Apr 23, 2013, 4:24 AM

Post #12 of 14 (1254 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

On 23/04/13 14:19, Tobias Klausmann wrote:
> bugs. The other option is to have a QA-like check for it, again
> using the simplest possible binary to do so.

Now that you said it... "QA"

Have your script (the one you generated the current list with) to
generate it to http://qa-reports.gentoo.org/
Like once a week now and once a month later
That'd be awesome, imho


waltdnes at waltdnes

Apr 23, 2013, 11:14 AM

Post #13 of 14 (1257 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

On Tue, Apr 23, 2013 at 01:19:05PM +0200, Tobias Klausmann wrote

> 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.

Will those messages be during the ebuild? There are currently
messages like...

> QA Notice: Package triggers severe warnings which indicate that it
> may exhibit random runtime failures.
> ExtensionSubtables.cpp:32:31: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
>
> Please do not file a Gentoo bug and instead report the above
> QA issues directly to the upstream developers of this software.
> Homepage: http://www.icu-project.org/

A similar message, about non-displaying icons instead of "random
runtime failures" may be in order. At the very least, it will let end
users know who to report the problem to.

--
Walter Dnes <waltdnes [at] waltdnes>
I don't run "desktop environments"; I run useful applications


klausman at gentoo

Apr 24, 2013, 3:47 AM

Post #14 of 14 (1249 views)
Permalink
Re: FYI: libpng16 won't be able to show some broken icons libpng15 was still able to [In reply to]

Hi!

On Tue, 23 Apr 2013, Walter Dnes wrote:
> On Tue, Apr 23, 2013 at 01:19:05PM +0200, Tobias Klausmann wrote
> > 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.
>
> Will those messages be during the ebuild? There are currently
> messages like...
>
> > QA Notice: Package triggers severe warnings which indicate that it
> > may exhibit random runtime failures.
> > ExtensionSubtables.cpp:32:31: warning: dereferencing type-punned
> > pointer will break strict-aliasing rules
> >
> > Please do not file a Gentoo bug and instead report the above
> > QA issues directly to the upstream developers of this software.
> > Homepage: http://www.icu-project.org/
>
> A similar message, about non-displaying icons instead of "random
> runtime failures" may be in order. At the very least, it will let end
> users know who to report the problem to.

Exactly. I'd envision something like this:

[snip]
QA Notice: Package installs broken PNG files that may cause
warnings, errors or fail to display completely.
[... list of bad PNGs ...]
See http://to-be-written-page/ for more information
on how to fix these files.

Please do not file a Gentoo bug and instead report the above
QA issues directly to the upstream developers of this
software. Homepage: http://project-homepage/
[pins]

Regards,
Tobias

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.