Friday, 2021-07-30

*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:09
*** nucatus <nucatus!> has joined #yocto00:53
*** camus <camus!~Instantbi@> has joined #yocto00:55
*** nucatus <nucatus!> has quit IRC (Ping timeout: 245 seconds)00:58
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 245 seconds)01:18
*** otavio <otavio!> has quit IRC (Remote host closed the connection)01:22
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)01:24
*** nucatus <nucatus!> has joined #yocto01:26
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)01:30
*** rber|res <rber|res!~rber|> has joined #yocto01:32
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Ping timeout: 265 seconds)01:34
*** camus <camus!~Instantbi@> has joined #yocto01:54
*** nucatus <nucatus!> has joined #yocto01:55
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)01:57
*** camus <camus!~Instantbi@> has joined #yocto01:57
*** nucatus <nucatus!> has quit IRC (Ping timeout: 276 seconds)02:00
*** camus1 <camus1!~Instantbi@> has joined #yocto02:03
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 258 seconds)02:04
*** camus1 is now known as camus02:04
*** alex88 <alex88!> has quit IRC (Read error: Connection reset by peer)02:10
*** alex88 <alex88!> has joined #yocto02:11
*** vmeson <vmeson!> has quit IRC (Ping timeout: 268 seconds)02:24
*** vmeson <vmeson!> has joined #yocto02:39
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:44
*** camus1 <camus1!~Instantbi@> has joined #yocto02:52
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)02:54
*** camus1 is now known as camus02:54
*** nucatus <nucatus!> has joined #yocto02:57
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)03:02
*** nucatus <nucatus!> has joined #yocto03:29
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)03:35
*** paulg <paulg!> has quit IRC (Ping timeout: 276 seconds)03:45
*** camus <camus!~Instantbi@> has joined #yocto04:16
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 258 seconds)04:22
alicefany way to add commands to yocto git command ? something like BB_GIT_CMD = "depth=1"04:24
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)04:26
*** nucatus <nucatus!> has joined #yocto04:26
*** bluelightning <bluelightning!~paul@2406:e003:1385:8501:ad77:7a5:e243:41b9> has quit IRC (Ping timeout: 240 seconds)04:55
*** camus <camus!~Instantbi@> has joined #yocto05:01
*** roussinm <roussinm!> has quit IRC (Quit: WeeChat 3.3-dev)05:11
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)05:40
*** mihai <mihai!~mihai@user/mihai> has left #yocto05:55
*** mihai <mihai!~mihai@user/mihai> has joined #yocto05:56
michaelo[m]I'm on Matrix and receiving some of these messages in bursts.05:59
michaelo[m]The synchronization with looks broken05:59
*** rostam98[m] <rostam98[m]!~rostam98m@2001:470:69fc:105::ca0e> has joined #yocto05:59
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)06:11
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)06:17
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 265 seconds)06:18
*** camus <camus!~Instantbi@> has joined #yocto06:34
*** mckoan|away is now known as mckoan06:38
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:40
*** nucatus <nucatus!> has joined #yocto06:41
mckoanalicef: see BB_GIT_SHALLOW_DEPTH in bitbake/lib/bb/fetch2/git.py06:42
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 258 seconds)06:42
*** camus <camus!~Instantbi@> has joined #yocto06:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)06:57
*** prabhakarlad <prabhakarlad!> has joined #yocto07:10
*** nucatus <nucatus!> has joined #yocto07:10
*** vd <vd!> has quit IRC (Ping timeout: 246 seconds)07:20
*** rosa <rosa!> has joined #yocto07:27
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)07:32
*** nucatus <nucatus!> has joined #yocto07:41
*** camus1 <camus1!~Instantbi@> has joined #yocto07:56
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)07:57
*** camus1 is now known as camus07:57
qschulzoverride: don't reinvent the wheel and take upgrade mechanisms that already exist (mender, rauc, swupdate, you namne it)08:07
qschulzmost of them support A/B mechanism I think08:07
qschulzwhich have their own specific way of booting rootfs A or B (kernel A and B too I guess)08:07
*** florian <florian!> has joined #yocto08:08
qschulzyou'll need to implement the U-Boot logic I guess but I sure hope it's appropriately documented :)08:08
qschulzmichaelo[m]: It's very hard for me to restrain myself from trolling on matrix :)08:10
michaeloqschulz: funny, then IRC moderates you :)08:12
qschulzmichaelo: It was more about trolling on Matrix piece of SW :)08:14
qschulzI didn't have a good experience with it but people keep telling me everything works perfectly fine :)08:15
*** LetoThe2nd <LetoThe2nd!> has joined #yocto08:18
LetoThe2ndyo dudX08:18
wyrehi guys, I'm trying of flashing an ubifs image in NAND and apparently the flshing process looks good but then kernel doesn't load this is my environment, as you can see I had to create a new bootzcmd_ubi variable because the existent one uses bootm instead bootz08:20
wyreI'd say all is correct, but it doesn't boot 😞08:21
*** alinucs <alinucs!> has joined #yocto08:22
qschulzwyre: why are you TFTP loading the ubifs file?08:23
wyreqschulz, well, according the documentation page 10 ... the rootfs can be flashed from the tftp08:24
wyrein fact, I've taken the script that does this from the manufacturer repo
qschulzwyre: ubi0: empty MTD device detected08:26
wyreqschulz, so the process is not finishing successfully?08:27
qschulzand you didn't give us the bootlog so can't help08:27
wyrewhere can I find the bootlog?08:27
wyreoh, you mean this part?
wyreas I've said ... it's stuck in there08:28
qschulzand what's the content of this bootzcmd_ubi? this is VERY likely an issue with either the device tree being corrupted or not correctly loaded, or incorrect (or missing) bootargs variable08:31
qschulznothing to do with ubi (yet)08:31
wyreqschulz, you can see the contents in the link I pasted with the environment
wyreI've basically copied the bootcmd_ubi which is using bootm but replacing this with bootz08:34
wyrebecause the built image is a zImage08:35
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:35
qschulzcheck that you have enough space for the zImage in the area reserved for it in your NAND, same for dtb. Make sure when loading into RAM with nand read that one is not overwritting the other.08:38
qschulzBut that's probably more a question for #u-boot08:39
wyreI see, thank you anyway ...08:40
jsandmanHi there, I'm trying to generate an extensible sdk for my image with Yocto 3.1.1. I get this weird error that I don't know how to solve " failed with exit code 'setscene whitelist' " Does this sound faimiliar to someone here?08:46
LetoThe2ndjsandman: does this happen with a raw dunfell poky?08:54
michaelowyre: wow, your nand read for the DTB is pessimistic, 1 MB for the DTB, while 100 KB (or even 64 KB) are probably enough!08:56
jsandmanI have not tried to generate an sdk for that. I shall try that yeah08:56
michaelowyre: did you try to boot your kernel and DTB by loading them to the same addresses through tftp? This could rule out an issue in the way you flashed.08:57
michaelowyre: I also agree with the advice from qschulz08:58
wyremichaelo, I've used the script that manufacturer provides in their repository (layer)
LetoThe2ndjsandman: please do so, yes. to trim down the possible sources.08:59
michaelowyre: Thanks for the details, but I'm proposing to figure out whether the kernel works or not... Try "tftp 0x82000000 zImage; tftp 0x83000000 imx6ull-microgea-microdev.dtb; bootz 0x82000000 - 0x83000000"09:04
qschulzmichaelo: you probably want the load addresses swapped though09:05
wyremichaelo, thank you very much 😁09:05
qschulzDTB is usually very small, so unlikely to overwrite the kernel09:05
qschulzwhile the opposite can be true (especially if you have an initrd in the kernel)09:05
qschulzs/can be true/is more likely/09:06
*** argonautx <argonautx!> has joined #yocto09:06
michaeloqschulz: from what I understand, the kernel will be decompressed at 0x80008000, so there should be enough space for the uncompressed kernel below 0x82000000. But you're right, swapping the two addresses is generally a good idea, and I should do that more often. In this case, there is enough space as the compressed kernel is 7 MB.09:09
qschulzif zImage overlaps on 0x83000000, the dtb will replace some code from the zImage even before the zImage is uncompressed, that's what I meant :)09:14
michaeloqschulz: right, I eventually understood :) Thanks for the clarification anyway.09:19
michaeloSo I agree that's a good idea to copy the DTB below the zImage.09:19
wyremichaelo, qschulz so do you recommend me still to try that michaelo suggested?09:29
michaelowyre: given the zImage size, my command would work. But what qschulz proposes is: "tftp 0x83000000 zImage; tftp 0x82000000 imx6ull-microgea-microdev.dtb; bootz 0x83000000 - 0x82000000"09:32
qschulzwyre: that, or you can compare the content of the RAM after loading the kernel from NAND with nand read followed by md to what is to be expected (tftp followed by md for example)09:32
michaeloGood idea09:32
wyreqschulz, how can I see the content of the RAM?09:33
michaelomd 0x83000000 after tftp or nand read to the same address09:33
wyremichaelo, qschulz
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)09:36
qschulzwyre: 0x83 in tftp log for the kernel?09:38
qschulzotherwise, looks like your zImage is corrupted09:38
wyrewell, I don't know why is doing this09:40
wyrebecause I'm giving the command what you wrote09:41
qschulzretype the whole line, there might be some invisible character that messes up the address, U-Boot command line is extremely finicky09:42
wyrelol, now "it worked"09:42
wyreI don't know why it was not handling properly the address09:42
wyrebut now did something
wyreqschulz, sure it was because that09:42
michaelowyre, qschulz: that's the first time I see this. Not the invisible characters in U-Boot in general, but the invisible characters in the addresses. I guess I was just lucky so far.09:43
wyreso now it's apparently failing because there is no rootfs, right?09:44
wyrebecause I can see at 708 line VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -1909:45
qschulzmichaelo: it happens so often to me when using Ctrl+W to (try) to remove the last word. Using Delete and not backspace also messes up the command line.09:45
qschulzwyre: looks like it09:46
qschulzcheck that your zImage has support for booting ubifs rootfs09:46
wyreqschulz, how can I check that?09:46
wyrealso I'm not sure the rootfs was properly flashed in nand 🤔09:47
wyreqschulz, in u-boot?09:47
qschulzwyre: yeah that's unlikely since ubifsls returned something correct in your earlier logs09:47
RPmichaelo: The invisible character thing can be a pain. I pasted an expression out of a web page into a commandline and caught one. I couldn't understand why grep was not finding things!09:47
qschulzno, you want to check if the *kernel* supports it, so kernel menuconfig09:47
wyreqschulz, but in the docker instance where I'm building the image, you mean?09:48
RPmichaelo: thanks for working on that docs change :)09:49
RPqschulz: and thanks for the review, I spent quite a while trying to avoid mistakes and you found a load :)09:50
wyreI'm not sure what are you talking about, I mean ... apparently menuconfig is a tool? what I should use to check the zImage? at any host? should I boot the zImage in some particular way? ...09:51
michaeloRP: your text was already pretty good. Such "raw" text is perfect for me!09:52
wyrealso ... the problem was in the addresses in the ker_dtb_fs.scr script?09:54
wyreshould I replace them with these you gave me?09:54
wyreI guess the point aren't those addresses themselves but the ${loadaddr} and ${fdt_addr} variables, right?09:55
michaelowyre: actually reading Bootlin's embedded Linux training materials should be profitable for several of your questions:
wyreoh, thank you very much, michaelo 😁10:11
qschulzRP: it's sometimes useful to be able to catch typos/mistakes easily but it's often a curse, I seem to always see them and be bothered by them 😭 For documentation, that's nice though :)10:22
*** eduardas <eduardas!~eduardas@> has joined #yocto10:30
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto10:35
*** xmn <xmn!> has joined #yocto10:35
michaeloqschulz: indeed, you have a gift, not a curse!10:36
michaeloqschulz: however, do you catch *your own typos* that easily too?10:36
RPqschulz: I have to laugh as the end of your last email had a small bit of grammar that made me wince :)10:37
michaeloqschulz: I agree though that it can be a curse indeed, especially when you're reading a text or source code, and are too distracted by the spelling or style mistakes that it's hard to focus on the meaning instead.10:38
qschulzmichaelo: I just feel bad if I don't catch my own typos, so I proof read my texts too many times and rephrase often. Since English is not my native language, I end up making mistakes anyway :D10:40
qschulzRP: and now I'm curious :) please enlighten me :)10:41
RPqschulz: "the script done by" would usually be written/merged/created/added but not done by10:42
qschulzRP: made by was probably what I wanted to go for10:43
RPqschulz: Just made me smile in the context of this discussion, there are plenty of native speakers who'd say that. It just isn't technically correct :)10:43
wyreare dtb and zImage generated always I build my image? 🤔10:43
qschulzRP: do and make are the same wnch :)10:43
qschulzthe same word in French*10:43
wyrehow can I force the zImage and dtb regeneration?10:44
qschulzit's a mistake very often ~done~ made by French speaker :/10:44
qschulz~~done~~? what's the strikethrough magic characters on IRC :p10:44
RPqschulz: and your other languages will be way better than mine :)10:44
LetoThe2ndqschulz: a lot of non-native speakers have specific common errors they make10:45
qschulzRP: I'm always wondering how bad it is for native speakers to have to converse in their own language with people''s second/third/4+ language with so many mistakes, syntactical/grammar issues10:46
qschulzI tried to bother my former Irish colleague to at least tell me when something was horrendously wrong but he never did... smh how am I going to learn from my mistakes if I don't see them :)10:47
qschulzLetoThe2nd: the usual "juste" typo for french people :D10:48
RPqschulz: With English it gets interesting as there are many strong dialects/accents. I live in an area with a particularly strong dialect (geordie)10:48
qschulzor I am agree, this one hurts a lot :p10:48
LetoThe2ndqschulz: for Germans, its "get" vs. "become"10:48
*** vmeson <vmeson!> has quit IRC (Ping timeout: 252 seconds)10:48
LetoThe2ndqschulz: for slavik language, i have the impression that they often leave out "the" or "a"10:49
LetoThe2ndqschulz: nope, german "werden"10:49
qschulzLetoThe2nd: yup, I had a Ukrainian colleague who did that a lot10:49
RPqschulz: that does mean I'm fairly tolerant. There are words I wouldn't use in conversations with non-locals10:49
qschulzRP: BTW, please correct me if you read something that could fuel your nightmares :)10:54
RPqschulz: I will, in general I don't see things to be honest. As I said, that one just made me smile given the discussion at the time10:55
qschulzRP: I think that's a rule. If you correct someone's grammar, you'll make a mistake yourself while arguing/correcting/explaining :)11:00
*** vmeson <vmeson!> has joined #yocto11:02
rber|res"German has more dialects then C" - should explain it all ;) - Oida11:07
qschulzwyre: it depends. But usually if you don't pass arguments to `make`, yes. Otherwise, you can pass `zImage dtbs` and that'll compile what you need11:09
wyreqschulz, but when I use bitbake to build the image I just use `bitbake <image-recipe>` ...11:10
wyreI mean, I'm not using make 🤔11:10
*** tnovotny <tnovotny!> has joined #yocto11:12
qschulzwyre: bitbake does. But it's safe to assume that your zImage and dtbs are compiled when needed11:12
wyreqschulz, I've removed manually tmp/deploy/images/<machine> folder and run again `bitbake <image>`, but it does not produce again the zImage and the dtb 😞11:14
qschulzbecause you're not supposed to do that IIRC11:17
qschulzremove the whole tmpdir or change nothing in it11:17
qschulz(make sure you have sstate-cache and downloads directories somewhere safe :)11:17
wyreso I should remove the whole tmp dir? 🤔11:17
RPwyre: bitbake <image> -c clean11:22
RPand maybe virtual/kernel too since you messed with that :)11:22
qschulzI always forget about clean, I always go for the nuke :p11:24
*** vd <vd!> has joined #yocto11:43
vdhi all -- I can have a recipe in recipes-core/images/ and multiple append in recipes-*/images/foo.bbappend, and all will be considered, correct?11:45
LetoThe2ndvd: correct.11:45
vdI have many _bar overrides in my recipe so I wanted to isolate them, I moved them in recipes-bar/images/foo.bbappend. Just wanted to make sure this is supposed to work.11:46
wyreRP, I'd say -c clean doesn't even remove the tmp/deploy/images dirs11:46
qschulzvd: bitbake-layers show-appends can tell you if it works ;)11:50
vdqschulz great thanks!11:51
vdlast question, if has do_rootfs[depends] += "bar:do_build", do I need to change this line if I'm now building the image from a multiconfig with mc:foo:foo?11:51
vdin other words, does "depends" target the current multiconfig (if any) or does it target the default local config (as in mc::foo)?11:53
wyremichaelo, and you were right, zImage is 7.5MB large and dtb is just 30KB large 🤔11:54
qschulzvd: I don't know but I think you need mc: only when doing cross-references. So if the recipe in which do_rootfs is and bar recipe are for the same machine, no need I'd say for mc:11:54
vdqschulz ok indeed I'd expect it to work as if BB_CURRENT_MC was specified. But I see a bench of image recipes with mc: prefix being built, so I'm kinda worried11:57
vdfor example both mc:foo:linux-ti-staging and linux-ti-staging are being built. Same for an image recipe. Should I specify do_rootfs[mcdepends] += "${BB_CURRENT_MC}:${BB_CURRENT_MC}:bar:do_build" from now on?12:09
vd(unless something like do_rootfs[depends]_foo works with an override fashion)12:10
RPwyre: it will remove specific contents, not the dir itself12:31
*** paulg <paulg!> has joined #yocto12:41
*** nucatus <nucatus!> has quit IRC ()12:42
michaelowyre: this sounds normal to me12:55
*** vd91 <vd91!> has joined #yocto13:07
*** vd <vd!> has quit IRC (Ping timeout: 246 seconds)13:10
vd91every time I rm -rf build/ and rebuild, it looks like linux-ti-staging recompiles from scratch (taking several minutes in do_compile). Is it because it's -git version? Like any other package it should be already built and retrieved from my (external) sstate-cache13:12
*** vd91 is now known as vd13:12
qschulzvd: maybe bitbake-diffsig will be able to tell you why13:14
jordemortgetting closer but still haven't cracked building an out-of-tree kernel module yet - here's a censored version of my recipe and the error i'm getting
jordemortit builds, but then when i try and build my image i get `nothing provides kernel-5.4.24+gd61efa3e9b18 needed by kernel-module-modname-5.4.24+gd61efa3e9b18-`13:19
jordemortit looks like `kernel-abiversion` is changing out from under me? in a previous iteration of this i had all my modules installed under /lib/modules/5.4.24+(some hex string) and this module installed under /lib/modules/5.4.24+(some entirely different hex string)13:20
jordemortso i've made progress from there in the sense that the package manager now recognizes there's a problem, at least13:21
*** yocti` <yocti`!> has joined #yocto13:25
*** Fanfwe42 <Fanfwe42!> has joined #yocto13:26
*** ad__ <ad__!> has joined #yocto13:26
qschulzjordemort: should help you get the basics I think13:34
*** alejandrohs <alejandrohs!> has quit IRC (*.net *.split)13:34
*** kmaincent1 <kmaincent1!> has quit IRC (*.net *.split)13:34
*** fray <fray!> has quit IRC (*.net *.split)13:34
*** __ad <__ad!~heisenbug@user/ad/x-9056428> has quit IRC (*.net *.split)13:34
*** yocti <yocti!> has quit IRC (*.net *.split)13:34
*** Fanfwe <Fanfwe!> has quit IRC (*.net *.split)13:34
qschulzLook also into the makefile and patch your OoT kernel driver's makefile if need be13:34
vdqschulz thanks, will try.13:35
jordemortqschulz: i'm pretty sure i've got everything from hello-mod covered13:35
vdcan do_rootfs[depends] += be written somehow with a _foo override?13:35
jordemortit builds the module and builds packages for it, the kernel-abiversion is just mismatched13:36
jordemortand i'm not sure why or how that's changing under me13:36
jordemortif i completely blow away sstate, then it will all build consistently13:37
JaMaRP: perfect, thanks, lets see how many I've missed :)13:38
* RP sets a data for merging all this to core of Monday13:40
JaMacan we test and merge the bitbake compatibility change to older bitbake branches before that?13:42
RPJaMa: it just merged13:44
*** argonautx <argonautx!> has quit IRC (Quit: Leaving)13:45
RPJaMa: admittedly it does need more testing but hopefully I got it right13:45
overrideis there a class or something I can inherit to work with yarn in recipes ?13:46
overridekinda like how setuptools etc work with python modules13:46
*** rosa <rosa!> has quit IRC (Remote host closed the connection)13:47
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)13:47
LetoThe2ndoverride: nope, not that i know of. also check the layerindex, but i'm pretty sure there is none.13:50
JaMaarmpit: feel free to use your version of the convertsion, my WIP wasn't very well tested anyway as we use only smack recipe from main security-layer and BBMASK everything else14:00
tlwoernerzeddii: could you recommend a MACHINE/BSP to study as a reference that provides a good example of using the kmeta and friends?14:03
* RP tweaks the conversion script so you can pass mbox/diffs through it14:05
RPthis is such a bad idea but...14:05
*** vd <vd!> has quit IRC (Ping timeout: 246 seconds)14:09
LetoThe2ndwe love bad ideas.14:13
*** sakoman <sakoman!> has joined #yocto14:14
*** vd <vd!> has joined #yocto14:14
qschulzRP: I had thought that VAR_var would mean _var is necessarily an override?14:15
RPqschulz: you can have a variable called VAR_var14:15
vdIf you want to ship tweaks for images, how do you choose between writing a class to inherit from or writing image features?14:16
RPI'm not saying it is a good idea, just that it is allowed14:16
qschulzRP: yeah, makes it so much harder to understand what is an override and what is not... which will be clarified with the new syntax :)14:16
RPqschulz: exactly14:16
RPqschulz: I did have to go and look at what that test was doing14:17
qschulzI'll probably need to do something similar for the modifications I suggested for the other tests14:17
qschulzalmost got caught by :some_val: override until I remember x86_64 is a valid override too14:17
qschulzwhat a nightmare14:17
RPqschulz: I replied about that, before you go too deep have a look at my other patch. I left the automated fixes and the manual ones as two patches14:18
RPqschulz: it is a total nightmare, hence the desire to add this syntax :)14:18
RPqschulz: FWIW bitbake-selftest does pass after the changes submitted14:19
qschulzYeah but if the tests are false positives... :p14:19
RPqschulz: happy to have a second opinion on that14:20
qschulzRP: and all that was needed to trigger this change was to present a talk at YP summit :p14:20
qschulz(let me believe please)14:20
RPqschulz: definitely :)14:20
qschulzRP: at least I've an opportunity to do a v2 :p14:21
qschulznot that much is supposed to change14:21
qschulzthough I'm keeping an eye on this new operator if it's still on the table14:21
qschulz(admittedly missed a few mails :) )14:22
armpitJaMa: k14:22
RPqschulz: new operator is uncertain at the moment. One step at a time14:24
* RP is struggling with this change alone14:24
vdwhat is the proper syntax to override a variable with flag? SOMEVAR[flag]_foo ?14:35
JaMaRP: the check is already finding more and more places missed by the script (I've shared some in reply to ML, but after fixing them it finds more and more :))14:36
JaMae.g. RDEPENDS_${PN}-apply_append_class-target = " ${VIRTUAL-RUNTIME_bash}"14:37
RPJaMa: It did find one issue in my OE-core patch too14:37
RPJaMa: we might want to remove some of the exclusions in the core script for other layers14:37
RPJaMa: I think its too specific to core14:37
RPJaMa: a list of the issues you're finding might be helpful so we know which exclusions to consider dropping14:38
RPmy reasoning is core is basically done and it would be better to be more widely useful14:38
JaMae.g. do_generate_toolchain_file_append_class-native  was skipped due to "file_append" in the exceptions14:40
JaMabut hard to imagine what were the cases where you needed "file_append" in the exceptions14:41
RPJaMa: there are test cases with that name in core but this is why I'm thinking we should drop it14:41
JaMabut the same would happen in oe-core if here is do_generate_toolchain_file_append somewhere, right?14:42
RPJaMa: yes14:43
vddoes SOMEVAR[flag]_machine += works?14:51
vdRP: does this need a change?,,,20,1,0,0::recentpostdate%2Fsticky,,,20,2,0,8443990315:03
*** michaelo <michaelo!> has quit IRC (Remote host closed the connection)15:04
*** michaelo <michaelo!> has joined #yocto15:04
qschulzvd: for the new syntax?15:05
jordemortooh i think i figured it out15:12
jordemorti'm using meta-freescale and the linux-imx kernel recipe and there's an fsl-kernel-localversion that seems to be fooling w/ things15:12
vdqschulz no for the current syntax15:13
vdqschulz is there a new syntax supporting this already?15:15
qschulzvd: just been posted to the bitbake-devel ML, that's what we were briefly discussing earlier15:16
qschulzhence my question :)15:16
RPvd: that one isn't really used as an override so no15:16
qschulzRP: I think it was just meant as a ping and unrelated to new override syntax? let's see :)15:17
RPqschulz: oh15:19
RPbut it already merged: ?15:19
vdqschulz my bad. So I guess the current syntax doesn't support override for do_rootfs[depends] += neither, does it?15:22
vdRP: my bad, I'm still not used to patches getting applied without a reply ^^15:23
qschulzvd: try do_rootfs_override[depends] I guess?15:24
RPvd: it isn't ideal but replying to them all just isn't feasible and we don't have the right automation in place to do it :(15:24
qschulzor do_rootfs_override_append_override[depends] and check with bitbake -e but oof, not sure it's ideal :)15:24
qschulzRP: I don't know if patchwork can do this for you?15:25
RPqschulz: kind of but even that isn't working15:26
kergothflags aren't propogated when overrides are applied. the flags will stay on the original variable name15:26
kergothalso bitbake -e doesn't show flag values15:26
qschulzkergoth: something to be added maybe then :)15:27
vdRP: do you mean that you didn't write a script for your email client to pipe the message in git-am and reply "Applied, thanks." automatically? ;-D15:27
kergothqschulz: the semantics aren't clear.15:27
RPwe are not adding overrides to flags15:27
qschulzRP: pffff you don't know how to have fun15:27
kergoththe behavior would be unintuitive no matter how we implement it15:27
kergothwhen does a flag value replace vs alter an existing value?15:27
kergothit's a mess, no15:27
qschulzI was talking about adding the flag value to bitbake -e :)15:27
RPvd: if only it were that simple ;-)15:28
qschulzTwo topics at once, not easy :p15:28
RPadding flags to bitbake-getvar would be the right question15:28
kergothbitbake -e's output is actually coming from a function that's used in a bunch of places15:28
kergothyeah, thats what i was going to suggest too :)15:28
kergothcould just make it accept flag syntax. bitbake-getvar 'do_rootfs[depends]'15:28
vdwhat is the proper way to add a dependency to task for an override then?15:29
kergothvd: like i suggested earlier, use an intermediate variable if you need to15:29
kergothFOO = "something"; FOO_override = "something else"; do_foo[bar] += "${FOO}"15:29
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)15:29
kergothor whatever15:29
vdkergoth sorry I missed your reply15:30
vdkergoth ho ok that's nice, ${FOO} can safely be empty I presume?15:30
kergothexactly, yes15:30
vdkergoth: if has FOO = ""; do_foo[bar] += "${FOO}" and foo.bbappend has FOO_override = "something else15:38
vd", will do_foo[bar] contain "something else"?15:38
kergothif override is in OVERRIDES, yeah. doesn't matter if its in a bbappend or not, bbappending is basically concatenation15:38
*** eduardas <eduardas!~eduardas@> has quit IRC (Quit: Konversation terminated!)15:41
vdkergoth perfect then. Yes I'm setting OVERRIDES .= ":${BB_CURRENT_MC}" to customize recipes and packages based on the multiconfig they are built for. To isolate changes, I put the overriden variables in .bbappend files.15:42
RPvd: Small tip is to do something like OVERRIDES .= ":mc-${BB_CURRENT_MC}" since mc-XXX is much more unique than variable mc names15:44
kergothgood point. i wish we'd namespaced our existing overrides to avoid conflicts :)15:44
RPkergoth: we have tried to learn from that since!15:45
RP(task-, pn-, tune- but not img-, bad RP)15:46
vdRP: thank you!15:47
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)15:47
*** mckoan is now known as mckoan|away15:47
vdThe variable system of OpenEmbedded is very powerful, but I wish the scopes were somehow explicit and obvious (local > auto > multiconfig > machine > distro > image > package > ...)15:48
kergoththat layering is essentially encoded both in variables via overrides and in the configuration data in the order of the inclusion of the config files15:49
kergothnot 100% since local.conf *has* to be before machine/distro, but..15:49
vdyeah the tricky part in the OE learning curve is knowing if a given config file can override a variable or not15:50
vdBut I have absolutely no idea how you could make the scope of a variable obvious...15:51
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto15:51
jordemortis there a way to "disinherit" a class from a .bbappend?16:04
kergothvd: its easier than it used to be now that bitbake -e shows variable history. being able to see exactly what lines in what files set the variable is very helpful16:05
kergothcourse thats not new anymore, just still seems that way to me :)16:05
overridetrying to understand what a sysroot is16:06
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:14
*** florian <florian!> has joined #yocto17:00
*** florian <florian!> has quit IRC (Ping timeout: 265 seconds)17:09
*** florian <florian!> has joined #yocto17:17
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:40
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)17:40
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)17:48
*** otavio <otavio!> has joined #yocto17:55
*** yocti` is now known as yocti18:10
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)18:11
*** florian <florian!> has joined #yocto18:26
*** florian <florian!> has quit IRC (Ping timeout: 258 seconds)18:31
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)18:32
vdfunny, _append_override or _override_append works the same, it's a bit confusing18:42
*** bps <bps!> has joined #yocto18:53
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:55
*** bps <bps!~bps@user/bps> has quit IRC (Remote host closed the connection)19:07
*** bps <bps!> has joined #yocto19:07
vdis one syntax preferred over the other?19:17
smurrayRP: that hang does seem very much like something changed in Python 3.8 or 3.9, I'm having no luck reproducing it when I try on Debian 10 with 3.7.  Which is maybe useful information, need to dig through their release notes (and rig up a test with 3.8.x)19:20
vdhow do you choose between writing an image feature vs. writing a class to inherit from?19:31
*** florian <florian!> has joined #yocto19:39
rber|resvd, why do you think  _append_override or _override_append works the same?19:40
rber|resvd, check here:
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)19:51
JaMaRP: another case missed by conversion script (not sure how common this one is, there are 4 cases in meta-webos-ports which luckily broke do_install task: install -m 0644 ${S}/files/systemd/${SYSTEMD_SERVICE_${PN}} ${D}${systemd_unitdir}/system/20:05
*** ant__ <ant__!> has joined #yocto20:10
vdrber|res you're right, they aren't the same. I'm even more confused now20:20
vdrber|res ok I get it, thank you.20:32
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 276 seconds)20:35
vdCan you force a package version from a configuration file?20:45
rber|resvd, if you are confused with BitBake you are on the right track ;) shameless self promotion:
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 250 seconds)21:03
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 265 seconds)21:03
rber|resvd, version: look e.g. here:
rber|resvd, this inlcudes:
rber|resvd, which sets many things to AUTOREV -> latest and greatest21:04
rber|resvd, e.g. PREFERRED_VERSION would work21:05
vdrber|res: perfect!21:05
rber|resvd, you had also a question about FEATURE vs. class21:06
rber|resvd, in my mind those are different things ;)21:06
rber|resvd, there are IMAGE, MACHINE, DISTRO features21:06
vdrber|res: unfortunately, I have different builds to do with various combinations of firmware versions. I guess I can simply with a multiconfig file per variant which sets the PREFFERED_VERSION for the firmware packages.21:07
vds/simply with/simply write/21:08
rber|resvd, so you build the same image with different versions of components?21:09
rber|resvd, I guess PREFERRED_VERSION would work then.21:09
rber|resvd, if you also want to build things differently you could introduce a FEATURE, check in your recipes for this FEATURE and build things accordingly21:10
vdrber|res: exactly. unfortunately different customer use different firmware versions, so I must support them all.21:10
rber|resvd, hehe yes I have many customers who need stuff like that ;)21:11
vdcan PREFERRED_VERSION be set at the image recipe level?21:11
rber|resvd, Yocto chant number 1 (I think): config data is global, recipe data is local21:12
rber|resvd, I guess you want it in a config file and not in your image recipe21:12
vdyep, hence the multiconfig per combination is preferred21:12
vdrber|res: for feature vs. class, I have a few do_rootfs[depends], a few ROOTFS_POSTPROCESS_COMMAND and other kernel command line tweaks per image, and if I want to factorize that, I'm not just if I must write a bbclass, or image features.21:13
rber|resvd, I see as class as something which you define once and it's used multiple times, like cmake.bbclass21:14
rber|resvd, if you inherit this in your recipe, the recipe knows about cmake and does it's steps accordingly21:15
vdhum, and since I'm customize rootfs overlays and stuffs like that, I guess these are local image FEATURES, not a sharable functionality across images.21:16
rber|resvd, kernel command line tweaks: I would just create a .bbappend e.g. to the boot loader environment21:16
rber|resvd, IMAGE_FEATURES can be across all images21:17
*** goliath <goliath!~goliath@user/goliath> has joined #yocto21:17
vdwell depends how you see it. in fact I might define an overlay.bbclass, which embeds overlay images, and inject an initramfs which mounts them and switch-root to it.21:19
rber|resvd, something like this?
vdrber|res something similar yes21:23
rber|resvd, I just grepped for do_rootfs[depends] in all the layers I have lying around here and it's only used in .bbclass files. It looks like mainly to bring in -native tools and some keys21:26
rber|resvd, seems to be similar with ROOTFS_POSTPROCESS_COMMAND ;)21:27
vdrber|res I see. I use both to embed the initrd and overlays inside the rootfs.21:28
rber|resvd, check here:
rber|resvd, there you see e.g. if IMAGE_FEATURES contains debug-tweaks then do this, otherwise that21:29
vdrber|res the naming is confusing, is this class implementing ROOTFS_POSTPROCESS_COMMAND or only relying on it?21:33
vdI feel like it's the latter, hence image-features.bbclass would've been more appropriate21:33
rber|resvd, it just does ROOTFS_PROCESS_COMMANDS based on image features21:34
vdIn other words, this class is where you implement new upstream image features?21:34
RPsmurray: that would match the cases we've see as it is usually buildtools which is 3.921:34
vdyou don't need to declare them somewhere else21:34
rber|resvd, nope21:34
smurrayRP: yeah21:35
RPJaMa: I think we only had one case of that in core and the same variable. We could add special handling for it21:35
rber|resvd, you define an image feature e.g. in a config and now based on if it's set or not you can do different things in classes and recipes21:35
*** sakoman <sakoman!> has joined #yocto21:35
vdrber|res I see so my custom "features" would be a similar bbclass adding support for new custom values of IMAGE_FEATURES (or another variable), via ROOTFS_POSTPROCESS_COMMAND21:36
rber|resvd, your custom features could trigger things in your custom classes or recipes21:37
vdin fact this code could simply go into the image recipe, if I only use one recipe for now (which is appended here and there via overrides)21:37
rber|resvd, here different kernel config fragments are pulled in based in FEATURES:
rber|resvd, your features are not a class21:40
rber|resvd, let's say you want to add a custom DISTRO_FEATURE. Then in a config file you can add DISTRO_FEATURES_append = " lumpi"21:41
rber|resvd, and now in your recipe or class you could see if someone set lumpi in DISTRO_FEATURES and react on it21:41
rber|resvd, this line says, that if someone added soft-watchdog to DISTRO_FEATURES to add some kernel config (the soft watchdog)21:43
vdI see in fact features and class are really orthogonal, features are just a list of keywords that some code (an image recipe or class) can react on21:43
rber|resvd, yep21:43
rber|resvd, and with BACKFILL you can remove features from a list ;)21:43
vdho, I was using DISTRO_FEATURES_remove = "nfs", is it bad? :D21:44
rber|resvd, you could have FEATURES which all your customers want except for one, or which don't work on a special hardware21:44
rber|resvd, RP will tell you what is the punishment for this ;)21:44
* vd is scared now21:45
RPrber|res: I'm mainly against using remove in oe-core21:45
vdrber|res ho damn, I think you just opened a door in my mind, I might now sleep tonight :D21:46
rber|resvd, good - normally this only happends after lots of alc with my brain ;)21:46
vdrber|res: so let say my product is highly customizable, same base hardware, but some have solar panel, some have a gps, some have a 3g modem, etc. I should define (distro, machine or image?) features for e.g. "product-solarpanel", "product-gps", "product-3g" and include or exclude packages and config accordingly21:48
rber|resvd, idealle you clould see MACHINE as something hardware near21:49
rber|resvd, ideally21:50
rber|resvd, hardware supports bluetooth is in my mind a MACHINE feature21:50
rber|resvd, but in order to use bluetooth you also need a few user space apps and daemons21:50
rber|resvd, so this would be a DISTRO feature21:51
rber|resvd, normally both need to exist e.g. to turn on things on kernel level and to install/configure apps21:51
rber|resvd. but you might now want to use a non standard bluetooth stack and so on21:52
rber|resvd, it's pretty flexible21:52
vdso I would define a bbclass which looks for "bluetooth" in DISTRO/IMAGE_FEATURES and configure my preferred bluetooth stack?21:53
rber|resvd, you can actually grep for this, since this should exist ;)21:53
ant__there is indeed a relation between kernel config and machine features but afaik there is not yet a binding21:53
vdwell an image could only decide which package to install, not set the preferred provider I presume21:53
ant__zeddii, maybe you did explore that thing21:54
rber|resvd, you could define MACHINE features in your machine config21:54
rber|resvd, = "alsa bluetooth usbgadget screen vfat"21:54
rber|resvd, ?= "acl alsa argp bluetooth21:55
vdis it best to integrate existing features in your layer (e.g. "screen") or is it better to define your own features?21:56
vd(e.g. "myproduct-screen")21:56
ant__I'd say use features and split these between sibling machines21:58
ant__i.e {@bb.utils.contains('MACHINE_FEATURES', 'v3d-nxpl', 'file://egl/EGLNativeTypeV3D-nxpl.patch', '', d)} \.21:59
ant__patches can also be related21:59
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)22:00
vdSeems like a very powerful mess :D22:00
vdhum, with OVERRIDES = "override"; FOO = "A"; FOO_override += "B", FOO with be "B", not "A B", right?22:08
vdI must use FOO_append_override if I want to preserve the initial value of FOO if I'm not mistaken22:09
RPvd: correct22:10
vdin order to create a minimal overlay image, how can I make sure that an image with IMAGE_INSTALL = "foo" (or PACKAGE_INSTALL = "foo"?) contains *ONLY* FILES_foo? (and same for foo dependencies)22:14
rber|resvd, I am a bit confused now. You will have an image recipe which defines what it contains.22:16
vdrber|res I tried both IMAGE_INSTALL = "foo" or PACKAGE_INSTALL = "foo", but there are always non-foo files in the image22:17
*** sakoman <sakoman!> has quit IRC (Read error: Connection reset by peer)22:17
rber|resvd, maybe dependencies?22:18
rber|resvd, I typically use a core-image-minimal and add stuff to it.22:18
rber|resvd, if you want something really minimal, like what's in a container this can be done as well.22:20
*** sakoman <sakoman!> has joined #yocto22:20
vdrber|res it'll come with packagegroup-core-boot stuffs and other files (package database files I guess). What I'm trying to have is a squashfs image of a few packages (let's say "foo" and its dependency "bar")22:20
vdmaybe using a image recipe is wrong because it's not really a rootfs image, but it's the approach I took since it's the way to select packages and the output squashfs format22:21
vdRP: thank you btw, it now explains why my image didn't boot anymore, IMAGE_BOOT_IMAGES_override += "somefile" wasn't what I initally thought ;)22:24
rber|resvd, so don't use packagegroup-core-boot ;)22:26
rber|resvd, for container stuff I use something like this:
vdrber|res I had to use VOLATILE_LOG_DIR = "no" in my distro to workaround the systemd-nspawn calls ;-)22:28
rber|resCan we please punish upstream repo maintainers who remove the master branch and rename it to main ;) a right to compensation for personal suffering, etc.22:29
rber|resvd if you have systemd-nspawn you already have your overlays ;)22:30
vdrber|res thanks for the input. Although I'm trying to create an overlay image, not a minimal rootfs image. For example it could contains a proprietary application (hence only its /usr/bin/foo and /usr/lib/ files)22:30
rber|resvd, and you are sure you want to do this yourself manually?22:30
vdrber|res say no more, this master -> main renaming makes absolutely no sense, because here "master" isn't use in a master-slave context. "master" is still a valid word. What's next, "Karate Mains"?22:32
rber|resvd, and BitBake uses by default "master" - I was searching a few hours now why a recipe did not build and was getting frustrated.22:33
rber|resvd, I REALLY did not think that someone renamed the master branch to something else and removed it.22:33
rber|resvd, we will have much fun with our recipes if this happens all over the place ;)22:34
vdmakes no sense. I truly understand the master-slave problem and I'm all for the renaming. With have this vocabulary in kernel networking and it's inappropriate. But in a non master-slave context, renaming master makes no sense...22:35
vdrber|res anyway, on boot I'm mounting this proprietary overlay containing only the said application over the base rootfs. Isn't an image recipe suitable for this overlay?22:35
rber|resvd, one more hint, which might help. I added a container to a package. So this might help in your case as well. Just write a ?image recipe which adds only what you want and install this package. This might do what you want.22:35
rber|resvd, multiconfig - one config (in my case) which builds the container, another config which picks this up, makes a pkg out of it and installs it to the rootfs22:36
rber|resvd, I guess a pkg which contains only foo and bar is what you might want.22:37
vdrber|res I'm already packaging a container with do_rootfs[depends] += "container:do_build" and installing it in /var/lib/machines with ROOTFS_POSTPROCESS_COMMAND.22:38
vdBut for the overlay image, yes I only want foo and bar inside of it, as if you created the squashfs manually (e.g. only two files /usr/bin/foo and /usr/lib/bar in it)22:38
*** paulg <paulg!> has quit IRC (Ping timeout: 258 seconds)22:39
rber|resvd, so you don't bundle it as a package, but just copy it over?22:39
rber|resvd, I'm doing something along these lines:
rber|resvd, do_fetch[mcdepends] = "mc:${NATIVE_MACHINE}:${CONTAINER_MACHINE}-${CONTAINER_DISTRO}:${CONTAINER_IMAGE}:do_image_complete"22:44
rber|resHere it's getting 1:45 in the morning ;) So I guess I'll give up for tonight. CU22:45
vdrber|res currently I have this image doing IMAGE_FSTYPES = "squashfs"; IMAGE_INSTALL = "foo", and for I'm doing the do_rootfs[depends]/ROOTFS_POSTPROCESS_COMMAND trick to install it. But I could also define a package to handle the install part.22:46
rber|resvd, Yep understood22:46
vdmy worries is the overlay.squashfs containing *only* the files from the foo package22:46
* vd will read rber|res's code ;)22:46
rber|resvd, the package manager will pull in runtime dependencies as well ;)22:47
vdyes this I don't want in the overlay squashfs :/22:48
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)22:49
*** florian <florian!> has joined #yocto23:04
*** florian <florian!> has quit IRC (Ping timeout: 272 seconds)23:17
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)23:58

Generated by 2.17.2 by Marius Gedminas - find it at!