QoL pull request

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

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.
 

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 = ''

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 <https://github.com/AppImage/pkg2appimage/blob/master/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 <https://github.com/AppImageCommunity/pkg2appimage/blob/master/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 <no-external-dependencies>` 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 <https://github.com/AppImage/pkg2appimage/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist\#L38-L41>`__)), or libraries that are build and linked differently on different distributions (e.g., :code:`libharfbuzz.so.0` and :code:`libfreetype.so.6` (`source <https://github.com/AppImage/pkg2appimage/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist\#L98-L102>`__).
+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 <https://github.com/AppImageCommunity/pkg2appimage/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist\#L38-L41>`__)), or libraries that are build and linked differently on different distributions (e.g., :code:`libharfbuzz.so.0` and :code:`libfreetype.so.6` (`source <https://github.com/AppImageCommunity/AppImageUpdate/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist\#L98-L102>`__).
 
-The list of libraries that can resp. have to be excluded, the so-called `excludelist <https://github.com/AppImage/pkg2appimage/blob/master/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 <https://github.com/AppImageCommunity/pkg2appimage/blob/master/excludelist>`__, is carefully curated by the AppImage team, and is regularly updated.
 
 .. _zlib: https://zlib.net/
 .. _GLib: https://developer.gnome.org/glib/

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:
 

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 <https://github.com/AppImage/pkg2appimage/tree/master/recipes>`__ 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 <https://github.com/AppImageCommunity/AppImageUpdate/tree/master/recipes>`__ 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 <https://github.com/AppImage/pkg2appimage/tree/master/recipes>`__ 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 <https://github.com/AppImageCommunity/AppImageUpdate/tree/master/recipes>`__ to see how it works.
 
-.. _pkg2appimage: https://github.com/AppImage/pkg2appimage/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 <ref-from-source>`.
 
    .. seealso::
-      See `this GitHub issue <https://github.com/AppImage/pkg2appimage/issues/197>`__ for more information on the security issue.
+      See `this GitHub issue <https://github.com/AppImageCommunity/pkg2appimage/issues/197>`__ 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/pkg2appimage/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/recipes/Mu.yml

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/
 
 

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/pkg2appimage/blob/master/functions.sh which can use in your own scripts.
 
 .. todo::
 

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 <https://github.com/AppImage/AppImageUpdate/issues/16>`__).
+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 <https://github.com/AppImageCommunity/AppImageUpdate/issues/16>`__).
 
 .. note::
 

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 <https://www.electron.build/configuration/appimage.html>`__ and `the documentation on distributable formats <https://www.electron.build/index.html#pack-only-in-a-distributable-format>`__ in the `electron-builder manual <https://www.electron.build>`__.
+   More information can be found in the `documentation on AppImage <https://www.electron.build/appimage>`__ and `the documentation on distributable formats <https://www.electron.build/index.html#pack-only-in-a-distributable-format>`__ in the `electron-builder manual <https://www.electron.build>`__.
 
    There are a lot of examples on GitHub that can be found using the `GitHub search <https://github.com/search?utf8=%E2%9C%93&q=electron-builder+linux+target+appimage&type=Code&ref=searchresults>`__.
 
@@ -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:

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/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/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/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.
 
@@ -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::
 

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 <https://en.wikipedia.org/wiki/INI_file>`__-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/
 
 

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

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