From: sangeeta jain
All test id (eg. @alias) inside manual testcase file shall follow the same test
id
naming convention from oeqa automated tests (eg. selftest, runtime, sdk, etc),
where
the test id consists of ...
Furthermore,
there shall be only 1 unique test_module per each manual
From: sangeeta jain
Two changes made in oeqa/manual/compliance-test.json:
1. All test id (eg. @alias) inside manual testcase file shall follow the same
test id
naming convention from oeqa automated tests (eg. selftest, runtime, sdk, etc),
where
the test id consists of ...
Furthermore,
there
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Hi Ross：
Just work around.
Now I don't know why does createrepo-c depend on python3-dev.
--
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
MAIL :
On Tue, 2019-03-12 at 11:18 +0100, Łukasz Łaguna wrote:
> ---
> meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
> b/meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
>
From: Khem Raj
These patches were applied, hoping that they will eventually be accepted
upstream but they have been rejected, I think its best that they are
dropped so we can avoid novel unintended behaviours that no other
distros will be seeing
(From OE-Core:
From: Khem Raj
These patches were applied, hoping that they will eventually be accepted
upstream but they have been rejected, I think its best that they are
dropped so we can avoid novel unintended behaviours that no other
distros will be seeing
(From OE-Core
The tc command is provided both by busybox and iproute2.
Signed-off-by: Lars Persson
---
meta/recipes-connectivity/iproute2/iproute2.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc
b/meta/recipes-connectivity/iproute2/iproute2.inc
The original fix was deleted when systemd was bumped from v239 to v241,
however not all of the patches have made it into the latest version.
Refactor the original patch to contain the missing changes.
Signed-off-by: Marcus Cooper
---
.../systemd/systemd/CVE-2019-6454.patch| 216
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.
This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:
Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.
This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:
Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t
I think I've done everything, but cannot figure out what step I missed.
I am using yesterday's "thud" branches:
BB_VERSION = "1.40.0"
BUILD_SYS= "x86_64-linux"
meta = "HEAD:fbb688ab3eeca1bbfbffd8c81fd8052bcc68"
meta-oe
meta-multimedia
meta-networking
When building GO packages for ARM (v5, v6, v7) it is expected that the
GOARM env variable is set during the build. Not having GOARM exported
will result in GO binaries which can't be executed on the target
(terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
We already have the
The cortexa7 tunings use 'cortexa7' in their tunings and do not
include 'arm7' so we need to look for both when setting TARGET_GOARM.
Signed-off-by: Mark Asselstine
---
meta/classes/goarch.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/goarch.bbclass
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options
On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> How would bitbake respond to an ‘export’ line with the empty string? I.e.
> can you do an actual conditional export the way we do conditional inherits,
> so it still is only exported for arm, even if the value is set to the
On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
wrote:
>
> The cortexa7 tunings use 'cortexa7' in their tunings and do not
> include 'arm7' so we need to look for both when setting TARGET_GOARM.
Is cortexa7 a special case? Or will the same issue be there for
cortexa5, cortexa9, cortexa15, etc?
On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
>
> wrote:
> > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > include 'arm7' so we need to look for both when setting TARGET_GOARM.
>
> Is cortexa7 a special
How would bitbake respond to an ‘export’ line with the empty string? I.e.
can you do an actual conditional export the way we do conditional inherits,
so it still is only exported for arm, even if the value is set to the empty
string for others?
On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
From: sangeeta jain
Two changes made in oeqa/manual/bsp-hw.json:
1. All test id (eg. @alias) inside manual testcase file shall follow the same
test id naming
convention from oeqa automated tests (eg. selftest, runtime, sdk, etc), where
the
test id consists of ... Furthermore,
there shall be
You need a *very* good reason to upgrade in stable releases, so please
explain the rationale.
Ross
On Wed, 13 Mar 2019 at 20:54, Jonathan Rajotte
wrote:
>
> Signed-off-by: Jonathan Rajotte
> ---
> .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
> 1 file changed, 2
Hi,
Disregard this series. It does not follow the project guideline regarding recipe
update for stable release.
Thanks
On Wed, Mar 13, 2019 at 08:55:53PM +, Jonathan Rajotte wrote:
> Signed-off-by: Jonathan Rajotte
> ---
> .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4
Signed-off-by: Jonathan Rajotte
---
.../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}
(90%)
diff --git
Pertinent fix for OE-Core since 2.10.6:
Fix: out of memory error handling
Fix: access migrate_disable field directly
Prevent allocation of buffers if exceeding available memory
2.10.9 also contains the necessary fix to support kernel up to 5.0.
Signed-off-by: Jonathan Rajotte
---
Signed-off-by: Jonathan Rajotte
---
.../lttng/{lttng-tools_2.9.5.bb => lttng-tools_2.9.11.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.9.5.bb =>
lttng-tools_2.9.11.bb} (97%)
diff --git
Signed-off-by: Jonathan Rajotte
---
.../lttng/{babeltrace_1.5.4.bb => babeltrace_1.5.6.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/lttng/{babeltrace_1.5.4.bb => babeltrace_1.5.6.bb}
(82%)
diff --git
On Wed, Mar 13, 2019 at 09:55:04PM +, Burton, Ross wrote:
> You need a *very* good reason to upgrade in stable releases, so please
> explain the rationale.
Yeah we got good reason, these are bugfix stable release, as a project we would
like our user to experience a good experience out-of-the
Hi,
Disregard this patch. It does not follow the project guideline regarding recipe
update for stable release.
Thanks,
On Wed, Mar 13, 2019 at 09:30:08PM +, Jonathan Rajotte wrote:
> Signed-off-by: Jonathan Rajotte
> ---
> .../lttng/{babeltrace_1.5.4.bb => babeltrace_1.5.6.bb}| 4
Update 0001-Allow-multiple-attempts-to-connect-to-relayd.patch chunk
accordingly.
Signed-off-by: Jonathan Rajotte
---
...multiple-attempts-to-connect-to-relayd.patch | 17 -
...tng-tools_2.9.5.bb => lttng-tools_2.9.11.bb} | 4 ++--
2 files changed, 10 insertions(+), 11
Signed-off-by: Jonathan Rajotte
---
.../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}
(90%)
diff --git
Drop patch [1] since it is part of the 2.10.9 release.
[1]
lttng-modules/0001-Fix-net-expose-sk-wmem-in-sock_exceed_buf_limit-trac.patch
Signed-off-by: Jonathan Rajotte
---
...k-wmem-in-sock_exceed_buf_limit-trac.patch | 67 ---
...ules_2.10.7.bb => lttng-modules_2.10.9.bb} |
Confusion on my end, disregard this series and the following [1] [2].
[1]
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280107.html
[2]
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280110.html
As for the confusion more info here [3].
[3]
On Tue, 2019-03-12 at 21:13 +, Jonathan Rajotte wrote:
> Multiple tests are failing due to missing dependencies on a bare
> core-image-minimal build with only lttng-tools ptest present.
>
> "getconf LONG_BIT" is used to get the bitness of the host to run the
> correct consumerd. Depend on
On 3/13/19 1:53 PM, Jonathan Rajotte wrote:
> Signed-off-by: Jonathan Rajotte
please provide more info on the update. is this fixing something? is it
a bug fix only release?
- armin
> ---
> .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
> 1 file changed, 2
35 matches
Mail list logo
