**** BEGIN LOGGING AT Thu Sep 08 02:59:57 2011
Sep 08 06:04:20 <juri_> ok, got a treo 700w to attempt to hack, and a neo1973 to reprogram.
Sep 08 09:33:37 <radekp> hi, any idea why fsodeviced kills usb networking on startup (on debian unstable)
Sep 08 09:34:39 <radekp> i suspect that it has to do something with usb host mode and i can even workaround it with ignore_usbhost=true, but still it's annoying
Sep 08 09:55:30 <ssam> is it corrct that if i install QI, it will always try to boot from SD, but i can hold down aux to get a boot menu and boot from NAND?
Sep 08 09:56:02 <ssam> (I am wanting to install debian. and currently have SHR on NAND)
Sep 08 10:09:21 <jluis_> ssam: if you press the aux menu before power you will get the NOR u-boot menu where booting from NAND is the default option
Sep 08 10:09:48 <ssam> ok, thanks
Sep 08 10:13:55 <jluis_> if aux is pressed just after power qui will skip the first SD partition with /boot/uImage-GTA02.bin and try the next  part with the fille or boot from NAND
Sep 08 10:15:10 <jluis_> the last partition scanned by qi is mmcblk0p3
Sep 08 10:22:24 <mickey|office> radekp: the reason could be that USB host is a resource and fsodeviced enables all resources if fsousaged can't be reached (for whatever reason), so USB host mode is then being enabled, which effectively kills USB client unfortunately
Sep 08 10:24:20 <mickey|office> morning, btw.
Sep 08 10:32:10 <ssam> i am using "TASKS="ALL" QI=true SINGLE_PART=true SD_SWAP_SIZE=256 ./install.sh all", but it stops after "Fetching time from ntp.fu-berlin.de with rdate"
Sep 08 10:36:09 <ssam> on the openmoko "rdate -s ntp.fu-berlin.de" fails with "rdate: timeout connecting to time server". ping google.com works, so the netowrk is up
Sep 08 10:41:05 <jluis_> try editing the server on install.sh to pool.ntp.org or check your firewall configuration 
Sep 08 10:45:44 <ssam> i guess it must be todo with the iptable command for allowing the openmoko to access the network through my desktop. i think i'll just skip the time but
Sep 08 10:45:47 <ssam> bit
Sep 08 10:52:41 <jluis_> acording to the documentation of install.sh you could just call it for the next steps replacing "all" with  "partition format mount debian apt fso configuration tasks kernel cleanup unmount"
Sep 08 10:59:59 <lindi-> ssam: is that ntp server down?
Sep 08 11:00:22 <ssam> no, work with ntpdate on my desktop
Sep 08 11:01:12 <lindi-> ssam: you should not use NOR u-boot for booting
Sep 08 11:01:50 <lindi-> ssam: since you can't fix bugs in that without debug board
Sep 08 11:02:00 <lindi-> ssam: you can boot NAND with qi too if you hit AUX at the right time
Sep 08 11:02:11 <ssam> ok
Sep 08 11:02:13 <lindi-> ssam: I don't think this is particularly usable but I have some ideas on how to improve that
Sep 08 11:02:41 <lindi-> ssam: I uploaded qi to debian recently in case you wonder why :)
Sep 08 11:02:59 <ssam> because you need SHR (or something) on NAND to install debian. and the debian page recommend QI
Sep 08 11:03:11 <lindi-> ssam: http://packages.qa.debian.org/q/qi.html
Sep 08 11:03:24 <ssam> but once you put QI on then it will try to boot from SD
Sep 08 11:03:43 <lindi-> qi also lacks a good manual
Sep 08 11:04:02 <lindi-> ssam: also I suggest #openmoko-debian
Sep 08 11:04:23 <ssam> ok, shall we carry on there
Sep 08 11:05:26 <lindi-> ssam: I'm at work right now so I can't promise anything :)
Sep 08 11:05:40 <ssam> ok
Sep 08 11:25:34 <radekp> mickey|office: hi, thanks that sounds good, i have installed and run fsousaged and now it seems ok
Sep 08 12:08:47 <jluis_> where can I get  udev-173.tar.gz and the md5 now that git.kernel.org is down 
Sep 08 12:19:57 <JaMa> jluis_: try this one http://launchpad.net/udev/main/173/+download/udev-173.tar.bz2
Sep 08 12:20:06 <JaMa> ah you want gz
Sep 08 12:20:26 <JaMa> http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/udev-173.tar.gz
Sep 08 12:20:50 <jluis_> no problem i will generate it :)  thanks JaMa
Sep 08 12:56:05 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * rbd71871a880b 10/meta-openmoko/recipes-graphics/drm/ (libdrm/glamo.patch libdrm_2.4.26.bbappend): meta-openmoko: libdrm: add glamo support
Sep 08 12:56:16 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * r7cc0e2df06ce 10/meta-openmoko/recipes-graphics/mesa/ (mesa-dri/glamo.patch mesa-dri_7.11.bbappend): meta-openmoko: mesa-dri: add glamo support
Sep 08 12:56:16 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * rd5d53e418307 10/meta-shr/conf/distro/shr.conf: shr: set PREFERRED_PROVIDER_virtual/libx11-native
Sep 08 13:13:07 <DocScrutinizer> [Notice] -christel- [Global Notice] Hi all, as previously promised today will be the day where the network goes up in flames... I mean, where we carry out some upgrades to the ircd. I'm about to kill off a number of servers and the affected user count is ~8K! Hopefully this won't take long but I suggest you brace for impact..
Sep 08 13:36:31 <jfthomps> I need some help building shr-testing
Sep 08 13:36:42 <JaMa> what exactly?
Sep 08 13:36:57 <jfthomps> I'm following http://shr-project.org/trac/wiki/Building SHR
Sep 08 13:37:22 <jfthomps> when I get to 'bitbake -k shr-image', I'm getting "ERROR: Unable to parse /OE/shr-testing/openembedded/recipes/ed/ed_0.5.bb"
Sep 08 13:37:38 <JaMa> you need older bitbake for shr-testing
Sep 08 13:37:43 <jfthomps> then it gives some python error stuff
Sep 08 13:38:04 <jfthomps> so http://shr-project.org/trac/wiki/Building SHR doesn't work for shr-testing?
Sep 08 13:38:43 <JaMa> jfthomps: no, because bitbake checkout tracks bitbake/master and that is more picky about multiline comments etc
Sep 08 13:38:57 <JaMa> jfthomps: there should be shr-testing/bitbake -> ../bitbake symlink
Sep 08 13:39:58 <JaMa> jfthomps: do rm -f shr-testing/bitbake; cp -ra bitbake shr-testing/; cd shr-testing/bitbake; git checkout 1.13.1
Sep 08 13:40:28 <JaMa> not sure about 1.13.1 (just test few older versions)
Sep 08 13:40:33 <jfthomps> is that /OE/shr-testing/bitbake?  if so, I don't have 'bitbake' under /OE/shr-testing
Sep 08 13:41:47 <jfthomps> I have /OE/openembedded/recipes/bitbake and /OE/shr-testing/openembedded/recipes/bitbake
Sep 08 13:42:23 <JaMa> and /OE/bitbake?
Sep 08 13:42:44 <jfthomps> no
Sep 08 13:42:52 <JaMa> then call "make setup-bitbake" in /OE dir
Sep 08 13:43:24 <JaMa> then mv /OE/bitbake /OE/shr-testing/bitbake;  cd shr-testing/bitbake; git checkout 1.13.1
Sep 08 13:44:05 <jfthomps> ok, that works so far
Sep 08 13:44:47 <jfthomps> do I try bitbake -k shr-image again now?
Sep 08 13:44:59 <JaMa> check $PATH
Sep 08 13:45:04 <JaMa> after . ./setup-env
Sep 08 13:45:12 <JaMa> you should see /OE/shr-testing/bitbake/bin there
Sep 08 13:45:37 <jfthomps> yep, it's there
Sep 08 13:45:49 <JaMa> ok then you can try image
Sep 08 13:46:29 <jfthomps> :( same error message
Sep 08 13:46:47 <jfthomps> I did get this first though:
Sep 08 13:46:51 <JaMa> then checkou 1.12
Sep 08 13:46:52 <jfthomps> NOTE: Cache version mismatch, rebuilding...
Sep 08 13:46:55 <jfthomps> ok
Sep 08 13:49:47 <jfthomps> ok, looks like it is working now
Sep 08 13:49:52 <jfthomps> thanks for your help!
Sep 08 13:50:10 <JaMa> could you please update wiki with this information?
Sep 08 13:50:18 <jfthomps> ok
Sep 08 13:50:18 <JaMa> the samy does apply for shr-unstable
Sep 08 13:50:27 <JaMa> only shr-core needs bitbake from bitbake/master or shr-chroot
Sep 08 13:50:35 <jfthomps> shr-unstable needs bitbake 1.12 as well?
Sep 08 13:51:13 <JaMa> yes
Sep 08 13:51:18 <jfthomps> ok, got it
Sep 08 15:28:00 <jfthomps> wiki page updated and instructions tested
Sep 08 15:53:27 <angelox|laptop> hi!
Sep 08 17:16:07 <morphis> heyho
Sep 08 17:21:32 <pespin> morphis, hi :)
Sep 08 17:22:10 <pespin> morphis, could you tell me which is the support status of the pre 3?
Sep 08 17:35:30 <dcordes> gnutoo: I received interesting bit of information on bcm4329 from phh 
Sep 08 17:35:57 <phh> ah you found something ?
Sep 08 17:36:50 <dcordes> phh: m-m
Sep 08 17:36:55 <dcordes> unfortunately not
Sep 08 17:37:01 <phh> ah
Sep 08 17:37:09 <dcordes> I am compiling the non-working driver with the working driver's makefile now
Sep 08 17:37:29 <dcordes> phh: I thought I might ping gnutoo cuase he might have an idea
Sep 08 17:37:34 <dcordes> phh: regarding your hint
Sep 08 17:37:55 <dcordes> gnutoo: so.. :) he said some define is influencing how wext works
Sep 08 17:38:06 <phh> could be.
Sep 08 17:38:09 <phh> i might be messing with another driver
Sep 08 17:38:21 <phh> (even though i think pretty much all the drivers i've seen are like that)
Sep 08 17:39:06 <dcordes> phh: because all of them are for andorid use ?
Sep 08 17:39:16 <phh> no
Sep 08 17:39:25 <dcordes> hm
Sep 08 17:39:38 <phh> one is like nvidia stuff, os abstraction layer everywhere
Sep 08 17:39:40 <phh> ralink thingy
Sep 08 17:39:52 <dcordes> I see
Sep 08 17:39:58 <phh> in early stages of this driver, only iwpriv stuff were working i think
Sep 08 17:40:34 <dcordes> afaik android doesn't need the wext
Sep 08 17:40:46 <phh> it's not really android relaetd
Sep 08 17:40:53 <dcordes> and no matter if you could scan in non-android, in android it always worked
Sep 08 17:41:02 <phh> it's that android is more closed system, so wifi constructors can change wpa_supplicant the wait they want
Sep 08 17:41:12 <phh> and indeed most constructors uses proprietary extensions
Sep 08 17:41:35 <dcordes> that's why non-android is always broken
Sep 08 17:41:43 <phh> dcordes: and hum btw, using android's wpa_supplicant should work on non-android
Sep 08 17:41:50 <phh> if you feel like rebuilding it and fixing it
Sep 08 17:42:11 <phh> or if you feel like having an android /system
Sep 08 17:42:16 <phh> (but that's only good for testing...=)
Sep 08 17:42:49 <dcordes> phh: you mean if I take the driver version that works in android but not in non-android I can fix non-android using android's wpa_supplicant binary ?
Sep 08 17:43:57 <dcordes> phh: gotta get going. thanks for the input! I hope it will ring a bell for gnutoo 
Sep 08 17:44:23 <phh> i think so
Sep 08 17:44:48 <phh> but i know there have been some extensions to wpa_supplicant "protocol" as well in android, AFAIK they are minor, but well ..
Sep 08 17:50:17 <morphis> pespin: it's not supported
Sep 08 17:50:24 <morphis> pespin: and I will not do the support for it
Sep 08 17:50:42 <pespin> ok :)
Sep 08 18:01:15 * angelox|nokia forgots his laptop turned on :(
Sep 08 18:03:41 <angelox|nokia> Hi morphis
Sep 08 18:07:22 <morphis> angelox|nokia: hey
Sep 08 18:07:29 <morphis> angelox|nokia: I am back in some minutes
Sep 08 18:07:37 <angelox|nokia> ok
Sep 08 18:13:58 <morphis> gnutoo: ping
Sep 08 18:19:03 <angelox|nokia> morphis: i've few ideas to a *far* release of aurora,mainly in the default layout and in the default theme
Sep 08 18:19:41 <angelox|nokia> morphis: i did create SVG images based in my ideas,but i haven't them here,at home i'll try to send them to you
Sep 08 18:20:20 <angelox|nokia> i hope,when you get here again,you see these messages :)
Sep 08 18:37:25 <GNUtoo|laptop> hi
Sep 08 18:37:27 <GNUtoo|laptop> hi morphis 
Sep 08 18:37:31 <GNUtoo|laptop> how's the nexus S?
Sep 08 18:37:38 <morphis> GNUtoo|laptop: very good
Sep 08 18:37:52 <GNUtoo|laptop> did you do a review of it?
Sep 08 18:38:33 <GNUtoo|laptop> like on a wiki(since there is no review of it on your blog)
Sep 08 18:38:37 <GNUtoo|laptop> morphis, I must PM you
Sep 08 18:53:38 <nschle85> hello, i have a problem, if i bitbake gcc it hangs (log) ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored
Sep 08 18:58:04 <GNUtoo|laptop> nschle85, hi
Sep 08 18:58:26 <nschle85> GNUtoo|laptop: hi :-)
Sep 08 18:58:29 <GNUtoo|laptop> libpseudo has something to do with pseudo I guess
Sep 08 18:58:29 <GNUtoo|laptop> are you in the right dir when you bitbake that?
Sep 08 18:59:38 <nschle85> i hope so i always bitbake in the same directory
Sep 08 19:00:16 <nschle85> who misses libpseudo is it the bitbake binary ?
Sep 08 19:00:30 <nschle85> ldd ??? 
Sep 08 19:02:04 <nschle85> gnutoo: i use JaMa|Off: Makefile to setup the environment
Sep 08 19:03:01 <GNUtoo|laptop> nschle85, it's pseudo
Sep 08 19:03:04 <GNUtoo|laptop> a fakeroot replacement
Sep 08 19:03:08 <GNUtoo|laptop> from the yocto project
Sep 08 19:04:35 <nschle85> GNUtoo|laptop: and how is it called ? 'which pseudo' gives no result
Sep 08 19:04:49 <GNUtoo|laptop> it's build with openembedded
Sep 08 19:04:58 <GNUtoo|laptop> *oe-core
Sep 08 19:05:16 <nschle85> i already bitbaked pseudo-native
Sep 08 19:06:03 <nschle85> gnutoo: i heard that there are problems if pseudo is updated
Sep 08 19:22:30 <GNUtoo|laptop> maybe look from where comes that lib
Sep 08 19:22:30 <GNUtoo|laptop> form what native package
Sep 08 19:23:13 <GNUtoo|laptop> but note that pseudo is built before openembedded starting to build something
Sep 08 19:23:13 <GNUtoo|laptop> it's done in 2 passes:
Sep 08 19:23:13 <GNUtoo|laptop> first pseudo is built
Sep 08 19:23:13 <GNUtoo|laptop> then the real build starts
Sep 08 19:23:32 <nschle85> GNUtoo|laptop: yes
Sep 08 19:24:42 <nschle85> if i clean pseudo-native and delete pseudodone it is rebuild
Sep 08 19:25:59 <nschle85> libpseudo.so is located in shr-core/tmp/sysroots/x86_64-linux/usr/lib/pseudo/lib64
Sep 08 19:27:48 <GNUtoo|laptop> ok
Sep 08 19:28:58 <nschle85> should i copy it to x86_64-linux/usr/lib ?
Sep 08 19:30:01 <GNUtoo|laptop> ok
Sep 08 19:30:01 <GNUtoo|laptop> maybe report on oe ml?
Sep 08 19:32:01 <nschle85> GNUtoo|laptop: i dont know, is it a real problem ?
Sep 08 19:32:31 <nschle85> GNUtoo|laptop: how can i check the ld-library path used in bitkake env ?
Sep 08 19:33:41 <nschle85> GNUtoo|laptop: have you got a new phone ?
Sep 08 19:33:41 <GNUtoo|laptop> bitbake -e
Sep 08 19:33:51 <GNUtoo|laptop> not yet
Sep 08 19:33:55 <GNUtoo|laptop> why?
Sep 08 19:34:19 <nschle85> GNUtoo|laptop: i thought you destroyed one and your laptop too
Sep 08 19:34:36 <GNUtoo|laptop> I destroyed one hdd and 1 phone
Sep 08 19:35:13 <GNUtoo|laptop> it was an htcdream
Sep 08 19:35:13 <GNUtoo|laptop> and I had 2 of them
Sep 08 19:35:13 <GNUtoo|laptop> and only the screen of the phone is destroyed
Sep 08 19:35:36 <nschle85> GNUtoo|laptop: and have you got your u-boot problem soved ?
Sep 08 19:35:40 <nschle85> solved
Sep 08 19:35:49 <GNUtoo|laptop> no idea
Sep 08 19:35:55 <GNUtoo|laptop> building takes longer now that I work
Sep 08 19:36:26 <GNUtoo|laptop> so I just built an om-gta02 image now
Sep 08 19:36:33 <GNUtoo|laptop> I'm flashing it
Sep 08 19:36:52 <nschle85> GNUtoo|laptop: do you flash directly to phone ?
Sep 08 19:37:17 <GNUtoo|laptop> yes
Sep 08 19:37:37 <GNUtoo|laptop> I forgott NAND scrub tough
Sep 08 19:37:38 <GNUtoo|laptop> if it doesn't work I'll reflash
Sep 08 19:37:49 <nschle85> for me its too long so i alwys copy to sdcard
Sep 08 19:37:51 <GNUtoo|laptop> or maybe I should NAND scrub now
Sep 08 19:37:51 <GNUtoo|laptop> ?
Sep 08 19:37:57 <GNUtoo|laptop> ok
Sep 08 19:38:13 <GNUtoo|laptop> yes it's long
Sep 08 19:38:14 <GNUtoo|laptop> but else I must dedicate a sdcard to it
Sep 08 19:38:15 <GNUtoo|laptop> and it's a mess
Sep 08 19:38:23 <GNUtoo|laptop> while they are numbered....some are broken
Sep 08 19:38:52 <GNUtoo|laptop> and I lost my number<->what's inside file
Sep 08 19:38:52 <nschle85> GNUtoo|laptop: hmm buy a new one, and install qi
Sep 08 19:38:57 <GNUtoo|laptop> in the hdd crash
Sep 08 19:39:11 <GNUtoo|laptop> new what?
Sep 08 19:39:26 <nschle85> GNUtoo|laptop: sd card
Sep 08 19:40:33 <GNUtoo|laptop> I've no time to buy new things
Sep 08 19:40:33 <GNUtoo|laptop> aha timeout -110
Sep 08 19:40:34 <GNUtoo|laptop> ah no
Sep 08 19:40:34 <GNUtoo|laptop> I was flashing on kernel
Sep 08 19:40:35 <GNUtoo|laptop> never mind I'll nand scrub
Sep 08 19:42:04 <nschle85> GNUtoo|laptop: hope gta04 will be released soon :-)
Sep 08 19:42:22 <GNUtoo|laptop> me too
Sep 08 19:45:25 <GNUtoo|laptop> and I hope the wifi chip will be ok 
Sep 08 19:46:17 <nschle85> GNUtoo|laptop: lsof says: /home/nschle85/build-core-shr/shr-core/tmp/sysroots/x86_64-linux/usr/lib/pseudo/lib64/libpseudo.so
Sep 08 19:46:36 <nschle85> so the file may be found but it cannot pre loaded
Sep 08 19:46:55 * angelox|laptop is back
Sep 08 19:48:05 <nschle85> GNUtoo|laptop: i could cry... i want to compile shr-image and it does not work
Sep 08 19:48:08 <GNUtoo|laptop> ok
Sep 08 19:49:30 <nschle85> GNUtoo|laptop: the reason to split the repository was to avoid such situations but at the moment its much worse than before
Sep 08 19:52:46 <GNUtoo|laptop> or you could report to the mailing list
Sep 08 19:52:46 <GNUtoo|laptop> or try to debug harder
Sep 08 19:52:46 <GNUtoo|laptop> like ldd
Sep 08 19:52:46 <GNUtoo|laptop> etc...
Sep 08 19:52:47 <GNUtoo|laptop> you could also ask in #oe
Sep 08 19:52:48 <GNUtoo|laptop> or in #yocto
Sep 08 19:52:48 <GNUtoo|laptop> or something like taht
Sep 08 19:52:49 <GNUtoo|laptop> *that
Sep 08 19:52:51 <GNUtoo|laptop> I know, but what ca I do?
Sep 08 19:53:44 <nschle85> GNUtoo|laptop: i thought you are a kind of expert :-)
Sep 08 19:53:53 <nschle85> GNUtoo|laptop: so i asked you
Sep 08 19:53:59 <GNUtoo|laptop> I meant:
Sep 08 19:54:06 <GNUtoo|laptop> what can I do against oe-core
Sep 08 19:54:13 <GNUtoo|laptop> I mean everyone is migrating to it
Sep 08 19:54:17 <GNUtoo|laptop> I cannot revert that
Sep 08 19:54:34 <GNUtoo|laptop> and I know some stuff
Sep 08 19:54:40 <GNUtoo|laptop> but I cannot know every solution to every problem
Sep 08 19:55:52 <nschle85> GNUtoo|laptop: ups... ok the decision process to split the repository was very fast i think...  
Sep 08 19:55:59 <GNUtoo|laptop> here it refuses to load your library
Sep 08 19:55:59 <GNUtoo|laptop> you must try to findout why
Sep 08 19:55:59 <GNUtoo|laptop> look with ldd
Sep 08 19:55:59 <GNUtoo|laptop> and match it with the libs that you have
Sep 08 19:57:31 <nschle85> GNUtoo|laptop: ldd pseudo
Sep 08 19:57:31 <nschle85>         linux-vdso.so.1 =>  (0x00007fffe8664000)
Sep 08 19:57:31 <nschle85>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe7c11ab000)
Sep 08 19:57:31 <nschle85>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe7c0fa7000)
Sep 08 19:57:31 <nschle85>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7c0c12000)
Sep 08 19:57:31 <nschle85>         /lib64/ld-linux-x86-64.so.2 (0x00007fe7c13f4000)
Sep 08 19:58:16 <nschle85> so libpseudo is not used by pseudo ?
Sep 08 19:58:55 <GNUtoo|laptop> yes
Sep 08 19:58:55 <GNUtoo|laptop> but now it's done
Sep 08 19:58:55 <GNUtoo|laptop> and everybody migrated or is migrating to it
Sep 08 19:58:56 <GNUtoo|laptop> the only way back
Sep 08 19:58:56 <GNUtoo|laptop> is to take oe-core
Sep 08 19:58:57 <GNUtoo|laptop> and to merge it again in one repo
Sep 08 19:58:57 <GNUtoo|laptop> since oe-dev is too old....
Sep 08 20:01:07 <nschle85> GNUtoo|laptop: ok, lets do it :-)
Sep 08 20:03:02 <nschle85> GNUtoo|laptop: at the moment, GCC has a bug, a fixing patch is available in openembedded-core but not in shr openembedded-core-contrib
Sep 08 20:03:35 <nschle85> GNUtoo|laptop: so we have to wait until JaMa|Off: will merge the fix...
Sep 08 20:04:27 <nschle85> GNUtoo|laptop: so why we have this branch ?
Sep 08 20:05:52 <nschle85> GNUtoo|laptop: i am also not amused about the stability of shr source code
Sep 08 20:06:04 <GNUtoo|laptop> neither do I
Sep 08 20:06:22 <GNUtoo|laptop> we must do a test framework
Sep 08 20:06:24 <GNUtoo|laptop> dos1, ping
Sep 08 20:09:49 <nschle85> GNUtoo|laptop: i have a dedicated server running jenkins
Sep 08 20:10:22 <dos1> GNUtoo|laptop: pong
Sep 08 20:10:40 <nschle85> GNUtoo|laptop: but the problem at the moment is, that the most problems are seen only during a complete rebuild
Sep 08 20:10:55 <GNUtoo|laptop> dos1, what's the status of the white keyboard?
Sep 08 20:11:03 <nschle85> dos1: dobrij den
Sep 08 20:11:20 <dos1> nschle85: dzień dobry ;)
Sep 08 20:11:24 <dos1> GNUtoo|laptop: white keyboard?
Sep 08 20:12:11 <nschle85> dos1: white letters on white keys i think (observed on N900 too)
Sep 08 20:12:15 <dos1> ach
Sep 08 20:12:30 <dos1> GNUtoo|laptop: if you want, i can try to fix it
Sep 08 20:12:39 <dos1> but tomorrow
Sep 08 20:12:54 <dos1> well, i'm not using gry theme, so i just forgot about it :)
Sep 08 20:13:15 <nschle85> dos1: iam using shr-theme
Sep 08 20:13:26 <dos1> nschle85: shr's default theme is gry*
Sep 08 20:13:33 <dos1> (e-wm and elementary)
Sep 08 20:13:45 <nschle85> dos1: ok
Sep 08 20:14:18 <nschle85> dos1: i have a stupid question: why it was destroyed ? it worked in old oe dev !
Sep 08 20:14:39 <dos1> nschle85: old OE-dev has old EFL
Sep 08 20:14:48 <dos1> nschle85: upgrade it in OE-dev and you'll get the same :]
Sep 08 20:15:08 <dos1> nschle85: gry* theme just has to be updated to match newer codebase
Sep 08 20:15:20 <nschle85> dos1: ok
Sep 08 20:15:43 <dos1> e theming isn't stable, some group names are sometimes changed
Sep 08 20:16:12 <nschle85> dos1: i would like to thank to if you could fix it, it will give back a lot of usability
Sep 08 20:16:20 <dos1> nschle85: ok
Sep 08 20:16:24 <nschle85> dos1: can you fix it for old oe dev too ?
Sep 08 20:16:31 <dos1> nschle85: in meantime you can just use default e theme
Sep 08 20:17:25 <nschle85> dos1: yes, but my intention is to have it fixed, i do not use shr on n900 in real life (its unusable)
Sep 08 20:17:45 <dos1> nschle85: ok ok, just telling you
Sep 08 20:18:10 <dos1> as fixing it shouldn't be hard, probably it's matter of changing few words in group description
Sep 08 20:18:44 <nschle85> dos1: no, i wont attack you, i am here to develop something (if shr will compile) not do do workarounds
Sep 08 20:20:35 <nschle85> dos1: can i create a ticke and assign to you ?
Sep 08 20:20:44 <dos1> nschle85: yes, of course
Sep 08 20:26:15 <nschle85> dos1: http://shr-project.org/trac/ticket/1482
Sep 08 20:26:26 <nschle85> dos1: thank you
Sep 08 20:32:15 <GNUtoo|laptop> TAsn, hi
Sep 08 20:32:30 <GNUtoo|laptop> TAsn, what's the state of http://www.shr-project.org/trac/ticket/1469
Sep 08 20:33:55 <TAsn> dunno
Sep 08 20:33:59 <TAsn> sec
Sep 08 20:34:30 <TAsn> dos1, you bastard! :P
Sep 08 20:34:42 <TAsn> dos1, I'm not that theme maintainer.
Sep 08 20:34:49 <dos1> hmm?
Sep 08 20:35:23 <TAsn> GNUtoo|laptop, I'm SUPER short on time in general, and especially this month. I won't be able to attend to it. I'll reassign it to dos.
Sep 08 20:35:45 <dos1> TAsn: hmm?
Sep 08 20:35:58 <dos1> TAsn: i haven't said anything about you :o
Sep 08 20:36:11 <TAsn> http://www.shr-project.org/trac/ticket/1469
Sep 08 20:36:12 <GNUtoo|laptop> btw what's the modules to load and install to get sound on om-gta02?
Sep 08 20:36:13 <TAsn> look here
Sep 08 20:36:47 <dos1> TAsn: it looks like you was automatically assigned due to component :P
Sep 08 20:37:01 <TAsn> ah. :)
Sep 08 20:37:13 <dos1> nschle85: i'll close your ticket as duplicate of #1469
Sep 08 20:38:11 <dos1> dos1: btw, i'm not that theme maintainer too :D
Sep 08 20:38:17 <dos1> but i'll do it anyway :]
Sep 08 20:39:18 <nschle85> dos1: i created a ticket, not a task
Sep 08 20:39:37 <dos1> nschle85: hmm?
Sep 08 20:39:58 <nschle85> dos1: you can close it if the original is fixed :-)
Sep 08 20:40:12 <dos1> nschle85: ah, just updated #1469 to have better description and to be a defect
Sep 08 20:40:48 <nschle85> dos1: ok, then its a duplicate :-)
Sep 08 20:40:57 <nschle85> and who will fix it ?
Sep 08 20:41:07 <[Rui]> hoha
Sep 08 20:42:21 <dos1|N900> nschle85, I will tommorow
Sep 08 20:43:04 <nschle85> dos1|N900: ok i see the ticket is assigned to you
Sep 08 20:43:07 <GNUtoo|laptop> dos1|N900, do you know how to fix sound on om-gta02?
Sep 08 20:43:21 <GNUtoo|laptop> hi mrmoku 
Sep 08 20:43:21 <GNUtoo|laptop> what modules should I load/install?
Sep 08 20:43:38 <dos1|N900> gnutoo, dunno :(
Sep 08 20:44:02 <GNUtoo|laptop> who knows?
Sep 08 21:17:50 <nschle85> JaMa|Off: before i delete my sanbox and build all again, do you have any idea how to fix my libpseudo problem ?
Sep 08 23:25:48 <[Rui]> gnight
Sep 09 02:42:17 <mrmoku> HOME SWEET HOME :-D
Sep 09 02:42:22 <mrmoku> and good night :P
**** ENDING LOGGING AT Fri Sep 09 02:59:57 2011