View Issue Details

IDProjectCategoryView StatusLast Update
0000261Cinelerra-GG[All Projects] Featurepublic2019-07-23 18:55
ReporterMatN Assigned ToPhyllisSmith  
Status closedResolutionno change required 
PlatformX86_64OSMintOS Version19.1
Product Version2019-06 
Target VersionFixed in Version 
Summary0000261: Add Flatpak and/or AppImage as supported platforms if it doesn´t get too large.

Flatpak and AppImage are distribution agnostic application formats. I´m not sure which one has the largest user base, or what the exact differences/limitations are.

It seems Flatpaks are very large, the Kdelive and OpenShot Flatpaks in Mint 19.1 are in the 800-900M range!

The AppImage of etcher-electron-1.4.4-x86_64 is 90M, of Musescore 150M.

Cinelerra (55 MByte download) is quite small (compared to Premiere and Davinci Resolve). Very likely such a new form would make it bigger, I have no idea how much. Also, an extra platform to build and test, so is it worth it?

TagsNo tags attached.




2019-07-23 18:55

manager   ~0001974

For future reference, this BT will come in handy! and as MatN states "if there is demand to have Cinelerra for another distro, it is probably easier to create builds for that", I hardily agree. We attempted to add Gentoo a long time ago as there has been a couple of requests for that, but may try again in the future if there is a step by step "how to" like was provided for Arch when we initially added that.



2019-07-21 13:26

manager   ~0001963

Yes, my thanks to MatN also as that was a major time investment and put this idea into perspective. We can probably close this in a couple of days after others are given a chance to comment if they want.



2019-07-21 11:50

administrator   ~0001961

Mat, thank you so much for your efforts. Too bad that the tests were not positive. I think it would be interesting to offer such formats in the long run, but currently due to a lack of more developers we should concentrate our energies on the existing process.

Cinelerra on Windows or Mac would be interesting, but there are already so many NLE's competing with each other that we would only be one software of many. I think Cinelerra's home is Linux.



2019-07-21 10:26

reporter   ~0001960

I did some more testing with the AppImage I built:
MX Linux 18.3: Error, missing .
Manjaro 18.0.4: Begins to run, but errors regarding plugins and unable to create directories (but they exists).

So AppImage does not look to be an easy way to extend Cinelerra to Linux distro's, plus lots of additional testing each release. If there is demand to have Cinelerra for another distro, it is probably easier to create builds for that.

Like others have said already, there are many other NLE video editors on Windows, and adding Cinelerra would likely create a lot of support requests. In addition, Windows' WSL does not seem to have sound support, and it basically requires a modified Ubuntu on top of WSL. Hardly just a simple AppImage. And it would require a new build environment as well.

For MacOS, there are already a number of open source NLEs, and the Linux AppImage (or any Linux executable) doesn't run on that anyway. It too would require a new build environment.

So IMHO it looks that neither AppImage nor FlatPak is currently a worthwhile addition to the supported 9 (not 8, as as wrongly wrote earlier) Cinelerra incarnations.

The limited develop/test resources are, like others have mentions, best used as now, steadily improving Cinelerra on Linux.



2019-07-17 22:48

administrator   ~0001932

In my humble opinion, there are enough other alternatives for Windows, Cinelerra can't quite keep up with that at the moment. I think we should concentrate on Linux and become the best free video editing software there.



2019-07-17 22:31

manager   ~0001930

Just some feedback on this comment -- "I wonder (like Andrea) if the community would be able to manage the requests from MS users having issues with the software, as it seems that the community runs Linux as main OS." -- there are a lot of windows users out there so there might be some willing and able, but neither GG or I would be of any help.



2019-07-13 12:18

administrator   ~0001908

We are a community of volunteers. Any contribution to this community is highly welcome. If MatN or any other developer or user could take on this task, it would certainly be a relief for the developers.



2019-07-13 08:09

reporter   ~0001906

Me and you also found the way to the video editing program. So who is the target group?

