How to submit a patch to OpenEmbedded

A task-oriented guide to creating a patch

Note: More details are available on the policy pages, but this document is good enough for most beginners.

• Patchwork
• Commit Policy

Let's say you create a new bitbake recipe for OpenEmbedded and you'd like to submit it for inclusion (and you've already tested that it works, of course).

Set up git

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

On Debain / 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 "Tekkub"
git config --global user.email "tekkub@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 tekkupl@gmail.com

Create and Commit your patch

1. 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 org.openembedded.dev/ # or whereever you keep your clone of the repo
git add recipes/nodejs/
git commit -s # don't use the -m option but include my signature

nodejs: added recipe for v0.2.1

* included libev-cross patch which prevents wscript from executing cross-compiled code
* included node-cross patch which forwards DEST_CPU to v8's ARCH

2. Create your patch. Use -N for N commits to be included in the patch. Use -s to add a signoff line like "Signed-off-by: Tekku B. <tekkub@gmail.com>"

git format-patch -1 # creating a patch for my only commit

If you are submitting a second version also add "--subject-prefix [v2]"

3. Send your patch to patchwork

git send-email --to=openembedded-devel@lists.openembedded.org 001-nodejs-added-recipe-for-v0.2.1

Your patch will be immediately visible on http://patchwork.openembedded.org/patch/

4. Once your patch has been accepted or rejected, create an account and update the status to "accepted" or "rejected"

4++. If you get soft-rejected (a lot of feedback), you should make changes according to the feedback, submit the next version, and update the status of the previous patch to "superseded". Remember to use `--subject-prefix` to mark the patch iteration.

Appendix

steps for people which don't have snmp access for git

Patches should not be set as attachment but inline.

If you do not have snmp 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)