Re: [yocto] packages not generated in output folder

[Khem Raj]

On Thu, May 16, 2024 at 12:55 PM Martin Jansa via
lists.yoctoproject.org 
wrote:
>
> You probably inherit rm_work somewhere, use bitbake-getvar to find out
> where and remove it if you don't want the files to be removed after
> the build is finished.

right, thats perhaps the real reason for the intermediate build
objects being removed
it could also be inherited globally in conf file via local.conf or such

INHERIT += "rm_work"



>
> On Thu, May 16, 2024 at 9:28 PM SIMON BABY via lists.yoctoproject.org
>  wrote:
> >
> > Hello,
> >
> > I am building some applications in 5.15.0-102-generic #112~20.04.1-Ubuntu. 
> > My yocto recipes aeh building successfully but I am unable to see any 
> > package folders under the tmp directory. I see only log files under temp 
> > are created. Nothing else. Can I know if I am missing any configuration?
> >
> > tmp/work/cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi/marvell-umsd/3.0.7-r0$ 
> > ls -ll
> > total 12
> > drwxr-xr-x 2 sbaby sbaby 12288 May 16 12:26 temp
> >
> > This is valid for other recipes as well.
> >
> > /build/tmp/work/cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi/libgcc/11.4.0-r0$
> >  ls
> > temp
> >
> >
> > Regards
> > Simon
> >
> >
> >
> >
> >
>
> 
>

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

Re: [yocto] packages not generated in output folder

[Khem Raj]

On Thu, May 16, 2024 at 12:28 PM SIMON BABY via lists.yoctoproject.org
 wrote:
>
> Hello,
>
> I am building some applications in 5.15.0-102-generic #112~20.04.1-Ubuntu. My 
> yocto recipes aeh building successfully but I am unable to see any package 
> folders under the tmp directory. I see only log files under temp are created. 
> Nothing else. Can I know if I am missing any configuration?
>
> tmp/work/cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi/marvell-umsd/3.0.7-r0$ ls 
> -ll
> total 12
> drwxr-xr-x 2 sbaby sbaby 12288 May 16 12:26 temp
>
> This is valid for other recipes as well.
>
> /build/tmp/work/cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi/libgcc/11.4.0-r0$ 
> ls
> temp

Packages usually fall into 3 categories roughly
all - meant to work on all architectures e.g. scripts etc.
arch - runs on given architecture and machines based on this arch
machine - has machine specific stuff that makes it work only on the
given machine

what you search for is in arch specific build area, there is also
machine build area
which is usually -poky-linux-gnueabi and will be located in parallel to
cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi in your case. Look in there as well.

>
>
> Regards
> Simon
>
>
>
> 
>

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

Re: [yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Khem Raj]

We need a new uninative tarball generated with gcc14 for f40 so there might
be issues like you are seeing due to that. You can disable uninative
temporarily in your build and see if that works for the moment

On Thu, May 16, 2024 at 8:39 AM Ross Burton via lists.yoctoproject.org
 wrote:

>
>
> > On 16 May 2024, at 16:31, Zoran via lists.yoctoproject.org
>  wrote:
> > The full log (full_log.txt) is attached to this @, as per Ur request
> > (lot of stuff, echt!).
>
> From your log:
>
> WARNING: Host distribution "fedora-40" has not been validated with this
> version of the build system; you may possibly experience unexpected
> failures. It is recommended that you use a tested distribution.
>
> This is saying that Fedora 40 has not been validated and you may
> experience unexpected failures.
>
> Later in the log:
>
> pzstd:
> /home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6:
> version `CXXABI_1.3.15' not found (required by pzstd)
>
> That is the sort of unexpected failure you can expect when using Fedora
> 40, because it has not been validated.
>
> This is an incompatibility with Fedora 40 and uninative, so until this is
> resolved you can disable uninative with this in your local.conf:
>
> INHERIT:remove = “uninative”
>
> Ross
> 
>
>

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

Re: [yocto] requires libsqlite3.so()(64bit), but no providers found in RDEPENDS:xxx? [file-rdeps] #kirkstone #yocto

[Khem Raj]

On Tue, May 14, 2024 at 12:56 AM Altous, Salahaldeen via
lists.yoctoproject.org
 wrote:
>
> Hi All,
>
> I have one yocto recipe which is using libsqlite3, the compile task is OK but 
> I got this error with do_package_qa
>
> /usr/lib/libexample.so.0.2.3 contained in package example requires 
> libsqlite3.so()(64bit), but no providers found in RDEPENDS:example.? 
> [file-rdeps]

Generally the linker should link in versioned solib, libsqlite3
provides libsqlite3.so.0 and shlibs solver will automatically resolve
that
so I would suggest to look into this package and check how its linking
with libsqlite and fix it

>
>
>
> I have added this to the example recipe RDEPENDS but still the problem is not 
> solved, any idea?
>
> DEPENDS += " sqlite3"
> RDEPENDS_${PN} += " libsqlite3.so()(64bit)"
>
>
>
> Regards,
>
> Salahaldeen
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63094): https://lists.yoctoproject.org/g/yocto/message/63094
Mute This Topic: https://lists.yoctoproject.org/mt/106090753/21656
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
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] Warning about "no-recipes"

[Khem Raj]

On Tue, May 7, 2024 at 8:38 PM Worik Stanton
 wrote:
>>>
>>>
 fudged unto single repository. AFAICT
 gstreamer1.0-plugins-base_1.20.0.imx.bb should be
 coming from meta-freescale or meta-imx and if you have a unified
 metadata tree then this bb file should be somewhere, if not, that
>>>
>>>
>>> Which "bb"?   "gstreamer1.0-plugins-base_1.20.0.imx.bb"?
>>>
>>> I have: 
>>> layers/openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.20.5.bb
>>>
>>> The suffix is different. (1.20.5.bb V. 1.20.0.bb)
>>>
>>> That looks like the problem.  Should I rename this file?
>>
>>
>> No, that won’t help whoever has put this together for you would be the 
>> person to help and regenerate it for you including right dependencies
>>>
>>>
>
>
> The "whomever" has gone away, and I am on my own!
>
> Where do I start resolving a dependency like this?

It's hard to help you with the information you have shared so far.
Maybe you can describe in detail about your
setup and what release you are using and machines being targeted etc.

>
> Worik
>
>>>
>>> Worik
>>>
>>>
 means the project missed adding this layer
 to your build system.

 if you dont need this recipe then you can ignore failing on bbappends by 
 adding

 BB_DANGLINGAPPENDS_WARNONLY = "1" to yout local.conf

 > ```
 >
 > The file in mentioned  (gstreamer1.0-plugins-base_1.20.0.imx.bbappend) 
 > contains:
 >
 > ```
 > FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
 >
 > SRC_URI:append = " 
 > file://0001-glupload-don-t-reject-non-RGBA-output-format-in-_dir.patch"
 > ```
 >
 > And the file: 
 > "layers/meta-thisbuild-nxp/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-glupload-don-t-reject-non-RGBA-output-format-in-_dir.patch"
 >   exists.
 >
 > What can I do about this?
 >
 > Worik
 >
 >
 >
>>>
>>>
>>> 
>>>

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

Re: [yocto] Warning about "no-recipes"

[Khem Raj]

On Tue, May 7, 2024 at 6:53 PM Worik Stanton via lists.yoctoproject.org
 wrote:

>
>
> On Wed, 8 May 2024 at 13:39, Khem Raj  wrote:
>
>
>> > I am getting a warning as I build a yocto build I inherited.  Forgive
>> me I know very little about Yocto
>> >
>> > ```
>> > WARNING: No recipes in default available for:
>> >
>>  
>> /home/yocto/thisbuild-yocto/layers/openembedded-core/../meta-thisbuild-nxp/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.20.0.imx.bbappend
>>
>> how did you build your project metadata ? it seems some layers are
>>
>
> It builds from several directories under "meta-*"  I am unsure how I
> should answer that.
>
>
>> fudged unto single repository. AFAICT
>> gstreamer1.0-plugins-base_1.20.0.imx.bb should be
>> coming from meta-freescale or meta-imx and if you have a unified
>> metadata tree then this bb file should be somewhere, if not, that
>>
>
> Which "bb"?   "gstreamer1.0-plugins-base_1.20.0.imx.bb"?
>
> I have: layers/openembedded-core/meta/recipes-multimedia/gstreamer/
> gstreamer1.0-plugins-base_1.20.5.bb
>
> The suffix is different. (1.20.5.bb V. 1.20.0.bb)
>
> That looks like the problem.  Should I rename this file?
>

No, that won’t help whoever has put this together for you would be the
person to help and regenerate it for you including right dependencies

>
> Worik
>
>
> means the project missed adding this layer
>> to your build system.
>>
>> if you dont need this recipe then you can ignore failing on bbappends by
>> adding
>>
>> BB_DANGLINGAPPENDS_WARNONLY = "1" to yout local.conf
>>
>> > ```
>> >
>> > The file in mentioned  (gstreamer1.0-plugins-base_1.20.0.imx.bbappend)
>> contains:
>> >
>> > ```
>> > FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
>> >
>> > SRC_URI:append = "
>> file://0001-glupload-don-t-reject-non-RGBA-output-format-in-_dir.patch"
>> > ```
>> >
>> > And the file:
>> "layers/meta-thisbuild-nxp/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-glupload-don-t-reject-non-RGBA-output-format-in-_dir.patch"
>> exists.
>> >
>> > What can I do about this?
>> >
>> > Worik
>> >
>> >
>> >
>>
>
> 
>
>

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

Re: [yocto] Warning about "no-recipes"

[Khem Raj]

On Tue, May 7, 2024 at 6:28 PM Worik Stanton via
lists.yoctoproject.org
 wrote:
>
> I am getting a warning as I build a yocto build I inherited.  Forgive me I 
> know very little about Yocto
>
> ```
> WARNING: No recipes in default available for:
>   
> /home/yocto/thisbuild-yocto/layers/openembedded-core/../meta-thisbuild-nxp/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.20.0.imx.bbappend

how did you build your project metadata ? it seems some layers are
fudged unto single repository. AFAICT
gstreamer1.0-plugins-base_1.20.0.imx.bb should be
coming from meta-freescale or meta-imx and if you have a unified
metadata tree then this bb file should be somewhere, if not, that
means the project missed adding this layer
to your build system.

if you dont need this recipe then you can ignore failing on bbappends by adding

BB_DANGLINGAPPENDS_WARNONLY = "1" to yout local.conf

> ```
>
> The file in mentioned  (gstreamer1.0-plugins-base_1.20.0.imx.bbappend) 
> contains:
>
> ```
> FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
>
> SRC_URI:append = " 
> file://0001-glupload-don-t-reject-non-RGBA-output-format-in-_dir.patch"
> ```
>
> And the file: 
> "layers/meta-thisbuild-nxp/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-glupload-don-t-reject-non-RGBA-output-format-in-_dir.patch"
>   exists.
>
> What can I do about this?
>
> Worik
>
> 
>

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

Re: [yocto] Command line Variable

[Khem Raj]

On Mon, May 6, 2024 at 9:25 PM Bratiranjan Acharya via
lists.yoctoproject.org
 wrote:
>
> Hi,
> Could we establish a tailored command within Yocto, taking to 
> "BUILD_ID=123456 bitbake custom-image" mirroring the functionality of 
> "MACHINE=x86 bitbake custom-image"? Essentially, I'm exploring the 
> possibility of introducing a custom variable like of 'MACHINE' and executing 
> it similarly from the command line, as mentioned before.
> I have tried various ways like defining in the conf,recipe,.inc file like 
> "BUILD_ID ?= "none"" and running directly from command line  "BUILD_ID=123456 
> bitbake custom-image" so it must change the BUILD_ID to 123456 but its not 
> working like that. Anyone have any suggestions? Thanks & Regards Brati
>

Maybe set BB_ENV_PASSTHROUGH_ADDITIONS = "BUILD_ID"

> 
>

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

Re: [yocto] [tsc] [qa-build-notification] QA notification for completed autobuilder build (yocto-5.0.rc2)

[Khem Raj]

On Wed, Apr 17, 2024 at 1:50 AM Richard Purdie via lists.yoctoproject.org
 wrote:

> On Wed, 2024-04-17 at 08:37 +, Pokybuild User via
> lists.yoctoproject.org wrote:
> >
> > A build flagged for QA (yocto-5.0.rc2) was completed on the
> autobuilder and is available at:
> >
> >
> > https://autobuilder.yocto.io/pub/releases/yocto-5.0.rc2
> >
> >
> > Build URL:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6813
>
> This does have two failures in it and two known ptest warnings (curl and
> gstreamer).
>
> The failures are from:
>
> a) a github network issue (rate limiting?)


Do we know it works ok in another build ?

>
>
> b) pip being missing in the buildtools tarball used to run the build for
> patchtest-selftest
>
> For b), updating buildtools should resolve it, I thought I had done
> that but there were a lot of moving pieces so I must not have got the
> latest.
>
> I'm proposing we do but this into QA as I'd not block release on these
> issues. I've done my best to get this into as good a shape as we can.
>

I am ok with this going ahead


> Cheers,
>
> Richard
>
> 
>
>

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

[linux-yocto] [kernel-cache][PATCH] nft_test.cfg: Enable CONFIG_VETH

[Khem Raj]

nftable ptests do create interfaces of veth type and this
feature would be needed to enable those tests

e.g. from tests/shell/testcases/packetpath/vlan_8021ad_tag

ip link add veth0 netns $ns1 type veth peer name veth0 netns $ns2

Signed-off-by: Khem Raj 
---
 features/nf_tables/nft_test.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/features/nf_tables/nft_test.cfg b/features/nf_tables/nft_test.cfg
index 45ca8e5d..0a959d0e 100644
--- a/features/nf_tables/nft_test.cfg
+++ b/features/nf_tables/nft_test.cfg
@@ -10,3 +10,4 @@ CONFIG_NFT_OSF=m
 CONFIG_NFT_QUOTA=m
 CONFIG_NFT_SYNPROXY=m
 CONFIG_NFT_XFRM=m
+CONFIG_VETH=y
-- 
2.44.0


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

Re: [yocto] [meta-raspberrypi][PATCH 0/3] Initial u-boot support for raspberrypi5

[Khem Raj]

On Sun, Apr 7, 2024 at 1:25 PM Tim Orling  wrote:

> Dear GitHub, please let us attach a repo to another GitHub repo after the
> creation. Why is a fork something opaque to us?
>

Look into using git remote add …

>
> On Sun, Apr 7, 2024 at 1:22 PM Tim Orling  wrote:
>
>> I set up my github repo with git.yoctoproject.org so I have to destroy
>> it to fork from agherzan and send a PR.
>>
>> It's Sunday. I'm not going to do that.
>>
>> On Sun, Apr 7, 2024 at 1:11 PM Khem Raj  wrote:
>>
>>> I think it would be better if you opened a github PR so it can run
>>> through CI
>>>
>>> On Sun, Apr 7, 2024 at 12:54 PM Tim Orling 
>>> wrote:
>>> >
>>> > Enable u-boot for the raspberrypi5 via the meta-lts-mixins
>>> 'scarthgap/u-boot' branch.
>>> >
>>> > This is initial support for raspberrypi5, not all features (usb,
>>> ethernet) are enabled
>>> > in u-boot yet.
>>> >
>>> > You may need to have a UART dongle plugged into the 'UART' port
>>> between 'HDMI0' and
>>> > 'HDMI1' to get the kernel to boot. Your mileage may vary.
>>> >
>>> > The following changes since commit
>>> d072cc8a48571a4af40a937f98e173b5c9468c4f:
>>> >
>>> >   rpi-base: Add hifiberry-dacplusadc overlay (2024-03-28 03:35:31
>>> +)
>>> >
>>> > are available in the Git repository at:
>>> >
>>> >   https://github.com/moto-timo/meta-raspberrypi
>>> scarthgap/raspberrypi5_u-boot
>>> >
>>> https://github.com/moto-timo/meta-raspberrypi/tree/scarthgap/raspberrypi5_u-boot
>>> >
>>> > Tim Orling (3):
>>> >   layer.conf: rpi5 recommends lts-u-boot-mixin
>>> >   u-boot: re-enable rapsberrypi5
>>> >   raspberrypi5.conf: Fix KERNEL_IMAGETYPE_UBOOT
>>> >
>>> >  conf/layer.conf  | 3 +++
>>> >  conf/machine/raspberrypi5.conf   | 6 ++
>>> >  recipes-bsp/u-boot/u-boot_%.bbappend | 3 ---
>>> >  3 files changed, 9 insertions(+), 3 deletions(-)
>>> >
>>> > --
>>> > 2.43.2
>>> >
>>> >
>>> > 
>>> >
>>>
>>

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

Re: [yocto] [meta-raspberrypi][PATCH 0/3] Initial u-boot support for raspberrypi5

[Khem Raj]

I think it would be better if you opened a github PR so it can run through CI

On Sun, Apr 7, 2024 at 12:54 PM Tim Orling  wrote:
>
> Enable u-boot for the raspberrypi5 via the meta-lts-mixins 'scarthgap/u-boot' 
> branch.
>
> This is initial support for raspberrypi5, not all features (usb, ethernet) 
> are enabled
> in u-boot yet.
>
> You may need to have a UART dongle plugged into the 'UART' port between 
> 'HDMI0' and
> 'HDMI1' to get the kernel to boot. Your mileage may vary.
>
> The following changes since commit d072cc8a48571a4af40a937f98e173b5c9468c4f:
>
>   rpi-base: Add hifiberry-dacplusadc overlay (2024-03-28 03:35:31 +)
>
> are available in the Git repository at:
>
>   https://github.com/moto-timo/meta-raspberrypi scarthgap/raspberrypi5_u-boot
>   
> https://github.com/moto-timo/meta-raspberrypi/tree/scarthgap/raspberrypi5_u-boot
>
> Tim Orling (3):
>   layer.conf: rpi5 recommends lts-u-boot-mixin
>   u-boot: re-enable rapsberrypi5
>   raspberrypi5.conf: Fix KERNEL_IMAGETYPE_UBOOT
>
>  conf/layer.conf  | 3 +++
>  conf/machine/raspberrypi5.conf   | 6 ++
>  recipes-bsp/u-boot/u-boot_%.bbappend | 3 ---
>  3 files changed, 9 insertions(+), 3 deletions(-)
>
> --
> 2.43.2
>
>
> 
>

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

Re: [yocto] Add json-c package to yocto sdk

[Khem Raj]

On Wed, Apr 3, 2024 at 1:50 PM Jacob Avraham
 wrote:
>
> I want to create a yocto sdk for arm64 architecture that includes the json-c 
> library package.
>
> After running 'source oe-init-build-env' in the poky directory, I did the 
> following changes to the local.conf file: MACHINE ??= "qemuarm64"
> IMAGE_INSTALL += " json-c"

Can you try doing CORE_IMAGE_EXTRA_INSTALL += "json-c"

>
> Then I ran 'bitbake core-image-minimal' and 'bitbake -c populate_sdk 
> core-image-minimal'.
>
> I see that the package is compiled as native, but I don't see it in the 
> created image, nor in the SDK. I tried it also with target 
> 'core-image-full-cmdline', but no luck there either.
>
> What am I missing here?
>
>
> Jacob
>
>
>
> 
>

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

Re: [yocto] Pipewire Integration with Yocto 4.0.13 (kirkstone)

[Khem Raj]

On Tue, Mar 26, 2024 at 5:01 AM Sudarshana Reddy Singathala
 wrote:
>
> Hi,
>
> I am working with yocto project on IMX8MM board, i am trying to replace 
> pulseaudio with pipewire as I have seen pipewire is part of  yocto 
> meta-opembedded/meta-multimedia/recipe-multimedia/pipewire.
>
> But im not able to see pipewire configuration and commands in my image.
>
> And then i added the below packages in local.conf file
> IMAGE_INSTALL:append = " libspa-dbus libpipewire pipewire pipewire-pulse 
> wireplumber pipewire-alsa pipewire-modules-meta pipewire-v4l2"
>
> And i getting the below error message while running pipewire service,
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 pipewire[483]: [W][8.835990] 
> pw.context   | [   context.c:  374 pw_context_new()] 0xaaab10aeba40: 
> can't load dbus library: support/libspa-dbus
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 pipewire[483]: [E][8.836576] 
> pw.module| [   impl-module.c:  278 pw_context_load_module()] No module 
> "libpipewire-module-rt" was found
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 pipewire[483]: [E][8.838528] 
> pw.module| [   impl-module.c:  278 pw_context_load_module()] No module 
> "libpipewire-module-profiler" was found
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 pipewire[483]: [E][8.838576] 
> pw.conf  | [  conf.c:  560 load_module()] 0xaaab10aeba40: could 
> not load mandatory module "libpipewire-module-profily
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 pipewire[483]: [E][8.839009] 
> default  | [  pipewire.c:  125 main()] failed to create context: No 
> such file or directory

I guess it needs some additional pipewire-modules to be installed, you
might have to add them into the IMAGE_INSTALL as well.

> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: pipewire.service: Main 
> process exited, code=exited, status=254/n/a
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: pipewire.service: Failed 
> with result 'exit-code'.
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: pipewire.service: 
> Scheduled restart job, restart counter is at 5.
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: Stopped PipeWire 
> Multimedia Service.
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: pipewire.service: Start 
> request repeated too quickly.
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: pipewire.service: Failed 
> with result 'exit-code'.
> Apr 28 18:28:37 phyboard-pollux-imx8mp-3 systemd[1]: Failed to start PipeWire 
> Multimedia Service.
>
> Can some one help me in integrating pipewire.
>
> Best Regards,
> Sudarshan.
>
> 
>

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

Re: [yocto] libtool error

[Khem Raj]

is this error reproducible ? Check if its causing some sort of out of
memory errors and crashes on your build system. Can you see if there
are some coredumps etc ?

On Sun, Mar 24, 2024 at 9:04 AM Amol Practise  wrote:
>
> Hello ,
>
> I am getting error while building yocto for raspberry pi , please see 
> attached log file for reference.
>
> Help is appreciated.
>
> Thank you.
> Amol Palshetkar
>
>
> 
>

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

Re: [yocto] Cannot ssh into qemu guest

[Khem Raj]

See if you have debug-tweaks in IMAGE_FEATURES you can easily check it with
bitbake-getvar IMAGE_FEATURES -r core-image-full-cmdline

On Sat, Mar 9, 2024 at 10:59 AM Xylopyrographer
 wrote:
>
> Thanks for the reply.
>
> Still a bit green with all this but from the QEMU VM, sshd is running and 
> port 22 is open.
>
> Checked by running:
> ps aux | grep sshd
> and
> netstat -plant | grep :22
>
> as well, I can telnet in to the VM itself by running (from within the VM):
>
> telnet localhost 22
>
> which returns:
> Connected to localhost
> SSH-2.0-OpenSSH_9.5
>
> So I think all is as it should be on the QEMU side of things?
>
> Just need the magic keystrokes to get in from outside the VM.
>
> Any further hints?
>
> Many thanks.
>
> 
>

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

[linux-yocto] [kernel-cache][PATCH] riscv: Enable XHCI usb

[Khem Raj]

This brings it closer to other qemu configs in yocto and help to use usb
mouse and keyboard device emulation

Signed-off-by: Khem Raj 
---
 bsp/qemuriscv32/qemuriscv32.scc | 6 ++
 bsp/qemuriscv64/qemuriscv64.scc | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/bsp/qemuriscv32/qemuriscv32.scc b/bsp/qemuriscv32/qemuriscv32.scc
