Re: [OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?

That's testing for offline installation. If $D is not set, it's running on the target. p. On 25 August 2021 22:12:22 BST, "Robert P. J. Day" wrote: > >Quoting Alexander Kanavin : > >> If you show the confusing examples, we could try to figure it out. >> >> Alex >> >> On Wed, 25 Aug 2021 at

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

On Mon, Jun 28, 2021 at 02:10:39PM -0700, Khem Raj wrote: > well, if we can beat the compiler to not complain about using neon on a > non-neon system then yes, but changing float ABI to make compiler happy > seems a bit iffy, since compiler will generate code expecting VFP and that > could trip

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

On Mon, Jun 28, 2021 at 12:42:55PM -0700, Khem Raj wrote: > On Mon, Jun 28, 2021 at 12:10 PM Phil Blundell wrote: > > > > On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote: > > > I still hope that if we can add a proper neon detection patch to meson > >

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote: > I still hope that if we can add a proper neon detection patch to meson > they would be ok to accept it. Why doesn't the runtime detection work in the way that upstream clearly think it ought to? p. -=-=-=-=-=-=-=-=-=-=-=- Links: You

Re: [OE-core] [PATCH] lib: oe: utils: always append host gcc version to NATIVELSBSTRING

Wouldn't it be easier to just force -fPIE on for those users for whom this is a problem? Or force -fPIE off for native everywhere. I'm not sure that doing something based on GCC version is obviously the right plan. p. On 7 June 2021 22:25:58 BST, bkyleruss...@gmail.com wrote: >By having

Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES

On Thu, Feb 11, 2021 at 01:05:20PM +0100, Martin Jansa wrote: > Or you can read it as that it makes sense to build mesa recipe only when > DISTRO supports opengl or vulkan or opengles, It's never been the intent of DISTRO_FEATURES to determine which recipes it "makes sense" to build, above and

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

On Fri, Dec 04, 2020 at 08:30:01AM -0500, Sinan Kaya wrote: > +Richard, > > On 12/4/2020 6:01 AM, Phil Blundell via lists.openembedded.org wrote: > > On Thu, Dec 03, 2020 at 11:28:24PM +, Sinan Kaya wrote: > >> This subclass allows us to easily split a reci

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

On Thu, Dec 03, 2020 at 11:28:24PM +, Sinan Kaya wrote: > This subclass allows us to easily split a recipe into > subpackages. "lib_subpackage" seems a slightly odd name for something that isn't dealing with libraries. What's the etymology of that? > +d.appendVar("PACKAGES", " " + "

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

On Thu, Dec 03, 2020 at 05:35:23PM -0500, Trevor Woerner wrote: > On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell wrote: > > > If we're talking about OpenGLES applications, wouldn't you already have > > opengl in DISTRO_FEATURES? > > > > Not necessarily. > &

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

If we're talking about OpenGLES applications, wouldn't you already have opengl in DISTRO_FEATURES? I'm not sure it makes a lot of sense to introduce a check for dispmanx to oe-core if nothing in oe-core ever defines that feature. p. On 3 December 2020 13:35:26 GMT, Trevor Woerner wrote:

Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package

On Thu, Jun 04, 2020 at 01:05:30PM -0700, Andre McCurdy wrote: > The fix being proposed is simply to always leave the config file in > the rootfs, so it's always there when ldconfig is run at build time. > Doing so seems safe enough. Since the config file is only parsed by > ldconfig, there's no

Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package

On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote: > I understand the concern, I am a little torn on this as adding in too > many different controls and options complicates the test matrix and > makes things harder for users. > > You're effectively suggesting a new DISTRO_FEATURE to

Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package

On Tue, Jun 02, 2020 at 02:17:22PM +0200, Rasmus Villemoes wrote: > In case of a read-only rootfs, one could add some logic to remove them > if one really wants to shave those few dozens of bytes off. Note that there's also a slight runtime performance penalty associated with having these files

Re: [OE-core] [PATCH] update-alternatives: introduce new package as a opkg-utils spin-off

On Tue, Jun 02, 2020 at 09:43:45PM +0200, Gregor Zatko wrote: > - if you take a look at > http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/update-alternatives > you'll simply see it's a shellscript; if we wanted to have it without > bash we'd need a C++ > implementation, am I right? No,

Re: [OE-core] [PATCH] update-alternatives: introduce new package as a opkg-utils spin-off

On Tue, Jun 02, 2020 at 09:09:25PM +0200, Gregor Zatko wrote: > In some cases there is a need for update-alternatives script which gets built > within opkg-utils recipe into a standalone package. However, this causes to > many unnecessary dependencies, including Python, bc, OpenSSL etc. to be

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

On Thu, May 28, 2020 at 10:38:15AM -0700, Andre McCurdy wrote: > And where does it leave OLDEST_KERNEL (currently set to 3.2.0)? If > even kernel 4.1 is too old to be used with OE master then > OLDEST_KERNEL looks like it should be updated to avoid giving users > with older kernels false hope.

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

On Thu, May 28, 2020 at 12:30:13PM -0700, Andre McCurdy wrote: > What I was trying to get at is why you felt that bringing up the fact > the kernel 4.1 was released at around the time gcc 5 was current is > important? Agreed, I think this is a red herring. One of my current targets is in fact

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

On Wed, May 27, 2020 at 05:02:00PM -0700, Khem Raj wrote: > https://github.com/torvalds/linux/commit/052876f8e5aec887d22c4d06e54aa5531ffcec75 > > this change e.g. in userspace checks for UINPUT_VERSION and decides to > use one method > or legacy to setup the device but this is really not gonna

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > and building userspace against way newer kernel-headers with older > kernel underneath has unintended > consequences. Can you be more specific? If this doesn't work, it's just a bug and should be fixed. What problems are you having?

Re: [OE-core] [PATCH] glibc: move ld.so.conf back to main package

On Mon, May 18, 2020 at 02:12:43PM +0200, Rasmus Villemoes wrote: > I'm certainly open to other ways of solving this. But can we agree that > it is a bug that the ldconfig done at build-time does not take > /etc/ld.so.conf.d/* into account, and that that should not depend on > whether one has

Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe

On Wed, Nov 27, 2019 at 02:32:46PM +, Ross Burton wrote: > On 26/11/2019 11:59, Phil Blundell wrote: > > On Mon, Nov 25, 2019 at 12:07:25PM +, Ross Burton wrote: > > > If you can send a patch sooner rather than later for lrzsz to fix the > > > buil

Re: [OE-core] [PATCH] systemd-conf: add timesyncd.conf

On Tue, Nov 26, 2019 at 11:02:15PM +0300, Cengiz Can wrote: > 1) Does Google allow their time servers to be directly used? I believe so. I couldn't immediately find anything on their website that said differently. > 2) Can we apply for a vendor name like "oe" so at least they can >

Re: [OE-core] [PATCH] systemd-conf: add timesyncd.conf

On Tue, Nov 26, 2019 at 04:39:43PM +0300, Cengiz Can wrote: > This patch adds a default timesyncd.conf with Google's time servers > moved to Fallback and pool.ntp.org as primary time servers. The "advice for vendors" on the ntp.org website specifically says: Do not use the standard

Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe

On Tue, Nov 26, 2019 at 12:59:54PM +0100, Phil Blundell wrote: > On Mon, Nov 25, 2019 at 12:07:25PM +, Ross Burton wrote: > > If you can send a patch sooner rather than later for lrzsz to fix the build > > with modern gettext then that would be *awesome*, as this recipe is the s

Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe

On Thu, Nov 21, 2019 at 10:10:30AM +, Richard Purdie wrote: > On Thu, 2019-11-21 at 09:24 +, Ross Burton wrote: > > 2) the source is positively ancient and building it on modern linux is > > getting harder over time Just to put this in perspective, I tried fetching lrzsz-1.20.0.tar.gz

Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe

On Wed, Nov 20, 2019 at 11:12:37PM +0100, Alexander Kanavin wrote: > The gettext problem is the immediate reason, but the broader reason is that > the code is not maintained, and we should try to avoid burdening the > project with unmaintained code. There's already 8 custom patches fixing > issues

Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe

On Wed, Nov 20, 2019 at 09:00:28PM +0100, Alexander Kanavin wrote: > Do you want to maintain it? Protocols are not changing, but the software > that lrzsz depends on is changing. > > Your first task would be making it build with the latest version of > gettext, the branch containing that is here:

Re: [OE-core] [PATCH] go, go-common: Add missing quotes in shell variable assignment

On Fri, 2019-02-01 at 10:20 +, Richard Purdie wrote: > > go tool dist: cannot invoke C compiler "gcc ": exec: "gcc ": executable > > file not found in $PATH Oh, huh, I guess this is an example of getting the (approximately) right result for the wrong reasons. I'll have to think about that

[OE-core] [PATCH] go, go-common: Add missing quotes in shell variable assignment

Otherwise we will lose if ${BUILD_CC} happens to contain a space. Signed-off-by: Phil Blundell --- meta/recipes- devtools/go/go-common.inc | 2 +- meta/recipes- devtools/go/go_1.9.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/go/go-common.inc b

