**** BEGIN LOGGING AT Sun Feb 08 02:59:58 2015 Feb 08 12:03:54 rburton: starting the tests of u-boot class change Feb 08 17:51:33 So, attempting to build Yocto for the Intel Edison board, and I seem to be stuck on a weird issue popping up from quilt. Feb 08 17:52:16 When I issue 'bitbake core-image-minimal', quilt's configure script bails out claiming that 'cp -l' doesn't support hardlinks. Feb 08 17:52:34 Where the heck can I look to see what the heck it actually tried to run? Feb 08 17:53:25 * texel sighs Feb 08 17:53:31 Just found the exact command in the configure script. Feb 08 17:53:39 Still doesn't really help -- no idea which cp it's attempting to use. Feb 08 17:54:34 Ah, sorry, this is in quilt-native_0.48.bb Feb 08 18:00:05 Aha. Apparently it needs to build "pseudo" first. Feb 08 18:00:29 Thing is, I've already built this and it's on /usr/local in my host system. How can I tell poky about it? Feb 08 18:10:21 its unlikely you have the exact version poky needs (read: the absolute latest) Feb 08 18:12:08 Aha. I see what happened now. Feb 08 18:12:17 It's due to weird filesystem semantics on my end. Feb 08 18:12:18 Ugh. Feb 08 18:12:54 The extra bit of info here is that I'm running this on Ubuntu somethsomething inside of Parallels Desktop on a MacBook Pro. =op Feb 08 18:13:13 The source tree is in my "shared folders" mount, which apparently can't create hardlinks. Feb 08 18:13:14 * texel sighs Feb 08 18:13:33 * texel really doesn't understand why people make filesystems and then don't support basic semantics like this... Feb 08 18:20:31 My only other question is, what does quilt do that actually needs hardlinks? =op Feb 08 18:21:39 the build system makes quite a lot of use of hardlinks in order to save space Feb 08 18:22:25 Ah. That's good to know. Feb 08 18:22:31 Also, that's awesome -- wish more build systems did that. =o) Feb 08 18:22:48 *cough*android*cough* Feb 08 18:23:26 Yeah, moving the build off the weird Parallels fs fixed the issue. Feb 08 18:24:51 Woot! Now I get build errors relating to tar. ;_; Feb 08 18:25:53 "tar: --same-order option cannot be used with -c" Feb 08 18:29:18 there is a fix for that, one moment Feb 08 18:30:20 http://git.yoctoproject.org/cgit/cgit.cgi/poky/patch/?id=bf19a8617d05f17506dcb7154e19e2aa2b61838b Feb 08 18:30:27 and Feb 08 18:30:29 http://git.yoctoproject.org/cgit/cgit.cgi/poky/patch/?id=d3846f06d1e3faedcbc3c28e22c427bb0088683d Feb 08 18:30:51 Ah. These are on mainline, I take it? Feb 08 18:30:58 Or rather, in the master branch? Feb 08 18:31:25 Also, thanks for digging those up. =o) Feb 08 18:32:39 well, a newer stable branch Feb 08 18:34:38 Aha. That explains why it wasn't in edison. Feb 08 18:39:19 Whoa. The year on that is 2013. Feb 08 18:42:01 Wow. Okay, so what build of Ubuntu is used generally to develop on Poky? Feb 08 18:42:14 I just got an error for gets from the host glibc install. Feb 08 18:52:08 texel: what is the error? Feb 08 18:52:14 texel: the reference manual has the list of the supported versions Feb 08 18:52:24 texel: mainly LTS supported ones work Feb 08 18:58:35 bluelightning: "#error gets is a security risk" or something similar. Feb 08 18:58:47 It's from that recent change that went into glibc that broke the world. =o/ Feb 08 18:59:06 I've given up trying to build yocto directly and instead am using the BSP from Intel directly. Hopefully that will have better results. Feb 08 18:59:39 otavio: I'm on Ubuntu 14 LTS Feb 08 18:59:53 14.04.1 LTS, to be precise. Feb 08 19:00:16 texel: I'm confused now - I thought you were building the BSP as supplied before... Feb 08 19:00:52 I'm not sure what "as supplied" really is when it comes to the Edison. The docs are all over the place. =op Feb 08 19:01:14 So first I tried building the BSP from source by cloning the yocto core git repo and then pulling down meta-intel on top of that. Feb 08 19:01:27 Had to setup my bblayers.conf and local.conf to reference the right machine and all that. Feb 08 19:01:57 Now I've downloaded a "source tarball" directly from Intel which seems to include a source tree for Yocto that seems to build (so far) Feb 08 19:02:09 just checking - you didn't at any point check out the "edison" branch... right? Feb 08 19:02:18 Yes, I did. Feb 08 19:02:24 In both repos. Feb 08 19:02:47 ok, so our "edison" branch bears no relation to the Intel Edison... one of our previous releases was coincidentally named edison Feb 08 19:03:00 Oh, geeze. Feb 08 19:03:06 hence the already solved build failures you had to work around... Feb 08 19:03:08 Okay, that makes much more sense now. Feb 08 19:03:11 Yeah. Feb 08 19:03:55 So then if I wanted to build an image for the Edison, I'd stay on the master branch and just use the appropriate machine targets, then? Feb 08 19:04:09 for the moment, I'd recommend sticking with the Edison BSP build instructions Feb 08 19:04:20 Right. Feb 08 19:04:24 hopefully there will be a better answer than that soon Feb 08 19:05:01 I hope so -- the instructions available are a bit crazy. Feb 08 19:05:27 Not that I think the yocto project should be responsible for Intels docs, mind you. =op Feb 08 19:06:43 (FWIW, I work for Intel, but in a different part than the group that produces the Edison) Feb 08 19:07:35 Oh, cool. Feb 08 19:08:19 Glad to see Intel folks out in the OSS world. =o) Feb 08 19:11:21 Ultimately my goal for this little mote is to run a copy of SBCL and build a wearable system out of it. Feb 08 19:12:31 I'd like to do that with as little extra junk as possible (ie: get rid of Node.js, etc.) -- hence the point of building a whole new image. Feb 08 19:22:27 Ugh. Doesn't look like this is going to work, either. Now I'm getting errors in the gcc toolchain build relating to -Wformat-security "format not a string literal and no format arguments" Feb 08 19:40:14 Hm. Nevermind. VM config error. Feb 08 21:09:31 Hi all, I have a question about DISTRO_FEATURES and VIRTUAL-RUNTIME. Is it possible to set these in an image recipe? I want to configure them in a more permanent/cohesive location than conf/local.conf Feb 08 21:10:07 I tried putting them there of course, but the options didn't stick. Feb 08 21:12:19 $ git grep -l DISTRO_FEATURES|grep image Feb 08 21:12:20 meta/classes/image.bbclass Feb 08 21:12:20 meta/classes/testimage.bbclass Feb 08 21:12:20 meta/recipes-extended/images/core-image-lsb.bb Feb 08 21:12:20 meta/recipes-graphics/images/core-image-directfb.bb Feb 08 21:12:20 meta/recipes-graphics/images/core-image-weston.bb Feb 08 21:12:22 meta/recipes-graphics/images/core-image-x11.bb Feb 08 21:12:29 ...so, it looks like it. Feb 08 21:13:07 setting DISTRO_FEATURES in a recipe would have no meaning, the whole point of it is to affect how things build Feb 08 21:13:11 one recipe can't affect others Feb 08 21:13:18 virtual-runtime, yes, it's used in the image Feb 08 21:17:09 Is inheriting distro_features_check in the recipe required as well? As paulg indicates, they are set in some of the default image recipes. My image inherits core-image, but not distro_features_check yet. Feb 08 21:18:30 distro_features_check is used to make the recipe not buildable when its required distro features are not set, that's all Feb 08 21:18:40 you'd only inherit if it that's what you need Feb 08 21:20:25 ok, interesting Feb 08 21:22:46 Where would you recommend I set DISTRO_FEATURES then? Is conf/local.conf the most appropriate place? Feb 08 21:23:23 distro features are generally set by the distro Feb 08 21:23:32 if you need to build on that, then yes, local.conf Feb 08 21:25:49 Hmm. I forked poky and am using that as the basis for a largely custom distro. If I wanted to make a systemic change my distro settings where would I do it? Feb 08 21:26:49 in your distro .conf, as i just said Feb 08 21:26:57 I'm looking to replace sysvinit with systemd, by the way. I just want it to be tied in with the rest of the feature set, not local settings. Feb 08 21:28:01 yes, again, put it in your distro Feb 08 21:29:50 OK, where is that set? o set Feb 08 21:29:54 whoops Feb 08 21:30:50 Is there a file for distro configuration? Maybe I'm having trouble with terminology. Is that distinct from image .bb recipes and .conf files? Feb 08 21:33:49 I appreciate your patience with my scattered questions Feb 08 21:35:29 first of all, you really shouldnt' be forking poky, just create your own layer with your own distro and do what you like there Feb 08 21:35:41 you can have the new distro include poky.conf, to use poky as a starting point Feb 08 21:56:01 kergoth, I misspoke earlier. We cloned oe-core, not poky. Apparently oe-core is distroless, hence no [poky/distro].conf. Feb 08 21:56:11 I need to read up on the differences. Feb 08 21:59:18 still a bad idea that isn't really in line with how things are done nowadays, but if there's no other option, okay Feb 08 22:14:27 r23s: at any rate, your best bet would be to create a distro in a new layer. conf/distro/.conf and adjust policy there. see poky.conf in meta-yocto as an example, or just include it in yours as a baseline Feb 08 22:16:50 kergoth: I'm reading up on the differences now and think that's exactly what I need to do. Thanks for your patience and for helping me out! Feb 08 22:17:13 np Feb 08 22:17:26 there's a lot to get your head around Feb 08 22:17:32 high complexity, but also high flexibility Feb 08 22:20:51 Indeed. I'm excited to get my head around all of these capabilities. It's already been immensely helpful, even with my primitive understanding of it. Feb 08 23:33:07 Welp, everything built. I'mma happy camper now. Feb 08 23:33:13 Thanks bluelightning. =o) **** ENDING LOGGING AT Mon Feb 09 02:59:58 2015