seninha has quit [Remote host closed the connection]
seninha has joined #yocto
Guest65 has joined #yocto
leon-anavi has joined #yocto
<Guest65>
Hi! I have a SRCREV question. The recipe fetches from an upstream git repo. After that 1 patch is applied. When checking with devtool modify xxx, the original git repo + 1 patch is applied (branch devtool). When I use SRCREV="${AUTOREV}" it works, but because it is not recommended I try with SRCREV="<upstream SHA1>". Then I get "basehash is not
<Guest65>
deterministic"-errors. If I try with SRCREV="<devtooled SHA1>", I also get basehash and/or fetch issues. What have I misunderstood?
ptsneves has joined #yocto
<qschulz>
Guest65: are you pasting all 40 characters in SRCREV?
<qschulz>
also no leading nor trailing space?
<Guest65>
Yes, e.g. SRCREV = "0bf86d03592f8ee6139559f0977df16a27d835ea"
<qschulz>
Guest65: mmm would you be able to share the recipe in a pastebin somewhere?
<qschulz>
what's PV set to for example?
<Guest65>
PV = "1.0+git${SRCPV}"
<qschulz>
first time I see the not deterministic error, usually it's written as "basehash mismatch| or something like that
<Guest65>
So it should work? I might have done something in the wrong order
<rburton>
share the recipe if you can, sounds like something went wrong. a recipe with a patch should work obviously :)
<Guest65>
I was just able to build if I started doing :
<Guest65>
bitbake -c cleanall -c cleanssate xxx
<Guest65>
<edit recipe with SHA1_upstream>
<Guest65>
bitbake xxx
<rburton>
fwiw cleanall/cleansstate are almost never needed, don't use them
<qschulz>
Guest65: mmm any chance you still had devtool'ed recipe in your workspace? since it is a bbappend applied on top of the recipe in your layers, maybe it messed up something?
<qschulz>
but yes, if you need cleanall/cleansstate to fix something, that recipe is seriously broken :)
<Guest65>
I better share it... I nee to google pastebin first :-)
thomasd13 has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
starblue has joined #yocto
<rburton>
Guest65: you won't need FILESEXTRAPATHS to be set but there's nothing in there that looks wrong. i'd check your workspace/ for anything like a lsdbus%.bbappend which might be changing the recipe
<rburton>
TRO[m]: nice!
<rburton>
Entei[m]: what are you trying to do? what bit is yocto?
goliath has joined #yocto
car1t has joined #yocto
mckoan is now known as mckoan|away
car1t has quit [Quit: leaving]
car1t has joined #yocto
seninha has joined #yocto
goliath has quit [Quit: SIGSEGV]
Thorn has quit [Ping timeout: 240 seconds]
camus has quit [Ping timeout: 264 seconds]
Thorn has joined #yocto
kpo_ has quit [Ping timeout: 264 seconds]
d-s-e has joined #yocto
lars has joined #yocto
lars is now known as Guest5379
<Guest5379>
Hello, I have for some reason trouble getting a clean fresh clone of poky kirkstone to build. Cmake-native fails and claims that g++ does not support C++11 and the specified C++ flags. Any ideas? My gcc is 13.1.1 so it should be new enough to build cmake
<Guest5379>
I have done absolutely nothing to the repo after I cloned it, there are no local modifications
prabhakarlad has quit [Quit: Client closed]
<RP>
Guest5379: which host OS are you using? Something new?
<RP>
Guest5379: well, since you say gcc 13 it has to be. Things don't work on gcc13 yet out the box
<Guest5379>
I'm on Arch
<Guest5379>
When you say things don't work "out of the box" yet, does that imply that there is something I can do to make it work?
<RP>
Guest5379: disable uninative
<Guest5379>
How do I do that?
<RP>
guessing you have meta-poky/conf/distro/poky.conf:INHERIT += "uninative" ?
<RP>
disable that
gsalazar has joined #yocto
<Guest5379>
Seems to be working. Thanks
<Guest5379>
Are there any side effects of doing this that I should be aware of?
<RP>
Guest5379: sstate isn't sharable between different machines
<Guest5379>
Okay, I can live with that
kalj has quit [Quit: Client closed]
gsalazar has quit [Remote host closed the connection]
kpo_ has joined #yocto
Zaid has joined #yocto
<RP>
abelloni: is your gcc 13 branch somewhere?
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<Guest65>
rburton there's an lsdbus%.bbappend that reference the patch-file.
<Guest65>
I removed name=lsdbus;, use SRCREV="<upstream_SHA1>" and it worked as I wanted .The patch was applied (as you all said).
<Guest65>
So now everything is working as I wanted it to.
<Entei[m]>
<rburton> "Entei: what are you trying to do..." <- The bit where I am not sure what I am doing wrong...sorry. How do I get podman working on yocto?
nemik has quit [Ping timeout: 248 seconds]
goliath has joined #yocto
nemik has joined #yocto
<rburton>
do you mean "i've built an image with yocto and i want to use podman in it"
<rburton>
in that case, you need to install the fuse kernel module, like the error says
<Guest65>
I do not understand why I've had so many issues with "basehash".In my conf/local.conf I have INHERIT += "rm_work" and I had BB_SERVER_TIMEOUT = "3600".
<Guest65>
Sometimes I feel a bit uncertain if those two cause extra issues.
<rburton>
that server timeout is quite high, i just use a minute. but rm_work is definitely safe.
<Entei[m]>
rburton: I don't have much knowledge of this particular thing tbh. Is fuse just supposed to be package or I have to edit my Kconfig to enable it?
<Entei[m]>
jetm has joined #yocto
<Guest65>
Great. My disk space is limited. I was desperate to shorten the time of recipe parsing, but after getting rid of the AUTOREV's, it's fast enough (y)
<rburton>
Entei[m]: make sure your kernel config actually enables fuse, and then ensure you actually install the kernel-module-fuse packages into the image. you can install _every_ kernel module build by adding 'kernel-modules' to the image if you want.
camus has joined #yocto
<Entei[m]>
rburton: I see. I'll try it out. Thanks
<rburton>
Entei[m]: feel free to send a patch to the podman recipe if you found more module depends, it lists a few already
<Entei[m]>
Will do as soon as I get it working
<RP>
abelloni: found khem's patches on his branch
<abelloni>
ah sorry, I wasn't paying attention here
<abelloni>
I can push a branch if required
<RP>
abelloni: I think master-next should be ok now
<mcfrisk>
what is the yocto way of enabling kernel features like seccomp, CONFIG_SECCOMP? DISTRO_FEATURE enables the support in userspace, but not kernel. Then default linux-yocto kmeta has broken config file for seccomp, or it looks like that to me. A custom config fragment in my layer to enable CONFIG_SECCOMP=y to linux-yocto, in our layer?
bunk has joined #yocto
<rburton>
mcfrisk: fix the seccomp file if its broken, but yeah a custom fragment is the answer
<mcfrisk>
rburton: ok, I think I could send the config fragment to oe-core and make it enabled on DISTRO_FEATURE seccomp
Zaid has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
d-s-e has quit [Ping timeout: 265 seconds]
kscherer has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has joined #yocto
<jbo>
Hey guys, the WIC I'm currently getting out of bitbake has two partitions as usual. I'm trying to figure out how I could add a 3rd partition for on-device data storage. However, I'm struggling figuring out what the minimal setup would look like by reading the docs. could somebody point me towards the right direction? I'd just like a 3rd partition which will be empty in the WIC so the device has something to store data on itself.
<rburton>
my understanding is you just define a new partition in the wic and don't tell it to fill it with an image
<JPEW>
jbo: I think adding a line like `part /userdata --size=1G --fstype=ext4 --label userdata` will do it
<jbo>
that would be more or less what I understood as well. However, I'm unclear what would need to happen in my custom layer to "automate" this
<JPEW>
jbo: The main key is to omit the `--source` option
<rburton>
"automate"?
<jbo>
JPEW, that is good info, thanks!
<jbo>
rburton, yeah, I'd like to end up with a WIC which I can flash just like now (using dd).
<rburton>
just add that line to your wic and you're good
<jbo>
then I might be lacking the understanding of what "your wic" is.
<jbo>
so far I just run bitbake and get a *.wic out of it :D
<jbo>
automagically
<rburton>
there is no implicit wic, but some BSPs have a default wic
<rburton>
change that, or write your own
<jbo>
rburton, when you're referring to "wic", is that a/the tool, the resulting image, some recipie, ... ?
<JPEW>
jbo: Your image recipe keys off the WKS_FILES variable to know which .wks file to use to generate the disk image; you can double check which one it's using with `bitbake -e`
<jbo>
JPEW, thanks! I used grep instead but I guess I should start using bitbake -e more when I try to figure out how things work
<JPEW>
Right. So you can modify the .wks file it's using, or write your own and change `WKS_FILES` to point to it
<jbo>
I'll probably write my own as that seems more proper (correct me if I'm wrong). however, I don't have a custom machine config yet.
<JPEW>
You probably want your own
<JPEW>
You can also set it in your image recipe, if you already have a custom image recipe
<jbo>
I do have that!
<jbo>
I have custom image & distro stuff by now. I guess custom machine is the last thing missing :)
<JPEW>
jbo: Depends on what you are doing, but ya
<jbo>
JPEW, well it's a custom board I designed so I think it's more than warrented. just didn't do that yet as I am completely new to yocto
<jbo>
thanks for the information on the WKS file. that is exactly what I was looking for!
<JPEW>
jbo: We try not to use custom machines unless we are actually doing our own hardware, so for example when we do our build for a RPi4, we us the upstream machine
<JPEW>
jbo: Ya, if you have a custom board you should have a custom machine to match
<jbo>
jup
<jbo>
I'll digg into that now that I know that the hardware is actually working. I was struggling quite a bit with the audio codec I slapped on the board and the LTE modem. but I managed to finally get everything sorted out. kinda weird to have a rev 1.0 where everything is working :x
<JPEW>
_batman voice_: First try!
jtoomey has joined #yocto
<jbo>
heh :)
<jbo>
certainly took me longer to understand some of the basic yocto concepts than to design & assemble the PCB
<LetoThe2nd>
jbo: eventually that will change. but also, eventually not.
<jbo>
LetoThe2nd, as a C++ dev I am used to spending well over a decade on some tech and still feeling like I don't understand any of it :D
<jbo>
or would I have to copy all those / copy-paste their contents into my custom machine config?
<LetoThe2nd>
jbo: you can require/include, it just needs the full path in the layer then, which is not the case if both files are in the same layer. then a relative path is fine.
<jbo>
LetoThe2nd, is that a "traditional UNIX relative path" or is there some fancy syntax involved?
<LetoThe2nd>
jbo: now that you ask, i actually don't know if the .. operator is supported.
<jbo>
heh...
<jbo>
for example, in my custom bblayers.conf.sample I have ##OEROOT## to reference some top level dir.
<JPEW>
jbo: bitbake searches BBPATH for relative include/requires, so `require conf/machine/include/samad52.inc` should work
<JPEW>
No need to reference relative to OEROOT or the current file
goliath has quit [Quit: SIGSEGV]
<JPEW>
well, as long as you use the correct file name, which my example did not :)
<jbo>
I spotted that ;-)
<jbo>
alright, now bitbake is complaining about my custom machine not being listed in COMPATIBLE_MACHINE for the kernel. The manual section 6.2 talks about that but I don't actually have a defconfig file. I do have a .cfg file where I set kernel specific configs tho.
<jbo>
from manual section 6.2 it's unclear to me where COMPATIBLE_MACHINE would need to be specified.
bunk has quit [Quit: leaving]
<JPEW>
It's not uncommon for a BSP to use a bbappend to add to COMPATIBLE_MACHINES for upstream kernels...
<JPEW>
It looks weird to use the machine override to set it to the machine, but it keeps the layer "Yocto compatible" (e.g. it plays nice with other layers)
<jbo>
wait... why is this: COMPATIBLE_MACHINE:<machine>: "<machine>" that seems weird - or is that exactly what you meant with "looks weird"? :D
<JPEW>
Ya, thats what I mean
<JPEW>
The naive (but still functional) way would be `COMPATIBLE_MACHINE += "<machine>"`
<JPEW>
But that technically changes the parsing of the recipe for other machines, which is not "Yocto compatible"
<jbo>
hmm. I see
<JPEW>
(There is a script you can run to check your layer for such things)
<jbo>
well, it seems like I need some extra steps in my setup. after adding that COMPATIBLE_MACHINE:custom = "custom" line the previous complains about the kernel are gone. However, now it's complaing about "at91bootstrap was skipped: incompatible with machine synature (not in COMPATIBLE_MACHINE)"
<JPEW>
The basic idea is that a layer should modify the parsing of any recipes it doesn't provide itself (e.g. in bbappends), unless the user opts into a machine or distro provided by that layer
<jbo>
I tried adding a 2nd COMPATIBLE_MACHINE:custom = "at91bootstrap" but that didn't seem to be the way to go
<jbo>
JPEW, that does seem reasonable
<JPEW>
Probably also need a bbappend for at91boostrap?
<jbo>
why would I need a bbappend for at91bootstrap when I add a custom machine?
<jbo>
oh, you mean just for the COMPATIBLE_MACHINE sake?
<JPEW>
Ya, just like the kernel
<jbo>
in situations like this right now, I find myself not knowing where that bbappend file would need to be located in my custom layer. how do I properly figure that out without guessing?
<JPEW>
Match the same path as the original recipe, just in your layer
<jbo>
so what I did now is grep the vendor's layer and deducing the path from that - that is the correct way of doing things?
<JPEW>
Ya pretty much
<JPEW>
`find . -name 'at91bootstrap*'`
<jbo>
alright, that got me further. now it complains about the same for u-boot-at91 so I guess more of this :D
<paulg>
anyone seen a systemd based initramfs/initrd .bb example before? (vs /init just being a quick-and-dirty script)?
<JPEW>
Ya
<JPEW>
paulg: Can you elaborate? We use systemd with a custom /init script; you just exec the systemd /init to have it take over when you are done (same as sysvinit FWIW)
<JPEW>
jbo: COMPATIBLE_MACHINE actually matches anything in MACHINEOVERRIDES, so some recipes will be nice and be compatible with ${SOC_FAMILY) so you don't have to do that
<paulg>
JPEW, so it is a chicken and egg thing. The systemd has its own parsing tool for setting up dm-verity stuff from bootargs.
<paulg>
but that tool isn't available unless systemd and the assoc helper tools are in the initramfs. Because they are in the dm-verity protected rootfs. :(
<JPEW>
Ah, you want an initrd with /init handled by systemd so it can setup the rootfs and chain to itself?
<JPEW>
paulg: Ya, I think it supports that, but I've not done it before
<paulg>
I'm just unsure if I'm brave enough to try going down that road... vs. more manual setup steps in the shell variant of /init we (yocto) normally use with core-image-minimal
<JPEW>
paulg: It actually looks pretty straight forward TBH; just make the initrd a normal image with systemd and it knows its in an initrd because of the /etc/initrd-release file
<JPEW>
And when you are done, run `systemctl switch-root`?
<paulg>
I've learned to never assume anything involving systemd will be easy or straight forward...
<jbo>
JPEW, I got quite a bit further with this. but I am currently not understanding this bitbake error: ERROR: at91bootstrap-4.0.6+gitAUTOINC+d166742ae1-r0 do_configure: No config files found I created meta-custom/recipes-bsp/at91bootstrap/at91bootstrap_%.bbappend which only contains COMPATIBLE_MACHINE:custom = "custom" is there some other magic missing I'm not yet familiar with?
<JPEW>
paulg: It can be if you go off the rails of what they expect
<paulg>
I'll probably give it quick try, and if it all goes pear shaped, I'll simply walk away.
<JPEW>
jbo: Probably something with that specific recipe?
<JPEW>
jbo: Looks like it's expecting you to provide something for your machine (maybe some variable that says which config to use)? IDK much about that
<jonmason>
RP: a quick/dirty look doesn't show anything actively using it. let me try ripping it out and see who complains
<JPEW>
paulg: Now that you pointed me here, I'm tempted to switch our initrd to use systemd :)
<paulg>
JPEW, heh. Wasn't my intention of course.
zpfvo has quit [Quit: Leaving.]
<jbo>
JPEW, thanks for mentioning that. I digged around and spotted a missing AT91BOOTSTRAP_CONFIG:custom adding that got me a bit further :)
<rburton>
khem: so networkmanager was broken before i touched it - it appears to depend on pygobject being on the host
d-s-e has quit [Quit: Konversation terminated!]
Minvera has joined #yocto
florian__ has joined #yocto
ardo has joined #yocto
<jbo>
JPEW, so I made quite some progress on the custom machine config. But I've been stuck now for quite some time and don't know anymore what to check for. bitbake complains about not being able to complet do_image_wic. It complains about uboot.env missing from the build/tmp/ directory. any pointers on what to look for?
frieder has quit [Remote host closed the connection]
ardo has quit [Ping timeout: 240 seconds]
<JPEW>
job: Check out WIC_DEPENDS
<JPEW>
maybe
<JPEW>
^^ jbo
<jbo>
JPEW, well, so far I just want to have a custom machine config which does exactly the same as the vendor provided one for their EVK so I just copied their machine config. In there there is this: do_image_wic[depends] += "u-boot-at91:do_deploy"
<jbo>
is that what you're referring to?
ardo has joined #yocto
kpo_ has joined #yocto
<JPEW>
jbo: Ah, yes. Sorry
kpo_ has quit [Ping timeout: 240 seconds]
<JPEW>
"A particular BSP" made a WIC_DEPENDS variable to encompass that :)
<jbo>
JPEW, that would be meta-atmel/recpies-bsp/u-boot/u-boot-at91_2022.10.bb I already created a meta-custom/recipes-bsp/u-boot/u-boot-at91_%.bbappend where I only added the COMPATIBLE_MACHINE:custom = "custom" line to it. I fail at figuring out what else is necessary. I did a grep for 'WIC_DEPENDS' within meta-atmel and nothing showed up. kinda out of ideas :(
Thorn has quit [Quit: Relax, its only ONES and ZEROS!]
<jbo>
I've also searched the yocto documentation for WIC_DEPENDS (and out of desparation WKS_DEPENDS) and nothing showed up there either.
Thorn has joined #yocto
<JPEW>
jbo: It's do_image_wic[depends], I was mistaken
<jbo>
but in any case I don't know what I have to do in general tbh :D
<jbo>
JPEW, well, the `do_image_wic[depends]` line is in my custom machine config (copied from meta-atmel machine config): do_image_wic[depends] += "u-boot-at91:do_deploy
florian__ has quit [Ping timeout: 240 seconds]
<jbo>
meh, I'll try again tomorrow.
BWhitten has joined #yocto
aardo has joined #yocto
<JPEW>
jbo: Not sure then, sorry
ardo- has joined #yocto
ardo has quit [Ping timeout: 240 seconds]
aardo has quit [Ping timeout: 240 seconds]
zenstoic has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
florian__ has joined #yocto
ptsneves has quit [Ping timeout: 240 seconds]
leon-anavi has quit [Quit: Leaving]
<JPEW>
though because DEPENDS _does_ work so somehow it knows how to find the sysroot for a recipe without knowing it's exact ${PACKAGE_ARCH}... I can't quite figure out how though
<JPEW>
RP: Theory on the SPDX problems: Currently, SPDX documents are deployed to `${DEPLOY_DIR}/spdx/${MACHINE}/`, when perhaps they should be `${DEPLOY_DIR}/spdx/${PACKAGE_ARCH}/`; I think this would probably fix the multilib and SDK issues? The problem it introduces is that now do_create_spdx can't find another recipe's document because it doesn't know the ${PACKAGE_ARCH} for that recipe. Presumably this is a actually a solved problem somewhere
<rburton>
pkgdata probably knows
Thorn has quit [Ping timeout: 246 seconds]
car1t has joined #yocto
vmeson has quit [Read error: Connection reset by peer]
<JPEW>
rburton: It does not
<JPEW>
Perhaps could though?
vmeson has joined #yocto
kpo_ has joined #yocto
<JPEW>
mmm, pkgdata also doesn't appear to be defined for -native recipes
alessioigor has quit [Quit: alessioigor]
<RP>
JPEW: would SSTATE_PKGARCH be more appropriate?
<RP>
JPEW: the sstate code already has what I think might be needed here
<JPEW>
RP: the anon code that munges is based on inherits_class ?
<JPEW>
*munges is
<JPEW>
*munges it
<RP>
JPEW: yes. There is magic which allows it to look up the pkgarch of a dependency iirc
<RP>
deep magic :/
<JPEW>
find_sstate_manifest?
Thorn has joined #yocto
<RP>
JPEW: yes, it isn't what I was thinking it does
<JPEW>
It returns a datastore for the target recipe I think?
<JPEW>
well.... target task
<RP>
JPEW: no, it can't do that
<RP>
JPEW: it can apply multilib overrides to an existing datastore
<JPEW>
Ah, I see
<JPEW>
It loops over all pacakges arches until it finds a matching manifest file... can it return the pkgarch for the manifest it found as well?
<RP>
JPEW: it is basically constructing a search path and it looks for the manifest through each in turn
<RP>
JPEW: we could certainly refactor things a little to do that
<JPEW>
Or factor that out to a new function would also work I think
<RP>
JPEW: right, that was what I was thinking
<RP>
There is something nagging me that we could do this in a better way
<JPEW>
Seems like it should be possible
<JPEW>
Does the MACHINE -> PACKAGE_ARCH seem like it is probably the issue in the first place though?
<RP>
JPEW: That was my conclusion last time I looked at this, yes
<RP>
JPEW: the other trick I'm thinking of is BB_HASHFILENAME (see sstate.bbclass)
<RP>
JPEW: currently it is just used by the scenequeue data but I'm wondering what if that was combined with the TASKDEPS structure