yocto@lists.yoctoproject.org

Re: [meta-spdxscanner][PATCH] fossology-rest.bbclass: Moved check if spdx already exists out of the task

leimaohui

Hi Marco

I'm sorry, but your patch seems not base on the latest source code.
https://git.yoctoproject.org/cgit/cgit.cgi/meta-spdxscanner/tree/classes/fossology-rest.bbclass

Best regards
Lei

Show quoted text

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Marco Cavallini
Sent: Thursday, July 22, 2021 9:06 PM
To: yocto@...
Cc: Marco Cavallini <m.cavallini@...>; Marco Cavallini
<koansoftware@...>
Subject: [yocto] [meta-spdxscanner][PATCH] fossology-rest.bbclass: Moved
check if spdx already exists out of the task

From: Marco Cavallini <m.cavallini@...>

 With the previous code was impossible to run the do_get_report  task
whenever a correspondent .spdx file was already present  in
tmp/deploy/spdx.
 Now the check if spdx already exists is at a higher level  therefore is possible
to run : bitbake -c get_report

Signed-off-by: Marco Cavallini <koansoftware@...>
---
 classes/fossology-rest.bbclass | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/classes/fossology-rest.bbclass b/classes/fossology-rest.bbclass index
3694440..e55e859 100644
--- a/classes/fossology-rest.bbclass
+++ b/classes/fossology-rest.bbclass
@@ -84,6 +84,15 @@ python () {
         create_manifest(info,sstatefile)
         return

+    # if spdx already exists
+    if os.path.exists(info['outfile']):
+        bb.note(info['pn'] + "spdx file has been exist, do nothing")
+        return
+    if os.path.exists( sstatefile ):
+        bb.note(info['pn'] + "spdx file has been exist, do nothing")
+        create_manifest(info,sstatefile)
+        return
+
     d.appendVarFlag('do_spdx', 'depends', ' %s:do_get_report' % pn)
     bb.build.addtask('do_get_report', 'do_configure', 'do_patch' , d)
     bb.build.addtask('do_spdx', 'do_configure', 'do_get_report', d) @@
-157,15 +166,6 @@ python do_get_report () {
     info['outfile'] = os.path.join(manifest_dir, info['pn'] + "-" + info['pv'] +
".spdx" )
     sstatefile = os.path.join(spdx_outdir, info['pn'] + "-" + info['pv'] + ".spdx" )

-    # if spdx has been exist
-    if os.path.exists(info['outfile']):
-        bb.note(info['pn'] + "spdx file has been exist, do nothing")
-        return
-    if os.path.exists( sstatefile ):
-        bb.note(info['pn'] + "spdx file has been exist, do nothing")
-        create_manifest(info,sstatefile)
-        return
-
     spdx_get_src(d)

     bb.note('SPDX: Archiving the patched source...')
--
2.17.1

Re: [meta-rockchip][PATCH] rock-pi-e: update preferred kernel

Trevor Woerner

#54222

On Tue, Jul 13, 2021 at 7:32 PM Trevor Woerner <twoerner@...> wrote:

The latest updates to linux-yocto-dev now include support for the rock-pi-e so
do away with our custom recipe and use the one from oe-core.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/rock-pi-e.conf | 2 +-
.../linux/linux-stable-bleeding_5.11.bb | 18 ------------------
recipes-kernel/linux/linux-yocto%.bbappend | 1 +
3 files changed, 2 insertions(+), 19 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-stable-bleeding_5.11.bb

applied to meta-rockchip master

Re: [meta-rockchip][PATCH] remove LINUX_VERSION_EXTENSION

Trevor Woerner

#54221

On Tue, Jul 13, 2021 at 7:32 PM Trevor Woerner <twoerner@...> wrote:

Adding "-rockchip" to the Linux kernel name implies, to me anyway, that this
is a vendor kernel. The PREFERRED_PROVIDERs of all kernels specified in this
BSP are upstream linux-yocto kernels, not vendor kernels. Therefore remove the
version name extension to avoid confusion.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

applied to meta-rockchip master

Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: July 22, 2021 -- resend

Randy MacLeod

#54220

Resend:

The list:
   Yocto discussion list <yocto@...>
didn't work and may be dead so switch to:
   yocto@... <yocto@...>
../Randy



YP AB Intermittent failures meeting
===================================
July 22, 2021, 9 AM ET
https://windriver.zoom.us/j/3696693975

Attendees:  Tony, Richard, Trevor, Randy, Tony


Summary:
========

ptest failures, somewhat improved AGAIN but still seeing
problems particularly with LTT-NG.


If anyone wants to help, we could use more eyes on the logs,
particularly the summary logs and understanding iostat #
when the dd test times out.



Plans for the week:
===================

All: Wait and see if the ptest failure rate continues to be lower
     than previous weeks.

  Richard:
  Alex:
  Sakib: hook more responsive load average in to latency test.
  Trevor: patch to set PARALLEL_MAKE : -l 50
    -> dunfell, gatesgarth, hardknott
  Tony:
  Saul: on vacation
  Randy: Look at performance data


Meeting Notes:
==============

1, runqemu (same as last week so I'll drop this comment next week)

Tony having trouble with runqemu on some Wind River machine.
Richard has a fix for a race in runqemu in master-next.
These might be related but if not Tony should debug the
issue/ collect logs.

2. job server

- ninja could be patched with make's more responsive algorithm
  next or is this good enough?

- Richard suggested that we extract make's code for measuring the load
  average to a separate binary and run it in the periodic io latency
  test. Also can we translate it to python?
  - Trevor is working on this.

- performance build servers
  - fewer failures there so no point in limiting jobs and
    it would be disruptive to performance monitoring.


3. AB status

   ptest cases are improving, we may be close to done!
   Let's wait a week to see how things go.


4. Nothing new on this item this week:
   Richard reported
   - something really flaky going on with serial ports.
   - particularly bad on qemuppc but also x86.
   - related to Saul's QMP data dump?
   - Juy 22: We didn't talk about this issue this week.

5. Sakib's improvements to the logging are merged.
   We think Michael needs to update the script that generates the
   web page. Randy/Sakib to talk with Michael.

6. (From July 8)
   Richard says that we may need to redesign the data collection system
   that Sakib's AB INT tests are based on.



Still relevant parts of
Previous Meeting Notes:
=======================


4. bitbake server timeout.

   "Timeout while waiting for a reply from the bitbake server (60s)"

   Randy mentioned that the bitbake server timeouts seen in the
   Wind River build cluster have gone away after upgrading to
   a newer version of docker.

   Old: Docker Version: Docker version 18.09.4, build d14af54266
   New: Docker Version: Docker version 20.10.7, build f0df350


   Clearly the YP ABs aren't running in docker but what
   about firmware and kernel tunings.

   Michael,

   Is the BIOS/firmware kept up to date on most nodes?
   - July 22: This was done.


   For the performance builder trend see:

https://autobuilder.yocto.io/pub/non-release/20210721-9/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_master_20210721150057_1ad79313a5.html


https://autobuilder.yocto.io/pub/non-release/20210721-14/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20210721210034_1ad79313a5.html


   Summary,
    - CentOS-7 seems to take less time (~ 1 min),
    - Ubuntu-16.04 seems to take more (~ 5 min)
   That's a bit surprising!
   Randy to look at 62659 commit number in poky.


5. io stalls

   Richard said that it would make sense to write an ftrace utility
   / script to monitor io latency and we could install it with sudo
   Ch^W mentioned ftrace on IRC.
   Sakib and Randy will work on that but not for a week or two.





../Randy

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

Anibal Limon

#54219

Hi,

I tried to apply without success, looks like the patch is corrupted, can you send it again?, or share a git repo/branch.

Regards,

Anibal

Show quoted text

On Mon, 26 Jul 2021 at 11:10, Anibal Limon <anibal.limon@...> wrote:

Indeed this change doesn't has a direct impact but is fine to me.

Applied, Thanks!

On Wed, 21 Jul 2021 at 04:47, ?ukasz Majewski <lukma@...> wrote:
From: Adrian Freihofer <adrian.freihofer@...>

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@...>
---
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

- struct ptest_list *head, *run;
+ struct ptest_list *head = NULL;
+ struct ptest_list *run = NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options opts;

opts.dirs = malloc(sizeof(char **) * 1);
@@ -175,7 +176,7 @@ main(int argc, char *argv[])

head = NULL;
for (i = 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp = NULL;

tmp = get_available_ptests(opts.dirs[i], opts.timeout);
if (tmp == NULL) {
@@ -211,7 +212,7 @@ main(int argc, char *argv[])

run = 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);
}

for (i = 0; i < ptest_exclude_num; i++)
@@ -219,7 +220,7 @@ main(int argc, char *argv[])

rc = run_ptests(run, opts, argv[0], stdout, stderr);

- ptest_list_free_all(run);
+ ptest_list_free_all(&run);

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);
}

-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i = 0;
struct ptest_list *p, *q;

- VALIDATE_PTR_RINT(head);
-
- p = head;
+ p = *head;
while (p != NULL) {
q = p;
p = p->next;

ptest_list_free(q);
- i++;
}
-
- return i;
+ *head = NULL;
}

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 = NULL; \
} while (0)