index 7d368aad..2a1e3292 100644
--- a/bsp/qemuriscv32/qemuriscv32.scc
+++ b/bsp/qemuriscv32/qemuriscv32.scc
@@ -3,3 +3,9 @@ kconf hardware qemuriscv32.cfg
 
 # Graphics support
 include features/drm-bochs/drm-bochs.scc
+
+# XHCI USB
+include features/usb/xhci-hcd.scc
+include features/net/net.scc
+include features/pci/pci.scc
+include cfg/net/mdio.scc
diff --git a/bsp/qemuriscv64/qemuriscv64.scc b/bsp/qemuriscv64/qemuriscv64.scc
index 2f012c53..f7d834f5 100644
--- a/bsp/qemuriscv64/qemuriscv64.scc
+++ b/bsp/qemuriscv64/qemuriscv64.scc
@@ -3,3 +3,9 @@ kconf hardware qemuriscv64.cfg
 
 # Graphics support
 include features/drm-bochs/drm-bochs.scc
+
+# XHCI USB
+include features/usb/xhci-hcd.scc
+include features/net/net.scc
+include features/pci/pci.scc
+include cfg/net/mdio.scc
-- 
2.44.0


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

[linux-yocto] [PATCH] riscv: Enable XHCI usb

[Khem Raj]

This brings it closer to other qemu configs in yocto and help to use usb
mouse and keyboard device emulation

Signed-off-by: Khem Raj 
---
 bsp/qemuriscv32/qemuriscv32.scc | 6 ++
 bsp/qemuriscv64/qemuriscv64.scc | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/bsp/qemuriscv32/qemuriscv32.scc b/bsp/qemuriscv32/qemuriscv32.scc
index 7d368aad..2a1e3292 100644
--- a/bsp/qemuriscv32/qemuriscv32.scc
+++ b/bsp/qemuriscv32/qemuriscv32.scc
@@ -3,3 +3,9 @@ kconf hardware qemuriscv32.cfg
 
 # Graphics support
 include features/drm-bochs/drm-bochs.scc
+
+# XHCI USB
+include features/usb/xhci-hcd.scc
+include features/net/net.scc
+include features/pci/pci.scc
+include cfg/net/mdio.scc
diff --git a/bsp/qemuriscv64/qemuriscv64.scc b/bsp/qemuriscv64/qemuriscv64.scc
index 2f012c53..f7d834f5 100644
--- a/bsp/qemuriscv64/qemuriscv64.scc
+++ b/bsp/qemuriscv64/qemuriscv64.scc
@@ -3,3 +3,9 @@ kconf hardware qemuriscv64.cfg
 
 # Graphics support
 include features/drm-bochs/drm-bochs.scc
+
+# XHCI USB
+include features/usb/xhci-hcd.scc
+include features/net/net.scc
+include features/pci/pci.scc
+include cfg/net/mdio.scc
-- 
2.44.0


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

Re: [yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Khem Raj]

; compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.49.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.5.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.50.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.51.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.52.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.53.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.54.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.55.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.56.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.57.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.58.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.59.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.6.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.60.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.61.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.62.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.63.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.64.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.65.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.66.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.67.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.68.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.69.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.7.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.70.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.71.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.72.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.73.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.74.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.75.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.76.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.77.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.78.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.79.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.8.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.80.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.81.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.82.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.83.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.84.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.85.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.86.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.87.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.88.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.89.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.9.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.90.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.91.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.92.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.93.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.94.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.95.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.96.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.97.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.98.rcgu.o
>>> compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.99.rcgu.o
>>>
>>>
>>>
>>> On Sat, Feb 24, 2024 at 6:06 PM Khem Raj  wrote:
>>>>
>>>> try to run ar x on the .a file and see what objects it contains.
>>>>
>>>> On Fri, Feb 23, 2024 at 5:51 PM Joel Winarske  
>>>> wrote:
>>>> >
>>>> > Running readelf -h on the file does work and it shows that it is indeed 
>>>> > the correct machine architecture
>>>> >
>>>> > ELF Header:
>>>> >   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>>>> >   Class: ELF64
>>>> >   Data:  2's complement, little endian
>>>> >   Version:   1 (current)
>>>> >   OS/ABI:UNIX - System V
>>>> >   ABI Version:   0
>>>> >   Type:  REL (Relocatable file)
>>>> >   Machine:   AArch64
>>>> >   Version:   0x1
>>>> >   Entry point address:   0x0
>>>> >   Start of program headers:  0 (bytes into file)
>>>> >   Start of section headers:  201744 (bytes into file)
>>>> >   Flags: 0x0
>>>> >   Size of this header:   64 (bytes)
>>>> >   Size of program headers:   0 (bytes)
>>>> >   Number of program headers: 0
>>>> >   Size of section headers:   64 (bytes)
>>>> >   Number of section headers: 165
>>>> >   Section header string table index: 1
>>>> >
>>>> >
>>>> > On Fri, Feb 23, 2024 at 5:40 PM Joel Winarske  
>>>> > wrote:
>>>> >>
>>>> >> I'm hitting qa issue when attempting to install a archive file built 
>>>> >> with Rust:
>>>> >>
>>>> >> dwarfsrcfiles: 
>>>> >> /home/joel/agl/raspberrypi4/tmp/work/aarch64-agl-linux/rive-taffy-ffi/0.3.0-r0/package/usr/lib/taffy_ffi/libtaffy_ffi.a:
>>>> >>  not a valid ELF file
>>>> >>
>>>> >> I can link this same archive file with C code and the executable runs.  
>>>> >> It's a valid archive.
>>>> >>
>>>> >> Any suggestions?
>>>> >
>>>> >
>>>> >
>>>> >
>>>
>>>
>>>
>>>
>>
>>
>>
>
> 
>

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

Re: [yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Khem Raj]

try to run ar x on the .a file and see what objects it contains.

On Fri, Feb 23, 2024 at 5:51 PM Joel Winarske  wrote:
>
> Running readelf -h on the file does work and it shows that it is indeed the 
> correct machine architecture
>
> ELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF64
>   Data:  2's complement, little endian
>   Version:   1 (current)
>   OS/ABI:UNIX - System V
>   ABI Version:   0
>   Type:  REL (Relocatable file)
>   Machine:   AArch64
>   Version:   0x1
>   Entry point address:   0x0
>   Start of program headers:  0 (bytes into file)
>   Start of section headers:  201744 (bytes into file)
>   Flags: 0x0
>   Size of this header:   64 (bytes)
>   Size of program headers:   0 (bytes)
>   Number of program headers: 0
>   Size of section headers:   64 (bytes)
>   Number of section headers: 165
>   Section header string table index: 1
>
>
> On Fri, Feb 23, 2024 at 5:40 PM Joel Winarske  wrote:
>>
>> I'm hitting qa issue when attempting to install a archive file built with 
>> Rust:
>>
>> dwarfsrcfiles: 
>> /home/joel/agl/raspberrypi4/tmp/work/aarch64-agl-linux/rive-taffy-ffi/0.3.0-r0/package/usr/lib/taffy_ffi/libtaffy_ffi.a:
>>  not a valid ELF file
>>
>> I can link this same archive file with C code and the executable runs.  It's 
>> a valid archive.
>>
>> Any suggestions?
>
>
> 
>

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

[linux-yocto] [yocto-kernel-cache][PATCH] qemuriscv32/qemuriscv64: Enable Goldfish RTC

[Khem Raj]

This is required for the qemu based riscv system to set system time
correctly. Otherwise, it falls back to defaults in /etc/timestamp which
is set at image build time and is not current.

Fixes
hwclock: can't open '/dev/misc/rtc': No such file or directory
Fri Mar  9 12:34:56 UTC 2018
hwclock: can't open '/dev/misc/rtc': No such file or directory
hwclock: can't open '/dev/misc/rtc': No such file or directory

Signed-off-by: Khem Raj 
---
 bsp/qemuriscv32/qemuriscv32.cfg | 6 ++
 bsp/qemuriscv64/qemuriscv64.cfg | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/bsp/qemuriscv32/qemuriscv32.cfg b/bsp/qemuriscv32/qemuriscv32.cfg
index 36cadb51..ae1dd6f3 100644
--- a/bsp/qemuriscv32/qemuriscv32.cfg
+++ b/bsp/qemuriscv32/qemuriscv32.cfg
@@ -41,3 +41,9 @@ CONFIG_VIRTIO_CONSOLE=y
 # IRQ chip support
 #
 CONFIG_SIFIVE_PLIC=y
+
+#
+# Enable Goldfish RTC
+#
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_GOLDFISH=y
diff --git a/bsp/qemuriscv64/qemuriscv64.cfg b/bsp/qemuriscv64/qemuriscv64.cfg
index 0d51803b..5dcfbe63 100644
--- a/bsp/qemuriscv64/qemuriscv64.cfg
+++ b/bsp/qemuriscv64/qemuriscv64.cfg
@@ -37,3 +37,9 @@ CONFIG_VIRTIO_CONSOLE=y
 # IRQ chip support
 #
 CONFIG_SIFIVE_PLIC=y
+
+#
+# Enable Goldfish RTC
+#
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_GOLDFISH=y
-- 
2.43.2


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

Re: [yocto] initramfs and system logs

[Khem Raj]

On Wed, Jan 17, 2024 at 5:43 AM jguittet.opensource via
lists.yoctoproject.org
 wrote:
>
> Dear community,
>
> I'm currently building a professional yocto project.
> There are 2 variants of the image I'm building: the first one is using 
> classical rootfs on SD card (dev and test purpose). The other one is building 
> an initramfs fitImage (production). I'm using INITRAMFS_IMAGE to indicate the 
> name of the recipe building the initramfs + INITRAMFS_IMAGE_BUNDLE = "1".
>
> Problem I get is that the initramfs image produces no logs (except kernel 
> logs) in the console while the dev with the rootfs on the SD card have logs 
> printed in the console. I don't understand why and where I should patch to 
> have logs. The wanted logs are logs from init.d scripts for example (creating 
> ssh keys, setting hwclock etc) + logs from my own applications that are 
> properly output on the serial console with the "classic" image.

check if /dev/console is created in the initramfs init script which
runs as /sbin/init

>
> Thanks for any feedbacks!
> Joel
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62179): https://lists.yoctoproject.org/g/yocto/message/62179
Mute This Topic: https://lists.yoctoproject.org/mt/103785822/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] remove adding all kernel modules by default

[Khem Raj]

On Mon, Jan 15, 2024 at 4:57 AM Quentin Schulz  wrote:
>
> Hi Trevor,
>
> On January 14, 2024 3:46:18 PM GMT+01:00, Trevor Woerner  
> wrote:
> >A BSP layer shouldn't be deciding to include all kernel modules. That's more
> >of a distro decision, or for local.conf at a minimum. Modules that are
> >required for the basic functioning of a board are fine, but doing a blanket
> >"install all" is overreach and inflates images unnecessarily (~45MB, by one
> >measurement).
> >
>
> It's only a RRECOMMENDS, so I'd say this is fine as is? This allows to have a 
> working system without spending too much time figuring out what's exactly 
> needed. If someone needs to have a smaller image, they can then play with 
> kernel defconfig or kernel-modules- in packages to install.
>

Yeah on one thought, BSP users may not be well versed in OE speak and
this adds to their bad starting experience but it also has a bad
effect where the images are bloated. So IMO if it is well documented
how to enable/disable it easily could be useful. I don't have strong
leanings
on which way you want to go w.r.t defaults.

> Up to you though :)
>
> Cheers,
> Quentin
>
> >I expect patches will probably roll in after this one to add back necessary
> >modules, but it will be easier to figure out which ones when starting with
> >having none of them included by default.
> >
> >Signed-off-by: Trevor Woerner 
> >---
> > conf/machine/include/rock-pi-4.inc | 2 --
> > conf/machine/nanopi-m4b.conf   | 2 --
> > conf/machine/nanopi-r2s.conf   | 1 -
> > conf/machine/nanopi-r4s.conf   | 2 --
> > conf/machine/rock-5a.conf  | 1 -
> > conf/machine/rock-5b.conf  | 1 -
> > conf/machine/rock-pi-e.conf| 1 -
> > conf/machine/rock-pi-s.conf| 1 -
> > 8 files changed, 11 deletions(-)
> >
> >diff --git a/conf/machine/include/rock-pi-4.inc 
> >b/conf/machine/include/rock-pi-4.inc
> >index 0a868463bc64..02dfb18fc775 100644
> >--- a/conf/machine/include/rock-pi-4.inc
> >+++ b/conf/machine/include/rock-pi-4.inc
> >@@ -2,5 +2,3 @@
> > MACHINEOVERRIDES =. "rock-pi-4:"
> >
> > require conf/machine/include/rk3399.inc
> >-
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >diff --git a/conf/machine/nanopi-m4b.conf b/conf/machine/nanopi-m4b.conf
> >index 35cd8f68e82e..b924b0018867 100644
> >--- a/conf/machine/nanopi-m4b.conf
> >+++ b/conf/machine/nanopi-m4b.conf
> >@@ -5,7 +5,5 @@
> >
> > require conf/machine/include/rk3399.inc
> >
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >-
> > KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4b.dtb"
> > UBOOT_MACHINE = "nanopi-m4b-rk3399_defconfig"
> >diff --git a/conf/machine/nanopi-r2s.conf b/conf/machine/nanopi-r2s.conf
> >index 4472c21f0217..0451002ecff5 100644
> >--- a/conf/machine/nanopi-r2s.conf
> >+++ b/conf/machine/nanopi-r2s.conf
> >@@ -6,6 +6,5 @@
> > require conf/machine/include/rk3328.inc
> >
> > KERNEL_DEVICETREE = "rockchip/rk3328-nanopi-r2s.dtb"
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >
> > UBOOT_MACHINE = "nanopi-r2s-rk3328_defconfig"
> >diff --git a/conf/machine/nanopi-r4s.conf b/conf/machine/nanopi-r4s.conf
> >index 21be4400c89d..161f4b4e4609 100644
> >--- a/conf/machine/nanopi-r4s.conf
> >+++ b/conf/machine/nanopi-r4s.conf
> >@@ -5,7 +5,5 @@
> >
> > require conf/machine/include/rk3399.inc
> >
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >-
> > KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-r4s.dtb"
> > UBOOT_MACHINE = "nanopi-r4s-rk3399_defconfig"
> >diff --git a/conf/machine/rock-5a.conf b/conf/machine/rock-5a.conf
> >index 5ace4dac8fe4..28e06486eda3 100644
> >--- a/conf/machine/rock-5a.conf
> >+++ b/conf/machine/rock-5a.conf
> >@@ -7,6 +7,5 @@ require conf/machine/include/rk3588s.inc
> >
> > PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> > KERNEL_DEVICETREE = "rockchip/rk3588s-rock-5a.dtb"
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >
> > UBOOT_MACHINE = "rock5a-rk3588s_defconfig"
> >diff --git a/conf/machine/rock-5b.conf b/conf/machine/rock-5b.conf
> >index d1371084becc..ea2cf219e153 100644
> >--- a/conf/machine/rock-5b.conf
> >+++ b/conf/machine/rock-5b.conf
> >@@ -7,6 +7,5 @@ require conf/machine/include/rk3588.inc
> >
> > PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> > KERNEL_DEVICETREE = "rockchip/rk3588-rock-5b.dtb"
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >
> > UBOOT_MACHINE = "rock5b-rk3588_defconfig"
> >diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf
> >index 517956c4b9db..1e2169b01993 100644
> >--- a/conf/machine/rock-pi-e.conf
> >+++ b/conf/machine/rock-pi-e.conf
> >@@ -6,6 +6,5 @@
> > require conf/machine/include/rk3328.inc
> >
> > KERNEL_DEVICETREE = "rockchip/rk3328-rock-pi-e.dtb"
> >-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >
> > UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"
> >diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf
> >index 79ea73c6b47e..3aa868b7ec7c 100644
> >--- a/conf/machine/rock-pi-s.conf
> >+++ b/conf/machine/rock-pi-s.conf
> >@@ -6,6 

Re: [yocto] do_install_append syntax error

[Khem Raj]

change do_install_append to do_install:append

On Sun, Jan 14, 2024 at 11:09 AM Crane  wrote:
>
> Hello,
>
> I am adding a systemd service. It always complains
>
> Variable do_install_append contains an operation using the old override 
> syntax. Please convert this layer/metadata before attempting to use with a 
> newer bitbake.
>
> Already changed _ to :. Anyone can help with this?
>
> Thanks!
> Crane
>
> The recipe is like this:
>
> SUMMARY = "init service at boot"
>
> LICENSE = "CLOSED"
>
>
>
> inherit systemd
>
>
>
> SRC_URI += "file://farview.service"
>
> S = "${WORKDIR}"
>
>
>
> SYSTEMD_AUTO_ENABLE:${PN} = "enable"
>
> SYSTEMD_PACKAGES = "${PN}"
>
> SYSTEDD_SERVICE:${PN} = "farview.service"
>
>
>
> do_install_append() {
>
> install -d ${D}${systemd_system_unitdir}
>
> install -m 0644 ${WORKDIR}/farview.service ${D}${systemd_system_unitdir}
>
> }
>
>
>
> FILES:{PN} += "${systemd_system_unitdir}/farview.service"
>
> REQUIRED_DISTRO_FEATURES = " systemd"
>
>
> 
>

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

Re: [yocto] sd-bus.h not found even with DEPENDS += "systemd"

[Khem Raj]

I do not understand when you have multilib disabled then how can a target
binary embed /lib64/ld-linux-x86_64.so.2  as desired dynamic linker. it
would be understood if multilib was enabled.

On Wed, Jan 10, 2024 at 9:11 AM  wrote:

> seems it is blank, I get below output on running bitbake-getvar MULTILIBS
>
> 
>
>

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

Re: [yocto] Problem with overlayed recipes

[Khem Raj]

On Tue, Jan 9, 2024 at 7:22 AM Daniele Lugli  wrote:
>
> Thank you for your reply.
>
> I replaced the content of mytest-image.bb with that of 
> meta-intel/recipes-rt/images/core-image-rt-sdk.bb and added
>
> IMAGE_INSTALL += "simple-local"
>
> at the end. This way I get a bootable wic, but find / -name simple-local 
> finds nothing.

It could be that above IMAGE_INSTALL did not get effective. Check

bitbake-getvar -r mytest-image  IMAGE_INSTALL

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

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

Re: [yocto] How to share a directory between an x86_64 host and a Yocto Dunfell guest? #bitbake #imx8 #poky #qemu #ubuntu #yocto

[Khem Raj]

https://wiki.qemu.org/Documentation/9psetup might help.

On Thu, Jan 4, 2024 at 3:50 PM Myles Dear  wrote:
>
> Hello,
>
> I successfully built my Yocto Poky 3.1.30 binary on my x86_64 build host 
> (running Ubuntu 20.04.6 LTS) and launched via QEMU.  So far so good.
>
> I now wish to share a host directory with my guest OS, but hit a limitation 
> that neither the 9pnet nor the 9pnet_virtio drivers required for sharing 
> appear to be installed on either side.
>
> I may be able to install these drivers on my host, but when I tried the 
> "bitbake -c menuconfig virtual/kernel" command on my build host, and 
> navigated to the File systems / Pseudo filesystems, I did not see any Plan 9 
> kernel modules available.
>
> Am I missing something here?  Is it possible to share folders between host 
> and guest?
>
> Could you recommend next steps ?
>
>
>
> Many thanks.
>
>
> 
>

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

Re: [yocto] [meta-rockchip] [PATCH] use MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to add kernel-modules

[Khem Raj]

do you see same issue with core-image-base ?

On Wed, Jan 3, 2024 at 10:18 PM Stephen Chen  wrote:
>
> I revert the patch, and run command, MACHINE=rock-5a bitbake-getvar 
> MACHINE_EXTRA_RRECOMMENDS
> And I get this:
>
> ### Shell environment set up for builds. ###
>
> You can now run 'bitbake '
>
> Common targets are:
> core-image-minimal
> core-image-full-cmdline
> core-image-sato
> core-image-weston
> meta-toolchain
> meta-ide-support
>
> You can also run generated qemu images with a command like 'runqemu 
> qemux86-64'.
>
> Other commonly useful commands are:
>  - 'devtool' and 'recipetool' handle common recipe tasks
>  - 'bitbake-layers' handles common layer tasks
>  - 'oe-pkgdata-util' handles common target package tasks
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> #
> # $MACHINE_EXTRA_RRECOMMENDS [3 operations]
> #   append 
> /tank/stephen/yocto-rockchip-mainline/meta-rockchip/conf/machine/rock-5a.conf:10
> # "kernel-modules"
> #   set 
> /tank/stephen/yocto-rockchip-mainline/openembedded-core/meta/conf/documentation.conf:283
> # [doc] "A list of machine-specific packages to install as part of the 
> image being built that are not essential for booting the machine. The image 
> being built has no build dependencies on the packages in this list."
> #   set? 
> /tank/stephen/yocto-rockchip-mainline/openembedded-core/meta/conf/bitbake.conf:897
> # ""
> # pre-expansion value:
> #   " kernel-modules"
> MACHINE_EXTRA_RRECOMMENDS=" kernel-modules"
>
> On Thu, Jan 4, 2024 at 12:40 PM, Khem Raj wrote:
>
> MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS should be used when you need a
> module to be pulled in to enable something always.
> so I think setting MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to pull in a
> meta package sounds a bit wrong. I wonder if you have something
> overriding MACHINE_EXTRA_RRECOMMENDS, please try
>
> bitbake-getvar MACHINE_EXTRA_RRECOMMENDS
>
> and check if it contains kernel-modules or not. Also check output of
> bitbake -e core-image-full-cmdline
> so see if kernel-modules are being pulled into image or not. bitbake
> -g core-image-full-cmdline might also help in finding the dependencies
> being pulled into image and their relations.
>
> On Wed, Jan 3, 2024 at 8:20 PM Stephen Chen  wrote:
>
>
> On Thu, Jan 4, 2024 at 05:27 AM, Trevor Woerner wrote:
>
> On Tue 2023-12-19 @ 07:23:52 PM, Stephen Chen wrote:
>
> This will add all built kernel modules to the image.
>
> Signed-off-by: Stephen Chen 
>
> diff --git a/conf/machine/include/rock-pi-4.inc 
> b/conf/machine/include/rock-pi-4.inc
> index 0a86846..fd9a9eb 100644
> --- a/conf/machine/include/rock-pi-4.inc
> +++ b/conf/machine/include/rock-pi-4.inc
> @@ -3,4 +3,4 @@ MACHINEOVERRIDES =. "rock-pi-4:"
>
> require conf/machine/include/rk3399.inc
>
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
> diff --git a/conf/machine/nanopi-m4b.conf b/conf/machine/nanopi-m4b.conf
> index 35cd8f6..01d5c59 100644
> --- a/conf/machine/nanopi-m4b.conf
> +++ b/conf/machine/nanopi-m4b.conf
> @@ -5,7 +5,7 @@
>
> I've tried this a couple times and a couple different ways and I can't figure
> out how what we already have (MACHINE_EXTRA_RRECOMMENDS) is any different from
> what you're proposing (MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS).
>
> Using a very basic, no-distro setup I've built core-image-minimal and
> core-image-base both with and without your patch and I see absolutely no
> difference in the list of installed packages
> (buildhistory/images/rock_5b/glibc/core-image-*/installed-packages.txt).
>
> All of meta-rockchip's machine/include/* files already include
> MACHINE_EXTRA_RRECOMMENDS, do you have a scenario where a build is not
> including all of the built kernel modules in an image?
>
> require conf/machine/include/rk3399.inc
>
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4b.dtb"
> UBOOT_MACHINE = "nanopi-m4b-rk3399_defconfig"
> diff --git a/conf/machine/nanopi-r2s.conf b/conf/machine/nanopi-r2s.conf
> index 4472c21..4ed3160 100644
> --- a/conf/machine/nanopi-r2s.conf
> +++ b/conf/ma

