[yocto] [meta-gplv2] [PATCH] coreutils_6.9.bb: Fix build with glibc 2.34

[Khem Raj]

Signed-off-by: Khem Raj 
---
 ...-includes-for-glibc-2.34-portability.patch | 39 +++
 recipes-core/coreutils/coreutils_6.9.bb   |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch

diff --git 
a/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
 
b/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
new file mode 100644
index 000..0d9b5e2
--- /dev/null
+++ 
b/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
@@ -0,0 +1,39 @@
+From e241a55767c4eaac7d14c412d880037cb6d2ee33 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 29 Jun 2021 22:43:16 -0700
+Subject: [PATCH] sort.c: Reorder includes for glibc 2.34 portability
+
+With glibc 2.34 config.h will include stdlib.h and that would disable
+sys/wait.h to include needed definitions from bits/waitflags.h since
+_STDLIB_H would have been defined already and sys/wait.h would think
+these paths are included already, this is fixed with newer gnulib and
+configure so this is to get this old version to compile with latest
+glibc headers
+
+Upstream-Status: Inappropriate [OE-Specific]
+Signed-off-by: Khem Raj 
+---
+ src/sort.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/sort.c b/src/sort.c
+index 58ca66a..48b22c8 100644
+--- a/src/sort.c
 b/src/sort.c
+@@ -21,11 +21,11 @@
+ 
+Ørn E. Hansen added NLS support in 1997.  */
+ 
++#include 
++#include 
+ #include 
+ 
+ #include 
+-#include 
+-#include 
+ #include 
+ #include "system.h"
+ #include "argmatch.h"
+-- 
+2.32.0
+
diff --git a/recipes-core/coreutils/coreutils_6.9.bb 
b/recipes-core/coreutils/coreutils_6.9.bb
index 42b4f3c..69e5489 100644
--- a/recipes-core/coreutils/coreutils_6.9.bb
+++ b/recipes-core/coreutils/coreutils_6.9.bb
@@ -27,6 +27,7 @@ SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.bz2 \
file://no-man.patch \
file://build-don-t-need-charset.alias-when-building-for-mus.patch \
file://no-su.patch \
+   
file://0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch \
"
 
 SRC_URI[md5sum] = "c9607d8495f16e98906e7ed2d9751a06"
-- 
2.32.0


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

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

[Zoran]

Hello to everyone,

Mguentner fixed the cmake issue:
https://github.com/mguentner/cannelloni/issues/35

With this patch:
https://github.com/mguentner/cannelloni/commit/125a7c72e4bcbbf580aeb6ee03e25ed0540be217

So I also reinstated the old cannelloni recipe with:
https://github.com/ZoranStojsavljevic/meta-socketcan/commit/b79e35425b72ba1caf90404a953235a43202e16f

Zee
___

On Fri, May 21, 2021 at 7:55 AM Zoran via lists.yoctoproject.org
 wrote:
>
> Hello Joel,
>
> Thank you for the tips. Really helpful, appreciated very much.
>
> I spent some time this morning investigating this issue, and to find
> the culprit.
>
> Here are my findings, which resulted in a cannelloni.bb recipe change
> (according to what you wrote).
>
> The fix submitted is in recipe:
> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb
>
> The last cannelloni version which works is:
> https://github.com/mguentner/cannelloni/commit/0bd7e27db35bdef361226882ae04205504f7b2f4
>
> The culprit introducing the cmake errors is this one:
> https://github.com/mguentner/cannelloni/commit/d01dd1dc745914d129b1f4da2074e282253246af
>
> And, the issue recorded with Maximilian Guentner's cannelloni repo:
> https://github.com/mguentner/cannelloni/issues/35
>
> Thank you again,
> Zoran
> ___
>
> On Thu, May 20, 2021 at 4:48 PM Joel Winarske  wrote:
> >
> > Hi Zoran,
> >
> > Your cannelloni recipe is set to autorev, meaning it's not locked to a 
> > commit.  So when something changes upstream you have to manage it.
> >
> > Chances are Canelloni introduced a CMake change which is overwriting 
> > (opposed to appending) one or more variables required for cross compiling.  
> > Perhaps try to cross compile (not a host build) Canelloni by itself without 
> > Yocto involved.  Once that's sorted, then reintroduce yocto.
> >
> >
> > Joel
> >
> >
> > On Thu, May 20, 2021, 6:58 AM Zoran  wrote:
> >>
> >> Hello Yocto developers,
> >>
> >> I have few problems running the following self proprietary script from
> >> one of my public git repos:
> >> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh
> >>
> >> I recall that last time I used the script (I used then Fedora 31), the
> >> ./yocto setup dunfell worked seamlessly, did setup the environment,
> >> and upon bitbake -k core-image-minimal completed the tasks without any
> >> problem.
> >>
> >> Now, I am using Fedora 33 (in the meantime I did two Fedora version 
> >> upgrades).
> >>
> >> The problem is that while compiling the cannelloni package, the
> >> following errors were issued (please, look into the attached file
> >> cmake_problem.txt).
> >>
> >> This cmake problem was introduced after switching from Fedora 31 to Fedora 
> >> 33 ?!
> >>
> >> Any clue/idea why this is happening??? What is the cause of the problem?
> >>
> >> Thank you,
> >> Zoran
> >> ___
> >>
> >>
> >>
>
> 
>

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

