Bug 1527

Summary: kdenlive install fails on Fedora 14 (missing mlt package)
Product: Fedora Reporter: Valent Turkovic <valent.turkovic>
Component: kdenliveAssignee: Ryan Rix <ry>
Status: RESOLVED FIXED    
Severity: normal CC: brancomat, covex, hobbes1069, j.golderer, johan, joukj, kevin.kofler, sergio, terry
Priority: P5    
Version: 14   
Hardware: All   
OS: GNU/Linux   
namespace:

Description Valent Turkovic 2010-11-19 21:52:19 CET
I can see only f13 packages in RPM Fusion and I get this error:


# yum install kdenlive
Loaded plugins: langpacks, presto, refresh-packagekit, remove-with-leaves
Adding en_US to language list
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package kdenlive.i686 0:0.7.7.1-1.fc13 set to be installed
--> Processing Dependency: libmlt++.so.3 for package: kdenlive-0.7.7.1-1.fc13.i686
--> Processing Dependency: dvdauthor for package: kdenlive-0.7.7.1-1.fc13.i686
--> Processing Dependency: dvgrab for package: kdenlive-0.7.7.1-1.fc13.i686
--> Processing Dependency: libmlt.so.2 for package: kdenlive-0.7.7.1-1.fc13.i686
--> Running transaction check
---> Package dvdauthor.i686 0:0.6.18-2.fc14 set to be installed
--> Processing Dependency: libGraphicsMagick.so.3 for package: dvdauthor-0.6.18-2.fc14.i686
---> Package dvgrab.i686 0:3.5-1.fc13 set to be installed
---> Package kdenlive.i686 0:0.7.7.1-1.fc13 set to be installed
--> Processing Dependency: libmlt++.so.3 for package: kdenlive-0.7.7.1-1.fc13.i686
--> Processing Dependency: libmlt.so.2 for package: kdenlive-0.7.7.1-1.fc13.i686
--> Running transaction check
---> Package GraphicsMagick.i686 0:1.3.12-2.fc14 set to be installed
---> Package kdenlive.i686 0:0.7.7.1-1.fc13 set to be installed
--> Processing Dependency: libmlt++.so.3 for package: kdenlive-0.7.7.1-1.fc13.i686
--> Processing Dependency: libmlt.so.2 for package: kdenlive-0.7.7.1-1.fc13.i686
--> Finished Dependency Resolution
Error: Package: kdenlive-0.7.7.1-1.fc13.i686 (rpmfusion-free)
           Requires: libmlt.so.2
Error: Package: kdenlive-0.7.7.1-1.fc13.i686 (rpmfusion-free)
           Requires: libmlt++.so.3
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


It seams that mlt package is missing from Fedora 14 RPM Fusion repo

This fixes the problem for me:
# yum install --enablerepo='rpmfusion-free-rawhide' kdenlive
Comment 1 Kevin Kofler 2010-11-21 02:57:38 CET
Looks like the build fails due to an inline assembly problem:

http://buildsys.rpmfusion.org/logs/fedora-14-rpmfusion_free/8567-mlt-0.5.4-1.fc14.1/i686/build.log

cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -fPIC -DPIC    -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -Wall -fPIC -DPIC    -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -I../../ -Wall -fPIC -DPIC    -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -DARCH_X86   -c -o yadif.o yadif.c
In file included from yadif.c:275:0:
vf_yadif_template.h: In function 'filter_line_sse2':
vf_yadif_template.h:228:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
vf_yadif_template.h:234:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
vf_yadif_template.h:228:9: error: 'asm' operand has impossible constraints
vf_yadif_template.h:228:9: error: 'asm' operand has impossible constraints
vf_yadif_template.h:234:9: error: 'asm' operand has impossible constraints
vf_yadif_template.h:234:9: error: 'asm' operand has impossible constraints
make[2]: Leaving directory `/builddir/build/BUILD/mlt-0.5.4/src/modules/xine'
make[2]: *** [yadif.o] Error 1
Comment 2 Kevin Kofler 2010-11-21 03:09:12 CET
Current MLT git has a workaround:
http://mltframework.org/gitweb/mlt.git?p=mltframework.org/mlt.git;a=commitdiff;h=dbe47e303ef2fda32049f0b2a0abcd49d75e2407
(Not ideal, but it'll make it build.) Please apply that fix and do a build for F14 ASAP.
Comment 3 Ryan Rix 2010-12-22 00:43:27 CET
*** Bug 1533 has been marked as a duplicate of this bug. ***
Comment 4 Ryan Rix 2010-12-22 00:43:44 CET
*** Bug 1556 has been marked as a duplicate of this bug. ***
Comment 5 Ryan Rix 2010-12-22 02:38:47 CET
Currently trying to fix this issue. Seems the build system is broken, though, at the moment.
http://buildsys.rpmfusion.org/build-status/job.psp?uid=8805
Comment 6 Adam Pribyl 2011-05-01 22:45:14 CEST
This problem still persist. Does the build still fails?
Comment 7 Kevin Kofler 2011-05-01 22:47:57 CEST
There's now a new problem, where mlt 0.7.0 was pushed without a kdenlive rebuild for it, plus the OpenShot maintainer wants mlt to get downgraded to 0.6.2, so for now we kicked 0.7.0 back to testing. We need a build of mlt 0.6.2 and a build of kdenlive against mlt 0.6.2 which can get pushed together.
Comment 8 Ryan Rix 2011-05-02 08:43:58 CEST
This is idiotic... I rebuilt kdenlive at the same time as MLT. There were some issues, but I fixed them. Why was it not pushed with 0.7.0??? 

The issues with 0.7.0 v. 0.6.2 are in a seperate bug report. This mess needs to just go away.
Comment 9 Kevin Kofler 2011-05-02 10:24:41 CEST
> This is idiotic... I rebuilt kdenlive at the same time as MLT. There were some
> issues, but I fixed them. Why was it not pushed with 0.7.0???

It was built ~3 days later, so it would have been pushed to stable just as much later, since nobody told the admins that the stuff needs to get pushed together.

> The issues with 0.7.0 v. 0.6.2 are in a seperate bug report. This mess needs to
> just go away.

If you think 0.7.0 should be pushed, could you please tell that to the admins? And take it up with Richard Shaw? They're waiting for you and him to agree on how to proceed.

See the rpmfusion-devel mailing list.
Comment 10 Kevin Kofler 2011-05-02 10:46:36 CEST
To explain this in more detail: The default action for testing updates in RPM Fusion, unless requested/agreed otherwise, is for them to get pushed to stable after 2 weeks in testing. This is how we ended up with mlt pushed without the matching kdenlive.

Now why wasn't kdenlive just moved to stable to fix this? The problem here is that Richard Shaw wants mlt downgraded:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-April/009485.html

I don't know if the idea there is to downgrade without an Epoch bump and thus prevent a move to stable. I think the Epoch is probably the cleaner solution if we really want to downgrade, also for those people using testing or development.
Comment 11 Richard 2011-08-22 17:43:01 CEST
Verified I could install kdenlive in a F14 chroot environment. Closing.