Bug 185203 – jpeg support broken in latest build

Bug 185203 - jpeg support broken in latest build

Summary:	jpeg support broken in latest build

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	python-imaging (Show other bugs)
Sub Component:
Version:	5
Hardware:	x86_64 Linux

Priority	medium Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	José Matos
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2006-03-11 13:40 EST by Rick L Vinyard Jr
Modified:	2007-11-30 17:11 EST (History)
CC List:	2 users (show)

See Also:
Fixed In Version:	1.1.5-4
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2006-04-05 05:58:38 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
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
Add an attachment (proposed patch, testcase, etc.)

Groups: 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):
1.1.5-1

How reproducible:
Always

Steps to Reproduce:
1. Run python app that manipulates jpegs
2.
3.
  
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
support.

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.