Fix all links

Author: meator

src/mini-tutorials/how-to-add-completions.md

@@ -44,13 +44,13 @@ or somewhere else. Or they might not be documented at all.
 Sometimes the build system needs to generate completions.
 
 This should be familiar to you if you've read my [xbps-src packaging
-tutorial](xbps-src-packaging-tutorial.md), because it's used in
-[`bat`](packaging-bat.md) itself.
+tutorial](../xbps-src-tutorial/index.md), because it's used in
+[`bat`](../xbps-src-tutorial/packaging-bat.md) itself.
 
 A disadvantage of this approach is that the shell completion generation might
 have extra dependencies or it might require tweaking (like setting
 `BAT_ASSETS_GEN_DIR` in
-[`bat`](packaging-bat.md#installing-supplementary-files)).
+[`bat`](../xbps-src-tutorial/packaging-bat.md#installing-supplementary-files)).
 
 If the build system generates completions, it also usually installs them. But
 this isn't the case in `bat` for example.
@@ -70,7 +70,7 @@ As you sure remember, you can't run programs compiled for target architecture on
 host. If the program is compiled (`hatch` mentioned above isn't by the way, so
 the following advice doesn't apply to it), you'll have to use `build_helper=qemu`.
 
-This is described in [tips and tricks](tips_and_tricks.md#qemu).
+This is described in [tips and tricks](../tips_and_tricks.md#qemu).
 
 This is used in
 [`mdBook`](https://github.com/void-linux/void-packages/blob/3ddc63b10ff4f7a574996a3a43952c39c732101f/srcpkgs/mdBook/template#L18-L21)

src/mini-tutorials/how-to-fetch-git-submodules.md

@@ -12,17 +12,17 @@ that breakage won't occur, you should replace the submodule with actual packaged
 dependency.
 
 If you choose this path, you will likely have to [patch the build
-system](packaging-j4-dmenu-desktop.md#when-their-build-system-is-broken) or
-modify it in some other way to accept the packaged dependency. If you are
+system](../xbps-src-tutorial/packaging-j4-dmenu-desktop.md#when-their-build-system-is-broken)
+or modify it in some other way to accept the packaged dependency. If you are
 knowledgable of git submodules and upstream's build system, you could propose a
 more packaging friendly way to handle dependencies [to
-upstream](troubleshooting.md#notifying-upstream).
+upstream](../troubleshooting.md#notifying-upstream).
 
 But if the project is using a old version of the submodule or a customized one,
 this likely won't be possible. The submodule also might not be packaged.
 
 Header only libraries also [don't really meet the quality
-requirements](packaging-j4-dmenu-desktop.md#quality-requirements) (but it
+requirements](../xbps-src-tutorial/packaging-j4-dmenu-desktop.md#quality-requirements) (but it
 depends), so packaging them as a dependency might not be reasonable. Leaving the
 header only dependency as a git submodule is preferable in this scenario.
 
@@ -52,11 +52,11 @@ second method is [using plain `git`](#using-git).
 ### Using GitHub UI
 Go to the release the package is using (here it's the latest release `v0.3.3`):
 
-![main page](images/git_submodules/main_page.png)
+![main page](../images/git_submodules/main_page.png)
 
 Click on the associated tag:
 
-![release tag](images/git_submodules/release_tag.png)
+![release tag](../images/git_submodules/release_tag.png)
 
 This will take you back to the repository in the state it was when the release
 was made.
@@ -73,14 +73,14 @@ located. `gazou`'s `.gitmodules` looks like this:
 
 You should return to the root of the repository. You must click on the correct link:
 
-![return](images/git_submodules/return.png)
+![return](../images/git_submodules/return.png)
 
 If you click on the link crossed out on the picture, you will return to master
 and you will no longer be browsing the repo at the specified commit.
 
 You should go to the directories where the submodules should be:
 
-![submodule commit](images/git_submodules/submodule_commit.png)
+![submodule commit](../images/git_submodules/submodule_commit.png)
 
 You should also make sure that you are still checked out to the release. The
 green box shouldn't contain `master` nor `main`. It should be a tag.
@@ -99,24 +99,24 @@ This hash is usable, but you should make sure that the commit isn't tied to a
 tag. Tags should be preferred over commit hashes because they are nicer and
 shorted. To do that, click on the top commit:
 
-![tag commit](images/git_submodules/tag_commit.png)
+![tag commit](../images/git_submodules/tag_commit.png)
 
 You should see whether there is a tag listed:
 
-![tagged pin](images/git_submodules/tagged_pin.png)
+![tagged pin](../images/git_submodules/tagged_pin.png)
 
 If it isn't (it is on the picture), return to the root of the repo while
 preserving the checkout like before and proceed with [getting the
 archive](#getting-the-archive).
 
 Click on the tag. If you get brought to a release page, click on the tag again:
 
-![next tag](images/git_submodules/next_tag.png)
+![next tag](../images/git_submodules/next_tag.png)
 
 #### Getting the archive
 Click on "Code" and copy the link for downloading ZIP:
 
-![get link](images/git_submodules/get_link.png)
+![get link](../images/git_submodules/get_link.png)
 
 This is the link to download the submodule. Note that `void-packages` prefers
 `.tar.gz` archives instead of `.zip` archives. GitHub has no button for that,
@@ -298,4 +298,4 @@ to change the name of the downloaded archive. They are then put into
            `build_wrksrc` can be used to tell `xbps-src` which of the extracted
            directories should be treated as the primary one. [CWD is set to
            `build_wrksrc` in some build
-           steps.](packaging-j4-dmenu-desktop.md#cwd)
+           steps.](../xbps-src-tutorial/packaging-j4-dmenu-desktop.md#cwd)

src/package-update-tutorial.md

@@ -299,7 +299,7 @@ the project has one.
 It might be necessary to modify the template to fix the build. There is no
 universal way to fix these problems, but general understanding of `xbps-src` is
 helpful in these situations. I recommend you reading the [xbps-src packaging
-tutorial](xbps-src-packaging-tutorial.md).
+tutorial](xbps-src-tutorial/index.md).
 
 ## `xlint`
 You should always run `xlint` when finishing a package. It can find common
@@ -318,10 +318,10 @@ haven't caused the warnings), it is tolerable to leave the warning be. You
 should make a comment about it in the pull request description.
 
 ## Making a pull request
-Contributing is described at [Contributing](contributing.md). You should already
+Contributing is described at [Contributing](xbps-src-tutorial/contributing.md). You should already
 have a working clone of your fork, the `upstream` remote should be set up and
 you should be on a non-default branch. You can skip these parts in
-[Contributing](contributing.md).
+[Contributing](xbps-src-tutorial/contributing.md).
 
 [You should ensure that the branch is up to date.](troubleshooting.md#being-up-to-date)
 
@@ -380,4 +380,4 @@ It will output a link that will open the pull request.
           [different ways of cloning](tips_and_tricks.md#different-ways-of-cloning).
 [^remotes]: This is briefly described in the [remotes section of contributing
             (of this tutorial, not void-packages'
-            CONTRIBUTING)](contributing.md#remotes)
+            CONTRIBUTING)](xbps-src-tutorial/contributing.md#remotes)

src/tips_and_tricks.md

@@ -116,7 +116,7 @@ The following architectures are checked:
 
 I assume you are on `x86_64` (I make this assumption in the entire tutorial as
 I've mentioned in
-[j4-dmenu-desktop](packaging-j4-dmenu-desktop.md#void-packages-structure)). The
+[j4-dmenu-desktop](xbps-src-tutorial/packaging-j4-dmenu-desktop.md#void-packages-structure)). The
 following instructions can be easily changed to fit other architectures as well.
 For example if you are on `musl`, you won't have to create a special builddir
 for `x86_64-musl` because that is your default builddir.
@@ -435,7 +435,7 @@ _If you're on `x86_64`, this method is recommended only for `i686` and `x86_64-m
 
 ### Running compiled programs inside `masterdir` (QEMU build helper) { #qemu }
 As I've mentioned in [Packaging
-j4-dmenu-desktop](packaging-j4-dmenu-desktop.md#what-is-cross-compilation), you
+j4-dmenu-desktop](xbps-src-tutorial/packaging-j4-dmenu-desktop.md#what-is-cross-compilation), you
 can't run compiled executables when building a template under normal conditions.
 
 _This applies only for **cross compilation**, not for [native compilation for
@@ -472,7 +472,7 @@ hungry.
 If upstream's build system wants to execute things (and it isn't `cmake` nor
 `meson`[^badqemu]), you will have to convince it to use QEMU. You'll probably
 have to [make patches to the build
-system](packaging-j4-dmenu-desktop.md#when-their-build-system-is-broken). This
+system](xbps-src-tutorial/packaging-j4-dmenu-desktop.md#when-their-build-system-is-broken). This
 can be difficult
 sometimes. You should consider [notifying upstream about
 it](troubleshooting.md#notifying-upstream).

src/troubleshooting.md

@@ -180,7 +180,7 @@ way of communication could be a mailing list, there might simply not be any way
 to contact the maintainers and more.
 
 ## Failing checks
-See [contributing](contributing.md#solving-check-errors).
+See [contributing](xbps-src-tutorial/contributing.md#solving-check-errors).
 
 ## Other problems
 ### Builds use only a single thread

src/xbps-src-tutorial/contributing.md

@@ -70,30 +70,30 @@ account](https://docs.github.com/en/account-and-profile/setting-up-and-managing-
 
 This is what a good commit looks like:
 
-![good commit](images/contributing/good_commit.png)
+![good commit](../images/contributing/good_commit.png)
 
 When you'll hover over it, you'll see a popup:
 
-![good commit popup](images/contributing/good_commit_popup.png)
+![good commit popup](../images/contributing/good_commit_popup.png)
 
 This is how a bad commit looks like:
 
-![bad commit](images/contributing/bad_commit.png)
+![bad commit](../images/contributing/bad_commit.png)
 
 When you hover over it, nothing happens.
 
 Here are some funny examples of bad commits:
 
-![funny commit](images/contributing/meator_with_meator.png)
+![funny commit](../images/contributing/meator_with_meator.png)
 
-![funny commit closeup](images/contributing/meator_with_meator_detailed.png)
+![funny commit closeup](../images/contributing/meator_with_meator_detailed.png)
 
 Here I have collaborated with myself apparently. This can happen when your
 author string doesn't match your `user.name` and `user.email`.
 
 ## Things to check
 [You should ensure that the repo is up to
-date.](troubleshooting.md#being-up-to-date)
+date.](../troubleshooting.md#being-up-to-date)
 
 You should also make sure that no `xlint` errors are in the templates you want
 to contribute.
@@ -118,7 +118,7 @@ git checkout upstream/master -b <a-descriptive-name>
 ```
 
 to really make sure the branch is [up to
-date](troubleshooting.md#being-up-to-date).[^uptodate]
+date](../troubleshooting.md#being-up-to-date).[^uptodate]
 
 ## Making the commits
 The most important requirement (apart from quality requirements) are commit
@@ -207,10 +207,10 @@ using different architectures and libcs.
 
 Here is an example of a failed check:
 
-![failed check](images/contributing/failed_check.png)
+![failed check](../images/contributing/failed_check.png)
 
 You can click on Details to see what `xbps-src` outputted. [It is also useful to
-reproduce the error locally.](tips_and_tricks.md#reproduce-checks-locally)
+reproduce the error locally.](../tips_and_tricks.md#reproduce-checks-locally)
 
 You should try to fix these errors. Cross compilation is the source of most
 problems when contributing new packages. This is briefly described in [Packaging
@@ -422,12 +422,12 @@ You can then follow the link provided by git to create the pull request.
 
 ## That's all folks!
 This is the end of xbps-src packaging tutorial. Thank you for taking the time to
-read this tutorial! Feel free to share your [feedback](feedback.md) if you'd
+read this tutorial! Feel free to share your [feedback](../feedback.md) if you'd
 like to.
 
 If you want to continue reading, you can look at
-[troubleshooting](troubleshooting.md) and [tips and tricks](tips_and_tricks.md)
-for more useful info about `xbps-src`.
+[troubleshooting](../troubleshooting.md) and [tips and
+tricks](../tips_and_tricks.md) for more useful info about `xbps-src`.
 
 ---
 

src/xbps-src-tutorial/packaging-bat.md

@@ -20,7 +20,7 @@ of it is in their repository: <https://github.com/sharkdp/bat>
 - `short_desc`: `Cat(1) clone with syntax highlighting and Git integration`
 - `license`: `bat` has two licenses, `Apache-2.0` and `MIT`:
 
-   ![license](images/bat/license.png)
+   ![license](../images/bat/license.png)
 
    Multiple licenses should be separated by ", " like this:
    ```
@@ -42,7 +42,7 @@ of it is in their repository: <https://github.com/sharkdp/bat>
 
 - `distfiles`: `bat`'s release has a lot of files in it:
 
-   ![bat release](images/bat/release.png)
+   ![bat release](../images/bat/release.png)
 
    Prebuilt archives can not be used in
    [`void-packages`](https://github.com/void-linux/void-packages). So you must
@@ -290,7 +290,7 @@ post_install() {
 }
 ```
 
-[This is an useful trick by the way.](tips_and_tricks.md#setting-environmental-variables)
+[This is an useful trick by the way.](../tips_and_tricks.md#setting-environmental-variables)
 
 `BAT_ASSETS_GEN_DIR` uses `XBPS_BUILDDIR`, `pkgname` and `version` variables.
 `pkgname` and `version` are defined in the template and `XBPS_BUILDDIR` is an