[OE-core] [PATCH] runqemu: If using a vmtype image do not add the -no-reboot flag

ot be added. Signed-off-by: Jason Wessel --- scripts/runqemu | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/runqemu b/scripts/runqemu index 21680b4..5ae3e5e 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -1241,7 +1241,9 @@ cla

Re: [OE-core] [PATCH] module.bbclass: swap AR and LD order

On 1/24/20 3:19 PM, Khem Raj wrote: > On Fri, Jan 24, 2020 at 1:05 PM Jason Wessel > wrote: >> >> On 1/24/20 1:13 PM, Khem Raj wrote: >>> On 1/24/20 10:19 AM, Christopher Larson wrote: >>>> What makefile change caused this? That behavior doesn't make much

Re: [OE-core] [PATCH] module.bbclass: swap AR and LD order

On 1/24/20 1:13 PM, Khem Raj wrote: > On 1/24/20 10:19 AM, Christopher Larson wrote: >> What makefile change caused this? That behavior doesn't make much sense >> given how make processes its command-line arguments. >> > > I agree with you here, it could be a rare check where one want to define

[OE-core] [PATCH] module.bbclass: swap AR and LD order

as command line arguments to the linker due to some changes in the kernel's Makefile. For now the easiest fix is to just swap the arguments in the module.bbclass. Signed-off-by: Jason Wessel --- meta/classes/module.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta

Re: [OE-core] [PATCH v2] wic: Using the right rootfs size during prepare_rootfs

ni Signed-off-by: Jason Wessel --- scripts/lib/wic/partition.py | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py index 2a71d7b1d6..d809408e1a 100644 --- a/scripts/lib/wic/partition.py +++ b/s

Re: [OE-core] [PATCH] wic: Using the right rootfs size during prepare_rootfs

ext") else self.fstype method = getattr(self, "prepare_rootfs_" + prefix) >From 04ba59686d6e70d7ae347a8e92667edbb882cb9d Mon Sep 17 00:00:00 2001 From: Jason Wessel Date: Wed, 25 Sep 2019 12:31:57 -0700 Subject: [PATCH] wic: Only use ROOTFS_SIZE for the IMAGE_ROOTF

[OE-core] [PATCH] gnupg: Extend -native wrapper to fix gpgme-native's gpgconf problems

-by: Jason Wessel --- meta/recipes-support/gnupg/gnupg_2.2.17.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-support/gnupg/gnupg_2.2.17.bb b/meta/recipes-support/gnupg/gnupg_2.2.17.bb index e5456dd9b9..689cf8a75e 100644 --- a/meta/recipes-support/gnupg/gnupg_2.2.17.bb +++ b/meta

[OE-core] [PATCH v2] serial-getty@.service: Allow device to fast fail if it does not exist

This other nice effect of this change is that the fast fail device extend to additional serial ports that may not exist on ARM BSPs or that might be configured in or out by the dtb files on different boards. Signed-off-by: Jason Wessel --- .../systemd/systemd-serialgetty/serial-getty@.servi

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

On 8/28/19 5:41 PM, Richard Purdie wrote: On Wed, 2019-08-28 at 15:24 -0500, Jason Wessel wrote: On 8/27/19 7:15 PM, richard.pur...@linuxfoundation.org wrote: On Tue, 2019-08-27 at 19:03 -0500, Jason Wessel wrote: On 8/27/19 5:58 PM, Richard Purdie wrote: Hi Jason, Somehow this change

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

On 8/27/19 7:15 PM, richard.pur...@linuxfoundation.org wrote: On Tue, 2019-08-27 at 19:03 -0500, Jason Wessel wrote: On 8/27/19 5:58 PM, Richard Purdie wrote: Hi Jason, Somehow this change is responsible for this build failure: https://autobuilder.yoctoproject.org/typhoon/#/builders/72

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

On 8/27/19 5:58 PM, Richard Purdie wrote: Hi Jason, Somehow this change is responsible for this build failure: https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/976 (steps 5c and 7c so failure during testimage). I have bisected it to this change, I haven't looked into why.

[OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

oted up all the way to systemd completion in less than 90 seconds. This other nice effect of this change is that the fast fail device extend to additional serial ports that may not exist on ARM BSPs or that might be configured in or out by the dtb files on different boards. Signed-off-by: Jason We

[OE-core] [PATCH] Revert "kernel.bbclass: adjust a condition checking"

. If an end user does not want the INITRAMFS_IMAGE generated, it should be set to "". [ Issue: LIN1019-1791 ] Signed-off-by: Jason Wessel --- meta/classes/kernel.bbclass | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/classes/kernel.bbclass b/me

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

On 8/16/19 4:50 PM, richard.pur...@linuxfoundation.org wrote: On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote: On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie wrote: This was discussed on IRC. We really really want to avoid that as a dependency if we care about build performance. Its really

[OE-core] [RFC PATCH 2/2] libc-package.bbclass: Split locale hard link processing into two parts

the results with out a parallel build to ensure the locale-tree is correct in its final form. [YOCTO #11299] [YOCTO #12434] Signed-off-by: Jason Wessel --- meta/classes/libc-package.bbclass | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meta/classes/libc-package.bbclass

[OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

to package the new binary. [YOCTO #11299] [YOCTO #12434] Signed-off-by: Jason Wessel --- .../glibc/cross-localedef-native_2.30.bb |3 + .../glibc/add-cross-localedef-hardlink.patch | 1115 + ...le-separate-from-util-linux-hardlink.patch | 226 3 files changed, 1344

[OE-core] [PATCH v2 4/4] dpkg: Provide update-alternative for start-stop-daemon

-r1/rootfs/usr/sbin/start-stop-daemon exists and is not a link === The solution is to add an update-alternative to start-stop-daemon for dpkg. Signed-off-by: Jason Wessel --- meta/recipes-devtools/dpkg/dpkg.inc | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meta

[OE-core] [PATCH v2 3/4] wic: Make disk partition size consistently computed

the end user about. Some of my default images make use of the head room + a computed directory size or while generating images. Signed-off-by: Jason Wessel --- scripts/lib/wic/partition.py | 18 ++ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/scripts/lib/wic

[OE-core] [PATCH v2 2/4] wic: Add partition type for msdos partition tables

1s 321996s logical ext4 3 860936s 890939s 30004s primary ext4 boot Signed-off-by: Jason Wessel --- scripts/lib/wic/ksparser.py | 2 ++ scripts/lib/wic/partition.py | 1 + scripts/lib/wic/plugins/imager/direct.py | 37 +--- 3

[OE-core] [PATCH v2 1/4] image_types_wic.bbclass: Copy the .wks and .env files to deploy image dir

a wild card like: cd tmp*/deploy/images/* wic create --vars . -e core-image-minimal -s -m core-image-minimal-*.wks Signed-off-by: Jason Wessel --- meta/classes/image_types_wic.bbclass | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/meta/classes

Re: [OE-core] [PATCH 1/4] image_types_wic.bbclass: Copy the .wks and .env files to deploy image dir

On 8/8/19 1:42 PM, Richard Purdie wrote: On Thu, 2019-08-08 at 05:55 -0700, Jason Wessel wrote: When using a .wks.in file, the only place that the generated .wks file exists in the tmp/work area. A copy should be left behind in the deploy directory so that you can easily run the wic tool to re

Re: [OE-core] [PATCH 1/4] image_types_wic.bbclass: Copy the .wks and .env files to deploy image dir

On 8/8/19 7:55 AM, Jason Wessel wrote: When using a .wks.in file, the only place that the generated .wks file exists in the tmp/work area. A copy should be left behind in the deploy directory so that you can easily run the wic tool to re-generate or modify a new image without running bitbake

[OE-core] [PATCH 3/4] wic: Make disk partition size consistently computed

the end user about. Some of my default images make use of the head room + a computed directory size or while generating images. Signed-off-by: Jason Wessel --- scripts/lib/wic/partition.py | 18 ++ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/scripts/lib/wic

[OE-core] [PATCH 2/4] wic: Add partition type for msdos partition tables

1s 321996s logical ext4 3 860936s 890939s 30004s primary ext4 boot Signed-off-by: Jason Wessel --- scripts/lib/wic/ksparser.py | 2 ++ scripts/lib/wic/partition.py | 1 + scripts/lib/wic/plugins/imager/direct.py | 37 +--- 3

[OE-core] [PATCH 1/4] image_types_wic.bbclass: Copy the .wks and .env files to deploy image dir

a wild card like: cd tmp*/deploy/images/* wic create --vars . -e core-image-minimal -s -m core-image-minimal-*.wks Signed-off-by: Jason Wessel --- meta/classes/image_types_wic.bbclass | 9 + 1 file changed, 9 insertions(+) diff --git a/meta/classes/image_types_wic.bbclass b/meta

[OE-core] [PATCH 4/4] dpkg: Provide update-alternative for start-stop-daemon

-r1/rootfs/usr/sbin/start-stop-daemon exists and is not a link === The solution is to add an update-alternative to start-stop-daemon for dpkg. Signed-off-by: Jason Wessel --- meta/recipes-devtools/dpkg/dpkg.inc | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meta

[OE-core] [PATCH v3] sqlite3: Fix zlib determinism problem

cache variable). The target binaries were not previously building with zlib, so we will leave the default being zlib turned off, while the host binaries were building with it "occasionally", but not for anything at runtime. Signed-off-by: Jason Wessel --- meta/recipes-support/sqlite/s

[OE-core] [PATCH v2] sqlite3: Fix zlib determinism problem

cache variable). The target binaries were not previously building with zlib, so we will leave the default being zlib turned off, while the host binaries were building with it "occasionally", but not for anything at runtime. Signed-off-by: Jason Wessel --- meta/recipes-support/sqlite/s

Re: [OE-core] [PATCH] sqlite3: Always build sqlite3-native with zlib

On 8/6/19 2:17 PM, Alexander Kanavin wrote: On Tue, 6 Aug 2019 at 20:52, Jason Wessel mailto:jason.wes...@windriver.com>> wrote: Just to follow up to be very specific about how I deleted files, you can see the identical failure with: sudo yum install -y zlib-devel rm -

Re: [OE-core] [PATCH] sqlite3: Always build sqlite3-native with zlib

On 8/6/19 1:36 PM, Jason Wessel wrote: On 8/6/19 12:55 PM, Alexander Kanavin wrote: On Tue, 6 Aug 2019 at 19:31, Jason Wessel mailto:jason.wes...@windriver.com>> wrote: The build of sqlite3-native is not fully deterministic.  There is some corner case as shown with the recent

Re: [OE-core] [PATCH] sqlite3: Always build sqlite3-native with zlib

On 8/6/19 12:55 PM, Alexander Kanavin wrote: On Tue, 6 Aug 2019 at 19:31, Jason Wessel mailto:jason.wes...@windriver.com>> wrote: The build of sqlite3-native is not fully deterministic.  There is some corner case as shown with the recent pseudo commit where the s

[OE-core] [PATCH] sqlite3: Always build sqlite3-native with zlib

is ignored as usual. Signed-off-by: Jason Wessel --- meta/recipes-support/sqlite/sqlite3.inc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc index daf3db5e9f..2e48f303ee 100644 --- a/meta/recipes-support/sqlite

Re: [OE-core] [PATCH v3] pseudo: Fix openat() with a symlink pointing to a directory

On 8/6/19 10:39 AM, Jason Wessel wrote: On 8/6/19 9:59 AM, Jason Wessel wrote: On 8/6/19 9:20 AM, Richard Purdie wrote: On Mon, 2019-08-05 at 09:32 -0700, Jason Wessel wrote: While working with ostree disk generation in conjunction with wic, I found a problem with pseudo where it tried

Re: [OE-core] [PATCH v3] pseudo: Fix openat() with a symlink pointing to a directory

On 8/6/19 9:59 AM, Jason Wessel wrote: On 8/6/19 9:20 AM, Richard Purdie wrote: On Mon, 2019-08-05 at 09:32 -0700, Jason Wessel wrote: While working with ostree disk generation in conjunction with wic, I found a problem with pseudo where it tried to resolve a symlink when it shouldn't, based

Re: [OE-core] [PATCH v3] pseudo: Fix openat() with a symlink pointing to a directory

On 8/6/19 9:20 AM, Richard Purdie wrote: On Mon, 2019-08-05 at 09:32 -0700, Jason Wessel wrote: While working with ostree disk generation in conjunction with wic, I found a problem with pseudo where it tried to resolve a symlink when it shouldn't, based on openat() flags. A C program has been

[OE-core] [PATCH v3] pseudo: Fix openat() with a symlink pointing to a directory

nk", O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC | O_NOFOLLOW); if (target_dfd == -1) { printf("This is right\n"); } else { printf("This is broken\n"); } return 0; } Many thanks to Peter Seebach for fixing the problem in the pseudo code to use th

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

If we understood more about the nature of the race condition a test case could probably be constructed. For now, it is worth a try to see if it is any better.  I am certain the timing will change ever so slightly, so we could hit the glibc-locale issue more or less... All of the regression

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

seems the db is corrupted */ if (!lstat("tlink", ) && sbuf.st_uid == 0) printf("Test 5 good\n"); else printf("Test 5 failed... tlink is owned by %i and not 0\n", sbuf.st_uid); return 0; } On 8/1/19 6:57 PM, Seebs wrote: On Thu, 1

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] I'll continue to look into the problem. Cheers, Jason. On 8/1/19 3:03 PM, Jason Wessel wrote: While working with ostree disk generation in conjunction with wic, I found a problem with pseudo where

[OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink

Seebach for fixing the problem in the pseudo code to use the same logic which was already there for the AT_SYMLINK_NOFOLLOW. Also updated is the license MD5 checksum since the master branch of pseudo has had teh SPDX data updated. Signed-off-by: Jason Wessel --- meta/recipes-devtools/pseudo/pseudo.inc| 2 +- meta/r

Re: [OE-core] [PATCH] pseudo: Upgrade to latest to fix openat() with a directory symlink

Looks like the checksum license changed between the prior commit and now.  So I'll send a v2, because we don't want to break the master branch of oe-core. Cheers, Jason. On 8/1/19 12:55 PM, Jason Wessel wrote: While working with ostree disk generation in conjunction with wic, I found

[OE-core] [PATCH] pseudo: Upgrade to latest to fix openat() with a directory symlink

Seebach for fixing the problem in the pseudo code to use the same logic which was already there for the AT_SYMLINK_NOFOLLOW. Signed-off-by: Jason Wessel --- meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/re

Re: [OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs

On 7/6/19 2:31 PM, Adrian Bunk wrote: On Thu, Jul 04, 2019 at 06:57:50AM -0500, Jason Wessel wrote: On 7/4/19 5:57 AM, Adrian Bunk wrote: On Thu, Jul 04, 2019 at 11:13:18AM +0200, Martin Jansa wrote: I don't see how this change (or the previous glibc-locale one) would cause that, but since

[OE-core] [PATCH] glibc / glibc-locale: Fix stash_locale determinism problems

ocale-tree//usr/share/i18n/charmaps/*gz.gz: No such file or directory = After this one time change I tested changing only the do_stash_locale() function and it now works well because it is deterministically operating off the sstate data or a local build. Signed-off-by: Jason Wessel --- meta/re

Re: [OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs

On 7/4/19 5:57 AM, Adrian Bunk wrote: On Thu, Jul 04, 2019 at 11:13:18AM +0200, Martin Jansa wrote: I don't see how this change (or the previous glibc-locale one) would cause that, but since the oe-core upgrade yesterday I'm seeing following glibc-locale.do_package failure:

[OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs

of this patch is make it 100% consistent between the build types and fix the builds. Signed-off-by: Jason Wessel --- meta/recipes-core/glibc/glibc-package.inc | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta

[OE-core] [PATCH 2/3] glibc-locale: Fix build error with PACKAGE_NO_GCONV = "1"

the empty directory. Signed-off-by: Jason Wessel --- meta/recipes-core/glibc/glibc-locale.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/glibc/glibc-locale.inc b/meta/recipes-core/glibc/glibc-locale.inc index f033635bd0..bf5eaee938 100644 --- a/meta/recipes-core/glibc

[OE-core] [PATCH 0/3] Fixes for build failures for multilibs + usrmerge, NLS and GCONV

Here are a few more fixes for usrmerge, multilibs, NLS, and GCONV. Thanks, Jason. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] psmisc: Fix dependency for USE_NLS=no

es Gettext | ERROR: autoreconf execution failed. This is because the gettext.bbclass returns gettext-minimal-native for the host dependency which does not include autopoint. The autopoint utility is required to build psmisc, so it needs to list gettext-native as a dependency. Signed-off-by: Ja

[OE-core] [PATCH v2] glibc: Fix multilibs + usrmerge builds

= "/usr/lib" ]; then * yes multilibs no usrmerge if [ "/usr/lib64" != "/usr/lib" ] && [ "/lib" != "/usr/lib" ]; then * yes multilibs yes user merge if [ "/usr/lib64" != "/usr/lib" ] && [ "/usr/li

Re: [OE-core] [PATCH] glibc: Fix multilibs + usrmerge builds

This version was against the thud branch.  I'll send a v2 for the master branch since there was some fuzz that the auto patch checker couldn't deal with.  The same problem exists in thud and the master branch. Cheers, Jason. On 6/29/19 7:41 PM, Jason Wessel wrote: The build of glibc fails

[OE-core] [PATCH] glibc: Fix multilibs + usrmerge builds

= "/usr/lib" ]; then * yes multilibs no usrmerge if [ "/usr/lib64" != "/usr/lib" ] && [ "/lib" != "/usr/lib" ]; then * yes multilibs yes user merge if [ "/usr/lib64" != "/usr/lib" ] && [ "/usr/li

Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner

On 4/11/19 3:01 PM, Alexander Kanavin wrote: > Yes, I agree. > > Alex > >> On 11 Apr 2019, at 21.59, Richard Purdie >> wrote: >> >>> On Thu, 2019-04-11 at 11:36 -0500, Jason Wessel wrote: >>> >>> It all appears to work fine without the n

Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner

On 4/11/19 10:35 AM, Alexander Kanavin wrote: > On Thu, 11 Apr 2019 at 17:25, Jason Wessel wrote: >>> Generally because generating introspection data is disabled for native >>> packages, as a matter of policy (do not build something which is >>> unused and untes

Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner

On 4/11/19 9:44 AM, Alexander Kanavin wrote: > Generally because generating introspection data is disabled for native > packages, as a matter of policy (do not build something which is > unused and untested). > > If you could add > EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}" > > to

Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner

should not be running g-ir-scanner at all, as we > explicitly disable this for native builds. Can you please look into > why it is happening, because the patch is really treating the symptom > rather than the problem. > > Alex > > On Wed, 10 Apr 2019 at 23:54, Jason Wessel

[OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner

in the bbclass should be all that is needed. The qemu wrapper was already setting this properly, but we also need it for the -native builds. meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:131: export GI_SCANNER_DISABLE_CACHE=1 Signed-off-by: Jason Wessel --- meta/classes

Re: [OE-core] [PATCH 2/3] boost: Fix link problems with caffe and Movidius SDK

. The override to build with python boost for cmake and caffe is as follows: cmake -DBoost_PYTHON_LIBRARY_DEBUG=/usr/lib64/libboost_python3.so \    -DBoost_PYTHON_LIBRARY_RELEASE=/usr/lib64/libboost_python3.so \    -DBLAS=Open \    .. Cheers, Jason. On 03/14/2018 09:55 AM, Jason Wessel wrote: Perhaps

Re: [OE-core] [PATCH 1/3] alsa-lib: Add an RPROVIDES for alsa-lib

y odd.  Can you give an example of this happening? Ross On 13 March 2018 at 03:08, Jason Wessel <jason.wes...@windriver.com <mailto:jason.wes...@windriver.com>> wrote: There are a number of other recipes outside oe-core that depend on alsa-lib and the rpm4 dependencies resolve s

Re: [OE-core] [PATCH 2/3] boost: Fix link problems with caffe and Movidius SDK

the python3 tests with the Movidius SDK pass (which use python3). Jason. On 03/14/2018 09:50 AM, Burton, Ross wrote: I thought that boost_python was the py2 binary, and boost_python3 was the py3 one?  Is this not a bug in caffe? On 13 March 2018 at 03:08, Jason Wessel <jason.wes...@windriver.

[OE-core] [PATCH 3/3] python3: Fix purelib install and runtime paths

): File "", line 1, in ImportError: No module named 'imutils' Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- .../python/python3/python-3.3-multilib.patch| 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/meta/recipes

[OE-core] [PATCH 2/3] boost: Fix link problems with caffe and Movidius SDK

): The dependency target "pycaffe" of target "pytest" does not exist. Conditionally creating the link when building python3 support into boost is all that is needed. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/recipes-support/boost/boost.inc

[OE-core] [PATCH 1/3] alsa-lib: Add an RPROVIDES for alsa-lib

is to add an RPROVIDES for alsa-lib to libasound which provides all the shared objects for alsa. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-multimedia/alsa/alsa-lib

[OE-core] [PATCH] python3: Fix install purelib to make pip3-python work properly

that python3 will never reference and cause random failures. This patch fixes the purelib install directory to match the purelib use directory for externally managed python modules when using multilibs. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/recipes-devtools/python/

[OE-core] [PATCH] package_manager.py: Print offending package instead of non-sense trace

022:return True 0023: Exception: TypeError: stat: can't specify None for path argument Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/lib/oe/package_manager.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/pa

Re: [OE-core] [PATCH] image.bbclass: Use deltask instead of noexec for package_write_rpm

On 03/05/2018 07:52 AM, Jason Wessel wrote: On 03/03/2018 09:50 AM, Richard Purdie wrote: On Sat, 2018-03-03 at 12:46 -0300, Otavio Salvador wrote: On Fri, Mar 2, 2018 at 5:27 PM, Jason Wessel <jason.wessel@windriver. com> wrote: If you install an image into another image (this is th

Re: [OE-core] [PATCH] image.bbclass: Use deltask instead of noexec for package_write_rpm

On 03/03/2018 09:50 AM, Richard Purdie wrote: On Sat, 2018-03-03 at 12:46 -0300, Otavio Salvador wrote: On Fri, Mar 2, 2018 at 5:27 PM, Jason Wessel <jason.wessel@windriver. com> wrote: If you install an image into another image (this is the case for custom initrd for example), it wil

[OE-core] [PATCH] image.bbclass: Use deltask instead of noexec for package_write_rpm

erated. Not running the task eliminates the problem. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/classes/image.bbclass | 2 +- meta/lib/oe/package_manager.py | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/classes/image.bbclass b/met

[OE-core] [PATCH] logging.bbclass: Enclose the tr string in quotes

remove the digits using the tr expression. Enclosing the expression in quotes causes it to work properly. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/classes/logging.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/logging.bbclass

[OE-core] [PATCH] libgfortran: Work around libbacktrace build failures

on the target system. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/recipes-devtools/gcc/libgfortran.inc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/meta/recipes-devtools/gcc/libgfortran.inc b/meta/recipes-devtools/gcc/libgfortran.inc index 5f5d4af758..2f

[OE-core] [PATCH 1/1] ovmf: Fix build failure for PARALLEL_MAKE with no space

is because the build.sh expects a space. The simple work around is to fix the recipe to add some white space. The build.sh only cares that it gets at least one space between the arguments, the extra space if someone uses "-j 4" does not cause problems. Signed-off-by: Jason Wessel <jas

[OE-core] [ PATCH 0/1 ] ovmf: Fix build failure for PARALLEL_MAKE with no space

Please consider for master and the rocko branch. It is a simple build fix reported by someone using PARALLEL_MAKE = "-j4" instead of PARALLEL_MAKE = "-j 4". It is the only package that we have hit so far that exhibits this kind of failure so it seems it would be best to just fix it. :-)

Re: [OE-core] [PATCH] systemd: Fix rootfs transaction error when PACKAGECONFIG has polkit

: Does this work on hosts without polkitd user? Here it failed with: | chown: invalid user: ‘polkitd:root’ On Tue, Aug 15, 2017 at 8:55 PM, Jason Wessel <jason.wes...@windriver.com <mailto:jason.wes...@windriver.com>> wrote: The systemd 234 added some files to the polk

[OE-core] [PATCH] systemd: Fix rootfs transaction error when PACKAGECONFIG has polkit

attempted installs of polkit-0.113-r0.15.core2_64 and systemd-1:234-r0.0.core2_64 The fix similar to other packages such as libvirt where the user must exist and the directory must be created with the proper attributes. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/recipe

[OE-core] [PATCH] openssl10: Fix conflict between openssl and openssl10 man pages.

pages and symlinks to have a prefix of openssl10-. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- meta/recipes-connectivity/openssl/openssl10.inc | 10 ++ 1 file changed, 10 insertions(+) diff --git a/meta/recipes-connectivity/openssl/openssl10.inc b/meta/r

Re: [OE-core] [PATCH 2/2] Revert "kernel: Modify kernel modules installation path."

On 01/20/2017 07:52 AM, Burton, Ross wrote: On 20 January 2017 at 13:48, Jason Wessel <jason.wes...@windriver.com <mailto:jason.wes...@windriver.com>> wrote: WARNING: linux-yocto-4.8.12+gitAUTOINC+3edb4de355_9bcb4ea3fa-r0 do_package: QA Issue: linux-yocto: Files/dire

Re: [OE-core] [PATCH 2/2] Revert "kernel: Modify kernel modules installation path."

On 01/20/2017 07:30 AM, Burton, Ross wrote: On 20 January 2017 at 13:29, Maxin B. John > wrote: > The issue here is that in a multilib build the ${base_libdir} is resolving to /lib64 which completely breaks some tools that fully expect

Re: [OE-core] [PATCH 2/2] Revert "kernel: Modify kernel modules installation path."

quite that simple because it didn't fully work for the firmware loader so for now it would be best to just revert the two patches and keep oe-core working. Cheers, Jason. On 01/19/2017 03:14 PM, Jason Wessel wrote: This reverts commit 0ccb2efe9837e2915c093341a662dffc1df00866. The OVS fails

[OE-core] [PATCH 2/2] Revert "kernel: Modify kernel modules installation path."

This reverts commit 0ccb2efe9837e2915c093341a662dffc1df00866. The OVS fails to function and the kernel modules cannot be found by any of the kernel tools such as depmod because they are installed into the wrong directory in multilib 64bit/32bit bulids. Signed-off-by: Jason Wessel <jason.

[OE-core] [PATCH 1/2] Revert "linux-firmware: Modify firmware installation path"

This reverts commit a46a23fed9acd097ecc8ab3985d18688abe7b065. The 64bit/32bit multilib builds break because the kernel's firmware loader cannot find the firmware because it gets placed int the wrong directory. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- .../linux-firmware

[OE-core] [PATCH] systemd: Backport cgroup fix from 233 to 232

backported and can be dropped in a future uprev. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- ...use-the-unified-hierarchy-for-the-systemd.patch | 51 ++ meta/recipes-core/systemd/systemd_232.bb | 1 + 2 files changed, 52 insertions(+) creat

Re: [OE-core] [PATCH] liburi-perl: Uprev from 1.60 to 1.71 to pickup bugfixes and compatibilty

Looks like someone beat me to it, but it had not been merged yet, so this can be ignored. Cheers, Jason. On 12/07/2016 12:31 PM, Jason Wessel wrote: The exo recipe from meta-oe no longer compiles and some parts of URI::Escape no longer work due to changes in perl 5. The main reason

[OE-core] [PATCH] liburi-perl: Uprev from 1.60 to 1.71 to pickup bugfixes and compatibilty

e perl 5.24 transitioned the \C regex from deprecated into a hard error. Signed-off-by: Jason Wessel <jason.wes...@windriver.com> --- .../perl/{liburi-perl_1.60.bb => liburi-perl_1.71.bb} | 8 1 file changed, 4 insertions(+), 4 deletions(-) rename meta/recipes-devtoo

[OE-core] [PATCH] initscripts: Fix regression for requiring /bin/bash

/lib/smart install -y dropbear@armv7at2_vfp hac@armv7at2_vfp run-postinsts@all kernel-modules@qemuarma9 packagegroup-core-boot@qemuarma9' returned 1: error: Can't install initscripts-1.0-r155.0@armv7at2_vfp: no package provides /bin/bash Signed-off-by: Jason Wessel jason.wes...@windriver.com

Re: [OE-core] relocate_sdk.py: Possible bug, /lib64/ld-linux-x86-64.so.2 not relocated

On 03/01/2014 08:26 AM, Stefan Agner wrote: Hi, Using top of dylan branch, I generated a SDK using bitbake meta-toolchain. I'm running Arch Linux, but I also see similar issues on Ubuntu 12.04.4 LTS: Some binaries segfault when running them. I discovered, that the dynamic linker of the

Re: [OE-core] [PATCH v2 1/6] unfs3: Add a NFSv3 user mode server for use with runqemu

On 02/01/2014 03:22 AM, Richard Purdie wrote: Hi Jason, We're seeing a parallel make race on the autobuilder and it seems its from this patch: You actually still need the patch or you get a different parallel build error with the lib file. I tracked down the regression from the original.

[OE-core] [PATCH 1/1] unfs3: Fix dependencies and allow target builds

be deployed into an image * Delete commented out unfs3 references in separatebuilddir.inc because unfs3 works correctly with autotools. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- meta/conf/distro/include/seperatebuilddir.inc |2 -- .../unfs3/unfs3

[OE-core] [PATCH 0/1] unfs3: Fix dependencies and allow target builds

The prior series which introduced unfs3 was going to have a v3, but the v2 series already got merged to the master branch. The patch that follows was originally going to be squashed into different patches in the series. The aim is to address the remaining comments from Phil. Thanks, Jason.

[OE-core] [PATCH v2] unfs3: Fix dependencies and allow target builds

be deployed into an image * Add unfs3 references in separatebuilddir.inc because unfs3 works correctly with autotools. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- meta/conf/distro/include/seperatebuilddir.inc |7 +++ .../unfs3/unfs3/alternate_rpc_ports.patch

Re: [OE-core] [PATCH 1/1] unfs3: Fix dependencies and allow target builds

On 01/29/2014 08:19 AM, Richard Purdie wrote: On Wed, 2014-01-29 at 08:12 -0600, Jason Wessel wrote: Fixed in this patch: * All patches marked as submitted to the upstream * Remove the pseudo dependency because unfs3 can fully stand alone or be used with pseudo and it does

[OE-core] [PATCH v2 5/6] runqemu-export-rootfs: update for unfs3

The unfs3 no longer has an rpc.mountd component. There is just a single server for mountd and nfsd requests. This means changing the name of the server in the scripts that check for it. [YOCTO #5639] Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/runqemu-export-rootfs

[OE-core] [PATCH v2 6/6] runqemu, runqemu-internal: Allow slirp for NFS and KVM use

will not be configure or used. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/runqemu | 10 ++ scripts/runqemu-internal | 19 +++ 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/scripts/runqemu b/scripts/runqemu index dcb2931

[OE-core] [PATCH v2 3/6] runqemu: Use the newer unfs3 for serving user space nfs

From: Saul Wold s...@linux.intel.com This new version correctly handles the 64bit ext3 / ext4 issues we were seeing with the older unfs-server which did not handle 64bit file systems correctly, producing the duplicate cookies. [YOCTO #5639] Signed-off-by: Saul Wold s...@linux.intel.com ---

[OE-core] [PATCH v2 2/6] unfs3, unfs-server: Replace all instances of unfs-server with unfs3

Other recipes dependencies and even some comments need to be updated for the removal of unfs-server and the replacement with unfs3. The unfs3 is a complete drop in replacement providing all the prior functionality of NFSv2 but also adding NFSv3. [YOCTO #5639] Signed-off-by: Jason Wessel

[OE-core] [PATCH v2 1/6] unfs3: Add a NFSv3 user mode server for use with runqemu

] Signed-off-by: Jason Wessel jason.wes...@windriver.com --- meta/files/common-licenses/unfs3 | 24 +++ .../unfs3/unfs3/alternate_rpc_ports.patch | 158 .../unfs3/unfs3/fix_compile_warning.patch | 25

Re: [OE-core] [PATCH v2 1/6] unfs3: Add a NFSv3 user mode server for use with runqemu

On 01/23/2014 09:01 AM, Phil Blundell wrote: On Thu, 2014-01-23 at 08:32 -0600, Jason Wessel wrote: +++ b/meta/files/common-licenses/unfs3 @@ -0,0 +1,24 @@ +UNFS3 user-space NFSv3 server +(C) 2003, Pascal Schmidt unfs3-ser...@ewetel.net + +Redistribution and use in source and binary forms

[OE-core] [PATCH 2/6] unfs3, unfs-server: Replace all instances of unfs-server with unfs3

Other recipes dependencies and even some comments need to be updated for the removal of unfs-server and the replacement with unfs3. The unfs3 is a complete drop in replacement providing all the prior functionality of NFSv2 but also adding NFSv3. [YOCTO #5639] Signed-off-by: Jason Wessel

[OE-core] [PATCH 0/6] Replace unfs-server with unfs3

a rootfs and run it as a non-root user. Example: runqemu-extract-sdk tmp-eglibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.tar.bz2 rootfs runqemu qemux86-64 `pwd`/rootfs nographic slirp Cheers, Jason. Jason Wessel (5

[OE-core] [PATCH 6/6] runqemu, runqemu-internal: Allow slirp for NFS and KVM use

will not be configure or used. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/runqemu | 10 ++ scripts/runqemu-internal | 19 +++ 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/scripts/runqemu b/scripts/runqemu index dcb2931

[OE-core] [PATCH 3/6] runqemu: Use the newer unfs3 for serving user space nfs

From: Saul Wold s...@linux.intel.com This new version correctly handles the 64bit ext3 / ext4 issues we were seeing with the older unfs-server which did not handle 64bit file systems correctly, producing the duplicate cookies. [YOCTO #5639] Signed-off-by: Saul Wold s...@linux.intel.com ---

  1   2   3   >