**** BEGIN LOGGING AT Wed Sep 07 02:59:58 2016 Sep 07 06:53:19 Good morning. What is the practice for placing tools/scripts needed for building images? Placing in the metas? Sep 07 06:54:38 Is it frowned upon and possible to refer to a another recipe's SRCes to get tools? Sep 07 08:10:33 hi Sep 07 08:11:24 rburton, made upstream geoclue release that builds fine now but for some reason generated rpm package is now named libgeoclue just cause a library is added Sep 07 08:11:36 rburton, any clues? Sep 07 08:18:06 zeenix: there's a library renamer (to follow debian naming policy IIRC). You can override if needed but usually the renaming is not a bad thing. Is there a problem? Sep 07 08:19:20 i guess zeenix expacts the package to be named geoclue-...rpm no matter that it includes a file libgeoclue.so Sep 07 08:20:42 yeah Sep 07 08:21:07 or some way of seperating out library part into another package Sep 07 08:23:21 s/expact/expect/ Sep 07 08:28:53 zeenix: maybe separate the daemon/utils to separate package(s) instead? Sep 07 08:29:15 assuming that makes sense for geoclue Sep 07 08:33:50 jku, not really but wouldn't be a bad workaround i guess Sep 07 08:34:57 zeenix: if all of it really should be in the same package then that's doable as well... it's just rare I think Sep 07 08:38:30 zeenix: case in point, don't your fedora rpms have the same separation? Sep 07 08:38:57 geoclue2-libs & geoclue3-demos Sep 07 08:39:12 s/3/2/ Sep 07 08:39:42 jope Sep 07 08:39:44 nope Sep 07 08:40:03 the main package is geoclue Sep 07 08:40:06 and geoclue2 itself for daemon Sep 07 08:40:13 then we have separate packages for others Sep 07 08:40:35 yes Sep 07 08:41:10 yeah, on fedora we have geoclue2, geoclue2-libe and geoclue2-demos Sep 07 08:41:19 geoclue2-libs Sep 07 08:43:09 zeenix: jku: http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-DEBIAN_NOAUTONAME Sep 07 08:43:24 if you really want to turn off the package renaming Sep 07 08:44:19 I still don't see the real problem... AFAICS the lib and daemon really should be in separate packages Sep 07 08:44:34 is this just about the name of the daemon package? Sep 07 08:47:15 They probably should be in separate packages, yeah Sep 07 08:56:00 if the issue is that the daemon should be in a package called "geoclue", I think that should still be possible. Just add "geoclue" to PACKAGES and add the daemon files to that package. Sep 07 08:57:33 jku, yeah, that's what i was looking for i think :) Sep 07 08:58:00 man these sweds eat lunch even earlier than finns Sep 07 09:00:46 11 am? just think of it as breakfast Sep 07 09:07:21 hi everyone Sep 07 09:12:59 i'm using wayland on a Freescale IMX6, everything is ok whith bitbake, I can build the sdk for my image. When i'm using my sdk to build a graphical application (using gtk3+) the configure complains about missing package "wayland-egl". I checked on bitbake's sysroot I can find the wayland-egl.pc but I can't find it in the sdk sysroot... Any idea to workaround this? Sep 07 09:13:58 (i can find the wayland-egl.pc inside a package : libwayland-egl-mx6-dev-5.0.11.p8.3+hfp-r0.0.cortexa9hf_neon_mx6qdl.rpm) Sep 07 09:24:59 aurele: you probably need to add wayland-egl-dev or some such to TOOLCHAIN_TARGET_TASK (http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-TOOLCHAIN_TARGET_TASK) Sep 07 09:25:42 aurele: btw, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=10216 to learn an easy way to figure out which package provides a file. it's some pending documentation. Sep 07 09:25:43 Bug 10216: normal, Undecided, ---, srifenbark, NEW , Suggested (currently missing) documentation for oe-pkgdata-util Sep 07 09:26:14 oe-pkgdata-util find-path /path/to/wayland-egl.pc might tell you Sep 07 09:26:42 the path is relative to the sysroot (or, put another way, the path within the package9 Sep 07 09:30:51 hi. i could need a hint. i'm writing a recipe for a project with a sucky layout: it uses plain makefiles. there's one Makefile in the root source directory, and then there's another Makefile in a subdirectory. how do i write a recipe that builds using both makefiles? Sep 07 09:31:58 ionte_: do both need to be run manually, or does the top-level makefile call the other one? Sep 07 09:32:12 Ulfalizer: the top-level does not call the other one Sep 07 09:33:23 ionte_: you could do something like oe_runmake; oe_runmake -C $subdir in your do_compile Sep 07 09:34:24 it's better to use oe_runmake than directly calling make (or using ${MAKE}) btw. adds parallelization options automatically (via EXTRA_OEMAKE). Sep 07 09:34:59 the latest version of the reference manual has more information on do_compile than previous versions btw: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-tasks-compile Sep 07 09:35:03 and more information on oe_runmake Sep 07 09:35:39 nice! thanks! i tried using just make, but that did not work (missing includes etc) Sep 07 09:35:48 works perfectly now Sep 07 09:36:12 missing includes usually means missing stuff in DEPENDS Sep 07 09:36:13 np Sep 07 09:36:35 don't think so, since oe_runmake works Sep 07 09:37:09 ionte_: sometimes things can build even though there are missing build-time dependencies. see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#checking-for-missing-build-time-dependencies. Sep 07 09:37:43 there's probably no problem in your case, but worth being aware of at least :) Sep 07 09:38:13 in general, the newest (2.2) version of the manuals add a lot of stuff over the 2.1 version Sep 07 09:38:32 it might be because i had to add extra cflags using EXTRA_OEMAKE and oe_runmake use that information while plain "make" does not... Sep 07 09:38:46 yup, that's it, if you were using EXTRA_OEMAKE Sep 07 09:38:54 gotta run. brb. Sep 07 10:42:57 Ulfalizer, sry to be late, thanks for the tips (to find wich package provide which files I made a python script wich calls "rpm -qpl" on all package then stores it in a json file... then searching is pretty fast) Sep 07 10:44:06 the oe-pkgdata-util approach uses package metadata written out during do_package btw Sep 07 10:46:29 Ulfalizer, of course I can imagine oe-pkgdata-util uses better way than mine ;) I just tried, it is pretty powerfull! Sep 07 10:47:53 yeah, not sure why it's so "hidden" Sep 07 12:42:02 can i tell yocto to use a gcc-4 compiler? Sep 07 12:44:34 What process creates the link from the generic image to the datestamped image in deploy? Where can I find the recipe for this? Sep 07 12:47:45 to answer myself see meta/conf/distro/include/tcmode-default.inc variable GCCVERSION Sep 07 12:52:48 Has anyone used the mkefidisk wic image for minnowboard max? Sep 07 13:43:56 I have a corrupted Packages.stamps in my (production) build folder. Looks like there's some extra data at the end (ie like a smaller file was written on top, essentially) Sep 07 13:46:58 I was given the advice to try a new tmp folder. However that's not great given it's meant for production, I assume at least, so I'm looking for other suggestions for repairing it/regenerating it if possible Sep 07 13:49:26 simonl: it's not a bad idea to always start with an empty tmp/ for production Sep 07 13:50:42 neverpanic: I've experimented a bit and ended up getting new revisions of pretty much every package. Maybe I messed something up then to make that happen Sep 07 13:52:15 neverpanic: since it sounds like it's meant to be safe (I'd assumed it was better _not_ to do it) maybe I should just try again. Sep 07 13:53:34 we always wipe tmp/ for each build to ensure repeatability on builds in production. We rely on sstate cache to provide efficiency during rebuilds Sep 07 13:55:04 rebuilding a unchanged source from a wiped tmp and with full cache only takes a few minutes Sep 07 13:55:14 I originally set it all up in a hurry, and haven't really had the time to revisit the topic. Until it broke :( Sep 07 13:55:39 jku, am i doing it wrong? http://paste.fedoraproject.org/423380/25652214/ Sep 07 14:02:53 uh, I might have been wrong. maybe you can't set the daemon package name as that if it's the original (non-debianized) main package name... Sep 07 14:02:59 zeenix: ^ Sep 07 14:03:41 easy test would be to change the daemon package name to something else Sep 07 14:06:03 zeenix: do you want to share the recipe though, kind of hard to guess from single line? Sep 07 14:11:40 jku, sure, i was hoping to submit it actually once i've happy with it Sep 07 14:12:20 jku, http://paste.fedoraproject.org/423390/25752714/ Sep 07 14:12:59 zeenix: yes I think I was indeed wrong: the package name mangling happens after the files have been split to the package directories -- so you can't reuse the name Sep 07 14:13:10 What controls the rootfs size with wic? My 380M image has 65M to spare (80% use). I've set IMAGE_OVERHEAD_FACTOR="1.0" and IMAGE_ROOTFS_EXTRA_SPACE="1024". Any other ideas? Sep 07 14:13:33 sorry about that Sep 07 14:14:12 jku: zeenix: pretty sure you want to add a -libs package and split the library into that Sep 07 14:15:28 joshuagl: was just about to say I would just put the daemon to ${PN}-daemon package, but either way should work Sep 07 14:15:57 jku: or that, sure. I don't know enough about geoclue to know which makes sense as the ${PN} package Sep 07 14:16:09 I mean if there is a standard library package naming, why work against that? Sep 07 14:19:41 one good question is why are you splitting daemon/libraries Sep 07 14:19:50 if they're both essential then what does that achieve Sep 07 14:19:58 well ${PN}-daemon => libgeoclue-daemon Sep 07 14:20:07 which is giving wrong impression Sep 07 14:20:19 the actual thing is daemon/service, library is just a wrapper Sep 07 14:20:38 just throw it all in PN splitting is overrated Sep 07 14:20:43 Jefro ping Sep 07 14:20:46 unless you're playing multilib games Sep 07 14:20:47 rburton, sure Sep 07 14:21:00 rburton, just that it names my package as libgeoclue Sep 07 14:21:08 just cause there is a library file included Sep 07 14:21:19 zeenix: IIRC it won't if it also has binaries Sep 07 14:21:22 that would surprise me because it only renames if there is *only* a library in there Sep 07 14:21:40 it *does* rename PN, so PN-daemon would be libgeoclue-daemon Sep 07 14:21:41 i wouldn't have minded it automatically splitting a -lib package Sep 07 14:21:50 if you don't want that then call the other package geoclue-daemon Sep 07 14:22:05 but again, unless you actually want it split up, don't bother :) Sep 07 14:22:25 but it does name it as libgeoclue Sep 07 14:22:44 where is this recipe so you can prove it ;) Sep 07 14:22:51 but could be cause daemon binary is under /usr/libexec ? Sep 07 14:22:52 not if you use "geoclue-daemon", not "${PN}-daemon" Sep 07 14:23:07 oh there is the recipe Sep 07 14:23:08 1 PACKAGES += "geoclue" Sep 07 14:23:34 honest just ignore splitting. :) Sep 07 14:23:36 ah that was there to try to fix the issue :) Sep 07 14:23:47 sure, ignored Sep 07 14:24:13 so i guess all i neeed then is: Sep 07 14:24:15 DEBIAN_NOAUTONAME_geoclue = "1" Sep 07 14:26:43 also Sep 07 14:26:51 DEBIAN_NOAUTONAME_geoclue-dev = "1" Sep 07 14:26:57 and for -dbg Sep 07 14:32:54 zeenix: Or set AUTO_LIBNAME_PKGS to exclude the packages you don't want to be renamed Sep 07 14:34:18 rburtons point is good though: if the renamer shouldn't rename if there is more than a library in the package then something is going wrong in the first place Sep 07 14:37:06 well, stuff in libexec can be considered part of the library Sep 07 14:37:40 the renamer just checks for $bindir which is fair enough imho Sep 07 14:38:06 AUTO_LIBNAME_PKGS="" should work nicely to nullify it Sep 07 14:38:20 oh I missed the libexec detail Sep 07 14:41:28 rburton: submited my v2, btw... Sep 07 14:41:44 once it's accepted, I can work on the real goal of this project... Sep 07 14:41:50 backporting to jethro Sep 07 14:41:55 mwahahaha Sep 07 14:42:15 boucman_work: yeah was just looking at it actually Sep 07 14:42:59 when tar complains about not being able to exec lbzip2, which package am I missing? libbz2 is apparently not it Sep 07 14:43:20 sveinse: paste the full message? Sep 07 14:44:16 tar --directory=/mnt -xf /opt/image/image-01.tar.bz2 tar (child): lbzip2: Cannot exec: No such file or directory Sep 07 14:44:43 This is on target Sep 07 14:45:22 that's interesting Sep 07 14:46:08 I've installed ${CORE_IMAGE_BASE_INSTALL} from core-image. perhaps I'm missing something here Sep 07 14:47:08 And I've installed tar explicitly, as the busybox tar can't handle --directory Sep 07 14:47:41 sveinse: i would expect tar to call a binary called bzip2, not lbzip2 so two things to investigate Sep 07 14:47:52 http://lbzip2.org Sep 07 14:48:03 oh... Sep 07 14:48:08 i suspect it found lbzip2 on your build host at configure time and thought I KNOW I'LL USE THAT Sep 07 14:48:36 sveinse: so my first prediction is that you have lbzip2 on your build host Sep 07 14:49:01 hmm, interesting case of host poulution... Sep 07 14:49:50 i keep on thinking we need to patch AC_CHECK_FILE etc to check for configure scripts poking at the host Sep 07 14:50:05 we use pbzip, i wonder what one is better Sep 07 14:56:00 rburton: I do have libbz2-1.0 installed on host. So yes, host pollution it apparently is. Sep 07 14:56:27 I don't really care about which version of bz2, I just need one that works on target :P Sep 07 14:56:53 zeenix: yocto@ is for user support mostly, for meta-oe you want to send to openembedded-devel@lists.openembedded.org Sep 07 14:57:04 If all else fails, I can uncompress and stream to tar manually Sep 07 14:57:26 rburton, ah ok. i had trouble finding where to send the patch. thanks Sep 07 14:57:55 zeenix: README in the layer says "Send pull requests to openembedded-devel@lists.openembedded.org with '[meta-oe]' in the subject'" Sep 07 14:58:32 hello Sep 07 14:58:44 Maybe I don't need to RDEPEND on libbz2, as I see bunzip2 is a part of busybox Sep 07 14:59:01 rburton, right :( thanks Sep 07 15:06:18 I've been doing linux embedded systems and build systems for 10 years, and one thing amazes me guys: How have you managed to do fs system manipulation without ever becoming root? Respect! Sep 07 15:08:05 pseudo Sep 07 15:08:11 sveinse: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#fakeroot-and-pseudo Sep 07 15:10:49 very elegant Sep 07 15:14:09 could probably be done without emulation on modern kernels. they allow you to create isolated environments where you appear to be root. Sep 07 15:14:44 that's what e.g. containers use Sep 07 15:15:50 patches welcome : Sep 07 15:16:44 ain't broken though, plus two implementations would probably make the code harder to follow ;) Sep 07 15:17:42 if it was a required kernel feature, it could probably simplify things a lot though Sep 07 15:17:54 going on a guess, because i've never actually done much with container stuff :P Sep 07 15:18:21 Ulfalizer: That's a Linux-only feature, though. pseudo used to work on OS X as well Sep 07 15:18:37 alright Sep 07 15:18:49 Plus a lot of distro kernels still don't ship user namespaces by default Sep 07 15:20:09 neverpanic: until apple basically banned it :/ Sep 07 15:20:58 rburton: why banned? Sep 07 15:21:09 persistence might get tricky too Sep 07 15:21:31 i.e., run a task, quit bitbake, run another task that needs to see the same fake permissions Sep 07 15:22:02 sveinse: http://jwintz.me/blog/2015/11/30/on-preload-and-sip-on-macos-x-dot-11/ Sep 07 15:24:50 rburton: thanks. More of a side-effect really then Sep 07 15:30:41 rburton, thanks for all the help. Sep 07 15:32:10 OpenIndiana :) Sep 07 15:32:33 Ulfalizer: You might want to play with OpenIndiana on Linux zones soon... ;) Sep 07 15:32:48 anyone here familiar with u-boot ? I have an old version that I have compiled outside of yocto that works. Now I'm trying to switch to yocto and getting the yocto u-boot working for my board. U-boot runs, but when I get to the actual booting of the kernel it gets to "Starting Linux..." and just hangs. The same kernel image I can load and run just fine with my old U-boot. Sep 07 15:33:29 a1cypher: compare the u-boot environments for old and new Sep 07 15:33:37 it's the same environment. Sep 07 15:33:53 a1cypher: One common cause is that kernel output is going to another console. Have you checked the kernel parameters for the new, including the default built-in to u-boot? Sep 07 15:33:58 a1cypher: missing console parameters Sep 07 15:34:36 a1cypher: you compared printenv from both u-boot versions? Sep 07 15:34:55 rburton: well, there are workarounds for Apple's ban as well Sep 07 15:35:21 i'll try the compared printenv next. I dont think the kernel is starting at all. I have an led setup as a heartbeat in the kernel that never starts blinking Sep 07 15:35:29 Ulfalizer: persistence might work with usernamespaces if you have sub-UIDs configured... but then again, who currently has. Sep 07 15:38:44 rburton: To be honest, it seems Apple's "ban" on DYLD_INSERT_LIBRARIES is more of a bug than a conscient decision. You can always still use it on copies of the binaries (so why doesn't it just behave as if it was when run with DYLD_* stuff set?), and it breaks /usr/bin/env and /usr/bin/printenv (they won't show DYLD variables) Sep 07 15:39:36 envinronments are identical except the new one also has a defined fdt_file variable. However, I dont load this and when I boot it does say "No Flattened Device Tree Continuing to boot without FDT" Sep 07 15:42:04 that will be it ; the dtb/dts can specify pretty much anything/everything -- ram size, serial ports etc. If it doesn't find/use one, and makes assumptions in some (largely untested) legacy mode, chances are it will get things wrong. Sep 07 15:42:42 my old kernel predates FDT so all the machine specific stuff is compiled in Sep 07 15:44:16 yeah, if you are on some old 2.6.x stuff and trying to move forward to today, you probably have your work cut out for you if the board isn't supported in mainline. Sep 07 15:44:59 it is supported. I have another devboard that boots just fine using the latest yocto and the same version of u-boot. I"m trying now to move to my custom board Sep 07 15:46:02 well that is good; at least you have a working comparison to help narrow down the delta. Sep 07 15:46:28 yeah, I'm trying to figure out just u-boot first, then I'll move on to the kernel. I was thinking that the new u-boot should be able to load my old kernel just fine. Sep 07 15:47:22 might be worth jumping ahead ; test new u-boot with dtb on new kernel ; if you don't have a use case for new u-boot and old kernel, then who cares? Sep 07 15:48:16 yes, ideally it would work, but probably on the wrong side of the bathtub curve on that one. Sep 07 15:50:04 yeah, perhaps thats the best bet. I just need to write up a simple dts for my board and see if I can get it to boot the same new kernel as the devboard Sep 07 15:59:40 What is the right way to remove a PNBLACKLIST in a bbappend? A python fragment that does d.delVarFlag('PNBLACKLIST', 'package') ? Sep 07 16:00:51 if you have master you can use the new keyword Sep 07 16:01:19 unset VAR[flag] Sep 07 16:12:48 is there any best practices for placing scripts and tools for recipes in layers? Sep 07 16:13:17 a scripts/ directory in the layer? Sep 07 16:14:28 jup. I need to path myself to it? Or can this be added in layer.conf? Sep 07 16:15:02 for *you* to run, or the recipe? Sep 07 16:15:13 recipe Sep 07 16:15:21 then write a native recipe and ship them into the sysrot Sep 07 16:15:38 thats the "best" way Sep 07 16:16:05 you could use the layer path and extend $PATH in the layer.conf i guess though Sep 07 16:16:22 right, when do you divide scripts and tools as separate repos vs. embed them into the meta layer? Sep 07 16:16:56 yeah your choice really :) Sep 07 16:17:13 because the idea is to keep the meta as a meta, right. With native tools somewhere in between Sep 07 16:18:37 dummy question guys: I get the message "Files/directories were installed but not shipped" Sep 07 16:19:04 file not listed in FILES_packagename Sep 07 16:19:09 Adding a FILES_${PN} += should be sufficient? Sep 07 16:19:30 yes Sep 07 16:19:43 And if I still get the message then? Sep 07 16:20:20 you did FILES_${PN} += /path/to/dir/thats/missing right? Sep 07 16:20:31 only the file name Sep 07 16:20:36 not the full path Sep 07 16:20:52 then /path/to/filename ? Sep 07 16:21:43 fragfutter: that's it! :) the full path :) Sep 07 16:22:02 fragfutter: thanks! Sep 07 16:22:10 you are welcome. Sep 07 16:29:21 How does yocto know what dtb's to build? I have added my new dts to the kernel and added it to the Makefile in the dts directory, but when i do bitbake linux-fslc -c compile -f it does not seem to make nor deploy the dtb file. Sep 07 16:31:29 KERNEL_DEVICETREE variable Sep 07 16:32:48 thanks. found it! Sep 07 16:57:42 Sweet! booting my new kernel using the new u-boot and dtb. thanks for the help paulg, fragfutter, and sveinse Sep 07 17:00:25 a1cypher, no problem; glad my guess of being on the wrong side of the bathtub curve proved correct. Sep 07 17:01:01 now I just need to finish getting my dtb correct for all the other devices on my board. Sep 07 17:02:55 heh, been down that road back in the day when all of ppc went dtb ; don't have fond memories of it. Sep 07 17:05:38 wow, that was back in 2008. http://lists.denx.de/pipermail/u-boot/2008-July/036985.html Sep 07 17:06:10 time flies. Sep 07 17:06:45 I've since deleted that BSP from u-boot and the kernel. :) Sep 07 17:53:13 * kergoth thinks the bitbake user manual should be included in the mega manual Sep 07 17:54:09 seconded... Sep 07 17:54:33 folks keep searching the mega manual for things, like the fetcher url parameters, and not realizing it's covered in the bitbake manual Sep 07 18:06:31 my google-fu is not strong today ... gcc on my host is 6.1. Some recipes in the Yocto release I'm using right now are failing to compile with that. I also have gcc-4.9 installed, and that seems to work. How do I tell the build to use gcc-4.9 instead of gcc for native builds? Sep 07 18:07:01 (how did I figure that gcc-4.9 works? I messed around with symlinks the PATH) Sep 07 18:07:53 BUILD_CC Sep 07 18:18:08 thanks, still waiting to see if that works :D Sep 07 18:31:34 it won't work for everythging, sadly Sep 07 18:31:40 theres a series to fix that on the list now Sep 07 18:31:51 symlinks in path work now Sep 07 18:32:28 ah, didn't realize those weren't merged yet Sep 07 18:34:46 i am trying to get files which I included as native/nativesdk to be in my populate-sdk build Sep 07 18:34:58 i have them in my sysroot for x86_64 Sep 07 18:35:11 but the sysroot install does not have them Sep 07 18:35:39 i have done the inherit native nativesdk bit in my recipe. is there something else I need to do? Sep 07 18:47:50 I also added to local.conf a SDKIMAGE_FEATURES += "my recipe" Sep 07 18:48:17 with all that, it does not make it to the sysroots directory after I install the sdk. Sep 07 18:51:12 features != packages Sep 07 18:51:14 wrong variable Sep 07 18:51:28 see TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK Sep 07 18:51:40 image features are things like dbg-pkgs, dev-pkgs, etc. Sep 07 18:53:24 kergoth: thanks Sep 07 20:19:14 hmm. now I am back to where I started with this error. Sep 07 20:19:29 * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'my native recipe' Sep 07 20:37:46 davis: native recipes shouldn't be going anywhere near packaging - what are you trying to do exactly? Sep 07 20:38:16 bluelightning: its complicated, but to try and boil it down to this. Sep 07 20:38:30 i have a recipe which builds some code for the host. Sep 07 20:38:58 the recipe is able to add some binaries to my host sysroot bin directory. Sep 07 20:39:14 now I want to build an sdk which has these bins in it. Sep 07 20:39:34 if I remove references to my recipe the sdk will build Sep 07 20:39:40 add nativesdk to BBCLASSEXTEND, add nativesdk-yourrecipe to TOOLCHAIN_HOST_TASK Sep 07 20:40:02 i do believe that is what i have Sep 07 20:40:09 one sec, i'll pull up the refs Sep 07 20:40:34 local.conf has TOOLCHAIN_HOST_TASK += "pcmx-native" Sep 07 20:41:07 native is not quite the same as nativesdk Sep 07 20:41:13 pcmx-native_%.bb has Sep 07 20:41:21 BBCLASSEXTEND = "native nativesdk" Sep 07 20:41:33 that's not quite right Sep 07 20:41:59 the recipe should be pcmx and by virtue of the BBCLASSEXTEND you will get pcmx-native and pcmx-nativesdk out of it Sep 07 20:42:19 ok, so here is the complication i omitted. Sep 07 20:42:48 i need to have two pcmx's. one for native and one for target. I was trying to use pcmx as the target and pcmx-native as the host. Sep 07 20:43:00 pcmx-native is used to build pcmx. Sep 07 20:43:04 as bluelightning just said, create a pcmx recipe, let bbclassextend create -native and nativesdk- Sep 07 20:43:15 DEPENDS_class-target = "pcmx-native" Sep 07 20:43:33 davis: right, and that's fine - you just need to be using pcmx-nativesdk in TOOLCHAIN_HOST_TASK not pcmx-native Sep 07 20:44:37 of course you'll need to tidy up the -native naming of the recipe beforehand Sep 07 20:45:02 ok so I need to have a recipe named pcmx_%.bb Sep 07 20:45:21 in this recipe I'm going to have BBCLASSEXTEND = "native nativesdk" Sep 07 20:45:42 and then in my local.conf I'm going to have DEPENDS_class-target = "pcmx-native" Sep 07 20:46:02 ? Sep 07 20:46:06 why would you put depends in local.conf? Sep 07 20:46:12 and TOOLCHAIN_HOST_TASK += "pcmx-native" Sep 07 20:46:15 no, that goes in the pcmx recipe so the target one depends on -native Sep 07 20:46:26 hmm. Sep 07 20:46:26 and no, bluelightning just told you explicitly not to put -native in TOOLCHAIN_HOST_TASK, you use nativesdk there Sep 07 20:46:43 [13:43:33] davis: right, and that's fine - you just need to be using pcmx-nativesdk in TOOLCHAIN_HOST_TASK not pcmx-native Sep 07 20:48:10 * kergoth kicks the shallow git code repeatedly Sep 07 20:48:55 ok. i'll try to replay the notes and get it right again. i'm doing a build at the momemnt which I need to complete. Sep 07 21:03:13 Does the delay loop bogomips reported by the kernel correspond to the speed the processor is running? In my old kernel I have 999.42 bogomips which looks right considering it is a 1GHz processor but the same board on the new kernel I am working with it reports only 66.66 Bogomips. Sep 07 21:03:49 Trying to figure out if its just the schedule timer that is running at 33MHz now or if the whole processor is running slow because the kernel is not switching/setting clock frequencies right Sep 07 21:14:21 kergoth: bluelightning this is what I tried to do. It fails during parsing. https://gist.github.com/netskink/d51f1caf02157b580e2af10a3ace5b09 Sep 07 21:14:45 nativesdk is prepended to the name Sep 07 21:14:53 it's nativesdk-pcmx, not pcmx-nativesdk Sep 07 21:15:26 oh, sorry, that was my fault Sep 07 21:15:42 in history (almost ancient history by now) it used to be the other way around Sep 07 21:15:46 no worries Sep 07 21:16:02 i've made that change to gist and local.conf. lets see what bitbake does. Sep 07 21:17:41 hmm. Sep 07 21:18:47 its breaking in cmake now. it can't find gcc. Sep 07 21:20:19 when building which variant? Sep 07 21:20:54 i have an inherit native cmake line. I also do not have a depends line. perhaps I need to add depends=gcc Sep 07 21:21:14 its breaking durin g the nativesdk build do configure Sep 07 21:23:02 i added a depends=gcc and now, i see its building a nativesdk-gcc Sep 07 21:23:14 so this might work. Sep 07 21:23:53 that shouldn't be necessary Sep 07 21:24:08 gcc is a dependency by default unless you do something like INHIBIT_DEFAULT_DEPS = "1" Sep 07 21:24:50 I doubt that will fix it, nativesdk-gcc is the gcc that goes into the SDK, not the compiler used to build things for the SDK Sep 07 21:25:48 yah it did not Sep 07 21:26:14 previously i had the code building with cmake Sep 07 21:26:34 and my god that was an endevour Sep 07 21:28:33 usually if it can't find it it means it's somehow looking in the wrong place, because it is almost certainly where it should be Sep 07 21:29:06 I suspect you haven't built the nativesdk variant until now and if so that would account for this coming up now Sep 07 21:29:19 i probably have not. Sep 07 21:29:25 ive built the sdk Sep 07 21:29:36 would i say depends=nativesdk? Sep 07 21:30:11 well, i take that back. Sep 07 21:30:23 it had to be using the nativesdk when it was building for the host Sep 07 21:30:42 i was getting binaries in the x86_64 sysroot Sep 07 21:31:10 and then when i was building for the target it knew to use some of the files built for the host Sep 07 21:31:35 it just was not getting into the sdk when I did the populate_sdk command. Sep 07 21:31:38 native != nativesdk Sep 07 21:31:43 nativesdk uses a completely different toolchain Sep 07 21:31:51 ok Sep 07 21:32:49 depends=nativesdk also does not work. Sep 07 21:34:04 depends=nativegcc-sdk might Sep 07 21:34:33 err nativesdk-gcc Sep 07 21:35:32 nope. virtual:nativesdk pcmx do configure fails. the cmake compiler can not find gcc. Sep 07 21:38:00 i updated this gist to include the entire .bb file Sep 07 21:38:04 https://gist.github.com/netskink/d51f1caf02157b580e2af10a3ace5b09 Sep 07 21:41:35 you don't need to add gcc as a dep, it's there by default, as bluelightning said. check into their use of cmake to figure out why it's not finding it Sep 07 21:43:17 kergoth: you said this earlier. 16:43 < kergoth> DEPENDS_class-target = "pcmx-native" Sep 07 21:43:42 where is that line supposed to go? in local.conf? Sep 07 21:43:47 i told you this already Sep 07 21:43:58 you said pcmx needed the native binaries to run, that's how you make pcmx depend on pcmx-native Sep 07 21:44:04 and no, as i said earlier, it belongs inthe recipe Sep 07 21:44:09 yes, i was reading scrollback and ... Sep 07 21:44:09 but it's irrelevent to nativesdk Sep 07 21:44:20 that's for the target recipe, which *you* said needed the native tools to build Sep 07 21:44:47 yes, Sep 07 21:45:27 so when I get pcmx to build for the host again, I will use that perhaps in my image recipe for building the target version of pcmx? Sep 07 21:45:58 that really doesn't make any sense Sep 07 21:46:06 the image doesn't need to run pcmx Sep 07 21:46:23 if pcmx needs pcmx-native to build, then put the DPENEDS i gave you into the pcmx recipe Sep 07 21:47:11 i had a pcmx and a pcmx-native recipe. the pcmx-native was building to sysroot of x86_64 but not breaking the sdk build. Sep 07 21:47:25 pcmx and pcmx-native are both irrelevent to nativesdk. Sep 07 21:47:38 i removed the pcmx and pcmx-native recipes. Now I just have a single recipe pcmx_%.bb Sep 07 21:47:50 nativesdk is its own build, with its own toolchain Sep 07 21:47:56 it has similar layout as pcmx-native before. Sep 07 21:57:21 so i am repulling this code and buidling fresh. Sep 07 21:57:57 hopefully with the single pcmx file and not the pcmx and pcmx-native it will work. Sep 07 23:49:47 kergoth: bluelightning you folks here? Sep 07 23:50:55 fwiw, rather than building in x86_64-linux/pcmx its now in x86_64-nativesdk-oesdk-linux/nativesdk-pcmx so that sounds as expected. Sep 07 23:52:07 in the dir for where the source is located. it has a toolchain.cmake Sep 07 23:52:40 this file looks like it is wrong though. CMAKE_C_COMPILER is set to gcc. Sep 07 23:52:46 davis: I am yes Sep 07 23:52:58 that was ok for host builds (since it worked) Sep 07 23:53:26 but for this nativesdk build its probably needs to be gcc-native or something Sep 07 23:53:45 davis: well, that's not a recipe name, it's a command Sep 07 23:54:06 so gcc is expected to be in the PATH when cmake goes to check if it's there Sep 07 23:54:24 AFAIK that should be the case Sep 07 23:54:55 in my pcmx_%.bb file, I don't specify any variable overrides for cmake. Sep 07 23:55:04 nor should you have to Sep 07 23:55:06 I'm currently doing only this Sep 07 23:55:11 BBCLASSEXTEND = "native nativesdk" Sep 07 23:55:13 you could double-check by running bitbake -c devshell nativesdk-pcmx Sep 07 23:55:20 then run "which gcc" Sep 07 23:55:28 inherit native cmake Sep 07 23:55:33 oh wait Sep 07 23:55:36 ok good idea Sep 07 23:55:41 ok wait Sep 07 23:55:43 you *definitely* do not want "inherit native" Sep 07 23:55:56 not if you are also using BBCLASSEXTEND Sep 07 23:56:05 gotcha Sep 07 23:56:11 that's probably causing the issue here Sep 07 23:56:18 lets see what that does. ill do a clean before hand. one sec Sep 07 23:56:30 bitbake -c cleanall pcmx Sep 07 23:56:55 err, prolly s/pcmx/nativesdk-pcmx/ Sep 07 23:58:24 this looks like its working. Sep 07 23:58:28 nope Sep 07 23:59:10 it is failing in cmake build now Sep 07 23:59:16 this is understandable Sep 07 23:59:40 this cmake project is the bane of my existance and only serves as payment for my past sins. Sep 08 00:01:22 bluelightning: thanks for the help. I appreciate it. Sep 08 00:01:38 im going home for the day, i can pick up with the cmake again tomorrow. Sep 08 00:01:46 no problem, have a good evening Sep 08 00:02:08 when I got this code, it had screwed up dependencies and it seems as if its now a problem yet again. Sep 08 00:03:03 btw, before I go, if I do nativesdk, will bitbake be able to build some code using cmake and then be able to run this code as part of its build? Sep 08 00:03:29 i was able to do that when it was native and in the x86_64-linux work fs Sep 08 01:51:10 davis: if you need to do that it's best to rely on the -native recipe to build those and then depend on that **** ENDING LOGGING AT Thu Sep 08 02:59:58 2016