Date   

Re: How to pass arguments to a shell function from python task bb.build.exec_func ? #bitbake #yocto

Joshua Watt
 

AFAIK, passing arguments from a python function to a shell function is not allowed

On 7/21/21 10:45 AM, Bel Hadj Salem Talel wrote:
Hi All,

I have this example that can call a shell function from a python task:

shell_function(){
    bbwarn "This is a shell function, arg1 = $1"
}

python do_something(){
   bb.build.exec_func('shell_function', d)
}

How to pass arguments to the shell function ?

I tried this : "bb.build.exec_func('shell_function 1', d)" but it fails with the error: "shell_function 1" not found.

Thanks,
Talel



meta-security layer

Michael Nazzareno Trimarchi
 

Hi Armin

Using the meta-integrety layer and I'm able to deploy the image but I
don't have the attribute insde the ext4 and wic image I create.
Do you know what step are missing?

Michael


How to pass arguments to a shell function from python task bb.build.exec_func ? #bitbake #yocto

Bel Hadj Salem Talel
 

Hi All,

I have this example that can call a shell function from a python task:

shell_function(){
    bbwarn "This is a shell function, arg1 = $1"
}

python do_something(){
   bb.build.exec_func('shell_function', d)
}

How to pass arguments to the shell function ?

I tried this : "bb.build.exec_func('shell_function 1', d)" but it fails with the error: "shell_function 1" not found.

Thanks,
Talel


Yocto Technical Team Minutes, Engineering Sync, for July 20, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for July 20, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner
Stephen Jolley
Armin Kuster
Jan-Simon Möller
Joshua Watt
Steve Sakoman
Trevor Gamblin
Scott Murray
Randy MacLeod
Richard Purdie
Martin Jansa (JaMa)
Michael Halstead
Bruce Ashfiled
Tony Tascioglu
Ross Burton
Alexandre Belloni
Paul Barker
Denys Dmytriyenko

== project status ==
- -m2 to be built this week (after pzstd included in buildtools tarball)
- 3.3.2 (hardknott) to QA after -m2 build
- proposal to add lz4c, zstd, and pzstd as required host commands
- architectural discussion on a change to the override syntax
- prserv still waiting on python asyncio issues
- AB-INT issues around ptest
- simpler test cases still required for multiconfig to resolve issues

== discussion ==
RP: syntax changes. we’re limited by not knowing definitively what and
what isn’t an override. leads to lots of caching and extra resources.
it would help speed things up. there are issues around backwards
compatibility, but it shouldn’t be a problem. the new character was
illegal previously (no clash). so with the backwards compatibility solved
it should be clear sailing (famous last words)
ScottM: sgtm, i like the syntax
RP: “feels” right, and it helps massively inside bitbake. how old would we
have to go back
ScottM: dunfell
RP: so if we backport this to dunfell then AGL should be helped
ScottM + J-SM: yes. we’d have to wait for a bunch of BSPs to adopt too
ScottM: can we mix and match old and new syntax?
RP: yes
ScottM: then we should be okay. AGL will be a good test case
JPEW: mix and match now, then make it required in the future?
RP: discussion ongoing
TrevorW: we started discussions on override syntax at OEDEM 2015, glad to see
it coming in
RP: my instinct is to bring it in quickly rather than have a long overlap. it
is used a lot in image filesystem code, also in tune features, qemu. the
package code relies heavily on the override syntax (package data). the tsc
generally thinks we should move forward. how long to wait before moving
forward?
AlexB: not too long. definitely before next lts and a little before
RP: which means now is a good time
PaulB: great idea. how about -m2? before or after?
RP: wanted -m2 last week, need new buildtools tarball, tempted to do it before
-m2
PaulB: ship it! (lol)
JPEW: at this point we’re just talking about converting the metadata?
RP: yes.
RP: tempted to do it for -m2.
RP: steve?
SS: sounds good, good idea to backport
RP: see discussion on oe-architecture

