Fix some REF_NOT_FOUND with newer Hugo

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

content/architecture/application/data_sharing.md

@@ -22,12 +22,12 @@ one or more ***consumers*** receive information from one or more
 
 ## Use cases
 
-- [Points of interest]( {{< ref "/points_of_interest.md" >}} ) should use one
+- [Points of interest]( {{< ref "points_of_interest.md" >}} ) should use one
   of these patterns
-- [Sharing]( {{< ref "/sharing.md" >}} ) could use one of these patterns
+- [Sharing]( {{< ref "sharing.md" >}} ) could use one of these patterns
 - Global search (see [ConceptDesigns]( {{< ref "global-search.md" >}} ))
   currently carries out the equivalent of
-  [interface discovery]( {{< ref "/interface_discovery.md" >}} ) by
+  [interface discovery]( {{< ref "interface_discovery.md" >}} ) by
   reading the manifest directly, but other than that it is similar to
   [Query-based access via D-Bus](#query-based-access-via-d-bus)
 
@@ -62,7 +62,7 @@ consumers and among providers.
 ## Discovery
 
 Each initiator carries out [Interface
-discovery]( {{< ref "/interface_discovery.md" >}} ) to find implementations of
+discovery]( {{< ref "interface_discovery.md" >}} ) to find implementations of
 the responder. If the initiator is the consumer, the interface that is
 discovered might have a name like
 `com.example.PointsOfInterestProvider`. If the initiator is the
@@ -374,7 +374,7 @@ If the system is restarted and the previously running applications are
 restored, and the interface is one where resuming communication makes
 sense, we recommend that the original initiator re-initiates
 communication. This would normally be done by repeating [interface
-discovery]( {{< ref "/interface_discovery.md" >}} ).
+discovery]( {{< ref "interface_discovery.md" >}} ).
 
 In a few situations it might be preferable for the original initiator to
 store a list of the responders with which it was previously

content/concepts/archive/application/points_of_interest.md

@@ -212,7 +212,7 @@ policy.
 
 ## Recommendations
 
-See [Data sharing]( {{< ref "/data_sharing.md" >}} ) for background information
+See [Data sharing]( {{< ref "data_sharing.md" >}} ) for background information
 on various possible communication between apps. The *consumer* here is
 the navigation app, and the *providers* are the POI, TPEG and weather
 providers.
@@ -223,11 +223,11 @@ started automatically on boot, whereas the various providers will be
 agents provided by platform components and/or store applications,
 started either on boot or on-demand. Because the consumer might be a
 HMI, we recommend that it should act as the *initiator* as described in
-[Data sharing]( {{< ref "/data_sharing.md" >}} ).
+[Data sharing]( {{< ref "data_sharing.md" >}} ).
 
 We recommend that the navigation app should locate suitable POI, weather
 and/or TPEG providers by performing [interface
-discovery]( {{< ref "/interface_discovery.md" >}} ).
+discovery]( {{< ref "interface_discovery.md" >}} ).
 
 To bypass concerns about [Access to location
 information](#access-to-location-information) and ensure
@@ -259,7 +259,7 @@ new consumer connects.
 #### TPEG stream
 
 One option is to use [data sharing\#Consumer-initiated push via a
-stream]( {{< ref "/data_sharing.md#consumer-initiated-push-via-a-stream" >}} ).
+stream]( {{< ref "data_sharing.md#consumer-initiated-push-via-a-stream" >}} ).
 In this model, the method that is called by the provider would start a
 stream of TPEG messages, in either the binary or XML encoding, with a
 suitable framing protocol (which will need to be specified) if one is
@@ -283,7 +283,7 @@ message might be designed to exploit bugs in the consumer's parser.
 #### Stream of some other format
 
 Another option is to use [data sharing\#Consumer-initiated push via a
-stream]( {{< ref "/data_sharing.md#consumer-initiated-push-via-a-stream" >}} ),
+stream]( {{< ref "data_sharing.md#consumer-initiated-push-via-a-stream" >}} ),
 but require the messages carried by the stream to be in some other
 format instead of TPEG, for example
 [KML](https://en.wikipedia.org/wiki/Keyhole_Markup_Language). This would
@@ -327,7 +327,7 @@ implementation provided by the platform.
 #### Publish/subscribe via D-Bus
 
 TPEG providers could use a [publish/subscribe approach via
-D-Bus]( {{< ref "/data_sharing.md#publish.2fsubscribe-via-d-bus" >}} ), with
+D-Bus]( {{< ref "data_sharing.md#publish.2fsubscribe-via-d-bus" >}} ), with
 each D-Bus message either carrying a binary or XML TPEG message, or a
 message translated into a non-TPEG encoding using D-Bus data structures.
 However, our current understanding of the expected message rate is that
