Building from source on Slackware

[BusinessKid]

Question: A clear and concise question, with enough context and explanation for people to answer it.

System Details:

• OpenShot Version [e.g. 2.4.3]: {{ log_context.openshot_qt_version }}
• Operating System / Distro: [e.g. Windows 10, Linux Mint 17.1]

Screenshots: (Optional) If applicable, add screenshots to help explain your question. You can include screenshots by copy/pasting them here, dragging-and-dropping into this form, or clicking below and loading images saved to your computer. All images are public, so please don't post screenshots containing personal information.

[BusinessKid]

I'm trying to build Openshot from source on Slackware64. Slackware has 32bit libs in /lib, lusr/lib, etc and 64bit libs in /lib64, /usr/lib64; Most distros put 64bit libs in /lb, /usr/lib and have various odd systems for 32 bit stuff. It does not have dependency checking, but I know how to invoke ldd :-).

Can I make an appeal for more information on compile-time options, better build instructions and/or a conventional build system? Normally I can simply run ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc <& others if needed> make make DESTDIR=/tmp/pack install and I can use the slackware 'makepkg' utility to build a slackware package, install it and uninstall it.

[ferdnyc]

@BusinessKid ./configure is a GNU Autotools convention. OpenShot uses cmake to build its libraries, and installs the OpenShot Python module using Python setuptools, neither of which has a configure script. These are common patterns.

That being said, OpenShot uses cmake wrong, and has been for some time. Every time I've submitted a patch to correct this, it's had to be reverted because the build servers that build the official OpenShot packages rely on those wrong assumptions, unfortunately.

Fedora uses the same 64-bit paths as Slackware, I'll take a look at our Fedora package build and see what we're doing to mitigate the path errors from the libopenshot cmake process.

[BusinessKid]

Yes, yes, version & System details. I had the git as of yesterday of openshot-qt, but since realised there's 3 projects in openshot';s git. The system is a Samsung Np350C-A05-UK. i3, HD4000 graphics, Panther Point (Series 7) chipset 250Gssd & 6G ram, running Slackware64-current.

Fedora uses the same 64-bit paths as Slackware, I'll take a look at our Fedora package build and see what we're doing to mitigate the path errors from the libopenshot cmake process.

There's a rpm2tar.gz script with slackware. I can get that, explode it in a tmpdir, fix what's needed (If anything) and make a slackware package from it. I'll probably shove it in /usr/local or /opt here.

Personally, I find cmake and meson painful to work with. If left alone, they think they know better than you, which they don't. It then becomes much more difficult to specify oddities. And help is always sparse.

[ferdnyc]

I had the git as of yesterday of openshot-qt, but since realised there's 3 projects in openshot';s git.

And that's the important thing. "Building" (really just packaging) and installing openshot-qt itself is easy, as it uses Python setuptools which does all of the heavy lifting. But it's useless without the libopenshot Python bindings, which are only available after you've built and installed first libopenshot-audio, and then libopenshot.

Fedora uses the same 64-bit paths as Slackware, I'll take a look at our Fedora package build and see what we're doing to mitigate the path errors from the libopenshot cmake process.

There's a rpm2tar.gz script with slackware. I can get that, explode it in a tmpdir, fix what's needed (If anything) and make a slackware package from it. I'll probably shove it in /usr/local or /opt here.

Well, I can give you my binary RPMs, but unless you've got the exact same versions of all the dependencies installed, libopenshot will probably be linked with the wrong libraries. Given how many dependencies there are, it'd be a Christmas miracle if that actually worked.

Or, I can provide my source RPMs... I don't know if those are of any use?

Anyway, here's a Google Drive folder containing both the binary x86_64 RPMs (or noarch, for openshot itself), plus the SRPMs for each package. These are all from the latest commit to the repos as of this writing.

https://drive.google.com/open?id=1Y08WB3LTC6hwqkJ6ha1qdS5DaLiNtW33

Basically, what we do to build the Fedora (actually RPM Fusion) RPMs is:

