**** BEGIN LOGGING AT Thu Nov 05 03:00:15 2015 Nov 05 04:42:12 Rallis: I'd instead suggest you to try etnaviv Nov 05 05:02:22 Has etnaviv been brought in as a recipe? Nov 05 07:16:00 how do I append to CMAKE_MODULE_PATH in my recipe? I tried CMAKE_MODULE_PATH += "my own dir" but no luck Nov 05 07:45:31 parrot1 maybe CMAKE_MODULE_PATH_append = " yourdir" ? sorry, I can only make guesses. Nov 05 07:48:15 stephan: negative. Thanks for trying though Nov 05 07:53:45 parrot1 http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/cmake.bbclass <= here they append something to it. list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/") Nov 05 07:57:24 stephan: I tried adding list(APPEND CMAKE_MODULE_PATH "my own dir") to my recipe but poky won't parse it :-( Nov 05 08:00:20 mmmmhhh.... putting it in cmake_do_generate_toolchain_file_append() { } ? Nov 05 08:00:32 did that too Nov 05 08:00:45 or maybe adding a new task between generate_toolchain_file and before do_configure? Nov 05 08:00:49 got bunch of ShellSyntaxError they said Nov 05 08:01:53 (you see that line starting with addtask in the file I linked) Nov 05 08:03:23 no luck :-( It still complained about the generate_toolchain_file_append method Nov 05 08:10:51 good morning Nov 05 08:11:03 good morning mckoan Nov 05 08:37:41 parrot1, I know the reason... Nov 05 08:37:50 sorry, I was blind :) Nov 05 08:38:13 in the first line of the function you see that toolchain.cmake is written with cat and a heredoc Nov 05 08:38:32 I guess you will have to append to that function (or write your own) appending to toolchain.cmake Nov 05 08:38:52 or maybe using sed on that file to edit the line Nov 05 08:57:51 stephan: I think I will look forward to append to that function rather than messing with toolchain.cmake Nov 05 09:18:49 morning all Nov 05 09:20:49 bluelightning: Is there a way that I can append to method cmake_do_generate_toolchain_file() in http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/cmake.bbclass in my recipe? Nov 05 09:21:18 I need to append to CMAKE_MODULE_PATH. Nov 05 09:22:08 parrot1: wouldn't you just install the required modules into that directory? Nov 05 09:24:27 bluelightning: not sure if that would be an elegant solution. If I were to submit my recipe to somebody else for example, I wouldn't want to have the end user to take the hard work of installing the module. Nov 05 09:25:46 I can also copy the module in do_patch or some other routines but not sure if that's alright since I'm writing to CMAKE_MODULE_PATH directory Nov 05 09:27:18 parrot1, no, I didn't mean, you should modify the file... you can in your recipe append to it or add a new task, which modifies the file, which is generated in the heredoc Nov 05 09:28:09 parrot1: so the cmake modules you wish to pick up - are they supplied by the same piece of software you are attempting to build? Nov 05 09:28:41 bluelightning: yes. Nov 05 09:29:01 isn't there already a facility for cmake to pick up those somehow? Nov 05 09:29:04 stephan: I'm also thinking of appending to toolchain.cmake Nov 05 09:29:15 bluelightning: what's the facility? Nov 05 09:29:28 I'm not sure, but how does it work normally? Nov 05 09:32:49 not sure either Nov 05 09:42:09 bluelightning: fyi, i solved the issue by writing a pre_configure routine that appends my own cmake path to CMAKE_MODULE_PATH Nov 05 10:09:49 hi Nov 05 10:22:05 yann|work: hi Nov 05 10:22:35 yann|work: btw, your name sounded familiar (heh) - you used to work on Linux-on-iPAQs some time ago, is that right? Nov 05 10:23:37 * rburton groans Nov 05 10:54:32 bluelightning: right :) Nov 05 10:58:01 I think I also had another short contact with OE in the meantime, though I can't remember what it was Nov 05 10:58:18 maybe playtesting something for the FreeRunner Nov 05 11:31:24 the 1.8 ref manual seems outdated wrt ipk feeds: when I read it I understand that ipk feeds are not generated, as opposed to deb/rpm, but in fact there are feeds in deploy/ipk Nov 05 11:33:32 I'm not not found yet which recipe does that :) Nov 05 11:33:40 yann|work: which part of the manual? Nov 05 11:33:58 yann|work: it's not a recipe so much as a couple of classes and a set of python modules Nov 05 11:34:39 i.e. classes/*ipk*.bbclass and meta/lib/oe/package_manager.bbclass Nov 05 11:38:52 oh, so it's not that easy to get it refreshed after manually building a package that's not mentionned in the conf ? Nov 05 11:40:14 bluelightning: first there is a note in "3.5.4. Package Splitting" which is not ipk-specific and says there is no support for feed generation Nov 05 11:41:21 then "6.2.13. build/tmp/deploy/ipk/" does not include the " The packages are sorted into feeds for different architecture types" text the other two have Nov 05 11:44:04 yann|work: bitbake package-index will refresh it Nov 05 11:45:58 yann|work: I think what that note is trying to say (perhaps not as well as it could) is that the "feeds" that the build system creates aren't proper distribution-style feeds Nov 05 11:46:18 I mean they'll probably work just fine for most cases Nov 05 11:47:15 yes, looks like they do :) Nov 05 11:47:21 it's not exactly clearly written I'll agree though Nov 05 11:47:34 which is bad because I helped Scott write that section :/ Nov 05 11:48:42 :) Nov 05 11:48:58 in the meantime, package-index is exactly what I needed, thx! Nov 05 12:08:15 what would be the correct place to report a bug the ruby recipe in the meta-openembedded layer? Nov 05 12:08:24 +for Nov 05 12:14:39 Ulfalizer: the openembedded-devel mailing list; however in master the ruby recipe lives in OE-Core Nov 05 12:14:56 I'm sure I stumbled on a cross-ref to where is detailed how to get the source for a recipe from a local tree ("5.3.6. Fetching Code" would seem a good match, but does not talk about that), I just can't find it any more Nov 05 12:16:52 yann|work: http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#building-software-from-an-external-source Nov 05 12:17:11 devtool modify will also do that if it's for temporary (during development) usage Nov 05 12:17:35 bluelightning: this is specifically for the 1.9 recipe, not the newer one from meta/. i've also found a small "bug" in the newer one though in that it enables --disable-versioned-paths though no such option exists. Nov 05 12:17:45 that option does exist for 1.9 though, because a patch adds it Nov 05 12:17:50 so might be a copy-paste thing Nov 05 12:18:11 also, i should double-check if the above is true. it's what i remember. Nov 05 12:18:31 bluelightning: thx Nov 05 15:04:51 is it a good idea, to add to DISTRO_FEATURES in local.conf, to test before having started to define my own distro ? I'd just like to produce a directfb image, and looks like I must first touch DISTRO_FEATURES.. Nov 05 15:06:12 yann|work, that is reasonable Nov 05 15:07:40 cool :) Nov 05 15:08:37 oh, but then I have to remove the x11 feature :( Nov 05 15:09:46 is there no "DISTRO_FEATURES -= whatever" :) Nov 05 15:12:25 it seems to accept overriding DISTRO_FEATURES completely in local.conf, cool Nov 05 15:13:30 yann|work: DISTRO_FEATURES_remove = "x11" Nov 05 15:46:13 rburton: oh, cool! Nov 05 15:56:35 changes to DISTRO_FEATURES are not supposed to be noticed as requiring rebuild of recipes that check for features ? libsdl2 is apparently not completely rebuilt: obviously it attempts to relink, but the objects predate the change :( Nov 05 15:56:50 going to use a separate build dir... Nov 05 16:00:02 if the recipe uses contains() to check DISTRO_FEATURES, then only the existance or not of the feature theyr'e checking for will affect their signatures, not any change to DISTRO_FEATURES Nov 05 16:35:17 ok Nov 05 16:36:25 so I have setup a second build dir for the directfb image build, sharing the sstate and dl dirs, but it's still rebuilding be the cross toolchain :( Nov 05 16:38:40 rha, my bad, forget it :) Nov 05 16:45:55 rha again, with proper sstate setting, it seems at first to reuse everything and go much faster, with 600+ populate_sysroot tasks going OK, then warns about a couple of setscene tasks for minor recipes returning 1, and seems to go on compiling native tools... Nov 05 16:46:51 have to stop here for today... Nov 05 18:10:59 hmm, we have fs-perms.txt doing some volatile links, but not others, then we have volatiles in initscripts setting some up, and tmpfiles.d setting others up for systemd, and they're not entirely equivalent Nov 05 18:13:46 I seem to have broken how rpms are prevented from depending on other packages that are not generated due to being empty (eg qtbase depending on qtbase-qmlplugins). Anyone know how this is supposed work or where to look? Nov 05 18:41:44 bluelightning: is it expected that with sstate sharing between 2 builds dirs of the same source, with only x11 vs. directfb as local.conf difference, even the toolchain gets rebuilt ? Nov 05 19:04:41 Ok, so I'm down to TUNE_FEATURES = "arm armv7a vfp" Nov 05 19:04:54 and this builds but doesn't boot Nov 05 19:06:10 yann|work: hmm, it shouldn't be that way, however I don't know that DISTRO_FEATURES changing in an otherwise same environment is a well-optimised case Nov 05 19:09:59 should probably review all checks of DISTRO_FEATURES to make sure they all use contains() or contains_any() at a minimum, might be more to do beyond that, though Nov 05 19:20:29 RP, and possibly others: Just a note that so far as I know, OS X starting with El Capitan is going to permanently break pseudo for host binaries, because they're not letting LD_PRELOAD override libc anymore. Good security feature, does mean it'll be much harder to make pseudo work on OS X. There may be a setting to override that, but it's going to be a barrier to oe-core-on-OS-X. Nov 05 19:22:07 @yann|work: If you want to dig into it you can use bitbake-diffsigs. Nov 05 19:31:29 bluelightning: I think there are boot tests somewhere, are the results public ? Nov 05 19:38:01 seebs: ouch :( Nov 05 19:38:58 yann|work: its not expected, no Nov 05 19:41:57 I don't know whether there's a setting for it, if not we'd pretty much have to come up with a complete self-hosting environment including sh and everything to work around it, eww. Nov 05 19:44:50 seebs: well that might be an improvement, you'd probably be able to build yocto on windows too then :) Nov 05 19:45:34 "improvement" Nov 05 19:45:37 hmm Nov 05 20:27:05 abelloni: we do regular boot tests on the autobuilder, basically for every build - and the results of those are public Nov 05 20:27:44 within QEMU though; I don't think we've got to the point where we have the infrastructure properly set up for regular real hardware boot tests Nov 05 20:35:06 Is there a bitbake command that will show me the Build Configuration section without actually building something? Nov 05 20:37:52 you can do a dry run (which noops all of the tasks but still runs through the logic of scheduling and running them) with -n Nov 05 20:45:40 joshuagl: that works. Thanks! Nov 05 20:46:13 np Nov 05 20:52:25 anyone seeing devshell failures recently? can't get screen or tmux to work at all anymore on 14.04-64 Nov 05 21:53:28 seebs: i implemented a workaround to el cap's SIP for macports' DYLD_INSERT_LIBRARIES usage Nov 05 21:53:45 seebs: if you're interested I can give you a link Nov 05 21:54:55 seebs: "csrutil disable" in rescue mode also works, but is really not a good thing to advise people to do Nov 05 22:33:26 So I've got an error message that I cannot figure out the correlation between the two. The error is here: http://paste.pound-python.org/show/u0J1YBmENInkCBHZV46p/ And it only happens when I add https://github.com/jmesmon/meta-rust into my BBLAYERS Nov 05 23:28:13 neverpanic: I would indeed be pretty interested in that. Can you email it to me (peter.seebach@windriver.com)? **** BEGIN LOGGING AT Thu Nov 05 23:50:44 2015 Nov 06 00:58:57 * armpit has to stop breaking things Nov 06 01:49:04 mdadm failure ^^^ Nov 06 02:17:22 * armpit mmm, thought 64 targets put libs in /lib64... must be confused again Nov 06 02:21:29 Depends on the target, I think. Nov 06 02:21:41 Some use /lib for 64-bit stuff, and /lib32 for any 32-bit stuff that's also installed. Nov 06 02:27:38 seebs, thanks Nov 06 02:31:40 how do I check the order the methods gets executed when executing a recipe? **** ENDING LOGGING AT Fri Nov 06 02:59:58 2015