nyuuzyou/wikis huggingface dataset:
DevDay Edinburgh 2018

This page contains slides for the talks in the Advanced Lab at Dev Day Edinburgh 2018
Starting at 9:00am, 26 October 2018. 
DevDay home page is here: 
== Keynote ==
* Class Slides
 : Keynote Slides (PDF)
== Beginning Class ==
* Class Slides
 : Begining Class Slides (PDF)
== Advanced Class ==
* Class Slides
 : Advanced Class Slides (PowerPoint)
 : Advanced Class Slides (PDF)
 : Slim Bootloader
 : (Fun with) Libraries/SDK and OE/the YP Slides
* Sample Code
 Class code for "(Fun with) Libraries/SDK and OE/YP"
DevDay Portland 2018

This page contains slides for the talks in the Advanced Lab at Dev Day US 2018
Starting at 9:00am, 26 October DevDay Page
== Beginning Class ==
* Class Slides
 TBD
* Sample Code
== Advanced Class ==
* Class Slides
 Advanced Class Slides (PowerPoint)
 Advanced Class Slides (PDF)
 Advanced Class Devtool #1 (PowerPoint)
 Advanced Class Devtool #1 (PDF)
* Sample Code
 TBD
DevDay Prague 2017

Page for DevDay Prague 2017
Starting at 9:00am, 26 October More info and tentative schedule
== Begining Class ==
* Class Slides
 Beginning Class Slides
* Sample Code
== Advanced Class ==
* Class Slides
 Advanced Class Slides (PDF)
 Advanced Class Slides (PowerPoint)
* Sample Code
 Sample script 'event_overlap.py'
* Class image set up
 Sample script to prepare up the class image
* Devtool transcript
 devtool.txt
* CROPS eSDK notes (for Mac OS X)
 
 crops-extsdk-mac.txt
* eSDK sample code
 hello.c
* User Space notes (command cheatsheet)
 Cheatsheet_userspace.txt
* CROPS Toaster notes (for Mac OS X)
 crops-toaster-mac.txt
* CROPS poky container notes (for Mac OS X)
 crops-poky-mac.txt
* Events notes (command cheatsheet)
 events_cheatsheet.txt
DevDay San Diego 2019

This page contains slides for the talks in the Advanced Lab at Dev Day San Diego 2019
Starting at 9:00am, 20 August 2019. 
DevDay home page is here: 
== Class ==
* Class Slides
 Class Slides (PowerPoint)
 Class Slides (PDF)
 SRTool Slides (PowerPoint)
 SRTool Slides (PDF)
 Joshua Watt Hash Equivalence
* Sample Code
 TBD
Developer Interaction Tips

Sometimes interactions between developers can be tricky. The project aims to be inclusive and supportive of different use cases and perspectives, encouraging people to be productive and enjoy working with it and its community. We appreciate that some people find interactions more challenging due to language barriers, particular ways of thinking and the many different ways people approach problems and challenges. We've tried to document some things to keep in mind (in no particular order):
* The problem you're currently working on is going to clearly be important and the most pressing thing to you. Remember that other people have their own priorities and will be working on different things so they might not be as excited/interested in it as you are.
* Whether others engage on an issue or not isn't a good measure of how important it is, it would likely be more a factor of whether anyone has appropriate experience/knowledge and can offer any useful input. Everyone has a different background and nobody knows every different area.
* You might wonder why to you, there is such a glaring obvious hole in the project in some way. Perhaps people haven't approached things from your direction before. Perhaps they don't have your knowledge or expertise. It is very unlikely to be a purposeful omission. Anything unusual done purposefully will usually be documented as such.
* Whilst there may be a wonderful way of doing things that you can see, it is probably impractical that big changes can happen quickly and everyone can just change to that, much as everyone would wish otherwise. For a variety of reasons, changes often need slower incremental steps towards an end goal. This may feel frustrating but it is amazing over time how much change you can actually make. It does need patience.
* Criticising an existing approach or code may make people defensive even if they also don't like it. There are often reasons why things end up as they are, even if they are far from perfect. They probably did improve on something before them, the people involved probably learnt things since and would love to redo it with that hindsight or new knowledge too. Approaching things as suggesting incremental improvements is usually more productive rather.
* Maintainers have to view changes from multiple perspectives and balance the needs pf many different and often diverse users. If they suggest caution or potential problems or ask for improvements to a change, it isn't to be negative but to try and ensure any change has the best chance of getting included. Maintainers do actively want code improvements and contributions.
* Remember than when asking for something to be included, maintainers are acutely aware that once merged, you will probably move on to other things and they will be left looking after it going forward. This may mean they ask questions, it may make then reluctant to take a change if they don't want to be left maintaining it. If you think you will be around and using it and able to help in future, making that clear may help. Also try and be clear if you cannot help any more.
Development Best Practices

