Re: [yocto] Correct way for multiple recipes to install files in the same directory

[Markus Volk]

On Fri, Apr 12 2024 at 09:14:45 AM -07:00:00, Linus Nilsson 
 wrote:
I haven't worked with the classes yet but I can see how they can be 
used to make things a lot easier in my case.


But don't use classen too invasively. They can be problematic, e.g. an 
:append may be ignored depending on the BBFILE_PRIORITY of a layer



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

Re: [yocto] Correct way for multiple recipes to install files in the same directory

[Markus Volk]

On Thu, Apr 11 2024 at 12:52:49 AM -07:00:00, linusnils...@hotmail.com 
wrote:

Is there a proper way to do this?

Kind regards, Linus


Hi,
can't tell if this would be a proper way, but this is how I do it and 
what works for me:


Create a main user:


Inherit a main-user class for every recipe that wants to write stuff to 
/home/user



You can override the values set in main-user.bbclass to fit your needs 
in e.g. local.conf


Regards,
Markus



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

Re: [yocto] Yocto Project Quick Build - MACHINE

[Markus Volk]

On Thu, Mar 7 2024 at 03:46:30 PM -08:00:00, Worik Stanton 
 wrote:

What have I done wrong?


Hi,
did you add meta-altera here?

build/conf/bblayers.conf


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

[Markus Volk]

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

Re: [yocto] Building Tailscale with Yocto #golang

[Markus Volk]

You need to allow network connection for the do_compile task

do_compile[network] = "1"


On Sun, Jul 2 2023 at 12:45:40 PM -0700, przemek.re...@gmail.com wrote:

Hi!
I'm trying to build Tailscale with Yocto
This is me recipe:

inherit go-mod

SRC_URI = 
"git://github.com/tailscale/tailscale;protocol=https;branch=main"

SRCREV = "30d9201a11ebc2e3a0f17bf8963956b77dadeb5d"

GO_IMPORT = "tailscale.com"
GO_WORKDIR = "${GO_IMPORT}"
GO_INSTALL = "\
${GO_IMPORT}/cmd/tailscale \
${GO_IMPORT}/cmd/tailscaled \
"

do_install() {
install -d ${D}/${bindir}
install -d ${D}/${sbindir}
install ${B}/bin/tailscale ${D}/${bindir}/tailscale
install ${B}/bin/tailscaled ${D}/${sbindir}/tailscaled
}


However, build step ends up with errors like these (full log):

| wgengine/netstack/netstack.go:34:2: 
gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
"https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip": 
dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
connect: network is unreachable
| wgengine/netstack/netstack.go:35:2: 
gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
"https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip": 
dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
connect: network is unreachable
| net/tstun/tap_linux.go:23:2: 
gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
"https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip": 
dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
connect: network is unreachable
| wgengine/netstack/netstack.go:37:2: 
gvisor.dev/gvisor@v0.0.0-20230504175454-7b0a1988a28f: Get 
"https://proxy.golang.org/gvisor.dev/gvisor/@v/v0.0.0-20230504175454-7b0a1988a28f.zip": 
dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
connect: network is unreachable
| ipn/ipnauth/ipnauth.go:16:2: 
inet.af/peercred@v0.0.0-20210906144145-0893ea02156a: Get 
"https://proxy.golang.org/inet.af/peercred/@v/v0.0.0-20210906144145-0893ea02156a.zip": 
dial tcp: lookup proxy.golang.org on 8.8.8.8:53: dial udp 8.8.8.8:53: 
connect: network is unreachable


On some resources I have found it was recomended to add environmental 
variables: `GOPROXY="direct"` and `GOSUMDB="off"`, but it didn't 
helped.


Maybe someone has some ideas what is the cause of these errors?



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

Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

[Markus Volk]

On Sun, Jun 25 2023 at 12:01:29 AM +0200, Manuel Wagesreither 
 wrote:
The HDMI port is unused on my raspi. I'm using the official Raspberry 
Pi 7" Touchscreen connected via DSI.


Have you also added ?

dtoverlay=vc4-kms-dsi-7inch
dtoverlay=rpi-ft5406

I never dealt with the 7'' Display but i guess they are needed for kms

hdmi_force_hotplug=1

may also be needed


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

Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

[Markus Volk]

Two pitfalls come to mind here

It used to be necessary to use vc4-kms-v3d-pi4 dtbo. At some point this 
was changed so that even for the rpi4 only vc4-kms-v3d overlay had to 
be loaded and vc4-kms-v3d-pi4 was automatically reloaded. If your 
software version is old enough, using vc4-kms-v3d-pi4 dtoverlay might 
be necessary.


kms relies completely on edid. fkms is more tolerant and often displays 
an image without a valid edid. I would therefore most likely guess a 
problem reading the edit information. Things I would try first are 
using  a different HDMI cable or switching the hdmi port.


On Sat, Jun 24 2023 at 06:02:52 PM +0200, Manuel Wagesreither 
 wrote:

Am Sa, 24. Jun 2023, um 17:25, schrieb Khem Raj:
On Sat, Jun 24, 2023 at 7:47 AM Manuel Wagesreither 
mailto:man...@fastmail.fm>> wrote:

Am Sa, 24. Jun 2023, um 00:04, schrieb Khem Raj:
> On Fri, Jun 23, 2023 at 2:39 PM Manuel Wagesreither 
mailto:man...@fastmail.fm>> wrote:

>>
>> Hi users of meta-raspberrypi,
>>
>> I'd like to ask around if for you people vc4-kms-v3d (opposed to 
vc4-fkms-v3d) *really* is the working way to get vc4 support on a 
Raspberry Pi 4 Model B.

>>
>> Both on master and kirkstone, vc4-kms-v3d is the default. It's 
defined in /conf/machine/raspberrypi4-64.conf:

>>
>> VC4DTBO ?= "vc4-kms-v3d"
>>
>> I was mildly surprised to find this, because on my system 
(running Kirkstone) I can get the screen to work only if I specify 
vc4-fkms-v3d.

>>
>> Commit a6fa6b3aec36b92c3750852dd6788af9d2ce08f6 [1] broke my 
build. The commit message further suggests that vc4-Fkms-v3d is 
broken, while vc4-kms-v3d is not. So I'm wondering:hy is it exactly 
the other way round on my machine?

