[OE-core] [PATCH 3/4] syslinux: improve packaging
Usually only parts of syslinux are used by products and thus syslinux
can be greatly reduced in size. This changes does it as:
- syslinux: syslinux binary
- syslinux-extlinux: extlinux binary
- syslinux-mbr: mbr.bin
- syslinux-chain: chain.c32
- syslinux-pxelinux: pxelinux.0
- syslinux-isolinux: isolinux.bin
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-devtools/syslinux/syslinux_4.03.bb | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/syslinux/syslinux_4.03.bb
b/meta/recipes-devtools/syslinux/syslinux_4.03.bb
index 05bcb21..dc0785e 100644
--- a/meta/recipes-devtools/syslinux/syslinux_4.03.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_4.03.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
# If you really want to run syslinux, you need mtools. We just want the
# ldlinux.* stuff for now, so skip mtools-native
DEPENDS = nasm-native
-PR = r0
+PR = r1
SRC_URI =
${KERNELORG_MIRROR}/linux/utils/boot/syslinux/syslinux-${PV}.tar.bz2 \
file://cross-build.patch
@@ -46,4 +46,14 @@ do_install() {
install -m 644 ${S}/core/ldlinux.bss ${D}${libdir}/syslinux/
}
+PACKAGES =+ ${PN}-extlinux ${PN}-mbr ${PN}-chain ${PN}-pxelinux
${PN}-isolinux
+
+FILES_${PN} = ${bindir}/syslinux
+FILES_${PN}-extlinux = ${sbindir}/extlinux
+FILES_${PN}-mbr = ${libdir}/${PN}/mbr.bin
+FILES_${PN}-chain = ${libdir}/${PN}/chain.c32
+FILES_${PN}-isolinux = ${libdir}/${PN}/isolinux.bin
+FILES_${PN}-pxelinux = ${libdir}/${PN}/pxelinux.0
+FILES_${PN}-dev += ${datadir}/${PN}/com32
+
BBCLASSEXTEND = native
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] meta/conf/local.conf.sample: fix mklibs comment line split and typo
Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- meta/conf/local.conf.sample |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample index ba92df8..02164eb 100644 --- a/meta/conf/local.conf.sample +++ b/meta/conf/local.conf.sample @@ -53,9 +53,10 @@ EXTRA_IMAGE_FEATURES = tools-debug tools-profile tools-testapps debug-tweaks #PACKAGE_CLASSES ?= package_rpm package_deb package_ipk PACKAGE_CLASSES ?= package_ipk -# mklibs library size optimization is more useful to smaller images, -# and less useful for bigger images. Also mklibs library optimization can break the ABI compatibility, so should not be applied to the images which are tobe -# extended or upgraded later. +# mklibs library size optimization is more useful to smaller images, +# and less useful for bigger images. Also mklibs library optimization +# can break the ABI compatibility, so should not be applied to the +# images which are to be extended or upgraded later. #This enabled mklibs library size optimization just for the specified image. #MKLIBS_OPTIMIZED_IMAGES ?= core-image-minimal #This enable mklibs library size optimization will be for all the images. -- 1.7.2.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] RFC: Recipe based User Group addition, modification and deletion
RFC: Recipe based User Group addition, modification and deletion Problem: In OE-Core we need a method for dynamically adding non-standard user and group entries to the system. This system must be flexible, extensible and easy to use by the recipe authors. We require this functionality in order to address numerous system wide security requirements. Among these requirements is the necessity to enable non-root owned files (and eventually directories) in the packages constructed by the build system. Architecture: The architecture design is based in part on the existing update-rc.d infrastructure. As such three choices for architecture were considered. In each of the descriptions below any references to the passwd file should also assume a shadow file may exist, similarly any references to a group file should assume a gshadow file may exist. 1) Enable a small set of native tools that can be used to manipulate the passwd and group files in both pre and post install scripts as specified in the recipes. The small set of tools should include: adduser, addgroup, moduser, modgroup, deluser, delgroup, passwd and gpasswd. This set of tools will enable the addition, modification and removal of specific user and group entries, as well as enable the ability to set the corresponding passwords for a given entry. The tools in question also need to support shadow password files. In order to leverage the existing tooling it is expected that they will each be modified to add a --root parameter that enables the program to either chroot into a specific directory using the facilities provided by pseudo, or using the item as an alternative mechanism to locate files on the disk. A set of example pre and post install recipe instructions will be generated as examples. 2) We add a new variable to the recipe syntax. The variable will need to allow a recipe to specify an arbitrary number of new users and groups, along with their corresponding settings. The update-rc.d.bbclass is used as an example for this item. The new class _useradd.bbclass_ will use a small number of variables to control user and group creation. As with update-rc.d, an 'inherit useradd' will be required in the recipe to use this functionality. The variable USERADD_PACKAGES will control which binary packages will have the special user add code. The corresponding USERADD_PARAM_pkg variable will contain a list of parameters in the format of the command line useradd program as document by useradd(8) man page. Multiple parameters will be separated by a semicolon (;). For example, to add two new users for sendmail, you could use: USERADD_PACKAGES = sendmail USERADD_PARAM_sendmail = -u 47 -d /var/spool/mqueue -r -s /bin/true mailnull ; -u 51 -d /var/spool/mqueue -r -s /bin/true smmsp This would add two users, and their corresponding groups based on the rules of the useradd program parameters. For GROUP control, the vales would be changed to GROUPADD_PACKAGES and GROUPADD_PARAM_pkg. Note, many groups are automatically generated as part of a useradd -- so specific group adds are only required in specific circumstances. If both USERADD and GROUPADD are specified, the GROUPADD will always run before the USERADD. This ensures that new users can rely on similarly new groups. Removal and modification of existing users is not supported by this approach. The implementation of the actual add of user and group entries is up to the packaging approach with a reasonable default approach specified. 3) Combine approaches 1 and 2. Ensure that the recipe variable approach (2) uses the mechanisms as implemented and defined in the command approach (1). This will allow for the most flexibility, but also ensure that if a recipe needs more then simple 'add' control it can be achieved. --- It is recommended that the 3rd choice above be selected as the architecture for the new functionality. However, no matter which choice above is selected -- or potentially even ones that are not listed above there are still some additional items that will need to be resolved. Any pre-installation steps will need to be preformed prior to the do_install() stage of recipe building. Otherwise the necessary user/group entries may not be available which could lead to incorrect packaging occurring. The passwd and group files manipulated by this pre-install step will need to be global to the sysroot, with PSEUDO specified to use this specific passwd and group file. (PSEUDO_PASSWD environment variable specifies the path to a directory containing a passwd and group file.) The above will enable the ability to do, chown new_user:new_group path/file. within a do_install() step. During rootfs image creation, the pre-install steps will also need to be executed prior to the package being installed -- or a suitable cleanup step run that ensures the correct owners and groups for files (and directories) exist after installation. This will likely require changes to the various rootfs
Re: [OE-core] How to patch yocto kernel
On Sun, May 1, 2011 at 10:31 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Sun, May 1, 2011 at 11:56 PM, Khem Raj raj.k...@gmail.com wrote:
On Sun, May 1, 2011 at 7:40 PM, Bruce Ashfield bruce.ashfi...@gmail.com
wrote:
On Sun, May 1, 2011 at 9:14 PM, Khem Raj raj.k...@gmail.com wrote:
Hi
I am trying to test this patch
http://uclibc.org/~kraj/perf-tool-Fix-gcc-4.6.0-issues.patch
to fix the build using gcc 4.6.0 but the kernel patching for yocto is
not as usual as other recipes
since it uses entire set of tooling around it.
I tried to look around for documentation and few references I found
https://wiki.pokylinux.org/wiki/Wind_River_Kernel
discourages putting patches in metadata. and in another document it
says it uses git to do patching but does not explain how.
So if someone can explain in simple terms how to patch a linux-yocto
would be really helpful from a
developer POV or any documentation will be helpful.
How do people develop/test patches on linux-yocto I understand
eventually they are desired to be part
of linux-yocto git but that comes after they are tried and tested locally
I would have preferred to have the usual SRC_URI patching atleast for
local testing. As of now
it seems not to use normal OE recipe procedures.
Are you actually not seeing this work ? I put in place compatibility
with existing patching via the SRC_URI for just this reason. A patch
specified in the SRC_URI will be picked up by the tools and applied
to the end of the BSP branch during the patching phase.
if it worked. I would not be writing this email :)
:) you never know, I didn't see your error message so I didn't want
to presume.
But I spoke too soon earlier, I had a bbappend in my layers that
meant I was modifying the wrong SRC_URI to have your patch
applied.
When I modified the right SRC_URI like so:
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta\
+ file://perf-tool-Fix-gcc-4.6.0-issues.patch
(i.e. the obvious way)
I see the patch applied to the end of my BSP branch:
git branch
master
meta
yocto/base
yocto/eg20t
yocto/emgd
yocto/gma500
yocto/standard/arm-versatile-926ejs
yocto/standard/base
yocto/standard/beagleboard
yocto/standard/common-pc-64/base
yocto/standard/common-pc-64/jasperforest
yocto/standard/common-pc-64/sugarbay
yocto/standard/common-pc/atom-pc
* yocto/standard/common-pc/base
commit 2500f7dc4d6c0d8b2f5ddad6369ee4541456533a
Author: Kyle McMartin k...@mcmartin.ca
Date: Mon May 2 01:26:49 2011 -0400
commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream.
GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
due to the -Werror=unused-but-set-variable flag.
I've gone through and annotated some of the assignments that had side
effects (ie: return value from a function) with the __used annotation,
and in some cases, just removed unused code.
In a few cases, we were assigning something useful, but not using it in
later parts of the function.
kyle@dreadnought:~/src% gcc --version
gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)
Cc: Ingo Molnar mi...@redhat.com
LKML-Reference: 20110124161304.gk27...@bombadil.infradead.org
Signed-off-by: Kyle McMartin k...@redhat.com
[ committer note: Fixed up the annotation fixes, as that code
moved recently ]
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
[Backported to 2.6.38.2 by deleting unused but set variables]
Signed-off-by: Thomas Meyer tho...@m3y3r.de
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
[Backported to linux-yocto kernel git version]
Signed-off-by: Khem Raj raj.k...@gmail.com
I did modify the patch format slightly, since git am needs to be able to
grok the patch for it to apply.
Did you get any sort of error message when your patch didn't apply ?
yes it would not apply the patch and instead complained it could not
checkout a branch because tree was dirty
I dont have exact message handy. I will see if I can reproduce it
Cheers,
Bruce
It has definitely worked during all the development cycles, so if you
are seeing it not work, it's a bug and I'll fix it.
Cheers,
Bruce
Thanks
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] GCC 4.6.0 on ARM?
On Mon, May 2, 2011 at 5:06 AM, Gary Thomas samoht.y...@gmail.com wrote: It seems that the file gcc-4_6-branch-backports/0055-Remove-svn-mergeinfo.patch is empty in your tree, so patch didn't create it for me. Should it just be removed from the SRC list? good find. Yes it should be. I will remove it and repush to same branch ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] busybox: add support to mdev
On Mon, May 2, 2011 at 19:21, Khem Raj raj.k...@gmail.com wrote: Did you test this patch on a config where mdev support is disabled ? that will be interesting to know Yes I did. It seems to work fine for me. Do you see any problem with that? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] RFC: design of network based PR service
On Thu, Apr 28, 2011 at 10:28 PM, Lu, Lianhao lianhao...@intel.com wrote:
Mark Hatle wrote on 2011-04-29:
(adding oe-core back to the list as it got dropped off my previous reply)
On 4/28/11 4:04 PM, Joshua Lock wrote:
On Thu, 2011-04-28 at 10:19 -0500, Mark Hatle wrote:
On 4/28/11 4:22 AM, Martin Jansa wrote:
On Thu, Apr 28, 2011 at 03:08:03PM +0800, Lu, Lianhao wrote:
Hi Guys,
Here is the design of network based PR service, please help to
review and give you comment. Thanks a lot!
Hi,
looks good, just wondering if we can use the same mechanism for
LOCALCOUNT numbers in SRCPV, we can even use same table if we
prefix first column ie LOCALCOUNT_${PN} and CheckSum in 2nd column
would be actuall git hash (from SRCREV or HEAD for AUTOREV) or 2nd
table with similar structure.
But it wont work very well if one builder is using AUTOREV and
another one isn't, but that can be resolved by allowing only
trusted builders with same configuration (wrt AUTOREV) to send such
tuples.
Do we have at least 2 groups of users.
1) trusted which increments PR when hash is not found
2) public which can query PR for given hash (not sure what they should
do if hash is not found)
I think this points our something necessary. There are manual
indications of a change. I.e. the current PR usage. If I change
the recipe, patches, etc I should expect to update the 'PR' to the
next value. However, if something ELSE changes (affecting the
checksum), or an end user forgets to change the PR, the auto
increment
should be used.
Why would you need to update the PR manually? Detecting changes in
the recipe/patches/etc should all be handled by the checksumming.
Checksums and timestamps are not enough to determine a logical
progression of the components.
We need something that informs the user where these changes fit in the
grand scheme of things. Are they newer or older then a recipe of the
same name (and package version)?
So this really allows us to visualize multiple levels of upstream work:
Level 1 - Upstream version (PV)
Level 2 - Upstream (oe-core) recipe versioning (PR)
...
Level N - Local build and configuration versioning (checksum based
auto incrementing)
In a lot of projects 1, 2 and N are enough.. but it's understandable
to add in other intermediate levels to indicate different upstreams along
the way.
(Such as if a company has their own internal distribution..)
I've seen cases where a level 3 exists to indicate a distribution version..
Level N (when done manually) has usually captured major system
configuration changes and rebuilding in order to enable solver tools to
upgrade properly.
While the checksum will be able to point a unique instance of the
recipe to a given PR... it doesn't guaranty any type of logical
numbering.. other then a new checksum is a new (presumably larger) PR
number. By adding in the various levels of version information the
checksum becomes more unique as it only refers to specific
'upstream' revisions, and make it more logical that a level 1, 2, ... N
change means it's a newer version of the package.
If a new PV(and/or PR) value comes, does the level N value need to be reset
to 0? Or should it continue to increase?
I am in favor of reseting it to 0
Best Regards,
Lianhao
___
poky mailing list
p...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/poky
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] GCC 4.6.0 on ARM?
2011/5/2 Gary Thomas g...@mlbassoc.com: I was able to build my kernel (ARM OMAP/3530 based) using this, but good. the USB still doesn't work, so no improvement, sorry. bad. hmm I guess it needs to be debugged. Many times new compilers unearth coding errors sometimes compiler mess up too. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] git: use DESTDIR=$D instead prefixing all variables by $D
On Sat, Apr 30, 2011 at 1:01 AM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 30 apr 2011, om 00:09 heeft Saul Wold het volgende geschreven:
On 04/29/2011 03:13 AM, Koen Kooi wrote:
From: Martin Jansamartin.ja...@gmail.com
* with git-native and rm_work enabled I've noticed git fetcher errors like:
warning: templates not found
/OE/shr-core/tmp/work/x86_64-linux/git-native-1.7.3.4-r0/image/OE/shr-core/tmp/sysroots/x86_64-linux/usr/share/git-core/templates
fatal: Unable to find remote helper for 'http'
for every recipe using http:// for git repo
* after this change template_dir points to
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/share/git-core/templates
without that workdir prefix
* haven't tested target recipe, but I guess it needs different fix or
maybe it worked before and gets broken by this change (that's why this
is just RFC)
Is this still just an RFC or has it been tested on the target?
On the target I get:
strace -o /tmp/log git clone http://git.pingu.fi/xf86-video-omapfb
Cloning into xf86-video-omapfb...
fatal: Unable to find remote helper for 'http'
root@beagleboard-core:~#
It does find the templates:
open(/usr/share/git-core/templates/,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
open(/usr/share/git-core/templates/config, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
lstat64(/usr/share/git-core/templates/branches, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
open(/usr/share/git-core/templates/branches,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
lstat64(/usr/share/git-core/templates/description, {st_mode=S_IFREG|0644,
st_size=73, ...}) = 0
open(/usr/share/git-core/templates/description, O_RDONLY|O_LARGEFILE) = 4
lstat64(/usr/share/git-core/templates/hooks, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
open(/usr/share/git-core/templates/hooks,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
lstat64(/usr/share/git-core/templates/hooks/applypatch-msg.sample,
{st_mode=S_IFREG|0755, st_size=452, ...}) = 0
open(/usr/share/git-core/templates/hooks/applypatch-msg.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/post-receive.sample,
{st_mode=S_IFREG|0755, st_size=552, ...}) = 0
open(/usr/share/git-core/templates/hooks/post-receive.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/post-commit.sample,
{st_mode=S_IFREG|0755, st_size=160, ...}) = 0
open(/usr/share/git-core/templates/hooks/post-commit.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/update.sample,
{st_mode=S_IFREG|0755, st_size=3611, ...}) = 0
open(/usr/share/git-core/templates/hooks/update.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/pre-applypatch.sample,
{st_mode=S_IFREG|0755, st_size=398, ...}) = 0
open(/usr/share/git-core/templates/hooks/pre-applypatch.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/commit-msg.sample,
{st_mode=S_IFREG|0755, st_size=896, ...}) = 0
open(/usr/share/git-core/templates/hooks/commit-msg.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/post-update.sample,
{st_mode=S_IFREG|0755, st_size=189, ...}) = 0
open(/usr/share/git-core/templates/hooks/post-update.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/pre-commit.sample,
{st_mode=S_IFREG|0755, st_size=1578, ...}) = 0
open(/usr/share/git-core/templates/hooks/pre-commit.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/prepare-commit-msg.sample,
{st_mode=S_IFREG|0755, st_size=1359, ...}) = 0
open(/usr/share/git-core/templates/hooks/prepare-commit-msg.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/hooks/pre-rebase.sample,
{st_mode=S_IFREG|0755, st_size=5011, ...}) = 0
open(/usr/share/git-core/templates/hooks/pre-rebase.sample,
O_RDONLY|O_LARGEFILE) = 6
lstat64(/usr/share/git-core/templates/info, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
open(/usr/share/git-core/templates/info,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
lstat64(/usr/share/git-core/templates/info/exclude, {st_mode=S_IFREG|0644,
st_size=240, ...}) = 0
open(/usr/share/git-core/templates/info/exclude, O_RDONLY|O_LARGEFILE) = 6
But that didn't work before since /usr/libexec/git-core isn't getting
packaged.
And I noticed this:
koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep gitexecdir
meta/recipes-devtools/git/git.inc: oe_runmake install DESTDIR=${D}
bindir=${bindir} gitexecdir=${gitexecdir} \
koen@dominion:/OE/tentacle/sources/openembedded-core$
'gitexecdir' is undefined :(
yeah and git/makefile defines it
gitexecdir = libexec/git-core
may be we could set it to ${libdir}/git-core ?
I'll do a follow-up patch to fix git on the target, but that has *never*
worked in yocto/oe-core. So please apply
Re: [OE-core] qemu segfaulting when booting ext3 image
Did you installed Nvidia proprietary driver? Any error mesg from the runqemu script? I can't figure out one case that nfs root works and ext3 image doesn't... Khem Raj wrote: Hi I am seeing qemu segfaulting when booting ext3 image. The same rootfs boots fine over nfs. It does not give any useful message as to what happened. I am using the runqemu script. Same used to work fine 3 weeks back. I tried to blame compilers but the behavior is same irrespective of gcc version I use or even eglibc/uclibc Its on x86_64/ubuntu 11.04 host. Anyone experiencing it ? bisecting can be a long excercise for this. Thanks -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
