define is redefined
| /tmp/20200123-2021083-2c601q.h:13849:9: error: "__has_include" cannot be used
as a macro name
| 13849 | #define __has_include __has_include
| | ^
| compilation terminated due to -Wfatal-errors.
Since compiler already will take care of it int
From: Trevor Gamblin
See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632
Autobuilder tests occasionally fail, reporting that a new logfile
could not be created. While this failure did occur multiple times, it
could not be manually reproduced. However, there are issues with the
On 1/23/20 2:17 PM, Ross Burton wrote:
> On 23/01/2020 21:43, Bruce Ashfield wrote:
>> On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko
>> wrote:
>>>
>>> From: Denys Dmytriyenko
>>>
>>> Many BSPs require ARM Trusted Firmware (also known as Trusted
>>> Firmware-A).
>>> To avoid duplicating
On Thu, 2020-01-23 at 22:17 +, Ross Burton wrote:
> On 23/01/2020 21:43, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko
> > wrote:
> > > From: Denys Dmytriyenko
> > >
> > > Many BSPs require ARM Trusted Firmware (also known as Trusted
> > > Firmware-A).
> > > To
On Thu, Jan 23, 2020 at 02:39:52PM -0800, Andre McCurdy wrote:
> On Thu, Jan 23, 2020 at 2:17 PM Ross Burton wrote:
> > On 23/01/2020 21:43, Bruce Ashfield wrote:
> > > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> > >>
> > >> From: Denys Dmytriyenko
> > >>
> > >> Many BSPs require
On Thu, Jan 23, 2020 at 2:17 PM Ross Burton wrote:
> On 23/01/2020 21:43, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> >>
> >> From: Denys Dmytriyenko
> >>
> >> Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> >> To avoid
On Thu, Jan 23, 2020 at 1:43 PM Alexander Kanavin
wrote:
>
> I once more suggest we deal with all those special cases where linker
> customization is desired later on. New meson isn’t going to work without this
> change.
>
Perhaps I am missing something, what does new version gets us that we
The 5.x kernels seem to have made a change to the linker command line
processing.
When trying to build out of tree kernel modules, such as the
virtualbox guest additions, the following error is printed:
| make[1]: Entering directory
On 23/01/2020 21:43, Bruce Ashfield wrote:
On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
From: Denys Dmytriyenko
Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream
On Thu, Jan 23, 2020 at 04:10:33PM -0600, Joshua Watt wrote:
>
> On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> >On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> >>On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> >>>From: Denys Dmytriyenko
> >>>
> >>>Many BSPs require
On Thu, Jan 23, 2020 at 5:05 PM Denys Dmytriyenko wrote:
>
> On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> > >
> > > From: Denys Dmytriyenko
> > >
> > > Many BSPs require ARM Trusted Firmware (also known as Trusted
On Thu, Jan 23, 2020 at 5:10 PM Joshua Watt wrote:
>
>
> On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> > On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> >> On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> >>> From: Denys Dmytriyenko
> >>>
> >>> Many BSPs require ARM
On 23/01/2020 19:49, Andre McCurdy wrote:
Should this be using incompatible_license_contains() instead of
bb.utils.contains()?
Yes, it should. Thanks for reminding me of that function.
Ross
--
___
Openembedded-core mailing list
On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
From: Denys Dmytriyenko
Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating
On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> >
> > From: Denys Dmytriyenko
> >
> > Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> > To avoid duplicating efforts of adding very similar
== Series Details ==
Series: "procps: enable optional system..." and 2 more (rev3)
Revision: 3
URL : https://patchwork.openembedded.org/series/22252/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests
== Series Details ==
Series: "procps: enable optional system..." and 2 more (rev4)
Revision: 4
URL : https://patchwork.openembedded.org/series/22252/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests
== Series Details ==
Series: "procps: enable optional system..." and 2 more (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/22252/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests
From: Daniel McGregor
Allow setting custom buildhistory tag prefixes. This allows multiple
build directories to share one buildhistory git repository with multiple
worktrees.
Signed-off-by: Daniel McGregor
---
meta/classes/buildhistory.bbclass | 7 ---
1 file changed, 4 insertions(+), 3
From: Daniel McGregor
cmake 3.12 introduced this environment variable. Prefer it to passing
PARALLEL_MAKE and PARALLEL_MAKEINST on the cmake command line, because
it gets passed to second stage cmake invocations while command-line
arguments do not (for example, multi-stage clang builds)
From: Daniel McGregor
procps includes support for listing the owning unit of a process, but
this support is disabled by default. Enable support using
a PACKAGECONFIG that depends on the systemd DISTRO_FEATURE.
Signed-off-by: Daniel McGregor
---
meta/recipes-extended/procps/procps_3.3.15.bb |
On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
>
> From: Denys Dmytriyenko
>
> Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> To avoid duplicating efforts of adding very similar recipes to BSP layers,
> add an upstream reference implementation to
I once more suggest we deal with all those special cases where linker
customization is desired later on. New meson isn’t going to work without this
change.
Alex
> On 23 Jan 2020, at 20.27, Khem Raj wrote:
>
> On Thu, Jan 23, 2020 at 9:34 AM Alexander Kanavin
> wrote:
>>
>> Signed-off-by:
From: Denys Dmytriyenko
Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream reference implementation to openembedded-core, which can be
customized by BSPs, if needed.
Signed-off-by:
Sorry but certainly no. It’s already hard enough to make ptests pass with just
the one standard configuration tested by the autobuilder. I still have a
handful of components with cryptic failures left to fix, so if you can help
with valgrind, mdadm or lttng failures I’d appreciate that.
If you
Without the proper default tune in TUNE_FEATURES, certain variables
won't expand correctly. MACHINEOVERRIDES won't add cortexa72-cortexa53:
TUNE_CCARGS won't add -mtune=cortexa72.cortexa-53, generating the toolchain
incorrectly.
Adding missing 'cortexa72-cortexa53' to both
== Series Details ==
Series: "procps: enable optional system..." and 2 more
Revision: 1
URL : https://patchwork.openembedded.org/series/22252/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
From: Denys Dmytriyenko
Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream reference implementation to openembedded-core, which can be
customized by BSPs, if needed.
Signed-off-by:
From: Daniel McGregor
cmake 3.12 introduced this environment variable. Prefer it to passing
PARALLEL_MAKE and PARALLEL_MAKEINST on the cmake command line, because
it gets passed to second stage cmake invocations while command-line
arguments do not (for example, multi-stage clang builds)
From: Daniel McGregor
Allow setting custom buildhistory tag prefixes. This allows multiple
build directories to share one buildhistory git repository with multiple
worktrees.
Signed-off-by: Daniel McGregor
---
meta/classes/buildhistory.bbclass | 7 ---
1 file changed, 4 insertions(+), 3
From: Daniel McGregor
procps includes support for listing the owning unit of a process, but
this support is disabled by default. Enable support using
a PACKAGECONFIG that depends on the systemd DISTRO_FEATURE.
Signed-off-by: Daniel McGregor
---
meta/recipes-extended/procps/procps_3.3.15.bb |
Hi,
On Thu, 2020-01-23 at 18:34 +0100, Alexander Kanavin wrote:
> This is beneficial for parted ptests in particular, as
> they expect vfat functionality to work.
Could you also update the parted ptests to skip or delete those
tests that depend on vfat, please? I.e. when the DISTRO_FEATURE
is
Use NSS_USE_ARM_HW_CRYPTO to detect USE_ARM_GCM, since there are
dependent, without this we control the crypto code function inclusion in
build but do not control the call sites, which can result in undefined
symbols e.g.
Linux_SINGLE_SHLIB/gcm.o: in function `gcmHash_InitContext':
Help musl based systems provide ucontext APIs
Signed-off-by: Khem Raj
---
.../0001-pass-LDFLAGS-to-link-step.patch | 31 ++
meta/recipes-core/musl/libucontext_git.bb | 62 +++
2 files changed, 93 insertions(+)
create mode 100644
define is redefined
| /tmp/20200123-2021083-2c601q.h:13849:9: error: "__has_include" cannot be used
as a macro name
| 13849 | #define __has_include __has_include
| | ^
| compilation terminated due to -Wfatal-errors.
Since compiler already will take care of it int
libucontext is library implementation for ucontext APIs which in case of
glibc are bundled into C library but not for musl, this helps compiling
apps needing these APIs on musl, e.g. chromium
The following changes since commit ca3993cc4b13d4e661228cee6fb9448adfd0a4ba:
bitbake: tests/fetch:
python code underneath is smart and pokes at python installation in
sysroot for compile environment, the overrides from EXTRA_OEMAKE are
ofcourse preferred but it falls back to python3's distutils/sysconfig
for rest of them, and it does use CCLD and LDSHARED for linking, when we
use clang to
On Wed, Jan 22, 2020 at 6:46 AM Ross Burton wrote:
>
> packagegroup-base-vfat RRECOMMENDS on dosfstools, but this is GPLv3 so
> may be blacklisted. Respect INCOMPATIBLE_LICENSE and don't recommend if
> GPL-3.0 has been blacklisted.
>
> Signed-off-by: Ross Burton
> ---
>
On Thu, Jan 23, 2020 at 9:34 AM Alexander Kanavin
wrote:
>
> Signed-off-by: Alexander Kanavin
> ---
> meta/classes/meson.bbclass | 9 -
> meta/recipes-devtools/meson/meson.inc| 4 ++--
> .../0001-Make-CPU-family-warnings-fatal.patch| 12
On Thu, Jan 23, 2020 at 7:24 AM Richard Purdie
wrote:
> On Thu, 2020-01-23 at 09:59 -0500, Jean-Marie LEMETAYER wrote:
> > On Jan 23, 2020, at 3:37 PM, Richard Purdie
> > richard.pur...@linuxfoundation.org wrote:
> > > On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
> > > > I
define is redefined
| /tmp/20200123-2021083-2c601q.h:13849:9: error: "__has_include" cannot be used
as a macro name
| 13849 | #define __has_include __has_include
| | ^
| compilation terminated due to -Wfatal-errors.
Since compiler already will take care of it int
Signed-off-by: Alexander Kanavin
---
meta/classes/meson.bbclass | 9 -
meta/recipes-devtools/meson/meson.inc| 4 ++--
.../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
...-do-not-manipulate-the-environment-when.patch | 16
1. Do not clutter /, create a special-purpose dir
2. Clean up the dir after tests are done (if this is not
performed, disk will overflow later in ptesting).
3. Fix up more locations in ptests to use the dir.
Upstream default /var/tmp is not suitable as it is not
big enough (mdadm needs about 500
This should address ARM64 specific failures in particular.
eu-objdump is now installed on all architectures;
ptests fail in its absence and pass when it is present, so it's
useful at least in some scenarios in non-x86 architectures and
fails gracefully otherwise.
The original decision to exclude
This is beneficial for parted ptests in particular, as
they expect vfat functionality to work.
Signed-off-by: Alexander Kanavin
---
meta/conf/distro/include/default-distrovars.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/default-distrovars.inc
The lists of ptests are defined via PTESTS_FAST and PTESTS_SLOW;
ptests-pkgs also pulls in additional items that are specifically
excluded from those due to causing issues with ptesting.
Signed-off-by: Alexander Kanavin
---
meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 2 --
1 file
On Thu, Jan 23, 2020 at 7:48 AM Alexander Kanavin
wrote:
> New meson more or less forces one of 'bfd', 'lfd' or 'gold' for that
> option (both as 'ld' in cross file and in LD from environment), as it is
> passed directly to -fuse-ld, and that option takes only the three
> variants.You can't
New meson more or less forces one of 'bfd', 'lfd' or 'gold' for that option
(both as 'ld' in cross file and in LD from environment), as it is passed
directly to -fuse-ld, and that option takes only the three variants.You
can't place the actual binary name there.
There is a use case for letting
I forgot to mention that this is all entirely opt-in (via non-default
options to 'runqemu'). By default qemu behaves exactly as before, and does
not use virgl.
Alex
On Thu, 23 Jan 2020 at 16:38, Alexander Kanavin
wrote:
> virgl is a virtualized accelerated 3D graphics support for the qemu
>
This will allow better control over native virgl/qemu configurations.
Adjust gtk+3/cairo native configurations to actually ignore opengl
when building for -native: we do not need it, and it would cause build
failures as only a limited subset of mesa-native is currently built.
Drop
Note that to actually use accelerated GL passthrough, there are two options
1) a suitable frontend need to be also enabled - gtk+ and SDL both seem to work
well.
Previously I struggled to make SDL work, but now it seems fine.
2) it is also possible to render off-screen with -display
This allows virgl support in qemu with the SDL frontend
Signed-off-by: Alexander Kanavin
---
meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb
virgl is a virtualized accelerated 3D graphics support for the qemu
guests. This patchset enables virgl in qemu, when 'opengl' is in
DISTRO_FEATURES.
This adds a few native dependencies to qemu-system-native
(particularly, libdrm, virglrenderer and a special minimal configuration
of mesa-native).
On Thu, 2020-01-23 at 09:59 -0500, Jean-Marie LEMETAYER wrote:
> On Jan 23, 2020, at 3:37 PM, Richard Purdie
> richard.pur...@linuxfoundation.org wrote:
> > On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
> > > I understand the issue with blocked domains this is why I suggest
> > >
On Jan 23, 2020, at 3:37 PM, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
> On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
>> I understand the issue with blocked domains this is why I suggest the
>> custom domain "connectivitycheck.openembedded.org".
>>
>> But I dont
On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
> I understand the issue with blocked domains this is why I suggest the
> custom domain "connectivitycheck.openembedded.org".
>
> But I dont know if it could be an option. Can OE have a sub-domain
> like that? maybe using some cdn to
On Jan 23, 2020, at 2:56 PM, Ross Burton ross.bur...@intel.com wrote:
> On 23/01/2020 13:14, Jean-Marie LEMETAYER wrote:
>> So "example.com" is clearly not a good domain to do connectivity checks.
>>
>> The "openembedded.org" domain is good but have a slow response time.
>>
>> And finally
On Jan 23, 2020, at 2:26 PM, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
> On Thu, 2020-01-23 at 08:14 -0500, Jean-Marie LEMETAYER wrote:
>> Hi folks,
>>
>> I have noticed some hang-ups at the beginning of my builds on the
>> master branch.
>> I have search a little and discovered
On 23/01/2020 13:14, Jean-Marie LEMETAYER wrote:
So "example.com" is clearly not a good domain to do connectivity checks.
The "openembedded.org" domain is good but have a slow response time.
And finally "google.com" which have all sort of speedy networking stuff is very
efficient.
Oh my
On Thu, 2020-01-23 at 08:14 -0500, Jean-Marie LEMETAYER wrote:
> Hi folks,
>
> I have noticed some hang-ups at the beginning of my builds on the
> master branch.
> I have search a little and discovered that the connectivity check
> made by poky
> was the root cause. In fact connectivity check use
On Thu, Jan 23, 2020 at 2:14 PM Jean-Marie LEMETAYER
wrote:
>
> Hi folks,
>
> I have noticed some hang-ups at the beginning of my builds on the master
> branch.
> I have search a little and discovered that the connectivity check made by poky
> was the root cause. In fact connectivity check use
Hi folks,
I have noticed some hang-ups at the beginning of my builds on the master branch.
I have search a little and discovered that the connectivity check made by poky
was the root cause. In fact connectivity check use the CONNECTIVITY_CHECK_URIS
variable which is by default set to
From: Trevor Gamblin
See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632
Autobuilder tests occasionally fail, reporting that a new logfile
could not be created. While this failure did occur multiple times, it
could not be manually reproduced. However, there are issues with the
Hi Ross,
On 1/23/20, Ross Burton wrote:
> On 21/01/2020 11:21, JH wrote:
>> The wired
>> thing was that image injected so many new messages, including "Welcome
>> to OpenEmbedded nodistro.0!" I have never seen in previous built image
>> boot.
>
> If you've never seen that before, but now you do,
On 21/01/2020 11:21, JH wrote:
The wired
thing was that image injected so many new messages, including "Welcome
to OpenEmbedded nodistro.0!" I have never seen in previous built image
boot.
If you've never seen that before, but now you do, then the problem is
that you're not setting DISTRO in
This patch also helps to build with EXTERNALSRC.
Signed-off-by: Daisuke Yamane
---
meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
Use the same value of B between u-boot and u-boot-tools.
This patch also enable the out-of-tree builds of u-boot-tools actually.
Signed-off-by: Daisuke Yamane
---
meta/recipes-bsp/u-boot/u-boot-common.inc | 2 ++
meta/recipes-bsp/u-boot/u-boot.inc| 2 --
2 files changed, 2
== Series Details ==
Series: "[v4] u-boot-tools: Add capabil..." and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/22236/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
Use the same value of B between u-boot and u-boot-tools.
This patch also enable the out-of-tree builds of u-boot-tools actually.
---
meta/recipes-bsp/u-boot/u-boot-common.inc | 2 ++
meta/recipes-bsp/u-boot/u-boot.inc| 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
This patch also helps to build with EXTERNALSRC.
---
meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
index bede984..414ee33
70 matches
Mail list logo
