[OE-core] [RFC][PATCH] gcc: add flex-native explicit dependency

From: Denys Dmytriyenko It seems flex is required to build gcc: | .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex: command not found | WARNING: 'flex' is missing on your system. | You should only need it if you modified a '.l' file. | You may want

[OE-core] [PATCH] base.bbclass: drop legacy armv7a-vfp-neon TUNE_PKGARCH renaming

ARM specific TUNE_PKGARCH renaming was adding in 2011 handle the transition from armv7a -> armv7a-vfp-neon: http://git.openembedded.org/openembedded-core/commit/?id=08c0b7060009113e8dffdef51ff6b9b4b7f28894 Active package feeds should now have long since updated to the new naming. For example,

[OE-core] [PATCH] perf: depend on native versions of bison and flex

From: Denys Dmytriyenko Explicitly depend on bison-native and flex-native for deterministic builds, as those are required for the build: | Makefile.config:129: *** Error: flex is missing on this system, please install it. Stop. | Makefile.perf:205: recipe for target 'sub-make'

[OE-core] [PATCH 2/2] rpcbind: Stop freeing a static pointer

From: Jackie Huang commit 7ea36ee introduced a svc_freeargs() call that ended up freeing static pointer. It turns out the allocations for the rmt_args is not necessary . The xdr routines (xdr_bytes) will handle the memory management and the largest possible message

[OE-core] [PATCH 1/2] rpcbind: fix assertion failure

