Repository Layout

Overview

Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using Yocto 2.3 Pyro release through testing and stable branch.

For newer Yocto release there are rocko, sumo, thud, master branches and unstable points to one of them. These branches are for testing against new Yocto, (but not very often tested on target).

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

The Yocto upgrade was blocked by very old mesa we're still using in pyro, there was some progress recently, so hopefully we'll move forward soon.

Currently failing builds with new Yocto:

Yocto 2.5 Sumo

initramfs-android-recovery* file-rdeps

ERROR: initramfs-android-recovery-tissot-3.1.1-1-r0 do_package_qa: QA Issue: /recovery/sbin/permissive.sh contained in package initramfs-android-recovery-tissot requires /sbin/sh, but no providers found in RDEPENDS_initramfs-android-recovery-tissot? [file-rdeps]

• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_tissot/12/console

fixed in thud and master, now cherry-picked to sumo as well

Yocto 2.6 Thud

kernel and gcc8

• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_hammerhead/37/console
• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_mako/122/console
• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_onyx/1/console
• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_tenderloin/121/console

Some background about this from 2018-10-03 #webos-ports discussion

07:34 <+JaMa> how much are people attached to tenderloin/hammerhead targets?
07:35 <+JaMa> yesterday I've spent some time trying to fix their 3.4 kernels to build correctly with gcc-8 and not sure if it's worth it :)
07:36 <+JaMa> for 3.16 I needed cca 15 patches, for 3.4 it seems to be significantly more
07:54 < elvispre> Personally, I have neither of those targets but I note with some nervousness that both mako and onyx still also have 3.4 kernels.
08:52 <+Tofe> Morning
08:53 <+Tofe> JaMa: oh, that much is needed ?
09:03 <+Tofe> JaMa: what kind of error do you get ?
09:27 <+Herrie|Laptop> JaMa: I would be reluctant to drop the 3.4 targets at this point
09:27 <+Herrie|Laptop> It might be unavoidable at some point in the future
09:35 <+Tofe> Herrie|Laptop: I agree; N5 is, for me, a reference target. As long as we don't have the equivalent for aarch64 (tissot, rosy, onyx...) I'd want to keep N5.
09:36 <+Herrie|Laptop> Tofe: Seeing TP is our only tablet, I'm keep on keeping that as well
09:36 <+Tofe> Herrie|Laptop: I was writing that as well :)
09:36 <+Herrie|Laptop> We might want to look to see if there's some mainline availabl
09:37 <+Herrie|Laptop> +e
09:37 <+Herrie|Laptop> I recall some work has been done for some targets to mainline the kernel
09:37 <+Herrie|Laptop> That should "solve" a lot of issues but might introduce a lot of others as well
09:38 <+Tofe> it depends what is included in that mainline kernel, yes
09:51 <+Tofe> JaMa: but I'm willing to help fixing these issues, if needed
12:29 <+JaMa> Tofe: see http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_hammerhead/35/console
12:33 <+JaMa> Tofe: the simple fix is described here: http://lists.openembedded.org/pipermail/openembedded-devel/2018-May/118179.html
12:33 <+JaMa> Tofe: the tricky part is the other backport: http://lists.openembedded.org/pipermail/openembedded-devel/2018-May/118223.html
12:34 <+JaMa> the code is very different in 3.4 and I'm not asm expert to adapt it properly for the code in 3.4, so for 3.16 I was backporting enough changes to make this applicable with just minor tweaks
12:35 <+JaMa> and this all has kind of low priority until I unblock at least the rocko upgrade, once we're on sumo it will be more important to decide what to do with these targets
12:45 <+Tofe> ok thanks, I'll have a look

So for 3.16 kernel it took me 12+ backports to apply getuser.S-fix-build-with-gcc8.patch which resolved the issue, for 3.4 it might take significantly more or we'll need to fix the root cause without backporting all these other fixes.

mtp-server

mtp-server meta-webos-ports/meta-luneos/recipes-luneos/mtp-server/mtp-server_git.bb:do_configure

• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_tissot/11/consoleFull
• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_rosy/10/console
• http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_mido/11/console

fixed in master, will get it backported to thud later

Very old Overview

Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using dylan release, master is sometimes updated to test newer stuff in upstream layers (but not very often tested on target).

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

Current (as of right now 21th September 2013) we're using this set of layers:

• changes in our meta-webos fork (meta-webos-ports repository) are described here MetaWebosCommits

webos-ports-setup/master (this will be renamed when new oe-core 1.5 is released - master always tracks master in upstream layers)

https://github.com/webOS-ports/webos-ports-setup/blob/master/conf/layers.txt

• bitbake,master
• oe-core,webOS-ports/master
• meta-oe,master
• meta-qt5,master
• meta-smartphone,webOS-ports/master
• meta-webos-ports,master

Branch name prefixed with 'webOS-ports/', means we're modifying some upstream repository. webOS-ports/danny, webOS-ports/dylan also means that this modification is compatible with older danny, dylan branches and also indicates that this branch is sometimes rebased on danny, dylan branch in upstream repository.

Where to push changes: meta-webos-ports: master branch meta-smartphone: please try to push all changes to webOS-ports/master *and* shr (compatible with master) branches. meta-smartphone/shr is merged to meta-smartphone/master (when there isn't explicit dependency on other shr branches) and after that webOS-ports/master is rebased from meta-smartphone/master. If some change isn't pushed to "shr" branch, then there is a risk that we'll forget to forward-port that change when moving to next release. oe-core: webOS-ports/master

Branches which are rebased now have git tags with date when it was rebased (this way we can continue to use older revisions, which are no longer in branch after last rebase).