A list of projects, companies and other people using OE as well as some quotes from OE users.

== Commercial ==
* 4G-Systems are using it for the [http://meshcube.org Meshcube], see [http://www.meshcube.org/meshwiki/OpenEmbeddedDevelopment]
* Dream Multimedia TV are using it for their Dreambox 702x, see [http://developer.elitedvb.net/listprojects.php?curr_dir=80]
* [http://www.mn-solutions.de M&N Solutions] is using it for it's MNCI "Ramses" device for software release 5.4. They use a local derivate of OE for their radio hand-held terminals RT3000 and RT4000 and for their fork-lift terminal RT2100.
* [http://www.toradex.com Toradex] are using it for their Colibri development boards
* [http://www.axon.tv/ Axon Digital Design] builds small Linux based firmwares for some of their modular HDTV boards.
* [http://www.emqbit.com/ emQbit] is using it for their development boards
* [http://openmoko.com/ OpenMoko] is using it for the OpenMoko SmartPhone Distribution
* Techsol is using it for their [http://www.medallionsystem.com/ Medallion] boards.
* [http://www.gumstix.com/ Gumstix] is using OpenEmbedded for their small form factor Basix, Connex, and Verdex motherboards
* [http://buglabs.net Bug Labs] is using Poky Linux on the [http://buglabs.net/products BUG] device, a portable and modular Linux platform.
* [http://bec-systems.com BEC Systems] is helping customers use OE in commercial projects.
* [http://www.sidebranch.com Sidebranch] uses OE to help companies get on speed with embedded Linux in an open manner.
* Hark Technologies uses OE for their [http://linuxdevices.com/news/NS7648514863.html AT91SAM9260 SBC]
* [http://www.ronetix.at Ronetix] are using [http://www.kaeilos.com KaeilOS] it for their development boards
* Palm is using OpenEmbedded to build Palm [http://developer.palm.com/ webOS]
* [http://www.mvista.com/ MontaVista Software, Inc.] includes BitBake and OpenEmbedded based metadata collections as part of their [[MVL6]] product.
* [http://www.koansoftware.com/ KOAN] use OpenEmbedded (and BitBake) as foundation of their product [http://www.kaeilos.com KaeilOS] industrial grade embedded linux.
* [http://www.kernelconcepts.de/en/ kernel concepts] makes use of OpenEmbedded in its product [http://www.mucross.com µCross]

== Inhouse Usage ==
* AMD: internal work on distributions for a thin client
* [http://www.openedhand.com Openedhand] : Internal development work and custom images
* Siemens: internal work in R&D
* TI: internal work on distributions for developer boards
* [http://www.digital-cube.co.kr Digitalcube] : internal work in R&D for developer boards and PMP
* [http://www.kernelconcepts.de/en kernel concepts] : Internal R&D tasks and demo images for customers.
* NXP Semiconductors: Custom images & distributions for research purposes with third parties.
* [http://www.tid.es/netvehicles/tools.htm Telefonica I+D Networked Vehicles Division] : R&D tasks in automotive field. OE is used for vehicle On Board Units and infrastructure Road Side Units.
* [http://www.atmel.com Atmel]: demos and documentation on all AT91 ARM based products available on [http://www.linux4sam.org www.linux4sam.org] : are using [http://www.angstrom-distribution.org Ångström]/OE.
* [http://www.mentorel.com Mentorel]: demo images for customers using [http://www.angstrom-distribution.org Ångström]/OE.
* [http://www.slimlogic.co.uk SlimLogic]: Customer and internal R&D projects.
* [http://www.eccam.com Eccam]: is using [http://www.angstrom-distribution.org Ångström]/OE in R&D projects - like [http://www.eccam.com/opengles_map.php this map rendering demo].

== Education and Research ==
* University of Twente: http://www.freeband.nl/project.cfm?id=494&language=en
* University of California, San Diego: https://wiisard.org/
* University of Frankfurt: ELAN Project (E-Learning in Mobile Ad-hoc Networks)

== Open Source ==
* All [http://www.angstrom-distribution.org Ångström] releases are based on OE
* All [http://openzaurus.org OpenZaurus] releases >= 3.5.1 are based on OE
* All [http://opensimpad.org OpenSIMpad] releases >= 0.9.1 are based on OE
* [http://www.nslu2-linux.org/wiki/OpenSlug/HomePage OpenSlug] distribution for the Linksys NSLU2 and the [http://www.nslu2-linux.org/wiki/Unslung/HomePage Unslung] distribution for the NSLU2 as well.
* [http://owmnr.ifaistos.awmn.net OWMNR] - Open Wireless Metropolitan Network Router. OE based distribution for creating a wireless router.
* [http://gpephone.linuxtogo.org GPE Phone Edition] uses OE for VMWare demo images and to build SDKs.
* The [http://jlime.com JLime] Linux distribution uses OE for all current releases.
* All [http://dev.openbossa.org/mamona Mamona] releases are based on OE
* [http://jalimo.org Jalimo] maintains the Java build recipes in OE and provides binary packages for Maemo-based devices.
* The italian company [http://www.koansoftware.com KOAN] adopted OE in February 2009 as foundation for their [http://www.kaeilos.com KaeilOS] distribution since its release 4.0

== Open Hardware ==
* [http://wiki.emqbit.com/free-ecb-at91 Free ECB_AT91] - An open Single Board computer that [http://wiki.emqbit.com/openembedded runs openembedded].

== Quotes ==
''Well, looks like openembedded has really sorted out my install/setup nightmare for this eval board... thanks you guys. In the last 4 hours, i've gotten more done with this board than i have in 6 months.''

''I will try and add an smdk2410.conf machine file to the setup soon... not that i expect it'll be useful to a lot of people, but i'll try to at least document it so that other machines can be supported easily enough.''

''Well I just got OE set up and I've been really impressed so far.''

''OE takes all of the hassle out of cross-compiling.''

[[Category:Community]]

Java

2010-11-24T07:53:31Z

Eric: Undo revision 3278 by Yjytalamago (Talk)

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+), a large bunch of the Jakarta commons libraries and stuff like BSF, POI, log4j, logkit and ORO are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=== Ant ===
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Despite all this troubles Ant (1.7.1) is available and supported as an application which can be run from build recipes.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded, you need to install a JDK, Kaffe or Jikes and then make modifications to the PATH variable in order to allow the
build use the runtime or compiler. '''These suggestions are wrong!''' The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring (add info about what and where)=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following line to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

==ant-native==
If you need Ant to build your recipe add ''ant-native'' to your recipes dependencies. This will allow you to call the built-in Ant executable.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable.

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==Ant integration for build recipes==
Although ''ant'' can be used as a standalone tool there is no direct support for it in the recipe. E.g. the Debian buildsystem (CDBS) has support classes that can be used for Ant-based Java sourcepackages. It would be nice to have this too for OpenEmbedded.

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

== Q: I need to solve a specific Java problem in OE and want to throw money at this. Whom can I contact? ==
The [http://jalimo.org Jalimo] project has done a lot of Java work in OE and are available for contract work. You can also ask for experienced devs on the openembedded-devel mailing list.

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

JavaRecipeHowto

2010-11-24T07:53:16Z

Eric: Undo revision 3279 by Yjytalamago (Talk)

How to submit a patch to OpenEmbedded

2010-11-24T07:52:36Z

Eric: Undo revision 3280 by Yjytalamago (Talk)

== 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 [[How to create a bitbake recipe for dummies|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

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

=== Create and Commit your patch ===

1. First you have to subscribe to the mailing-list '''openembedded-devel@lists.openembedded.org''' to be able to post your patch. See [[Mailing lists]]

2. 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

3. 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="PATCH v2"

4. 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/

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

5++. 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 smtp access for git ===

Patches should not be set 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 Documentation/email-clients.txt in linux
kernel sources.

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

ToolingUseCases

2010-11-24T07:52:21Z

Eric: Undo revision 3281 by Yjytalamago (Talk)

= Overview =

This page defines primary user-roles in using OpenEmbedded. The material resulted from some discussions at OEDEM that were truncated due to time restrictions.

= Goals =

The goal of identifying user-roles is to be able to categorize different tooling scenarios, and what types of users will be interested in specific features. Tools designed for role type may not be appropriate for other roles. For example, a GUI for recipe editing may not be helpful for an application developer that's looking to remote debug their application on a target. On the other hand, a simple press-button build GUI may not be interesting for a seasoned OE hacker.

= Role Types =

== Application Developer ==

The application developer's main concern is developing and testing any given application on a target system. This person does not care nor want to learn much about the internal details of the build system or package metadata. The best possible case is that these systems are transparent and the developer is able to easily build and deploy applications to the target device.

=== Primary Tooling Requirements ===

* Build Application for Target
* Debug Application on Target
* Generate build system artifacts for Application (recipes)

=== Ideas ===

* Develop an Eclipse plugin to "Export project as Recipe"
** For CDT (C/C++) projects make, automake recipes are generated
** For Java projects java-library based recipies are generated
** Python?
** Initially wizard can just create a tarball of project sources
** Integration with SCM plugins?
** How to capture project dependencies?
** How to define export target? OTE, cloud, etc.?

== Distro Developer ==

Distro developer's concern is to compose packages and configurations into a working system. The distro developer has deep knowledge of packages available in Linux, and how sets of packages work well together. Additionally the distro developer is not afraid to work deeply within the build system to make it better, and to produce better, more maintainable package metadata and target systems.

=== Primary Tooling Requirements ===

* Build system image
* Create/edit distro definitions
* Debug build problems
* Visualize package dependencies

== Package Developer ==

The package developer is often a mix of the previous two role types. Often they have some knowledge of the build system and applications and build tools used to create those applications. They typically act as a bridge between pure application developers and the resulting target system that's produced. Package developers write recipes, debug applications, and debug build problems.

=== Primary Tooling Requirements ===

* Create and edit package metadata
* Easily integrate package metadata into build system
* Debug build issues
* Visualize Package Dependencies

=== Notes ===

* OpenEmbedded Tools for Eclipse (OTE) was designed for this role type.

== Target System User ==

This role type typically is not exposed to package metadata, cross compilers, or build systems. They are system users, and as such, at times want to:

* Generate system
* Update system
* Install packages
* Configure package metadata

=== Primary Tooling Requirements ===

* install binary package on target
* find new packages and package updates for target
* resolve package dependencies

=== Ideas ===

* A GUI application that runs with a local install of OE that can
** present a wizard style interface that allows users to build system images
** download overlays and other non-default artifacts
** select images, packages, distros, machines, etc.
** have a simple 'installer' that does not require knowledge of bitbake/OE internals

[[Category:OEDEM]]

Devshell

2010-11-24T07:52:05Z

Eric: Undo revision 3282 by Yjytalamago (Talk)

'''Q: I want to get a shell where all the variables OE and the recipe defines (CC, CFLAGS, ARCH, ...) are set.'''

When a build fails, it is often useful to interactively build the part that is failing. Because OE sets up the build environment, it may not be obvious how to quickly reproduce such an environment. This is where the interactive devshell can help you.

== Background ==

One technique that can be use is:

* cd into tmp/work/<failing package dir>/<failing package build dir>
* copy ../temp/run.do_compile.. x (or do_install or whatever task is failing)
* edit x and replace the do_compile (at the end of the file) function call w/ bash
* ./bash --norc (you now have a shell w/ the environment set up properly for doing a build)
* make (debug issues, etc)
* exit (when done to go back to shell without run.do_compile settings)

== Setup devshell ==

The above is mainly for illustration purposes. A better/quicker way to set up a development shell is this.

* Add 'devshell' to your local.conf's INHERIT variable and enjoy the power of devshell by running it like this:

bitbake -c devshell <target>

* You now have all the environment variables set up to correctly to run configure, make, etc.

The following variables affect the terminal handling:

TERMCMD = "${SCREEN_TERMCMD}"
TERMCMDRUN = "${SCREEN_TERMCMDRUN}"

# Some common terminal programs to choose from
GNOME_TERMCMD = 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE"'
GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x $SHELLCMDS'
SCREEN_TERMCMD = 'screen -D -m -t "$TERMWINDOWTITLE"'
SCREEN_TERMCMDRUN = '${SCREEN_TERMCMD} $SHELLCMDS'
XTERM_TERMCMD = 'xterm -T "$TERMWINDOWTITLE"'
XTERM_TERMCMDRUN = '${XTERM_TERMCMD} -e $SHELLCMDS'
KONSOLE_TERMCMD = 'konsole -T "$TERMWINDOWTITLE"'
KONSOLE_TERMCMDRUN = '${KONSOLE_TERMCMD} -e $SHELLCMDS'

== How to get a Screen-Devshell working ==

Using the above variables create you a devshell. Unfortunatelly you can't see anything because a new screen session is created - not a new tab in the existing session. Just use a new (SSH) connection to your (remote) account and list your screen sessions with screen -list. The last one should be your devshell and you can connect to it with screen -r <id>.

== X11 connection rejected because of wrong authentication ==

Sometimes if you try to run devshell remote over SSH with X11 redirection this error occurs:

X11 connection rejected because of wrong authentication.
ERROR: function do_devshell failed

The problem seems to be the XAUTHORITY handling. The following part in .profile helped some users.

if [ -e "$HOME/.Xauthority" ] ; then
export XAUTHORITY="$HOME/.Xauthority"
fi

[[Category:FAQ]]
[[Category:Debug build]]

Styleguide

2010-11-24T07:51:52Z

Eric: Undo revision 3283 by Yjytalamago (Talk)

= Naming Conventions =

[[Versioning Policy|Use $packagename_$version.bb]]

= Format Guidelines =

* No spaces are allowed behind the line continuation symbol
* The correct spacing for a variable is FOO = "BAR".
* Use quotes on the right hand side of assignments: FOO = "BAR"
* Comments inside bb files are allowed using the '#' character at the beginning of a line.
* Use spaces for indentation as developers tends to use different amount of spaces per one tab.
* Indentation of multiline variables such as SRC_URI is desireable.

= Style Checking tools =

Please run ./contrib/oe-stylize.py on your recipes before submitting them.

= Style Guidelines =

* Put the ''inherit'' declaration after the initial variables are set up and before any custom ''do_'' routines. This is flexible as ordering is often important.
* If you define custom ''do_'' routines, keep them in the order of the tasks being executed, that is:
** do_fetch
** do_unpack
** do_patch
** do_configure
** do_compile
** do_install
** do_package
** do_stage

* Don't use ''cp'' to put files into staging or destination directories, use ''install'' instead.
* Don't use ''mkdir'' to create destination directories, use ''install -d'' instead.

* There is a standard set of variables often found in a .bb file and the preferred order (to make the file easily readable to seasoned developers) is
** DESCRIPTION
** AUTHOR
** HOMEPAGE
** SECTION
** PRIORITY
** LICENSE
** DEPENDS
** RDEPENDS
** RRECOMMENDS
** RSUGGESTS
** PROVIDES
** RPROVIDES
** RCONFLICTS
** SRCDATE
** PV
** PR
** SRC_URI
** S
** inherit ...
** build class specific variables, i.e. EXTRA_QMAKEVARS_POST
** task overrides, i.e. do_configure
** PACKAGE_ARCH
** PACKAGES
** FILES

= Example Recipe =

<pre>
DESCRIPTION = "X11 Code Viewer"
AUTHOR = "John Bazz <john.bazz@example.org>"
HOMEPAGE = "http://www.example.org/xcv/"
SECTION = "x11/applications"
PRIORITY = "optional"
LICENSE = "GPLv2"
DEPENDS = "libsm libx11 libxext libxaw"
RDEPENDS = "shared-mime-info"
RRECOMMENDS = "ctags"
RCONFLICTS = "xcv2"
SRCDATE = "20060815"
PV = "0.0+cvs${SRCDATE}"
PR = "r5"

# upstream does not yet publish any release so we have to fetch last working version from CVS
SRC_URI = "cvs://anonymous@xcv.example.org/cvsroot/xcv;module=xcv \
file://toolbar-resize-fix.patch;patch=1"

S = "${WORKDIR}/xcv/"

inherit autotools

do_configure_prepend() {
rm ${S}/aclocal.m4
}

do_install() {
install -d ${D}${bindir}
install -d ${D}${mandir}/man1

install -m 0755 xcv ${D}${bindir}/
install -m 0644 xcv.1.gz ${D}${mandir}/man1/
}
</pre>

= PR variables with recipes that use INC files =
When recipe include files are used, the PR handling gets kind of messy. Its a pain to have to audit the PR in all the dependent recipes when you change something in an INC file. We usually use the following solution:

<pre>
recipe: PR = "${INC_PR}.1"

inc file: INC_PR = "r1"
</pre>

When converting existing recipes to use INC_PR, set the initial INC_PR to the maximum of the current PRs.
[[Category:Policy]]

Required software

2010-11-24T07:51:21Z

Eric: Undo revision 3285 by Yjytalamago (Talk)

= OpenEmbedded's Software Requirements =

This page is the reference of what software is needed. But [[OEandYourDistro]] is likely much faster in getting you that software actually installed.

To use the OE build system the following software is required on your system:
* [http://www.python.org/ Python] (Version 2.5.0 or 2.6.x for latest development version of bitbake)
** Note that you may also need certain development files for Python e.g. for bitbake's setup.py to work. Depending on the distribution you use you may want to look for a package called "python-dev", "python-devel", or similar.
* [http://www.gnu.org/software/patch/patch.html GNU Patch] (Version 2.5.9 or later, see ftp://alpha.gnu.org/gnu/diffutils/ . It is a "testing release" and is not mirrored on the GNU mirrors.)
* [http://www.gnu.org/software/m4/m4.html GNU m4]
* [http://www.gnu.org/software/make/ GNU make] (Version 3.80 or later for hh.org kernels)
* [http://psyco.sourceforge.net/ Psyco JIT Compiler] is recommended to increase performance (32bit only)
* [http://www.perl.org/ perl] (needs newer than 5.0, how much newer? probably at least 5.6.2)
* [http://invisible-island.net/diffstat/diffstat.html diffstat]
* [http://developer.berlios.de/projects/bitbake bitbake]

== Tools to download source files ==
* wget
* curl
* ftp
* [http://www.nongnu.org/cvs/ cvs]
* [http://subversion.tigris.org/ subversion]
* [http://git.or.cz/index.html git]

== Tools to verify integrity of the downloaded sources ==
* md5sum
* sha256sum

== Tools to unpack sources ==
* tar
* bzip2
* gzip
* unzip

== Tools to build the various *-doc packages==
* [http://www.jclark.com/jade/ Jade] or [http://www.netfolder.com/DSSSL/ OpenJade]
** I don't know which of these is preferred
* [http://sourceforge.net/projects/docbook/ Docbook] DTDs and DSSSL stylesheets
* [http://sgmltools-lite.sourceforge.net/ sgmltools], called "sgmltools-lite" too
* [http://sources.redhat.com/docbook-tools/ docbook-utils]
** docbook-utils download is hard to find; look in ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES
* [ftp://ftp.gnu.org/pub/gnu/texinfo/ Texinfo]
* [http://www.nongnu.org/texi2html/ texi2html] (Perl script that converts Texinfo to HTML)

== Other packages ==
* [http://www.gnu.org/software/sed/sed.html GNU sed] 4.x
* [http://www.gnu.org/software/bison/bison.html Bison]
* bc (binary calculator), if you want to build a Zaurus 2.4 or any of the collie kernels
* glibc headers (libc6-dev in Debian, glibc-devel in RPM based (in PLD also glibc-static is needed))
* [http://www.pcre.org/ pcre headers] (Perl 5 Compatible Regular Expression Library, required for e.g. konqueror-embedded)
* SDL headers to build qemu-native (apt-get install libsdl1.2-dev under Ubuntu/Debian)
* [http://www.mktemp.org/mktemp/ mktemp] (required by quilt and used in some package patches)
* help2man - Create simple man pages from --help output

There is an ongoing effort to accurately document the required software within the OpenEmbedded and ultimately, this will be reflected in the ASSUME_PROVIDED variable.

[[Category:User]]

Using IceCC

2010-11-24T07:51:06Z

Eric: Undo revision 3286 by Yjytalamago (Talk)

== IceCC and OE ==
It is possible to compile on a cluster of machines with OE, and quite easily so. This code is still somewhat experimental, but should rapidly stabilize thanks to the work that Ifaistos has put into it recently and previous work from likewise and zecke (I hope I did not forget anyone). You need to take the following steps to prepare for compilation with icecc. How to set up icecc itself is beyond this intro.

* Put ''INHERIT += "icecc"'' in your local.conf
* copy the customized [http://bugs.openembedded.org/attachment.cgi?id=1032&action=view create-icecc-env.sh] script to /path/to/your/oe/root/tmp/ and make it executable.
* set ''ICECC_ENV_EXEC = /path/to/your/oe/root/tmp/create-icecc-env.sh'' in your local.conf
* set ''ICECC_PATH = /usr/bin/icecc'' in your local.conf (be sure this matches the output of 'which icecc')

User now can specify if certain packages or packages belonging to class should not use icecc to distribute compile jobs to remote machines, but handled localy, by defining ICECC_USER_CLASS_BL and ICECC_USER_PACKAGE_BL with the appropriate values in local.conf

=== ICECC config ===

#
# Nice level of running compilers
#
# ICECC_NICE_LEVEL="5"
ICECC_NICE_LEVEL="5"
#
# icecc daemon log file
#
# ICECC_LOG_FILE="/var/log/iceccd.log"
ICECC_LOG_FILE="/var/log/iceccd.log"
#
# Identification for the network the scheduler and daemon run on.
# You can have several distinct icecc networks in the same LAN
# for whatever reason.
#
# ICECC_NETNAME=""
ICECC_NETNAME="oe"
#
# You can overwrite here the number of jobs to run in parallel. Per
# default this depends on the number of (virtual) CPUs installed.
#
# ICECC_MAX_JOBS=""
ICECC_MAX_JOBS="3"
#
# This is the directory where the icecc daemon stores the environments
# it compiles in. In a big network this can grow quite a bit, so use some
# path if your /tmp is small - but the user icecc has to write to it.
#
# ICECC_BASEDIR="/var/cache/icecc"
ICECC_BASEDIR="/var/cache/icecc"
#
# icecc scheduler log file
#
# ICECC_SCHEDULER_LOG_FILE="/var/log/icecc_scheduler.log"
ICECC_SCHEDULER_LOG_FILE="/var/log/icecc_scheduler.log"
#
# If the daemon can't find the scheduler by broadcast (e.g. because
# of a firewall) you can specify it.
#
# ICECC_SCHEDULER_HOST=""
ICECC_SCHEDULER_HOST=""

=== Local Configuration ===

A sample local.conf entry for icecc that does not distribute compiles jobs for native packages looks like this.
Change the paths to match your setup

PARALLEL_MAKE = "-j 10"
ICECC_PATH = "/usr/bin/icecc"
ICECC_ENV_EXEC = "/proj/oplinux-0.2/op-linux/branches/oplinux-0.2/tmp/icecc-create-env"
ICECC_USER_CLASS_BL = " native"
INHERIT += "icecc"

=== Successes and Failures ===

This whole explanation is probably highly dependent on the icecc version used. Please do add success reports here. Also note that a lot of packages turn PARALLEL_MAKE off, as they break if compiled on a single machine, although i have noticed that they do not fail under icecc. Any feedback on this would be helpful

* mixing versions of the icecc package can create problems. For example the icecc package from dapper and edgy are incompatible.
* I (Laibsch) have a working setup between two edgy machines now. I had trouble until I set ICECC_NETNAME and ICECC_SCHEDULER_HOST to the respective, pingable hostnames of the machines. This is weird since I am on a LAN (192.168.1.x) for both machines and there is no firewall.

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

Upgrading packages

2010-11-24T07:50:51Z

Eric: Undo revision 3287 by Yjytalamago (Talk)

Please follow these steps when upgrading a package to a more recent version. This is not to be seen as dogma, but rather as best practice. There are basically two cases we need to consider:

# You do want to keep the version of the bb file that is in OE now (somebody else needs this particular version)
# You don't.

Make sure you add an appropriate entry in checksums.ini and run the file through contrib/source-checker/oe-checksums-sorter.py if the new version fetches new sources.

= You do not need to keep the last version of the package =

# Use "[http://www.kernel.org/pub/software/scm/git/docs/git-mv.html git-mv] packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb" so that we don't accumulate unecessary cruft.
# make further changes to packages/$pkg/$file_v2.bb as appropriate.
# At the very minimum do a compilation test "bitbake $file" to make sure the new package does at least fetch and compile.
# inspect the output of "git diff packages/$pkg/". Is this really what you want to commit?
# Final step, publish your work. "git commit packages/$pkg/ && git push". Include conf/checksums.ini in your commit, if appropriate (see above).

= You do want to keep the last version of the package =

Same as above, except instead of the first step:

cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb
git-add packages/$pkg/$file_v2.bb

= Removing recipes =

Although preventing the accumulation of cruft in the repository is good, you should take into account that distributions may be using a certain recipe and depend upon it. Therefore, before removing a recipe from the repository, do a grep in the 'conf/distro' directory. If the version you are going to remove is being explicitly used, send the respective patch to the development mailing list for 'RFC' first.

: This is too restrictive and I think above paragraph was added to this page without a directive from the core team who should have been the one to decide. preferred-om-2008-versions.inc looks down virtually all recipes. In essence, the above requirement for RFC translates into "all old versions have to accumulate in HEAD or an RFC for their removal sent". I don't think that is what we want. I will certainly not follow that like a slave for packages that I maintain (For example, I will update libassa in a minute to 3.5.0 without keeping 3.4.2 around and wasting my time on re-libtoolizing an obsolete version of a fringe package. Sorry). --[[User:Laibsch|Laibsch]] 22:07, 18 May 2009 (UTC)

[[Category:Policy]]

Adding a new Machine

2010-11-24T07:50:37Z

Eric: Undo revision 3288 by Yjytalamago (Talk)

== Kernel configuration ==

# Find out which kernel version your custom kernel is (e.g. 2.6.27)
# Extract the diff: <tt>diff -Nurd linux-2.6.27/ linux-2.6.27-mymachine/</tt> (this step is optional if you already have a diff)
# Add <tt>DEFAULT_PREFERENCE_mymachine = "1"</tt> and <tt>SRC_URI_append_mymachine = "file://mymachine.diff"</tt> to <tt>linux_2.6.27.bb</tt>
# Put <tt>defconfig</tt> in <tt>recipes/linux/linux-2.6.27/mymachine/defconfig</tt>

If you really, really need to be ''special'' (which you really don't need, but companies seem to feel better when their name is plastered all over the place e.g. <tt>linux-mycompany_2.6.27.bb</tt>) you can create your ''own'' kernel recipe with the naming options you mentioned, then please use <tt>linux.inc</tt> to the basics working well. If even that is not ''special'' enough, then well, you are on your own.

By reusing a <tt>linux_2.6.xx</tt> recipe you can easily see what kind of patches other machines are applying and how issues with that kernel get solved.

== General steps and traps ==

Most of the time people that add new hardware to OE go through something like this (ARM example):

# Add <tt>mymachine.conf</tt>, <tt>linux-mymachine_2.6.xx.bb</tt>, <tt>openmymachine.conf</tt> distro
# Complain toolchain doesn't build, copy over versions from angstrom to get it fixed
# Complain their device doesn't boot, change defconfig to support EABI to get it fixed
# Complain NFS doesn't work, change defconfig to get that fixed

The toolchain problems wouldn't have been there if people had used an existing, working distro like angstrom, the kernel issues mentioned above are all handled automagically by linux.inc.

So people, please start by reusing existing things and creating your own stuff '''when need arises''', not when NIH arises.

== Further comments and information ==

* [http://docs.openembedded.org/usermanual/usermanual.html#commonuse_new_machine Adding a new Machine], Chapter 5. Common Use-cases/tasks, OpenEmbedded User Manual
* where available, don't forget to provide an URL to the machine's homepage in the machine configs for those who want to know more about it.

[[Category:Dev]]
[[Category:Machine]]

How to create a bitbake recipe for dummies

2010-11-24T07:50:19Z

Eric: Undo revision 3289 by Yjytalamago (Talk)

== Introduction ==

Currently only limited documentation is available on how to create a bitbake recipe. This article is a stub.

* [http://www.gumstix.net/Setup-and-Programming/view/Build-system-overview/Hello-world-tutorial/111.html Gumstix Hello world tutorial]
* [http://www.google.com/search?hl=en&q=bitbake+recipe+site:lists.linuxtogo.org/pipermail/openembedded-devel/ OpenEmbedded Mailing List Archives ]

== Recipe Template ==

Every recipe should start like this (pretend the package name is CHANGME:

DESCRIPTION = ""
HOMEPAGE = ""
LICENSE = ""
DEPENDS = ""
SRC_URI = " \
"
# SRC_URI could also point to a git repository, eg:
# SRC_URI = " git://host:port/path/to/repo.git;branch=win;protocol=ssh;user=username"

# any .patch files included here will be auto-magically applied, increasing the -p level until it sticks.
# SRC_URI = "file://omap_ctrl_readl.patch"

PR = "r0" # Package Revision, Update this whenever you change the recipe.

# For tarball packages (as opposed to git / svn which include the commit in the URI)
SRC_URI[md5sum] = ""
SRC_URI[sha256sum] = ""
S = "${WORKDIR}/CHANGEME-${PV}"
do_configure () {
./configure --prefix=${prefix}
}
do_compile () {
make
}
do_install () {
DESTDIR=${D} oe_runmake install
}

* '''PV''' refers to the revision. I.E. PV=0.2.1 for nodejs_0.2.1.bb

== Examples ==

=== wrapped with make ===

This example shows waf wrapped in make

DESCRIPTION = "nodeJS Evented I/O for V8 JavaScript"
HOMEPAGE = "http://nodejs.org"
LICENSE = "MIT"
DEPENDS = "openssl"
SRC_URI = " \
http://nodejs.org/dist/node-v${PV}.tar.gz \
file://libev-cross-cc.patch \
file://node-cross-cc.patch \
"
SRC_URI[md5sum] = "c6051dd216817bf0f95bea80c42cf262"
SRC_URI[sha256sum] = "5bb7d084b2138ce43fcb34739ed894379c450a1dd569a1c710405bc39d2861c2"
S = "${WORKDIR}/node-v${PV}"
do_configure () {
./configure --prefix=${prefix} --without-snapshot
}
do_compile () {
make
}
do_install () {
DESTDIR=${D} oe_runmake install
}

=== make ===

TODO

=== autotools ===

TODO

=== scons ===

TODO

=== waf ===

[[Category:FAQ]]
[[Category:Dev]]

GitServerSetup

2010-11-24T07:50:04Z

Eric: Undo revision 3290 by Yjytalamago (Talk)

= Git Service Overview =

Our git services are hosted on git.openembedded.org. There is a user called git and the repositories are located within /home/git/repositories. There is one repository for managing gitosis itself and currently one called openembedded.git with our metadata. git, webgit and gitosis are installed as debian packages, /etc/gitweb.con is pointing to /home/git/repositories. git-daemon is running as a serv the service configuration can be found in /var/services/git-daemon/run and it points to /home/git/repositories as configuration as well.

= Service Infrastructure =
== gitosis ==
Installed with debian. Clone :gitosis-admin if you are part of the admin team

== gitweb ==
/etc/gitweb.conf, it will list repositories from /home/git/repositories that have the gitweb flag in the object dir. This is the case for openembedded.git

== git-daemon ==
It is running as runsv service. This means there is a /var/run/service/git-daemon/ directory and inside the run file is the command of git-daemon. As basepath it is pointing to /home/git/repositores. Everything with a special flag inside the repository will be exported via git-daemon. This is the case for the openembedded.git repository

= Managing and Troubleshooting =
== Adding new keys ==
You will need admin rights. Then you can git-clone git@git.openembedded.org:gitosis-admin. You can add a key to keydir. Use name.pub for the key, then you can add name to the gitosis.conf. Commit your change and then git-push and the guy is able to push afterwards.

== How the commit mails and ciabot work ==
In the openembedded.git repository there is the activated "update" hook. At the end of this script git-notify in /home/git is called. git-notify was copied from the wine project at a certain date, see the top of the file.

== Troubleshooting ==
Add loglevel = DEBUG below [gitosis] (2nd line). Then you get more output when login fails or no permissions are given.

[[Category:Dev]]

Push patches upstream

2010-11-24T07:49:03Z

Eric: Undo revision 3292 by Yjytalamago (Talk)

= Outline =

OE has quite many patches that are just too valuable to keep to
ourselves. OE encourages the following soft policy for adding patches
to the repository.

By the way, [http://patch-tracker.debian.org/ Debian], [http://patches.ubuntu.com/ Ubuntu], [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo] as well as [http://cvs.fedoraproject.org/viewvc/rpms/ Fedora] are of course always a great source for grabbing high-quality patches to include in OE.

= Policy =

1) first line in a patch starts with '''upstream:''' and goes on to list the
URL where the bug has been reported upstream or "OE-only" if the patch
is just a hack or applicable only to OE.
2) further information can optionally be listed in the following fields.
Adding them is strongly encouraged where appropriate.

* status: pending, accepted in XXX, rejected (upstream)
* origin: where the patch has been stolen ;-)
* comment: any further detail such as description or reason for
application of the patch

Take a look at [http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/busybox/busybox-1.9.2/adduser-longops.patch an example]

= Push'em-weekends =

These are sprints in the spirit of our [[bug days|bug-squashing weekends]] when we try to
push our patches to the upstream projects. The first such sprint was held
on short notice from Friday, February 15th 2008 to Monday, the 18th. A few
patches were already pushed upstream. Second sprint is scheduled for first weekend in August.

Pushing our bugs upstream is beneficial for us (easier maintainability) and
them (we give back our work). The following two commands can give you a
list of patches still in need of being documented in line with above policy.

find recipes/ $ -name '*.patch' -or -name '*.diff' $ -print0 | xargs -0 egrep -L \^upstream\:

You can push those patches upstream even if you are only a normal user of
OE. Let us know via the [http://bugs.openembedded.net bug tracker] if you have reported one of our patches
upstream. Please be sure to test if the patch is still being applied
to the most recent version of the package in OE.

= sample text for upstream reports =

Hi,

thank you for sharing your work in $project. Openembedded.org includes
recipes to cross-compile $project for a large number of target devices.

I would like to make you aware of some of the changes that we at the
openembedded.org project did to the sources you publish.

Patch: http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/$patch-url
Comment: $explanation

You can find all our patches for $project at
http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/

Thank you again for your work.

Regards

$name

[[Category:Policy]]

OpenEmbedded Developers

2010-11-24T07:48:52Z

Eric: Undo revision 3293 by Yjytalamago (Talk)

Below is the list of developers that currently have commit access to OE git repos.

Please list in alphabetical order, format: Name (git_key_name)

# ??? quickdev
# Aloisio Almeida (aloisio_almeida)
# Andrea Adami (andrea_adami)
# Angus Ainslie (angus_ainslie)
# Bernhard Guillon (bernhard_guillon)
# Carsten Haitzler (carsten_haitzler)
# Chris Larson (kergoth)
# [[User:Cbrake|Cliff Brake]] (cbrake)
# Daniel Willmann (daniel_willmann)
# Denis Carikli (denis_carikli)
# Denys Dmytriyenko (denys_dmytriyenko)
# Dirk Opfer (dirk_opfer)
# Dmitry Baryshkov (dmitry_baryshkov)
# Elena Grandi (elena_grandi)
# Enrico Scholz (enrico_scholz)
# Erik Hovland (erik_hovland)
# [[User:Florian|Florian Boor]] (florian_boor)
# Frans Meulenbroeks (frans_meulenbroeks)
# Graeme Gregory (xora)
# Henning Heinold (henning_heinold)
# Holger Freyther (zecke)
# Jan Luebbe (jan_luebbe)
# Jeremy Laine (jeremy_laine)
# John Lee (john_lee)
# Julien Cassignol (julien_cassignol)
# Junqian Gordon Xu (xjqian)
# Kalev Lember (kalev_lember)
# Khem Raj (khem_raj)
# Klaus Kurzmann (klaus_kurzmann)
# Koen Kooi (koen)
# Kristoffer Ericson (kristoffer_ericson)
# Liam Girdwood (liam_girdwood)
# [[User:Likewise|Leon Woestenberg]] (leon_woestenberg)
# Lukas Gorris (lukas_gorris)
# Lynn Lin (lynn_lin)
# [[User:MarcinHrwJuszkiewicz|Marcin Juszkiewicz]] (hrw)
# [[User:MarcoCavallini|Marco Cavallini]] (mckoan)
# Mark Brown (mark_brown)
# Martin Dietze (martin_dietze)
# Martin Jansa (martin_jansa)
# [[User:Mickey|Michael Lauer]] (mickeyl)
# Mike Westerhof (mwester)
# Mustafa Yuecel (mustafa_yuecel)
# Otavio Salvador (otavio_salvador)
# Oyvind Repvik (oyvind_repvik)
# Paul Eggleton (paul_eggleton)
# Paul Sokolovsky (pfalcon)
# Phil Blundell (phil_blundell)
# Philip Balister (crofton)
# Philipp Zabel (phillip_zabel)
# Przemyslaw Wesolek (przemyslaw_wesolek)
# Relix Domke (felix_domke)
# Richard Purdie (rpurdie)
# Robert Schuster (robert_schuster)
# Rod Whitby (rwhitby)
# Rodrigo Vivi (rodrigo_vivi)
# Rolf Leggewie (rolf)
# Roman Khimov (roman_khimov)
# Sebastian Spaeth (sebastian_spaeth)
# Sergey Lapin (sergey_lapin)
# Shane Volpe (shane_volpe)
# Simon Busch (morphis)
# Stanislav Brabec (stanislav_brabec)
# Stefan Schmidt (stefan_schmidt)
# [[User:Sledz|Steffen Sledz]] (steffen_sledz)
# Theodore Roth (theodore_roth)
# Thomas Kunze (thomas_kunze)
# Tick Chen (tick_chen)
# Tim Ellis (tim_ellis)
# Tom Rini (tom_rini)
# Ulf Samuelsson (ulf_samuelsson)
# Xerxes Rånby (xerxes_ranby)
# Yuri Bushmelev (yuri_bushmelev)

[[Category:Dev]]