Re: [yocto] [meta-rockchip] [PATCH] use MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to add kernel-modules

[Khem Raj]

MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS should be used when you need a
module to be pulled in to enable something always.
so I think setting MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to pull in a
meta package sounds a bit wrong. I wonder if you have something
overriding MACHINE_EXTRA_RRECOMMENDS, please try

bitbake-getvar MACHINE_EXTRA_RRECOMMENDS

and check if it contains kernel-modules or not. Also check output of
bitbake -e core-image-full-cmdline
so see if kernel-modules are being pulled into image or not. bitbake
-g core-image-full-cmdline might also help in finding the dependencies
being pulled into image and their relations.

On Wed, Jan 3, 2024 at 8:20 PM Stephen Chen  wrote:
>
> On Thu, Jan 4, 2024 at 05:27 AM, Trevor Woerner wrote:
>
> On Tue 2023-12-19 @ 07:23:52 PM, Stephen Chen wrote:
>
> This will add all built kernel modules to the image.
>
> Signed-off-by: Stephen Chen 
>
> diff --git a/conf/machine/include/rock-pi-4.inc 
> b/conf/machine/include/rock-pi-4.inc
> index 0a86846..fd9a9eb 100644
> --- a/conf/machine/include/rock-pi-4.inc
> +++ b/conf/machine/include/rock-pi-4.inc
> @@ -3,4 +3,4 @@ MACHINEOVERRIDES =. "rock-pi-4:"
>
> require conf/machine/include/rk3399.inc
>
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
> diff --git a/conf/machine/nanopi-m4b.conf b/conf/machine/nanopi-m4b.conf
> index 35cd8f6..01d5c59 100644
> --- a/conf/machine/nanopi-m4b.conf
> +++ b/conf/machine/nanopi-m4b.conf
> @@ -5,7 +5,7 @@
>
> I've tried this a couple times and a couple different ways and I can't figure
> out how what we already have (MACHINE_EXTRA_RRECOMMENDS) is any different from
> what you're proposing (MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS).
>
> Using a very basic, no-distro setup I've built core-image-minimal and
> core-image-base both with and without your patch and I see absolutely no
> difference in the list of installed packages
> (buildhistory/images/rock_5b/glibc/core-image-*/installed-packages.txt).
>
> All of meta-rockchip's machine/include/* files already include
> MACHINE_EXTRA_RRECOMMENDS, do you have a scenario where a build is not
> including all of the built kernel modules in an image?
>
> require conf/machine/include/rk3399.inc
>
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4b.dtb"
> UBOOT_MACHINE = "nanopi-m4b-rk3399_defconfig"
> diff --git a/conf/machine/nanopi-r2s.conf b/conf/machine/nanopi-r2s.conf
> index 4472c21..4ed3160 100644
> --- a/conf/machine/nanopi-r2s.conf
> +++ b/conf/machine/nanopi-r2s.conf
> @@ -6,6 +6,6 @@
> require conf/machine/include/rk3328.inc
>
> KERNEL_DEVICETREE = "rockchip/rk3328-nanopi-r2s.dtb"
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> UBOOT_MACHINE = "nanopi-r2s-rk3328_defconfig"
> diff --git a/conf/machine/nanopi-r4s.conf b/conf/machine/nanopi-r4s.conf
> index 21be440..1a63a96 100644
> --- a/conf/machine/nanopi-r4s.conf
> +++ b/conf/machine/nanopi-r4s.conf
> @@ -5,7 +5,7 @@
>
> require conf/machine/include/rk3399.inc
>
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-r4s.dtb"
> UBOOT_MACHINE = "nanopi-r4s-rk3399_defconfig"
> diff --git a/conf/machine/rock-5a.conf b/conf/machine/rock-5a.conf
> index 5ace4da..53b56b1 100644
> --- a/conf/machine/rock-5a.conf
> +++ b/conf/machine/rock-5a.conf
> @@ -7,6 +7,6 @@ require conf/machine/include/rk3588s.inc
>
> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> KERNEL_DEVICETREE = "rockchip/rk3588s-rock-5a.dtb"
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> UBOOT_MACHINE = "rock5a-rk3588s_defconfig"
> diff --git a/conf/machine/rock-5b.conf b/conf/machine/rock-5b.conf
> index d137108..dc5fabc 100644
> --- a/conf/machine/rock-5b.conf
> +++ b/conf/machine/rock-5b.conf
> @@ -7,6 +7,6 @@ require conf/machine/include/rk3588.inc
>
> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> KERNEL_DEVICETREE = "rockchip/rk3588-rock-5b.dtb"
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> UBOOT_MACHINE = "rock5b-rk3588_defconfig"
> diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf
> index 517956c..3f83675 100644
> --- a/conf/machine/rock-pi-e.conf
> +++ b/conf/machine/rock-pi-e.conf
> @@ -6,6 +6,6 @@
> require conf/machine/include/rk3328.inc
>
> KERNEL_DEVICETREE = "rockchip/rk3328-rock-pi-e.dtb"
> -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"
> diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf
> index 79ea73c..590e972 100644
> --- a/conf/machine/rock-pi-s.conf
> +++ b/conf/machine/rock-pi-s.conf
> @@ -6,6 +6,6 

Re: [yocto] Nondeterministic errors with bitbake

[Khem Raj]

What is the configuration of this system ? CPU and memory specifically one
likely reason is that you have oom hitting the system because it’s
overloaded so check the system logs for any indication of this

On Tue, Jan 2, 2024 at 1:49 PM  wrote:

> Hi all and best wishes for the new year.
>
> I recently worked with nanbield on Ubuntu 22.04.3 in a VirtualBox machine.
> I added layers meta-intel and meta-realtime and, with a couple of small
> modifications to core-image-rt-extended.bb and to rt-app.bb, as suggested
> by some kind reader (see
> https://lists.yoctoproject.org/g/yocto/topic/103135158), and after a
> couple of restarts, I could obtain the image, prepare a .vdi from the .wic
> and boot a virtual machine with that disk.
>
> Now I moved to a physical machine with Ubuntu 22.04.3. Here is the build
> configuration:
>
> BB_VERSION   = "2.6.1"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "x86_64-poky-linux"
> MACHINE  = "genericx86-64"
> DISTRO   = "poky"
> DISTRO_VERSION   =
> "4.3+snapshot-b92406d2313234dccd77b05fe74c09ba9617a738"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta
> meta-poky
> meta-yocto-bsp   = "master:b92406d2313234dccd77b05fe74c09ba9617a738"
> meta-oe  = "master:10f1890af03dbb804bffd4fa7eda7729e08f12cb"
> meta-intel   = "master:5cfefd9a8ff1f5a3534c1ba9d7d7f6971ed5d56f"
> meta-realtime= "master:489e1d6b34e46f845a4bfe6461a39c6a4bcb7794"
>
> I am using exactly the same configuration as in the virtual Ubuntu and I
> have also applied the suggested modifications to core-image-rt-extended.bb
> and to rt-app.bb. So the situation should be the same.
>
> I cannot understand why I am getting error messages which look random:
> when, after the error, I rerun bitbake, I get a different error.
>
> As an instance, in the first run of bitbake core-image-extended.bb I get:
>
> |
> /home/daniele/poky/build/tmp/work/x86_64-linux/cmake-native/3.27.7/cmake-3.27.7/Source/cmComputeComponentGraph.cxx:139:1:
> internal compiler error: Segmentation fault
> |   139 | }
> |   | ^
> | 0x7fc36ca4251f ???
> | ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
> | 0x7fc36ca29d8f __libc_start_call_main
> | ../sysdeps/nptl/libc_start_call_main.h:58
> | 0x7fc36ca29e3f __libc_start_main_impl
> | ../csu/libc-start.c:392
> | Please submit a full bug report,
> | with preprocessed source if appropriate.
> ...
> Summary: 1 task failed:
>   /home/daniele/poky/meta/recipes-devtools/cmake/cmake-native_3.27.7.bb:
> do_compile
>
> Second attempt, without any modification. I get a different error:
>
> ERROR: Task
> (virtual:native:/home/daniele/poky/meta/recipes-devtools/python/python3_3.11.5.bb:do_install)
> failed with exit code '139'
> NOTE: Tasks Summary: Attempted 3568 tasks of which 3518 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> virtual:native:/home/daniele/poky/meta/recipes-devtools/python/python3_3.11.5.
>
> Third attempt, always without modifications. Still different:
>
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> ERROR: Task 
> (/home/daniele/poky/meta/recipes-devtools/gcc/gcc_13.2.bb:do_compile)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 6049 tasks of which 3567 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>   /home/daniele/poky/meta/recipes-devtools/gcc/gcc_13.2.bb:do_compile
> Summary: There were 2 ERROR messages, returning a non-zero exit code.
>
> And so on. Fourth attempt:
>
> ERROR: Task
> (/home/daniele/poky/meta-realtime/recipes-extended/images/core-image-rt-extended.bb:do_rootfs)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 6700 tasks of which 6052 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /home/daniele/poky/meta-realtime/recipes-extended/images/core-image-rt-extended.bb:
> do_rootfs
> Summary: There was 1 ERROR message, returning a non-zero exit code.
>
> How is this possible? Problems in the communication with the server, or
> what?
>
> Thank you in advance and best regards
>
> --
> 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
>
> 
>
>

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

Re: [yocto] I get an error with bitbake when a program requires libgpiod.

[Khem Raj]

On Mon, Dec 25, 2023 at 6:58 AM Stephen Chen  wrote:

> Hi
>
> I don't know how to reproduce your issue.
> But to add libgpiod, you can add the following lines to your
> build/conf/local.conf
>
> IMAGE_INSTALL:append = " \
> libgpiod \
> libgpiod-dev \
> libgpiod-tools \
> "
>

-dev and -tools may not be required so just use libgpiod to begin with

>
> 
>
>

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

Re: [yocto] sd-bus.h not found even with DEPENDS += "systemd"

[Khem Raj]

On Tue, Dec 19, 2023 at 12:08 AM  wrote:
>
> Was this issue resolved? Even I am facing same issue and not able to figure 
> out the solution on how to resolve sd-bus dependency

can you check if sd-bus.h is in the recipe sysroot ? and if yes whats
the path to it, is your package adding the needed path to CLFLAGS via
-I ?

> 
>

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

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-5.0_M1.rc3)

[Khem Raj]

On Mon, Dec 18, 2023 at 9:17 AM Richard Purdie
 wrote:
>
> On Mon, 2023-12-18 at 14:43 +, Pokybuild User wrote:
> > A build flagged for QA (yocto-5.0_M1.rc3) was completed on the 
> > autobuilder and is available at:
> >
> >
> > https://autobuilder.yocto.io/pub/releases/yocto-5.0_M1.rc3
> >
> >
> > Build URL: 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6345
> >
> > Build hash information:
> >
> > bitbake: 8295ac1b6672c25bee595cff6e000b2af817f904
> > meta-agl: 266ac5373b4458d7fcb78b1e8948eb2b33f18b5d
> > meta-arm: e6e7ac4d99f103d26a0ffefd6d0a5d2deef5b17c
> > meta-aws: 7915e6bafd876ab3d654a26629dbf501479caae0
> > meta-intel: 5cfefd9a8ff1f5a3534c1ba9d7d7f6971ed5d56f
> > meta-mingw: e01d47d183945caeaf3c5c086539af0a925ddc32
> > meta-openembedded: 0a0ea87b8dda01a2887a525cef78eb6c3f4c2c32
> > meta-virtualization: caa14c63f158fdd13382ccf1ff4e20a8ba6ad667
> > oecore: 6b729088dce302eb3a967cb6839f00488025be0e
> > poky: 33112178d164ddd9ef0b1115c254ad4341ec3ad1
> >
> >
> >
> > This is an automated message from the Yocto Project Autobuilder
> > Git: git://git.yoctoproject.org/yocto-autobuilder2
> > Email: richard.pur...@linuxfoundation.org
> >
>
> There was one autobuilder failure against this build in qemux86 but it
> is a known issue where we're waiting for upstream to merge a kernel fix
> for alternatives handling. I believe we can proceed for QA and it does
> not block release.
>
> I'd also note the regression report generation was successful :)
>

cool. LGTM also.

> Cheers,
>
> Richard
>
> 
>

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

Re: [yocto] Update the yocto dunfell to latest version

[Khem Raj]

On Sun, Dec 17, 2023 at 11:37 PM MOHAMMED HASSAN
 wrote:
>
> Hi guys,
> Can you suggest some resources for me to update to the latest yocto dunfell 
> version. Currently I am using dunfell 3.1.11 and want to update to 3.1.29.
> What could be the consequences?

This will be relatively safer to do since point releases do not
contain major features and essentially are bug fixes and security
fixes. However, this is
not always the case that it will be smooth for you since there might
be a particular bugfix that could change a behavior which you might be
relying on
so needs some due diligence.

> Also If I manually update the nodejs folder to the latest one will it fetch 
> the latest nodejs files(example)?

This is your call and hence the problems you encounter will also be
unique to you. You might seek help in the community and if there are
some
folks who have tried what you will be doing you might find some support.

>
> Regards,
> Hassan
>
> 
>

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

Re: [yocto] Wireless interface (wlan) not shown on Raspberry Pi Zero W

[Khem Raj]

go into meta-raspberrypi checkout and then

then do
git cherry-pick 0917b60527242d3668efc2d3b918df64b13e7b6f

this should bring the one commit I am asking you to apply on top of kirkstone.

On Fri, Dec 15, 2023 at 3:35 PM Renato Mendes
 wrote:
>
>
> Sorry I’m confused… what exactly Khem asked to do - can you please elaborate. 
> Thanks.
>
> Em 15 de dez. de 2023, à(s) 18:51, Martin Jansa  
> escreveu:
>
> 
> > Am I doing the backport correctly? Maybe config file problems?
>
> You've backported different commit than what Khem asked you to try.
>
> On Fri, Dec 15, 2023 at 10:33 PM Renato Mendes  
> wrote:
>>
>> So Khem, that's what I've done:
>>
>> Load from git and backport:
>>
>> git clone -b kirkstone git://git.yoctoproject.org/poky ./src/poky
>> git clone -b kirkstone git://git.openembedded.org/meta-openembedded 
>> ./src/meta-openembedded
>>
>> git clone -b kirkstone git://git.yoctoproject.org/meta-raspberrypi 
>> ./src/meta-raspberrypi
>> git checkout master
>> git checkout kiskstone
>> git cherry-pick master
>> Auto-merging docs/extra-build-config.md
>> Auto-merging recipes-bsp/bootfiles/rpi-cmdline.bb
>> [kirkstone a900a5e] rpi-cmdline, rpi-u-boot-src: Support USB boot
>>  Author: Harunobu Kurokawa 
>>  Date: Fri May 5 14:49:51 2023 +0900
>>  Committer: quadfloor 
>> Your name and email address were configured automatically based
>> on your username and hostname. Please check that they are accurate.
>> You can suppress this message by setting them explicitly. Run the
>> following command and follow the instructions in your editor to edit
>> your configuration file:
>>
>> git config --global --edit
>>
>> After doing this, you may fix the identity used for this commit with:
>>
>> git commit --amend --reset-author
>>
>>  4 files changed, 24 insertions(+), 3 deletions(-)
>>
>> Configuration:
>>
>> After that, rebuilt with the short configuration:
>>
>> MACHINE = "raspberrypi0-wifi"
>> SERIAL_CONSOLE = ""
>> DISABLE_RPI_BOOT_LOGO = "1"
>> DISABLE_OVERSCAN = "1"
>> DISABLE_SPLASH = "1"
>> BOOT_DELAY = "0"
>> GPU_MEM_256 = "128"
>> GPU_MEM_512 = "196"
>> GPU_MEM_1024 = "396"
>> PACKAGE_CLASSES = "package_ipk"
>> DISTRO_FEATURES:append = " wifi "
>> IMAGE_INSTALL:append = " linux-firmware-bcm43430 wpa-supplicant"
>> IMAGE_FSTYPES = "tar.bz2 ext4 rpi-sdimg"
>> SDIMG_ROOTFS_TYPE = "ext4"
>>
>>
>> $ cat bblayers.conf
>> # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
>> # changes incompatibly
>> POKY_BBLAYERS_CONF_VERSION = "2"
>>
>> BBPATH = "${TOPDIR}"
>> BBFILES ?= ""
>>
>> BBLAYERS ?= " \
>>   /home/quadfloor/release_1/src/poky/meta \
>>   /home/quadfloor/release_1/src/poky/meta-poky \
>>   /home/quadfloor/release_1/src/poky/meta-yocto-bsp \
>>   /home/quadfloor/release_1/src/meta-openembedded/meta-oe \
>>   /home/quadfloor/release_1/src/meta-openembedded/meta-python \
>>   /home/quadfloor/release_1/src/meta-openembedded/meta-multimedia \
>>   /home/quadfloor/release_1/src/meta-openembedded/meta-networking \
>>   /home/quadfloor/release_1/src/meta-raspberrypi \
>>   "
>>
>> Result:
>> $ ifcofing -a -> Only lo interface, no wlan
>>
>> $ dmesg | grep brcmfmac shows nothing
>> $ dmesg | grep wlan shows nothing
>>
>> $ lsmod
>> Module  Size Used  by
>> nfsd   45465611
>>
>> So, basically the same
>>
>> Am I doing the backport correctly? Maybe config file problems?
>>
>> Thanks for supporting...
>>
>> 
>>

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

Re: [yocto] how to create symlink in dunfell after compilation of library file

[Khem Raj]

On Fri, Dec 15, 2023 at 10:01 AM Ron Eggler  wrote:
>
>
> On 2023-12-14 5:25 p.m., Khem Raj wrote:
>
>
>
> On Thu, Dec 14, 2023 at 5:13 PM Ron Eggler  wrote:
>>
>>
>> On 2023-12-14 5:00 p.m., Khem Raj wrote:
>>
>> On Thu, Dec 14, 2023 at 4:26 PM Mistyron  wrote:
>>
>> Hi,
>>
>> I'm working with dunfell and want to create a symlink after compilation
>> of the library:
>>
>> I added the following in aziot-keys_%.bbapend:
>>
>> do_install_append() {
>>  install -d ${D}/usr/lib
>>  lnr ${D}/usr/lib64/rust/libaziot_keys.so ${D}/usr/lib/libaziot_keys.so
>>
>> try using ln -rs instead of lnr.
>>
>> With ln -rs I get the following error:
>>
>> ERROR: aziot-keys-1.4.7.AUTOINC+91e058880c-r0 do_package: QA Issue: 
>> aziot-keys: Files/directories were installed but not shipped in any package: 
>>  
>>  
>>  
>>  /usr/lib
>>  
>>  
>>  
>>  
>>  
>>   /usr/lib/libaziot_keys.so
>
>
> Right so you need to add /usr/lib to FILES variable
>
>
> Right, so I've updated my recipe to:
>
> FILES_${PN} += "/usr/lib" do_install_append() { install -d ${D}/usr/lib cd 
> ${D}/usr/lib lnr ${D}../lib64/rust/libaziot_keys.so libaziot_keys.so }
>
> With this I don't get any errors nor warnings but the symlink does not get 
> created.
>
> I tried to replace lnr with ln -sr but am getting errors with that:
>
> ERROR: aziot-keys-1.4.7.AUTOINC+91e058880c-r0 do_package_qa: QA Issue: non 
> -dev/-dbg/nativesdk- package aziot-keys contains symlink .so 
> '/usr/lib/libaziot_keys.so' [dev-so] ERROR: 
> aziot-keys-1.4.7.AUTOINC+91e058880c-r0 do_package_qa: Error executing a 
> python function in exec_func_python() autogenerated: The stack trace of 
> python calls that resulted in this exception/failure was: File: 
> 'exec_func_python() autogenerated', lineno: 2, function:  ... ... 
> Exception: FileNotFoundError: [Errno 2] No such file or directory: 
> '/home/yocto/rzv_vlp_v3.0.0/build/tmp/work/aarch64-poky-linux/aziot-keys/1.4.7.AUTOINC+91e058880c-r0/packages-split/aziot-keys/usr/lib/libaziot_keys.so'
>  ERROR: Logfile of failure stored in: 
> /home/yocto/rzv_vlp_v3.0.0/build/tmp/work/aarch64-poky-linux/aziot-keys/1.4.7.AUTOINC+91e058880c-r0/temp/log.do_package_qa.88151
>  ERROR: Task 
> (/home/yocto/rzv_vlp_v3.0.0/build/../meta-iotedge/recipes-core/aziot-keys/aziot-keys_1.4.7.bb:do_package_qa)
>  failed with exit code '1'
>
> But I do wonder if your link should be inside ${libdir} which is /usr/lib64 
> in your case
>
> I don't think so as after boot, I can create the link with:
>
> # ln -s /usr/lib64/rust/libaziot_keys.so /usr/lib/libaziot_keys.so
>>
>>
>> Please set FILES such that these items are packaged. Alternatively if they 
>> are unneeded, avoid installing them or delete them within do_install.
>> aziot-keys: 2 installed and not shipped files. [installed-vs-shipped]
>> ERROR: aziot-keys-1.4.7.AUTOINC+91e058880c-r0 do_package: Fatal QA errors 
>> found, failing task.
>> ERROR: Logfile of failure stored in: 
>> /home/yocto/rzv_vlp_v3.0.0/build/tmp/work/aarch64-poky-linux/aziot-keys/1.4.7.AUTOINC+91e058880c-r0/temp/log.do_package.64055
>> ERROR: Task 
>> (/home/yocto/rzv_vlp_v3.0.0/build/../meta-iotedge/recipes-core/aziot-keys/aziot-keys_1.4.7.bb:do_package)
>>  failed with exit code '1'

Add
INSANE_SKIP:${PN} += "dev-so"

>>
>> I came across a post that read that for dunfell, lnr shoudl be used (rather 
>> than ln -r for newer versions)
>>
>> }
>>
>> Yet, after building the image,
>> I do not see the symlink in/usr/lib/
>>
>> I did find the recipe for which I created the bbappend with:
>> oe-pkgdata-util find-path /usr/lib64/rust/libaziot_keys.so
>>
>> What is missing?
>>
>> Thank you,
>> Ron
>>
>> --
>> Mistyron
>>
>>
>> --
>> Mistyron
>>
>> 
>
> --
>
>
> RON EGGLER
> Firmware Engineer, Tech Lead
> (he/him/his)
> www.mistywest.com

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

Re: [yocto] Wireless interface (wlan) not shown on Raspberry Pi Zero W

[Khem Raj]

reread what I said.

On Fri, Dec 15, 2023 at 9:47 AM Renato Mendes
 wrote:
>
> I'm already on kirkstone:
>
> git clone -b kirkstone git://git.yoctoproject.org/meta-raspberrypi 
> ./src/meta-raspberrypi
>

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

Re: [yocto] Wireless interface (wlan) not shown on Raspberry Pi Zero W

[Khem Raj]

On Fri, Dec 15, 2023 at 9:38 AM Renato Mendes
 wrote:
>
> Hummm. got it. Could never imagine this situation :-)
>
> You mean backporting to dunfell? I'm currently on kirkstone

backport from master to kirkstone branch ( meta-raspberrypi )

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

Re: [yocto] Wireless interface (wlan) not shown on Raspberry Pi Zero W

[Khem Raj]

On Fri, Dec 15, 2023 at 9:26 AM Renato Mendes
 wrote:
>
> Thanks for helping...
>
> $ lsmod
> Module  Size   Used by
> nfsd   454656 11
>