@@ -361,7 +361,7 @@ for a TPEG stream.
 
 If TPEG has an encoding for points of interest, then the same approach
 can be taken as for TPEG: [data sharing\#Consumer-initiated push via a
-stream]( {{< ref "/data_sharing.md#consumer-initiated-push-via-a-stream" >}} ),
+stream]( {{< ref "data_sharing.md#consumer-initiated-push-via-a-stream" >}} ),
 with a stream of binary or XML TPEG messages. This has the advantage
 that we do not need to define our own encoding for points of interest.
 
@@ -385,7 +385,7 @@ approach should not be chosen either.
 As with TPEG, we could define a non-TPEG encoding for points of interest
 and stream them to the consumer using [Data sharing\#Consumer-initiated
 push via a
-stream]( {{< ref "/data_sharing.md#consumer-initiated-push-via-a-stream" >}} ).
+stream]( {{< ref "data_sharing.md#consumer-initiated-push-via-a-stream" >}} ).
 Similar considerations apply to the design of the new format: we could
 select an existing format such as
 [KML](https://en.wikipedia.org/wiki/Keyhole_Markup_Language), or design
@@ -399,7 +399,7 @@ still be lost in translation.
 #### Publish/subscribe via D-Bus
 
 As with TPEG, POI providers could use a [publish/subscribe approach via
-D-Bus]( {{< ref "/data_sharing.md#publish.2fsubscribe-via-d-bus" >}} ), with
+D-Bus]( {{< ref "data_sharing.md#publish.2fsubscribe-via-d-bus" >}} ), with
 each D-Bus message carrying one or more points of interest, either
 described using D-Bus data structures or as an opaque byte-array in some
 known format. We anticipate that POI providers would normally have
@@ -430,7 +430,7 @@ messages.
 
 Another possible implementation is to use [Data_sharing\#Query-based
 access via
-D-Bus]( {{< ref "/data_sharing.md#query-based-access-via-d-bus" >}} ), which is
+D-Bus]( {{< ref "data_sharing.md#query-based-access-via-d-bus" >}} ), which is
 a good fit for implementations that query a web service, but a poor fit
 for implementations that receive weather from TPEG (which would have to
 cache all available weather information, and use their cache to be able
@@ -471,14 +471,14 @@ jargon for clarification, for example:
 
 If we anticipate that all categories of data will typically all have the
 same consumers, we recommend having a single shared interface for
-[interface discovery]( {{< ref "/interface_discovery.md" >}} ), perhaps
+[interface discovery]( {{< ref "interface_discovery.md" >}} ), perhaps
 `org.apertis.LocationInfoProvider` or `org.apertis.TPEGProvider`.
 Clients not requiring all of the available data for that interface could
 receive and discard it.
 
 If we anticipate that categories will often have different consumers, we
 will need a list of categories, and an interface for [interface
-discovery]( {{< ref "/interface_discovery.md" >}} ) per category, for example
+discovery]( {{< ref "interface_discovery.md" >}} ) per category, for example
 `PointsOfInterestProvider`, `TrafficProvider` and `WeatherProvider`.
 
 One approach to these categories would be to define a separate D-Bus

content/concepts/archive/application_framework/content_hand-over.md

@@ -28,7 +28,7 @@ ask the system to start the navigation app for that location.
 ## Use-cases
 
 See [Content
-hand-over/Use-cases]( {{< ref "/content_hand-over_use-cases.md" >}} ).
+hand-over/Use-cases]( {{< ref "content_hand-over_use-cases.md" >}} ).
 
 ## The API
 

content/concepts/archive/application_framework/content_hand-over_related.md

@@ -24,7 +24,7 @@ requirements. We recommend that they are examined separately.
 
   - [Interface discovery]( {{< ref "interface_discovery.md" >}} )
   - [Sharing]( {{< ref "sharing.md" >}} )
