esben[m] has quit [Quit: Bridge terminating on SIGTERM]
Salamandar has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
derinachan[m] has quit [Quit: Bridge terminating on SIGTERM]
Ablu[m] has quit [Quit: Bridge terminating on SIGTERM]
lrusak[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
patersonc[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
yudjinn[m] has quit [Quit: Bridge terminating on SIGTERM]
ebilizbelaziz[m] has quit [Quit: Bridge terminating on SIGTERM]
suwako[m] has quit [Quit: Bridge terminating on SIGTERM]
ramacassis[m] has quit [Quit: Bridge terminating on SIGTERM]
gstinocher[m] has quit [Quit: Bridge terminating on SIGTERM]
TRO[m] has quit [Quit: Bridge terminating on SIGTERM]
p34nuts[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
KareemZarka[m] has quit [Quit: Bridge terminating on SIGTERM]
osteoblast22[m] has quit [Quit: Bridge terminating on SIGTERM]
phako[m] has quit [Quit: Bridge terminating on SIGTERM]
tenko[m]1 has quit [Quit: Bridge terminating on SIGTERM]
static_rocket has quit [Quit: Bridge terminating on SIGTERM]
argonautx[m] has quit [Quit: Bridge terminating on SIGTERM]
NiteshD[m] has quit [Quit: Bridge terminating on SIGTERM]
Mickal[m] has quit [Quit: Bridge terminating on SIGTERM]
Finn[m] has quit [Quit: Bridge terminating on SIGTERM]
mborzecki has quit [Quit: Bridge terminating on SIGTERM]
hpsy[m] has quit [Quit: Bridge terminating on SIGTERM]
VasylVavrychuk[m has quit [Quit: Bridge terminating on SIGTERM]
Archon[m] has quit [Quit: Bridge terminating on SIGTERM]
lorenzog[m] has quit [Quit: Bridge terminating on SIGTERM]
linex[m] has quit [Quit: Bridge terminating on SIGTERM]
glgspg[m] has quit [Quit: Bridge terminating on SIGTERM]
HenkMedenblik[m] has quit [Quit: Bridge terminating on SIGTERM]
DasChaos[m] has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
tomzy_0[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
simonsilie[m] has quit [Quit: Bridge terminating on SIGTERM]
Francesco[m] has quit [Quit: Bridge terminating on SIGTERM]
g-tenko-r[m] has quit [Quit: Bridge terminating on SIGTERM]
mrybczyn[m] has quit [Quit: Bridge terminating on SIGTERM]
baeruhne[m] has quit [Quit: Bridge terminating on SIGTERM]
arlort[m] has quit [Quit: Bridge terminating on SIGTERM]
banditopazzo[m] has quit [Quit: Bridge terminating on SIGTERM]
Entei[m] has quit [Quit: Bridge terminating on SIGTERM]
abbasalichezgi[m has quit [Quit: Bridge terminating on SIGTERM]
perceval[m] has quit [Quit: Bridge terminating on SIGTERM]
jquaresma[m] has quit [Quit: Bridge terminating on SIGTERM]
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
Guest98 has joined #yocto
<Guest98>
Hi everyone. I want to pull the MACHINE_ARCH value with the python function and call a function accordingly in a recipe. I want to do something as i will share below. What did i do wrong?
<Guest98>
pastebin.com/17kSxzAa
ecdhe has quit [Ping timeout: 268 seconds]
ecdhe has joined #yocto
<mcfrisk>
Guest98: it is easy to make functions MACHINE specific. Is that suffiecient? basically add machine specific functions to the recipe, do_configure:machine_a(). You need to use machine names specified in MACHINEOVERRIDES
eddy_ has joined #yocto
eddy_ has quit [Client Quit]
gsalazar has joined #yocto
<Guest98>
mcfrisk Instead of using a Python function, you say use it like this:
<Guest98>
do_install_machine_a(){
<Guest98>
install -d ${D}/machine_a
<Guest98>
}
<Guest98>
do_install_machine_b(){
<Guest98>
install -d ${D}/machine_b
<Guest98>
}
<Guest98>
am i right?
<mcfrisk>
Guest98: do_install:machine_a() {...}
<mcfrisk>
Guest98: use the machine override name specified in MACHINEOVERRIDES variable
<rburton>
(if opsec installed MS Defender, then say goodbye to performance)
dwagenk has joined #yocto
Ablu[m] has joined #yocto
static_rocket has joined #yocto
kayterina[m] has joined #yocto
ejoerns[m] has joined #yocto
Entei[m] has joined #yocto
berton[m] has joined #yocto
argonautx[m] has joined #yocto
perceval[m] has joined #yocto
jquaresma[m] has joined #yocto
DasChaos[m] has joined #yocto
ebilizbelaziz[m] has joined #yocto
phako[m] has joined #yocto
ramacassis[m] has joined #yocto
KareemZarka[m] has joined #yocto
linex[m] has joined #yocto
osteoblast22[m] has joined #yocto
lorenzog[m] has joined #yocto
HenkMedenblik[m] has joined #yocto
baeruhne[m] has joined #yocto
Finn[m] has joined #yocto
arlort[m] has joined #yocto
banditopazzo[m] has joined #yocto
NiteshD[m] has joined #yocto
hpsy[m] has joined #yocto
Mickal[m] has joined #yocto
abbasalichezgi[m has joined #yocto
Archon[m] has joined #yocto
mborzecki has joined #yocto
<Emantor>
rburton: Hey, is there a specific reason meta-arm depends on meta-arm toolchain? We have some recipes we'd like to use from meta-arm (TF-A, OP-TEE,…) but usually don't need/require meta-arm-toolchain.
<rburton>
because some bits of meta-arm need the binary toolchain (at the moment)
<rburton>
they're in the same repo and adding meta-arm-toolchain won't change anything unless you explicitly use it
<rburton>
it's not like adding it switches your compiler automatically
<Emantor>
So the eventual goal is to remove the meta-arm-toolchain dependency? Just feels weird to have meta-arm-toolchain in bblayers when it is not used for anything.
<rburton>
it doesn't do any harm
<rburton>
we've a long-term plan to switch the M class builds to use multiconfig, but that means people with A/M platforms need to build gcc-cross twice, so pick your poison
<Emantor>
Eh, I see, thanks for the info.
<shoragan>
we try to keep our layer lists minimal, so having an unused layer in there regularly leads to questions :)
alejandr1 has quit [Ping timeout: 256 seconds]
<rburton>
live with it feeling weird to have a layer that you don't use. the alternative right now is to have a separate layer that _just_ contains tfm, which is silly
manuel1985 has quit [Ping timeout: 264 seconds]
<shoragan>
for some customers we decided to copy the recipes instead, which isn't optimal either
alejandr1 has joined #yocto
<rburton>
sorry, tfm and scp
<shoragan>
why do they need the binary toolchain?
<rburton>
because they need a M-class compiler that targets baremetal, not an A-class that targets linux
<shoragan>
and that's not possible with the toolchain in oe-core?
<rburton>
with multiconfig, yes. haven't got around to doing that yet.
<rburton>
also, tfm is _incredibly_ sensitive to gcc, and upgrading the binary toolchain will break it
<shoragan>
ah, so it's just using the binary toolchain for the cortex-m binaries in the cortex-a build
<shoragan>
hrmm.
<shoragan>
thanks for explaining
seninha has quit [Quit: Leaving]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
manuel1985 has joined #yocto
<RP>
rburton: I'm still not 100% convinced we can't use our toolchain to build baremetal without multilib. Does it actually need any library code?
<rburton>
you'd be surprised where libgcc creeps into builds, which then expects to be running in linux
<rburton>
it mostly works right now but firmware is doing stuff like stubbing out functions
<rburton>
letting that argument settle before making any changes :)
<RP>
rburton: building a different libgcc with our current build shouldn't be too hard...
<RP>
it is effectively what baremetal does
<rburton>
right
<RP>
it could be a kind of multilib
<rburton>
i suspect we'll end up multiconfiging a proper m/baremetal compiler and other pieces, especially as stuff like Trusted Services is basically building a second OS
yssh has quit [Quit: Client closed]
<RP>
rburton: the baremetal stuff is really simple so there are a few options...
<rburton>
don't look at the trusted-services recipe :)
<ecdhe>
I'm trying to build a 'sumo' image in `kas-container' but HOSTTOOLS is calling out python2.7 and it's missing from the container.
<ecdhe>
Are sumo-era builds not supported by kas?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Xagen has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
<LetoThe2nd>
ecdhe: well the container generation obviously needs to be roughly aligned with the release generation. kas without containers will happily build sumo for you.
<LetoThe2nd>
ecdhe: alternatively, inject a custom (outdated) container. or even better: upgrade.
Haxxa has joined #yocto
alessioigor has quit [Quit: alessioigor]
<rburton>
ecdhe: kas container is far too new for sumo yes
akiCA has quit [Quit: Leaving]
PobodysNerfect has quit [Quit: Gone to sleep. ZZZzzz…]
Thorn has quit [Ping timeout: 240 seconds]
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
goliath has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
prabhakar has quit [Quit: Connection closed]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
bps has joined #yocto
bps has joined #yocto
warthog9 has quit [Quit: Leaving]
warthog9 has joined #yocto
Minvera has quit [Ping timeout: 240 seconds]
astlep5504 has joined #yocto
PobodysNerfect has joined #yocto
florian_kc has quit [Ping timeout: 246 seconds]
bps has quit [Ping timeout: 265 seconds]
PobodysNerfect has quit [Ping timeout: 265 seconds]