RP: Ross is proposing a function for bitbake-utils (layer_path()) for a layers
path to be extracted. why not a bblayersdir variable. core has this, sort
of. but maybe other layers could use this too. if you start encoding
paths like this, they get into the signatures (sigs depend on locations)
so path has to be in hash whitelisting variable. but path ends up in
signature file (for debugging). maybe have “add layer” like “add
task” that takes care of this. patches are on mailing list. we could
drop bbcollections variable that would be nice to drop (historic, predates
layers). it’d be nice to simplify some of the variables used in bitbake.
we force the priority to 5 (for no reason)
JPEW: priority levels has always been confusing
RP: this could make this go away
Denys: and there’s recipe priority
RP: and preferred, etc…
JPEW: and recipe priority only holds inside a layer
RP: one of the big issues with python2 → python3 was this sort of thing
JPEW: this could be easily backwards compatible?
RP: yes
PaulB: sounds like the right direction. layer.conf has always been confusing
(copy this boilerplate and it’ll work, don’t ask how) moving this into
bitbake would make it easier for users
Ross: i like getting rid of layer priority since this is a cause of lots
of issues since it works one day then stops a while later (after
bblayers.conf changes)
RP: behind the scenes bitbake does ugly stuff expanding layer dirs etc. so
this would get rid of that ugly code
ScottM: also backported to dunfell?
RP: more nervous backporting something like this
JPEW: probably wouldn’t be able to backport forcing the priority
PaulB: it’d be nice to have a branch of a layer support dunfell, hardknott,
and master all at the same time (without changes), but it probably won’t
be too hard
JPEW: yes, we do that too, and we go back a lot further. it’s possible
RP: i don’t want to block Ross’s patch and i think this would be good

ScottM: read-only prserv. moving the syncio loop creation. ran oe-selftest a
couple times. i don’t think it’s helping, still seeing failures with
the patches (and not without). i’ll need to double-check to make sure
these aren’t intermittent issues. do we want this feature bad enough
that doing it without the unification of the async-rpc code with the hash
equivalency is required? could we push that out to next release and just
do more minor tweaks for read-only mode for this release?
RP: i’m now worried about hash-equiv server as well. we run one on the
server but i think there’s gremlins there
JPEW: ScottM ping me on it, i think it should work, i’d like to help
ScottM: yea, i think it should work too. i think there’s a race in the
shutdown code. with enough load i think we’re running into something.
but i think it’s in the shutdown and solvable. i’m pretty sure i can
run enough load locally to mimic the behaviour of the AB.
RP: when i originally worked on this and we scaled AB, i had to do crazy load
tests. AB finds these failures
ScottM: was seeing loadavg of 800-900 on my local machine. it looked like
bitbake had shutdown during the build at one point. so it seems to match
the AB failures
PaulB: sounds like the failures i was seeing
ScottM: unfortunately the server tests don’t ever see these. they have to be
run on the whole build with a loaded build machine. so i think we should
do some for -m2 and then work on the rest for future releases/builds
RP: i’m not up-to-date on the asyncio stuff, but i've analyzed lots of
failures with bitbake shutdowns so i think i can help too
PaulB: i’ve moved off, but i’m happy to review patches or help brainstorm

ScottM: would it be possible to do a build on the AB with the auto-start
hash-equiv to see how that goes?
RP: if we put something into helper then we could try that
ScottM: we would lose some performance
JPEW: it would be a “throw-away” build
ScottM: okay, i’d like to try it to see how that would work
RP: AlexB can you set that up?
AlexB: sure
ScottB: bbhashserv = auto
RP: okay, do that and let scott know which build it is that’s got that
setting

ScottM: elc/yps?
TrevorW: working on it. we’ll do something, most likely a copy of the last
one but probably 3-days

