linux/poky.git/meta/recipes-devtools/mtools, branch warrior

default-distrovars: Drop DISTRO_FEATURES_LIBC

2019-02-28T13:21:54+00:00

After eglibc was merged into glibc, Kconfig support was also dropped so these libc features therefore are not effective anymore and can be removed (From OE-Core rev: c62b1cc06613a4cdddf53290e6203559f43fc62d) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

packages: respect PACKAGE_NO_GCONV

2018-12-05T22:30:19+00:00

PACKAGE_NO_GCONV is set in libc-package.bbclass if not all of 'libc-charsets libc-locale-code libc-locales' included in DISTRO_FEATURES. And then no packages glibc-gconv-* glibc-charmap-* and glibc-localedata-* is created. Update recipes and conf file which depend on these packages to check required distro features. (From OE-Core rev: 58446992de0f16a345f1f55b66d0d34d31dc341b) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie

mtools: upgrade 4.0.18 -> 4.0.19

2018-11-19T17:03:24+00:00

(From OE-Core rev: f08f09accc124162e7538595694868d307c59649) Signed-off-by: Richard Purdie

mtools: Fix build with clang

2018-09-20T12:41:32+00:00

Identify with __clang__ to undefine UNUSED (From OE-Core rev: fcede6dd3e44d9f7761d058db76dfaf103b75c6a) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

mtools: fix race issue while mtools invoked frequently

2018-08-23T06:50:00+00:00

While invoking mtools frequently, the unblocking request caused race issue. Here is an example of syslinux [snip] dd if=/dev/zero of=floppy.img bs=1024 count=144 losetup /dev/loop1 floppy.img mkdosfs /dev/loop1 syslinux -i /dev/loop1 |plain floppy: device "/proc/6351/fd/3" busy (Resource temporarily unavailable): |Cannot initialize 'S:' |Bad target s:/ldlinux.sys [snip] The idea is from: https://bugzilla.redhat.com/show_bug.cgi?id=1235016 https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-dev/bRPUCFHoBTQ/ZjB8kjjx1vUJ (From OE-Core rev: 927fad7881841a58e1d88f3a6ce070eaa66ba1a5) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

mtools: refresh patches

2018-03-07T14:34:51+00:00

The patch tool will apply patches by default with "fuzz", which is where if the hunk context isn't present but what is there is close enough, it will force the patch in. Whilst this is useful when there's just whitespace changes, when applied to source it is possible for a patch applied with fuzz to produce broken code which still compiles (see #10450). This is obviously bad. We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For that to be realistic the existing patches with fuzz need to be rebased and reviewed. (From OE-Core rev: 24674afaf90491e898bfd2c12992a1b5c5e8d2f4) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: Drop remnants of uclibc support

2017-06-22T08:16:00+00:00

uclibc support was removed a while ago and musl works much better. Start to remove the various overrides and patches related to uclibc which are no longer needed. uclibc support in a layer would still be possible. I have strong reasons to believe nobody is still using uclibc since patches are missing and I doubt the metadata even parses anymore. (From OE-Core rev: 653704e9cf325cb494eb23facca19e9f05132ffd) Signed-off-by: Richard Purdie

mtools-native: fix Upstream-Status

2017-06-14T13:53:58+00:00

This is OE-specific customisation so set the status as such. (From OE-Core rev: 059846662f1ea1c82804cfce5f91afcb2980ec8a) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

mtools-native: disable reading host configs

2017-06-14T09:18:28+00:00

Removed code that reads /etc/mtools.conf, /etc/default/mtools.conf, /etc/mtools and /etc/default/mtools to ensure that mtools output doesn't depend on the global host configs. It's still possible to use ~/.mtoolsrc config or point MTOOLSRC environment variable to any configuration file if user want to configure mtools. (From OE-Core rev: 868cb638c92f650a2f0bea9669b68c1e8aebabab) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

recipes: Move out stale GPLv2 versions to a seperate layer

2017-03-07T20:05:31+00:00

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. (From OE-Core rev: 19b7e950346fb1dde6505c45236eba6cd9b33b4b) Signed-off-by: Richard Purdie