Gitlab maintenance activity starting at 1700 CET, Friday 15th of October !!!

  1. 13 Oct, 2021 3 commits
  2. 09 Oct, 2021 1 commit
  3. 07 Oct, 2021 3 commits
  4. 30 Sep, 2021 1 commit
  5. 29 Sep, 2021 8 commits
  6. 28 Sep, 2021 3 commits
    • Zygmunt Krynicki's avatar
      Makefile: use SystemdUnit template for systemd units · 345b5118
      Zygmunt Krynicki authored
      This ensures that the install location is correct and automatic.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <>
    • Zygmunt Krynicki's avatar
      .zmk-modules: add template for installing systemd units · a579b52e
      Zygmunt Krynicki authored
      Systemd units are a thin wrapper to the InstallUninstall template. Units
      can be either system-wide (default) or user-session (by setting
      $(unit).IsUser to non-empty value). The InstallDir is set to the
      appropriate location for the unit type and is obtained by querying
      pkg-config systemd module.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <>
    • Zygmunt Krynicki's avatar
      .zmk-modules: add template for using pkg-config · 2731bf9a
      Zygmunt Krynicki authored
      The new PkgConfig template uses PkgConfig.Cmd, by default the
      pkg-config executable found on PATH, to check availability of
      pkg-config modules.
      Each module must have the $(module).AtLeastVersion variable defined, the version
      check is checked at compile time but is not enforced. The outcome of the
      check is stored in PkgConfig.Modules.$(module).Status and is one of
      "sufficient", "outdated" or "missing".
      Each module that is not missing will have a number of standard variables
      populated under the PkgConfig.Modules.$(module) namespace, those are
      .Version, .Cflags, .CflagsOnlyI, .CflagsOnlyOther, .Libs,
      .LibsOnlyLowerL, .LibsOnlyL and .LibsOnlyOther.
      In addition a module may also have any number of module variable names
      listed in $(module).Variables. Those are resolved using pkg-config
      --variable= and are available under the namespace
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <>
  7. 24 Sep, 2021 1 commit
    • Zygmunt Krynicki's avatar
      boot/piboot: use $(system)/usr/lib/sysota/boot-assets · a4f73996
      Zygmunt Krynicki authored
      The effective change is from $(system)/boot to
      $(system)/usr/lib/sysota/boot-assets. A small slice of code and tests
      are affected.
      After discussing the boot asset location with Andrei we've decided to
      switch away from $(system)/boot - namely the boot directory in the
      system partition to the aforementioned new location under
      SystemOTA-specific directory.
      The rationale for that is comprised of several observations:
      1) The /boot directory is not synonymous to the $(boot) partition.
      The contents of the boot partition are what SystemOTA needs but the
      content of the /boot directory is platform specific and, in fact, there
      are already platforms where those are not identical. By choosing a new,
      explicit location, that is specific to SystemOTA update process, we
      avoid this problem entirely.
      2) SystemOTA uses a custom slot-{a,b}/ directory structure in $(boot).
      The exact details of how SystemOTA manages the boot partition may change
      over time but in any case, are a custom extension that is not widely
      We had an existing design problem that $(boot), as it came out of the
      build system, was not really representative of the $(boot) partition
      after several (or even the first) updates. Most clearly, the slot
      structure is not represented there at all.
      There are several ways we could have addressed that: by teaching the
      build system about SystemOTA specific (and perhaps platform specific)
      layout, by creating a tool which encapsulates that knowledge and build
      out of SystemOTA tree or by ignoring it.
      We had the same problem with boot assets inside the image, should it
      have the slot structure? Should it be identical to the boot assets on a
      vanilla system on first boot?
      The solution we chose is to avoid the problem entirely and avoid the
      need for special tooling. This is how it works.
      The build system produces regular boot partition without any special
      sauce. The build system has a small SystemOTA specific logic, to copy
      everything present in the $(boot) partition to the $(system) partition,
      as explained above. This is also implemented in meta-ohos by [1].
      Most importantly this has the following property: there is no more need
      to pre-process the image or have a special, and perhaps fragile, first
      boot which re-organizes the critical boot partition.
      Instead, on the first update, the boot protocol can remove up assets
      that underwent slotted duplication (like the kernel) and leave
      everything else (like firmware files) intact. In other words, on the
      first update, after it succeeds and we start to clean up, we can remove
      files that we are certain not to be needed anymore. This is also an
      entirely *optional* step. It can be skipped or aborted mid-way without
      any consequences.
      3) Using a generic location like /usr/lib/boot-assets is risky
      While it is tempting to offer standardization, we believe this step is
      premature. Using a directory specific to the OTA project allows us to
      experiment and make mistakes at a smaller scope.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <>
  8. 16 Sep, 2021 13 commits
  9. 15 Sep, 2021 1 commit
  10. 14 Sep, 2021 1 commit
  11. 13 Sep, 2021 5 commits