olani has quit [Remote host closed the connection]
olani has joined #yocto
<qschulz>
o/
d-fens_ has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
mvlad has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
xmn_ has joined #yocto
xmn has quit [Ping timeout: 264 seconds]
florian has joined #yocto
d-fens_ has joined #yocto
xmn_ has quit [Quit: ZZZzzz…]
tomzy_0 has quit [Quit: Client closed]
<ldericher>
g'morning as well :) still struggling with SDKs ... for unit testing purposes, I need to build my application _for the host_, so I'd appreciate if I could `bitbake ... -c populate_sdk` to target my host. After building, I'll figure out dealing with the dynamic links myself :)
<qschulz>
ldericher: I would build the SDK for a machine that works on your host
<qschulz>
e.g. genericx86-64 possibly?
<LetoThe2nd>
ldericher: well thats just not what the sdk is. so you either have to switch machines (as qschulz suggested), or create a form of "sdk-like" class
<ldericher>
qschulz, "a machine that works on your host" as in "a machine my host can run (i.e. run the tests using qemu)", or like "a machine that approximates my host (i.e. run the tests natively)"?
florian_kc has joined #yocto
<LetoThe2nd>
ldericher: the latter.
marek49 has joined #yocto
seninha has joined #yocto
<qschulz>
and if you want the former, we have qemu machines for those
<d-fens_>
hi, how can i add "dtoverlay=dwc2,dr_mode=host" to my config.txt ?
<d-fens_>
thanks, i already added ENABLE_DWC2_HOST = "1" and probably it is in effect as it doesn't boot anymore but searches the network for a netboot or idk, so something different is fishy
mckoan_ has joined #yocto
mckoan_ is now known as mckoan|away
mckoan|away has quit [Client Quit]
mckoan has quit [Ping timeout: 256 seconds]
mckoan has joined #yocto
<rburton>
RP: ouch, why is a sstate test taking so long?
<RP>
rburton: it is probably the changes in master-next :(
<RP>
rburton: although I'm surprised they're running that slowly
<rburton>
maybe the machine was just incredibly loaded
<rburton>
ldericher: if you just want your app in the SDK, just add nativesdk-myapp (after doing BBCLASSEXTEND=nativesdk). Though as said, a better solution is building your stack for qemux86-64 or whatever your host architecture is: then you can runqemu with kvm, get native speed, but still run the tests in the right environment.
<rburton>
you can use testimage/ptests etc for running the test suite
<rburton>
add it as part of the CI
jtoomey has quit [Ping timeout: 260 seconds]
tomzy_0 has joined #yocto
<rburton>
has anyone else seen master's clang get upset at kernels with "llvm-objcopy: error: Link field value 27 in section .rela.dyn is not a symbol table" (paging khem)
marek49 has quit [Quit: Client closed]
mckoan is now known as mckoan|away
Algotech has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
Algotech has joined #yocto
tomzy_0 has quit [Quit: Client closed]
florian_kc has joined #yocto
Amynka_ is now known as Amynka
pml has joined #yocto
seninha has quit [Quit: Leaving]
<pml>
Hi - i'm getting a compile error for autoconf-native recipe on dunfell...specifically the error is "make: *** No rule to make target '4'. Stop.".. any suggestions where to start debugging ?
Guest22 has joined #yocto
Guest22 has quit [Client Quit]
<rburton>
pml: can you replicate with a bare poky checkout on the dunfell branch (literally clone, checkout dunfell, bitbake autoconf-native)? can you share the full log? is the host distro a supported one?
<pml>
rburon: yes, it's a supported distro (ubuntu20.04)... I'll try with a bare poke and report back shortly
<pml>
interestingly enough, I've successfully built a previous dunfell image on this host for another project...
<rburton>
possibly a broken build tree and deleting it would work, or you've got a layer which is doing something really nasty
<pml>
rburton: so..with a bare poky checkout (dunfell), it works (as expected)
<rburton>
pml: so what layers are you adding to break it? :)
prabhakarlad has quit [Quit: Client closed]
<pml>
lol -- let me share the list, one sec
<rburton>
in theory you can use bitbake to tell you what broke. build bare poky, add the layers, bitbake -Sdiff automake-native
<rburton>
iirc
<pml>
ok, will try that.. in meantime, it seems to me that the meta-ti and meta-smartmicro (their own layer) is breaking it
<pml>
seems to be a layer commenly used in automotive sector..?
<pml>
but it is at the url i posted above
<rburton>
oh god why does that layer have a whole new toolchain in
<pml>
i have no idea
<pml>
ugh
<pml>
so i'm trying the -S thing again, but its not showing a diff
<pml>
am i suppose to do a cleanall again, after adding the layer and try building again ?
<rburton>
just blast tmp, faster than cleanll
<rburton>
you're just building autoconf-native anyway
<pml>
so, i blast the tmp, rebuild, it fails with the previous error, i then do bitbake -Sdiff autoconf-native
<pml>
but it is not giving a diff ? only wrting a locked sigs file...?
<rburton>
-Sprintdiff
<rburton>
do a good build, add the layers which breaks it, then printdiff
<pml>
ok, gotcha
prabhakarlad has joined #yocto
<ldericher>
now my `do_populate_sdk` errors out with some inode mismatches. Can I clean that without a complete rebuild?
<qschulz>
ldericher: are you building inside a contianer?
florian_kc has quit [Ping timeout: 268 seconds]
pidge[m] has joined #yocto
<ldericher>
yes
<ldericher>
qschulz, ...
<qschulz>
ldericher: hehehe
<qschulz>
--tmpfs /tmp
<qschulz>
and IIRC you also need to increase the pids_limit in /etc/containers/containers.conf
<ldericher>
qschulz, `bitbake: error: no such option: --tmpfs` am I dumb?
<qschulz>
ldericher: it's an argument to podman/docker
<ldericher>
… I'm probably dumb though, that seems like an arg to docker
<ldericher>
_hi5_
<qschulz>
yeah sorry, should have made this clearer
<ldericher>
weird thing is, a few moments ago everything built well
<qschulz>
ldericher: the pids_limit is not always hit if you reuse the cache between builds
<qschulz>
as for the tmpfs, it's probably related too
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
rusam has joined #yocto
florian_kc has joined #yocto
marek56 has joined #yocto
<marek56>
Hi, I'm adding some more info to /ect/issue doing rootfs postprocess handling. I know it' not "yocto" way but I need to run some shell commands in order to populate some variables. Is there any way I can force run postprocess on every build? I've tried to add `my_cmd[nostamp] = "1"` but it doesn't help. Thanks
<qschulz>
marek56: i'm nbot sure but i'd believe that nostamp only applies to tasks?
<rusam>
marek56: search the manual for the ROOTFS_POSTPROCESS_COMMAND variable
<marek56>
qschulz: Hmm probably right. So there is not a way ho to handle that?
sakoman has joined #yocto
<qschulz>
marek56: mark the task calling this function as nostamp
<qschulz>
also I think it depends how you set the variable
<qschulz>
because it's not because a function is re-run that the variable it depends on are re-evaluated between builds
<qschulz>
since it will probably detect there were no changes to recipes/classes/whatever so there's no need to reparse and reevaluate the variables
<qschulz>
(except if the variable is set in your function directly then forcing the rerun of the function via nostamp should be enough I think
<marek56>
qschulz I would need mark do_rootfs then as no stamp as in meta/lib/oe/rootfs.py there is handling ` post_process_cmds = self.d.getVar("ROOTFS_POSTPROCESS_COMMAND")`
d-fens_ has quit [Read error: Connection reset by peer]
<pml>
rburton: i've done a good build, added the offending layer, and the did a -Sprintdiff... but it is not showing any diff... i'm not sure what i'm doing wrong
<pml>
in addition, i can get the autoconf-native to fail by just adding back their internal layer
nemik_ has quit [Ping timeout: 256 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 248 seconds]
nemik_ has joined #yocto
tor has quit [Ping timeout: 256 seconds]
<rburton>
well at least you've isolated the layer
rusam has quit [Quit: Leaving...]
d-fens_ has joined #yocto
<d-fens_>
how can i find out what receipe is generating the missing bootfiles ? (cp: cannot stat '/build/tmp/deploy/images/raspberrypi4/bootfiles/*': No such file or directory)
xmn has joined #yocto
<d-fens_>
cleaned the dir out as the error with 'Disk ful'l when generating boot partition still persited
<rburton>
yeah its talking about the disk image it's creating
<rburton>
something in meta-rpi probably has a hardcoded size for that partition
rsalveti has joined #yocto
<d-fens_>
now i'd like to run bitbake -c clean but_which_receipt
<rburton>
easier to just delete tmp, it rebuilds from sstate in seconds
<d-fens_>
ok will try that
<ldericher>
ok, this one is beyond repair. how can I cleanup everything related to building the SDK?
<rburton>
ldericher: delete tmp :)
<ldericher>
rburton, just a touch less aggressive, i hoped?
<rburton>
meh, more effort
<rburton>
you might miss something
<rburton>
delete and build from sstate is faster than trying to figure out the list of recipes to clean
<ldericher>
should I also remove build/deploy?
<ldericher>
rburton, ...
<rburton>
that's part of tmp/
<rburton>
so yes
<qschulz>
ldericher: anything that isn't the downloads or sstate-cache directory should be safe from deletion
<qschulz>
if it's not, then it's an issue in one of the layers you're using and should be fixed
<ldericher>
my issue is definitely related to tmp - it built fine a few hours ago and I didn't change any layers in the meantime
leon-anavi has quit [Quit: Leaving]
<ldericher>
well … at least that machine is rather safe from `(sudo) rm -rf /` - deleting tmp takes quite some time even with 24 cores
sion33 has joined #yocto
malsyned has joined #yocto
<rburton>
i typically mv tmp foo, and rm -rf foo &
<rburton>
cores are irrelevant, it's an I/O thing
nemik_ has quit [Ping timeout: 260 seconds]
rob_w has quit [Remote host closed the connection]
<mcfrisk>
I see kernel module signing failures on kirkstone again. Somehow kernel and modules ended up with different keys, all out of sstate cache. signing modules happens in kernel "make modules_install", kernel is embedded with the same key at compile time. there must be races..
Wouter010067 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
gsalazar_ has quit [Remote host closed the connection]
Estrella has joined #yocto
<malsyned>
LetoThe2nd: Our set-up may be a little unusual, but our source tree has the source for our app under src/ and our bitbake layer in yocto/meta-<mycompany>, with other layers checked out as submodules under yocto/. So all of our recipes contain something like FILESEXTRAPATHS:prepend :=
<malsyned>
t to abstract that somewhere, so that it only has to change in one place and isn't a magic incantation everywhere.
<malsyned>
"${THISDIR}/../../../../:" which is kinda ugly and brittle. I wan
<malsyned>
My first thought was a bbclass, because I already have a bbclass handling some other layer-specific stuff.
<qschulz>
malsyned: what about using externalsrc class for this?
<malsyned>
qschulz: first time I've heard of it, but the name sounds promising. I'll check it out, thanks!
<qschulz>
malsyned: but that's not a very good idea to be honest, having the source code with your build system in the same git repo
gsalazar_ has joined #yocto
<qschulz>
what happens if you decide to change the build system (e.g. switch to buildroot for example, or whatever else you could think of)
<malsyned>
qschulz: I would imagine I'd try the same thing I'm doing here, adding a buildroot/ subdir for that set-up and asking these same kinds of questions in there IRC channel :)
<malsyned>
We definitely may outgrow our setup and have to graduate to what you're describing, but for the time being this is a simpler and less error-prone workflow to explain and oversee.
<qschulz>
it also means you're tying a version of your sw to a specific version of yocto
<qschulz>
there is no need for that
<malsyned>
At the moment, that's an advantage to us.
<qschulz>
anyways, up to you. I've been there, was more painful than helpful to me.
<qschulz>
can't remember all the pitfalls, just that I complained a lot about it :)
<qschulz>
well, i complain a lot in general, so maybe it was just business as usual, who knows :)
goliath has joined #yocto
<rburton>
no you're right its a terrible idea
<rburton>
system integration != software development
<RP>
malsyned: for such a layer you could set a variable in layer.conf using ${LAYERDIR} which you could then reference the source with?
<zeddii>
since distro_features is a variable like the rest .. can it have a native set of values ? Special handling might be breaking things, but I'm trying to get the incantation right.
<RP>
zeddii: we set it differently for native recipesiirc
frieder has quit [Remote host closed the connection]
<zeddii>
I'll grep around a bit and see what I can find.
<zeddii>
I'm trying to build some recipes as native and they are tripping over the distro features check.
<RP>
zeddii: DISTRO_FEATURES_FILTER_NATIVE and DISTRO_FEATURES_NATIVE in bitbake.conf
<zeddii>
I was able to do a class-native :remove override to make one build, but that seems too error prone.
<zeddii>
ahaha
<zeddii>
cool. I'll chase that down.
<rburton>
kanavin: do you have a python 3.11.1 upgrade in one of your branches?
<malsyned>
RP: that may be what I go with.
leon-anavi has joined #yocto
leon-anavi has quit [Quit: Leaving]
marek56 has quit [Ping timeout: 260 seconds]
yashraj466 has joined #yocto
zpfvo has quit [Remote host closed the connection]