openshot 3.0

[Jerry3904]

This is my standard video editor and I was interested today in seeing that a major upgrade has been released. I added this repo:

Code: Select all

deb https://ppa.launchpadcontent.net/openshot.developers/ppa/ubuntu kinetic main 

and then tested what it would need to install on MX-21 Xfce

Code: Select all

└─> sudo apt upgrade openshot -s
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
openshot is already the newest version (2.5.1+dfsg1-1).
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  libjs-jquery-ui python3-pyqt5.qtwebkit
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  libminizip1 libqt5opengl5 libqt5webengine-data libqt5webengine5 libqt5webenginecore5 libqt5webenginewidgets5 libre2-9 python3-defusedxml
  python3-pyqt5.qtopengl python3-pyqt5.qtwebchannel python3-pyqt5.qtwebengine python3-sentry-sdk python3-xdg
The following packages will be upgraded:
  openshot-qt
1 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Inst libminizip1 (1.1-8+b1 Debian:11.6/stable [amd64])
Inst libqt5opengl5 (5.15.2+dfsg-9 Debian:11.6/stable [amd64])
Inst libqt5webengine-data (5.15.2+dfsg-3 Debian:11.6/stable [all])
Inst libre2-9 (20210201+dfsg-1 Debian:11.6/stable [amd64])
Inst libqt5webenginecore5 (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Inst libqt5webengine5 (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Inst libqt5webenginewidgets5 (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Inst python3-defusedxml (0.6.0-2 Debian:11.6/stable [all])
Inst python3-pyqt5.qtopengl (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Inst python3-pyqt5.qtwebchannel (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Inst python3-pyqt5.qtwebengine (5.15.2-2 Debian:11.6/stable [amd64])
Inst python3-sentry-sdk (0.13.2-1 Debian:11.6/stable [all])
Inst python3-xdg (0.27-2 Debian:11.6/stable [all])
Inst openshot-qt [2.5.1+dfsg1-1] (3.0.0+dfsg2+1609+202212112000~ubuntu22.10.1 OpenShot: Stable PPA - Official Releases:22.10/kinetic [all])
Conf libminizip1 (1.1-8+b1 Debian:11.6/stable [amd64])
Conf libqt5opengl5 (5.15.2+dfsg-9 Debian:11.6/stable [amd64])
Conf libqt5webengine-data (5.15.2+dfsg-3 Debian:11.6/stable [all])
Conf libre2-9 (20210201+dfsg-1 Debian:11.6/stable [amd64])
Conf libqt5webenginecore5 (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Conf libqt5webengine5 (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Conf libqt5webenginewidgets5 (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Conf python3-defusedxml (0.6.0-2 Debian:11.6/stable [all])
Conf python3-pyqt5.qtopengl (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Conf python3-pyqt5.qtwebchannel (5.15.2+dfsg-3 Debian:11.6/stable [amd64])
Conf python3-pyqt5.qtwebengine (5.15.2-2 Debian:11.6/stable [amd64])
Conf python3-sentry-sdk (0.13.2-1 Debian:11.6/stable [all])
Conf python3-xdg (0.27-2 Debian:11.6/stable [all])
Conf openshot-qt (3.0.0+dfsg2+1609+202212112000~ubuntu22.10.1 OpenShot: Stable PPA - Official Releases:22.10/kinetic [all])

I don't see a stumbling block so I have 2 questions:
1. I use it on my desktop/business computer--any reason not to go ahead? (Chris tells me that he has been using the appimage without problem, FWIW).
2. If my machine doesn't blow up as a result, could we get this into MX Test Repo at some point?

[Jerry3904]

Hmmm. Tried it, and the ppa apps won't install for the Ubu versions I tried (jammy, kinetic).

Just going to chill for a while...

[dolphin_oracle]

I'm surprised it won't install if the simulated run worked. that's unusual.

openshot flatpak is up to 3.0

[AVLinux]

Hi,

I think this begs a larger question... There are probably a handful of these 'big' multimedia apps that have gotten quite popular and most also now are cross-platform.. (Openshot, Kdenlive, Audacity3, Musescore, Cinelerra-GG to name only a few..)

They are complex, monolithic and quite popular, they have numerous regular updates and they often have a lot of support library dependencies required from Debian and in the example of Kdenlive require the runtimes of KDE which may not be wanted on XFCE4 and other 'lighter' systems. I think they ask and demand a lot of a small and already overworked Package Team and I think a lot of Users of these apps are already transitioning to AppImage and Flatpak for the immediate upgrades without waiting on Packaging and for deploying on multiple installed systems..

In AV Linux I have resorted to wrapping AppImages of a handful of these super popular apps into Debs and putting them on the ISO that way because I already feel I'm asking a lot here and @Stevo and @timkb4cq have already been accommodating beyond belief.. this is a strategy that won't work for MX obviously but I do think expecting all of this kind of stuff to get into MX and be maintained is a HUGE burden and I think it is something that is kind of occurring in the background..

Of course as we love to do in the Linux world we had a pretty great idea in AppImage (that wasn't perfect but at least was self-contained and sandboxed in the Userspace) and now Flatpak has taken over and I think it is absolutely the wrong way to do things, it's basically a re-invention of the Repository system with metapackages and multiple dependencies strewn throughout the filesystem but what I think about it doesn't matter... it's here and it's not going away..

Anyway I wonder if some polling about how the average MX User gets the latest Multimedia applications onto their system would shed some light on what future direction and emphasis accommodating this kind of highly popular and specialized stuff should have...?

[Stevo]

Remember, Ubuntu debs since Jammy by default use a form of data compression that Debian doesn't support. It's possible for the Ubuntu packager to tell it to use xz to make it compatible, but apparently no so in this case.

The simulation just looks at whether the dependencies are met in Debian. Then you ran into the compression issue.

[Jerry3904]

So can we use the version before jammy?

[wdscharff]

Openshot and shotcut always publish an app image at the same time.
In contrast to the flatpaks and *.deb, I have never had any problems with the appimages, which is why I have been using the appimage as a matter of principle for two years.
After my experiences with appimages so far, I now use appimages as a matter of principle (if they are directly from the author), the significantly higher space requirement at a time when a 1TB NVME costs 100€ is not relevant for me. At least for video editing, image processing and some tools like Drill (file search) or czkawka (doublet search). My cloud and my email client are also appimages.
For some programmes I don't even know if they are still offered in classic packages for the various distributions or only as appimages and/or flatpaks.

openshot v3 is also very successful :-)

[Stevo]

I can port them over to the MX repo tomorrow sometime.

[Stevo]

openshot-qt 3.0 should be in our MX 19/21 test repos soon for i386, amd64, and armhf.

[MXRobo]

Thank you Stevo, I was considering possibly requesting Openshot 3.0 (but then I saw your post stating that you'll be porting them over sometime tomorrow) after I saw wdscharff's post and found that it has more than 1000 improvements & fixes and is supposed to be much more stable – although using an AMD A6 is not what to use for video editing, but still issues with Ryzen 3, now have a Ryzen 7.

I was reluctant to request as AVLinux said, the MX team does so much as it is, and I thought maybe I should just install the Flatpak or Appimage as AVlinux (sort of) and wdscharrf do.

I installed Flowblade, Shotcut, and Pitivi thinking that I'd never use Openshot again due to its bugs and problem using flac for audio (which may still be an issue – don't know), but I'm familiar with Openshot, so I'll definitely try it.

Anyway I look forward to – oh I just looked, it's available now – great!

Any thoughts on using Flatpaks and Appimages instead of linux apps, it seems as though it would save you some work, and disk space is rather inexpensive – particularly recently?

FYI – I very rarely use Flatpaks.