invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
gho has quit [Ping timeout: 264 seconds]
gho has joined #yocto
sakoman has quit [Quit: Leaving.]
amitk has joined #yocto
<PhoenixMage>
tlwoerner: FYI, one of the radxa devs has an up to date mainline u-boot that works with Rock 3a, I believe they are submitting patches
demirok has quit [Quit: Leaving.]
amitk_ has joined #yocto
alessioigor has joined #yocto
demirok has joined #yocto
goliath has joined #yocto
sgw has joined #yocto
goliath has quit [Quit: SIGSEGV]
Lihis has quit [Read error: Connection reset by peer]
Lihis_ has joined #yocto
Lihis_ is now known as Lihis
rob_w has joined #yocto
Payam has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<LetoThe2nd>
yo dudX
invalidopcode1 has quit [Read error: Connection reset by peer]
invalidopcode1 has joined #yocto
Jham has joined #yocto
mckoan_ is now known as mckoan
<mckoan>
good morning
davidinux has quit [Quit: WeeChat 3.5]
goliath has joined #yocto
manuel1985 has joined #yocto
mvlad has joined #yocto
thomasd13 has joined #yocto
rfuentess has joined #yocto
Schlumpf has joined #yocto
zpfvo has joined #yocto
xmn has quit [Quit: ZZZzzz…]
vladest has quit [Ping timeout: 255 seconds]
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
leon-anavi has joined #yocto
Haxxa has quit [Remote host closed the connection]
Haxxa has joined #yocto
d-s-e has joined #yocto
davidinux has joined #yocto
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
frieder has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
d-s-e has quit [Ping timeout: 260 seconds]
gsalazar has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
<qschulz>
o/
florian has joined #yocto
ptsneves has joined #yocto
amitk_ has quit [Ping timeout: 252 seconds]
<ptsneves>
Good morning all :)
florian_kc has joined #yocto
manuel__ has joined #yocto
manuel1985 has quit [Ping timeout: 256 seconds]
ArgaKhan has joined #yocto
<ArgaKhan>
Hello. I ran Bitbake and it's now at its 243rd hour. Is this normal? No freezing or stuttering but it seems like it took too long. qtdeclarative_do-compile, icedtea7-native_do-compile, qtbase_do-package-write-deb, gcc_do-package-write-deb, binutils_do-package-write-deb, librsvg_do-package-write-deb, libwebp_do-package- libwebp_do-package-write-deb seems to be in progress.
ArgaKhan has quit [Remote host closed the connection]
ArgaKhan has joined #yocto
<JaMa>
10 days is a bit too much
<ArgaKhan>
JaMa: I'm also afraid to cancel because I thought it froze in 140 hours and canceled :(
vladest has quit [Remote host closed the connection]
<JaMa>
any OOMK in dmesg?
<JaMa>
check e.g. htop if there is any visible load from bitbake triggered processes, if not then something went wrong
<JaMa>
even if you cancel it, it should reuse all finished tasks
<ArgaKhan>
I'm on tty3 screen, will bitbake be canceled if I switch to tty1?
vladest has joined #yocto
<JaMa>
no
<ArgaKhan>
now the ethernet lights are not working either I tried to connect via ssh but
vladest has quit [Client Quit]
vladest1 has joined #yocto
vladest1 has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
<ArgaKhan>
I searched for bitbake in htop. Time writes 0 and cpu mem usage is 0.
vladest has quit [Read error: Connection reset by peer]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest1 has joined #yocto
<ArgaKhan>
There is an error in dmesg: Out of memory: Killed process 3237 (Cooker) total-vm:1131408kB, anon-rss:69296kB, file-rss:0kB, shmem-rss:32kB, UID:1000 pgtables:1980kB oom_score_adj:0
vladest1 has quit [Client Quit]
vladest has joined #yocto
<ArgaKhan>
likewise surfshark got killed
<JaMa>
ArgaKhan: than you need more RAM or at least swap
<JaMa>
you can keep PARALLEL_MAKE, but still add more swap
<ArgaKhan>
ok then
<ArgaKhan>
thank you
<JaMa>
qtdeclarative isn't too demanding, but if your image includes something like qtwebkit/qtwebruntime then you'll need more than 8+2g
<ArgaKhan>
yes it contains. just in case I'm allocating 144 gb swap :D
<JaMa>
and it should finish in lets say 24 hours, if it's running again for more than 100 then cancel it for sure and check htop/dmesg
<JaMa>
probably less as you might be half-way done
<ArgaKhan>
Let's see. thanks
frieder has quit [Ping timeout: 256 seconds]
amitk_ has quit [Ping timeout: 246 seconds]
frieder has joined #yocto
amitk_ has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
frieder has quit [Ping timeout: 264 seconds]
manuel1985 has joined #yocto
manuel__ has quit [Ping timeout: 256 seconds]
frieder has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
sa7mfo has joined #yocto
<sa7mfo>
Is there a good way to get rid of "WARNING: Duplicate inclusion for /work/layers/meta-xxx-base/recipes-core/images/xxx-image.bb"? I have several layers that are built on top of each other and every layer is adding something to the previous image file. Is there a good way to build such hiarchy without getting that warning?
<sa7mfo>
I use "require" to include the image files
<mckoan>
sa7mfo: .bbappend ?
<JaMa>
sa7mfo: use require only once per path
<sa7mfo>
sorry, I will try to rephrase. I have X.bb and X-dev.bb. X-dev.bb requires X.bb. Another meta-layer has Y.bb that requires X.bb and Y-dev.bb that requires X-dev.bb
<JaMa>
and which one is included multiple times?
d-s-e has joined #yocto
demirok has quit [Quit: Leaving.]
<JaMa>
rburton: still breaking "git am"? seen in ppp patch
<rburton>
damn it sorry
<JaMa>
np :)
davidinux has joined #yocto
<sa7mfo>
JaMa: shorturl.at/eiuv5 Most of the files is included multiple times now :/
demirok has joined #yocto
alessioigor has quit [Quit: alessioigor]
<sa7mfo>
I will try to work something out with bbappaned instead
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
vladest has quit [Remote host closed the connection]
<JaMa>
sa7mfo: ok, you forgot to say that Y-dev requires both Y as well as X-dev, but it's shown in the digraph
vladest has joined #yocto
zpfvo has joined #yocto
<JaMa>
in our case we have similar hiearchy of layers (4 levels), but with X.inc and dev.inc, so upper layers can include various .inc without multiple includes
<JaMa>
as well as .bbclass for more "generic" image features to inherit
frieder has quit [Ping timeout: 252 seconds]
vladest has quit [Remote host closed the connection]
frieder has joined #yocto
amitk_ has quit [Ping timeout: 264 seconds]
* alessioigor
waves all
<alessioigor>
FYI If I add api-documentation in the DISTRO_FEATURES (honister) the recipe upower stops to be built:
<alessioigor>
Is there a way to disable api-documentation effects for that recipe?
<alessioigor>
Thanks!
<JaMa>
alessioigor: try it with supported release and if it works there you might be able to find which fix to backport
frieder has quit [Ping timeout: 268 seconds]
sakoman has joined #yocto
<rburton>
alessioigor: set GTKDOC_ENABLED="False" in the recipe (or in your distro/local.conf with GTKDOC_ENABLED:pn-upower)
<alessioigor>
JaMa, rburton: Thanks!
xmn has joined #yocto
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
amitk_ has joined #yocto
frieder has joined #yocto
amitk_ has quit [Ping timeout: 246 seconds]
amitk_ has joined #yocto
td40 has joined #yocto
<td40>
Hi,
<td40>
I might have some resources to work on devtool to support multiple versions on recipes. I'd like it to work with multiple versions of for example kernel recipe with changing PREFERRED_VERSION and keeping multiple sources versions in workspace/sources, workspace/appends. It would improve a lot in workflow in my company. Would you be open for such
<td40>
contribution?
<qschulz>
td40: mmm I thought this was already supported? what are you missing or rather, what's your issue?
<qschulz>
because I did a devtool modify u-boot on kirkstone, it found my preferred provider (u-boot-tsd) and created a bbappend in the devtool workspace called u-boot-tsd_2022.10.bbappend
<qschulz>
td40: ah, I see that the sources onlyu have the name of the recipe and not its version
Schlumpf has joined #yocto
<td40>
I might oversleep some big change but last time I checked it was not supported. I will come back to you, but yes, I'd love it to contain multiple versions of sources as well, so developers could work parallel on kernel master and master_next :)
<td40>
I'll verify, but I think it's still not fully supported
thomasd13 has quit [Ping timeout: 256 seconds]
<qschulz>
td40: in any case, I assume if we get proper tests of the new feature(s) and it makes sense, that should be ok
<td40>
great, thank you for quick answer :)
amitk_ has quit [Ping timeout: 252 seconds]
<qschulz>
the issue is we don't have a devtool maintainer, so until we get a patch to look at, I guess there's not much more we can say :/ ?
<td40>
right:D then I'll probably go back with a patch in some long time:) thanks
<landgraf>
qschulz: or volunteer to be a maintainer :-)
<td40>
I need to think about that. I did some patches to devtool already so I know the code. Is there some requirements I need to meet to become a maintainer?
<td40>
besides having a lot of time
<landgraf>
a lot of time... who has this?
<qschulz>
td40: I would guess doing reviews of patches to devtool, fix or help fixing issues in devtool when they arise?
<td40>
that I know:D I thought of some formal requirements. but seems not :)
<qschulz>
td40: https://git.yoctoproject.org/poky/tree/MAINTAINERS.md#n41 a patch against this to make it official if you want :) but I don't think we require anything. In any case, just providing reviews/acked-by/reviewed-by even if you're not officially listed as maintainer is *really* helpful
rob_w has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
d-s-e has quit [Quit: Konversation terminated!]
amitk_ has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
amitk_ has quit [Ping timeout: 256 seconds]
manuel__ has joined #yocto
manuel1985 has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
Schlumpf has quit [Quit: Client closed]
<kergoth>
Hmm the older distro crops docker images are busted due to use of too-new buildtools tarballs. Don't wnat to be using a 4.1 buildtools tarball, the newer python breaks with older yocto stable branches
amitk_ has joined #yocto
barometz_ is now known as barometz
<rburton>
RP: hm sdk packaging should be reusing the image_types logic. i wanted to switch to something not-xz as it takes forever but that's not trivial.
<RP>
rburton: I think I ended up concluding it wasn't worth the pain
<rburton>
unifying it seems like a sensible thing to do if its not a lot of effort, considering its not trivial to eg experiment with tar.zstd SDKs.
<rburton>
i'll put it on my backlog of things to look at. shouldn't be *too* difficult, especially if we refactor a bit of the image code at the same time into a nice module :)
<RP>
rburton: I can understand users needing different image outputs, having multiple sdk types didn't seem to have as much of a need
<RP>
rburton: the image code is horrible, last time I looked there were other areas that needed work in priority
ArgaKhan has quit [Remote host closed the connection]
Jham has quit [Quit: Leaving]
goliath has joined #yocto
td40 has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
gho has quit [Quit: Leaving.]
<kergoth>
sdk packaging is a mess in some other ways too, it acts like it should support formats other than shar, but you can't relocate without it since all the logic is embedded into the shar instead of split out
<kergoth>
been meaning to submit a change to split it all out into relocate_sdk.sh one of these days
gho has joined #yocto
zpfvo has quit [Remote host closed the connection]
kscherer has joined #yocto
pidge_ is now known as pidge
rfuentess has quit [Remote host closed the connection]
<dacav>
Hi. I'm writing a .bbclass that all my recipes are going to INHERIT. Is there a way to collect data in a single build-global variable?
xmn has quit [Ping timeout: 260 seconds]
mckoan is now known as mckoan|away
alessioigor has quit [Quit: alessioigor]
<qschulz>
dacav: no, because the bbclass is just included verbatim in the recipe and recipe data is local to the recipe
xmn has joined #yocto
<dacav>
I see. And what about DEPLOYDIR? Can I `inherit deploy` from my bbclass in order to get DEPLOYDIR? Will this force all the recipes to implement on_deploy?
<dacav>
My goal would be to collect certain information for each built recipe, then aggregate it all as last step
florian has quit [Quit: Ex-Chat]
<qschulz>
dacav: that makes sense yes. you would still need to write the do_deploy task to deploy something into DEPLOYDIR
<qschulz>
dacav: I would also look into how we manage license.manifest because this is also a collection of artifacts from multiple recipes
<dacav>
Thanks for the hint!
florian_kc has quit [Ping timeout: 268 seconds]
xmn_ has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
<dacav>
qschulz: what if I inherit deploy from my.bbclass, I write a do_deploy, then I put INHERIT += "my" in my local.conf. Will this break recipes that declare themselves a do_deploy?
<qschulz>
dacav: yes
<dacav>
ouch, not what I want probably :)
<qschulz>
so you can borrow the same mechanism as deploy bbclass but use different names and sstate paths I believe
<qschulz>
or maybe simply using do_deploy:append would be enough
<dacav>
Or can I read the variables of the recipes I DEPEND upon?
<qschulz>
you want to read a variable in recipe A from recipe B where in recipe B you have DEPENDS = "recipe-a" ?
<dacav>
yep
<qschulz>
nope, not possible, recipe a data is local to recipe a and cannot be accessed outside of it
<qschulz>
you could (ab)use the sysroot to communicate info between recipes but I would not recommend
<dacav>
Right... otherwise the answer to the previous question about global variable would have been yes. Sorry :D
<rburton>
dacav: what are you actually trying to do?
<dacav>
rburton: I need to put together a report for licensing purposes. license.manifest is covering already part of my needs. I've attempted to use meta-doubleopen (buggy) and meta-spdxscanner (buggy and depening on python2).
<dacav>
I figured I could get away with less than the whole SPDX for each recipe
<rburton>
why not use the built in spdx stuff, then you don't need to write anything
<rburton>
also you can get more info out of the license code, what is it you actually want?
<dacav>
What spdx stuff would you recommend me to look at?