<wojci>
hnez, I think that #labgrid is quite dead. Was that German company behind labgrid not sold to Intel? Is it still active? :)
Saur_Home94 has quit [Quit: Client closed]
<hnez>
wojci: You are thinking of Linutronix. Pengutronix, my employer, is still doing fine and was not sold to Intel ;)
Saur_Home94 has joined #yocto
<wojci>
hnez, Ah. I see. :D
jmd has quit [Remote host closed the connection]
<wojci>
hnez, I'm kind of wondering about the design of Labgrid. I was expecting to be able to use the client from another network with just a SSH connection the the exporter, but it doesn't seem to work that way. The client sends packets directly and not using the host running the exporter.
<rburton>
we never integrated the 'run in qemu' bit
<rburton>
lets respin that and see
ehussain has quit [Ping timeout: 272 seconds]
<mcfrisk_>
rburton: the uki patches had a refactoring bug, easy to fix. I'm adding testcase for x86* and aarch64 (I guess this will cover qemuarm64 and genericarm64). test can be arch agnostic but the build config needs to know if u-boot or ovmf gets compiled
xmn has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
dmoseley_ has quit [Ping timeout: 246 seconds]
Chaser has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
wooosaiiii has quit [Ping timeout: 276 seconds]
wooosaiiii has joined #yocto
vthor_ has joined #yocto
vthor has quit [Read error: Connection reset by peer]
aduskett has joined #yocto
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #yocto
pidge_ has quit [Ping timeout: 265 seconds]
aduskett has quit [Remote host closed the connection]
aduskett has joined #yocto
GillesM has joined #yocto
Guest37 has quit [Quit: Client closed]
bhstalel has joined #yocto
<bhstalel>
Hello everyone,
<bhstalel>
If recipe A just installs an executable that rdepends on a shared library provided by recipe B
<bhstalel>
Does just specifying DEPENDS += "B" is enough in order for recipe A to find out in the package_data of each recipe in DEPENDS that B provides that library and then it adds it automatically to RDEPENDS ?
luc4 has joined #yocto
<RP>
bhstalel: usually bitbake can see the shared library dependency unless it uses dlopen or something
<bhstalel>
I mean, if I have recipe A that provides the lib, but I never build it, and recipe B depends on it at run time.
<bhstalel>
BitBake will find out that recipe B's executable depends on a shared library, does it just fire an error/warning, or tries to look in all recipes ?
<bhstalel>
I think the recipe A needs to be built in order for BitBake to export that it provides a shared library, so when it comes to recipe B then it finds recipe A and added to RDEPENDS
<bhstalel>
right ?
<luc4>
Hello! It seems that Yocto often keeps data from previous builds. Is there a way to cleanup everything that is not actually part of the current image? For example, I built many versions of the same packages, and I think old versions are kept. Any way to clean everything and leave only what is currently used by an image (without rebuilding it)?
<kanavin>
luc4, you can pretty much wipe build/tmp anytime between running bitbake
<kanavin>
cleaning sstate is trickier, typically people use find to get a list of things that haven't been accessed recently, and wipe those
<luc4>
kanavin: but doing that implies that next time I'll build my image, everything will be rebuilt?
<kanavin>
luc4, doing what?
<luc4>
kanavin: wipe build/tmp
<kanavin>
luc4, no. it will get prebuilt objects from sstate and unpack them, which is as fast as your machine can do i/o and zstd decompress
<luc4>
kanavin: ah I see, thanks then!
<kanavin>
the only thing that will repeat is producing the image, do_rootfs and further tasks
<kanavin>
try it. it's pretty neat to watch the first time :)
<luc4>
kanavin: by "wipe" do you mean the good old "rm -rf"?
<kanavin>
luc4, I do 'mv tmp tmp2' first then 'rm -rf tmp2'
<kanavin>
that way you can start bitbake without waiting for rm to finish
<luc4>
kanavin: ok, I'll try then :-) thanks!
<kanavin>
luc4, there's also rm_work class that does this automatically, but I don't use it because I like manual control over what is kept in the build trees and what is deleted
<kanavin>
but some ppl love rm_work
<RP>
kanavin: It was fun to note a build with rm_work is 1 min slower on an SSD :)
Saur_Home94 has quit [Quit: Client closed]
Saur_Home94 has joined #yocto
gspbirel56 has joined #yocto
gspbirel56 has quit [Ping timeout: 252 seconds]
pidge has joined #yocto
bhstalel has quit [Quit: Client closed]
Guest37 has joined #yocto
wojci has quit [Ping timeout: 248 seconds]
aduskett has quit [Quit: Konversation terminated!]
bhstalel has joined #yocto
Saur_Home94 has quit [Quit: Client closed]
Saur_Home94 has joined #yocto
jmiehe has joined #yocto
Guest37 has quit [Quit: Client closed]
fabatera has joined #yocto
luc4 has quit [Quit: Konversation terminated!]
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #yocto
rob_w has quit [Remote host closed the connection]
Guest9 has joined #yocto
Xagen has joined #yocto
gspbirel56 has joined #yocto
<Guest9>
Hi,
<Guest9>
I am trying to figure out whether the following can be achieved in Yocto.
<Guest9>
Say I have a recipe, "mylib.bb", that ultimately installs a file called "libmylib.so" under folder "/foo/".
<Guest9>
Say I have another recipe, "myapp.bb", that is a make-based C/C++ application, that needs "libmylib.so" and hence has a DEPENDS on "mylib.bb".
<Guest9>
As folder "/foo" is an unusual installation folder, by default, the makefile+toolchain setup will not include it on the search path for libraries.
<Guest9>
Can I do something in "mylib.bb" so that by adding it as a DEPENDS its takes care of adjusting the LDFLAGS (ie: modifies somehow TARGET_LDFLAGS adding the required "-L=/foo/") for "myapp.bb" ?
<Guest9>
I know I can do TARGET_LDFLAGS:append directly on "myapp.bb", but that makes things harder to maintain.
<Guest9>
Thx.
<rburton>
Guest9: easy fix: install the library into $libdir
<rburton>
workaround is to add -L=/foo to LDFLAGS as you have done, because that's the correct answer to your problem
<rburton>
if you have _lots_ of libraries that install into that directory then you can do other things
mathieudb has quit [Quit: leaving]
mathieudb has joined #yocto
gspbirel56 has quit [Ping timeout: 272 seconds]
<bhstalel>
Guest9: I am not sure if your /foo is picked up by do_populate_sysroot ?
<rburton>
yeah thats another complication of using random paths
<bhstalel>
do_populate_sysroot picks what is in SYSROOT_DIRS variable.
sotaoverride has joined #yocto
<bhstalel>
So, for your question, you need also to do:
<bhstalel>
SYSROOT_DIRS:append = " /foo"
<bhstalel>
rburton: exactly
<rburton>
you could just extend LDFLAGS globally instead of in that recipe,
aduskett has joined #yocto
mathieudb has quit [Quit: leaving]
GillesM has quit [Quit: Leaving]
Granjow has joined #yocto
<Granjow>
Hi, I'm trying to apply kernel configuration from a config file I received (it is around 5k lines long), and I'm getting a myriad of info entries that “last val (m) and .config val (n) do not match” or similar. I have a .scc file which does “kconf hardware mylongfile.cfg”. Is this wrong?
Minvera has joined #yocto
<tlwoerner>
do tasks have to be written in sh or can we use bash?
mathieudb has joined #yocto
<bhstalel>
tlwoerner: Yocto docs: "Shell Function Syntax: Write shell functions as if you were writing a shell script when you describe a list of actions to take. You should ensure that your script works with a generic sh and that it does not require any bash or other shell-specific functionality. "
<JaMa>
at least dash is quite common for /bin/sh
<rburton>
yeah i assume dash to be honest
fabatera has quit [Quit: Client closed]
Net147 has quit [Ping timeout: 255 seconds]
steelswords94 has quit [Read error: Connection reset by peer]
Saur_Home94 has quit [Quit: Client closed]
Saur_Home94 has joined #yocto
steelswords94 has joined #yocto
ray-san has quit [Ping timeout: 260 seconds]
bhstalel has quit [Quit: Client closed]
bhstalel has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
<Guest9>
rburton, bhstalel
<Guest9>
Thx for the mindshare.
<Guest9>
I had already taken care of SYSROOT_DIRS (indeed a gotcha for those of us only moderately versed in Yocto). Thx.
<Guest9>
Using standard folder is obviously also a solution, but, I am asking because that path is not entirely under my control.
<Guest9>
A pity there is no built-in mechanism.
<Guest9>
What about when building the "Standard SDK" ? Can the recipe "mylib.bb" influence the initial LDFLAGS that we get on the SDK environment ?
<yocton>
isn't it a task for packageconfig?
<yocton>
mylib would create a .pc file with it's custom LFLAGS and the recipes depending on this lib can get the paths from the same .pc file?
Poppy has joined #yocto
bhstalel has quit [Quit: Client closed]
<yocton>
I meant pkg-config instead of packageconfig
xmn has joined #yocto
Granjow has quit [Ping timeout: 256 seconds]
Saur_Home94 has quit [Quit: Client closed]
Saur_Home94 has joined #yocto
<Guest9>
yocton - interesting suggestion - I'll explore that
Kubu_work has quit [Quit: Leaving.]
gspbirel56 has joined #yocto
rfuentess has quit [Remote host closed the connection]
sukbeom has quit [Quit: Ping timeout (120 seconds)]
sukbeom has joined #yocto
patwolfe has joined #yocto
florian has quit [Ping timeout: 252 seconds]
florian has joined #yocto
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #yocto
nerdboy has quit [Ping timeout: 252 seconds]
Saur_Home84 has quit [Quit: Client closed]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
Saur_Home84 has joined #yocto
Kubu_work has quit [Quit: Leaving.]
Chaser has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
reatmon_ has joined #yocto
mrhip has joined #yocto
mrhip has quit [Client Quit]
mr-hip has joined #yocto
<mr-hip>
I have copied all the poky files to a newly created partition. I'm trying to install grub on that partition so it boots poky. But grub-install says "cannot get canonical path of overlay".
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
mr-hip has quit [Ping timeout: 256 seconds]
mr-hip has joined #yocto
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #yocto
Xagen has joined #yocto
Xagen has quit [Client Quit]
Xagen has joined #yocto
mr-hip has quit [Ping timeout: 256 seconds]
patwolfe has quit [Quit: Client closed]
merit has joined #yocto
Saur_Home84 has quit [Quit: Client closed]
Saur_Home84 has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
Saur_Home84 has quit [Quit: Client closed]
Saur_Home84 has joined #yocto
vthor_ has quit [Excess Flood]
vthor_ has joined #yocto
mr-hip has joined #yocto
<mr-hip>
I have copied all the poky files to a newly created partition. I'm trying to install grub on that partition so it boots poky. But grub-install says "cannot get canonical path of overlay".