[arch-dev-public] Some PNG images won't work with libpng 1.6
After moving the libpng 1.6 rebuilds to [testing], I noticed that some PNG icons wouldn't load. In my case the broken icons belonged to nm-applet and smplayer (both have been fixed in [extra]). Some KDE components are probably affected but I'm not sure of the extend there. The plan is to run a check on the source files of all packages to better assess the situation. (pngchecker.py can be used for that.¹) It's not clear whether future libpng 1.6.x versions will be able to load these, apparently invalid, PNG images.² Running optipng (which is statically compiled against libpng 1.4) seems to fix the problematic PNG files. I have used this workaround in smplayer.³ More information can be found in Gentoo's discussion about this issue: http://www.gossamer-threads.com/lists/gentoo/dev/271064 ¹ https://bugs.gentoo.org/show_bug.cgi?id=466190#c11 ² https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c3 ³ https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/smplayer&id=83c83d34c8872cd29ee256a5485e64f87814fc43
On 3 May 2013 14:36, Evangelos Foutras <evangelos@foutrelis.com> wrote:
The plan is to run a check on the source files of all packages to better assess the situation. (pngchecker.py can be used for that.¹)
Quick note so that no one else spends time on this; I have gathered all PNG files from every source package and I will post a list of invalid PNGs and the respective packages tomorrow.
On 03/05/13 14:36, Evangelos Foutras wrote:
After moving the libpng 1.6 rebuilds to [testing], I noticed that some PNG icons wouldn't load. In my case the broken icons belonged to nm-applet and smplayer (both have been fixed in [extra]).
Some KDE components are probably affected but I'm not sure of the extend there.
The plan is to run a check on the source files of all packages to better assess the situation. (pngchecker.py can be used for that.¹)
So, not many packages are affected after all: https://dev.archlinux.org/~foutrelis/invalid-pngs-report/ I think we should wait a bit for the libpng maintainer to say whether the invalid PNGs will be readable again in a future libpng version. If not, we can go ahead and fix the affected packages. I've asked him (Glenn) here: https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c9
Tentatively, should we just run the fixer for the affected packages and push them to testing (so visuals don't break all of a sudden after updates)? Whether the maintainer says anything or not, we're gonna have to move stuff out from testing anyway. Thanks for taking the trouble to look into this. On 4 May 2013 14:25, Evangelos Foutras <evangelos@foutrelis.com> wrote:
On 03/05/13 14:36, Evangelos Foutras wrote:
After moving the libpng 1.6 rebuilds to [testing], I noticed that some PNG icons wouldn't load. In my case the broken icons belonged to nm-applet and smplayer (both have been fixed in [extra]).
Some KDE components are probably affected but I'm not sure of the extend there.
The plan is to run a check on the source files of all packages to better assess the situation. (pngchecker.py can be used for that.น)
So, not many packages are affected after all:
https://dev.archlinux.org/~foutrelis/invalid-pngs-report/
I think we should wait a bit for the libpng maintainer to say whether the invalid PNGs will be readable again in a future libpng version. If not, we can go ahead and fix the affected packages.
I've asked him (Glenn) here:
-- GPG/PGP ID: C0711BF1
Am 04.05.2013 09:38, schrieb Rashif Ray Rahman:
Tentatively, should we just run the fixer for the affected packages and push them to testing (so visuals don't break all of a sudden after updates)? Whether the maintainer says anything or not, we're gonna have to move stuff out from testing anyway.
Thanks for taking the trouble to look into this.
On 4 May 2013 14:25, Evangelos Foutras <evangelos@foutrelis.com> wrote:
On 03/05/13 14:36, Evangelos Foutras wrote:
After moving the libpng 1.6 rebuilds to [testing], I noticed that some PNG icons wouldn't load. In my case the broken icons belonged to nm-applet and smplayer (both have been fixed in [extra]).
Some KDE components are probably affected but I'm not sure of the extend there.
The plan is to run a check on the source files of all packages to better assess the situation. (pngchecker.py can be used for that.น)
So, not many packages are affected after all:
https://dev.archlinux.org/~foutrelis/invalid-pngs-report/
I think we should wait a bit for the libpng maintainer to say whether the invalid PNGs will be readable again in a future libpng version. If not, we can go ahead and fix the affected packages.
I've asked him (Glenn) here:
Imho libpng should continue to accept these files if it did in the past. While we can easily fix local packages we cant fix all the others people might find on the net or on websites. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
On 04/05/13 10:38, Rashif Ray Rahman wrote:
Tentatively, should we just run the fixer for the affected packages and push them to testing (so visuals don't break all of a sudden after updates)? Whether the maintainer says anything or not, we're gonna have to move stuff out from testing anyway.
I'd like to move the packages out of testing too, so I created a todo list to fix the problematic packages: https://www.archlinux.org/todo/fix-invalid-pngs-for-libpng-16/ I left out some packages that shouldn't need to be fixed. (Unused PNGs that only exist in the source files.) It'd also be nice to push the fixed PNGs upstream so we can drop our manual fixing in future versions. This would only be worthwhile for actively maintained software (in my opinion).
On Sat, May 4, 2013 at 2:22 PM, Evangelos Foutras <evangelos@foutrelis.com>wrote:
On 04/05/13 10:38, Rashif Ray Rahman wrote:
Tentatively, should we just run the fixer for the affected packages and push them to testing (so visuals don't break all of a sudden after updates)? Whether the maintainer says anything or not, we're gonna have to move stuff out from testing anyway.
I'd like to move the packages out of testing too, so I created a todo list to fix the problematic packages:
https://www.archlinux.org/todo/fix-invalid-pngs-for-libpng-16/
I left out some packages that shouldn't need to be fixed. (Unused PNGs that only exist in the source files.)
It'd also be nice to push the fixed PNGs upstream so we can drop our manual fixing in future versions. This would only be worthwhile for actively maintained software (in my opinion).
I'm in the process of fixing kdelibs3. I notice that optipng doesn't fix all png files. Some are still broken after running optipng on them. I still need to figure out how to fix them (maybe I need to use an optipng option). This is just a heads up.
On 5 May 2013 01:31, Eric Bélanger <snowmaniscool@gmail.com> wrote:
I'm in the process of fixing kdelibs3. I notice that optipng doesn't fix all png files. Some are still broken after running optipng on them. I still need to figure out how to fix them (maybe I need to use an optipng option). This is just a heads up.
I use the following in prepare(): find -name '*.png' -exec optipng -quiet -force -fix {} + Without -force it might choose not to optimize (and thus fix) a file. I'll add it to the todo description.
On Sun, May 5, 2013 at 1:15 AM, Evangelos Foutras <evangelos@foutrelis.com>wrote:
I'm in the process of fixing kdelibs3. I notice that optipng doesn't fix all png files. Some are still broken after running optipng on them. I still need to figure out how to fix them (maybe I need to use an optipng
On 5 May 2013 01:31, Eric Bélanger <snowmaniscool@gmail.com> wrote: option).
This is just a heads up.
I use the following in prepare():
find -name '*.png' -exec optipng -quiet -force -fix {} +
Without -force it might choose not to optimize (and thus fix) a file.
I'll add it to the todo description.
Thanks. That worked.
On 4 May 2013 07:25, Evangelos Foutras <evangelos@foutrelis.com> wrote:
So, not many packages are affected after all:
I've fixed the problematic file in hugin in upstream repository: http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/rev/81e8750b3813 That file is not really important (AFAIK it's only a logo in the offline help), so I don't think there is an actual need to fix this in a PKGBUILD.
On 3 May 2013 14:36, Evangelos Foutras <evangelos@foutrelis.com> wrote:
It's not clear whether future libpng 1.6.x versions will be able to load these, apparently invalid, PNG images.
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/127b08a265f99ce517ea31ec7988a91fc17d... I'll give it a go on the previously failing PNGs in a couple of hours.
On 06/05/13 09:12, Evangelos Foutras wrote:
On 3 May 2013 14:36, Evangelos Foutras <evangelos@foutrelis.com> wrote:
It's not clear whether future libpng 1.6.x versions will be able to load these, apparently invalid, PNG images.
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/127b08a265f99ce517ea31ec7988a91fc17d...
I'll give it a go on the previously failing PNGs in a couple of hours.
libpng 1.6.2-3 now contains the above upstream workaround. Once the fix is final and part of libpng 1.6.3, we can go ahead and drop the optipng workaround from the following already fixed packages: cinelerra-cv cinepaint digikam gnumeric hydrogen kadu kdelibs3 links scim smplayer-themes virtuoso Sorry for the slightly unnecessary rebuilds everyone.
On 6 May 2013 12:49, Evangelos Foutras <evangelos@foutrelis.com> wrote:
libpng 1.6.2-3 now contains the above upstream workaround.
And it's now in the stable repositories (along with the rebuilt packages).
On 06/05/13 09:12, Evangelos Foutras wrote:
On 3 May 2013 14:36, Evangelos Foutras <evangelos@foutrelis.com> wrote:
It's not clear whether future libpng 1.6.x versions will be able to load these, apparently invalid, PNG images.
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/127b08a265f99ce517ea31ec7988a91fc17d...
I'll give it a go on the previously failing PNGs in a couple of hours.
Unfortunately, this workaround won't make it into 1.6.3: https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c12 I've reinstated the todo list with the remaining 10 packages; these should be fixed before we update libpng to 1.6.3 (not yet released).
participants (5)
-
Eric Bélanger
-
Evangelos Foutras
-
Lukas Jirkovsky
-
Pierre Schmitz
-
Rashif Ray Rahman