**** BEGIN LOGGING AT Fri Mar 20 02:59:57 2020 Mar 20 14:43:32 does anyone know about the mesa-gl recipe? I've got a bug report that if someone is using it and turns off x11 and wayland it fails with an error. I can't find anything that says if this error is reasonable or not.. "building dri drivers require at least one windowing system or classic osmesa" Mar 20 14:43:47 My understanding is the user is trying to build it for fbdev Mar 20 14:44:17 If I turn on gbm it will compile, but then I get conflicts with other providers of gbm Mar 20 14:55:49 fray: mesa-gl is specifically to provide the big-GL library which on Linux uses GLX Mar 20 14:56:00 so "mesa-gl without x11" is an oxymoron Mar 20 14:56:54 the recipe should refuse to build without x11 enabled explicitly with a distro features check Mar 20 14:57:03 if someone wants gl on framebuffer, they want egl Mar 20 14:58:23 that's the problem they're trying to build QT and are convinced they need mesa-gl and their custom mali-gl driver.. Mar 20 14:58:32 they're wrong Mar 20 14:58:35 :) Mar 20 14:58:35 I don't know enough about this to understand if that is even reasonable.. Mar 20 14:58:52 my understanding is that mali does gles/egl already Mar 20 14:59:00 Ok, so if they are NOT building with X11, this is unreasonable.. I can add a distro check to mesa-gl.. Mar 20 14:59:21 (the PACKAGECONFIG in mesa-gl does have x11 as 'variable'...) Mar 20 14:59:45 thats most likely because its just reusing the mesa recipe and controlling what it does Mar 20 15:00:04 PACKAGECONFIG_class-target = "opengl dri ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}" Mar 20 15:00:25 so I'm assuming that should -always- be 'x11', and adding a required distro feature check is what is needed? Mar 20 15:00:50 hm Mar 20 15:00:57 i wonder what it builds if you turn off x11 Mar 20 15:01:03 it doesn't Mar 20 15:01:06 that's the problem Mar 20 15:01:33 right, making it mandatory and have a distro check seems like the obvious fix Mar 20 15:02:40 if I add 'gbm', it'll build w/o X11.. but then provides libgbm which conflicts with the custom mali version Mar 20 15:02:53 yeah gbm is 'fun' Mar 20 15:02:57 people have forked it Mar 20 15:03:11 the code in mesa itself is looking for either gbm or 'osmesa == classic' Mar 20 15:03:24 otherwise it throws up it's hands and errors.. Mar 20 15:03:35 (I have no idea what this osmesa thing is) Mar 20 15:03:56 iirc, off-screen Mar 20 15:04:04 and iirc, its obsolete Mar 20 15:04:56 it was enabled for this config about a year ago.. so someone is still using it Mar 20 15:06:27 (enabled in mesa itself) Mar 20 20:56:56 Hmm. fixing my meta-musl-nativesdk layer. sdk relocation didn't fix the interp on all the binaries for some reason. hmm Mar 20 21:12:41 kergoth: interesting whats the goal for this layer, Mar 20 21:12:46 use it on alpine ? Mar 20 21:15:34 I'm just mulling over sdk vs external toolchain packaging for yocto toolchain builds and the possibility of building them statically. musl makes more sense than glibc to try something like that. plus it's just smaller Mar 20 21:15:40 smaller buildtools tarball, etc Mar 20 21:15:53 ex TCLIBC can be glibc while SDKLIBC is musl Mar 20 21:18:13 was pretty simple, https://github.com/kergoth/meta-kergoth-wip/blob/master/meta-musl-nativesdk/conf/musl-nativesdk.conf + https://github.com/kergoth/meta-kergoth-wip/blob/master/meta-musl-nativesdk/conf/distro/include/sdklibc-musl.conf and a few minor tweaks. added bbclassextends, etc **** ENDING LOGGING AT Sat Mar 21 02:59:57 2020