Bug 185203 - jpeg support broken in latest build
jpeg support broken in latest build
Product: Fedora
Classification: Fedora
Component: python-imaging (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: José Matos
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-03-11 13:40 EST by Rick L Vinyard Jr
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.1.5-4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-05 05:58:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Just to show where is the probl. (401 bytes, patch)
2006-03-27 14:35 EST, Stanislav Polasek
no flags Details | Diff
.spec patch (1.27 KB, patch)
2006-03-31 13:27 EST, Rick L Vinyard Jr
no flags Details | Diff
Modified Stanislav's patch (374 bytes, patch)
2006-03-31 13:30 EST, Rick L Vinyard Jr
no flags Details | Diff

  None (edit)
Description Rick L Vinyard Jr 2006-03-11 13:40:55 EST
Description of problem:
jpeg support in PIL is broken in the latest build... resulting in broken python
apps that use PIL for jpeg manipulation.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run python app that manipulates jpegs
Actual results:
PIL returns I/O error: no jpeg decoder available

Expected results:

Additional info:
Regression to 1.1.4-9 downgrades PIL to previous version, but has working jpeg
Comment 1 José Matos 2006-03-17 16:27:56 EST
It works for me. 
Could you give an example, please? 
If it fails could you install ImageMagick and use identify to give further 
details about those jpeg files: 
$ identify *.jpg 
As an example I run this in a directory full of jpeg images and I don't get 
any problem: 
import Image 
import glob 
for i in glob.glob("*.jpg"): 
    im[i] = Image.open(i) 
    print im[i].format, im[i].size, im[i].mode 
Comment 2 Stanislav Polasek 2006-03-27 14:35:24 EST
Created attachment 126844 [details]
Just to show where is the probl.
Comment 3 Stanislav Polasek 2006-03-27 14:36:02 EST
I have the same problem on the x86 platform. Trying rebuild the package, I got
error on the selftest.py phase. As I do not have much time to resolve this
issue, I just added explicitly the path to the /usr/lib64 libs to the setup.py
and recompiled the package. Please find atached "patch" for the details:
Comment 4 José Matos 2006-03-28 05:37:42 EST
Aha, now I see the problem only occurs in x86-64, and it is a problem related 
with /usr/lib/ versus /usr/lib64. 
Now that I have a clue I will fix this issue soon. 
Thank your for the patch. 
Comment 5 Rick L Vinyard Jr 2006-03-31 13:27:57 EST
Created attachment 127145 [details]
.spec patch

Modified .spec to apply modification of Stanislav's patch on x86_64.

Tested on x86_64 and fixes original bug.
Comment 6 Rick L Vinyard Jr 2006-03-31 13:30:31 EST
Created attachment 127146 [details]
Modified Stanislav's patch

Stripped directories so patch can be -p0 instead of -p3
Comment 7 José Matos 2006-04-05 06:02:50 EDT
I have applied a similar fix. The reason why I have not applied the patch 
proposed in this report is that this would give two different src.rpm 
depending on the arch used.

This fix is also in line with other python-* fixes applied to solved this type 
of problem, see python-crypto.

Thank you for the reports.

Note You need to log in before you can comment on or make changes to this bug.