Hello,
With the newest Manjaro stable update release (5.10.30-1) few days ago, i got a serious bug on shotcut and this Application no longer works, when i change the stock presets for video encoding and click on export file it does created a “job successfull” icon but its fake and but there is no file and its all done in zero seconds.
So i’m created a bug report to the shotcut forum, but the ticket system froze my new created account and it takes time to get support there. (Developer just response, that he won’t give me support)
In the mean time i want to ask, how i can rollback to the last working version.
I never have done anything like this, so it would be nice if someone give me a step by step info how to do this.
Shotcut is inherited from Arch repo - it is not built by or for Manjaro.
You cannot rollback Manjaro unless you have a timeshift backup.
My personal guess is that shotcut will work with a fresh install and it will be difficult to reproduce the issue you have - simply becasue every system is different in how the system is put together.
Manjaro only provides a basic installation which upon installation is governed by your hardware and the subsequent choice of packages to suit your particular needs - therefore it is difficult to advise.
Rolling back a rolling a release is next to impossible.
That’s really bad news… i really don’t think that a full Manjaro reinstall will help to fix this issue… because when i just don’t change settings in shotcut, the programm works and encode the video.
But without changing settings, this programm is almost useless for me.
I just read “official repositories” in pamac browser. Anyways, this package got a bug and its not from my Manjaro install, im glad that i can still use Shotcut.
I was very worried about… because it took alot of time to learn how everything works.
Edit: @linux-aarhus Thanks for the help.
If i want to have this bug fixed from Manjaro Repo install, i should E-Mail the packager, who provided this build?
There might be some trouble when an application release cycle is “too slow”. For instance, Blender usually releases a new version months after its dependencies do, so here we get those updated dependencies “ahead of schedule”. Maybe that’s also the case for Shotcut, in which case you should rather use a Snap or Flatpak like @linux-aarhus suggested.
Okay thanks for the info, i keep checking the release cycles from developer and how they sync with the manjaro repo’s, if this is the case i will switch to flatpack.
At this moment i’m just happy that everything works as expected
That is usually a good idea but in this case I don’t recommend it.
Arch packagers don’t care about the distribution which build on their base and this is because the Arch philosophy is user-centric - Arch provides a set binary packages - what the user do is the user’s responsibility and problem.
So unless you can recreate the problem on a pure hand built arch system don’t bother to report - your report will most like be closed with with comment on - not arch - no problem - and I can’t say I blame them.
I never thought of that… Have you ever run into a situation where a major application, like Blender, doesn’t work after an update? I haven’t so far
How does pacman or pamac handle this — an application is installed and one or more of it’s dependencies has an update. Do you get a message like “Breaks dependency” and given the opportunity to terminate the install? What is the state of /var/cache/pacman/pkg?
Best practice for developing libraries used by other application is to not make and API/ABI changes that break compatibility with a minor or patch version upgrade.
E.g. appxyz should NOT break when libxyz is let’s say upgraded from version 1.1.0 to version 1.2.0 or 1.1.1, etc. The library is supposed to keep backwards compatibility.
Hence, normally, package dependencies are not requiring a specific version of a library (well, sometimes you see libxyz>=1.1.0 which says, I need that lib with that version or greater, normally not the other way around though).
Now if there is a major version update for a library, let’s say libxyz is available in version 2.0.1 it may introduce breaking changes. Hence in those cases it’s common to have a separate package “libxyz2”.
(f.e. gtk2, gtk3, gtk4…)
Now that’s the ideal world. In reality it still happens that breaking changes are introduced with a minor version update, etc…
Like others already suggested, flatpak Version seem like something you would want because it should stay stable for longer.
But everything is possible if you have enough nervers and time to burn. You can try one of the methods shown HERE, I would try a downgrade and don’t forget to make a backup before doing anything.
I managed to restore a broken pacman once with the cache method after restore of my system broke pacman.
You should be using timeshift in any case, even if usualy nothing brakes for you. Using a system with rolling release is like walking on a minfield, at some point something will explode.
