<JaMa>
ccf: Cau, it's kept by default unless you inherit rm_work or reuse it from sstate, if you want to force rebuilding something (without sstate) you can use -C compile or -c cleansstate and rebuild
Thorn has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
prabhakarlad has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus1 is now known as camus
goliath has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
mvlad has joined #yocto
frieder has joined #yocto
leon-anavi has joined #yocto
td43 has joined #yocto
<mcfrisk_>
Broken pipe[Errno 32] Broken pipe[Errno 32] Broken pipe[Errno 32] Broken pipe[Errno 32] Broken pipe[Errno 32]... "bitbake -e core-image-minimal | less" goes crazy after some time
xtopher_ has quit [Ping timeout: 255 seconds]
CosmicPenguin has quit [Ping timeout: 255 seconds]
CosmicPenguin has joined #yocto
xtopher_ has joined #yocto
shivamurthy has quit [Ping timeout: 255 seconds]
reatmon has quit [Ping timeout: 255 seconds]
jamestperk has quit [Ping timeout: 255 seconds]
nohit has quit [Ping timeout: 255 seconds]
smurray has quit [Ping timeout: 255 seconds]
reatmon has joined #yocto
shivamurthy has joined #yocto
sgw has quit [Ping timeout: 255 seconds]
ndec has quit [Ping timeout: 255 seconds]
sgw has joined #yocto
elfenix|cloud has quit [Ping timeout: 255 seconds]
nohit has joined #yocto
jamestperk has joined #yocto
louis_ has joined #yocto
louis_ is now known as louson
Thorn has joined #yocto
ptsneves has joined #yocto
<JaMa>
mcfrisk_: looks like you need good plumber :)
smurray has joined #yocto
ndec has joined #yocto
elfenix|cloud has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
azcraft has joined #yocto
davidinux has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
knicklicht has joined #yocto
<shoragan>
is there a mechanism to keep the user ids allocated via USERADD_PARAM static over a longer term?
ptsneves1 has joined #yocto
<knicklicht>
Hello all, I added DISTRO_FEATURES_BACKFILL_CONSIDERED = "pulseaudio" to my distro config to exclude any pulseaudio components that are present in an alsa package group that I enabled in my build. Now I get an error when building: "configure: error: not using libltdl; cannot load alsa dynamically" in sox_14.4.2.bb recipe. I did not explicitly add
<knicklicht>
sox. I tried adding libltdl/libtool to my built but it does not fix the error. How do I: 1. find the recipe that adds this dependency, 2. Add the needed dependencies to built sox?
manuel__ has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
<yocton>
knicklicht: You can get a dependency graph with "bitbake -g <you image>"
florian_kc has joined #yocto
neverpanic has quit [Ping timeout: 248 seconds]
<knicklicht>
yocton: Thanks, I will try it out.
neverpanic has joined #yocto
<Saur[m]>
shoragan: Yes, there is. This is what we use in our configuration: https://pastebin.com/tvszSXH0. Then in the `files/static-ids` file, we list all users/groups and their IDs as `<name>::<id>`. One note, we make sure to use the same ID for both user and group with the same name. Otherwise you would have to have separate files.
amitk has quit [Remote host closed the connection]
florian__ has joined #yocto
davidinux has joined #yocto
td43 has quit [Quit: Client closed]
<ptsneves>
I am so confused with how git lfs works in yocto. There is no documentation for it, and there are actually 3 states, lfs=0, lfs=1 and undefined lfs parameter in the SRC_URI but lfs=1 and undefined lfs parameters use different code paths
<ptsneves>
s/yocto/bitbake
<RP>
ptsneves: I've relied on patches from people so I'm not really sure either :(
<RP>
ptsneves: is there anything in the git commits related to it which helps?
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<ptsneves>
@RP Yes, and some context as well. The thing is that git filter handling, which is what git-lfs is, is something done transparently by git. With lfs=1 we just make sure that the git filter does not happen in the do_unpack task but at the do_fetch part. With the lfs URI parameter unset and with a git lfs repository, git may fetch git lfs blobs in every unpack due to the filters running on git checkout
<JaMa>
ptsneves: if you have lfs enabled in .gitconfig bitbake fetcher will be affected by it as well
<ptsneves>
@RP So my suggestions is that we add git-lfs to the auto builder and use an actual git lfs repository instead of the current one which is a dummy non-git lfs repo
<ptsneves>
JaMa: exactly!
<RP>
ptsneves: we're not adding git-lfs to the autobuilder, the dependencies are horrendous
<ptsneves>
RP: git-lfs is a go binary, which can be built statically if i am not wrong?
<RP>
ptsneves: remember that we have all different flavours of distros as autobuilder workers. We'd have to have something that would work for all of them. The systems are also supposed to have minimal installs
rob_w has quit [Remote host closed the connection]
<ptsneves>
then we should re-do the lfs specific logic into general git filter handling logic. Basically we would look for any gitattributes related to filters in the fetch, and if any, do the tempdir checkout on do_fetch to run the filters. We could also look at the smudge/process filter command and do a which on it. If not found do a warning.
<ptsneves>
This would be testable without git-lfs specifically and would cover git-lfs implicitly
davidinux has quit [Ping timeout: 255 seconds]
<RP>
ptsneves: that sounds reasonable to me without knowing much about any of the details :)
<LetoThe2nd>
it might be my age showing, but my brain always reads: "Git Linux From Scratch"
<ptsneves>
LetoThe2nd: ahah me too. It is so strongly burned on me that I need to make a mental tai-chi to let it go
starblue has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
ptsneves: tell me if it works. i tried drinking, but no success.
<shoragan>
Saur[m], ah, excellent!
<ptsneves>
RP: Do you know who could help me validate my understanding on the subject?
starblue has joined #yocto
<RP>
ptsneves: not really :(
<ptsneves>
RP: That is not great as my understanding of the current behavior keeps changing.
<ptsneves>
https://pastebin.com/gXktRex0 is a patch of real git-lfs checkout where lfs=1 and lfs unset both work, but the fetcher code paths are different
<RP>
ptsneves: we should probably add those and ensure it shows a warning if lfs is used without lfs=1 being set?
Wouter010067044 has joined #yocto
<ptsneves>
RP: We cannot add it because they actually require git-lfs to be in the autobuilder, or they need to be disabled in the autobuilder.
<ptsneves>
Regarding the warning i agree.
<ptsneves>
@RP at least according to your statement that we cannot have git-lfs in the autobuilder
<JaMa>
ptsneves: my understanding is also quite limited and when I've asked in RFC on ML what is the expected behavior I got no reply, but please update the ticket with your understanding and link it from your future changes
<RP>
ptsneves: we can skip the tests if it isn't present. Having the tests would be better than not
seninha has quit [Remote host closed the connection]
<RP>
ptsneves: we do already skip tests if we can't reasonably run them
seninha has joined #yocto
<ptsneves>
JaMa: You know, i was skimming the ticket and the reason i started this investigation was because I found an issue with the exact same error message, except it was not on git submodule. Fixing the filters, fixed the issue. By the way you can make git ignore system and global gitconfig by setting
<LetoThe2nd>
who's the current masterbrain for wic+plugins?
<JaMa>
ptsneves: that's true, but I need the rest of my .gitconfig :)
<JaMa>
so blocking the system config helps a bit, but still doesn't prevent different results on different users (which might have lfs enabled in user's .gitconfig like I had)
<ptsneves>
JaMa: Yes then you are in the worst scenario. You cannot really disable git-lfs with git -c filter.lfs.process= does not disable the filter.
<ptsneves>
That is why i say the way to go is to have a generic scan of .gitattributes and a sanity check of the filters that bitbake will implicitly run through git. So that missing filters can at least cause a warning, and existing filters can be logged in notes.
davidinux has joined #yocto
zhmylove has joined #yocto
krissmas1er has quit [Remote host closed the connection]
<phako[m]>
I am having FILES:${PN}-cruft += "${libdir}/foo/ " which makes ${libdir}/foo/cruft/* appear in the package, but not ${libdir}/foo/cruft/data or anything within data. is that expected?
<RP>
LetoThe2nd: we don't have one :(
<LetoThe2nd>
RP: a brain, or a master?
<qschulz>
phako[m]: it's probably matched by another package before ${PN}-cruft is created
<qschulz>
oe-pkgdata-util find-path '/usr/lib/foo/cruft/data' or something like that
<phako[m]>
er wait, sorry. its in the correct packages-split path
<qschulz>
and then you can figure out which FILES variable to modify
<phako[m]>
why isn't in the target
<qschulz>
are you installting PN-cruft?
<RP>
LetoThe2nd: either, it is an area that is struggling :(
<phako[m]>
qschulz: yes, I am stupid, I confused myself by the package hierarchy
<LetoThe2nd>
RP: can I quote you that we are struggling with brains? ;-)
<RP>
LetoThe2nd: I did wonder if you were trying to set me up but decided to play along anyway :)
<RP>
LetoThe2nd: given how I'm feeling today, mine definitely is struggling...
<LetoThe2nd>
RP: i did not intentionally, but playing along is appreciated.
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
<qschulz>
LetoThe2nd: is a jester a jester if people aren't in on the joke?
<qschulz>
we gotta preserve your important (though self-proclaimed) title!
<LetoThe2nd>
qschulz: :-)
<ptsneves>
qschulz: agree!
Thorn has quit [Quit: Life without danger is a waste of oxygen]
amitk has quit [Ping timeout: 248 seconds]
d-s-e has joined #yocto
<ptsneves>
can anybody provide me with the docs on SHELL? I searched the glossary of bitbake manual and poky and cannot find it. I only see that it is default assigned to bash on the terminal.bbclass
<rburton>
ptsneves: man login? what about it specifically.
<ptsneves>
Yeah, but this variable is available in non terminal related recipes through transient dependencies. For example through patch.bbclass
<RP>
ptsneves: it is more of a terminal/unix thing
angman has joined #yocto
<ptsneves>
RP: Yes that is my understanding. My question is because in private I see users using that variable in non terminal tasks, and i wanted to know if this variable's use is recommended.
<RP>
ptsneves: bitbake nor OE really care about it afaik
angman has quit [Quit: Client closed]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
rossaroni has quit [Quit: leaving]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
AKN_R has quit [Read error: Connection reset by peer]
AKN has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
xmn has joined #yocto
brazuca has quit [Quit: Client closed]
<TRO[m]>
Hi, who knows about the autobuilder infrastructure used? (e.g. AWS instance type etc.)
angman has joined #yocto
<angman>
Hi. I'm investigating how to create spdx files with our yocto build system (dunfell). I have already tried the following two ways, but there are some challenges.
<angman>
Using meta-spdxscanner is the easiest way. But I found that it takes too much time to create spdx files. I need a faster way to create them.
<angman>
Using create-spdx.bbclass is the best I can do. I have found that create-spdx.bbclass works with updating, adding or modifying some poky/meta files. But I think this is a hacky way.
<angman>
Do you have any idea how to create spdx files with dunfell?
<qschulz>
because I don't quite understand what you mean by "works with updating, adding or modifying some poky/meta files."
<angman>
To be precise, no. I want to create spdx in Dunfell's poky, but the method of using create-spdx described in the linked manual instructions is only supported from kirkstone....
<angman>
Thus, when I used create-spdx on my build system (dunfell), it means that I updated or added some files in the meta layer to match kirkstone's poky.
prabhakarlad has joined #yocto
<angman>
However, I don't think this is a good approach and am looking for other methods.
<qschulz>
I don't know exactly how good the support for SBOM creation is in Dunfell, so summoning JPEW :)
<JPEW>
I don't think we backported it, but the class is pretty straight forward so I think you could copy it back? We get that request a lot....
<angman>
Yes, and I already tried it and succeded. 😊
<angman>
But I feel that this is not a very appropriate method, so I asked if there is another way.
<qschulz>
angman: update to kirkstone :D ?
kscherer has joined #yocto
<qschulz>
angman: you could always have the new create-spdx class from kirkstone in your own layer and setup BBPATH appropriately
<angman>
Yes, but only a few files becuase I used a bsp provided by other board vendor, and it includes dunfell poky...
<qschulz>
but that is definitely not best practice
Guest83 has joined #yocto
Guest83 has left #yocto [#yocto]
<angman>
Yes, that's right. But I guess I'll have to bring the create-spdx related files from kirkstone for now.
<angman>
Just knowing that was very helpful. Thanks!😁
angman has quit [Quit: Client closed]
<JPEW>
keep an eye on master, we are working on a few other SPDX fix
<qschulz>
ndec: LetoThe2nd this is for you I guess? ^
hcg has quit [Quit: Client closed]
<RP>
mcfrisk_: I asked that same question recently. There is a news on the bottom bar
<RP>
mcfrisk_: there is a redesign in progress FWIW
d-s-e has quit [Ping timeout: 255 seconds]
d-s-e has joined #yocto
Guest40 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<Guest40>
Hi, i'm having trouble adding the e2fsprogs of meta-openembedded on a yocto project (morty), I append it on the image .bb file "IMAGE_INSTALL += "\
<Guest40>
${CORE_IMAGE_BASE_INSTALL} \
<Guest40>
Hi, i'm having trouble adding the e2fsprogs of meta-openembedded on a yocto project (morty), I append it on the image .bb file "IMAGE_INSTALL += "\
<Guest40>
${CORE_IMAGE_BASE_INSTALL} \
<Guest40>
alsa-lib\
<Guest40>
e2fsprogs\
<Guest40>
"
<Guest40>
the alsa-lib packet is correctly added but no clue what happened to the e2fsprogs
<qschulz>
Guest40: which binary are you expecting in your image?
<qschulz>
if you were on a decently recent release of yocto I would have suggested to use oe-pkgdata-util find-path 'tune2fs' and you'd have known directly without reading the recipe :)
<qschulz>
Guest40: also, morty... EOL for almost 5 years now, time to upgrade :)
amitk has joined #yocto
<linex[m]>
if I bbappend and modify a variable, will it have the access to the variables from its initial context ?
<rburton>
"it"?
<linex[m]>
e.g. VAR = "$PREV_CONTEXT_VAR $MY_ADDITION"
<Saur[m]>
@linex: VAR += "${MY_ADDITION}"
<rburton>
VAR = "$VAR FOO" does what you want, but += is neater
<Saur[m]>
Or: VAR:append = " ${MY_ADDITION}"
<Guest40>
qschulz the documentation of https://layers.openembedded.org/layerindex/recipe/53502/ it is said that the e2fsprogs package (which contains tune2fs) has version 1.43 for yocot morty in the meta-openembedded layer, why is it not added in my tune2fs image if I add e2fsprogs in the same way as alsa-lib?
<linex[m]>
but in my actual use-case I'm not just adding to it I'm modifying it
<Saur[m]>
That was not what you asked for. ;)
<qschulz>
Guest40: because the e2fsprogs **recipe** produces multiple **packages**
<Guest40>
qschulz i've just tried to add the "e2fsprogs-tune2fs" packet but same result as adding only e2fsprogs
<qschulz>
and it happens that the e2fsprogs-tune2fs package has the binary you're interested int
<qschulz>
Guest40: make sure you're modifying the same image recipe you're building
<linex[m]>
better example VAR = "$PREV_CONTEXT_VAR1 -P $PREV_CONTEXT_VAR2"
<Saur[m]>
linex: You can reference the old `${VAR}` when defining VAR if you use `VAR := "foo ${VAR} bar"
<linex[m]>
hmm, meaning what I wanted to do won't work easily
<linex[m]>
unless I inherit the original file, to get access to those vars
<linex[m]>
thanks ! :)
<rburton>
a bbappend has access to the original variables because it is evaluated at the same time as the recipe is parsed
<qschulz>
linex[m]: not sure exactly what you mean by PREV_CONTEXT_VAR1 and I feel there may be some logic misunderstanding here
<Guest40>
qschulz i've only got one image , so it's sure i'm modifying the same recipe i'm building, problem is if i don't add the "e2fsprogs" or "e2fsprogs-tune2fs" line to the .bb file , i bitbake and 3008 tasks are needed to "build" and when i modified the .bb file same numbre of tasks are needed (when i add a diferent packet more tasks are needed), is
<Guest40>
like it doesn't load anything
<phako[m]>
can I enable ccache for just one recipe? I am fighting with some installation issues and each change to cmake or bb causes a full recompile and that takes ages -.-
<phako[m]>
*full recompile of that recipe
<rburton>
phako[m]: yes, just inherit ccache in the recipe
<phako[m]>
\o/ it looked like somethign that applies to the whole distro
zhmylove has quit [Quit: Leaving]
<phako[m]>
at least its only 7 minutes with gcc 11 and not the full 25 with gcc 9
<qschulz>
Guest40: if you're adding a different package from the same recipe, the whole recipe will still be built
<qschulz>
Guest40: it's expected that little changes in that scenario
<phako[m]>
thanks
<qschulz>
at least in terms of tasks to be done for your image to be built
prabhakarlad has joined #yocto
<Guest40>
ok, thank you qschulz
leon-anavi has quit [Quit: Leaving]
ptsneves1 has quit [Ping timeout: 255 seconds]
ndec has quit [Ping timeout: 255 seconds]
ndec has joined #yocto
<zeddii>
tlwoerner, I missed your reply 2 days ago on my feedback. do you still want / need a reply ?
Jham has quit [Quit: Leaving]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
frieder has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 255 seconds]
amitk has quit [Ping timeout: 264 seconds]
d-s-e has quit [Ping timeout: 255 seconds]
<fabatera[m]>
Hi, is there a big advantage on using zst compressed rootfs?
<tlwoerner>
zeddii: i'm good, your feedback was perfect. i have an update to dtc to 1.7.0 and adding support to build pylibfdt in the same recipe
<zeddii>
awesome. I can try dropping my vendor'd pylibfdt in the lopper repository and see how it works. I had done that vendoring due to the pypi lagging, etc.
vladest has quit [Remote host closed the connection]
<Guest1085>
according to the error message it seems that the git clone fails, but if I execute it manually (copy&paste from the log) it works
<Guest1085>
has anyone experienced this issue too or know how to resolve it?
<rburton>
Guest1085: expired pastebin
<fabatera[m]>
rburton: Thanks. I read this before asking but wondering if there was any consideration / benchmark in the yocto side (that lead to the decision of using zst).
vladest has quit [Remote host closed the connection]
<rburton>
fabatera[m]: the metrics on that site really. its faster than algorithms like gzip, which is 30 years old now.
vladest has joined #yocto
mckoan is now known as mckoan|away
florian has quit [Remote host closed the connection]
<Guest1085>
rburton not sure why that happened, I set expiration to 1 week, here's a new one: https://pastebin.com/2VKi1S4C
<rburton>
"This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff."
<rburton>
looks like your missing the git-upload-pack binary
seninha has quit [Quit: Leaving]
<Guest1085>
you mean in the OS? its definitely installed and exists in my PATH
<Guest1085>
and as I said, the same command from the log works if I execute i manually
<rburton>
try adding HOSTTOOLS += "git-upload-pack" to your local.conf
d-s-e has joined #yocto
<Guest1085>
rburton thanks, that seems to have worked :)
invalidopcode1 has quit [Remote host closed the connection]
<rburton>
Guest1085: annoying. i wonder why that is.
invalidopcode1 has joined #yocto
<Guest1085>
is it a known issue? otherwise it might be distro specific? I'm using void linux
<rburton>
might be, that's not a supported distro
<Guest1085>
yeah, but I have been able to build it once on the same system, it was a few months ago though
<rburton>
never seen that before, so it might be a weird thing in how git is packaged in void
seninha has joined #yocto
Guest1085 has quit [Quit: Client closed]
ptsneves has joined #yocto
goliath has joined #yocto
ccf has quit [Ping timeout: 252 seconds]
d-s-e has quit [Quit: Konversation terminated!]
amitk_ has quit [Ping timeout: 260 seconds]
ptsneves has quit [Ping timeout: 255 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian_kc has joined #yocto
roussinm has joined #yocto
<roussinm>
Is there a way to specify wheels to download? Something like in the documentation here: https://pip.pypa.io/en/stable/cli/pip_download/ where I can specify platform, python version, etc. I wanted a quick workaround to install https://github.com/wlav/cppyy in our image. At the moment I'm going to install pip in the image for the time being, but this project doesn't make it easy to integrate in yocto.
<roussinm>
Just installing x86 binary for python3.10 would be fine for now.
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
<rburton>
roussinm: it would be fairly trivial to write a class that just does a 'pip install'
<rburton>
(or recipe, if you don't care about generalising)
<rburton>
(build-appliance-image already does)
<roussinm>
I tried something like that, but I must missed something because pip was never available when trying to do that.
<roussinm>
maybe I didn't try depending on this: python3-pip-native that must be it
<rburton>
yeah you don't have pip if you don't depend on pip
<roussinm>
isn't there something that prevent downloading stuff during configure/compile phase?
ptsneves has joined #yocto
yocti has quit [Remote host closed the connection]
yocti has joined #yocto
ptsneves has quit [Ping timeout: 255 seconds]
goliath has quit [Quit: SIGSEGV]
advi[1] has joined #yocto
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 252 seconds]
Thorn has joined #yocto
<tlwoerner>
d'oh! i completely forgot do add the "changes from v2/1" sections on my patches
kscherer has quit [Quit: Konversation terminated!]
kevinrowland has joined #yocto
advi[1] has quit [Quit: Client closed]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Thorn has quit [Ping timeout: 248 seconds]
<kevinrowland>
How exactly do the files in tmp/deploy/images/*/ get removed when I clean the recipe that puts them there? Is it the magic of the sstate machinery? I'm trying to write my own BBCLASS that deploys some special test results to tmp/deploy/tests/. So far I mimicked deploy.bbclass so that my_task[sstate-inputdirs] is a directory relative to WORKDIR,
<kevinrowland>
where I place the results, and then my_stask[sstate-outputdirs] is basically ${DEPLOY_DIR}/tests/. That actually works, and my results magically show up in ${DEPLOY_DIR}/tests/. Now I want those results to be removed when I clean the recipe, but it's not working.
<kevinrowland>
Hmm, I've just discovered the manifest file in tmp/sstate-control/ -- and I see the sstate_clean_manifest function in sstate.bbclass.. still when I run :do_cleanall the files in the manifest aren't removed
<kevinrowland>
I also see that do_clean should call all of the functions in CLEANFUNCS, which includes sstate_cleanall, which calls sstate_clean_manifest. Doesn't help that I can't see the do_clean logs after running it
jmiehe has joined #yocto
jmiehe has quit [Quit: jmiehe]
azcraft has quit [Remote host closed the connection]