Thursday, 2022-11-24

*** psj <psj!> has joined #yocto00:34
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:43
*** psj <psj!> has quit IRC (Remote host closed the connection)00:52
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)01:03
*** kscherer <kscherer!> has quit IRC (Quit: Konversation terminated!)01:40
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)02:04
*** davidinux <davidinux!~davidinux@> has joined #yocto02:05
*** m4ho <m4ho!> has quit IRC (Ping timeout: 260 seconds)02:15
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto02:16
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)02:16
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:17
*** sakoman <sakoman!> has joined #yocto02:28
*** starblue <starblue!> has quit IRC (Ping timeout: 260 seconds)02:33
*** starblue <starblue!> has joined #yocto02:35
*** m4ho <m4ho!> has joined #yocto02:47
*** ptsneves <ptsneves!> has joined #yocto03:32
*** amitk <amitk!~amit@> has joined #yocto03:35
*** jclsn <jclsn!~jclsn@2a04:4540:652c:e900:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 252 seconds)03:36
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 260 seconds)03:36
*** jclsn <jclsn!~jclsn@2a04:4540:6526:c600:2ce:39ff:fecf:efcd> has joined #yocto03:38
*** xmn <xmn!> has quit IRC (Ping timeout: 260 seconds)03:46
*** m4ho <m4ho!> has quit IRC (Ping timeout: 256 seconds)04:02
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto04:10
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 260 seconds)04:13
*** m4ho <m4ho!> has joined #yocto04:16
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:45
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 268 seconds)05:09
*** nemik <nemik!~nemik@> has joined #yocto05:10
*** Wouter0100 <Wouter0100!> has quit IRC (Quit: The Lounge -
*** Wouter0100 <Wouter0100!> has joined #yocto05:12
*** amitk_ <amitk_!~amit@> has joined #yocto05:48
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:51
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:52
*** tor <tor!~tor@user/tor> has joined #yocto06:18
*** rob_w <rob_w!> has joined #yocto06:21
*** tor <tor!~tor@user/tor> has quit IRC (Quit: Leaving)06:52
*** tor <tor!~tor@user/tor> has joined #yocto06:54
*** tomzy_0 <tomzy_0!> has joined #yocto07:06
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:27
*** manuel <manuel!~manuel198@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has quit IRC (*.net *.split)07:33
*** manuel <manuel!~manuel198@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto07:34
*** risca <risca!> has quit IRC (Ping timeout: 248 seconds)07:36
*** Circuitsoft <Circuitsoft!> has quit IRC (Quit: Connection closed for inactivity)07:39
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 256 seconds)07:41
*** iokill <iokill!> has quit IRC (*.net *.split)07:44
*** ernstp <ernstp!sid168075@2a03:5180:f:4::2:908b> has quit IRC (*.net *.split)07:44
*** georgem <georgem!sid210681@2a03:5180:f::3:36f9> has quit IRC (*.net *.split)07:44
*** KanjiMonster <KanjiMonster!> has quit IRC (*.net *.split)07:44
*** Zappan <Zappan!> has quit IRC (*.net *.split)07:44
*** polprog <polprog!~ath0@user/polprog> has quit IRC (*.net *.split)07:44
*** iokill <iokill!> has joined #yocto07:44
*** georgem <georgem!> has joined #yocto07:45
*** ernstp <ernstp!> has joined #yocto07:45
*** Zappan <Zappan!> has joined #yocto07:45
*** polprog <polprog!~ath0@user/polprog> has joined #yocto07:45
*** KanjiMonster <KanjiMonster!> has joined #yocto07:45
hmw[m]how do i overwrite the default do configure?07:49
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto07:52
*** mvlad <mvlad!~mvlad@2a02:2f08:4503:c400:24d7:51ff:fed6:906d> has joined #yocto08:08
*** zpfvo <zpfvo!> has joined #yocto08:12
*** gho <gho!> has joined #yocto08:17
*** payam <payam!> has quit IRC (Remote host closed the connection)08:23
*** vladest <vladest!> has joined #yocto08:23
*** derRichard <derRichard!> has joined #yocto08:30
derRichardis there a reason why this fix is not in dunfell yet?
tomzy_0is there someone who successfully compiled xorg-xserver 21.1.3 provided since kirkstone?08:39
*** d-fens <d-fens!~d-fens@> has joined #yocto08:40
jclsnHow can I get the return value from a bash function in a Bitbake script. I tried automatically setting PARALLEL_MAKE = "-j ${nproc}", but that throws an error08:59
*** kiwi_29_[m] <kiwi_29_[m]!~msgboardp@2001:470:69fc:105::1:6699> has quit IRC (Quit: You have been kicked for being idle)09:00
LetoThe2ndyo dudX09:00
*** kiwi_29_[m] <kiwi_29_[m]!~msgboardp@2001:470:69fc:105::1:6699> has joined #yocto09:00
*** kiwi_29_[m] <kiwi_29_[m]!~msgboardp@2001:470:69fc:105::1:6699> has left #yocto09:00
jclsnIt seems you can't define Bitbake functions in local.conf either09:02
*** florian <florian!> has joined #yocto09:14
LetoThe2ndjclsn: yeah AFAIK functions cannot go into .conf files?09:15
jclsnLetoThe2nd: Pity, so only fixed values are possible for PARALLEL_MAKE09:17
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 268 seconds)09:19
jclsnWell, I guess the default is nproc, so I could just work with that and divide it by two or something09:19
LetoThe2ndjclsn: well you can always override those in a specific recipe or class09:21
jclsnLetoThe2nd: I want to globally override them though. I want to see if keeping the load average lower will improve performance. So something like PARALLEL_MAKE = "${PARALLEL_MAKE}/${BB_NUMBER_THREADS}"09:23
jclsnPer recipe doesn't make sense09:23
*** d-fens <d-fens!~d-fens@> has quit IRC (Quit: Client closed)09:23
LetoThe2ndjclsn: well globally should not be that much of a problem. just look at how they are assigned in the first place and then patch/modify09:25
jclsnBut you can't do arithmetic calculations inside the variables09:26
jclsnTypisation would come in handy here09:27
jclsnAh well I guess I will just leave it09:28
qschulzjclsn: you could set the variable in the local environment and use the environment variable in your local.conf09:28
qschulzotherwise, it supports in-line python09:29
qschulzso something like PARALLEL_MAKE = "${@os.cpucount()}" ?09:30
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Ping timeout: 260 seconds)09:32
*** zpfvo <zpfvo!> has joined #yocto09:33
jclsnqschulz: cpucount is in multiprocessing. How can I do an import statement before that?09:36
jclsnI tried "${@import multiprocessi}${@multiprocessing.cpucount()}09:36
jclsnah os.cpu_count() works it seems09:38
*** mckoan|away <mckoan|away!> has joined #yocto09:40
jclsnAh but now I have PARALLEL_MAKE="24/2" ^^09:40
qschulzjclsn: why?09:42
qschulzdo PARALLEL_MAKE = "${@os.cpucount() / 2}"09:42
qschulzand I think you need -j in front?09:42
qschulzso PARALLEL_MAKE = "-j ${@os.cpucount() / 2}" ?09:42
jclsnIf I put "${@os.cpu_count/${BB_NUMBER_THREADS}}" I get 12.009:42
jclsnAh yes09:42
jclsnLet met try09:42
qschulzjclsn: then //09:42
qschulzthat's just python09:42
mcfriskwhat about enabling kernel module signing by default in poky master branch? maybe via config snippet and PACKAGECONFIG. it's not the default in x86_64 in upstream but I think it should be. and it would show the stripping failure earlier too (still investigating, disabling stripping fixes this)09:43
jclsnYeah but make don't take floats bra09:43
qschulzjclsn: hence the //09:43
jclsnBut it's not maxing out the core now ^^09:46
jclsnGuess going with the default is the best09:46
qschulzjclsn: what are you trying to do09:47
jclsnqschulz: Our devops guy was complaining that our load average is too high. So like 4 times the number of physical core. He said to optimize efficiency I should adjust those settings properly09:48
jclsnBitbake seems to have a lot of processes waiting for IO09:48
LetoThe2ndwhy is that a problem?09:48
jclsnBecause our Devops guy is a nerd09:48
jclsnHe said we would waste performance09:49
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Read error: Connection reset by peer)09:49
LetoThe2ndthe build will eventually finish, why does $DEVOPS guy have to tell you how to run the builc? if it affects other stuff, he shall give you a quota. rest is not of his concern, IMHO09:49
jclsnActually the kernel should handle all of these things imo09:49
*** OnkelUlla <OnkelUlla!> has quit IRC (Read error: Connection reset by peer)09:49
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 264 seconds)09:49
qschulzthe only worry you should have is not running out of memory09:50
qschulzI remember reading somewhere that anything above 20 threads isn't going to help anyway so you can limit it to that09:51
LetoThe2ndqschulz: yup. give or take a few, but somewhere above 24-32 you're not gaining anything anymore.09:51
jclsnLetoThe2nd: Yeah true, as long as we don't have problems why fix it. I am just curious to make a few experiments too. I didn't even know what the load everage meant before that. So at least I learnt something09:52
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto09:58
Saur[m]jclsn: If you are using Kirkstone or later, you might want to look inte to the new BB_PRESSURE_* variables too.10:01
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 248 seconds)10:04
jclsnSaur[m]: I wouldn't know how to find the right pressure values10:05
jclsnAh will just let it be for now. It is not so important really10:07
jclsnThanks for showing me those variables though. Maybe in the future I will make use of them10:08
*** mckoan|away <mckoan|away!> has joined #yocto10:12
*** mckoan|away is now known as mckoan10:13
*** d-fens <d-fens!~d-fens@> has joined #yocto10:30
jclsnIf BB_SRCREV_POLICY = "cache" will that not break AUTOREV?10:30
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 268 seconds)10:31
jclsnIf it doesn't check the repo every time it builds, it can't be up-to-date really10:31
*** OnkelUlla <OnkelUlla!> has joined #yocto10:33
jclsnSeems like it does unfortunately10:42
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 248 seconds)10:49
RPjclsn: devops people don't always think about builds in the right way. bitbake tends to queue up everything it can, it then leaves it to the kernel to work out what it can do with the resources available. The kernel tends to be much better at that than userspace can be10:50
d-fenshi, fetching some python deps on kirkstone i was looking for  bitbake -s | grep ^python3-git which resulted in 3.1.27-r0 and then tried and was given but the latest version is 3.1.29  (not 27) - question: why10:53
d-fensdon't i see the 29 file that does live in while 27 doesn't xist ? is the layerindex not updated regularly and what am i doing wrong?10:53
LetoThe2ndd-fens: let`s say the layerindex is not exactly well maintained at the moment.10:54
*** gsalazar <gsalazar!> has joined #yocto10:54
*** Saur <Saur!> has quit IRC (Ping timeout: 260 seconds)11:00
*** Wouter0100 <Wouter0100!> has quit IRC (Quit: The Lounge -
*** Wouter0100 <Wouter0100!> has joined #yocto11:02
JaMajclsn: you can see some benchmarks in
*** starblue <starblue!> has quit IRC (Ping timeout: 260 seconds)11:06
*** Notgnoshi <Notgnoshi!> has quit IRC (Ping timeout: 255 seconds)11:07
*** starblue <starblue!> has joined #yocto11:08
d-fensLetoThe2nd i see, so the poky layer is my oe-core layer, where only .27 exists for kirkstone; how should i handle the .29 requirement while staying on kirkstone?11:10
d-fenscopy the to my distro layer?11:11
*** Saur <Saur!> has joined #yocto11:14
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 265 seconds)11:15
mcfrisklinux-yocto in poky has some neat config stuff, but sadly I haven't seen any BSP layer using it...11:16
LetoThe2ndd-fens: rather the application layer, but basically yes.11:16
*** gsalazar <gsalazar!> has joined #yocto11:21
jclsnRP: Yeah I also think that thinking that you are able to handle things better than the kernel is a bit presumptuous11:26
rburtonmcfrisk: meta-arm does for some BSPs11:27
mcfriskrburton: cool, sadly vendor kernels weren't using them..11:29
RPjclsn: I've tried before in bitbake and usually we just made performance worse11:31
jclsnSame for me11:31
RPIt is a balance, which is why we have PARALLEL_MAKE and BB_NUMBER_THREADS but anything finer grained doesn't usually help11:31
*** d-fens <d-fens!~d-fens@> has quit IRC (Ping timeout: 260 seconds)11:32
jclsnRP: I am just looking at this bug which was caused by one of your patches11:32
RPjclsn: right, I fixed several problems and caused some others :(11:33
jclsnI tried to workaround by using BB_SRCREV_POLICY = "cache", but that breaks AUTOREV it seems11:33
jclsnRP: Happens to the best of us ;)11:33
jclsnWell, I guess you have no idea how to fix it or did you just have no time to look at it?11:34
jclsnI am trying to understand the code11:34
RPjclsn: I haven't had the time to dig in and understand what is going wrong11:34
jclsnNo worries. I will use fixed SRCREV for now11:35
jclsnMaybe I will have a look at it myself11:35
RPhelp in fixing it would be very welcome, I just don't have the bandwidth to do it :(11:36
Saur[m]jclsn: If you use BB_SRCREV_POLICY = "cache", which we do, then as you have noticed, you can not use ${AUTOREV, which means that devtool not supporting ${AUTOREV} is no longer a problem. ;)11:36
*** d-fens <d-fens!~d-fens@> has joined #yocto11:37
mcfriskfor CPU usage kernel is good, same for virtual memory/RAM, but for IO, things are different. By default, background writing of things tmp will happen way too fast. Tuning of VM parameters is needed to keep things in RAM so that rm_work can remove them before flush to disk happens..11:37
mcfriskbuilding on full tmpfs is nice but it's rare to have so much RAM available for full build/tmp11:38
* RP really doesn't like rm_work :(11:38
jclsnSaur[m]: Great workaround :D11:39
jclsnI got used to AUTOREV though. So convenient11:39
RPSaur[m]: can't you manually clear the cache with BB_SRCREV_POLICY = "cache" to trigger autorev?11:39
mcfriskRP: any non-trivial build env must use rm_work, otherwise tmp/work* will be too big11:39
RPmcfrisk: thanks, clearly I only ever do trivial stuff11:40
mcfriskI only had 3 Tb disks/nvme/ssd's on the big machines, that was enoug for 3-4 project builds with download and sstate caches shared. A single build with rm_work was easily 150 Gb on disk. Can't even imagine how big those would have been without rm_work...11:42
* RP notes the autobuilders are also trivial11:43
mcfriskonly core-image-minimal? without systemd?11:44
RPwhat worries me about rm_work is that it was hacked on top of everything, not designed in properly and is extremely fragile. It integrates with the task graph particularly poorly and has a poor story around debugging failures.11:44
RPDespite it being used heavily, nobody actually cares about fixing any of that, just patching it to make it mostly work11:44
mcfriskfor me it works, can't remember ever having problems with it11:44
RPmcfrisk: you don't get the bug reports when it breaks :(11:45
mcfrisktrue, sorry about that11:46
RPmcfrisk: trying to change other parts of the system to improve them whilst ensuring it keeps working is also frustrating given everything else11:46
qschulzmcfrisk: I remove everything between CI builds except sstate cache and dl dir, no need for rm_work in that scenrario?11:46
mcfriskbut it does help a lot to keep the amount of IO lower during builds and to keep fs buffers in RAM11:47
qschulz(though yes, I only build very small images)11:47
RPanyway, like I said, I just personally really don't like it. I know people use it and why which is why it does continue to exist11:47
mcfriskqschulz: check how much writes your build does..11:47
mcfriski used pcp to monitor CPU, RAM, IO read/write bytes, network bytes11:47
RPqschulz: you might see some speed up if rm_work can trigger before the data makes it out the cache and onto disk11:48
RPif your build isn't io bound, it won't actually matter11:48
mcfriskthere I could see the effect of Linux vm background writes going to real IO, and once disabled running low on fs buffers on RAM also triggering useless writes which rm_work helped to get rid of11:48
mcfriskit's a good idea to monitor full cache rebuilds to see how developers broke download and sstate caching: nothing should download anything from network if caches full, nothing should get recompiled if sstate cache uptodate and no changes...11:50
qschulzRP: mcfrisk: thanks, will try to remember this the day we need to go for bigger builds (maybe never? only BSP products on Yocto right now)11:50
mcfrisksome of the breakage I saw came from BSPs...11:50
qschulzmcfrisk: I don't get your last sentence11:51
mcfriskRP: +KERNEL_FEATURES:append = " features/module-signing/force-signing.scc" in meta/recipes-kernel/linux/ results in runtime failure "Loading of unsigned module is rejected" on yocto master.. kernel modules are getting stripped of signing data11:52
mcfriskqschulz: I saw BSP layers breaking download and sstate caching11:52
qschulzmcfrisk: ah yes, a layer is a layer, people can do many kind of crazy things in there :)11:54
qschulzwhat I meant is as a BSP vendor, I have very little to build right now to test my layer/boards, so no use yet for rm_work11:54
mcfriskyea, that's good for you, but checking that download and sstate caching isn't broken is a good idea. For downoad caching, debuild without network access with full download cache11:56
mcfriskfor sstate cache test, rebuild with full cache and check that no do_compile tasks got executed11:57
RPmcfrisk: I'm not surprised, I thought there was an open bug around this11:59
mcfriskwould be nice to device a test for this, it's so easy for various layers and recipes and developers to accidently break things12:00
*** amitk_ <amitk_!~amit@> has joined #yocto12:03
*** davidinux <davidinux!> has joined #yocto12:04
*** manuel1985 <manuel1985!> has joined #yocto12:09
RPmcfrisk: The maze of kernel options does need more tests, one would be very welcome12:10
*** alessioigor <alessioigor!~alessioig@> has joined #yocto12:11
RPmcfrisk: we are slowly improving as we notice cases like this, document and add tests12:11
*** payam <payam!> has joined #yocto12:21
*** xmn <xmn!> has joined #yocto12:37
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)12:55
*** alessioigor <alessioigor!~alessioig@> has joined #yocto12:56
*** mckoan <mckoan!> has quit IRC (Ping timeout: 264 seconds)12:56
*** manuel1985 <manuel1985!> has quit IRC (Ping timeout: 264 seconds)13:08
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 265 seconds)13:10
ldericherhow do I define a multiline string in a bitbake recipe?13:12
rburtonbackslash-escape the newline13:12
ldericherSo I want a string like BAZ = "foo\nbar" with a literal newline in between. Can I `BAZ = \[NL]"foo\[NL]bar"` where [NL] is a newline in my bbfile?13:18
*** payam <payam!> has quit IRC (Remote host closed the connection)13:18
rburtonoh you want a literal newline? i guess \\n might do it13:20
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)13:21
*** alessioigor <alessioigor!~alessioig@> has joined #yocto13:21
ldericherrburton, well I think so … maybe it'd be clearer to use an array of lines though. Possible?13:22
rburtonbitbake variables are strings13:24
ldericherso finally, I'm writing a ROOTFS_POSTPROCESS_COMMAND in my image recipe that generates an /etc/issue file for me.13:25
ldericherin there, I want (multiline) ASCII art, exposed as a bitbake var13:25
*** goliath <goliath!~goliath@user/goliath> has joined #yocto13:25
rburtonis it literally just copying the file from the var to the rootfs?13:26
rburtonor do you process it in some way13:26
ldericherit is processed - "issue" needs escaped backslashes13:27
ldericheralso I want to add some stuff like distro name13:27
rburtonif thats all your doing just create a bbappend for base-files and put an issue file alongside13:27
rburtonbase-files will install it for you13:28
rburtonwell its a bit more complex than that for this specific file, but a postprocess hook is overcomplicating things13:28
ldericherrburton, well yes but actually no, I need it to pull in the correct ASCII art for the image that's to be built.13:29
rburtonso there is processing: you have per-image artwork13:29
rburtoni'd still write a recipe that emits lots of packages for each of your images13:30
rburtoneasier to write the ascii art in a text editor instead of faffing with it being in a variable13:30
ldericherI'm really rusty tbh, can you help with the "emit lots of packages" part?13:31
rburtonsomething like write a recipe which installs /etc/issue.(name) files for each of your image types and then symlink the right one to /etc/issue13:32
*** manuel1985 <manuel1985!> has joined #yocto13:33
*** xmn <xmn!> has quit IRC (Ping timeout: 264 seconds)13:36
ldericheroooh that's clever!13:36
*** davidinux <davidinux!> has quit IRC (Quit: WeeChat 3.5)13:37
*** xmn <xmn!> has joined #yocto13:38
rburtonif you're feeling really clever, use alternatives to provide /etc/issue and then you just install the right issue-foo package and the symlink is made for you13:39
*** rob_w <rob_w!> has quit IRC (Ping timeout: 260 seconds)13:43
*** manuel1985 <manuel1985!> has quit IRC (Ping timeout: 268 seconds)13:47
*** manuel1985 <manuel1985!> has joined #yocto13:48
*** sakoman <sakoman!> has joined #yocto13:53
*** rob_w <rob_w!> has joined #yocto13:55
ldericherwhen the image is built, where can I find the resulting sysroot, again?13:58
*** davidinux <davidinux!~davidinux@> has joined #yocto14:08
*** d-fens <d-fens!~d-fens@> has quit IRC (Ping timeout: 260 seconds)14:13
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Read error: Connection reset by peer)14:17
OnkelUllaotavio: Hi Otavio! Is there a chance that you perhaps could have a look at ("[meta-java][PATCH] layer.conf: Mark as compatible with langdale")?14:20
OnkelUllaI sent it together with ("[meta-java][PATCH] openjdk-8: refresh patches") some weeks ago and did not get any feedback up to now.14:20
*** Net147 <Net147!> has joined #yocto14:20
*** d-fens <d-fens!~d-fens@> has joined #yocto14:39
*** manuel1985 <manuel1985!> has quit IRC (Remote host closed the connection)14:50
*** mckoan <mckoan!> has joined #yocto14:50
*** florian_kc <florian_kc!> has joined #yocto14:53
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 265 seconds)15:01
*** risca <risca!> has joined #yocto15:14
*** zpfvo <zpfvo!> has joined #yocto15:15
*** rob_w <rob_w!> has quit IRC (Ping timeout: 260 seconds)15:15
d-fensit seems to be a stupid idea to delete the contents o build\tmp-glibc\deploy\images ... how can i trigger a rebuild of bootfiles and dtb's ?15:22
qschulzd-fens: remove everything in your build/tmp-glibc and rebuild it's the easiest15:23
qschulzotherwise I know rburton has some bitbake magic command somewhere up his sleeve15:24
ldericherROOTFS_POSTPROCESS_COMMAND must be in an image recipe?15:24
*** Notgnoshi <Notgnoshi!> has joined #yocto15:25
*** rob_w <rob_w!> has joined #yocto15:27
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)15:27
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto15:29
vvnldericher: yes. If you want to share some code between image recipes, write a foo.bbclass, add your ROOTFS_POSTPROCESS_COMMAND += "foo;" in there with a foo () { } function and make your images inherit foo15:32
vvnqschulz: btw do you need to remove TOPDIR as well or remove TMPDIR is enough to trigger a "fresh" build?15:34
vvnin other words, is the content of TOPDIR (except TMPDIR) reusable/sharable?15:34
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)15:43
*** nemik <nemik!> has joined #yocto15:44
*** mthenault <mthenault!> has joined #yocto15:46
*** nemik <nemik!> has quit IRC (Ping timeout: 265 seconds)15:48
*** nemik <nemik!~nemik@> has joined #yocto15:48
rburtond-fens: just delete tmp15:54
rburtonvvn: the cache/ is not relocatable15:55
rburtonsstate and downloads are15:55
d-fensrburton did that and it worked, it's actually tmp-glibc , no idea why the output path changed from tmp a few days ago15:57
rburtontmp/ is a pokyism15:59
rburtondefault is tmp-(libc name) for... reasons15:59
*** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has quit IRC (Quit: You have been kicked for being idle)16:00
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)16:00
*** mkorpershoek <mkorpershoek!> has left #yocto16:08
vvnrburton: this means that TOPDIR is specific to the build machine, but you can reuse it for other fresh builds as long as you don't move it to another location, am I correct?16:11
rburtonvvn: well, you can always share sstate and downloads.  tmp and cache just wipe and they'll regenerate. so then all that is left is conf.16:14
vvnand bitbake.lock and bitbake.sock (as well as a daemon log)16:15
rburtonthe former are specific to a running bitbake and will be deleted once it quits16:15
vvnI should've said the content of TOPDIR, except TMPDIR, DL_DIR and SSTATE_DIR16:15
*** d-fens <d-fens!~d-fens@> has quit IRC (Ping timeout: 260 seconds)16:16
vvnrburton: bitbake.conf says that PERSISTENT_DIR (${TOPDIR}/cache) "should be shared by all builds"16:20
otavioOnkelUlla: I can look, for sure. Can you send an email so I don't forget?
vvnSo one only needs to wipe TMPDIR for a fresh build I guess, no need to wip cache16:20
rburtonvvn: we talked about that earlier in the week here.  the bitbake parser cache goes into tmp/cache explicitly, and that very much shouldn't be shared16:20
rburtonRP: i say bitbake's caches should go into tmp/cache not topdir/cache16:21
*** tor <tor!~tor@user/tor> has quit IRC (Remote host closed the connection)16:22
JaMarburton: PRSERV is in PERSISTNT_DIR, right? so that needs to stay in topdir like hashserve16:25
rburtoni should be able to put persistant_dir alongside my shared sstate and downloads, right? the parser cache being in there means i can't do that.16:26
OnkelUllaotavio: Thanks, I'll resend them! You've been on CC, but perhaps the address found in meta-java's README (Otavio Salvador <>) is not in active use anymore.16:27
otavioit is the same; just resend.16:27
RPrburton: depends which cache you mean16:28
RPrburton: that is from codeparser rather than recipe parsing. If you had two TMPDIRs, you could share the code parser between them16:30
JaMaRP: was this a NAK? or should I send v2 accepting only '1' as value?16:31
rburtonRP: so it could sit in a central location alongside a shared sstate and different builds of different branches wouldn't argue over it?16:31
RPJaMa: Oddly enough I was staring a the export and unexport flags today with the same issue and was thinking about the network flag16:31
RPJaMa: we should probably put a bb.utils.to_boolean() around it (and merge the local patch I have to make bb.utils.to_boolean() handle int values16:32
JaMait's a bit unfortunate that inheritting icecc.bbclass now enables network everywhere16:32
RPrburton: depends what central location means. It isn't as sharable as sstate/dl_dir but does offer a speed up to builds and is about as safe as the the bb persist data there16:33
RPJaMa: yes :(16:33
JaMaok, I'll resend it with bb.utils.to_boolean once the local patch is merged, I didn't want to add more than bare-minimum processing as you said earlier that this is in hot path16:34
RPJaMa: I'm worried that should we change the network flag, the export/unexport flags work differently16:34
RPJaMa: If I change export/unexport to match we take a 4% parsing speed hit16:34
RPperhaps I should just stop caring16:35
RPrburton: codeparser basically says "python fragment X has dependencies on functions Y and variables Z"16:36
RPrburton:  it is versioned and the version could change depending on the version of bitbake16:36
RPrburton: it isn't as simple as "this is sharable"16:36
*** mthenault <mthenault!> has quit IRC (Ping timeout: 265 seconds)16:37
JaMaFWIW: in rare cases I've seen codeparser cache getting corrupted when bitbake was killed in some unfortunate moment16:37
*** amitk_ <amitk_!~amit@> has joined #yocto16:39
RPJaMa: I'm not entirely surprised since each parser thread writes out a copy of it's cache and then a thread merges them all together in the background16:39
RPJaMa: in theory it should just throw it all away in case of problems and start again16:39
JaMaI think in some rare cases it didn't throw it automatically and I had to delete it, but never found any reproducer and it was very rare (and possibly fixed since then)16:42
*** kscherer <kscherer!> has joined #yocto16:42
*** olani <olani!~olani@> has joined #yocto16:45
JPEWRP: I had an epiphany about how to efficiently transfer the strings, but won't be able to do anything to implement it until next week16:54
*** BrziCo <BrziCo!~BrziCo@> has joined #yocto16:55
RPJaMa: if you have a broken file sometime I'd be interested to see what it looks like and the error bitbake gives16:57
RPJPEW: any hints on what you're thinking or you're going to keep me in suspense?16:58
* RP suspects he will be getting told off by the conference organisers for distracting JPEW soon16:58
BrziCoHello everyone,17:03
BrziCoI'm currently learning about Yocto project, and I'm trying to create Linux image for Raspberry Pi 3. I cloned the BSP layer ( and I added desired variables in local.conf (e.g. ENABLE_UART = "1" ... ) and it works just fine. Now, I'm trying to move those variables away from local.conf to my own layer, so i17:03
BrziCocreated my machine (raspberrypi3-my.conf) that just contains this line include conf/machine/raspberrypi3.conf but when I run bitbake i get error saying: "Could not locate BSP definition for raspberrypi3-my/standard and no defconfig was provided". Any help? Thanks :D17:03
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:07
RPBrziCo: the MACHINE value is probably being used as an OVERRIDE in places. MACHINEOVERRIDES =. "raspberrypi3:" might help17:07
JaMaRP: haven't found any in my current TOPDIRs, if I see it again I'll save it (but not doing so many build nowadays, so probability to hit it again is even lower)17:07
rburtonBrziCo: it might be better to create a new distro that uses the rpi machine, instead of a whole new machine17:08
RPJaMa: fair enough. Just mentioning what we'd need to try and improve things in case you do run into it :)17:08
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)17:09
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)17:11
*** gho <gho!> has quit IRC (Quit: Leaving.)17:12
*** zpfvo <zpfvo!> has quit IRC (Quit: Leaving.)17:13
JPEWRP: getstate returns 2-tuple, first is the list of tuples ((os.getpid() len(cache)), "new string" or frozenset), for every new object added to the cache, the second is the actual dictionary, where the values are replaced with the (os.getpid(), len(cache)) tuple.17:16
JPEWsetstate populates the cache with all the new objects seen, then restores the dicts by replacing the tuples via lookup in the cache17:17
JPEWIt could even dedup efficiently across multiple worker process17:18
JPEWAnd neatly, it's all wrapped up in the getstate, setstate, so nothing else needs to know it's happening17:19
*** xmn <xmn!> has quit IRC (Ping timeout: 265 seconds)17:20
JPEWAnyway, the main idea is that the list of new objects makes sure each is only sent once the first time it's seen without needing special cases in the actual value dictionaries17:21
RPJPEW: right, that makes sense. It was along the lines I was thinking but I was just doing to hack the state dictonary :)17:25
*** mckoan is now known as mckoan|away17:26
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 264 seconds)17:36
*** Wouter0100 <Wouter0100!> has quit IRC (Quit: The Lounge -
*** Wouter0100 <Wouter0100!> has joined #yocto17:47
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto17:59
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)18:01
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:01
RPdo we need to move to #quecto?18:01
JaMalets discuss trivial builds in #quecto and non-trivial in #quetta to make things simpler :)18:03
* JaMa just run out of 2+2TB nvme again18:05
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)18:09
*** nemik <nemik!~nemik@> has joined #yocto18:10
*** alessioigor <alessioigor!~alessioig@> has joined #yocto18:13
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Remote host closed the connection)18:13
BrziCoRP thanks MACHINEOVERRIDES = "raspberrypi3:${MACHINE}" helped18:20
*** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto18:36
*** BrziCo <BrziCo!~BrziCo@> has quit IRC (Quit: Client closed)18:43
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto18:58
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 248 seconds)19:00
*** florian_kc <florian_kc!> has joined #yocto19:12
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 260 seconds)19:14
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)19:26
*** invalidopcode <invalidopcode!> has joined #yocto19:28
*** qschulz <qschulz!> has joined #yocto19:29
*** gsalazar_ <gsalazar_!> has joined #yocto19:36
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 264 seconds)19:38
*** amitk_ <amitk_!~amit@> has quit IRC (Remote host closed the connection)19:38
*** prabhakarlad <prabhakarlad!> has joined #yocto19:46
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 268 seconds)20:19
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)20:32
*** gsalazar_ <gsalazar_!> has quit IRC (Ping timeout: 265 seconds)20:37
*** Tamis <Tamis!> has joined #yocto20:40
*** gsalazar_ <gsalazar_!> has joined #yocto20:52
*** Tamis17 <Tamis17!> has joined #yocto21:01
*** Tamis <Tamis!> has quit IRC (Ping timeout: 260 seconds)21:02
*** gsalazar_ <gsalazar_!> has quit IRC (Remote host closed the connection)21:14
*** gsalazar_ <gsalazar_!> has joined #yocto21:15
*** jlf` <jlf`!~jlf`@user/jlf> has joined #yocto21:24
*** Wouter0100 <Wouter0100!> has quit IRC (Quit: The Lounge -
*** Wouter0100 <Wouter0100!> has joined #yocto21:42
*** mvlad <mvlad!~mvlad@2a02:2f08:4503:c400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:46
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)21:54
*** Tamis17 <Tamis17!> has quit IRC (Ping timeout: 260 seconds)21:55
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:59
*** gsalazar_ <gsalazar_!> has quit IRC (Remote host closed the connection)22:00
*** gsalazar_ <gsalazar_!> has joined #yocto22:00
*** florian_kc <florian_kc!> has joined #yocto22:10
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto22:11
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 260 seconds)22:12
*** olani <olani!~olani@> has quit IRC (Ping timeout: 260 seconds)22:26
*** gsalazar_ <gsalazar_!> has quit IRC (Ping timeout: 265 seconds)22:29

Generated by 2.17.2 by Marius Gedminas - find it at!