Collaborate with upstream and upstream some patches

[guihkx]

@HugLifeTiZ suggested that we could maybe add our input to this upstream pull request.

I also want to try to upstream some patches I've recently introduced.

But first, I need to check if a fix doesn't already exist in Avidemux's upstream master branch. These are the patches:

• Fix issues with appstreamcli validation
• Force libdir location (TODO: This patch is not ideal, needs a better solution)
• Add /app/include/ffnvcodec to Avidemux's nvcodec search path (TODO: Verify if this has been fixed in master)
• Don't manually add an extension when saving a file (This patch is technically correct, but upstream might reject it because it's only an issue when Avidemux is running with restricted filesystem access)

[guihkx]

I'm not sure if someone has attempted to make this an official package in the past, but I suspect that upstream might not be interested in doing so...

I found this recent bug report on Avidemux forums.

The bug report itself is not relevant to this discussion, but the response from the main commiter of Avidemux, probably confirms my suspicion (this was translated using Google Translate, and I added the emphasis):

Good morning,

Did you reinstall Avidemux as an (official) appImage or did you compile it yourself from source (git master, preferably)?

Sorry for repeating myself, but Avidemux packaged in Flatpak is absolutely not supported here.

Cdlt

In any case, I think it's worth a shot.

[TiZ-HugLife]

Well, that's a funny little thread you found: it looks like the OP is having document portal troubles. Specifically, it looks like they're hitting a variant of #14. That thread was made March 16, when you committed the patch to address it. So I wonder if the OP's problem is actually fixed.

It's hard to tell if the main committer is one of those "never Flatpak ever" regressives holding back our entire ecosystem, or if they have specific, concrete reasons not to support this package, like if a quirk in our build process, or the containerization, creates problems for the package that they haven't documented anywhere. Or maybe they only support whatever distribution methods they deem "official", and it's solely a matter of pragmatism. In that case, I wish they would say "go to the Flathub package's issue tracker" instead of "don't use Flatpaks."

The main committer seems to favor AppImage. I wonder why that is. There are bound to be issues that appear in the AppImage version that don't appear here. Like this one. This kind of nonsense is inevitable with AppImage. That commenter's distro was ancient, but this is a cyclical issue inherent to AppImage, and it will come back. It would be a good use of the maintainer's time to provide guidance and support for our packaging. But if they're a "never Flatpak ever" kind of person, there's literally nothing we'll be able to say to them to convince them of that.

So we may never be able to become "official." Oh well, that's fine. If their officially supported distributions are AppImage and "build it from source," then we're just as unofficial as any distro would be.

We should participate in that issue, but not with aims to become an officially supported packaging method, but rather, because we are packaging it, and anyone packaging it, regardless of what for, would benefit from improved organizational structure in Avidemux.

[guihkx]

Well, that's a funny little thread you found: it looks like the OP is having document portal troubles

Indeed. I've opened #26 so we can discuss it.

The main committer seems to favor AppImage. I wonder why that is. There are bound to be issues that appear in the AppImage version that don't appear here. Like this one.

That's a definitely good point in favor of Flatpak, yeah.

We should participate in that issue, but not with aims to become an officially supported packaging method, but rather, because we are packaging it, and anyone packaging it, regardless of what for, would benefit from improved organizational structure in Avidemux.

I agree with you on that. For now though, I don't think I have anything substantial to add to that PR, but I've subscribed to it.

I do want to try to upstream some of the patches I've introduced recently here, though.