Re: [OE-core] a few more picky questions about COMPATIBLE_MACHINE usage

On Mon, 2017-02-27 at 09:09 -0500, Robert P. J. Day wrote: >  # webkit-efl isn't available for < armv7a >  COMPATIBLE_MACHINE = "(-)" >   COMPATIBLE_MACHINE_x86 = "(.*)" >   COMPATIBLE_MACHINE_x86-64 = "(.*)" >   COMPATIBLE_MACHINE_armv7a = "(.*)" > >   first, that comment seems out of date as it

Re: [OE-core] multipath-tools on arm (was: Re: State of bitbake world, Failed tasks 2017-02-08)

On Tue, 2017-02-14 at 16:35 +0100, Patrick Ohly wrote: > {standard input}: Assembler messages: > {standard input}:80: Error: shifts in CMP/MOV instructions are only > supported in unified syntax -- `mov r12,r12,ror#3' > {standard input}:80: Error: shifts in CMP/MOV instructions are only >

Re: [OE-core] RSS difficulties

On Mon, 2017-02-06 at 14:44 +, Phil Blundell wrote: > But sadly the contents of libecj-bootstrap-native doesn't actually > show up in gnujaf-native's recipe-sysroot-native. A bit of further sleuthing reveals that although this problem only started with rss the blame lies somewher

Re: [OE-core] RSS difficulties

By the way, this message:    msgbuf.append("Skipping setscene dependency %s for installation into the sysroot")   is not as illuminating as it could be. I suppose it wants "% setscenedeps[datadep][0])" on the end. :-} p. -- ___

Re: [OE-core] RSS difficulties

On Mon, 2017-02-06 at 14:27 +, Richard Purdie wrote: > What happens if you set DEPENDS? With DEPENDS I do at least get some entries for ecj-bootstrap-native in task-depends.dot. The relevant ones seem to be: "gnujaf-native.do_prepare_recipe_sysroot" -> "ecj-bootstrap-

Re: [OE-core] RSS difficulties

On Fri, 2017-02-03 at 12:29 +, Phil Blundell wrote: > Ah, right, thanks.  The particular piece of magic I was missing was: > > # Nothing need depend on libc-initial/gcc-cross-initial > if "-initial" in taskdependees[task][0]: >

Re: [OE-core] RSS difficulties

On Fri, 2017-02-03 at 11:20 +, Richard Purdie wrote: > > It comes down to what setscene_depvalid() in sstate.bbclass returns. > If > that returns False a given dependency is installed, it if returns > True, > it is skipped and not installed. > > Reading that function should give some clues

[OE-core] RSS difficulties

I'm having a few problems adapting our build setup to work with recipe specific sysroots. More specifically, I am finding it difficult to get the correct set of components installed into the recipe-sysroot in all cases. In some cases I am getting too much (which causes build failures if oe

Re: [OE-core] [PATCH] busybox: update flock behavior to match upstream

On Thu, 2016-04-21 at 12:24 +0300, Maxin B. John wrote: > +- > +-if (argv[0]) > +-return spawn_and_wait(argv); > +- > ++if (argv[0]) { > ++cmd_args[0] = getenv("SHELL"); > ++if (!cmd_args[0]) > ++cmd_args[0] = (char*)DEFAULT_SHELL; > ++

Re: [OE-core] [PATCH 2/2] glibc: Upgrade to 2.25

On Fri, 2017-01-13 at 10:52 -0800, Khem Raj wrote: > > I have sent a patchset with IFUNC change reverted for now until its > fixed. Yeah, I saw that.  But in light of recent developments it seems like it might be better to revert the earlier NPTL patch that apparently introduced the real

Re: [OE-core] [PATCH 2/2] glibc: Upgrade to 2.25

On Wed, 2017-01-11 at 12:19 +, Burton, Ross wrote: > > > The gdk-pixbuf link does use -lpthread, is this saying that libpng should be linked against pthread too?  I can replicate on demand if you have any suggestions. > > So, amusingly, it now appears that libpng in pthread-using programs

Re: [OE-core] [PATCH 2/2] glibc: Upgrade to 2.25

On Wed, 2017-01-11 at 08:21 -0800, Khem Raj wrote: > > This is showing when executing target binaries in qemu here I > believe. One > workaround we could try is to use LD_PRELOAD of libpthread.so.0, that > might get us over this error, but the issue still may manifest on > target apps > using

Re: [OE-core] [PATCH 2/2] glibc: Upgrade to 2.25

On Wed, 2017-01-11 at 12:19 +, Burton, Ross wrote: > > > On 11 January 2017 at 03:51, Khem Raj wrote: > > > > Signed-off-by: Khem Raj > > > This fails when building gdk-pixbuf for x86-64 with gobject- introspection enabled: > > > > > > > > > > > > >

Re: [OE-core] [PATCH 2/2] glibc: Upgrade to 2.25

On Tue, 2017-01-10 at 19:51 -0800, Khem Raj wrote: > Signed-off-by: Khem Raj The log message for this commit is a bit misleading.  Glibc 2.25 has not been released (and the release is not scheduled for another three weeks) and we clearly can't upgrade to a version that

Re: [OE-core] [PATCH 1/1] rootfs-postcommands.bbclass: sort passwd entries

On Sat, 2017-01-07 at 22:52 +, Richard Purdie wrote: > On Sat, 2017-01-07 at 20:00 +0100, Patrick Ohly wrote: > > > > On Sat, 2017-01-07 at 09:59 +, Phil Blundell wrote: > > > > > > That sounds like a good idea.  And in that case, maybe it would >

Re: [OE-core] [PATCH 1/1] rootfs-postcommands.bbclass: sort passwd entries

On Sat, 2017-01-07 at 09:06 +0100, Patrick Ohly wrote: > Yes, but there's already a solution for that problem: > useradd-staticids.bbclass > > I was assuming that someone who wants identical files is already > using > that. Should it be mentioned in a comment next to the new feature? That

Re: [OE-core] [PATCH 1/1] rootfs-postcommands.bbclass: sort passwd entries

On Thu, 2017-01-05 at 16:38 +0100, Patrick Ohly wrote: > The /etc passwd files in a rootfs consist of the default entries from > base-passwd plus anything that gets added by preinst scripts or > extrausers.bbclass. > > The execution order of preinst scripts is not perfectly > deterministic, > or

Re: [OE-core] [PATCH 3/6] libglu: add opengl to REQUIRED_DISTRO_FEATURES

On Wed, 2017-01-04 at 15:57 -0700, Christopher Larson wrote: > >  # Requires libGL.so which is provided by mesa when x11 in > DISTRO_FEATURES > -REQUIRED_DISTRO_FEATURES = "x11" > +REQUIRED_DISTRO_FEATURES = "x11 opengl" I sort of have the sense that something has gone a bit wrong with the way

Re: [OE-core] [PATCH] lttng-ust: Patch python shebang appropriately for native builds

On Wed, 2016-12-14 at 15:38 -0800, Khem Raj wrote: > On Wed, Dec 14, 2016 at 1:38 PM, Phil Blundell <p...@pbcl.net> wrote: > > If we are building a native package then ${bindir}/python3 is not > > guaranteed > > to be available, and if it is available then it

[OE-core] [PATCH] lttng-ust: Patch python shebang appropriately for native builds

-by: Phil Blundell <ph...@gnu.org> --- meta/recipes-kernel/lttng/lttng-ust_git.bb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-kernel/lttng/lttng-ust_git.bb b/meta/recipes-kernel/lttng/lttng-ust_git.bb index 5869093..df22352 100644 --- a/meta/recipes-kernel

Re: [OE-core] [PATCH] libbsd 0.8.3: BBCLASSEXTEND to native and nativesdk

On Fri, 2016-11-04 at 23:24 +, Burton, Ross wrote: > > No, I checked the files in /usr on the host, as this is a native build it should be linking against the host libc. > > $ grep -r getrandom > x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom >

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

On Fri, 2016-11-04 at 16:55 -0700, Khem Raj wrote: > > yes I meant <= v5, it should work usually, I am just thinking its a > untested > option, it may not be as bad as I think but some testing might be > useful Well, I admit I haven't looked at the actual code, but from the comments in the patch

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

On Fri, 2016-11-04 at 11:22 -0700, Khem Raj wrote: > > > On 11/4/16 2:07 AM, Li Zhou wrote: > > > > The swpb in macro MUTEX_SET will cause "undefined instruction" > > error > > on the new arm arches which don't support this assembly instruction > > any more. If use ldrex/strex to replace swpb,

Re: [OE-core] SERIAL_CONSOLE versus SERIAL_CONSOLES?

On Mon, 2016-10-17 at 07:57 -0400, Robert P. J. Day wrote: >   so is it a fair statement that, pedantically, i might as well just > define everything in terms of SERIAL_CONSOLES and think that way? > Yes.  SERIAL_CONSOLE predates SERIAL_CONSOLES and remains supported in the configuration for

Re: [OE-core] File conflicts in DL_DIR

On Wed, 2016-10-12 at 11:03 -0700, Matt Madison wrote: > I use ";downloadfilename=${BPN}-${PV}.tar.gz" to deal with this > problem, and it's worked well for me. Thanks, that works for me. p. -- ___ Openembedded-core mailing list

[OE-core] File conflicts in DL_DIR

I just ran into an annoying problem with two recipes whose upstreams both use the same poor naming scheme for their downloadable tarballs which causes the sources to collide in DL_DIR.  One of them is eudev, which has: SRC_URI = "https://github.com/gentoo/${BPN}/archive/v${PV}.tar.gz This shows

Re: [OE-core] [PATCH] kernel: Permit overriding of KERNEL_IMAGETYPE_FOR_MAKE

On Thu, 2015-11-05 at 14:47 +, Mike Crowe wrote: > Commit a1690131691507bbf5853540229b3ad775b836bf removed the ability > of > recipes to set KERNEL_IMAGETYPE_FOR_MAKE. This can be fixed by only > setting KERNEL_IMAGETYPE_FOR_MAKE if it doesn't already have a > value. This should hopefully be a

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

On Tue, 2016-10-11 at 14:56 +0200, Mark Hatle wrote: > > This was the first instance of the patch.  However after discussing > the issue w/ > Khem Raj (in person), we came to the conclusion that we did want a > way to permit > people to modify the plural.y via a patch, otherwise someone could >

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

On Tue, 2016-10-11 at 16:02 +0800, Yuanjie Huang wrote: > From: Yuanjie Huang > > Source file plural.c might be updated with bison from plural.y, touch > it > before applying patches so that this file is consistent across > builds. I think it would be better to just

Re: [OE-core] [PATCH] update-rc.d.bbclass: check that init script exists before running it

On Thu, 2016-10-06 at 16:46 +0300, Markus Lehtonen wrote: > It was moved to prerm earlier to fix some other problems: > http://git.openembedded.org/openembedded-core/commit/meta/classes/upd > ate-al > ternatives.bbclass?id=2a5484a90513b58c829a916bfe5268a0fde3512a The commit message for that

Re: [OE-core] [PATCH] update-rc.d.bbclass: check that init script exists before running it

On Thu, 2016-10-06 at 11:49 +0300, Markus Lehtonen wrote: > On Wed, 2016-10-05 at 16:51 +0200, Andreas Oberritter wrote: > > Hello Markus, > > > > On 05.10.2016 16:11, Markus Lehtonen wrote: > > > Check that the init script that is going to be called in the > > > prerm() > > > script really

Re: [OE-core] [PATCH] x264: add textrel to INSANE_SKIP to skip the warning

On Wed, 2016-09-21 at 13:44 +0530, sujith h wrote: > > The above mentioned functions are part of .S files. OK.  In that case, please just mention in the commit message that you can't easily get rid of the TEXTRELs because they are coming from assembler source files that would (I assume) need

Re: [OE-core] [PATCH] x264: add textrel to INSANE_SKIP to skip the warning

On Thu, 2016-09-15 at 12:22 +0530, Sujith H wrote: > From: Fahad Usman > > This change help fix the warning message: > > x264/r2491+gitAUTOINC+c8a773ebfc-r0/packages- > split/x264/usr/lib/libx264.so.144' has relocations in .text [textrel] > > Adding textrel to

Re: [OE-core] [Openembedded-architecture] Removal of uclibc from oe-core?

On Mon, 2016-07-18 at 23:01 +0100, Burton, Ross wrote: > Now that musl is fairly mature I think it's time to take uclibc out to > pasture, where the pasture is possibly called meta-uclibc. I think this is a splendid idea. p. -- ___

Re: [OE-core] [PATCH] meta: remove obsolete architectures

On Fri, 2016-04-01 at 10:59 +0100, Phil Blundell wrote: > On Fri, 2016-04-01 at 10:06 +0100, Ross Burton wrote: > > Remove ancient and obsolete architectures from openembedded-core, they've no > > real users and are causing complications that can be now removed. > >

Re: [OE-core] [PATCH] meta: remove obsolete architectures

On Fri, 2016-04-01 at 10:06 +0100, Ross Burton wrote: > Remove ancient and obsolete architectures from openembedded-core, they've no > real users and are causing complications that can be now removed. It seems a bit harsh, or possibly wishful thinking on Intel's part, to describe most of these as

Re: [OE-core] [PATCH V2] psmisc: Remove including sys/user.h and __WORDSIZE

On Wed, 2016-03-30 at 17:56 +, Khem Raj wrote: > +Subject: [PATCH] Use UINTPTR_MAX instead of __WORDSIZE > + > +Do not include sys/user.h since it conflicts with > +pt_regs struct from kernel APIs in asm/ptrace.h > + > +Signed-off-by: Khem Raj This description (and the

Re: [OE-core] [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote: > Either way it shouldn't be a concern for the CPU tuning files. > Building Thumb2 for an armv8a CPU is really just an extension of > "optimise for size" and we don't include -Os, -O2, etc options in the > CPU tuning files. Yes, agreed. In

Re: [OE-core] [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

On Tue, 2016-03-29 at 18:59 +0300, Dragomir Daniel wrote: > > arch-arm8a.inc add now support for armv8-A processors which support 2 > states: > 32-bit and 64-bit states. It makes more sense to have support for > both states > in the same inc file because both refer to the same arch.  OK.  And I

Re: [OE-core] [PATCH v4 3/5] weston: Add XWayland support

On Mon, 2016-03-28 at 18:00 -0500, Tom Hochstein wrote: > Add a new distro feature 'xwayland' to enable XWayland support. Why does this need to be a DISTRO_FEATURE? p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org

Re: [OE-core] [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote: > For AArch64 state, the default tune is aarch32 and include which > include just the aarch64 feature. I don't really understand what this sentence is trying to say. Can you re-phrase it so as to be more accessible to non-experts? >

Re: [OE-core] [PATCH] gcc-configure-common.inc: duplicate armv7a over-ride for armv8a

On Thu, 2016-03-24 at 15:22 -0700, Khem Raj wrote: > > On Mar 24, 2016, at 11:32 AM, Phil Blundell <p...@pbcl.net> wrote: > > > > On Thu, 2016-03-24 at 10:37 -0700, Andre McCurdy wrote: > >> > >> Renaming armv8a -> aarch32 is going to affect a

Re: [OE-core] [PATCH] gcc-configure-common.inc: duplicate armv7a over-ride for armv8a

On Thu, 2016-03-24 at 10:37 -0700, Andre McCurdy wrote: > > Renaming armv8a -> aarch32 is going to affect almost every line in > the patch. We should probably drop the current patch from master- > next. "AArch32" applies retrospectively to all older versions of the ARM architecture as well, so

Re: [OE-core] [PATCH] nss: Explicitly link with libssp on musl/ppc

On Thu, 2016-03-24 at 15:24 +, Khem Raj wrote: > Signed-off-by: Khem Raj This is all a bit obscure.  Please add an explanation of why this is needed specifically by ppc (and not other architectures) to the commit message. Also, the subject says "musl" but the patch

Re: [OE-core] [PATCH] insane.bbclass: tighten lib_re and exec_re patterns to avoid false positive

On Wed, 2016-03-23 at 17:59 +, Burton, Ross wrote: > > On 23 March 2016 at 17:56, Phil Blundell <p...@pbcl.net> wrote: > > > lib_re would match files like "/libsoletta.so.0.0.1-gdb.py" which > > are > > > not valid library filenames. > >

Re: [OE-core] [PATCH] insane.bbclass: tighten lib_re and exec_re patterns to avoid false positive

On Wed, 2016-03-23 at 08:54 -0700, Bill Randle wrote: > lib_re would match files like "/libsoletta.so.0.0.1-gdb.py" which are > not valid library filenames. What are the consequences of it matching things that are not libraries? > Tighten up the re for lib_re and exec_re so they match only valid

Re: [OE-core] [PATCH 4/4] linux-firmware: Break out some additional firmware

On Tue, 2016-03-22 at 22:37 +, Burton, Ross wrote: > > > On 22 March 2016 at 21:56, Saul Wold wrote: > > > | linux-firmware-iwlwifi-7265D > > | *** Error: Package name contains illegal characters, > (other than > > [a-z0-9.+-]) >

[OE-core] X.org licenses

This morning it came to my notice that libxdmcp, and a bunch of other files (mostly, though not exclusively, in xorg-libs) contain things like: LICENSE = "MIT-style" It's not very clear to me whether "MIT-style" is meant to mean "an unspecified license in the same general style as the MIT one"

Re: [OE-core] X.org licenses

On Wed, 2016-03-16 at 12:59 +, Burton, Ross wrote: > Ditto, MIT-style and MIT-X all map to MIT. > > Considering xorg-lib-common.inc already sets LICENSE="MIT-X" and these > recipes are overriding that assignment, we should probably remove all > instances of MIT-style from the xorg recipes as

Re: [OE-core] [PATCH RESEND 1/4] ARM: handle missing thumb suffix

On Wed, 2016-03-16 at 10:34 +0100, Jens Rehsack wrote: > When enabling tune for arm926ejs, poky optionally appends suffixes for > thumb and dsp support. Since sometimes arm926ejse (ARM code) and sometime > arm926ejste (thumb code) is used in PACKAGE_ARCH, allow both. Personally I think this is a

Re: [OE-core] [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

On Thu, 2016-03-03 at 11:11 -0800, Andre McCurdy wrote: > All the good work and effort that Martin has been doing keeping the > Thumb1 builds alive could then perhaps be redirected to testing Thumb2 > (or some other case which isn't covered by the default oe-core CI > builds). Yes, agreed. Given

Re: [OE-core] [PATCH] boost.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

On Wed, 2016-02-24 at 16:48 -0800, Andre McCurdy wrote: > The original over-ride dates back to 2009: > >   http://git.openembedded.org/openembedded-core/commit/?id=43e94412c4 > 5b4b79485a64010c76d89b245bb235 > > There are no obvious issues seen now when building boost in thumb2 > for Cortex A15.

Re: [OE-core] [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

On Thu, 2016-03-03 at 14:18 +0100, Martin Jansa wrote: > On Thu, Mar 03, 2016 at 01:02:35PM +0000, Phil Blundell wrote: > > On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote: > > > -ARM_INSTRUCTION_SET = "arm" > > > +ARM_INSTRUCTION_SET_armv4 = "ar

Re: [OE-core] [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote: > -ARM_INSTRUCTION_SET = "arm" > +ARM_INSTRUCTION_SET_armv4 = "arm" > +ARM_INSTRUCTION_SET_armv5 = "arm" Although I agree that this is a net improvement over the old code in almost all cases, this patch is not quite right.  The reason for

Re: [OE-core] Recovering GCC 4.8

On Fri, 2016-02-19 at 07:37 +0100, Gary Thomas wrote: > | checking for suffix of object files... configure: error: in > `/local/p0381_2016-02-19/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libgcc-initial/4.8.4-r0/gcc-4.8.4/build.arm-amltd-linux-gnueabi.arm-amltd-linux-gnueabi/libgcc': > |

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

