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 testcas
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
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 o
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 glib
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]
http://l
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 insertions
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 +
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 +
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 b
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 inser
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 a/meta/recipes-kernel/lttng/babeltrace_1.5.
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 deletions
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 a/meta/recipes-kernel/lttng/lttng-ust_2.10.
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} |
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 a/meta/recipes-kernel/lttng/lttng-tools_
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-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 a/meta/recipes-kernel/lttng/lttng-ust_2.10.
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 emp
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 c
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?
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 <
ma
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 l
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 b/m
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
meta
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 armv
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
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 rev:54550aa42378ce4b215bccbfd95e5e65
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: 54550aa42378ce4b215bccbfd95e5e650b0
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 armv
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
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
inde
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
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
> inde
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 : zhengrq.f...
34 matches
Mail list logo
