Compare revisions

Walter Lozano · Denis Pynkin · Emanuele Aina · Frederic Danis · Peter Senna Tschudin · Martyn Welch
--- a/content/_index.md
+++ b/content/_index.md
@@ -63,6 +63,7 @@ For more information, see [Release flow and product lines]( {{< ref "release-flo
 * Current stable release: [v2020.3]( {{< ref "/release/v2020.3/releasenotes.md" >}} )
 * Current old stable release: [v2019.5]( {{< ref "/release/v2019.5/releasenotes.md" >}} )
 * Current preview release: [v2021pre]( {{< ref "/release/v2021pre/releasenotes.md" >}} )
+* Current development release: [v2022dev0]( {{< ref "/release/v2022dev0/releasenotes.md" >}} )
 * [Further releases]( {{< ref "releases.md" >}} )



--- a/content/architecture/encrypted-updates.md
+++ b/content/architecture/encrypted-updates.md
@@ -117,3 +117,13 @@ New keys should be generated:
 ## How to handle the leak of a key to the public and how that impacts future updates
  - If the keys are stored on the filesystem, the leak of one key implies the leak of the others
  - If the keys are stored using the secure-boot-verified key storage system, the next update should be signed with a key that hasn't been leaked and the update should revoke the leaked key
+
+# Encryption Parameters
+
+In a classical usage, the encryption is setup through a benchmark on the computer/board which will use it, allowing a good balance between password strength and unlocking time. This could end-up by encrypted file not usable due to out of memory error or slow unlocking time.
+
+LUKS key strength is managed through 3 `cryptsetup` parameters: `--pbkdf-memory`, `--pbkdf-force-iterations` and `--pbkdf-parallel`.
+
+`--pbkdf-parallel` configures the maximun number of threads used to unlock the encrypted file. This is automatically decreased on hardware devices that have only one of just a few cores.
+
+As encrypted update file is created during image build on computer with more CPU power and memory, and that it is important to find a balance between password strength and usability, the `--pbkdf-memory` and `--pbkdf-force-iterations` should be forced to appropriate values for the target board.
--- a/content/concepts/tls-stack.md
+++ b/content/concepts/tls-stack.md
@@ -514,7 +514,7 @@ appropriate by the individual projects.
 <td>neon27</td>
 <td>LGPL-2.1+</td>
 <td></td>
-<td></td>
+<td>X</td>
 <td>X</td>
 <td></td>
 </tr>

--- a/content/guides/automated_license_install.md
+++ b/content/guides/automated_license_install.md
+++
+date = "2020-12-15"
+weight = 100
+
+title = "Automated Licensing Compliance Install"
+++
+
+# Automated Licensing Compliance Install
+
+As described in [Automated License Compliance]( {{< ref "automated-license-compliance.md" >}}) a check is performed on image creation to confirm the compliance with the terms that [Apertis may wish to avoid]( {{< ref "license-expectations.md" >}} ).
+
+To support this feature several pieces of software need to be installed.
+
+## FOSSology
+
+The recommended FOSSolgy setup consist in
+- FOSSology server
+- PostgreSQL database server
+- Apache HTTP server
+
+We recommend to build this setup trough a Docker installation as described in [FOSSolgy Docker installation](https://github.com/fossology/fossology/blob/master/README.md#docker)
+
+Bellow there is a sample Docker compose file to spawn the different services
+
+```
+# FOSSology Docker Compose file
+# Copyright Siemens AG 2016, fabio.huser@siemens.com
+# Copyright TNG Technology Consulting GmbH 2016-2017, maximilian.huber@tngtech.com
+#
+# Copying and distribution of this file, with or without modification,
+# are permitted in any medium without royalty provided the copyright
+# notice and this notice are preserved.  This file is offered as-is,
+# without any warranty.
+#
+# Description: Recipe for setting up a multi container FOSSology
+#              Docker setup with separate Database instance
+version: '3.5'
+services:
+  scheduler:
+    image: fossology/fossology:3.9.0
+    restart: unless-stopped
+    environment:
+      - FOSSOLOGY_DB_HOST=db
+      - FOSSOLOGY_DB_NAME=fossology
+      - FOSSOLOGY_DB_USER=fossy
+      - FOSSOLOGY_DB_PASSWORD=fossy
+    command: scheduler
+    depends_on:
+      - db
+    volumes:
+      - repository:/srv/fossology/repository/
+  web:
+    image: fossology/fossology:3.9.0
+    restart: unless-stopped
+    environment:
+      - FOSSOLOGY_DB_HOST=db
+      - FOSSOLOGY_DB_NAME=fossology
+      - FOSSOLOGY_DB_USER=fossy
+      - FOSSOLOGY_DB_PASSWORD=fossy
+      - FOSSOLOGY_SCHEDULER_HOST=scheduler
+    command: web
+    ports:
+      - 8081:80
+    depends_on:
+      - db
+      - scheduler
+    volumes:
+      - repository:/srv/fossology/repository/
+  db:
+    image: postgres:9.6
+    restart: unless-stopped
+    environment:
+      - POSTGRES_DB=fossology
+      - POSTGRES_USER=fossy
+      - POSTGRES_PASSWORD=fossy
+      - POSTGRES_INITDB_ARGS='-E SQL_ASCII'
+    volumes:
+      - database:/var/lib/postgresql/data
+
+volumes:
+  database:
+  repository:
+```
+
+## Gitlab CI
+
+The license scanning process is triggered by Gitlab CI, which requires the latest version of the following recipes:
+
+- `ci-package-builder`
+- `apertis-docker-images`
+- `apertis-image-recipes`
+
+The following CI variables configure the parameters to connect with FOSSology sever
+- `FOSSOLOGY_URL`
+- `FOSSOLOGY_USERNAME`
+- `FOSSOLOGY_PASSWORD`
+
+## OBS
+
+The package build process is performed in OBS by running `debhelper`, which requires the version `12.1.1co1` or above.
+
+
--- a/content/policies/contributions.md
+++ b/content/policies/contributions.md
@@ -235,9 +235,13 @@ is not different in this regard.
 Whilst Apertis does accept changes to existing components, it needs to be
 acknowledged that this increases the effort required to maintain the package in
 question. It may be requested that an attempt be made to upstream
-the changes, in line with the [upstream first]( {{< ref "#upstream-first-policy" >}} ) policy,
-either to the packages upstream or Debian. More guidance is provided in the
-[upstreaming]( {{< ref "upstreaming.md" >}} ) documentation.
+the changes, in line with the
+[upstream first]( {{< ref "#upstream-first-policy" >}} ) policy, either to the
+packages upstream or Debian. More guidance is provided in the
+[upstreaming]( {{< ref "upstreaming.md" >}} ) documentation. If changes are not
+generally of use or would have a negative impact on the broader Apertis user
+base, changes may be required to be carried by the specific project within a
+[dedicated project area]( {{<ref "#dedicated-project-areas" >}}).


 ## Adding designs to Apertis

--- a/content/policies/releases.md
+++ b/content/policies/releases.md
@@ -47,13 +47,14 @@ and getting the support of two or more Apertis maintainers.

 The latest releases are:

+  - v2022dev0: [release notes]( {{< ref "/release/v2022dev0/releasenotes.md" >}} ), [release schedule]( {{< ref "/release/v2022dev0/release_schedule.md" >}} )
  - v2021pre: [release notes]( {{< ref "/release/v2021pre/releasenotes.md" >}} ), [release schedule]( {{< ref "/release/v2021pre/release_schedule.md" >}} )
  - v2020.3: [release notes]( {{< ref "/release/v2020.3/releasenotes.md" >}} ), [release schedule]( {{< ref "/release/v2020.3/release_schedule.md" >}} )
  - v2019.5: [release notes]( {{< ref "/release/v2019.5/releasenotes.md" >}} ), [release schedule]( {{< ref "/release/v2019.5/release_schedule.md" >}} )

 The next releases will be:

-  - v2022dev0: [release schedule]( {{< ref "/release/v2022dev0/release_schedule.md" >}} )
+  - v2022dev1: [release schedule]( {{< ref "/release/v2022dev0/release_schedule.md" >}} )
  - v2021.0: [release schedule]( {{< ref "/release/v2021.0/release_schedule.md" >}} )
  - v2020.4: [release schedule]( {{< ref "/release/v2020.4/release_schedule.md" >}} )
  - v2019.6: [release schedule]( {{< ref "/release/v2019.6/release_schedule.md" >}} )

--- a/content/reference_hardware/rcar-gen3_setup.md
+++ b/content/reference_hardware/rcar-gen3_setup.md
 +++
 date = "2019-03-14"
+lastmod = "2020-12-17"
 weight = 100

 title = "R-Car Hardware Setup"
@@ -15,11 +16,12 @@ aliases = [

 You should have at least:

-  - 1 suported R-car board
+  - 1 supported R-car board
  - 1 suitable Power adaptor
  - 1 USB to micro-usb cable
  - ATF /optee setup on the board and booting from the A57 CPU (See
-    manufactorer documentation on how to set this up)
+    the [documentation](https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware)
+    on how to set this up)

 You need to provide your own:

@@ -27,26 +29,19 @@ You need to provide your own:

 ## Prepare SD card

-1.  Download the arm64 minimal image (for example,
-    [1](https://images.apertis.org/daily/17.03/images/minimal/arm64-generic/20170331.0/apertis-17.03-minimal-arm64-generic_20170331.0-collabora.btrfs.img.gz)),
-    plus the `.bmap` files (you can find them here,
-    [2](https://images.apertis.org/release/15.03) or You might want a
-    daily updated image. You can find it here as well
-    [3](https://images.apertis.org/daily/)), and flash the image to a
+  - Download the
+    [arm64 minimal image](https://images.apertis.org/release/v2020/v2020.3/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.3.img.gz),
+    plus the [`.bmap` file](https://images.apertis.org/release/v2020/v2020.3/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.3.img.bmap).
    microSD card using command:
-        sudo bmaptool copy path/to/image.img.gz /dev/mmcblk0

-Alternatively bmaptool can flash directly from http e.g. by using:
+        sudo bmaptool copy apertis_v2020-minimal-arm64-uboot_v2020.3.img.gz /dev/mmcblk0

-    sudo bmaptool copy https://images.apertis.org/release/v2020/v2020.0/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.0.img.gz /dev/mmcblk0
+    Alternatively bmaptool can flash directly from http e.g. by using:

-<li>
+        sudo bmaptool copy https://images.apertis.org/release/v2020/v2020.3/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.3.img.gz /dev/mmcblk0

-Put the SD card in the board

-</li>
-
-</ol>
+  - Put the SD card in the board

 ## Setup instructions

@@ -57,10 +52,10 @@ Renesas u-boot, as such at least u-boot needs to be updated.

 ### Updating U-Boot

-At the time of this writing most R-Car boards are still early production, this
-unfortunately means different IPL/DRAM setup versions (part of the
-arm-trusted-firmare Renesas repository) are needed for boards depending on the
-time of productions. As such Apertis doesn't currently supply builds for those
+R-Car boards are shipped with different IPL/DRAM setup versions (part of the
+[arm-trusted-firmare](https://github.com/renesas-rcar/arm-trusted-firmware)
+Renesas repository) depending on the
+time of productions. Apertis doesn't currently supply builds for those
 components (hence the requirement to already have that setup). The following
 instructions assume an IPL and Secure monitor revision newer than 1.0.10

@@ -90,10 +85,10 @@ The following table shows the file to get for the various types of boards:

 | Hardware                       | u-boot path                                                                                                                                       |
 | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| R-car Starter Kit Pro (M3)     | [m3ulcb/u-boot-elf.srec](https://images.apertis.org/release/v2021dev1/v2021dev1.0/firmware/u-boot/m3ulcb/u-boot-elf.srec)                         |
-| R-car Starter Kit Premier (H3) | [h3ulcb/u-boot-elf.srec](https://images.apertis.org/release/v2021dev1/v2021dev1.0/firmware/u-boot/h3ulcb/u-boot-elf.srec)                         |
-| R-car Salvator-X H3            | [r8a7795_salvator-x/u-boot-elf.srec](https://images.apertis.org/release/v2021dev1/v2021dev1.0/firmware/u-boot/r8a7795_salvator-x/u-boot-elf.srec) |
-| R-car Salvator-X M3            | [r8a7796_salvator-x/u-boot-elf.srec](https://images.apertis.org/release/v2021dev1/v2021dev1.0/firmware/u-boot/r8a7796_salvator-x/u-boot-elf.srec) |
+| R-car Starter Kit Pro (M3)     | [r8a7796_ulcb/u-boot-elf.srec](https://images.apertis.org/release/v2021dev3/v2021dev3.0/firmware/u-boot/r8a7796_ulcb/u-boot-elf.srec)             |
+| R-car Starter Kit Premier (H3) | [r8a7795_ulcb/u-boot-elf.srec](https://images.apertis.org/release/v2021dev3/v2021dev3.0/firmware/u-boot/r8a7795_ulcb/u-boot-elf.srec)             |
+| R-car Salvator-X H3            | [r8a7795_salvator-x/u-boot-elf.srec](https://images.apertis.org/release/v2021dev3/v2021dev3.0/firmware/u-boot/r8a7795_salvator-x/u-boot-elf.srec) |
+| R-car Salvator-X M3            | [r8a7796_salvator-x/u-boot-elf.srec](https://images.apertis.org/release/v2021dev3/v2021dev3.0/firmware/u-boot/r8a7796_salvator-x/u-boot-elf.srec) |

 To flash first configure the dip switches on the board to boot into the
 monitor. The exact configuration depends on the board and can be found in the
@@ -128,6 +123,12 @@ and reset the board. To do this on the boards currently availble to us:
 | Starter Kit Premier | SW6[ALL]=ON (this enables DDR3200)                       |
 | Salvator-X H3       | SW10\[5\]=ON, SW10\[6\]=ON, SW10\[7\]=OFF, SW10\[8\]=OFF |

+It is recommended to reset the U-Boot environment after flashing new version of bootloader.
+Stop in U-Boot prompt and execute commands:
+
+    setenv default -a
+    saveenv
+
 After reset the board should now boot Apertis from SD card automatically.

 ### Flashing image to eMMC
@@ -201,11 +202,11 @@ low is off).
  - In case if the boot has stopped after loading the kernel, initramfs
    and dtb with string `Starting kernel ...`

-Please check the values of `kernel_addr_r` and `ramdisk_addr_r` -- there
-should be enough space to load the kernel.
+    Check the values of `kernel_addr_r` and `ramdisk_addr_r` -- there
+    should be enough space to load the kernel.

-Probably you need to increase `ramdisk_addr_r` value to avoid
-overlapping of the kernel in memory. For example:
+    Probably you need to increase `ramdisk_addr_r` value to avoid
+    overlapping of the kernel in memory. For example:

-    kernel_addr_r=0x48080000
-    ramdisk_addr_r=0x4A000000
+        kernel_addr_r=0x48080000
+        ramdisk_addr_r=0x4A000000
--- a/content/release/v2021pre/releasenotes.md
+++ b/content/release/v2021pre/releasenotes.md
@@ -126,21 +126,6 @@ top-level `variables:` section.

 ## Build and integration

-### Dynamic KVM/UML backend selection in Debos
-
-During the v2021dev1 release cycle an
-[alternative backend for the Debos image builder]({{< ref "release/v2021dev1/releasenotes.md#gitlabci-based-image-building-pipeline-technology-preview" >}})
-using UML rather than KVM was developed to make our build pipeline more
-cloud-friendly, since KVM is often not available on machines provided by
-cloud providers. Unfortunately UML is by design quite slower than
-hardware-assisted KVM and this introduced a performance regression for
-developers using machines with KVM virtualization available.
-
-In this cycle the UML backend was landed to the upstream main branch, adding
-automatic backend selection: Debos is now able to use KVM if available and fall
-back to UML in other cases without any user intervention, giving the best
-performance available.
-
 ### Builds orchestrator

 Since the switch to GitLab all the pipelines producing the nightly artifacts
@@ -247,6 +232,22 @@ the Mildenhall compositor:

    sudo sed -i -e 's|Exec=/usr/bin/mildenhall|Exec=/usr/bin/env GBM_ALWAYS_SOFTWARE=1 /usr/bin/mildenhall|' /etc/xdg/user-session-launcher/session.launcher

+#### OSTree offline update bundle format change
+
+The upstream `libostree` 2020.7 version supports two different formats for
+static delta bundles, as used for offline updates: the old one without signed
+metadata and a new one which also signs the superblock metadata to ensure it
+can be trusted.
+
+Support for signed metadata was first introduced in Apertis with the v2021dev2
+release and was [later upstreamed](https://github.com/ostreedev/ostree/pull/1985).
+
+However, during the upstreaming process the format has changed and Apertis now
+aligns to the upstream format.
+
+This means that signed bundles created with the OSTree version from the v2021
+development releases won't be accepted by this release.
+
 ### Deprecations

 During this release cycle we have continued to mark obsolete or

--- a/content/release/v2022dev0/releasenotes.md
+++ b/content/release/v2022dev0/releasenotes.md
--- a/content/release/v2022dev1/release_schedule.md
+++ b/content/release/v2022dev1/release_schedule.md
+++
+date = "2020-12-23"
+weight = 100
+
+title = "v2022dev1 Release schedule"
+++
+
+The v2022dev1 release cycle started in January 2021.
+
+| Milestone                                                                                                | Date              |
+| -------------------------------------------------------------------------------------------------------- | ----------------- |
+| Start of release cycle                                                                                   | 2020-01-01        |
+| Soft feature freeze: end of feature proposal and review period                                           | 2021-02-19        |
+| Soft code freeze/hard feature freeze: end of feature development for this release, only bugfixes allowed | 2021-03-10        |
+| Release candidate 1 (RC1)/hard code freeze: no new code changes may be made after this date              | 2021-03-17        |
+| RC testing                                                                                               | 2021-03-18..03-24 |
+| v2022dev1 release                                                                                          | 2021-03-25        |
+
+If the release candidate 1 does not successfully pass all required
+tests, then the issues will be fixed and a new release candidate will be
+re-tested. This would delay the release, which would be reflected on
+this page.
+
+## See also
+
+  - [Roadmap]( {{< ref "/roadmap.md" >}} )
+  - Previous [release schedules]( {{< ref "/policies/releases.md" >}} ) and
+    more information about the timeline
--- a/data/releases.toml
+++ b/data/releases.toml
-#[Development]
-#version = "v2022dev0"
-#revision = "0"
+[Development]
+version = "v2022dev0"
+revision = "0"

 [Preview]
 # When promoting this to stable add arm64 target on download page
No results found