Date   

[meta-zephyr][PATCH] zephyr-kernel-test: disable broken tests

Jon Mason
 

Add tests that don't currently compile successfully to the remove
list for each specific machine.

Signed-off-by: Jon Mason <jon.mason@arm.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index f970225c884d..c7ccf9e05742 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -5,6 +5,14 @@ ZEPHYRTESTS:remove = "fifo fpu_sharing lifo mbox mem_heap mem_pool \
# Exclude tests which does not build for various reasons
ZEPHYRTESTS:remove = "gen_isr_table spinlock smp mp"

+# Exclude tests that are not currently compiling
+ZEPHYRTESTS:remove:96b-avenger96 = "common device poll queue sleep"
+ZEPHYRTESTS:remove:96b-nitrogen = "common device poll queue sleep"
+ZEPHYRTESTS:remove:arduino-nano-33-ble = "common device poll queue sleep"
+ZEPHYRTESTS:remove:nrf52840dk-nrf52840 = "common device poll queue sleep"
+ZEPHYRTESTS:remove:qemu-x86 = "common device interrupt poll queue sleep"
+ZEPHYRTESTS:remove:stm32mp157c-dk2 = "common device poll queue sleep"
+
# test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register
#ZEPHYRTESTS:remove:arm += ""

--
2.20.1


#bitbake TOPDIR not evaluating on custom distro #bitbake

jussi.vanska@...
 

I have a curious problem with TOPDIR environment variable.

Running standard Poky build with 25.0.3 works as expected but when using a custom distro layer the build fails as the host tools are not visible in path. Environment is identical, not counting the different path names, after sourcing the environment and before running bitbake but when running using a custom setup the PATH contains only relative references:

/home/jive/stage/yocto-25.0.3/bitbake/bin:tmp-glibc/hosttools"; export HOME="/home/jive"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P ../localmirror 'http://sources.openembedded.org/quilt-0.66.tar.gz' --progress=dot -v failed with exit code 127, output:
/usr/bin/env: ‘wget’: No such file or directory

whereas the Poky standard seems to expand the TOPDIR and TMPDIR ok

/home/jive/stage/yocto-25.0.3/bitbake/bin:/home/jive/stage/build/tmp/hosttools"; export HOME="/home/jive"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/jive/stage/build/downloads 'https://download.savannah.gnu.org/releases/quilt/quilt-0.66.tar.gz' --progress=dot -v

I can not find a place where the TOPDIR is set in configuration or what recipe/class overrides it. I'm aware the build directory should be under the OEROOT not beside it but this used to work with 18.x versions of YPCore.

cache.py@303 sets the variable and it looks very dangerous as it is relative to recipe currently parsing. Is this really how it should work? Another thing which is confusing is copy_buildsystem.py@46 still uses COREBASE even though the release documentation says the environment variable is deprecated and should not be used anymore. What makes this curious is that the OEROOT related paths work ok so I guess problem is somehow related to OEROOT vs. COREBASE handling.

There is another problem related to this as the inline python in my custom distro configuration distro/layer.conf
COREBASE = '${@os.path.normpath("${OEROOT}")}' does not work but complains

File "/home/jive/stage/yocto-25.0.3/meta/classes/metadata_scm.bbclass", line 27, in base_get_metadata_git_branch(path='${@os.path.normpath("${OEROOT}")}/meta', d=<bb.data_smart.DataSmart object at 0x7fc9ba2e6390>):

Any advice would be welcome before digging deeper into the internals of bitbake.


Re: virtual/egl on Raspberry Pi 4

Joel Winarske
 

Hi Greg,

Do you have this in your local.conf?

DISTRO_FEATURES_append = " opengl"

On Tue, Oct 5, 2021, 11:22 AM Greg Wilson-Lindberg <gwilson@...> wrote:

Hi Khem,

I added the VC4GRAPHICS line and here is the complete error that I get:


ERROR: Nothing PROVIDES 'virtual/egl' (but /home/gwilson/Qt-5.15.6/Yocto-build-RPi4/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb DEPENDS on or otherwise requires it)
vc-graphics PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics
opengldummy PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not opengldummy
vc-graphics-hardfp PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
qtglesstream-dummy-client PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not qtglesstream-dummy-client
NOTE: Runtime target 'zint' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['zint', 'qtbase', 'virtual/egl']