* Do not patch generated files (e.g. configure, Makefile) when they will be regenerated from steps like do_configure (e.g. from configure.ac, Makefile.am). Is important the timestamps of the base files are newer than the generated files so the system works deterministically and it also ensures consistency in approach across the metadata. An exception would be where we don't regenerate the files (e.g. in gcc configure).
Development Methodology

The project will be managed as a series of 6-8-week milestones. The milestones will be broken out as follows:
* 1 week – planning and development week
* 2-4 weeks – development
* 1-4 week – stabilization
* 1 week – release
(The above time adds up to more than 5-8 weeks due to the planning week overlapping the release week).
The final project milestone is up to 4 weeks of stabilization and then release.
At the end of each milestone there is a milestone release that:
* has been stabilized, with bugs tracked and showstoppers fixed
* has had some amount of QA applied beyond the nightly sanity test
* can demonstrate some feature or features
Each developer is expected to focus on 1-2 features/tasks at a time, which can help the team focus and also prevent from sending all pull requests at the end of a milestone. Project developers must respect this rule. It gives the maintainers a break.
Distribution Support

==Distribution Support ==
===Distribution Support ===
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "Supported Linux Distributions" section in the Yocto Project Reference Manual.
Example of distro list in poky.conf:
SANITY_TESTED_DISTROS ?= " \
 poky-2.4 \n \
 poky-2.5 \n \
 ubuntu-15.04 \n \
 ubuntu-16.04 \n \
 ubuntu-16.10 \n \
 ubuntu-17.04 \n \
 fedora-26 \n \
 centos-7 \n \
 debian-8 \n \
 debian-9 \n \
 opensuse-42.1 \n \
 opensuse-42.2 \n \
 "
Again, the previous listing is just an example and is not meant to be a definitive reference. 
=== How to add a new entry or additional distro information ===
The criteria for adding a supported distro is quite rigid. Obviously, any candidate distro must be of production quality. In other words, the distro is capable of being used in a production environment on a Yocto Project Autobuilder build worker. A compelling reason must also exist for the Yocto Project to actually use the distro on a build worker. Obscure, poorly supported, or highly customized distros are not likely to be good candidates for submission. Major stable distros (e.g. Debian, Fedora, Ubunto, Centos, and so forth.) are generally already supported. If they are not supported, they are likely on the list to become supported once sufficient criteria are met. Please be sure to check the latest supported distros beforehand to make sure the distro in question is not already supported.
If you have a compelling reason to suggest a distro for support, please submit your request to the Yocto Project mailing list for discussion. You will likely be asked to provide the reasoning behind your request. Along with your request, relevant bug reports, failed test cases, and so forth are helpful. Have them ready in advance. 
If you are not already a member of the Yocto Project mailing list, you can find more information and subscription requirements here: https://lists.yoctoproject.org/listinfo/yocto.
The Yocto Project mailing list is also the right place for more general questions or issues surrounding distro support.
== Distro Testing ==
=== Distro test coverage ===
Distro Testing is intended to reveal bugs that are distribution-specific using the yocto-autobuilder. The tests all run on identical hardware and use each updated OS.
For detailed information on Distro testing, please see Distro_Testing_Plan.
For more information on the overall QA testing plan, please see QA_Master_Test_Plan. (Comprehensive)
Distro/DebianWheezy

