Date   

Re: Build issue - newbie

Morne
 

ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)

The above error happens when I run bitbake obmc-phosphor-image in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
The above command succeeds when I use Ubuntu native installation.
What YP version are you using ?

Can you verify that you are using the same YP version in both cases ?

- Morné


Re: Build issue - newbie

Khem Raj
 

On 12/11/19 9:59 PM, Sujoy Ray wrote:
Hello,
I am trying to build yocto project and having following error:
==========================
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/sujoy/OpenBMC/openbmc/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 2104 at 2019-12-11 19:23:03.474760 ---
ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)
=============================================
The above error happens when I run /bitbake obmc-phosphor-image/ in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
The above command succeeds when I use Ubuntu native installation.
Could anybody please help?
it seems your project has mixed releases of different layers. So please describe how you setup your project. Usually you should be using same release/branch for all layers, unless a layer states otherwise

Thanks,
Sujoy.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47646): https://lists.yoctoproject.org/g/yocto/message/47646
Mute This Topic: https://lists.yoctoproject.org/mt/68263780/1997914
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [raj.khem@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [meta-rockchip][PATCH] rk3288: Convert to using wic

Trevor Woerner
 

Super awesome! Applied, thanks :-)


Build issue - newbie

Sujoy Ray
 

Hello,
I am trying to build yocto project and having following error:
==========================
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/sujoy/OpenBMC/openbmc/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 2104 at 2019-12-11 19:23:03.474760 ---
ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)
=============================================
 
The above error happens when I run bitbake obmc-phosphor-image in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
 
The above command succeeds when I use Ubuntu native installation. 

Could anybody please help?
Thanks,
Sujoy.


[meta-rockchip][PATCH] rk3288: Convert to using wic

Joshua Watt
 

Coverts the firefly-rk3288, tinker-rk3288, and vyasa-rk3288 machines to
use wic instead of the rockchip-gpt-img class. The rock2-squared machine
has to keep the older image class because u-boot doesn't provided a
combined idbloader for it.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/firefly-rk3288.conf | 15 ++++++++++++++-
conf/machine/include/rk3288.inc | 2 --
conf/machine/rock2-square.conf | 6 ++++++
conf/machine/tinker-rk3288.conf | 15 ++++++++++++++-
conf/machine/vyasa-rk3288.conf | 14 ++++++++++++++
wic/firefly-rk3288.wks | 26 ++++++++++++++++++++++++++
wic/tinker-rk3288.wks | 26 ++++++++++++++++++++++++++
wic/vyasa-rk3288.wks | 27 +++++++++++++++++++++++++++
8 files changed, 127 insertions(+), 4 deletions(-)
create mode 100644 wic/firefly-rk3288.wks
create mode 100644 wic/tinker-rk3288.wks
create mode 100644 wic/vyasa-rk3288.wks

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 0900440..71e0bc3 100644
--- a/conf/machine/firefly-rk3288.conf
+++ b/conf/machine/firefly-rk3288.conf
@@ -10,4 +10,17 @@ require conf/machine/include/rk3288.inc

KERNEL_DEVICETREE = "rk3288-firefly.dtb"
UBOOT_MACHINE = "firefly-rk3288_defconfig"
-GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
+
+WKS_FILE = "firefly-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index 6e9a09a..b261692 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -12,5 +12,3 @@ SERIAL_CONSOLES = "115200;ttyS2"
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
SPL_BINARY ?= "idbloader.img"

-IMAGE_FSTYPES += "rockchip-gpt-img"
-IMAGE_CLASSES += "rockchip-gpt-img"
diff --git a/conf/machine/rock2-square.conf b/conf/machine/rock2-square.conf
index 737d3ae..46064ee 100644
--- a/conf/machine/rock2-square.conf
+++ b/conf/machine/rock2-square.conf
@@ -11,3 +11,9 @@ require conf/machine/include/rk3288.inc
SPL_BINARY = "u-boot-spl-dtb.bin"
KERNEL_DEVICETREE = "rk3288-rock2-square.dtb"
UBOOT_MACHINE = "rock2_defconfig"
+
+# This board doesn't support the combined idbloader, so resort to the older
+# image class
+IMAGE_FSTYPES += "rockchip-gpt-img"
+IMAGE_CLASSES += "rockchip-gpt-img"
+
diff --git a/conf/machine/tinker-rk3288.conf b/conf/machine/tinker-rk3288.conf
index 9e23f8d..e460d43 100644
--- a/conf/machine/tinker-rk3288.conf
+++ b/conf/machine/tinker-rk3288.conf
@@ -9,4 +9,17 @@ require conf/machine/include/rk3288.inc

KERNEL_DEVICETREE = "rk3288-tinker.dtb"
UBOOT_MACHINE = "tinker-rk3288_defconfig"
-GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
+
+WKS_FILE = "tinker-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
index bfbd09b..03a436a 100644
--- a/conf/machine/vyasa-rk3288.conf
+++ b/conf/machine/vyasa-rk3288.conf
@@ -12,3 +12,17 @@ KERNEL_DEVICETREE = "rk3288-vyasa.dtb"
KERNEL_EXTRA_ARGS += "LOADADDR=0x02000000"

UBOOT_MACHINE = "vyasa-rk3288_defconfig"
+
+WKS_FILE = "vyasa-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/wic/firefly-rk3288.wks b/wic/firefly-rk3288.wks
new file mode 100644
index 0000000..5013aea
--- /dev/null
+++ b/wic/firefly-rk3288.wks
@@ -0,0 +1,26 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk0 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk0 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk0 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk0 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk0 --align 12288 --size 4096K
+part /boot --ondisk mmcblk0 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk0 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/tinker-rk3288.wks b/wic/tinker-rk3288.wks
new file mode 100644
index 0000000..5013aea
--- /dev/null
+++ b/wic/tinker-rk3288.wks
@@ -0,0 +1,26 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk0 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk0 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk0 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk0 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk0 --align 12288 --size 4096K
+part /boot --ondisk mmcblk0 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk0 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/vyasa-rk3288.wks b/wic/vyasa-rk3288.wks
new file mode 100644
index 0000000..3fc9a5b
--- /dev/null
+++ b/wic/vyasa-rk3288.wks
@@ -0,0 +1,27 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk2 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk2 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk2 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk2 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk2 --align 12288 --size 4096K
+part /boot --ondisk mmcblk2 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk2 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7 rootfstype=ext4 init=/sbin/init"
+
--
2.23.0


Re: variable and task/function timing

Nicolas Dechesne
 

On Wed, Dec 11, 2019 at 5:41 PM Trevor Woerner <twoerner@...> wrote:

On Wed 2019-12-11 @ 04:49:27 PM, Nicolas Dechesne wrote:
right.. I was confused, I missed a few things in your email (well, it
was really long ;).
lol
Apparently writing long emails is therapeutic for me.

