openembedded-core.git/meta/recipes-core/coreutils, branch master-next 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>
recipes: Make use of the new bb.utils.filter() function 2017-03-01T11:17:22+00:00 Peter Kjellerstedt peter.kjellerstedt@axis.com 2017-02-27T13:02:50+00:00 0a1427bf9aeeda6bee2cc0af8da4ea5fd90aef6f Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
coreutils: upgrade to 8.26 2017-01-16T18:01:50+00:00 Chen Qi Qi.Chen@windriver.com 2016-12-26T08:10:35+00:00 07fabf6aa622c4b9ed6f0dc97a6acf5df5a6f058 Add 0001-local.mk-fix-cross-compiling-problem.patch to fix the following cross compiling problem. | Makefile:3418: *** Recursive variable 'INSTALL' references itself (eventually). Stop. Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Add 0001-local.mk-fix-cross-compiling-problem.patch to fix the following
cross compiling problem.

| Makefile:3418: *** Recursive variable 'INSTALL' references itself (eventually).  Stop.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta: remove True option to getVar calls 2016-12-16T08:30:03+00:00 Joshua Lock joshua.g.lock@intel.com 2016-12-14T21:13:04+00:00 7c552996597faaee2fbee185b250c0ee30ea3b5f getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
coreutils: enable xattr for native 2016-09-06T09:23:59+00:00 Robert Yang liezhi.yang@windriver.com 2016-09-05T07:30:43+00:00 18ff7efef77120538372a81b2cc8e8479742b064 The lib/oe/path.py requires xattr, fixed: Subprocess output: cp: cannot preserve extended attributes, cp is built without xattr support Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The lib/oe/path.py requires xattr, fixed:
Subprocess output:
cp: cannot preserve extended attributes, cp is built without xattr support

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
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>
coreutils: revert upstream commit causing havoc with ls output 2016-05-30T08:30:31+00:00 Paul Gortmaker paul.gortmaker@windriver.com 2016-05-25T14:10:08+00:00 51ba2908d66228ce4d6bf24c3a8538d9a37268ff A recent commit causes ls to have the following behaviour: meta-overc:~$ mkdir abc meta-overc:~$ cd abc meta-overc:~/abc$ touch aaaa bbbb 'filename with spaces' meta-overc:~/abc$ ls aaaa bbbb 'filename with spaces' meta-overc:~/abc$ Note the appearance of quotation marks. This new behaviour was introduced as "opt-out" and not "opt-in", and further, the opt-out suggestion causes other breakage. More details can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813164 Several large distros are reverting the change, for practical considerations as per what can be seen above for Debian. Here we do the same; I've marked the patch as upstream submitted since there have been enough people vocally annoyed by this change that it seems implausible that the coreutils team is unaware of it. Hopefully this change here is just temporary and the coreutils team will put the default back to the old way it was based on feedback similar to what is recorded in the above Debian bug. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
A recent commit causes ls to have the following behaviour:

   meta-overc:~$ mkdir abc
   meta-overc:~$ cd abc
   meta-overc:~/abc$ touch  aaaa bbbb 'filename with spaces'
   meta-overc:~/abc$ ls
   aaaa  bbbb  'filename with spaces'
   meta-overc:~/abc$

Note the appearance of quotation marks.  This new behaviour was
introduced as "opt-out" and not "opt-in", and further, the opt-out
suggestion causes other breakage.  More details can be found here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813164

Several large distros are reverting the change, for practical
considerations as per what can be seen above for Debian.

Here we do the same; I've marked the patch as upstream submitted
since there have been enough people vocally annoyed by this change
that it seems implausible that the coreutils team is unaware of it.

Hopefully this change here is just temporary and the coreutils team
will put the default back to the old way it was based on feedback
similar to what is recorded in the above Debian bug.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
coreutils: Fix rootfs creation errors 2016-05-22T15:09:22+00:00 Dai Caiyun daicy.fnst@cn.fujitsu.com 2016-02-27T23:05:53+00:00 6cc65261169c9d4da61a85596e3f7864699d50d0 1) error: file /usr/share/man/man1/su.1 from install of shadow-doc-4.2.1 conflicts with file from package coreutils-doc-6.9-r5 2) error: file /usr/share/man/man1/hostname.1 from install of net-tools-doc conflicts with file from package coreutils-doc-6.9-r5 3) error: file /usr/share/man/man1/hostname.1 from install of net-tools-doc conflicts with file from package coreutils-doc-8.25 Signed-off-by: Dai Caiyun <daicy.fnst@cn.fujitsu.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
    1) error: file /usr/share/man/man1/su.1 from install of shadow-doc-4.2.1
       conflicts with file from package coreutils-doc-6.9-r5
    2) error: file /usr/share/man/man1/hostname.1 from install of net-tools-doc
       conflicts with file from package coreutils-doc-6.9-r5
    3) error: file /usr/share/man/man1/hostname.1 from install of net-tools-doc
       conflicts with file from package coreutils-doc-8.25

Signed-off-by: Dai Caiyun <daicy.fnst@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
coreutils: fix for native and nativesdk 2016-05-17T13:42:17+00:00 Dengke Du dengke.du@windriver.com 2016-04-26T05:59:19+00:00 1b5b831d1bbb92760ce01b38347cf0bcaa1bb59f The do_install_append is used for moving/renaming for ALTERNATIVE, but it breaks native, for example there is no ln, but ln.coreutils, that makes coreutils-native don't work. This patch fixes the problem. Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The do_install_append is used for moving/renaming for ALTERNATIVE, but
it breaks native, for example there is no ln, but ln.coreutils, that
makes coreutils-native don't work. This patch fixes the problem.

Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk-coreutils: a lot of warnings fixed 2016-03-23T21:49:58+00:00 Dengke Du dengke.du@windriver.com 2016-03-16T02:49:13+00:00 37039da6a09d7781beb93892932488940786b41f When we create nativesdk-coreutils, a lot of warnings appear,it show many files can't find. Because in the coreutils recipe, it didn't contain the do_install for the nativesdk, so when the alternative system check the files in the following process, it can't find the files. So we should add the do_install for the nativesdk, change the function do_install_append_class-target() to do_install_append() in the file: meta/recipes-core/coreutils/coreutils_8.25.bb in this way, the alternative system can find the files, the warnings disappear. Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
When we create nativesdk-coreutils, a lot of warnings appear,it
show many files can't find. Because in the coreutils recipe, it
didn't contain the do_install for the nativesdk, so when the
alternative system check the files in the following process, it
can't find the files. So we should add the do_install for the
nativesdk, change the function do_install_append_class-target() to
do_install_append() in the file:
	meta/recipes-core/coreutils/coreutils_8.25.bb
in this way, the alternative system can find the files, the warnings
disappear.

Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>