openembedded-core.git/meta/recipes-extended/findutils, branch pyro Mirror of openembedded-core recipes: Move out stale GPLv2 versions to a seperate layer 2017-03-07T20:04:58+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2017-03-02T12:04:08+00:00 19b7e950346fb1dde6505c45236eba6cd9b33b4b These are recipes where the upstream has moved to GPLv3 and these old versions are the last ones under the GPLv2 license. There are several reasons for making this move. There is a different quality of service with these recipes in that they don't get security fixes and upstream no longer care about them, in fact they're actively hostile against people using old versions. The recipes tend to need a different kind of maintenance to work with changes in the wider ecosystem and there needs to be isolation between changes made in the v3 versions and those in the v2 versions. There are probably better ways to handle a "non-GPLv3" system but right now having these in OE-Core makes them look like a first class citizen when I believe they have potential for a variety of undesireable issues. Moving them into a separate layer makes their different needs clearer, it also makes it clear how many of these there are. Some are probably not needed (e.g. mc), I also wonder whether some are useful (e.g. gmp) since most things that use them are GPLv3 only already. Someone could now more clearly see how to streamline the list of recipes here. I'm proposing we mmove to this separate layer for 2.3 with its future maintinership and testing to be determined in 2.4 and beyond. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
These are recipes where the upstream has moved to GPLv3 and these old
versions are the last ones under the GPLv2 license.

There are several reasons for making this move. There is a different
quality of service with these recipes in that they don't get security
fixes and upstream no longer care about them, in fact they're actively
hostile against people using old versions. The recipes tend to need a
different kind of maintenance to work with changes in the wider ecosystem
and there needs to be isolation between changes made in the v3 versions
and those in the v2 versions.

There are probably better ways to handle a "non-GPLv3" system but right
now having these in OE-Core makes them look like a first class citizen
when I believe they have potential for a variety of undesireable issues.

Moving them into a separate layer makes their different needs clearer, it
also makes it clear how many of these there are. Some are probably not
needed (e.g. mc), I also wonder whether some are useful (e.g. gmp)
since most things that use them are GPLv3 only already. Someone could
now more clearly see how to streamline the list of recipes here.

I'm proposing we mmove to this separate layer for 2.3 with its future
maintinership and testing to be determined in 2.4 and beyond.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta: update patch metadata 2016-07-08T08:55:40+00:00 Ross Burton ross.burton@intel.com 2016-06-27T19:59:19+00:00 606a43dc38a00cc243f933722db657aea4129f8e Enforce the correct tag names across all of oe-core for consistency. Signed-off-by: Ross Burton <ross.burton@intel.com> 
Enforce the correct tag names across all of oe-core for consistency.

Signed-off-by: Ross Burton <ross.burton@intel.com>
findutils: upgrade to 4.6.0 2016-02-26T17:15:07+00:00 Ross Burton ross.burton@intel.com 2016-02-22T16:24:21+00:00 0b3810bfb4c25d0a023045eab429c9401293375a Inherit upstream-version-is-even as minor-odd releases (such as 4.5.x) are development snapshots. Change the SRC_URI back to using GNU_MIRROR now we're not using a development release but a stable tarball. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Inherit upstream-version-is-even as minor-odd releases (such as 4.5.x) are
development snapshots.

Change the SRC_URI back to using GNU_MIRROR now we're not using a development
release but a stable tarball.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
findutils: upgrade to 4.5.19 2016-02-18T22:55:10+00:00 Chen Qi Qi.Chen@windriver.com 2016-02-18T05:29:02+00:00 4ec00dbb121cb06d365a6536229fc5819d671228 Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta: Fix Upstream-Status statements 2015-09-12T21:59:01+00:00 Ross Burton ross.burton@intel.com 2015-09-10T18:59:47+00:00 bd220fe6ce8c3a0805f13a14706d3130ea872604 Fix a variety of problems such as typos, bad punctuations, or incorrect Upstream-Status values. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Fix a variety of problems such as typos, bad punctuations, or incorrect
Upstream-Status values.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
recipes: Fix charset.alias for musl 2015-04-21T06:19:05+00:00 Khem Raj raj.khem@gmail.com 2015-04-16T02:00:25+00:00 fbe6d2c12aa9f7956bc87efeb68cb64b26b60c7a This is same gnulib fix replicated across needed recipes Change-Id: I756713407111a726eae98e26c9c1ff64981371c0 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
This is same gnulib fix replicated across needed recipes

Change-Id: I756713407111a726eae98e26c9c1ff64981371c0
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
findutils 4.2.31: fix SRC_URI 2015-02-07T18:52:46+00:00 Robert Yang liezhi.yang@windriver.com 2015-01-27T07:38:23+00:00 243e6d1380d376d1669c0ffa477027c1bec7f74a The findutils_4.2.31.bb can't use the SRC_URI in findutils.inc (but findutils_4.5.14.bb can use it), use the right SRC_URI to fix it. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> 
The findutils_4.2.31.bb can't use the SRC_URI in findutils.inc (but
findutils_4.5.14.bb can use it), use the right SRC_URI to fix it.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
findutils: Upgrade to 4.5.14 2014-11-06T16:41:36+00:00 Saul Wold sgw@linux.intel.com 2014-09-04T20:41:09+00:00 8071b8d1ccc5e8a6b24ccf13b185f5cda6ce890e Move findutils-4.4.2 directory to more generic findutils Removed backported patches Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Move findutils-4.4.2 directory to more generic findutils
Removed backported patches

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Add texinfo.bbclass; recipes that use texinfo utils at build-time inherit it. 2014-05-01T22:17:50+00:00 Max Eliaser max.eliaser@intel.com 2014-05-01T20:00:28+00:00 e6fb2f9afe2ba6b676c46d1eb297ca9cc532d405 The class itself currently does nothing. The idea is to mark all recipes that make use of the texinfo utilities. In the future, this class could be used to suppress the generation/formatting of documentation for performance, explicitly track dependencies on these utilities, and eliminate Yocto's current dependency on the host system's texinfo utilities. Signed-off-by: Max Eliaser <max.eliaser@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The class itself currently does nothing. The idea is to mark all recipes that
make use of the texinfo utilities. In the future, this class could be used to
suppress the generation/formatting of documentation for performance,
explicitly track dependencies on these utilities, and eliminate Yocto's
current dependency on the host system's texinfo utilities.

Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Globally replace 'base_contains' calls with 'bb.utils.contains' 2014-04-25T16:10:58+00:00 Otavio Salvador otavio@ossystems.com.br 2014-04-24T18:59:20+00:00 d83b16dbf0862be387f84228710cb165c6d2b03b The base_contains is kept as a compatibility method and we ought to not use it in OE-Core so we can remove it from base metadata in future. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The base_contains is kept as a compatibility method and we ought to
not use it in OE-Core so we can remove it from base metadata in
future.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>