Regards,

Greg


From: Khem Raj <raj.khem@...>
Sent: Tuesday, October 5, 2021 9:31:49 AM
To: Greg Wilson-Lindberg
Cc: yocto@...
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
 
that should have worked well for userland recipe to provide it. Maybe
you need to set

VC4GRAPHICS = ""

in local.conf

On Tue, Oct 5, 2021 at 8:53 AM Greg Wilson-Lindberg
<GWilson@...> wrote:
>
> I am compiling in 32 bit mode.
>
>
>
> From: Khem Raj <raj.khem@...>
> Sent: Monday, October 4, 2021 5:15 PM
> To: Greg Wilson-Lindberg <GWilson@...>
> Cc: yocto@...
> Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
>
>
>
> It should have automatically found user land package as one of providers but if it is not doing so that means it’s being ignored because it’s not compatible arch or something
>
> Are you compiling 32bit mode ?
>
>
>
>
>
> On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg <GWilson@...> wrote:
>
> Hi Khem,
> Yes, the Raspberry Pi boards do use closed source drivers. What I need is how do I include the proper package that will bring in the necessary virtual/egl for the Raspberry Pi 4.
>
> Greg
> > -----Original Message-----
> > From: Khem Raj <raj.khem@...>
> > Sent: Monday, October 4, 2021 14:17
> > To: Greg Wilson-Lindberg <GWilson@...>;
> > yocto@...
> > Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
> >
> >
> >
> > On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
> > > Hello list,
> > >
> > > I'm working on a Qt supplied boot2qt Yocto build currently based on
> > > Zeus that is running on a Raspberry Pi 4. I recently updated the qt
> > > version to 5.15.6 and Qt changed something in the Yocto configuration
> > > that they are using and now one of the recipes that we use is failing
> > > saying that in needs 'virtual/egl' but that it is not provided by any recipe.
> > >
> > > In the searching that I have done I have found that the raspberry pi 4
> > > is particular on which package supplies the virtual/egl but I haven't
> > > seen anything that indicates what I should do to re-enable it.
> > >
> > > Can anyone tell me what I need to do to enable the correct driver to
> > > get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
> > > how I could search through the packages that are enabled on the old
> > > and new Yocto trees so that I can figure out what changed between the
> > > releases and re-enable the virtual/egl.
> > >
> >
> > it should be provided by userland package if you are using closed source
> > graphics driver.
> >
> > > Best Regards,
> > >
> > > Greg Wilson-Lindberg
> > >
> > >
> > >
> > >
> > >




Re: #dunfell Path to sources in debugfs #dunfell

bohdan.shubenok@...
 

Hi,

I`m trying to debug without connection to target at all. This are the examples of what I`m running:

# gdb-multiarch b2010_rootfs/usr/bin/noah-heatsystem var/volatile/crash/core.noah.565
(gdb) set sysroot b2010_rootfs/
(gdb) set substitute-path /usr/src/debug b2010/usr/src/debug
.... things are getting loaded .....

(gdb) bt
#0  0xb4a6a144 in saveCursorsOnList (p=0xccf34862, iRoot=3, pExcept=0xb540b350) at ../sqlite-autoconf-3310100/sqlite3.c:64883
.... more frames here .....

And this how it looks like when out of tree build disabled:

# gdb-multiarch b2010_rootfs/usr/bin/noah-heatsystem var/volatile/crash/core.noah.565
(gdb) set sysroot src_add_rootfs/
(gdb) set substitute-path /usr/src/debug src_add_rootfs/usr/src/debug
.... things are getting loaded .....

(gdb) bt
#0  0xb4a6a144 in saveCursorsOnList (p=0xccf34862, iRoot=3, pExcept=0xb540b350) at sqlite3.c:64883
.... more frames here .....


In a  first case `layout next` command shows that no source code can be found and in a second case source code is shown.

Best regards,

Bohdan.


Re: #dunfell Path to sources in debugfs #dunfell

