Re: [yocto] [meta-mingw] [PATCH] mingw-w64: upgrade to 11.0.1

[Joshua Watt]

Thanks.

I put this in master-next, but we are pretty close to scarthgap
release, so I'm not sure when this will get a chance to run on the AB;
please check back if it's not merged in a week or so.

On Mon, Mar 18, 2024 at 6:45 AM Samuli Piippo  wrote:
>
> Upgrade to latest release of MinGW-w64.
>
> Signed-off-by: Samuli Piippo 
> ---
>  recipes-devtools/mingw-w64/mingw-w64.inc| 2 +-
>  ...4-headers_9.0.0.bb => nativesdk-mingw-w64-headers_11.0.1.bb} | 0
>  ...4-runtime_9.0.0.bb => nativesdk-mingw-w64-runtime_11.0.1.bb} | 0
>  ...reads_9.0.0.bb => nativesdk-mingw-w64-winpthreads_11.0.1.bb} | 0
>  4 files changed, 1 insertion(+), 1 deletion(-)
>  rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-headers_9.0.0.bb => 
> nativesdk-mingw-w64-headers_11.0.1.bb} (100%)
>  rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-runtime_9.0.0.bb => 
> nativesdk-mingw-w64-runtime_11.0.1.bb} (100%)
>  rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-winpthreads_9.0.0.bb 
> => nativesdk-mingw-w64-winpthreads_11.0.1.bb} (100%)
>
> diff --git a/recipes-devtools/mingw-w64/mingw-w64.inc 
> b/recipes-devtools/mingw-w64/mingw-w64.inc
> index ce5d0db..713c0ad 100644
> --- a/recipes-devtools/mingw-w64/mingw-w64.inc
> +++ b/recipes-devtools/mingw-w64/mingw-w64.inc
> @@ -5,7 +5,7 @@ COMPATIBLE_HOST = ".*-mingw.*"
>
>  SRC_URI = 
> "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
>
> -SRC_URI[sha256sum] = 
> "1929b94b402f5ff4d7d37a9fe88daa9cc55515a6134805c104d1794ae22a4181"
> +SRC_URI[sha256sum] = 
> "3f66bce069ee8bed7439a1a13da7cb91a5e67ea6170f21317ac7f5794625ee10"
>
>  UPSTREAM_CHECK_URI = 
> "http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/;
>  UPSTREAM_CHECK_REGEX = "mingw-w64-v(?P(\d+[\.\-_]*)+)\.tar"
> diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_9.0.0.bb 
> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_11.0.1.bb
> similarity index 100%
> rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_9.0.0.bb
> rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_11.0.1.bb
> diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_9.0.0.bb 
> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_11.0.1.bb
> similarity index 100%
> rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_9.0.0.bb
> rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_11.0.1.bb
> diff --git 
> a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_9.0.0.bb 
> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_11.0.1.bb
> similarity index 100%
> rename from 
> recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_9.0.0.bb
> rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_11.0.1.bb
> --
> 2.25.1
>

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

Re: [yocto] bmap-tools repository closes

[Joshua Watt]

I'd rather it stay on GitHub; I think it makes more sense _for this
project_. First of all, it already is on GitHub, so moving it is
likely more disruptive to the workflow

Secondly, it already has CI setup through GitHub actions, which we
would need to spend effort to replicate elsewhere.

Thirdly, I've always wanted this to be published as a python module on
PyPi to make it easier for users to keep up to date; GitHub and PyPi
have streamlined this process to the point that it's surprisingly
trivial.

Finally, if we are worried about the maintenance, it's pretty easy to
delegate the maintenance of the repo to the people who are
volunteering to maintain it here, which is likely what would happen if
it went somewhere other than the Yocto GitHub account anyway.

On Fri, Jan 26, 2024 at 6:33 AM Richard Purdie
 wrote:
>
> On Thu, 2024-01-25 at 17:58 -0500, Philip Balister wrote:
> > On 1/25/24 11:58, Trevor Woerner wrote:
> > > On Wed 2024-01-24 @ 03:16:04 PM, Tim Orling wrote:
> > > > On Wed, Jan 24, 2024 at 2:02 PM Joshua Watt  
> > > > wrote:
> > > >
> > > > > On Wed, Jan 24, 2024 at 10:59 AM Trevor Woerner 
> > > > > wrote:
> > > > > >
> > > > > > Hi Artem,
> > > > > >
> > > > > > On Wed 2024-01-24 @ 02:01:08 PM, Artem Bityutskiy wrote:
> > > > > > > Hello Yocto community,
> > > > > > >
> > > > > > > some parts of Yocto software (MIC?) use the 'bmap-tools' project 
> > > > > > > to
> > > > > speed up
> > > > > > > image flashing.
> > > > > > >
> > > > > > > https://github.com/intel/bmap-tools
> > > > > > >
> > > > > > > I am the original author of the software, and I created it many 
> > > > > > > years
> > > > > ago to
> > > > > > > speed up Tizen image flashing, and it helped a lot back at the 
> > > > > > > time.
> > > > > It was also
> > > > > > > my first python project, so it was a lot of fun learning python 
> > > > > > > while
> > > > > also
> > > > > > > creating something useful.
> > > > > >
> > > > > > Thank you for your contribution, this tool has been quite useful 
> > > > > > for me
> > > > > over
> > > > > > the years.
> > > > > >
> > > > > > > But after that, I stopped working on it and it was mostly Yocto 
> > > > > > > folks
> > > > > who
> > > > > > > contributed changes here and there. I never had time and enough
> > > > > motivation to
> > > > > > > maintain the project further, but other folks helped.
> > > > > > >
> > > > > > > Simon McVitte was active maintainer, but he said he does not have 
> > > > > > > time
> > > > > for it
> > > > > > > now as well.
> > > > > > >
> > > > > > > The project is in "github.com/intel" space, and Intel is going to
> > > > > archive the
> > > > > > > git repository soon. This basically means the repository becomes
> > > > > read-only soon.
> > > > > >
> > > > > > Thank you for this update and letting us know ahead of time.
> > > > > >
> > > > > > > Would Yocto community have enthusiasts to fork it and maintain the
> > > > > fork?
> > > > > >
> > > > > > Yes, I'll volunteer to maintain it going forward. My 
> > > > > > non-stackoverflow
> > > > > python
> > > > > > knowledge is minimal, but I recently dug deeply into bmaptools to 
> > > > > > solve
> > > > > an
> > > > > > issue I had noticed. So I'm confident enough to take it over if 
> > > > > > nobody
> > > > > else is
> > > > > > interested.
> > > > >
> > > > > Ya, it's an awesome tool and a huge time saver for us, so can also
> > > > > help maintain it
> > > > >
> > > >
> > > > We can probably move it under the https://github.com/yoctoproject 
> > > > umbrella?
> > > > I can also help maintain this tremendous time saver.
> > >
> > > https://github.com/yocto

Re: [yocto] bmap-tools repository closes

[Joshua Watt]

On Wed, Jan 24, 2024 at 10:59 AM Trevor Woerner  wrote:
>
> Hi Artem,
>
> On Wed 2024-01-24 @ 02:01:08 PM, Artem Bityutskiy wrote:
> > Hello Yocto community,
> >
> > some parts of Yocto software (MIC?) use the 'bmap-tools' project to speed up
> > image flashing.
> >
> > https://github.com/intel/bmap-tools
> >
> > I am the original author of the software, and I created it many years ago to
> > speed up Tizen image flashing, and it helped a lot back at the time. It was 
> > also
> > my first python project, so it was a lot of fun learning python while also
> > creating something useful.
>
> Thank you for your contribution, this tool has been quite useful for me over
> the years.
>
> > But after that, I stopped working on it and it was mostly Yocto folks who
> > contributed changes here and there. I never had time and enough motivation 
> > to
> > maintain the project further, but other folks helped.
> >
> > Simon McVitte was active maintainer, but he said he does not have time for 
> > it
> > now as well.
> >
> > The project is in "github.com/intel" space, and Intel is going to archive 
> > the
> > git repository soon. This basically means the repository becomes read-only 
> > soon.
>
> Thank you for this update and letting us know ahead of time.
>
> > Would Yocto community have enthusiasts to fork it and maintain the fork?
>
> Yes, I'll volunteer to maintain it going forward. My non-stackoverflow python
> knowledge is minimal, but I recently dug deeply into bmaptools to solve an
> issue I had noticed. So I'm confident enough to take it over if nobody else is
> interested.

Ya, it's an awesome tool and a huge time saver for us, so can also
help maintain it

>
> Best regards,
> Trevor
>
> 
>

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

Re: [yocto] [meta-mingw] patches for meta-openembedded recipes

[Joshua Watt]

Depends on what the fix looks like. Most likely meta-openembedded though

On Wed, Nov 8, 2023, 1:57 AM Samuli Piippo  wrote:

> Hi,
>
> There is a mingw build problem with abseil-cpp recipe from
> meta-openembedded layer (master/nanbield). meta-mingw declares dependency
> only to oe-core, so the question is that should fixes be pushed to
> meta-mingw layer or directly to meta-openembedded?
>
> -samuli
>

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

Re: [yocto] SPDX generation fails every second time the image is created

[Joshua Watt]

David,

I just pushed a patch to the ML to provide better debugging when this
happens; it will at least tell us which document is missing. Is there
any way you can run you build again with that patch applied?

https://lists.openembedded.org/g/openembedded-core/message/188378

Thanks,

On Thu, Sep 28, 2023 at 8:20 AM David Daniel  wrote:
>
> Hello
>
> Something changed in master the last days that makes the image creation
> fail. When I create the image with bitbake, every second time the image
> creation fails with:
>
>Exception: AttributeError: 'NoneType' object has no attribute 'open'
>
> Funnily this only happens every 2nd time - afterwards I cannot build
> the image anymore. Up to now I "solve" this by deleting the entire
> build folder and start over again.
> I attached the log of the build that shows the error - I don't
> understand where this comes from.
>
> Any idea what's causing this?
>
> Have a great day,
> BR
> David
>
> 
>

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

[yocto] [meta-raspberrypi][PATCH] rpi-base: wic images depend on the kernel

[Joshua Watt]

wic images depend on the kernel device trees, and therefore should
depend on virtual/kernel:do_deploy to make sure these are present in the
deploy directory.

Most of the time, this dependency is satisfied indirectly since a rootfs
image will depend on the kernel, but add it explicitly for the cases
where it is not.

Signed-off-by: Joshua Watt 
---
 conf/machine/include/rpi-base.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 895fcfe..64f60ab 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -149,6 +149,7 @@ IMAGE_BOOT_FILES ?= "${BOOTFILES_DIR_NAME}/* \
  ${RPI_EXTRA_IMAGE_BOOT_FILES} \
  "
 do_image_wic[depends] += " \
+virtual/kernel:do_deploy \
 rpi-bootfiles:do_deploy \
 ${@bb.utils.contains('RPI_USE_U_BOOT', '1', 'u-boot:do_deploy', '',d)} \
 "
-- 
2.34.1


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

[yocto] [ptest-runner][PATCH] tests: Ensure that timeouts still print ERROR

[Joshua Watt]

When a test times out, it should still print an ERROR message in the log
for parsing. Modify the timeout test suite to ensure this is done.

Signed-off-by: Joshua Watt 
---
 tests/utils.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/utils.c b/tests/utils.c
index d82b90e..e493858 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -201,12 +201,13 @@ START_TEST(test_run_ptests)
 END_TEST
 
 static void
-search_for_timeout_and_duration(const int rp, FILE *fp_stdout)
+search_for_timeout_error_and_duration(const int rp, FILE *fp_stdout)
 {
const char *timeout_str = "TIMEOUT";
const char *duration_str = "DURATION";
+   const char *error_str = "ERROR";
char line_buf[PRINT_PTEST_BUF_SIZE];
-   bool found_timeout = false, found_duration = false;
+   bool found_timeout = false, found_duration = false, found_error = false;
char *line = NULL;
 
ck_assert(rp != 0);
@@ -215,10 +216,12 @@ search_for_timeout_and_duration(const int rp, FILE 
*fp_stdout)
// once true, stay true
found_timeout = found_timeout ? found_timeout : find_word(line, 
timeout_str);
found_duration = found_duration ? found_duration : 
find_word(line, duration_str);
+   found_error = found_error ? found_error : find_word(line, 
error_str);
}
 
ck_assert_msg(found_timeout == true, "TIMEOUT not found");
ck_assert_msg(found_duration == true, "DURATION not found");
+   ck_assert_msg(found_error == true, "ERROR not found");
 }
 
 START_TEST(test_run_timeout_duration_ptest)
@@ -226,7 +229,7 @@ START_TEST(test_run_timeout_duration_ptest)
struct ptest_list *head = get_available_ptests(opts_directory);
unsigned int timeout = 1;
 
-   test_ptest_expected_failure(head, timeout, "hang", 
search_for_timeout_and_duration);
+   test_ptest_expected_failure(head, timeout, "hang", 
search_for_timeout_error_and_duration);
 
ptest_list_free_all(head);
 }
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 3/5] Report test failure on timeout

[Joshua Watt]

Even when a test times out, an "ERROR:" message should be printed so
that the OE selftest parser knows the test has failed.

Signed-off-by: Joshua Watt 
---
 utils.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/utils.c b/utils.c
index d0e6a99..aacf123 100644
--- a/utils.c
+++ b/utils.c
@@ -575,23 +575,20 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
entime = time(NULL);
duration = entime - sttime;
 
-   int exit_code = 0;
-
-   if (!_child_reader.timeouted) {
-   if (WIFEXITED(status)) {
-   exit_code = WEXITSTATUS(status);
-   if (exit_code) {
-   fprintf(fp, "\nERROR: 
Exit status is %d\n", exit_code);
-   rc += 1;
-   }
-   } else if (WIFSIGNALED(status)) {
-   int signal = WTERMSIG(status);
-   fprintf(fp, "\nERROR: Exited 
from signal %s (%d)\n", strsignal(signal), signal);
-   rc += 1;
-   } else {
-   fprintf(fp, "\nERROR: Exited 
for unknown reason (%d)\n", status);
+   int exit_code = -1;
+   if (WIFEXITED(status)) {
+   exit_code = WEXITSTATUS(status);
+   if (exit_code) {
+   fprintf(fp, "\nERROR: Exit 
status is %d\n", exit_code);
rc += 1;
}
+   } else if (WIFSIGNALED(status)) {
+   int signal = WTERMSIG(status);
+   fprintf(fp, "\nERROR: Exited from 
signal %s (%d)\n", strsignal(signal), signal);
+   rc += 1;
+   } else {
+   fprintf(fp, "\nERROR: Exited for 
unknown reason (%d)\n", status);
+   rc += 1;
}
fprintf(fp, "DURATION: %d\n", (int) duration);
if (_child_reader.timeouted) {
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 1/5] Revert "Change test timeout to be total elapsed time"

[Joshua Watt]

This reverts commit e50f2175d9c6b8aeb8b0bf687e5cca64a0f6e61a.

The timeout is actually the amount of time to wait until there is no
output from the test, not the total test time.

Signed-off-by: Joshua Watt 
---
 tests/data/hang/ptest/run-ptest |  1 -
 tests/utils.c   |  2 +-
 utils.c | 23 +++
 3 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/tests/data/hang/ptest/run-ptest b/tests/data/hang/ptest/run-ptest
index 9031be3..738041d 100755
--- a/tests/data/hang/ptest/run-ptest
+++ b/tests/data/hang/ptest/run-ptest
@@ -3,6 +3,5 @@
 echo "hang" 1>&2
 echo "hang"
 while true; do
-   echo "hang"
sleep 1
 done
diff --git a/tests/utils.c b/tests/utils.c
index 849a412..d82b90e 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -224,7 +224,7 @@ search_for_timeout_and_duration(const int rp, FILE 
*fp_stdout)
 START_TEST(test_run_timeout_duration_ptest)
 {
struct ptest_list *head = get_available_ptests(opts_directory);
-   unsigned int timeout = 3;
+   unsigned int timeout = 1;
 
test_ptest_expected_failure(head, timeout, "hang", 
search_for_timeout_and_duration);
 
diff --git a/utils.c b/utils.c
index 353d6dc..34ca2f0 100644
--- a/utils.c
+++ b/utils.c
@@ -403,8 +403,7 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
pid_t child;
int pipefd_stdout[2] = {-1, -1};
int pipefd_stderr[2] = {-1, -1};
-   time_t sttime, entime, now;
-   time_t timeout_deadline;
+   time_t sttime, entime;
time_t duration;
int slave;
int pgid = -1;
@@ -490,7 +489,6 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
}
 
sttime = time(NULL);
-   timeout_deadline = sttime + opts.timeout;
fprintf(fp, "%s\n", get_stime(stime, 
GET_STIME_BUF_SIZE, sttime));
fprintf(fp, "BEGIN: %s\n", ptest_dir);
 
@@ -521,17 +519,18 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
if (done) {
break;
}
-   now = time(NULL);
-   if (now >= timeout_deadline) {
-   kill(-child, SIGKILL);
-   _child_reader.timeouted = 1;
-   break;
-   }
 
-   int ret = poll(pfds, 2, 
(timeout_deadline - now) * 1000);
+   int ret = poll(pfds, 2, 
_child_reader.timeout*1000);
 
-   if (ret == 0) {
-   continue;
+   if (ret == 0 && 
!_child_reader.timeouted) {
+   /* kill the child if we haven't
+* already. Note that we
+* continue to read data from
+* the pipes until EOF to make
+* sure we get all the output
+*/
+   kill(-child, SIGKILL);
+   _child_reader.timeouted = 1;
}
 
for (int i = 0; i < 2; i++) {
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 2/5] Only collect system state on timeout

[Joshua Watt]

To match the behavior of the previous ptest-runner, only collect system
state when a test has timed out

Signed-off-by: Joshua Watt 
---
 utils.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/utils.c b/utils.c
index 34ca2f0..d0e6a99 100644
--- a/utils.c
+++ b/utils.c
@@ -556,21 +556,18 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
}
}
}
-   collect_system_state(_child_reader.fps[0]);
 
-   for (int i = 0; i < 2; i++) {
-   fflush(_child_reader.fps[i]);
-   }
-
-   /*
-* This kill is just in case the child did
-* something really silly like close its
-* stdout and stderr but then go into an
-* infinite loop and never exit. Normally, it
-* will just fail because the child is already
-* dead
-*/
-   if (!_child_reader.timeouted) {
+   if (_child_reader.timeouted) {
+   collect_system_state(fp);
+   } else {
+   /*
+* This kill is just in case the child 
did
+* something really silly like close its
+* stdout and stderr but then go into an
+* infinite loop and never exit. 
Normally, it
+* will just fail because the child is 
already
+* dead
+*/
kill(-child, SIGKILL);
}
waitpid(child, , 0);
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 5/5] Flush stdout and stderr after test

[Joshua Watt]

After reporting test results, flush the output buffers to ensure the
files are written out. Also flush again at the end of running all tests

Signed-off-by: Joshua Watt 
---
 utils.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/utils.c b/utils.c
index bd52544..59b8b77 100644
--- a/utils.c
+++ b/utils.c
@@ -601,6 +601,9 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
do_close(_stderr[PIPE_READ]);
do_close(_stderr[PIPE_WRITE]);
 
+   fflush(fp);
+   fflush(fp_stderr);
+
PTEST_LIST_ITERATE_END
fprintf(fp, "STOP: %s\n", progname);
} while (0);
@@ -611,6 +614,9 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
if (opts.xml_filename)
xml_finish(xh);
 
+   fflush(fp);
+   fflush(fp_stderr);
+
return rc;
 }
 
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 0/5] Fix ptest timeout errors

[Joshua Watt]

e50f217 ("Change test timeout to be total elapsed time") was misguided
in that the timeout is actually the timeout between receiving output
from the process and not the total test timeout. Fix this and also a few
other bugs that were noticed as being different between the old
ptest-runner and the new one.

Joshua Watt (5):
  Revert "Change test timeout to be total elapsed time"
  Only collect system state on timeout
  Report test failure on timeout
  Remove _child_reader singleton
  Flush stdout and stderr after test

 tests/data/hang/ptest/run-ptest |   1 -
 tests/utils.c   |   2 +-
 utils.c | 179 +++-
 3 files changed, 84 insertions(+), 98 deletions(-)

-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 4/5] Remove _child_reader singleton

[Joshua Watt]

Instead of using the _child_reader singleton to track the child process,
use variables on the stack. Also, limit the variable scope as much as
possible and used named constants for the pipe indices.

Signed-off-by: Joshua Watt 
---
 utils.c | 108 +---
 1 file changed, 48 insertions(+), 60 deletions(-)

diff --git a/utils.c b/utils.c
index aacf123..bd52544 100644
--- a/utils.c
+++ b/utils.c
@@ -55,14 +55,10 @@
 
 #define UNUSED(x) (void)(x)
 
-static struct {
-   int fds[2];
-   FILE *fps[2];
-
-   unsigned int timeout;
-   int timeouted;
-   int padding1;
-} _child_reader;
+enum {
+   PIPE_READ = 0,
+   PIPE_WRITE = 1,
+};
 
 static inline char *
 get_stime(char *stime, size_t size, time_t t)
@@ -398,15 +394,7 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
FILE *xh = NULL;
 
struct ptest_list *p;
-   char stime[GET_STIME_BUF_SIZE];
 
-   pid_t child;
-   int pipefd_stdout[2] = {-1, -1};
-   int pipefd_stderr[2] = {-1, -1};
-   time_t sttime, entime;
-   time_t duration;
-   int slave;
-   int pgid = -1;
 
if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -423,12 +411,16 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
 
fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p)
+   int pipefd_stdout[2] = {-1, -1};
+   int pipefd_stderr[2] = {-1, -1};
+   int pgid = -1;
+
if ((rc = pipe2(pipefd_stdout, 0)) == -1)
break;
 
if ((rc = pipe2(pipefd_stderr, 0)) == -1) {
-   close(pipefd_stdout[0]);
-   close(pipefd_stdout[1]);
+   close(pipefd_stdout[PIPE_READ]);
+   close(pipefd_stdout[PIPE_WRITE]);
break;
}
 
@@ -443,16 +435,18 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
fprintf(fp, "ERROR: getpgid() failed, %s\n", 
strerror(errno));
}
 
-   child = fork();
+   pid_t child = fork();
if (child == -1) {
fprintf(fp, "ERROR: Fork %s\n", 
strerror(errno));
rc = -1;
break;
} else if (child == 0) {
+   int slave;
+
close(0);
/* Close read ends of the pipe */
-   do_close(_stdout[0]);
-   do_close(_stderr[0]);
+   do_close(_stdout[PIPE_READ]);
+   do_close(_stderr[PIPE_READ]);
 
if ((slave = setup_slave_pty(fp)) < 0) {
fprintf(fp, "ERROR: could not setup pty 
(%d).", slave);
@@ -469,37 +463,35 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
fprintf(fp, "ERROR: Unable to attach to 
controlling tty, %s\n", strerror(errno));
}
 
-   run_child(p->run_ptest, pipefd_stdout[1], 
pipefd_stderr[1]);
+   run_child(p->run_ptest, 
pipefd_stdout[PIPE_WRITE], pipefd_stderr[PIPE_WRITE]);
 
} else {
-   int status;
+   bool timedout = false;
+   char stime[GET_STIME_BUF_SIZE];
 
/* Close write ends of the pipe, otherwise this 
process will never get EOF when the child dies */
-   do_close(_stdout[1]);
-   do_close(_stderr[1]);
-
-   _child_reader.fds[0] = pipefd_stdout[0];
-   _child_reader.fds[1] = pipefd_stderr[0];
-   _child_reader.fps[0] = fp;
-   _child_reader.fps[1] = fp_stderr;
-   _child_reader.timeout = opts.timeout;
-   _child_reader.timeouted = 0;
+   do_close(_stdout[PIPE_WRITE]);
+   do_close(_stderr[PIPE_WRITE]);
+
if (setpgid(child, pgid) == -1) {
fprintf(fp, "ERROR: setpgid() failed, 
%s\n", strerror(errno));
}
 
-   sttime = time(NULL)

[yocto] [ptest-runner][PATCH 4/4] Change test timeout to be total elapsed time

[Joshua Watt]

Changes the way that tests time out to be the total elapsed time for the
test, not just the time between receiving output from the test. This
matches the implementation before 8259375 ("runner: Remove threads and
mutexes").

Also update the timeout test case to test for this correctly.

Signed-off-by: Joshua Watt 
---
 tests/data/hang/ptest/run-ptest |  1 +
 tests/utils.c   |  2 +-
 utils.c | 23 ---
 3 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/tests/data/hang/ptest/run-ptest b/tests/data/hang/ptest/run-ptest
index 738041d..9031be3 100755
--- a/tests/data/hang/ptest/run-ptest
+++ b/tests/data/hang/ptest/run-ptest
@@ -3,5 +3,6 @@
 echo "hang" 1>&2
 echo "hang"
 while true; do
+   echo "hang"
sleep 1
 done
diff --git a/tests/utils.c b/tests/utils.c
index d82b90e..849a412 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -224,7 +224,7 @@ search_for_timeout_and_duration(const int rp, FILE 
*fp_stdout)
 START_TEST(test_run_timeout_duration_ptest)
 {
struct ptest_list *head = get_available_ptests(opts_directory);
-   unsigned int timeout = 1;
+   unsigned int timeout = 3;
 
test_ptest_expected_failure(head, timeout, "hang", 
search_for_timeout_and_duration);
 
diff --git a/utils.c b/utils.c
index 34ca2f0..353d6dc 100644
--- a/utils.c
+++ b/utils.c
@@ -403,7 +403,8 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
pid_t child;
int pipefd_stdout[2] = {-1, -1};
int pipefd_stderr[2] = {-1, -1};
-   time_t sttime, entime;
+   time_t sttime, entime, now;
+   time_t timeout_deadline;
time_t duration;
int slave;
int pgid = -1;
@@ -489,6 +490,7 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
}
 
sttime = time(NULL);
+   timeout_deadline = sttime + opts.timeout;
fprintf(fp, "%s\n", get_stime(stime, 
GET_STIME_BUF_SIZE, sttime));
fprintf(fp, "BEGIN: %s\n", ptest_dir);
 
@@ -519,18 +521,17 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
if (done) {
break;
}
-
-   int ret = poll(pfds, 2, 
_child_reader.timeout*1000);
-
-   if (ret == 0 && 
!_child_reader.timeouted) {
-   /* kill the child if we haven't
-* already. Note that we
-* continue to read data from
-* the pipes until EOF to make
-* sure we get all the output
-*/
+   now = time(NULL);
+   if (now >= timeout_deadline) {
kill(-child, SIGKILL);
_child_reader.timeouted = 1;
+   break;
+   }
+
+   int ret = poll(pfds, 2, 
(timeout_deadline - now) * 1000);
+
+   if (ret == 0) {
+   continue;
}
 
for (int i = 0; i < 2; i++) {
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 0/4] Stop running ptests in parallel

[Joshua Watt]

07d8a67 ("runner: Correctly handle running parallel tests") made an
incorrect assumption that it was OK to run ptests in parallel and
interleave the output. This is not correct since OE selftest expects all
text between a BEGIN and END block to be for a single ptest. Revert the
commit to run in parallel and add the correct fix for the bug with
running multiple ptests in a single invocation, as well as a few other
fixes

Joshua Watt (4):
  Revert "runner: Correctly handle running parallel tests"
  Recreate pipe for each test
  Report if child dies from a signal
  Change test timeout to be total elapsed time

 tests/data/hang/ptest/run-ptest   |   1 +
 tests/data/signal/ptest/run-ptest |  10 ++
 tests/utils.c |   4 +-
 utils.c   | 290 +-
 4 files changed, 140 insertions(+), 165 deletions(-)
 create mode 100755 tests/data/signal/ptest/run-ptest

-- 
2.33.0


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

[yocto] [ptest-runner][PATCH 3/4] Report if child dies from a signal

[Joshua Watt]

Tests can exit due to a signal, which should also be reported in the
test output.

Signed-off-by: Joshua Watt 
---
 tests/data/signal/ptest/run-ptest | 10 
 tests/utils.c | 39 +++---
 utils.c   | 40 +--
 3 files changed, 68 insertions(+), 21 deletions(-)
 create mode 100755 tests/data/signal/ptest/run-ptest

diff --git a/tests/data/signal/ptest/run-ptest 
b/tests/data/signal/ptest/run-ptest
new file mode 100755
index 000..93ac65b
--- /dev/null
+++ b/tests/data/signal/ptest/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+echo "signal" 1>&2
+echo "signal"
+
+kill -ABRT $$
+
+while true; do
+   sleep 1
+done
diff --git a/tests/utils.c b/tests/utils.c
index 19657ee..d82b90e 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -50,9 +50,10 @@ static char *ptests_found[] = {
"glibc",
"hang",
"python",
+   "signal",
NULL
 };
-static int ptests_found_length = 6;
+static int ptests_found_length = 7;
 static char *ptests_not_found[] = {
"busybox",
"perl",
@@ -186,6 +187,7 @@ START_TEST(test_run_ptests)
head = get_available_ptests(opts_directory);
ptest_list_remove(head, "hang", 1);
ptest_list_remove(head, "fail", 1);
+   ptest_list_remove(head, "signal", 1);
 
rc = run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc == 0);
@@ -215,8 +217,8 @@ search_for_timeout_and_duration(const int rp, FILE 
*fp_stdout)
found_duration = found_duration ? found_duration : 
find_word(line, duration_str);
}
 
-   ck_assert(found_timeout == true);
-   ck_assert(found_duration == true);
+   ck_assert_msg(found_timeout == true, "TIMEOUT not found");
+   ck_assert_msg(found_duration == true, "DURATION not found");
 }
 
 START_TEST(test_run_timeout_duration_ptest)
@@ -230,6 +232,36 @@ START_TEST(test_run_timeout_duration_ptest)
 }
 END_TEST
 
+static void
+search_for_signal_and_duration(const int rp, FILE *fp_stdout)
+{
+   char line_buf[PRINT_PTEST_BUF_SIZE];
+   bool found_error = false, found_duration = false;
+   char *line = NULL;
+
+   ck_assert(rp != 0);
+
+   while ((line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp_stdout)) != 
NULL) {
+   // once true, stay true
+   found_error = found_error ? found_error : find_word(line, 
"ERROR: Exited from signal");
+   found_duration = found_duration ? found_duration : 
find_word(line, "DURATION");
+   }
+
+   ck_assert_msg(found_error == true, "ERROR not found");
+   ck_assert_msg(found_duration == true, "DURATION not found");
+}
+
+START_TEST(test_run_signal_ptest)
+{
+   struct ptest_list *head = get_available_ptests(opts_directory);
+   unsigned int timeout = 10;
+
+   test_ptest_expected_failure(head, timeout, "signal", 
search_for_signal_and_duration);
+
+   ptest_list_free_all(head);
+}
+END_TEST
+
 static void
 search_for_fail(const int rp, FILE *fp_stdout)
 {
@@ -318,6 +350,7 @@ utils_suite(void)
tcase_add_test(tc_core, test_filter_ptests);
tcase_add_test(tc_core, test_run_ptests);
tcase_add_test(tc_core, test_run_timeout_duration_ptest);
+   tcase_add_test(tc_core, test_run_signal_ptest);
tcase_add_test(tc_core, test_run_fail_ptest);
tcase_add_test(tc_core, test_xml_pass);
tcase_add_test(tc_core, test_xml_fail);
diff --git a/utils.c b/utils.c
index c1188dd..34ca2f0 100644
--- a/utils.c
+++ b/utils.c
@@ -343,18 +343,6 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
/* exit(1); not needed? */
 }
 
-static inline int
-wait_child(pid_t pid)
-{
-   int status = -1;
-
-   waitpid(pid, , 0);
-   if (WIFEXITED(status))
-   status = WEXITSTATUS(status);
-
-   return status;
-}
-
 /* Returns an integer file descriptor.
  * If it returns < 0, an error has occurred.
  * Otherwise, it has returned the slave pty file descriptor.
@@ -585,21 +573,37 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
if (!_child_reader.timeouted) {
kill(-child, SIGKILL);
}
-   status = wait_child(child);
+   waitpid(child, , 0);
 
entime = time(NULL);
duration = entime - sttime;
 
-   if (status) {
-   fprintf(fp, "\nERROR: Exit status is 
%d\n", status);
-   rc += 1;
+   int exit_code = 0;

[yocto] [ptest-runner][PATCH 2/4] Recreate pipe for each test

[Joshua Watt]

The write end of the pipe has to be closed by ptest-runner to make sure
that it will get EOF when the child process is done with it. This means
that a new pipe needs to be opened for each child so that the write ends
can be passed to it.

Fixes the problem where tests would be reported with no output when
ptest-runner was told to run multiple tests because they were passed
invalid stdin/stderr pipes.

Signed-off-by: Joshua Watt 
---
 utils.c | 45 -
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/utils.c b/utils.c
index 6a6e848..c1188dd 100644
--- a/utils.c
+++ b/utils.c
@@ -61,7 +61,6 @@ static struct {
 
unsigned int timeout;
int timeouted;
-   pid_t pid;
int padding1;
 } _child_reader;
 
@@ -414,8 +413,8 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
char stime[GET_STIME_BUF_SIZE];
 
pid_t child;
-   int pipefd_stdout[2];
-   int pipefd_stderr[2];
+   int pipefd_stdout[2] = {-1, -1};
+   int pipefd_stderr[2] = {-1, -1};
time_t sttime, entime;
time_t duration;
int slave;
@@ -429,28 +428,22 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
 
do
{
-   if ((rc = pipe2(pipefd_stdout, 0)) == -1)
-   break;
-
-   if ((rc = pipe2(pipefd_stderr, 0)) == -1) {
-   close(pipefd_stdout[0]);
-   close(pipefd_stdout[1]);
-   break;
-   }
-
if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
fprintf(fp, "ERROR: Unable to detach from controlling 
tty, %s\n", strerror(errno));
}
 
-   _child_reader.fds[0] = pipefd_stdout[0];
-   _child_reader.fds[1] = pipefd_stderr[0];
-   _child_reader.fps[0] = fp;
-   _child_reader.fps[1] = fp_stderr;
-   _child_reader.timeout = opts.timeout;
-   _child_reader.timeouted = 0;
 
fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p)
+   if ((rc = pipe2(pipefd_stdout, 0)) == -1)
+   break;
+
+   if ((rc = pipe2(pipefd_stderr, 0)) == -1) {
+   close(pipefd_stdout[0]);
+   close(pipefd_stdout[1]);
+   break;
+   }
+
char *ptest_dir = strdup(p->run_ptest);
if (ptest_dir == NULL) {
rc = -1;
@@ -497,7 +490,12 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
do_close(_stdout[1]);
do_close(_stderr[1]);
 
-   _child_reader.pid = child;
+   _child_reader.fds[0] = pipefd_stdout[0];
+   _child_reader.fds[1] = pipefd_stderr[0];
+   _child_reader.fps[0] = fp;
+   _child_reader.fps[1] = fp_stderr;
+   _child_reader.timeout = opts.timeout;
+   _child_reader.timeouted = 0;
if (setpgid(child, pgid) == -1) {
fprintf(fp, "ERROR: setpgid() failed, 
%s\n", strerror(errno));
}
@@ -543,7 +541,7 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
 * the pipes until EOF to make
 * sure we get all the output
 */
-   kill(-_child_reader.pid, 
SIGKILL);
+   kill(-child, SIGKILL);
_child_reader.timeouted = 1;
}
 
@@ -585,7 +583,7 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
 * dead
 */
if (!_child_reader.timeouted) {
-   kill(-_child_reader.pid, SIGKILL);
+   kill(-child, SIGKILL);
}
status = wait_child(child);
 
@@ -607,6 +605,11 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
fprintf(fp, "%s\n", get_stime(stime, 
GET_STIME_BUF_SIZE, entime));
}
free(ptest_dir);
+   do_close(_stdout[0]);
+   do_close(_std

[yocto] [ptest-runner][PATCH 1/4] Revert "runner: Correctly handle running parallel tests"

[Joshua Watt]

This reverts commit 07d8a676aa962ecc5ec264ec33b0074adf2a8733.

This commit incorrectly assumed that ptest ran tests in parallel, which
is not true. Doing so interleaves the test output in the log file, which
the OE selftest parser cannot handle and thus breaks the test cases.

Signed-off-by: Joshua Watt 
---
 tests/utils.c |  39 +---
 utils.c   | 248 +-
 2 files changed, 105 insertions(+), 182 deletions(-)

diff --git a/tests/utils.c b/tests/utils.c
index 4560e93..19657ee 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -50,10 +50,9 @@ static char *ptests_found[] = {
"glibc",
"hang",
"python",
-   "signal",
NULL
 };
-static int ptests_found_length = 7;
+static int ptests_found_length = 6;
 static char *ptests_not_found[] = {
"busybox",
"perl",
@@ -187,7 +186,6 @@ START_TEST(test_run_ptests)
head = get_available_ptests(opts_directory);
ptest_list_remove(head, "hang", 1);
ptest_list_remove(head, "fail", 1);
-   ptest_list_remove(head, "signal", 1);
 
rc = run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc == 0);
@@ -217,8 +215,8 @@ search_for_timeout_and_duration(const int rp, FILE 
*fp_stdout)
found_duration = found_duration ? found_duration : 
find_word(line, duration_str);
}
 
-   ck_assert_msg(found_timeout == true, "TIMEOUT not found");
-   ck_assert_msg(found_duration == true, "DURATION not found");
+   ck_assert(found_timeout == true);
+   ck_assert(found_duration == true);
 }
 
 START_TEST(test_run_timeout_duration_ptest)
@@ -232,36 +230,6 @@ START_TEST(test_run_timeout_duration_ptest)
 }
 END_TEST
 
-static void
-search_for_signal_and_duration(const int rp, FILE *fp_stdout)
-{
-   char line_buf[PRINT_PTEST_BUF_SIZE];
-   bool found_error = false, found_duration = false;
-   char *line = NULL;
-
-   ck_assert(rp != 0);
-
-   while ((line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp_stdout)) != 
NULL) {
-   // once true, stay true
-   found_error = found_error ? found_error : find_word(line, 
"ERROR: Exited with signal");
-   found_duration = found_duration ? found_duration : 
find_word(line, "DURATION");
-   }
-
-   ck_assert_msg(found_error == true, "ERROR not found");
-   ck_assert_msg(found_duration == true, "DURATION not found");
-}
-
-START_TEST(test_run_signal_ptest)
-{
-   struct ptest_list *head = get_available_ptests(opts_directory);
-   unsigned int timeout = 10;
-
-   test_ptest_expected_failure(head, timeout, "signal", 
search_for_signal_and_duration);
-
-   ptest_list_free_all(head);
-}
-END_TEST
-
 static void
 search_for_fail(const int rp, FILE *fp_stdout)
 {
@@ -350,7 +318,6 @@ utils_suite(void)
tcase_add_test(tc_core, test_filter_ptests);
tcase_add_test(tc_core, test_run_ptests);
tcase_add_test(tc_core, test_run_timeout_duration_ptest);
-   tcase_add_test(tc_core, test_run_signal_ptest);
tcase_add_test(tc_core, test_run_fail_ptest);
tcase_add_test(tc_core, test_xml_pass);
tcase_add_test(tc_core, test_xml_fail);
diff --git a/utils.c b/utils.c
index c444b2a..6a6e848 100644
--- a/utils.c
+++ b/utils.c
@@ -60,20 +60,11 @@ static struct {
FILE *fps[2];
 
unsigned int timeout;
+   int timeouted;
+   pid_t pid;
int padding1;
 } _child_reader;
 
-struct running_test {
-   struct running_test *next;
-   char *ptest_dir;
-   pid_t pid;
-   time_t start_time;
-   time_t end_time;
-   int status;
-   bool timed_out;
-   bool exited;
-};
-
 static inline char *
 get_stime(char *stime, size_t size, time_t t)
 {
@@ -353,18 +344,16 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
/* exit(1); not needed? */
 }
 
-static void
-wait_child(struct running_test *test, int options)
+static inline int
+wait_child(pid_t pid)
 {
-   int status;
+   int status = -1;
 
-   if (!test->exited) {
-   if (waitpid(test->pid, , options) == test->pid) {
-   test->status = status;
-   test->end_time = time(NULL);
-   test->exited = true;
-   }
-   }
+   waitpid(pid, , 0);
+   if (WIFEXITED(status))
+   status = WEXITSTATUS(status);
+
+   return status;
 }
 
 /* Returns an integer file descriptor.
@@ -427,9 +416,10 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
pid_t child;
int pipefd_stdout[2];
int pipefd_stderr[2];
+   time_t sttime, entime;
+   time_t duration;
int slave;
int pgid = -1;
-   stru

[yocto][meta-mingw][PATCH] mingw32: Fix GCC override

[Joshua Watt]

6badeda ("mingw32: Add WINDRES export for SDK") attempted to fix the GCC
13 Canadian cross compile for MinGW host, but used the broad sdkming32
override, which made it apply to all target recipes. This caused build
errors in other recipes. Move the variables so that they only apply when
cross compiling GCC instead of globally.

[YOCTO #15158]

Signed-off-by: Joshua Watt 
---
 conf/machine-sdk/include/mingw32-common.inc| 3 ---
 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend | 4 
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/conf/machine-sdk/include/mingw32-common.inc 
b/conf/machine-sdk/include/mingw32-common.inc
index 1007bd4..b993307 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -38,9 +38,6 @@ TESTSDKEXT_CLASS_NAME = ""
 WINDMC:mingw32 = "${HOST_PREFIX}windmc"
 WINDRES:mingw32 = "${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}"
 RC:mingw32 = "${WINDRES}"
-WINDMC:sdkmingw32 = "${HOST_PREFIX}windmc"
-WINDRES:sdkmingw32 = "${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}"
-RC:sdkmingw32 = "${WINDRES}"
 
 export WINDMC
 export WINDRES
diff --git a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend 
b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
index 13ea016..25a449f 100644
--- a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
+++ b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
@@ -5,6 +5,10 @@ EXEEXT:sdkmingw32 = ".exe"
 ELFUTILS:sdkmingw32 = ""
 DEPENDS:remove:sdkmingw32 = "nativesdk-gettext"
 
+WINDMC:sdkmingw32 = "${HOST_PREFIX}windmc"
+WINDRES:sdkmingw32 = "${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}"
+RC:sdkmingw32 = "${WINDRES}"
+
 # With plugins enabled, it will output 'dll.a' files that are mistaken
 # for ELF which can trigger a failure.  Simply avoid processing these
 # to avoid the error condition.
-- 
2.33.0


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

[yocto] [ptest-runner][PATCH] runner: Correctly handle running parallel tests

[Joshua Watt]

8259375 ("runner: Remove threads and mutexes") did not correctly account
for the case where multiple tests are being run in parallel by
ptest-runner. Fix the code to track all of the child processes (but
still have them share the same stdout/stderr pipe) and wait for all of
them to finish before exiting.

Signed-off-by: Joshua Watt 
---
 tests/utils.c |  39 +++-
 utils.c   | 248 +-
 2 files changed, 182 insertions(+), 105 deletions(-)

diff --git a/tests/utils.c b/tests/utils.c
index 19657ee..4560e93 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -50,9 +50,10 @@ static char *ptests_found[] = {
"glibc",
"hang",
"python",
+   "signal",
NULL
 };
-static int ptests_found_length = 6;
+static int ptests_found_length = 7;
 static char *ptests_not_found[] = {
"busybox",
"perl",
@@ -186,6 +187,7 @@ START_TEST(test_run_ptests)
head = get_available_ptests(opts_directory);
ptest_list_remove(head, "hang", 1);
ptest_list_remove(head, "fail", 1);
+   ptest_list_remove(head, "signal", 1);
 
rc = run_ptests(head, opts, "test_run_ptests", fp_stdout, fp_stderr);
ck_assert(rc == 0);
@@ -215,8 +217,8 @@ search_for_timeout_and_duration(const int rp, FILE 
*fp_stdout)
found_duration = found_duration ? found_duration : 
find_word(line, duration_str);
}
 
-   ck_assert(found_timeout == true);
-   ck_assert(found_duration == true);
+   ck_assert_msg(found_timeout == true, "TIMEOUT not found");
+   ck_assert_msg(found_duration == true, "DURATION not found");
 }
 
 START_TEST(test_run_timeout_duration_ptest)
@@ -230,6 +232,36 @@ START_TEST(test_run_timeout_duration_ptest)
 }
 END_TEST
 
+static void
+search_for_signal_and_duration(const int rp, FILE *fp_stdout)
+{
+   char line_buf[PRINT_PTEST_BUF_SIZE];
+   bool found_error = false, found_duration = false;
+   char *line = NULL;
+
+   ck_assert(rp != 0);
+
+   while ((line = fgets(line_buf, PRINT_PTEST_BUF_SIZE, fp_stdout)) != 
NULL) {
+   // once true, stay true
+   found_error = found_error ? found_error : find_word(line, 
"ERROR: Exited with signal");
+   found_duration = found_duration ? found_duration : 
find_word(line, "DURATION");
+   }
+
+   ck_assert_msg(found_error == true, "ERROR not found");
+   ck_assert_msg(found_duration == true, "DURATION not found");
+}
+
+START_TEST(test_run_signal_ptest)
+{
+   struct ptest_list *head = get_available_ptests(opts_directory);
+   unsigned int timeout = 10;
+
+   test_ptest_expected_failure(head, timeout, "signal", 
search_for_signal_and_duration);
+
+   ptest_list_free_all(head);
+}
+END_TEST
+
 static void
 search_for_fail(const int rp, FILE *fp_stdout)
 {
@@ -318,6 +350,7 @@ utils_suite(void)
tcase_add_test(tc_core, test_filter_ptests);
tcase_add_test(tc_core, test_run_ptests);
tcase_add_test(tc_core, test_run_timeout_duration_ptest);
+   tcase_add_test(tc_core, test_run_signal_ptest);
tcase_add_test(tc_core, test_run_fail_ptest);
tcase_add_test(tc_core, test_xml_pass);
tcase_add_test(tc_core, test_xml_fail);
diff --git a/utils.c b/utils.c
index 6a6e848..c444b2a 100644
--- a/utils.c
+++ b/utils.c
@@ -60,11 +60,20 @@ static struct {
FILE *fps[2];
 
unsigned int timeout;
-   int timeouted;
-   pid_t pid;
int padding1;
 } _child_reader;
 
+struct running_test {
+   struct running_test *next;
+   char *ptest_dir;
+   pid_t pid;
+   time_t start_time;
+   time_t end_time;
+   int status;
+   bool timed_out;
+   bool exited;
+};
+
 static inline char *
 get_stime(char *stime, size_t size, time_t t)
 {
@@ -344,16 +353,18 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
/* exit(1); not needed? */
 }
 
-static inline int
-wait_child(pid_t pid)
+static void
+wait_child(struct running_test *test, int options)
 {
-   int status = -1;
-
-   waitpid(pid, , 0);
-   if (WIFEXITED(status))
-   status = WEXITSTATUS(status);
+   int status;
 
-   return status;
+   if (!test->exited) {
+   if (waitpid(test->pid, , options) == test->pid) {
+   test->status = status;
+   test->end_time = time(NULL);
+   test->exited = true;
+   }
+   }
 }
 
 /* Returns an integer file descriptor.
@@ -416,10 +427,9 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
pid_t child;
int pipefd_stdout[2];
int pipefd_stderr[2];
-   time_t sttime, entime;
-   time_t duration;
int slave;

[yocto] [ptest-runner][PATCH] runner: Remove threads and mutexes

[Joshua Watt]

Re-works the way that ptest-runner waits for processes to exit to make
it simpler and eliminate the need for a thread. In the new system, the
runner will not wait() for the process to exit until both the stdout and
stderr pipes have gotten an EOF. This works because when a process
exits, the pipes will be closed. This also ensures that the runner reads
all available output from the child process before moving on. After
reading all the data, then ptest runner will wait() on the process,
which should never block (unless a process does something strange like
close its stdout and stderr without exiting, which is handled with an
extra SIGKILL to prevent deadlock). Test timeouts are handled by sending
the child process SIGKILL if no output is detected for the timeout, but
the loop still waits for the file descriptors to reach EOF before
reaping the child.

Signed-off-by: Joshua Watt 

[YOCTO #15154]

Signed-off-by: Joshua Watt 
---
 utils.c | 214 +---
 1 file changed, 125 insertions(+), 89 deletions(-)

diff --git a/utils.c b/utils.c
index 65b1df3..6a6e848 100644
--- a/utils.c
+++ b/utils.c
@@ -39,7 +39,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -63,7 +63,6 @@ static struct {
int timeouted;
pid_t pid;
int padding1;
-   pthread_mutex_t fd_lock;
 } _child_reader;
 
 static inline char *
@@ -88,6 +87,29 @@ check_allocation1(void *p, size_t size, char *file, int 
line, int exit_on_null)
}
 }
 
+static void
+set_nonblocking(int fd)
+{
+   int flags = fcntl(fd, F_GETFL, 0);
+   if (flags < 0) {
+   fprintf(stderr, "Unable to get flags for FD %d: %s\n", fd, 
strerror(errno));
+   return;
+   }
+
+   if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) < 0) {
+   fprintf(stderr, "Unable to set flags for FD %d: %s\n", fd, 
strerror(errno));
+   }
+}
+
+static void
+do_close(int *fd)
+{
+   if (*fd >= 0) {
+   close(*fd);
+   *fd = -1;
+   }
+}
+
 
 struct ptest_list *
 get_available_ptests(const char *dir)
@@ -227,7 +249,7 @@ filter_ptests(struct ptest_list *head, char **ptests, int 
ptest_num)
}
 
head_new = ptest_list_alloc();
-   if (head_new == NULL) 
+   if (head_new == NULL)
break;
 
for (i = 0; i < ptest_num; i++) {
@@ -259,7 +281,7 @@ filter_ptests(struct ptest_list *head, char **ptests, int 
ptest_num)
if (fail) {
PTEST_LIST_FREE_ALL_CLEAN(head_new);
errno = saved_errno;
-   } 
+   }
} while (0);
 
return head_new;
@@ -269,7 +291,7 @@ filter_ptests(struct ptest_list *head, char **ptests, int 
ptest_num)
  * i.e. do not close STDIN, STDOUT, STDERR.
  * Typically called in in a child process after forking
  * but before exec as a good policy especially for security.
- */ 
+ */
 static void
 close_fds(void)
 {
@@ -303,55 +325,6 @@ collect_system_state(FILE* fout)
}
 }
 
-static void *
-read_child(void *arg)
-{
-   struct pollfd pfds[2];
-   int r;
-
-   UNUSED(arg);
-
-   pfds[0].fd = _child_reader.fds[0];
-   pfds[0].events = POLLIN;
-   pfds[1].fd = _child_reader.fds[1];
-   pfds[1].events = POLLIN;
-
-   do {
-   r = poll(pfds, 2, _child_reader.timeout*1000);
-   pthread_mutex_lock(&_child_reader.fd_lock);
-   if (r > 0) {
-   char buf[WAIT_CHILD_BUF_MAX_SIZE];
-   ssize_t n;
-
-   if (pfds[0].revents != 0) {
-   n = read(_child_reader.fds[0], buf, 
WAIT_CHILD_BUF_MAX_SIZE);
-   if (n > 0)
-   fwrite(buf, (size_t)n, 1, 
_child_reader.fps[0]);
-   }
-
-   if (pfds[1].revents != 0) {
-   n = read(_child_reader.fds[1], buf, 
WAIT_CHILD_BUF_MAX_SIZE);
-   if (n > 0)
-   fwrite(buf, (size_t)n, 1, 
_child_reader.fps[1]);
-   }
-
-   } else if (r == 0) {
-   // no output from the test after a timeout; the test is 
stuck, so collect
-   // as much data from the system as possible and kill 
the test
-   collect_system_state(_child_reader.fps[0]);
-   _child_reader.timeouted = 1;
-   pthread_mutex_unlock(&_child_reader.fd_lock);
-   kill(-_child_reader.pid, SIGKILL);
-}
-
-   fflush(_child_reader.fps[0]);
-   fflush(_child_reader.fps[1]);
-   pthread_mutex_unlock(&_child_reader.fd_lock);
-   } while (1);
-
-  

Re: [yocto] [meta-mingw] [PATCHv2] Ignore WINDMC from hash

[Joshua Watt]

On Thu, Jun 8, 2023 at 4:49 AM Samuli Piippo  wrote:
>
> Amend 6c54d16058ed8fb911c44df93b5732ae693b9803 and add WINDMC
> to be ignored from hash, otherwise it contaminates sstate cache
> for every recipe.

Applied. Thanks

>
> Signed-off-by: Samuli Piippo 
> ---
>  conf/machine-sdk/include/mingw32-common.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/conf/machine-sdk/include/mingw32-common.inc 
> b/conf/machine-sdk/include/mingw32-common.inc
> index 9ec6e07..1007bd4 100644
> --- a/conf/machine-sdk/include/mingw32-common.inc
> +++ b/conf/machine-sdk/include/mingw32-common.inc
> @@ -46,7 +46,7 @@ export WINDMC
>  export WINDRES
>  export RC
>
> -BB_BASEHASH_IGNORE_VARS:append = " WINDRES RC"
> +BB_BASEHASH_IGNORE_VARS:append = " WINDRES RC WINDMC"
>
>  # Needed to override no-static-libs.inc
>  DISABLE_STATIC:mingw32 = ""
> --
> 2.25.1
>

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

[yocto][meta-mingw][PATCH] tests: Map WORKDIR to W: to shorten paths

[Joshua Watt]

In some cases Wine (and Windows proper) struggle with very long paths;
in particular the way that gcc invokes the 'cc1' subprogram is limited
in how deep the path to the subprogram can be. This can cause issues
when testing the SDK under wine, as the paths can easily get quite long
and exceed this limit. In order to work around this, setup the Wine test
context so that the W: drive maps to the SDK image ${WORKDIR}, which
allows wine to effectively use paths relative to this directory making
them significantly shorter.

Signed-off-by: Joshua Watt 
---
 lib/oeqa/sdkmingw/case.py|  4 ++--
 lib/oeqa/sdkmingw/context.py | 11 ++-
 lib/oeqa/sdkmingw/testsdk.py |  5 -
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/lib/oeqa/sdkmingw/case.py b/lib/oeqa/sdkmingw/case.py
index 169c143..dee7d3d 100644
--- a/lib/oeqa/sdkmingw/case.py
+++ b/lib/oeqa/sdkmingw/case.py
@@ -56,7 +56,7 @@ class OESDKMinGWTestCase(OESDKTestCase):
 return s[1:-1]
 return s
 
-command = ['wine', 'cmd', '/c', self.tc.wine_sdk_env, '>', 'NUL', 
'&&', 'cd', self.wine_test_dir, '&&']
+command = ['wine', 'cmd', '/c', self.tc.wine_sdk_env, '>', 'NUL', '&&']
 
 # Perform some massaging so that commands can be written naturally in
 # test cases. shlex.split() in Non-posix mode gets us most of the way
@@ -65,7 +65,7 @@ class OESDKMinGWTestCase(OESDKTestCase):
 command.extend(strip_quotes(s) for s in shlex.split(cmd, posix=False))
 
 return subprocess.check_output(command, env=self.tc.get_wine_env(),
-stderr=subprocess.STDOUT, universal_newlines=True)
+stderr=subprocess.STDOUT, universal_newlines=True, 
cwd=self.test_dir)
 
 def assertIsTargetElf(self, path):
 import oe.qa
diff --git a/lib/oeqa/sdkmingw/context.py b/lib/oeqa/sdkmingw/context.py
index edabcbd..5319223 100644
--- a/lib/oeqa/sdkmingw/context.py
+++ b/lib/oeqa/sdkmingw/context.py
@@ -12,10 +12,19 @@ class OESDKMinGWTestContext(OESDKTestContext):
 sdk_files_dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), 
"files")
 
 def __init__(self, td=None, logger=None, sdk_dir=None, sdk_env=None, 
wine_prefix=None,
-wine_arch=None, target_pkg_manifest=None, host_pkg_manifest=None):
+wine_arch=None, wine_devices={}, target_pkg_manifest=None, 
host_pkg_manifest=None):
 super(OESDKMinGWTestContext, self).__init__(td, logger, sdk_dir, 
sdk_env, target_pkg_manifest, host_pkg_manifest)
 self.wine_prefix = wine_prefix
 self.wine_arch = wine_arch
+# Create the wine environment
+subprocess.check_output(["wine", "cmd", "/c", "echo 1"], 
env=self.get_wine_env())
+
+device_dir  = "%s/dosdevices" % wine_prefix
+bb.utils.mkdirhier(device_dir)
+for device, path in wine_devices.items():
+device_path = "%s/%s" % (device_dir, device)
+os.symlink(os.path.relpath(path, device_dir), device_path)
+
 self.wine_sdk_dir = self.wine_path(sdk_dir)
 self.wine_sdk_env = self.wine_path(sdk_env)
 
diff --git a/lib/oeqa/sdkmingw/testsdk.py b/lib/oeqa/sdkmingw/testsdk.py
index 173cfd9..5c80bb4 100644
--- a/lib/oeqa/sdkmingw/testsdk.py
+++ b/lib/oeqa/sdkmingw/testsdk.py
@@ -44,6 +44,9 @@ class TestSDKMinGW(TestSDK):
 
 return {
 'wine_prefix': wine_prefix,
-'wine_arch': d.getVar('TESTSDK_WINEARCH') or 'win64'
+'wine_arch': d.getVar('TESTSDK_WINEARCH') or 'win64',
+'wine_devices': {
+'w:': d.getVar("WORKDIR"),
 }
+}
 
-- 
2.33.0


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

[yocto] [PATCH yocto-autobuilder-helper v2] config.json: Use buildtools for Ubuntu 18.04

[Joshua Watt]

Bitbake is going to upgrade the minimum python to 3.8, so Ubuntu 18.04
needs to use buildtools tarball to remain compatible

Signed-off-by: Joshua Watt 
---
 config.json | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 713afe5..1149c98 100644
--- a/config.json
+++ b/config.json
@@ -11,6 +11,7 @@
 "BUILDTOOLS_URL_TEMPLOCAL" : 
"/srv/autobuilder/autobuilder.yocto.io/pub/non-release/20210214-8/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.2+snapshot-7d38cc8e749aedb8435ee71847e04b353cca541d.sh",
 "BUILDTOOLS_URL_TEMPLOCAL2" : 
"https://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M3/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200315.sh;,
 "BUILDTOOLS_URL" : 
"https://downloads.yoctoproject.org/releases/yocto/yocto-3.4/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.4.sh;,
+"BUILDTOOLS_ARM_URL" : 
"https://downloads.yoctoproject.org/releases/yocto/yocto-3.4/buildtools/aarch64-buildtools-extended-nativesdk-standalone-3.4.sh;,
 "BUILDTOOLS_MAKE_URL" : 
"/srv/autobuilder/autobuilder.yocto.io/pub/non-release/20220413-28/buildtools/x86_64-buildtools-make-nativesdk-standalone-4.0.sh",
 
 "REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
@@ -1287,6 +1288,8 @@
 "debian9*" : "${BUILDTOOLS_URL}",
 "centos7*" : "${BUILDTOOLS_URL}",
 "ubuntu1604*" : "${BUILDTOOLS_URL}",
+"ubuntu1804-ty-*" : "${BUILDTOOLS_URL}",
+"ubuntu1804-arm-*" : "${BUILDTOOLS_ARM_URL}",
 "alma8*"   : "${BUILDTOOLS_MAKE_URL}",
 "centos8*" : "${BUILDTOOLS_MAKE_URL}",
 "stream8*" : "${BUILDTOOLS_MAKE_URL}",
@@ -1294,6 +1297,8 @@
 "opensuse154*" : "${BUILDTOOLS_MAKE_URL}",
 "perf-alma8*"  : "${BUILDTOOLS_MAKE_URL}",
 "perf-centos7*" : "${BUILDTOOLS_URL}",
-"perf-ubuntu1604*" : "${BUILDTOOLS_URL}"
+"perf-ubuntu1604*" : "${BUILDTOOLS_URL}",
+"perf-ubuntu1804-ty-*" : "${BUILDTOOLS_URL}",
+"perf-ubuntu1804-arm-*" : "${BUILDTOOLS_ARM_URL}"
 }
 }
-- 
2.33.0


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

[yocto] [PATCH yocto-autobuilder-helper] config.json: Use buildtools for Ubuntu 18.04

[Joshua Watt]

Bitbake is going to upgrade the minimum python to 3.8, so Ubuntu 18.04
needs to use buildtools tarball to remain compatible

Signed-off-by: Joshua Watt 
---
 config.json | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 713afe5..3d89856 100644
--- a/config.json
+++ b/config.json
@@ -1287,6 +1287,7 @@
 "debian9*" : "${BUILDTOOLS_URL}",
 "centos7*" : "${BUILDTOOLS_URL}",
 "ubuntu1604*" : "${BUILDTOOLS_URL}",
+"ubuntu1804*" : "${BUILDTOOLS_URL}",
 "alma8*"   : "${BUILDTOOLS_MAKE_URL}",
 "centos8*" : "${BUILDTOOLS_MAKE_URL}",
 "stream8*" : "${BUILDTOOLS_MAKE_URL}",
@@ -1294,6 +1295,7 @@
 "opensuse154*" : "${BUILDTOOLS_MAKE_URL}",
 "perf-alma8*"  : "${BUILDTOOLS_MAKE_URL}",
 "perf-centos7*" : "${BUILDTOOLS_URL}",
-"perf-ubuntu1604*" : "${BUILDTOOLS_URL}"
+"perf-ubuntu1604*" : "${BUILDTOOLS_URL}",
+"perf-ubuntu1804*" : "${BUILDTOOLS_URL}"
 }
 }
-- 
2.33.0


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

Re: [yocto] Reproducible builds not working with musl?

[Joshua Watt]

On 11/21/22 08:38, Alexander Kanavin wrote:

On Mon, 21 Nov 2022 at 15:31, Kenth Eriksson
 wrote:

Having trouble with reproducible builds in yocto on dunfell release with musl 
as libc. E.g. I can see that the build path for musl crti assembler file is 
leaking through and becomes visible when I do strings on libraries and binaries.

$ strings 
/opt/infn-xr/1.0/sysroots/aarch64-xr-linux-musl/usr/lib64/.debug/libcrypto.so.1.1
 | grep crt[a-z]\.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crti.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crtn.o
$

Is this a known issue? Yocto passes -fmacro-prefix-map and -fdebug-prefix-map 
as part of DEBUG_PREFIX_MAP to eliminate paths to WORKDIR. But it looks as that 
fails for the musl assembler file?

Testing reproducibility properly is a heavy exercise (you need to
build everything from scratch, then compare), and so we do it only for
glibc.

There have been recent fixes and tests to check that host paths do not
leak into target files, but dunfell probably has neither the fix nor
the test.


This is correct; it's hard for upstream to test every possible 
combination for reproducibility. We do try to get some decent coverage, 
but ultimately if you really care about reproducible builds, you should 
setup a reproducible build test for your exact combination. We've tried 
to make this pretty easy, see https://youtu.be/zXEdqGS62Wc?t=1021




Alex




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

Re: [yocto] [meta-mingw][kirkstone][PATCH] toolchain-scripts-mingw32.bbclass: Remove trailing slash in SDKROOT

[Joshua Watt]

Ya, I queued it in master-next. Let me run it through the AB then we
can merge it

On Fri, Oct 28, 2022 at 7:00 AM Hamza, Muhammad
 wrote:
>
> Hi,
> Any update on this?
>
> -Original Message-
> From: Hamza, Muhammad 
> Sent: Monday, October 24, 2022 11:03 AM
> To: yocto@lists.yoctoproject.org
> Cc: jpewhac...@gmail.com; Hamza, Muhammad 
> Subject: [meta-mingw][kirkstone][PATCH] toolchain-scripts-mingw32.bbclass: 
> Remove trailing slash in SDKROOT
>
> Modify toolchain-scripts-mingw32.bbclass to add a check in environment-setup 
> script which removes trailing slash in path of SDKROOT.
> This is needed to avoid multiple adjacent slashes in paths which are produced 
> by appending to SDKROOT.
> In reference to 
> https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN
> naming convention used for paths and disk drives in windows should use a 
> single backslash. Even though in some cases windows ignores double slashes in 
> paths and it might work but it isn't documented as a right naming convention 
> and does fail in some cases eg. dir command cannot interpret double slashes 
> and fails.
>
> For example if my SDK is located in D: drive, the environment setup scripts 
> sets "SDKROOT=D:\" and hence SDKTARGETSYSROOT gets set as 
> "SDKTARGETSYSROOT=D:\\sysroots\armv8a-oe-linux"
> The introduced check removes additional slash in SDKROOT to set it as 
> "SDKROOT=D:" so all other variables using SDKROOT get set without additional 
> slash.
>
> Signed-off-by: Muhammad Hamza 
> ---
>  classes/toolchain-scripts-mingw32.bbclass | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/classes/toolchain-scripts-mingw32.bbclass 
> b/classes/toolchain-scripts-mingw32.bbclass
> index d96cb40..8cb426a 100644
> --- a/classes/toolchain-scripts-mingw32.bbclass
> +++ b/classes/toolchain-scripts-mingw32.bbclass
> @@ -12,6 +12,7 @@ toolchain_create_sdk_env_script:sdkmingw32 () {
> touch $script
> # Be sure to use the 'short' path, so we can have deeper directories.
> echo 'set SDKROOT=%~sdp0%' >> $script
> +   echo 'IF %SDKROOT:~-1%==\ set SDKROOT=%SDKROOT:~0,-1%' >> $script
>
> # Convert to mingw32 subpaths
> sysroot='%SDKROOT%'${sysroot##${SDKPATH}}
> --
> 2.25.1
>

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

Re: [yocto] [meta-mingw] Branch for langdale?

[Joshua Watt]

Ya, I'll push one now

On Wed, Oct 26, 2022 at 2:17 PM Mark Hatle
 wrote:
>
> Doesn't look like langdale has been branched in meta-mingw.  Is it in a state
> where it can be branched?
>
> (I tried master and it seems to work for my use-case.)
>
> --Mark
>
> 
>

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

[yocto][meta-mingw][PATCH] Switch to HOSTTOOLS_NONFATAL

[Joshua Watt]

The changes to split classes into global vs. image specific contexts
has broken the inclusion of `wine` and `wineserver` host tools for
testing MinGW SDKs. This is because testsdk is an image specific class
and therefore it's inclusion is not detected globally and the wine host
tools are not present so the SDK tests fail.

Resolve this by using HOSTTOOLS_NONFATAL which will include the tools if
they exist, but won't fail if they are not present. This does mean that
users will now not know they need wine "up front" when doing a build,
but it will instead fail later when they actually try to test the SDK,
but there isn't really a better way to fix this.

Signed-off-by: Joshua Watt 
---
 conf/machine-sdk/include/mingw32-common.inc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/conf/machine-sdk/include/mingw32-common.inc 
b/conf/machine-sdk/include/mingw32-common.inc
index 966c63b..07b5b8f 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -50,5 +50,4 @@ DISABLE_STATIC:mingw32 = ""
 GCCPIE:mingw32 = ""
 
 # wine and wineserver are required to test MinGW SDKs
-HOSTTOOLS += "${@'wine wineserver' if (bb.utils.contains_any('IMAGE_CLASSES', 
'testsdk', True, False, d) or any(x in (d.getVar("BBINCLUDED") or "") for x in 
["testsdk.bbclass"])) else ''}"
-
+HOSTTOOLS_NONFATAL += "wine wineserver"
-- 
2.33.0


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

Re: [yocto] BBClass function and symbolic link (symlink) ... I throw in the towel #python #bitbake #kirkstone

[Joshua Watt]

On Tue, Aug 2, 2022 at 10:02 AM Martin Leduc  wrote:
>
> Hi Joshua,
>
> I've founded a second function, in the same class, using ln -s
>
> set_log_folder () {
> bbplain "Set var log folder BEGIN"
> rm -Rf ${IMAGE_ROOTFS}/var/log
> ln -s /mnt/general_data/log/ ${IMAGE_ROOTFS}/var/log
> bbplain "Set var log folder END"
> }
>
> The logs show "Set var log folder BEGIN" and "Set var log folder END" and no 
> issues 

Your set version function looks like it's running from the logs, so
don't think your function is directly causing a problem. My guess is
something else later is crashing or something else unrelated?

>
> What the hell I'm doing wrong
>
>
> Martin Leduc
> T : (418) 856-6896
> martin.le...@luminator.com
>
>
> -Message d'origine-
> De : yocto@lists.yoctoproject.org  De la part 
> de Martin Leduc via lists.yoctoproject.org
> Envoyé : 2 août 2022 10:20
> À : Joshua Watt 
> Cc : yocto@lists.yoctoproject.org
> Objet : Re: [yocto] BBClass function and symbolic link (symlink) ... I throw 
> in the towel #python #bitbake #kirkstone
>
> Hi Joshua,
>
> Thank you for your quick reply.
>
> Please see the crash log in the attachment.
>
> "Also, I'm not quite clear what you mean by "works like a charm with 
> Warrior"; it sounds like something still isn't working in Warrior that you 
> need, or just in Kirkstone?"
> This bbclass is imported from a previous build make using the Yocto Warrior 
> version and the build report no failure using "ln -s" directly, well it 
> compile.
>
> BR,
>
> -Message d'origine-
> De : Joshua Watt  Envoyé : 2 août 2022 09:57 À : Martin 
> Leduc  Cc : yocto@lists.yoctoproject.org Objet : 
> [EXTERNAL] Re: [yocto] BBClass function and symbolic link (symlink) ... I 
> throw in the towel #python #bitbake #kirkstone
>
> CAUTION: This email originated from outside of Luminator Technology Group. Do 
> not click links or open attachments unless you recognize the sender and know 
> the content is safe.
>
> On Tue, Aug 2, 2022 at 8:44 AM Martin Leduc via lists.yoctoproject.org 
>  wrote:
> >
> > Hi team,
> >
> > Well, I throw in the towel.  But it's looks like so simple  for me 藍藍.
> >
> > I've a function to replace the version file in /etc/version.  This function 
> > is integrated into my mybase-image.bbclass, defined in my layer and I add, 
> > in my core-image-minimal.bbappend recipe inherit mybase-image.bbclass.
> >
> > In my bbclass, I call my function using
> >
> > ROOTFS_POSTPROCESS_COMMAND += " \
> > set_version_file ; \
> > "
> >
> > My function is written like this
> > set_version_file() {
> > bbplain "set_version_file BEGIN"
> > mkdir -p ${IMAGE_ROOTFS}/etc/tmp/
> > echo ${PV} > ${IMAGE_ROOTFS}/etc/tmp/version
> > chmod 644 ${IMAGE_ROOTFS}/etc/tmp/version
> > rm ${IMAGE_ROOTFS}/etc/version
> > ln -sf /etc/tmp/version "${IMAGE_ROOTFS}/etc/version"
> > }
> > Note: /etc/tmp is just for the purpose of this test
> >
> > I mean, I don't try to do anything outstanding but the ln -sf line makes my 
> > compilation crash BUT it works like a charm with Warrior but Kirkstone 
> > rejects "ln -sf" command.
>
> Can you provide a little more detail about how it crashes? Also, I'm not 
> quite clear what you mean by "works like a charm with Warrior"; it sounds 
> like something still isn't working in Warrior that you need, or just in 
> Kirkstone?
>
> >
> > I'm definitely not the only one who adds symlinks to the recipes
> >
> > I've also tried:
> >
> > lnr
> > inherit relative_symlinks (don't have any impact but I've given it a
> > try), from the poky folder I've tried grep -r "ln" ./* | grep bbclass
> > (to validate the syntax) Read many posts on this topic
> >
> >
> > I'm unable to find where is my issue.
> >
> > Any ideas are welcome, even if it works like a charm on Warrior but not in 
> > Kirkstone.
> >
> > BR,
> > Martin
> >
> >

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

Re: [yocto] BBClass function and symbolic link (symlink) ... I throw in the towel #python #bitbake #kirkstone

[Joshua Watt]

On Tue, Aug 2, 2022 at 8:44 AM Martin Leduc via lists.yoctoproject.org
 wrote:
>
> Hi team,
>
> Well, I throw in the towel.  But it's looks like so simple  for me 藍藍.
>
> I've a function to replace the version file in /etc/version.  This function 
> is integrated into my mybase-image.bbclass, defined in my layer and I add, in 
> my core-image-minimal.bbappend recipe inherit mybase-image.bbclass.
>
> In my bbclass, I call my function using
>
> ROOTFS_POSTPROCESS_COMMAND += " \
> set_version_file ; \
> "
>
> My function is written like this
> set_version_file() {
> bbplain "set_version_file BEGIN"
> mkdir -p ${IMAGE_ROOTFS}/etc/tmp/
> echo ${PV} > ${IMAGE_ROOTFS}/etc/tmp/version
> chmod 644 ${IMAGE_ROOTFS}/etc/tmp/version
> rm ${IMAGE_ROOTFS}/etc/version
> ln -sf /etc/tmp/version "${IMAGE_ROOTFS}/etc/version"
> }
> Note: /etc/tmp is just for the purpose of this test
>
> I mean, I don't try to do anything outstanding but the ln -sf line makes my 
> compilation crash BUT it works like a charm with Warrior but Kirkstone 
> rejects "ln -sf" command.

Can you provide a little more detail about how it crashes? Also, I'm
not quite clear what you mean by "works like a charm with Warrior"; it
sounds like something still isn't working in Warrior that you need, or
just in Kirkstone?

>
> I'm definitely not the only one who adds symlinks to the recipes
>
> I've also tried:
>
> lnr
> inherit relative_symlinks (don't have any impact but I've given it a try),
> from the poky folder I've tried grep -r "ln" ./* | grep bbclass (to validate 
> the syntax)
> Read many posts on this topic
>
>
> I'm unable to find where is my issue.
>
> Any ideas are welcome, even if it works like a charm on Warrior but not in 
> Kirkstone.
>
> BR,
> Martin
> 
>

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

Re: [yocto] [meta-zephyr] meets create-spdx

[Joshua Watt]

On Fri, Jul 1, 2022 at 2:14 AM Marta Rybczynska  wrote:
>
> Hello all,
> We're trying to use create-spdx.bbclass with meta-zephyr. However,
> this is failing with errors like the one at the bottom of the message.
> While digging deeper, it is hard to reproduce reliably (but happens at
> different recipes and frequently enough to have it at every build).
> The workaround that works is to add:
> do_create_spdx[nostamp] = "1"
> which isn't great.
>
> Has anyone tried create-spdx.bbclass with meta-zephyr? Any insight?
>
> Kind regards,
> Marta
>
> And an example error message:
>
> ERROR: python3-native-3.10.4-r0 do_create_spdx: Error executing a
> python function in exec_func_python() autogenerated:
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_func_python() autogenerated', lineno: 2, function: 
> 0001:
> *** 0002:do_create_spdx(d)
> 0003:
> File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/classes/create-spdx.bbclass',
> lineno: 516, function: do_create_spdx
> 0512:
> 0513: if archive is not None:
> 0514: recipe.packageFileName = str(recipe_archive.name)
> 0515:
> *** 0516: dep_recipes = collect_dep_recipes(d, doc, recipe)
> 0517:
> 0518: doc_sha1 = oe.sbom.write_doc(d, doc, "recipes")
> 0519: dep_recipes.append(oe.sbom.DepRecipe(doc, doc_sha1, recipe))
> 0520:
> File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/classes/create-spdx.bbclass',
> lineno: 345, function: collect_dep_recipes
> 0341: ))
> 0342: for dep_pn in deps:
> 0343: dep_recipe_path = deploy_dir_spdx / "recipes" /
> ("recipe-%s.spdx.json" % dep_pn)
> 0344:
> *** 0345: spdx_dep_doc, spdx_dep_sha1 = oe.sbom.read_doc(dep_recipe_path)
> 0346:
> 0347: for pkg in spdx_dep_doc.packages:
> 0348: if pkg.name == dep_pn:
> 0349: spdx_dep_recipe = pkg
> File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/lib/oe/sbom.py', lineno:
> 67, function: read_doc
> 0063: else:
> 0064: with fn.open("rb") as f:
> 0065: yield f
> 0066:
> *** 0067: with get_file() as f:
> 0068: sha1 = hashlib.sha1()
> 0069: while True:
> 0070: chunk = f.read(4096)
> 0071: if not chunk:
> File: '/usr/lib/python3.8/contextlib.py', lineno: 113, function: __enter__
> 0109: # do not keep args and kwds alive unnecessarily
> 0110: # they are only needed for recreation, which is not possible anymore
> 0111: del self.args, self.kwds, self.func
> 0112: try:
> *** 0113: return next(self.gen)
> 0114: except StopIteration:
> 0115: raise RuntimeError("generator didn't yield") from None
> 0116:
> 0117: def __exit__(self, type, value, traceback):
> File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/lib/oe/sbom.py', lineno:
> 64, function: get_file
> 0060: def get_file():
> 0061: if isinstance(fn, io.IOBase):
> 0062: yield fn
> 0063: else:
> *** 0064: with fn.open("rb") as f:
> 0065: yield f
> 0066:
> 0067: with get_file() as f:
> 0068: sha1 = hashlib.sha1()
> File: '/usr/lib/python3.8/pathlib.py', lineno: 1222, function: open
> 1218: the built-in open() function does.
> 1219: """
> 1220: if self._closed:
> 1221: self._raise_closed()
> *** 1222: return io.open(self, mode, buffering, encoding, errors, newline,
> 1223: opener=self._opener)
> 1224:
> 1225: def read_bytes(self):
> 1226: """
> File: '/usr/lib/python3.8/pathlib.py', lineno: 1078, function: _opener
> 1074: raise ValueError("I/O operation on closed path")
> 1075:
> 1076: def _opener(self, name, flags, mode=0o666):
> 1077: # A stub for the opener argument to built-in open()
> *** 1078: return self._accessor.open(self, flags, mode)
> 1079:
> 1080: def _raw_open(self, flags, mode=0o777):
> 1081: """
> 1082: Open the file pointed by this path and return a file descriptor,
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/tmp/workspace.yd5o77EYlf/build/tmp-newlib/deploy/spdx/qemu-cortex-m3/recipes/recipe-gnu-config-native.spdx.json'

This appears to be the actual error: python3:do_create_spdx can't find
the recipe-gnu-config-native.spdx.json. I'm not sure why that would be
the case though; do_create_spdx for gnu-config-native should always
run before do_create_spdx for python3 since it's a deptask

> ERROR: Logfile of failure stored in:
> /tmp/workspace.yd5o77EYlf/build/tmp-newlib/work/x86_64-linux/python3-native/3.10.4-r0/temp/log.do_create_spdx.12842
> NOTE: recipe python3-native-3.10.4-r0: task do_create_spdx: Failed
> ERROR: Task 
> (virtual:native:/tmp/workspace.yd5o77EYlf/oe-core/meta/recipes-devtools/python/python3_3.10.4.bb:do_create_spdx)
> failed with exit code '1'

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

Re: [yocto] Yocto Windows SDK with meta-qt6

[Joshua Watt]

CC'd the mailing list


On 6/28/22 01:27, Rasool, Ansar wrote:


Hi,

I am trying to create a Kit in Qt Creator 7.0.2 from an SDK generated 
for x86_64 arch with mingw support (meta-mingw) for Windows Host. Upon 
adding qmake.exe file and compilers (C/C++), Kit throws error of "The 
Compiler GCC cannot produce code for Qt Version". However, the ABIs 
set in both GCC and Qt versions are same and compatible. Screenshot is 
attached below.


Upon investigating, i found out that the gcc compiler 
/x86_64-oe-linux-gcc.exe /doesn't work on cmdline. It throws error of 
missing libwinpthread-1.dll library which is actually present there 
but seems like the compiler binary is wrongly placed by meta-mingw 
layer. Currently, the locations of library and compiler binary is as 
below:



/sysroot/x86_64-mingw32/usr/bin/libwinpthread-1.dll
/sysroot/x86_64-mingw32/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gcc.exe

This setup throws error. But if I copy the libwinpthread-1.dll library 
onto the same directory where the compiler binary is present, it works 
fine. Which means that, somehow the compiler is expecting the dll to 
be loaded from current working directory whereas it is present in its 
parent directory. So, the SDK paths needs to be fixed.



Can you check if it works without any additional layers? Also would it 
be possible to get your local.conf?





Kindly input what could be the proper fix for it.


Regards,
Ansar Rasool

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

Re: [yocto] meta-egl failure: Nothing RPROVIDES polkit

[Joshua Watt]

On Tue, May 31, 2022 at 7:27 AM  wrote:
>
> On Sat, 2022-05-28 at 07:40 +0300, Marius Vlad wrote:
> > On Fri, May 27, 2022 at 04:25:00PM -0400, Scott Murray wrote:
> > > On Fri, 27 May 2022, Tim Orling wrote:
> > >
> > > > On Fri, May 27, 2022 at 9:18 AM Jan Simon Moeller <
> > > > jsmoel...@linuxfoundation.org> wrote:
> > > >
> > > > > Hi !
> > > > >
> > > > > Yes, we need to look into this and likely change the location of the
> > > > > RDEPENDS.
> > > > > Thanks for flagging.
> > > > >
> > > > > polkit needs to be in DISTRO_FEATURES and the recipe needs to have a 
> > > > > check
> > > > for that (and inherit features_check)
> > > [snip]
> > >
> > > For an immediate fix I've moved the polkit addition to a bbappend added
> > > via BBFILES_DYNAMIC, gated on meta-oe presence.  The current intent is
> > > that the meta-agl-core test on the autobuilder only need poky, so letting
> > > this slip in was a thinko on our part.  We may revisit making meta-oe a
> > > required dependency when binary packagefeed prototyping starts in AGL.
> > > Your comment re features_check is right on, I'll add that when I get a
> > > chance over the weekend.  One thing I may bring up on the next dev call
> > > is Weston does need polkit in some situations (hence the addition in
> > > AGL), so maybe shifting it to oe-core starts to make more sense now...
> > Yes, when using the logind launcher, or the seatd launcher with the
> > logind back-end, polkit is needed to activate the session.  There's no
> > more a direct launcher, weston-launch has been removed and upstream weston
> > can for some time now use systemd user sessions to starting-up.
> >
> > The seatd launcher with daemon or built-in back-end, appears to be doing
> > the activation on its own, but I reckon systemd-logind back-end will be
> > the de-facto back-end if changing the launcher in weston to seatd, and
> > removing systemd-logind launcher (as we're currently working towards
> > having just a single launcher).
> >
> > One thing to mention here is that while digging this up I've found a
> > patch to systemd-logind [1] which supposedely should allow just logind
> > to activate the session as a non-root user, just that either it wasn't
> > working or it is no longer present, as I haven't been able to activate
> > sessions without polkit installed.
> >
> > [1] 
> > https://github.com/openembedded/openembedded-core/commit/e42dd9cff98f2149904e104f08bc3f19ee7b6fc0
> >
>
> Adding Joshua, I'm hoping he might have some ideas here?

That patch in question fixed a regression in systemd behavior that was
introduced at some point that broke the non-polkit behavior. I was
able to get it fixed, but I also suspect that fighting against using
polkit isn't going to be productive in the long run and we should look
at a way to pull it in. preferably without needing mozjs (why a
policy system decided to rely on javascript is beyond me). Eventually,
we are going to want polkit-only features from systemd and there won't
be grounds (like "This worked before polkit") to get upstream systemd
to change to support it.

>
> Cheers,
>
> Richard
>

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

Re: [yocto] Honister on Ubuntu 14.04

[Joshua Watt]

On 3/3/22 12:06, Daniel Ammann wrote:

Hi,

I'm trying to build honister on Ubuntu 14.04. This is meant as a 
temporary

solution until the build server can be upgraded to something recent.
For now, I got it running with extended buildtools from poky, but the 
build of

libnsl2-native fails. It appears that the pkgconfig step is not executed
properly since do_compile fails with a header not found error.

Has anybody done a successful build of honister on Ubuntu 14.04? Is it 
even

possible?


You might be better off trying to use a container to build, but with a 
host that old, even that might be hard. There are several container 
solutions for the project, including:


* crops - https://github.com/crops/poky-container

* pyrex - https://github.com/garmin/pyrex

* kas - https://github.com/siemens/kas



Kind regards

Daniel





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

Re: [yocto] QA change - reduced number of reproducibility builds tests?

[Joshua Watt]

On Fri, Feb 25, 2022 at 12:50 PM Steve Sakoman  wrote:
>
> On Fri, Feb 25, 2022 at 8:09 AM Richard Purdie
>  wrote:
> >
> > Hi All,
> >
> > As the project develops, some tests are valuable and some become less 
> > valuable
> > over time.
> >
> > When we first started reproducible builds work, testing reproducibility 
> > heavily
> > across multiple distros highlighted some unusual bugs and let us improve 
> > things.
> > We therefore currently run a-full with the targets:
> >
> > reproducibile-centos
> > reproducibile-debian
> > reproducibile-fedora
> > reproducibile-ubuntu
> >
> > I've noticed we pretty much always see the same set of failures with these
> > targets now, i.e. if one fails, they all fail the same way.
> >
> > Those targets are heavy builds which don't reuse sstate for one of the build
> > streams and hence load the autobuilder heavily.
> >
> > I'm thinking they've served their purpose and that a-full should go back to 
> > just
> > the randomly selected reproduiclbe target.
> >
> > Does anyone feel we shouldn't do that?
>
> I support this.  It has been quite some time since dunfell encountered
> a distro specific reproducibility issue.

I agree. I assume the change is simple enough to make that we can
bring them back easily if we think it might be helpful is some
scenario?

Also, just to clarify, those workers will still contribute to the
initial sstate, so they will still help find cross-host reproducible
problems, they just might not find it themselves?

>
> Steve

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

Re: [yocto] Minutes: Yocto Project Weekly Triage Meeting 1/6/2022

[Joshua Watt]

On Thu, Jan 6, 2022 at 10:22 AM Trevor Gamblin
 wrote:
>
> Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage
>
> Attendees: Alexandre, Joshua, Michael, Randy, Richard, Saul, Stephen, Steve, 
> Tim, Trevor
>
> ARs:
>
> - Joshua to send a patch limiting the size of diffoscope output for 
> reproducibility

Merged as 52d5f76f54eac384f9480dffe96df089d9ee8f33 in OE-core

>
> Notes:
>
> N/A
>
> Medium+ 3.5 Unassigned Enhancements/Bugs: 75 (Last week 75)
>
> Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (Last week 38)
>
> AB Bugs: 66 (Last week 70)

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

Re: [yocto] Red alert but apparently harmless setscene errors

[Joshua Watt]

On Thu, Jan 13, 2022 at 11:23 AM Michael Opdenacker
 wrote:
>
> Hi,
>
> Sharing this before opening a bug if needed...
>
> I'm building the latest Poky ("core-image-minimal" plus a few extra
> packages).
>
> I'm always getting the below setscene errors after upgrading my Poky
> sources:
>
> ... 
> WARNING: libffi-native-3.4.2-r0 do_populate_sysroot_setscene: Failed to
> fetch URL
> file://universal/c8/be/sstate:libffi-native:x86_64-linux:3.4.2:r0:x86_64:7:c8be7b784ce8ebbf6d897367bc8e96f6718040858d61f9a4f6aa5325821b0ce5_populate_sysroot.tar.zst.siginfo;downloadfilename=universal/c8/be/sstate:libffi-native:x86_64-linux:3.4.2:r0:x86_64:7:c8be7b784ce8ebbf6d897367bc8e96f6718040858d61f9a4f6aa5325821b0ce5_populate_sysroot.tar.zst.siginfo,
> attempting MIRRORS if available
> ERROR: libffi-native-3.4.2-r0 do_populate_sysroot_setscene: Fetcher
> failure: Unable to find file
> file://universal/c8/be/sstate:libffi-native:x86_64-linux:3.4.2:r0:x86_64:7:c8be7b784ce8ebbf6d897367bc8e96f6718040858d61f9a4f6aa5325821b0ce5_populate_sysroot.tar.zst.siginfo;downloadfilename=universal/c8/be/sstate:libffi-native:x86_64-linux:3.4.2:r0:x86_64:7:c8be7b784ce8ebbf6d897367bc8e96f6718040858d61f9a4f6aa5325821b0ce5_populate_sysroot.tar.zst.siginfo
> anywhere. The paths that were searched were:
> /media/mike/ssd/yocto/poky/build/sstate-cache
> /media/mike/ssd/yocto/poky/build/sstate-cache
> WARNING: libpcre2-native-10.39-r0 do_populate_sysroot_setscene: Failed
> to fetch URL
> file://universal/bf/03/sstate:libpcre2-native:x86_64-linux:10.39:r0:x86_64:7:bf035286ff06470377fe9c9298ba116222c9d557f2fa44d418beb919aa185db9_populate_sysroot.tar.zst.siginfo;downloadfilename=universal/bf/03/sstate:libpcre2-native:x86_64-linux:10.39:r0:x86_64:7:bf035286ff06470377fe9c9298ba116222c9d557f2fa44d418beb919aa185db9_populate_sysroot.tar.zst.siginfo,
> attempting MIRRORS if available
> ERROR: libpcre2-native-10.39-r0 do_populate_sysroot_setscene: Fetcher
> failure: Unable to find file
> file://universal/bf/03/sstate:libpcre2-native:x86_64-linux:10.39:r0:x86_64:7:bf035286ff06470377fe9c9298ba116222c9d557f2fa44d418beb919aa185db9_populate_sysroot.tar.zst.siginfo;downloadfilename=universal/bf/03/sstate:libpcre2-native:x86_64-linux:10.39:r0:x86_64:7:bf035286ff06470377fe9c9298ba116222c9d557f2fa44d418beb919aa185db9_populate_sysroot.tar.zst.siginfo
> anywhere. The paths that were searched were:
> /media/mike/ssd/yocto/poky/build/sstate-cache
> /media/mike/ssd/yocto/poky/build/sstate-cache
> ERROR: libpcre2-native-10.39-r0 do_populate_sysroot_setscene: No
> suitable staging package found
> ERROR: Logfile of failure stored in:
> /media/mike/ssd/yocto/poky/build/tmp/work/x86_64-linux/libpcre2-native/10.39-r0/temp/log.do_populate_sysroot_setscene.315121
> WARNING: Setscene task
> (virtual:native:/media/mike/ssd/yocto/poky/meta/recipes-support/libpcre/libpcre2_10.39.bb:do_populate_sysroot_setscene)
> failed with exit code '1' - real task will be run instead
> Currently  4 running tasks (1838 of 1838/467 of 4630)  10%
> |
>
> As expected, the error messages are highlighted in red, but they are not
> critical as BitBake can always build the corresponding recipes from sources.
>
> Two questions:
>
>   * Anything wrong with my local sstate cache? Should I erase it?

This usually happens when there is a sstate archive (.tar.zst), but no
corresponding siginfo file (.tar.zst.siginfo). The sstate code assumes
the siginfo file is present if archive is present, and "errors" if
not. In my experience, this usually happens when you try to clean out
the sstate cache using a mechanism that is unaware of the relationship
and deletes the siginfo and not the archive (e.g. some form of "find
-delete ...")

>   * Should these issues really be treated as errors, scaring users that
> something could be wrong while the resulting build looks correct anyway?

As noted by the build, it will actually just execute the missing
tasks; one annoyance (depending on context) is that bitbake will
return a non-zero exit code if any ERROR occurs in the build, even
though in this case it was recovered.

This has been discussed at length before (I can't find a citation
ATM), and I believe it was left this way because this particular case
is considered an actual error that should never happen and needs
investigation on the YP Autobuilder.

>
> Thanks in advance
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
> 
>

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

[yocto] Reproducible build website broken (CORS setting on git.yoctoproject.org?)

[Joshua Watt]

Michael,

I noticed that the
https://www.yoctoproject.org/reproducible-build-results/ website went
down (it always shows "Error fetching test results"). I did a little
debugging and I think that the CORS setting on git.yoctoproject.org is
not allowing www.yoctoproject.org to request the data anymore. I
thought we had fixed this at one point in the past and maybe it got
lost somewhere along the way?

If that's something we can fix, that would be great, otherwise we
might need to look into another solution for fetching the
reproducibility data.

Thanks,
Joshua Watt

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

Re: [yocto] spdx: Extending SPDX SBOMs for SDKs

[Joshua Watt]

On Wed, Dec 15, 2021 at 3:33 PM Andres Beltran
 wrote:
>
> + Joshua, Saul
>
> On 12/6/2021 6:54 PM, Andres Beltran wrote:
>
> Hello,
>
>
> I've been working on extending SPDX SBOMs for SDKs. In 
> poky/meta/classes/create-spdx.bbclass I added:
>
>
>
> do_populate_sdk[recrdeptask] += "do_create_spdx do_create_runtime_spdx"
>
>
>
> I ran into a dependency loop when I try to build an SDK that contains 
> nativesdk-clang (it works fine for other SDKs):
>
>
>
> ERROR:
>
> Dependency loop #1 found:
>
> Task 
> mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang-crosssdk_git.bb:do_create_spdx
>  (dependent Tasks ['glibc_2.31.bb:do_create_spdx', 
> 'binutils-crosssdk_2.34.bb:do_create_spdx', 'clang_git.bb:do_create_spdx', 
> 'quilt-native_0.66.bb:do_populate_sysroot', 
> 'nativesdk-clang-glue.bb:do_create_spdx'])
>
>
>
> Task 
> mc:lnx-sdk:virtual:nativesdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang_git.bb:do_create_spdx
>  (dependent Tasks ['clang_git.bb:do_packagedata', 
> 'cmake-native_3.16.5.bb:do_create_spdx', 'swig_3.0.12.bb:do_create_spdx', 
> 'libedit_20191231-3.1.bb:do_create_spdx', 
> 'binutils-crosssdk_2.34.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 
> 'libffi_3.3.bb:do_create_spdx', 'clang-crosssdk_git.bb:do_create_spdx', 
> 'zlib_1.2.11.bb:do_create_spdx', 'clang_git.bb:do_package', 
> 'python3_3.8.2.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 
> 'python3_3.8.2.bb:do_create_spdx', 'pkgconfig_git.bb:do_create_spdx', 
> 'binutils_2.34.bb:do_create_spdx', 
> 'quilt-native_0.66.bb:do_populate_sysroot', 
> 'libedit_20191231-3.1.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 
> 'ninja_1.10.0.bb:do_create_spdx'])
>
>
>
> Task 
> mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/nativesdk-clang-glue.bb:do_create_spdx
>  (dependent Tasks ['gcc-runtime_9.3.bb:do_create_spdx', 
> 'glibc_2.31.bb:do_create_spdx', 'nativesdk-clang-glue.bb:do_package', 
> 'gcc-crosssdk_9.3.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 
> 'quilt-native_0.66.bb:do_populate_sysroot', 
> 'nativesdk-clang-glue.bb:do_packagedata', 'clang_git.bb:do_create_spdx'])

Looks like the loop is:
  nativesdk-clang-glue.bb:do_create_spdx ->
clang_git.bb:do_create_spdx -> clang-crosssdk_git.bb:do_create_spdx ->
nativesdk-clang-glue.bb:do_create_spdx

I don't know enough about the clang recipes to be able to help you
much beyond that however

>
>
>
> Any help on this would be appreciated.
>
>
>
> Thanks,
>
> Andres Beltran
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55598): https://lists.yoctoproject.org/g/yocto/message/55598
Mute This Topic: https://lists.yoctoproject.org/mt/87554396/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] grpc: use the new PACKAGECONFIG to disable shared

[Joshua Watt]

On 8/24/21 11:48 AM, Sinan Kaya wrote:

There is a new PACKAGECONFIG for grpc to allows us
to selectively enable/disable shared builds.

Signed-off-by: Sinan Kaya 
---
  .../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend  | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git 
a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend 
b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
index dc0ea42..4cbd1a4 100644
--- a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
+++ b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
@@ -1,5 +1,4 @@
  # doesn't build and not required
  DEPENDS:remove:mingw32 = "libnsl2"
  
-EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"

-EXTRA_OECMAKE:append:mingw32 = " -DBUILD_SHARED_LIBS=OFF"
+PACKAGECONFIG:remove:mingw32 = "shared"


This is good, thanks. Is the libnsl2 also tied to some feature? Perhaps 
you can explain why it needs to be removed from MinGW




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54580): https://lists.yoctoproject.org/g/yocto/message/54580
Mute This Topic: https://lists.yoctoproject.org/mt/85115270/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] grpc: remove nl2 requirement since it is optional

[Joshua Watt]

On Sat, Aug 21, 2021, 6:26 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Fri, 2021-08-20 at 20:46 +, Sinan Kaya wrote:
> > Signed-off-by: Sinan Kaya 
> > ---
> >  .../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend  | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git
> a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
> b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
> > index a72496d..dc0ea42 100644
> > ---
> a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
> > +++
> b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
> > @@ -1,2 +1,5 @@
> > +# doesn't build and not required
> > +DEPENDS:remove:mingw32 = "libnsl2"
> > +
> >  EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"
> >  EXTRA_OECMAKE:append:mingw32 = " -DBUILD_SHARED_LIBS=OFF"
>
> Should we be making that a PACKAGECONFIG which mingw32 could change?
>

Yes, that's a good idea. Sinan, please make that change in meta-oe, then
change this patch to remove it from PACKAGECONFIG


> Cheers,
>
> Richard
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54528): https://lists.yoctoproject.org/g/yocto/message/54528
Mute This Topic: https://lists.yoctoproject.org/mt/85030549/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

[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

[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 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]
-=-=-=-=-=-=-=-=-=-=-=-

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 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw] [PATCH] binutils: Package static libdep linker plugins

[Joshua Watt]

On 8/13/21 2:05 AM, Samuli Piippo wrote:

ping.

I'm still seeing problem with this on hardknott, at least when 
building for qemux86 target:

agent:2021/08/13 06:00:50 build.go:391: ERROR: 
binutils-cross-canadian-i686-2.36.1-r0 do_package_qa: QA Issue: non -staticdev 
package contains static .a library: binutils-cross-canadian-i686 path 
'/opt/poky/3.3.2/sysroots/x86_64-w64-mingw32/usr/lib/i686-poky-linux/bfd-plugins/libdep.dll.a'
agent:2021/08/13 06:00:50 build.go:391: non -staticdev package contains static 
.a library: binutils-cross-canadian-i686 path 
'/opt/poky/3.3.2/sysroots/x86_64-w64-mingw32/usr/lib/i686-poky-linux/bfd-plugins/libdep.dll.a'
 [staticdev]
agent:2021/08/13 06:00:50 build.go:391: ERROR: 
binutils-cross-canadian-i686-2.36.1-r0 do_package_qa: QA run found fatal 
errors. Please consider fixing them.


Hmm, I'm not sure why I missed this. However, why is the MinGW build 
producing the .a files and not all the builds? It seems like this could 
go in the oe-core version of the recipe (w/o the override) instead of 
the bbappend?




On Tue, 16 Feb 2021 at 11:07, Samuli Piippo via lists.yoctoproject.org 
 
> wrote:


this is new plugin added in binutils 2.36

Signed-off-by: Samuli Piippo mailto:samuli.pii...@qt.io>>
---
 recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend | 2 ++
 1 file changed, 2 insertions(+)

diff --git
a/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
b/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
index 5845fe0..0d376bb 100644
--- a/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
+++ b/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
@@ -3,3 +3,5 @@ LDFLAGS_append_sdkmingw32 = " -Wl,-static"

 DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
 DEPENDS_remove_sdkmingw32 = "nativesdk-flex"
+
+FILES_${PN}-staticdev_append_sdkmingw32 = "
${libdir}/bfd-plugins/lib*.a"
-- 
2.17.1






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

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

[Joshua Watt]

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


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

Hi All,

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

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

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

How to pass arguments to the shell function ?

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


Thanks,
Talel




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

Re: [yocto] [meta-mingw][PATCH] openssl: support for building nativesdk of mingw

[Joshua Watt]

On 1/4/21 9:31 PM, Changqing Li wrote:

* add support for mingw32
* Engines are installed in a slightly different path, which is
   urgly, patch it to make the path shorter
* remove runtime dependency from perl for mingw nativesdk

since commit 70da1f956bfbb627691c47eba7451182aca758e3 of oe-core
'openssl: Add c_rehash to misc package and add perl runtime dependency'

package openssl-misc have runtime dependency on perl, and perl then
have depenency on another 3 recipes, db/gdbm/libxcrypt. according to
http://arsv.github.io/perl-cross/usage.html, perl don't support
cross-compile build for mingw32 and another 3 recipes also don't
support mingw well. so remove the dependency of perl, don't support
c_rehash for mingw.



It would appear that some or all of this patch is unnecessary. OE-core 
166bb89f6d97495b6522786182b4f9623acd7ff4 implements part of this patch, 
which makes me think it's working there without any changes necessary. 
It would be worth following up to see if that is the case.





Signed-off-by: Changqing Li 
---
  ...ile.tmpl-don-t-add-prefix-for-libdir.patch | 32 +++
  .../openssl/openssl_%.bbappend| 31 ++
  2 files changed, 63 insertions(+)
  create mode 100644 
recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
  create mode 100644 recipes-connectivity/openssl/openssl_%.bbappend

diff --git 
a/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
 
b/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
new file mode 100644
index 000..028431b
--- /dev/null
+++ 
b/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
@@ -0,0 +1,32 @@
+From 8fe5c9421acfaff35b637e7ad55d1df598bb7081 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Tue, 22 Dec 2020 09:22:10 +0800
+Subject: [PATCH] unix-Makefile.tmpl: don't add prefix for libdir
+
+we had pass libdir to Configure, don't use prefix again to
+avoid engineer dir set to:
+/opt/poky/3.2+snapshot/sysroots/x86_64-w64-mingw32/usr/opt/poky/3.2+snapshot/sysroots/x86_64-w64-mingw32/usr/lib/engines-1_1
+
+Upstream-Status: Inappropriate[oe-specific]
+
+Signed-off-by: Changqing Li 
+---
+ Configurations/unix-Makefile.tmpl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Configurations/unix-Makefile.tmpl 
b/Configurations/unix-Makefile.tmpl
+index bbafb98..eecb63e 100644
+--- a/Configurations/unix-Makefile.tmpl
 b/Configurations/unix-Makefile.tmpl
+@@ -244,7 +244,7 @@ LIBDIR={- our $libdir = $config{libdir} || "lib";
+   File::Spec::Win32->file_name_is_absolute($libdir) ? "" : $libdir -}
+ ENGINESDIR_dev={- use File::Spec::Win32;
+   our $enginesdir =
+-  File::Spec::Win32->catdir($prefix,$libdir,
++  File::Spec::Win32->catdir($libdir,
+ "engines-$sover_dirname");
+   our ($enginesdir_dev, $enginesdir_dir, $enginesdir_file) =
+   File::Spec::Win32->splitpath($enginesdir, 1);
+--
+2.17.1
+
diff --git a/recipes-connectivity/openssl/openssl_%.bbappend 
b/recipes-connectivity/openssl/openssl_%.bbappend
new file mode 100644
index 000..7fd82f1
--- /dev/null
+++ b/recipes-connectivity/openssl/openssl_%.bbappend
@@ -0,0 +1,31 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+SRC_URI_append_mingw32_class-nativesdk = " \
+   file://0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch \
+"
+
+do_configure_mingw32 () {
+   os=${HOST_OS}
+   target="$os-${HOST_ARCH}"
+   case $target in
+mingw32-x86_64)
+target=mingw64
+;;
+mingw32-i686)
+target=mingw
+;;
+esac
+
+useprefix=${prefix}
+if [ "x$useprefix" = "x" ]; then
+useprefix=/
+fi
+# WARNING: do not set compiler/linker flags (-I/-D etc.) in 
EXTRA_OECONF, as they will fully replace the
+# environment variables set by bitbake. Adjust the environment 
variables instead.
+HASHBANGPERL="/usr/bin/env perl" PERL=perl 
PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
+perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} 
--prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target
+perl ${B}/configdata.pm --dump
+}
+
+FILES_${PN}-engines_mingw32_class-nativesdk = "${libdir}/engines-1_1"
+RDEPENDS_${PN}-misc_remove_mingw32_class-nativesdk = "perl"




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

Re: [yocto] Zuul - Project Gating System with Yocto Project

[Joshua Watt]

On 7/1/21 9:48 AM, Tomasz Dziendzielski wrote:

Hello,
is anyone here using Zuul along with Yocto Project? We are thinking 
about integrating Zuul to our project that already uses Yocto, but we 
are not too familiar with Zuul and we want it to conform to good open 
source practices, without losing any advantages of both projects and 
we want to avoid creating some hacky monster.
Could you share some suggestions on how it can be combined together 
and what is the best approach/structure to do this? Please also share 
if you have some "what I wish I'd known" about Zuul integration to 
Yocto. Any hints are appreciated.



I haven't, but it's on my radar to look at as it seems like it could be 
pretty useful. If you look into it, please share your findings!





Best regards,
Tomasz Dziendzielski




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

[yocto][meta-mingw][PATCH] Disable debuginfod

[Joshua Watt]

Disables debuginfod when using MingGW. This feature brings in
unbuildable dependencies and can't be used.

Signed-off-by: Joshua Watt 
---
 conf/machine-sdk/include/mingw32-common.inc| 2 ++
 recipes-devtools/gdb/gdb-cross-canadian_%.bbappend | 1 +
 2 files changed, 3 insertions(+)

diff --git a/conf/machine-sdk/include/mingw32-common.inc 
b/conf/machine-sdk/include/mingw32-common.inc
index 0109e75..3997a26 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -15,6 +15,8 @@ USE_NLS_mingw32 = "no"
 FILES_${PN}-staticdev_append_mingw32 = " ${libdir}/*.lib"
 ALLOW_EMPTY_${PN}_mingw32 = "1"
 
+DISTRO_FEATURES_FILTER_NATIVESDK_remove_mingw32 = "debuginfod"
+
 # Do what amounts to a NOOP
 SDK_PACKAGING_FUNC = "do_compile"
 
diff --git a/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend 
b/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
index c33a9ce..096fc63 100644
--- a/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
+++ b/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
@@ -4,3 +4,4 @@ RDEPENDS_${PN}_remove_sdkmingw32 = "nativesdk-python-core 
nativesdk-python-lang
 EXTRA_OECONF_append_sdkmingw32 = " --without-curses --without-system-readline 
--with-python=no"
 PACKAGECONFIG_remove_sdkmingw32 = "readline"
 PACKAGECONFIG_remove_sdkmingw32 = "python"
+PACKAGECONFIG_remove_sdkmingw32 = "debuginfod"
-- 
2.31.1


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

Re: [yocto] Making a recipe that enables a systemd service it doesn't provide

[Joshua Watt]

It might be easier to manually enable the service with a symbolic link 
instead of using systemd.bbclass with something like:


do_install() {

  install -Dm 755 ${D}${systemd_unitdir}/system/multi-user.target.wants/

  ln -s ${systemd_unitdir}/system/openvpn@.service 
${D}${systemd_unitdir}/system/multi-user.target.wants/openvpn@test.service


}

NOTE: I didn't explicitly test this

On 5/27/21 9:17 AM, François GOUDAL wrote:

Hello,

I am struggling with something I couldn’t find any solution for so far.

I am trying to make a very simple recipe that does this:
- Drop an openvpn configuration file in /etc/openvpn/test.conf
- Make the systemd service openvpn@test.service enabled by default

The recipe itself depends on openvpn, and so, it doesn’t, by itself, provide 
the openvpn@.service , which comes with openvpn.

Dropping the openvpn configuration file in the rootfs is easy, but I can’t 
manage to make the recipe to enable the service.
I’ve tried adding this to my recipe:

inherit systemd
SYSTEMD_AUTO_ENABLE = "enable"
SYSTEMD_SERVICE_${PN} = "openvpn@test.service"

But bitbake fails on this recipe with the message below:

ERROR: test-openvpn-config-1.0-r0 do_package: 
SYSTEMD_SERVICE_test-openvpn-config value openvpn@test.service does not exist

I believe this is caused by the fact that the service file is not part of the 
files installed by the recipe itself, but it is not meant to be anyway.

Is there a (clean) way to achieve this ?

Thanks in advance







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

[yocto][meta-mingw][PATCH] zstd: Fix MinGW builds

[Joshua Watt]

Fixes the MinGW builds for zstd

Signed-off-by: Joshua Watt 
---
 recipes-extended/zstd/zstd_%.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 recipes-extended/zstd/zstd_%.bbappend

diff --git a/recipes-extended/zstd/zstd_%.bbappend 
b/recipes-extended/zstd/zstd_%.bbappend
new file mode 100644
index 000..3b2b991
--- /dev/null
+++ b/recipes-extended/zstd/zstd_%.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OEMAKE_append_mingw32 = " OS=Windows"
+FILES_${PN}_append_mingw32 = " ${libdir}/*.dll"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53656): https://lists.yoctoproject.org/g/yocto/message/53656
Mute This Topic: https://lists.yoctoproject.org/mt/83102237/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] mingw-libgnurx: Add recipe

[Joshua Watt]

On 5/4/21 12:59 PM, Khem Raj wrote:

This implements glibc regex and will be used by many
packages e.g. flex, therefore add recipe

Signed-off-by: Khem Raj 
---
  ...onor-DESTDIR-variable-during-install.patch |  39 ++
  .../0002-Add-autotool-files.patch | 125 ++
  .../mingw-libgnurx/mingw-libgnurx_2.5.1.bb|  20 +++
  3 files changed, 184 insertions(+)
  create mode 100644 
recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
  create mode 100644 
recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
  create mode 100644 recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb

diff --git 
a/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
 
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
new file mode 100644
index 000..ea8d9ed
--- /dev/null
+++ 
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
@@ -0,0 +1,39 @@
+From a9b7e07a8ba9c390d9774daae769748a09d409ce Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sat, 1 May 2021 14:41:21 -0700
+Subject: [PATCH] Honor DESTDIR variable during install
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ Makefile.in | 14 +++---
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 6397bf1..8395d2f 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -78,16 +78,16 @@ gnurx.lib: libgnurx-$(DLLVERSION).dll
+ install: install-dll @install_dev@
+
+ install-dll:
+-  mkdir -p ${bindir}
+-  cp -p $(BINDIST_FILES) ${bindir}
++  mkdir -p $(DESTDIR)${bindir}
++  cp -p $(BINDIST_FILES) $(DESTDIR)${bindir}
+
+ install-dev:
+-  mkdir -p ${includedir} ${libdir}
+-  cp -p ${srcdir}/regex.h ${includedir}
+-  cp -p $(DEVDIST_FILES) ${libdir}
++  mkdir -p ${includedir} $(DESTDIR)${libdir}
++  cp -p ${srcdir}/regex.h $(DESTDIR)${includedir}
++  cp -p $(DEVDIST_FILES) $(DESTDIR)${libdir}
+   for s in 3 7; do \
+-mkdir -p ${mandir}/man$$s; \
+-gzip -c ${srcdir}/regex.$$s > ${mandir}/man$$s/regex.$$s.gz; \
++mkdir -p $(DESTDIR)${mandir}/man$$s; \
++gzip -c ${srcdir}/regex.$$s > 
$(DESTDIR)${mandir}/man$$s/regex.$$s.gz; \
+   done
+
+ dist:  bindist devdist srcdist
diff --git 
a/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch 
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
new file mode 100644
index 000..1365f24
--- /dev/null
+++ 
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
@@ -0,0 +1,125 @@
+From 0b74bbc32c4acf5b67d7568a5d1e776fe6578202 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sat, 1 May 2021 14:53:09 -0700
+Subject: [PATCH] Add autotool files
+
+This helps in reconfiguring the component with autotools on Linux
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ Makefile.am  |  7 
+ configure.ac | 90 ++--
+ 2 files changed, 16 insertions(+), 81 deletions(-)
+ create mode 100644 Makefile.am
+
+diff --git a/Makefile.am b/Makefile.am
+new file mode 100644
+index 000..be0a797
+--- /dev/null
 b/Makefile.am
+@@ -0,0 +1,7 @@
++lib_LTLIBRARIES = libgnurx.la
++
++libgnurx_la_SOURCES = regex.c
++libgnurx_la_includedir = $(includedir)
++libgnurx_la_include_HEADERS = regex.h
++libgnurx_la_CFLAGS = -I$(top_srcdir)
++libgnurx_la_LDFLAGS = -no-undefined -version-info 0:0:0 -export-dynamic
+diff --git a/configure.ac b/configure.ac
+index c97738d..de64f75 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1,83 +1,11 @@
+ # configure.ac  -*- Autoconf -*-
+ # Process this file with autoconf, to generate a configure script.
+-#
+-# $Id: configure.ac,v 1.2 2007/05/03 22:46:09 keithmarshall Exp $
+-#
+-# Copyright (C) 2007, MinGW Project
+-# Written by Keith Marshall 
+-#
+-# Package identification.
+-#
+-# This is configure.ac for the MinGW `libgnurx' package.
+-# BASENAME, VERSION_MAJOR and VERSION_MINOR are required tags;
+-# complete `Value' fields as appropriate.
+-#
+-#Tag  Value
+-#---  --
+-  MINGW_AC_DEFINE_PACKAGE_ID([BASENAME],  [libgnurx])
+-  MINGW_AC_DEFINE_PACKAGE_ID([VERSION_MAJOR], [2])
+-  MINGW_AC_DEFINE_PACKAGE_ID([VERSION_MINOR], [5])
+-#
+-# PATCHLEVEL is optional; comment/uncomment and adjust as required.
+-#
+-  MINGW_AC_DEFINE_PACKAGE_ID([PATCHLEVEL],[1])
+-#
+-# DLL_VERSION is required; installed DLLs will be versioned, by
+-# appending a hyphen, the specified tag value, and then the `.dll'
+-# file name extension, to the base name of each generated DLL.
+-#
+-  MINGW_AC_DEFINE_PACKAGE_ID([DLL_VERSION],   [0])
+-#
+-#
+-# libgnurx is an adaptation of Tor Lillqvist's original port of the
+-# regex functions from GNU libc, for use on native Woe32 

Re: [yocto] [meta-rockchip][PATCH v3 0/7] OP-TEE support for ARM and rk3399

[Joshua Watt]

On 4/23/21 11:58 AM, Yann Dirson wrote:

From: Yann Dirson 

Changes from v2:
  - turn the DISTRO_FEATURE idea into separate RFC patches so as to allow
merging of basic support
  - remove optee-os patch that proved unnecessary

Changes from v1:
  - fix last-minute typo in TFA_SPD setting, which led to optee not being 
started
  - use PACKAGECONFIG[optee] to simplify recipes as suggested on meta-arm ml

Yann Dirson (7):
   trusted-firmware-a: include optee support when requested by
 DISTRO_FEATURE
   u-boot: include optee-os as BL32 when requested by DISTRO_FEATURE
   optee-os: enable rk3399 support, including serial console support
   RFC optee: new "optee" DISTRO_FEATURE to enable optee-os integration
   RFC: optee: only enable the recipes when "optee" is included in
 DISTRO_FEATURES
   WIP nanopi-m4: declare OP-TEE presence in devicetree
   WIP kernel config feature for OP-TEE activation


In general, it seems like a lot of these changes should be in the 
upstream recipes, not the meta-rockchip bbappends.


Also, the things that do belong in this layer need proper variable 
overrides to keep the layer (mostly) Yocto project compliant.




  conf/machine/include/rk3399.inc   |  2 +
  .../trusted-firmware-a_%.bbappend | 14 +
  recipes-bsp/u-boot/u-boot%.bbappend   |  9 
  .../0001-nanopi-declare-optee-presence.patch  | 30 +++
  recipes-kernel/linux/files/bsp/tee.cfg|  2 +
  recipes-kernel/linux/linux-yocto%.bbappend|  1 +
  ...399-enable-serial-console-by-default.patch | 52 +++
  recipes-security/optee/optee%.bbappend|  4 ++
  recipes-security/optee/optee-os_%.bbappend|  8 +++
  9 files changed, 122 insertions(+)
  create mode 100644 
recipes-kernel/linux/files/0001-nanopi-declare-optee-presence.patch
  create mode 100644 recipes-kernel/linux/files/bsp/tee.cfg
  create mode 100644 
recipes-security/optee/files/0001-rk3399-enable-serial-console-by-default.patch
  create mode 100644 recipes-security/optee/optee%.bbappend
  create mode 100644 recipes-security/optee/optee-os_%.bbappend





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

Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

[Joshua Watt]

On 4/6/21 6:47 PM, Yann Dirson wrote:

From: Yann Dirson 

TF-A runs between two u-boot stages which both uses 150 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:

  [20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
  [20210406-175438.135956] Channel 0: DDR3, 933MHz
  [20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 
Size=1024MB
  [20210406-175438.237000] Channel 1: DDR3, 933MHz
  [20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 
Size=1024MB
  [20210406-175438.237008] 256B stride
  [20210406-175438.237012] Trying to boot from BOOTROM
  [20210406-175438.237015] Returning to boot ROM...
  [20210406-175438.237018]
  [20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +)
  [20210406-175438.573431] Trying to boot from MMC1

  [20210406-175438.589254] NOTICE:  BL31: v2.3():v2.3-dirty
  [20210406-175440.534055] NOTICE:  BL31: Built : 15:56:43, Apr 20 2020

  [20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +)
  [20210406-175441.393429]
  [20210406-175441.393433] SoC: Rockchip rk3399


Very good. TF-A should work "out of the box" in meta-rockchip, so I 
think changing it's baudrate to 150 makes sense at this point (at 
least until u-boot can pass the DTB)




Signed-off-by: Yann Dirson 
---
  .../files/serial-console-baudrate.patch   | 35 +++
  .../trusted-firmware-a_%.bbappend |  5 +++
  2 files changed, 40 insertions(+)
  create mode 100644 
recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch 
b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson 
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 150.
+
+TF-A runs between two u-boot stages which both uses 150 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in 
https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.


Please add Upstream-Status:



+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h 
b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
 b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**
+  * UART related constants
+  **/
+-#define RK3399_BAUDRATE   115200
++#define RK3399_BAUDRATE   150
+ #define RK3399_UART_CLOCK 2400
+
+ 
/**
+--
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend 
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"
  
  COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"

  COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+file://serial-console-baudrate.patch \
+"




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

Re: [yocto] [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

[Joshua Watt]

On 3/22/21 2:30 PM, Yann Dirson wrote:

Hi Joshua,

Le lun. 22 mars 2021 à 19:24, Joshua Watt  a écrit :


On 3/22/21 9:59 AM, Yann Dirson wrote:

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner  a écrit :

On Mon 2021-03-22 @ 02:42:12 PM, yann.dir...@blade-group.com wrote:

This supports both the 2GB and 4GB versions of the board.  This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.

Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.

Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?

FWIW, I'd rather u-boot could automatcially detect what variant of the board 
it's running on and do the right thing (usually, just selecting the proper DTB 
from the FIT image). The only reason I did not do this on the rock-pi-4 is 
because there doesn't appear to be a way for u-boot to detect which variant 
it's on :/

Wait, it's only the dtb used by u-boot which is different in this
case, the kernel uses a single dtb for both variants.
Those probably get embedded inside the bootloader, in any case they
are not those embedded in the fitImage.

  #include "rk3399-nanopi4-u-boot.dtsi"
-#include "rk3399-sdram-ddr3-1866.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"

I have no clue how easily the two boards could be told one from the
other (let alone if that can be done safely),
and I feel that would rather be uboot-side work, rather than something
to be solved on the yocto side.


Ah, I was referring to the DTB used by the Kernel (which u-boot can 
switch), not the DTB used by u-boot itself (which AFAIK is compiled into 
u-boot and cannot be changed).















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

Re: [yocto] [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

[Joshua Watt]

On 3/22/21 9:59 AM, Yann Dirson wrote:

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner  a écrit :

On Mon 2021-03-22 @ 02:42:12 PM, yann.dir...@blade-group.com wrote:

This supports both the 2GB and 4GB versions of the board.  This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.

Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.

Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?


FWIW, I'd rather u-boot could automatcially detect what variant of the 
board it's running on and do the right thing (usually, just selecting 
the proper DTB from the FIT image). The only reason I did not do this on 
the rock-pi-4 is because there doesn't appear to be a way for u-boot to 
detect which variant it's on :/










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

Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?

[Joshua Watt]

On 3/14/21 6:16 PM, p32 via lists.yoctoproject.org wrote:
Thank you very much. I figured out that you can have Yocto create a 
suitable U-Boot wrapper as follows (from the image recipe):

IMAGE_FSTYPES = "cpio.xz.u-boot"

Now there is only one last issue that I wasn't able to solve yet: I 
would like Yocto to not only generate this U-Boot file but also add it 
to the boot partition of a wic.gz image. I tried to extend the image 
recipe as follows:

IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
IMAGE_BOOT_FILES_append += 
"${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"


Unfortunately, there is a dependency issue here. BitBake schedules the 
do_image_wic task before the do_image_cpio task, which creates the 
u-boot file. I tried to fix it as follows (from the image recipe):

do_image_wic[depends] = "my-image-recipe:do_image_cpio"

While the dependency graph acknowledges this dependency, BitBake does 
not seem to care about it. Whatever I try, do_image_wic is always 
executed first and, obviously, does not succeed. I think the problem 
is comparable to the unsolved one outlined here:

https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image

How can I instruct Yocto to execute do_image_cpio first?


You might try splitting it up with two images; one that makes your CPIO 
and one that makes the wic image. Since the wic image (presumably?) 
doesn't even have the rootfs specified, it probably doesn't even matter 
what the image is (e.g. you could use core-image-minimal as a test, or 
try to make some even slimmer empty image).


I think by doing that you could do something like:

 IMAGE_BOOT_FILES += "my-cpio-image.cpio.xz.u-boot"

 IMAGE_FILE_DEPENDS += "my-cpio-image"

Then:

 bitbake core-image-minimal

Would sort of do what you are asking

I think they key is that you need a "root file system image" that is 
*not* your CPIO because wic expects to be tied to one that it can write 
to the .wic image, even if thats not actually what you are doing.







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

[yocto] [meta-rockchip][PATCH v2] rock-pi-4: Split our variant machines

[Joshua Watt]

Splits out the three variants of the rock-pi-4 (A, B & C) into their own
machines. Unfortunately, it is not possible to have a single machine
that works for all three, as there isn't any known ways for the
bootloader to distinguish them. The old rock-pi-4 machine is kept around
for use with older kernels

Signed-off-by: Joshua Watt 
---
 conf/machine/include/rk3399.inc|  2 +-
 conf/machine/include/rock-pi-4.inc | 22 ++
 conf/machine/rock-pi-4.conf| 22 --
 conf/machine/rock-pi-4a.conf   | 11 +++
 conf/machine/rock-pi-4b.conf   | 11 +++
 conf/machine/rock-pi-4c.conf   | 11 +++
 6 files changed, 60 insertions(+), 19 deletions(-)
 create mode 100644 conf/machine/include/rock-pi-4.inc
 create mode 100644 conf/machine/rock-pi-4a.conf
 create mode 100644 conf/machine/rock-pi-4b.conf
 create mode 100644 conf/machine/rock-pi-4c.conf

diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 4019988..f6b7826 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -5,8 +5,8 @@ SOC_FAMILY = "rk3399"
 
 DEFAULTTUNE ?= "cortexa72-cortexa53-crypto"
 
-require conf/machine/include/tune-cortexa72-cortexa53.inc
 require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa72-cortexa53.inc
 require conf/machine/include/rockchip-defaults.inc
 
 KBUILD_DEFCONFIG ?= "defconfig"
diff --git a/conf/machine/include/rock-pi-4.inc 
b/conf/machine/include/rock-pi-4.inc
new file mode 100644
index 000..9c21084
--- /dev/null
+++ b/conf/machine/include/rock-pi-4.inc
@@ -0,0 +1,22 @@
+# Add a common override for all Rock Pi 4 machines
+MACHINEOVERRIDES =. "rock-pi-4:"
+
+require conf/machine/include/rk3399.inc
+
+RK_BOOT_DEVICE = "mmcblk1"
+WKS_FILE ?= "rock-pi-4.wks"
+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+mtools-native \
+dosfstools-native \
+virtual/bootloader \
+virtual/kernel \
+"
+IMAGE_BOOT_FILES ?= "\
+${KERNEL_IMAGETYPE} \
+"
+
+SERIAL_CONSOLES = "150;ttyS2"
+
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/rock-pi-4.conf b/conf/machine/rock-pi-4.conf
index 5231abf..23bbfc3 100644
--- a/conf/machine/rock-pi-4.conf
+++ b/conf/machine/rock-pi-4.conf
@@ -4,26 +4,12 @@
 #@TYPE: Machine
 #@NAME: Rock Pi 4 RK3399
 #@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+#
+# NOTE: This machine is for Kernels before 5.10. If you are using an newer 
kernel
+# see rock-pi-4{a,b,c}.conf
 
-require conf/machine/include/rk3399.inc
+require conf/machine/include/rock-pi-4.inc
 
 KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4.dtb"
 UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
 
-RK_BOOT_DEVICE = "mmcblk1"
-WKS_FILE ?= "rock-pi-4.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
-mtools-native \
-dosfstools-native \
-virtual/bootloader \
-virtual/kernel \
-"
-IMAGE_BOOT_FILES ?= "\
-${KERNEL_IMAGETYPE} \
-"
-
-SERIAL_CONSOLES = "150;ttyS2"
-
-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/rock-pi-4a.conf b/conf/machine/rock-pi-4a.conf
new file mode 100644
index 000..abe2336
--- /dev/null
+++ b/conf/machine/rock-pi-4a.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4A RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+#
+# NOTE: This machine is for Kernel 5.10 and later. If you are using an older
+# kernel, see rock-pi-4.conf
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4a.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4b.conf b/conf/machine/rock-pi-4b.conf
new file mode 100644
index 000..587fb32
--- /dev/null
+++ b/conf/machine/rock-pi-4b.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4B RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+#
+# NOTE: This machine is for Kernel 5.10 and later. If you are using an older
+# kernel, see rock-pi-4.conf
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4b.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4c.conf b/conf/machine/rock-pi-4c.conf
new file mode 100644
index 000..3af26ff
--- /dev/null
+++ b/conf/machine/rock-pi-4c.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4C RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+#
+# NOTE: This machine is for Kernel 5.10 and later. If you are using an older
+# kernel, see rock-pi-4.conf
+
+require conf/mac

Re: [yocto] [meta-rockchip][PATCH] rock-pi-4: Split our variant machinesy

[Joshua Watt]

On Mon, Jan 25, 2021 at 5:15 PM Trevor Woerner  wrote:
>
> Is there any way to make this work with both new (4.10, -dev, -tiny, -rt) and
> old (5.4) kernels? What if we left the old rock-pi-4 MACHINE for the 5.4
> kernel and required one of the new ones for 5.10?

Ya, we can keep the old machine around for the old kernels

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

Re: [yocto] [meta-rockchip][PATCH] linux-yocto: Remove Rock Pi 4 patch for serial

[Joshua Watt]

On 1/25/21 4:34 PM, Trevor Woerner wrote:

On Sat 2021-01-23 @ 03:05:25 PM, Joshua Watt wrote:

Upstream OE Core has moved to Kernel 5.10 which fixed this problem, so
remove the patch for 5.8

Thanks, I've already pushed a patch for this one.


Ya, I saw that. We should probably remove the .patch file also.


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

[yocto] [meta-rockchip][PATCH] linux-yocto: Remove Rock Pi 4 patch for serial

[Joshua Watt]

Upstream OE Core has moved to Kernel 5.10 which fixed this problem, so
remove the patch for 5.8

Signed-off-by: Joshua Watt 
---
 ...-resolve-supply-after-creating-regul.patch | 53 ---
 recipes-kernel/linux/linux-yocto_5.8.bbappend |  4 --
 2 files changed, 57 deletions(-)
 delete mode 100644 
recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
 delete mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git 
a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
 
b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
deleted file mode 100644
index 3dd336b..000
--- 
a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
-From: Joshua Watt 
-Date: Thu, 10 Dec 2020 15:59:47 -0600
-Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
-
-This commit prevents the serial console from working on the Rock Pi 4
-for some reason. It *appears* to possibly be fixed by some other commit
-upstream, but after a lot of head scratching and bisecting, I was unable
-to find which one, so just revert it for now and we can deal with it
-later.
-
-This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
-

- drivers/regulator/core.c | 21 -
- 1 file changed, 8 insertions(+), 13 deletions(-)
-
-diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
-index 25e601bf9383..be8c709a7488 100644
 a/drivers/regulator/core.c
-+++ b/drivers/regulator/core.c
-@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
-   else if (regulator_desc->supply_name)
-   rdev->supply_name = regulator_desc->supply_name;
- 
-+  /*
-+   * Attempt to resolve the regulator supply, if specified,
-+   * but don't return an error if we fail because we will try
-+   * to resolve it again later as more regulators are added.
-+   */
-+  if (regulator_resolve_supply(rdev))
-+  rdev_dbg(rdev, "unable to resolve supply\n");
-+
-   ret = set_machine_constraints(rdev, constraints);
--  if (ret == -EPROBE_DEFER) {
--  /* Regulator might be in bypass mode and so needs its supply
--   * to set the constraints */
--  /* FIXME: this currently triggers a chicken-and-egg problem
--   * when creating -SUPPLY symlink in sysfs to a regulator
--   * that is just being created */
--  ret = regulator_resolve_supply(rdev);
--  if (!ret)
--  ret = set_machine_constraints(rdev, constraints);
--  else
--  rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
--   ERR_PTR(ret));
--  }
-   if (ret < 0)
-   goto wash;
- 
--- 
-2.29.2
-
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend 
b/recipes-kernel/linux/linux-yocto_5.8.bbappend
deleted file mode 100644
index 5a31842..000
--- a/recipes-kernel/linux/linux-yocto_5.8.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI_append_rock-pi-4 = " 
file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
-
-- 
2.30.0


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

[yocto] [meta-rockchip][PATCH] rock-pi-4: Split our variant machines

[Joshua Watt]

Splits out the three variants of the rock-pi-4 (A, B & C) into their own
machines. Unfortunately, it is not possible to have a single machine
that works for all three, as there isn't any known ways for the
bootloader to distinguish them.

Signed-off-by: Joshua Watt 
---
 conf/machine/include/rk3399.inc| 2 +-
 conf/machine/{rock-pi-4.conf => include/rock-pi-4.inc} | 8 ++--
 conf/machine/rock-pi-4a.conf   | 8 
 conf/machine/rock-pi-4b.conf   | 8 
 conf/machine/rock-pi-4c.conf   | 8 
 5 files changed, 27 insertions(+), 7 deletions(-)
 rename conf/machine/{rock-pi-4.conf => include/rock-pi-4.inc} (68%)
 create mode 100644 conf/machine/rock-pi-4a.conf
 create mode 100644 conf/machine/rock-pi-4b.conf
 create mode 100644 conf/machine/rock-pi-4c.conf

diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 4019988..f6b7826 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -5,8 +5,8 @@ SOC_FAMILY = "rk3399"
 
 DEFAULTTUNE ?= "cortexa72-cortexa53-crypto"
 
-require conf/machine/include/tune-cortexa72-cortexa53.inc
 require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa72-cortexa53.inc
 require conf/machine/include/rockchip-defaults.inc
 
 KBUILD_DEFCONFIG ?= "defconfig"
diff --git a/conf/machine/rock-pi-4.conf b/conf/machine/include/rock-pi-4.inc
similarity index 68%
rename from conf/machine/rock-pi-4.conf
rename to conf/machine/include/rock-pi-4.inc
index 5231abf..7a98063 100644
--- a/conf/machine/rock-pi-4.conf
+++ b/conf/machine/include/rock-pi-4.inc
@@ -1,15 +1,11 @@
 # Copyright (C) 2020 Garmin Ltd. or its subsidaries
 # Released under the MIT license (see COPYING.MIT for the terms)
 
-#@TYPE: Machine
-#@NAME: Rock Pi 4 RK3399
-#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+# Add a common override for all Rock Pi 4 machines
+MACHINEOVERRIDES =. "rock-pi-4:"
 
 require conf/machine/include/rk3399.inc
 
-KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4.dtb"
-UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
-
 RK_BOOT_DEVICE = "mmcblk1"
 WKS_FILE ?= "rock-pi-4.wks"
 IMAGE_FSTYPES += "wic wic.bmap"
diff --git a/conf/machine/rock-pi-4a.conf b/conf/machine/rock-pi-4a.conf
new file mode 100644
index 000..9f3aa5a
--- /dev/null
+++ b/conf/machine/rock-pi-4a.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4A RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4a.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4b.conf b/conf/machine/rock-pi-4b.conf
new file mode 100644
index 000..033c063
--- /dev/null
+++ b/conf/machine/rock-pi-4b.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4B RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4b.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4c.conf b/conf/machine/rock-pi-4c.conf
new file mode 100644
index 000..9e9
--- /dev/null
+++ b/conf/machine/rock-pi-4c.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4C RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip 
RK3399 Processor.
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4c.dtb"
+UBOOT_MACHINE = "rock-pi-4c-rk3399_defconfig"
-- 
2.30.0


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

Re: [yocto] [meta-rockchip][PATCH] Fix Rock Pi 4 serial port

[Joshua Watt]

On 12/11/20 9:16 AM, Bruce Ashfield wrote:

On Fri, Dec 11, 2020 at 9:48 AM Joshua Watt  wrote:

Fixes the serial port output stopping mid way through the boot process
by reverting the kernel commit that caused it.

If you want, I can also pick this up and merge it directly into
linux-yocto and do a SRCREV bump.

Have you tested against 5.10 ? I'm working through issues with it now,
and it would be nice to fix this before it pops up again on the next
reference kernel bump.


When I use `linux-yocto-dev` as the kernel provider, it works just fine 
(in fact, I can't seem to find the commit that *fixes* the problem 
there), so I think 5.10 will be OK? Is there something else I should 
try instead?



I'm not sure if we want to backport it to linux-yocto or not... I 
presume upstream backported it because it fixed something, so I'd be a 
little worried about a regression somewhere else.




Cheers,

Bruce


Signed-off-by: Joshua Watt 
---
  ...-resolve-supply-after-creating-regul.patch | 53 +++
  recipes-kernel/linux/linux-yocto_5.8.bbappend |  4 ++
  2 files changed, 57 insertions(+)
  create mode 100644 
recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
  create mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git 
a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
 
b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
new file mode 100644
index 000..3dd336b
--- /dev/null
+++ 
b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
@@ -0,0 +1,53 @@
+From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
+From: Joshua Watt 
+Date: Thu, 10 Dec 2020 15:59:47 -0600
+Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
+
+This commit prevents the serial console from working on the Rock Pi 4
+for some reason. It *appears* to possibly be fixed by some other commit
+upstream, but after a lot of head scratching and bisecting, I was unable
+to find which one, so just revert it for now and we can deal with it
+later.
+
+This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
+
+---
+ drivers/regulator/core.c | 21 -
+ 1 file changed, 8 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index 25e601bf9383..be8c709a7488 100644
+--- a/drivers/regulator/core.c
 b/drivers/regulator/core.c
+@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
+   else if (regulator_desc->supply_name)
+   rdev->supply_name = regulator_desc->supply_name;
+
++  /*
++   * Attempt to resolve the regulator supply, if specified,
++   * but don't return an error if we fail because we will try
++   * to resolve it again later as more regulators are added.
++   */
++  if (regulator_resolve_supply(rdev))
++  rdev_dbg(rdev, "unable to resolve supply\n");
++
+   ret = set_machine_constraints(rdev, constraints);
+-  if (ret == -EPROBE_DEFER) {
+-  /* Regulator might be in bypass mode and so needs its supply
+-   * to set the constraints */
+-  /* FIXME: this currently triggers a chicken-and-egg problem
+-   * when creating -SUPPLY symlink in sysfs to a regulator
+-   * that is just being created */
+-  ret = regulator_resolve_supply(rdev);
+-  if (!ret)
+-  ret = set_machine_constraints(rdev, constraints);
+-  else
+-  rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+-   ERR_PTR(ret));
+-  }
+   if (ret < 0)
+   goto wash;
+
+--
+2.29.2
+
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend 
b/recipes-kernel/linux/linux-yocto_5.8.bbappend
new file mode 100644
index 000..5a31842
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.8.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append_rock-pi-4 = " 
file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
+
--
2.29.2






--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

[yocto] [meta-rockchip][PATCH] Fix Rock Pi 4 serial port

[Joshua Watt]

Fixes the serial port output stopping mid way through the boot process
by reverting the kernel commit that caused it.

Signed-off-by: Joshua Watt 
---
 ...-resolve-supply-after-creating-regul.patch | 53 +++
 recipes-kernel/linux/linux-yocto_5.8.bbappend |  4 ++
 2 files changed, 57 insertions(+)
 create mode 100644 
recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
 create mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git 
a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
 
b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
new file mode 100644
index 000..3dd336b
--- /dev/null
+++ 
b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
@@ -0,0 +1,53 @@
+From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
+From: Joshua Watt 
+Date: Thu, 10 Dec 2020 15:59:47 -0600
+Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
+
+This commit prevents the serial console from working on the Rock Pi 4
+for some reason. It *appears* to possibly be fixed by some other commit
+upstream, but after a lot of head scratching and bisecting, I was unable
+to find which one, so just revert it for now and we can deal with it
+later.
+
+This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
+
+---
+ drivers/regulator/core.c | 21 -
+ 1 file changed, 8 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index 25e601bf9383..be8c709a7488 100644
+--- a/drivers/regulator/core.c
 b/drivers/regulator/core.c
+@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
+   else if (regulator_desc->supply_name)
+   rdev->supply_name = regulator_desc->supply_name;
+ 
++  /*
++   * Attempt to resolve the regulator supply, if specified,
++   * but don't return an error if we fail because we will try
++   * to resolve it again later as more regulators are added.
++   */
++  if (regulator_resolve_supply(rdev))
++  rdev_dbg(rdev, "unable to resolve supply\n");
++
+   ret = set_machine_constraints(rdev, constraints);
+-  if (ret == -EPROBE_DEFER) {
+-  /* Regulator might be in bypass mode and so needs its supply
+-   * to set the constraints */
+-  /* FIXME: this currently triggers a chicken-and-egg problem
+-   * when creating -SUPPLY symlink in sysfs to a regulator
+-   * that is just being created */
+-  ret = regulator_resolve_supply(rdev);
+-  if (!ret)
+-  ret = set_machine_constraints(rdev, constraints);
+-  else
+-  rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+-   ERR_PTR(ret));
+-  }
+   if (ret < 0)
+   goto wash;
+ 
+-- 
+2.29.2
+
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend 
b/recipes-kernel/linux/linux-yocto_5.8.bbappend
new file mode 100644
index 000..5a31842
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.8.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append_rock-pi-4 = " 
file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
+
-- 
2.29.2


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

Re: [yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

[Joshua Watt]

On 11/16/20 2:38 PM, Marek Belisko wrote:

Hi,

I'm bumping my project based on zeus to dunfell. I've update all
layers and in one of my recipes I'm seeing following issue (not see on
zeus at all):
WARNING: cv-my-test-1.0-r0 do_package: KeyError in ./package/srv/10%.png
ERROR: cv-my-test-1.0-r0 do_package: Error executing a python function
in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:sstate_report_unihash(d)
  0003:
File: '/home/ubuntu/projects/my-test-/poky/meta/classes/sstate.bbclass',
lineno: 840, function: sstate_report_unihash
  0836:report_unihash = getattr(bb.parse.siggen, 'report_unihash', None)
  0837:
  0838:if report_unihash:
  0839:ss = sstate_state_fromvars(d)
  *** 0840:report_unihash(os.getcwd(), ss['task'], d)
  0841:}
  0842:
  0843:#
  0844:# Shell function to decompress and prepare a package for installation
File: '/home/ubuntu/projects/my-test-/poky/bitbake/lib/bb/siggen.py',
lineno: 555, function: report_unihash
  0551:
  0552:if "." in self.method:
  0553:(module, method) = self.method.rsplit('.', 1)
  0554:locs['method'] =
getattr(importlib.import_module(module), method)
  *** 0555:outhash = bb.utils.better_eval('method(path,
sigfile, task, d)', locs)
  0556:else:
  0557:outhash = bb.utils.better_eval(self.method +
'(path, sigfile, task, d)', locs)
  0558:
  0559:try:
File: '/home/ubuntu/projects/my-test-/poky/bitbake/lib/bb/utils.py',
lineno: 420, function: better_eval
  0416:if extraglobals:
  0417:ctx = copy.copy(ctx)
  0418:for g in extraglobals:
  0419:ctx[g] = extraglobals[g]
  *** 0420:return eval(source, ctx, locals)
  0421:
  0422:@contextmanager
  0423:def fileslocked(files):
  0424:"""Context manager for locking and unlocking file locks."""
File: '', lineno: 1, function: 
   File "", line 1, in 

File: '/home/ubuntu/projects/my-test-/poky/meta/lib/oe/sstatesig.py',
lineno: 595, function: OEOuthashBasic
  0591:process(root)
  0592:for f in files:
  0593:if f == 'fixmepath':
  0594:continue
  *** 0595:process(os.path.join(root, f))
  0596:finally:
  0597:os.chdir(prev_dir)
  0598:
  0599:return h.hexdigest()
File: '/home/ubuntu/projects/my-test-/poky/meta/lib/oe/sstatesig.py',
lineno: 551, function: process
  0547:add_perm(stat.S_IXOTH, 'x')
  0548:
  0549:if include_owners:
  0550:try:
  *** 0551:update_hash(" %10s" %
pwd.getpwuid(s.st_uid).pw_name)
  0552:update_hash(" %10s" %
grp.getgrgid(s.st_gid).gr_name)
  0553:except KeyError:
  0554:bb.warn("KeyError in %s" % path)
  0555:raise
Exception: KeyError: 'getpwuid(): uid not found: 1000'

ERROR: Logfile of failure stored in:
/home/ubuntu/projects/my-test-/build/tmp/work/aarch64-poky-linux/cv-my-test/1.0-r0/temp/log.do_package.27454

Is this known issue or something related to my host setup?


This means the recipe is having host contamination (where the UID of the 
user doing the build is leaking into the file system).




Thanks and BR,

marek





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

Re: [yocto] #yocto bbappend question

[Joshua Watt]

On 11/16/20 8:24 AM, Monsees, Steven C (US) via lists.yoctoproject.org 
wrote:


If a recipe has a “do_install_append” can I create a bbappend file to 
do a “do_install_append_append” in order to change 1 line in that 
routine, or do I need to just


replace the “do_install_append” routine entirely with a copy and the 
modified line?


AFAIK, there is no way to replace a do_install_append from another 
.bbappend; you'll have to modify the original.







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

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

[Joshua Watt]

On 10/5/20 3:36 PM, Peter Kjellerstedt wrote:

-Original Message-
From: yocto@lists.yoctoproject.org  On
Behalf Of Joshua Watt
Sent: den 1 oktober 2020 15:27
To: Khem Raj 
Cc: Peter Kjellerstedt ;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC
10 (which uses -fno-common by default)

On Wed, Sep 30, 2020 at 4:34 PM Khem Raj  wrote:

On Wed, Sep 30, 2020 at 1:37 PM Joshua Watt 

wrote:

With this patch applied, I get the following errors when using the
latest master branches:

| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
| mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
| mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
| mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
| mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
| mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
| ../util/libutil.a(iobuf.o): In function `file_filter':
| iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o): In function `underflow':
| iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
references to `iobuf_debug_mode' follow
| collect2: error: ld returned 1 exit status

If I revert this commit, gnupg-native will again build correctly. Any
ideas?

Interesting. I had not considered building the recipes from
meta-gplv2 for native as we only use them for target builds.


does it help if you add -fno-common to native CFLAGS

No. It works in all cases if I remove the patch and use "-fcommon"
though. Oddly enough, in my build having the patch caused the target
recipe to fail one way, and not having it caused it to fail another
way

Are you saying you still have build failures when building gnupg for
target as well, with the patch applied?


Correct. I don't remember exactly, but there was no combination of 
"-fno-common" and the patch that worked for both native and target 
cases. The only way I could get it to work for both was without the 
patch and with "-fcommon"





not sure what's going on there, but I suspect for something
this old, adding "-fcommon" to restore the original behavior makes the
most sense.

Anyway, I get the same errors as above when I try building it for
native using gcc 9.3.1. I'll look into it and see if I can improve
the patch, or if I will have to resort to using -fcommon.

//Peter


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

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

[Joshua Watt]

On Wed, Sep 30, 2020 at 4:34 PM Khem Raj  wrote:
>
> On Wed, Sep 30, 2020 at 1:37 PM Joshua Watt  wrote:
> >
> > With this patch applied, I get the following errors when using the
> > latest master branches:
> >
> > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
> > | mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
> > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
> > | mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
> > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
> > | mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
> > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
> > | mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
> > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
> > | mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
> > | ../util/libutil.a(iobuf.o): In function `file_filter':
> > | iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
> > | iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
> > | iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
> > | iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
> > | ../util/libutil.a(iobuf.o): In function `underflow':
> > | iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
> > | ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
> > references to `iobuf_debug_mode' follow
> > | collect2: error: ld returned 1 exit status
> >
> > If I revert this commit, gnupg-native will again build correctly. Any ideas?
> >
>
> does it help if you add -fno-common to native CFLAGS

No. It works in all cases if I remove the patch and use "-fcommon"
though. Oddly enough, in my build having the patch caused the target
recipe to fail one way, and not having it caused it to fail another
way not sure what's going on there, but I suspect for something
this old, adding "-fcommon" to restore the original behavior makes the
most sense.

>
> > On Mon, Aug 31, 2020 at 5:44 PM Peter Kjellerstedt
> >  wrote:
> > >
> > > Signed-off-by: Peter Kjellerstedt 
> > > ---
> > >  ...th-GCC-10-which-uses-fno-common-by-d.patch | 93 +++
> > >  recipes-support/gnupg/gnupg_1.4.7.bb  |  3 +-
> > >  2 files changed, 95 insertions(+), 1 deletion(-)
> > >  create mode 100644 
> > > recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
> > >
> > > diff --git 
> > > a/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
> > >  
> > > b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
> > > new file mode 100644
> > > index 000..2f84155
> > > --- /dev/null
> > > +++ 
> > > b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
> > > @@ -0,0 +1,93 @@
> > > +From 1d0141d77d4f81cfa3213370fb7eeddbf53fc085 Mon Sep 17 00:00:00 2001
> > > +From: Peter Kjellerstedt 
> > > +Date: Tue, 1 Sep 2020 00:29:22 +0200
> > > +Subject: [PATCH] Make it build with GCC 10 (which uses -fno-common by 
> > > default)
> > > +
> > > +Signed-off-by: Peter Kjellerstedt 
> > > +---
> > > + g10/options.h| 3 +--
> > > + include/cipher.h | 2 +-
> > > + include/iobuf.h  | 2 +-
> > > + include/memory.h | 2 +-
> > > + include/mpi.h| 2 +-
> > > + tools/mpicalc.c  | 1 +
> > > + 6 files changed, 6 insertions(+), 6 deletions(-)
> > > +
> > > +diff --git a/g10/options.h b/g10/options.h
> > > +index c5f0f22..33ed333 100644
> > > +--- a/g10/options.h
> > >  b/g10/options.h
> > > +@@ -28,8 +28,7 @@
> > > + #include "packet.h"
> > > +
> > > + #ifndef EXTERN_UNLESS_MAIN_MODULE
> > > +-/* Norcraft can't cope with common symbols */
> > > +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
> > > ++#if !defined (INCLUDED_BY_MAIN_MODULE)
> > > + #define EXTERN_UNLESS_MAIN_MODULE extern
> > > + #else
> > > + #define EXTERN_UNLESS_MAIN_MODULE
> > > +diff --git a/include/cipher.h b/include/cipher.h
> > > +index 168ab41..794c12b 100644
> > > +--- a/include/cipher.h
> > >  b/include/cipher.h
> > > +@@ -109,7 +109,7 @@ struct gcry_md_context {
> > > + typedef struct gc

[yocto][meta-gplv2][PATCH] gnupg: Build with "-fcommon"

[Joshua Watt]

The patch from f9761c0 ("gnupg: Make it build with GCC 10 (which uses
-fno-common by default)") doesn't work in all cases, such as when
building gnupg-native. Instead of trying to patch around it, re-enable
the -fcommon flag explicitly to keep the build the same as it was before
GCC 10 changed the default.

This reverts commit f9761c01495cd52ce88e33fbc8824f882cf80288.

Signed-off-by: Joshua Watt 
---
 ...th-GCC-10-which-uses-fno-common-by-d.patch | 93 ---
 recipes-support/gnupg/gnupg_1.4.7.bb  |  7 +-
 2 files changed, 5 insertions(+), 95 deletions(-)
 delete mode 100644 
recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch

diff --git 
a/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
 
b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
deleted file mode 100644
index 2f84155..000
--- 
a/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
+++ /dev/null
@@ -1,93 +0,0 @@
-From 1d0141d77d4f81cfa3213370fb7eeddbf53fc085 Mon Sep 17 00:00:00 2001
-From: Peter Kjellerstedt 
-Date: Tue, 1 Sep 2020 00:29:22 +0200
-Subject: [PATCH] Make it build with GCC 10 (which uses -fno-common by default)
-
-Signed-off-by: Peter Kjellerstedt 

- g10/options.h| 3 +--
- include/cipher.h | 2 +-
- include/iobuf.h  | 2 +-
- include/memory.h | 2 +-
- include/mpi.h| 2 +-
- tools/mpicalc.c  | 1 +
- 6 files changed, 6 insertions(+), 6 deletions(-)
-
-diff --git a/g10/options.h b/g10/options.h
-index c5f0f22..33ed333 100644
 a/g10/options.h
-+++ b/g10/options.h
-@@ -28,8 +28,7 @@
- #include "packet.h"
- 
- #ifndef EXTERN_UNLESS_MAIN_MODULE
--/* Norcraft can't cope with common symbols */
--#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
-+#if !defined (INCLUDED_BY_MAIN_MODULE)
- #define EXTERN_UNLESS_MAIN_MODULE extern
- #else
- #define EXTERN_UNLESS_MAIN_MODULE 
-diff --git a/include/cipher.h b/include/cipher.h
-index 168ab41..794c12b 100644
 a/include/cipher.h
-+++ b/include/cipher.h
-@@ -109,7 +109,7 @@ struct gcry_md_context {
- typedef struct gcry_md_context *MD_HANDLE;
- 
- #ifndef EXTERN_UNLESS_MAIN_MODULE
--#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
-+#if !defined (INCLUDED_BY_MAIN_MODULE)
- #define EXTERN_UNLESS_MAIN_MODULE extern
- #else
- #define EXTERN_UNLESS_MAIN_MODULE 
-diff --git a/include/iobuf.h b/include/iobuf.h
-index a1d58c9..25f682b 100644
 a/include/iobuf.h
-+++ b/include/iobuf.h
-@@ -73,7 +73,7 @@ struct iobuf_struct {
- };
- 
- #ifndef EXTERN_UNLESS_MAIN_MODULE
--#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
-+#if !defined (INCLUDED_BY_MAIN_MODULE)
- #define EXTERN_UNLESS_MAIN_MODULE extern
- #else
- #define EXTERN_UNLESS_MAIN_MODULE 
-diff --git a/include/memory.h b/include/memory.h
-index 895d8a7..217d316 100644
 a/include/memory.h
-+++ b/include/memory.h
-@@ -87,7 +87,7 @@ unsigned secmem_get_flags(void);
- #define DBG_MEMSTAT   memory_stat_debug_mode
- 
- #ifndef EXTERN_UNLESS_MAIN_MODULE
--#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
-+#if !defined (INCLUDED_BY_MAIN_MODULE)
- #define EXTERN_UNLESS_MAIN_MODULE extern
- #else
- #define EXTERN_UNLESS_MAIN_MODULE 
-diff --git a/include/mpi.h b/include/mpi.h
-index 81061d3..d529bda 100644
 a/include/mpi.h
-+++ b/include/mpi.h
-@@ -38,7 +38,7 @@
- #include "memory.h"
- 
- #ifndef EXTERN_UNLESS_MAIN_MODULE
--#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
-+#if !defined (INCLUDED_BY_MAIN_MODULE)
- #define EXTERN_UNLESS_MAIN_MODULE extern
- #else
- #define EXTERN_UNLESS_MAIN_MODULE 
-diff --git a/tools/mpicalc.c b/tools/mpicalc.c
-index 1df27d9..647dfbd 100644
 a/tools/mpicalc.c
-+++ b/tools/mpicalc.c
-@@ -30,6 +30,7 @@
- #include 
- #include 
- 
-+#define INCLUDED_BY_MAIN_MODULE 1
- #include "util.h"
- #include "mpi.h"
- #include "i18n.h"
diff --git a/recipes-support/gnupg/gnupg_1.4.7.bb 
b/recipes-support/gnupg/gnupg_1.4.7.bb
index 6258809..f02aaba 100644
--- a/recipes-support/gnupg/gnupg_1.4.7.bb
+++ b/recipes-support/gnupg/gnupg_1.4.7.bb
@@ -20,8 +20,7 @@ SRC_URI = "${GNUPG_MIRROR}/gnupg/gnupg-${PV}.tar.bz2 \
file://CVE-2013-4242.patch \
file://fix-ustar-check-issue.patch \
file://0001-Make-it-build-with-gettext-0.20.patch \
-   
file://0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch \
-   "
+  "
 
 SRC_URI[md5sum] = "b06a141cca5cd1a55bbdd25ab833303c"
 SRC_URI[sha256sum] = 
"69d18b7d193f62ca27ed4febcb4c9044aa0c95305d3258fe902e2fae5fc6468d"
@@ -89,6 +88,10 @@ EXTRA_OECONF = "--disable-ldap \
 BUILD_CFLAGS += "-fgnu89-inline"
 CFLAGS += "-fgnu89-inline"
 
+# Force -fcommon to avoid issues with GCC 10 (

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

[Joshua Watt]

With this patch applied, I get the following errors when using the
latest master branches:

| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
| mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
| mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
| mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
| mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
| mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
| ../util/libutil.a(iobuf.o): In function `file_filter':
| iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o): In function `underflow':
| iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
references to `iobuf_debug_mode' follow
| collect2: error: ld returned 1 exit status

If I revert this commit, gnupg-native will again build correctly. Any ideas?

On Mon, Aug 31, 2020 at 5:44 PM Peter Kjellerstedt
 wrote:
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  ...th-GCC-10-which-uses-fno-common-by-d.patch | 93 +++
>  recipes-support/gnupg/gnupg_1.4.7.bb  |  3 +-
>  2 files changed, 95 insertions(+), 1 deletion(-)
>  create mode 100644 
> recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
>
> diff --git 
> a/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
>  
> b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
> new file mode 100644
> index 000..2f84155
> --- /dev/null
> +++ 
> b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch
> @@ -0,0 +1,93 @@
> +From 1d0141d77d4f81cfa3213370fb7eeddbf53fc085 Mon Sep 17 00:00:00 2001
> +From: Peter Kjellerstedt 
> +Date: Tue, 1 Sep 2020 00:29:22 +0200
> +Subject: [PATCH] Make it build with GCC 10 (which uses -fno-common by 
> default)
> +
> +Signed-off-by: Peter Kjellerstedt 
> +---
> + g10/options.h| 3 +--
> + include/cipher.h | 2 +-
> + include/iobuf.h  | 2 +-
> + include/memory.h | 2 +-
> + include/mpi.h| 2 +-
> + tools/mpicalc.c  | 1 +
> + 6 files changed, 6 insertions(+), 6 deletions(-)
> +
> +diff --git a/g10/options.h b/g10/options.h
> +index c5f0f22..33ed333 100644
> +--- a/g10/options.h
>  b/g10/options.h
> +@@ -28,8 +28,7 @@
> + #include "packet.h"
> +
> + #ifndef EXTERN_UNLESS_MAIN_MODULE
> +-/* Norcraft can't cope with common symbols */
> +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
> ++#if !defined (INCLUDED_BY_MAIN_MODULE)
> + #define EXTERN_UNLESS_MAIN_MODULE extern
> + #else
> + #define EXTERN_UNLESS_MAIN_MODULE
> +diff --git a/include/cipher.h b/include/cipher.h
> +index 168ab41..794c12b 100644
> +--- a/include/cipher.h
>  b/include/cipher.h
> +@@ -109,7 +109,7 @@ struct gcry_md_context {
> + typedef struct gcry_md_context *MD_HANDLE;
> +
> + #ifndef EXTERN_UNLESS_MAIN_MODULE
> +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
> ++#if !defined (INCLUDED_BY_MAIN_MODULE)
> + #define EXTERN_UNLESS_MAIN_MODULE extern
> + #else
> + #define EXTERN_UNLESS_MAIN_MODULE
> +diff --git a/include/iobuf.h b/include/iobuf.h
> +index a1d58c9..25f682b 100644
> +--- a/include/iobuf.h
>  b/include/iobuf.h
> +@@ -73,7 +73,7 @@ struct iobuf_struct {
> + };
> +
> + #ifndef EXTERN_UNLESS_MAIN_MODULE
> +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
> ++#if !defined (INCLUDED_BY_MAIN_MODULE)
> + #define EXTERN_UNLESS_MAIN_MODULE extern
> + #else
> + #define EXTERN_UNLESS_MAIN_MODULE
> +diff --git a/include/memory.h b/include/memory.h
> +index 895d8a7..217d316 100644
> +--- a/include/memory.h
>  b/include/memory.h
> +@@ -87,7 +87,7 @@ unsigned secmem_get_flags(void);
> + #define DBG_MEMSTAT   memory_stat_debug_mode
> +
> + #ifndef EXTERN_UNLESS_MAIN_MODULE
> +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
> ++#if !defined (INCLUDED_BY_MAIN_MODULE)
> + #define EXTERN_UNLESS_MAIN_MODULE extern
> + #else
> + #define EXTERN_UNLESS_MAIN_MODULE
> +diff --git a/include/mpi.h b/include/mpi.h
> +index 81061d3..d529bda 100644
> +--- a/include/mpi.h
>  b/include/mpi.h
> +@@ -38,7 +38,7 @@
> + #include "memory.h"
> +
> + #ifndef EXTERN_UNLESS_MAIN_MODULE
> +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
> ++#if !defined (INCLUDED_BY_MAIN_MODULE)
> + #define EXTERN_UNLESS_MAIN_MODULE extern
> + #else
> + #define 

Re: [yocto] [meta-mingw][PATCH] Override SDK_VENDOR

[Joshua Watt]

On Mon, Sep 21, 2020, 8:12 AM Samuli Piippo  wrote:

>
> On Mon, 21 Sep 2020 at 15:53, Joshua Watt  wrote:
>
>> On Fri, Sep 18, 2020 at 7:30 AM Samuli Piippo 
>> wrote:
>> >
>> > Set SDK_VENDOR to '-w64', which makes the host triplet match what GCC
>> > expect to find when using mingw32-w64. This enables features that are
>> > not functional in the classic mingw32, but have been implemented in the
>> > mingw32-w64.
>>
>> Does this enable it for the i686 toolchain also? Does that make sense?
>>
>
> This enables it for both x86_64-mingw32 and i686-mingw32 targets and it
> makes sense
> since it's not about the target bitness but the mingw implementation. w64
> has support
> for both targets and provides improved support over the original mingw32.
>

Thanks. I figured that was the case. This is testing on the AB.


>
>> >
>> > Disable 32bit libs from the runtime component when compiling for 64bit,
>> > which were enabled as a side effect of the GCC config change.
>> >
>> > Signed-off-by: Samuli Piippo 
>> > ---
>> >  conf/machine-sdk/include/mingw32-common.inc| 3 +++
>> >  .../mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb | 2 ++
>> >  2 files changed, 5 insertions(+)
>> >
>> > diff --git a/conf/machine-sdk/include/mingw32-common.inc
>> b/conf/machine-sdk/include/mingw32-common.inc
>> > index 9011ded..bc6c91e 100644
>> > --- a/conf/machine-sdk/include/mingw32-common.inc
>> > +++ b/conf/machine-sdk/include/mingw32-common.inc
>> > @@ -1,4 +1,7 @@
>> >  SDK_OS = "mingw32"
>> > +SDK_VENDOR_mingw32 = "-w64"
>> > +SDK_VENDOR_sdkmingw32 = "-w64"
>> > +
>> >  NATIVESDKLIBC = "libc-mingw"
>> >
>> >  PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32
>> = "nativesdk-mingw-w64-runtime"
>> > diff --git a/recipes-devtools/mingw-w64/
>> nativesdk-mingw-w64-runtime_7.0.0.bb b/recipes-devtools/mingw-w64/
>> nativesdk-mingw-w64-runtime_7.0.0.bb
>> > index cf39c6a..9f79ffe 100644
>> > --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
>> > +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
>> > @@ -19,6 +19,8 @@ PROVIDES += "virtual/nativesdk-libintl"
>> >
>> >  TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
>> >
>> > +EXTRA_OECONF_x86-64 = "--disable-lib32"
>> > +
>> >  do_configure() {
>> >  oe_runconf
>> >  }
>> > --
>> > 2.17.1
>> >
>>
>> 
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50753): https://lists.yoctoproject.org/g/yocto/message/50753
Mute This Topic: https://lists.yoctoproject.org/mt/76929287/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] Override SDK_VENDOR

[Joshua Watt]

On Fri, Sep 18, 2020 at 7:30 AM Samuli Piippo  wrote:
>
> Set SDK_VENDOR to '-w64', which makes the host triplet match what GCC
> expect to find when using mingw32-w64. This enables features that are
> not functional in the classic mingw32, but have been implemented in the
> mingw32-w64.

Does this enable it for the i686 toolchain also? Does that make sense?

>
> Disable 32bit libs from the runtime component when compiling for 64bit,
> which were enabled as a side effect of the GCC config change.
>
> Signed-off-by: Samuli Piippo 
> ---
>  conf/machine-sdk/include/mingw32-common.inc| 3 +++
>  .../mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb | 2 ++
>  2 files changed, 5 insertions(+)
>
> diff --git a/conf/machine-sdk/include/mingw32-common.inc 
> b/conf/machine-sdk/include/mingw32-common.inc
> index 9011ded..bc6c91e 100644
> --- a/conf/machine-sdk/include/mingw32-common.inc
> +++ b/conf/machine-sdk/include/mingw32-common.inc
> @@ -1,4 +1,7 @@
>  SDK_OS = "mingw32"
> +SDK_VENDOR_mingw32 = "-w64"
> +SDK_VENDOR_sdkmingw32 = "-w64"
> +
>  NATIVESDKLIBC = "libc-mingw"
>
>  PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
> "nativesdk-mingw-w64-runtime"
> diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb 
> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
> index cf39c6a..9f79ffe 100644
> --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
> @@ -19,6 +19,8 @@ PROVIDES += "virtual/nativesdk-libintl"
>
>  TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
>
> +EXTRA_OECONF_x86-64 = "--disable-lib32"
> +
>  do_configure() {
>  oe_runconf
>  }
> --
> 2.17.1
>

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

Re: [yocto] Additional log handler

[Joshua Watt]

On 8/24/20 8:26 AM, Richard Purdie wrote:

On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:

The newer log handling uses Python's structure logging configuration
[1], so you should be able to use whatever capabilities it has
(including logging different domains/levels to a separate file). In
fact, this is the only way logging is handled by core bitbake now;
all of the other logging mechanisms used by the UI are additional
configuration specified on top of the user's BB_LOGCONFIG file. If
you are interested, you can see this in bitbake/lib/bb/ui/knotty.py.
In that file is an additional tool that might be helpful. Around line
553, there are two commented lines of code:

 #import logging_tree
 #logging_tree.printout()

uncommenting them and installing the logging_tree python package will
make bitbake dump the entire structured logging configuration to
stdout on startup so you can look at it.

On a slightly different but related note, could we remove the
debug_domains code now? I assume that can all be handled by
BB_LOGCONFIG?


Ah, right; you jogged my memory :) Structured logging still co-exists 
with the debug_domains, so it's not the *only* way the core speicfies 
logging messages. The main reason for this is that we still need to pass 
the set of active logging domains to the bitbake workers that they only 
send back requested logging levels over IPC instead of all log levels 
(per some code I believe you wrote Richard). It should the theoretically 
possible to send over the entire structured log config (which isn't very 
large) to the worker and add in worker side handlers to send back logs 
over IPC instead of the simplified list of logging domains (as a bonus, 
this should allow you to log anything on the worker, not just things in 
the "BitBake" domain). IIRC I tried to get this working in the original 
change, but it ended up being more complicated and not strictly 
necessary for the feature at hand (extra logging hashequiv on the AB) so 
I left in the debug_domain method of filtering in the workers. Since I 
had to leave that in, I also left in the UI code to directly deal with 
the debug domains. The log handling itself still all goes through Python 
logging, and it correctly merges the structured logging and user domains 
so that the actual logging domain level filter level passed to the 
workers is the lower of the user specified logging domain and whatever 
is specified for that domain in the structured config. The UI code could 
fairly easily be converted to instead map the command line arguments to 
structured logging configuration, which would remove any knowledge of 
them on the UI side.



TL;DR No, we can't remove it yet, but we could with some work.




Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50336): https://lists.yoctoproject.org/g/yocto/message/50336
Mute This Topic: https://lists.yoctoproject.org/mt/76366066/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Additional log handler

[Joshua Watt]

On 8/24/20 3:53 AM, Richard Purdie wrote:

On Sun, 2020-08-23 at 17:01 +0200, Konrad Weihmann wrote:

Hi all,

when running bitbake in CI I would like to add an additional log
handler to used python logging to catch *ALL* (task warnings,
dangling append, qa issues, a.s.o.), instead of manually grepping
through the console  log.
The information coming from this should be ideally be written to a
file, file, which can then serve as some sort of report.

Is there a way to do that?

In theory it should be possible to hook to an (obviously non-
existing)
event and handle it from there, right?

Or am I thinking in the wrong direction?

Any pointers are appreciated from my side...

On the autobuilder the code simple watches the console log, filtering
on WARNING: and produces a separate warning stream. A non empty file
triggers the build to show a having warnings.

At the bitbake level it would also definitely be possible, the log
messages are seen in the UI code as events and it can do whatever it
wants with them.

There was a also much more advanced log handling added recently through
the BB_LOGCONFIG variable. I'm not sure if that can define a completely
separate stream or not, I've not tried that.


The newer log handling uses Python's structure logging configuration 
[1], so you should be able to use whatever capabilities it has 
(including logging different domains/levels to a separate file). In 
fact, this is the only way logging is handled by core bitbake now; all 
of the other logging mechanisms used by the UI are additional 
configuration specified on top of the user's BB_LOGCONFIG file. If you 
are interested, you can see this in bitbake/lib/bb/ui/knotty.py. In that 
file is an additional tool that might be helpful. Around line 553, there 
are two commented lines of code:


    #import logging_tree
    #logging_tree.printout()

uncommenting them and installing the logging_tree python package will 
make bitbake dump the entire structured logging configuration to stdout 
on startup so you can look at it.



[1]: https://docs.python.org/3/library/logging.config.html



Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50333): https://lists.yoctoproject.org/g/yocto/message/50333
Mute This Topic: https://lists.yoctoproject.org/mt/76366066/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Changing SDKPATH

[Joshua Watt]

On Fri, Aug 21, 2020 at 8:30 AM Damien LEFEVRE  wrote:
>
> Hi,
>
> I would need that to change the default location for the SDK install script 
> to avoid mistakes with multiple SDKs and ease installations. How can I change 
> the SDKPATH?
>
> My distro includes conf/distro/poky.conf and I overwrite
> SDKPATH = 
> "/opt/${IMAGE_BASENAME}-${SDK_VERSION}-${DISTRO_CODENAME}-${MACHINE}"

You can't include IMAGE_BASENAME in SDKPATH because it's not known at
the time recipe are built; it's only defined when the final image is
created. I'm guessing that's the source of your error.

For reference, we do:

  SDKPATH = "/opt/toolchains/${DISTRO}-${MACHINE}/${SDK_VERSION}"

and it works fine.

>
> If I set SDKPATH to something other than /opt/${DISTRO}/${SDK_VERSION} , 
> nativesdk-libgcc-initial fails some sanity test:
> ...
> checking how to run the C preprocessor... x86_64-pokysdk-linux-gcc -E 
> --sysroot=/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/recipe-sysroot
> configure: error: in 
> `/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/gcc-7.3.0/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc':
> configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E 
> --sysroot=/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/recipe-sysroot
>  " fails sanity check
> See `config.log' for more details.
> WARNING: exit code 1 from a shell command.
> ...
>
> Thanks,
> -Damien
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50315): https://lists.yoctoproject.org/g/yocto/message/50315
Mute This Topic: https://lists.yoctoproject.org/mt/76328600/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto][meta-mingw][PATCH] gdb-cross-canadian: Stop statically linking

[Joshua Watt]

gdb was configured to statically link, presumably so it could find the
static libexpat library. Since libexpat has been updated, it no longer
builds a static library, so remove the flag to make GDB look for one.

Signed-off-by: Joshua Watt 
---
 recipes-devtools/gdb/gdb-cross-canadian_%.bbappend | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend 
b/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
index 067b614..c33a9ce 100644
--- a/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
+++ b/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
@@ -1,4 +1,3 @@
-LDFLAGS_append_sdkmingw32 = " -Wl,-static"
 EXEEXT_sdkmingw32 = ".exe"
 DEPENDS_remove_sdkmingw32 = "nativesdk-ncurses nativesdk-readline 
nativesdk-python"
 RDEPENDS_${PN}_remove_sdkmingw32 = "nativesdk-python-core 
nativesdk-python-lang nativesdk-python-re nativesdk-python-codecs 
nativesdk-python-netclient"
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50054): https://lists.yoctoproject.org/g/yocto/message/50054
Mute This Topic: https://lists.yoctoproject.org/mt/75709150/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto][meta-mingw][PATCH] cmake: Remove toolchain append

[Joshua Watt]

Now that cmake.bbclass in OE-core correctly accounts for MinGW hosts, it
is no longer necessary to manually specify that CMAKE_SYSTEM_NAME as
"Windows"

Signed-off-by: Joshua Watt 
---
 recipes-devtools/cmake/cmake_%.bbappend | 6 --
 1 file changed, 6 deletions(-)

diff --git a/recipes-devtools/cmake/cmake_%.bbappend 
b/recipes-devtools/cmake/cmake_%.bbappend
index d9d7ceb..42d36ac 100644
--- a/recipes-devtools/cmake/cmake_%.bbappend
+++ b/recipes-devtools/cmake/cmake_%.bbappend
@@ -1,7 +1 @@
 DEPENDS_remove_mingw32 = "ncurses"
-
-cmake_do_generate_toolchain_file_append_mingw32() {
-cat >> ${WORKDIR}/toolchain.cmake <-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50053): https://lists.yoctoproject.org/g/yocto/message/50053
Mute This Topic: https://lists.yoctoproject.org/mt/75709145/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] expat: Switch platform to Windows in CMake toolchain file

[Joshua Watt]

On Sat, Jul 18, 2020 at 11:03 AM Oleksandr Popovych
 wrote:
>
> GNU Autotools build system is considered in upstream as potentially
> deprecated (https://github.com/libexpat/libexpat/issues/330), and
> expat library will be switched to use CMake.
>
> So this patch depends on "expat: Added ptest" patch for 'meta' layer,
> and fixes CMake toolchain file to work correctly with 'meta-mingw'
> layer.
> ---
>  recipes-core/expat/expat_%.bbappend | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/recipes-core/expat/expat_%.bbappend 
> b/recipes-core/expat/expat_%.bbappend
> index 626ea5b..0fe3aa0 100644
> --- a/recipes-core/expat/expat_%.bbappend
> +++ b/recipes-core/expat/expat_%.bbappend
> @@ -1,3 +1,9 @@
>
>  FILES_${PN}-bin_mingw32 = "${bindir}/*.exe ${sbindir}/*.exe"
>
> +cmake_do_generate_toolchain_file_append_mingw32() {
> +cat >> ${WORKDIR}/toolchain.cmake < +set( CMAKE_SYSTEM_NAME Windows )
> +EOF
> +}
> +

Hmm, this seems like the kind of thing that should be set for all
mingw32 builds

> --
> 2.17.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50015): https://lists.yoctoproject.org/g/yocto/message/50015
Mute This Topic: https://lists.yoctoproject.org/mt/75687157/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

[Joshua Watt]

On Wed, Jul 1, 2020 at 9:47 AM MikeB  wrote:
>
> The rumors of my success were exaggerated.  If performing a fresh build from 
> scratch, the image build succeeds, but the populate_sdk still fails as in the 
> original post.  If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', 
> the populate_sdk succeeds.

Ok. Are you using archiver.bbclass?

>
> Mike
>
> On Wed, Jul 1, 2020 at 6:45 AM MikeB  wrote:
>>
>> The combination of the 
>> https://lists.openembedded.org/g/openembedded-core/message/140161 and a 
>> 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.
>>
>> Thank you all for the help!
>>
>> On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman  wrote:
>>>
>>> On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
>>> lists.yoctoproject.org 
>>> wrote:
>>> >
>>> > On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt  wrote:
>>> > >
>>> > > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt  
>>> > > wrote:
>>> > > >
>>> > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB  wrote:
>>> > > > >
>>> > > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if 
>>> > > > > this is a bug or just my problem.  I maintain five different 
>>> > > > > architectures and all five have the same failure in gcc-sanitizers 
>>> > > > > as I'm trying to build the SDK.
>>> > > > >
>>> > > > > | cat: 
>>> > > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
>>> > > > >  No such file or directory
>>> > > > > | WARNING: 
>>> > > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
>>> > > > >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
>>> > > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>>> > > > > | ERROR: Execution of 
>>> > > > > '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
>>> > > > >  failed with exit code 1:
>>> > > > > | cat: 
>>> > > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
>>> > > > >  No such file or directory
>>> > > > > | WARNING: 
>>> > > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
>>> > > > >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
>>> > > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>>> > > > >
>>> > > > > At first, I thought this may be a dependency issue because I 
>>> > > > > inherit "rm_work" to tidy up; but I tried a build without it - i.e. 
>>> > > > > keeping all work around - and got the same failure.
>>> > > >
>>> > > > I've encountered a similar error just today when switching SDKMACHINE.
>>> > > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
>>> > > > just recently fixed a bug in archive.bbclass
>>> > > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
>>> > > > gcc-source raced with do_preconfigure and I'm wondering if it's
>>> > > > related
>>> > >
>>> > > I believe I have fixed this in
>>> > > https://lists.openembedded.org/g/openembedded-core/message/140161,
>>> > > please try it out to make sure it solves your issue as well.
>>> >
>>> > That patch came in after the 3.1.1 release, but it is present in the
>>> > dunfell branch so it will make it into 3.1.2
>>>
>>> Doh, I'm getting ahead of myself! I was thinking of another
>>> classes/archiver patch that Joshua sent :-)
>>>
>>> Steve
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49819): https://lists.yoctoproject.org/g/yocto/message/49819
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

[Joshua Watt]

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt  wrote:
>
> On Tue, Jun 30, 2020 at 4:56 PM MikeB  wrote:
> >
> > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a 
> > bug or just my problem.  I maintain five different architectures and all 
> > five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
> >
> > | cat: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> >  No such file or directory
> > | WARNING: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > | ERROR: Execution of 
> > '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
> >  failed with exit code 1:
> > | cat: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> >  No such file or directory
> > | WARNING: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> >
> > At first, I thought this may be a dependency issue because I inherit 
> > "rm_work" to tidy up; but I tried a build without it - i.e. keeping all 
> > work around - and got the same failure.
>
> I've encountered a similar error just today when switching SDKMACHINE.
> Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> just recently fixed a bug in archive.bbclass
> (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> gcc-source raced with do_preconfigure and I'm wondering if it's
> related

I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.

>
> >
> > I've attached the full error log.  Any troubleshooting advice would be 
> > appreciated. 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49801): https://lists.yoctoproject.org/g/yocto/message/49801
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

[Joshua Watt]

On Tue, Jun 30, 2020 at 4:56 PM MikeB  wrote:
>
> I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a 
> bug or just my problem.  I maintain five different architectures and all five 
> have the same failure in gcc-sanitizers as I'm trying to build the SDK.
>
> | cat: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
>  No such file or directory
> | WARNING: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
>  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> | ERROR: Execution of 
> '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
>  failed with exit code 1:
> | cat: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
>  No such file or directory
> | WARNING: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
>  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>
> At first, I thought this may be a dependency issue because I inherit 
> "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work 
> around - and got the same failure.

I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related

>
> I've attached the full error log.  Any troubleshooting advice would be 
> appreciated. 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49800): https://lists.yoctoproject.org/g/yocto/message/49800
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto][meta-mingw][PATCH] mingw-w64: Upgrade to 7.0.0

[Joshua Watt]

Signed-off-by: Joshua Watt 
---
 recipes-devtools/mingw-w64/mingw-w64.inc  | 3 +--
 ...-headers_6.0.0.bb => nativesdk-mingw-w64-headers_7.0.0.bb} | 4 
 ...-runtime_6.0.0.bb => nativesdk-mingw-w64-runtime_7.0.0.bb} | 0
 ...eads_6.0.0.bb => nativesdk-mingw-w64-winpthreads_7.0.0.bb} | 0
 4 files changed, 1 insertion(+), 6 deletions(-)
 rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-headers_6.0.0.bb => 
nativesdk-mingw-w64-headers_7.0.0.bb} (82%)
 rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-runtime_6.0.0.bb => 
nativesdk-mingw-w64-runtime_7.0.0.bb} (100%)
 rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-winpthreads_6.0.0.bb => 
nativesdk-mingw-w64-winpthreads_7.0.0.bb} (100%)

diff --git a/recipes-devtools/mingw-w64/mingw-w64.inc 
b/recipes-devtools/mingw-w64/mingw-w64.inc
index 8c68bcc..a435dea 100644
--- a/recipes-devtools/mingw-w64/mingw-w64.inc
+++ b/recipes-devtools/mingw-w64/mingw-w64.inc
@@ -5,8 +5,7 @@ COMPATIBLE_HOST = ".*-mingw.*"
 
 SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
 
-SRC_URI[md5sum] = "cf5673f6d689bb5e02863e6284cc3d03"
-SRC_URI[sha256sum] = 
"805e11101e26d7897fce7d49cbb140d7bac15f3e085a91e0001e80b2adaf48f0"
+SRC_URI[sha256sum] = 
"aa20dfff3596f08a7f427aab74315a6cb80c2b086b4a107ed35af02f9496b628"
 
 UPSTREAM_CHECK_URI = 
"http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/;
 UPSTREAM_CHECK_REGEX = "mingw-w64-v(?P(\d+[\.\-_]*)+)\.tar"
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
similarity index 82%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
index 58073d6..292d22b 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
@@ -10,10 +10,6 @@ inherit autotools nativesdk
 INHIBIT_DEFAULT_DEPS = "1"
 DEPENDS = ""
 
-PACKAGECONFIG ??= "secure-api"
-
-PACKAGECONFIG[secure-api] = "--enable-secure-api,--disable-secure-api"
-
 do_configure() {
oe_runconf
 }
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_6.0.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_6.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
diff --git 
a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_6.0.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_7.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_6.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_7.0.0.bb
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49790): https://lists.yoctoproject.org/g/yocto/message/49790
Mute This Topic: https://lists.yoctoproject.org/mt/75223283/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto Using BBMASK or BBFILES with multiconfig

[Joshua Watt]

On Fri, Jun 26, 2020 at 9:55 AM  wrote:
>
> Hi all,
>
> I'm working on a project using multiconfig, with Yocto version 2.6. I'd like 
> to enable or disable an entire layer, depending on which multiconfig is 
> selected. My initial thought is to use BBMASK, and mask out undesired layers 
> in a multiconfig conf file, but I'm having trouble getting this to work.
>
> For example, I have layers meta-vm0 and meta-vm1, and multiconfigs vm0 and 
> vm1. I want to mask the files from meta-vm1 when the vm0 configuration is 
> selected. So, I add to vm0.conf:
> BBMASK = "meta-vm0/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend"
> However, the file still is included in the build.
>
> If I add the same line to layer.conf instead, the file gets masked correctly. 
> Is there some syntax I am missing that's different between layer.conf and 
> multiconfig conf files? Also, is there a better way to accomplish this goal - 
> say by editing BBFILES directly in the multiconfig conf file?

Support for doing this was just recently added on master, and is due
to be released until the 3.2 release. If you need it on 2.6, you'll
have to backport it yourself. If you look on master for commits by me
(jpewhac...@gmail.com) you can find the relevant things to backport.


>
> Cheers,
> Scott
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49762): https://lists.yoctoproject.org/g/yocto/message/49762
Mute This Topic: https://lists.yoctoproject.org/mt/75125906/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] Use TF-A recipe from meta-arm

[Joshua Watt]

On 6/24/20 10:44 PM, Trevor Woerner wrote:

On Wed 2020-06-24 @ 11:30:57 PM, Trevor Woerner wrote:

On Fri 2020-06-12 @ 12:38:23 PM, Joshua Watt wrote:

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend 
b/recipes-bsp/u-boot/u-boot%.bbappend
index 401d649..042507d 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -7,8 +7,8 @@ do_compile_append_rock2-square () {
  
  ATF_DEPENDS ??= ""
  
-EXTRA_OEMAKE_append_rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31.elf"

-ATF_DEPENDS_rk3399 = "virtual/atf:do_deploy"
+EXTRA_OEMAKE_append_rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"

The space you've included at the start of the following string makes me stop
and double-check... did you mean to add an "_append" in the following symbol?


+ATF_DEPENDS_rk3399 = " virtual/trusted-firmware-a:do_deploy"

Ah… I should have read the next line before replying. I see you switched from
+= to .= and hence the space. A bit curious, though?


It prevents the recipe adding in an extra space to the task depends when 
the machine is not an rk3399, which helps the layer by YP 2.0 compatible



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49746): https://lists.yoctoproject.org/g/yocto/message/49746
Mute This Topic: https://lists.yoctoproject.org/mt/74844089/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-mingw]: Static libraries

[Joshua Watt]

Please "Reply-All" to keep the discussion on the mailing list

On 6/16/20 1:05 PM, Edgar Chaves wrote:

Hi, do you have thoughts about this?

My concern is that *-staticdev part of nativesdk-* providers is not 
deployed correctly.



nativesdk-*-staticdev packages shouldn't be included in the SDK. 
nativesdk- recipes are intended to run on the host where the SDK is 
extracted, and that SDK will be used to compile software for some 
target. The SDK isn't intended to be able to compile more software for 
running on the SDK host itself, so none of the development files for 
nativesdk recipes are included in SDK iteself.


Practically speaking, this means that the SDK will not include a package 
like nativesdk-curl-staticdev (which is used to build SDK host 
software), but it could include curl-staticdev (which is used by the SDK 
to build target software).





El mié., 3 jun. 2020 a las 19:37, Edgar Chaves (<mailto:edgarchv...@gmail.com>>) escribió:


OK. Let me correct it.

I believe the layer and recipes are missing some packaging,
therefore I'm missing /some/ .a libraries in the SDK.

Something like this: FILES_${PN} += " ${baselib_dir}"

El mar., 2 jun. 2020 a las 7:37, Joshua Watt
(mailto:jpewhac...@gmail.com>>) escribió:

CC'in the mailing list.

On 6/1/20 10:39 PM, Edgar Chaves wrote:

Hi

I want to ask about meta-mingw static libraries for Windows.
The thing is that I don't get ".lib" in the SDK. Do you have
any information about that?


meta-mingw is primarily intended to build and SDK that allows
you to cross compile for a Linux target from a Windows host,
so including the static libraries for the Windows portions
doesn't really make sense. I think there has been a little
discussions about making and SDK that cross compiles for
Windows, but I don't recall where that went.

Perhaps you can clarify what your use case is?




Thank you, I'd appreciate your answer.

—Edgar


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49653): https://lists.yoctoproject.org/g/yocto/message/49653
Mute This Topic: https://lists.yoctoproject.org/mt/74924298/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-rockchip][PATCH] wic: Use --offset and --fixed-size instead of --align and --size

[Joshua Watt]

The --align argument isn't intended to make a partition exist at a fixed
location like the Rockchip boot ROM requires. Use the recently added
--offset argument which will fail to build the image if the partition
can't be placed at the correct location. Also used --fixed-size to make
sure that Wic isn't inserting hidden padding that changes things around.

Finally, the location of the rootfs isn't required to be at sector
262144 since u-boot and the kernel reads the partition table to find it
and actually hasn't been at this location anyway since Wic has been
padding the /boot partition, so remove it's alignment requirements.

Signed-off-by: Joshua Watt 
---
 wic/firefly-rk3288.wks |  2 +-
 wic/rk3288-boot.wks| 14 +++---
 wic/rk3399-boot.wks| 14 +++---
 wic/rock-pi-4.wks  |  2 +-
 wic/tinker-board.wks   |  2 +-
 wic/vyasa-rk3288.wks   |  2 +-
 6 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/wic/firefly-rk3288.wks b/wic/firefly-rk3288.wks
index b60aa0e..da0067f 100644
--- a/wic/firefly-rk3288.wks
+++ b/wic/firefly-rk3288.wks
@@ -2,6 +2,6 @@
 # Released under the MIT license (see COPYING.MIT for the terms)
 
 include rk3288-boot.wks
-part / --align 131072 --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 
--label root
+part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
 
 bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw 
root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/rk3288-boot.wks b/wic/rk3288-boot.wks
index c0b7d95..e4d30cc 100644
--- a/wic/rk3288-boot.wks
+++ b/wic/rk3288-boot.wks
@@ -12,13 +12,13 @@
 #   loader2 16384   8192
 #   atf 24576   8192
 #   boot32768   229376
-#   root262144  -
+#   root262144  -   (suggested)
 #
 
-part loader1--align 32 --size 4000K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
-part reserved1  --align 4032   --size 64K  --ondisk 
${RK_BOOT_DEVICE}
-part reserved2  --align 4096   --size 4096K--ondisk 
${RK_BOOT_DEVICE}
-part loader2--align 8192   --size 4096K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.bin"
-part atf--align 12288  --size 4096K--ondisk 
${RK_BOOT_DEVICE}
-part /boot  --align 16384  --size=114688K --active --ondisk 
${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot 
--sourceparams="loader=u-boot"
+part loader1--offset 32 --fixed-size 4000K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1  --offset 4032   --fixed-size 64K  --ondisk 
${RK_BOOT_DEVICE}
+part reserved2  --offset 4096   --fixed-size 4096K--ondisk 
${RK_BOOT_DEVICE}
+part loader2--offset 8192   --fixed-size 4096K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.bin"
+part atf--offset 12288  --fixed-size 4096K--ondisk 
${RK_BOOT_DEVICE}
+part /boot  --offset 16384  --size   114688K --active --ondisk 
${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot 
--sourceparams="loader=u-boot"
 
diff --git a/wic/rk3399-boot.wks b/wic/rk3399-boot.wks
index 885d46b..8a65179 100644
--- a/wic/rk3399-boot.wks
+++ b/wic/rk3399-boot.wks
@@ -12,13 +12,13 @@
 #   loader2 16384   8192
 #   atf 24576   8192
 #   boot32768   229376
-#   root262144  -
+#   root262144  -   (suggested)
 #
 
-part loader1--align 32 --size 4000K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
-part reserved1  --align 4032   --size 64K  --ondisk 
${RK_BOOT_DEVICE}
-part reserved2  --align 4096   --size 4096K--ondisk 
${RK_BOOT_DEVICE}
-part loader2--align 8192   --size 4096K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.itb"
-part atf--align 12288  --size 4096K--ondisk 
${RK_BOOT_DEVICE}
-part /boot  --align 16384  --size=114688K --active --ondisk 
${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot 
--sourceparams="loader=u-boot"
+part loader1--offset 32 --fixed-size 4000K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1  --offset 4032   --fixed-size 64K  --ondisk 
${RK_BOOT_DEVICE}
+part reserved2  --offset 4096   --fixed-size 4096K--ondisk 
${RK_BOOT_DEVICE}
+part loader2--offset 8192   --fixed-size 4096K--ondisk 
${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.itb"
+part atf--offset 12288  --fixed-s

[yocto] [meta-rockchip][PATCH] Use TF-A recipe from meta-arm

[Joshua Watt]

Converts the build to pull the canonical TF-A recipe from meta-arm
instead of duplicating it in this layer.

Signed-off-by: Joshua Watt 
---
 README|  4 ++
 conf/layer.conf   |  2 +-
 conf/machine/include/rk3399.inc   |  5 +--
 .../arm-trusted-firmware_2.3.bb   | 43 ---
 .../trusted-firmware-a_%.bbappend |  6 +++
 recipes-bsp/u-boot/u-boot%.bbappend   |  6 +--
 6 files changed, 16 insertions(+), 50 deletions(-)
 delete mode 100644 recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.3.bb
 create mode 100644 recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend

diff --git a/README b/README
index a97b89e..e1cfe3e 100644
--- a/README
+++ b/README
@@ -11,6 +11,10 @@ Dependencies:
layers: meta
branch: matched branches (e.g. master, sumo, ...)
 
+   URI: git://git.yoctoproject.org/meta-arm
+   layers: meta-arm
+   branch: matched branches (e.g. master, sumo, ...)
+
 Status of supported boards:
 --
builds and boots wic image:
diff --git a/conf/layer.conf b/conf/layer.conf
index 72d5366..4168391 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,4 +15,4 @@ BBFILE_PRIORITY_rockchip = "1"
 # cause compatibility issues with other layers
 LAYERVERSION_rockchip = "1"
 LAYERSERIES_COMPAT_rockchip = "dunfell"
-LAYERDEPENDS_rockchip = "core"
+LAYERDEPENDS_rockchip = "core meta-arm"
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 1fd8fd6..4019988 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -13,9 +13,8 @@ KBUILD_DEFCONFIG ?= "defconfig"
 KERNEL_CLASSES = "kernel-fitimage"
 KERNEL_IMAGETYPE = "fitImage"
 
-ATF_PLATFORM ?= "rk3399"
-ATF_TARGET ?= "bl31"
-ATF_SUFFIX ?= "elf"
+TFA_PLATFORM = "rk3399"
+TFA_BUILD_TARGET = "bl31"
 
 UBOOT_SUFFIX ?= "itb"
 UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.3.bb 
b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.3.bb
deleted file mode 100644
index 8d36d66..000
--- a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.3.bb
+++ /dev/null
@@ -1,43 +0,0 @@
-# Copyright (C) 2019 Garmin Ltd. or its subsidaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-
-SUMMARY = "Arm Trusted Firmware"
-HOMEPAGE = "https://developer.trustedfirmware.org/;
-LICENSE = "BSD-3-Clause"
-LIC_FILES_CHKSUM = 
"file://docs/license.rst;md5=189505435dbcdcc8caa63c46fe93fa89"
-
-# Rockchip RK3399 compiles some M0 firmware which requires an arm-none-eabi GCC
-# toolchain
-DEPENDS_rk3399 = "virtual/arm-none-eabi-gcc"
-
-PROVIDES = "virtual/atf"
-
-BRANCH = "master"
-SRC_URI = 
"git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=http;branch=${BRANCH}
 \
-   "
-SRCREV = "8ff55a9e14a23d7c7f89f52465bcc6307850aa33"
-
-S = "${WORKDIR}/git"
-B = "${WORKDIR}/build"
-
-inherit deploy
-
-ATF_SUFFIX ??= "bin"
-
-do_compile() {
-unset LDFLAGS
-unset CFLAGS
-unset CPPFLAGS
-
-oe_runmake -C ${S} BUILD_BASE=${B} DEBUG=0 CROSS_COMPILE=${TARGET_PREFIX} \
-PLAT=${ATF_PLATFORM} ${ATF_TARGET}
-}
-
-PACKAGE_ARCH = "${MACHINE_ARCH}"
-
-do_deploy() {
-install -m 644 
${B}/${ATF_PLATFORM}/release/${ATF_TARGET}/${ATF_TARGET}.${ATF_SUFFIX} \
-${DEPLOYDIR}/${ATF_TARGET}.${ATF_SUFFIX}
-}
-addtask deploy after do_compile
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend 
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
new file mode 100644
index 000..ecde25d
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -0,0 +1,6 @@
+# Rockchip RK3399 compiles some M0 firmware which requires an arm-none-eabi GCC
+# toolchain
+DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc"
+
+COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
+
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend 
b/recipes-bsp/u-boot/u-boot%.bbappend
index 401d649..042507d 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -7,8 +7,8 @@ do_compile_append_rock2-square () {
 
 ATF_DEPENDS ??= ""
 
-EXTRA_OEMAKE_append_rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31.elf"
-ATF_DEPENDS_rk3399 = "virtual/atf:do_deploy"
+EXTRA_OEMAKE_append_rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
+ATF_DEPENDS_rk3399 = " virtual/trusted-firmware-a:do_deploy"
 
-do_compile[depends] += "${ATF_DEPENDS}"
+do_compile[depends] .= "${ATF_DEPENDS}"
 
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49633): https://lists.yoctoproject.org/g/yocto/message/49633
Mute This Topic: https://lists.yoctoproject.org/mt/74844089/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [WIC] Multiple WKS Files

[Joshua Watt]

On 5/4/20 11:14 AM, Rudolf J Streif wrote:



On 5/2/20 2:47 PM, Joshua Watt wrote:



On Sat, May 2, 2020, 1:22 PM Rudolf J Streif 
mailto:rudolf.str...@ibeeto.com>> wrote:


eMMC devices commonly have three hardware partitions: two boot
partitions and a user partition. I was looking for a convenient
way to
have wic build an image for the boot partition and one for the user
partition. However, that does not seem to be possible right out
of the
box. The variable WKS_FILE only accepts one file and not a list. The
class image_types_wic.bbclass uses WKS_FILES internally but that
seems
to be a search list and the code only builds the file it finds first.


I think part of the problem is that wks files are tied to a rootfs 
image, so it's not currently possible to have multiple because there 
is no way to differentiate them. Also because of that it's a little 
odd to have a wks file that doesn't reference the rootfs it's built with.


You might be able to do it by making a simple dummy image recipe for 
the boot partition(s), then overriding the WKS_FILE variable for the 
image with a pn override in the machine.conf file (e.g. 
WKS_FILE_pn-my-emmc-boot = "emmc-boot.wks" )


Thank you, Joshua. I might try your idea. I have noticed that it is 
tied to the rootfs as I tried to use ondisk/ondrive to create images 
for different partitions. But that did not work. Actually, the use of 
the ondisk/ondrive parameter is not entirely obvious to me (but I also 
have not dissected the code to figure it out).


I haven't used it a whole lot because of the way we provision our 
devices, but I think its mostly so that wic can create a valid fstab in 
the root file system that will mount all the partitions. This way, the 
root file system image can remain generic and work with different 
partitions layouts specified in the wks file.


It might be worthwhile looking into enhancing wic to be able to create 
multiple images. Devices now also use universal flash storage (UFS) 
which supports multiple logical disks like a SCSI drive once it is 
provisioned.


Yes, that would be really nice. I don't think that wic currently has any 
concept of "hardware partitions" (e.g. the emmc boot partitions or the 
UFS SCSI LUNs), just GPT/MBR partitions. I'm not sure how you would add 
support for it.






Is my understanding correct?

Any smart ideas to make this work?

Thanks,
Rudi







--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49331): https://lists.yoctoproject.org/g/yocto/message/49331
Mute This Topic: https://lists.yoctoproject.org/mt/73940589/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [WIC] Multiple WKS Files

[Joshua Watt]

On Sat, May 2, 2020, 1:22 PM Rudolf J Streif 
wrote:

> eMMC devices commonly have three hardware partitions: two boot
> partitions and a user partition. I was looking for a convenient way to
> have wic build an image for the boot partition and one for the user
> partition. However, that does not seem to be possible right out of the
> box. The variable WKS_FILE only accepts one file and not a list. The
> class image_types_wic.bbclass uses WKS_FILES internally but that seems
> to be a search list and the code only builds the file it finds first.


I think part of the problem is that wks files are tied to a rootfs image,
so it's not currently possible to have multiple because there is no way to
differentiate them. Also because of that it's a little odd to have a wks
file that doesn't reference the rootfs it's built with.

You might be able to do it by making a simple dummy image recipe for the
boot partition(s), then overriding the WKS_FILE variable for the image with
a pn override in the machine.conf file (e.g. WKS_FILE_pn-my-emmc-boot =
"emmc-boot.wks" )


> Is my understanding correct?
>
> Any smart ideas to make this work?
>
> Thanks,
> Rudi
>
>
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49312): https://lists.yoctoproject.org/g/yocto/message/49312
Mute This Topic: https://lists.yoctoproject.org/mt/73940589/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-rockchip][PATCH] arm-trusted-firmware: Upgrade 2.2 -> 2.3

[Joshua Watt]

Upgrades arm-trusted-firmware to the latest version, which fixes a bug
where the RK3399 would hang during a warm reboot

Signed-off-by: Joshua Watt 
---
 ...hip-Prevent-macro-expansion-in-paths.patch | 94 ---
 ...are_2.2.bb => arm-trusted-firmware_2.3.bb} |  3 +-
 2 files changed, 1 insertion(+), 96 deletions(-)
 delete mode 100644 
recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-rockchip-Prevent-macro-expansion-in-paths.patch
 rename recipes-bsp/arm-trusted-firmware/{arm-trusted-firmware_2.2.bb => 
arm-trusted-firmware_2.3.bb} (89%)

diff --git 
a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-rockchip-Prevent-macro-expansion-in-paths.patch
 
b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-rockchip-Prevent-macro-expansion-in-paths.patch
deleted file mode 100644
index 755b618..000
--- 
a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-rockchip-Prevent-macro-expansion-in-paths.patch
+++ /dev/null
@@ -1,94 +0,0 @@
-From 39a97dce61aca9f618e28e26c6e441c8976f3172 Mon Sep 17 00:00:00 2001
-From: Joshua Watt 
-Date: Fri, 13 Dec 2019 13:44:55 -0600
-Subject: [PATCH] rockchip: Prevent macro expansion in paths
-
-Instead of stringizing the paths to binary files, add them as string
-defines on the command line (e.g. -DFOO=\"BAR\" instead of -DFOO=BAR).
-This prevents macros from being expanded inside the string value itself.
-For example, -DFOO=/path/with-linux-in-it would have been expanded to
-"/path/with-1-in-it" because `linux=1` is one of the standard GCC
-defines.
-
-Upstream-Status: Accepted 
[https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2813]
-Change-Id: I7b65df3c9930faed4f1aff75ad726982ae3671e6
-Signed-off-by: Joshua Watt 

- plat/rockchip/rk3399/drivers/dp/cdn_dp.c  |  2 +-
- plat/rockchip/rk3399/drivers/pmu/pmu_fw.c | 24 +++
- plat/rockchip/rk3399/platform.mk  |  6 +++---
- 3 files changed, 15 insertions(+), 17 deletions(-)
-
-diff --git a/plat/rockchip/rk3399/drivers/dp/cdn_dp.c 
b/plat/rockchip/rk3399/drivers/dp/cdn_dp.c
-index aa71fdea..a8773f4f 100644
 a/plat/rockchip/rk3399/drivers/dp/cdn_dp.c
-+++ b/plat/rockchip/rk3399/drivers/dp/cdn_dp.c
-@@ -18,7 +18,7 @@ __asm__(
-   ".global hdcp_handler\n"
-   ".balign 4\n"
-   "hdcp_handler:\n"
--  ".incbin \"" __XSTRING(HDCPFW) "\"\n"
-+  ".incbin \"" HDCPFW "\"\n"
-   ".type hdcp_handler, %function\n"
-   ".size hdcp_handler, .- hdcp_handler\n"
-   ".popsection\n"
-diff --git a/plat/rockchip/rk3399/drivers/pmu/pmu_fw.c 
b/plat/rockchip/rk3399/drivers/pmu/pmu_fw.c
-index a09ad21e..25596b18 100644
 a/plat/rockchip/rk3399/drivers/pmu/pmu_fw.c
-+++ b/plat/rockchip/rk3399/drivers/pmu/pmu_fw.c
-@@ -5,20 +5,18 @@
-  */
- 
- /* convoluted way to make sure that the define is pasted just the right way */
--#define _INCBIN(file, sym, sec) \
-+#define INCBIN(file, sym, sec) \
-   __asm__( \
--  ".section " #sec "\n" \
--  ".global " #sym "\n" \
--  ".type " #sym ", %object\n" \
-+  ".section " sec "\n" \
-+  ".global " sym "\n" \
-+  ".type " sym ", %object\n" \
-   ".align 4\n" \
--  #sym ":\n" \
--  ".incbin \"" #file "\"\n" \
--  ".size " #sym ", .-" #sym "\n" \
--  ".global " #sym "_end\n" \
--  #sym "_end:\n" \
-+  sym ":\n" \
-+  ".incbin \"" file "\"\n" \
-+  ".size " sym ", .-" sym "\n" \
-+  ".global " sym "_end\n" \
-+  sym "_end:\n" \
-   )
- 
--#define INCBIN(file, sym, sec) _INCBIN(file, sym, sec)
--
--INCBIN(RK3399M0FW, rk3399m0_bin, ".sram.incbin");
--INCBIN(RK3399M0PMUFW, rk3399m0pmu_bin, ".pmusram.incbin");
-+INCBIN(RK3399M0FW, "rk3399m0_bin", ".sram.incbin");
-+INCBIN(RK3399M0PMUFW, "rk3399m0pmu_bin", ".pmusram.incbin");
-diff --git a/plat/rockchip/rk3399/platform.mk 
b/plat/rockchip/rk3399/platform.mk
-index cfc48e8f..643c24f5 100644
 a/plat/rockchip/rk3399/platform.mk
-+++ b/plat/rockchip/rk3399/platform.mk
-@@ -82,13 +82,13 @@ PLAT_M0 :=  ${PLAT}m0
- BUILD_M0  :=  ${BUILD_PLAT}/m0
- 
- RK3399M0FW=${BUILD_M0}/${PLAT_M0}.bin
--$(eval $(call add_define,RK3399M0FW))
-+$(eval $(call add_define_val,RK3399M0FW,\"$(RK3399M0FW)\"))
- 
- RK3399M0PMUFW=${BUILD_M0}/${PLAT_M0}pmu.bin
--$(eval $(call add_define,RK339

Re: [Yocto] Building Qt5 toolchain for windows

[Joshua Watt]

On 4/21/20 1:00 PM, d.fourdrign...@idplus.org.mx wrote:


Hello,

I’m working on a project and I need to build a Qt5 toolchain for Windows,

I’m using meta-qt5 and meta-mingw and my build machine is an ubuntu 18.04

However I keep having errors when i execute « bitbake 
meta-toolchain-qt5 », very much like the one in below forum thread


https://www.yoctoproject.org/pipermail/yocto/2019-March/044512.html

Am I doing something wrong ? Could you help sending me some ideas on 
how I could accomplish what I want ?




I don't actually know a whole lot about cmake/qt5, so I'm not sure what 
would need to be done (other than what I've already stated in the 
message above). Samuli Piippo (cc'd) recently did some work to get cmake 
to build for MinGW, so he might have some insight.



Thanks,

Best regards,

David Fourdrigniez.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49198): https://lists.yoctoproject.org/g/yocto/message/49198
Mute This Topic: https://lists.yoctoproject.org/mt/73179276/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core

[Joshua Watt]

On 4/14/20 10:48 AM, Khem Raj wrote:

On Tue, Apr 14, 2020 at 6:32 AM Joshua Watt  wrote:

Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.

Signed-off-by: Joshua Watt 
---
  conf/machine/include/rk3288.inc   |  2 +-
  conf/machine/include/rockchip-defaults.inc|  3 +-
  ...-cfg-Allow-specification-of-ncurses-.patch | 51 ---
  recipes-kernel/linux/linux-longterm_4.19.bb   |  9 
  recipes-kernel/linux/linux-longterm_5.4.bb|  7 ---
  recipes-kernel/linux/linux-mainline_5.6.bb|  9 
  recipes-kernel/linux/linux-mutual.inc | 18 ---
  recipes-kernel/linux/linux-stable_5.5.bb  |  7 ---
  ...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++
  recipes-kernel/linux/linux-yocto_%.bbappend   |  2 +
  recipes-kernel/linux/linux-yocto_5.4.bbappend |  5 ++
  11 files changed, 41 insertions(+), 103 deletions(-)
  delete mode 100644 
recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
  delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
  delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
  delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
  delete mode 100644 recipes-kernel/linux/linux-mutual.inc
  delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
  create mode 100644 
recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
  create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
  create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend


I think another solution could be to use yocto kernel tooling but
point to mainline kernels much like what meta-meson [1] is doing
this will let you keep bumping to latest releases from mainline, this
approach is used by many other BSPs

[1] 
https://github.com/superna/meta-meson/blob/master/recipes-kernel/linux/linux-yocto-meson64_5.4.bb


My goal here was to minimize the maintenance required for this BSP layer 
to get newer kernels. Using the linux-yocto kernel in OE-core is quite 
simple (as this patch shows) and allows us to piggyback off of Bruce's 
work to keep everything up to date. While it is possible that OE-core 
accidentally breaks something in this layer with a kernel update, it 
seems likely this would be pretty rare and would probably require less 
overall work than maintaining our own kernel recipes, particularly for 
the set of boards in this BSP which have really good and stable support 
in the kernel.



I think it should be possible to easily track the upstream vanilla 
kernel branches in the linux-yocto recipe, and Bruce has done some work 
to make this easier, but I think there might need to be little more work 
in that area before it's completely ready to go.



diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
  require conf/machine/include/soc-family.inc
  require conf/machine/include/rockchip-defaults.inc

-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
  KERNEL_IMAGETYPE = "zImage"

  SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc 
b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
  # meta-rockchip default settings

  # kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
  LINUX_VERSION_EXTENSION ?= "-rockchip"

  # xserver
diff --git 
a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
 
b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..000
--- 
a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield 
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-In some cross build environments such as the Yocto Project build
-environment it provides an ncurses library that is compiled
-differently than the host's version.  This causes display corruption
-problems when the host's curses includes are used instead of the
-includes from the provided compiler are overridden.  There is a second
-case where there is no curses libraries at all on the host system and
-menuconfig will just fail entirely.
-
-The solution is simply to allow an override va

[yocto] [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core

[Joshua Watt]

Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.

Signed-off-by: Joshua Watt 
---
 conf/machine/include/rk3288.inc   |  2 +-
 conf/machine/include/rockchip-defaults.inc|  3 +-
 ...-cfg-Allow-specification-of-ncurses-.patch | 51 ---
 recipes-kernel/linux/linux-longterm_4.19.bb   |  9 
 recipes-kernel/linux/linux-longterm_5.4.bb|  7 ---
 recipes-kernel/linux/linux-mainline_5.6.bb|  9 
 recipes-kernel/linux/linux-mutual.inc | 18 ---
 recipes-kernel/linux/linux-stable_5.5.bb  |  7 ---
 ...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++
 recipes-kernel/linux/linux-yocto_%.bbappend   |  2 +
 recipes-kernel/linux/linux-yocto_5.4.bbappend |  5 ++
 11 files changed, 41 insertions(+), 103 deletions(-)
 delete mode 100644 
recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
 delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
 delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
 delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
 delete mode 100644 recipes-kernel/linux/linux-mutual.inc
 delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
 create mode 100644 
recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
 create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
 create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend

diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
 require conf/machine/include/soc-family.inc
 require conf/machine/include/rockchip-defaults.inc
 
-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
 KERNEL_IMAGETYPE = "zImage"
 
 SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc 
b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
 # meta-rockchip default settings
 
 # kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
 LINUX_VERSION_EXTENSION ?= "-rockchip"
 
 # xserver
diff --git 
a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
 
b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..000
--- 
a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield 
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-In some cross build environments such as the Yocto Project build
-environment it provides an ncurses library that is compiled
-differently than the host's version.  This causes display corruption
-problems when the host's curses includes are used instead of the
-includes from the provided compiler are overridden.  There is a second
-case where there is no curses libraries at all on the host system and
-menuconfig will just fail entirely.
-
-The solution is simply to allow an override variable in
-check-lxdialog.sh for environments such as the Yocto Project.  Adding
-a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
-compiling and linking against the right headers and libraries.
-
-Signed-off-by: Jason Wessel 
-cc: Michal Marek 
-cc: linux-kbu...@vger.kernel.org
-Signed-off-by: Bruce Ashfield 

- scripts/kconfig/mconf-cfg.sh | 8 
- 1 file changed, 8 insertions(+)
- mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh
-
-diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
-old mode 100755
-new mode 100644
-index c812872d7f9d..65a9b9e5b8a6
 a/scripts/kconfig/mconf-cfg.sh
-+++ b/scripts/kconfig/mconf-cfg.sh
-@@ -4,6 +4,14 @@
- PKG="ncursesw"
- PKG2="ncurses"
- 
-+if [ "$CROSS_CURSES_LIB" != "" ]; then
-+echo libs=\'$CROSS_CURSES_LIB\'
-+if [ x"$CROSS_CURSES_INC" != x ]; then
-+  echo cflags=\'$CROSS_CURSES_INC\'
-+fi
-+exit 0
-+fi
-+
- if [ -n "$(command -v pkg-config)" ]; then
-   if pkg-config --exists $PKG; then
-   echo cflags=\"$(pkg-config --cflags $PKG)\"
--- 
-2.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb 
b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0

Re: [yocto] sstate causing stripped kernel vs symbols mismatch

[Joshua Watt]

On Thu, Apr 9, 2020, 12:52 PM Bruce Ashfield 
wrote:

> On Thu, Apr 9, 2020 at 1:21 PM Sean McKay  wrote:
> >
> > I don’t know offhand, but the kernel documentation seems relatively
> straightforward.
> >
> > I can start investigating in that direction and see how complex it looks
> like it’s going to be.
> >
>
> I can tweak linux-yocto in the direction of reproducibility without
> much trouble (for the build part). But I'm a bit out of my normal flow
> for testing that it really is reproducible. So if anyone can point me
> at what they are running to currently test that .. I can do the build
> part.
>

Reproducible builds are part of the standard OE QA tests. You can run them
with:

 oe-selftest -r reproducible

It currently tests core-image-sato, which I thought would cover the kernel,
so I'm a little surprised it's not. Anyway, you can easily modify the
reporducible.py test file to build whatever you want, since doing the full
core-image-sato build can be pretty slow


> Bruce
>
> >
> >
> > When you say that reproducible builds are turned on by default, is there
> a flag somewhere that can be used to turn that off that I need to gate
> these changes behind? Or can they be made globally so that the
> reproducibility can’t be turned off (easily)?
> >
> >
> >
> >
> >
> > Do we expect to generally be okay with letting this sort of race
> condition remain in sstate? I concede that it’s probably okay, since I
> think the kernel is the only thing with this kind of forking task tree
> behavior after do_compile, and if we get 100% reproducible builds working,
> it’s not overly relevant… but it seems like it probably deserves a warning
> somewhere in the documentation.
> >
> >
> >
> > I can also bring this question to the next technical meeting (I know I
> just missed one) if it seems the sort of thing we need to get consensus.
> >
> >
> >
> > Cheers!
> >
> > -Sean
> >
> >
> >
> >
> >
> >
> >
> > From: Joshua Watt 
> > Sent: Thursday, April 9, 2020 10:00 AM
> > To: McKay, Sean ; yocto@lists.yoctoproject.org
> > Subject: Re: [yocto] sstate causing stripped kernel vs symbols mismatch
> >
> >
> >
> >
> >
> > On 4/9/20 11:42 AM, Sean McKay wrote:
> >
> > Anyone have any thoughts or guidance on this?
> >
> > It seems like a pretty major bug to me.
> >
> >
> >
> > We’re willing to put the work in to fix it, and if it’s not something
> the upstream community is interested in, I’ll just pick a solution for us
> and go with it.
> >
> > But if it’s something that we’d like me to upstream, I’d like some
> feedback on which path I should start walking down before I start taking
> things apart.
> >
> >
> >
> > We have had a recent push for reproducible builds (and they are now
> enabled by default). Do you have any idea how much effort it would take to
> make the kernel build reproducibly? It's something we probably want anyway,
> and can add to the automated testing infrastructure to ensure it doesn't
> regress.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Cheers!
> >
> > -Sean
> >
> >
> >
> > From: yocto@lists.yoctoproject.org  On
> Behalf Of Sean McKay
> > Sent: Tuesday, April 7, 2020 12:03 PM
> > To: yocto@lists.yoctoproject.org
> > Subject: [yocto] sstate causing stripped kernel vs symbols mismatch
> >
> >
> >
> > Hi all,
> >
> >
> >
> > We’ve discovered that (quite frequently) the kernel that we deploy
> doesn’t match the unstripped one that we’re saving for debug symbols. I’ve
> traced the issue to a combination of an sstate miss for the kernel
> do_deploy step combined with an sstate hit for do_package_write_rpm. (side
> note: we know we have issues with sstate reuse/stamps including things they
> shouldn’t which is why we hit this so much. We’re working on that too)
> >
> >
> >
> > The result is that when our debug rootfs is created (where we added the
> kernel symbols), it’s got the version of the kernel from the sstate cached
> rpm files, but since do_deploy had an sstate miss, the entire kernel gets
> rebuilt to satisfy that dependency chain. Since the kernel doesn’t have
> reproducible builds working, the resulting pair of kernels don’t match each
> other for debug purposes.
> >
> >
> >
> > So, I have two questions to start:
> >
> > What is the recommended way to be getting debug symbols for the kernel,
> since do_deploy doesn’t seem to have a debug 

Re: [yocto] sstate causing stripped kernel vs symbols mismatch

[Joshua Watt]

On 4/9/20 11:42 AM, Sean McKay wrote:


Anyone have any thoughts or guidance on this?

It seems like a pretty major bug to me.

We’re willing to put the work in to fix it, and if it’s not something 
the upstream community is interested in, I’ll just pick a solution for 
us and go with it.


But if it’s something that we’d like me to upstream, I’d like some 
feedback on which path I should start walking down before I start 
taking things apart.




We have had a recent push for reproducible builds (and they are now 
enabled by default). Do you have any idea how much effort it would take 
to make the kernel build reproducibly? It's something we probably want 
anyway, and can add to the automated testing infrastructure to ensure it 
doesn't regress.






Cheers!

-Sean

*From:* yocto@lists.yoctoproject.org  
*On Behalf Of *Sean McKay

*Sent:* Tuesday, April 7, 2020 12:03 PM
*To:* yocto@lists.yoctoproject.org
*Subject:* [yocto] sstate causing stripped kernel vs symbols mismatch

Hi all,

We’ve discovered that (quite frequently) the kernel that we deploy 
doesn’t match the unstripped one that we’re saving for debug symbols. 
I’ve traced the issue to a combination of an sstate miss for the 
kernel do_deploy step combined with an sstate hit for 
do_package_write_rpm. (side note: we know we have issues with sstate 
reuse/stamps including things they shouldn’t which is why we hit this 
so much. We’re working on that too)


The result is that when our debug rootfs is created (where we added 
the kernel symbols), it’s got the version of the kernel from the 
sstate cached rpm files, but since do_deploy had an sstate miss, the 
entire kernel gets rebuilt to satisfy that dependency chain. Since the 
kernel doesn’t have reproducible builds working, the resulting pair of 
kernels don’t match each other for debug purposes.


So, I have two questions to start:

 1. What is the recommended way to be getting debug symbols for the
kernel, since do_deploy doesn’t seem to have a debug counterpart
(which is why we originally just set things up to add the rpm to
the generated debug rootfs)
 2. Does this seem like a bug that should be fixed? If so, what would
be the recommended solution (more thoughts below)?

Even if there’s a task somewhere that does what I’m looking for, this 
seems like a bit of a bug. I generally feel like we want to be able to 
trust sstate, so the fact that forking dependencies that each generate 
their own sstate objects can be out of sync is a bit scary.


I’ve thought of several ways around this, but I can’t say I like any 
of them.


  * (extremely gross hack) Create a new task to use instead of
do_deploy that depends on do_packagegroup_write_rpm. Unpack the
restored (or built) RPMs and use those blobs to deploy the kernel
and symbols to the image directory.
  * (gross hack with painful effects on build time) Disable sstate for
do_package_write_rpm and do_deploy. Possibly replace with sstate
logic for the kernel’s do_install step (side question – why
doesn’t do_install generate sstate? It seems like it should be
able to, since the point is to drop everything into the image
directory)
  * (possibly better, but sounds hard) Change the sstate logic so that
if anything downstream of a do_compile task needs to be rerun,
/everything/ downstream of it needs to be rerun and sstate reuse
for that recipe is not allowed (basically all or nothing sstate).
Maybe with a flag that’s allowed in the bitbake file to indicate
that a recipe /does/ have reproducible builds and that different
pieces are allowed to come from sstate in that case.
  * (fix the symptoms but not the problem) Figure out how to get
linux-yocto building in a reproducible fashion and pretend the
problem doesn’t exist.

If you’re interested, this is quite easy to reproduce – these are my 
repro steps


  * Check out a clean copy of zeus (22.0.2)
  * Add kernel-image to core-image-minimal in whatever fashion you
choose (I just dumped it in the RDEPENDS for
packagegroup-core-boot for testing)
  * bitbake core-image-minimal
  * bitbake -c clean core-image-minimal linux-yocto (or just wipe your
whole build dir, since everything should come from sstate now)
  * Delete the sstate object(s) for linux-yocto’s deploy task.
  * bitbake core-image-minimal
  * Compare the BuildID hashes for the kernel in the two locations
using file (you’ll need to use the kernel’s extract-vmlinux script
to get it out of the bzImage)
  o file

tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/boot/vmlinux-5.2.28-yocto-standard
  o ./tmp/work-shared/qemux86-64/kernel-source/scripts/extract-vmlinux
tmp/deploy/images/qemux86-64/bzImage > vmlinux-deploy && file
vmlinux-deploy

Anyone have thoughts or suggestions?

Cheers!

-Sean McKay



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online 

Re: [yocto][meta-spdxscanner][PATCH V2] Remove redundant code.

[Joshua Watt]

On 4/2/20 11:45 AM, Li, Xiaoming wrote:

FOLDER_ID has already been assigned a defalut value "1", so there is no
need add 'or "1"' here.

Signed-off-by: Li Xiaoming 
---
  classes/fossology-rest.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/fossology-rest.bbclass b/classes/fossology-rest.bbclass
index 5c5ef70..69f4998 100644
--- a/classes/fossology-rest.bbclass
+++ b/classes/fossology-rest.bbclass
@@ -230,7 +230,7 @@ def get_folder_id(d):
  folder_name = d.getVar('FOLDER_NAME')
  folder_id = create_folder(d, folder_name)
  else:
-folder_id = (d.getVar('FOLDER_ID', True) or "1")
+folder_id = d.getVar('FOLDER_ID', False)


You probably shouldn't be disabling variable expansion here (i.e. 
passing False as the second argument)?


  
  bb.note("Folder Id =  " + str(folder_id))

  return str(folder_id)


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49037): https://lists.yoctoproject.org/g/yocto/message/49037
Mute This Topic: https://lists.yoctoproject.org/mt/72720682/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-