[yocto] [meta-openssl102-fips][PATCH] openssh: refresh patches for 8.6p1

[Yi Zhao]

Refresh patches:
  0001-openssh-8.6p1-fips.patch
  0001-conditional-enable-fips-mode.patch

Signed-off-by: Yi Zhao 
---
 .../0001-conditional-enable-fips-mode.patch   | 38 +++--
 ...ps.patch => 0001-openssh-8.6p1-fips.patch} | 55 ++-
 recipes-connectivity/openssh/openssh_fips.inc |  2 +-
 3 files changed, 50 insertions(+), 45 deletions(-)
 rename recipes-connectivity/openssh/openssh/{0001-openssh-8.4p1-fips.patch => 
0001-openssh-8.6p1-fips.patch} (92%)

diff --git 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
index 9fd19c0..9bec7d7 100644
--- 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
+++ 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -1,4 +1,4 @@
-From 4de317391522186c6ae24a8d6d7d7add2673 Mon Sep 17 00:00:00 2001
+From 1696484c2a06e2ec095d748d2155eb8206dd850b Mon Sep 17 00:00:00 2001
 From: Hongxu Jia 
 Date: Sat, 21 Dec 2019 13:03:23 +0800
 Subject: [PATCH] conditional enable fips mode
@@ -14,11 +14,12 @@ The ssh_malloc_init function is removed in openssh 8.1p1, 
we need to
 insert ssh_enable_fips_mode function to main function for all
 applications.
 
+Rebase to 8.6p1
 Signed-off-by: Yi Zhao 
 ---
  sftp-server-main.c  |  1 +
  sftp-server.c   |  1 +
- sftp.c  |  1 +
+ sftp.c  |  2 ++
  ssh-add.c   |  1 +
  ssh-agent.c |  1 +
  ssh-keygen.c|  1 +
@@ -29,7 +30,7 @@ Signed-off-by: Yi Zhao 
  sshd.c  |  1 +
  xmalloc.c   | 20 
  xmalloc.h   |  1 +
- 13 files changed, 32 insertions(+)
+ 13 files changed, 33 insertions(+)
 
 diff --git a/sftp-server-main.c b/sftp-server-main.c
 index 06566d3..a10566d 100644
@@ -44,10 +45,10 @@ index 06566d3..a10566d 100644
sanitise_stdfd();
  
 diff --git a/sftp-server.c b/sftp-server.c
-index 7300900..42da9d7 100644
+index 838f048..8a8d87b 100644
 --- a/sftp-server.c
 +++ b/sftp-server.c
-@@ -1616,6 +1616,7 @@ sftp_server_main(int argc, char **argv, struct passwd 
*user_pw)
+@@ -1656,6 +1656,7 @@ sftp_server_main(int argc, char **argv, struct passwd 
*user_pw)
extern char *optarg;
extern char *__progname;
  
@@ -56,19 +57,20 @@ index 7300900..42da9d7 100644
log_init(__progname, log_level, log_facility, log_stderr);
  
 diff --git a/sftp.c b/sftp.c
-index fb3c08d..85b9b67 100644
+index 3f46c55..e9c8f1d 100644
 --- a/sftp.c
 +++ b/sftp.c
-@@ -2345,6 +2345,7 @@ main(int argc, char **argv)
-   size_t num_requests = DEFAULT_NUM_REQUESTS;
+@@ -2342,6 +2342,8 @@ main(int argc, char **argv)
+   size_t num_requests = 0;
long long limit_kbps = 0;
  
 +  ssh_enable_fips_mode();
++
/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
sanitise_stdfd();
msetlocale();
 diff --git a/ssh-add.c b/ssh-add.c
-index 7edb9f9..c75f85b 100644
+index 92192fc..4ed14cd 100644
 --- a/ssh-add.c
 +++ b/ssh-add.c
 @@ -667,6 +667,7 @@ main(int argc, char **argv)
@@ -80,7 +82,7 @@ index 7edb9f9..c75f85b 100644
sanitise_stdfd();
  
 diff --git a/ssh-agent.c b/ssh-agent.c
-index 58fe6dd..9018a7c 100644
+index 48a47d4..8a0d7a2 100644
 --- a/ssh-agent.c
 +++ b/ssh-agent.c
 @@ -1388,6 +1388,7 @@ main(int ac, char **av)
@@ -92,7 +94,7 @@ index 58fe6dd..9018a7c 100644
sanitise_stdfd();
  
 diff --git a/ssh-keygen.c b/ssh-keygen.c
-index 6451584..246caa1 100644
+index fc73943..cdb45a9 100644
 --- a/ssh-keygen.c
 +++ b/ssh-keygen.c
 @@ -3153,6 +3153,7 @@ main(int argc, char **argv)
@@ -140,7 +142,7 @@ index a9a6fe3..3c76f70 100644
seed_rng();
TAILQ_INIT(_keylist);
 diff --git a/ssh.c b/ssh.c
-index 729d87a..ab78b53 100644
+index a6e7642..8f91534 100644
 --- a/ssh.c
 +++ b/ssh.c
 @@ -650,6 +650,7 @@ main(int ac, char **av)
@@ -152,10 +154,10 @@ index 729d87a..ab78b53 100644
sanitise_stdfd();
  
 diff --git a/sshd.c b/sshd.c
-index fee4703..07faf7b 100644
+index b2ab001..8112d2c 100644
 --- a/sshd.c
 +++ b/sshd.c
-@@ -1534,6 +1534,7 @@ main(int ac, char **av)
+@@ -1535,6 +1535,7 @@ main(int ac, char **av)
Authctxt *authctxt;
struct connection_info *connection_info = NULL;
  
@@ -199,13 +201,13 @@ index b48d33b..456a063 100644
 +}
 +}
 diff --git a/xmalloc.h b/xmalloc.h
-index abaf7ad..b3b1c8c 100644
+index a6b8d23..18fe756 100644
 --- a/xmalloc.h
 +++ b/xmalloc.h
-@@ -26,3 +26,4 @@ int   xasprintf(char **, const char *, ...)
- __attribute__((__nonnull__ (2)));
+@@ -25,3 +25,4 @@ int   xasprintf(char **, const char *, ...)
+ __attribute__((__format__ (printf, 2, 3))) __attribute__((__nonnull__ 
(2)));
  intxvasprintf(char **, const char *, va_list)
-   __attribute__((__nonnull__ (2)));
+ __attribute__((__nonnull__ (2)));
 +void  ssh_enable_fips_mode(void);
 -- 
 2.17.1
diff --git 

[linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx]: update kernel with NXP pre-released SDK bsp30 v5.10 patches

[Zhantao Tang]

Hi Bruce,


There are 828 patches from NXP pre-released SDK bsp30 v5.10 kernel tree, and 
for this update,
a new branch v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx based on 
v5.10/standard/base shoule be created,
and all the patches are applied to the new branch, the patches infos as 
following:

The following changes since commit 
139fe7d68413054f850e206ab749f97a968867a8:

  rcu: Fix stall-warning deadlock due to non-release of rcu_node ->lock 
(2021-06-25 20:05:02 -0400)

are available in the Git repository at:

  https://github.com/zhantaotang/linux-yocto-std 
v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx

for you to fetch changes up to 4c7e068410164425fc262dc97646767a9487212a:

  doc: s32gen1: mc_rgm: Add fsl,s32gen1-mc_rgm.yaml documentation file 
(2021-06-29 14:01:40 +0800)



Would you please help to create the new branch

v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx based on v5.10/standard/base

and merge the patches into the above new created branch 
v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx?


Thanks,
Zhantao


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

[yocto] Yocto Technical Team Minutes, Engineering Sync, for June 29 2021

[Trevor Woerner]

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

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

== attendees ==
Trevor Woerner, Stephen Jolley, Steve Sakoman, Joshua Watt, Jon Mason, Tony
Tascioglu, Richard Purdie, Scott Murray, Armin Kuster, Paul Barker, Tim
Orling, Alejandro H, Bruce Ashfield, Randy MacLeod, Denys Dmytriyenko

== notes ==
- 3.1.9 (dunfell) through QA awaiting release approval, no blockers
- 3.4 m1 (honister) released
- identified an RCU stall hang that’s been causing some of our AB-INT issues. 
closed a couple of AB-INT bugs as a result, but found some more
- prserv rewrite using asyncio is stuck on AB hangs when tested on larger scale
- ARM-specific ltp hang issue (bug 14460, 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14460)
- multiconfig needs simpler test cases
- about 50% of AB issues are ptest-related

== general ==
RP: the RCU fix is awesome, significantly fixed AB-INT issues


PaulB: (summary) prserv code updated to asycio, it works for me on my home
machine, but then we see failures when that code is run on the AB. bitbake
hangs, probably in the shutdown path. i have been able to reproduce it
at home. works with python3.6 but seems to fail with python3.8 (from
buildtools). we’re using asyncio and multiprocessing in various modules
and it’s unclear how well they play together. there might be issues wrt
to which system gets initiated first and when forking occurs
JPEW: buildtools tarball only?
PaulB: i need to check the matrix of what’s running native vs what’s from
the buildtools
JPEW: you’re mixing asyncio and multiprocessing?
PaulB: yes
JPEW: doesn’t that do a fork/exec itself? just to be clear: you’re
init’ing asyncio first, then forking?
PaulB: yes, that’s what other parts of the code are doing too. maybe we
should fork first, then call start_tcp_server(), then start the asyncio?
JPEW: server or client?
PaulB: server, but that’s in bitbake. there’s no clear docs on how these
things would work together
JPEW: the AB uses hash equiv server but it’s running on its own, so i’m
not sure what code paths are used
PaulB: yes, RP and i discussed that and we know that code path is not being
used
JPEW: so what happens? what are you seeing?
PaulB: it gets so far through the test suite then the bitbake server stops.
we see the keepalive messages but no other output. RP got stuff installed
and did some dumps. it looks to be prserver-export functionality related.
bitbake is finished and is run successfully, but stalled in tring to
shutdown bitbake 
RP: for example in one case we saw 57 zombie threads, the 58th is stuck in
a client side asyncio call to prserv. we tried killing the prserv, so
we’re not sure if it’s hung. then we found it waiting on the socket
(which was already closed)
PaulB: and if we sent sigint to the process, it’s not waiting
RP: we had backtrace issues which we’ve fixed. but there’s this hang. some
tests failed early with python3.8, but then an oeselftest failed. one of
the parsers was stuck in this prserv call
PaulB: we should take a look through prserv.bbclass to see what’s also done.
we could look at the args used and check for parse completed events
RP: hashserv vs prserv: hashserv is called in its own context but prserv is
called from within the parser threads
PaulB: yes, back to the issue of the init-vs-fork timing
JPEW: i would expect that’s an issue. have them init in each thread. are
they threads or processes?
RP: can’t remember. i think processes, but not sure
JPEW: that seems something to try. i would guess setting up asyncio then
forking wouldn’t work over that boundary. so have each parser thread
setup their asyncio separately
PaulB: we can run builds quite happily. the build works, but then when i try
the prserv-export that’s where it falls over
RP: in the parse thread
PaulB: it’s also queried in do_package, and that seems fine
JPEW: i think asyncio in python is an abstraction around some OS primitive,
but it’s configurable so it’s possible the one being put in the
buildtools tarballs (from wherever it’s being built) isn’t properly
setup for the actual machine on which it’s run. if we could dump the
config then we’lll probably see that it’s not using the proper backend
PaulB: i think there’s just a linux one and a windows one
JPEW: okay, maybe it’s something else
RP: i think the async init is key
PaulB: i think asyncio has a good reputation of working. on stackoverflow
there are other instances/questions of people mixing asyncio with threads
and none of them have definitive answers. so there must be caveats that
the docs don’t address. most 

[yocto] Yocto Project Status WW26`21

[Stephen Jolley]

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 1st at 7:30am PDT (

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

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

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

 

Key Status/Updates:

*   YP 3.1.9 has been through QA and is awaiting release approval, no
blocking issues were identified.
*   YP 3.4 M1 was released.
*   Significantly for the project, we have now identified a kernel hang
caused from RCU stalls which has been plaguing our autobuilder testing for
months. The issue is still open in upstream mainline kernels but there is a
patch queued in the rcu tree for it. Since applying this patch to
linux-yocto, our builds have been noticeably greener and more stable. We
have closed out many of the related AB-INT bugs and will be creating new
ones for any remaining issues as they occur since it is hard to tell some
other bugs apart from the RCU issue.
*   The prserv rewrite to use asyncio is stuck on autobuilder hangs when
testing at larger scale. We'd welcome help from anyone with more details
asyncio knowledge/experience as it is looking like the new code isn't
entirely stable in python 3.5/3.6 and may have "at exit" issues, as well as
perhaps issues mixing async io code on the client side with multiprocessing
during parsing.
*   There does still seem to be an arm specific LTP hang reading
/proc/kmsg now tracked by bug
 14460.
*   The multiconfig changes in bitbake continue to cause problems, we
still need simpler test cases to reproduce issues rather than huge builds.
The existing patches seem to fix some workloads and break others. Richard is
trying to fix but trying to fix autobuilder issues and other problems and
these are slow builds to debug.
*   Intermittent autobuilder issues continue to occur, about 50% of the
open issues are now ptest failures and the rest are various other races or
timeouts. You can see the list of failures we're continuing to see by
searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

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

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

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

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

 

YP 3.4 Milestone Dates:

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

 

Planned upcoming dot releases:

*   YP 3.1.9 is under review
*   YP 3.3.2 build date 2021/07/19
*   YP 3.3.2 release date 2021/07/30
*   YP 3.1.10 build date 2021/07/26
*   YP 3.1.10 release date 2021/08/06
*   YP 3.1.11 build date 2021/09/13
*   YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

*   WDD 2704 (last week 2684) (

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

*   Total patches found: 1279 (last week 1272)
*   Patches in the Pending State: 481 (38%) [last week 481 (38%)]

 

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

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

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If 

[yocto] pyqtwebengine recipe problem

[Bel Hadj Salem Talel]

Hi All,

I want to make a recipe for python3-pyqt5 and python3-pyqtwebengine,
the problem is that the source doe does not contain setup.py , it contains 
project.py and configure.py.

Is there a solution for this so that it works with setuptools and pypi ?

Thanks,
Talel

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

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

[Bruce Ashfield]

On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
 wrote:
>
> Howdy!
>
> Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
> > I was thinking about my issue described here [1], and discovered the
> > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
> > use to stop recipes from being built for machines (/hosts) with which
> > the recipes are not compatible". And so I wondered if it would make
> > sense to add COMPATIBLE_IMAGE, for a similar purpose.
> >
> > Let me explain my issue: I define different images in different layers
> > (say `first-project-image` and `second-project-image`), and in each of
> > those layers I create `.bbappends` to configure some packages. Typically
> > `hostapd` is used by both images, but with a different config file.
> >
> > The thing is that when I run `bitbake first-project-image`, because
> > `second-project-image` is part of my bblayers.conf, then the
> > hostapd_%.bbappend from `second-project-image` is used and may have an
> > impact on `first-project-image`, which I don't want. I really want this
> > bbappend to only affect the image `second-project-image`.
> >
> > One way I can see to deal with that is to realize that
> > `first-project-image` and `second-project-image` are two different
> > projects, and build them from two different BUILDDIRs. The thing I don't
> > like here is that all the packages are therefore downloaded and built
> > twice, which seems like a loss of time and space.
> >
> > That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
> > of `first-project-image`, I would set "COMPATIBLE_IMAGE =
> > 'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
> > 'second-project-image'". So that I could still share a BUILDDIR between
> > different projects.
>
> Yocto chant #1 applies: "Recipe data is local, configuration data is
> global." Means: the recipe does not see at all which image it is being
> built for. So it also can't react to it - you can't check a variable
> against something you do not even see.
>
> > How bad of an idea is that?
>
> It just doesn't work. If that counts as "bad" is left for you to decide :)
>
> What you actually might use is using different DISTROs for the images,
> because that actually what they mean to do: you change the ABI/API of
> the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
> derivatives, so its all there already. It just cannot be triggered from
> the image, because, well.. see first pragraph of the answer.

I was also going to suggest distros.

And also, if the concern really is about builds reusing downloads,
etc, then by all means configure those different distro builds to
share download and sstate directories.

Bruce

>
> Greetz
>
> > Thanks in advance,
> > Jonas
> >
> > [1]: https://stackoverflow.com/questions/68167244/image-specific-layers
> > 
> >
> >
> >
> >
>
> 
>


-- 
- 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 (#54006): https://lists.yoctoproject.org/g/yocto/message/54006
Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

[Erik Boto]

On Tue, Jun 29, 2021 at 8:41 AM Josef Holzmayr
 wrote:
>
> Howdy!
>
> Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
> > I was thinking about my issue described here [1], and discovered the
> > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
> > use to stop recipes from being built for machines (/hosts) with which
> > the recipes are not compatible". And so I wondered if it would make
> > sense to add COMPATIBLE_IMAGE, for a similar purpose.
> >
> > Let me explain my issue: I define different images in different layers
> > (say `first-project-image` and `second-project-image`), and in each of
> > those layers I create `.bbappends` to configure some packages. Typically
> > `hostapd` is used by both images, but with a different config file.
> >
> > The thing is that when I run `bitbake first-project-image`, because
> > `second-project-image` is part of my bblayers.conf, then the
> > hostapd_%.bbappend from `second-project-image` is used and may have an
> > impact on `first-project-image`, which I don't want. I really want this
> > bbappend to only affect the image `second-project-image`.
> >
> > One way I can see to deal with that is to realize that
> > `first-project-image` and `second-project-image` are two different
> > projects, and build them from two different BUILDDIRs. The thing I don't
> > like here is that all the packages are therefore downloaded and built
> > twice, which seems like a loss of time and space.
> >
> > That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
> > of `first-project-image`, I would set "COMPATIBLE_IMAGE =
> > 'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
> > 'second-project-image'". So that I could still share a BUILDDIR between
> > different projects.
>
> Yocto chant #1 applies: "Recipe data is local, configuration data is
> global." Means: the recipe does not see at all which image it is being
> built for. So it also can't react to it - you can't check a variable
> against something you do not even see.
>
> > How bad of an idea is that?
>
> It just doesn't work. If that counts as "bad" is left for you to decide :)
>
> What you actually might use is using different DISTROs for the images,
> because that actually what they mean to do: you change the ABI/API of
> the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
> derivatives, so its all there already. It just cannot be triggered from
> the image, because, well.. see first pragraph of the answer.

I agree with everything Josef said, but just wanted to add that if
it's just different
configurations needed for different images it might be easier to just
put the configs
into separate packages and install the right package in the respective image.

So configuration for first-project-image goes into -foo, and the
config for second-project-image goes into -bar. Then the image
would add the correct configuration package.

This only works for the simple cases, and if you really need to change the way
a package is built the DISTRO way is better.

Erik

>
> Greetz
>
> > Thanks in advance,
> > Jonas
> >
> > [1]: https://stackoverflow.com/questions/68167244/image-specific-layers
> > 
> >
> >
> >
> >
>
> 
>

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

Re: [yocto] Yocto build isnot Booting up on board zc702 #gatesgarth #linux #yocto

[Leon Woestenberg]

Hello,

>
> i have tried to build yocto image.  And it compiled successfully without any 
> error but when am trying to BOOT them it didnt prompt any error message
> what should i do to BOOT my yocto build image on zc702 board

What is your output from the ZC702 (USB) serial console?


I had similar issue on ZCU102 and debugged my issue:

"the U-Boot not showing anything I have debugged to be an issue where
DEVICE_TREE does not propagate from the BitBake recipe into the U-Boot
build (both for upstream and Xilinx). I have reported this on
meta-xilinx but will make it a separate bug report."

I can imagine the same problem would occur on ZC702 (single-core Zynq).

I have posted a few messages with meta-xilinx in the subject on how I
had to bring Yocto to the ZCU102.

Regards,

Leon.


--
Leon Woestenberg
l...@sidebranch.com
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Jun 29, 2021 at 8:02 AM shoaib akhtar
 wrote:
>
>
>
>
> i have tried to build yocto image.  And it compiled successfully without any 
> error but when am trying to BOOT them it didnt prompt any error message my 
> BBlayer.conf is shown below
>
> # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> POKY_BBLAYERS_CONF_VERSION = "2"
>
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
>
> BBLAYERS ?= " \
>   /media/vmnrtc/Drive/poky/meta \
>   /media/vmnrtc/Drive/poky/meta-poky \
>   /media/vmnrtc/Drive/poky/meta-yocto-bsp \
>   /media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-bsp \
>   /media/vmnrtc/Drive/poky/meta-openembedded/meta-oe \
>   /media/vmnrtc/Drive/poky/meta-openembedded/meta-python \
>   /media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-standalone \
>   /media/vmnrtc/Drive/poky/meta-xilinx-tools \
>   /media/vmnrtc/Drive/poky/build/meta-networking \
>   "
>
> MY files in image directories
>
>
> boot.bin
> boot.bin-zc702-zynq7
> boot.bin-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
> boot.scr
> core-image-minimal-zc702-zynq7-20210629031233.qemuboot.conf
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio.gz.u-boot
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.manifest
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.tar.gz
> core-image-minimal-zc702-zynq7-20210629031233.testdata.json
> core-image-minimal-zc702-zynq7.cpio
> core-image-minimal-zc702-zynq7.cpio.gz.u-boot
> core-image-minimal-zc702-zynq7.manifest
> core-image-minimal-zc702-zynq7.qemuboot.conf
> core-image-minimal-zc702-zynq7.tar.gz
> core-image-minimal-zc702-zynq7.testdata.json
> modules--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.tgz
> modules-zc702-zynq7.tgz
> pxeboot
> pxelinux.cfg
> u-boot.elf
> u-boot.img
> u-boot-xlnx-AUTOINC+bb4660c33a.elf
> u-boot-xlnx-initial-env
> u-boot-xlnx-initial-env-zc702-zynq7
> u-boot-xlnx-initial-env-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
> u-boot-zc702-zynq7.elf
> u-boot-zc702-zynq7.img
> u-boot-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0.img
> u-boot-zynq-scr--1.0-r0.scr
> uEnv.txt
> uImage
> uImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
> uImage-zc702-zynq7.bin
> zImage
> zImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
> zImage-zc702-zynq7.bin
> zynq-zc702--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.dtb
> zynq-zc702.dtb
> zynq-zc702-zc702-zynq7.dtb
>
>
>
> what should i do to BOOT my yocto build image on zc702 board
>
>
> 
>

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

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

[Josef Holzmayr]

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
I was thinking about my issue described here [1], and discovered the 
variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can 
use to stop recipes from being built for machines (/hosts) with which 
the recipes are not compatible". And so I wondered if it would make 
sense to add COMPATIBLE_IMAGE, for a similar purpose.


Let me explain my issue: I define different images in different layers 
(say `first-project-image` and `second-project-image`), and in each of 
those layers I create `.bbappends` to configure some packages. Typically 
`hostapd` is used by both images, but with a different config file.


The thing is that when I run `bitbake first-project-image`, because 
`second-project-image` is part of my bblayers.conf, then the 
hostapd_%.bbappend from `second-project-image` is used and may have an 
impact on `first-project-image`, which I don't want. I really want this 
bbappend to only affect the image `second-project-image`.


One way I can see to deal with that is to realize that 
`first-project-image` and `second-project-image` are two different 
projects, and build them from two different BUILDDIRs. The thing I don't 
like here is that all the packages are therefore downloaded and built 
twice, which seems like a loss of time and space.


That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend 
of `first-project-image`, I would set "COMPATIBLE_IMAGE = 
'first-project-image'", and similarly for "COMPATIBLE_IMAGE = 
'second-project-image'". So that I could still share a BUILDDIR between 
different projects.


Yocto chant #1 applies: "Recipe data is local, configuration data is 
global." Means: the recipe does not see at all which image it is being 
built for. So it also can't react to it - you can't check a variable 
against something you do not even see.



How bad of an idea is that?


It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images, 
because that actually what they mean to do: you change the ABI/API of 
the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO 
derivatives, so its all there already. It just cannot be triggered from 
the image, because, well.. see first pragraph of the answer.


Greetz


Thanks in advance,
Jonas

[1]: https://stackoverflow.com/questions/68167244/image-specific-layers 







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

[yocto] Yocto build isnot Booting up on board zc702 #gatesgarth #linux #yocto

[shoaib akhtar]

i have tried to build yocto image.  And it compiled successfully without any 
error but when am trying to BOOT them it didnt prompt any error message my 
BBlayer.conf is shown below

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/media/vmnrtc/Drive/poky/meta \
/media/vmnrtc/Drive/poky/meta- poky \
/media/vmnrtc/Drive/poky/meta- yocto-bsp \
/media/vmnrtc/Drive/poky/meta- xilinx/meta-xilinx-bsp \
/media/vmnrtc/Drive/poky/meta- openembedded/meta-oe \
/media/vmnrtc/Drive/poky/meta- openembedded/meta-python \
/media/vmnrtc/Drive/poky/meta- xilinx/meta-xilinx-standalone \
/media/vmnrtc/Drive/poky/meta- xilinx-tools \
/media/vmnrtc/Drive/poky/ build/meta-networking \
"

MY files in image directories

boot.bin
boot.bin-zc702-zynq7
boot.bin-zc702-zynq7-v2020.01- xilinx-v2020.2+gitAUTOINC+ bb4660c33a-r0
boot.scr
core-image-minimal-zc702- zynq7-20210629031233.qemuboot. conf
core-image-minimal-zc702- zynq7-20210629031233.rootfs. cpio
core-image-minimal-zc702- zynq7-20210629031233.rootfs. cpio.gz.u-boot
core-image-minimal-zc702- zynq7-20210629031233.rootfs. manifest
core-image-minimal-zc702- zynq7-20210629031233.rootfs. tar.gz
core-image-minimal-zc702- zynq7-20210629031233.testdata. json
core-image-minimal-zc702- zynq7.cpio
core-image-minimal-zc702- zynq7.cpio.gz.u-boot
core-image-minimal-zc702- zynq7.manifest
core-image-minimal-zc702- zynq7.qemuboot.conf
core-image-minimal-zc702- zynq7.tar.gz
core-image-minimal-zc702- zynq7.testdata.json
modules--5.4+git0+62ea514294- r0-zc702-zynq7-20210622034511. tgz
modules-zc702-zynq7.tgz
pxeboot
pxelinux.cfg
u-boot.elf
u-boot.img
u-boot-xlnx-AUTOINC+ bb4660c33a.elf
u-boot-xlnx-initial-env
u-boot-xlnx-initial-env-zc702- zynq7
u-boot-xlnx-initial-env-zc702- zynq7-v2020.01-xilinx-v2020.2+ 
gitAUTOINC+bb4660c33a-r0
u-boot-zc702-zynq7.elf
u-boot-zc702-zynq7.img
u-boot-zc702-zynq7-v2020.01- xilinx-v2020.2+gitAUTOINC+ bb4660c33a-r0.img
u-boot-zynq-scr--1.0-r0.scr
uEnv.txt
uImage
uImage--5.4+git0+62ea514294- r0-zc702-zynq7-20210622034511. bin
uImage-zc702-zynq7.bin
zImage
zImage--5.4+git0+62ea514294- r0-zc702-zynq7-20210622034511. bin
zImage-zc702-zynq7.bin
zynq-zc702--5.4+git0+ 62ea514294-r0-zc702-zynq7- 20210622034511.dtb
zynq-zc702.dtb
zynq-zc702-zc702-zynq7.dtb

what should i do to BOOT my yocto build image on zc702 board

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