paulg has quit [Remote host closed the connection]
cabazon has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 276 seconds]
<gvmeson>
Someone's laptop was OOMing and when I told them about the existing tuning knobs, they asked if anyone played with /proc/PID/oom_score_adj for bitbake builds? One can just set the parent shell that should help guide the OOM killer to reap one of bitbake's child processes.
<gvmeson>
it might be nice to add a bitbake option or a shell wrapper. I may do that if they find that this approach helps.
paulg has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
sanbeam9 has joined #yocto
sanbeam18 has quit [Ping timeout: 248 seconds]
rm5248 has quit [Quit: Leaving.]
sanbeam18 has joined #yocto
sanbeam9 has quit [Ping timeout: 276 seconds]
cabazon has quit [Quit: Client closed]
sanbeam9 has joined #yocto
sanbeam18 has quit [Ping timeout: 276 seconds]
sanbeam9 has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
beneth has quit [Ping timeout: 248 seconds]
sanbeam9 has joined #yocto
sanbeam18 has joined #yocto
sanbeam9 has quit [Ping timeout: 248 seconds]
sanbeam9 has joined #yocto
sanbeam18 has quit [Ping timeout: 248 seconds]
sanbeam18 has joined #yocto
sanbeam9 has quit [Ping timeout: 276 seconds]
Daanct12 has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
<mischief>
is it possible to patch a git submodule in a sane way
<khem>
gvmeson: on latest yocto pressure handing is available, not sure which version you are at. look for BB_PRESSURE_MAX_* variables
<khem>
mischief: yes it is depending upon how you are modifying the tree, git submods are easy to work with
<mischief>
the geniuses at qorvo do a git fetch and cherry pick of upstream openthread into a submodule at compile time :-/
<khem>
ah quorvo stuff so perhaps not yocto then its MCU stuff right ?
<mischief>
no, this is the rcp that runs on the (our) host
<khem>
oh compile time fetching is a bad sign
<mischief>
right. this only appeared with the no net changes while we upgrade to scarthgap
<mischief>
i need two changes, one to remove this git fetch and another to apply the patch to the submodule, but im not sure how to do patches to submodules.
<khem>
well, you can use SRC_UTI with multiple git repos and fetch the openthread module and turn the cherry function into a dummy
<khem>
look at breakpad recipe e.g.
<mischief>
so move to two git:// SRC_URI instead of gitsm://?
<khem>
you can even try using gitsm:// fetcher
<mischief>
can devtool modify work with that to create the patch?
<khem>
yeah two repos would be more expressive
<khem>
devtool I am not sure, I usually do not use it on complex recipes yet
sanbeam18 has quit [Ping timeout: 248 seconds]
vvn has quit [Quit: WeeChat 4.5.1]
<ndeuteron>
Hello mischief, fancy seeing you here! :)
<mischief>
g'day m8
enok has joined #yocto
enok has quit [Ping timeout: 248 seconds]
enok has joined #yocto
enok has quit [Ping timeout: 252 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
florian_kc has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
goliath has joined #yocto
frgo has joined #yocto
rob_w has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
ptsneves has joined #yocto
enok71 has quit [Ping timeout: 276 seconds]
ciscokid has joined #yocto
ciscokid has quit [Client Quit]
hulk has joined #yocto
mckoan|away is now known as mckoan
rfuentess has joined #yocto
beneth has joined #yocto
florian has joined #yocto
hulk has quit [Ping timeout: 240 seconds]
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
florian has quit [Ping timeout: 248 seconds]
mulk has quit [Ping timeout: 268 seconds]
mulk has joined #yocto
leon-anavi has joined #yocto
olani has quit [Ping timeout: 272 seconds]
olani has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
vThor has quit [Read error: Connection reset by peer]
vThor has joined #yocto
vThor has quit [Changing host]
vThor has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
enok has joined #yocto
frieder has joined #yocto
gsalazar has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
enok71 has joined #yocto
tleb has quit [Remote host closed the connection]
sfo has quit [Remote host closed the connection]
raghavgururajan has quit [Remote host closed the connection]
tostr has quit [Remote host closed the connection]
jonesv has quit [Remote host closed the connection]
enok has quit [Ping timeout: 244 seconds]
enok71 is now known as enok
Vonter has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
<rburton>
ebassi: yeah very strong fan of removing the legacy image manifest and just having the spdx, i think we need to write or suggest some basic tooling to extract stuff like "what packages were in this image" from the spdx first
olani has quit [Remote host closed the connection]
<RP>
rburton: turning it off by default would be a good start
<RP>
rburton: JPEW should be sending a patch for that I hope!
Kubu_work has joined #yocto
Kubu_work has quit [Client Quit]
Kubu_work has joined #yocto
frieder has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
jonesv has joined #yocto
tleb has joined #yocto
raghavgururajan has joined #yocto
sfo has joined #yocto
tostr has joined #yocto
olani has joined #yocto
tor has quit [Quit: Leaving]
olani has quit [Ping timeout: 252 seconds]
<ebassi>
rburton: my goal is to have a CI pipeline set up some static web page like this one, populating it from the metadata: https://releases.elementary.io/
olani has joined #yocto
<ebassi>
rburton: so the spdx is definitely more appropriate
<ebassi>
I might go for the full sbom for a more detailed report, but the spdx.tar.zst is a good start for a quick overview
rob_w has quit [Remote host closed the connection]
florian_kc is now known as florian
florian has quit [Ping timeout: 276 seconds]
florian has joined #yocto
frieder has quit [Ping timeout: 272 seconds]
<RP>
ebassi: is that spdx 2.2?
rob_w has joined #yocto
frieder has joined #yocto
Tyaku has joined #yocto
teroshan has joined #yocto
<Tyaku>
Hello, When we have multiple layers, what is the good practice to update IMAGE_INSTALL ? currently what we are doing is probably uggly: We have "company layer" that contains the "product image", and in the "product image" we put IMAGE_INSTALL from differents layers, like "company bsp for board X" "layer for matter protocol" "layer for openthread". Long time ago I find peoples that was doing something
<Tyaku>
different like: Updating directly the "core image" in layer A, B, C. So that when this layers are present, the related package are automatically added to the image.
<Tyaku>
If it works, is it a good practice doing like this ?
frieder has quit [Ping timeout: 252 seconds]
<yocton>
Isn't that methode specifically forbidden by yocto-check-layer? (I have not verified it). Personaly, I do not like when BSP layers do what you describe :-/
<yocton>
I also would recommend using the dynamic-layers mecanism on a "image" layer sitting on top of every others and appending to your image depending on what layer is added or not.
frieder has joined #yocto
Chaser has joined #yocto
<rburton>
Tyaku: why can't you just have a single image in your product layer that depends on all the layers you need
Xagen has joined #yocto
florian has quit [Ping timeout: 252 seconds]
<JPEW>
RP: sent
<ebassi>
RP: we're using scarthgap, so I assume not
<RP>
ebassi: right, sadly that is 2.2. spdx 3 is much nicer as it doesn't need a tarball of docs :/
<RP>
JPEW: great thanks
<ebassi>
RP: I'll make a note, in case we can backport it to our tree
<JPEW>
ebassi: There's been talk of making a mix-in layer to backport it also, smurray was interested (among others)
<RP>
JPEW: I think we probably need to do this
<JPEW>
RP: Ya, there is enough interest that I'm pretty sure it will happen
<JPEW>
Worth bringing up on the tech call
<RP>
JPEW: agreed
<RP>
JPEW: can that example script use the bindings we have in lib/oe for spdx?
florian has joined #yocto
<JPEW>
RP: Ya, it can (assuming that's in the python library search path); I was trying to model how it would work if you wanted to make an standalone tool
<RP>
JPEW: right, I'm torn as someone using OE/bitbake likely has these pieces already so they can do it simpler. I'm not sure which is more useful...
<JPEW>
Right. The difference in my mind is do we want an example that people can use to do their own thing (in which case, I think this is more useful), or an actual tool to do a specific thing (in which case, using the existing library makes more sense)
<JPEW>
Or maybe both
<JPEW>
Perhaps some sort of additional manifest-from-spdx script would make sense
<RP>
both might be interesting if not too painful...
<JPEW>
Ya, I think the hang up for me is that I don't really like "guessing" on use cases
<RP>
JPEW: we're not trying to guess, more just show what is possible and both directions are something someone might want to do
<RP>
I think in time this will become easy/commonplace but until then...
mckoan is now known as mckoan|away
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
goliath has quit [Quit: SIGSEGV]
ptsneves has joined #yocto
dgriego has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
frgo has quit [Remote host closed the connection]
wdouglass has joined #yocto
<wdouglass>
is there a way to add a layer to a yocto project from a bitbake recipe? i have a vendor that packages their sdk (for a special piece of hardware) as a set of binary libraries and a bitbake meta-layer, but it would be nice from a CI and bringup perspective for me to treat that whole vendor package as a dependency and have bitbake unpack and install it, but also expose all of the .bb packages inside. Is there any way to accomplish this o
<wdouglass>
am i out of line here?
<rburton>
wdouglass: yeah you can't do that. though bitbake-layers makes it a one-liner to add a directory (or even a remote repo, i think) as a layer.
<wdouglass>
yeah, that's what we're doing now, i was just wondering if there was a way to streamline it from a devops perspective. thanks for the quick answer!
kienan has left #yocto [#yocto]
druppy has joined #yocto
jmiehe has joined #yocto
prabhakalad has quit [Remote host closed the connection]
jmiehe has quit [Quit: jmiehe]
florian has quit [Ping timeout: 276 seconds]
prabhakalad has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
goliath has joined #yocto
ptsneves has joined #yocto
rob_w has quit [Quit: Leaving]
Chaser_ has joined #yocto
frieder has quit [Remote host closed the connection]
frgo has joined #yocto
Chaser has quit [Ping timeout: 265 seconds]
frgo has quit [Remote host closed the connection]
frgo has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
rfuentess has quit [Remote host closed the connection]
Chaser_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
florian has joined #yocto
leon-anavi has quit [Quit: Leaving]
florian has quit [Ping timeout: 276 seconds]
gsalazar has quit [Remote host closed the connection]
piie has quit [Ping timeout: 248 seconds]
Chaser has joined #yocto
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
<kanavin>
wdouglass, I think you should make a git repo for both, and do overwrite and commit in that repo each time you get a new bundle from the vendor
<kanavin>
then fetch the layer as you would fetch any other layer
<kanavin>
and have a serious talk with the vendor, they're misusing yocto
hoyes_ has joined #yocto
piie has joined #yocto
hoyes73 has joined #yocto
frgo has quit [Remote host closed the connection]
hoyes73 is now known as hoyes
hoyes has quit [Changing host]
hoyes has joined #yocto
<wdouglass>
kanavin: no kidding, they are indeed misusing yocto, but unfortunately there's a language barrier, so I don't think i'll get anything to change. Unfortunately, I think yocto is (mis)used in different ways by many vendors -- the greatest offender i've seen is qualcomm (although they're not the vendor in question, i'll just never stop being mad at qualcomm)
hoyes_ has quit []
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
<rburton>
I hope to see Qualcomm improve in the future, fwiw
goliath has quit [Quit: SIGSEGV]
<kanavin>
wdouglass, you don't need to tell me, at some point I spent several months guiding qualcomm to fixup their layer to something resembling sanity from a safe distance
florian has joined #yocto
<wdouglass>
rburton: me too, but i'm not holding my breath, and i'm not rushing to buy qualcomm chips any time soon
<wdouglass>
kanavin: thank you for doing that work! i know its not easy
ptsneves has quit [Ping timeout: 248 seconds]
ptsneves has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 265 seconds]
dgriego has quit [Quit: Computer going to sleep]
goliath has joined #yocto
druppy has joined #yocto
dgriego has joined #yocto
<mischief>
khem: devtool modify doesn't seem to work with multiple git:// SRC_URI :(
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
frgo has joined #yocto
<RP>
mischief: there may be a bug open for that, if not there should be if it doesn't work
<jwinarsk>
I had meta-openembedded on styhead. Checking again
<jwinarsk>
yeah poky was on styhead too. Sigh
frgo has joined #yocto
<jwinarsk>
operator error. Thanks for the assist
<RP>
at least it wasn't my patch :)
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jwinarsk>
lol
frgo has quit [Ping timeout: 252 seconds]
<Saur>
RP: Please hold off on my Meson patch that adds CMake support. It seems it can lead to CMake injecting host paths into Meson's target configuration under some circumstances... :(
<RP>
Saur: rburton mentioned this earlier as potentially possible so it was on hold. I'll drop it from -next until I hear otherwise, thanks for the headsup
<Saur>
RP: Ok. I think I am on track for finding a solution, but it means I have to increase my CMake knowledge above 0%...