-  - [Points of interest]( {{< ref "/points_of_interest.md" >}} )
+  - [Points of interest]( {{< ref "points_of_interest.md" >}} )
 
 ## Monitoring status
 

content/concepts/archive/application_framework/egress_filtering.md

@@ -349,7 +349,7 @@ files and other content items that mention a contact's name.
   - *Non-requirement:* it is not possible to prevent the attacker from
     sending the user's confidential data to other applications, and we
     will not attempt to do so. For example, if the address book app must
-    be allowed to carry out a [Sharing]( {{< ref "/sharing.md" >}} ) operation,
+    be allowed to carry out a [Sharing]( {{< ref "sharing.md" >}} ) operation,
     then the compromised app is equally able to "share" the user's
     entire address book with any registered sharing provider.
       - Note that [our assumption that the attacker does not control

content/concepts/archive/application_framework/interface_discovery.md

@@ -31,7 +31,7 @@ to the "API contract" for this set of functionality as an
     menu similar to the one in Android requires a list of applications
     with which files or data can be shared.
   - A navigation app, potentially from an app-store, obtains [points of
-    interest]( {{< ref "/points_of_interest.md" >}} ) from a number of
+    interest]( {{< ref "points_of_interest.md" >}} ) from a number of
     providers, again potentially from an app-store. In a "pull" model,
     the navigation app would consume the interface "points-of-interest
     provider" by sending queries to the implementors and getting results
@@ -49,7 +49,7 @@ to the "API contract" for this set of functionality as an
     the preferred navigation app" to start the navigation app on-demand.
     If it is, it must be possible to mark one as preferred.
   - A navigation app could have a preferences dialog in which [points of
-    interest]( {{< ref "/points_of_interest.md" >}} ) providers can be selected
+    interest]( {{< ref "points_of_interest.md" >}} ) providers can be selected
     or deselected. It should not display points of interest from
     deselected providers, and should not waste system resources on
     receiving points of interest from those providers. However, if
@@ -57,7 +57,7 @@ to the "API contract" for this set of functionality as an
     points of interest provider in the navigation app should not prevent
     it from being used by the other application.
   - The platform could have a preferences dialog in which [points of
-    interest]( {{< ref "/points_of_interest.md" >}} ) providers can be selected
+    interest]( {{< ref "points_of_interest.md" >}} ) providers can be selected
     or deselected. If a POI provider is deselected here, POI consumers
     such as the navigation app should behave as though the deselected
     provider had not been installed at all.

content/concepts/archive/application_security/sharing.md

@@ -30,7 +30,7 @@ application, either built-in or a store application.
   Skype" or "share on Facebook", each with the icon of its associated
   app bundle.
     - *One possible way to obtain this list would be via [Interface
-      discovery]( {{< ref "/interface_discovery.md" >}} ).*
+      discovery]( {{< ref "interface_discovery.md" >}} ).*
 - When the user selects an item from that menu, the current
   application must send the location of the current file to the
   platform, which will respond by launching the app-bundle
@@ -38,7 +38,7 @@ application, either built-in or a store application.
 - The platform must make the relevant file available to the receiving
   application as described in [Content hand-over/Use-cases\#Ensuring
   that the relevant file is
-  accessible]( {{< ref "/content_hand-over_use-cases.md#ensuring-that-the-relevant-file-is-accessible" >}} ).
+  accessible]( {{< ref "content_hand-over_use-cases.md#ensuring-that-the-relevant-file-is-accessible" >}} ).
     - *In practice the implementation is likely to be the same as in
       that use-case.*
 - An app bundle that offers similar functionality must be able to
@@ -54,7 +54,7 @@ application, either built-in or a store application.
   another person, such as a PDF viewer's ability to open PDF files,
   should not normally participate in the sharing menu. Merely opening
   a file for viewing or editing should be treated as 
-  [Content hand-over use-cases]( {{< ref "/content_hand-over_use-cases.md#opening-a-file-by-type" >}} )
+  [Content hand-over use-cases]( {{< ref "content_hand-over_use-cases.md#opening-a-file-by-type" >}} )
   instead.
 - A recommended user-interface toolkit library such as Mildenhall
   could provide a ready-made implementation of the sharing menu.

