**** BEGIN LOGGING AT Mon Jan 11 02:59:58 2016
Jan 11 15:10:48 <ericbutters> hi, for my target i have a nand flash layout using multiple partitions, is there a way to tell yocto to install rootfs to corresponding multiple archives?
Jan 11 15:20:08 <mtownsend1973> Whats the best way of including host tools like mkenvimage from u-boot into the SDK (-cpopulate_sdk)?
Jan 11 15:22:52 <fl0v01> ericbutters: i'm not an expert, but i would create different images for each partition
Jan 11 16:37:08 <ericbutters> ping kergoth
Jan 11 16:42:02 <khem> mtownsend1973: check out u-boot-mkimage recipe you have to add nativesdk-u-boot-mkimage to your SDK
Jan 11 16:43:11 <khem> ericbutters: you might want to look into wic
Jan 11 16:47:55 <ericbutters> khem: can you provide a link?
Jan 11 16:51:09 <mtownsend1973> khem: Thank you, I've copied that recipe and changed mkimage to mkenvimage.
Jan 11 16:58:28 <khem> ericbutters: http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#creating-partitioned-images
Jan 11 16:58:32 <ericbutters> khem: i looked into the RM, there is not much :) and yes maybe it can help me.. but anyone here that had the same idea/issue? splitting yocto rootfs into different parts to one can apply to corresponding flash partitions?
Jan 11 16:59:23 <khem> ericbutters: we have a custom solution which I dont like
Jan 11 16:59:26 <ericbutters> khem: oh! nice, thanks.. seems to be a good thing
Jan 11 16:59:50 <khem> it doesnt deal with many details e.g. update alternatives
Jan 11 17:00:02 <khem> and volatile binds
Jan 11 17:00:39 <khem> so wic is better and if it falls short then fix it
Jan 11 17:00:51 <khem> and upstream the patches
Jan 11 17:01:13 <ericbutters> okay, i will take a look into this.. if you have more info or good ideas please let me know :) thanks again
Jan 11 17:25:32 <janemba> hi
Jan 11 17:27:50 <nerdboy> ho
Jan 11 17:31:35 <janemba> ;)
Jan 11 17:33:57 <janemba> when running bitbake core-image-minimal I got the error "unable to determine endianness for architecture armv7l" so I add "armv7l": "endian-little bit-32 arm-commin arm-32" in siteinfo.bbclass but I got the exact same error
Jan 11 17:35:05 <nerdboy> that should be set by machine config
Jan 11 17:36:04 <janemba> how ?
Jan 11 17:38:02 <nerdboy> sorry, site info
Jan 11 17:38:40 <nerdboy> poky/documentation/ref-manual/ref-variables.xml <= try setting in local.con
Jan 11 17:38:49 <nerdboy> local.conf even
Jan 11 17:39:00 <janemba> ok
Jan 11 17:39:07 <nerdboy> SITEINFO_ENDIANNESS = "be"
Jan 11 17:41:21 <nerdboy> afaik tune_features should set it...
Jan 11 17:42:32 <challinan> exit
Jan 11 17:43:30 <janemba> hm...I tried SITEINFO_ENDIANNESS = "le" in local.conf but still with the same error
Jan 11 17:43:39 <janemba> I'm looking for tune_features
Jan 11 17:46:11 <janemba> hmmm there is no arch-armv7l.inc file is that a problem ?
Jan 11 17:50:57 <nerdboy> should be in arch-armv7a.inc
Jan 11 17:51:18 <nerdboy> SITEINFO_ENDIANNESS *should* take care of it
Jan 11 17:52:05 <nerdboy> but the variations within armv7 are handled as tune options
Jan 11 17:52:19 <nerdboy> at least they were last time i looked...
Jan 11 17:52:30 <janemba> hmmm
Jan 11 17:52:43 <benjamirc> halstead: you around?
Jan 11 17:53:57 <janemba> I can't find any armv7l in any inc files
Jan 11 17:54:07 <benjamirc> halstead: I sent you an email to your corporate account, I did that to your .org account but I failed to remember the address, according to mailman
Jan 11 17:54:23 <nerdboy> it's all v7afoo
Jan 11 17:54:49 <nerdboy> # Big Endian => AVAILTUNES += "armv7ab armv7atb armv7ab-vfpv3d16 armv7atb-vfpv3d16 armv7ab-vfpv3 armv7atb-vfpv3 armv7ab-neon armv7atb-neon"
Jan 11 17:56:14 <janemba> but armv7l is little endian
Jan 11 17:57:42 <nerdboy> take off the b
Jan 11 17:57:52 <nerdboy> same tunes without b are le
Jan 11 17:58:24 <nerdboy> several recipes check that value, eg, ${@base_conditional('SITEINFO_ENDIANNESS', 'le', '--with-endianness=little', '--with-endianness=big', d)}
Jan 11 17:58:42 <janemba> *** hm...I tried SITEINFO_ENDIANNESS = "le" in local.conf but still with the same error ***
Jan 11 17:58:47 <nerdboy> what is your machine name?
Jan 11 17:59:14 <nerdboy> you might need to clean some things and/or nuke /tmp
Jan 11 17:59:25 <janemba> ok lets try to nuke /tmp :)
Jan 11 18:08:18 <khem> janemba: arm default to LE in OE for BE you need to append is to arch part or triplet e.g. armeb
Jan 11 18:10:02 <khem> you must be missing proper tune arch in your machine conf
Jan 11 18:10:43 <janemba> khem: well I don't think the issue is endiannesss. The error said it can't find my arch in some file...
Jan 11 18:16:31 <khem> janemba: read my second comment
Jan 11 18:16:48 <khem> which machine are you building for ?
Jan 11 18:16:58 <khem> is it something your own ?
Jan 11 18:17:29 <janemba> khem: this is imx6 board
Jan 11 18:17:33 <janemba> *an*
Jan 11 18:18:05 <khem> from meta-fsl-arm ?
Jan 11 18:18:11 <khem> can you point to souces
Jan 11 18:20:15 <janemba> khem: this board -> http://tinyurl.com/j4mcnky
Jan 11 18:20:53 <khem> I meant to say point to BSP layer sources
Jan 11 18:21:14 <janemba> oh
Jan 11 18:25:49 <janemba> khem: from here http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/
Jan 11 18:28:06 <janemba> this branch imx-3.14.38-6UL_patch
Jan 11 18:36:41 <janemba> seems nuke fix it...
Jan 11 19:16:43 <khem> janemba: so its fixed ?
Jan 11 19:17:13 <janemba> khem: its still compiling but I think its fixed
Jan 11 19:17:35 <khem> ?
Jan 11 19:19:55 <janemba> I got the error right after bitbake command and it hasn't happened
Jan 11 20:14:54 * kergoth grumbles
Jan 11 21:09:35 * nerdboy untangles his beard...
Jan 11 21:10:11 <nerdboy> found some stale .bbappends
Jan 11 21:13:37 <armpit> so would that be .beardappends ?
Jan 11 21:23:47 <yann|work> I'm a bit a a loss, with a kernel's run.do_compile not containing any uboot_mkimage reference - that's a sunxi 4.4 I'm writing a recipe for based on the existing 3.4
Jan 11 21:25:01 <yann|work> noone seems to override KERNEL_CLASSES
Jan 11 21:30:34 <khem> yann|work: not clear as to what you are asking for
Jan 11 21:32:01 <yann|work> let's try to explain then :)
Jan 11 21:32:20 <khem> AFAIR mkimage is done in a separate task depending upon KERNEL_TYPE
Jan 11 21:32:32 <khem> KERNEL_IMAGE_TYPE
Jan 11 21:33:33 <yann|work> I'm trying to write a machine def for the OrangePi-Plus for jethro, and for this am trying to do that by building a linux-sunxi 4.4 (branch sunxi-next)
Jan 11 21:34:14 <khem> OK
Jan 11 21:34:27 <yann|work> I've simply based this on the recipe for 3.4 (just removed all patches)
Jan 11 21:34:28 <khem> then somewhere in your machine conf you might be setting KERNEL_IMAGETYPE
Jan 11 21:35:16 <yann|work> the machine conf is mostly copied from existing ones, so I supposed it would work - although I admit not checking first :>
Jan 11 21:35:40 <khem> if KERNEL_IMAGETYPE is set to uImage
Jan 11 21:35:47 <khem> then the task would kick in
Jan 11 21:36:41 <yann|work> include/sunxi.inc does set it
Jan 11 21:37:42 <yann|work> in fact something is working, as "make uImage" is run, but the problem is it should get LOADADDR= on the "make uImage" cmdline
Jan 11 21:38:25 <yann|work> and even kernel-uimage.bbclass does not do it that way (maybe it would work if it was really being used)
Jan 11 21:48:27 <khem> yann|work: are you setting UBOOT_LOADADDRESS in machine conf ?
Jan 11 21:50:12 <yann|work> khem: no, it is set in include/sunxi.inc as well, just not used (as shown by the typo in the value)
Jan 11 21:50:58 <yann|work> now just adding KERNEL_EXTRA_ARGS += " LOADADDR=${UBOOT_LOADADDRESS}" to the kernel recipe dies the trick as a workaround, but I'm not quite happy with it :)
Jan 11 22:07:02 <tripzero_> what causes "ERROR: BBCLASSEXTEND=imagevariant must be used with parameters, as in BBCLASSEXTEND=imagevariant:no-debug-tweaks,tools-profile"?
Jan 11 22:08:28 <seebs> So, bitbake idiom question.
Jan 11 22:09:10 <seebs> I want to have some bitbake code error out cleanly if a given value isn't in TUNE_FEATURES. I would like it to, ideally, produce a meaningful error message and cause things to abort because this code shouldn't have been included if that feature isn't available.
Jan 11 22:09:15 <seebs> Is there a reasonable idiom for this?
Jan 11 22:12:29 <kergoth> seebs: you'll have to determine just what you mean by 'error out' and when exactly you want it to error
Jan 11 22:13:01 <kergoth> e.g. if you do it immediately in inline python, it'd error at parse time, which is likely too early. or if you do it at ConfigParsed time, you' dhave hte metadata you need, but it'd also prevent bitbake -e from working
Jan 11 22:13:25 <seebs> Ugh, point.
Jan 11 22:13:42 <seebs> And I want bitbake -e to be able to work, if at all possible, but I want to prevent anything from actually being done, because any attempt to build would be Bad.
Jan 11 22:14:29 <seebs> More context: A thing which, if specified, would like to add compiler flags. The compiler flags are inappropriate for being part of a tune, but are only meaningful on a very small set of processors, and I'd rather blow up during sanity checks and stuff than let you build all the native/sdk stuff and THEN find out that your TARGET_CFLAGS are wrong.
Jan 11 22:14:31 <kergoth> i think the most common way of handling that sort of thing is to do it at BuildStarted time, or around there, and use bb.fatal. bitbake -e will succeed, but it'd error before any tasks start running
Jan 11 22:14:53 <seebs> Come to think of it: Maybe I should try to implement it as a sanity check.
Jan 11 22:14:56 <kergoth> of course sanity.bbclass has its own way of doing things, and there's a SanityCheck event that fires..
Jan 11 22:15:32 <seebs> Hmm, that might be the right thing. Add a handler for SanityCheck that does the quick check or fails.
Jan 11 22:16:09 <seebs> Okay, I like that. Thanks.
Jan 11 22:16:44 <kergoth> there are events for sanity success / failure, might want to fire the latter but not the former if it fails? *shrug*
Jan 11 22:16:52 <kergoth> np
Jan 11 22:22:05 <seebs> Not a bad idea, although I suspect a bb.fatal() is good enough for now. Probably.
Jan 11 22:47:51 <pericynthion> Hi - I'm getting started with development using Yocto and was wondering whether or not it's important to keep all the layers within the same source directory?  All the tutorials I've seen do it that way, but it seems to work OK to have some layers in different directories.  This would make it easier to manage the yocto portion of our broader project (which is contained in one large git repo and includes various non-embedded thing
Jan 11 22:49:55 <bluelightning> pericynthion: hey... no, it doesn't matter where you put them since you specify the full path to each one in bblayers.conf
Jan 11 23:09:16 <khem> pericynthion: why one git repo ? may be you can look at git submodules
Jan 11 23:09:23 <khem> its quite usable now a days
Jan 11 23:10:09 <khem> bluelightning: your pixz not supporting --disable-manpages option is a bit confusing
Jan 11 23:10:21 <khem> I wonder if its relatively a new option
Jan 11 23:10:23 <khem> let me check
Jan 11 23:13:00 <khem> bluelightning: ah
Jan 11 23:13:03 <khem> see https://github.com/vasi/pixz/commit/936d8068ae19d95260d3058f41dd6cf718101cd6
Jan 11 23:13:39 <khem> this commit is after 1.0.6 release
Jan 11 23:14:00 <khem> so that needs backporting
Jan 11 23:40:22 <bluelightning> khem: ah, I see
Jan 11 23:55:10 <wyrm> Any chance there's somebody lurking here who has their fingers in the dhpc package?
Jan 11 23:56:28 <Raj_> is anyone using IMX6 builds with gstremer
Jan 11 23:56:46 <Raj_> i am trying to compile and getting following errors
Jan 11 23:57:03 <Raj_> g++: error: unrecognized command line option ‘-mthumb’ g++: error: unrecognized command line option ‘-mfpu=neon’ g++: error: unrecognized command line option ‘-mvectorize-with-neon-quad’ g++: error: unrecognized command line option ‘-mfloat-abi=hard’ make: *** [src/configure] Error 127
Jan 11 23:57:17 <Raj_> any suggestions?
Jan 11 23:57:21 <wyrm> I'm having a problem with it that looks like a regression bug from fido to jethro. Or possibly dhcpd-4.3.1 to dhcpd-4.3.2, but I can only reproduce the bug with the bitbake'd dhcpd. If I compile it myself, it works fine.
Jan 11 23:59:22 <Raj_> @Darknight any suggestions?
Jan 11 23:59:46 <wyrm> Raj_: At a stab in the dark, I'd guess you might be using the wrong floating point type?
Jan 12 00:00:46 <Raj_> i have not seen this before g++: error: unrecognized command line option ‘-mthumb
Jan 12 00:02:28 <Raj_> i have following flags in makefile CFLAGS = -W -O0 -g -std=c++11 -pthread -mthumb  -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -ffast-math
Jan 12 00:03:07 <pumpernickel_> so...
Jan 12 00:03:10 <pumpernickel_> I was wondering...
Jan 12 00:03:44 <pumpernickel_> If I make a package that contains a static library, is there any way for me to get bitbake to add the -L to the built library?
Jan 12 00:04:01 <pumpernickel_> I assume there must be, but I've been having trouble identifying how.
Jan 12 00:04:14 <pumpernickel_> To formulate the question better:
Jan 12 00:06:12 <wyrm> Raj_: Try dropping -mthumb and see how that works for you.
Jan 12 00:09:02 <Raj_> it still fails for others g++: error: unrecognized command line option ‘-mfpu=neon’ g++: error: unrecognized command line option ‘-mvectorize-with-neon-quad’ g++:
Jan 12 00:10:29 <wyrm> Oh, hey. Are you compiling on your IMX6 board, or cross-compiling for that board?
Jan 12 00:10:46 <Raj_> cross compiling on UBUNTU
Jan 12 00:11:51 <wyrm> You need to call your tools with the appropriate prefix. arm-linux-gcc, arm-linux-g++, etc
Jan 12 00:12:24 <wyrm> or possibly arm-linux-somethingabisomething-*
Jan 12 00:13:14 <Raj_> let me try that
Jan 12 00:13:16 <Raj_> thanks
Jan 12 00:14:11 <wyrm> Once you find the right one, you can use...
Jan 12 00:14:24 <wyrm> export CROSS_COMPILE=arm-linux-whatever-
Jan 12 00:14:43 <wyrm> and that'll set the prefix for you.
Jan 12 00:15:07 <pumpernickel_> I build libA.a, and I want libB.so to link it into it. What is the proper way to pass the linker path to libA.a?
Jan 12 00:15:42 <Raj_> @wyrm, Thanks a lot
Jan 12 00:19:49 <wyrm> pumpernickel_: ld -o <output_file> <object_file>.o -L<path_to_library> -l<name_of_library>
Jan 12 00:21:18 <wyrm> Note that the library file itself must be named lib<name_of_library>.a, but the argument to ld is just <name_of_library> without the lib- prefix or .a suffix.
Jan 12 00:21:26 <pumpernickel_> wyrm: Thanks for your help in advance. I understand the syntax of how to link the library.
Jan 12 00:21:39 <pumpernickel_> The problem is getting that pesky -L argument into my makefile.
Jan 12 00:21:53 <pumpernickel_> I'm not sure the proper path to use, since the static library isn't put onto the target.
Jan 12 00:22:27 <pumpernickel_> Actually, I take that back, it *does* put the libA.a onto the target.
Jan 12 00:22:36 <pumpernickel_> The problem I'm having is that it still doesn't find it.
Jan 12 00:23:03 <pumpernickel_> I had thought that --sysroot to the compiler would have made /usr/lib a search path for static libraries as well, but it doesn't seem to be the case.
Jan 12 00:23:29 <wyrm> Is there a priority conflict? I mean, is the compiler finding another library of the same name first?
Jan 12 00:23:34 <wyrm> Or, linker, rather.
Jan 12 00:24:35 <pumpernickel_> Sorry, double-checking that I'm not accidentally putting the full-name in my Makefile.
Jan 12 00:25:09 <pumpernickel_> For ease of use to the other developers here, I had to write Makefile infrastructure to make it appear more like Android.mk (make of that what you will.)
Jan 12 00:25:20 <pumpernickel_> So it's a bit abstract.
Jan 12 00:32:23 <pumpernickel_> Hmm, perhaps my misunderstanding comes from the gnu toolchain.
Jan 12 00:32:47 <pumpernickel_> In the past, I've been able to link static libraries without specifying the trimmed down name.
Jan 12 00:32:55 <pumpernickel_> Though I admit, I'm using g++ to do the link step.
Jan 12 00:33:55 <pumpernickel_> something akin to
Jan 12 00:34:19 <pumpernickel_> g++ libA.a  b.o  -o libB.so
Jan 12 00:40:46 <pumpernickel_> Although, I suppose this is more accurate: g++ b.o libA.a -o libB.so
Jan 12 00:41:00 <pumpernickel_> Since in that scenario, the implication is that b.o depends on libA.a
Jan 12 00:43:39 <pumpernickel_> wyrm: Sure enough, you were correct! Thanks again for your help.
Jan 12 00:44:36 <pumpernickel_> I suppose if I don't pass it as -lLibName, it doesn't search the same paths, and must just assume that it's in the local directory.
Jan 12 00:44:40 <pumpernickel_> Stupid mistake on my part.
**** ENDING LOGGING AT Tue Jan 12 02:59:59 2016