**** BEGIN LOGGING AT Wed Aug 14 02:59:59 2013 Aug 14 06:01:07 hi everyone, I am writing a recipe for the qhull library (qhull.org) and this software has a own special open-source license, and now I am wondering what should be put in the recipe as LICENSE? Google and searching through the documentation did not give me a hint. Should I just invent a name (like qhull-LICENSE) or is there a standard string to indicate special licenses? Aug 14 06:19:03 lukas-bulwahn: I think you can choose a descriptive name like you suggest Aug 14 06:19:39 lukas-bulwahn: I grepped through poky metadata and found things like ttf-bitstream-vera_1.10.bb:LICENSE = "BitstreamVera" Aug 14 06:20:21 thanks a lot--I just wanted to make sure that this is common practice. Aug 14 06:20:26 libpng has a license called libpng too Aug 14 06:20:34 so just name it qhull Aug 14 09:23:17 morning all Aug 14 09:37:08 hi. i have a component using a custom makefile that expects some env variables to be set prior to calling make. also, this component supports multiple config and it's expected to have a .bbappend to customize this env variables. what's the most elegant solution for dealing with that? how can i set vars in .bb which will be available in makefile? Aug 14 09:37:56 i was thinking about making a do_compile_prepend function, but then how can i tweak it from .bbappend? Aug 14 09:38:37 is there a mechanism to tell which 'recipe' vars need to be exported in Shell? Aug 14 10:34:15 ndec: you could set the variables within the recipe (outside of a function) and then export the variables in the do_compile_prepend (could even name the variable differently outside of the function and export the real name within do_compile_prepend) Aug 14 10:34:39 ndec: btw I am having trouble reproducing the devshell failure Aug 14 10:35:41 hmm, now it fails :/ Aug 14 10:35:48 spoke too soon apparently Aug 14 11:06:45 khem: Hi, did you remove extra python recipes from kraj/python3? now it shows only main python recipe Aug 14 11:13:22 bluelightning: ah, thanks for the suggestion. that's what i need indeed. i can even add the exports in do_compile, since i have that function. Aug 14 11:13:37 bluelightning: for the devshell, let me know if you want me to test anything. Aug 14 11:14:55 hi all Aug 14 11:15:27 hi pb Aug 14 11:18:47 morning woglinde Aug 14 11:19:17 heh, what sort of lunatic is still using reiserfs? Aug 14 11:20:19 one with a murderous rage? Aug 14 11:21:00 I was not going to comment on that thread that there is a reason reiser4 has never merged into the kernel, it just doesn't work! Aug 14 11:22:39 pb_: :) Aug 14 11:23:27 XorA: it worked fine few years ago and now there is updated patch for latest kernel :) Aug 14 11:23:53 JaMa: if by "worked fine" you mean randomely hoses all your data, I will agree with you :-D Aug 14 11:24:21 JaMa: I always found OE builds brought reiserfs to its knees Aug 14 11:25:46 I've stopped using it after it hosed all my data twice after unclean shutdown from power loss Aug 14 11:26:03 but other than that it was quite fast for working with many small files Aug 14 11:27:07 so its quite fast by not actually writing data, see my issue with that ;-) Aug 14 11:31:29 :) Aug 14 12:12:45 so if I see SOC_FAMILY in a bsp I should replace that with a MACHINEOVERRIDES .=":socname" ? Aug 14 12:36:28 is OE/bitbake doing anything special with CFLAGS? i am making a recipe for a component with a custom makefile that plays with CFLAGS, and I have the feeling that any change in CFLAGS done in the makefile are simply ignored. Aug 14 12:36:40 it sounds like something obvious, which for some reasons, i don't see... Aug 14 12:38:51 ndec: variables passed into make override those set in Makefiles Aug 14 12:39:16 argh... got it... oe_runmake does -e ;-) Aug 14 12:39:33 XorA: yep, that's it. Aug 14 12:57:14 XorA, is there real arm64 hw yet? Aug 14 12:57:30 Crofton|work: yes, I saw it at Connect Aug 14 12:57:39 Crofton|work: from APM Aug 14 12:57:39 ndec: just trying to figure out what's missing since that patch is in master and works there Aug 14 12:57:46 we need to show OE running on it :) Aug 14 12:57:52 as in do builds :) Aug 14 12:58:43 Crofton|work: has anyone tested ARM/ARM build already? Aug 14 12:58:56 i meant ARM for HOST. Aug 14 12:59:39 bluelightning: if you diff the 2 run_do_terminal that i sent, most of the diff are about pseudo and LD preload. Aug 14 12:59:45 that can be a hint.. Aug 14 13:00:14 dunno Aug 14 13:00:22 I have no arms that I could run OE on Aug 14 13:03:48 hrw: ^ i think we discussed about that together. don't remember if you ever tried that ! Aug 14 13:04:17 Crofton|work: everybody has qemuarm ;-) Aug 14 13:04:26 true Aug 14 13:06:33 I've never got into emulators much Aug 14 13:19:49 that reminds me, I am wondering if it is worth adding some generic machine confs to oe-core Aug 14 13:20:06 that build filesystems, without caring about the kernel etc Aug 14 13:21:22 Crofton|work: +1, that's one thing we have in meta-linaro. Aug 14 13:21:48 https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=tree;f=meta-linaro/conf/machine;h=21cb9e072a786c34d15117d8f348c6636e7beba5;hb=ca98091c55be8d695cdf59bf59910e56deb977dd Aug 14 13:21:50 most of us know just to do a qemu build Aug 14 13:22:17 heh, but the qemu in core is armv5 :) Aug 14 13:22:34 well, support for armv7 qemu would be nice too. Aug 14 13:23:01 i use qemuarm a lot, but then when going to real h/w we use armv7... so it's a complete rebuild. Aug 14 13:24:34 that one builds a kernel though :) Aug 14 13:28:04 Crofton|work: yes, i know. i use qemuarm to test locally what i build, so i do run through qemu for real. but i would prefer to run through a v7 qemu, so that i could share package feed with real h/w Aug 14 13:29:41 Crofton|work: need to beat people to make some Exynos5 boards with decent RAM on them, it supports LPAE Aug 14 13:29:46 I think the real answer to my question is add more qemu-arm targets :) Aug 14 13:30:47 and the headache is more machines in oe-core increases autobuilder test time Aug 14 13:32:55 ah runqueue looks healthier when you dont forget to update conf/local.conf Aug 14 14:06:59 anyway, did anyone see my question about repalcing SOC_FAMILY with MACHINEOVERRIDES? **** BEGIN LOGGING AT Wed Aug 14 16:42:31 2013 Aug 14 22:48:19 well, that's not a good start for my custom sdk build... Aug 14 22:48:44 m4-native failed Aug 14 22:54:51 heh, ouch Aug 14 23:00:05 just can't figure out why it needs a gets warning patch... Aug 14 23:01:42 easy fix, but why? Aug 14 23:01:50 * mr_science scratches head Aug 14 23:40:51 looks good for a sfew seconds, then libtool-cross fails... Aug 14 23:44:56 looks like it's mixing vfp instructions when it shouldn't Aug 14 23:45:10 so i guess i missed one of the config bits? Aug 14 23:58:46 nope, afaict all the config bits are correct Aug 14 23:59:20 gcc flags have neon/hardfp but somehow libtool gets confused Aug 14 23:59:37 who'd a-thunk it... Aug 15 02:36:07 okay, another quirk... Aug 15 02:41:45 the default softfp builds fine (with Sourcery G++ Lite 2009q1-203) and uses libtool-cross-2.2.6b-r28.1 Aug 15 02:42:31 trying to build the sdk hardfp fails... Aug 15 02:43:06 the libtool-cross configure thinks the C compiler can't create executables Aug 15 02:43:36 do i need to swap put the external toolchain first? Aug 15 02:43:49 *swap out even **** ENDING LOGGING AT Thu Aug 15 02:59:59 2013