List of broken PNGs provided by Tobias K. in bug 466190, Comment #12. More information in the same bug. http://bugs.gentoo.org/attachment.cgi?id=346192 Short version: Some PNG files that have broken IDAT are not viewable anymore with libpng16, and they need to be fixed. Latest ~arch pngcrush built with USE="-system-libs" can fix them using `pngcrush -force -fix`
You can also use png-fix-IDAT-windowsize from media-gfx/pngcheck which works independently of libpng. I'm currently preparing a new list of distfiles with broken packages, this time including all the package names&versions that use said distfile. It should be ready in a few hours (checking 1.5 million PNG files strewn across 55k distfiles of various formats takes a bit, even if you do it in parallel).
Created attachment 347306 [details] distfiles containing broken PNGs as of 03/May/2013 And here's the file
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/024890.html Looks like there's probably going to be a workaround in libpng 1.6.3: https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c10 The commit is the following: http://sourceforge.net/p/libpng/code/ci/127b08a265f99ce517ea31ec7988a91fc17da4d9/
Can't apply http://sourceforge.net/p/libpng/code/ci/127b08a265f99ce517ea31ec7988a91fc17da4d9 directly because it conflicts with the -apng.patch for libpng 1.6.2 Propably easiest to wait for libpng 1.6.3 and -apng.patch for it The workaround is propably not going to be there forever, so these files should be still fixed, in my opinion
There are some windows Programs with missing icons when app-emulation/wine is compiled with libpng-1.6. for example "Sigma Photo Pro 5" which has no alternative on Linux. Or another one would be the "Tangysoft Usenet Client". Also, wine gives console warnings (something like "wine is compiled with libpng16.so but using libpng15.so.15") when using libpng16 from slot 0. It gives that message regardless of the slot 1.5 libpng being installed. I reverted to libpng-1.5 in slot 0, recompiled wine and that solved the issue. Might that be a AMD64 only issue? Does a 32bit wine profile use the amd64 libpng? A viable solution that I could think off would be to depend and compile wine against media-libs/libpng:1.5 instead of libpng-1.6 from slot 0 for the time being. At least until wine is aware of that problem and has come up with some internal way of fixing pngs before giving them to libpng. That would be the only way, because we will not get all the windows devs to fix their PNGs. How should I proceed? Should I create a bug for wine and depend it on this one, libpng-1.6 metabug, or both?
(In reply to Johannes Schmidt from comment #5) > There are some windows Programs with missing icons when app-emulation/wine > is compiled with libpng-1.6. > for example "Sigma Photo Pro 5" which has no alternative on Linux. Or > another one would be the "Tangysoft Usenet Client". > > Also, wine gives console warnings (something like "wine is compiled with > libpng16.so but using libpng15.so.15") when using libpng16 from slot 0. It > gives that message regardless of the slot 1.5 libpng being installed. > > I reverted to libpng-1.5 in slot 0, recompiled wine and that solved the > issue. > > Might that be a AMD64 only issue? Does a 32bit wine profile use the amd64 > libpng? > > > A viable solution that I could think off would be to depend and compile wine > against media-libs/libpng:1.5 instead of libpng-1.6 from slot 0 for the time > being. At least until wine is aware of that problem and has come up with > some internal way of fixing pngs before giving them to libpng. That would be > the only way, because we will not get all the windows devs to fix their PNGs. > > How should I proceed? Should I create a bug for wine and depend it on this > one, libpng-1.6 metabug, or both? All of this is unrelated to this bug. To build 32bit wine on 64bit versions of 32bit and 64bit libpng must match, the current libpng version in emul- packages is 1.5 Anyway, out of topic for this bug
Ah, ok. That's why I postet the question here, before opening a bug in the wrong place. I will probably open a bug concerning the emul- libs at some point though, if it will not resolve by itself once libpng-1.6 makes it into emul-libs. Thanks for the advice.
okay, libpng 1.6.3 is out and has official utilities to fix the broken images: $ qlist libpng |grep bin.*fix /usr/bin/png-fix-itxt /usr/bin/pngfix $ qlist libpng |grep bin.*fix /usr/bin/png-fix-itxt /usr/bin/pngfix ssuominen@null ~/gentoo-x86/kde-base/libkdcraw $ pngfix --help Usage: pngfix {[options] png-file} Tests, optimizes and optionally fixes the zlib header in PNG files. Optionally, when fixing, strips ancilliary chunks from the file.
there is a tool shipped with libpng-1.6.3 that helps out I made a small bashscipt to fix boswars files for i in $(find . -iname '*.png'); do pngfix -q ${i}; if [[ $? -eq 1 ]]; then echo ${i} broken ; pngfix -q --out=${i/.png/_fixed.png} ${i} ; pngfix -q ${i/.png/_fixed.png} ; if [[ $? -eq 0 ]]; then echo "${i} fixed successfully" ;mv ${i/.png/_fixed.png} ${i};fi; fi ; done
reassign to qa@ as this isn't anymore a base-system@ issue, as this is a problem tree wide in random packages
after discussion with ulm, I'm closing this bug as RESOLVED, FIXED, and let people file bugs in their own pace if they notice broken images in their packages, since most major packages have already been fixed (firefox, networkmanager, and such)
For reference: http://sourceforge.net/p/libpng/code/ci/5a1d1b5369135b13e97c5c255b1fea4467a9ea34/ "[libpng16] Do not reject ICC V2 profiles that lack padding" Yeah.
