summaryrefslogtreecommitdiffstats
path: root/meta
Commit message (Collapse)AuthorAgeFilesLines
* buildhistory: remove duplicate renamesAnuj Mittal2018-03-081-2/+11
| | | | | | | | | | | | | | | | | | In cases when a package like qemu might have files with same names in multiple directories, the rename logic might go wrong and create multiple rename pair for a single directory. Make sure that we process each rename pair once. Also, don't print FILELIST as part of PKGSIZE to ensure that it gets printed only once when reporting package changes. Fixes [YOCTO #12559] (From OE-Core rev: cff000c43d6e9a183911338951026dfbef88f838) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libcgroup: Various fixesOla x Nilsson2018-03-081-5/+6
| | | | | | | | | | | | | * Use PACKAGECONFIG for pam instead of two bb.utils.contains * Add leading whitespace to EXTRA_OEMAKE_append_libc_musl * Usr lnr in do_install_append rather than a sed generated ../-sequence. (From OE-Core rev: 02416e0d007c6c0f8c01a1e1fe0485b21087ec00) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* util-linux: Remove kill from native installMike Crowe2018-03-081-0/+2
| | | | | | | | | | | | | | | | | | util-linux installs kill as ${base_bindir}/kill. coreutils installs kill as ${bindir}/kill. If base_bindir and bindir are the same (as they are in meta-micro) then this causes a conflict for recipes that depend on util-linux-native and coreutils-native. This means that in the unlikely event that a recipe needs to run kill during the build, it will need to depend on coreutils-native. core-image-sato built successfully for me with this change. (From OE-Core rev: 5569e6ef3ef646fa498f59b8dae1d5d34d0bb9c3) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libpng: Upgrade 1.6.32 -> 1.6.34youngseok2018-03-081-4/+4
| | | | | | | | | | License-Update: License file changes are due to updates in Version and Copyright date (From OE-Core rev: cdf16bb9751603fdb0340c03ef43f193918d31df) Signed-off-by: youngseok <earwigz32@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* patch:2.7.5 -> 2.7.6Huang Qiyu2018-03-081-2/+2
| | | | | | | | | | Upgrade patch from 2.7.5 to 2.7.6. (From OE-Core rev: e5dcd58e5b2ef0b8e2bbe90e9bb1cede4e76bf75) Signed-off-by: Huang Qiyu <huangqy.fnst@cn.fujitsu.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* iptables: 1.6.1 -> 1.6.2Huang Qiyu2018-03-081-2/+2
| | | | | | | | | | Upgrade iptables from 1.6.1 to 1.6.2. (From OE-Core rev: 1bca3f22d48d138086752e61569ddc9cf8e9cf79) Signed-off-by: Huang Qiyu <huangqy.fnst@cn.fujitsu.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libdrm: 2.4.90 -> 2.4.91Otavio Salvador2018-03-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a minor release, announced in March 5th, 2018, which includes following changes: ,---- | Andrey Grodzovsky (1): | amdgpu: Fix mistake in initial hole size calculation. | | Christian König (3): | amdgpu: mostly revert "use the high VA range if possible v2" | amdgpu: add AMDGPU_VA_RANGE_HIGH | amdgpu: fix "add AMDGPU_VA_RANGE_HIGH" | | Chunming Zhou (1): | test/amdgpu: disable bo eviction test by default | | Eric Engestrom (1): | meson: add configuration summary | | Heiko Becker (1): | *-symbol-check: Don't hard-code nm executable | | Igor Gnatenko (1): | meson: do not use cairo/valgrind if disabled | | Jonathan Gray (1): | meson/configure.ac: pthread-stubs not present on OpenBSD | | Marek Olšák (2): | meson: bump the version number | RELEASING: mention meson | | Michel Dänzer (1): | tests/amdgpu: Fix misspellings of "suite" | | Rob Clark (2): | freedreno: add interface to get buffer address | bump version for release | | Rob Herring (4): | android: revert making handle magic and version members const | android: fix mis-named alloc_handle_t | android: add helper to convert buffer_handle_t to gralloc_handle_t ptr | android: fix gralloc_handle_create() problems | | Thierry Reding (2): | drm/fourcc: Fix fourcc_mod_code() definition | drm/tegra: Sanitize format modifiers `---- (From OE-Core rev: eef14164fb663d722234dbaf98611cf7ff0043d9) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libsolv: update to version 0.6.33Maxin B. John2018-03-081-1/+1
| | | | | | | | | | | | | | | 0.6.32 -> 0.6.33 * new Selection.clone() method in the bindings * new pool.parserpmrichdep() method in the bindings * fix bad assignment in solution refinement that led to a memory leak * use license tag instead of doc in the spec file [bnc#1082318] (From OE-Core rev: 57a4c4bc5fddf920af2745d7d9ff87a76bdd9807) Signed-off-by: Maxin B. John <maxin.john@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libunistring: update version to 0.9.9Maxin B. John2018-03-081-3/+3
| | | | | | | | | | | License-Update: checksum change is due to bump in copyright year to 2018. (From OE-Core rev: 1ab66475eb296dd0edab13d32eb1b47e600e38f9) Signed-off-by: Maxin B. John <maxin.john@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-07-05 03:59:23 +0000