**** BEGIN LOGGING AT Sun Nov 08 02:59:56 2009
Nov 08 10:00:39 <spaetz> mrmoku|away, now that the image buiilds again. what about syncing it into shr-unstable?
Nov 08 10:01:05 <spaetz> i can write anannouncement text for ml/blog
Nov 08 10:02:17 <spaetz> i'd like to get initial testing and then branch off for -testing as quickly a possible (if nobody volunteers, i'll maintain that..)
Nov 08 10:09:06 <JaMa> spaetz: shouldn't we wait for successfull feed build? for -testing?
Nov 08 10:09:36 <JaMa> spaetz: +1 for shr-unstable if there is warning about reflash in announcement
Nov 08 10:19:48 <spaetz> JaMa, yes announcement is needed
Nov 08 10:20:38 <spaetz> JaMa, either  wait for -feed building for -testing image or start cherry picking fixes into -testing
Nov 08 10:21:07 <spaetz> i imagine -testing to be quite conservative...
Nov 08 10:21:24 <spaetz> and only take bug fixees
Nov 08 10:21:52 <spaetz> i really really wantt to get sth that we can ccall the first releasee ;-)
Nov 08 10:22:34 <spaetz> that'swhy i volunteer to be -testing maintainer if nobody else volunteers
Nov 08 10:23:51 <spaetz> our last unstable img is stii sep 6
Nov 08 10:23:54 <spaetz> still
Nov 08 10:30:00 <spaetz> cool , germany gave the kde founder a medal (http://www.pro-linux.de/news/2009/14923.html german)
Nov 08 10:32:13 <juri_>  ok, new simm card aquired..
Nov 08 10:32:34 <JaMa> spaetz: but we should start -testing from some well tested and usable state.. which is not in shr/merge now.. 
Nov 08 10:33:31 <spaetz> ' i'd like to get initial testing and then branch off for -testing as quickly a possible'
Nov 08 10:33:48 <spaetz> that's what i meant:
Nov 08 10:34:01 <spaetz> get -unstable shr/merge out
Nov 08 10:34:24 <spaetz> and bake that for 2-3weeks to iron out  the glitches
Nov 08 10:34:43 <spaetz> hen branch off that and stabilize from there
Nov 08 10:36:43 <JaMa> spaetz: if we start -testing now than I think that all patches to shr/merge would be needed in shr/testing too
Nov 08 10:37:26 <JaMa> spaetz: so you would need to merge every day or so.. and with first patch (not welcome in -testing) you would need to start cherry-picking all patches one-by-one
Nov 08 10:37:43 <CIA-86> freesmartphone.org: 03mickey 07cornucopia * rb5c5d0c3a778 10/fsogsmd/tests/testsms.vala: fsogsmd: testsms: fix uint8
Nov 08 10:37:48 <JaMa> ah after 2-3 weeks it seems reasonable..
Nov 08 10:39:43 <spaetz> yep, bake it first a bit, not branching now
Nov 08 10:39:48 * spaetz nods
Nov 08 10:40:15 <spaetz> hor however long it takes to stabilize what we have,a bit
Nov 08 10:43:11 * JaMa would like to push shr/merge stuff to oe.dev before new stable/2010 (no idea where its planned and if its just snapshot of oe.dev)
Nov 08 10:43:34 <JaMa> then we could base -testing on stable/2010 and -unstable on oe.dev
Nov 08 11:12:07 <Flyser> spaetz: the image builds again? where can I download that image? the mrmoku images seem outdated
Nov 08 11:17:42 <spaetz> locally. i don;t think its available on the buildhost yet. that's why i am pushing for getting one out...
Nov 08 11:18:08 <JaMa> PaulFertser: I guess that TOUCHSCREEN_S3C2410 should depend on S3C24XX_ADC, its just "!S390 && ARCH_S3C2410 && INPUT && INPUT_TOUCHSCREEN" now and fails to build without S3C24XX_ADC enabled
Nov 08 11:18:19 <JaMa> PaulFertser: I'll push patch for that to oe in few mins
Nov 08 11:18:39 <JaMa> spaetz: what about that tests/mrmoku/oemerge? ist from shr/merge and about 2 days old..
Nov 08 11:19:09 <spaetz> i don't know what is from where and how updated.
Nov 08 11:19:29 <spaetz> ok, so then that might be our release candidate
Nov 08 11:19:48 <JaMa> PaulFertser: or if you push it to om-2.6.31 than it would be nice..
Nov 08 11:20:19 <PaulFertser> JaMa: i prefer to leave modifying important stuff to larsc 
Nov 08 11:21:30 <JaMa> PaulFertser: http://jama.homelinux.org/org.openembedded.shr/linux-openmoko-2.6.31/0002-Kconfig-TOUCHSCREEN_S3C2410-depends-on-S3C24XX_ADC-a.patch http://jama.homelinux.org/org.openembedded.shr/linux-openmoko-2.6.31/0003-gta02_defconfig-update-config.patch
Nov 08 11:22:17 <JaMa> PaulFertser: take a look, it should be safe... but as you wish.. I can drop it later from oe repo
Nov 08 11:22:59 <JaMa> PaulFertser: there is also that workaround for gcc-4.4.2 with do_div but you probably dont accept it :)
Nov 08 11:28:42 <pbaxter> hello...which is the website of blipomoko???
Nov 08 11:54:12 * JaMa lunch
Nov 08 12:09:36 <spaetz> lunch too
Nov 08 12:43:54 <max_posedon> opkg upgrade works now 12 hours, looks like it slowest upgrade in my life
Nov 08 12:53:54 <pieterc> apt seen panicking
Nov 08 12:53:56 <apt> panicking <n=Michael@77.224.194.88> was last seen on IRC in channel #openmoko, 4d 16h 39m 39s ago, saying: 'yes but ask to the and2moko channel'.
Nov 08 12:55:22 <pieterc> eanyone tested my youtube app yet?
Nov 08 12:55:39 <pieterc> It works great when deleting the -zoom=0.5 argument
Nov 08 12:55:54 <pieterc> it's very slow with that argument... is that due glamo?
Nov 08 12:55:55 <rebelThor> youtube? on the FR ?
Nov 08 12:56:28 <pieterc> yes
Nov 08 12:56:35 <pieterc> moment, brb, changing from console to X
Nov 08 12:57:15 <pieterc> ok
Nov 08 12:57:26 <playya__> how can i fix the problem with matchbox-panel2?
Nov 08 12:57:49 <pieterc> http://code.google.com/p/oywl/ ==> check this
Nov 08 12:58:30 <pieterc> I want to create a gui for it
Nov 08 12:58:44 <pieterc> but I do still want the regexp power of perl
Nov 08 12:58:51 <pieterc> what programming language should i use?
Nov 08 12:58:59 <pieterc> Bash with GTK?
Nov 08 13:03:35 <playya__> vala :D
Nov 08 13:05:23 <dos1> elementary
Nov 08 13:05:24 <dos1> ;)
Nov 08 13:07:17 <pieterc> I won't have the perl power with vala
Nov 08 13:07:23 <pieterc> and elementary + what?
Nov 08 13:07:35 <pieterc> is there a bash way to use elementary
Nov 08 13:07:40 <pieterc> ?
Nov 08 13:10:12 <Sharwin_F> I think there exists something called shellementary or something similiar which is elm + sh
Nov 08 13:12:34 <pieterc> http://www.opkg.org/package_267.html ==> oh this is interesting indeed:)
Nov 08 13:35:37 <pieterc`> is there not a perl ellementary package?
Nov 08 13:35:48 <pieterc`> s/ellementary/elementary/
Nov 08 13:35:49 <apt> pieterc` meant: is there not a perl elementary package?
Nov 08 14:25:36 <playya__> gpgme changed the ckecksum
Nov 08 14:34:34 <playya__> at least bitbake shows an error
Nov 08 14:48:45 <BluesLee> does someone use evopedia here?
Nov 08 14:49:42 <richy> I used to
Nov 08 14:51:45 <CIA-86> freesmartphone.org: 03mickey 07cornucopia * r45b2bf888f5c 10/libfsobasics/ (3 files in 2 dirs): libfsobasics: add FileHandling.removeTree()
Nov 08 14:51:47 <BluesLee> richy: does gps work for you?
Nov 08 14:52:56 <BluesLee> richy: i mean, i cant see my osm maps within evopedia
Nov 08 14:54:27 <richy> BluesLee: I was able to see the map. However, as of now it just says: can't connect to host. Though I'll just wait and try again on upcoming unstable image
Nov 08 14:56:29 <BluesLee> richy: do u see  the map when you are online or offline?
Nov 08 14:57:34 <richy> offline
Nov 08 14:58:09 <richy> BluesLee: It uses cached TangoGPS-Tiles, afaik
Nov 08 15:01:02 <CIA-86> freesmartphone.org: 03mickey 07cornucopia * r2a33e5ffe96c 10/fsogsmd/src/lib/sms.vala: fsogsmd: implement SmsStorage.clear()
Nov 08 15:06:20 <pieterc`> does someone has a bash script to make an ipk file out of a dir structure?
Nov 08 15:06:32 <pieterc`> or how is it done normally? By hand?
Nov 08 15:11:49 <Zorkmn> http://www.bitsum.com/creating_ipk_packages.htm
Nov 08 15:15:54 <pieterc`> yep indeed Yorick, but I did not find the file he uses on that page :s
Nov 08 15:16:27 <pieterc`> (the make_ipk.sh - file)
Nov 08 15:16:47 <pieterc`> I guess i'll just edit an existing ipk by hand ...
Nov 08 15:17:31 <Zorkmn> I thought it was just a tarred file... (with that controll dirctory added)
Nov 08 15:18:39 <pieterc`> Yes it is, but it's quite some work when the tarred file should reffer to /usr/bin ...
Nov 08 15:18:55 <BluesLee> richy: that means that i have to start tangogps before?
Nov 08 15:19:05 <BluesLee> richy: okay, will try that
Nov 08 15:19:23 <Zorkmn> pieterc`: think it's always nescessary to create the same directory structure by hand..;
Nov 08 15:19:56 <pwgen> is the sim/pim and dial dialog ( enter numbers ) domwhere defined as widget or have i to code my own ?
Nov 08 15:20:20 <pwgen> s/domwhere/somewhere/
Nov 08 15:20:21 <apt> pwgen meant: is the sim/pim and dial dialog ( enter numbers ) somewhere defined as widget or have i to code my own ?
Nov 08 15:20:34 <richy> BluesLee: well, not everytime. Just start it once , download the part of the world you need and that should be it
Nov 08 15:22:48 <BluesLee> richy: i have all maps offline, i will start tangogps zoom around, and then evopedia
Nov 08 15:22:57 <BluesLee> richy: should it work without a gps fix?
Nov 08 15:24:52 <richy> I think so, but you might have to move around a "bit" to get to a place where there you have some map-data
Nov 08 15:24:55 <Zorkmn> BluesLee: it works withouth gps fix
Nov 08 15:25:25 <pieterc`> Zorkmn: normally there are some sh scripts doing that automatically... but no idea where to find those :)
Nov 08 15:25:59 <BluesLee> Zorkmn: doesnt work here, in some cases i see articles but no map
Nov 08 15:26:01 <Zorkmn> pieterc`: maybe post to the comm list? a lot of people must have them in that case...
Nov 08 15:27:22 <Zorkmn> BluesLee: i'm having a strange problem now also...zoomed out it works fine, but when zooming too much the maps aren't being displayed, altough I know I have it and can use it in tangogps..
Nov 08 15:27:35 <Zorkmn> oh wait, it was just slow :)
Nov 08 15:28:21 <BluesLee> Zorkmn: i use Evopedia version 0.2.3-r1 
Nov 08 15:29:37 <BluesLee> Zorkmn: okay,no idea why it doesnt work
Nov 08 15:29:47 <Zorkmn> i think i'm using the r2, not sure though, after navit is updated i'll tell you
Nov 08 15:37:57 <BluesLee> who is the author of evopedia?
Nov 08 15:41:33 <BluesLee> Zorkmn: i will return in some minutes
Nov 08 16:10:03 <bumbl> hmm could someone give me some git hand? i have a master branch locally and a remote git repository - i want to push the changes i did to the master branch but git tells me error: failed to push some refs to ...; googling tells me that i should git pull but the interesting thing is - i am the only one who works with this repo
Nov 08 16:10:28 <PaulFertser> bumbl: are you sure you can fast-forward the remote branch?
Nov 08 16:10:31 <bumbl> my local master branch has developed out of the remote master branch
Nov 08 16:11:00 <PaulFertser> bumbl: no history rewriting?
Nov 08 16:12:24 <bumbl> PaulFertser: hmm this might be it - i reverted a commit which was really stupid but i might have pushed it. - how to fix best?
Nov 08 16:13:06 <bumbl> (so that the stupid commit is removed from the "remote" repo [a folder.git inside my Dropbox])
Nov 08 16:14:38 <larsc> bumbl: if your are the only one using the repo force push it
Nov 08 16:14:46 <bumbl> ok
Nov 08 16:14:53 <bumbl> (yes i am the only one using it)
Nov 08 16:14:55 <PaulFertser> bumbl: if the remote branch wasn't used by anybody (except you) to develop on top, you just -f not-fastforward push.
Nov 08 16:17:19 <bumbl> PaulFertser: so git -f push remote will do? /me googles not-fastforward
Nov 08 16:17:25 <PaulFertser> bumbl: yep
Nov 08 16:17:30 <PaulFertser> bumbl: git push -f
Nov 08 16:19:21 <bumbl> thank you larsc and PaulFertser, you rock
Nov 08 16:20:24 * PaulFertser wished it was true that basic git knowledge would allow people to "rock"...
Nov 08 16:23:43 <sicu_> baby steps ;)
Nov 08 16:29:52 <JaMa> larsc: I guess that TOUCHSCREEN_S3C2410 should depend on S3C24XX_ADC, its just "!S390 && ARCH_S3C2410 && INPUT && INPUT_TOUCHSCREEN" now and fails to build without S3C24XX_ADC enabled
Nov 08 16:30:10 <JaMa> larsc: http://jama.homelinux.org/org.openembedded.shr/linux-openmoko-2.6.31/0002-Kconfig-TOUCHSCREEN_S3C2410-depends-on-S3C24XX_ADC-a.patch http://jama.homelinux.org/org.openembedded.shr/linux-openmoko-2.6.31/0003-gta02_defconfig-update-config.patch
Nov 08 16:30:26 <Weiss> woohoo! Working Glamo burst commands!
Nov 08 16:30:54 <JaMa> Weiss: congratz!
Nov 08 16:31:38 <Weiss> now I get to spend a few minutes figuring out exactly what wasn't right before
Nov 08 16:32:16 <PaulFertser> Weiss: amazing! you finally did it. Congrats! :D
Nov 08 16:33:34 <Weiss> (it didn't help that I'd added a goto which skipped over the actual submission part, but other stuff was going on as well)
Nov 08 16:33:47 <larsc> Weiss: :)
Nov 08 16:33:59 <Zorkmn> what is useful about glamo bursts? (just asking, don't know what you are talking about Weiss :))
Nov 08 16:34:47 <Weiss> Zorkmn: more efficient submission when sending large command sequences (e.g. 3D). also much less of a headache to program in that case
Nov 08 16:35:23 <Weiss> the datasheets are vague, but they suggest that 3D can *only* be programmed with bursts
Nov 08 16:43:12 <Weiss> hmm, nope - I think it was always just because I'm a muppet. I committed the code with the jump over the "active lines" over two weeks ago
Nov 08 17:08:37 <TAsn> Weiss, so does it, or doesn't it work? :)
Nov 08 17:09:49 <Weiss> it works
Nov 08 17:09:58 <TAsn> :)
Nov 08 17:10:01 <Weiss> the only reason it didn't was that I'd left a "goto" in
Nov 08 17:10:24 <TAsn> :)
Nov 08 17:10:56 <TAsn> that's why when I write hackish workaround I either use an #if 0 or tag it with /*FIXME: REMOVE THIS UGLY CRAP ASAP */ :)
Nov 08 17:11:00 * Weiss needs some kind of Git pre-commit script which detects muppetry
Nov 08 17:11:10 <Weiss> e.g. the line near the end of the first hunk of http://git.bitwiz.org.uk/?p=kernel.git;a=commitdiff;h=e05d2881be7db3f4e1a42440c809d3e18e406003
Nov 08 17:11:49 <JaMa> :)
Nov 08 17:12:27 <TAsn> Weiss, consider using a script that looks for a string (for instance "HACK") in the diff and alerts you before you commit ;)
Nov 08 17:12:32 <TAsn> ^
Nov 08 17:12:34 <TAsn> I'm not joking
Nov 08 17:12:35 <TAsn> :(
Nov 08 17:12:36 <TAsn> :)
Nov 08 17:13:12 <Weiss> hehe
Nov 08 17:13:29 <TAsn> that could prove itself useful actually :)
Nov 08 17:15:04 <TAsn> I kinda do the same manually
Nov 08 17:15:25 <TAsn> I write down in a list all of the hacks I do and I'm not willing to commit :)
Nov 08 17:15:41 <TAsn> and then fix them before committing :)
Nov 08 17:51:25 <JaMa> Heinervdm: fonts should be fixed now..
Nov 08 17:51:35 <JaMa> Heinervdm: thanks for hints
Nov 08 17:51:48 <Heinervdm> JaMa: nice :)
Nov 08 17:52:12 <mrmoku> dos1: some problem with sysvinit?
Nov 08 17:52:21 <dos1> mrmoku: hmm?
Nov 08 17:52:37 <dos1> mrmoku: ah, i left that directory on buildhost?
Nov 08 17:52:54 <mrmoku> yup :)
Nov 08 17:53:00 <dos1> mrmoku: no, i was only checking something, as i upgraded my image with shr/merge repositories
Nov 08 17:53:10 <dos1> mrmoku: and /sbin/shutdown.sysvinit was missing ;)
Nov 08 17:53:12 <mrmoku> soo.... we have a full image... a lite image... did you try one of them?
Nov 08 17:53:24 <dos1> i didn't
Nov 08 17:53:32 <dos1> but i announced it here, maybe someone else tried
Nov 08 17:53:33 <dos1> :P
Nov 08 17:53:36 <TAsn> mrmoku, what about
Nov 08 17:53:38 <mrmoku> dos1: well
Nov 08 17:53:40 <TAsn> an image? :)
Nov 08 17:53:42 <mrmoku> not possible
Nov 08 17:53:52 <max_posedon> dos1, upgrade from glibc branch is epic fail
Nov 08 17:53:52 <mrmoku> as it is not public
Nov 08 17:54:05 <TAsn> ciao. :|
Nov 08 17:54:17 <max_posedon> so, I deside flush eglibc image
Nov 08 17:54:23 <JaMa> Weiss: do you still have sigsegvs with KMS kernel?
Nov 08 17:54:32 <mrmoku> max_posedon: already did? or want to do?
Nov 08 17:54:39 <JaMa> Weiss: I just tested KMS kernel again and its the same here..
Nov 08 17:54:56 <max_posedon> already did
Nov 08 17:54:59 <mrmoku> ah, ok
Nov 08 17:55:24 <dos1> mrmoku: it's public
Nov 08 17:55:27 <max_posedon> btw, does new-message bug fixed?
Nov 08 17:55:30 <dos1> in tests/mrmoku/oemerge ;)
Nov 08 17:55:34 <mrmoku> dos1: no
Nov 08 17:55:37 <dos1> mrmoku: i changed symlinks
Nov 08 17:55:40 <mrmoku> ohh
Nov 08 17:55:44 <mrmoku> ok
Nov 08 17:55:45 <Weiss> JaMa: hmm.. which segvs?
Nov 08 17:55:48 <mrmoku> then it is ;)
Nov 08 17:56:08 <dos1> max_posedon: but i did that (upgrade from glibc)
Nov 08 17:56:15 <dos1> max_posedon: and guess what - it works :P
Nov 08 17:56:25 <max_posedon> missing shutdown?)
Nov 08 17:56:29 <dos1> max_posedon: fixed :P
Nov 08 17:56:34 <dos1> i can't recommend it to "typical user"
Nov 08 17:56:43 <JaMa> Weiss: http://shr.pastebin.com/m1fcb4621
Nov 08 17:56:49 <max_posedon> I got so many errors during upgrade
Nov 08 17:56:53 <max_posedon> fix all and the end
Nov 08 17:56:58 <dos1> but i fixed everything which was broken
Nov 08 17:57:02 <max_posedon> and after, my system was unbootable)
Nov 08 17:57:05 <dos1> and everything works, even phonefsod/phoneuid ;)
Nov 08 17:57:58 <JaMa> Weiss: but gdrm-gem-mmap         gdrm-kms-addfb works ok
Nov 08 17:58:39 <Weiss> JaMa: hmm.. did I/we/you ever work out why it had decided not to use KMS?
Nov 08 17:59:23 <Weiss> I knew already that non-KMS DDX on KMS DDX was a bit of a disaster area
Nov 08 17:59:31 <JaMa> Weiss: no but this started to happen after that log.output fix and then start failing after merge non-KMS and KMS DDX
Nov 08 18:00:30 <JaMa> I think that after this patch I never seen "Using KMS" :/ http://git.openmoko.org/?p=xf86-video-glamo.git;a=commitdiff;h=f9ad3d94703932c94182d5eac15c887e54133857
Nov 08 18:01:52 <Weiss> hmm... but that patch doesn't really do anything..?
Nov 08 18:02:30 <JaMa> Weiss: better backtrace http://shr.pastebin.ca/1662295
Nov 08 18:03:51 <Weiss> yep.. that's it breaking because it can't allocate offscreen memory (because the kernel hides it all behind GEM)
Nov 08 18:03:54 <BluesLee> Zorkmn: ping
Nov 08 18:04:12 <Weiss> JaMa: what's in /sys/bus/platform/devices/glamo-fb.0/ for you?
Nov 08 18:04:19 <alexxy> TAsn: mrmoku : please add reiserfsprogs to feed =)
Nov 08 18:04:51 <JaMa> Weiss: driver  drm  graphics  modalias  power  subsystem  uevent
Nov 08 18:06:25 <Weiss> interesting... you should have a drm:controlDnn (where nn=something)
Nov 08 18:06:43 <JaMa> Weiss: imho non-KMS DDX behave like this on KMS kernel before.. so maybe --enable-kms haven't enabled everything needed?
Nov 08 18:06:56 <dos1> alexxy: it's already added
Nov 08 18:06:58 <JaMa> Weiss: SHR root@gojama ~ $ ls /sys/bus/platform/devices/glamo-fb.0/drm/
Nov 08 18:06:58 <JaMa> card0  controlD64
Nov 08 18:07:05 <alexxy> dos1: not realy
Nov 08 18:07:21 <dos1> alexxy: well, we can't do anything with old repos without syncing
Nov 08 18:07:32 <dos1> it's in shr/merge repo, so it will be after sync
Nov 08 18:07:45 <dos1> so there's nothing more we can do (except faster syncing :P)
Nov 08 18:07:59 <Weiss> JaMa: the test for KMS-ability is really simple (just GlamoKernelModeSettingAvailable in glamo-kms-driver.c).. but for some reason, your kernel has a different sysfs layout
Nov 08 18:08:36 <alexxy> dos1: whats difference betwen http://build.shr-project.org/tests/mrmoku/unstable/feed/ and oemerge?
Nov 08 18:08:51 <dos1> alexxy: oemerge is based on shr/merge
Nov 08 18:09:01 <dos1> alexxy: unstable is based on shr/import
Nov 08 18:09:09 <alexxy> dos1: is it usable ? as phone i mean
Nov 08 18:09:10 <alexxy> ?
Nov 08 18:09:12 <dos1> and there is huge difference between packages and versions
Nov 08 18:09:12 <Weiss> JaMa: it can be fixed in xf86-video-glamo very easily.. but I'm interested about why it's happening..
Nov 08 18:09:27 <dos1> so upgrading will fail (which is fixable, but not for "typical user")
Nov 08 18:09:53 <alexxy> dos1: /me not realy a tipical user =)
Nov 08 18:10:01 <JaMa> Weiss: I updated kernel config a bit.. to sync it with andy-tracking.. but this shouldn't change sysfs layout..
Nov 08 18:10:04 <alexxy> so how i can fix upgrade?
Nov 08 18:10:40 <alexxy> dos1: so is it usable as phone?
Nov 08 18:10:44 <Weiss> JaMa: hmm.. we should compare kernel configs
Nov 08 18:10:44 <JaMa> Weiss: there is what is applied on top of drm-tracking now http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-shr-drm-devel?h=shr/merge
Nov 08 18:10:50 <dos1> alexxy: all i can say it's "here it works" :P
Nov 08 18:11:09 <alexxy> dos1: ok; then it'll work for me 
Nov 08 18:11:10 <alexxy> =)
Nov 08 18:11:31 <dos1> i had to workaround few things...
Nov 08 18:11:47 <dos1> firstly i upgraded opkg, and upgraded whole system with new opkg version
Nov 08 18:11:58 <dos1> and then i run just "opkg upgrade"
Nov 08 18:12:04 <Weiss> JaMa: hmm... do you have the kernel config exactly as it was used? then I can diff against mine
Nov 08 18:12:05 <dos1> then "opkg upgrade --force-overwrite"
Nov 08 18:12:19 <dos1> then looked at conflicting packages and fixed them
Nov 08 18:12:33 <JaMa> Weiss: sure.. mmt
Nov 08 18:12:37 <dos1> and then reinstalled sysvinit-utils, as something was broken and /sbin/shutdown.sysvinit was missing
Nov 08 18:12:57 <dos1> and then run "opkg upgrade" again, as some packages were failing to configure due to some runlevel problems
Nov 08 18:13:10 <JaMa> Weiss: http://jama.homelinux.org/org.openembedded.shr/config.gz
Nov 08 18:13:15 <spaetz> dos1, you never reflassh. do you? :-)
Nov 08 18:13:26 <dos1> and that was all - after that there were only typical problems with fsousaged etc. which i solved quickly :P
Nov 08 18:13:29 <dos1> spaetz: yup, almost :)
Nov 08 18:13:44 <dos1> i reflashed SHR about 3 times in about year :D
Nov 08 18:13:57 <JaMa> good score!
Nov 08 18:14:00 <spaetz> hehe
Nov 08 18:14:09 * JaMa reflashed SHR about 3 times in one day..
Nov 08 18:14:24 <spaetz> same here,jama
Nov 08 18:14:26 <dos1> and i was never forced to reflash - it was my choice, for instance to test something on fresh image
Nov 08 18:14:30 <dos1> ;)
Nov 08 18:14:33 <lindi-> dos1: whoa, I have only installed debian three times since summer 2008 :)
Nov 08 18:15:05 <lindi-> dos1: and once I did it purely just to test the installer
Nov 08 18:15:07 * JaMa wasn't forced either, but reflash rutine is automated here.. so its fast and easy :)
Nov 08 18:15:20 <dos1> my actual image is from "Fri, 17 Apr 2009, 18:19:28 +0200" ;D
Nov 08 18:15:29 <spaetz> manual here.. but still easy.
Nov 08 18:15:52 * mrmoku reflashes often to test images and upgrade paths...
Nov 08 18:15:59 <dos1> and i'm using FR as my daily phone ;)
Nov 08 18:16:05 <mrmoku> me too :P
Nov 08 18:16:12 <spaetz> so do i
Nov 08 18:16:14 <lindi-> mrmoku: shouldn't upgrades be testable without the actual device?
Nov 08 18:16:45 <mrmoku> lindi-: hmm... how?
Nov 08 18:17:15 <lindi-> mrmoku: in x86 chroot or armel qemu?
Nov 08 18:17:35 <spaetz> mrmoku, seen my previous comments? If nobody else volunteers, I cant take the shr/merge branch in a few  weeks and branch it offf for a -testing candidate
Nov 08 18:17:43 <mrmoku> you don't know then if GSM still works after upgrade... and if opkg complained due to OOM
Nov 08 18:17:44 <spaetz> I can...
Nov 08 18:17:56 <Weiss> JaMa: hmm.. I have CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2
Nov 08 18:17:56 <lindi-> mrmoku: debian uses piuparts ( package installation, upgrading, and removal testing tool )
Nov 08 18:18:29 <lindi-> mrmoku: it's done automatically for all packages
Nov 08 18:18:32 <dos1> mrmoku: new opkg from shr/merge looks quite stable
Nov 08 18:18:37 <mrmoku> lindi-: we don't have such a thing :(
Nov 08 18:18:40 <spaetz> consider that a grudging offer to be a -testing maintainer for the next -testing release
Nov 08 18:18:46 <mrmoku> anyway... have to read the good night story now
Nov 08 18:18:53 <mrmoku> bb after that :)
Nov 08 18:19:52 <dos1> spaetz: " I cant take the shr/merge branch " can't?
Nov 08 18:20:13 <dos1> or did you mean "can"? :)
Nov 08 18:22:00 <JaMa> Weiss: ok I'll try
Nov 08 18:22:35 <JaMa> PaulFertser: today tests of ubi are returning bad blocks.. maybe reason why it failed before.. see http://shr.pastebin.com/m6401109a
Nov 08 18:22:49 <JaMa> PaulFertser: someone else should try it and see if it works for him..
Nov 08 18:23:30 <JaMa> Weiss: IRC those two were removed for me with make oldconfig.. but can be reenabled in menuconfig..
Nov 08 18:24:16 <Weiss> probably xf86-video-glamo should just be fixed to take account of both situations
Nov 08 18:30:20 <JaMa> Weiss: sure if its the only problem
Nov 08 18:30:21 <spaetz> dos1, see my next line...
Nov 08 18:30:24 <spaetz> i can...
Nov 08 18:30:41 <JaMa> Weiss: rebuilding now..
Nov 08 18:32:54 <max_posedon> dos1, mrmoku/oemerge
Nov 08 18:32:56 <max_posedon> image works
Nov 08 18:33:07 <PaulFertser> JaMa: to me it looks like unrelated to the bad blocks
Nov 08 18:33:14 <max_posedon> after upgrade (I changed opkg settings to oemerge feed)
Nov 08 18:33:17 <max_posedon> it doesn't
Nov 08 18:33:30 <max_posedon> (framework doesn't start gsm)
Nov 08 18:34:06 <JaMa> PaulFertser: but that debug output says io errors about exactly the same PEBs as ubiformat before
Nov 08 18:34:11 <max_posedon> also, "lock" button have strange behavior
Nov 08 18:35:41 <PaulFertser> JaMa: but ubi should deal with bad blocks in a transparent way
Nov 08 18:36:37 <JaMa> Weiss: both SYSFS options are enabled in my config too.. strange
Nov 08 18:37:14 <Weiss> JaMa: hmm? they weren't in the config.gz..
Nov 08 18:38:40 <max_posedon> dos1, mrmoku|away JaMa , somebody!)
Nov 08 18:38:56 <sicu> max_posedon: i'm using that image too and was told to restart frameworkd manually after startup to get gsm back up, due to some race condition or other
Nov 08 18:39:08 <dos1> why anyone is using "lock" button?
Nov 08 18:39:10 <dos1> :x
Nov 08 18:39:16 <dos1> it never worked correctly ;p
Nov 08 18:39:27 <max_posedon> dos1, I mean "aux"
Nov 08 18:39:37 <dos1> max_posedon: oh
Nov 08 18:39:41 <dos1> max_posedon: what's wrong with aux?
Nov 08 18:39:45 <max_posedon> it shows lock screen
Nov 08 18:39:47 <max_posedon> cool!
Nov 08 18:39:55 <max_posedon> but also show [Lock] message
Nov 08 18:39:56 <max_posedon> bad
Nov 08 18:40:07 <dos1> max_posedon: just remove it in config
Nov 08 18:40:12 <max_posedon> and can be unlocked by aux, not my moving nice slider
Nov 08 18:40:12 <dos1> or rm -rf ~/.e
Nov 08 18:40:23 <max_posedon> dos1, its "fresh" e, I think
Nov 08 18:40:24 <max_posedon> but ok
Nov 08 18:40:25 <sicu> hmm, mine only shows that black centered stripe lock screen
Nov 08 18:40:48 <max_posedon> sicu, pure, but restarting framework doesn't helps..
Nov 08 18:41:16 <sicu> hmm, that worked here .. though i also had to enable gsm antenna in shr-settings
Nov 08 18:41:47 <dos1> 1047 commits to SHR and 346 commits to FSO... hmm, i'm good :D
Nov 08 18:41:57 <sicu> hehe =D
Nov 08 18:42:21 <TAsn> dos1, fixed the ophonekitd->phonefsod move?
Nov 08 18:42:22 <TAsn> :)
Nov 08 18:42:32 <dos1> TAsn: i'll do that in few days
Nov 08 18:42:46 <dos1> TAsn: if i won't, spank me :P
Nov 08 18:42:47 * TAsn used to like dos1, not anymore...
Nov 08 18:42:48 <TAsn> ;]
Nov 08 18:42:49 <TAsn> :)
Nov 08 18:43:21 <JaMa> hehe
Nov 08 18:43:21 <dos1> TAsn: well, if i won't be too tired on evening, i'll do that even today :P
Nov 08 18:43:40 <spaetz> TAsn, what movee?
Nov 08 18:43:42 <max_posedon> sicu, ok, works now, correct workaround
Nov 08 18:43:45 <spaetz> move?
Nov 08 18:43:53 <TAsn> spaetz, in shr-settings
Nov 08 18:43:57 <sicu> dos1: when i said yesterday that i'm seeing pixelation when using x11-16, that's mostly on buttons in various progs, like shr-settings for instance
Nov 08 18:44:01 <max_posedon> 1. stop phonefsod. 2. start frameworkd, 3. wait 4. start phonefsod
Nov 08 18:44:01 <TAsn> he still checks for ophonekitd
Nov 08 18:44:21 <TAsn> and still asks it for antenna iirc
Nov 08 18:44:46 <sicu> max_posedon: nice =]
Nov 08 18:44:52 <max_posedon> I don't understand why you want fix  ophonekitd->phonefsod move
Nov 08 18:45:05 <TAsn> max_posedon, huh?
Nov 08 18:45:10 <max_posedon> because glibc->eglibc is near impossible)
Nov 08 18:45:21 <max_posedon> so, users will flush images with phonefsod
Nov 08 18:45:36 <max_posedon> or I didn't understand smth little bit
Nov 08 18:46:12 <JaMa> max_posedon: you're too pesimistic.. you said impossible about thumb :)
Nov 08 18:48:06 <max_posedon> also, right now shr can't get correct timezone/time I think
Nov 08 18:48:11 <dos1> max_posedon: you're wrong ;p
Nov 08 18:48:24 <dos1> max_posedon: that change has to be done
Nov 08 18:48:43 <dos1> as shr-settings is still checking if ophonekitd is running and wants to connect to ophonekitd
Nov 08 18:48:50 <max_posedon> ah, ok
Nov 08 18:49:20 <TAsn> JaMa, ++ :)
Nov 08 18:49:43 <sicu> the alarm app in oemerge segfaults when trying to add an alarm
Nov 08 18:49:54 <TAsn> you guys conquered that thumb issue and proved nothing is impossible ;]
Nov 08 18:50:01 <TAsn> sicu, with what message/log?
Nov 08 18:50:11 <TAsn> what revision comparing to the import revision?
Nov 08 18:50:30 <TAsn> give me something to work with here ;]
Nov 08 18:50:37 <JaMa> ifs ffalarma? something said that before..
Nov 08 18:50:49 <JaMa> s/ffalarma/ffalarms/
Nov 08 18:50:50 <apt> JaMa meant: ifs ffalarms? something said that before..
Nov 08 18:51:35 <sicu> i think someone mentioned that being an issue the past few days, but thought i'd confirm it
Nov 08 18:52:02 <max_posedon> yes, same here, ffalarms segfaults
Nov 08 18:52:05 <sicu> TAsn: i'll check
Nov 08 18:53:10 <Weiss> JaMa: can't see anything else relevant in the diff between configs..
Nov 08 18:53:51 <JaMa> Weiss: I just rebooted.. let me check config.gz 
Nov 08 18:54:05 <dos1> about ffalarms - IIRC it's something easly fixable
Nov 08 18:54:09 <dos1> it was on maillist somewhere
Nov 08 18:54:12 <max_posedon> TAsn, ffalarms_0.3.1+svnr67-r0.4_armv4t.ipk
Nov 08 18:54:16 <JaMa> Weiss: it probably works.. I see Xorg..
Nov 08 18:54:52 <Weiss> I'm confident enough that that was the problem to have already committed (but not pushed) the fix :)
Nov 08 18:55:23 <JaMa> Weiss: yes DEPRECATED SYSFS options are now enabled.. 
Nov 08 18:55:45 <Weiss> and you have drm:controlDnn not inside a 'drm' folder?
Nov 08 18:56:14 <JaMa> yes bus  driver  drm:card0  drm:controlD64  graphics:fb0  modalias  power  subsystem  uevent
Nov 08 18:56:59 <JaMa> Weiss: please push your fix and I'll try to rebuild kernel to see if SYSFS options get lost again.. and then if it works without them :)
Nov 08 18:58:15 <Weiss> JaMa: done
Nov 08 18:58:31 * JaMa not sure what bitbake does with kernel config between workdir/defconfig (where its enabled) and workdir/git/.config (where it gets lost), but -c configure, -c menuconfig (reenable SYSFS), -c build works ok
Nov 08 18:59:47 <JaMa> lets test suspend/resume :)
Nov 08 19:00:32 <Weiss> WSOD still, probably, if you had it before
Nov 08 19:02:06 <JaMa> well yes.. http://shr.pastebin.ca/1662356 i can log in over ssh but display is only white even while testing gdrm-kms-addfb
Nov 08 19:03:21 <TAsn> I noticed the weirdest thing ever a couple of days back
Nov 08 19:03:28 <TAsn> all of a sudden the phone got REALLY slow
Nov 08 19:03:33 <TAsn> and even after a reboot
Nov 08 19:03:37 <TAsn> it was barely responsive
Nov 08 19:03:38 <TAsn> :|
Nov 08 19:07:27 <JaMa> Weiss: btw if you swap old and new location test in that file it will be a bit faster :)
Nov 08 19:08:06 <sicu> TAsn: and you didn't find the cause of it?
Nov 08 19:08:16 <Weiss> JaMa: about 0.001s? :)
Nov 08 19:08:21 <TAsn> sicu, unfortunately not.
Nov 08 19:08:27 <TAsn> I was at a concert (quite good actually)
Nov 08 19:08:32 <TAsn> and needed my phone urgently
Nov 08 19:08:44 <TAsn> so I rebooted again, (which fixed it)
Nov 08 19:08:54 <TAsn> and forgot about the logs.
Nov 08 19:09:08 <TAsn> though you reminded me about a ticket I wanted to open ;]
Nov 08 19:09:33 <sicu> well, i have to say that with oemerge and the gry theme, my FR feels anything but sluggish
Nov 08 19:10:43 <JaMa> Weiss: even less :)
Nov 08 19:10:49 <sicu> admittedly the image i ran before this was from 081123, so a reflash was in order ;p
Nov 08 19:11:36 <dos1> sicu: my image is from 080417 :>
Nov 08 19:15:20 <Weiss> JaMa: but it works?
Nov 08 19:16:39 <JaMa> Weiss: mmt
Nov 08 19:17:11 <TAsn> http://trac.shr-project.org/trac/ticket/700
Nov 08 19:17:14 <TAsn> weepee, I got 700 ;]
Nov 08 19:17:23 <max_posedon> 2009.11.08 21:16:50.41 odeviced.kernel26    ERROR    Can't read RTC alarm. Returning 0
Nov 08 19:17:36 <max_posedon> may be smth wrong with our kernel?
Nov 08 19:18:11 <max_posedon> (ffalarms still segfauls after rm -rf .e)
Nov 08 19:25:51 <sicu> dos1: yeh, but you've been upgrading ;p .. mine was left untouched for almost a year ;)
Nov 08 19:25:52 <JaMa> libfsobasics-0.8.2.0+gitr12+2a33e5ffe96c611e6a6b8b6c33d2a83ba656f55b-r0.0 do_compile error? anyone? http://pastebin.ca/1662379
Nov 08 19:26:25 <dos1> sicu: oh, 08 ;x mine is from 09, sorry ;D
Nov 08 19:26:43 <dos1> but i'm using it, so i'm still better! ;)
Nov 08 19:26:45 <dos1> :D
Nov 08 19:27:32 <TAsn> mine is pretty new
Nov 08 19:27:32 <JaMa> Weiss: f84cf6e1b0a6692e7e5a41b7133544265cefed49 fails
Nov 08 19:27:45 <TAsn> I sometimes do clean flashes to check for potential testing cands ;]
Nov 08 19:27:57 <sicu> hehe, true .. i didn't want to face the headache of starting to upgrade my old image
Nov 08 19:28:09 <JaMa> Weiss: (II) Not using KMS
Nov 08 19:29:34 <max_posedon> JaMa, vala-0.7.8?
Nov 08 19:29:36 <JaMa> Weiss: the name in drm subdirectory is different (without drm: prefix..)
Nov 08 19:29:41 <JaMa> max_posedon: yes
Nov 08 19:31:55 <Weiss> JaMa: ah, d'oh
Nov 08 19:33:01 <Weiss> JaMa: try now
Nov 08 19:36:11 <JaMa> Weiss: btw shouldn't it just switch to non-KMS DDX and ignore DRM enabled in kernel?
Nov 08 19:36:37 <JaMa> Weiss: or does old DDX depend on old kernel-FB driver?
Nov 08 19:38:34 <Weiss> JaMa: the latter - non-KMS can't handle not finding any VRAM to use for offscreen pixmaps
Nov 08 19:39:38 <JaMa> Weiss: ah ok.. and if I let old FB enabled as well as new one, it will eat some part of VRAM?
Nov 08 19:39:57 <JaMa> hmm failed again..
Nov 08 19:41:17 <JaMa> Weiss: I guess you should check only first 8 characters :) instead of 12
Nov 08 19:41:29 <Weiss> if you try to enable both glamo-fb and glamo-drm, it'll fall apart horribly
Nov 08 19:42:06 <Weiss> d'oh.. third time lucky..
Nov 08 19:42:53 <GNUtoo> hi,I've still no notices of alsa moderation so I do others things while waiting for that
Nov 08 19:42:58 <GNUtoo> so here's my question:
Nov 08 19:43:10 <GNUtoo> how do I make xfbdev support xrandr -o 1
Nov 08 19:43:21 <GNUtoo> s/xfbdev/fbdev for xorg
Nov 08 19:43:36 <PaulFertser> GNUtoo: (alsa moderation) use a decent MUA that doesn't break inline patches and post it inline.
Nov 08 19:43:44 <PaulFertser> GNUtoo: or use git send-email.
Nov 08 19:43:52 <GNUtoo> PaulFertser, I used git-send-email
Nov 08 19:44:09 <PaulFertser> GNUtoo: you had some error that needs to be fixed.
Nov 08 19:44:16 <PaulFertser> GNUtoo: but i didn't have a chance to talk to you about it.
Nov 08 19:44:46 <GNUtoo> PaulFertser, so I should re-post it inline or wait for the moderation aproval of the git send-email?
Nov 08 19:45:10 <GNUtoo> PaulFertser, "you had some error that needs to be fixed." is for alsa
Nov 08 19:45:11 <GNUtoo> ?
Nov 08 19:46:04 <PaulFertser> GNUtoo: i think you mentioned that git send-email didn't work for you at all so you attached the patch and now it's in the moderation queue.
Nov 08 19:46:19 <GNUtoo> yes
Nov 08 19:46:26 <GNUtoo> but
Nov 08 19:46:39 <GNUtoo> git-send-email didint' worked the first time
Nov 08 19:46:45 <GNUtoo> so I re-sent with git-send-email
Nov 08 19:46:48 <GNUtoo> and it worked
Nov 08 19:46:53 <GNUtoo> but ended up in moderation
Nov 08 19:46:58 <GNUtoo> because the patch was huge
Nov 08 19:49:16 <PaulFertser> GNUtoo: why is the patch huge? I guess it means there's something wrong with it then, no?
Nov 08 19:49:31 <GNUtoo> I'll look
Nov 08 19:50:20 <GNUtoo> 87K > 60k
Nov 08 19:50:26 <GNUtoo> the patch is 87k
Nov 08 19:50:33 <GNUtoo> the max size is 60k
Nov 08 19:50:45 <GNUtoo> if I remember well the max size
Nov 08 19:51:21 <PaulFertser> GNUtoo: well, why is the patch so huge? Probably it includes something not really needed to work. Because nobody's going to look through such a big patch.
Nov 08 19:51:59 <GNUtoo> maybe I should only keep the part for msm7k 
Nov 08 19:52:05 <GNUtoo> because there is a part for msm8k
Nov 08 19:59:05 <Weiss> JaMa: (fix for the fix for the fix pushed just after you mentioned it, by the way..)
Nov 08 19:59:26 <JaMa> mickey|away: ping
Nov 08 20:00:32 <JaMa> mickey|away: do we need something newer than upstream vala-0.7.8? libfsobasics-0.8.2.0+gitr12+2a33e5ffe96c611e6a6b8b6c33d2a83ba656f55b-r0.0 do_compile error? anyone? http://pastebin.ca/1662379
Nov 08 20:03:32 <TAsn> dos1, I can't get enough of the cool sliding animation you added to shr-today, thanks :)
Nov 08 20:15:14 <TAsn> opkg: (null): Bad address
Nov 08 20:15:14 <TAsn> opkg: (null): Bad address
Nov 08 20:15:20 <TAsn> sucksors.
Nov 08 20:19:09 <TAsn> who wrote the gry theme?
Nov 08 20:19:17 <TAsn> it's awesome except for one part.
Nov 08 20:19:54 <TAsn> the ***UGLY*** wrench and keyboard buttons :(
Nov 08 20:21:57 <JaMa> TAsn: Jesus
Nov 08 20:22:12 <TAsn> okie. ;)
Nov 08 20:22:20 <TAsn> thanks.
Nov 08 20:22:24 * JaMa should try it.. still with neo theme
Nov 08 20:23:53 <TAsn> it's awesome :)
Nov 08 20:27:31 <GNUtoo> PaulFertser, 56k now...but the problem is that everything is needed...and worse I didn't include the arch/arm/mach-msm/qdsp5
Nov 08 20:27:49 <GNUtoo> should I re-send it?
Nov 08 20:28:07 <PaulFertser> GNUtoo: make sure it's understandable and yes, then send it.
Nov 08 20:28:14 <GNUtoo> ok
Nov 08 20:28:18 <PaulFertser> GNUtoo: broonie seems to be quite sympathetic.
Nov 08 20:28:18 <GNUtoo> thanks
Nov 08 20:28:26 <PaulFertser> GNUtoo: do not forget to CC Pavel Machek.
Nov 08 20:28:35 <GNUtoo> ah yes I would have forgetten
Nov 08 20:28:44 <PaulFertser> GNUtoo: he's a big nitpicker but he might be interested to move this forward.
Nov 08 20:28:54 <GNUtoo> ok
Nov 08 20:31:20 <GNUtoo> PaulFertser, should I attach or inline it?
Nov 08 20:31:36 <GNUtoo> because the issue was only size
Nov 08 20:31:41 <GNUtoo> I bet attach
Nov 08 20:31:45 <PaulFertser> GNUtoo: inline if your client wouldn't mangle it.
Nov 08 20:31:55 <GNUtoo> my client is git-send-email
Nov 08 20:32:02 <sicu> is x11-16 going to be default in SHR?
Nov 08 20:32:41 <TAsn> sicu, depends on who you ask.
Nov 08 20:32:46 <TAsn> if you ask dos1, yeah.
Nov 08 20:32:51 <TAsn> if you ask me, no way.
Nov 08 20:32:55 <TAsn> if you ask phoneuid, no way.
Nov 08 20:33:03 <TAsn> so I think I outvoted dos1 :)
Nov 08 20:33:20 <dos1> if you ask shr-settings, yes
Nov 08 20:33:22 <sicu> well, judging by this commit i'd say yes ;p 0f973ce5a73b9f35055928434b4ba5967785e930
Nov 08 20:33:26 <dos1> if you ask shr-installer - yes ;D
Nov 08 20:33:51 <TAsn> sicu, where was that commit at?
Nov 08 20:33:52 <sicu> fight fight ;p
Nov 08 20:33:58 <TAsn> sicu, what repo?
Nov 08 20:34:06 <TAsn> dos1, I hope you didn't do that.
Nov 08 20:34:12 <TAsn> as I already told you, it breaks stuff.
Nov 08 20:34:18 <sicu> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=shr/merge&id=0f973ce5a73b9f35055928434b4ba5967785e930
Nov 08 20:34:39 <dos1> TAsn: that wasn't me ;p
Nov 08 20:34:59 <TAsn> JaMa, mind explaining what that is? :)
Nov 08 20:35:03 <sicu> but as far as making gry the default theme, i totally concur =D
Nov 08 20:35:33 <TAsn> sicu, same here, in the meanwhile, until it wins the theme contest. ;]
Nov 08 20:35:53 <TAsn> well, I think we should take the gry theme and merge our logo with it
Nov 08 20:35:55 <dos1> i don't like gry... elm_frames are ugly ;x
Nov 08 20:35:58 <TAsn> i.e use the logo instead of wrench
Nov 08 20:36:01 <TAsn> and stuff.
Nov 08 20:36:07 <TAsn> but using x11-16 is BAD>
Nov 08 20:36:11 <TAsn> an not really needed.
Nov 08 20:36:29 <dos1> and i'm for fixing phoneuid to work with x11-16 :>
Nov 08 20:37:02 <TAsn> JaMa, mind changing x11-16 to x11? no one voted for that. I can live with the gry theme, as it's not a use change, but changing is to x11-16 is bad. In other words, please revert.
Nov 08 20:37:04 <mrmoku> that is not going to happen... as there is nothing to fix
Nov 08 20:37:09 <TAsn> dos1, it's not phoneuid's fault.
Nov 08 20:37:11 <TAsn> exactly.
Nov 08 20:37:14 <dos1> i know
Nov 08 20:37:15 <spaetz> dos1, the gry frames aare ugly. but that's fixable...
Nov 08 20:37:15 <dos1> :P
Nov 08 20:37:16 <TAsn> mrmoku, you can revert that :)
Nov 08 20:37:24 <TAsn> mrmoku, just change to x11 :)
Nov 08 20:37:31 <dos1> just provoking ;D
Nov 08 20:37:33 <TAsn> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=shr/merge&id=0f973ce5a73b9f35055928434b4ba5967785e930
Nov 08 20:37:42 <dos1> and x11 even with gry theme is slow ;/
Nov 08 20:38:10 <TAsn> no it's not.
Nov 08 20:38:15 <TAsn> it's quite fast.
Nov 08 20:38:33 <sicu> it's a lot faster than default illume theme
Nov 08 20:38:36 <dos1> quite ;p
Nov 08 20:38:37 <max_posedon> oemerge haven't gry theme?!
Nov 08 20:39:02 <dos1> slow illume launcher is acceptable
Nov 08 20:39:13 <dos1> but slow scrolling in elementary apps isn't
Nov 08 20:39:16 <sicu> but fast is a relative term, we are after all speaking about the FR ;p
Nov 08 20:39:17 <dos1> it's too slow even with x11-16
Nov 08 20:39:21 <dos1> ;P
Nov 08 20:39:35 <TAsn> nah.
Nov 08 20:39:40 <JaMa> TAsn: revert to X11 sure.. somebody said that it should be also set.. maybe dos1? :P
Nov 08 20:39:45 <max_posedon> dos1, btw, does shr-contacts can show some custom image per-contact?
Nov 08 20:39:46 <sicu> max_posedon: nope, the commit came after the last image
Nov 08 20:39:48 <TAsn> JaMa, probably dos.
Nov 08 20:39:56 <TAsn> but that's bad, and even worst, was not voted for :)
Nov 08 20:40:03 <dos1> i didn't say anything like that
Nov 08 20:40:04 <dos1> ;P
Nov 08 20:40:20 <dos1> JaMa just asked me if ELM_ENGINE has to be set in this file
Nov 08 20:40:22 <max_posedon> dos1, e.g. I'm interesting how to change it, if its possible)
Nov 08 20:40:26 <dos1> and i answered "yes" ;P
Nov 08 20:40:28 <dos1> max_posedon: dunno
Nov 08 20:40:38 <TAsn> JaMa, don't worry I know it's not your fault, but dos1's. :)
Nov 08 20:40:41 <dos1> max_posedon: probably not yet
Nov 08 20:40:52 <TAsn> max_posedon, it can.
Nov 08 20:40:57 <TAsn> iirc.
Nov 08 20:41:01 <dos1> how?
Nov 08 20:41:09 <TAsn> there's an opimd field
Nov 08 20:41:10 <max_posedon> nice, what I should to do?)
Nov 08 20:41:13 <dos1> what data it suppose from opimd?
Nov 08 20:41:16 <TAsn> mrmoku, what's the opimd field?
Nov 08 20:41:23 <TAsn> dos1, filename
Nov 08 20:41:27 <dos1> as there is no "standard" yet :p
Nov 08 20:41:47 <TAsn> dos1, there won't be before you fix it according to opimd_redesign :)
Nov 08 20:41:54 * JaMa won't touch that file again.. :)
Nov 08 20:41:57 <TAsn> standard ^
Nov 08 20:42:00 <TAsn> JaMa, hehe, :)
Nov 08 20:42:03 <spaetz> heheh
Nov 08 20:42:19 <TAsn> mrmoku, field name?
Nov 08 20:42:30 <mrmoku> max_posedon: Photo
Nov 08 20:42:40 <TAsn> mrmoku, with file:// prefix or not?
Nov 08 20:42:47 <mrmoku> does not matter ;)
Nov 08 20:42:48 <max_posedon> ok, there I put filename with  full path? or in which form
Nov 08 20:42:53 <spaetz> JaMa, nvm, yay for gry
Nov 08 20:43:00 <TAsn> max_posedon, full path.
Nov 08 20:43:09 <mrmoku> max_posedon: full path... like /media/card/fotos/foo/bar.png
Nov 08 20:43:19 <spaetz> but i concur  with dos, the frames are ugly
Nov 08 20:43:50 <JaMa> lets take Jesus to ring too
Nov 08 20:44:37 <JaMa> mabye he can improve frames to make everybody happy :)
Nov 08 20:45:33 <spaetz> yep
Nov 08 20:47:18 <JaMa> so what about that x11/x11_16 fight?
Nov 08 20:48:06 * JaMa doesn't care, every x11* is good :)
Nov 08 20:48:17 <mrmoku> JaMa: well... unfortunately it isn't ;)
Nov 08 20:48:28 <max_posedon> mrmoku, It supported with any(default?) opimd backend?
Nov 08 20:48:35 <mrmoku> I agree with dos1 that x11-16 is significantly faster
Nov 08 20:48:41 <mrmoku> max_posedon: well... with SIM not
Nov 08 20:48:43 <spaetz> x11-16 is faster but broken according to upstream (aka rraster)
Nov 08 20:48:43 * JaMa ment good enough for me
Nov 08 20:48:58 <mrmoku> max_posedon: but default is new contacts go to SQLite
Nov 08 20:49:02 <TAsn> spaetz, and downstream
Nov 08 20:49:04 <TAsn> aka tasn and mrmoku 
Nov 08 20:49:10 <spaetz> hehe
Nov 08 20:49:13 <TAsn> mrmoku, what about the image?
Nov 08 20:49:15 <mrmoku> max_posedon: sorry for not thinking about mentioning that
Nov 08 20:49:18 <JaMa> im using x11 for long.. and haven't seen something terribly broken.. (with neo theme also from Jesus..)
Nov 08 20:49:24 <JaMa> ah!
Nov 08 20:49:27 <JaMa> im using x11_16 for long.. and haven't seen something terribly broken.. (with neo theme also from Jesus..)
Nov 08 20:49:30 <PaulFertser> GNUtoo: the patch is ok :)
Nov 08 20:49:42 <dos1> x11-16 isn't broken
Nov 08 20:49:43 <GNUtoo> ok
Nov 08 20:49:44 <GNUtoo> thanks
Nov 08 20:49:46 <GNUtoo> a lot
Nov 08 20:49:51 <dos1> it's just not complete and not maintained
Nov 08 20:49:53 <mrmoku> TAsn: what image?
Nov 08 20:50:01 <max_posedon> so, what workflow I should follow, for add a photo to contact, when contact on sim now
Nov 08 20:50:05 <dos1> but that's what we need
Nov 08 20:50:11 <max_posedon> delete, new?
Nov 08 20:50:12 <mrmoku> dos1: yup... that's the problem - want to maintain it? :P
Nov 08 20:50:16 <TAsn> mrmoku, shr image..
Nov 08 20:50:18 <dos1> someone should work on it... ;x
Nov 08 20:50:25 <dos1> maybe cofundos project? :D
Nov 08 20:50:40 <mrmoku> max_posedon: no idea what is the most elegant way...
Nov 08 20:50:45 <mrmoku> maybe pisi can help?
Nov 08 20:50:47 <TAsn> dos1, I'm not paying a dime for that broken thing... :)
Nov 08 20:51:10 <TAsn> though raster said there are ways to amazingly speed up x11-32
Nov 08 20:51:15 <TAsn> we should just ask him.
Nov 08 20:51:35 <max_posedon> ok, looks like I'll just postpone this idea may be
Nov 08 20:51:44 <dos1> we *NEED* x11-16. that's just raster (and rest of world) who doesn't need it at all  :P
Nov 08 20:52:00 <sicu> using x11-16 the buttons in shr-settings become 'nicely' pixelated ... this happens to you guys too, right?
Nov 08 20:52:01 <dos1> but we need complete and maintained x11-16
Nov 08 20:52:03 <mrmoku> dos1: is there some elegant way to transfer SIM to SQLite?
Nov 08 20:52:09 <dos1> and it's unlikely to happen ;P
Nov 08 20:52:20 <dos1> mrmoku: i think pisi is the most elegant ATM
Nov 08 20:52:33 <dos1> mrmoku: but i want to support copying between backends in opimd later
Nov 08 20:52:56 <dos1> sicu: it's just because smooth scrolling is not allowed when using x11-16
Nov 08 20:53:09 <dos1> but with gry theme nothing should be pixelated.
Nov 08 20:53:12 <max_posedon> may be pisi should be added to feeds?
Nov 08 20:53:23 <mrmoku> max_posedon: it is in the feeds
Nov 08 20:53:24 <PaulFertser> GNUtoo: it's a little bit (to say the least) unclear that your patch is to get alsa for the HTC Dream working.
Nov 08 20:53:24 <dos1> max_posedon: it isn't? for sure it was
Nov 08 20:53:46 <max_posedon> cat list | grep pisi | wc -l => 0
Nov 08 20:54:33 <GNUtoo> ok
Nov 08 20:54:59 <TAsn> dos1, raster said
Nov 08 20:55:02 <max_posedon> (mrmoku/oermerge feeds)
Nov 08 20:55:14 <TAsn> that there's a way to do it fast with x11-32
Nov 08 20:55:19 <PaulFertser> GNUtoo: i wonder what makes it hard for you to collaborate with the guys who wrote the code.
Nov 08 20:55:20 <mrmoku> root@om-gta02 ~ $ opkg list | grep pisi
Nov 08 20:55:20 <mrmoku> pisi - 0.4.7-r0.4 - PISI is synchronizing information
Nov 08 20:55:24 <TAsn> no need for x11-16
Nov 08 20:55:25 <dos1> TAsn: i know
Nov 08 20:55:26 <sicu> dos1: then something must've gone wrong here then, as shr-settings looks like it's gone through a pixel blender even when using gry ;p
Nov 08 20:55:57 <max_posedon> mrmoku, which feed you use?
Nov 08 20:56:06 <dos1> TAsn: and i think you got him wrongly
Nov 08 20:56:08 <JaMa> Weiss: strange.. but it still fails...
Nov 08 20:56:08 <mrmoku> tests/mrmoku/oemerge
Nov 08 20:56:11 <TAsn> max_posedon, in other words
Nov 08 20:56:14 <TAsn> drop it :)
Nov 08 20:56:20 <TAsn> it'll be there when the image arrives
Nov 08 20:56:26 <TAsn> no need to worry about it atm.
Nov 08 20:56:28 <spaetz> 16 wiil always be  faster than 32 (if maintained...) :-)
Nov 08 20:56:41 <TAsn> duh.
Nov 08 20:56:44 <Weiss> JaMa: :S
Nov 08 20:56:44 <GNUtoo> PaulFertser, should I try...I bet they don't want to collaborate because of their vision of the "open source"
Nov 08 20:57:10 <PaulFertser> GNUtoo: what is Aurora forum?
Nov 08 20:57:11 <dos1> TAsn: i understand him like "32-bit engine could be faster than actual implementation of x11"
Nov 08 20:57:29 <TAsn> dos1, I think he meant
Nov 08 20:57:29 <GNUtoo> PaulFertser, yes it's them
Nov 08 20:57:29 <max_posedon> TAsn, ok)
Nov 08 20:57:34 <GNUtoo> PaulFertser, qualcomm
Nov 08 20:57:48 <PaulFertser> GNUtoo: but you can try nevertheless. We have an idiom (it rhymes) here: an attempt is not a torture.
Nov 08 20:57:53 <TAsn> "You can change stuff to make x11-32 faster"
Nov 08 20:58:00 <GNUtoo> ok thanks
Nov 08 20:58:05 <dos1> TAsn: yup. theme. but that's not enough.
Nov 08 20:58:08 <TAsn> i.e drop smoothing
Nov 08 20:58:21 <Flyser_> does xf86-video-glamo support EXA acceleration? if so, you could use the xrender backend (if that is maintained)
Nov 08 20:58:57 <dos1> TAsn: gry theme (AFAIK) doesn't use images at all, so there is no smoothing ;p
Nov 08 20:58:58 <Weiss> JaMa: what's inside that "drm" folder for you? (I guess you're using the non-deprecated sysfs now?)
Nov 08 20:59:05 <TAsn> dos1, :)
Nov 08 20:59:12 <TAsn> that was just an example ffs.
Nov 08 20:59:21 <Weiss> Flyser_: yep, but not composite
Nov 08 20:59:33 <dos1> TAsn: i was watching what he was saying
Nov 08 20:59:40 <Flyser_> no need for composite ...
Nov 08 20:59:42 <TAsn> we'll just wait for him. :)
Nov 08 21:00:18 <dos1> TAsn: look at x11+gry at your neo. you won't get anything faster than it is with x11 engine
Nov 08 21:00:26 <JaMa> Weiss: http://pastebin.ca/1662498
Nov 08 21:00:30 <TAsn> dos1, maybe.
Nov 08 21:00:43 <dos1> TAsn: you can with x11-16, but it's completely unmaitained and was created as hack.
Nov 08 21:00:54 <TAsn> :)
Nov 08 21:00:56 <dos1> TAsn: that's what he was saying (and how i understood that)
Nov 08 21:01:02 <TAsn> dos1, I bet hacking down x11-32 
Nov 08 21:01:09 <TAsn> shouldn't be *that* hard.
Nov 08 21:01:36 <dos1> TAsn: if it wouldn't be hard, then it would be already done...
Nov 08 21:01:42 <dos1> as e is meant to be higly optimised
Nov 08 21:01:42 <TAsn> i disagree.
Nov 08 21:01:55 <TAsn> I think no one cared enough.
Nov 08 21:02:06 <TAsn> I'll take a look at it sometime when I'll have time
Nov 08 21:02:24 <TAsn> I worked with both the x11 and x11-16 engines quite a lot
Nov 08 21:02:29 <TAsn> a couple of months ago
Nov 08 21:02:35 <sicu> i want x11-64
Nov 08 21:02:39 <TAsn> sicu, ;]
Nov 08 21:02:39 <dos1> TAsn: raster was mentioning also more caches on his TODO list
Nov 08 21:02:49 <dos1> TAsn: maybe that's what you think? :P
Nov 08 21:02:54 <TAsn> no.
Nov 08 21:02:54 <dos1> but it'll make both engines faster ;p
Nov 08 21:03:08 <TAsn> I just don't think it should be that hard.
Nov 08 21:03:15 <Weiss> JaMa: hmmm.
Nov 08 21:03:23 <TAsn> it's just taking the 32 engine and making it uglier
Nov 08 21:03:24 <TAsn> ;]
Nov 08 21:03:32 <TAsn> I don't think it can be that hard.
Nov 08 21:03:36 <Flyser_> anyone ever tried the xrender backend? It could actually speed things up a bit, as it will use less bandwith
Nov 08 21:03:43 <Weiss> JaMa: oh, I see..
Nov 08 21:03:51 <TAsn> (uglier = smaller values for colors, less calcs)
Nov 08 21:04:39 <Weiss> JaMa: try now..
Nov 08 21:05:43 <dos1> TAsn: raster already told you
Nov 08 21:05:49 <TAsn> told me what?
Nov 08 21:05:54 <TAsn> (I don't think I recall)
Nov 08 21:06:10 <dos1> TAsn: that it's completelly different logic for calculations in different color modes
Nov 08 21:06:27 <Weiss> Flyser_: composite (=xrender) isn't accelerated..
Nov 08 21:06:44 <TAsn> dos1, I'll take a look at that (the logic)
Nov 08 21:06:47 <dos1> that's why x11-16 is incomplete, as it's not just "take x11-32, reduce colors and disable smooth scrolling"
Nov 08 21:06:53 <TAsn> :)
Nov 08 21:07:02 <dos1> s/scrolling/scaling/
Nov 08 21:07:02 <apt> dos1 meant: that's why x11-16 is incomplete, as it's not just "take x11-32, reduce colors and disable smooth scaling"
Nov 08 21:07:22 <dos1> but anyway
Nov 08 21:07:24 <Flyser_> Weiss: do you mean compositing in terms of a compositing window manager?
Nov 08 21:07:29 <dos1> i'm off :P
Nov 08 21:07:56 <sicu> and they won't complete it either i guess, as most hw will run x11-32 like a dream
Nov 08 21:07:57 <dos1> Flyser_: xrender is slowing things down with glamo
Nov 08 21:08:11 <dos1> sicu: that's what i say
Nov 08 21:08:20 <Flyser_> is this still true for the latest xf86-video-glamo?
Nov 08 21:08:26 <dos1> BUT gta02 doesn't run x11-32 like a dream ;P
Nov 08 21:08:38 <dos1> Flyser_: how could it change?
Nov 08 21:08:40 <sicu> hehe, i'm well aware of that ;p
Nov 08 21:08:58 <dos1> sicu: yup, that was more to TAsn :P
Nov 08 21:09:01 <Weiss> Flyser_: yep, both that AND xrender (accelerated Porter-Duff blending)
Nov 08 21:09:08 <Flyser_> dos1: recent improvements in the xserver or due to Weiss' work
Nov 08 21:09:15 <dos1> we need x11-16, but noone more needs x11-16
Nov 08 21:09:19 <Flyser_> Weiss: oh, I see :-(
Nov 08 21:09:43 <dos1> Flyser_: well, it won't make everything fast as dream :P
Nov 08 21:09:44 <JaMa> Weiss: better :)
Nov 08 21:09:51 <Flyser_> of course not^^
Nov 08 21:10:02 <dos1> as Xglamo was already accelerated
Nov 08 21:10:05 <TAsn> Weiss, do you think improving the glamo driver will make it a lot faster with x11-32?
Nov 08 21:10:06 <Flyser_> just as x11-16 wont
Nov 08 21:10:52 <sicu> well, at least i can dream about it being fast, no one can take that away from me ;p
Nov 08 21:10:54 <dos1> TAsn: (i would answer "No", but you asked him, not me :P)
Nov 08 21:11:06 <TAsn> :)
Nov 08 21:11:22 <dos1> ok, good night!
Nov 08 21:11:26 <Weiss> possibly we could accelerate xrender, at least for the 16-bit surfaces we have, but I haven't looked properly at that part of the datasheet and maybe there's some reason we can't
Nov 08 21:11:33 <dos1> and don't dreem about e17 engines
Nov 08 21:11:33 <sicu> g'nite dos1 =]
Nov 08 21:11:39 <dos1> there are much better things to dream ;D
Nov 08 21:11:45 <dos1> s/dreem/dream/
Nov 08 21:12:00 <Flyser_> Weiss: do you plan to add Xrender acceleration in the future or is that impossible on this hw?
Nov 08 21:12:05 <Weiss> TAsn: what I'm working on is about providing an interface for when programs want to use more advanced acceleration, e.g. OpenGL or MPEG
Nov 08 21:12:18 <TAsn> i c.
Nov 08 21:12:20 <TAsn> :)
Nov 08 21:12:40 <TAsn> but maybe
Nov 08 21:12:49 <TAsn> we'll be able to use the opengl engine
Nov 08 21:12:58 <TAsn> would that be faster?
Nov 08 21:12:58 <Weiss> i.e. allowing you to selectively bypass the X server for that kind of thing (that's what the "Direct" in "direct rendering" is about)
Nov 08 21:13:03 <dos1> TAsn: no
Nov 08 21:13:07 <TAsn> :|
Nov 08 21:13:08 <dos1> TAsn: only with QVGA :P
Nov 08 21:13:14 <TAsn> dos1, why?
Nov 08 21:13:17 <dos1> TAsn: with VGA you can't use opengl with glamo at all
Nov 08 21:13:21 <dos1> as texture size is limited
Nov 08 21:13:25 <TAsn> sucksors :|
Nov 08 21:13:26 <Weiss> indeed
Nov 08 21:13:26 <dos1> to something around 500x500 IIRC
Nov 08 21:13:35 <sicu> yay, bring on the QVGA fight next
Nov 08 21:13:47 <dos1> (and i don't want QVGA. NO NO NO!)
Nov 08 21:13:48 <sicu> it's at least been a couple of days since last time ^^
Nov 08 21:13:51 <Flyser_> is it possible to use the full VGA resolution and have a QVGA window with acceleration?
Nov 08 21:13:51 <Weiss> and probably the OpenGL engine assumes that everything can be accelerated (just like the other engines, I think)
Nov 08 21:14:05 <Weiss> Flyser_: yep
Nov 08 21:14:11 <mrmoku> max_posedon: copying my contacts from SIM to SQLite right now... with pisi
Nov 08 21:14:26 <Weiss> Flyser_: (in fact, you can experience that already. although the only part of OpenGL which works so far is glClear())
Nov 08 21:14:35 <Flyser_> :-)
Nov 08 21:14:38 <max_posedon> mrmoku, nice for you, but *my* mrmoku/oemerge feeds havent's pisi)
Nov 08 21:14:56 <mrmoku> max_posedon: opkg update?
Nov 08 21:15:07 <max_posedon> just did, same
Nov 08 21:15:14 <mrmoku> max_posedon: where do your feed files point to exactly?
Nov 08 21:15:26 <max_posedon> http://pastebin.ca/1662523
Nov 08 21:15:27 <sicu> max_posedon: http://build.shr-project.org/tests/mrmoku/oemerge/feed/all/
Nov 08 21:15:47 <max_posedon> ah, get now
Nov 08 21:15:52 <JaMa> Weiss: btw I start reading about vdpau, seems easier to maintain than -vo glamo patches for mplayer :)
Nov 08 21:16:06 <mrmoku> max_posedon: opkg update ... not upgrade
Nov 08 21:16:16 <max_posedon> all feed was currepted
Nov 08 21:16:23 <sicu> ;)
Nov 08 21:16:53 <mrmoku> JaMa: what do we do with dbus?
Nov 08 21:17:14 <Flyser_> vdpau would be damn cool on the freerunner :-)
Nov 08 21:17:18 <Weiss> JaMa: indeed... there's also libva, but I think more people favour vdpau at the moment
Nov 08 21:17:55 <mrmoku> hmm... how does one disable SIM contacts in opimd?
Nov 08 21:17:56 <Flyser_> And support for that is already present in the upstream mplayer
Nov 08 21:18:04 <Weiss> I have my work cut out for me with OpenGL, but if anyone wants to attempt a DRI-based VDPAU/libVA driver, the infrastructure for it is already there
Nov 08 21:18:12 <sicu> sigh, my gf bought an iPhone, just to annoy me
Nov 08 21:18:17 <sicu> it worked :/
Nov 08 21:18:32 <mrmoku> sicu: kick her ;)
Nov 08 21:18:53 <sicu> hehe, i think that's what caused her to buy one in the first place ;p
Nov 08 21:24:09 <alexxy> mrmoku: TAsn : i get http://dpaste.com/117927/ 
Nov 08 21:24:29 <alexxy> when i tryed to upgrade from tests/mrmoku/unstable to oemerge
Nov 08 21:24:30 <alexxy> =)
Nov 08 21:24:43 <max_posedon> alexxy, I losed 1 day
Nov 08 21:24:57 <max_posedon> after fixing all issues, I got unbootable image
Nov 08 21:25:00 <TAsn> no idea atm, sorry :|
Nov 08 21:25:06 <max_posedon> but as for this issue
Nov 08 21:25:07 <max_posedon> open
Nov 08 21:25:10 <max_posedon> vim /usr/sbin/update-rc.d
Nov 08 21:25:12 <alexxy> so seems better to reflash image
Nov 08 21:25:13 <alexxy> =)
Nov 08 21:25:19 <max_posedon> comment 173 line, and uncomment 172
Nov 08 21:25:34 <max_posedon> but belive me, it useless try to do such feed change
Nov 08 21:25:35 <TAsn> it's probably best not to test upgrade paths when they are not supported :)
Nov 08 21:26:57 <alexxy> well but upgrade works
Nov 08 21:27:08 <alexxy> if you resolve all deps and collisions
Nov 08 21:27:23 <TAsn> but there's no use checking that
Nov 08 21:27:27 <TAsn> as we don't care about that ;)
Nov 08 21:27:40 <TAsn> especially since upgrade doesn't move you from libframeworkd-phonegui-efl to libphone-ui-shr
Nov 08 21:27:43 <TAsn> and such.
Nov 08 21:29:15 <JaMa> Flyser_: vdpau_glamo.so would be 2nd api consumer I think.. it would be topic for /. :)
Nov 08 21:30:17 <JaMa> Flyser_: but with my wide radius of interests.. and speed and experience.. I'll have something done a week after Hurd-1.0 release...
Nov 08 21:32:08 <JaMa> mrmoku: what's wrong with that? someone confirmed that there is no fso issue with dbus_1.2.3?
Nov 08 21:34:22 <mrmoku> JaMa: don't think so... but someone should
Nov 08 21:34:47 <mrmoku> JaMa: another thing I have is:
Nov 08 21:34:47 <mrmoku> [21474631.615000] EXT3-fs error (device mmcblk0p2): ext3_dx_find_entry: bad entry in directory #26771: rec_len is too small for name_len - offset=16492, inode=27111, rec_len=28, name_len=126
Nov 08 21:34:52 <mrmoku> and lots of them
Nov 08 21:35:05 <mrmoku> after fresh install on SD and *after* first reboot
Nov 08 21:35:17 * JaMa would like to pay more attention to his daywork in next week as deadline is near and that stuff is so booring.. :)
Nov 08 21:35:30 <mrmoku> JaMa: hehe, yeah
Nov 08 21:35:44 <mrmoku> actually I do not even want *you* to try it :)
Nov 08 21:35:55 <mrmoku> just someone... might be even me :P
Nov 08 21:35:58 <JaMa> mrmoku: havn't seen any ext3 error in my log..
Nov 08 21:36:09 <JaMa> mrmoku: did you format your partition?
Nov 08 21:36:17 <mrmoku> JaMa: yep 
Nov 08 21:36:27 <JaMa> I probably did but from older shr-u
Nov 08 21:36:48 <JaMa> mrmoku: what about trying fsck?
Nov 08 21:37:00 <mrmoku> yeah, will do that
Nov 08 21:37:06 <mrmoku> and see if they come back afterwards
Nov 08 21:37:13 <mrmoku> but they were not there on first boot
Nov 08 21:38:09 <max_posedon> mrmoku, pisi for me export all contacts without phone numbers
Nov 08 21:38:32 <mrmoku> max_posedon: yeah, it exports the phone numbers as 'Cell phone' field
Nov 08 21:38:53 <mrmoku> and somehow we don't look at that... probably because of the missing capital P
Nov 08 21:38:56 * mrmoku checks
Nov 08 21:39:47 <sicu> what format does pisi export to?
Nov 08 21:40:06 <max_posedon> ok, but what field you want?
Nov 08 21:40:09 <mrmoku> yup
Nov 08 21:40:18 <max_posedon> Phone?
Nov 08 21:40:18 <mrmoku> max_posedon: anything with Phone in it
Nov 08 21:40:26 <mrmoku> so Cell Phone would be fine
Nov 08 21:40:30 <mrmoku> but Cell phone not so :|
Nov 08 21:41:34 <max_posedon> update contact_values SET Field = 'Phone' where Field = 'Cell phone';
Nov 08 21:42:10 <mrmoku> that would help yes )
Nov 08 21:42:12 <max_posedon> what I should do, to refresh contacts, restart phonefsod?
Nov 08 21:42:27 <mrmoku> max_posedon: no, guess you have to restart opimd
Nov 08 21:42:30 <mrmoku> aka frameworkd
Nov 08 21:42:59 <max_posedon> how it can be, opimd caches smth?
Nov 08 21:43:36 <mrmoku> max_posedon: think so, yes
Nov 08 21:45:40 <max_posedon> ok, now contacts not even duplicated
Nov 08 21:46:17 <Weiss> blurb about what DRI/DRM/KMS does, if anyone's interested: http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
Nov 08 21:46:21 <mrmoku> max_posedon: yeah, because opimd merges them I guess
Nov 08 21:46:32 <mrmoku> don't know if that is perfect
Nov 08 21:46:40 <TAsn> Weiss, I am. thanks :)
Nov 08 21:47:57 <max_posedon> ah, it was temporary bug
Nov 08 21:48:05 <max_posedon> now contacts duplicated
Nov 08 21:48:13 <Weiss> TAsn: it's pretty hastily written. if you find any mistakes or think it misses anything, let me know..
Nov 08 21:48:29 <mrmoku> max_posedon: you can turn the SIM backend off
Nov 08 21:48:41 <max_posedon> how? looks like shr-settings doesn't work
Nov 08 21:48:48 <mrmoku> sim-contacts-fso_disable = 1 in [opimd]
Nov 08 21:48:52 <max_posedon> I click domains->contacts->nothing
Nov 08 21:48:55 <TAsn> Weiss, ok.
Nov 08 21:48:56 <TAsn> :)
Nov 08 21:48:58 <max_posedon> ah, ok
Nov 08 21:49:29 <TAsn> mrmoku, what about the hoversel issue?
Nov 08 21:49:43 <mrmoku> TAsn: don't think anything changed
Nov 08 21:49:55 <TAsn> :|
Nov 08 21:51:47 <alexxy> mrmoku: TAsn: nice boot screen with oemerge image
Nov 08 21:51:47 <alexxy> =)
Nov 08 21:53:28 <TAsn> I think dos made that one :)
Nov 08 21:54:02 <max_posedon> mrmoku, sorry, sim-contacts-fso_disable or sim_contacts_fso_disable?
Nov 08 21:54:21 <mrmoku> max_posedon: the first one :)
Nov 08 21:54:25 <JaMa> Weiss: wow great.. I'll read it before sleep today :)
Nov 08 21:54:35 <mrmoku> it is backend name in lowercase + _disable
Nov 08 21:54:39 <Weiss> JaMa: :).. it'll certainly help you sleep..
Nov 08 21:54:40 <max_posedon> really strange, ok
Nov 08 21:55:02 <mrmoku> max_posedon: yeah, backend name is SIM-Contacts-FSO
Nov 08 21:58:27 <max_posedon> btw, could we have imagemagick in feeds?
Nov 08 22:00:16 <CIA-86> SHR: 03tom 07libphone-ui * re98b9dfe3563 10/data/libphoneui.conf: Fixed the alsa controls in the configuration file to the correct one, thanks to DocScrutinizer
Nov 08 22:00:20 <CIA-86> SHR: 03tom 07libphone-ui * r4455bce1643f 10/src/ (phoneui-utils.c phoneui.h.in): Merge branch 'master' of git+ssh://git.shr-project.org/libphone-ui
Nov 08 22:01:24 <max_posedon> contacts, letters at right, COOL!
Nov 08 22:01:45 <mrmoku> max_posedon: index?
Nov 08 22:01:48 <max_posedon> mrmoku, one little issue, after adding field, shr-contacts closed
Nov 08 22:01:49 <mrmoku> yep that is cool :)
Nov 08 22:02:00 <max_posedon> but, why we don't display it always?
Nov 08 22:02:24 <mrmoku> heh, no idea if that is possible with an elm_index...
Nov 08 22:02:41 <max_posedon> ah, ok, but its really cool)
Nov 08 22:03:28 <max_posedon> btw, after adding filed, opimd replaced all properties of person
Nov 08 22:03:46 <TAsn> mrmoku, rebuild please :) ^
Nov 08 22:03:48 <max_posedon> including phone number, with removing "tel:" at beginning
Nov 08 22:03:53 <TAsn> fixed the default config file :)
Nov 08 22:03:57 <mrmoku> max_posedon: btw.... to work around the no GSM on boot issue I start fsousaged before frameworkd in /etc/init.d/framework
Nov 08 22:03:58 <TAsn> setting mic also works now. :)
Nov 08 22:04:10 <TAsn> mrmoku, ugly ! :)
Nov 08 22:04:14 <JaMa> Weiss: finished.. nice overview...
Nov 08 22:04:25 <mrmoku> TAsn: better than having to manually restart frameworkd ;)
Nov 08 22:04:26 <JaMa|Zzz> gnite all
Nov 08 22:04:30 <max_posedon> mrmoku, I prefer stop/start magic
Nov 08 22:04:33 <TAsn> mrmoku, probably. :)
Nov 08 22:04:35 <mrmoku> JaMa|Zzz: night... and have fun reading ;)
Nov 08 22:04:42 <max_posedon> restarting frameword doesn't help some times!)
Nov 08 22:04:53 <max_posedon> only if phonefsod stopped
Nov 08 22:04:54 <JaMa|Zzz> mrmoku: I alread read it just now..
Nov 08 22:05:06 <mrmoku> well sleep well then :)
Nov 08 22:05:41 <mrmoku> TAsn: building imagemagick first
Nov 08 22:06:02 <TAsn> cool.
Nov 08 22:06:40 <max_posedon> hm, why opimd structure so much far from vcard..
Nov 08 22:06:53 <Weiss> :)
Nov 08 22:07:15 <TAsn> max_posedon, 
Nov 08 22:07:25 <TAsn> http://openmoko.org/wiki/opimd_redesign
Nov 08 22:07:28 <mrmoku> TAsn: and clock is still one hour off
Nov 08 22:07:31 <TAsn> though concerning that question
Nov 08 22:07:42 <mrmoku> aka UTC
Nov 08 22:08:12 <TAsn> vcard is used for transferring contacts or I dunno what, opimd is designed for saving various types of information about people
Nov 08 22:08:19 <TAsn> it was initially designed for BB
Nov 08 22:09:49 <max_posedon> and I didn't understand fields in contacts, when all of them in contact_values
Nov 08 22:10:57 <max_posedon> TAsn, I'll think about it, but, its all about opimd internals, so not important for me, as user
Nov 08 22:13:41 <max_posedon> mrmoku, btw, does "new" message bag fixed?
Nov 08 22:13:51 <max_posedon> or I should know some workaround
Nov 08 22:14:29 <TAsn> what new message bug?
Nov 08 22:15:01 <max_posedon> some days ago, when I received sms, shr-messages doesn't show it
Nov 08 22:15:47 <TAsn> raster, hey.
Nov 08 22:16:15 <TAsn> raster, how hard do you think making an optimized (lower quality) x11-32 engine will be? (for me, not for you)
Nov 08 22:17:00 <PaulFertser> TAsn: i guess he'd say you can only make a slower engine and it'll take a month of hard work ;)
Nov 08 22:17:31 <raster> TAsn: u are not going to be able to do it
Nov 08 22:17:38 <raster> because - everything is already there
Nov 08 22:17:41 <max_posedon> [opimd] :( http://pastebin.ca/1662623
Nov 08 22:17:46 <raster> dont use smooth scaling
Nov 08 22:17:53 <raster> u can compile evas with line-dither
Nov 08 22:18:01 <raster> u are not going to get better.
Nov 08 22:18:29 <TAsn> raster, what about completing x11-16?
Nov 08 22:18:34 <TAsn> how hard is that?
Nov 08 22:18:34 <TAsn> :)
Nov 08 22:18:47 <raster> getting hardeer by the day
Nov 08 22:18:49 <raster> its not too bad
Nov 08 22:19:01 <raster> but... expect that i have x11-16 in my targets to kill off
Nov 08 22:20:01 <TAsn> that's even better.
Nov 08 22:20:10 <TAsn> dos1 really wants x11-16 but I hate it :)
Nov 08 22:20:24 <raster> as such evas has way too  many engines
Nov 08 22:20:32 <raster> they need to be simplified and reduced
Nov 08 22:20:34 <TAsn> I preferred finishing it over using the incomplete version, but killing it is preferred.
Nov 08 22:20:36 <TAsn> :)
Nov 08 22:20:52 <raster> the software engines are ok- but i can improve their display interfacing to be cleaner and easier to support
Nov 08 22:21:12 <raster> so in the end an engine is a very simple "copy resultant converted pixels to the screen  fast" and thats all
Nov 08 22:21:24 <raster> it does a bit more now - but can be easier
Nov 08 22:21:40 <raster> that way every software engine  inherits the exact same core
Nov 08 22:21:40 <raster> easy to maintain
Nov 08 22:21:48 <raster> and then - i'd probably reduce to just a gl enigne
Nov 08 22:21:54 <raster> and otherwise nothing else
Nov 08 22:22:18 <TAsn> well, re-factoring the copy pastes is a good idea.
Nov 08 22:22:43 <raster> well as such the software engines are pretty good
Nov 08 22:22:45 <raster> the 32bit ones
Nov 08 22:22:51 <raster> they do inherit the same rendering cores
Nov 08 22:22:57 <raster> ie literally inherit
Nov 08 22:23:05 <raster> there's an inheritance scheme in enignes
Nov 08 22:23:30 <raster> software_generic is an engine they all inherit
Nov 08 22:23:37 <TAsn> yeah, noticed that.
Nov 08 22:23:46 <raster> but it is possible to reduce the work of doing a software engine further
Nov 08 22:23:47 <TAsn> (when I worked on rtl)
Nov 08 22:24:06 <raster> a lot of apis need changing
Nov 08 22:25:17 <raster> theres many years of cruft in there by now
Nov 08 22:26:21 <TAsn> :)
Nov 08 22:26:21 <raster> adding in the map/3d/rotation stuff - i'm having to wrestle with it a bit
Nov 08 22:26:24 <raster> for example
Nov 08 22:26:30 <raster> so.. i want things reduced
Nov 08 22:26:38 <raster> it limits what evas can expand to do
Nov 08 22:26:45 <TAsn> and I can understand you.
Nov 08 22:26:53 <TAsn> so stop and re-factor.
Nov 08 22:26:54 <raster> and the future isnt in trying to keep pushing a 16bit engine
Nov 08 22:27:24 <raster> even previous-gen embedded devices work fine in the 32bit enigne e(s3c64xx - armv6 for example)
Nov 08 22:27:34 <raster> current getn (cortex-a8) dont care
Nov 08 22:27:44 <raster> i'm worrying about next-gen (cortex-a9)
Nov 08 22:27:58 <raster> and anything with gfx accel in it :)
Nov 08 22:27:59 <mrmoku> max_posedon: imagemagick built... building package index now
Nov 08 22:28:12 <mrmoku> TAsn: after that it will build a light and a full image (including your alsa fix>)
Nov 08 22:28:22 <mrmoku> and me is going to bed now :)
Nov 08 22:28:26 <mrmoku> gnight all
Nov 08 22:28:37 <sicu> g'nite mrmoku|away
Nov 08 22:28:48 <TAsn> mrmoku|away, night.
Nov 08 22:28:55 <TAsn> mrmoku|away, make sure you revert jama's change.
Nov 08 22:29:16 <TAsn> mrmoku|away, and btw, from what raster just said, I think we are officially killing x11-16 :)
Nov 08 22:29:55 <sicu> TAsn: it was reverted 32 mins ago =]
Nov 08 22:30:00 <TAsn> I'm glad. :
Nov 08 22:30:43 <sicu> how long does the buildhost take to build lite and full image?
Nov 08 22:31:45 <raster> TAsn: 32bit will always have anoverhead of (for solid data) having to read+write 100% more than 16bit
Nov 08 22:31:59 <raster> alos you have a conversion overhead of any updates from 32->16bit
Nov 08 22:32:19 <TAsn> raster, so a 32bit engine isn't *that* bad
Nov 08 22:32:20 <TAsn> right?
Nov 08 22:32:35 <TAsn> (if I drop the smooth effect{
Nov 08 22:32:55 <raster> and.. for alpha blends u have an overhead of about 50% more reads, 100% more writes
Nov 08 22:33:12 <raster> 16bit enigne refuses to support smooth shading - which is a speedup, but a quality degredation
Nov 08 22:33:23 <raster> not something i think can't be jst done in themes/apps anyway
Nov 08 22:33:41 <raster> it depends what you do.
Nov 08 22:34:45 <raster> chances are 32bit will take about 50% longer to do anything compared to 16bit enigne
Nov 08 22:34:49 <raster> give or take
Nov 08 22:35:15 <raster> as the 32bit engines is better optimised, has more caching paths, has simpler pixel layout paths,
Nov 08 22:35:28 <raster> that make up for the other slow-downs a bit
Nov 08 22:37:06 <TAsn> but a better 16bit engine will probably be twice as fast.
Nov 08 22:38:08 <sicu> time to hit the sack, nn folks
Nov 08 22:38:32 <TAsn> I'm also off.
Nov 08 22:38:33 <TAsn> raster, thanks.
Nov 08 22:38:35 <TAsn> night all.
Nov 08 22:40:32 <raster> TAsn: yeah. it'll be able to be fast
Nov 08 22:40:33 <raster> BUT
Nov 08 22:40:39 <raster> u will pay a quality price
Nov 08 22:40:47 <raster> and in a feew years from now - it'll be useless
Nov 08 22:40:52 <raster> desktops just dont use 16bit anymore
Nov 08 22:40:58 <raster> embedded is beginning to ween off it already
Nov 08 22:41:01 <TAsn> yep. :|
Nov 08 22:41:05 <TAsn> I agree.
Nov 08 22:41:05 <raster> i have a phone that is 32bit
Nov 08 22:41:11 <TAsn> I also think it's useless.
Nov 08 22:41:16 <TAsn> raster, same here (FR)
Nov 08 22:41:17 <TAsn> :)
Nov 08 22:41:22 <raster> (hell it's an oled screen - 16bit would be so underselliong your display hw)
Nov 08 22:41:46 <raster> the quality between 32 and 16bit is very visible (to me anyway)
Nov 08 22:43:53 <raster> 16bit engine to me is like
Nov 08 22:43:54 <raster> http://i172.photobucket.com/albums/w36/pjphreak_photos/00041.jpg
Nov 08 22:43:58 <raster> and 32bit engine is
Nov 08 22:44:09 <raster> http://images2.layoutsparks.com/1/53305/another-skyline-car-stylish.jpg
Nov 08 22:44:31 <raster> one of those is dirty and ugly :)
Nov 08 22:44:54 <TAsn> raster, and the other is for posers.
Nov 08 22:45:11 <TAsn> for this example I get you hate image quality altogether ;)
Nov 08 22:45:26 <raster> hey - don't knock the gt-r!
Nov 08 22:45:41 <TAsn> I like the skyline, I just don't like the kit. :)
Nov 08 22:46:20 <raster> http://autopartswarehouse.files.wordpress.com/2009/01/02_nissan_gt-r_specv_opt.jpg
Nov 08 22:46:21 <max_posedon> what image formats are fastest for displaying with etk, keeping in mind 64x64 size
Nov 08 22:46:22 <raster> that better?
Nov 08 22:46:22 <max_posedon> ?
Nov 08 22:46:34 <raster> (normal factory kit for current gt-r)
Nov 08 22:46:43 <raster> and no
Nov 08 22:46:52 <raster> when i see screenshots of 16bit enigne stuff.,.. i cringe
Nov 08 22:47:48 <TAsn> raster, a lot better.
Nov 08 22:47:49 <TAsn> :)
Nov 08 22:48:00 <TAsn> now I get your example. :)
Nov 08 22:48:33 <raster> :)
Nov 08 22:48:37 <raster> thats how it looks to me
Nov 08 22:48:37 <TAsn> anyhow, now I'm really off. :)
Nov 08 22:48:43 <TAsn> raster, I can feel you
Nov 08 22:48:47 <Kensan> raster: evenin' sir
Nov 08 22:48:48 <raster> one of those cars... i'd not be seen dead in
Nov 08 22:48:48 <TAsn> as I also feel the difference
Nov 08 22:48:49 <raster> :)
Nov 08 22:49:09 <TAsn> raster, that's why I don't use the x11-16 engine
Nov 08 22:49:19 <TAsn> and I want to eliminate it completely ;]
Nov 08 22:49:20 <raster> i am well past that time in my life where i'd drive a piece of shit because i simply have no money.. and cant get credit
Nov 08 22:49:21 <raster> :)
Nov 08 22:49:26 <raster> Kensan:  yo yo
Nov 08 22:49:30 <TAsn> raster, ;]
Nov 08 22:49:32 <TAsn> ciao.
Nov 08 22:49:38 <raster> TAsn:  ciao!
Nov 08 22:49:54 <max_posedon> raster, I'm sure you can suggest me smth)
Nov 08 22:50:25 <Kensan> raster: so how is the australian summer coming?
Nov 08 22:51:01 <Kensan> raster: There's snow here in the mountains you know ;)
Nov 08 22:51:38 <raster> max_posedon: ooh.. um... do u need alpha?
Nov 08 22:52:07 <raster> Kensan: so far, have had 1 sumemr day (last week - was up to 37 in the city, but... thats it. pretty lame for summer)
Nov 08 22:52:16 <raster> tho technically. it's still spring
Nov 08 22:52:44 <max_posedon> raster, I want 2 answers for both cases)
Nov 08 22:52:56 <max_posedon> but it can be 'no'
Nov 08 22:53:40 <max_posedon> I want little improve shr-contacts , make thumb-ing for images faster as possible
Nov 08 22:54:03 <Kensan> raster: heh I see. I'll be hitting the slopes in about a month or so I hope.
Nov 08 22:54:07 <raster> jpeg is surprisingly fast
Nov 08 22:54:20 <raster> if u want alpha - .eet files cna encode jpe WITH alpha
Nov 08 22:55:24 <max_posedon> 64x64, jpeg? hm, freankly speaking I agree even with smth like bmp, main reason - be fast
Nov 08 22:55:57 <max_posedon> but freankly speaking want smth toolkit independed, so imagemagick should be possible to convert
Nov 08 22:56:00 <raster> jpeg
Nov 08 22:56:05 <raster> decode is REALLY fast
Nov 08 22:56:12 <raster> u can decode at a ,lower res for free
Nov 08 22:56:14 <raster> hell - its FASTEr
Nov 08 22:56:21 <raster> jpeg thanks to its compression is low on disk-io
Nov 08 22:56:36 <raster> Kensan:  bastard!
Nov 08 22:57:23 <Kensan> raster: well, I have to buy new equipment first though... won't be cheap :/
Nov 08 22:57:40 <raster> i used to own some
Nov 08 22:57:49 <raster> got tired of lugging it around the world on planes
Nov 08 22:57:59 <raster> i just rent :)
Nov 08 22:58:00 <Kensan> raster: well you can go to the beach and surf or get a sunburn or whatever, that's not that bad either  ;)
Nov 08 22:58:16 <raster> sun burn.. oooooh ow.... no thanks!
Nov 08 22:58:17 <raster> :)
Nov 08 22:58:41 <Kensan> raster: well I don't need to fly, I just drive up to the cabine and take my gear out of the storage room ;)
Nov 08 22:59:47 <raster> Kensan:  thus my "bastard!" line :)
Nov 08 23:00:13 <Kensan> raster: yeah I know, I get that sometimes... not for the same reason though *heh*
Nov 08 23:00:34 <raster> :)
Nov 08 23:00:41 <raster> more from the women you date? :)
Nov 08 23:02:01 <alexxy> mrmoku|away: TAsn: btw fsousaged seems dont work again 
Nov 08 23:02:02 <alexxy> =)
Nov 08 23:02:20 <Kensan> no comment
Nov 08 23:03:12 <max_posedon> alexxy, it work
Nov 08 23:03:22 <max_posedon> your phone can't register yes?
Nov 08 23:03:28 <alexxy> yep
Nov 08 23:03:38 <max_posedon> (ok, it might be fsousaged) but workaround is classic
Nov 08 23:03:56 <max_posedon> stop phonefsod, stop framework, start framework, wait, start phonefsod
Nov 08 23:05:21 <alexxy> i know =)
Nov 08 23:09:37 <max_posedon> may be you even know ffalarms workaround?
Nov 08 23:10:55 <alexxy> hmm
Nov 08 23:11:07 <alexxy> i dont actualy use ffalarms
Nov 08 23:11:09 <alexxy> =)
Nov 08 23:29:23 <CIA-86> SHR: 03seba.dos1 07shr-settings * r07cd88562116 10/shr_settings_modules/shr_pm.py: [PM] use phonefsod dbus interface instead of ophonekitd
Nov 08 23:33:43 <CIA-86> SHR: 03seba.dos1 07shr-settings * r0bf2eaaafc00 10/shr-settings: [launcher] s/ophonekitd/phonefsod/, display phonefsod logs
Nov 08 23:45:07 <CIA-86> SHR: 03seba.dos1 07shr-settings * r4177f9d7ef34 10/shr-settings: [launcher] use init.d script to start phonefsod
Nov 08 23:45:14 <CIA-86> SHR: 03seba.dos1 07shr-settings * r4d3def816be2 10/TODO: [TODO] update
Nov 08 23:45:15 <CIA-86> SHR: 03seba.dos1 07shr-settings * r7bb4030d557a 10/shr_settings_modules/shr_services.py: [services] replace ophonekitd with phonefsod
Nov 09 00:38:24 <GarthPS> hi 
Nov 09 00:38:57 <GarthPS> is there some one how can tel me what to do to this error ona "make image"? 
Nov 09 00:38:58 <GarthPS> Using dash as /bin/sh causes various subtle build problems, please use bash instead.
Nov 09 00:39:37 <max_posedon> so, why didn't you want use bash?
Nov 09 00:39:59 <max_posedon> ls -la /bin/sh
Nov 09 00:40:10 <max_posedon> will may be explain you key of problem
Nov 09 00:41:30 <GarthPS> I do want to use it! Idid nothing to tell 'I don't know what' to use dash instead of bash
Nov 09 00:41:40 <GarthPS> ls -la /bin/sh
Nov 09 00:41:40 <GarthPS> lrwxrwxrwx 1 root root 4 2009-10-25 11:25 /bin/sh -> dash
Nov 09 00:41:59 <max_posedon> should be /bin/sh -> bash
Nov 09 00:42:38 <max_posedon> (and make sure that you have /bin/bash before changing symlink)
Nov 09 00:43:54 <GarthPS> but why do !I have to change it in the system? can't i change some thing else like the caller ? but I don't know who want to use /bin/sh instead of /bin/bash
Nov 09 00:44:03 <GarthPS> for the record, I do have /binbash
Nov 09 00:44:35 <max_posedon> I don't know who wants it too
Nov 09 00:45:04 <max_posedon> yes you can change caller line in some scripts (I don't know which scripts)
Nov 09 00:45:17 <max_posedon> so, you have 2 options
Nov 09 00:45:28 <max_posedon> 1. just change /bin/sh (may be temporary)
Nov 09 00:45:42 <GarthPS> I fact it is the first time I want to build SHR
Nov 09 00:45:44 <max_posedon> 2. find and fix calling /bin/bash where nesessory
Nov 09 00:46:02 <max_posedon> if you decide 2, don't forget send patches after
Nov 09 00:46:44 <GarthPS> I made  wget Makefile ; make setup; cd shr-unstalbe; edit my local.conf and make image and then error
Nov 09 00:47:37 <max_posedon> yes, common way
Nov 09 00:48:07 <GarthPS>  make image
Nov 09 00:48:07 <GarthPS> . conf/topdir.conf && test "`pwd`" = "$TOPDIR" || echo "TOPDIR='`pwd`'" > conf/topdir.conf
Nov 09 00:48:07 <GarthPS> . ./setup-env; exec bitbake "shr-lite-image"
Nov 09 00:48:07 <GarthPS> ERROR:  Openembedded's config sanity checker detected a potential misconfiguration.
Nov 09 00:48:07 <GarthPS>         Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Nov 09 00:48:07 <GarthPS>         Following is the list of potential problems / advisories:
Nov 09 00:48:09 <GarthPS>         Using dash as /bin/sh causes various subtle build problems, please use bash instead.
Nov 09 00:48:11 <GarthPS> make: *** [image] Erreur 1
Nov 09 00:49:09 <max_posedon> yep, I know this error
Nov 09 00:49:19 <max_posedon> so, what you want?
Nov 09 00:49:32 <GarthPS> bin juste que ca marche! :p
Nov 09 00:50:14 <GarthPS> I do have /bin/bash, so will the caller calls for /bin/sh if it is not a good choice?
Nov 09 00:51:02 <max_posedon> sorry, don't get your question
Nov 09 00:51:20 <max_posedon> scripts doesn't deside what shell which run them
Nov 09 00:51:39 <max_posedon> OS just exec #!/bin/sh
Nov 09 00:52:05 <max_posedon> and for OE it /bin/sh must be symlink to bash
Nov 09 00:52:21 <GarthPS> so I need to define my OS to use /bin/bash instead of /bin/sh
Nov 09 00:52:54 <max_posedon> nope
Nov 09 00:53:06 <max_posedon> you haven't any "/bin/sh"
Nov 09 00:53:16 <max_posedon> its *symlink* to /bin/dash
Nov 09 00:53:27 <max_posedon> it *must be* symlink to /bin/bash
Nov 09 00:53:32 <max_posedon> so, go ahead and fix it
Nov 09 00:55:46 <GarthPS> ok I understand but I do not find this very clean...
Nov 09 00:56:07 <GarthPS> but perhaps it is the way..
Nov 09 00:59:12 <GarthPS> ok it runs know but what to I do if an other program needs the opposit this time? like /bin/sh-> dash?
Nov 09 01:00:13 <GarthPS> (do you know if I need to add "CACHE = "~/your/path/somedir" " to /usr/share/bitbake/conf/bitbake.conf ? it is the first time i use bitbake.)
Nov 09 01:00:32 <GarthPS> ands thanks of your help! ;)
Nov 09 01:00:58 <max_posedon> bash have all features that dash have, so it won't
Nov 09 01:01:11 <max_posedon> about CACHE, I don't think so
Nov 09 01:01:19 <max_posedon> but you can if you want
Nov 09 01:02:26 <GarthPS> ok thanks!
Nov 09 01:02:35 <GarthPS> do you know about ccache?
Nov 09 01:03:19 <max_posedon> Do I know what?)
Nov 09 01:05:35 <GarthPS> "ccache"
Nov 09 01:07:01 <max_posedon> I know what is ccache, if you asking this
Nov 09 01:09:40 <GarthPS> yes it is :). but I have found my next question's answer so.. :) thanks again. good night
**** ENDING LOGGING AT Mon Nov 09 02:59:56 2009