On Thu, 2016-02-18 at 13:33 -0800, Andre McCurdy wrote: > Aside from automated detection of such problems, what's the best fix > in this particular case? > > 1) Use LEAD_SONAME to force renaming, even in the case when the > libsoup-2.4 package contains both shared libs. > > 2) Split

Re: [OE-core] [PATCH] lib/qa.py: raise ValueError if file isn't an ELF

On Mon, 2016-02-15 at 17:50 +, Ross Burton wrote: > Instead of raising a generic Exception that can't be handled specifically, > raise > a ValueError. If what you want is an exception to mean "this file isn't actually ELF", how about defining a new exception class InvalidElfError or

Re: [OE-core] [PATCH 1/9] distutils: Consider S != B case

On Wed, 2016-02-10 at 17:43 +, Khem Raj wrote: > +cwd=$PWD;cd ${S} > +STAGING_INCDIR=${STAGING_INCDIR} \ > +STAGING_LIBDIR=${STAGING_LIBDIR} \ > +BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \ > +${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}

Re: [OE-core] [PATCH] iptables: Add systemd support

Also, please don't hardcode /usr/libexec/iptables or /etc/default/iptables in the service files. p. On Thu, 2016-02-04 at 22:14 +0100, Pau Espin Pedrol wrote: > Please use ${systemd_system_unitdir} instead of > ${systemd_unitdir}/system > > Pau Espin Pedrol > mail/jabber: pespin.s...@gmail.com