bohdan.shubenok@...
 

Hi,

I can see this on Qt builds as well. I doubt Qt can have such strange behavior left unnoticed for a long time. The part is missing is "include/QtCore"


Re: Getting absolute paths in yocto generated native binary #toolchain #sdk #bitbake #native

Chuck Wolber
 

Native recipes are meant for the build machine itself to aid your build. If you are packaging something to run on a destination machine, you should be producing non-native recipe images.

..Ch:W..


On Tue, Oct 5, 2021 at 1:59 PM Jean-Pierre Doyon <jpdoyon@...> wrote:

I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the production machine to program the empty boards right after being assembled.

While I had plenty of hurdles figuring out how to do this (I'm still pretty newbie with Yocyo), I managed to get everything just the way I wanted it. But when I get the tarball to the production machine, which runs the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The reason being that it's missing some library. Running LDD on the executable turns up this:

└─$> ldd usr/bin/imx_usb
    linux-vdso.so.1 =>  (0x00007ffd7031d000)
    libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f986a47e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f986a0b4000)
    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f986a86c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9869e97000)
    /home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f986a696000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9869c8f000)

Why is the ld-linux-x86-64.so.2 using an absolute path while all the other libraries aren't?

If I install the library in the location above, then the executable starts working... So how do I make sure Yocto doesn't do this?






--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: Google GN support

Joel Winarske
 


> look at meta-browser/meta-chromium as well.

The download archive (tar.xz) approach may be the easiest solution.  Then one would just need to make a versioned recipe for each LTS.

Thanks Khem!


Re: Getting absolute paths in yocto generated native binary #toolchain #sdk #bitbake #native

Khem Raj
 

On Tue, Oct 5, 2021 at 1:59 PM Jean-Pierre Doyon <jpdoyon@newtrax.com> wrote:

I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the production machine to program the empty boards right after being assembled.

While I had plenty of hurdles figuring out how to do this (I'm still pretty newbie with Yocyo), I managed to get everything just the way I wanted it. But when I get the tarball to the production machine, which runs the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The reason being that it's missing some library. Running LDD on the executable turns up this:

└─$> ldd usr/bin/imx_usb
linux-vdso.so.1 => (0x00007ffd7031d000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f986a47e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f986a0b4000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f986a86c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9869e97000)
/home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f986a696000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9869c8f000)

Why is the ld-linux-x86-64.so.2 using an absolute path while all the other libraries aren't?

If I install the library in the location above, then the executable starts working... So how do I make sure Yocto doesn't do this?
yocto provides a layer to abstract native binaries on top of build
host and thats what you are seeing. Its as designed.




Re: Google GN support

Khem Raj
 

On Tue, Oct 5, 2021 at 2:34 PM Joel Winarske <joel.winarske@gmail.com> wrote:

I'm looking into best practice LTS support for Google GN based projects. This includes Chromium, Flutter, SKIA, etc.

The weakness I see today for GN projects is that it's a build system within a build system, and doesn't support idiomatic download caching, download vs patching isn't clear as it should be, etc.

Two approaches to resolve this come to mind:
1. Do something similar to how meta-rust does it. Pre-process GN build files and generate Yocto recipes using a hostside tool (similar to cargo-bitbake for meta-rust). This would skip usage of gclient entirely, and the tradeoff is to incur download performance penalty.

2. Implement build parsing in a gclient/gn fetcher class.

I feel the first approach would be easier to maintain and provide better flexibility. It would incur a new host dependency, and require an additional step to generate an updated recipe.

I suspect the second approach would be an OE maintenance headache, as complexities would be directly exposed in OE. Is this why gclient fetcher support came and went?

I'm figuring/hoping there are a few opinions floating around on this subject.

Is there a better approach?
look at meta-browser/meta-chromium as well.


Thanks,
Joel



Google GN support

Joel Winarske
 

I'm looking into best practice LTS support for Google GN based projects.  This includes Chromium, Flutter, SKIA, etc.

The weakness I see today for GN projects is that it's a build system within a build system, and doesn't  support idiomatic download caching, download vs patching isn't clear as it should be, etc.

