Remove user pages

Most of the user pages contain links to pages written by the user as some
users took the convention of writing pages in their user areas before
moving into a more suitable location once they had been reviewed. As this
is no longer the expected workflow and the new site does not have the
concept of users, remove these pages.

Any pages with potential value as still in progress have been moved to
branches which can be reviewed an merged properly in the future.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/marketing_resources.md

@@ -41,7 +41,7 @@ Apertis community have previously shared (ordered newest to oldest):
 
   - [<File:Genivi-amm-2017-slides.odp>](/genivi-amm-2017-slides.odp)
     - introduction to application framework for GENIVI and Apertis by
-    [Kat]( {{< ref "/user_kittykat.md" >}} ) and Andre
+      Ekaterina Gerasimova and Andre Magalhães
 
 ### 2016
 
@@ -50,4 +50,4 @@ Apertis community have previously shared (ordered newest to oldest):
     - an introduction to Apertis by Lukas Nack
   - [<File:Apertis-GNOMEAsia-2016-slides.odp>](/apertis-gnomeasia-2016-slides.odp)
     - an overview of architecture and development by Sudarshan
-    Chikkapura Puttalingaiah
+    Chikkapura Puttalingaiah
\ No newline at end of file

content/user_andrewsh.md

-+++
-date = "2016-09-15"
-weight = 100
-
-title = "User:Andrewsh"
-
-aliases = [
-    "/old-wiki/User:Andrewsh"
-]
-+++
-

content/user_fdalleau.md

-+++
-date = "2016-08-26"
-weight = 100
-
-title = "User:Fdalleau"
-
-aliases = [
-    "/old-wiki/User:Fdalleau"
-]
-+++
-
-Work in progress
-
-[User:Connman-pan-network-access-profile]( {{< ref "/qa/test_cases/connman-pan-network-access.md" >}} )
-
-[User:ofono-voicecall]( {{< ref "/user_ofono-voicecall.md" >}} )
\ No newline at end of file

content/user_joykim.md

-+++
-date = "2017-03-24"
-weight = 100
-
-title = "User:Joykim"
-
-aliases = [
-    "/old-wiki/User:Joykim"
-]
-+++
-
-[User:Joykim/HowToWorkWithPatches]( {{< ref "/guidelines/contribution_process.md" >}} )
-
-[User:Joykim/HowToReleasePackages]( {{< ref "/guidelines/howtoreleasepackages.md" >}} )

content/user_kittykat.md

-+++
-date = "2015-11-03"
-weight = 100
-
-title = "User:Kittykat"
-
-aliases = [
-    "/old-wiki/User:Kittykat"
-]
-+++
-
-  - IRC: kittykat on freenode and GIMPNet
-  - Blog: <http://blogs.gnome.org/kittykat/>
\ No newline at end of file

content/user_kittykat/todo.md

-+++
-date = "2016-01-07"
-weight = 100
-
-title = "User:Kittykat TODO"
-
-aliases = [
-    "/old-wiki/User:Kittykat/TODO"
-]
-+++
-
-  - Link <https://wiki.apertis.org/Creating_a_project> to a licensing
-    page
\ No newline at end of file

content/user_martyn.md

-+++
-date = "2019-11-25"
-weight = 100
-
-title = "User:Martyn"
-
-aliases = [
-    "/old-wiki/User:Martyn"
-]
-+++
-
-## Published pages
-
-  - [User:Martyn/HowToBuildYourOwnKernel]( {{< ref "/guidelines/howtobuildyourownkernel.md" >}} )
-  - [User:Martyn/BuildingPatchingAndMaintainingTheApertisKernel]( {{< ref "/guidelines/buildingpatchingandmaintainingtheapertiskernel.md" >}} )
-
-## Draft pages
-
-  - [User:Martyn/Main_Page]( {{< ref "/user_martyn/main_page.md" >}} )
-  - [User:Martyn/HardwareBringUp]( {{< ref "/user_martyn/hardwarebringup.md" >}} )
\ No newline at end of file

content/user_martyn/hardwarebringup.md