* Distribution: Debian
* Arch: 64 
* MACHINE (qemux86/qemuarm/qemuppc... etc):
* TARGET (core-image-sato/core-image-sato-sdk... etc):
* Commit/Release (7eea637db0.../master, 1.0.1 release):
* Validated by/DATE (user@email.com - 2011-09-14):
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)
Distro/centos6.2

* Distribution: CentOS 6.2
* Arch (32/64): 32
* MACHINE: armv5te
* TARGET: core-image-minimal
* Commit/Release: 1a03b7dfba464fde770ba69b618427d13e0a3b8b
* Validated by/DATE: robert.casey@agilent.com - 2012-05-17
* Bug ID:
Distro/fedora13 32b

-----------------
* Distribution: Fedora 13
* Arch (32/64): 32
* MACHINE (qemux86/qemuarm): beagleboard
* TARGET (core-image-sato/core-image-sato-sdk): core-image-sato
* Commit/Release (7eea637db0.../master, 1.0.1 release): 7a0cbe6..../master 
* Validated by: gary@mlbassoc.com - 2011-09-23
Distro/fedora15 32b

-----------------
* Distribution: Fedora 15
* Arch (32/64): 32
* MACHINE (qemux86/qemuarm): beagleboard
* TARGET (core-image-sato/core-image-sato-sdk): core-image-sato
* Commit/Release (7eea637db0.../master, 1.0.1 release): 7a0cbe6..../master 
* Validated by: gary@mlbassoc.com - 2011-09-23
Distro/fedora15 64b

-----------------
* Distribution: Fedora 15
* Arch (32/64): 64 
* MACHINE (qemux86/qemuarm): qemux86
* TARGET (core-image-sato/core-image-sato-sdk): world, core-image-sato-sdk 
* Commit/Release (7eea637db0.../master, 1.0.1 release): f8cddd7457..../master 
* Validated by: jiajun.xu@intel.com - 2011-09-14
Distro/fedora16 64b

-----------------
* Distribution: Fedora 16
* Arch (32/64): 64 
* MACHINE (qemux86/qemuarm): qemumips
* TARGET (core-image-sato/core-image-sato-sdk): world, core-image-sato-sdk 
* Commit/Release (7eea637db0.../master, 1.0.1 release): master 
* Validated by: josh@linux.intel.com - 2011-09-16
Distro/fedora17 64b

-----------------
* Distribution: Fedora 17
* Arch (32/64): 64 
* MACHINE: ARM (v4t, v5te, v6, v7a), PowerPC (hf/sf, 4xx, 4xx-sf, e500v2), MIPS (BE, LE)
* TARGET: core-image-minimal, core-image-minimal-mtdutils, core-image-minimal-dev, core-image-base, core-image-basic, core-image-core, core-image-clutter, core-image-lsb, core-image-lsb-dev, core-image-lsb-sdk, core-image-sato, core-image-sato-dev, core-image-sato-sdk, core-image-qte-sdk, meta-toolchain-sdk, meta-toolchain-qte 
* Commit/Release: 1.2
* Validated by: wd@denx.de - June 2012
Distro/fedora18 64b

-----------------
* Distribution: Fedora 18
* Arch (32/64): 64 
* MACHINE: ARM (v4t, v5te, v6, v7a, v7a-hf), PowerPC (powerpc, powerpc-softfloat, 4xx, 4xx-softfloat, e500v2), MIPS (BE, LE)
* TARGET: core-image-minimal, core-image-minimal-mtdutils, core-image-minimal-dev, core-image-base, core-image-basic, core-image-core, core-image-clutter, core-image-lsb, core-image-lsb-dev, core-image-lsb-sdk, core-image-sato, core-image-sato-dev, core-image-sato-sdk, core-image-qte-sdk, meta-toolchain-sdk, meta-toolchain-qte 
* Commit/Release: 1.4
* Validated by: wd@denx.de - September 2013
Distro/opensuse11.3 32b