Two approaches to resolve this come to mind:
1. Do something similar to how meta-rust does it.  Pre-process GN build files and generate Yocto recipes using a hostside tool (similar to cargo-bitbake for meta-rust).  This would skip usage of gclient entirely, and the tradeoff is to incur download performance penalty.

2. Implement build parsing in a gclient/gn fetcher class.

I feel the first approach would be easier to maintain and provide better flexibility.  It would incur a new host dependency, and require an additional step to generate an updated recipe.

I suspect the second approach would be an OE maintenance headache, as complexities would be directly exposed in OE.  Is this why gclient fetcher support came and went?

I'm figuring/hoping there are a few opinions floating around on this subject.

Is there a better approach?

Thanks,
Joel


Getting absolute paths in yocto generated native binary #toolchain #sdk #bitbake #native

Jean-Pierre Doyon <jpdoyon@...>
 

I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the production machine to program the empty boards right after being assembled.

While I had plenty of hurdles figuring out how to do this (I'm still pretty newbie with Yocyo), I managed to get everything just the way I wanted it. But when I get the tarball to the production machine, which runs the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The reason being that it's missing some library. Running LDD on the executable turns up this:

└─$> ldd usr/bin/imx_usb
    linux-vdso.so.1 =>  (0x00007ffd7031d000)
    libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f986a47e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f986a0b4000)
    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f986a86c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9869e97000)
    /home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f986a696000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9869c8f000)

Why is the ld-linux-x86-64.so.2 using an absolute path while all the other libraries aren't?

If I install the library in the location above, then the executable starts working... So how do I make sure Yocto doesn't do this?


Re: #dunfell Path to sources in debugfs #dunfell

Robert Berger
 

Hi,

My comments are inline.

On 05/10/2021 17:04, bohdan.shubenok@sigma.software wrote:
Hi all,
I`m trying to debug coredump generated on embedded system running dunfel.
Just to clarify your user space applications crashes and you try to see why? In other words you would like to load the application and the core file into your debugger and inspect it?

The issue I`m facing is with the source files path in "-dbg.rootfs" archive and within dedug portion of a package.
When loaded in QtCreator some sources can`t be found :
The part is missing is "*build/..*". Such notation is obviosly cancels itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found in build path for sqlite:
   build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
   build/Makefile:313:abs_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:315:abs_top_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:358:srcdir = ../sqlite-autoconf-3310100
So I tried to disable out-of-tree build for sqlite by replacing *'inherit autotools*' with '*inherit autotools-brokensep*'. After building and loading new debugfs QtCreator was able to found required sources:
Is this a known issue or me doing something wrong with build setup?
This is very strange, but also I am not quite sure how exactly you debug.
I assume you run gdbserver on the target and connect from some cross-gdb on your host to it.

You could try to install gdb onto your target plus debug info and sources to exclude the cross-gdb configuration problem as I describe below.

If you use gdbserver/cross-gdb I assume directories on your target rootfs and host roots are different. So you need to tell your cross-gdb on the host where to find the debug info and the sources.

Can you please try something like this?

http://docs.yoctoproject.org/singleindex.html#using-the-gdbserver-method

What I would inspect carefully is something like that:

$ cd directory-holding-the-debugfs-directory
$ arch-gdb
(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) target remote IP-of-target:1234

At least in the latest and greatest version this works. I remember a bug a long time ago with some ancient yocto release with cross-debugging, but this was resolved with some upgrade and was certainly older than dunfell.

Regards,

Robert


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

Trevor Woerner
 

On Fri 2021-10-01 @ 03:20:35 PM, Markus Volk wrote:
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 <f_l_k@t-online.de>
---
wic/rockchip.wks | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I tweaked the patch so that the fields lined up vertically, but otherwise…
Applied to meta-rockchip, master.
Thanks!


Re: [meta-rockchip][PATCH 3/3] nanopi-m4: add common override

Trevor Woerner
 

On Wed 2021-09-29 @ 01:29:38 AM, Trevor Woerner wrote:
Add a common override for both nanopi-m4 MACHINEs.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/include/nanopi-m4.inc | 3 +++
1 file changed, 3 insertions(+)
Applied to meta-rockchip, master.


Re: [meta-rockchip][PATCH 2/3] include/nanopi-m4: remove KMACHINE

Trevor Woerner
 

On Wed 2021-09-29 @ 01:29:37 AM, Trevor Woerner wrote:
There is no "nanopi-m4" defined in any yocto kernel metadata (yet?), therefore
remove this superfluous line.

Build (core-image-base) and run tested (both systemd and sysvinit) on:
- nanopi-m4

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/include/nanopi-m4.inc | 1 -
1 file changed, 1 deletion(-)
Applied to meta-rockchip, master.


Re: [meta-rockchip][PATCH 1/3] linux-yocto: remove mmc aliases

Trevor Woerner
 

On Wed 2021-09-29 @ 01:29:36 AM, Trevor Woerner wrote:
Now that we're booting via UUID, we no longer need these aliases in the DT.
Personally I wasn't able to prove to myself that they actually worked (at
least not with 5.13.y) and fiddling with these aliases didn't seem to affect
the mmc probe order on boot. Additionally it looks like some of these aliases
will be landing upstream shortly.

Build (core-image-base) and run tested (both systemd and sysvinit) on:
- rock64
- rock-pi-e

(i.e. the two rk3328 MACHINEs)

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 -------------------
recipes-kernel/linux/linux-yocto%.bbappend | 3 ---
2 files changed, 30 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
Applied to meta-rockchip, master.


Re: #dunfell Path to sources in debugfs #dunfell

Khem Raj
 

On 10/5/21 7:04 AM, bohdan.shubenok@sigma.software wrote:
Hi all,
I`m trying to debug coredump generated on embedded system running dunfel. The issue I`m facing is with the source files path in "-dbg.rootfs" archive and within dedug portion of a package.
When loaded in QtCreator some sources can`t be found :
The part is missing is "*build/..*". Such notation is obviosly cancels itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found in build path for sqlite:
   build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
   build/Makefile:313:abs_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:315:abs_top_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:358:srcdir = ../sqlite-autoconf-3310100
