Difference between revisions of "Repository Layout"

From WebOS-Ports
Jump to navigation Jump to search
(Replaced content with "== Overview == Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using LTS Yocto 3.1 Dunfell release through testing...")
Tag: Replaced
(3 intermediate revisions by the same user 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 2.3 Pyro release through testing and stable branch.
+
Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using LTS Yocto 3.1 Dunfell release through testing (with LTS Qt 5.15) and Yocto 3.2 Gatesgarth through unstable branch. Next stable build will be with Yocto 3.1 Dunfell as well, once we're ready for new release.
  
−
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).
+
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.
 
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.
 
−
 
−
For this testing I'm using extra subdirectory on the fileserver and for sstate-cache on the build server.
 
−
http://build.webos-ports.org/luneos-unstable/thud/
 
−
http://build.webos-ports.org/luneos-unstable/sumo/
 
−
http://build.webos-ports.org/luneos-unstable/rocko/
 
−
and
 
−
sstate-cache/thud
 
−
sstate-cache/sumo
 
−
sstate-cache/rocko
 
−
when switching unstable branch from one release to another it's important to move the content to correct subdirectory (previous release) and restore the content from new release subdirectory. That way we can keep multiple sets of sstate-cache for faster builds (without clean-workspace job pruning the archives for other release) and making sure that the builds are from the release you want to test. Hopefully we won't need this for long (testing shouldn't be so far behind with Yocto releases or unstable branch that we would need to test multiple releases at the same time).
 
−
 
−
=== Yocto 2.4 Rocko ===
 
−
 
−
Everything is building fine and quick runtime test on tissot didn't reveal any terrible issues.
 
−
 
−
qemux86 has the same issue with vboxtouch plugin as pyro (and all other Yocto release have), since mesa upgrade and switch to vboxvideo for DRM it was crashing after failed ioctl, the segfault after failed ioctl was fixed, but ioctl still doesn't work, I'm debugging why (either due to changes in vbox guest kernel modules where we switched from external modules built from 5.2.* VirtualBox to the staging driver in linux-yocto-dev currently 5.0-rc8, or it's because we're using vboxvideo instead of uvesafb now), related commits:
 
−
https://github.com/webOS-ports/meta-webos-ports/commit/42e290089146987b9dab8890c1bd26fea085bc96
 
−
https://github.com/meta-qt5/meta-qt5/commit/201fcf27cf07d60b7d6ab89c7dcefe2190217745
 
−
 
−
DEBUG: 17:05:39.393: vboxtouch: Using vbox device /dev/vboxguest
 
−
WARNING: 17:05:39.402: vboxtouch setpointershape: ioctl error: Invalid argument
 
−
WARNING: 17:05:39.403: vboxtouch init: ioctl error: Invalid argument
 
−
DEBUG: 17:05:39.403: shutting down vboxtouch
 
−
 
−
or
 
−
 
−
WARNING: 09:43:23.240: Failed to move cursor on screen VGA1: -13
 
−
WARNING: 09:43:23.247: Could not set cursor on screen VGA1: -13
 
−
DEBUG: 09:43:23.266: vboxtouch: Using vbox device /dev/vboxguest
 
−
WARNING: 09:43:23.266: vboxtouch init: ioctl error: Invalid argument
 
−
DEBUG: 09:43:23.266: shutting down vboxtouch
 
−
 
−
You can drop -plugin vboxtouch from /etc/luna-next/environment.conf, but then you still won't get mouse input in VirtualBox.
 
−
 
−
=== Yocto 2.5 Sumo ===
 
−
 
−
==== (resolved) tenderloin nyx-modules.do_install ====
 
−
* http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_tenderloin/122/consoleFull
 
−
unrelated to Yocto upgrade, the same issue already exists in pyro sync OSE migration
 
−
fixed in https://github.com/webOS-ports/meta-webos-ports/commit/850bbe337b83be40e225507d018c782d165d4665
 
−
 
−
==== (resolved) 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
 
−
 
−
==== mako not working ====
 
−
 
−
Just sticks on the Google boot display.  (Might be the same as on tissot)
 
−
adb devices gets a response, but adb shell simply closes the connection attempt.
 
−
 
−
==== No boot for onyx ====
 
−
 
−
Nothing happens. (Might be the same as on tissot)
 
−
 
−
==== Boot loop on tissot ====
 
−
 
−
Should be fixed by (either should work)
 
−
http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/sumo&id=ec7c2a637d924fad6845692de8c1ec64ec9fddea
 
−
https://github.com/webOS-ports/meta-webos-ports/pull/311
 
−
 
−
+kernel fix:
 
−
https://github.com/shr-distribution/meta-smartphone/commit/6424fb3835625d954d8947a85c1a7fd0e56947ac
 
−
 
−
=== 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
 
−
 
−
New builds without glog/mtp-server issue:
 
−
* http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_tenderloin/129/console
 
−
* http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_hammerhead/44/console
 
−
* http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_mako/129/console
 
−
* http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_onyx/8/console
 
−
 
−
Latest builds:
 
−
http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_tenderloin/132/console
 
−
http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_hammerhead/47/console
 
−
http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_mako/132/console
 
−
http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_onyx/11/console
 
−
 
−
 
−
Some background about this from 2018-10-03 #webos-ports discussion
 
−
<pre>
 
−
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
 
−
</pre>
 
−
 
−
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.
 
−
 
−
==== (resolved) 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 glog in master, will get it backported to thud later: https://patchwork.openembedded.org/patch/156422/ https://patchwork.openembedded.org/patch/156922/ https://patchwork.openembedded.org/patch/156939/
 
−
 
−
=== Yocto 2.7 Warrior (master) ===
 
−
 
−
== 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).
 

Revision as of 18:42, 14 September 2020

Overview

Right layers and branches/revs are always defined in webos-ports-setup/conf/layers.txt. Currently we're using LTS Yocto 3.1 Dunfell release through testing (with LTS Qt 5.15) and Yocto 3.2 Gatesgarth through unstable branch. Next stable build will be with Yocto 3.1 Dunfell 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.

Retrieved from "http://webos-ports.org/index.php?title=Repository_Layout&oldid=10610"