**** BEGIN LOGGING AT Fri Jan 20 02:59:57 2012 Jan 20 14:10:11 kergoth: ping? Jan 20 15:36:44 RP__: pong Jan 20 15:37:29 kergoth: I was having trouble with python namespaces and importing classes from lib/oe but with some help from bluelightning got it figured out about 5 mins ago! :) Jan 20 15:37:52 kergoth: I've been running into that parsing issue again though, did you have a patch series to submit for that? Jan 20 15:39:36 I haven't had a chance to revisit investigating the deadlock I was hitting with the homerolled process pool. I have a version on my github that uses the pulled in futures/concurrent.futures module, that's about it. Would need more time to try to fix the other solution. Jan 20 15:40:03 swamped at work lately, over half my team is being pulled onto other projects recently :| Jan 20 15:41:25 see https://github.com/kergoth/bitbake/compare/parsing-fix-futures and https://github.com/kergoth/bitbake/compare/parsing-homerolled-wip Jan 20 15:42:49 kergoth: how about pulling in the futures version? Jan 20 15:43:23 that seems like a fine first step, can always remove the dep later on Jan 20 15:44:57 kergoth: agreed Jan 20 15:46:04 I hate doing that, because it seems so rare that we find time to go back and do the final polish or whatever, but in this case it's a pretty annoying bug and neither of us has much time nowadays Jan 20 15:46:09 heh Jan 20 15:46:37 kergoth: FYI I'm seeing issues with the siggen code in bitbake. We really need an OE specific version of it. Trouble is doing it without a bitbake version dependency. Obviously it can be done without that but its so ugly I'm thinking we might need to bump OE's min bitbake version Jan 20 15:47:05 kergoth: The parsing hang is annoying enough and easy enough to trigger I think we need to fix it with whatever we have Jan 20 15:47:10 * kergoth nods, doesn't seem unreasonable Jan 20 15:47:11 agreed Jan 20 15:47:43 even a traceback would be better at this point, a *silent* hang is something the user will have no idea how to even start investigating Jan 20 15:47:46 heh Jan 20 15:47:50 * kergoth goes to get food Jan 20 16:48:36 zeddii: you around? I am having a "do_validate_branches" issue again Jan 20 16:50:51 here. I have a meeting in 10mins though. on master or edison ? Jan 20 19:12:40 zeddii: sorry did not see your reply, this is against master a clean world build! Jan 20 19:16:53 sgw. definitely not seeing it here. there's been no changes that would trigger a validate branch failure. what's the last thing you merged from me ? just the addition of the ${WORKDIR} in the patch phase. Jan 20 19:17:44 Right, this is a clean master Jan 20 19:18:15 zeddii: I even did a cleanall and refetched, this is the commit it's looking for 9e73573b6b227ab2c62e66e63470866d136f8d76 Jan 20 19:19:59 lemme check. Jan 20 19:21:10 sgw. I see that in my clones. right on the top of qemux86's branch Jan 20 19:21:17 I'll check the cgit interface. Jan 20 19:22:18 I see it also, when I go into the $WORKDIR/linux I am on the yocto/standard/common-pc/base branch and when I try to do a log on that ref, I get a bad object! Jan 20 19:23:25 yah. that's a 10 day old commit. Jan 20 19:23:29 is something feeding a bad tree ? Jan 20 19:24:16 That's my next guess, I am going clone from my downloads area and check and then do another cleanall Jan 20 19:26:48 ok Jan 20 19:26:51 I'll be around. Jan 20 19:29:00 zeddii: Ok, what's the difference between the linux-yocto-3.0.git and linux-yocto-3.0 directories, cleanall removed the -3.0, but not the -3.0.git version Jan 20 19:30:43 the .git is your local bare clone. that's the same as what we have up on git.yoctoproject.org, the non bare clone is only needed if you are doing actual work on the kernel. Jan 20 19:38:40 zeddii: then I am still confused, the -3.0 is what got cleaned and repopulated when I did a cleanall/fetch, I have to go for my swim, back at 1:30 Jan 20 19:41:05 sgw. your SRC_URI is pointing at the wrong one then, if you are using meta-kernel-dev. I'm adding a check that will error out of that's the case. Jan 20 20:52:33 nitink: around ? Jan 20 20:52:46 khem: yes Jan 20 20:52:58 nitink: with commit 936a73eae5fd5732c9dc5ae2a47d6196f7f69c0a you added --with-libelf=${STAGING_DIR_TARGET} to gdb configure Jan 20 20:53:14 do you remember which gdb failed to configure without it ? Jan 20 20:54:21 dependency on libelf looks incorrect to me Jan 20 20:54:35 khem: it must have been for gdb 7.1 Jan 20 20:54:44 as that commit is upgrading to that version Jan 20 20:54:57 I want to disable it Jan 20 20:56:11 khem: if gdb continues to build without libelf change, then that is fine Jan 20 20:56:50 since it was in common parts I cant figure if you had issues in all gdb or one particular like gdb-cross or gdb or canadian Jan 20 20:56:58 as per log gdb configure was failing, hence it was added Jan 20 20:57:10 so target gdb ? Jan 20 20:57:21 khem: I do not remember which gdb Jan 20 20:58:03 khem: from log looks like: one of these gdb, gdb-cross & gdb-cross-canadian Jan 20 20:58:16 heh are there more :) Jan 20 20:59:08 khem :) Jan 20 21:00:30 ok what I can see is that 7.3 is building fine on target Jan 20 21:00:35 without libelf Jan 20 21:04:47 khem: cool then you can drop libelf requirement Jan 20 21:05:24 yeah I am building canadian version those are the ones that can have such requirements others seem to build ok Jan 20 21:21:56 RDEPENDS: removed "external-csl-toolchain 4.5.2)" added "eglibc 4.6.2+svnr181430)" - heh, not sure the buildhistory analysis is splitting rdeps properly Jan 20 21:56:37 zeddii: Just to followup, my SRC_URI is the default, unless mirroring is doing something strange. Jan 20 22:27:17 khem or nitink: I have a question about which .a files belong in -dev package vs -staticdev for standard builds. I think the following need to be in -dev: /usr/lib/libc_nonshared.a /usr/lib/libpthread_nonshared.a, /usr/lib/libssp_nonshared.a, libgcc.a Jan 20 22:28:23 khem, nitink: I am not sure about libgcc_eh.a and libgcov.a (I think they belong in -dev), there are also the libstdc++.a and libsupc++.a, which I am less sure about. Jan 20 22:30:13 sgw: I think khem can answer better than me here Jan 20 22:30:52 nitink: thanks Jan 20 22:31:09 nonshared.a are needed in .dev Jan 20 22:31:40 others can go into staticdev Jan 20 22:32:11 khem, thanks, are you sure about the libgcc.a, I thought that was also a special case Jan 20 22:33:06 oh right actually libgcc.a should go into libgcc itself Jan 20 22:33:11 not even dev Jan 20 22:33:35 hmm well -dev Jan 20 22:33:46 it should go into libgcc-dev Jan 20 22:34:18 khem, what about the other 2 static libs in libgcc-dev? Jan 20 22:34:57 which ones ? Jan 20 22:35:09 libgcov.a libgcc_eh.a Jan 20 22:35:57 libgcov.a should be in libgcov-dev Jan 20 22:36:36 libgcc_eh.a should be in libgcc-dev Jan 20 22:37:15 do we package libgcov separately ? we better do Jan 20 22:37:50 Any binutils or libc++ special cases that you know of? I will add a package for libgcov-dev Jan 20 22:39:45 no they should be all normal Jan 20 22:40:03 khem, great thanks for helping confirm Jan 20 22:40:48 khem, can I ask you to make sure that uclibc is packaged correctly Jan 20 22:44:20 yes I will look into it. Generally it should be fine Jan 20 22:45:20 khem: Ok thanks Jan 20 22:47:20 hmm now that I see Jan 20 22:47:40 there are some .a in uclibc-dev that should move into corresponding staticdev Jan 20 22:48:43 libdl.a libm.a libnsl.a libpthread.a libcrypt.a libresolv.a librt.a libuargp.a libubacktrace.a Jan 20 22:52:52 same set that is in eglibc, I am working on moving those now. Jan 20 22:55:39 yeah its was a greedy regexpt in uclibc Jan 20 22:55:44 I took care of that **** ENDING LOGGING AT Sat Jan 21 02:59:57 2012