Re: [OE-core] [PATCH v2] udev: add runtime dependencies for udev-cache

On Thu, 2016-02-04 at 13:01 -0800, Khem Raj wrote: > > On Feb 4, 2016, at 12:12 PM, Ricardo Neri > > wrote: > > inherit autotools pkgconfig update-rc.d ptest > > RDEPENDS_${PN}-ptest += "make perl python" > > +RDEPENDS_${PN}-cache += "gzip findutils” > >

Re: [OE-core] [PATCH 8/8] boost: Fix build on soft-float ABI arm systems

On Mon, 2016-02-01 at 05:08 +, Khem Raj wrote: > + BOOST_FPE_ALL = MCW_EM, > +-#elif defined(BOOST_NO_FENV_H) || defined(BOOST_CLANG) > ++#elif defined(BOOST_NO_FENV_H) || defined(BOOST_CLANG) \ > ++|| defined(__ARM_PCS) > + BOOST_FPE_ALL = 1, This looks a bit bogus.

Re: [OE-core] Default value for FULL_OPTIMIZATION

On Tue, 2016-02-02 at 22:17 -0800, Khem Raj wrote: > -pipe does speed up build time so its an optimization. How much does it really speed it up by? I seem to recall the effect was fairly negligible, but maybe I am remembering that wrong. p. -- ___

