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

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

mtools: Patch out a useless sanity check

2016-06-03T12:13:30+00:00

The sanity check is ensuring that filesystem size is divisible by sectors-per-track. That seems to be just an optimization for ancient media, and quite tricky to accomplish as different dosfstools versions produce filesystems with different sectors-per-track. Continue processing even if filesystem size is not divisible by sectors-per-track. (From OE-Core rev: 970cdbe26d9b6d0bd93325c8e734416e679010df) Signed-off-by: Jussi Kukkonen Signed-off-by: Richard Purdie

mtools: Drop GCONV_PATH manipulation

2016-03-07T12:41:38+00:00

Now that nativesdk-glibc handles GCONV_PATH itself we don't need to do this here. This unbreaks mtools for the native case without uninative since the existing patch wasn't nativesdk specific. (From OE-Core rev: 331ad5c5f80044a5e82abca0e87a85b162126411) Signed-off-by: Richard Purdie

mtools: keep v3.9.9 recipe in sync with the v4.0.18 version

2016-01-26T22:32:00+00:00

Changes are mostly cosmetic, but also include one important fix to support builds using musl libc. http://git.openembedded.org/openembedded-core/commit/?id=9f5eb272784d3be17e7fe8e7cab511bd4086ba1e (From OE-Core rev: c03cdb8a9f1929d9ef03c55b8b18d60ff69db447) Signed-off-by: Andre McCurdy Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

mtools: Fix build with uclibc

2016-01-24T09:40:27+00:00

unlike glibc, uclibc does not have internal APIs implemented for libiconv, so it needs to depend upon libiconv (From OE-Core rev: 04a609a70f6c464ffd32a4a073c3801d9446622b) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

mtools: Use proper glibc override to add glibc packages to recommendations

2015-12-12T23:42:55+00:00

Helps building mtools on musl (From OE-Core rev: 9f5eb272784d3be17e7fe8e7cab511bd4086ba1e) Signed-off-by: Khem Raj Signed-off-by: Ross Burton Signed-off-by: Richard Purdie