SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One of the things I have to do quite a lot is video editing. My favourite Linux app for this is Kdenlive. Unfortunately, this is only being developed for KDE5 these days, and the older KDE4 version has some irritating bugs.
So, after experimenting with AlienBob's Plasma5 implementation on an old machine, I've bitten the bullet and installed it on my main machine.
So far so good!
Now I don't know if anyone else out there has tried to build Kdenlive, but it is dependency hell! However, they do an AppImage version, claimed to run "as is". So to keep me going whilst I work my through weeks of compiling dependencies, I thought I'd give it a try.
Big problem!
It relies on libselinux for some reason. All the references I can find to this on Slackware seem to imply that its a pig to install, and really has no place on a sane system. Fair enough, but I NEED it, for the time being, at any rate!
Has anyone got any pointers as to how best to install it, the "gotchas" that seem to be associated with it, or any other advice?
they do an AppImage version, claimed to run "as is"
Bollocks innit
Quote:
Originally Posted by pchristy
All the references I can find to this on Slackware seem to imply that its a pig to install, and really has no place on a sane system. Fair enough, but I NEED it, for the time being, at any rate!
Whatever hassle you think it is to build kdenlive, selinux would be ten times worse. DON'T GO THERE.
Here's the dependency tree for kdenlive, it's not too bad at all, you might even have lots of the deps already:
Yes, I do already have many of the dependencies installed, and when I build a new version of ffmpeg, I always make sure it has the right configuration options for Kdenlive. However, whilst your list correctly includes MLT and Frei0r as dependencies, I don't think it includes some of *their* dependencies (OpenCV?) - hence my comments about dependency hell!
The last time I tried to build OpenCV it failed with an obscure error that I didn't managed to track down. Must give it another go.....
I know Pat is very conservative when it comes to introducing big revisions of major components, but I'm hoping we get an official Plasma 5 version of Slackware soon. Its not that I'm having any big issues with AlienBob's excellent version, but I do worry that when 5 is officially supported, I might have to go through this whole compilation process again! And Kdenlive isn't the only package that I use regularly that no longer supports KDE-4.......
And Kdenlive isn't the only package that I use regularly that no longer supports KDE-4
I am using kdenlive in kde4 with Slackware 14.2. Since I didn't want to compile all stuff, I went for a "lazy" approach and installed kdenlive and its dependencies via the Slackonly repository [0]. You can even add it to slackpkg+ [1] (although you might get some "conflicts" with other repositories providing the same software (but in a different version), so it would be wise to set a PKGS_PRIORITY for some of the packages - if you actually are using other repositories with slackpkg+).
According to the kdenlive Slackbuild [2] you need the following dependencies:
(*) can be installed from Slackware's extras repository or from the Slackonly repository (I have used Slackonly to have all kdenlive dependencies from the same repository)
From these dependencies, three packages (marked in bold) have aditional dependencies:
dvgrab:
Quote:
libavc1394
libdv
libiec61883
faac
Quote:
libmp4v2
mlt (**)
Quote:
libdv
libquicktime (***)
ffmpeg (****)
(**) Has optional dependencies qt5, ladspa_sdk, frei0r, swfdec and jack-rack. If you have installed KDE Plasma from AlienBob you already have qt5 and I don't remember having installed any of the other optional dependencies. I did install frei0r for using it with Openshot, but removed it afterwards.
(***) Optional dependencies are faac, faad2, ffmpeg, lame, libdv, schroedinger and x264, but all are included in previous dependencies.
(****) Seems to have a lot of optional dependencies, which I did not install, but did not prevent me from having a functional kdenlive (for my needs, at least).
As you can see libdv is a repeated "sub-dependency". So, if you add slackonly repository to slackpkg+, just execute:
I've not been able to build kdenlive on slackware for at least several months now, as you state dependency hell. Sometimes it will build but then i have issues with ffmpeg not working along with it, resulting in no use at all.
I did in the end, go with pitivi. Which simply works. On slackbuilds it is merely a repackage (doesn't require compiling if i remember rightly). I've been using that for a while for some video editing, and it does most of the things i need.
Just thought that might be useful if you're looking for something else that isn't a headache and a half to get running.
bateleur: Thanks for another interesting approach! I whish I'd known about it before I embarked on this!
I think I *may* have finally managed to build it all and get it working. It is at least working superficially, though I haven't had chance to give it a good wringing out yet.
A lot of the "dependencies" are only dependent if you need that functionality. For example, I don't need dvgrab, and none of my other utilities / libraries have been built with that requirement, so I can safely ignore it.
The items that caused me the most grief were opencv, mlt and ffmpeg (of all things!). I managed to get opencv-3.1.0 to build, but I simply could not get 3.2 to compile at all. Its meant to contain a lot of bug fixes, so I was quite keen to use it if possible, but whatever I tried, it would get to about 84%, and then just stop! No errors, 0% cpu usage, just nothing! Ctl-C got out of it, but absolutely no clue as to what was happening or why! It just stopped!
MLT kept complaining about Qt5 requiring a c++11 compatible compiler. Luckily I'd run into this one before with avidemux (you need to add -std=c++11 to the cxxflags), but it took a while to find the correct syntax to make it work with mlt!
FFmpeg refused to compile ffplay - again, without any warnings! Google indicated that it needs the sdl libraries to compile ffplay, which I had installed. What it meant was that it needed *SDL2* - but this isn't mentioned anywhere that I could find! And of course, kdenlive requires ffplay!
Anyway, I think I now have a working editor again. Over the next week or two I'll find out if I've left anything else out........!
p.s. Coralfang: I worked as a professional editor in Bristol for a while, though I've now retired to south Devon. I can give you a more detailed description of how I got it all built if you want to try kdenlive again...
The items that caused me the most grief were opencv, mlt and ffmpeg (of all things!).
opencv and ffmpeg are both pains since they both have optional dependencies against each other (ffmpeg can use opencv and opencv can use ffmpeg -- circular dependencies... yay). On my system, I ended up building ffmpeg without opencv but built opencv against ffmpeg. I'm not sure if one is better than the other or if they should both be rebuilt until they both rely on each other...
But I use slackrepo (created by 55020), which I've found is far easier to plan for these big dependency items, especially when they contain a bunch of optional dependencies. You just set up a hint file for each program that has optional dependencies, then let slackrepo figure out the build order on it's own. When updates to SBo are pushed, you can easily update all required packages.
For kdenlive, I had hintfiles set up for dvgrab, libquicktime, ffmpeg, libass, enca, and vid.stab, which added a number of additional optional dependencies (35, by my count).
Basically, when you go to build one of these programs, you check the READMEs on SBo and then create a hint file for any program that needs optional dependencies (and optional commands, like ffmpeg). You just work your way through the list, checking each optional dependency to see what you want to include. Many times, you'll find you have a hint file already created (like me, since I had already built ffmpeg and created a hint file for that). It does take some time, but you then know you have everything you want, and slackrepo will remember it any time you need to rebuild it (like if/when future updates to any of those dependencies change). Once you're done, you just issue: slackrepo build kdenlive and just wait. My package list for kdenlive is below (sorted alphabetically, so I could remove all the duplicate dependencies -- since multiple programs can rely on the same dependency):
Slackrepo is very unique in that it will generate a clean chroot every time it goes to compile a program. This prevents your programs from relying on dependencies you haven't specifically specified (and ensures your packages will work on any system you install them on, provided you install all the dependencies). Even though I was using sbopkg with sqg for a few years and being plenty happy with it, I'm really glad I made the switch to slackrepo. It really is a better way of building packages. Due to all my options in the hint files, my dependency tree is quite a bit larger than the one 55020 posted:
And my various hint files contain the following (ffmpegs kinda crazy since dependencies require options to be passed... I really wish they'd just support autodetection):
Bassmadrigal: Many thanks for that detailed and thoughtful post! That is certainly something I shall investigate for the future, and also something of which I was totally unaware until I started this thread! Hopefully it may help others as well.
One thing I have noticed is that the latest -current updates now include ffmpeg. Unfortunately, the version supplied seems to omit many of the requirements, not only for kdenlive, but also for any reasonably comprehensive video management tool. I've stuck with my own build, which I know has everything I need built in. However, it does make me wonder how many Slackware packages are likely to have an ffmpeg dependency, either now or in the future. For example, I now use MPV as my media player of choice (sometimes within smplayer) instead of MPlayer. I find it much slicker, more stable and easier to use than either VLC or MPlayer. However, it does need to be compiled against ffmpeg, and if you update ffmpeg, you usually have to recompile mpv as well. I can see this causing some awkwardness in future, with some Slackware packages being compiled against Slackware's ffmpeg rather than my own, more comprehensive version. I wonder which ones are likely to barf in future because they come across the "wrong" ffmpeg?
Yes, the version in Slackware needs to be limited due to patent/copyright issues. Overall, it does certainly seem that Pat adding ffmpeg to Slackware will make things more interesting. Unfortunately, it's new enough that I don't know how we will be affected (especially since I don't normally run -current, so I won't be directly affected for a while).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
