Identify with __clang__ to undefine UNUSED Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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. Signed-off-by: Ross Burton <ross.burton@intel.com>
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is OE-specific customisation so set the status as such. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> 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>
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. Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>