>>
>> raspberrypi4: Use full kms (vc4-kms-v3d) DT overlay
>>
>> With latest 5.10 kernel fkms version fails to bring up VC4 
and we do not
>> get dri device initialized ( /dev/dri ) is empty, which 
means we can not

>> launch wayland componsitors.
>>
>
> We have moved away from 5.10 kernel to 5.15 and then 6.1, so its
> possible that fkms is working fine again.
> If you test it with both vc4graphics and userland graphics do 
both work ?


The meta-raspberrypi commit I'm on 
(a6fa6b3aec36b92c3750852dd6788af9d2ce08f6) has recipes for Linux 
5.10.110 and 5.15.34 and on both of them vc4-fkms-v3d works while 
vc4-kms-v3d does not.


* When using vc4-kms-v3d, the screen goes dark very early in the 
boot process.

* When using vc4-kms-v3d, kmscube and weston-wayland both work.


Which release branch are you using for
Your project


I'm two commits behind kirkstone, on meta-raspberrypi.



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

Re: [yocto] resize2fs, what's provide this package

[Markus Volk]

Hi,
you need to install 'e2fsprogs-resize2fs'

Am Di, 21. Feb 2023 um 13:02:56 -0800 schrieb Martin Leduc via 
lists.yoctoproject.org 
:

Hi community,

I look for the resize2fs recipes.  This application shall be included 
in the e2fsprog package but it's not there.  I've also tried to 
configure the e2fsprog package using menuconfig without any success 
(bitbake -c menuconfig e2fsprog).


Normally I use https://layers.openembedded.org 
 to find the recipes for required 
packages but this time, everything points me to the e2fsprog recipes 
but it doesn't work for me.


Any idea and another system to find which meta-* provides a specific 
application?


Thank you, team,

Have a nice day

Martin



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

Re: [yocto] Hardware accelerated video decoding and display on AMD hardware?

[Markus Volk]

You need to enable gallium-llvm and r600 PACKAGECONFIGS for mesa to 
build the radeonsi driver


On Sat, Jan 28 2023 at 08:07:28 PM -0700, Ori Pessach 
 wrote:

Thanks.

Unfortunately, neither xf86-video-amdgpu nor linux-firmware seem to 
be available. meta-amd certainly doesn't have them, and  
xf86-video-amdgpu is only in a newer branch of meta-oe than the one 
I'm currently using.


xf86-video-ati is available and I already use it - it doesn't 
accelerate OpenGL or video decoding, unfortunately.


Regarding meta-amd, its FEATURES.md suggests that it doesn't support 
any multimedia features on any of its targeted machines. I'm left 
wondering what it does support...


Any other suggestions? Or ideas why the mesa recipe doesn't want to 
build the radeonsi driver even though the version I'm building 
(21.2.4) seems to include it?


Thanks,

Ori Pessach

On Sat, Jan 28, 2023 at 4:29 PM Tim Orling > wrote:



On Sat, Jan 28, 2023 at 2:47 PM Ori Pessach > wrote:

Hello,

I asked this on the meta-amd mailing list but got no response.

Can anyone tell me what needs to be added to an image if I want to 
enable accelerated video decoding and display on commodity (PC) AMD 
hardware?


The image is currently running Xorg and, at least on Intel 
hardware, is capable of accelerated decoding and display using 
VAAPI and OpenGL. The user application uses gstreamer for decoding 
and display.


I donā€™t have any direct experience, but a search for ā€œRadeonā€ 
on layerindex gives some hints:



So you probably want xf86-video-amdgpu and linux-firmware-amdgpu.



Thanks,

Ori Pessach






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

Re: [yocto] recipe won't build, missing pseudo

[Markus Volk]

Am Mo, 26. Dez 2022 um 18:54:01 -0800 schrieb Mistyron 
:

Hi,

I'm want to write a recipe to compile phytool but I'm getting the 
below error when building it with:

$ bitbake -b phytool_2.0
ERROR: Failed to spawn fakeroot worker to run 
/home/yocto/rzg_vlp_v3.0.0/build/../meta-mistysom/recipes-bringup/phytool/phytool_2.0.bb:do_install: 
[Errno 2] No such file or directory: 
'/home/yocto/rzg_vlp_v3.0.0/build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo'


my bb file looks like:

[phytool_2.0.bb]
DESCRIPTION = "Recipe builds phytool utility"
# Needs to be changed to GPLv2
LICENSE = "MIT"
SRC_URI = "git://github.com/MistySOM/phytool.git"
SRCREV = "8882328c08ba2efb13c049812098f1d0cb8adf0c"
LIC_FILES_CHKSUM = 
"file://../git/LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0" 


INHERIT += " pseudo"

python do_display_banner() {
bb.plain("some message")
}

addtask display_banner before do_build
[/phytool_2.0.bb]

It appears like my INHERIT line does not satsify the requirement.
How can I resolve this?

--
RON EGGLER Firmware Engineer (he/him/his) www.mistywest.com 








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

Re: [yocto] lsusb

[Markus Volk]

Am Sa, 24. Dez 2022 um 08:34:49 -0800 schrieb Mistyron 
:

$ grep usb path/to/package.manifest
  libusb-1.0-0
  usbutils
  usbutils-python


lsusb is part of usbutils, so it is not explicitly listed, but should 
be included in your image



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

Re: [yocto] undefined reference problem persists

[Markus Volk]

