Difference between revisions of "Repository Layout"

From WebOS-Ports
Jump to navigation Jump to search
(Created page with "== Overview == Right layers and branches/revs are always defined in webos-ports/webos/layers.txt and mcf is calling simplified oebb.sh (+layerman) script to checkout/update them...")
 
 
(30 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
 +
Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using Yocto 3.2 Gatesgarth release through testing (with LTS Qt 5.15) and Yocto 3.3 Hardknott through unstable branch. Next stable build will be with Yocto 3.2 Gatesgarth as well, once we're ready for new release.
  
Right layers and branches/revs are always defined in webos-ports/webos/layers.txt and mcf is calling simplified oebb.sh (+layerman) script to checkout/update them.
+
The stable, testing, unstable branches in webos-ports-setup are rebased on top of Yocto release branch and the only difference is the branch name in the Makefile. That way if you use e.g. testing branch it will automatically switch between Yocto releases once we switch the testing builds on jenkins. Stable is the same as testing most of the time, but has locked meta-webos-ports and meta-smartphone revisions instead of latest.
  
We're using mcf but in simplified form too, it does not use git submodules, but normal checkouts (managed by layerman). And we've removed options to enable/disable layers (one setup to rule them all). I would also change build layout, because separate BUILD-machine dir is not needed and one tmpdir is more effective - sharing native and cross builds. Each machine has separate sysroot in it so no problem with this.
+
Layerman will take care of the checkout of right layers with right revisions - just type make update if you want newer.
  
Current (as of right now 3rd October 2012) it looks like this:
+
The layout of directories on fileserver looks like this:
  
* bitbake,git://github.com/openembedded/bitbake.git,master,e5045429bce15b66c4355be214db3982ac7761f3
+
Basically jenkins jobs are rsyncing artifacts to
* meta-openembedded,git://github.com/openembedded/meta-oe.git,master,443481fec3855476f60ee34358887d00368e6859
+
a) luneos-stable-staging for stable builds, which are later promoted to luneos-stable by separate jenkins job after testing
* meta-smartphone,http://git.shr-project.org/repo/meta-smartphone.git,master,HEAD
+
  drwxrwxr-x  5 jenkins jenkins 4.0K Sep 15 14:57 luneos-stable
* openembedded-core,git://github.com/openembedded/oe-core.git,master,04568d1f18250d531aad5d286157d2d559083520
+
  drwxrwxr-x 60 jenkins jenkins 4.0K Oct 30  2019 luneos-stable-staging
* meta-webos,git@github.com:webos-ports/meta-webos.git,webos-ports/master,HEAD
+
b) luneos-{testing,unstable} symlinks
* meta-webos-ports,git@github.com:webos-ports/meta-webos-ports.git,master,HEAD
+
  lrwxrwxrwx  1 jenkins jenkins  25 Oct 22 09:31 luneos-testing -> luneos-testing-gatesgarth
 +
  lrwxrwxrwx  1 jenkins jenkins  25 Nov  1 11:26 luneos-unstable -> luneos-unstable-hardknott
 +
which point to corresponding luneos-{testing,unstable}-<yocto-release> directory:
 +
  drwxrwxr-x  4 jenkins jenkins 4.0K Oct 22 09:47 luneos-testing-dunfell
 +
  drwxrwxr-x  5 jenkins jenkins 4.0K Nov  1 05:16 luneos-testing-gatesgarth
 +
  drwxrwxr-x  3 jenkins jenkins 4.0K Oct 30  2019 luneos-testing-warrior
 +
  drwxrwxr-x  4 jenkins jenkins 4.0K Sep 14 17:16 luneos-testing-zeus
 +
  drwxrwxr-x  5 jenkins jenkins 4.0K Oct 23 05:51 luneos-unstable-gatesgarth
 +
  drwxrwxr-x  2 jenkins jenkins 4.0K Nov  1 11:26 luneos-unstable-hardknott
  
* bitbake/oe-core/meta-oe are using master with locked revision (from 2012-08-18).
+
And there is luneos-<yocto-release> convenience symlinks pointing to best LuneOS build for given yocto-release (testing if already available, otherwise unstable).
* meta-smartphone is using master/HEAD, but because master should stay compatible with oe-core/meta-oe HEAD we plan to create webos-ports/master branch there as soon as we have some commits in master which needs newer oe-core or meta-oe then what we have in webos setup.
+
  lrwxrwxrwx  1 jenkins jenkins   22 Sep 14 17:34 luneos-dunfell -> luneos-testing-dunfell