* Distribution: OpenSUSE 11.3
* Arch: 32
* MACHINE: qemux86
* TARGET: core-image-sato (build & boot)
* Commit/Release: 49ed1cab3bee.../master
* Validated by: Paul Eggleton <paul.eggleton@linux.intel.com> - 2011-09-27
Distro/opensuse11.4 64b

-----------------------
* Distribution: Opensuse 11.4
* Arch (32/64): 64
* MACHINE (qemux86/qemuarm): qemuppc
* TARGET (core-image-sato/core-image-sato-sdk): world, core-image-sato-sdk
* Commit/Release (7eea637db0.../master, 1.0.1 release): f8cddd7457..../master 
* Validated by: jiajun.xu@intel.com - 2011-09-14
* Bug ID: 1451
Distro/rhel6.2 64b

* Distribution: RHEL Server 6.2
* Arch (32/64): 64
* MACHINE: armv5te
* TARGET: core-image-minimal
* Commit/Release: cd4d346c0e83fc9bf5497dd0424368e9244b6e08
* Validated by/DATE: robert.casey@agilent.com - 2012-05-17
* Bug ID:
Distro/ubuntu10.04 32b

---------------------
* Distribution: Ubuntu 10.04
* Arch (32/64): 32
* MACHINE (qemux86/qemuarm): qemux86
* TARGET (core-image-sato/core-image-sato-sdk): core-image-sato
* Commit/Release (7eea637db0.../master, 1.0.1 release): ce66e2c6bd1..../master
* Validated by: jiajun.xu@intel.com - 2011-09-14
Distro/ubuntu11.04 64b

---------------
* Distribution: Ubuntu 11.04
* Arch (32/64): 64
* MACHINE (qemux86/qemuarm): qemuarm
* TARGET (core-image-sato/core-image-sato-sdk): world, core-image-sato-sdk
* Commit/Release (7eea637db0.../master, 1.0.1 release): f8cddd7457..../master 
* Validated by: jiajun.xu@intel.com - 2011-09-14
Distro Test

== Latest OSD Test Result ==
OS version 	Arch 	Yocto1.1-M1-RC2	Status-RC5 	Yocto1.2-M4-RC1	Yocto1.2-M4-RC2	Yocto1.2-M4-RC3	Yocto1.2-M4-RC4	Yocto1.2-M4-RC5
Ubuntu10.04 	X86-64	N/A 	PASS 	N/A 	N/A 	N/A 	N/A 	N/A
Ubuntu11.04 	X86-64	PASS 	N/A 	N/A 	N/A 	N/A 	N/A 	N/A
Ubuntu11.10 	X86-64	N/A 	N/A 	Pass 	Pass 	Pass 	Pass 	Pass
Ubuntu12.04 	X86-64	N/A 	N/A 	Pass 	Pass 	Pass 	Pass 	Pass
Opensuse11.3 	X86-64	N/A 	FAIL(bug 969)	N/A 	N/A 	N/A 	N/A 	N/A
Opensuse11.4 	X86-64	N/A 	N/A 	N/A 	N/A 	N/A 	N/A 	N/A
Opensuse12.1 	X86-64	N/A 	N/A 	Pass 	Pass 	Pass 	Fail(bug2362) 	Pass
Opensuse12.2 Milestone2	X86-64	N/A 	N/A 	Fail(bug2201) 	Fail(bug2201) 	Fail(bug2201) 	Fail(bug2201) 	Fail(bug2201)
Fedora14 	X86-64	N/A 	PASS 	N/A 	N/A 	N/A 	N/A 	N/A
Fedora16 	X86-64	N/A 	N/A 	Pass 	Pass 	Pass 	Pass 	Pass
Fedora17 Alpha 	X86-64	N/A 	N/A 	Pass 	Fail(bug2278) 	Fail(bug2278) 	Fail(bug2363) 	Fail(bug2363)
Centos5.6/5.7 	X86 	N/A 	N/A 	Pass 	Fail(bug2264) 	Pass 	Pass 	Pass
Centos6.2 	X86-64	N/A 	N/A 	Pass 	Pass 	Pass 	Pass 	Pass
Note: 
* All OSD testing is performed in RHEL6 KVM Virtual Machine.
* PASS means sato-sdk and lsb-sdk image could be built green
== Test Configuration ==
=== Host configuration ===
* OS:Red Hat Enterprise Linux6.0
* CPU:Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz 6 cores 12 processor
* Physical Memory:5838M
* KVM version: qemu-kvm-0.12.1.2-2.113.el6.x86_64
=== Guest configuration === 
* Virtual Processor Per Guest: 4
* Virtual Memory Per Guest: 2000M
Documentation Decoder