1. Build libopenshot-audio (as it's a dependency for libopenshot)

   1. Our cmake command line (which is mostly all automated by the Fedora rpm macros) is:

      /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON .

   2. Then just make

   3. Followed by make install DESTDIR=$BUILDROOT (where $BUILDROOT is the dir the package is built from, when installed it'll be the filesystem root)

2. Build libopenshot

   The trickiest thing here is all the dependencies. But assuming you have them all installed in the standard system paths, they should be detected automatically.

   1. Trickiest one: libopenshot-audio itself. If it's not installed at a standard path like /lib64, /usr/lib64, /usr/local/lib64, etc. you'll have to set an environment variable (it only works as an envvar, for now; there's a patch pending to fix that, too) with its location. So if it's installed to, for example, /opt/libopenshot-audio/usr/lib64/libopenshot-audio.so and /opt/libopenshot-audio/usr/include/libopenshot-audio/, you'd need to export LIBOPENSHOT_AUDIO_DIR=/opt/libopenshot-audio/usr/ before running cmake for libopenshot. But if it's in /usr/ or /usr/local it should get picked up automatically.

   2. Again, mostly-automated from Fedora:

      cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -Wno-dev -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_SKIP_RPATH:BOOL=YES -DUSE_SYSTEM_JSONCPP:BOOL=ON .

   3. Assuming that's successful, make to build

   4. make install DESTDIR=$BUILDROOT

   5. However, here we correct the Python bindings path, which ends up wrong: mv $BUILDROOT/usr/lib/python3.7 $BUILDROOT/usr/lib64/python3.7

If you don't install the openshot Python bindings (those are the ones that come from libopenshot, not openshot-qt) in the system Python site-packages, you'll have to set PYTHONPATH to the location you do install them in order to run openshot.

Honestly, I would suggest getting the libraries built and installed first, then at least experimentally running OpenShot itself from the source tree, before worrying about doing anything more with its install. If you have the libraries correctly built and installed, and the Python bindings at some location /path/to/openshot.py, you can run OpenShot from a clone of the openshot-qt repo like so:

cd /git/clone/of/openshot-qt/src
PYTHONPATH=/path/to/ python3 ./launch.py

Before even trying that, though, I'd suggest you test the python bindings after installing libopenshot, which you can do in much the same way:

PYTHONPATH=/path/to/ python3
>>> import openshot
>>> print(openshot.GetVersion().ToString())
0.2.3

If you get no errors and it prints the version, the bindings are all installed correctly.

If you have trouble with anything, using non-standard install locations, it'll likely be RPATH issues. There, as you said, ldd is your friend. The cmake command lines above disable any RPATH settings, since Fedora packaging mandates not setting any RPATH — all libraries are expected to be installed in the standard LD_LIBRARY_PATH search dirs. If you're installing them elsewhere, you might want cmake to manage the RPATH on your various libraries, by removing the -DCMAKE_SKIP_RPATH:BOOL=YES from the libopenshot cmake line.

[BusinessKid]

Thank you for the very complete build instructions complete with gotchas.Somebody ought to put that in the docs. It seems to answer my original appeal for information. Boy, am I glad I did ask before wasting too much time. I have experience with compiling from source. You're right, it would be a miracle if the versions coincided with Fedora. I'm running Slackware64; the last official version was in 2015, and the personal difficulties of Slackware's BDFL and his vision for the next version have held things up. But there's rolling releases, (slackware64-current) and I'm running the latest, July 2019.

Ways to approach catering for slackware is to install it ( 32 & 64 bit, & multilib if required) in a vm and build packages, Slackware doesn't have dependency checking; there's an 11 line description (optional), and an installation script. If there's symlinks in the package, the 'makepkg' command automatically offers to drop them in a script for you.

Another approach is to write a slackbuild script. These are bash scripts which untar the archives in /tmp, build them (in /tmp/SBo) and make a package to install on your pc.

I'll save off these instructions, and close this bug/question for the moment. The feedback is definitely poorer in cmake. As you can see from ii above, cmake isn't being given much latitude to detect things for itself. Mind you, I'm fresh from a battle with meson (a new build system) over Mesa. Someone in Slackware wrote a 206 line script to get a compile of Mesa! I'm surprised to see a Fortran flags, as Fortran is rare these days, but I can install gcc-fortran

Thanks again. BK.

[ferdnyc]

@BusinessKid Absolutely no need to install gcc-fortran, as I said those cmake args are autogenerated by Fedora's macros. They're blindly added to all cmake runs during package builds. cmake will simply ignore the -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG, since it's not used. (Or you can certainly omit it; I simply copied-and-pasted the entire command line from my build logs without going through and sanitizing. But the Fortran flags, for one, are definitely superfluous.)

[ferdnyc]

For libopenshot, sorting out the dependencies is certainly one major task. I didn't cover that above, but the build process assumes the following dependency packages are already installed and detectable on the system: BuildRequires: ImageMagick7-c++-devel BuildRequires: ffmpeg-devel BuildRequires: qt5-qttools-devel BuildRequires: qt5-qtmultimedia-devel BuildRequires: unittest-cpp-devel BuildRequires: cppzmq-devel BuildRequires: zeromq-devel BuildRequires: jsoncpp-devel

ETA: I left off one more requirement for building the Python bindings (in addition to Python itself): BuildRequires: swig

(Those are Fedora's package names, obviously they may differ on Slack.)

• ImageMagick-c++ isn't required and libopenshot will build fine without it, it's still supported but the functionality's pretty much been replaced by Qt's QImage.
• If jsoncpp isn't installed on the system, you can just remove -DUSE_SYSTEM_JSONCPP:BOOL=ON from the cmake command line, and libopenshot will build with a bundled copy of jsoncpp.
• Everything else is hard required, along with libopenshot-audio.

[ferdnyc]

The full set of Qt components that libopenshot scans for in its CMakeLists.txt is:

################# QT5 ###################
# Find QT5 libraries
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Core REQUIRED)
find_package(Qt5Gui REQUIRED)
find_package(Qt5Multimedia REQUIRED)
find_package(Qt5MultimediaWidgets REQUIRED)

(Some of those are implied by the listed Fedora packages.)

[ferdnyc]

Oh, right, and I somehow neglected to mention that openshot-qt then requires PyQt5, and it requires that both Qt and PyQt5 have the optional QtWebKit module installed. Since Qt 5.6, it's no longer bundled with Qt.

[BusinessKid]

Thanks for that information, guys. From Post#1

Can I make an appeal for more information on compile-time options, better build instructions and/or a > conventional build system?

I sure have that now. PUT IT IN A DOCUMENT FOR OTHERS.

I have a lot of that stuff already installed, qt4+5, & webkits, json. Slackware doesn't split off libs, but is more like LFS. You get the whole package - binaries, headers, relevant extras, etc. Very handy when installing.

[ferdnyc]

A lot of the info is in the libopenshot build instructions, just in a more generic form that assumes you're not working with any particular distro setup OK, it basically assumes you're on Ubuntu. Since I knew there are some quirks that Slackware and Fedora share (mostly around lib paths), I was able to give you a more targeted version.

(Also, the build docs are a bit out of date. Updating them is one of the current ongoing projects; the Windows doc took first priority, since it was much, much more out of date, to the point of being useless.)

[BusinessKid]

I went about compiling this today. I decided to make 3 packages of it. Linopenshot-audio went in fine. Your instructions don't give cmake any room to manouvre, do they?

Libopenshot puked thusly, and I presume I am missing ZMO, whatever that is - some obtuse lib, I presume?

-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found OpenMP: TRUE
CMake Error at /usr/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find ZMQ (missing: ZMQ_LIBRARY ZMQ_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) cmake/Modules/FindZMQ.cmake:24 (find_package_handle_standard_args) src/CMakeLists.txt:184 (FIND_PACKAGE)

Any idea what zmo is? It's an unfortunate name that turns up many false hits. Slackware repositories don't seem to have it.

[ferdnyc]

@BusinessKid

That's actually a "q" — the library you're looking for is the ZeroMQ messaging library. Specifically, you need both ZeroMQ itself, and its C++ interface cppzmq. (You'll also need the Python bindings pyzmq, later, for OpenShot itself.)

[ferdnyc]

Your instructions don't give cmake any room to manouvre, do they?

Like you said... it thinks it knows better. Best not to give it any rope. :wink:

[BusinessKid]

Evidently, you guys used an awful lot of dependencies. I suppose python make you do that. I installed zeromq-4.3.1 (along with the python bit via pip3), unittest-cpp, & jsoncpp to try to get libopenshot going. The 'cmake' bit gets through with a 'using that instead of this' warning, but the make pukes looking for zmq.hpp

cd /home/dec/libopenshot/src && /usr/bin/c++ -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DOPENSHOT_IMAGEMAGICK_COMPATIBILITY=0 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DUSE_IMAGEMAGICK=1 -Dopenshot_EXPORTS -I/home/dec/libopenshot/src/include -I/home/dec/libopenshot/src/include/effects -I/home/dec/libopenshot/src/include/Qt -I/home/dec/libopenshot/include -I/usr/include/ImageMagick-6 -I/usr/include/libopenshot-audio -I/usr/include/jsoncpp -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtMultimedia -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtMultimediaWidgets -g -ggdb -fopenmp -DNDEBUG -fPIC -fPIC -std=c++11 -o CMakeFiles/openshot.dir/CacheBase.cpp.o -c /home/dec/libopenshot/src/CacheBase.cpp In file included from /home/dec/libopenshot/src/../include/Frame.h:58, from /home/dec/libopenshot/src/../include/CacheBase.h:35, from /home/dec/libopenshot/src/CacheBase.cpp:31: /home/dec/libopenshot/src/../include/ZmqLogger.h:43:10: fatal error: zmq.hpp: No such file or directory 43 | #include Zeromq seems to have very little in there; 2 libs, 2 includes (zmq.h, & zmq_utils.h) and the rest documentation.

[ferdnyc]

@BusinessKid You're missing cppzmq, the C++ bindings. ZeroMQ itself only ships C headers. cppzmq will supply the zmq.hpp header.

[ferdnyc]

Evidently, you guys used an awful lot of dependencies. I suppose python make you do that.

Not especially. It's more just the nature of multimedia software, really. libopenshot has far more dependencies than OpenShot does on the Python side. But even combined, they have fewer dependencies than a lot of other packages. On my Fedora 30 system:

$ rpm -q --requires ffmpeg-libs|egrep -v '(libstdc|libc.so)' |wc -l
83
$ rpm -q --requires vlc|egrep -v '(libstdc|libc.so)' |wc -l
49
$ rpm -q --requires inkscape|egrep -v '(libstdc|libc.so)' |wc -l
76
$ rpm -q --requires openshot |wc -l
17
$ rpm -q --requires libopenshot|egrep -v '(libstdc|libc.so)' |wc -l
40

[ferdnyc]

(That's not a perfect metric, but you get the point.) Building this kind of software is still excessively complex, for the most part, and OpenShot does an incredibly poor job of improving on that situation.

The number one priority for OpenShot's build system has always been the official builds, since @jonoomph maintains servers that publish official packaged builds for all supported OSes. Enduser packaging is unfortunately a secondary concern. So, that's one major hurdle. But, while that's unfortunate, it's also reasonable: As long as the official packages are being produced, we can at least offer that option to anyone who wants to use OpenShot. Whereas, if the project builds break down, being able to build OpenShot themselves only helps a tiny percentage of its users.

We've slowly been making incremental changes to the build system that should improve the build experience for endusers. And, there are more such changes in PRs waiting to be merged. But, having to "work around" the official build process complicates and slows that process considerably, and basically rules out any sort of sweeping overhaul. (Hasn't stopped me from trying, a couple of times... but each attempt failed.)

Plus, no matter what we do it'll just never be "easy" to build libopenshot, given all of its complex moving parts. As much as we can try to improve things (and there's still a lot of room for improvement), we're ultimately constrained by that reality.

[BusinessKid]

All you need to do, I imagine, is stick a slackware vm in some box. then copy in a compiled fedora destdir, and make a package. You can even just drop the package tools into fedora. The txz format is simply extracts in / As for the rpm dependencies - yes, ffmpeg & vlc use loads, but they count things we take for granted as dependencies.

Back at the compile, cppzmq must have it's own issues. That compile went belly up at the linking stage with undefined references:

undefined reference to zmq_msg_routing_id' undefined reference tozmq_msg_set_routing_id' undefined reference to zmq_msg_group' undefined reference tozmq_msg_set_group' And another dozen or so to 'zmqpoller'

I presume there's some other nasty bit of zmq I haven't got. I did an update to Zeromq-4.3.2, but that isn't it. I'll leave it tonight.

[ferdnyc]

@BusinessKid Yeah, not sure... from those missing symbols it looks like it's not linking with libzmq itself.

If you do a make VERBOSE=1 and post the gcc command line that's failing, I can look to see if anything jumps out at me.

[ferdnyc]

All you need to do, I imagine, is stick a slackware vm in some box. then copy in a compiled fedora destdir, and make a package.

Oh, Fedora isn't an official package either — I maintain it for the RPM Fusion package collection, but as an unofficial third-party build.

The only official Linux packages are the AppImage builds downloadable from openshot.org, and the Launchpad PPA — mostly because the project Linux build servers run Ubuntu, and they use the PPA to pull in build components for the official (AppImage) package builds. Everything else is third-party maintainer.

The decision was made #WayBackWhen to go down the AppImage route, rather than trying to maintain packages in a dozen different distro package collections, especially ones we don't actually use or know their packaging process/rules/quirks.

[BusinessKid]

Persisting out of obstinacy more than wisdom, I found a script called ci_build_sh in cppzmq. Evidently somebody else is making a rod for his own back (like you have) by using cmake, and using a script to get out of it. I have that in /usr/local, and I'm not bothered moving it.

Going back to libopenshot, It gets through the compile to linking libopenshot, and then goes belly up thusly:

/usr/bin/c++ -g -ggdb -fopenmp -DNDEBUG CMakeFiles/openshot-example.dir/examples/Example.cpp.o -o openshot-example libopenshot.so.0.2.3 /usr/lib64/libopenshot-audio.so /usr/lib64/libQt5MultimediaWidgets.so.5.11.3 /usr/lib64/libQt5Widgets.so.5.11.3 /usr/lib64/libQt5Multimedia.so.5.11.3 /usr/lib64/libQt5Gui.so.5.11.3 /usr/lib64/libQt5Network.so.5.11.3 /usr/lib64/libQt5Core.so.5.11.3 /usr/lib64/libjsoncpp.so /usr/lib64/libzmq.so /usr/lib64/libavcodec.so /usr/lib64/libavdevice.so /usr/lib64/libavformat.so /usr/lib64/libavfilter.so /usr/lib64/libavutil.so /usr/lib64/libpostproc.so /usr/lib64/libswscale.so /usr/lib64/libswresample.so /usr/lib64/libavresample.so -fopenmp /usr/lib64/libMagick++-6.Q16HDRI.so /usr/lib64/libMagickWand-6.Q16HDRI.so /usr/lib64/libMagickCore-6.Q16HDRI.so /usr/bin/ld: libopenshot.so.0.2.3: undefined reference to Json::Value::toStyledString[abi:cxx11]() const' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference toJson::Value::asString[abi:cxx11]() const' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference to Json::Value::operator[](std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference toJson::parseFromStream(Json::CharReader::Factory const&, std::istream&, Json::Value, std::__cxx11::basic_string<char, std::char_traits, std::allocator >)' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference to Json::Value::Value(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' collect2: error: ld returned 1 exit status make[2]: *** [src/CMakeFiles/openshot-player.dir/build.make:109: src/openshot-player] Error 1 make[2]: Leaving directory '/home/dec/libopenshot' make[1]: *** [CMakeFiles/Makefile2:238: src/CMakeFiles/openshot-player.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... /usr/bin/ld: libopenshot.so.0.2.3: undefined reference toJson::Value::toStyledString[abi:cxx11]() const' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference to Json::Value::asString[abi:cxx11]() const' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference toJson::Value::operator[](std::cxx11::basic_string<char, std::char_traits, std::allocator > const&)' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference to `Json::parseFromStream(Json::CharReader::Factory const&, std::istream&, Json::Value*, std::cxx11::basic_string<char, std::char_traits, std::allocator >*)' /usr/bin/ld: libopenshot.so.0.2.3: undefined reference to `Json::Value::Value(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)' collect2: error: ld returned 1 exit status make[2]: [src/CMakeFiles/openshot-example.dir/build.make:109: src/openshot-example] Error 1 make[2]: Leaving directory '/home/dec/libopenshot' make[1]: [CMakeFiles/Makefile2:164: src/CMakeFiles/openshot-example.dir/all] Error 2 make[1]: Leaving directory '/home/dec/libopenshot' make: *** [Makefile:155: all] Error 2

My installed json stuff is: json-c-0.13.1_20180305-x86_64-1 jsoncpp-1.8.1-x86_64-1_slonly json-c-compat32-0.13.1_20180305-x86_64-1compat32 qjson-0.9.0-x86_64-1 json-glib-1.4.4-x86_64-1

The 'compat32' package is 32bit compatibility libs; the 'slonly' package might be a version behind, as it's for slackware-14.2, but it's otherwise good. Just guessing, is there some C++ json package I'm missing?

I won't go for an AppImage if I can avoid it, because they're as slow as a windows update in loading, and slow to operate. This building is a serious waste of my time, and a drain on you guys. Why isn't there a list of dependencies you can point me at? I'm disabled, so I have time. Every project that gets big uses GNU Autotools. You write a configure.in, a Makefile.in, then run 'xmkmf -a' and everything is generated. You can put feedback in the configure script "you need to install package."

[ferdnyc]

Hmm. That error's not linking libopenshot — it's apparently already done that — it's in linking libopenshot to the openshot-example test executable.

The only thing I can think of that would cause that would be if libopenshot was compiled (in whole or in part) differently than the current build — like, say, the library was partially built with the bundled jsoncpp, because it wasn't installed on the system at first. (An example of the type of situation that would cause this, though not necessarily the exact scenario here.)

The best fix is to completely wipe out the build directory and start a new build from scratch, so that all of the objects get compiled the same way. That's the first thing I'd try. Those missing symbols make no sense if everything was compiled and linked against the same libs/headers.

...Oh, BTW, what's the 'slonly' mean on "jsoncpp-1.8.1-x86_64-1_slonly"? Is it relevant?

Anyway, if you want to be sure you're building with a compatible jsoncpp, one option is to drop the -DUSE_SYSTEM_JSONCPP=1 from the cmake command line, and let libopenshot use its bundled copy.

[ferdnyc]

Every project that gets big uses GNU Autotools.

Five, ten years ago, maybe. I can't remember the last project I heard of that switched to autotools, though plenty are switching away from it, often gleefully. CMake isn't necessarily the biggest draw, but it's one of them. (For any Qt-based project, there's a certain amount of pressure to adopt the official/native qmake, of course.)

The biggest dealbreaker on autotools is that it's great on Linux — any Unix, really — but relatively worthless on both Windows and macOS. At best, it can be hacked into working well enough for a particular project, but the heavy lifting ends up getting done by the autotools user-developers, not the autotools themselves. Whereas CMake at least supports all three OS platforms, officially and actively. (Heck, M$ Visual Studio even has CMake integration, not that we support building with Visual Studio. I'm told from time to time that "everybody" builds with Visual Studio, too.)

[BusinessKid]

.Oh, BTW, what's the 'slonly' mean on "jsoncpp-1.8.1-x86_64-1_slonly"? Is it relevant? It's an unofficial package repository offering extra stuff. There's a couple. That one is compiled against releases. The last release was 2015, due largely to the personal problems of the Slackware BDFL and his design goals for Slackware-15.0. There's a rolling release (Slackware64 Current), and I'm actually running on the July 2019 revision of that.

Anyway, if you want to be sure you're building with a compatible jsoncpp, one option is to drop the -DUSE_SYSTEM_JSONCPP=1 from the cmake command line, and let libopenshot use its bundled copy. AH! will do that. I will take a new git clone and start there.

[ferdnyc]

.Oh, BTW, what's the 'slonly' mean on "jsoncpp-1.8.1-x86_64-1_slonly"? Is it relevant? It's an unofficial package repository offering extra stuff. There's a couple. That one is compiled against releases. The last release was 2015, due largely to the personal problems of the Slackware BDFL and his design goals for Slackware-15.0. There's a rolling release (Slackware64 Current), and I'm actually running on the July 2019 revision of that.

Gotcha. I just wanted to make sure it didn't mean something potentially-complicating, like "shared libs only" or "static linking only". (Obviously, it would be a terrible abbreviation to use for either of those two phrases, simply because it could be short for EITHER of those two phrases...)

[BusinessKid]

Got libopenshot packaged today, & installed it. I tried running launch.py in openshot-qt, which pukes thusly:

bash-5.0$ PYTTHONPATH=/home/dec/openshot-qt/src python3 ./launch.py Loaded modules from current directory: /home/dec/openshot-qt/src QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-dec' app:INFO ------------------------------------------------ app:INFO OpenShot (version 2.4.4-dev2) app:INFO ------------------------------------------------ app:INFO openshot-qt version: 2.4.4-dev2 app:INFO libopenshot version: 0.2.3 app:INFO platform: Linux-4.19.34-dec2-x86_64-Intel-R-_Core-TM-_i3-3110MCPU@_2.40GHz-with-slackware-Slackware-Current app:INFO processor: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz app:INFO machine: x86_64 app:INFO python version: 3.7.4 app:INFO qt5 version: 5.13.0 app:INFO pyqt5 version: 5.13.0 language:INFO Qt Detected Languages: ['en-IE'] language:INFO LANG Environment Variable: en_IE.utf8 language:INFO LOCALE Environment Variable: language:INFO OpenShot Preference Language: Default project_data:INFO Setting default profile to HD 720p 30 fps app:INFO Setting font to /home/dec/openshot-qt/src/images/fonts/Ubuntu-R.ttf logger_libopenshot:INFO Connecting to libopenshot with debug port: 5556 app:INFO Setting custom dark theme exceptions:ERROR Unhandled Exception Traceback (most recent call last): File "./launch.py", line 103, in main() File "./launch.py", line 96, in main app = OpenShotApp(argv) File "/home/dec/openshot-qt/src/classes/app.py", line 199, in init from windows.main_window import MainWindow File "/home/dec/openshot-qt/src/windows/main_window.py", line 45, in from windows.views.timeline_webview import TimelineWebView File "/home/dec/openshot-qt/src/windows/views/timeline_webview.py", line 41, in from PyQt5.QtWebKitWidgets import QWebView ModuleNotFoundError: No module named 'PyQt5.QtWebKitWidgets' metrics:INFO Track exception: [200] http://www.openshot.org/exception/json/ | exception-successfully-sent ^C logger:ERROR Exception ignored in: logger:ERROR <module 'threading' from '/usr/lib64/python3.7/threading.py'> logger:ERROR Traceback (most recent call last): logger:ERROR File "/usr/lib64/python3.7/threading.py", line 1308, in _shutdown logger:ERROR lock.acquire() logger:ERROR KeyboardInterrupt It hangs on the line where the Ctrl_C is, and the rest is spat out. That PyQt5.QtWebKitWidgets module seems to be unavailable. BTW, I'd also value how you package openshot-qt. I did look at the README.md, but it's mostly "How Great We Are" :-P I haven't risked the setup.py as I don't want it going off and doing stuff as root! The Dependencies don't mention PyQt5.QtWebKitWidgets. StackOverflow does mention it; it's apparently unavailable and dropped in qt5.6 or so. They recommend some other widget set. But I can't find which page I found that on. Was it qt5webengines? https://github.com/conda-forge/pyqt-feedstock/issues/19

I have these qt5 packages installed, as well as wxwidgets or the like /var/lib/pkgtools/packages/qt5-5.13.0-x86_64-1alien /var/lib/pkgtools/packages/qt5-webkit-5.212.0_alpha3-x86_64-1alien

Before you ask, alien packages are developed by a slackware dev, although they are 'unofficial.' He does the multilib stuff, the 64/32 builds (e.g. wine) and undoubtedly keeps the best repository.

[ferdnyc]

No module named 'PyQt5.QtWebKitWidgets'

Looks like Qt may have webkit installed, but PyQt doesn't. In Fedora's packaging that's also a separate subpackage (python3-qt5-webkit), just like qt5-qtwebkit is on the Qt side.

Also, unrelated, but no reason to set PYTHONPATH to the directory you're running in, when launching OpenShot from source with launch.py. That's implied. The only reason you'd need to set PYTHONPATH is if you need to point it to the libopenshot bindings in an uninstalled / non-default location (to make import openshot work).

[ferdnyc]

Oh, sorry, I didn't see some of your commentary towards the end as it snuck into the quoted section.

It hangs on the line where the Ctrl_C is, and the rest is spat out. That PyQt5.QtWebKitWidgets module seems to be unavailable.

Agreed. It's part of PyQt5.QtWebKit, which like I said appears to be missing.

BTW, I'd also value how you package openshot-qt. I did look at the README.md, but it's mostly "How Great We Are" :-P

Fair.

I haven't risked the setup.py as I don't want it going off and doing stuff as root!

setup.py is how we package OpenShot, for Fedora. It won't do anything as root unless you run it as root. (Which you shouldn't do, as it's not necessary.) Sorry, thought I'd posted this part. It's also macro-driven, in fact the commands are all default Fedora packaging macros, but they expand to:

%build
/usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s'

%install
/usr/bin/python3 setup.py install -O1 --skip-build --root %{_buildroot}

The Dependencies don't mention PyQt5.QtWebKitWidgets. StackOverflow does mention it; it's apparently unavailable and dropped in qt5.6 or so.

That's QtWebKit itself, and outdated info. The QtWebKit module has been maintained as an external Qt component since it was dropped from the Qt distribution. It was previously bundled with Qt, but removed as of Qt 5.6, so it's now a separate package. But you already have QtWebKit installed so that's neither here nor there.

PyQt5.QtWebKit and PyQt5.QtWebKitWidgets are the Python wrappers for the QtWebKit modules, and appear to be what's missing.

They recommend some other widget set. But I can't find which page I found that on. Was it qt5webengines?

QtWebEngine was Qt's replacement for QtWebKit, yes, but it's not compatible with OpenShot. (It's not a direct replacement, in fact there are significant differences between the two.)

[BusinessKid]

%build /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s' %install /usr/bin/python3 setup.py install -O1 --skip-build --root %{_buildroot}

Root has to be used in the install to make directories like /usr/bin which is root:root owned. I'm afraid you were still thinking in python on the install line. It installed to a directory %{_buildroot} where I was; that was ok, because I could unset buildroot and copy it manually to my $BUILDROOT. So, I'm shy of the PyQt5.QtWebKit and PyQt5.QtWebKitWidgets modules. I'll do a search for them tomorrow, and see if I can turn up anything.

[ferdnyc]

Root has to be used in the install to make directories like /usr/bin which is root:root owned.

Sure, unless a buildroot is used. But point is, it won't elevate itself to root. If you run without root privs and without setting a buildroot, it'll simply fail with permission errors. Scripts that abuse sudo to "automatically" grant themselves root powers (Read: MALICIOUSLY SEIZE ROOT ACCESS) are the devil, that kind of shit really chaps my ass. No such tomfoolery with setup.py.

I'm afraid you were still thinking in python on the install line. It installed to a directory %{_buildroot} where I was; that was ok, because I could unset buildroot and copy it manually to my $BUILDROOT.

Yeah, sorry, that's not actually Python either, it's RPM spec macro. Equivalent to $BUILDROOT.

So, I'm shy of the PyQt5.QtWebKit and PyQt5.QtWebKitWidgets modules. I'll do a search for them tomorrow, and see if I can turn up anything.

nod They'll be packaged/installed together, PyQt5.QtWebKitWidgets can't be separated from PyQt5.QtWebKit. It's just one of the component modules.

[BusinessKid]

So, I'm shy of the PyQt5.QtWebKit and PyQt5.QtWebKitWidgets modules. I'll do a search for them tomorrow, and see if I can turn up anything.

OK. What I found was that the 2 modules above have been deprecated. There some replacement being worked on - pyqt5.qtwebenginewidgets.pyd. When I go to download it, there's only windows versions. Apparently the guy ripped off those deprecated modules and cobbled pyqt5.qtwebenginewidgets.pyd together. He's still deciding on what to put in - he has a page up for voting up/down the various bits with a view. to settling on a version. That leaves you with some decisions to make, but it doesn't help me. I'll have to go the AppImage Route after all. I have a windoze 10 vm and could set up python there, but that's a learning curve I do not want.

So thank you guys & ferdnyc in particular for all the help, but we appear to have fallen at the last hurdle because you're referencing something that no longer exists. I don't see that as my problem, I see it as yours. I'll probably download the AppImage before the day is out. Please inform all who matter that the source cannot be compiled any longer & don't update your systems until you decide what to do about this.

[ferdnyc]

OK. What I found was that the 2 modules above have been deprecated.

True. Deprecated does not mean removed, it means just that: Deprecated. No longer supported for use, not advisable for new code/projects, and subject to possible removal at any time.

It does not mean "gone", "not usable", or "no longer working".

So thank you guys & ferdnyc in particular for all the help, but we appear to have fallen at the last hurdle because you're referencing something that no longer exists. I don't see that as my problem, I see it as yours. I'll probably download the AppImage before the day is out. Please inform all who matter that the source cannot be compiled any longer & don't update your systems until you decide what to do about this.

I have no idea where you're getting your information, but it's wrong.

The QtWebKit and QtWebKitWidgets module bindings are included in even the latest PyQt5_gpl-5.13.0.tar.gz source tarball downloadable from Riverbank (the authors).

If QtWebKit is installed in Qt, when PyQt5 is built, those modules will be included. I am using them, via officially-supported Fedora packages, Right. Now. Fedora is not in the habit of packaging software which "no longer exists".

[BusinessKid]

I have no idea where you're getting your information, but it's wrong.

I'm glad to hear it. I have those downloads, and ended in an interesting pickle. Qmake is part of qt; Slackware-14.2 offers qt-4.8.7, although qt5 is available as an unofficial extra. My qmake binary was from qt-4.8.7. So I remover that reinstalled qt-5.11.3 to compile your thing, but that comes with no qmake, presumably to avoid the standard package. Catch-22. I'll go off and sort myself out on that one as lazily as possible, and report back.

[BusinessKid]

Went there, running on qt-5.11.3 (an Alien package). a little detective work found qmake as qmake-qt5, so a symlink found that. Your riverbank computing gave me sip-4.19.19 and pyqt5-5.13. I'm being careful to package everything, so I can uninstall everything a lot more painlessly than I installed them! Now I get less of an attempt to run than I did before

bash-5.0$ python3 ./launch.py Traceback (most recent call last): File "./launch.py", line 47, in from classes import info File "/home/dec/openshot-qt/src/classes/info.py", line 30, in from PyQt5.QtCore import QDir RuntimeError: the sip module implements API v12.0 to v12.6 but the PyQt5.QtCore module requires API v12.7 bash-5.0$

I'm ready for a home for the bewildered… BTW, I'm glad to hear Fedora no longer package outdated software. The last time I was into Fedora was their (discontinued) Electronic Spin - about 10-15 years back? I built a better setup for Electronics myself on Slackware. They were packaging dead projects (not just Electronic ones) if it suited them, anytime you got used to something they changed it and told you to shut up and get used to it. They opted for blackdown(?) as a flash player (which sucked) and you couldn't help the feeling that you were a crashtester for RHEL when you updated and the kernel puked (again!) and you can't boot. Back in the day, Tomsrtbt saved my butt more often than I care to remember.

[ferdnyc]

RuntimeError: the sip module implements API v12.0 to v12.6 but the PyQt5.QtCore module requires API v12.7

That sounds like you built PyQt5 with SIP API v12.7 (which I'm guessing is what sip-4.19.19 implements, not sure since Fedora is still on 4.19.17), then tried to use it with an earlier sip module that only supports up to v12.6. Without knowing any of the paths involved I'm only guessing, but part of SIP is a Python extension (implemented as a shared library, like _openshot.so from libopenshot), so if you have an earlier version in /usr/lib64/pythonM.N/site-packages/ then it may be trying to load that one instead of your newer one.

You could try commands like:

$ pydoc3 PyQt5
$ pydoc3 PyQt5.sip
$ pydoc3 sip

Each module's docs will list a FILE section at the bottom showing the path it's loading from. I get (respectively):

FILE
    /usr/lib64/python3.7/site-packages/PyQt5/__init__.py
FILE
    /usr/lib64/python3.7/site-packages/PyQt5/sip.so
FILE
    /usr/lib64/python3.7/site-packages/sip.so

Entirely offtopic after this point

BTW, I'm glad to hear Fedora no longer package outdated software.

Oh, we package a ton of outdated software. People want compatibility, and existing code often relies on outdated software. Hell, QtWebKit is very outdated software. But anything packaged still has to exist, and if it exists it's hardly exclusive to Fedora.

(A lot of Red Hat internal projects that they maintain kind of are, since they're the sole maintainers and some of that crap is so ancient nobody else is interested in developing it. But even those are still open-source projects in public repos, things that anyone on a different distro could still use if they wanted.)

The last time I was into Fedora was their (discontinued) Electronic Spin - about 10-15 years back?

I never did anything with the Spins, so I can't comment on those. Never really understood the point, since I don't build a dedicated computer for each type of project I want to do. I have one computer that needs to be able to do everything I need it to.

I built a better setup for Electronics myself on Slackware.

Why couldn't you have built a better setup for Electronics yourself in Fedora? And contributed those improvements back?

They were packaging dead projects (not just Electronic ones) if it suited them

I don't think anyone packages anything simply because it suits them, they do it because those packages still have users. I have some packages installed on my system, both self-built and from the official repos, that are built from codebases that haven't been updated in more than a decade. Typically because they're still useful to me, and nobody's developed a better replacement yet.

anytime you got used to something they changed it and told you to shut up and get used to it.

Well, if the only reason for the objection is "It's different", then... yeah. Humans have a knee-jerk reaction to reject anything new and unfamiliar, even if it's better than the old thing they're used to. Understandable, but not the impulse that should govern a bleeding-edge distro like Fedora.

They opted for blackdown(?) as a flash player (which sucked)

*shrug* Fedora does not package proprietary software. Doesn't mean you can't use proprietary software. I always just installed Adobe's flash-plugin package, they still to this day maintain a yum repo that publishes RPMs of their releases. (Not that it hasn't been years since I last had a browser that still supports their NPAPI plugin. Though I do still have it installed on my system, for some reason.)

$ rpm -qi flash-plugin
Name        : flash-plugin
Version     : 32.0.0.223
Release     : release
Architecture: x86_64
Install Date: Tue 09 Jul 2019 01:09:33 AM EDT
Group       : Applications/Internet
Size        : 21070700
License     : Commercial
Signature   : DSA/SHA1, Fri 21 Jun 2019 08:22:39 PM EDT, Key ID 3a69bd24f6777c67
Source RPM  : flash-plugin-32.0.0.223-release.src.rpm
Build Date  : Fri 21 Jun 2019 07:03:04 PM EDT
Build Host  : frtubt-jnkns6
Relocations : (not relocatable)
Packager    : Adobe Systems Inc.
Vendor      : Adobe Systems Inc.
URL         : http://www.adobe.com/downloads/
Summary     : Adobe Flash Player NPAPI
Description :
Adobe Flash Plugin 32.0.0.223

and you couldn't help the feeling that you were a crashtester for RHEL

Because you are! Which means you get to preview all of the newest changes they're working on. Sounds like a win-win to me.

For people who demand stability over recency, there's always CentOS which basically never updates anything and is always years behind the latest releases for supported packages. Deliberately. If you're running production servers or whatever, then obviously you go that route, since doing it on Fedora would be crazy. But the needs of server systems (stable, unchanging, predictable) are very different than my needs for my desktop.

[BusinessKid]

The way I read that, it was an error between the Riverbank computing stuff. Anything with 'pyqt' in it is theirs. I found some guy's email on the Changelog of PyQt5, and emailed him. No answer yet. I named my package sipmodule-4.19.19-dec, but found today there was already a package sip-4.19.8. I got that out, reinstalled my own, and thought I was sorted, but no dice. I got the same 3 files as you did with pydoc, ran 'ls -lh' on them, and they're all recently dated in the last day or so. I even checked if it was picking up a python2.7 module, but there's nothing remotely similar. Everything on my system is packages, listing all the files with their paths in plain text. So I grepped them for PyQt5.QtCore but found nothing There's PyQt5, & QtCore, but not the pair together.

RuntimeError: the sip module implements API v12.0 to v12.6 but the PyQt5.QtCore module requires API v12.7

I also tried changing the /usr/bin/python symlink to point to python3, but no dice. There's a dev release on the riverbank site now of PyQt5_gpl-5.13.1, but I imagine that's a bug fix. Are we that stuck to be grasping at straws? On Fedora: yes, we can convict them of inflicting alpha kernel patches etc. on users. The only reason I didn't purge libflashplayer.so is that 1 or 2 of the local tv and news websites were very slow to leave flash behind. My pet hate for rpms comes from when the Pentium was just out and hugely expensive. I bought an overclockable AMD i586-133 P75, i.e. an amd i586 which ran all the Pentium instructions, and approximately matched a P75. But it sat in a 486 socket, and as a newbie I spent a day trying to figure out how to install a particular i586 rpm. I eventually found the key was 'ignorearch.' It had identified it as a '486 :-/. Overclocked, it ran as a P90.

[BusinessKid]

Found a few problems like mine on stackoverflow. It's usually the sip module. In one case the guy did

import sip print(sip, sip.SIP_VERSION_STR) and got different versions. But I get the same versions (Now 4.19.19dev). I tried sip-4.19.18(stable). Same error; went to qt-5.13.0; same error. Tried a few versions of pyqt5; Error remains.

[ferdnyc]

@BusinessKid

One test that may be informative, in python3:

>>> import sip
>>> print(sip, sip.SIP_VERSION_STR)
<module 'sip' from '/usr/lib64/python3.7/site-packages/sip.so'> 4.19.17
>>> import PyQt5
>>> print(PyQt5.sip, PyQt5.sip.SIP_VERSION_STR)
<module 'PyQt5.sip' from '/usr/lib64/python3.7/site-packages/PyQt5/sip.so'> 4.19.17

(Assuming import PyQt5 succeeds and doesn't hit you with the same API version error.)

[ferdnyc]

I named my package sipmodule-4.19.19-dec, but found today there was already a package sip-4.19.8. I got that out, reinstalled my own, and thought I was sorted, but no dice.

Did you rebuild PyQt5 after? SIP is a build dependency of PyQt5, not (just) a runtime dependency, so it's unlikely that things can be swapped out without rebuilding afterwards.

Everything on my system is packages, listing all the files with their paths in plain text. So I grepped them for PyQt5.QtCore but found nothing There's PyQt5, & QtCore, but not the pair together.

Because Python module components represent a directory hierarchy. import PyQt5.QtCore will look for things like PyQt5/QtCore.py and PyQt5/QtCore/__init__.py in the module search path.

ETA: Or, in the case of SIP-wrapped bindings, PyQt5/QtCore.pyi and PyQt5/QtCore.so.

[ferdnyc]

Those .pyi files can also help in checking what SIP version they were built with. From the top of my /usr/lib64/python3.7/site-packages/PyQt5/QtCore.pyi:

# The PEP 484 type hints stub file for the QtCore module.
#
# Generated by SIP 4.19.17
#
# Copyright (c) 2019 Riverbank Computing Limited <info@riverbankcomputing.com>
# 
# This file is part of PyQt5.

[BusinessKid]

Did you rebuild PyQt5 after? SIP is a build dependency of PyQt5, not (just) a runtime dependency, so it's unlikely that things can be swapped out without rebuilding afterwards.

£@€&$%! doing it now. I also found orphaned directories 'pyqt4' in the site-packages and purged that also. I'm rebuilding PyQt5-5.13.0 now. That'll be turning wheels for quite a while. The sip module seems right @4.19.19dev1907211649

[BusinessKid]

Let's put an end to this here, and now. I removed sip and pyqt5, purged ~site-packages of spurious entries, reinstalled sip-4.19.19.dev1907211649, & PyQt5_gpl-5.13.0. So I started getting this error

bash-5.0$ PYTHONPATH=/home/dec/openshot-qt/src python3 ./launch.py Traceback (most recent call last): File "./launch.py", line 47, in from classes import info File "/home/dec/openshot-qt/src/classes/info.py", line 30, in from PyQt5.QtCore import QDir ModuleNotFoundError: No module named 'PyQt5.sip'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "./launch.py", line 50, in import openshot_qt ModuleNotFoundError: No module named 'openshot_qt'

Thinking sip may be wrong because pyqt5 wasn't installed when I built it, I installed it, rebuilt sip, & rebuilt pyqt5. (The 'upgradepkg command in Slackware doesn't remove any added files when it removes a package). I still get the above error. I'm going the Appimage route - life's too short for this. I'll spare you my opinions at this stage, save to say it's the second time in the last 20 years that I have given up on something. I'll purge the dependencies too. I won't need them with an Appimage, will I?

[BusinessKid]

/mutter, growl, etc You've been very nice to me, and helpful. I'm very grateful. So I won't write what I feel like. As some smart-alec put it: "Speak when you're angry, and you'll make the bast speech you'll ever regret." I downloaded OpenShot-v2.4.4-x86_64.AppImage from openshot.org, Then I made a symlink as 'openshot.' Here's the output:

bash-5.0$ /opt/openshot Loaded modules from current directory: /tmp/.mount_YY0oPG/usr/bin Traceback (most recent call last): File "/home/gitlab-runner/builds/5cd61c66/0/OpenShot/openshot-qt/openshot.py", line 18, in swig_import_helper File "/usr/lib/python3.4/imp.py", line 297, in find_module ImportError: No module named '_openshot'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.4/dist-packages/cx_Freeze-4.3.4-py3.4-linux-x86_64.egg/cx_Freeze/initscripts/Console.py", line 27, in File "openshot_qt/launch.py", line 55, in from classes.app import OpenShotApp File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2237, in _find_and_load File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2226, in _find_and_load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1200, in _load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1129, in _exec File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1471, in exec_module File "/usr/lib/python3.4/importlib/_bootstrap.py", line 321, in _call_with_frames_removed File "/tmp/.mount_YY0oPG/usr/bin/classes/app.py", line 41, in from classes import info, settings, project_data, updates, language, ui_util, logger_libopenshot File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2284, in _handle_fromlist File "/usr/lib/python3.4/importlib/_bootstrap.py", line 321, in _call_with_frames_removed File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2237, in _find_and_load File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2226, in _find_and_load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1200, in _load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1129, in _exec File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1471, in exec_module File "/usr/lib/python3.4/importlib/_bootstrap.py", line 321, in _call_with_frames_removed File "/tmp/.mount_YY0oPG/usr/bin/classes/logger_libopenshot.py", line 31, in import openshot File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2237, in _find_and_load File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2226, in _find_and_load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1191, in _load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1161, in _load_backward_compatible File "/home/gitlab-runner/builds/5cd61c66/0/OpenShot/openshot-qt/openshot.py", line 28, in File "/home/gitlab-runner/builds/5cd61c66/0/OpenShot/openshot-qt/openshot.py", line 20, in swig_import_helper File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2237, in _find_and_load File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2226, in _find_and_load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1191, in _load_unlocked File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1161, in _load_backward_compatible File "/usr/lib/python3.4/importlib/_bootstrap.py", line 539, in _check_name_wrapper File "/usr/lib/python3.4/importlib/_bootstrap.py", line 1715, in load_module File "/usr/lib/python3.4/importlib/_bootstrap.py", line 321, in _call_with_frames_removed ImportError: libselinux.so.1: cannot open shared object file: No such file or directory

Now selinux isn't installed and people run happier, more secure systems without it. But I did actually have a copy of selinux.so.1 in an app called Shotcut, which is also a video editing suite. That uses an approach I would recommend. It distributes a compressed tar, which expands like firefox, or palemoon as a directory, they stick a startup symlink or script in /usr/bin, and away you go. That's also there to be tried out. So a link went in /usr/lib64 to your competition's libselinux.so.1, and it crapped out in much the same way for the lack of libpcre.so.3 (again in shotcut). Talk it over with your friends. I seem to have one of the most openshot-unfriendly systems in existence. I can't mess with the Appimage - I believe I can loop mount it, but you'd need to know about AppImages before going that route. I do believe you weren't aware how much your Appimage relies on system libs, which is not good, as some systems mightn't have them. I have libpcre-1.2.11 installed. Why it's so far back I don't know. But it is.

Your move, I think. I have just one video editor to try out ATM, and it isn't yours.

[inukaze]

Someone had a Script for Slackware to Download & Compile OpenShot without the error ModuleNotFoundError: No module named 'PyQt5' ?

[BusinessKid]

Yes, there's a lot of extra repositories for slackware, of varying quality. Slackware also hasn't had an official "release" since 2016. So it's a bit like Debian - always behind, but there's a rolling release version. PyQT5 is now out there in one of those, (although I think you wanted a later version than they provide).

So I took a break. When I came back to it, I found PyQt5, shoehorned it in, and actually got openshot going. It's good. Then, recently I have had to do a total disk wipe and total reinstall. March's rolling release has actually got PyQt5-5.13.2 which is probably quite recent. I have that installed now, but I don't have openshot - yet. I'm still bedding stuff in, as I didn't get a fix by reinstalling my last backup. Extras come later.

[inukaze]

I just want a version of kdenlive with "compose" plugin, because i had compile from SlackBuilds, and after i test version from slonly, and don't had that plugin, just "Composite & Transform" but is diferent from the plugin i need to compose 4 videos in the same screen. with this plugin under slackware, i can set the region on the screen but just 1 video be rendered, not the 4 outputs.

And the AppImage don't work for me, because i don't had things like SystemD, PulseAudio neither Avahi. (i really don't understand if this are optional components must be installed to launch apps like if are not optionals components, for the distros are just making a sick dependency on that softwares, should be detected and use if available)

[BusinessKid]

Look, inukaze, this is an old thread about compiling/installing on Slackware. This bug is closed, because I closed it. Get onto http://slackware.pkgs.org and you'll find links to all the repos there. You need to be giving an awful lot more info to get anything sorted: Distro & kernel version, versions of all extra components, video drivers, your openshot version, your kde version, & your problem. Stop posting here if you want an answer from devs and start a new thread

[inukaze]

i am asking to users, not to devs because the video-editors devs never answers fine. and well this bug can be old, but still exist, and the package from repositories : Slackware, Alien, SLOnly, SlackBuilds (SBo). Don't work if PulseAudio is not installed first.

Distro : Slackware(64) 14.2 Kernel : 4.4.14

you want all packages i had installed manually in each version for each and each library installed on my distro ?

video drivers : nvidia 304.137

openshot version : latest from github

kde version : from when a group of persons of dev team are declare like version ?

my problem : segmentation fault, without errors on the output in the terminal neither with gdb. that prevents i can use openshot under Slackware. i don't know if debug flag really works.

[BusinessKid]

A quick reaction to that is that it will never work, and here's why. Slackware-14.2 was released in 2016. openshot from github uses the latest from everything. Library versions are going to be all wrong and python3 support is going to be inadequate. If you update eerything, you run a serious risk of breaking the base distro. I suggest you update to slackware-current.I have the version from 24-March-2020 and it has PyQt5 like I mentioned, although previous versions of ~Current don't. As for kde versions, you only have to look at the package list (/var/log/packages in 14.2, /var/lib/pkgtools/packages in Current, although var/log/packages is still symlinked) to find versions.