pbergin has quit [Remote host closed the connection]
manuel_ has joined #yocto
pbergin has joined #yocto
florian has joined #yocto
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
manuel1985 has quit [Ping timeout: 250 seconds]
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
bps has joined #yocto
bps has joined #yocto
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
Wulf has quit [Ping timeout: 252 seconds]
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
Wulf has joined #yocto
florian has quit [Ping timeout: 260 seconds]
pbergin has quit [Ping timeout: 252 seconds]
jwillikers[m] has quit [Quit: Client limit exceeded: 20000]
dev1990 has quit [Quit: Konversation terminated!]
<wesm>
I patched out the opengl dep check to see if I could get it to build. It wants GL/gl.h which I got from mesa but now I have a bunch of "undefined reference to glFoo etc" errors so something is still missing
jordemort has joined #yocto
Spectrejan[m] has joined #yocto
lexano[m] has joined #yocto
Emantor[m] has joined #yocto
shoragan[m] has joined #yocto
dwagenk has joined #yocto
t_unix[m] has joined #yocto
jonesv[m] has joined #yocto
zagor has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
Barry[m] has joined #yocto
JosefHolzmayrThe has joined #yocto
Dhruvagole[m] has joined #yocto
suy|m has joined #yocto
ericson2314 has joined #yocto
cperon has joined #yocto
Epictek[m] has joined #yocto
nrossi[m] has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
prabhakarlad has joined #yocto
Tokamak has joined #yocto
sakoman has quit [Quit: Leaving.]
camus1 has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus1 is now known as camus
prabhakarlad has quit [Ping timeout: 256 seconds]
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
codavi has quit [Ping timeout: 268 seconds]
xmn has quit [Read error: Connection reset by peer]
davidinux has joined #yocto
geoffhp60 has joined #yocto
bluelightning has quit [Quit: Konversation terminated!!!111]
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
<vd>
core-image-minimal-initramfs has COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)' and my HOST_SYS is arm-oe-linux-gnueabi and yet initramfs-module-install was skipped: incompatible with host. Why am I missing?
sakoman has quit [Quit: Leaving.]
berton[m] has quit [Quit: Client limit exceeded: 20000]
troth has quit [Ping timeout: 265 seconds]
troth has joined #yocto
tlwoerner_ has quit [Quit: Leaving]
tlwoerner_ has joined #yocto
tlwoerner_ has quit [Remote host closed the connection]
tlwoerner has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
kiran_ has quit [Ping timeout: 265 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
vd62 has joined #yocto
vd has quit [Ping timeout: 256 seconds]
rob_w has joined #yocto
GNUmoon has joined #yocto
troth has quit [Ping timeout: 260 seconds]
F_Adrian has joined #yocto
kayterina has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
troth has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Borimo has joined #yocto
_whitelogger has joined #yocto
vd62 has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
zpfvo has joined #yocto
rfuentess has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
goliath has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<wyre>
what's the proper way to generate the patch for arch/arm/boot/dts/Makefile ?
berton[m] has joined #yocto
<wyre>
could I just use diff?
<wyre>
I'm asking this because when I run diff I can see a relative path in the output https://bpa.st/LKMA
<wyre>
and I'm not sure how this will affect
<wyre>
how this will affect the do_patch task, I mean
<deuteron>
wyre: I'd normally do like `cp Makefile Makefile.orig`
<deuteron>
Then from the source directory run `diff -u arch/arm/boot/dts/Makefile{,.orig}`
<deuteron>
That'll get you closer, but you'll probably have to put a/ and b/ prefixes on the paths.
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
mariusz has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<wyre>
deuteron, I just cloned the kernel repo and made the modification in there and used git diff 😉
<wyre>
but thank you anyway 😊
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<qschulz>
wyre: devtool modify <kernel> and do the change in the workspace
<qschulz>
which ultimately is the same thing that you did,. except that devtool update-recipe creates the patches for you once you've committed in the kernel workspace git repo
<qschulz>
wyre: the kernel has nothing to do with the Yocto version you can use
kayterina has quit [Read error: Connection reset by peer]
<qschulz>
Yocto is a build system, just write a kernel recipe that fetches the kernel version you think you need to use
<wyre>
qschulz, I see
<JosefHolzmayrThe>
qschulz: lets say "under some preconditions"
pbergin has joined #yocto
<qschulz>
JosefHolzmayrThe: ? care to elaborate?
<JosefHolzmayrThe>
qschulz: sure ;-) the most prominent one is if you're stuck on a rather old vendor kernel, it is often very problematic to use a newer toolchain
<wyre>
I'm not sure also what kernel version would be more appropriate to boot in less than 128MB
MauroAnjo has joined #yocto
<qschulz>
wyre: well, aren't you using a specific kernel in your pyro build? start by using this one?
<wyre>
I don't know even if would be possible to build newer versions to make them bootable with this low DRAM availability
<qschulz>
JosefHolzmayrThe: indeed, just disable all the warnings turned into errors and it's fine :D
* JosefHolzmayrThe
has just kicked off poky master and will likely boot it on low memory in a few minutes.
<qschulz>
JosefHolzmayrThe: if it does not work, you probably want to lower the amount of memory allocated to CMA
<wyre>
Do you think could I do what I've suggested?
<JosefHolzmayrThe>
qschulz: nope. there was a time when the kernel actually did magic depending on the reported version string by gcc and would fall over
<qschulz>
there's a config for it or I think passing cma=16MB or similar should help
<wyre>
qschulz, just to do what I've said?
<qschulz>
JosefHolzmayrThe: yeah, there's a reason I hate working with vendor kernels :)
<qschulz>
wyre: my last remark was for JosefHolzmayrThe
<JosefHolzmayrThe>
qschulz: thats what i meant with "preconditions"
<qschulz>
yeah good point
<qschulz>
I mean... at one point it might even make more sense to build the kernel by yourself outside of Yocto then :p
<JosefHolzmayrThe>
qschulz: heh yeah
mariusz has quit [Ping timeout: 256 seconds]
<wyre>
qschulz, this is the kernel recipe I'm using to build dunfell on my MACHINE https://bpa.st/PIOQ
<wyre>
do you think I just could create another recipe for a different branch with a lower kernel version and create a custom MACHINE config file?
<qschulz>
wyre: see points raised by JosefHolzmayrThe
<wyre>
upss ... no, they just have branches for 5.4 and 5.10
<qschulz>
but who does not try does not know
<wyre>
I probably will have to use the pyro kernel 😥
<ykrons>
Hello, I see the following in a recipe, but could not find the meaning of the (= ${variable}) syntax (e.g.: RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV})"). Could someone explain it to me please?
<qschulz>
wyre: there's no pyro kernel!
<wyre>
qschulz, sure, I know
<wyre>
in fact is an Engicam's kernel
<wyre>
I meant the kernel version Engicam's using in their BSP to build pyro
<qschulz>
the point being, you might be stuck with an old kernel (though "stuck" is relative) but that is usually not a reason for having a really old version of Yocto used to build it
<wyre>
I guess that's what you meant when you talked about vendor kernels
<qschulz>
I build a 4.4 kernel on Dunfell for example
<JosefHolzmayrThe>
wyre: when can we actually invoice you or engicam?
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
sstiller has joined #yocto
<RP>
"tar (child): zstd: Cannot exec: No such file or directory" - why would a previously fine autobuilder worker do that :/
<rburton>
rfs613: the pydevshell (or devpyshell, can't remember) gives you a python interactive shell, where you can do d.expand("${bindir}") iirc
florian has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<qschulz>
RP: I don't know, same question as to why I have pseudo aborts when I don't pass --tmpfs /tmp to containers
<RP>
qschulz: what does pseudo.log say?
<qschulz>
tlwoerner: hi /me waves do you want me to ping on the mail for the meta-rockchip patches so you get them at the top of your mailbox :) or is this message enough :) ?
<qschulz>
RP: path mismatch
<JosefHolzmayrThe>
wyre: qschulz for the record, latest poky master qemuarm boots flawlessly with 64M. no magic needed, just kicked off 'runqemu nographic slirp qemuparams="-m 64"'
<hmw[m]>
Hi, i have added layer meta-qt5-extra but now it is complainging that it needs multimedia-layer ( i have oe-core/meta/recipes-multimedia)
<qschulz>
hmw[m]: meta/recipes-multimedia is not a layer
<RP>
qschulz: right, but which path. Can you share the exact log message please?
<JosefHolzmayrThe>
hmw: 1) meta-multimedia is a part of meta-openembedded 2) make sure all layers are on the same release.
<wyre>
JosefHolzmayrThe, I'm assuming you aren't using a specific vendor kernel, right?
<RP>
qschulz: Was that with containers?
<qschulz>
RP: /tmp paths I don't think I have the logs anymore but it shouldn't take too long
<JosefHolzmayrThe>
wyre: like i said, when can we invoice you or engicam?
<qschulz>
wyre: vendors usually allocate WAY too much memory for graphic stuff, just to make sure they never have customers hitting weird issues
<wyre>
I didn't know you were here to make money, JosefHolzmayrThe 😆
<JosefHolzmayrThe>
wyre: they sell hardware, they get the money. and you're probably not doing this for fun too.
<qschulz>
so I wouldn't be surprised it's just a configuration thing
<wyre>
qschulz, but could I change this memory allocation by modifying build params for the kernel? 🤔
<wyre>
JosefHolzmayrThe, well, I so keen on Yocto actually, I like so much the project 😊
<JosefHolzmayrThe>
wyre: i'm not here *for* the money, but I stand for the common sense of liability that those who get the money also should provide the support.
<qschulz>
wyre: the point JosefHolzmayrThe is trying to make is that doing free support for vendors isn't really something to be expected from communities :)
<wyre>
sure qschulz I know that and I'm so grateful to you because all of your help
<wyre>
you are helping me a lot to understand how this environment works
<qschulz>
wyre: if it's only CMA pool being too big, there should be a kconfig option yes, or passing cma=<somnething> to the kernel command line via bootargs in U-Boot or whatever bootloader you're using
<JosefHolzmayrThe>
wyre: so if you're running into things that are of relevance to more people, then I'm happy to try and explain. yet if we're all wasting our time on a BSP that ships old layers and you can't get working because whatever, then, well... I just think its unfair behaviour on mostly engicams, but also your side.
<qschulz>
but that's too deep into your vendor BSP and I *personally* will not help with this more as the community does not really benefit from this (and also, kernel question on yocto chan :) )
<qschulz>
JosefHolzmayrThe: stop saying the same things ugh :p
<JosefHolzmayrThe>
qschulz: no probem. I'll stop saying and resort to typing, mkay?
<wyre>
well, anyway thank you very much, because you give me a few researching lines 😊
<qschulz>
wyre: our pleasure, good luck :)
davidinux has quit [Ping timeout: 250 seconds]
<RP>
qschulz: what is /tmp in that case instead? part of the container rootfs?
<qschulz>
yes
davidinux has joined #yocto
<hmw[m]>
Josef Holzmayr (TheYoctoJester): qschulz : tnx i was missing it in the bblayer file
<qschulz>
hmw[m]: :+1:
bps has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
<qschulz>
RP: if that matters in any way, I'm using rootless podman for the machine that failed with pseudo aborts
<qschulz>
which AFAICT is using fuse-overlayfs? (podman 3.0.1 + 5.10.x kernel on a debian bullseye)
creich has quit [Remote host closed the connection]
<ykrons>
Anyone could help about the (= ${variable}) syntax ? I can't find explaination in bitbake and yocto documentation
<RP>
qschulz: I suspect something odd with the filesystem stuff, overlayfs is a nightmare with pseudo :(
<ykrons>
rburton: Yes it is RDEPENDS related: RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV})"
zpfvo has quit [Ping timeout: 250 seconds]
<ykrons>
rburton: thanks for the link, I have a look
MauroAnjo has quit [Quit: Client closed]
zpfvo has joined #yocto
otavio_ has quit [Remote host closed the connection]
otavio has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
pbergin has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<rburton>
that's just saying that avahi-dev depends on avah-daemon of the exact version, so they get upgraded in unison
bps has joined #yocto
bps has joined #yocto
<RP>
ykrons: the version constraints effectively get passed to the package managers like opkg/dpkg/rpm
tre has joined #yocto
bps has quit [Ping timeout: 260 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
pbergin has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
pbergin_ has joined #yocto
pbergin has quit [Ping timeout: 260 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
tnovotny has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<qschulz>
RP: yeah that would be my guess too. Don't have any more ideas though :/
<tlwoerner>
qschulz: i'll look at them today, thanks!
adrian_ has joined #yocto
<qschulz>
tlwoerner: not urgent but I saw that you were reviewing/merging patches from Khem so I didn't want the patches to be forgotten :)
F_Adrian has quit [Ping timeout: 250 seconds]
jwillikers has joined #yocto
rob_w has quit [Remote host closed the connection]
<perdmann_>
Hi, i have a weird behaviour. A custom software is running if i start it in the console. If i start it via a systemd service it is starting but something is missing. So how can i compare these startup behaviours?
<rburton>
when run as a service you'll have less environment variables set (as its not an interactive login), and no TTYs connected
<rburton>
so most likely one of those, and really most likely the environment
<perdmann_>
rburton: yes i already checked this and tried to create that environment in the start script i created...
<perdmann_>
Is it possible to run a service in a specific user environment (with kind of login?)?
<rburton>
you can set the user to run as, and set any environment
<rburton>
dont' think you can fake a login though
<ykrons>
I've got a SDK problem that seems to be linked to the watchdog recipe. I have included watchdog-keepalive package in my image, and now SDK reports a solver warning due to a conflict with watchdog package ("RCONFLICTS_${PN}-keepalive += "${PN}") and a lot of other packages data are missing from the SDK.
<ykrons>
Is it because yocto try to include watchdog-keepalive-dev in the SDK and fallbacks on watchdog-dev because there is no watchdog-keepalive-dev package defined?
<perdmann_>
rburton: i have to try, thank you
<perdmann_>
rburton: it is an Qualcomm delivery. Its awful
<ykrons>
And shouldn't the SDK build fail in that case rather than reporting only a warning and produces a broken SDK?
<JPEW>
It's really hard to guess all the little variations people might have
<JPEW>
Also, the container only runs while bitbake is running
<qschulz>
JPEW: yeah which makes it hard to inspect if it's correctly set up. Is there some command/trick to have it running so one can docker/dpoman exec -it in it?
jwillikers has quit [Remote host closed the connection]
<coldspark29[m]>
It is the standard poky honister from the Yocto qucik build guide
mvlad has quit [Remote host closed the connection]
<JPEW>
Your bblayers.conf file is referencing the wrong paths
<JPEW>
You want /home/claussenj instead of /home/yocto
jwillikers has joined #yocto
mvlad has joined #yocto
goliath has joined #yocto
<coldspark29[m]>
Ah yeah, I downloaded poky with another container. That's why
<coldspark29[m]>
Yeah it runs :)
<coldspark29[m]>
Settings this up for our already worked on project will be a bit painful I guess
<JPEW>
Depends. If you don't already use a container, it shouldn't be too bad
<coldspark29[m]>
Do I have to add the pyrex folders to my repo? Not sure if my colleagues will want to use it as well.
<coldspark29[m]>
Upload them to Github I mean
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
<coldspark29[m]>
Because we work with repo and would lose all those folder when syncing I guess
<JPEW>
coldspark29[m]: do you mean meta-pyrex?
davidinux has quit [Ping timeout: 250 seconds]
<JPEW>
You usually want to make pyrex.ini available for your coworkers if they are going to use pyrex so that they can get the same container version etc
jwillikers has quit [Remote host closed the connection]
pbergin__ has joined #yocto
davidinux has joined #yocto
pbergin_ has quit [Ping timeout: 260 seconds]
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
tre has quit [Remote host closed the connection]
<hmw[m]>
hi, my weston keeps crashing a few minits after boot ( if i restart it manualy it keeps running) it crashes with caught signal 15
<rburton>
SIGTERM 15 15 15 15
<rburton>
it gets killed
<rburton>
slap a gdb on it
camus has quit [Ping timeout: 268 seconds]
sakoman has joined #yocto
dacav has joined #yocto
<coldspark29[m]>
<JPEW> "You usually want to make pyrex...." <- Yes, so I guess we would have to merge it into our repo as well. I will have to see about that. One new colleague wants to use an Eclipse plugin and the other uses geany for editing. So the demand might not be so high. I really like it though.
zpfvo has quit [Ping timeout: 260 seconds]
<JPEW>
coldspark29[m]: Ya, the idea is since only bitbake runs in a container, they can still use their editor of choice in the host
zpfvo has joined #yocto
<coldspark29[m]>
And if Garmin uses it, it can't be so bad. The later watch models are also better in the softwaree department. Hoping that this trend will continue. I just sold my Apple watch, because it was too annoying and the Garmin watches are still not Smart enough for me ;)
<coldspark29[m]>
JPEW: It's a neat feature actually
<dacav>
Hi. I'm trying to understand how the devicetrees are handled for the SoC I'm working on. As far as I know, the device trees for many platforms are often found in the kernel sources. In this case some dts files are provided within a yocto layer, there are also some dtsi files... but I can't make sense of them
<coldspark29[m]>
dacav: .dtsi files are included files. They are like .h files in C
<coldspark29[m]>
In the end the .dts and .dtsi files are all compiled into a single .dtb file
<dacav>
I'm wondering, to begin with, how it works with the dt hierarchy: I know that it is a tree and there should be at most one root, but can / be declared by multiple dts/dtsi? If so, are they merged?
<dacav>
I could not find this info in the specification
<qschulz>
dacav: yes
zpfvo has quit [Ping timeout: 268 seconds]
<qschulz>
everything redeclared is merged
<coldspark29[m]>
I am not sure about that. Also pretty new here.
<qschulz>
and it's merged in the order in which it is included
<qschulz>
so if you have a property that is redeclared multiple times (e.g. "status")
<qschulz>
the last included dtsi or the final dts has the last word
<qschulz>
otherwise, just do you tests yourself and then use `dtc -I dtb -O dts my.dtb`
<qschulz>
phandles won't be in the human form but most of it should be readable
<qschulz>
human readable form obviously :)
codavi has joined #yocto
ar__ has joined #yocto
codavi has quit [Ping timeout: 268 seconds]
manuel_ has quit [Ping timeout: 250 seconds]
kayterina has joined #yocto
zpfvo has joined #yocto
<qschulz>
mmmm damn opengl :/
<qschulz>
so there's a header file for opengl es 3 which is supposed to be called gl2ext.h according to Khronos doc, but mesa provides a gl3ext.h only
<qschulz>
kmscube (a mesa project) includes gl3ext.h and therefore breaks projects where only gl2ext.h is provided, e.g. rockchip's libmali
<qschulz>
so I don't know what to do :)
<qschulz>
oh, and most important piece of information. The gl{2,3}ext.h file is empty.
<dacav>
Another question (Q2): is the SRC_URL per-recipe, or per-layer?
<qschulz>
dacav: not sure to see what the use case would be for a per-layer SRC_URI
<qschulz>
it's per-recipe
<qschulz>
actually, it's gl3ext.h from mesa that is empty, gl2ext.h is not
<qschulz>
ok nevermind, I was looking for gl2ext.h in include/GLES3
<qschulz>
tgif
maoti__ has joined #yocto
jpuhlman_ has quit [Ping timeout: 265 seconds]
<qschulz>
mmmm, are circular RDEPENDS possible?
zpfvo has quit [Ping timeout: 260 seconds]
davidinux has quit [Quit: WeeChat 2.8]
zpfvo has joined #yocto
<rburton>
if you install them both at the same time, sure
<rburton>
terrible idea though
<qschulz>
it's related to my monologue above
<qschulz>
basically, I think libgles3-dev should RDEPENDS on libgles2-dev to have include/GLES2/gl2ext.h available
<qschulz>
however, mesa already has an RDEPENDS:mesa-ligles2-dev = "mesa-ligles3-dev" though I couldn't really make sense of the reason for this
OnkelUlla has quit [Remote host closed the connection]
davidinux has joined #yocto
<kanavin>
qschulz, pressure your vendor to ditch the blob :)
<kanavin>
there are mali drivers in mesa
marc1 has joined #yocto
<qschulz>
kanavin: the issue here being that mesa itself does not follow the specs
<qschulz>
but my vendor does :)
<qschulz>
well, not mesa, kmscube
<qschulz>
and mesa provides a file that shouldn't be here
<qschulz>
which kmscube includes but shouldn't
<JPEW>
qschulz: We ditched the vendor mali driver and hired collabra to add mesa for support our specific GPU (since it didn't already). Best money we've ever spent
<qschulz>
(see patches on the ML)
<qschulz>
JPEW: I've to check if Panfrost supports the Rockchip PX30 in some way
<qschulz>
but that does not solve an actual issue in Yocto/kmscube/mesa
<JPEW>
qschulz: Sure. I don't know if panfrost supports the G series of GPUs; ours was an older one (who's name escapes me ATM)
<qschulz>
but.. don't know if it's well supported in 5.4 :/
<JPEW>
qschulz: Ah, we had a T-720
<qschulz>
though they say it's non-conformant..
<dacav>
self-answers so far: SRC_URL is per-recipe. While this was intuitively obvious, I was puzzled by the SRC_URL in question (apparently) lacking of some sources... it turned out that a .bbappend was hidden somewhere and adding stuff without me knowing it. `bitbake ... -e` solved the mistery.
<qschulz>
JPEW: I'm always wary recommending FOSS GPU/VPU/IPU implementations to clients. You never know if it has implemented this fancy feature. Though admittedly, I've very little experience in dealing with that kind of stuff :)
<qschulz>
dacav: I answered you an hour ago
<qschulz>
(also, it's SRC_URI and not SRC_URL :) )
<qschulz>
dacav: but good use of bitbake -e :)
<JPEW>
qschulz: It does depend on the GPU, but in my expirence Panfrost is miles ahead of the vendor blobs when it comes to featyres
<JPEW>
qschulz: It basically gets all the mesa features, and has the same (or maybe even better) performance
<JPEW>
We _had_ to switch because we needed some Wayland support the vendor blob just couldn't do
<qschulz>
JPEW: yeah, will think about it, quite difficult to make a client do such a big change during the life cycle of a product I think
<JPEW>
qschulz: Sure, that makes sense. I would keep it in mind though in case you come across some missing feature your SoC vendor is unwilling to implement
<qschulz>
JPEW: yeah if the vendor does not support something, first thing to try is if upstream supports it :) I don't like "supporting" vendor stuff but as said, don't feel couraadventurousnough to change that months/years after a product has started selling :|
<qschulz>
will think of it when (if) we do a big jump between 5.4 and the next (next?) LTS
<qschulz>
JPEW: thanks for the feedback :)
vd has joined #yocto
<kayterina>
hello. I have a yocto repository that includes poky and the folder is added to .gitignore. When I checkout an older version of the repository, can I know if any changes in poky might make the build fail? Should git keep some info about the versions of all layers it uses?
sstiller has quit [Quit: Leaving]
<qschulz>
kayterina: your layers should be kept in sync. We recommend using the same branch for each layer, they usually are named after the Yocto release they support
<qschulz>
for how to keep them in sync, there's nothing implemented in Yocto, you'll have to use a 3rd party tool
<qschulz>
some people use repo, git submodules too I assume, and some others use kas (github.com/siemens/kas)
<qschulz>
also, the commit hash of each layer is printed when bitbake starts so you can always check that manually to see if something's off
<kayterina>
a,yes I found .gitmodules. So this line "branch = zeus-patched" keeps poky at the same version?
<qschulz>
I don't use gitsubmodules so can't say :}
<qschulz>
:| *
kiran_ has joined #yocto
<kayterina>
ok thanks
<JPEW>
kayterina: The `branch` line just tells git what the remote tracking branch should be for the repository. The actual commit SHA is stored in the git data
<JPEW>
If the submodule isn't at the correct SHA-1, `git status` will show it as modified
<kayterina>
there is a /.git/modules/sources/poky/HEAD, is that the SHA?
<JPEW>
kayterina: I beleive that is the current SHA-1 that is checked out, same as you would get from `git rev-parse HEAD` in the submodule
<JPEW>
kayterina: But... you really shouldn't poke around in the .git directory for anything; there are commands to tell you what you want to know
<t_unix[m]>
is there a CLI formatting tool for bitbake recipes?
Tokamak has quit [Read error: Connection reset by peer]
kayterina has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
<RP>
JPEW: did you have a patch in mind to simplify the bitbake parser feeder process usage?
<JPEW>
RP: I don't think so, but if I did it would have been a while ago and I don't remember; can you remind me what it was about?
rfuentess has quit [Remote host closed the connection]
<RP>
JPEW: we have a feeder thread in the parsing code in cooker.py. It was there, I think added by kergoth to work around python bugs/issues in multiprocessing. I remember you disliked it quite a bit and wanted to remove it. I think we were close to release and I said to defer to afterwards and we never got back to it
<RP>
I've just been pondering whether asyncio would help cooker and the bitbake server code. Jury is still out on that :/
<JPEW>
Ah, that sounds familiar. Let me look....
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<JPEW>
RP: poky-contrib cgit seems to not be updated, but is 153ebe3ade191b6cb99f7aae07e2766c317b03b4 in poky-contrib what you were thinking of?
<RP>
JPEW: yes, that looks like it!
zpfvo has quit [Ping timeout: 268 seconds]
<JPEW>
RP: FYI I *just* rebased it, so I don't know if it works just yet
<RP>
JPEW: I was looking at the exception handling and wondering if that was right :)
zpfvo has joined #yocto
<RP>
would certainly be nice to clean that up if we can
leon-anavi has quit [Remote host closed the connection]
<JPEW>
Which exception handling?
<rburton>
RP: would it be sensible to make bitbake spawn its workers use sys.exe or whatever so that it uses the exact same py interpretter instead of searching $path for python3?
<RP>
JPEW: Looking more closely I think it is fine
<RP>
rburton: probably
<rburton>
<cough> for no reason
<RP>
rburton: I have a good imagination :/
<rburton>
awwww pypy's os module isn't identical to standard py
dev1990 has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
<JPEW>
RP: Ah, the old ParserFailure wrapping? Ya that's unnecessary now. multiprocessing does a better job passing the execeptions back to the parent
<RP>
JPEW: right, it makes sense when you step back
zpfvo has joined #yocto
geoffhp has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
Tokamak has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
Tokamak has joined #yocto
camus has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
dev1990 has quit [Quit: Konversation terminated!]
geoffhp has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<kergoth>
t_unix[m]: unfortunately not. It's not entirely trivial to reformat bitbake recipes, particularly if you want to reorder or sort lines, as bitbake's file format is order dependent, and lines may well depend on one another, or require that they are set before or after inherit, etc
<kergoth>
A simple one that just corrects indentation and whatnot would be easy enough, and oe-stylize does exist but has flaws
<kergoth>
Ideally I think we could implement reordering using our knowledge of variable dependencies, at least within sections delinated by inherits.. hmm
<kergoth>
Now to test lima+nerdctl for yocto builds on my macbook
<kergoth>
(unrelated)
<kergoth>
RP, JPEW: Oh I'd love to see the parsing process crap streamlined. it's amazing looking back at how many issues we've hit with multiprocessing over the years..
<kergoth>
OT, but anyone know offhand if we require a python version that supports f-strings yet?
florian has joined #yocto
<rfs613>
when adding a new (3rd party) layer to an existing project, is there a way to check whether existing recipes are affected (eg. some bbappend from the new layer etc)?
<t_unix[m]>
kergoth: yeah, I know it's non-trivial. Indentation would be sufficient for me atm though.
<kergoth>
Fair enough, your best bet about that sort of thing is to check oe-core's scripts dir, particularly scripts/contrib
mariusz has joined #yocto
florian has quit [Ping timeout: 268 seconds]
<JPEW>
kergoth: python is new enough, but I think we are holding off on using fstrings just yet so that backports are still possible
mariusz has quit [Ping timeout: 260 seconds]
<kergoth>
Ah, makes sense.
<kergoth>
They sure are nice, I'm looking forward to it :)
* RP
suspects we won't be able to hold off for much longer, right rburton? :)
kroon has joined #yocto
<kroon>
qschulz, ping
<fray>
I didn't mind '%' format.. but I always hated str.format(...)
<fray>
the new f-string format (hadn't seen it before) seems reasonable though
<JPEW>
RP: asyncio is helpful if you have a lot of I/O bound things to do at once; I don't think it would necessarily help with parsing per-se, but probably with task execution (where the bitbake main process has to wait for a bunch of subprocesses to do things
<JPEW>
It lets you write code a lot more naturally at least since you don't need to have callbacks and state being passed all over the place
kroon has quit [Quit: Leaving]
xantoz has quit [Ping timeout: 265 seconds]
aduskett has joined #yocto
<aduskett>
Hello, does anybody have any experience with selinux perchance? I have a read only file system and / is set to unlabeled_t on bootup. I can remount / as rw and run restorecon which sets it to root_t (as it should be) but this isn't ideal.
adrian__ has joined #yocto
<RP>
JPEW: I wasn't thinking about parsing, more about the server and command processing and handling the different data read/writes
<RP>
JPEW: looking at the code I was reminded about the parsing change
adrian_ has quit [Ping timeout: 250 seconds]
adrian__ has quit [Ping timeout: 268 seconds]
mvlad has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
<rburton>
kergoth: have you tried using lima on macos to do a yocto build?
<kergoth>
I have, actually. It's workable if you don't mind shoving your tmpdir into a volume, you can't use bind mounts with -v for that on mac right now, lima uses sshfs for it, and it mucks up permissions
<rburton>
i was guessing that would be the problem
<rburton>
i've done a build in a vm on my m1 mbp and was quite impressed
<kergoth>
I usually like to use bind mounts to make the docker usage transparent, but not workable on the mac
<kergoth>
nice
tnovotny has quit [Quit: Leaving]
<kergoth>
I'm hopeful that lima moves in the qemu+9p direction or so
<rburton>
yeah, they said that in the readme
<kergoth>
lima is really nice in general. easy use of nerdctl or podman is convenient
<rburton>
lima looks a lot more like my style than parallels
<kergoth>
yeah, it's like wsl basically..
<kergoth>
Ugh, can't leave the layers in an rw bind mount either, it needs to write pyshtables.py and bitbake.lock in builddir. will have to just drop into the container and do everything in the volume. workable, just irritating, and it means i can't use vscode for the layer content..
<kergoth>
docker for desktop might have license issues, but it certainly avoided these issues
<kergoth>
I'd like to see pyrex get support for nerdctl in general as well as support for nerdctl or podman via lima as alternatives to native podman, which doesn't support host volumes at all
<JPEW>
RP: Can you really get a data stream to bitbake-worker that looks like "<foo>A</foo>B</foo>"?
<JPEW>
It's certianlly written to handle that :/
<RP>
JPEW: that certainly shouldn't happen. We did add some code to make it error and give decent debug info for malformed streams though?
<JPEW>
Ya, but the deserializing code will keep looping looking for "</foo>" and handling it... looks like some strange leftover
<RP>
JPEW: I don't remember. It could well be some kind of leftover
<rfs613>
rburton: thanks for the tip about 'devpyshell', very handy.
<kergoth>
rburton: seems like lima is viable if you stick to the linux homedir and do all development inside, it's only if you try to use host paths whether via containers or not that you run into headaches.
kiran_ has quit [Ping timeout: 250 seconds]
vd has quit [Quit: Client closed]
vd has joined #yocto
florian has joined #yocto
troth has quit [Quit: Leaving.]
pbergin__ has quit [Ping timeout: 250 seconds]
<kergoth>
Hmm, wonder if there's a way to share data between lima instances without going through the host
ar__ has quit [Ping timeout: 250 seconds]
<kergoth>
Works pretty well without containers in the mix. Here's hoping that sshfs issue gets fixed eventually for that piece