[yocto] M+ & H bugs with Milestone Movements WW34

2021-08-23 Thread Stephen Jolley
All,

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


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  13722

Debugging With the GNU Project Debugger enhancements

randy.macl...@windriver.com

john.kaldas.e...@gmail.com

3.4 M2

3.4 M4


 

  13903

npmsw fetcher fails if multiple recipes have common npm packages

randy.macl...@windriver.com

jeanmarie.lemeta...@gmail.com

3.4 M2

3.4 M4


 

  13954

Invalid layerindex data causing backtrace in `bitbake-layers layerindex-fetch`

randy.macl...@windriver.com

unassig...@yoctoproject.org

3.4 M2

3.4 M4


 

  14060

devtool modify fails when applied on recipes using patches

randy.macl...@windriver.com

saul.w...@windriver.com

3.4 M2

3.4 M4


 

  14146

Post-patch hook fails with submodules and PATCHTOOL=git and 
PATCH_COMMIT_FUNCTIONS=1

randy.macl...@windriver.com

unassig...@yoctoproject.org

3.4 M2

3.99


 

  14385

mode of sstate files created under pseudo

randy.macl...@windriver.com

mark.ha...@kernel.crashing.org

3.4 M2

3.4 M4


 

  1

[multilib] lib32-core-image-minimal -c populate_sdk failure on dunfell

randy.macl...@windriver.com

st...@sakoman.com

3.4 M2

3.1.11


 

  14449

AB-INT PTEST ARM: quilt patch-wrapper ptest intermittent failure

randy.macl...@windriver.com

randy.macl...@windriver.com

3.4 M3

3.4 M4

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com  

 


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



[yocto] Enhancements/Bugs closed WW34!

2021-08-23 Thread Stephen Jolley
All,

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


Who

Count


r...@burtonini.com

2


fransmeulenbro...@yahoo.com

1


alexandre.bell...@bootlin.com

1


randy.macl...@windriver.com

1


jay.shen.t...@intel.com

1


Grand Total

6

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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



[yocto] Current high bug count owners for Yocto Project 3.4

2021-08-23 Thread Stephen Jolley
All,

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


Who

Count


michael.opdenac...@bootlin.com

32


r...@burtonini.com

31


david.re...@windriver.com

22


richard.pur...@linuxfoundation.org

21


bruce.ashfi...@gmail.com

16


randy.macl...@windriver.com

13


trevor.gamb...@windriver.com

13


timothy.t.orl...@intel.com

12


jpewhac...@gmail.com

10


sakib.sa...@windriver.com

10


bluelightn...@bluelightning.org

7


kai.k...@windriver.com

7


tony.tascio...@windriver.com

5


hongxu@windriver.com

4


qi.c...@windriver.com

4


mingli...@windriver.com

3


chee.yang@intel.com

3


alexandre.bell...@bootlin.com

2


ms...@mvista.com

2


jae...@xilinx.com

2


yf...@uwaterloo.ca

2


akuster...@gmail.com

2


yi.z...@windriver.com

2


alejan...@enedino.org

2


vinay.m.e...@gmail.com

1


raj.k...@gmail.com

1


pokyli...@reliableembeddedsystems.com

1


mostthings...@gmail.com

1


weave...@gmail.com

1


martin.ja...@gmail.com

1


yoctoproj...@cookiesoft.de

1


nicolas.deche...@linaro.org

1


kerg...@gmail.com

1


dl...@gmx.de

1


mark.ha...@kernel.crashing.org

1


open.sou...@oleksandr-kravchuk.com

1


p...@pbarker.dev

1


jon.ma...@arm.com

1


mister...@web.de

1


ydir...@free.fr

1


john.kaldas.e...@gmail.com

1


naveen.kumar.sa...@intel.com

1


devendra.tew...@gmail.com

1


jeanmarie.lemeta...@gmail.com

1


diego.sue...@arm.com

1


aeh...@gmail.com

1


thomas.per...@bootlin.com

1


matthew...@posteo.net

1


douglas.ro...@taitradio.com

1


saul.w...@windriver.com

