date:20230313

Re: [linux-yocto] [kernel-cache][PATCH 10/11] common-pc: Enable DesignWare PWM & SPI Controller support

2023-03-13 Thread Naveen Saini



> -Original Message-
> From: linux-yocto@lists.yoctoproject.org  yo...@lists.yoctoproject.org> On Behalf Of Bruce Ashfield
> Sent: Thursday, March 9, 2023 5:51 AM
> To: Saini, Naveen Kumar 
> Cc: linux-yocto@lists.yoctoproject.org
> Subject: Re: [linux-yocto] [kernel-cache][PATCH 10/11] common-pc: Enable
> DesignWare PWM & SPI Controller support
> 
> In message: [linux-yocto] [kernel-cache][PATCH 10/11] common-pc: Enable
> DesignWare PWM & SPI Controller support on 06/03/2023 Naveen Saini
> wrote:
> 
> > Signed-off-by: Naveen Saini 
> > ---
> >  bsp/common-pc/common-pc-drivers.cfg | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/bsp/common-pc/common-pc-drivers.cfg
> > b/bsp/common-pc/common-pc-drivers.cfg
> > index 5e2018d6..0d2672bc 100644
> > --- a/bsp/common-pc/common-pc-drivers.cfg
> > +++ b/bsp/common-pc/common-pc-drivers.cfg
> > @@ -62,3 +62,12 @@ CONFIG_EEPROM_AT24=m
> >
> >  CONFIG_NVME_CORE=y
> >  CONFIG_BLK_DEV_NVME=y
> > +
> > +# DesignWare PWM Controller
> > +CONFIG_PWM_DWC=m
> > +
> > +# DesignWare SPI controller core support CONFIG_SPI_DESIGNWARE=m
> > +CONFIG_SPI_DW_DMA=y CONFIG_SPI_DW_PCI=m
> CONFIG_SPI_DW_MMIO=m
> 
> Out of curiosity, why did these specific drivers get enabled in common-pc-
> drivers, versus a named feature that could be included ?

Yes, it should be included as named feature. I will do that.

> 
> Bruce
> 
> > --
> > 2.25.1
> >
> 
> >
> >
> >


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

Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU

2023-03-13 Thread Naveen Saini

Hi Bruce,

Thank you for reviewing.

> -Original Message-
> From: Bruce Ashfield 
> Sent: Thursday, March 9, 2023 6:00 AM
> To: Saini, Naveen Kumar 
> Cc: linux-yocto@lists.yoctoproject.org
> Subject: Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop
> RANDOM_TRUST_CPU
> 
> Hi Naveen,
> 
> I commented directly on one of the patches, and this 1/11 in particular is
> clear, but the other patches in the series are a little bit less unclear as 
> to the
> overall goal.
> 
> As Paul mentioned, a 0/N for the series would have helped explain the
> motivation.

Yes, will make sure I provide that next time.

> 
> I didn't reply directly to the review and thread that started, as everyone had
> valid points to make. We have a balance to strike between enablement and
> also providing a streamlined base configuration.
> 
> I'm adding the following, so it'll be captured in the archives:
> 
> Generic demo and "works everywhere" configs have their place, and in our
> model, they are built up using the kernel features on top of a tuned baseline
> configuration. It is easier to add than to remove. So we turn on as little as
> possible, then have the kernel types, followed by kernel features triggered
> by distro or recipe space coordinated features.
> 
> The baseline machine configurations shouldn't be guessing what the distro or
> image needs, and the distro or image shouldn't be undoing things that are
> done by the baseline configuration to tune/slim it down. Those baseline
> configs need to serve all the kernel types, they are also additive (for the
> most part .. tiny is the outlier), not subtractive.
> 
> All that being said, the review and comments are exactly what I like to see.
> As we keep in mind that the machine/baseline configuration cannot possibly
> be all things to all configurations. Not all users of the kernel-cache have to
> adhere to the guidelines we have for the reference boards, kernel types,
> etc, but we can certainly try and guide them in that direction, which is the
> point of the shared repository of configuration fragments .. and that's what
> we are doing here.
> 
> What the intel boards are doing, actually is quite close to what I described
> above. These are named features, and are included versus just adding the
> configs to a giant .cfg/.scc file. That means that someone doing a new BSP
> could decide what type of functionality to build on top of the baseline "it
> boots" configuration. Maybe some of the fragments doing most of the
> including could be named a bit differently, or be split a bit .. but that is
> something we can do as different functionality needs are found on the ends
> of the new
> -> old board spectrum.
> 
> So my only real question was whether or not we can split the fragments out
> of common-pc, into a named fragment.

For the ones being added in this series, I guess we can move them to a separate 
named .scc/.cfg instead of including in intel-common- drivers.scc.

We can also create a new config for intel-skylake-64 machine (which enables 
relatively newer hardware) in meta-intel which can then turn on these features 
by default.

Or, we can just enable the features in .scc via KERNEL_FEATURES in meta-intel 
so it's easier to disable or override if required.

Please let us know what you think.

> 
> That, and I assume this is for master, since you mentioned 6.2.

Yes, this is for master/6.2.

Thanks,
Naveen

> 
> Bruce
> 
> In message: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop
> RANDOM_TRUST_CPU on 06/03/2023 Naveen Saini wrote:
> 
> > This option is no longer present in v6.2 as the following commit removed it:
> >
> https://github.com/torvalds/linux/commit/b9b01a5625b5a9e9d96d14d4a813
> a
> > 54e8a124f4b
> >
> > Signed-off-by: Naveen Saini 
> > ---
> >  bsp/intel-common/intel-common-drivers.scc | 1 -
> >  features/random/random.cfg| 2 --
> >  features/random/random.scc| 5 -
> >  kern-features.rc  | 1 -
> >  4 files changed, 9 deletions(-)
> >  delete mode 100644 features/random/random.cfg  delete mode 100644
> > features/random/random.scc
> >
> > diff --git a/bsp/intel-common/intel-common-drivers.scc
> > b/bsp/intel-common/intel-common-drivers.scc
> > index 59dc6750..33451730 100644
> > --- a/bsp/intel-common/intel-common-drivers.scc
> > +++ b/bsp/intel-common/intel-common-drivers.scc
> > @@ -85,7 +85,6 @@ include features/input/keyboard-gpio.scc  include
> > features/ciphers/ciphers.scc  include features/pci-iov/pci-iov.scc
> > include features/intel-tco/intel-tco.scc -include
> > features/random/random.scc
> >
> >  # default policy for standard kernels  include
> > cfg/usb-mass-storage.scc diff --git a/features/random/random.cfg
> > b/features/random/random.cfg deleted file mode 100644 index
> > bacab3cb..
> > --- a/features/random/random.cfg
> > +++ /dev/null
> > @@ -1,2 +0,0 @@
> > -# SPDX-License-Identifier: MIT
> > -CONFIG_RANDOM_TRUST_CPU=y
> > diff --git

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

2023-03-13 Thread Stephen Jolley

All,

 

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


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

11781

bitbake --observe-only may get KeyError

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

11899

broken 'bitbake --status-only' and 'bitbake -m' for multiple connections

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

13424

devupstream doesn't work with mutilib

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

13599

Enhancement: Detect variables that shouldn't be defined in image scope, but in 
global (distro) scope

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

13808

do_task[noexec] = "" marks task noexec, which is inconsistent with docs

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

14385

mode of sstate files created under pseudo

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

14620

QA error not seen when reusing SSTATE

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

14717

OEToolchainConfig.cmake sets wrong and unsuitable compiler flags

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

14811

Incorrect path matching in pseudo cause package failure in yocto

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

14870

Dangling bbappend behaviour can lead to unexpected surprises (error vs warn)

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.3 M1


 

14896

Current autobuilder code incompatible with buildbot 3.5.0

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

14918

Devtool fails if SRCREV is set to ${AUTOREV}

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

15010

native.bbclass is unable to clear unconditional overrides during dependency 
rewriting

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

4.2 M4


 

15008

'BitBakeXMLRPCServer' object has no attribute 'set_async_cmd'

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2 M3

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

[yocto] Enhancements/Bugs closed WW10!

2023-03-13 Thread Stephen Jolley

All,

 

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


Who

Count


richard.pur...@linuxfoundation.org

5


ross.bur...@arm.com

3


randy.macl...@windriver.com

3


Grand Total

11

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 (#59423): https://lists.yoctoproject.org/g/yocto/message/59423
Mute This Topic: https://lists.yoctoproject.org/mt/97592917/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 4.2

2023-03-13 Thread Stephen Jolley

All,

 

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


Who

Count


michael.opdenac...@bootlin.com

33


ross.bur...@arm.com

31


bruce.ashfi...@gmail.com

25


randy.macl...@windriver.com

25


david.re...@windriver.com

23


richard.pur...@linuxfoundation.org

22


jpewhac...@gmail.com

10


pa...@zhukoff.net

9


sakib.sa...@windriver.com

6


pi...@toganlabs.com

4


tim.orl...@konsulko.com

4


saul.w...@windriver.com

3


sundeep.kokko...@windriver.com

3


sundeep.kokko...@gmail.com

3


alexandre.bell...@bootlin.com

2


alexis.loth...@bootlin.com

2


yoann.con...@smile.fr

2


yash.shi...@windriver.com

2


jon.ma...@arm.com

2


rybczyn...@gmail.com

2


piotr.lob...@vm.pl

2


fawzi.kha...@smile.fr

1


louis.ran...@syslinbit.com

1


hongxu@windriver.com

1


chee.yang@intel.com

1


jens.ge...@desy.de

1


nick.ow...@eero.com

1


mathew.pro...@gmail.com

1


martin.ja...@gmail.com

1


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

1


mhalst...@linuxfoundation.org

1


st...@sakoman.com

1


thomas.per...@bootlin.com

1


geoffrey.g...@smile.fr

1


naveen.go...@windriver.com

1


tvgamb...@gmail.com

1


yashinde...@gmail.com

1


zheng@windriver.com

1


Grand Total

232

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 (#59422): https://lists.yoctoproject.org/g/yocto/message/59422
Mute This Topic: https://lists.yoctoproject.org/mt/97592840/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

2023-03-13 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 424
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,  "4.2", "4.3", "4.99" and "Future", the more pressing/urgent
issues being in "4.2" and then "4.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 (#59421): https://lists.yoctoproject.org/g/yocto/message/59421
Mute This Topic: https://lists.yoctoproject.org/mt/97592811/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] State of Yocto styleguide and oe-stylize.py script

2023-03-13 Thread Martin Jansa

On Mon, Mar 13, 2023 at 6:34 PM Alexander Kanavin 
wrote:

> There is not a lot of interest in maintaining style guides, and
> associated tooling. My personal feeling is that they don't really help
> with the truly problematic things in recipes that need a human eye (or
> chatgpt level intelligence :) - by and large people do follow
> reasonable order of entries for example, and nitpicking on an exact
> order would just be wasting precious maintainer time.
>

I agree that there are other more important things, but I also like style
(only in code - human looks are overrated :)).

If the tool is executed locally before sending the contribution (and
Carsten does seem interested in doing just that - not asking Khem to run it
on incoming patches) then I believe it can save maintainers time by sending
better patches on first try not waste it and our styleguide really needs
some TLC as Carsten found out.

The same does apply to e.g. scripts/contrib/patchreview.py.

If the missing/malformed Upstream-Status is reported to the original
contributor before he/she/it sends the patch, by some at least well
documented work flow how to submit patches, then it saves more maintainer
time, than asking for it during e-mail review or worse after the change is
merged or built by maintainer and QA check reports it's missing or
malformed.

If someone is willing to help with the tooling, we should endorse that, not
discourage them even when there are bigger-greater goals
like yocto-check-layer script you mentioned.

Cheers,

If you want to ensure good quality, making your layer pass the yocto
> compatibility script, and ensuring there are no warnings of any kind
> from bitbake when built with latest master revisions of everything is
> a better first step in my opinion.
>
> Alex
>
> On Mon, 13 Mar 2023 at 15:20, VIVAVIS AG via lists.yoctoproject.org
>  wrote:
> >
> > Hi,
> >
> > I'm wondering whether the styleguide
> www.openembedded.org/wiki/Styleguide,
> > meta-openembedded/contrib/oe-stylize.py or none of them is the source of
> > truth for writing a good recipe.
> >
> > E.g., if you run oe-stylize.py, the SRCREV variable is placed above
> SRC_URI,
> > or RDEPENDS is placed above FILES, which is not what the Wiki documents.
> > And there are more discrepancies of this type.
> >
> > Furthermore, the script doesn't know the FILESEXTRAPATHS variable in
> bbappend files
> > and moves it to the end of my recipe. Well, this is not decribed in the
> Wiki, but a look
> > into append files in meta-openembedded shows, that it is common pactice
> to put
> > FILESEXTRAPATHS in the first line of the recipe.
> >
> > The Wiki has an interesting note and the end: "You can run
> contrib/oe-stylize.py from
> > meta-oe on your recipes before submitting them; however it is not
> necessarily up-to-date
> > with all current style conventions. This page should be considered the
> canonical reference."
> >
> > Furthermore, there's github.com/openembedded/meta-openembedded/pull/465
> > providing another ruleset for the new linter.
> >
> > So, my question to the Yocto maintainers is, what is the current state
> of the styleguide
> > and oe-stylize.py? Are there plans to synchronize them?
> >
> > Thanks for clarification.
> >
> > Carsten Stelling
> >
> >
> >
>
> 
>
>

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

Re: [yocto] State of Yocto styleguide and oe-stylize.py script

2023-03-13 Thread Alexander Kanavin

There is not a lot of interest in maintaining style guides, and
associated tooling. My personal feeling is that they don't really help
with the truly problematic things in recipes that need a human eye (or
chatgpt level intelligence :) - by and large people do follow
reasonable order of entries for example, and nitpicking on an exact
order would just be wasting precious maintainer time.

If you want to ensure good quality, making your layer pass the yocto
compatibility script, and ensuring there are no warnings of any kind
from bitbake when built with latest master revisions of everything is
a better first step in my opinion.

Alex

On Mon, 13 Mar 2023 at 15:20, VIVAVIS AG via lists.yoctoproject.org
 wrote:
>
> Hi,
>
> I'm wondering whether the styleguide www.openembedded.org/wiki/Styleguide,
> meta-openembedded/contrib/oe-stylize.py or none of them is the source of
> truth for writing a good recipe.
>
> E.g., if you run oe-stylize.py, the SRCREV variable is placed above SRC_URI,
> or RDEPENDS is placed above FILES, which is not what the Wiki documents.
> And there are more discrepancies of this type.
>
> Furthermore, the script doesn't know the FILESEXTRAPATHS variable in bbappend 
> files
> and moves it to the end of my recipe. Well, this is not decribed in the Wiki, 
> but a look
> into append files in meta-openembedded shows, that it is common pactice to put
> FILESEXTRAPATHS in the first line of the recipe.
>
> The Wiki has an interesting note and the end: "You can run 
> contrib/oe-stylize.py from
> meta-oe on your recipes before submitting them; however it is not necessarily 
> up-to-date
> with all current style conventions. This page should be considered the 
> canonical reference."
>
> Furthermore, there's github.com/openembedded/meta-openembedded/pull/465
> providing another ruleset for the new linter.
>
> So, my question to the Yocto maintainers is, what is the current state of the 
> styleguide
> and oe-stylize.py? Are there plans to synchronize them?
>
> Thanks for clarification.
>
> Carsten Stelling
>
> 
>

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

Re: [yocto] State of Yocto styleguide and oe-stylize.py script

2023-03-13 Thread Khem Raj


On 3/13/23 7:20 AM, VIVAVIS AG via lists.yoctoproject.org wrote:

Hi,

I'm wondering whether the styleguide www.openembedded.org/wiki/Styleguide,
meta-openembedded/contrib/oe-stylize.py or none of them is the source of
truth for writing a good recipe.

E.g., if you run oe-stylize.py, the SRCREV variable is placed above SRC_URI,
or RDEPENDS is placed above FILES, which is not what the Wiki documents.
And there are more discrepancies of this type.

Furthermore, the script doesn't know the FILESEXTRAPATHS variable in bbappend 
files
and moves it to the end of my recipe. Well, this is not decribed in the Wiki, 
but a look
into append files in meta-openembedded shows, that it is common pactice to put
FILESEXTRAPATHS in the first line of the recipe.

The Wiki has an interesting note and the end: "You can run 
contrib/oe-stylize.py from
meta-oe on your recipes before submitting them; however it is not necessarily 
up-to-date
with all current style conventions. This page should be considered the canonical 
reference."

Furthermore, there's github.com/openembedded/meta-openembedded/pull/465
providing another ruleset for the new linter.

So, my question to the Yocto maintainers is, what is the current state of the 
styleguide
and oe-stylize.py? Are there plans to synchronize them?


oe-stylize.py is still the linter of choice but as you have noted it has 
been lacking on certain areas and wiki should be updated to match what 
it produces. It does need some TLC and patches are welcome.




Thanks for clarification.

Carsten Stelling







OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

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

[yocto] [yocto-autobuilder-helper][PATCH 8/8] config: flag A. Belloni master-next branch as testing branch

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

Add "abelloni/master-next" branch from poky-contrib in configuration so that
regression reports are generated when testing for patches

Signed-off-by: Alexis Lothoré 
---
 config.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 687608d..fcd0588 100644
--- a/config.json
+++ b/config.json
@@ -6,7 +6,7 @@
 "BUILD_HISTORY_DIR" : "buildhistory",
 "BUILD_HISTORY_REPO" : 
"ssh://g...@push.yoctoproject.org/poky-buildhistory",
 "BUILD_HISTORY_DIRECTPUSH" : ["poky:morty", "poky:pyro", "poky:rocko", 
"poky:sumo", "poky:thud", "poky:warrior", "poky:zeus", "poky:dunfell", 
"poky:gatesgarth", "poky:hardknott", "poky:honister", "poky:kirkstone", 
"poky:langdale", "poky:master"],
-"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master", 
"poky:master-next" : "poky:master"},
+"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master", 
"poky-contrib:abelloni/master-next": "poky/master", "poky:master-next" : 
"poky:master"},
 
 "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;,
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 6/8] scripts/send-qa-email: fix testing branches regression reporting

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

d6018b891a3b7c62c7a2883c7fb9ae55e66f1363 broke regression reporting for testing
branches (e.g: master-next in poky, ross/mut in poky-contrib) by ignoring the 
comparebranch returned by
utils.getcomparison branch

Fix regression reporting for those branches by using comparebranch again. The
fix also refactor/add a intermediary step to guess base and target for
regression reporting, to isolate a bit the logic and make it easier later to add
multiple base/target couples

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 540eb94..78e051a 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -49,18 +49,28 @@ def get_previous_tag(targetrepodir, version):
 defaultbaseversion, _, _ = 
utils.get_version_from_string(subprocess.check_output(["git", "describe", 
"--abbrev=0"], cwd=targetrepodir).decode('utf-8').strip())
 return utils.get_tag_from_version(defaultbaseversion, None)
 
-def generate_regression_report(querytool, targetrepodir, basebranch, 
resultdir, outputdir, yoctoversion):
-baseversion = get_previous_tag(targetrepodir, yoctoversion)
-print(f"Comparing {basebranch} to {baseversion}")
+def get_regression_base_and_target(basebranch, comparebranch, release, 
targetrepodir):
+if not basebranch:
+# Basebranch/comparebranch is an arbitrary configuration (not defined 
in config.json): do not run regression reporting
+return None, None
+
+if is_release_version(release):
+# We are on a release: ignore comparebranch (which is very likely 
None), regression reporting must be done against previous tag
+return get_previous_tag(targetrepodir, release), basebranch
+elif comparebranch:
+# Basebranch/comparebranch is defined in config.json: regression 
reporting must be done against branches as defined in config.json
+return comparebranch, basebranch
+
+def generate_regression_report(querytool, targetrepodir, base, target, 
resultdir, outputdir):
+print(f"Comparing {target} to {base}")
 
 try:
-regreport = subprocess.check_output([querytool, "regression-report", 
baseversion, basebranch, '-t', resultdir])
+regreport = subprocess.check_output([querytool, "regression-report", 
base, target, '-t', resultdir])
 with open(outputdir + "/testresult-regressions-report.txt", "wb") as f:
f.write(regreport)
 except subprocess.CalledProcessError as e:
 error = str(e)
-print(f"Error while generating report between {basebranch} and 
{baseversion} : {error}")
-
+print(f"Error while generating report between {target} and {base} : 
{error}")
 
 def send_qa_email():
 parser = utils.ArgParser(description='Process test results and optionally 
send an email about the build to prompt QA to begin testing.')
@@ -142,8 +152,9 @@ def send_qa_email():
 subprocess.check_call(["git", "push", "--all"], cwd=tempdir)
 subprocess.check_call(["git", "push", "--tags"], cwd=tempdir)
 
-if basebranch:
-generate_regression_report(querytool, targetrepodir, 
basebranch, tempdir, args.results_dir, args.release)
+regression_base, regression_target = 
get_regression_base_and_target(basebranch, comparebranch, args.release, 
targetrepodir)
+if regression_base and regression_target:
+generate_regression_report(querytool, targetrepodir, 
regression_base, regression_target, tempdir, args.results_dir)
 
 finally:
 subprocess.check_call(["rm", "-rf",  tempdir])
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 7/8] scripts/test_send_qa_email.py: add tests for base/target pair guessing

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

Signed-off-by: Alexis Lothoré 
---
 scripts/test_send_qa_email.py | 21 +
 1 file changed, 21 insertions(+)

diff --git a/scripts/test_send_qa_email.py b/scripts/test_send_qa_email.py
index 48bca98..ccdcba6 100755
--- a/scripts/test_send_qa_email.py
+++ b/scripts/test_send_qa_email.py
@@ -35,6 +35,21 @@ class TestVersion(unittest.TestCase):
 {"input": None, "expected":False}
 ]
 
+# This data represent real data returned by utils.getcomparisonbranch
+# and the release argument passed to send-qa-email script
+regression_inputs = [
+{"name": "Arbitrary branch", "input": {"basebranch": None,
+   "comparebranch": None, 
"release": None}, "expected": (None, None)},
+{"name": "Master release", "input": {"basebranch": "master",
+ "comparebranch": None, "release": 
"yocto-4.2_M3.rc1"}, "expected": ("4.2_M2", "master")},
+{"name": "Older release", "input": {"basebranch": "kirkstone",
+"comparebranch": None, "release": 
"yocto-4.0.8.rc2"}, "expected": ("yocto-4.0.7", "kirkstone")},
+{"name": "Master Next", "input": {"basebranch": "master-next",
+  "comparebranch": "master", 
"release": None}, "expected": ("master", "master-next")},
+{"name": "Fork Master Next", "input": {"basebranch": "ross/mut",
+   "comparebranch": "master", 
"release": None}, "expected": ("master", "ross/mut")},
+]
+
 def test_versions(self):
 for data in self.test_data_get_version:
 test_name = data["input"]["version"]
@@ -47,6 +62,12 @@ class TestVersion(unittest.TestCase):
 with self.subTest(f"{data['input']}"):
 
self.assertEqual(send_qa_email.is_release_version(data['input']), 
data['expected'])
 
+def test_get_regression_base_and_target(self):
+for data in self.regression_inputs:
+with self.subTest(data['name']):
+self.assertEqual(send_qa_email.get_regression_base_and_target(
+data['input']['basebranch'], 
data['input']['comparebranch'], data['input']['release'], 
os.environ.get("POKY_PATH")), data['expected'])
+
 if __name__ == '__main__':
 if os.environ.get("POKY_PATH") is None:
 print("Please set POKY_PATH to proper poky clone location before 
running tests")
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 5/8] scripts/send-qa-email: add tests for is_release_version

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

Signed-off-by: Alexis Lothoré 
---
 scripts/test_send_qa_email.py | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/scripts/test_send_qa_email.py b/scripts/test_send_qa_email.py
index c1347fb..48bca98 100755
--- a/scripts/test_send_qa_email.py
+++ b/scripts/test_send_qa_email.py
@@ -29,6 +29,12 @@ class TestVersion(unittest.TestCase):
 {"input": {"version": "4.1.rc4"}, "expected": "yocto-4.0"}
 ]
 
+test_data_is_release_version = [
+{"input": "yocto-4.2", "expected":True},
+{"input": "20230313-15", "expected":False},
+{"input": None, "expected":False}
+]
+
 def test_versions(self):
 for data in self.test_data_get_version:
 test_name = data["input"]["version"]
@@ -36,6 +42,10 @@ class TestVersion(unittest.TestCase):
 self.assertEqual(send_qa_email.get_previous_tag(os.environ.get(
 "POKY_PATH"), data["input"]["version"]), data["expected"])
 
+def test_is_release_version(self):
+for data in self.test_data_is_release_version:
+with self.subTest(f"{data['input']}"):
+
self.assertEqual(send_qa_email.is_release_version(data['input']), 
data['expected'])
 
 if __name__ == '__main__':
 if os.environ.get("POKY_PATH") is None:
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 4/8] scripts/send-qa-email: protect is_release_version from None value

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 320ff24..540eb94 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -16,7 +16,7 @@ import utils
 
 def is_release_version(version):
 p = re.compile('\d{8}-\d+')
-return p.match(version) is None
+return version is not None and p.match(version) is None
 
 def get_previous_tag(targetrepodir, version):
 previousversion = None
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 0/8] fix regression reports generation on "master-next" branches

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

This series fixes regression report generation on "next" branches, as raised in
[1].

The first five patches are preparatory updates for the real fix, being either
refactoring, cleanup or unit tests addition to better understand how integration
branches are used in send-qa-email.
The proper fix is in 6th commit, followed by corresponding tests
Finally, the last commit add Alexandre's "next" branch as "fork" branches to
enable regression reports generation when testing patches, as suggested in [1]
too.

Since patch testing branches are force-pushed on a regular basis, it is quite
difficult to get a relevant testing scenario, so this series has been tested by
faking SHA1 in yocto_testresults_query to match some master-next results in
yocto-testresults at the time of testing this series. I would gladly take
feedback about this series running for real in a master-next branch

[1] https://lists.yoctoproject.org/g/yocto/message/59067

Alexis Lothoré (8):
  scripts/utils: add unit tests for getcomparisonbranch
  scripts/send-qa-email: remove unused variable
  scripts/send-qa-email: invert boolean logic for release check
  scripts/send-qa-email: protect is_release_version from None value
  scripts/send-qa-email: add tests for is_release_version
  scripts/send-qa-email: fix testing branches regression reporting
  scripts/test_send_qa_email.py: add tests for base/target pair guessing
  config: flag A. Belloni master-next branch as testing branch

 config.json   |   2 +-
 scripts/send_qa_email.py  |  34 +++
 scripts/test_send_qa_email.py |  31 ++
 scripts/test_utils.py | 104 ++
 4 files changed, 158 insertions(+), 13 deletions(-)
 create mode 100755 scripts/test_utils.py

-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 2/8] scripts/send-qa-email: remove unused variable

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 7999c1b..96225a8 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -83,7 +83,6 @@ def send_qa_email():
 
 args = parser.parse_args()
 
-scriptsdir = os.path.dirname(os.path.realpath(__file__))
 ourconfig = utils.loadconfig()
 
 with open(args.repojson) as f:
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper][PATCH 1/8] scripts/utils: add unit tests for getcomparisonbranch

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

Signed-off-by: Alexis Lothoré 
---
 scripts/test_utils.py | 104 ++
 1 file changed, 104 insertions(+)
 create mode 100755 scripts/test_utils.py

diff --git a/scripts/test_utils.py b/scripts/test_utils.py
new file mode 100755
index 000..ab91e3b
--- /dev/null
+++ b/scripts/test_utils.py
@@ -0,0 +1,104 @@
+#!/usr/bin/env python3
+
+import os
+import unittest
+import utils
+
+
+class TestGetComparisonBranch(unittest.TestCase):
+TEST_CONFIG = {
+"BUILD_HISTORY_DIRECTPUSH": [
+"poky:morty",
+"poky:pyro",
+"poky:rocko",
+"poky:sumo",
+"poky:thud",
+"poky:warrior",
+"poky:zeus",
+"poky:dunfell",
+"poky:gatesgarth",
+"poky:hardknott",
+"poky:honister",
+"poky:kirkstone",
+"poky:langdale",
+"poky:master"
+], "BUILD_HISTORY_FORKPUSH": {
+"poky-contrib:ross/mut": "poky:master",
+"poky:master-next": "poky:master",
+"poky-contrib:abelloni/master-next": "poky:master"
+}
+}
+
+def test_release_master(self):
+repo = "ssh://g...@push.yoctoproject.org/poky"
+branch = "master"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(
+basebranch, "master", msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding base branch")
+self.assertEqual(
+comparebranch, None, msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding compare branch")
+
+def test_release_kirkstone(self):
+repo = "ssh://g...@push.yoctoproject.org/poky"
+branch = "kirkstone"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(basebranch, "kirkstone",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding base branch")
+self.assertEqual(
+comparebranch, None, msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding compare branch")
+
+def test_release_langdale(self):
+repo = "ssh://g...@push.yoctoproject.org/poky"
+branch = "langdale"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(basebranch, "langdale",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding base branch")
+self.assertEqual(
+comparebranch, None, msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding compare branch")
+
+def test_master_next(self):
+repo = "ssh://g...@push.yoctoproject.org/poky"
+branch = "master-next"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(basebranch, "master-next",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_FORKPUSH must return corresponding base branch")
+self.assertEqual(comparebranch, "master",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_FORKPUSH must return corresponding compare branch")
+
+def test_abelloni_master_next(self):
+repo = "ssh://g...@push.yoctoproject.org/poky-contrib"
+branch = "abelloni/master-next"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(basebranch, "abelloni/master-next",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_FORKPUSH must return corresponding base branch")
+self.assertEqual(comparebranch, "master",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_FORKPUSH must return corresponding compare branch")
+
+def test_ross_master_next(self):
+repo = "ssh://g...@push.yoctoproject.org/poky-contrib"
+branch = "ross/mut"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(basebranch, "ross/mut",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_FORKPUSH must return corresponding base branch")
+self.assertEqual(comparebranch, "master",
+ msg="Repo/branch pair present in 
BUILD_HISTORY_FORKPUSH must return corresponding compare branch")
+
+def test_arbitrary_branch(self):
+repo = "ssh://g...@push.yoctoproject.org/poky-contrib"
+branch = "akanavin/package-version-updates"
+basebranch, comparebranch = utils.getcomparisonbranch(
+self.TEST_CONFIG, repo, branch)
+self.assertEqual(
+basebranch, None,

[yocto] [yocto-autobuilder-helper][PATCH 3/8] scripts/send-qa-email: invert boolean logic for release check

2023-03-13 Thread Alexis Lothoré via lists . yoctoproject . org

From: Alexis Lothoré 

is_non_release_version has an inverted logic which makes its reuse quite
confusing

Transform it as is_release_version and let caller do the negation if needed

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 96225a8..320ff24 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -14,15 +14,15 @@ import re
 
 import utils
 
-def is_non_release_version(version):
+def is_release_version(version):
 p = re.compile('\d{8}-\d+')
-return p.match(version) is not None
+return p.match(version) is None
 
 def get_previous_tag(targetrepodir, version):
 previousversion = None
 previousmilestone = None
 if version:
-if is_non_release_version(version):
+if not is_release_version(version):
 return subprocess.check_output(["git", "describe", "--abbrev=0"], 
cwd=targetrepodir).decode('utf-8').strip()
 compareversion, comparemilestone, _ = 
utils.get_version_from_string(version)
 compareversionminor = compareversion[-1]
-- 
2.39.2


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

[yocto] State of Yocto styleguide and oe-stylize.py script

2023-03-13 Thread VIVAVIS AG via lists.yoctoproject.org

Hi,

I'm wondering whether the styleguide www.openembedded.org/wiki/Styleguide,
meta-openembedded/contrib/oe-stylize.py or none of them is the source of
truth for writing a good recipe.

E.g., if you run oe-stylize.py, the SRCREV variable is placed above SRC_URI,
or RDEPENDS is placed above FILES, which is not what the Wiki documents.
And there are more discrepancies of this type.

Furthermore, the script doesn't know the FILESEXTRAPATHS variable in bbappend 
files
and moves it to the end of my recipe. Well, this is not decribed in the Wiki, 
but a look
into append files in meta-openembedded shows, that it is common pactice to put
FILESEXTRAPATHS in the first line of the recipe.

The Wiki has an interesting note and the end: "You can run 
contrib/oe-stylize.py from
meta-oe on your recipes before submitting them; however it is not necessarily 
up-to-date
with all current style conventions. This page should be considered the 
canonical reference."

Furthermore, there's github.com/openembedded/meta-openembedded/pull/465
providing another ruleset for the new linter.

So, my question to the Yocto maintainers is, what is the current state of the 
styleguide
and oe-stylize.py? Are there plans to synchronize them?

Thanks for clarification.

Carsten Stelling

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

Re: [linux-yocto] [PATCH] tty: serial: fsl_lpuart: don't break the on-going transfer when global reset

2023-03-13 Thread Xiaolei Wang

Hi bruce

Please help merge this patch to v5.15/standard/nxp-sdk-5.15/nxp-soc and 
v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc branches

thanks
xiaolei

From: linux-yocto@lists.yoctoproject.org  
on behalf of Xiaolei Wang via lists.yoctoproject.org 

Sent: Monday, March 13, 2023 9:44 PM
To: bruce.ashfi...@gmail.com 
Cc: linux-yocto@lists.yoctoproject.org 
Subject: [linux-yocto] [PATCH] tty: serial: fsl_lpuart: don't break the 
on-going transfer when global reset

From: Sherry Sun 

commit 76bad3f88750f8cc465c489e6846249e0bc3d8f5 from upstream.

lpuart_global_reset() shouldn't break the on-going transmit engine, need
to recover the on-going data transfer after reset.

This can help earlycon here, since commit 60f361722ad2 ("serial:
fsl_lpuart: Reset prior to registration") moved lpuart_global_reset()
before uart_add_one_port(), earlycon is writing during global reset,
as global reset will disable the TX and clear the baud rate register,
which caused the earlycon cannot work any more after reset, needs to
restore the baud rate and re-enable the transmitter to recover the
earlycon write.

Also move the lpuart_global_reset() down, then we can reuse the
lpuart32_tx_empty() without declaration.

Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp 
and imx8qxp")
Signed-off-by: Sherry Sun 
Link: https://lore.kernel.org/r/20221024085844.22786-1-sherry@nxp.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Xiaolei Wang 
---
 drivers/tty/serial/fsl_lpuart.c | 75 +
 1 file changed, 48 insertions(+), 27 deletions(-)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 3f8fe874905d..5eae048950b5 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -433,33 +433,6 @@ static unsigned int lpuart_get_baud_clk_rate(struct 
lpuart_port *sport)
 #define lpuart_enable_clks(x)   __lpuart_enable_clks(x, true)
 #define lpuart_disable_clks(x)  __lpuart_enable_clks(x, false)

-static int lpuart_global_reset(struct lpuart_port *sport)
-{
-   struct uart_port *port = >port;
-   void __iomem *global_addr;
-   int ret;
-
-   if (uart_console(port))
-   return 0;
-
-   ret = clk_prepare_enable(sport->ipg_clk);
-   if (ret) {
-   dev_err(sport->port.dev, "failed to enable uart ipg clk: %d\n", 
ret);
-   return ret;
-   }
-
-   if (is_imx7ulp_lpuart(sport) || is_imx8ulp_lpuart(sport) || 
is_imx8qxp_lpuart(sport)) {
-   global_addr = port->membase + UART_GLOBAL - IMX_REG_OFF;
-   writel(UART_GLOBAL_RST, global_addr);
-   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
-   writel(0, global_addr);
-   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
-   }
-
-   clk_disable_unprepare(sport->ipg_clk);
-   return 0;
-}
-
 static void lpuart_stop_tx(struct uart_port *port)
 {
 unsigned char temp;
@@ -2845,6 +2818,54 @@ static int lpuart_attach_pd(struct device *dev)
 return 0;
 }

+static int lpuart_global_reset(struct lpuart_port *sport)
+{
+   struct uart_port *port = >port;
+   void __iomem *global_addr;
+   unsigned long ctrl, bd;
+   unsigned int val = 0;
+   int ret;
+
+   ret = clk_prepare_enable(sport->ipg_clk);
+   if (ret) {
+   dev_err(sport->port.dev, "failed to enable uart ipg clk: %d\n", 
ret);
+   return ret;
+   }
+
+   if (is_imx7ulp_lpuart(sport) || is_imx8qxp_lpuart(sport)) {
+   /*
+* If the transmitter is used by earlycon, wait for transmit 
engine to
+* complete and then reset.
+   */
+   ctrl = lpuart32_read(port, UARTCTRL);
+   if (ctrl & UARTCTRL_TE) {
+   bd = lpuart32_read(>port, UARTBAUD);
+   if (read_poll_timeout(lpuart32_tx_empty, val, val, 1, 
10, false,
+   port)) {
+   dev_warn(sport->port.dev,
+   "timeout waiting for transmit engine to 
complete\n");
+   clk_disable_unprepare(sport->ipg_clk);
+   return 0;
+   }
+   }
+
+   global_addr = port->membase + UART_GLOBAL - IMX_REG_OFF;
+   writel(UART_GLOBAL_RST, global_addr);
+   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
+   writel(0, global_addr);
+   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
+
+   /* Recover the transmitter for earlycon. */
+   if (ctrl & UARTCTRL_TE) {
+   lpuart32_write(port, bd, UARTBAUD);
+   lpuart32_write(port, ctrl, UARTCTRL);
+   }
+

[linux-yocto] [PATCH] tty: serial: fsl_lpuart: don't break the on-going transfer when global reset

2023-03-13 Thread Xiaolei Wang

From: Sherry Sun 

commit 76bad3f88750f8cc465c489e6846249e0bc3d8f5 from upstream.

lpuart_global_reset() shouldn't break the on-going transmit engine, need
to recover the on-going data transfer after reset.

This can help earlycon here, since commit 60f361722ad2 ("serial:
fsl_lpuart: Reset prior to registration") moved lpuart_global_reset()
before uart_add_one_port(), earlycon is writing during global reset,
as global reset will disable the TX and clear the baud rate register,
which caused the earlycon cannot work any more after reset, needs to
restore the baud rate and re-enable the transmitter to recover the
earlycon write.

Also move the lpuart_global_reset() down, then we can reuse the
lpuart32_tx_empty() without declaration.

Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp 
and imx8qxp")
Signed-off-by: Sherry Sun 
Link: https://lore.kernel.org/r/20221024085844.22786-1-sherry@nxp.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Xiaolei Wang 
---
 drivers/tty/serial/fsl_lpuart.c | 75 +
 1 file changed, 48 insertions(+), 27 deletions(-)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 3f8fe874905d..5eae048950b5 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -433,33 +433,6 @@ static unsigned int lpuart_get_baud_clk_rate(struct 
lpuart_port *sport)
 #define lpuart_enable_clks(x)  __lpuart_enable_clks(x, true)
 #define lpuart_disable_clks(x) __lpuart_enable_clks(x, false)
 
-static int lpuart_global_reset(struct lpuart_port *sport)
-{
-   struct uart_port *port = >port;
-   void __iomem *global_addr;
-   int ret;
-
-   if (uart_console(port))
-   return 0;
-
-   ret = clk_prepare_enable(sport->ipg_clk);
-   if (ret) {
-   dev_err(sport->port.dev, "failed to enable uart ipg clk: %d\n", 
ret);
-   return ret;
-   }
-
-   if (is_imx7ulp_lpuart(sport) || is_imx8ulp_lpuart(sport) || 
is_imx8qxp_lpuart(sport)) {
-   global_addr = port->membase + UART_GLOBAL - IMX_REG_OFF;
-   writel(UART_GLOBAL_RST, global_addr);
-   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
-   writel(0, global_addr);
-   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
-   }
-
-   clk_disable_unprepare(sport->ipg_clk);
-   return 0;
-}
-
 static void lpuart_stop_tx(struct uart_port *port)
 {
unsigned char temp;
@@ -2845,6 +2818,54 @@ static int lpuart_attach_pd(struct device *dev)
return 0;
 }
 
+static int lpuart_global_reset(struct lpuart_port *sport)
+{
+   struct uart_port *port = >port;
+   void __iomem *global_addr;
+   unsigned long ctrl, bd;
+   unsigned int val = 0;
+   int ret;
+
+   ret = clk_prepare_enable(sport->ipg_clk);
+   if (ret) {
+   dev_err(sport->port.dev, "failed to enable uart ipg clk: %d\n", 
ret);
+   return ret;
+   }
+
+   if (is_imx7ulp_lpuart(sport) || is_imx8qxp_lpuart(sport)) {
+   /*
+* If the transmitter is used by earlycon, wait for transmit 
engine to
+* complete and then reset.
+   */
+   ctrl = lpuart32_read(port, UARTCTRL);
+   if (ctrl & UARTCTRL_TE) {
+   bd = lpuart32_read(>port, UARTBAUD);
+   if (read_poll_timeout(lpuart32_tx_empty, val, val, 1, 
10, false,
+   port)) {
+   dev_warn(sport->port.dev,
+   "timeout waiting for transmit engine to 
complete\n");
+   clk_disable_unprepare(sport->ipg_clk);
+   return 0;
+   }
+   }
+
+   global_addr = port->membase + UART_GLOBAL - IMX_REG_OFF;
+   writel(UART_GLOBAL_RST, global_addr);
+   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
+   writel(0, global_addr);
+   usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
+
+   /* Recover the transmitter for earlycon. */
+   if (ctrl & UARTCTRL_TE) {
+   lpuart32_write(port, bd, UARTBAUD);
+   lpuart32_write(port, ctrl, UARTCTRL);
+   }
+   
}
+
+   clk_disable_unprepare(sport->ipg_clk);
+   return 0;
+}
+
 static int lpuart_probe(struct platform_device *pdev)
 {
const struct lpuart_soc_data *sdata = 
of_device_get_match_data(>dev);
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12254): 
https://lists.yoctoproject.org/g/linux-yocto/message/12254
Mute This Topic: https://lists.yoctoproject.org/mt/97580546/21656
Group Owner:

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.1.3.rc1)

2023-03-13 Thread Jing Hui Tham

Hi All,
 
QA for yocto-4.1.3.rc1 is completed. This is the full report for this release:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
 
=== Summary 
No high milestone defects.
 
No new issue found. 
 
Thanks,
Jing Hui



> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Tuesday, 7 March, 2023 3:43 PM
> To: yocto@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder 
> build
> (yocto-4.1.3.rc1)
> 
> 
> A build flagged for QA (yocto-4.1.3.rc1) was completed on the autobuilder and 
> is
> available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.1.3.rc1
> 
> 
> Build hash information:
> 
> bitbake: 592ee222a1c6da42925fb56801f226884b6724ec
> meta-agl: 09135164a21a216c6e3e75d7decce896b92962f0
> meta-arm: 04071ec9f5091ec76da202ce610e256d8d347a60
> meta-aws: 93a2f788e773b36d9813243d2164987c040d6cf4
> meta-intel: de84b34a9596aa96f9cc4c187efebdccc6690d06
> meta-mingw: b0067202db8573df3d23d199f82987cebe1bee2c
> meta-openembedded: b5b732876da1885ecbab2aa45f80d7a3086c5262
> meta-virtualization: d1cbc4c9fc44f0c5994a1276e38cdbb7bdb5bbd3
> oecore: b995ea45773211bd7bdd60eabcc9bbffda6beb5c
> poky: 91d0157d6daf4ea61d6b4e090c0b682d3f3ca60f
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


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

Re: [yocto] setup in Ubuntu on VMWare #ubuntu

2023-03-13 Thread Janne Kiiskila

Hei,

Indeed – same as natively. However, the VMWare slowed it down by some 50% vs. 
running the same build on the same machine natively (in my case Ubuntu 20.04).

Best Regards,


Janne Kiiskilä

From: yocto@lists.yoctoproject.org  On Behalf Of 
Mike via lists.yoctoproject.org
Sent: sunnuntai 12. maaliskuuta 2023 12.24
To: Crane 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] setup in Ubuntu on VMWare #ubuntu

I've done this in the past.  Build time in that environment is painfully slow 
(an entire day using a decent machine).

On Sat, Mar 11, 2023, 10:52 PM Crane 
mailto:crane2...@gmail.com>> wrote:
Hello,

I want to run Yocto project build on Ubuntu 22.04 running on VMWare. In the 
documentation at this 
link,
 there are three cases, but none of them is for Linux running on virtual 
machine.
I wonder if it belongs to the category of "Native Linux Host". If not, how to 
set up Ubuntu 22.04 on VMWare.

Thanks!
Crane


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

Re: [linux-yocto] [kernel-cache][PATCH 10/11] common-pc: Enable DesignWare PWM & SPI Controller support

Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU

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

[yocto] Enhancements/Bugs closed WW10!

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

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

Re: [yocto] State of Yocto styleguide and oe-stylize.py script

Re: [yocto] State of Yocto styleguide and oe-stylize.py script

Re: [yocto] State of Yocto styleguide and oe-stylize.py script

[yocto] [yocto-autobuilder-helper][PATCH 8/8] config: flag A. Belloni master-next branch as testing branch

[yocto] [yocto-autobuilder-helper][PATCH 6/8] scripts/send-qa-email: fix testing branches regression reporting

[yocto] [yocto-autobuilder-helper][PATCH 7/8] scripts/test_send_qa_email.py: add tests for base/target pair guessing

[yocto] [yocto-autobuilder-helper][PATCH 5/8] scripts/send-qa-email: add tests for is_release_version

[yocto] [yocto-autobuilder-helper][PATCH 4/8] scripts/send-qa-email: protect is_release_version from None value

[yocto] [yocto-autobuilder-helper][PATCH 0/8] fix regression reports generation on "master-next" branches

[yocto] [yocto-autobuilder-helper][PATCH 2/8] scripts/send-qa-email: remove unused variable

[yocto] [yocto-autobuilder-helper][PATCH 1/8] scripts/utils: add unit tests for getcomparisonbranch

[yocto] [yocto-autobuilder-helper][PATCH 3/8] scripts/send-qa-email: invert boolean logic for release check

[yocto] State of Yocto styleguide and oe-stylize.py script

Re: [linux-yocto] [PATCH] tty: serial: fsl_lpuart: don't break the on-going transfer when global reset

[linux-yocto] [PATCH] tty: serial: fsl_lpuart: don't break the on-going transfer when global reset

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.1.3.rc1)

Re: [yocto] setup in Ubuntu on VMWare #ubuntu

23 matches

Site Navigation

Mail list logo

Footer information