I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"
I did propose a 3rd way (in the original email) which does work which is very
similar to what you're suggesting:

# set the build type to either 'release' or 'debug'
# the upstream mesa sources actually build a debug release by default
# but here we assume the user will want a release build by default
MESA_BUILD_TYPE ?= "release"
def check_buildtype(d):
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
#bb.plain("setting meson build type to debugoptimized")
return 'debugoptimized'
return 'plain'
MESON_BUILDTYPE = "${@check_buildtype(d)}"

The user experience is rather different though. Let's say the user sets the
following in conf/local.conf:

MESA_BUILD_TYPE = "hello"

Using the "addtask" method (which doesn't work) produces a very nice error
message:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
Parsing of 1528 .bb files complete (1524 cached, 4 parsed). 2259 targets, 103 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "opensuseleap-15.1"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "tinker-rk3288"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-rockchip = "master:e8fd1f92ed59e0e71a7418779b912c5da342495c"
meta-tweaks = "master:b9184893949356a2da43bb2b5ec88dd573a5db0d"
meta = "master:093a1971f2ae12e1f514598da984f268607e550b"
meta-oe = "master:851321744e17e51aeb822a8d88c3532dffdf1cef"

Initialising tasks: 100% |####################################################################################################################| Time: 0:00:00
Sstate summary: Wanted 0 Found 0 Missed 0 Current 77 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: mesa-2_19.2.4-r0 do_check_build_type: unknown build type (hello), please set to either 'release' or 'debug'
ERROR: Logfile of failure stored in: /z/build-master/tinker-rk3288/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/mesa/2_19.2.4-r0/temp/log.do_check_build_type.12869
ERROR: Task (/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb:do_check_build_type) failed with exit code '1'
NOTE: Tasks Summary: Attempted 606 tasks of which 603 didn't need to be rerun and 1 failed.

Using the method proposed above produces:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug' ETA: --:--:--
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug'
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb
ERROR: ExpansionError during parsing /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
Traceback (most recent call last):
File "Var <MESON_BUILDTYPE>", line 1, in <module>
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa.inc", line 56, in check_buildtype(d=<bb.data_smart.DataSmart object at 0x7ffac8d0f4a8>):
if _buildtype not in ['release', 'debug']:
> bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/bitbake/lib/bb/__init__.py", line 108, in fatal:
mainlogger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()

bb.data_smart.ExpansionError: Failure expanding variable MESON_BUILDTYPE, expression was ${@check_buildtype(d)} which triggered exception BBHandledException:


Summary: There were 4 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
then you could use an anonymous python function instead.

python () {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
}

or something along these lines. that would be done during parsing, so
the variable should be set for all tasks.


Re: [yocto-docs][PATCH] ref-manual: mention PREPROCESS_RELOCATE_DIRS variable

Martin Jansa
 

ping again


On Fri, Sep 6, 2019 at 1:32 PM Martin Jansa <martin.jansa@...> wrote:
On Mon, Aug 12, 2019 at 07:51:40PM +0000, Martin Jansa wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@...>

ping

> ---
>  documentation/ref-manual/ref-classes.xml   |  5 ++++-
>  documentation/ref-manual/ref-variables.xml | 21 +++++++++++++++++++++
>  2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
> index ece47e757..159efb3b1 100644
> --- a/documentation/ref-manual/ref-classes.xml
> +++ b/documentation/ref-manual/ref-classes.xml
> @@ -413,7 +413,10 @@
>          <filename>cross</filename>, and
>          <filename>cross-canadian</filename> recipes to change
>          <filename>RPATH</filename> records within binaries in order to make
> -        them relocatable.
> +        them relocatable. To extend the list of directories where it searches
> +        for binaries to relocate, you can set
> +        <link linkend='var-PREPROCESS_RELOCATE_DIRS'><filename>PREPROCESS_RELOCATE_DIRS</filename></link>
> +        variable in your recipe.
>      </para>
>  </section>

> diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
> index 9470a780a..5ac766658 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -11424,6 +11424,27 @@
>              </glossdef>
>          </glossentry>

> +        <glossentry id='var-PREPROCESS_RELOCATE_DIRS'><glossterm>PREPROCESS_RELOCATE_DIRS</glossterm>
> +            <info>
> +                PREPROCESS_RELOCATE_DIRS[doc] = "List of extra directories where to search for binaries which should be relocatable."
> +            </info>
> +            <glossdef>
> +                <para role="glossdeffirst">
> +<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
> +                    List of extra directories with binaries.
> +                </para>
> +
> +                <para>
> +                    <filename>PREPROCESS_RELOCATE_DIRS</filename> is used by
> +                    chrpath.bbclass to allow extending the list where it searches
> +                    for binaries. By default it searches in:
> +                    ${bindir} ${sbindir} ${base_sbindir} ${base_bindir} ${libdir} ${base_libdir} ${libexecdir}
> +                    Thus, <filename>PREPROCESS_RELOCATE_DIRS</filename> usually doesn't
> +                    need to be set withing recipes.
> +                </para>
> +            </glossdef>
> +        </glossentry>
> +
>          <glossentry id='var-PRIORITY'><glossterm>PRIORITY</glossterm>
>              <info>
>                  PRIORITY[doc] = "Indicates the importance of a package.  The default value is 'optional'.  Other standard values are 'required', 'standard', and 'extra'."
> --
> 2.17.1
>

--
Martin 'JaMa' Jansa     jabber: Martin.Jansa@...


[PATCH 2/2] ref-manual: Update the documentation for USERADD_ERROR_DYNAMIC

Peter Kjellerstedt
 

* Update USERADD_ERROR_DYNAMIC[doc] and the first paragraph to match
the definition in meta/conf/documentation.conf.
* Add a note explaining the differences in behavior when setting
USERADD_ERROR_DYNAMIC to "warn" and "error" respectively.

[YOCTO #12932]

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...>
---
documentation/ref-manual/ref-variables.xml | 33 ++++++++++++++++------
1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index e6009926be..c8ece0c579 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -16770,18 +16770,21 @@

<glossentry id='var-USERADD_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm>
<info>
- USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in files/passwd and files/group files. If set to 'warn', a warning will be issued instead."
+ USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in any of the files listed in USERADD_UID_TABLES and USERADD_GID_TABLES. If set to 'warn', a warning will be issued instead."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- If set to "error", forces the OpenEmbedded build system to
- produce an error if the user identification
- (<filename>uid</filename>) and group identification
- (<filename>gid</filename>) values are not defined
- in <filename>files/passwd</filename>
- and <filename>files/group</filename> files.
- If set to "warn", a warning will be issued instead.
+
+ If set to <filename>error</filename>, forces the
+ OpenEmbedded build system to produce an error if the user
+ identification (<filename>uid</filename>) and group
+ identification (<filename>gid</filename>) values are not
+ defined in any of the files listed
+ in <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>
+ and <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>. If
+ set to <filename>warn</filename>, a warning will be issued
+ instead.
</para>

<para>
@@ -16808,6 +16811,20 @@
<link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
variables.
</para>
+
+ <note>
+ There is a difference in behavior between
+ setting <filename>USERADD_ERROR_DYNAMIC</filename>
+ to <filename>error</filename> and setting it
+ to <filename>warn</filename>. When it is set
+ to <filename>warn</filename>, the build system will report a
+ warning for every undefined <filename>uid</filename> and
+ <filename>gid</filename> in any recipe. But when it is set
+ to <filename>error</filename>, it will only report errors
+ for recipes that are actually built. This saves you from
+ having to add static IDs for recipes that you know will
+ never be built.
+ </note>
</glossdef>
</glossentry>

--
2.21.0


[PATCH 1/2] ref-manual: Add missing/remove extraneous quotes

Peter Kjellerstedt
 

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...>
---
documentation/ref-manual/migration.xml | 4 ++--
documentation/ref-manual/ref-variables.xml | 20 +++++++++-----------
2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
index 8d50ab9133..2052188b6b 100644
--- a/documentation/ref-manual/migration.xml
+++ b/documentation/ref-manual/migration.xml
@@ -2110,7 +2110,7 @@
such as the following:
<literallayout class='monospaced'>
inherit bluetooth
- PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
+ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
</literallayout>
@@ -3624,7 +3624,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
image types, this part of the kernel image base name as been
removed leaving only the following:
<literallayout class='monospaced'>
- KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}
+ KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
</literallayout>
If you have recipes or classes that use
<filename>KERNEL_IMAGE_BASE_NAME</filename> directly, you might
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 02abc590cd..e6009926be 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -367,7 +367,7 @@

<glossentry id='var-ASSUME_SHLIBS'><glossterm>ASSUME_SHLIBS</glossterm>
<info>
- ASSUME_SHLIBS[doc] = Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
+ ASSUME_SHLIBS[doc] = "Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -1423,7 +1423,7 @@
Use the following format to export the variable to the
BitBake environment:
<literallayout class='monospaced'>
- export BBSERVER=localhost:$port"
+ export BBSERVER=localhost:$port
</literallayout>
</para>

@@ -3786,7 +3786,7 @@
It is not intended to be user-configurable.
It is best to just reference the variable to see which distro features are
being backfilled for all distro configurations.
- See the <link linkend='ref-features-backfill'>Feature Backfilling</link> section for
+ See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
more information.
</para>
</glossdef>
@@ -11054,7 +11054,7 @@

<glossentry id='var-PN'><glossterm>PN</glossterm>
<info>
- PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package.
+ PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -13383,8 +13383,7 @@

<glossentry id='var-SKIP_FILEDEPS'><glossterm>SKIP_FILEDEPS</glossterm>
<info>
- SKIP_FILEDEPS[doc] = "Enables you to remove all files from
- the "Provides" section of an RPM package."
+ SKIP_FILEDEPS[doc] = "Enables you to remove all files from the 'Provides' section of an RPM package."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -15331,7 +15330,7 @@

<glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
<info>
- TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib."
+ TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or 'newlib'."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -16473,7 +16472,7 @@
Appends a string to the name of the local version of the
U-Boot image.
For example, assuming the version of the U-Boot image
- built was "2013.10, the full version string reported by
+ built was "2013.10", the full version string reported by
U-Boot would be "2013.10-yocto" given the following
statement:
<literallayout class='monospaced'>
@@ -17108,7 +17107,7 @@
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
section in the Yocto Project Development Tasks Manual.
For details on the kickstart file format, see the
- "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
+ "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>"
Chapter.
</para>
</glossdef>
@@ -17178,8 +17177,7 @@

<glossentry id='var-XSERVER'><glossterm>XSERVER</glossterm>
<info>
- XSERVER[doc] = "Specifies the packages that should be installed
- to provide an X server and drivers for the current machine."
+ XSERVER[doc] = "Specifies the packages that should be installed to provide an X server and drivers for the current machine."
</info>
<glossdef>
<para role="glossdeffirst">
--
2.21.0


Re: variable and task/function timing

Trevor Woerner
 

On Wed 2019-12-11 @ 04:49:27 PM, Nicolas Dechesne wrote:
right.. I was confused, I missed a few things in your email (well, it
was really long ;).
lol
Apparently writing long emails is therapeutic for me.

I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"
I did propose a 3rd way (in the original email) which does work which is very
similar to what you're suggesting:

# set the build type to either 'release' or 'debug'
# the upstream mesa sources actually build a debug release by default
# but here we assume the user will want a release build by default
MESA_BUILD_TYPE ?= "release"
def check_buildtype(d):
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
#bb.plain("setting meson build type to debugoptimized")
return 'debugoptimized'
return 'plain'
MESON_BUILDTYPE = "${@check_buildtype(d)}"

The user experience is rather different though. Let's say the user sets the
following in conf/local.conf:

MESA_BUILD_TYPE = "hello"

Using the "addtask" method (which doesn't work) produces a very nice error
message:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
Parsing of 1528 .bb files complete (1524 cached, 4 parsed). 2259 targets, 103 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "opensuseleap-15.1"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "tinker-rk3288"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-rockchip = "master:e8fd1f92ed59e0e71a7418779b912c5da342495c"
meta-tweaks = "master:b9184893949356a2da43bb2b5ec88dd573a5db0d"
meta = "master:093a1971f2ae12e1f514598da984f268607e550b"
meta-oe = "master:851321744e17e51aeb822a8d88c3532dffdf1cef"

Initialising tasks: 100% |####################################################################################################################| Time: 0:00:00
Sstate summary: Wanted 0 Found 0 Missed 0 Current 77 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: mesa-2_19.2.4-r0 do_check_build_type: unknown build type (hello), please set to either 'release' or 'debug'
ERROR: Logfile of failure stored in: /z/build-master/tinker-rk3288/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/mesa/2_19.2.4-r0/temp/log.do_check_build_type.12869
ERROR: Task (/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb:do_check_build_type) failed with exit code '1'
NOTE: Tasks Summary: Attempted 606 tasks of which 603 didn't need to be rerun and 1 failed.

Using the method proposed above produces:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug' ETA: --:--:--
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug'
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb
ERROR: ExpansionError during parsing /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
Traceback (most recent call last):
File "Var <MESON_BUILDTYPE>", line 1, in <module>
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa.inc", line 56, in check_buildtype(d=<bb.data_smart.DataSmart object at 0x7ffac8d0f4a8>):
if _buildtype not in ['release', 'debug']:
> bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/bitbake/lib/bb/__init__.py", line 108, in fatal:
mainlogger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()

bb.data_smart.ExpansionError: Failure expanding variable MESON_BUILDTYPE, expression was ${@check_buildtype(d)} which triggered exception BBHandledException:


Summary: There were 4 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.


Re: variable and task/function timing

Trevor Woerner
 

On Wed 2019-12-11 @ 03:48:51 PM, Richard Purdie wrote:
On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to
debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..."
line makes no difference. Probably because the variable is being set
by a task (which, I assume, is too late to have any effect, which is
a large part of why I wrote this email: when do these tasks get
called with respect to how variable are being set by all the
different ways they're being set?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.

That is why the setVar in a task has no effect outside that task.
Excellent, that explains a lot, thanks!

So in this case, the answer to the question of "when" is: never :-)


Re: variable and task/function timing

Nicolas Dechesne
 

On Wed, Dec 11, 2019 at 4:48 PM Richard Purdie
<richard.purdie@...> wrote:

On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to
debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..."
line makes no difference. Probably because the variable is being set
by a task (which, I assume, is too late to have any effect, which is
a large part of why I wrote this email: when do these tasks get
called with respect to how variable are being set by all the
different ways they're being set?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.
right... so my array is not 2D, but 3D then! but as i just said, i
missed the addtask in the first email.


That is why the setVar in a task has no effect outside that task.

Cheers,

Richard



Re: variable and task/function timing

Nicolas Dechesne
 

hey Trevor,

On Wed, Dec 11, 2019 at 4:39 PM Trevor Woerner <twoerner@...> wrote:

On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
On Wed, Dec 11, 2019 at 8:18 AM Trevor Woerner <twoerner@...> wrote:

Is there a document, or better yet a diagram, showing the order in which
various config files, recipes, tasks, etc are parsed?

Figuring out the order of the config files is easy enough (bitbake.conf), but
trying to figure out when various other parts are processed is just a guess
for me right now.
well the easiest way to visualize it is to think about all variables
being in a large array. Each variable (each row) having a different
'value' for each 'column' and each column representing a recipe. When
bitbake references a variable it is always in the context of a given
recipe, so you are looking at a specific 'column'. Initially this
array is filled with default values resulting from the parsing of all
global .conf files, as you noticed the list of conf files and the
order is set in bitbake.conf (which itself is hardcoded in bitbake,
and the first file to parse).

then bitbake will parse each recipe, one by one, and update each
variable's value in that array (in the relevant column). At the end of
the parsing, you have all variables which are known.

you can use bitbake -e to print variables value:

bitbake -e | grep ^MESON_BUILDTYPE

it will show you the default value (if it is set) outside the context
of any recipe.

bitbake -e <bar> | grep ^MESON_BUILDTYPE

will give you the value of this variable as it is set in <bar> recipe
Ooh, I like this already! Your row/column concept is a good mental map of the
process. Your explanation cleared up the "bitbake -e" vs "bitbake -e <bar>"
case for me too!

The content of the class is parsed when it is inherited. So you need
to initialize class variables *before* you inherit the class. e.g.

MESA_BUILD_TYPE ?= "release"
...
inherit meson

in your case is very different from
inherit meson
...
MESA_BUILD_TYPE ?= "release"

+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..." line makes
no difference. Probably because the variable is being set by a task (which, I
assume, is too late to have any effect, which is a large part of why I wrote
this email: when do these tasks get called with respect to how variable are
being set by all the different ways they're being set?)

You are
mixing BUILD_TYPE and BUILDTYPE in your email.. maybe you are mixing
that in your testing as well? What is set in local.conf will be parsed
first, so if you set a variable there, it will be 'set' when you parse
the recipe, so when you use ?= it should be a no-op.
Notice, though, that I'm using two different variables:

1) MESA_BUILD_TYPE: which can be set to "debug" or "release"
2) MESON_BUILDTYPE: which can be set to "plain" or "debugoptimized"

MESA_BUILD_TYPE is how the user tweaks the MESON_BUILDTYPE from the mesa
recipe. Given what you've said above, however, I can see now that (as you say)
setting:

MESON_BUILDTYPE_pn-mesa = ...

in conf/local.conf will do what I want since this variable is recipe-specific
and setting it in one recipe this way won't affect it in others.
right.. I was confused, I missed a few things in your email (well, it
was really long ;).


I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"


Re: variable and task/function timing

Richard Purdie
 

On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to
debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..."
line makes no difference. Probably because the variable is being set
by a task (which, I assume, is too late to have any effect, which is
a large part of why I wrote this email: when do these tasks get
called with respect to how variable are being set by all the
different ways they're being set?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.

That is why the setVar in a task has no effect outside that task.

Cheers,

Richard


Re: variable and task/function timing

Trevor Woerner
 

On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
On Wed, Dec 11, 2019 at 8:18 AM Trevor Woerner <twoerner@...> wrote:

Is there a document, or better yet a diagram, showing the order in which
various config files, recipes, tasks, etc are parsed?

Figuring out the order of the config files is easy enough (bitbake.conf), but
trying to figure out when various other parts are processed is just a guess
for me right now.
well the easiest way to visualize it is to think about all variables
being in a large array. Each variable (each row) having a different
'value' for each 'column' and each column representing a recipe. When
bitbake references a variable it is always in the context of a given
recipe, so you are looking at a specific 'column'. Initially this
array is filled with default values resulting from the parsing of all
global .conf files, as you noticed the list of conf files and the
order is set in bitbake.conf (which itself is hardcoded in bitbake,
and the first file to parse).

then bitbake will parse each recipe, one by one, and update each
variable's value in that array (in the relevant column). At the end of
the parsing, you have all variables which are known.

you can use bitbake -e to print variables value:

bitbake -e | grep ^MESON_BUILDTYPE

it will show you the default value (if it is set) outside the context
of any recipe.

bitbake -e <bar> | grep ^MESON_BUILDTYPE

will give you the value of this variable as it is set in <bar> recipe
Ooh, I like this already! Your row/column concept is a good mental map of the
process. Your explanation cleared up the "bitbake -e" vs "bitbake -e <bar>"
case for me too!

The content of the class is parsed when it is inherited. So you need
to initialize class variables *before* you inherit the class. e.g.

MESA_BUILD_TYPE ?= "release"
...
inherit meson

in your case is very different from
inherit meson
...
MESA_BUILD_TYPE ?= "release"

+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..." line makes
no difference. Probably because the variable is being set by a task (which, I
assume, is too late to have any effect, which is a large part of why I wrote
this email: when do these tasks get called with respect to how variable are
being set by all the different ways they're being set?)

You are
mixing BUILD_TYPE and BUILDTYPE in your email.. maybe you are mixing
that in your testing as well? What is set in local.conf will be parsed
first, so if you set a variable there, it will be 'set' when you parse
the recipe, so when you use ?= it should be a no-op.
Notice, though, that I'm using two different variables:

1) MESA_BUILD_TYPE: which can be set to "debug" or "release"
2) MESON_BUILDTYPE: which can be set to "plain" or "debugoptimized"

MESA_BUILD_TYPE is how the user tweaks the MESON_BUILDTYPE from the mesa
recipe. Given what you've said above, however, I can see now that (as you say)
setting:

MESON_BUILDTYPE_pn-mesa = ...

in conf/local.conf will do what I want since this variable is recipe-specific
and setting it in one recipe this way won't affect it in others.

I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure


Re: meta-intel stuck on bootup #yocto

Dimitris Tassopoulos
 

Hi, I don't is alsa is your actual issue, even if the kernel seems that it's stuck there,
but in any case you can remove the alsa from your distro. I guess you're using poky
as base distro, so add this line to your tmp/conf/local.conf file.

DISTRO_FEATURES_remove = "alsa"

then rebuild.

Regards.

On Wed, Dec 11, 2019 at 2:16 PM eph_pendragon <leocorp96@...> wrote:
Hi everyone,
So I am relatively new to the project and I have successfully been a able to make a few builds following the really well crafted documentation.

I however have a few issues regarding my target system, an IPC (Simatic Nanobox) with a quad-core Intel celeron processor. Since there's no Bsp that I am aware of, building an image with "genericx86-64" everything boots up alright but I am unable to reboot or shutdown the target system successfully. 

I later on added the "meta-intel" layer but up to no avail. The image gets stuck indefinitely on boot-up at: "listing ALSA devices ...".

1. Since I am not really interested in sound for my project, could someone point me to how to remove, fix or skip this step in the boot process altogether?

2. Also, what configuration should I make to my kernel or Bsp layer in order to achieve a successful reboot and shutdown on my target machine when using the bare yocto core-image-minimal?

Thanks. -=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47631): https://lists.yoctoproject.org/g/yocto/message/47631
Mute This Topic: https://lists.yoctoproject.org/mt/68149279/3958120
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=7196821
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [dimtass@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [meta-selinux] Dependency loop help with selinux userspace/python3/util-linux

Peter Morrow
 

On Wed, 2019-12-11 at 08:41 -0500, Joe MacDonald wrote:
[Re: [yocto] [meta-selinux] Dependency loop help with selinux userspace/python3/util-linux] On 19.12.11 (Wed 09:21) Peter Morrow via Lists.Yoctoproject.Org wrote:

On Wed, 2019-12-11 at 10:18 +0800, Yi Zhao via Lists.Yoctoproject.Org
wrote:


On 12/5/19 9:46 PM, Peter Morrow via Lists.Yoctoproject.Org wrote:

Hi Folks,

I'm trying to upgrade the meta-selinux layer to use a newer version
of
the selinux userspace tools (from 2.8 to 2.9), in doing so these
newer
userspace tools now depend on python3 instead of python2.  This
unfortunately has created a build time dependency loop in yocto:

python3 --> util-linux --> libselinux --> python3 (used to be
python2
with 2.8 selinux userspace).


Hi Peter,
I had sent a series patches to update selinux usersapce tools from
2.8 ot 2.9: 
https://www.yoctoproject.org/pipermail/yocto/2019-November/047329.html

After switch to python3, there is a loop dependency error with
libselinux-python package when build libselinux. So I split the
original libselinux recipe into  libselinux and libselinux-python.
You can refer my patchset.

Hi Yi,

Great!  Is there anything stopping these patches being merged?

No, no issue as far as I can tell, I'm preparing another merge to master
in the next couple of days.  This includes Yi's patches, my update
refpolicy purge feature and a few other things currently pending on the
list from the last few weeks.

-J.

Excellent , thanks Joe.

Peter.



Thanks,
Peter.




//Yi


Running "bitbake libselinux" results in a pile of loops, the one
below
illustrates the point.

ERROR:
Dependency loop #1 found:
  Task /workspace/git/yocto-selinux/meta-selinux/recipes-
security/selinux/libselinux_2.9.bb:do_package (dependent Tasks
['gcc-
runtime_9.2.bb:do_packagedata', 'libsepol_2.9.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'glibc_2.30.bb:do_packagedata',
'python3_3.7.5.bb:do_packagedata',
'libpcre_8.43.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'dwarfsrcfiles.bb:do_populate_sysroot',
'libselinux_2.9.bb:do_install'])
  Task /workspace/git/yocto-selinux/meta-selinux/recipes-
security/selinux/libselinux_2.9.bb:do_packagedata (dependent Tasks
['libselinux_2.9.bb:do_package'])
  Task /workspace/git/yocto-selinux/poky/meta/recipes-
extended/pam/libpam_1.3.1.bb:do_package (dependent Tasks ['gcc-
runtime_9.2.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'glibc_2.30.bb:do_packagedata', 'libselinux_2.9.bb:do_packagedata',
'flex_2.6.0.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'libxcrypt_4.4.8.bb:do_packagedata', 'libpam_1.3.1.bb:do_install',
'dwarfsrcfiles.bb:do_populate_sysroot',
'cracklib_2.9.5.bb:do_packagedata', 'libtool-
cross_2.4.6.bb:do_packagedata'])
  Task /workspace/git/yocto-selinux/poky/meta/recipes-
extended/pam/libpam_1.3.1.bb:do_packagedata (dependent Tasks
['libpam_1.3.1.bb:do_package'])
  Task /workspace/git/yocto-selinux/poky/meta/recipes-core/util-
linux/util-linux_2.34.bb:do_package (dependent Tasks ['gcc-
runtime_9.2.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'bash-completion_2.9.bb:do_packagedata',
'zlib_1.2.11.bb:do_packagedata', 'glibc_2.30.bb:do_packagedata',
'libselinux_2.9.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'ncurses_6.1+20190803.bb:do_packagedata',
'libxcrypt_4.4.8.bb:do_packagedata', 'libcap-
ng_0.7.9.bb:do_packagedata', 'opkg-utils_0.4.1.bb:do_packagedata',
'libpam_1.3.1.bb:do_packagedata', 'util-
linux_2.34.bb:do_install_ptest_base',
'dwarfsrcfiles.bb:do_populate_sysroot', 'util-
linux_2.34.bb:do_install', 'libtool-
cross_2.4.6.bb:do_packagedata'])
  Task /workspace/git/yocto-selinux/poky/meta/recipes-core/util-
linux/util-linux_2.34.bb:do_packagedata (dependent Tasks ['util-
linux_2.34.bb:do_package'])
  Task /workspace/git/yocto-selinux/poky/meta/recipes-
devtools/python/python3_3.7.5.bb:do_package (dependent Tasks
['xz_5.2.4.bb:do_packagedata', 'bzip2_1.0.8.bb:do_packagedata',
'gdbm_1.18.1.bb:do_packagedata', 'libnsl2_git.bb:do_packagedata',
'gcc-
runtime_9.2.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'python3_3.7.5.bb:do_install', 'libffi_3.3~rc0.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'sqlite3_3.29.0.bb:do_packagedata',
'openssl_1.1.1d.bb:do_packagedata',
'libtirpc_1.1.4.bb:do_packagedata',
'zlib_1.2.11.bb:do_packagedata',
'glibc_2.30.bb:do_packagedata',
'libxcrypt_4.4.8.bb:do_packagedata',
'python3_3.7.5.bb:do_install_ptest_base', 'util-
linux_2.34.bb:do_packagedata', 'opkg-
utils_0.4.1.bb:do_packagedata',
'readline_8.0.bb:do_packagedata',
'dwarfsrcfiles.bb:do_populate_sysroot', 'libtool-
cross_2.4.6.bb:do_packagedata'])
  Task /workspace/git/yocto-selinux/poky/meta/recipes-
devtools/python/python3_3.7.5.bb:do_packagedata (dependent Tasks
['python3_3.7.5.bb:do_package'])

Python3 (3.7.5) appears to depend on util-linux for libuuid
support, so
I don't think anything can be done with regards to
this.  libselinux
now depends on python3 as of 2.9, so again not much can be done
here. 
It's proving a bit harder to track down the util-linux dependency
on
libselinux but I believe this is a hard depdency as well.

I'm using the master branch of both poky and meta-selinux for
testing,
my local.conf file has the following to enable testing:

DISTRO_FEATURES_append=" acl xattr pam selinux"

The crux of the libselinux recipe change is really just changing
the
python2 deps over to python3 ones in meta-selinux/recipes-
security/selinux/libselinux.inc.

At this point I'd be trying to look for places where recipes can be
split out to remove the loop, but nothing jumps out at me.

Can anyone offer any advice or pointers on how to get around
this?  Or
am I just stuffed?

Many Thanks,
Peter.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47570): 
https://lists.yoctoproject.org/g/yocto/message/47570


Mute This Topic: 
https://lists.yoctoproject.org/mt/66953299/3616783


Group Owner: 
yocto+owner@...


Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/unsub

  [
yi.zhao@...

]
-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47623): 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fyocto%2Fmessage%2F47623&amp;data=02%7C01%7Cpeter.morrow%40microsoft.com%7Cf3b2a9c85ae945b3a0e008d77de064c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116275033359425&amp;sdata=tI784Zq%2BnoD%2BGVMjaWOfjRkqo5pJMN74RGfK4k9tQLI%3D&amp;reserved=0


Mute This Topic: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fmt%2F66953299%2F3618499&amp;data=02%7C01%7Cpeter.morrow%40microsoft.com%7Cf3b2a9c85ae945b3a0e008d77de064c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116275033359425&amp;sdata=IWzv8oKNUERzRgWWwRaBkh7fWwrQN14KJ1rhR73W484%3D&amp;reserved=0


Group Owner: 
yocto+owner@...


Unsubscribe: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fyocto%2Funsub&amp;data=02%7C01%7Cpeter.morrow%40microsoft.com%7Cf3b2a9c85ae945b3a0e008d77de064c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116275033359425&amp;sdata=mA9oeKX5%2Fq8B1WiUP6avWHP3%2BBY8OFcEHV%2BfqaJmClo%3D&amp;reserved=0

  [
peter.morrow@...

]
-=-=-=-=-=-=-=-=-=-=-=-



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47629): 
https://lists.yoctoproject.org/g/yocto/message/47629

Mute This Topic: 
https://lists.yoctoproject.org/mt/66953299/1150288

Group Owner: 
yocto+owner@...

Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/unsub
  [
joe@...
]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [meta-selinux] Dependency loop help with selinux userspace/python3/util-linux

Joe MacDonald
 

[Re: [yocto] [meta-selinux] Dependency loop help with selinux userspace/python3/util-linux] On 19.12.11 (Wed 09:21) Peter Morrow via Lists.Yoctoproject.Org wrote:

On Wed, 2019-12-11 at 10:18 +0800, Yi Zhao via Lists.Yoctoproject.Org
wrote:


On 12/5/19 9:46 PM, Peter Morrow via Lists.Yoctoproject.Org wrote:

Hi Folks,

I'm trying to upgrade the meta-selinux layer to use a newer version
of
the selinux userspace tools (from 2.8 to 2.9), in doing so these
newer
userspace tools now depend on python3 instead of python2. This
unfortunately has created a build time dependency loop in yocto:

python3 --> util-linux --> libselinux --> python3 (used to be
python2
with 2.8 selinux userspace).

Hi Peter,
I had sent a series patches to update selinux usersapce tools from
2.8 ot 2.9:
https://www.yoctoproject.org/pipermail/yocto/2019-November/047329.html
After switch to python3, there is a loop dependency error with
libselinux-python package when build libselinux. So I split the
original libselinux recipe into libselinux and libselinux-python.
You can refer my patchset.
Hi Yi,

Great! Is there anything stopping these patches being merged?
No, no issue as far as I can tell, I'm preparing another merge to master
in the next couple of days. This includes Yi's patches, my update
refpolicy purge feature and a few other things currently pending on the
list from the last few weeks.

-J.

Thanks,
Peter.




//Yi


Running "bitbake libselinux" results in a pile of loops, the one
below
illustrates the point.

ERROR:
Dependency loop #1 found:
Task /workspace/git/yocto-selinux/meta-selinux/recipes-
security/selinux/libselinux_2.9.bb:do_package (dependent Tasks
['gcc-
runtime_9.2.bb:do_packagedata', 'libsepol_2.9.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'glibc_2.30.bb:do_packagedata',
'python3_3.7.5.bb:do_packagedata',
'libpcre_8.43.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'dwarfsrcfiles.bb:do_populate_sysroot',
'libselinux_2.9.bb:do_install'])
Task /workspace/git/yocto-selinux/meta-selinux/recipes-
security/selinux/libselinux_2.9.bb:do_packagedata (dependent Tasks
['libselinux_2.9.bb:do_package'])
Task /workspace/git/yocto-selinux/poky/meta/recipes-
extended/pam/libpam_1.3.1.bb:do_package (dependent Tasks ['gcc-
runtime_9.2.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'glibc_2.30.bb:do_packagedata', 'libselinux_2.9.bb:do_packagedata',
'flex_2.6.0.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'libxcrypt_4.4.8.bb:do_packagedata', 'libpam_1.3.1.bb:do_install',
'dwarfsrcfiles.bb:do_populate_sysroot',
'cracklib_2.9.5.bb:do_packagedata', 'libtool-
cross_2.4.6.bb:do_packagedata'])
Task /workspace/git/yocto-selinux/poky/meta/recipes-
extended/pam/libpam_1.3.1.bb:do_packagedata (dependent Tasks
['libpam_1.3.1.bb:do_package'])
Task /workspace/git/yocto-selinux/poky/meta/recipes-core/util-
linux/util-linux_2.34.bb:do_package (dependent Tasks ['gcc-
runtime_9.2.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'bash-completion_2.9.bb:do_packagedata',
'zlib_1.2.11.bb:do_packagedata', 'glibc_2.30.bb:do_packagedata',
'libselinux_2.9.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'ncurses_6.1+20190803.bb:do_packagedata',
'libxcrypt_4.4.8.bb:do_packagedata', 'libcap-
ng_0.7.9.bb:do_packagedata', 'opkg-utils_0.4.1.bb:do_packagedata',
'libpam_1.3.1.bb:do_packagedata', 'util-
linux_2.34.bb:do_install_ptest_base',
'dwarfsrcfiles.bb:do_populate_sysroot', 'util-
linux_2.34.bb:do_install', 'libtool-
cross_2.4.6.bb:do_packagedata'])
Task /workspace/git/yocto-selinux/poky/meta/recipes-core/util-
linux/util-linux_2.34.bb:do_packagedata (dependent Tasks ['util-
linux_2.34.bb:do_package'])
Task /workspace/git/yocto-selinux/poky/meta/recipes-
devtools/python/python3_3.7.5.bb:do_package (dependent Tasks
['xz_5.2.4.bb:do_packagedata', 'bzip2_1.0.8.bb:do_packagedata',
'gdbm_1.18.1.bb:do_packagedata', 'libnsl2_git.bb:do_packagedata',
'gcc-
runtime_9.2.bb:do_packagedata',
'rpm_4.14.2.1.bb:do_populate_sysroot',
'python3_3.7.5.bb:do_install', 'libffi_3.3~rc0.bb:do_packagedata',
'pseudo_git.bb:do_populate_sysroot',
'sqlite3_3.29.0.bb:do_packagedata',
'openssl_1.1.1d.bb:do_packagedata',
'libtirpc_1.1.4.bb:do_packagedata',
'zlib_1.2.11.bb:do_packagedata',
'glibc_2.30.bb:do_packagedata',
'libxcrypt_4.4.8.bb:do_packagedata',
'python3_3.7.5.bb:do_install_ptest_base', 'util-
linux_2.34.bb:do_packagedata', 'opkg-
utils_0.4.1.bb:do_packagedata',
'readline_8.0.bb:do_packagedata',
'dwarfsrcfiles.bb:do_populate_sysroot', 'libtool-
cross_2.4.6.bb:do_packagedata'])
Task /workspace/git/yocto-selinux/poky/meta/recipes-
devtools/python/python3_3.7.5.bb:do_packagedata (dependent Tasks
['python3_3.7.5.bb:do_package'])

Python3 (3.7.5) appears to depend on util-linux for libuuid
support, so
I don't think anything can be done with regards to
this. libselinux
now depends on python3 as of 2.9, so again not much can be done
here.
It's proving a bit harder to track down the util-linux dependency
on
libselinux but I believe this is a hard depdency as well.

I'm using the master branch of both poky and meta-selinux for
testing,
my local.conf file has the following to enable testing:

DISTRO_FEATURES_append=" acl xattr pam selinux"

The crux of the libselinux recipe change is really just changing
the
python2 deps over to python3 ones in meta-selinux/recipes-
security/selinux/libselinux.inc.

At this point I'd be trying to look for places where recipes can be
split out to remove the loop, but nothing jumps out at me.

Can anyone offer any advice or pointers on how to get around
this? Or
am I just stuffed?

Many Thanks,
Peter.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47570):
https://lists.yoctoproject.org/g/yocto/message/47570

Mute This Topic:
https://lists.yoctoproject.org/mt/66953299/3616783

Group Owner:
yocto+owner@...

Unsubscribe:
https://lists.yoctoproject.org/g/yocto/unsub
[
yi.zhao@...
]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47623):
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fyocto%2Fmessage%2F47623&;data=02%7C01%7Cpeter.morrow%40microsoft.com%7Cf3b2a9c85ae945b3a0e008d77de064c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116275033359425&amp;sdata=tI784Zq%2BnoD%2BGVMjaWOfjRkqo5pJMN74RGfK4k9tQLI%3D&amp;reserved=0

Mute This Topic:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fmt%2F66953299%2F3618499&;data=02%7C01%7Cpeter.morrow%40microsoft.com%7Cf3b2a9c85ae945b3a0e008d77de064c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116275033359425&amp;sdata=IWzv8oKNUERzRgWWwRaBkh7fWwrQN14KJ1rhR73W484%3D&amp;reserved=0

Group Owner:
yocto+owner@...

Unsubscribe:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fyocto%2Funsub&;data=02%7C01%7Cpeter.morrow%40microsoft.com%7Cf3b2a9c85ae945b3a0e008d77de064c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116275033359425&amp;sdata=mA9oeKX5%2Fq8B1WiUP6avWHP3%2BBY8OFcEHV%2BfqaJmClo%3D&amp;reserved=0
[
peter.morrow@...
]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47629): https://lists.yoctoproject.org/g/yocto/message/47629
Mute This Topic: https://lists.yoctoproject.org/mt/66953299/1150288
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [joe@...]
-=-=-=-=-=-=-=-=-=-=-=-

--
-Joe MacDonald.
:wq


meta-intel stuck on bootup #yocto

eph_pendragon
 

Hi everyone,
So I am relatively new to the project and I have successfully been a able to make a few builds following the really well crafted documentation.

I however have a few issues regarding my target system, an IPC (Simatic Nanobox) with a quad-core Intel celeron processor. Since there's no Bsp that I am aware of, building an image with "genericx86-64" everything boots up alright but I am unable to reboot or shutdown the target system successfully. 

I later on added the "meta-intel" layer but up to no avail. The image gets stuck indefinitely on boot-up at: "listing ALSA devices ...".

1. Since I am not really interested in sound for my project, could someone point me to how to remove, fix or skip this step in the boot process altogether?

2. Also, what configuration should I make to my kernel or Bsp layer in order to achieve a successful reboot and shutdown on my target machine when using the bare yocto core-image-minimal?

Thanks.


Re: variable and task/function timing

Nicolas Dechesne
 

On Wed, Dec 11, 2019 at 8:18 AM Trevor Woerner <twoerner@...> wrote:

Is there a document, or better yet a diagram, showing the order in which
various config files, recipes, tasks, etc are parsed?

Figuring out the order of the config files is easy enough (bitbake.conf), but
trying to figure out when various other parts are processed is just a guess
for me right now.
well the easiest way to visualize it is to think about all variables
being in a large array. Each variable (each row) having a different
'value' for each 'column' and each column representing a recipe. When
bitbake references a variable it is always in the context of a given
recipe, so you are looking at a specific 'column'. Initially this
array is filled with default values resulting from the parsing of all
global .conf files, as you noticed the list of conf files and the
order is set in bitbake.conf (which itself is hardcoded in bitbake,
and the first file to parse).

then bitbake will parse each recipe, one by one, and update each
variable's value in that array (in the relevant column). At the end of
the parsing, you have all variables which are known.

you can use bitbake -e to print variables value:

bitbake -e | grep ^MESON_BUILDTYPE

it will show you the default value (if it is set) outside the context
of any recipe.

bitbake -e <bar> | grep ^MESON_BUILDTYPE

will give you the value of this variable as it is set in <bar> recipe

Of course, the parsing is dealing with all operators as well.

In a global conf file you set a variable for a specific recipe with
the _pn- operator. e.g. use:

MESON_BUILDTYPE_pn-bar = "debug"
to set MESON_BUILDTYPE to debug for the <bar> recipe.


Conceptually this is what I want to do:

Currently the meson build system (class) is hard-coded to always produce
a buildtype of "plain", which are (basically) production builds. But
there are other buildtypes that can be specified; such as
"debugoptimized". I want a recipe to be able to influence the meson
buildtype, and I want the user to be able to tweak this parameter from
their conf/local.conf.

Here's what I want to do:

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index dc8c28963c..e1a13bbbf7 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
def noprefix(var, d):
return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)

+MESON_BUILDTYPE ?= "plain"
MESONOPTS = " --prefix ${prefix} \
- --buildtype plain \
+ --buildtype ${MESON_BUILDTYPE} \
--bindir ${@noprefix('bindir', d)} \
--sbindir ${@noprefix('sbindir', d)} \
--datadir ${@noprefix('datadir', d)} \
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 5838207e6b..fb232d414e 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,20 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"

MESA_LLVM_RELEASE ?= "${LLVMVERSION}"

+# set the build type to either 'release' or 'debug'
+# the upstream mesa sources actually build a debug release by default
+# but here we assume the user will want a release build by default
+MESA_BUILD_TYPE ?= "release"
The content of the class is parsed when it is inherited. So you need
to initialize class variables *before* you inherit the class. e.g.

MESA_BUILD_TYPE ?= "release"
...
inherit meson

in your case is very different from
inherit meson
...
MESA_BUILD_TYPE ?= "release"

+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \

Therefore if the user doesn't do anything explicitly, a production buildtype
will be produced. However, if the user were to specify the following in their
conf/local.conf:

MESA_BUILD_TYPE = "debug"

I want mesa's buildtype to be "debugoptimized".

I don't want the user to specify the following in their conf/local.conf:

MESON_BUILDTYPE = "debugoptimized"
use _pn- operator for that, as mentioned above.


because that would cause *all* meson-built packages to switch to the
debugoptimized buildtype. I only want mesa's build to be debugoptimized.

However, the above doesn't work. If I set MESA_BUILD_TYPE to "hello" in my
conf/local.conf, then the build will flag it and error out asking me to
specify either 'release' or 'debug', which is great. But if I set
MESA_BUILD_TYPE to 'debug' the MESON_BUILDTYPE variable is always set to
"plain" regardless. So this task runs, but I guess it runs too late to
influence the MESON_BUILDTYPE variable?
That is unexpected.. I would have thought it should work. You are
mixing BUILD_TYPE and BUILDTYPE in your email.. maybe you are mixing
that in your testing as well? What is set in local.conf will be parsed
first, so if you set a variable there, it will be 'set' when you parse
the recipe, so when you use ?= it should be a no-op.


So, how can I run this function earlier (?) so that it can set the
MESON_BUILDTYPE variable correctly? I tried the following:

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index dc8c28963c..e1a13bbbf7 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
def noprefix(var, d):
return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)

+MESON_BUILDTYPE ?= "plain"
MESONOPTS = " --prefix ${prefix} \
- --buildtype plain \
+ --buildtype ${MESON_BUILDTYPE} \
--bindir ${@noprefix('bindir', d)} \
--sbindir ${@noprefix('sbindir', d)} \
--datadir ${@noprefix('datadir', d)} \
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 5838207e6b..b302f8ee55 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,20 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"

MESA_LLVM_RELEASE ?= "${LLVMVERSION}"

+# set the build type to either 'release' or 'debug'
+# the upstream mesa sources actually build a debug release by default
+# but here we assume the user will want a release build by default
+MESA_BUILD_TYPE ?= "release"
+def check_buildtype(d):
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ bb.plain("setting meson build type to debugoptimized")
+ return 'debugoptimized'
+ return 'plain'
+MESON_BUILDTYPE = "${@check_buildtype(d)}"
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \

This will print out the bb.plain() message 16 times during parsing etc, it
will fail out if MESA_BUILD_TYPE is not one of 'release' or 'debug' (which is
good), but if this occurs, the error message is printed out twice plus a
python traceback, which might be scary to users.

The last thing I tried was the following:

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index dc8c28963c..e1a13bbbf7 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
def noprefix(var, d):
return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)

+MESON_BUILDTYPE ?= "plain"
MESONOPTS = " --prefix ${prefix} \
- --buildtype plain \
+ --buildtype ${MESON_BUILDTYPE} \
--bindir ${@noprefix('bindir', d)} \
--sbindir ${@noprefix('sbindir', d)} \
--datadir ${@noprefix('datadir', d)} \
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 5838207e6b..c265ffc246 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,12 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"

MESA_LLVM_RELEASE ?= "${LLVMVERSION}"

+# set the build type to either 'release' or 'debug'
+# the upstream mesa sources actually build a debug release by default
+# but here we assume the user will want a release build by default
+MESA_BUILD_TYPE ?= "release"
+MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \

This works perfectly, but it lacks the error checking and helpful messages of
the previous attempts.

Any thoughts on how I can have it all? (i.e. nice error checking and error
messages with the variable tweakable from conf/local.conf?

Best regards,
Trevor
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47628): https://lists.yoctoproject.org/g/yocto/message/47628
Mute This Topic: https://lists.yoctoproject.org/mt/68144480/1279857
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [nicolas.dechesne@...]
-=-=-=-=-=-=-=-=-=-=-=-

11021 - 11040 of 58669