**** BEGIN LOGGING AT Fri Apr 25 02:59:58 2014 Apr 25 07:00:56 isn't the heartbleed-fix going to be done in dylan? Apr 25 07:01:26 ah, sorry Apr 25 07:02:01 found a post about it, and see that it is a backported fix Apr 25 07:04:36 koen: seems that fix has not made its way to Angstrom-distribution/oe-core. don't know if you are still the person to bother about this :) Apr 25 07:12:07 which is dylan? Apr 25 07:12:09 2012.12? Apr 25 07:13:34 2013.06 Apr 25 07:20:12 tasslehoff: angstrom 2013.06 has the heartbleed fix Apr 25 07:20:24 tasslehoff: not the backport, but an upgrade to 1.01g Apr 25 07:21:02 tasslehoff: https://github.com/Angstrom-distribution/oe-core/commits/angstrom-staging-yocto1.5 Apr 25 07:23:43 koen: 2013.06 is 1.4, not 1.5 Apr 25 07:23:48 I think Apr 25 07:24:33 still, it seems to be there as well. Apr 25 07:25:32 koen: gah. I looked in the dylan branch, not the angstrom-staging-yocto1.4 Apr 25 07:26:05 I wish everyone would use the same name, and I wish that name had a number in it Apr 25 07:30:03 tasslehoff: iirc I backported it to 2012.12 as well Apr 25 07:30:12 since that's why my internet router is running :) Apr 25 07:31:41 koen: yeah. it was the multiple "dylan"-branches that confused me Apr 25 07:38:24 yeah Apr 25 07:38:46 for v2013.12 we're going to try to leave all layers the same as upstream and up recipe overlays and bbappends in meta-angstrom Apr 25 08:40:16 nativesdk-file fails to configure in master Apr 25 08:40:53 here at least Apr 25 08:45:15 cleansstate seems to fix it though.. Apr 25 08:49:10 but I have to cleansstate, one package at a time.. Apr 25 09:07:52 When will the daisy branch be pushed to meta-openembedded? Does this usually wait until it's actually required to diverge from master? Apr 25 09:17:33 zibri: usually a few weeks Apr 25 09:22:42 morning all Apr 25 09:23:35 hey bluelightning Apr 25 09:27:17 koen: thanks. i find that it could be helpful to have that branch available from the start; not as much to think about for me as a user. "i need the daisy branch of the layers i use", but understand why you'd not want to push such a branch before it's necessary. Apr 25 09:33:04 what is the difference between the common targets meta-toolchain, meta-toolchain-sdk and meta-ide-support? Apr 25 09:33:06 ofile=${host_alias}-libtool Apr 25 09:46:26 koen: hey Apr 25 09:46:55 mago_: I think meta-toolchain-sdk is gone, in favour of bitbake -c populate_sdk Apr 25 09:47:42 mago_: meta-ide-support is just for the native bits needed for interacting with an IDE AIUI Apr 25 09:50:00 kroon: what was the error? Apr 25 09:51:08 anyone here know why automake through a native recipy would generate a configure file that is different from when running it in the console? Apr 25 09:51:53 if I diff the two configuration files, the one has a line that looks like this -> ofile=libtool Apr 25 09:52:08 if I diff the two configuration files, the one has a line that looks like this -> ofile=${host_alias}-libtool Apr 25 09:52:26 since host_alies is empty Apr 25 09:52:36 the scripts start to jam when they work on -libtool Apr 25 09:53:40 pompomJuice: I assume host_alias was meant to be substituted earlier Apr 25 09:55:19 yes Apr 25 09:55:35 somewhere in the ./configure process config.status is run Apr 25 09:55:56 inside config.status there is a line that tries to `rm -f -libtool' Apr 25 09:55:57 bluelightning, oh okay. I just built meta-toolchain-sdk (on dora). Mostly a bit confused what output I should expect from these targets. Does bitbake -c populate_sdk produce an SDK tarball/shell with the sysroot of ? Apr 25 09:56:11 which fails because it does not understand the -l switch Apr 25 09:56:31 bluelightning, and what exactly does meta-toolchain target produce? Apr 25 09:57:04 Autoconf 2.68 Apr 25 09:57:16 Autoconf 2.69 Apr 25 09:57:17 mago_: IIRC just an installable toolchain, with no headers/libs Apr 25 09:57:42 mago_: -c populate_sdk produces an SDK containing the toolchain and headers/libs based on the packages in the image Apr 25 09:58:31 pompomJuice: ultimately if you want to see how we are running configure you will need to look at run.do_configure under temp in the recipe workdir Apr 25 09:58:52 actually Apr 25 09:58:54 I found out now Apr 25 09:58:54 alright, so i do not have to bother with the "extraction of root filesystem" when using -c populate_sdk? Apr 25 09:59:07 two different versions of autoconf is at play Apr 25 09:59:35 angstrom yocto-1.5 somehow finds a 2.69 Apr 25 09:59:41 which generates the bug Apr 25 10:00:01 the interesting part is that it does not happen on another branch of mono Apr 25 10:00:12 so it's not just a bitbake environment issue Apr 25 10:00:13 mago_: I don't think so, no (is there a set of instructions you're reading where you're finding that requirement?) Apr 25 10:00:42 the ./configure in the do_configure file has been checked and is what I use in the console Apr 25 10:00:43 pompomJuice: perhaps autoconf in the sysroot vs. autoconf on your host machine? Apr 25 10:00:54 bluelightning, exactly Apr 25 10:01:11 pompomJuice: autoconf on your host shouldn't be being used Apr 25 10:01:20 looks like it is not Apr 25 10:01:32 hmmm, I'm seeing a failure in do_unpack, apparently it can't open the input file, has anyone seen failures like this before? Apr 25 10:01:50 it's on a very heavily loaded system, with two builds going from the same downlaods and sstate directories Apr 25 10:02:11 jackmitchell, if you choke your bandwidth that happens Apr 25 10:02:21 ah hah Apr 25 10:02:21 jackmitchell: perhaps sharing downloads dir isn't a good idea for that exact reason Apr 25 10:02:29 that could well be it Apr 25 10:02:43 im from africa, here we have no bandwidth. Happens all the time Apr 25 10:03:23 bluelightning, ok so what I have at the moment is the following: Apr 25 10:03:40 2.68 generates this -> ofile=libtoo Apr 25 10:03:42 2.68 generates this -> ofile=libtool Apr 25 10:03:54 2.69 generates this -> ofile=${host_alias}-libtool Apr 25 10:03:59 the second one is clearly wrong Apr 25 10:04:03 hmm, well the file seems to be there and it has it's .done Apr 25 10:04:20 the file might have garbage in it Apr 25 10:04:22 bluelightning: shared downloads dir is supported though, is it not? Apr 25 10:04:36 delete the file and download again Apr 25 10:04:41 it happens if the line is chokend Apr 25 10:04:52 choked* Apr 25 10:04:58 ok, I'll give it a go; the other build is currently building eglibc so I'll delete once that is finished Apr 25 10:05:08 onlyone bitbake at a time Apr 25 10:05:12 you will be reminded Apr 25 10:05:18 in fact Apr 25 10:05:25 these days boitbake does all the thinking for us Apr 25 10:05:55 I've always been under the assumption that you can run multiple builds in parallel? Apr 25 10:06:14 cannot see the point in that Apr 25 10:06:24 unless you have unlimited processor Apr 25 10:06:49 just time saving, kick two different builds off and come back later to have them both done Apr 25 10:06:59 I guess Apr 25 10:07:10 so much trashing though in the threds and io Apr 25 10:07:22 also one might have 4 unpacking tasks, while the other is doing 4 compile tasks Apr 25 10:07:33 yea that works Apr 25 10:07:36 or downloading tasks etc etc Apr 25 10:40:28 pompomJuice: "the line is choked" doesn't seem like a good reason for a failure like this Apr 25 10:41:49 jackmitchell: I'm not sure that sharing the downloads dir is a commonly tested case; if there is insufficient locking there you'll get races and the result might be something like what you're seeing Apr 25 10:47:42 I try to avoid having multiple builds downlaoding files :) Apr 25 11:01:33 bluelightning, yes, the instruction i was reading is at http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#extracting-the-root-filesystem Apr 25 11:02:49 mago_: ok, the answer is it depends - it gives the rationale in that exact section of the manual Apr 25 11:06:46 yeah, i noticed. although, i'm not exactly sure what the last bullet means, "You want to develop your target application using the root filesystem as the target sysroot"? When would you do that? Apr 25 11:07:15 if the SDK already ships with headers and libs that was put into the image in the first place Apr 25 11:20:01 mago_: I'm not much of an expert on the ADT I'm afraid Apr 25 12:15:42 bluelightning, about the configure errors, I kind of kept going on, I skipped looking at the actual errors in more detail. will do some proper investigation the next time it happens Apr 25 13:55:45 I notice that the following call is added to my do_configure -> autotools_do_configure Apr 25 13:55:52 how can I disable this behaviour? Apr 25 13:56:00 don't inherit autotools Apr 25 13:56:07 but I want autotools Apr 25 13:56:09 right Apr 25 13:56:11 the problem is Apr 25 13:56:16 so stop asking the wrong question :) Apr 25 13:56:17 Mono does not work on the standard way Apr 25 13:56:32 building mono from git requires a ./autogen -> make -> make install Apr 25 13:56:37 how does one achieve this then? Apr 25 13:57:01 I want the make and the make install to be handled by autotools Apr 25 13:57:19 but not the configure stage as mono has a custom maneuver for that part Apr 25 13:57:46 anyone know why doing enabling the dropbear ssh-server on core-image-minimal (using EXTRA_IMAGE_FEATURES in local.conf) breaks my shell login? I see that dropbear starts during boot, but when I try to login as "root" (no password, which has always worked before), I now don't even get to enter a password, and after a few seconds there is a login timeout. Apr 25 13:58:01 pompomJuice: does it actually use autotools, or not? Apr 25 13:58:08 uuhm Apr 25 13:58:09 no Apr 25 13:58:17 right, then it must not inherit autotools Apr 25 13:58:17 and I am not sure what inherit autotools do? Apr 25 13:58:27 you need to define your own do_configure and do_install Apr 25 13:58:28 does it only affect the configure stage? Apr 25 13:58:44 but I want the do install part that autotools provide Apr 25 13:59:07 does that mean I must copy the parameters to make in run.do_install and make my own manually? Apr 25 13:59:15 it's only oe_runmake install (+ perhaps some arguments), there's not a lot to it Apr 25 13:59:23 ok fair enough Apr 25 13:59:27 I know how Apr 25 13:59:28 il do that Apr 25 14:00:34 One other question Apr 25 14:01:13 if you dont inherit autotools, does your do_package stage automagically pick up the files that was installed by the install stage? Apr 25 14:01:19 yes Apr 25 14:01:37 how does bitbake know again what your staging area is? Apr 25 14:01:43 what variable Apr 25 14:02:05 do you mean where files should be installed into during do_install? Apr 25 14:02:11 if so, that's ${D} Apr 25 14:02:12 trying to compile llvm but it has a LLVM_INSTALL_DIR = "${WORKDIR}/llvm-install" Apr 25 14:02:15 aah yea Apr 25 14:02:26 thanks Apr 25 14:02:29 np Apr 25 14:02:39 ficing recipy... Apr 25 14:02:42 fixing* Apr 25 14:03:10 ok this is interesting Apr 25 14:03:29 basically, I am trying to make Mono 3.4 work on angstrom with llvm support Apr 25 14:03:47 mono suggests you use their mono/llvm repo Apr 25 14:04:00 I therefor copy the llvm recipies from oe-core, and modify Apr 25 14:04:42 those recipies all make the "make install" stage install to something that is not ${D}, how did they expect it was going to work then? Apr 25 14:05:00 anyway Apr 25 14:05:07 let me try to fix this Apr 25 14:09:53 ok I found the problem Apr 25 14:10:08 SYSROOT_PREPROCESS_FUNCS += "llvm_sysroot_preprocess" Apr 25 14:10:22 that fuction is not executing Apr 25 15:17:07 I'm having issues with building xterm and I think it might be to the new seperate build dir changes Apr 25 15:17:27 logfile: http://ix.io/bVj Apr 25 15:17:48 does anyone have any recommendations to what I can do to quickly test it without the build seperation? Apr 25 15:18:04 add it to the blacklist? Apr 25 15:18:10 SEPB or something Apr 25 15:18:16 there doesn't seem to be include autotools in the recipe, so I'm not sure I can do the autotools-sepbuild trick Apr 25 15:18:17 or set B to S Apr 25 15:18:35 it likely inherits it through the includes Apr 25 15:18:45 yeah, the include no longer exists... Apr 25 15:18:53 as far as I can tell Apr 25 15:19:04 ah I lie Apr 25 15:19:12 it's in oe-core, not meta-oe Apr 25 15:24:28 ok, that fixes it Apr 25 15:24:54 so I think the real problem is that gnu-configize --force is called in the wrong directory Apr 25 15:25:48 or some of the required sources don't get copied to the build directory, is B=S a valid solution or is there a better way? Apr 25 15:29:30 ok, so I hacked it a bit; is this valid or complete idiocracy Apr 25 15:29:41 http://ix.io/bVk Apr 25 15:30:07 in particular the 'cd ${S}' *do_stuff* 'cd -' Apr 25 22:21:06 CMoH|notebook: The image creation groups are: [['tar']] Apr 25 22:21:06 CMoH|notebook: Running image creation script for tar: /home/mhatle/git/oss/poky/build-tizen/tmp/work/qemux86_64-poky-linux/tizen-common-core-image-minimal/1.0-r0/temp/create_image.tar ... Apr 25 22:21:06 CMoH|notebook: Creating symlinks for tar image ... Apr 25 22:21:09 oops Apr 25 22:25:55 :) Apr 25 22:26:22 no idea why my client put your name on it.. but paste to the wrong window.. :/ Apr 25 22:26:35 np **** ENDING LOGGING AT Sat Apr 26 02:59:58 2014