qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
rm5248 has quit [Quit: Leaving.]
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
benkard has joined #yocto
mulk has quit [Ping timeout: 255 seconds]
benkard is now known as mulk
afong__ has quit [Ping timeout: 264 seconds]
ehussain has joined #yocto
chep` has joined #yocto
chep- has joined #yocto
chep has quit [Ping timeout: 268 seconds]
chep- is now known as chep
chep` has quit [Ping timeout: 240 seconds]
xmn has quit [Ping timeout: 252 seconds]
ablu has quit [Read error: Connection reset by peer]
ablu has joined #yocto
simone has joined #yocto
simone has quit [Ping timeout: 268 seconds]
alperak has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
leon-anavi has joined #yocto
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Dracos-Carazza has joined #yocto
rob_w has joined #yocto
jmd has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
mattsm7 has joined #yocto
mattsm has quit [Ping timeout: 264 seconds]
mattsm7 is now known as mattsm
thomas_34 has joined #yocto
<thomas_34>
Good morning guys, a special question for all the yocto veterans here: ;)
<thomas_34>
I have a bunch of different MACHINES which all uses the same kernel sources, but with different defconfigs.
<thomas_34>
The defconfigs are set during patch-task via FILES += "defconfig_machinename".
<thomas_34>
Whats the best practise, to be sure that bitbake does not overwrite WORKDIR or caches wrongly when I build the kernel/image for every MACHINE in a row?
<thomas_34>
My idea was, to control MULTIMATCH_TARGET_SYS which is part of WORKDIR. Is that the right approach?
<thomas_34>
To give that a extra flavor for each of my MACHINE definition? Just for the kernel recipe?
olani- has joined #yocto
<ablu>
thomas_34: Different machines should already build to different folders. So this should "just" work. Do you observe errors?
<thomas_34>
ablu, For the kernel it does work. I have also some modificated u-boot-stuff which is put into "tmp/<toolchain>/aarch64_oe_linux/. aarch64 is wrong here, its the architecture of the core, not the machine name.
<thomas_34>
But this is my fault. I just wanna know if that approach would be correct here?
<ablu>
thomas_34: What made you change that path? Can you just drop the manual assignment of the WORKDIR there?
<thomas_34>
I had to modify u-boot so much that I ended up to write a new recipe which just builds all the artefacts which I need from my u-boot sources.
<ablu>
thomas_34: Ok, I am not sure why you need to override "WORKDIR" for that, but I guess the first step would be to attempt to stop doing that :)
enok has joined #yocto
<thomas_34>
ablu, what happens if you build u-boot from same sources with config1, config2, config3 via bitbake?
<ablu>
thomas_34: What does "from the same sources" mean? Typically you would specify a SRC_URI and that gets unpacked under your WORKDIR. So each build will have it's own set of sources to build against.
<thomas_34>
For each of the 3 variants, the same git source (commit hash) is used.
<ablu>
You should still have 3 unpacks for each variant (if "variant" is machine), so three WORKDIRs with each an unpacked source under them.
Michael_Guest has joined #yocto
<thomas_34>
ablu now we are at the point. This I don't have. Where do you think should be the difference in the paths of these variants?
<ablu>
thomas_34: Well, WORKDIR should already provide you with machine and recipe specific paths. But it sounded like you overwrite that. It would probably help if you would post the recipe.
rfuentess has joined #yocto
<thomas_34>
No, I am not overwriting that. Thats why I have no difference regarding my machine configurations. My question was which part of the WORKDIR yocto people normaly doing that. And I think the solution would be "PACKAGE_ARCH = "${MACHINE_ARCH}". Because that will impact MULTIMATCH_TARGET_SYS
<JaMa>
thomas_34: if your recipe or bbappend depends on something MACHINE specific (could be MACHINE as override or something MACHINE_ARCH in DEPENDS/RDEPENDS) then you should use PACKAGE_ARCH = "${MACHINE_ARCH}"
rob_w has quit [Remote host closed the connection]
<thomas_34>
Thank you JaMa for approval!
<RP>
thomas_34: JaMa is right, PACKAGE_ARCH = "${MACHINE_ARCH}" is the usual way to do that
tgamblin has joined #yocto
<Tyaku>
rburton: Yesterday we talk about listing the runtime dependencies, did you know the best approch ? I was thinking about it:
<Tyaku>
1. Open the manifest file in `tmp/deploy/images/MY_IMAGE` directory, parse it and store the package names present in the.
<Tyaku>
2. For each package, call `oe-pkgdata-util read-value RDEPENDS {package_name}` and.. Parse it and append lines in the runtime-deps.dot
<Tyaku>
NOTE: `oe-pkgdata-util read-value RDEPENDS XXX` is not easly parsable.
<Tyaku>
The idea is to build a .dot like "bitbake -g" but for RDEPENDS.
Kubu_work has joined #yocto
olani- has quit [Remote host closed the connection]
<Tyaku>
I also find it:https://docs.yoctoproject.org/dev/dev-manual/build-quality.html#using-build-history-to-gather-image-information-only which can provide installed-package-names.txt and it also provide depends.dot but don't know yet if it's the equivalent of RDEPENDS I'm going to test.
olani- has joined #yocto
jmd has quit [Remote host closed the connection]
Kubu_work1 has joined #yocto
Kubu_work has quit [Ping timeout: 255 seconds]
<Tyaku>
It seems that this dot file contains runtime deps. So it's all good!
<Tyaku>
But the way how it is presented with graphivz is a real pain. "xdot file.dot", display a very large file that cannot be really used as this is so big.
<ablu>
> No, I am not overwriting that.Ah. The question around "MULTIMATCH_TARGET_SYS" made me think you did that somehow...
<landgraf>
RP: Do you remember RDEPENDS/repo issue I was complating about? Same recipe with RDEPENDS:${PN} = "bash" with multiconfig and without produces different spec file. without mc "Requires: bash; Requires(post): bash" and with mc: "BuildRequires: bash" which is wrong :(
<landgraf>
multiconfig sets only TMPDIR
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
mckoan|away is now known as mckoan
MikaelW has joined #yocto
Guest52 has quit [Quit: Client closed]
khem has quit [Quit: Connection closed for inactivity]
<MikaelW>
Hi!
<MikaelW>
As part of the rootfs creation I have added some code that generate a file with some information. What shall I do so that bitbake removes this file when I run a new build or I run clean on the image the rootfs belongs to?
florian has joined #yocto
mvlad has joined #yocto
<rburton>
MikaelW: where is this file written?
<MikaelW>
In the same dir as the image is created.
<MikaelW>
tmp/deploy/images/xxxx/
<rburton>
surely if the code just writes to the same filename then it will replace it anyway
<MikaelW>
It doesn't, it follow the name the image has with timestamps, machine and everything.
<MikaelW>
I did it that way to make sure the information file is fully matched to the image it was created with.
<rburton>
ah so you want the old timestamped name to be purged like the images are too
<MikaelW>
Yes
<rburton>
not sure - have a look in image.bbclass and see if you can spot the logic
<MikaelW>
Ok thanks.
<rburton>
RP: does the image pruning in deploydir (old timestamped image deleted) happen as a side-effect of do_image being sstated? I'm surprised do_image is going through sstate to be honest!
olani has quit [Ping timeout: 256 seconds]
olani has joined #yocto
Michael_Guest has quit [Ping timeout: 250 seconds]
grma has joined #yocto
Michael_Guest has joined #yocto
<RP>
rburton: it is as a result of the sstate tracking code, yes
<RP>
rburton: we don't create/write sstate artefacts for it, just use it for file cleanup
Maxxed has quit [Quit: Ping timeout (120 seconds)]
sukbeom has joined #yocto
sng has joined #yocto
Maxxed has joined #yocto
lexano has joined #yocto
prabhakar has quit [Ping timeout: 240 seconds]
<MikaelW>
rburton: Thanks!!
rm5248 has joined #yocto
<MikaelW>
rburton: That worked very well. So again, thanks!!
<MikaelW>
That has been a thorne in my eye for a long time ...
dgriego has quit [Ping timeout: 255 seconds]
xmn has joined #yocto
dgriego has joined #yocto
<thomas_34>
Is it possible to combine OVERRIDE variables? Like ´variable = "foo"´ but only if o1 AND o2 shows up in OVERRIDE ?
<thomas_34>
variable:o1:o2 = "foo" ? Is there some syntax like that?
<JaMa>
yes
<thomas_34>
JaMa, could you point me to the documentation which explains that? Or could you describe?
<JaMa>
use bitbake -e or bitbake-getvar whenever you don't know
<thomas_34>
Okay... but how does me help that to know which syntax I should use?
<thomas_34>
I have never seen somewhere, that someone combined override variables with some boolean logic
<JaMa>
it's not very common, but there are some cases in oe-core as well, e.g. meta/recipes-devtools/qemu/qemu_8.2.1.bb:EXTRA_OECONF:append:class-target:mipsarcho32 = "${@bb.utils.contains('BBEXTENDCURR', 'multilib', ' --disable-capstone', '', d)}"
<rburton>
thomas_34: but basically what you suggested is exactly what you'd do
<rburton>
Jama means to experiment and see if your syntax works (it does)
<thomas_34>
JaMa, oh okay thank you for that link!
Kubu_work has joined #yocto
<thomas_34>
rburton, Okay - I read this chapter multiple times, but I wasn't sure if my case is possible, because every example just uses a single override. And also to what extend. So what I understand is, that a logical AND is possible. How about a logical OR, etc..
<thomas_34>
Thank you both, AND is just what I need now
<rburton>
feel free to contribute a paragraph talking about this
<rburton>
(please do :)
afong__ has joined #yocto
<thomas_34>
rburton, Can I see somewhere, how exactly this OVERRIDE mechanizm works? So then I can deviate how to achieve that. Is there some python functionality? Or is this behaviour similar to Portage from Gentoo?
<JaMa>
you can read bitbake sources :)
<JaMa>
it's always AND, if you need OR you need to use 2 assignments
<JaMa>
foo:o1 = "a"; foo:o2 = "a"; bar = "${foo}"
<JaMa>
foo = "else"
<thomas_34>
JaMa, yeah, so you dont know if there is a certain "module" or something where the logic behind that is encapsulated?
<thomas_34>
About the OR: Assignment is easy, yes. But appending not so, right? I would like to avoid that "a" got append two times.
<thomas_34>
Yeah, I think to provide some documentation about that, after I dig into that topic :)
amitk_ has joined #yocto
<JaMa>
bar:append = "${foo}" won't append it twice
<thomas_34>
Ahhh, I understand.... using that as "preprocessing"... Cool idea!
<JaMa>
lib/bb/data_smart.py
<thomas_34>
Oh thank you! I'm setting a bookmark on that
sev99 has quit [Quit: Client closed]
amitk_ has quit [Ping timeout: 268 seconds]
thomas_34 has quit [Ping timeout: 250 seconds]
amitk_ has joined #yocto
Xagen has joined #yocto
amitk_ has quit [Ping timeout: 268 seconds]
afong__ has quit [Remote host closed the connection]
afong__ has joined #yocto
Michael_Guest has quit [Ping timeout: 250 seconds]
Dracos-Carazza has quit [Ping timeout: 260 seconds]
enok has quit [Ping timeout: 246 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
florian_kc has joined #yocto
Hazza has joined #yocto
Haxxa has quit [Ping timeout: 268 seconds]
Xagen has joined #yocto
<kanavin>
"Do you sometimes get frustrated at how slow your computer's operating system can be? Now is your chance to prove that you could do a better job!
<kanavin>
Behold the nerdiest game ever, in which YOU are the operating system! As such, you have to manage the computer's processes, memory and input/output events, and try not to get rebooted by an impatient user. Good luck!"
<mario-goulart>
I'd use the same scheduling algorithm used to juggle bug tickets: ASAP-as-possible scheduling.
zeddiii is now known as zeddii
<JaMa>
kanavin: thanks :)
rm5248 has quit [Ping timeout: 272 seconds]
rfs613 has quit [Ping timeout: 264 seconds]
rm5248 has joined #yocto
rfs613 has joined #yocto
ctraven is now known as sotaoverride
rm5248 has quit [Ping timeout: 268 seconds]
rm5248 has joined #yocto
manuel1985 has quit [Ping timeout: 260 seconds]
manuel1985 has joined #yocto
<rm5248>
can having the SSTATE_DIR on a different filesystem than what I'm building on cause pseudo abort errors? I have a problem where my build is failing on the build server but it works fine locally
<JaMa>
rm5248: it shouldn't
<JaMa>
rm5248: is it building always from scratch (empty TMPDIR) or is it incremental build?
<JaMa>
many of pseudo aborts are triggered only in incremental builds which is more likely to accidentally trigger inode conflict
<rm5248>
I delete the TMPDIR every time - I'm using kas to set it all up, so it deletes the build directory(which would delete TMPDIR) every time
<rm5248>
I have tried deleting everything and then re-running the build, but it still failed. I can try that again though
<JaMa>
then check if there is something special about the file which it complains about in pseudo.log
<JaMa>
e.g. I've recently seen many aborts when SRC_URI has something fetched outside ${S} and then the source files are copied to ${PN}-dev from $WORKDIR (but not from ${S} which is excluded from pseudo paths)
<rm5248>
I always get the error on the meta-extsdk-toolchain-dbg_1.0-r0_cortexa5t2hf-vfp.ipk package/file. Since it is not something that I have modified, that makes me somewhat suspicious of the build machine.
dmoseley has joined #yocto
<rm5248>
I think I can try two things: 1. deleting the full sstate_cache dir 2. building without the sstate cache dir(so it is all on one filesystem)