yeah so no kernel modules could be the problem.
You said you are on kirkstone

Can you try backporting

https://github.com/agherzan/meta-raspberrypi/commit/0917b60527242d3668efc2d3b918df64b13e7b6f

to kirkstone and see if it helps. ?

> dmesg | grep brcmfmac shows nothing
> 
>

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

Re: [yocto] Wireless interface (wlan) not shown on Raspberry Pi Zero W

[Khem Raj]

On Fri, Dec 15, 2023 at 7:14 AM Renato Mendes
 wrote:
>
> I'm still struggling to solve that... I came up with a very basic 
> configuration on Yocto (using kirkstone):
>
>
>
> # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> POKY_BBLAYERS_CONF_VERSION = "2"
>
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
>
> BBLAYERS ?= " \
>   /home/quadfloor/release_1/src/poky/meta \
>   /home/quadfloor/release_1/src/poky/meta-poky \
>   /home/quadfloor/release_1/src/poky/meta-yocto-bsp \
>   /home/quadfloor/release_1/src/meta-openembedded/meta-oe \
>   /home/quadfloor/release_1/src/meta-openembedded/meta-python \
>   /home/quadfloor/release_1/src/meta-openembedded/meta-multimedia \
>   /home/quadfloor/release_1/src/meta-openembedded/meta-networking \
>   /home/quadfloor/release_1/src/meta-raspberrypi \
>   "
>
> local.conf:
>
> MACHINE = "raspberrypi0-wifi"
> SERIAL_CONSOLE = ""
> DISABLE_RPI_BOOT_LOGO = "1"
> DISABLE_OVERSCAN = "1"
> DISABLE_SPLASH = "1"
> BOOT_DELAY = "0"
> GPU_MEM_256 = "128"
> GPU_MEM_512 = "196"
> GPU_MEM_1024 = "396"
> PACKAGE_CLASSES = "package_ipk"
> DISTRO_FEATURES:append = " wifi "
> IMAGE_INSTALL:append = " linux-firmware-bcm43430 wpa-supplicant"
> IMAGE_FSTYPES = "tar.bz2 ext4 rpi-sdimg"
> SDIMG_ROOTFS_TYPE = "ext4"
>
> The error still persists: No wlan at all (ifconfig -a show only lo).

It seems that your system does not have wifi driver loaded. Can you
check output of
lsmod ?

secondly look what

dmesg | grep brcmfmac

says

>
> No idea where to go - project stuck and tigh deadline... Help very much 
> needed...
>
>
> 
>

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

Re: [yocto] how to create symlink in dunfell after compilation of library file

[Khem Raj]

On Thu, Dec 14, 2023 at 5:13 PM Ron Eggler  wrote:

>
> On 2023-12-14 5:00 p.m., Khem Raj wrote:
>
> On Thu, Dec 14, 2023 at 4:26 PM Mistyron  
>  wrote:
>
> Hi,
>
> I'm working with dunfell and want to create a symlink after compilation
> of the library:
>
> I added the following in aziot-keys_%.bbapend:
>
> do_install_append() {
>  install -d ${D}/usr/lib
>  lnr ${D}/usr/lib64/rust/libaziot_keys.so ${D}/usr/lib/libaziot_keys.so
>
> try using ln -rs instead of lnr.
>
> With ln -rs I get the following error:
>
> ERROR: aziot-keys-1.4.7.AUTOINC+91e058880c-r0 do_package: QA Issue:
> aziot-keys: Files/directories were installed but not shipped in any
> package:
> /usr/lib
> /usr/lib/libaziot_keys.so
>

Right so you need to add /usr/lib to FILES variable
But I do wonder if your link should be inside ${libdir} which is /usr/lib64
in your case

>
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> aziot-keys: 2 installed and not shipped files. [installed-vs-shipped]
> ERROR: aziot-keys-1.4.7.AUTOINC+91e058880c-r0 do_package: Fatal QA errors
> found, failing task.
> ERROR: Logfile of failure stored in:
> /home/yocto/rzv_vlp_v3.0.0/build/tmp/work/aarch64-poky-linux/aziot-keys/1.4.7.AUTOINC+91e058880c-r0/temp/log.do_package.64055
> ERROR: Task
> (/home/yocto/rzv_vlp_v3.0.0/build/../meta-iotedge/recipes-core/aziot-keys/aziot-keys_1.4.7.bb:do_package)
> failed with exit code '1'
>
> I came across a post that read that for dunfell, lnr shoudl be used
> (rather than ln -r for newer versions)
>
> }
>
> Yet, after building the image,
> I do not see the symlink in/usr/lib/
>
> I did find the recipe for which I created the bbappend with:
> oe-pkgdata-util find-path /usr/lib64/rust/libaziot_keys.so
>
> What is missing?
>
> Thank you,
> Ron
>
> --
> Mistyron
>
>
> --
> Mistyron
>
> 
>
>

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

Re: [yocto] how to create symlink in dunfell after compilation of library file

[Khem Raj]

On Thu, Dec 14, 2023 at 4:26 PM Mistyron  wrote:
>
> Hi,
>
> I'm working with dunfell and want to create a symlink after compilation
> of the library:
>
> I added the following in aziot-keys_%.bbapend:
>
> do_install_append() {
>  install -d ${D}/usr/lib
>  lnr ${D}/usr/lib64/rust/libaziot_keys.so ${D}/usr/lib/libaziot_keys.so

try using ln -rs instead of lnr.

> }
>
> Yet, after building the image,
> I do not see the symlink in/usr/lib/
>
> I did find the recipe for which I created the bbappend with:
> oe-pkgdata-util find-path /usr/lib64/rust/libaziot_keys.so
>
> What is missing?
>
> Thank you,
> Ron
>
> --
> Mistyron
>
>
> --
> Mistyron
>
> 
>

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

Re: [yocto] do_rootfs failed

[Khem Raj]

I think change below line

https://git.yoctoproject.org/meta-realtime/tree/recipes-extended/images/core-image-rt-extended.bb#n3
to

DEPENDS:append = " linux-yocto"

and see if this helps.

On Wed, Dec 13, 2023 at 10:36 AM  wrote:
>
> Thank you Alex.
> git branch --contains in poky/meta-realtime does not find the SRCREV 
> 17be4548c4260b80be623e0e1317e98a770dea7a in any branch
> Anyway I added ;branch=master;protocol=https to the SRC_URI in rt-app.bb and 
> the warnings disappeared. Good!
>
> Khem:
> I added
> DEPENDS:append = " qemuwrapper-cross"
> in core-image-rt-extended.bb
> and I have no more failure in the postinstall intercept hook; log.do_rootfs 
> is now clean. Good!
>
> Unluckily this isn't yet the conclusion. What I get now is:
>
> | ERROR: A native program mkfs.ext4 required to build the image was not found 
> (see details above).
> | Please make sure wic-tools have e2fsprogs-native in its DEPENDS, build it 
> with 'bitbake wic-tools' and try again
> ERROR: Task 
> (/home/vboxuser/Documents/poky/meta-realtime/recipes-extended/images/core-image-rt-extended.bb:do_image_wic)
>  failed with exit code '1'
>
> I verified that poky/meta/recipes-core/meta/wic-tools.bb already has 
> e2fsprogs-native in its dependecncies, issued 'bitbake wic-tools' then again 
> 'bitbake core-image-rt-extended' but mkfs.ext4 is still not found.
>
> I will now try a clean bitbake by removing sstate-cache and tmp.
>
> Any suggestion is appreciated.
>
> My best regards
>
> --
> 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
>
> 
>

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

Re: [yocto] do_rootfs failed

[Khem Raj]

On Tue, Dec 12, 2023 at 10:51 AM  wrote:
>
> Thank you Khem for your reply.
>
> From meta-poky/conf/distro/poky.conf:
> DISTRO = "poky"
> DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
> DISTRO_VERSION = "4.3+snapshot-${METADATA_REVISION}"
> DISTRO_CODENAME = "nanbield"
>
> From bitbake:
> Build Configuration:
> BB_VERSION   = "2.6.1"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "x86_64-poky-linux"
> MACHINE  = "genericx86-64"
> DISTRO   = "poky"
> DISTRO_VERSION   = "4.3+snapshot-4bb222e0d71a4cb159b8a4f1a90b65b1af32ac10"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta
> meta-poky
> meta-yocto-bsp   = "master:4bb222e0d71a4cb159b8a4f1a90b65b1af32ac10"
> meta-oe  = "master:5ad7203f68987461baaf2699378d0cf36c11d6c2"
> meta-intel   = "master:5cfefd9a8ff1f5a3534c1ba9d7d7f6971ed5d56f"
> meta-realtime= "master:489e1d6b34e46f845a4bfe6461a39c6a4bcb7794"
>
> Working on Ubuntu 22.04.3 in VirtualBox

this seems all good to me, I think somewhere dependency on
qemuwrapper-cross is being lost in your image recipe perhaps.
Add it with append and see if it helps. something like DEPENDS:append
= " qemuwrapper-cross" in core-image-rt-extended.bb
and see if that helps.

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

Re: [yocto] do_rootfs failed

[Khem Raj]

which release of yocto are you on. Its always good to include Build
Configuration that bitbake prints at the beginning. Secondly make sure
you are using tested distro on build host for that  release of yocto
for best results

On Tue, Dec 12, 2023 at 10:20 AM  wrote:
>
> Hello all,
> I am new to Yocto, so please be patient.
>
> I added layers meta-intel and meta-realtime to poky.
> Now
> bitbake core-image-rt-extended
> tells me:
>
> Summary: 1 task failed:
> /home/vboxuser/Documents/poky/meta-realtime/recipes-extended/images/core-image-rt-extended.bb:do_rootfs
>
> and at the end of log.do_rootfs I see:
>
> NOTE: Running intercept scripts:
> NOTE: > Executing update_gio_module_cache intercept ...
> NOTE: Exit code 127. Output:
> /home/vboxuser/Documents/poky/build/tmp/work/genericx86_64-poky-linux/core-image-rt-extended/1.0/intercept_scripts-4d6b1b8857aea9ead0c0757d1be3a10e464187681f98f3ad9c7448104f320d6e/update_gio_module_cache:
>  13: qemuwrapper: not found
> ERROR: The postinstall intercept hook 'update_gio_module_cache' failed, 
> details in 
> /home/vboxuser/Documents/poky/build/tmp/work/genericx86_64-poky-linux/core-image-rt-extended/1.0/temp/log.do_rootfs
>
> On the internet I can find some discussions about problems with qemuwrapper. 
> All very old, and none seem suitable.
>
> Do you have any suggestion?
>
> Thank you in advance,
>
> Daniele Lugli
>
>
> 
>

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

Re: [yocto] Static library created by recipe arch is not correct #sdk #yocto

[Khem Raj]

Can you run file command on libiobb.a it seems its not built for either 
correct architecture or is corrupted in SDK somehow.


It will be good to use AR/RANLIB/CC/CXX variables in your Makefile and 
weakly assign them e.g.


CC ?= cc

AR ?= ar

...


On 12/7/23 4:28 AM, Iurascu Teodor wrote:

Hello,

I have created a recipe to include the IOBB library in the SDK. Trying 
to compile a .c file in the SDK environment gives me this error:


$ ${CC} pb-test-inputs.c -liobb
/opt/poky/4.2.2/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/12.3.0/ld: 
/opt/poky/4.2.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/local/lib/libiobb.a: 
error adding symbols: file format not recognized


Recipe file:

do_compile () {
    # You will almost certainly need to add additional arguments here
    oe_runmake cc=${CC}
}

do_install () {
    # This is a guess; additional arguments may be required
    oe_runmake install locatie=${D}
    #rm ${D}/usr/local/lib/libiobb.a
}


Makefile:

libiobb.a: ${LIB_PATH}BBBiolib.c ${LIB_PATH}BBBiolib.h 
BBBiolib_PWMSS.o BBBiolib_McSPI.o BBBiolib_ADCTSC.o i2cfunc.o

${cc}-c ${LIB_PATH}BBBiolib.c -o ${LIB_PATH}BBBiolib.o
ar -rs ${LIB_PATH}libiobb.a ${LIB_PATH}BBBiolib.o 
${LIB_PATH}BBBiolib_PWMSS.o ${LIB_PATH}BBBiolib_McSPI.o 
${LIB_PATH}BBBiolib_ADCTSC.o ${LIB_PATH}i2cfunc.o


Thank you!






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

Re: [yocto] initramfs creation

[Khem Raj]

On Thu, Dec 7, 2023 at 3:04 AM Ross Burton  wrote:
>
> On 6 Dec 2023, at 21:47, mattwood2000 via lists.yoctoproject.org 
>  wrote:
> >
> >  Hi,
> >
> > I'm trying to create a custom initramfs to handle some things before 
> > switching root to my actual filesystem.  I followed the docs and have been 
> > able to use INITRAMFS_IMAGE = "custom-image" and INITRAMFS_IMAGE_BUNDLE = 
> > "1" to generate a zImage for my ARM platform.
> >
> > The custom-image.bb recipe is based on the core-image-minimal-initramfs 
> > recipe and is in a meta-layer that has another image recipe for the actual 
> > eMMC filesystem image.  Both the eMMC image and initramfs bundle are 
> > created.
> >
> > In custom-image.bb, PACKAGE_INSTALL includes INITRAMFS_SCRIPTS which seem 
> > to be geared towards live-image things but that's not what I want.
> >
> > The image boots but hangs waiting for removable media.  I figured out that 
> > /init is not pointing to systemd but the live-image script from 
> > recipes-core/initrdscripts.
>
> The problem is most likely that your kernel is missing eMMC drivers.  They’re 
> most likely built as kernel modules, but you didn’t install the modules into 
> the initramfs.  One easy fix is to just add kernel-modules to your initramfs.

Right, this is how we tame bbb to include some USB drivers into kernel
proper so that we can read the USB stick in initramfs

https://github.com/YoeDistro/yoe-distro/blob/master/sources/meta-yoe/dynamic-layers/meta-ti/recipes-kernel/linux/files/updater.cfg

>
> I do have some tweaks to the initramfs images to post, but they’re not quite 
> ready yet. You can see the WIP in poky-contrib:ross/genericarm64.
>
> Ross
> 
>

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

Re: [yocto] Mold linker

[Khem Raj]

On Tue, Dec 5, 2023 at 1:10 PM Randy MacLeod 
wrote:

> On 2023-02-15 2:22 a.m., Khem Raj via lists.yoctoproject.org wrote:
>
> On Tue, Feb 14, 2023 at 9:36 PM Joel Winarske  
>  wrote:
>
> Has anyone played around with the mold linker?
> https://github.com/rui314/mold
>
>
> Curious what the build time difference might be on a large multi-core machine.
>
> Yes, lightly. I found it similar to lld in many cases, only used it on
> native links for chromium
> it seems to be better at parallelization.
>
> Has anyone checked recently, there's been quite a bit of work since Feb
> 2023 (1)
>
> Narpat might try this out for Chromium.
>

Chromium builds use lld already in meta-browser so I am not expecting day
and night difference but it will be certainly good to know how much delta
it can reduce

>
> I'd expect that the overall build time isn't reduced much even on our 100+
> core systems
> since there are just soo many .cpp files to compile but it's worth
> checking.
>
> ../Randy
>
>
> 1)
>
> mold.git on main
> ❯ TZ=$(date +%z) git log --reverse --date-order --format="%cd"
> --date=iso-local 9615b8b962edc659f7113029c5c85a81b173e4dc... \
> | cut -d- -f1-2 \
> | uniq -c \
> | column -t \
> | perl -pwe 's{\s+}{\t}'
> 1452023-01
> 342023-02
> 372023-03
> 112023-04
> 122023-06
> 552023-07
> 1432023-08
> 432023-09
> 1052023-10
> 952023-11
> 122023-12
>
>  Joel
>
>
>
>
>
> 
>
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
>

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

Re: [yocto] [meta-mingw][kirkstone][PATCH] libxcrypt: fixed some build error for nativesdk with mingw

[Khem Raj]

On Thu, Nov 30, 2023 at 6:38 PM Kang Wenlin 
wrote:

>
> On 12/1/2023 00:54, Khem Raj wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
> >
> > On Thu, Nov 30, 2023 at 12:31 AM wenlin.k...@windriver.com via
> > lists.yoctoproject.org
> >  wrote:
> >> From: Wenlin Kang 
> >>
> >> Steps to reproduce
> >>1) add layer meta-mingw
> >>2) add line in local.conf
> >>   SDKMACHINE = "x86_64-mingw32"
> >>3) bitbake nativesdk-libxcrypt
> >>
> >> Fixed:
> >> 1. .symver error
> >>| {standard input}: Assembler messages:
> >>| {standard input}:4: Error: unknown pseudo-op: `.symver'
> >>
> >> 2. pedantic error
> >>| ../git/lib/crypt.c:316:24: error: ISO C does not allow extra ';'
> outside of a function [-Werror=pedantic]
> >>|   316 | SYMVER_crypt_gensalt_rn;
> >>|   |
> >>
> >> 3. conversion error
> >>| ../git/lib/util-get-random-bytes.c: In function
> '_crypt_get_random_bytes':
> >>| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from
> 'size_t' {aka 'long long unsigned int'} to 'unsigned int' may change value
> [-Werror=conversion]
> >>|   140 |   ssize_t nread = read (fd, buf, buflen);
> >>
> >> Signed-off-by: Wenlin Kang 
> >> ---
> >>   .../0001-Fix-for-compilation-on-Windows.patch | 37 +++
> >>   ...dom-bytes.c-fixed-conversion-error-w.patch | 47 +++
> >>   recipes-core/libxcrypt/libxcrypt_%.bbappend   |  7 +++
> >>   3 files changed, 91 insertions(+)
> >>   create mode 100644
> recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> >>   create mode 100644
> recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> >>   create mode 100644 recipes-core/libxcrypt/libxcrypt_%.bbappend
> >>
> >> diff --git
> a/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> >> new file mode 100644
> >> index 000..5760ee0
> >> --- /dev/null
> >> +++
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> >> @@ -0,0 +1,37 @@
> >> +From a507b628a5a5d4e4f1cf0f0a9a72967470ee7624 Mon Sep 17 00:00:00 2001
> >> +From: Brecht Sanders 
> >> +Date: Fri, 3 Feb 2023 08:44:49 +0100
> >> +Subject: [PATCH] Fix for compilation on Windows
> >> +
> >> +This fix allows the library to build on Windows (at least with
> MinGW-w64).
> >> +
> >> +`.symver` is only supported for ELF format but Windows uses COFF/PE.
> >> +
> >> +Workaround dummy define of `symver_set()`
> >> +
> >> +Upstream-Status: Backport [
> https://github.com/besser82/libxcrypt/commit/a507b628a5a5d4e4f1cf0f0a9a72967470ee7624
> ]
> >> +
> >> +Signed-off-by: Wenlin Kang 
> >> +---
> >> + lib/crypt-port.h | 5 +
> >> + 1 file changed, 5 insertions(+)
> >> +
> >> +diff --git a/lib/crypt-port.h b/lib/crypt-port.h
> >> +index f06ca24..a707939 100644
> >> +--- a/lib/crypt-port.h
> >>  b/lib/crypt-port.h
> >> +@@ -201,6 +201,11 @@ extern size_t strcpy_or_abort (void *dst, size_t
> d_size, const void *src);
> >> +   __asm__(".globl _" extstr);   \
> >> +   __asm__(".set _" extstr ", _" #intname)
> >> +
> >> ++#elif defined _WIN32
> >> ++
> >> ++/* .symver is only supported for ELF format, Windows uses COFF/PE */
> >> ++# define symver_set(extstr, intname, version, mode)
> >> ++
> >> + #elif defined __GNUC__ && __GNUC__ >= 3
> >> +
> >> + # define _strong_alias(name, aliasname) \
> >> +--
> >> +2.34.1
> >> +
> >> diff --git
> a/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> >> new file mode 100644
> >> index 000..3846f76
> >> --- /dev/null
> >> +++
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> >> @@ -0,0 +1,47 @@
> >> +From ff99091eb8a6b9e6edc567f6d2552183f

Re: [yocto] [meta-mingw][kirkstone][PATCH] libxcrypt: fixed some build error for nativesdk with mingw

[Khem Raj]

On Thu, Nov 30, 2023 at 12:31 AM wenlin.k...@windriver.com via
lists.yoctoproject.org
 wrote:
>
> From: Wenlin Kang 
>
> Steps to reproduce
>   1) add layer meta-mingw
>   2) add line in local.conf
>  SDKMACHINE = "x86_64-mingw32"
>   3) bitbake nativesdk-libxcrypt
>
> Fixed:
> 1. .symver error
>   | {standard input}: Assembler messages:
>   | {standard input}:4: Error: unknown pseudo-op: `.symver'
>
> 2. pedantic error
>   | ../git/lib/crypt.c:316:24: error: ISO C does not allow extra ';' outside 
> of a function [-Werror=pedantic]
>   |   316 | SYMVER_crypt_gensalt_rn;
>   |   |
>
> 3. conversion error
>   | ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
>   | ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 
> 'size_t' {aka 'long long unsigned int'} to 'unsigned int' may change value 
> [-Werror=conversion]
>   |   140 |   ssize_t nread = read (fd, buf, buflen);
>
> Signed-off-by: Wenlin Kang 
> ---
>  .../0001-Fix-for-compilation-on-Windows.patch | 37 +++
>  ...dom-bytes.c-fixed-conversion-error-w.patch | 47 +++
>  recipes-core/libxcrypt/libxcrypt_%.bbappend   |  7 +++
>  3 files changed, 91 insertions(+)
>  create mode 100644 
> recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
>  create mode 100644 
> recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
>  create mode 100644 recipes-core/libxcrypt/libxcrypt_%.bbappend
>
> diff --git 
> a/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch 
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> new file mode 100644
> index 000..5760ee0
> --- /dev/null
> +++ 
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> @@ -0,0 +1,37 @@
> +From a507b628a5a5d4e4f1cf0f0a9a72967470ee7624 Mon Sep 17 00:00:00 2001
> +From: Brecht Sanders 
> +Date: Fri, 3 Feb 2023 08:44:49 +0100
> +Subject: [PATCH] Fix for compilation on Windows
> +
> +This fix allows the library to build on Windows (at least with MinGW-w64).
> +
> +`.symver` is only supported for ELF format but Windows uses COFF/PE.
> +
> +Workaround dummy define of `symver_set()`
> +
> +Upstream-Status: Backport 
> [https://github.com/besser82/libxcrypt/commit/a507b628a5a5d4e4f1cf0f0a9a72967470ee7624]
> +
> +Signed-off-by: Wenlin Kang 
> +---
> + lib/crypt-port.h | 5 +
> + 1 file changed, 5 insertions(+)
> +
> +diff --git a/lib/crypt-port.h b/lib/crypt-port.h
> +index f06ca24..a707939 100644
> +--- a/lib/crypt-port.h
>  b/lib/crypt-port.h
> +@@ -201,6 +201,11 @@ extern size_t strcpy_or_abort (void *dst, size_t 
> d_size, const void *src);
> +   __asm__(".globl _" extstr);   \
> +   __asm__(".set _" extstr ", _" #intname)
> +
> ++#elif defined _WIN32
> ++
> ++/* .symver is only supported for ELF format, Windows uses COFF/PE */
> ++# define symver_set(extstr, intname, version, mode)
> ++
> + #elif defined __GNUC__ && __GNUC__ >= 3
> +
> + # define _strong_alias(name, aliasname) \
> +--
> +2.34.1
> +
> diff --git 
> a/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
>  
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> new file mode 100644
> index 000..3846f76
> --- /dev/null
> +++ 
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> @@ -0,0 +1,47 @@
> +From ff99091eb8a6b9e6edc567f6d2552183fbaacec3 Mon Sep 17 00:00:00 2001
> +From: Wenlin Kang 
> +Date: Mon, 6 Nov 2023 14:43:28 +0800
> +Subject: [PATCH] lib/util-get-random-bytes.c: fixed conversion error with
> + mingw
> +
> +With x86_64-w64-mingw32-gcc. get below error:
> +| ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
> +| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 'size_t' 
> {aka 'long long unsigned int'} to 'unsigned int' may change value 
> [-Werror=conversion]
> +|   140 |   ssize_t nread = read (fd, buf, buflen);
> +|   |  ^~
> +
> +In util-get-random-bytes.c, has get_random_bytes(void *buf, size_t buflen),
> +but in mingw-w64-mingw-w64/mingw-w64-headers/crt/io.h, read() has "unsigned 
> int"
> +read(int _FileHandle,void *_DstBuf,unsigned int _MaxCharCount), and has:
> + #ifdef _WIN64
> +   __MINGW_EXTENSION typedef unsigned __int64 size_t;
> + #else
> +   typedef unsigned int size_t;
> + #endif /* _WIN64 */
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Wenlin Kang 
> +---
> + lib/util-get-random-bytes.c | 4 
> + 1 file changed, 4 insertions(+)
> +
> +diff --git a/lib/util-get-random-bytes.c b/lib/util-get-random-bytes.c
> +index 79816db..68cd378 100644
> +--- a/lib/util-get-random-bytes.c
>  b/lib/util-get-random-bytes.c
> +@@ -137,7 +137,11 @@ get_random_bytes(void *buf, size_t buflen)
> + 

[yocto] [PATCH yocto-autobuilder-helper] config.json: Match the machine spec to task for rv32 qemu jobs

[Khem Raj]

Signed-off-by: Khem Raj 
---
 config.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index e95a292..c4b31e3 100644
--- a/config.json
+++ b/config.json
@@ -589,7 +589,7 @@
 "TEMPLATE" : "ltp-qemu"
 },
 "qemuriscv32" : {
-"MACHINE" : "qemuriscv64",
+"MACHINE" : "qemuriscv32",
 "TEMPLATE" : "arch-qemu"
 },
 "qemuriscv64" : {
@@ -597,7 +597,7 @@
 "TEMPLATE" : "arch-qemu"
 },
 "qemuriscv32-tc" : {
-"MACHINE" : "qemuriscv64",
+"MACHINE" : "qemuriscv32",
 "TEMPLATE" : "toolchain-qemu"
 },
 "qemuriscv64-tc" : {
-- 
2.43.0


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

Re: [yocto] [yocto-autobuilder-helper][PATCH] config.json: Add lib32-matchbox-terminal to multilib images

[Khem Raj]

On Fri, Nov 24, 2023 at 9:04 AM Ross Burton  wrote:

>
>
> > On 24 Nov 2023, at 16:53, Khem Raj  wrote:
> > So the trigger is bad packaging, as surely the vte recipe should split
> the libraries up so that installing a gtk*3* based terminal doesn’t pull in
> gtk4 for no reason.
> >
> > New vte enables both gtk3 and gtk4 support I don’t think it’s bad
> packaging. Multiple versions of gtk can live together in a rootfs without
> conflict
>
> Sure they _can_ but it’s a terrible idea to pull in both if they’re not
> needed.


Ok so do we think should gtk4 be a distro feature which conflicts with gtk3
?


>
> Ross

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

Re: [yocto] [yocto-autobuilder-helper][PATCH] config.json: Add lib32-matchbox-terminal to multilib images

[Khem Raj]

On Fri, Nov 24, 2023 at 4:09 AM Ross Burton  wrote:

> On 23 Nov 2023, at 16:38, Khem Raj  wrote:
> >
> > it pulls in lib32-vte which pulls in lib32-gtk4
>
> So the trigger is bad packaging, as surely the vte recipe should split the
> libraries up so that installing a gtk*3* based terminal doesn’t pull in
> gtk4 for no reason.
>

New vte enables both gtk3 and gtk4 support I don’t think it’s bad
packaging. Multiple versions of gtk can live together in a rootfs without
conflict


> Ross

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

Re: [yocto] [yocto-autobuilder-helper][PATCH] how can a missing file be a WARNING and the build 'succeed'?

[Khem Raj]

maybe your bbappend is not matching in name to recipe or maybe
something else, typos etc. Showing exact code can help a bit more in
understanding what might be going on.

On Thu, Nov 23, 2023 at 7:13 AM Dave Hitchman  wrote:
>
> I am trying to append to linux-imx.
> If I deliberately put a wrong filename in the src_uri append it warns me and 
> carries on with no effect or worry.
> Anything I put in the do_configure:append() or prepend() is just totally and 
> utterly ignored.
>
>

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

Re: [yocto] [yocto-autobuilder-helper][PATCH] config.json: Add lib32-matchbox-terminal to multilib images

[Khem Raj]

On Thu, Nov 23, 2023 at 4:14 AM Ross Burton  wrote:
>
> On 23 Nov 2023, at 12:00, Alexander Kanavin  wrote:
> >
> > matchbox-terminal depends on vte, and latest vte enables gtk4 support.
>
> Are you sure?
>
> https://git.yoctoproject.org/poky/tree/meta/recipes-support/vte/vte_0.72.2.bb#n14
>
> > Also, I do not understand how the fix works. How does installing
> > additional packages into an image resolve a conflict between two
> > packages installing different files into the same location?
>
> The problem is that the ipkg rootfs generation works “interestingly” and 
> appears to create two parallel rootfs (one for normal one for multilib) and 
> then splats them together.
>
> The schemas are installed in /usr/share but if you have different sets of 
> libraries in /usr/lib and /usr/lib32 then the compiled schemas are different.

Does not depend on content of /usr/lib or /usr/lib32, depending upon
whats getting into given rootfs, the schemas pulled are different and
hence the compiled gschema is
different which is them being overlayed into combined rootfs finally.
A good solution would be to create. common /usr/share directory
between two rootfs'es and let it be
populated with given dependencies, that way it will generate correct superset.

>
> This feels like an issue which has existed for a long time, so how has it 
> only just been noticed?  Did something change?
>
> Ross

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

Re: [yocto] [yocto-autobuilder-helper][PATCH] config.json: Add lib32-matchbox-terminal to multilib images

[Khem Raj]

On Thu, Nov 23, 2023 at 3:50 AM Ross Burton  wrote:
>
> Is this working around a failure on the autobuilder?  How does 
> matchbox-terminal pull in gtk4?

yes
it pulls in lib32-vte which pulls in lib32-gtk4

>
> Ross
> > On 22 Nov 2023, at 01:48, Khem Raj via lists.yoctoproject.org 
> >  wrote:
> >
> > This avoids an issue when a package that pulls in gtk4 into
> > core-image-sato but not into multilib pieces results in different
> > gschema compiled files as reported in [1]
> >
> > [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15291
> >
> > Signed-off-by: Khem Raj 
> > ---
> > config.json | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/config.json b/config.json
> > index c5fca45..e95a292 100644
> > --- a/config.json
> > +++ b/config.json
> > @@ -900,7 +900,7 @@
> > "MULTILIBS = 'multilib:lib32'",
> > "DEFAULTTUNE:virtclass-multilib-lib32 = 'x86'",
> > "RPM_PREFER_ELF_ARCH = '1'",
> > -"IMAGE_INSTALL:append = ' lib32-connman-gnome 
> > pango-module-basic-fc lib32-pango-module-basic-fc'"
> > +"IMAGE_INSTALL:append = ' lib32-connman-gnome 
> > lib32-matchbox-terminal pango-module-basic-fc lib32-pango-module-basic-fc'"
> > ]
> > },
> > "step4" : {
> > @@ -915,7 +915,7 @@
> > "MULTILIBS = 'multilib:lib32'",
> > "DEFAULTTUNE:virtclass-multilib-lib32 = 'x86'",
> > "RPM_PREFER_ELF_ARCH = '1'",
> > -"IMAGE_INSTALL:append = ' lib32-connman-gnome 
> > pango-module-basic-fc lib32-pango-module-basic-fc'"
> > +"IMAGE_INSTALL:append = ' lib32-connman-gnome 
> > lib32-matchbox-terminal pango-module-basic-fc lib32-pango-module-basic-fc'"
> > ]
> > },
> > "step5" : {
> > --
> > 2.43.0
> >
> >
> > 
> >
>

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

[yocto] [yocto-autobuilder-helper][PATCH] config.json: Add lib32-matchbox-terminal to multilib images

[Khem Raj]

This avoids an issue when a package that pulls in gtk4 into
core-image-sato but not into multilib pieces results in different
gschema compiled files as reported in [1]

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15291

Signed-off-by: Khem Raj 
---
 config.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index c5fca45..e95a292 100644
--- a/config.json
+++ b/config.json
@@ -900,7 +900,7 @@
 "MULTILIBS = 'multilib:lib32'",
 "DEFAULTTUNE:virtclass-multilib-lib32 = 'x86'",
 "RPM_PREFER_ELF_ARCH = '1'",
-"IMAGE_INSTALL:append = ' lib32-connman-gnome 
pango-module-basic-fc lib32-pango-module-basic-fc'"
+"IMAGE_INSTALL:append = ' lib32-connman-gnome 
lib32-matchbox-terminal pango-module-basic-fc lib32-pango-module-basic-fc'"
 ]
 },
 "step4" : {
@@ -915,7 +915,7 @@
 "MULTILIBS = 'multilib:lib32'",
 "DEFAULTTUNE:virtclass-multilib-lib32 = 'x86'",
 "RPM_PREFER_ELF_ARCH = '1'",
-"IMAGE_INSTALL:append = ' lib32-connman-gnome 
pango-module-basic-fc lib32-pango-module-basic-fc'"
+"IMAGE_INSTALL:append = ' lib32-connman-gnome 
lib32-matchbox-terminal pango-module-basic-fc lib32-pango-module-basic-fc'"
 ]
 },
 "step5" : {
-- 
2.43.0


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

Re: [yocto] Architecture did not match

[Khem Raj]

in your recipe, you need to add runtime dependencies. e.g.

RDEPENDS:${PN} += "bash"

or you can ignore the deps if your image has them all in already.
since your package is binary only.
add
INSANE_SKIP:${PN} = "file-rdeps"

On Tue, Nov 14, 2023 at 11:29 PM MOHAMMED HASSAN
 wrote:
>
> On Tue, Nov 14, 2023 at 11:17 PM, Khem Raj wrote:
>
> add lib32-testing-firmware in your image instead of testing-firmware
>
> NOTE: lib32-gst-plugin-video-sink: compiling from external source tree 
> /Yocto_sdk/yocto_sdk/aml-comp/multimedia/gst-plugin-video-sink
> NOTE: lib32-gst-plugin-aml-v4l2dec: compiling from external source tree 
> /Yocto_sdk/yocto_sdk/aml-comp/multimedia/gst-plugin-aml-v4l2dec
> NOTE: u-boot: compiling from external source tree 
> /Yocto_sdk/yocto_sdk/aml-comp/uboot
> ERROR: lib32-testing-firmware-0.1-r0 do_package_qa: QA Issue: Architecture 
> did not match (x86-64, expected ARM) on 
> /work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/packages-split/lib32-testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node
> Architecture did not match (x86-64, expected ARM) on 
> /work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/packages-split/lib32-testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node
> Architecture did not match (AArch64, expected ARM) on 
> /work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/packages-split/lib32-testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/android-arm64/node.napi.armv8.node
> Architecture did not match (AArch64, expected ARM) on 
> /work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/packages-split/lib32-testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm64/node.napi.armv8.node
>  [arch]
> WARNING: lib32-testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/install.sh contained in package lib32-testing-firmware 
> requires /bin/bash, but no providers found in 
> RDEPENDS_lib32-testing-firmware? [file-rdeps]
> ERROR: lib32-testing-firmware-0.1-r0 do_package_qa: QA run found fatal 
> errors. Please consider fixing them.
> ERROR: Logfile of failure stored in: 
> /Yocto_sdk/yocto_sdk/tmp/work/armv7at2hf-neon-pokymllib32-linux-gnueabi/lib32-testing-firmware/0.1-r0/temp/log.do_package_qa.52476
> ERROR: Task 
> (virtual:multilib:lib32:/Yocto_sdk/yocto_sdk/meta-blaze/recipes-example/testing-firmware/testing-firmware_0.1.bb:do_package_qa)
>  failed with exit code '1'
> NOTE: Tasks Summary: Attempted 7801 tasks of which 7737 didn't need to be 
> rerun and 1 failed.
> NOTE: Writing buildhistory
> NOTE: Writing buildhistory took: 1 seconds
>
> Summary: 1 task failed:
>
> Still the same error but now the architecture is shown different.
>
>
> 
>

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

Re: [yocto] Architecture did not match

[Khem Raj]

add lib32-testing-firmware in your image instead of testing-firmware

On Tue, Nov 14, 2023 at 10:26 PM MOHAMMED HASSAN
 wrote:
>
> Hi guys,
> So the SDK my vendor provided kernel toolchain of "aarch64-poky-linux-gcc" 
> while the application uses a 32 bit toolchain 
> "arm-pokymllib32-linux-gnueabi-gcc".
> So i want to just copy my nodejs application to the home directory. To 
> compensate for the architecture issues I have made the changes in my recipe 
> file as shown below.
>
> testing-firmware_0.1.bb:
> DESCRIPTION =  "Testing firmware for Edge 3 hubs"
>
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = 
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> SRC_URI = "file://Edge_3_firmware_testing.zip"
>
> S = "${WORKDIR}"
> INSANE_SKIP:${PN} += "arch:/Edge/node_modules/"
>
> do_install() {
> install -d ${D}/home/root
> cp -r ${WORKDIR}/Edge -d ${D}/home/root/
> cp -r ${WORKDIR}/Edge -d ${D}{bindir}/
> }
>
> FILES_${PN} = "/home/root/Edge"
>
> But when i try to build the testing firmware I get the following error:
>
> ERROR: testing-firmware-0.1-r0 do_package_qa: QA Issue: Architecture did not 
> match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware-dbg/home/root/Edge/node_modules/epoll/build/Release/.debug/epoll.node
> Architecture did not match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware-dbg/home/root/Edge/node_modules/epoll/build/Release/obj.target/.debug/epoll.node
>  [arch]
> ERROR: testing-firmware-0.1-r0 do_package_qa: QA Issue: Architecture did not 
> match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node
> Architecture did not match (x86-64, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node
> Architecture did not match (x86-64, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node
> Architecture did not match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> Architecture did not match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node
> Architecture did not match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/epoll/build/Release/epoll.node
> Architecture did not match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node
> Architecture did not match (ARM, expected AArch64) on 
> /work/aarch64-poky-linux/testing-firmware/0.1-r0/packages-split/testing-firmware/home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll/src/epoll.o
>  [arch]
> WARNING: testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node 
> contained in package testing-firmware requires libpthread.so.0(GLIBC_2.4), 
> but no providers found in RDEPENDS_testing-firmware? [file-rdeps]
> WARNING: testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node 
> contained in package testing-firmware requires libc.so.6(GLIBC_2.9), but no 
> providers found in RDEPENDS_testing-firmware? [file-rdeps]
> WARNING: testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node 
> contained in package testing-firmware requires libc.so.6(GLIBC_2.4), but no 
> providers found in RDEPENDS_testing-firmware? [file-rdeps]
> WARNING: testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node 
> contained in package testing-firmware requires libstdc++.so.6(CXXABI_1.3.9), 
> but no providers found in RDEPENDS_testing-firmware? [file-rdeps]
> WARNING: testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node 
> contained in package testing-firmware requires 
> libstdc++.so.6(CXXABI_ARM_1.3.3), but no providers found in 
> RDEPENDS_testing-firmware? [file-rdeps]
> WARNING: testing-firmware-0.1-r0 do_package_qa: QA Issue: 
> /home/root/Edge/node_modules/epoll/build/Release/obj.target/epoll.node 
> contained 

Re: [yocto] Files copied to /usr/local during installation get removed misteriously

[Khem Raj]

On Thu, Nov 9, 2023 at 10:02 PM Javier Casas Marín
 wrote:
>
> Hi,
> I have a recipe that creates some directories in /usr/local and copies there 
> some files using do_install:append
>
> inherit qmake5
> OE_QMAKE_PATH_HEADERS = "${OE_QMAKE_PATH_QT_HEADERS}"
> DEPENDS += "qtbase qtdeclarative qtmultimedia libgpiod"
>
> RDEPENDS:${PN} += "qtxmlpatterns qtdeclarative-qmlplugins qtbase-plugins 
> ttf-dejavu-sans qtquickcontrols qtquickcontrols2 qtfreevirtualkeyboard 
> libgpiod valgrind
>
> do_install:append () {
> install -d ${D}${bindir}
> install -d ${D}/usr/local/test
> install -m 0775 qt_test ${D}${bindir}
> install -m 0775 ${S}/test.db ${D}/usr/local/test
> cp -r ${WORKDIR}/Resources ${D}/usr/local/test/resources
> cp -r ${WORKDIR}/LocalFiles ${D}/usr/local/test/LocalFiles
> }
> FILES:${PN} += "${bindir}/qt_test"
> FILES:${PN} += "/opt/*"
> FILES:${PN} += "/usr/local/test/*"
>
> When I build the image, I see the folders appear in /usr/local as expected 
> while creating the rootfs but at some point they are removed and, by the time 
> the rootfs creation finishes, they are gone.
> If I take the ipk package and install it on the embedded device the folders 
> and files are created correctly so I guess that the recipe is fine but there 
> is some task during the rootfs creation that deletes all the files in 
> /usr/local (my folders are not the only ones that are deleted).
>
> Who could be doing that or how can I debug it to find the culprit?

There could be a rootfs postprocessing task which could be involked
after rootfs generation to do such tweaks. Look for what you have in
ROOTFS_POSTPROCESS_COMMAND variable.

>
>
> Kind regards,
> Javi
>
>
>
>
> 
>

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

Re: [yocto] Problem when adding own tasks

[Khem Raj]

On Sat, Nov 11, 2023 at 4:04 AM athragared via lists.yoctoproject.org
 wrote:
>
> Hello everyone, this is my first mail here, I hope this is the right 
> "channel" for my question.
>
> I am currently using the 'Kirkstone' branch of yocto and I have encountered a 
> problem. I have written a .bbappend file for systemd in my own layer. Here I 
> have written my own python function as follows:
>
> python do_my_own_function(){
> # do something
> }
> addtask my_own_function before do_install
>
> This seems to work most of the time. However, I would like to execute my own 
> function AFTER the do_install. However, this does not seem to work.

Code says _before_ but you say you wanted it _after_ do_install is
run, so maybe change the directive to before, moreover, add anchors on
both sides
to ensure its run in certain order so maybe say before do_package
after do_install.

you can also look into postfuncs/prefuncs

do_install[postfuncs] += "do_my_own_function"

> If I delete the build folder before building the image and then look in the 
> log.task_order file I see that my own function is NOT executed. Other people 
> on stackoverflow seem to have observed this problem as well.
>
>
>
> So I wanted to ask how to solve the problem or debug it further?
>
>
> Regards
> 
>

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

Re: [yocto] Package dependencies not generated?

[Khem Raj]

On Thu, Nov 2, 2023 at 11:16 AM Michael Opdenacker via
lists.yoctoproject.org
 wrote:
>
> Greetings,
>
> I compiled rsyslog from meta-oe:
> bitbake rsyslog
>
> I set up a binary feed ("bitbake package-index") and a webserver to
> serve it, and when I try to install the rsyslog package, I get:
> $ opkg install rsyslog

I see you ran bitbake package-index so thats good. maybe you did but
let me ask did you run opkg update before doing opkg install ?

>   * Solver encountered 1 problem(s):
>   * Problem 1/1:
>   *   - conflicting requests
>   *   - nothing provides libestr0 >= 0.1.11 needed by
> rsyslog-8.2306.0-r0.core2-64
>
> Indeed, no "*libestr*" package(s) got generated. Why not?
>
> I checked RDEPENDS:rsyslog and it contains "logrotate" for which a
> package was indeed generated. I thought that shared libraries
> dependencies were automatically detected and added to runtime
> dependencies. That's confirmed by
> https://docs.yoctoproject.org/dev/overview-manual/concepts.html#automatically-added-runtime-dependencies
> . Why didn't it happen?
>
> I checked that libestr got compiled (it's part of the DEPENDS for
> rsyslog), but I can't find any package for it, even in the working area.
>
> It sounds like a very basic misconception between my keyboard and my
> chair. What did I get wrong?
>
> Thanks in advance for your insights.
>
> Cheers
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
> 
>

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

Re: [yocto] [yocto-autobuilder-helper] [PATCH] config.json: Make meta-oe source mirror config wider coverage

[Khem Raj]

On 10/24/23 4:03 AM, Richard Purdie wrote:

Some recipes depend on DISTRO_FEATURES, commercial licensing or compiler
config like fortran. Set these things so that we get wider soruce mirror
coverage and fewer warnings.

'commercial' license usage is ok here since we're not building and then
shipping any binaries or using it, only mirroring the source code.

Signed-off-by: Richard Purdie 
---
  config.json | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/config.json b/config.json
index 0c35632..61cf374 100644
--- a/config.json
+++ b/config.json
@@ -1451,6 +1451,12 @@
  "${BUILDDIR}/../meta-openembedded/meta-initramfs",
  "${BUILDDIR}/../meta-openembedded/meta-webserver"
  ],
+"extravars" : [
+"LICENSE_FLAGS_ACCEPTED = 'commercial'",
+"DISTRO_FEATURES:append = ' pam systemd usrmerge'",
+"FORTRAN:forcevariable = ',fortran'",
+"RUNTIMETARGET:append:pn-gcc-runtime = ' libquadmath'"


I think RUNTIMETARGET should automatically be appended with libquadmath 
if FORTRAN is set.



+],
  "step1" : {
  "shortname" : "Sources pre-fetching",
  "BBTARGETS" : "universe -c fetch -k",







OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

Re: [yocto] Clang LLVM do_package strip error

[Khem Raj]

On Tue, Oct 24, 2023 at 6:33 AM Martin Townsend  wrote:
>
> On Mon, Oct 23, 2023 at 5:43 PM Khem Raj  wrote:
> >
> > On Mon, Oct 23, 2023 at 9:29 AM Martin Townsend  
> > wrote:
> > >
> > > Hi,
> > >
> > > I've updated the project I'm working on to kirkstone and using GCC it
> > > is working.  We want to move to Clang but I've seen a couple of
> > > recipes fail in do_package with a similar error.  Here is the output
> > > for runc-opencontainers, the package tini has something similar
> > >
> > >
> > > ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
> > > Fatal errors occurred in subprocesses:
> > > Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
> > > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
> > > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
> > > returned non-zero exit status 1.
> > > Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
> > > value 47 in section .rela.plt is not a symbol table
> > >
> >
> > Its using clang and also binutils from llvm here and there has been
> > many fixes we had done to llvm
> > tools and things are better with clang 17, but since you are on
> > kirkstone, you might be using older clang
> > and llvm. So you can try if master branch solves the problem and maybe
> > next LTS you are set other
> > option which might be immediately useful would be to fall back to
> > using objcopy from binutils which you
> > can do via something like below in site.conf
> >
> >  OBJCOPY:pn-runc-opencontainers:toolchain-clang = "${HOST_PREFIX}objcopy"
> >
>
> Moving to master and modifying a few recipes has fixed these issues
> but now docker and containerd-opencontainers are not compiling, for
> containerd, grepping for error I can see

did you switch all layers in your project to respective master branches ?
if not perhaps that might be the first thing to look at.

>
> vendor/k8s.io/apimachinery/pkg/util/sets/byte.go:34:16: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/int.go:34:15: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/int32.go:34:17: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/int64.go:34:17: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:24:10: syntax
> error: unexpected |, expecting semicolon or newline or }
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:31:9: syntax
> error: unexpected |, expecting semicolon or newline or }
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:38:2: syntax
> error: unexpected ~, expecting method or interface name
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:45:2: syntax
> error: unexpected ~, expecting method or interface name
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:52:2: syntax
> error: unexpected ~, expecting method or interface name
> vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: syntax error:
> unexpected comparable, expecting ]
> vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: too many errors
>
> and
>
> make: *** [Makefile:264: bin/containerd-shim] Error 2
> make: *** [Makefile:268: bin/containerd-shim-runc-v1] Error 2
> make: *** [Makefile:272: bin/containerd-shim-runc-v2] Error 2
> make: *** [Makefile:255: bin/ctr] Error 2
> make: *** [Makefile:255: bin/containerd-stress] Error 2
> make: *** [Makefile:255: bin/containerd] Error 2
>
>
> It looks like it's compiling go, do I need to do anything special for
> clang to compile go? I tried updating the recipe to the latest from
> master and still the same error.
>
> The lines from the makefile are
>
> define BUILD_BINARY
> @echo "$(WHALE) $@"
> $(GO) build ${DEBUG_GO_GCFLAGS} ${GO_GCFLAGS} ${GO_BUILD_FLAGS} -o $@
> ${GO_LDFLAGS} ${GO_TAGS}  ./$<
> endef
>
> # Build a binary from a cmd.
> bin/%: cmd/% FORCE
> $(call BUILD_BINARY)
>
>
> > > ERROR: Logfile of failure stored in:
> > > /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
> > > ERROR: Task 
> > > (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.

Re: [yocto] Clang LLVM do_package strip error

[Khem Raj]

On Mon, Oct 23, 2023 at 9:29 AM Martin Townsend  wrote:
>
> Hi,
>
> I've updated the project I'm working on to kirkstone and using GCC it
> is working.  We want to move to Clang but I've seen a couple of
> recipes fail in do_package with a similar error.  Here is the output
> for runc-opencontainers, the package tini has something similar
>
>
> ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
> Fatal errors occurred in subprocesses:
> Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
> '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
> '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
> returned non-zero exit status 1.
> Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
> value 47 in section .rela.plt is not a symbol table
>

Its using clang and also binutils from llvm here and there has been
many fixes we had done to llvm
tools and things are better with clang 17, but since you are on
kirkstone, you might be using older clang
and llvm. So you can try if master branch solves the problem and maybe
next LTS you are set other
option which might be immediately useful would be to fall back to
using objcopy from binutils which you
can do via something like below in site.conf

 OBJCOPY:pn-runc-opencontainers:toolchain-clang = "${HOST_PREFIX}objcopy"


> ERROR: Logfile of failure stored in:
> /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
> ERROR: Task 
> (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package)
> failed with exit code '1'
> Pseudo log:
> inode mismatch:
> '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc'
> ino 84410787 in db, 84431171 in request.
> Setup complete, sending SIGUSR1 to pid 2936321.
>
> I'm sure these used to compile with Clang in dunfell so could this be
> a toolchain problem?
>
> I'm using the kirkstone branch of meta-clang and have the following in
> my distro conf
> PREFERRED_PROVIDER_llvm = "clang"
> PREFERRED_PROVIDER_llvm-native = "clang-native"
> PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang"
> PROVIDES:pn-clang = "llvm"
> PROVIDES:pn-clang-native = "llvm-native"
> PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"
>
> and this in local.conf
>
> TOOLCHAIN ?= "clang"
> RUNTIME ?= "llvm"
>
> I notice there is a kirkstone-clang12 branch in meta-clang, should I
> be using this?
> If not, any help in debugging this would be appreciated.
>
> Cheers,
> Martin.
>
> 
>

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

Re: [yocto] find: unrecognized: -printf

[Khem Raj]

On 10/20/23 2:51 AM, Ross Burton wrote:

On 20 Oct 2023, at 07:07, Gyorgy Sarvari via lists.yoctoproject.org 
 wrote:


In case busybox's "find" utility is not sufficient for you, you could disable 
"find" in busybox's config, and add the full version of find to your image (recipe is 
called findutils).