PaulB: anyone looked at Deny’s email? (adding 5.10 kernel to dunfell)
ScottM: we’d really like to do it for AGL
J-SM: many customers have already done it so it’d be nice to do it in one place
Denys: kernel has a new lts every year, and dunfell is over a year old. this
is something coming from YP members requests. thanks for reviews. the next
yocto lts would have the same issue
PaulB: reminds me of hardware enablement kernels from ubuntu, in other words,
seems common among linux distros with long-term lts releases that last
longer than 1 year (i.e. kernel lts time frames)
Randy: sounds like this is a good and requested thing. are there any
downsides? effects on userspace?
Denys: userspace would be 5.4 but kernel would be 5.10. if we switch userspace
to 5.10 then everything has to rebuild (toolchain, glibc, which leads to
everything rebuilding)
RP: i think the goal is to not change the toolchain. the impact shouldn’t be
on SS (libc-headers causes toolchain updates). thanks Denys for getting
the ball rolling
Denys: i’d like to move it away from github and bring it under
git.yoctoproject.org
PaulB: the repos on git.yp.org are organized by headings, so maybe have a
heading for dunfell mixin layers
RP: sounds like something the tsc should think about
Denys: anyone want to do a mixin layer for gcc? gcc10 for dunfell? (i.e. a
newer toolchain)
<crickets>
Randy: sounds like a “no”. what’s the motivation?
Denys: some vendors would like to stay on dunfell (less work than moving to
master) but also test and build against newer tools
PaulB: newer toolchains always generate new warnings, errors… which leads to
lots of patches required everywhere. lots of effort to update to a newer
toolchain
Denys: true. like with all the -fcommon stuff
Randy: so vendors would have to wait for next lts and/or work towards master
PaulB: if dunfell gets extended for another 2 years then a newer u-boot mixin
layer would be useful (and we might as well make that public). but only if
dunfell is extended
Denys: to be clear: my understanding is that all these individual updates
should be done with individual mixin layers, not all done in one layer?
PaulB: yes, kernel, u-boot, are relatively self-contained, so should be able
to do as separate mixin layers

SS: any process/timeline for making that decision (dunfell extended?)
RP: comes down to funding. we’ve asked the members, but they haven’t
decided yet. i’m advocating for it and would like to see it


[ptest-runner 5/5] main: Do not return number of failed tests when calling ptest-runner

?ukasz Majewski
 

Up till now ptest-runner2 returns number of failed tests with its
exit status code. Such use case is not recommended [1] and may cause
issues when there are more than 256 tests to be executed.

To alleviate this issue the number of total tests with number of failed
ones is printed before exit. To be more specific - failure of a single
test doesn't indicate that the ptest-runner itself encounter any issue
during its execution.

One can test this change with executing:
./ptest-runner -d tests/data fail

Links:
[1] - https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html

Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
main.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/main.c b/main.c
index efa21b2..9f03857 100644
--- a/main.c
+++ b/main.c
@@ -219,6 +219,9 @@ main(int argc, char *argv[])
ptest_list_remove(run, opts.exclude[i], 1);
=20
rc =3D run_ptests(run, opts, argv[0], stdout, stderr);
+ fprintf(stdout, "TOTAL: %d FAIL: %d\n", ptest_list_length(run), rc);
+ if (rc > 0)
+ rc =3D 0;
=20
ptest_list_free_all(&run);
=20
--=20
2.20.1


[ptest-runner 4/5] mem: Refactor ptest_list cleanup

?ukasz Majewski
 

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Try to make memory management more robust by assigning always NULL to
struct ptest_list pointers. It's a refactoring which probably improves
the code but does not fix a concrete bug.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
main.c | 9 +++++----
ptest_list.c | 13 ++++---------
ptest_list.h | 8 +-------
tests/ptest_list.c | 13 +++++++------
tests/utils.c | 22 +++++++++++-----------
utils.c | 6 +++---
6 files changed, 31 insertions(+), 40 deletions(-)

