Bug 878627

Summary: XloadIimage returns unsupported image for a PNG format
Product: [Fedora] Fedora Reporter: Panos Kavalagios <Panos.Kavalagios>
Component: xloadimageAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-03 03:24:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Tux in PNG format none

Description Panos Kavalagios 2012-11-20 19:39:13 UTC
Created attachment 648760 [details]
Tux in PNG format

Description of problem: The xloadimage does not load PNG images anymore. It produces an unsupported error.


Version-Release number of selected component (if applicable): xloadimage-4.1-9.fc17.x86_64


How reproducible: Attempt to load a PNG image


Steps to Reproduce:
1. Run xloadimage <image>
2.
3.
  
Actual results: The following error occurs:
"unknown or unsupported image type"


Expected results: The image should have been loaded.


Additional info: This is a blocking issue. The utility does not work at all. You cannot set background anymore in Fedora 17. It causes great inconvenience as all programs relied on xloadimage to set background do not work.

It seems to affect Fedora 17, as in Fedora 16 it works fine:

panos@hector:[103] ~/tmp > cat /etc/redhat-release 
Fedora release 17 (Beefy Miracle)
panos@hector:[104] ~/tmp > rpm -q xloadimage
xloadimage-4.1-9.fc17.x86_64
panos@hector:[105] ~/tmp > xloadimage tux.png 
tux.png: unknown or unsupported image type

panos@pharmacy:[216] ~/tmp > cat /etc/redhat-release 
Fedora release 16 (Verne)
panos@pharmacy:[217] ~/tmp > rpm -q xloadimage
xloadimage-4.1-6.fc16.x86_64
panos@pharmacy:[218] ~/tmp > xloadimage tux.png 
tux.png is 400x479 PNG image, color type RGB_ALPHA, 8 bit
  Building XImage...done

Refusing to load Tux is a sacrilege against all Linux community in my opinion :)

Comment 1 Tom "spot" Callaway 2012-11-27 21:34:26 UTC
Whoops! Looks like I broke PNG support in Fedora 17. I've got a fix coming, please test it when it arrives!

Comment 2 Fedora Update System 2012-11-28 15:26:19 UTC
xloadimage-4.1-12.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xloadimage-4.1-12.fc17

Comment 3 Fedora Update System 2012-11-28 15:26:31 UTC
xloadimage-4.1-12.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xloadimage-4.1-12.fc18

Comment 4 Fedora Update System 2012-11-28 21:16:06 UTC
Package xloadimage-4.1-12.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xloadimage-4.1-12.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19336/xloadimage-4.1-12.fc18
then log in and leave karma (feedback).

Comment 5 Panos Kavalagios 2012-11-30 07:49:54 UTC
It works like a charm! Thanks Tom! You saved the penguin :)

panos@bb229:[206] ~/tmp > cat /etc/redhat-release
Fedora release 17 (Beefy Miracle)
panos@bb229:[207] ~/tmp > rpm -q xloadimage
xloadimage-4.1-12.fc17.x86_64
panos@bb229:[208] ~/tmp > xloadimage tux.png
tux.png is 400x479 PNG image, color type RGB_ALPHA, 8 bit
  Building XImage...done

Comment 6 Fedora Update System 2012-12-03 03:24:35 UTC
xloadimage-4.1-12.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2012-12-07 03:29:24 UTC
xloadimage-4.1-12.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.