Fix broken links

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

content/architecture/application/apis-and-services.md

@@ -129,7 +129,7 @@ system to provide the basic UI even if there are no user focused applications:
 
 - [eglibc](http://www.gnu.org/software/libc/manual/html_node/index.html): Basic OS interfaces
 - [GLib](https://developer.gnome.org/glib/stable/): Basic programming framework
-- [OSTree](http://ostree.readthedocs.io/): Atomic software updates
+- [OSTree](https://ostreedev.github.io/ostree/): Atomic software updates
 - [systemd](https://www.freedesktop.org/wiki/Software/systemd/): Service
   management service, used as both a system service and a user service. The
   system instance is process 1 (the first process launched by the kernel after

content/architecture/application/wayland_compositors.md

@@ -298,10 +298,10 @@ GLES, to form the final output frame.
 
   ![](/images/wayland_compositor_6.svg)
 
-[Wayland]: https://wayland.freedesktop.org/wayland
+[Wayland]: https://wayland.freedesktop.org
 [Wayland Protocols]: https://gitlab.freedesktop.org/wayland/wayland-protocols
-[Weston]: https://github.com/wayland-project/weston
-[libweston]: https://github.com/wayland-project/weston/tree/master/libweston
+[Weston]: https://gitlab.freedesktop.org/wayland/weston
+[libweston]: https://wayland.pages.freedesktop.org/weston/toc/libweston.html
 [XDG-shell]: https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/xdg-shell/xdg-shell.xml
 [Mutter]: https://gitlab.gnome.org/GNOME/mutter
 [Clutter]: https://wiki.gnome.org/Projects/Clutter

content/architecture/distribution/workflow-guide.md

@@ -162,7 +162,7 @@ platforms.
 
 A GitLab CI/CD pipeline periodically schedules a batch of tests against the
 latest images on the
-[LAVA instance hosted by Collabora](https://lava.collabora.co.uk). LAVA takes
+[LAVA instance hosted by Collabora](https://lava.collabora.dev). LAVA takes
 care of deploying the freshly generated images on actual target devices running
 in the Collabora device farm, and of controlling them over serial connections
 to run the defined test cases and gather the results. These results are
@@ -181,9 +181,9 @@ published on the
   to provide quick feedback to the developer
 - A GitLab CI/CD pipeline is used to push new releases on release branches
   to OBS.
-- [OBS](https://build.collabora.co.uk) builds source packages and generates
+- [OBS](https://build.collabora.com) builds source packages and generates
   binary packages in controlled environments.
 - Every night GitLab CI/CD pipelines generate images from the binary packages,
   built and added to repositories by OBS.
 - On success, the pipeline triggers on-device tests using
-  [LAVA](https://lava.collabora.co.uk) to check the produced images
+  [LAVA](https://lava.collabora.dev) to check the produced images

content/concepts/application_customization/preferences-and-persistence.md

@@ -1807,7 +1807,7 @@ As discussed in the above sections, we recommend:
 
 [iOS-keychain]: https://developer.apple.com/library/ios/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html#//appl_ref/doc/uid/TP30000897-CH203-TP1
 
-[GENIVI-peristence]: http://docs.projects.genivi.org/persistence-client-library/1.0/Persistence_ArchitectureManual.pdf
+[GENIVI-persistence]: http://docs.projects.genivi.org/persistence-client-library/1.0/Persistence_ArchitectureManual.pdf
 
 [GENIVI-relational-API]: http://docs.projects.genivi.org/persistence-client-library/1.0/Persistence_ClientLibrary_UserGuide.pdf
 

content/concepts/platform/audio-management.md

@@ -20,7 +20,7 @@ natively supports containerized applications and keeps policy management
 separate from the core routing system, making it much easier to tailor for
 specific products.
 
-Applications can use PipeWire through [its native API](https://pipewire.github.io/pipewire/),
+Applications can use PipeWire through [its native API](https://docs.pipewire.org/page_api.html),
 as the final layer to access sound features. This does not mean that applications have to deal directly with PipeWire:
 applications can still make use of their preferred sound APIs as intermediate
 layers for manipulating audio streams, with support being available for the
@@ -402,7 +402,7 @@ it, which suites the needs for Apertis better since it also targets special
 use-cases that don't really match the desktop ones, and this separation
 brings more flexibility.
 
-[WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) is a service
+[WirePlumber](https://pipewire.pages.freedesktop.org/wireplumber/) is a service
 that provides the policy logic for PipeWire. It's where the policies like
 the one above is implemented, but unlike PulseAudio is explicitly designed to
 let people define them using LUA scripts and they are also what AGL has used to
@@ -614,7 +614,7 @@ Since the CE domain do not know what is happening in the automotive domain.
 
 All the policies in WirePlumber are completely scriptable and written in Lua.
 The Lua API Documentation can be found
-[here](https://pipewire.pages.freedesktop.org/wireplumber/lua_api.html).
+[here](https://pipewire.pages.freedesktop.org/wireplumber/scripting/lua_api.html).
 
 The default roles, priorities and related actions are defined in
 `/usr/share/wireplumber/policy.lua.d/50-endpoints-config.lua` and can be re-written
@@ -854,5 +854,5 @@ This design fulfill the following requirements:
 [inter domain communication]:  {{< ref "inter-domain-communication.md" >}} 
 [Application bundle metadata]:  {{< ref "application-bundle-metadata.md" >}} 
 [Multimedia]:  {{< ref "multimedia.md" >}} 
-[GENIVI audio manager]: http://docs.projects.genivi.org/AudioManager/
+[GENIVI AudioManager]: https://genivi.github.io/AudioManager/
 [mute hard-key]: {{< ref "hardkeys.md" >}}

content/concepts/platform/system-updates-and-rollback.md

@@ -1192,7 +1192,7 @@ A survey of system update managers:
 
 The OSTree bootable file systems tree store:
 
-  - [*http://ostree.readthedocs.io*](http://ostree.readthedocs.io)
+  - [*https://ostreedev.github.io/ostree/*](https://ostreedev.github.io/ostree/)
 
 The U-Boot Bootloader:
 
@@ -1201,7 +1201,7 @@ The U-Boot Bootloader:
 The ChromeOS auto-update system:
   - [*https://www.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate*](https://www.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate)
 
-[OSTree]: http://ostree.readthedocs.io
+[OSTree]: https://ostreedev.github.io/ostree/
 
 [OSTree atomic upgrades]: https://ostree.readthedocs.io/en/stable/manual/atomic-upgrades
 

content/guides/testing/lava-apertis-testing.md

@@ -373,10 +373,10 @@ for our changes:
 
        user: '<REPLACE_THIS_WITH_YOUR_LAVA_USERNAME>'
        auth-token: '<REPLACE_THIS_WITH_YOUR_AUTH_TOKEN>'
-       server: 'https://lava.collabora.co.uk/'
+       server: 'https://lava.collabora.dev/'
 
    where `user` is your login name for LAVA and `auth-token` must be obtained
-   from LAVA API: https://lava.collabora.co.uk/api/tokens/
+   from LAVA API: https://lava.collabora.dev/api/tokens/
 
    To test the setup just run command below, if the configuration is correct you
    should see your LAVA login name:
@@ -400,7 +400,7 @@ for our changes:
        Submitted job job-apertis_ostree_v2023dev1-fixedfunction-armhf-uboot_v2023dev1.0rc2-systemctl.yaml with id 3463731
 
    It is possible to check the job status by URL with the ID returned by the above command:
-   https://lava.collabora.co.uk/scheduler/job/3463731
+   https://lava.collabora.dev/scheduler/job/3463731
 
    {{% notice note %}}
    The `lava-submit.py` tool is currently only a wrapper around the `lqa` tool.

content/guides/testing/lava-external-devices.md

@@ -402,12 +402,12 @@ Once tests results are available at LAVA , and the test cases are enabled for th
 specific images from the test case repository, the results will be available from
 the QA Report App automatically.
 
-[MultiNode Protocol]: https://lava.collabora.co.uk/static/docs/v2/actions-protocols.html#multinode-protocol
+[MultiNode Protocol]: https://lava.collabora.dev/static/docs/v2/actions-protocols.html#multinode-protocol
 
-[MultiNodeAPI]: https://lava.collabora.co.uk/static/docs/v2/multinodeapi.html#multinode-api
+[MultiNodeAPI]: https://lava.collabora.dev/static/docs/v2/multinodeapi.html#multinode-api
 
-[LXC Protocol]: https://lava.collabora.co.uk/static/docs/v2/actions-protocols.html#lxc-protocol-reference
+[LXC Protocol]: https://lava.collabora.dev/static/docs/v2/actions-protocols.html#lxc-protocol-reference
 
-[Secondary Connections]: https://lava.collabora.co.uk/static/docs/v2/pipeline-writer-secondary.html
+[Secondary Connections]: https://lava.collabora.dev/static/docs/v2/pipeline-writer-secondary.html
 
-[AddingTestsActions]: https://lava.collabora.co.uk/static/docs/v2/writing-multinode.html#adding-test-actions
+[AddingTestsActions]: https://lava.collabora.dev/static/docs/v2/writing-multinode.html#adding-test-actions

content/policies/contributions.md

@@ -483,11 +483,11 @@ All commits must have a [`Signed-off-by` line]( {{< ref "#sign-offs" >}} )
 assigning responsibility for their open source licensing.
 
 Some admin steps on the periphery of packaging and releasing new versions of
-Apertis modules as Debian packages may require access to build.collabora.co.uk
+Apertis modules as Debian packages may require access to build.collabora.com
 (OBS). These are issued separately from commit rights, and are generally not
 needed for the main development workflows.
 
-Submitting automated test runs on lava.collabora.co.uk requires CI rights,
+Submitting automated test runs on lava.collabora.dev requires CI rights,
 which are granted similarly to packaging rights. However, CI results may be
 viewed read-only by anyone.
 
@@ -495,7 +495,7 @@ viewed read-only by anyone.
 ## Getting commit rights
 
 Commit rights (to allow direct pushes to git, and potentially access to the
-package building system, build.collabora.co.uk) may be granted to trusted third
+package building system, build.collabora.com) may be granted to trusted third
 party contributors if they regularly contribute to Apertis, with high quality
 contributions at the discretion of current Apertis maintainers.
 

content/policies/copyrights.md

@@ -78,10 +78,10 @@ license on their behalf.
     must include a licensing notice stating that the work is released
     under CC BY-SA and either a) a hyperlink or URL to the text of the
     license or b) a copy of the license. For this purpose, a suitable
-    URL is: <http://creativecommons.org/licenses/by-sa/4.0/>
+    URL is: <https://creativecommons.org/licenses/by-sa/4.0/>
 
 **For further information**, please refer to the [legal code of the CC
-BY-SA License](http://creativecommons.org/licenses/by-sa/4.0/legalcode).
+BY-SA License](https://creativecommons.org/licenses/by-sa/4.0/legalcode).
 
 ## Notes
 

content/policies/package_maintenance.md

@@ -12,7 +12,7 @@ aliases = [
 Apertis hosts its own package subset on the
 [Apertis GitLab instance](https://gitlab.apertis.org/). On successful
 completion of the CI pipeline these are uploaded to
-[Collabora's Open Build Service (OBS) instance](https://build.collabora.co.uk)
+[Collabora's Open Build Service (OBS) instance](https://build.collabora.com)
 where the packages are formally built and hosted for Apertis.
 
 ## Packages Guidelines

content/qa/_index.md

@@ -28,9 +28,9 @@ Reports of the testing performed are available on the
 
 # Services
 
-- [LAVA (Linaro Automated Validation Architecture)](https://lava.collabora.co.uk)
+- [LAVA (Linaro Automated Validation Architecture)](https://lava.collabora.dev/)
 
-  - [LAVA Documentation](https://lava.collabora.co.uk/static/docs/v2/index.html)
+  - [LAVA Documentation](https://lava.collabora.dev/static/docs/v2/index.html)
 
 # Tools
 

content/qa/lqa.md

@@ -51,12 +51,12 @@ The configuration file has three main fields: `user`, `auth-token` and
 
 These names are very self-explanatory, `user` is your LAVA user name,
 `auth-token` is the LAVA API token (generated from the web UI at
-<https://lava.collabora.co.uk/api/tokens/>), and `server` is the LAVA
+<https://lava.collabora.dev/api/tokens/>), and `server` is the LAVA
 server URL address:
 
     user: '<REPLACE_THIS_WITH_YOUR_LAVA_USERNAME>'
     auth-token: '<REPLACE_THIS_WITH_YOUR_API_TOKEN>'
-    server: 'https://lava.collabora.co.uk/'
+    server: 'https://lava.collabora.dev/'
 
 Save this file as `~/.config/lqa.yaml` and now test your configuration:
 

content/reference_hardware/arm64.md

@@ -29,7 +29,7 @@ Alternative ARM64 reference devices are the following:
 | [Renesas R-Car H3 Starter Kit Premier (H3SK/h3ulcb)](http://elinux.org/R-Car/Boards/H3SK)       | [Setup guide]( {{< ref "/reference_hardware/rcar-gen3_setup.md" >}} ) Tested on H3e-2G(WS3.0) silicon mounted board (`RTP8J779M1ASKB0SK0SA003`)   |
 | [Renesas R-Car H3 Salvator-X (r8a7795-salvator-x)](http://elinux.org/R-Car/Boards/Salvator-X)   | [Setup guide]( {{< ref "/reference_hardware/rcar-gen3_setup.md" >}} )              |
 | [Renesas R-Car M3-W Salvator-X (r8a7796-salvator-x)](http://elinux.org/R-Car/Boards/Salvator-X) | [Setup guide]( {{< ref "/reference_hardware/rcar-gen3_setup.md" >}} ) **Untested** |
-| [Raspberry Pi 4 model B](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/)          | [Setup guide]( {{< ref "/reference_hardware/rpi4_setup.md" >}} )           |
+| [Raspberry Pi 4 model B](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/)          | [Setup guide]( {{< ref "/reference_hardware/rpi4_setup.md" >}} )           |
 | [Raspberry Pi CM4 CANOPi](https://github.com/boschresearch/kuksa.hardware/)                     | [Setup guide]( {{< ref "/reference_hardware/rpi_cm4_canopi_setup.md" >}} ) |
 | [i.MX8MN Variscite Symphony board](https://www.variscite.com/product/evaluation-kits/var-som-mx8m-nano-evaluation-kits/) | [Setup guide]( {{< ref "/reference_hardware/imx8mn_var_symphony_setup.md" >}} ) |
 | i.MX8MN BSH SMM S2 PRO board                                                                    | [Setup guide]( {{< ref "/reference_hardware/imx8mn_bsh_smm_s2pro_setup.md" >}} ) |

content/reference_hardware/rpi4_setup.md

@@ -63,7 +63,7 @@ It is highly recommended to upgrade the bootrom to the latest available
 stable version!
 
 The easiest method for updating and managing the boot sequence for local usage and
-development is the [RPI Imager](https://www.raspberrypi.org/downloads) which will
+development is the [RPI Imager](https://www.raspberrypi.com/software/) which will
 prepare the bootable SD-card with fresh updates for you:
 
 ![Misc utility images](/images/rpi-imager-1-misc.png)
@@ -92,7 +92,7 @@ If you have a display attached to device, it will have a green color in case of
 
 {{% notice info %}}
 Apertis is available through the
-[RPI Imager](https://www.raspberrypi.org/downloads) (`Choose OS` -> `Other
+[RPI Imager](https://www.raspberrypi.com/software/) (`Choose OS` -> `Other
 general-purpose OS` -> `Apertis`)
 
 ![Apertis in RPi Imager](/images/rpi-imager-3-apertis.png)

content/reference_hardware/rpi4_setup_lava.md

@@ -24,7 +24,7 @@ See the GPIO header pinout at [pinout.xyz](https://pinout.xyz/).
 
 The Raspberry Pi 4 OTP first stage bootloader is using a second stage located in the EEPROM chip.
 
-Depending on the [boot mode](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow_2711.md)
+Depending on the [boot mode](https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#eeprom-boot-flow)
 flashed into SPI EEPROM the second stage bootloader is able to boot the DUT
 from SD-card, USB mass storage device or network.
 
@@ -36,7 +36,7 @@ Low level tuning of bootrom is possible with the tools from `rpi-eeprom` package
 A distribution which ships the `rpi-eeprom` package is needed, for instance NOOBS, Raspbian or Ubuntu.
 Boot the RPi4 device with a selected distro and proceed in terminal.
 
-Check the list of [available stable bootroms](https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware/stable)
+Check the list of [available stable bootroms](https://github.com/raspberrypi/rpi-eeprom)
 and export variable with the last available version, for example:
 ```
 PI_EEPROM_VERSION=2021-04-29
@@ -53,7 +53,7 @@ rpi-eeprom-config pieeprom-${PI_EEPROM_VERSION}.bin > bootconf.txt
 ```
 
 Change the bootrom configration file `bootconf.txt` with any editor according
-[documentation](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md).
+[documentation](https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#update-the-bootloader-configuration).
 
 The configuration below is forcing the board to use network boot only and use `bcm2711-rpi-4-b`
 directory on server side to search boot files:
@@ -98,7 +98,7 @@ from package [raspi-firmware](https://gitlab.apertis.org/pkg/raspi-firmware)).
 In addition, the DTB file `bcm2711-rpi-4-b.dtb` from the kernel
 used in Apertis and the `config.txt` boot configuration needs to
 be copied under the same `bcm2711-rpi-4-b/` directory.
-The description of variables for `config.txt` is [available online](https://www.raspberrypi.org/documentation/configuration/config-txt/README.md).
+The description of variables for `config.txt` is [available online](https://www.raspberrypi.com/documentation/computers/config_txt.html).
 For Apertis we use singe bootable U-Boot image for RPi3 and RPi4, 64b OS and
 upstream kernel, hence a minimal `config.txt` file should look like this: