Date   

Re: [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 <okaya@...>
---
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 0000000..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


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

Sinan Kaya <okaya@...>
 

Signed-off-by: Sinan Kaya <okaya@...>
---
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 0000000..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


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

Sinan Kaya <okaya@...>
 

[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 <okaya@...>
---
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 0000000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
--
2.17.1


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

Sinan Kaya <okaya@...>
 

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 <okaya@...>
---
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 0000000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"
--
2.17.1


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

Sinan Kaya <okaya@...>
 

[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 <okaya@...>
---
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 0000000..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


Re: [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.


[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 <lukma@...>
---
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);
=20
rc =3D run_ptests(run, opts, argv[0], stdout, stderr);
+ fprintf(stdout, "TOTAL: %d FAIL: %d\n", ptest_list_length(run), rc);
+ if (rc > 0)
+ rc =3D 1;
=20
ptest_list_free_all(&run);
=20
--=20
2.20.1


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

?ukasz Majewski
 

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

---
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
=20
- struct ptest_list *head, *run;
+ struct ptest_list *head =3D NULL;
+ struct ptest_list *run =3D NULL;
__attribute__ ((__cleanup__(cleanup_ptest_opts))) struct ptest_options =
opts;
=20
opts.dirs =3D malloc(sizeof(char **) * 1);
@@ -176,7 +177,7 @@ main(int argc, char *argv[])
=20
head =3D NULL;
for (i =3D 0; i < opts.dirs_no; i ++) {
- struct ptest_list *tmp;
+ struct ptest_list *tmp =3D NULL;
=20
tmp =3D get_available_ptests(opts.dirs[i]);
if (tmp =3D=3D NULL) {
@@ -212,7 +213,7 @@ main(int argc, char *argv[])
=20
run =3D filter_ptests(head, opts.ptests, ptest_num);
CHECK_ALLOCATION(run, (size_t) ptest_num, 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
=20
for (i =3D 0; i < ptest_exclude_num; i++)
@@ -220,7 +221,7 @@ main(int argc, char *argv[])
=20
rc =3D run_ptests(run, opts, argv[0], stdout, stderr);
=20
- ptest_list_free_all(run);
+ ptest_list_free_all(&run);
=20
return rc;
}
diff --git a/ptest_list.c b/ptest_list.c
index 917ef4f..0c0e5b2 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -69,24 +69,19 @@ ptest_list_free(struct ptest_list *p)
free(p);
}
=20
-int
-ptest_list_free_all(struct ptest_list *head)
+void
+ptest_list_free_all(struct ptest_list **head)
{
- int i =3D 0;
struct ptest_list *p, *q;
=20
- VALIDATE_PTR_RINT(head);
-
- p =3D head;
+ p =3D *head;
while (p !=3D NULL) {
q =3D p;
p =3D p->next;
=20
ptest_list_free(q);
- i++;
}
-
- return i;
+ *head =3D NULL;
}
=20
int
diff --git a/ptest_list.h b/ptest_list.h
index 02a64bb..658a07a 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -36,12 +36,6 @@
x =3D NULL; \
} while (0)
=20
-#define PTEST_LIST_FREE_ALL_CLEAN(x) \
- do { \
- ptest_list_free_all(x); \
- x =3D NULL; \
- } while (0)
-
#define PTEST_LIST_ITERATE_START(head, p) for (p =3D head->next; p !=3D =
NULL; p =3D p->next) {
#define PTEST_LIST_ITERATE_END }
=20
@@ -57,7 +51,7 @@ struct ptest_list {
=20
extern struct ptest_list *ptest_list_alloc(void);
extern void ptest_list_free(struct ptest_list *);
-extern int ptest_list_free_all(struct ptest_list *);
+extern void ptest_list_free_all(struct ptest_list **);
=20
extern int ptest_list_length(struct ptest_list *);
extern struct ptest_list *ptest_list_search(struct ptest_list *, char *)=
;
diff --git a/tests/ptest_list.c b/tests/ptest_list.c
index 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 =3D ptest_list_alloc();
ck_assert(ptest_list_add(head, strdup("perl"), NULL) !=3D NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -62,14 +62,15 @@ START_TEST(test_free_all)
struct ptest_list *head =3D NULL;
int i;
=20
- ck_assert(ptest_list_free_all(head) =3D=3D -1);
+ ptest_list_free_all(&head);
+ ck_assert(head =3D=3D NULL);
ck_assert(errno =3D=3D EINVAL);
=20
head =3D ptest_list_alloc();
for (i =3D 0; i < ptests_num; i++)
ptest_list_add(head, strdup(ptest_names[i]), NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -87,7 +88,7 @@ START_TEST(test_length)
ptest_list_add(head, strdup(ptest_names[i]), NULL);
=20
ck_assert_int_eq(ptest_list_length(head), ptests_num);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -109,7 +110,7 @@ START_TEST(test_search)
for (i =3D ptests_num - 1; i >=3D 0; i--)
ck_assert(ptest_list_search(head, ptest_names[i]) !=3D NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -141,7 +142,7 @@ START_TEST(test_remove)
ck_assert_int_eq(ptest_list_length(head), n);
=20
ck_assert(ptest_list_search(head, "busybox") !=3D NULL);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
diff --git a/tests/utils.c b/tests/utils.c
index 8fffc18..0a51cec 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -88,13 +88,13 @@ START_TEST(test_get_available_ptests)
for (i =3D 0; ptests_not_found[i] !=3D NULL; i++)
ck_assert(ptest_list_search(head, ptests_not_found[i]) =3D=3D NULL);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
START_TEST(test_print_ptests)
{
- struct ptest_list *head;
+ struct ptest_list *head =3D NULL;
=20
char *buf;
size_t size =3D PRINT_PTEST_BUF_SIZE;
@@ -116,14 +116,14 @@ START_TEST(test_print_ptests)
=20
head =3D ptest_list_alloc();
ck_assert(print_ptests(head, fp) =3D=3D 1);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line =3D fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line !=3D NULL);
ck_assert(strcmp(line, PRINT_PTESTS_NOT_FOUND) =3D=3D 0);
=20
head =3D get_available_ptests(opts_directory);
ck_assert(print_ptests(head, fp) =3D=3D 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
line =3D fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp);
ck_assert(line !=3D NULL);
ck_assert(strcmp(line, PRINT_PTESTS_AVAILABLE) =3D=3D 0);
@@ -144,7 +144,7 @@ END_TEST
START_TEST(test_filter_ptests)
{
struct ptest_list *head =3D get_available_ptests(opts_directory);
- struct ptest_list *head_new;
+ struct ptest_list *head_new =3D NULL;
char *ptest_not_exists[] =3D {
"glib",
};
@@ -161,8 +161,8 @@ START_TEST(test_filter_ptests)
ck_assert(head_new !=3D NULL);
ck_assert(ptest_list_length(head_new) =3D=3D 3);
=20
- ptest_list_free_all(head);
- ptest_list_free_all(head_new);
+ ptest_list_free_all(&head);
+ ptest_list_free_all(&head_new);
}
END_TEST
=20
@@ -191,7 +191,7 @@ START_TEST(test_run_ptests)
=20
rc =3D run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc =3D=3D 0);
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
=20
fclose(fp_stdout);
free(buf_stdout);
@@ -227,7 +227,7 @@ START_TEST(test_run_timeout_duration_ptest)
=20
test_ptest_expected_failure(head, timeout, "hang", search_for_timeout_a=
nd_duration);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -255,7 +255,7 @@ START_TEST(test_run_fail_ptest)
=20
test_ptest_expected_failure(head, timeout, "fail", search_for_fail);
=20
- ptest_list_free_all(head);
+ ptest_list_free_all(&head);
}
END_TEST
=20
@@ -354,7 +354,7 @@ test_ptest_expected_failure(struct ptest_list *head, =
const unsigned int timeout,
fp_stdout
);
=20
- PTEST_LIST_FREE_ALL_CLEAN(filtered);
+ ptest_list_free_all(&filtered);
}
=20
fclose(fp_stdout);
diff --git a/utils.c b/utils.c
index 128ff61..0f80357 100644
--- a/utils.c
+++ b/utils.c
@@ -92,7 +92,7 @@ check_allocation1(void *p, size_t size, char *file, int=
line, int exit_on_null)
struct ptest_list *
get_available_ptests(const char *dir)
{
- struct ptest_list *head;
+ struct ptest_list *head =3D NULL;
struct stat st_buf;
=20
int n, i;
@@ -189,7 +189,7 @@ get_available_ptests(const char *dir)
free(namelist);
=20
if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head);
+ ptest_list_free_all(&head);
errno =3D saved_errno;
break;
}
@@ -257,7 +257,7 @@ filter_ptests(struct ptest_list *head, char **ptests,=
int ptest_num)
}
=20
if (fail) {
- PTEST_LIST_FREE_ALL_CLEAN(head_new);
+ ptest_list_free_all(&head_new);
errno =3D saved_errno;
}=20
} while (0);
--=20
2.20.1


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

Sinan Kaya <okaya@...>
 

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.


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


Re: execute a python code in raspberrypi #python

Nicolas Jeker
 

On Fri, 2021-08-13 at 02:40 -0700, yasminebenghozzi6@... 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 .


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


Can't parse unset of variables with override

Zhenfei Tai
 

Hi,

I'm not sure if this has been brought up already. After the syntax change from underscore to colon, I noticed the error when using unset on variables with override. Could someone confirm if this is expected?
# in bbappend
unset SRCREV:xyz

# in build log
ERROR: ParseError at /../abc%.bbappend:3: unparsed line: 'unset SRCREV:xyz
Thanks,
Zhenfei


Re: Hardknott systemd-journald issue

Zoran
 

Hello Jupiter,

This might provide you a great help:
https://askubuntu.com/questions/864722/where-is-journalctl-data-stored

Namely:

Usually the storage directory is /var/log/journal or /run/log/journal, but it doesn't have to necessarily exist in your system.

If you just want to check the amount of space that the journal is currently occupying on your disk, simply type:

$ journalctl --disk-usage


You also can combine the df command (look into man df).

Zee
_______


On Tue, Aug 17, 2021 at 4:18 AM JH <jupiter.hce@...> wrote:
Hi,

I've just upgraded from Zeus to Hardknott with the kernel 5.10.59, the
/run/log/journal was running out of space and crashed, is it a kernel
issue or Hardknott build issue?

I never seen that issue in Zeus, I thought that systemd-journald
should be capable of detecting the space, if it is no log space, stop
writing rather crashing the tmpfs

[13749.397288] systemd-journald[97]: Failed to open runtime journal:
No space left on device
[13749.439047] systemd-journald[97]: File
/run/log/journal/4ba2cd613d004916863e30730800bb69/system.journal
corrupted or uncleanly shut down, renaming and replacing.

Thank you.

Kind regards,

- jh




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

Khem Raj
 



On Mon, Aug 16, 2021 at 6:36 PM Sinan Kaya <okaya@...> 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 <okaya@...>
---
 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 0000000..7e62ff6
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:class-nativesdk = " --disable-shared"

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

--
2.17.1





M+ & H bugs with Milestone Movements WW33

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW33 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13975

cve-checker: save to alternate file format like JSON

randy.macleod@...

unassigned@...

3.4 M2

3.4 M3

 

14127

cve-check falsely indicates a vulnerabily to be patched

randy.macleod@...

unassigned@...

3.4 M2

3.4 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW33!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

2

mhalstead@...

2

ross@...

2

Grand Total

6

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW33 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 52 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

ross@...

32

michael.opdenacker@...

29

david.reyna@...

22

richard.purdie@...

20

bruce.ashfield@...

18

trevor.gamblin@...

12

timothy.t.orling@...

12

bluelightning@...

10

randy.macleod@...

10

JPEWhacker@...

10

sakib.sajal@...

10

tony.tascioglu@...

8

kai.kang@...

7

hongxu.jia@...

4

Qi.Chen@...

4

chee.yang.lee@...

3

alexandre.belloni@...

3

mostthingsweb@...

3

mingli.yu@...

3

akuster808@...

3

yf3yu@...

2

yi.zhao@...

2

raj.khem@...

2

alejandro@...

2

jaewon@...

2

mshah@...

2

john.kaldas.enpj@...

1

shachar@...

1

diego.sueiro@...

1

ydirson@...

1

mister_rs@...

1

dl9pf@...

1

devendra.tewari@...

1

open.source@...

1

sangeeta.jain@...

1

pokylinux@...

1

stacygaikovaia@...

1

nicolas.dechesne@...

1

yoctoproject@...

1

mark.hatle@...

1

jon.mason@...

1

thomas.perrot@...

1

Martin.Jansa@...

1

douglas.royds@...

1

kergoth@...

1

paul@...

1

naveen.kumar.saini@...

1

jeanmarie.lemetayer@...

1

tonyb@...

1

aehs29@...

1

vinay.m.engg@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 379 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Hardknott systemd-journald issue

JH
 

Hi,

I've just upgraded from Zeus to Hardknott with the kernel 5.10.59, the
/run/log/journal was running out of space and crashed, is it a kernel
issue or Hardknott build issue?

I never seen that issue in Zeus, I thought that systemd-journald
should be capable of detecting the space, if it is no log space, stop
writing rather crashing the tmpfs

[13749.397288] systemd-journald[97]: Failed to open runtime journal:
No space left on device
[13749.439047] systemd-journald[97]: File
/run/log/journal/4ba2cd613d004916863e30730800bb69/system.journal
corrupted or uncleanly shut down, renaming and replacing.

Thank you.

Kind regards,

- jh

2981 - 3000 of 57384