The maintenance ties up some resources (manpower), which are missing in the actual much more important further development. Is the effort justifiable?

Why not let User MatN take over this task? With a link to his archive (or the problem would be solved.



2019-07-12 13:27

reporter   ~0001902

Flatpak would be a cool option, especially because they have their own 'store' where CinGG would get even more visibility.

I didn't know flatpaks ran on Windows, it would be cool, however I wonder (like Andrea) if the community would be able to manage the requests from MS users having issues with the software, as it seems that the community runs Linux as main OS.

If we are unable to provide support for Windows users I don't know if the hassle is worth (unless you want to give a 'no support on Windows' version).

IMHO CinGG should focus on Linux (distributed as flatpak as well, why not).

ps: in case you wonder yes that's me, I had issues with my account and had to create another one :)



2019-07-10 07:04

updater   ~0001892

My thoughts on CinGG on Win:

  • Is that a desirable goal?
    Complex question. I don't feel the need! Running on win means increasing a lot, but really a lot, the number of users and then get publicity (weak point of Cin: anyone who talks about video editing on Linux never mentions Cinelerrra, let alone CinGG). So are we interested in publicizing our program or not? Personally, I try to make CinGG known to as many people as possible, but in reality I'm happy with a slow enlargement or even to stand still in this state: I'm convinced that GG/Phyllis would continue their work even if they were alone and I really like that.

  • How much proffesional users would use it.
    CinGG cannot meet the demands of the pros. Guarantees; customer support; market STD support; exchange of EDLs with other programs; etc. But IMO, as a feature is not far from the Pro programs. Or at least it is closer than any other open program on Linux.

  • How far is the new Windows' WSL2 short of things that Cinelerra needs?
    I don't have the knowledge to answer that. I read that on WSL you can also install Xorg, if you want I look for the source (that I forgot!). Maybe the large size of Flatpak and Snap is really useful to have no problems with dependencies?

[For test I installed the Natron's Flatpak (on Linux, not Win): I can not add an external hotfix and I could not add external plugins (probably by my fault). The performance seems to me lower, but I have not done exhaustive tests.]



2019-07-09 21:06

updater   ~0001890

I really have no code skills to pretend to understand anything about it... But isn't OSX built on a BSD basis?

There is already a version of Cinelerra-GG prepared for FreeBSD, maybe it would be possible for a coding guru to adapt it to OSX.



2019-07-09 19:38

reporter   ~0001889

I had a little time, so I tested the appimage I made from the Mint 19.1 deb on a few other distributions. Results:
Fedorea 30: Error, missing .
Mint 18.3, recovery mode: Error, missing .
Mint 17.3: Error, missing

So it was too easy indeed :-). These probably can be fixed easily, but is it worth the effort?

The question to ask is: which problem are you trying to solve? For Linuxes, the current 8 platforms give quite good coverage I think. The only ¨problem¨ to solve (that I see at the moment) would be to get it running under Windows 10 (I don´t think MacOsX can run Linux programs, AppImage or not).

  • Is that a desirable goal?
  • How much proffesional users would use it (that determines if any effort is worthwhile)
  • How far is the new Windows' WSL2 short of things that Cinelerra needs? (Wikipedia show Synaptic running on it; is an X server needed? I´m not sure a free one is available).
  • Is sound supported? I´ve seen some mentioning that it is not, which would be a no-go. But I did not delve into WSL2, don´t have Windows or easy access to a test system of that.
  • And, should WSL2 have pretty much everything a Cinelerra appImages needs, would not the tar work too?


2019-07-09 03:31

manager   ~0001885

After much discussion with GG, who reviewed the files that MatN provided, and reading some online docs, here is some feedback/conclusions.

As a free-bie this is worth having so if anyone wants to provide a specific appimage Cin when the monthly builds are created, we can surely upload it to the server. But the advantages as outlined by wikipedia are already available with Cinelerra by using the tar build - namely 1. do not have to be superuser, 2. no extraction tools needed (other than a simple tar), 3. no modification to the operating system or user environment. I.e "Regular users on the common Linux distributions can download it, make it executable, and run it." - same result as using the tar, except you don't have to make it executable as it already is. There is a little bit of concern from a security point of view when using which could do just about anything.



2019-07-08 20:57

manager   ~0001882

Whoa! you make it sound so simple. Maybe I can get GG to test if he can find a partition that he can sacrifice. And maybe someone can test on a Windows 10?



2019-07-08 20:13

reporter   ~0001881

Astonishing. I looked at the websites, and gave it a quick try, just to see what problems popped up. In short: I have what appears to be a working appimage.

Basically, you create a recipe (.yml) file and then run pkg2appimage (this last one is a shell script).
I downloaded the pkg2appimage shell script and put it into a file. URL is , select RAW mode, copy the screen content
and paste it into a file named pkg2appimage . I have attached the file.

The create a very simple ¨recipe¨ file, also attached. I put both files in the same directory (¨~/Sources/Recipes¨), just for a quick try.

Then I ran in that directory: bash -ex ./pkg2appimage ./cin.yml . I actually used ¨bash -ex ./pkg2appimage ./cin.yml 1>run1.txt 2>run2.txt¨ so I could log normal and error output separately. In the end , I had a subdirectory ¨out¨ with the file ¨cin-5.1.mint19.glibc2.27-x86_64.AppImage¨ in it. And it seems to run fine. Without the download,, the creation is in seconds on my machine.

It is only 79 MByte (24 M bigger than the deb file), so if someone want to have it let me know your mail address and I can wetransfer the file. But is it just as easy to create it yourself.
I have at the moment no no-Mint platforms to test on, it would be really nice to have it tried on a Windows 10 machine. To be honest, this went so easy I expect many problems.

Normally the recipe file downloads a .deb file, but after the first time I already had it locally so I changed the recipe file to use a local file. See the commented out lines in the .yml file.

It seems possible to do desktop integration as well, I have not bothered with it.

pkg2appimage (17,353 bytes)
#!/usr/bin/env bash

# env

HERE="$(dirname "$(readlink -f "${0}")")"

# Use privately bundled apt-get and dpkg-deb if available; can be got on trusty using
# apt download apt libapt-pkg4.12 libbz2-1.0 liblzma5 multiarch-support zlib1g dpkg
if [ -e "${HERE}/" ] ; then
  export UNION_PRELOAD="${HERE}"
  export LD_PRELOAD="${HERE}/"
  export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
  export LD_LIBRARY_PATH="${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib32/:"${HERE}"/usr/lib64/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${HERE}"/lib32/:"${HERE}"/lib64/:"${LD_LIBRARY_PATH}"
  export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}"

