otavio has quit [Remote host closed the connection]
chrfle_ has joined #yocto
chrfle has quit [Ping timeout: 265 seconds]
chrfle_ is now known as chrfle
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
Vonter has joined #yocto
bluelightning has quit [Quit: Konversation terminated!!!111]
amitk has joined #yocto
dmoseley has quit [Ping timeout: 240 seconds]
dmoseley has joined #yocto
sakoman has quit [Quit: Leaving.]
xmn has quit [Ping timeout: 240 seconds]
Vonter has quit [Ping timeout: 256 seconds]
marex has quit [Ping timeout: 265 seconds]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
mariusz1 has joined #yocto
Schlumpf has joined #yocto
Vonter has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
tnovotny has joined #yocto
mckoan|away is now known as mckoan
mvlad has joined #yocto
ziga has quit [Quit: Leaving]
ziga has joined #yocto
<ziga>
Where can I check the compilation output / log for any recipe that was already compiled?
lexano has quit [Ping timeout: 240 seconds]
<qschulz>
ziga: if you didn't remove the tmp dir, it's in ${WORKDIR}/temp/log.do_<task>
lexano has joined #yocto
prabhakarlad has joined #yocto
<RP>
rburton: we have more of those meson "not runnable" errors on arm :(
<RP>
ah, but centos7. I wonder if it is that qemu kernel version removal
<dacav>
Hi. I've got a defective SDK installer (I can't build it). Is there a practical way of connecting the right gdb to the gdbserver that I'm running on the target?
<dacav>
ah, nvm, I think I can try with a minimal method, as by manual.
<ziga>
Thank you qschulz!
manuel1985 has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
<dacav>
So, I went for `bitbake gdb-cross-<architecture>` as suggested by the common-tasks manual (both populate_sdk and meta-toolchain tasks fail). I'm now a bit confused on where to find my gdb ... :-/ There's a ton of sub-directories here
zpfvo has joined #yocto
<dacav>
The manual suggeests `dir/tmp/sysroots/host/usr/bin/architecture/architecture-gdb`, but there's not much under `sysroots`
<qschulz>
dacav: I suspect you're reading old docs?
<qschulz>
binaries usually are available in the WORKDIR of the recipe
<qschulz>
that is, in tmp/work/<arch>/<recipe-name>/<recipe-version>/
<dacav>
qschulz: eh, I found it now, thanks. It is missing dependencies though.
<dacav>
runtime dependencies.
<dacav>
(let alone the crazy-long path it is hidden below :D)
<dacav>
Am I supposed to chroot somewhere, perhaps?
<ziga>
qschultz there are multiple "do_configure" logs that I am interested i.e. "log.do_configure.1136934" "log.do_configure.2146617" ... How do I use the trailing number to know which one is which? How do I find the last one?
<dacav>
ziga: ah, I know this one! YAY! It is the pid
<dacav>
also there should be a symlink to the last one, I believe. Otherwise, the last modification date should help ;-)
<qschulz>
ziga: use the one without the trailing number
<qschulz>
dacav: ok, that's the last docs, I guess they would benefit an updte if it's not correct anymore
<ziga>
Thank you dacv & qschulz. Is the one without the trailing number the last one?
<qschulz>
dacav: I'm not sure runtime dependencies are built when building a recipe only?
<dacav>
ziga: the one without the trailing number should be a symlink to the last one
Guest86 has joined #yocto
<dacav>
qschulz: ...not sure either. In this case it is gdb complaining about missing python bits. I'm wondering if they're missing because they're not built, or because the search path should be fixed.
<ziga>
@dacav TY
Guest86 is now known as epac-tom
<qschulz>
dacav: I think there's a wrapper to execute host packages built from Yocto but I'm not sure anymore
<qschulz>
something like -c devshell?
<dacav>
`bitbake -c devshell` or so? I'll try
Vonter has quit [Read error: Connection reset by peer]
<dacav>
bitbake -c listtasks gdb-cross-aarch64 | grep -q devshell && echo YEP, I see that.
<dacav>
EXCELLENT!
<dacav>
qschulz: thanks, that was precious!
Vonter has joined #yocto
<dacav>
This is totally worth a mention in the docs! May I mention it on the docs ml maybe?
zpfvo has quit [Ping timeout: 256 seconds]
<qschulz>
dacav: where would you want this to be mentioned? and what should it say about devshell?
leon-anavi has joined #yocto
zpfvo has joined #yocto
<hmw[m]>
Hi,
<hmw[m]>
is $PV availble set as enviroment variable when do_compile is executed ?
<rburton>
no
<rburton>
you can export it if you want though
<hmw[m]>
( can i use it in cmakelists.txt
<rburton>
typically the source knows the version, and the recipe reflects that, not the other way around
<rburton>
but just export it if you need to
<hmw[m]>
rburton: yes, ( got a few lazy devs that don´t update version number and is updated-ed using ci tools ....)
mckoan is now known as mckoan|away
<dacav>
qschulz: you said that the document I mentioned would benefit from an update. I would suggest to replace the "If you are using the build system, Gdb is located in..." part.
<dacav>
(hence replacing the outdated info with this excellent trick!)
<qschulz>
dacav: if that is what one's actually supposed to do, fine by me :)
<qschulz>
it seems the original doc wasn't correct anymore anyway
<qschulz>
I just don't know if it's the proper solution or not
manuel1985 has quit [Ping timeout: 240 seconds]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
goliath has quit [Quit: SIGSEGV]
manuel1985 has joined #yocto
otavio has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
leon-anavi has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
camus has quit [Quit: camus]
mariusz1 has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
Guest49 has joined #yocto
<Guest49>
Hi.. What would you recommend when I need to override (phyton) function for two machines/overrides? E.g. I have machine machA and machB and func do_something. I would like to override this function for machA and machB
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<qschulz>
Guest49: is it a python function or a python task?
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
Schlumpf has quit [Quit: Client closed]
sakoman has joined #yocto
<Guest49>
qschulz sry, task
<Guest49>
or variable override for two (or more) machines/overrides
<qschulz>
Guest49: if it's a task, just use the override
<qschulz>
Guest49: do_mytask:machA () {}
<qschulz>
note that it completely overrides the original do_mytask
<qschulz>
if you want to append/prepend, it's a different thign
<Guest49>
qschulz that's clear..
<qschulz>
halstead: michaelo: docs.yoctoproject.org is broken, it returns a file browser instead of the master/dev branch of the docs
<Guest49>
qschulz I would like to do do_mytask:machA () {common logic for machA and machB, but not for others} and do_mytask:machB () {common logic for machA and machB, but not for others}, but combine it so it's not duplicated
<qschulz>
Guest49: define a common override in both of your machines and add it to MACHINEOVERRIDES
<rburton>
what to fetch, what config, what to build
<zpfvo>
rburton: nice, will look into it. maybe we can use it :)
<kergoth>
Kas is nice, but I do wish it had more options to generate the config, i.e. from repo manifest, .gitmodules, bblayers.conf, ..
<kergoth>
just as a convenience. guess i could do that myself if i cared enough to :)
<vd>
does the kernel require particular options for runqemu?
hjones2199[m] has quit [Quit: You have been kicked for being idle]
<coldspark29[m]>
@rburton Why do you think they are icky?
<rburton>
they're just a bit of a pain to work with
<rburton>
you can very much tell that submodules are bolted onto git
<JPEW>
I prefer submodules FWIW
<JPEW>
They've gotten a lot better, and most tools know how to deal with them now
<kergoth>
More git operations seem to recurse into them nowadays at least. Still has some pain points
<JPEW>
Plus, I don't like having to gitignore my modules (when not using submodules) because then my grep tools don't recurse into the modules
mariusz1 has joined #yocto
<kergoth>
I just don't use a parent repository at the top of my workspace, then that's not an issue. I.e. when using repo
<vd>
kergoth: wouldn't it be better to have a mechanism such as recipes for the layer you want to use?
<vd>
kergoth: in addition to what recipes provide already, we'd benefit from the bitbake fetcher to get the layer repositories from any source
tnovotny has quit [Quit: Leaving]
marex has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
epac-tom has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
goliath has joined #yocto
<coldspark29[m]>
Hmm well, I like kas, but I also see the advantage of not being dependent on it.
<halstead>
qschulz: Looks like the last docs build didn't copy completely. Docs are rebuilding now.
florian has quit [Quit: Ex-Chat]
Vonter has quit [Quit: WeeChat 3.4]
leon-anavi has quit [Quit: Leaving]
Guest49 has quit [Quit: Client closed]
florian has joined #yocto
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
mariusz1 has quit [Ping timeout: 240 seconds]
<vd>
'runqemu nographic slirp core-image-minimal' works fine with beaglebone-yocto but I have no console with beaglebone from meta-ti, even though I copied over the QB_* variable.
wCPO has quit [Read error: Connection reset by peer]