[OE-core] [PATCH] glib-2.0: fix for non-utf8 encoded files

From: Jackie Huang Some source files aren't valid utf-8 containing for example iso8859-1 accented characters in author's names. Replace invalid data with a replacement '?' character and print a warning to keep things working. Signed-off-by: Jackie Huang

[OE-core] ✗ patchtest: failure for devtool improvements

== Series Details == Series: devtool improvements Revision: 1 URL : https://patchwork.openembedded.org/series/10071/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed

[OE-core] [PATCH 12/12] lib/oe/recipeutils: add .txz extension to archive list

Prompted by bitbake commit 2ba8a6b25ccc12e7b543e8450121e5311c7a701d, add .txz to the list of archives used within get_recipe_local_files() here as well. Signed-off-by: Paul Eggleton --- meta/lib/oe/recipeutils.py | 2 +- 1 file changed, 1 insertion(+), 1

[OE-core] [PATCH 07/12] lib/oe/recipeutils: allow patch_recipe_file() to be re-called

If patch_recipe_file() is called with output redirection on the same file twice in succession, then we don't want to wipe out the changes the first call made so we need to be reading in the redirected file if it exists instead of the original one. This is important to enable devtool finish to

[OE-core] [PATCH 11/12] oe-selftest: devtool: add test for multiple source trees

Add two synthetic tests for devtool modify + devtool finish: first with multiple source trees side-by-side, and second to test with one as a subdirectory of the main source tree. These also test devtool finish's recently added dry-run option and that detects and errors on uncommitted changes

[OE-core] [PATCH 08/12] devtool: support extracting multiple source trees

If you have multiple source trees being extracted to the work directory within a recipe (e.g. you have two tarballs referred to in SRC_URI) and one isn't being extracted into the other, then devtool failed to extract all the sources because it only took the source tree that S pointed into. To fix

[OE-core] [PATCH 09/12] devtool: fix handling of linux-yocto after multisrc changes

devtool now handles multiple source trees for any recipe that includes them in SRC_URI, extracting them all side-by-side so that you can make changes in any of them. As a result, when running devtool modify on a linux-yocto kernel recipe under the source path you will get a "source" subdirectory

[OE-core] [PATCH 10/12] oe-selftest: devtool: fix kernel test for multisrc changes

Fix the oe-selftest test to understand that the source will be found in a "source" subdirectory if the kernel inherits linux-yocto since there are multiple trees extracted. Signed-off-by: Paul Eggleton --- meta/lib/oeqa/selftest/cases/devtool.py | 13 +

[OE-core] [PATCH 01/12] devtool: refactor return for _extract_source()

Use a namedtuple to return information to the caller, since I've been expanding that information we should avoid having to change all of the calling code each time. Additionally, it turned out that a bunch of the callers were checking for None being returned in the initial_rev value, but that's

[OE-core] [PATCH 04/12] devtool: deploy-target: don't specify ssh/scp port unless user does

If the user doesn't specify a port then we should avoid specifying one on the ssh/scp command line in case the user has configured one for the host they are connecting to, which was being overridden unnecessarily. Fixes [YOCTO #12381]. Signed-off-by: Paul Eggleton

[OE-core] [PATCH 05/12] devtool: extract: fix usage with kern-tools-native

The kern-tools-native recipe as it currently stands is unusual in that it fetches source from a repository but sets S = "${WORKDIR}" which causes some problems. First you get a failure because we're calling "git commit" unconditionally even if there are no local files, and there aren't any in this

[OE-core] [PATCH 00/12] devtool improvements

A set of improvements for devtool, mostly aimed at improving the handling of recipes that fetch multiple source trees (i.e. have multiple tarballs or repositories in SRC_URI), with a couple of other fixes thrown in. The following changes since commit a7cd9d1183be603777fc9c8c448281fe01224f7b:

[OE-core] [PATCH 02/12] devtool: reset: delete bbappend file if _check_preserve() doesn't

If the .devtool_md5 file doesn't contain a reference to the bbappend file (e.g. because devtool was interrupted before it could write that out) then _check_preserve() won't delete it, so we need to delete it separately because otherwise the recipe won't actually be reset. Signed-off-by: Paul

[OE-core] [PATCH 03/12] devtool: finish: fix erroneously creating bbappend for relative paths

