NetworkManager applet shows a red filled circle with a white dash in it, my TTY is getting spammed with the message in the bug summary; a quick google for that yields this has to do with the libpng 1.6 upgrade. If needed, feel free to reassign to the libpng maintainers since this then may be a regression for them.
I've googled the mailing list thread and saw this reply from Mark Adler (zlib upstream) in it: "Those files are in fact broken, in that the zlib header says that a 512-byte window is ok, but the maximum distance found in all of them is 1419. That would require at least a 2048-byte window. For zlib to detect this, it has to be compiled with INFLATE_STRICT defined. The default compilation of zlib does not check for strict compliance of the compressed data to the specified window size. zlib will report an error if it has to look further back than the sliding window it has retained, but if it has the data that far back available, it will use it. These files are one example of that case, where there would very likely be enough output space provided to decompress in a single step (all are less than 2K decompressed), so that a sliding window is never even created. In that case, all of the output is available, and zlib can correctly decompress the input, even if windowBits == 9 is specified. As I recall, INFLATE_STRICT was added specifically at the request of the PNG community. Mark" I'm puzzled what "Those files are in fact broken" in facts means for us. In the same thread Glenn mentions latest pngcrush "fixing" the files. I'll ask them by mail if this is something that is going to be fixed in libpng or not, or if we should "fix" the files.
Created attachment 345742 [details] nm-signal-75.png icons/22/nm-signal-75.png from network-manager-applet-0.9.6.4 tarball
This is the reply from Glenn I got, "You can fix them with the current version of pngcrush, built with libpng-1.5.15, or for that matter most any image editor/converter built with libpng-1.5.15 or earlier will write them with the proper zlib headers. Reverting to libpng-1.5.15 works because this actually allocates a 32k window regardless of what CMF asks for." So it seems this will not be fixed in libpng and the files are really broken and it's an bug in nm-applet because of it.
Created attachment 345816 [details, diff] nm-applet-0.9.8.0.ebuild.patch Upgrade pngcrush to 1.7.57 with USE="-system-libs" and you can for example `pngcrush -fix -force nm-signal-00.png nm-signal-00.png.new` I've done that for you and rolled them into .tar.xz: http://dev.gentoo.org/~ssuominen/pngcrush-fixed-nm-signal-icons.tar.xz
The ebuild patch is untested, but I'm sure you will notice :-)
Okay, will try this tomorrow and let you know.
Reported to upstream: https://bugzilla.gnome.org/show_bug.cgi?id=698286
Fixed upstream: https://git.gnome.org/browse/network-manager-applet/commit/icons/22?id=43a3480460aa3db2738630a0b8bc91f34c1d2be3
Created attachment 346084 [details] List of broken PNGs I'll attach a list of broken PNGs on my system. I've already removed the obviously-on-our-problem ones (e.g. /home/**). Not all of the rest re claimed by packages. I'll also attach a list of packages-with-files for the claimed files as soon as I have it.
Comment on attachment 346084 [details] List of broken PNGs This file list is incorrect since convert sees invalid ICC profiles as "broken". I'll remake the list.
Created attachment 346088 [details] parallel PNG checker New and improved parallel checker attached. Output for my system: # locate png |grep \\.png$ | ~klausman/pngfixer.py Checked 54637 files in 165.99 seconds, 329.15 files/s. 4 files need fixing. /usr/share/icons/hicolor/16x16/apps/smplayer.png /usr/share/icons/hicolor/22x22/apps/smplayer.png /usr/share/icons/hicolor/32x32/apps/smplayer.png /usr/share/icons/hicolor/64x64/apps/smplayer.png # Will file an smplayer bug blocking this one.
Created attachment 346192 [details] List of distfiles + packages containing/using broken PNGs I've made a copy of a distfile mirror and checked all distfiles if they contain broken PNGs (only broken in the sense of this bug). Attached is a list of them. Since we're talking about 232 distfiles in almost 100 packages, I'd very much prefer filing the corresponding bugs autmatically, not by hand. Unfortunately, I have no experience scripting bug submission and I'm out of time for today. Feel free to pick up where I left.
Addendum: the KDE packages are a bit messy in that file. I think we should file a master bug with the KDE team since figuring out what is used by which package is tricky.
+ 03 May 2013; Samuli Suominen <ssuominen@gentoo.org> nm-applet-0.9.6.4.ebuild, + nm-applet-0.9.8.0.ebuild: + Fix nm-signal-*.png icons with media-gfx/pngcrush built against libpng15 for + -fix -force to correct IDAT lenght wrt #466190 Futher discussion happens in bug 468386 if needed, let's stop bugspamming the nm-applet maintainer now ;)
(In reply to Samuli Suominen from comment #14) > + 03 May 2013; Samuli Suominen <ssuominen@gentoo.org> > nm-applet-0.9.6.4.ebuild, > + nm-applet-0.9.8.0.ebuild: > + Fix nm-signal-*.png icons with media-gfx/pngcrush built against libpng15 > for > + -fix -force to correct IDAT lenght wrt #466190 > > Futher discussion happens in bug 468386 if needed, let's stop bugspamming > the nm-applet maintainer now ;) great work