1


to...@cybernetics.com

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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



[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2021-08-23 Thread Stephen Jolley
All,

 

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

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

https://bugzilla.yoctoproject.org/createaccount.cgi

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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



[yocto] Update bitbake broken build

2021-08-23 Thread JH
Hi,

I updated the bitbake to run git pull in master branch, now it is
broken, what does the following error message mean, how to fix it?

$ bitbake-layers show-layers

NOTE: Starting bitbake server...
ERROR: Variable PROVIDES_prepend contains an operation using the old
override syntax. Please convert this layer/metadata before attempting
to use with a newer bitbake.

Thank you.

Kind regards,

- jupiter

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



Re: [yocto] Wayland and X11 on Yocto

2021-08-23 Thread Manuel Wagesreither
Hi all, hi Khem,

Am Do, 19. Aug 2021, um 00:22, schrieb Khem Raj:
> On Wed, Aug 18, 2021 at 3:06 PM Manuel Wagesreither  
> wrote:
> >
> > Hello all,
> >
> > I'm building an image to run on various SBCs and would like to equip it 
> > with a graphical interface.
> >
> > There are quite a few things very unclear to me. Can someone help me with 
> > that?
> >
> > * Why is X11 enabled by setting an IMAGE_FEATURE (namely  x11, x11-base or 
> > x11-sato), while Wayland is enabled by IMAGE_INSTALL only (weston-init and 
> > weston)?
> 
> x11-* features is primarily to control what kind of x11 packages you
> want to include in image e.g.
> ./meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb is
> pulled in when x11-sato is added to IMAGE_FEATURES
> we have many X11 based images and sato is one of them so thats why its
> separated out.
> 
Okay, so if I get things right then IMAGE_FEATURES+="x11" is under the hood 
nothing more than an IMAGE_INSTALL+="packagegroup-core-x11". Is that right? If 
so, what's the purpose of adding the concept of IMAGE_FEATURE? I mean, it 
doesn't make things SO much easier. Setting an IMAGE_FEATURE or an 
IMAGE_INSTALL variable is the same to me.

> you should really is looking at DISTRO_FEATURES e.g. wayland distro
> feature is needed for core-image-weston to build.
> 
Yepp, I know. I left them out on purpose because I was mainly interested in 
where the configuration for X11 and wayland differs conceptually. With 
"conceptually" I mean that one is added through IMAGE_FEATURES while the other 
is through IMAGE_INSTALL.

> > * Theory: Is IMAGE_FEATURE +=x11 manipulating IMAGE_INSTALL under the hood 
> > so you don't have to do it manually? And as there is no IMAGE_FEATURE 
> > "wayland", you have do it manually. Correct?
> > * Why is Wayland different in that it doesn't need an IMAGE_FEATURE to 
> > enable it?
> 
> there are not many wayland based compositors or images we have in core
> as of now.
> 
And if there would be more wayland based compositors or images then you would 
turn extract this into an IMAGE_FEATURE as well? Why? How does that make things 
easier? Again, I feel there's something to IMAGE_FEATURES I didn't yet 
understand.

> > * Why does core-image-weston.bb need to enable IMAGE_FEATURE hwcodec, while 
> > core-image-x11.bb does not? (Dunfell branch.)
> 
> openGL is needed for wayland/weston to work too but hwcodec feature is
> infact to pull in machine specific drivers MACHINE_HWCODECS into image
> if a given BSP defined it.
> e.g. intel bsps define vaapi codecs and mediasdk for specific machines
> via MACHINE_HWCODECS
> defaults for this image features are empty

Thanks for the explanation on MACHINE_HWCODEC. I'm curious, so is 
core-image-x11 require DISTRO_FEATURE hwcodec or not? If yes, than it seems to 
be missing in the core-image-x11.bb (it's in the core-images-weston.bb, after 
all), if no, then why is it not required for X11?


I know I'm asking quite detailed questions, but I got the feeling I need to 
understand this once and for all.

Thanks, regards, Manuel

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



[yocto] Extensible SDK - runtime packages installation

2021-08-23 Thread d0ku
Hi,

I've been playing with extensible SDK lately and got to a point, where I
want to create a minimal SDK installer and install all the required
packages in runtime via `devtool sdk-install`, so that every developer can
get only the stuff that's actually needed.

For the target part it works as expected, installing the content to
${OECORE_TARGET_SYSROOT}, however for the host part the content gets
installed to ${OECORE_NATIVE_SYSROOT}, but it's not visible in the PATH in
some cases. E.g. for perl-native the binaries are installed to `/bin/perl-native` and are not visible, unless I manually extend the
PATH with this directory, then it works fine.

So my questions are:
* Is the runtime installation of packages meant to run on host actually
supported? It surely works for e.g. compiler, so I assume it should be also
fine for other packages?
* Should I install `nativesdk-` or `-native` packages, if I want to use
them this way? Or can I actually do both? In the eSDK talk by Paul Eggerton
I saw that `nativesdk-cmake` was added, but the `nativesdk-` doesn't really
seem to fit `mini Yocto environment` that eSDK basically is.
* Am I possibly missing some configuration steps? In Yocto environment the
PATH gets expanded with `bin/perl-native` automatically, but I wasn't able
to pinpoint what file/task actually does it.

Best Regards and thanks in advance,
Jakub

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



Re: [yocto] meta-gnome error #yocto

2021-08-23 Thread Khem Raj



On 8/23/21 2:55 AM, yasminebenghoz...@gmail.com wrote:

Hello, please can anyone help with this error ?
ERROR: ParseError at 
/home/yasmine/yocto/poky/meta-openembedded/meta-gnome/recipes-gnome/yelp/yelp_3.34.0.bb:7: 
Could not inherit file classes/itstool.bbclass


this is the line 7:
inherit gnomebase itstool autotools-brokensep gsettings gettext gtk-doc 
features_check mime-xdg





this class is provided by meta-oe layer. Make sure you have meta-oe 
layer in your bblayers.conf






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



[yocto] Yocto Technical Team Minutes, Engineering Sync, for August 17, 2021

2021-08-23 Thread Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for August 17, 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 Richard Purdie Peter Kjellerstedt Joshua
Watt Randy MacLeod Saul Wold Michael Halstead Richard Elberger Scott Murray
Steve Sakoman Tony Toscioglu Trevor Gamblin Bruce Ashfield Ross Burton
Alexandre Belloni Daiane Angolini Jon Mason Jan-Simon Möller

== project status ==
- 3.1.10 (dunfell) released
- 3.4 (honister) is in feature freeze next week (pending work includes rust
and prserv)
- glibc 2.34 update merged. the builds are fine, but causes problems with
uninative and pseudo, fixes being investigated
- kernel: drop 5.4, updates to 5.10 and 5.13
- appears to be issues with buildtools tarball in aarch64 (probably related to
gcc 11 update)
- plan to migrate tune files into architecture-specific directories; patch
likely to merge in the next few days
- bitbake fetcher no longer ignores SSL certificates
- LTO linker flag handling changes merged to help with reproducibility issues
- overlayfs class changes were merged

== discussion ==
Randy: the pending rust work is coming along. fixed ppc issue and fixed
reproducibility issues but still having an issue with diffsigs. Alex did a
full build and it’s looking good. is diffsig issue a requirement?
RP: yes. maybe show it to me and i can take a look. perhaps a status update to
the mailing list

Scott: re: prserv. i was away. i was able to reproduce the hang issues that RP
was seeing on the AB before i left. however, i’m seeing a new issue with
debian 10 and python 3.7 we’re seeing a hang, but it’s not like any
of the other hangs we’ve seen before so still investigating. is feature
freeze the end of this week, or next
RP: technically Monday. but this is a planned feature so there is some
flexibility so we’ll see how the progress goes
Scott: what’s the minimum python?
RP: 3.5 or 3.6?
Ross: 3.5
Scott: we could also lift the read-only feature and put that in for this
release then work on the rest for the next release
RP: well, we need read-only for hashequiv and prserv
Scott: it’s already there for hashequiv. i don’t think it’s a huge need
for this code. but i’ll keep working on it
RP: we could do that as a backup plan, but i’d prefer to see it all go in
for this release. i’m reluctant to do this.
Scott: python 3.9 seems quite happy. the problem seems to be with the older
versions. maybe there’s something we can do with the older versions to
make them happy
JPEW: hash equiv is a lot cleaner, it doesn’t have to do all the forking etc
Scott: i thought i had it working (before i left) but i guess not. i’m
seeing a strange ld.so bug (inconsistency detected by ld.so: dl-open
worker assert dl_debug_initialize()->rstate == RT_CONSISTENT failed). not
sure what this is, not what you’d expect out of a python program. looks
like maybe loading debug symbols? when i attach gdb i don’t see any
obvious problems. the coverage on the AB uses buildtools, what combos on
the AB include the old python?
RP: i think the really older ones all have buildtools tarball, but newer ones
would run native
PeterK: i think the latest python is 3.6 with the fstreams thing
JPEW: i thought it was 3.6 too, i’m pretty sure i was the one who bumped it
RP: i was thinking 3.6 for fstreams too when Ross said 3.5
PeterK: not that it helps you if you want 3.9
RP: but it does help somewhat
Randy: (finds log) January 2021
RP: ah, the core does have the version bump, but it was not done in bitbake
JPEW: i think it was something specific in oe-core that needs 3.6 and if
someone is using bitbake without oe-core then they can still use 3.5

JPEW: is bitbake major version going to bump with overrides
RP: it did
JPEW: i meant bitbake 2.0.0
RP: not yet. i’m tempted for next LTS, but we’ll see. i’m getting tired
of 1.x ;-)
JPEW: let’s use dates

JPEW: re spdx. if you go to poky-contrib there is a branch jpew-sbom which
includes all the stuff i’ve done with spdx and sbom creation. please
take a look and let me know if what we’re creating generates something
that’s useful to you. if you do fossology scanning then please take a
look at the output and let me know if that works for you
Saul: i’m looking at it. do you have any plans about creating a single large
image sbom instead of the relationship based one
JPEW: originally i went down that road, it can be done if we can do it sanely.
however we have to create different parts at different times in the build,
so it’s just easier to have separate docs and then link them later.
so we get 100’s and 100’s of docs, and then 

[linux-yocto][PATCH 3/3] arm: axxia: ddr_retention: use malloc/free to fix -Wframe-larger-than build warning

2021-08-23 Thread quanyang.wang
From: Quanyang Wang 

This is to fix compile warning which is introduced by the SDK
commit a4396719ad21 ("ARM: axxia: Fix support for kernel 5.10")
as below:

arch/arm/mach-axxia/ddr_retention.c:220:1: warning: the frame size of 1032 
bytes is larger than 1024 bytes [-Wframe-larger-than=]
  220 | }
  | ^

Signed-off-by: Quanyang Wang 
---
 arch/arm/mach-axxia/ddr_retention.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-axxia/ddr_retention.c 
b/arch/arm/mach-axxia/ddr_retention.c
index 64ddb2f42c135..ca7b1b771133b 100644
--- a/arch/arm/mach-axxia/ddr_retention.c
+++ b/arch/arm/mach-axxia/ddr_retention.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -205,9 +206,13 @@ static inline void flush_tlb_ID(void)
 static void exercise_stack_ptr(volatile char *recursions)
 {
volatile char *p;
-   char stack_var[1024];
+   char *stack_var;
int i;
 
+   stack_var = kmalloc(1024, GFP_KERNEL);
+   if (!stack_var)
+   return;
+
p = stack_var;
 
for (i = 0; i < 1024; i++)
@@ -217,6 +222,8 @@ static void exercise_stack_ptr(volatile char *recursions)
*recursions -= 1;
exercise_stack_ptr(recursions);
}
+
+   kfree(stack_var);
 }
 
 void
-- 
2.25.1


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



[linux-yocto][PATCH 2/3] net: ethernet: axxia_acp_net: use dev_dbg instead of dev_info to silience noisy info

2021-08-23 Thread quanyang.wang
From: Quanyang Wang 

Just as what said in the commit message in the SDK commit b0162883a002
("net: ethernet: Clean Up Intel Axxia FEMAC driver"):

"Packets are also discarded, although by the driver and not the hardware,
"when the destination MAC is not for us. This is the case because the
"hardware only supports promiscuous mode."

The console will continue print the message:
"acp-femac 201012.femac: Packets not for us, 164 out of 164"

It's better to silience the meaningless info.

Signed-off-by: Quanyang Wang 
---
 drivers/net/ethernet/axxia/axxia_acp_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/axxia/axxia_acp_net.c 
b/drivers/net/ethernet/axxia/axxia_acp_net.c
index 4bc4cdeb35828..3a7104c0f764d 100644
--- a/drivers/net/ethernet/axxia/axxia_acp_net.c
+++ b/drivers/net/ethernet/axxia/axxia_acp_net.c
@@ -317,7 +317,7 @@ static void get_hw_statistics(struct appnic_device *pdata)
u32 tx_under;
 
if (pdata->not_for_us != 0)
-   dev_info(pdata->dev, "Packets not for us, %lu out of %lu\n",
+   dev_dbg(pdata->dev, "Packets not for us, %lu out of %lu\n",
 pdata->not_for_us, pdata->stats.rx_dropped);
 
/* stats.tx_packets */
-- 
2.25.1


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



[linux-yocto][PATCH 1/3] axxia: Added i2c device node for axm5616-victoria board

2021-08-23 Thread quanyang.wang
From: Quanyang Wang 

Add i2c device node for axm5616-victoria board, or else the user
app "sensors" can't find sensor via i2c bus.

Signed-off-by: Quanyang Wang 
---
 .../arm64/boot/dts/intel/axm5616-victoria.dts | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/intel/axm5616-victoria.dts 
b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
index cc2be5e4a93bd..b960f0388a0d0 100644
--- a/arch/arm64/boot/dts/intel/axm5616-victoria.dts
+++ b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
@@ -202,6 +202,43 @@  {
 
  {
status = "okay";
+
+   pxa9555@20 {
+   compatible = "pca9555";
+   reg = <0x20>;
+   };
+
+   adt7467@2e {
+   compatible = "adt7473";
+   reg = <0x2e>;
+   };
+
+   temp@18 {
+   compatible = "jedec,jc-42.4-temp";
+   reg = <0x18>;
+   };
+
+   temp@1a {
+   compatible = "jedec,jc-42.4-temp";
+   reg = <0x1a>;
+   };
+
+   spd@50 {
+   compatible = "spd";
+   reg = <0x50>;
+   };
+
+   spd@52 {
+   compatible = "spd";
+   reg = <0x52>;
+   };
+
+   eeprom@54 {
+   compatible = "atmel, 24c1024";
+   reg = <0x54>;
+   pagesize = <128>;
+   };
+
 };
 
  {
@@ -210,6 +247,17 @@  {
 
  {
status = "okay";
+
+   ltc2974@5c {
+   compatible = "ltc2974";
+   reg = <0x5c>;
+   };
+
+   ltc2974@5d {
+   compatible = "ltc2974";
+   reg = <0x5d>;
+   };
+
 };
 
 _cpu {
-- 
2.25.1


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



[linux-yocto][[v5.10/standard/preempt-rt/sdkv5.10/axxia]][PATCH 0/3] axxia: fix issues

2021-08-23 Thread quanyang.wang
From: Quanyang Wang 

Hi Bruce,

Would you please help merge these 3 patches to:

v5.10/standard/preempt-rt/sdkv5.10/axxia
v5.10/standard/sdkv5.10/axxia

Thanks,
Quanyang

Quanyang Wang (3):
  axxia: Added i2c device node for axm5616-victoria board
  net: ethernet: axxia_acp_net: use dev_dbg instead of dev_info to
silience noisy info
  arm: axxia: ddr_retention: use malloc/free to fix -Wframe-larger-than
build warning

 arch/arm/mach-axxia/ddr_retention.c   |  9 +++-
 .../arm64/boot/dts/intel/axm5616-victoria.dts | 48 +++
 drivers/net/ethernet/axxia/axxia_acp_net.c|  2 +-
 3 files changed, 57 insertions(+), 2 deletions(-)

-- 
2.25.1


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



[yocto] meta-gnome error #yocto

2021-08-23 Thread yasminebenghozzi6
Hello, please can anyone help with this error ?
ERROR: ParseError at 
/home/yasmine/yocto/poky/meta-openembedded/meta-gnome/recipes-gnome/yelp/yelp_3.34.0.bb:7:
 Could not inherit file classes/itstool.bbclass

this is the line 7:
inherit gnomebase itstool autotools-brokensep gsettings gettext gtk-doc 
features_check mime-xdg

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



[yocto] [meta-zephyr][PATCH] layer.conf: update machine confs with new tune locations

2021-08-23 Thread Naveen Saini
Added logic to make sure, it does not break with old releases.

Signed-off-by: Naveen Saini 
---
 conf/layer.conf | 2 ++
 conf/machine/include/tune-corei7-common.inc | 4 ++--
 conf/machine/qemu-x86.conf  | 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 5f13c27..35f1075 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -16,3 +16,5 @@ LAYERVERSION_zephyr = "1"
 LAYERDEPENDS_zephyr = "core meta-python"
 
 LAYERSERIES_COMPAT_zephyr = "dunfell gatesgarth hardknott honister"
+
+X86_TUNE_DIR = "${@bb.utils.contains('LAYERSERIES_CORENAMES', 'honister', 
'include/x86', 'include', d)}"
diff --git a/conf/machine/include/tune-corei7-common.inc 
b/conf/machine/include/tune-corei7-common.inc
index 509d190..b68fc05 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,6 +1,6 @@
 DEFAULTTUNE ?= "corei7-64"
-require conf/machine/include/tune-corei7.inc
-require conf/machine/include/x86-base.inc
+require conf/machine/${X86_TUNE_DIR}/tune-corei7.inc
+require conf/machine/${X86_TUNE_DIR}/x86-base.inc
 
 # Add x86 to MACHINEOVERRIDE
 MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index 31ce80d..ae7716c 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -3,7 +3,7 @@
 #@DESCRIPTION: Machine for Zephyr BOARD qemu_x86
 
 require conf/machine/include/qemu.inc
-require conf/machine/include/tune-i586.inc
+require conf/machine/${X86_TUNE_DIR}/tune-i586.inc
 
 ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
 
-- 
2.17.1


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



[yocto] [PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to export Fetcher env

2021-08-23 Thread Mingrui Ren
From 1b0d7b4bb4a5b39f7ae0ce7d7ae5897a33637972 Mon Sep 17 00:00:00 2001
From: Mingrui Ren 
Date: Mon, 23 Aug 2021 14:49:03 +0800
Subject: [PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to export 
Fetcher env

The environment variables used by Fetcher are hard-coded, and are obtained
from HOST env instead of bitbake datastore
This patch add a new variable 'BB_FETCH_ENV',and modify the default
BB_ENV_EXTRAWHITE_OE for backwards compatibility, trying to fix the
problems above.

Signed-off-by: Mingrui Ren 
---
changes in v2:
 a.changes the variable name from 'FETCH_ENV_WHITELIST' to 'BB_FETCH_ENV'.
 b.add 'BB_FETCH_ENV' in local.conf, rather than export it in host
   enviroment.
 c.modify existing BB_ENV_EXTRAWHITE_OE for backwards compatibility.
 d.Two commits recently modified this variable. The commit ID is:
   348384135272ae7c62a11eeabcc43eddc957811f and 
5dce2f3da20a14c0eb5229696561b0c5f6fce54c,
   So I adjusted the new variables in the patch.

 bitbake/lib/bb/fetch2/__init__.py | 34 ---
 bitbake/lib/bb/fetch2/wget.py |  2 +-
 meta-poky/conf/local.conf.sample  | 12 +++
 scripts/oe-buildenv-internal  |  3 ++-
 4 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/__init__.py 
b/bitbake/lib/bb/fetch2/__init__.py
index 914fa5c024..cbbe32d1df 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -808,28 +808,13 @@ def localpath(url, d):
 fetcher = bb.fetch2.Fetch([url], d)
 return fetcher.localpath(url)
 
-# Need to export PATH as binary could be in metadata paths
-# rather than host provided
-# Also include some other variables.
-FETCH_EXPORT_VARS = ['HOME', 'PATH',
- 'HTTP_PROXY', 'http_proxy',
- 'HTTPS_PROXY', 'https_proxy',
- 'FTP_PROXY', 'ftp_proxy',
- 'FTPS_PROXY', 'ftps_proxy',
- 'NO_PROXY', 'no_proxy',
- 'ALL_PROXY', 'all_proxy',
- 'GIT_PROXY_COMMAND',
- 'GIT_SSH',
- 'GIT_SSL_CAINFO',
- 'GIT_SMART_HTTP',
- 'SSH_AUTH_SOCK', 'SSH_AGENT_PID',
- 'SOCKS5_USER', 'SOCKS5_PASSWD',
- 'DBUS_SESSION_BUS_ADDRESS',
- 'P4CONFIG',
- 'SSL_CERT_FILE',
- 'AWS_ACCESS_KEY_ID',
- 'AWS_SECRET_ACCESS_KEY',
- 'AWS_DEFAULT_REGION']
+def getfetchenv(d):
+# Need to export PATH as binary could be in metadata paths
+# rather than host provided
+# Also include some other variables.
+vars = ['HOME', 'PATH']
+vars.extend((d.getVar("BB_FETCH_ENV") or "").split())
+return vars
 
 def runfetchcmd(cmd, d, quiet=False, cleanup=None, log=None, workdir=None):
 """
@@ -839,7 +824,7 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None, 
log=None, workdir=None):
 Optionally remove the files/directories listed in cleanup upon failure
 """
 
-exportvars = FETCH_EXPORT_VARS
+exportvars = getfetchenv(d)
 
 if not cleanup:
 cleanup = []
@@ -855,9 +840,8 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None, 
log=None, workdir=None):
 d.setVar("PV", "fetcheravoidrecurse")
 d.setVar("PR", "fetcheravoidrecurse")
 
-origenv = d.getVar("BB_ORIGENV", False)
 for var in exportvars:
-val = d.getVar(var) or (origenv and origenv.getVar(var))
+val = d.getVar(var)
 if val:
 cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)
 
diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py
index 29fcfbb3d1..0ce06ddb4f 100644
--- a/bitbake/lib/bb/fetch2/wget.py
+++ b/bitbake/lib/bb/fetch2/wget.py
@@ -306,7 +306,7 @@ class Wget(FetchMethod):
 # to scope the changes to the build_opener request, which is when the
 # environment lookups happen.
 newenv = {}
-for name in bb.fetch2.FETCH_EXPORT_VARS:
+for name in bb.fetch2.getfetchenv(d):
 value = d.getVar(name)
 if not value:
 origenv = d.getVar("BB_ORIGENV")
diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample
index f1f6d690fb..4e8a6f0c77 100644
--- a/meta-poky/conf/local.conf.sample
+++ b/meta-poky/conf/local.conf.sample
@@ -267,6 +267,18 @@ PACKAGECONFIG:append:pn-qemu-system-native = " sdl"
 #
 #BB_SERVER_TIMEOUT = "60"
 
+# Bitbake Fetcher Environment Variables
+#
+# Specific which environment variables in bitbake datastore used by fetcher 
when
+# executing fetch task.
+# NOTE: You may need to modify BB_ENV_EXTRAWHITE, in order to add environment
+# variable into bitbake datastore first.
+BB_FETCH_ENV ?= "HTTP_PROXY http_proxy HTTPS_PROXY https_proxy \
+FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy NO_PROXY no_proxy ALL_PROXY 
all_proxy \
+GIT_PROXY_COMMAND GIT_SSH