There is no need to disable find in busybox, simply make the etckeeper recipe 
RDEPEND on findutils.



Alternatively, make etckeeper scripts not use the find options that 
busybox does not support, that might make it portable too.




Ross







OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

Re: [yocto] Using cmake... how?

[Khem Raj]

On Mon, Oct 16, 2023 at 8:27 AM Dave Hitchman  wrote:
>
> So my current recipe for the project works, including building various C, C++ 
> files
> I wanted to now add a library of someone elses creation.
> On my machine this library builds using the tools installed so the code is ok
>
> I added a recipe to my yocto build and it attempts to do the cmake.
>
> Unfortunately whatever I have tried over 2 days cmake insists:
>
> On using the from my machine NOT the cross compiling tool set the rest of the 
> yocto build uses.
> | -- The CXX compiler identification is GNU 9.4.0
> | -- The C compiler identification is GNU 9.4.0
> Getting upset about the flags passed in:
> | g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
> | cc1plus: error: bad value (‘armv8-a+crc+crypto’) for ‘-march=’ switch
> I cant even find where these flags are actually set, where I found them and 
> thought they were set I altered them to be FRED and nothing changed in the 
> errors at all.
>
>
> Any idea? Surely it should be pretty easy?

share your recipe and also any peculiarities in CMake files in this library

>
> thanks
> Dave
>
>
> 
>

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

Re: [yocto] any interest in a YP riscv mailing list?

[Khem Raj]

On Fri, Oct 13, 2023 at 7:25 AM Robert P. J. Day  wrote:
>
>
>   given that other acrhitectures have their own ML, is it reasonable
> that risc-v have its own mailing list?

We do not have generic architecture specific layers, existing mailing
lists should suffice for that matter.
I think you are referring to BSP layer specific mailing list they also
happen to main proponents of architecture,
these are member maintained layers.

>
> rday
>
> 
>

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

Re: [yocto] adjtimex #kirkstone

[Khem Raj]

or maybe for - https://github.com/rogers0/adjtimex

On Tue, Oct 10, 2023 at 12:08 PM Khem Raj  wrote:
>
> On Tue, Oct 10, 2023 at 10:31 AM Gary Huband via
> lists.yoctoproject.org 
> wrote:
> >
> > I'm on Kirkstone using core-image-full-cmdline image.  Is there a way to 
> > add adjtimex besides busybox?  I did not see an adjtimex recipe in 
> > kirkstone.
>
> there is not one. Perhaps straightforward to create from
> https://www.ibiblio.org/pub/Linux/system/admin/time/adjtimex-1.28.tar.gz
>
> >
> > Thanks
> >
> > Gary
> > 
> >

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

[Khem Raj]

On Tue, Oct 10, 2023 at 10:31 AM Gary Huband via
lists.yoctoproject.org 
wrote:
>
> I'm on Kirkstone using core-image-full-cmdline image.  Is there a way to add 
> adjtimex besides busybox?  I did not see an adjtimex recipe in kirkstone.

there is not one. Perhaps straightforward to create from
https://www.ibiblio.org/pub/Linux/system/admin/time/adjtimex-1.28.tar.gz

>
> Thanks
>
> Gary
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61310): https://lists.yoctoproject.org/g/yocto/message/61310
Mute This Topic: https://lists.yoctoproject.org/mt/101880152/21656
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] Modify target 'march' for RISCV VisionFive 2

[Khem Raj]

On Sun, Oct 8, 2023 at 2:37 PM Electronic Consult
 wrote:
>
> I'm using a KAS setup & added the following line:
>
> TUNE_CCARGS = "-march=rv64imafdc_zicsr_zifencei_zihintpause"

yes this is on right way, you need to create a new tune for this
option and select that as DEFAULTTUNE
see meta/conf/machine/include/riscv/tune-riscv.inc is the right place to add it.
>
> It seems to have resulted in a successful build of qtbase (following rebuilds 
> of gcc etc)
>
> I imagine there's a more correct way to achieve this however.
> 
>

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

Re: [yocto] Modify target 'march' for RISCV VisionFive 2

[Khem Raj]

Can you post the full log.do_compile of qtbase 6.7 somewhere ?

On Fri, Oct 6, 2023 at 9:44 AM Electronic Consult
 wrote:
>
> Hello all,
>
> I'd like to try building Qt6 for the RISCV VisionFive 2 board. My first 
> attempt returns the error (full error at the bottom):
>
> Error: unrecognized opcode `pause', extension `zihintpause' required
>
> It seems I need to append _zihintpause to the target march. Currently 
> 'riscv64-poky-linux-g++ -dumpspecs' returns:
>
> march=rv64imafdc_zicsr_zifencei mabi=lp64d
>
> I tried using BUILD_AS_ARCH & TUNE_FEATURES without success. Is there a way 
> to modify 'march' on a recipe basis?
>
> Thanks,
>
> Owen
>
> [26/1146] 
> /home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot-native/usr/bin/riscv64-poky-linux/riscv64-poky-linux-g++
>  
> --sysroot=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot
>  -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS -DQT_ASCII_CAST_WARNINGS 
> -DQT_BUILDING_QT -DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
> -DQT_DISABLE_DEPRECATED_UP_TO=0x05 
> -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 
> -DQT_MOC_COMPAT -DQT_NO_AS_CONST -DQT_NO_CAST_TO_ASCII 
> -DQT_NO_CONTEXTLESS_CONNECT -DQT_NO_DEBUG -DQT_NO_FOREACH 
> -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
> -DQT_NO_QEXCHANGE -DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS 
> -DQT_USE_QSTRINGBUILDER -DQT_WARN_DEPRECATED_UP_TO=0x07 
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/src/corelib/Core_autogen/include
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/include
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/include/QtCore
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git/src/corelib
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/src/corelib
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/src/corelib/global
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/src/corelib/kernel
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git/src/corelib/../3rdparty/tinycbor/src
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/include/QtCore/6.7.0
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/include/QtCore/6.7.0/QtCore
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git/src/corelib/../3rdparty/double-conversion/double-conversion
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git/src/corelib/../3rdparty/double-conversion
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git/src/corelib/../3rdparty/forkfd
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build/src/corelib/.rcc
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git/mkspecs/linux-g++
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot/usr/include/glib-2.0
>  
> -I/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot/usr/lib/glib-2.0/include
>  -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security  
> --sysroot=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot
>   -O2 -pipe -g -feliminate-unused-debug-types -fcanon-prefix-map  
> -fmacro-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git=/usr/src/debug/qtbase/6.7.0-r0
>   
> -fdebug-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/git=/usr/src/debug/qtbase/6.7.0-r0
>   
> -fmacro-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build=/usr/src/debug/qtbase/6.7.0-r0
>   
> -fdebug-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/build=/usr/src/debug/qtbase/6.7.0-r0
>   
> -fdebug-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot=
>   
> -fmacro-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot=
>   
> -fdebug-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/recipe-sysroot-native=
>
> -fmacro-prefix-map=/home/projects/yocto/build-riscv/build/tmp/work/riscv64-poky-linux/qtbase/6.7.0/image=
>   -fvisibility-inlines-hidden -DNDEBUG -O3 -std=c++17 -fPIC 
> -fvisibility=hidden 

Re: [yocto] [yocto-autobuilder-helper][PATCH v2] config.json: add reproducible-openembedded build

[Khem Raj]

looks fine to me Thanks

On Mon, Oct 2, 2023 at 7:56 AM Fabien Thomas  wrote:
>
> The purpose of this new builder is to report the reproducibility status
> of all meta-openembedded recipes layer by layer. It use the same
> reproducible selftest than OE-Core but setting only world as target,
> and excluding all oecore and other openembedded layer recipes.
> Also, the report output directory is split by layers.
>
> Signed-off-by: Fabien Thomas 
> Reviewed-by: Yoann Congal 
> ---
>
> Changes v1->v2 :
> * Split builder into multiple steps, one for each openembedded layers.
> * Split reports output in the same way, one for each layers.
> * For each step, only to be tested layer and its dependancies are added.
> * Every other layers than the one that is tested is excluded from world.
>
>  config.json | 133 
>  1 file changed, 133 insertions(+)
>
> diff --git a/config.json b/config.json
> index 05c6794..90762f9 100644
> --- a/config.json
> +++ b/config.json
> @@ -264,6 +264,136 @@
>
>  }
>  },
> +"reproducible-meta-openembedded" : {
> +"MACHINE" : "qemux86-64",
> +"SDKMACHINE" : "x86_64",
> +"DISTRO" : "None",
> +"NEEDREPOS" : ["oecore", "bitbake", "meta-openembedded"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-selftest"
> +],
> +"extravars" : [
> +"EXCLUDE_FROM_WORLD:layer-core = '1'",
> +"EXCLUDE_FROM_WORLD:layer-selftest = '1'",
> +"OEQA_REPRODUCIBLE_TEST_TARGET = 'world'"
> +],
> +"step1" : {
> +"shortname" : "Reproducible Selftest for openembedded 
> meta-filesystems layer",
> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded-meta-filesystems/
>  DISPLAY=:1 oe-selftest -r reproducible"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-openembedded/meta-filesystems",
> +"${BUILDDIR}/../meta-openembedded/meta-oe"
> +],
> +"extravars" : [
> +"EXCLUDE_FROM_WORLD:layer-openembedded-layer = '1'"
> +]
> +},
> +"step2" : {
> +"shortname" : "Reproducible Selftest for openembedded 
> meta-gnome layer",
> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded-meta-gnome/
>  DISPLAY=:1 oe-selftest -r reproducible"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-openembedded/meta-gnome",
> +"${BUILDDIR}/../meta-openembedded/meta-oe",
> +"${BUILDDIR}/../meta-openembedded/meta-networking",
> +"${BUILDDIR}/../meta-openembedded/meta-python"
> +],
> +"extravars" : [
> +"EXCLUDE_FROM_WORLD:layer-openembedded-layer = '1'",
> +"EXCLUDE_FROM_WORLD:layer-networking-layer = '1'",
> +"EXCLUDE_FROM_WORLD:layer-meta-python = '1'"
> +]
> +},
> +"step3" : {
> +"shortname" : "Reproducible Selftest for openembedded 
> meta-initramfs layer",
> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded-meta-initramfs/
>  DISPLAY=:1 oe-selftest -r reproducible"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-openembedded/meta-initramfs"
> +]
> +},
> +"step4" : {
> +"shortname" : "Reproducible Selftest for openembedded 
> meta-multimedia layer",
> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded-meta-multimedia/
>  DISPLAY=:1 oe-selftest -r reproducible"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-openembedded/meta-multimedia",
> +"${BUILDDIR}/../meta-openembedded/meta-oe",
> +"${BUILDDIR}/../meta-openembedded/meta-python"
> +],
> +"extravars" : [
> +"EXCLUDE_FROM_WORLD:layer-openembedded-layer = '1'",
> +"EXCLUDE_FROM_WORLD:layer-meta-python = '1'"
> +]
> +},
> +"step5" : {
> +"shortname" : "Reproducible Selftest for openembedded 
> meta-networking layer",
> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded-meta-networking/
>  DISPLAY=:1 oe-selftest -r reproducible"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-openembedded/meta-networking",
> +

Re: [yocto] Trouble enabling vtable-verify for gcc-cross

[Khem Raj]

On Sun, Oct 1, 2023 at 2:05 PM Alex Roberts  wrote:
>
> I identified the issue. libvtv's Makefile.in and Makefile.am are
> expecting CC_FOR_TARGET to be set
>
> CXXVTV=$(CC_FOR_TARGET)
> CXXLD=$(CC_FOR_TARGET)
>
> gcc-cross_9.3.inc exports CC_FOR_TARGET, but gcc-runtime_9.3.inc does not.
> When libvtv is compiled during gcc-runtime recipe, CXXVTV and CXXLD
> are empty and libtool fails with the error that the -D definitions are
> unrecognized options.
>
> Setting CXXVTV=$(CXX) and CXXLD=$(CXX) allowed me to build libvtv and
> cross-compile programs with the -fvtable-verify compiler option.
>

meta/recipes-devtools/gcc/gcc-configure-common.inc sets CC_FOR_TARGET
selectively for cross-compiled gcc recipes
so it should be set in do_configure step of gcc-runtime but you can
see that gcc-runtime overrides do_configure function
in meta/recipes-devtools/gcc/gcc-runtime.inc, perhaps we should
replicate the exports in gcc-runtme do_configure as well


> On Thu, Sep 28, 2023 at 2:55 PM Alex Roberts via
> lists.yoctoproject.org 
> wrote:
> >
> > Today I revisited cloning gcc-sanitizers.inc and gcc-sanitizers_9.3.bb
> > in an attempt to make a recipe that configures and builds libvtv. This
> > somewhat works, but I get errors with libtool
> >
> >
> > | /bin/sh ./libtool --tag=CXX   --mode=compile  -DPACKAGE_NAME=\"GNU\
> > Vtable\ Verification\ Runtime\ Library\" -DPACKAGE_TARNAME=\"libvtv\"
> > -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"GNU\ Vtable\
> > Verification\ Runtime\ Library\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
> > -DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\; -DSTDC_HEADERS=1
> > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> > -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
> > -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DPACKAGE=\"libvtv\"
> > -DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1 -DHAVE___FORTIFY_FAIL=1
> > -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE__OBSTACK_BEGIN=1 -I.
> > -I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv
> > -I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../include
> >  -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
> > -I./../libstdc++-v3/include
> > -I./../libstdc++-v3/include/aarch64-oe-linux
> > -I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../libstdc++-v3/libsupc++
> > -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -O2
> > -fomit-frame-pointer-Wa,--noexecstack -fexpensive-optimizations
> > -frename-registers -ftree-vectorize   -finline-functions
> > -finline-limit=64   -Wno-error=maybe-uninitialized
> > -Wno-error=unused-result -fvisibility-inlines-hidden -c -o
> > vtv_malloc.lo 
> > ../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/vtv_malloc.cc
> > | /bin/sh ./libtool --tag=CXX   --mode=compile  -DPACKAGE_NAME=\"GNU\
> > Vtable\ Verification\ Runtime\ Library\" -DPACKAGE_TARNAME=\"libvtv\"
> > -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"GNU\ Vtable\
> > Verification\ Runtime\ Library\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
> > -DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\; -DSTDC_HEADERS=1
> > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> > -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
> > -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DPACKAGE=\"libvtv\"
> > -DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1 -DHAVE___FORTIFY_FAIL=1
> > -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE__OBSTACK_BEGIN=1 -I.
> > -I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv
> > -I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../include
> >  -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
> > -I./../libstdc++-v3/include
> > -I./../libstdc++-v3/include/aarch64-oe-linux
> > -I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../libstdc++-v3/libsupc++
> > -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -O2
> > -fomit-frame-pointer-Wa,--noexecstack -fexpensive-optimizations
> > -frename-registers -ftree-vectorize   -finline-functions
> > -finline-limit=64   -Wno-error=maybe-uninitialized
> > -Wno-error=unused-result -fvisibility-inlines-hidden -c -o
> > vtv_rts.lo 
> > ../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/vtv_rts.cc
> > | /bin/sh ./libtool --tag=CXX   --mode=compile  -DPACKAGE_NAME=\"GNU\
> > Vtable\ Verification\ Runtime\ Library\" -DPACKAGE_TARNAME=\"libvtv\"
> > -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"GNU\ Vtable\
> > Verification\ Runtime\ Library\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
> > -DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\; -DSTDC_HEADERS=1
> > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> > 

Re: [yocto] CDN for sstate.yoctoproject.org

[Khem Raj]

For fun, I tried scratch build of core-image-sato-sdk from master-next
+ my changes with the new SSTATE_MIRROR

Initialising tasks: 100%
|###|
Time: 0:02:16
Checking sstate mirror object availability: 100%
|###|
Time: 0:02:26
Sstate summary: Wanted 5040 Local 3 Mirrors 5024 Missed 13 Current 0
(99% match, 0% complete)

...

NOTE: Tasks Summary: Attempted 10124 tasks of which 10092 didn't need
to be rerun and all succeeded.

So match percentage is cool.

Elapsed time: 799.86 seconds

which is approx 13 mins so pretty cool given that sstate download is
also included in this time.

On Sat, Sep 23, 2023 at 12:53 PM Michael Halstead
 wrote:
>
> When adding https://cdn.jsdelivr.net/yocto/sstate/all please remove any 
> reference to sstate.yoctoproject.org from SSTATE_MIRRORS to ensure a proper 
> test.
>
> Thank you
>
> On Sat, Sep 23, 2023 at 12:51 PM Michael Halstead 
>  wrote:
>>
>> After some workshopping this morning we have a solution for larger files. 
>> Almost every package is now available with CDN acceleration. For files over 
>> 64MB the fetcher will need to follow a series of redirects to work properly. 
>> Files under 64MB will be served fast from every region. Larger files will be 
>> proxyed and cached on a smaller network of servers that can handle them. 
>> Once cached they will be stored for up to a month. Because sstate is 
>> immutable that means fast access after the first use in a region.
>>
>> Set SSTATE_MIRRORS to include https://cdn.jsdelivr.net/yocto/sstate/all or 
>> http://cdn.jsdelivr.net/yocto/sstate/all, test it out, and report back.
>>
>> If we want the system to perform as fast as possible we need to change 
>> SSTATE to work with 64MB file segments but that's a discussion to have after 
>> this solution is tested.
>>
>>
>> On Fri, Sep 22, 2023 at 12:03 PM Michael Halstead 
>>  wrote:
>>>
>>> Here are packages and size ranges that are not yet served via CDN. 
>>> Hopefully testing on the smaller files is possible while we figure out a 
>>> solution for these.
>>>
>>> assimp 75M 76M
>>> binutils 64M 100M
>>> boost 68M 148M
>>> ceres-solver 167M 182M
>>> cmake 157M 553M
>>> ffmpeg 68M 69M
>>> gcc 127M 681M
>>> gcc-cross-aarch64 64M 102M
>>> gcc-cross-arm 64M 72M
>>> gcc-cross-i686 65M 80M
>>> gcc-cross-mips 65M 69M
>>> gcc-cross-mips64 64M 69M
>>> gcc-cross-powerpc 64M 72M
>>> gcc-cross-x86_64 65M 104M
>>> gcc-crosssdk-aarch64-pokysdk-linux 65M 75M
>>> gcc-crosssdk-i686-oesdk-linux 65M 77M
>>> gcc-crosssdk-i686-pokysdk-linux 65M 79M
>>> gcc-crosssdk-i686-w64-mingw32 66M 78M
>>> gcc-crosssdk-x86_64-oesdk-linux 65M 78M
>>> gcc-crosssdk-x86_64-pokysdk-linux 65M 80M
>>> gcc-crosssdk-x86_64-w64-mingw32 67M 79M
>>> gdb 66M 105M
>>> ghostscript 64M 115M
>>> git 68M 90M
>>> glibc-locale 81M 228M
>>> go 67M 67M
>>> go-binary-native 82M 82M
>>> go-cross-core2-32 98M 100M
>>> go-cross-core2-64 93M 100M
>>> go-cross-corei7-64 98M 99M
>>> go-cross-cortexa15t2hf-neon 99M 99M
>>> go-cross-cortexa57 93M 99M
>>> go-cross-cortexa8hf-neon 99M 100M
>>> go-cross-mips32r2 98M 99M
>>> go-cross-mips64 99M 99M
>>> go-cross-mips64r2 99M 99M
>>> go-native 86M 86M
>>> go-runtime 64M 82M
>>> grpc 74M 102M
>>> hdf5 78M 137M
>>> influxdb 76M 98M
>>> intel-media-driver 68M 132M
>>> jemalloc 164M 164M
>>> kea 65M 153M
>>> lib32-binutils 64M 70M
>>> lib32-boost 77M 122M
>>> lib32-cmake 158M 305M
>>> lib32-gcc 144M 390M
>>> lib32-gcc-cross-i686 65M 79M
>>> lib32-gcc-cross-mips 65M 69M
>>> lib32-ghostscript 65M 83M
>>> lib32-git 65M 65M
>>> lib32-glibc-locale 81M 228M
>>> lib32-go-cross-x86 98M 99M
>>> lib32-kea 64M 88M
>>> lib32-linux-firmware 275M 419M
>>> lib32-llvm 1126.4M 2662.4M
>>> lib32-ltp 77M 305M
>>> lib32-mesa 65M 68M
>>> lib32-openssl 119M 360M
>>> lib32-piglit 106M 106M
>>> lib32-qemu 275M 639M
>>> lib32-rust 93M 129M
>>> lib32-rust-llvm 64M 76M
>>> lib32-spirv-tools 68M 107M
>>> lib32-valgrind 68M 89M
>>> lib32-vulkan-demos 74M 74M
>>> lib32-vulkan-validation-layers 65M 101M
>>> lib32-webkitgtk 1126.4M 927M
>>> lib64-boost 75M 119M
>>> lib64-gcc 151M 401M
>>> lib64-gcc-cross-mips64 65M 69M
>>> lib64-gcc-cross-x86_64 65M 80M
>>> lib64-glibc-locale 82M 228M
>>> lib64-go-cross-x86_64 98M 99M
>>> lib64-go-runtime 68M 81M
>>> lib64-ltp 67M 347M
>>> lib64-mesa 66M 68M
>>> lib64-openssl 276M 411M
>>> lib64-rust 97M 123M
>>> lib64-rust-llvm 64M 67M
>>> lib64-valgrind 65M 84M
>>> libyang 93M 93M
>>> linux-firmware 275M 419M
>>> linux-intel 120M 395M
>>> linux-yocto 66M 537M
>>> linux-yocto-rt 174M 287M
>>> llvm 1126.4M 3481.6M
>>> llvm-native 71M 88M
>>> ltp 64M 598M
>>> mariadb 1331.2M 966M
>>> mariadb-native 237M 259M
>>> mesa 64M 113M
>>> minifi-cpp 155M 214M
>>> mozjs-102 183M 255M
>>> nativesdk-glibc-locale 81M 226M
>>> 

Re: [yocto] Forcing uninative?

[Khem Raj]

On Wed, Sep 20, 2023 at 2:16 PM Alexandre Belloni via
lists.yoctoproject.org
 wrote:
>
> Hello,
>
> On 20/09/2023 13:59:54-0700, Rudolf J Streif wrote:
> > I need to resurrect a Yocto Project build environment based on honister. My
> > dev system has since moved on to a newer glibc etc. As expected, I am
> > getting this warning
> >
> > WARNING: Your host glibc version (2.37) is newer than that in uninative
> > (2.34). Disabling uninative so that sstate is not corrupted.
> >
> > The distro's gcc now is 13.2.1.
> >
> > Now the following packages do not compile anymore:
> >
> >  * rust-llvm-native : which there is a patch (applied to kirkstone):
> >
> > https://lore.kernel.org/openembedded-core/CANPvuR=G1NxfJb67xD19FoNh4eTDsTM4TDyF+vDbh6crNH=d...@mail.gmail.com/T/
> >  * libdnf-native : because std::uint32_t does not exist anymore
> >
> > I don't care about the sstate as I am creating a new one. However, how can I
> > force uninative to be used and would it even solve the problem (I would
> > think so as the idea of uninative is to isolate the build from the host
> > libraries)?
> >
>
> You should rather use buildtools. You can install those with
> scripts/install-buildtools. The -r option is there to allow you to
> select a target release. You can try something like:
>
> poky/scripts/install-buildtools -d ~/YP/buildtools -r yocto-3.4.4 
> --installer-version 3.4.4
>
> This will then tell you to source 
> buildtools/environment-setup-x86_64-pokysdk-linux
>
> This should be enough to be able to build old releases.

real issue would be getting native packages compiling with newer
compilers, unless you are ready to do such backports this
is going to be a problem. I would suggest using a supported/tested
distro for honister release inside a VM or container to build it.
>
> Regards,
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> 
>

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

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

[Khem Raj]

does it work if you add do_compile[network] = "1"

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60879): https://lists.yoctoproject.org/g/yocto/message/60879
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] EXTRA_USERS_PARAMS doesn't work to generate password for root and add new users

