http://www.openembedded.org/api.php?action=feedcontributions&user=77.47.162.103&feedformat=atomOpenembedded.org - User contributions [en]2024-03-29T15:41:47ZUser contributionsMediaWiki 1.29.0http://www.openembedded.org/index.php?title=Required_software&diff=2364Required software2010-06-30T14:46:25Z<p>77.47.162.103: </p>
<hr />
<div>= OpenEmbedded's Software Requirements =<br />
<br />
This page is the reference of what software is needed. But [[OEandYourDistro]] is likely much faster in getting you that software actually installed.<br />
<br />
To use the OE build system the following software is required on your system:<br />
* [http://www.python.org/ Python] (Version 2.4.0 or later)<br />
** 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.<br />
* [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.)<br />
* [http://www.gnu.org/software/m4/m4.html GNU m4]<br />
* [http://www.gnu.org/software/make/ GNU make] (Version 3.80 or later for hh.org kernels)<br />
* [http://psyco.sourceforge.net/ Psyco JIT Compiler] is recommended to increase performance (32bit only)<br />
* [http://www.perl.org/ perl] (needs newer than 5.0, how much newer? probably at least 5.6.2)<br />
* [http://invisible-island.net/diffstat/diffstat.html diffstat]<br />
* [http://developer.berlios.de/projects/bitbake bitbake]<br />
<br />
== Tools to download source files ==<br />
* wget <br />
* curl <br />
* ftp<br />
* [http://www.nongnu.org/cvs/ cvs]<br />
* [http://subversion.tigris.org/ subversion]<br />
* [http://git.or.cz/index.html git]<br />
<br />
== Tools to verify integrity of the downloaded sources ==<br />
* md5sum<br />
* sha256sum<br />
<br />
== Tools to unpack sources ==<br />
* tar<br />
* bzip2<br />
* gzip<br />
* unzip<br />
<br />
== Tools to build the various *-doc packages==<br />
* [http://www.jclark.com/jade/ Jade] or [http://www.netfolder.com/DSSSL/ OpenJade]<br />
** I don't know which of these is preferred<br />
* [http://sourceforge.net/projects/docbook/ Docbook] DTDs and DSSSL stylesheets<br />
* [http://sgmltools-lite.sourceforge.net/ sgmltools], called "sgmltools-lite" too<br />
* [http://sources.redhat.com/docbook-tools/ docbook-utils]<br />
** docbook-utils download is hard to find; look in ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES<br />
* [ftp://ftp.gnu.org/pub/gnu/texinfo/ Texinfo]<br />
* [http://www.nongnu.org/texi2html/ texi2html] (Perl script that converts Texinfo to HTML)<br />
<br />
== Other packages ==<br />
* [http://www.gnu.org/software/sed/sed.html GNU sed] 4.x<br />
* [http://www.gnu.org/software/bison/bison.html Bison]<br />
* bc (binary calculator), if you want to build a Zaurus 2.4 or any of the collie kernels<br />
* glibc headers (libc6-dev in Debian, glibc-devel in RPM based (in PLD also glibc-static is needed))<br />
* [http://www.pcre.org/ pcre headers] (Perl 5 Compatible Regular Expression Library, required for e.g. konqueror-embedded)<br />
* SDL headers to build qemu-native (apt-get install libsdl1.2-dev under Ubuntu/Debian)<br />
* [http://www.mktemp.org/mktemp/ mktemp] (required by quilt and used in some package patches)<br />
* help2man - Create simple man pages from --help output<br />
<br />
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.<br />
<br />
[[Category:User]]<br />
<br />
[http://www.bestessays.com do my essay]</div>77.47.162.103http://www.openembedded.org/index.php?title=How_to_disable_generation_of_locales&diff=2359How to disable generation of locales2010-06-28T14:02:08Z<p>77.47.162.103: </p>
<hr />
<div>Generating locales and their packages takes a very long time. Quoting [http://cgit.openembedded.net/cgit.cgi/openembedded/tree/conf/local.conf.sample local.conf.sample] on how to skip or limit that step to significantly speed up your builds.<br />
<br />
<pre><br />
<br />
# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION<br />
# to generate binary locale packages at build time using qemu-native and<br />
# thereby guarantee i18n support on all devices. If your build breaks on <br />
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that<br />
# this breaks i18n on devices with less than 128MB RAM) or installing<br />
# a working third-party qemu (e.g. provided by your distribution) and<br />
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party<br />
# qemus lack patches needed to work with various OE targets.<br />
# ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
# ASSUME_PROVIDED += "qemu-native"<br />
<br />
# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales<br />
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge<br />
# time-savior for developmental builds. Format: list of locale.encoding pairs<br />
# with spaces as separators.<br />
# GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8 de_DE.UTF-8"<br />
<br />
</pre><br />
<br />
[[Category:FAQ]]<br />
<br />
[http://www.applicationessay.net/ application essay]</div>77.47.162.103http://www.openembedded.org/index.php?title=Push_patches_upstream&diff=2358Push patches upstream2010-06-28T13:41:50Z<p>77.47.162.103: </p>
<hr />
<div>= Outline =<br />
<br />
OE has quite many patches that are just too valuable to keep to<br />
ourselves. OE encourages the following soft policy for adding patches<br />
to the repository.<br />
<br />
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.<br />
<br />
= Policy =<br />
<br />
1) first line in a patch starts with '''upstream:''' and goes on to list the<br />
URL where the bug has been reported upstream or "OE-only" if the patch <br />
is just a hack or applicable only to OE.<br />
2) further information can optionally be listed in the following fields.<br />
Adding them is strongly encouraged where appropriate.<br />
<br />
* status: pending, accepted in XXX, rejected (upstream)<br />
* origin: where the patch has been stolen ;-) <br />
* comment: any further detail such as description or reason for<br />
application of the patch<br />
<br />
Take a look at [http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/busybox/busybox-1.9.2/adduser-longops.patch an example]<br />
<br />
= Push'em-weekends =<br />
<br />
These are sprints in the spirit of our [[bug days|bug-squashing weekends]] when we try to <br />
push our patches to the upstream projects. The first such sprint was held <br />
on short notice from Friday, February 15th 2008 to Monday, the 18th. A few <br />
patches were already pushed upstream. Second sprint is scheduled for first weekend in August.<br />
<br />
Pushing our bugs upstream is beneficial for us (easier maintainability) and<br />
them (we give back our work). The following two commands can give you a <br />
list of patches still in need of being documented in line with above policy.<br />
<br />
find recipes/ \( -name '*.patch' -or -name '*.diff' \) -print0 | xargs -0 egrep -L \^upstream\:<br />
<br />
You can push those patches upstream even if you are only a normal user of <br />
OE. Let us know via the [http://bugs.openembedded.net bug tracker] if you have reported one of our patches<br />
upstream. Please be sure to test if the patch is still being applied<br />
to the most recent version of the package in OE.<br />
<br />
= sample text for upstream reports =<br />
<br />
Hi,<br />
<br />
thank you for sharing your work in $project. Openembedded.org includes<br />
recipes to cross-compile $project for a large number of target devices.<br />
<br />
I would like to make you aware of some of the changes that we at the <br />
openembedded.org project did to the sources you publish.<br />
<br />
Patch: http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/$patch-url<br />
Comment: $explanation<br />
<br />
You can find all our patches for $project at <br />
http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/<br />
<br />
Thank you again for your work.<br />
<br />
Regards<br />
<br />
$name<br />
<br />
[[Category:Policy]]<br />
<br />
[http://www.resumesplanet.com professional resumes]</div>77.47.162.103http://www.openembedded.org/index.php?title=BitBake_(dev)&diff=2357BitBake (dev)2010-06-28T13:12:44Z<p>77.47.162.103: </p>
<hr />
<div>''developer homepage''<br />
<br />
* First , RTFM ;-) : http://bitbake.berlios.de/manual/<br />
* Don't forget mailinglist :<br />
** https://lists.berlios.de/pipermail/bitbake-dev/<br />
** https://lists.berlios.de/pipermail/bitbake-commit/<br />
* Best documentation for source is via python documentation system.<br />
<br />
= Tutorial =<br />
<br />
This tutorial focus bitbake developement, not bbclass or openembedded developement that is documented elsewhere.<br />
<br />
== "Helloworld" using bb library ==<br />
<br />
=== Simplest ===<br />
<br />
<pre><br />
#!/usr/bin/env python<br />
# ex:ts=4:sw=4:sts=4:et<br />
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-<br />
<br />
import bb<br />
<br />
version = bb.__version__<br />
bb.note("Hello from helloworld using lib bb v%s." % ( version ))<br />
</pre><br />
<br />
=== with data module ===<br />
<br />
<pre><br />
#!/usr/bin/env python<br />
# ex:ts=4:sw=4:sts=4:et<br />
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-<br />
<br />
import os , bb<br />
from bb import data<br />
<br />
hello = ("Hello from helloworld using lib bb v%s." % ( bb.__version__ ))<br />
<br />
d = data.init()<br />
data.setVar('HELLO_MSG', hello, d)<br />
<br />
mystring = data.getVar('HELLO_MSG', d, 1)<br />
bb.note(mystring)<br />
</pre><br />
<br />
data module is well documented because it uses doctest.<br />
Enjoy to play with the different methods. <br />
<br />
=== with persist_data module ===<br />
<br />
Now you want persistant data to exchange data between threads/tasks.<br />
This can be done using bb.persist_data module that uses sqlite via pyslite2.<br />
<br />
<pre><br />
#!/usr/bin/env python<br />
# ex:ts=4:sw=4:sts=4:et<br />
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-<br />
<br />
import bb, os, sys<br />
from bb import data, persist_data, fetch<br />
<br />
__version__ = "0.0.1"<br />
<br />
def main():<br />
"""<br />
The main Method<br />
"""<br />
<br />
# persist_data module need debug_level to be set<br />
bb.msg.set_debug_level(0) <br />
<br />
# init a data with PERSISTENT_DIR to set where the data will be saved<br />
d = data.init()<br />
data.setVar('PERSISTENT_DIR', os.getcwd(), d)<br />
<br />
# create persist_data base in bb_persist_data.sqlite3<br />
pd = persist_data.PersistData(d)<br />
<br />
# create a sql table<br />
pd.addDomain("MYBASE")<br />
<br />
# add a data in this table<br />
pd.setValue( "MYBASE", "TOTO", "hello world!")<br />
<br />
# print it<br />
val = pd.getValue ( "MYBASE", "TOTO")<br />
print val<br />
<br />
if __name__ == '__main__':<br />
main()<br />
</pre><br />
<br />
You can edit and watch your base using [http://sqlitebrowser.sourceforge.net sqlitebrowser] for example. Should be useful for debug and test purpose. You can look also at fetch module source that use bb.persist_data.<br />
<br />
[[Category:Dev]]<br />
<br />
[http://uk.bestessays.com essay writing]</div>77.47.162.103