diff --git a/main.c b/main.c
index e73626c..efa21b2 100644
--- a/main.c
+++ b/main.c
@@ -116,7 +116,8 @@ main(int argc, char *argv[])
mtrace();
#endif
=20
- struct ptest_list *head, *run;
+ struct ptest_list *head =3D NULL;
+ struct ptest_list *run =3D NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options =
opts;
=20
opts.dirs =3D malloc(sizeof(char **) * 1);
@@ -175,7 +176,7 @@ main(int argc, char *argv[])
=20
head =3D NULL;
for (i =3D 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp =3D NULL;
=20
tmp =3D get_available_ptests(opts.dirs[i], opts.timeout);
if (tmp =3D=3D NULL) {
@@ -211,7 +212,7 @@ main(int argc, char *argv[])
=20
run =3D filter_ptests(head, opts.ptests, ptest_num);
CHECK_ALLOCATION(run, (size_t) ptest_num, 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
=20
for (i =3D 0; i < ptest_exclude_num; i++)
@@ -219,7 +220,7 @@ main(int argc, char *argv[])
=20
rc =3D run_ptests(run, opts, argv[0], stdout, stderr);
=20
- ptest_list_free_all(run);
+ ptest_list_free_all(&run);
=20
return rc;
}
diff --git a/ptest_list.c b/ptest_list.c
index b689670..87b8c71 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -69,24 +69,19 @@ ptest_list_free(struct ptest_list *p)
free(p);
}
=20
-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i =3D 0;
struct ptest_list *p, *q;
=20
- VALIDATE_PTR_RINT(head);
-
- p =3D head;
+ p =3D *head;
while (p !=3D NULL) {
q =3D p;
p =3D p->next;
=20
ptest_list_free(q);
- i++;
}
-
- return i;
+ *head =3D NULL;
}
=20
int
diff --git a/ptest_list.h b/ptest_list.h
index e583d9f..949250c 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -36,12 +36,6 @@
x =3D NULL; \
} while (0)
=20
-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x =3D NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p =3D head->next; p !=3D =
NULL; p =3D p->next) {
#define PTEST_LIST_ITERATE_END }
=20
@@ -58,7 +52,7 @@ struct ptest_list {
=20
extern struct ptest_list *ptest_list_alloc(void);
extern void ptest_list_free(struct ptest_list *);
-extern int ptest_list_free_all(struct ptest_list *);
+extern void ptest_list_free_all(struct ptest_list **);
=20
extern int ptest_list_length(struct ptest_list *);
extern struct ptest_list *ptest_list_search(struct ptest_list *, char *)=
;
diff --git a/tests/ptest_list.c b/tests/ptest_list.c
index 37d19ae..6bbc13b 100644
--- a/tests/ptest_list.c
+++ b/tests/ptest_list.c
@@ -53,7 +53,7 @@ START_TEST(test_add)
{
struct ptest_list *head =3D ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL, 1) !=3D NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head =3D NULL;
int i;
=20
- ck_assert(ptest_list_free_all(head) =3D=3D -1);
+ ptest_list_free_all(&head);
+ ck_assert(head =3D=3D NULL);
ck_assert(errno =3D=3D EINVAL);
=20
head =3D ptest_list_alloc();
for (i =3D 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);
=20
ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i =3D ptests_num - 1; i >=3D 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) !=3D NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);
=20
ck_assert(ptest_list_search(head, "busybox") !=3D NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
diff --git a/tests/utils.c b/tests/utils.c
index 8df1b54..4e244fe 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -88,13 +88,13 @@ START_TEST(test_get_available_ptests)
for (i =3D 0; ptests_not_found[i] !=3D NULL; i++)
ck_assert(ptest_list_search(head, ptests_not_found[i]) =3D=3D NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
START_TEST(test_print_ptests)
{
- struct ptest_list *head;
+ struct ptest_list *head =3D NULL;
=20
char *buf;
size_t size =3D PRINT_PTEST_BUF_SIZE;
@@ -116,14 +116,14 @@ START_TEST(test_print_ptests)
=20
head =3D ptest_list_alloc();
ck_assert(print_ptests(head, fp) =3D=3D 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line =3D fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line !=3D NULL);
ck_assert(strcmp(line, PRINT_PTESTS_NOT_FOUND) =3D=3D 0);
=20
head =3D get_available_ptests(opts_directory, 1);
ck_assert(print_ptests(head, fp) =3D=3D 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line =3D fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line !=3D NULL);
ck_assert(strcmp(line, PRINT_PTESTS_AVAILABLE) =3D=3D 0);
@@ -144,7 +144,7 @@ END_TEST
START_TEST(test_filter_ptests)
{
struct ptest_list *head =3D get_available_ptests(opts_directory, 1);
- struct ptest_list *head_new;
+ struct ptest_list *head_new =3D NULL;
char *ptest_not_exists[] =3D {
"glib",
};
@@ -161,8 +161,8 @@ START_TEST(test_filter_ptests)
ck_assert(head_new !=3D NULL);
ck_assert(ptest_list_length(head_new) =3D=3D 3);
=20
- ptest_list_free_all(head);
- ptest_list_free_all(head_new);
+ ptest_list_free_all(&head);
+ ptest_list_free_all(&head_new);
}
END_TEST
=20
@@ -191,7 +191,7 @@ START_TEST(test_run_ptests)
=20
rc =3D run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc =3D=3D 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
=20
fclose(fp_stdout);
free(buf_stdout);
@@ -227,7 +227,7 @@ START_TEST(test_run_timeout_duration_ptest)
=20
test_ptest_expected_failure(head, timeout, "hang", search_for_timeout_a=
nd_duration);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -255,7 +255,7 @@ START_TEST(test_run_fail_ptest)
=20
test_ptest_expected_failure(head, timeout, "fail", search_for_fail);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -354,7 +354,7 @@ test_ptest_expected_failure(struct ptest_list *head, =
const int timeout, char *pr
fp_stdout
);
=20
- PTEST_LIST_FREE_ALL_CLEAN(filtered);
+ ptest_list_free_all(&filtered);
}
=20
fclose(fp_stdout);
diff --git a/utils.c b/utils.c
index a23679a..4737bcd 100644
--- a/utils.c
+++ b/utils.c
@@ -110,7 +110,7 @@ get_ptest_file(char **ptest_file, struct stat *st_buf=
, const char *main_dir,
struct ptest_list *
get_available_ptests(const char *dir, int global_timeout)
{
- struct ptest_list *head;
+ struct ptest_list *head =3D NULL;
struct stat st_buf;
=20
int n, i;
@@ -212,7 +212,7 @@ get_available_ptests(const char *dir, int global_time=
out)
free(namelist);
=20
if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head);
+ ptest_list_free_all(&head);
errno =3D saved_errno;
break;
}
@@ -282,7 +282,7 @@ filter_ptests(struct ptest_list *head, char **ptests,=
int ptest_num)
}
=20
if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head_new);
+ ptest_list_free_all(&head_new);
errno =3D saved_errno;
}=20
} while (0);
--=20
2.20.1


