Description of problem: Basic sanity test revealed that the following netpbm tools fail to work as expected: tifftopnm, sgitopnm, pnmtofiasco, eyuvtoppm, pamtosvg, pamtojpeg2k Version-Release number of selected component (if applicable): netpbm-10.35.57-1.fc11.i386 netpbm-progs-10.35.57-1.fc11.i386 Preparing reproducers: ppmwheel 100 | pnmquant 16 > test.ppm ppmtopgm test.ppm > test.pgm pgmtopbm test.pgm > test.pbm Testing details: eyuvtoppm fails on self generated eyuv file: # ppmtoeyuv test.ppm > test.eyuv # eyuvtoppm test.eyuv >back.ppm eyuvtoppm: Premature end of file reading EYUV input file pamtosvg segfauults on pbmm files # pamtosvg test.pbm > test.svg Segmentation fault pamtojpeg2k fails on all pnm files # pamtojpeg2k test.ppm > test.jpc warning: color space apparently not RGB pamtojpeg2k: close of file failed with errno 9 (Bad file descriptor) tifftopnm, sgitopnm and pnmtofiasco fail to accept files on stdin # pnmtotiff test.ppm > test.tiff pnmtotiff: computing colormap... pnmtotiff: 16 colors found # file test.tiff test.tiff: TIFF image data, little-endian # tifftopnm test.tiff > back.pnm tifftopnm: writing PPM file # cat test.tiff | tifftopnm > back.pnm TIFFReadDirectory: Standard Input: Seek error accessing TIFF directory. tifftopnm: error opening standard input as TIFF file # pnmtosgi test.ppm > test.sgi # file test.sgi test.sgi: SGI image data, RLE, 3-D, 100 x 100, 3 channels # sgitopnm test.sgi > back.pnm sgitopnm: writing PPM image # cat test.sgi | sgitopnm > back.pnm sgitopnm: seek error for offset 2912 # cat test.ppm | pnmtofiasco >test.fiasco pnmtofiasco: bad magic number - not a ppm, pgm, or pbm file
The pamtosvg segfault is now fixed. The tifftopnm seek failure is fine. The input stream has to be seekable so passing the input file via pipe is not possible. Man page says: "The tiff-filename argument names the regular file that contains the Tiff image. If you specify ’-’ or don’t specify this argument, tfftopnm uses Standard Input. In either case, the file must be seekable. That means no pipe, but any regular file is fine." In case of sgitopnm it's the same problem as in case of tifftopnm, but it's not documented. pnmtofiasco needs a bit special arguments, one can convert the file via pnmtofiasco -i <file>.pnm -o <file>.fco
I see... Then tifftopnm is fine and we should perhaps just make the documentation for sgitopnm consistent. As far as pntofiasco is concerned, I think the behaviour should be consistent with the rest of the tools, that is to accept files on stdin, which is also described in man: > pnmtofiasco compresses the named pbm, pgm, or ppm image files, > or Standard Input if no file is named > > -i name, --input-name=name > Compress the named images, not Standard Input.
Three more failing tools: # ppmshadow test.ppm Global symbol "$ourtmp" requires explicit package name at /usr/bin/ppmshadow line 75. Global symbol "$ourtmp" requires explicit package name at /usr/bin/ppmshadow line 147. Global symbol "$ourtmp" requires explicit package name at /usr/bin/ppmshadow line 164. ... Execution of /usr/bin/ppmshadow aborted due to compilation errors. # ppmrainbow yellow >test.ppm sh: .tmp/ppmrainbow.20466.000.ppm: No such file or directory pgmramp|pgmtoppm failed. at /usr/bin/ppmrainbow line 60. # pnmmontage test.ppm test.pgm test.pbm > joined.pnm pnmmontage: object too large
ppmshadow and ppmrainbow is now fixed. It was caused by broken perl syntax in security patches. pnmmontage is fixed as well. It used allocation_depth member of pam struct in color depth decision. But allocation_depth was uninitialized -> kaboom. I'm still looking at pnmfiasco.
The ppmtoeyuv and eyuvtoppm problem is not a bug. eyuvtoppm fails to reconstruct the image created by ppmtoeyuv because the file format lacks any information related to image dimensions. They have to be specified on commandline. So for the test image: $ eyuvtoppm --height 100 --width 100 test.eyuv > test2.ppm eyuvtoppm: Converting Frame 0 eyuvtoppm succeeds. The image dimensions are considered default (352x240) if unspecified. That explains the "eyuvtoppm: Premature end of file reading EYUV input file" you see.
I just fixed pnmtofiasco as well. The problem was that pnmtofiasco read the pnm header then closes the file and uses another function to read the signature again and all the data. Since stdin is not rewindable it tried to read the pnm signature twice from stdin what caused this problem.
netpbm-10.35.58-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
netpbm-10.35.58-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
pamtojpeg2k error still present in the newest rawhide packages: netpbm-progs-10.35.59-1.fc11.i386 netpbm-10.35.59-1.fc11.i386 # ppmwheel 100 > test.ppm # pamtojpeg2k < test.ppm > test.jpc warning: color space apparently not RGB pamtojpeg2k: close of file failed with errno 9 (Bad file descriptor) Anyway, the file seems to be successfully generated.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The problems still present in netpbm-10.47.07-1.fc12.x86_64: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: TEST PROTOCOL :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Test run ID : BKbrJTV :: [ LOG ] :: Package : netpbm :: [ LOG ] :: Installed: : netpbm-10.47.07-1.fc12.x86_64 :: [ LOG ] :: Test started : 2010-04-27 10:22:25 :: [ LOG ] :: Test finished : 2010-04-27 10:23:56 :: [ LOG ] :: Test name : /CoreOS/netpbm/Sanity/converters :: [ LOG ] :: Distro: : Fedora release 12 (Constantine) :: [ LOG ] :: Hostname : localhost :: [ LOG ] :: Architecture : x86_64 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ FAIL ] :: Testing cmuwmtopbm on pbmtocmuwm-from-pbm.cmuwm (Expected 0, got 1) :: [ FAIL ] :: Testing pnmtofiasco on test.pbm (Expected 0, got 134) :: [ FAIL ] :: Testing pnmtofiasco on test.pgm (Expected 0, got 134) :: [ FAIL ] :: Testing pnmtofiasco on test.ppm (Expected 0, got 134) :: [ FAIL ] :: Testing pstopnm on pnmtops-from-pbm.ps (Expected 0, got 1) :: [ FAIL ] :: Testing pstopnm on pnmtops-from-pgm.ps (Expected 0, got 1) :: [ FAIL ] :: Testing pstopnm on pnmtops-from-ppm.ps (Expected 0, got 1) :: [ FAIL ] :: Testing pamtojpeg2k on test.pbm (Expected 0, got 139) :: [ FAIL ] :: Testing pamtojpeg2k on test.pgm (Expected 0, got 1) :: [ FAIL ] :: Testing pamtojpeg2k on test.ppm (Expected 0, got 139) :: [ FAIL ] :: Testing pamtosvg on test.pgm (Expected 0, got 1) :: [ FAIL ] :: Testing pamtosvg on test.ppm (Expected 0, got 1)
Similarly with netpbm-10.47.09-2.fc13.x86_64: :: [ FAIL ] :: Testing cmuwmtopbm on pbmtocmuwm-from-pbm.cmuwm (Expected 0, got 1) :: [ FAIL ] :: Testing pstopnm on pnmtops-from-pbm.ps (Expected 0, got 1) :: [ FAIL ] :: Testing pstopnm on pnmtops-from-pgm.ps (Expected 0, got 1) :: [ FAIL ] :: Testing pstopnm on pnmtops-from-ppm.ps (Expected 0, got 1) :: [ FAIL ] :: Testing pamtojpeg2k on test.pbm (Expected 0, got 139) :: [ FAIL ] :: Testing pamtojpeg2k on test.pgm (Expected 0, got 1) :: [ FAIL ] :: Testing pamtojpeg2k on test.ppm (Expected 0, got 139)
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.