From 4eb8baf23f0d920be94ce63d79ba63f7eab7486e Mon Sep 17 00:00:00 2001 From: TheAssassin Date: Wed, 25 Nov 2020 15:54:11 +0100 Subject: [PATCH] Use anonymous refs for all external links Issue in the reST spec, see https://github.com/sphinx-doc/sphinx/issues/3921#issuecomment-315581557 for more information. Fixes/prevents "duplicate explicit target name" errors. --- source/contact.rst | 8 ++++---- source/introduction/concepts.rst | 6 +++--- source/introduction/quickstart.rst | 2 +- source/introduction/software-overview.rst | 8 ++++---- .../converting-binary-packages/pkg2appimage.rst | 6 +++--- source/packaging-guide/distribution.rst | 4 ++-- source/packaging-guide/environment-variables.rst | 2 +- .../from-source/linuxdeploy-user-guide.rst | 4 ++-- .../packaging-guide/from-source/native-binaries.rst | 12 ++++++------ .../hosted-services/opensuse-build-service.rst | 6 +++--- source/packaging-guide/hosted-services/travis-ci.rst | 4 ++-- source/packaging-guide/manual.rst | 4 ++-- source/packaging-guide/optional/appstream.rst | 2 +- source/packaging-guide/optional/updates.rst | 12 ++++++------ source/packaging-guide/overview.rst | 6 +++--- source/reference/appdir.rst | 2 +- source/reference/architecture.rst | 2 +- source/reference/desktop-integration.rst | 2 +- source/reference/specification.rst | 4 ++-- .../external-tool-to-mount-and-extract-appimages.rst | 2 +- source/user-guide/run-appimages.rst | 2 +- .../troubleshooting/electron-sandboxing.rst | 2 +- source/user-guide/troubleshooting/fuse.rst | 4 ++-- source/user-guide/troubleshooting/index.rst | 2 +- 24 files changed, 54 insertions(+), 54 deletions(-) diff --git a/source/contact.rst b/source/contact.rst index a792009..6c1c73b 100644 --- a/source/contact.rst +++ b/source/contact.rst @@ -3,7 +3,7 @@ Contact ======= -The AppImage project documentation is brought to you by `the AppImage team `_. The source code is available `on GitHub `_. +The AppImage project documentation is brought to you by `the AppImage team `__. The source code is available `on GitHub `__. This page outlines how you can contact the team behind AppImage, e.g., to get additional support or have questions answered. @@ -11,14 +11,14 @@ This page outlines how you can contact the team behind AppImage, e.g., to get ad IRC --- -If you have further questions, please feel free to contact the AppImage team. The easiest and fastest way is to join our `IRC channel #appimage `_ on `Freenode `_ (`webchat `_). +If you have further questions, please feel free to contact the AppImage team. The easiest and fastest way is to join our `IRC channel #appimage `__ on `Freenode `__ (`webchat `__). .. note:: - Please beware that it might take a few minutes/hours until someone will check the chat and might be able to help you, so don't give up too quickly, and leave e.g., the tab open in the background if you can. You can also try at other times again. Please read `this article `_ before joining the IRC chat if you are new to IRC. + Please beware that it might take a few minutes/hours until someone will check the chat and might be able to help you, so don't give up too quickly, and leave e.g., the tab open in the background if you can. You can also try at other times again. Please read `this article `__ before joining the IRC chat if you are new to IRC. Forum ----- -A slower but more sustainable way is to use the `Discourse forum `_. You can log in using your existing Google or GitHub account, or alternatively register a local account with your email address. +A slower but more sustainable way is to use the `Discourse forum `__. You can log in using your existing Google or GitHub account, or alternatively register a local account with your email address. diff --git a/source/introduction/concepts.rst b/source/introduction/concepts.rst index b9b9b8c..5acf178 100644 --- a/source/introduction/concepts.rst +++ b/source/introduction/concepts.rst @@ -19,7 +19,7 @@ AppImages are simple to understand. Every AppImage is a regular file, and every .. _ref-opinion-reusable-frameworks: .. note:: - On a regular basis, `users ask `_ about implementing support for some sort of "reusable/shared frameworks". These frameworks are supposed to contain bundles of libraries which are needed by more than one AppImage, and hence could save some disk space. For management, they suggest complex automagic systems that will automatically fetch the "frameworks" from the Internet if they're not available, or some complicated, mostly manual methods how to users could bundle frameworks together with the AppImages on portable disks like USB sticks. + On a regular basis, `users ask `__ about implementing support for some sort of "reusable/shared frameworks". These frameworks are supposed to contain bundles of libraries which are needed by more than one AppImage, and hence could save some disk space. For management, they suggest complex automagic systems that will automatically fetch the "frameworks" from the Internet if they're not available, or some complicated, mostly manual methods how to users could bundle frameworks together with the AppImages on portable disks like USB sticks. These may be good ideas for some people, and even if they worked perfectly fine, they'd break with our most important concept: :ref:`one app = one file `. AppImages are so simple to understand *because* every application is a single file. There's no complexity in this approach, even grandma could understand it. And after all, disk space is cheap nowadays, right? @@ -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,7 +49,7 @@ 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 :ref:`excludelist `, is carefully curated by the AppImage team, and is regularly updated. diff --git a/source/introduction/quickstart.rst b/source/introduction/quickstart.rst index 529d17f..388152b 100644 --- a/source/introduction/quickstart.rst +++ b/source/introduction/quickstart.rst @@ -48,7 +48,7 @@ That's it! The AppImage should now be executed. Translated versions of this guide ********************************* -Translated versions are available in a `post in the AppImage forum `_. +Translated versions are available in a `post in the AppImage forum `__. Getting help diff --git a/source/introduction/software-overview.rst b/source/introduction/software-overview.rst index e5a1c72..cee569c 100644 --- a/source/introduction/software-overview.rst +++ b/source/introduction/software-overview.rst @@ -20,7 +20,7 @@ AppImage project AppImageKit ----------- -`AppImageKit `_ is the reference implementation of the :ref:`AppImage specification `. It is split up into several components, which are described in this subsection. +`AppImageKit `__ is the reference implementation of the :ref:`AppImage specification `. It is split up into several components, which are described in this subsection. .. _ref-runtime: @@ -42,7 +42,7 @@ appimagetool is the easiest way to create AppImages from existing directories on appimagetool implements all optional features, like for instance :ref:`update information `, :ref:`signing `, and some linting options to make sure the information in the AppImage is valid (for instance, it can validate :ref:`AppStream files `). -**Download:** You can get it as an AppImage from https://github.com/AppImage/AppImageKit/releases/continuous. +**Download:** You can get it as an AppImage from https://github.com/AppImage/AppImageKit/releases/continuous. AppRun @@ -108,7 +108,7 @@ The project consists of two tools: :code:`appimageupdatetool`, a full-featured C appimaged --------- -`appimaged `_ is a daemon that monitors a predefined set of directories on the system, looking for AppImages. It automatically integrates all AppImages it can find during an initial search, and then live watches for new AppImage (or AppImages that were removed) and (de)integrates these immediately. +`appimaged `__ is a daemon that monitors a predefined set of directories on the system, looking for AppImages. It automatically integrates all AppImages it can find during an initial search, and then live watches for new AppImage (or AppImages that were removed) and (de)integrates these immediately. It is shipped in a few native distribution package formats as well as as AppImage. @@ -142,7 +142,7 @@ linuxdeploy linuxdeploy_ is a simple yet flexible, plugins-based to use tool that can be used to create AppDirs and AppImages. It has been developed in 2018, and describes itself as an "AppDir creation and maintenance tool". -linuxdeploy is planned to succeed of :ref:`linuxdeployqt`, and can be used in all projects that use :ref:`linuxdeployqt`. The list of plugins is continually growing, providing solutions for bundling frameworks such as `Qt `_ as well as complete environments for non-native programming languages such as `Python `_. +linuxdeploy is planned to succeed of :ref:`linuxdeployqt`, and can be used in all projects that use :ref:`linuxdeployqt`. The list of plugins is continually growing, providing solutions for bundling frameworks such as `Qt `__ as well as complete environments for non-native programming languages such as `Python `__. .. _linuxdeploy: https://github.com/linuxdeploy/linuxdeploy diff --git a/source/packaging-guide/converting-binary-packages/pkg2appimage.rst b/source/packaging-guide/converting-binary-packages/pkg2appimage.rst index ee2c0d8..d9619c6 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,7 +22,7 @@ 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 @@ -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 diff --git a/source/packaging-guide/distribution.rst b/source/packaging-guide/distribution.rst index 90a43d9..79f04da 100644 --- a/source/packaging-guide/distribution.rst +++ b/source/packaging-guide/distribution.rst @@ -86,7 +86,7 @@ You can use a "Download as an AppImage" banner alongside other similar buttons: Link this banner directly to the latest version of your AppImage, or to a download page containing the link to the latest version of your AppImage. -Banner by `Khushraj Rathod `_ under the `CC0 license `_ +Banner by `Khushraj Rathod `__ under the `CC0 license `_ Social Media '''''''''''' @@ -98,7 +98,7 @@ Also be sure to advertise your new AppImage on social media, for example on Twit AppImageHub ''''''''''' -You may want to add your AppImage to `AppImageHub `_, a crowd-sourced directory of available, automatically tested AppImages with data that 3rd party app stores and software centers can use. Given an URL to an AppImage, it inspects the AppImage and puts it into a community-maintained catalog. +You may want to add your AppImage to `AppImageHub `__, a crowd-sourced directory of available, automatically tested AppImages with data that 3rd party app stores and software centers can use. Given an URL to an AppImage, it inspects the AppImage and puts it into a community-maintained catalog. App stores and software centers can consume the metadata collected by this project. See `AppImage ecosystem`_. diff --git a/source/packaging-guide/environment-variables.rst b/source/packaging-guide/environment-variables.rst index 6ffd3eb..2e9ca4c 100644 --- a/source/packaging-guide/environment-variables.rst +++ b/source/packaging-guide/environment-variables.rst @@ -76,5 +76,5 @@ The type 2 AppImage runtime makes a few environment variables available for use Scenarios where :code:`ARGV0` is really useful involve so-called multi-binary AppImages, where the filename in :code:`ARGV0` defines which program is called inside the AppImage. This concept is also known from - single-binary tools like `BusyBox `_, and can be implemented in a custom + single-binary tools like `BusyBox `__, and can be implemented in a custom :code:`AppRun` script (see :ref:`Architecture ` for more information). diff --git a/source/packaging-guide/from-source/linuxdeploy-user-guide.rst b/source/packaging-guide/from-source/linuxdeploy-user-guide.rst index 4be4cf8..b7de88e 100644 --- a/source/packaging-guide/from-source/linuxdeploy-user-guide.rst +++ b/source/packaging-guide/from-source/linuxdeploy-user-guide.rst @@ -11,7 +11,7 @@ This page illustrates how linuxdeploy can be used. linuxdeploy is capable of packaging dependencies of resources in an existing AppDir, or creating the AppDir from scratch, bundling resources into the right locations that the user passes to it. -linuxdeploy describes itself as an `"AppDir maintenance tool" `_. Its primary focus is on AppDirs, and it uses plugins to create output formats such as AppImages. +linuxdeploy describes itself as an `"AppDir maintenance tool" `__. Its primary focus is on AppDirs, and it uses plugins to create output formats such as AppImages. .. contents:: Contents @@ -49,7 +49,7 @@ linuxdeploy provides different flags to bundle different kinds of resources. Onl Bundle a desktop file into the AppDir. These are required for desktop integration, and there must always be at least one of them in the AppDir. Please see :ref:`creating-desktop-file` for a guide how they can be created, and for best practices related to AppImages. ``--icon``/``-i`` - Bundle icon file. Supported are all formats which the `Icon Theme Specification `_ lists. linuxdeploy will automatically calculate the right output path, which depends on file format and resolution. You can specify multiple icons for multiple resolutions in the form of ``/.``. + Bundle icon file. Supported are all formats which the `Icon Theme Specification `__ lists. linuxdeploy will automatically calculate the right output path, which depends on file format and resolution. You can specify multiple icons for multiple resolutions in the form of ``/.``. .. |rpath-comment| replace:: Set up everything so that other libraries, executables etc. use this one instead of a system one. diff --git a/source/packaging-guide/from-source/native-binaries.rst b/source/packaging-guide/from-source/native-binaries.rst index 8c60ad0..73c346e 100644 --- a/source/packaging-guide/from-source/native-binaries.rst +++ b/source/packaging-guide/from-source/native-binaries.rst @@ -9,7 +9,7 @@ The AppImage team provides tools that simplify the packaging process significant .. _linuxdeploy: https://github.com/linuxdeploy/linuxdeploy -linuxdeploy is an AppDir maintenance tool. Its primary focus is on AppDirs, AppImage is just one possible output format. It features a plugin system for greater flexibility in use. Plugins can either bundle additional resources for e.g., frameworks such as `Qt `_, but are also used to provide output generators, e.g., for `AppImages `_. +linuxdeploy is an AppDir maintenance tool. Its primary focus is on AppDirs, AppImage is just one possible output format. It features a plugin system for greater flexibility in use. Plugins can either bundle additional resources for e.g., frameworks such as `Qt `__, but are also used to provide output generators, e.g., for `AppImages `__. .. contents:: Contents @@ -107,7 +107,7 @@ Using linuxdeploy for building AppImages Now that we have the basic AppDir, we need to bundle dependencies into it to make the AppDir self-contained in preparation to make an AppImage from it. The following guide shows how linuxdeploy_ is used for this purpose. -linuxdeploy describes itself as an `"AppDir maintenance tool" `_. Its primary focus is on AppDirs, and it uses plugins to create output formats such as AppImages. +linuxdeploy describes itself as an `"AppDir maintenance tool" `__. Its primary focus is on AppDirs, and it uses plugins to create output formats such as AppImages. The following section describes how it can be used to deploy dependencies of applications into an AppDir that was created using the methods described in the :ref:`previous section `, and shows how this AppDir can eventually be packaged as an AppImage. @@ -149,7 +149,7 @@ Example: # run linuxdeploy and generate an AppDir > ./linuxdeploy-x86_64.AppImage --appdir AppDir -You can bundle additional resources such as icon files, executable and desktop files using the respective flags described in the ``--help`` text or on linuxdeploy's `homepage `_. +You can bundle additional resources such as icon files, executable and desktop files using the respective flags described in the ``--help`` text or on linuxdeploy's `homepage `__. .. note:: Desktop file and icon are used for so-called :ref:`desktop integration `. If your build system didn't install such files into the right location, you can have linuxdeploy put your own files into the right places. Please see :ref:`linuxdeploy-bundle-desktop-files-icons` for more information. @@ -188,7 +188,7 @@ Please see :ref:`linuxdeploy-input-plugins` for more information. Build AppImages from AppDir using linuxdeploy --------------------------------------------- -As mentioned previously, linuxdeploy uses plugins to create actual output files from AppDirs. For AppImages, there's `linuxdeploy-plugin-appimage `_. +As mentioned previously, linuxdeploy uses plugins to create actual output files from AppDirs. For AppImages, there's `linuxdeploy-plugin-appimage `__. To create AppImages, just add ``--output appimage`` to your linuxdeploy call to enable the plugin. An AppImage will be created using :ref:`ref-appimagetool`. @@ -207,7 +207,7 @@ As most plugins, linuxdeploy-plugin-appimage provides some environment variables Add update information to the AppImage, and generate a ``.zsync`` file. .. seealso:: - More information on the environment variables can be found in the `README `_, including a complete (and up to date) list of supported environment variables. + More information on the environment variables can be found in the `README `__, including a complete (and up to date) list of supported environment variables. Examples @@ -218,7 +218,7 @@ In this section, some examples how linuxdeploy can be used are shown. QtQuickApp ++++++++++ -This section contains a few example scripts that showcase how AppImages can be built for `QtQuickApp `_, a basic demonstration app based on QtQuick, using some QML internally. It can be built using both CMake and qmake. We use it to show some example scripts how AppImages can be built for it, using the methods introduced in this guide. +This section contains a few example scripts that showcase how AppImages can be built for `QtQuickApp `__, a basic demonstration app based on QtQuick, using some QML internally. It can be built using both CMake and qmake. We use it to show some example scripts how AppImages can be built for it, using the methods introduced in this guide. Using qmake and ``make install`` diff --git a/source/packaging-guide/hosted-services/opensuse-build-service.rst b/source/packaging-guide/hosted-services/opensuse-build-service.rst index f2069b8..59f0164 100644 --- a/source/packaging-guide/hosted-services/opensuse-build-service.rst +++ b/source/packaging-guide/hosted-services/opensuse-build-service.rst @@ -3,7 +3,7 @@ Using the Open Build Service ============================ -`Open Build Service `_ is a generic system to build and distribute packages from sources in an automatic, consistent and reproducible way. It allows you to build software for various package formats and distributions. Now it can also build AppImages that run on a variety of distributions. +`Open Build Service `__ is a generic system to build and distribute packages from sources in an automatic, consistent and reproducible way. It allows you to build software for various package formats and distributions. Now it can also build AppImages that run on a variety of distributions. The `openSUSE Build Service`_ is the public instance of the Open Build Service (OBS). This infrastructure can can be used for free by open source projects. However, you are not limited to it - you can set up your own Open Build Service instance if you like. @@ -31,7 +31,7 @@ There are different ways to build AppImages. Why is using Open Build Service int The osc command line tool ------------------------- -While OBS can be used entirely through the web interface, it can be beneficial to use the `osc` command line tool. It is available as an AppImage from `OpenSUSE's download page `_. Since this page is mainly geared toward beginners, it mainly describes the web interface. However, using the command line tool may offer a quicker route for more experienced OBS users. +While OBS can be used entirely through the web interface, it can be beneficial to use the `osc` command line tool. It is available as an AppImage from `OpenSUSE's download page `__. Since this page is mainly geared toward beginners, it mainly describes the web interface. However, using the command line tool may offer a quicker route for more experienced OBS users. Setting up an account and a project @@ -121,7 +121,7 @@ The :code:`build:` section can be used to define resources which are required to The packages listed in the ingredients section do not get installed into the build environment but get extracted into the AppDir. -URLs for the supported source control management systems (git, svn, cvs, hg, bzr) get handled via the appimage source service, which is a part of `obs-service-tar_scm `_. It is downloading the sources and provides them to the build system as directory structure. +URLs for the supported source control management systems (git, svn, cvs, hg, bzr) get handled via the appimage source service, which is a part of `obs-service-tar_scm `__. It is downloading the sources and provides them to the build system as directory structure. .. todo:: diff --git a/source/packaging-guide/hosted-services/travis-ci.rst b/source/packaging-guide/hosted-services/travis-ci.rst index f5b6708..037facd 100644 --- a/source/packaging-guide/hosted-services/travis-ci.rst +++ b/source/packaging-guide/hosted-services/travis-ci.rst @@ -39,7 +39,7 @@ For general information on linuxdeploy, see :ref:`ref-linuxdeploy`. Uploading the generated AppImage -------------------------------- -Once an Appimage has been generated, you want to upload it to GitHub Releases. For this, you can use the :code:`upload.sh` script available in the `uploadtool repository on GitHub `_. +Once an Appimage has been generated, you want to upload it to GitHub Releases. For this, you can use the :code:`upload.sh` script available in the `uploadtool repository on GitHub `__. .. note:: @@ -52,7 +52,7 @@ Super simple uploading of continuous builds (each push) to GitHub Releases. If t Using ``upload.sh`` ^^^^^^^^^^^^^^^^^^^ -The :code:`upload.sh` script in the `uploadtool repository `_ is designed to be called from Travis CI after a successful build. By default, this script will *delete* any pre-existing release tagged with :code:`continuous`, tag the current state with the name :code:`continuous`, create a new release with that name, and upload the specified binaries there. For pull requests, it will upload the binaries to transfer.sh instead and post the resulting download URL to the pull request page on GitHub. +The :code:`upload.sh` script in the `uploadtool repository `__ is designed to be called from Travis CI after a successful build. By default, this script will *delete* any pre-existing release tagged with :code:`continuous`, tag the current state with the name :code:`continuous`, create a new release with that name, and upload the specified binaries there. For pull requests, it will upload the binaries to transfer.sh instead and post the resulting download URL to the pull request page on GitHub. .. _uploadtool-github: https://github.com/probonopd/uploadtool diff --git a/source/packaging-guide/manual.rst b/source/packaging-guide/manual.rst index f0fa3fc..8ac3e12 100644 --- a/source/packaging-guide/manual.rst +++ b/source/packaging-guide/manual.rst @@ -43,7 +43,7 @@ Your binary, myapp, must not contain any hardcoded paths that would prevent it f strings MyApp.AppDir/usr/bin/myapp | grep /usr -Should this return something, then you need to modify your app programmatically (e.g., by using relative paths, using `binreloc `_, or using :code:`QString QCoreApplication::applicationDirPath()`). +Should this return something, then you need to modify your app programmatically (e.g., by using relative paths, using `binreloc `__, or using :code:`QString QCoreApplication::applicationDirPath()`). If you prefer not to change the source code of your app and/or would not like to recompile your app, you can also patch the binary, for example using the command @@ -99,7 +99,7 @@ To create an AppImage, run :code:`appimagetool` on the AppDir in order to turn i Bundling GTK libraries ^^^^^^^^^^^^^^^^^^^^^^ -The following steps allow bundling the GTK libraries and configuration files in a relocatable way, without the need to patch the files and replace hard-coded paths. The full set of bundling commands, in the form of a bash script, can be found `here `_. They assume the existence of an :code:`APPDIR` environment variable that points to the root folder of the AppImage bundle. +The following steps allow bundling the GTK libraries and configuration files in a relocatable way, without the need to patch the files and replace hard-coded paths. The full set of bundling commands, in the form of a bash script, can be found `here `__. They assume the existence of an :code:`APPDIR` environment variable that points to the root folder of the AppImage bundle. GDK-Pixbuf modules and cache file """"""""""""""""""""""""""""""""" diff --git a/source/packaging-guide/optional/appstream.rst b/source/packaging-guide/optional/appstream.rst index 89b8958..7743c5e 100644 --- a/source/packaging-guide/optional/appstream.rst +++ b/source/packaging-guide/optional/appstream.rst @@ -21,7 +21,7 @@ Desktop environments, file managers, AppImage catalogs, software centers, and ap So if you would like your application to show a nice screenshot in app centers, you should add an AppStream metainfo file to your AppImage. AppStream is a format that exists independently of AppImage and can be used in conjunction with other packaging formats as well. Many open source applications already come with AppStream metainfo files by default. .. seealso:: - More information on AppStream can be found on the `FreeDesktop.org pages `_. + More information on AppStream can be found on the `FreeDesktop.org pages `__. Using the AppStream generator diff --git a/source/packaging-guide/optional/updates.rst b/source/packaging-guide/optional/updates.rst index f5958b4..ae3bfc7 100644 --- a/source/packaging-guide/optional/updates.rst +++ b/source/packaging-guide/optional/updates.rst @@ -45,9 +45,9 @@ Please see https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update- Using linuxdeploy ^^^^^^^^^^^^^^^^^ -:ref:`linuxdeploy's ` `AppImage plugin `_ supports an environment variable ``$UPDATE_INFORMATION`` (or short ``$UPD_INFO``) that can be used to set the update information manually. +:ref:`linuxdeploy's ` `AppImage plugin `__ supports an environment variable ``$UPDATE_INFORMATION`` (or short ``$UPD_INFO``) that can be used to set the update information manually. -Please see `the README `_ for details. +Please see `the README `__ for details. Using linuxdeployqt @@ -67,7 +67,7 @@ One way to inject the update information into the AppImage created with :code:`e Making AppImages self-updateable -------------------------------- -Once you have made your AppImage updateable via external tools as described above, you may optionally go one step further and bundle everything that is required to update an AppImage inside the AppImage itself, so that the user can get updates without needing anything besides the AppImage itself. This is conceptually similar to how the `Sparkle Framework `_ works on macOS. +Once you have made your AppImage updateable via external tools as described above, you may optionally go one step further and bundle everything that is required to update an AppImage inside the AppImage itself, so that the user can get updates without needing anything besides the AppImage itself. This is conceptually similar to how the `Sparkle Framework `__ works on macOS. Via AppImageUpdate built into the AppImage @@ -134,7 +134,7 @@ You will have to initialize your submodule. AppImageUpdate pulls in some depende $ git submodule update --init --recursive -Please refer to the `Git book `_ for more information about submodules and how they work, how to update them etc. +Please refer to the `Git book `__ for more information about submodules and how they work, how to update them etc. Next, instruct CMake that you want to use the library. Add :code:`add_subdirectory(AppImageUpdate)` to :code:`lib/CMakeLists.txt`. @@ -198,7 +198,7 @@ See this easy example for an update check: This is faster and less verbose than an exception based workflow, however, you can't see what caused the update check to fail. -This can be found out using the built in status message system. Every :code:`Updater` instance contains a message queue. All methods within the updater and the systems it uses (like e.g., `ZSync2 `_, which is one of the backends for the binary delta updates) add messages to this queue, which means that all kinds of status messages ever generated by any of the libraries will end up there. +This can be found out using the built in status message system. Every :code:`Updater` instance contains a message queue. All methods within the updater and the systems it uses (like e.g., `ZSync2 `__, which is one of the backends for the binary delta updates) add messages to this queue, which means that all kinds of status messages ever generated by any of the libraries will end up there. .. note:: @@ -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 29bdff9..e703698 100644 --- a/source/packaging-guide/overview.rst +++ b/source/packaging-guide/overview.rst @@ -29,7 +29,7 @@ This option might be the easiest if you already have continuous builds on Travis More information on using Travis CI for making AppImages can be found in :ref:`ref-travis-ci`. .. seealso:: - There are a lot of examples on GitHub that can be found using the `GitHub search `_. + There are a lot of examples on GitHub that can be found using the `GitHub search `__. .. _sec-electron-builder: @@ -41,9 +41,9 @@ 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 `_. + There are a lot of examples on GitHub that can be found using the `GitHub search `__. .. _Electron: https://electronjs.org/ .. _electron-builder: https://www.electron.build/ diff --git a/source/reference/appdir.rst b/source/reference/appdir.rst index bc6791d..23ed2c5 100644 --- a/source/reference/appdir.rst +++ b/source/reference/appdir.rst @@ -54,7 +54,7 @@ Conventions In contrary to the rules in the previous section, the ones introduced in this section are no basic requirement. However, this is the recommended structure to put applications into AppDirs. It's picking up ideas from well-known, widely spread Linux standards such as the `Filesystem Hierarchy Standard`_ (part of the `Linux Standards Base`_). .. seealso:: - A very good summary of the FHS can be found on `Wikipedia `_. + A very good summary of the FHS can be found on `Wikipedia `__. .. _Filesystem Hierarchy Standard: https://wiki.linuxfoundation.org/lsb/fhs .. _Linux Standards Base: https://wiki.linuxfoundation.org/lsb/start diff --git a/source/reference/architecture.rst b/source/reference/architecture.rst index 8f479a5..10809c5 100644 --- a/source/reference/architecture.rst +++ b/source/reference/architecture.rst @@ -19,7 +19,7 @@ An AppImage consists of two parts: a *runtime* and a *file system image*. For th .. figure:: /_static/img/reference/architecture-overview.svg :align: center - AppImage file structure. Copyright © `@TheAssassin `_ 2019. Licensed under CC-By-SA Intl 4.0. + AppImage file structure. Copyright © `@TheAssassin `__ 2019. Licensed under CC-By-SA Intl 4.0. What happens when an AppImage is run is that the operating system runs the AppImage as an executable. The runtime, the executable part, tries to mount the file system image using :ref:`FUSE `. If that succeeds, the :ref:`AppDir ` is available in a :ref:`temporary mountpoint `, and can be used like a read-only directory. diff --git a/source/reference/desktop-integration.rst b/source/reference/desktop-integration.rst index 8d9c70c..865d753 100644 --- a/source/reference/desktop-integration.rst +++ b/source/reference/desktop-integration.rst @@ -14,7 +14,7 @@ Desktop files A central component of the Linux desktop, so-called *desktop entries* (or, colloquially, *desktop files*) are also relevant for AppImage desktop integration. Every AppImage ships with such a file in its :ref:`AppDir `. -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. +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/ .. _Desktop Entry Specification: https://specifications.freedesktop.org/desktop-entry-spec/latest/ diff --git a/source/reference/specification.rst b/source/reference/specification.rst index 838b95b..9963f62 100644 --- a/source/reference/specification.rst +++ b/source/reference/specification.rst @@ -20,11 +20,11 @@ Development The specification's repository contains a description of the current **type 2** format. You can find the `full text `_ -in the `GitHub repository `_. +in the `GitHub repository `__. The documentation receives updates regularly, e.g., to fix bugs or document new features. For type 2, a decision was made to not release specific versions but work with continuous releases. This implies there might be some AppImages that lack newer features because they're using an older runtime, etc. Backwards compatibility is maintained by the team in the reference implementation. -Please feel free to file `issues on GitHub `_ if you encounter bugs or have ideas for additional features. Also, improvements on wording etc. are highly appreciated. +Please feel free to file `issues on GitHub `__ if you encounter bugs or have ideas for additional features. Also, improvements on wording etc. are highly appreciated. Reference implementation diff --git a/source/user-guide/notes/external-tool-to-mount-and-extract-appimages.rst b/source/user-guide/notes/external-tool-to-mount-and-extract-appimages.rst index 8e371c8..7cf89e5 100644 --- a/source/user-guide/notes/external-tool-to-mount-and-extract-appimages.rst +++ b/source/user-guide/notes/external-tool-to-mount-and-extract-appimages.rst @@ -1,4 +1,4 @@ .. seealso:: There is currently no way to use the former method without calling the target AppImage. This might not always be appropriate, e.g., if the AppImage is not trustworthy. - The AppImage team is working on implementing a mount option in :ref:`ref-appimagetool`. Please see the related `GitHub issue `_ for progress on this. + The AppImage team is working on implementing a mount option in :ref:`ref-appimagetool`. Please see the related `GitHub issue `__ for progress on this. diff --git a/source/user-guide/run-appimages.rst b/source/user-guide/run-appimages.rst index 50982f2..729061b 100644 --- a/source/user-guide/run-appimages.rst +++ b/source/user-guide/run-appimages.rst @@ -101,7 +101,7 @@ AppImages are standalone bundles, and do not need to be *installed*. However, so appimaged ********* -`appimaged `_ is a daemon that monitors the system and integrates AppImages. It monitors a predefined set of directories on the user's system searching for AppImages, and integrates them into the system using :ref:`libappimage`. +`appimaged `__ is a daemon that monitors the system and integrates AppImages. It monitors a predefined set of directories on the user's system searching for AppImages, and integrates them into the system using :ref:`libappimage`. .. seealso:: More information on appimaged can be found in :ref:`appimaged`. diff --git a/source/user-guide/troubleshooting/electron-sandboxing.rst b/source/user-guide/troubleshooting/electron-sandboxing.rst index 6754386..ecae8c0 100644 --- a/source/user-guide/troubleshooting/electron-sandboxing.rst +++ b/source/user-guide/troubleshooting/electron-sandboxing.rst @@ -3,7 +3,7 @@ I have issues with Electron-based AppImages and their sandboxing ================================================================ -AppImages based on `Electron `_ require the kernel to be configured in a certain way to allow for its sandboxing to work as intended (specifically, the kernel needs to be allowed to provide "unprivileged namespaces"). Many distributions come with this configured out of the box (like `Ubuntu `_ for instance), but some do not (for example `Debian `_). +AppImages based on `Electron `__ require the kernel to be configured in a certain way to allow for its sandboxing to work as intended (specifically, the kernel needs to be allowed to provide "unprivileged namespaces"). Many distributions come with this configured out of the box (like `Ubuntu `__ for instance), but some do not (for example `Debian `__). .. warning:: diff --git a/source/user-guide/troubleshooting/fuse.rst b/source/user-guide/troubleshooting/fuse.rst index 498e123..6b19a31 100644 --- a/source/user-guide/troubleshooting/fuse.rst +++ b/source/user-guide/troubleshooting/fuse.rst @@ -111,7 +111,7 @@ On Clear Linux OS, FUSE _should_ be enabled by default. However, if you see the .. seealso:: - This bug was also reported on `reported on GitHub `_. + This bug was also reported on `reported on GitHub `__. Setting up FUSE on Chromium OS, Chrome OS, Crostini or other derivatives @@ -201,7 +201,7 @@ Type 1 AppImages are regular ISO9660 files. They can therefore be *loop-mounted* # when you're done, you can unmount the AppImage again sudo unmount /mnt -You can alternatively extract the AppImage, either using `AppImageExtract `_ or using an extraction tool which supports ISO9660 images (e.g., ``bsdtar``): +You can alternatively extract the AppImage, either using `AppImageExtract `__ or using an extraction tool which supports ISO9660 images (e.g., ``bsdtar``): .. code-block:: shell diff --git a/source/user-guide/troubleshooting/index.rst b/source/user-guide/troubleshooting/index.rst index 68035e7..d2edfe0 100644 --- a/source/user-guide/troubleshooting/index.rst +++ b/source/user-guide/troubleshooting/index.rst @@ -8,7 +8,7 @@ the most common issues you can have when using AppImages. .. note:: - If you as a user think there are errors within this section or you would like to have some additional problems covered, please do not hesitate to `create an issue `_ on `GitHub `_ (or ideally send a pull request right away). We're always open for feedback! + If you as a user think there are errors within this section or you would like to have some additional problems covered, please do not hesitate to `create an issue `__ on `GitHub `__ (or ideally send a pull request right away). We're always open for feedback! This page is not considered to be exhaustive. For additional help, please see the :ref:`Contact page `.