Re: [OE-core][PATCH 0/4] Import recipes from meta-python
On Fri, May 15, 2020, 1:32 PM Khem Raj wrote: > > > On 5/15/20 12:12 PM, Joshua Watt wrote: > > > > On 5/15/20 2:05 PM, Richard Purdie wrote: > >> On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote: > >>> I see Richard has merged these to master-next, thanks! > >>> And thanks Joshua for volunteering to maintain these recipes :) > >>> I submitted removal patches to meta-python. > >>> > >>> So, it is good we are getting this extra dependency resolved in > >>> master. The > >>> question is - can we get these backported to dunfell, does it qualify? > >>> > >>> Otherwise Jon wanted to finally branch off meta-arm into dunfell > >>> today and > >>> we'll have to live with it until gatesgarth. > >> I put them into -next so we could test them, see if the autobuilder had > >> any surprises. Good news is there weren't any. > >> > >> The question still remains whether this is the best approach or not and > >> some people I talked to were not convinced that a consensus had been > >> reached. > >> > >> The question I guess is how widely used is optee and does it warrant > >> adding this? Its a little ironic the thing people want is trusted- > >> firmware... > > > > FWIW, after having gone through the exercise of pulling in TF-A into > > qemuarm64, I think I've been convinced that op-tee and TF-A belong > > together since they are sometimes tightly integrated together (something > > I didn't realize before). As such, having both in the same layer makes > > sense. Even if TF-A was in oe-core, you'd probably want op-tee also, > > which means the python modules would have to be there anyway. I think we > > can still have the discussion about moving the whole lot over there, but > > we don't need to do that now, and moving the python recipes at least > > cuts out the meta-python dependency. > > > > My last concern was testing of optee, since there was no platform that > > could build it by default, but I fixed that by implemented support for a > > qemuarm64-based machine that's defined in meta-arm which uses TF-A + > > optee + u-boot and can successful boot using TF-A and passes the op-tee > > unit tests, so I don't have any concern about that anymore. > > > > I think getting oe-core qemuarm64 boot with uboot+TF-A as an option > sounds good, and if thats more common solution that armv8 devices are > following then perhaps would make sense to have this tested in core too. > But I guess that can be ironed out. As such python deps I think are good > for dunfell too, we have to ensure meta-python removal happens in > dunfell as well. > +1 on keeping testing this in core as the end goal, I also agree that this would qualify for the Dunfell changes in both oe-core and meta-python since its the first step in that direction Alejandro > >> > >> Cheers, > >> > >> Richard > >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138372): https://lists.openembedded.org/g/openembedded-core/message/138372 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [oe] OpenEmbedded Happy Hour
See you all from down under ! Cheers Ankur On Sun, May 17, 2020, 2:27 AM Marco Cavallini [KOAN] < m.cavall...@koansoftware.com> wrote: > On 15/05/20 17:56, Philip Balister wrote: > > I've made a wiki page to track these: > > > > https://www.openembedded.org/wiki/Happy_Hours > > > > Then next one is scheduled for 2100 UTC on May 27. This is late evening > > for Europe and morning for New Zealand, so hopefully we see some > > different faces. The meeting info is on the wiki page. > > > > There is no set agenda, so bring some projects to talk about with the > > community. > > > > > > Philip > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+27=20200527T21=%3A=1 > > -- > Marco > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138371): https://lists.openembedded.org/g/openembedded-core/message/138371 Mute This Topic: https://lists.openembedded.org/mt/74261148/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 0/4] Import recipes from meta-python
On Sat, May 16, 2020 at 1:24 PM Andrey Zhizhikin wrote: > On Sat, May 16, 2020 at 10:10 PM Adrian Bunk wrote: > > On Sat, May 16, 2020 at 07:54:32PM +, Peter Kjellerstedt wrote: > > > > > > > > meta-openembedded/meta-python has a higher layer priority than OE-core. > > > > > > > > Adding higher upstream versions of these recipes to a lower-priority > > > > layer in a stable series is a potential source for weird problems. > > > > > > I would assume they'd be removed from meta-python at the same time > > > they are added to meta. > > > > "at the same time" is complicated since OE-core has releases, > > but meta-openembedded is just a branch. > > > > I would also assume that not all users of stable series are updating > > meta-openembedded to the latest on the dunfell branch at the same > > time as OE-core, some users might end up updating one but never > > updating the other one. > > That I believe would be a terrible mistake when people opt-in to take > a layer, but never care about updating it... :( > > On the contrary, a quick run of "bitbake-layers show-overlayed" > exhibits the following on the [master] of both OE-Core and > meta-openembedded: > = > python3-cython: > meta-python 0.29.14 > meta 0.29.16 > python3-dbusmock: > meta-python 0.16.7 > meta 0.19 > python3-docutils: > meta-python 0.15.2 > meta 0.16 > python3-pyparsing: > meta-python 2.4.6 > meta 2.4.7 > = > > Judging be versions, it looks like OE-Core recipes are maintained, but > in meta-openembedded they are left on the side... Right, and that's the problem. Anyone using meta-python will continue to use the older recipes and not see the updates (since meta-python is a higher priority layer than oe-core). The right way to have done this would have been to update the recipes in meta-python before merging to oe-core, not merging to oe-core and then immediately updating them there. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138370): https://lists.openembedded.org/g/openembedded-core/message/138370 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 0/4] Import recipes from meta-python
On Sat, May 16, 2020 at 10:10 PM Adrian Bunk wrote: > > On Sat, May 16, 2020 at 07:54:32PM +, Peter Kjellerstedt wrote: > > > > > > meta-openembedded/meta-python has a higher layer priority than OE-core. > > > > > > Adding higher upstream versions of these recipes to a lower-priority > > > layer in a stable series is a potential source for weird problems. > > > > I would assume they'd be removed from meta-python at the same time > > they are added to meta. > > "at the same time" is complicated since OE-core has releases, > but meta-openembedded is just a branch. > > I would also assume that not all users of stable series are updating > meta-openembedded to the latest on the dunfell branch at the same > time as OE-core, some users might end up updating one but never > updating the other one. That I believe would be a terrible mistake when people opt-in to take a layer, but never care about updating it... :( On the contrary, a quick run of "bitbake-layers show-overlayed" exhibits the following on the [master] of both OE-Core and meta-openembedded: = python3-cython: meta-python 0.29.14 meta 0.29.16 python3-dbusmock: meta-python 0.16.7 meta 0.19 python3-docutils: meta-python 0.15.2 meta 0.16 python3-pyparsing: meta-python 2.4.6 meta 2.4.7 = Judging be versions, it looks like OE-Core recipes are maintained, but in meta-openembedded they are left on the side... > > > //Peter > > cu > Adrian > -- Regards, Andrey. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138369): https://lists.openembedded.org/g/openembedded-core/message/138369 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 0/4] Import recipes from meta-python
On Sat, May 16, 2020 at 07:54:32PM +, Peter Kjellerstedt wrote: > > > > meta-openembedded/meta-python has a higher layer priority than OE-core. > > > > Adding higher upstream versions of these recipes to a lower-priority > > layer in a stable series is a potential source for weird problems. > > I would assume they'd be removed from meta-python at the same time > they are added to meta. "at the same time" is complicated since OE-core has releases, but meta-openembedded is just a branch. I would also assume that not all users of stable series are updating meta-openembedded to the latest on the dunfell branch at the same time as OE-core, some users might end up updating one but never updating the other one. > //Peter cu Adrian -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138368): https://lists.openembedded.org/g/openembedded-core/message/138368 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 0/4] Import recipes from meta-python
> -Original Message- > From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Adrian Bunk > Sent: den 16 maj 2020 19:47 > To: Steve Sakoman > Cc: Richard Purdie ; Denys > Dmytriyenko ; Joshua Watt ; > Patches and discussions about the oe-core layer c...@lists.openembedded.org>; jdma...@kudzu.us; Khem Raj > > Subject: Re: [OE-core][PATCH 0/4] Import recipes from meta-python > > On Fri, May 15, 2020 at 03:21:57PM -1000, Steve Sakoman wrote: > > > > I'm seeing a few votes of "yes for dunfell" and no opposition as yet > > (at least here on the list). > > > > I support the desire to get rid of a meta-python dependency in bsp > > layers so I'm also a yes vote unless someone comes up with a good > > reason why we shouldn't. > > meta-openembedded/meta-python has a higher layer priority than OE-core. > > Adding higher upstream versions of these recipes to a lower-priority > layer in a stable series is a potential source for weird problems. > > > Steve > > cu > Adrian I would assume they'd be removed from meta-python at the same time they are added to meta. //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138367): https://lists.openembedded.org/g/openembedded-core/message/138367 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] pypi.python.org simply a redirect to pypi.org?
it *appears* that pypi.python.org is just a redirect to pypi.org,
which means a few things could be simplified, such as a few recipes,
as well as pypi.bbclass:
HOMEPAGE ?= "https://pypi.python.org/pypi/${PYPI_PACKAGE}/;
...
UPSTREAM_CHECK_URI ?= "https://pypi.org/project/${PYPI_PACKAGE}/;
seems could be replaced by:
HOMEPAGE ?= "https://pypi.org/project/${PYPI_PACKAGE}/;
...
UPSTREAM_CHECK_URI ?= ${HOMEPAGE}
unless i'm missing something. thoughts?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138366):
https://lists.openembedded.org/g/openembedded-core/message/138366
Mute This Topic: https://lists.openembedded.org/mt/74256683/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 0/4] Import recipes from meta-python
On Fri, May 15, 2020 at 03:21:57PM -1000, Steve Sakoman wrote: > > I'm seeing a few votes of "yes for dunfell" and no opposition as yet > (at least here on the list). > > I support the desire to get rid of a meta-python dependency in bsp > layers so I'm also a yes vote unless someone comes up with a good > reason why we shouldn't. meta-openembedded/meta-python has a higher layer priority than OE-core. Adding higher upstream versions of these recipes to a lower-priority layer in a stable series is a potential source for weird problems. > Steve cu Adrian -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138365): https://lists.openembedded.org/g/openembedded-core/message/138365 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/6] multilib_header_wrapper.h: Remove pragma once
This was a bandaid to avoid include recursion caused by multilibbed wordsize.h Signed-off-by: Khem Raj --- scripts/multilib_header_wrapper.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/scripts/multilib_header_wrapper.h b/scripts/multilib_header_wrapper.h index c81e7ee5e8..62b57ca8ee 100644 --- a/scripts/multilib_header_wrapper.h +++ b/scripts/multilib_header_wrapper.h @@ -5,8 +5,6 @@ * */ -#pragma once - #if defined (__bpf__) #define __MHWORDSIZE 64 #elif defined (__arm__) -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138361): https://lists.openembedded.org/g/openembedded-core/message/138361 Mute This Topic: https://lists.openembedded.org/mt/74251772/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 5/6] multilib_header_wrapper: Drop using __MHWORDSIZE
This is not needed as __WORDSIZE already represents same value and is directly defined in wordsize.h, this simplifies the multlib headers Signed-off-by: Khem Raj --- scripts/multilib_header_wrapper.h | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/scripts/multilib_header_wrapper.h b/scripts/multilib_header_wrapper.h index df01b56a72..88f3193812 100644 --- a/scripts/multilib_header_wrapper.h +++ b/scripts/multilib_header_wrapper.h @@ -5,22 +5,9 @@ * */ -#if defined (__arm__) -#define __MHWORDSIZE 32 -#elif defined (__aarch64__) && defined ( __LP64__) -#define __MHWORDSIZE 64 -#elif defined (__aarch64__) -#define __MHWORDSIZE 32 -#else #include -#if defined (__WORDSIZE) -#define __MHWORDSIZE __WORDSIZE -#else -#error "__WORDSIZE is not defined" -#endif -#endif -#if __MHWORDSIZE == 32 +#if __WORDSIZE == 32 #ifdef _MIPS_SIM @@ -36,7 +23,7 @@ #include #endif -#elif __MHWORDSIZE == 64 +#elif __WORDSIZE == 64 #include #else #error "Unknown __WORDSIZE detected" -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138363): https://lists.openembedded.org/g/openembedded-core/message/138363 Mute This Topic: https://lists.openembedded.org/mt/74251774/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/6] glibc: Do not synthesize wordsize.h for arm multilibs
This has been constant source of trouble, because it is fundamental file
which sets machine word length and everything else builts on top of that
so when it is sythesized like this, where the sythesize template itself
needs wordsize.h to determine machine word length, it creates the
catch-22 problem, which is seen when building things like bpf, or
running clang-tidy etc. where compiler internal defines may not be used
this ends up in all sorts of problems. Now that glibc provides exact
same header for arm and aarch64, its no longer needed to be multilibbed
here
Signed-off-by: Khem Raj
---
meta/recipes-core/glibc/glibc-package.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/glibc/glibc-package.inc
b/meta/recipes-core/glibc/glibc-package.inc
index 3e92ce0629..ff25fd4187 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -152,7 +152,7 @@ do_install_append_armeb () {
}
do_install_armmultilib () {
- oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
+ oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h
oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h
bits/pthreadtypes.h bits/pthreadtypes-arch.h bits/sem.h bits/semaphore.h
bits/setjmp.h
oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h
bits/typesizes.h
oe_multilib_header bits/procfs-id.h bits/procfs.h bits/shmlba.h
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138360):
https://lists.openembedded.org/g/openembedded-core/message/138360
Mute This Topic: https://lists.openembedded.org/mt/74251771/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/6] glibc: Unify wordsize.h for arm and aarch64
Should help simplify multilib in arm world
Signed-off-by: Khem Raj
---
...y-the-header-between-arm-and-aarch64.patch | 67 +++
meta/recipes-core/glibc/glibc_2.31.bb | 1 +
2 files changed, 68 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0030-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch
diff --git
a/meta/recipes-core/glibc/glibc/0030-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch
b/meta/recipes-core/glibc/glibc/0030-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch
new file mode 100644
index 00..cbef2f2830
--- /dev/null
+++
b/meta/recipes-core/glibc/glibc/0030-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch
@@ -0,0 +1,67 @@
+From 9cb0a756b017f5961b70ac781d3eaec6c82513cb Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Fri, 15 May 2020 17:05:45 -0700
+Subject: [PATCH] wordsize.h: Unify the header between arm and aarch64
+
+This helps OE multilibs to not sythesize this header which causes all
+kind of recursions and other issues since wordsize is fundamental header
+and ends up including itself in many case e.g. clang tidy, bpf etc.
+
+Upstream-Status: Inappropriate [ OE-Specific ]
+
+Signed-off-by: Khem Raj
+---
+ sysdeps/aarch64/bits/wordsize.h | 8 ++--
+ sysdeps/{aarch64 => arm}/bits/wordsize.h | 8 ++--
+ 2 files changed, 12 insertions(+), 4 deletions(-)
+ copy sysdeps/{aarch64 => arm}/bits/wordsize.h (85%)
+
+diff --git a/sysdeps/aarch64/bits/wordsize.h b/sysdeps/aarch64/bits/wordsize.h
+index ee01841773..34fcdef1f1 100644
+--- a/sysdeps/aarch64/bits/wordsize.h
b/sysdeps/aarch64/bits/wordsize.h
+@@ -17,12 +17,16 @@
+License along with the GNU C Library; if not, see
+
[OE-core] [PATCH 4/6] multilib_header: Fall back to worsize form libc for bpf target
Setting bpf to use 64bit for wordlength is not right, it happens to work perhaps becuase the targets its being run on are 64bit inherently Signed-off-by: Khem Raj --- scripts/multilib_header_wrapper.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/scripts/multilib_header_wrapper.h b/scripts/multilib_header_wrapper.h index 62b57ca8ee..df01b56a72 100644 --- a/scripts/multilib_header_wrapper.h +++ b/scripts/multilib_header_wrapper.h @@ -5,9 +5,7 @@ * */ -#if defined (__bpf__) -#define __MHWORDSIZE 64 -#elif defined (__arm__) +#if defined (__arm__) #define __MHWORDSIZE 32 #elif defined (__aarch64__) && defined ( __LP64__) #define __MHWORDSIZE 64 -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138362): https://lists.openembedded.org/g/openembedded-core/message/138362 Mute This Topic: https://lists.openembedded.org/mt/74251773/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 6/6] syslinux: Fix build with gcc10
Bring in a patch from fedora to fix -fno-common issue
Signed-off-by: Khem Raj
---
...multiple-definition-of-symbol-errors.patch | 97 +++
.../syslinux/syslinux_6.04-pre2.bb| 1 +
2 files changed, 98 insertions(+)
create mode 100644
meta/recipes-devtools/syslinux/syslinux/0010-Workaround-multiple-definition-of-symbol-errors.patch
diff --git
a/meta/recipes-devtools/syslinux/syslinux/0010-Workaround-multiple-definition-of-symbol-errors.patch
b/meta/recipes-devtools/syslinux/syslinux/0010-Workaround-multiple-definition-of-symbol-errors.patch
new file mode 100644
index 00..44cb153276
--- /dev/null
+++
b/meta/recipes-devtools/syslinux/syslinux/0010-Workaround-multiple-definition-of-symbol-errors.patch
@@ -0,0 +1,97 @@
+From 951928f2cad5682c2844e6bd0f7201236c5d9b66 Mon Sep 17 00:00:00 2001
+From: Merlin Mathesius
+Date: Wed, 13 May 2020 08:02:27 -0500
+Subject: [PATCH] Workaround multiple definition of symbol errors
+
+Lifted from Fedora
https://src.fedoraproject.org/rpms/syslinux/blob/master/f/0005-Workaround-multiple-definition-of-symbol-errors.patch
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj
+
+---
+ com32/cmenu/Makefile | 2 +-
+ com32/elflink/ldlinux/Makefile | 2 +-
+ com32/gpllib/Makefile | 2 +-
+ com32/hdt/Makefile | 2 +-
+ core/Makefile | 2 +-
+ dos/Makefile | 2 +-
+ efi/Makefile | 2 +-
+ 7 files changed, 7 insertions(+), 7 deletions(-)
+
+--- a/com32/cmenu/Makefile
b/com32/cmenu/Makefile
+@@ -49,7 +49,7 @@ makeoutputdirs:
+ @mkdir -p $(OBJ)/libmenu
+
+ libmenu/libmenu.elf: $(LIBMENU)
+- $(LD) -shared $(LDFLAGS) -soname $(patsubst %.elf,%.c32,$(@F)) \
++ $(LD) -shared $(LDFLAGS) -z muldefs -soname $(patsubst
%.elf,%.c32,$(@F)) \
+ -o $@ $^
+
+ tidy dist:
+--- a/com32/elflink/ldlinux/Makefile
b/com32/elflink/ldlinux/Makefile
+@@ -33,7 +33,7 @@ endif
+ all: $(BTARGET) ldlinux_lnx.a
+
+ ldlinux.elf : $(OBJS)
+- $(LD) $(LDFLAGS) -soname $(SONAME) -o $@ $^ $(LIBS)
++ $(LD) $(LDFLAGS) -z muldefs -soname $(SONAME) -o $@ $^ $(LIBS)
+
+ LNXCFLAGS += -D__export='__attribute__((visibility("default")))'
+ LNXLIBOBJS = get_key.lo
+--- a/com32/gpllib/Makefile
b/com32/gpllib/Makefile
+@@ -24,7 +24,7 @@ makeoutputdirs:
+ $(addprefix $(OBJ),$(sort $(dir $(LIBOBJS,$(b))
+
+ libgpl.elf : $(LIBOBJS)
+- $(LD) -shared $(LDFLAGS) -soname $(patsubst %.elf,%.c32,$(@F)) -o $@ $^
++ $(LD) -shared $(LDFLAGS) -z muldefs -soname $(patsubst
%.elf,%.c32,$(@F)) -o $@ $^
+
+ tidy dist clean:
+ find . \( -name \*.o -o -name .\*.d -o -name \*.tmp \) -print0 | \
+--- a/com32/hdt/Makefile
b/com32/hdt/Makefile
+@@ -52,7 +52,7 @@ QEMU ?= qemu-kvm
+ all: $(MODULES) $(TESTFILES)
+
+ hdt.elf : $(OBJS) $(LIBS) $(C_LIBS)
+- $(LD) $(LDFLAGS) -o $@ $^
++ $(LD) $(LDFLAGS) -z muldefs -o $@ $^
+
+ memtest:
+ -[ ! -f $(FLOPPY_DIR)/$(MEMTEST) ] && $(WGET) $(MEMTEST_URL) -O
$(FLOPPY_DIR)/$(MEMTEST)
+--- a/core/Makefile
b/core/Makefile
+@@ -156,7 +156,7 @@ LDSCRIPT = $(SRC)/$(ARCH)/syslinux.ld
+ NASM_ELF = elf
+
+ %.elf: %.o $(LIBDEP) $(LDSCRIPT) $(AUXLIBS)
+- $(LD) $(LDFLAGS) -pie -Bsymbolic \
++ $(LD) $(LDFLAGS) -z muldefs -pie -Bsymbolic \
+ -T $(LDSCRIPT) \
+ --unresolved-symbols=report-all \
+ -E --hash-style=gnu -M -o $@ $< \
+--- a/dos/Makefile
b/dos/Makefile
+@@ -19,7 +19,7 @@ include $(MAKEDIR)/embedded.mk
+ CFLAGS+= -D__MSDOS__ -mregparm=3 -DREGPARM=3
+ # CFLAGS += -DDEBUG
+
+-LDFLAGS= -T $(SRC)/dosexe.ld
++LDFLAGS= -T $(SRC)/dosexe.ld -z muldefs
+ OPTFLAGS = -g
+ INCLUDES = -include code16.h -nostdinc -iwithprefix include \
+ -I$(SRC) -I$(SRC)/.. -I$(SRC)/../libfat \
+--- a/efi/Makefile
b/efi/Makefile
+@@ -71,7 +71,7 @@ $(OBJS): | $(OBJ)/$(ARCH)
+ BTARGET = syslinux.efi
+
+ syslinux.so: $(OBJS) $(CORE_OBJS) $(LIB_OBJS)
+- $(LD) $(LDFLAGS) --strip-debug -o $@ $^ -lgnuefi -lefi
++ $(LD) $(LDFLAGS) -z muldefs --strip-debug -o $@ $^ -lgnuefi -lefi
+
+ # We need to rename the .hash section because the EFI firmware
+ # linker really doesn't like it.
diff --git a/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
b/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
index e9dbefb930..3e7eef3a75 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
@@ -20,6 +20,7 @@ SRC_URI =
"https://www.zytor.com/pub/syslinux/Testing/6.04/syslinux-${PV}.tar.xz
file://0007-linux-syslinux-implement-ext_construct_sectmap_fs.patch
\
file://0008-libinstaller-syslinuxext-implement-syslinux_patch_bo.patch \
file://0009-linux-syslinux-implement-install_bootblock.patch \
+ file://0010-Workaround-multiple-definition-of-symbol-errors.patch \
Re: [OE-core] Cannot disable weston
On Wed, May 6, 2020 at 1:58 PM Otavio Salvador wrote: > > Hello all, > > Adding Khem on Cc. > > On Wed, May 6, 2020 at 5:42 PM Andrey Zhizhikin wrote: > > On Wed, May 6, 2020 at 10:29 PM Tom Hochstein wrote: > > > > > > We are no longer able to disable weston service with standard `systemctl > > > disable weston@root.service`. > > > > I've faced similar issues a while back, and also found out that weston > > has been actually started twice: once from udev, and once from > > systemd. At that time, I removed the udev locally on the EVK and > > didn't look further into it. > > > > > On boot the service is started again. It seems likely this started with > > > the introduction of a starting udev rule: > > > > > > https://github.com/openembedded/openembedded-core/commit/aa3bced2e1de2f4ba507aa014835b06edccc138a#diff-d92aa97566c1bd0dd1eb817bb4511cda > > > > > > Is this behaving correctly? Can the rule be made to honor the service > > > disablement? > > > > Or the other way around: can the systemd service be disabled? Or in > > general: is it possible to leave only one of those mechanisms, and > > which one is the correct one? > > Why the udev support was added and why this cannot be done in the service? > udev service integrates well when you have weston but for some reason no drm on machine so it only launches when system detects graphics/drm if you need to manually control it then disable the udev rule and it will show up disabled always and then can be managed manually. > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138358): https://lists.openembedded.org/g/openembedded-core/message/138358 Mute This Topic: https://lists.openembedded.org/mt/74037529/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] OpenEmbedded Happy Hour
On 15/05/20 17:56, Philip Balister wrote: I've made a wiki page to track these: https://www.openembedded.org/wiki/Happy_Hours Then next one is scheduled for 2100 UTC on May 27. This is late evening for Europe and morning for New Zealand, so hopefully we see some different faces. The meeting info is on the wiki page. There is no set agenda, so bring some projects to talk about with the community. Philip https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+27=20200527T21=%3A=1 -- Marco -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138357): https://lists.openembedded.org/g/openembedded-core/message/138357 Mute This Topic: https://lists.openembedded.org/mt/74230229/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
