<michaelo[m]>
I'm on Matrix and receiving some of these messages in bursts.
<michaelo[m]>
The synchronization with libera.chat looks broken
rostam98[m] has joined #yocto
nucatus has quit [Remote host closed the connection]
xmn has quit [Quit: ZZZzzz…]
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
mckoan|away is now known as mckoan
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
nucatus has joined #yocto
<mckoan>
alicef: see BB_GIT_SHALLOW_DEPTH in bitbake/lib/bb/fetch2/git.py
camus has quit [Ping timeout: 258 seconds]
camus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
prabhakarlad has joined #yocto
nucatus has joined #yocto
vd has quit [Ping timeout: 246 seconds]
rosa has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
<qschulz>
override: don't reinvent the wheel and take upgrade mechanisms that already exist (mender, rauc, swupdate, you namne it)
<qschulz>
most of them support A/B mechanism I think
<qschulz>
which have their own specific way of booting rootfs A or B (kernel A and B too I guess)
florian has joined #yocto
<qschulz>
you'll need to implement the U-Boot logic I guess but I sure hope it's appropriately documented :)
<qschulz>
michaelo[m]: It's very hard for me to restrain myself from trolling on matrix :)
<michaelo>
qschulz: funny, then IRC moderates you :)
<qschulz>
michaelo: It was more about trolling on Matrix piece of SW :)
<qschulz>
I didn't have a good experience with it but people keep telling me everything works perfectly fine :)
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudX
<wyre>
hi guys, I'm trying of flashing an ubifs image in NAND and apparently the flshing process looks good but then kernel doesn't load https://bpa.st/BHOA this is my environment https://bpa.st/SMYA, as you can see I had to create a new bootzcmd_ubi variable because the existent one uses bootm instead bootz
<wyre>
I'd say all is correct, but it doesn't boot 😞
alinucs has joined #yocto
<qschulz>
wyre: why are you TFTP loading the ubifs file?
<qschulz>
and 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 variable
<qschulz>
nothing to do with ubi (yet)
<wyre>
qschulz, you can see the contents in the link I pasted with the environment https://bpa.st/SMYA
<wyre>
I've basically copied the bootcmd_ubi which is using bootm but replacing this with bootz
<wyre>
because the built image is a zImage
goliath has joined #yocto
<qschulz>
check 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.
<qschulz>
But that's probably more a question for #u-boot
<wyre>
I see, thank you anyway ...
<jsandman>
Hi 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 " sqlite3_3.31.1.bb:do_fetch) failed with exit code 'setscene whitelist' " Does this sound faimiliar to someone here?
<LetoThe2nd>
jsandman: does this happen with a raw dunfell poky?
<michaelo>
wyre: wow, your nand read for the DTB is pessimistic, 1 MB for the DTB, while 100 KB (or even 64 KB) are probably enough!
<jsandman>
I have not tried to generate an sdk for that. I shall try that yeah
<michaelo>
wyre: 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.
<michaelo>
wyre: I also agree with the advice from qschulz
<LetoThe2nd>
jsandman: please do so, yes. to trim down the possible sources.
<michaelo>
wyre: 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"
<qschulz>
michaelo: you probably want the load addresses swapped though
<wyre>
michaelo, thank you very much 😁
<qschulz>
DTB is usually very small, so unlikely to overwrite the kernel
<qschulz>
while the opposite can be true (especially if you have an initrd in the kernel)
<qschulz>
s/can be true/is more likely/
argonautx has joined #yocto
<michaelo>
qschulz: 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.
<qschulz>
if zImage overlaps on 0x83000000, the dtb will replace some code from the zImage even before the zImage is uncompressed, that's what I meant :)
<michaelo>
qschulz: right, I eventually understood :) Thanks for the clarification anyway.
<michaelo>
So I agree that's a good idea to copy the DTB below the zImage.
<wyre>
michaelo, qschulz so do you recommend me still to try that michaelo suggested?
<michaelo>
wyre: 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"
<qschulz>
wyre: 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)
<michaelo>
Good idea
<wyre>
qschulz, how can I see the content of the RAM?
<michaelo>
md 0x83000000 after tftp or nand read to the same address
<michaelo>
wyre, 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.
<wyre>
so now it's apparently failing because there is no rootfs, right?
<wyre>
because I can see at 708 line VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19
<qschulz>
michaelo: 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.
<qschulz>
wyre: looks like it
<qschulz>
check that your zImage has support for booting ubifs rootfs
<wyre>
qschulz, how can I check that?
<wyre>
also I'm not sure the rootfs was properly flashed in nand 🤔
<qschulz>
menuconfig
<wyre>
qschulz, in u-boot?
<qschulz>
wyre: yeah that's unlikely since ubifsls returned something correct in your earlier logs
<RP>
michaelo: 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!
<qschulz>
no, you want to check if the *kernel* supports it, so kernel menuconfig
<wyre>
qschulz, but in the docker instance where I'm building the image, you mean?
<RP>
michaelo: thanks for working on that docs change :)
<RP>
qschulz: and thanks for the review, I spent quite a while trying to avoid mistakes and you found a load :)
<wyre>
I'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? ...
<michaelo>
RP: your text was already pretty good. Such "raw" text is perfect for me!
<wyre>
also ... the problem was in the addresses in the ker_dtb_fs.scr script?
<wyre>
should I replace them with these you gave me?
<wyre>
I guess the point aren't those addresses themselves but the ${loadaddr} and ${fdt_addr} variables, right?
<qschulz>
RP: 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 :)
eduardas has joined #yocto
jwillikers has joined #yocto
xmn has joined #yocto
<michaelo>
qschulz: indeed, you have a gift, not a curse!
<michaelo>
qschulz: however, do you catch *your own typos* that easily too?
<RP>
qschulz: I have to laugh as the end of your last email had a small bit of grammar that made me wince :)
<michaelo>
qschulz: 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.
<qschulz>
michaelo: 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 :D
<qschulz>
RP: and now I'm curious :) please enlighten me :)
<RP>
qschulz: "the script done by" would usually be written/merged/created/added but not done by
<qschulz>
RP: made by was probably what I wanted to go for
<RP>
qschulz: 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 :)
<wyre>
are dtb and zImage generated always I build my image? 🤔
<qschulz>
RP: do and make are the same wnch :)
<qschulz>
the same word in French*
<wyre>
how can I force the zImage and dtb regeneration?
<qschulz>
it's a mistake very often ~done~ made by French speaker :/
<qschulz>
~~done~~? what's the strikethrough magic characters on IRC :p
<RP>
qschulz: and your other languages will be way better than mine :)
<LetoThe2nd>
qschulz: a lot of non-native speakers have specific common errors they make
<qschulz>
RP: 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 issues
<qschulz>
I 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 :)
<qschulz>
LetoThe2nd: the usual "juste" typo for french people :D
<RP>
qschulz: With English it gets interesting as there are many strong dialects/accents. I live in an area with a particularly strong dialect (geordie)
<qschulz>
or I am agree, this one hurts a lot :p
<LetoThe2nd>
qschulz: for Germans, its "get" vs. "become"
vmeson has quit [Ping timeout: 252 seconds]
<qschulz>
will?
<LetoThe2nd>
qschulz: for slavik language, i have the impression that they often leave out "the" or "a"
<LetoThe2nd>
qschulz: nope, german "werden"
<qschulz>
LetoThe2nd: yup, I had a Ukrainian colleague who did that a lot
<RP>
qschulz: that does mean I'm fairly tolerant. There are words I wouldn't use in conversations with non-locals
<qschulz>
RP: BTW, please correct me if you read something that could fuel your nightmares :)
<RP>
qschulz: 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 time
<qschulz>
RP: I think that's a rule. If you correct someone's grammar, you'll make a mistake yourself while arguing/correcting/explaining :)
vmeson has joined #yocto
<rber|res>
"German has more dialects then C" - should explain it all ;) - Oida
<qschulz>
Genau
<LetoThe2nd>
OIDA
<qschulz>
wyre: 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 need
<wyre>
qschulz, but when I use bitbake to build the image I just use `bitbake <image-recipe>` ...
<wyre>
I mean, I'm not using make 🤔
tnovotny has joined #yocto
<qschulz>
wyre: bitbake does. But it's safe to assume that your zImage and dtbs are compiled when needed
<wyre>
qschulz, 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 😞
<qschulz>
because you're not supposed to do that IIRC
<qschulz>
remove the whole tmpdir or change nothing in it
<qschulz>
(make sure you have sstate-cache and downloads directories somewhere safe :)
<wyre>
so I should remove the whole tmp dir? 🤔
<RP>
wyre: bitbake <image> -c clean
<RP>
and maybe virtual/kernel too since you messed with that :)
<qschulz>
I always forget about clean, I always go for the nuke :p
<LetoThe2nd>
nuke++
vd has joined #yocto
<vd>
hi all -- I can have a recipe in recipes-core/images/foo.bb and multiple append in recipes-*/images/foo.bbappend, and all will be considered, correct?
<LetoThe2nd>
vd: correct.
<vd>
I 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.
<wyre>
RP, I'd say -c clean doesn't even remove the tmp/deploy/images dirs
<qschulz>
vd: bitbake-layers show-appends can tell you if it works ;)
<vd>
qschulz great thanks!
<vd>
last question, if foo.bb 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?
<vd>
in other words, does "depends" target the current multiconfig (if any) or does it target the default local config (as in mc::foo)?
<wyre>
michaelo, and you were right, zImage is 7.5MB large and dtb is just 30KB large 🤔
<qschulz>
vd: 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:
<vd>
qschulz 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 worried
<vd>
for 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?
<vd>
(unless something like do_rootfs[depends]_foo works with an override fashion)
<RP>
wyre: it will remove specific contents, not the dir itself
paulg has joined #yocto
nucatus has quit []
<michaelo>
wyre: this sounds normal to me
vd91 has joined #yocto
vd has quit [Ping timeout: 246 seconds]
<vd91>
every 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-cache
vd91 is now known as vd
<qschulz>
vd: maybe bitbake-diffsig will be able to tell you why
<jordemort>
it 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-5.9.0.8+37203.20200904+COEX20200103+1717-r0.sercomm_na503s`
<jordemort>
it 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)
<jordemort>
so i've made progress from there in the sense that the package manager now recognizes there's a problem, at least
<jordemort>
so it looks like it at least unpacked and built some of the kernel, in order to build the module, but ended up with a different `kernel-abiversion` from when it last built the kernel packages, and elected not to rebuild the rest of the kernel packages
<jordemort>
i've mostly just been trying to copy the wireguard and lkrg recipies i see out there and i'm not sure what is missing
<RP>
JaMa: I've added a check to bitbake to error if it sees old style _append/_remove/_prepend being used which goes a long way to showing users using unconverted layers or local.conf
<jordemort>
what is kernel-abiversion and what causes it to change? why aren't my other kernel packages getting rebuilt when it has apparently changed for building this module?
<jordemort>
do i need to make my kernel recipe depend on the 3rd party module somehow?
<vd>
can do_rootfs[depends] += be written somehow with a _foo override?
ad__ has quit [Changing host]
ad__ has joined #yocto
<jordemort>
it builds the module and builds packages for it, the kernel-abiversion is just mismatched
<jordemort>
and i'm not sure why or how that's changing under me
<jordemort>
if i completely blow away sstate, then it will all build consistently
<JaMa>
RP: perfect, thanks, lets see how many I've missed :)
* RP
sets a data for merging all this to core of Monday
<JaMa>
can we test and merge the bitbake compatibility change to older bitbake branches before that?
<RP>
JaMa: it just merged
argonautx has quit [Quit: Leaving]
<RP>
JaMa: admittedly it does need more testing but hopefully I got it right
<override>
is there a class or something I can inherit to work with yarn in recipes ?
<override>
kinda like how setuptools etc work with python modules
rosa has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<LetoThe2nd>
override: nope, not that i know of. also check the layerindex, but i'm pretty sure there is none.
<JaMa>
armpit: 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 else
<tlwoerner>
zeddii: could you recommend a MACHINE/BSP to study as a reference that provides a good example of using the kmeta and friends?
* RP
tweaks the conversion script so you can pass mbox/diffs through it
<RP>
this is such a bad idea but...
vd has quit [Ping timeout: 246 seconds]
<LetoThe2nd>
we love bad ideas.
sakoman has joined #yocto
vd has joined #yocto
<qschulz>
RP: I had thought that VAR_var would mean _var is necessarily an override?
<RP>
qschulz: you can have a variable called VAR_var
<vd>
If you want to ship tweaks for images, how do you choose between writing a class to inherit from or writing image features?
<RP>
I'm not saying it is a good idea, just that it is allowed
<qschulz>
RP: yeah, makes it so much harder to understand what is an override and what is not... which will be clarified with the new syntax :)
<RP>
qschulz: exactly
<RP>
qschulz: I did have to go and look at what that test was doing
<qschulz>
I'll probably need to do something similar for the modifications I suggested for the other tests
<qschulz>
almost got caught by :some_val: override until I remember x86_64 is a valid override too
<qschulz>
what a nightmare
<RP>
qschulz: 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 patches
<RP>
qschulz: it is a total nightmare, hence the desire to add this syntax :)
<RP>
qschulz: FWIW bitbake-selftest does pass after the changes submitted
<qschulz>
Yeah but if the tests are false positives... :p
<RP>
qschulz: happy to have a second opinion on that
<qschulz>
RP: and all that was needed to trigger this change was to present a talk at YP summit :p
<qschulz>
(let me believe please)
<RP>
qschulz: definitely :)
<qschulz>
RP: at least I've an opportunity to do a v2 :p
<qschulz>
not that much is supposed to change
<qschulz>
though I'm keeping an eye on this new operator if it's still on the table
<qschulz>
(admittedly missed a few mails :) )
<armpit>
JaMa: k
<RP>
qschulz: new operator is uncertain at the moment. One step at a time
* RP
is struggling with this change alone
<vd>
what is the proper syntax to override a variable with flag? SOMEVAR[flag]_foo ?
<JaMa>
RP: 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 :))
<JaMa>
e.g. RDEPENDS_${PN}-apply_append_class-target = " ${VIRTUAL-RUNTIME_bash}"
<RP>
JaMa: It did find one issue in my OE-core patch too
<RP>
JaMa: we might want to remove some of the exclusions in the core script for other layers
<RP>
JaMa: I think its too specific to core
<RP>
JaMa: a list of the issues you're finding might be helpful so we know which exclusions to consider dropping
<RP>
my reasoning is core is basically done and it would be better to be more widely useful
<JaMa>
e.g. do_generate_toolchain_file_append_class-native was skipped due to "file_append" in the exceptions
<JaMa>
but hard to imagine what were the cases where you needed "file_append" in the exceptions
<RP>
JaMa: there are test cases with that name in core but this is why I'm thinking we should drop it
<JaMa>
but the same would happen in oe-core if here is do_generate_toolchain_file_append somewhere, right?
<vd>
qschulz my bad. So I guess the current syntax doesn't support override for do_rootfs[depends] += neither, does it?
<vd>
RP: my bad, I'm still not used to patches getting applied without a reply ^^
<qschulz>
vd: try do_rootfs_override[depends] I guess?
<RP>
vd: 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 :(
<qschulz>
or do_rootfs_override_append_override[depends] and check with bitbake -e but oof, not sure it's ideal :)
<qschulz>
RP: I don't know if patchwork can do this for you?
<RP>
qschulz: kind of but even that isn't working
<kergoth>
flags aren't propogated when overrides are applied. the flags will stay on the original variable name
<kergoth>
also bitbake -e doesn't show flag values
<qschulz>
kergoth: something to be added maybe then :)
<vd>
RP: 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? ;-D
<kergoth>
qschulz: the semantics aren't clear.
<RP>
we are not adding overrides to flags
<qschulz>
RP: pffff you don't know how to have fun
<kergoth>
the behavior would be unintuitive no matter how we implement it
<kergoth>
when does a flag value replace vs alter an existing value?
<kergoth>
it's a mess, no
<qschulz>
I was talking about adding the flag value to bitbake -e :)
<RP>
vd: if only it were that simple ;-)
<qschulz>
Two topics at once, not easy :p
<RP>
adding flags to bitbake-getvar would be the right question
<kergoth>
bitbake -e's output is actually coming from a function that's used in a bunch of places
<kergoth>
yeah, thats what i was going to suggest too :)
<kergoth>
could just make it accept flag syntax. bitbake-getvar 'do_rootfs[depends]'
<vd>
what is the proper way to add a dependency to task for an override then?
<kergoth>
vd: like i suggested earlier, use an intermediate variable if you need to
<vd>
kergoth ho ok that's nice, ${FOO} can safely be empty I presume?
<kergoth>
exactly, yes
<vd>
kergoth: if foo.bb has FOO = ""; do_foo[bar] += "${FOO}" and foo.bbappend has FOO_override = "something else
<vd>
", will do_foo[bar] contain "something else"?
<kergoth>
if override is in OVERRIDES, yeah. doesn't matter if its in a bbappend or not, bbappending is basically concatenation
eduardas has quit [Quit: Konversation terminated!]
<vd>
kergoth 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.
<RP>
vd: Small tip is to do something like OVERRIDES .= ":mc-${BB_CURRENT_MC}" since mc-XXX is much more unique than variable mc names
<kergoth>
good point. i wish we'd namespaced our existing overrides to avoid conflicts :)
<RP>
kergoth: we have tried to learn from that since!
<RP>
(task-, pn-, tune- but not img-, bad RP)
<vd>
RP: thank you!
bps has quit [Ping timeout: 268 seconds]
mckoan is now known as mckoan|away
<vd>
The variable system of OpenEmbedded is very powerful, but I wish the scopes were somehow explicit and obvious (local > auto > multiconfig > machine > distro > image > package > ...)
<kergoth>
that layering is essentially encoded both in variables via overrides and in the configuration data in the order of the inclusion of the config files
<kergoth>
not 100% since local.conf *has* to be before machine/distro, but..
<vd>
yeah the tricky part in the OE learning curve is knowing if a given config file can override a variable or not
<vd>
But I have absolutely no idea how you could make the scope of a variable obvious...
jmiehe has joined #yocto
<jordemort>
is there a way to "disinherit" a class from a .bbappend?
<kergoth>
nope
<kergoth>
vd: 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 helpful
<kergoth>
course thats not new anymore, just still seems that way to me :)
<override>
trying to understand what a sysroot is
florian has quit [Quit: Ex-Chat]
florian has joined #yocto
florian has quit [Ping timeout: 265 seconds]
florian has joined #yocto
Tokamak has joined #yocto
florian has quit [Ping timeout: 252 seconds]
jmiehe has quit [Quit: jmiehe]
otavio has joined #yocto
yocti` is now known as yocti
LetoThe2nd has quit [Quit: Connection closed for inactivity]
florian has joined #yocto
florian has quit [Ping timeout: 258 seconds]
Tokamak has quit [Ping timeout: 258 seconds]
<vd>
funny, _append_override or _override_append works the same, it's a bit confusing
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
Tokamak has joined #yocto
bps has quit [Remote host closed the connection]
bps has joined #yocto
bps has joined #yocto
<vd>
is one syntax preferred over the other?
<smurray>
RP: 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)
<vd>
how do you choose between writing an image feature vs. writing a class to inherit from?
florian has joined #yocto
<rber|res>
vd, why do you think _append_override or _override_append works the same?
<JaMa>
RP: 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/
ant__ has joined #yocto
<vd>
rber|res you're right, they aren't the same. I'm even more confused now
<vd>
rber|res ok I get it, thank you.
Vonter has quit [Ping timeout: 276 seconds]
<vd>
Can you force a package version from a configuration file?
<rber|res>
vd, which sets many things to AUTOREV -> latest and greatest
<rber|res>
vd, e.g. PREFERRED_VERSION would work
<vd>
rber|res: perfect!
<rber|res>
vd, you had also a question about FEATURE vs. class
<rber|res>
vd, in my mind those are different things ;)
<rber|res>
vd, there are IMAGE, MACHINE, DISTRO features
<vd>
rber|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.
<vd>
s/simply with/simply write/
<rber|res>
vd, so you build the same image with different versions of components?
<rber|res>
vd, I guess PREFERRED_VERSION would work then.
<rber|res>
vd, if you also want to build things differently you could introduce a FEATURE, check in your recipes for this FEATURE and build things accordingly
<vd>
rber|res: exactly. unfortunately different customer use different firmware versions, so I must support them all.
<rber|res>
vd, hehe yes I have many customers who need stuff like that ;)
<vd>
can PREFERRED_VERSION be set at the image recipe level?
<rber|res>
vd, Yocto chant number 1 (I think): config data is global, recipe data is local
<rber|res>
vd, I guess you want it in a config file and not in your image recipe
<vd>
yep, hence the multiconfig per combination is preferred
<vd>
rber|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.
<vd>
s/just/sure/
<rber|res>
vd, I see as class as something which you define once and it's used multiple times, like cmake.bbclass
<rber|res>
vd, if you inherit this in your recipe, the recipe knows about cmake and does it's steps accordingly
<vd>
hum, and since I'm customize rootfs overlays and stuffs like that, I guess these are local image FEATURES, not a sharable functionality across images.
<rber|res>
vd, kernel command line tweaks: I would just create a .bbappend e.g. to the boot loader environment
<rber|res>
vd, IMAGE_FEATURES can be across all images
<vd>
well 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.
<rber|res>
vd, 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 keys
<rber|res>
vd, seems to be similar with ROOTFS_POSTPROCESS_COMMAND ;)
<vd>
rber|res I see. I use both to embed the initrd and overlays inside the rootfs.
<rber|res>
vd, there you see e.g. if IMAGE_FEATURES contains debug-tweaks then do this, otherwise that
<vd>
rber|res the naming is confusing, is this class implementing ROOTFS_POSTPROCESS_COMMAND or only relying on it?
<vd>
I feel like it's the latter, hence image-features.bbclass would've been more appropriate
<rber|res>
vd, it just does ROOTFS_PROCESS_COMMANDS based on image features
<vd>
In other words, this class is where you implement new upstream image features?
<RP>
smurray: that would match the cases we've see as it is usually buildtools which is 3.9
<vd>
you don't need to declare them somewhere else
<rber|res>
vd, nope
<smurray>
RP: yeah
<RP>
JaMa: I think we only had one case of that in core and the same variable. We could add special handling for it
<rber|res>
vd, 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 recipes
sakoman has joined #yocto
<vd>
rber|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_COMMAND
<rber|res>
vd, your custom features could trigger things in your custom classes or recipes
<vd>
in 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)
<vd>
I 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 on
<rber|res>
vd, yep
<rber|res>
vd, and with BACKFILL you can remove features from a list ;)
<vd>
ho, I was using DISTRO_FEATURES_remove = "nfs", is it bad? :D
<rber|res>
vd, you could have FEATURES which all your customers want except for one, or which don't work on a special hardware
<rber|res>
vd, RP will tell you what is the punishment for this ;)
<RP>
rber|res: I'm mainly against using remove in oe-core
<vd>
rber|res ho damn, I think you just opened a door in my mind, I might now sleep tonight :D
<rber|res>
vd, good - normally this only happends after lots of alc with my brain ;)
<vd>
rber|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 accordingly
<rber|res>
vd, idealle you clould see MACHINE as something hardware near
<rber|res>
vd, ideally
<rber|res>
vd, hardware supports bluetooth is in my mind a MACHINE feature
<rber|res>
vd, but in order to use bluetooth you also need a few user space apps and daemons
<rber|res>
vd, so this would be a DISTRO feature
<rber|res>
vd, normally both need to exist e.g. to turn on things on kernel level and to install/configure apps
<rber|res>
vd. but you might now want to use a non standard bluetooth stack and so on
<rber|res>
vd, it's pretty flexible
<vd>
so I would define a bbclass which looks for "bluetooth" in DISTRO/IMAGE_FEATURES and configure my preferred bluetooth stack?
<rber|res>
vd, you can actually grep for this, since this should exist ;)
<ant__>
there is indeed a relation between kernel config and machine features but afaik there is not yet a binding
<vd>
well an image could only decide which package to install, not set the preferred provider I presume
<ant__>
zeddii, maybe you did explore that thing
<rber|res>
vd, you could define MACHINE features in your machine config
<rber|res>
vd, qemu.inc:MACHINE_FEATURES = "alsa bluetooth usbgadget screen vfat"
<rber|res>
vd, default-distrovars.inc:DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth
<vd>
is it best to integrate existing features in your layer (e.g. "screen") or is it better to define your own features?
<vd>
(e.g. "myproduct-screen")
<ant__>
I'd say use features and split these between sibling machines
jwillikers has quit [Remote host closed the connection]
<vd>
Seems like a very powerful mess :D
<vd>
hum, with OVERRIDES = "override"; FOO = "A"; FOO_override += "B", FOO with be "B", not "A B", right?
<vd>
I must use FOO_append_override if I want to preserve the initial value of FOO if I'm not mistaken
<RP>
vd: correct
<vd>
in 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)
<rber|res>
vd, I am a bit confused now. You will have an image recipe which defines what it contains.
<vd>
rber|res I tried both IMAGE_INSTALL = "foo" or PACKAGE_INSTALL = "foo", but there are always non-foo files in the image
sakoman has quit [Read error: Connection reset by peer]
<rber|res>
vd, maybe dependencies?
<rber|res>
vd, I typically use a core-image-minimal and add stuff to it.
<rber|res>
vd, if you want something really minimal, like what's in a container this can be done as well.
sakoman has joined #yocto
<vd>
rber|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")
<vd>
maybe 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 format
<vd>
RP: thank you btw, it now explains why my image didn't boot anymore, IMAGE_BOOT_IMAGES_override += "somefile" wasn't what I initally thought ;)
<rber|res>
vd, so don't use packagegroup-core-boot ;)
<vd>
rber|res I had to use VOLATILE_LOG_DIR = "no" in my distro to workaround the systemd-nspawn calls ;-)
<rber|res>
Can we please punish upstream repo maintainers who remove the master branch and rename it to main ;) a right to compensation for personal suffering, etc.
<rber|res>
vd if you have systemd-nspawn you already have your overlays ;)
<vd>
rber|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/libfoo.so files)
<rber|res>
vd, and you are sure you want to do this yourself manually?
<vd>
rber|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"?
<rber|res>
vd, and BitBake uses by default "master" - I was searching a few hours now why a recipe did not build and was getting frustrated.
<rber|res>
vd, I REALLY did not think that someone renamed the master branch to something else and removed it.
<rber|res>
vd, we will have much fun with our recipes if this happens all over the place ;)
<vd>
makes 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...
<vd>
rber|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?
<rber|res>
vd, 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.
<rber|res>
vd, 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 rootfs
<rber|res>
vd, I guess a pkg which contains only foo and bar is what you might want.
<vd>
rber|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.
<vd>
But 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)
paulg has quit [Ping timeout: 258 seconds]
<rber|res>
vd, so you don't bundle it as a package, but just copy it over?
<rber|res>
Here it's getting 1:45 in the morning ;) So I guess I'll give up for tonight. CU
<vd>
rber|res currently I have this overlay.bb image doing IMAGE_FSTYPES = "squashfs"; IMAGE_INSTALL = "foo", and for rootfs.bb 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.
<rber|res>
vd, Yep understood
<vd>
my worries is the overlay.squashfs containing *only* the files from the foo package
* vd
will read rber|res's code ;)
<rber|res>
vd, the package manager will pull in runtime dependencies as well ;)
<vd>
yes this I don't want in the overlay squashfs :/