**** BEGIN LOGGING AT Fri May 13 02:59:58 2011 May 13 07:14:57 hrw: hi May 13 07:15:05 I am seekign development advice May 13 07:15:24 I wrote a program that needs to be resident and want to add aUI May 13 07:16:15 should my program be a class called from the UI, then to terminate call that class kill method May 13 07:16:24 or should it be a stand alone? May 13 07:16:55 wrong channel? :) May 13 07:17:13 it runs on a mobile device May 13 07:17:25 and I am seeking development advice May 13 07:17:36 and I know hrw can help May 13 07:17:52 I dont know that many developers May 13 07:17:55 good ones May 13 08:32:25 had some bad connection May 13 08:32:37 can anyone pls help me with the UI issue? May 13 08:44:48 cityLights: 'resident' means daemon? May 13 08:45:23 cityLights: you can have daemon running and UI speaking to daemon over socket or dbus May 13 08:45:40 hrw: long time no see May 13 08:45:42 thanks May 13 08:45:53 right May 13 08:46:12 I need it to reside as I need to catch dbus signals in it May 13 08:46:50 should I design it as a deamon? May 13 08:47:44 I mean, this program sleeps most of the time May 13 08:48:39 is my question clear? May 13 08:49:19 no idea sorry May 13 08:53:05 greettings from OE's LinuxTag booth everyone :) May 13 08:53:51 rschus: thanks for promoting OE :) May 13 08:55:13 bluelightning: we're also explaining Yocto and OE-Yocto relationship - I think we should intensify relations between both projects (shared booths and such) May 13 08:56:03 rschus: yes that would be good May 13 08:58:14 hrw, I wrote a program that looks at the calender and changes the profile when in a meeting May 13 08:58:42 I also check if I get a calender change signal May 13 08:59:03 so this program should be a deamon May 13 08:59:30 should I seperate that deamon from the UI or leave them both May 13 08:59:31 ? May 13 08:59:38 I would May 13 08:59:46 and now I need to go May 13 08:59:51 man May 13 08:59:59 when will you be back? May 13 09:02:02 hard to tell as I am at uds so sessions to go and have to do some testing on my laptop when I have kernel hackers in a range May 13 09:02:21 cityLights: better would be to catch other people as I do not write applications anymore May 13 09:02:36 who? May 13 09:02:49 is there anyone nice? May 13 09:03:01 I aksed in #maemo and got no replay May 13 09:03:05 no idea, I do not follow OE so much as before May 13 09:03:24 cityLights: #oe is definitelly wrong channel for this May 13 09:04:01 ok May 13 09:04:37 do you write device drv now? May 13 09:04:58 I do only packaging May 13 09:05:01 see you later May 13 09:05:07 bye May 13 10:01:55 ericben / otavio: what do you guys think about supporting qt 4.6.3 ? is this something we will need to do for a while yet? May 13 10:03:05 (considering oe-core where we tend to support only a single version of a package, rather than oe) May 13 10:31:12 hi woglinde May 13 10:33:58 hw pb May 13 10:44:35 gi rschus May 13 10:44:38 ups hi May 13 12:04:24 hi zecke May 13 12:24:16 hej, anybody noticed that mklibs_0.1.31 disappeared from the mirrors ? ;( May 13 12:38:21 mlip: yeah, it was deleted from the pool, need to use 0.1.33 now May 13 12:39:54 pb_, I just renamed the recipe (pr to 0) and updated the checksums; works for me; I assume somebody is patching (or has already a patch) anyways May 13 13:41:00 why libpcap depends have bluez-libs? may be it wrong? i try build tcpdump and was shocked. oe tried to build a lot of packages. i remove this depends and have worked tcpdump without a lot of dependences May 13 13:56:27 vanner_: libpcap has bluetooth support and it has been chosen to be enabled in OE May 13 14:29:20 bletch, I had forgotten what the busybox recipe looked like May 13 14:30:42 :-) May 13 14:31:49 * pb_ trying to backport current oe master busybox to oe-core May 13 14:32:00 or at least, enough of it to make do_install work on micro May 13 14:32:28 oops May 13 14:35:15 is "backport" really the right word getting something into oe-core? May 13 14:35:40 well, dunno. the oe-core versions tend to be older, so it seems like backporting. May 13 14:36:12 but I guess it is more of a sideways move really, not quite a backport May 13 14:36:30 :-) May 13 14:38:13 hm, is there a way to override a file:// file from another layer? May 13 14:38:35 i.e. can I have busybox_1.18.4.bb from oe-core fetch its defconfig from meta-micro? May 13 14:38:51 if not then I guess I should just give up on porting the changes I need and copy the whole recipe from oe master into meta-micro. May 13 14:39:58 I remember I hat something like this working a while ago. May 13 14:40:01 pb_: if you fix up FILESPATH in your bbappend it should work May 13 14:40:20 pb_: see e72210c791fa2565b7922bdc6542fc064203930b May 13 14:40:25 for an example May 13 14:40:34 ok, cool May 13 14:40:48 it's a little more involved than I personally would like but it does work May 13 14:40:57 what repo is that in? May 13 14:41:10 erm, sorry that the poky rev.. hang on a sec May 13 14:41:13 you could also change it so they all find them in all the layers by default, used to do that back when using collections May 13 14:41:26 dont' see any reason you couldn't here too, of course it'd explode the size of filespath a bit :) May 13 14:42:26 pb_: http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=e72210c791fa2565b7922bdc6542fc064203930b May 13 14:42:30 yeah. I guess I could override FILESPATH_pn-busybox or something to avoid havng to do it for all recipes May 13 14:42:46 bluelightning: thanks May 13 14:46:34 ezee_1.0.0.bb seems to have a md5sum error on ezee-1.0.0.0.tar.gz May 13 14:47:41 ok, cool, that seems to be working May 13 14:48:09 jkridner: what branch? May 13 14:48:18 jkridner: there is eeze_1.0.1.bb in oe.dev May 13 14:48:26 maintainence May 13 14:48:58 then ask someone to cherry-pick 79d295c31e64e972608d5dde5d57e6250d7ca77c May 13 14:49:14 * kergoth_ thinks oe-core could use filespathbase/filepathpkg or similar, base_set_filespath is pretty lame May 13 14:49:24 kergoth_: agreed May 13 14:49:39 JaMa|W thanks. May 13 14:50:27 bye May 13 14:51:27 kergoth_: good point... that's how I did it: changing FILESPATHBASE May 13 14:53:18 * pb_ stabs image-prelink.bbclass, hardwired reference to "/usr/sbin/prelink" May 13 14:53:39 (among others) May 13 15:00:51 so, I pushed those busybox changes (and a few others) to https://github.com/philb/oe-core/commits/pb%2Fcompat/ May 13 15:00:59 I do seem to get a plausible-looking rootfs out now, so that's good news May 13 15:01:16 just gotta find a kernel recipe that works so I can try it :-) May 13 15:08:18 also now pushed the current meta-micro bits to git://pbcl.net/git/meta-micro.git in case anyone is interested May 13 15:43:02 pb_: nice May 13 16:51:32 03Otavio Salvador  07master * rabecbb4c0a 10bitbake.git/lib/bb/codeparser.py: May 13 16:51:32 codeparser.py: fix syntax error in exception handling May 13 16:51:32 Commit 036cf3cd11b3a6836b77f5ffa760ceee6b71b1ef missed the needed May 13 17:10:40 is http://wiki.openembedded.net/index.php/How_to_submit_a_patch_to_OpenEmbedded up to date for patch submission procedure? And, where would I send a patch for bitbake - I have a one line change/fix for bzr.py fetcher May 13 17:13:44 hbeck: bitbake-dev mailing list May 13 17:16:24 kergoth_: ok. for a change in bitbake/lib/bb/fetch, should I also make the change in .../fetch2/ (the code is the same in this case) May 13 17:16:41 yep May 13 17:17:30 procedure on the wiki is good I assume? First time I'm contributing here so trying to make sure I have things correct May 13 17:27:42 hi, it seems git hooks are not working : no log here when comiting and no mail are sent to the comit list May 13 17:55:14 blindvt ping May 13 17:59:31 woglinde: hey. :} May 13 17:59:42 hey zecke May 13 18:34:04 he mickeyl May 13 19:21:10 hms uclibc nptl support dont works for armv4 May 13 19:22:31 better dont compiles May 13 19:25:33 hm looks like a simple patch May 13 19:29:43 ah May 13 19:43:01 Arrg. Did I miss an answer? May 13 19:45:43 no May 13 19:45:59 Thanks. May 13 19:54:27 args May 13 19:54:40 how do I tell a machine config it nots supporting thumb May 13 19:57:56 hm I found it I gess May 13 20:07:16 mehmeh May 13 20:07:40 * kergoth_ yawns May 13 20:08:57 he kergoth May 13 20:09:23 hm where the hell libgcc_s_personality comes from May 13 20:26:31 woglinde: armv4 should work with nptl May 13 20:26:34 what issues do u see May 13 20:27:47 /libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c:49:3: error: 'libgcc_s_personality' undeclared (first use in this function) May 13 20:27:53 latest git tree May 13 20:28:54 libgcc_s_resume isnt found too May 13 20:29:27 thats strange since its unwinding part May 13 20:29:33 yes May 13 20:29:42 is eabi set correctly May 13 20:29:48 yes May 13 20:30:06 CONFIG_ARM_EABI=y May 13 20:30:12 # COMPILE_IN_THUMB_MODE is not set May 13 20:30:13 # USE_BX is not set May 13 20:30:33 set machine to simpad May 13 20:30:37 and see yourself May 13 20:30:53 first the config merger will add BX back May 13 20:31:06 because it finds some thumb-interwork var se May 13 20:31:07 t May 13 20:31:12 yes May 13 20:31:30 which is stupid for armv4 arch May 13 20:31:42 wont happen for minimal May 13 20:31:54 which distro arr u using May 13 20:31:57 hm May 13 20:32:02 angstroem May 13 20:32:07 minimal-uclibc May 13 20:32:08 try that May 13 20:32:11 why? May 13 20:33:07 has the same line May 13 20:33:09 DISTRO_FEATURES += ' ${@["", "thumb-interwork"][bb.data.getVar('THUMB_INTERWORK', d, 1) == "yes"]}' May 13 20:35:27 woglinde: paste code of /libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c May 13 20:35:42 http://git.uclibc.org/uClibc/tree/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c May 13 20:36:09 at beginning there is static _Unwind_Reason_Code (*libgcc_s_personality) (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); May 13 20:36:27 is that same code what you are compiling ? May 13 20:36:33 args May 13 20:36:38 wrong file May 13 20:37:02 http://git.uclibc.org/uClibc/tree/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c May 13 20:37:14 but the look mostly the same May 13 20:37:15 yes May 13 20:37:31 I wonder why that error then May 13 20:38:21 in the end it should be aliased to __gcc_personality_v0 May 13 20:38:43 I dont have classical oe setup handy May 13 20:38:54 and there is no layer with armv4 machines yet May 13 20:39:02 that I could easily try May 13 20:40:18 hm I try now to find where interwork is set May 13 20:40:58 ah there May 13 20:40:59 it should be in arm-thumb.inc May 13 20:41:03 IIRC May 13 20:41:03 stupid May 13 20:41:04 np May 13 20:41:05 no May 13 20:41:16 angstroen and kaeilos hardcoded it May 13 20:41:24 distro/include/angstrom.inc:THUMB_INTERWORK = "yes" May 13 20:41:25 ok May 13 20:44:20 in arm-thumb.inc it should be losely set to no May 13 20:45:05 this is infact one machine feature that distro should enquire machines before taking a decision to set it or not May 13 20:45:28 in many cases like this there may be no option at all May 13 20:48:47 khem hm the error in unwind remains May 13 20:50:06 woglinde: same snapshot compiled for armv4t ? May 13 20:50:09 or newer May 13 20:50:33 let met try May 13 20:50:49 it could be someone just borked it May 13 20:50:55 hello, some days ago I asked here about tethering and N900, today I bought an XS Stick P14, Installation under windows was very confusing me, a reboot was also necessary, under linux, i plugged the stick in , entered my PIN and the connection was established :-) May 13 20:51:24 send this note to Redmond Washington May 13 20:51:39 and ask them to fix windows May 13 20:51:49 * pb_ stabs ubuntu, stupid bash completion setup May 13 20:52:03 * khem reminds himself of calling the painter May 13 20:52:15 I normaly use hostap and iptables to tether May 13 20:52:17 pb_: I like bash completion May 13 20:53:13 what is quata limit on github to host git repos for free May 13 20:53:15 I find it's one of those features which is cute in theory but infuriating in practice if it isn't entirely correct May 13 20:53:18 quota May 13 20:53:47 for example, if I do "cd tmp/deploy/ipk/i586; dpkg-deb -I dropbear", it won't complete the name of the archive. May 13 20:54:01 presumably because it sees "dpkg" and thinks I want the name of a debian package May 13 20:54:31 so, I end up having to deliberately mistype the command, tab-complete the argument, then hit ^A to go back and correct the name of the command I wanted May 13 20:55:17 yes it will show dpkg-deb options :) May 13 20:55:56 right, but dpkg-deb just takes a filename as its argument May 13 20:56:11 so, all I want it to do here is complete the name of the fil in the current directory, but it doesn't actually do that. May 13 20:57:10 hmm there must be a way to communicate that I dont want the options but the input files May 13 20:57:19 or may be show files along with options May 13 20:57:21 you'd think, but I haven't found one May 13 20:57:29 it doesn't actually show the options, it just does nothing at all May 13 20:57:51 (if I press TAB after the -I) May 13 20:57:55 bbiab, dinner time May 13 20:59:08 .o(late dinner) May 13 21:00:34 pb_: complete -o filenames -F _filedir_xspec dpkg-deb May 13 21:00:42 then it will show files May 13 21:00:47 in completion May 13 21:03:48 but yeah its only useful upto certain limits May 13 21:04:07 I like the fact that it shows the cmdline options for commands May 13 21:11:32 khem ah hm May 13 21:11:38 armv7 suffers the same May 13 21:11:54 yes there is something which is broken May 13 21:12:10 are you using the git srcrev that uclibc_git is set to May 13 21:12:18 we need to figure out what breaks it May 13 21:13:58 1bfe83b42b5b850c20ed8d35819cced510eaef3c May 13 21:14:31 251f2266bf24b1b396f59eef60d0acf41fdd02e4 works May 13 21:18:48 hms May 13 21:18:58 no mood to bisect it May 13 21:19:22 arent you supposed to work ;) May 13 21:19:58 hm but it worked with fts support May 13 21:20:01 ok let me make it a bit simple May 13 21:20:07 074930dd7f2a18a7013cdb72cc38136f3be39c40 works too May 13 21:20:11 oh May 13 21:20:19 it worked with fts May 13 21:20:20 that I remember May 13 21:20:31 now you confuse me May 13 21:20:32 hm wait there was a gcc update May 13 21:20:43 maybee thats the problem May 13 21:20:57 may be May 13 21:21:01 may be not May 13 21:21:03 *sigh* May 13 21:21:12 same gcc is compiling meta-oe uclibc ok May 13 21:21:27 khem I tested here for systemd with fts commited in uclibc May 13 21:21:35 this makes the bisect smaller May 13 21:21:53 ok so if you enable fts is works May 13 21:22:00 if you disable it then it barfs May 13 21:22:03 right ? May 13 21:22:21 no May 13 21:22:31 I meant with fts intotruced May 13 21:24:09 woglinde: I have a snapshot which is newer that fts and it compiles May 13 21:24:14 but I have fts enabled May 13 21:24:43 thats what I said May 13 21:24:51 251f2266bf24b1b396f59eef60d0acf41fdd02e4 is from march May 13 21:24:56 whats your rev? May 13 21:25:02 074930dd7f2a18a7013cdb72cc38136f3be39c40 May 13 21:26:07 I asked you same question and you said no May 13 21:26:13 uhm May 13 21:26:14 sorry May 13 21:28:20 yes this version works May 13 21:28:35 can you send me your .config May 13 21:28:40 I can bisect it may be May 13 21:29:30 it should fail four you too May 13 21:29:32 latest rev May 13 21:29:41 but I bisect it now myself May 13 21:30:08 can you revert 7d8c08baf43d27aac22a29e55c1108f31b8d7595 May 13 21:30:11 and see if that helps May 13 21:31:03 woglinde: I have a hunch its this commit May 13 21:31:12 yeah May 13 21:31:17 didnt saw it before May 13 21:31:47 can you confirm if this is the culprit ? May 13 21:32:05 tested with my libgcc_eh fix May 13 21:32:28 ok so 7d8c08baf43d27aac22a29e55c1108f31b8d7595 is to blame then right ? May 13 21:33:08 mom May 13 21:33:55 I mean moving sysdep headers to generic include is dead wrong anyway May 13 21:34:02 this patch has to be wrong May 13 21:34:38 problem is now for arm it will pick this generic unwind.h May 13 21:34:45 and not the arm/unwind.h May 13 21:35:07 yes May 13 21:35:11 thats the problem May 13 21:35:39 I will give you a patch in moment May 13 21:35:41 try that May 13 21:37:18 git mv include/unwind.h ./libc/sysdeps/linux/common/ May 13 21:37:19 "unwind.h" May 13 21:37:23 I guess May 13 21:37:28 and recompile May 13 21:38:12 let me know if it fixes it May 13 21:38:17 it should actually May 13 21:38:20 yeah mom May 13 21:41:17 woglinde: and also git mv ./libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind.h ./libc/sysdeps/linux/arm/ May 13 21:41:50 khem there are no headers in this dir May 13 21:42:03 ./libc/sysdeps/linux/common/ May 13 21:42:41 woglinde: what do u mean May 13 21:42:49 ./libc/sysdeps/linux/common/sysdep.h is there May 13 21:42:53 isnt that a header May 13 21:43:00 or ./libc/sysdeps/linux/common/syscalls.h May 13 21:43:04 hm okay May 13 21:43:06 yes May 13 21:43:11 looked wrong way May 13 21:43:49 problem that bernhard tried to fix was some non nptl stuff is using unwind headers May 13 21:43:56 yes May 13 21:44:03 so he did a gross hack to move it so anyone gets it May 13 21:44:35 we just make sure that override order is preserved May 13 21:44:44 still the same May 13 21:44:50 errors out ? May 13 21:45:07 yes May 13 21:45:08 ./libc/sysdeps/linux/arm/unwind.h May 13 21:45:08 ./libc/sysdeps/linux/common/unwind.h May 13 21:45:18 | ./libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c:31:19: error: expected ')' before 'struct' May 13 21:45:59 hm mom May 13 21:46:06 will do a clean build May 13 21:48:10 args May 13 21:48:20 wrong machine May 13 21:48:28 huh May 13 21:48:43 let me know once you sort it out May 13 21:49:18 few seconds May 13 21:50:05 yes May 13 21:50:12 worked for armv7 May 13 21:50:19 ok May 13 21:50:26 no armv4 test May 13 21:50:35 no or now ? May 13 21:50:41 now May 13 21:50:53 deciphering through errors May 13 21:51:24 and I only wanted to build opie May 13 21:51:57 heh yeah this phenomenon is call shitball May 13 21:54:56 khem armv4 build to May 13 21:56:48 hm - the following looks fishy: May 13 21:56:51 ERROR: Nothing RPROVIDES 'glibc-utilsglibc-utils' (but /home/liam/code/oestuff/angstrom-setup-scripts/sources/openembedded-core/meta/recipes-core/tasks/task-core-nfs.bb RDEPENDS on or otherwise requires it) May 13 21:57:36 liamMT yes May 13 21:57:53 trying to build qemuarm console-image from oe-core via angstrom setup scripts May 13 21:58:28 khem could you commit it to uclibc? May 13 21:58:57 any hints on what might be causing this? May 13 21:59:15 remove one glibc-utils from /home/liam/code/oestuff/angstrom-setup-scripts/sources/openembedded-core/meta/recipes-core/tasks/task-core-nfs.bb May 13 22:02:09 seems it has both May 13 22:02:10 RRECOMMENDS_task-core-nfs-server_append_linux = "${GLIBC_DEPENDENCIES}" May 13 22:02:10 RRECOMMENDS_task-core-nfs-server_append_linux-gnueabi = "${GLIBC_DEPENDENCIES}" May 13 22:02:32 ah append whithout blanl May 13 22:02:32 if I remove the former, at least the build continues, though I don't understand the implications May 13 22:02:36 ups blank May 13 22:02:37 thats bad May 13 22:03:02 without blank? May 13 22:03:20 yes May 13 22:03:27 append does append May 13 22:03:43 so you have "${GLIBC_DEPENDENCIES}${GLIBC_DEPENDENCIES}" May 13 22:03:47 in the end May 13 22:04:11 I see - so what would be the appropriate fix in this case? May 13 22:04:51 its stupid anyway May 13 22:05:05 try to remove both line May 13 22:05:25 or remove the RRECOMMENDS_task-core-nfs-server_append_linux-gnueabi lin May 13 22:05:32 and make RRECOMMENDS_task-core-nfs-server_append_linux = "${GLIBC_DEPENDENCIES}" May 13 22:05:45 to RRECOMMENDS_task-core-nfs-server_append_linux = " ${GLIBC_DEPENDENCIES}" May 13 22:06:43 ah, ok. will try May 13 22:07:21 khem ping May 13 22:08:43 ok, that works - just inserting a space before the second item May 13 22:08:45 thanks! May 13 22:08:55 *sigh* May 13 22:09:22 this is straight from git - helpful to log this somewhere? May 13 22:09:32 is package-index meta recipe the best way to knock the listings up to date? (something in my brain is telling me it was somehow deprecated) May 13 22:09:40 hbeck yes May 13 22:09:52 its the way I am doing it too May 13 22:10:50 woglinde_: thanks May 13 22:12:55 ok, easy question #2 (I swear I had this set up before...) - how to set up the feed config (eg: armv4t.conf) for opkg to pull from my box which doesn't provide http access? May 13 22:13:01 just for local dev quick testing May 13 22:13:33 ...did I mention the opkg documentation is abysmal? May 13 22:25:09 hm I hit this May 13 22:25:11 http://comments.gmane.org/gmane.comp.video.mesa3d.devel/26049 May 13 22:25:14 case for jama May 13 22:30:56 woglinde_: yes May 13 22:32:20 khem pushed? May 13 22:33:08 hm no May 13 22:33:19 woglinde_: no May 13 22:35:06 woglinde_: ok it should be there now May 13 22:35:13 71d63ed75648da9b0b71afabb9c60aaad792c55c May 13 22:35:41 woglinde_: ? May 13 22:36:56 woglinde_: that was fixed by http://git.openembedded.net/cgit.cgi/openembedded/commit/?id=f2a73450a70d113d77fbf703772fbf0db81e8e61 May 13 22:38:09 woglinde_: thanks for reporting and testing the uclibc issue May 13 22:39:14 khem paul found it too May 13 22:39:25 ok May 13 22:39:36 * khem hands eBeers to both May 13 22:39:59 jama than maybee angstroem problem with pinned revs May 13 22:41:01 woglinde_: no May 13 22:41:19 woglinde_: I had the same and there is only one version of glproto and dri2proto May 13 22:41:29 I guess you don't have this patch yet May 13 22:41:36 ? May 13 22:41:41 I pulled May 13 22:41:42 JaMa|Off: did you try gcc 4.6 yes May 13 22:41:45 yet May 13 22:41:56 khem: not yet May 13 22:42:01 JaMa|Off: ok May 13 22:42:09 we have it in meta-oe May 13 22:42:19 khem: all my hosts rebuilding from scrath almost all the time May 13 22:42:25 khem: thanks to sstate.. May 13 22:42:34 hmmm May 13 22:42:38 hm May 13 22:42:46 for me sstate has worked so so May 13 22:44:12 khem: it does "right" thing most of time.. but sometimes it's too often :) May 13 22:44:25 heh May 13 22:44:32 yeah May 13 22:44:39 we can improve it May 13 22:44:49 its already improvement over staging May 13 22:44:52 jama yes didnt have the latest commit from today May 13 22:45:08 khem: and lately I did rebuild accidentaly when running build with preferred gcc-4.5.0 instead of 4.5 May 13 22:45:14 e.g. I have not build from scratch in 2 weeks May 13 22:45:20 khem: and then when we lost TARGET_VENDOR May 13 22:45:27 and rebuild toolchain 10 times a days May 13 22:45:31 khem: and then again when I returned TARGET_VENDOR May 13 22:45:51 khem, hi May 13 22:45:59 tharvey: hello May 13 22:46:18 did you see my posting to the ml about issues with sdk and autoconf projects? May 13 22:46:52 tharvey: not yet May 13 22:46:59 the way I see it the failure is in the binconfigs - trying to figure out if there is a better way to do things May 13 22:47:02 I have been swamped with other stuff May 13 22:47:02 woglinde_: let me know if it still fails for you May 13 22:47:09 no builded May 13 22:47:14 even with mesa 7.10 May 13 22:47:14 great May 13 22:47:25 yes May 13 22:47:29 but I'm 'still' not understanding your thoughts on libtool being the fault or how even libtool factors in May 13 22:47:32 thanks for quick fix May 13 22:47:43 woglinde_: yw, sorry for noise May 13 22:47:48 tharvey: lets clean the slate May 13 22:47:57 khem, yes May 13 22:47:58 tharvey: I might not have understood the problem fully May 13 22:48:11 so you have an sdk May 13 22:48:11 so in summary freetype-config in the sdk from freetype-dev spits out / based paths May 13 22:48:28 and you want to build another project with it which uses autotools May 13 22:48:31 so gd's configure runs freetype-config and ends up putting / based paths in your makefile May 13 22:49:05 and I don't see how any manner of autoreconf will solve that unless your supplying rewrites of all the m4's that avoid using the binconfigs May 13 22:49:06 hmm yes thats possible May 13 22:49:12 so we need to fix freetype-config May 13 22:49:40 so binconfig.bbclass will mung binconfigs for STAGING_DIR May 13 22:49:51 yes something like that May 13 22:49:55 which is why autoreconf && configure words for gd May 13 22:50:26 but you can't ship SDK relative paths in binconfigs in the -dev packages because they can/may be used on target which is / based May 13 22:50:46 I think making SDK just work for autotoolized projects could be a good thing but its a bit hard for cross May 13 22:51:04 so my question/suggestion on ML is perhaps we should stage/package binconfigs that use a prefix of LIBTOOL_SYSROOT_PATH or something that the SDK defines but the target wouldn't May 13 22:51:18 tharvey: we can use something like SDKROOT May 13 22:51:24 right... May 13 22:51:32 which is / for targets and something else for SDKs May 13 22:51:42 although there is already the LIBTOOL_SYSROOT_PATH that is the same in the SDK May 13 22:51:49 and I'm still not clear when/where that is used May 13 22:52:24 LIBTOOL_SYSROOT_PATH is used to convey sysroot location to libtool 2.4 May 13 22:53:11 brb May 13 22:54:45 yes, I've been told that, but I still dont' know what that means. So current SDK does include libtool 2.4 - how/where is LIBTOOL_SYSROOT_PATH used? it doesn't look to me like the libtool script uses it, so I figure its supposed to be passed to 'something' (configure? autoreconf?) May 13 23:00:33 good nite May 14 00:55:10 khem, I've got to run - comment on http://thread.gmane.org/gmane.comp.handhelds.openembedded/45324 when you have a chance. I'm also trying to understand better how/where to use the LIBTOOL_SYSROOT_PATH (passed in somehow to configure, or autoreconf, or?) **** ENDING LOGGING AT Sat May 14 02:59:58 2011