Am So, 6. Nov 2022 um 00:45:36 -0700 schrieb Mistyron 
:
| 
/usr/src/debug/lrd-networkmanager-sterling/10.4.0.10-r0/build/../lrd-network-manager-10.4.0.10/src/nmcli/common.c:904: 
undefined reference to `rl_echo_signal_char'


missing readline dependency ?


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

Re: [yocto] Adding Vulkan to core-image-weston

[Markus Volk]

Am Mo, 19. Sep 2022 um 16:54:52 + schrieb Edgar Mobile 
:

This wasn't enough


i guess you would also need to add venus support to virglrenderer.bb 
for qemu:


DEPENDS:append = "vulkan-loader vulkan-headers"
EXTRA_OEMESON += "-Dvenus-experimental=true"

but i have never tested this


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

Re: [yocto] Adding Vulkan to core-image-weston

[Markus Volk]

Am Mo, 19. Sep 2022 um 16:33:11 +0100 schrieb Alexander Kanavin 
:
You need to check the Mesa recipe to see how the build options are 
defined


mesa builds vulkan support, if you add 'vulkan' to DISTRO_FEATURES. If 
you need to, you can add additional drivers with a line like this to a 
mesa_%.bbappend:


VULKAN_DRIVERS:append = ",foo,bar"


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

Re: [yocto] wget - The certificate has not yet been activated

[Markus Volk]

Hi Matthias,

check if busybox is built with this option

CONFIG_FEATURE_WGET_OPENSSL=y



On Thu, Feb 3 2022 at 06:37:01 AM +, Matthias Klein 
 wrote:

Hello,

I have with the current master branch in a IMX6 Yocto the problem 
that with wget no HTTPS downloads work:


# wget -4 
--2022-02-03 06:23:25--  
SSL_INIT
Resolving speed.hetzner.de... 88.198.248.254
Connecting to speed.hetzner.de|88.198.248.254|:443... connected.
The certificate has not yet been activated

I do not understand why the validation of the certificate does not 
work.

With curl it works. It is also not due to the time of the system.
I use my own kernel based on the mainline kernel 5.10.47 with 
PREEMPT_RT.


TARGET_SYS   = "arm-poky-linux-gnueabi"
TUNE_FEATURES= "arm vfp cortexa9 neon thumb 
callconvention-hard"

TARGET_FPU   = "hard"

Can it be that something is missing in the kernel configuration?
Does anyone have any idea what the problem could be?

# wget --version
GNU Wget 1.21.2 built on linux-gnueabi.

-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink +nls
+ntlm +opie -psl +ssl/gnutls

Wgetrc:
/etc/wgetrc (system)
Locale:
/usr/share/locale
Compile:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DHAVE_CONFIG_H
-DSYSTEM_WGETRC="/etc/wgetrc" -DLOCALEDIR="/usr/share/locale" -I.
-I../../wget-1.21.2/src -I../lib -I../../wget-1.21.2/lib -DNDEBUG
-O2 -pipe -g -feliminate-unused-debug-types
Link:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DNDEBUG -O2
-pipe -g -feliminate-unused-debug-types -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -lpcre
-lnettle -lgnutls -lz ftp-opie.o gnutls.o http-ntlm.o
../lib/libgnu.a -lunistring

Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic .
Please send bug reports and questions to .

A test with gnutls-cli seems to work though:

root@smartrail-8037:~# gnutls-cli -d 1 imap.gmail.com -p 993
Processed 127 CA certificate(s).
Resolving 'imap.gmail.com:993'...
Connecting to '2a00:1450:4013:c02::6d:993'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=imap.gmail.com', issuer `CN=GTS CA 1C3,O=Google Trust 
Services LLC,C=US', serial 0x65fa03b5a71a05070a00012e04f6, 
EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2022-01-10 
03:07:10 UTC', expires `2022-04-04 03:07:09 UTC', 
pin-sha256="ZrSVXSwpcGu6oCbquwHwx6H2FM7DjzANRxMjQUC/Ng8="

Public Key ID:
sha1:ae10ac489504779956e7acfc17631471be3e20d6

sha256:66b4955d2c29706bbaa026eabb01f0c7a1f614cec38f300d4713234140bf360f

Public Key PIN:

pin-sha256:ZrSVXSwpcGu6oCbquwHwx6H2FM7DjzANRxMjQUC/Ng8=


- Certificate[1] info:
 - subject `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', issuer 
`CN=GTS Root R1,O=Google Trust Services LLC,C=US', serial 
0x0203bc53596b34c718f5015066, RSA key 2048 bits, signed using 
RSA-SHA256, activated `2020-08-13 00:00:42 UTC', expires `2027-09-30 
00:00:42 UTC', 
pin-sha256="zCTnfLwLKbS9S2sbp+uFz4KZOocFvXxkV06Ce9O5M2w="

- Certificate[2] info:
 - subject `CN=GTS Root R1,O=Google Trust Services LLC,C=US', issuer 
`CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE', serial 
0x77bd0d6cdb36f91aea210fc4f058d30d, RSA key 4096 bits, signed using 
RSA-SHA256, activated `2020-06-19 00:00:42 UTC', expires `2028-01-28 
00:00:42 UTC', 
pin-sha256="hxqRlPTu1bMS/0DITB1SSu0vd4u/8l8TjPgfaAp63Gc="

- Status: The certificate is trusted.
- Description: 
(TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
- Session ID: 
FB:E7:27:9D:B0:8F:4C:2D:0C:5C:E9:17:0F:5C:9B:28:EE:3F:C0:38:0C:43:15:8D:9B:73:A7:AA:BD:AA:F9:87

- Options:
- Handshake was completed

- Simple Client Mode:

* OK Gimap ready for requests from 
2a02:908:4c16:7960:20c:c6ff:fe81:e7fa k10mb249481499edf


Best regargds,
Matthias








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

Re: [yocto] /bin/sh: 1: bison: not found while compiling own kernel module with poky-dunfell #bitbake

[Markus Volk]

hello,

try to add 'bison-native' to DEPENDS.

Am 29.12.21 um 07:16 schrieb prashantsi...@dialtronics.com:

hello team,
I'm trying to build my own kernel module with yocto for raspberry-pi 
kernel, but it's giving me error that "*bison not found*", as-


DEBUG: Executing shell function do_compile
NOTE: make -j 12 
KERNEL_SRC=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source 
KSRC=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts 
KERNEL_PATH=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source 
KERNEL_VERSION=5.4.72-v7 CC=arm-poky-linux-gnueabi-gcc 
-mno-thumb-interwork -marm -fuse-ld=bfd 
-fmacro-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0=/usr/src/debug/ax88772/1.0-r0 
-fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0=/usr/src/debug/ax88772/1.0-r0 
-fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0/recipe-sysroot= 
-fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0/recipe-sysroot-native= 
-fdebug-prefix-map=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source=/usr/src/kernel 
LD=arm-poky-linux-gnueabi-ld.bfd   AR=arm-poky-linux-gnueabi-ar 
O=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts 
KBUILD_EXTRA_SYMBOLS=
make -C 
/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts 
SUBDIRS=/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work/raspberrypi3-poky-linux-gnueabi/ax88772/1.0-r0 
modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent 
make rule.
make[1]: Entering directory 
'/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts'

  GEN Makefile
  YACC    scripts/kconfig/parser.tab.[ch]
/bin/sh: 1: bison: not found
make[4]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] 
Error 127
make[3]: *** 
[/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:590: 
syncconfig] Error 2
make[2]: *** 
[/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:696: 
include/config/auto.conf.cmd] Error 2
make[1]: *** 
[/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-source/Makefile:179: 
sub-make] Error 2
make[1]: Leaving directory 
'/home/dialtronics/DIALT_WORK/RPI_YOCTO/PS_RPI_BUILD/FXS_BSP/workspace/FXS/tmp/work-shared/raspberrypi3/kernel-build-artifacts'

