summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* flex: create separate package for libflAndre McCurdy2018-03-081-0/+4
| | | | | | | | | | | | Target binaries linked with libfl currently generate a runtime dependency on the entire flex package (and therefore m4 and bison too). Copy Debian's approach and create a separate package for libfl. (From OE-Core rev: 1bc6ad19d56498847dc95cce0ea371ba77eff143) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gdb: Add signed-off-by tag to patchDaniel Díaz2018-03-071-0/+5
| | | | | | | | | | | | | | | A patch went in (in 4aaf747) without a proper signed-off-by because the project (in its upstream repository) does not use Git. This will take care of that before spreading the patch to other branches. (From OE-Core rev: b8ddb0c8d79b969fff40e0fdfbeeef214a338ebe) Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gtk-doc: inherit classes only if gtk-doc is enabledRoss Burton2018-03-071-12/+10
| | | | | | | | | | | | | Respect GTKDOC_ENABLED when inheriting python3native and DEPENDing on qemu-native, as they're not needed when disabled. python3native is required as otherwise the host Python is most likely used which may or may not have python3-six installed (a requirement of gtk-doc). (From OE-Core rev: b93386b22e1dc78b2917652dac4ad02745a99989) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libfm: fix dependenciesRoss Burton2018-03-072-4/+4
| | | | | | | | | | | libfm uses glib-gettextize so explicitly depend on glib-2.0-native. Instead of depending on gettext-native, inherit gettext. (From OE-Core rev: 9c367c92df0ca8afe0a75b066fdc9e21560d57ff) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* valgrind: Mask CPUID support in HWCAP on aarch64Manjukumar Matha2018-03-072-0/+37
| | | | | | | | | | | | | | | | | | | | | valgrind currently does not know anything about the CPUID flag added to the HWCAP auxv entry in kernel 4.11+ At runtime it will fails like this: ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD5380001 disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0001 ==2082== valgrind: Unrecognised instruction at address 0x4014e64. This patch is a workaround by masking all HWCAP. This patch is dervied from https://bugzilla.redhat.com/show_bug.cgi?id=1464211 (From OE-Core rev: cdeb3d530af6cec1959c986aff3d6906939c8918) Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package_manager.py: Print offending package instead of non-sense traceJason Wessel2018-03-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have a package that does not generate a manifest due to using a noexec rule, the package name should be printed so the problem can be tracked down. With out the patch you get an error that makes it look more like the package_manager is broken as shown below. oe-core/meta/lib/oe/package_manager.py', lineno: 534, function: create_packages_dir 0530: 0531: for dep in rpmdeps: 0532: c = taskdepdata[dep][0] 0533: manifest, d2 = oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d, multilibs) *** 0534: if not os.path.exists(manifest): 0535: continue 0536: with open(manifest, "r") as f: 0537: for l in f: 0538: l = l.strip() File: '/usr/lib/python3.5/genericpath.py', lineno: 19, function: exists 0015:# This is false for dangling symbolic links on systems that support them. 0016:def exists(path): 0017: """Test whether a path exists. Returns False for broken symbolic links""" 0018: try: *** 0019: os.stat(path) 0020: except OSError: 0021: return False 0022: return True 0023: Exception: TypeError: stat: can't specify None for path argument (From OE-Core rev: 21924fdba286e5962b1680601664dc0491527e25) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* usbutils: drop upstreamed patchRoss Burton2018-03-072-29/+0
| | | | | | | | | | This has been fixed upstream since 008, albeit slightly differently so the patch continued to apply. (From OE-Core rev: e65ec7a68de6a0d409a5750b2fbd7ebca9acf5a3) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libpcre: refresh patchesRoss Burton2018-03-071-12/+12
| | | | | | | | | | | | | | | | | | | 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: eb7632f593b81066da4de44bc001974d6726a118) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* vulkan: refresh patchesRoss Burton2018-03-071-5/+7
| | | | | | | | | | | | | | | | | | | 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: 453a433768bff76e4d3ad9bf40fd9d8210b0950e) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* xproto: refresh patchesRoss Burton2018-03-071-4/+6
| | | | | | | | | | | | | | | | | | | 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: a9f9ca73840d1e6911e496a32ee862a724615b50) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libxcb: refresh patchesRoss Burton2018-03-071-8/+8
| | | | | | | | | | | | | | | | | | | 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: 4a3d8806d25e146be40eaf640bc6da8bdd1b6e05) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libaio: refresh patchesRoss Burton2018-03-071-6/+6
| | | | | | | | | | | | | | | | | | | 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: e3e8c2ec038c95d8203c4886ef46aec6b0741837) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lsb: refresh patchesRoss Burton2018-03-071-10/+7
| | | | | | | | | | | | | | | | | | | 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: fc856d4539a13f1ea6bf7ce347e9ca85577ecfb8) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* screen: refresh patchesRoss Burton2018-03-071-11/+8
| | | | | | | | | | | | | | | | | | | 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: e0a363d3374738d1bc8a0889dade83d2c35ef964) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sysstat: refresh patchesRoss Burton2018-03-071-16/+13
| | | | | | | | | | | | | | | | | | | 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: 4a0c9bb514ff3d6966f1da480cd48c076403f58d) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* unzip: refresh patchesRoss Burton2018-03-071-5/+7
| | | | | | | | | | | | | | | | | | | 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: b45ce6dbbd459ecc96eae76b5695927dbda1dbb4) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* watchdog: refresh patchesRoss Burton2018-03-071-6/+8
| | | | | | | | | | | | | | | | | | | 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: 7c8e3b9bd26b35654f3bd24bbb8d86b8c6e34a67) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sysklogd: refresh patchesRoss Burton2018-03-071-5/+5
| | | | | | | | | | | | | | | | | | | 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: a441306ce9de4ca1cc07dfb8aa330e8d6d67e651) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* btrfs-tools: refresh patchesRoss Burton2018-03-071-10/+7
| | | | | | | | | | | | | | | | | | | 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: d7696f5f89ac94b5cae13c5e07d6d4c7133c3ed9) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* elfutils: refresh patchesRoss Burton2018-03-071-23/+23
| | | | | | | | | | | | | | | | | | | 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: 2526fcfac8e360d5d27f5ebe26608df470b3b84b) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ccache: refresh patchesRoss Burton2018-03-071-8/+5
| | | | | | | | | | | | | | | | | | | 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: 4bfeaf65d3f48174d27af09ac4279c1c91bf4104) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* flex: refresh patchesRoss Burton2018-03-071-5/+5
| | | | | | | | | | | | | | | | | | | 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: a17860995731ab1e327bf88953fa3ed4641b584e) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* mtools: refresh patchesRoss Burton2018-03-071-8/+12
| | | | | | | | | | | | | | | | | | | 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 <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* squashfs-tools: refresh patchesRoss Burton2018-03-071-4/+4
| | | | | | | | | | | | | | | | | | | 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: 319de7e44f9fc853b53f2628abaf640d8241f615) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* iproute2: refresh patchesRoss Burton2018-03-071-5/+5
| | | | | | | | | | | | | | | | | | | 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: f369e9dce9dc2bcd89b2492545112da78aca690e) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* neard: refresh patchesRoss Burton2018-03-071-9/+6
| | | | | | | | | | | | | | | | | | | 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: 1aa6e504b21d1e7290d81af8fc7863053269a196) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nfs-utils: refresh patchesRoss Burton2018-03-073-25/+20
| | | | | | | | | | | | | | | | | | | 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: 0902bef12c815f302f04fa28606ece4b014260d6) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* dropbear: refresh patchesRoss Burton2018-03-071-10/+7
| | | | | | | | | | | | | | | | | | | 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: 18300f8faa5050178efcd22f2db843f9b3f3bb0f) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kbd: refresh patchesRoss Burton2018-03-071-13/+13
| | | | | | | | | | | | | | | | | | | 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: b1fa565ffa02796eaa55f5ac6700f1a932d62957) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libxml: refresh patchesRoss Burton2018-03-071-23/+20
| | | | | | | | | | | | | | | | | | | 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: d71d6854fadc96fc3c75617af3beba02952fdef6) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ovmf: refresh patchesRoss Burton2018-03-071-1/+1
| | | | | | | | | | | | | | | | | | | 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: 68d567bd64debc3dfb37df3c814287549da56a3b) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gtk+: refresh patchesRoss Burton2018-03-071-7/+8
| | | | | | | | | | | | | | | | | | | 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: 7ac8688c9fce49a005cbe9afe028453f6fea4e79) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gobject-introspection: refresh patchesRoss Burton2018-03-071-22/+19
| | | | | | | | | | | | | | | | | | | 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: 5a72d04296cc7aea5893cba29c6da1cf1469911b) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* dbus-glib: refresh patchesRoss Burton2018-03-071-4/+6
| | | | | | | | | | | | | | | | | | | 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: 9f15e5256eb79c8cfc4b3a4e11617eeb5f38edea) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* dbus: remove upstreamed patchRoss Burton2018-03-072-39/+0
| | | | | | | (From OE-Core rev: 887afb4cf326cf3ad37761343db9e898dbcad2f5) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* util-linux: add taskset to alternatives listLars Persson2018-03-061-1/+1
| | | | | | | | | | The taskset command is provided by both busybox and util-linux. (From OE-Core rev: 83a36fb20f8cb0e45295cb71b76e74af3986f993) Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gdb: fix header ordering for TRAP_HWBKPTDaniel Díaz2018-03-062-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | This error can appear in gdb/nat/linux-ptrace.c because of the order in which some headers are processed: | In file included from ../../gdb-7.11.1/gdb/nat/linux-ptrace.c:20:0: | ../../gdb-7.11.1/gdb/nat/linux-ptrace.h:175:22: error: expected identifier before numeric constant | # define TRAP_HWBKPT 4 | ^ | Makefile:2357: recipe for target 'linux-ptrace.o' failed | make[2]: *** [linux-ptrace.o] Error 1 | make[2]: *** Waiting for unfinished jobs.... | make[2]: Leaving directory '/oe/build/tmp-rpb-glibc/work/aarch64-linaro-linux/gdb/7.11.1-r0/build-aarch64-linaro-linux/gdb' | Makefile:8822: recipe for target 'all-gdb' failed | make[1]: *** [all-gdb] Error 2 | make[1]: Leaving directory '/oe/build/tmp-rpb-glibc/work/aarch64-linaro-linux/gdb/7.11.1-r0/build-aarch64-linaro-linux' | Makefile:846: recipe for target 'all' failed | make: *** [all] Error 2 A patch from GDB's current master solves the issue. (From OE-Core rev: 4aaf747099714ec11158571527396ed9e818729e) Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitionsFathi Boudra2018-03-062-0/+70
| | | | | | | | | | | | Patch submitted upstream, pending to be merged: https://sourceware.org/bugzilla/show_bug.cgi?id=21286 (From OE-Core rev: 11ebb5054e5ec1171ade90249e3a30ac8174a35a) Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org> Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* e2fsprogs_1.43.8.bb: improve reproducibilityJuro Bystricky2018-03-061-0/+3
| | | | | | | | | | | | | | | | | | | | Various builds of e2fsprogs 1.43.7 package locales which may or may not have POT-Creation-Date removed. There is no obvious pattern, it affects different locales each time, the build being non-deterministic. The root cause was tracked to non-deterministic time stamps (as GIT does not preserve file mktime), so some "make" rules sometimes fired, sometimes did not. The remedy is to explicitly "touch" files that cause non-deterministic build. [YOCTO #12516] (From OE-Core rev: b32f3b655189fd89dcfce084b6fda0d379300f75) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kmscube: Add patch for missing GBM functionDaniel Díaz2018-03-062-1/+118
| | | | | | | | | | | | | Some implementations of GBM, like the one included with libMali, do not have gbm_bo_map() nor gbm_bo_unmap(). This patch enables kmscube to work with those implementations even if it doesn't work as great. (From OE-Core rev: 54615151da5e8c77c803947ce5760d06c1691c58) Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meson.bbclass: fix to build for more projectsChen Qi2018-03-061-12/+8
| | | | | | | | | | | | | | | | | We should use the value of CC for the c compiler setting in cross compilation configuration file for meson. For example, if we only use ${HOST_PREFIX}gcc instead of ${CC}, we would meet the following do_compile failure for systemd. cc1: fatal error: linux/capability.h: No such file or directory Do the same change for LD, AR, NM, STRIP and READELF. (From OE-Core rev: 177bd96a531fcc85e62baff04aba327e2bccee07) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libconvert-asn1-perl: inherit ptest-perlTim Orling2018-03-061-1/+1
| | | | | | | | | | * Enable ptest using new ptest-perl.bbclass (From OE-Core rev: 04f49bc0f9c56ef9b6970891058c200968c5ded9) Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* dtc: add rdepends_${PN}-misc = diffutilsIoan-Adrian Ratiu2018-03-061-1/+1
| | | | | | | | | | Needed by dtdiff which calls `diff` to display its result. (From OE-Core rev: ace8b318038389c07694ae5234811ce92982ddc8) Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* diffutils: allow native & nativesdk buildsIoan-Adrian Ratiu2018-03-061-0/+1
| | | | | | | | | | | | | Required by the new dtc rdepends to avoid errors like this: ERROR: Required build target 'ionel-rpi-image' has no buildable providers. Missing or unbuildable dependency chain was: ['ionel-rpi-image', 'nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-dtc', 'nativesdk-diffutils'] (From OE-Core rev: dc3829f31bcc7522e8eb457623a74655a738c0d9) Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* godep.bbclass: Add helper class to enable go-dep toolKhem Raj2018-03-061-0/+8
| | | | | | | | | | | | Many go packages can take advantage of dep tool since they manage their own dependencies, this class helps in using go dep tool for such packages (From OE-Core rev: 9bea8313b0dd5a6af08d15ee8634fe2ef9ee0f75) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tcmode-default.inc: add settings for goMatt Madison2018-03-061-0/+10
| | | | | | | | | | | to allow GOVERSION to be set for using an older go toolchain. (From OE-Core rev: 10193150381b1088a5de627aed0ad1d052a3955d) Signed-off-by: Matt Madison <matt@madison.systems> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go-runtime: remove unneeded nativesdk override, rename variableMatt Madison2018-03-061-4/+2
| | | | | | | | | | | | since GO_LDFLAGS is also used by the dist tool, and it's confusing to use a variable with the same name (but not exported, so unused by make.bash/dist). (From OE-Core rev: b5ee166307ea095c77237e06744dff6810800bad) Signed-off-by: Matt Madison <matt@madison.systems> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* packagegroup-go-sdk-target: add go-runtime-staticdevMatt Madison2018-03-061-0/+1
| | | | | | | | | | | to allow go programs to be linked either statically or dynamically when cross-compiling with the SDK. (From OE-Core rev: d2201447692940a5b21977fc28e6b944e3a53d3c) Signed-off-by: Matt Madison <matt@madison.systems> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go: disable PIE CFLAGS for nativesdk and cross-canadian buildsMatt Madison2018-03-063-7/+6
| | | | | | | | | | | | The statically-linked Go code in the toolchain is not compatible with PIE, so disable its use in the C compiler during the toolchain build. (From OE-Core rev: cc7b179917c715b29822200fe91ecd755a5750e6) Signed-off-by: Matt Madison <matt@madison.systems> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go.bbclass, goarch.bbclass: update SECURITY_CFLAGSMatt Madison2018-03-062-3/+2
| | | | | | | | | | | | With go1.10 the NOPIE flags are only required for MIPS target builds, and are now incompatible for the other architectures. (From OE-Core rev: f2ff90eb7d27a2f69f5948fa8c301de30f5c8132) Signed-off-by: Matt Madison <matt@madison.systems> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-07-01 19:06:49 +0000