Directory permissions and ownership -- RFC
I've had the task to resolve the directory permissions and ownership issues. From the original RFC I sent out, a lot has changed.
The way OE, opkg and deb packages are defined, there is no way to define what package "owns" a directory. There is an expectation that directory permissions, owner and group are consistent between packages (and thus recipes).
I've worked though a number of the issues. While I'm not posting the patches yet for inclusion, I'd like some feed back on the two specific patches below.
Patch 1:
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Patch 2:
The item adds a new step to the package.bbclass, fixup_perms. The function that is responsible for fixing directory and file permissions, owners and groups during the packaging process. This will fix various issues where two packages may create the same directory and end up with different permissions, owner and/or group.
The issue being resolved is that if two packages conflict in their ownership of a directory, the first installed into the rootfs sets the permissions. This leads to a least potentially non-deterministic filesystems, at worst security defects.
The function has a set of default values. We sanitize all of the system directories, as defined in bitbake.conf as 0755, root, root. We also have determined as series of documentation directories. These are sanitized as 0755, root, root with the files they contain as 0644, root, root. The user can add their own settings, or override the defaults by providing a meta/files/fs-perms.txt file. The format of this file is described in the default file.
Any comments/feedback is appreciated.
--Mark
Quoted 4 lines · Mark Hatle
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Are you confident that this isn't going to break anything like group-shared DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks like do_install() might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.
I'm also not quite sure I understand why this is necessary if fixup_perms is going to fix up the permissions anyway.
Quoted 2 lines
The user can add their own settings, or override the defaults by providing a
meta/files/fs-perms.txtfile.
Using a magically-named file rather than metadata vars is a bit unconventional and seems like it will make life unnecessarily harder for distros/other overlays. Is there any reason it needs to be done that way?
p.
Quoted 6 lines · Phil Blundell
Quoted 4 lines · Mark Hatle
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.
This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "do_install" really isn't an option. Between the custom do_install components, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.
(I'd love to be corrected if someone things of another way of doing it.) The setting of the umask is a very low cost operation, so doing it for certain steps shouldn't cause a performance penalty... but until we figure that out this is the best and easiest solution I've come up with.
Quoted 2 lines
I'm also not quite sure I understand why this is necessary if
fixup_permsis going to fix up the permissions anyway.
fixup_perms only knows of certain global directories, it doesn't know of ones that may or may not be unique to given packages, or sets of packages. (yes they could be added over time to the fs-perms.txt file. I started down this path, and when the file reached a few hundred lines I gave up and went to the root cause.. mismatched umask.)
(The global directories are the standard GNU ones, specified in bitbake.conf, and a hand full of specific documentation and similar... I could have put these into the fs-perms.txt, but keeping them dynamic ensures that if someone changes the value of "libdir", we don't have to specify anything for it to work properly.)
The umask fixes both the directories we should know about, and those we'll never know about -- recipes that don't exist in oe-core/meta-oe... It also has a side effect of ensuring that the recipe author only has to pay attention to basic recipe tasks, and not do a full world build and look for conflcts.
A good example of the problem is that cups generates a directory /etc/cups and sets the perms to 0755 w/ uid/gid of root:lp. When ghostscript comes along to put something in /etc/cups, it does a "mkdir -p /etc/cups"... that means /etc/cups now gets the default mode, uid/gid... Changing "ghostscript" to match is easy, it's one package... but what happens when someone adds HP printer drivers, then epson printer drivers, etc.. you quickly get into a situation where you really want a global way to affect /etc/cups, and potentially everything located inside of it.
Quoted 7 lines
Quoted 2 lines
The user can add their own settings, or override the defaults by providing a
meta/files/fs-perms.txtfile.Using a magically-named file rather than metadata vars is a bit unconventional and seems like it will make life unnecessarily harder for distros/other overlays. Is there any reason it needs to be done that way?
fs-perms.txt is the default name. It was done to work similarly to the 'device_table-minimal.txt' file that already exists.
The logic is:
Use the variable FILESYSTEM_PERMS_TABLES, the contents of this may be full paths, or partial paths within the BBPATH structure. Multiple files may be listed space separated. (Evaluation is is order it's specified, so the last one loaded takes precedence over earlier ones.)
If the variable FILESYSTEM_PERMS_TABLES is not specified, we then use the files/fs-perms.txt, again BBPATH is searched for that.
--Mark
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines · Mark Hatle
fs-perms.txt is the default name. It was done to work similarly to the 'device_table-minimal.txt' file that already exists.
The logic is:
Quoted 7 lines
Use the variable
FILESYSTEM_PERMS_TABLES, the contents of this may be full paths, or partial paths within the BBPATH structure. Multiple files may be listed space separated. (Evaluation is is order it's specified, so the last one loaded takes precedence over earlier ones.)If the variable
FILESYSTEM_PERMS_TABLESis not specified, we then use thefiles/fs-perms.txt, again BBPATH is searched for that.
Okay, I see. Does it support variable interpolation? If the permissions are going to be specified out-of-band then I think at a minimum there needs to be a way to refer symbolically to things like ${prefix} rather than hardcoding their values.
Also, from what you wrote above about device_table-minimal, it sounds as though this file is a global manifest rather than being per-recipe. Is that right? If so, it sounds like this is going to be a frequent source of merge headaches in much the same way as the old checksums.ini was.
p.
(Note, I found an additional issue mentioned at the end of this email...)
Quoted 11 lines · Phil Blundell
Quoted 10 lines · Mark Hatle
fs-perms.txt is the default name. It was done to work similarly to the 'device_table-minimal.txt' file that already exists.
The logic is:
Use the variable
FILESYSTEM_PERMS_TABLES, the contents of this may be full paths, or partial paths within the BBPATH structure. Multiple files may be listed space separated. (Evaluation is is order it's specified, so the last one loaded takes precedence over earlier ones.)
Quoted 7 lines
Quoted 2 lines
If the variable
FILESYSTEM_PERMS_TABLESis not specified, we then use thefiles/fs-perms.txt, again BBPATH is searched for that.Okay, I see. Does it support variable interpolation? If the permissions are going to be specified out-of-band then I think at a minimum there needs to be a way to refer symbolically to things like ${prefix} rather than hardcoding their values.
I don't know how to do this within bitbake (easily). The table is currently a static set of paths that exist within the distribution as a whole. They are not recipe specific, but you can have more then one file... the assumption is different layers may bring in additional files, only if necessary.
If there is existing code I can use to identify and resolve in-line variables, I'll be happy to add that into the code. I'd certainly like to add that capability, but so far we don't have it. (Would be nice in the device_table file.. but I doubt that's practical as the code is not run within python.)
I could certainly write code that parsed each path for "${...}" tear it down and do a getVar.. But I still suspect there is code elsewhere in bitbake that could do this for me.
Quoted 4 lines
Also, from what you wrote above about device_table-minimal, it sounds as though this file is a global manifest rather than being per-recipe. Is that right? If so, it sounds like this is going to be a frequent source of merge headaches in much the same way as the old checksums.ini was.
Yes, it is global. I don't see any way around that, as recipe specific items only affect that recipe. I started by looking into adding "yet another" set of variables to the .conf space, but that was shot down as too complicated.
This resulted in only one new variable, a way to define the filesystem, and use it in all of the recipes automatically. (One advantage is that if a distribution decides that /sbin should be 0500, it can make that change globally without affecting any recipes.)
---
Note, there is one remaining issue that I haven't resolved. A few directories are defined in terms of symlinks:
/var/cache root root 120777 volatile/cache
+/var/cache root root 40755
/var/log root root 120777 volatile/log
+/var/log root root 40755
/var/run root root 120777 volatile/run
+/var/run root root 40755
I'm not sure how to resolve this. If the package(s) that define them as a directory are installed before the one that tries to make them a symlink into "volatile" it will could cause a failure -- or at least different system behavior.
I'm tempted to extend the fs_perms file to include a way to specify symlinks.. if one was found then the recipe's install would be modified to mv the directory to the target of the link, and add in the symlink.
--Mark
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 9 lines · Mark Hatle
I don't know how to do this within bitbake (easily). The table is currently a static set of paths that exist within the distribution as a whole. They are not recipe specific, but you can have more then one file... the assumption is different layers may bring in additional files, only if necessary.
If there is existing code I can use to identify and resolve in-line variables, I'll be happy to add that into the code. I'd certainly like to add that capability, but so far we don't have it. (Would be nice in the
device_tablefile.. but I doubt that's practical as the code is not run within python.)
I think bb.data.expand() should do what you need there.
p.
Quoted 6 lines · Phil Blundell
Quoted 5 lines · Mark Hatle
I don't know how to do this within bitbake (easily). The table is currently a static set of paths that exist within the distribution as a whole. They are not recipe specific, but you can have more then one file... the assumption is different layers may bring in additional files, only if necessary.
Quoted 10 lines
Quoted 4 lines
If there is existing code I can use to identify and resolve in-line variables, I'll be happy to add that into the code. I'd certainly like to add that capability, but so far we don't have it. (Would be nice in the
device_tablefile.. but I doubt that's practical as the code is not run within python.)I think
bb.data.expand()should do what you need there.p.
Based on the above, I reworked the package.bbclass commit. The new version is located at:
Functionally it's almost the same, but structurally it has changed a lot. From the last version to this version:
* create a local (to fixup_perms) a function to actually setup the data structure
* remove the default documentation, locale and header correction entries
- move them to the fs-perms.txt
* When processing a "line" to setup the data structure, we expand all of the variables with it first. This not only allows for the directory to be set with a variable, but also the mode, uid, and gid if necessary.
--Mark
Quoted 12 lines · Mark Hatle
Note, there is one remaining issue that I haven't resolved. A few directories are defined in terms of symlinks:
/var/cache root root 120777 volatile/cache
+/var/cache root root 40755/var/log root root 120777 volatile/log
+/var/log root root 40755/var/run root root 120777 volatile/run
+/var/run root root 40755
Quoted 7 lines
I'm not sure how to resolve this. If the package(s) that define them as a directory are installed before the one that tries to make them a symlink into "volatile" it will could cause a failure -- or at least different system behavior.
I'm tempted to extend the
fs_permsfile to include a way to specify symlinks.. if one was found then the recipe's install would be modified to mv the directory to the target of the link, and add in the symlink.
Yes, please try to find a way to extend the fs_perms file to include handling of
symlinks. Otherwise we are bound to get problems immediately...
The outline of the symlink handling above seems to be fine, assuming you find a good place to hook it up to in the tasks.
/Anders
Op 21 jun 2011, om 21:12 heeft Mark Hatle het volgende geschreven:
Quoted 15 lines · Phil Blundell
Quoted 6 lines · Mark Hatle
Quoted 4 lines
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.
Quoted 6 lines
This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "
do_install" really isn't an option. Between the customdo_installcomponents, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.
Would something like this work?
myclass.bbclass:
addtask mytask before do_package after do_install
mytask() {
do stuff
}
DISTRO.conf:
# do stuff INHERIT += "myclass"
regards,
Koen
Quoted 27 lines · Koen Kooi
Op 21 jun 2011, om 21:12 heeft Mark Hatle het volgende geschreven:
Quoted 15 lines · Phil Blundell
Quoted 6 lines · Mark Hatle
Quoted 4 lines
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.Quoted 6 lines
This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "
do_install" really isn't an option. Between the customdo_installcomponents, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.Would something like this work?
Quoted 7 lines
myclass.bbclass:
addtask mytask before
do_packageafterdo_install
mytask(){
do stuff
}
Unfortunately it won't work as the umask would only be set in the "mytask" - task. It needs to be set in all of the do_install and do_package tasks.
The only way to do this (from what Chris L told me) is to setup an event handler and set the umask when we get into specific events. I'm not sure if I could correctly capture do_install and later.. plus if someone did what you are mentioning, then it would no longer be in the umask 022.
Quoted 13 lines
DISTRO.conf:
# do stuff INHERIT += "myclass"regards,
Koen
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 7 lines · Mark Hatle
Unfortunately it won't work as the umask would only be set in the "mytask" - task. It needs to be set in all of the
do_installanddo_packagetasks.The only way to do this (from what Chris L told me) is to setup an event handler and set the umask when we get into specific events. I'm not sure if I could correctly capture
do_installand later.. plus if someone did what you are mentioning, then it would no longer be in the umask 022.
I think you could probably fix do_install by wrapping it in a python method. That is, something along the lines of:
python do_wrapped_install() {
os.umask(022)
bb.build.exec_func("install", d)
}addtask wrapped_install after do_compile
and, obviously, remove the existing addtask for do_install. You get the idea, anyway.
For do_package and other tasks which come from classes within oe-core itself, I continue to think that the right answer is just to fix the classes to do the right thing.
p.
Quoted 11 lines · Phil Blundell
Quoted 7 lines · Mark Hatle
Unfortunately it won't work as the umask would only be set in the "mytask" - task. It needs to be set in all of the
do_installanddo_packagetasks.The only way to do this (from what Chris L told me) is to setup an event handler and set the umask when we get into specific events. I'm not sure if I could correctly capture
do_installand later.. plus if someone did what you are mentioning, then it would no longer be in the umask 022.I think you could probably fix
do_installby wrapping it in a python method. That is, something along the lines of:
Or, I guess, if you were prepared to countenance patching bitbake, just set:
do_install[umask] = 022
and arrange for the right things to happen. That might not be so awful.
p.
Quoted 22 lines · Mark Hatle
Quoted 6 lines · Phil Blundell
Quoted 4 lines · Mark Hatle
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "
do_install" really isn't an option. Between the customdo_installcomponents, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.
Quoted 4 lines
(I'd love to be corrected if someone things of another way of doing it.) The setting of the umask is a very low cost operation, so doing it for certain steps shouldn't cause a performance penalty... but until we figure that out this is the best and easiest solution I've come up with.
How about a umask flag for tasks?
If bitbake sees it for a given task it would set the umask as indicated for the task. Cheap and easy and would only impact do_install tasks...
Cheers,
Richard
I like that better then trying to wrap do_install and such with special code.
It should be fairly easy to set the default for do_install and do_package then.
I wonder if there would be a way to "notice" and flag as possible errors tasks
running between do_install and do_package (in a single recipe) that may need the umask set as well.
--Mark
Quoted 44 lines · Richard Purdie
Quoted 22 lines · Mark Hatle
Quoted 6 lines · Phil Blundell
Quoted 4 lines · Mark Hatle
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "
do_install" really isn't an option. Between the customdo_installcomponents, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.Quoted 4 lines
(I'd love to be corrected if someone things of another way of doing it.) The setting of the umask is a very low cost operation, so doing it for certain steps shouldn't cause a performance penalty... but until we figure that out this is the best and easiest solution I've come up with.
How about a umask flag for tasks?
If bitbake sees it for a given task it would set the umask as indicated for the task. Cheap and easy and would only impact
do_installtasks...Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 8 lines · Mark Hatle
I like that better then trying to wrap
do_installand such with special code.It should be fairly easy to set the default for
do_installanddo_packagethen.
I wonder if there would be a way to "notice" and flag as possible errors tasks
running betweendo_installanddo_package(in a single recipe) that may need the umask set as well.--Mark
I worked out a patch to bitbake for this:
The associated changes to oe-core:
Revert of the original umask patch:
New patch that enables umask is specific areas:
---
Any comments. I'm not sure I like this task approach, simply because it's more complicated. But what I am testing now enables umask of 022 in:
do_installdo_packagedo_rootfs
rootfs_<pkg>_do_rootfsdo_populate_sysroot
adt-installer_1.0.bb: do_deploy
linux-tools.inc: do_install_perf
I think that covers everywhere it will be needed...
--Mark
Quoted 51 lines · Richard Purdie
Quoted 40 lines · Mark Hatle
Quoted 22 lines · Phil Blundell
Quoted 6 lines · Mark Hatle
Quoted 4 lines
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "
do_install" really isn't an option. Between the customdo_installcomponents, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.Quoted 4 lines
(I'd love to be corrected if someone things of another way of doing it.) The setting of the umask is a very low cost operation, so doing it for certain steps shouldn't cause a performance penalty... but until we figure that out this is the best and easiest solution I've come up with.
How about a umask flag for tasks?
If bitbake sees it for a given task it would set the umask as indicated for the task. Cheap and easy and would only impact
do_installtasks...Cheers,
Richard
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 1 line · Mark Hatle
On 6/21/11 5:13 PM, Mark Hatle wrote:
...
Quoted 11 lines
Any comments. I'm not sure I like this task approach, simply because it's more complicated. But what I am testing now enables umask of 022 in:
do_installdo_packagedo_rootfs
rootfs_<pkg>_do_rootfsdo_populate_sysroot
adt-installer_1.0.bb:do_deploy
linux-tools.inc:do_install_perf
Quoted 1 line
I think that covers everywhere it will be needed...
Results from my over night build.
Just setting do_install and do_package isn't enough. A lot of packages appear to unpack, patch, configure, compile, and then in do_install copy, while preserving permissions, from the build directory. This leads to a number of files with 0664 and directories with 0775 permissions (when the users umask is 002.)
I can certainly expand this to do_configure and do_compile. But I'm really concerned this will quickly grow out of control and end up being very complex...
(I will attempt to do this and see if I get better results.)
--Mark
Quoted 59 lines
--Mark
Quoted 47 lines · Richard Purdie
Quoted 40 lines · Mark Hatle
Quoted 22 lines · Phil Blundell
Quoted 6 lines · Mark Hatle
Quoted 4 lines
Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions.
Quoted 7 lines
Are you confident that this isn't going to break anything like group-shared
DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks likedo_install()might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using "install -m ..." with the permissions that we actually want.This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into "
do_install" really isn't an option. Between the customdo_installcomponents, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value.Quoted 4 lines
(I'd love to be corrected if someone things of another way of doing it.) The setting of the umask is a very low cost operation, so doing it for certain steps shouldn't cause a performance penalty... but until we figure that out this is the best and easiest solution I've come up with.
How about a umask flag for tasks?
If bitbake sees it for a given task it would set the umask as indicated for the task. Cheap and easy and would only impact
do_installtasks...Cheers,
Richard
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core