zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
camus has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
camus has quit [Quit: camus]
camus has joined #yocto
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #yocto
xmn has joined #yocto
xmn has quit [Remote host closed the connection]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #yocto
silbe has quit [Ping timeout: 240 seconds]
sakman has joined #yocto
jmd has joined #yocto
emdevt has joined #yocto
sakman has quit [Quit: Leaving]
jmd has quit [Remote host closed the connection]
sakman has joined #yocto
brrm has quit [Ping timeout: 240 seconds]
brrm has joined #yocto
rob_w has joined #yocto
emdevt has quit [Remote host closed the connection]
emdevt has joined #yocto
alessioigor has joined #yocto
Guest72 has joined #yocto
Guest72 has quit [Quit: Client closed]
Chocky1 has quit [Ping timeout: 255 seconds]
Chocky1 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w_ has joined #yocto
mvlad has joined #yocto
rfuentess has joined #yocto
mckoan|away is now known as mckoan
Kubu_work has joined #yocto
frieder has joined #yocto
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
Schlumpf has joined #yocto
olani- has joined #yocto
lucaceresoli has joined #yocto
belsirk has joined #yocto
ptsneves has quit [Ping timeout: 240 seconds]
rfuentess has quit [Ping timeout: 255 seconds]
pabigot has quit [Ping timeout: 240 seconds]
varjag has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
pabigot has joined #yocto
Daanct12 has joined #yocto
michaelo has joined #yocto
radanter has joined #yocto
zpfvo has joined #yocto
<Rich_1234>
Hello everyone, good morning from England. I am trying to get my TI board up and running a graphical demo. I can run glmark2-es2-wayland & glmark2-es2-drm. However I am failing to open an EGL window with SDL2, so I am wondering if either a driver is not configured properly or somewhere something isn't configured. modetest reports that attempting
<Rich_1234>
any device fails. Now I think the problem I am having is I am not too sure on what device I expect to see open (potentially imx-drm if im using an imx chip?) or how to tell if my graphics is configured properly so I was wondering if anyone had some good resource suggestions for learning about embedded graphics drivers & learn more about what
<Rich_1234>
exactly krmdrms / omap is and how to really use modetest and so forth
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
Dracos-Carazza_ is now known as Dracos-Carazza
pabigot has quit [Ping timeout: 248 seconds]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<emdevt>
What is your SoC ?
leon-anavi has joined #yocto
<Rich_1234>
emdevt Right now I am using the AM68 evaluation module
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
<emdevt>
Never used that one. What is your gui framework? QT ?
Schlumpf has quit [Quit: Client closed]
<Rich_1234>
Just pure OpenGLES with SDL2 to open a window, I did have an example of running the SDL window with opengl rendering on this board before
<emdevt>
Ok. I've always used QT with eglfs and getting that eglfs stuff built and deployed correctly is always pain. So maybe someone else could fill gaps here.
<Rich_1234>
Alright, thanks anyway. I did have a problem with the rendering crashing the board, posted to TI forums and they would update it and 6 months have passed and now I have 6 months of commits added since the last demo. So things may have changed
<emdevt>
Yeah, I mainly use buildroot for my stuff - but yocto in my day job. So peeking that side might be useful as well.
pabigot has joined #yocto
linfax has joined #yocto
florian_kc has joined #yocto
<Rich_1234>
Yeah, I did get an embedded linux book that introduced both buildroot and yocto, but I have been using yocto mostly. And found it way easier to use than the TI SDK at least
<emdevt>
What display you're using with that board?
<Rich_1234>
Just a standard 1920*1080 display that I am using for my regular machine that I plug an hdmi cable into
olani- has quit [Read error: Connection reset by peer]
<emdevt>
I do same with RPi's - I have eglfs as QT backend on those as well.
olani- has joined #yocto
<Rich_1234>
Right, we did use QT for another project but moved away using Qt because of their licencing terms. Otherwise yeah it probably would be easier using that
<emdevt>
My QT projects are open source, so no license issues. But I would assume that staying in 5.12 (?) prevents most of that gplv3 trouble.
emdevt__ has joined #yocto
<JaMa>
well staying on unsupported 5.12 avoids license issue, but causes other issues (like security issues where you cannot easily cherry-pick the fix from newer version as it might violate the license)
<emdevt__>
Agree. That's why I segment my implementation strictly to UI functionality. No network stuff etc from QT
<JaMa>
so you got affected by only half of the security issues? :)
<emdevt__>
Yes :)
<Rich_1234>
It was a little outside my domain but I am working for a medical device company, and one of the engineers got in touch with a lawyer and discussed terms but it wasn't made clear if our product fell into a specific category but if I did we would need to pay the yearly subscription and back pay it. And then there was part of it about allowing the
<Rich_1234>
user to upgrade a specific library which for a medical product isn't ideal because you want to lock down library versions right
emdevt has quit [Ping timeout: 260 seconds]
<Rich_1234>
But anyway, now i'm just on a proof of concept
<emdevt__>
Rich_1234 - we're on same table. I have medical thing here as well with same issue.
<Rich_1234>
oh :(
<emdevt__>
However that does not use QT. I tend to stick to QT on my personal stuff.
<Rich_1234>
Am i allowed to ask what you use for rendering or is that a secret
ptsneves has joined #yocto
florian_kc is now known as florian
<emdevt__>
On that medical device?
<Rich_1234>
Yeah on the non personal stuff
<emdevt__>
I think I cannot go in details there. But there are options, but better (or more secure) than QT - I don't know.
<Rich_1234>
Right, yeah I understand
Chocky1 has quit [Quit: Leaving.]
Chocky has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.5]
Daanct12 has joined #yocto
Chocky has quit [Client Quit]
Chocky1 has joined #yocto
Chocky1 has quit [Client Quit]
Chocky2 has joined #yocto
Chocky2 has quit [Client Quit]
Chocky1 has joined #yocto
Chocky1 has quit [Client Quit]
Chocky has joined #yocto
Chocky1 has joined #yocto
Chocky1 has quit [Client Quit]
Chocky has quit [Client Quit]
Chocky has joined #yocto
Chocky1 has joined #yocto
Chocky has quit [Client Quit]
rob_w has quit [Ping timeout: 260 seconds]
rob_w_ has quit [Ping timeout: 246 seconds]
rob_w has joined #yocto
rob_w_ has joined #yocto
rob_w has quit [Ping timeout: 240 seconds]
rob_w__ has joined #yocto
rfuentess has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
belsirk has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tnovotny has joined #yocto
Xagen has quit [Ping timeout: 252 seconds]
silbe has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
diecore has joined #yocto
tnovotny has quit [Ping timeout: 255 seconds]
<diecore>
Hello guys. I have issue trying to add a new driver and test it with devtool in yocto. I have a weird behavior: I've run devtool modify our-linux-kernel and then did the changes to add the it6664 driver boilerplate. I can see the new driver choice and I enable it as module from the make menuconfig. My problem is that after generating the .config file if I try devtool build our-linux-mchp the kernel fails to build because it complains: The
<diecore>
source tree is not clean, please run 'make mrproper'
<diecore>
I can't run make mrproper because it erases the custom .config file and the new driver is not enabled
kayterina3 has joined #yocto
amsobr has joined #yocto
tnovotny has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Xagen has joined #yocto
kayterina3 has quit [Remote host closed the connection]
jmd has joined #yocto
olani- has quit [Remote host closed the connection]
<jmd>
Which package provides /bin/vi ?
<jmd>
"opkg search /bin/vi" yields nothing :(
<rburton>
busybox
<jmd>
What else!
<jmd>
That provides everything!
<rburton>
assume busybox unless told otherwise :)
Chocky has joined #yocto
<jmd>
I suppose it's responsible for /bin/less too
Chocky1 has quit [Read error: Connection reset by peer]
<rburton>
indeed
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
frieder has quit [Ping timeout: 260 seconds]
belsirk has joined #yocto
tnovotny_ has joined #yocto
zhmylove has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
tnovotny has quit [Ping timeout: 258 seconds]
frieder has joined #yocto
<RP>
jmd: busybox provides many things through update-alternatives and symlinks so ls -la /bin/vi probably gives a clue too
<jmd>
RP: Thanks.
frieder has quit [Ping timeout: 255 seconds]
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
florian_kc has joined #yocto
kayterina3 has joined #yocto
zpfvo has quit [Ping timeout: 258 seconds]
zpfvo has joined #yocto
<kayterina3>
Hello, how is "INITSCRIPT_PACKAGES" used? I want to add multiple init scripts with one single recipe. I tried to create a new PACKAGE and append th INITSCRIPT* variables but the script is not included in the final image under /etc/rcX/
frieder has joined #yocto
<kayterina3>
If I use "initscripts_1.0.bb" and call update-rc.d from do_install() it works.
diecore has quit [Remote host closed the connection]
rob_w__ has quit [Quit: Leaving]
<KanjiMonster>
I want to do cve_check for an image without actually building the image, is there an easy way? e.g. bitbake -c cve_check core-image-minimal throws an error in a fresh environment (e.g. "Task do_cve_check does not exist for target core-image-minimal")
<KanjiMonster>
(using kirkstone)
emdevt__ has quit [Quit: Leaving]
prabhakarlad has joined #yocto
<mckoan>
kayterina3: inherit the cve-check class in local.conf then run bitbake core-image-minimal
<mckoan>
KanjiMonster: inherit the cve-check class in local.conf then run bitbake
<mckoan>
core-image-minimal
<mckoan>
kayterina3: wrong recipent, sorry :-)
<KanjiMonster>
mckoan: after looking at my script again I noticed I added the line to local.conf.sample *after* doing oe-init-build-env, which obviously didn't work
<KanjiMonster>
mckoan: but thanks anyway
linfax has quit [Ping timeout: 264 seconds]
<rburton>
KanjiMonster: bitbake --runall cve_check core-image-mininal will avoid the actual building of the image
ablu-linaro has joined #yocto
<rburton>
it will still fetch everything because that's how it looks inside the patches, and there's no way to say "fetch just the patches"
xmn has joined #yocto
kayterina3 has quit [Remote host closed the connection]
kayterina3 has joined #yocto
frieder has quit [Ping timeout: 264 seconds]
ptsneves has joined #yocto
<KanjiMonster>
rburton: thank you, --runall did work much better than -c. Though it didn't seem to fetch anything, downloads/ is empty apart from the cve-check database (and uninative)
amitk_ has joined #yocto
frieder has joined #yocto
<rburton>
ah maybe we fixed that :)
Rich_1234 has quit [Quit: Connection closed]
Rich_1234 has joined #yocto
goliath has quit [Quit: SIGSEGV]
frieder has quit [Remote host closed the connection]
Rich_1234 has quit [Quit: Connection closed]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<JaMa>
haven't seen any update from kanavin for yocto-check-layer for this one, but maybe I've overlooked it somewhere
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
brrm has quit [Ping timeout: 252 seconds]
tnovotny_ has quit [Quit: Leaving]
<Chocky>
Thank you for the CVE mention; I hadn't been aware of that. That's a big deal for me, to push part of the security process much earlier in the dev process = yuuuuge time saving.
<Chocky>
Yuge.
<RP>
khem: if you're using master-next then there are changes and we're still sorting the patches
<Dane91>
Hi! :-) I'm new to Yocto, coming from buildroot, and am trying to get a project ported from there - first step, I'm very simply trying to get u-boot built, which involves using a specific release (2022.10) and applying a patch. This seems like it should be super-easy, but I've been struggling for hours (despite reading through BitBake docs as well
<Dane91>
as part of a book and a lot of internet searches). I've created a new layer and added a recipe which sets PREFERRED_PROVIDER, PREFERRED_VERSION and SRCREV, and also adds the patch file to SRC_URI; it looks like u-boot 2022.10 gets downloaded successfully to the tmp/work/... dir, but there is an error applying the patch:
<Dane91>
CmdError('quilt --quiltrc /home/dane/yocto/fsl-community-bsp/exappscreen/tmp/work/exappscreen-fslc-linux-gnueabi/u-boot/1_2022.10-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: stderr: /bin/sh: 1: quilt: not found
<Dane91>
I've checked and .../recipe-sysroot-native/etc/quiltrc does not exist.
<Dane91>
What am I missing here? :-D
<Dane91>
(If I should rather be asking this somewhere else then my apologies and please point me in the right direction)
<rburton>
did you write your own patch task?
<mckoan>
Dane91: a recipe can't set PREFERRED_*
<Dane91>
No, just added the patch file to SRC_URI, which is what the example file I copied from (for 2022.01) does.
Guest83 has joined #yocto
<mckoan>
Dane91: pastebin the recipe would help to fihure out what's wrong
<rburton>
Dane91: are you doing bitbake -b path/to/uboot.bb? specifically, the -b bit?
<Dane91>
rburton yes, correct
<rburton>
" Execute tasks from a specific .bb recipe directly. WARNING: Does not handle any dependencies from other recipes."
<rburton>
see that big WARNING?
<rburton>
that's why you don't have quilt
<rburton>
don't do that
<rburton>
just "bitbake u-boot", and set PREFERRED_VERSION in local.conf or your bsp if you have one
<Dane91>
Ah ok thanks! Let me try that :-D.
<rburton>
how did you decide to use -b? maybe there's more documentation we need to stamp on to make it more obvious to never ever ever use
brrm has joined #yocto
GNUmoon has quit [Remote host closed the connection]
<Dane91>
rburton Let me look back, I think it was in the book I bought.
GNUmoon has joined #yocto
<rburton>
if it encourages you to use -b then burn the book
<rburton>
i've been using yocto since before it was called yocto, and I've literally needed to use -b once
<RP>
rburton: I used to use it a lot! the stamp changes make it less useful now
<rburton>
shush you're not usual
<rburton>
i use it to parse specific kernel recipes to extract their version when updating the cve exclusions
<Chocky>
My build setup likes to rebuild the kernel a lot, which is unhelpful. Now that's probably its own issue I'll get to in time, but -b would help me here.
<rburton>
Dane91: "The “-b” option explicitly does not handle recipe dependencies. Other than for debugging purposes, it is instead recommended that you use the syntax presented in the next section."
<Dane91>
Yip I saw that now =#
<rburton>
i do think that the -b option should be at the end of that section instead of first
<Chocky>
rburton: More serious suggestion. If you too aggressively kill bitbake, it'll leave the .lock file and then bitch when you restart leading to confusing messages. I know that this logic is necessary, but perhaps some improvement can be made here in regards to messaging, considering a stale .lock file or checking for processes?
<Chocky>
The background here is that I'm dealing with a bunch of people who are largely new to Linux dev, never mind Yocto. Not everyone was doing Linux dev back in the 1990s like you and I.
<RP>
Chocky: I'd suggest checking ps as it will handle a stale lockfile ok meaning there is probably something still running
<rburton>
yeah i've encountered the old "i hit control-c 1000 times and now bitbake won't start" problem
<rburton>
and yeah there's usually something hanging around that won't quite die, or is taking its sweet time quitting
<Chocky>
Even if the only improvement here was better messaging, then I'll take it. "Can't connect to server" looks potentially like a networking problem, which has been a big issue for us, but is unrelated.
Rich_1234 has joined #yocto
<RP>
Chocky: patches welcome for the messaging
<ablu>
/me started to always run bitbake from a container at some point. Then one can just nuke the entire container :)
<RP>
ablu: way easier than trying to fix the code properly :(
<ablu>
RP : Well, I mostly did it to keep the environment consistent. In fact, I do not remember any recent cases of having to kill the container due to hanging bitbake processes (even if I regulary spam Ctrl+C).
<RP>
ablu: there have been issues with the exit handling but I'd hoped most are now resolved
<ablu>
RP : Yeah... At <old-job> I was working with some very old-releases. I do not think I have seen issues while roughly following master during the last year.
<Chocky>
RP: I'm just the complaints guy.
Guest83 has quit [Quit: Client closed]
<Dane91>
rburton: Completed successfully, thanks! Currently trying to figure out if it's built the same binary as what buildroot does - file sizes differ, but then again the file sizes between u-boot build and buildroot build differ as well, so I'll probably just need to load this on a board and test.
kayterina3 has quit [Remote host closed the connection]
kayterina3 has joined #yocto
<rburton>
Dane91: first check that you set preferred version right and you didn't build the latest release :)
zpfvo has quit [Quit: Leaving.]
<rburton>
but yeah, different compilers will mean different binary
<Dane91>
source in the work folder is the correct version (y)
rfuentess has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
mckoan is now known as mckoan|away
florian_kc has quit [Ping timeout: 260 seconds]
<Dane91>
Looks like the patch hasn't been applied.
<rburton>
preferred* variables can't be set in recipes
<rburton>
what is set in a recipe, stays in a recipe. and the choice of preferred version needs to be a global assignment
<Chocky>
Like Vegas
<rburton>
you just need PREFERRED_VERSION_u-boot = "2022.10" in your local or bsp config
<kayterina3>
I apped the variables "INITSCRIPT_NAME/PARAMS" but the second file 'init-script-2' is not added in /etc/rcX.d/. The recipe is like this https://pastebin.com/qW6QasEn
<kayterina3>
*appended
<Dane91>
OK so I'm guessing that it's the SRVREV set which is causing it to work then (because it is pulling the correct source).
<Dane91>
*SRCREV
jmd has joined #yocto
<Dane91>
Why would the patch not be applied?
<rburton>
most likely because its not actually building that recipe at all
<Dane91>
OK maybe the source I'm seeing in the work directory is still from when I was doing the -b
<rburton>
yeah, the work dir is per-version so check the log from bitbake to see what version it _actually_ built
ray-san has quit [Remote host closed the connection]
radanter has quit [Remote host closed the connection]
<Dane91>
OK so what I'm trying to achieve here in short is to grab the 2022.10 version of u-boot and apply a patch. What would be the right way to do this? I also need to tell the Freescale BSP to build vanilla u-boot and not the Freescale version.
<Dane91>
(u-boot-fslc)
<rburton>
you've written the recipe, so just set preferred version of uboot in your local.cofn
<khem>
otherwise basic image builds are broken with clang
leon-anavi has quit [Quit: Leaving]
<khem>
this is a regression because of the version upgrade for shared-mime-info that went in last week
florian_kc has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Dane91 has quit [Quit: Client closed]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Kubu_work has quit [Quit: Leaving.]
sakman has joined #yocto
jmd has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
nanbield doesn need that surely
goliath has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
otavio has joined #yocto
prabhakarlad has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
<fray>
Hmm.. trying to run core-image-ptest on nanbield (it's been a while) but it's saying it's skipped becasue "no class extension set", any idea what I'm doing wrong?
<fray>
(I added IMAGE_CLASSES += "testimage" to the local.conf, and I'm building poky)
prabhakarlad has joined #yocto
<fray>
I figured it out, I was trying core-image-ptest, I mean to run core-image-ptest-all
<khem>
fray: you also need to create quite a bit of tap devices depending upon how many parallel jobs you are running
amitk_ has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
<khem>
ah yes
<khem>
all good I guess
<khem>
then
<khem>
I just needed to update poky submodule to latest master
<fray>
khem you don't happen to know if there is a switch that enables multiple qemu in the ptest? Mine is currently running one ptest/qemu session at a time (I'm NOT using YP qemu) so I'm trying to figure out is it something in our QEMU that is blocking, or is it a switch I need to flip?
jgrossholtz79 has quit [Ping timeout: 255 seconds]
<fray>
Ahh, i think I found it.. "testimagelock" needs to be set to "" for qemu..
jgrossholtz79 has joined #yocto
<fray>
yup, setting that and now I'm running the ptests in paralle and have a load of 120.. :)
Danct12 has left #yocto [A-lined: This user has been AViVA-lined!]
Danct12 has joined #yocto
kscherer has quit [Quit: Konversation terminated!]