-+++
-date = "2019-12-03"
-weight = 100
-
-title = "User:Martyn HardwareBringUp"
-
-aliases = [
-    "/old-wiki/User:Martyn/HardwareBringUp"
-]
-+++
-
-When we wish to utilise Apertis on a new platform, it is highly likely
-that "Hardware Bring-Up" will be one of the first tasks that needs to be
-performed. Hardware bring-up is the process by which support for an
-initially unsupported target platform is iteratively created and tested.
-
-The process of board bring-up by necessity initially follows the boot
-process, we need at least a basic implementation of the initial boot
-steps in place before moving on to the later steps. It is likely that
-this process will be iterative, with the boot process initially being
-implemented in a way that is more suited to the development process and
-evolving over time with the addition of extra board support to become
-closer to that desired for the final end product.
-
-Unless a third party CPU module on an architecture with highly
-standardised boot firmware is being used (which may be the case with an
-x86 based CPU module, where development of the boot firmware may be
-entirely by-passed), development will start with enabling support in a
-suitable boot firmware. For the majority of the reference platforms
-currently enabled in Apertis (and as a result, the other platforms that
-have been enabled in Apertis) have utilised
-[U-Boot](https://www.denx.de/wiki/U-Boot) as boot firmware. In this
-guide we will assume development is to be carried out on an ARM based
-platform, though it is likely that the process would be broadly similar
-for targets utilising other architectures as well.
-
-# Development Environment
-
-In order to perform the required development a suitable development
-environment will be required. It is likely that early development steps
-could be carried out on any Linux host with a suitable toolchain
-available. As development progresses the required feature set of the
-toolchain will grow and will incorporate tools generally only found in
-Debian based development systems. In order to ensure that prospective
-Apertis developers have access to a suitable environment, the Apertis
-project makes available a [Software Development
-Kit](https://wiki.apertis.org/Deployment_Environment) (SDK) which can be
-used through VirtualBox.
-
-# Boot firmware source
-
-The two code bases that are most likely to need to be adapted or
-configured to bring-up the target hardware are a boot loader, such as
-U-Boot and the Linux kernel. Whilst, within reason, any relatively
-recent version of a boot loader and Linux kernel can be used some of the
-advanced features supported by Apertis have required specific
-configuration changes and/or changes to be made to the boot loader and
-kernel. In order to minimise work required to support such features
-(should they be needed at a later date) and to take full advantage of
-the efficiencies afforded by the Apertis platform, it is advisable to
-start from the current supported Apertis bootloader. Apertis stores it's
-source code in gitlab the currently supported bootloader and kernel can
-be found here:
-
-  - [U-Boot](https://gitlab.apertis.org/pkg/target/u-boot)
-  - [Linux Kernel](https://gitlab.apertis.org/pkg/target/linux)
-
-# Development process
-
-## Bootloader Development
-
-Unless developing for a target utilising an Architecture or SoC not
-currently supported by the chosen firmware (something that is out of
-scope for this guide), it is likely that the initial focus will be on
-ensuring that the firmware is correctly configuring the memory timing,
-pin multiplexing and serial port configuration . These are generally
-configured in a board support file in the U-Boot firmware under
-`board/`. Whilst serial ports have broadly been replaced in their
-traditional use cases, the simplicity of the port means that it remains
-a very common mechanism for sending boot process and debug messages
-during board bring-up. If these settings are correctly configured, this
-is usually enough to get early an boot message via the serial port when
-booted.
-
-Generally it is not necessary to start from scratch. The U-Boot source
-contains support for a myriad of existing targets and it's acceptable to
-pick support for an existing board, copy it and use that as a basis for
-your own board. Please note that whilst this can be more efficient that
-starting from scratch, there is a risk of picking up a board that
-doesn't follow the latest preferred style/mechanisms, so it's worth
-spending a bit of time looking at the available boards and understanding
-which mechanisms are being used in the latest boards.
-
-In order to ensure the development process is as efficient as possible,
-it is advisable to utilise any available process that allows the target
-to be booted from a remote source. In the case of the ARM architecture,
-most if not all System-on-Chips (SoCs) provide some mechanism to boot
-the device over USB using a SoC specific protocol to load the boot
-firmware into RAM. On many SoCs, the boot process must be broken down
-into multiple stages as the default state of the system is unable to
-handle the size of a full U-Boot binary. In order to enable bigger
-binaries to be loaded, U-Boot has the concept of a Secondary Program
-Loader (SPL). This is a smaller cut-down version of U-Boot that is
-loaded before the main U-Boot binary and is used to configure the system
-sufficiently to enable the main U-Boot binary to be loaded. (In fact on
-some systems there is also a Tertiary Program Loader (TPL) to enable
-loading of the SPL.) U-Boot is able to handle a number of these SoC
-specific protocols allowing the multiple stages of U-Boot to be loaded
-via these mechanisms. For later components in the boot process, network
-booting such as TFTP usually becomes a viable option.
-
-In order to maximise driver reuse and to allow a single binary to
-support multiple target platforms, both U-Boot and the Linux kernel make
-use of a [device tree](https://elinux.org/Device_Tree_What_It_Is) to
-describe the non-discoverable hardware available in a given target
-system. It is common to utilise the same device tree in both U-Boot and
-the Linux kernel, potentially with an overlay in U-Boot to provide
-U-Boot specific customisations to the device tree. The device tree
-enables U-Boot's Driver Model (DM) to instantiate drivers to drive
-compatible hardware wherever they sit in the devices memory map. The use
-of device trees means that for any already supported SoCs, a large part
-of the work associated with initial bring up is in adding the required
-nodes to the device tree to describe the hardware and enabling the
-required drivers. Where possible it is highly recommended to utilise
-U-Boot's driver model.
-
-### Apertis Requirements
-
-Apertis utilises the "[Generic Distro Configuration
-Concept](https://gitlab.denx.de/u-boot/u-boot/raw/master/doc/README.distro)"
-(often referred to as "Distro Boot") during it's boot process. It is
-recommended to enable both the required local boot media, PXE and DHCP
-options via the `BOOT_TARGET_DEVICES` macro, the PXE and DHCP options
-being especially useful during development as this allows the kernel and
-subsequent binaries in the boot process to be provided via a network
-interface. Such a network interface may be an Ethernet connection
-provided by the target board (and enabled in U-Boot) or if no Ethernet
-port is available, it is possible to provide networking with a USB RNDIS
-gadget should a USB On-The-Go (USB OTG) port be available. This allows
-U-Boot to retrieve boot configuration and the required binaries, such as
-the Linux kernel, device tree binary (DTB) and initrd, via TFTP.
-
-## Kernel Development
-
-Once U-Boot has reached the point where it can load via the Distro Boot
-mechanism we can start to focus on the Linux kernel rather than U-Boot.
-At this point we are likely to have a simple device tree, providing
-nodes for the minimal support that we've needed to add for the limited
-functionality we need in the bootloader. This can be integrated into the
-kernel source tree and needs to be expanded whilst enabling support for
-board features required at runtime, but which are not required as part
-of the bootloader.
-
-In order to provide a user space environment for testing on the target
-device, especially before the on-board storage has been enabled and
-initialised, it is common to use a [NFS based root file
-system](https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt).
-This requires networking and NFS support to be enabled in the kernel and
-the location of the NFS root can be specified via the Distro Boot
-configuration. This of course requires a roof file system and the
-Apertis minimal OSpack (downloadable from
-[images.apertis.org](https://images.apertis.org)) can be extracted and
-used to provide this. The minimal image can be easily extended using
-`apt` to install and tools and utilities needed to test the interfaces
-and peripherals attached to the system.
-
-Once a point has been reached where the device tree adequately describes
-the hardware found in the target platform, it is worth spending the time
-to update the device tree found in the U-Boot source to match the one
-found in the kernel source to ensure that the two stay in sync.
-
-### Apertis Requirements
-
-In order to support the Apertis user space, the kernels support for
-Apparmor should be enabled as this is widely used by Apertis for process
-containment. As Apertis uses systemd, it is necessary to also ensure
-that the [kernel configuration
-options](https://github.com/systemd/systemd/blob/master/README) required
-by systemd are also enabled. This will be the case if starting from the
-existing [Apertis kernel
-configuration]( {{< ref "/guidelines/buildingpatchingandmaintainingtheapertiskernel.md#building" >}} ).
-Further guidance regarding the integration of specific hardware is
-provided in [Hardware Interfaces]( {{< ref "/hardware_interfaces.md" >}} ).
-
-## Packaging Components
-
-Once we have a kernel booting to an NFS-based rootfs with sufficient
-support (including the local storage that is to be used), we need to
-package the bootloader and kernel. If using the Apertis supplied
-bootloader and kernel, a lot of the necessary metadata will already be
-in place and the workflow has been documented in [Building, Patching And
-Maintaining The Apertis
-Kernel]( {{< ref "/guidelines/buildingpatchingandmaintainingtheapertiskernel.md" >}} ).
-
-If working from a kernel from another source, it will be necessary to
-become familiar with [Debian
-packaging](https://wiki.debian.org/Packaging/Intro). Note that the
-Debian kernel (and thus the Apertis kernel) utilise a slightly modified
-approach to configuration compared with most deb packages due to the
-special nature of the kernel. More information about the kernel
-configuration, see the Debian kernel's
-[README.Debian](https://salsa.debian.org/kernel-team/linux/blob/master/debian/README.Debian).
-
-## Creating Target Specific Images
-
-Once the bootloader and kernel have been packaged, an image suitable for
-loading onto the device can be created. Building these packages is
-expected to be carried out from source by the Apertis infrastructure,
-ensuring all packages dependencies are properly described and reducing
-the risk of unexpected dependencies. This also results in the packages
-being made available in a deb package repository and thus available by
-the image creation tooling.
-
-These packages are usually assembled into 2 bigger building blocks
-before ultimately being combined, the `OSpack` and the `HWpack`. The
-process is managed by a tool called
-[Debos](https://github.com/go-debos/debos), which uses yaml
-configuration files to guide what steps it takes.
-
-### OSpack
-
-The OSpack is a generic (architecture specific but largely hardware
-independent) archived rootfs built from Apertis packages. Apertis
-provides Debos yaml files to assemble a number of differently targeted
-OSpacks, ranging from a minimal GUI-less OSpack, a target focused GUI
-OSpack and a development environment with a desktop style GUI.
-
-### HWpack
-
-Unlike the OSpack, that is generic, the hardware pack (HWpack) contains
-the bits needed to boot on a specific target. The HWpack is not a single
-item, it is a number of packages and processes, controlled via a Debos
-script, that convert a hardware independent OSpack into an image which
-can be successfully booted on a specific hardware platform. It is
-expected a small number of OSpacks to be combined with a number of
-HWpacks to create an array of images suitable for a wide range of
-targets.
-
-The configuration used to create OSpacks and images from them for the
-Apertis reference platforms can be found in
-[GitLab](https://gitlab.apertis.org/infrastructure/apertis-image-recipes)
-with their use documented in `README.md`.
-
-To find out more about the process of creating OSpacks and HWpacks, see
-[Image Building]( {{< ref "/image_building.md" >}} ).
-
-### Building images for hypervisors and virtual machines
-
-TBD (Basically the same as packaging for real hardware)
-
-# Testing
-
-TBD
-
-  - Boot test on both new and existing hardware
-
-<!-- end list -->
-
-  - Boot test
-  - Ensure changes do not result in regressions against Apertis tests
-
-# Submitting Upstream
-
-The Apertis project strongly supports the concept of upstreaming and
-supports it's users to upstream. The Apertis project provides
-documentation covering [why, where and
-what](https://designs.apertis.org/latest/upstreaming.html) to upstream,
-as well as [guidance on the upstreaming
-process](https://designs.apertis.org/latest/contribution-process.html).
\ No newline at end of file

content/user_martyn/main_page.md

-+++
-date = "2019-11-14"
-weight = 100
-
-title = "User:Martyn Main Page"
-
-aliases = [
-    "/old-wiki/User:Martyn/Main_Page"
-]
-+++
-
-Apertis is a versatile open source infrastructure tailored to the
-automotive needs and fit for a wide variety of electronic devices.
-Security and modularity are two of its primary strengths. Apertis
-provides a feature-rich framework for add-on software and resilient
-upgrade capabilities. Beyond an operating system, it offers new APIs,
-tools and cloud services.
-
-<table>
-<tbody>
-<tr class="odd">
-<td><table>
-<tbody>
-<tr class="odd">
-<td><h2 id="mp-tfa-h2" style="margin:3px; background:#3a5a82; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#ffffff; padding:0.2em 0.4em;">
-<p>Production Friendly</p>
-</h2></td>
-</tr>
-<tr class="even">
-<td><div id="mp-tfa" style="padding:2px 5px">
-<p>Apertis aims to accomplish the following goals:</p>
-<ul>
-<li>Ensure that all the software shipped in Apertis is open source or at least freely distributable, so that downstreams are entitled to use, modify and redistribute work derived from our deliverables.</li>
-<li>Ensure that Apertis images targeting devices (such as target and minimal), are not subject to licensing constraints that may conflict with the regulatory requirements of some intended use cases.</li>
-</ul>
-<p>Apertis is primarily licensed under the Mozilla Public License Version 2.0, with images and documentation licensed under CC BY-SA 4.0.</p>
-<p>For more information see <a href="https://designs.apertis.org/latest/license-expectations.html">Open source License expectations</a>.</p>
-<p>Apertis undergoes regular automated and manual testing with publicly available results.</p>
-<p>For more information see</p>
-<h2 id="further-links-1">Further Links</h2>
-<ul>
-<li><a href="https://designs.apertis.org/latest/license-expectations.html">Licensing</a></li>
-<li><a href=" {{< ref "/build_and_integration_infrastructure_documentation.md" >}} ">Build and Integration infrastructure</a></li>
-<li><a href=" {{< ref "/qa.md" >}} ">Quality assurance</a></li>
-<li><a href="https://lavaphabbridge.apertis.org">Test results</a></li>
-</ul></td>
-</tr>
-</tbody>
-</table></td>
-<td></td>
-<td><table>
-<tbody>
-<tr class="odd">
-<td><h2 id="mp-itn-h2" style="margin:3px; background:#3a5a82; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#ffffff; padding:0.2em 0.4em;">
-<p>Frequent Releases</p>
-</h2></td>
-</tr>
-<tr class="even">
-<td><div id="mp-itn">
-<p>The overall goal is for Apertis to do a yearly product release. These releases will be named after the year of the stable release, in other words the product release targetted at 2020 will be given major version 2020. A product release is intended to both be based on the most recent mainline kernel LTS release and the current Debian stable release. Since Debian releases roughly once every two years, that means that there will typically be two Apertis product releases based on a single Debian stable release. With Linux doing an LTS release on a yearly basis, each Apertis product release will be based on a different (and then current) Linux kernel release.</p>
-<p>The standard support period for each Apertis product release is 7 quarters. In other words from the initial release at the end of Q1 until the end of the next year.</p>
-<p>For more information, see <a href="https://designs.apertis.org/latest/release-flow.html">Release flow and product lines</a>.</p>
-<h2 id="further-links-3">Further Links</h2>
-<ul>
-<li><a href=" {{< ref "/releasenotes.md" >}} ">Releases</a></li>
-<li><a href=" {{< ref "/roadmap.md" >}} ">Roadmap</a></li>
-<li><a href=" {{< ref "/v2019.0/release_schedule.md" >}} ">Release schedule for V2019.0</a></li>
-<li><a href=" {{< ref "/v2020dev0/release_schedule.md" >}} ">Release schedule for V2020dev0</a></li>
-</ul></td>
-</tr>
-</tbody>
-</table></td>
-<td></td>
-<td><table>
-<tbody>
-<tr class="odd">
-<td><h2 id="mp-itn-h2" style="margin:3px; background:#3a5a82; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#ffffff; padding:0.2em 0.4em;">
-<p>Developer Ready</p>
-</h2></td>
-</tr>
-<tr class="even">
-<td><div id="mp-itn">
-<p>Apertis provides a number of pre-built images for Intel (64-bit) and ARM (32-bit and 64-bit) for evaluation on one of the Apertis <a href="https://wiki.apertis.org/Reference_Hardware">Reference Hardware</a> platforms. Additionally Apertis provides an SDK image to simplify development for the platform.</p>
-<p><img src="/images/vm-sdk.png" alt="frameless|center|The Apertis SDK"></p>
-<h2 id="further-links-5">Further Links</h2>
-<ul>
-<li><a href=" {{< ref "/apertis_code_of_conduct.md" >}} ">Code of conduct</a></li>
-<li><a href=" {{< ref "/images.md" >}} ">Download the current images</a></li>
-<li><a href=" {{< ref "/deployment_environment.md" >}} ">Set up your development environment</a></li>
-<li><a href="https://gitlab.apertis.org">Source code</a></li>
-<li><a href=" {{< ref "/guidelines.md" >}} ">Development guidelines</a></li>
-<li><a href="https://developer.apertis.org">App developer portal</a></li>
-<li><a href="https://lists.apertis.org/">Mailing lists</a></li>
-<li><a href="https://images.apertis.org/">Images</a></li>
-<li><a href="https://repositories.apertis.org/">Repositories</a></li>
-<li><a href=" {{< ref "/conceptdesigns.md" >}} ">Concept designs</a></li>
-<li><a href="https://developer.apertis.org/latest/apis.html">Supported APIs</a></li>
-</ul></td>
-</tr>
-</tbody>
-</table></td>
-</tr>
-</tbody>
-</table>
-
- 
\ No newline at end of file

content/user_peter.md

-+++
-date = "2019-11-25"
-weight = 100
-
-title = "User:Peter"
-
-aliases = [
-    "/old-wiki/User:Peter"
-]
-+++
-
-[User:Peter/HWPACKforVendors](https://wiki.apertis.org/User:Peter/HWPACKforVendors)
\ No newline at end of file

content/user_peter/hwpackforvendors.md

-+++
-date = "2019-11-25"
-weight = 100
-
-title = "User:Peter HWPACKforVendors"
-
-aliases = [
-    "/old-wiki/User:Peter/HWPACKforVendors"
-]
-+++
-
-# Apertis hwpack: requirements for vendors
-
-This is the output of
-[APERTIS-6608](https://phabricator.apertis.org/T6608).
-
-## Introduction
-
-Adding support to a new architecture, or to a new board is done trough
-cycles of hardware bring-up. During each cycle, the developer enables
-new features, or fixes known issues until the hardware support is
-considered adequate. On a low level perspective, hardware bring-up is
-about developing and adjusting a few components such as the boot loader
-and the kernel to provide the hardware initialization and hardware
-support for the operating system. When using Apertis, the output of the
-hardware bring-up will be the hwpack, which is a platform specific
-collection of artifacts that are needed for the hardware initialization
-and support.
-
-[Debos](https://github.com/go-debos/debos) is the main tool used for
-building Apertis images. Debos allows for modular design of images, and
-is capable of creating the modules and the images. The image modules
-used by Apertis are:
-
-`* hwpack: platform-specific artifacts related to hardware initialization and hardware support`
-`* ospack: platform-independent artifacts common to a set of images such as target or development images`
-
-The
-[apertis-image-recipes](https://gitlab.apertis.org/infrastructure/apertis-image-recipes)
-is the code repository that hosts the Debos recipes that are used for
-creating Apertis images. While the ospack recipes are explicitly named,
-the hwpacks are defined inside the apertis-image-\*.yaml files. The
-rationale is that the hwpack is a set of steps and components that
-extends the ospack to boot on the target. Looking at the
-[apertis-image-uboot.yaml](https://gitlab.apertis.org/infrastructure/apertis-image-recipes/blob/apertis/v2020pre/apertis-image-uboot.yaml)
-recipe, we see that Debos uncompress the ospack to add changes on top of
-it, that it creates the image with partition scheme, filesystems,
-u-boot, and that it deploys the modified ospack into the image adding
-hwpack artifacts such as the kernel, and other system packages.
-
-Apertis is both a platform and the automated infrastructure that is used
-to conveniently evolve and cheaply maintain the platform. The
-infrastructure uses automation to ensure quality and minimize
-maintenance costs. Some of the hwpack requirements and suggestions are
-in place to avoid deviation from the existing Apertis processes.
-
-## Requirements
-
-### Source code
-
-### Long term support
-
-### Updates
-
-### Security fixes
-
-### Boot loader
-
-### Kernel
-
-## Suggestions
-
-### Boot loader
-
-### Kernel
-
-## Example of Apertis hwpack
-
-## Final words
\ No newline at end of file