Hi,

on kirkstone branch when trying to build rust for raspberrypi machine
I'm getting:

ERROR: rust-cross-arm1176jzfshf-vfp-glibc-1.59.0-r0
do_rust_gen_targets: Error executing a python function in
exec_func_python() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_rust_gen_targets(d)
0003:
File: '/data/projects/test-build/.build-rpi/../sources/poky/meta/recipes-devtools/rust/rust-cross.inc',
lineno: 19, function: do_rust_gen_targets
0015: if arch == "arm" and target_is_armv7(d):
0016: arch = 'armv7'
0017: features = d.getVar('TARGET_LLVM_FEATURES') or ""
0018: cpu = d.getVar('TARGET_LLVM_CPU')
*** 0019: rust_gen_target(d, thing, wd, features, cpu, arch, abi)
0020:}
0021:
0022:# Otherwise we'll depend on what we provide
0023:INHIBIT_DEFAULT_RUST_DEPS = "1"
File: '/data/projects/test-build/.build-rpi/../sources/poky/meta/recipes-devtools/rust/rust-common.inc',
lineno: 314, function: rust_gen_target
0310: # build tspec
0311: tspec = {}
0312: tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
0313: tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
*** 0314: tspec['max-atomic-width'] =
int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
0315: tspec['target-pointer-width'] =
d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
0316: tspec['target-c-int-width'] =
d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
0317: tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
0318: tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like
object or a number, not 'NoneType'

by adding below it seems to fix an issue (copied from meta-rust):
diff --git a/meta/recipes-devtools/rust/rust-common.inc
b/meta/recipes-devtools/rust/rust-common.inc
index ef70c48d0f..389c75d2f7 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -118,6 +118,15 @@ def llvm_features(d):
llvm_features_from_target_fpu(d))


+
+DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm-eabi] = "little"
+TARGET_POINTER_WIDTH[arm-eabi] = "32"
+TARGET_C_INT_WIDTH[arm-eabi] = "32"
+MAX_ATOMIC_WIDTH[arm-eabi] = "64"
+FEATURES[arm-eabi] = "+v6,+vfp2"
+
## arm-unknown-linux-gnueabihf

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Pokybuild User
Sent: Tuesday, 15 November, 2022 7:00 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [yocto] QA notification for completed autobuilder build (yocto-
4.1.1.rc1)


A build flagged for QA (yocto-4.1.1.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.1.1.rc1


Build hash information:

bitbake: 138dd7883ee2c521900b29985b6d24a23d96563c
meta-agl: e5dd276442a8c9268a8818a638b07ee96383b657
meta-arm: ff9b6f29bf4a6e3fcead5c1025a413cffee7bc53
meta-aws: 8537180c8645455ee2b57c696389df21fc17f63a
meta-intel: f70cf173dc40131e5ed3955a4a459fff3aa010ed
meta-mingw: b0067202db8573df3d23d199f82987cebe1bee2c
meta-openembedded: c5668905a6d8a78fb72c2cbf8b20e91e686ceb86
meta-virtualization: 8857b36ebfec3d548755755b009adc491ef320ab
oecore: 9237ffc4feee2dd6ff5bdd672072509ef9e82f6d
poky: d3cda9a3e0837eb2ac5482f5f2bd8e55e874feff



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

Thanks Mike for your advice!
I've replaced underscore to hyphen and rerun a build from fetch, but unfortunately that didn't invoke auto-load.
In fact, my modules are device drivers developed in out-of-tree repositories. Some user-space applications depend on them, so I wanted them to be auto-loaded on boot. Autoload didn't occur even though I've added corresponding devicetree properties.
Best
Merlin

langdale isn't currently supported on any branch of meta-agl

Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 17 -----------------
1 file changed, 17 deletions(-)

diff --git a/config.json b/config.json
index da87a2d..27283c9 100644
--- a/config.json
+++ b/config.json
@@ -403,23 +403,6 @@
"SANITYTARGETS" : "core-image-sato:do_testsdk"
}
},
- "meta-agl-core" : {
- "NEEDREPOS" : ["poky", "meta-agl"],
- "ADDLAYER" : [
- "${BUILDDIR}/../meta-agl/meta-agl-core"
- ],
- "DISTRO" : "poky-agl",
- "BUILDINFO" : true,
- "BUILDHISTORY" : true,
- "PACKAGE_CLASSES" : "package_rpm",
- "extravars" : [
- "AGL_FEATURES = 'aglcore'"
- ],
- "step1" : {
- "MACHINE": "qemux86-64",
- "BBTARGETS": "agl-image-core-autobuilder"
- }
- },
"meta-aws" : {
"NEEDREPOS" : ["poky", "meta-openembedded", "meta-aws"],
"ADDLAYER" : [
--
2.25.1

Hi Maik,

On 11/17/22 16:22, Maik Vermeulen wrote:
> Hi,
>
> Depending on the image that's being built, e.g. development vs. production,
> we would like to be able to include different user passwords and firewall
> settings.
>
> We know this can be achieved by just having two different recipes that do
> the same thing, but with different variables or included files. However, we
> were wondering if there is a neater way?
>
> We saw this post:
> https://urldefense.com/v3/__https://www.yoctoproject.org/pipermail/yocto/2018-June/041378.html__;!!OOPJP91ZZw!k-UkKru_mKI6U4p8UgDfH_VEh1-qar1kiQuqcmnyrETRAnubF79KykqR7VGaRu47i1Ws7n8CAagOJBqEFBB3goTxmBkgn8-qL3X383IHnKva$
> which seems to do what we want, because one recipe can install
> recipe-development, and the other can install recipe-production, while the
> recipe itself can then implement what needs to happen for either.
> However, other recipes included in the images can also depend on recipe,
> and they shouldn't depend on one specifically. They should accept that
> either recipe-development or recipe-production is included. Currently we
> see that both the generic recipe and the specific recipe used by the image
> are built and overwrite each other.
>
> What would be a neat way to achieve two variants of a recipe, and having
> different contents and settings in them?
> Or, can we solve that other included recipes depend on one of the variants,
> instead of on the generic one.
>

Development vs production is solved by using different distros.

You can then have the same recipe but with different files (see
(DISTRO)OVERRIDES mechanism for SRC_URI file:// files, c.f.
https://summit.yoctoproject.org/media/yocto-project-summit-2022-05/submissions/SCYYWD/resources/Demystifying_the_OVERRIDES_mec_2lZOP3n.pdf)
and/or different variables via FOO:dev-distro or FOO:append:dev-distro
for example.

You could also have different recipes both PROVIDES'ing the same virtual
recipe and then have PREFERRED_PROVIDER_my-recipe = "my-recipe-dev" in
your dev-distro.conf file.

Two distros is usually overkill when you have very small and
non-invasive differences between your dev and prod images (e.g. an
additional package, or a lone package that needs to be slightly
different). In that scenario, a "drity" solution is to have two recipes
and have the final image pick the appropriate package. But this quickly
does not scale well once you have recipes/packages depending on those or
if you have more than two flavors to support.

The best practice is to use two distros.

Cheers,
Quentin