content/guides/app_devel/ade.md

@@ -21,7 +21,7 @@ Apertis provides tools, pre-installed in the Apertis SDK, for the purpose of
 downloading and interacting with sysroots.
 
 These tools are pre-installed in the Apertis SDK. The SDK images shipped by
-Apertis are meant to be run in [VirtualBox]( {{< ref "/virtualbox.md" >}} ).
+Apertis are meant to be run in [VirtualBox]( {{< ref "virtualbox.md" >}} ).
 They provide a common, reproducible environment to build both platform
 packages and application-bundles for Apertis.  The tool provides general manual
 pages so you can get command information by using `man ade` on the SDK.

content/guides/app_devel/webkit2.md

@@ -41,7 +41,7 @@ current X session. Relying on your `$HOME` avoid incurring in the limited disk
 space available on the SDK image.
 
 Using a shared folder to export the build to a
-[VirtualBox]( {{< ref "/virtualbox.md" >}} ) instance is quite likely to be
+[VirtualBox]( {{< ref "virtualbox.md" >}} ) instance is quite likely to be
 more efficient than building in the VM.
 
 When building on ARM you will probably need a lot of swap space, since the
@@ -110,7 +110,7 @@ other actor.
 # How to customize gtk widgets
 
 You can style gtk widget by using GtkCssProvider. This is covered in 
-[How to Customize GTK Widgets Used by WebKit2GTK+]( {{< ref "/webkit2_customizablewidget.md" >}} ).
+[How to Customize GTK Widgets Used by WebKit2GTK+]( {{< ref "webkit2_customizablewidget.md" >}} ).
 
 # Updating the package
 

content/guides/low_level/enabling_new_hardware.md

@@ -28,7 +28,7 @@ there are two big flavours of images targeted towards devices:
     video decoding to be utilised.
   - Fixed Function Images: GUI-less images with a minimal footprint (though
     images can be [scaled down
-    further]( {{< ref "/scaleddownapertisimage.md" >}} ) if that's required).
+    further]( {{< ref "scaleddownapertisimage.md" >}} ) if that's required).
     Only relies on network connectivity and generally has far lower
     resource demands.
 
@@ -88,4 +88,4 @@ course if the board is completely new for Apertis a new hardware pack
 should be created.
 
 More information about image building in can be found on [Image
-building]( {{< ref "/image_building.md" >}} ).
+building]( {{< ref "image_building.md" >}} ).

content/guides/sdk/virtualbox.md

@@ -488,7 +488,7 @@ that it may boot in [QEMU](https://www.qemu.org/).
 {{% /notice %}}
 
 - Download the `.img.gz` and `.img.bmap` files for the image you need from the
-  [image repository]( {{< ref "/images.md" >}} )
+  [image repository]( {{< ref "images.md" >}} )
 - Expand the downloaded `.img.gz` file:
   - If you have `bmaptool` (recommended), use that to create a sparse file:
 

content/policies/hardware_enablement.md

@@ -41,7 +41,7 @@ software interface should be provided to enable it. As the list is not
 exhaustive with respect to all available types of hardware (e.g. new
 types of hardware that can not currently support by Apertis may not be
 listed here), please ask on the [Apertis developers
-list]( {{< ref "/community.md" >}} ) for guidance when in doubt.
+list]( {{< ref "community.md" >}} ) for guidance when in doubt.
 
 In general the overall guidance is simply if there are well-established
 kernel interfaces for a type of device, those should be used without

content/policies/images.md

@@ -89,7 +89,7 @@ easily be uninstalled and/or excluded from custom-built images.
 ## Base SDK
 
 The base SDK images are APT-based and meant to be run as
-[VirtualBox]( {{< ref "/virtualbox.md" >}} ) VMs to provide a standardized,
+[VirtualBox]( {{< ref "virtualbox.md" >}} ) VMs to provide a standardized,
 ready-to-use environment for developers targeting Apertis, both for platform
 and application development.
 

content/qa/immutablerootfstests.md