make: *** [Makefile:19: default] Error 2
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.


*Here is my bb file for the same-*

SUMMARY = "WAN IC asix kernel module"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=014e508ee78ef83e5007b9cb3834f0e9"

DEPENDS = "virtual/kernel bc bison"

inherit module

PR = "r0"
PV = "1.0"

SRC_URI = "file://Makefile \
  file://asix.c \
  file://asix.h \
  file://axusbnet.c \
  file://axusbnet.h \
  file://command.h \
  file://debug.txt \
  file://eeprom_data.tar.bz2 \
  file://ioctl.c \
  file://ioctl.h \
  file://ioctl_readme \
  file://readme \
  file://readme \
  file://LICENSE \
"

S = "${WORKDIR}"

export TARGET_SYS
EXTRA_OEMAKE += "KSRC=${STAGING_KERNEL_BUILDDIR}"

do_compile_append() {
    ${CC} ioctl.c -o ioctl
}

do_install_prepend() {
    export DESTDIR="${D}"
}




# The inherit of module.bbclass will automatically name module 
packages with

# "kernel-module-" prefix as required by the oe-core build environment.



Same kernel module with poky zeus and rpi kernel 4.19 got compiled 
successfully, but here I'm getting issue with poky dunfell with Rpi 
kernel 5.4


Please help me resolve this issue.

Thanks.




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

[yocto] [OE-core] [PATCH] libva: move wayland PACKAGECONFIG to libva.inc

[Markus Volk]

I encountered an error while trying to build libva under wayland. libva-initial
was missing wayland-native dependency and failed like this:

| Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
| Run-time dependency wayland-client found: YES 1.19.0
| Program wayland-scanner /usr/bin/wayland-scanner found: NO
|
| ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner 
/usr/bin/wayland-scanner' not found
|
| A full log can be found at 
/home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
| ERROR: meson failed
| WARNING: exit code 1 from a shell command.

This commit moves the PACKAGECONFIG[wayland] to libva.inc to make it available 
to libva-initial also

Signed-off-by: MarkusVolk 
---
 meta/recipes-graphics/libva/libva.inc   | 7 +++
 meta/recipes-graphics/libva/libva_2.13.0.bb | 4 +---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
index bcf9757c1a..0e2721e291 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -27,3 +27,10 @@ UPSTREAM_CHECK_URI = 
"https://github.com/intel/libva/releases;
 DEPENDS = "libdrm"
 
 inherit meson pkgconfig
+
+PACKAGECONFIG:append = " \
+${@bb.utils.filter('DISTRO_FEATURES', 'wayland', d)} \
+"
+
+PACKAGECONFIG[wayland] = "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native 
wayland"
+
diff --git a/meta/recipes-graphics/libva/libva_2.13.0.bb 
b/meta/recipes-graphics/libva/libva_2.13.0.bb
index ed2be289fc..a8c6355b01 100644
--- a/meta/recipes-graphics/libva/libva_2.13.0.bb
+++ b/meta/recipes-graphics/libva/libva_2.13.0.bb
@@ -2,14 +2,12 @@ require libva.inc
 
 PACKAGECONFIG ??= " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)} \
-${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
+${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
 "
 
 PACKAGECONFIG[x11] = "-Dwith_x11=yes,-Dwith_x11=no,virtual/libx11 libxext 
libxfixes"
 PACKAGECONFIG[glx] = "-Dwith_glx=yes,-Dwith_glx=no,virtual/mesa"
 
-PACKAGECONFIG[wayland] = "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native 
wayland"
-
 PACKAGES =+ "${PN}-x11 ${PN}-glx ${PN}-wayland"
 
 RDEPENDS:${PN}-x11 =+ "${PN}"
-- 
2.25.1


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

[yocto][meta-rockchip][PATCH] rockchip.wks: use uuid for /boot during fstab-update

[Markus Volk]

Since the recent patch to switch to UUIDs [0aa5e600: "use uuid
instead of hard-coding root device"] wic fstab-update is not able
to get the correct value for the used device anymore and falls to
the default 'sda'. Thus wrong /dev/sda entries are generated in fstab.

For partitions that should be updated automatically this can be avoided
by either generate entries using uuid or label.

Signed-off-by: MarkusVolk 
---
 wic/rockchip.wks | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..bd36ab0 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -20,7 +20,7 @@ part reserved1  --offset 4032   --fixed-size 64K
 part reserved2  --offset 4096   --fixed-size 4096K
 part loader2--offset 8192   --fixed-size 4096K--source rawcopy 

--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
 part atf--offset 12288  --fixed-size 4096K
-part /boot  --offset 16384  --size   114688K --active --source 
bootimg-partition --fstype=vfat --label boot
--sourceparams="loader=u-boot"
+part /boot  --offset 16384  --size   114688K --active --source 
bootimg-partition --fstype=vfat --label boot
--sourceparams="loader=u-boot" --use-uuid
 part /--source rootfs  
  --fstype=ext4 --label root --use-uuid
 
 bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"
-- 
2.25.1


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

[yocto] [meta-rockchip][PATCH] use uuid instead of hard-coding root device

[Markus Volk]

Am 25.09.21 um 17:09 schrieb Trevor Woerner:

You'll need to re-send this with a better subject line and commit
message so the right people will notice it. Otherwise they'll think it's
meta-rockchip-specific.

If (when) this patch gets applied upstream, then we can remove our
work-around.


The patch has been applied :)

I had a quick look where this sda entries come from and i guess we fall to the 
default value here:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/ksparser.py#n166

We may avoid getting /dev/sda entries in fstab by either setting --use-uuid or 
--use-label for '/boot' ?


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54874): https://lists.yoctoproject.org/g/yocto/message/54874
Mute This Topic: https://lists.yoctoproject.org/mt/85688479/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] use uuid instead of hard-coding root device

[Markus Volk]

Am 23.09.21 um 22:55 schrieb Trevor Woerner:

We can add the --use-uuid line to the /boot entry if you really think it
should be mounted on boot, but we shouldn't use it on the others and cause wic
to generate a bad fstab. There are examples of other boards that don't mount
/boot by default (raspi for sure, and I think bbb too).


Could the solution be as simple as this?

From b8ba56d84fbac53901e5b7ca122498320e51fbf4 Mon Sep 17 00:00:00 2001
From: MarkusVolk 
Date: Sat, 25 Sep 2021 09:21:15 +0200
Subject: [PATCH] wic:direct.py: improve filter for fstab update

Signed-off-by: MarkusVolk 
---
 scripts/lib/wic/plugins/imager/direct.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 9d10ec01d0..15fa47356f 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -117,7 +117,7 @@ class DirectPlugin(ImagerPlugin):
 updated = False
 for part in self.parts:
 if not part.realnum or not part.mountpoint \
-   or part.mountpoint == "/":
+   or part.mountpoint == "/" or not 
part.mountpoint.startswith('/'):
 continue
 
 if part.use_uuid:

--
2.25.1

With this patch wic only adds the /boot mountpoint. The invalid entries get 
filtered out.
We would then only need to set --use-uuid for /boot to avoid the system from 
crashing if
'no-fstab-update' isn't expicitly given as an argument


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54849): https://lists.yoctoproject.org/g/yocto/message/54849
Mute This Topic: https://lists.yoctoproject.org/mt/85688479/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 v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default

[Markus Volk]

Am 24.09.21 um 15:10 schrieb Trevor Woerner:

Thanks for the patch and the SoB line. I'm going to apply this patch, but I'm
going to amend the commit message to capture some of the conversation we've
had. There's a chance we'll want to know "why" at some point in the future ;-)


Thanks for applying :)

It would be cool if wic had something like an 'exclude-from-fstab-update" 
option.
That would make the 'fstab-update' much more useful.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54848): https://lists.yoctoproject.org/g/yocto/message/54848
Mute This Topic: https://lists.yoctoproject.org/mt/85824924/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] use uuid instead of hard-coding root device

[Markus Volk]

Am 24.09.21 um 06:46 schrieb Khem Raj:

are you both using systemd or sysvinit


I am using systemd


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54841): https://lists.yoctoproject.org/g/yocto/message/54841
Mute This Topic: https://lists.yoctoproject.org/mt/85688479/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] use uuid instead of hard-coding root device

[Markus Volk]

I'm surprised mount doesn't complain about those first 5 lines! Those are not
properly-formed fstab(5) entries.


No, it doesn't. Those entries are ignored except /boot.
One interesting thing: i always had that bunch of malformed fstab entries.
Before the change from static to uuid it looked like this in fstab:

/dev/mmcblk1p1  loader1 vfatdefaults0   0
/dev/mmcblk1p2  reserved1   vfatdefaults0   0
/dev/mmcblk1p3  reserved2   vfatdefaults0   0
/dev/mmcblk1p4  loader2 vfatdefaults0   0
/dev/mmcblk1p5  atf vfatdefaults0   0
/dev/mmcblk1p6  /boot   vfatdefaults0   0

Now it looks like wic fails in getting the correct value and uses sda as a best 
bet


you're proposing (a bunch of malformed fstab(5) entries) should be considered
correct.


I guess i just got used to it because it has always been like this since i 
build for the rock-pi


In the mean time I'd like to apply your patch 2/2, if you could please add
your SoB line?


Have sent new patches. Just delete the first one if you dont need it


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

[yocto][meta-rockchip][PATCH v2 1/2] rockchip.wks: use uuid for all partitions

[Markus Volk]

My rock pi 4 refused to boot with the latest changes because there are false 
entries
written to fstab. Fix this by using uuid for all partitions

Signed-off-by: MarkusVolk 
---
 wic/rockchip.wks | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
 #   boot32768   229376
 #   root262144  -   (suggested)
 
-part loader1--offset 32 --fixed-size 4000K--source rawcopy 

--sourceparams="file=${SPL_BINARY}"
-part reserved1  --offset 4032   --fixed-size 64K
-part reserved2  --offset 4096   --fixed-size 4096K
-part loader2--offset 8192   --fixed-size 4096K--source rawcopy 

--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
-part atf--offset 12288  --fixed-size 4096K
-part /boot  --offset 16384  --size   114688K --active --source 
bootimg-partition --fstype=vfat --label boot
--sourceparams="loader=u-boot"
-part /--source rootfs  
  --fstype=ext4 --label root --use-uuid
+part loader1   --offset 32 --fixed-size 4000K --source rawcopy 
--sourceparams="file=${SPL_BINARY}" --use-uuid
+part reserved1 --offset 4032 --fixed-size 64K --use-uuid
+part reserved2 --offset 4096 --fixed-size 4096K --use-uuid
+part loader2   --offset 8192 --fixed-size 4096K --source rawcopy 
--sourceparams="file=u-boot.${UBOOT_SUFFIX}" --use-uuid
+part atf   --offset 12288 --fixed-size 4096K --use-uuid
+part /boot --offset 16384 --size 114688K --active --source 
bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot" 
--use-uuid
+part / --source rootfs --fstype=ext4 --label root --use-uuid
 
-bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"
-- 
2.25.1


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

