Re: [yocto] best way to get feature of systemd v248 in yocto-hardknott (systemd v247)?

[Nicolas Jeker]

On Fri, 2021-08-13 at 15:31 -0600, Bill Plunkett wrote:
> I'd like to use a systemd DHCP client feature that became available
> in v248 in my yocto-hardknott system.  Is there any hope of using the
> complete v249.1 recipe from the oe master branch?
> 

To backport a newer version, I usually just take the trial and error
route by copying the recipe to a custom layer and then, if necessary,
resolving missing or outdated dependencies on the go. This works most
of the time, but it could get a bit more complicated for systemd if
something fundamentally changed.

> Bill



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54429): https://lists.yoctoproject.org/g/yocto/message/54429
Mute This Topic: https://lists.yoctoproject.org/mt/84873812/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] execute a python code in raspberrypi #python

[Nicolas Jeker]

On Fri, 2021-08-13 at 02:40 -0700, yasminebenghoz...@gmail.com wrote:
> Hello beautiful people, 
> 
> I successfully executed helloworld.py on the raspberrypi by making a
> layer. BUt now i need to add a whole python code with classes etc,
> which exists in different files like the picture, I wanna know please
> how to add them to be able to run the code on the raspberrypi. THey re
> all related together and i need to run the main-SF.py so the code will
> be executed.
> 

I recommend putting your whole python project into a repository (e.g.
with git) and then create a recipe that fetches the git repository and
installs the files to a sensible location.

You should be able to follow the documentation on writing a new recipe
to some degree:

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-writing-a-new-recipe

To run your script on boot, I would create an init script / systemd
service, depending on what init system your image is using. See here
for more information:

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-enabling-system-services

> THank you .



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54430): https://lists.yoctoproject.org/g/yocto/message/54430
Mute This Topic: https://lists.yoctoproject.org/mt/84859973/21656
Mute #python:https://lists.yoctoproject.org/g/yocto/mutehashtag/python
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] How to disable installing python in Hardknott version?

[JH]

Hello,

I used dbus-send and installed the dbus package in Zeus, it did not
install python, but in Hardknott, the python3 and dbus-python
installed automatically, the python3 size is too large, how can I
disable installing python3?

Thank you.

Kind regards,

- jh

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54431): https://lists.yoctoproject.org/g/yocto/message/54431
Mute This Topic: https://lists.yoctoproject.org/mt/84944623/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH 1/3] protobuf: static link tools when generating sdk

[Sinan Kaya]

On 8/17/2021 6:26 AM, Khem Raj wrote:
> +EXTRA_OECONF:append:class-nativesdk = " --disable-shared"
> 
> 
> This is not an inert change can it use some mingw specific override as well 

Change is targeting meta-mingw repository. I looked at other files
in the repo to see what the pattern is.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54432): https://lists.yoctoproject.org/g/yocto/message/54432
Mute This Topic: https://lists.yoctoproject.org/mt/84939073/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [PATCH v2 ptest-runner 2/2] 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 tests (one
or more) causes ptest-runner to provide exit code of 1.

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 
---
Changes for v2:
- When number of failed tests is N, the ptest-runner returns value of 1
  to indicate error in the execution
---
 main.c | 3 +++
 1 file changed, 3 insertions(+)

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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54434): https://lists.yoctoproject.org/g/yocto/message/54434
Mute This Topic: https://lists.yoctoproject.org/mt/84946492/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [PATCH v2 ptest-runner 1/2] mem: Refactor ptest_list cleanup

[?ukasz Majewski]

From: 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 

---
Changes for v2 [lukma]:
- Rebase from origin/dev to origin/master (the dev branch had
  some adjustments for timeout, which shall be discarded as not
  needed anymore.
---
 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 2b13ef5..890bc6a 100644
--- a/main.c
+++ b/main.c
@@ -117,7 +117,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);
@@ -176,7 +177,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]);
if (tmp == NULL) {
@@ -212,7 +213,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++)
@@ -220,7 +221,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 917ef4f..0c0e5b2 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 02a64bb..658a07a 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 }
 
@@ -57,7 +51,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 081f027..fc15acb 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) != 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);
 
-   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);
 
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)

Re: [yocto] [meta-mingw] [PATCH 1/3] protobuf: static link tools when generating sdk

[Joshua Watt]

On 8/17/21 6:03 AM, Sinan Kaya wrote:

On 8/17/2021 6:26 AM, Khem Raj wrote:

 +EXTRA_OECONF:append:class-nativesdk = " --disable-shared"


This is not an inert change can it use some mingw specific override as well

Change is targeting meta-mingw repository. I looked at other files
in the repo to see what the pattern is.


All of the bbappends in meta-mingw should be using the :mingw32 override 
(or sdkmingw32 if it specific to just the SDK). If you found an example 
in the current code where that is not the case, it needs to be fixed. 
Either way, you need to use that override in your patches.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54435): https://lists.yoctoproject.org/g/yocto/message/54435
Mute This Topic: https://lists.yoctoproject.org/mt/84939073/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk

[Sinan Kaya]

Dynamically linked protoc.exe is failing as follows:

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/protobuf/protobuf_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-devtools/protobuf/protobuf_%.bbappend

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend 
b/recipes-devtools/protobuf/protobuf_%.bbappend
new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54437): https://lists.yoctoproject.org/g/yocto/message/54437
Mute This Topic: https://lists.yoctoproject.org/mt/84948454/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v2 3/3] grpc: static link tools when generating SDK

[Sinan Kaya]

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/grpc/grpc_%.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 recipes-devtools/grpc/grpc_%.bbappend

diff --git a/recipes-devtools/grpc/grpc_%.bbappend 
b/recipes-devtools/grpc/grpc_%.bbappend
new file mode 100644
index 000..4fcd8b9
--- /dev/null
+++ b/recipes-devtools/grpc/grpc_%.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OECMAKE:remove:sdkmingw32 = "-DBUILD_SHARED_LIBS=ON"
+EXTRA_OECMAKE:append:sdkmingw32 = " -DBUILD_SHARED_LIBS=OFF"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54436): https://lists.yoctoproject.org/g/yocto/message/54436
Mute This Topic: https://lists.yoctoproject.org/mt/84948453/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v2 2/3] protobuf-c: static link when generating sdk

[Sinan Kaya]

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/protobuf-c/protobuf-c_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-devtools/protobuf-c/protobuf-c_%.bbappend

diff --git a/recipes-devtools/protobuf-c/protobuf-c_%.bbappend 
b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend
new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54438): https://lists.yoctoproject.org/g/yocto/message/54438
Mute This Topic: https://lists.yoctoproject.org/mt/84948455/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH] abseil-cpp: disable shared build as it is broken

[Sinan Kaya]

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend

diff --git a/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend 
b/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend
new file mode 100644
index 000..b73a8ea
--- /dev/null
+++ b/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54439): https://lists.yoctoproject.org/g/yocto/message/54439
Mute This Topic: https://lists.yoctoproject.org/mt/84948944/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk

[Joshua Watt]

On 8/17/21 9:07 AM, Sinan Kaya wrote:

Dynamically linked protoc.exe is failing as follows:

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
  recipes-devtools/protobuf/protobuf_%.bbappend | 1 +
  1 file changed, 1 insertion(+)
  create mode 100644 recipes-devtools/protobuf/protobuf_%.bbappend

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend 
b/recipes-devtools/protobuf/protobuf_%.bbappend
new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"


Apologies, this should use the :mingw32 override, since it's not 
*specific* to the SDK, but MinGW in general. Anyway, I fixed this up for 
you since I wasn't clear; this is in master-next and I'll get it tested 
shortly




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54440): https://lists.yoctoproject.org/g/yocto/message/54440
Mute This Topic: https://lists.yoctoproject.org/mt/84948454/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk

[Joshua Watt]

These 3 recipes are in meta-oe, not OE-core which means that the 
bbappends are going to cause a dangling appends error/warning. Please 
add a dynamic BBFILES pattern[1] so that these are conditionally applied 
only if meta-oe is present, something like:


 BBFILES_DYNAMIC += "\
openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bb 
\
openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bbappend 
\

 "

[1]: 
https://docs.yoctoproject.org/ref-manual/variables.html#term-BBFILES_DYNAMIC


On 8/17/21 9:33 AM, Joshua Watt wrote:


On 8/17/21 9:07 AM, Sinan Kaya wrote:

Dynamically linked protoc.exe is failing as follows:

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
  recipes-devtools/protobuf/protobuf_%.bbappend | 1 +
  1 file changed, 1 insertion(+)
  create mode 100644 recipes-devtools/protobuf/protobuf_%.bbappend

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend 
b/recipes-devtools/protobuf/protobuf_%.bbappend

new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"


Apologies, this should use the :mingw32 override, since it's not 
*specific* to the SDK, but MinGW in general. Anyway, I fixed this up 
for you since I wasn't clear; this is in master-next and I'll get it 
tested shortly




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54441): https://lists.yoctoproject.org/g/yocto/message/54441
Mute This Topic: https://lists.yoctoproject.org/mt/84948454/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Status WW33`21

[Stephen Jolley]

Current Dev Position: YP 3.4 M3

Next Deadline: 23rd Aug. 2021 YP 3.4 M3 build (Feature Freeze)

 

Next Team Meetings:

*   Bug Triage meeting Thursday Aug. 19th at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday Sept. 7th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday Aug. 17th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.1.10 was released
*   Next week is feature freeze for YP 3.4
*   Known pending work for YP 3.4 includes rust support in core and the
prserv changes.
*   OE-Core has moved to the new override syntax and is now only
compatible with the honister release series. Other layers will need to
migrate to the new syntax to work with it. There is documentation about
handling migration to the new syntax in the migration section of the manual:

 

http://docs.yoctoproject.org/migration-guides/migration-3.4.html#override-sy
ntax-changes

*   There continue to be small bug fixes from the override syntax change
but most of the core layers tested on the autobuilder now seem to be working
ok.
*   We merged the upgrade to glibc to 2.34. Unfortunately this version
makes some changes which have broken uninative and pseudo. Fixes for those
issues are being investigated. 
*   Kernel changes to drop 5.4 and switch to 5.10 and 5.13 are pending,
mainly on other layers being ready for the change to the default versions.
*   There also appear to be issues in the buildtools tarball on aarch64,
probably from the gcc 11 upgrade.
*   There is a plan to migrate the tune files into architecture specific
directories. This patch will likely merge in the next few days and will need
BSP layers to be updated as the tune files will no longer be found.
*   The bitbake fetcher no longer ignores SSL certificates by default
(this wasn't a huge problem as we separately checksum input files).
*   LTO linker flags handling changes were merged now the
reproducibility issues it introduced were fixed meaning LTO builds should be
more reproducible.
*   Overlayfs class changes were merged.
*   Intermittent issues are ongoing and 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

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.4. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.4_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.4 Milestone Dates:

*   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.1.10  is released
*   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:

*   WDD 2583 (last week 2577) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1293 (last week 1292)
*   Patches in the Pending State: 485 (38%) [last week 485 (38%)]

 

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

Re: [yocto] [meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk

[Sinan Kaya]

On 8/17/2021 5:44 PM, Joshua Watt wrote:
> These 3 recipes are in meta-oe, not OE-core which means that the
> bbappends are going to cause a dangling appends error/warning. Please
> add a dynamic BBFILES pattern[1] so that these are conditionally applied
> only if meta-oe is present, something like:
> 
>  BBFILES_DYNAMIC += "\
> openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bb
> \
> openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bbappend
> \
>  "
> 
> [1]:
> https://docs.yoctoproject.org/ref-manual/variables.html#term-BBFILES_DYNAMIC

I wasn't aware of this functionality. Will post v3.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54443): https://lists.yoctoproject.org/g/yocto/message/54443
Mute This Topic: https://lists.yoctoproject.org/mt/84948454/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk

[Sinan Kaya]

On 8/17/2021 5:33 PM, Joshua Watt wrote:
>> +EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
> 
> Apologies, this should use the :mingw32 override, since it's not
> *specific* to the SDK, but MinGW in general. Anyway, I fixed this up for
> you since I wasn't clear; this is in master-next and I'll get it tested
> shortly

My reading of the problem says that the problem only happens on win32
platforms due to how DLLs initialize the heap.

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.

I'd like to keep target builds same.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5): https://lists.yoctoproject.org/g/yocto/message/5
Mute This Topic: https://lists.yoctoproject.org/mt/84948454/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Sinan Kaya]

Dynamically linked protoc.exe is failing as follows:

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/protobuf/protobuf_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-devtools/protobuf/protobuf_%.bbappend

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend 
b/recipes-devtools/protobuf/protobuf_%.bbappend
new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54445): https://lists.yoctoproject.org/g/yocto/message/54445
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v3 2/5] protobuf-c: static link when generating sdk

[Sinan Kaya]

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/protobuf-c/protobuf-c_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-devtools/protobuf-c/protobuf-c_%.bbappend

diff --git a/recipes-devtools/protobuf-c/protobuf-c_%.bbappend 
b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend
new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54446): https://lists.yoctoproject.org/g/yocto/message/54446
Mute This Topic: https://lists.yoctoproject.org/mt/84949863/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v3 3/5] grpc: static link tools when generating SDK

[Sinan Kaya]

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/grpc/grpc_%.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 recipes-devtools/grpc/grpc_%.bbappend

diff --git a/recipes-devtools/grpc/grpc_%.bbappend 
b/recipes-devtools/grpc/grpc_%.bbappend
new file mode 100644
index 000..4fcd8b9
--- /dev/null
+++ b/recipes-devtools/grpc/grpc_%.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OECMAKE:remove:sdkmingw32 = "-DBUILD_SHARED_LIBS=ON"
+EXTRA_OECMAKE:append:sdkmingw32 = " -DBUILD_SHARED_LIBS=OFF"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54447): https://lists.yoctoproject.org/g/yocto/message/54447
Mute This Topic: https://lists.yoctoproject.org/mt/84949864/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v3 4/5] abseil-cpp: disable shared build as it is broken

[Sinan Kaya]

Signed-off-by: Sinan Kaya 
---
 recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend

diff --git a/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend 
b/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend
new file mode 100644
index 000..b73a8ea
--- /dev/null
+++ b/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54448): https://lists.yoctoproject.org/g/yocto/message/54448
Mute This Topic: https://lists.yoctoproject.org/mt/84949865/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH v3 5/5] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers

[Sinan Kaya]

Add a dynamic BBFILES pattern so that patches for openembedded-layer
are conditionally applied only if meta-oe is present.

Signed-off-by: Sinan Kaya 
---
 conf/layer.conf | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 5fefa73..d4823fc 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -3,6 +3,12 @@ BBPATH := "${BBPATH}:${LAYERDIR}"
 
 # We have a packages directory, add to BBFILES
 BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
+BBFILES_DYNAMIC += "\
+openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bb
+\
+openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bbappend
+\
+ "
 
 BBFILE_COLLECTIONS += "meta-mingw"
 BBFILE_PATTERN_meta-mingw := "^${LAYERDIR}/"
@@ -10,4 +16,5 @@ BBFILE_PRIORITY_meta-mingw = "8"
 
 LAYERDEPENDS_meta-mingw = "core"
 
-LAYERSERIES_COMPAT_meta-mingw = "honister"
\ No newline at end of file
+LAYERSERIES_COMPAT_meta-mingw = "honister"
+
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54449): https://lists.yoctoproject.org/g/yocto/message/54449
Mute This Topic: https://lists.yoctoproject.org/mt/84949866/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[vishal . rana118]

Hi,

I am using *ubuntu 16.04* (host) in VirtualBox.

Memory allocated to VM machine is 100+ GB.

Poky *dunfell*.

While trying to build the project fo *r x86_64.*

Steps followed as per yocto quick guide for "dunfell"

// // 

after baking 54% of recipe I am getting error.

// // 


| /home/vrana/Desktop/yocto_ Practice/build/tmp/work/core2- 
64-poky-linux/gcc/9.3.0-r0/ recipe-sysroot-native/usr/bin/ 
x86_64-poky-linux/../../ libexec/x86_64-poky-linux/gcc/ 
x86_64-poky-linux/9.3.0/as: out of memory allocating 4064 bytes after a total 
of 452272128 bytes

| Makefile:1117: recipe for target 'insn-emit.o' failed

| make[1]: *** [insn-emit.o] Error 2

| make[1]: *** Waiting for unfinished jobs

| rm gcc.pod

| make[1]: Leaving directory '/home/vrana/Desktop/yocto_ 
Practice/build/tmp/work/core2- 64-poky-linux/gcc/9.3.0-r0/ 
gcc-9.3.0/build.x86_64-poky- linux.x86_64-poky-linux/gcc'

| Makefile:4328: recipe for target 'all-gcc' failed

| make: *** [all-gcc] Error 2

| WARNING: exit code 1 from a shell command.

|

ERROR: Task (/home/vrana/Desktop/yocto_ Practice/source/poky/meta/ 
recipes-devtools/gcc/gcc_9.3. bb:do_compile) failed with exit code '1'

NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:

/home/vrana/Desktop/yocto_ Practice/source/poky/meta/ 
recipes-devtools/gcc/gcc_9.3. bb:do_compile

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

// //

looking for guidance.

Regards,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54450): https://lists.yoctoproject.org/g/yocto/message/54450
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] ZFS/ZoL on Yocto

[Manuel Wagesreither]

Hello all,

I would like to know if anyone has experiences with equipping Yocto created 
images with ZFS support.

If I'm not mistaken, the main problems of using ZFS in linux are of legal 
nature. ZFS can not go into the linux kernel source tree, as it conflicts with 
the GPL. Hence, the linux version of ZFS called ZoL (ZFS-On-Linux) must be 
compiled as kernel module and recompiled at every kernel bump. On normal 
machines, that's a bit cumbersome, but for Yocto this shouldn't be a problem at 
all.

So, given the large fanbase ZFS has, I'm wondering why there are no recipes 
around?

I googled a bit, and these are the only meaningful results I found:
* https://lists.yoctoproject.org/g/yocto/message/29331
* https://gist.github.com/cveilleux/54961ccc41071e8aee8c19b69fcba78f

Regards,
Manuel

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54451): https://lists.yoctoproject.org/g/yocto/message/54451
Mute This Topic: https://lists.yoctoproject.org/mt/84950894/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Joshua Watt]

I had to clean these up a little bit and pushed them to master-next. 
Please verify that they still work for you and if not used them as a 
starting point and send a V4 patchset.


On 8/17/21 10:09 AM, Sinan Kaya wrote:

Dynamically linked protoc.exe is failing as follows:

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya 
---
  recipes-devtools/protobuf/protobuf_%.bbappend | 1 +
  1 file changed, 1 insertion(+)
  create mode 100644 recipes-devtools/protobuf/protobuf_%.bbappend

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend 
b/recipes-devtools/protobuf/protobuf_%.bbappend
new file mode 100644
index 000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54452): https://lists.yoctoproject.org/g/yocto/message/54452
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Sinan Kaya]

On 8/17/2021 7:01 PM, Joshua Watt wrote:
> I had to clean these up a little bit and pushed them to master-next.
> Please verify that they still work for you and if not used them as a
> starting point and send a V4 patchset.

Sounds good.

What do you think about this?

My reading of the problem says that the problem only happens on win32
platforms due to how DLLs initialize the heap.

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.

I'd like to keep target builds same supporting both static and dynamic
build but limit the tools to static link by using sdkmingw32 instead of
mingw32.

Should I send a V4?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54453): https://lists.yoctoproject.org/g/yocto/message/54453
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[Zoran]

> /home/vrana/Desktop/yocto_Practice/build/tmp/ \
> work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/ \
> usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/ \
> gcc/x86_64-poky-linux/9.3.0/as:
> *out of memory allocating 4064 bytes after a total of 452272128 bytes*

Looks to me that your VM ran out of SDRAM memory,
allocated for the VM, somehow.

> Memory allocated to VM machine is 100+ GB.

It is (hopefully) a VDI (Dynamic) VM disk image, NOT a SDRAM,
my best guess.

[1] You can just try to continue bitbake process, it might pass, since the
 Bitbake processes were forcefully killed, and some memory hogged
 fortunately were entirely deallocated;
[2] If [1] fails again a few times, you can try to reconfigure VMM to give
 more SDRAM to VM (have no idea what is the allocated default), it
 might help!

Zee
___

On Tue, Aug 17, 2021 at 5:38 PM  wrote:

> Hi,
>
> I am using* ubuntu 16.04* (host) in VirtualBox.
>
> Memory allocated to VM machine is 100+ GB.
>
> Poky* dunfell*.
>
> While trying to build the project fo*r x86_64.*
>
> Steps followed as per yocto quick guide for "dunfell"
>
> 
>
> after baking 54% of recipe I am getting error.
>
>
> 
>
> |
> /home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/as:
> out of memory allocating 4064 bytes after a total of 452272128 bytes
>
> | Makefile:1117: recipe for target 'insn-emit.o' failed
>
> | make[1]: *** [insn-emit.o] Error 2
>
> | make[1]: *** Waiting for unfinished jobs
>
> | rm gcc.pod
>
> | make[1]: Leaving directory
> '/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/gcc-9.3.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc'
>
> | Makefile:4328: recipe for target 'all-gcc' failed
>
> | make: *** [all-gcc] Error 2
>
> | WARNING: exit code 1 from a shell command.
>
> |
>
> ERROR: Task
> (/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile)
> failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
>
> /home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:
> do_compile
>
> Summary: There were 2 ERROR messages shown, returning a non-zero exit
> code.
>
>
>
> 
>
> looking for guidance.
>
>
>
> Regards,
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54454): https://lists.yoctoproject.org/g/yocto/message/54454
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[Khem Raj]

On 8/17/21 8:38 AM, vishal.rana...@gmail.com wrote:

Hi,

I am using*ubuntu 16.04* (host) in VirtualBox.

Memory allocated to VM machine is 100+ GB.



how much DRAM is allocated.


Poky*dunfell*.

While trying to build the project fo*r x86_64.*

Steps followed as per yocto quick guide for "dunfell"



after baking 54% of recipe I am getting error.



| 
/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/as: 
out of memory allocating 4064 bytes after a total of 452272128 bytes


| Makefile:1117: recipe for target 'insn-emit.o' failed

| make[1]: *** [insn-emit.o] Error 2

| make[1]: *** Waiting for unfinished jobs

| rm gcc.pod

| make[1]: Leaving directory 
'/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/gcc-9.3.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc'


| Makefile:4328: recipe for target 'all-gcc' failed

| make: *** [all-gcc] Error 2

| WARNING: exit code 1 from a shell command.

|

ERROR: Task 
(/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile) 
failed with exit code '1'


NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be 
rerun and 1 failed.


Summary: 1 task failed:

   
/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile


Summary: There were 2 ERROR messages shown, returning a non-zero exit code.



looking for guidance.

Regards,






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54455): https://lists.yoctoproject.org/g/yocto/message/54455
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[vishal . rana118]

Previously SDRAM was 3 GB allocated.

After changing SDRAM to 4 GB.
then trying to build/make/bitbake..

getting new error i.e.
Unable to connect to bitbake server

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54456): https://lists.yoctoproject.org/g/yocto/message/54456
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Joshua Watt]

On 8/17/21 11:29 AM, Sinan Kaya wrote:

On 8/17/2021 7:01 PM, Joshua Watt wrote:

I had to clean these up a little bit and pushed them to master-next.
Please verify that they still work for you and if not used them as a
starting point and send a V4 patchset.

Sounds good.

What do you think about this?

My reading of the problem says that the problem only happens on win32
platforms due to how DLLs initialize the heap.

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.


Are you building with "mingw32" as the target (not as the SDK), and it 
works there? I wonder why it only fails for the SDK build and not the 
target build? If that is truly the case, then yes I suppose it should be 
the "sdkmingw32" override. The strange thing about that (and why I 
thought it was incorrect) is that we have a few recipes that disable 
shared libraries and/or enable static with just the "mingw32" override, 
which is why I assumed it was a general limitation of MinGW, not just 
the SDK. I looked through the recipes, and it does seem more apparent 
that it is inconsistent, with a few recipe using "mingw32", a few using 
"class-nativesdk:mingw32", and a few using "sdkmingw32".



Anyway, please send a V4 if it needs to be changed, and I apologize for 
changing it unnecessarily :)




I'd like to keep target builds same supporting both static and dynamic
build but limit the tools to static link by using sdkmingw32 instead of
mingw32.

Should I send a V4?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54457): https://lists.yoctoproject.org/g/yocto/message/54457
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Sinan Kaya]

On 8/17/2021 9:10 PM, Joshua Watt wrote:
>> We have use cases of both dynamic and static linkage for the
>> target build that we have not seen any issues with.
> 
> Are you building with "mingw32" as the target (not as the SDK), and it
> works there? I wonder why it only fails for the SDK build and not the
> target build? If that is truly the case, then yes I suppose it should be
> the "sdkmingw32" override. The strange thing about that (and why I
> thought it was incorrect) is that we have a few recipes that disable
> shared libraries and/or enable static with just the "mingw32" override,
> which is why I assumed it was a general limitation of MinGW, not just
> the SDK. I looked through the recipes, and it does seem more apparent
> that it is inconsistent, with a few recipe using "mingw32", a few using
> "class-nativesdk:mingw32", and a few using "sdkmingw32".
> 

I see two classes of problems based on my engagement with the mingw32.
Some recipes just don't build without using the static method for
the SDK and the target both. (abseil-cpp is one of them)

The nativesdk problem for grpc and protobuf is a silent failure. Even
though we are able to build the binary, we get a binary that just
doesn't work on windows. (crashes upon execution)

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.

> 
> Anyway, please send a V4 if it needs to be changed, and I apologize for
> changing it unnecessarily :)

Will do.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54458): https://lists.yoctoproject.org/g/yocto/message/54458
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Joshua Watt]

On 8/17/21 1:15 PM, Sinan Kaya wrote:

On 8/17/2021 9:10 PM, Joshua Watt wrote:

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.

Are you building with "mingw32" as the target (not as the SDK), and it
works there? I wonder why it only fails for the SDK build and not the
target build? If that is truly the case, then yes I suppose it should be
the "sdkmingw32" override. The strange thing about that (and why I
thought it was incorrect) is that we have a few recipes that disable
shared libraries and/or enable static with just the "mingw32" override,
which is why I assumed it was a general limitation of MinGW, not just
the SDK. I looked through the recipes, and it does seem more apparent
that it is inconsistent, with a few recipe using "mingw32", a few using
"class-nativesdk:mingw32", and a few using "sdkmingw32".


I see two classes of problems based on my engagement with the mingw32.
Some recipes just don't build without using the static method for
the SDK and the target both. (abseil-cpp is one of them)

The nativesdk problem for grpc and protobuf is a silent failure. Even
though we are able to build the binary, we get a binary that just
doesn't work on windows. (crashes upon execution)

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.


RIght, the "mingw32" override shouldn't affect what you do with the 
*target* unless your target is MinGW; I'm not sure if anyone is actually 
doing that, most SDKs target Linux for ARM, Linux for AArch64, Linux for 
x86, etc.


What is your target?

It's important to remember that the recipe can be built differently for 
the SDK vs the target :)





Anyway, please send a V4 if it needs to be changed, and I apologize for
changing it unnecessarily :)

Will do.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54459): https://lists.yoctoproject.org/g/yocto/message/54459
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

[Sinan Kaya]

On 8/17/2021 9:19 PM, Joshua Watt wrote:
>> I still would like to be able to static/dynamic link grpc/protobuf for
>> my target using the SDK.
> 
> RIght, the "mingw32" override shouldn't affect what you do with the
> *target* unless your target is MinGW; I'm not sure if anyone is actually
> doing that, most SDKs target Linux for ARM, Linux for AArch64, Linux for
> x86, etc.
> 
> What is your target?
> 
> It's important to remember that the recipe can be built differently for
> the SDK vs the target :)
> 

ah, mine is both arm and arm64. No need to touch the recipe then.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54460): https://lists.yoctoproject.org/g/yocto/message/54460
Mute This Topic: https://lists.yoctoproject.org/mt/84949862/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[Khem Raj]

On Tue, Aug 17, 2021 at 10:36 AM  wrote:
>
> Previously SDRAM was 3 GB allocated.
>
> After changing SDRAM to 4 GB.
> then trying to build/make/bitbake..

keep in mind that based upon how many vcores you allocate to VM will
determine memory pressure
as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
cores might workout ok but some bigger packages like
chromium etc. need minimal 16GB RAM to build.

>
> getting new error i.e.
> Unable to connect to bitbake server

this seems that it finds bitbake is still running and its trying to
reconnect to it. Maybe just reboot the box and try again

> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54461): https://lists.yoctoproject.org/g/yocto/message/54461
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] ZFS/ZoL on Yocto

[Alexandre Belloni]

On 17/08/2021 17:52:17+0200, Manuel Wagesreither wrote:
> Hello all,
> 
> I would like to know if anyone has experiences with equipping Yocto created 
> images with ZFS support.
> 
> If I'm not mistaken, the main problems of using ZFS in linux are of legal 
> nature. ZFS can not go into the linux kernel source tree, as it conflicts 
> with the GPL. Hence, the linux version of ZFS called ZoL (ZFS-On-Linux) must 
> be compiled as kernel module and recompiled at every kernel bump. On normal 
> machines, that's a bit cumbersome, but for Yocto this shouldn't be a problem 
> at all.
> 
> So, given the large fanbase ZFS has, I'm wondering why there are no recipes 
> around?
> 

I'm guessing that ZFS is not really popular on embedded systems ;)

> I googled a bit, and these are the only meaningful results I found:
> * https://lists.yoctoproject.org/g/yocto/message/29331
> * https://gist.github.com/cveilleux/54961ccc41071e8aee8c19b69fcba78f
> 
> Regards,
> Manuel

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54462): https://lists.yoctoproject.org/g/yocto/message/54462
Mute This Topic: https://lists.yoctoproject.org/mt/84950894/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[Zoran]

> keep in mind that based upon how many vcores you allocate to VM will
> determine memory pressure
> as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
> cores might workout ok but some bigger packages like
> chromium etc. need minimal 16GB RAM to build.

This should be reflected somewhere in YOCTO documentation. Especially
for chromium.

In the section: Host HW Requirements (with some explanation why).

Zee
___


On Tue, Aug 17, 2021 at 10:14 PM Khem Raj  wrote:
>
> On Tue, Aug 17, 2021 at 10:36 AM  wrote:
> >
> > Previously SDRAM was 3 GB allocated.
> >
> > After changing SDRAM to 4 GB.
> > then trying to build/make/bitbake..
>
> keep in mind that based upon how many vcores you allocate to VM will
> determine memory pressure
> as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
> cores might workout ok but some bigger packages like
> chromium etc. need minimal 16GB RAM to build.
>
> >
> > getting new error i.e.
> > Unable to connect to bitbake server
>
> this seems that it finds bitbake is still running and its trying to
> reconnect to it. Maybe just reboot the box and try again
>
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54463): https://lists.yoctoproject.org/g/yocto/message/54463
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

[Geller, Nir]

Hi,

Any help on this topic would be much appreciated.

Thanks,

Nir.

From: yocto@lists.yoctoproject.org  On Behalf Of 
Geller, Nir
Sent: Wednesday, August 11, 2021 6:40 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

Executing
bitbake lib32-libtool-cross -e
Yields, among many others,

18513 # $TARGET_VENDOR [3 operations]
18514 #   set /home/build/tisdk/sources/oe-core/meta/conf/bitbake.conf:132
18515 # "-oe"
18516 #   set 
/home/build/tisdk/sources/meta-arago/meta-arago-distro/conf/distro/include/toolchain-arm.inc:15
18517 # ""
18518 #   override[virtclass-multilib-lib32]:set multilib_global.bbclass:159 
[multilib_virtclass_handler_vendor]
18519 # "mllib32"
18520 # pre-expansion value:
18521 #   "mllib32"
18522 TARGET_VENDOR="mllib32"

Later, HOST_VENDOR  = "${TARGET_VENDOR}",
And HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"

Ok.

So either these variables are calculated incorrectly, or the libtool-cross 
recipe needs to be fixed in order to support multilib properly.

Can anyone please assist?

Thanks,

Nir.

From: yocto@lists.yoctoproject.org 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Geller, Nir
Sent: Wednesday, August 11, 2021 5:03 PM
To: Geller, Nir 
mailto:nir.gel...@servotronix.com>>; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

The variable SYS_HOST is expanded to armmllib32-linux-gnueabi
Shouldn't it be expanded to arm-none-linux-gnueabihf ?

Thanks,

Nir.

From: yocto@lists.yoctoproject.org 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Geller, Nir
Sent: Wednesday, August 11, 2021 4:41 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

Investigating run.do_configure suggests that in the configure stage 
oe_runconf() is set with what seems to be wrong -host and -target values:
 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

How can I influence oe_runconf() generation and set correct values?

From: yocto@lists.yoctoproject.org 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

Hi There,

Following the instruction from TI

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

I've setup a yocto project for the AM64x.

Toolchain used is 9.2-2019.12

Now I need to add support for multilib32 because I have some software that can 
be compiled only 32 bit.

I added the following lines to conf/local.conf

# Define multilib target
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

And I am able to build a few packges with lib32- successfully, however, 
lib32-libtool-cross fails at the configure stage:

--host is set to the value armmllib32-linux-gnueabi

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed
ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of 
'/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261'
 failed with exit code 1:
automake (GNU automake) 1.16.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey mailto:tro...@redhat.com>>
   and Alexandre Duret-Lutz mailto:a...@gnu.org>>.
AUTOV is 1.16
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
--system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/
 
--automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16
 -I 
/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/
 -I 
/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/
 -I 
/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cro