Re: [OE-core] [PATCH 8/8] boost: Fix build on soft-float ABI arm systems

On Wed, 2016-02-03 at 12:58 -0800, Khem Raj wrote: > On Wed, Feb 3, 2016 at 12:42 PM, Phil Blundell <p...@pbcl.net> wrote: > I think it might be true > > that some libraries don't implement fesetenv() when using softfp (i.e. > > no VFP instructions at all) but that is

Re: [OE-core] Default value for FULL_OPTIMIZATION

On Wed, 2016-02-03 at 12:51 -0800, Khem Raj wrote: > On Wed, Feb 3, 2016 at 12:48 PM, Phil Blundell <p...@pbcl.net> wrote: > > On Tue, 2016-02-02 at 22:17 -0800, Khem Raj wrote: > >> -pipe does speed up build time so its an optimization. > > > > How much do

Re: [OE-core] Default value for FULL_OPTIMIZATION

On Wed, 2016-02-03 at 12:59 -0800, Khem Raj wrote: > in systems of this age it should be yet. Sorry, I didn't really understand that comment. For what it's worth, as a very quick and fairly unscientific comparison, I did "time make -j4" in a glibc tree and got: real1m38.812s user

Re: [OE-core] Default value for FULL_OPTIMIZATION

On Tue, 2016-02-02 at 14:26 +0100, Pascal Bach wrote: > I'm not sure if the documentation is wrong or if the default set in > bitbake.conf is incorrect. > Maybe somebody can shed some light on this. FULL_OPTIMIZATION in bitbake.conf did use to match what the documentation says (or at least, was

