<vvn>
khem: meta-qt 6f82e21d60318ea9e4208470a10cc547b3b91dae breaks my build for qtwebengine. It used to work just fine without x11, now I get a "libxkbfile was skipped: missing required distro feature 'x11' (not in DISTRO_FEATURES)"
<vvn>
khem: reverting it fixes the build
<vvn>
and the build also breaks for nspr from meta-openembedded too, had to revert a9736c3
Wouter0100 has joined #yocto
sakoman has quit [Quit: Leaving.]
Guest81 has quit [Quit: Client closed]
jtoomey has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
starblue has joined #yocto
<tlwoerner>
zeddii: kernel recipes don't have a "do_patch" step?
<tlwoerner>
they have a do_kernel_metadata instead?
<yolo>
what's quilt-native for, what does native mean in yocto
<rfs613>
yolo: it means a binary that runs on your build machine (host)
<rfs613>
quilt is a tool for managing stacks of patches... kind of like git
<yolo>
yes used quilt before...I see, I was used to 'quilt-host' naming
<yolo>
in openwrt at least those are calls 'host' packages
<yolo>
s/calls/called/
<yolo>
nativesdk is also a bit odd to me, SDK by default implies a host-package(e.g. x86), is there a crosssdk? what does that even mean then
<yolo>
nativesdk makes me think it's a native sdk running on the target, as the true sdk is cross, or, just call it SDK, which imples SDK running on the host/build machine
<rfs613>
meh, naming... if we could just all agree, what would we do with all the time gained? :P
<yolo>
similarly i was thinking quilt-native is for the target, as the host does not need 'native', just call it quilt
<rfs613>
the distinction is that your host may have quilt (from ubuntu or whatever), but yocto has it's own, which they call quilt-native.
<yolo>
got it. thanks.
<rfs613>
basically to control the versions of tools used durign build, and not rely on what's installed on host system.
<yolo>
i was used to: cross-toolchain(SDK,including its own perl,python,quilt), host-tools(perl,python,quilt on x86 host originally)), native-anything -- runs on the target natively
<yolo>
e.g. an arm embedded board can have gcc installed natively in addition to be cross compiled on an x86 host
<rfs613>
and then there's canadian cross...
goliath has quit [Quit: SIGSEGV]
jmiehe has joined #yocto
Thorn has quit [Ping timeout: 272 seconds]
Thorn has joined #yocto
<yolo>
is there a shell env to play with `T="123"; A:="test ${T}"` etc to practice with bitbake syntax? devshell|devpyshell not a good fit
jclsn785 has joined #yocto
<yolo>
it's like a bitbake shell to debug recipes, similar to bash to debug shell scripts REPL way
<khem>
and report in the pull if that fixes your problem
<khem>
nspr-native is fixed in master-next already it should be in master soon
<khem>
yolo nativesdk packages are to be meant to be able to run on SDK hosts, we have build host = the machine you are building on and you can also build a cross SDK which can be installed on another host called SDK host and used to cross build packages for target like you are doing on your build host as well. nativesdk packages become like native packages but on SDK host
<khem>
the gcc on device is like any other target package in OE speak. No difference
<khem>
you can call it on-device SDK if you want to
<khem>
So on my native ( x86_64) host I build an SDK which will run on arm64 (SDK host) and generate code for riscv64 ( target )
jmiehe has quit [Quit: jmiehe]
<khem>
yolo you might use bb.debug much like printf like debugging. You can run bitbake server using bitbake --server-only
<khem>
REPL is quite powerful I agreee
<yolo>
thanks. not sure what bitbake --server-only is for though
pgowda_ has joined #yocto
sakoman has quit [Quit: Leaving.]
<vvn>
khem: qt5 fix tested ;-)
<khem>
vvn add the info to pull
<vvn>
khem: already done
<vvn>
hence the wink wink
<khem>
very good thanks
* khem
checks his eyes
GNUmoon has quit [Ping timeout: 240 seconds]
alex88 has quit [Ping timeout: 240 seconds]
alex88 has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
manuel1985 has joined #yocto
manuel1985 has quit [Ping timeout: 240 seconds]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
dtometzki has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
sakoman has joined #yocto
tnovotny has joined #yocto
cb5r has joined #yocto
kriive has quit [Remote host closed the connection]
mvlad has joined #yocto
leon-anavi has joined #yocto
florian_kc has joined #yocto
<jclsn785>
Morning
<jclsn785>
God there is another number again
<jclsn785>
In a month my nick will look like the Matrix
<jclsn785>
Why is this happening?
<mckoan>
jclsn785: you have top register your nick in the IRC server
manuel1985 has joined #yocto
<mckoan>
*have to
<jclsn785>
I did already
<jclsn785>
And I couldn't even register as jclsn
<jclsn785>
So it became jclsn7
<jclsn785>
Not it is 785
<jclsn785>
*now
<jclsn785>
Maybe I have to leave the Yocto channel in Matrix
<jclsn>
mckoan: You have been part of the project since the beginning right?
<jclsn>
I was asking myself yesterday whether the order of the layers in the bblayers.conf matters. Most people here were not sure either.
<qschulz>
jclsn: the order of layers of same priorities "matters"
<jclsn>
I am asking because in the Yocto example openembedded and poky always come first, but kas always puts them last
florian_kc has quit [Ping timeout: 250 seconds]
<jclsn>
qschulz: How can I determine the priority of a layer?
thekappe has joined #yocto
<jclsn>
I already looked in the layer.conf
<qschulz>
jclsn: kas put them last VERY likely because of your kas.yaml file
<jclsn>
I put them the other way round int he kas.yml
<jclsn>
Didn't change a thing
<thekappe>
hello guys ! I have one question.. is it possible to pass a variable to bitbake from the command line (eg: bitbake foo=bar core-image-minimal) ?
<qschulz>
jclsn: bitbake-layers show-layers I think should show the priority
<qschulz>
jclsn: BBFILE_PRIORITY_something in your conf/layer.conf
<jclsn>
So meta-webkit and meta-chromium can conflict
<qschulz>
jclsn: private pastebin
<jclsn>
Ah
<jclsn>
Thought that would mean it doesn't list on google o
<jclsn>
Public now
<jclsn>
Guess I should work with expiry dates
<jclsn>
I don't want all our company's configs lying around for everyone to see. At least not forever
<qschulz>
jclsn: I would rather have them exist forever. Otherwise, someone might see the IRC archives, click on the pastebin to have some context and won't have access to it and then the whole help session we'll do will only benefit yourself
<jclsn>
True
<qschulz>
not sure making the pastebin private or limited in time bring something to you here on this channel? (but I might be missing out on something :) )
<qschulz>
jclsn: it's a name and you can anonymise the data before putting it on the pastebin :)
<jclsn>
Ok ok
<jclsn>
Anyway, I think I should assign a higher priority to our custom layer as it mostly contains kernel and bsp modifications
florian has joined #yocto
GNUmoon has joined #yocto
<thekappe>
@qschulz, I couldn't find the information in the link you've just sent me
<thekappe>
the proposed variables seems to be the ones used inside a recipe
<qschulz>
thekappe: what is it that you want to do?
<thekappe>
bitbake foo=bar core-image-minimal
<thekappe>
supposing that there is a recipe using the foo variable
<qschulz>
yes, so you need to tell bitbake this environment variable can be used
<qschulz>
because by default the environment variables are not used, as you saw
<qschulz>
so I sent you a link to the bitbake variable you need to set in order to pass environment variables through bitbake
<qschulz>
you need to add it to your local.conf
<thekappe>
it's used in my build/conf/local.conf to set another variable
<JaMa>
is someone collecting interesting performance statistics during OE builds? I'm thinking about adding some graphs to my results in test-oe-build-time to better show how bad and how long the memory usage peaks actually are during different build setups (number of threads)
<jclsn>
Also don't know how to relate these version numbers to 3.0.2 or 2.6.3
<rburton>
JaMa: the oe-build-perf scripts/machines collect some data, would be interesting to add memory usage
cb5r has quit [Quit: cb5r]
cb5r has joined #yocto
<JaMa>
mem usage, swap, disk io, load seem obvious, but maybe something else would be nice to include
* JaMa
will have a look at oe-build-perf-test, I think I haven't used this one before (only the matrix build maybe 15 years ago :))
sinko has joined #yocto
<JaMa>
scripts/contrib/bb-perf/bb-matrix.sh
<rburton>
JaMa: its what the build-perf machines in the autobuilder run, so there are reliable metrics over time
<rburton>
i havent actually looked at the numbers for a while, which is bad.
<JaMa>
I was planing to install prometheus or something new and fancy
<sinko>
Hello everyone, I installed an openvpn server on ubuntu. I also installed openvpn client in Yocto. However, on the yocto side, I am getting an openvpn client error in runtime. the error is as follows:
<sinko>
Mar 11 10:33:58 x-rp432 systemd[1]: Starting OpenVPN Robust And Highly Flexible Tunneling Application On client...
<sinko>
Mar 11 10:33:58 x-rp432 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mopenvpn@client.service: Control process exited, code=exited, status=1/FAILURE[[0m
<sinko>
Mar 11 10:33:58 x-rp432 systemd[1]: [[0;1;38;5;185m[[0;1;39m[[0;1;38;5;185mopenvpn@client.service: Failed with result 'exit-code'.[[0m
<sinko>
Mar 11 10:33:58 x-rp432 systemd[1]: [[0;1;31m[[0;1;39m[[0;1;31mFailed to start OpenVPN Robust And Highly Flexible Tunneling Application On client.[[0m
<sinko>
I couldn't find what caused it. Is there anyone who can help?
<JaMa>
but if build-perf collects all I need, then it will be easier to document in test-oe-build-time for others to share comparable results
robertd[m] has left #yocto [#yocto]
<rburton>
JaMa: that is the new hotness, for sure. bonus points for throwing buildstats information into the same store so you can see a spike and easily correlate that to what tasks a running :)
<sinko>
I created openvpn folder in etc. I put the ca.crt, client.crt, client.key, client.conf files that I created on the server into it.
<rburton>
sinko: did you look at the log for that unit in the journal?
<JaMa>
rburton: not sure how much time I'll actually spend on this, the workstation is already running for 3 days refreshing the results for honister, for kirkstone I just wanted to capture "a bit more" :)
<sinko>
I did not add the syslog to the image.
<rburton>
sinko: journald is part of systemd
<JaMa>
and the weather is getting warmer, so I don't need this 70C heather on all the time :)
xmn has quit [Quit: ZZZzzz…]
<sinko>
I think, im either looking at it in the wrong place or im missing it.
<sinko>
rburton I couldn't find any logs in journal.
<sinko>
rburton These are the log outputs I found with journalctl -u openvpn@client, nothing more.
<sinko>
Mar 11 10:47:02 x-rp432 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39m/lib/systemd/system/openvpn@.service:8: PIDFile= references a path below legacy directory /var/run/, updating /var/run/openvpn/client.p
<sinko>
id → /run/openvpn/client.pid; please update the unit file accordingly.[[0m
<sinko>
Mar 11 10:47:24 x-rp432 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39m/lib/systemd/system/openvpn@.service:8: PIDFile= references a path below legacy directory /var/run/, updating /var/run/openvpn/client.p
<sinko>
id → /run/openvpn/client.pid; please update the unit file accordingly.[[0m
<sinko>
Mar 11 10:47:32 x-rp432 systemd[1]: Starting OpenVPN Robust And Highly Flexible Tunneling Application On client...
<sinko>
Mar 11 10:47:32 x-rp432 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mopenvpn@client.service: Control process exited, code=exited, status=1/FAILURE[[0m
<sinko>
Mar 11 10:47:32 x-rp432 systemd[1]: [[0;1;38;5;185m[[0;1;39m[[0;1;38;5;185mopenvpn@client.service: Failed with result 'exit-code'.[[0m
<sinko>
Mar 11 10:47:32 x-rp432 systemd[1]: [[0;1;31m[[0;1;39m[[0;1;31mFailed to start OpenVPN Robust And Highly Flexible Tunneling Application On client.[[0m
<qschulz>
sinko: try without units first if you can
<sinko>
"journalctl" output:
<sinko>
Sep 20 10:43:59 x-rp432 kernel: Booting Linux on physical CPU 0x0
<sinko>
Sep 20 10:43:59 x-rp432 kernel: [[0;1;39m[[0;1;31m[[0;1;39mLinux version 5.
<sinko>
4.72-v7l (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP Mon Oct 19 11:12:20
<JaMa>
sinko: use pastebin and I believe "without units" was meant as trying to run openvpn by hand instead of systemd, not pasting whole journalctl output
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
<qschulz>
JaMa: yes, thank you for clarifying
<sinko>
im new so i dont know much. thank you for the information. i will share the log after running it manually.
cb5r has quit [Quit: cb5r]
cb5r has joined #yocto
sinko has quit [Quit: Client closed]
goliath has joined #yocto
bradfa has joined #yocto
robertd[m] has joined #yocto
<robertd[m]>
hey guys
<robertd[m]>
is there a way to cache lfs?
<robertd[m]>
the `do_unpack` task seems to reach out to fetch lfs each and every time
JaMa has quit [Quit: reboot]
JaMa has joined #yocto
<jclsn>
JPEW: Does Pyrex build with its own toolchain or does it use my local toolchain?
<rburton>
pyrex is a container which has its own native toolchain
<rburton>
its based on ubuntu 20.04
<JPEW>
jclsn: yes it grew. We made the "oe" containers able to run oe-selftest
<jclsn>
I was just wondering what changed, because I am experiencing problems with my build
<jclsn>
It is either caused by kas 3.0.0, which I use to checkout or by the Pyrex toolchain
<jclsn>
I think I using both is too much tooling. It makes debugging harder
<mckoan>
do we have any recipe example showing how to define SRC_URI for an Azure private repo ?
<mckoan>
git repo
<JPEW>
jclns: both is untested for sure. I don't use kas
<thekappe>
mmmm long story short.. I've put in local.conf:
<thekappe>
BB_ENV_EXTRAWHITE += " SW_REV"
<thekappe>
MY_SW_REV="${SW_REV}"
<thekappe>
then in my image/rootfs/etc/os-release I get
<thekappe>
MY_SW_REV="${SW_REV}"
<thekappe>
after running:
<thekappe>
$ SW_REV=next bitbake my-image
<thekappe>
any idea on how to get SW_REV correctly expanded in /etc/os-release ?
<qschulz>
thekappe: check with bitbake -e that BB_ENV_EXTRAWHITE is correctly set and if SW_REV is set (not sure if it's printed or not in the log though this one)
<jclsn>
EXTRAWHITE sounds like tooth whitener
<thekappe>
qschulz, running bitbake -e shoes that BB_ENV_EXTRAWHITE="....... SW_REV", btw SW_REV is not defined
<thekappe>
moreover: I get the same result using d.getVar
<thekappe>
btibake -e | grep SW_REV
<thekappe>
....
<thekappe>
....
<thekappe>
# $MY_SW_REV
<thekappe>
# "${@d.getVar('SW_REV')}"
<thekappe>
MY_SW_REV="None"
<jclsn>
Could clam be the reason for my error? Any experiences??
<jclsn>
I know from Windows that compiling and anti-virus programs don't get along well
<rburton>
turn it off and see, i guess
sakoman has joined #yocto
<rburton>
jclsn: have you ran diffoscope over two images yet to see *where* the differnces are?
pgowda_ has quit [Quit: Connection closed for inactivity]
<jclsn>
rburton: Yes, but the differences are to many. Plus, I don't speak binary
<rburton>
are they all over the image, or just the kernel
<rburton>
if you have reproducible builds and the same SHAs, then the filesystem should be identical
<kayterina[m]>
Hello. I am looking for the python3 interpreter. I did 'bitbake -s | grep ^python3' but there is no python3-core. The ultimate goal is to use the yocto's machine python for crossenv
<jclsn>
I just builts successfullx
<jclsn>
rburton
<jclsn>
Pyrex is the problem
<jclsn>
If I build with kas, it works
<rburton>
pyrex is triggering the problem. it's just a container :)
<jclsn>
Yeah the Pyrex's container
<jclsn>
*then
<jclsn>
Ah nevermind
<jclsn>
I just didn't flash cleanly
<jclsn>
I am still clueless
<jclsn>
Horrible
<jclsn>
I really hope it is clam
pasherring has joined #yocto
xmn has joined #yocto
<jclsn>
rburton: I have reproducible builds on and just checked the kernel
<jclsn>
I could use my colleagues kernel and boot, so that is where the issue lies
<jclsn>
I am currently just building kernel with all different combinations
<jclsn>
My machine is cursed
<rburton>
running memcheck is always worth a go, bad ram does cause all sorts of fun things
<pasherring>
this plagued me just yesterday. BTW, thanks for the tip, rburton .
<pasherring>
I reduced a bit ram frequency on the build machine and the memtest started passing.
<pasherring>
This is obviously just paliative, I need to pick up some new ram modules :)
<tlwoerner>
RP: ignore what i said last night, removing threads and parallel had the same random chance of success/fail on my jenkins last night as it did with them in the config
<jclsn>
rburton: I have also thought about that
<jclsn>
If this is the case, I won't buy a ThinkPad with onboard RAM anymore
<qschulz>
jclsn: building yocto on a laptop does not make much sense anyway
<qschulz>
(and I'm saying this from my Thinkpad T15 Gen 1 which is unbearably slow compiling stuff
<jclsn>
qschulz: I have the same remember?
<jclsn>
My boss wants to give me his old tower, which should be a bit slower. Has like 12 cores I think
<prabhakarlad>
Hi all, has anyone hit the below issue on meta-riscv
<prabhakarlad>
x86_64-oesdk-linux/usr/lib/riscv64-oe-linux/gcc/riscv64-oe-linux/9.3.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
<prabhakarlad>
9 | # include_next <stdint.h>
<jclsn>
But I can't take that home. Would have to talk with the IT to be able to SSH into it
<jclsn>
Which is painful ^^
<jclsn>
Our IT is big crap
robertd[m] has left #yocto [#yocto]
<jclsn>
I am currently setting up a CI pipeline with a 20-core runner, but I couldn't get it to work yet
<jclsn>
At some point I will run through the company screaming THREADRIPPER!!!!!!
<jclsn>
but the 64-core version is easily at 10.000 €...
<rfs613>
jclsn: watch out, they may come for you with a fancy jacket, and carry you off to the dungeon in the basement...
<qschulz>
jclsn: 10k is usually a small-ish budget for companies
<qschulz>
jclsn: setting up a jenkins/gitlab/whatever pipeline with a VERY powerful server might be easier to sell to your boss
<jclsn>
rfs631: Yeah I should better write it via email
<jclsn>
qschulz: That is my plan
manuel1985 has quit [Ping timeout: 252 seconds]
<rburton>
worth doing the sums for a CI setup on AWS or similar with spot instances for the builds
<jclsn>
When that Gitlab pipeline is ready I will see
<rburton>
spot instances that are bought up to build as needed, with SSTATE_DIR shared over EFS
xmn has quit [Ping timeout: 240 seconds]
kyrix has joined #yocto
cb5r has quit [Ping timeout: 240 seconds]
kyrix has quit [Ping timeout: 245 seconds]
Guest23 has joined #yocto
<Guest23>
How can I trigger a download of uninative-tarball in yocto?
manuel1985 has joined #yocto
thekappe has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
<rburton>
build something, anything
<rburton>
if you want to reload, delete it from DL_DIR and wipe tmp/
troth has joined #yocto
<Guest23>
rburton ok. is there any benefit building my own uninative-tarball?
manuel1985 has quit [Ping timeout: 268 seconds]
<rburton>
none at all
<rfs613>
well, depends if you wear a tin foil hat ;-)
<rburton>
if you wear tin foil then turn off uninative :)
<rfs613>
bingo :
<rfs613>
(for the record, my tin foil hat is safely stored in a dark drawer, just in case I need it someday)
manuel1985 has joined #yocto
florian_kc has quit [Ping timeout: 272 seconds]
florian has quit [Quit: Ex-Chat]
Guest23 has quit [Quit: Client closed]
manuel1985 has quit [Ping timeout: 250 seconds]
<pasherring>
ro
<pasherring>
ops :\
manuel1985 has joined #yocto
<rfs613>
kanavin: I was not aware of meta-lts-mixin, thanks for the pointer. And I see it has goland/docker which is of interest to my client. I will take a closer look soon, maybe have some questions.
<kanavin>
rfs613, sure
dev1990 has quit [Quit: Konversation terminated!]
cb5r has joined #yocto
camus has quit [Quit: camus]
kyrix has joined #yocto
<khem>
prabhakarlad: what are using building, explain the situation a bit more
<prabhakarlad>
khem: Im trying to build the Renesas FlashWriter utility with the SDK installed (I am using dunfell release). I even created a recipe to build the utility and still seeing the exact same issue.