Openembedded.org - User contributions [en]

OEDEM2025

2025-08-24T13:41:45Z

Michael Opdenacker: /* Dinner */ Remove Michael Opdenacker (delayed train)

==Sponsors==

Thanks to our sponsors for helping out with the food for the meeting.

Morning coffee and snacks - [https://redwiretechnologies.us/ Redwire Technologies]

Lunch - [https://www.konsulko.com/ Konsulko]

Afternoon snacks and coffee - [https://pengutronix.de/en/index.html Pengutronix]

Dinner - Qualcomm (food only, you pay for drinks)

Shameless plug for Yocto Project Dev Day on Aug 28, 2025: https://pretalx.com/ypdd-amsterdam-2025/

==Location and time==

The venue is [https://hotelarena.nl/en/ Hotel Arena] at

Gravesandestraat 55
1092 AA Amsterdam
The Netherlands

The meeting starts at 1000 on August 24, 2025 and runs until we are done, or until 1800 when we have to leave.

==Registration==

Registration is handled at https://pretix.eu/OpenEmbedded/oedem25/

Currently the ticket shop shows the room as full. You can join the waiting list if you are interested and we will try and get people to free up tickets if they can not make it.

==Agenda==

* config file handling on R/O systems, hermetic /usr, https://uapi-group.org/specifications/specs/configuration_files_specification/ (Jan Lübbe)
* boot phase variable naming (Jon Mason)
* meta-security future plans: user's feedback (Marta & Scott)
* Addressing CRA requirements (secure by default) (Marta)
* bitbake-setup: How do we make progress? What will encourage users to give it a try? (Tim)
* Application cross-development challenging (and therefore prefer Debian). Update and discussion about latest improvements related to SDKs and IDE's (Adrian)
* Future developer meetings. What do people want, what does the project need, how do we make these happen? Should we do at 20'th anniversary developer meeting in Berlin next year? (Philip)
* Email is becoming less reliable. Emails from pretix are going to spam, making it hard to organize this meeting. Patches end up tagged as spam by groups.io. Moving forward, what steps can we take to improve communication. Add tools you think might be useful below.(Philip)
** https://community.tmpdir.org/ (Discourse)

===Done===

* handling of static users across distros, https://www.freedesktop.org/software/systemd/man/latest/sysusers.d.html (Jan Lübbe)
* What comes after Sato (Ross Burton)
* Maintainers
* Megan leads a game to find out how we feel about various parts of the ecosystem, with discussion (Megan)

==Dinner==

Add your name here if you are interested in dinner after the meeting. Koen has a reservation at Shiva at 1900.

# Jon Mason
# Koen Kooi
# Jose Quaresma
# Peter Kjellerstedt
# Jan Lübbe
# Michael Olbrich
# Marta Rybczynska
# Joshua Watt
# Chuck Wolber
# Karey Wolber
# Scott Murray
# Vyacheslav Yurkov (Slava)
# Iben Ahlström
# Piotr Buliński
# Philip Balister
# Alexander Sverdlin
# Alessandro Zini
# Stefan Gloor
# Adrian Freihofer
# Nynke Zandstra
# Tim Orling
# Patrick Wicki
# Megan Knight
# Cory Hisey
# Peter Johennecken
# Kaiwan Billimoria
# Michael Halstead

===Recommended Restaurants===
* [https://www.shivarestaurant.nl/ Shiva] (Indian Food)

===Recommended bars/pubs===
* https://wynand-fockink.nl/

==Minutes==

Community Minutes: https://docs.google.com/document/d/1yu74XXNuBcEcazbzA3mpgz6W5_If1bMnm_1vWLugmNw/edit?usp=sharing

==A Photo from the first OEDEM==
[[File:OEDEM2006.jpeg]]

[[Category:OEDEM]]

OEDEM2025

2025-08-22T08:37:27Z

Michael Opdenacker: /* Dinner */ Update Michael Opdenacker

==Sponsors==

Thanks to our sponsors for helping out with the food for the meeting.

Morning coffee and snacks - [https://redwiretechnologies.us/ Redwire Technologies]

Lunch - [https://www.konsulko.com/ Konsulko]

Afternoon snacks and coffee - [https://pengutronix.de/en/index.html Pengutronix]

Dinner - Qualcomm (food only, you pay for drinks)

==Location and time==

The venue is [https://hotelarena.nl/en/ Hotel Arena] at

Gravesandestraat 55
1092 AA Amsterdam
The Netherlands

The meeting starts at 1000 on August 24, 2025 and runs until we are done, or until 1800 when we have to leave.

==Registration==

Registration is handled at https://pretix.eu/OpenEmbedded/oedem25/

Currently the ticket shop shows the room as full. You can join the waiting list if you are interested and we will try and get people to free up tickets if they can not make it.

==Agenda==

* config file handling on R/O systems, hermetic /usr, https://uapi-group.org/specifications/specs/configuration_files_specification/ (Jan Lübbe)
* handling of static users across distros, https://www.freedesktop.org/software/systemd/man/latest/sysusers.d.html (Jan Lübbe)
* boot phase variable naming (Jon Mason)
* What comes after Sato (Ross Burton)
* Megan leads a game to find out how we feel about various parts of the ecosystem, with discussion (Megan)
* Future developer meetings. What do people want, what does the project need, how do we make these happen? Should we do at 20'th anniversary developer meeting in Berlin next year? (Philip)
* Email is becoming less reliable. Emails from pretix are going to spam, making it hard to organize this meeting. Patches end up tagged as spam by groups.io. Moving forward, what steps can we take to improve communication. Add tools you think might be useful below.(Philip)
** https://community.tmpdir.org/ (Discourse)
* meta-security future plans: user's feedback (Marta & Scott)
* Addressing CRA requirements (secure by default) (Marta)
* bitbake-setup: How do we make progress? What will encourage users to give it a try? (Tim)
* Application cross-development challenging (and therefore prefer Debian). Update and discussion about latest improvements related to SDKs and IDE's (Adrian)

==Dinner==

Add your name here if you are interested in dinner after the meeting. Koen has a reservation at Shiva at 1900.

# Jon Mason
# Koen Kooi
# Jose Quaresma
# Peter Kjellerstedt
# Jan Lübbe
# Michael Olbrich
# Marta Rybczynska
# Michael Opdenacker (arriving around 20:15)
# Joshua Watt
# Chuck Wolber
# Karey Wolber
# Scott Murray
# Vyacheslav Yurkov (Slava)
# Iben Ahlström
# Piotr Buliński
# Philip Balister
# Alexander Sverdlin
# Alessandro Zini
# Stefan Gloor
# Adrian Freihofer
# Nynke Zandstra
# Tim Orling
# Patrick Wicki
# Megan Knight
# Cory Hisey
# Peter Johennecken

===Recommended Restaurants===
* [https://www.shivarestaurant.nl/ Shiva] (Indian Food)

===Recommended bars/pubs===
* https://wynand-fockink.nl/

==Minutes==

==A Photo from the first OEDEM==
[[File:OEDEM2006.jpeg]]

OEDEM2025

2025-08-15T14:56:16Z

Michael Opdenacker: Dinner: add Michael Opdenacker

How to submit a patch to OpenEmbedded

2023-08-18T17:03:07Z

Michael Opdenacker: Mark this page as obsolete and redirect to new location.

'''IMPORTANT: This page is now obsolete and will be emptied soon. It's contents have been integrated in https://docs.yoctoproject.org/next/contributor-guide/index.html. Please contribute to this document instead.'''

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

=== Subscribe to the mailing list ===

You must subscribe to the appropriate mailing-list in order to be able to send your patch(es) to mailing lists. If you attempt to send a patch to a list where you are not a member then the patch will be returned as undeliverable.

* For patches against '''OE-Core''' the mailing list is '''openembedded-core@lists.openembedded.org'''.
* For patches against '''meta-oe''' (and many others) the list is '''openembedded-devel@lists.openembedded.org'''.

See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Fixing your From identity ====

If you choose the first method: submitting your patches via e-mail.

We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:

From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"

This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
The following will ensure that your e-mails have an additional <code>From</code> field at the beginning of the e-mail body, and that maintainers accepting your patches don't have to fix commit author information manually:

git config --global sendemail.from "linus.torvalds@kernel.org"

The sendemail.from field should be just your email address, which forces Git to add an explicit From field in the body of the patch.

==== Configuring git send-email ====

You need to let git send-email know how to send e-mail from your domain, that is, how to connect to your SMTP server.

For example, here are settings for sending your e-mails through Google Mail's SMTP server:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com
git config --global sendemail.smtppass = XXXXXXXX

Of course, the above should match the e-mail address you used to subscribe to the mailing list.

==== Sending using git-send-email ====

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

Additionally for released branches, please add the branch name (such as dunfell, kirkstone, mickledore, ...) to the prefix:
--subject-prefix="mickledore][meta-oe][PATCH"

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

Please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on https://patchwork.yoctoproject.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback in a day or two it may have already been merged so do a git pull on your branch to check on that. Note that many if not most layer maintainers do '''not''' send out acknowledgement emails if the patch is accepted. Alternatively, if there is no response or merge after a few days the patch may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

Document Consolidation

2023-08-18T16:57:48Z

Michael Opdenacker: Strike out http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual as a sort of [https://wiki.yoctoproject.org/wiki/Contributors_Manual Contributors Manual].

When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)

* https://www.openembedded.org/wiki/Styleguide
* https://www.openembedded.org/wiki/Versioning_Policy
* <del>https://www.openembedded.org/wiki/Getting_started</del>
* <del>http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded</del>
* https://wiki.yoctoproject.org/wiki/Poky_Contributions
* <del>https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project</del>
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md
* https://git.openembedded.org/bitbake/tree/README
* https://git.openembedded.org/openembedded-core/tree/README.OE-Core.md
* https://www.openembedded.org/wiki/Recipe_License_Fields
* https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Document Consolidation

2023-08-16T13:37:28Z

Michael Opdenacker: Strike out https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project (done)

This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual as a sort of [https://wiki.yoctoproject.org/wiki/Contributors_Manual Contributors Manual].

When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)

* https://www.openembedded.org/wiki/Styleguide
* https://www.openembedded.org/wiki/Versioning_Policy
* <del>https://www.openembedded.org/wiki/Getting_started</del>
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
* https://wiki.yoctoproject.org/wiki/Poky_Contributions
* <del>https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project</del>
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md
* https://git.openembedded.org/bitbake/tree/README
* https://git.openembedded.org/openembedded-core/tree/README.OE-Core.md
* https://www.openembedded.org/wiki/Recipe_License_Fields
* https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Document Consolidation

2023-08-10T12:34:43Z

Michael Opdenacker: Strike out https://www.openembedded.org/wiki/Getting_started (done)

This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual as a sort of [https://wiki.yoctoproject.org/wiki/Contributors_Manual Contributors Manual].

When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)

* https://www.openembedded.org/wiki/Styleguide
* https://www.openembedded.org/wiki/Versioning_Policy
* <s>https://www.openembedded.org/wiki/Getting_started</s>
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
* https://wiki.yoctoproject.org/wiki/Poky_Contributions
* https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md
* https://git.openembedded.org/bitbake/tree/README
* https://git.openembedded.org/openembedded-core/tree/README.OE-Core.md
* https://www.openembedded.org/wiki/Recipe_License_Fields
* https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Getting started

2023-08-10T09:57:44Z

Michael Opdenacker: Now redirect to Yocto Project manual, as discussed in a meeting about the contributor guide.

See the [https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Yocto Project Quick Build] guide for details about getting started with OpenEmbedded.
See also [https://docs.yoctoproject.org/ref-manual/system-requirements.html System Requirements] for supported GNU/Linux distributions.

How to submit a patch to OpenEmbedded

2023-05-09T08:55:18Z

Michael Opdenacker: /* Fixing your From identity */ Clarify that we are adding another "From" field

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

=== Subscribe to the mailing list ===

You must subscribe to the appropriate mailing-list in order to be able to send your patch(es) to mailing lists. If you attempt to send a patch to a list where you are not a member then the patch will be returned as undeliverable.

* For patches against '''OE-Core''' the mailing list is '''openembedded-core@lists.openembedded.org'''.
* For patches against '''meta-oe''' (and many others) the list is '''openembedded-devel@lists.openembedded.org'''.

See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Fixing your From identity ====

If you choose the first method: submitting your patches via e-mail.

We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:

From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"

This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
The following will ensure that your e-mails have an additional <code>From</code> field at the beginning of the e-mail body, and that maintainers accepting your patches don't have to fix commit author information manually:

git config --global sendemail.from "linus.torvalds@kernel.org"

The sendemail.from field should be just your email address, which forces Git to add an explicit From field in the body of the patch.

==== Configuring git send-email ====

You need to let git send-email know how to send e-mail from your domain, that is, how to connect to your SMTP server.

For example, here are settings for sending your e-mails through Google Mail's SMTP server:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com
git config --global sendemail.smtppass = XXXXXXXX

Of course, the above should match the e-mail address you used to subscribe to the mailing list.

==== Sending using git-send-email ====

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

Please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on https://patchwork.yoctoproject.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

Getting started

2023-05-04T16:52:31Z

Michael Opdenacker: Provide link to Yocto docs "System Requirements" page

== Required software ==

Before being able to build you will need to install a fairly short list of required software on your host system.

'''Note:''' for a headless (i.e. non-graphical / server) machine you can skip installing SDL and xterm, these are optional; however without SDL you will not be able to run graphical OS images within QEMU.

(Lists below borrowed from the Yocto Project [https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions System Requirements] page)

=== Ubuntu / Debian ===

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
xz-utils debianutils iputils-ping

=== Fedora ===

sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
python3-pexpect findutils which file cpio python python3-pip xz

=== openSUSE ===

sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \
diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
python3-pexpect xz which

=== CentOS ===

sudo yum install -y epel-release
sudo yum makecache
sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip xz \
which

== Setup Instructions ==

At this point you have a number of different alternatives:

=== Standalone OE-Core setup ===

As OE-Core can be used to build working images entirely on its own, you can get started with it immediately.

See '''[[OE-Core Standalone Setup]]''' for instructions.

=== Systems based upon OE-Core ===

There are a number of other systems that make use of the OE-Core metadata which provide their own set of setup instructions. Here are some links to "getting started" information for these:

* [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Yocto Project]

More can be found in the [http://layers.openembedded.org layer index] (click on ''Layers'', then click on ''Filter Layers'' on the right hand side and make it so ''Distribution'' is the only ticked item.)

Getting started

2023-05-04T16:46:47Z

Michael Opdenacker: /* Setup Instructions */ Remove SHR and Angstrom, no longer maintained

== Required software ==

Before being able to build you will need to install a fairly short list of required software on your host system.

'''Note:''' for a headless (i.e. non-graphical / server) machine you can skip installing SDL and xterm, these are optional; however without SDL you will not be able to run graphical OS images within QEMU.

(Lists below borrowed from the Yocto Project Quick Start guide.)

=== Ubuntu / Debian ===

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
xz-utils debianutils iputils-ping

=== Fedora ===

sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
python3-pexpect findutils which file cpio python python3-pip xz

=== openSUSE ===

sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \
diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
python3-pexpect xz which

=== CentOS ===

sudo yum install -y epel-release
sudo yum makecache
sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip xz \
which

== Setup Instructions ==

At this point you have a number of different alternatives:

=== Standalone OE-Core setup ===

As OE-Core can be used to build working images entirely on its own, you can get started with it immediately.

See '''[[OE-Core Standalone Setup]]''' for instructions.

=== Systems based upon OE-Core ===

There are a number of other systems that make use of the OE-Core metadata which provide their own set of setup instructions. Here are some links to "getting started" information for these:

* [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Yocto Project]

More can be found in the [http://layers.openembedded.org layer index] (click on ''Layers'', then click on ''Filter Layers'' on the right hand side and make it so ''Distribution'' is the only ticked item.)

Getting started

2023-05-04T16:40:07Z

Michael Opdenacker: /* Alternative methods */ Remove this section, oe-made-easy is no longer maintained

== Required software ==

Before being able to build you will need to install a fairly short list of required software on your host system.

'''Note:''' for a headless (i.e. non-graphical / server) machine you can skip installing SDL and xterm, these are optional; however without SDL you will not be able to run graphical OS images within QEMU.

(Lists below borrowed from the Yocto Project Quick Start guide.)

=== Ubuntu / Debian ===

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
xz-utils debianutils iputils-ping

=== Fedora ===

sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
python3-pexpect findutils which file cpio python python3-pip xz

=== openSUSE ===

sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \
diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
python3-pexpect xz which

=== CentOS ===

sudo yum install -y epel-release
sudo yum makecache
sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip xz \
which

== Setup Instructions ==

At this point you have a number of different alternatives:

=== Standalone OE-Core setup ===

As OE-Core can be used to build working images entirely on its own, you can get started with it immediately.

See '''[[OE-Core Standalone Setup]]''' for instructions.

=== Systems based upon OE-Core ===

There are a number of other systems that make use of the OE-Core metadata which provide their own set of setup instructions. Here are some links to "getting started" information for these:

* [http://github.com/Angstrom-distribution/meta-angstrom/blob/master/README Angstrom]
* [http://shr-project.org/trac/wiki/Building%20SHR SHR]
* [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Yocto Project]

More can be found in the [http://layers.openembedded.org layer index] (click on ''Layers'', then click on ''Filter Layers'' on the right hand side and make it so ''Distribution'' is the only ticked item.)

How to submit a patch to OpenEmbedded

2023-02-20T17:43:56Z

Michael Opdenacker: /* A task-oriented guide to creating a patch */ Further clarification of e-mail configuration instructions

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

=== Subscribe to the mailing list ===

You must subscribe to the appropriate mailing-list in order to be able to send your patch(es) to mailing lists. If you attempt to send a patch to a list where you are not a member then the patch will be returned as undeliverable.

* For patches against '''OE-Core''' the mailing list is '''openembedded-core@lists.openembedded.org'''.
* For patches against '''meta-oe''' (and many others) the list is '''openembedded-devel@lists.openembedded.org'''.

See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Fixing your From identity ====

If you choose the first method: submitting your patches via e-mail.

We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:

From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"

This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
The following will ensure that your e-mails have a correct <code>From</code> field, and that maintainers accepting your patches don't have to fix commit author information manually:

git config --global sendemail.from "linus.torvalds@kernel.org"

==== Configuring git send-email ====

You need to let git send-email know how to send e-mail from your domain, that is, how to connect to your SMTP server.

For example, here are settings for sending your e-mails through Google Mail's SMTP server:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com
git config --global sendemail.smtppass = XXXXXXXX

Of course, the above should match the e-mail address you used to subscribe to the mailing list.

==== Sending using git-send-email ====

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

Please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on https://patchwork.yoctoproject.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

How to submit a patch to OpenEmbedded

2023-02-20T17:33:39Z

Michael Opdenacker: /* Sending patches */ Improving e-mail sending instructions

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

=== Subscribe to the mailing list ===

You must subscribe to the appropriate mailing-list in order to be able to send your patch(es) to mailing lists. If you attempt to send a patch to a list where you are not a member then the patch will be returned as undeliverable.

* For patches against '''OE-Core''' the mailing list is '''openembedded-core@lists.openembedded.org'''.
* For patches against '''meta-oe''' (and many others) the list is '''openembedded-devel@lists.openembedded.org'''.

See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Fixing your From identity ====

If you choose the first method: submitting your patches via e-mail.

We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:

From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"

This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
The following will ensure that your e-mails have a correct <code>From</code> field, and that maintainers accepting your patches don't have to fix commit author information manually:

git config --global sendemail.from "linus.torvalds@kernel.org"

==== Sending using git-send-email ====

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Settings for Gmail users ====

Here are settings for sending your e-mails through Google Mail's SMTP server:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com

You can use <code>git send-email</code>'s <code>--envelope-sender</code> option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the Gmail settings tab. Use the Send mail as selection to address you want to send email from.

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

Please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on https://patchwork.yoctoproject.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

How to submit a patch to OpenEmbedded

2023-02-20T17:12:20Z

Michael Opdenacker: /* Sending using git-send-email */ Explain why we're advising to set "sendemail.from"

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

=== Subscribe to the mailing list ===

You must subscribe to the appropriate mailing-list in order to be able to send your patch(es) to mailing lists. If you attempt to send a patch to a list where you are not a member then the patch will be returned as undeliverable.

* For patches against '''OE-Core''' the mailing list is '''openembedded-core@lists.openembedded.org'''.
* For patches against '''meta-oe''' (and many others) the list is '''openembedded-devel@lists.openembedded.org'''.

See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Sending using git-send-email ====

We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:

From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"

This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
The following will ensure that your e-mails have a correct <code>From</code> field, and that maintainers accepting your patches don't have to fix commit author information manually:

git config --global sendemail.from "linus.torvalds@kernel.org"

Here are settings for sending your e-mails through Google Mail's SMTP server:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com

You can use <code>git send-email</code>'s <code>--envelope-sender</code> option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the Gmail settings tab. Use the Send mail as selection to address you want to send email from.

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on https://patchwork.yoctoproject.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

How to submit a patch to OpenEmbedded

2022-09-02T09:23:24Z

Michael Opdenacker: /* A task-oriented guide to creating a patch */ Improve git-send-email documentation. Mention the sometimes important sendemail.from git setting.

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

=== Subscribe to the mailing list ===

You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Sending using git-send-email ====

The following will ensure that your e-mails have a correct <code>From</code> field. This field is used by <code>git am</code> to recreate commits with the right author name.

git config --global sendemail.from "ada.lovelace@gmail.com"

Here are settings for sending your e-mails through Google Mail's SMTP server:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com

You can use <code>git send-email</code>'s <code>--envelope-sender</code> option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the Gmail settings tab. Use the Send mail as selection to address you want to send email from.

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

How to submit a patch to OpenEmbedded

2022-06-29T08:31:20Z

Michael Opdenacker: /* Set up git */ Fix example e-mail

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using ada.lovelace@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

Any Google Apps account

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com

You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.

=== Subscribe to the mailing list ===

You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Sending using git-send-email ====

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

How to submit a patch to OpenEmbedded

2022-06-29T08:30:26Z

Michael Opdenacker: /* Set up git */ Use a clearer name and last name

OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

== Finding the right place for your patch ==

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].

== A task-oriented guide to creating a patch ==

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

=== Set up git ===

Properly configuring git (using tekkub@gmail.com as an example user)

On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)

sudo aptitude install git-core git-email

These are important to the commit meta-data

git config --global user.name "Ada Lovelace"
git config --global user.email "ada.lovelace@gmail.com"

Any Google Apps account

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser ada.lovelace@gmail.com

You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.

=== Subscribe to the mailing list ===

You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.

=== Committing your patch ===

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

cd oe-core/ # or whereever you keep your clone of the repo
git add meta/recipes-devtools/flex
git commit -s # don't use the -m option but include my signature

flex: backport Debian patches to fix generated code warnings

The generated parser had warnings regarding signess and return check
which makes Linux Kernel's perf tool from 3.4 release to fail without
those patches.

All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

=== Sending patches ===

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

==== Sending using git-send-email ====

To send just the top commit on your current branch (substitute mailing list address as appropriate):

git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:
--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

==== Sending via a pull request ====

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.
# Push the branch to the remote.
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.

===== Request OE contrib Write Access =====

please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
# List the repositories you're planning to contribute to.
# Include your preferred branch prefix for *-contrib repositories.

=== Backporting fixes to stable releases ===

When a bug is present on a stable branch of OE yet has been fixed in master one can request that the stable branch's maintainer accept the fix into the stable branch.
The best way to do this is generate a patch with the backport and submit it to the openembedded-core@lists.openembedded.org mailing list (CC'ing the maintainer may help the patch be reviewed for inclusion more quickly).

Patches for stable branches should be prefixed with the branch name (which is the same as the release series name), for example morty, pyro, etc.
Once you've identified the commit hash of the patch you'd like to see accepted as a backport you can generate the patch with:

git format-patch <COMMIT_HASH> -1 --subject-prefix="<BRANCH_NAME>][PATCH"

The generated patch can then be sent using the procedure described above.

== Community review ==

Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

== Appendix ==

=== Steps for people which don't have SMTP access for git ===

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).

A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.

=== Streamlining git-send-email with configuration ===

Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.

<ul>
<li>Always confirm sending (for all repositories):
<pre>git config --global sendemail.confirm always</pre></li>
<li>Set send-to email address for the repository (don't forget to specify the right address!):
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre>
</li>
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre>
</li>
</ul>

==See also==
* [[Commit Patch Message Guidelines]]
* [[Styleguide]]

[[Category:FAQ]]
[[Category:User]]

Template:Main page/news

2021-11-10T10:21:17Z

Michael Opdenacker: News: add Yocto Project Summit 2021.11

'''Recent News:'''.
* '''''2021-11-30:''''' [https://www.yoctoproject.org/yocto-project-summit-2021-11/] Yocto Project Summit 2021.11
* '''''2021-5-25:''''' [https://pretalx.com/yocto-project-summit-2021/] Yocto Project Summit 2021
* '''''2020-9-8:''''' [https://pretalx.com/yocto-project-summit-2020/] Yocto Project Summit 2020
* '''''2020-4-29:''''' [https://lists.openembedded.org/g/openembedded-core/message/137354] OpenEmbedded Happy hour

See [[NewsArchive|News Archive]] for older news.

Template:Main page/Developers

2021-11-10T10:17:55Z

Michael Opdenacker: Remove 2011.3 release

* [[:Category:Policy|Policies]]
* [[:Category:Debug build|Debugging a build]]
* [[OpenEmbedded-Core]]
* [[Organization]]
* [[:Category:Dev|'''More''']]

Documentation

2021-11-10T10:16:11Z

Michael Opdenacker: Remove out of date notice

Documentation that relates to OpenEmbedded.

== Yocto Project Manuals ==

The most up-to-date manuals relating to OpenEmbedded (in particular, the new [[OpenEmbedded-Core]]) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.

See '''[https://docs.yoctoproject.org/]''' for links to all the manuals.

== Solutions for common problems ==

* Set [[PREFERRED_PROVIDER for jpeg and jpeg-native]]

== Bitbake Manual ==

[https://docs.yoctoproject.org/bitbake/index.html Bitbake Manual]

== Other ==

Guides and HowTos:
* [https://bootlin.com/doc/training/yocto/ Bootlin's freely available Yocto Project and OpenEmbedded training materials]
* [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]
* [[How to submit a patch for dummies]]
* [[List of Executable tasks]] Usage: bitbake -c <task>

[[Category:User]]
[[Category:Dev]]

Documentation

2021-11-10T10:15:26Z

Michael Opdenacker: /* Other */ Update links to documentation - Eliminate broken one. Add link to Bootlin's materials.

Documentation

2021-11-10T10:08:06Z

Michael Opdenacker: /* Yocto Project Manuals */ Update Yocto Project docs URL

{{OutdatedWIP}}

Documentation that relates to OpenEmbedded.

== Yocto Project Manuals ==

The most up-to-date manuals relating to OpenEmbedded (in particular, the new [[OpenEmbedded-Core]]) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.

See '''[https://docs.yoctoproject.org/]''' for links to all the manuals.

== Solutions for common problems ==

* Set [[PREFERRED_PROVIDER for jpeg and jpeg-native]]

== Bitbake Manual ==

[https://docs.yoctoproject.org/bitbake/index.html Bitbake Manual]

== Other ==

Many of these are out-of-date:

Articles about Openembedded:
* [http://bec-systems.com/site/tag/openembedded articles at BEC Systems]
** [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]

Guides and HowTos:
* [[How to create a bitbake recipe for dummies]]
* [[How to submit a patch for dummies]]
* [[List of Executable tasks]] Usage: bitbake -c <task>
* [http://www.kernel-labs.org/files/openembedded-guide/openembedded-guide.html OpenEmbedded Guide by Example]
* [http://www.uv-ac.de/openembedded/ OpenEmbedded HowTo]
* [http://free-electrons.com/docs/openembedded/ Using OpenEmbedded to build embedded Linux distributions]
* [http://www.kunen.org/uC/beagle/oe_kmod.html Open Embedded - Kernel module development]

[[Category:User]]
[[Category:Dev]]

Documentation

2021-11-10T10:06:15Z

Michael Opdenacker: /* Bitbake Manual */ Update description of the BitBake manual

{{OutdatedWIP}}

Documentation that relates to OpenEmbedded.

== Yocto Project Manuals ==

The most up-to-date manuals relating to OpenEmbedded (in particular, the new [[OpenEmbedded-Core]]) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.

See the '''[http://www.yoctoproject.org/documentation Documentation]''' section on the Yocto Project website for links to all the manuals.

== Solutions for common problems ==

* Set [[PREFERRED_PROVIDER for jpeg and jpeg-native]]

== Bitbake Manual ==

[https://docs.yoctoproject.org/bitbake/index.html Bitbake Manual]

== Other ==

Many of these are out-of-date:

Articles about Openembedded:
* [http://bec-systems.com/site/tag/openembedded articles at BEC Systems]
** [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]

Guides and HowTos:
* [[How to create a bitbake recipe for dummies]]
* [[How to submit a patch for dummies]]
* [[List of Executable tasks]] Usage: bitbake -c <task>
* [http://www.kernel-labs.org/files/openembedded-guide/openembedded-guide.html OpenEmbedded Guide by Example]
* [http://www.uv-ac.de/openembedded/ OpenEmbedded HowTo]
* [http://free-electrons.com/docs/openembedded/ Using OpenEmbedded to build embedded Linux distributions]
* [http://www.kunen.org/uC/beagle/oe_kmod.html Open Embedded - Kernel module development]

[[Category:User]]
[[Category:Dev]]

Documentation

2021-11-10T10:05:15Z

Michael Opdenacker: Fix BitBake manual URL

{{OutdatedWIP}}

Documentation that relates to OpenEmbedded.

== Yocto Project Manuals ==

The most up-to-date manuals relating to OpenEmbedded (in particular, the new [[OpenEmbedded-Core]]) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.

See the '''[http://www.yoctoproject.org/documentation Documentation]''' section on the Yocto Project website for links to all the manuals.

== Solutions for common problems ==

* Set [[PREFERRED_PROVIDER for jpeg and jpeg-native]]

== Bitbake Manual ==

The [https://docs.yoctoproject.org/bitbake/index.html Bitbake Manual] is in need of update but its content should still be applicable.

== Other ==

Many of these are out-of-date:

Articles about Openembedded:
* [http://bec-systems.com/site/tag/openembedded articles at BEC Systems]
** [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]

Guides and HowTos:
* [[How to create a bitbake recipe for dummies]]
* [[How to submit a patch for dummies]]
* [[List of Executable tasks]] Usage: bitbake -c <task>
* [http://www.kernel-labs.org/files/openembedded-guide/openembedded-guide.html OpenEmbedded Guide by Example]
* [http://www.uv-ac.de/openembedded/ OpenEmbedded HowTo]
* [http://free-electrons.com/docs/openembedded/ Using OpenEmbedded to build embedded Linux distributions]
* [http://www.kunen.org/uC/beagle/oe_kmod.html Open Embedded - Kernel module development]

[[Category:User]]
[[Category:Dev]]

Documentation

2021-11-10T10:02:19Z

Michael Opdenacker: Remove broken link to OpenEmbedded Manual

{{OutdatedWIP}}

Documentation that relates to OpenEmbedded.

== Yocto Project Manuals ==

The most up-to-date manuals relating to OpenEmbedded (in particular, the new [[OpenEmbedded-Core]]) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.

See the '''[http://www.yoctoproject.org/documentation Documentation]''' section on the Yocto Project website for links to all the manuals.

== Solutions for common problems ==

* Set [[PREFERRED_PROVIDER for jpeg and jpeg-native]]

== Bitbake Manual ==

The [http://docs.openembedded.org/bitbake/html/ Bitbake Manual] is in need of update but its content should still be applicable.

== Other ==

Many of these are out-of-date:

Articles about Openembedded:
* [http://bec-systems.com/site/tag/openembedded articles at BEC Systems]
** [http://bec-systems.com/site/456/capture-oe-source-changes How to Capture OE Source Code Changes to a Package]

Guides and HowTos:
* [[How to create a bitbake recipe for dummies]]
* [[How to submit a patch for dummies]]
* [[List of Executable tasks]] Usage: bitbake -c <task>
* [http://www.kernel-labs.org/files/openembedded-guide/openembedded-guide.html OpenEmbedded Guide by Example]
* [http://www.uv-ac.de/openembedded/ OpenEmbedded HowTo]
* [http://free-electrons.com/docs/openembedded/ Using OpenEmbedded to build embedded Linux distributions]
* [http://www.kunen.org/uC/beagle/oe_kmod.html Open Embedded - Kernel module development]

[[Category:User]]
[[Category:Dev]]