[ptest-runner 3/5] mem: Simplify memory management

?ukasz Majewski
 

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Removes the following warnings thrown by
make && valgrind -s --leak-check=3Dfull ./ptest-runner -d tests/data2

=3D=3D4154390=3D=3D Invalid write of size 8
=3D=3D4154390=3D=3D at 0x40360D: run_child (utils.c:357)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D Address 0x4a66440 is 0 bytes inside a block of size =
2 alloc'd
=3D=3D4154390=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154390=3D=3D by 0x4035E4: run_child (utils.c:354)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D
=3D=3D4154390=3D=3D Invalid write of size 8
=3D=3D4154390=3D=3D at 0x403618: run_child (utils.c:358)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D Address 0x4a66448 is 6 bytes after a block of size 2=
alloc'd
=3D=3D4154390=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154390=3D=3D by 0x4035E4: run_child (utils.c:354)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D
=3D=3D4154390=3D=3D Syscall param execve(argv) points to unaddressable by=
te(s)
=3D=3D4154390=3D=3D at 0x4955C2B: execve (in /usr/lib64/libc-2.32.so)
=3D=3D4154390=3D=3D by 0x40365E: run_child (utils.c:368)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)
=3D=3D4154390=3D=3D Address 0x4a66442 is 0 bytes after a block of size 2=
alloc'd
=3D=3D4154390=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154390=3D=3D by 0x4035E4: run_child (utils.c:354)
=3D=3D4154390=3D=3D by 0x403C5B: run_ptests (utils.c:534)
=3D=3D4154390=3D=3D by 0x402C4D: main (main.c:223)

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
utils.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/utils.c b/utils.c
index bce9808..a23679a 100644
--- a/utils.c
+++ b/utils.c
@@ -351,12 +351,9 @@ read_child(void *arg)
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
- char **argv =3D malloc(sizeof(char) * 2);
+ char *const argv[2] =3D {run_ptest, NULL};
chdir(dirname(strdup(run_ptest)));
=20
- argv[0] =3D run_ptest;
- argv[1] =3D NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
--=20
2.20.1


