**** BEGIN LOGGING AT Wed Jan 11 02:59:57 2012
**** BEGIN LOGGING AT Wed Jan 11 05:01:37 2012
Jan 11 06:09:31 <mrmoku> GNUtoo: pong
Jan 11 06:09:36 <mrmoku> and moin :)
Jan 11 07:38:33 <mrmoku> moin JaMa 
Jan 11 07:39:03 <mrmoku> JaMa: now edje-native is failing for me
Jan 11 07:41:56 <mrmoku> | src/examples/Makefile.am:67: `pkglibdir' is not a legitimate directory for `PROGRAMS'
Jan 11 07:43:23 <JaMa> moin
Jan 11 07:44:25 <JaMa> weird, it's probably cause by new automake, but I've built edje-native yesterday without problem and automake wasn't upgraded in shr-chroot yet
Jan 11 07:44:34 <JaMa> I'll probably upgrade it today and try
Jan 11 07:46:15 <JaMa> btw: there is gcc and eglibc upgrade in queue
Jan 11 07:46:16 <mrmoku> hmm, ok
Jan 11 07:46:22 <mrmoku> fun :P
Jan 11 07:46:42 <mrmoku> with some linaro fixing... I sa
Jan 11 07:46:43 <mrmoku> w
Jan 11 07:47:32 <CIA-77> SHR: 03Martin.Jansa 07shr-chroot * r5bc2a9cae6e7 10/ (357 files in 36 dirs): system upgrade
Jan 11 07:50:24 <CIA-77> SHR: 03Martin.Jansa 07shr-chroot * re7af99c5bce1 10/ (136 files in 15 dirs): automake upgrade
Jan 11 07:52:26 * mrmoku retries
Jan 11 07:56:43 <mrmoku> JaMa: still same failure
Jan 11 08:10:32 <JaMa> mrmoku: jenkins has the same but in eina and eina-native, weird
Jan 11 08:10:52 <mrmoku> heh
Jan 11 08:13:47 <JaMa> mrmoku: it's fixed in r66599
Jan 11 08:13:55 <JaMa> that's why I haven't seen it
Jan 11 08:14:50 <JaMa> and now the difficult part :), do we want this commit split to multiple patches applied to almost every efl recipe, or do we want EFL bump?
Jan 11 08:15:08 <mrmoku> hehe
Jan 11 08:15:13 <mrmoku> well
Jan 11 08:15:34 <mrmoku> build failure is IMHO a legitime reason for an EFL bump now
Jan 11 08:15:47 <JaMa> i can split it and add to meta-efl, but cannot test it as I'm on newer EFL already
Jan 11 08:16:12 <JaMa> test it locally I mean, so I would be able to test it on buildhost/jenkins
Jan 11 08:19:10 <JaMa> I'll push toolchain upgrade first to keep you and buildhost busy 
Jan 11 08:19:50 <mrmoku> heh, ok :P
Jan 11 08:20:12 <CIA-77> SHR: 03Martin.Jansa 07meta-smartphone * rd4880c5c5788 10/meta-shr/conf/distro/include/preferred-shr-versions.inc: meta-shr: prefer eglibc-2.15, 2.14 is gone
Jan 11 08:20:25 <JaMa> and then efl bump if jenkins build from scratch finishes fine with it
Jan 11 08:22:18 <mrmoku> JaMa: ok, I will do the upgrade-build test then
Jan 11 09:10:39 <mrmoku> JaMa: ERROR: '/OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc-initial_2.15.bb' failed
Jan 11 09:10:42 <mrmoku> ERROR: '/OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.15.bb' failed
Jan 11 09:10:52 <mrmoku> will try a clean_toolchain_core now
Jan 11 09:11:16 <JaMa> how it failed?
Jan 11 09:11:27 <mrmoku> ahh, moment
Jan 11 09:11:30 <JaMa> incremental build worked here fine, gcc yesterday and eglibc today
Jan 11 09:12:03 <JaMa> and buildhost is also already in eglibc-initial do_install
Jan 11 09:12:19 <mrmoku> heh
Jan 11 09:12:20 <mrmoku> | ERROR: Function 'Fetcher failure for URL: 'svn://www.eglibc.org/svn/branches/;module=eglibc-2_15;proto=http'. Unable to fetch URL svn://www.eglibc.org/svn/branches/;module=eglibc-2_15;proto=http from a
Jan 11 09:12:24 <mrmoku> | svn: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
Jan 11 09:12:33 <mrmoku> that libcap thing I hadd before already
Jan 11 09:12:54 <mrmoku> so unrelated to the toolchain update
Jan 11 09:13:31 <JaMa> sysroots/x86_64-linux/lib/libcap.so.2 here
Jan 11 09:13:59 <JaMa> maybe it was moved with those base_libdir changes and svn needs rebuilding
Jan 11 09:14:04 <mrmoku> hmm... have it there too
Jan 11 09:14:10 <mrmoku> rebuilding svn then
Jan 11 09:15:46 <JaMa> 'll push http://patchwork.openembedded.org/patch/18967/ today as it's fixing rebuild from scratch (stuff like readline-native)
Jan 11 09:15:56 <JaMa> but probably not related to your issue
Jan 11 09:17:03 <mrmoku> ok
Jan 11 09:18:27 <mrmoku> hmm... it's not svn-native? just svn?
Jan 11 09:19:03 <JaMa> subversion-native even
Jan 11 09:19:09 <mrmoku> :P
Jan 11 09:19:13 <mrmoku> ok
Jan 11 09:20:15 <JaMa> seems like chroot's svn is not even linked to libcap 
Jan 11 09:21:35 <JaMa> ah neither is the one in sysroot, so probably something indirect
Jan 11 09:41:22 <mrmoku> JaMa: hmm...  now I'm somehow doomed I guess
Jan 11 09:41:23 <mrmoku> | /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lcap
Jan 11 10:00:17 <JaMa> mrmoku: while building subversion right?
Jan 11 10:00:39 <JaMa> isn't libcap somehow broken on fs?
Jan 11 10:04:11 <mrmoku> hmm
Jan 11 10:04:18 <mrmoku> yeah, while building svn
Jan 11 10:04:42 <mrmoku> OE om-gta04@shr ~/shr-core $ l tmp-eglibc/sysroots/x86_64-linux/lib/libcap*
Jan 11 10:04:45 <mrmoku> -rw-r--r-- 1 bitbake bitbake 86336 Jan  8 13:33 tmp-eglibc/sysroots/x86_64-linux/lib/libcap.a
Jan 11 10:04:48 <mrmoku> lrwxrwxrwx 1 bitbake bitbake    11 Jan  8 13:33 tmp-eglibc/sysroots/x86_64-linux/lib/libcap.so -> libcap.so.2
Jan 11 10:04:51 <mrmoku> lrwxrwxrwx 1 bitbake bitbake    14 Jan  8 13:33 tmp-eglibc/sysroots/x86_64-linux/lib/libcap.so.2 -> libcap.so.2.22
Jan 11 10:04:54 <mrmoku> -rw-r--r-- 1 bitbake bitbake 56157 Jan  8 13:33 tmp-eglibc/sysroots/x86_64-linux/lib/libcap.so.2.22
Jan 11 10:05:18 <JaMa> same here, including filesize
Jan 11 10:08:02 <mrmoku> export LDFLAGS += " -L${STAGING_LIBDIR} "
Jan 11 10:08:14 <mrmoku> from subversion recipe
Jan 11 10:15:36 * JaMa hates those libdir moves.. :/
Jan 11 10:16:01 * mrmoku too 
Jan 11 10:16:55 <JaMa> moving other way then fedora/systemd is
Jan 11 10:18:17 <JaMa> what if you add -L${STAGING_DIR_HOST}${base_libdir} there?
Jan 11 10:18:52 <mrmoku> JaMa: NOTE: package subversion-native-1.7.2-r0: task do_compile: Started
Jan 11 10:18:55 <mrmoku> with exactly that
Jan 11 10:22:19 <mrmoku> | /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lcap
Jan 11 10:23:48 * JaMa wondering what exactly are those yocto buildhosts testing..
Jan 11 10:34:35 <JaMa> WARNING: QA Issue: /lib/libgudev-1.0.so.0.1.0 links to something under exec_prefix .. I hope they won't move whole libffi + glib + stuff to /lib too
Jan 11 10:37:27 <mrmoku> :P
Jan 11 10:45:23 <JaMa> NOTE: Running task 3011 of 7618
Jan 11 10:45:33 <JaMa> build from scratch going interestingly good
Jan 11 11:02:05 <mrmoku> JaMa: will trigger a build from scratch on my desktop too then
Jan 11 11:03:05 <JaMa> mrmoku: wait for efl bump
Jan 11 11:03:15 <mrmoku> ok
Jan 11 11:03:46 <JaMa> do you want me to push it now? or should I wait for test build to finish?
Jan 11 11:05:00 <JaMa> or you can build from meta-oe-contrib/jansa/test + meta-smartphone/jansa/efl
Jan 11 11:05:32 <mrmoku> will build from the test branches then
Jan 11 11:05:48 <mrmoku> I would like to start my build now as I have to go to meetings for the rest of the day
Jan 11 11:05:58 <mrmoku> so hopefully I have something when I come back this evening :-)
Jan 11 11:05:59 <JaMa> I see
Jan 11 11:06:23 <JaMa> and this evening I'll push it to shr branches I guess
Jan 11 11:06:51 <mrmoku> ok
Jan 11 11:13:15 <mrmoku> bbl
Jan 11 12:20:50 <CIA-77> SHR: 03Martin.Jansa 07libphone-ui-shr * r5b77d7d7e0e5 10/src/view/ (4 files): adapt to elm_hover API changes from r66989
Jan 11 12:20:55 <CIA-77> SHR: 03Martin.Jansa 07libphone-ui-shr * r6859416ba792 10/src/view/ (phone-log-view.c quick-settings-view.c): adapt to elm_toolbar API changes from r66927
Jan 11 12:20:55 <CIA-77> SHR: 03Martin.Jansa 07libphone-ui-shr * r5ce1bb482971 10/src/view/quick-settings-view.c: adapt to elm_hoversel API changes from r66343
Jan 11 12:21:05 <CIA-77> SHR: 03Martin.Jansa 07libphone-ui-shr * rf149d86442ea 10/src/util/ (ui-utils-contacts.c ui-utils.c): adapt to elm_list API changes from r66796
Jan 11 12:26:09 <JaMa> mrmoku: bumped EFL again so we don't need to ship that enjoy patch from me
Jan 11 13:13:02 <angelox|laptop> good morning guys
Jan 11 13:29:13 <CIA-77> SHR: 03Martin.Jansa 07meta-smartphone * r373ed8efdce7 10/meta-shr/recipes-shr/shr/libphone-ui-shr_git.bb: libphone-ui-shr: bump SRCREV to adapt to newer EFL api
Jan 11 15:51:56 <mrmoku> JaMa: ok, don't have to build from test branches anymore, right?
Jan 11 15:52:06 <mrmoku> I ran out of time before and so did not yet start building
Jan 11 15:53:17 <Alex[sp3dev]> GNUtoo: ping
Jan 11 15:54:46 <JaMa> mrmoku: yes, it's all pushed now to shr branches
Jan 11 15:55:30 <mrmoku> good :)
Jan 11 15:56:03 <mrmoku> build started
Jan 11 15:56:08 * mrmoku off to the next meeting :/
Jan 11 16:05:55 <paulk-desktop> anyone knowing GPRS very well?
Jan 11 16:07:30 <paulk-desktop> my question is: is it possible to connect to multiple APNs at the same time?
Jan 11 16:07:36 <paulk-desktop> like one for data and one for mms
Jan 11 16:11:09 <lindi-> paulk-desktop: should be
Jan 11 16:11:14 <paulk-desktop> nice
Jan 11 16:11:54 <paulk-desktop> (I'm working on Nexus S modem and it helps me figuring out a data structure)
Jan 11 16:14:49 <holtmann> paulk-desktop: Yes, but it depends on if the modem supports it and if the network does as well. You can also connect the same APN multiple times.
Jan 11 16:15:02 <paulk-desktop> ok
Jan 11 16:15:07 <paulk-desktop> apparently here it's possible
Jan 11 16:21:13 <GNUtoo> Alex[sp3dev], pong
Jan 11 16:45:09 <Alex[sp3dev]> GNUtoo: so, are you using s3c-fb on s5pc100?
Jan 11 16:55:16 <GNUtoo> yes
Jan 11 16:55:31 <GNUtoo> but it's modified
Jan 11 16:55:44 <GNUtoo> and it's s5pc110
Jan 11 16:56:06 <GNUtoo> it's from the samsung kernel
Jan 11 17:08:23 <Alex[sp3dev]> GNUtoo: i tried running vanilla and linaro on my exynos (s5pv310). The kernels with android fb seem to boot and switch to fb, while vanilla hangs. I have no clue how to debug since UART seems to be disabled or not routed (at least, it is said so on xda and I have not yet checked, gonna buy a connector and try tomorrow)
Jan 11 17:37:17 <GNUtoo> Alex[sp3dev], ok
Jan 11 17:37:42 <GNUtoo> Alex[sp3dev], I've UART on my nexus S
Jan 11 17:37:58 <GNUtoo> Alex[sp3dev], do you want me to try something?
Jan 11 17:38:35 <Alex[sp3dev]> GNUtoo: no, I think not. my cpu is different, so there may be something different
Jan 11 17:39:04 <Alex[sp3dev]> worst thing is that samsung used a single kernel for recovery/boot so i cannot simply reboot and dump ramconsole
Jan 11 17:39:27 <GNUtoo> my arch is s5pv210
Jan 11 17:39:59 <GNUtoo> ok there is the same on the galaxy tab
Jan 11 17:40:06 <GNUtoo> (single kernel)
Jan 11 17:40:18 <GNUtoo> kexec works?
Jan 11 17:40:20 <Alex[sp3dev]> is there uboot for s5p with fb support?
Jan 11 17:40:27 <GNUtoo> possible
Jan 11 17:40:36 <GNUtoo> not sure if it has fb support
Jan 11 17:40:42 <GNUtoo> but there is indeed uboot for it
Jan 11 17:40:47 <Alex[sp3dev]> kexec doesn't work (it is generally broken on armv7 smp and i spent some day trying to apply all fixes, but didn't get it working)
Jan 11 17:40:47 <GNUtoo> and it's mergerd in master
Jan 11 17:40:54 <GNUtoo> *upstream
Jan 11 17:41:01 <GNUtoo> ok
Jan 11 17:41:17 <GNUtoo> what's the device btw?
Jan 11 17:41:25 <Alex[sp3dev]> you see, there's no way to debug except fb since uart is not there.. do you think simply memcpy'ing to fb address will work?
Jan 11 17:41:35 <GNUtoo> but fb was merged upstream right?
Jan 11 17:41:39 <Alex[sp3dev]> it's galaxy s2, of course
Jan 11 17:41:42 <GNUtoo> ok
Jan 11 17:44:32 <GNUtoo> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c248b7d2960faec3e1b8f3f9c5d9d0df28e0a3c
Jan 11 17:45:44 <GNUtoo> Alex[sp3dev], ^^^
Jan 11 17:46:04 <Alex[sp3dev]> well, origen and other boards just use s3c-fb. if nothing works, i could just stick to the 3.1 kernel with android fb. for now, i just want to dump memory to figure out which atags are passed by default by sgs bootloader
Jan 11 17:46:18 <GNUtoo> ok
Jan 11 17:49:28 <Alex[sp3dev]> GNUtoo: which toolchain are you using?
Jan 11 17:50:44 <GNUtoo> ah right
Jan 11 17:50:55 <GNUtoo> I'm using the linaro one, gcc 4.6
Jan 11 17:51:04 <Alex[sp3dev]> link to binaries?
Jan 11 17:51:15 <GNUtoo> it's from oe
Jan 11 17:51:22 <GNUtoo> I build shr-core
Jan 11 17:51:29 <GNUtoo> and then I export the path to the toolchain
Jan 11 17:51:35 <GNUtoo> there are no official binaries for it
Jan 11 17:51:42 <GNUtoo> but it unalign stuff
Jan 11 17:51:51 <GNUtoo> so older kernels have the alignement problem
Jan 11 17:51:54 <Alex[sp3dev]> could you tar it? my host is i386 debian, dunno if your binaries will work
Jan 11 17:52:02 <GNUtoo> ah ouch
Jan 11 17:52:09 <GNUtoo> I've x86_64
Jan 11 17:52:28 <GNUtoo> if you're looking for a toolchain I know where to find one tough
Jan 11 17:52:41 <GNUtoo> but it may be for armv4
Jan 11 17:53:15 <Alex[sp3dev]> i've been building kernels with 2010q1 4.4 iirc. will that work for 3.2 or does it break? 
Jan 11 17:54:06 <GNUtoo> I guess it would work
Jan 11 17:54:10 <GNUtoo> do you want me to try?
Jan 11 17:55:52 <Alex[sp3dev]> well, if you have time, you could try. Honestly i think the problem is elsewhere. If i launch zImage, the screen is filled with noise. if i launch Image, it just hangs. if i launch zImage of 3.1 for origen, it fills with noise and then switches and fills with some other color, so i guess fb registers. I don't feel like bisecting from 3.1 to 3.2 since there were a lot of renames and fb driver was replaced
Jan 11 17:58:26 <GNUtoo> ok
Jan 11 17:58:38 <GNUtoo> do you have a link to your toolchain?
Jan 11 17:59:15 <Alex[sp3dev]> 2010q1-188 from sourcery
Jan 11 17:59:32 <Alex[sp3dev]> https://sourcery.mentor.com/sgpp/lite/arm/portal/release1294
Jan 11 18:18:34 <GNUtoo> larsc, hi
Jan 11 18:18:49 <GNUtoo> larsc, here's the thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/046853.html
Jan 11 18:24:26 <GNUtoo> Alex[sp3dev], btw does your device have the address changed?
Jan 11 18:24:37 <Alex[sp3dev]> GNUtoo: which address?
Jan 11 18:24:42 <GNUtoo> like that for instance:
Jan 11 18:24:44 <GNUtoo> -#define PLAT_PHYS_OFFSET               UL(0x20000000)
Jan 11 18:24:44 <GNUtoo> +#define PLAT_PHYS_OFFSET               UL(0x30000000)
Jan 11 18:25:09 <Alex[sp3dev]> let me check. should not be
Jan 11 18:25:16 <GNUtoo> mine does
Jan 11 18:25:49 <Alex[sp3dev]> no, 0x40000000, as other exynos boards
Jan 11 18:25:50 <GNUtoo> btw there is a 3.0 for crespo if I remember correctly the version
Jan 11 18:25:51 <GNUtoo> ok
Jan 11 18:26:34 <Alex[sp3dev]> i think i can make 3.1 android tree run, but i want vanilla because ultimately everyone will be using that, even android
Jan 11 18:27:02 <Alex[sp3dev]> if nothing works, i could start with backporting vanilla fb to a working kernel, actually
Jan 11 18:28:56 <GNUtoo> ok I understand and I know for android and vanilla
Jan 11 18:32:25 <GNUtoo> but I was telling that in another perspective
Jan 11 18:32:39 <GNUtoo> the perspective was to import the fb driver from 3.0
Jan 11 19:30:10 <morphis> heyho
Jan 11 19:30:59 <angelox|laptop> hey morphis!
Jan 11 19:31:34 <morphis> angelox|laptop: I hope you will not kill me; I rewrote most aurora stuff again :)
Jan 11 19:31:54 <morphis> but I will integrate your stuff before pushing
Jan 11 19:32:10 <morphis> most important thing is we got rid of the symbian/qt components
Jan 11 19:32:14 * angelox|laptop searches for his colt :P
Jan 11 19:32:16 <morphis> as they does not scale
Jan 11 19:32:28 <morphis> for various display resolution without much adjustments
Jan 11 19:32:34 <angelox|laptop> that is good
Jan 11 19:32:43 <morphis> but I will tell you more when it's ready
Jan 11 19:32:58 <morphis> currently I don't have much time to be available online due to day work
Jan 11 19:33:20 <angelox|laptop> ok
Jan 11 19:34:05 <angelox|laptop> do you know what can i do now?
Jan 11 19:34:12 <angelox|laptop> maybe documentation ;)
Jan 11 19:36:06 <morphis> yes but please wait until it's ready
Jan 11 19:36:11 <morphis> maybe I will push this weekend
Jan 11 19:37:46 <angelox|laptop> ok
Jan 11 19:49:06 <GNUtoo> mickeyl, ping
Jan 11 19:49:08 <GNUtoo> mrmoku, ping
Jan 11 19:49:15 <GNUtoo> I think alsaloop won't work
Jan 11 19:49:21 <GNUtoo> the usage is near 20%
Jan 11 19:49:26 <GNUtoo> at max
Jan 11 19:49:36 <GNUtoo> it varies between 10 and 20%
Jan 11 19:49:47 <GNUtoo> only for modem->CODEC
Jan 11 19:52:55 <GNUtoo> ping mrmoku mickeyl 
Jan 11 20:12:05 <GNUtoo> I took some advises in #alsa
Jan 11 20:12:10 <GNUtoo> and I'll use the kernel module
Jan 11 20:26:54 <mrmoku> GNUtoo: pong
Jan 11 20:28:23 <GNUtoo> mrmoku, I'm trying to lower the CPU usage of alsaloop
Jan 11 20:28:26 <mrmoku> GNUtoo: snd-aloop?
Jan 11 20:28:27 <GNUtoo> in #alsa
Jan 11 20:28:32 <GNUtoo> not a good idea
Jan 11 20:28:35 <GNUtoo> it's not what we want
Jan 11 20:28:38 <GNUtoo> it's a virtual card
Jan 11 20:28:42 <GNUtoo> where you write in it
Jan 11 20:28:46 <GNUtoo> and then read in it
Jan 11 20:28:51 <GNUtoo> it doesn't forward
Jan 11 20:28:58 <mrmoku> ok
Jan 11 20:29:55 <mrmoku> GNUtoo: how's the cpu usage of your forwarder?
Jan 11 20:31:08 <GNUtoo> between 10 and 20% ony for modem->CODEC
Jan 11 20:31:28 <GNUtoo> I guess it's way too high
Jan 11 20:32:05 <mrmoku> hmm, so what is the solution?
Jan 11 20:32:10 <GNUtoo> no idea
Jan 11 20:32:16 <GNUtoo> what's perf?
Jan 11 20:33:00 <mrmoku> community/perf 3.2-1 Linux kernel performance auditing tool
Jan 11 20:33:50 <GNUtoo> yes http://www.pixelbeat.org/programming/profiling/
Jan 11 20:33:51 <GNUtoo> hmmm
Jan 11 20:33:56 <GNUtoo> s/yes//
Jan 11 20:40:47 <GNUtoo> ok I now know how to use gprof again(I forgetten how to use it)
Jan 11 20:41:11 <GNUtoo> I need to cross compile gprof now that I've the dump I guess
Jan 11 20:55:23 <nschle85> GNUtoo: do you have any experiences with pandaboard (ES) ?
Jan 11 20:59:01 <GNUtoo> no but what's the question?
Jan 11 21:01:40 <nschle85> GNUtoo: i need to setup a productive streaming client in my living room. so the option is to use xbmc or a kde program. 
Jan 11 21:02:18 <nschle85> GNUtoo: which distribution should i take ?
Jan 11 21:03:03 <nschle85> GNUtoo: and it may be necessary to compile some stuff because my infrared receiver is not supported yet in LIRC
Jan 11 21:03:53 <nschle85> so ithought somethink oe core based would be good
Jan 11 21:04:46 <nschle85> the board itself is not supported in shr so i would like to use somethink which actively supports the board
Jan 11 21:06:44 <GNUtoo> yes like angstrom
Jan 11 21:07:04 <GNUtoo> it's for music only?
Jan 11 21:07:09 <GNUtoo> or also for videos?
Jan 11 21:07:15 <GNUtoo> do you know mpd?
Jan 11 21:10:06 <nschle85> GNUtoo: its also for video
Jan 11 21:10:23 <nschle85> GNUtoo: i would like to stream kartina.tv
Jan 11 21:10:52 <nschle85> there is a plugin for xbmc and a kde app vlc-record
Jan 11 21:11:22 <GNUtoo> I don't know xbmc sorry
Jan 11 21:11:29 <GNUtoo> in fact I only know mpd and xmms2
Jan 11 21:11:34 <GNUtoo> I never used media centers
Jan 11 21:11:44 <GNUtoo> there is even one made in efl
Jan 11 21:11:49 <GNUtoo> made by captainigloo
Jan 11 21:11:53 <GNUtoo> enna I think
Jan 11 21:13:18 <nschle85> GNUtoo: should i investigate angstrom ?
Jan 11 21:13:58 <GNUtoo> yes they have an IRC channel
Jan 11 21:14:07 <nschle85> GNUtoo: i think shr would also be good, but its missing the board support
Jan 11 21:14:20 <GNUtoo> shr or angstrom is nearly the same thing
Jan 11 21:14:24 <GNUtoo> for such device
Jan 11 21:14:35 <GNUtoo> and angstrom would be a bit better....
Jan 11 21:14:46 <GNUtoo> else there is ubuntu or other distros
Jan 11 21:14:51 <GNUtoo> look at the pandaboard wiki
Jan 11 21:15:00 <GNUtoo> or in wiki that talk about the pandaboard
Jan 11 21:18:27 <nschle85> GNUtoo: ok thank you
Jan 11 21:22:31 <nschle85> GNUtoo: do you know why jama is not only ?
Jan 11 21:22:37 <nschle85> online ?
Jan 11 21:23:12 <GNUtoo> no idea
Jan 11 21:48:10 <nschle85> GNUtoo: do you know the irc name of Koen Kooi?
Jan 11 21:48:17 <GNUtoo> yes 
Jan 11 21:48:19 <GNUtoo> koen
Jan 11 21:48:22 <GNUtoo> why?
Jan 11 21:48:37 <GNUtoo> It's not a good idea bothering him, he's known to be rude with people
Jan 11 21:49:12 <nschle85> GNUtoo: then he should invest more time in documentation :-)
Jan 11 21:49:23 <GNUtoo> why?
Jan 11 21:49:25 <GNUtoo> what's wrong?
Jan 11 21:50:07 <nschle85> GNUtoo: how do i setup a build env for angstrom-core  / pandaboard ?
Jan 11 21:50:18 <nschle85> in shr we have makefile
Jan 11 21:50:21 <GNUtoo> ah ok
Jan 11 21:50:25 <GNUtoo> easy
Jan 11 21:50:40 <GNUtoo> http://sakrah.homelinux.org/blog/2011/03/using-openembedded-core-to-build-angstrom-for-qemu/
Jan 11 21:50:49 <GNUtoo> but there is also some images and feeds
Jan 11 21:50:54 <GNUtoo> for instance narcisius
Jan 11 21:51:05 <GNUtoo> http://narcissus.angstrom-distribution.org/
Jan 11 21:51:34 <GNUtoo> only that it's slow as hell here
Jan 11 21:53:32 <nschle85> http://narcissus.angstrom-distribution.org/ server not fould
Jan 11 21:53:35 <nschle85> found
Jan 11 21:53:50 <GNUtoo> yes same for www.angstrom-distribution.org
Jan 11 21:53:55 <GNUtoo> they have a problem currently
Jan 11 21:54:21 <nschle85> no, for me it works
Jan 11 21:54:39 <nschle85> may be a dns problem
Jan 11 21:54:40 <GNUtoo> ok
Jan 11 21:54:55 <GNUtoo> I hope it's not my DNS
Jan 11 21:55:05 <nschle85> GNUtoo: or routing
Jan 11 21:55:26 <nschle85> i sometimes have routing problems to openembedded
Jan 11 22:00:03 <GNUtoo> I run my own DNS
Jan 11 22:00:27 <PaulFertser> nschle85: btw, http://sourceforge.net/apps/mediawiki/mbm/index.php?title=MBM http://sourceforge.net/apps/mediawiki/mbm/index.php?title=Using_mbm-gpsd suggests there're some GSM/UMTS modems that have GPS as well, and they provide gpsd with pseudo-devices, just like i suggested to you it seems.
Jan 11 22:01:13 <nschle85> PaulFertser: thank you
Jan 11 22:15:24 <GNUtoo> nschle85, did you try that: http://sakrah.homelinux.org/blog/2011/03/using-openembedded-core-to-build-angstrom-for-qemu/
Jan 11 22:15:25 <GNUtoo> ?
Jan 11 22:16:42 <nschle85> no, but page opens
Jan 11 22:16:49 <nschle85> now ill try
Jan 11 22:17:04 <GNUtoo> it's to build angstrom-core
Jan 11 22:17:18 <nschle85> please visit #angstrom channel, i found a brother with same problem :-)
Jan 11 22:30:24 <nschle85> GNUtoo: what do you think about a "Desktop Phone" ? 
Jan 11 22:30:39 <GNUtoo> what would that mean?
Jan 11 22:30:47 <GNUtoo> I must go to sleep btw
Jan 11 22:31:28 <nschle85> FSO+USB internet stick, + SHR applications
Jan 11 22:31:52 <GNUtoo> ok
Jan 11 22:31:56 <GNUtoo> I must go bye
Jan 11 22:32:01 <nschle85> bye
Jan 11 22:46:32 <nschle85> mickel ping
Jan 11 22:46:43 <nschle85> mickeyl: ping
**** ENDING LOGGING AT Thu Jan 12 02:59:57 2012