[Khem Raj]

On Wed, Aug 23, 2023 at 10:11 PM Jeffrey Simons
 wrote:
>
> On Wed, Aug 23, 2023 at 03:50 PM, Crane wrote:
>
> >
> > On Wed, Aug 23, 2023 at 03:45 AM, Mauro wrote:
> >
> > >
> > > You can put the encrypted password (the result of the "openssl passwd -6
> > > root" command) directly in the variable, taking care to put a "\" before
> > > the three "$" contained in the string. Something like this:
> > >
> > > EXTRA_USERS_PARAMS=" usermod -p
> > >
> > '\$6\$CEM0hANiVS9VXN8N\$Q9XK1KTpq2faq2fNbSRLNeeA4mmQsl8g1Gwl3QnTPlRPb5ljCAa./bbhffcthXxUen4jSFL6HKGQPlHZNQkfA/'
> > > root; useradd -p
> > >
> > '\$6\$5wVybJkbuowR0iMi\$tnEJEEbXbcRfksKRSt7rjlY1hRERrjqFOlCaa0s1ivISxAHT7MFdcnZvVbRHgkqRSYzA1oLUxtR0LuvDTMPR5/'
> > > crane; "
> >
> > Tried as well. And a \ is added automatically in front of $, so no need to 
> > add
> > it. But still not working.
> > There must be something else missing. Anyway to debug in this case?
> >
>
> From testing I have observed that the extrausers does not work from a recipe, 
> while useradd works correctly from a recipe.
> The extrausers should work as expected from within the distribution 
> description, so you might want to try that.
>
> For debugging you could print the bitbake variables to screen (-e) and grep 
> on the EXTRA_USERS_PARAMS.
>

See this

https://github.com/YoeDistro/yoe-distro/blob/master/conf/projects/rpi4-64/config.conf#L57-L66

you might try something like that in config metadata e.g. local.conf

> Hope this is will help you solving the issue.
>
> --
> With kind regards,
>
> Jeffrey Simons
>
> Software Engineer
> Royal Boon Edam International B.V.
>
> 
>

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

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

[Khem Raj]

which task is failing ?

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60869): https://lists.yoctoproject.org/g/yocto/message/60869
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] Qemu not working for raspberry pi

[Khem Raj]

On Sat, Aug 19, 2023 at 5:42 AM  wrote:
>
> Hi all,
> i want to run my raspberry pi in qemu and for this, I have created the image 
> using core-image-weston and also set machine to:MACHINE ??= "qemux86-64" 
> .after this whenever I try to run using qemu it shows
> Error:"runqemu - ERROR - IMAGE_LINK_NAME wasn't set to find corresponding 
> .qemuboot.conf file"

Its not clear what you are trying to do but I guess you have built an
image for RPI which
you want to run on an emulator instead of real hardware. In that case,
you have to use
either qemuarm or qemuarm64 depending upon your image being 64bit or
32bit. you might
have to explore runqemu options where you can point it to a kernel and
rootfs explicitly
and use that to point it to the rpi images. This may not work even
after that since there might be more tweaks needed for the pi image to
run in qemu.

>
> Please help
> 
>

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

Re: [yocto] Qt6.2 with eglfs build failing on kirkstone

[Khem Raj]

On 8/11/23 2:24 AM, Gurnett, Bjorn via lists.yoctoproject.org wrote:
Trying to build an custom image based on core-image with kirkstone and 
qt lts-6.2 that should use the eglfs backend for a am625.


when building I keep getting the following error

glfskmsegldeviceintegration.cpp
| In file included from 
/home/jenkins/Yocto/kirkstone/poky/build/tmp/work/x86_64-linux/qtbase-native/6.2.10-r0/build/include/QtEglFSDeviceIntegration/6.2.10/QtEglFSDeviceIntegration/private/qeglfscursor_p.h:1,
|                  from 
/home/jenkins/Yocto/kirkstone/poky/build/tmp/work/x86_64-linux/qtbase-native/6.2.10-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldeviceintegration.cpp:46:
| 
/home/jenkins/Yocto/kirkstone/poky/build/tmp/work/x86_64-linux/qtbase-native/6.2.10-r0/build/include/QtEglFSDeviceIntegration/6.2.10/QtEglFSDeviceIntegration/private/../../../../../../git/src/plugins/platforms/eglfs/api/qeglfscursor_p.h:57:10: fatal error: QtOpenGL/QOpenGLShaderProgram: No such file or directory

|    57 | #include 
|       |          ^~~

would appreciate any suggestions


This is  native recipe so it does not really have same packageconfigs as 
target I would suggest to have eglfs specific options only for target 
version of recipe.









OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

Re: [yocto] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Khem Raj]

you should generate it w.r.t S not WORKDIR

On Tue, Aug 8, 2023 at 11:38 AM Crane  wrote:
>
> Now the issue is with the patch itself.
>
> The patch is created by using "diff -ruN" is not working. The error is "no 
> file to patch". I can understand this as the file compared to in the patch 
> doesn't exist in the $(WORKDIR).
>
> I changed to use "git format-patch" in the $(WORKDIR) to generate the patch. 
> But still not working. The error is "does not apply (enforce with -f)".
>
> And applying -f option got the same error.
>
> Where is the problem? The way to create the patch or apply the patch.
>
>
> 
>

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

Re: [yocto] Rootless Podman

[Khem Raj]

On Tue, Aug 8, 2023 at 11:43 AM 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.
>

With yoe

local.sh
export DOCKER_REPO=yoedistro/yoe-build:bookworm-`uname -m`
export DOCKER=podman

and then try to build yoe-simple-image, it complains about enough
parallel threads not being available when running node to build
qtwebengine
omp running out of threads in other recipes and so on. These issues
don't happen on native or docker builds e.g. privileged mode also does
show these issues.

> 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

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

[Khem Raj]

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60746): https://lists.yoctoproject.org/g/yocto/message/60746
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] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Khem Raj]

On Tue, Aug 8, 2023 at 10:44 AM Daniel Chaves  wrote:

> Hi, it might be a syntax issue with THISDIR variable expansion: it should
> be in curly braces for Yocto.
>

Ah yes I was ignoring it all along thinking it is meta code but if it is
literally coded like this then that is the issue really


> FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
> SRC_URI:append =  " file://rpi-config.patch"
>
> Have a look to this Variable Expansion documentation for more details:
> https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-metadata.html#variable-expansion
>
> Regards,
> Daniel
>
>
> On Tue, Aug 8, 2023 at 11:28 AM Khem Raj  wrote:
>
>> where does 0001-disable-bluetooth-and-enable-uart0.patch exist in your
>> layer? can you show the path ?
>>
>> On Tue, Aug 8, 2023 at 10:02 AM Crane  wrote:
>> >
>> > The error is this when bitbaking only the recipe for rpi-config:
>> > "WARNING: rpi-config-git-r5 do_fetch: Failed to fetch URL
>> file://0001-disable-bluetooth-and-enable-uart0.patch, attempting MIRRORS if
>> available
>> > ERROR: rpi-config-git-r5 do_fetch: Fetcher failure: Unable to find file
>> file://0001-disable-bluetooth-and-enable-uart0.patch anywhere. The paths
>> that were searched were:
>> > 
>> > "
>> > The listed searching paths don't include the custom layer where the
>> patch is placed.
>> > The complete error info is in the attached file "bitbake
>> rpi-config.txt".
>> >
>> > When bitbaking the recipe for the image, the error is the same.
>> > The complete error info is in attached file "bitbake image.txt".
>> >
>> >
>> >
>> >
>>
>> 
>>
>>

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

Re: [yocto] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Khem Raj]

where does 0001-disable-bluetooth-and-enable-uart0.patch exist in your
layer? can you show the path ?

On Tue, Aug 8, 2023 at 10:02 AM Crane  wrote:
>
> The error is this when bitbaking only the recipe for rpi-config:
> "WARNING: rpi-config-git-r5 do_fetch: Failed to fetch URL 
> file://0001-disable-bluetooth-and-enable-uart0.patch, attempting MIRRORS if 
> available
> ERROR: rpi-config-git-r5 do_fetch: Fetcher failure: Unable to find file 
> file://0001-disable-bluetooth-and-enable-uart0.patch anywhere. The paths that 
> were searched were:
> 
> "
> The listed searching paths don't include the custom layer where the patch is 
> placed.
> The complete error info is in the attached file "bitbake rpi-config.txt".
>
> When bitbaking the recipe for the image, the error is the same.
> The complete error info is in attached file "bitbake image.txt".
>
>
> 
>

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

Re: [yocto] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Khem Raj]

this looks good. So now what kind of error do you see. You might want
to check the build tree of this recipe and see if the patch is applied
in S