== URL Decoder ==
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. 
Searches many times return very old versions of a manual.
URLs use the following format: https://docs.yoctoproject.org/release/name/name.
With this format, the "release" string specifies the Yocto Project release associated with the manual.
The "name" string represents the manual's folder name.
You can find the list of the current folder strings in the next section.
Here is an example for the "Yocto Project Reference Manual" for release 3.3: https://docs.yoctoproject.org/3.3/ref-manual/
You can use the string current rather than a specific release number (e.g. 3.3) to go to the latest released version of a manual.
For example, to access the latest Yocto Project Development Tasks Manual, use the https://docs.yoctoproject.org/current/dev-manual/ URL.
== List of Manual Pages ==
Here is a list of documentation page names and brief descriptions of their purposes.
This list represents the latest Yocto Project release:
:brief-yoctoprojectqs. A very brief quick start to get you going.
:overview-manual. Presents Yocto Project overview and conceptual information.
:dev-manual. A development tasks manual. Provides procedures for common and not-so-common development tasks.
:sdk-manual. Describes how to build and use Yocto Project SDKs for application development.
:bsp-guide. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.
:kernel-dev. The kernel development manual, which is often used in conjunction with BSP guide.
:profile-manual Presents information on profiling and tracing.
:toaster-manual. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. 
:ref-manual. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.
:mega-manual. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.
Documentation Production Workflow

