jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
Daanct12 has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
alperak has joined #yocto
rob_w has joined #yocto
JJalling has joined #yocto
druppy has joined #yocto
beneth has joined #yocto
<JJalling>
Hello, isn't it possible to have one kernel module recipe (r)depend on another kernel module? Even if I in the recipe for kernel-module-foo adds RDEPENDS:${PN} += "kernel-module-bar", the bar module is never included in my rootfs
druppy has quit [Ping timeout: 272 seconds]
Kbo has joined #yocto
ptsneves has joined #yocto
zeemate has joined #yocto
leon-anavi has joined #yocto
DixitP has joined #yocto
goliath has joined #yocto
ptsneves has quit [Ping timeout: 276 seconds]
Guest70 has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
JJalling has quit [Quit: Client closed]
Guest43 has joined #yocto
JJalling has joined #yocto
DixitP has quit [Quit: Client closed]
florian has joined #yocto
<alperak>
Does DEBUG_PREFIX_MAP also handle the absolute paths that are injected into the binary as string literals via macros, or does it only affect debug information? If not, what is the best way to remove such string literals from the binary?
<alperak>
Using sed command?
<kanavin>
alperak, by setting macros correctly to begin with
<kanavin>
by first checking if they can be passed in as build arguments
<kanavin>
once something gets into a binary, it's impossible to fix after the fact
<alperak>
@kanavin thanks
<Guest43>
has someone hands on experience with integrating go-applications in yocto?
<kanavin>
Guest43, no need for lead-ins. Just ask the actual question.
<Guest43>
kanavin I am getting segmentation fault whatever go application I build in scarthgap
<zeemate>
hello, still not sure if petalinux is a full complied yocto linux, I added my own meta-layer into the bblayer.conf and added 1 package from this custom layer +IMAGE_INSTALL:append but was completely ignored
<zeemate>
no complains either
<JJalling>
Petalinux is a full yocto setup, with some added AMD/Xilinx tooling on top
<zeemate>
JJalling, thanks, but is something special with petlinux regarding adding custom layers? because I added my own layer and there are no errors no complains, but no builds either
<JJalling>
No I don't think so. And you are sure that you have added the layer to the bblayers.conf?
<JJalling>
So the recipe that you are creating, is it your own recipe or is it an append to an existing one?
<JJalling>
And what happens if you try to add other recipes to your image? Does they get applied?
<zeemate>
yes, it's within the bblayers.conf and it's getting meantiond at the beginning of the build, with all the other layers. the layer and the recipe is tested with a raspi build
<zeemate>
I tried to add vim into the build, Im about to see the result. though Im not sure if Vim is already within the build?
__lore__ is now known as _lore_
<rburton>
just adding layers doesn't add anything to your images
<rburton>
otherwise by your layer listing, your image would have multiple web servers, virtualisation frameworks, and both xfce and gnome installed
<zeemate>
rburton, I added also one of the recipies to +IMAGE_INSTALL:append, this usualy worked on other builds e.g. with my current layer on a raspi build
<rburton>
check the manifest that is next to the image, that lists all the packages that are in the image
<rburton>
you need to tell it what image recipe to read
<rburton>
but also what did you _actually_ put in local.conf as that should have affected the default
<JJalling>
bitbake -e core-image-minimal ... or whatever image you are building
ablu has quit [Ping timeout: 252 seconds]
<rburton>
"bitbake-getvar --value --recipe core-image-minimal" is the better way
<rburton>
erm add IMAGE_INSTALL onto that :)
<JJalling>
rburton, Thanks for the info
ablu has joined #yocto
Guest43 has joined #yocto
<zeemate>
in my case then bitbake-getvar --value --recipe petalinux-image-minimal IMAGE_INSTALL, and this is the output: https://pastebin.com/QCCUFhUd
<LetoThe2nd>
sounds like the reason why I tell people that if you absolutely want to add packages through local.conf, please use CORE_IMAGE_EXTRA_INSTALL
ptsneves has joined #yocto
rob_w has joined #yocto
<zeemate>
note: I didn't build bitbake core-image-minimal but petalinux-image-minimal !
<rburton>
zeemate: i still have questions about whether your local.conf change was correct, and if that file is even being read
<rburton>
zeemate: you can remove --value from the bitbake-getvar and see all the operations that were involved, which should show your append even if it ends up being ignored (maybe the image forcibly sets an IMAGE_INSTALL so you can't change it)
<rburton>
you can just make your own image, after all.
<rburton>
petalinux-image-minimal is a minimal example image, feel free to copy and edit
<zeemate>
if I write bull**** into local.conf I get an error, however, it's not comletely ignored
<JJalling>
You should remove the + in front of IMAGE_INSTALL. But do yourself the favor to at least create an append file for petalinux-image-minimal and put it there instead, as rburton also suggests.
<Guest88>
to mke a long story short am populating my A/B partitions scheme with two distinct yocto installations, the B partition is much smaller so that yotco is not including much apart from rauc and a few utiliies, at the moment the kernel's log.task_order does not show a call to do_deploy and my bbappend contains an essential do_deploy:append function
<Guest88>
which of couorse does not get called and the subsequent do_install:append fails as there is a file which can not be found as it should have been created by do_deploy:append, the bbappend even contains an addtask of do_deploy which should not be necessary. any idea on how to make that do_deploy happen?
<rburton>
zeemate: yeah remove the leading +, that's not right
ptsneves has quit [Ping timeout: 248 seconds]
frgo_ has quit [Read error: Connection reset by peer]
frgo has joined #yocto
Guest43 has quit [Quit: Client closed]
geoffhp has quit [Ping timeout: 244 seconds]
DixitP has joined #yocto
JJalling has quit [Quit: Client closed]
|Xagen has quit [Ping timeout: 252 seconds]
ptsneves has joined #yocto
Kbo has joined #yocto
prabhakar has joined #yocto
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
prabhakar has quit [Ping timeout: 268 seconds]
<RobertBerger>
Amsterdam
florian has quit [Ping timeout: 272 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
florian has joined #yocto
florian_kc has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
Guest43 has joined #yocto
Guest88 has quit [Quit: Client closed]
Daanct12 has quit [Quit: WeeChat 4.6.3]
Xagen has joined #yocto
<smurray>
khem: just a heads up, the abseil-cpp upgrade on meta-oe master-next seems to break the protobuf-native (and probably protobuf, I assume) build here
Guest43 has quit [Quit: Client closed]
rob_w has quit [Quit: Leaving]
<zeemate>
it works now, thank you guys
DixitP has quit [Ping timeout: 272 seconds]
Kbo has quit [Quit: Client closed]
druppy has joined #yocto
geoffhp has joined #yocto
fredcl has left #yocto [#yocto]
fredcl has joined #yocto
druppy has quit [Ping timeout: 248 seconds]
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
<zeemate>
one question left, I have a ADRV1CRR-FMC carrier board and a ADRV9361-Z7035 as a SOM. I guess only the latter matters, but what I use as MACHINE ?
pilonsi_ has joined #yocto
pilonsi has quit [Ping timeout: 265 seconds]
<qschulz>
anyone aware of issues on master trying to build python3-hatchling-native?
<qschulz>
it complains about python3-pluggy dependency not found
<qschulz>
it's there
<rburton>
qschulz: yeah theres been a few reports of that
<qschulz>
but the dist-info/METADATA file reports Version: 0.0.0
<rburton>
if you figure it out, send a patch :)
<qschulz>
replace that with 1.6.0 and it passes
<rburton>
so my _hunch_ is that you did a build with an existing build tree and a pluggy upgrade happened
<rburton>
so wiping tmp/ might just fix it
<qschulz>
let's see
<qschulz>
not the first time a git pull has broken my build with a builddir from an earlier commit
<rburton>
then the smoking gun would be if you build before the pluggy upgrade and then immediately after the upgrade and it breaks
<qschulz>
Quite possibly what happened, I rarely build master but trying to fix this mesa recipe is driving me nuts :)
jmd has joined #yocto
<qschulz>
I forgot it'll recompile clang-native again 😭
<RP>
rburton, qschulz: I've been hitting this locally. It looks like the problem we hit a while ago which people keep claiming is fixed and removing the fixes for
<rburton>
qschulz: guess why i have a pretty firm reasoning for the hunch
<rburton>
i saw it break once, hoped it wouldn't happen again
<rburton>
time to argue with upstream _again_
<rburton>
we can add back the "no really an empty directory is meaningless" piece
<RP>
rburton: please, that would likely fix this mess
<rburton>
though arguably, pluggy is broken if its breaking here
<RP>
I'd prefer to carry an non-upstreamable patch than this mess
<rburton>
the dist with the newer version should be first
* RP
likes words like "should"
tchx84 has joined #yocto
<qschulz>
rburton: barely saw python3-hatchling-native in my bitbake task list and it hasn't complained so I guess rm -rf tmp/ worked (around the issue)
<rburton>
qschulz: do you happen to have the stack trace from hatch to hand?
<rburton>
damnit i was hoping for more python stack failure, no problem obvious hatch doesn't consider this an error
<rburton>
glaring at hatchling code now, it _should_ be doing the right thing...
florian_kc has quit [Ping timeout: 276 seconds]
<rburton>
oh god why is this code trying to be clever but is just so bad
<rburton>
oh i'm so smart i'll lazily transform this list but yeah helps if you don't just stop halfway through and keep on having to do the beginning of the list every time
goliath has joined #yocto
tchx84 has quit [Ping timeout: 272 seconds]
vvn has joined #yocto
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
Guest88 has joined #yocto
<Guest88>
Guest88 12:17:57
<Guest88>
to mke a long story short am populating my A/B partitions scheme with two distinct yocto installations, the B partition is much smaller so that yotco is not including much apart from rauc and a few utiliies, at the moment the kernel's log.task_order does not show a call to do_deploy and my bbappend contains an essential do_deploy:append function
<Guest88>
which of couorse does not get called and the subsequent do_install:append fails as there is a file which can not be found as it should have been created by do_deploy:append, the bbappend even contains an addtask of do_deploy which should not be necessary. any idea on how to make that do_deploy happen?
Guest88 has quit [Quit: Client closed]
leon-anavi has quit [Quit: Leaving]
florian_kc has joined #yocto
ptsneves has joined #yocto
<rburton>
good news! i isolated the pluggy problem
<rburton>
now its dinner time
tgamblin_ has joined #yocto
goliath has quit [Quit: SIGSEGV]
tgamblin has quit [Ping timeout: 276 seconds]
tgamblin_ is now known as tgamblin
savolla has quit [Quit: WeeChat 4.6.3]
sgw has joined #yocto
Vonter has quit [Ping timeout: 276 seconds]
sgw has quit [Ping timeout: 272 seconds]
sgw has joined #yocto
vvn has quit [Quit: WeeChat 4.6.3]
<Saur>
RP: After the toolchain changes, we have a build failure in a recipe that sets `FC = ""` to avoid its configure task from trying to run the non-existing Fortran compiler. However, that no longer works due to toolchain/gcc.bbclass being inherit using inherit_defer and setting all variables using `=`. Now I have to set FC using an override in the recipe for it to win. This does not seem correct to me. Shouldn't the variables set by
<Saur>
toolchain/gcc.bbclass be set using `?=` or `??=` due to the use of inherit_defer?
goliath has joined #yocto
ptsneves has quit [Ping timeout: 276 seconds]
<rburton>
hmm why would bitbake leave an empty directory in site-packages for some people but not me when i'm trying to replicate the pluggy problem
<rburton>
qschulz: master, i presume?
<rburton>
qschulz: actual master or master before the python3.13.5 upgrade?
* rburton
grasping at straws
alperak has quit [Quit: Connection closed for inactivity]
jmd has quit [Remote host closed the connection]
<RP>
Saur: it is very unusual for a recipe to need/want to change those. The variables do really need to be left under the control of the toolchain selection
<RP>
Saur: I do understand your point but I fear changing that won't end well and people will end up with the toolchain selection not doing what they expect
<RP>
rburton: I was seeing it on master with an incrementally rebuilt TMPDIR
<rburton>
RP: for me, bitbake is pruning pluggy-1.5.0.dist-info entirely when it switches to pluggy-1.6.0.distinfo
<rburton>
and i'm struggling to remember/workout why a file would get left in that directory
<rburton>
even if i make a directory with the bad name and ensure it appears first in listdir(), it works
<RP>
rburton: I think the trick is the sstate cleaning code. It can't know when it is safe to remove an empty directory so it doesn't
<rburton>
RP: but it is!
<RP>
rburton: you need to trigger that sstate cleaning mechanism
<RP>
rburton: sometimes it can know it is safe
<RP>
I don't remember the details :/
<rburton>
but even if i create the bad directories, i can't break it right now
<RP>
rburton: I wish I'd left me mess intact so I could demo this!
<rburton>
i've seen it before too, i know it _does_ happen
<rburton>
i just wish i'd grabbed the tmpdir when it did
<RP>
rburton: I had one earlier but I got annoyed and removed large chunks of it
<RP>
rburton: I'd have to poke to try and reproduce. I'd probably make an old checkout of poky, build it from scratch, then upgrade
KanjiMonster_ has joined #yocto
<rburton>
yeah i have a branch with some select reverts and i'm force building various recipes
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
KanjiMonster has quit [Ping timeout: 272 seconds]
KanjiMonster_ is now known as KanjiMonster
<rburton>
elif os.path.exists(entry) and len(os.listdir(entry)) == 0 and not canrace:
<rburton>
hm
<rburton>
so only if its cleaning sstate _and_ the manifest exists
<rburton>
i think i know the fix i need to make but don't want to make it blindly
florian_kc has quit [Ping timeout: 268 seconds]
<Saur>
RP: Unfortunately, I think it will be problematic as is as well. I did a quick grep for the variables set in toolchain/gcc.bbcass, and found `CC += "-fuse-ld=bfd"` in the glibc
<Saur>
... the glibc recipe, which currently isn't having the intended effect. There are also three recipes in meta-oe that do `CC += ...`
kergoth has joined #yocto
sgw has quit [Ping timeout: 245 seconds]
<Saur>
There are also a couple of recipes that do `export AR = ...`, `export AS = ...` and `export LD = ...`in meta-openembedded.
<RP>
Saur: we probably need to change them to use cflags
<qschulz>
rburton: 60e8db858864 ("ref-manual/yocto-project-supported-features: Set riscv32 maintainers as TBD")
<qschulz>
fir poky
<qschulz>
i have meta-arm, meta-openembedded and meta-rockchip (and my own two layers which are minimal and aren't changing anything in interesting recipes)
goliath has quit [Quit: SIGSEGV]
sgw has joined #yocto
<Saur>
RP: Sent a patch for glibc.
zeemate has quit [Ping timeout: 252 seconds]
<rburton>
qschulz: if you can make it break again, please keep your tmpdir
rosbur01 has joined #yocto
rosbur01 has quit [Client Quit]
Kubu_work has quit [Quit: Leaving.]
sgw has quit [Ping timeout: 260 seconds]
sgw has joined #yocto
tangofoxtrot has quit [Ping timeout: 276 seconds]
sgw has quit [Ping timeout: 268 seconds]
tangofoxtrot has joined #yocto
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 268 seconds]
kergoth has quit [Quit: Connection closed for inactivity]