[ptest-runner 2/5] mem: Fix memleak for ptest_opts

?ukasz Majewski
 

From: Adrian Freihofer <adrian.freihofer@siemens.com>

make && valgrind -s --leak-check=3Dfull ./ptest-runner -d tests/data2

=3D=3D4154029=3D=3D HEAP SUMMARY:
=3D=3D4154029=3D=3D in use at exit: 20 bytes in 2 blocks
=3D=3D4154029=3D=3D total heap usage: 45 allocs, 43 frees, 42,909 bytes=
allocated
=3D=3D4154029=3D=3D
=3D=3D4154029=3D=3D 20 (8 direct, 12 indirect) bytes in 1 blocks are defi=
nitely lost in loss record 2 of 2
=3D=3D4154029=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307)
=3D=3D4154029=3D=3D by 0x40252D: str2array (main.c:70)
=3D=3D4154029=3D=3D by 0x402768: main (main.c:119)
=3D=3D4154029=3D=3D
=3D=3D4154029=3D=3D LEAK SUMMARY:
=3D=3D4154029=3D=3D definitely lost: 8 bytes in 1 blocks
=3D=3D4154029=3D=3D indirectly lost: 12 bytes in 1 blocks
=3D=3D4154029=3D=3D possibly lost: 0 bytes in 0 blocks
=3D=3D4154029=3D=3D still reachable: 0 bytes in 0 blocks
=3D=3D4154029=3D=3D suppressed: 0 bytes in 0 blocks
=3D=3D4154029=3D=3D
=3D=3D4154029=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: =
0 from 0)