On Mon, Aug 7, 2023 at 7:36 PM Crane  wrote:
>
> The recipe append name I used is rpi-config_git.bbappend.
> It is placed in meta-custom/recipes-bsp/bootfiles/
>
> The layer conf of the custom layer is like this:
> # We have a conf and classes directory, add to BBPATH
> BBPATH .= ":${LAYERDIR}"
> # We have recipes-* directories, add to BBFILES
> BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
> ${LAYERDIR}/recipes-*/*/*.bbappend"
> BBFILE_COLLECTIONS += "meta-farview"
> BBFILE_PATTERN_meta-farview = "^${LAYERDIR}/"
> BBFILE_PRIORITY_meta-farview = "19"
> LAYERDEPENDS_meta-farview = "core"
> LAYERSERIES_COMPAT_meta-farview = "kirkstone"
>
>
> 
>

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

Re: [yocto] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Khem Raj]

On Mon, Aug 7, 2023 at 6:50 PM Crane  wrote:
>
> Thanks Raj for your quick reply.
>
> For config.txt, the recipe I am referring to is rpi-config_git.bb in 
> meta-respberrypi layer. This is the one I am testing now.
>
> Further on, I will add recipe appends for rpi-cmdline.bb.
> To change /etc/inittab, I still need to find which recipe to append.
>

what is the name you are using for bbappend ? secondly what does your
layer.conf look like for this custom layer ?

> Thanks!
> Crane
>
> 
>

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

Re: [yocto] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Khem Raj]

On Mon, Aug 7, 2023 at 6:29 PM Crane  wrote:
>
> Hello,
>
> I would like to write a .bbappend for config.txt, cmdline.txt and 
> /etc/inittab in my custom layer to make some changes.
>
> The recipe append for config.txt is created like this:
> FILESEXTRAPATHS:prepend := "$(THISDIR)/files:"
> SRC_URI += "file://rpi-config.patch"
>
> The paths of the recipe and patch are in the custom layer's bblayer.conf.
> But Bitbake doesn't search the custom layer for the recipe append.
>
> Is it a proper way to do that? If yes, what might be missing in the 
> configuration?
>

yes, however, which recipe are you referring to?

> Thanks!
> Crane
>
>
>
>
>
>
> 
>

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

Re: [yocto] Yocto on Raspberry Pi 3: Error when building image from a machine conf in a new layer

[Khem Raj]

On Wed, Aug 2, 2023 at 7:07 PM Crane  wrote:
>
> Hello,
>
> I am using Yocto to build a image for Raspberry Pi 3. I don't see a specific 
> group for RaspberryPi and hope to get help from here.
>
> I am using Kirkstone commit and didn't download meta-openembedded as it 
> doesn't say it is needed in README. And it works to build a image.
>
> Now I would like to add a new machine in the my customized layer to make some 
> changes based on the original machine configuration.
> So I copied raspberrypi3.conf from meta-raspberrypi to my new layer first.
>
> But bitbake displays errors as below:
>
> ===
> crane@Ubuntu2204:~/yocto-pi/build$ bitbake -k farview-image-base
>
> Loading cache: 100% 
> |#|
>  Time: 0:00:00
>
> Loaded 657 entries from dependency cache.
>
> WARNING: 
> /home/crane/yocto-pi/sources/poky/meta/recipes-extended/images/core-image-testcontroller.bb:
>  Exception during build_dependencies for IMAGE_BOOT_FILES
>
> WARNING: 
> /home/crane/yocto-pi/sources/poky/meta/recipes-extended/images/core-image-testcontroller.bb:
>  Error during finalise of 
> /home/crane/yocto-pi/sources/poky/meta/recipes-extended/images/core-image-testcontroller.bb
>
> ERROR: ExpansionError during parsing 
> /home/crane/yocto-pi/sources/poky/meta/recipes-extended/images/core-image-testcontroller.bb
>
> Traceback (most recent call last):
>
> File "Var ", line 1, in 
>
> File 
> "/home/crane/yocto-pi/sources/meta-raspberrypi/conf/machine/include/rpi-base.inc",
>  line 134, in make_dtb_boot_files(d= 0x7f4952f3d9c0>):
>
> > return ' '.join([transform(dtb) for dtb in alldtbs.split(' ') if dtb])
>
> bb.data_smart.ExpansionError: Failure expanding variable IMAGE_BOOT_FILES, 
> expression was bootfiles/* ${@make_dtb_boot_files(d)} 
> ${@bb.utils.contains('RPI_USE_U_BOOT', '1', 'zImage u-boot.bin;kernel7.img 
> boot.scr', 'zImage;kernel7.img', d)} which triggered exception TypeError: 
> sequence item 61: expected str instance, NoneType found
>
> The variable dependency chain for the failure is: IMAGE_BOOT_FILES
>
> ERROR: Parsing halted due to errors, see error messages above
>
> Summary: There were 2 WARNING messages.
>
> Summary: There were 2 ERROR messages, returning a non-zero exit code.
>
> crane@Ubuntu2204:~/yocto-pi/build$
>
> =
>
> I don't understand why it tries to parse core-image-testcontroller.bb, which 
> I don't intentionally use at all.
> I am afraid that the process to create a new machine is not correct.
>
> Does anyone can help with understanding what is missing here? Or it is not 
> the correct way to create a new machine for raspberrypi?

What does your new machine conf looks like ?
Generally you do something like

MACHINEOVERRIDES =. "raspberrypi3:"
include conf/machine/raspberrypi3.conf

>
> Thanks!
> Crane
> 
>

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

Re: [yocto] Add different PREFERRED_VERSION of recipe to different images

[Khem Raj]

On Wed, Jul 26, 2023 at 12:54 AM Priyanshu Sharma
 wrote:
>
> I have two images in same custom layer : A-image.bb & B-image.bb
>
> I want to add readline_5.2.bb in A-image.bb & readline_8.2.bb in B-image.bb. 
> How can I achieve this?

It can not be done at image scope but at config metadata e.g. distro
or machine config.

>
> Adding PREFERRED_VERSION in local.conf applies to both the image recipes.
>
> Thanks,
>
>
> 
>

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

Re: [yocto] libgcc dependency

[Khem Raj]

On Mon, Jul 17, 2023 at 6:38 AM Martin Townsend  wrote:
>
> Hi,
>
> I am trying to remove all GPLv3 packages from my image.  The clang
> toolchain is used where possible and currently there are no
> dependencies on libstdc++ and as far as I can see none on libgcc but
> this library is installed in the rootfs.  I've created a script to
> parse all elf binaries to see which one dynamically links against
> libgcc but none do.  I think it's being installed due to libgcc being
> in the BASEDEPENDS but I can't see what is adding libgcc to this
> variable.  I'm using the dunfell version of yocto and base.bbclass has
>
> def base_dep_prepend(d):
> if d.getVar('INHIBIT_DEFAULT_DEPS', False):
> return ""
> return "${BASE_DEFAULT_DEPS}"
>
> BASE_DEFAULT_DEPS = "virtual/${TARGET_PREFIX}gcc
> virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
>
> BASEDEPENDS = ""
> BASEDEPENDS_class-target = "${@base_dep_prepend(d)}"
> BASEDEPENDS_class-nativesdk = "${@base_dep_prepend(d)}"
>
> but when I check the BASEDEPENDS for various recipes I get
>
> BASEDEPENDS=" clang-cross-aarch64 virtual/libc  libgcc
> virtual/aarch64-poky-linux-compilerlibs  gettext-native"
> BASEDEPENDS_class-nativesdk=" clang-cross-aarch64 virtual/libc  libgcc
>  virtual/aarch64-poky-linux-compilerlibs "
> BASEDEPENDS_class-target=" clang-cross-aarch64 virtual/libc  libgcc
> virtual/aarch64-poky-linux-compilerlibs "
>
> Is it possible to remove libgcc from the BASEDEPENDS somehow?
> Although we are using Dunfell I'm happy to move to another release if
> it's easier to achieve this.

Things are better with master and perhaps kirkstone too ( but did not try )
in yoe we use

RUNTIME = "llvm"
TC_CXX_RUNTIME = "llvm"
TOOLCHAIN = "clang"
CLANGSDK = "1"

and libgcc is not used. e.g. see below. however it still uses crt
files which maybe from gcc/glibc you might have to check
that I am talking about crtstuff

% bitbake-getvar BASEDEPENDS
NOTE: Starting bitbake server...
NOTE: Started PRServer with DBfile:
/mnt/b/yoe/master/cache/prserv.sqlite3, Address: 127.0.0.1:37359, PID:
713437
#
# $BASEDEPENDS [3 operations]
#   set /mnt/b/yoe/master/sources/poky/meta/classes-global/base.bbclass:53
# ""
#   override[class-target]:set
/mnt/b/yoe/master/sources/poky/meta/classes-global/base.bbclass:54
# "${@get_base_dep(d)}"
#   override[class-nativesdk]:set
/mnt/b/yoe/master/sources/poky/meta/classes-global/base.bbclass:55
# "${@get_base_dep(d)}"
# pre-expansion value:
#   "${@get_base_dep(d)}"
BASEDEPENDS=" clang-cross-riscv64 virtual/libc  compiler-rt libcxx"

>
> Best Regards,
> Martin.
>
> 
>

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

Re: [yocto] Creating a Software Bill of Materials in Yocto Zeus #zeus

[Khem Raj]

On Wed, Jul 12, 2023 at 10:59 PM Poornesh G ( India - Bangalore )
 wrote:
>
> Greetings !
>
> Is it possible to generate  "Software Bill of Materials" in Yocto Zeus ? Is 
> there any recommended patche for creating required bbclass for creating SBOM.
>
> INHERIT += "create-spdx"


zeus is too old for spdx stuff, I would suggest to use latest release
mickledone for best results regarding SBOMs
>
> Thanks,
>
>
> 
>

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

Re: [yocto] [meta-raspberrypi] wifi

[Khem Raj]

232906.519:5): prog-id=8 op=LOAD
>  Starting User Login Management...
>  Starting OpenSSH Key Generation...
> [  OK  ] Started D-Bus System Message Bus.
> [  OK  ] Started Configure Bluetooth Modems connected by UART.
> [  OK  ] Finished IPv4 Packet Filtering Framework.
> [  OK  ] Finished OpenSSH Key Generation.
> [  OK  ] Reached target Preparation for Network.
>  Starting Network Manager...
>  Starting Raspberry Pi bluetooth helper...
>  Starting LSB: network connection manager...
>  Starting Network Configuration...
> [9.700542] mcp251x spi0.0: MCP251x didn't enter in conf mode after reset
> [9.707859] mcp251x spi0.0: Probe failed, err=110
> [9.712832] mcp251x: probe of spi0.0 failed with error -110
> [  OK  ] Started LSB: network connection manager.
> [  OK  ] Finished Raspberry Pi bluetooth helper.
> [  OK  ] Started User Login Management.
>  Starting Bluetooth service...
> [  OK  ] Started Network Configuration.
> [9.994264] bcmgenet fd58.ethernet: configuring instance for external 
> RGMII (RX delay)
> [   10.005669] bcmgenet fd58.ethernet eth0: Link is Down
>  Starting Network Name Resolution...
> [  OK  ] Started Network Manager.
> [   10.094290] audit: type=1334 audit(1651232907.219:6): prog-id=9 op=LOAD
> [   10.101120] audit: type=1334 audit(1651232907.227:7): prog-id=10 op=LOAD
>  Starting Hostname Service...
> [  OK  ] Started Bluetooth service.
> [  OK  ] Reached target Bluetooth Support.
> [   10.205340] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [   10.210960] Bluetooth: BNEP filters: protocol multicast
> [   10.216322] Bluetooth: BNEP socket layer initialized
> [   10.240623] Bluetooth: MGMT ver 1.22
> [   10.261915] NET: Registered PF_ALG protocol family
> [  OK  ] Started Network Name Resolution.
> [  OK  ] Reached target Network.
> [  OK  ] Reached target Host and Network Name Lookups.
>  Starting DNS forwarder and DHCP server...
>  Starting Permit User Sessions...
> [  OK  ] Started Xinetd A Powerful Replacement For Inetd.
> [  OK  ] Finished Permit User Sessions.
> [  OK  ] Started Hostname Service.
> [  OK  ] Started DNS forwarder and DHCP server.
>  Starting Network Manager Script Dispatcher Service...
> [  OK  ] Started Getty on tty1.
> [  OK  ] Started Serial Getty on ttyS0.
> [  OK  ] Reached target Login Prompts.
> [  OK  ] Reached target Multi-User System.
>      Starting Weston, a Wayland…ositor, as a system service...
> [  OK  ] Started Network Manager Script Dispatcher Service.
> [   10.826800] audit: type=1334 audit(1651232907.951:8): prog-id=11 op=LOAD
> [   10.837083] audit: type=1334 audit(1651232907.959:9): prog-id=12 op=LOAD
>  Starting User Database Manager...
> [  OK  ] Started User Database Manager.
> [  OK  ] Created slice User Slice of UID 1000.
>  Starting User Runtime Directory /run/user/1000...
> [  OK  ] Finished User Runtime Directory /run/user/1000.
>  Starting User Manager for UID 1000...
> [   11.283733] audit: type=1006 audit(1651232908.407:10): pid=354 uid=0 
> old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=1 res=1
> [   11.301961] audit: type=1300 audit(1651232908.407:10): arch=c0b7 
> syscall=64 success=yes exit=4 a0=8 a1=7fcf5a02c8 a2=4 a3=0 items=0 ppid=1 
> pid=354 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
> tty=(none) ses=1 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
> [  OK  ] Started User Manager for UID 1000.
> [  OK  ] Started Session c1 of User weston.
> [   11.952188] kauditd_printk_skb: 1 callbacks suppressed
> [   11.952207] audit: type=1006 audit(1651232909.075:11): pid=348 uid=0 
> old-auid=4294967295 auid=1000 tty=tty7 old-ses=4294967295 ses=2 res=1
> [   11.971521] audit: type=1300 audit(1651232909.075:11): arch=c0b7 
> syscall=64 success=yes exit=4 a0=8 a1=7fcf5a02c8 a2=4 a3=0 items=0 ppid=1 
> pid=348 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
> tty=tty7 ses=2 comm="(weston)" exe="/lib/systemd/systemd" key=(null)
> [   11.997917] audit: type=1327 audit(1651232909.075:11): proctitle="(weston)"
> [   12.759139] vc4-drm gpu: [drm] Cannot find any crtc or sizes
> [  OK  ] Started Weston, a Wayland …mpositor, as a system service.
> [  OK  ] Reached target Graphical Interface.
>  Starting Record Runlevel Change in UTMP...
> [  OK  ] Finished Record Runlevel Change in UTMP.
>
> OpenEmbedded nodistro.0 raspberrypi4-64 ttyS0
>
> raspberrypi4-64 login: [   19.942785] platform soc:sound: deferred probe 
> pending
> [   40.664644] audit: type=1334 audit(1651232937.791:12): prog-id=10 op=UNLOAD
> [   40.671

Re: [yocto] How to exclude package from build history in Yocto?

[Khem Raj]

On Thu, Jul 6, 2023 at 2:58 PM Ehsan Mohandesi  wrote:
>
> Hi all,
> I have updated BUILDHISTORY_FEATURES=image to avoid including the package 
> directory in the build history. However, I am still seeing the package 
> directory with numerous subdirectories in the build history.
> How can I completely exclude the package directory from the build history?
> The following is what I see in the buildhistory directory.
> ~/ws/OpenBMC/build/dc-scm-m1110$ ls buildhistory
> images  metadata-revs  packages

I assume this directory buildhistory/ was created fresh after above change


> 
>

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

Re: [yocto] [meta-raspberrypi] wifi

[Khem Raj]

On Thu, Jul 6, 2023 at 9:04 AM Oosman Saeed  wrote:
>
> I think that is the problem, I don't know which wifi is used on the board. 
> How do I find out what wifi driver to load?
>

Perhaps there are clues in early kernel logs. Maybe check dmesg or serial logs.

>
>
> On Thursday, July 6, 2023 at 10:19:50 AM CDT, Khem Raj  
> wrote:
>
>
> On Thu, Jul 6, 2023 at 8:06 AM Oosman Saeed  wrote:
> >
> > root@raspberrypi4-64:~# ifconfig -a
> > eth0: flags=4163  mtu 1500
> >inet 192.168.7.8  netmask 255.255.255.0  broadcast 192.168.7.255
> >ether dc:a6:32:e3:eb:fe  txqueuelen 1000  (Ethernet)
> >RX packets 962  bytes 117191 (114.4 KiB)
> >RX errors 0  dropped 0  overruns 0  frame 0
> >TX packets 1766  bytes 299578 (292.5 KiB)
> >TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > lo: flags=73  mtu 65536
> >inet 127.0.0.1  netmask 255.0.0.0
> >inet6 ::1  prefixlen 128  scopeid 0x10
> >loop  txqueuelen 1000  (Local Loopback)
> >RX packets 12567  bytes 780277 (761.9 KiB)
> >RX errors 0  dropped 0  overruns 0  frame 0
> >TX packets 12567  bytes 780277 (761.9 KiB)
> >TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> >
> >
>
>
>
> OK in your kernel module list I dont see any kmods for wifi being loaded
> so it might be that its not enabling them in rootfs for some reason ?
> which wifi is used on your board ?
>
>
> > On Thursday, July 6, 2023 at 10:03:16 AM CDT, Khem Raj  
> > wrote:
> >
> >
> > what does ifconfig -a say
> >
> > On Thu, Jul 6, 2023 at 6:25 AM oosman3 via lists.yoctoproject.org
> >  wrote:
> > >
> > > I am building my raspberrypi wic image using the layer meta-raspberrypi.
> > >
> > > I am using a raspiberrypi compute module 4 with wifi chip.
> > >
> > > I just can't seem to get the wlan0 device to appear when I type ifconfig.
> > >
> > > 
> > > root@raspberrypi4-64:~# ifconfig
> > > eth0: flags=4163  mtu 1500
> > >inet 192.168.7.8  netmask 255.255.255.0  broadcast 192.168.7.255
> > >ether dc:a6:32:e3:eb:fe  txqueuelen 1000  (Ethernet)
> > >RX packets 407  bytes 62442 (60.9 KiB)
> > >RX errors 0  dropped 0  overruns 0  frame 0
> > >TX packets 567  bytes 94749 (92.5 KiB)
> > >TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> > >
> > > lo: flags=73  mtu 65536
> > >inet 127.0.0.1  netmask 255.0.0.0
> > >inet6 ::1  prefixlen 128  scopeid 0x10
> > >loop  txqueuelen 1000  (Local Loopback)
> > >RX packets 4047  bytes 252037 (246.1 KiB)
> > >RX errors 0  dropped 0  overruns 0  frame 0
> > >TX packets 4047  bytes 252037 (246.1 KiB)
> > >TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> > > ===
> > >
> > >
> > >
> > > Here is a filtered output of my lsmod command
> > >
> > > ===
> > > root@raspberrypi4-64:~# lsmod
> > > Module  Size  Used by
> > > 88XXau  2265088  0
> > > cmac  16384  3
> > > algif_hash16384  1
> > > aes_arm64  16384  3
> > > aes_generic36864  1 aes_arm64
> > > algif_skcipher16384  1
> > > af_alg28672  6 algif_hash,algif_skcipher
> > > bnep  24576  2
> > > 8021q  32768  0
> > > garp  16384  1 8021q
> > > stp16384  1 garp
> > > llc16384  2 stp,garp
> > > imx21924576  0
> > > mcp251x24576  0
> > > spidev20480  0
> > > can_dev40960  1 mcp251x
> > > hci_uart  45056  0
> > > btbcm  24576  1 hci_uart
> > > v3d90112  1
> > > bluetooth585728  26 hci_uart,btbcm,bnep
> > > i2c_mux_pinctrl16384  0
> > > gpu_sched  49152  1 v3d
> > > snd_soc_simple_card20480  0
> > > snd_soc_simple_card_utils28672  1 snd_soc_simple_card
> > > drm_shmem_helper  24576  1 v3d
> > > raspberrypi_hwmon  16384  0
> > > i2c_mux16384  1 i2c_mux_pinctrl
> > > i2

Re: [yocto] [meta-raspberrypi] wifi

[Khem Raj]

On Thu, Jul 6, 2023 at 8:06 AM Oosman Saeed  wrote:
>
> root@raspberrypi4-64:~# ifconfig -a
> eth0: flags=4163  mtu 1500
> inet 192.168.7.8  netmask 255.255.255.0  broadcast 192.168.7.255
> ether dc:a6:32:e3:eb:fe  txqueuelen 1000  (Ethernet)
> RX packets 962  bytes 117191 (114.4 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 1766  bytes 299578 (292.5 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 12567  bytes 780277 (761.9 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 12567  bytes 780277 (761.9 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
>
>



OK in your kernel module list I dont see any kmods for wifi being loaded
so it might be that its not enabling them in rootfs for some reason ?
which wifi is used on your board ?


> On Thursday, July 6, 2023 at 10:03:16 AM CDT, Khem Raj  
> wrote:
>
>
> what does ifconfig -a say
>
> On Thu, Jul 6, 2023 at 6:25 AM oosman3 via lists.yoctoproject.org
>  wrote:
> >
> > I am building my raspberrypi wic image using the layer meta-raspberrypi.
> >
> > I am using a raspiberrypi compute module 4 with wifi chip.
> >
> > I just can't seem to get the wlan0 device to appear when I type ifconfig.
> >
> > 
> > root@raspberrypi4-64:~# ifconfig
> > eth0: flags=4163  mtu 1500
> >inet 192.168.7.8  netmask 255.255.255.0  broadcast 192.168.7.255
> >ether dc:a6:32:e3:eb:fe  txqueuelen 1000  (Ethernet)
> >RX packets 407  bytes 62442 (60.9 KiB)
> >RX errors 0  dropped 0  overruns 0  frame 0
> >TX packets 567  bytes 94749 (92.5 KiB)
> >TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > lo: flags=73  mtu 65536
> >inet 127.0.0.1  netmask 255.0.0.0
> >inet6 ::1  prefixlen 128  scopeid 0x10
> >loop  txqueuelen 1000  (Local Loopback)
> >RX packets 4047  bytes 252037 (246.1 KiB)
> >RX errors 0  dropped 0  overruns 0  frame 0
> >TX packets 4047  bytes 252037 (246.1 KiB)
> >TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> > ===
> >
> >
> >
> > Here is a filtered output of my lsmod command
> >
> > ===
> > root@raspberrypi4-64:~# lsmod
> > Module  Size  Used by
> > 88XXau  2265088  0
> > cmac  16384  3
> > algif_hash16384  1
> > aes_arm64  16384  3
> > aes_generic36864  1 aes_arm64
> > algif_skcipher16384  1
> > af_alg28672  6 algif_hash,algif_skcipher
> > bnep  24576  2
> > 8021q  32768  0
> > garp  16384  1 8021q
> > stp16384  1 garp
> > llc16384  2 stp,garp
> > imx21924576  0
> > mcp251x24576  0
> > spidev20480  0
> > can_dev40960  1 mcp251x
> > hci_uart  45056  0
> > btbcm  24576  1 hci_uart
> > v3d90112  1
> > bluetooth585728  26 hci_uart,btbcm,bnep
> > i2c_mux_pinctrl16384  0
> > gpu_sched  49152  1 v3d
> > snd_soc_simple_card20480  0
> > snd_soc_simple_card_utils28672  1 snd_soc_simple_card
> > drm_shmem_helper  24576  1 v3d
> > raspberrypi_hwmon  16384  0
> > i2c_mux16384  1 i2c_mux_pinctrl
> > i2c_brcmstb16384  0
> > bcm2835_unicam53248  0
> > dwc2  192512  0
> > roles  20480  1 dwc2
> > v4l2_dv_timings40960  1 bcm2835_unicam
> > v4l2_fwnode24576  2 imx219,bcm2835_unicam
> > ecdh_generic  16384  2 bluetooth
> > v4l2_async24576  3 v4l2_fwnode,imx219,bcm2835_unicam
> > ecc36864  1 ecdh_generic
> > libaes16384  3 aes_arm64,bluetooth,aes_generic
> > spi_bcm283520480  0
> > snd_soc_bcm2835_i2s20480  0
> > bcm2835_codec  49152  0
> > rpivid_hevc49152  0
> > bcm2835_v4l2  45056  0
> > bcm2835_isp28672  0
> > bcm2835_mmal_vchiq36864  3 bcm2835_codec,bcm2

Re: [yocto] [meta-raspberrypi] wifi

[Khem Raj]

what does ifconfig -a say

On Thu, Jul 6, 2023 at 6:25 AM oosman3 via lists.yoctoproject.org
 wrote:
>
> I am building my raspberrypi wic image using the layer meta-raspberrypi.
>
> I am using a raspiberrypi compute module 4 with wifi chip.
>
> I just can't seem to get the wlan0 device to appear when I type ifconfig.
>
> 
> root@raspberrypi4-64:~# ifconfig
> eth0: flags=4163  mtu 1500
> inet 192.168.7.8  netmask 255.255.255.0  broadcast 192.168.7.255
> ether dc:a6:32:e3:eb:fe  txqueuelen 1000  (Ethernet)
> RX packets 407  bytes 62442 (60.9 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 567  bytes 94749 (92.5 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 4047  bytes 252037 (246.1 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 4047  bytes 252037 (246.1 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> ===
>
>
>
> Here is a filtered output of my lsmod command
>
> ===
> root@raspberrypi4-64:~# lsmod
> Module  Size  Used by
> 88XXau   2265088  0
> cmac   16384  3
> algif_hash 16384  1
> aes_arm64  16384  3
> aes_generic36864  1 aes_arm64
> algif_skcipher 16384  1
> af_alg 28672  6 algif_hash,algif_skcipher
> bnep   24576  2
> 8021q  32768  0
> garp   16384  1 8021q
> stp16384  1 garp
> llc16384  2 stp,garp
> imx219 24576  0
> mcp251x24576  0
> spidev 20480  0
> can_dev40960  1 mcp251x
> hci_uart   45056  0
> btbcm  24576  1 hci_uart
> v3d90112  1
> bluetooth 585728  26 hci_uart,btbcm,bnep
> i2c_mux_pinctrl16384  0
> gpu_sched  49152  1 v3d
> snd_soc_simple_card20480  0
> snd_soc_simple_card_utils28672  1 snd_soc_simple_card
> drm_shmem_helper   24576  1 v3d
> raspberrypi_hwmon  16384  0
> i2c_mux16384  1 i2c_mux_pinctrl
> i2c_brcmstb16384  0
> bcm2835_unicam 53248  0
> dwc2  192512  0
> roles  20480  1 dwc2
> v4l2_dv_timings40960  1 bcm2835_unicam
> v4l2_fwnode24576  2 imx219,bcm2835_unicam
> ecdh_generic   16384  2 bluetooth
> v4l2_async 24576  3 v4l2_fwnode,imx219,bcm2835_unicam
> ecc36864  1 ecdh_generic
> libaes 16384  3 aes_arm64,bluetooth,aes_generic
> spi_bcm283520480  0
> snd_soc_bcm2835_i2s20480  0
> bcm2835_codec  49152  0
> rpivid_hevc49152  0
> bcm2835_v4l2   45056  0
> bcm2835_isp28672  0
> bcm2835_mmal_vchiq 36864  3 bcm2835_codec,bcm2835_v4l2,bcm2835_isp
> v4l2_mem2mem   40960  2 bcm2835_codec,rpivid_hevc
> videobuf2_vmalloc  16384  1 bcm2835_v4l2
> videobuf2_dma_contig20480  4 
> bcm2835_codec,bcm2835_unicam,rpivid_hevc,bcm2835_isp
> videobuf2_memops   16384  2 videobuf2_vmalloc,videobuf2_dma_contig
> videobuf2_v4l2 32768  6 
> bcm2835_codec,bcm2835_unicam,bcm2835_v4l2,rpivid_hevc,v4l2_mem2mem,bcm2835_isp
> videobuf2_common   69632  10 
> bcm2835_codec,videobuf2_vmalloc,videobuf2_dma_contig,videobuf2_v4l2,bcm2835_unicam,bcm2835_v4l2,rpivid_hevc,v4l2_mem2mem,videobuf2_memops,bcm2835_isp
> videodev  274432  10 
> v4l2_async,bcm2835_codec,imx219,videobuf2_v4l2,bcm2835_unicam,bcm2835_v4l2,videobuf2_common,rpivid_hevc,v4l2_mem2mem,bcm2835_isp
> vc_sm_cma  32768  2 bcm2835_mmal_vchiq,bcm2835_isp
> snd_bcm283528672  0
> mc 61440  10 
> v4l2_async,videodev,bcm2835_codec,imx219,videobuf2_v4l2,bcm2835_unicam,videobuf2_common,rpivid_hevc,v4l2_mem2mem,bcm2835_isp
> uio_pdrv_genirq16384  0
> nvmem_rmem 16384  0
> uio24576  1 uio_pdrv_genirq
> sch_fq_codel   20480  6
> brcmutil   24576  0
> cfg80211  929792  1 88XXau
> rfkill 32768  4 bluetooth,cfg80211
> fuse  139264  1
> ipv6  552960  28
>
> 
>
> And here is my /boot/config.txt
>
> root@raspberrypi4-64:~# cat /boot/config.txt
> 
> ##  Raspberry Pi Configuration Settings
> ##
> ##  Revision 16, 2013/06/22
> ##
> ##  Details taken from the eLinux wiki
> ##  For up-to-date information please refer to wiki page.
> ##
> ##  Wiki Location : http://elinux.org/RPiconfig
> ##
> ##
> 

Re: [yocto] poky master weston failed to start

[Khem Raj]

On Tue, Jul 4, 2023 at 2:47 PM Marek Belisko  wrote:
>
> Hi,
>
> I'm using tip of poky master and build weston image for bananapi-m64 board. 
> Board boots fine but weston is not started and in log I see:
>
>  Jul 04 21:42:28 bananapi-m64 systemd[1]: Starting Weston, a Wayland 
> compositor, as a system service...
> [  306.464755] audit: type=1006 audit(1688506948.933:18): pid=377 uid=0 
> old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=10 res=1
> [  306.48] audit: type=1300 audit(1688506948.933:18): arch=c0b7 
> syscall=64 success=yes exit=4 a0=8 a1=fcdd7050 a2=4 a3=1 items=0 ppid=1 
> pid=377 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
> tty=(none) ses=10
>  comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
> [  306.504195] audit: type=1327 audit(1688506948.933:18): 
> proctitle="(systemd)"
> [  306.942909] audit: type=1006 audit(1688506949.409:19): pid=375 uid=0 
> old-auid=4294967295 auid=1000 tty=tty7 old-ses=4294967295 ses=11 res=1
> [  306.955818] audit: type=1300 audit(1688506949.409:19): arch=c0b7 
> syscall=64 success=yes exit=4 a0=8 a1=fcdd7050 a2=4 a3=1 items=0 ppid=1 
> pid=375 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
> tty=tty7 ses=11 c
> omm="(weston)" exe="/lib/systemd/systemd" key=(null)
> [  306.981861] audit: type=1327 audit(1688506949.409:19): proctitle="(weston)"
> root@bananapi-m64:~# [  307.474004] audit: type=1701 
> audit(1688506949.941:20): auid=1000 uid=1000 gid=1000 ses=11 pid=375 
> comm="weston" exe="/usr/bin/weston" sig=11 res=1
> Jul 04 21:42:29 bananapi-m64 systemd[1]: Started Weston, a Wayland 
> compositor, as a system service.
> Jul 04 21:42:29 bananapi-m64 systemd[1]: weston.service: Main process exited, 
> code=killed, status=11/SEGV

It seems weston is segfaulting. So you want to find out why ?

> Jul 04 21:42:29 bananapi-m64 systemd[1]: weston.service: Failed with result 
> 'signal'.
>
>
> When try to run command manually I'm getting:
> root@bananapi-m64:~# /usr/bin/weston --debug --modules=systemd-notify.so
> Date: 2023-07-04 UTC
> [21:43:49.208] weston 12.0.1
>https://wayland.freedesktop.org
>Bug reports to: 
> https://gitlab.freedesktop.org/wayland/weston/issues/
>Build: 12.0.1
> [21:43:49.208] Command line: /usr/bin/weston --debug 
> --modules=systemd-notify.so
> [21:43:49.208] OS: Linux, 6.1.9, #1 SMP PREEMPT Wed Feb  1 07:38:58 UTC 2023, 
> aarch64
> [21:43:49.208] Flight recorder: enabled
> [21:43:49.208] Using config file '/etc/xdg/weston/weston.ini'
> WARNING: debug protocol has been enabled. This is a potential 
> denial-of-service attack vector and information leak.
> [21:43:49.209] Output repaint window is 7 ms maximum.
> [21:43:49.209] Loading module '/usr/lib/libweston-12/wayland-backend.so'
> [21:43:49.255] Error: Failed to connect to parent Wayland compositor: No such 
> file or directory
>display option: (none), WAYLAND_DISPLAY=/run/wayland-0
> [21:43:49.255] fatal: failed to create compositor backend
>
> Any idea what I'm missing to make it working? On mickledore weston works just 
> fine.
>
> 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
>
> 
>

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

[Khem Raj]

On Mon, Jul 3, 2023 at 7:25 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.
>

yes go mod vendor is a way to get this working in a reasonable way.
This also avoid go's module management coming in way of
bitbake fetcher.

> But, the repo will get a lot larger that way. But, that fulfills the Yocto 
> demands as far as I know.

As a distro, I think this should be even preferred even though size is
bigger and several modules will be duplicated per recipe if
there are other go packages in image. As a developer this might be not
preferred however.

>
>
>
> 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.
>
>
> 
>

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