[yocto][meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default

[Markus Volk]

Signed-off-by: MarkusVolk 
---
 conf/machine/include/rockchip-wic.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc 
b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
SPL_BINARY \
UBOOT_SUFFIX \
"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54826): https://lists.yoctoproject.org/g/yocto/message/54826
Mute This Topic: https://lists.yoctoproject.org/mt/85824924/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] use uuid instead of hard-coding root device

[Markus Volk]

Am 23.09.21 um 13:59 schrieb Trevor Woerner:

Curious. I boot tested my patch on multiple boards and I've built and booted
numerous images on my rock-pi-4b and rock64 boards in the last day or so since
I applied the patch. I'll try some "clean" builds and see if that makes a
difference. I don't doubt your report (especially since Khem confirmed it),
I'd just like to know for myself what's different.


That is really strange. As soon as there are those /dev/sda* entries in my fstab
my rock-pi-4c doesn't boot up anymore. As soon as i comment them out or delete 
them,
everything is working again.


I wonder if just applying your 2nd patch would be enough (i.e. the one that
removes the /dev/sda* lines from /etc/fstab)? It's odd that the first 6
entries in the wic file would need UUIDs since it's the SoC's ROM firmware
that uses them, and I'm pretty sure the Rockchip firmware isn't using UUIDs
(my guess is it's just blindly grabbing whatever it finds at specific
offsets). The things stored in those partitions are u-boot related bits (atf,
spl, the u-boot binary itself) so by the time Linux starts, those things are
already "behind" us. I can't see how adding UUIDs to the partitions holding
u-boot would affect how the kernel finds the root partition (?).


Applying only the second patch should be enough to hide the problem, but as 
soon as
one decides to disable WIC_CREATE_EXTRA_ARGS for example because he/she wants 
/boot to be
mounted automatically, those non working /dev/sda* entries will be written into 
fstab again.
With the first patch they are included like this and are mountable via fstab:


UUID=0C48-9342  loader1 vfatdefaults0   0
UUID=C4D3-D17A  reserved1   vfatdefaults0   0
UUID=8FBE-2551  reserved2   vfatdefaults0   0
UUID=35FA-8BBB  loader2 vfatdefaults0   0
UUID=CFF3-5D80  atf vfatdefaults0   0
UUID=832C-48C4  /boot   vfatdefaults0   0


u-boot is able to find its partitons even if '--use-uuid' is set. As you 
mentioned u-boot doesn't
know about uuid but it seems to be able to find its partitions nevertheless. 
But if '--use-uuid'
is not set, wic writes /dev/sda* instead of the correct  UUID values to fstab. 
So its not u-boot that
needs uuid to be set but fstab.
Of course it would be nice, if wic didn't try to add the u-boot partitions to 
fstab at all.
I guess nobody ever needs to have them mounted into userspace ( except possibly 
/boot).


Are you using poky or a distro other than "nodistro"? Perhaps other
layers/distros are affecting the build?


Thats not unlikely. I have a long layer-list in bblayers.conf to build my image:

  /home/flk/build/poky/meta \
  /home/flk/build/poky/meta-poky \
  /home/flk/build/poky/meta-yocto-bsp \
  /home/flk/build/poky/meta-rockchip \
  /home/flk/build/poky/meta-rockchip-extras \
  /home/flk/build/poky/meta-wayland \
  /home/flk/build/poky/meta-retro \
  /home/flk/build/poky/meta-retro-wayland \
  /home/flk/build/poky/meta-rauc \
  /home/flk/build/poky/meta-openembedded/meta-oe \
  /home/flk/build/poky/meta-openembedded/meta-multimedia \
  /home/flk/build/poky/meta-openembedded/meta-networking \
  /home/flk/build/poky/meta-openembedded/meta-xfce \
  /home/flk/build/poky/meta-openembedded/meta-gnome \
  /home/flk/build/poky/meta-openembedded/meta-python \
  /home/flk/build/poky/meta-openembedded/meta-filesystems \
  /home/flk/build/poky/meta-arm/meta-arm \
  /home/flk/build/poky/meta-arm/meta-arm-toolchain \
  /home/flk/build/poky/meta-kodi \
  /home/flk/build/poky/meta-browser/meta-chromium \
  /home/flk/build/poky/meta-browser/meta-firefox \
  /home/flk/build/poky/meta-clang \


best regards,

  Markus


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

[yocto] [meta-rockchip][PATCH 1/2] rockchip.wks: use uuid for all partitions

[Markus Volk]

My rock pi 4 refused to boot with the latest changes because there are false 
entries
written to fstab. Fix this by using uuid for all partitions
---
 wic/rockchip.wks | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
 #   boot32768   229376
 #   root262144  -   (suggested)
 
-part loader1--offset 32 --fixed-size 4000K--source rawcopy 

--sourceparams="file=${SPL_BINARY}"
-part reserved1  --offset 4032   --fixed-size 64K
-part reserved2  --offset 4096   --fixed-size 4096K
-part loader2--offset 8192   --fixed-size 4096K--source rawcopy 

--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
-part atf--offset 12288  --fixed-size 4096K
-part /boot  --offset 16384  --size   114688K --active --source 
bootimg-partition --fstype=vfat --label boot
--sourceparams="loader=u-boot"
-part /--source rootfs  
  --fstype=ext4 --label root --use-uuid
+part loader1   --offset 32 --fixed-size 4000K --source rawcopy 
--sourceparams="file=${SPL_BINARY}" --use-uuid
+part reserved1 --offset 4032 --fixed-size 64K --use-uuid
+part reserved2 --offset 4096 --fixed-size 4096K --use-uuid
+part loader2   --offset 8192 --fixed-size 4096K --source rawcopy 
--sourceparams="file=u-boot.${UBOOT_SUFFIX}" --use-uuid
+part atf   --offset 12288 --fixed-size 4096K --use-uuid
+part /boot --offset 16384 --size 114688K --active --source 
bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot" 
--use-uuid
+part / --source rootfs --fstype=ext4 --label root --use-uuid
 
-bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"
-- 
2.25.1


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

[yocto] [meta-rockchip][PATCH 2/2] rockchip-wic.inc: dont let wic edit fstab by default

[Markus Volk]

---
 conf/machine/include/rockchip-wic.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc 
b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
SPL_BINARY \
UBOOT_SUFFIX \
"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54803): https://lists.yoctoproject.org/g/yocto/message/54803
Mute This Topic: https://lists.yoctoproject.org/mt/85797881/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] use uuid instead of hard-coding root device

[Markus Volk]

Hi,

with this change my rock-pi-4 doesnt boot up and falls to emergency 
shell because wic includes wrong devices into fstab. For some reason it 
assumes /dev/sda1. I was able to fix this for my machine by using uuid 
for all partitions.


diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
 #   boot    32768   229376
 #   root    262144  -   (suggested)

-part loader1    --offset 32 --fixed-size 4000K --source rawcopy 
--sourceparams="file=${SPL_BINARY}"

-part reserved1  --offset 4032   --fixed-size 64K
-part reserved2  --offset 4096   --fixed-size 4096K
-part loader2    --offset 8192   --fixed-size 4096K --source rawcopy 
--sourceparams="file=u-boot.${UBOOT_SUFFIX}"

-part atf    --offset 12288  --fixed-size 4096K
-part /boot  --offset 16384  --size   114688K --active --source 
bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"

-part / --source rootfs    --fstype=ext4 --label root --use-uuid
+part loader1   --offset 32 --fixed-size 4000K --source rawcopy 
--sourceparams="file=${SPL_BINARY}" --use-uuid

+part reserved1 --offset 4032 --fixed-size 64K --use-uuid
+part reserved2 --offset 4096 --fixed-size 4096K --use-uuid
+part loader2   --offset 8192 --fixed-size 4096K --source rawcopy 
--sourceparams="file=u-boot.${UBOOT_SUFFIX}" --use-uuid

+part atf   --offset 12288 --fixed-size 4096K --use-uuid
+part /boot --offset 16384 --size 114688K --active --source 
bootimg-partition --fstype=vfat --label boot 
--sourceparams="loader=u-boot" --use-uuid

+part / --source rootfs --fstype=ext4 --label root --use-uuid

-bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 
init=/sbin/init"



In addition i added an option that avoids editing fstab by wic at all 
since the image also boots without mounting /boot, but i guess this is 
just a matter of taste.


diff --git a/conf/machine/include/rockchip-wic.inc 
b/conf/machine/include/rockchip-wic.inc

index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
    SPL_BINARY \
    UBOOT_SUFFIX \
    "
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"


Am 18.09.21 um 00:01 schrieb Trevor Woerner:

Recent upstream kernel changes have made the mmc probing order unpredictable.
Therefore, boards with both an emmc and sdmmc interface aren't guaranteed to
boot with a hard-coded root device selected.

For example, on the rock64, with linux-yocto 5.10.y, using the uSD card (i.e.
the sdmmc interface) about 50% of the time the boot would succeed, and roughly
50% of the time it wouldn't:

...
[0.612233] Waiting for root device /dev/mmcblk1p7...
[0.634551] mmc_host mmc1: Bus speed (slot 0) = 30Hz (slot req 
30Hz, actual 30HZ div = 0)
[0.639064] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 
5000Hz, actual 5000HZ di)
[0.640007] mmc0: new high speed SDXC card at address 5048
[0.641176] mmcblk0: mmc0:5048 SD64G 58.0 GiB
[0.647610] random: fast init done
[0.648279] GPT:Primary header thinks Alt. header is not at the end 
of the disk.
[0.648941] GPT:376479 != 121634815
[0.649252] GPT:Alternate GPT header not at the end of the disk.
[0.649796] GPT:376479 != 121634815
[0.650106] GPT: Use GNU Parted to correct GPT errors.
[0.650598]  mmcblk0: p1 p2 p3 p4 p5 p6 p7