So I tried to disable out-of-tree build for sqlite by replacing *'inherit autotools*' with '*inherit autotools-brokensep*'. After building and loading new debugfs QtCreator was able to found required sources:
Is this a known issue or me doing something wrong with build setup?
I think its not a general problem with autotool based projects doing out of tree builds but just with sqlite3 package. Perhaps you might want to look at compiler commandline options being passed to sqlite3 build and see if paths can be adjusted during build to account for out of tree build.


Re: virtual/egl on Raspberry Pi 4

Greg Wilson-Lindberg
 

Hi Khem,

I added the VC4GRAPHICS line and here is the complete error that I get:


ERROR: Nothing PROVIDES 'virtual/egl' (but /home/gwilson/Qt-5.15.6/Yocto-build-RPi4/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb DEPENDS on or otherwise requires it)
vc-graphics PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics
opengldummy PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not opengldummy
vc-graphics-hardfp PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
qtglesstream-dummy-client PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not qtglesstream-dummy-client
NOTE: Runtime target 'zint' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['zint', 'qtbase', 'virtual/egl']

Regards,

Greg


From: Khem Raj <raj.khem@...>
Sent: Tuesday, October 5, 2021 9:31:49 AM
To: Greg Wilson-Lindberg
Cc: yocto@...
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
 
that should have worked well for userland recipe to provide it. Maybe
you need to set

VC4GRAPHICS = ""

in local.conf