After OE-Core rev 5e3fe00a0233d563781849a44f53885b4e924a9c we call os.path.abspath() on the original layer path, but we later compare that to the destination layer path. If that layer path isn't absolute but is effectively the same path, it should be writing to the original recipe but because we

[OE-core] [PATCH 1/2] classes/patch: remove unused variable

Signed-off-by: Paul Eggleton --- meta/classes/patch.bbclass | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass index 8f35cb4..930ee33 100644 --- a/meta/classes/patch.bbclass +++ b/meta/classes/patch.bbclass @@

[OE-core] [PATCH 2/2] classes/patch: when PATCHTOOL = "git" double-check the repository

If a bug is present or the user has set PATCHTOOL = "git" on a source tree that isn't git, if we try to perform git operations (such as committing or changing branches) when extracting source, then we might in fact be running those operations on the metadata repository if the build directory is

[OE-core] [PATCH 0/2] patch class fixes

A couple of fixes for the patch class. The following changes since commit a7cd9d1183be603777fc9c8c448281fe01224f7b: lib/oe/utils: remove param_bool() (2017-12-02 11:24:38 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/patch-fixes

[OE-core] [PATCH V2] icu: fix libicudata corruption on big endian system

ICU library libicudata is created with a wrong endianness if the host and target have different endianness. (e.g. build ICU for qemuppc on x86-64 host) See upstream bug report: http://bugs.icu-project.org/trac/ticket/11758 The discussion in oe-core mailing list:

[OE-core] [PATCH V2] icu: fix libicudata corruption on big endian system

Changes from V1: fix hardcored file version Yi Zhao (1): icu: fix libicudata corruption on big endian system meta/recipes-support/icu/icu.inc | 13 + 1 file changed, 13 insertions(+) -- 2.7.4 -- ___ Openembedded-core mailing list

[OE-core] [PATCH 3/3][RFC] oeqa/qemu: remove elf image type

Since we are depercating the ELF image type, we should not test it here either. Signed-off-by: Saul Wold --- meta/lib/oeqa/core/target/qemu.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oeqa/core/target/qemu.py

[OE-core] [PATCH 2/3][RFC] mkelfimage: Remove un-needed recipe

As we are removing the ELF image type, we can now removed this older mkelfimage recipe also, we reach back 3+ years in the coreboot git repo to retrieve the source. This tool needs updating everything we change binutils, which would normally be done by the upstream, but that is now gone. [YOCTO

[OE-core] [PATCH 1/3][RFC] image_types: Remove ELF type

As warned in a proir commit, it's time to remove the elf image type, it is not long used anywhere (that I am aware of) and the mkelfimage tool has been removed from the upstream coreboot code base. Signed-off-by: Saul Wold --- meta/classes/image_types.bbclass | 13

[OE-core] [PATCH 0/3][RFC] Remove ELF Image Type

The ELF Image type is not currently used any more by the coreboot project which was the original creator of this image type along with the mkelfimage tool. The tool was removed from the coreboot repo back in 2014 and has no updates. Each time binutils changes, the mkelfimage tool breaks and

[OE-core] [PATCH v2] acpica: drop NATIVE_INSTALL_WORKS and fix RCONFLICTS

* NATIVE_INSTALL_WORKS hasn't been used in a very long time, so there's no need to be setting it here. * RCONFLIGHTS was clearly a typo. Signed-off-by: Paul Eggleton --- meta/recipes-extended/acpica/acpica_20170303.bb | 3 +-- 1 file changed, 1 insertion(+), 2

[OE-core] [PATCH] acpica: drop NATIVE_INSTALL_WORKS

This variable hasn't been used in a very long time, so there's no need to be setting it here. Signed-off-by: Paul Eggleton --- meta/recipes-extended/acpica/acpica_20170303.bb | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [OE-core] ✗ patchtest: failure for initramfs-framework installation improvements (rev4)

On Mon, Dec 04, 2017 at 09:23:59AM -0600, Leonardo Sandoval wrote: > On Fri, 1 Dec 2017 23:07:48 +0100 > Martin Jansa wrote: > > > Is it trying to apply whole series (including the 2 patches which were > > already merged to master and actually introduced the issue I was

Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

On 12/4/17 4:00 AM, Olof Johansson wrote: > On 17-12-01 22:13 +0100, Olof Johansson wrote: >> On 17-12-01 11:43 -0600, Mark Hatle wrote: >>> The original implementation did not include the ',' options because >>> different >>> versions of file (as well as different architectures) would return

[OE-core] [PATCH] mesa: Upgrade to 17.2.6 stable release

This upgrades the recipe to 17.2.6 bugfix release. The changes can be seen at: https://www.mesa3d.org/relnotes/17.2.6.html Signed-off-by: Otavio Salvador --- meta/recipes-graphics/mesa/{mesa-gl_17.2.5.bb => mesa-gl_17.2.6.bb} | 0

[OE-core] [PATCH v2] perl: native modules will not trigger build perl for target.

Currently building perl-native modules triggers build perl for target due to PACKAGES_DYNAMIC regex. This commit will cause, that perl native modules will trigger perl-native build. Signed-off-by: Krzysztof Taborski ---

[OE-core] [PATCH] perl: native modules will not trigger build perl for target.

Currently building perl-native modules triggers build perl for target due to PACKAGES_DYNAMIC regex. This commits fix will cause, that perl native modules will trigger perl-native build. Signed-off-by: Krzysztof Taborski ---

[OE-core] ✗ patchtest: failure for Perl native modules will not trigger build perl for target.

== Series Details == Series: Perl native modules will not trigger build perl for target. Revision: 1 URL : https://patchwork.openembedded.org/series/10059/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several

[OE-core] [PATCH] Perl native modules will not trigger build perl for target.

Currently building perl-native modules triggers build perl for target due to PACKAGES_DYNAMIC regex. This commits fix will cause, that perl native modules will trigger perl-native build. --- meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++ meta/recipes-devtools/perl/perl_5.24.1.bb

Re: [OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

On 2017-12-04 12:39 PM, Richard Purdie wrote: On Mon, 2017-12-04 at 12:24 -0500, Bruce Ashfield wrote: On 2017-12-04 11:38 AM, Khem Raj wrote: On Mon, Dec 4, 2017 at 7:39 AM, Bruce Ashfield wrote: Outside of the normal patch refreshes and boot issues, there

Re: [OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

On 2017-12-04 12:39 PM, Richard Purdie wrote: On Mon, 2017-12-04 at 12:24 -0500, Bruce Ashfield wrote: On 2017-12-04 11:38 AM, Khem Raj wrote: On Mon, Dec 4, 2017 at 7:39 AM, Bruce Ashfield wrote: Outside of the normal patch refreshes and boot issues, there

Re: [OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

On Mon, 2017-12-04 at 12:24 -0500, Bruce Ashfield wrote: > On 2017-12-04 11:38 AM, Khem Raj wrote: > > > > On Mon, Dec 4, 2017 at 7:39 AM, Bruce Ashfield > > wrote: > > > > > > Outside of the normal patch refreshes and boot issues, there are > > > new > > > build

Re: [OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

On 2017-12-04 11:38 AM, Khem Raj wrote: On Mon, Dec 4, 2017 at 7:39 AM, Bruce Ashfield wrote: Outside of the normal patch refreshes and boot issues, there are new build time tools within the kernel that required the following dependencies: For ORC_UNWINDER

[OE-core] [PATCH 000/130][v2] Rocko next pull request

Cover letter only Please consider these changes for Rocko-next Good builds over weekend. [v2] Removed two patches causing oe-selftest issues The following changes since commit f7b90ab3eaf832bd81f3efc1dab4dcf6863ac284: bitbake: main: Give a user readable error if we can't locate topdir

Re: [OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

On Mon, Dec 4, 2017 at 7:39 AM, Bruce Ashfield wrote: > Outside of the normal patch refreshes and boot issues, there are new > build time tools within the kernel that required the following > dependencies: > > For ORC_UNWINDER support in x86-64: > > DEPENDS +=

Re: [OE-core] [PATCH v9] kernel: Add support for multiple kernel packages

I know I'm late and this has gone through so many revisions, but I'm seeing unexplained changes in buildhistory: $ buildhistory-diff packages/corei7-64-intel-common-poky-linux/linux-intel/kernel-image-bzimage: FILELIST: removed "/boot/bzImage" Doing builds of virtual/kernel with and without this

[OE-core] Yocto Project Status WW49’17

Current Dev Position: YP 2.5 M1 development Next Deadline: YP 2.5 M1 cut off of 12/4/17 SWAT team rotation: Todor -> Tracy on Dec. 1, 2017. SWAT team rotation: Tracy -> Stephano on Dec. 8, 2017. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: ·

[OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

Outside of the normal patch refreshes and boot issues, there are new build time tools within the kernel that required the following dependencies: For ORC_UNWINDER support in x86-64: DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native elfutils', '', d)}" And for certificate

[OE-core] [PATCH 7/8] kernel-yocto: ensure that only a single defconfig is processed

As a follow up to the changes to ensure that KBUILD_DEFCONFIG will always get its defconfig into the processing, we also should ensure that we don't get both a KBUILD_DEFCONFIG and a SRC_URI defconfig in the configuration queue. If both are in the configuration queue, we end up with competing

[OE-core] [PATCH 4/8] linux-yocto/4.12: update to v4.12.16

Integrating the -stable updates from Paul Gortmaker that cover the following commits: 8500552cb6f7 Linux 4.12.16 3041c36e51aa vmbus: more host signalling avoidance 170ce449d952 vmbus: eliminate duplicate cached index 1843e4c61d03 vmbus: refactor hv_signal_on_read 3114e4beb799

[OE-core] [PATCH 6/8] kernel-yocto: Stop the build if defconfig is missing

From: Saul Wold The bberror does not stop the build correctly, this should be a bbfatal_log to ensure the failure correctly stops the build and logs the failure. Part of [YOCTO #12162] Signed-off-by: Saul Wold Signed-off-by: Bruce Ashfield

[OE-core] [PATCH 5/8] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG

From: Saul Wold When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig regardless if it compares or is copied. Otherwise $sccs is not set and the defconfig is not found correctly. Part of [YOCTO #12162] Signed-off-by: Saul Wold

[OE-core] [PATCH 2/8] linux-yocto/4.12: iwlwifi calltrace fixes and configuration warning cleanups

Merging the following upstream backports to fix a iwlwifi calltrace: 0b17e1b52f99 iwlwifi: mvm: support new flush API 89025056c0d1 iwlwifi: mvm: avoid variable shadowing d6dc077966e7 iwlwifi: mvm: add and use iwl_mvm_device_running() 5dfb593df8f0 iwlwifi: add wait for tx queue empty

[OE-core] [PATCH 0/8] kernel-yocto: consolidated pull request

Hi all, Here is the latest set of kernel updates and bug fixes to the kernel-yocto build. The 4.9 and 4.12 updates are routine -stable updates. I realize we are still fighting some boot/hang issues with 4.12, but I didn't see any new issues with the 4.12 updates, so I included them in this pull

[OE-core] [PATCH 1/8] linux-yocto/4.9: update to v4.9.61

Integrating the korg -stable updates that comprise the following commits: 5caae9d14199 Linux 4.9.61 be3390d86bc2 ARM: dts: mvebu: pl310-cache disable double-linefill 26fc85a0113d staging: r8712u: Fix Sparse warning in rtl871x_xmit.c 244cff7066f6 xen: don't print error message in case

[OE-core] [PATCH 3/8] linux-yocto/4.9: update to v4.9.65

Integrating the korg stable updates that include the following changes: 133e6ccf46f1 Linux 4.9.65 ceaec6e8cd98 mm/pagewalk.c: report holes in hugetlb ranges fae5947129eb coda: fix 'kernel memory exposure attempt' in fsync 9980b8278338 mm/page_alloc.c: broken deferred calculation

Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

On 4 December 2017 at 15:30, Olof Johansson wrote: > On 17-12-04 12:36 +, Burton, Ross wrote: > > You might be interested in some of the patches I've got sitting in > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mutb > > specifically around

Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

On 17-12-04 12:36 +, Burton, Ross wrote: > You might be interested in some of the patches I've got sitting in > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mutb > specifically around "Add new ELF parser". This adds a fully-featured > Python ELF parser to lib/oe which

Re: [OE-core] ✗ patchtest: failure for initramfs-framework installation improvements (rev4)

On Fri, 1 Dec 2017 23:07:48 +0100 Martin Jansa wrote: > Is it trying to apply whole series (including the 2 patches which were > already merged to master and actually introduced the issue I was trying to > fix)? > > Does it mean that I cannot send a fix into the e-mail

Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

You might be interested in some of the patches I've got sitting in http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mutb specifically around "Add new ELF parser". This adds a fully-featured Python ELF parser to lib/oe which could be used to inspect the binaries the way file

Re: [OE-core] [PATCH] bitbake.conf: set more conservative default for IMAGE_FSTYPES_DEBUGFS

Nope its queued now. You'll have noticed from the status reports we've been holding back on merging whilst trying to stabilise the autobuilders. Ross On 1 December 2017 at 19:45, Andre McCurdy wrote: > On Tue, Nov 7, 2017 at 2:35 PM, Andre McCurdy

[OE-core] [PATCHv2] libbsd: Make it build with GCC 5.0 and older

Signed-off-by: Peter Kjellerstedt --- This hit us when building master and Rocko with GCC 4.7.2... PATCHv2: Added a Signed-off-by to the patch. ...r-older-GCCs-not-supporting-__has_include.patch | 31 ++

[OE-core] [PATCH 2/3] coreutils: upgrade to 8.28

Signed-off-by: Chen Qi --- .../coreutils/{coreutils_8.27.bb => coreutils_8.28.bb}| 8 1 file changed, 4 insertions(+), 4 deletions(-) rename meta/recipes-core/coreutils/{coreutils_8.27.bb => coreutils_8.28.bb} (95%) diff --git

[OE-core] [PATCH 3/3] coreutils: add PACKAGECONFIG for single-binary

Add PACKAGECONFIG for single-binray. Disable it by default. When enabled, there would only be one binary file /usr/bin/coreutils, other files like 'ls' are text files containing contents like: #!/usr/bin/coreutils --coreutils-prog-shebang=ls And the size of the rpm package reduces from 849K

[OE-core] [PATCH 0/3] Upgrade coreutils and pciutils

The following changes since commit 4469acdf1d0338220f3fe2ecb5e079eea6fda375: lib/oe/utils: remove param_bool() (2017-12-02 11:25:34 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/PU-coreutils-pciutils

[OE-core] [PATCH 1/3] pciutils: upgrade to 3.5.6

Signed-off-by: Chen Qi --- meta/recipes-bsp/pciutils/{pciutils_3.5.5.bb => pciutils_3.5.6.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-bsp/pciutils/{pciutils_3.5.5.bb => pciutils_3.5.6.bb} (92%) diff --git

Re: [OE-core] [PATCH] libyui

Again, it sounds like this should be in another layer. Ross On 4 December 2017 at 02:01, Zheng, Ruoqin wrote: > Hi Alex: >I attend to make dnfdragora(which is a gui for dnf) used in oe-core, > and libyui is the depend of dnfdragora. > >

Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

On 17-12-01 22:13 +0100, Olof Johansson wrote: > On 17-12-01 11:43 -0600, Mark Hatle wrote: > > The original implementation did not include the ',' options because > > different > > versions of file (as well as different architectures) would return different > > strings. > > > > They all

Re: [OE-core] [PATCH 1/5] lib/oe/package.py: Expose is_elf

On 17-12-01 16:50 +0100, Olof Johansson wrote: > is_elf/isELF had copies in both staging.bbclass and package.bbclass. > After recent refactoring in staging.bbclass (involving breaking out the > isELF function to is_elf in lib/oe/package.py), the implementions > diverged. It would be beneficial to

[OE-core] [PATCH V2 1/1] ltp: remove ltp-staticdev package

The nm01 testcase runtime depends on a static library, and ltp-staticdev package is entirely pointless, so remove it and add the static libraries to ltp main package and skip the "staticdev" checks. Signed-off-by: Dengke Du --- meta/recipes-extended/ltp/ltp_20170929.bb

[OE-core] [PATCH V2 0/1] ltp: remove ltp-staticdev package

Changed in V2: Remove the pointless package: ltp-staticdev. The following changes since commit 4469acdf1d0338220f3fe2ecb5e079eea6fda375: lib/oe/utils: remove param_bool() (2017-12-02 11:25:34 +) are available in the git repository at:

[OE-core] [PATCH] busybox: CVE-2017-16544

In the add_match function in libbb/lineedit.c in BusyBox through 1.27.2, the tab autocomplete feature of the shell, used to get a list of filenames in a directory, does not sanitize filenames and results in executing any escape sequence in the terminal. This could potentially result in code