**** BEGIN LOGGING AT Fri Aug 22 02:59:59 2014 Aug 22 06:20:16 good morning Aug 22 07:48:28 good morning Aug 22 08:13:29 good morgen Aug 22 08:14:07 I do not get it ... http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/core-image-minimal-mtdutils.bb#n7 -> the manual says to use _append rather than +=, so why is oe-core not following the manual therein? Aug 22 08:18:56 hello, what is best tutorial to study creating recipe ? Aug 22 08:20:54 jooncheol: I would read this, http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-recipes Aug 22 08:21:34 thanks! Aug 22 08:21:44 is there any useful pkg repository tool and server such as yum, apt, zypper ? Aug 22 08:22:59 or does anyone use scratchbox or qemu to build something difficult to x-compile for yocto environment ? Aug 22 08:27:15 morning all Aug 22 08:32:43 morning~ Aug 22 08:36:55 jooncheol: Yocto supports deb, rpm and ipk. Aug 22 08:37:10 and bitbake is doing the building. Aug 22 08:37:24 you can use this for existing recipes and layers: http://layers.openembedded.org/layerindex/branch/master/layers/ Aug 22 08:38:20 bluelightning: why is it += rather than _append = " foo" as per manual? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/core-image-minimal-mtdutils.bb#n7 Aug 22 08:40:05 lpapp: because here we are inside a recipe vs local.conf Aug 22 08:40:39 aside from any hypothetical bbappends there are no lines to be parsed after this that might touch IMAGE_INSTALL, so += is fine Aug 22 08:40:57 bluelightning: that is not what the manual says. Aug 22 08:41:01 (well, rather than "touch", "set it outright") Aug 22 08:41:18 the manual is trying to make a general recommendation that will always work, that doesn't mean you can never use += Aug 22 08:41:29 bluelightning: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_INSTALL Aug 22 08:41:38 yes, I know, I helped write that section... Aug 22 08:41:51 please read it again; it is confusing. Aug 22 08:42:04 "Furthermore, the same operation from within an image recipe may or may not succeed depending on the specific situation." -> that is very ambiguous Aug 22 08:42:09 what situation? Aug 22 08:47:20 well, at least it is confusing to me because I do not get what situation it is referring to. Aug 22 08:48:43 lpapp, thanks! Aug 22 08:49:12 one more question, what does "-native" mean ? Aug 22 08:49:30 when I do 'bitbake -s', there's xxx and xxx-native Aug 22 08:49:40 e.g - pkgconfig, pkgconfig-native Aug 22 08:50:11 is "xxxx-native" for cross compile env ?? Aug 22 08:52:25 jooncheol: -native is the same arch as your host, not necessarily like the target Aug 22 08:52:39 in other words, xxx is meant for being used on the target, whereas xxx-native on the host. Aug 22 08:53:21 so, if there's xxx-native, xxx pkg could be used for cross compile in the host. right ? Aug 22 08:54:01 yes, xxx is cross-compiled on the host for the target. Aug 22 08:54:32 IMHO the whole -native idea should be hidden and internal details, but that is not a discussion for today... :-) Aug 22 08:54:39 (it just confuses users needlessly) Aug 22 08:54:47 thanks ! Aug 22 08:55:32 actually, I wanted to build qt5.3.1 for freescale imx6 target Aug 22 08:55:40 maxin: ping Aug 22 08:56:27 i found the qt-4.8 but I couldn't find the recipe for 5.x. but I just found it on github. Aug 22 08:56:49 but I need to study more, I don't know how to import it on my env yet. ^^ Aug 22 08:57:27 and I wonder whether it can be used or not ... Aug 22 08:58:43 since I don't know BB yet, I'm trying to build qt5 on the qemu chroot env. Aug 22 09:01:42 lpapp, what about nativesdk-xxx ? Aug 22 09:01:59 I found libxcb and nativesdk-libxcb. Aug 22 09:03:09 what it does not follow the rule of xxx/xxx-native ? Is there something different concept ? Aug 22 09:08:53 lpapp: pong .. Aug 22 09:10:33 maxin: sorry, unping now. Aug 22 09:11:04 lpapp: ok :) Aug 22 09:21:15 maxin: well, reping, my ptest package is not generated. :-( Aug 22 09:22:57 lpapp: was working with some other tasks.. sorry that I didn't get time to look into that.. Aug 22 09:23:45 maxin: no, I mean I just modified my recipe (inherit ptest, added ptest install function and run-ptest), but I am not seeing foo-ptest generated. Aug 22 09:25:10 maxin: should I see it after bitbake foo or even bitbake foo-core-image-dbg? Aug 22 09:25:15 lpapp: have you set DISTRO_FEATURES= "ptest" and IMAGE_FEATURES_append = " ptest-pkgs" Aug 22 09:25:37 yes Aug 22 09:26:21 lpapp: ok, can you share the name of the recipe.. or your modifications.. Aug 22 09:28:44 maxin: well, no, actually that is not what I used. I used what the manual said, namely: DISTRO_FEATURES_append = " ptest" Aug 22 09:28:47 EXTRA_IMAGE_FEATURES = "ptest-pkgs" Aug 22 09:28:52 I put this into the dbg image recipe. Aug 22 09:29:13 (since ptest should be always present for the debug image) Aug 22 09:29:19 lpapp: please set IMAGE_FEATURES_append = " ptest-pkgs" in local.conf Aug 22 09:30:23 no, that will be global or local, that is not acceptable behavior for us. Aug 22 09:31:04 that is different to what I am trying to achieve. I want to get ptest packages for my debug image, only. Aug 22 09:32:59 I could put the distro features into the distro config, however, I believe. Aug 22 09:33:06 but the image feature should go into the specific image. Aug 22 09:33:28 lpapp: yes.. Aug 22 09:34:54 anyway, the ptest package is not generated for my recipe :( Aug 22 09:34:56 why is that? Aug 22 09:35:42 maxin: this is my ptest install function in the recipe, do_install_ptest () { cp ${S}/foo/mytest.sh ${D}${PTEST_PATH}/ } Aug 22 09:37:31 lpapp: this part looks ok.. Aug 22 09:38:25 maxin: then I added this to the SRC_URI: file://run-ptest" Aug 22 09:42:26 maxin: and run-ptest says this, http://paste.kde.org/pfdfcfggl Aug 22 10:18:19 maxin: was ptest working properly in dylan? Aug 22 10:18:38 I do not mean the individual ptest additions for many recipes, but the bulk stuff in the core. Aug 22 10:22:55 maxin: I am getting the foo-ptest package now, but it only contains the run script, not the actual test script itself, so it will not work. Aug 22 10:32:45 maxin: this is in the do_install_ptest_base log: /home/lpapp/Projects/polatis/Yocto/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/foo-git/AUTOINC+0373d08fcd19348aae58bc76bce031d7471b76b2-r0/temp/run.do_install_ptest_base.32556: 84: [: a-t:: unexpected operator Aug 22 10:53:45 maxin: if [ a$(type -t do_install_ptest) = afunction ]; then -> this is the 84th line. Aug 22 10:54:56 maxin: is it some issue that is fixed post-dylan? Aug 22 10:57:36 lpapp: was out for lunch.. Aug 22 10:59:52 maxin: got a clue? Aug 22 11:00:06 seems the Yocto generated stuff is broken. Aug 22 11:09:21 lpapp: do_install_ptest_base is present in meta/classes/ptest.bbclass. Have you tried to debug it from there ? Aug 22 11:11:00 maxin: nope, I have no idea how this code works, sorry.... got a clue though what to put in there? Aug 22 11:11:09 maxin: anyhow, what is wrong about the shell line? Aug 22 11:11:14 type is empty or what? Aug 22 11:21:08 lpapp: the bug that you see was one of the corner cases in ptest at that time.. It is fixed in master .. Could you try the latest version.. Aug 22 11:21:19 maxin: no Aug 22 11:21:39 please show me the change and I will try to integrate it or even better, is there any workaround? Aug 22 11:21:51 well, it is not such a corner case... it always appears with stock manual copy/paste. Aug 22 11:24:58 lpapp: the problem happened if you didn't have do_install_ptest defined (type will return an empty string, which make the test fail). The function is defined in ptest.bbclass, but only if you have ptest in DISTRO_FEATURES Aug 22 11:26:53 joseppc: I have ptest in the DISTRO_FEATURES. Aug 22 11:28:09 joseppc: bitbake nic-git -e | grep ^DISTRO_FEATURES | grep ptest -> works as expected, so that is not my case. Aug 22 11:28:15 in which other cases was it still an issue? Aug 22 11:30:30 lpapp: ok, I was just commenting the reason behind that change in the line you mentioned above Aug 22 11:30:49 joseppc: so it must be something else then, I guess... Aug 22 11:36:04 lpapp: most likely, and if you have ptest in DISTRO_FEATURES, and ptest-pkgs in EXTRA_IMAGE_FEATURES, then I don't know, sorry Aug 22 11:36:35 joseppc: perhaps it is an irrelevant old log? Aug 22 11:36:46 hmm, no, it is relevant Aug 22 11:36:54 the ptest package is created, but not with the content in that function. Aug 22 11:36:59 yeah, I am running out of ideas, too ... :( Aug 22 11:39:51 joseppc: which is the change anyway? I could give it a try. Aug 22 11:41:20 joseppc: maxin dbus ptest failed :( Aug 22 11:41:28 this stuff seems to be very unstable in dylan, sadly. Aug 22 11:42:52 joseppc: maxin http://paste.kde.org/pu1raahea Aug 22 11:43:24 lpapp: those changes were introduced in 44120a0, if that's what you're referring to Aug 22 11:45:19 I will leave ptest for now, I guess. Aug 22 11:45:43 it is too broken in dylan for the basics. I think we will need to get back to it when we update Yocto in 1-2 years maybe. Aug 22 11:46:01 (hopefully that will not be broken) Aug 22 11:46:28 what bugs me is that I can reproduce this with just enabling ptest, so this feature seems to have never been really tested with clean stuff. Can such commits even go to Yocto? :( Aug 22 11:53:12 I think the workaround for now is to do the copy in do_install Aug 22 11:53:46 or is there any better workaround? Aug 22 12:00:39 joseppc: maxin do you know if I remove the EXTRA_IMAGE_FEATURES = "ptest-pkgs" line from my image recipe, it should disable ptest completely for the image generation? Aug 22 12:00:56 because I tried to do that, but I am still getting the ptest error for dbus. Aug 22 12:01:10 I am OK with getting the ptest only for my package now by bitbake foo-git. Aug 22 12:01:32 but I would like to able to still keep building the dbg image properly without ptests in it since it is broken. Aug 22 12:04:18 lpapp: dbus recipe had ptest related bug and it was fixed before.. Please use ptest implementation from master.. Aug 22 12:04:58 maxin: as I said already, I cannot, we use dylan. It is not like we can update the whole Software Stack just because one little thing is fixed there. Aug 22 12:05:10 updating a full software stack is a HUGE and RISKY undertake. Aug 22 12:05:37 I am disappointed that Yocto accept fully untested commits :( Aug 22 12:05:41 accepts* Aug 22 12:05:56 lpapp: I understand your concern. Please backport those fixes. Aug 22 12:06:16 no, I will not mess up with the core foundation of the software stack. I will take that risk. Aug 22 12:06:23 I will work it around in the high layers. Aug 22 12:06:41 will not take* Aug 22 12:06:58 see, committing an untested change can have serious consequences, like this. Aug 22 12:07:21 I will read upon the QA reports how Dylan was tested. Aug 22 12:09:07 cause hopefully at least I will know what not to rely on ... Aug 22 12:13:37 having said that, I do not even know a workaround for this... it is just so fundamentally b0rked :( Aug 22 12:13:51 I cannot get bitbake foo-git working without the distro features, but with that, the image will not build. Aug 22 12:13:58 * lpapp clears ptest from memory Aug 22 12:19:13 lpapp: afair runtime testing was expected to work on 1.5+ Aug 22 12:19:25 http://events.linuxfoundation.org/sites/events/files/slides/Keeping%20it%20Green.pdf Aug 22 12:19:38 tbh I never used that Aug 22 12:20:09 ant_work: dylan is 1.4 Aug 22 12:20:25 why do you insist then ? ;) Aug 22 12:20:27 why was it put in there untested? This thing worries me because I lose the confidence... perhaps other things are also pushed untested? Aug 22 12:20:46 ant_work: I am not insisting at all; if you read above, you can see I rm -rf'd the idea. Aug 22 12:20:57 people were insisting that I should use it because it is so cool. Aug 22 12:21:09 I gave them half of my day wasted to see that I consider it. Aug 22 12:23:16 ant_work: the last thing I will try is pretty much this, and if that does not work either, I will completely give it up: Aug 22 12:25:50 in do_install () { ... }: http://paste.kde.org/pfxoeppam Aug 22 12:26:42 and I will try to install ptest-runner, but I will not use ptest.bbclass for now. Aug 22 12:35:47 can I call a recipe function from another recipe function in the same recipe, e.g. to create a do_install_ptest that I call from do_install? Aug 22 12:35:57 so that when we get the latest Yocto, it will be as smooth transient as possible? Aug 22 12:44:41 meh, really? inherit useradd # ptest Aug 22 12:44:46 that is a syntax error for bitbake, why?! Aug 22 12:44:54 # ought to be a comment, no? Aug 22 12:47:16 just for the record, I cloned dylan and build an image with ptests enabled. It worked flawlessly Aug 22 12:47:39 cloned != released Aug 22 12:47:46 (well, not necessarily) Aug 22 12:48:07 try 9.0.1 and you might se... Aug 22 12:48:07 e Aug 22 12:49:41 preferred is to clone with git: https://www.yoctoproject.org/downloads/core/dylan143 Aug 22 12:51:13 like I said before several times, it is easy to say without seeing end user products. Aug 22 12:51:27 you cannot just clone forth and back and expect full reliability for a very serious and critical product. Aug 22 12:51:36 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6645 Aug 22 12:51:38 Bug 6645: normal, Undecided, ---, richard.purdie, NEW , Bitbake does not accept # (comments) in the inherit line Aug 22 12:52:09 lpapp: normally end products will not contain test suites (in my experience) Aug 22 12:52:54 maxin: yeah, sure, you will not test serious and critical products ... :-) Aug 22 12:53:19 or "better" (being sarcastic here): you will use a completely different environment for testing than the actual product... :-) Aug 22 12:53:22 lpapp: will test the products.. but will not release a debug image for the prduct Aug 22 12:53:30 product Aug 22 12:53:33 you do not get it. Aug 22 12:53:43 even the debug image relies on a _stable_ system. Aug 22 12:54:02 you will not use a completely difference release or even bleeding edge for testing, when you test a reliable product. Aug 22 12:54:12 you really need to see how Yocto is used in certain environments :) Aug 22 12:55:11 lpapp: depends on your test strategy, it can vary.. Aug 22 12:55:17 when I was younger and hacking all the time, I also thought bleeding edge is always the coolest thing ever, but sometimes you need to cover your food, aka. get things done. Aug 22 12:56:13 lpapp: agree on that. still, bleeding edge is considered as the "latest and greatest" Aug 22 12:56:24 in YOUR mind. Aug 22 12:57:15 where stability, reliability and robustness are the leading factors, not "latest and greatest" (in fact that is the opposite of the previous traits), you behave differently. Aug 22 12:57:58 we are not Intel or any other company for that matter where wasting a few weeks for "interesting" stuff is acceptable. Aug 22 13:02:37 maxin: in other words, we can do better than ptest.bbclass and other ptest features except ptest-runner did in Dylan. Aug 22 13:04:00 lpapp: I agree that ptest is the panacea for all our testing problems.. Please suggest fixes or improvements or even better, send patches.. Aug 22 13:04:28 maxin: why would I send patches? Aug 22 13:04:36 when I do not wish to update the core stack? That does not make any sense. Aug 22 13:04:46 but one suggestion: please do eliminate the need for ptest-runner in each image ... Aug 22 13:04:56 ptest.bbclass should take care of it in the first place. Aug 22 13:05:16 it should set the dependency basically, which should pull ptest-runner in automatically. Aug 22 13:05:21 lpapp: the same reason why you would send the patches before :) Aug 22 13:05:37 maxin: I think you do not get it. Aug 22 13:05:55 maxin: I am not evaluating the latest. It might be working, I do not know. I am not in a position for the next 1-2 years to know. Aug 22 13:06:15 what I see is that ptest was integrated into dylan and it is terribly broken. :( Aug 22 13:06:26 I will solve that it my way in our project now. Aug 22 13:06:43 that my way* Aug 22 13:08:53 in fact, I would strongly suggest to remove ptest altogether from the dylan documentation, at least 9.0.1 Aug 22 13:08:59 cause it says it works which is wrong. Aug 22 13:09:21 except that it works Aug 22 13:10:55 yes, I am a big liar. Aug 22 13:11:15 no, I guess I am Aug 22 13:11:26 sigh Aug 22 13:11:55 git clone from the latest != 9.0.1 Aug 22 13:12:01 if you claim that, yes, you are a liar. Aug 22 13:12:32 any decent documentation includes a "since" tag for features when they were introduced. Aug 22 13:12:50 for exactly this very reason, others cannot misled you to try it and waste half a day or more Aug 22 13:12:56 or the documentation does not misled you ... Aug 22 13:13:03 it is not really rocket science, but generic practice. Aug 22 13:13:27 I have tried this issue on three different machines now (all "supported" OSes, etc), and it works nowhere with 9.0.1 Aug 22 13:18:07 if it _really_ works, the documentation needs to be extended what steps are needed to get it work. Aug 22 13:24:59 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6646 Aug 22 13:25:01 Bug 6646: normal, Undecided, ---, richard.purdie, NEW , Implement rm_old_work Aug 22 13:41:26 hmm, why does ptest-runner always return zero (success) even when run-ptest failes (returning with 1)? Aug 22 13:41:36 should it somehow indicate that it failed at some test? Aug 22 13:47:34 not really, what's useful is the output of ptest-runner, : Aug 22 13:48:39 not really, no. Aug 22 13:48:58 for me, the single most important thing is to know whether it succeeds, so Jenkins can report it as success or failure. Aug 22 13:49:28 I definitely do not want to parse output in Jenkins... if this script cannot be extended to handle that, I have no desire to use it. Aug 22 13:50:02 then you can pipe the script and grep for FAIL or something... Aug 22 13:50:16 I do not really see why I would. Aug 22 13:50:17 for most people it's important to know what tests failed, not that some tests failed Aug 22 13:50:26 you sure joke Aug 22 13:50:32 in CI, you would like to know any failure. Aug 22 13:50:44 if anything fails, report it to the corresponding developers. Aug 22 13:50:45 my point exactly Aug 22 13:51:07 which means return the failure code (whatever that is), and Jenkins can easily now. Aug 22 13:51:10 know* Aug 22 13:51:28 and then the developer gets an email obviously, and can have a detailed look at the log. Aug 22 13:52:34 this should do it: http://paste.kde.org/p4tgxkgw7 Aug 22 13:56:48 I agree with lpapp Aug 22 13:57:00 s/return/exit/ Aug 22 13:57:29 or even add 1 for each failed test and use number of failed tests as return value Aug 22 13:58:26 you might need to convince "make check" to do that too... but maybe it already does? Aug 22 13:59:52 that is a different problem :) Aug 22 14:00:17 JaMa: no, I would rather prefer FAILED/ALL instead of that. Aug 22 14:00:31 so that the exit code remains reliable, not something constantly changing. Aug 22 15:01:18 would it be acceptable to add CCACHE_PATH to the environment setup script when someone installs the SDK? Aug 22 15:01:32 currently, ccache does not like my Yocto SDK since that does not touch CCACHE_PATH, only path. Aug 22 17:20:49 Shouldn't lsb rdepend on lsbinitscripts? lsb's lsb_log_message file contains code that seems to relie on functions that are not defined anywhere in the files installed by the lsb package, as far as I can see. Those funcions seem to be defined by lsbinitscripts' functions file. Am I missing something? Aug 22 17:55:57 Hey everybody Aug 22 17:56:02 Can anyone help me with something? Aug 22 17:57:38 theguy: ask Aug 22 17:59:20 My LCD is shutting off after 15 minutes, and I've tried everything but can't seem to stop it Aug 22 18:00:27 Here's what I've tried: Aug 22 18:00:33 passing consoleblank=0 to bootargs Aug 22 18:00:38 modifying drivers/tty/vt/vt.c with static int blankinterval = 0; Aug 22 18:00:43 echo -e -n '\033[9]' > /dev/tty0 Aug 22 18:00:48 echo 0 > /sys/class/graphics/fb0/blank Aug 22 18:00:53 echo 0 > /sys/class/vtconsole/vtcon1/bind Aug 22 18:01:11 Those commands were all run in a startup script as root. Nothing is working! Aug 22 18:02:46 If I run cat /sys/module/kernel/parameters/consoleblank I always get a value of 900 Aug 22 19:01:21 anyone know how the populate_sdk/meta-toolchain stuff supports builds of out-of-tree kernel modules if you ship kernel-dev in the sdk? do we rely on the user who installed the sdk going into usr/src/kernel and running make scripts? Aug 22 19:03:37 trying to ship prebuilt binary stuff in there would be a giant pain in the ass, is why i ask.. Aug 22 19:11:06 kergoth: I have filed an enhancement request for it Aug 22 19:11:45 yes we do not really prepare the source tree for cross-build we do so for target build Aug 22 19:12:03 so if you build modules with on device SDK it will work Aug 22 19:12:23 but on cross SDK story is not complete yet Aug 22 19:13:02 cross is the one i'm most concerned with. easing the lives of the application/kernel developer who doesn't want to care about bitbake is a good thing Aug 22 19:13:13 nod Aug 22 19:13:18 me too Aug 22 19:13:43 we're shipping something similar to the yocto sdk but as p2 artifacts that install directly into eclipse/codebench, populating an sdk in its install Aug 22 19:13:51 or rather, we let the user use bitbake to build such a thing Aug 22 19:14:03 but then somebody has to run make scripts somewhere :) Aug 22 19:18:31 I guess you'd have to create a nativesdk extend of the kernel, which grabs the sources and runs make scripts using the toolchain for the SDKMACHINE and wraps that up and puts it in the nativesdk sysroot, but likely under a subdir which references $MACHINE, or something.. or perhaps not, with the simplified sysroots in the sdk nowadays the entire sdk seems machine bound Aug 22 19:18:38 * kergoth ponders Aug 22 19:19:17 might have to do a disgusting hack for the time being :( Aug 22 19:27:26 Hello I am running on 3.0.35-4.1.0+yocto+g5809938 imx6qsabrelite board and at some time at least one a day I get 100% CP usage and both daemon.log and syslog gets hudge filling entire /var/volatile partition. Aug 22 19:28:40 I see connmand using high cpu and /etc/udhcpc/50default renew spining Aug 22 19:29:37 All I see is these two messages with rate about 20 a sec Aug 22 19:29:39 Aug 9 09:00:45 imx6qsabrelite connmand[1831]: eth0 {del} route 0.0.0.0 gw 192.168.15.1 scope 0 Aug 22 19:29:59 Aug 9 09:00:45 imx6qsabrelite connmand[1831]: eth0 {add} route 0.0.0.0 gw 192.168.15.1 scope 0 Aug 22 21:39:24 Hi everyone, I'm trying to create a new layer for my custom board, is it possible to add a new machine definition taking as "required" another definition present in another layer? I'm using a custom freescale board and I would like to use the original machine definition with my custom hack. Aug 22 21:39:40 use the 'require' directive Aug 22 21:39:48 grep around, plenty of .conf files include or require other files Aug 22 21:40:15 in fact, every machine should already do so, thats how they pull in the correct tune- config Aug 22 21:41:20 I know that, but I need to add a file from another layer, I've added a "require meta-fsl-arm/conf/machine/imx28.bb" but bitbake cannot find that path. Aug 22 21:42:13 again, every machine already pulls files from other layers Aug 22 21:42:31 every time a relative path is included, it searches all the paths in BBPATH (aka allt he layer paths) to find it Aug 22 21:42:38 so drop meta-fsl-arm/ from that and it'll work fine Aug 22 21:42:49 oh Aug 22 21:42:58 just make sure your LAYERDEPENDS in layer.conf reflects the dependency on the other layer Aug 22 21:43:01 thank you, that's what I was looking for! Aug 22 21:43:04 so if its missing, the build will abort Aug 22 21:43:06 sure Aug 22 21:43:11 np Aug 22 22:32:46 zeddii: any news about perf @3.16? **** ENDING LOGGING AT Sat Aug 23 02:59:58 2014