**** BEGIN LOGGING AT Fri Oct 17 03:00:00 2014 Oct 17 07:23:01 after doing some toaster poking, i'm always unable to get it working, only thing i see in the browser is a 501 error. any pointers? Oct 17 07:58:30 morning all, did someone got a yocto recipe for sdl_mixer v2? Oct 17 09:05:21 Hi! I'm trying to build QT5 (5.3.2) from meta-qt5 without X11 or Wayland and it fails due to the following error: eglvivante.h:222:22: fatal error: X11/Xlib.h: No such file or directory Oct 17 09:07:09 I think this error occurs because EGL_API_FB isn't defined, but i have no idea what should define this. Oct 17 09:08:35 morning all Oct 17 09:09:32 good morning! Oct 17 09:09:59 hi auke- Oct 17 09:10:42 Has someone experience with the meta-intel layer? I'm very confused about the state of support regarding GPU/QuickSync etc. with ATOM E3845 Baytrail CPUs. One the one there seems to be an EMGD driver on the other there is a valleyisland layer mentioned, but that does not seem to be part of the meta-intel daisy branch. In the meta-intel layer README they say for Baytrail SOCs one should use the intel-corei7-64 config, but Oct 17 09:10:42 this config does not use the EMGD driver. Oct 17 09:12:30 volker_123456: I'm pretty sure we don't use EMGD on baytrail-based systems Oct 17 09:13:07 it's not my area of expertise though; if you don't get an answer here I would strongly recommend emailing the meta-intel list Oct 17 09:14:32 bluelightning: thx: ok, I'm just wondering what that means for hardware acceleration support. Intel itself seems to mention EMGD for the E3800 family: http://www.intel.com/content/www/us/en/embedded/software/emgd/atom-e3800-and-celeron-n2807-n2930-j1900.html Oct 17 09:15:10 but I also saw that there was some comment on the meta-intel mailing list, that EMGD is retired (whatever that means and what's the reason for that) Oct 17 09:17:23 I think the answer there is that EMGD is binary-only and is tied to the particular kernel version it was built against Oct 17 09:17:40 within meta-intel at least we prefer to use the open source drivers which do not have that limitation Oct 17 09:19:27 but the best way to get a definitive answer on any of these kinds of questions is to email the meta-intel list Oct 17 09:24:31 Hm. So I have a build that has three layers meta-myhardware, meta-mymiddleware and meta-myapplication. Now, it so happens that I pull the conf from the "myapplication" layer via TEMPLATECONF with oe-init-build-env. However, I'd really like to have a bit of local.conf that sets up certain vars for the mymiddleware as well. Is there a way you can build / inherit things or do I just have to bodge it into the other layers local.conf.sample instead? Oct 17 09:32:53 Hello all; I need help, I need to write some recipe which need to build an image (like initram) to include it in a binary, and, to make a final package. Oct 17 09:33:35 at this moment, I have a "bad" solution, witch consiste to have a package witch depend to an image, and make all thing, but, i think it's not the best way to do... Oct 17 09:34:06 the question is, how to generate in a do_compile for exemple, a rootfs or an image ? Oct 17 09:39:23 pev: you really should have a distro layer to contain such policy configuration Oct 17 09:40:17 condo43: any recipe that produces an image should simply "inherit image" which will allow it to produce an image during do_rootfs Oct 17 09:40:26 (or core-image) Oct 17 09:47:43 bluelightning: OK, I'd looked at this before but the documentation is a bit thin - can you reccommend any documentation / good examples? Oct 17 09:48:05 pev: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution Oct 17 09:48:18 bluelightning: Yes, I success to build an image, my problem is to include this image in a package Oct 17 09:48:19 (I'm happy to help if that doesn't cover things adequately) Oct 17 09:48:43 condo43: I don't follow - why would you include the image in a package? the image is composed of packages itself... Oct 17 10:07:36 toaster people, heads up? i'm trying to follow on the quick start instructions, but my interface only gives me a 501 page Oct 17 10:19:41 bluelightning: In fact, we build an uboot with an embedded minimal kernel+initrd for rescue Oct 17 10:20:58 the process is to build a busybox minimal, a kernel, different filesystem part... generate u-boot elf, and make a file with uboot elf, and the kernel + initrd, and store it into RPM u-boot installed on the system Oct 17 10:21:11 condo43: ok, well, if the recipe producing that binary (u-boot itself?) has a task dependency on do_rootfs for the initramfs image, that would be the way to implement that Oct 17 10:21:51 ok, i will try this solution... I'll back later if I fail... Oct 17 10:28:02 hm. is there current breakage on master? current checkout breaks core-image-minimal with: Nothing PROVIDES 'gzip-native' Oct 17 10:30:18 LetoThe2nd: I have to say I don't see that error... Oct 17 10:30:27 bluelightning: hmhmhm. Oct 17 10:30:42 let me retry, maybe i managed to whack my builddir Oct 17 10:32:53 LetoThe2nd: it would be metadata or configuration triggering that though Oct 17 10:33:17 bluelightning: metadata is totally unchanged poky Oct 17 10:33:36 no additional layers, just tring to cook up a super minimal functional toaster testing case Oct 17 10:34:05 right... I guess what I was hinting at was if you were thinking of trying to delete tmpdir or something like that in order to fix it, it's unlikely to have an effect Oct 17 10:36:16 e.g. checkout, source env, set downloads and sstate, source toaster start, kick build Oct 17 10:37:14 i interrupted it on my first try though, so recreadting builddir seems to have fixed it Oct 17 10:37:44 that is worrying... Oct 17 10:37:59 yeah. Oct 17 10:38:20 i actually just did ctrl-c during a running bake Oct 17 10:38:36 during the parsing I guess? Oct 17 10:39:52 or later? Oct 17 10:42:11 don't know actually. think it was later, though Oct 17 10:56:45 LetoThe2nd: hi - heard you encoutered Toaster issues Oct 17 10:56:55 LetoThe2nd: anything I can help with ? Oct 17 10:58:25 ddalex: maybe! thanks for stepping up.. basically see for yourself at http://54.77.181.136:8200/ Oct 17 10:59:31 LetoThe2nd: are you running the out-of-box configuration ? if so, please open up the browser to port 8000, not 8200 Oct 17 10:59:45 the startup message is quite confusing Oct 17 10:59:49 ddalex: totally out of the box :) Oct 17 10:59:54 ok, let me check Oct 17 11:00:18 LetoThe2nd: the web server runs on port 8000, the bitbake server is on port 8200 Oct 17 11:00:51 LetoThe2nd: bitbake protocol is HTTP-based, so a browser will connect to it, but can't do anything useful Oct 17 11:02:19 GAAAH gotcha Oct 17 11:02:43 i'd really, REALLY encourage anybody to change that startup message! Oct 17 11:03:16 ddalex: on my todo list, thanks Oct 17 11:03:53 ddalex: i've poking this now for about 6hrs, feel free to drop dead laughing :-( Oct 17 11:04:03 *been Oct 17 11:10:33 LetoThe2nd: sorry about the mess Oct 17 11:11:10 LetoThe2nd: we debated about automatically starting a browser, it might have been helpful Oct 17 11:12:25 ddalex: i just re-read the startup message, which really is like "starting webserver - interface 0.0.0.0 - successful start" Oct 17 11:12:34 bluelightning: I tried cherry picking the mesa-demos 8.2.0 from master (to daisy) to get them compiled without glew/x11. But it still requires libglu and this seem to depend on libGL and that seems to be not compiled by the mesa package if you don't specify X11. At least libglu fails during linking with "cannot find -lGL" Oct 17 11:12:48 the automagic browser wouldn't have helped, it's a non-X ec2 instance Oct 17 11:13:58 LetoThe2nd: ok, then changing the startup messsages will be done on the next merge request Oct 17 11:14:22 ddalex: if possible, i personally would just add a final line saying something like "find your webinterface on 127.0.0.1:8000" or something similar Oct 17 11:14:37 ddalex: Oct 17 11:14:50 ddalex: thanks! Oct 17 11:16:25 volker_123456: I just passed that on, I don't have the details; but libglu shouldn't be being built since AIUI libGL cannot work without X11, so the dependency on libglu is where the problem lies Oct 17 11:17:22 LetoThe2nd: sure; feel free to ping me again for any issues Oct 17 11:20:10 thanks, that hint maybe gave me the solution: in the mesa-demos_8.2.0.bb file there is the following line: PACKAGECONFIG ?= "drm osmesa freetype2 gbm egl gles1 gles2 glu ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 glew', '', d)}" but I guess it has to be: PACKAGECONFIG ?= "drm osmesa freetype2 gbm egl gles1 gles2 \ Oct 17 11:20:10 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 glew glu', '', d)}" at least it now compiles correctly..... I will check if it also results in a correct packaging on the final image Oct 17 11:20:41 volker_123456: that sounds like a reasonable fix Oct 17 11:21:46 I think it's fair to say we need more testing of x11 not in DISTRO_FEATURES Oct 17 11:21:54 (on the autobuilder, I mean) Oct 17 11:22:02 I might file a bug Oct 17 11:24:14 bluelightning: yes, certainly Oct 17 11:24:32 the weston-no-x11 image should be a good test, as it builds gtk and clutter too Oct 17 11:25:12 (more accurate, core-image-weston without the x11 distro feature set) Oct 17 11:39:26 any tips on how to resolve "requires libGLESv2.so, but no providers in its RDEPENDS" QA issues? Oct 17 11:42:04 just add virtual/libgles2 to RDEPENDS? Oct 17 12:03:40 by the way, whats the overall state concerning the eclipse plugin? $COWORKER just told me the last commit has been like 14 months ago.. Oct 17 12:10:45 bluelightning: strange, now bitbake doesn't seem to realize there have been changes to local.conf Oct 17 12:12:35 could that be a sideeffect of the toaster instance running? Oct 17 12:13:31 LetoThe2nd: yes it does stay memory resident Oct 17 12:13:59 LetoThe2nd: unfortunately there are a few things like that with the memory resident functionality that don't work as well as they should Oct 17 12:14:22 bluelightning: hm is that a local-sqlite-toaster effect only? or is it always like, stop toaster-change-start toaster again? Oct 17 12:14:46 Net147: that should do it... Oct 17 12:14:51 Net147: FYI: http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#qa-issue-file-rdeps Oct 17 12:14:57 (just added yesterday) Oct 17 12:16:02 LetoThe2nd: it's unfortunately a known issue with the bitbake memory resident functionality which toaster requires Oct 17 12:16:14 something we will hopefully address in the upcoming dev cycle Oct 17 12:16:22 ok, i see Oct 17 12:16:59 LetoThe2nd: re the eclipse plugin, we're still looking for help with that basically Oct 17 12:17:28 bluelightning: has j.zh. been reassigned, or something like that? Oct 17 12:17:57 LetoThe2nd: she's the manager of our team now Oct 17 12:18:08 bluelightning: uh-huh Oct 17 12:21:25 it looks like we still have a job opening for that so if you know anyone who would like to work on Eclipse, let us know Oct 17 12:22:30 (we being Intel in this instance, just in case that's not clear) Oct 17 12:22:37 bluelightning: I noticed a few weeks ago in poky master that if I have file://somedir specified in a recipe, it didn't rebuild if a file inside somedir changed. is that normal? Oct 17 12:22:40 bluelightning: duly noted ;) Oct 17 12:23:24 bluelightning: actually my eclipsing coworker is just sitting on the other side of the table and trying to dig into the plugin ;) Oct 17 12:23:30 Net147: I don't think that is expected no Oct 17 12:24:11 LetoThe2nd: ok, cool... FWIW I think we'd also be keen to have (tested) patches as well ;) Oct 17 12:25:01 bluelightning: i can understand that desire.. if he comes up with something i shall have it forwarded, but given our r&d team size and workload, don't expect much Oct 17 12:25:18 LetoThe2nd: no worries, just putting it out there :) Oct 17 12:26:21 bluelightning: :) Oct 17 12:33:51 bluelightning: i just fear your offer tempted him too much.. seeing him leave would be a huge blow Oct 17 12:34:14 * LetoThe2nd continues pointless mumblings Oct 17 12:36:57 I would certainly hope not to have anyone join us at the expense of leaving a big gap somewhere else; but then, that's always hard Oct 17 12:38:37 yeah don't take my mumblings too seriously, i'm just trying to do some yoctos tinkering during the train ride home from elce Oct 17 12:39:41 net result: some more understanding of toasters pitfalls Oct 17 12:43:15 Hi everybody, can someone suggest where I can find examples of using python code in recipes? I have read documentation, but not sure if I understand everything Oct 17 12:57:42 speaking of ELCE did they announce where it is next year yet? Oct 17 12:58:44 rburton: not that i know Oct 17 12:59:28 ndec: same here Oct 17 12:59:50 how am i meant to plan next years holiday without knowing where elce is! Oct 17 12:59:53 ndec: seems like we successfully managed to run away from each other all week Oct 17 13:00:09 LetoThe2nd: yeah. i tried hard, and it seemed to work ;_) Oct 17 13:00:24 ndec: hooray Oct 17 13:00:36 well, i am still here, you too? Oct 17 13:00:47 ndec: nah i'm riding the mystery train Oct 17 13:01:08 little sandworm is waiting for me Oct 17 13:01:27 ;-) Oct 17 13:02:06 i also missed woglinde.. so maybe next time Oct 17 14:24:07 bluelightning: Thanks - I've had a read through that and giving it a shot. Is there any convention for how / where you keep multiple configurations? I'm assuming you probably would want to keep in your distro layer somewhere and then point at with TEMPLATECONF when you set up the build environment? Oct 17 14:40:06 pev: well TEMPLATECONF could point to a dir containing template config files which added the distro layer and set DISTRO to point to the distro config within that layer, yes Oct 17 14:43:58 bluelightning: Grand, thanks. Just trying to figure out what the way thats "normal" is - I'm sure I can't be the only person with five or six standard configurations to support in that kind of way?! Oct 17 14:46:21 pev: I would expect not, but it ought to be as simple as separate distro files for each configuration Oct 17 14:46:43 they can be as close as right next to eachother, even sharing common parts through inc files; or they could be in completely separate layers Oct 17 14:46:51 all depends on what you're trying to do Oct 17 14:50:47 bluelightning: Well, I've created layer splits so individual layers for each custom board (where warranted) and then project specific software layers. Then theres also a general distro layer for all the common stuff and another layer for a particular bit of middleware thats always shared. Oct 17 14:52:22 so something like meta-pev (distro layer) // meta-pev-hw-boardN // meta-pev-sw-projectN // meta-pev-sw-middleware Oct 17 14:53:04 so there are lots of different ways you could handle it; but at face value it's possible that you would need a distro config for each project so it might go into the project-specific software layer Oct 17 14:53:10 I was going to create dirs something like meta-pev/oeconf/proj-configN and put the local.conf.sample and bblayer.conf.sample under each Oct 17 14:53:11 depends how different the projects are Oct 17 14:53:41 well, one of the things the distro config is supposed to help with is avoiding putting too much into local.conf Oct 17 14:54:10 Ah, OK, I was thinking "distro" was something more broad, hadnt thought that it was so flexible. I guess I should read up a bit more about that... Oct 17 14:54:12 local.conf is really supposed to be just selecting distro, machine, and specifying local paths Oct 17 14:54:20 Ah.... Oct 17 14:54:34 So effectively then the per-project element is the distro config then, gotcha Oct 17 14:54:39 yep Oct 17 14:55:08 Right, I'll stick my nose back into the ref manual again then and experiment some more :-) Oct 17 15:46:51 bluelightning: Am I better off duplicating poky.conf then modifying and trimming? Looks like I change / lose a lot just doing whats in the ref manual and starting with a bare conf Oct 17 15:47:22 pev: you can certainly do that Oct 17 15:47:35 you can also just include/require poky.conf if you dont' mind a layer dependency on meta-yocto Oct 17 15:47:37 * kergoth yawns Oct 17 15:48:07 and you don't care about your distro config changing to match anything new that gets added to poky.conf Oct 17 15:48:26 (not that that happens often) Oct 17 15:48:28 indeed, good point Oct 17 15:51:56 kergoth: Ah yes! I see that's what poky-tiny does... That's a good plan as it does a lot of handy stuff already Oct 17 15:57:16 OK. Here's an unrelated question... In my world I have a few different kernel versions that get built, e.g. linux-imx-3.0.35 and linux-imx-3.10.17. These get built by different recipes selected by PREFERRED_VERSION in the distro files now. Oct 17 15:57:50 Now, take for example something like v4l-utils. In it's package it contains its own copy of various kernel headers such as videodev2.h. So when building different distros with different kernel versions the included videodev2.h will probably be wrong. Oct 17 15:58:10 the high-maintenance approach would be to create different v4l-util recipes to match the kernels Oct 17 15:58:46 but could you for example just have the one v4l-utils recipe that matches the version of yocto we're using and then add a bbappend to patch? Oct 17 15:58:52 (which is what I do at the mo) Oct 17 15:59:12 but how would you then with the two kernels via preferred_version select the different patch in the v4l-utils recipe? Oct 17 15:59:25 or is there a simple and obvious solution I'm missing? :-D Oct 17 16:02:51 also, creating the new distro (just requiring poky.conf and setting DISTRO=) seems to now build a new gcc-cross and I guess much more rather than pulling from sstate-cache - is that expected? Oct 17 16:03:16 a distro change is pretty invasive Oct 17 16:03:24 even if none of the vars it sets change Oct 17 16:05:37 Ah, OK, I'll just have to suck it up then.... Oct 17 16:08:38 Maybe I'm better off supporting my multiple configurations just by using various local.conf.sample versions and TEMPLATECONF then. This could get pretty tedious if I have to build different full toolchains for each board type I'm using... ?! Oct 17 16:14:01 i wouldn't recommend that. maintanance over the long term you're best off using a distro. local.conf is best for temporary or user changes Oct 17 16:17:03 Hm... Oct 17 16:18:31 but it does depend on the situation, of course. everyone has slightly different workflow :) Oct 17 17:30:54 Hm, anyone seen : "ERROR: QA Issue: eglibc-locale: Files/directories were installed but not shipped" ? Oct 17 17:31:13 Changed to new distro conf which is basically a dupe of poky-tiny with a name change and I get that Oct 17 19:02:57 I'm writing a bitbake file for a package that needs build_dir = src_dir, is there an accepted way to do that? Oct 17 19:03:53 B = "${S}" if not autotools, or change inherit autotools to inherit autotools-brokensep if autotools Oct 17 19:09:31 kergoth: thanks. Oct 17 19:09:45 np Oct 17 19:17:17 RP, home? **** ENDING LOGGING AT Sat Oct 18 02:59:59 2014