**** BEGIN LOGGING AT Thu Mar 23 03:00:04 2017 Mar 23 03:56:33 why are they needed ? Mar 23 03:59:29 khem: turns out windres needs utf-16 and cp1252 for parsing/generating resource files Mar 23 04:06:28 Is there a nice way to redo a package after a rm -f build/tmp/.../.../package? Mar 23 04:11:36 ok, bitbake package -f -c do_cleansstate :-) Mar 23 04:17:37 just -cclean might be enough Mar 23 04:18:00 nrossi: in this case, I guess it might be ok Mar 23 04:21:01 kergoth: partially because yocto project does not test layers ( due to combotool ) Mar 23 04:21:27 this could be one reason why it gets less attention Mar 23 06:45:40 could someone tell me who is the maintainer of meta rockchip now? Mar 23 07:34:59 Hi is there a way to "include" a machine conf from a different layer in my own machine conf ... seems like require only work in my own layer and include doesn't seem to work at all? Mar 23 07:47:19 sgw_: ping Mar 23 07:48:05 sgw_: there is no LICENSE/COPYING files in meta-intel repository (only in meta-tlk sublayer), can you please clarify it? Mar 23 07:59:41 mdnneo: I think require should work if you use a path relative to the layer directory. E.g. require conf/machine/include/imx-base.inc Mar 23 08:11:37 frsc: seems like it just work if I provide some relative path like ../meta-intel/conf/machine/core-i7.conf and then I get errors about the used requires in this file is not working Mar 23 08:14:07 mdnneo: IIRC it hast to be the full path from the layers root, but not relative Mar 23 08:14:16 like frsc said Mar 23 08:18:54 LetoThe2nd: still I would have the errors the the requie in the file itself fails even if I use the absolute path Mar 23 08:20:32 mdnneo: then maybe show the complete line? we do something similar for our distro to derive from poky, and we see no issues. Mar 23 08:22:41 LetoThe2nd: require ../../conf/machine/intel-corei7-64.conf (the dots are needed in our structure) Mar 23 08:23:05 LetoThe2nd: so we have meta-intel next to meta-our Mar 23 08:23:27 LetoThe2nd: oh there is a meta-intel missing in after the dots Mar 23 08:23:38 mdnneo: just make the path conf/machine/intel-corei7-64.conf Mar 23 08:24:01 mdnneo: i'm pretty sure that the dots are the problem. meta-intel is in bblayers, hopefully. so in the flattened structure, it is just conf/machine/intel-corei7-53.conf Mar 23 08:24:04 mdnneo: It should search each entry in BBPATH for this flle Mar 23 08:25:13 s/53/64/g... unless intel has some cool esoteric boards out that i don't know of yet ;-) Mar 23 08:25:34 still ... Could not include required file conf/machine/intel-corei7-64.conf Mar 23 08:26:17 and you are sure that the layers are all included? Mar 23 08:28:43 LetoThe2nd: pretty since I can build the original machine Mar 23 08:29:07 RP: what license is used for meta-intel? Mar 23 08:29:37 currently I'm not sure if conf files are ment to be included at all? Mar 23 08:29:45 JaMa: for the metadata? Should be the standard MIT afaik Mar 23 08:30:04 there is no LICENSE/COPYING file in meta-intel root, just in meta-tlk sublayer Mar 23 08:30:25 so some coleagues are worried to assume MIT just because it's used almost everywhere else Mar 23 08:30:37 JaMa: that is bad, something sgw needs to fix Mar 23 08:31:01 mdnneo: i can only confirm what RP and frsc said. it works, and it works here too. so the best guess is that you are messing up the path somehow. Mar 23 08:31:14 JaMa: we can get that fixed when sgw is around Mar 23 08:31:54 RP: thanks Mar 23 08:32:33 LetoThe2nd, mdnneo: there is an example with poky-lsb which does require conf/distro/poky.conf Mar 23 08:32:48 mdnneo: you are not putting quotes around the path are you? Mar 23 08:33:03 RP: nope Mar 23 08:34:21 mdnneo: maybe put the real thing onto some pastrbin, instead of manually placing it in here (with all the errors that come with that) so we can have a look. Mar 23 08:35:50 RP, LetoThe2nd : currently just have a build running give me a sek ... I think the poky-lsb is working since its in the same layer, isn't it? Mar 23 08:36:37 mdnneo: maybe that particular case. but it certainly works across layers too. Mar 23 08:44:16 LetoThe2nd: so here you see what I tried and what are the errors Mar 23 08:44:19 http://pastebin.com/J0iuirYC Mar 23 08:46:15 what would be a good method to just call some recipes from one recipe? Mar 23 08:46:57 just create a dummy recipe that would depend on those I want? or there is a better method? Mar 23 08:47:40 Tamis: If you just need to overwrite a function/variable use a bbappend file Mar 23 08:48:40 Tamis: if you want to provide a own package the depend should be ok IMHO Mar 23 08:50:00 mdnneo: I want something basic. I built lets say 5 recipes. I don't want to type those 5 every time. I want to make a recipe make_all_5.bb Mar 23 08:50:39 Tamis: so then I think you want packagegroups Mar 23 08:51:44 mdnneo: hmm thanks I will search for it Mar 23 08:52:00 mdnneo: well according to current meta-intel state, you are mixing things up. there is a file called 'conf/machine/intel-corei7-64.conf', and there is a file called 'conf/machine/include/intel-corei7-64-common.inc'. but no 'conf/machine/include/intel-corei7-64.conf' as stated in your paste Mar 23 08:52:18 Tamis: like poky/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb Mar 23 08:53:02 LetoThe2nd: damn copy paste ... remove the its one lvl up .. without include Mar 23 08:53:49 LetoThe2nd: like in 3. Mar 23 08:54:05 mdnneo: why again did i tell you to give me the real thing instead of mashing something up? Mar 23 08:55:08 mdnneo: so for your paste: 1) has a wrong path. 2) has a wrong path 3) has a relative path and is not supposed to work Mar 23 08:55:40 LetoThe2nd: but the error msg is correct ... also for the correct path ... sry Mar 23 08:56:13 LetoThe2nd: Could not include required file conf/machine/intel-corei7-64.conf ... to many stuff in parallel Mar 23 08:56:40 mdnneo: i am absolutely sure that unless there is something that you fail to mention or are hiding, that "require conf/machine/intel-corei7-64.conf" is correct. Mar 23 08:57:20 LetoThe2nd: using jethro also shouldn't matter? Mar 23 08:57:43 mdnneo: we are actively using this technique on dizzy krogoth and morty. Mar 23 08:57:54 i see no reason why jethro should be different Mar 23 08:58:19 is your layer tinkering with priorities, or messing BBPATH? Mar 23 09:00:33 if in doubt, create a new blank layer, and try again. Mar 23 09:06:44 LetoThe2nd: readding via bitbake-layers add-layer ../meta-intel/ fixed it .. seems like I really messed it up ... sorry for the noise Mar 23 09:08:07 mdnneo: so you are saying that you didn't check bblayers.conf? Mar 23 09:08:33 09:24 < LetoThe2nd> mdnneo: i'm pretty sure that the dots are the problem. meta-intel is in bblayers, hopefully. Mar 23 09:08:59 LetoThe2nd: I checked but I changed the absolute path to use a var ... still need to check whats the problem with this Mar 23 09:09:05 * LetoThe2nd grumbles, sighs, and returns to actually productive stuff. Mar 23 09:09:56 mdnneo: not all ways of variable expansion in bblayers work out. if in doubt, be absolulte. Mar 23 09:10:56 LetoThe2nd: I need to check ... sry for "wasting" your time ... was really not my intention Mar 23 09:21:20 zlib 1.2.8 is no longer on zlib.net Mar 23 09:21:29 how do you usually workaround this? Mar 23 09:23:42 and sf.net mirror has a checksum mismatch :( Mar 23 09:32:01 cornel: we have our own mirror which we enable by default - have you disabled that? Mar 23 09:33:07 bluelightning, no, but this means i must havethat mirror, for example this would not help somebody starting just now Mar 23 09:33:59 cornel: by own mirror I mean it's available now on yoctoproject.org and default configured to fetch from there if fetching from upstream fails - so it should work for everyone Mar 23 09:34:14 bluelightning, ah, i see Mar 23 09:34:42 not sure, maybe it already works, have not checked this. i just assumed it uses our local mirror :) Mar 23 09:34:55 the variable we set to enable it is MIRRORS Mar 23 09:35:01 let me try again Mar 23 09:35:26 the warning is: zlib-1.2.8 not found, trying MIRRORS Mar 23 09:35:39 right - but you just get the warning? Mar 23 09:35:42 not an error? Mar 23 09:35:47 yes, i just get the warning Mar 23 09:36:06 and i wanted to get rid of the warning Mar 23 09:36:32 so i've updated SRC_URI to point to sf.net mirrors, then it failed because checksum was wrong Mar 23 09:36:41 the only way to do that is to fix the recipe's URL to match whatever upstream has moved it to Mar 23 09:36:51 you'd have to ask upstream about that Mar 23 09:37:18 bluelightning, ok, thank you very much Mar 23 09:37:36 at least your build isn't blocked though :) Mar 23 09:37:52 indeed :) Mar 23 09:45:24 Hello there, I am trying to build core-image-minimal image for raspberrypi3. Even I had successfully build, I can not see the wlan interface. What should be the reason? Which kernel module do I have to use Mar 23 09:46:34 btw I have added DISTRO_FEATURES_append += " wifi" to my local.conf Mar 23 09:47:11 kanavin, marquiz: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/224/steps/Running%20oe-selftest/logs/stdio is "interesting". Do we need to do anything about those warnings? Mar 23 09:52:13 ilkmc2r: IIRC 'wifi' in distro features only trigger installation of wpa_supplicant, nothing more, you still have to make sure that your kernel has the right drivers and that these drivers are being loaded Mar 23 09:52:52 mborzecki: Thanks for your feedback, do you have any idea for kernel modules ? Mar 23 09:53:17 mborzecki: I mean for the drivers Mar 23 09:54:20 if you're using meta-raspberrypi then kernel-modules (all of them) should already get installed, now you just need to verify which module is right for your wifi dongle Mar 23 09:55:46 rpi3 has a built-in wifi, right? Mar 23 09:56:10 cornel: yes afaik Mar 23 09:56:33 oh, w8, right ;) i'm still stuck with rpi2 Mar 23 10:00:40 ilkmc2r: looks like there are some patches in meta-raspberrypi master https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=6ce6e57782c23fd21ad47286ac8b809ce989ea78 that might be of interest to you Mar 23 10:03:50 mborzecki: Thanks, I will try this! Mar 23 10:19:12 Hello, I have issues fetching 'file' in morty, I have already applied patch updating SRC_REV but I still get error messages Mar 23 10:19:36 ERROR: file-5.28-r0 do_fetch: Fetcher failure: Unable to find revision acbaf156236cbc54b3cf3bc6cbf05d80cb196451 in branch master even from upstream Mar 23 10:19:39 ERROR: file-5.28-r0 do_fetch: Fetcher failure for URL: 'git://github.com/file/file.git'. Unable to fetch URL from any source. Mar 23 10:19:48 is someone else experiencing similar issues? Mar 23 10:20:07 do you have any hint I could try to work around this issue? Mar 23 10:27:03 nevermind, ";nobranch=1" makes it work again Mar 23 10:27:04 zumbi: when you say you already applied the patch - are you aware that upstream changed their hash and then went back to the old hash? so you probably shouldn't need any patch now Mar 23 10:27:59 RP: warnings, maybe not (as it's only a temporary dir for testing), but errors about unable to allocate memory are a bit of problem. We use host gpg for signing, and I wonder, if we should start building it natively, so we don't have to chase differences across versions and distributions. Mar 23 10:29:10 bluelightning: interesting.. a fresh checkout does not contain the new hash -- I did not notice they went bach to old hash.. Mar 23 10:30:40 kanavin: the memory error was likely due to other builds in progress at the time. But yes, I wondered about the host version independence as we have hit a few issues there it seems :/ Mar 23 10:30:41 bluelightning: right, dropping that patch, makes it work again Mar 23 11:37:26 test_devtool_virtual_kernel_modify took 5 hours to run on the AB :( Mar 23 11:47:45 ouch! Mar 23 11:48:18 joshuagl: ^^^ - slow kernel cloning again :( Mar 23 11:48:25 why it keeps cloning I don't know :/ Mar 23 11:50:53 khem: regarding clang_git.bb... why is binutils in DEPENDS? Shouldn't that be binutils-native or RDEPENDS? Mar 23 11:52:44 RP: urgh :-/ Mar 23 11:52:55 we probably want/need a separate bug to figure that out Mar 23 11:57:16 linux-yocto runs do_populate_sysroot_setscene then later do_fetch :-/ Mar 23 11:58:01 that's in the ~4hrs BuildImages step, before oe-selftest is run Mar 23 11:59:11 joshuagl: the do_fetch is understandable since we don;t put the kernel sources into sstate. The question is why it isn't just updating the existing git repo and refetching the whole thing Mar 23 12:28:04 khem: at least clang compiled without binutils in DEPENDS. I guess binutils is needed just for the linker? Mar 23 12:43:01 hi.. how to remove features from an image using a variable set with BB_ENV_EXTRAWHITE? Is there a way to do this? Mar 23 12:51:23 is there any easy way to create bootable sd card image for BeagleBone Black from Yocto/Poky? I seem to misunderstand BBB booting requirements (RAW mode with dd'ed U-Boot vs. MLO/SPL on a FAT partition) Mar 23 13:00:06 luneff: have you tried wic? Mar 23 13:00:45 not yet. Thanks! I'll look into it Mar 23 13:01:19 bitabke parted-native dosfstools-native mtools-native Mar 23 13:01:21 then Mar 23 13:01:31 wic create sdimage-bootpart -e image-name Mar 23 13:01:39 I misspelled bitbake Mar 23 13:01:55 Will it work with meta-ti? I saw meta-yocto-bsp being specifically non-compatible with meta-ti Mar 23 13:02:18 I have no idea what that means Mar 23 13:02:20 :) Mar 23 13:05:02 ok :-) I'll try wic, thank you :-) Mar 23 13:05:49 good luck Mar 23 13:09:54 luneff: should work with meta-ti too Mar 23 13:10:07 mborzecki, ok :-) Mar 23 13:10:59 best if you pull the latest meta-ti master, a commit that fixed wic support was added just recently https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/conf/machine/beaglebone.conf?id=38dd996ea1b0ad94e6a496336282d5bf23e6f345 Mar 23 13:22:22 Hi! Who can I ask the questions about Outreachy Project? Mar 23 13:23:25 mborzecki, thanks! I hope uEnv.txt stuff is going to be automagically correct :-) Mar 23 13:38:37 ed2: a lot of bugs merged reference #10618, do you think it's closable now? Mar 23 13:39:50 rburton: not sure yet. The goal was to increase coverage to at least 80%. it's 74% atm. Mar 23 13:39:59 ok Mar 23 13:40:14 rburton: however, it seems hard to do, so I might consider closing it anyway. will see. Mar 23 13:40:31 i was just running my git find-bugs command, and that wasn't an obvious one to close Mar 23 13:49:49 mborzecki, thanks! wic produced a bootable image :-) now the PowerVR "fun" starts... Mar 23 14:33:15 saparina: I know one person who can help you Mar 23 14:35:23 saparina: I will let this person know that you are interested, so she will ping you Mar 23 14:44:16 mborzecki: i built an image recently for bbb with this new wic commit, but it won't boot up. u-boot starts, the complains it can't find some things, and it never boots the kernel Mar 23 14:44:44 am i supposed to simply 'dd' the wic file to an SD card, hold the boot button, and boot? Mar 23 14:45:29 yup, that's how it's supposed to work Mar 23 14:45:39 were you using meta-yocto-bsp or meta-ti? Mar 23 14:52:42 I want to get Qt5 running with omapdrm drivers from TI (BeagleBone Black). I can't start any OpenGL ES app because of "CRTC" errors (pvrsrv.. module is on, both "um" and "km" parts for meta-ti graphics is built and running). I learned that CRTC is related to DRM. How do I start an OpenGL ES app that needs DRM? Wayland? Weston? Just some environment magic? Maybe even X somehow? Mar 23 14:53:17 mborzecki: just openembedded-core + meta-ti Mar 23 14:53:40 (and bitbake) Mar 23 14:58:44 tlwoerner: haven't used meta-ti for a while, have you tried with meta-yocto-bsp? beaglebone is supposed to be a reference board, ie. working ootb Mar 23 14:59:13 note that the yocto-bsp beaglebone is fairly crippled, no closed-source drivers for graphics Mar 23 14:59:57 rburton: that's quite the vote of confidence ;-) Mar 23 15:00:10 mborzecki: i'll give yocto-bsp a try, for comparison Mar 23 15:00:20 rburton, I got those drivers but I can't start the examples :-) Mar 23 15:00:28 tlwoerner: I'm replying to your email Mar 23 15:00:55 denix: :-) Mar 23 15:00:55 tlwoerner: the issue is core-image-minimal Mar 23 15:01:24 oh, that's interesting Mar 23 15:01:52 core-image-too-minimal ;-) Mar 23 15:02:06 core-image-minimal omits some stuff that is required to boot :-) core-image-base is better Mar 23 15:04:38 I have a problem with importing a package into yocto Mar 23 15:04:48 luneff: kernel-devicetree? Mar 23 15:05:06 I need to run the git command in src code to generate the version information to C header file Mar 23 15:05:42 tlwoerner: I even had to mention the limitations of core-image-minimal when I added beaglebone to meta-yocto-bsp, see steps 5+ in the manual instructions - http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/commit/README.hardware?id=283b51b0149f7e5838bd1c8465451897baf0bf44 Mar 23 15:05:47 but it can't work in yocto system as it would switch to the other directory build source code Mar 23 15:06:41 mborzecki, 4.9.13-git from meta-ti morty. The error I get states "WSEGL_CreateWindowDrawable: Couldn't set CRTC: Invalid argument [0, ]" and "EGL_BAD_ALLOC" :-( Mar 23 15:07:09 sorry, i meant to ask what's missing from core-image-minimal, my guess was kernel-devicetree ;) Mar 23 15:07:39 mborzecki, uh. yes :-) no dtbs and half of /lib/modules/`uname -r` :-) Mar 23 15:07:52 denix: ah, that matches what i was seeing Mar 23 15:08:32 tlwoerner: of course, ed2 had to drop all the important details about core-image-minimal limitations when replacing instructions with wic... Mar 23 15:09:53 denix: by the look of it https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/beaglebone.conf#n20 it should be possible to build a bootable core-image-minimal with meta-yocto-bsp Mar 23 15:10:10 ih, my case https://lists.yoctoproject.org/pipermail/meta-ti/2016-October/009092.html Mar 23 15:10:45 mborzecki: IMAGE_INSTALL_append yeah, tlwoerner doesn't have that Mar 23 15:11:35 luneff: yeah, google is your friend Mar 23 15:12:09 luneff: everything has previously been discussed, including mesa/gbm conflict... Mar 23 15:12:15 what's strange is, looking at openembedded-core/meta/recipes-core/images/core-image-base.bb, it *looks* as if all it adds is: IMAGE_FEATURES += "splash" Mar 23 15:16:36 btw, such a hypocrisy - has binary-only drivers = bad, doesn't have binary-only drivers = crippled... Mar 23 15:28:08 denix, ok. I'll try meta-arago and weston, got the gbm part Mar 23 15:28:56 luneff: you just need a weston bbappend from there with few extra patches Mar 23 15:33:07 tlwoerner: did you finally get it working? Mar 23 15:34:50 denix: haha patience... i have 2 other builds i'm trying to do at the same time, and those others aren't doing well :-) Mar 23 15:38:09 denix: my machine is at loadavg 89.06... Mar 23 15:38:39 tlwoerner: sounds about right :) Mar 23 15:49:17 luneff: the main issue I ran into was TI's libgbm.so having a different name from the standard one (libgbm.so.2 instead of libgbm.so.1) Mar 23 15:49:50 so.. is anyone else seeing the new bitbake-dumpsig -t argument hanging at waitpid and never exiting? Mar 23 15:49:52 luneff: this had a tendency to result in *both* being loaded into the same application via different paths, with hilarious results Mar 23 15:50:00 i.e. bitbake-dumpsig -t autoconf-native do_configure hangs Mar 23 15:50:10 luneff: other than that, getting the drivers working went fairly smoothly Mar 23 15:50:18 s/drivers/userspace libs/ Mar 23 15:50:53 luneff: with yocto I expect this issue shouldn't exist though, since you can simply compile the world against libgbm.so.2 instead of libgbm.so.1 Mar 23 15:51:57 zmatt, well, I'm taking weston-2.0 with meta-arago .bbappend that deals with this problem. Some hours later we'll see the difference :-) Mar 23 15:52:20 has nobody realised that forking libgdm is a really bad idea yet and actually sorted this out Mar 23 15:53:21 rburton: the thing is, the gbm backend and the WSEGL backend of the powervr libs are one and the same Mar 23 15:54:01 whereas mainline gbm dropped support for backends other than mesa's Mar 23 15:55:02 I don't know much about all this hairy stuff other than what I saw while getting the libs to work though Mar 23 15:55:10 luneff: are you trying master with weston-2.0? that won't work Mar 23 15:55:38 denix, the .bbappend from arago appends to 2.0. Mar 23 15:56:02 luneff: the patches apply to 1.9/1.11, but 2.0 changed sources a bit - I was looking at rebasing them... Mar 23 15:56:10 lukma: yeah, the patches will fail to apply Mar 23 15:56:25 rburton: i.e. libpvrGBMWSEGL links to pvr's "libdbm", which based on symbols looks suspiciously like it's doing the same thing as libgbm, again (NIH syndrome?) Mar 23 15:57:21 rburton: fun project would be to intercept those and redirect them again to mesa's libgbm ;-) Mar 23 15:57:21 denix, should weston_2.0.0.bbappend be ignored then? Mar 23 15:57:50 luneff: btw, krogoth and morty is what's been tested Mar 23 15:58:03 rburton: we've discussed this some time ago Mar 23 15:58:16 zmatt: libgbm is just a shim Mar 23 15:58:29 denix: *which* libgbm ? :) Mar 23 15:58:35 zmatt: https://github.com/robclark/libgbm Mar 23 15:58:40 yes, that one is Mar 23 15:58:49 zmatt: btw, I see you are quick to call names... Mar 23 15:59:00 am I? Mar 23 15:59:52 the NIH-thing was maybe a bit uncalled for Mar 23 15:59:53 denix, ok, got it Mar 23 16:00:44 rburton: anyway, it's not re-implementing things, it's just glueing stuff together, as described in the the README in the link above Mar 23 16:01:39 denix: there are numerous clones of libgbm which is sad. i don't see why it can't be ripped out of mesa tbh. Mar 23 16:01:57 google has another copy which does more than mesa's one Mar 23 16:02:13 I don't know the history, but looking at current libgbm from mesa, it looks like it had pluggable backends but this was abandoned? Mar 23 16:03:07 since this is the backend "loader" right now.... https://cgit.freedesktop.org/mesa/mesa/tree/src/gbm/main/backend.c Mar 23 16:03:50 rburton, zmatt: last time we discussed it, the suggestion was to be able to disable gbm in mesa in order to use "alternatives"... Mar 23 16:05:11 denix: I basically did that... dpkg-diverted libgbm.so.1 out of the way and replaced it with gcc -shared -o libgbm.so.1 libgbm.so.2 Mar 23 16:05:39 zmatt: is that in debian? Mar 23 16:05:42 yeah Mar 23 16:06:00 I see. yeah, we also need to resolve build conflicts in OE/Yocto Mar 23 16:06:03 no idea what I might have broken by doing that, but Qt5 eglfs_kms seems to work fine Mar 23 16:06:10 ditto kmscube Mar 23 16:06:16 (after I fixed it to support tilcdc) Mar 23 16:06:47 oh and one other lib needed a similar redirection iirc... Mar 23 16:07:49 yeah, gcc -shared -o libGLESv2.so.2 libGLESv2.so.1 Mar 23 16:08:47 and I created a null libdrm_omap since the sgx libs for am335x pointlessly link to that Mar 23 16:10:21 oh and I patched Qt since it uses hardcoded XRGB8888 format while RGB565 should be used on the beaglebone Mar 23 16:10:27 apart from that it pretty much worked out of the box ;) Mar 23 16:11:01 simples! Mar 23 16:11:29 zmatt: yeah, it should work out of the box... I've heard that before. that's not counting all the patches :) Mar 23 16:12:58 rburton: any recommendation for dealing with gbm before I go? Mar 23 16:13:45 none Mar 23 16:17:25 https://gist.github.com/kergoth/5744c784efb16d73ceaa332ac4276f49 seem reasonably sane? for after this release, obviously, since it's not a bugfix. just a minor new bitbake arg Mar 23 16:17:32 denix: I was too lazy to recompile Qt though, but this worked -> https://hastebin.com/vafajeruvo.pl Mar 23 16:18:49 <3 the newly sorted -e Mar 23 16:19:01 zmatt: heh, that's heavy :) Mar 23 16:20:35 a proper patch would be to make Qt's eglfs backend support more than one hardcoded framebuffer format of course, and actually check which is supported by the kernel driver Mar 23 16:20:47 it's vaguely somewhere on my to-do list :P Mar 23 16:44:27 denix: w00T! much better :-D Mar 23 16:44:59 (still wish i could figure out why core-image-base is seemingly only different from core-image-minimal by adding splash....) Mar 23 16:45:59 IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}" Mar 23 16:46:09 thats the important bit in -minimal Mar 23 16:49:42 rburton: ah, so it's not that -base adds so much as -minimal defines its own IMAGE_INSTALL which has less (?) Mar 23 16:51:26 hmm.. -base has packagegroup-core-boot and packagegroup-base-extended whereas -minimal is just the first Mar 23 16:52:16 tlwoerner: yeah, minimal overrides IMAGE_INSTALL to just pull in what it says, everything else uses the default assignment in the class Mar 23 16:52:42 rburton: nice Mar 23 16:56:00 saparina: I was told you needed some information Mar 23 17:35:29 :-( I took weston .bbappends & patches from meta-arago, placed them in my own layer, placed it last in bblayers.conf. I've added PACKAGECONFIG_append = "kms" in that bbappend (temporary hack), PACKAGECONFIG_append_pn-weston = "kms" in local.conf. weston still things he needs virtual/mesa and thus breaks :-( Mar 23 17:36:46 luneff: did you set a preferred provider for virtual/mesa? Mar 23 17:36:53 (or do the arago bbappends remove that) Mar 23 17:37:03 no, preferred is ti-sgx stuff Mar 23 17:37:28 "mesa PROVIDES virtual/mesa but was skipped:" Mar 23 17:38:26 sounds like you need to set an alternative provider for virtual/mesa Mar 23 17:39:40 no, mesa is not the thing being provided Mar 23 17:39:41 no, i need to get PACKAGECONFIG["kms"] from openembeded-core weston 1.11 overriden by this bbappend. so that virtual/mesa goes away at all, I'm not having it Mar 23 17:41:34 * luneff enabled dirty hack mode Mar 23 17:44:22 ok, dirty hacking work. and I seen to have "wayland" PACKAGECONFIG in this configuration that brought virtual/mesa Mar 23 18:45:08 huh, https://github.com/Qix-/better-exceptions Mar 23 19:38:12 https://lkml.wtf/post/2017-03-23/ amuses me Mar 23 19:44:54 * paulg wonders which of the three is kergoth's favourite Mar 23 19:45:22 I'm guessing the clang kooks. Mar 23 19:45:48 only 'cause I have to personally endure some of them myself. Mar 23 22:44:48 what MACHINE is a Minnowboard Max (Bay Trail)? In LX8 is was a "intel-corei7-64" which is no longer availalble. Is it now a 'intel-x86-64'? Mar 23 22:47:13 dreyna: well, the machine names in meta-intel haven't changed Mar 23 22:48:06 zeddii: ^ Mar 23 22:48:08 ah, sorry **** ENDING LOGGING AT Fri Mar 24 03:00:00 2017