kscherer has quit [Quit: Konversation terminated!]
money_ has joined #yocto
money__ has joined #yocto
money_ has quit [Ping timeout: 256 seconds]
jclsn has quit [Ping timeout: 252 seconds]
money_ has joined #yocto
money__ has quit [Ping timeout: 256 seconds]
universalfiction has joined #yocto
universalfiction has left #yocto [#yocto]
jclsn has joined #yocto
money_ has quit [Remote host closed the connection]
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
sakoman has quit [Quit: Leaving.]
money_ has joined #yocto
money_ has quit [Client Quit]
pml has joined #yocto
money_ has joined #yocto
money_ has quit [Quit: late]
rfs613 has quit [Remote host closed the connection]
deuteron has joined #yocto
money_ has joined #yocto
<deuteron>
Hi all. I'm trying to get rid of the RUNPATH in the target sysroot libraries in an SDK produced by yocto.
<deuteron>
I've used SDK_POSTPROCESS_COMMAND to add a function which calls `chrpath -d ...` on all relevant files. It appears to work when I look at the files under tmp but when I install the resultant SDK, the RUNPATH field is back or still there.
money_ has quit [Read error: Connection reset by peer]
money__ has joined #yocto
money__ has quit [Quit: late]
money_ has joined #yocto
amitk has joined #yocto
money__ has joined #yocto
money_ has quit [Ping timeout: 256 seconds]
thomasd13 has joined #yocto
money__ has quit [Ping timeout: 256 seconds]
alessioigor has joined #yocto
Starfoxxes has quit [Ping timeout: 255 seconds]
BWhitten has joined #yocto
sion33 has joined #yocto
money_ has joined #yocto
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
money_ has quit [Quit: late]
Guest13 has quit [Ping timeout: 260 seconds]
Starfoxxes has joined #yocto
mckoan|away is now known as mckoan
<LetoThe2nd>
yo dudX
<mckoan>
good morning
sion33 has quit [Ping timeout: 246 seconds]
sion33 has joined #yocto
mvlad has joined #yocto
zpfvo has joined #yocto
rfuentess has joined #yocto
Estrella_ has quit [Ping timeout: 252 seconds]
Estrella has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
gho has joined #yocto
<deuteron>
I think I found the problem. There's a bunch of core functionality embedded in SDK_POSTPROCESS_COMMAND. Namely archive_sdk.
<deuteron>
Not sure why it was done like this rather than proper tasks for each part.
<deuteron>
SDK_POSTPROCESS_COMMAND I would expect is for users to hack some things with.
<deuteron>
Shouldn't have to fight the core sdk generation too.
camus has quit [Remote host closed the connection]
camus has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
money has joined #yocto
money has quit [Quit: late]
money has joined #yocto
nemik_ has quit [Ping timeout: 252 seconds]
nemik_ has joined #yocto
gsalazar_ has joined #yocto
malsyned has joined #yocto
BWhitten has quit [Ping timeout: 252 seconds]
nemik_ has quit [Ping timeout: 272 seconds]
nemik_ has joined #yocto
malsyned has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
money has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
matiop6[m] has quit [Quit: You have been kicked for being idle]
camus has quit [Remote host closed the connection]
camus has joined #yocto
creich_ has joined #yocto
florian has joined #yocto
seninha has quit [Remote host closed the connection]
<d-s-e>
Hi, I 'd like to mount an OverlayFS on /var/lib with /data/var/lib as the upper layer, /data is already mounted via fstab on a separate partition. Now the build fails with "Mount path /data/var/lib not found in fstab and unit data-var-lib.mount not found in systemd unit directories."
<d-s-e>
But what mount-file is missing? /data is already mounted with an existing /data//var/lib folder.
xmn has joined #yocto
rfs613 has joined #yocto
goliath has joined #yocto
grma has quit [Ping timeout: 246 seconds]
Guestu has joined #yocto
sakoman has joined #yocto
<Guestu>
hey, I would like to use fetch method in Image recipe, so I have added d.delVarFlag("do_fetch", "noexec") in anonymous function but I have to call bitbake -c fetch, it's not automatically done, any hint ? thx. ( the purpose is to use custom tool on git server to crypt the image )
gsalazar_ has quit [Remote host closed the connection]
gsalazar_ has joined #yocto
<rburton>
Guestu: write the crypting as a image conversion, and then you can add a depends to that conversion and have a normal recipe to provide the tool
<rburton>
see image_types.bbclass and eg how the zip conversion works. crypting it is just another type of conversion.
<Guestu>
rburton yes but I need to access some environment variables, and normally environment is local for recipe not image isn't it ?
<rburton>
an image is a recipe
<rburton>
well the image recipe is a recipe
<rburton>
image recipes are not special
<Guestu>
ok my bad thx for the hint
<Guestu>
image recipes doesn't call fetch so for me it's special ^^
<zeddii>
RP: First 6.1 pass on libc-headers and the reference kernel's are looking good. just a couple of tools to fix up. I expect to send the patches over the weekend for more testing, but not to make them the default.
<rburton>
Guestu: that would be because image.bbclass does do_fetch[noexec] = "1"
<rburton>
zeddii: woot. had people asking about 6.1 yesterday
<zeddii>
rburton: I'll push to linux-yocto and a zedd/kernel-next branch today, so if anyone is really anxious to have a go, the stuff is already pretty sane.
<zeddii>
I'm arguing with systemtap and other such tools that no one normally uses :)
<zeddii>
and musl passed as well. same with -rt
<zeddii>
but I did most of the 6.1 work before the last release, so this has been relatively smooth.
malsyned has joined #yocto
florian_kc is now known as florian
<RP>
zeddii: sounds good! I'm in a world of breakage from the bitbake changes
kscherer has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
<Guestu>
rburton CONVERSION_CMD assume that's the tool is a binary isn't ? (as for lzo in the doc) but in my case if bash script + config files I cannot depends on "git repo"
thomasd13 has quit [Ping timeout: 252 seconds]
<rburton>
Guestu: conversion commands are just a sh script to run. if you can put your tools in a recipe you can depend on the recipe and call it.
<RP>
paulg: at least the message was polite. One bitbake message suggests the user post the reproducer on the bitbake-devel list so we can have a laugh :)
<Guestu>
rburton ok got it, the custom image is not really an image but a bbclass with some append function
* paulg
runs ./scripts/install-buildtools and hopes for the best
Guestu has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
mvlad has quit [Ping timeout: 252 seconds]
<RP>
paulg: that probably needs updating :(
<zeddii>
paulg: run sudo rm -rf / first
<zeddii>
:)
* LetoThe2nd
ubuntus zeddii
<RP>
zeddii: we should a "scripts/fix-my-build"
yann has quit [Ping timeout: 260 seconds]
<paulg>
there have been times where I've wished for a script that would "bitbake -c cleanall <failed_pkg>" in a loop over every failed pkg...
<paulg>
this is of course another self inflicted punishment for re-using the same build dir forever ; apparently sth only zeddii and I do.
rber|res has quit [Remote host closed the connection]
rber|res has joined #yocto
<RP>
paulg: you're not alone in that
<JaMa>
I just use cleansstate instead of cleanall, because I never see the issue to be caused by downloaded sources and redownloading from upstream is just masochism
mvlad has joined #yocto
<paulg>
fresh bytes have to be better than stale ones. ;-)
<paulg>
kinda like the fancy HDMI cables they want to sell you for $50/ea. :)
gho has quit [Quit: Leaving.]
<JaMa>
many HDMI cables dont deal well with reasonable length with 4K@120
<JaMa>
smelly stale sources still can produce the binaries :)
malsyned has quit [Ping timeout: 252 seconds]
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
seninha has joined #yocto
<rburton>
abelloni: hm, i tested the no-gl paths when doing that gtk patch
<rburton>
paulg: rm tmp is much easier :)
<abelloni>
rburton: I wanted to warn you earlier but I was trying to sort the other issues
<abelloni>
this had all your meson patches
PhoenixMage has quit [Ping timeout: 272 seconds]
PhoenixMage has joined #yocto
<rburton>
i'll go back to glaring at gtk
<paulg>
rburton, I usually get to about the 5th pkg, then say f*ck it and nuke tmp
PhoenixMage has quit [Ping timeout: 255 seconds]
malsyned has joined #yocto
PhoenixMage has joined #yocto
rfuentess has quit [Remote host closed the connection]
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
<rburton>
rm_work lets you nuke tmp faster ;)
prabhakarlad has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 246 seconds]
<whuang0389>
Hi, I'm trying to find which recipe is pulling in `sed` in my final image. Did a bitbake -g <image>; oe-depends-dot sed.build <file>. Result is pointing to my image <image>.bb, however searching through my image recipe doesnt show it's pulling in `sed` directly. Is there another way to search for what's pulling in `sed`?
zpfvo has joined #yocto
amsobr has quit [Quit: Client closed]
<rburton>
whuang0389: its a package that you're pulling in. did you try --why to oe-depends-dot?
<whuang0389>
yep. i passed in the --why flag
<rburton>
did you do oe-depends-dot --why --key sed?
<whuang0389>
yep
<whuang0389>
oe-depends-dot -w -k
<whuang0389>
the only way I found out which package(s) are actually pulling it in is via PACKAGE_EXCLUDE which spits out a bunch of errors saying that actually tells me which package rdepends on sed
<rburton>
whuang0389: the depends-dot usually works, unless its a dependency which is discovered at runtime only
<rburton>
i need to finish writing the tool to scan pkgdata at the same time
whuang0389 has quit [Quit: Client closed]
<abelloni>
khem: probably not, I'm struggling to have a working build
<khem>
abelloni: ok no worries take your time. I just saw mariadb failing in my builds and I was wondering what went wrong, then realized that the patch disappeared in rebase
camus has quit [Remote host closed the connection]
<khem>
one thing is sure that this will result in lot of rebuilds since libpcre2-native is needed by many basic packages
camus has joined #yocto
sotaover1ide has quit [Ping timeout: 256 seconds]
camus has quit [Remote host closed the connection]
sotaover1ide has joined #yocto
camus has joined #yocto
<abelloni>
I'm not too concerned by the rebuilds, oe-selftest is taking 12h...
camus has quit [Remote host closed the connection]
camus has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
PhoenixMage has quit [Ping timeout: 256 seconds]
malsyned has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
malsyned has joined #yocto
BWhitten has joined #yocto
leon-anavi has quit [Remote host closed the connection]
malsyned has quit [Ping timeout: 272 seconds]
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
gsalazar_ has quit [Ping timeout: 255 seconds]
alessioigor has quit [Quit: alessioigor]
<rburton>
abelloni: hm, gtk worked for me with oe-core.
camus has quit [Remote host closed the connection]
<JPEW>
It doesn't cover how to actually specify the filters for a variable, but it does give the engine to evaluate them
camus has joined #yocto
<JPEW>
I was thinking.... if you do your idea to be able to use python syntax in variable expressions, this might be possible to very naturally write something like: VAR[filer] = ["prefix(v, 'a')", "suffix(v, 'b')"]
<JPEW>
*VAR[filter] that is, FWIW
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
money_ has quit [Quit: late]
money_ has joined #yocto
money_ has quit [Read error: Connection reset by peer]
<JPEW>
And... actually for starters, you can manually chain the calls like `"prefix(prefix(v, 'b'), 'a')"` so it may not even be necessary to allow multiple filter expressions for now
<RP>
JPEW: the earlier ones are connection lost, the system then restarted the build, moving the old one out the way
<RP>
JPEW: so the build doesn't actually finish but stays in memory for a bit, then deletes the sock file when it exits at the old path?
<JPEW>
Do we reuse build paths?
<RP>
JPEW: yes
<RP>
I just found a cookerdaemon log with "[2022-12-15 20:46:33,757 pyinotify ERROR] The pathname '/home/pokybuild/yocto-worker/qemuarm/build/build' of this watch <Watch wd=17 path=/home/pokybuild/yocto-worker/qemuarm/build/build mask=4042 proc_fun=None auto_add=False exclude_filter=<function WatchManager.<lambda> at 0x7f2a00ffaa70> dir=True > has probably changed and couldn't be updated, so it cannot be trusted anymore. To fix this error move
<RP>
directories/files only between watched parents directories, in this case e.g. put a watch on '/home/pokybuild/yocto-worker/qemuarm/build'." in
PhoenixMage has quit [Ping timeout: 272 seconds]
<RP>
which is what suddenly made me wonder
<JPEW>
Ya, I could see how a long bitbake timeout could cause that
<JPEW>
I feel like that could cause a lot of problems actually
<JPEW>
And I suspect that is a really rare thing to do outside of the AB