# Specify a certain commit if you do not want to use master
# by using:
# export PKG2AICOMMIT=<git sha>
if [ -z "$PKG2AICOMMIT" ] ; then

usage() {
  if [ -z "$APPIMAGE" ]  ; then
  echo "usage:"
  echo "  $MYSELF [--no-di] META-NAME|YAMLFILE"
  echo ""
  echo "options:"
  echo "  --di    enable legacy desktop integration (unsupported)"
  exit 1

if [ $# -eq 0 ] || [ "x${!#}" = "x--di" ] ; then
if [ $# -eq 2 ] && [ "x$1" != "x--di" ] ; then

if [ "x$1" = "x--di" ] ; then

# Halt on errors
set -e
set -x

# Check dependencies
which wget >/dev/null 2>&1 || ( echo wget missing && exit 1 )
which grep >/dev/null 2>&1 || ( echo grep missing && exit 1 )
which sed >/dev/null 2>&1 || ( echo sed missing && exit 1 )
which cut >/dev/null 2>&1 || ( echo cut missing && exit 1 )

# If the yaml file doesn't exist locally, get it from GitHub
if [ ! -f "${!#}" ] ; then
  rm -f "$YAMLFILE"
  wget -q "${PKG2AICOMMIT}/recipes/${!#}.yml" -O "$YAMLFILE"
  YAMLFILE=$(readlink -f "${!#}")

# Lightweight bash-only dpkg-scanpackages replacement
scanpackages() {
  for deb in *.deb ; do
    dpkg -I $deb | sed 's/^ *//g' | grep -i -E '(package|version|installed-size|architecture|depends|priority):'
    echo "Filename: $(readlink -f $deb)"
    echo "MD5sum: $(md5sum -b $deb | cut -d' ' -f1)"
    echo "SHA1: $(sha1sum -b $deb | cut -d' ' -f1)"
    echo "SHA256: $(sha256sum -b $deb | cut -d' ' -f1)"

# Function to parse yaml
# based on
parse_yaml() {
    local prefix=$2
    local s
    local w
    local fs
    fs="$(echo @|tr @ '\034')"
    sed -ne "s|^\($s\)\($w\)$s:$s\"\(.*\)\"$s\$|\1$fs\2$fs\3|p" \
        -e "s|^\($s\)\($w\)$s[:-]$s\(.*\)$s\$|\1$fs\2$fs\3|p" "$1" |
    awk -F"$fs" '{
    indent = length($1)/2;
    vname[indent] = $2;
    for (i in vname) {if (i > indent) {delete vname[i]}}
        if (length($3) > 0) {
            vn=""; for (i=0; i<indent; i++) {vn=(vn)(vname[i])("_")}
            printf("%s%s%s=(\"%s\")\n", "'"$prefix"'",vn, $2, $3);
    }' | sed 's/_=/+=/g'

# Read yaml file
parse_yaml $YAMLFILE "_"
eval $(parse_yaml $YAMLFILE "_")

if [ ! -z $_enable_di ]; then

# Execute multiple script lines together as one
# shell_execute filename key_of_group_of_commands
shell_execute() {
  if [ -f /tmp/recipe_script ] ; then
    rm /tmp/recipe_script
  parse_yaml $YAMLFILE "_" | grep "^$2+=" > /tmp/recipe_script
  sed -i -e 's|^'$2'+=("||g' /tmp/recipe_script
  sed -i -e 's|")$||g' /tmp/recipe_script
  bash -ex /tmp/recipe_script
  rm /tmp/recipe_script

if [ ! -z $_lowerapp ] ; then

mkdir -p ./$APP/$APP.AppDir/usr/lib
cd ./$APP/

if [ -d "./$APP.AppDir/" ] ; then
  rm -rf ./$APP.AppDir/

# Source the bundled if it exists
# in "${HERE}/usr/share/pkg2appimage/"
# or source a user-provided if the environment
# variable FUNCTIONS_SH was set and the file exists
if [ -e "${HERE}/usr/share/pkg2appimage/" ] ; then
  . "${HERE}/usr/share/pkg2appimage/"
elif [ -z "$FUNCTIONS_SH" ] ; then
  if [ ! -e ] ; then
    wget -q${PKG2AICOMMIT}/ -O ./
  . ./
  if [ -e "$FUNCTIONS_SH" ] ; then

# If there is an ARCH environment variable, then use that
# architecture to for apt-get. Not that for the AppImage to be
# operable, we also need to embed a matching AppImage runtime
# and ingredients of that architecture. Debian packages
# should be available for most architectures, e.g., oldstable
# has "armhf"
if [ ! -z $ARCH] ; then
  OPTIONS="$OPTIONS -o APT::Architecture=$ARCH"

if [ ! -z "${_ingredients_ghreleases[0]}" ] ; then
  for GHREPO in "${_ingredients_ghreleases[@]}" ; do
    wget -q "${GHREPO}/releases/" -O /tmp/gh-release.html
    DEB=$(cat /tmp/gh-release.html | grep ".deb" | grep x86_64 | head -n 1 | cut -d '"' -f 2)
    if [ -z "$DEB" ] ; then
      DEB=$(cat /tmp/gh-release.html | grep ".deb" | grep amd64 | head -n 1 | cut -d '"' -f 2)
    if [ -z "$DEB" ] ; then
      DEB=$(cat /tmp/gh-release.html | grep ".deb" | grep x64 | head -n 1 | cut -d '"' -f 2)
    if [ -z "$DEB" ] ; then
      DEB=$(cat /tmp/gh-release.html | grep ".deb" | grep linux64 | head -n 1 | cut -d '"' -f 2)
    rm /tmp/gh-release.html
    wget -c "${DEB}"

if [ ! -z "${_ingredients_dist}" ] ; then
  rm status 2>/dev/null || true

  # Some packages depend on packages which we do not want to bundle,
  # in addition to the global excludes defined in excludedeblist.
  # Use
  # ingredients:
  #   exclude:
  #     - packagename
  if [ ! -z "${_ingredients_exclude[0]}" ] ; then
    for PACKAGE in "${_ingredients_exclude[@]}" ; do
      printf "Package: $PACKAGE\nStatus: install ok installed\nArchitecture: all\nVersion: 9:999.999.999\n\n" >> status

  # Some packages depend on an exact version of a dependency to be installed.
  # Use
  # ingredients:
  #   pretend:
  #     - packagename version_to_be_pretended
  if [ ! -z "${_ingredients_pretend[0]}" ] ; then
    for PRETEND in "${_ingredients_pretend[@]}" ; do
      P_PKG=$(echo "$PRETEND" | cut -d " " -f 1)
      P_VER=$(echo "$PRETEND" | cut -d " " -f 2)
      cat status | tr '\n' '@' | sed -e 's|@@|\n\n|g' | sed -e 's|Package: '"$P_PKG"'@Status: install ok [email protected]: [email protected]: 9:999.999.999|Package: '"$P_PKG"'@Status: install ok [email protected]: [email protected]: '"$P_VER"'|g' | sed -e 's|@|\n|g' > status.temp
      mv status.temp status

  if [ -e sources.list ] ; then
    rm sources.list
  for SOURCE in "${_ingredients_sources[@]}" ; do
    echo "${SOURCE}" >> sources.list
  for PPA in "${_ingredients_ppas[@]}" ; do
    echo "deb${PPA}/ubuntu ${_ingredients_dist} main" >> sources.list
  for DEBFILE in "${_ingredients_debs[@]}" ; do
    cp ${DEBFILE} .
  # Use libcurl-slim to reduce AppImage size, thanks darealshinji
  # Not really compiled on xenial but CentOS 6,
  echo "deb xenial main" >> sources.list
  # Use gnutls-patched to have libgnutls look in various distributions' places for certificates,
  # echo "deb ${_ingredients_dist} main" >> sources.list
  ### echo "deb trusty main" >> sources.list #

if [ ! -z "${_ingredients_script[0]}" ] ; then
  # Execute extra steps defined in recipe
  shell_execute $YAMLFILE _ingredients_script

if [ ! -z "${_ingredients_dist}" ] ; then
  # Some projects provide raw .deb files without a repository
  # hence we create our own local repository as part of
  # the AppImage creation process in order to "install"
  # the package using apt-get as normal
  if [ ! -z "${_ingredients_debs[0]}" ] ; then
    for DEB in "${_ingredients_debs[@]}" ; do
      if [ ! -f $(basename "$DEB") ] ; then
        wget -c $DEB
  scanpackages | gzip -9c > Packages.gz
  echo "deb file:$(readlink -e $PWD) ./" >> sources.list

  if [ ! -z "${_ingredients_package}" ] ; then
  if [ ! -z "${_ingredients_packages}" ] ; then

  # If packages are specifically listed, only install these, not a package with the name of the app
  if [ ! -z "${_ingredients_packages[0]}" ] ; then

  apt-get -o Acquire::AllowInsecureRepositories=true -o Acquire::Languages="none" -o Acquire::AllowDowngradeToInsecureRepositories=true $OPTIONS update || true
  URLS=$(apt-get --allow-unauthenticated -o Apt::Get::AllowUnauthenticated=true $OPTIONS -y install --print-uris $INSTALL | cut -d "'" -f 2 | grep -e "^http") || true
  if which aria2c &>/dev/null; then

  $dltool -c -i- <<<"$URLS"

if [ ! -z "${_ingredients_post_script[0]}" ] ; then
  # Execute extra steps defined in recipe
  shell_execute $YAMLFILE _ingredients_post_script

mkdir -p ./$APP.AppDir/
cd ./$APP.AppDir/

mkdir -p usr/bin usr/lib
find ../*.deb -exec dpkg-deb -X {} . \; || true


# Try to copy icons to standard locations where appimaged can pick them up
mkdir -p usr/share/icons/hicolor/{22x22,24x24,32x32,48x48,64x64,128x128,256x256,512x512}/apps/
find . -path *icons* -path *22* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/22x22/apps/ \; || true
find . -path *icons* -path *24* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/24x24/apps/ \; || true
find . -path *icons* -path *32* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/32x32/apps/ \; || true
find . -path *icons* -path *48* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/48x48/apps/ \; || true
find . -path *icons* -path *64* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/64x64/apps/ \; || true
find . -path *icons* -path *128* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/128x128/apps/ \; || true
find . -path *icons* -path *256* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/256x256/apps/ \; || true
find . -path *icons* -path *512* -name "*$LOWERAPP*" -exec cp {} usr/share/icons/hicolor/512x512/apps/ \; || true


if [ -z "${_union}" ] ; then
cat > AppRun <<\EOF
HERE="$(dirname "$(readlink -f "${0}")")"
export LD_PRELOAD="${HERE}/"
export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
export LD_LIBRARY_PATH="${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib32/:"${HERE}"/usr/lib64/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${HERE}"/lib32/:"${HERE}"/lib64/:"${LD_LIBRARY_PATH}"
export PYTHONPATH="${HERE}"/usr/share/pyshared/:"${PYTHONPATH}"
export PYTHONHOME="${HERE}"/usr/
export XDG_DATA_DIRS="${HERE}"/usr/share/:"${XDG_DATA_DIRS}"
export PERLLIB="${HERE}"/usr/share/perl5/:"${HERE}"/usr/lib/perl5/:"${PERLLIB}"
export GSETTINGS_SCHEMA_DIR="${HERE}"/usr/share/glib-2.0/schemas/:"${GSETTINGS_SCHEMA_DIR}"
export QT_PLUGIN_PATH="${HERE}"/usr/lib/qt4/plugins/:"${HERE}"/usr/lib/i386-linux-gnu/qt4/plugins/:"${HERE}"/usr/lib/x86_64-linux-gnu/qt4/plugins/:"${HERE}"/usr/lib32/qt4/plugins/:"${HERE}"/usr/lib64/qt4/plugins/:"${HERE}"/usr/lib/qt5/plugins/:"${HERE}"/usr/lib/i386-linux-gnu/qt5/plugins/:"${HERE}"/usr/lib/x86_64-linux-gnu/qt5/plugins/:"${HERE}"/usr/lib32/qt5/plugins/:"${HERE}"/usr/lib64/qt5/plugins/:"${QT_PLUGIN_PATH}"
EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')
exec ${EXEC} "[email protected]"
chmod a+x AppRun


# Prevent Qt from loading plugins from the system
unset QTPATH
QTPATH=$(find usr/lib -type d -name qt4 -or -name qt5 | sed -e 's|usr/|../|g')
if [ ! -z $QTPATH ] ; then
cat > usr/bin/qt.conf <<EOF
Prefix = $QTPATH

# At runtime, Mono looks in three places for assemblies necessary
# to run a program. It first searches the location of the executing assembly.
# For this to work without setting $MONO_PATH, we need to move the
# main *.exe to usr/lib/mono/exe, because we move all "assemblies" (sic)
# there in this script

if [ -e usr/lib/mono ] ; then
  # Force all so files referenced in config files into LD_LIBRARY_PATH
  find . -name "*.dll.config" -exec cat {} > temp \;
  # Remove all absolute paths
  sed -i -E 's|target=\"\/(.*\/)([a-z0-9].*?)>|target=\"\2>|g' temp
  SONAMES=$(cat temp | cut -d '"' -f 4  | grep ".so" || true)
  if [ "" != "$SONAMES" ] ; then
    for SONAME in $SONAMES; do
      find . -name "$SONAME" -exec mv {} usr/lib \;
  rm temp
  mkdir -p "$PATH_OF_THE_EXE"
  # Force all dll files into PATH_OF_THE_EXE (or MONO_PATH which we would have to set)
  find . -name "*.dll" -and -not -name "mscorlib.dll" -exec mv {} "$PATH_OF_THE_EXE" \;
  # Edit all config files in place to remove absolute paths
  find . -name "*.dll.config" -exec sed -i -E 's|target=\"\/(.*\/)([a-z0-9].*?)>|target=\"\2>|g' {} \;
  # Force all config files into the PATH_OF_THE_EXE (or MONO_PATH which we would have to set)
  find . -name "*.dll.config" -exec mv {} "$PATH_OF_THE_EXE" \;
  # Remove gac, we are not using it since it is convoluted
  rm -rf usr/lib/mono/gac/

if [ -d "./usr/lib/x86_64-linux-gnu/gstreamer-1.0/" ] ; then
  mv ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/* ./usr/lib/x86_64-linux-gnu/
  rm -r ./usr/lib/x86_64-linux-gnu/gstreamer-1.0

if [ -d "./usr/lib/x86_64-linux-gnu/pulseaudio/" ] ; then
  mv ./usr/lib/x86_64-linux-gnu/pulseaudio/* ./usr/lib/x86_64-linux-gnu/
  rm -r ./usr/lib/x86_64-linux-gnu/pulseaudio

# Execute extra steps defined in recipe
if [ ! -z "${_script}" ] ; then
  shell_execute $YAMLFILE _script

DESKTOP=$(find . -name '*.desktop' | sort | head -n 1)

# desktop-file-validate complains about missing trailing semicolons for some
# keys although the format definition says that they are optional
fix_desktop "$DESKTOP"

# Some non-distribution provided applications have an absolute
# path in the Exec= line which we remove for relocateability
if [ -z "$DESKTOP" ] ; then
  echo "desktop file not found, aborting"
  exit 1
  desktop-file-validate "$DESKTOP" || exit 1
  ORIG=$(grep -o "^Exec=.*$" "${DESKTOP}" | head -n 1| cut -d " " -f 1)
  REPL=$(basename $(grep -o "^Exec=.*$" "${DESKTOP}" | head -n 1 | cut -d " " -f 1 | sed -e 's|Exec=||g'))
  sed -i -e 's|'"${ORIG}"'|Exec='"${REPL}"'|g' "${DESKTOP}"

# Compile GLib schemas if the subdirectory is present in the AppImage
# AppRun has to export GSETTINGS_SCHEMA_DIR for this to work
if [ -d usr/share/glib-2.0/schemas/ ] ; then
  ( cd usr/share/glib-2.0/schemas/ ; glib-compile-schemas . )

if [ -f ../VERSION ] ; then
  get_version || true

# patch_usr
# Patching only the executable files seems not to be enough for some apps
if [ ! -z "${_binpatch}" ] ; then
  find usr/ -type f -exec sed -i -e 's|/usr|././|g' {} \;
  find usr/ -type f -exec sed -i -e '[email protected]/.//bin/[email protected]/usr/bin/[email protected]' {} \;

# Don't suffer from NIH; use LD_PRELOAD to override calls to /usr paths
if [ ! -z "${_union}" ] ; then
  mkdir -p usr/src/
  wget -q "" -O - | \
  sed -e 's|SNAPPY|UNION|g' | sed -e 's|SNAPP|UNION|g' | sed  -e 's|SNAP|UNION|g' | \
  sed -e 's|snappy|union|g' > usr/src/libunionpreload.c
  gcc -shared -fPIC usr/src/libunionpreload.c -o -ldl -DUNION_LIBNAME=\"\"


if [ "$ENABLE_DI" = "yes" ] ; then
  get_desktopintegration $LOWERAPP

# Fix desktop files that have file endings for icons
sed -i -e 's|\.png||g' *.desktop || true
sed -i -e 's|\.svg||g' *.desktop || true
sed -i -e 's|\.svgz||g' *.desktop || true
sed -i -e 's|\.xpm||g' *.desktop || true

# Setting PYTHONHOME instead
# Fix Python imports,
# SITECUSTOMIZEFILES=$(find . -name "")
# rm $SITECUSTOMIZEFILE # Remove symlinks, replace by files
# import sys,os
# if sys.version_info[0] < 3:
#     prefix = os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(sys.path[0]))))
#     sys.path = [ prefix+s for s in sys.path if not s.startswith(prefix) ]
# done

# Execute extra steps defined in recipe
if [ ! -z "${_post_script[0]}" ] ; then
  shell_execute $YAMLFILE _post_script

# Go out of AppImage
cd ..

ls -lh ../out/*.AppImage

pkg2appimage (17,353 bytes)
cinelerra.yml (540 bytes)


2019-07-07 22:06

manager   ~0001878

Interesting. Maybe someone will come along and work on a CinGG flatpak/appimage build to test -- I wonder if it would run slower? Snap seems to be less talked about. WSL on Windows 10 sounds like it makes it possible to run Cinelerra on a Windows system, so there is no need to create a Windows specific version!



2019-07-07 19:23

reporter   ~0001877

There´s a nice overview of the differences between AppImage, Snap and Flatpak on .
It seems AppImage is indeed the smallest, it looks like FlatPak includes a lot of desktop stuff. There´s also a website ( telling you how to create an AppImage from an existing application. If I didn´t have visitors all week, I´d be tempted to try it.
Probably, Cinelerra, being GTK based, has little GUI dependencies.

Andrea: apparently AppImage can run on Windows too:



2019-07-07 12:06

updater   ~0001875

Issue History

Date Modified Username Field Change
2019-07-07 10:58 MatN New Issue
2019-07-07 12:06 Andrea_Paz Note Added: 0001875
2019-07-07 19:23 MatN Note Added: 0001877
2019-07-07 22:06 PhyllisSmith Note Added: 0001878
2019-07-08 20:13 MatN File Added: pkg2appimage
2019-07-08 20:13 MatN File Added: cinelerra.yml
2019-07-08 20:13 MatN Note Added: 0001881
2019-07-08 20:57 PhyllisSmith Note Added: 0001882
2019-07-09 03:31 PhyllisSmith Note Added: 0001885
2019-07-09 19:38 MatN Note Added: 0001889
2019-07-09 21:06 Pierre Note Added: 0001890
2019-07-10 07:04 Andrea_Paz Note Added: 0001892
2019-07-12 13:27 WPfilmmaker4 Note Added: 0001902
2019-07-13 08:09 Olaf Note Added: 0001906
2019-07-13 12:18 Sam Note Added: 0001908
2019-07-17 22:31 PhyllisSmith Note Added: 0001930
2019-07-17 22:48 Sam Note Added: 0001932
2019-07-21 10:26 MatN Note Added: 0001960
2019-07-21 11:50 Sam Note Added: 0001961
2019-07-21 13:26 PhyllisSmith Note Added: 0001963
2019-07-23 18:55 PhyllisSmith Assigned To => PhyllisSmith
2019-07-23 18:55 PhyllisSmith Status new => closed
2019-07-23 18:55 PhyllisSmith Resolution open => no change required
2019-07-23 18:55 PhyllisSmith Note Added: 0001974