Re: [OE-core] [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch

On Mon, 2016-02-01 at 17:23 -0500, Randy MacLeod wrote: > Do you remember why this patch was needed? The comments in the patch provide a fairly clear explanation of what problem it was trying to solve. But I agree with Andre that this cure is in fact worse than the original disease. In any

Re: [OE-core] [PATCH] xterm: revert FILES_PN change from recent package uprev

On Sun, 2016-01-31 at 14:56 -0500, Paul Gortmaker wrote: > diff --git a/meta-oe/recipes-graphics/xorg-app/xterm_320.bb > b/meta-oe/recipes-graphics/xorg-app/xterm_320.bb > index f67d890abcae..10b75fca32db 100644 > --- a/meta-oe/recipes-graphics/xorg-app/xterm_320.bb > +++

Re: [OE-core] [PATCH] git: add site_perl to packaged files to fix QA install error

On Sun, 2016-01-31 at 13:27 -0500, Paul Gortmaker wrote: > FILES_${PN}-perltools += " \ > ${PERLTOOLS} \ > ${libdir}/perl \ > +${libdir}/site_perl \ > ${datadir}/perl \ It seems a bit wrong for git (or any other package) to be installing itself into site-perl. That path is

Re: [OE-core] [PATCH] xterm: revert FILES_PN change from recent package uprev

On Sun, 2016-01-31 at 16:51 -0500, Paul Gortmaker wrote: > If i go into poky/meta-openembedded, and crack open .git/config I'll see > the source git://git.openembedded.org/meta-openembedded listed. So I > think at least at that point, I need to look at OE lists and not yocto > lists. But looking

Re: [OE-core] Glibc 2.24 _might_ require minimum kernel version 3.2

[cross-posting trimmed...] On Sun, 2016-01-31 at 09:41 -0800, Khem Raj wrote: > This is FYI, as I have sent a RFT for glibc 2.24, Um, have you? 2.23 hasn't been released yet and I think that's the version you sent an RFT for. 2.24 is still some way off. p. --

  1   2   3   4   5   6   7   8   9   10   >