Re: [OE-core] Why is dnrd blacklisted?
[Why is dnrd blacklisted?] On 17.10.11 (Wed 15:03) Lennart Sorensen wrote: > There is a blacklist entry in the recipe for dnrd claiming there are QA > issues in the package. > > However when the blacklist is removed and the package is built, there > are no QA warnings at all from the package and it seems to be working > perfectly fine. > > Could this blacklist be removed since it makes it harder to build than > it has to be and there is apparently nothing wrong with the recipe in > the first place. Even more so since it was actually removed about a month ago from the tree. :-) But yes, I'm happy to consider a patch that resurrects it if it seems to be working now. I couldn't find the discussion around the QA error in the mailing list, so it was probably something that came up over IRC. I don't know. If it was something the world build found there's (almost?) always a link to the build log. -- -Joe MacDonald. :wq signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for radvd: 2.14 -> 2.17
Please note that the advice from patchtest, in this case, may be misleading. The main issue, I think, is this went to the wrong mailing list. -J. [[OE-core] ✗ patchtest: failure for radvd: 2.14 -> 2.17] On 17.07.24 (Mon 06:01) Patchwork wrote: > == Series Details == > > Series: radvd: 2.14 -> 2.17 > Revision: 1 > URL : https://patchwork.openembedded.org/series/7876/ > State : failure > > == Summary == > > > Thank you for submitting this patch series to OpenEmbedded Core. This is > an automated response. Several tests have been executed on the proposed > series by patchtest resulting in the following failures: > > > > * Issue Series does not apply on top of target branch > [test_series_merge_on_head] > Suggested fixRebase your series on top of targeted branch > Targeted branch master (currently at 514e9be6b0) > > > > If you believe any of these test results are incorrect, please reply to the > mailing list (openembedded-core@lists.openembedded.org) raising your concerns. > Otherwise we would appreciate you correcting the issues and submitting a new > version of the patchset if applicable. Please ensure you add/increment the > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> > [PATCH v3] -> ...). > > --- > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe > -- -Joe MacDonald. :wq signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
Literally no different than v1, differs from v3 in that the doccumentation for
PNDEPRECATED has been removed again, since updates to documentation have to go
to a different list.
meta/classes/deprecated.bbclass| 16
meta/conf/distro/defaultsetup.conf | 3 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(d.getVar('MACHINE'
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
${INHERIT_BLACKLIST}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
[Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)] On 17.02.27 (Mon 14:25) Leonardo Sandoval wrote: > On Mon, 2017-02-27 at 15:06 -0500, Joe MacDonald wrote: > > [✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable > > for recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote: > > > > > == Series Details == > > > > > > Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3) > > > Revision: 3 > > > URL : https://patchwork.openembedded.org/series/5489/ > > > State : failure > > > > > > == Summary == > > > > > > > > > Thank you for submitting this patch series to OpenEmbedded Core. This is > > > an automated response. Several tests have been executed on the proposed > > > series by patchtest resulting in the following failures: > > > > > > > > > > > > * Issue Series does not apply on top of target branch > > > [test_series_merge_on_head] > > > Suggested fixRebase your series on top of targeted branch > > > Targeted branch master (currently at 65cfc8aca3) > > > > I had been out of date, but this time I'm reasonably confident v3 is > > still directly on top of master. > > > > yocto-mainline> git config --local --get-regexp '^remote' > > remote.yocto.url git://git.yoctoproject.org/poky > > remote.yocto.projectname poky > > remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/* > > yocto-mainline> git pull > > Already up-to-date. > > yocto-mainline> git status > > On branch master > > Your branch is ahead of 'yocto/master' by 1 commit. > > (use "git push" to publish your local commits) > > > > nothing to commit, working directory clean > > > > Is patchtest having a bad day? > > yes, there were some issues with the cron job running patchtest but > that is now solved. The problem is that your patch is a documentation > patch, not a oe-core patch, so it does not apply into oe-core. Send it > to the correct list (yo...@yoctoproject.org) if necessary. It's actually both a change to oe-core and the accompanying documentation. I wasn't aware that they needed to be sent to separate lists when introducing a change to meta/ and documentation/ (to document the change in meta/, obviously). Seems like an odd thing to do, but I'll break them up into separate commits, I guess. -J. > > > > > > > > > > If you believe any of these test results are incorrect, please reply to > > > the > > > mailing list (openembedded-core@lists.openembedded.org) raising your > > > concerns. > > > Otherwise we would appreciate you correcting the issues and submitting a > > > new > > > version of the patchset if applicable. Please ensure you add/increment the > > > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> > > > [PATCH v3] -> ...). > > > > > > --- > > > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest > > > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe > > > > > > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
[✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote: > == Series Details == > > Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3) > Revision: 3 > URL : https://patchwork.openembedded.org/series/5489/ > State : failure > > == Summary == > > > Thank you for submitting this patch series to OpenEmbedded Core. This is > an automated response. Several tests have been executed on the proposed > series by patchtest resulting in the following failures: > > > > * Issue Series does not apply on top of target branch > [test_series_merge_on_head] > Suggested fixRebase your series on top of targeted branch > Targeted branch master (currently at 65cfc8aca3) I had been out of date, but this time I'm reasonably confident v3 is still directly on top of master. yocto-mainline> git config --local --get-regexp '^remote' remote.yocto.url git://git.yoctoproject.org/poky remote.yocto.projectname poky remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/* yocto-mainline> git pull Already up-to-date. yocto-mainline> git status On branch master Your branch is ahead of 'yocto/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working directory clean Is patchtest having a bad day? > If you believe any of these test results are incorrect, please reply to the > mailing list (openembedded-core@lists.openembedded.org) raising your concerns. > Otherwise we would appreciate you correcting the issues and submitting a new > version of the patchset if applicable. Please ensure you add/increment the > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> > [PATCH v3] -> ...). > > --- > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe > -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
v2: Included documentation for new variable
v3: Refreshed to address patchwork scolding
documentation/ref-manual/ref-classes.xml | 28
documentation/ref-manual/ref-variables.xml | 28
meta/classes/deprecated.bbclass| 16
meta/conf/distro/defaultsetup.conf | 3 ++-
4 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/documentation/ref-manual/ref-classes.xml
b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
+
+deprecated.bbclass
+
+
+The deprecated class identifies recipes
+that for one reason or another are being considered for removal
+from their current layer. It may be due to persistent, known
+issues with the package, that there are newer, more feature-rich
+alternatives available in the same layer or that the recipe is
+no longer needed. The recipe should provide a reason for the
+depercation and a suggestion to consumers of the recipe as to how
+to proceed.
+To use this class, inherit the class globally and set
+PNDEPRECATED
+for each recipe you intend to deprecate.
+Specify the PN
+value as a variable flag (varflag) and provide a reason, which is
+reported, if the package is requested to be built as the value.
+For example, if you want to deprecate a recipe called "exoticware",
+you add the following to your local.conf
+or distribution configuration:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has
been replaced by 'standardware'. 'exoticware' may not appear in future
releases."
+
+
+
+
devshell.bbclass
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
+PNDEPRECATED
+
+PNDEPRECATED[doc] = "Lists recipes that may be removed in a
future release or have more actively maintained alternatives."
+
+
+
+
+Lists recipes that may be removed in a future release or
+have more actively maintained alternatives.
+This variable works in conjunction with the
+deprecated
+class, which the recipe must inherit globally.
+
+
+
+To identify a recipe as deprecated, inherit the class
+globally and use the variable in your
+local.conf file.
+Here is an example that will show a warning when
+myrecipe is included in a project:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you
should consider using 'mynewrecipe' as an alternative."
+
+
+
+
+
POPULATE_SDK_POST_HOST_COMMAND
POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of
functions to call once the OpenEmbedded build system has created host part of
the SDK."
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(d.getVar('MACHINE'
USER_CLA
Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
[Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes] On 17.02.24 (Fri 21:51) Martin Jansa wrote: > OK, should I update all currently PNBLACKLISTed recipes to add " - the > recipe will be removed on 2017-09-01 unless the issue is fixed" in the > PNBLACKLIST value, so that we can delete all blacklisted recipes > before 2.4 release? I haven't seen any additional discussion on this yet but my personal opinion on this is it seems reasonable to draw a line in the sand and one that's quite far out. I also expect that there'll be a flurry of activity as the deadline draws close, so there's room for flexibility in the drop-dead date, but that'd be a discretionary thing. If we wanted to be slightly less contentious, the wording could be 'may' rather than 'will' and then the message is "if it isn't fixed by this date, it's fair game to be removed whenever someone gets around to it". -J. > > On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister <phi...@balister.org> wrote: > > On 02/24/2017 01:16 AM, Martin Jansa wrote: > >> If nobody speaks up within some > > amount of time the maintainer considers reasonable (I'm thinking a Yocto > > release > > cycle) then it's fair game to remove the recipe in question. > > > > Maybe this is different case with at least some PNBLACKLIST entries we > > currently have, but > > I don't remove PNBLACKLISTed recipes, because as we discussed it's > always > > easier to unblacklist > > recipe from e.g. DISTRO config if the issue doesn't affect you for > whatever > > reason and causes > > less churn in the metadata when it gets unblacklisted. > > > > And many PNBLACKLISTed recipes are also abandonware. > > > > I think we need to use a different "flag" for recipes that need > updating, and have maintained upstreams from recipes that have upstreams > that are abandoned. > > So blacklist broken recipes with good upstreams and deprecate recipes > with dead upstreams. > > Philip > > > > > So my question is, if we will remove PNDEPRECATed recipes after one > cycle, > > should we start > > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both > > cases it might backfire > > when someone will fail to find recipe for his favorite abandonware and > will > > try to add completely > > new recipe for it, or we see someone restoring these recipes (e.g. in > own > > layers instead of fixing > > the PNBLACKLIST/PNDEPRECATED reasons in original layer). > > > > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <raj.k...@gmail.com> wrote: > > > >> > >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald > <joe_macdon...@mentor.com> > >> wrote: > >> > >>> Based on the blacklist behaviour, recipes can be tagged as deprecated. > >>> Such recipes will produce a warning message when included in a build > but > >>> unlike blacklisted recipes, the build will continue. > >> > >> > >> Perhaps this should also be documented in manuals > >> > >>> > >>> > >>> Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com> > >>> --- > >>> > >>> I threw this together a long time ago and never got around to sending > it > >>> out for > >>> consideration, but after the excitement last week and this, I got > >>> thinking about > >>> it again and thought it might be useful. My specific use-case for > this > is > >>> recipes I see in meta-networking that I know are largely abandonware > but > >>> that I > >>> don't want to completely throw out without giving some kind of heads > up. > >>> Obviously this is purely informational, there's no mechanism set up > for > >>> purging > >>> deprecated recipes, that's intended to be a maintainer activity, but > the > >>> idea > >>> would be that the maintainer would flag a recipe as deprecated > (probably > >>> when > >>> it's become more trouble than it seems to be worth) and thereafter > users > >>> would > >>> have fair warning that this thing is on notice. If nobody speaks up > >>> within some > >>> amount of
[OE-core] [PATCH v2] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
documentation/ref-manual/ref-classes.xml | 28
documentation/ref-manual/ref-variables.xml | 28
meta/classes/deprecated.bbclass| 16
meta/conf/distro/defaultsetup.conf | 3 ++-
4 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/documentation/ref-manual/ref-classes.xml
b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
+
+deprecated.bbclass
+
+
+The deprecated class identifies recipes
+that for one reason or another are being considered for removal
+from their current layer. It may be due to persistent, known
+issues with the package, that there are newer, more feature-rich
+alternatives available in the same layer or that the recipe is
+no longer needed. The recipe should provide a reason for the
+depercation and a suggestion to consumers of the recipe as to how
+to proceed.
+To use this class, inherit the class globally and set
+PNDEPRECATED
+for each recipe you intend to deprecate.
+Specify the PN
+value as a variable flag (varflag) and provide a reason, which is
+reported, if the package is requested to be built as the value.
+For example, if you want to deprecate a recipe called "exoticware",
+you add the following to your local.conf
+or distribution configuration:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has
been replaced by 'standardware'. 'exoticware' may not appear in future
releases."
+
+
+
+
devshell.bbclass
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
+PNDEPRECATED
+
+PNDEPRECATED[doc] = "Lists recipes that may be removed in a
future release or have more actively maintained alternatives."
+
+
+
+
+Lists recipes that may be removed in a future release or
+have more actively maintained alternatives.
+This variable works in conjunction with the
+deprecated
+class, which the recipe must inherit globally.
+
+
+
+To identify a recipe as deprecated, inherit the class
+globally and use the variable in your
+local.conf file.
+Here is an example that will show a warning when
+myrecipe is included in a project:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you
should consider using 'mynewrecipe' as an alternative."
+
+
+
+
+
POPULATE_SDK_POST_HOST_COMMAND
POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of
functions to call once the OpenEmbedded build system has created host part of
the SDK."
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(d.getVar('MACHINE'
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blackli
[OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
I threw this together a long time ago and never got around to sending it out for
consideration, but after the excitement last week and this, I got thinking about
it again and thought it might be useful. My specific use-case for this is
recipes I see in meta-networking that I know are largely abandonware but that I
don't want to completely throw out without giving some kind of heads up.
Obviously this is purely informational, there's no mechanism set up for purging
deprecated recipes, that's intended to be a maintainer activity, but the idea
would be that the maintainer would flag a recipe as deprecated (probably when
it's become more trouble than it seems to be worth) and thereafter users would
have fair warning that this thing is on notice. If nobody speaks up within some
amount of time the maintainer considers reasonable (I'm thinking a Yocto release
cycle) then it's fair game to remove the recipe in question.
meta/classes/deprecated.bbclass| 16
meta/conf/distro/defaultsetup.conf | 3 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(d.getVar('MACHINE'
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
${INHERIT_BLACKLIST}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] devtool: Add a line break to generated README
When devtool creates a new workspace, it produced a README with one very
long line and no space following 'bblayers.conf'. Add a line break as was
intended.
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
scripts/devtool | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/devtool b/scripts/devtool
index 91e3954..0c32c50 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -187,7 +187,7 @@ def _create_workspace(workspacedir, config, basepath):
f.write('directly (although recipes added with "devtool add" will
often need\n')
f.write('direct modification.)\n')
f.write('\nIf you no longer need to use devtool or the workspace
layer\'s contents\n')
-f.write('you can remove the path to this workspace layer from your
conf/bblayers.conf')
+f.write('you can remove the path to this workspace layer from your
conf/bblayers.conf\n')
f.write('file (and then delete the layer, if you wish).\n')
f.write('\nNote that by default, if devtool fetches and unpacks
source code, it\n')
f.write('will place it in a subdirectory of a "sources"
subdirectory of the\n')
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dpkg-deb: strip virtual/ package prefix in control files
If a recipe provides a 'virtual/foo', dpkg-deb will fail as '/' characters
are not allowed in any of the Depends, Recommends, Suggests, etc. fields.
The intent of these in the Debian package system and the few cases where
they are used in Yocto layers seems like throwing away the 'virtual/'
prefix preserves the intent, while not requiring it to be removed for
package systems that allow it (eg. opkg and rpm).
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
meta/classes/package_deb.bbclass | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 8f9b09a..1e8afa1 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -253,17 +253,17 @@ python do_package_deb () {
rconflicts =
bb.utils.explode_dep_versions2(localdata.getVar("RCONFLICTS", True) or "")
debian_cmp_remap(rconflicts)
if rdepends:
-ctrlfile.write("Depends: %s\n" % bb.utils.join_deps(rdepends))
+ctrlfile.write("Depends: %s\n" % re.sub(r'virtual/', '',
bb.utils.join_deps(rdepends)))
if rsuggests:
-ctrlfile.write("Suggests: %s\n" % bb.utils.join_deps(rsuggests))
+ctrlfile.write("Suggests: %s\n" % re.sub(r'virtual/', '',
bb.utils.join_deps(rsuggests)))
if rrecommends:
-ctrlfile.write("Recommends: %s\n" %
bb.utils.join_deps(rrecommends))
+ctrlfile.write("Recommends: %s\n" % re.sub(r'virtual/', '',
bb.utils.join_deps(rrecommends)))
if rprovides:
-ctrlfile.write("Provides: %s\n" % bb.utils.join_deps(rprovides))
+ctrlfile.write("Provides: %s\n" % re.sub(r'virtual/', '',
bb.utils.join_deps(rprovides)))
if rreplaces:
-ctrlfile.write("Replaces: %s\n" % bb.utils.join_deps(rreplaces))
+ctrlfile.write("Replaces: %s\n" % re.sub(r'virtual/', '',
bb.utils.join_deps(rreplaces)))
if rconflicts:
-ctrlfile.write("Conflicts: %s\n" % bb.utils.join_deps(rconflicts))
+ctrlfile.write("Conflicts: %s\n" % re.sub(r'virtual/', '',
bb.utils.join_deps(rconflicts)))
ctrlfile.close()
for script in ["preinst", "postinst", "prerm", "postrm"]:
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] classes/base: provide hints on PACKAGECONFIG error
Commit 771f89498c introduces an error message that is very rarely hit and
when it is, it is usually easy to trace the root cause very quickly. The
information provided in the error message isn't enough to lead you back to
the actual failure, however, so expand upon it a bit, pinpointing the
specific package and flag that fails.
Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com>
---
meta/classes/base.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f078001..d711ae4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -391,7 +391,8 @@ python () {
items = flagval.split(",")
num = len(items)
if num > 4:
-bb.error("Only enable,disable,depend,rdepend can be
specified!")
+bb.error("%s: PACKAGECONFIG[%s] Only
enable,disable,depend,rdepend can be specified!"
+% (d.getVar('PN', True), flag))
if flag in pkgconfig:
if num >= 3 and items[2]:
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libpcap: add pkg-config support
libpcap was not previously installing a pkg-config file. Add a basic one
that will allow using 'pkg-config --libs libpcap', for example, in recipes
rather than 'pcap-config', which frequently returns incorrect information.
Signed-off-by: Joe MacDonald joe_macdon...@mentor.com
---
Hmm, pretty sure I sent this to the wrong list, now that I think about it. So
here's what I put in the comment I sent to the Yocto list. Sorry about that.
I'm not convinced that this is necessary, but when I tried to convert the ptpd
recipe in meta-networking to stop failing by using pcap-config it seems like
libpcap was never actually installing a reasonable .pc file. The only other
example I could find in meta-networking switched from using pcap-config to an
internal pcap library, rather than using the oe-core version, so maybe it really
isn't working for anyone right now. I created something that at least gets ptpd
to stop blowing up, but if there's a proper way to do this for ptpd, I'd be
happy to adopt that instead.
-J.
meta/recipes-connectivity/libpcap/libpcap.inc | 2 +-
.../libpcap/libpcap-pkgconfig-support.patch| 71 ++
meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb | 6 +-
3 files changed, 77 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch
diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 979665c..0c608b5 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
file://pcap.h;beginline=1;endline=32;md5=39af3510e011f34b8872f120b1dc31d2
DEPENDS = flex-native bison-native
-inherit bluetooth
+inherit bluetooth pkgconfig
PACKAGECONFIG ??= ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
'${BLUEZ}', '', d)}
PACKAGECONFIG[bluez4] = --enable-bluetooth,--disable-bluetooth,bluez4
diff --git
a/meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch
b/meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch
new file mode 100644
index 000..9cfb9df
--- /dev/null
+++ b/meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch
@@ -0,0 +1,71 @@
+From 8887132e85892a72a84ca3878e60f254ad2ce939 Mon Sep 17 00:00:00 2001
+From: Joe MacDonald joe_macdon...@mentor.com
+Date: Tue, 24 Feb 2015 15:56:06 -0500
+Subject: [PATCH] libpcap: pkgconfig support
+
+Adding basic structure to support pkg-config.
+
+Upstream-status: Inappropriate [embedded specific]
+
+Signed-off-by: Joe MacDonald joe_macdon...@mentor.com
+---
+ Makefile.in | 5 +
+ configure.in | 1 +
+ libpcap.pc.in | 10 ++
+ 3 files changed, 16 insertions(+)
+ create mode 100644 libpcap.pc.in
+
+diff --git a/Makefile.in b/Makefile.in
+index 1c2d745..1f25faf 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -60,6 +60,10 @@ V_RPATH_OPT = @V_RPATH_OPT@
+ DEPENDENCY_CFLAG = @DEPENDENCY_CFLAG@
+ PROG=libpcap
+
++# pkgconfig support
++pkgconfigdir = $(libdir)/pkgconfig
++pkgconfig_DATA = libpcap.pc
++
+ # Standard CFLAGS
+ FULL_CFLAGS = $(CCOPT) $(INCLS) $(DEFS) $(CFLAGS)
+
+@@ -275,6 +279,7 @@ EXTRA_DIST = \
+ lbl/os-solaris2.h \
+ lbl/os-sunos4.h \
+ lbl/os-ultrix4.h \
++ libpcap.pc \
+ missing/snprintf.c \
+ mkdep \
+ msdos/bin2c.c \
+diff --git a/configure.in b/configure.in
+index 8f5c86b..fb51b35 100644
+--- a/configure.in
b/configure.in
+@@ -1700,6 +1700,7 @@ esac
+ AC_PROG_INSTALL
+
+ AC_CONFIG_HEADER(config.h)
++AC_CONFIG_FILES([libpcap.pc])
+
+ AC_OUTPUT_COMMANDS([if test -f .devel; then
+ echo timestamp stamp-h
+diff --git a/libpcap.pc.in b/libpcap.pc.in
+new file mode 100644
+index 000..4f78ad8
+--- /dev/null
b/libpcap.pc.in
+@@ -0,0 +1,10 @@
++prefix=@prefix@
++exec_prefix=@exec_prefix@
++libdir=@libdir@
++includedir=@includedir@
++
++Name: libpcap
++Description: System-independent interface for user-level packet capture.
++Version: @VERSION@
++Libs: -L${libdir} -lpcap
++Cflags: -I${includedir}
+--
+1.9.1
+
diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
b/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
index a2d5ef4..611543e 100644
--- a/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
+++ b/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
@@ -1,6 +1,8 @@
require libpcap.inc
-SRC_URI += file://aclocal.patch
+SRC_URI += file://aclocal.patch \
+file://libpcap-pkgconfig-support.patch \
+
SRC_URI[md5sum] = 5f14191c1a684a75532c739c2c4059fa
SRC_URI[sha256sum] =
5db3e2998f1eeba2c76da55da5d474248fe19c44f49e15cac8a796a2c7e19690
@@ -19,4 +21,6 @@ do_install_prepend () {
install -d ${D}${bindir}
oe_runmake install-shared DESTDIR=${D}
oe_libinstall -a -so libpcap ${D}${libdir}
+sed s|@VERSION@|${PV}| -i ${B}/libpcap.pc
Re: [OE-core] State of bitbake world, Failed tasks 2015-02-18
, but no providers in its RDEPENDS [file-rdeps] lio-utils-4.1+gitAUTOINC+28bd928655: lio-utils requires /bin/bash, but no providers in its RDEPENDS [file-rdeps] lmsensors-config-1.0: lmsensors-config-cgi requires /usr/bin/rrdcgi, but no providers in its RDEPENDS [file-rdeps] nodejs-0.8.18: nodejs requires /bin/bash, but no providers in its RDEPENDS [file-rdeps] numptyphysics-0.2+svnr109: numptyphysics requires /bin/bash, /usr/bin/perl, but no providers in its RDEPENDS [file-rdeps] opensaf-4.5.0: opensaf requires /bin/bash, /usr/bin/python, but no providers in its RDEPENDS [file-rdeps] packagekit-0.5.6: packagekit requires /bin/bash, but no providers in its RDEPENDS [file-rdeps] pcsc-lite-1.8.6: pcsc-lite requires /usr/bin/python, but no providers in its RDEPENDS [file-rdeps] pm-qa-0.4.14: pm-qa requires /bin/bash, but no providers in its RDEPENDS [file-rdeps] qt-creator-2.8.1: qt-creator requires /usr/bin/perl, but no providers in its RDEPENDS [file-rdeps] tracker-0.14.2: tracker-nautilus-extension requires libnautilus-extension.so.1()(64bit), but no providers in its RDEPENDS [file-rdeps] tracker-0.14.2: tracker-nautilus-extension requires libnautilus-extension.so.1, but no providers in its RDEPENDS [file-rdeps] ubx-utils-0.0.0+gitrAUTOINC+b63c0932dd: ubx-utils requires /bin/bash, but no providers in its RDEPENDS [file-rdeps] unionfs-fuse-0.26: unionfs-fuse requires /bin/bash, but no providers in its RDEPENDS [file-rdeps] usbpath-0.0+svnr3172: usbpath requires /usr/bin/perl, but no providers in its RDEPENDS [file-rdeps] wvstreams-4.6.1: wvstreams requires /usr/bin/perl, but no providers in its RDEPENDS [file-rdeps] count: 0 issue: version-going-backwards -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Joe MacDonald :wq -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-networking][PATCH v2] openl2tp: add new recipe
From: Li xin lixin.f...@cn.fujitsu.com OpenL2TP is an open source L2TP client / server, written specifically for Linux. It has been designed for use as an enterprise L2TP VPN server or in commercial, Linux-based, embedded networking products and is able to support hundreds of sessions, each with different configuration. It is used by several ISPs to provide L2TP services and by corporations to implement L2TP VPNs. Signed-off-by: Li Xin lixin.f...@cn.fujitsu.com Signed-off-by: Joe MacDonald joe_macdon...@mentor.com --- Martin: This is basically just a minor clean-up of the earlier openl2tp recipe. So far I've been unable to reproduce the error reported in the world build. If there's still a log kicking around from that failure, I'd love to get a look at it, I'm also doing a world build locally to try this out, but it still looks like it should be okay now. If it fails for you again before I get some kind of results, can you point me at the log? -J. ...kefile-modify-CFLAGS-to-aviod-build-error.patch | 106 + .../recipes-protocols/openl2tp/openl2tp_1.8.bb | 32 +++ 2 files changed, 138 insertions(+) create mode 100644 meta-networking/recipes-protocols/openl2tp/openl2tp/Makefile-modify-CFLAGS-to-aviod-build-error.patch create mode 100644 meta-networking/recipes-protocols/openl2tp/openl2tp_1.8.bb diff --git a/meta-networking/recipes-protocols/openl2tp/openl2tp/Makefile-modify-CFLAGS-to-aviod-build-error.patch b/meta-networking/recipes-protocols/openl2tp/openl2tp/Makefile-modify-CFLAGS-to-aviod-build-error.patch new file mode 100644 index 000..96dbc75 --- /dev/null +++ b/meta-networking/recipes-protocols/openl2tp/openl2tp/Makefile-modify-CFLAGS-to-aviod-build-error.patch @@ -0,0 +1,106 @@ +From 152486fa3c36c3b99d17d5b553cf87ef412fae8e Mon Sep 17 00:00:00 2001 +From: Li xin lixin.f...@cn.fujitsu.com +Date: Mon, 1 Dec 2014 01:53:41 +0900 +Subject: [PATCH] Makefile:modify CFLAGS to aviod build error. + +Upstream-Status: pending + +Signed-off-by: Li Xin lixin.f...@cn.fujitsu.com +--- + Makefile | 22 +++--- + plugins/Makefile | 6 +++--- + 2 files changed, 14 insertions(+), 14 deletions(-) + +diff --git a/Makefile b/Makefile +index 4aaa448..baa7882 100644 +--- a/Makefile b/Makefile +@@ -152,10 +152,10 @@ LIBS.dmalloc=-ldmalloc + export USE_DMALLOC + endif + +-CPPFLAGS= $(CPPFLAGS.l2tptest) $(CPPFLAGS-y) +-CFLAGS= -I. -Iusl -Icli -isystem include \ +- -MMD -Wall -Werror -Wno-strict-aliasing \ +- $(CPPFLAGS) $(CPPFLAGS.dmalloc) \ ++ADD_CPPFLAGS= $(CPPFLAGS.l2tptest) $(CPPFLAGS-y) ++ADD_CFLAGS= -I. -Iusl -Icli -isystem include \ ++ -MMD -Wall -Wno-strict-aliasing \ ++ $(ADD_CPPFLAGS) $(CPPFLAGS.dmalloc) \ + -DSYS_LIBDIR=$(SYS_LIBDIR) + LDFLAGS.l2tpd=-Wl,-E -L. -Lusl -lusl -ldl $(LIBS.dmalloc) -lc + LDFLAGS.l2tpconfig= -Lcli -lcli -lreadline $(LIBS.dmalloc) $(READLINE_LDFLAGS) -lc +@@ -170,10 +170,10 @@ CFLAGS.optimize= $(OPT_CFLAGS) + endif + export CFLAGS.optimize + +-CFLAGS+= $(CFLAGS.optimize) ++ADD_CFLAGS+= $(CFLAGS.optimize) + + ifeq ($(L2TP_USE_ASYNC_RPC),y) +-CPPFLAGS+=-DL2TP_ASYNC_RPC ++ADD_CPPFLAGS+=-DL2TP_ASYNC_RPC + endif + + ifeq ($(L2TP_FEATURE_RPC_MANAGEMENT),y) +@@ -220,13 +220,13 @@ endif + + # Compile without -Wall because rpcgen-generated code is full of warnings. + %_xdr.o: %_xdr.c +- $(CC) -I. -MMD -w $(CFLAGS.optimize) -c $(CPPFLAGS) $ ++ $(CC) -I. -MMD -w $(CFLAGS.optimize) -c $(ADD_CPPFLAGS) $ + + %_client.o: %_client.c +- $(CC) -I. -MMD -w $(CFLAGS.optimize) -c $(CPPFLAGS) $ ++ $(CC) -I. -MMD -w $(CFLAGS.optimize) -c $(ADD_CPPFLAGS) $ + + %_server.o: %_server.c +- $(CC) -I. -MMD -w $(CFLAGS.optimize) -c $(CPPFLAGS) $ ++ $(CC) -I. -MMD -w $(CFLAGS.optimize) -c $(ADD_CPPFLAGS) $ + + %_xdr.c: %.x + -$(RM) $@ +@@ -272,7 +272,7 @@ l2tpconfig:$(L2TPCONFIG_SRCS.o) + $(CC) -o $@ $^ $(LDFLAGS.l2tpconfig) + + %.o: %.c +- $(CC) -c $(CFLAGS) $ -o $@ ++ $(CC) -c $(CFLAGS) $(ADD_CFLAGS) $ -o $@ + + l2tp_options.h: FORCE + @rm -f $@.tmp +@@ -325,7 +325,7 @@ install: install-all + install-all: all install-daemon install-app + + install-daemon: +- @for d in $(filter-out usl,$(SUBDIRS)); do $(MAKE) -C $$d $(MFLAGS) EXTRA_CFLAGS=$(CPPFLAGS) install; if [ $$? -ne 0 ]; then exit 1; fi; done ++ @for d in $(filter-out usl,$(SUBDIRS)); do $(MAKE) -C $$d $(MFLAGS) EXTRA_CFLAGS
[OE-core] [meta-networking][PATCH] meta-networking: update LAYERDEPENDS
A minor typo was causing LAYERDEPENDS to be overwritten instead of
appended to in our layer.conf.
Signed-off-by: Joe MacDonald joe_macdon...@mentor.com
---
meta-networking/conf/layer.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-networking/conf/layer.conf b/meta-networking/conf/layer.conf
index d99d738..63bb07d 100644
--- a/meta-networking/conf/layer.conf
+++ b/meta-networking/conf/layer.conf
@@ -14,7 +14,7 @@ BBFILE_PRIORITY_networking-layer = 5
LAYERVERSION_networking-layer = 1
LAYERDEPENDS_networking-layer = core
-LAYERDEPENDS_networking-layer = openembedded-layer
-LAYERDEPENDS_networking-layer = meta-python
+LAYERDEPENDS_networking-layer += openembedded-layer
+LAYERDEPENDS_networking-layer += meta-python
LICENSE_PATH += ${LAYERDIR}/licenses
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Reagrding meta-networking
[Re: [OE-core] Reagrding meta-networking] On 14.07.01 (Tue 02:24) Himanshu Pandey wrote: So, do I have to set IMAGE_INSTALL variable in local.conf and packagename_X is what to be followed for the addition of each package. That is certainly an option, though I tend to prefer IMAGE_INSTALL_append for local.conf tweaks. If you expect this to be a longer-term thing, you may want to consider defining an image type for your project that includes specifically what you want in it. -J. Regards, Himanshu From: Henning Heinold henn...@itconsulting-heinold.de Sent: Tue, 01 Jul 2014 01:01:52 To: openembedded-core@lists.openembedded.org openembedded-core@lists.openembedded.org Subject: Re: [OE-core] Reagrding meta-networking On Mon, Jun 30, 2014 at 01:29:26PM -, Himanshu Pandey wrote: Hi, Since I want dhcp and pppoe, so I downloaded the same from git and included meta-networking layer in bblayers.conf. This layer is getting compiled but somehow dhcp and pppoe are not getting included in the final image. So what I have to do inorder to add dhcp and pppoe in the final image. Please help. Regards, Himanshu IMAGE_INSTALL += packagename_dhcp packagname_pppoe Be aware that recipe(bb)-name is mostly not the resulting packagename. Bye Henning -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core [signaturel] Get your own FREE website, FREE domain FREE mobile app withKnow More Company email. -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world
[Re: [OE-core] State of bitbake world] On 13.11.19 (Tue 16:50) Martin Jansa wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I'm interested. I've not had nearly as much time to hunt down the ones I own as I'd like, but I do appreciate the mail and I flag them in my mailboxes for easy reference later. -J. The stats also show that nobody is interested in fixing them, some issues are there for 6+ months. Date Failed tasksQA QA-w/o-unrecognized qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 2013-11-1912 17 19 141 142 131 29 27 18 2013-11-0311 18 19 96 127 123 22 21 16 2013-10-319 17 19 74 114 107 23 21 14 2013-10-3011 16 18 224 191 184 28 23 16 -- -Joe MacDonald. :wq signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][RFC PATCH] sstate.bbclass: Add an extra check for sstate_mirrors
BB_NO_NETWORK disables any fetching, however if we're using an external
sstate cache, we may want to be able to fetch those objects even if we are
not fetching the upstream sources. Denote this situation by setting
SSTATE_MIRROR_ALLOW_NETWORK in local.conf. When it is found, for sstate
cache fetches, mask off BB_NO_NETWORK for the local function.
Signed-off-by: Joe MacDonald joe.macdon...@windriver.com
---
meta/classes/sstate.bbclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 28dc312..c1ca54b 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -509,6 +509,11 @@ def pstaging_fetch(sstatefetch, sstatepkg, d):
localdata.setVar('DL_DIR', dldir)
localdata.setVar('PREMIRRORS', mirrors)
+# if BB_NO_NETWORK is set but we also have SSTATE_MIRROR_ALLOW_NETWORK,
+# we'll want to allow network access for the current set of fetches.
+if localdata.getVar('BB_NO_NETWORK', True) == 1 and
localdata.getVar('SSTATE_MIRROR_ALLOW_NETWORK', True) == 1:
+localdata.delVar('BB_NO_NETWORK')
+
# Try a fetch from the sstate mirror, if it fails just return and
# we will build the package
for srcuri in ['file://{0}'.format(sstatefetch),
@@ -619,6 +624,11 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
bb.debug(2, SState using premirror of: %s % mirrors)
+# if BB_NO_NETWORK is set but we also have SSTATE_MIRROR_ALLOW_NETWORK,
+# we'll want to allow network access for the current set of fetches.
+if localdata.getVar('BB_NO_NETWORK', True) == 1 and
localdata.getVar('SSTATE_MIRROR_ALLOW_NETWORK', True) == 1:
+localdata.delVar('BB_NO_NETWORK')
+
for task in range(len(sq_fn)):
if task in ret:
continue
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bdwgc: support configure on autoconf 2.69
Adding the oe-core list back to the cc list since I accidentally dropped
the list on my first response.
On Wed, Jun 19, 2013 at 10:37 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2013-06-19 at 10:15 -0400, Joe MacDonald wrote:
On Wed, Jun 19, 2013 at 10:10 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2013-06-19 at 09:56 -0400, j...@deserted.net wrote:
From: Joe MacDonald j...@deserted.net
Building bdwgc-native on systems with older versions of
autoconf (earlier
than 2.69) is known to have issues:
https://github.com/ivmai/bdwgc/issues/16
An option is to simply mask the errors with
m4_pattern_allow(...) for each
of the macros, but rerunning autoreconf produces a
functional configure
script that builds a functional native version of bdwgc.
Signed-off-by: Joe MacDonald j...@deserted.net
---
meta/recipes-support/bdwgc/bdwgc_7.2d.bb | 9 +
1 file changed, 9 insertions(+)
I tripped over this yesterday on one of my older builders.
It happens to still
be Ubuntu 12.04.2. I don't know if it's unique to my
configuration, but after
doing some digging around on the web I can't see any obvious
indications that
I'm missing any autotools package and the general consensus
seems to be that
autoreconf is the best option when the failures are
relatively beign as they
are here.
-J.
diff --git a/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
b/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
index 46e5257..d8e2de5 100644
--- a/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
+++ b/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
@@ -36,3 +36,12 @@ ARM_INSTRUCTION_SET = arm
inherit autotools
BBCLASSEXTEND = native nativesdk
+
+do_configure_prepend() {
+ # Without this, on older installations of autoconf
errors crop up during configure:
+ # | configure.ac:70: error: possibly undefined macro:
AC_MSG_ERROR
+ # | If this token and others are legitimate,
please use m4_pattern_allow.
+ # | See the Autoconf documentation.
+ # | configure.ac:358: error: possibly undefined macro:
AS_IF
+ ( cd ${S}; autoreconf -i )
+}
This is timely since we're seeing this issue on some of the
autobuilders. We should be autoreconfing by default though,
any idea why
it doesn't in this case?
No, I didn't actually dig into that, I didn't realize it should be
autoreconfing. Is it explciit in the do_configure step, or implicit?
Maybe it's a timestamp issue or something? The only machine I've got
left that has this problem is pretty fast, so maybe on a slower (or
more heavily loaded) machine an implicit rule will fire where a beefy,
unloaded one won't? Just a wild guess.
Reading the link you supplied further, it could be a missing pkgconfig
dependency?
I thought so at first, but I couldn't find anything absent on my builder
that looked even remotely pkgconfig-related. Then I started digging into
the autotools stuff, since the warning is clearly about expanding autoconf
macros and that's when I finally started paying attention to the version
numbers on the failing host versus the builders I use that weren't
complaining.
It could still be that there's something missing, but when I noticed the
comment just below the closed bar in the issue I linked:
https://github.com/ivmai/bdwgc/issues/16#issuecomment-7854845
ivmaihttps://github.com/ivmai
commented https://github.com/ivmai/bdwgc/issues/16#issuecomment-785484510
months ago https://github.com/ivmai/bdwgc/issues/16#issuecomment-7854845
I have tested the git sources from bdwgc and they only configure properly
with autoconf = 2.69. [...]
It seemed like I'd found at least confirmation that what I was seeing was
expected.
I have no idea why the autotools.bbclass' autoreconf wouldn't do it,
though. I'll go have a quick look to see if the tree is different because
I also passed it -i when I did the autoreconf.
--
Joe MacDonald
:wq
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bdwgc: support configure on autoconf 2.69
On Wed, Jun 19, 2013 at 11:02 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2013-06-19 at 10:50 -0400, Joe MacDonald wrote:
Adding the oe-core list back to the cc list since I accidentally
dropped the list on my first response.
On Wed, Jun 19, 2013 at 10:37 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2013-06-19 at 10:15 -0400, Joe MacDonald wrote:
On Wed, Jun 19, 2013 at 10:10 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2013-06-19 at 09:56 -0400, j...@deserted.net
wrote:
From: Joe MacDonald j...@deserted.net
Building bdwgc-native on systems with older
versions of
autoconf (earlier
than 2.69) is known to have issues:
https://github.com/ivmai/bdwgc/issues/16
An option is to simply mask the errors with
m4_pattern_allow(...) for each
of the macros, but rerunning autoreconf produces a
functional configure
script that builds a functional native version of
bdwgc.
Signed-off-by: Joe MacDonald j...@deserted.net
---
meta/recipes-support/bdwgc/bdwgc_7.2d.bb | 9
+
1 file changed, 9 insertions(+)
I tripped over this yesterday on one of my older
builders.
It happens to still
be Ubuntu 12.04.2. I don't know if it's unique to
my
configuration, but after
doing some digging around on the web I can't see
any obvious
indications that
I'm missing any autotools package and the general
consensus
seems to be that
autoreconf is the best option when the failures
are
relatively beign as they
are here.
-J.
diff --git
a/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
b/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
index 46e5257..d8e2de5 100644
--- a/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
+++ b/meta/recipes-support/bdwgc/bdwgc_7.2d.bb
@@ -36,3 +36,12 @@ ARM_INSTRUCTION_SET = arm
inherit autotools
BBCLASSEXTEND = native nativesdk
+
+do_configure_prepend() {
+ # Without this, on older installations of
autoconf
errors crop up during configure:
+ # | configure.ac:70: error: possibly
undefined macro:
AC_MSG_ERROR
+ # | If this token and others are
legitimate,
please use m4_pattern_allow.
+ # | See the Autoconf documentation.
+ # | configure.ac:358: error: possibly
undefined macro:
AS_IF
+ ( cd ${S}; autoreconf -i )
+}
This is timely since we're seeing this issue on some
of the
autobuilders. We should be autoreconfing by default
though,
any idea why
it doesn't in this case?
No, I didn't actually dig into that, I didn't realize it
should be
autoreconfing. Is it explciit in the do_configure step, or
implicit?
Maybe it's a timestamp issue or something? The only
machine I've got
left that has this problem is pretty fast, so maybe on a
slower (or
more heavily loaded) machine an implicit rule will fire
where a beefy,
unloaded one won't? Just a wild guess.
Reading the link you supplied further, it could be a missing
pkgconfig
dependency?
I thought so at first, but I couldn't find anything absent on my
builder that looked even remotely pkgconfig-related. Then I started
digging into the autotools stuff, since the warning is clearly about
expanding autoconf macros and that's when I finally started paying
attention to the version numbers on the failing host versus the
builders I use that weren't complaining.
It could still be that there's something missing, but when I noticed
the comment just below the closed bar in the issue I
Re: [OE-core] should perl modules go in oe-core? (possibly python and ruby ones too)
[[OE-core] should perl modules go in oe-core? (possibly python and ruby ones too)] On 13.05.16 (Thu 14:56) Jesse Zhang wrote: Hi, We've accumulated quite a few perl modules and would like to contribute some/all of them to oe-core. But I think we'd better ask how everyone thinks before doing so, since the number of the modules are pretty large, and the policy may as well apply to python/ruby packages. Most of the modules are simple cpan recipes. They are easy to maintain, but do consume *some* manpower. I think there are a few alternatives. 1. decide on each module on a case-by-case basis. 2. keep all of them in some special layer other than oe-core. 3. everyone maintain what they need in-house. Have you considered the possibility of a meta-perl or meta-cpan layer in meta-openembedded? It was the first thing that occurred to me and I see both Phil and Richard making pretty similar suggestions. There's already a meta-ruby layer there and it may also help address some of the perl dependency problems that crop up in recipes in meta-Openembedded. -J. None of them seems perfect. Is there already some policy? jesse ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- -Joe MacDonald. :wq signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: Creating meta-networking
On Thu, Aug 23, 2012 at 2:22 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 22 aug. 2012, om 21:22 heeft Chris Larson kerg...@gmail.com het volgende geschreven: On Wed, Aug 22, 2012 at 11:59 AM, Joe MacDonald j...@deserted.net wrote: On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson kerg...@gmail.com wrote: On Friday, June 15, 2012 at 8:15 AM, Joe MacDonald wrote: We've been talking about this on-and-off at Wind River for a while now, but it now seems like a reasonable time to bring a proposal to the OE community at large. We're thinking about creating a new layer to house recipes, etc. for networking packages. I'll try to address what seem to be the most immediate questions (certainly the ones we've been thinking most about any time I've discussed this with anyone): Has their been any progress on the creation of this layer? Absolutely. I think at least some of my mail on the subject have been bouncing from the lists but the short version is at the end of July the existing meta-openembedded pieces were done in my tree and there was a list of stuff that needed fixing in migrating the oe-classic bits into the new meta-networking layer (the list I laid out in my initial email). I was on vacation between then and Monday, so nothing's happened since then but this week I'm back looking at the best way to handle these older recipes that are in need of love in order to work with the current meta-oe and we should be good to go. I think what's likely to happen is there will be some of them updated right away and others will be integrated and updated soon after. Sounds good, thanks for the update. Is this repository-in-progress available somewhere public yet? I'd very much welcome a patch creating an empty layer in meta-openembedded with just the README, layer.conf and COPYING.MIT Easily done! git-send-emailing it now. -- Joe MacDonald :wq ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: Creating meta-networking
On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson kerg...@gmail.com wrote: On Friday, June 15, 2012 at 8:15 AM, Joe MacDonald wrote: We've been talking about this on-and-off at Wind River for a while now, but it now seems like a reasonable time to bring a proposal to the OE community at large. We're thinking about creating a new layer to house recipes, etc. for networking packages. I'll try to address what seem to be the most immediate questions (certainly the ones we've been thinking most about any time I've discussed this with anyone): Has their been any progress on the creation of this layer? Absolutely. I think at least some of my mail on the subject have been bouncing from the lists but the short version is at the end of July the existing meta-openembedded pieces were done in my tree and there was a list of stuff that needed fixing in migrating the oe-classic bits into the new meta-networking layer (the list I laid out in my initial email). I was on vacation between then and Monday, so nothing's happened since then but this week I'm back looking at the best way to handle these older recipes that are in need of love in order to work with the current meta-oe and we should be good to go. I think what's likely to happen is there will be some of them updated right away and others will be integrated and updated soon after. -J. -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Joe MacDonald :wq ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: Creating meta-networking
On Wed, Aug 22, 2012 at 3:22 PM, Chris Larson kerg...@gmail.com wrote: On Wed, Aug 22, 2012 at 11:59 AM, Joe MacDonald j...@deserted.net wrote: On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson kerg...@gmail.com wrote: On Friday, June 15, 2012 at 8:15 AM, Joe MacDonald wrote: We've been talking about this on-and-off at Wind River for a while now, but it now seems like a reasonable time to bring a proposal to the OE community at large. We're thinking about creating a new layer to house recipes, etc. for networking packages. I'll try to address what seem to be the most immediate questions (certainly the ones we've been thinking most about any time I've discussed this with anyone): Has their been any progress on the creation of this layer? Absolutely. I think at least some of my mail on the subject have been bouncing from the lists but the short version is at the end of July the existing meta-openembedded pieces were done in my tree and there was a list of stuff that needed fixing in migrating the oe-classic bits into the new meta-networking layer (the list I laid out in my initial email). I was on vacation between then and Monday, so nothing's happened since then but this week I'm back looking at the best way to handle these older recipes that are in need of love in order to work with the current meta-oe and we should be good to go. I think what's likely to happen is there will be some of them updated right away and others will be integrated and updated soon after. Sounds good, thanks for the update. Is this repository-in-progress available somewhere public yet? Yep, sure is, though I'd discourage using it as a basis for work right now as I'm not guaranteeing a clean history on it. It's full of dead branches and options I'd been working through with Koen. So now that you know what you're getting into, my current WIP is here: https://github.com/joeythesaint/meta-oe/tree/meta-networking-reordered-1 You can expect that the top commit (dd48fb590) will not be present at all in the final version but everything leading up to it will likely remain unchanged in the final version, I think we're mostly settled on those being sensible. Though since this is still a WIP I plan to rebase the whole branch before sending any kind of pull request. -- Joe MacDonald :wq ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: Creating meta-networking
On Wed, Aug 22, 2012 at 3:37 PM, Joe MacDonald j...@deserted.net wrote: On Wed, Aug 22, 2012 at 3:22 PM, Chris Larson kerg...@gmail.com wrote: On Wed, Aug 22, 2012 at 11:59 AM, Joe MacDonald j...@deserted.net wrote: On Wed, Aug 22, 2012 at 2:20 PM, Christopher Larson kerg...@gmail.com wrote: On Friday, June 15, 2012 at 8:15 AM, Joe MacDonald wrote: We've been talking about this on-and-off at Wind River for a while now, but it now seems like a reasonable time to bring a proposal to the OE community at large. We're thinking about creating a new layer to house recipes, etc. for networking packages. I'll try to address what seem to be the most immediate questions (certainly the ones we've been thinking most about any time I've discussed this with anyone): Has their been any progress on the creation of this layer? Absolutely. I think at least some of my mail on the subject have been bouncing from the lists but the short version is at the end of July the existing meta-openembedded pieces were done in my tree and there was a list of stuff that needed fixing in migrating the oe-classic bits into the new meta-networking layer (the list I laid out in my initial email). I was on vacation between then and Monday, so nothing's happened since then but this week I'm back looking at the best way to handle these older recipes that are in need of love in order to work with the current meta-oe and we should be good to go. I think what's likely to happen is there will be some of them updated right away and others will be integrated and updated soon after. Sounds good, thanks for the update. Is this repository-in-progress available somewhere public yet? Yep, sure is, though I'd discourage using it as a basis for work right now as I'm not guaranteeing a clean history on it. It's full of dead branches and options I'd been working through with Koen. So now that you know what you're getting into, my current WIP is here: https://github.com/joeythesaint/meta-oe/tree/meta-networking-reordered-1 You can expect that the top commit (dd48fb590) will not be present at all in the final version but everything leading up to it will likely remain unchanged in the final version, I think we're mostly settled on those being sensible. Though since this is still a WIP I plan to rebase the whole branch before sending any kind of pull request. Oh, and right after sending that I realize that what's currently in my github tree doesn't have the style cleanups yet (PRIORITY fields, metadata ordering, etc.) so even the earlier ones still have some changes coming. Sorry about that. -- Joe MacDonald :wq ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: Creating meta-networking
On Fri, Jun 15, 2012 at 3:55 PM, Philip Balister phi...@balister.org wrote: On 06/15/2012 02:55 PM, Andrei Gherzan wrote: On Fri, Jun 15, 2012 at 9:08 PM, Otavio Salvador ota...@ossystems.com.brwrote: On Fri, Jun 15, 2012 at 12:42 PM, Khem Raj raj.k...@gmail.com wrote: I think creating a networking layer is fine idea, alongside meta-oe, as a separate layer in meta-openembedded repo. Reshuffling recipes from meta-oe into different layers is fine. I would like to avoid copies. I'd prefer if it used another git repository; people needing to use it shouldn't be forced to clone whole meta-oe. This would be my proposal as well. To have this as a separate layer. meta-oe already hosts several layers. It is kind of nice not to have to clone a slowly increasing number of git repos. Rather clone a few and manage the layers within them. I'm inclined to agree. I see the value in keeping this in meta-oe, but my goal with this layer is that it's as self-contained as possible. Meaning that it could be used by someone building a small, network connected system. I'm thinking there'd be value in reflecting in the layer itself by being a separate repo that can be cloned independent of the rest of meta-oe. I can definitely see both sides of the debate, though. My larger concern with the networking layer, is what layers will it depend on? Will the layer dependencies change based on the distro features? This is the hardest thing to get right with layer grouping. Agreed. The intent is for it to not depend on any layers other than oe-core. The reality will likely be something short of that ideal, but what I`ve been playing with as my proof-of-concept is nicely self-contained. You bring up a really good point, though, about layer dependencies changing based on distro features. I think that`s something that we`d have to manage carefully. -J. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Proposal: Creating meta-networking
Hi all, We've been talking about this on-and-off at Wind River for a while now, but it now seems like a reasonable time to bring a proposal to the OE community at large. We're thinking about creating a new layer to house recipes, etc. for networking packages. I'll try to address what seem to be the most immediate questions (certainly the ones we've been thinking most about any time I've discussed this with anyone): Who would use this? The intent is that this would be a layer generally useful directly on top of the Yocto Project / OE-core, but it would also draw from and compliment meta-oe. Right now I'm imagining two main groups interested in this layer. - Anyone building a small networking device (eg. a home router / bridge / switch). - Anyone wanting to add network services to their device (eg. anything that might benefit from a small ftp/tftp server) What will it include? The focus should be on networking protocols, daemons, servers and utilities. The plan is for a staged approach. Initially we're going to bring forward a number of recipes from OE Classic that aren't currently in OE-core or the meta-oe layer. The short list right now is: - aoetools - openldap - quagga - radvd - tftp-hpa - traceroute - tunctl - vblade - vlan - xl2tpd The next two stages would run concurrently, with Wind River contributing a number of recipes we intend to support for the long-term. That list is still being firmed up but will include: - freeradius - netcat - racoon2 - rdist There's about another six or seven packages on the short list right now, generally in the same vein. The other stage is migrating packages that seem like obvious fits into this layer from meta-oe. The current list under consideration would be: - atftp - bridge-utils - dnsmasq - dnsmasq-dbus - inetutils - ipsec-tools - iw - libnet - libnfnetlink - net-snmp - ntp - ntp-ssl - openvpn - ptpd - rp-pppoe - samba - strongswan - talloc - tcpdump - vsftpd That's a lot of stuff, are you going to organize it somehow? The plan is that we will have subdirectories for logical groups of recipes in much the same way meta-oe is organized today. Groupings I would propose right now would be: - recipes-daemons - containing stuff like atftp, dnsmasq, racoon2, radvd, etc. - recipes-protocols - containing stuff like quagga, openldap, xl2tpd, maybe iscsi if it appears, etc. - recipes-support - containing the rest, aoetools, bridge-utils, traceroute, etc. This is definitely the least-clear part of our plan so far and would need the most feedback and fine-tuning, I expect. Why move anything from meta-oe? Networking covers such a broad area and touches so much that it really seems like 'meta-networking' should be a home for all of the embedded networking bits. Leaving some parts in meta-oe and having the rest in meta-networking would ultimately seem a bit arbitrary. Who is 'we'? Wind River is volunteering to maintain the layer and any recipes we contribute at the outset. For recipes imported from OE Classic it'd be great if the maintainers there continued ownership, but if that's not possible, WR will also sign up for general maintenance. For recipes imported from meta-oe we would hope that the current maintainers would continue support in meta-networking once it's created. WR definitely won't be able to do this alone so we're hoping for help from everyone here. When are you doing this? I've been working on a prototype on and off for the last little bit but considering the scope and potential impact, it seemed best to open up the discussion here first and if it seemed like a generally desirable thing, we'd get some version of this up and available within a few days of consensus. So what does everyone think? Awesome idea? Terrible idea? (Hopefully) something in between? All feedback is welcome. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
