<tomzy_0>
as env variables which are later used by bitbake
<tomzy_0>
to use correct paths
<JaMa>
bazel has nice "sstate" on steroids, but it takes a while to get used to it (and not sure if prior knowledge of OE helps or harms the experience :))
<tomzy_0>
this behavior seems to changed after update to kirkstone
<tomzy_0>
and we need to put those inside local.conf file for example
ccf has joined #yocto
<tomzy_0>
is this a known situation? we were able to just set env variables for those, like DL_DIR and TMP_DIR?
<JaMa>
tomzy_0: do you set BB_ENV_PASSTHROUGH_ADDITIONS ?
<JaMa>
tomzy_0: this variable was renamed in kirkstone
<LetoThe2nd>
JaMa: shouldn't those be in BB_ENV_PASSTHROUGH?
<tomzy_0>
hmm
<tomzy_0>
probably not
<JaMa>
see kirkstone migration documentation, if you didn't update this variable in your setup, then env variables won't work
<jclsn>
Morning
<JaMa>
but you should see a warning when old variable is still set (unless bazel eaten it)
<jclsn>
Firmware should be automatically loaded from /lib/firmware, shouldn't it? I have a broadcom .hcd file and I installed it to /lib/firmware/brcm, but it still isn't loaded on boot
<JaMa>
ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
<JaMa>
ERROR: Shell environment variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
<JaMa>
ERROR: Exiting to allow enviroment variables to be corrected
<tomzy_0>
is it possible that DL_DIR for example was there by default and no it is not?
<tomzy_0>
now it is not*
<LetoThe2nd>
tomzy_0: let me check a build
<JaMa>
it's not in openembedded-core/scripts/oe-buildenv-internal and I don't remember DL_DIR ever being there, but check in your old environment (as it might be added through some other places)
<jclsn>
Is there maybe some userspace tool needed to load the firmwares?
* mcfrisk_
remembers when bazel based builds started failing bitbake builds when build machines had different versions of some downloaded java dependencies in build users $HOME...
Joel55 has joined #yocto
<Joel55>
Good day folks! I'm getting this error when trying to install encrypted rauc updates "Failed to open /dev/mapper/control: No such file or directory". I believe I have the right config settings but for the life of me can't figure out if they are being used. For example, using "CONFIG_DMX_CRYPT=y" instead of "CONFIG_DM_CRYPT=y" doesn't produce any
<Joel55>
errors. And neither does introducing random strings into that config file.
<mcfrisk_>
Joel55: if you want to verify kernel config, then check the generated kernel-dev package for the config file, or after do_compile() in the build directory
chep has joined #yocto
xcm has joined #yocto
tangofoxtrot has quit [Remote host closed the connection]
xcm_ has quit [Read error: Connection reset by peer]
<Joel55>
mcfrisk_ I do see "kernel-module-dm-crypt-5.15.34-v7-dev" in build/tmp/pkgdata/raspberrypi3/runtime/kernel-dev but no device mapper on the target device boot
<Joel55>
After boot
tangofoxtrot has joined #yocto
<ejoerns[m]>
Joel55: since you posted the question in #rauc, too, I guess we should continue discussing there to not have two threads open
<ejoerns[m]>
Joel55: linux-raspberrypi.inc includes linux-yocto.inc thus it should have the same capabilities of merging configs
<ejoerns[m]>
jclsn: if you use bluetooth, enabling the distro feature might make sense anyway. I cannot find any bluetooth-related config option in qtwebengine, so maybe the build failure is unrelated?
grma has quit []
grma has joined #yocto
florian__ has joined #yocto
ptsneves has joined #yocto
<KareemZarka[m]>
what the new syntax for IMAGE_FEATURES_remove?
<JaMa>
:remove
vladest has joined #yocto
seninha has joined #yocto
d-s-e has quit [Ping timeout: 246 seconds]
Haxxa has quit [Ping timeout: 248 seconds]
xmn has joined #yocto
d-s-e has joined #yocto
Michael23 has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
Joel55 has quit [Quit: Client closed]
Haxxa has joined #yocto
d-s-e has quit [Ping timeout: 255 seconds]
d-s-e has joined #yocto
vladest1 has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
vladest1 is now known as vladest
sakoman has joined #yocto
Joel36 has joined #yocto
Net147 has quit [Ping timeout: 255 seconds]
Michael23 has quit [Quit: Client closed]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
kscherer has joined #yocto
mborzecki has joined #yocto
mborzecki has left #yocto [#yocto]
xmn has joined #yocto
mborzecki has joined #yocto
<mborzecki>
is it safe to call d.getVar() if the variable is unset? I have a little inline snippet ${@'fitImage-${INITRAMFS_IMAGE}.signed' if d.getVar('INITRAMFS_IMAGE') else 'fitImage.signed'} which is only correctly expanded when INITRAMFS_IMAGE is set, otherwise I see that that the snippet isn't expanded in bitbake -e of the recipe
<ptsneves>
mborzecki: it is. it will return None
<jclsn>
ejoerns[m]: Seems like it is coming down to a device tree misconfiguration. I will test that out now
<jclsn>
Thank you though
Estrella_ has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
<ptsneves>
mborzecki: in my chat program your message is truncated and contains a link that does not work :)
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
thekappe has joined #yocto
<thekappe>
Hello world !! I've to solve this problem: RecipeA builds but doesn't install librecipeA.a. RecipeB requires librecipeA.a to build correctly. How can I solve this dependency in yocto ?
<JaMa>
install librecipeA.a (you don't have to install it in the target image)
<rburton>
with the default packaging you'll end up with RecipeA-staticdev that contains the static library. DEPEND on recipea and you'll get the static library in the sysroot, but not in the image.
<rburton>
LetoThe2nd: was that conf worth it in the end?
<LetoThe2nd>
rburton: depends on your mission and objectives.
<rburton>
was it worth it for you?
<LetoThe2nd>
yup
Ad0 has quit [Ping timeout: 252 seconds]
tomzy_0 has quit [Quit: Ping timeout (120 seconds)]
tomzy_0 has joined #yocto
vladest1 has joined #yocto
vladest has quit [Ping timeout: 252 seconds]
vladest1 is now known as vladest
manuel1985 has quit [Ping timeout: 255 seconds]
amitk__ has joined #yocto
amitk___ has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
amitk_ has quit [Ping timeout: 248 seconds]
derRichard has quit [Quit: leaving]
Herrie has quit [Ping timeout: 248 seconds]
Herrie has joined #yocto
<JaMa>
anyone using XFS for builds?
Ad0 has joined #yocto
thekappe has quit [Ping timeout: 260 seconds]
<ptsneves>
@JaMa did, but things sometimes get funny due to it's unusual xattrs list
<RP>
JaMa: we gave up on the autobuilders as it broke too often
<JaMa>
ok, I'm debugging strange nodejs build failure (directory is created with mkdir, then qemu-arm is executed to run mksnapshot which should create a file inside this directory and it fails to open that file) - it's reproducible only on one server I'm aware of and the main difference seem to be XFS on /home (instead of EXT4 used on other servers), if I move TOPDIR to ext4 fs inside ext4.img, then it builds OK
<JaMa>
will rebuild it few times to make sure it's really OK and then will try to reproduce inside xfs.img on different host
<JaMa>
hmm yes, there is also docker with overlay involved :)
<tlwoerner>
zeddii: i want to add features/taskstats/taskstats.scc to qemuall in linux-yocto.inc because the build-appliance-image notices it missing when bitbaking
leon-anavi has quit [Quit: Leaving]
<tlwoerner>
zeddii: is that too big of a hammer? is there a more narrow way to apply this?
ccf has quit [Remote host closed the connection]
<ptsneves>
JaMa: hehe only joy!
<JaMa>
luckily I can probably just replace it with EXT4 once owner of that server confirms
<JaMa>
they even made huge rootfs 7TB (for some strange reason) so I can temorary move 3TB from XFS /home (18T) there before reformat - I wish I had that much Pr0n^w disk space
<ptsneves>
JaMa: you have very generous resources. I just requested a 1TB disk as i currently work on 512GB disk :(
<ptsneves>
No space for Pr0n^w <--ahahha
<JaMa>
I do a lot of builds and even NVME aren't terribly expensive anymore
<JaMa>
but this is someone elses server where I was just debugging that nodejs failure
<JaMa>
and it will probably end being shared by many people for OE builds
<moto-timo>
dodm
<moto-timo>
didn't b4 used to work with auh patches? hmmm
<JaMa>
moto-timo: XFS seems to be the reason for that nodejs issue I've mentioned yesterday
<moto-timo>
🤦 file systems and network infra
<JaMa>
I was ignorant about file systems issues since I've switched from reiser4 to ext3 and then ext4 .. until yesterday
davidinux has quit [Ping timeout: 248 seconds]
<JaMa>
they were still failing, but usually together with the disk HW
otavio has quit [Ping timeout: 260 seconds]
d-s-e has quit [Ping timeout: 255 seconds]
otavio has joined #yocto
d-s-e has joined #yocto
florian__ has quit [Ping timeout: 246 seconds]
<zeddii>
tlwoerner: the only way to make it more specific would be a distro feature, and it would have to be a new disto feature, as i can't think of an existing one that is a good trigger.
<zeddii>
we have a little used split of the developer and production kernel types, and you could see that in the developer kernel type, and not in production as an example.
<zeddii>
it is minimal overhead, and no one goes to production with the qemu types, so I don't see a big problem with enabling it.
ptsneves has quit [Ping timeout: 255 seconds]
zpfvo has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
ptsneves has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
d-s-e has quit [Quit: Konversation terminated!]
<tlwoerner>
zeddii: sounds good, thank you
Minvera has joined #yocto
advi[1] has joined #yocto
seninha has quit [Ping timeout: 268 seconds]
ptsneves has quit [Ping timeout: 246 seconds]
amitk___ has quit [Ping timeout: 255 seconds]
sakoman has quit [Quit: Leaving.]
davidinux has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Parlanchin has joined #yocto
<JaMa>
zeddii: last docker-moby upgrade is failing for some MACHINEs (with admitedly bad combination of TUNE flags), fails with cc1: error: switch '-mcpu=cortex-a9' conflicts with switch '-march=armv7-a+simd' [-Werror]
<zeddii>
hmm. leaking flags maybe ? The do_compile() is one of the originals, and i've always kept flag manipulations in it, due to all the issues I've had over the years with it.
<zeddii>
is it an oe-core defined machine ? I can spin up a build here. just testing qemuarm64 with some other WIP updates now.
<JaMa>
zeddii: it's not from oe-core, I'll debug it and let you know (possibly by patch)
<JaMa>
it's just FYI that it changed with the upgrade
<zeddii>
sounds good. thanks for the heads up.
<JaMa>
there is also some other more mysterious change in today's oe-core update which somehow reliably kills jenkins job after half build, but everything seems to behave normaly when building the same locally :)
<zeddii>
I had a master -> main branch jump out at me, between build of one machine and another. thought it was transient, but no.
Parlanchin has left #yocto [#yocto]
florian has joined #yocto
sakoman has joined #yocto
florian has quit [Read error: Connection reset by peer]
<Parlanchin>
hi all! we are trying to subscribe to the openembedded mailing lists to send a patch, but we are getting errors such as "The following addresses had permanent fatal errors ----- <confirm+SOMENUMBERS@lists.openembedded.org> (reason: 500 This group does not exist.)".... are the mailiing list systems down or so?
tomzy_0 has quit [Quit: Client closed]
<nerdboy>
hey
seninha has joined #yocto
advi[1] has quit [Quit: Client closed]
<nerdboy>
anyone know what keeps mounting vfat card partition under /run/media/mmcblk0p1 ? something in xilinx/avnet layers maybe?
<nerdboy>
i already got rid of their udev rules that were mounting both card partitions