http://www.openembedded.org/api.php?action=feedcontributions&user=83.171.164.148&feedformat=atomOpenembedded.org - User contributions [en]2024-03-19T11:38:23ZUser contributionsMediaWiki 1.29.0http://www.openembedded.org/index.php?title=How_to_disable_generation_of_locales&diff=2382How to disable generation of locales2010-07-13T08:58:07Z<p>83.171.164.148: UNSPAM:Undo revision 2359 by 77.47.162.103 (Talk)</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]]</div>83.171.164.148http://www.openembedded.org/index.php?title=Push_patches_upstream&diff=2381Push patches upstream2010-07-13T08:57:36Z<p>83.171.164.148: UNSPAM:Undo revision 2358 by 77.47.162.103 (Talk)</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]]</div>83.171.164.148http://www.openembedded.org/index.php?title=BitBake_(dev)&diff=2380BitBake (dev)2010-07-13T08:57:06Z<p>83.171.164.148: UNSPAM: Undo revision 2357 by 77.47.162.103 (Talk)</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]]</div>83.171.164.148