<JosefHolzmayrThe>
moto-timo thx (why are you awake?)
mckoan|away is now known as mckoan
<mckoan>
good morning
<moto-timo>
JosefHolzmayrThe: just barely
<moto-timo>
Night shift hands off to the morning shift. May your espresso be excellent and the cream strong.
<JosefHolzmayrThe>
Hrhr
zpfvo has joined #yocto
tnovotny has joined #yocto
leon-anavi has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
wwilly has joined #yocto
zpfvo has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
davidinux has joined #yocto
frieder has joined #yocto
gsalazar has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
mcfrisk_ is now known as mcfrisk
r0bin has joined #yocto
Tokamak has joined #yocto
kroon has joined #yocto
r0bin has quit [Quit: WeeChat 2.8]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
zpfvo has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
ant__ has quit [Ping timeout: 252 seconds]
<dagmcr>
hi, does anyone know why PARALLEL_MAKEINST variable change makes the sstate unusable for quite a lot of recipes? (only tested on dunfell)
rber|res has joined #yocto
arlen has quit [Ping timeout: 252 seconds]
arlen has joined #yocto
<RP>
dagmcr: makes it unusable how? It should be filtered out
florian has joined #yocto
Tokamak has quit [Ping timeout: 252 seconds]
<dagmcr>
RP: unusable meaning recipes will rebuild
<dagmcr>
just using latest dunfell from poky and updating PARALLEL_MAKEINST value in the site.conf
<dagmcr>
(some recipes)
<RP>
dagmcr: recipes from OE-Core?
<dagmcr>
well, i'm using oe-core from poky so, yes. For example, glib-2.0
<dagmcr>
wayland, libxcb...
<RP>
dagmcr: I just checked locally and you're right, it doesn't work as intended
<dagmcr>
It's a bit strange because even if you set up the same value I think it rebuilds
<RP>
dagmcr: in a really quick test, adding PARALLEL_MAKEINST[vardepvalue] = "1" made it work here
<dagmcr>
okay, I wasn't sure how to add the variable globally
<dagmcr>
thanks
dvorkindmitry has joined #yocto
tnovotny has quit [Quit: Leaving]
<RP>
dagmcr: most people let PARALLEL_MAKE and PARALLEL_MAKEINST take the same value which then means you don't see this issue
<RP>
dagmcr: I'll queue something to tweak this in core
<dagmcr>
RP: they had the same value assigned individually in my conf file
<RP>
dagmcr: right, and if you just didn't define one it would have worked :)
<RP>
dagmcr: I've sent a patch
ilunev has joined #yocto
<dagmcr>
RP: Awesome!
<dagmcr>
PARALLEL_MAKEINST = "-j 32"
<dagmcr>
Yes, it would have worked. Defining PARALLEL_MAKE redefines PARALLEL_MAKEINST and then, the sstate is being reused. But defining something like this:
<dagmcr>
PARALLEL_MAKE = "-j 32"
<dagmcr>
makes the sstate unusable for some recipes
<dagmcr>
even though the string value was the same as the previous build
<kanavin>
abelloni, can you drop my patches from kirkstone-next please? I meanwhile modified the set, and wouldn't want confusion and half-baked items in there.
ilunev has quit [Client Quit]
<kanavin>
I can resend them perhaps
<abelloni>
which ones ? :)
<kanavin>
abelloni, I can do some git-fu perhaps to determine that, I'll let you know.
<abelloni>
I'm guessing the rpm stuff but there are more updates that are probably useful
<kanavin>
abelloni, I guess you would just need to replace the patches that I modified afterwards, I just need to detemine which ones.
<kanavin>
and resend them
<dagmcr>
RP: I can't make your patch work in dunfell (I haven't tried in master). I'll try to see if there is something else more.
<kanavin>
abelloni, I just sent two patches (rpm zstd, inetutils), those should replace ones in kirkstone-next
arlen has quit [Ping timeout: 252 seconds]
arlen_ has joined #yocto
<abelloni>
kanavin: I did have the CVE patch removal for inetutils
<dagmcr>
RP: Okay, after applying your patch, the build went again without reusing the sstate. After it finished, your patch worked as intended and I can update PARALLEL_MAKEINST reusing the sstate. Is this second build due to the bitbake.conf change, isn't? But I guess in this case is intentional?
gsalazar has quit [Ping timeout: 245 seconds]
florian_kc has joined #yocto
Sion has joined #yocto
Flumpy33 has quit [Ping timeout: 252 seconds]
<fabatera[m]>
Yocto builds are taking over all machine resources after updating build server from Debian 9 to 11. The system becomes non responsive and builds take forever.
<fabatera[m]>
Any suggestions here?
<fabatera[m]>
Debian 9 docker container has the same issue (used to work in Debian 9 host).
wwilly has quit [Quit: Leaving]
<fabatera[m]>
It takes much longer even to finish the "parsing recipes"
Sion has quit [Quit: Konversation terminated!]
Sion has joined #yocto
tnovotny has joined #yocto
<kanavin>
abelloni, thanks, I only look at my own patches
<kanavin>
*looked
<RP>
Does anyone have any idea why centos8 machines would be losing files from /tmp ?
<RP>
dagmcr: yes, it has to adapt to the new signature
<dagmcr>
RP: okay
jwillikers has joined #yocto
<RP>
abelloni: any ideas on why so many /tmp issues, all centos8?
mckoan is now known as mckoan|away
<abelloni>
no idea :(
<abelloni>
was there an update recently ?
<abelloni>
naveen also reported something, I didn't have the time to look at
cameron6 has joined #yocto
<RP>
abelloni: master is broken atm due to me damaging sstate :/
<cameron6>
Good morning, I'm looking for a reliable way of determining the ID of the touchscreen device as reported by `xinput list` on my debian yocto build. Any ideas?
<gchamp>
hi! how is decided which firmware in linux-firmware makes it in a seperate package? If I only need amdgpu firmwares, should I create a new package for those?
Guest2348 has joined #yocto
mattsm has joined #yocto
<RP>
abelloni: was there an older one of these issues, I think in one of your builds? Just wondering if we can put time bounds on it
Guest54 has quit [Ping timeout: 256 seconds]
<override>
anyone feeling like giving me a run down of steps for updating kernel module version? Think im running an older version of CAN drivers which dont support flexible datarates (FD)
<RP>
gchamp: yes, just add entries for the pieces you're needing similar to the existing nes
<RP>
ones
sakoman has joined #yocto
<gchamp>
RP: ok, thanks.
<JPEW>
RP: That is an interesting way to work around the caching path issue :)
Tokamak has joined #yocto
Xagen has joined #yocto
goliath has quit [Quit: SIGSEGV]
sstiller has quit [Quit: Leaving]
Sion has quit [Ping timeout: 250 seconds]
Guest2348 has quit [Quit: WeeChat 3.3]
marc has joined #yocto
marc is now known as Guest1721
Guest1721 has quit [Client Quit]
marc has joined #yocto
marc is now known as Guest1024
Guest1024 is now known as mfe
tnovotny has quit [Quit: Leaving]
<RP>
JPEW: I'd love something better
<RP>
JPEW: starting to think we may want to be explicit about the call sites for it
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
<JPEW>
RP: Maybe the class can provide a standarized prefunc so users can do `do_my_special_task[prefunc] += "get_source_date_epoch"` ?
<RP>
JPEW: right, I was thinking about something like that
<JPEW>
Presumably, the repro testing would detect if that call was missing
<JPEW>
and we can over the most common cases (do_compile, do_install, do_package, do_deploy, etc.)
<RP>
JPEW: if we cover the common cases it should be fine, yes
<override>
can some one walk me through the process of updating recipes etc to fetch the latest socket can drivers? trying to get some direction here
dev1990 has joined #yocto
<RP>
override: usually it is a case of changing the SRC_URI, version in the recipe or recipe filename and then the checksums to match the new version. You then have to deal with any issues that arise in the new version and compatibility with the rest of the recipes
<RP>
override: but I know nothing of socket can drivers
<override>
RP: im just trying to figure out a sure shot way of figuring out what recipe the bsp is using to bring in the driver to begin with
<qschulz>
if the can driver is in the Linux kernel sources and not an out-of-tree driver, you'll need to backport the patches you want manually (nothing to do with Yocto) or upgrade your kernel version (still nothing to be done in Yocto until you get your board to boot the newer kernel)
<RP>
I was assuming this was some out of tree module but yes, you need to know where they're coming from first
<qschulz>
override: if it's a module, just run oe-pkgdata-util find-path '*can-whatever.ko'
<qschulz>
then from there, oe-pkgdata-util lookup-recipe <pkg_returned_by_previous_command>
<override>
qschulz: isnt backporting for downgrading? im suspecting im like a version behind or something becuase the current driver doesnt seem to support the flexiable datarate mode
<override>
plus isnt there a recipe that brings in the kernel to begin in? why would you say updating the kernel has nothing to do with yocto? lost me there
<override>
begin with*
<qschulz>
override: I expect that you have a custom kernel, so it's not as simple as just modifying a commit hash
<qschulz>
in a recipe
<qschulz>
you need to do the work before integrating it to Yocto
<override>
but like yocto does bring in the kenel using a recipe though, right?
<override>
I was thinking I should maybe find that recipe
<qschulz>
If it's in-tree (which is very likely), you'll need to backport the driver or patches from newer upstream release to your kernel
<qschulz>
yes, I gave you the commands to run earlier
<qschulz>
if it's really built as a module
<qschulz>
if it's not, just run bitbake -e virtual/kernel | grep "PREFERRED_*_virtual/kernel" to find the name of the recipe and the version
<override>
just to clarify, if something is given a [y] as apposed to [m] in that make menuconfig thing
<override>
is it still considered a module, like I can do this backporting method of getting it updated ??
<override>
I currently dont have to modprobe the module so its not a loadable module is what im trying to say
<fray>
(like 1/16" or so) :)
<override>
huh?
<fray>
ha.. wrong window
<qschulz>
it's built-in driver not a module
<fray>
(I was talking about adjusting the rear toe-in on my vehicle.. toe changes based on weight levels)
<qschulz>
you can still patch the kernel yes
<qschulz>
though the amount of work required depend on the quality of the vendor kernel and/or how far you are in terms of Linux version you are from the driver which has the features you want
<override>
ok, i guess I can also see why itll be called backporting, newer driver version being added to an older kernel..
<qschulz>
absolutely
<override>
can u explain the preferred_*_virtual/kernel bit too a litttle or should I mega manual that instead ?
Markus[m]1 has quit [Ping timeout: 264 seconds]
Markus[m]1 has joined #yocto
agherzan has quit [Ping timeout: 250 seconds]
agherzan has joined #yocto
Pierre-jeanTexie has quit [Quit: You have been kicked for being idle]
zpfvo has quit [Quit: Leaving.]
<qschulz>
PREFERRED_VERSION and PREFERRED_PROVIDER are mechanism to chose (for the former) a specific version for a recipe if there are multiple valid version and (for the latter) which recipe to pick if multiple recipes are able to provide a given recipe (mechanism called virtual recipes)
<kergoth>
Random tip: another way to check what recipe is being used for a provider, even in the case where a preferred preference isn't set, you can use the FILE variable to see the reicpe file for it. i.e. bitbake-getvar -r virtual/kernel FILE
manuel1985 has joined #yocto
michaelo[m] has quit [Ping timeout: 246 seconds]
michaelo[m] has joined #yocto
meck[m] has quit [Ping timeout: 246 seconds]
<Xagen>
i have a bbappend for apache2 that i added RDEPENDS for ttf-dejavu fonts, but when i build apache2 i get ERROR: Nothing RPROVIDES 'ttf-dejavu-common-native'
<Xagen>
does anyone know how to fix this?
<rburton>
Xagen: just add the rdepends to the target package
<rburton>
(using class-target override)
meck[m] has joined #yocto
<rburton>
surprised apache needs a font rdepends thoug
<Xagen>
there's some content that we're displaying on a webpage that apache is hosting that needs those fonts
<Xagen>
so i felt like that was the right place to put it
<Xagen>
rburton: are you saying that the depends needs to be in the image recipe instead?
<rburton>
Xagen: i'd put the content in a separate recipe and the rdepends on that
<rburton>
keep apache the daemon separate from the content
frieder has quit [Remote host closed the connection]
<Xagen>
rburton: but wouldn't that recipe then also have the same issue of saying that nothing RPROVIDES it?
<rburton>
no, because you wouldn't have a native form of your content recipe
<rburton>
apache needs apache-native to build, and you're saying that apache-native needs the fonts
<Xagen>
and then it appends the native to the fonts
<rburton>
the fonts don't have a native form (yet) as that's typically pointless
t_unix[m] has quit [Ping timeout: 246 seconds]
<Xagen>
ok, i gotcha
<Xagen>
let me play around with that then
t_unix[m] has joined #yocto
k4wsys[m] has quit [Ping timeout: 246 seconds]
goliath has joined #yocto
khem has quit [Ping timeout: 264 seconds]
khem has joined #yocto
ramprakash[m] has quit [Ping timeout: 268 seconds]
janvermaete[m] has quit [Ping timeout: 246 seconds]
dwagenk has quit [Ping timeout: 250 seconds]
ramprakash[m] has joined #yocto
janvermaete[m] has joined #yocto
florian has quit [Quit: Ex-Chat]
dwagenk has joined #yocto
ericson23141 has quit [Ping timeout: 264 seconds]
fabatera[m] has quit [Ping timeout: 264 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
ericson23141 has joined #yocto
Barry[m] has quit [Ping timeout: 268 seconds]
fabatera[m] has joined #yocto
DanielWalls[m] has quit [Ping timeout: 250 seconds]
Emantor[m] has quit [Ping timeout: 268 seconds]
glembo[m] has quit [Ping timeout: 264 seconds]
agherzan has quit [Ping timeout: 268 seconds]
Barry[m] has joined #yocto
k4wsys[m] has joined #yocto
DanielWalls[m] has joined #yocto
Emantor[m] has joined #yocto
glembo[m] has joined #yocto
agherzan has joined #yocto
vd has joined #yocto
barath has quit [Ping timeout: 250 seconds]
barath has joined #yocto
<override>
can some one tell me where the index or something for kernel modules is at? im trying to see when / what version exactly was the FD feature added to the SocketCAN driver
florian_kc has joined #yocto
jonesv[m] has quit [Ping timeout: 264 seconds]
jonesv[m] has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
<manuel1985>
I have problems executing a self-written do_patch() function after a self-written do_fetch() function.
davidinux has joined #yocto
<manuel1985>
do_fetch() mkdirs the directory and git-clones the repo, but do_patch deletes the directory
coldspark29[m] has quit [Ping timeout: 268 seconds]
coldspark29[m] has joined #yocto
cameron6 has quit [Quit: Client closed]
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Dracos-Carazza has joined #yocto
jonesv[m] has quit [Ping timeout: 246 seconds]
jonesv[m] has joined #yocto
florian_kc has quit [Ping timeout: 245 seconds]
<vd>
rburton: I just commented on a new syntax proposal for kas and auto.conf etc. You might like it.
<rburton>
ah cool, i'll read that properly later
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
<alex88_>
vd, just found that exact one, thank you again
barath has quit [Ping timeout: 250 seconds]
barath has joined #yocto
<vd>
Does EGLFS imply GLES2?
<vd>
I'm kinda lost between opengl, gl, gles2, egl, eglfs
alessioigor has joined #yocto
behanw has joined #yocto
alessioigor has quit [Quit: alessioigor]
jonesv[m] has quit [Ping timeout: 250 seconds]
jonesv[m] has joined #yocto
behanw76 has joined #yocto
behanw76 has quit [Client Quit]
leon-anavi has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
ant__ has joined #yocto
florian_kc has joined #yocto
sakoman has joined #yocto
moto_timo[m] has quit [Ping timeout: 264 seconds]
moto_timo[m] has joined #yocto
<override>
this can git tree for instance, I cant really tell what version CAN this is. Can someone help me figure that out?
<vd>
that's a lot of CANs
<override>
im just trying to figure out where in can-dev or like the simple can.ko kinda drivers have their versions specified
<override>
like is there a var in kconfig or something for the version?
<override>
one of the CAN's on m baords acting it when I make it talk to a micro, so im trying to figure if it has something to do with the versions
<agherzan>
RP: What is the current estimation for getting feedback on Layer Compatible applications?
<agherzan>
If you happen to know.
<RP>
agherzan: er, I haven't seen on. ndec_ should get them initially
dev1990 has quit [Quit: Konversation terminated!]
zen_coder has joined #yocto
amitk_ has joined #yocto
arlen_ has joined #yocto
arlen has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 250 seconds]
<vd>
In which scenario would a distro decide to remove the x11 or opengl feature for example?
<ant__>
if you only have dvb? maybe glesv2 for kodi?
<ant__>
some bcm stb
<ant__>
actually they do it per-machine not in the distros
<vd>
my point exactly, distro features configure software, they don't reflect the hardware support
<ant__>
mostly v3d variants or mali/hisil
<vd>
The only reason I could think of is reducing the binary size by removing likely unwanted features, but it feels like an eventually undiserable trade-off
<ant__>
depends on the size of your filesystem :)
<ant__>
some have nowadays only 512MB
<ant__>
older 256
<vd>
true but again, that'd be an image feature don't you think? removing e.g. the ext4 support in the distro itself seems a little drastic
<ant__>
20 yrs ago 32 or 64 :)
<ant__>
I am actually biased thinking about the dvb world where the set-top-boxes are/were indeed limited
<smurray>
vd: for one of you specific examples if you only support wayland, removing x11 avoids building unneeded bits
<smurray>
s/you/your/
<vd>
idk maybe distro features are only a very biased point of view of the target software, but I wouldn't expect one to tweak it too much in comparison to machine or image features.
<smurray>
they can be (and signficantly are for some of them) used to determine PACKAGECONFIG values in recipes
<vd>
smurray but that's totally biased, you agree? e.g. if I'm writing a distro for kiosks, I think x11 or wayland is bad and only directfb or dvb is cool. If you want to use a full screen wayland app for your kiosk, well, too bad! Seems a little rough.
<smurray>
I'm not sure I follow, the whole point of OE is to build customized distros
<ant__>
most packageconfig knobs are related to MACHINE or DISTRO features (at least in kodi)
<smurray>
ant__: systemd is widely used
<smurray>
vd: if you want a generic distro that can run anything, turn them all on, if not, tweak them
<smurray>
ant__: and there are many bsp layers that use x11, wayland, opengl, etc. to configure their graphics bits
<ant__>
yes, it all depends on the target capabilities
<ant__>
this is what OE/Yocto is for
FredO2 has quit [Read error: Connection reset by peer]
<vd>
smurray: ok so let's say I'm writing a distro for kiosks (embedded machine with an optional screen with limited user interaction), it'd be my choice as the distro maintainer to exclude software rendered graphics and compositors and only allow direct fb, eventually hardware accelerated. Thus I would add DISTRO_FEATURES:remove = "x11 opengl wayland
<vd>
vulkan", DISTRO_FEATURES:append = " directfb" and let the machines configure packages like "eglfs gles2" for Qt for example.
<smurray>
vd: that's definitely an option
<vd>
This is what I was describing by being a bit rough and definitely biased. But true, you wouldn't want packages configured with x11 for sure if a window manager isn't supposed to be used on the target.
<smurray>
it's your choice as a distro definer
<vd>
And if a given scenario (like a development/testing environment) needs a window manager to test a GUI, then it's the user/machine maintainer responsibility to hack the distro in order to support wayland or x11.
<smurray>
sure
<vd>
Okay, a distro is biased by definition after all, so it makes sense.
<smurray>
right
<vd>
then there are scenarios like qtbase which seems to depend on wayland to support egl but that's another special case ^^
FredO has joined #yocto
<vd>
setups like Qt are tricky because you may not wish to enable eglfs or libinput even though you have a 3d capable touchscreen, so that's where the distro features comes in.
zen_coder has quit [Ping timeout: 256 seconds]
<vd>
btw does opengl mean software only or eglfs/gles2 rely on opengl?
<smurray>
vd: I'm not sure right off the top of my head
arlen has joined #yocto
<vd>
it's a little weird to me because I get this: Feature 'eglfs' was enabled, but the pre-condition '!config.android && !config.darwin && !config.win32 && !config.wasm && features.egl' failed.
<vd>
And I don't really understand how to enable the said 'egl' feature which eglfs seems to depend on.
arlen_ has quit [Ping timeout: 268 seconds]
<vd>
I'm not even sure to understand if eglfs/gles2 is hardware specific or can be software rendered.
jwillikers has quit [Remote host closed the connection]