This page gathers ideas to properly document a production workflow for developers...
Initial ideas from Robert Berger, summarized and expanded by this mind mapping attachement: https://bugzilla.yoctoproject.org/attachment.cgi?id=4793
A developer workflow for production should be mentioned:
* SDK for developer/bitbake for production build and Yocto/OE person
* devtool for developer/devtool for Yocto/OE person
== Build efficiency ==
* local source mirrors
* strategies for handling the git cloned repos (use local branches and rebase vs bbappend )
== Software update solutions ==
SW update solutions (System Update) should be mentioned for production, since people are reinventing all the time what's already there.
== Tracking image contents ==
* To be able to see what meta-layers/branch/commit-id were used to build the image and whether something was modified without being checked in: image-buildinfo.bbclass. You can see on https://hub.docker.com/r/yoctotrainer/app-container-tensorflow-oci how the output of image-buildinfo.bbclass and image-manifestinfo.bbclass looks like.
* What packages are in the rootfs (without a package manager)
** I use https://gitlab.com/meta-layers/meta-resy/-/blob/dunfell/classes/image-manifestinfo.bbclass to write /etc/image-manifest (all packages) into my rootfs
== License compliance ==
* Something like the oss-review toolkit (https://github.com/tsteenbe/ort) could be used to help with license compliance. I am not sure yet whether this should be outside of the YP or integrated with it.
== Hardening the production image ==
* cve-check.bbclass
* static code checks: https://github.com/priv-kweihmann/meta-sca
== Credits ==
Thanks to:
* Robert Berger
* Randy MacLeod
Editing WW38 - 2013-09-18 - Full Pass Release 1.5 M5.rc4

=Testing data=
 
 Test type: Full Pass Release
 Branch: Master
 Milestone: M5
 Build name: 1.5_M5.rc4
 poky commit: 853bc53cd58a621918f0e5ce662dba263d1befb4
 Eclipse Plugin commit Kepler: ad74249895f882a8f00bdeef7a0f7c18998cc43e
 Autobuilder images repository: http://autobuilder.yoctoproject.org/pub/releases/1.5_M5.rc4/
 Distributions tested: Ubuntu 12.04 64bit, Ubuntu 13.10 64bit beta, Fedora 19 64bit, Fedora 19 32bit, Fedora 18 64bit, OpenSuse 12.3 64bit, OpenSuse 12.2 64bit, CentOS 6.4 64bit, CentOS 6.4 32bit, Debian 7 64bit
 
=Summary Report=
	
=Detailed Report=
Embedded Linux Conference 2021

== Yocto Project related talks at ELC 2021 ==
* BoF: The Yocto Project and Embedded Linux - Armin Kuster, MontaVista, LLC & Nicolas Dechesne, Linaro
* Securing a Yocto-based Distribution: The Case of AllScenariosOS - Marta Rybczynska
* Yocto Continuous Integration in a Kube - Joshua Watt, Garmin
* The 5 Key Success Factors to Deploy Yocto for “Production Grade” Embedded/IoT Devices - Adrien Leravat, Witekio
* Binary Artifacts and the Ease of Use Onramp for the Yocto Project - Bruce Ashfield, Xilinx
* A Tale of Three Build Systems: Building a Custom Linux OS for BeagleV Starlight with Buildroot, Isar and Yocto Project - Tim Orling, Intel Corporation
* Practical Experience with Linux A/B Upgrades - Leon Anavi, Konsulko Group
* Yocto Project and Android – Compare and Contrast - Chris Simmonds, 2net
Enable sstate cache

== sstate background ==
To speed up the build process, sstate provides a cache mechanism, where sstate files from server can be reused to avoid build from scratch if the producer and consumer of the sstate have the same environment. With perfect case, we can achieve more than 80% time decreasing.
== use sstate cache server ==
Another build machine is needed to produce the sstate file periodically. The default sstate files directory is sstate-cache under build dir, which is needed to be exported via NFS, http or ftp server.
On your local machine, change the conf/local.conf as follows:
<nowiki>
SSTATE_MIRRORS ?= "\
file://.* http://someserver.tld/share/sstate/PATH"
</nowiki>
for an NFS server:
<nowiki>
SSTATE_MIRRORS ?= "\
file://.* file:///local/mounted/dir/sstate/PATH"
</nowiki>
The special "PATH" suffix is important as it is automatically expanded to the correct value for native packages (which are split by the host distribution being used).
== Use local sstate cache ==
You can make all the builds pointing to the same SSTATE_DIR to share sstate files between them, like this:
 SSTATE_DIR ?= "/share/sstate-cache"
So that each build would consume the sstate file if match, and produce new sstate file if not match.
== Verify the sstate is working ==
If sstate works, you can see something like:
 NOTE: Preparing runqueue
 NOTE: Executing SetScene Tasks
 NOTE: Running setscene task 118 of 155 (virtual:native:/home/lulianhao/poky-build/edwin/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
 NOTE: Running setscene task 119 of 155 (/home/lulianhao/poky-build/edwin/poky/meta/recipes-devtools/quilt/quilt-native_0.48.bb:do_populate_sysroot_setscene)
If there is no setscene tasks running, sstate cache can't be used because sstate function got broken or some environment value changes invalidate sstate cache. You can use following tools to check any changes between sstate cache and new produced one.
If you wish to compare signatures to see any changes that caused a rebuild since the last built version, you can use bitbake-diffsigs with the -t option:
 $ bitbake-diffsigs -t quilt-native do_configure
Alternatively you can compare siginfo files directly:
 $ bitbake-diffsigs /mnt/sstate/sstate-packagename-checksum1-tgz.siginfo builddir/sstate-cache/sstate-packagename-checksum2-tgz.siginfo
== Known issues ==
* New changeset may invalidate part or all of the sstate cache occasionally - this is by design
* Native package’s sstate cache can’t be reused among 32bit and 64bit host
* Missing sstate file on http/ftp server cause wget hang for a long time due to the retries and timeout