-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x = NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p = head->next; p != NULL; p = p->next) {
#define PTEST_LIST_ITERATE_END }

@@ -58,7 +52,7 @@ struct ptest_list {

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 **);

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 = ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL, 1) != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head = NULL;
int i;

- ck_assert(ptest_list_free_all(head) == -1);
+ ptest_list_free_all(&head);
+ ck_assert(head == NULL);
ck_assert(errno == EINVAL);

head = ptest_list_alloc();
for (i = 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);

ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i = ptests_num - 1; i >= 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) != NULL);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);

ck_assert(ptest_list_search(head, "busybox") != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

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 = 0; ptests_not_found[i] != NULL; i++)
ck_assert(ptest_list_search(head, ptests_not_found[i]) == NULL);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

START_TEST(test_print_ptests)
{
- struct ptest_list *head;
+ struct ptest_list *head = NULL;

char *buf;
size_t size = PRINT_PTEST_BUF_SIZE;
@@ -116,14 +116,14 @@ START_TEST(test_print_ptests)

head = ptest_list_alloc();
ck_assert(print_ptests(head, fp) == 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line != NULL);
ck_assert(strcmp(line, PRINT_PTESTS_NOT_FOUND) == 0);

head = get_available_ptests(opts_directory, 1);
ck_assert(print_ptests(head, fp) == 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line != NULL);
ck_assert(strcmp(line, PRINT_PTESTS_AVAILABLE) == 0);
@@ -144,7 +144,7 @@ END_TEST
START_TEST(test_filter_ptests)
{
struct ptest_list *head = get_available_ptests(opts_directory, 1);
- struct ptest_list *head_new;
+ struct ptest_list *head_new = NULL;
char *ptest_not_exists[] = {
"glib",
};
@@ -161,8 +161,8 @@ START_TEST(test_filter_ptests)
ck_assert(head_new != NULL);
ck_assert(ptest_list_length(head_new) == 3);

- ptest_list_free_all(head);
- ptest_list_free_all(head_new);
+ ptest_list_free_all(&head);
+ ptest_list_free_all(&head_new);
}
END_TEST

@@ -191,7 +191,7 @@ START_TEST(test_run_ptests)

rc = run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc == 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);

fclose(fp_stdout);
free(buf_stdout);
@@ -227,7 +227,7 @@ START_TEST(test_run_timeout_duration_ptest)

test_ptest_expected_failure(head, timeout, "hang", search_for_timeout_and_duration);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -255,7 +255,7 @@ START_TEST(test_run_fail_ptest)

test_ptest_expected_failure(head, timeout, "fail", search_for_fail);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -354,7 +354,7 @@ test_ptest_expected_failure(struct ptest_list *head, const int timeout, char *pr
fp_stdout
);

- PTEST_LIST_FREE_ALL_CLEAN(filtered);
+ ptest_list_free_all(&filtered);
}

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 = NULL;
struct stat st_buf;

int n, i;
@@ -212,7 +212,7 @@ get_available_ptests(const char *dir, int global_timeout)
free(namelist);

if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head);
+ ptest_list_free_all(&head);
errno = saved_errno;
break;
}
@@ -282,7 +282,7 @@ filter_ptests(struct ptest_list *head, char **ptests, int ptest_num)
}

if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head_new);
+ ptest_list_free_all(&head_new);
errno = saved_errno;
}
} while (0);
--
2.20.1

Re: Private: Re: [yocto] Recipe dependent on Debian package - How should I approach? #debian #yocto

William Huang

#54218

cc-ing yocto list

Show quoted text

On Mon, Jul 26, 2021 at 10:04 AM Mitch Gaines <gainesmitch2@...> wrote:

So, that is something I already have. What I really need are the systemd header files in order to build my recipe. Looks like the log output didn't format well. Let me re-post that below with some better formatting and you'll see what I'm referring to. How can I get those header files to build with my project? I thought just adding it as a DEPENDS would do it, but that doesn't seem to be the case.

NOTE: Executing Tasks
ERROR: <recipe-name> do_compile: oe_runmake failed
ERROR: <recipe-name> do_compile: Execution of '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/run.do_compile.13271' failed with exit code 1:
make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core'
CC file-name.c
../file-name.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory
    6 | #include <systemd/sd-daemon.h>
      |          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:93: build/file-name.o] Error 1
make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core'
make: *** [Makefile:72: some-recipe] Error 2
WARNING: exit code 1 from a shell command.

ERROR: Logfile of failure stored in: /home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/log.do_compile.13271
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 24 my-project
| make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core'
| CC my-file.c
| ../my-file.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory
|     6 | #include <systemd/sd-daemon.h>
|       |          ^~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
| make[1]: *** [Makefile:93: build/my-file.o] Error 1
| make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core'
| make: *** [Makefile:72: my-project] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Execution of '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/run.do_compile.13271' failed with exit code 1:
| make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core'
| CC my-file.c
| ../my-file.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory
|     6 | #include <systemd/sd-daemon.h>
|       |          ^~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
| make[1]: *** [Makefile:93: build/my-file.o] Error 1
| make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core'
| make: *** [Makefile:72: my-recipe] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/home/mitch/bin/yocto/project-name/layers/meta-project/recipes-main/my-recipe/my-recipe_git.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2166 tasks of which 2163 didn't need to be rerun and 1 failed.

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

Anibal Limon

#54217

Indeed this change doesn't has a direct impact but is fine to me.

Applied, Thanks!

Show quoted text

On Wed, 21 Jul 2021 at 04:47, ?ukasz Majewski <lukma@...> wrote:

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

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@...>
---
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

- struct ptest_list *head, *run;
+ struct ptest_list *head = NULL;
+ struct ptest_list *run = NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options opts;

opts.dirs = malloc(sizeof(char **) * 1);
@@ -175,7 +176,7 @@ main(int argc, char *argv[])

head = NULL;
for (i = 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp = NULL;

tmp = get_available_ptests(opts.dirs[i], opts.timeout);
if (tmp == NULL) {
@@ -211,7 +212,7 @@ main(int argc, char *argv[])

run = 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);
}

for (i = 0; i < ptest_exclude_num; i++)
@@ -219,7 +220,7 @@ main(int argc, char *argv[])

rc = run_ptests(run, opts, argv[0], stdout, stderr);

- ptest_list_free_all(run);
+ ptest_list_free_all(&run);

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);
}

-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i = 0;
struct ptest_list *p, *q;

- VALIDATE_PTR_RINT(head);
-
- p = head;
+ p = *head;
while (p != NULL) {
q = p;
p = p->next;

ptest_list_free(q);
- i++;
}
-
- return i;
+ *head = NULL;
}

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 = NULL; \
} while (0)

-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x = NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p = head->next; p != NULL; p = p->next) {
#define PTEST_LIST_ITERATE_END }

@@ -58,7 +52,7 @@ struct ptest_list {

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 **);

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 = ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL, 1) != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head = NULL;
int i;

- ck_assert(ptest_list_free_all(head) == -1);
+ ptest_list_free_all(&head);
+ ck_assert(head == NULL);
ck_assert(errno == EINVAL);

head = ptest_list_alloc();
for (i = 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL, 1);

ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i = ptests_num - 1; i >= 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) != NULL);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);

ck_assert(ptest_list_search(head, "busybox") != NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

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 = 0; ptests_not_found[i] != NULL; i++)
ck_assert(ptest_list_search(head, ptests_not_found[i]) == NULL);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

START_TEST(test_print_ptests)
{
- struct ptest_list *head;
+ struct ptest_list *head = NULL;

char *buf;
size_t size = PRINT_PTEST_BUF_SIZE;
@@ -116,14 +116,14 @@ START_TEST(test_print_ptests)

head = ptest_list_alloc();
ck_assert(print_ptests(head, fp) == 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line != NULL);
ck_assert(strcmp(line, PRINT_PTESTS_NOT_FOUND) == 0);

head = get_available_ptests(opts_directory, 1);
ck_assert(print_ptests(head, fp) == 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line != NULL);
ck_assert(strcmp(line, PRINT_PTESTS_AVAILABLE) == 0);
@@ -144,7 +144,7 @@ END_TEST
START_TEST(test_filter_ptests)
{
struct ptest_list *head = get_available_ptests(opts_directory, 1);
- struct ptest_list *head_new;
+ struct ptest_list *head_new = NULL;
char *ptest_not_exists[] = {
"glib",
};
@@ -161,8 +161,8 @@ START_TEST(test_filter_ptests)
ck_assert(head_new != NULL);
ck_assert(ptest_list_length(head_new) == 3);

- ptest_list_free_all(head);
- ptest_list_free_all(head_new);
+ ptest_list_free_all(&head);
+ ptest_list_free_all(&head_new);
}
END_TEST

@@ -191,7 +191,7 @@ START_TEST(test_run_ptests)

rc = run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc == 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);

fclose(fp_stdout);
free(buf_stdout);
@@ -227,7 +227,7 @@ START_TEST(test_run_timeout_duration_ptest)

test_ptest_expected_failure(head, timeout, "hang", search_for_timeout_and_duration);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -255,7 +255,7 @@ START_TEST(test_run_fail_ptest)

test_ptest_expected_failure(head, timeout, "fail", search_for_fail);

- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST

@@ -354,7 +354,7 @@ test_ptest_expected_failure(struct ptest_list *head, const int timeout, char *pr
fp_stdout
);

- PTEST_LIST_FREE_ALL_CLEAN(filtered);
+ ptest_list_free_all(&filtered);
}

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 = NULL;
struct stat st_buf;

int n, i;
@@ -212,7 +212,7 @@ get_available_ptests(const char *dir, int global_timeout)
free(namelist);

if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head);
+ ptest_list_free_all(&head);
errno = saved_errno;
break;
}
@@ -282,7 +282,7 @@ filter_ptests(struct ptest_list *head, char **ptests, int ptest_num)
}

if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head_new);
+ ptest_list_free_all(&head_new);
errno = saved_errno;
}
} while (0);
--
2.20.1

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

Anibal Limon

#54216

Applied, Thanks!,

Show quoted text

On Wed, 21 Jul 2021 at 04:47, ?ukasz Majewski <lukma@...> wrote:

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

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

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

Signed-off-by: Adrian Freihofer <adrian.freihofer@...>
---
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 = malloc(sizeof(char) * 2);
+ char *const argv[2] = {run_ptest, NULL};
chdir(dirname(strdup(run_ptest)));

- argv[0] = run_ptest;
- argv[1] = NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
--
2.20.1

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

Anibal Limon

#54215

Hi,

In a normal execution this memleak doesn't have a bad effect in practical terms because at end of the program the memory will be free'd.

I'm fine to pick this patch.

Regards,

Anibal

Show quoted text

On Wed, 21 Jul 2021 at 04:46, ?ukasz Majewski <lukma@...> wrote:

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

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

==4154029== HEAP SUMMARY:
==4154029== in use at exit: 20 bytes in 2 blocks
==4154029== total heap usage: 45 allocs, 43 frees, 42,909 bytes allocated
==4154029==
==4154029== 20 (8 direct, 12 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2
==4154029== at 0x4839809: malloc (vg_replace_malloc.c:307)
==4154029== by 0x40252D: str2array (main.c:70)
==4154029== by 0x402768: main (main.c:119)
==4154029==
==4154029== LEAK SUMMARY:
==4154029== definitely lost: 8 bytes in 1 blocks
==4154029== indirectly lost: 12 bytes in 1 blocks
==4154029== possibly lost: 0 bytes in 0 blocks
==4154029== still reachable: 0 bytes in 0 blocks
==4154029== suppressed: 0 bytes in 0 blocks
==4154029==
==4154029== 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@...>
---
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;
}

+void cleanup_ptest_opts(struct ptest_options *opts)
+{
+ for (int i=0; i < opts->dirs_no; i++)
+ free(opts->dirs[i]);
+
+ free(opts->dirs);
+ opts->dirs = NULL;
+
+ if (opts->ptests) {
+ free(opts->ptests);
+ opts->ptests = NULL;
+ }
+
+ if (opts->xml_filename) {
+ free(opts->xml_filename);
+ opts->xml_filename = NULL;
+ }
+}
+
int
main(int argc, char *argv[])
{
@@ -98,7 +117,7 @@ main(int argc, char *argv[])
#endif

struct ptest_list *head, *run;
- struct ptest_options opts;
+ __attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options opts;

opts.dirs = malloc(sizeof(char **) * 1);
CHECK_ALLOCATION(opts.dirs, 1, 1);
--
2.20.1

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

Anibal Limon

#54214

Applied, Thanks!, Anibal.

Show quoted text

On Wed, 21 Jul 2021 at 04:47, ?ukasz Majewski <lukma@...> wrote:

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

Signed-off-by: Adrian Freihofer <adrian.freihofer@...>
---
.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
--
2.20.1

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

Anibal Limon

#54213

Hi all,

Just replied in other email about this situation, so yes for me is better at least return 1 when any test fails to make it backwards compatible and knows when some test fails.

Regards,

Anibal

Show quoted text

On Mon, 26 Jul 2021 at 02:00, Tero Kinnunen <tero.kinnunen@...> wrote:

I would favor to keep non-zero exit value if any tests failed. We have relied on exit value since ptest started to support it, others may be doing that as well. This would be backward incompatible change, making tests silently fail. It is somewhat clumsy to try to parse failed tests from output, so non-zero rc was very welcome change to me.

Looking at other test runners, it is very common to return non-zero if any tests failed. (Some examples: pytest, python unittest, googletest, shunit2, robot framework.) See pytest exit codes for example: https://docs.pytest.org/en/latest/reference/exit-codes.html

Indeed the failed count is not a good exit value though because of rollover, should be fixed. Could consider using own rc for "any tests failed" differentiating from other errors.

- Tero

Re: Recipe dependent on Debian package - How should I approach? #debian #yocto

William Huang

#54212

Hi Mitch,
You can get systemd into your image... refer to the mega-manual:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-systemd-exclusively
Hopefully this resolves your issue.

- William Huang

Show quoted text

On Mon, Jul 26, 2021 at 9:30 AM Mitch Gaines <gainesmitch2@...> wrote:

I have a project I am attempting to migrate from a Debian platform to Yocto. This specific project has a dependency on libsystemd-dev which is a Debian package, but it doesn't seem to build when adding a DEPENDS on "systemd" which is available on yocto. What is the best approach for migrating dependencies in this manner? I'm sure I am going to run into other projects to migrate which require Debian packages that are not directly available on Yocto. Or am I doing something wrong? See this specific example outlined below:

Below is a recipe for a Makefile C project that was mostly generated with `recipetool create`. I then added the DEPENDS on "systemd" and removed the unused tasks:
    # Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be fully functional.
# (Feel free to remove these comments when editing.)

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
# your responsibility to verify that the values are complete and correct.
#
# The following license files were not able to be identified and are
# represented as "Unknown" below, you will need to check them yourself:
#   debian/copyright
LICENSE = "Unknown"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=some-hash"

SRC_URI = "git://git@...;protocol=ssh"

# Modify these as desired
PV = "1.0+git${SRCPV}"
SRCREV = "<...>"

S = "${WORKDIR}/git"
DEPENDS = "systemd"

# NOTE: this is a Makefile-only piece of software, so we cannot generate much of the
# recipe automatically - you will need to examine the Makefile yourself and ensure
# that the appropriate arguments are passed in.


do_compile () {
    oe_runmake my-project
}
Whenever I bitbake this recipe, I get the following:


NOTE: Executing Tasks ERROR: <recipe-name> do_compile: oe_runmake failed ERROR: <recipe-name> do_compile: Execution of '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/run.do_compile.13271' failed with exit code 1: make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' CC file-name.c ../file-name.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory 6 | #include <systemd/sd-daemon.h> | ^~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:93: build/file-name.o] Error 1 make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' make: *** [Makefile:72: some-recipe] Error 2 WARNING: exit code 1 from a shell command. ERROR: Logfile of failure stored in: /home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/log.do_compile.13271 Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 24 my-project | make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' | CC my-file.c | ../my-file.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory | 6 | #include <systemd/sd-daemon.h> | | ^~~~~~~~~~~~~~~~~~~~~ | compilation terminated. | make[1]: *** [Makefile:93: build/my-file.o] Error 1 | make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' | make: *** [Makefile:72: my-project] Error 2 | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Execution of '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/run.do_compile.13271' failed with exit code 1: | make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' | CC my-file.c | ../my-file.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory | 6 | #include <systemd/sd-daemon.h>


Am I doing anything overtly wrong here? Would appreciate any assistance you can provide.

Thanks!

Recipe dependent on Debian package - How should I approach? #debian #yocto

Mitch Gaines <gainesmitch2@...>

#54211

I have a project I am attempting to migrate from a Debian platform to Yocto. This specific project has a dependency on libsystemd-dev which is a Debian package, but it doesn't seem to build when adding a DEPENDS on "systemd" which is available on yocto. What is the best approach for migrating dependencies in this manner? I'm sure I am going to run into other projects to migrate which require Debian packages that are not directly available on Yocto. Or am I doing something wrong? See this specific example outlined below:

Below is a recipe for a Makefile C project that was mostly generated with `recipetool create`. I then added the DEPENDS on "systemd" and removed the unused tasks:

# Recipe created by recipetool

# This is the basis of a recipe and may need further editing in order to be fully functional.

# (Feel free to remove these comments when editing.)

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is

# your responsibility to verify that the values are complete and correct.

#

# The following license files were not able to be identified and are

# represented as "Unknown" below, you will need to check them yourself:

# debian/copyright

LICENSE = "Unknown"

LIC_FILES_CHKSUM = "file://debian/copyright;md5=some-hash"

SRC_URI = "git://git@...;protocol=ssh"

# Modify these as desired

PV = "1.0+git${SRCPV}"

SRCREV = "<...>"

S = "${WORKDIR}/git"

DEPENDS = "systemd"

# NOTE: this is a Makefile-only piece of software, so we cannot generate much of the

# recipe automatically - you will need to examine the Makefile yourself and ensure

# that the appropriate arguments are passed in.

do_compile () {

oe_runmake my-project

}

Whenever I bitbake this recipe, I get the following:

NOTE: Executing Tasks ERROR: <recipe-name> do_compile: oe_runmake failed ERROR: <recipe-name> do_compile: Execution of '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/run.do_compile.13271' failed with exit code 1: make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' CC file-name.c ../file-name.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory 6 | #include <systemd/sd-daemon.h> | ^~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:93: build/file-name.o] Error 1 make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' make: *** [Makefile:72: some-recipe] Error 2 WARNING: exit code 1 from a shell command. ERROR: Logfile of failure stored in: /home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/log.do_compile.13271 Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 24 my-project | make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' | CC my-file.c | ../my-file.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory | 6 | #include <systemd/sd-daemon.h> | | ^~~~~~~~~~~~~~~~~~~~~ | compilation terminated. | make[1]: *** [Makefile:93: build/my-file.o] Error 1 | make[1]: Leaving directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' | make: *** [Makefile:72: my-project] Error 2 | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Execution of '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/temp/run.do_compile.13271' failed with exit code 1: | make[1]: Entering directory '/home/mitch/bin/yocto/project-name/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/recipe-name/1.0+gitAUTOINC+...-r0/git/src/core' | CC my-file.c | ../my-file.c:6:10: fatal error: systemd/sd-daemon.h: No such file or directory | 6 | #include <systemd/sd-daemon.h>

Am I doing anything overtly wrong here? Would appreciate any assistance you can provide.

Thanks!

[wic/filemap] wic takes the wrong filemap.py file

jonas.hoelscher@...

#54210

Hi guys,

i am running yocto (with IMX BSP gatesgarth-5.10.9-1.0.0) inside docker and am getting the below issue which i though to be already fixed by https://patchwork.openembedded.org/patch/174423/.
File "/home/dev/my-yocto/build/tmp/work/imx8mn_bat_bs4_dev-poky-linux/my-image/1.0-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/bmaptools/Filemap.py", line 238, in _probe_seek_hole##[error]#15 18105.0 raise ErrorNotSupp("the file-system does not support "SEEK_HOLE" and "SEEK_DATA" but only provides a stub implementation

Obviously the file "Filemap.py" getting used is the one downloaded via the bmap-tools recipe. It does not contain the fix linked above.
./build/tmp/work/x86_64-linux/bmap-tools-native/3.5+gitAUTOINC+a17f0e3ff8-r0/sysroot-destdir/home/<...>/build/tmp/work/x86_64-linux/bmap-tools-native/3.5+gitAUTOINC+a17f0e3ff8-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/bmaptools/Filemap.py
Why does it not take the one from sources/poky/scripts/lib/wic/filemap.py which does have the desired fix ?

Any pointer / hint is appreciated.

Thanks and Regards,
Jonas

Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4_M2.rc1)

Sangeeta Jain

#54209

Hello all,

This is the full report for yocto-3.4_M2.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects. 

2 new issue found 

BUG id:14489 - [3.4 M2 beaglebone] There are some warnings for xkbcomp on boot
   
BUG id:14491 - [QA 3.4_M2.rc1] - stap.StapTest.test_stap failure
  
  
======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?14489
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14491

Thanks,
Sangeeta

Show quoted text

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Wednesday, 21 July, 2021 5:22 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.4_M2.rc1)

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@...

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

Tero Kinnunen

#54208

I would favor to keep non-zero exit value if any tests failed. We have relied on exit value since ptest started to support it, others may be doing that as well. This would be backward incompatible change, making tests silently fail. It is somewhat clumsy to try to parse failed tests from output, so non-zero rc was very welcome change to me.

Looking at other test runners, it is very common to return non-zero if any tests failed. (Some examples: pytest, python unittest, googletest, shunit2, robot framework.) See pytest exit codes for example: https://docs.pytest.org/en/latest/reference/exit-codes.html

Indeed the failed count is not a good exit value though because of rollover, should be fixed. Could consider using own rc for "any tests failed" differentiating from other errors.

- Tero

[PATCH yocto-autobuilder-helper] auh-config: enable systemd only for glibc

Alexander Kanavin

#54207

It is not guaranteed to build or work otherwise, and causes
update failures in unrelated recipes when building for musl for instance.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
 scripts/auh-config/local.conf.append | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
index b18590f..417d228 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,4 +1,5 @@
 
 INHERIT += "buildhistory"
 LICENSE_FLAGS_WHITELIST = "commercial"
-DISTRO_FEATURES_append = ' systemd pam'
+DISTRO_FEATURES_append_libc-glibc = ' systemd'
+DISTRO_FEATURES_append = ' pam'
-- 
2.31.1

Re: [PATCH yocto-autobuilder-helper] Enable canary builds for meta-aws[aws-iot-device-sdk-cpp-v2] on x86-64 and arm64.

Richard Purdie

#54206

On Thu, 2021-07-22 at 17:29 -0400, elberger via lists.yoctoproject.org wrote:
From: Richard Elberger <elberger@...>

This patch provides the buildbot system to make the aws-iot-device-sdk-cpp-v2.
- build on poky
- meta-openembedded and meta-aws are additional repo dependencies
- build for the two dominant architectures: x86-64 and arm64.

Signed-off-by: Richard Elberger <elberger@...>
---
 config.json | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/config.json b/config.json
index 3709b40..f04fac8 100644
--- a/config.json
+++ b/config.json
@@ -350,6 +350,23 @@
                 "BBTARGETS": "agl-image-core-autobuilder"
             }
         },
+        "meta-aws" : {
+            "NEEDREPOS" : ["poky", "meta-openembedded", "meta-aws"],
+            "ADDLAYER" : [
+                "${BUILDDIR}/../meta-openembedded/meta-oe",
+                "${BUILDDIR}/../meta-openembedded/meta-networking",
+                "${BUILDDIR}/../meta-openembedded/meta-python",
+                "${BUILDDIR}/../meta-aws"The ordering isn't correct here since they have to be added in dependency 
order and for some reason this was different to the patch we discussed 
previously. I've just gone ahead and fixed it.

Cheers,

Richard

Re: [poky] [PATCH] local.conf.sample: disable prelink

Robert Berger

#54205

On 22/07/2021 22:05, Alexander Kanavin wrote:
PIE is nowadays more or less the only available option and is expected for improved security; Yocto does not even test non-PIE builds or provide an off the shelf way to turn it off.I am worried about those libraries, which are non-PIE libraries by default. My theory is, that they are non-PIE since prelink is able to operate on them. So prelink can "at least" be used a PIE detector.

They are:

lib/libdl-2.33.so is prelinked
lib/ld-2.33.so is prelinked
lib/libpthread-2.33.so is prelinked
lib/libc-2.33.so is prelinked

Is there are rational explanation why they are not compiled in PIE mode and/or if they are compiled in PIE mode how cross-prelink can operate on them? If cross-prelink can operate on them why not on the others?

I also have to note that prelink does show higher RAM consumption in your tests as well (MemFree column). On the constrained systems which would benefit most from improved prelink timings that might be a bigger loss than not prelinking.I guess we agree that MemFree shows free physical memory (user and kernel space).

My experiments show, that non-PIE and no prelink leaves the biggest amount of free physical memory.

They also show that non-PIE and prelink leave the smallest amount of free physical memory ;)

The difference is significant
prelinked-no-pie/no-prelink-no-pie:		4552 (kB)

If we leave things are they are:
prelinked-no-pie/prelinked-with-pie:		3972 (kB)

If we disable prelink (as you suggest - and I tend to agree since it does not make sense as it is right now)
prelinked-no-pie/no-prelink-with-pie:		4120 (kB)

...

but

if you look at the next line MemAvailable kB things looks a bit differently.

My interpretation of MemAvailable is, that it is an estimate of virtual memory available after reclaimable parts of memory (caches, buffer, slab,...) have been reclaimed without getting swap involved.

I see this:

MemAvailable kB

prelinked-with-pie 	939412
no-prelink-with-pie	939696
prelinked-no-pie	940344
no-prelink-no-pie	941216

Which means, that our current default setting is the worst possible solution ;)

no-prelink-no-pie would (theoretically) be the best.

I will try to update my second article and try to explain a bit more my interpretation of the results and maybe also try to see what bootchart says to all this.

Don't get me wrong. I am neither pro nor con prelink. I just would like to understand what it does, if it does something ;)

I spent quite some time on this - also discussing with most of you offline.
If you ask me, we should use your patch, since people didn't even notice that prelink can not prelink on PIE binaries for a couple of years.

So there does not seem to be much demand for it ;)

We can keep a "placebo" in for the homeopaths who think they use prelink in their images since PIE was enabled ;)

But yes, there is a timing benefit visible in the tests: 0.01s vs 0.1s.Also less CPU usage can be seen. I hope I'll find time to run some test with bootchart. Maybe then we can also see boot time, memory, CPU,...

Regards,

Robert

Alex
On Mon, 19 Jul 2021 at 22:58, Robert Berger@... <robert.berger.yocto.user@... <mailto:robert.berger.yocto.user@...>> wrote:
Hi Alex, RP, Mark,
I did some research on the subject in order to try to figure out
    what is
    going on.
1) I come to a similar conclusion with what found, but tried to look a
    bit deeper for the reason.
1.1) The reason that cross-prelink is not prelinking is, that for a
    quite some time by default everything is built with PIE mode by default
    and cross-prelink does not seem to be able to work on exe/libs compiled
    with PIE mode. So seeing the same behavior with and without prelinking
    is what I would expect as long as everything is compiled with PIE mode.
A more detailed analysis of my tests can be found on my not yet
    officially published site:
https://rlbl.me/prelink-1 <https://rlbl.me/prelink-1>
https://rlbl.me/prelink-2 <https://rlbl.me/prelink-2>
Alex:
Can you please rebuild your test images without PIE mode and re-run the
    tests?
Then we should have the 4 test cases:
prelinked-with-pie
    no-prelink-with-pie
    prelink-no-pie
    no-prelink-no-pie
I guess then we can discuss what are the next steps.
In my opinion the current default settings, which compile close to
    everything in PIE mode, but invoke also cross-prelink do not make much
    sense.
The question is: "Do we want to drop cross-prelink, or do we want to
    drag it along and come up more fine-grained configuration options?"
We could e.g. exclude certain files from pre-linking.
IMHO cross-prelink still works, but not on exe/libs which were compiled
    in PIE mode.
Regards,
Robert

Re: #yocto #yocto

Yocto

#54204

maybe clear your build tmp cache sstate and rebuild

Show quoted text

On Friday 23 July 2021 13:26:08 PM (+07:00), sateesh m wrote:

Hi Guys,

I am facing below error while compiling consul package. can anybody know this issue please suggest me.
ERROR: consul-git-r0 do_compile: Execution of '/home/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/consul/git-r0/temp/run.do_compile.26832' failed with exit code 2:

internal/unsafeheader

unicode/utf16

container/list

internal/cpu

crypto/internal/subtle

crypto/subtle

vendor/golang.org/x/crypto/cryptobyte/asn1

