Go to file
Lars Niesen 22ae80d45a
!92 Add meta-intel layer
Add meta-intel intel layer to build for the intel cpu
board configuration.
2023-09-23 23:36:51 +02:00
dev !26 Add upstream changes to UID and GID 2023-09-23 17:40:08 +02:00
meta-caros/conf !92 Add meta-intel layer 2023-09-23 23:36:51 +02:00
.gitignore #20 map/deploy every deployable folders 2023-09-13 09:52:54 +02:00
default.xml !92 Add meta-intel layer 2023-09-23 23:36:51 +02:00
LICENSE !14 Add Authors into the licensefile 2023-09-21 18:46:02 +02:00
NOTICE Implement basic yocto build setup based on protos from jhnc-oss 2023-07-12 23:46:17 +02:00
README.md #1 & #2 Add colaboration rules to the readme 2023-08-25 20:56:28 +02:00
Roadmap.md #25 Add draft of the planned Roadmap 2023-09-13 07:41:23 +00:00

CaROS

Car Realtime Operating System.

A yocto base distro for DIY car radio

The CaROS specific software is found in meta-caros

Description

Setup

Preliminaries

Install required packages:

  • podman

Get yocto-build

git clone git@git.larsniesen.de:caros/caros.git

User Namespace Mapping

Ensure, that /etc/subgid and /etc/subuid contain corresponding and sane entries for your account (podman run user). If not you might need to run the following setup script (requires restart):

$ sudo ./dev/AddUserToSubgidAndSubuid.sh

Start development build container

$ ./dev/bootstrap.sh [--deploy] [--sstate]

By adding the parameter --deploy, bootstraph.sh maps a deploy folder into the build container. Built RPMs will be placed in this folder.

The parameter --sstate maps the build cache directory. This allows the cache to be preserved when the container is closed thus significantly reducing build time.

You will end up in the yocto build container as user yocto e.g.:

[yocto@1453b5f0ab01 build]$

Collaboration

Working with branches

Every contributor should use his/her initials (eg. Max Mustermann uses 'mm') as the branch prefix. After the prefix comes the issue ID and a short name describing the work.

The branch of Max Mustermann regarding the issue "#13 Integrate Fancy UI into the new web server" should be named:

mm/13-integrate-new-web-ui

Pull requests

The pull request is to be opened after testing the branch feature. The exception to this are draft PRs

Before merging each PR needs to be reviewed from at least one other contributor

Merging

Merges are to be done the following:

  1. Update main.
$ git pull origin
  1. Rebase main onto your feature branches. In your feature branch do:
$ git rebase origin/main
  1. Test Again if the rebase broke something.
  2. Squash your commits into one.
$ git rebase -i HEAD~<num of commits>

In the now open editor replace pick with squash on all of your commits except the first. After that quit the editor and another editor should pop up. Now enter the new commit message. The commit message should look like this:

<issue id>: Description

For the above example it would be:

13: Integrate the new web-UI to improve the experience for new users.

The Description should be why the commit was made and not what the commit does.

  1. Now we add the hash at the start of the commit with:
git commit --amend -m "#13: Integrate the new web-UI to improve the experience for new users."

The amend flag lets you change your last commit message. You have to enter your complete commit message but with a hash at the start.

  1. Now force push your branch to the remote.
$ git push --force
  1. Fast-forward merge on GitLab without merge commit.

For those who are not comfortable with git rebase please follow these steps. It is still recommended to do the squashing on the terminal.

  1. Update main.
$ git pull origin/main
  1. Rebase main onto your feature branches. In your feature branch do:
$ git rebase origin/main
  1. Test Again if the rebase broke something.

  2. Now force push your branch to the remote.

$ git push --force
  1. In the PR now fast-forward merge with squashing and without merge commit.