On Tue, Oct 5, 2021 at 8:53 AM Greg Wilson-Lindberg
<GWilson@...> wrote:
>
> I am compiling in 32 bit mode.
>
>
>
> From: Khem Raj <raj.khem@...>
> Sent: Monday, October 4, 2021 5:15 PM
> To: Greg Wilson-Lindberg <GWilson@...>
> Cc: yocto@...
> Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
>
>
>
> It should have automatically found user land package as one of providers but if it is not doing so that means it’s being ignored because it’s not compatible arch or something
>
> Are you compiling 32bit mode ?
>
>
>
>
>
> On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg <GWilson@...> wrote:
>
> Hi Khem,
> Yes, the Raspberry Pi boards do use closed source drivers. What I need is how do I include the proper package that will bring in the necessary virtual/egl for the Raspberry Pi 4.
>
> Greg
> > -----Original Message-----
> > From: Khem Raj <raj.khem@...>
> > Sent: Monday, October 4, 2021 14:17
> > To: Greg Wilson-Lindberg <GWilson@...>;
> > yocto@...
> > Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
> >
> >
> >
> > On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
> > > Hello list,
> > >
> > > I'm working on a Qt supplied boot2qt Yocto build currently based on
> > > Zeus that is running on a Raspberry Pi 4. I recently updated the qt
> > > version to 5.15.6 and Qt changed something in the Yocto configuration
> > > that they are using and now one of the recipes that we use is failing
> > > saying that in needs 'virtual/egl' but that it is not provided by any recipe.
> > >
> > > In the searching that I have done I have found that the raspberry pi 4
> > > is particular on which package supplies the virtual/egl but I haven't
> > > seen anything that indicates what I should do to re-enable it.
> > >
> > > Can anyone tell me what I need to do to enable the correct driver to
> > > get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
> > > how I could search through the packages that are enabled on the old
> > > and new Yocto trees so that I can figure out what changed between the
> > > releases and re-enable the virtual/egl.
> > >
> >
> > it should be provided by userland package if you are using closed source
> > graphics driver.
> >
> > > Best Regards,
> > >
> > > Greg Wilson-Lindberg
> > >
> > >
> > >
> > >
> > >


Re: file package dependency

Khem Raj
 

On 10/5/21 5:10 AM, Timur wrote:
Hi, I'm building a yocto release from the thud branch. The size of the OS image is very critical, so I need to remove as much as I can. Looking at the dependency information, I can see that the "file" package is not required by any other package, but yet it is installed. I really have to remove this package because it is quite large with its magic database, but I can't find who is installing it and why.
I think looking into buildhistory metadata might give some hints, it stores the information about image to package dependencies in a dotty file which you can either open in a viewer or text editor and see who might be pulling the package which provides file utility. So firstly you have to find which package provides file utility which could be done via oe-pkg-utils tool


Re: virtual/egl on Raspberry Pi 4

Khem Raj
 

that should have worked well for userland recipe to provide it. Maybe
you need to set

VC4GRAPHICS = ""

in local.conf

On Tue, Oct 5, 2021 at 8:53 AM Greg Wilson-Lindberg
<GWilson@sakuraus.com> wrote:

I am compiling in 32 bit mode.



From: Khem Raj <raj.khem@gmail.com>
Sent: Monday, October 4, 2021 5:15 PM
To: Greg Wilson-Lindberg <GWilson@sakuraus.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4



It should have automatically found user land package as one of providers but if it is not doing so that means it’s being ignored because it’s not compatible arch or something

Are you compiling 32bit mode ?





On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg <GWilson@sakuraus.com> wrote:

Hi Khem,
Yes, the Raspberry Pi boards do use closed source drivers. What I need is how do I include the proper package that will bring in the necessary virtual/egl for the Raspberry Pi 4.

Greg
-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Monday, October 4, 2021 14:17
To: Greg Wilson-Lindberg <GWilson@sakuraus.com>;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4



On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
Hello list,

I'm working on a Qt supplied boot2qt Yocto build currently based on
Zeus that is running on a Raspberry Pi 4. I recently updated the qt
version to 5.15.6 and Qt changed something in the Yocto configuration
that they are using and now one of the recipes that we use is failing
saying that in needs 'virtual/egl' but that it is not provided by any recipe.

In the searching that I have done I have found that the raspberry pi 4
is particular on which package supplies the virtual/egl but I haven't
seen anything that indicates what I should do to re-enable it.

Can anyone tell me what I need to do to enable the correct driver to
get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
how I could search through the packages that are enabled on the old
and new Yocto trees so that I can figure out what changed between the
releases and re-enable the virtual/egl.
it should be provided by userland package if you are using closed source
graphics driver.

Best Regards,

Greg Wilson-Lindberg




1001 - 1020 of 55944