**** BEGIN LOGGING AT Fri Dec 19 02:59:57 2008
Dec 19 03:43:58 <digital-ex> Hi everyone.  Does anyone know what may be causing the nfs-utils-1.1.2 build to fail?  This is reported by the autobuild (http://bugs.openembedded.net/show_bug.cgi?id=4635).  
Dec 19 03:47:29 <khem> digital-ex: there are 2 reasons it seems
Dec 19 03:47:38 <khem> digital-ex: 1. It depends on libblkid
Dec 19 03:47:58 <khem> 2. on powerpc your <staging>/usr/lib/libc.so is hosed up
Dec 19 03:48:08 <khem> or in general it is hosed up
Dec 19 03:48:23 <khem> this file should be a linker script file
Dec 19 03:51:47 <digital-ex> Hi khem -- thanks for the info.  I am building for powerpc.
Dec 19 03:53:24 <digital-ex> Perhaps I should erase the whole staging folder?
Dec 19 03:53:30 <khem> digital-ex: ok can you check what do you have in <staging>/usr/lib/libc.so
Dec 19 03:57:21 <digital-ex> The contents of libc.so are here: http://pastebin.ca/1289048
Dec 19 04:03:18 <khem> digital-ex: that looks ok to me
Dec 19 04:03:31 <khem> Are you seeing same error
Dec 19 04:03:35 <khem> as reported in the bug
Dec 19 04:04:40 <digital-ex> I'm seeing the same error reported by the Efika build on 2008.11.07 in the bug report.  It's the case of "undefined reference to `__nldbl_printf'"
Dec 19 04:05:12 <digital-ex> In the testlk.c file
Dec 19 04:06:48 <digital-ex> I'm trying to build the nas-server-image
Dec 19 04:08:46 <digital-ex> I can successfully build and run the console-image, so I think the tool chain is OK
Dec 19 04:10:46 <khem> digital-ex: yeah that seems so
Dec 19 04:12:21 <khem> digital-ex: let me try to reproduce it on eglibc
Dec 19 04:12:30 <khem> if I am able to do so then I will fix it
Dec 19 04:14:13 <digital-ex> Thanks khem... that would be great.  I just found this: http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=14125220&tstart=0
Dec 19 04:14:40 <digital-ex> It looks like the __nldbl_printf issue may be related to the version of glibc
Dec 19 04:17:23 <khem> actually this is --enable-long-double-128
Dec 19 04:17:28 <khem> issue I am guessing
Dec 19 04:18:03 <khem> digital-ex: what version of glibc are you using
Dec 19 04:18:08 <digital-ex> Yes... that looks suspicious.  Is that enabled in the nfs-utils-1.1.2 package?
Dec 19 04:18:11 <khem> can you try eglibc >
Dec 19 04:18:35 <khem> no thats in glibc
Dec 19 04:18:41 <digital-ex> At this point I'm out of my depth... how do I check which glibc I'm currently using?  And how do I try eglibc?
Dec 19 04:19:47 <khem> digital-ex: ok which distro are you using angstrom ?
Dec 19 04:20:10 <digital-ex> Yes it's angstrom, on the dev branch. 
Dec 19 04:20:15 <khem> are you using latest .dev snapshot ?
Dec 19 04:20:23 <khem> ok then its simple
Dec 19 04:20:46 <digital-ex> Well, the last pull I did was about 2 weeks ago... since then I've been experimenting with adding support for the Rainier (440GRx), so I haven't updated lately
Dec 19 04:20:55 <khem> you can add this ANGSTROMLIBC="eglibc"
Dec 19 04:21:03 <khem> make sure that you have latest bitbake
Dec 19 04:21:42 <digital-ex> Where do I add ANGSTROMLIBC?  To the environment, in local.conf, or elsewhere?
Dec 19 04:21:55 <khem> yes in local.conf
Dec 19 04:22:36 <khem> bitbake --version ?
Dec 19 04:24:01 <digital-ex> BitBake Build Tool Core version 1.8.11, bitbake version 1.8.11
Dec 19 04:24:44 <khem> ok
Dec 19 04:24:49 <digital-ex> I updated local.conf and started the build... 
Dec 19 04:25:01 <khem> digital-ex: you can also set ANGSTROMLIBC=eglibc on commandline
Dec 19 04:25:15 <khem> ANGSTROMLIBC=eglibc bitbake console-image 
Dec 19 04:25:52 <digital-ex> Good to know... maybe I should try that with nfs-utils only?  Otherwise it could be a while...
Dec 19 04:26:39 <khem> unfortunately it will rebuild whole thing
Dec 19 04:26:50 <khem> changing libc is fundamental change 
Dec 19 04:27:48 <digital-ex> OK... it's still parsing the bb files.  What did we just do?  Switch from the GNU C Library to something else?
Dec 19 04:28:42 <khem> its still gnu C library but for embedded systems
Dec 19 04:28:48 <khem> www.eglibc.org
Dec 19 04:28:55 <khem> its glibc+embedded stuff
Dec 19 04:28:58 <khem> more suited here
Dec 19 04:29:35 <digital-ex> Thanks... good to know. 
Dec 19 04:30:18 <khem> btw it uses latest release of glibc so you will have relatively new library
Dec 19 04:31:20 <digital-ex> khem: It seems to have tried to build nfs-utils right away and failed again.  See here: http://pastebin.ca/1289078
Dec 19 04:44:29 <digital-ex> khem: It's night night time for me... thanks for the help.  I can continue testing this tomorrow around the same time if it will help...
Dec 19 05:08:01 <CIA-5> 03John Lee <john_lee@openmoko.org> 07org.openembedded.dev * r87852fa81b 10openembedded.git/conf/machine/om-gta01.conf: om-gta01.conf: don't need to set PACKAGE_EXTRA_ARCHS now.
Dec 19 05:08:02 <CIA-5> 03John Lee <john_lee@openmoko.org> 07org.openembedded.dev * rd57301a708 10openembedded.git/conf/machine/om-gta02.conf: om-gta02.conf: don't need to set PACKAGE_EXTRA_ARCHS now.
Dec 19 05:08:02 <CIA-5> 03John Lee <john_lee@openmoko.org> 07org.openembedded.dev * r3b4c349dc1 10openembedded.git/conf/machine/om-gta01.conf: om-gta01.conf: fix IMAGE_FSTYPES ?= to +=
Dec 19 05:08:03 <CIA-5> 03John Lee <john_lee@openmoko.org> 07org.openembedded.dev * r6eeb81ad43 10openembedded.git/conf/machine/om-gta02.conf: om-gta02.conf: fix IMAGE_FSTYPES ?= to +=
Dec 19 05:52:46 <khem> digital-ex: ok gnight
Dec 19 06:26:36 <CIA-5> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r0ea723f744 10openembedded.git/packages/nfs-utils/nfs-utils_1.1.2.bb: 
Dec 19 06:26:36 <CIA-5> nfs-utils_1.1.2: Add e2fsprogs-libs to DEPENDS
Dec 19 06:26:36 <CIA-5> * fixes bug 4625
Dec 19 06:29:06 <cdbot2> * * OE Bug 4635 has been RESOLVED (FIXED) by raj.khem(AT)gmail.com
Dec 19 06:29:08 <cdbot2> * * nfs-utils-1.1.2-autobuild
Dec 19 06:29:10 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4635
Dec 19 07:08:50 <Tartarus> Woop
Dec 19 07:09:06 <Tartarus> Got canadian sdk stuff building both an efika and nokia800 windows toolchain in one TMPDIR
Dec 19 07:09:22 <Tartarus> Time to have a buncha stuff build overnight and test some actual SDKs tomorrow
Dec 19 07:14:44 <CIA-5> 03John Lee <john_lee@openmoko.org> 07org.openembedded.dev * ref44fb4e17 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs.inc: update svnr of openmoko-toolchain-scripts
Dec 19 07:53:39 <CIA-5> 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * ref5ad935d6 10openembedded.git/packages/directfb/lite_0.9.26+cvs20070207.bb: lite bb: SRC_URI fixed
Dec 19 08:23:34 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r89becd1388 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev
Dec 19 08:23:45 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r26102276cb 10openembedded.git/packages/gnuradio/ (gnuradio.inc gnuradio/acinclude.m4 gnuradio_3.1.3.bb): gnuradio: fix packaging and python detection
Dec 19 09:26:21 <pb_> zecke: hail zecke
Dec 19 09:26:39 <favor> hi.all
Dec 19 09:28:04 <favor> when i bitbake the image, i got an error: NOTE: Resolving any missing task queue dependenciesERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'openzaurus-sa' but it wasn't found in any PACKAGE or RPROVIDES variables
Dec 19 09:28:04 <favor> NOTE: Runtime target 'openzaurus-sa' is unbuildable, removing...Missing or unbuildable dependency chain was: ['openzaurus-sa']. do you know what is the problem?
Dec 19 09:31:34 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r4329072ac5 10openembedded.git/packages/i2c-tools/ (3 files in 2 dirs): 
Dec 19 09:31:34 <CIA-5> picodlp-control: small program to read out status bits from the pico DLP projector
Dec 19 09:31:34 <CIA-5> * http://dlp.com/regional/dlp_discovery/pico.aspx
Dec 19 10:07:42 <florian> good morning
Dec 19 10:11:10 <pb__> hi florian 
Dec 19 10:17:39 <favor> we are afternoon in china!
Dec 19 10:46:12 <rschuster> make install copied a little too much
Dec 19 10:46:16 <rschuster> is rm -rf ${STAGING_BINDIR} safe?
Dec 19 10:50:36 <florian> hi XorA 
Dec 19 10:52:31 <XorA> yo florian
Dec 19 11:30:58 <schurig> rschuster: normally not, after it you won't get the binaries back, you'd have to remove the stamp files for the staging subtask as well
Dec 19 12:21:53 <jeanseb> hello
Dec 19 12:22:17 <jeanseb> got problem building oendreambox image
Dec 19 12:22:33 <jeanseb> cycling dependance in tuxbux plugin 
Dec 19 12:22:37 <jeanseb> any jint ?
Dec 19 12:22:41 <jeanseb> hint
Dec 19 12:29:26 <CIA-5> 03Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r448c0f81a2 10openembedded.git/ (3 files in 3 dirs): 
Dec 19 12:29:26 <CIA-5> fso-gpsd: Bump to 0.8 release. Initscript changes.
Dec 19 12:29:26 <CIA-5> The author requested to change the way PID is handled and that it should only
Dec 19 12:29:26 <CIA-5> listen on localhost.
Dec 19 13:22:09 <ant_work> 'morning
Dec 19 13:23:09 <ant_work> with kernel 2.6.26 I get 'Unkwnon HZ value! (87) Assume 100'
Dec 19 13:23:26 <ant_work> seems like sysinfo.c doesn' know about these values...
Dec 19 13:23:48 <ant_work> is there any newer procps in OE?
Dec 19 13:30:34 <ant_work> hmm...3.27 is already in...needing a patch for embedded arm?
Dec 19 13:37:28 <ant_work> hm...in kernel config I see CONFIG_HZ=100
Dec 19 14:31:46 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rdce67387e0 10openembedded.git/packages/i2c-tools/ (picodlp-control/picodlp-control.c picodlp-control_0.1.bb): picodlp-control: cycle through flipmodes and reindent
Dec 19 14:37:25 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r38b122343c 10openembedded.git/packages/i2c-tools/ (picodlp-control/picodlp-control.c picodlp-control_0.1.bb): picodlp control: write to both flip bits, not twice to the same bit
Dec 19 14:43:11 <CIA-5> 03Jeremy Lainé <jeremy.laine@m4x.org> 07org.openembedded.dev * rc4f96a54d4 10openembedded.git/packages/linux/linux_2.6.26.bb: linux-2.6.26: don't apply cdc_ether hack on boc01 for now
Dec 19 15:53:46 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r2a50ede20b 10openembedded.git/packages/linux/linux-omap/ (2 files in 2 dirs): linux-omap git: fix evm regression
Dec 19 16:09:37 <sakoman> good morning!
Dec 19 16:09:48 <sakoman> any e-wm experts around?
Dec 19 16:10:13 <sakoman> in recent builds on beagle file manager icons seem to have gotten broken
Dec 19 16:10:58 <sakoman> right-clicking on a file manager window and selecting one of the view options will temporarily bring them back (until the window is closed)
Dec 19 16:11:18 <sakoman> and they are alays missing from the desktop
Dec 19 16:11:27 <sakoman> has anyone else seen this?
Dec 19 16:30:24 <zecke> sakoman: mickeyl or raster would be your man...
Dec 19 16:53:48 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * r6c47d0120d 10openembedded.git/packages/xorg-lib/libsm-native_1.0.3.bb: libsm-native 1.0.3: New recipe.
Dec 19 16:53:49 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * rf1371751af 10openembedded.git/packages/xorg-lib/libxt-native_1.0.5.bb: libxt-native 1.0.5: New recipe.
Dec 19 16:53:50 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * r77cb0b922d 10openembedded.git/packages/xorg-lib/libice-native_1.0.4.bb: libice-native 1.0.4: Add 'inherit native'.
Dec 19 16:53:50 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * r8ff09c1058 10openembedded.git/packages/xorg-lib/libice-native_1.0.4.bb: libice-native 1.0.4: New recipe.
Dec 19 16:53:53 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * r2043cbaf8d 10openembedded.git/packages/jamvm/ (jamvm-native.inc jamvm-native_1.5.1.bb): jamvm: Increased default max heap.
Dec 19 16:53:56 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * rd6d83c20ce 10openembedded.git/packages/xorg-lib/libxt-native_1.0.5.bb: libxt-native 1.0.5: Fixed contents (committed a copy of libxt_1.0.5.bb).
Dec 19 16:53:59 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * rb357fabdfd 10openembedded.git/packages/xorg-lib/libsm-native_1.0.3.bb: libsm 1.0.3: Add 'inherit native'.
Dec 19 16:54:02 <CIA-5> 03Robert Schuster <thebohemian@gmx.net> 07org.openembedded.dev * rd6aa54692b 10openembedded.git/packages/lcms/lcms-native_1.17.bb: lcms-native 1.17: New recipe.
Dec 19 16:54:21 <zecke> yeah
Dec 19 16:55:11 <sakoman> zecke: thanks, looks like neither are around :-(
Dec 19 16:56:10 <zecke> mickey|zzZZzz: ping?
Dec 19 17:38:51 <CIA-5> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r45782aa50d 10openembedded.git/packages/tasks/task-beagleboard-demo.bb: task-beagleboard-demo: move omapfbplay to armv7a rrecommends, add kernel-modules
Dec 19 18:28:31 <hrw> bye
Dec 19 18:28:52 <zecke> bye
Dec 19 18:30:31 <prpplague> bye
Dec 19 18:43:51 <tharvey> I've got a recipe question:  for an app that has a series of makefiles and specifies CFLAGS within these makefiles using oe_runmake causes the CFLAGS from the env to take precedence and thus the Makefiles CFLAGS don't get used - should I be moving those important CFLAGS out into the recipe such as CFLAGS_append or not use oe_runmake?
Dec 19 18:44:28 <tharvey> specifically the package has several dirs and thus has several -I<dirname> in CFLAGS - seems silly to have to translate all of that out of the apps Makefile and into a recipe
Dec 19 18:56:21 <khem> tharvey: try CFLAGS_append
Dec 19 19:08:12 <tharvey> khem, right but my question is that shouldn't the app's makefile be a black box?  seems bad that I would have to dig into it and keep porting things from the Makefile's CFLAGS back into the recipes CFLAGS_append
Dec 19 19:08:50 <tharvey> all recipes I've worked on have used oe_runmake but I'm wondering if there are perhaps a lot out there that use 'make CC="${CC}"' etc to avoid what I'm talking about
Dec 19 19:10:30 <mwester> tharvey:  there are many apps out there who do not write makefiles that are friendly to CFLAGS being passed in.
Dec 19 19:11:14 <tharvey> the real issue is that the app's Makefile(s) don't append to CFLAGS correct?
Dec 19 19:11:18 <mwester> tharvey:  in fact, I would venture to say that the majority of the complexity of bb recipes is in dealing with the various shortcoming, oversights, and outright errors in the Makefiles/autoconf stuff .
Dec 19 19:12:39 <mwester> tharvey:  I haven't looked at your situation specifically, but in my experience, it's usually that Makefiles don't properly pass CFLAGS and other overrides to sub-makefiles.
Dec 19 19:13:06 <khem> tharvey: key difference is we cross compile and many makefiles arent written cross compilation friendly 
Dec 19 19:13:17 <khem> tharvey: so we beat them up and then they behave
Dec 19 19:13:24 <tharvey> I'm trying to write a recipe for mgen (http://downloads.pf.itd.nrl.navy.mil/mgen/) which is a c++ app with multiple directory levels
Dec 19 19:14:07 <khem> tharvey: Does this app work as expected on native system
Dec 19 19:15:06 <tharvey> yes... they have a directory of Makefiles tailored to various systems... I can cross-compile it just fine by manipulating my PATH to give precedence to my cross-compiler tools
Dec 19 19:15:18 <tharvey> just trying to figure out the 'right way' to do the recipe
Dec 19 19:16:20 <khem> hmmm then it should just work because all those paths to cross tools are added by bitbake
Dec 19 19:20:16 <tharvey> you would think... if my do_install() is simply 'make -f Makefile.linux' it uses g++ and regardless of g++ being in the path in run.do_compile() its still using my native g++
Dec 19 19:21:50 <khem> tharvey: then these makefiles do not honor CC or CXX it seems 
Dec 19 19:22:11 <tharvey> hmm... its not the .o's that are wrong arch its the final app - must be a linker issue
Dec 19 19:23:19 <tharvey> its true the Makefiles assign CC=g++ RNALIB=ranlib AR=ar - but as you point out the modified PATH should make those ok
Dec 19 19:24:10 <hrw> no
Dec 19 19:24:20 <hrw> makefile should not decide such things
Dec 19 19:24:51 <hrw> tharvey: CC=arm-angstrom-gnueabi-gcc is more common (for arm and angstrom)
Dec 19 19:25:42 <tharvey> yes I know that technically that Makefile is wrong and shouldn't be assuming that, but the fact that the cross g++ is in the path should make it 'work' - and it does seem to as all the .o's are correct arch, just the final app isn't
Dec 19 19:28:24 <tharvey> I'm simply trying to determine the right path to take here - patch the crappy Makefiles, or try to work around them and if so what the best workaround is
Dec 19 19:29:37 <hrw> patch
Dec 19 19:34:18 <khem> tharvey: yeah if Makefile is not cross compilation friendly then make it 
Dec 19 19:48:56 <thesing> morning all
Dec 19 19:51:48 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rc22ce11000 10openembedded.git/packages/ica/ica-bin_10.6.bb: ica-bin: rdepends on libxaw
Dec 19 19:51:49 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * re4ad862c15 10openembedded.git/packages/psplash/psplash_svn.bb: psplash: use psplash.h if the distribution provides it
Dec 19 19:51:50 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r5d1879fe4c 10openembedded.git/ (conf/checksums.ini packages/fbpanel/fbpanel_4.12.bb): fbpanel: add 4.12
Dec 19 19:51:50 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r75ce6ebf69 10openembedded.git/ (conf/checksums.ini packages/openbox/openbox_3.4.7.2.bb): openbox: add 3.4.7.2
Dec 19 19:51:51 <otavio> morning (here it is afternoon)
Dec 19 19:51:53 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r6bd3e47c26 10openembedded.git/ (conf/checksums.ini packages/lxde/menu-cache_0.2.2.bb): menu-cache: add 0.2.2
Dec 19 19:51:56 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rda838ce397 10openembedded.git/ (conf/checksums.ini packages/lxde/lxpanel_0.3.99.bb): lxpanel: add 0.3.99
Dec 19 19:52:01 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r4be50f4eb7 10openembedded.git/ (conf/checksums.ini packages/lxde/lxpanel_0.3.8.1.bb): lxpanel: add 0.3.8.1
Dec 19 19:52:04 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r359fa754e8 10openembedded.git/ (conf/checksums.ini packages/lxde/lxmenu-data_0.1.bb): lxmenu-data: add 0.1
Dec 19 19:52:07 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r32e2a08bd6 10openembedded.git/ (conf/checksums.ini packages/lxde/lxde-common_0.3.2.1.bb): lxde-common: add 0.3.2.1
Dec 19 19:52:10 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rf34c7b6188 10openembedded.git/ (conf/checksums.ini packages/lxde/lxsession-lite_0.3.6.bb): lxsession-lite: add 0.3.6
Dec 19 19:58:26 <CIA-5> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r2fe38e26dd 10openembedded.git/packages/xkeyboard-config/ (files/abnt2-fixes.patch xkeyboard-config_1.4.bb): 
Dec 19 19:58:26 <CIA-5> xkeyboard-config: fix abnt2 keycodes (when using evdev)
Dec 19 19:58:26 <CIA-5> This patch has been taken from GIT and will be included in 1.5.
Dec 19 20:12:19 <zecke> any automake/m4 guru around?
Dec 19 20:12:45 <thesing> zecke, I thought you are one.
Dec 19 20:14:39 <zecke> no
Dec 19 20:15:10 <zecke> I can fixup and understand and cleanup.... but my m4 skills are pretty weak in creating new constructs
Dec 19 20:34:04 <goutham> hi can anybody help me with compiling perl-5.8.8 with oe
Dec 19 20:34:34 <goutham> i am having trouble compiling on x86_64 fedora 10
Dec 19 20:34:49 <goutham> IO.xs: In function 'XS_IO__Poll__poll':
Dec 19 20:34:49 <goutham> | IO.xs:238: error: invalid application of 'sizeof' to incomplete type 'struct pollfd'
Dec 19 20:38:23 <zecke> goutham: man 3 poll
Dec 19 20:38:28 <zecke> goutham: then add the header file
Dec 19 20:39:42 <goutham> i tried that by changing "poll.h" to <sys/poll.h> in IO.xs
Dec 19 20:40:02 <goutham> that didn't fix it
Dec 19 20:45:12 <goutham> zecke: it worked now. I actually added <poll.h> before now after changing to <sys/poll.h> it is working. Thanks for your suggestion
Dec 19 20:45:37 <zecke> goutham: please create a patch :)
Dec 19 20:45:46 <goutham> I will
Dec 19 22:08:54 <ant_> woglinde: hallo?
Dec 19 22:10:44 <woglinde> he ant
Dec 19 22:10:50 <ant_> hey
Dec 19 22:11:34 <ant_> can I do smthg to debug that gettext/libintl thing?
Dec 19 22:11:44 <woglinde> ant hm?
Dec 19 22:11:49 <woglinde> whats the problem now?
Dec 19 22:12:12 <ant_> http://rafb.net/p/2Ria4776.html
Dec 19 22:12:19 <ant_> you said is a problem...
Dec 19 22:12:51 <woglinde> hm no
Dec 19 22:12:57 <woglinde> I wondered why it came from
Dec 19 22:12:59 <woglinde> where
Dec 19 22:13:19 <ant_> maybe bitbake and ?-D or -v options?
Dec 19 22:13:42 <ant_> I can try
Dec 19 22:13:48 <woglinde> hm no
Dec 19 22:13:52 <woglinde> its okay
Dec 19 22:14:00 <woglinde> maybee a package renaming 
Dec 19 22:14:16 <woglinde> so I should merge the gettext changes?
Dec 19 22:14:32 <ant_> I had absolutely no problems (uclibc/glibc)
Dec 19 22:14:51 <ant_> khem too tested your patch
Dec 19 22:17:51 <ant_> woglinde: silly question:
Dec 19 22:18:06 <ant_> why is uclibc machine-specific?
Dec 19 22:19:08 <ant_> i mean, is in /c7x0-angstrom-linux-uclibcgnueabi 
Dec 19 22:19:15 <ant_> (klibc too)
Dec 19 22:20:12 <ant_> while glibc is in /armv5te-angstrom-linux-gnueabi    
Dec 19 22:21:59 <woglinde> dont know
Dec 19 22:22:03 <woglinde> ask koen
Dec 19 22:22:32 <ant_> PACKAGE_ARCH = "${MACHINE_ARCH}"
Dec 19 23:36:34 <tharvey> anyone using any simple v4l2 capture apps with oe they can recommend?  I see webcam-server and camsource packages - not sure if either is worthwhile or not
Dec 19 23:39:53 <tharvey> simply looking for v4l2 frame/stream capture/store and possibly stream - no local display
Dec 19 23:41:35 <Fique> i've tried using mjpeg-streamer with a UVC webcam
Dec 19 23:41:48 <Fique> never made a complete OE recipe for it though since I was justmessing around
Dec 19 23:42:47 <Fique> your other bet is a custom build of ffmpeg
Dec 19 23:43:03 <Fique> ffmpeg has commandline capture and a second commandline streamer
Dec 19 23:43:25 <tharvey> I'll look at those thx
Dec 19 23:43:38 <tharvey> I didn't know ffmpeg was so versatile - I typically think of it as a lib that other apps use
Dec 19 23:44:53 <woglinde> fique hm I tried mjpeg-streamer on the nokia n810 and it didnt work
Dec 19 23:45:06 <Fique> ive only used it on my arm based platform
Dec 19 23:45:23 <Fique> sorry just mentioning what i've played with
Dec 19 23:45:28 <woglinde> okay good night
Dec 19 23:45:42 <tharvey> ive noticed that a lot of the older simpler webcam apps don't work with my v4l2 source - I didn't dig too deep yet but I think its b/c my source only supports a few formats
Dec 19 23:46:03 <tharvey> seems that most of them were written with specific hardware in mind and are not very flexible
Dec 19 23:46:32 <Fique> yeah mjpeg-streamer is meant specifically for UVC usb-webcams and gspa based usb webcams
Dec 19 23:46:52 <Fique> i think ffmpeg just looks for a valid v4l2 device
Dec 20 00:27:43 * rwhitby is also looking for a pwc-based webcam streamer ...
Dec 20 00:28:54 <zecke> god I hate libtool
Dec 20 00:29:09 <zecke> when I ever see the creator of it, something will happen to him...
Dec 20 00:40:22 * kergoth chuckles
Dec 20 00:40:48 <kergoth> zecke: it wouldnt be nearly so bad if the code wasn't so terrible.  even if it used shell functions instead of duplicating code all over the place, it wouldnt be quite so bad..
Dec 20 00:40:52 <kergoth> heh
Dec 20 00:44:52 <zecke> kergoth: yes the 8 copies of -L/usr/lib for m68k... make me want to puke
Dec 20 00:45:07 <zecke> kergoth: for whatever reasons it tries to put -L/usr/lib IN FRONT OF my linker path
Dec 20 00:45:43 <zecke> fucking bastards... On this server connected via GPRS... a plain call to gcc works and libtool is fucking compilicating it...
Dec 20 00:47:04 <zecke> the whole GNU buildsystem toolchain is just inherently broken
Dec 20 00:47:46 * zecke is quite angry
Dec 20 01:55:07 * mwester hopes zecke is at least getting paid for that activity.
**** ENDING LOGGING AT Sat Dec 20 02:59:57 2008