Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • eclipse/oniro-core/oniro
  • landgraf/oniro
  • zyga/oniro
  • mrybczyn/oniro
  • agherzan/oniro
  • pcoval/oniro
  • tony3oo3/oniro
  • stefanschmidt/oniro
  • waykovalenko/oniro
  • bero/oniro
  • esben/oniro
  • robertd/oniro
  • pidge/oniro
  • shettygururaj/oniro
  • thierrye/oniro
  • sradakovi/oniro
  • dricci783/oniro
  • ektor5/oniro
  • fldn/oniro
  • lucafavaretto/oniro
  • lucazizolfi/oniro
  • artemkondratiuk/oniro
  • lucaseri/oniro
  • gwozdzcfs/oniro
  • kristis/oniro
  • brgl/oniro
  • heurtemattes/oniro
  • idlethread/oniro
  • lquach/oniro
  • ghassaneben/oniro
  • heurtemattes/oniro-bitbake
  • kzarka/oniro
  • heurtemattes/oniro-migration
  • pastanki/oniro
  • malowe/oniro
  • chaseqi/oniro
  • mrfrank/oniro
37 results
Show changes
Commits on Source (126)
26 additional commits have been omitted to prevent performance issues.
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 866 additions and 753 deletions
.gitignore
View file @ 9936330f
......@@ -6,3 +6,4 @@ docs/build
*.pyc
*.pyo
*.swp
*~
.gitlab-ci.yml
View file @ 9936330f
This diff is collapsed.
.gitlab/issue_templates/Bug.md
View file @ 9936330f
<!--
SPDX-FileCopyrightText: Huawei Inc.
SPDX-License-Identifier: MIT
-->
## The module affected
## What is the action to reproduce the bug?
......
.oniro-ci/build-generic.yaml
View file @ 9936330f
......@@ -330,88 +330,6 @@
# Avoid pulling in any artifacts from the previous stage.
dependencies: []
.publish-rauc-bundle-to-hawkbit:
image: zyga/hawkbitctl:latest-ubuntu
# Use the deploy stage so that we only publish bundles to HawkBit if and only
# if all the bundles built in their stage completed successfully. This delays
# publishing to ensure that we have a consistent set and not some partial set
# when something failed to build.
stage: deploy
variables:
# Those variables have to be provided by specialized jobs.
CI_ONIRO_HAWKBIT_SWMOD_NAME: ""
CI_ONIRO_HAWKBIT_DS_NAME: ""
CI_ONIRO_RAUC_BUNDLE_NAME: ""
MACHINE: ""
script:
- set -e
- test -n "${CI_ONIRO_HAWKBIT_SWMOD_NAME:-}" || (
echo "precondition failed - CI_ONIRO_HAWKBIT_SWMOD_NAME is not set."
&& echo "It should be set to the name of the HawkBit software module"
&& exit 1 )
- test -n "${CI_ONIRO_HAWKBIT_DS_NAME:-}" || (
echo "precondition failed - CI_ONIRO_HAWKBIT_DS_NAME is not set."
&& echo "It should be set to the name of the HawkBit distribution set."
&& exit 1 )
- test -n "${CI_ONIRO_RAUC_BUNDLE_NAME:-}" || (
echo "precondition failed - CI_ONIRO_RAUC_BUNDLE_NAME is not set."
&& echo "It should be set to the name of the Yocto recipe constructing the RAUC bundle."
&& exit 1 )
- test -n "${MACHINE:-}" || (
echo "precondition failed - MACHINE is not set."
&& echo "It should be set to the name of the Yocto machine name."
&& exit 1 )
- test -n "${HAWKBIT_URL:-}" || (
echo "precondition failed - HAWKBIT_URL is not set."
&& exit 1 )
- test -n "${HAWKBIT_USERNAME:-}" || (
echo "precondition failed - HAWKBIT_USERNAME is not set."
&& exit 1 )
- test -n "${HAWKBIT_PASSWORD:-}" || (
echo "precondition failed - HAWKBIT_PASSWORD is not set."
&& echo "It should be set with a protected and masked variable."
&& exit 1 )
- test -L "${CI_PROJECT_DIR}/artifacts/images/${MACHINE}/${CI_ONIRO_RAUC_BUNDLE_NAME}-${MACHINE}.raucb" || (
echo "precondition failed - bundle file is either missing or is not a symbolic link."
&& find "${CI_PROJECT_DIR}/artifacts"
&& exit 1 )
- BUNDLE_FILE="$(readlink "${CI_PROJECT_DIR}/artifacts/images/${MACHINE}/${CI_ONIRO_RAUC_BUNDLE_NAME}-${MACHINE}.raucb")"
- test -n "$BUNDLE_FILE" || (
echo "Cannot compute BUNDLE_FILE"
&& ls -l "${CI_PROJECT_DIR}/artifacts/images/${MACHINE}/${CI_ONIRO_RAUC_BUNDLE_NAME}-${MACHINE}.raucb"
&& exit 1 )
- BUNDLE_VERSION="$(echo "$BUNDLE_FILE" | awk 'BEGIN { RS = "-" } /.*\.raucb/ { sub(".raucb", "", $NF); print $NF }')"
- test -n "$BUNDLE_VERSION" || (
echo "Cannot compute BUNDLE_VERSION"
&& echo "BUNDLE_FILE=$BUNDLE_FILE"
&& exit 1 )
# TODO: create or find sw mod type for SysOTA + RAUC bundle
- hawkbitctl create software-module
-name "$CI_ONIRO_HAWKBIT_SWMOD_NAME"
-version "$BUNDLE_VERSION"
-type os
-vendor "Onrio"
-description "Automatic build from Oniro CI"
# TODO: create or find ds type for MACHINE and OS
- hawkbitctl create distribution-set
-name "$CI_ONIRO_HAWKBIT_DS_NAME"
-version "$BUNDLE_VERSION"
-type os
-modules "$CI_ONIRO_HAWKBIT_SWMOD_NAME:$BUNDLE_VERSION"
-description "Automatic build from Oniro CI"
- hawkbitctl upload
-m "$CI_ONIRO_HAWKBIT_SWMOD_NAME:$BUNDLE_VERSION"
-a "${CI_PROJECT_DIR}/artifacts/images/${MACHINE}/$(readlink "${CI_PROJECT_DIR}/artifacts/images/${MACHINE}/${CI_ONIRO_RAUC_BUNDLE_NAME}-${MACHINE}.raucb")"
rules:
# Publishing is done only for scheduled builds
- if: '$CI_PIPELINE_SOURCE == "schedule"'
# Run the job when a tag is placed.
- if: '$CI_COMMIT_TAG'
# For merge requests, the publishing is optional and can be triggered manually.
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: manual
allow_failure: true
.build-zephyr-image:
extends: .build-image
variables:
......
.oniro-ci/containers/bitbake-builder/Dockerfile
View file @ 9936330f
......@@ -27,7 +27,7 @@ RUN apt-get update -qq \
gawk git sudo wget language-pack-en-base time locales python-is-python3 \
python3-distutils python3-pip libssl-dev iproute2 iputils-ping curl jq \
lz4 zstd iptables\
&& eatmydata apt-get install -qq -y 'ca-certificates=20211016~20.04.1' \
&& eatmydata apt-get install -qq -y 'ca-certificates=20211016ubuntu0.20.04.1' \
&& eatmydata apt-get clean && rm -rf /var/lib/apt/lists/*
RUN locale-gen
RUN pip3 install anybadge
......
.oniro-ci/containers/dco-check/Dockerfile
View file @ 9936330f
......@@ -23,5 +23,5 @@ ARG DEBIAN_FRONTEND="noninteractive"
RUN apt-get update -qq \
&& apt-get install -y eatmydata \
&& eatmydata apt-get install -qq -y 'dco-check=0.1.1-1+ostc2' \
&& eatmydata apt-get install -qq -y 'ca-certificates=20210119~20.04.2' \
&& eatmydata apt-get install -qq -y 'ca-certificates=20211016ubuntu0.20.04.1' \
&& eatmydata apt-get clean && rm -rf /var/lib/apt/lists/*
.oniro-ci/containers/docs-builder/Dockerfile
View file @ 9936330f
......@@ -13,7 +13,7 @@ RUN apt-get update -qq \
git-repo git git-lfs \
python3-pip python3-sphinx python3-sphinx-rtd-theme python3-recommonmark \
python3-sphinxcontrib.plantuml \
&& eatmydata apt-get install -qq -y 'ca-certificates=20211016~20.04.1' \
&& eatmydata apt-get install -qq -y 'ca-certificates=20211016ubuntu0.20.04.1' \
&& eatmydata apt-get clean && rm -rf /var/lib/apt/lists/*
# We need to fix the version here to avoid pulling docutils 0.18 which is
......
.oniro-ci/containers/reuse/Dockerfile
View file @ 9936330f
......@@ -23,5 +23,5 @@ ARG DEBIAN_FRONTEND="noninteractive"
RUN apt-get update -qq \
&& apt-get install -y eatmydata \
&& eatmydata apt-get install -qq -y reuse=0.13.0-1 'spread=0~20201124-1+ohos3' \
&& eatmydata apt-get install -qq -y 'ca-certificates=20210119~20.04.2' \
&& eatmydata apt-get install -qq -y 'ca-certificates=20211016ubuntu0.20.04.1' \
&& eatmydata apt-get clean && rm -rf /var/lib/apt/lists/*
.oniro-ci/containers/ubuntu-checkbox/Dockerfile
View file @ 9936330f
# SPDX-FileCopyrightText: Huawei Inc.
#
# SPDX-License-Identifier: MIT
FROM ubuntu:20.04
ARG DEBIAN_FRONTEND="noninteractive"
......
.oniro-ci/machines-and-flavours.yaml
View file @ 9936330f
......@@ -243,15 +243,6 @@ zephyr-qemu-cortex-m3-twister-gcc:
zephyr-qemu-cortex-m3-twister-clang:
extends: [.zephyr-qemu-cortex-m3-twister, .toolchain-clang, .broken]
.zephyr-96b-avenger:
extends: .build-zephyr-image
variables:
MACHINE: 96b-avenger96
zephyr-96b-avenger-gcc:
extends: [.zephyr-96b-avenger, .toolchain-gcc]
zephyr-96b-avenger-clang:
extends: [.zephyr-96b-avenger, .toolchain-clang, .broken]
.zephyr-nrf52840dk-nrf52840:
extends: .build-zephyr-image
variables:
......
.oniro-ci/test-generic.yaml
View file @ 9936330f
......@@ -50,7 +50,10 @@
fi
script:
# Build callback URL for the "report" job
- curl --silent "$CI_API_V4_URL/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/jobs?per_page=100" > jobs-manual.json
- |
curl --silent \
--header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \
"$CI_API_V4_URL/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/jobs?per_page=100" > jobs-manual.json
- job_id="$(jq -r ".[] | select(.name == \"$CI_REPORT_JOB_NAME\") | .id" jobs-manual.json)"
- build_job_id="$(jq -r ".[] | select(.name == \"$CI_BUILD_JOB_NAME\") | .id" jobs-manual.json)"
- update_job_id="$(jq -r ".[] | select(.name == \"$CI_UPDATE_JOB_NAME\") | .id" jobs-manual.json)"
......
.reuse/dep5 0 → 100644
View file @ 9936330f
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Files: meta-oniro-staging/recipes-devtools/gcc/gcc_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-12.2.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-common.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-configure-common.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-cross_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-cross-canadian_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-cross-canadian.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-cross.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-crosssdk_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-crosssdk.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-multilib-config.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-runtime_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-runtime.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-sanitizers.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-shared-source.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-source_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/gcc-source.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-target.inc
meta-oniro-staging/recipes-devtools/gcc/gcc-testsuite.inc
meta-oniro-staging/recipes-devtools/gcc/libgcc_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/libgcc-common.inc
meta-oniro-staging/recipes-devtools/gcc/libgcc-initial_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/libgcc-initial.inc
meta-oniro-staging/recipes-devtools/gcc/libgcc.inc
meta-oniro-staging/recipes-devtools/gcc/libgfortran_12.2.bb
meta-oniro-staging/recipes-devtools/gcc/libgfortran.inc
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe files copied from Poky at https://git.yoctoproject.org/poky,
meta/recipes-devtools/gcc. LICENSE file of Poky project states:
"All metadata is MIT licensed unless otherwise stated."
Files: meta-oniro-staging/recipes-devtools/gcc/gcc/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0002-gcc-poison-system-directories.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0003-64-bit-multilib-hack.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0004-Pass-CXXFLAGS_FOR_BUILD-in-a-couple-of-places-to-avo.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0005-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0006-cpp-honor-sysroot.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0007-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0008-libtool.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0009-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0010-Use-the-multilib-config-files-from-B-instead-of-usin.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0011-Avoid-using-libdir-from-.la-which-usually-points-to-.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0012-export-CPP.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0013-Ensure-target-gcc-headers-can-be-included.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0014-Don-t-search-host-directory-during-relink-if-inst_pr.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0015-libcc1-fix-libcc1-s-install-path-and-rpath.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0016-handle-sysroot-support-for-nativesdk-gcc.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0017-Search-target-sysroot-gcc-version-specific-dirs-with.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0018-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0019-Re-introduce-spe-commandline-options.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0020-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0021-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0022-mingw32-Enable-operation_not_supported.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0023-libatomic-Do-not-enforce-march-on-aarch64.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0024-Fix-install-path-of-linux64.h.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0025-Move-sched.h-include-ahead-of-user-headers.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/0026-rust-recursion-limit.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/hardcoded-paths.patch
meta-oniro-staging/recipes-devtools/gcc/gcc/prefix-map-realpath.patch
Copyright: OpenEmbedded Contributors
License: GPL-3.0-only WITH GCC-exception-3.1 AND GPL-3.0-only
Comment: Patch files for gcc copied from Poky at
https://git.yoctoproject.org/poky, meta/recipes-devtools/gcc/gcc.
LICENSE file of Poky project states:
"Source code included in tree for individual recipes (e.g. patches) are
under the LICENSE stated in the associated recipe (.bb file) unless
otherwise stated."
The LICENSE stated in gcc recipes is GPL-3.0-with-GCC-exception & GPLv3
Files: meta-oniro-staging/recipes-devtools/binutils/binutils_2.39.bb
meta-oniro-staging/recipes-devtools/binutils/binutils-2.39.inc
meta-oniro-staging/recipes-devtools/binutils/binutils-cross_2.39.bb
meta-oniro-staging/recipes-devtools/binutils/binutils-cross-canadian_2.39.bb
meta-oniro-staging/recipes-devtools/binutils/binutils-cross-canadian.inc
meta-oniro-staging/recipes-devtools/binutils/binutils-cross-testsuite_2.39.bb
meta-oniro-staging/recipes-devtools/binutils/binutils-cross.inc
meta-oniro-staging/recipes-devtools/binutils/binutils-crosssdk_2.39.bb
meta-oniro-staging/recipes-devtools/binutils/binutils.inc
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe files copied from Poky at https://git.yoctoproject.org/poky,
meta/recipes-devtools/binutils. LICENSE file of Poky project states:
"All metadata is MIT licensed unless otherwise stated."
Files: meta-oniro-staging/recipes-devtools/binutils/binutils/0001-binutils-crosssdk-Generate-relocatable-SDKs.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0003-binutils-nativesdk-Search-for-alternative-ld.so.conf.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0004-Point-scripts-location-to-libdir.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0005-don-t-let-the-distro-compiler-point-to-the-wrong-ins.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0006-warn-for-uses-of-system-directories-when-cross-linki.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0007-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0008-Use-libtool-2.4.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0009-Fix-rpath-in-libtool-when-sysroot-is-enabled.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0010-sync-with-OE-libtool-changes.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0011-Check-for-clang-before-checking-gcc-version.patch
meta-oniro-staging/recipes-devtools/binutils/binutils/0012-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch
Copyright: OpenEmbedded Contributors
License: GPL-3.0-only
Comment: Patch files for binutils copied from Poky at
https://git.yoctoproject.org/poky, meta/recipes-devtools/binutils/binutils.
LICENSE file of Poky project states:
"Source code included in tree for individual recipes (e.g. patches) are
under the LICENSE stated in the associated recipe (.bb file) unless
otherwise stated."
The LICENSE stated in binutils recipes is GPL-3.0-only
Files: meta-oniro-staging/recipes-devtools/libcoap/libcoap_4.3.0.bb
meta-oniro-staging/recipes-devtools/libcoap/libcoap/0001-coap_session.c-Balance-SESSIONS_ADD-and-SESSIONS_DEL.patch
meta-oniro-staging/recipes-devtools/libcoap/libcoap/0001-libcoap-Fix-gnu-configize-error.patch
meta-oniro-staging/recipes-devtools/libcoap/libcoap/run-ptest
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe and patch files for libcoab copied from OpenEmbedded at
https://git.openembedded.org/meta-openembedded,
meta-networking/recipes-devtools/libcoap. OpenEmbedded is licensed
under MIT license.
Files: meta-oniro-staging/recipes-containers/buildah/buildah_git.bb
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe file for buildah copied from meta-virtualization project at
https://git.yoctoproject.org/meta-virtualization,
recipes-containers/buildah.
README file of meta-virtualization project states:
"All metadata is MIT licensed unless otherwise stated."
Files: meta-oniro-staging/recipes-devtools/ninja/ninja/0001-feat-support-cpu-limit-by-cgroups-on-linux.patch
Copyright: Google Inc.
License: Apache-2.0
Comment: Patch for ninja backported from Ninja project at
https://github.com/ninja-build/ninja, commit 540be33
Copyright text left as found in the header of the patched file.
Files: meta-oniro-core/recipes-support/rauc-hawkbit-updater/rauc-hawkbit-updater/0001-hawkbit-client-do-not-pass-NULL-format-to-g_strdup_v.patch
Copyright: 2021-2022 Bastian Krause <bst@pengutronix.de>, Pengutronix
2018-2020 Lasse K. Mikkelsen <lkmi@prevas.dk>, Prevas A/S (www.prevas.com)
License: LGPL-2.1-only
Comment: Patch for rauc-hawkbit-updater backported from
https://github.com/rauc/rauc-hawkbit-updater, commit 439feee
Copyright text left as found in the header of the patched file.
Files: meta-oniro-staging/recipes-multimedia/libtiff/files/0001-fix-upstream-issue-352-heap-buffer-overflow-by-correcting-uint32t-underflow.patch
Copyright: 1988-1997 Sam Leffler
1991-1997 Silicon Graphics, Inc.
Richard Nolde 2006-2010
License: libtiff
Comment: Patch for libtiff backported from Libtiff project at
https://gitlab.com/libtiff/libtiff, commit bcf28bb7
Copyright text left as found in the header of the patched file.
CONTRIBUTING.md
View file @ 9936330f
......@@ -4,19 +4,30 @@ SPDX-FileCopyrightText: Huawei Inc.
SPDX-License-Identifier: CC-BY-4.0
-->
- [Gitlab Contributions](#gitlab-contributions)
- [Overview](#overview)
- [Commit Guidelines](#commit-guidelines)
- [Contributions to Documentation](#contributions-to-documentation)
- [REUSE Compliance](#reuse-compliance)
- [SPDX Information and REUSE Standard](#spdx-information-and-reuse-standard)
- [SPDX Header Example](#spdx-header-example)
- [Substantial Contributions](#substantial-contributions)
- [DCO sign-off](#dco-sign-off)
- [Overview](#overview-1)
- [Developer Certificate of Origin](#developer-certificate-of-origin)
- [`oniro`-specific contributions process and guidelines](#oniro-specific-contributions-process-and-guidelines)
- [Eclipse Contributor Agreement](#eclipse-contributor-agreement)
- <a href="#eclipse-contributor-agreement" id="toc-eclipse-contributor-agreement">Eclipse Contributor Agreement</a>
- <a href="#gitlab-contributions" id="toc-gitlab-contributions">Gitlab Contributions</a>
- <a href="#overview" id="toc-overview">Overview</a>
- <a href="#git-setup" id="toc-git-setup">Git setup</a>
- <a href="#commit-guidelines" id="toc-commit-guidelines">Commit Guidelines</a>
- <a href="#contributions-to-documentation" id="toc-contributions-to-documentation">Contributions to Documentation</a>
- <a href="#creating-merge-requests" id="toc-creating-merge-requests">Creating merge requests</a>
- <a href="#reuse-compliance" id="toc-reuse-compliance">REUSE Compliance</a>
- <a href="#spdx-information-and-reuse-standard" id="toc-spdx-information-and-reuse-standard">SPDX Information and REUSE Standard</a>
- <a href="#spdx-header-example" id="toc-spdx-header-example">SPDX Header Example</a>
- <a href="#dep5-files-paragraph-examples" id="toc-dep5-files-paragraph-examples">DEP5 "Files" Paragraph Examples</a>
- <a href="#substantial-contributions" id="toc-substantial-contributions">Substantial Contributions</a>
- <a href="#dco-sign-off" id="toc-dco-sign-off">DCO sign-off</a>
- <a href="#overview-1" id="toc-overview-1">Overview</a>
- <a href="#docs_dco" id="toc-docs_dco">Developer Certificate of Origin</a>
- <a href="#oniro-specific-contributions-process-and-guidelines" id="toc-projectname-specific-contributions-process-and-guidelines"><code>oniro</code>-specific contributions process and guidelines</a>
# Eclipse Contributor Agreement
Before your contribution can be accepted by the project team, contributors must electronically sign the [Eclipse Contributor Agreement (ECA)](http://www.eclipse.org/legal/ECA.php).
Commits must have a Signed-off-by field in the footer indicating that the author is aware of the terms by which the contribution has been provided to the project. Also, an associated Eclipse Foundation account needs to be in place with a signed Eclipse Contributor Agreement on file. These requirements are enforced by the Eclipse Foundation infrastructure tooling.
For more information, please see the [Eclipse Committer Handbook](https://www.eclipse.org/projects/handbook/#resources-commit).
# Gitlab Contributions
......@@ -24,6 +35,19 @@ SPDX-License-Identifier: CC-BY-4.0
Oniro Project handles contributions as [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) to relevant repositories part of the Oniro Project [GitLab instance](https://gitlab.eclipse.org/eclipse/oniro-core). The flow for handling that is classic: fork-based merge requests. This means that once you have an account, you can fork any repository, create a branch with proposed changes and raise a merge request against the forked repository. More generic information you can find on the Gitlab's documentation as part of ["Merge requests workflow"](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html).
## Git setup
Clone your fork locally, enter its directory and set:
``` bash
$ git config --local user.email <your_eclipse_account_email>
$ git config --local user.name <your_eclipse_full_name>
```
To push and pull over HTTPS with Git using your account, you must set a password or [a Personal Access Token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) .
If you want to push or pull repositories using SSH, you have to [add a SSH key](https://docs.gitlab.com/ee/user/ssh.html) to your profile.
## Commit Guidelines
<div class="note">
......@@ -42,39 +66,39 @@ At its core, contributing to the Oniro Project project means *wrapping* your wor
To achieve this, we maintain the following commit guidelines:
- Each commit should be able to stand by itself providing a building block as part of the MR.
- A good balance of granularity with scoped commits helps to handle backports (e.g. cherry-picks) and also improves the ability to review smaller chunks of code taking commit by commit.
- Changes that were added on top of changes introduced in the MR, should be squashed into the initial commit.
- For example, a MR that introduced a new build system recipe and, as a separate commit, fixed a build error in the initial recipe. The latter commit should be squashed into the initial commit.
- For example, a MR introducing a new docs chapter and also adding, as a separate commit, some typo fixes. The latter commits should be squashed into the initial commit.
- There is a small set of exceptions to this rule. All these exceptions gravitate around the case where an MR, even if it provides multiple commits in the same scope (for example, to the same build recipe), each of the commits has a very specific purpose.
- For example, a line formating change followed by a chapter addition change in the same documentation file.
- Also, it can be the case of two functional changes that are building blocks in the same scope.
- Another example where commits are not to be squashed is when having a commit moving the code and a commit modifying the code in the new location.
- Make sure you clean your code of trailing white spaces/tabs and that each file ends with a new line.
- Avoid *merge* commits as part of your MR. Your commits should be rebased on top of the *HEAD* of the destination branch.
- Each commit should be able to stand by itself providing a building block as part of the MR.
- A good balance of granularity with scoped commits helps to handle backports (e.g. cherry-picks) and also improves the ability to review smaller chunks of code taking commit by commit.
- Changes that were added on top of changes introduced in the MR, should be squashed into the initial commit.
- For example, a MR that introduced a new build system recipe and, as a separate commit, fixed a build error in the initial recipe. The latter commit should be squashed into the initial commit.
- For example, a MR introducing a new docs chapter and also adding, as a separate commit, some typo fixes. The latter commits should be squashed into the initial commit.
- There is a small set of exceptions to this rule. All these exceptions gravitate around the case where an MR, even if it provides multiple commits in the same scope (for example, to the same build recipe), each of the commits has a very specific purpose.
- For example, a line formating change followed by a chapter addition change in the same documentation file.
- Also, it can be the case of two functional changes that are building blocks in the same scope.
- Another example where commits are not to be squashed is when having a commit moving the code and a commit modifying the code in the new location.
- Make sure you clean your code of trailing white spaces/tabs and that each file ends with a new line.
- Avoid *merge* commits as part of your MR. Your commits should be rebased on top of the *HEAD* of the destination branch.
As mentioned above, *git log* becomes informally part of the documentation of the product. Maintaining consistency in its format and content improves debugging, auditing, and general code browsing. To achieve this, we also require the following commit message guidelines:
- The *subject* line (the first line) needs to have the following format: `scope: Title limited to 80 characters`.
- Use the imperative mood in the *subject* line for the *title*.
- The *scope* prefix (including the colon and the following whitespace) is optional but most of the time highly recommended. For example, fixing an issue for a specific build recipe, would use the recipe name as the *scope*.
- The *title* (the part after the *scope*) starts with a capital letter.
- The entire *subject* line shouldn't exceed 80 characters (same text wrapping rule for the commit body).
- The commit *body* separated by an empty line from the *subject* line.
- The commit *body* is optional but highly recommended. Provide a clear, descriptive text block that accounts for all the changes introduced by a specific commit.
- The commit *body* must not contain more than 80 characters per line.
- The commit message will have the commit message *trailers* separated by a new line from the *body*.
- Each commit requires at least a *Signed-off-by* trailer line. See more as part of the `/contributing/dco` document.
- All *trailer* lines are to be provided as part of the same text block - no empty lines in between the *trailers*.
- The *subject* line (the first line) needs to have the following format: `scope: Title limited to 80 characters`.
- Use the imperative mood in the *subject* line for the *title*.
- The *scope* prefix (including the colon and the following whitespace) is optional but most of the time highly recommended. For example, fixing an issue for a specific build recipe, would use the recipe name as the *scope*.
- The *title* (the part after the *scope*) starts with a capital letter.
- The entire *subject* line shouldn't exceed 80 characters (same text wrapping rule for the commit body).
- The commit *body* separated by an empty line from the *subject* line.
- The commit *body* is optional but highly recommended. Provide a clear, descriptive text block that accounts for all the changes introduced by a specific commit.
- The commit *body* must not contain more than 80 characters per line.
- The commit message will have the commit message *trailers* separated by a new line from the *body*.
- Each commit requires at least a *Signed-off-by* trailer line. See more as part of the `/contributing/dco` document.
- All *trailer* lines are to be provided as part of the same text block - no empty lines in between the *trailers*.
Additional commit message notes:
- Avoid using special characters anywhere in the commit message.
- Be succinct but descriptive.
- Have at least one *trailer* as part of each commit: *Signed-off-by*.
- You can automatically let `git` add the *Signed-off-by* by taking advantage of its `-s` argument.
- Whenever in doubt, check the existing log on the file (`<FILE>`) you are about to commit changes, using something similar to: `git log <FILE>`.
- Avoid using special characters anywhere in the commit message.
- Be succinct but descriptive.
- Have at least one *trailer* as part of each commit: *Signed-off-by*.
- You can automatically let `git` add the *Signed-off-by* by taking advantage of its `-s` argument.
- Whenever in doubt, check the existing log on the file (`<FILE>`) you are about to commit changes, using something similar to: `git log <FILE>`.
Example of a full git message:
......@@ -97,23 +121,36 @@ In terms of file format, the project unifies its documentation as `ReStructuredT
As a rule of thumb, anything that ends up compiled in the project documentation is to maintain the RestructuredText file format. Text files that are not meant to be compiled as part of the project's documentation can be written in [Markdown](https://daringfireball.net/projects/markdown/). For example, a repository `README` file can be written in Markdown as it doesn't end up compiled in the project-wide documentation.
### Creating merge requests
Once your changes have been pushed to your fork, you are ready to prepare a merge request.
1. Go to your repository in an internet browser.
2. Create a merge request by clicking `Merge Requests` on left toolbar and press `New merge request`. Add an explainable description and create a merge request. Alternatively, you can enter the website of your fork. You should see a message that you pushed your branch to the repository. In the same section you can press `Create merge request`.
3. Before merging, it has to be reviewed and approved by Oniro Project repository maintainers. Read their review and add any required changes to your merge request.
4. After you polish your merge request, the maintainers will run the pipelines which check if your changes do not break the project and approve them. If everything is correct, your work is merged to the main project. Remember that each commit of the merge request should be a minimum, self-contained building block.
# REUSE Compliance
## SPDX Information and REUSE Standard
All projects and files for an hosted project **MUST** be [REUSE](https://reuse.software/) compliant. REUSE requires SPDX information for each file, rules for which are as follows:
- Any new file must have a SPDX header (copyright and license).
- For files that don't support headers (for example binaries, patches etc.) an associated `.license` file must be included with the relevant SPDX information.
- Do not add Copyright Year as part of the SPDX header information.
- The general rule of thumb for the license of a patch file is to use the license of the component for which the patch applies.
- When modifying a file through this contribution process, you may (but don't have to) claim copyright by adding a copyright line.
- Never alter copyright statements made by others, but only add your own.
Some files will make an exception to the above rules as described below:
- Files for which copyright is not claimed and for which this information was not trivial to fetch (for example backporting patches, importing build recipes etc. when upstream doesn't provide the SPDX information in the first place)
- license files (for example `common-licenses` in bitbake layers)
- for files copyrighted by projects contributors (**"First Party Files"**):
- any new file MUST have a SPDX header (copyright and license);
- for files that don't support headers (for example binaries, patches etc.) an associated `.license` file MUST be included with the relevant SPDX information;
- do not add Copyright Year as part of the SPDX header information;
- the general rule for patch files is to use the MIT license and *not* the license of the component for which the patch applies - the latter solution would be error-prone and hard to manage and maintain in the long run, and there may be difficult-to-handle cases (what if the patches modifies multiple files in the same component - eg. gcc - which are subject to different licenses?);
- when modifying a file through this contribution process, you may (but don't have to) claim copyright by adding a copyright line;
- you MUST NOT alter copyright statements made by others, but only add your own;
- for files copyrighted by third parties and just added to the project by contributors, eg. files copied from other projects or back-ported patches (**"Third Party Files"**):
- if upstream files already have SPDX headers, they MUST be left unchanged;
- if upstream files do *not* have SPDX headers:
- the exact upstream provenance (repo, revision, path) MUST be identified;
- you MUST NOT add SPDX headers to Third Party Files;
- copyright and license information, as well as upstream provenance information (in the "Comment" section), MUST be stored in <span class="title-ref">.reuse/dep5</span> following [Debian dep5 specification](https://dep-team.pages.debian.net/deps/dep5/) (see examples below);
- you MUST NOT use wildcards (\*) in dep5 "Files" paragraphs even if Debian specs allow it: it may lead to unnoticed errors or inconsistencies in case of future file additions that may be covered by wildcard expressions even if they have a different license;
- in case of doubts or problems in finding the correct license and copyright information for Third Party Files, contributors may ask the project's Legal Team in the project mailing list <oniro-dev@eclipse.org>;
### SPDX Header Example
......@@ -127,6 +164,26 @@ Make sure all of your submitted new files have a licensing statement in the head
*/
```
### DEP5 "Files" Paragraph Examples
``` text
Files: meta-oniro-staging/recipes-containers/buildah/buildah_git.bb
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe file for buildah copied from meta-virtualization project at
https://git.yoctoproject.org/meta-virtualization,
recipes-containers/buildah.
README file of meta-virtualization project states:
"All metadata is MIT licensed unless otherwise stated."
Files: meta-oniro-staging/recipes-devtools/ninja/ninja/0001-feat-support-cpu-limit-by-cgroups-on-linux.patch
Copyright: Google Inc.
License: Apache-2.0
Comment: Patch for ninja backported from Ninja project at
https://github.com/ninja-build/ninja, commit 540be33
Copyright text left as found in the header of the patched file.
```
### Substantial Contributions
Therefore, if your contribution is only a patch directly applied to an existing file, then you are not required to do anything. If your contribution is an entire new project, or a substantial, copyrighted contribution, you **MUST** make sure that you do that following the [IP Policy](https://git.ostc-eu.org/oss-compliance/ip-policy/) and that you comply with REUSE standard to include the licensing information where they are required.
......@@ -216,14 +273,3 @@ Signed-off-by: Joe Developer <joe.developer@example.com>
Please note that by signing off the commit, you make a **legally binding
statement** that you certify as in the [DCO sign-off](#dco-sign-off) section.
# Eclipse Contributor Agreement
Before your contribution can be accepted by the project team, contributors must electronically sign the
[Eclipse Contributor Agreement (ECA)](http://www.eclipse.org/legal/ECA.php)
Commits that are provided by non-committers must have a Signed-off-by field in the footer indicating that the author is aware of the terms by which the contribution has been provided to the project.
The non-committer must additionally have an Eclipse Foundation account and must have a signed Eclipse Contributor Agreement (ECA) on file.
For more information, please see the [Eclipse Committer Handbook](https://www.eclipse.org/projects/handbook/#resources-commit)
LICENSES/GCC-exception-3.1.txt 0 → 100644
View file @ 9936330f
GCC RUNTIME LIBRARY EXCEPTION
Version 3.1, 31 March 2009
General information: http://www.gnu.org/licenses/gcc-exception.html
Copyright (C) 2009 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
This GCC Runtime Library Exception ("Exception") is an additional permission under section 7 of the GNU General Public License, version 3 ("GPLv3"). It applies to a given file (the "Runtime Library") that bears a notice placed by the copyright holder of the file stating that the file is governed by GPLv3 along with this Exception.
When you use GCC to compile a program, GCC may combine portions of certain GCC header files and runtime libraries with the compiled program. The purpose of this Exception is to allow compilation of non-GPL (including proprietary) programs to use, in this way, the header files and runtime libraries covered by this Exception.
0. Definitions.
A file is an "Independent Module" if it either requires the Runtime Library for execution after a Compilation Process, or makes use of an interface provided by the Runtime Library, but is not otherwise based on the Runtime Library.
"GCC" means a version of the GNU Compiler Collection, with or without modifications, governed by version 3 (or a specified later version) of the GNU General Public License (GPL) with the option of using any subsequent versions published by the FSF.
"GPL-compatible Software" is software whose conditions of propagation, modification and use would permit combination with GCC in accord with the license of GCC.
"Target Code" refers to output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase. Notwithstanding that, Target Code does not include data in any format that is used as a compiler intermediate representation, or used for producing a compiler intermediate representation.
The "Compilation Process" transforms code entirely represented in non-intermediate languages designed for human-written code, and/or in Java Virtual Machine byte code, into Target Code. Thus, for example, use of source code generators and preprocessors need not be considered part of the Compilation Process, since the Compilation Process can be understood as starting with the output of the generators or preprocessors.
A Compilation Process is "Eligible" if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC. For example, using non-GPL-compatible Software to optimize any GCC intermediate representations would not qualify as an Eligible Compilation Process.
1. Grant of Additional Permission.
You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.
2. No Weakening of GCC Copyleft.
The availability of this Exception does not imply any general presumption that third-party software is unaffected by the copyleft requirements of the license of GCC.
LICENSES/GPL-2.0-only.txt 0 → 100644
View file @ 9936330f
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the program's name and an idea of what it does. Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker.
signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice
LICENSES/GPL-3.0-only.txt 0 → 100644
View file @ 9936330f
This diff is collapsed.
LICENSES/LGPL-2.1-only.txt 0 → 100644
View file @ 9936330f
This diff is collapsed.
LICENSES/libtiff.txt 0 → 100644
View file @ 9936330f
Copyright (c) 1988-1997 Sam Leffler
Copyright (c) 1991-1997 Silicon Graphics, Inc.
Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that (i) the above copyright notices and this permission notice appear in all copies of the software and related documentation, and (ii) the names of Sam Leffler and Silicon Graphics may not be used in any advertising or publicity relating to the software without the specific, prior written permission of Sam Leffler and Silicon Graphics.
THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
README.md
View file @ 9936330f
......@@ -6,7 +6,7 @@ SPDX-License-Identifier: CC-BY-4.0
# Oniro Project
Welcome to the Oniro\* Project main git reposiotory! Oniro is an Eclipse
Welcome to the Oniro\* Project main git repository! Oniro is an Eclipse
Foundation project focused on the development of a distributed open source
operating system for consumer devices.
......
docs/build-flavours/zephyr-flavour.rst
View file @ 9936330f
......@@ -22,7 +22,6 @@ Supported machines (default in **bold**):
* **qemu-x86**
* qemu-cortex-m3
* 96b-avenger96 (96Boards Avenger96)
* arduino-nano-33-ble (Arduino Nano 33 BLE and Arduino Nano 33 BLE Sense)
Build steps example:
......

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent