Re: [yocto] It is failed to build v6.6/standard/nxp-sdk-6.6/nxp-soc

[Bruce Ashfield]

Use the linux-yocto mailing list.

The Wind River team contributes those BSPs and should be able to identify
and help with the issue.

Bruce

On Thu, Sep 19, 2024 at 5:01 AM leimaohui via lists.yoctoproject.org
 wrote:

> Hi,
>
> I tried to build the last v6.6/standard/nxp-sdk-6.6/nxp-soc
> (9e20a24ffe9be528c1b9529763ef053239eca34f), but met error as the following.
> Should I submit this issue here?
> -
> Error: arch/arm64/boot/dts/freescale/imx8mp-evk.dts:12.1-2 syntax error
> FATAL ERROR: Unable to parse input tree
> make[3]: *** [scripts/Makefile.lib:423:
> arch/arm64/boot/dts/freescale/imx8mp-evk.dtb] Error 1
> make[2]: *** [scripts/Makefile.build:480: arch/arm64/boot/dts/freescale]
> Error 2
> make[2]: *** Waiting for unfinished jobs
> -
>
>
> Best regards
> Lei
>
> 
>
>

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

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

Re: [linux-yocto] [yocto-kernel-cache]: nxp-ls1028: enable dependency config for CONFIG_MTD_NAND_FSL_IFC

[Bruce Ashfield]

In message: [yocto-kernel-cache]: nxp-ls1028: enable dependency config for 
CONFIG_MTD_NAND_FSL_IFC
on 02/09/2024 Meng Li wrote:

> From: Limeng 
> 
> Hi Bruce,
> 
> This patch is used to enable dependency config for CONFIG_MTD_NAND_FSL_IFC.

merged.

Bruce

> 
> Could you please help to merge this patch into yocto-kernel-cache, branch is 
> only yocto-6.6?
> 
> diffstat info as below:
> 
>  nxp-ls1028.cfg |2 ++
>  1 file changed, 2 insertions(+)
> 
> 
> thanks,
> Limeng

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14352): 
https://lists.yoctoproject.org/g/linux-yocto/message/14352
Mute This Topic: https://lists.yoctoproject.org/mt/108223829/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][linux-yocto v6.1] kernel code for marvell octeon [RT]

[Bruce Ashfield]

In message: [linux-yocto][linux-yocto v6.1] kernel code for marvell octeon [RT]
on 02/09/2024 Bo Sun wrote:

> Hi Bruce,
> 
> Could you please assist with merging code into our linux-yocto repository?
> The details are as follows:
> 
> Repository:
> linux-yocto
> Branch:
> v6.1/standard/preempt-rt/cn-sdkv6.1/octeon

merged.

Bruce

> 
> Thank you for your help.
> 
> Best regards,
> Bo
> 
> 
> The following changes since commit 959e25b0411ada0ff79b9c3bf53a4119d18e430d:
> 
>   Merge branch 'v6.1/standard/preempt-rt/cn-sdkv6.1/octeon-merge' into 
> v6.1/standard/preempt-rt/cn-sdkv6.1/octeon (2024-08-26 22:23:49 -0400)
> 
> are available in the Git repository at:
> 
>   https://git.sr.ht/~bsun/linux-yocto 
> v6.1/standard/preempt-rt/cn-sdkv6.1/octeon
> 
> for you to fetch changes up to 4695d7af450a1e1b2f2e6267491eef09ff246971:
> 
>   octeontx2-af: RPM: Read proper counters for RS-FEC (2024-09-02 04:05:37 
> +)
> 
> 
> Amit Singh Tomar (3):
>   fs/resctrl: check for monitoring capability
>   arm_mpam: Fix lock related warnings
>   arm_mpam: extend SRCU critical section to debugfs
> 
> Geetha sowjanya (4):
>   Marvell: cn20k: Add cn20k silicon check
>   octeontx2-af: Fix APR entry in debugfs
>   octeontx2-af: cn20k: Add block discovery register
>   octeontx2-pf: Fix representor interface name
> 
> Hariprasad Kelam (4):
>   octeontx2-af: Quiesce traffic before NIX block reset
>   octeontx2-af: Fix kernel crash in CGX block init
>   octeontx2-af: RPM: fix fifo_len corruption
>   octeontx2-af: RPM: Read proper counters for RS-FEC
> 
> Kiran Kumar K (1):
>   octeontx2-af: Adding changes to parse stacked VLANs
> 
> Linu Cherian (5):
>   octeontx2-af: Add cn20k NPA context support
>   octeontx2-af: Extend debugfs support for cn20k NPA
>   octeontx2-pf: Add cn20k aura/pool context support
>   octeontx2-af: Skip NDC operations for cn20k
>   octeontx2-af: Minor updates to cn20k npa struct
> 
> Prince John (2):
>   dt-bindings: thermal: Added marvell armada-ap807-thermal
>   drivers: thermal: fix sequence and add ap807
> 
> Prince Takkar (1):
>   octeontx2-af: add skeleton code for ML EB driver
> 
> Sai Krishna (5):
>   octeontx2-af: Basic mbox operations to support CN20k, OcteonTX2
>   octeontx2-af: CN20k mbox to support AF REQ/ACK functionality
>   octeontx2-pf: CN20K mbox REQ/ACK implementation for NIC PF
>   octeontx2-vf: CN20K mbox REQ/ACK implementation for AF's VF
>   octeontx2-pf: CN20K mbox REQ/ACK implementation between PF-VF
> 
> Sebastien Dubois (1):
>   mrvl_swup: support compatibility with previous structures
> 
> Subbaraya Sundeep (10):
>   octeontx2: Do not scatter pcifunc macros across modules
>   octeontx2: Set correct PF, VF masks and shifts based on silicon
>   octeontx2-af: Simplify context writing and reading to hardware
>   octeontx2-af: Add cn20k NIX contexts support
>   octeontx2-af: Extend debugfs support for cn20k NIX
>   octeontx2-pf: Use new nix SQ context for cn20k
>   octeontx2-af: Accommodate more bandwidth profiles for cn20k
>   octeontx2-af: Display new bandwidth profiles too in debugfs
>   octeontx2-pf: Use new bandwidth profiles in receive queue
>   octeontx2-af: Display missing info in cn20k CQ context
> 
>  .../devicetree/bindings/thermal/armada-thermal.txt |   1 +
>  arch/arm64/boot/dts/marvell/armada-ap807.dtsi  |   3 +
>  drivers/net/ethernet/marvell/octeontx2/af/Makefile |   6 +-
>  drivers/net/ethernet/marvell/octeontx2/af/cgx.c|  23 +-
>  drivers/net/ethernet/marvell/octeontx2/af/cgx.h|   1 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/api.h  |  35 ++
>  .../ethernet/marvell/octeontx2/af/cn20k/debugfs.c  | 216 ++
>  .../ethernet/marvell/octeontx2/af/cn20k/debugfs.h  |  28 ++
>  .../marvell/octeontx2/af/cn20k/mbox_init.c | 391 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/nix.c  |  20 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/npa.c  |  21 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/reg.h  |  76 
>  .../net/ethernet/marvell/octeontx2/af/cn20k/rvum.c |  93 
>  .../net/ethernet/marvell/octeontx2/af/cn20k/rvum.h |  20 +
>  .../ethernet/marvell/octeontx2/af/cn20k/rvum_reg.h |  17 +
>  .../ethernet/marvell/octeontx2/af/cn20k/struct.h   | 357 
>  .../ethernet/marvell/octeontx2/af/lmac_common.h|   7 +-
>  drivers/net/ethernet/marvell/octeontx2/af/mbox.c   | 115 +
>  drivers/net/ethernet/marvell/octeontx2/af/mbox.h   |  84 
>  .../ethernet/marvell/octeontx2/af/npc_profile.h|  36 +-
>  drivers/net/ethernet/marvell/octeontx2/af/rpm.c|  58 ++-
>  drivers/net/ethernet/marvell/octeontx2/af/rpm.h|   5 +
>  drivers/net/ethernet/marvell/octeontx2/af/rvu.c| 241 ---
>  drivers/net/ethernet/marvell/octeontx2/af/rvu.h|  43 +-
>  .../net/ethernet/marvell/octeont

Re: [linux-yocto][linux-yocto v6.1] kernel code for marvell octeon

[Bruce Ashfield]

In message: [linux-yocto][linux-yocto v6.1] kernel code for marvell octeon
on 02/09/2024 Bo Sun wrote:

> Hi Bruce,
> 
> Could you please assist with merging code into our linux-yocto repository?
> The details are as follows:
> 
> Repository:
> linux-yocto
> Branch:
> v6.1/standard/cn-sdkv6.1/octeon

merged.

Bruce

> 
> Thank you for your help.
> 
> Best regards,
> Bo
> 
> 
> The following changes since commit b157ed59d7393e9d15654d652bc61e8e9eb5e0ec:
> 
>   Merge branch 'v6.1/standard/cn-sdkv6.1/octeon-merge' into 
> v6.1/standard/cn-sdkv6.1/octeon (2024-08-26 22:22:20 -0400)
> 
> are available in the Git repository at:
> 
>   https://git.sr.ht/~bsun/linux-yocto v6.1/standard/cn-sdkv6.1/octeon
> 
> for you to fetch changes up to dfee438fe56294014441416c46d79b8704251995:
> 
>   octeontx2-af: RPM: Read proper counters for RS-FEC (2024-09-02 12:33:21 
> +0800)
> 
> 
> Amit Singh Tomar (3):
>   fs/resctrl: check for monitoring capability
>   arm_mpam: Fix lock related warnings
>   arm_mpam: extend SRCU critical section to debugfs
> 
> Geetha sowjanya (4):
>   Marvell: cn20k: Add cn20k silicon check
>   octeontx2-af: Fix APR entry in debugfs
>   octeontx2-af: cn20k: Add block discovery register
>   octeontx2-pf: Fix representor interface name
> 
> Hariprasad Kelam (4):
>   octeontx2-af: Quiesce traffic before NIX block reset
>   octeontx2-af: Fix kernel crash in CGX block init
>   octeontx2-af: RPM: fix fifo_len corruption
>   octeontx2-af: RPM: Read proper counters for RS-FEC
> 
> Kiran Kumar K (1):
>   octeontx2-af: Adding changes to parse stacked VLANs
> 
> Linu Cherian (5):
>   octeontx2-af: Add cn20k NPA context support
>   octeontx2-af: Extend debugfs support for cn20k NPA
>   octeontx2-pf: Add cn20k aura/pool context support
>   octeontx2-af: Skip NDC operations for cn20k
>   octeontx2-af: Minor updates to cn20k npa struct
> 
> Prince John (2):
>   dt-bindings: thermal: Added marvell armada-ap807-thermal
>   drivers: thermal: fix sequence and add ap807
> 
> Prince Takkar (1):
>   octeontx2-af: add skeleton code for ML EB driver
> 
> Sai Krishna (5):
>   octeontx2-af: Basic mbox operations to support CN20k, OcteonTX2
>   octeontx2-af: CN20k mbox to support AF REQ/ACK functionality
>   octeontx2-pf: CN20K mbox REQ/ACK implementation for NIC PF
>   octeontx2-vf: CN20K mbox REQ/ACK implementation for AF's VF
>   octeontx2-pf: CN20K mbox REQ/ACK implementation between PF-VF
> 
> Sebastien Dubois (1):
>   mrvl_swup: support compatibility with previous structures
> 
> Subbaraya Sundeep (10):
>   octeontx2: Do not scatter pcifunc macros across modules
>   octeontx2: Set correct PF, VF masks and shifts based on silicon
>   octeontx2-af: Simplify context writing and reading to hardware
>   octeontx2-af: Add cn20k NIX contexts support
>   octeontx2-af: Extend debugfs support for cn20k NIX
>   octeontx2-pf: Use new nix SQ context for cn20k
>   octeontx2-af: Accommodate more bandwidth profiles for cn20k
>   octeontx2-af: Display new bandwidth profiles too in debugfs
>   octeontx2-pf: Use new bandwidth profiles in receive queue
>   octeontx2-af: Display missing info in cn20k CQ context
> 
>  .../devicetree/bindings/thermal/armada-thermal.txt |   1 +
>  arch/arm64/boot/dts/marvell/armada-ap807.dtsi  |   3 +
>  drivers/net/ethernet/marvell/octeontx2/af/Makefile |   6 +-
>  drivers/net/ethernet/marvell/octeontx2/af/cgx.c|  23 +-
>  drivers/net/ethernet/marvell/octeontx2/af/cgx.h|   1 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/api.h  |  35 ++
>  .../ethernet/marvell/octeontx2/af/cn20k/debugfs.c  | 216 ++
>  .../ethernet/marvell/octeontx2/af/cn20k/debugfs.h  |  28 ++
>  .../marvell/octeontx2/af/cn20k/mbox_init.c | 391 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/nix.c  |  20 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/npa.c  |  21 +
>  .../net/ethernet/marvell/octeontx2/af/cn20k/reg.h  |  76 
>  .../net/ethernet/marvell/octeontx2/af/cn20k/rvum.c |  93 
>  .../net/ethernet/marvell/octeontx2/af/cn20k/rvum.h |  20 +
>  .../ethernet/marvell/octeontx2/af/cn20k/rvum_reg.h |  17 +
>  .../ethernet/marvell/octeontx2/af/cn20k/struct.h   | 357 
>  .../ethernet/marvell/octeontx2/af/lmac_common.h|   7 +-
>  drivers/net/ethernet/marvell/octeontx2/af/mbox.c   | 115 +
>  drivers/net/ethernet/marvell/octeontx2/af/mbox.h   |  84 
>  .../ethernet/marvell/octeontx2/af/npc_profile.h|  36 +-
>  drivers/net/ethernet/marvell/octeontx2/af/rpm.c|  58 ++-
>  drivers/net/ethernet/marvell/octeontx2/af/rpm.h|   5 +
>  drivers/net/ethernet/marvell/octeontx2/af/rvu.c| 241 ---
>  drivers/net/ethernet/marvell/octeontx2/af/rvu.h|  43 +-
>  .../net/ethernet/marvell/octeontx2/af/rvu_cgx.c|  45 +-
>  .../net/ethernet/marv

Re: [yocto] Machine qemuarm linux-yocto-tiny_5.15 Missing ext4 in Kernel

[Bruce Ashfield]

The -tiny kernel configuration is just that ... tiny. Most everything
is off by default.

Unless there's a distro feature to coordinate features, it won't be
turned on unless you bbappend a fragment to enable what you need.

Bruce


On Fri, Feb 23, 2024 at 7:49 PM  wrote:
>
> Getting past that it seems like a other options are missing. I'm going to do 
> some more testing and see what I come up with
> 
>


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

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

Re: [yocto] 'yocto-kernel-tools' requires git version much greater than general Yocto requirement

[Bruce Ashfield]

On Fri, Feb 23, 2024, 5:26 PM Konstantin Aladyshev 
wrote:

> Thanks Richard! That did the trick!
>
> I've made the following changes to the "kern-tools-native_git.bb":
> ```
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index 941160ea9c..7f8ea3e050 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "\
> file://Kconfiglib/LICENSE.txt;md5=712177a72a3937909543eda3ad1bfb7c
> \
>  "
>
> -DEPENDS = "git-native"
> +DEPENDS = "git-replacement-native"
>
>  SRCREV = "7160ebe8b865dd6028aef278efa219433db93f7e"
>  PV = "0.3+git"
> ```
> Is it ok? Can I send this patch to the mailing list?
>

It is easier if I just make the change locally and send it to the list as
part of my next pull request.

Thanks for the report and testing, I'll send a patch shortly.

Bruce



>
> Best regards,
> Konstantin Aladyshev
>
> On Sat, Feb 24, 2024 at 12:07 AM Richard Purdie
>  wrote:
> >
> > On Fri, 2024-02-23 at 13:45 -0500, Bruce Ashfield wrote:
> > > On Fri, Feb 23, 2024 at 12:15 PM Konstantin Aladyshev
> > >  wrote:
> > > >
> > > > Should I see the new git version in the linux-yocto devshell?
> > > > """
> > > > bitbake linux-yocto -c devshell
> > > > """
> > > >
> > > > I've tried to check it in the current poky master, and it gives me:
> > > > """
> > > > $/data/poky/build/workspace/sources/linux-yocto# git --version
> > > > git version 2.30.2
> > > > $/data/poky/build/workspace/sources/linux-yocto# which git
> > > > /data/poky/scripts/git
> > > > """
> > > > So in this case host git is used. "bitbake kern-tools-native -c
> > > > devshell" gives the same result.
> > > > Can this be considered as a proof that git-native is not used?
> > > >
> > >
> > > It is likely ASSUME_PROVIDED that is causing the issue, git-native is
> > > in there, which means it is going to use the host version and not
> > > build our -native recipe for it.
> > >
> > > We'll need some guidance from Richard on this, because the use of
> > > that
> > > flag in the git operations is in fact required for security reasons,
> > > so it isn't going to be optional. If that means we need a minimum git
> > > version or to use our own built one (and possibly the buildtools
> > > tarball, etc), then those are the hoops we'll have to jump through.
> > >
> > > When I pulled git-native out of ASSUME_PROVIDED locally, I ended up
> > > in
> > > a dependency loop.
> > >
> > > I can have a closer look at this again on Monday, but i'm out of time
> > > for it today.
> >
> > We do have a way to handle this.
> >
> > DEPENDS += "git-replacement-native"
> >
> > should do it.
> >
> > Cheers,
> >
> > Richard
>

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

Re: [yocto] 'yocto-kernel-tools' requires git version much greater than general Yocto requirement

[Bruce Ashfield]

On Fri, Feb 23, 2024 at 12:15 PM Konstantin Aladyshev
 wrote:
>
> Should I see the new git version in the linux-yocto devshell?
> """
> bitbake linux-yocto -c devshell
> """
>
> I've tried to check it in the current poky master, and it gives me:
> """
> $/data/poky/build/workspace/sources/linux-yocto# git --version
> git version 2.30.2
> $/data/poky/build/workspace/sources/linux-yocto# which git
> /data/poky/scripts/git
> """
> So in this case host git is used. "bitbake kern-tools-native -c
> devshell" gives the same result.
> Can this be considered as a proof that git-native is not used?
>

It is likely ASSUME_PROVIDED that is causing the issue, git-native is
in there, which means it is going to use the host version and not
build our -native recipe for it.

We'll need some guidance from Richard on this, because the use of that
flag in the git operations is in fact required for security reasons,
so it isn't going to be optional. If that means we need a minimum git
version or to use our own built one (and possibly the buildtools
tarball, etc), then those are the hoops we'll have to jump through.

When I pulled git-native out of ASSUME_PROVIDED locally, I ended up in
a dependency loop.

I can have a closer look at this again on Monday, but i'm out of time
for it today.

Bruce


Bruce

> Konstantin
>
> On Fri, Feb 23, 2024 at 4:11 PM Bruce Ashfield  
> wrote:
> >
> > On Fri, Feb 23, 2024 at 6:43 AM Alexander Kanavin
> >  wrote:
> > >
> > > On Fri, 23 Feb 2024 at 12:32, Konstantin Aladyshev
> > >  wrote:
> > > > Thanks for the response! What would be a proper way to fix this problem 
> > > > then?
> > >
> > > 1. show how to reproduce the issue in plain poky master.
> > > 2. check why none of the tests expose the issue. You can for example
> > > grep related keywords in meta/lib/oeqa/selftest/cases. I think there
> > > are tests that check devtool kernel operations there.
> > > 3. see if existing tests can be easily extended to cover it, so that
> > > they fail without a fix.
> > > 4. perhaps the fix would be to check git version first, and add the
> > > argument only if the version is recent enough.
> >
> > Which unfortunately would still leave the problem that the change is
> > intended to fix, so I wouldn't want to merge any patches to make it
> > conditional in the kern-tools.
> >
> > Those changes were made to prevent git operations from running
> > hooks from the host environment, for both security and consistency
> > reasons.
> >
> > We added git-native to the kern-tools-native recipe to get a consistently
> > new version available for any operations involving the tools.
> >
> > So I'd add another question .. why is this operation not using our
> > natively built git ? Is there something going on with the path, environment
> > or something else that we missed when adding that native dependency.
> >
> > Bruce
> >
> > >
> > > Alex
> > >
> > > 
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II



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

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

Re: [yocto] 'kgit-s2q' doesn't remove 'rebase-apply' directory

[Bruce Ashfield]

On Fri, Feb 23, 2024 at 5:35 AM Konstantin Aladyshev
 wrote:
>
> Hello!
>
> 'kgit-s2q' in the linux recipe tries to use 'git apply' if 'git am' fails.
> In this case 'kgit-s2q' manually creates a ".git/rebase-apply"
> directory 
> (https://git.yoctoproject.org/yocto-kernel-tools/tree/tools/kgit-s2q#n622)
> But it looks like this directory is not removed after the patches are
> applied. This creates a problem, since with this directory present git
> thinks that rebase operation is still in progress.
> Because of this bug 'devtool modify linux' can't perform its own
> rebase operations in the "devtool_post_patch" tasks
> https://git.yoctoproject.org/poky/tree/meta/classes/devtool-source.bbclass#n214
> In the end this creates a situation when the local patches are not applied.

Leaving that directory is intentional, as it is used during some resuming
and skipping of patching  errors. These tools predate devtool and other
similar things by quite a few years, so there's not much coordination between
the two. It might be something that could be cleaned up, but devtool could
just as easily ensure that it has a clean environment before starting and
removing any failed/lingering operations .. I run into this all the time when
manually working with my kernel trees, I just clean it up and move on.

Also, see the README in the kern-tools repository, you are using the
wrong mailing
list for these questions. They should go to linux-yocto.

Cheers,

Bruce

>
> Best regards,
> Konstantin Aladyshev
>
> 
>


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

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

Re: [yocto] 'yocto-kernel-tools' requires git version much greater than general Yocto requirement

[Bruce Ashfield]

On Fri, Feb 23, 2024 at 6:43 AM Alexander Kanavin
 wrote:
>
> On Fri, 23 Feb 2024 at 12:32, Konstantin Aladyshev
>  wrote:
> > Thanks for the response! What would be a proper way to fix this problem 
> > then?
>
> 1. show how to reproduce the issue in plain poky master.
> 2. check why none of the tests expose the issue. You can for example
> grep related keywords in meta/lib/oeqa/selftest/cases. I think there
> are tests that check devtool kernel operations there.
> 3. see if existing tests can be easily extended to cover it, so that
> they fail without a fix.
> 4. perhaps the fix would be to check git version first, and add the
> argument only if the version is recent enough.

Which unfortunately would still leave the problem that the change is
intended to fix, so I wouldn't want to merge any patches to make it
conditional in the kern-tools.

Those changes were made to prevent git operations from running
hooks from the host environment, for both security and consistency
reasons.

We added git-native to the kern-tools-native recipe to get a consistently
new version available for any operations involving the tools.

So I'd add another question .. why is this operation not using our
natively built git ? Is there something going on with the path, environment
or something else that we missed when adding that native dependency.

Bruce

>
> Alex
>
> 
>


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

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

Re: [yocto] [meta-security][PATCH 1/1] sanity-meta-security.bbclass: allow warning customization

[Bruce Ashfield]

On Thu, Feb 15, 2024 at 2:06 PM Slater, Joseph  wrote:
>
>
>
> > -Original Message-
> > From: Bruce Ashfield 
> > Sent: Thursday, February 15, 2024 9:57 AM
> > To: yocto@lists.yoctoproject.org; Slater, Joseph 
> > Cc: MacLeod, Randy 
> > Subject: Re: [yocto] [meta-security][PATCH 1/1] 
> > sanity-meta-security.bbclass:
> > allow warning customization
> >
> > On Thu, Feb 15, 2024 at 12:15 PM Joe Slater via lists.yoctoproject.org
> >  wrote:
> > >
> > > From: Joe Slater 
> > >
> > > Introduce META_SECURITY_SANITY_CHECK_WARNING variable which can be
> > > overridden, if desired.
> >
> > The existence of the patch implies that there's a reason why the warning
> > message isn't appropriate for your use case.
> >
> > That's something that should be explained in the patch.
> >
> > A knob to disable the warning if you know what you are doing has already 
> > been
> > provided. So again, this patch implies that you want the warning, but want 
> > to
> > change the message .. it would be good to understand why.
> >
> > Bruce
>
> Some people want to know how to disable the warning without reading the 
> README.  I don't think that's a great idea, but allowing customization would 
> let that be done on a distro or similar basis.  I didn't want to mention that 
> stuff in a commit message, but maybe it should be there.

Things like that should always be mentioned in a commit message.

Technical parts of the changes can be understood by looking at the
commit, the why is the important part.

I wouldn't allow this to be tweaked in my layers, since it opens the
door for incorrect information to be injected into the layer's
warning, but that decision is up to the layer maintainer :)

Bruce

>
> Joe
>
> >
> > >
> > > Signed-off-by: Joe Slater 
> > > ---
> > >  classes/sanity-meta-security.bbclass | 13 +
> > >  1 file changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/classes/sanity-meta-security.bbclass
> > > b/classes/sanity-meta-security.bbclass
> > > index f9e2698..95180aa 100644
> > > --- a/classes/sanity-meta-security.bbclass
> > > +++ b/classes/sanity-meta-security.bbclass
> > > @@ -1,10 +1,15 @@
> > >  addhandler security_bbappend_distrocheck
> > > security_bbappend_distrocheck[eventmask] = "bb.event.SanityCheck"
> > > +
> > >  python security_bbappend_distrocheck() {
> > >  skip_check = e.data.getVar('SKIP_META_SECURITY_SANITY_CHECK') == "1"
> > >  if 'security' not in e.data.getVar('DISTRO_FEATURES').split() and not
> > skip_check:
> > > -bb.warn("You have included the meta-security layer, but \
> > > -'security' has not been enabled in your DISTRO_FEATURES. Some
> > > bbappend files \ -and preferred version setting may not take effect.
> > > See the meta-security README \ -for details on enabling security
> > > support.")
> > > +bb.warn(e.data.getVar('META_SECURITY_SANITY_CHECK_WARNING'))
> > >  }
> > > +
> > > +META_SECURITY_SANITY_CHECK_WARNING ??= "\ You have included the
> > > +meta-security layer, but 'security' has not been \ enabled in your
> > > +DISTRO_FEATURES. Some bbappend files and preferred version \ settings
> > > +may not take effect. See the meta-security README for details on \
> > > +enabling security support."
> > > +
> > > --
> > > 2.25.1
> > >
> > >
> > > 
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await thee 
> > at its
> > end
> > - "Use the force Harry" - Gandalf, Star Trek II



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

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

Re: [yocto] [meta-security][PATCH 1/1] sanity-meta-security.bbclass: allow warning customization

[Bruce Ashfield]

On Thu, Feb 15, 2024 at 12:15 PM Joe Slater via lists.yoctoproject.org
 wrote:
>
> From: Joe Slater 
>
> Introduce META_SECURITY_SANITY_CHECK_WARNING variable which
> can be overridden, if desired.

The existence of the patch implies that there's a reason why the warning message
isn't appropriate for your use case.

That's something that should be explained in the patch.

A knob to disable the warning if you know what you are doing has already been
provided. So again, this patch implies that you want the warning, but want to
change the message .. it would be good to understand why.

Bruce

>
> Signed-off-by: Joe Slater 
> ---
>  classes/sanity-meta-security.bbclass | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/classes/sanity-meta-security.bbclass 
> b/classes/sanity-meta-security.bbclass
> index f9e2698..95180aa 100644
> --- a/classes/sanity-meta-security.bbclass
> +++ b/classes/sanity-meta-security.bbclass
> @@ -1,10 +1,15 @@
>  addhandler security_bbappend_distrocheck
>  security_bbappend_distrocheck[eventmask] = "bb.event.SanityCheck"
> +
>  python security_bbappend_distrocheck() {
>  skip_check = e.data.getVar('SKIP_META_SECURITY_SANITY_CHECK') == "1"
>  if 'security' not in e.data.getVar('DISTRO_FEATURES').split() and not 
> skip_check:
> -bb.warn("You have included the meta-security layer, but \
> -'security' has not been enabled in your DISTRO_FEATURES. Some bbappend files 
> \
> -and preferred version setting may not take effect. See the meta-security 
> README \
> -for details on enabling security support.")
> +bb.warn(e.data.getVar('META_SECURITY_SANITY_CHECK_WARNING'))
>  }
> +
> +META_SECURITY_SANITY_CHECK_WARNING ??= "\
> +You have included the meta-security layer, but 'security' has not been \
> +enabled in your DISTRO_FEATURES. Some bbappend files and preferred version \
> +settings may not take effect. See the meta-security README for details on \
> +enabling security support."
> +
> --
> 2.25.1
>
>
> 
>


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

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

Re: [yocto] kernel headers in my image

[Bruce Ashfield]

On Wed, Jan 24, 2024 at 12:05 PM Daniele Lugli  wrote:
>
> Hi all,
>
> I would like to have kernel headers in my image, in order to locally build a 
> module.
>
> I added
>
> IMAGE_INSTALL:append = " kernel-dev"
> IMAGE_INSTALL:append = " kernel-devsrc"
> IMAGE_INSTALL:append = " kernel-modules"
>
> in my image recipe and, as a result, I see that /usr/src/kernel and 
> /lib/modules/${uname -r}/build are now populated.
>
> But when I try to build my module (which builds correctly on a non-poky 
> machine) I get:
>
> ./include/linux/compiler.h:247:10: fatal error: asm/rwonce.h No such file or 
> directory
>
> And, in fact, there is no rwonce.h under /usr/src/kernel. There is one under 
> /lib/modules... but it is in asm-generic/rwonce.h
>

Have you run "make scripts prepare" in /usr/src/kernel ?

Bruce

> Any idea?
>
> Thank you in advance
> --
> Daniele Lugli
> General Logic srl
> Viale Curreno, 41
> 10133 Torino
> Italy
> tel +39 329 3933041
> www.general-logic.com
> www.linkedin.com/in/daniele-lugli
>
> 
>


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

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

[yocto] [PATCH] poky/poky-tiny: make 6.6 the default kernel

[Bruce Ashfield]

From: Bruce Ashfield 

Bumping the reference distros to the latest -stable/lts
kernel.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 meta-poky/conf/distro/poky.conf  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf 
b/meta-poky/conf/distro/poky-tiny.conf
index 24bcbee9bb..f3dfa8107a 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -44,7 +44,7 @@ FULL_OPTIMIZATION="-Os -pipe ${DEBUG_FLAGS}"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "6.5%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "6.6%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index f4d55a41c1..3b7bc66780 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -19,8 +19,8 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "6.5%"
-PREFERRED_VERSION_linux-yocto-rt ?= "6.5%"
+PREFERRED_VERSION_linux-yocto ?= "6.6%"
+PREFERRED_VERSION_linux-yocto-rt ?= "6.6%"
 
 SDK_NAME = 
"${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.39.2


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

Re: [yocto] [meta-rockchip][PATCH] KERNEL_DEVICETREE: 32-bit re-org

[Bruce Ashfield]

On Wed, Oct 4, 2023 at 9:59 AM Quentin Schulz via lists.yoctoproject.org
 wrote:

> Hi Trevor,
>
> On 10/3/23 15:38, Trevor Woerner wrote:
> > On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote:
> >> Hi Trevor,
> >>
> >> On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote:
> >>> The upstream kernel reorganized the 32-bit arch/arm device-tree
> directory structure
> >>> to separate out the device-trees by manufacturer (similar to the
> organization
> >>> of the arch/arm64 device-trees). Update the references to 32-bit arm
> >>> device-trees to match.
> >>>
> >>
> >> Does this work with linux-yocto and linux-yocto-dev from master or do we
> >> need to add some logic to support both (do you want to?).
> >
> > This doesn't work at all. I figured this was an easy one, made the tweak,
> > submitted it, then added it to my jenkins builder to verify overnight.
> Woke up
> > to find the do_image_wic() tasks failed. It's the same layout as the
> 64-bit
> > machines but I'll have to dig in to figure out why it didn't work.
> >
> > As for the linux-yocto vs linux-yocto-dev question I'll take a look. This
> > happened with linux-yocto, so I would assume it is already the case with
> > linux-yocto-dev. But if oe-core supports multiple versions of
> linux-yocto,
> > that might be the tricky bit and yes, I would look into supporting both
> for
> > the time-being until the transition period ends.
> >
>
> This was done in v6.5-rc1 so anything before won't work sadly.
>
> master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto
> (linux-yocto-dev being typically newer than the latest linux-yocto and
> the latest linux-yocto already having the change, I'll omit the change
> for linux-yocto-dev).
>
> For reference, denix on IRC suggested you look at
>
> https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300
> for what we're trying to do here. But I think this isn't applying to how
> the DTB is found but rather where it's put and this is too late for us.
>
> I think we need to modify get_real_dtb_path_in_kernel in
> meta/classes-recipe/kernel-devicetree.bbclass instead.
>
> We could handle it this way for example to allow a fallback:
> """
> get_real_dtb_path_in_kernel:arm () {
> dtb="$1"
> dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb"
>  # Handle pre-v6.5 layout for Aarch32/ARM DTB
> if [ ! -e "$dtb_path" ]; then
> dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")"
> fi
> if [ ! -e "$dtb_path" ]; then
> dtb_path="${B}/arch/${ARCH}/boot/$dtb"
> fi
>  # Handle pre-v6.5 layout for Aarch32/ARM DTB
> if [ ! -e "$dtb_path" ]; then
> dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")"
> fi
>
> echo "$dtb_path"
> }
> """
> (to be determined if "arm" is a valid OVERRIDES, otherwise we need to
> check against "ARCH" bb variable; also not sure about the second
> basename if it's necessary at all).
>
> Then you would just have KERNEL_DEVICETREE done the same way as in this
> patch:
> KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb"
>
> and we wouldn't have to handle it on the recipe level.
>
> Otherwise, we could do the following:
> RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb"
> KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}"
>
> then have a bbappend for all old-layout recipes:
> linux-yocto-rt_6.1.bbappend
> linux-yocto-tiny_6.1.bbappend
> linux-yocto_6.1.bbappend
> linux-yocto-rt_6.4.bbappend
> linux-yocto-tiny_6.4.bbappend
> linux-yocto_6.4.bbappend
>
> KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in
> d.getVar('RK_KERNEL_DEVICETREE').split())}"
>
> or something like that. We probably want to have something a bit more
> precise than just arm to avoid breaking other arm machine conf files
> which do not define RK_KERNEL_DEVICETREE, maybe
> KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly.
>
> > Although... any BSP layer supporting 32-bit machines will have similar
> issues,
> > so perhaps there's a better way to solve this in oe-core?
> >
> Adding Bruce in Cc, I hope he doesn't mind being summoned like this.
> Maybe you have an idea on how to handle both the new and old layout for
> ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable?
>

My last run in with this may have been before some of the most recent
device tree handling patches, and/or I may have been doing it wrong.

But my solution was to simply override the variable in a kernel version
specific bbappend, and not do it in the conf files.

But of course, if that variable is being interpreted by a different class in
the global namespace, then the kernel bbappend approach isn't going
to work anymore.

I've stayed away from utilities or searching, etc, rather just a way for the
configuration to specify directly what to find, as anything that searches
ends up being fragile.

Bruce


>
> Cheers,
> Quentin
>
> 
>
>

Re: [yocto] [meta-virtualization] nerdctl broken in kirkstone

[Bruce Ashfield]

On Mon, Sep 11, 2023 at 3:50 PM Marek Belisko  wrote:
>
> On Mon, Sep 11, 2023 at 9:27 PM Marek Belisko via lists.yoctoproject.org 
>  wrote:
>>
>> On Mon, Aug 28, 2023 at 10:38 PM Belisko Marek  
>> wrote:
>>>
>>> On Thu, Aug 24, 2023 at 4:05 PM Khem Raj  wrote:

 does it work if you add do_compile[network] = "1"
>>>
>>> Nope it is not. It turns out that the fetch phase is not correct. When I do 
>>> bitbake nerdctl -e | grep SRC_URI I got only:
>>>
>>>  
>>> SRC_URI="git://github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"
>>>
>>> and not other SRC_URI's added in src_uri.inc file. It's mystery to me why 
>>> this include is not working
>>
>> Khem any idea what can be the cause of this issue please? I've tried yq 
>> recipe which using more less the same approach and there SRC_URI's are 
>> printed properly.
>
> OK please disregard this message. I find out I have a nerdctl bbappend which 
> overwrites SRC_URI permanently. BTW on kirkstone nerdctl is broken due wrong 
> branch name + wrong SRCREV. Should I post a patch?

You do realize that you are using the wrong mailing list for this thread ?

We have newer/working updated nerdctl recipes in newer branches of meta-virt.

The upstream repos have just (unfortunately) changed some of their
revs, so the ones captured and tested on release have gone out of
date.

Bruce




 On Wed, Aug 23, 2023 at 11:14 PM Belisko Marek  
 wrote:
 >
 >
 >
 > Sent from my iPhone
 >
 > > On 24 Aug 2023, at 02:23, Khem Raj  wrote:
 > >
 > > which task is failing ?
 > do_compile
 > >
 > >> On Wed, Aug 23, 2023 at 2:31 PM Marek Belisko 
 > >>  wrote:
 > >>
 > >> Hi,
 > >>
 > >> I'm trying to add nerdctl to an image using kirkstone release for 
 > >> meta-virtualization.
 > >> I've added bbappend with following fix:
 > >>
 > >> SRC_URI = 
 > >> "git://github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"
 > >>
 > >> (branch name in original recipe is master but main is required)
 > >>
 > >> but then anyways it fails with:
 > >>
 > >> rsync: [sender] change_dir 
 > >> "/data/projects/test/build/tmp/work/cortexa53-crypto-poky-linux/nerdctl/v0.18.0-r0/nerdctl-v0.18.0/src/import/vendor.fetch/github.com/Masterminds/semver/v3"
 > >>  failed: No such file or directory (2)
 > >> | rsync error: some files/attrs were not transferred (see previous 
 > >> errors) (code 23) at main.c(1327) [sender=3.2.5]
 > >>
 > >> And in ${BP} I cannot see any of those vendor stuff which should be 
 > >> present. Is there some fix for that already pending or it's known 
 > >> issue?
 > >>
 > >> Thanks and BR,
 > >>
 > >> marek
 > >>
 > >> --
 > >> as simple and primitive as possible
 > >> -
 > >> Marek Belisko - OPEN-NANDRA
 > >> Freelance Developer
 > >>
 > >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
 > >> Tel: +421 915 052 184
 > >> skype: marekwhite
 > >> twitter: #opennandra
 > >> web: http://open-nandra.com
 > >>
 > >>
 > >>
>>>
>>>
>>>
>> Thanks,
>>
>> marek
>> --
>> as simple and primitive as possible
>> -
>> Marek Belisko - OPEN-NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> twitter: #opennandra
>> web: http://open-nandra.com
>>
>>
>>
>
> Thanks,
>
> marek
>
>
> 
>


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

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

Re: [yocto] Rootless Podman

[Bruce Ashfield]

On Tue, Aug 8, 2023 at 3:25 PM Bruce Ashfield  wrote:
>
> Assuming we are talking about a meta-virtualization built podman, and
> a yocto image,
> this would be more appropriate on the meta-virtualization mailing list
>
> That being said, I do test rootless podman each release, and during
> updates to the
> package (I have a medium term TODO to automate that), and I was able to just
> run a simple rootless podman test on master.
>
> But rootless anything isn't a simple question. What release are we
> talking about ?
> What kernel ? What architecture, and what is the container image and commands
> that are being run ?

HAH! Not enough coffee today.

Never mind, I completely read over the word BUILDING!!!

At least this motivated me to test our on-target rootless podman again.

Bruce

>
> Bruce
>
> On Tue, Aug 8, 2023 at 2:43 PM Stephen John Smoogen  wrote:
> >
> >
> > Does anyone know what ways it is failing (or how I can duplicate it ) and I 
> > can forward to the podman group (can't promise I can get it fixed.. but 
> > will do what I can). Also if people have already opened issues on the 
> > failures, let me know.
> >
> > On Tue, 8 Aug 2023 at 14:34, Khem Raj  wrote:
> >>
> >>
> >> We have tried it hard in yoe distro but it always fails in novel ways so 
> >> much. I have switched back to docker for now
> >>
> >> On Tue, Aug 8, 2023 at 11:07 AM Joel Winarske  
> >> wrote:
> >>>
> >>> Anyone successfully building using Rootless Podman?
> >>>
> >>> I'm seeing a variety of strange issues.
> >>>
> >>> My baseline podman config:
> >>> --user 1001:1001
> >>> --ipc host
> >>> --privileged
> >>> --security-opt label=disable
> >>> --pid host
> >>> --userns keep-id
> >>> --ulimit host
> >>> --mount type=devpts,destination=/dev/pts
> >>> --security-opt label=disable
> >>> --group-add keep-groups
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > --
> > Stephen J Smoogen.
> > Let us be kind to one another, for most of us are fighting a hard battle. 
> > -- Ian MacClaren
> >
> > 
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



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

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

Re: [yocto] Rootless Podman

[Bruce Ashfield]

Assuming we are talking about a meta-virtualization built podman, and
a yocto image,
this would be more appropriate on the meta-virtualization mailing list

That being said, I do test rootless podman each release, and during
updates to the
package (I have a medium term TODO to automate that), and I was able to just
run a simple rootless podman test on master.

But rootless anything isn't a simple question. What release are we
talking about ?
What kernel ? What architecture, and what is the container image and commands
that are being run ?

Bruce

On Tue, Aug 8, 2023 at 2:43 PM Stephen John Smoogen  wrote:
>
>
> Does anyone know what ways it is failing (or how I can duplicate it ) and I 
> can forward to the podman group (can't promise I can get it fixed.. but will 
> do what I can). Also if people have already opened issues on the failures, 
> let me know.
>
> On Tue, 8 Aug 2023 at 14:34, Khem Raj  wrote:
>>
>>
>> We have tried it hard in yoe distro but it always fails in novel ways so 
>> much. I have switched back to docker for now
>>
>> On Tue, Aug 8, 2023 at 11:07 AM Joel Winarske  
>> wrote:
>>>
>>> Anyone successfully building using Rootless Podman?
>>>
>>> I'm seeing a variety of strange issues.
>>>
>>> My baseline podman config:
>>> --user 1001:1001
>>> --ipc host
>>> --privileged
>>> --security-opt label=disable
>>> --pid host
>>> --userns keep-id
>>> --ulimit host
>>> --mount type=devpts,destination=/dev/pts
>>> --security-opt label=disable
>>> --group-add keep-groups
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard battle. -- 
> Ian MacClaren
>
> 
>


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

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

Re: [yocto] Building Tailscale with Yocto #golang

[Bruce Ashfield]

On Mon, Jul 3, 2023 at 10:05 AM Janne Kiiskila
 wrote:
>
> Hei,
>
>
>
> Golang does have the required features to support this, but it is more of a 
> challenge to convince the repo owners to start using this.
>
> You can download all of the dependencies in golang with go mod vendor and 
> then store the vendor-folder to the repo as well.
>
> But, the repo will get a lot larger that way. But, that fulfills the Yocto 
> demands as far as I know.
>

Yes, again, if you read the mailing list discussions on this in the
past, we are well aware of what golang does (and doesn't do) and the
options to fully integrate into the core capabilities via a dedicated
fetcher.

But no one has stepped up to implement a fully integrated solution, so
we have proposals only as this point.

I've gone a different way with meta-virtualization and am using large
SRC_URIs with the dependencies fetched to allow full integration with
the fetcher, and still build reproducible go binaries.

Bruce

>
>
> Best Regards,
>
>
>
>
>
> Janne Kiiskilä
>
>
>
>
>
> From: yocto@lists.yoctoproject.org  On Behalf 
> Of Markus Volk via lists.yoctoproject.org
> Sent: maanantai 3. heinäkuuta 2023 16.43
> To: Bruce Ashfield 
> Cc: przemek.re...@gmail.com; yocto@lists.yoctoproject.org
> Subject: Re: [yocto] Building Tailscale with Yocto #golang
>
>
>
> On Mon, Jul 3 2023 at 09:07:11 AM -0400, Bruce Ashfield 
>  wrote:
>
> We really shouldn't suggest the above to a developer without also the 
> explanation as to why network access is disabled by default in tasks such as 
> compile.
>
>
>
> You are of course right with your objections. However, this is the only way I 
> know of to get around this problem. Reproducibility is not a must have 
> requirement for me, but I use some gtk go programs and would love to have a 
> way to build at least gotk3 shared, since it takes quite a long time and has 
> to be rebuilt for each program.
>
> I had experimented with this some time ago, but it looked to me like there 
> was no easy solution to this problem. This is somehow quite a conflict 
> between different concepts.



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

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

Re: [yocto] Building Tailscale with Yocto #golang

[Bruce Ashfield]

On Sun, Jul 2, 2023 at 4:30 PM Markus Volk  wrote:
>
> You need to allow network connection for the do_compile task
>
> do_compile[network] = "1"

We really shouldn't suggest the above to a developer without also the
explanation as to why network access is disabled by default in tasks
such as compile.

Your build may in fact work once you've allowed go to fetch its
dependencies / modules, but you will also not have reproducibility, a
full license report or sstate/download reuse (things you'd get from
fetcher integration).

If none of those things are significant to you, then by all means, you
can just allow go fetching in do_compile()

For more details on the options and the long discussions on the topic
in the past, I'd suggest searching the oe-core mailing list archives.

Bruce

>
>
> On Sun, Jul 2 2023 at 12:45:40 PM -0700, przemek.re...@gmail.com wrote:
>
> Hi!
> I'm trying to build Tailscale with Yocto
> This is me recipe:
>
> inherit go-mod
>
> SRC_URI = "git://github.com/tailscale/tailscale;protocol=https;branch=main"
> SRCREV = "30d9201a11ebc2e3a0f17bf8963956b77dadeb5d"
>
> GO_IMPORT = "tailscale.com"
> GO_WORKDIR = "${GO_IMPORT}"
> GO_INSTALL = "\
> ${GO_IMPORT}/cmd/tailscale \
> ${GO_IMPORT}/cmd/tailscaled \
> "
>
> do_install() {
> install -d ${D}/${bindir}
> install -d ${D}/${sbindir}
> install ${B}/bin/tailscale ${D}/${bindir}/tailscale
> install ${B}/bin/tailscaled ${D}/${sbindir}/tailscaled
> }
>
>
> However, build step ends up with errors like these (full log):
>
> | wgengine/netstack/netstack.go:34:2: 
> gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
> "https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip":
>  dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
> connect: network is unreachable
> | wgengine/netstack/netstack.go:35:2: 
> gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
> "https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip":
>  dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
> connect: network is unreachable
> | net/tstun/tap_linux.go:23:2: 
> gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
> "https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip":
>  dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
> connect: network is unreachable
> | wgengine/netstack/netstack.go:37:2: 
> gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
> "https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip":
>  dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
> connect: network is unreachable
> | ipn/ipnauth/ipnauth.go:16:2: 
> inet.af/peercred@v0.0.0-20210906144145-0893ea02156a: Get 
> "https://proxy.golang.org/inet.af/peercred/@v/v0.0.0-20210906144145-0893ea02156a.zip":
>  dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
> connect: network is unreachable
>
> On some resources I have found it was recomended to add environmental 
> variables: `GOPROXY="direct"` and `GOSUMDB="off"`, but it didn't helped.
>
> Maybe someone has some ideas what is the cause of these errors?
>
>
> 
>


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

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

Re: [yocto] [meta-security][PATCH 0/2] Drop a kernel patch and a kernel config option

[Bruce Ashfield]

On Tue, May 9, 2023 at 2:43 PM Jose Quaresma  wrote:
>
>
>
> Stefan Berger  escreveu no dia terça, 9/05/2023 à(s) 
> 19:19:
>>
>>
>>
>> On 5/9/23 14:11, Jose Quaresma wrote:
>> > Hi Stefan, Stefan Berger  escreveu no dia terça, 
>> > 9/05/2023 à(s) 18: 55: This PR removes a kernel patch related to overlayfs 
>> > and IMA appraisal file change notifictions and a squashfs xattr kernel 
>> > config option.
>> > ZjQcmQRYFpfptBannerStart
>> > This Message Is From an External Sender
>> > This message came from outside your organization.
>> > ZjQcmQRYFpfptBannerEnd
>> > Hi Stefan,
>> >
>> > Stefan Berger mailto:stef...@linux.ibm.com>> 
>> > escreveu no dia terça, 9/05/2023 à(s) 18:55:
>> >
>> > This PR removes a kernel patch related to overlayfs and IMA appraisal 
>> > file change
>> > notifictions and a squashfs xattr kernel config option.
>> >
>> > Stefan
>> >
>> > Stefan Berger (2):
>> >linux: overlayfs: Drop kernel patch resolving a file change
>> >  notification issue
>> >ima: Drop kernel config option CONFIG_SQUASHFS_XATTR=y from ima.cfg
>> >
>> >   ...Increment-iversion-upon-file-changes.patch | 42 
>> > ---
>> >   .../recipes-kernel/linux/linux/ima.cfg|  1 -
>> >   .../recipes-kernel/linux/linux_ima.inc|  1 -
>> >
>> > CONFIG_SYSTEM_TRUSTED_KEYS=
>> > Unfortunately this is not enough because in the full patchset you are 
>> > overriding the do_configure task
>> > on meta-integrity/recipes-kernel/linux/linux_ima.inc and this file is 
>> > included in every recipe that follies the
>> > pattern starting by linux- (recipes-kernel/linux/linux-%.bbappend).
>>
>> You are referring tho this here?
>>
>> do_configure() {
>>  sed -i 
>> "s|^CONFIG_SYSTEM_TRUSTED_KEYS=.*|CONFIG_SYSTEM_TRUSTED_KEYS=\"${IMA_EVM_ROOT_CA}\"|"
>>  .config
>> }
>>
>> You are saying that this deactivates some other do_configure's ? If this is 
>> the case, what would be the right syntax to fix it?
>
>
> Yes, this is the problem. The right fix IMHO is reverting because we can't 
> assume that the .config it's always there
> on the bitbake build directory and this only happens when building the kernel.
>
> Another no less significant side effect is that this change is also applied 
> to a wide range of recipes,
> anyone starting with the name linux-*.bb.
>
> So the full patch set should be reverted in my opinion and be more tested 
> locally, building for example
> some recipe that respects the pattern linux-*.bb and also other kernels and 
> re-submitted again.

I had to deal with the need for a similarly broad bbappend, and both
distro / kernel version
conditions in meta-virtualization.

This isn't exactly what Stefan is looking for, but it is a starting point:

https://git.yoctoproject.org/meta-virtualization/tree/recipes-kernel/linux/linux-%25.bbappend

Bruce

>
> Jose
>
>>
>>
>> It's a no-op on a .config that does not contain the 
>> CONFIG_SYSTEM_TRUSTED_KEYS= option already.=
>>
>> Stefan
>>
>> >
>> > This breaks many recipes like linux-firmware and maybe others.
>> > The root cause of the issue is now on f4f7624d2e but because this patch is 
>> > too evasive, maybe everything has to be reversed.
>> > I am now building with the full patchset revert and so far the build is 
>> > looking good.
>>
>>
>> >
>> > Jose
>> >
>> >   3 files changed, 44 deletions(-)
>> >   delete mode 100644 
>> > meta-integrity/recipes-kernel/linux/linux/0001-ovl-Increment-iversion-upon-file-changes.patch
>> >
>> > --
>> > 2.34.1
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > José Quaresma
>> >
>> >
>> >
>> >
>
>
>
> --
> Best regards,
>
> José Quaresma
>
> 
>


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

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

Re: [yocto] build kernel libelf.h error

[Bruce Ashfield]

On Tue, May 2, 2023 at 3:01 AM abbas ali chezgi  wrote:
>
> hello everybody,
> i want to compile kernel with `CONFIG_DEBUG_INFO_BTF=y`
> it has errors:
> ```
> | linker.c:17:10: fatal error: libelf.h: No such file or directory
> |17 | #include 
> |   |  ^~
> | compilation terminated.
> | btf.c:18:10: fatal error: gelf.h: No such file or directory
> |18 | #include 
> |   |  ^~~~
> ```
>
> i also added to linux_%.bbappend:
> ```
> DEPENDS = "elfutils elfutils-native"
> ```
>
> how can i solve this problem?

I can at least confirm that linux-yocto builds with that option
enabled. It has similar dependencies in the recipes for elfutils.

What's your kernel provider ?

Bruce

> thanks
>
>
> 
>


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

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

Re: [yocto] #kernelmodule #kirkstone Kernel configuration fragment overriden by netfilter.cfg

[Bruce Ashfield]

On Wed, Apr 19, 2023 at 12:08 PM Gary Huband via
lists.yoctoproject.org 
wrote:
>
>
> I'm using kirkstone and meta-intel for a build.  I have a few kernel 
> configuration fragments but one of the fragment files, modbusbs.cfg, is not 
> applied.
>

It is of course being applied, but as you mentioned at the bottom, it
is being overridden by a later fragment.

netfilter fragments are likely coming from either the core or the
intel KERNEL_EXTRA_FEATURES variable, which feed into KERNEL_FEATURES.

KERNEL_FEATURES are always applied last, as they represent something
that has been flagged as important/critical.

You can either make your fragment a kernel feature itself (documented
in the development manuals), or remove the netfilter fragment from
KERNEL_EXTRA_FEATURES or KERNEL_FEATURES.

Bruce

> I created each fragment with
> bitbake -c menuconfig virtual/kernel
> bitbake -c diffconfig virtual/kernel
> Then copied fragment.cfg to my layer.
>
> The files in my layer:
>
> linux-intel_%.bbappend:
> FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
>
> SRC_URI += "\
> file://i2c-dev.cfg \
> file://modbusfw.cfg \
> file://vlan.cfg \
>"
>
> i2c-dev.cfg:
> CONFIG_I2C_CHARDEV=y
>
> modbusfw.cfg:
> CONFIG_NETFILTER_XTABLES=y
> CONFIG_IP_NF_IPTABLES=y
>
> vlan.cfg:
> CONFIG_MRP=y
> CONFIG_VLAN_8021Q=y
> CONFIG_VLAN_8021Q_MVRP=y
>
> The i2c-dev.cfg and vlan.cfg are applied, but modbusfw.cfg is not.
>
> Part of merge_config_build.log:
>
> Value of CONFIG_I2C_CHARDEV is redefined by fragment 
> .kernel-meta/configs/v5.15/standard/./i2c-dev.cfg:
> Previous value: CONFIG_I2C_CHARDEV=m
> New value: CONFIG_I2C_CHARDEV=y
>
> Merging .kernel-meta/configs/v5.15/standard/./modbusfw.cfg
> Value of CONFIG_IP_NF_IPTABLES is redefined by fragment 
> .kernel-meta/configs/v5.15/standard/./modbusfw.cfg:
> Previous value: CONFIG_IP_NF_IPTABLES=m
> New value: CONFIG_IP_NF_IPTABLES=y
>
> Merging .kernel-meta/configs/v5.15/standard/./vlan.cfg
> Value of CONFIG_VLAN_8021Q is redefined by fragment 
> .kernel-meta/configs/v5.15/standard/./vlan.cfg:
> Previous value: CONFIG_VLAN_8021Q=m
> New value: CONFIG_VLAN_8021Q=y
>
> Merging .kernel-meta/configs/v5.15/standard/cfg/virtio.cfg
> Merging .kernel-meta/configs/v5.15/standard/features/netfilter/netfilter.cfg
> Value of CONFIG_NETFILTER_XTABLES is redefined by fragment 
> .kernel-meta/configs/v5.15/standard/features/netfilter/netfilter.cfg:
> Previous value: CONFIG_NETFILTER_XTABLES=y
> New value: CONFIG_NETFILTER_XTABLES=m
>
> Value of CONFIG_IP_NF_IPTABLES is redefined by fragment 
> .kernel-meta/configs/v5.15/standard/features/netfilter/netfilter.cfg:
> Previous value: CONFIG_IP_NF_IPTABLES=y
> New value: CONFIG_IP_NF_IPTABLES=m
>
> So my modbusfw.cfg is being overriden by netfilter.cfg.
>
> Any suggestions to fix this?
>
> Thanks
>
> Gary
> 
>


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

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

Re: [yocto] error when try to use sudo command in recipe

[Bruce Ashfield]

On Mon, Apr 3, 2023 at 11:42 AM Adrian Dudau 
wrote:

> Hi Khem,
>
> Thanks for the reply, though I am not sure I fully understand the first
> part of your answer. I'm trying to do something similar to the thread
> creator, i.e running "podman pull" at build time to populate an image store
> that I can later install into the target rootfs.
>
>
FWIW. The above is something that I have almost working, but had to drop
the completion of the support for the upcoming release (it was too late,
and I had to get some kernel changes done). I'm hoping to have something
usable in the next few months.

If you are trying to generate containers (I don't recommend pulling them)
and installing them into a container store that is part of the rootfs, then
collaborating on the meta-virtualization mailing list is a good starting
point.

Bruce



> Still, I am failing to understand why /usr/bin/sudo doesn't show up as
> owned by the root user, even when running under pseudo. Also, why has this
> changed between Dunfell and master and where exactly has the changed
> happened..
>
> Best regards,
> --Adrian
> --
> *From:* Khem Raj 
> *Sent:* Monday, April 3, 2023 4:57 PM
> *To:* Adrian Dudau 
> *Cc:* yocto@lists.yoctoproject.org 
> *Subject:* Re: [yocto] error when try to use sudo command in recipe
>
> You don't often get email from raj.k...@gmail.com. Learn why this is
> important 
> CAUTION: External Sender - Be cautious when clicking links or opening
> attachments. Please email info...@keyfactor.com with any questions.
>
>
>
> On Mon, Apr 3, 2023 at 12:25 AM  wrote:
>
> On Mon, Feb 6, 2023 at 01:13 AM, Richard Purdie wrote:
> Hi Richard,
>
> Jumping on this thread to provide some clarifications as I hit the same
> bug.
> I can confirm that this is not an environment issue. I could reproduce it
> by adding a sudo call in an empty recipe like this:
>
> SUMMARY = ""
> HOMEPAGE = ""
> LICENSE = ""
> SECTION = ""
> DEPENDS = ""
>
> SRC_URI = ""
>
> do_install() {
> ls -l /usr/bin/sudo
> sudo ls -l /usr/bin/sudo
> }
>
>
> Build already use a fake root environment using pseudo to intercept the
> calls so this might not be out of line here. What is the original issue you
> are running into ?
>
>
>
> Running bitbake barebone on my x86 machine produces this error:
>
> | -rwxr-xr-x 1 nobody 65534 232416 Mar  1 13:59 /usr/bin/sudo
> | sudo: /etc/sudo.conf is owned by uid 65534, should be 0
> | sudo: /etc/sudo.conf is owned by uid 65534, should be 0
> | sudo: error in /etc/sudo.conf, line 0 while loading plugin
> "sudoers_policy"
> | sudo: /usr/libexec/sudo/sudoers.so must be owned by uid 0
> | sudo: fatal error, unable to load plugins
>
> Indeed it seems that ownership is broken somehow in the bb environment.
> The issue was introduced somewhere between dunfell and kirkstone. I know
> it's a large timespan but it's a bit time consuming to narrow it down.
>
> Hoping to get some help on this. I would try to investigate further myself
> but I have no idea where to start to be honest.
>
> Best regards,
> --Adrian
>
>
>
>
> 
>
>

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

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

Re: [RFC][yocto][meta-lts-mixins][kirkstone/go] Backport golang from master to kirkstone

[Bruce Ashfield]

On Thu, Mar 30, 2023 at 10:41 AM Jose Quaresma  wrote:
>
> Hi,
>
> I already did some tests using the meta-virt master branch with
> the oe-core kirkstone and this version of the meta-lts-mixins.
> Our stack on meta-virt is not very big but what I tested looks good.
>
> On meta-virt I only need to add kirk compatibility:
> LAYERSERIES_COMPAT_virtualization-layer += "kirkstone"
>
> On meta-lts-mixins I need to change the meta-virt busybox oe-core tracked 
> version:
> PV:pn-busybox-initrd = "1.35.0"
>
> But maybe I need to test this with a large set of recipes in the meta-virt 
> master branch.
> I will add Bruce and I take the opportunity to ask him what he thinks of this 
> approach?
>

I'm not sure I follow which approach you are referring to ?

Tweaking the busybox-initrd and adding your own compatibility tag to
the meta-virt branch you are matching (in this case master) ?

If it works, I don't see any issues with it. I wouldn't carry such a
layerseries_compat update in the layer itself, since additional layers
are required to make it work.

I'm also still willing to carry multiple versions of recipes in
maintained release branches (and set the preferred version to be the
existing recipe), if we need to get a newer version of a recipe in a
release branch to match both security and golang requirements.

Bruce

> Jose
>
>
> Alexander Kanavin  escreveu no dia quinta, 30/03/2023 
> à(s) 14:42:
>>
>> That may require an unknown amount of fixing in the recipes and
>> classes. Existing code is not designed for co-existing with a
>> different version of itself, and so everything needs to be versioned
>> and cleanly separated. But in theory it's possible.
>>
>> Alex
>>
>> On Thu, 30 Mar 2023 at 15:15,  wrote:
>> >
>> > Hi Alex, hi José
>> >
>> > The meta-lts-mixin layers for dunfell have a major disadvantage:
>> > Replacing the go tool-chain breaks more or less all recipes from meta-
>> > virtualization and potentially other layers.
>> >
>> > I think with go it should be possible to have a meta-lts-mixin layer
>> > which adds support for additional go versions instead of overriding the
>> > version provided by poky. That would potentially allow to use poky on
>> > the kirkstone branch and meta-virtualization on a newer branch on the
>> > long run.
>> >
>> > Would it be possible to add e.g. a copy of the go.bbclass as well as
>> > the go recipes from a recent poky version in a way it does not override
>> > the go stack provided by poky?
>> > As an example: Would it be possible to add a go1-19.bbclass to the
>> > meta-meta-lts-mixin layer? This would allow to add also a newer Docker
>> > recipe which inherits go1-19 instead of just go to the meta-lts-mixin
>> > layers without breaking anything from poky or meta-virtualization.
>> >
>> > I already tried to share my thoughts here:
>> > https://lists.openembedded.org/g/openembedded-core/message/178146?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Cgolang%2C20%2C2%2C0%2C97444547
>> >
>> > Best regards,
>> > Adrian
>> >
>> >
>> > On Thu, 2023-03-30 at 12:08 +0200, Alexander Kanavin wrote:
>> > > I think I pushed the work directly to the respecitve branches in
>> > > meta-lts-mixins. I'd suggest you send the patches here, and we'll
>> > > sort
>> > > out the technicalities (I can publish the branch on
>> > > git.yoctoproject.org, or maybe you'll be able to push directly as
>> > > well, provided you also send the patches here). There's no
>> > > autobuilder
>> > > testing; for mixin items the contributors are trusted :)
>> > >
>> > > Alex
>> > >
>> > >
>> > > On Thu, 30 Mar 2023 at 11:20, Jose Quaresma 
>> > > wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > The golang version in kirkstone is the 1.17 and because of this is
>> > > > not possible to use some recent version of other projects like
>> > > > docker that requires a more recent version of the language.
>> > > >
>> > > > I have a kirkstone branch [1] available at Foundries.io with the
>> > > > golang backported from the oe-core master that I liked to submit to
>> > > > the meta-lts-mixins [2].
>> > > > Alex is the maintainer of the dunfell golang backport and this
>> > > > kirkstone branch is based on that version.
>> > > >
>> > > > Would that be interesting for the project? How should I proceed?
>> > > >
>> > > > [1]
>> > > > https://github.com/foundriesio/meta-lts-mixins/tree/kirkstone/go
>> > > > [2] https://git.yoctoproject.org/meta-lts-mixins
>> > > >
>> > > > Jose
>> > > >
>> > > > --
>> > > > Best regards,
>> > > >
>> > > > José Quaresma
>> > >
>> > > 
>> > >
>> >
>
>
>
> --
> Best regards,
>
> José Quaresma



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

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

[yocto] [PATCH 1/2] yocto-bsp/6.1: update reference boards to v6.1.20

[Bruce Ashfield]

From: Bruce Ashfield 

Updating the hardware reference BSPs to match to core qemu machine
versions.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_6.1.bbappend   | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.1.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.1.bbappend
index e693cb32e4..dc58f988eb 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.1.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.1.bbappend
@@ -7,17 +7,17 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_machine:genericx86-64 ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_machine:edgerouter ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_machine:beaglebone-yocto ?= "872afe79c5e568acf5f971952e78caada8424df7"
+SRCREV_machine:genericx86 ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
+SRCREV_machine:genericx86-64 ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
+SRCREV_machine:edgerouter ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
+SRCREV_machine:beaglebone-yocto ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
 COMPATIBLE_MACHINE:edgerouter = "edgerouter"
 COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-LINUX_VERSION:genericx86 = "6.1.3"
-LINUX_VERSION:genericx86-64 = "6.1.3"
-LINUX_VERSION:edgerouter = "6.1.3"
-LINUX_VERSION:beaglebone-yocto = "6.1.3"
+LINUX_VERSION:genericx86 = "6.1.20"
+LINUX_VERSION:genericx86-64 = "6.1.20"
+LINUX_VERSION:edgerouter = "6.1.20"
+LINUX_VERSION:beaglebone-yocto = "6.1.20"
-- 
2.34.1


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

[yocto] [PATCH 2/2] yocto-bsp/5.15: update to v5.15.103

[Bruce Ashfield]

From: Bruce Ashfield 

updating the 5.15 hardware reference BSPs to match the versions of
the oe-core qemu reference platforms.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.15.bbappend  | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
index a969222442..87aa38a85e 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
@@ -7,17 +7,17 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "1275299b4a49c5845378537d2d623dfbe027dcca"
-SRCREV_machine:genericx86-64 ?= "1275299b4a49c5845378537d2d623dfbe027dcca"
-SRCREV_machine:edgerouter ?= "28658152bb865c3e7ffde6ac277fab5dc1940c0a"
-SRCREV_machine:beaglebone-yocto ?= "4f8b81b735ff381cde5ae840552727175393b77a"
+SRCREV_machine:genericx86 ?= "024d08fb706170a9723e9751e505681f9d4c7ab6"
+SRCREV_machine:genericx86-64 ?= "024d08fb706170a9723e9751e505681f9d4c7ab6"
+SRCREV_machine:edgerouter ?= "2ac6461adfceb54f47a756046fbdd142adce4301"
+SRCREV_machine:beaglebone-yocto ?= "26aee42556a000123129552b73de6bf2ac039034"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
 COMPATIBLE_MACHINE:edgerouter = "edgerouter"
 COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-LINUX_VERSION:genericx86 = "5.15.80"
-LINUX_VERSION:genericx86-64 = "5.15.80"
-LINUX_VERSION:edgerouter = "5.15.80"
-LINUX_VERSION:beaglebone-yocto = "5.15.80"
+LINUX_VERSION:genericx86 = "5.15.103"
+LINUX_VERSION:genericx86-64 = "5.15.103"
+LINUX_VERSION:edgerouter = "5.15.103"
+LINUX_VERSION:beaglebone-yocto = "5.15.103"
-- 
2.34.1


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

Re: [yocto] [PATCH 0/2] poky/yocto-bsps: drop 5.19 and move to 6.1

[Bruce Ashfield]

On Wed, Jan 25, 2023 at 3:04 PM Bruce Ashfield via
lists.yoctoproject.org
 wrote:
>
> On Wed, Jan 25, 2023 at 12:34 PM Alexandre Belloni
>  wrote:
> >
> > Hello,
> >
> > One of the two series breaks xen:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/1191/steps/13/logs/stdio
> >
>
> That's chicken and egg.
>
> I won't merge the changes to meta-virt, until oe-core gets the new
> default kernel.

I should add that the fixes should be on the meta-virt master-next branch.

Cheers,

Bruce

>
> Cheers,
>
> Bruce
>
> > On 24/01/2023 17:02:05-0500, Bruce Ashfield wrote:
> > > From: Bruce Ashfield 
> > >
> > > Richard,
> > >
> > > These follow the OEcore patches to remove 5.19. This bumps poky
> > > and poky-tiny to 6.1 and leaves the alt configuration on 5.15.
> > >
> > > Bruce
> > >
> > > The following changes since commit 
> > > 3c3fd6a65e8103f74ae382d196d486b31a168b39:
> > >
> > >   insane: Improve patch warning/error handling (2023-01-21 07:46:38 +)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://git.yoctoproject.org/poky-contrib zedd/kernel-yocto
> > >   
> > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto
> > >
> > > Bruce Ashfield (2):
> > >   poky/poky-tiny: bump preferred version to 6.1
> > >   yocto-bsps: remove 5.19 bbappend
> > >
> > >  meta-poky/conf/distro/poky-tiny.conf  |  2 +-
> > >  meta-poky/conf/distro/poky.conf   |  4 ++--
> > >  .../linux/linux-yocto_5.19.bbappend   | 23 ---
> > >  3 files changed, 3 insertions(+), 26 deletions(-)
> > >  delete mode 100644 
> > > meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend
> > >
> > > --
> > > 2.34.1
> > >
> >
> > >
> > >
> > >
> >
> >
> > --
> > Alexandre Belloni, co-owner and COO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


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

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

Re: [yocto] [PATCH 0/2] poky/yocto-bsps: drop 5.19 and move to 6.1

[Bruce Ashfield]

On Wed, Jan 25, 2023 at 12:34 PM Alexandre Belloni
 wrote:
>
> Hello,
>
> One of the two series breaks xen:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/1191/steps/13/logs/stdio
>

That's chicken and egg.

I won't merge the changes to meta-virt, until oe-core gets the new
default kernel.

Cheers,

Bruce

> On 24/01/2023 17:02:05-0500, Bruce Ashfield wrote:
> > From: Bruce Ashfield 
> >
> > Richard,
> >
> > These follow the OEcore patches to remove 5.19. This bumps poky
> > and poky-tiny to 6.1 and leaves the alt configuration on 5.15.
> >
> > Bruce
> >
> > The following changes since commit 3c3fd6a65e8103f74ae382d196d486b31a168b39:
> >
> >   insane: Improve patch warning/error handling (2023-01-21 07:46:38 +)
> >
> > are available in the Git repository at:
> >
> >   https://git.yoctoproject.org/poky-contrib zedd/kernel-yocto
> >   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto
> >
> > Bruce Ashfield (2):
> >   poky/poky-tiny: bump preferred version to 6.1
> >   yocto-bsps: remove 5.19 bbappend
> >
> >  meta-poky/conf/distro/poky-tiny.conf  |  2 +-
> >  meta-poky/conf/distro/poky.conf   |  4 ++--
> >  .../linux/linux-yocto_5.19.bbappend   | 23 ---
> >  3 files changed, 3 insertions(+), 26 deletions(-)
> >  delete mode 100644 
> > meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend
> >
> > --
> > 2.34.1
> >
>
> >
> > 
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



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

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

[yocto] [PATCH 0/2] poky/yocto-bsps: drop 5.19 and move to 6.1

[Bruce Ashfield]

From: Bruce Ashfield 

Richard,

These follow the OEcore patches to remove 5.19. This bumps poky
and poky-tiny to 6.1 and leaves the alt configuration on 5.15.

Bruce

The following changes since commit 3c3fd6a65e8103f74ae382d196d486b31a168b39:

  insane: Improve patch warning/error handling (2023-01-21 07:46:38 +)

are available in the Git repository at:

  https://git.yoctoproject.org/poky-contrib zedd/kernel-yocto
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (2):
  poky/poky-tiny: bump preferred version to 6.1
  yocto-bsps: remove 5.19 bbappend

 meta-poky/conf/distro/poky-tiny.conf  |  2 +-
 meta-poky/conf/distro/poky.conf   |  4 ++--
 .../linux/linux-yocto_5.19.bbappend   | 23 ---
 3 files changed, 3 insertions(+), 26 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend

-- 
2.34.1


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

[yocto] [PATCH 2/2] yocto-bsps: remove 5.19 bbappend

[Bruce Ashfield]

From: Bruce Ashfield 

5.19 has been dropped from oe-core, so we drop our bbappend to match.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.19.bbappend   | 23 ---
 1 file changed, 23 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend
deleted file mode 100644
index 5794657cfe..00
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend
+++ /dev/null
@@ -1,23 +0,0 @@
-KBRANCH:genericx86  = "v5.19/standard/base"
-KBRANCH:genericx86-64  = "v5.19/standard/base"
-KBRANCH:edgerouter = "v5.19/standard/edgerouter"
-KBRANCH:beaglebone-yocto = "v5.19/standard/beaglebone"
-
-KMACHINE:genericx86 ?= "common-pc"
-KMACHINE:genericx86-64 ?= "common-pc-64"
-KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine:genericx86 ?= "aaf4490d1807c49e3e0ceab1372533937ef2c82b"
-SRCREV_machine:genericx86-64 ?= "aaf4490d1807c49e3e0ceab1372533937ef2c82b"
-SRCREV_machine:edgerouter ?= "43e6ab6ed043f4bc8e7cffbb08af86af0bdb5e12"
-SRCREV_machine:beaglebone-yocto ?= "43e6ab6ed043f4bc8e7cffbb08af86af0bdb5e12"
-
-COMPATIBLE_MACHINE:genericx86 = "genericx86"
-COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-
-LINUX_VERSION:genericx86 = "5.19.17"
-LINUX_VERSION:genericx86-64 = "5.19.17"
-LINUX_VERSION:edgerouter = "5.19"
-LINUX_VERSION:beaglebone-yocto = "5.19"
-- 
2.34.1


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

[yocto] [PATCH 1/2] poky/poky-tiny: bump preferred version to 6.1

[Bruce Ashfield]

From: Bruce Ashfield 

5.19 will be removed shortly, bumping the preferred versions for
poky/poky-tiny to 6.1. The -alt config remains on 5.15.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 meta-poky/conf/distro/poky.conf  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf 
b/meta-poky/conf/distro/poky-tiny.conf
index ce466e30b7..188bd6c8c0 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -44,7 +44,7 @@ FULL_OPTIMIZATION="-Os -pipe ${DEBUG_FLAGS}"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "5.19%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "6.1%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index dc0e8e76ab..1d086b9213 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -20,8 +20,8 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "5.19%"
-PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"
+PREFERRED_VERSION_linux-yocto ?= "6.1%"
+PREFERRED_VERSION_linux-yocto-rt ?= "6.1%"
 
 SDK_NAME = 
"${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.34.1


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

Re: [yocto] do_install hangs on native tasks

[Bruce Ashfield]

On Tue, Dec 6, 2022 at 5:07 PM Christopher Friedt  wrote:
>
> In all cases, the problem is traced back to a Makefile, where
> something calls $(shell git ... ) to get a git version.
>
> I was able to find out because one shell had executed a script called
> scripts/setlocalversion that looked kind of suspicious in terms of
> error propagation. In this script, if I manually echoed "1.6.0" and
> then exited, do_install would not hang.
>
> Some early discussion suggests that it might be avoidable with 'set -o
> pipefail' in the shell, but I haven't investigated further.
>

I don't have anything super helpful to add, but when that git command
is hung, are you seeing any stalled network connections or processes
in D state ?

It wasn't clear from your first message. Are all native processes hanging
at do_install ? or is it a subset ?

Bruce

> C
>
> 
>


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

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

Re: [yocto] Help with setting up a PREEMPT_RT image for BeagleBone Black #yocto

[Bruce Ashfield]

On Tue, Nov 1, 2022 at 5:10 PM Michael T Pham  wrote:

>
> >To build a kernel recipe (not just linux-yocto), it must be marked
> >as compatible with your machine. The messages you are seeing are
> >telling you that, by indicating that the recipes were skipped (since
> >they are not compatible) and once they are all skipped you get a failure
> >as nothing provides virtual/kernel.
> >
> >For linux-yocto, you also need a BSP description that the tooling
> >uses to create the kernel configuration.
>
> I am not sure what is meant by this. Sorry, I'm a complete newbie ':)
>

You can find the details in the yocto manuals, but I'm describing how
the standard/tiny/preempt-rt reference kernels have their configurations
constructed using the kernel-yocto tooling.

For each kernel type, there's a matching config that has the MACHINE
+ kernel type in it. The tools find that description and use it to pull all
the common configs, kernel type specifics and machine fragments into
a final config.

If one doesn't exist, you either need to have your own defconfig, or you
can create one. In this case, you don't need to create one, as it
exists.
i.e.:
https://git.yoctoproject.org/yocto-kernel-cache/tree/bsp/beaglebone/beaglebone-preempt-rt.scc?h=yocto-5.15


>
> >We haven't been testing the beaglebone-yocto reference against -rt,
> >so it isn't marked as compatible by default. That being said, it
> >can be easily made compatible via a bbappend. Look at the
> >meta-yocto-bsp layer, and the bbappends in there. We are adding
> >the reference boards as compatible with linux-yocto. A similar
> >bbappend would work for linux-yocto-rt, and you'd solve that first
> >issue of not having a compatible machine.
>
> I think I see what you're saying. So I would copy the contents of
> /poky/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.19.bbappend
> for linux-yocto-rt? Where is the location to place this?
>

You'd only need to have the beaglebone yocto bits in the new bbappend,
and it would be placed in any layer, in the appropriate subdirectory. This
bappend is no different than any other.

I'm being intentionally terse there, since it is best to read the docs for
this, as I won't do it justice.


>
> >For the BSP description, it does happen that we have one in the
> >linux-yocto configuration meta-data, so one doesn't need to be
> >created. The tools would find that description during the build
> >and use it accordingly. The default KBRANCH should aslo be fine
> >for the beaglebone-yocto, as we aren't carrying any extra patches
> >for the board, so the linux-yocto-rt recipe's default values will
> >get the right branch checked out and built.
>
> Forgive me for not understanding but at first it sounds like you are
> saying I need to create something and then you are saying I don't
> need to?
>

I was describing the general case, and then commenting on this specific
one. I don't want someone to read this later and maybe think that any
machine + linux-yocto-rt combination will "just work".

Bruce



>
> Michael
>


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

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

Re: [yocto] Help with setting up a PREEMPT_RT image for BeagleBone Black #yocto

[Bruce Ashfield]

In message: [yocto] Help with setting up a PREEMPT_RT image for BeagleBone 
Black #yocto
on 27/10/2022 mpha...@gmu.edu wrote:

> Hello all,
> 
> I am new to Yocto and would like to seek assistance for setting up a 
> PREEMPT_RT
> image for BeagleBone Black.
> 
> Here is what I have tried so far. First I followed the Yocto Project Quick
> Build tutorial in the documentation.
> 
> 1)
> sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential
> chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils
> iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint 
> xterm
> python3-subunit mesa-common-dev zstd liblz4-tool
> 
> 2)
> git clone git://git.yoctoproject.org/poky
> 
> 3)
> cd poky
> 
> 4)
> git checkout -t origin/langdale -b my-langdale
> 
> 5)
> git pull
> 
> 6)
> source oe-init-build-env
> 
> 7) Then I went to poky/build/conf and edited local.conf by uncommenting
> MACHINE ?= "beaglebone-yocto"
> and commenting out
> #MACHINE ??= "qemux86-64"
> Then I added these two lines at the bottom of the file:
> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
> COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
> 
> 8) Next I ran this command:
> bitbake core-image-minimal
> 
> 9) Then I get errors at this point.
> ERROR: Nothing PROVIDES 'virtual/kernel'
> linux-yocto-upstream PROVIDES virtual/kernel but was skipped: Set
> PREFERRED_PROVIDER_virtual/kernel to linux-yocto-upstream to enable it
> linux-yocto PROVIDES virtual/kernel but was skipped: Set
> PREFERRED_PROVIDER_virtual/kernel to linux-yocto to enable it
> linux-yocto-rt PROVIDES virtual/kernel but was skipped: incompatible with
> machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> linux-yocto-dev PROVIDES virtual/kernel but was skipped: Set
> PREFERRED_PROVIDER_virtual/kernel to linux-yocto-dev to enable it
> linux-yocto-rt PROVIDES virtual/kernel but was skipped: incompatible with
> machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> linux-yocto-upstream PROVIDES virtual/kernel but was skipped: Set
> PREFERRED_PROVIDER_virtual/kernel to linux-yocto-upstream to enable it
> linux-yocto PROVIDES virtual/kernel but was skipped: Set
> PREFERRED_PROVIDER_virtual/kernel to linux-yocto to enable it
> linux-yocto-tiny PROVIDES virtual/kernel but was skipped: incompatible with
> machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> linux-dummy PROVIDES virtual/kernel but was skipped: 
> PREFERRED_PROVIDER_virtual
> /kernel set to linux-yocto-rt, not linux-dummy
> linux-yocto-tiny PROVIDES virtual/kernel but was skipped: incompatible with
> machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> ERROR: Required build target 'core-image-minimal' has no buildable providers.
> Missing or unbuildable dependency chain was: ['core-image-minimal', 'virtual/
> kernel']
>  
> Summary: There was 1 WARNING message.
> Summary: There were 2 ERROR messages, returning a non-zero exit code.
> 
> I've tried a variety of ways and read lots of links but still no luck. Can
> someone tell me the best way to accomplish my goal?
> Thank you for any help.

To build a kernel recipe (not just linux-yocto), it must be marked
as compatible with your machine. The messages you are seeing are
telling you that, by indicating that the recipes were skipped (since
they are not compatible) and once they are all skipped you get a failure
as nothing provides virtual/kernel.

For linux-yocto, you also need a BSP description that the tooling
uses to create the kernel configuration.

We haven't been testing the beaglebone-yocto reference against -rt,
so it isn't marked as compatible by default. That being said, it
can be easily made compatible via a bbappend. Look at the
meta-yocto-bsp layer, and the bbappends in there. We are adding
the reference boards as compatible with linux-yocto. A similar
bbappend would work for linux-yocto-rt, and you'd solve that first
issue of not having a compatible machine.

For the BSP description, it does happen that we have one in the
linux-yocto configuration meta-data, so one doesn't need to be
created. The tools would find that description during the build
and use it accordingly. The default KBRANCH should aslo be fine
for the beaglebone-yocto, as we aren't carrying any extra patches
for the board, so the linux-yocto-rt recipe's default values will
get the right branch checked out and built.

Whether it builds (it should), boots (it should) or gives you
appropriate -rt performance (unknown) .. are other questions
that are to be answered :)

Bruce


> 
> Michael

> 
> 
> 


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

Re: [yocto] do_kernel_configme - Could not generate configuration queue

[Bruce Ashfield]

On Tue, Oct 18, 2022 at 5:01 PM Jeremy Puhlman  wrote:

> On 10/14/2022 6:52 PM, Bruce Ashfield wrote:
>
>
>
> On Fri, Oct 14, 2022 at 10:11 PM Jose Quaresma 
> wrote:
>
>> Hi Rudolf,
>>
>> I have reported this issue and together with a path [1] to fix it.
>> Anyway Bruce has fixed the issue in another way in [2] and this works for
>> me as well.
>>
>> [1] https://lists.yoctoproject.org/g/linux-yocto/message/11746
>> [2]
>> https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=6a4752ebbe7d242c02b3c74a5772926edd243626
>>
>>
> Yes indeed. This has also passed my other regression testing, but I was
> traveling today and couldn't send my pull request.
>
> I'll send it over the weekend, so hopefully it'll be merged shortly!
>
> Bruce
>
>
> Did this end up getting sen to the list? I also validated updating to the
> specific hash resolved my issue too.
>
>
Nope. I got tied up with some other issues, I'll send it tonight when I get
a moment!

Bruce



>
>
>> Jose
>>
>> Rudolf J Streif  escreveu no dia sábado,
>> 15/10/2022 à(s) 01:45:
>>
>>> I am running into a bizarre problem with kernel configuration.
>>>
>>> I have an existing build environment that builds for an i.MX6ul machine.
>>> That works fine and the linux-fslc kernel 5.18 builds without any
>>> problems. Now within the that build environment I changed the machine to
>>> imx6ullevk and then the kernel configuration fails with this error
>>> message:
>>>
>>> | DEBUG: Executing shell function do_kernel_configme
>>> | NOTE: do_kernel_metadata: for summary/debug, set KCONF_AUDIT_LEVEL > 0
>>> | [ERROR]: processing of file /tmp/tmp.owmBptYrba failed
>>> | /develop/projects/altec/tcu/build/tmp/hosttools/dirname: missing
>>> operand
>>> | Try '/develop/projects/altec/tcu/build/tmp/hosttools/dirname --help'
>>> for more information.
>>> | ERROR: Could not generate configuration queue for imx6ullevk.
>>> | WARNING:
>>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
>>>
>>> exit 1 from 'exit 1'
>>> | WARNING: Backtrace (BB generated script):
>>> | #1: bbfatal_log,
>>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>>
>>> line 209
>>> | #2: do_kernel_metadata,
>>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>>
>>> line 382
>>> | #3: do_kernel_configme,
>>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>>
>>> line 150
>>> | #4: main,
>>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>>
>>> line 484
>>> ERROR: Task
>>>
>>> (/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
>>>
>>> failed with exit code '1'
>>>
>>> I tried to debug do_kernel_configme. The issue seems in the scc script
>>> more specifically, I think, in the kconf command that is called by scc
>>> when parsing the temporary configuration queue file in /tmp:
>>> tmp.owmBptYrba
>>>
>>> #
>>> # spp v0.8
>>> # processed: Fri Oct 14 09:49:02 PM UTC 2022
>>> #
>>> # This is a preprocessor output file, do not edit
>>> #
>>> #
>>> prefix
>>>
>>> /develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
>>> kconf non-hardware
>>>
>>> /develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
>>> # run time: 0 seconds
>>> # processed files:
>>> # _cfg
>>>
>>> /develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
>>>
>>> Apparently a call to dirname is missing the argument. However, I do not
>>> understand why.
>>>
>>> I wiped out build/tmp directory entirely, ran a cleanall on
>>> virtual/kernel but to no avail. The problem remains the same.
>>>
>>> Has anybody seen this issue before?
>>>
>>>
>>> Rudi
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Best regards,
>>
>> José Quaresma
>>
>>
>>
>>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> Jeremy A. puhlmanjpuhl...@mvista.com
>
>
> 
>
>

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

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

Re: [yocto] Dealing with go dependencies in recipes - native docker-compose

[Bruce Ashfield]

On Tue, Oct 18, 2022 at 9:17 AM Bruce Ashfield via lists.yoctoproject.org
 wrote:

>
>
> On Tue, Oct 18, 2022 at 6:56 AM Konstantin Kletschke <
> konstantin.kletsc...@inside-m2m.de> wrote:
>
>> On Sun, Oct 16, 2022 at 10:28:18PM -0400, Bruce Ashfield wrote:
>>
>> > FYI: Here's the very lightly tested RFC version of the recipe:
>> >
>> >
>> https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630
>>
>> Thanks for the kind notification.
>>
>> My stuff is based upon kirkstone, I stuffed the recipe from master-next
>> into my kirkstone build. One package of this new docker-compose is
>> depending
>> upon go-1.19 (kirkstone provides go-1.17) so I pulled in go-1.19 from
>> langdale also into my kirkstone build.
>>
>> The compiling and building works just fine! The recipe(s) for
>> docker-compose look impressive, I would not have expected them being so
>> complex. But they work.
>>
>>
> The amount of fetches is certainly impressive, but it is like that for any
> non-vendored go application, whether we can see it or not.  When the
> recipes are simple, all of the fetching and source structuring takes place
> behind the scenes (I know, I'm stating the obvious), just in a manner we
> don't control.
>
> I just yank the complexity out to the front, and go directly to the
> upstream sources of all the go libraries/packages. If we let go fetch it,
> we have to both rely on the versions being in the fetch locations
> "forever", or the infrastructure always being available (it should, but you
> never know). We then have to setup our own go proxy/mirror infrastructure
> to get around those two issues, and have now become curators of our own
> repositories and infrastructure. That infrastructure isn't really hard to
> setup, but in a maintenance mode, updating it, and getting new versions of
> the code for CVEs, etc, could be challenging.
>
> By doing the fetches directly, all of the established infrastructure,
> archiving, mirrors, licensing, etc, "just work", and we can bump the SRCREV
> of any dependency if a CVE or issue is found.
>
> Definitely a balancing act, with no 'one true answer' yet, so I've been
> going with what I know works :)
>
> Two notes:
>>
>> After installing the package provides /bin/docker-compose. I realized
>> other parties provide this as /usr/lib/docker/cli-plugins/docker-compose
>> which make something like "docker compose version" working. For me this
>> does not harm, only as remark. May be this is intentional.
>>
>
> Completely random. I just put it there. I'll make that adjustment in the
> recipe.
>
>
>> Upon investigating I realized the version reported by docker-compose is
>> "dev" instead of the expected "v2.11.2".
>>
>
> I saw the same thing, and was looking into fixing it, I figured it was
> worth getting the recipe out, before I did more tweaking.
>

emux86-64-c9 login: root

root@qemux86-64-c9:~# /usr/lib/docker/cli-plugins/docker-compose version

Docker Compose version v2.11.2

Cheers,

Bruce


>
>>
>> Great work, thank you!
>>
>
> I appreciate the testing and the report, very helpful!
>
> Bruce
>
>
>>
>> Regards Konstantin
>>
>>
>>
>>
>>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
> 
>
>

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

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

Re: [yocto] Dealing with go dependencies in recipes - native docker-compose

[Bruce Ashfield]

On Tue, Oct 18, 2022 at 6:56 AM Konstantin Kletschke <
konstantin.kletsc...@inside-m2m.de> wrote:

> On Sun, Oct 16, 2022 at 10:28:18PM -0400, Bruce Ashfield wrote:
>
> > FYI: Here's the very lightly tested RFC version of the recipe:
> >
> >
> https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630
>
> Thanks for the kind notification.
>
> My stuff is based upon kirkstone, I stuffed the recipe from master-next
> into my kirkstone build. One package of this new docker-compose is
> depending
> upon go-1.19 (kirkstone provides go-1.17) so I pulled in go-1.19 from
> langdale also into my kirkstone build.
>
> The compiling and building works just fine! The recipe(s) for
> docker-compose look impressive, I would not have expected them being so
> complex. But they work.
>
>
The amount of fetches is certainly impressive, but it is like that for any
non-vendored go application, whether we can see it or not.  When the
recipes are simple, all of the fetching and source structuring takes place
behind the scenes (I know, I'm stating the obvious), just in a manner we
don't control.

I just yank the complexity out to the front, and go directly to the
upstream sources of all the go libraries/packages. If we let go fetch it,
we have to both rely on the versions being in the fetch locations
"forever", or the infrastructure always being available (it should, but you
never know). We then have to setup our own go proxy/mirror infrastructure
to get around those two issues, and have now become curators of our own
repositories and infrastructure. That infrastructure isn't really hard to
setup, but in a maintenance mode, updating it, and getting new versions of
the code for CVEs, etc, could be challenging.

By doing the fetches directly, all of the established infrastructure,
archiving, mirrors, licensing, etc, "just work", and we can bump the SRCREV
of any dependency if a CVE or issue is found.

Definitely a balancing act, with no 'one true answer' yet, so I've been
going with what I know works :)

Two notes:
>
> After installing the package provides /bin/docker-compose. I realized
> other parties provide this as /usr/lib/docker/cli-plugins/docker-compose
> which make something like "docker compose version" working. For me this
> does not harm, only as remark. May be this is intentional.
>

Completely random. I just put it there. I'll make that adjustment in the
recipe.


> Upon investigating I realized the version reported by docker-compose is
> "dev" instead of the expected "v2.11.2".
>

I saw the same thing, and was looking into fixing it, I figured it was
worth getting the recipe out, before I did more tweaking.


>
> Great work, thank you!
>

I appreciate the testing and the report, very helpful!

Bruce


>
> Regards Konstantin
>
>
> 
>
>

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

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

Re: [yocto] Dealing with go dependencies in recipes - native docker-compose

[Bruce Ashfield]

On Thu, Oct 13, 2022 at 10:05 AM Konstantin Kletschke <
konstantin.kletsc...@inside-m2m.de> wrote:

> On Tue, Oct 11, 2022 at 11:23:31PM -0300, Bruce Ashfield wrote:
>
> > Adding the missing setuptools does get things working.
>
> Oh my, I was still looking for python3-distutils (deprecated, not
> available) and did not realize I now need setuptools. Thanks for
> clarifying, however, I investigated the gao approach then...
>
>
> > I actually have a prototype recipe for this that I was working on before
> > ELCe, but I didn't get it into meta-virtualization yet, as it had a few
> > rough edges.
>
> I suppose, those go recipes look extremly difficult to do.
>
> > If you give me a few days, I can post it to the meta-virtualization list,
> > but I'm on the road right now and don't have access to all my build
> > machines.
>
> Of course I have patience and I am very curious to test this out!
> Currently I have no urge but in future it will be extremely handy to
> have the native docker compose approach available. It is a bit smaller
> then the python approach (if python is only used by this docker-compose,
> a third disk space is used by native approach).
>
> > I also did a presentation at the yocto summit about "modern languages".
>
> Opps, interesting. No need to summarize here, I agree. I will dig this
> up in the internet. Interesting...
>
> > You can see the approach that I take for this in the k3s and nerdctl
> recipes
> > in meta-virtualization. My new docker-compose recipe is of similar
> format.
>
> As I vaguely mentioned above, those recipes look far more complex than I
> would have imagined when starting to dig into the go world...
> astonishing!
>

FYI: Here's the very lightly tested RFC version of the recipe:

https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630

Cheers,

Bruce


> > If we just bypass the fetcher, offline builds, some of licensing and SBOM
> > and reproducible builds .. you can have a simple recipe like that as
> well :)
>
> Yea, and I already learned to lovae this reproducibility approach.
>
> --
> INSIDE M2M GmbH
> Konstantin Kletschke
> Berenbosteler Straße 76 B
> 30823 Garbsen
>
> Telefon: +49 (0) 5137 90950136
> Mobil: +49 (0) 151 15256238
> Fax: +49 (0) 5137 9095010
>
> konstantin.kletsc...@inside-m2m.de
> http://www.inside-m2m.de
>
> Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek
> Uhlig
> HRB: 111204, AG Hannover
>
>
> 
>
>

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

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

Re: [yocto] do_kernel_configme - Could not generate configuration queue

[Bruce Ashfield]

On Fri, Oct 14, 2022 at 10:11 PM Jose Quaresma 
wrote:

> Hi Rudolf,
>
> I have reported this issue and together with a path [1] to fix it.
> Anyway Bruce has fixed the issue in another way in [2] and this works for
> me as well.
>
> [1] https://lists.yoctoproject.org/g/linux-yocto/message/11746
> [2]
> https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=6a4752ebbe7d242c02b3c74a5772926edd243626
>
>
Yes indeed. This has also passed my other regression testing, but I was
traveling today and couldn't send my pull request.

I'll send it over the weekend, so hopefully it'll be merged shortly!

Bruce



> Jose
>
> Rudolf J Streif  escreveu no dia sábado,
> 15/10/2022 à(s) 01:45:
>
>> I am running into a bizarre problem with kernel configuration.
>>
>> I have an existing build environment that builds for an i.MX6ul machine.
>> That works fine and the linux-fslc kernel 5.18 builds without any
>> problems. Now within the that build environment I changed the machine to
>> imx6ullevk and then the kernel configuration fails with this error
>> message:
>>
>> | DEBUG: Executing shell function do_kernel_configme
>> | NOTE: do_kernel_metadata: for summary/debug, set KCONF_AUDIT_LEVEL > 0
>> | [ERROR]: processing of file /tmp/tmp.owmBptYrba failed
>> | /develop/projects/altec/tcu/build/tmp/hosttools/dirname: missing operand
>> | Try '/develop/projects/altec/tcu/build/tmp/hosttools/dirname --help'
>> for more information.
>> | ERROR: Could not generate configuration queue for imx6ullevk.
>> | WARNING:
>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
>>
>> exit 1 from 'exit 1'
>> | WARNING: Backtrace (BB generated script):
>> | #1: bbfatal_log,
>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>
>> line 209
>> | #2: do_kernel_metadata,
>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>
>> line 382
>> | #3: do_kernel_configme,
>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>
>> line 150
>> | #4: main,
>> /develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
>>
>> line 484
>> ERROR: Task
>>
>> (/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
>>
>> failed with exit code '1'
>>
>> I tried to debug do_kernel_configme. The issue seems in the scc script
>> more specifically, I think, in the kconf command that is called by scc
>> when parsing the temporary configuration queue file in /tmp:
>> tmp.owmBptYrba
>>
>> #
>> # spp v0.8
>> # processed: Fri Oct 14 09:49:02 PM UTC 2022
>> #
>> # This is a preprocessor output file, do not edit
>> #
>> #
>> prefix
>>
>> /develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
>> kconf non-hardware
>>
>> /develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
>> # run time: 0 seconds
>> # processed files:
>> # _cfg
>>
>> /develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
>>
>> Apparently a call to dirname is missing the argument. However, I do not
>> understand why.
>>
>> I wiped out build/tmp directory entirely, ran a cleanall on
>> virtual/kernel but to no avail. The problem remains the same.
>>
>> Has anybody seen this issue before?
>>
>>
>> Rudi
>>
>>
>>
>>
>>
>>
>
> --
> Best regards,
>
> José Quaresma
>
> 
>
>

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

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

Re: [yocto] Dealing with go dependencies in recipes - native docker-compose

[Bruce Ashfield]

On Tue, Oct 11, 2022 at 2:51 PM Konstantin Kletschke <
konstantin.kletsc...@inside-m2m.de> wrote:

> Today I realized, that the docker-compose in the meta-virtualization
> layer is the old python3 based one and a native solution is available. I
> tried to make a recipe for it to get rid of python3 (no other packages
> uses it in our setup) and the current python3-docker-compose is broken:
>
>
> https://lore.kernel.org/yocto-meta-virtualization/49660ea1-cd22-40db-98c7-c43f38a72...@ieee.org/


Adding the missing setuptools does get things working.



>
>
> I tried to build the native solution proposed in
> https://github.com/docker/compose/tree/v2.11.2.
>

I actually have a prototype recipe for this that I was working on before
ELCe, but I didn't get it into meta-virtualization yet, as it had a few
rough edges.

If you give me a few days, I can post it to the meta-virtualization list,
but I'm on the road right now and don't have access to all my build
machines.

>
> So my current recipe docker-compose_2.11.2.bb looks like this:
>
> LICENSE = "Apache-2.0"
>
> inherit go
> inherit go-mod
>
> GO_IMPORT = "github.com/docker/compose"
>
> SRC_URI = "git://${GO_IMPORT};protocol=https;branch=v2"
> # v2.11.2
> SRCREV = "616777eb4ad4d1101622d6727d9b7adaeb7943bb"
>
> # S = "${WORKDIR}/git"
>
> DEPENDS = "docker-ce"
> RDEPENDS:${PN} = "docker-ce-cli"
>
> With this I run into the issue, that go want's to download stuff while
> compiling. Which is forbidden and breaks the reliable build proposal.
> Totally understandable. Looks similair to this:
>
> dial tcp: lookup proxy.golang.org: Temporary failure in name resolution
>
> I read about a proposal allowing this by adding do_compile[network] =
> "1" to meta/classes/go.bb:
>
> https://lore.kernel.org/all/20220228235433.3948994-1-and...@gherzan.com/
>
> Of course, if this works, the reliable build thingy is gone, but while
>

Right, it works, but would never make it into core due to it bypassing many
of the fetcher properties.



> trying I discovered go loads external stuff, compiles it too.
> In my case (I have kirkstone with go-1.17) I run into modules demanding
> a go more recent:
>
> ASH[build k8s.io/client-go/applyconfigurations/autoscaling/v2beta2]:
> "file containerresourcemetricsource.go Mas4-HIX5lGBEQNTIo58\n"
> # github.com/docker/compose/v2/pkg/utils
> pkg/utils/slices.go:23:6: missing function body
> pkg/utils/slices.go:23:14: syntax error: unexpected [, expecting (
> note: module requires Go 1.19
> HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]
> HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]:
> "go1.17.13"
>
> which could be worked around by moving to landsdale release. Which
> bothers me, because I too want to keep my build reliable. And I do not
> want to mess around outside our meta layer in the distribution!
> How do I do this properly?
> I see people pulling in each dependency by individual golang.org-x.bb
> recipes, how could such a recipe look like?
>

There are many different discussions about how to generate go recipes, as
well
as similar discussions for ruby/rust, etc, you can find them on the
openembedded-core
and openembedded-architectures lists.

I also did a presentation at the yocto summit about "modern languages".

So I won't try and summarize all those discussions here, since they are
archived
and do a much better job than I could here.

But to answer the specific question .. you can't really handle the
individual
go dependencies as recipes. They are far too sensitive to versions and
individual git hashes.  Plus you'll end up with thousands of recipes of
varying
versions.

There have been several proposals about how to generate go recipes to deal
with
the dependencies. Some prototypes have been posted, but there hasn't
been a lot of traffic on that topic for several months now.

You can see the approach that I take for this in the k3s and nerdctl recipes
in meta-virtualization. My new docker-compose recipe is of similar format.


>
> I read
>
> https://lore.kernel.org/all/8132db85-5881-636e-c091-d84c47efe...@gmail.com/T/
> where Mike is not happy with this appraoch either and comes up with a
> working recipe I don't get why this could work at all.
>
> What am I missing here where is the missing link I did not get yet?
>
> Also, I am jealous about the buildroot guys sometimes, how do they do
> this in a 22 lines makefile including comments:
>
>
> https://git.busybox.net/buildroot/tree/package/docker-compose/docker-compose.mk
>
>
If we just bypass the fetcher, offline builds, some of licensing and SBOM
and reproducible builds .. you can have a simple recipe like that as well :)

Bruce



>
> Regards
> Konstantin
>
> --
> INSIDE M2M GmbH
> Konstantin Kletschke
> Berenbosteler Straße 76 B
> 30823 Garbsen
>
> Telefon: +49 (0) 5137 90950136
> Mobil: +49 (0) 151 15256238
> Fax: +49 (0) 5137 9095010
>
> konstantin.kletsc...@inside-m2m.de
> http://www.inside-m2m.de
>
> Geschäftsführung: Michael Emmert, Ingo

[yocto] [PATCH 1/2] yocto-bsps: update to v5.15.54

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

843dae1756d9 Linux 5.15.54
c0c041a60cac selftests/net: fix section name when using xdp_dummy.o
a5fe76328ea5 dmaengine: idxd: force wq context cleanup on device disable 
path
568b2bd79b59 dmaengine: ti: Add missing put_device in 
ti_dra7_xbar_route_allocate
2f6ded79068c dmaengine: qcom: bam_dma: fix runtime PM underflow
cb9813d7eae9 dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
e08ccbaa5fb3 dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() 
correctly
c787908bee3f dmaengine: lgm: Fix an error handling path in 
intel_ldma_probe()
0bbb30d077f2 dmaengine: pl330: Fix lockdep warning about non-static key
8b07022de2d3 ida: don't use BUG_ON() for debugging
9839d89112d4 dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typo
e99bad0d76cf Revert "serial: 8250_mtk: Make sure to select the right 
FEATURE_SEL"
2fa22e7906c1 Revert "mm/memory-failure.c: fix race with changing page 
compound again"
c1c98764c3c3 misc: rtsx_usb: set return value in rsp_buf alloc err path
bab1a05a1141 misc: rtsx_usb: use separate command and response buffers
378080b7d8dd misc: rtsx_usb: fix use of dma mapped buffer for usb bulk 
transfer
d76704f8ccbb dmaengine: imx-sdma: Allow imx8m for imx7 FW revs
530ee8d3c6a4 i2c: cadence: Unregister the clk notifier in error path
941d77b795d1 r8169: fix accessing unset transport header
3abec0b38173 selftests: forwarding: fix error message in learning_test
1b74fe2e8f5c selftests: forwarding: fix learning_test when h1 supports 
IFF_UNICAST_FLT
8e5fcfecd99a selftests: forwarding: fix flood_unicast_test when h2 supports 
IFF_UNICAST_FLT
3fdca34e7811 ibmvnic: Properly dispose of all skbs during a failover.
5912e5e47ac9 ARM: dts: stm32: add missing usbh clock and fix clk order on 
stm32mp15
d5670adf5cff ARM: dts: stm32: use usbphyc ck_usbo_48m as USBH OHCI clock on 
stm32mp151
ddec6cbbe227 i40e: Fix VF's MAC Address change on VM
9d1e322a9103 i40e: Fix dropped jumbo frames statistics
d2bf1a6480e8 i2c: piix4: Fix a memory leak in the EFCH MMIO support
e7a1d5100921 xsk: Clear page contiguity bit when unmapping pool
a2b92fffd51b ARM: at91: fix soc detection for SAM9X60 SiPs
e3ee4ffa3c92 ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
f5b0e6d7b453 ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
a65b92628ae0 ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt
cfd0e717bd93 ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
9ec5fe55ba75 ARM: at91: pm: use proper compatible for sama5d2's rtc
ec5533b2ce26 arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
76292cf4b3bc pinctrl: sunxi: sunxi_pconf_set: use correct offset
c041165d8f04 arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc 
settings
44826474a39a arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad 
settings
ea8dbe870c84 arm64: dts: imx8mp-phyboard-pollux-rdk: correct uart pad 
settings
67a21eb8c48e arm64: dts: imx8mp-evk: correct I2C3 pad settings
b34da817e3fa arm64: dts: imx8mp-evk: correct I2C1 pad settings
37413a0ea090 arm64: dts: imx8mp-evk: correct eqos pad settings
ebad4d73ab1c arm64: dts: imx8mp-evk: correct vbus pad settings
f1571c8c8724 arm64: dts: imx8mp-evk: correct gpio-led pad settings
637b3dab51f7 arm64: dts: imx8mp-evk: correct the uart2 pinctl value
401d27fec614 arm64: dts: imx8mp-evk: correct mmc pad settings
ee1ced3dd863 ARM: mxs_defconfig: Enable the framebuffer
89a718d1d080 arm64: dts: qcom: sdm845: use dispcc AHB clock for mdss node
216094007699 arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
4157343a6a1a ASoC: codecs: rt700/rt711/rt711-sdca: resume bus/codec in 
.set_jack_detect
ac80a45ddb62 ASoC: rt711-sdca: Add endianness flag in 
snd_soc_component_driver
25e61636a5c3 ASoC: rt711: Add endianness flag in snd_soc_component_driver
29029ca6eed7 pinctrl: sunxi: a83t: Fix NAND function name for some pins
7208101ded1e ARM: meson: Fix refcount leak in meson_smp_prepare_cpus
9c26be2c3e69 tty: n_gsm: fix encoding of command/response bit
3b9f49138669 btrfs: fix use of uninitialized variable at rm device ioctl
cb91c0548ff2 virtio-blk: modify the value type of num in virtio_queue_rq()
d35b78cb053a btrfs: fix error pointer dereference in btrfs_ioctl_rm_dev_v2()
f88e79727fba Revert "serial: sc16is7xx: Clear RS485 bits in the shutdown"
83d3449e8ae5 xfs: remove incorrect ASSERT in xfs_rename
63a3d2377715 can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits
420b99306b7e can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency 
regression
baffaed7fab3 can: kvaser_usb: replace run-time checks with struct 
kvaser_usb_driver_info
   

[yocto] [PATCH 2/2] yocto-bsps: update to v5.10.130

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:

26ae9c361414 Linux 5.10.130
8365b151fd50 dmaengine: ti: Add missing put_device in 
ti_dra7_xbar_route_allocate
37147e22cd8d dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
1be247db203e dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() 
correctly
7b721f5aec92 dmaengine: pl330: Fix lockdep warning about non-static key
e23cfb3fdcbb ida: don't use BUG_ON() for debugging
37995f034ff2 dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typo
ca4a91958466 misc: rtsx_usb: set return value in rsp_buf alloc err path
ff79e0ca2bea misc: rtsx_usb: use separate command and response buffers
af7d9d4abe84 misc: rtsx_usb: fix use of dma mapped buffer for usb bulk 
transfer
86884017bb63 dmaengine: imx-sdma: Allow imx8m for imx7 FW revs
9b329edd77ca i2c: cadence: Unregister the clk notifier in error path
26938bd28c0c r8169: fix accessing unset transport header
904f622ec78e selftests: forwarding: fix error message in learning_test
9906c223400f selftests: forwarding: fix learning_test when h1 supports 
IFF_UNICAST_FLT
859b889029fc selftests: forwarding: fix flood_unicast_test when h2 supports 
IFF_UNICAST_FLT
23cdc57d88d1 ibmvnic: Properly dispose of all skbs during a failover.
2b4659c145ba i40e: Fix dropped jumbo frames statistics
5561bddd0599 xsk: Clear page contiguity bit when unmapping pool
87d2bb888259 ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
9b7d8e28b686 ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
ade03e5ea778 ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
b40ac801cbb1 ARM: at91: pm: use proper compatible for sama5d2's rtc
4c3e73a66a27 arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
1d0c3ced2d1c pinctrl: sunxi: sunxi_pconf_set: use correct offset
e1cda2a03d81 arm64: dts: imx8mp-evk: correct I2C3 pad settings
2ade1b1d92f6 arm64: dts: imx8mp-evk: correct gpio-led pad settings
17b3883ba55f arm64: dts: imx8mp-evk: correct the uart2 pinctl value
43319ee6a075 arm64: dts: imx8mp-evk: correct mmc pad settings
6bf74a1e748f arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
2c0d10ce002a pinctrl: sunxi: a83t: Fix NAND function name for some pins
3d90607e7e6a ARM: meson: Fix refcount leak in meson_smp_prepare_cpus
e14930e9f9c6 xfs: remove incorrect ASSERT in xfs_rename
852952ea0e15 can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits
a741e762e199 can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency 
regression
f439d08ef1a2 can: kvaser_usb: replace run-time checks with struct 
kvaser_usb_driver_info
79af7be44ccb powerpc/powernv: delay rng platform device creation until 
later in boot
19104425c962 video: of_display_timing.h: include errno.h
96fa24eb1a38 memregion: Fix memregion_free() fallback definition
d6931bff1cc1 PM: runtime: Redefine pm_runtime_release_supplier()
cecb806c766c fbcon: Prevent that screen size is smaller than font size
b727561ddc93 fbcon: Disallow setting font bigger than screen size
b81212828ad1 fbmem: Check virtual screen sizes in fb_set_var()
d03e8ed72d7d fbdev: fbmem: Fix logo center image dx issue
963c80f070ed iommu/vt-d: Fix PCI bus rescan device hot add
0a5e36dbcb44 netfilter: nf_tables: stricter validation of element data
4a6430b99f67 netfilter: nft_set_pipapo: release elements in clone from 
abort path
4f59d12efe30 net: rose: fix UAF bug caused by rose_t0timer_expiry
0085da9df3dc usbnet: fix memory leak in error case
e917be1f83ea bpf: Fix insufficient bounds propagation from 
adjust_scalar_min_max_vals
9adec7334969 bpf: Fix incorrect verifier simulation around jmp32's jeq/jne
d0b8e2239988 can: gs_usb: gs_usb_open/close(): fix memory leak
b6f4b347a1fb can: grcan: grcan_probe(): remove extra of_node_get()
85cd41070df9 can: bcm: use call_rcu() instead of costly synchronize_rcu()
b75d4bec85b8 ALSA: hda/realtek: Add quirk for Clevo L140PU
6c32496964da mm/slub: add missing TID updates on slab deactivation
7208d1236f72 Linux 5.10.129
0e21ef18019c clocksource/drivers/ixp4xx: remove EXPORT_SYMBOL_GPL from 
ixp4xx_timer_setup()
7055e3446244 net: usb: qmi_wwan: add Telit 0x1070 composition
f1a53bb27f17 net: usb: qmi_wwan: add Telit 0x1060 composition
43c8d33ce353 xen/arm: Fix race in RB-tree based P2M accounting
547b7c640df5 xen-netfront: restore __skb_queue_tail() positioning in 
xennet_get_responses()
cbbd2d253153 xen/blkfront: force data bouncing when backend is untrusted
4923217af574 xen/netfront: force data bouncing when backend is untrusted
728d68bfe68d xen/netfront: fix leaking data in shared pages
cfea428030be xen/blkfront: fix leaking data in shared pages
d341e5a75480 selftests/rseq: Change type of rseq_offset to ptrdif

Re: [yocto] [PATCH 00/10] linux-yocto: consolidated pull request

[Bruce Ashfield]

On Thu, Jul 14, 2022 at 3:12 PM Bruce Ashfield via
lists.yoctoproject.org
 wrote:
>
> From: Bruce Ashfield 
>
> Richard,
>
> The gen-mach-types patches are repeats of ones I sent before, but I've
> included them to make the ordering clear.
>
> After that, we have two -stable updates (getting ready for the "big"
> CVE updates)
>
> And then the pnmtologo fixes. That should be all the builpaths warnings.
>
> I'm sending this all to oe-core fo simplicty sake, but obviously the
> yocto-bsp ones are for the yocto layers.

Clearly, I did the opposite of what I claimed, I'm resending to
oe-core for a wider audience.

Bruce

>
> Brue
>
> The following changes since commit e65ee81d621e679107b5f4ef2dbbb8d1786e93ad:
>
>   ltp: fix builds when host ld doesn't know about target ELF formats 
> (2022-07-14 10:08:57 +0100)
>
> are available in the Git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zedd/kernel
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
>
> Bruce Ashfield (10):
>   linux-yocto/5.10: fix buildpaths issue with gen-mach-types
>   linux-yocto/5.15: fix buildpaths issue with gen-mach-types
>   yocto-bsps/5.10: fix buildpaths issue with gen-mach-types
>   yocto-bsps/5.15: fix buildpaths issue with gen-mach-types
>   linux-yocto/5.15: update to v5.15.54
>   linux-yocto/5.10: update to v5.10.130
>   linux-yocto/5.15: fix buildpaths issue with pnmtologo
>   linux-yocto/5.10: fix buildpaths issue with pnmtologo
>   yocto-bsps/5.10: fix buildpaths issue with pnmtologo
>   yocto-bsps/5.15: fix buildpaths issue with pnmtologo
>
>  .../linux/linux-yocto_5.10.bbappend   |  8 +++---
>  .../linux/linux-yocto_5.15.bbappend   |  8 +++---
>  .../linux/linux-yocto-rt_5.10.bb  |  6 ++---
>  .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
>  .../linux/linux-yocto-tiny_5.10.bb|  8 +++---
>  .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
>  meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 -
>  meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
>  8 files changed, 46 insertions(+), 46 deletions(-)
>
> --
> 2.19.1
>
>
> 
>


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

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

[yocto] [PATCH 10/10] yocto-bsps/5.15: fix buildpaths issue with pnmtologo

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

a40d2daf2795 pnmtologo: use relocatable file name

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_5.15.bbappend| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
index 8d2ec873fa..52aa36b2e6 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
-SRCREV_machine:genericx86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
-SRCREV_machine:edgerouter ?= "e90573857c176458965737d77b1747be83fe7edc"
-SRCREV_machine:beaglebone-yocto ?= "d91bb88e58c575e7c3b9fb111b6711a206eba64b"
+SRCREV_machine:genericx86 ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
+SRCREV_machine:genericx86-64 ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
+SRCREV_machine:edgerouter ?= "90f1ee6589264545f548d731c2480b08a007230f"
+SRCREV_machine:beaglebone-yocto ?= "9aabbaa89fcb21af7028e814c1f5b61171314d5a"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-- 
2.19.1


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

[yocto] [PATCH 08/10] linux-yocto/5.10: fix buildpaths issue with pnmtologo

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

2883e69e202d pnmtologo: use relocatable file name

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.10.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.10.bb|  4 ++--
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 20 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index 40cc21bceb..53ccd41033 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "faeb2e0ef8f7014788d4e8152d4f5698a7472e0f"
+SRCREV_machine ?= "63771123b1eea439bea2cf80f9f5682667528d9f"
 SRCREV_meta ?= "96ea2660bb97e15f48f4885b9e436f24c3606bd9"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index 2993ddc951..7b3aaa7fa0 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "da9808c1a36f935dec2b90fb5fa5f9df4ff400a3"
-SRCREV_machine ?= "bf0ae2ab0102a68bad4a586fd42ceb78cc0a24e1"
+SRCREV_machine:qemuarm ?= "bff12aa9748d83efc518e524858913c028f0707a"
+SRCREV_machine ?= "5bdf36bd73803640ee495fc6f36b0207993bf62a"
 SRCREV_meta ?= "96ea2660bb97e15f48f4885b9e436f24c3606bd9"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index b1c991f55b..d5bf2c9496 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.10/standard/base"
 KBRANCH:qemux86-64 ?= "v5.10/standard/base"
 KBRANCH:qemumips64 ?= "v5.10/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "859babe91947ce09d70f8be4c8b314d9712a30ea"
-SRCREV_machine:qemuarm64 ?= "0a59ce2115693d52b931b0fc72f5699a22a77e81"
-SRCREV_machine:qemumips ?= "5bebdf68c5391f8a56f98a8cb31522c0627e05e0"
-SRCREV_machine:qemuppc ?= "0f4a4f1329c7331a02d36f7195f9414e40709d43"
-SRCREV_machine:qemuriscv64 ?= "a6e419710dedbe0390cbf30267c13752b9161972"
-SRCREV_machine:qemuriscv32 ?= "a6e419710dedbe0390cbf30267c13752b9161972"
-SRCREV_machine:qemux86 ?= "a6e419710dedbe0390cbf30267c13752b9161972"
-SRCREV_machine:qemux86-64 ?= "a6e419710dedbe0390cbf30267c13752b9161972"
-SRCREV_machine:qemumips64 ?= "03dc9bc06ba1b7d105467bea334e84b3666b67f4"
-SRCREV_machine ?= "a6e419710dedbe0390cbf30267c13752b9161972"
+SRCREV_machine:qemuarm ?= "8d513bf2294b60cbfa7bfbfab43f7ec458e88de0"
+SRCREV_machine:qemuarm64 ?= "f86e70ec0a39fa6cfd5b19a013703345cf9e8d4c"
+SRCREV_machine:qemumips ?= "a5c1977699a2733ed4ddd08f1bcc1cbcc1fa8862"
+SRCREV_machine:qemuppc ?= "2e52a4c55beaea77e6b99720de58624c416e7569"
+SRCREV_machine:qemuriscv64 ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
+SRCREV_machine:qemuriscv32 ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
+SRCREV_machine:qemux86 ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
+SRCREV_machine:qemux86-64 ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
+SRCREV_machine:qemumips64 ?= "37c7c3e8979a2b0eb75bf8ceab7f2b7f12565ceb"
+SRCREV_machine ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
 SRCREV_meta ?= "96ea2660bb97e15f48f4885b9e436f24c3606bd9"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \
-- 
2.19.1


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

[yocto] [PATCH 09/10] yocto-bsps/5.10: fix buildpaths issue with pnmtologo

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

2883e69e202d pnmtologo: use relocatable file name

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_5.10.bbappend| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index bfb36e173a..93466b70ed 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
-SRCREV_machine:genericx86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
-SRCREV_machine:edgerouter ?= "43a7a15cfe433584b6065c2492b2a7f9be7954c5"
-SRCREV_machine:beaglebone-yocto ?= "3651cd48f159c3b2a3a60d645baccc9d34baed54"
+SRCREV_machine:genericx86 ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
+SRCREV_machine:genericx86-64 ?= "2883e69e202dc7948c99a7828e192b2b42c2d90a"
+SRCREV_machine:edgerouter ?= "7c9332d91089ee63581be6cd3e7197c9d3e9a883"
+SRCREV_machine:beaglebone-yocto ?= "3c44f12b9de336579d00ac0105852f4cbf7e8b7d"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-- 
2.19.1


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

[yocto] [PATCH 07/10] linux-yocto/5.15: fix buildpaths issue with pnmtologo

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

a40d2daf2795 pnmtologo: use relocatable file name

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.15.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.15.bb|  2 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 20 +--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 0cac752eba..b6e443d4da 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "3a0e5a16b0c30008959538258553ca70f33ff2fc"
+SRCREV_machine ?= "0222cbb8d40318cf5377875017e32eebefa59ab8"
 SRCREV_meta ?= "0e3a81a5aefbea03388b1235fbcc3dec278425d0"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 3a35c1e44c..aadf014463 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -14,7 +14,7 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "e7447cb9afee4a22b0d3102922c3430eeb44bcc3"
+SRCREV_machine ?= "9b1d0e5eb8b08323577f5e2b21cbb2065aba0aa1"
 SRCREV_meta ?= "0e3a81a5aefbea03388b1235fbcc3dec278425d0"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 0b499b29ff..4c1d163a1e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "e12b73a556e5cbd2c5cb157aba0d84e2c3be1ddf"
-SRCREV_machine:qemuarm64 ?= "b1f3c7dddb39848a5b6bae9f6490927bf090de84"
-SRCREV_machine:qemumips ?= "aa4bd512de00a1054205069ac334d97f82564b1e"
-SRCREV_machine:qemuppc ?= "fcd84bc0d01c29fe94f736812ef58978c57d6836"
-SRCREV_machine:qemuriscv64 ?= "d81d20a55992c55475d7b5570589cd5884059147"
-SRCREV_machine:qemuriscv32 ?= "d81d20a55992c55475d7b5570589cd5884059147"
-SRCREV_machine:qemux86 ?= "d81d20a55992c55475d7b5570589cd5884059147"
-SRCREV_machine:qemux86-64 ?= "d81d20a55992c55475d7b5570589cd5884059147"
-SRCREV_machine:qemumips64 ?= "694134b0fceb27051d3b0cfccc7ba0649319aa7e"
-SRCREV_machine ?= "d81d20a55992c55475d7b5570589cd5884059147"
+SRCREV_machine:qemuarm ?= "c284142affccb534122ad93bdcd4774af161d767"
+SRCREV_machine:qemuarm64 ?= "c4c194a34c568c17389120608b2ee8a7a988150a"
+SRCREV_machine:qemumips ?= "7b446965d9659d312952ef4dedf5b50a493e60c2"
+SRCREV_machine:qemuppc ?= "0c2a4ad856c8f0c1b3ca8a38c17e1194f47e4643"
+SRCREV_machine:qemuriscv64 ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
+SRCREV_machine:qemuriscv32 ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
+SRCREV_machine:qemux86 ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
+SRCREV_machine:qemux86-64 ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
+SRCREV_machine:qemumips64 ?= "9a8d4e00df67daf224ae62b238c151a3f3f70ae7"
+SRCREV_machine ?= "a40d2daf2795d89e3ef8af0413b25190558831ec"
 SRCREV_meta ?= "0e3a81a5aefbea03388b1235fbcc3dec278425d0"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
-- 
2.19.1


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

[yocto] [PATCH 05/10] linux-yocto/5.15: update to v5.15.54

[Bruce Ashfield]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

843dae1756d9 Linux 5.15.54
c0c041a60cac selftests/net: fix section name when using xdp_dummy.o
a5fe76328ea5 dmaengine: idxd: force wq context cleanup on device disable 
path
568b2bd79b59 dmaengine: ti: Add missing put_device in 
ti_dra7_xbar_route_allocate
2f6ded79068c dmaengine: qcom: bam_dma: fix runtime PM underflow
cb9813d7eae9 dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
e08ccbaa5fb3 dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() 
correctly
c787908bee3f dmaengine: lgm: Fix an error handling path in 
intel_ldma_probe()
0bbb30d077f2 dmaengine: pl330: Fix lockdep warning about non-static key
8b07022de2d3 ida: don't use BUG_ON() for debugging
9839d89112d4 dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typo
e99bad0d76cf Revert "serial: 8250_mtk: Make sure to select the right 
FEATURE_SEL"
2fa22e7906c1 Revert "mm/memory-failure.c: fix race with changing page 
compound again"
c1c98764c3c3 misc: rtsx_usb: set return value in rsp_buf alloc err path
bab1a05a1141 misc: rtsx_usb: use separate command and response buffers
378080b7d8dd misc: rtsx_usb: fix use of dma mapped buffer for usb bulk 
transfer
d76704f8ccbb dmaengine: imx-sdma: Allow imx8m for imx7 FW revs
530ee8d3c6a4 i2c: cadence: Unregister the clk notifier in error path
941d77b795d1 r8169: fix accessing unset transport header
3abec0b38173 selftests: forwarding: fix error message in learning_test
1b74fe2e8f5c selftests: forwarding: fix learning_test when h1 supports 
IFF_UNICAST_FLT
8e5fcfecd99a selftests: forwarding: fix flood_unicast_test when h2 supports 
IFF_UNICAST_FLT
3fdca34e7811 ibmvnic: Properly dispose of all skbs during a failover.
5912e5e47ac9 ARM: dts: stm32: add missing usbh clock and fix clk order on 
stm32mp15
d5670adf5cff ARM: dts: stm32: use usbphyc ck_usbo_48m as USBH OHCI clock on 
stm32mp151
ddec6cbbe227 i40e: Fix VF's MAC Address change on VM
9d1e322a9103 i40e: Fix dropped jumbo frames statistics
d2bf1a6480e8 i2c: piix4: Fix a memory leak in the EFCH MMIO support
e7a1d5100921 xsk: Clear page contiguity bit when unmapping pool
a2b92fffd51b ARM: at91: fix soc detection for SAM9X60 SiPs
e3ee4ffa3c92 ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
f5b0e6d7b453 ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
a65b92628ae0 ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt
cfd0e717bd93 ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
9ec5fe55ba75 ARM: at91: pm: use proper compatible for sama5d2's rtc
ec5533b2ce26 arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
76292cf4b3bc pinctrl: sunxi: sunxi_pconf_set: use correct offset
c041165d8f04 arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc 
settings
44826474a39a arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad 
settings
ea8dbe870c84 arm64: dts: imx8mp-phyboard-pollux-rdk: correct uart pad 
settings
67a21eb8c48e arm64: dts: imx8mp-evk: correct I2C3 pad settings
b34da817e3fa arm64: dts: imx8mp-evk: correct I2C1 pad settings
37413a0ea090 arm64: dts: imx8mp-evk: correct eqos pad settings
ebad4d73ab1c arm64: dts: imx8mp-evk: correct vbus pad settings
f1571c8c8724 arm64: dts: imx8mp-evk: correct gpio-led pad settings
637b3dab51f7 arm64: dts: imx8mp-evk: correct the uart2 pinctl value
401d27fec614 arm64: dts: imx8mp-evk: correct mmc pad settings
ee1ced3dd863 ARM: mxs_defconfig: Enable the framebuffer
89a718d1d080 arm64: dts: qcom: sdm845: use dispcc AHB clock for mdss node
216094007699 arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
4157343a6a1a ASoC: codecs: rt700/rt711/rt711-sdca: resume bus/codec in 
.set_jack_detect
ac80a45ddb62 ASoC: rt711-sdca: Add endianness flag in 
snd_soc_component_driver
25e61636a5c3 ASoC: rt711: Add endianness flag in snd_soc_component_driver
29029ca6eed7 pinctrl: sunxi: a83t: Fix NAND function name for some pins
7208101ded1e ARM: meson: Fix refcount leak in meson_smp_prepare_cpus
9c26be2c3e69 tty: n_gsm: fix encoding of command/response bit
3b9f49138669 btrfs: fix use of uninitialized variable at rm device ioctl
cb91c0548ff2 virtio-blk: modify the value type of num in virtio_queue_rq()
d35b78cb053a btrfs: fix error pointer dereference in btrfs_ioctl_rm_dev_v2()
f88e79727fba Revert "serial: sc16is7xx: Clear RS485 bits in the shutdown"
83d3449e8ae5 xfs: remove incorrect ASSERT in xfs_rename
63a3d2377715 can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits
420b99306b7e can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency 
regression
baffaed7fab3 can: kvaser_usb: replace run-time checks with struct 
kvaser_usb_driver_info
188c798f3c25 net

[yocto] [PATCH 06/10] linux-yocto/5.10: update to v5.10.130

[Bruce Ashfield]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

26ae9c361414 Linux 5.10.130
8365b151fd50 dmaengine: ti: Add missing put_device in 
ti_dra7_xbar_route_allocate
37147e22cd8d dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
1be247db203e dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() 
correctly
7b721f5aec92 dmaengine: pl330: Fix lockdep warning about non-static key
e23cfb3fdcbb ida: don't use BUG_ON() for debugging
37995f034ff2 dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typo
ca4a91958466 misc: rtsx_usb: set return value in rsp_buf alloc err path
ff79e0ca2bea misc: rtsx_usb: use separate command and response buffers
af7d9d4abe84 misc: rtsx_usb: fix use of dma mapped buffer for usb bulk 
transfer
86884017bb63 dmaengine: imx-sdma: Allow imx8m for imx7 FW revs
9b329edd77ca i2c: cadence: Unregister the clk notifier in error path
26938bd28c0c r8169: fix accessing unset transport header
904f622ec78e selftests: forwarding: fix error message in learning_test
9906c223400f selftests: forwarding: fix learning_test when h1 supports 
IFF_UNICAST_FLT
859b889029fc selftests: forwarding: fix flood_unicast_test when h2 supports 
IFF_UNICAST_FLT
23cdc57d88d1 ibmvnic: Properly dispose of all skbs during a failover.
2b4659c145ba i40e: Fix dropped jumbo frames statistics
5561bddd0599 xsk: Clear page contiguity bit when unmapping pool
87d2bb888259 ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
9b7d8e28b686 ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
ade03e5ea778 ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
b40ac801cbb1 ARM: at91: pm: use proper compatible for sama5d2's rtc
4c3e73a66a27 arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
1d0c3ced2d1c pinctrl: sunxi: sunxi_pconf_set: use correct offset
e1cda2a03d81 arm64: dts: imx8mp-evk: correct I2C3 pad settings
2ade1b1d92f6 arm64: dts: imx8mp-evk: correct gpio-led pad settings
17b3883ba55f arm64: dts: imx8mp-evk: correct the uart2 pinctl value
43319ee6a075 arm64: dts: imx8mp-evk: correct mmc pad settings
6bf74a1e748f arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
2c0d10ce002a pinctrl: sunxi: a83t: Fix NAND function name for some pins
3d90607e7e6a ARM: meson: Fix refcount leak in meson_smp_prepare_cpus
e14930e9f9c6 xfs: remove incorrect ASSERT in xfs_rename
852952ea0e15 can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits
a741e762e199 can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency 
regression
f439d08ef1a2 can: kvaser_usb: replace run-time checks with struct 
kvaser_usb_driver_info
79af7be44ccb powerpc/powernv: delay rng platform device creation until 
later in boot
19104425c962 video: of_display_timing.h: include errno.h
96fa24eb1a38 memregion: Fix memregion_free() fallback definition
d6931bff1cc1 PM: runtime: Redefine pm_runtime_release_supplier()
cecb806c766c fbcon: Prevent that screen size is smaller than font size
b727561ddc93 fbcon: Disallow setting font bigger than screen size
b81212828ad1 fbmem: Check virtual screen sizes in fb_set_var()
d03e8ed72d7d fbdev: fbmem: Fix logo center image dx issue
963c80f070ed iommu/vt-d: Fix PCI bus rescan device hot add
0a5e36dbcb44 netfilter: nf_tables: stricter validation of element data
4a6430b99f67 netfilter: nft_set_pipapo: release elements in clone from 
abort path
4f59d12efe30 net: rose: fix UAF bug caused by rose_t0timer_expiry
0085da9df3dc usbnet: fix memory leak in error case
e917be1f83ea bpf: Fix insufficient bounds propagation from 
adjust_scalar_min_max_vals
9adec7334969 bpf: Fix incorrect verifier simulation around jmp32's jeq/jne
d0b8e2239988 can: gs_usb: gs_usb_open/close(): fix memory leak
b6f4b347a1fb can: grcan: grcan_probe(): remove extra of_node_get()
85cd41070df9 can: bcm: use call_rcu() instead of costly synchronize_rcu()
b75d4bec85b8 ALSA: hda/realtek: Add quirk for Clevo L140PU
6c32496964da mm/slub: add missing TID updates on slab deactivation
7208d1236f72 Linux 5.10.129
0e21ef18019c clocksource/drivers/ixp4xx: remove EXPORT_SYMBOL_GPL from 
ixp4xx_timer_setup()
7055e3446244 net: usb: qmi_wwan: add Telit 0x1070 composition
f1a53bb27f17 net: usb: qmi_wwan: add Telit 0x1060 composition
43c8d33ce353 xen/arm: Fix race in RB-tree based P2M accounting
547b7c640df5 xen-netfront: restore __skb_queue_tail() positioning in 
xennet_get_responses()
cbbd2d253153 xen/blkfront: force data bouncing when backend is untrusted
4923217af574 xen/netfront: force data bouncing when backend is untrusted
728d68bfe68d xen/netfront: fix leaking data in shared pages
cfea428030be xen/blkfront: fix leaking data in shared pages
d341e5a75480 selftests/rseq: Change type of rseq_offset to ptrdiff_t
7e617278bf3a

[yocto] [PATCH 03/10] yocto-bsps/5.10: fix buildpaths issue with gen-mach-types

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

80f5207b5abd tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_5.10.bbappend| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 975d6c6565..bfb36e173a 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:genericx86-64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:edgerouter ?= "58eb61187e8c78dc0241b2b85cb7d2c958f0e1fd"
-SRCREV_machine:beaglebone-yocto ?= "aab4d3436476d643c68ac2efccb887a4386a35bb"
+SRCREV_machine:genericx86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:genericx86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:edgerouter ?= "43a7a15cfe433584b6065c2492b2a7f9be7954c5"
+SRCREV_machine:beaglebone-yocto ?= "3651cd48f159c3b2a3a60d645baccc9d34baed54"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-- 
2.19.1


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

[yocto] [PATCH 04/10] yocto-bsps/5.15: fix buildpaths issue with gen-mach-types

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

6c085baf1838 tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_5.15.bbappend| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
index 11e78e2be2..8d2ec873fa 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:genericx86-64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:edgerouter ?= "26de0a7a59c56b63833a55dc33dbf70a7984d140"
-SRCREV_machine:beaglebone-yocto ?= "3ec00e9ee0e41e4c402396425337c42da58c4d6f"
+SRCREV_machine:genericx86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:genericx86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:edgerouter ?= "e90573857c176458965737d77b1747be83fe7edc"
+SRCREV_machine:beaglebone-yocto ?= "d91bb88e58c575e7c3b9fb111b6711a206eba64b"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-- 
2.19.1


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

[yocto] [PATCH 02/10] linux-yocto/5.15: fix buildpaths issue with gen-mach-types

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

6c085baf1838 tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.15.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.15.bb|  2 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 20 +--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 61b1df04a9..f1f5de3b18 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "4132e425a2dee778212b42d99a9812fe1c78a03d"
+SRCREV_machine ?= "3a7da2af1ba40b8c2247bac03a1fae488a1abde2"
 SRCREV_meta ?= "f122fe59e74365eba84bae800898ffd7329c628d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 7c81b048dc..e271c6741a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -14,7 +14,7 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "b2dcc4f70362059ef107000f9be5c76c2886911c"
+SRCREV_machine ?= "122de5742628e6b4303f0bbc653d409ff9f93557"
 SRCREV_meta ?= "f122fe59e74365eba84bae800898ffd7329c628d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 3e22f8d570..1c090db7b8 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "3d2ffe77f277a0a650e7d012c5bfe3765a467e4b"
-SRCREV_machine:qemuarm64 ?= "1da6524b1508ca6e9b6602471b478d310bec1960"
-SRCREV_machine:qemumips ?= "4101fd448319edc00fec2bd822be407d19205bb9"
-SRCREV_machine:qemuppc ?= "651a0112fb207bae1be0d2609e9a910135fb4feb"
-SRCREV_machine:qemuriscv64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemuriscv32 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemux86 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemux86-64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemumips64 ?= "d518b9a80c938ca7ce11e56d2275c33b89dfc9c3"
-SRCREV_machine ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
+SRCREV_machine:qemuarm ?= "41652fad285637467681f47d4e94a886ffb473cd"
+SRCREV_machine:qemuarm64 ?= "b28bd930f849c23a8f1576b22a8e59a0b2ac8cc1"
+SRCREV_machine:qemumips ?= "fb51b7d8d905883f2595f006428c142975231886"
+SRCREV_machine:qemuppc ?= "731587ce51ec087bfbb6255a1e9c763b4f71f7cb"
+SRCREV_machine:qemuriscv64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemuriscv32 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemux86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemux86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemumips64 ?= "5fcf0d1536623c9ede2ee54d143a650c59ca9d59"
+SRCREV_machine ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
 SRCREV_meta ?= "f122fe59e74365eba84bae800898ffd7329c628d"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
-- 
2.19.1


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

[yocto] [PATCH 01/10] linux-yocto/5.10: fix buildpaths issue with gen-mach-types

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

80f5207b5abd tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.10.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.10.bb|  4 ++--
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 20 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index a695740976..c705b7c07a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "f481ff6adf4be55c3ab89d0cf7243bbca69205c9"
+SRCREV_machine ?= "2f72685aa16ee5e1c8c53df03457b223a6996540"
 SRCREV_meta ?= "2f79722c50ad61cf055b40e8ba6d6f48e8dc6db0"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index 41cad3d37e..6336ef544f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "cab1bb0e702f93b16762fc560d6be582fbf86a6a"
-SRCREV_machine ?= "5239dc7bbd53a3d4d5e31f8631612c2eb6cee0b8"
+SRCREV_machine:qemuarm ?= "3b951d9995d83be4e2985d6aa904d59cb9ac7692"
+SRCREV_machine ?= "f2b78db2b548501a7b0b17f76b9ee2f09978fb30"
 SRCREV_meta ?= "2f79722c50ad61cf055b40e8ba6d6f48e8dc6db0"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index fbee1874f4..96c77e6a87 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.10/standard/base"
 KBRANCH:qemux86-64 ?= "v5.10/standard/base"
 KBRANCH:qemumips64 ?= "v5.10/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "952586297dec710cba21ccf7f6fe4a1aadde0a5d"
-SRCREV_machine:qemuarm64 ?= "268aa738ea2454a1293dcb6c829c88552a5768d2"
-SRCREV_machine:qemumips ?= "bb9cabbe92165b556329cb0eed12ab67d2dee7a7"
-SRCREV_machine:qemuppc ?= "88ee9e4c24d32b6d0ec90756f0c7729954d3feae"
-SRCREV_machine:qemuriscv64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemuriscv32 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemux86 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemux86-64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemumips64 ?= "1a760ff71146a87cb5b7de87aed88db07a907ef1"
-SRCREV_machine ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
+SRCREV_machine:qemuarm ?= "8b54878acc1161bdcfa3a1153cb2fff39c675b89"
+SRCREV_machine:qemuarm64 ?= "2db48159fdcfa0c0dab5804769ea528bb6ed"
+SRCREV_machine:qemumips ?= "fc5fb9c35b8c52a3b1b2348a56237b6f1bb7fc6b"
+SRCREV_machine:qemuppc ?= "736b1667a61f21d7a1b8c88e8cedb648e79e687b"
+SRCREV_machine:qemuriscv64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemuriscv32 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemux86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemux86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemumips64 ?= "2105a97021e3d0c565d84947e5cd45dd77be07e3"
+SRCREV_machine ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
 SRCREV_meta ?= "2f79722c50ad61cf055b40e8ba6d6f48e8dc6db0"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \
-- 
2.19.1


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

[yocto] [PATCH 00/10] linux-yocto: consolidated pull request

[Bruce Ashfield]

From: Bruce Ashfield 

Richard,

The gen-mach-types patches are repeats of ones I sent before, but I've
included them to make the ordering clear.

After that, we have two -stable updates (getting ready for the "big"
CVE updates)

And then the pnmtologo fixes. That should be all the builpaths warnings.

I'm sending this all to oe-core fo simplicty sake, but obviously the
yocto-bsp ones are for the yocto layers.

Brue

The following changes since commit e65ee81d621e679107b5f4ef2dbbb8d1786e93ad:

  ltp: fix builds when host ld doesn't know about target ELF formats 
(2022-07-14 10:08:57 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (10):
  linux-yocto/5.10: fix buildpaths issue with gen-mach-types
  linux-yocto/5.15: fix buildpaths issue with gen-mach-types
  yocto-bsps/5.10: fix buildpaths issue with gen-mach-types
  yocto-bsps/5.15: fix buildpaths issue with gen-mach-types
  linux-yocto/5.15: update to v5.15.54
  linux-yocto/5.10: update to v5.10.130
  linux-yocto/5.15: fix buildpaths issue with pnmtologo
  linux-yocto/5.10: fix buildpaths issue with pnmtologo
  yocto-bsps/5.10: fix buildpaths issue with pnmtologo
  yocto-bsps/5.15: fix buildpaths issue with pnmtologo

 .../linux/linux-yocto_5.10.bbappend   |  8 +++---
 .../linux/linux-yocto_5.15.bbappend   |  8 +++---
 .../linux/linux-yocto-rt_5.10.bb  |  6 ++---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.10.bb|  8 +++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 -
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 8 files changed, 46 insertions(+), 46 deletions(-)

-- 
2.19.1


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

Re: [yocto] [PATCH] yocto-bsps: update to v5.15.52 and buildpaths fixes

[Bruce Ashfield]

On Tue, Jul 12, 2022 at 11:19 PM Bruce Ashfield via
lists.yoctoproject.org
 wrote:
>
> On Tue, Jul 12, 2022 at 6:45 PM Richard Purdie
>  wrote:
> >
> > On Tue, 2022-07-12 at 10:40 -0400, bruce.ashfi...@gmail.com wrote:
> > > From: Bruce Ashfield 
> > >
> > > Updating linux-yocto/5.15 to the latest korg -stable release that 
> > > comprises
> > > the following commits:
> >
> > Thanks, this test build showed two warnings. I have no idea why this
> > only showed up now:
> >
> > beaglebone:
> > WARNING: linux-yocto-5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0 
> > do_package_qa: QA Issue: File 
> > /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h
> >  in package linux-yocto-src contains reference to TMPDIR
> >
> > beaglebond-alt:
> > WARNING: linux-yocto-5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0 
> > do_package_qa: QA Issue: File 
> > /usr/src/debug/linux-yocto/5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h
> >  in package linux-yocto-src contains reference to TMPDIR
> >
>
> Yet another generation script referencing itself .. they seem to like
> doing that.
>
> I don't get the warning, but I do have the file with the reference in
> it here, so I'll send a SRCREV bump with a fix Wednesday.

As you can see, patches are on the list. This one was an awk fix.

So now we have: shell, python, perl and awk to fix the full path
issues ... what's the next scripting language to hack ?

Bruce

>
> Bruce
>
> > So at least it is down to one error in 5.10 and 5.15 for the same
> > platform!
> >
> > I think we're mostly winning and nearly there :)
> >
> > Cheers,
> >
> > Richard
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


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

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

[yocto] [PATCH 2/2] yocto-bsps/5.15: fix buildpaths issue with gen-mach-types

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

6c085baf1838 tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_5.15.bbappend| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
index 11e78e2be2..8d2ec873fa 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:genericx86-64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:edgerouter ?= "26de0a7a59c56b63833a55dc33dbf70a7984d140"
-SRCREV_machine:beaglebone-yocto ?= "3ec00e9ee0e41e4c402396425337c42da58c4d6f"
+SRCREV_machine:genericx86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:genericx86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:edgerouter ?= "e90573857c176458965737d77b1747be83fe7edc"
+SRCREV_machine:beaglebone-yocto ?= "d91bb88e58c575e7c3b9fb111b6711a206eba64b"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-- 
2.19.1


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

[yocto] [PATCH 1/2] yocto-bsps/5.10: fix buildpaths issue with gen-mach-types

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

80f5207b5abd tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_5.10.bbappend| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 975d6c6565..bfb36e173a 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:genericx86-64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:edgerouter ?= "58eb61187e8c78dc0241b2b85cb7d2c958f0e1fd"
-SRCREV_machine:beaglebone-yocto ?= "aab4d3436476d643c68ac2efccb887a4386a35bb"
+SRCREV_machine:genericx86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:genericx86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:edgerouter ?= "43a7a15cfe433584b6065c2492b2a7f9be7954c5"
+SRCREV_machine:beaglebone-yocto ?= "3651cd48f159c3b2a3a60d645baccc9d34baed54"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-- 
2.19.1


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

Re: [yocto] [PATCH] yocto-bsps: update to v5.15.52 and buildpaths fixes

[Bruce Ashfield]

On Tue, Jul 12, 2022 at 6:45 PM Richard Purdie
 wrote:
>
> On Tue, 2022-07-12 at 10:40 -0400, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield 
> >
> > Updating linux-yocto/5.15 to the latest korg -stable release that comprises
> > the following commits:
>
> Thanks, this test build showed two warnings. I have no idea why this
> only showed up now:
>
> beaglebone:
> WARNING: linux-yocto-5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0 
> do_package_qa: QA Issue: File 
> /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h
>  in package linux-yocto-src contains reference to TMPDIR
>
> beaglebond-alt:
> WARNING: linux-yocto-5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0 
> do_package_qa: QA Issue: File 
> /usr/src/debug/linux-yocto/5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h
>  in package linux-yocto-src contains reference to TMPDIR
>

Yet another generation script referencing itself .. they seem to like
doing that.

I don't get the warning, but I do have the file with the reference in
it here, so I'll send a SRCREV bump with a fix Wednesday.

Bruce

> So at least it is down to one error in 5.10 and 5.15 for the same
> platform!
>
> I think we're mostly winning and nearly there :)
>
> Cheers,
>
> Richard



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

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

[yocto] [PATCH] yocto-bsps: update to v5.10.128 and buildpaths fixes

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:

ea86c1430c83 Linux 5.10.128
2d10984d99ac net: mscc: ocelot: allow unregistered IP multicast flooding
6a656280e775 powerpc/ftrace: Remove ftrace init tramp once kernel init is 
complete
6b734f7b7071 xfs: check sb_meta_uuid for dabuf buffer recovery
071e750ffb3d xfs: remove all COW fork extents when remounting readonly
1e76bd4c6722 xfs: Fix the free logic of state in xfs_attr_node_hasname
0cdccc05da76 xfs: punch out data fork delalloc blocks on COW writeback 
failure
db3f8110c3b0 xfs: use kmem_cache_free() for kmem_cache objects
09c9902cd80a bcache: memset on stack variables in bch_btree_check() and 
bch_sectors_dirty_init()
c4ff3ffe0138 tick/nohz: unexport __init-annotated tick_nohz_full_setup()
069fff50d400 drm: remove drm_fb_helper_modinit
52dc7f3f6fa1 MAINTAINERS: add Amir as xfs maintainer for 5.10.y
deb587b1a48d Linux 5.10.127
1cca46c20541 powerpc/pseries: wire up rng during setup_arch()
95d73d510b8a kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS 
(2nd attempt)
feb5ab798698 random: update comment from copy_to_user() -> copy_to_iter()
959bbaf5b7a9 modpost: fix section mismatch check for exported init/exit 
sections
c980392af147 ARM: cns3xxx: Fix refcount leak in cns3xxx_init
889aad2203e0 memory: samsung: exynos5422-dmc: Fix refcount leak in 
of_get_dram_timings
44a5b3a073e5 ARM: Fix refcount leak in axxia_boot_secondary
30bbfeb480ae soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in 
brcmstb_pm_probe
68f28d52e6cb ARM: exynos: Fix refcount leak in exynos_map_pmu
59fdf108144c ARM: dts: imx6qdl: correct PU regulator ramp delay
fb70bd86751a ARM: dts: imx7: Move hsic_phy power domain to HSIC PHY node
f78acc4288ed powerpc/powernv: wire up rng during setup_arch
7db1ba660b07 powerpc/rtas: Allow ibm,platform-dump RTAS call with null 
buffer address
1f5a9205a3be powerpc: Enable execve syscall exit tracepoint
ca144919afd4 parisc: Enable ARCH_HAS_STRICT_MODULE_RWX
a1c902349ad5 parisc/stifb: Fix fb_is_primary_device() only available with 
CONFIG_FB_STI
af0ff2da0152 xtensa: Fix refcount leak bug in time.c
6c0839cf1b9e xtensa: xtfpga: Fix refcount leak bug in setup
501652a2ad54 iio: adc: adi-axi-adc: Fix refcount leak in 
adi_axi_adc_attach_client
d40514d4403a iio: adc: axp288: Override TS pin bias current for some models
d579c893dd6c iio: adc: stm32: Fix IRQs on STM32F4 by removing custom 
spurious IRQs message
62284d45e26d iio: adc: stm32: Fix ADCs iteration in irq handler
e3ebb9d16ce1 iio: imu: inv_icm42600: Fix broken icm42600 (chip id 0 value)
3e0af68b99b8 iio: adc: stm32: fix maximum clock rate for stm32mp15x
b07a30a774b3 iio: trigger: sysfs: fix use-after-free on remove
399788e819a1 iio: gyro: mpu3050: Fix the error handling in 
mpu3050_power_up()
c1ec7d52a218 iio: accel: mma8452: ignore the return value of reset operation
42caf44906d6 iio:accel:mxc4005: rearrange iio trigger get and register
e26dcf627971 iio:accel:bma180: rearrange iio trigger get and register
f26379e19958 iio:chemical:ccs811: rearrange iio trigger get and register
4b6cdcff7cb8 f2fs: attach inline_data after setting compression
2d7bdb6a5a37 usb: chipidea: udc: check request status before setting device 
address
656eca37aae1 USB: gadget: Fix double-free bug in raw_gadget driver
54604108be64 usb: gadget: Fix non-unique driver names in raw-gadget driver
d87dec22fdf5 xhci-pci: Allow host runtime PM as default for Intel Meteor 
Lake xHCI
114080d04ae4 xhci-pci: Allow host runtime PM as default for Intel Raptor 
Lake xHCI
b8142a84657e xhci: turn off port power in shutdown
116c3e81b053 usb: typec: wcove: Drop wrong dependency to INTEL_SOC_PMIC
a547662534ca iio: adc: vf610: fix conversion mode sysfs node name
58c3a27e9c23 iio: mma8452: fix probe fail when device tree compatible is 
used.
5ee016f6120a s390/cpumf: Handle events cycles and instructions identical
abe487a88a5d gpio: winbond: Fix error code in winbond_gpio_get()
30531e0d7b5d nvme: move the Samsung X5 quirk entry to the core quirks
169f7d770552 nvme-pci: add NO APST quirk for Kioxia device
938f594266a6 nvme-pci: allocate nvme_command within driver pdu
ba388d4e9a68 nvme: don't check nvme_req flags for new req
e7ccaa1abacf nvme: mark nvme_setup_passsthru() inline
3ee62a1f0701 nvme: split nvme_alloc_request()
fe06c692cd7e nvme: centralize setting the timeout in nvme_alloc_request
afbc954e7896 Revert "net/tls: fix tls_sk_proto_close executed repeatedly"
340fbdc8011f virtio_net: fix xdp_rxq_info bug after suspend/resume
3bccf82169c5 igb: Make DMA faster when CPU is active on the PCIe link
7d7450363fdf regmap-irq: Fix a bug in regmap_irq_enable() for type_in_mask 
chips
40b3815

[yocto] [PATCH] yocto-bsps: update to v5.15.52 and buildpaths fixes

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

545aecd22961 Linux 5.15.52
ea512d540a55 io_uring: fix not locked access to fixed buf table
5696f7983d5d net: mscc: ocelot: allow unregistered IP multicast flooding to 
CPU
810962c79417 rtw88: rtw8821c: enable rfe 6 devices
d52f1c588824 rtw88: 8821c: support RFE type4 wifi NIC
e8d4878dcd00 fs: account for group membership
dc85bc24fbf1 fs: fix acl translation
38753e9173a5 fs: support mapped mounts of mapped filesystems
968e66f8ff70 fs: add i_user_ns() helper
21c6c720be75 fs: port higher-level mapping helpers
7d0536a8fab7 fs: remove unused low-level mapping helpers
f895d0ff47be fs: use low-level mapping helpers
1c62e0186d94 docs: update mapping documentation
b20dcf603b8d fs: account for filesystem mappings
3374eb1b0afc fs: tweak fsuidgid_has_mapping()
7bc23abcb414 fs: move mapping helpers
b3679e8b5996 fs: add is_idmapped_mnt() helper
ab0b6dc5e16b powerpc/ftrace: Remove ftrace init tramp once kernel init is 
complete
ce6bfe55237e xfs: only bother with sync_filesystem during readonly remount
3465b167831e xfs: prevent UAF in xfs_log_item_in_current_chkpt
4f0c91ab4c7d xfs: check sb_meta_uuid for dabuf buffer recovery
c4f376ba8be8 xfs: remove all COW fork extents when remounting readonly
40de647b2bab xfs: Fix the free logic of state in xfs_attr_node_hasname
0e84e17c16a3 xfs: punch out data fork delalloc blocks on COW writeback 
failure
71a218ca4fde xfs: use kmem_cache_free() for kmem_cache objects
1cdcd496b7ca bcache: memset on stack variables in bch_btree_check() and 
bch_sectors_dirty_init()
edbaf6e5e93a x86, kvm: use proper ASM macros for kvm_vcpu_is_preempted
f4a80ec8c51d tick/nohz: unexport __init-annotated tick_nohz_full_setup()
37238449af78 Linux 5.15.51
7fc188a9a9cc powerpc/pseries: wire up rng during setup_arch()
17aa69b458fd kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS 
(2nd attempt)
cced9ce619ef dma-direct: use the correct size for dma_set_encrypted()
a8bbb4c26460 perf build-id: Fix caching files with a wrong build ID
46a78d141335 random: update comment from copy_to_user() -> copy_to_iter()
7a3a4683562e ARM: dts: bcm2711-rpi-400: Fix GPIO line names
bcf2087ce4de modpost: fix section mismatch check for exported init/exit 
sections
da3ee7cd2f15 ARM: cns3xxx: Fix refcount leak in cns3xxx_init
cde4480b5ab0 memory: samsung: exynos5422-dmc: Fix refcount leak in 
of_get_dram_timings
4d9c60e868f7 ARM: Fix refcount leak in axxia_boot_secondary
10ba9d499a9f soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in 
brcmstb_pm_probe
d23f76018e17 ARM: exynos: Fix refcount leak in exynos_map_pmu
5e00d3d4023c arm64: dts: ti: k3-am64-main: Remove support for HS400 speed 
mode
4b5047643466 ARM: dts: imx6qdl: correct PU regulator ramp delay
c845b98be950 ARM: dts: imx7: Move hsic_phy power domain to HSIC PHY node
93f7d2a7fcf3 drm/msm/dp: Always clear mask bits to disable interrupts at 
dp_ctrl_reset_irq_ctrl()
1ad385647bf3 powerpc/powernv: wire up rng during setup_arch
c1cfae46c5dc powerpc/rtas: Allow ibm,platform-dump RTAS call with null 
buffer address
fe643b5afde6 powerpc: Enable execve syscall exit tracepoint
416d16b7dc0b powerpc/microwatt: wire up rng during setup_arch()
6b28ca2cf344 parisc: Enable ARCH_HAS_STRICT_MODULE_RWX
cb4d52085c8b parisc/stifb: Fix fb_is_primary_device() only available with 
CONFIG_FB_STI
0dcc1dd8a5dd xtensa: Fix refcount leak bug in time.c
016245172317 xtensa: xtfpga: Fix refcount leak bug in setup
711591bf1dab iio: adc: ti-ads131e08: add missing fwnode_handle_put() in 
ads131e08_alloc_channels()
ab7bf025cee8 iio: adc: adi-axi-adc: Fix refcount leak in 
adi_axi_adc_attach_client
4358bf6b1aad iio: adc: rzg2l_adc: add missing fwnode_handle_put() in 
rzg2l_adc_parse_properties()
bb6f853289fe iio: adc: axp288: Override TS pin bias current for some models
4f89730288ee iio: adc: stm32: Fix IRQs on STM32F4 by removing custom 
spurious IRQs message
d361b3cc1cf8 iio: adc: stm32: Fix ADCs iteration in irq handler
148bab179f04 iio: afe: rescale: Fix boolean logic bug
80e80577043f iio: imu: inv_icm42600: Fix broken icm42600 (chip id 0 value)
2a2d448a74ab iio: adc: stm32: fix maximum clock rate for stm32mp15x
4687c3f95524 iio: trigger: sysfs: fix use-after-free on remove
f359c4751de1 iio: gyro: mpu3050: Fix the error handling in 
mpu3050_power_up()
005cb02224a9 iio: accel: mma8452: ignore the return value of reset operation
cb0d87f2519d iio:accel:mxc4005: rearrange iio trigger get and register
3357fb9da21a iio:accel:bma180: rearrange iio trigger get and register
240fb3913f18 iio:accel:kxcjk-1013: rearrange iio trigger get and register
a1356318042e iio:chemical:ccs811: rearrange iio trigger get 

[yocto] [PATCH] yocto-bsps: update to v5.10.113

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:

54af9dd2b958 Linux 5.10.113
7992fdb045fb Revert "net: micrel: fix KS8851_MLL Kconfig"
8bedbc8f7f35 block/compat_ioctl: fix range check in BLKGETSIZE
fea24b07edfc staging: ion: Prevent incorrect reference counting behavour
dccee748af17 spi: atmel-quadspi: Fix the buswidth adjustment between 
spi-mem and controller
572761645b88 jbd2: fix a potential race while discarding reserved buffers 
after an abort
50aac4427360 can: isotp: stop timeout monitoring when no first frame was 
sent
e1e96e372721 ext4: force overhead calculation if the s_overhead_cluster 
makes no sense
4789149b9ea2 ext4: fix overhead calculation to account for the reserved gdt 
blocks
0c54b093766b ext4, doc: fix incorrect h_reserved size
22c450d39f89 ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
75ac724684b7 ext4: fix use-after-free in ext4_search_dir
a46b3d849864 ext4: fix symlink file size not match to file content
f6038d43b25b ext4: fix fallocate to use file_modified to update permissions 
consistently
19590bbc691d perf report: Set PERF_SAMPLE_DATA_SRC bit for Arm SPE event
e012f9d1af54 powerpc/perf: Fix power9 event alternatives
0a2cef65b329 drm/vc4: Use pm_runtime_resume_and_get to fix 
pm_runtime_get_sync() usage
f8f8b3124b89 KVM: PPC: Fix TCE handling for VFIO
405d98427416 drm/panel/raspberrypi-touchscreen: Initialise the bridge in 
prepare
231381f52116 drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not 
initialised
51d9cbbb0f5a perf/core: Fix perf_mmap fail when CONFIG_PERF_USE_VMALLOC 
enabled
88fcfd6ee6c5 sched/pelt: Fix attach_entity_load_avg() corner case
c55327bc3712 arm_pmu: Validate single/group leader events
5580b974a84b ARC: entry: fix syscall_trace_exit argument
7082650eb826 e1000e: Fix possible overflow in LTR decoding
43a2a3734aa3 ASoC: soc-dapm: fix two incorrect uses of list iterator
54e6180c8c2d gpio: Request interrupts after IRQ is initialized
0837ff17d052 openvswitch: fix OOB access in reserve_sfa_size()
19f6dcb1f0f0 xtensa: fix a7 clobbering in coprocessor context load/store
f399ab11dd6c xtensa: patch_text: Fixup last cpu should be master
ba2716da2336 net: atlantic: invert deep par in pm functions, preventing 
null derefs
358a3846f6a9 dma: at_xdmac: fix a missing check on list iterator
cf23a960c5c6 ata: pata_marvell: Check the 'bmdma_addr' beforing reading
9ca66d791439 mm/mmu_notifier.c: fix race in mmu_interval_notifier_remove()
ed5d4efb4df1 oom_kill.c: futex: delay the OOM reaper to allow time for 
proper futex cleanup
6b932920b96f mm, hugetlb: allow for "high" userspace addresses
50cbc583fa83 EDAC/synopsys: Read the error count from the correct register
7ec6e06ee405 nvme-pci: disable namespace identifiers for Qemu controllers
316bd86c2261 nvme: add a quirk to disable namespace identifiers
76101c8e0c31 stat: fix inconsistency between struct stat and struct 
compat_stat
bf28bba30410 scsi: qedi: Fix failed disconnect handling
a284cca3d81a net: macb: Restart tx only if queue pointer is lagging
9581e07b549b drm/msm/mdp5: check the return of kzalloc()
8d71edabb0ab dpaa_eth: Fix missing of_node_put in dpaa_get_ts_info()
b3afe5a7fd75 brcmfmac: sdio: Fix undefined behavior due to shift 
overflowing the constant
202748f44148 mt76: Fix undefined behavior due to shift overflowing the 
constant
0de9c104d04a net: atlantic: Avoid out-of-bounds indexing
5bef9fc38ffa cifs: Check the IOCB_DIRECT flag, not O_DIRECT
e129c55153c8 vxlan: fix error return code in vxlan_fdb_append
8e7ea1136475 arm64: dts: imx: Fix imx8*-var-som touchscreen property sizes
cd227ac03f2a ALSA: usb-audio: Fix undefined behavior due to shift 
overflowing the constant
490815f0b50e platform/x86: samsung-laptop: Fix an unsigned comparison which 
can never be negative
cb17b56a9b4d reset: tegra-bpmp: Restore Handle errors in BPMP response
d513ea9b7ef8 ARM: vexpress/spc: Avoid negative array index when !SMP
052e4a661f90 arm64: mm: fix p?d_leaf()
18ff7a2efa4e arm64/mm: Remove [PUD|PMD]_TABLE_BIT from [pud|pmd]_bad()
3bf8ca350170 selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted 
packets
520aab8b723c dmaengine: idxd: add RO check for wq max_transfer_size write
9a3c026dc3a5 dmaengine: idxd: add RO check for wq max_batch_size write
f593f49fcd17 net: stmmac: Use readl_poll_timeout_atomic() in atomic state
3d55b195747c netlink: reset network and mac headers in netlink_dump()
49516e6ed914 ipv6: make ip6_rt_gc_expire an atomic_t
078d839f11ac l3mdev: l3mdev_master_upper_ifindex_by_index_rcu should be 
using netdev_master_upper_dev_get_rcu
0ac8f83d8f64 net/sched: cls_u32: fix possible leak in u32_init_knode()
93366275be72 i

Re: [yocto] [PATCH yocto-autobuilder2 v2] config.py: add meta-virtualization to a-full

[Bruce Ashfield]

On Fri, Apr 29, 2022 at 8:14 AM Ross Burton  wrote:
>
> The meta-virtualization builder is reliable and useful now, so add it to
> a-full.

Acked-by: Bruce Ashfield 

The meta-virtualization "team" will do my best to respond to breakages
in a timely manner :)

Bruce

>
> Signed-off-by: Ross Burton 
> ---
>  config.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/config.py b/config.py
> index 17ccd21..c1c8c7e 100644
> --- a/config.py
> +++ b/config.py
> @@ -10,7 +10,7 @@ buildertorepos = {
>  "a-quick": ["poky", "meta-intel", "oecore", "bitbake",
>  "meta-mingw", "meta-gplv2"],
>  "a-full": ["poky", "meta-intel", "oecore", "bitbake",
> -"meta-mingw", "meta-gplv2", "meta-arm", "meta-aws", 
> "meta-agl", "meta-openembedded"],
> +"meta-mingw", "meta-gplv2", "meta-arm", "meta-aws", 
> "meta-agl", "meta-openembedded", "meta-virtualization"],
>  "non-gpl3": ["poky", "meta-gplv2"],
>  "meta-mingw": ["poky", "meta-mingw"],
>  "qa-extras": ["poky", "meta-mingw"],
> @@ -88,7 +88,7 @@ trigger_builders_wait_full = trigger_builders_wait_shared + 
> [
>  "qemumips-alt", "edgerouter-alt", "qemuppc-alt", "qemux86-world-alt",
>  "oe-selftest-ubuntu", "oe-selftest-debian", "oe-selftest-fedora", 
> "oe-selftest-centos",
>  "qemux86-64-ptest", "qemux86-64-ltp", "qemuarm64-ptest", "qemuarm64-ltp",
> -"meta-intel", "meta-arm", "meta-aws", "meta-agl-core"
> +"meta-intel", "meta-arm", "meta-aws", "meta-agl-core", "meta-virt"
>  ]
>
>  trigger_builders_wait_quick_releases = {
> --
> 2.25.1
>
>
> 
>


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

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

Re: [yocto] How to force build system to use a working kernel defconfig?

[Bruce Ashfield]

On Thu, Apr 28, 2022 at 5:39 AM Jupiter  wrote:
>
> Hi Bruce,
>
> Thanks for your response.
>
> > You can't suppress the kernel's config step, it is always going to
> > run. You can't just copy over .config and have the kernel build.
>
> If the OE build kernel config step can be disabled to compile kernel
> using customer defconfig, that will make users life much easier to
> disable unwanted kernel drivers and features.

This has nothing to do with OE, that's what the kernel would do
no matter how you build it.

>
> The customer defconfig can be certainly generated from bitbake -c
> menuconfig, but honestly, the kernel configure selection is not easier
> to understand, we have to use defconfig to disable unwanted the
> configures and tested it, inadvertently disable some configures could
> cause kernel panic regardless if the OE build system config step is
> running or not.
>

There's a reason why kernel-yocto (and other frameworks) provide
things like configuration fragments, kernel types, etc, This is a well
explored topic. Check out my (and others) presentations about this
throughout the years of yocto summits, etc. They can all be found
online in various formats.

> I have searched the internet, it is not just me, there are many others
> who requested to run customer defconfig without OE build kernel config
> step.

It can already do that, just as I described in my previous response.
The defconfig is copied in, and then the kernel *will* run its configuration
process over it, not OE's, the kernel.

>
> Are you a contributor in the OE dev team? Are there any reasons why
> the OE dev team won't consider this feature?

See above,

Bruce

>
> Thank you very much.
>
> Kind regards,
>
> jupiter



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

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

Re: [yocto] How to force build system to use a working kernel defconfig?

[Bruce Ashfield]

On Tue, Apr 26, 2022 at 6:59 AM JH  wrote:
>
> Hi,
>
> I followed Yocto document 2.3.3 Changing the Configuration to set up a
> complete working Linux kernel defconfig in my kernel bbappend, I
> copied the defconfig to build/.config:
> do_compile:prepend () {
> install -m 0644 ${WORKDIR}/defconfig ${WORKDIR}/build/.config
> }
>
> I hope the build system can just use the defconfig in build/.config,
> but that did not work, the build system still ran Restart config... to
> compare the defconfig and to generate and overwrite build/.config. How
> can I suppress the build system not to run the "Restart config"
> process, just to run the compile process using the build/.config I
> copied to build/.config?

You can't suppress the kernel's config step, it is always going to
run. You can't just copy over .config and have the kernel build.

The behaviour of the configuration depends on the kernel recipe and
bbclasses in play. I can answer from the context of
linux-yocto/kernel-yocto.bbclass and the default kernel.bbclass.

If you have a file called "defconfig" in your SRC_URI, it will be
copied into the kernel's .config and then yes, the kernel
configuration step will be run. The kernel's config subsystem will
apply its logic, and what your final .config is .. may or may not be
exactly what that input defconfig.

If the defconfig is a full copy of a .config (which is what they used
to be), then you can use either allnoconfig as the mode, or all
defconfig as the mode .. it won't make much of a difference since most
settings are fully specified. But the kernel-yocto processing assumes
an older defconfig style, and will use allnoconfig when it sees a
'defconfig' and the mode isn't explicitly specified.

If the defconfig was created using savedefconfig or similar, then
you'd want to specify the mode as alldefconfig, since you need those
defaults to be used to get a functional .config created.

Bruce

>
> I tried to add KCONFIG_MODE = "alldefconfig" in my kernel bbappend,
> but it did not work either.
>
> Appreciate your advice.
>
> Thank you very much.
>
> Kind regards,
>
> JH
>
> 
>


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

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

Re: [yocto] Howto build packages for dependencies of an out of image recipe build.

[Bruce Ashfield]

On Wed, Mar 9, 2022 at 5:24 AM Daniel Squires  wrote:
>
> We have our image and it is working as we need.
> We have an apt repo setup and working so that we can install additional 
> packages within a deployment of the image.
> However when we manually bitbake additional packages (e.g bitbake 
> my-optional-recipe) which we want to make available within this apt 
> repository by default only the package for my-optional-recipe gets built, 
> although all the dependencies of my-optional-recipe get built, none of them 
> are packaged. how do we make sure all the dependencies have packages built?

Are the dependencies in the recipe as RDEPENDS ? If so, they will be
built and packaged. If they weren't, then image assembly and pretty
much any package feed would be non-functional.

Bruce

>
> Best Regards
>
> Dan
> 
>


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

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

Re: [yocto] bbappend conditional check for advanced metadata (yocto-kernel-cache)?

[Bruce Ashfield]

On Thu, Jan 20, 2022 at 6:20 AM Matthias Klein
 wrote:
>
> Hello,
>
>
>
> I would like to create a linux-%.bbappend file and add the following to it, 
> for example:
>
>
>
> KERNEL_FEATURES:append = " features/overlayfs/overlayfs.scc".
>
>
>
> Works also for all kernels which use the advanced metadata. Unfortunately it 
> leads to an error with a kernel which uses a defconfig.
>
> I would only enable the above line if the kernel uses the advanced metadata. 
> Is this possible?
>

Presumably, the kernel recipe you are using inherits kernel-yocto, and
that whatever recipe is using a defconfig isn't also putting the
kernel-cache into the SRC_URI ? (or that kernel_features append
wouldn't be an actual error). So we can run with that assumption.

One option is to allow dangling kernel features, and you'll get a
warning from a the missing feature
(KERNEL_DANGLING_FEATURES_WARN_ONLY). But of course, you'll get a
warning .. which may or may not be a bad thing :)

Another is to make that append conditional based on something you can
test. i.e. test for kernel-cache in the SRC_URI, and if present, do
the append. Or you could test for the defconfig in the SRC_URI and
don't do the append. There may be other options for this, but without
all the details of the recipes, I can't say for sure.

I have a few variations of that theme in meta-virtualization, since
there's a broad range of kernel types supported
(https://git.yoctoproject.org/meta-virtualization/tree/recipes-kernel/linux/linux-yocto_virtualization.inc).

Cheers,

Bruce


>
>
> Many greetings,
>
> Matthias
>
>
> 
>


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

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

[yocto] [PATCH 1/3] yocto-bsp: change default to 5.15

[Bruce Ashfield]

From: Bruce Ashfield 

5.14 has been removed from core, so we change our default version
to the 5.15 LTS kernel.

Signed-off-by: Bruce Ashfield 
---
 meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
 meta-yocto-bsp/conf/machine/edgerouter.conf   | 2 +-
 meta-yocto-bsp/conf/machine/include/genericx86-common.inc | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf 
b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index b3d960a8cd..a5cb16cd93 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -24,7 +24,7 @@ SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
 SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
 
 KERNEL_IMAGETYPE = "zImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf 
b/meta-yocto-bsp/conf/machine/edgerouter.conf
index 32be4b9c39..249864e9ce 100644
--- a/meta-yocto-bsp/conf/machine/edgerouter.conf
+++ b/meta-yocto-bsp/conf/machine/edgerouter.conf
@@ -11,7 +11,7 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
 KERNEL_IMAGE_STRIP_EXTRA_SECTIONS  = ".comment"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
 
 SERIAL_CONSOLES = "115200;ttyS0"
 USE_VT ?= "0"
diff --git a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc 
b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
index 4651b37e5d..8c5e5522bc 100644
--- a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
+++ b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
@@ -2,7 +2,7 @@ include conf/machine/include/x86/x86-base.inc
 require conf/machine/include/x86/qemuboot-x86.inc
 MACHINE_FEATURES += "wifi efi pcbios"
 
-PREFERRED_VERSION_linux-yocto ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "${XSERVER_X86_BASE} \
-- 
2.19.1


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

[yocto] [PATCH 3/3] poky: set default kernel to 5.15

[Bruce Ashfield]

From: Bruce Ashfield 

5.14 is no longer actively maintained, so we bump our default
to the 5.15 LTS.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 meta-poky/conf/distro/poky.conf  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf 
b/meta-poky/conf/distro/poky-tiny.conf
index 756c65a2f9..b6c4eeccd0 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -43,7 +43,7 @@ FULL_OPTIMIZATION="-Os -pipe ${DEBUG_FLAGS}"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "5.14%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "5.15%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index b92784fdc4..2dc3606ae5 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -19,8 +19,8 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "5.14%"
-PREFERRED_VERSION_linux-yocto-rt ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
+PREFERRED_VERSION_linux-yocto-rt ?= "5.15%"
 
 SDK_NAME = 
"${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.19.1


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

[yocto] [PATCH 2/3] yocto-bsp/5.14: drop recipes

[Bruce Ashfield]

From: Bruce Ashfield 

5.14 has been removed from core, so we drop our bbappend. 5.15
is now the default kernel version for the reference BSPs.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.14.bbappend   | 23 ---
 1 file changed, 23 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend
deleted file mode 100644
index af4a7392f0..00
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend
+++ /dev/null
@@ -1,23 +0,0 @@
-KBRANCH:genericx86  = "v5.14/standard/base"
-KBRANCH:genericx86-64  = "v5.14/standard/base"
-KBRANCH:edgerouter = "v5.14/standard/edgerouter"
-KBRANCH:beaglebone-yocto = "v5.14/standard/beaglebone"
-
-KMACHINE:genericx86 ?= "common-pc"
-KMACHINE:genericx86-64 ?= "common-pc-64"
-KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine:genericx86 ?= "9d5572038eacda2e2a86e3f743f35ec415319fb4"
-SRCREV_machine:genericx86-64 ?= "9d5572038eacda2e2a86e3f743f35ec415319fb4"
-SRCREV_machine:edgerouter ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
-SRCREV_machine:beaglebone-yocto ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
-
-COMPATIBLE_MACHINE:genericx86 = "genericx86"
-COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-
-LINUX_VERSION:genericx86 = "5.14.21"
-LINUX_VERSION:genericx86-64 = "5.14.21"
-LINUX_VERSION:edgerouter = "5.14.6"
-LINUX_VERSION:beaglebone-yocto = "5.14.6"
-- 
2.19.1


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

Re: [yocto] #golang Build tools required during go generate

[Bruce Ashfield]

I tweaked the recipe a bit (you should use SRCREV, versus a tag), etc,
and added some link flags to make things static.

This tends to be why I write my own do_compile for go applications, so
I can use the provided Makefiles when possible (although there were a
few bad things in the project Makefile .. so using the built in
go.bbclass works just as well).

The almost-no-testing recipe is here:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?h=easyjson&id=b64de1f188e6f675cadf02c77bc72b06ed728eeb

I did see segfaults with other combinations of flags, but I didn't go
back to isolate if all of my tweaks are required or not.

build [/home/bruc...9d7f52f-r0]> ./build/bin/easyjson
Usage of ./build/bin/easyjson:

Bruce


Bruce

On Sat, Nov 6, 2021 at 10:14 AM Sebastian Rühl  wrote:
>
> Sure here you go:
>
>
>
> ```
>
> SUMMARY = "easyjson"
>
> DESCRIPTION = "easy json command util"
>
> HOMEPAGE = "https://github.com/mailru/easyjson";
>
> LICENSE = "MIT"
>
> LIC_FILES_CHKSUM = 
> "file://src/${GO_IMPORT}/LICENSE;md5=819e81c2ec13e1bbc47dc5e90bb4d88b"
>
>
>
> RDEPENDS_${PN}-dev += "bash"
>
>
>
> SRC_URI = "git://${GO_IMPORT};nobranch=1;protocol=https"
>
> SRCREV = "v${PV}"
>
>
>
> GO_IMPORT = "github.com/mailru/easyjson"
>
> GO_WORKDIR ?= "${GO_IMPORT}/easyjson"
>
>
>
> GO_LINKSHARED = ""
>
> export CGO_ENABLED = "0"
>
>
>
> inherit go-mod
>
> BBCLASSEXTEND = "native"
>
> # Upstream class "forgot" this argument
>
> GOBUILDFLAGS:append = " -trimpath"
>
>
>
> INSANE_SKIP = "arch"
>
> ```
>
>
>
> Sebastian
>
>
>
> Von: Bruce Ashfield 
> Datum: Freitag, 5. November 2021 um 21:51
> An: Sebastian Rühl 
> Cc: Khem Raj , yocto@lists.yoctoproject.org 
> 
> Betreff: Re: [yocto] #golang Build tools required during go generate
>
> On Fri, Nov 5, 2021 at 3:18 PM Sebastian Rühl  wrote:
> >
> > Yep might be… For me that’s desirable as these a built-utils, it’s golang 
> > and I see no benefit in having them dynamically linked anyay. Any tips how 
> > to statically link these? As far as I understand the golang classes do 
> > dynamic linking by default. Btw. I’m using the backported 1.16 versions 
> > from hardknot but I don’t think that matters as our “main” application 
> > works just perfectly fine on the target hardware.
> >
> >
> >
> > I tried:
> >
> > GO_LINKSHARED = ""
> >
> > export CGO_ENABLED = "0"
>
> It varies based on the application, the ones I've dealt with, tend to
> have a -static flag.
>
> Of course, the flag may not be exposed, and in those scenarios, I
> patch the Makefile/build.
>
> If you have public repos, or a pointer to the source of the
> applications, I could have a look to see if there's anything I can
> specifically recommend.
>
> Bruce
>
> >
> >
> >
> > But it didn’t help ☹
> >
> >
> >
> > Sebastian
> >
> >
> >
> > Von: Bruce Ashfield 
> > Datum: Freitag, 5. November 2021 um 20:07
> > An: Sebastian Rühl 
> > Cc: Khem Raj , yocto@lists.yoctoproject.org 
> > 
> > Betreff: Re: [yocto] #golang Build tools required during go generate
> >
> > I'd bet it is a variant of this:
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14386
> >
> > Bruce
> >
> > On Fri, Nov 5, 2021 at 2:58 PM Sebastian Rühl  wrote:
> > >
> > > Here some outputs:
> > >
> > >
> > >
> > > Bitbake -c devshell target-recipe
> > >
> > > sh-4.4# easyjson
> > >
> > > Segmentation fault
> > >
> > > sh-4.4# strace easyjson
> > >
> > > execve("/workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson",
> > >  ["easyjson"], 0x7ffc7e88d530 /* 138 vars */) = 0
> > >
> > > brk(NULL)   = 0x556083886000
> > >
> > > arch_prctl(0x3001 /* ARCH_??? */, 0x7fffd54fcc80) = -1 EINVAL (Invalid 
> > > argument)
> > >
> > > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
> > > si_addr=0x556083a1d000} ---
> > >
> > > +++ killed by SIGSEGV +++
> > >
> > > Segmentation fault
> > >
> > > sh-4.4# file $(which easyjson)
> > >
> > > /workdir/build/tmp/work/aarch64-fslc-linux/datadog

Re: [yocto] #golang Build tools required during go generate

[Bruce Ashfield]

On Fri, Nov 5, 2021 at 3:18 PM Sebastian Rühl  wrote:
>
> Yep might be… For me that’s desirable as these a built-utils, it’s golang and 
> I see no benefit in having them dynamically linked anyay. Any tips how to 
> statically link these? As far as I understand the golang classes do dynamic 
> linking by default. Btw. I’m using the backported 1.16 versions from hardknot 
> but I don’t think that matters as our “main” application works just perfectly 
> fine on the target hardware.
>
>
>
> I tried:
>
> GO_LINKSHARED = ""
>
> export CGO_ENABLED = "0"

It varies based on the application, the ones I've dealt with, tend to
have a -static flag.

Of course, the flag may not be exposed, and in those scenarios, I
patch the Makefile/build.

If you have public repos, or a pointer to the source of the
applications, I could have a look to see if there's anything I can
specifically recommend.

Bruce

>
>
>
> But it didn’t help ☹
>
>
>
> Sebastian
>
>
>
> Von: Bruce Ashfield 
> Datum: Freitag, 5. November 2021 um 20:07
> An: Sebastian Rühl 
> Cc: Khem Raj , yocto@lists.yoctoproject.org 
> 
> Betreff: Re: [yocto] #golang Build tools required during go generate
>
> I'd bet it is a variant of this:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=14386
>
> Bruce
>
> On Fri, Nov 5, 2021 at 2:58 PM Sebastian Rühl  wrote:
> >
> > Here some outputs:
> >
> >
> >
> > Bitbake -c devshell target-recipe
> >
> > sh-4.4# easyjson
> >
> > Segmentation fault
> >
> > sh-4.4# strace easyjson
> >
> > execve("/workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson",
> >  ["easyjson"], 0x7ffc7e88d530 /* 138 vars */) = 0
> >
> > brk(NULL)   = 0x556083886000
> >
> > arch_prctl(0x3001 /* ARCH_??? */, 0x7fffd54fcc80) = -1 EINVAL (Invalid 
> > argument)
> >
> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x556083a1d000} 
> > ---
> >
> > +++ killed by SIGSEGV +++
> >
> > Segmentation fault
> >
> > sh-4.4# file $(which easyjson)
> >
> > /workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson:
> >  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
> > linked, interpreter 
> > /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2,
> >  stripped
> >
> > sh-4.4# gdb $(which easyjson)
> >
> > GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
> >
> > Copyright (C) 2018 Free Software Foundation, Inc.
> >
> > License GPLv3+: GNU GPL version 3 or later 
> > <http://gnu.org/licenses/gpl.html>
> >
> > This is free software: you are free to change and redistribute it.
> >
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> >
> > and "show warranty" for details.
> >
> > This GDB was configured as "x86_64-linux-gnu".
> >
> > Type "show configuration" for configuration details.
> >
> > For bug reporting instructions, please see:
> >
> > <http://www.gnu.org/software/gdb/bugs/>.
> >
> > Find the GDB manual and other documentation resources online at:
> >
> > <http://www.gnu.org/software/gdb/documentation/>.
> >
> > For help, type "help".
> >
> > Type "apropos word" to search for commands related to "word"...
> >
> > Reading symbols from 
> > /workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson...(no
> >  debugging symbols found)...done.
> >
> > (gdb) run
> >
> > Starting program: 
> > /workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson
> >
> > warning: Error disabling address space randomization: Operation not 
> > permitted
> >
> > BFD: warning: 
> > /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2:
> >  unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
> >
> > BFD: warning: 
> > /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2:
> >  unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
> >
> > BFD: warning: 
> > /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/.debug/ld-2.33.so: 
> > unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
> >
> > BFD: warning: 
> > /workdir/build/tmp/sysroots-unin

Re: [yocto] #golang Build tools required during go generate

[Bruce Ashfield]

I'd bet it is a variant of this:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14386

Bruce

On Fri, Nov 5, 2021 at 2:58 PM Sebastian Rühl  wrote:
>
> Here some outputs:
>
>
>
> Bitbake -c devshell target-recipe
>
> sh-4.4# easyjson
>
> Segmentation fault
>
> sh-4.4# strace easyjson
>
> execve("/workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson",
>  ["easyjson"], 0x7ffc7e88d530 /* 138 vars */) = 0
>
> brk(NULL)   = 0x556083886000
>
> arch_prctl(0x3001 /* ARCH_??? */, 0x7fffd54fcc80) = -1 EINVAL (Invalid 
> argument)
>
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x556083a1d000} 
> ---
>
> +++ killed by SIGSEGV +++
>
> Segmentation fault
>
> sh-4.4# file $(which easyjson)
>
> /workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson:
>  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
> interpreter 
> /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, 
> stripped
>
> sh-4.4# gdb $(which easyjson)
>
> GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
>
> Copyright (C) 2018 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later 
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "x86_64-linux-gnu".
>
> Type "show configuration" for configuration details.
>
> For bug reporting instructions, please see:
>
> .
>
> Find the GDB manual and other documentation resources online at:
>
> .
>
> For help, type "help".
>
> Type "apropos word" to search for commands related to "word"...
>
> Reading symbols from 
> /workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson...(no
>  debugging symbols found)...done.
>
> (gdb) run
>
> Starting program: 
> /workdir/build/tmp/work/aarch64-fslc-linux/datadog-agent/7.31.1-r0/recipe-sysroot-native/usr/bin/easyjson
>
> warning: Error disabling address space randomization: Operation not permitted
>
> BFD: warning: 
> /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2: 
> unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
>
> BFD: warning: 
> /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2: 
> unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
>
> BFD: warning: 
> /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/.debug/ld-2.33.so: 
> unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
>
> BFD: warning: 
> /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/.debug/ld-2.33.so: 
> unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
>
>
>
> Program received signal SIGSEGV, Segmentation fault.
>
> 0x7fcfd962c2fa in strcmp () from 
> /workdir/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>
> (gdb)
>
>
>
> Hope that helps….
>
>
>
> Small background: Yocto on dunfell, build with poky docker image
>
>
>
> Von: Khem Raj 
> Datum: Freitag, 5. November 2021 um 18:29
> An: Sebastian Rühl , yocto@lists.yoctoproject.org 
> 
> Betreff: Re: [yocto] #golang Build tools required during go generate
>
>
>
> On 11/5/21 7:32 AM, sebast...@mapped.com wrote:
> > Hi yoto-devs/users,
> >
> > in order to get a golang application to run which relies on `go
> > generate` calls I wrote special recipes for this tools and include them
> > in my original recipe. However I always get a segmentation fault.
> > In the tools (which happens to be based on golang too) I use [1] in the
> > recipes and in the recipe I want to use them I include them via [2].
> > However if for example enter the dev-shell or during build I get a
> > segmentation fault although the binary seems to be compiled for the
> > right architecture (host-amd64).
> > Is there something wrong I try to use that?
>
> do you have stack trace ? that might give some more info on whats going on
>
> >
> > Sebastian
> >
> > [1]
> > inherit go-mod
> > BBCLASSEXTEND = "native"
> > [2]
> > DEPENDS += "random-go-tool-needed-by-recipe-native"
> >
> >
> >
> >
>
>
> 
>


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

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

Re: [yocto] yocto preempt-rt

[Bruce Ashfield]

Correct.

The rt patches are already integrated on the branches that that recipe will
build out of the linux-yocto repository.

Bruce

On Tue, Nov 2, 2021 at 12:23 PM Monsees, Steven C (US) via
lists.yoctoproject.org 
wrote:

>
>
> Is it true that no patch work is required if out under
>
> …/poky/meta/recipes-kernel, there exists  a yocto-linux-rt_##.##.bb recipe
> that matches your kernel release?, and that it will build the full
> preemptive RT Kernel ?
>
>
>
> Thanks,
>
> Steve
>
>
>
> 
>
>

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

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

Re: [yocto] rebuilding perf fails after cleanall

[Bruce Ashfield]

On Fri, Oct 22, 2021 at 1:23 PM chuck kamas via lists.yoctoproject.org
 wrote:
>
> Hi all,
>
>
> I am trying to model a new recipe off of perf.bb to compile the usbip
> helper kernel code. I have been having issues with the
> work-shared/../kernel-source directory being empty, so I went back to
> the perf recipie and tried:
>
> bitbake perf -c cleanall
>
> bitbake perf
>

What release are you using ? We did have some issues with this in the
past, but they should all be accounted for now.

I can bitbake perf, bitbake -c cleanall perf; bitbake perf

perf makes a copy of the kernel-sharel tools directory (it didn't in
the past), so
it should be safe for any combinations like that.

Bruce

>
> I get the same error about path does not exist and the work-shared
> kernel-source directory being empty.
>
>
> Is perf.bb only executable in the context of a global rebuild?
>
>
> Chuck
>
>
>
>
>
> 
>


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

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

Re: [yocto] docker fragment missing conntrack and netfilter entries? #meta-virtualization

[Bruce Ashfield]

On Thu, Oct 14, 2021 at 12:23 PM  wrote:
>
> Hi,
>
> I have just completed a bringup of Poky on the ODROID N2+ platform, but 
> noticed that Docker failed to start, complaining that it could not load the 
> "nf_conntrack_netlink" module.
> After checking docker.cfg, I noticed that a few configuration options I 
> expected were missing.
>
> Shouldn't the following be added: (?)
>
> CONFIG_NETFILTER_NETLINK=m
> CONFIG_NT_CT_NETLINK=m
>
> CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

FYI: you want the meta-virtualization mailing list, not the main yocto
one for questions like this.

There's a balancing act with the fragments: they are as
non-overlapping as possible, they often support a wide range of kernel
versions and kernel providers, so there are sometimes more, or less
options than you'd expect in a fragment.

In particular the fragments in meta-virtualization are changing right
now, and are being unified in the kernel-cache repository (that allows
the duplicated options to be rationalized).

So depending on which docker.cfg you are looking at, you'd either send
a patch to the linux-yocto mailing list, or the meta-virtualization
list.

In particular, the netfilter fragment is what is expected to provide
many of the needed options, and that's what has been happening with
the out of box docker, lxc, podman, k8s, etc, configurations tested in
meta-virt. The docker.scc fragment will start pulling that in
automatically as part of the de-duplication effort I hinted at above.

But there's no harm in sending a patch, I'll figure out how/where it
applies as I go through those efforts.

Cheers,

Bruce






>
> Thanks,
> Ben
>
>
> 
>


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

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

Re: [yocto] building the kernel's usbipd daemon

[Bruce Ashfield]

On Tue, Oct 12, 2021 at 12:33 AM chuck kamas via
lists.yoctoproject.org 
wrote:
>
> Thanks for the quick reply. I looked at the perf recipe, and its quite 
> involved. Is there a simpler recipie to use as a template? Perhaps one of 
> these?
>

My intent was just to show how you'd get the source from whatever
kernel you are building,

> meta-openembedded/meta-oe/recipes-kernel/bpftool/bpftool.bb
>
> meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb
>
> meta-openembedded/meta-oe/recipes-kernel/cpupower/cpupower.bb
>
>
> all three of these appear to be basically the same very simple bb file.
>

Assuming that you don't need to patch the sources directly, any of
those would likely work ... depending on the dependencies and options
of what tool you are building.

Bruce

>
> Chuck
>
>
> On 10/11/21 5:46 PM, Bruce Ashfield wrote:
>
> On Mon, Oct 11, 2021 at 6:16 PM chuck kamas via lists.yoctoproject.org
>  wrote:
>
> Hi all,
>
>
> I've googled most of the day, but to no avail. How does one compile and
> add to the image the daemon usbipd? Is there a bitbake file already for
> this? The code is part of the kernel found in the kernel tree:
>
> KERNEL_SRC_PATH/tools/usb/usbip/src
>
> and is invoked from the KERNEL_SRC_PATH/tools directory by calling
>
> make usb
>
>
> from:
> https://wiki.st.com/stm32mpu/wiki/How_to_build_Linux_kernel_user_space_tools
>
> PC $> cd /tools
> PC $> make 
>
>
> I would think that there is a preexisting recipe.
>
> There isn't one that I've ever heard of, and the layerindex
> (http://layers.openembedded.org/) confirms that nothing registered
> with it provides that recipe.
>
> So if you need it, you'd have to create a recipe .. and submit it to
> somewhere like meta-openembedded if appropriate.
>
> Have a look at the perf recipe for one of the ways we build tools out
> of the kernel source. Something similar will work in this case.
>
> Bruce
>
> thanks,
>
> Chuck
>
>
>
>
>
>
>
>
>
>
> 
>


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

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

Re: [yocto] building the kernel's usbipd daemon

[Bruce Ashfield]

On Mon, Oct 11, 2021 at 6:16 PM chuck kamas via lists.yoctoproject.org
 wrote:
>
> Hi all,
>
>
> I've googled most of the day, but to no avail. How does one compile and
> add to the image the daemon usbipd? Is there a bitbake file already for
> this? The code is part of the kernel found in the kernel tree:
>
> KERNEL_SRC_PATH/tools/usb/usbip/src
>
> and is invoked from the KERNEL_SRC_PATH/tools directory by calling
>
> make usb
>
>
> from:
> https://wiki.st.com/stm32mpu/wiki/How_to_build_Linux_kernel_user_space_tools
>
> PC $> cd /tools
> PC $> make 
>
>
> I would think that there is a preexisting recipe.

There isn't one that I've ever heard of, and the layerindex
(http://layers.openembedded.org/) confirms that nothing registered
with it provides that recipe.

So if you need it, you'd have to create a recipe .. and submit it to
somewhere like meta-openembedded if appropriate.

Have a look at the perf recipe for one of the ways we build tools out
of the kernel source. Something similar will work in this case.

Bruce

>
> thanks,
>
> Chuck
>
>
>
> 
>


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

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

Re: [yocto] LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell

[Bruce Ashfield]

On Fri, Oct 8, 2021 at 11:52 AM  wrote:
>
> I have defined LINUX_VERSION_EXTENSION in my kernel recipe.
>
> I have no CONFIG_LOCALVERSION or CONFIG_LOCALVERSION_AUTO defined in my 
> defconfig
>
> After i run bitbake -c kernel_configme  I can see in my 
> .config file:
>
> CONFIG_LOCALVERSION=""
> # CONFIG_LOCALVERSION_AUTO is not set
>
> and at the very end:
>
> CONFIG_LOCALVERSION=""
> So far so good.
>
> Then I execute  bitbake -c configure 
> and the .config file is changed. Now there is:
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> and there is no trace of CONFIG_LOCALVERSION=""

Assuming what you are using as a kernel recipe is linux-yocto based,
the code that is adding the CONFIG_LOCALVERSION is a task that runs
after do_configure. So just running -c configure, it shouldn't be in
the .config (and the default kernel configure task, will copy your
defconfig -> .config, and then lets the kernel process it, so you will
have symbols in the .config that are not in your defconfig
explicitly).

If you can make your recipe available, I can probably offer more
specific comments.

Bruce

>
> Yocto: dunfell
> Kernel 5.4.70
>
>
>
>
>
>
>
> 
>


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

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

[yocto] [PATCH] yocto-bsp/5.13: drop recipes

[Bruce Ashfield]

From: Bruce Ashfield 

5.13 has been removed from core, and we've moved the default
support to 5.14, so we can drop our bbappend.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.13.bbappend   | 23 ---
 1 file changed, 23 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
deleted file mode 100644
index daf5fd2cd6..00
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
+++ /dev/null
@@ -1,23 +0,0 @@
-KBRANCH:genericx86  = "v5.13/standard/base"
-KBRANCH:genericx86-64  = "v5.13/standard/base"
-KBRANCH:edgerouter = "v5.13/standard/edgerouter"
-KBRANCH:beaglebone-yocto = "v5.13/standard/beaglebone"
-
-KMACHINE:genericx86 ?= "common-pc"
-KMACHINE:genericx86-64 ?= "common-pc-64"
-KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine:genericx86 ?= "7280c93f5599946db3add473eeb05b34c364938d"
-SRCREV_machine:genericx86-64 ?= "7280c93f5599946db3add473eeb05b34c364938d"
-SRCREV_machine:edgerouter ?= "a832a0390e96c4f014d7b2bf9f161ac9477140f7"
-SRCREV_machine:beaglebone-yocto ?= "dbdc921374c057a75b2df92302124994e241ca51"
-
-COMPATIBLE_MACHINE:genericx86 = "genericx86"
-COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-
-LINUX_VERSION:genericx86 = "5.13.15"
-LINUX_VERSION:genericx86-64 = "5.13.15"
-LINUX_VERSION:edgerouter = "5.13.15"
-LINUX_VERSION:beaglebone-yocto = "5.13.15"
-- 
2.19.1


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

[yocto] [PATCH 1/2] yocto-bsp/5.10: update to v5.10.63

[Bruce Ashfield]

From: Bruce Ashfield 

Updating the reference platforms to match the latest 5.10 -stable in
oe-core.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.10.bbappend  | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 1e14229c23..a7ef143dc9 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,17 +7,17 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "c274623910704eefcc98380a17649889ac7e9408"
-SRCREV_machine:genericx86-64 ?= "c274623910704eefcc98380a17649889ac7e9408"
-SRCREV_machine:edgerouter ?= "ac089d661362ba857e235c5630242039b150ae26"
-SRCREV_machine:beaglebone-yocto ?= "a6df693a45f5787d4254e0998f52b4465b2a5efe"
+SRCREV_machine:genericx86 ?= "164ed895bc1e94722e80fe6496b176f6bb815cd4"
+SRCREV_machine:genericx86-64 ?= "164ed895bc1e94722e80fe6496b176f6bb815cd4"
+SRCREV_machine:edgerouter ?= "4ab94e777d8b41ee1ee4c279259e9733bc8049b1"
+SRCREV_machine:beaglebone-yocto ?= "941cc9c3849f96f7eaf109b1e35e05ba366aca56"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
 COMPATIBLE_MACHINE:edgerouter = "edgerouter"
 COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-LINUX_VERSION:genericx86 = "5.10.55"
-LINUX_VERSION:genericx86-64 = "5.10.55"
-LINUX_VERSION:edgerouter = "5.10.55"
-LINUX_VERSION:beaglebone-yocto = "5.10.55"
+LINUX_VERSION:genericx86 = "5.10.63"
+LINUX_VERSION:genericx86-64 = "5.10.63"
+LINUX_VERSION:edgerouter = "5.10.63"
+LINUX_VERSION:beaglebone-yocto = "5.10.63"
-- 
2.19.1


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

[yocto] [PATCH 2/2] yocto-bsp/5.13: update to v5.13.15

[Bruce Ashfield]

From: Bruce Ashfield 

Updating the reference boards to match the oe-core kernel version.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.13.bbappend  | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
index 6089a94d75..daf5fd2cd6 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
@@ -7,17 +7,17 @@ KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:genericx86-64 ?= "common-pc-64"
 KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine:genericx86 ?= "fe64083abac67ac736aa0133f3a4088286aece40"
-SRCREV_machine:genericx86-64 ?= "fe64083abac67ac736aa0133f3a4088286aece40"
-SRCREV_machine:edgerouter ?= "7b80606f7484fb1967a261e7e262de9adeb7ed59"
-SRCREV_machine:beaglebone-yocto ?= "e486ea86794d62e7e6adbb3a2b2fd65222f323f7"
+SRCREV_machine:genericx86 ?= "7280c93f5599946db3add473eeb05b34c364938d"
+SRCREV_machine:genericx86-64 ?= "7280c93f5599946db3add473eeb05b34c364938d"
+SRCREV_machine:edgerouter ?= "a832a0390e96c4f014d7b2bf9f161ac9477140f7"
+SRCREV_machine:beaglebone-yocto ?= "dbdc921374c057a75b2df92302124994e241ca51"
 
 COMPATIBLE_MACHINE:genericx86 = "genericx86"
 COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
 COMPATIBLE_MACHINE:edgerouter = "edgerouter"
 COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-LINUX_VERSION:genericx86 = "5.13.11"
-LINUX_VERSION:genericx86-64 = "5.13.11"
-LINUX_VERSION:edgerouter = "5.13.11"
-LINUX_VERSION:beaglebone-yocto = "5.13.11"
+LINUX_VERSION:genericx86 = "5.13.15"
+LINUX_VERSION:genericx86-64 = "5.13.15"
+LINUX_VERSION:edgerouter = "5.13.15"
+LINUX_VERSION:beaglebone-yocto = "5.13.15"
-- 
2.19.1


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

Re: [yocto] Binary compliance validation

[Bruce Ashfield]

On Tue, Aug 31, 2021 at 11:48 AM Anatol Belski
 wrote:
>
> Hi,
>
> I'm writing to present an ABI compliance check mechanism for Poky
> recently developed to help improve the product stability. It is still
> an early work which however has already proven itself useful and thus
> the time seems right to ask for the community view.
>
> Binary compliance is an important metric, when a distrubition intends
> to provide stability guarantees to consumers outside the monolithic
> image build. For example, projects utilizing the SDK might not be in
> sync with the image builds from even the same branch. Even in stable
> branches where bugfixes, security patches or even non breaching
> upgrades have to flow in as necessary, there's is currently no
> verifiable mechainsm to ensure the binary compatibility long term.
>
> The currently implemented validation is based on libabigail and as such
> is focused on the ABI compliance. Libabigail is a tool developed by Red
> Hat and is in use for Fedora and RHEL RPM builds. Some companies are
> known to utilize libabigail to support the kernel maintanance (Linux
> kernel for Android). The meta layer contains a bbclass extending the
> buildhistory functionality with the ABI serialization and comparison.
> One buildhistory version taken as a baseline would serve the comparison
> with any follow up builds. The ABI changes detected are then reported.
>
> The handling routines in Poky are currently attached to the install
> task, which implies the baseline build needs to take place with the
> sstate disabled. The follow up buids can use sstate and in that case
> the postinstall routines will be invoked only if some change took place
> and thus do_install has been called.
>
> The implementation is made as a core Python module, which can be used
> in a Yocto layer or imported in any other script. The layer is
> available under:
> https://github.com/clio-project/meta-binaryaudit
>
> and the accompanying python module (which moves at some faster pace and
> is synchronized into the layer) and a command line tool:
> https://github.com/clio-project/python-binaryaudit
>
> The layer is yet an early work and the impluementation doesn't exhaust
> all the possible features of Poky and libabigail. However, it already
> proves itself helpful and is used for some real products to esure the
> ABI stability. Certainly the mechanisms and the integration can be
> improved.
>
> The future for this layer is open containing at least the topics below:
>
> - Binary size auditing.
> - Security auditing.
>
> As a shorter term serviceableness, the ABI compliance validation
> mechanism seems to be a useful tool in helping to keep promises on LTS,
> but would most likely also help maintaining non LTS branches. It would
> be great to receive any feedback, reviews and ideas in regard to meta-
> binaryaudit.

Out of curiosity, are you coordinating with the work sent in March by BMW ?

see the email with the subject: [yocto] Demo of abi checker hook with hashequiv

And the associated layers: https://github.com/bmwcarit/meta-abicompat
and https://github.com/bmwcarit/meta-abicompat-poky

Bruce

>
> Thanks!
>
> Anatol
>
>
> 
>


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

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

[yocto] [PATCH] parselogs.py: ignore intermittent CD/DVDROM identification failure

[Bruce Ashfield]

From: Bruce Ashfield 

We don't use the CD/DVD ROM drive in any of our tests, but it
periodically fails discovery and that leads to a QA error:

[6.403477] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)

The only way to disable the optical ROM drive in qemu is to use
the '-nodefaults' option, which disables the CDROM (among other things).
We can't be sure that none of our tests, or extended users are relying
on default devices, so using that option is more of a risk than adding
the message to our ignore list.

To date, no one has sent a patch to just disable the optical drive
(either in qemu or the BIOS), but that is something we could consider
in the future.

[YOCTO #14528]

Signed-off-by: Bruce Ashfield 
---
 meta/lib/oeqa/runtime/cases/parselogs.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py 
b/meta/lib/oeqa/runtime/cases/parselogs.py
index af8a8d67bd..5db0216597 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -98,6 +98,7 @@ ignore_errors = {
 'qemux86' : [
 'Failed to access perfctr msr (MSR',
 'pci :00:00.0: [Firmware Bug]: reg 0x..: invalid BAR (can\'t 
size)',
+'failed to IDENTIFY (I/O error, err_mask=0x4)',
 ] + qemux86_common,
 'qemux86-64' : qemux86_common,
 'qemumips' : [
-- 
2.19.1


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

[yocto] [PATCH 4/4] poky-alt: switch default kernel to 5.10

[Bruce Ashfield]

From: Bruce Ashfield 

5.4 has been dropped from oe-core release/development, so we switch
the alt-config to use 5.10.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/include/poky-distro-alt-test-config.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/include/poky-distro-alt-test-config.inc 
b/meta-poky/conf/distro/include/poky-distro-alt-test-config.inc
index 9c2d7753a1..0de2013826 100644
--- a/meta-poky/conf/distro/include/poky-distro-alt-test-config.inc
+++ b/meta-poky/conf/distro/include/poky-distro-alt-test-config.inc
@@ -2,7 +2,7 @@
 DISTRO_FEATURES:append = " pam"
 
 # Use the LTSI Kernel
-PREFERRED_VERSION_linux-yocto = "5.4%"
+PREFERRED_VERSION_linux-yocto = "5.10%"
 
 # Ensure the kernel nfs server is enabled
 KERNEL_FEATURES:append:pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
-- 
2.19.1


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

[yocto] [PATCH 3/4] yocto-bsp: drop 5.4 bbappend

[Bruce Ashfield]

From: Bruce Ashfield 

5.4 has been removed from oe-core, so we drop our associated
bbappend.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.4.bbappend| 23 ---
 1 file changed, 23 deletions(-)
 delete mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend
deleted file mode 100644
index 290aa323eb..00
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend
+++ /dev/null
@@ -1,23 +0,0 @@
-KBRANCH:genericx86  = "v5.4/standard/base"
-KBRANCH:genericx86-64  = "v5.4/standard/base"
-KBRANCH:edgerouter = "v5.4/standard/edgerouter"
-KBRANCH:beaglebone-yocto = "v5.4/standard/beaglebone"
-
-KMACHINE:genericx86 ?= "common-pc"
-KMACHINE:genericx86-64 ?= "common-pc-64"
-KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine:genericx86 ?= "31db2b47ac7d8508080fbb7344399b501216de66"
-SRCREV_machine:genericx86-64 ?= "31db2b47ac7d8508080fbb7344399b501216de66"
-SRCREV_machine:edgerouter ?= "706efec4c1e270ec5dda92275898cd465dfdc7dd"
-SRCREV_machine:beaglebone-yocto ?= "706efec4c1e270ec5dda92275898cd465dfdc7dd"
-
-COMPATIBLE_MACHINE:genericx86 = "genericx86"
-COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-
-LINUX_VERSION:genericx86 = "5.4.94"
-LINUX_VERSION:genericx86-64 = "5.4.94"
-LINUX_VERSION:edgerouter = "5.4.58"
-LINUX_VERSION:beaglebone-yocto = "5.4.58"
-- 
2.19.1


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

[yocto] [PATCH 2/4] poky: set default kernel to 5.13

[Bruce Ashfield]

From: Bruce Ashfield 

both -rt and -standard have been updated to 5.13, so we switch out
defaults.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index c7c46cd226..ae0c52178a 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -19,8 +19,8 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "5.10%"
-PREFERRED_VERSION_linux-yocto-rt ?= "5.10%"
+PREFERRED_VERSION_linux-yocto ?= "5.13%"
+PREFERRED_VERSION_linux-yocto-rt ?= "5.13%"
 
 SDK_NAME = 
"${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.19.1


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

[yocto] [PATCH 1/4] poky/poky-tiny: set default kernel to 5.13

[Bruce Ashfield]

From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf 
b/meta-poky/conf/distro/poky-tiny.conf
index c25e50c73a..b8f5f21a31 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -43,7 +43,7 @@ FULL_OPTIMIZATION="-Os -pipe ${DEBUG_FLAGS}"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "5.10%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "5.13%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
-- 
2.19.1


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

[yocto] [PATCH 0/4] poky: kernel: change defaults to 5.10/5.13

[Bruce Ashfield]

From: Bruce Ashfield 

Richard,

This is a follow on to my oe-core series that drops the 5.4 recipes.

I haven't had any issues with 5.10/5.13 in my local testing, but I do
expect we'll find something during integration.

Cheers,

Bruce

The following changes since commit ababb195496f1d16d8b082e1bc6d87a177d2b2a6:

  conf/machine: bump qemu preferred versions to 5.13 (2021-08-15 10:44:27 -0400)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel-yocto
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (4):
  poky/poky-tiny: set default kernel to 5.13
  poky: set default kernel to 5.13
  yocto-bsp: drop 5.4 bbappend
  poky-alt: switch default kernel to 5.10

 .../include/poky-distro-alt-test-config.inc   |  2 +-
 meta-poky/conf/distro/poky-tiny.conf  |  2 +-
 meta-poky/conf/distro/poky.conf   |  4 ++--
 .../linux/linux-yocto_5.4.bbappend| 23 ---
 4 files changed, 4 insertions(+), 27 deletions(-)
 delete mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend

-- 
2.19.1


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

Re: [yocto] [yocto-kernel-cache] [yocto-5.10] nxp-imx8: Enable IMX_SCU_SOC config

[Bruce Ashfield]

In message: RE: [yocto-kernel-cache] [yocto-5.10] nxp-imx8: Enable IMX_SCU_SOC 
config
on 16/07/2021 Wang, Xiaolei wrote:

> Hi bruce
> 
> Can you help me merge this patch to yocto-kernel-cache branch yocto-5.10

The original patch didn't have a branch specified, so it somehow managed to
miss my filters.

this is now merged

Bruce

> 
> Thanks
> Xiaolei
> 
> -Original Message-
> From: linux-yo...@lists.yoctoproject.org  
> On Behalf Of Xiaolei Wang
> Sent: Friday, July 9, 2021 12:58 PM
> To: bruce.ashfi...@gmail.com
> Cc: linux-yo...@lists.yoctoproject.org
> Subject: [linux-yocto] [PATCH] nxp-imx8: Enable IMX_SCU_SOC config
> 
> Enable IMX_SCU_SOC config for imx8 get soc_id value and get revision, Because 
> the SW workaround for i.MX8QM TKT340553 is required on the imx8qm board, it 
> is necessary to set TKT340553_SW_WORKAROUND to true in tlbflush.h, otherwise 
> the system will often encounter memory problems and cause hang
> 
> Signed-off-by: Xiaolei Wang 
> ---
>  bsp/nxp-imx8/nxp-imx8.cfg | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg index 
> d9ea3caf..dbc77b3a 100644
> --- a/bsp/nxp-imx8/nxp-imx8.cfg
> +++ b/bsp/nxp-imx8/nxp-imx8.cfg
> @@ -475,6 +475,7 @@ CONFIG_OF_OVERLAY=y
>  CONFIG_MAILBOX=y
>  CONFIG_IMX_MBOX=y
>  CONFIG_IMX_SCU=y
> +CONFIG_IMX_SCU_SOC=y
>  CONFIG_IMX_DSP=y
>  CONFIG_IMX_SCU_PD=y
>  CONFIG_IIO=y
> --
> 2.25.1
> 

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

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

[Bruce Ashfield]

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

I was also going to suggest distros.

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

Bruce

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


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

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

[yocto] [PATCH] bsps/5.10: update to v5.10.43

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release, and to
match the qemu BSPs in oe-core

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.10.bbappend  | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index bc2b3bf576..f8362b6635 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,17 +7,17 @@ KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
-SRCREV_machine_genericx86-64 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
-SRCREV_machine_edgerouter ?= "965ab3ab746ae8a1158617b6302d9c218ffbbb66"
-SRCREV_machine_beaglebone-yocto ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_genericx86 ?= "ab49d2db98bdee2c8c6e17fb59ded9e5292b0f41"
+SRCREV_machine_genericx86-64 ?= "ab49d2db98bdee2c8c6e17fb59ded9e5292b0f41"
+SRCREV_machine_edgerouter ?= "274d63799465eebfd201b3e8251f16d29e93a978"
+SRCREV_machine_beaglebone-yocto ?= "ab49d2db98bdee2c8c6e17fb59ded9e5292b0f41"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
 COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 
-LINUX_VERSION_genericx86 = "5.10.21"
-LINUX_VERSION_genericx86-64 = "5.10.21"
-LINUX_VERSION_edgerouter = "5.10.21"
-LINUX_VERSION_beaglebone-yocto = "5.10.21"
+LINUX_VERSION_genericx86 = "5.10.43"
+LINUX_VERSION_genericx86-64 = "5.10.43"
+LINUX_VERSION_edgerouter = "5.10.43"
+LINUX_VERSION_beaglebone-yocto = "5.10.43"
-- 
2.19.1


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

Re: [yocto] [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: dspi: fsl: fix dspi transfer hang issue

[Bruce Ashfield]

In message: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: 
drivers: dspi: fsl: fix dspi transfer hang issue
on 04/06/2021 Zhantao Tang wrote:

> 
> Hi Bruce,
> 
> 
> There is an patch to fix dspi hang issue.
> 
> Would you please help to merge this patch into linux-ycoto kernel, v5.10, 
> branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx?

This went to the wrong mailing list, but I did pick it up!

merged.

Bruce

> 
> 
> Thanks,
> Zhantao
> 

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

Re: [yocto] Can the Linux kernel reuse the barebox device tree? #kernel

[Bruce Ashfield]

On Fri, Jun 4, 2021 at 5:00 AM  wrote:
>
> Hi,
> I made the following observation in my custom Yocto system:
> The device tree loaded by the Linux kernel is one that is only available in 
> the barebox directory, but not available in the kernel sources. In fact, it 
> is quite similar, but I made some changes to it in the device tree provided 
> to the kernel. Especially the machine model that is shown during kernel boot 
> is a string that can only be found in the compiled barebox image, but not in 
> the dtb files (where I can find the correct machine model string) or anywhere 
> else in the compilation results. But also other messages indicate that the 
> wrong device tree is loaded.
>
> It was correct before, and I am not really sure what triggered that (just 
> upgraded from zeus, but it might or might not be triggered by that) and I 
> wouldn't expect that anyone could guess what I have done wrong without 
> debugging my setup in depth. But, my general question is: Is there any 
> mechanism that could explain such a behavior? Any configuration that means 
> "extract the device tree from the bootloader" or something similar?
>

In your upgrade, did the bootloader/initramfs/kernel version change ?
The passing of the device tree to the kernel is (commonly) part of the
bootflow, so changes to any of the components in that flow could cause
the different device tree usage you are seeing.

The bbclass and recipes involved wouldn't have been packaging up the
barebox tree and pulling it into the kernel in zeus, so while it isn't
impossible, it isn't likely to be in the build or packaging changes.

Bruce

> Greetings,
> Florian
> 
>


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

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

Re: [yocto] [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

[Bruce Ashfield]

On Fri, Jun 4, 2021 at 8:37 AM Bruce Ashfield via
lists.yoctoproject.org
 wrote:
>
> On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield  
> wrote:
> >
> > On Thu, Jun 3, 2021 at 11:35 PM Kai  wrote:
> > >
> > > On 6/4/21 11:22 AM, Bruce Ashfield wrote:
> > > > On Thu, Jun 3, 2021 at 11:06 PM  wrote:
> > > >> From: Kai Kang 
> > > >>
> > > >> Replace hardknott with honister in layer.conf which aligns with
> > > >> oe-core.
> > > >>
> > > > I had added this back in April, but apparently didn't push the change.
> > > >
> > > > I also noticed that I've been updating the wrong branch with 
> > > > compatibility.
> > > >
> > > > That should all be fixed now.
> > >
> > > Hi Bruce,
> > >
> > > Thanks. I have seen your commits.
> > >
> > > But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
> > > warning:
> > >
> > >WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
> > > length 28 exceeds maximum (25), truncating
> > >
> > > Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
> > > master, please?
> >
> > Nope. It is compatible with those releases, so they need to stay. I
> > see no valid reason to be limited to a certain number of characters.
> >
> > >
> > > Or it set in oe-core's layer.conf:
> > >
> > > LAYERSERIES_CORENAMES = "hardknott honister"
> > >
> > > we just align with it to keep the latest 2, please?
> >
> > That is just as arbitrary, I'll keep it as-is.
>
> I took a quick look, is this warning coming from the layer index ?
> That would be important information to convey when sending changes
> like this.

Apologies on this, I see in the follow up email you did mention the
layerindex .. I read completely over that, and had to search up the
warning myself. (my fault, not yours).

>
> That being said, it is a longer fix to get that warning changed, and
> I'd rather not break the index, so I dropped to only the last two
> releases.
>
> But I do recommend that the layer index be changed (if that is the
> cause of the warning), since we shouldn't be adapting to the index ..
> it should be adapting to layers.

This point still stands though :D

Bruce

>
> Bruce
>
> >
> > Bruce
> >
> > >
> > > Regards,
> > > Kai
> > >
> > > >
> > > > Bruce
> > > >
> > > >> Signed-off-by: Kai Kang 
> > > >> ---
> > > >>   conf/layer.conf | 2 +-
> > > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/conf/layer.conf b/conf/layer.conf
> > > >> index 007f578..8ae67ba 100644
> > > >> --- a/conf/layer.conf
> > > >> +++ b/conf/layer.conf
> > > >> @@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
> > > >>   # This should only be incremented on significant changes that will
> > > >>   # cause compatibility issues with other layers
> > > >>   LAYERVERSION_realtime = "1"
> > > >> -LAYERSERIES_COMPAT_realtime = "hardknott"
> > > >> +LAYERSERIES_COMPAT_realtime = "honister"
> > > >>   LAYERDEPENDS_realtime = "core openembedded-layer"
> > > >>   LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
> > > >> --
> > > >> 2.17.1
> > > >>
> > > >
> > >
> > > --
> > > Kai Kang
> > > Wind River Linux
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


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

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

Re: [yocto] [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

[Bruce Ashfield]

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield  wrote:
>
> On Thu, Jun 3, 2021 at 11:35 PM Kai  wrote:
> >
> > On 6/4/21 11:22 AM, Bruce Ashfield wrote:
> > > On Thu, Jun 3, 2021 at 11:06 PM  wrote:
> > >> From: Kai Kang 
> > >>
> > >> Replace hardknott with honister in layer.conf which aligns with
> > >> oe-core.
> > >>
> > > I had added this back in April, but apparently didn't push the change.
> > >
> > > I also noticed that I've been updating the wrong branch with 
> > > compatibility.
> > >
> > > That should all be fixed now.
> >
> > Hi Bruce,
> >
> > Thanks. I have seen your commits.
> >
> > But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
> > warning:
> >
> >WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
> > length 28 exceeds maximum (25), truncating
> >
> > Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
> > master, please?
>
> Nope. It is compatible with those releases, so they need to stay. I
> see no valid reason to be limited to a certain number of characters.
>
> >
> > Or it set in oe-core's layer.conf:
> >
> > LAYERSERIES_CORENAMES = "hardknott honister"
> >
> > we just align with it to keep the latest 2, please?
>
> That is just as arbitrary, I'll keep it as-is.

I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.

That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.

Bruce

>
> Bruce
>
> >
> > Regards,
> > Kai
> >
> > >
> > > Bruce
> > >
> > >> Signed-off-by: Kai Kang 
> > >> ---
> > >>   conf/layer.conf | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/conf/layer.conf b/conf/layer.conf
> > >> index 007f578..8ae67ba 100644
> > >> --- a/conf/layer.conf
> > >> +++ b/conf/layer.conf
> > >> @@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
> > >>   # This should only be incremented on significant changes that will
> > >>   # cause compatibility issues with other layers
> > >>   LAYERVERSION_realtime = "1"
> > >> -LAYERSERIES_COMPAT_realtime = "hardknott"
> > >> +LAYERSERIES_COMPAT_realtime = "honister"
> > >>   LAYERDEPENDS_realtime = "core openembedded-layer"
> > >>   LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
> > >> --
> > >> 2.17.1
> > >>
> > >
> >
> > --
> > Kai Kang
> > Wind River Linux
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



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

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

Re: [yocto] [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

[Bruce Ashfield]

On Thu, Jun 3, 2021 at 11:35 PM Kai  wrote:
>
> On 6/4/21 11:22 AM, Bruce Ashfield wrote:
> > On Thu, Jun 3, 2021 at 11:06 PM  wrote:
> >> From: Kai Kang 
> >>
> >> Replace hardknott with honister in layer.conf which aligns with
> >> oe-core.
> >>
> > I had added this back in April, but apparently didn't push the change.
> >
> > I also noticed that I've been updating the wrong branch with compatibility.
> >
> > That should all be fixed now.
>
> Hi Bruce,
>
> Thanks. I have seen your commits.
>
> But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
> warning:
>
>WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
> length 28 exceeds maximum (25), truncating
>
> Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
> master, please?

Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.

>
> Or it set in oe-core's layer.conf:
>
> LAYERSERIES_CORENAMES = "hardknott honister"
>
> we just align with it to keep the latest 2, please?

That is just as arbitrary, I'll keep it as-is.

Bruce

>
> Regards,
> Kai
>
> >
> > Bruce
> >
> >> Signed-off-by: Kai Kang 
> >> ---
> >>   conf/layer.conf | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/conf/layer.conf b/conf/layer.conf
> >> index 007f578..8ae67ba 100644
> >> --- a/conf/layer.conf
> >> +++ b/conf/layer.conf
> >> @@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
> >>   # This should only be incremented on significant changes that will
> >>   # cause compatibility issues with other layers
> >>   LAYERVERSION_realtime = "1"
> >> -LAYERSERIES_COMPAT_realtime = "hardknott"
> >> +LAYERSERIES_COMPAT_realtime = "honister"
> >>   LAYERDEPENDS_realtime = "core openembedded-layer"
> >>   LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
> >> --
> >> 2.17.1
> >>
> >
>
> --
> Kai Kang
> Wind River Linux
>


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

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

Re: [yocto] [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

[Bruce Ashfield]

On Thu, Jun 3, 2021 at 11:06 PM  wrote:
>
> From: Kai Kang 
>
> Replace hardknott with honister in layer.conf which aligns with
> oe-core.
>

I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.

Bruce

> Signed-off-by: Kai Kang 
> ---
>  conf/layer.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 007f578..8ae67ba 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
>  # This should only be incremented on significant changes that will
>  # cause compatibility issues with other layers
>  LAYERVERSION_realtime = "1"
> -LAYERSERIES_COMPAT_realtime = "hardknott"
> +LAYERSERIES_COMPAT_realtime = "honister"
>  LAYERDEPENDS_realtime = "core openembedded-layer"
>  LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
> --
> 2.17.1
>


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

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

Re: [yocto] Understanding kernel patching in linux-yocto

[Bruce Ashfield]

On Wed, May 12, 2021 at 10:07 AM Yann Dirson
 wrote:
>
> Thanks for those clarifications!
>
> Some additional questions below
>
> Le mer. 12 mai 2021 à 15:19, Bruce Ashfield  a 
> écrit :
> >
> > On Wed, May 12, 2021 at 7:14 AM Yann Dirson  
> > wrote:
> > >
> > > I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> > > [1], and I'm wondering how I should be providing kernel patches, as
> > > just add ing "patch" directives in the .scc does not get them applied
> > > unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
> > >
> > > From an old thread [3] I understand that the patches from the standard
> > > kmeta snippets are already applied to the tree, and that to get the
> > > patches from my BSP I'd need to reference it explicitly in SRC_URI
> > > (along with using "nopatch" in the right places to avoid the
> > > already-applied patches to get applied twice).
> > >
> > > I have the feeling that I'm lacking the rationale behind this, and
> > > would need to understand this better to make things right in this BSP.
> > > Especially:
> > > - at first sight, having the patches both applied to linux-yocto and
> > > referenced in yocto-kernel-cache just to be skipped on parsing looks
> > > like both information duplication and parsing of unused lines
> >
> > At least some of this is mentioned in the advanced section of the
> > kernel-dev manual, but I can summarize/reword things here, and
> > I'm also doing a presentation related to this in the Yocto summit at
> > the end of this month.
> >
> > The big thing to remember, is that the configuration and changes
> > you see in that repository, are not only for yocto purposes. The
> > concepts and structure pre-date when they were first brought in
> > to generate reference kernels over 10 years ago (the implementation
> > has changed, but the concepts are still the same). To this day,
> > there still are cases that they are used with just a kernel tree and
> > cross toolchain.
> >
> > With that in mind, the meta-data is used for many different things
> >
> >  - It organizes patches / features and their configuration into
> >reusable blocks. At the same time documenting the changes
> >that we have applied to a tree
> >  - It makes those patches and configuration blocks available to
> >other kernel trees (for whatever reason).
> >  - It configures the tree during the build process, reusing both
> >configuration only and patch + configuration blocks
>
> >  - It is used to generate a history clean tree from scratch for
> >each new supported kernel. Which is what I do when creating
> >new linux-yocto-dev references, and the new /standard/*
> >branches in linux-yocto.
>
> I'd think (and I take your further remarks about workflow as confirming
> this), that when upgrading the kernel the best tool would be git-rebase.
> Then, regenerating the linux-yocto branches would only be a akin to a
> check that the metadata is in sync with the new tree you rebased ?

The best of anything is a matter of opinion. I heavily use git-rebase and
sure, you could use it to do something similar here. But the result is
the same. There's still heavy use of quilt in kernel circles. Workflows
don't change easily, and as long as they work for the maintainer, they
tend to stay put. Asking someone to change their workflow, rarely goes
over well.

>
> If that conclusion is correct, wouldn't it be possible to avoid using the
> linux-yocto branches directly, and let all the patches be applied at
> do_patch time ?  That would be much more similar to the standard
> package workflow (and thus lower the barrier for approaching the
> kernel packages).

That's something we did in the past, and sure, you can do anything.
But patching hundreds of changes at build time means constant
failures .. again, I've been there and done that. We use similar patches
in many different contexts and optional stackings. You simply cannot
maintain them and stay sane by whacking patches onto the SRC_URI.
The last impression you want when someone builds your kernel is that
they can't even get past the patch phase.  So that's a hard no, to how
the reference kernels are maintained (and that hard no has been around
for 11 years now).

Also, we maintain contributed reference BSPs in that same tree, that
are yanking in SDKs from vendors, etc, they are in the thousands of
patches. So you need the tree and the BSP branches to support that.

>
>
> > So why not just drop all the pat

Re: [yocto] Understanding kernel patching in linux-yocto

[Bruce Ashfield]

On Wed, May 12, 2021 at 7:14 AM Yann Dirson  wrote:
>
> I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> [1], and I'm wondering how I should be providing kernel patches, as
> just add ing "patch" directives in the .scc does not get them applied
> unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
>
> From an old thread [3] I understand that the patches from the standard
> kmeta snippets are already applied to the tree, and that to get the
> patches from my BSP I'd need to reference it explicitly in SRC_URI
> (along with using "nopatch" in the right places to avoid the
> already-applied patches to get applied twice).
>
> I have the feeling that I'm lacking the rationale behind this, and
> would need to understand this better to make things right in this BSP.
> Especially:
> - at first sight, having the patches both applied to linux-yocto and
> referenced in yocto-kernel-cache just to be skipped on parsing looks
> like both information duplication and parsing of unused lines

At least some of this is mentioned in the advanced section of the
kernel-dev manual, but I can summarize/reword things here, and
I'm also doing a presentation related to this in the Yocto summit at
the end of this month.

The big thing to remember, is that the configuration and changes
you see in that repository, are not only for yocto purposes. The
concepts and structure pre-date when they were first brought in
to generate reference kernels over 10 years ago (the implementation
has changed, but the concepts are still the same). To this day,
there still are cases that they are used with just a kernel tree and
cross toolchain.

With that in mind, the meta-data is used for many different things

 - It organizes patches / features and their configuration into
   reusable blocks. At the same time documenting the changes
   that we have applied to a tree
 - It makes those patches and configuration blocks available to
   other kernel trees (for whatever reason).
 - It configures the tree during the build process, reusing both
   configuration only and patch + configuration blocks
 - It is used to generate a history clean tree from scratch for
   each new supported kernel. Which is what I do when creating
   new linux-yocto-dev references, and the new /standard/*
   branches in linux-yocto.

So why not just drop all the patches in the SRC_URI ? Been there,
done that. It fails spectacularly when you are managing queues of
hundreds of potentially conflicting patches (rt, yaffs, aufs, ... etc, etc)
and then attempting to constantly merge -stable and other kernel
trees into the repository. git is the tool for managing that, not stacks
of patches. You spend your entire life fixing patch errors and refreshing
fuzz (again, been there, done that).

So why not just keep a history and constantly merge new versions
into it ? Been there, done that. You end up with an absolute garbage
history of octopus merges and changes that are completely hidden,
non-obvious and useless for collaborating with other kernel projects.
Try merging a new kernel version into those same big features, it's
nearly impossible and you have a franken-kernel that you end up trying
to support and fix yourself. All the bugs are yours and yours alone.

So that's why there's a repository that tracks the patches and the
configuration and is used for multiple purposes. Keeping the patches
and config blocks separate would just lead to even more errors as
I update one and forget the other, etc, etc. There have been various
incarnations of the tools that also did different things with the patches,
and they weren't skipped, but detected as applied or not on-the-fly,
so there are other historical reasons for the structure as well.

> - kernel-yocto.bbclass does its own generic job of locating a proper
> BSP using the KMACHINE/KTYPE/KARCH tags in BSP, it looks like
> specifying a specific BSP file would just defeat of this: how should I
> deal with this case where I'm providing both "standard" and "tiny"
> KTYPE's ?

I'm not quite following the question here, so I can try to answer badly
and you can clarify based on my terrible answer.

The tools can locate your "bsp entry point" / "bsp definition" in
your layer. Either provided by something on the SRC_URI or something
in a kmeta repository (also specified on the SRC_URI).  Since
both of those are added to the search paths they check. Those
are just .scc files with a specified KMACHINE/KTYPE that match, and
as you could guess from my first term I used, they are the entry
point into building the configuration queue.

That's where you start inheriting the base configuration(s) and including
feature blocks, etc. Those definitions are exactly the same as the
internal ones in the kernel-cache repository. By default, that located
BSP definition is excluded from inheriting patches .. because as you
noted, it would start trying to re-apply changes to the tree. It is there
to get the configuration blocks, patc

Re: [yocto] Recipe Grep'ing

[Bruce Ashfield]

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber  wrote:
>
> I was pondering putting some work in to a fairly large patch set aimed at 
> making recipes easier to grep through, and wanted to get some feedback before 
> I put time and effort into it.
>
> I have often found that the following pattern cleanly describes the "what" 
> and the "why" when grep'ing through recipes to search for things:
>
> FOO += "item1"
> FOO += "item2"
>
> Whereas this pattern gives us the "what", but not the "why":
>
> FOO = "item1 \
>  item2 \
> "
>
> After discussing this with Richard Purdie on IRC, I also understand that the 
> latter pattern benefits some forms of build output. In addition, for SRC_URI, 
> the "why" is normally fairly obvious from context clues.

The other issue with large formatting patches, is that they make a
history "wall".  So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce

>
> So, is there any interest in accepting a patch set of that nature for Yocto 
> and OE repositories? If so, what variables and situations should be 
> considered "off limits" to a change like that?
>
> ..Ch:W..
>
>
> --
> "Perfection must be reached by degrees; she requires the slow hand of time." 
> - Voltaire
>
> 
>


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

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