* meta-webos, meta-webos-ports are using HEAD and need valid user to checkout from github, jenkins setups should get own github account.
+
  lrwxrwxrwx  1 jenkins jenkins  25 Oct 22 09:30 luneos-gatesgarth -> luneos-testing-gatesgarth
 
+
  lrwxrwxrwx  1 jenkins jenkins  25 Nov  1 11:33 luneos-hardknott -> luneos-unstable-hardknott
There are currently the following repositories needed to build webos-ports:
 
 
 
* openembedded-core
 
* meta-openembedded/meta-oe
 
* meta-webos
 
** The layer from the Open webOS project
 
* meta-webos-ports
 
** Layer with additions for meta-webos needed for webos-ports
 
* meta-smartphone/meta-samsung
 
** Hardware support for the gnex device
 
* meta-smartphone/meta-fso
 
* meta-smartphone/meta-android
 
 
 
Each of this will have a ''webos-ports/master'' branch if there are additional commits which are not upstream yet. If there is no ''webos-ports/master'' branch the ''master'' branch should be used. '''The master branch will always track the upstream ''master'' branch!'''
 
 
 
== Layer description ==
 
 
 
=== meta-webos ===
 
 
 
This layers contains the recipes needed for openwebos. This is the original repository from the openwebos project with some additional changes which should go upstream in the near future.
 
 
 
=== meta-webos-ports ===
 
 
 
This layer contains several additions to meta-webos which can not go into meta-webos as they are specific for the webos-ports project.
 

Latest revision as of 11:37, 1 November 2020

Overview

Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using Yocto 3.2 Gatesgarth release through testing (with LTS Qt 5.15) and Yocto 3.3 Hardknott through unstable branch. Next stable build will be with Yocto 3.2 Gatesgarth as well, once we're ready for new release.

The stable, testing, unstable branches in webos-ports-setup are rebased on top of Yocto release branch and the only difference is the branch name in the Makefile. That way if you use e.g. testing branch it will automatically switch between Yocto releases once we switch the testing builds on jenkins. Stable is the same as testing most of the time, but has locked meta-webos-ports and meta-smartphone revisions instead of latest.

Layerman will take care of the checkout of right layers with right revisions - just type make update if you want newer.

The layout of directories on fileserver looks like this:

Basically jenkins jobs are rsyncing artifacts to a) luneos-stable-staging for stable builds, which are later promoted to luneos-stable by separate jenkins job after testing

 drwxrwxr-x  5 jenkins jenkins 4.0K Sep 15 14:57 luneos-stable
 drwxrwxr-x 60 jenkins jenkins 4.0K Oct 30  2019 luneos-stable-staging

b) luneos-{testing,unstable} symlinks

 lrwxrwxrwx  1 jenkins jenkins   25 Oct 22 09:31 luneos-testing -> luneos-testing-gatesgarth
 lrwxrwxrwx  1 jenkins jenkins   25 Nov  1 11:26 luneos-unstable -> luneos-unstable-hardknott

which point to corresponding luneos-{testing,unstable}-<yocto-release> directory:

 drwxrwxr-x  4 jenkins jenkins 4.0K Oct 22 09:47 luneos-testing-dunfell
 drwxrwxr-x  5 jenkins jenkins 4.0K Nov  1 05:16 luneos-testing-gatesgarth
 drwxrwxr-x  3 jenkins jenkins 4.0K Oct 30  2019 luneos-testing-warrior
 drwxrwxr-x  4 jenkins jenkins 4.0K Sep 14 17:16 luneos-testing-zeus
 drwxrwxr-x  5 jenkins jenkins 4.0K Oct 23 05:51 luneos-unstable-gatesgarth
 drwxrwxr-x  2 jenkins jenkins 4.0K Nov  1 11:26 luneos-unstable-hardknott

And there is luneos-<yocto-release> convenience symlinks pointing to best LuneOS build for given yocto-release (testing if already available, otherwise unstable).

 lrwxrwxrwx  1 jenkins jenkins   22 Sep 14 17:34 luneos-dunfell -> luneos-testing-dunfell
 lrwxrwxrwx  1 jenkins jenkins   25 Oct 22 09:30 luneos-gatesgarth -> luneos-testing-gatesgarth
 lrwxrwxrwx  1 jenkins jenkins   25 Nov  1 11:33 luneos-hardknott -> luneos-unstable-hardknott