website: updates

website/docs/about/_common/_history-xbb-v5.mdx

@@ -5,9 +5,9 @@
 
 The project received a significant update by transitioning the build
 scripts from the cumbersome monolithic XBB Docker images to the more
-flexible and modular xPacks. XBB version
+flexible and modular **xpm** packages. XBB version
 [5.0.0](https://xpack.github.io/blog/2023/02/07/xbb-v5.0.0-released/)
 marked a major milestone for the xPack project, as it was the first
 self-sustained release. This version enabled the creation of new
-binary xPacks using existing binary xPacks, eliminating the need for
+binary packages using existing binary packages, eliminating the need for
 custom Docker images or other compiled tools.

website/docs/developer/_common/_platform-docker-section.mdx

@@ -45,7 +45,7 @@ or, for more verbosity, run the similar development build:
 
 {developmentDurations[ props.platform ]}, the output of the build script is a compressed
 archive and its SHA signature, created in
-the <code>buils-assets/build/{props.platform}/deploy</code> folder:
+the <code>build-assets/build/{props.platform}/deploy</code> folder:
 
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.tar.gz</code>
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.tar.gz.sha</code>

website/docs/developer/_common/_platform-native-section.mdx

@@ -42,7 +42,7 @@ or, for more verbosity, run the similar development build:
 
 {developmentDurations[ props.platform ]}, the output of the build script is a compressed
 archive and its SHA signature, created in
-the <code>buils-assets/build/{props.platform}/deploy</code> folder:
+the <code>build-assets/build/{props.platform}/deploy</code> folder:
 
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.tar.gz</code>
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.tar.gz.sha</code>

website/docs/developer/index.mdx

@@ -43,7 +43,7 @@ project and provides documentation on how to build and test the package.
 The build scripts in this project use the **xPack Build Box** (**XBB**)
 tools, which require the usual native development tools
 (packed as a Docker image for GNU/Linux builds), complemented with
-several binary xPacks, installed with `xpm` as development dependencies.
+several binary packages, installed with `xpm` as development dependencies.
 
 For those interested in understanding how things work, a good starting point
 would be to read the [XBB](https://xpack.github.io/xbb/) page.
@@ -144,17 +144,17 @@ xpm run build --config darwin-x64
 </details>
 
 <details>
-<summary>xPack actions</summary>
+<summary>xpm/xPack actions</summary>
 
-The xPack actions are extensions of npm scripts, i.e. named sequences
+The xpm actions are extensions of npm scripts, i.e. named sequences
 of commands that are invoked via `xpm run <name>` to perform specific
 operations.
 together in a sub-shell .
 
 The commands are invoked in a sub-shell with an adjusted PATH,
 having the `xpacks/.bin`
 folder prepended. This ensures the locally installed tools are
-prefered to the system tools.
+preferred to the system tools.
 
 Actions can be defined for the entire project or for a specific build
 configuration.
@@ -177,10 +177,10 @@ commands.
 <details>
 <summary>Visual Studio Code integration</summary>
 
-xPack actions and build configurations are supported in Visual Studio via the
+xpm/xPack actions and build configurations are supported in Visual Studio via the
 [xPack C/C++ Managed Build Tools](https://marketplace.visualstudio.com/items?itemName=ilg-vscode.xpack) extension.
 
-With this extension installed, xPack actions can be very conveniently
+With this extension installed, xpm/xPack actions can be very conveniently
 invoked via a single mouse click, for example:
 
 ![xPack actions](https://github.com/xpack/vscode-xpack-extension-ts/raw/master/assets/docs-images/xpack-actions.png)
@@ -328,7 +328,7 @@ In some cases it is necessary to run a debug session with the binaries.
 
 For these cases, the build script accepts the `--debug` options.
 
-There are also xPack actions that use this option (`build-development-debug`
+There are also xpm actions that use this option (`build-development-debug`
 and `docker-build-development-debug`).
 
 ### Use a local cache

website/docs/getting-started/index.mdx

@@ -97,18 +97,18 @@ are extracted into separate folders within the project.
 
 Based on the content, there are two types of packages:
 
-- **source xPacks** (that install source files, usually libraries) and
-- **binary xPacks** (that install executables/binary files, usually tools).
+- **source packages** (that install source files, usually libraries) and
+- **binary packages** (that install executables/binary files, usually tools).
 
-The binary xPacks include references to archives with the platform specific
+Binary packages include references to archives with the platform specific
 binaries (such as `.tar.gz` for Unix or `.zip` for Windows).
 
 These archives are also expanded along the package metadata. Since they
 include executables, links/forwarders to
 these executables are created in a `.bin` folder,
 eliminating the need to add multiple folders to the `PATH`.
 
-Given that some binary xPacks, such as toolchains, can have very large
+Given that some binary packages, such as toolchains, can have very large
 archives, the packages are extracted only once into a user global location to
 conserve space. In projects, instead of duplicating the content of these
 archives, symbolic links are created.
@@ -139,7 +139,7 @@ feasible.
 </details>
 
 Similarly to [flatpacks](https://flatpak.org) or [snap](https://snapcraft.io),
-but significantly simpler, xPacks include all dependent shared libraries
+but significantly simpler, xpm packages include all dependent shared libraries
 within the distributed archives, making the binaries independent of
 any similar libraries installed on the system. This ensures they
 can run on any system without needing specific libraries to be

website/docs/install/index.mdx

@@ -156,8 +156,8 @@ Similarly, **xpm** adds links/forwarders into
 a separate `<project>/xpacks/.bin` folder.
 
 With this setup, the project needs to prepend only this `.bin` folder
-to the `PATH`, and all the required tools are accesible
-and prefered to possible system tools.
+to the `PATH`, and all the required tools are accessible
+and preferred to possible system tools.
 
 </details>
 

website/docs/maintainer/_common/_platform-docker-build.mdx

@@ -39,7 +39,7 @@ xpm run docker-build-development --config ${props.platform} -C ~/Work/xpack-dev-
 
 {developmentDurations[ props.platform ]}, the output of the build script is a compressed
 archive and its SHA signature, created in
-the <code>buils-assets/build/{props.platform}/deploy</code> folder:
+the <code>build-assets/build/{props.platform}/deploy</code> folder:
 
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.{props.platform === 'win32-x64' ? 'zip' : 'tar.gz'}</code>
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.{props.platform === 'win32-x64' ? 'zip' : 'tar.gz'}.sha</code>

website/docs/maintainer/_common/_platform-native-build.mdx

@@ -38,7 +38,7 @@ xpm run build-development --config ${props.platform} -C ~/Work/xpack-dev-tools/g
 
 {developmentDurations[ props.platform ]}, the output of the build script is a compressed
 archive and its SHA signature, created in
-the <code>buils-assets/build/{props.platform}/deploy</code> folder:
+the <code>build-assets/build/{props.platform}/deploy</code> folder:
 
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.tar.gz</code>
 * <code>xpack-gcc-{customField('xpackVersion')}-{props.platform}.tar.gz.sha</code>

website/docs/maintainer/index.mdx

@@ -272,7 +272,7 @@ Before the real build, run test/development builds on all platforms.
 
 ### Visual Studio Code extension
 
-All actions are defined as **xPack actions** and can be conveniently
+All actions are defined as **xpm/xPack actions** and can be conveniently
 triggered via the VS Code graphical interface, using the
 [xPack C/C++ Managed Build Tools extension](https://marketplace.visualstudio.com/items?itemName=ilg-vscode.xpack).
 
@@ -443,7 +443,7 @@ In some cases it is necessary to run a debug session with the binaries.
 
 For these cases, the build script accepts the `--debug` options.
 
-There are also xPack actions that use this option (`build-development-debug`
+There are also xpm actions that use this option (`build-development-debug`
 and `docker-build-development-debug`).
 
 ### Files cache
@@ -589,7 +589,7 @@ xpm run generate-workflows -C ~/Work/xpack-dev-tools/gcc-xpack.git/build-assets
 
 ### Manually trigger the build GitHub Actions
 
-To trigger the GitHub Actions builds, use the xPack actions:
+To trigger the GitHub Actions builds, use the xpm actions:
 
 - **trigger-workflow-build-darwin-x64**
 - **trigger-workflow-build-darwin-arm64**
@@ -608,7 +608,7 @@ xpm run trigger-workflow-build-linux-arm64 -C ~/Work/xpack-dev-tools/gcc-xpack.g
 xpm run trigger-workflow-build-linux-arm -C ~/Work/xpack-dev-tools/gcc-xpack.git/build-assets
 ```
 
-The scripts behind these actions require the `GITHUB_API_DISPATCH_TOKEN`
+The scripts behind these actions require the `XPACK_DEV_TOOLS_FG_DISPATCH_TOKEN`
 variable to be present
 in the environment, and the organization `PUBLISH_TOKEN` to be visible in the
 Settings → Action →
@@ -636,7 +636,7 @@ The resulting binaries are available for testing from
 
 The automation is provided by GitHub Actions.
 
-To trigger the GitHub Actions tests, run the xPack actions:
+To trigger the GitHub Actions tests, run the xpm actions:
 
 <ul>
 <li><b>trigger-workflow-test-prime</b></li>
@@ -650,7 +650,7 @@ xpm run trigger-workflow-test-docker-linux-x64 -C ~/Work/xpack-dev-tools/gcc-xpa
 xpm run trigger-workflow-test-docker-linux-arm -C ~/Work/xpack-dev-tools/gcc-xpack.git/build-assets
 ```
 
-The scripts behind these accesible require the `GITHUB_API_DISPATCH_TOKEN` variable to be present
+The scripts behind these accessible require the `XPACK_DEV_TOOLS_FG_DISPATCH_TOKEN` variable to be present
 in the environment.
 
 These actions use the `xpack-development` branch of this repo and the

website/docs/user/_common/_arm-toolchain-versioning.mdx

@@ -18,7 +18,7 @@ import versionMinor from '@site/src/libs/versionMinor';
 The version string used by the
 upstream **Arm GNU Toolchain** project is a bit unusual and unstable in time,
 (like <code>{versionMajor()}.{versionMinor()}.Rel1</code>)
-therefore the upstream GCC version is prefered, which
+therefore the upstream GCC version is preferred, which
 is a three number string
 like <code>{customField('xpackVersion')}</code>;
 to this string the xPack distribution adds a fourth number that represents

website/docs/user/_common/_libraries-and-rpath.mdx

@@ -5,7 +5,7 @@
 
 ## Shared libraries
 
-On all platforms the binary xPack packages are **standalone**,
+On all platforms the binary xpm packages are **standalone**,
 and expect only the standard runtime to be present on the host.
 
 All dependencies that are built as shared libraries are copied locally