internal/nettrace

vendor/golang.org/x/crypto/internal/subtle

internal/race

unicode/utf8

runtime/internal/atomic

sync/atomic

internal/testlog

runtime/internal/sys

runtime/internal/math

internal/bytealg

encoding

unicode

math/bits

math

runtime

internal/reflectlite

sync

errors

internal/singleflight

sort

math/rand

strconv

internal/oserror

io

vendor/golang.org/x/net/dns/dnsmessage

container/heap

crypto/rc4

reflect

strings

bytes

syscall

hash

crypto

crypto/internal/randutil

crypto/hmac

hash/crc32

vendor/golang.org/x/crypto/hkdf

bufio

vendor/golang.org/x/text/transform

path

text/tabwriter

regexp/syntax

encoding/base32

html

hash/crc64

hash/fnv

internal/fmtsort

hash/adler32

encoding/binary

regexp

time

internal/syscall/unix

internal/syscall/execenv

encoding/base64

crypto/cipher

crypto/sha512

crypto/ed25519/internal/edwards25519

crypto/md5

crypto/aes

crypto/des

context

crypto/sha1

internal/poll

crypto/sha256

encoding/pem

vendor/golang.org/x/crypto/chacha20

vendor/golang.org/x/crypto/poly1305

vendor/golang.org/x/crypto/chacha20poly1305

os

fmt

path/filepath

net

io/ioutil

encoding/json

encoding/hex

vendor/golang.org/x/net/http2/hpack

mime

mime/quotedprintable

vendor/golang.org/x/crypto/curve25519

os/signal

log

compress/flate

vendor/golang.org/x/text/unicode/norm

vendor/golang.org/x/text/unicode/bidi

compress/gzip

runtime/debug

net/http/internal

math/big

net/textproto

net/url

go/token

compress/lzw

encoding/gob

os/exec

github.com/hashicorp/consul/vendor/golang.org/x/net/internal/socket

vendor/golang.org/x/text/secure/bidirule

vendor/golang.org/x/net/idna

github.com/hashicorp/consul/vendor/golang.org/x/sys/unix

flag

runtime/trace

testing

os/user

encoding/asn1

crypto/elliptic

text/template/parse

crypto/rand

vendor/golang.org/x/crypto/cryptobyte

crypto/ed25519

crypto/rsa

crypto/dsa

crypto/x509/pkix

mime/multipart

vendor/golang.org/x/net/http/httpproxy

vendor/golang.org/x/net/http/httpguts

internal/lazyregexp

go/scanner

crypto/ecdsa

text/template

compress/zlib

crypto/x509

go/ast

archive/tar

github.com/hashicorp/consul/vendor/github.com/boltdb/bolt

html/template

github.com/hashicorp/consul/vendor/github.com/shirou/gopsutil/host

go/parser

go/doc

crypto/tls

net/mail

log/syslog

encoding/xml

# github.com/hashicorp/consul/vendor/golang.org/x/net/internal/socket

src/github.com/hashicorp/consul/vendor/golang.org/x/net/internal/socket/cmsghdr.go:9:10: undefined: cmsghdr

src/github.com/hashicorp/consul/vendor/golang.org/x/net/internal/socket/cmsghdr.go:10:10: undefined: cmsghdr

src/github.com/hashicorp/consul/vendor/golang.org/x/net/internal/socket/cmsghdr.go:11:10: undefined: cmsghdr

src/github.com/hashicorp/consul/vendor/golang.org/x/net/internal/socket/mmsghdr_unix.go:11:17: undefined: mmsghdr

encoding/csv

net/http/httptrace

internal/profile

runtime/pprof

net/http

# github.com/hashicorp/consul/vendor/github.com/shirou/gopsutil/host

src/github.com/hashicorp/consul/vendor/github.com/shirou/gopsutil/host/host_linux.go:208:22: undefined: sizeOfUtmp

src/github.com/hashicorp/consul/vendor/github.com/shirou/gopsutil/host/host_linux.go:213:14: undefined: sizeOfUtmp

src/github.com/hashicorp/consul/vendor/github.com/shirou/gopsutil/host/host_linux.go:215:9: undefined: utmp

# github.com/hashicorp/consul/vendor/github.com/boltdb/bolt

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/bolt_unix.go:62:15: undefined: maxMapSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/bucket.go:135:15: undefined: brokenUnaligned

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/db.go:101:13: undefined: maxMapSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/db.go:317:12: undefined: maxMapSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/db.go:335:10: undefined: maxMapSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/db.go:336:8: undefined: maxMapSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/freelist.go:169:19: undefined: maxAllocSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/freelist.go:176:14: undefined: maxAllocSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/freelist.go:204:17: undefined: maxAllocSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/freelist.go:207:7: undefined: maxAllocSize

src/github.com/hashicorp/consul/vendor/github.com/boltdb/bolt/freelist.go:207:7: too many errors

expvar

net/http/httptest

net/rpc

net/http/httputil

net/http/cookiejar

# github.com/hashicorp/consul/vendor/golang.org/x/sys/unix

src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_linux_gc.go:10:6: missing function body

src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_linux_gc.go:14:6: missing function body

src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_unix_gc.go:12:6: missing function body

src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_unix_gc.go:13:6: missing function body

src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_unix_gc.go:14:6: missing function body

src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_unix_gc.go:15:6: missing function body

net/http/pprof

WARNING: exit code 2 from a shell command.

ERROR: Logfile of failure stored in: /home/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/consul/git-r0/temp/log.do_compile.26832

--
Regards,
Sateesh

--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com