@@ -23,7 +23,7 @@ one used in production, reducing the value of testing.
 Changing the rootfs is also impossible or very cumbersome to do with
 some deployment systems such as
 [dm-verity](https://source.android.com/security/verifiedboot/dm-verity)
-or [OSTree]( {{< ref "/ostree.md" >}} ). Other systems may simply not ship
+or [OSTree]( {{< ref "ostree.md" >}} ). Other systems may simply not ship
 package management systems like `apt`/`dpkg` due to size constraints,
 making package dependencies not viable.
 

content/release/15/15.06/releasenotes.md

@@ -75,7 +75,7 @@ Work has been started on migrating from WebKit Clutter to WebKit2GTK+.
 Since the port was still in its early stages, it was decided that the
 best use of time was on pushing the migration forward in the source code
 base rather than on integration, so there are no packages yet. Details
-can be found on the [WebKit2]( {{< ref "/webkit2.md" >}} ) page, the code can be
+can be found on the [WebKit2]( {{< ref "webkit2.md" >}} ) page, the code can be
 found here:
 
 `https://git.collabora.com/cgit/webkit-clutter.git/tree/?h=gtk-clutter`

content/release/15/15.09/releasenotes.md

@@ -92,7 +92,7 @@ resources to e.g. serve as a bridge between the automotive world and the
 wider internet.
 
 A description explaining how this image was put together can be found on
-the [ScaledDownApertisImage]( {{< ref "/scaleddownapertisimage.md" >}} ) page.
+the [ScaledDownApertisImage]( {{< ref "scaleddownapertisimage.md" >}} ) page.
 
 ## Migration to WebKit2GTK+
 
@@ -101,7 +101,7 @@ available in the target section of Apertis. To try it out, install the
 *webkit2gtk-testing* package and run the GtkClutterLauncher test browser
 that ships with it. The API can be used by installing the
 *libwebkit2gtk-4.0-dev* package. Details can be found on the
-[WebKit2]( {{< ref "/webkit2.md" >}} ) page, the code can be found in the git
+[WebKit2]( {{< ref "webkit2.md" >}} ) page, the code can be found in the git
 repository:
 
 `https://git.collabora.com/cgit/webkit-clutter.git/tree/?h=gtk-clutter`
@@ -278,11 +278,11 @@ release.
 
 ## Application communication designs
 
-Draft designs for [interface discovery]( {{< ref "/interface_discovery.md" >}} )
-and [data sharing]( {{< ref "/data_sharing.md" >}} ) have been added to the
+Draft designs for [interface discovery]( {{< ref "interface_discovery.md" >}} )
+and [data sharing]( {{< ref "data_sharing.md" >}} ) have been added to the
 Apertis wiki. These provide generic "building blocks" for app-to-app
 communication. A draft design for handling [points of
-interest]( {{< ref "/points_of_interest.md" >}} ) is a new feature in its own
+interest]( {{< ref "points_of_interest.md" >}} ) is a new feature in its own
 right, and also acts as a case-study for a specific set of use-cases for
 app-to-app communication.
 

content/release/16/16.03/releasenotes.md

@@ -229,7 +229,7 @@ adding new packages to the repositories (Pico TTS).
 ## Security design
 
 Detailed requirements have been gathered for a [Compositor
-security]( {{< ref "/compositor_security.md" >}} ) design proposal which is to
+security]( {{< ref "compositor_security.md" >}} ) design proposal which is to
 be worked on in a future release cycle.
 
 The [Application Layout design and

content/release/16/16.06/release_schedule.md

@@ -50,5 +50,5 @@ countdown on Phabricator](https://phabricator.apertis.org/countdown/).
 
 ## See also
 
-  - Previous [release schedules]( {{< ref "/releases.md" >}} ) and
+  - Previous [release schedules]( {{< ref "releases.md" >}} ) and
     information

content/release/16/16.06/releasenotes.md

@@ -244,7 +244,7 @@ matching colors, to improve visual experience. This included the wiki,
 documentation and application developer portals.
 
 In addition, the new visual is available for download form the
-[marketing resources]( {{< ref "/marketing_resources.md" >}} ) page.
+[marketing resources]( {{< ref "marketing_resources.md" >}} ) page.
 
 ## Documentation improvements
 

content/release/16/16.09/release_schedule.md

@@ -47,5 +47,5 @@ The 16.09 release cycle started in July 2016.
 
 ## See also
 
-  - Previous [release schedules]( {{< ref "/releases.md" >}} ) and more
+  - Previous [release schedules]( {{< ref "releases.md" >}} ) and more
     information about the timeline