<Harun>
IMAGE_LINGUAS can be used to specify needed locales in an image.
<Harun>
Is there a list which lists every locale, so that I can choose the needed ones?
<Harun>
Without it I have to guess :(
GNUmoon2 has quit [Ping timeout: 276 seconds]
JaMa is now known as Guest9634
JaMa has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dwagenk>
<ziga_> "I create a Yocto image,, mount..." <- does your SD-Image have a seperate "boot" or "firmware" partition? /boot may be populated in the rootfs, but depending on the classes used for building the SD-Image (triggered by what is in the IMAGE_FSTYPES variable) the contents may be copied to a different partition or "magic" postitions (without partition) on the SD card to match what your hardware expects. kn these cases the content of /boot in
<dwagenk>
the rootfs might be irrelevant for the boot process.
rob_w has joined #yocto
<ziga_>
@dwagenk Can you elaborate a bit ore on the topic. I don't understand yet.
<ziga_>
@dwagenk My SD card has two separate partitions yes. First there is /boot and there is /root. It seems that /boot is NOT mounted inside the /root/boot (which I don't understand why this is the case) - If I open /boot and /root/boot their content does not match. How can I solve this?
<coldspark29[m]>
Seems like it is not that big of a problem, because the kernel build finished successfully
rfuentess has joined #yocto
goliath has joined #yocto
zpfvo has joined #yocto
Vonter has joined #yocto
frieder has joined #yocto
<dwagenk>
<ziga_> "@dwagenk My SD card has two..." <- /boot is probably the relevant partition. see if modifications there (deleting the relevant dtb or kernel image) will cause the boot to fail.
<dwagenk>
look at the bbclass file for your IMAGE_FSTYPE that generated the sd image, maybe that can give more clues?
<dwagenk>
and regarding fixing: if you need /boot mounted in the rootfs you can use IMAGE_POSTPROCESSING_COMMAND (I don't have the exact naming on hand) to add it to the fstab. same mechanism might be helpful for clearing out the boot directory contained in the rootfs to prevent future confusion.
<dwagenk>
and if your image creation is using wic/wks files (search in the docs) you can also specify mount points and directories to exclude in there.
<coldspark29[m]>
In the end I did the patching manually
<coldspark29[m]>
and built that version
rfuentess has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
dev1990 has joined #yocto
xantoz has quit [Ping timeout: 256 seconds]
tnovotny has joined #yocto
prabhakarlad has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
Guest9634 is now known as JaMa2
Etheryon has joined #yocto
<Etheryon>
Hi All, I'm trying to build a dunfell version of poky, but I currently have python 3.10 installed which gives an error on imports. Any ideas how to solve this?
zyga-mbp has joined #yocto
<qschulz>
Etheryon: can you share the error?
<qschulz>
and which version of dunfell you're trying to build
<fabatera[m]>
Hi all, I'm using devtool to develop a c++ app. But it is a pain to build and wait for bitbake to do the cache load, parse recipes etc until the compilation errors are fixed. Can you recommend a better approach?
<fabatera[m]>
When the compilation is OK, I can devtool build and deploy to a qemu instance.
<dacav>
gcc-source-9.3.0 was skipped: incompatible with host arm-xilinx-eabi (not in COMPATIBLE_HOST)
<dacav>
but then...
<dacav>
COMPATIBLE_HOST="[^-]*-[^-]*-eabi"
<dacav>
and it looks to me that 'arm-xilinx-eabi' does matchi it
<dacav>
uhm... COMPATIBLE_HOST is actually empty for the gcc-cross-arm recipe.
florian_kc has joined #yocto
Harun has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
Skinny79 has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
tnovotny has quit [Quit: Leaving]
Vonter has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
Vonter has quit [Ping timeout: 268 seconds]
jsbronder has quit [Quit: WeeChat 3.2]
jsbronder has joined #yocto
sakoman has joined #yocto
jsbronder has quit [Remote host closed the connection]
jsbronder has joined #yocto
jsbronder has quit [Client Quit]
Vonter has joined #yocto
jsbronder has joined #yocto
<Skinny79>
Hi! I followed the steps in the docs regarding building a custom kernel configuration : https://www.yoctoproject.org/docs/3.1/kernel-dev/kernel-dev.html#configuring-the-kernel where I know have a defconfig file in 'meta-custom/recipes-kernel/linux/linux-yocto' and a 'meta-custom/recipes-kernel/linux/linux-yocto_%.bbappend' file which add that
<Skinny79>
defconfig to the build. Any typos in the .bbappend file trigger an error so I know it's picked up. However the resulting .config file in 'tmp/work/genericx86_64-poky-linux/linux-yocto' is still the default one and doesn't have my options set or unset. What am I not seeing ? TIA!
<ziga_>
On beaglebone Black I managed to use patch to add "/arch/arm/boot/dts/fotovolt.dts" file and also modify "/arch/arm/boot/dts/Makefile" so that it also compiles the .dts file. "fotovolt.dts" file only includes the "am335x-boneblack.dts" file and changes the "model". Everything compiles and in the end my image has fotovolt.dtb file there. But boot fails! WHY? I tried comparing the "am335x-boneblack-dts" with the decompiled "fotovolt.dts" and
<ziga_>
they are IDENTICAL except for the model. Yet with "fotovolt.dts" Beaglebone Black will not boot. What else do I need to do? My machine has "KERNEL_DEVICETREE = "fotovolt.dtb" set...
zpfvo has quit [Ping timeout: 240 seconds]
jatedev has joined #yocto
zpfvo has joined #yocto
jsbronder has quit [Quit: WeeChat 3.2]
akiCA has joined #yocto
jsbronder has joined #yocto
ardo has quit [Ping timeout: 250 seconds]
ardo has joined #yocto
Vonter has quit [Ping timeout: 250 seconds]
paulg has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
codavi has joined #yocto
akiCA has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
prabhakarlad has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
Tokamak has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
xmn has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
Vonter has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
manuel1985 has joined #yocto
<manuel1985>
Any ideas why poky is stuck on gtk+3? IIRC gtk4 was released in late 2020.
<tdz>
I'm having issues with git fetcher. If we have long workspace path (long jenkins job name in our case) it can happen that git fetcher when trying to create lockfile in downloads/git2/<workspace_path>.lock will hang due to "File name too long" because it might exceed the limit of 255 characters.
<tdz>
and this ud.path contains the whole path twice (first the path to /<long_path>/build/downloads second to git repository (also containing path)).
<tdz>
Do we really need the whole path there? Which way should I go with the fix? Cut the directory name in half or maybe change it to less human readable hash? I need some advice.
<tdz>
this code is inside bitbake/lib/bb/fetch2/git.py
davidinux has quit [Ping timeout: 250 seconds]
<jsandman>
Hi all. Does someone know a way to collect all src revisions for components set to AUTOREV before building everything? I've been doing it with the buildhistory mechanisim but It appears to be risky when building multiple machines at once as a commeit can make it in while the builds are happening
davidinux has joined #yocto
<ziga_>
On beaglebone Black I managed to use patch to add "/arch/arm/boot/dts/fotovolt.dts" file and also modify "/arch/arm/boot/dts/Makefile" so that it also compiles the "fotobolt.dts" file. "fotovolt.dts" file only includes the "am335x-boneblack.dts" file. Everything compiles and in the end my image has "/boot/fotovolt.dtb" file. But boot fails! My "fotofolt.dtb" is IDENTICAL to "am335x-boneblack.dtb" (I verified with diff). Then I renamed
<ziga_>
"fotovolt.dtb" to "am335x-boneblack.dtb" and now it boots. I suspects that U-boot settings are set so that it searches for "am335x-boneblack.dtb" and because it does not find it it fails to boot. How can I change this U-boot setting permamently in Yocto? I don't want to just create a symbolic link in /boot directory of an image (I knmow this solution, but I don't like it)..
<qschulz>
ziga_: try without yocto. Boot your custom kernel+dtb from U-Boot
<qschulz>
once you know this is working, you might have a better idea what needs to be changed, and then you can check how to do this in Yocto
<qschulz>
jsandman: why do you want to collect SRCREV of AUTOREV recipes?
<ziga_>
@qschulz First I have to change U-boot settings so that boot stops at U-boot. How do I do that?
<qschulz>
ziga_: you should be able to enter the U-Boot shell by pressing any key when asked to do so
<qschulz>
if not, then change CONFIG_BOOTDELAY or something in your defconfig and rebuild (and flash) U-Boot
<jsandman>
Hi qschulz, I have a bunch of repos that are constantly moving and I want to be able to put together an .inc file similar to the one reported by buildhistory-collect-src-rev so I can freeze it all at one point.
<jsandman>
If I let my server buildinng all the machines I have setup, then the repos my get something in. Because of how this team works, it'd be very painful to go recipe by recipe and set a SRCREV
<vd>
hi there -- how can I extract the partitions of the .wic image? I need the individual parititions images (especially the vfat boot partition) for an update framework
<qschulz>
vd: I think it makes more sense to create the partitions' FS outside of wic and then use them in .wic. Not sure how to do that but that what comes to mind right now
<qschulz>
vd: also, please check what the update framework do and do not build your own
<qschulz>
mender, rauc, swupdate, others...
berton[m] has quit [Quit: Client limit exceeded: 20000]
jqua[m] has quit [Quit: Client limit exceeded: 20000]
<qschulz>
jsandman: you probably can run only the fetch command of all the recipes needed by your image recipe
berton[m] has joined #yocto
jqua[m] has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
<ziga_>
I assume that U-boot's "defconnfig" is somewhere in the /tmp/work/? I should probably patch it with a .bbappend file similarly as I patched the kernel? But which filče to patch? I found some files here "tmp/work/fotovolt-poky-linux-gnueabi/u-boot-ti-staging/1_2021.01+gitAUTOINC+15769936a5-r16/git/configs" and the one that I think is the most appropriate is this one "am335x_boneblack_vboot_defconfig". It has this line inside: "CONFIG_DEFAULT_DE
<ziga_>
VICE_TREE="am335x-boneblack" so probably this is the one but how can I verify? Does Yocto have any mechanism to ferify if this is the right file?
zpfvo has joined #yocto
<qschulz>
ziga_: UBOOT_MACHINE
<qschulz>
jsandman: --runall=fetch I think
<qschulz>
jsandman: other idea that comes to mind is to have a task that is not in the task tree (so not run by default) which is just going to dump the current latest commit to a file (your .inc file for example?)
Minvera has joined #yocto
<qschulz>
jsandman: though, if you have multiple machines, it's obviously still possible to have commits be pushed between those runs
<qschulz>
you can have them all happen at the same time by using multiconfig but phew, talk about overengineering :)
<jsandman>
qschulz, Yep... I'm already running the fetch and it may take a while. If I have to run it for all machines I may end up in the same situation :S
<qschulz>
jsandman: how come? do you have SO many recipes that pertains to only one machine?
<jsandman>
indeed! I just want to find a solution that is simple enough so I don't regret if I have to come back to fix something
<qschulz>
otherwise the tarballs you have in build/downloads (or whatever DL_DIR is set to) should be reused between runs
<jsandman>
that's true, it did not seem to use what's already in downloads. Or at least not for all components but this may be this environment. I have to look into that as well
<shoragan[m]>
<qschulz> "vd: I think it makes more..." <- Yes, that's what I'd suggest for RAUC. Use image recipes to build images. :)
<vd>
qschulz: shoragan[m]: that's the thing, RAUC needs a fixed-size binary image for the vfat bootloader partition... So far I'm dd'ing the first partition out of the wic image, but that's kinda ugly. The best would be that wic itself deployed the partition images it creates to DEPLOY_DIR_IMAGE (especially the vfat ones).
<vd>
shoragan[m]: I'm talking about the boot-mbr-switch type ^
<vd>
and OE has no "vfat" IMAGE_FSTYPES, so you gotta hack something.
<ziga_>
@qschulz UBOOT_MACHINE = "fotovolt" did not compile. It says "Configuration file ".config" not found! Please run some configurator (e.g. "make oldconfig" or "make menuconfig" or "make xconfig")." Is it the defconfig file that I am missing? Should I create it like ""tmp/work/fotovolt-poky-linux-gnueabi/u-boot-ti-staging/1_2021.01+gitAUTOINC+15769936a5-r16/git/configs/fotovolt_defconfig"? IT is weird, because it says that ".config" file is
<ziga_>
missing and in this folder there are only "_defconfig" files.
<shoragan[m]>
vd: Why not have an image recipe building a fixed size FAT image? Then the bundle depends on that.
<vd>
shoragan[m]: 1) OE has no (v)fat IMAGE_FSTYPES. 2) for the bootloader partition image you need the IMAGE_BOOT_FILES, not an image rootfs.
<shoragan[m]>
So that would be a good opportunity to add that, instead of using WIC to build a partition table and disk image, and then throw that away again.
<vd>
that's not a solution for 2).
<qschulz>
ziga_: you need to suffix it with _defconfig
<ziga_>
@qschulz Ok.
<qschulz>
vd: create a filesystem with the fiels listed in IMAGE_BOOT_FILES then and use this filesystem in wic?
zpfvo has quit [Ping timeout: 268 seconds]
<qschulz>
but before trying to do things in Yocto wrt FW upgrade, check what is suggested by the framework you're using, I doubt this is an unanswered question
zpfvo has joined #yocto
<vd>
qschulz: that's what we're talking about with shoragan[m], he's one of the framework authors ;-)
<shoragan[m]>
vd: you can also add IMAGE_CMDs locally
<qschulz>
vd: considering shoragan[m] popped up right when I said rauc, I assume they have something to do with it and have a notification when it's mentioned :D
<shoragan[m]>
with RAUC, i only use WIC for the initial factory disk image, if at all. all images that are needed for that and for updates are built with normal bitbake recipes.
<shoragan[m]>
it's much more flexible that way
<shoragan[m]>
qschulz: yep :)
<vd>
shoragan[m]: you would just end up rewritting what wic does
<vd>
qschulz: yep, that's how you invoke genius, you gotta rub the rauc lamp
<vd>
I'
<shoragan[m]>
vd: why? which builds a rootfs, splits that and generates a pratition table. none of that is needed for your FAT partition
<vd>
shoragan[m]: you can see a .wic image as a kinda flattened bundle, which is kinda cool. It's the closed to what you need deployed on a target medium, thus picking partition images and tarballs wic created to prepare the bundle is quite simple.
zpfvo has joined #yocto
<vd>
I'll get back to you
<kanavin>
RP: both qemuarm and qemuarm-alt, with additional systemd fails in the latter
Vonter has quit [Ping timeout: 268 seconds]
<shoragan[m]>
vd: to me, that doesn't make sense. and update would not include partition tables
<shoragan[m]>
s/and/an/
Vonter has joined #yocto
<vd>
shoragan[m]: true, I'm talking about abusing wic to generate the bundle slot images
frieder has quit [Remote host closed the connection]
<qschulz>
vd: remember that usually pieces of SW likes to not be dependent on the build system they are built with. Which means it makes sense for RAUC to have their own bundle image creation process
<qschulz>
so that it'd work with Buildroot or handcrafted build systems
<vd>
qschulz: true but the problem is that because we don't have yet a mechanism to bundle the IMAGE_BOOT_FILES individually, you need a machine-specific recipe for the boot partition, which isn't very OE-friendly (where images must be kept generic if possible while the IMAGE_BOOT_FILES is defined by the machine configuration).
<qschulz>
vd: not sure to understand the issue?
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rfuentess has quit [Remote host closed the connection]
<vd>
qschulz: with OE the (generic) machine configuration defines IMAGE_BOOT_FILES. If you want to update the boot partition with RAUC, you need to pack these file in a fixed-size partition image. You can 1) create a custom recipe which fallocate/mkfs.vfat/mcopy the files listed in IMAGE_BOOT_FILES, or 2) add a task to extract the boot partition with e.g. dd ibs=512 skip=1 ... into DEPLOY_DIR_IMAGE
<vd>
(which wouldn't be necessary if WIC did that already).
Tokamak has joined #yocto
zpfvo has quit [Quit: Leaving.]
<shoragan[m]>
vd: you could also add an image recipe for 1) to oe-core or meta-oe
<shoragan[m]>
or implement that feature in wic
<shoragan[m]>
oe-core is not set in stone :)
florian has quit [Quit: Ex-Chat]
<vd>
shoragan[m]: that's exactly what I'm discussing. I think the best is to patch wic to optionally deploy the images it creates during the process.
mckoan is now known as mckoan|away
lucaceresoli has quit [Ping timeout: 268 seconds]
manuel1985 has quit [Quit: Leaving]
ecdhe has quit [Ping timeout: 250 seconds]
ecdhe has joined #yocto
leon-anavi has quit [Ping timeout: 250 seconds]
<ziga_>
U-boot uses "CONFIG_DEFAULT_DEVICE_TREE" to set the default U-boot DTB, but which variable is used to set the DTB that U-boot passes to the kernel?
amitk has quit [Ping timeout: 240 seconds]
dkl_ has joined #yocto
iokill has quit [Ping timeout: 240 seconds]
dkl has quit [Read error: Connection reset by peer]
derRichard has quit [Ping timeout: 256 seconds]
Wouter0100 has quit [Quit: Ping timeout (120 seconds)]
iokill has joined #yocto
Wouter0100 has joined #yocto
derRichard has joined #yocto
Skinny79 has quit [Quit: Client closed]
leon-anavi has joined #yocto
Schlumpf has quit [Quit: Konversation terminated!]
leon-anavi has quit [Ping timeout: 268 seconds]
<Tartarus>
ziga_: It ends up being BSP-specific, you're best off examining the environment in the console to see what it ends up as
<ziga_>
@Tartarus Hmmm how do I check the environment?
florian_kc has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xantoz has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
bluelightning_ has quit [Remote host closed the connection]
bluelightning_ has joined #yocto
Tokamak has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
<Tartarus>
ziga_: In console, printenv
<Tartarus>
Not a bitbake thing, an on-target thing
<ziga_>
@Tartarus The "set" command reveals "HOSTNAME='fotovolt'".
<ziga_>
@Tartarus That's all.
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Minvera has quit [Remote host closed the connection]
Minvera has joined #yocto
<ziga_>
@Tartarus I executed "set" after I boot to my target.
reatmon has joined #yocto
rob_w has quit [Quit: Leaving]
dmoseley has quit [Ping timeout: 256 seconds]
bluelightning_ has quit [Quit: Konversation terminated!!!111]
mvlad has quit [Remote host closed the connection]
dmoseley has joined #yocto
bluelightning has joined #yocto
florian_kc has joined #yocto
<RP>
kanavin: we may need to check that prelink-rtld doesn't use the functionality which is being removed in glibc when we use it in introspection :/
<kanavin>
RP: yes, I was thinking that it needs to be replaced with something that can also list shared libraries but doesn't come from prelink tree
<kanavin>
I guess something from binutils or elfutils will do the job, but just needs to be tested and probably data massaging added
<RP>
kanavin: upstream might be ok with with a cross ldd too, I can't remember exactly what this is doing
<kanavin>
RP: yes, that should work fine. I think native ldd didn't work, and prelink-rtld back then was available and quick and easy to substitute
<kanavin>
why native ldd can't handle something for a different architecture I can't understand :-/ but whatevs
florian_kc has quit [Ping timeout: 240 seconds]
<smurray>
is it something that readelf can pull out?
<kanavin>
basically anything that can print the list of shared libs from an executable
<kanavin>
preferably same way as ldd does
Minvera has quit [Quit: Leaving]
florian_kc has joined #yocto
goliath has quit [Quit: SIGSEGV]
<vd>
Do you usually see overrides written like FOO:<machine>:<distro> or FOO:<distro>:<machine> or does it not matter at all?
<RP>
smurray, kanavin: from memory I think the issue is that it has to "link" the executable the same way it would be at runtime to work out what that list looks like. prelink does that as part of its processing anyway but I don't think ldd can do it for cross binaries
codavi has quit [Ping timeout: 250 seconds]
Tokamak has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sveinse has left #yocto [#yocto]
florian_kc has quit [Ping timeout: 240 seconds]
Dracos-Carazza has quit [Ping timeout: 256 seconds]
<kanavin>
RP: g-i seems happy with $OBJDUMP -p executable