Yocto Project - User contributions [en]

Documentation

2010-10-26T17:07:48Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/projects/documentation page on the website for more information on this project.'

See the http://yoctoproject.org/projects/documentation page on the website for more information on this project.

Projects

2010-10-26T17:07:28Z

134.134.139.72:

== Welcome to the Projects Page ==
* [[AutoBuilder]]
* [[Poky]]
* [[SDK Generator]]
* [[Eclipse Plug-in]]
* [[Anjuta Plug-in]]
* [[Psuedo]]
* [[Swabber]]
* [[Cross-Link]]
* [[QA]]
* [[Documentation]]
* [[Boards]]

Projects

2010-10-26T17:06:47Z

134.134.139.72:

== Welcome to the Projects Page ==
* [[AutoBuilder]]
* [[Poky]]
* [[SDK Generator]]
* [[Eclipse Plug-in]]
* [[Anjuta Plug-in]]
* [[Psuedo]]
* [[Swabber]]
* [[Cross-Link]]
* [[Kernel]]
* [[QA]]
* [[Documentation]]
* [[Boards]]

Swabber

2010-10-26T17:05:55Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/projects/swabber page on the website for more information on this project.'

See the http://yoctoproject.org/projects/swabber page on the website for more information on this project.

Pseudo

2010-10-26T17:05:33Z

134.134.139.72:

See the http://yoctoproject.org/projects/pseudo page on the website for more information on this project.

Pseudo

2010-10-26T17:04:36Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/projects/psuedo page on the website for more information on this project.'

See the http://yoctoproject.org/projects/psuedo page on the website for more information on this project.

Eclipse Plug-in

2010-10-26T17:04:08Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/projects/eclipse page on the website for more information on this project.'

See the http://yoctoproject.org/projects/eclipse page on the website for more information on this project.

Cross-Prelink

2010-10-26T17:03:38Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/projects/cross-prelink page on the website for more information on this project.'

See the http://yoctoproject.org/projects/cross-prelink page on the website for more information on this project.

SDK Generator

2010-10-26T17:02:47Z

134.134.139.72:

==SDK documentation==
Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released.

You can also see the http://yoctoproject.org/projects/sdk-generator page on the website for more information on this project.

==SDK Userspace NFS Use Scenarios and Workflow==

=== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ===

Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Sally's System Administrator set up her workstation for Poky development by doing the following:

# Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky
# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of.

Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables.

She then downloads a poky-image-sdk tarball and a QEMU kernel. Sally can copy the kernel and extract the SDK image tarball to an arbitrary work area, but she must extract the SDK image tarball using the following script:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

The documentation may recommend standard directories (e.g, ~/qemukernels/<kernel> ~/rootfs/<machinetype>), but Sally is free to choose another directory if that suits her needs better.

She then can run QEMU to automatically boot to this nfsroot with the following command:

poky-qemu {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Sally shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Sally could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 2: In-tree Poky setup with a QEMU SDK image ===

Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Roger's System Administrator sets up his workstation for Poky development by doing the following:

# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of.

Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky).

Roger sources the poky-init-build-env script, which sets up his environment for Poky builds. He then bitbakes a poky-image-sdk image, which creates a qemu kernel and SDK image tarball in his ~/poky/build/tmp/deploy/images/ directory.

Roger then extracts the SDK image tarball with:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

and then starts QEMU to boot to this using:

poky-qemu {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Roger shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Roger could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 3: Exporting a rootfs to a non-QEMU target ===

This allows developers to export a rootfs to non-qemu targets (i.e, real hardware).

First, the rootfs must be created using the poky-extract-sdk script, which creates the filesystem tree using pseudo:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

Then they can start/stop/restart the unfs server with:

poky-export-rootfs {start|stop|restart} <path to rootfs>

The developer would then configure their hardware to boot using a kernel accessed over tftp and with a rootfs pointed at the hosts's IP and exported directory.

QA

2010-10-26T17:01:02Z

134.134.139.72:

See the http://yoctoproject.org/projects/testing-qa-and-autobuilder page on the website for more information on this project.

* [[Overall Test Plan]]
* [[Milestone Test Report]]
* [[Enabling Automation Test in Poky]]

AutoBuilder

2010-10-26T17:00:01Z

134.134.139.72:

See the http://yoctoproject.org/projects/testing-qa-and-autobuilder page on the website for more information on this project.

Here are some useful links for AutoBuilder

* Nightly build output: http://autobuilder.pokylinux.org/nightly/
* Weekly build output: http://autobuilder.pokylinux.org/weekly/
* Milestone build output: http://autobuilder.pokylinux.org/milestone/

AutoBuilder

2010-10-26T16:58:52Z

134.134.139.72:

See the http://yoctoproject.org/projects/autobuilder page on the website for more information on this project.

Here are some useful links for AutoBuilder

* Nightly build output: http://autobuilder.pokylinux.org/nightly/
* Weekly build output: http://autobuilder.pokylinux.org/weekly/
* Milestone build output: http://autobuilder.pokylinux.org/milestone/

Anjuta Plug-in

2010-10-26T16:57:47Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/projects/anjuta page on the website for information on this project.'

See the http://yoctoproject.org/projects/anjuta page on the website for information on this project.

Poky

2010-10-26T16:56:27Z

134.134.139.72:

See the http://yoctoproject.org/projects/poky page for information on this project.

Poky

2010-10-26T16:55:39Z

134.134.139.72: Created page with 'See the http://yoctoproject.org/project/poky page for information on this project.'

See the http://yoctoproject.org/project/poky page for information on this project.

Yocto Release Engineering

2010-10-26T16:41:15Z

134.134.139.72:

== Yocto Linux Release Engineering Procedures ==

This document describes release engineering procedures for the Yocto Linux project.

While this is intended to be a living document, this process is becoming more stable now that we're entering M3. Further changes will be considered if they are accompanied with strong reasoning and evidence of improvement.

== Naming Conventions ==

Official/public releases will use the following scheme: '''X.Y.Z'''

* X = major release number
* Y = minor release number
* Z = minor rev release number

Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc.

Nightly releases will be named using the following scheme: '''image-name-0.8.0-date-buildnum.extension''', where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.

Milestone releases will be named using the following scheme: '''image-name-0.8.0-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.

Our first public release (October) will be 0.9.0, with a 1.0.0 release to follow in Spring 2011.

== Release Procedure for Yocto ==

Notes on the things that need to be done:
<pre>
Set DISTRO_VERSION in poky.conf
git commit -a -m "Pinky 3.1.2 Release"
git tag -a pinky-3.1.2 -m "Tag Pinky 3.1.2"
git archive pinky-3.1.2 | bzip2 > /tmp/poky-pinky-3.1.2.tar.bz2
scp /tmp/poky-pinky-3.1.2.tar.bz2 o-hand.com:/srv/www/pokylinux.org/releases/poky-pinky-3.1.2.tar.bz2

cd docmentation/handbook
make
scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg o-hand.com:/srv/www/pokylinux.org/releases/purple-3.2/doc/

Edit Poky web pages (three version references, two in wordpress, one on the front page)
Post on Poky Blog
Port on Poky mailing list
</pre>

== Types of Releases ==

==== Internal/Nightly Releases ====

Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.

==== Internal/QA Weekly Releases ====

These releases are the basic unit of internal progress for the Yocto project.

Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).

If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.

If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again.

Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient.

==== Internal/QA Milestone Releases ====

These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.

To generate a milestone release, a snapshot of poky master is taken and pushed to a builds/milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.

The Release Criteria are the Milestone requirements as defined in [[OSEL-1.0-schedule]]. If features are missing, a decision based on input from the management team needs to approve exceptions to the release criteria.

==== Official/public releases ====

These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!

== Release Components ==

Yocto Linux includes a number of software components to be included in each release. These include:

==== Distro Components ====

* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.

==== SDK Components ====

* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc
* SDK plugins for the following IDEs: Anjuta, Eclipse

Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example).

==== Other components ====

* gitinfo - a file which includes information about which commit the images were built from
* Changelog - a file which includes git log information between the last released version and the newly built version
* Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version

== Official/public Release Procedures ==

A sign-off process needs to be established for official/public Yocto releases, which would include QA and possibly managerial signatures.

24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:

* Move the release directory from a staging area into the public web server area
* Push the web site update including new release information
* Post the pre-written release announcement on the blog and mailing lists

SDK Generator

2010-10-23T03:29:49Z

134.134.139.72: /* Scenario 2: In-tree Poky setup with a QEMU SDK image */

==SDK documentation==
Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released.

==SDK Userspace NFS Use Scenarios and Workflow==

=== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ===

Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Sally's System Administrator set up her workstation for Poky development by doing the following:

# Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky
# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of.

Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables.

She then downloads a poky-image-sdk tarball and a QEMU kernel. Sally can copy the kernel and extract the SDK image tarball to an arbitrary work area, but she must extract the SDK image tarball using the following script:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

The documentation may recommend standard directories (e.g, ~/qemukernels/<kernel> ~/rootfs/<machinetype>), but Sally is free to choose another directory if that suits her needs better.

She then can run QEMU to automatically boot to this nfsroot with the following command:

poky-qemu {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Sally shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Sally could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 2: In-tree Poky setup with a QEMU SDK image ===

Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Roger's System Administrator sets up his workstation for Poky development by doing the following:

# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of.

Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky).

Roger sources the poky-init-build-env script, which sets up his environment for Poky builds. He then bitbakes a poky-image-sdk image, which creates a qemu kernel and SDK image tarball in his ~/poky/build/tmp/deploy/images/ directory.

Roger then extracts the SDK image tarball with:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

and then starts QEMU to boot to this using:

poky-qemu {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Roger shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Roger could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 3: Exporting a rootfs to a non-QEMU target ===

This allows developers to export a rootfs to non-qemu targets (i.e, real hardware).

First, the rootfs must be created using the poky-extract-sdk script, which creates the filesystem tree using pseudo:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

Then they can start/stop/restart the unfs server with:

poky-export-rootfs {start|stop|restart} <path to rootfs>

The developer would then configure their hardware to boot using a kernel accessed over tftp and with a rootfs pointed at the hosts's IP and exported directory.

SDK Generator

2010-10-23T03:27:34Z

134.134.139.72: /* Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image */

==SDK documentation==
Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released.

==SDK Userspace NFS Use Scenarios and Workflow==

=== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ===

Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Sally's System Administrator set up her workstation for Poky development by doing the following:

# Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky
# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of.

Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables.

She then downloads a poky-image-sdk tarball and a QEMU kernel. Sally can copy the kernel and extract the SDK image tarball to an arbitrary work area, but she must extract the SDK image tarball using the following script:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

The documentation may recommend standard directories (e.g, ~/qemukernels/<kernel> ~/rootfs/<machinetype>), but Sally is free to choose another directory if that suits her needs better.

She then can run QEMU to automatically boot to this nfsroot with the following command:

poky-qemu {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Sally shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Sally could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 2: In-tree Poky setup with a QEMU SDK image ===

Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Roger's System Administrator sets up his workstation for Poky development by doing the following:

# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-qemu-ifup command N times to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of.

Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky).

Roger sources the poky-init-build-env script, which sets up his environment for Poky builds. He then bitbakes a poky-image-sdk image, which creates a qemu kernel and SDK image tarball in his ~/poky/build/tmp/deploy/images/ directory.

Roger then extracts the SDK image tarball with:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

and then starts QEMU to boot to this using:

runqemu-nfs {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Roger shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Roger could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 3: Exporting a rootfs to a non-QEMU target ===

This allows developers to export a rootfs to non-qemu targets (i.e, real hardware).

First, the rootfs must be created using the poky-extract-sdk script, which creates the filesystem tree using pseudo:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

Then they can start/stop/restart the unfs server with:

poky-export-rootfs {start|stop|restart} <path to rootfs>

The developer would then configure their hardware to boot using a kernel accessed over tftp and with a rootfs pointed at the hosts's IP and exported directory.

SDK Generator

2010-10-23T03:27:03Z

134.134.139.72: /* Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image */

==SDK documentation==
Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released.

==SDK Userspace NFS Use Scenarios and Workflow==

=== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ===

Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Sally's System Administrator set up her workstation for Poky development by doing the following:

# Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky
# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of.

Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables.

She then downloads a poky-image-sdk tarball and a QEMU kernel. Sally can copy the kernel and extract the SDK image tarball to an arbitrary work area, but she must extract the SDK image tarball using the following script:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

The documentation may recommend standard directories (e.g, ~/qemukernels/<kernel> ~/rootfs/<machinetype>), but Sally is free to choose another directory if that suits her needs better.

She then can run QEMU to automatically boot to this nfsroot with the following command:

runqemu-nfs {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Sally shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Sally could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 2: In-tree Poky setup with a QEMU SDK image ===

Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access.

Roger's System Administrator sets up his workstation for Poky development by doing the following:

# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
# Run the poky-qemu-ifup command N times to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of.

Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky).

Roger sources the poky-init-build-env script, which sets up his environment for Poky builds. He then bitbakes a poky-image-sdk image, which creates a qemu kernel and SDK image tarball in his ~/poky/build/tmp/deploy/images/ directory.

Roger then extracts the SDK image tarball with:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

and then starts QEMU to boot to this using:

runqemu-nfs {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Roger shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Roger could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

=== Scenario 3: Exporting a rootfs to a non-QEMU target ===

This allows developers to export a rootfs to non-qemu targets (i.e, real hardware).

First, the rootfs must be created using the poky-extract-sdk script, which creates the filesystem tree using pseudo:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

Then they can start/stop/restart the unfs server with:

poky-export-rootfs {start|stop|restart} <path to rootfs>

The developer would then configure their hardware to boot using a kernel accessed over tftp and with a rootfs pointed at the hosts's IP and exported directory.

Community Guidelines

2010-10-22T23:17:01Z

134.134.139.72: added some links

Note: Highlighted items require links to be added. Dawn will add links as those pages become available.

==Overview and General Guidlines==

We want to keep the Yocto Community a great place to participate, but we need your help to keep it that way. While we have specific guidelines for various tools, in general, you should:

* '''Be nice''': Be courteous and polite to fellow members of the list.
* '''Respect other people''': No regional, racial, gender or other abuse will be tolerated.
* '''Keep it clean''': Keep the language clean (no swearing)
* '''Be helpful''': Be patient with new people and be willing to jump in to answer questions.
* '''Stay calm''': The written word is always subject to interpretation, so give people the benefit of the doubt and try not to let emotions get out of control.
* '''Keep it legal''': Make sure that you have the legal right to post your content and are not violating copyright or other laws.
* '''Adhere to Terms of Service''': All community contributions are also subject to our Terms of Service

==Read Before Contributing - Search for existing answers==
'''IMPORTANT: Before you contribute, be sure that you have done a thorough search to see if your question has already been answered.''' We've already answered many questions, and you will get a better response from people if you have already done your due diligence to find obvious or partial answers.
* Search this wiki
* Search our [http://www.yoctoproject.org/community/discussions mailing lists]
* Search the [http://www.yoctoproject.org/ Yocto Project website]

==Wiki Guidelines==

You can [http://www.yoctoproject.org/community/documentation learn more about our documentation] on the Yocto website, and if you are unfamiliar with MediaWiki syntax, we have a short how-to document with instructions for [[Using the Wiki]].

Creating articles in the wiki is a collaborative process. After you have written your piece others may:
* Edit
* Alter
* Adapt
* Add

So don't worry about making your article perfect the first time through. Don't hesitate to add content you think is useful and don't hesitate to make edits where you think you can help. There's always somebody to fix anything that breaks.

'''Posting Guidelines'''

Here are a few guidelines to keep in mind when using the Yocto wiki:
* '''Search first''': Before creating a new page or making significant contributions to a page, please do a quick search to make sure that you aren't duplicating existing content on the wiki or other areas on the Yocto Project website.
* '''Contribute''': The wiki is a resource for anyone to use. Just keep the content relevant, that is anything related to Yocto as long as it meets our other guidelines should be appropriate.
* '''Make improvements''': If you find a typo or inaccurate information, just fix it.
* '''Respect links''': Please provide [http://www.mediawiki.org/wiki/Help:Redirects redirects] when you move content. Many people use the wiki and may have created bookmarks or linked to your content.

'''The Wiki is Public'''

Everything in the wiki is public.

Every edit and every new page created goes into the [[Special:RecentChanges|recent changes]] feed, which means that people will see your edits even if you haven't yet linked to a page.

Once it's out there, it's public.
* Technically, administrators can delete things, but the wiki content may be mirrored, has feeds and is in the Google cache, so deleting something doesn't make it go away.
* When you delete content from a page, the original content will still remain in the history for that page.

==Mailing List Guidelines==

[http://www.yoctoproject.org/community/discussions More information about our mailing lists] can be found on the Yocto Project website.

'''Keep It Short'''

Remember that thousands of copies of your message will exist in mailboxes:
* Keep your messages as short as possible.
* Avoid including log output (select only the most relevant lines, or place the log on a website or in a [http://pastebin.com/ pastebin] instead)
* Don't excessively quote previous messages in the thread (trim the quoted text down to the most recent/relevant messages only).

'''Use Proper Posting Style'''

* '''No HTML or Rich Text''': Set your mailer to send only plain text messages to avoid getting caught in our spam filters.
* '''Do not top post''': Top posting is replying to a message on "top" of the quoted text of the previous correspondence. This is highly unwanted in mailing lists because it increases the size of the daily digests to be sent out & is highly confusing and incoherent. By default, most email clients top post. Please, remove the irrelevant part of the previous communication(in case of more than a single correspondence) and use bottom, interleaved posting.
* '''Using interleaved posting''': Bottom, interleaved posting is replying to the relevant parts of the previous correspondence just below the block(s) of sentences. For a comment to another block of sentences of the same quoted text, you should move below that relevant block again. Do not reply below the whole of the quoted text. Also remove any irrelevant text.
* '''Use links''': Please provide URLs to articles wherever possible. Avoid cutting and pasting whole articles especially considering the fact that all may not be interested.
* '''Don't include attached files''': Instead of including attached files, please upload your file to the [[Special:Upload|this wiki]] or another website and post a link to the file from your email message.

'''Do Not Hijack Threads'''

Post new questions or new topics as new threads (new email message). Please do not reply to a random thread with a new question or start an unrelated topic of conversation in an existing thread. This creates confusion and makes it much less likely that you will get a response.

'''Do Not Cross Post'''

Avoid posting to multiple lists simultaneously. Pick a mailing list that is most suitable for your post and just use that. CC'ing multiple lists should be avoided.

'''Subscribers Only'''

Only subscribers can post to our mailing lists. If you would like to contribute to our mailing lists, we think it is only fair that you be a subscriber. Please note that if you want to participate only occasionally, you can subscribe to a list and set your email options to digest or no mail and read the web archives when you want to catch up.

'''Additional Resources'''
* [http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquette.pdf Mailing list guidelines by Shakthi Kannan (PDF)]: Great guideline summary and examples of posting styles.

==IRC Guidelines==

[http://www.yoctoproject.org/community/discussions More information about our IRC channels] can be found on the Yocto website.

Here are a few IRC guidelines:
* '''Don't post chunks''': Avoid posting big chunks of text - use [http://pastebin.com/ pastebin] or a similar service to shorten it to a link.
* '''Register your Nickname''': To avoid confusion and make sure you always have the same name on IRC, you should [http://freenode.net/faq.shtml#userregistration register your nick].
* '''Pick the right channel''': if you aren't sure, you should start in our main #yocto channel.
* '''More information''': this [http://irchelp.org/irchelp/ircprimer.html IRC primer] for new users and the [http://freenode.net/channel_guidelines.shtml general IRC guidelines] from freenode are also useful resources.
* '''Web access''': If you don't normally use IRC and want to try it out, you can use the [http://webchat.freenode.net/ freenode Web IRC] chat.

==Bugzilla Guidelines==

We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in the [http://www.yoctoproject.org/community/bugs Yocto Bugzilla].

* '''Be patient with others''': Sometimes people post imperfect bug reports. In case of missing information kindly tell reporters how to provide it, and/or suggest what they can do to improve the bug report.
* '''Stay on topic''': Don't start endless debates on topics not directly related to the scope of a specific bug report.
* '''Use proper quoting practices''': Avoid quoting complete previous comments by stripping unneeded lines, and avoid answering above the quoted text.

What to do if you find a bug
* '''Search first''': Try to avoid filing duplicates by searching to see whether your issue has already been filed.
* '''Ask''': You can ask on our mailing lists or IRC channels to see if anyone has seen this issue before to gather more details or see if someone has a workaround.
* '''Submit a bug report''': Give us as many details as possible about what happened and how your issue can be reproduced.
* '''Track our progress''': Get feedback from the development community and track resolution status.
* '''Provide a fix''': Use the tools, project wiki and git source repository in the Yocto Project to fix the problem yourself.

Learn more about reporting bugs and our process for submitting patches.

==Guideline Violations - 3 Strikes Method==
The point of this section is not to find opportunities to punish people, but we do need a fair way to deal with people who are making our community an unpleasant place.
* First occurrence: Public reminder that the behavior is inappropriate according to our guidelines.
* Second occurrence: Private message warning the user that any additional violations will result in removal from the community.
* Third occurrence: Depending on the violation, may include account deletion or banning.

'''Notes:'''
* Obvious spammers are banned on first occurrence. This is necessary to keep the community free of spam.
* Violations are forgiven after 6 months of good behavior.
* Minor formatting / style infractions will be dealt with through education, not the 3 strikes process.
* Extreme violations of a threatening, abusive, destructive or illegal nature will be addressed immediately and are not subject to 3 strikes.
* Contact [[User:Dawnfoster|Dawn Foster]] to report abuse or appeal violations (mistakes happen & will be corrected).

==Credits==
* [http://wiki.meego.com/Community_guidelines MeeGo Community Guidelines] were the basis for the Yocto Guidelines used under the [http://creativecommons.org/licenses/by/3.0/legalcode Creative Commons Attribution 3.0 License]
* [http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Fedora Mailing List Guidelines] used as a starting point under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported] license.