From: Jackie Huang Backport a patch to fix the assertion failure: rpcbind: ../../libtirpc-1.0.2/src/pmap_prot.c:50: xdr_pmap: Assertion `regs != NULL' failed. Signed-off-by: Jackie Huang ---

[OE-core] [PATCH 0/2] rpcbind: fix a freeing issue and an assertion failure

From: Jackie Huang -- The following changes since commit 205cfd702190026e64eed9cae27c05ff62d1637e: bitbake: fetch2/__init__: Disable pseudo in runfetchcmd() (2018-01-08 08:48:54 +) are available in the git repository at:

Re: [OE-core] [PATCH] at: explicitly depend on bison-native for deterministic builds

On Tue, Jan 09, 2018 at 11:11:56PM +, Richard Purdie wrote: > On Tue, 2018-01-09 at 17:24 -0500, Denys Dmytriyenko wrote: > > From: Denys Dmytriyenko > > > > Usually bison-native gets into sysroot through indirect dependencies, > > even with RSS. But when bison-native is not in

Re: [OE-core] [PATCH] core-image-minimal-initramfs: use initramfs-framework for initialization

Anything wrong with this? Haven't seen it hit any mut branches. Thanks, Cal On 12/19/2017 02:12 PM, California Sullivan wrote: initramfs-framework is more modular and expandable. This change was proposed in commit 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e "core-image-minimal-initramfs: use

Re: [OE-core] [PATCH] at: explicitly depend on bison-native for deterministic builds

On Tue, 2018-01-09 at 17:24 -0500, Denys Dmytriyenko wrote: > From: Denys Dmytriyenko > > Usually bison-native gets into sysroot through indirect dependencies, > even with RSS. But when bison-native is not in sysroot, due to > different > system config, Any idea what that

[OE-core] [PATCH] at: explicitly depend on bison-native for deterministic builds

From: Denys Dmytriyenko Usually bison-native gets into sysroot through indirect dependencies, even with RSS. But when bison-native is not in sysroot, due to different system config, it falls back to using "yacc" instead and fails like this: | yacc -d parsetime.y | make: yacc:

Re: [OE-core] Issues with meson in SDK with cross-file

On 01/09/2018 10:40 AM, Jussi Pakkanen wrote: On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly wrote: Note the "native C compiler" line, which directly uses $CC. I'm not sure if this is correct, but an easy way to fix the issue is to ignore $CC for internal sanity checking when

[OE-core] [PATCH] bash: ptest dependency on locale should honor virtual/libc-locale

From: Denys Dmytriyenko meta/conf/distro/include/tclibc-glibc.inc weakly assigns PREFERRED_PROVIDER for virtual/libc-locale to glibc-locale, but allows adjusting it if needed. Hence, bash should not depend on glibc-locale directly, but instead use this virtual/libc-locale variable.

[OE-core] [PATCH] mesa: Upgrade to 17.3.2 release

The 17.3.2 release, published in January 9th, 2018. It fixes a number of issues since 17.3.1 release. The release notes can be seen at: - 17.3.2: https://www.mesa3d.org/relnotes/17.3.2.html Signed-off-by: Otavio Salvador ---

Re: [OE-core] bash: add missing build dependencies for ptest

I believe below DEPENDS line should actually refer "virtual/libc-locale" instead of directly "glibc-locale": http://cgit.openembedded.org/openembedded-core/tree/meta/conf/distro/include/tclibc-glibc.inc On Mon, Jan 08, 2018 at 08:57:38PM -0500, Denys Dmytriyenko wrote: > Somehow, below change

Re: [OE-core] Issues with meson in SDK with cross-file

On 01/09/2018 02:06 AM, Nirbheek Chauhan wrote: On Tue, Jan 9, 2018 at 3:20 PM, Nirbheek Chauhan wrote: If we want to setup a cross-file to use these arguments, we would have to generate the cross-file on-the-fly (not good). Out of interest, why is that not good?

Re: [OE-core] Issues with meson in SDK with cross-file

+CC Khem Raj, who has done a lot of work on the SDK and may have an opinion about handling relocatable cross files. On 01/09/2018 01:50 AM, Nirbheek Chauhan wrote: On Tue, Jan 9, 2018 at 5:21 AM, Martin Kelly wrote: [Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

On 1/4/18 4:41 AM, Patrick Ohly wrote: > On Thu, 2018-01-04 at 11:18 +0100, José Bollo wrote: >>> Do you agree to move the patch to Smack specific layer? Such as  >>> meta-security? >> >> I agree. > > Layers like meta-security should not modify recipes from other layers, > at least not by

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

On Fri, 2018-01-05 at 01:07 +, Fan, Wenzong wrote: > It works and will override the labels of home dir that SELinux > applied, that's the issue. > > For SELinux enabled system, the user's home dir should have lavel > 'user_home_dir_t' instead of 'etc_t', it prevents users from creating >

[OE-core] [PATCH] meson.bbclass: use HOST_CC_ARCH, not TARGET_CC_ARCH

From: Christopher Larson Using TARGET_CC_ARCH is inconsistent with CC, which uses HOST_CC_ARCH, and the rest of meson.bbclass, which uses HOST_PREFIX, HOST_OS, etc. Signed-off-by: Christopher Larson --- meta/classes/meson.bbclass | 2 +- 1

[OE-core] [PATCH] glib-2.0: rationalise build dependencies

nativesdk-glib-2.0 doesn't build-depend on nativesdk-gettext, but all variations need to depend on gettext-native as they need msgfmt (so gettext-minimal-native isn't an option). Signed-off-by: Ross Burton --- meta/recipes-core/glib-2.0/glib.inc | 12 +++- 1 file

Re: [OE-core] [rocko][PATCH 0/4] Backport masterimage fixes

These missed the 2.4.1 boat. Could we get these applied so they are sure to make it into 2.4.2? Thanks! https://patchwork.openembedded.org/series/9690/ On 11/9/17 8:58 AM, Stephano Cetola wrote: > Backporting fixes since I never got these into 2.4. > > Requested by erik.b...@pelagicore.com. >

[OE-core] [PATCH v2] wic: if we can't get from ioctl, try from os.stat()

Under some conditions, ioctl FIGETBSZ can't return real value. We can try to use fallback via os.stat() to get block size. Source of patch: https://github.com/intel/bmap-tools/commit/17365f4fe9089df7ee9800a2a0ced177ec4798a4 Signed-off-by: Dogukan Ergun ---

[OE-core] ✗ patchtest: failure for wic: if we can't get from ioctl, try from os.stat()

== Series Details == Series: wic: if we can't get from ioctl, try from os.stat() Revision: 1 URL : https://patchwork.openembedded.org/series/10449/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have

[OE-core] [PATCH] wic: if we can't get from ioctl, try from os.stat()

Under some conditions, ioctl FIGETBSZ can't return real value. We can try to use fallback via os.stat() to get block size. Source of the patch: https://github.com/intel/bmap-tools/commit/17365f4fe9089df7ee9800a2a0ced177ec4798a4#diff-7c3551da8e9821c1b4ea133c74968c0f Signed-off-by: Dogukan Ergun

Re: [OE-core] [oe] Slideshow for FOSDEM

On Thu, Jan 4, 2018 at 1:22 PM, Andreas Müller wrote: > On Wed, Jan 3, 2018 at 6:29 PM, Philip Balister wrote: >> >> On 01/03/2018 09:47 AM, Paul Barker wrote: >> > Hi all, >> > >> > As we've only got one table at FOSDEM this year we're not going to

Re: [OE-core] [PATCH 7/9] avahi: remove explicit avahi-dev RDEPENDS

On 9 January 2018 at 09:01, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 01/08/2018 06:00 PM, Ross Burton wrote: > > -RRECOMMENDS_avahi-dev = "expat-dev libcap-dev libdaemon-dev dbus-dev >> glib-2.0-dev update-rc.d-dev" >> -RRECOMMENDS_avahi-dev_append_libc-glibc = "

Re: [OE-core] Issues with meson in SDK with cross-file

On Tue, Jan 9, 2018 at 3:20 PM, Nirbheek Chauhan wrote: >> If we want to setup a cross-file to use these arguments, we would have to >> generate the cross-file on-the-fly (not good). > > Out of interest, why is that not good? That is precisely what Gentoo > does and it

Re: [OE-core] Issues with meson in SDK with cross-file

(re-sending because the previous one was automatically rejected because I wasn't subscribed) On Tue, Jan 9, 2018 at 5:21 AM, Martin Kelly wrote: > [Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I > added you to get Yocto/OE and meson upstream all on the

[OE-core] [PATCH] terminal.bbclass: use SHELL to interpret the init script

/bin/sh was used to interpret the init script of the new terminal, below issue occurs when SHELL="/bin/bash" and /bin/sh is linked to /bin/dash: function foobar { echo foobar; }; export -f foobar bitbake -c devshell virtual/kernel Then the devshell fails to be started because "export -f xxx" is

Re: [OE-core] Issues with meson in cross-compiling environment

On 01/09/2018 01:51 AM, Martin Kelly wrote: Recently, we got meson added to OE-core as part of Yocto (thanks Alexander Kanavin!). As a part of that integration, we've had to add a few patches that fix problems specific to cross-compilation. You can see them here:

Re: [OE-core] [PATCH 7/9] avahi: remove explicit avahi-dev RDEPENDS

On 01/08/2018 06:00 PM, Ross Burton wrote: -RRECOMMENDS_avahi-dev = "expat-dev libcap-dev libdaemon-dev dbus-dev glib-2.0-dev update-rc.d-dev" -RRECOMMENDS_avahi-dev_append_libc-glibc = " gettext-dev" - -RRECOMMENDS_avahi-dev[nodeprrecs] = "1" - Cool, I was wondering about the necessity of