NOTE the discrepancy between the kernel waiting for device /dev/mmcblk1p7,
which comes from the hard-coded kernel cmdline, and the kernel probing putting
the sdmmc on mmcblk0.

With linux-yocto 5.13.y on the rock64 using the uSD card the board would never
boot, the sdmmc always appears on mmcblk0.

Instead of simply changing the hard-coded root device (i.e. from mmcblk0 to
mmcblk1) switch to using partition UUIDs instead. Hard-coding the boot device
would work with 5.13.y but would fail 50% of the time with 5.10.y; who knows
what other kernels will do?

In any case, switching to UUIDs works regardless of board, kernel, or
available mmc interfaces.

Boot tested on:
- rock64
- nanopi-m4-2gb
- tinker-board
- rock-pi-e
- rock-pi-4b

Signed-off-by: Trevor Woerner 
---
  conf/machine/include/nanopi-m4.inc|  2 --
  conf/machine/include/rock-pi-4.inc|  2 --
  conf/machine/include/rockchip-wic.inc |  4 
  conf/machine/rock64.conf  |  3 ---
  conf/machine/tinker-board-s.conf  |  2 --
  conf/machine/vyasa-rk3288.conf|  2 --
  wic/rockchip.wks  | 16 

Re: [yocto] editing Makefile after configure stage to disable -Werror

[Markus Volk]

you could try to add a line like this to your recipe:

CFLAGS:append = " -Wno-error=missing-attributes"


Am 31.08.21 um 08:41 schrieb Ivan Riabtsov:

Hello, I have the following error:

../../elfutils-0.166/libelf/libelfP.h:53:30: error: ‘__elf64_msize’
specifies less restrictive attribute than its target ‘elf64_fsize’:
‘const’ [-Werror=missing-attributes]

i try to solve this by patch:

diff -Naur elfutils-0.166_orig/libelf/libelfP.h elfutils-0.166/libelf/libelfP.h
--- elfutils-0.166_orig/libelf/libelfP.h 2016-01-12 15:49:19.0 +0300
+++ elfutils-0.166/libelf/libelfP.h 2021-08-30 19:38:44.866175082 +0300
@@ -48,6 +48,8 @@


  /* Helper Macros to write 32 bit and 64 bit functions.  */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmissing-attributes"
  #define __elfw2_(Bits, Name) __elf##Bits##_##Name
  #define elfw2_(Bits, Name) elf##Bits##_##Name
  #define ElfW2_(Bits, Name) Elf##Bits##_##Name
@@ -632,4 +634,5 @@
  #define INVALID_NDX(ndx, type, data) \
unlikely ((data)->d_size / sizeof (type) <= (unsigned int) (ndx))

+#pragma GCC diagnostic pop
  #endif  /* libelfP.h */


But the patch does  not work, error appears again.


i try to add --disable-werror to configure flags, but i have follows warning:

configure: WARNING: unrecognized options: --disable-werror.


The only solution to the problem I could think of is editing the
Makefile after configuration, please tell me how this can be done?




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

Re: [yocto] extrausers-bbclass: plaintext password (since shadow update to 4.9)

[Markus Volk]

I also have problems with setting passwords in current master branch. I 
only can provide a hacky workaround. I added the following lines to my 
image recipe to inject the passwords manually after rootfs creation:


RETRO_USER_PASSWORD ?= "retro"
ROOT_USER_PASSWORD ?= "root"
ROOTFS_POSTPROCESS_COMMAND += "set_root_passwd;"
ROOTFS_POSTPROCESS_COMMAND += "set_retro_passwd;"

set_root_passwd() {
   ROOTPW_ENCRYPTED="$(openssl passwd -6 -salt xyz ${ROOT_USER_PASSWORD})"
   sed -i "s%^root:[^:]*:%root:${ROOTPW_ENCRYPTED}:%" 
${IMAGE_ROOTFS}/etc/shadow

}

set_retro_passwd() {
   RETROPW_ENCRYPTED="$(openssl passwd -6 -salt xyz 
${RETRO_USER_PASSWORD})"
   sed -i "s%^retro:[^:]*:%retro:${RETROPW_ENCRYPTED}:%" 
