**** BEGIN LOGGING AT Thu Dec 19 02:59:59 2013
Dec 19 04:19:15 <chrisw95x> How can I remove something from MACHINE_FEATURES without resorting to editing the machine conf file?  Is there an equivalent from EXTRA_MACHINE_FEATURES for removing?
Dec 19 07:12:35 <tasslehoff> koen: morning. I've run into http://pastebin.com/KhEKdb4F again. you said I needed to get new binaries from TI, but I suspect that I can't for 4.05.00.03. 
Dec 19 07:12:56 <tasslehoff> do you know which commit(s) I can revert to get a working build again?
Dec 19 07:20:38 <nerdboy> can you filter out the vfp flags ?
Dec 19 07:38:33 <tasslehoff> nerdboy: filter them out, as in checking what they are?
Dec 19 07:39:56 <koen> tasslehoff: you can't turn of hardfloat, it wouldn't be angstrom anymore if you do
Dec 19 07:40:04 <koen> since it will break binary compatibility
Dec 19 07:46:40 <tasslehoff> koen: which layer had the recent vfp "detection" changes?
Dec 19 07:51:27 <koen> the angstrom layer
Dec 19 07:51:40 <koen> stick with v2012.12 if you need softfp
Dec 19 07:52:02 <tasslehoff> koen: has beagleboard been using hardfp all along?
Dec 19 07:52:36 <koen> v2012.12 and earlier releases used softfp for ARM based boards
Dec 19 07:52:59 <koen> v2013.06 and up use hardfp for armv7a
Dec 19 08:03:38 <tasslehoff> koen: if beagleboard C3 can run hardfp I have no reason to run softfp
Dec 19 08:05:21 <koen> right, but no 3D for you, since the hardfp evil binary for the sgx stuff doens't support 3530
Dec 19 08:09:32 <ndec> koen: any idea when/if hardfp blobs will be available? that's kind of lame that the default distro for beagle can't run well on beagle because of that.. the PVR drivers work very well with hardfp, they just need to be built..
Dec 19 08:10:15 <tasslehoff> koen: softfp it is then, since 3D is a must-have
Dec 19 08:11:05 <koen> http://tigraphics.blogspot.nl/2013/11/4q-2013-linux-graphics-sdk-release.html
Dec 19 08:11:33 <koen> you can hexedit the headers of the softfp ones if you want to
Dec 19 08:11:38 <koen> since it's integer-only code
Dec 19 08:11:54 <koen> the meego people did that a few years ago
Dec 19 08:13:29 <tasslehoff> koen: if I just compile with softfp, will it not work, or will you just not support me? :p
Dec 19 08:13:43 <koen> both
Dec 19 08:13:53 <tasslehoff> I think I reverted the "use hardfp" commit once before, and it seemed to work fine
Dec 19 08:14:14 <tasslehoff> on a console-image with qt5-embedded.
Dec 19 08:17:52 <tasslehoff> koen: any resources I can read up on to understand what will not work and why? 
Dec 19 08:19:18 <tasslehoff> the headache is that I've been following v2013.06, and going back to v2012.12 is not tempting. since v2013.06 seems to work fine for me compiled with softfp (and this is the final release for us on this platform) it is tempting to do it if the risks are not big.
Dec 19 08:45:33 <tasslehoff> koen: perhaps I can lock the v2013.06 layers to a date before the softfp->hardfp change?
Dec 19 08:53:07 <tasslehoff> or, perhaps I do not benefit much from running Angstrom since I have a console image only?
Dec 19 08:53:14 * tasslehoff just keeps talking
Dec 19 09:53:50 <bluelightning> morning all
Dec 19 09:58:48 <koen> hey bluelightning 
Dec 19 09:59:13 <bluelightning> hi koen
Dec 19 12:11:41 <Crofton|work> I woke up and still have rpath headaches in lidbc++ :(
Dec 19 12:12:29 * Crofton|work rads scrollback
Dec 19 12:12:45 * Crofton|work curses this mornings coffee fail
Dec 19 12:33:11 <Crofton|work> can someone remind me how I would do this in the db recipe?
Dec 19 12:33:13 <Crofton|work> <mr_science> what about something like "export ac_cv_hardcode_action=unsupported" ?
Dec 19 12:35:03 <Artox> Crofton|work: I think you expand (or make) a function do_configure_prepend
Dec 19 12:35:08 <Artox> and just put it inside
Dec 19 12:35:13 <Artox> but I am not completely sure
Dec 19 12:35:39 <Crofton|work> looks like adding to EXRA_OECONF
Dec 19 12:38:49 <Crofton|work> #fail
Dec 19 13:14:43 <Crofton|work> any suggestios for extreme rpath qwa issues?
Dec 19 13:16:44 <koen> which m4 is adding the rpath?
Dec 19 13:16:49 <koen> find that and patch/sed it
Dec 19 13:16:59 <Crofton|work> db
Dec 19 13:17:03 <Crofton|work> can't rebuild configure
Dec 19 13:17:38 <Crofton|work> hmmm a clue
Dec 19 13:20:07 <Crofton|work> crap
Dec 19 13:26:11 <Crofton|work> seding the offending rpah out od the Makefile led to failed to instal .lai file
Dec 19 13:27:47 <koen> can you pastebin your recipe/patch?
Dec 19 13:33:21 <Crofton|work> http://pastebin.com/qXrryj2b
Dec 19 13:33:28 <Crofton|work> middle part of the oe-core db recipe
Dec 19 13:36:18 <Crofton|work> I am going to patch configure
Dec 19 13:38:46 <koen> shouldn't that be CAHCE_CONFIGUREVARS or something?
Dec 19 13:39:46 <Crofton|work> dunno
Dec 19 13:40:07 <Crofton|work> I am in the phase of making wild guesses
Dec 19 13:40:56 <bluelightning> CACHED_CONFIGUREVARS +=
Dec 19 13:41:25 <Crofton|work> I just copied that form from an apacahe recipe
Dec 19 13:43:15 * koen is so happy for this to be the last workday of the year
Dec 19 13:43:21 <Crofton|work> +1
Dec 19 13:43:33 <koen> everywhere infrastructure broke because things have been fixed properly
Dec 19 13:43:43 <koen> so I'm doubly annoyed
Dec 19 13:43:48 <koen> first at the breakage
Dec 19 13:43:50 <Crofton|work> is this good or bad long term
Dec 19 13:44:03 <koen> then annoyed at myself for being annoyed at changes for the good
Dec 19 13:44:38 <koen> Crofton|work: in the OE case, angstrom distro configs can shrink a bit to remove workarounds
Dec 19 13:45:14 <koen> in the work case, my scripts can ditch a lot of special casing
Dec 19 13:49:26 <Crofton|work> change always sucks, even when it is for the best
Dec 19 13:50:41 <koen> "they moved of my lawn, now my automatic rocket launcher can't get at them youths"
Dec 19 14:04:59 <Crofton|work> clues on forcing this to a value?
Dec 19 14:05:00 <Crofton|work> _LT_TAGVAR(hardcode_action, $1)=
Dec 19 14:07:15 <Crofton|work> does not appear in an AC_CACHE_CHECK block
Dec 19 14:07:17 <Crofton|work> :(
Dec 19 14:14:08 <koen> ah, libtool joy
Dec 19 14:16:54 <Crofton|work> yeah
Dec 19 14:17:11 <Crofton|work> and the joy of configure scripts you cannot rebuild
Dec 19 14:18:41 <koen> in those cases I sed the resulting makefiles in do_configure
Dec 19 14:22:35 <Crofton|work> that led to failed to instal .lai file :(
Dec 19 14:23:44 <koen> how do you sed it?
Dec 19 14:24:13 <koen> crazy idea
Dec 19 14:24:22 <koen> can you add libtoolize --force to do_configure?
Dec 19 14:25:43 <Crofton|work> what will that do?
Dec 19 14:27:32 <koen> install libtool from the sysroot
Dec 19 14:27:40 <koen> in somethings fixes things
Dec 19 14:27:45 <koen> sometimes*
Dec 19 14:27:52 <koen> sometimes it breaks them even more
Dec 19 14:29:03 <Crofton|work> no change :(
Dec 19 14:29:12 <Crofton|work> WARNING: QA Issue: package dbcxx contains bad RPATH /home/balister/src/oe-core/build/tmp-eglibc/sysroots/odroid-xu/usr/lib in file /home/balister/src/oe-core/build/tmp-eglibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/db/5.3.21-r0/packages-split/dbcxx/usr/lib/libdb_cxx-5.3.so
Dec 19 14:29:13 <koen> did you -c clean it?
Dec 19 14:29:36 <Crofton|work> -ccleansstate
Dec 19 16:06:56 <awozniak> fagius: have you been able to discern any rhyme or reason to why the VPN connection shuts down sometimes?
Dec 19 16:19:16 <Crofton|work> this is epic
Dec 19 16:19:30 <Crofton|work> do_compile_append_class-target() {
Dec 19 16:19:30 <Crofton|work>         cd ${B}
Dec 19 16:19:30 <Crofton|work>         touch .libs/libdb-5.3.lai
Dec 19 16:19:30 <Crofton|work>         touch .libs/libdb_cxx-5.3.lai
Dec 19 16:19:30 <Crofton|work> }
Dec 19 18:17:39 <koen> | checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Dec 19 18:17:48 * koen stabs RTC jumps
Dec 19 18:22:17 <Crofton|work> all my hackery led to an emtpy db package
Dec 19 18:22:18 <Crofton|work> wtf
Dec 19 18:36:29 <XorA> Crofton|work: at least its error free then
Dec 19 18:36:37 <Crofton|work> heh
Dec 19 18:36:47 <Crofton|work> It stopped making shared libs
Dec 19 18:36:52 <Crofton|work> jsut .a files
Dec 19 18:41:39 <Crofton|work> what is the python 3 plan? in a call on anotehr channel it it would be nice to know
Dec 19 18:43:48 <koen> from what I understood is that it has the same issues as python2 has
Dec 19 18:44:00 <koen> so from my POV it's good to go
Dec 19 19:00:38 <bluelightning> IIRC I think Saul asked Khem to rebase and resubmit after 1.5, and that hasn't happened yet
Dec 19 19:00:55 <bluelightning> (the resubmission, obviously 1.5 happened)
Dec 19 19:05:08 <Crofton|work> we can build one or the other?
Dec 19 19:05:59 <Crofton|work> thanks guys
Dec 19 19:07:09 <bluelightning> Khem's series was to add the ability to build 3, didn't remove 2 at all
Dec 19 19:07:18 <bluelightning> so, once that is merged, yes
Dec 19 19:28:17 <Crofton|work> gnuradio is starting to think about python 3, and I do not want OE to be a limiting factor :)
Dec 19 19:37:46 <mr_science> Crofton|work: did you resolve your db config issue satisfactorily ?
Dec 19 19:37:53 <Crofton|work> no
Dec 19 19:38:03 <Crofton|work> I did make it stop making shared libs
Dec 19 19:38:14 <Crofton|work> I need to fight it more
Dec 19 19:38:23 <Crofton|work> but in a call now and going to ride my bike soon
Dec 19 19:39:28 <Crofton|work> I ran through some of your ideas without any luck
Dec 19 19:43:45 <mr_science> you mean the export ac_foo" thing?
Dec 19 19:44:32 <mr_science> i'll send myself a note and take a look after i get home tonight...
Dec 19 19:44:58 <mr_science> is there an existing bug on this?
Dec 19 19:45:08 <mr_science> nm, i can look...
Dec 19 19:47:59 <Crofton|work> I'll try and post th epathc I ahve to date later
Dec 19 19:48:07 <Crofton|work> the configure is a mess
Dec 19 19:57:59 <mr_science> Crofton|work: yeah, if you can post/paste your current status, etc, then maybe i can bring it home for you
Dec 19 19:58:01 <mr_science> maybe
Dec 19 22:56:30 <Crofton|work> mr_science, it is pretty hellish :)
Dec 19 22:57:40 <mr_science> been there, done that  (in general)
Dec 19 22:58:36 <mr_science> should at least be able to hack something that works, which you can then polish up a bit
**** ENDING LOGGING AT Fri Dec 20 03:00:00 2013