**** BEGIN LOGGING AT Fri Jun 07 02:59:58 2013 Jun 07 06:20:20 morning all Jun 07 06:20:36 what is the swabber-report? Jun 07 07:54:52 good morning Jun 07 08:05:39 morning mckoan Jun 07 08:16:55 morning all Jun 07 08:24:56 hi bluelightning, silviof, all Jun 07 09:42:47 Hello everybody. I wonder why I failed to install mkfs.ext4 in my rootfs though I bitbaked e2fsprogs and I added it to IMAGE_INSTALL... Any comment ? Jun 07 09:43:58 vadmeste: possibly because mkfs.ext4 is in the e2fsprogs-mke2fs package Jun 07 09:44:41 morning all Jun 07 09:46:38 hi pb_ Jun 07 09:48:37 pb_: thanks you, it works, I thought it comes with e2fsprogs package because I found under the latter the mkfs.ext4 binary.. Jun 07 10:59:10 JaMa: re the buildhistory issue, should we use TOOLCHAIN_OUTPUTNAME instead of SDK_NAME in BUILDHISTORY_DIR_SDK? Jun 07 11:16:18 what is a/the swabber-report? Jun 07 11:20:48 bluelightning: let me check the value of them Jun 07 11:54:31 hi Jun 07 11:54:56 how to create sdk packages Jun 07 11:55:05 and how to run them Jun 07 11:58:31 bluelightning: what about IMAGE_BASENAME? Jun 07 11:59:12 bluelightning: in my test case SDK_NAME is the same and TOOLCHAIN_OUTPUTNAME includes DISTRO_VERSION (which will make it a bit harder to compare toolchain from older distro) Jun 07 11:59:21 meta-toolchain-efl.env:TOOLCHAIN_OUTPUTNAME="oecore-x86_64-arm920tt-toolchain-efl-2013.07-next-20130607" Jun 07 11:59:24 meta-toolchain-gmae.env:TOOLCHAIN_OUTPUTNAME="oecore-x86_64-arm920tt-toolchain-gmae-2013.07-next-20130607" Jun 07 11:59:27 meta-toolchain-efl.env:SDK_NAME="oecore-x86_64-arm920tt" Jun 07 11:59:29 meta-toolchain-gmae.env:SDK_NAME="oecore-x86_64-arm920tt" Jun 07 11:59:42 meta-toolchain-efl.env:IMAGE_BASENAME="meta-toolchain-efl" Jun 07 11:59:42 meta-toolchain-gmae.env:IMAGE_BASENAME="meta-toolchain-gmae" Jun 07 12:00:01 or BPN Jun 07 12:10:09 JaMa: don't we have to split between different architectures? Jun 07 12:14:19 seems like SDKNAME/IMAGE_BASENAME would cover all sides Jun 07 12:39:27 bluelightning: you're right, arch is also important Jun 07 12:43:31 pt: you can create a SDK with bitbake meta-toolchain, then in tmp/deploy/sdk you will get an 'installable' SDK archive. Jun 07 12:44:02 pt: alternatively, you can do bitbake -c populate_sdk to create a SDK that has all dev packages for Jun 07 14:04:39 Hi Jun 07 14:04:48 I have a kernel recipe looking like this : http://pastebin.com/hG4fdj6n Jun 07 14:05:39 When building it I do not get the kernel versoin I want. I get 3.10-rcX. Why is that? Jun 07 14:06:20 SorenHolm: where did you place it? what is your machine? Jun 07 14:07:58 mckoan: I placed it in my own layer. My machine is a intel x86 type machine, Jun 07 14:09:51 SorenHolm: add your COMPATIBLE_MACHINE Jun 07 14:10:20 mckoan: Ok, so that is a requirement now ? Jun 07 14:12:04 SorenHolm: if you don't set any PREFERRED_PROVIDER_virtual/kernel, yes Jun 07 14:15:10 mckoan: Well ... building the recipe explicitly using -b gives me a 3.10-rc kernel so the recipe build alright.. I'll try to add the COMPATIBLE_MACHINE flag and rebuild. Jun 07 14:31:56 configure: error: GnuTLS version predates gnutls_certificate_verify_peers2, newer version required Jun 07 14:32:06 I get that compiling neon-native :-/ Jun 07 14:34:19 rah: so it's your host gnutls it's complaining about I guess Jun 07 14:36:46 bluelightning: it's not the host's gnutls; the gnutls version reported by the configure script is the same as that installed under tmp-eglibc/ and also, there is no gnutls development package installed on the host Jun 07 14:38:17 7 Jun 07 14:38:30 /store/rah/phones/shr/shr-core-gta04/tmp-eglibc/sysroots/x86_64-linux/usr/lib/libgnutls.so: undefined reference to `asn1_read_node_value@LIBTASN1_0_3' Jun 07 14:38:48 most odd Jun 07 14:42:59 mckoan: Welll it still checks out 3.10 .... my log.do_fetch looks like this : Jun 07 14:43:21 http://pastebin.com/c64Q8re3 Jun 07 14:56:08 SorenHolm: which is your distro? which is your MACHINE ?= Jun 07 14:57:25 SorenHolm: are you sure about your SRCREV ? Jun 07 15:08:24 what package should I put license files in? Jun 07 15:10:07 mckoan: yup. Going into the .git dir that unpack creates and moving the master-branch to the v3.8.13 commit makes the correct kernel compile. Somehow the recipe is fixed at 'master' Jun 07 15:10:55 Crofton: ${PN}-doc ? Jun 07 15:11:42 WARNING: QA Issue: zeroc-slice: Files/directories were installed but not shipped Jun 07 15:11:42 /usr/ICE_LICENSE Jun 07 15:11:42 /usr/LICENSE Jun 07 15:11:48 ok Jun 07 15:11:59 trying to fix this Jun 07 15:12:12 Crofton: I'm not sure if it's applicable but we already have LICENSE_CREATE_PACKAGE for those who want a package containing the license files for every recipe Jun 07 15:12:40 I just want the warning to go away :) Jun 07 15:12:46 -doc sounds like a plan Jun 07 15:17:52 Crofton: those paths look wrong in any case... surely that can't be a good place for them to be installed? Jun 07 15:28:33 heh Jun 07 15:28:34 yeah Jun 07 15:28:45 I stuffed them in the -doc file Jun 07 15:28:50 which won't get installed Jun 07 15:29:11 the ice build system is based on some wacky makefile Jun 07 15:29:17 the pain Jun 07 16:18:21 rah: FWIW, I just built neon-native and haven't received that error here Jun 07 16:18:45 Is there a way to find the absolute path to a '.inc' file? Jun 07 16:19:10 I have a custom version of qemu_ver.bb, that has a require receipes-devtools/qemu/qemu.inc -- I want to know where that file is so I can add that path to the FILESPATHs Jun 07 16:19:44 (I know within the .inc you can, but I'm trying to do it externally).. (and simply avoid duplicating all of the code) Jun 07 16:20:38 rah, bluelightning: http://bpaste.net/show/105281/ Jun 07 16:21:19 probably only triggered with gold Jun 07 16:22:20 Epic: +PYTHON_INCLUDE_DIR ?= /home/build/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/include/python2.7 Jun 07 16:22:36 Do we have a var that points to the python in clide dir? Jun 07 16:23:02 yes Jun 07 16:23:26 fray: don't think so; you'd probably need to use COREBASE Jun 07 16:23:28 see openembedded-core/meta/classes/python-dir.bbclass Jun 07 16:23:51 I have three lines Jun 07 16:23:58 ya.. was wondering if I might need to either search BBPATH or just hardcode COREBASE Jun 07 16:23:58 Crofton: and gdb-cross-canadian iirc Jun 07 16:24:02 only have site paackages Jun 07 16:24:07 in this case, corebase is really easy Jun 07 16:24:22 (and I know it's the corebase dir I want) :) Jun 07 16:24:37 Crofton: -I${STAGING_INCDIR}/${PYTHON_DIR}/ Jun 07 16:26:37 hopefully I cna use that i the makefile Jun 07 16:26:54 people that write their own Makefiles suck Jun 07 16:28:30 you can set it in EXTRA_OEMAKE Jun 07 17:11:53 Are any of you kernel-recipe experts. Compiling linux-yocto_3.8 always gives me a 3.10 kernel. Why is that? Jun 07 17:50:05 sounds like you're not getting either the kernel recipe or version that you think you are... Jun 07 17:50:28 preferred_provider/version should take care of that Jun 07 17:51:55 eg, PREFERRED_PROVIDER_virtual/kernel = "linux-omap3" Jun 07 17:52:26 usually in your machine/include/foo.inc Jun 07 18:44:16 RP, are you going to poop if I send in a patch to enable c++ for berkely db? Jun 07 18:44:57 can it be a pkgconfig option? Jun 07 18:45:10 probably Jun 07 18:45:21 I think I am working on a recipe that needs it Jun 07 18:45:22 I've had people ask me about doing that before.. but having it enabled by default added a ton of buildtime and crud.. Jun 07 18:45:30 but pkgconfig would make it really slick Jun 07 18:45:59 what I do not want to do is have to add a bbappend in meta-oe Jun 07 18:46:02 (in the end nobody who asked me actually needed it though) ;) Jun 07 18:46:07 ya, I agree Jun 07 18:46:15 can I have a recipe get skipped if a pkgconfig option is not set? Jun 07 18:46:28 not that I know of Jun 07 18:46:49 it parses, just refuses to build Jun 07 18:46:59 I do not want JaMa bugging me Jun 07 18:48:02 I'm confused how it adds a ton of build time Jun 07 18:48:47 when I tried it (this was a few years ago).. it caused a bunch of additional runtime deps to be needed.. Jun 07 18:49:00 and of course polluted the environment with libstdc++ on the target.. (this was before oe).. Jun 07 18:49:05 probably pulls in a bunch of c++ deps Jun 07 18:49:05 it MAY be much better now Jun 07 18:50:01 * mr_science has slow fingers today Jun 07 18:50:01 there is a seperate -lc_xx Jun 07 18:50:11 -ldb_cxx Jun 07 18:50:22 maybe package that seperately Jun 07 18:51:27 so no equivalent to a portage use flag for optional build deps? Jun 07 18:51:36 pkgconfig Jun 07 18:51:49 you can adjsut deps Jun 07 18:52:11 got an example of that? Jun 07 18:52:40 i thought pkgconfig was mainly a way to get dynamic libs and flags Jun 07 18:52:56 http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb?h=master Jun 07 18:53:06 namespace overlap Jun 07 18:53:18 the layer search tool os awesome Jun 07 18:53:46 on cgit your mean? Jun 07 18:53:51 *you Jun 07 18:54:05 PACKAGECONFIG[uhd] = "-DENABLE_GR_UHD=ON,-DENABLE_GR_UHD=OFF,uhd," Jun 07 18:54:18 I used layers.openembedded.org to find the recipe :) Jun 07 18:54:55 ah Jun 07 18:55:16 fray, Jun 07 18:55:17 -DB5_CONFIG ?= "--enable-o_direct --disable-cryptography --disable-queue --disab Jun 07 18:55:17 +DB5_CONFIG ?= "--enable-o_direct --disable-cryptography --disable-queue --disab Jun 07 18:55:21 gar Jun 07 18:55:38 heh Jun 07 18:55:55 I had to add --enable-cxx to the config Jun 07 18:56:17 I think the configuration I was dealing with (back then) had cryptography -enabled-.. Jun 07 18:56:22 but otherwise that sounds familiar Jun 07 18:57:48 PACKAGECONFIG[foo] options seem a little weird at first glance Jun 07 18:59:54 i assume the "-DENABLE_GR_FOO=ON,-DENABLE_GR_FOO=OFF,foo," syntax is documented somewhere? Jun 07 19:03:52 I hope so :) Jun 07 19:04:05 autoconf-argument-if-set,autoconf-argument-if-unset,dependencies-if-set,rdepends-if-set Jun 07 19:04:23 if you wantt od os omething otehr than autoconf, you'd have to use ${@base_contains()} Jun 07 19:04:31 s/autoconf/configure/g Jun 07 19:04:56 its unlikely those -Ds are going to do what you expect, since it just adds those to the ./configure commandline Jun 07 19:07:42 i assume it's specific to gnuradio Jun 07 19:08:49 if i used that, i assume i could use it to enable/disable configure options Jun 07 19:10:26 yup, the -D's are cmake options, not -Ddefines Jun 07 19:10:39 in the gnuradio example... Jun 07 19:11:23 so i'll definitely try using that... Jun 07 19:12:38 Crofton: thanks for bringing that up while I happened to be paying attention... Jun 07 19:13:25 I am barely paying attention :) Jun 07 19:13:40 hey, no stealing my thing Jun 07 19:14:39 I gotta run Jun 07 19:16:54 thanks again, i actually learned something useful today... **** ENDING LOGGING AT Sat Jun 08 02:59:58 2013