${IMAGE_ROOTFS}/etc/shadow

}


Am 30.08.21 um 14:54 schrieb Matthias Klein:

Hello,

I am trying to find a working alternative for the old -P option.

Previous:
EXTRA_USERS_PARAMS = "usermod -P toor root;"

The suggestions from this thread don't seem to work: 
https://lists.openembedded.org/g/openembedded-core/topic/84548199

Current:
hash="$(python3 -c "import crypt; print(crypt.crypt('toor', 
crypt.METHOD_SHA512))")"
EXTRA_USERS_PARAMS = "usermod -p ${hash} root;"

The hashed password does not seem to be escaped properly in the 
extrausers-bbclass. The password in the shadow file is missing $ characters.

Is there a way (with the current master branch) to define a password?

Many greetings,
Matthias





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

Re: [yocto] [meta-rockchip] Question about OVERRIDES in meta-rockchip

[Markus Volk]

Learned something new today :)

It could be done in local.conf like this:

OVERRIDES .= "${@bb.utils.contains_any('SOC_FAMILY', 'rk3066 rk3188 rk3288 
rk3399', ':rockchip', '', d)}"
DISTRO_FEATURES_remove_rockchip =

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

[yocto] [meta-rockchip] Question about OVERRIDES in meta-rockchip

[Markus Volk]

I'm building an image for rock-pi-4c using meta-rockchip layer and need to 
remove a DISTRO_FEATURE in local.conf. That would be needed for all rockchip 
based boards, but i only found overrides based on soc_family. I ended up adding 
a line for every soc_family:

DISTRO_FEATURES_remove_rk3066 =
DISTRO_FEATURES_remove_rk3188 =
DISTRO_FEATURES_remove_rk3288 =
DISTRO_FEATURES_remove_rk3399 =

So my question is: Is there any better way to achieve this or would it be 
thinkable to add an override for the complete rockchip family (maybe in 
rockchip-defaults.inc) like this?

MACHINEOVERRIDES .= ":rockchip"

Kind regards,
Markus Volk

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

Re: [yocto] rebuild issues using sstate mirror

[Markus Volk]

I sent patches to openembedded-c...@lists.openembedded.org

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

[yocto] rebuild issues using sstate mirror

[Markus Volk]

Hi Folks,
i did some research on building a custom yocto image using gatesgarth branch. 
The testcase was building an image on one machine and rebuild it on another 
using sstate mirror.
I encountered two issues witch i was able to fix in a way that may also be 
interesting upstream.

The first error:
| 
/home/flk/yocto/build/poky-3.2/hd51/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/gobject-introspection/1.64.1-r0/recipe-sysroot-native/usr/bin/bison:
 error while loading shared libraries: libreadline.so.7: cannot open shared 
object file: No such file or directory

the solution for me was to add 'readline'  to DEPENDS in bison_3.7.2.bb .

configure log for bison-native changed from:
checking for readline... no
checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
checking readline/history.h usability... no
checking readline/history.h presence... no
checking for readline/history.h... no

to:
checking for readline... yes
checking how to link with libreadline... 
/home/flk/yocto/build/poky-3.2/hd51/tmp/work/x86_64-linux/bison-native/3.7.2-r0/recipe-sysroot-native/usr/lib/libreadline.so
 -Wl,-rpath 
-Wl,/home/flk/yocto/build/poky-3.2/hd51/tmp/work/x86_64-linux/bison-native/3.7.2-r0/recipe-sysroot-native/usr/lib
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes

and the error disappeared

The second error:

ERROR: neutrino-image-1.0-r0 do_rootfs: Unable to update the package index 
files. Command 
'/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg
 --volatile-cache -f 
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/opkg.conf
 -t 
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/temp/ipktemp/
 -o 
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs
  --force_postinstall --prefer-arch-to-version   update' returned 127:
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg:
 error while loading shared libraries: libcharset.so.1: cannot open shared 
object file: No such file or directory

after some research why libiconv libs are  being used (which i didn't have 
installed on the rebuild machine) i found this in libarchive:
configure.ac ( 
https://github.com/libarchive/libarchive/blob/858fa8eaa9435340d2bda988715e0d9023089bec/configure.ac#L380%20
 )

and was able to avoid the error by including 'gettext' to the inherit line in 
libarchive_3.4.3.bb

Kind regards

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

[yocto] build issues using sstate mirror

[Markus Volk]

Hi Folks,
i did some research on building a custom yocto image using gatesgarth branch. 
The testcase was building an image on one machine and rebuild it on another 
using sstate mirror.
I encountered two issues which i was able to fix in a way that may also be 
interesting upstream.

The first error:
| 
/home/flk/yocto/build/poky-3.2/hd51/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/gobject-introspection/1.64.1-r0/recipe-sysroot-native/usr/bin/bison:
 error while loading shared libraries: libreadline.so.7: cannot open shared 
object file: No such file or directory

the solution for me was to add 'readline'  to the inherit line in 
bison_3.7.2.bb .

configure log for bison-native changed from:
checking for readline... no
checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
checking readline/history.h usability... no
checking readline/history.h presence... no
checking for readline/history.h... no

to:
checking for readline... yes
checking how to link with libreadline... 
/home/flk/yocto/build/poky-3.2/hd51/tmp/work/x86_64-linux/bison-native/3.7.2-r0/recipe-sysroot-native/usr/lib/libreadline.so
 -Wl,-rpath 
-Wl,/home/flk/yocto/build/poky-3.2/hd51/tmp/work/x86_64-linux/bison-native/3.7.2-r0/recipe-sysroot-native/usr/lib
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes

and the error disappeared

Second error:
ERROR: neutrino-image-1.0-r0 do_rootfs: Unable to update the package index 
files. Command 
'/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg
 --volatile-cache -f 
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/opkg.conf
 -t 
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/temp/ipktemp/
 -o 
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs
  --force_postinstall --prefer-arch-to-version   update' returned 127:
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg:
 error while loading shared libraries: libcharset.so.1: cannot open shared 
object file: No such file or directory

after some research why libiconv libs are  being used (which i didn't have 
installed on the rebuild machine) i found this in libarchive:
https://github.com/libarchive/libarchive/blob/858fa8eaa9435340d2bda988715e0d9023089bec/configure.ac#L380

and was able to avoid the error by including 'gettext' to the inherit line in 
libarchive_3.4.3.bb

Kind regards

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