**** BEGIN LOGGING AT Sun Jan 31 02:59:58 2016 Jan 31 05:51:09 that's right, give him some homework Jan 31 05:58:14 morning. Jan 31 07:03:03 khem, Jan 31 07:03:04 good **** BEGIN LOGGING AT Sun Jan 31 12:28:53 2016 Jan 31 17:50:01 ERROR: ParseError at /home/paul/poky/meta-openembedded/meta-oe/recipes-extended/scsirastools/scsirastools_1.6.4.bb:17: Could not inherit file classes/autotools_stage.bbclass Jan 31 17:50:10 above is new since THurs or Fri... Jan 31 17:51:25 commit 3890af576a609ad8c9b14d5d5420537363fe7a34 Jan 31 17:51:25 Author: Jagadeesh Krishnanjanappa Jan 31 17:51:25 Date: Sat Aug 15 00:40:27 2015 +0530 Jan 31 17:51:25 scsirastools: add new recipe Jan 31 17:51:38 apparently the above has some unmet implicit dependencies. Jan 31 17:51:44 * paulg_ reverts for now Jan 31 17:58:48 paulg_: autotools_stage.bbclass was just removed, at least i just saw the patch to remove it on the list Jan 31 17:58:51 * kergoth shrugs Jan 31 17:59:07 guess bad timing on my part... Jan 31 17:59:49 * paulg_ works on getting build fixes to git, xterm and inetutils sent out instead. Jan 31 18:00:37 of course, now that I pulled latest changes, I get to wait for gcc to build again. :-/ Jan 31 18:01:11 probably burnt through a trainload of coal rebuilding toolchains over the years.... Jan 31 18:15:52 autotools_stage just contained a single line, "inherit autotools". Jan 31 18:16:06 so it is fairly easy to fix up those errors. Jan 31 18:16:50 I don't really know why anybody would have been adding new recipes that depend on it though. I think that must have been a mistake. Jan 31 18:20:05 indeed Jan 31 18:58:11 I seem to be the only one using https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/bin_package.bbclass , and I have a problem with it. How can I change this to install nativesdk-stuff in the correct location? Jan 31 19:33:48 tasslehoff: it should work just fine for nativesdk, i'm guessing you want it to work with nativesdk *and* non-nativesdk with the same source tree? Jan 31 19:34:19 i expect you just need to alter it to add the expected prefix Jan 31 19:34:39 not sure what that is offhand, but you should be able to examine the sdk vars in bitbake.conf Jan 31 19:34:52 hmm Jan 31 19:36:51 kergoth it is indeed the prefix I think. my cude recipe is installed, but in /usr/local/cuda-6.5, instead of inside the sysroot. therefore, I think, it is never copied/installed by the installer Jan 31 19:37:11 kergoth: actually I only need it to work for nativesdk Jan 31 19:38:06 if you want to work around it, presumably you could set the unpack subdir on the tarball to the needed prefix rather than altering the class Jan 31 19:38:17 then it'd =have hte right prefix in ${S}, so the class would pull from there Jan 31 19:38:49 you could just examine nativesdk.bbclass and look at the base prefix Jan 31 19:39:01 kergoth: ah. that is worth a shot Jan 31 19:39:25 base_prefix = "${SDKPATHNATIVE}" Jan 31 19:39:57 ;subdir=${SDKPATHNATIVE} might do it, then Jan 31 19:40:05 so your stuff would end up in ${SDKPATHNATIVE}/usr/local/cuda-6.5 Jan 31 19:40:22 booting the work laptop now :) Jan 31 19:40:43 you're right though, it'd probably be a nice feature to make the class automatically move the files into ${base_prefix}/ or so Jan 31 19:40:53 i htink if it just did that, it'd work without any class-specific workarounds Jan 31 19:41:06 i.e. no direct mention of nativesdk Jan 31 19:43:11 tasslehoff: https://gist.github.com/kergoth/a1743182221586c7828d might do it (untested) Jan 31 19:47:52 kergoth I think that was almost correct. missing an install -d :) Jan 31 19:48:10 ah, indeed :) Jan 31 19:48:53 its debatable, since the input binary tarball might already obey base_prefix, but that'd be easy to work around by setting S in the recipe, so i think this would be an improvement overall Jan 31 19:52:06 the recipe output was promising. populating the sdk now. Jan 31 20:07:13 kergoth: no. with the SDKPATHNATIVE it uses the correct folde structure, but fails to populate. not sure why yet. Jan 31 20:07:41 the bin_package change did not change the path at all. Jan 31 20:12:16 kergoth: http://pastebin.com/AUrZKpJa Jan 31 20:12:24 this is the hack Jan 31 20:35:04 kergoth: errors: http://pastebin.com/eTTWZatZ Jan 31 21:01:18 the files are in ./6.5-r3/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/local/cuda-6.5/bin/nvcc but not added to any dir in packages-split Jan 31 21:01:30 * tasslehoff_ continues the ramblings Jan 31 21:04:29 /usr/local isn't in FILES vars by default, did you rememeber to include ${SDKPATHNATIVE} when you added it? Jan 31 21:06:45 kergoth: current recipe: http://pastebin.com/gnmEvpSx Jan 31 21:07:03 yeah, that won't package anything with nativesdk Jan 31 21:07:12 the files aren't in /usr, they're in ${SDKPATHNATIVE}/usr Jan 31 21:07:34 not normally an issue, since the vars we usually package, like ${prefix}, ${bindir} etc are all altered by nativesdk.bbclass for us Jan 31 21:07:41 but in this case you aren't using those Jan 31 21:08:07 so change that to FILES_${PN} += "${SDKPATHNATIVE}/usr", or just use ${prefix} Jan 31 21:10:18 kergoth: I don't *think* that first one works either. how do I use ${prefix}? Jan 31 21:10:32 i don't think guessing is going to help Jan 31 21:10:45 if you want to know if something works, test it Jan 31 21:10:52 i just told you what will work, pick one Jan 31 21:11:06 FILES_${PN} += "${prefix}" or FILES_${PN} += "${SDKPATHNATIVE}/usr" Jan 31 21:11:10 either should do the job Jan 31 21:11:32 kergoth: sorry. it did not work with =. I said think in cases changing to += would, but it didn't Jan 31 21:11:42 = vs += is irrelevent Jan 31 21:11:54 just controls whether hte existing entries are kept, and since nothing is installe din those paths, it wont' matter either way Jan 31 21:12:02 its ensuring the paths listed there are prefixed by SDKPATHNATIVE that matters Jan 31 21:12:58 kergoth: is it a problem that ${PN} does not contain the string SDK, or does it evaluate to nativesdk-cuda-core2 when building Jan 31 21:13:54 the string nativesdk, I mean Jan 31 21:15:21 ${PN} is nativesdk-cuda-core2 Jan 31 21:15:28 look for yourself, bitbake -e is your friend Jan 31 21:24:02 kergoth: now it doesn't put anything in my packages-split. I've made things worse along the way :) Jan 31 21:24:18 this is not that complex Jan 31 21:24:26 make sure the paths in image/ are listed in FILES,a nd it'll end up in the packages Jan 31 21:26:46 kergoth: image/ is empty Jan 31 21:49:04 kergoth: thanks for helping. think I'll give up for the night soon.. Jan 31 21:50:22 kergoth: or not. setting subdir=cuda-core2-6.5 brought back stuff both in images and packages-split Jan 31 21:52:32 kergoth: subdir=cuda-core2-6.5${SDKPATHNATIVE} seems to be what works. Jan 31 21:55:34 pb_, thanks for spotting I got the wrong list (again...) -- I _can't_ be the only one who does that. Jan 31 22:05:33 kergoth: indeed. this fixed "everything". Jan 31 22:20:58 ah, nice Jan 31 22:43:20 paulg_: right, you are far from the only one. And I agree that the structure is complicated and confusing. Jan 31 22:46:03 pb_, could to see you, even if only for a minute Jan 31 22:46:11 and to all gn Jan 31 22:49:58 pb_, good to hear, (in a way) -- maybe I'll look into clarifying it somehow and somewhere. **** ENDING LOGGING AT Mon Feb 01 02:59:58 2016