Description of problem: I am using ruby-tk to display images and installed tkimg. This places the image handlers in /usr/lib64/tcl8.5/Img1.4. However, errors are raised for some image types such as PNG. The following is a typical error report, from my calco program. /usr/share/ruby/tk.rb:2049:in `_invoke': invalid after png_start_read_image or png_read_update_info (RuntimeError) from /usr/share/ruby/tk.rb:2049:in `_ip_invoke_core' from /usr/share/ruby/tk.rb:2085:in `_tk_call_core' from /usr/share/ruby/tk.rb:2113:in `tk_call_without_enc' from /usr/share/ruby/tk/image.rb:80:in `initialize' from /usr/share/ruby/tk/image.rb:191:in `initialize' from /usr/share/ruby/tk/image.rb:58:in `block (2 levels) in new' from /usr/share/ruby/tk/image.rb:57:in `synchronize' from /usr/share/ruby/tk/image.rb:57:in `block in new' from /usr/share/ruby/tk/image.rb:56:in `instance_eval' from /usr/share/ruby/tk/image.rb:56:in `new' from /home/lcl/bin/calco:65:in `<module:Codes>' from /home/lcl/bin/calco:49:in `<main>' I wrote a trivial ruby script to test particular image formats and found that JPEGs displayed fine but the same jpg file converted to png failed. As a hack I copied the handler files from a Mageia 3 system to the Img1.4 directory and everything worked fine. Differences were apparent, as the following excerpts show. [root@canopus Img1.4]# diff libpngtcl1.4.3.so /usr/lib64/Img1.4/libpngtcl1.4.3.so Binary files libpngtcl1.4.3.so and /usr/lib64/Img1.4/libpngtcl1.4.3.so differ [root@canopus Img1.4]# ls -l /usr/lib64/Img1.4/libpngtcl1.4.3.so -rwxr-xr-x 1 root root 23408 Feb 3 01:13 /usr/lib64/Img1.4/libpngtcl1.4.3.so* [root@canopus Img1.4]# ls -l libpngtcl1.4.3.so -rwxr--r-- 1 root root 249546 May 13 2012 libpngtcl1.4.3.so* [root@canopus Img1.4]# diff libjpegtcl8.2.so /usr/lib64/Img1.4/libjpegtcl8.2.so Binary files libjpegtcl8.2.so and /usr/lib64/Img1.4/libjpegtcl8.2.so differ [root@canopus Img1.4]# ls -l /usr/lib64/Img1.4/libjpegtcl8.2.so -rwxr-xr-x 1 root root 15216 Feb 3 01:13 /usr/lib64/Img1.4/libjpegtcl8.2.so* [root@canopus Img1.4]# ls -l libjpegtcl8.2.so -rwxr--r-- 1 root root 338221 May 13 2012 libjpegtcl8.2.so* Most of the difference must be attributed to the fact that my originals are not stripped. They came from a Mandriva RPM some time ago. <Mandriva (Mageia 3) tkimg> [root@canopus Img1.4]# file libjpegtcl8.2.so libjpegtcl8.2.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=661071e50d2b28517ae8b26c5a136f965d1537f6, not stripped <Mageia 4 tkimg> [root@canopus Img1.4]# file /usr/lib64/Img1.4/libjpegtcl8.2.so /usr/lib64/Img1.4/libjpegtcl8.2.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7db97b1c6e0b03820bc6fae8783d440b93c639d8, stripped <Mandriva (Mageia 3) tkimg> [root@canopus Img1.4]# file libpngtcl1.4.3.so libpngtcl1.4.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3fa9b0a2517fe6d56667367f9df0ed415571b055, not stripped <Mageia 4 tkimg> [root@canopus Img1.4]# file /usr/lib64/Img1.4/libpngtcl1.4.3.so /usr/lib64/Img1.4/libpngtcl1.4.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5496d8c22641d183589dc76baafd6de4aba191b0, stripped Errors in the source code? Or missing or mismatched packages/libraries in the build? I doubt if the ruby code is at fault. As far as I can understand it it sends messages to tk to invoke the required image handlers and since it works for the older tkimg build it should continue to work. Sorry for the length of this spiel. Version-Release number of selected component (if applicable): 1.4 How reproducible: always Steps to Reproduce: 1. Run program or script which creates a Tk photoimage from a PNG file 2. Note the error report 3. Reproducible: Steps to Reproduce:
Keywords: (none) => TriagedAssignee: bugsquad => joequant
This little script should be sufficient to test an update for the tkimg handlers. Replace the image specification by anything suitable and chmod +x the script. #!/usr/bin/env wish package require Tk package require Img wm title . "Image test" wm geometry . "+400+300" image create photo icon -file "/home/lcl/images/icons/file-manager.png" label .label .label configure -image icon pack .label
The RPM I installed the successfull package from was: tkimg-1.4-0.20081115.1mdv2010.1.x86_64.rpm by Funda Wang (tkimg-devel-1.4-0.20081115.1mdv2010.1.x86_64.rpm) But note that it was built for tcl8.6 as opposed to our current tcl8.5 but it works fine for me. I had to juggle a bit and copy them to /usr/lib64/tcl8.5/Img1.4.
I found this workaround which keeps the tk code more up-to-date, at the expense of efficiency. Downloaded tkpng0.9.tgz from Sourceforge and built the libtkpng0.9.so library locally and copied it to /usr/lib(64)/tcl8.5/Img1.4 and in the same directory modified the pkgIndex.tcl file by adding package ifneeded tkpng 0.9 \ [list load [file join $dir libtkpng0.9.so] tkpng] at the head of the file and commenting out any further references to png in the rest of the file. To make this work with ruby-tk the png.rb file in /usr/share/ruby/tkextlib/tkimg also needs to be modified: The line TkPackage.require('img::png', '1.3') needs to be replaced by # TkPackage.require('img::png', '1.3') TkPackage.require('tkpng')
A simple tcl script produced the same error as above and using the strings command I was able to trace the reference to "png_start_read_image or png_read_update_image" to the libpngtcl1.4.3.so library but have not been able to find the source code anywhere so cannot investigate it any further. Attaching script - replace image file with any PNG.
Created attachment 6155 [details] Tcl script to expose PNG image error
Fedora has an update for tkimg dated 2015-03-10 which addresses the png problem: tkimg-1.4-20.fc21. This has been built against tcl8.6. http://koji.fedoraproject.org/koji/buildinfo?buildID=619325
(In reply to Len Lawrence from comment #6) > Fedora has an update for tkimg dated 2015-03-10 which addresses the png > problem: tkimg-1.4-20.fc21. This has been built against tcl8.6. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=619325 I incorporated some of the changes from the Fedora package into this svn checkout of the Cauldron repository: « mgarepo checkout tkimg » Now it runs the test Wish program from https://bugs.mageia.org/show_bug.cgi?id=12596#c3 fine. Can you try to test it? I guess I can create a package for Mageia 4 in updates_testing.
CC: (none) => shlomif
(In reply to Shlomi Fish from comment #7) > (In reply to Len Lawrence from comment #6) > > Fedora has an update for tkimg dated 2015-03-10 which addresses the png > > problem: tkimg-1.4-20.fc21. This has been built against tcl8.6. > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=619325 > > I incorporated some of the changes from the Fedora package into this svn > checkout of the Cauldron repository: > > « > mgarepo checkout tkimg > » > > Now it runs the test Wish program from > https://bugs.mageia.org/show_bug.cgi?id=12596#c3 fine. Can you try to test > it? I guess I can create a package for Mageia 4 in updates_testing. It is now in tkimg-1.4-2.1: http://pkgsubmit.mageia.org/ Regards, -- Shlomi Fish
Thanks Shlomi, will try that first thing tomorrow.
Well I would have done but it has not arrived in QA yet.
(In reply to Len Lawrence from comment #10) > Well I would have done but it has not arrived in QA yet. I can see it here fine: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/x86_64/media/core/updates_testing/tkimg-1.4-2.1.mga4.x86_64.rpm What is your mirror? Regards, -- Shlomi Fish
I cannot remember which I last picked but I changed back to distrib-coffee and still no tkimg with Core Updates Testing enabled and the hdlist files updated. That sort of thing seems to happen from time to time. So I downloaded it from the link above and installed it. It works for PNG files now but I notice that all the images are darkened with respect to the same images viewed in eom, gqview and gwenview. The stock icons in my ruby-tk interfaces are also noticeably darkened, which is acceptable. For background displays I suppose larger images might need to be processed via the Gimp; not important though. It might get picked up upstream sometime. Passed for x86_64. Shall try 32bits whenever that is available. Thanks for the good work. Those patches are mind-boggling. Regards Len
Whiteboard: (none) => has_procedure MGA4-64-OK
Extra comment on comment 11: Sorry Shlomi, I was assuming that the update had been pushed to QA testing. It does not seem to be in the database.
I have downloaded the i586 rpm now. Thanks.
It looks like tkimg in Cauldron has been fixed already: tkimg-1.4-4, and it does not darken PNG images so that particular fault does not need to be pursued.
(In reply to Len Lawrence from comment #15) > It looks like tkimg in Cauldron has been fixed already: tkimg-1.4-4, and it > does not darken PNG images so that particular fault does not need to be > pursued. Actually, the version with the fix there is tkimg-1.4-5 so it also needs to be pushed there.
@Shlomi: Excuse the babble. I have just tried tkimg on another Cauldron system and found that 1.4-4 does not deal with PNG images. On the previous machine it must have been overwritten by my Mandriva 10 hack. It is so confusing trying to keep track of five machines. So, thanks for tkimg-1.4-5. Shall test that as soon as it is available.
Reply to comment 16: Seems I am missing something here. If the update is already in Updates Testing what more needs to be done? I am clueless about the management side of QA. Just a foot soldier - don't have no stripes. So who do I ask to push it?
(In reply to Len Lawrence from comment #18) > Reply to comment 16: > > Seems I am missing something here. If the update is already in Updates > Testing what more needs to be done? I am clueless about the management side > of QA. Just a foot soldier - don't have no stripes. So who do I ask to > push it? First of all , we need to have MGA4-32-OK. Then someone should write an advisory. And then we can validate the update and push it into normal "Core/Updates".
Created attachment 6444 [details] More user-friendly test script Save the file with a name of your choosing, chmod +x the file then ./thefile
@Shlomi, re comment 19: Understood. But this sidesteps the normal process of submitting it for QA testing does it not? I have a feeling that I should have done something about that but don't know what. This may be why it does not come up in MADB. I guess I would be the best person to write the advisory and someone with authority would upload it with the push request.
Tested the 32-bit package in VirtualBox. All OK. Should be OK to push. Can I validate it if I write an advisory?
Whiteboard: has_procedure MGA4-64-OK => has_procedure MGA4-64-OK MGA$-32-OK
@Shlomi: As this is already in updates testing could you assign this bug to QA please so that it can be treated as an update candidate? Thanks
Whiteboard: has_procedure MGA4-64-OK MGA$-32-OK => has_procedure MGA4-64-OK MGA4-32-OK
Proposed advisory: Tkimg is a package of supplementary image handlers for use in Tcl scripts and has had a longstanding upstream bug with respect to the PNG handler (#12596). At the point where a script attempts to create a photo image from a PNG file the program crashes with a stack dump. This update solves the problem of failure to display PNGs for both architectures, although the new code has trouble with the brightness level of the displayed images. Source: tkimg-1.4-2.1.mga4.src.rpm Update candidates: tkimg-1.4-2.1.mga4.x86_64.rpm tkimg-1.4-2.1.mga4.i586.rpm
Created attachment 6452 [details] Replacement for 6444 6444 was treated as a bin file because extension not given This should fix it.
Thanks for all your help, Len! I submitted a Freeze Push for tkimg on Cauldron and am going to assign to QA.
Assigning to QA.
Assignee: joequant => qa-bugs
And thanks for all your help Shlomi.
Confirmed mga4 64 Before ------ $ ./showpng luckydip.png Error in startup script: invalid after png_start_read_image or png_read_update_info while executing "image create photo -file $png " invoked from within "set view [ image create photo -file $png ]" (file "./showpng" line 24) After ----- $ ./showpng luckydip.png Shows the png.
Validating. Advisory uploaded. Please push to 4 updates Thanks!
Keywords: (none) => validated_updateWhiteboard: has_procedure MGA4-64-OK MGA4-32-OK => has_procedure advisory MGA4-64-OK MGA4-32-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0044.html
Status: NEW => RESOLVEDResolution: (none) => FIXED