**** BEGIN LOGGING AT Tue May 10 02:59:58 2011
May 10 04:49:41 <sanket> hello
May 10 04:49:49 <sanket> I had cross compiled FLTK applications for MIPS development board ............. almost all the cross compiled binaries are running successfully... except one..... for that I m getting segmentation fault....... I had strace that binary.....  before getting seg fault ..... I getting some .... Inappropriate ioctl for device..... can any one help me wat will be problem....
May 10 04:49:58 <sanket> here is the strace result for that binary..... http://pastebin.mozilla.org/1221945
May 10 04:52:25 <CIA-78> 03Simon Busch <morphis@gravedo.de> 07master * r5a6efd58cd 10openembedded.git/recipes/qt4/ (4 files): (log message trimmed)
May 10 04:52:25 <CIA-78> qt4-native: introduce the native version of qt4 and remove old qt4-tools-native
May 10 04:52:25 <CIA-78> The new recipe is based on the qt4-tool-native one but it even installs the libraries of
May 10 04:52:25 <CIA-78> qt4 and not only the tools like moc/rcc. It will not increase the build time as most
May 10 04:52:25 <CIA-78> libraries are already build for the qt4-tool-native but not staged.
May 10 04:52:26 <CIA-78> This commit removes the old qt4-tools-native too. All versions provided by
May 10 04:52:27 <CIA-78> qt4-tools-native are even supported by qt4-native so it is a drop-in replacement.
May 10 07:08:15 <mckoan> good morning
May 10 07:22:16 <bluelightning> morning all
May 10 07:23:55 <CIA-78> 03Andreas Müller <schnitzeltony@gmx.de> 07org.openembedded.dev * r52ecfd3a14 10openembedded.git/recipes/u-boot/u-boot_2011.03.bb: 
May 10 07:23:55 <CIA-78> u-boot: add 2011.03
May 10 07:23:55 <CIA-78> Signed-off-by: Andreas Mueller <schnitzeltony@gmx.de>
May 10 07:23:55 <CIA-78> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 10 07:23:55 <CIA-78> 03Andreas Müller <schnitzeltony@gmx.de> 07org.openembedded.dev * rc9500e26ce 10openembedded.git/recipes/u-boot/ (u-boot_2011.03.bb u-boot_git.bb): (log message trimmed)
May 10 07:23:55 <CIA-78> overo: u-boot fix by moving to version 2011.03
May 10 07:23:56 <CIA-78> The old git version did not start up from SDCard.
May 10 07:23:56 <CIA-78> Tests:
May 10 07:23:57 <CIA-78> * Set default variable environment
May 10 07:23:57 <CIA-78> * Save variable environment
May 10 07:23:58 <CIA-78> * Boot kernel from MMC and NAND
May 10 07:25:26 <sanket> I had cross compiled FLTK applications for MIPS development board ............. almost all the cross compiled binaries are running successfully... except one..... for that I m getting segmentation fault....... I had strace that binary.....  before getting seg fault ..... I getting some .... Inappropriate ioctl for device..... can any one help me wat will be problhere is the strace result for that binary..... http://pastebin.mozilla.org/1221945em.... 
May 10 07:25:41 <sanket>  http://pastebin.mozilla.org/1221945
May 10 07:58:27 <CIA-78> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb974f1476f 10openembedded.git/recipes/linux/ (2 files in 2 dirs): 
May 10 07:58:27 <CIA-78> linux-omap-psp 2.6.32: support accept4 call
May 10 07:58:27 <CIA-78> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 10 08:03:40 <esbenh> kergoth_: ping
May 10 08:06:46 <CIA-78> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r465521a22a 10openembedded.git/recipes/udev/udev_168.bb: 
May 10 08:06:46 <CIA-78> udev: add 168
May 10 08:06:46 <CIA-78> This is a work in progress to clean out all the historical rules which aren't needed anymore and slow down booting
May 10 08:06:46 <CIA-78> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 10 08:12:43 <mickey|office> moin woglinde 
May 10 08:12:50 <woglinde> hi mickeyl
May 10 08:12:54 <woglinde> hi xora
May 10 08:15:14 <XorA> hey woglinde 
May 10 08:15:14 <mckoan> anybody could tell me how to properly create a custom branch into the OE repo? (not only a local branch)
May 10 08:15:30 <mckoan> I would like to avoid errors doing that
May 10 08:15:41 <mckoan> or creating a mess in the OE repo
May 10 08:16:46 <mckoan> is this ok? http://wiki.openembedded.org/index.php/GitPhraseBook#Feature_branches
May 10 08:17:19 <woglinde> hm reminds me to tell ka6sox to delete my old gettext branch
May 10 08:17:43 <woglinde> mckoan if you are unsure try github or gitorius first
May 10 08:18:21 <mckoan> woglinde: what do you mean? to test and learn before doing that?
May 10 08:18:31 <XorA> git push origin local-branch:remote-branch
May 10 08:19:00 <woglinde> mckoan yes
May 10 08:19:09 <woglinde> because without admin help you cannt delete your branch
May 10 08:20:18 <mckoan> woglinde: I simply need to take a OE current version, create a branch called kaeilos2009 (or something like that) and push it
May 10 08:20:47 * XorA just gave the command to do that
May 10 08:20:48 <mckoan> so I can restart working on the mainline
May 10 08:21:14 <mckoan> XorA: yep, thx, the same was in the wiki, I'll try that
May 10 08:31:08 <ka6sox-sick> woglinde, you want that done right?
May 10 08:32:23 <woglinde> ka6sox yes please delete the woglinde/gettext branch its only wasting space
May 10 08:32:31 <woglinde> look at the last commit
May 10 08:32:32 <woglinde> date
May 10 08:35:21 <ka6sox-sick> okay I will eithter do it myself or let the gitadmins know.
May 10 08:36:17 <woglinde> ka6sox ah hm I thought you were gitadmin too
May 10 08:36:26 <CIA-78> 03Martin Jansa <martin.jansa@gmail.com> 07master * r819fa4c451 10openembedded.git/recipes/ (9 files in 8 dirs): (log message trimmed)
May 10 08:36:26 <CIA-78> recipes: fix LICENSE fields
May 10 08:36:26 <CIA-78> * & in LICENSE breaks distribute_sources
May 10 08:36:26 <CIA-78> ERROR: Function 'SRC_DISTRIBUTECOMMAND' failed (see /OE/tmpdir-shr/work/armv4t-oe-linux-gnueabi/pixman-0.22.0-r5.0/temp/log.do_distribute_sources.17340 for further information)
May 10 08:36:26 <CIA-78> ERROR: Logfile of failure stored in: /OE/tmpdir-shr/work/armv4t-oe-linux-gnueabi/pixman-0.22.0-r5.0/temp/log.do_distribute_sources.17340
May 10 08:36:26 <CIA-78> Log data follows:
May 10 08:36:27 <CIA-78> | WARNING: LICENSE: 'PublicDomain & MIT & MIT-style'
May 10 08:36:28 <CIA-78> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r042d20546b 10openembedded.git/recipes/efl1/imlib2_svn.bb: 
May 10 08:36:29 <CIA-78> imlib2: sync LICENSE from meta-efl
May 10 08:36:29 <CIA-78> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 10 08:37:03 <CIA-78> 03Martin Jansa <martin.jansa@gmail.com> 07master * r1c25e6c73b 10openembedded.git/recipes/ (7 files in 5 dirs): (log message trimmed)
May 10 08:37:04 <CIA-78> recipes: drop '+' from LICENSE fields
May 10 08:37:04 <CIA-78> * '+' is valid folder name, so it does not break distribute_sources like & does,
May 10 08:37:04 <CIA-78> but still tmp/deploy/sources/+ folder doesn't make sense at all
May 10 08:37:04 <CIA-78> * PR was bumped only when white-spaces were removed from LICENSE field causing
May 10 08:37:05 <CIA-78> sources to be stored in different folder (classpathx recipes)
May 10 08:37:06 <CIA-78> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 10 08:37:10 <ka6sox-sick> I am, but I don't delete things without talking to folks first.
May 10 08:37:35 <mckoan> $ git push origin mckoan/kaeilos-2009
May 10 08:37:36 <mckoan> fatal: The remote end hung up unexpectedly
May 10 08:38:04 <ka6sox-sick> mckoan, it was rather overloaded for the last 20minutes
May 10 08:38:23 <mckoan> ka6sox-sick: uh, ok, sorry
May 10 08:38:31 <ka6sox-sick> which is why I was hoping that .eu would start pulling from github and pushing back to oe.git.org
May 10 08:39:35 <ka6sox-sick> the 0800-1000 rush every morning causes this.
May 10 08:44:07 <XorA> ka6sox-sick: boot koen to update the Angastrom scripts to pull from github
May 10 08:45:57 <ka6sox-sick> okay...let me do that now...
May 10 08:49:44 <ka6sox-sick> XorA, done
May 10 08:51:27 <XorA> I suspect most Angstrom users probably do oebb.sh update every morning
May 10 08:54:46 <XorA> it might be an idea to disable non ssh pulls for a week or so, forcing everyone to switch to the mirrors :-)
May 10 08:55:14 <ka6sox-sick> well...thats one way.
May 10 08:55:25 <ka6sox-sick> and it *will* get their attention.
May 10 08:55:31 <XorA> trouble is most people dont understand git so wont switch until forced
May 10 08:56:11 <ka6sox-sick> okay I'm not on the Angstrom ML...someone needs to write up something that says here is where you go now.
May 10 08:56:25 <XorA> do you have the github url handy?
May 10 08:57:49 <ka6sox-sick> they really use http and not RO git?
May 10 08:59:23 <XorA> I got fooled by that, both are there
May 10 08:59:29 <XorA> click on the bit that says read only git
May 10 08:59:52 <ka6sox-sick> git://github.com/openembedded/openembedded.git
May 10 08:59:58 <ka6sox-sick> so there are 4 repos
May 10 09:00:05 <ka6sox-sick> I don't know which ones they use.
May 10 09:00:08 <ka6sox-sick> probably all
May 10 09:01:31 <ka6sox-sick> XorA, see PM.
May 10 09:07:52 <woglinde> hi risca
May 10 09:38:28 <woglinde> gm rp
May 10 09:42:32 <zecke> woglinde: hey
May 10 09:43:06 <woglinde> he zecke
May 10 09:43:24 <sanket> I had cross compiled FLTK applications for MIPS development board ............. almost all the cross compiled binaries are running successfully... except one..... for that I m getting segmentation fault....... I had strace that binary.....  before getting seg fault ..... I getting some .... Inappropriate ioctl for device..... can any one help me wat will be problem..........here is the strace result for that binary.....   http://pastebin.mozilla.org/1221945
May 10 09:44:57 <woglinde> sanket better use gdb and debugsymbols
May 10 09:46:41 <sanket> but the same program is running on my host i386...
May 10 09:46:58 <woglinde> and?
May 10 09:47:27 <zecke> sanket: then use the host as target device? :)
May 10 09:47:36 <woglinde> zecke *g*
May 10 09:48:07 <zecke> woglinde: BTW: did you look at the poster? I wonder if the usage of gray is such a good idea. i will plot it both in A2 and A0 today
May 10 09:49:36 <woglinde> hm let me see
May 10 09:50:19 <woglinde> hm args I better had look yesterday
May 10 09:50:26 <woglinde> indeed the gray could be a problem
May 10 09:51:26 <woglinde> zecke hopefully the shop can make it not so dimm
May 10 09:54:09 <pb_> hi zecke, woglinde, mickey, all
May 10 09:55:35 <zecke> woglinde: I am getting too old for unorganized chaotic things. :(
May 10 09:56:14 <woglinde> hi pb
May 10 09:56:32 <woglinde> zecke okay so we will surrender from attending fairs?
May 10 09:56:47 <obi_> hi
May 10 09:56:53 <mlip> na sdorowje!
May 10 09:57:08 <woglinde> hi obi
May 10 10:02:30 <ka6sox-sick> zecke, better to resign to some desert island...life is getting crazier.
May 10 10:04:57 <zecke> woglinde: i already did, I'm more for  back office and schnittchen. :)
May 10 10:05:13 <zecke> woglinde: do you know when the booth will be equipped?
May 10 10:05:20 <woglinde> tomorrow
May 10 10:14:51 <likewise> gm
May 10 10:16:05 <woglinde> hi8 likewise
May 10 10:19:58 <mlip> ********* python .....
May 10 10:24:49 <luuk> hello 
May 10 10:25:35 <luuk> i have a problem compiling gst-plugins-good_0.10.28 for the ea3250
May 10 10:26:00 <woglinde> whats the problem?
May 10 10:26:41 <luuk> my make file stops 
May 10 10:26:52 <luuk> with differnt errors 
May 10 10:27:03 <luuk> esd.h no such file directory
May 10 10:27:24 <luuk> i think that the main reason
May 10 10:31:05 <luuk> does anyone know where i can find esd.h?
May 10 10:31:48 <woglinde> bitbak esd
May 10 10:31:57 <woglinde> ups bitbake
May 10 10:32:13 <woglinde> luuk and you dont tell at all which oe version you are using
May 10 10:32:53 <luuk> i am using the latest openembedded 
May 10 10:33:05 <luuk> just did a pull from the git
May 10 10:33:41 <luuk> and i use bitbake version 1.10.2 
May 10 10:41:32 <mlip> JaMa, ping... I just googled you in a chatlog trying to fix a _ctypes issue for python-native; could you solve it by now ? ;9
May 10 10:45:30 <mickey|office> hi pb_ 
May 10 10:45:33 <mickey|office> yo z.!
May 10 10:45:36 <JaMa> mlip: it's already fixed in oe.dev as well as oe-core
May 10 10:46:09 <mlip> JaMa, building python-native-2.6.6-nk1.0 misses _ctypes.so for me (native)
May 10 10:46:28 <mlip> JaMa, oe-core
May 10 10:47:27 <JaMa> ah, iirc it's solved only for non-native build
May 10 10:47:38 <JaMa> but same patch could be used for -native
May 10 10:48:33 <mlip> JaMa, you mean 06-ctypes-libffi-fix-configure.patch ?
May 10 10:48:53 <JaMa> yes
May 10 10:49:37 <mlip> then I will try, I am trying to get pyudev running and it needs ctypes-native to compile
May 10 10:58:48 <mlip> JaMa, fyi: patch didn work; I thought I had a chance to get that solved quickly
May 10 10:59:23 <JaMa> didn't apply or wasn't enough to reconfigure ctypes/libffi?
May 10 11:01:00 <JaMa> mlip: don't forget ot put:
May 10 11:01:00 <JaMa> do_configure_prepend() { autoreconf -Wcross --verbose --install --force --exclude=autopoint Modules/_ctypes/libffi || oenote "_ctypes failed to autoreconf"
May 10 11:01:03 <JaMa> to native recipe
May 10 11:01:05 <JaMa> }
May 10 11:01:07 <mlip> JaMa, sry: it applied, but it wasn't enough http://pastebin.com/JcJ2qxLK
May 10 11:01:20 <Crofton|work> mickey|office, sakoman_ is saying the source tarball for sip has disappeared already
May 10 11:01:25 <Crofton|work> no version on Arpil 30?
May 10 11:01:26 <mlip> JaMa, ! that's probably the missing link ;D
May 10 11:01:30 <Crofton|work> I did not check personally
May 10 11:02:12 <mlip> JaMa, log telling me anyways, but I didn't know which aclocal it's talking about
May 10 11:03:03 <JaMa> mlip: ?
May 10 11:04:09 <mlip> JaMa, log_compile states that the build systems needs to be regenerated
May 10 11:04:47 <JaMa> and did you run configure after adding it?
May 10 11:05:00 <mlip> JaMa, I am rebuilding right now
May 10 11:05:41 <mickey|office> Crofton: which version of sip from which domain?
May 10 11:06:28 <mickey|office> probably upstream
May 10 11:06:41 <mickey|office> they still didn't change their policy to keep old versions
May 10 11:06:42 <mickey|office> *sigh*
May 10 11:07:33 <CIA-78> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r6169e44950 10openembedded.git/recipes/gnome/gnome-desktop_2.32.1.bb: (log message trimmed)
May 10 11:07:33 <CIA-78> gnome-desktop-2.32.1: disable desktop docs
May 10 11:07:33 <CIA-78> * we don't have gnome-doc-utils-native in DEPENDS to provide xml2po and it calls
May 10 11:07:33 <CIA-78> `which xml2po` -m docbook -e -t "${mo}"
May 10 11:07:33 <CIA-78> which doesnt work on host without xml2po
May 10 11:07:33 <CIA-78> * if we add gnome-doc-utils-native to DEPENDS then it still fails:
May 10 11:07:34 <CIA-78> | xsltproc -o fdl-C.omf --stringparam db2omf.basename fdl --stringparam
May 10 11:08:28 <mlip> JaMa, worked; elf class is ELF64 so this should be ok
May 10 11:08:55 <mlip> JaMa, (although log_compile says it's failing, but afaik this is a python build system issue)
May 10 11:09:55 <mlip> ah, -native works without stating that it failed ;), just the cross build thinks it has failed
May 10 11:10:45 <flitjes> hi guys, i've got a problem with compiling gst-plugins-good_0.10.25.bb. It fails because it cant find esd.h. Does anyone know how to solve this problem?
May 10 11:15:33 <Crofton> mickey|office, yes, they are annoying
May 10 11:16:21 * flitjes slaps luuk around a bit with a large trout
May 10 11:18:20 <woglinde> gm crofton
May 10 11:18:40 * flitjes slaps luuk around a bit with a large trout
May 10 11:19:17 <woglinde> bitbake esd
May 10 11:21:38 <flitjes> what do u mean by bitbake esd because we cant find the recipe for esd
May 10 11:23:59 <woglinde> libesd?
May 10 11:24:04 <woglinde> let me see
May 10 11:24:42 <woglinde> hm ah bitbake esound
May 10 11:25:06 <flitjes> ok that one exists gonna try it
May 10 11:26:48 <flitjes> autoreconf failed with exit status: 1
May 10 11:27:30 <flitjes> and error possible undifined macro: AM_PATH_AUDIOFILE
May 10 11:33:20 * flitjes slaps luuk around a bit with a large trout
May 10 11:34:46 <woglinde> that dont helps
May 10 11:37:53 * flitjes slaps luuk around a bit with a large trout
May 10 11:38:07 <woglinde> could you please stop your stupid script
May 10 11:38:31 <flitjes> not a script just screwing arround with my classmate tho ;)
May 10 11:38:47 <woglinde> no kindergarten here
May 10 11:41:07 <flitjes> didnt knew you guys could see it also tho, im new to mirc because classmates suggested to turn to here for some help 
May 10 11:41:41 <woglinde> most people here dont uses windows
May 10 11:48:48 * XorA uses windows
May 10 11:49:16 <JaMa> do we need separate PACKAGES for nativesdk.bbclass?
May 10 11:50:06 <JaMa> or can we force it empty like we does for native.bbclass? http://git.openembedded.org/cgit.cgi/openembedded/commit/classes/native.bbclass?id=c3604894c130a6596b16abb945d3c57fbf40ef39
May 10 11:50:32 <JaMa> we do
May 10 11:51:07 <woglinde> jama hm question for mailinglist?
May 10 11:52:22 <JaMa> woglinde: question whether to send my patch as RFC or not at all :)
May 10 11:52:56 <JaMa> I have it in my branch for a while, but I'm not actively using generated SDKs
May 10 11:53:08 * woglinde neither
May 10 11:59:25 <JaMa> ok, sent
May 10 12:07:02 <mckoan> woglinde, XorA : I tried to push my branch but there is something wrong http://pastebin.com/1NQ65VeL do you have any hint please?
May 10 12:07:43 <XorA> mckoan: you have never pushed from that repo?
May 10 12:08:10 <XorA> mckoan: you cant push to git:// addresses
May 10 12:09:16 <mckoan> XorA: actually I usually push this way : git push git@git.openembedded.org:openembedded
May 10 12:09:37 <XorA> mckoan: man you like the hard way :-D
May 10 12:09:50 <XorA> mckoan: add git@git..... to push-url entry in git config
May 10 12:10:08 <mckoan> XorA: this means I don't know the easy one ;-)
May 10 12:13:33 <mckoan> XorA: do you mean this? git config remote.origin.url=git@git://git.openembedded.org/openembedded
May 10 12:13:50 <XorA> mckoan: I just use vi
May 10 12:13:59 <JaMa> and no git@git://
May 10 12:14:06 <mckoan> ok
May 10 12:14:27 <XorA> I use url to bit git protocol and push-url to be ssh
May 10 12:15:03 <JaMa> but it has to be "git+ssh://git@git" or git@git only
May 10 12:15:15 <JaMa> "git@git://git" doesn't make sense
May 10 12:15:18 <XorA> git@git... seems to work fine
May 10 12:15:45 <woglinde> re hrw
May 10 12:16:16 <XorA> uses url and push-url means you can pull from github and be nice to ka6sox-sick and push to OE
May 10 12:21:37 <mckoan> I'm really sorry for my ignorance, but I never understood well this git remote.origin configuration
May 10 12:22:00 <mckoan> now I have : remote.origin.url=git@git.openembedded.org/openembedded
May 10 12:22:12 <mckoan> $ git push origin mckoan/kaeilos-2009
May 10 12:22:12 <mckoan> fatal: 'git@git.openembedded.org/openembedded' does not appear to be a git repository
May 10 12:22:15 <mckoan> fatal: The remote end hung up unexpectedly
May 10 12:22:49 <JaMa> mckoan: remote.origin.url=git@git.openembedded.org:openembedded
May 10 12:22:53 <JaMa> mckoan: see :
May 10 12:24:26 <XorA> mckoan: its exactly the same url as you would use for rsync or scp :-)
May 10 12:24:44 <XorA> and JaMa has given correct form
May 10 12:25:33 <mckoan> many thanks
May 10 12:26:30 <hrw> re
May 10 12:26:32 <mckoan> it worked
May 10 12:26:40 <XorA> hrw in dah hause
May 10 12:26:54 * JaMa also switched to github
May 10 12:27:27 <JaMa> mckoan: this could be handy too :) git remote set-url --push origin git@git.openembedded.org:openembedded
May 10 12:27:56 <hrw> XorA: ;D
May 10 12:28:36 <hrw> broonie: wake up - we need to meet finally
May 10 12:30:13 <XorA> hrw: never met the broonie? wow!
May 10 12:30:30 <hrw> XorA: not that I remember
May 10 12:30:53 <hrw> and I got info that he is here at uds-o
May 10 12:30:57 <XorA> hrw: come for Edin hols :-D
May 10 12:31:34 * XorA unfortuneately didnt make uds-o :-(
May 10 12:32:07 <hrw> XorA: do you have >10°C during summer there?
May 10 12:32:29 <XorA> it should hit 30-35 in August-September
May 10 12:32:51 <mckoan> JaMa: great, this should be in the wiki
May 10 12:32:54 <XorA> if current warm spell keeps up
May 10 12:34:13 <mckoan> JaMa: but this setting shouldn't be already be done by the first git clone git@git.openembedded.org:openembedded
May 10 12:34:23 <mckoan> ?
May 10 12:35:11 <XorA> mckoan: it will if you had first cloned that way, but you first cloned from git://
May 10 12:35:36 <mckoan> XorA: yep, you're right, now is clear
May 10 12:35:56 <XorA> anyway best setup for OE is pull from github, push to OE
May 10 12:36:03 <XorA> that lowers the load on the poor OE server
May 10 12:41:20 <JaMa> mckoan: the important part is --push.. so if you've cloned from github or http:// or git:// then you just switch pushurl without need to know .git/config syntax
May 10 12:41:56 <JaMa> s/cloned/cloned or changed url to/g; s/switch/add different/g; 
May 10 12:45:16 <woglinde> ogra to broonie?
May 10 12:45:30 <CareBear\> ok so who is running the linuxtag booth?
May 10 12:45:36 <CareBear\> maybe Florian?
May 10 12:45:44 <CareBear\> ping he. :)
May 10 12:45:51 <woglinde> ups
May 10 12:46:08 <woglinde> carebear florian,robertsch,zecke and me
May 10 12:46:20 <woglinde> why?
May 10 12:47:03 <CareBear\> I'm standing in the booth and want to remodel a little :)
May 10 12:47:15 <woglinde> hm
May 10 12:47:20 <woglinde> in which manner?
May 10 12:47:40 <CareBear\> as you might know the c-base moon guys are not coming
May 10 12:47:42 <CareBear\> so we have more space
May 10 12:47:55 <woglinde> no
May 10 12:47:58 <CareBear\> yes
May 10 12:48:00 <CareBear\> :)
May 10 12:48:01 <woglinde> dont know that
May 10 12:48:03 <CareBear\> aha
May 10 12:48:06 <CareBear\> it's true!
May 10 12:48:22 <woglinde> more space sounds good
May 10 12:48:29 <CareBear\> currently the way the booth is set up your small table and large table are a little spread out and not really near your sign
May 10 12:48:41 <CareBear\> also they're in the back, not out by the isle
May 10 12:49:42 <CareBear\> it's difficult to do this over IRC maybe so unless someone is coming here later/soonish I guess I'll just try to do something clever
May 10 12:49:58 <CareBear\> but it would help to know what and how you guys plan to use the tables?
May 10 12:51:28 <woglinde> hm we have a 17" monitor
May 10 12:51:32 <woglinde> ups 21
May 10 12:51:42 <CareBear\> http://stuge.se/lt201_7b112.jpg
May 10 12:51:52 <CareBear\> meh
May 10 12:51:55 <CareBear\> http://stuge.se/lt2011_7b112.jpg
May 10 12:52:13 <CareBear\> the large table to the left is yours
May 10 12:52:49 <CareBear\> there are two small tables but three were requested (Kamailio, OE, flashrom+coreboot)
May 10 12:52:55 <CareBear\> I think we can play nice with the small table
May 10 12:53:05 <CareBear\> but question is where would be clever to put stuff
May 10 12:53:33 <CareBear\> I guess you want the large table over by where the name is?
May 10 12:54:11 <woglinde> on the left side is nobody?
May 10 12:54:16 <CareBear\> correct
May 10 12:54:26 <CareBear\> the name signs do not come apart
May 10 12:54:37 <CareBear\> ie. can not split Kamailio from OE easily
May 10 12:55:00 <CareBear\> but I could ask for new signs if you insist
May 10 12:55:07 <woglinde> hm
May 10 12:55:09 <CareBear\> (on your behalf)
May 10 12:55:31 <woglinde> dont know if they would do it
May 10 12:55:37 <CareBear\> me also not
May 10 12:55:40 <CareBear\> anyway
May 10 12:55:56 <CareBear\> coreboot and flashrom are good friends so I was thinking that we would hog the left side
May 10 12:55:57 <CareBear\> :)
May 10 12:56:21 <CareBear\> by moving the counter to the left
May 10 12:56:28 <woglinde> that would be okay
May 10 12:56:31 <rschus> CareBear\: would it make sense to move the tables around a bit?
May 10 12:56:44 <woglinde> CareBear yor are from Kamailio?
May 10 12:56:46 <CareBear\> on the other hand that is really stupid thinking of me because we want to be close to our name signs
May 10 12:56:56 <CareBear\> woglinde : I'm coreboot and a bit of flashrom
May 10 12:57:01 <CareBear\> rschus : I think so
May 10 12:57:13 <CareBear\> you'll put the 17" on the large table?
May 10 12:57:16 <CareBear\> and show stuff on?
May 10 12:57:21 <woglinde> 21
May 10 12:57:25 <CareBear\> 21 sogar
May 10 12:57:25 <CareBear\> ok
May 10 12:57:33 <CareBear\> then good that it's a large table! :p
May 10 12:57:35 <rschus> CareBear\: the door in the back is supposedly not to be blocked, I suppose
May 10 12:58:05 <rschus> otherwise I'd put the large table there and you guys claim the remaining space as you see fit
May 10 12:58:08 <woglinde> CareBear hm would you mind to take the left side?
May 10 12:58:09 <CareBear\> rschus : it could be blocked if noone in the booth cares, but inside there is network and power distribution
May 10 12:58:18 <zecke> rschus: ping. Should I print the poster in A1 and A2 today? or A0 and A2?
May 10 12:58:27 <zecke> rschus: and do you think the grey is okay?
May 10 12:58:38 <woglinde> Kamailio more to the mid and oe the large table to the right?
May 10 12:58:42 <CareBear\> maybe I should just move stuff around so that the furniture we requested is actually underneath the signs with respective names?
May 10 12:58:52 <CareBear\> woglinde : that's what I'm thinking
May 10 12:59:05 <CareBear\> the large table probably fits perfectly if stood against the right wall
May 10 12:59:20 <CareBear\> but maybe you want it to be facing outwards?
May 10 12:59:21 <woglinde> cool
May 10 12:59:22 <woglinde> yes
May 10 12:59:33 <woglinde> no that would be okay
May 10 12:59:51 <CareBear\> let's see. I'll try..
May 10 12:59:52 <woglinde> we can change it anyway
May 10 12:59:57 <woglinde> make a picture
May 10 13:00:01 <woglinde> *g*
May 10 13:02:19 <CareBear\> actually the table is a lot smaller than the space on the right
May 10 13:02:56 <XorA> this is like tetris where the players cant see the screen and CareBear\ has to describe it
May 10 13:04:15 <CareBear\> :)
May 10 13:04:19 <CareBear\> I send photos
May 10 13:04:42 <XorA> Massively Multiplayer Tetris :-D
May 10 13:04:54 <CareBear\> anyone tried tetrinet?
May 10 13:06:04 <CareBear\> http://stuge.se/7b112_table_right.jpg
May 10 13:06:45 <CareBear\> http://stuge.se/7b112_move1.jpg
May 10 13:07:39 <CareBear\> I think it's also fine to turn the table with the long side toward the isle
May 10 13:08:30 <woglinde> I wondower what Kamailio has ordered?
May 10 13:08:40 <woglinde> I only see 3 deks
May 10 13:08:43 <woglinde> desks
May 10 13:08:43 <CareBear\> 1 infopoint, 2 bar chairs, 1 small table, 2 chairs, 1 small literature rack P3. 
May 10 13:08:57 <CareBear\> (yes I have the wiki page open)
May 10 13:09:27 <CareBear\> right; there is one small table less than our combined requests
May 10 13:10:16 <woglinde> and what did folrian ordered for us?
May 10 13:10:50 <CareBear\> 1 large table, 1 small table, 2 bar chairs, 2 chairs 
May 10 13:11:22 <sakoman_> Crofton|work: I'm working on updated recipes for python-pyqt, python-sip, and sp-native
May 10 13:11:29 <CareBear\> damn this counter is heavy
May 10 13:11:38 <woglinde> sakoman_? mickeyl did that too
May 10 13:11:41 <sakoman_> all have issues with missing tarballs upstream
May 10 13:11:55 <woglinde> besides missing archivs
May 10 13:12:44 <sakoman_> woglinde: my pull was from yesterday am and all 3 failed
May 10 13:12:51 <woglinde> hm the bar chairs without infopoint makes no sense
May 10 13:13:06 <CIA-78> 03Marco Cavallini <m.cavallini@koansoftware.com> 07master * rd5e59ef9e7 10openembedded.git/MAINTAINERS: MAINTAINERS: removed xorg xinput-calibrator mantainers from my profile
May 10 13:13:22 <pb_> woglinde: unless you plan to have a bar, right?
May 10 13:13:27 * woglinde scratches head
May 10 13:13:31 <pb_> sounds like an outstanding plan to me
May 10 13:13:38 <CareBear\> woglinde : bar chairs are better than having to stand
May 10 13:13:45 <woglinde> pb they dont fit onto small and large table
May 10 13:13:54 <CareBear\> it's a nice way to relax a little and still be accessible to visitors
May 10 13:13:56 <CareBear\> well
May 10 13:14:09 <woglinde> carebear sure
May 10 13:14:23 <CareBear\> florian has been here many times enough to know :)
May 10 13:14:28 <CareBear\> maybe you too
May 10 13:14:44 <woglinde> CareBear I attend a lot of fairs yes
May 10 13:14:50 <CareBear\> as exhibitor?
May 10 13:14:53 <woglinde> yes
May 10 13:14:55 <CareBear\> cool
May 10 13:15:00 <CareBear\> yeah then you know
May 10 13:15:15 <woglinde> sure and bar chairs make sense with an info point desk
May 10 13:15:18 <CareBear\> come saturday the bar chairs will be like a cool blanket on a warm summer sunday morning in bed
May 10 13:15:48 <CareBear\> yes even more
May 10 13:15:49 <CareBear\> but I think still useful with the desk
May 10 13:16:41 <woglinde> hm okay then we need the table to the front
May 10 13:16:50 <woglinde> and I wonder where to put the small table
May 10 13:17:16 <CareBear\> table to the front is ok
May 10 13:17:25 <CareBear\> what's your plan for the small table?
May 10 13:17:40 <woglinde> by lookin at the booth, I dont really know
May 10 13:17:55 <CareBear\> we (coreboot+flashrom) wanted one to have a meeting point and a spot a little to the side to maybe sit down with more important booth visitors and chat, or even an interview
May 10 13:18:07 <CareBear\> VIP lounge if you will :p
May 10 13:18:11 <woglinde> only sane would be to combine it with the large table
May 10 13:18:42 <woglinde> but there isnt the space for it
May 10 13:20:05 <CareBear\> only "inwards"
May 10 13:20:22 <CareBear\> I guess you can fight with Kamilio about it ;)
May 10 13:21:00 <CareBear\> oh
May 10 13:21:08 <CareBear\> there are 2 bar chairs less than totally requested
May 10 13:21:31 <woglinde> uhm lol
May 10 13:22:06 <CareBear\> if that is the 2 you requested or the 2 Kamailio requested, I can't say ;p
May 10 13:23:02 <woglinde> hm wonderfull
May 10 13:23:48 <CareBear\> hmm
May 10 13:23:52 <CareBear\> the booth gets really empty
May 10 13:23:59 <CareBear\> when moving things around a little
May 10 13:24:52 <woglinde> hm hm
May 10 13:25:09 <woglinde> I think we will decide tomorrow
May 10 13:25:16 <woglinde> let it as it no
May 10 13:25:17 <woglinde> w
May 10 13:25:24 <woglinde> maybee ask for the barchairs
May 10 13:25:42 <woglinde> and thanks for notice us
May 10 13:26:19 <CareBear\> hold for move2.jpg
May 10 13:31:43 <CareBear\> http://stuge.se/7b112_move2.jpg http://stuge.se/7b112_move2_inside1.jpg http://stuge.se/7b112_move2_inside2.jpg http://stuge.se/7b112_move2_inside3.jpg http://stuge.se/7b112_move2_inside4.jpg
May 10 13:33:05 <XorA> when do the booth babes arrive :-D
May 10 13:33:31 <woglinde> xora you dressed up
May 10 13:33:35 <woglinde> ups when
May 10 13:33:44 <woglinde> and come over to act as one
May 10 13:33:55 <XorA> woglinde: that isnt unknown for me :-D
May 10 13:34:21 <XorA> but I dont make much of a babe
May 10 13:34:32 <CareBear\> woglinde : in one way the "front" of the booth is ok now, but it's *really* empty in the back
May 10 13:34:34 <CareBear\> and in the corner
May 10 13:34:40 <CareBear\> which is dumb
May 10 13:35:51 <woglinde> CareBear hm I would prefer putting our small table to our large table
May 10 13:36:00 <woglinde> and mov all desks to left
May 10 13:36:07 <woglinde> but thats only me
May 10 13:36:32 <CareBear\> woglinde : I see the point. unfortunately it messes up alignment for the signs above then :\
May 10 13:36:51 <woglinde> not really
May 10 13:37:00 <woglinde> look at http://stuge.se/7b112_move2.jpg
May 10 13:37:53 <CareBear\> yep?
May 10 13:38:25 <CareBear\> well maybe the K infopoint can scoot over a bit
May 10 13:38:26 <woglinde> if you move your vitrine to the left of the booth 
May 10 13:38:35 <woglinde> it would match too
May 10 13:38:42 <CareBear\> yes, actually already did that
May 10 13:38:48 <CareBear\> the 1dm or so
May 10 13:39:37 <woglinde> no completly left of the bearer
May 10 13:40:06 <woglinde> hms
May 10 13:42:28 <CareBear\> you mean where there is no name sign above? ;)
May 10 13:43:46 <CareBear\> http://stuge.se/7b112_move3.jpg
May 10 13:44:01 <woglinde> yes
May 10 13:44:25 <CareBear\> it sorta kinda fits
May 10 13:44:37 <CareBear\> but the Kamailio lit rack does not have a lot of space
May 10 13:44:44 <CareBear\> and it's REALLY empty in the back
May 10 13:45:00 <CareBear\> that is much more visible when standing up and looking into the booth
May 10 13:45:07 <CareBear\> it looks naked
May 10 13:45:08 <CareBear\> :(
May 10 13:45:16 <CareBear\> (although naked is usually good)
May 10 13:45:27 <CareBear\> but not the booth
May 10 13:47:17 <woglinde> okay
May 10 13:47:30 <woglinde> let it as it is on move3
May 10 13:48:03 <woglinde> we will see tomorrow
May 10 13:48:21 <woglinde> without kamailo guys
May 10 13:48:25 <woglinde> its useless
May 10 13:49:40 <CareBear\> http://www.google.com/search?q=kamailio+irc
May 10 13:49:59 <CareBear\> http://www.kamailio.org/w/irc-channels/
May 10 13:50:09 <CareBear\> irc.freenode.net #kamailio
May 10 13:50:17 <broonie> hrw: I've been here since 9am
May 10 13:52:04 <woglinde> lol
May 10 13:52:07 <woglinde> hi broonie
May 10 13:52:24 <woglinde> carebear did they answer?
May 10 13:52:56 <CareBear\> stone dead :(
May 10 14:06:54 <zecke> woglinde: i finished plotting.
May 10 14:08:23 <pb_> zecke: I think the essence of a successful plot is that you're meant to keep it secret
May 10 14:08:52 <mickey|office> heh
May 10 14:09:28 <woglinde> zecke you will come tomorrow to the fair?
May 10 14:24:38 <woglinde> re hrw
May 10 14:33:20 <CareBear\> woglinde : I got an email address now
May 10 14:33:27 <CareBear\> they're all serious with schedules and shit
May 10 14:33:30 <CareBear\> http://sip-router.org/wiki/meetings/berlin_2011
May 10 14:35:14 <woglinde> hm I see troubles
May 10 14:35:29 <woglinde> the equipment will not fit on the infodesk
May 10 14:35:49 <woglinde> and we have a lot of equipment too
May 10 14:47:55 <Crofton|work> woglinde, can you show different sets of hw each day?
May 10 14:48:07 <woglinde> hm
May 10 14:48:16 <woglinde> maybee
May 10 14:49:26 <XorA> start hanging boards from the ceiling
May 10 14:49:40 <woglinde> nah
May 10 14:49:50 <woglinde> people think they can grab one
May 10 14:55:18 <tharvey> khem, so I've built meta-toolchain from release-2011-03 as well as poky1.0 and think I have some more intelligent questions/observations now regarding sdk.
May 10 14:56:54 <tharvey> to use sdk against a project that uses autoconf is it expected that you would use 'autoreconf' prior to running ./configure --host=$TARGET_SYS ?
May 10 14:57:27 <tharvey> otherwise configure makes all kinds of horrible decisions based on the host system, such as looking for X in / etc
May 10 15:00:04 <tharvey> while libtool 2.4 is in my sdk (by virtue of libtool-sdk) on x86_64 instead of being 'libtool' its x86_64-linux-libtool (in the PATH as modified by the SDK) - I'm still not clear when/if libtool is used while using the sdk to cross-compile
May 10 15:02:44 <kergoth> tharvey: most projects include their own copies of the libtool macros, ltmain.sh, etc, so wouldn't get our improvements
May 10 15:02:49 <Crofton|work> we need an OpenEmbedded mobile
May 10 15:02:49 <kergoth> they don't run the 'system' libtool script
May 10 15:02:54 <kergoth> so it would make sense
May 10 15:06:07 <kergoth> okay, i'm not used to seeing oe commits all over my github dashboard
May 10 15:06:29 <kergoth> too bad it shows duplicates for master + org.openembedded.dev
May 10 15:07:19 <tharvey> kergoth, not understanding what your saying.  Your saying it doesn't matter if libtool is provided in the sdk or not if a project doesn't call it?  I'm trying to understand how libtool and sysroot support in libtool is supposed to magically make things better.  The way I see it is something as simple as gd (a lib that utilizes other libs) is not being built correctly (or at all in some cases) with meta-toolchain
May 10 15:08:04 <kergoth> tharvey: yes. most projects ship their own libtool and use that, they don't rely on what you have unless you force the matter or re-run libtoolize, which autoreconf does
May 10 15:08:31 <kergoth> there's a reason we run autoreconf in everything for our recipes :)
May 10 15:08:38 <kergoth> libtool is the biggest reason
May 10 15:09:14 <tharvey> yes, thats what I thought.  Ok so all these docs that I'm reading that say in order to use the sdk 'simply' run ./configure --host=$TARGET_SYS are just plain wrong - or at best work for 'some' projects
May 10 15:09:38 <kergoth> heh, by now you should know crosscompiling is never that easy ;)
May 10 15:10:20 <tharvey> other projects require 'what' exactly?  I see how for example gd built within OE runs autoreconf wiht a bunch of options, should I assume that its always safe to do it that way using oe generated sdk as well?
May 10 15:11:13 <kergoth> crosscompiling without something like oe is never trivial.  autoreconf -f should cover your bases, that forces it to ignore timestamps and make certain things are regenerated
May 10 15:11:26 * kergoth thinks
May 10 15:12:03 <tharvey> I don't see autoreconf run with any magic 'sysroot' option, but I do see it run with a -Wcross --install --force --exclude=autopoint and some -I's which point into sysroots aclocal dirs
May 10 15:12:27 <tharvey> I would assume those -I args are critical to point it to the sdk's ac configs?
May 10 15:13:06 <kergoth> the -Wcross is just a warning thing, excluding autopoint is only required in certain cases.  the -I's probably are required though, indeed :(.  you can try without it, it will check its hardcoded path, but that only covers part of it, i think
May 10 15:13:31 <kergoth> i have a commit on a personal branch that uses wrappers to make autoconf more relocatable without all those args, maybe i should get that merged
May 10 15:13:32 <kergoth> heh
May 10 15:15:08 <tharvey> oe also looks to be doing some magick to determine those '-I's though, need to find out where thats coming from
May 10 15:15:25 <tharvey> yes, I would think your wrappers would make a ton of sense for anyone trying to support an SDK
May 10 15:16:15 <tharvey> can you point me to what you have?
May 10 15:16:24 <kergoth> it's basically just making sure all the autoconf and aclocal search paths in the current sysroot(s) are hit. there's no reason it couldn't determine them based on its current location though
May 10 15:18:47 <kergoth> hrm, damn, this isn't ideal either.  it only covers the 'autoconf' datadir, not the aclocal ones, and it still ends up with hardcoded paths in it, just the current ones, it generates the wrappers when it goes into the sysroot.  no reason we couldn't do something similar but with relative paths though
May 10 15:18:50 <kergoth> https://github.com/kergoth/openembedded/commit/2abceee79e521764464f4a81bf9ee9ae68249ef6
May 10 15:19:04 <kergoth> was a work in progress, wanted to start moving away from our sed mangling everything in favor of things being more relocatable
May 10 15:19:26 <tharvey> so is nobody using meta-toolchain then if its so broken?
May 10 15:19:54 <tharvey> (for autoconf projects that is)
May 10 15:20:20 <kergoth> I don't know that i'd go that far, i'm just guessing based on what you've said and all, I can't imagine it's that broken for such a common case.. unless everybody manually reruns autoreconf, or forces the libtool
May 10 15:20:29 <kergoth> you could force it instead, see how that works
May 10 15:20:38 <kergoth> make LIBTOOL=/path/to/sdk/libtool
May 10 15:20:40 <kergoth> or something
May 10 15:20:44 * kergoth scratches head
May 10 15:20:58 <tharvey> I'm not uderstanding why on earth CPATH and LIBTOOL_SYSROOT_PATH are exported from the SDK if they are not used anywhere.  I also find that CONFIG_SITE while is very useful to configure points to an empty file
May 10 15:21:43 <kergoth> well, if the upstream already happens to use a libtool that obeys LIBTOOL_SYSROOT_PATH, then things would probably work fairly well
May 10 15:21:45 <kergoth> but *shrug*
May 10 15:21:58 <kergoth> maybe ask khem, he's the libtool 2.4 guy :)
May 10 15:22:00 <tharvey> in the sdk simply running 'autoreconf; ./configure --host=$TARGET_SYS' ends up bailing out in configure with all kinds of 'invalid options' errors to libtool
May 10 15:22:20 <kergoth> ouch
May 10 15:22:22 <tharvey> ya, have a question out to him
May 10 15:22:39 <tharvey> when you say upstream, in this case you mean the host using hte sdk?
May 10 15:22:47 <kergoth> i mean gd
May 10 15:22:59 <kergoth> the thing you're building
May 10 15:23:15 <kergoth> autoconf based projects generally ship with certain 'maintainer' files ready to go, so the average user doesn't  need to rerun things like autoconf
May 10 15:23:27 <kergoth> that includes ltmain.sh, which is the core of the libtool script
May 10 15:23:34 <kergoth> ./configure uses that to generate the libtool it runs
May 10 15:24:30 <kergoth>  oh, right, it's automake thats aclocal, adn its aclocal that needs most of those -I's, so perhaps https://github.com/kergoth/openembedded/commit/37b34e25816444a2d02eb0670e222c7e2f20567e really does solve it, it doesn't just use a wrapper, it determines the paths relatively programmatically with perl
May 10 15:25:13 <kergoth> (i doubt anyone has tested it but me though :)
May 10 15:26:26 <tharvey> so that patch is patching OE's automake - how does that affect upstream projects like in my example gd?
May 10 15:27:55 <kergoth> with that, you would potentially be able to run autoreconf -f without specifying the -I paths
May 10 15:28:04 <kergoth> doesn't fix everything, but would be a step in the right direction
May 10 15:28:45 <tharvey> I shouldn't have said autoreconf causes configure to bail out... looks like they are all warnings
May 10 15:28:57 <kergoth> but, i'm not aware of what all the sdk/meta-toolchain stuff does, maybe its already not necessary, no clue, guessing here :)
May 10 15:29:22 <tharvey> however it doesn't seem to solve anything either... grep ^CPPFLAGS Makefile still shows -I/usr/include/freetype2  -I/usr/include/libpng12  - host based dirs
May 10 15:31:26 <kergoth> i suspect that's quite independent of libtool, if it's in the makefile.  check the Makefile.am for silly things like -I@includedir@/freetype2.  we often have to patch things like that out in oe..
May 10 15:31:32 * kergoth shrugs
May 10 15:32:29 <tharvey> still don't see how your change to automake factors into the sdk - is it whats responsible for generating the *.m4's contained in the sdk?
May 10 15:33:09 <kergoth> no, the change to aclocal means aclocal will correctly use all the macros available in the sdk when generating the aclocal.m4
May 10 15:33:23 <kergoth> its about your running of autoreconf from the sdk, not about creation of the sdk
May 10 15:34:22 <tharvey> meta-toolchain built sdk in both release-2011-03 as well as poky, doesn't have any *.m4 files - what is supposed to be passed as '-I's to autoreconf?
May 10 15:35:39 <kergoth> does meta-toolchain not include autoconf and automake?
May 10 15:36:02 * kergoth kicks off a meta-toolchain build so he can poke around
May 10 15:36:17 <tharvey> sorry, I'm wrong about that... there are .m4's in the <sysroots>/usr/share/aclocal
May 10 15:37:31 <tharvey> ok so you want to give autoreconf the dir to your SDK's aclocal in its search path, and the files in the sdk aclocal are created by automake which your patch tweaks?  
May 10 15:38:29 <kergoth> i just want to make sure the sdk autoreconf finds those files in share/aclocal, which is all the -I's passed in autotools.bbclass do.  if the sdk is in the SDKDIR or whatever, it likely finds it already, so its a nonissue.
May 10 15:41:17 <kergoth> in which case just running autoreconf -f should be just fine.  if tehre are other issues beyond that, that won't fix them. there are lots of potential issues in crosscompiling anything, unfortunately
May 10 15:42:07 <tharvey> I see two aclocal dirs in the SDK that contain .m4's:  $SDK_PATH/share/aclocal and $SDK_PATH/$TARGET_SYS/usr/share/aclocal - how do those differ?
May 10 15:43:05 <tharvey> If I can get 'autoreconf -f -I<foo>' to end up producing a configure script that results in a valid Makefile, then I'll test your patch to see if it eliminates the need to include <foo>
May 10 15:43:14 <tharvey> still trying to determine what dir(s) <foo> should be
May 10 15:43:34 <ensc|w> is there some trick to create symlinks in staged sysroots? I have an amend.inc http://pastebin.com/ny2J4Q4v for eglibc but the symlinks show up in the final package only, not in the sysroot
May 10 15:44:11 <tharvey> ensc|w, you have them in do_install_append, seems like you would want them in do_stage_append?
May 10 15:44:15 <kergoth> ensc|w: *if* the recipe uses new style staging, then installing anything in do_install will result in it ending up in the sysroot, unless it uses a hook to manipulate what gets installed in the sysroot
May 10 15:44:26 <kergoth> if the recipe uses the old style, then as tharvey says, do_stage
May 10 15:46:51 <ensc|w> afais, eglibc does not have any stage/sysroot tasks
May 10 16:03:56 <ensc|w> kergoth: really? sysroot_stage_dirs copies only a set of directories; not the whole ${D}
May 10 16:04:20 <ensc|w>  /lib64 and /usr/lib64 are not a member of this set of directories
May 10 16:04:20 <kergoth> hrm
May 10 16:04:25 <kergoth> i forgot about that, that's silly
May 10 16:08:30 <tharvey> kergoth, still can't seem to find the magic options to autoreconf/configure to make SDK 'as-is' work - I'll see if khem can shed any light on it then revisit your patch
May 10 16:09:40 <kergoth> hrm, okay
May 10 16:09:52 <kergoth> i'll see if i can come up with anything poking at it myself
May 10 16:10:22 <tharvey> so I finally poked around (no pun intended) with poky and yocto - I'm not sure I understand where everything is headed.  will openembedded repo remain alive and well?  seems like poky repo (openembedded-core) pulls in recipes from oe when needed
May 10 16:10:49 <fray> tharvey a more formal announcement should be out soon... but..
May 10 16:11:08 <kergoth> The OE repo will eventually just be a repository of old recipes that haven't been pulled over to where the real work is done, as far as I understand it
May 10 16:11:11 <fray> oe-core will be a base "non-distribution" set of software.. based on poky, yocto and open embedded (existing)
May 10 16:11:17 <tharvey> not really clear why all the directory structure reorg had to happen, the reasons were to make it easier to find things yet I find it more difficult now that I have to look through many subdirs (just use find to be easy no?).  Moving thigns to a new repo looses all history as well
May 10 16:11:30 <fray> meta-oe will likely take the place of the existing repository.. a place for all sorts of software to be added..
May 10 16:11:34 <fray> but the core will be small
May 10 16:12:36 <fray> tharvey it is for ease of management, as well as eventual clearer "management" of the components.. i.e. if someone becomes a graphics expert, then they could become the maintainer of the graphics components.. handling pulls, making sure that things are reasonable for checkin etc.. (oe-core view)
May 10 16:12:44 <fray> meta-oe, the idea is similar.. but still forming
May 10 16:13:16 <tharvey> ok... so segregating into layers such that each layer is more individually maintainable?
May 10 16:13:31 <fray> yes..  thats the primary thing..
May 10 16:13:32 <tharvey> trying to not think all this reorg isn't just an intel 'not invented here' thing
May 10 16:13:56 <fray> oe has so much software that it's simply hard for us, all of us, to understand what is there.. and if we make a change, what is the related software for the change that we should attempt to verify still works
May 10 16:14:10 <ensc|w> are there plans to sync oe-meta with oe-dev?  oe-dev contains some enhancements in core parts which are not in oe-core yet
May 10 16:14:19 <fray> ya, it's not an intel thing....  (I can admit I'm somewhat respnsible for some of the reorg as well)
May 10 16:14:21 <tharvey> I notice oe-core has one linux kernel recipe... so all the support for things like linux-omap kernels that haven't made it all into mainline will be moved to bsp layers?
May 10 16:14:42 <fray> ensw|w we're working on that.. something that we need to continue to work on.. there will be two items..
May 10 16:14:58 <fray> things that are "standard" (ya I know, sometimes hard to define), will go into oe-core..  we need to merge them
May 10 16:15:05 <tharvey> I fail to see how oe-core + layer1 + layer2 + layer3 won't become the same 'difficult to know what works' mess
May 10 16:15:25 <tharvey> you can't simply things without removing a lot of functionality...
May 10 16:15:32 <fray> for things that are experimental, or not necessarily based.. they can be done in a layer, adding or overriding to oe-core version until it's agreed to be "the right answer"
May 10 16:15:52 <fray> we're working on layer tooling to help with all of that.. but it's not ready yet..
May 10 16:16:20 <fray> tooling is going to help with people working with layers to identify what code is being used.. since it can be confusing which recipe, fragments, configuration, etc was used with lots of layers..
May 10 16:17:01 <fray> similarly, we need tooling to help identify which layers are compatible, incompatible, etc.. and thats being figured out still... it's more complicated then simply adding a few compatibility fields.. we need to be able to process them and warn users, etc..
May 10 16:17:11 <fray> (sometimes compatibility may simply be layer inclusion order..)
May 10 16:18:08 <fray> oe-core is also an attempt to get the various oe-derived distributions to shared a common base of work..
May 10 16:18:34 <fray> this helps answer some of the complaints that "oe is too big and confusing"
May 10 16:24:06 <tharvey> where do the current layers exist?  I see meta-openembedded in OE's repo but not really clear what that is intended to add.  In the poky docs I see mention of bsp layers but haven't found where they are located.
May 10 16:25:02 <tharvey> also very confused by what 'sato' and 'bernard' are - are those supposed to be release names?  the current release 'tarball' is poky-bernard-5.0 which seems very wrong.  I also see 'sato' in recipe names such as sdk recipes and not clear what that is all about
May 10 16:26:14 <kergoth> meta-oe is where the general things that aren't core are going, afaik.
May 10 16:26:30 <kergoth> angstrom has layers on its git server
May 10 16:26:35 <fray> tharvey there will be documentation focused on oe-core..  "poky" is going away...
May 10 16:26:56 <fray> generally the thought is if you want what current oe is, you'd get bitbake, oe-core and meta-oe
May 10 16:27:08 <fray> (currently though meta-oe + oe-core is a fraction of what is in current oe)
May 10 16:31:30 <tharvey> ok, thats what confused me - lots of things missing from oe-core+meta-oe.  So at some point in the near future people will move over to oe-core+meta-oe and stop committing to openembedded repo - is this perhaps weeks or months away and who decides what gets moved into meta-oe and what goes the way of the dinosaur?
May 10 16:32:22 <fray> as of right now -- the thought is that as things are needed from "oe", they'll migrate to meta-oe (or oe-core)..
May 10 16:32:44 <fray> for the items that over time don't migrate, then they were likely not needed anymore -- or simply obsolete..
May 10 16:33:09 <fray> the existing openembedded repo won't simply disappear.. but it will be abandoned over time.. and the future is the oe-core + meta-oe + additional layers..
May 10 16:33:18 <fray> additional layers would be things like angstrom, BSPs, etc..
May 10 16:33:51 <fray> (as I think I mentioned above.. oe-core isn't a distro.. but meta-oe is..)
May 10 16:34:15 <fray> oe-core will have some distro like components, to enable basic sanity checking, testing..
May 10 16:35:09 <fray> ohh someone I think mentioned the kernel.. the unified kerenl in oe-core only supports the QEMU targets.. again for testing... we (yocto project) think BSPs should be based on it, but we (oe-tsc) realize that everyone has their own BSPs, and their own way of doing things.. so there will be NO MANDATE for how kernels work in OE
May 10 16:35:59 <fray> (now if the oe eV eventually think there is one proper way to do BSPs, the TSC is likely to start advocating that.. but at this point, the agreement is there is no concensus on this)
May 10 16:36:50 <tharvey> can you explain what 'sato' and 'bernard' are?
May 10 16:37:31 <fray> sato is a demo user-interface.. won't be in oe-core
May 10 16:37:41 <carstenbock> Hi anyone taking care of the LinuxTag booth here?
May 10 16:37:49 <fray> bernard is the "codename" for the Yocto Project's Poky 1.0.1.. it doesn't mean anything in terms of oe-core
May 10 16:38:16 <carstenbock> I am with the Kamailio project (your neighbour) and it seem we have a little problem with the furniture...
May 10 16:38:18 <fray> (there is some question if sato will be in meta-oe, or the meta-yocto... or somewhere else..)
May 10 16:41:44 <tharvey> fray, ok - good explanations... sounds like I'm not as 'behind the curve' as I thought and that thinks will start taking shape soon
May 10 16:41:49 <tharvey> thx
May 10 16:42:27 <fray> the (slightly moving plan) is that we're going to invite the rest of OE (not that we're stopping anyone is oe today) to use oe-core in the next week..
May 10 16:42:51 <fray> I think we've gotten all of the "show stoppers" resolved that the TSC identified... but we've got a meeting on Thursday to discuss this and make a formal recommendation..
May 10 16:43:17 <fray> Poky (as it was) was not acceptable for the oe community..  so we had to make the right changes to get it there..
May 10 16:43:26 <fray> those changes are almost complete today..
May 10 16:43:54 <fray> (again whole point of oe-core, lets all [not just oe developers] avoid redoing the same things over and over, that we can agree on]
May 10 17:27:31 <bioster> Hi, I'm wanting to use locate & updatedb on my Angstrom distribution... how would I find the package that contains them?
May 10 17:28:09 <woglinde> bioster uhm?
May 10 17:28:28 <bioster> Sorry, I asked on the #angstrom channel, but they're all asleep...
May 10 17:29:18 <woglinde> hm I just wonder why you really need it on the target
May 10 17:29:31 <woglinde> man pages aren installed at default
May 10 17:29:50 <bioster> Mainly because I use locate a lot, to find files I'm interested in.
May 10 17:29:58 <woglinde> find?
May 10 17:30:19 <woglinde> which should be fast
May 10 17:30:29 <bioster> well, doesn't find have to go through the entire system every time?
May 10 17:30:34 <woglinde> sure
May 10 17:30:45 <woglinde> how many files you have on the target?
May 10 17:31:03 <woglinde> let me see if we have a recipe for mlocate
May 10 17:32:16 <tharvey> don't see anything
May 10 17:34:16 <bioster> Where would I be able to search through lists of recipes myself, so I can figure this sort of stuff out?
May 10 17:35:21 <woglinde> bioster write the mlocate recipe yourself
May 10 19:15:11 <pb_> woglinde: can you remind me which branch it was that you wanted deleting?
May 10 19:15:22 <woglinde> woglinde/gettext
May 10 19:16:03 <pb_> righto
May 10 19:29:08 <sakoman_> is anyone aware of a command line image (i.e. jpeg) display utility package in OE? 
May 10 19:29:29 <woglinde> dfbpoint maybee?
May 10 19:29:38 <woglinde> needs directfb
May 10 19:29:58 <woglinde> and dont know if its working with actual dfb
May 10 19:30:30 <sakoman_> woglinde: thanks, will take a look at it
May 10 19:32:59 <pb_> woglinde: okay, it's gone. 
May 10 19:33:07 <woglinde> thanks
May 10 19:33:55 <woglinde> hm ah no
May 10 19:34:00 <woglinde> dfbsee I guess it is
May 10 19:34:28 <woglinde> yes
May 10 19:34:35 <woglinde> but may not work anymore
May 10 19:36:04 <sakoman_> woglinde: do you know which recipe builds dfbsee?
May 10 19:36:18 <sakoman_> not directfb, perhaps examples?
May 10 19:38:29 <woglinde> http://directfb.org/index.php?path=Projects%2FDFBSee
May 10 19:38:38 <woglinde> hm maybee we need an recipe
May 10 19:40:38 <likewise> gm
May 10 19:41:25 <pb_> out of interest, what is poky.conf doing in oe-core?  shouldn't that be in some kind of poky layer
May 10 19:41:27 <pb_> ?
May 10 19:41:45 <woglinde> pb ask on #yocto?
May 10 19:42:01 <woglinde> hi likewise
May 10 19:43:40 <likewise> pb_: good point, but oe-core is still to be made distro-less. 
May 10 19:44:04 <likewise> pb_: I think RP means to remove everything poky once it can be built distro-less.
May 10 19:44:20 <likewise> pb_: but pls do ask
May 10 19:49:31 <khem> pb_: RP posted patches today 
May 10 19:49:44 <khem> pb_: eventually drive is to get oe-core distroless
May 10 19:50:41 <woglinde> hi khem
May 10 19:50:47 <khem> woglinde: hello
May 10 19:57:42 <sakoman_> woglinde: seems that imagemagick has a utility called display
May 10 19:58:16 <sakoman_> doesn't seem to work for me though!  no matter what file I specify it just prints the command help info :-(
May 10 19:59:17 <woglinde> sakoman yes dont it works with X only?
May 10 19:59:35 <sakoman_> yeah
May 10 19:59:53 <sakoman_> just wanted to try it, but doesn't seem to work
May 10 19:59:54 <woglinde> hm maybee I missunderstood it
May 10 20:00:13 <sakoman_> no you understood!
May 10 20:00:26 <woglinde> okay
May 10 20:00:35 <sakoman_> I just wasn't aware of the display command and wanted to see how it works
May 10 20:00:43 <sakoman_> seems it doesn't!
May 10 20:00:55 <woglinde> sakoman hm or you quick write an app yourself with dfb and diskoframework
May 10 20:02:55 <sakoman_> woglinde: yes, it just seemed like someone has certainly already done such a thing!
May 10 20:03:52 <sakoman_> I hate to reinvent the wheel
May 10 20:05:30 <woglinde> sakoman sure problem is
May 10 20:05:37 <woglinde> is it working anymore
May 10 20:05:41 <woglinde> does it the stuff I want
May 10 20:06:00 <woglinde> or only half
May 10 20:08:33 <tharvey> khem, so I've got a built up sdk to play with and some questions.  Seems the right thing to do is to run autoreconf to fix up broken configure scripts yet I can't see to figure out the right options to give it
May 10 20:13:42 <woglinde> re jama
May 10 20:25:07 <likewise> hi khem
May 10 20:26:24 <JaMa> re woglinde 
May 10 20:33:25 <GNUtoo|laptop> hi, I'd like to have world war vi in oe
May 10 20:33:42 <GNUtoo|laptop> they use a plain Makefile with gcc hardcoded
May 10 20:34:00 <GNUtoo|laptop> so I sed to ${CC}
May 10 20:34:08 <GNUtoo|laptop> but then there is a native tool
May 10 20:34:19 <GNUtoo|laptop> If I put gcc there the whole stuff work
May 10 20:34:36 <GNUtoo|laptop> so I've most lines with arm-oe-gcc and 1 line with gcc
May 10 20:34:45 <GNUtoo|laptop> should I sed and resed after?
May 10 20:36:07 <Jay7> may be change Makefile to use weak assignment and EXTRA_OEMAKE?
May 10 20:36:15 <GNUtoo|laptop> good idea
May 10 20:36:23 <GNUtoo|laptop> I ship a different Makefile then
May 10 20:36:29 <Jay7> then you may send this to upstream
May 10 20:36:31 <pb_> good grief, is this a competition for the world's worst makefile?
May 10 20:36:39 <kergoth> GNUtoo|laptop: no, you should patch the makefile to use BUILD_CC and equivalent for building the native stuff
May 10 20:36:41 <GNUtoo|laptop> lol
May 10 20:36:50 <GNUtoo|laptop> ok
May 10 20:36:59 <kergoth> then pass those in EXTRA_OEMAKE
May 10 20:37:04 <GNUtoo|laptop> ok
May 10 20:37:15 <GNUtoo|laptop> I patch it with vi
May 10 20:37:19 <GNUtoo|laptop> and then I ship it
May 10 20:37:25 <GNUtoo|laptop> and I pass the flags?
May 10 20:38:02 <Jay7> may be ship only patch for Makefile?
May 10 20:38:10 <Jay7> not makefile itself
May 10 20:38:40 <GNUtoo|laptop> ah patch not with sed
May 10 20:38:41 <GNUtoo|laptop> ok
May 10 20:38:43 <GNUtoo|laptop> got it
May 10 20:39:15 <GNUtoo|laptop> sorry I'm tired and so It takes longer to understand
May 10 20:40:20 <GNUtoo|laptop> thanks a lot
May 10 20:40:28 <GNUtoo|laptop> (for the pointers)
May 10 21:11:34 <likewise> otavio: ping
May 10 21:43:21 <otavio> likewise: hello
May 10 22:09:34 <likewise> otavio: hi, just wondering how you generate the pull requests for your github oe-core mirror.
May 10 22:10:14 <likewise> otavio: I'm switching to github for my work and would not like to reinvent all the workflow tools -- lazy.
May 10 22:12:11 <Crofton|work> likewise, be sure to use the clone thing on the mirror page :)
May 10 22:13:08 <likewise> Crofton|work: you mean the "Fork" button ?
May 10 22:13:17 <woglinde_> good nite
May 10 22:13:33 <likewise> Crofton|work: I used the Fork button to create my mirrors, yes.
May 10 22:14:30 <zecke> likewise: did you look into Gitorious vs. github?
May 10 22:16:00 <likewise> zecke: no, I'm starting to play with github, I may change later
May 10 22:16:15 <likewise> zecke: btw, received the pdf file for linuxtag from robert or florian?
May 10 22:16:19 <Crofton|work> otavio, is using github
May 10 22:16:42 <zecke> likewise: yes, I was worried about the usage of gray.. and evince showed me it was A4... but the plotting went nicely.
May 10 22:16:49 <Crofton|work> If it is helpful, we can also mirror to gitorious for people who prefer that
May 10 22:17:02 <zecke> likewise: we have one A0 plot now, I will hand it to robert tomorrow
May 10 22:17:15 <likewise> zecke: ok, so it came out allright? 
May 10 22:17:36 <Crofton|work> zecke, thanks for doing this
May 10 22:17:55 <likewise> zecke: I remember it took me a full afternoon to get the prints correctly, both Windows and Linux messing up plotting to the DesignJet, OS X to the rescue.
May 10 22:18:46 <likewise> so who's at LinuxTag? I'm not...
May 10 22:20:49 <zecke> Crofton|work: no problem, I like to help
May 10 22:23:18 <CIA-78> 03Simon Busch <morphis@gravedo.de> 07master * r2d3fd2a73b 10openembedded.git/recipes/pyside/apiextractor-native_0.10.2.bb: 
May 10 22:23:18 <CIA-78> apiextractor-native: add initial recipe to build the native version
May 10 22:23:18 <CIA-78> The apiexractor is needed to build the python pyside binding for Qt.
May 10 22:23:18 <CIA-78> Signed-off-by: Simon Busch <morphis@gravedo.de>
May 10 22:23:48 <CIA-78> 03Simon Busch <morphis@gravedo.de> 07master * raa4b7e83ed 10openembedded.git/recipes/pyside/ (5 files in 3 dirs): 
May 10 22:23:48 <CIA-78> libshiboken: add initial version of recipe
May 10 22:23:48 <CIA-78> Signed-off-by: Simon Busch <morphis@gravedo.de>
May 10 22:23:53 <CIA-78> 03Simon Busch <morphis@gravedo.de> 07master * r5f1e026794 10openembedded.git/recipes/pyside/ (shiboken-native_1.0.2.bb shiboken.inc): 
May 10 22:23:53 <CIA-78> shiboken-native: add initial version of recipe
May 10 22:23:53 <CIA-78> Signed-off-by: Simon Busch <morphis@gravedo.de>
May 10 22:24:04 <CIA-78> 03Simon Busch <morphis@gravedo.de> 07master * re2ac55d5d3 10openembedded.git/recipes/pyside/ (5 files in 2 dirs): 
May 10 22:24:04 <CIA-78> python-pyside-embedded: add initial version of this recipe
May 10 22:24:04 <CIA-78> Signed-off-by: Simon Busch <morphis@gravedo.de>
May 10 22:25:44 <CIA-78> 03Simon Busch <morphis@gravedo.de> 07master * rcbd582b4d1 10openembedded.git/recipes/pyside/generatorrunner-native_0.6.9.bb: 
May 10 22:25:44 <CIA-78> generatorrunner-native: add initial recipe to build the native version
May 10 22:25:44 <CIA-78> The generatorrunner is needed to build the python pyside binding for Qt.
May 10 22:25:44 <CIA-78> Signed-off-by: Simon Busch <morphis@gravedo.de>
May 10 22:37:56 <likewise> gn
May 10 23:23:44 <khem> hey likewise 
May 10 23:24:16 <khem> there was a bit of biking event today spent morning doing that
May 10 23:25:34 <khem> tharvey: if you setup the environment and then do autoreconf using options we use in autotools.bbclass should be enough
May 10 23:26:22 <tharvey>  khem I've tried that but in my test case (gd) configure is still putting things from / in CFLAGS/etc
May 10 23:27:13 <tharvey> autoreconf  -Wcross --verbose --force -I/mnt/sda1/oe/dev/tmp/sysroots/armv7a-commonos-linux-gnueabi/usr/share/aclocal-1.11 -I /mnt/sda1/oe/dev/tmp/sysroots/armv7a-commonos-linux-gnueabi/usr/share/aclocal
May 10 23:27:30 <tharvey> does the same as well... 
May 10 23:28:28 <khem> hm
May 10 23:28:41 <tharvey> khem, even if I run configure with full args like: /configure --build=x86_64-linux --host=arm-angstrom-linux-gnueabi --target=arm-angstrom-linux-gnueabi --with-libtool-sysroot=$LIBTOOL_SYSROOT_PATH --with-zlib=$LIBTOOL_SYSROOT_PATH/usr --with-jpeg=$LIBTOOL_SYSROOT_PATH/usr --with-png=$LIBTOOL_SYSROOT_PATH/usr  --without-x --without-xpm --without-fontconfig --with-freetype
May 10 23:28:49 <khem> there is a script generated along with SDK
May 10 23:29:02 <tharvey> Makefile still gets: CPP = arm-angstrom-linux-gnueabi-gcc -E
May 10 23:29:02 <tharvey> CPPFLAGS = -I/usr/include/freetype2  -I/usr/include/libpng12 -I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include
May 10 23:29:52 <khem> there should be a config.log generated 
May 10 23:29:58 <khem> paste is on pastebin
May 10 23:34:23 <tharvey> http://pastebin.mozilla.org/1222267
May 10 23:34:32 <tharvey> should be everything relevant there
May 10 23:36:28 <tharvey> the thing that bothers me is that CPPFLAGS contains -I/usr/include/freetype2 -I/usr/include/libpng12
May 10 23:37:06 <tharvey> also doing a make ends up failing trying to link against /usr/lib: /bin/sh ./libtool --tag=CC   --mode=link arm-angstrom-linux-gnueabi-gcc  -g -O2 -version-info 2:0:0  -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -o libgd.la -rpath /usr/local/lib gd.lo gdfx.lo gd_security.lo gd_gd.lo gd_gd2.lo gd_io.lo gd_io_dp.lo gd_gif_in.lo gd_gif_out.lo gd_io_file.lo gd_io_ss.lo gd_jpeg.lo gd_png.lo gd_ss.lo gd_topal.lo gd_wbmp.lo gdcache.lo gdfontg.lo gd
May 10 23:37:06 <tharvey> fontl.lo gdfontmb.lo gdfonts.lo gdfontt.lo gdft.lo gdhelpers.lo gdkanji.lo gdtables.lo gdxpm.lo wbmp.lo  -ljpeg -lfreetype -lz -lm 
May 10 23:37:06 <tharvey> /bin/grep: /usr/lib/libz.la: No such file or directory
May 10 23:37:49 <khem> yeah libtool is messed up
May 10 23:38:01 <khem> ok paste the configure somewhere
May 10 23:39:25 <tharvey> that will be pretty big... I can look through and try to figure out what its doing wrong and why - I just though I was perhaps using autoreconf or configure wrong
May 10 23:39:44 <tharvey> if autoreconf does the right thing, then I shouldn't need to give configure anything other than --host correct?
May 10 23:39:57 <khem> tharvey: not really
May 10 23:40:10 <khem> it still would need the options
May 10 23:40:18 <tharvey> should the file pointed to by $CONFIG_SITE be empty?  it is and that suprised me.  I would think it would be feeding defaults to configure
May 10 23:40:35 <khem> but it will regenerate the scripts with given autotools which is a good thing
May 10 23:41:03 <khem> CONFIG_SITE should have some vars cached thats it I would think
May 10 23:41:08 <khem> not a big deal
May 10 23:42:04 <tharvey> I figure if I have to feed configure a bunch of options anyway, I'm pretty sure between those options and some vars in CONFIG_SITE I can get configure doing the right thing
May 10 23:42:17 <khem> yes
May 10 23:42:30 <khem> you probably are missing some options to configure 
May 10 23:42:36 <tharvey> so not sure what the point woudl be in messing with autoreconf then
May 10 23:42:41 <khem> once you troll the script you will find it 
May 10 23:43:00 <khem> options to configure is what I meant
May 10 23:43:04 <tharvey> either way seems to be a huge headache for devs using the SDK - I thought with autotools all this was supposed to be magic ;)
May 10 23:43:51 <kergoth> hmm, if its our autoconf, there's no reason we couldn't change the default in our macros, so that if you regenerate with the sysroot autoconf, it uses our sysroot, no?
May 10 23:44:40 <tharvey> autoconf/autoreconf are not in the sdk
May 10 23:45:15 <tharvey> I'm still not understanding what LIBTOOL_SYSROOT_PATH is used for exported by the SDK either - I haven't seen anything that uses that
May 10 23:46:12 <tharvey> I'm also not sure I understand libtool in the sdk... its /usr/local/angstrom/arm/bin/x86_64-linux-libtool - is that right or should it be just 'libtool'?
May 10 23:47:02 <tharvey> if I look at it also, macro_version=2.2.6b which I thought should be 2.4
May 10 23:48:04 <khem> it should be arm-*-*-libtool
May 10 23:48:06 <tharvey> oh wait... thats likely because this example I've been talking about is an sdk from release2011-03 with angstrom but I think thats defaulting to angstrom-2008 configs which uses libtool 2.2.6b? 
May 10 23:48:23 <khem> and you have to regenerate the libtool files
May 10 23:48:36 <tharvey> how would I do that?  I thought that was one of the things that autoreconf did?
May 10 23:50:00 <khem> tharvey: yes autoreconf should do it
May 10 23:50:22 <khem> so when you look at the libtool script it should say 2.4
May 10 23:50:37 <khem> and not 2.2.6 if you are using libtool 2.4
May 10 23:51:13 <tharvey> so 'my' sdk does use libtool2.4 but the one I just used for the example of discussion/pastebin was built last night off release-2011-03 which defaults to Angstrom-2008 which is 2.26 - let me redo that again with libtool 2.4 and investigate some more
May 10 23:52:09 <tharvey> thanks for the help!  I have to take off for the day, but I'll likely have something to report or ask again tomorrow if you don't mind
**** ENDING LOGGING AT Wed May 11 02:59:58 2011