**** BEGIN LOGGING AT Wed Dec 07 03:00:00 2016 Dec 07 03:30:19 anyone else seeing qemu segfault in the update_fonts_cache postinst intercept? Dec 07 03:30:28 even with the qemux86-64 MACHINE Dec 07 04:51:01 hi there Dec 07 04:51:36 I know it has been asked once in 2014, but how to enable ccache globally exactly? Dec 07 04:52:05 last time it’s mentioned on irc, but it seems no one answered this Dec 07 04:53:38 ccache is critical for rebuilding yocto from scratch within CI Dec 07 04:58:45 CI ? Dec 07 04:59:35 * paulg thought a kick arse multi core xeon was critical for rebuilding yocto from scratch Dec 07 05:01:45 kergoth, so -- our distro sanity tests have some gaps ; thanks for the prodding ; will send some improvement patches tomorrow. Dec 07 05:02:12 where "our" = yocto/oe Dec 07 05:02:21 np, glad you nailed it down Dec 07 05:03:34 surprisingly (to me) we just go numb and emit nothing if the supported distro list is blank; one of my patches adds a bbwarn for that. Dec 07 05:07:46 I could see someone wanting to explicitly disable host support checking entirely, if they're using local development distro and just don't care, so it'd be good to have a way to indicate that it's empty on purpose and don't want to see a warning for it. i.e. have a separate var to enable/disable the check vs emptying the list Dec 07 05:07:48 * kergoth ponders Dec 07 05:09:32 paulg: multi core xeon is not affordable for everyone Dec 07 05:10:56 and sometimes you just don’t have the access to replace cpu on the CI workstations Dec 07 05:11:35 anyway, that’s not the problem. Yocto requires ccache being installed in its installation steps Dec 07 05:12:09 so, how do people turn on that ccache support at all? Dec 07 05:13:34 if that’s no longer the prefered way, then probably yocto should remove ccache from its prerequisites and add multi core xeon processors Dec 07 05:13:37 huh? ccache does not have to be installed, it's not required in any way shape or form. just set CCACHE = "ccache " to enable it Dec 07 05:14:44 i can't imagine ccache is of that much use with sstate, though maybe it helps when a metadata change ripples outward and invalidates a good chunk of the sstates in a given dependency graph Dec 07 05:15:40 also, yocto is an umbrella project, it doesn't require anything. perhaps you're referring to poky, yocto's reference distribution, or the poky repository, which includes various open source components (oe-core, meta-yocto, bitbake) Dec 07 05:16:27 vicamo, the xeon comment was 1/2 in jest. I've done recent builds on a 2007 vintage core2-duo. They are fine ; they just take something like six hours instead of one hour. Dec 07 05:17:12 kergoth: my problem is around ccache, not sstate. Dec 07 05:17:20 and yeah, that is with no ccache and no sstate -- fully from scratch Dec 07 05:17:33 i have no idea what you're talking about. again, ccache is optional, and again, enabling it is trivial Dec 07 05:17:41 paulg: I have one workstation that finishes in half an hour, but that’s not good enough for me Dec 07 05:18:01 i only bring up sstate because it provides task level binary artifact caching, partially reducing the need/value of ccache Dec 07 05:18:26 if half an hour isn't good enough, you're in for a rough ride. rebuilding half a linux distro is going to take a while no matter what you do Dec 07 05:18:47 I used to play with ccache and distcc but post 2010 I found it simply was not worthwhile. Dec 07 05:18:53 kergoth: no, exporting CCACHE doesn’t seem to enable ccache. No tmp/ccache folder is created. Dec 07 05:19:06 it's not exported at all Dec 07 05:19:10 it's set in the metadata Dec 07 05:19:23 set CCACHE = "ccache " in local.conf or your distro .conf Dec 07 05:19:40 kergoth: I know it’s gonna take a while, but since I haven’t successfully try ccache, I’d like to know its limit. Dec 07 05:21:07 fair warning ; last time I poked at ccache it had a cache size limit that was truly 1998 vintage. Dec 07 05:21:41 kergoth: tried setting CCACHE in local.conf, gives “Please install the following missing utilities: C Compiler (ccache gcc ),C++ Compiler (ccache g++ )” Dec 07 05:21:48 so if you dont enlarge that beyond the tiny default you will get all of the overhead and none of the cache benefits.... Dec 07 05:21:58 so there must be some formal way to enable ccache? Dec 07 05:22:06 vicamo: that's just a bug in the sanity checker Dec 07 05:22:13 setting CCACHE is the "formal way" Dec 07 05:22:24 there's just a bug, no doubt becuase hardly anyone bothers with ccache anymore Dec 07 05:23:18 yah, seriously just run without it and then try to prove to yourself that enabling it in some way saves you time. Dec 07 05:23:42 I expect you won't be able to justify the latter part of the above sentence. Dec 07 05:24:49 everybody has a different use case so maybe you'll prove us wrong, but start by capitalizing on the experience here.... Dec 07 05:24:53 paulg: I recompiles yocto from a clean clone for CI. So there is no such thing called sstate in this case. Dec 07 05:25:45 paulg: I’m not saying you’re wrong. I’m saying yocto supports ccache, so it’s supposed to work out of box. Dec 07 05:25:54 That really doesn't make a great deal of sense. If you're retaining your ccache dir between CI builds, then you can retain sstate between CI builds. trivial. Dec 07 05:26:53 kergoth: so in order to preserve sstate blobs, which folders do you suggest me to save? Dec 07 05:27:04 see the SSTATE_DIR variable Dec 07 05:27:28 see also SSTATE_MIRRORS, which lets you pull from a remote mirror location rather than local path. whichever is easiest for you Dec 07 05:31:02 kergoth: but SSTATE_DIR doesn’t contain built binaries, how does it serve as the role ccache does? Dec 07 05:31:09 what are you talking about? Dec 07 05:31:15 SSTATE_DIR contains tarballs of built binaries Dec 07 05:31:17 that's the whole point Dec 07 05:31:36 it archives all the output for its task. not individual objects, but the final output. Dec 07 05:31:55 i.e. all the files put into the sysroot for the recipe are in the do_populate_sysroot sstate archive Dec 07 05:32:16 the metadata is checksummed, so it knows when it can use it and when it and its dependent tasks need to be re-run instead Dec 07 05:33:30 kergoth: thanks, I’ll check this again Dec 07 05:37:51 Hello all was able to add the gcc compiler Dec 07 05:38:39 Can we be able the source code Dec 07 09:19:15 Hello. Does anyone have a working bitbake recipe that successfully builds and packages qwt for qt5? Dec 07 09:28:11 INHERIT_linux-yocto += "ccache" in local.conf does not seem to have the same effect as adding "inherit ccache" in a .bbappend, is that normal ? Dec 07 09:31:41 iNHERIT_pn-linux-yocto Dec 07 09:45:12 kergoth: thanks, preserving sstate-cache finishes the second build in one minute Dec 07 09:58:24 Hi, I have some kerenel fragments and patches in BSP layer (meta-testBSP/recipes-kernel/linux/files) and everything works. But I would like to split the files to subdirectories e.g. meta-testBSP/recipes-kernel/linux/files/fragments and /patches. Dec 07 09:59:14 I tried several solutions, but I wasn't succesfull.. Does anybody have any suggestion how it could be done? Dec 07 10:12:53 file://fragments/ ? Dec 07 10:16:37 my problem is that when I do oe_runmake install INSTALLROOT=${D} SBINDIR=${sbindir} MANDIR=${mandir} INCLUDEDIR=${includedir} I get permission denied because make tries to create a directory in /usr/local Dec 07 10:16:57 I checked the makefile in my work folder Dec 07 10:17:06 it uses INSTALLROOT Dec 07 10:17:26 so I am confused why this is not working Dec 07 10:18:23 I tried that, but it will also automatically creates "fragments" directory in /tmp/work-shared/test/kernel-source/.meta/cfg/ and then bitbake ends with "ERROR: could not sanitize configuration fragments" during do_kernel_configme Dec 07 10:23:21 hmmm Dec 07 10:23:55 ondra__: http://www.yoctoproject.org/docs/1.7/mega-manual/mega-manual.html#var-SRC_URI Dec 07 10:24:02 you could try subdir Dec 07 10:30:34 Hi, how to maintain configuration of the given custom image ? Is the only way to store in the repository bblayers.conf and local.conf files ? I think toaster could be convinient for that, however it's measing an option to dump the configuration file (*.json) which later could be restored on another build machine. What is the common way to solve it ? Dec 07 10:31:40 eduardas_m: guess: did you mean to use the ${STAGING_INCDIR} ? Dec 07 10:32:47 adrianf0: split it into the things that are DISTRO related, MACHINE related and IMAGE related, then create a custom distro, machine and image for your use case, and pack those up in a layer. Dec 07 10:48:24 LetoThe2nd: Thank you. I understand I can create my custom distro, which will use a specific machine and packages, right ? Having such a custom distro, is there any common way to automatically add the dependency layers into conf/bblayers.conf and set (if needed) conf/ layer.conf ? Usually, such custom distro would come with some script which would perform that ? Is there any convention for name and location of such script ? Dec 07 10:51:24 adrianf0: hm, close. distro and machine should be orthogonal, so the distro should contain things that define your ABI. the machine, on the other hand, should contain the things that make everything work on your particular hardware. Dec 07 10:52:49 adrianf0: and automated creation of local.conf/bblayers.conf for a given defined target is subject of many discussions these days. many people use repo in some form, you might want to look at the layers for fresscale/imx which do serve as a nice example. Dec 07 11:09:01 graphiqs, thanks a lot for the reply... its is now clear to me I was doing something really stupid Dec 07 11:09:08 oe_runmake install INSTALL_ROOT=${D} actually works Dec 07 11:09:14 LetoThe2nd: Did you mean meta-resin-fsl-arm layer ? Others from freescale are only BSP. Dec 07 11:09:41 the thing was that the makefile for qwt requires INSTALL_ROOT and not INSTALLROOT Dec 07 11:09:50 I was one symbol short Dec 07 11:10:34 not sure what ${STAGING_INCDIR} does Dec 07 11:29:31 rburton: d'oh, thx! Dec 07 11:36:25 rburton: hm, that does add ccache, but it removes everything previously in INHERIT - not even those added with INHERIT+= (rm_work and the like) but also package_ipk, sstate, etc Dec 07 11:39:18 and INHERIT_pn-linux-yocto += "${INHERIT} ccache" is seen as a self-reference Dec 07 12:10:46 Does anybody here work with: https://github.com/rust-embedded/meta-rust-bin Dec 07 12:51:22 yann: += "ccache" Dec 07 12:51:34 erm, _append = " ccache", even Dec 07 13:06:39 I would like to ask something: what are you more inclined to use: chromium with javascript frameworks for embedded platforms or native qt solutions? Dec 07 13:07:19 because I get the impression people are often using chromium with javascript for embedded even though it might be overkill for the application itself Dec 07 13:08:16 I understand people want to leverage the abundance of available web developers and web frameworks Dec 07 13:08:42 but sometimes there are usecases where power consumption is an issue on handheld devices Dec 07 13:08:54 eduardas_m: maybe even for embedded people are not so much worried about performance and are more worried about how many programmers I will have that can program in this language Dec 07 13:08:55 and you can not afford a GPU and OpenGL Dec 07 13:09:13 eduardas_m: (exactly) Dec 07 13:11:23 falk0n, I get all that, but I have no grasp of the ratio here... how niche are handheld devices that do everything with qt5 and linuxfb for example? Dec 07 13:12:04 because when I talk to people I get the impression I am the only one trying to do things without a GPU Dec 07 13:12:14 which can not be true Dec 07 13:13:29 lots of boards have no gpu but lots also have very capable gpus Dec 07 13:13:50 if you don't have a capable gpu then you'll need to ensure you pick software that doesn't expect GLES etc Dec 07 13:15:06 maybe its not only you but, sometimes does decisions come from above (bosses) and for them that the amount of human resources is more important than performance Dec 07 13:15:20 rburton, I was asked to try and do things with imx6UL without a GPU because of power requirements... Dec 07 13:15:37 we want a handheld device to last for long in the field Dec 07 13:17:05 does anyone have a recommendation for a plotting solution that handles lots of points efficiently without OpenGL requirements? Dec 07 13:17:42 and preferably has a well-maintained recipe on the OE index? Dec 07 13:18:18 gtk? cairo directly? Dec 07 13:18:26 qt5 doesn't need gl for everything Dec 07 13:18:49 rburton, I am aware of that... it satisfies most of my needs Dec 07 13:19:25 actually, I have just finished debugging my qwt recipe that now builds with qt5 linuxfb Dec 07 13:19:51 now I need to make my qt5 SDK use it somehow Dec 07 13:21:18 rburton, they both work directly with framebuffer? how many people actually implement their plotting this way? I guess not that many... Dec 07 13:21:48 eduardas_m: we for example are rendering directly to a DRM plane Dec 07 13:23:07 eduardas_m: And here we use a wayland/ weston window manager with a gtk3 app. Dec 07 13:23:22 eduardas_m: both on x11 on a framebuffer Dec 07 13:23:25 LetoThe2nd, is that fundamentally different from how linuxfb works on qt5? Dec 07 13:23:31 nobody bothered to maintain gtk3 on directfb Dec 07 13:23:40 (or wayland) Dec 07 13:23:42 eduardas_m: um yes? no qt involved? Dec 07 13:24:28 I am not familiar with DRM... that confused me a bit Dec 07 13:25:58 DRM plane is the same thing as fb device, no? Dec 07 13:26:53 roughly, yes. Dec 07 13:27:48 zzeroo, do you do any serious plotting in the gtk3 app? Dec 07 13:30:31 It depends what you mean with serious plotting. Here we have a gas detection systemd where wo draw a user interface with some graphs. No 3d acceleration or something like that needed. Dec 07 13:31:43 s/systemd/system >< But the system is with systemd, wayland, weston and gtk3. Nothing else ^^ Dec 07 13:31:57 wait, wayland/weston builds without OpenGL just like x11 does, no? Dec 07 13:32:08 I have a working yocto build with matchbox for raspberry pi 2. I wanted to trim it down a little, but now I get "QA Issue: glibc-locale: Files/directories were installed but not shipped in any package" all the time. Dec 07 13:32:49 also after deleting tmp, sstate-cache etc. Dec 07 13:33:55 viengelm: Include the files in FILES http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-FILES Dec 07 13:34:08 zzeroo, by serious plotting I mean like 600 000 points with zoom in capability Dec 07 13:34:32 eduardas_m: No I haven't :) Dec 07 13:36:23 zzeroo: I'd rather not include them (as I said, I am trying to trim it down)... I'm mostly wondering how/why they get where they are when they aren't included then. Why would a recipe do such a thing? Dec 07 13:36:37 zzeroo, since you're using systemd, what are your motivations for using it? I am also building my distro with it Dec 07 13:37:09 it would be interesting to hear what other people think of systemd on embedded Dec 07 13:38:05 any common problems with it for embedded applications? Dec 07 13:39:25 my motivation is basically just to make my machine more accessable to developers who are used to desktop and server distros (that usually involve systemd) Dec 07 13:39:26 eduardas_m: It's more modern, faster and I have to formulate some dependencies in startup which I could only under systemd get running so fine. I like systemd and I use it heavy in all my projects. Dec 07 13:40:01 eduardas_m: wayland itself depends on very little but weston needs opengl Dec 07 13:40:55 jku, wayland is unusable without weston, no? Dec 07 13:41:11 I am absolutely not familiar with this Dec 07 13:41:39 eduardas_m: in the sense that weston is the only compositor shipped with yocto Dec 07 13:42:21 I'm guessing the other compositors require opengl as well... Dec 07 13:42:33 i *think* there are ways to run weston without GL now Dec 07 13:44:15 interesting Dec 07 13:46:45 thank you for the information, everyone... this has been very educational Dec 07 13:46:56 eduardas_m: I use systemd on deep-embedded a lot Dec 07 13:47:04 and, honestly, it's pretty good Dec 07 13:48:32 one of the pb we have with systemV in general is robustness. not sso much that systemV crashes, it's pretty solid nowdays, but it's almost impossible to have a system that properly reacts to network down and back up, various timmeouts, USB plug and unplug, wifi coming and going Dec 07 13:48:54 all that in shell scripts as systemV more or less forces you to do Dec 07 13:49:07 so systemd's system is a great way to save some sanity Dec 07 13:49:56 stuff like socket activation, timer activation, dependencies on device units, watchdog on services are awesome, but just the fact that it can properly stop and restart services is already a major selling point Dec 07 13:54:27 boucman_work1, yes...those are the same features that I also find attractive when I read systemd documentation Dec 07 13:55:33 the big downside of systemd is mainly (convincing your devs to) relearn how to do stuff Dec 07 13:55:35 boucman_work1: Full Ack, not to forget the log abilities Dec 07 13:55:55 zzeroo: agreed, but technically that's not systemd, it's journald :P Dec 07 13:56:16 and if we talk about the whole systemd galaxy, i'd like to sell d-bus, which is pretty awesome too Dec 07 13:56:23 boucman_work1: ^^ Dec 07 13:57:20 * boucman_work1 has discovered bustle, to make sequence diagrams out of d-bus... and then include them directly into the customer documentation Dec 07 13:57:31 next to the SVG with the whole boot process decomposed :) Dec 07 13:58:02 well, you can have d-bus without systemd Dec 07 13:58:57 and I think there is a separate bootchard tool outside of systemd that does similar stuff Dec 07 13:59:12 but yes, integration is very nice Dec 07 14:08:06 eduardas_m: I think the other bootchartd is about measuring the boot time of the kernel, not of userspace (but I may be wrong) Dec 07 14:09:48 the systemd bootchart is a clear evolution of the standalone one Dec 07 14:09:59 using the improved data you can get when in systemd Dec 07 14:14:38 * graphiqs compiles a image with systemd Dec 07 14:16:27 boucman_work1, I was talking about bootchart 2 by Michael Meeks Dec 07 14:16:34 and it does userspace too Dec 07 14:16:40 as far as I can tell Dec 07 14:16:49 and there's also an OE recipe Dec 07 14:17:06 haven't tried it myself though Dec 07 14:19:40 havn't used that forr a long time, I have to admit... Dec 07 14:31:05 Hi Dec 07 14:31:30 are there any OS other than Linux that Yocto supports? or that exists? Dec 07 14:36:25 vapula: do you mean running an openembedded/poky build *ON* something other than linux, or *producing* something other than linux? Dec 07 14:36:53 vapula: the former is kind-of supported through the CROPS project which utilizes docker containers, the later not at all. Dec 07 14:36:56 producing something other than linux Dec 07 14:37:23 say, freertos, qnx, or something else Dec 07 14:37:53 nope, i've never heard of such a thing. Dec 07 14:39:16 it's interesting that the Yocto material (code and docs) are totally generic, yet only Linux is supported as generation target Dec 07 14:39:45 vapula: i'd say that the code is all but generic Dec 07 14:40:31 as it has extensive special cases and infrastructure for the linux kernel Dec 07 14:41:57 Hi, does anyone know if is possible to use 2 kmeta repos and have reference/include scc file from a repo to other? For example to create a new bsp(new kmeta repo) but include standard ktype,... Dec 07 14:41:58 vapula: plus, always remember that yocto is (only) an umbrella project and you are most likely referring to the openembedded build system, respectively the poky distribution that uses it. Dec 07 14:42:35 LetoThe2nd: sure, but actually is OpenEmbedded also Linux-specific? Couldn't you have a FreeBSD OE? Dec 07 14:44:18 vapula: anything I just said holds especially true for OE. but of course, its only software. i don't think its impossible to add freebsd or minix as kernels, it just is not there at the moment. and i'd say that its fairly advanced to go for that. Dec 07 14:57:03 isn't zephyr compiled using OE ? Dec 07 14:57:21 abelloni: the sdk is built using OE Dec 07 14:58:02 basically its just baking 4 or 5 toolchains for different architectures, bundling them up, done. Dec 07 14:58:23 ok :) Dec 07 14:59:15 AFAIK zephyr itself uses the Kbuild/Kconfig style Dec 07 15:01:00 adca: you can, for an example have a look at how the meta-xilinx layer which uses multiple kmeta to support linux-yocto and linux-xlnx with a common BSP config repo (http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-xilinx-configs.inc) Dec 07 15:09:14 nrossi: thanks, I will have alook! for some reason config.queue is empty when I include from newbsp.scc the standard.scc(from yocto-kernel-cache). Dec 07 15:13:43 adca: there are some rules about how the kmeta stuff picks up the root .scc, so make sure its doing that. The config.queue, meta-series, etc files should help debugging though. Dec 07 15:59:01 hello gusy, could somebody help me with do_rootfs function failure: http://ix.io/1KKM ? Dec 07 16:06:04 how do I make the files of an additional package appear in the meta-toolchain-qt5 sysroot? Dec 07 16:06:43 for example, by qwt recipe builds packages libqwt-dev and libqwt-features Dec 07 16:07:07 I bbappend my qwt-qt5 recipe to meta-toolchain-qt5 Dec 07 16:07:08 i've no idea why meta-qt5 has its own toolchain stuff, but bitbake myimage -c populate_sdk will generate a toolchain for your image Dec 07 16:07:25 so if myimage has qwt in, your toolchain has qwt-dev Dec 07 16:07:36 rburton, without a qmake for cross-compilation IIRC Dec 07 16:07:59 if you want to install this packages on the host sysroot, set the TOOLCHAIN_HOST_TASK with the packages you want Dec 07 16:08:01 TOOLCHAIN_HOST_TASKS += nativesdk-qmae? Dec 07 16:08:16 (add the k) Dec 07 16:09:44 igor1, rburton thank you, will look into it Dec 07 16:12:39 so I need basically three text files I need to ship with the libqwt-dev package that are not packaged with it automatically Dec 07 16:13:18 how can I force bitbake to add them to this package during do_package? Dec 07 16:14:22 bbappend libqwt appending do_install task and FILES_${PN}-dev Dec 07 16:14:37 with the files you want Dec 07 16:15:28 igor1, thanks Dec 07 16:15:36 np Dec 07 16:41:36 I expected that stuff I added to the libqwt-dev package via FILES_${PN}-dev += " usr/features " to be present on the sysroot the SDK installs Dec 07 16:41:44 but its not there Dec 07 16:42:36 it is present in the package itself as I have checked Dec 07 16:43:38 I naively expected meta-toolchain-qt5 to take everything that package has Dec 07 16:55:30 I’m looking for abd and fastboot executables for yocto on Intel Edison? Is there anything available out there? Dec 07 16:56:41 eduardas_m: did you see the nativesdk-libqwt-dev or libqwt-dev? Dec 07 16:56:51 on the sdk, you installs nativesdk-packages Dec 07 16:59:04 igor1, interesting information, thank you Dec 07 16:59:13 will investigate tomorrow Dec 07 17:01:53 rburton: _append = " ccache" also ends up with just INHERIT = " ccache" according to "bb show" - and so does _append += " ccache" (which I'm not sure makes any sense at all anyway, tried just in case ;) Dec 07 17:02:46 INHERIT_append_pn-[recipename] = " ccache" Dec 07 17:10:18 Hmm, anyone played much with x32 builds? have a pile of local fixes, and still a couple failures remaining Dec 07 17:10:40 oh yay Dec 07 17:10:50 i filed a bug just last week saying "world doesn't work" Dec 07 17:11:30 kergoth: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10697 Dec 07 17:11:31 Bug 10697: normal, Medium, 2.3 M2, saul.wold, NEW , x32 world build fails badly Dec 07 19:07:08 hello, i'm having a gcc_runtime build error with Jethro. https://expirebox.com/download/9f5090b8452ea0c54ca153f98f5461a8.html Dec 07 19:07:14 anyone able to have a look? Dec 07 19:08:51 build config: http://pastebin.com/e3EXyNzd Dec 07 19:08:53 is that the compile log from a single packkage ? Dec 07 19:09:52 yeah, gcc-runtime_5.2.bb Dec 07 19:41:32 problem solved. I'm compiling the agl distro, and they have a workaround for an issue with rust, this workaround was causing the issue Dec 07 19:41:38 https://wiki.automotivelinux.org/agl-distro/source-code Dec 07 22:10:25 Hi! Has anybody worked with the meta-web-kiosk layer? I'm having issues with the webkitgkt compilation... Dec 07 22:48:34 halstead: Are you around? Dec 07 22:49:36 lamego I'm online but not totally available at the moment. Dec 07 22:50:29 halstead: Got it. Please take a look at my latest email when you have the time. thx Dec 07 22:52:27 lamego I will check those 3 things and get back to you. Dec 07 23:32:22 does BBMASK prevent parsing a recipe, or just remove it after the fact? Dec 08 00:13:47 mattsm: the former, it prevents parsing it entirely Dec 08 00:14:03 kergoth I must be messing it up then, because it's still parsing.. will keep debugging Dec 08 00:14:07 it's really the only way to work around something that won't parse without modifying the layer Dec 08 00:14:16 most likely your regex doesn't match the absolute path to the recipe Dec 08 01:39:02 I think the whitelist class from ostro is quite useful Dec 08 01:40:38 kergoth: do you know if we have qmake for target recipe ? **** ENDING LOGGING AT Thu Dec 08 03:00:01 2016