With this patch valgrind reports 0 errors.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
main.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/main.c b/main.c
index 467548e..e73626c 100644
--- a/main.c
+++ b/main.c
@@ -84,6 +84,25 @@ str2array(char *str, const char *delim, int *num)
return array;
}
=20
+void cleanup_ptest_opts(struct ptest_options *opts)
+{
+ for (int i=3D0; i < opts->dirs_no; i++)
+ free(opts->dirs[i]);
+
+ free(opts->dirs);
+ opts->dirs =3D NULL;
+
+ if (opts->ptests) {
+ free(opts->ptests);
+ opts->ptests =3D NULL;
+ }
+
+ if (opts->xml_filename) {
+ free(opts->xml_filename);
+ opts->xml_filename =3D NULL;
+ }
+}
+
int
main(int argc, char *argv[])
{
@@ -98,7 +117,7 @@ main(int argc, char *argv[])
#endif
=20
struct ptest_list *head, *run;
- struct ptest_options opts;
+ __attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options =
opts;
=20
opts.dirs =3D malloc(sizeof(char **) * 1);
CHECK_ALLOCATION(opts.dirs, 1, 1);
--=20
2.20.1


[ptest-runner 1/5] git: Extend the gitignore

?ukasz Majewski
 

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
.gitignore | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..ef07e6a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+*.o
+ptest-runner
+ptest-runner-test
--=20
2.20.1


[ptest-runner 0/5] ptest: Various memory fixes and enhancements

?ukasz Majewski
 

This patch series provides some memory management fixes and corrected
return code handling for ptest-runner2.

Adrian Freihofer (4):
git: Extend the gitignore
mem: Fix memleak for ptest_opts
mem: Simplify memory management
mem: Refactor ptest_list cleanup

Lukasz Majewski (1):
main: Do not return number of failed tests when calling ptest-runner

.gitignore | 3 +++
main.c | 33 ++++++++++++++++++++++++++++-----
ptest_list.c | 13 ++++---------
ptest_list.h | 8 +-------
tests/ptest_list.c | 13 +++++++------
tests/utils.c | 22 +++++++++++-----------
utils.c | 11 ++++-------
7 files changed, 58 insertions(+), 45 deletions(-)
create mode 100644 .gitignore

--=20
2.20.1


QA notification for completed autobuilder build (yocto-3.4_M2.rc1)

Richard Purdie
 

A build flagged for QA (yocto-3.4_M2.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.4_M2.rc1


Build hash information:

bitbake: 13e2855bff6a6ead6dbd33c5be4b988aafcd4afa
meta-arm: 9efa3b5683a5dd7ebbf63ff31b889ed589ff7a9a
meta-gplv2: b3fa26bc777ec0136ce189d90123b50f6ee567b9
meta-intel: 94c097a82cf9167fa567c2af80d5e39a3fbbc11f
meta-mingw: 8f3b6e3772879dc2caec8fe249ce277fbb1aa55f
oecore: c4fc226c2e3856b942bb4f57ead21a64c3dc8c0d
poky: 1ad79313a5c3e6a453fbeb44caac5c5bbad46d3c


[RP sending manually as the original failed to get through]
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org


Re: [yocto-kernel-cache] [yocto-5.10] nxp-imx8: Enable IMX_SCU_SOC config

Bruce Ashfield
 

In message: RE: [yocto-kernel-cache] [yocto-5.10] nxp-imx8: Enable IMX_SCU_SOC config
on 16/07/2021 Wang, Xiaolei wrote:

Hi bruce

Can you help me merge this patch to yocto-kernel-cache branch yocto-5.10
The original patch didn't have a branch specified, so it somehow managed to
miss my filters.

this is now merged

Bruce


Thanks
Xiaolei

-----Original Message-----
From: linux-yocto@lists.yoctoproject.org <linux-yocto@lists.yoctoproject.org> On Behalf Of Xiaolei Wang
Sent: Friday, July 9, 2021 12:58 PM
To: bruce.ashfield@gmail.com
Cc: linux-yocto@lists.yoctoproject.org
Subject: [linux-yocto] [PATCH] nxp-imx8: Enable IMX_SCU_SOC config

Enable IMX_SCU_SOC config for imx8 get soc_id value and get revision, Because the SW workaround for i.MX8QM TKT340553 is required on the imx8qm board, it is necessary to set TKT340553_SW_WORKAROUND to true in tlbflush.h, otherwise the system will often encounter memory problems and cause hang

Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
bsp/nxp-imx8/nxp-imx8.cfg | 1 +
1 file changed, 1 insertion(+)

diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg index d9ea3caf..dbc77b3a 100644
--- a/bsp/nxp-imx8/nxp-imx8.cfg
+++ b/bsp/nxp-imx8/nxp-imx8.cfg
@@ -475,6 +475,7 @@ CONFIG_OF_OVERLAY=y
CONFIG_MAILBOX=y
CONFIG_IMX_MBOX=y
CONFIG_IMX_SCU=y
+CONFIG_IMX_SCU_SOC=y
CONFIG_IMX_DSP=y
CONFIG_IMX_SCU_PD=y
CONFIG_IIO=y
--
2.25.1


Re: c++ dmalloc library versions not building for Rocko

Khem Raj
 

On Tue, Jul 20, 2021 at 8:25 AM forstevers via lists.yoctoproject.org
<steve=echodyne.com@lists.yoctoproject.org> wrote:

Trying to produce c++ versions of dmalloc libraries.The dmalloc recipe dmalloc_5.5.2.bb looks to be configured to build the c++ versions with:

'EXTRA_OECONF += "--enable-threads --enable-cxx --enable-shlib"'

But in the log.do_configure I see that the autoconf fails to find a c++ compiler, and I end up with the 'c' versions of the dmalloc library.

configure: configurations for the dmalloc library
configure: build utilities
checking for aarch64-xilinx-linux-gcc... aarch64-xilinx-linux-gcc --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-xilinx-linux-gcc --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
checking for aarch64-xilinx-linux-gcc --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether aarch64-xilinx-linux-g++ --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
configure: WARNING: could not find C++ compiler

Any suggestions on how to get this recipe to build the requested c++ versions. Is there a dependency I can add in an append file to force it to recognize the compiler?
there should be a config.log generated in this component's build
directory which should have more information on what check failed and
perhaps some more errors to tell what went wrong.



Re: [layerindex-web][PATCH 00/15] Upgrade to Django 3.2.5 LTS and Celery 5

Richard Purdie
 

On Sun, 2021-07-18 at 16:07 -0700, Tim Orling wrote:
The current code base uses Django 2.2.x which will go out of extended
support in April 2022, but also holds us back from updating a number of
dependencies.

Update to the current Django 3.2.5 LTS and also the latest Celery 5.1.2.
Celery 4 has not had any commits since 2020 and is unlikely to be
getting much more attention from the developers.

While we are at it, upgrade all of our dependencies to the latest
versions.
I don't have the skills to review this in detail but it sounds like a
good step forward for many different reasons, thanks!

Cheers,

Richard


eSDK generation problem

saurabhdaga@...
 

I am generating eSDK for my image which includes meta-qt layer for graphics.
meta-qt uses python3 where as my meta layer uses python2
my meta layer uses python2-mako where as meta-qt layer uses python3-mako.
While generating eSDK both meta layers tries to install mako-render in /usr/bin which generate build error for eSDK generation.
Any suggestion how to resolve this issue.


c++ dmalloc library versions not building for Rocko

forstevers
 

Trying to produce c++ versions of dmalloc libraries.The dmalloc recipe dmalloc_5.5.2.bb looks to be configured to build the c++ versions with:

'EXTRA_OECONF += "--enable-threads --enable-cxx --enable-shlib"'

But in the log.do_configure I see that the autoconf fails to find a c++ compiler, and I end up with the 'c' versions of the dmalloc library.

configure: configurations for the dmalloc library
configure: build utilities
checking for aarch64-xilinx-linux-gcc... aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
checking for aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether aarch64-xilinx-linux-g++  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
configure: WARNING: could not find C++ compiler

Any suggestions on how to get this recipe to build the requested c++ versions. Is there a dependency I can add in an append file to force it to recognize the compiler?


Yocto Project Status WW29`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • We plan to build M2 this week once we have pzstd included in the buildtools tarball
  • Once M2 is built, 3.3.2 will follow into QA.
  • There are proposals to add lz4c, zstd and pzstd as required host commands which we hope will allow better data archiving for license information and possibly for bitbake hash debugging too.
  • There are proposals and discussions on the architecture list around improving the syntax for overrides in the metadata. This would be a major change of a type we haven’t make in a while. The proposal includes the option of allowing the syntax in older bitbake versions to make metadata compatibility easier. Please comment on those discussions on the list if you have opinions on this.
  • The prserv rewrite is still pending on resolving the issues with python asyncio.
  • Intermittent issues are ongoing, particularly ptest ones. Help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others and current test cases are very slow to work with.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: #yocto #yocto

Monsees, Steven C (US)
 

Thanks...

-----Original Message-----
From: Ross Burton <ross@burtonini.com>
Sent: Tuesday, July 20, 2021 5:03 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


Not deleting the source tree is the default behaviour. It sounds like you've inherited rm_work, so if you want to not delete build trees after completion then add the recipe name to RM_WORK_EXCLUDE.

Ross

On Mon, 19 Jul 2021 at 15:22, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



What flag do I set in order to keep the source code for a recipe being built within the build tree after compilation ?



Thanks,

Steve




Re: #yocto #yocto

Ross Burton
 

Not deleting the source tree is the default behaviour. It sounds like
you've inherited rm_work, so if you want to not delete build trees
after completion then add the recipe name to RM_WORK_EXCLUDE.

Ross

On Mon, 19 Jul 2021 at 15:22, Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:




What flag do I set in order to keep the source code for a recipe being built within the build tree after compilation ?



Thanks,

Steve




Re: Exception: NotADirectoryError building Hardknott

Simon Haines <simon.haines@...>
 

On Mon, 19 Jul 2021 at 01:17, Richard Purdie <richard.purdie@...> wrote:
How is your container filesystem setup/configured? It looks like the filesystem
isn't liking the build trying to create hardlinked files. It is odd it would
get as far as gmp-native before having problems. That file definitely isn't a
directory too, it is an odd error.


Thanks Richard, I suspect you're right. I'm using fuse-overlayfs which I'm mounting with the 'noxattrs' option because the host is Fedora and its SELinux configuration interferes with yocto in other ways. It looks like overlayfs uses xattrs in some cases for hard link resolution. I'll have to dig in deeper there, thanks for the pointer.

Cheers,
Simon.


901 - 920 of 55050