From 8bb38fb6084e64e710e3e3854c435f3af48e70c7 Mon Sep 17 00:00:00 2001 From: DrSheppard <60893791+Drsheppard01@users.noreply.github.com> Date: Thu, 20 Mar 2025 23:49:36 +0300 Subject: [PATCH 1/2] qol --- CODE_LICENSE.txt | 2 +- LICENSE.txt | 2 +- source/conf.py | 6 +++--- source/introduction/concepts.rst | 6 +++--- source/introduction/software-overview.rst | 4 ++-- .../converting-binary-packages/pkg2appimage.rst | 12 ++++++------ source/packaging-guide/distribution.rst | 2 +- source/packaging-guide/hosted-services/travis-ci.rst | 2 +- source/packaging-guide/optional/updates.rst | 4 ++-- source/packaging-guide/overview.rst | 4 ++-- source/reference/best-practices.rst | 6 +++--- source/reference/desktop-integration.rst | 2 +- source/user-guide/mac.rst | 2 +- source/user-guide/portable-mode.rst | 2 +- 14 files changed, 28 insertions(+), 28 deletions(-) diff --git a/CODE_LICENSE.txt b/CODE_LICENSE.txt index 538497c..d0ea0e8 100644 --- a/CODE_LICENSE.txt +++ b/CODE_LICENSE.txt @@ -1,4 +1,4 @@ -Copyright 2018-2020 AppImage team and contributors +Copyright 2018-2025 AppImage team and contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/LICENSE.txt b/LICENSE.txt index 00685ef..193c903 100644 --- a/LICENSE.txt +++ b/LICENSE.txt @@ -1,4 +1,4 @@ -Copyright 2018-2020 AppImage team and contributors. +Copyright 2018-2025 AppImage team and contributors. The contents of these docs, e.g., the `.rst` files, are licensed under the terms of the CC-By 4.0 Intl. See CONTENT_LICENSE.txt for more information. diff --git a/source/conf.py b/source/conf.py index e832c46..6c754ca 100644 --- a/source/conf.py +++ b/source/conf.py @@ -4,7 +4,7 @@ # # This file does only contain a selection of the most common options. For a # full list see the documentation: -# http://www.sphinx-doc.org/en/master/config +# https://www.sphinx-doc.org/en/master/usage/configuration.html # -- Path setup -------------------------------------------------------------- @@ -22,8 +22,8 @@ # -- Project information ----------------------------------------------------- project = 'AppImage' -copyright = '2018-2022, The AppImage project' -author = 'The AppImage project and its contributors' +copyright = '2018-2025, The AppImage project' +author = 'The AppImage project and contributors' # The short X.Y version version = '' diff --git a/source/introduction/concepts.rst b/source/introduction/concepts.rst index 4781d86..25ab9af 100644 --- a/source/introduction/concepts.rst +++ b/source/introduction/concepts.rst @@ -35,7 +35,7 @@ The author of an AppImage needs to decide for which target systems (Linux distri To be able to run on any Linux distribution, an AppImage should bundle all the resources it needs at runtime that cannot be reasonably expected to be "there" in the default installation of all still-supported target systems (Linux distributions). The most common resources are the actual binaries, shared library dependencies, icons and other graphics and of course one or more desktop files for desktop integration. -This doesn't mean an AppImage must not use resources provided by the system, like for example basic libraries that can be assumed to be part of every target system (e.g., the C standard library or graphics libraries), user interface themes or the like. See the `excludelist `__ for a list of the libraries we consider to currently be part of each still-supported target system (distribution). +This doesn't mean an AppImage must not use resources provided by the system, like for example basic libraries that can be assumed to be part of every target system (e.g., the C standard library or graphics libraries), user interface themes or the like. See the `excludelist `__ for a list of the libraries we consider to currently be part of each still-supported target system (distribution). .. _build-on-old-systems: @@ -49,9 +49,9 @@ Applications should be built on the oldest possible system, allowing them to run It may seem contradictory to :ref:`the previous section ` to rely on distribution provided resources. This is a trade-off between trying to reduce redundancies while at the same time being as self-contained as possible. -In some cases, including the libraries might even break the AppImage on the target system. Those libraries involve, among others, hardware dependent libraries such as graphics card drivers provided libraries (e.g., :code:`libGL.so.1`, (`source `__)), or libraries that are build and linked differently on different distributions (e.g., :code:`libharfbuzz.so.0` and :code:`libfreetype.so.6` (`source `__). +In some cases, including the libraries might even break the AppImage on the target system. Those libraries involve, among others, hardware dependent libraries such as graphics card drivers provided libraries (e.g., :code:`libGL.so.1`, (`source `__)), or libraries that are build and linked differently on different distributions (e.g., :code:`libharfbuzz.so.0` and :code:`libfreetype.so.6` (`source `__). -The list of libraries that can resp. have to be excluded, the so-called `excludelist `__, is carefully curated by the AppImage team, and is regularly updated. +The list of libraries that can resp. have to be excluded, the so-called `excludelist `__, is carefully curated by the AppImage team, and is regularly updated. .. _zlib: https://zlib.net/ .. _GLib: https://developer.gnome.org/glib/ diff --git a/source/introduction/software-overview.rst b/source/introduction/software-overview.rst index 8d2c3f6..ff5539f 100644 --- a/source/introduction/software-overview.rst +++ b/source/introduction/software-overview.rst @@ -98,10 +98,10 @@ AppImageUpdate_ lets you update AppImages in a decentralized way using informati The project consists of two tools: :code:`appimageupdatetool`, a full-featured CLI tool for updating AppImages and dealing with `update information`_, and :code:`AppImageUpdate`, a user interface for updating AppImages written in Qt. -.. _AppImageUpdate: https://github.com/AppImage/AppImageUpdate +.. _AppImageUpdate: https://github.com/AppImageCommunity/AppImageUpdate .. _update information: https://github.com/AppImage/AppImageSpec/blob/master/draft.md\#update-information -**Download:** You can get it as an AppImage from https://github.com/AppImage/AppImageUpdate/releases/continuous. +**Download:** You can get it as an AppImage from https://github.com/AppImageCommunity/AppImageUpdate/releases/continuous. .. _appimaged: diff --git a/source/packaging-guide/converting-binary-packages/pkg2appimage.rst b/source/packaging-guide/converting-binary-packages/pkg2appimage.rst index 90675dd..d766cad 100644 --- a/source/packaging-guide/converting-binary-packages/pkg2appimage.rst +++ b/source/packaging-guide/converting-binary-packages/pkg2appimage.rst @@ -3,7 +3,7 @@ pkg2appimage ============ -If you already have existing binaries (either in archive or :code:`.deb` format or a ppa) then the recommended way to convert these to an AppImage is to write a `.yml description file `__ and run it with `pkg2appimage`_. +If you already have existing binaries (either in archive or :code:`.deb` format or a ppa) then the recommended way to convert these to an AppImage is to write a `.yml description file `__ and run it with `pkg2appimage`_. .. contents:: Contents @@ -22,9 +22,9 @@ To build an AppImage from a :code:`.yml` description file, simply run: bash -ex ./pkg2appimage recipes/XXX.yml -:code:`.yml` description files tell pkg2appimage where to get the ingredients from, and how to convert them to an AppImage (besides the general steps already included in pkg2appimage). Study some `examples `__ to see how it works. +:code:`.yml` description files tell pkg2appimage where to get the ingredients from, and how to convert them to an AppImage (besides the general steps already included in pkg2appimage). Study some `examples `__ to see how it works. -.. _pkg2appimage: https://github.com/AppImage/pkg2appimage/blob/master/pkg2appimage +.. _pkg2appimage: https://github.com/AppImageCommunity/AppImageUpdate/blob/master/pkg2appimage .. warning:: pkg2appimage suffers from a few notable issues: @@ -33,7 +33,7 @@ To build an AppImage from a :code:`.yml` description file, simply run: - pkg2appimage uses distribution packages downloaded using the package managers, however, the packages are not authenticated, as most security functionality has been deactivated. This is a major security issue. pkg2appimage is therefore recommended for personal use only. Upstream authors should consider :ref:`packaging from source `. .. seealso:: - See `this GitHub issue `__ for more information on the security issue. + See `this GitHub issue `__ for more information on the security issue. ``.yml`` files @@ -141,7 +141,7 @@ The following example ingredients section describes how to get the latest versio ingredients: dist: xenial sources: - - deb http://archive.ubuntu.com/ubuntu/ xenial main universe + - deb https://archive.ubuntu.com/ubuntu/ xenial main universe - deb http://download.opensuse.org/repositories/isv:/KDAB/xUbuntu_16.04/ / @@ -414,4 +414,4 @@ The following recipe will convert a Python 3 PyQt application using :code:`virtu Source: - https://github.com/AppImage/pkg2appimage/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/recipes/Mu.yml + https://github.com/AppImageCommunity/AppImageUpdate/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/recipes/Mu.yml diff --git a/source/packaging-guide/distribution.rst b/source/packaging-guide/distribution.rst index a789d55..c8d96df 100644 --- a/source/packaging-guide/distribution.rst +++ b/source/packaging-guide/distribution.rst @@ -135,7 +135,7 @@ As a format, AppImage is designed in a way that does not impose restrictions on .. _AppImage ecosystem: https://github.com/AppImage/AppImageKit/wiki/Ecosystem .. _oldest still-supported Ubuntu LTS release: https://www.ubuntu.com/info/release-end-of-life -.. _appdir-lint.sh: https://github.com/AppImage/pkg2appimage/blob/master/appdir-lint.sh +.. _appdir-lint.sh: https://github.com/AppImageCommunity/AppImageUpdate/blob/master/appdir-lint.sh .. _AppStream metainfo file: https://people.freedesktop.org/~hughsient/appdata/ diff --git a/source/packaging-guide/hosted-services/travis-ci.rst b/source/packaging-guide/hosted-services/travis-ci.rst index a29710e..02a8164 100644 --- a/source/packaging-guide/hosted-services/travis-ci.rst +++ b/source/packaging-guide/hosted-services/travis-ci.rst @@ -14,7 +14,7 @@ Services such as Travis CI make it easy to build software automatically whenever Producing an application directory using bash scripts ----------------------------------------------------- -Some types of applications can best be converted into application directories using custom bash script. However, to facilitate this, there is a collection of convenience functions in https://github.com/AppImage/pkg2appimage/blob/master/functions.sh which can use in your own scripts. +Some types of applications can best be converted into application directories using custom bash script. However, to facilitate this, there is a collection of convenience functions in https://github.com/AppImageCommunity/AppImageUpdate/blob/master/functions.sh which can use in your own scripts. .. todo:: diff --git a/source/packaging-guide/optional/updates.rst b/source/packaging-guide/optional/updates.rst index ae3bfc7..3a28a50 100644 --- a/source/packaging-guide/optional/updates.rst +++ b/source/packaging-guide/optional/updates.rst @@ -124,7 +124,7 @@ First of all, add the AppImageUpdate repository as a submodule. .. code-block:: shell - $ git submodule add https://github.com/AppImage/AppImageUpdate lib/AppImageUpdate + $ git submodule add https://github.com/AppImageCommunity/AppImageUpdate lib/AppImageUpdate You will have to initialize your submodule. AppImageUpdate pulls in some dependencies as well. Therefore, anyone using your repository will have to run the following command after cloning (unless they called :code:`git clone --recursive`): @@ -327,7 +327,7 @@ As you might not be interested in this feature, and probably don't trust on remo Updater updater("my.AppImage", true); -Now, the updater will perform the update and move the new file to the original file's location after successfully verifying the file integrity (and, as soon as it is implemented, validating the file's signature, see `the related issue on GitHub `__). +Now, the updater will perform the update and move the new file to the original file's location after successfully verifying the file integrity (and, as soon as it is implemented, validating the file's signature, see `the related issue on GitHub `__). .. note:: diff --git a/source/packaging-guide/overview.rst b/source/packaging-guide/overview.rst index 6d10841..43fcfaa 100644 --- a/source/packaging-guide/overview.rst +++ b/source/packaging-guide/overview.rst @@ -44,7 +44,7 @@ For `Electron`_ based applications, a tool called electron-builder_ can be used With electron-builder, making AppImages is as simple as defining ``AppImage`` as a target for Linux (default in the latest version of electron-builder). This should yield usable results for most applications. .. seealso:: - More information can be found in the `documentation on AppImage `__ and `the documentation on distributable formats `__ in the `electron-builder manual `__. + More information can be found in the `documentation on AppImage `__ and `the documentation on distributable formats `__ in the `electron-builder manual `__. There are a lot of examples on GitHub that can be found using the `GitHub search `__. @@ -82,7 +82,7 @@ including those made using: C/C++, Python, and Java. This tool removes the limitations of requiring an *old system* to compile the binaries. It can be used to pack an application from sources or to turn an existing Debian package into an AppImage. -For more information about appimage-builder please visit: https://appimage-builder.readthedocs.io +For more information about appimage-builder please visit: https://appimage-builder.readthedocs.io/en/latest/ .. _sec-create-appdir-manually: diff --git a/source/reference/best-practices.rst b/source/reference/best-practices.rst index 82394ce..35c5812 100644 --- a/source/reference/best-practices.rst +++ b/source/reference/best-practices.rst @@ -71,7 +71,7 @@ The trick is to search for :code:`/usr` in the binary and replace it by the same This command is also available as part of the bash function collection at `AppImage/pkg2appimage/functions.sh#L79`_. For the binary-patched application to work, you need to change to the :code:`usr/` directory inside the application directory before you launch the application. -.. _AppImage/pkg2appimage/functions.sh\#L79: https://github.com/AppImage/pkg2appimage/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/functions.sh#L79 +.. _AppImage/pkg2appimage/functions.sh\#L79: https://github.com/AppImageCommunity/AppImageUpdate/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/functions.sh#L79 .. _ref-binaries-compiled-on-old-system: @@ -91,7 +91,7 @@ then the binary is compiled on a newer system than the one you are trying to run When producing AppImages for the Subsurface project, we have had very good results by using **CentOS 7**, which is the oldest still-supported Linux distribution at the time of writing. This distribution is not too recent. However, there are still the most recent Qt and modern compilers available in the EPEL_ and devtools-2_ repositories (the community equivalent of the Red Hat Developer Toolset 2). Binaries built on this distribution run on nearly any distribution, including **Debian oldstable**. -Be sure to check https://github.com/AppImage/pkg2appimage, this is how I build and host my AppImages and the build systems to produce them in the cloud using travis-ci, docker, docker-hub, and bintray. Especially check the recipes for Subsurface and Scribus. +Be sure to check https://github.com/AppImageCommunity/AppImageUpdate, this is how I build and host my AppImages and the build systems to produce them in the cloud using travis-ci, docker, docker-hub, and bintray. Especially check the recipes for Subsurface and Scribus. See https://github.com/AppImage/AppImageKit/wiki/Docker-Hub-Travis-CI-Workflow for a description on how to set up a workflow involving your GitHub repository, Docker Hub, and Travis CI for a fully automated continuous build workflow. @@ -102,7 +102,7 @@ https://wiki.debian.org/Lintian .. _bingcc: https://github.com/sulix/bingcc .. _glibc_version_header: https://github.com/wheybags/glibc_version_header .. _EPEL: https://fedoraproject.org/wiki/EPEL -.. _devtools-2: http://people.centos.org/tru/devtools-2/ +.. _devtools-2: https://people.centos.org/tru/devtools-2/ .. seealso:: diff --git a/source/reference/desktop-integration.rst b/source/reference/desktop-integration.rst index 1f5076b..ab4e59a 100644 --- a/source/reference/desktop-integration.rst +++ b/source/reference/desktop-integration.rst @@ -16,7 +16,7 @@ A central component of the Linux desktop, so-called *desktop entries* (or, collo The FreeDesktop_ project maintains the so-called `Desktop Entry Specification`_. Desktop Entry files are `INI `__-style text documents containing key-value pairs, one per line. The file is structured in multiple sections, most notably the :code:`[Desktop Entry]`, where the main information goes into. There's a set of mandatory and optional keys to be set in these documents, and there may be additional sections. -.. _FreeDesktop: https://www.freedesktop.org/ +.. _FreeDesktop: https://www.freedesktop.org/wiki/ .. _Desktop Entry Specification: https://specifications.freedesktop.org/desktop-entry-spec/latest/ diff --git a/source/user-guide/mac.rst b/source/user-guide/mac.rst index c2a4af7..9bc9f56 100644 --- a/source/user-guide/mac.rst +++ b/source/user-guide/mac.rst @@ -38,7 +38,7 @@ should help macOS to Linux switchers to "get" AppImage concepts quickly. +---------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------+ -.. _AppImageUpdate: https://github.com/AppImage/AppImageUpdate +.. _AppImageUpdate: https://github.com/AppImageCommunity/AppImageUpdate .. _AppImageHub: https://github.com/appimage/appimage.github.io .. _Sparkle Framework: https://sparkle-project.org/ .. _update information: https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update-information diff --git a/source/user-guide/portable-mode.rst b/source/user-guide/portable-mode.rst index 385a86f..3609ec5 100644 --- a/source/user-guide/portable-mode.rst +++ b/source/user-guide/portable-mode.rst @@ -30,7 +30,7 @@ Example Imagine you want to use the Leafpad text editor, but carry its settings around with the executable. You can do the following: .. Tell Pygments to use 'shell' syntax, otherwise it defaults to 'python' -.. See http://www.sphinx-doc.org/en/1.4.9/markup/code.html#directive-code-block for more information +.. See https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html for more information .. code-block:: shell # Download Leafpad AppImage and make it executable From d7954684f25b7733a6a0c4c79e45e1c9ce741860 Mon Sep 17 00:00:00 2001 From: DrSheppard <60893791+Drsheppard01@users.noreply.github.com> Date: Thu, 20 Mar 2025 23:58:38 +0300 Subject: [PATCH 2/2] fix issues --- source/introduction/concepts.rst | 6 +++--- .../converting-binary-packages/pkg2appimage.rst | 6 +++--- source/packaging-guide/hosted-services/travis-ci.rst | 2 +- source/reference/best-practices.rst | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/source/introduction/concepts.rst b/source/introduction/concepts.rst index 25ab9af..901b81a 100644 --- a/source/introduction/concepts.rst +++ b/source/introduction/concepts.rst @@ -35,7 +35,7 @@ The author of an AppImage needs to decide for which target systems (Linux distri To be able to run on any Linux distribution, an AppImage should bundle all the resources it needs at runtime that cannot be reasonably expected to be "there" in the default installation of all still-supported target systems (Linux distributions). The most common resources are the actual binaries, shared library dependencies, icons and other graphics and of course one or more desktop files for desktop integration. -This doesn't mean an AppImage must not use resources provided by the system, like for example basic libraries that can be assumed to be part of every target system (e.g., the C standard library or graphics libraries), user interface themes or the like. See the `excludelist `__ for a list of the libraries we consider to currently be part of each still-supported target system (distribution). +This doesn't mean an AppImage must not use resources provided by the system, like for example basic libraries that can be assumed to be part of every target system (e.g., the C standard library or graphics libraries), user interface themes or the like. See the `excludelist `__ for a list of the libraries we consider to currently be part of each still-supported target system (distribution). .. _build-on-old-systems: @@ -49,9 +49,9 @@ Applications should be built on the oldest possible system, allowing them to run It may seem contradictory to :ref:`the previous section ` to rely on distribution provided resources. This is a trade-off between trying to reduce redundancies while at the same time being as self-contained as possible. -In some cases, including the libraries might even break the AppImage on the target system. Those libraries involve, among others, hardware dependent libraries such as graphics card drivers provided libraries (e.g., :code:`libGL.so.1`, (`source `__)), or libraries that are build and linked differently on different distributions (e.g., :code:`libharfbuzz.so.0` and :code:`libfreetype.so.6` (`source `__). +In some cases, including the libraries might even break the AppImage on the target system. Those libraries involve, among others, hardware dependent libraries such as graphics card drivers provided libraries (e.g., :code:`libGL.so.1`, (`source `__)), or libraries that are build and linked differently on different distributions (e.g., :code:`libharfbuzz.so.0` and :code:`libfreetype.so.6` (`source `__). -The list of libraries that can resp. have to be excluded, the so-called `excludelist `__, is carefully curated by the AppImage team, and is regularly updated. +The list of libraries that can resp. have to be excluded, the so-called `excludelist `__, is carefully curated by the AppImage team, and is regularly updated. .. _zlib: https://zlib.net/ .. _GLib: https://developer.gnome.org/glib/ diff --git a/source/packaging-guide/converting-binary-packages/pkg2appimage.rst b/source/packaging-guide/converting-binary-packages/pkg2appimage.rst index d766cad..2c7c7f5 100644 --- a/source/packaging-guide/converting-binary-packages/pkg2appimage.rst +++ b/source/packaging-guide/converting-binary-packages/pkg2appimage.rst @@ -24,7 +24,7 @@ To build an AppImage from a :code:`.yml` description file, simply run: :code:`.yml` description files tell pkg2appimage where to get the ingredients from, and how to convert them to an AppImage (besides the general steps already included in pkg2appimage). Study some `examples `__ to see how it works. -.. _pkg2appimage: https://github.com/AppImageCommunity/AppImageUpdate/blob/master/pkg2appimage +.. _pkg2appimage: https://github.com/AppImageCommunity/pkg2appimage/blob/master/pkg2appimage .. warning:: pkg2appimage suffers from a few notable issues: @@ -33,7 +33,7 @@ To build an AppImage from a :code:`.yml` description file, simply run: - pkg2appimage uses distribution packages downloaded using the package managers, however, the packages are not authenticated, as most security functionality has been deactivated. This is a major security issue. pkg2appimage is therefore recommended for personal use only. Upstream authors should consider :ref:`packaging from source `. .. seealso:: - See `this GitHub issue `__ for more information on the security issue. + See `this GitHub issue `__ for more information on the security issue. ``.yml`` files @@ -414,4 +414,4 @@ The following recipe will convert a Python 3 PyQt application using :code:`virtu Source: - https://github.com/AppImageCommunity/AppImageUpdate/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/recipes/Mu.yml + https://github.com/AppImageCommunity/pkg2appimage/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/recipes/Mu.yml diff --git a/source/packaging-guide/hosted-services/travis-ci.rst b/source/packaging-guide/hosted-services/travis-ci.rst index 02a8164..9936eba 100644 --- a/source/packaging-guide/hosted-services/travis-ci.rst +++ b/source/packaging-guide/hosted-services/travis-ci.rst @@ -14,7 +14,7 @@ Services such as Travis CI make it easy to build software automatically whenever Producing an application directory using bash scripts ----------------------------------------------------- -Some types of applications can best be converted into application directories using custom bash script. However, to facilitate this, there is a collection of convenience functions in https://github.com/AppImageCommunity/AppImageUpdate/blob/master/functions.sh which can use in your own scripts. +Some types of applications can best be converted into application directories using custom bash script. However, to facilitate this, there is a collection of convenience functions in https://github.com/AppImageCommunity/pkg2appimage/blob/master/functions.sh which can use in your own scripts. .. todo:: diff --git a/source/reference/best-practices.rst b/source/reference/best-practices.rst index 35c5812..45a7189 100644 --- a/source/reference/best-practices.rst +++ b/source/reference/best-practices.rst @@ -71,7 +71,7 @@ The trick is to search for :code:`/usr` in the binary and replace it by the same This command is also available as part of the bash function collection at `AppImage/pkg2appimage/functions.sh#L79`_. For the binary-patched application to work, you need to change to the :code:`usr/` directory inside the application directory before you launch the application. -.. _AppImage/pkg2appimage/functions.sh\#L79: https://github.com/AppImageCommunity/AppImageUpdate/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/functions.sh#L79 +.. _AppImage/pkg2appimage/functions.sh\#L79: https://github.com/AppImageCommunity/pkg2appimage/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/functions.sh#L79 .. _ref-binaries-compiled-on-old-system: @@ -91,7 +91,7 @@ then the binary is compiled on a newer system than the one you are trying to run When producing AppImages for the Subsurface project, we have had very good results by using **CentOS 7**, which is the oldest still-supported Linux distribution at the time of writing. This distribution is not too recent. However, there are still the most recent Qt and modern compilers available in the EPEL_ and devtools-2_ repositories (the community equivalent of the Red Hat Developer Toolset 2). Binaries built on this distribution run on nearly any distribution, including **Debian oldstable**. -Be sure to check https://github.com/AppImageCommunity/AppImageUpdate, this is how I build and host my AppImages and the build systems to produce them in the cloud using travis-ci, docker, docker-hub, and bintray. Especially check the recipes for Subsurface and Scribus. +Be sure to check https://github.com/AppImageCommunity/pkg2appimage, this is how I build and host my AppImages and the build systems to produce them in the cloud using travis-ci, docker, docker-hub, and bintray. Especially check the recipes for Subsurface and Scribus. See https://github.com/AppImage/AppImageKit/wiki/Docker-Hub-Travis-CI-Workflow for a description on how to set up a workflow involving your GitHub repository, Docker Hub, and Travis CI for a fully automated continuous build workflow.