| Summary: | media-video/transcode-1.0.3 emerge fails w/ USE="imagemagick" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michelangelo Scopelliti <kernelpanic> |
| Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | a_tevelev, billie, dliana, jaak, jakub, jmjoseph, julien.cynober, kentnl, kernelpanic, p.paixao, pesa, starz909, zeekec, znmeb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Patch candidate to be merged in CVS (both 1.0.x and 1.1.x branches). Please test.
further patch to fix filters with ImageMagick 6.3.x and HDR enabled |
||
|
Description
Michelangelo Scopelliti
2007-06-19 19:16:19 UTC
Ok, some insight. This bug is present also on AMD64. I think I've found the problem: media-gfx/imagemagick-6.3.4, introducing HDRI, changed the definition of type Quantum, which, in turn, is used to define PixelPacket, the type of variable pixelpacket. pixelpacket breaks the compilation of import_im.c. So, in the end, I suggest two possible workarounds: either have a transcode without imagemagick support, or block imagemagick to 6.3.3 (which doesn't show the bug). This until the problem is fixed upstream -- I will signale it later. bug acknowledged upstream. Something else breaks with HDRI, although I don't remember exactly what it is. It's a Ruby package -- I just don't remember which one. Thanks for the workaround. :) Created attachment 125149 [details, diff]
Patch candidate to be merged in CVS (both 1.0.x and 1.1.x branches). Please test.
This patch should fix this problem, and improve a bit transcode's IM modules
as well. We're switching from MagickCore to MagickWand API, as suggested by
ImageMagick docs. This is supposed to make our modules better, simpler and avoid
future problems like that.
Please test.
I'msorry for the dealy. The patch, as it is, breaks the compilation of filter_logoaway.c (same problem for >> operator as in imagemagick filter). This appens both on x86 and amd64. I was not able to determine were is a patch problem or gentoo-patches+this_patch problem. In my tries, I applied this patch after gentoo-patches. 1.0.4-rc0 is in the the tree now, please try that one on for size. (In reply to comment #5) > I'msorry for the dealy. NP > The patch, as it is, breaks the compilation of filter_logoaway.c (same problem > for >> operator as in imagemagick filter). This appens both on x86 and amd64. OK, got it. GetImagePixels is used even on our IM filters, so of course they must fixed too. This will take longer (groan). (In reply to comment #7) > OK, got it. GetImagePixels is used even on our IM filters, so of course > they must fixed too. This will take longer (groan). OK, a quick summary follows. The problem: ------------ (questionable) usage of ancient interface of ImageMagick in some transcode modules lead to compilation (and quite surely, on execution too) problems, as pointed out on this bug report. Affected modules: ----------------- - import/import_im.c - import/import_imlist.c - filter/filter_compare.c - filter/filter_logoaway.c - export/export_im.c (maybe) please note that filter/filter_logo.c uses IM as well, but was greatly enhanced and improved during 1.1.0 cycle, so it should be not affected by this issue. Status: ------- import/import_im.c: rewritten, hopefullly fixed, needs testing and regression checking. import/import_imlist.c: same as above filter/filter_compare.c: work in progress filter/filter_logoaway.c: work in progress export/export_im.c: needs more checks. Stay tuned. Bests, (In reply to comment #6) > 1.0.4-rc0 is in the the tree now, please try that one on for size. Transcode 1.0.4-rc0 still fails. (In reply to comment #6) > 1.0.4-rc0 is in the the tree now, please try that one on for size. > 1.0.4_rc0 still fails (on ~amd64)... Created attachment 126475 [details]
further patch to fix filters with ImageMagick 6.3.x and HDR enabled
this patch improves pixel access from filter modules. Together with previous onw should solve the ImageMagick 6.3.x HDR issues.
While this patch is part of upcoming transcode 1.0.4rc2, future 1.1.0 will very likely go a different way, at least partially.
transcode 1.0.4rc2 is ready on CVS and is expected to be released tomorrow.
Please test.
Both patch are necessary to make transcode-1.0.4_rc0 compile successfully here. [ebuild R ] media-gfx/imagemagick-6.3.4-r1 USE="X bzip2 graphviz hdri jbig jpeg jpeg2k lcms mpeg perl png tiff truetype wmf xml zlib -doc -fpx -gs -nocxx -openexr -q32 -q8" 0 kB [?=>0] [ebuild R ] media-video/transcode-1.0.4_rc0 USE="X a52 dv dvdread iconv imagemagick jpeg lzo mjpeg mmx mp3 mpeg network ogg oss quicktime sdl sse sse2 theora truetype v4l2 vorbis xml xvid -3dnow (-altivec) -extrafilters -fame" 0 kB [0] Thanks Francesco. *** Bug 187754 has been marked as a duplicate of this bug. *** transcode-1.0.4_rc3 has been released. Changelog follows: transcode 1.0.4 (since 1.0.3): ------------------------------ - improve detection of MPEG streams: do not use hardcoded defaults if sequence header has incorrect data; - make our IM filters compatible with IM 6.3.x with HDR: improve pixel access; - drop old GTK 1.x requirement; - improve compatibility with libmpeg3 1.7; - improve compatibility with newer ffmpeg libraries; - trivial warning reduction fixes; Please bump, this new RC fixes the build failure against imagemagick that this bug is about. This bug seems to be fixed in 1.0.4_rc6. Thanks :) *** Bug 194157 has been marked as a duplicate of this bug. *** *** Bug 194790 has been marked as a duplicate of this bug. *** *** Bug 199898 has been marked as a duplicate of this bug. *** *** Bug 203824 has been marked as a duplicate of this bug. *** Transcode-1.0.3 which is marked stable on amd64 still fails with this error! So why is this bug marked RESOLVED FIXED?!?! If this is a WONTFIX, please mask 1.0.3 and stabilize 1.0.4. (In reply to comment #21) > Transcode-1.0.3 which is marked stable on amd64 still fails with this error! So > why is this bug marked RESOLVED FIXED?!?! Because bugs resolution reflects latest version in the tree and NOT stable; if you want something stabilized, then file a new bug. Jakub, Such a response makes little sense to me. I am synced with the latest portage on an amd64 system, and have exactly the issue reported. Until this is corrected, the bug, as reported, is certainly not corrected. Why else would a report be made if not to seek, and offer suggestions for correction? ~Jacob |
