**** BEGIN LOGGING AT Mon Dec 21 02:59:57 2009
Dec 21 04:55:26 <satish> hi 
Dec 21 04:55:41 <satish> any one has idea on shr-testing image build ?
Dec 21 04:57:03 <tmzt> like?
Dec 21 06:49:14 <JesusMcCloud> moin
Dec 21 06:56:31 <JaMa> moin
Dec 21 06:57:42 <JesusMcCloud> JaMa, hi, i'm having some trouble here... i did not upgrade or antyhign but suspend si proken and fsousaged.log tells me that lowleverl_type 'openmoko" plugin is not found
Dec 21 06:57:56 <JesusMcCloud> do cou have any idea how to fix it? which package to reinstall?
Dec 21 07:09:25 <JaMa> JesusMcCloud: still same kernel from andy-tracking? 2.6.29_rc3?
Dec 21 07:10:10 <JaMa> JesusMcCloud: /usr/lib/cornucopia/modules/fsousage/lowlevel_openmoko.so is part of fsousaged package..
Dec 21 07:10:13 <JesusMcCloud> JaMa, still same kernel (my system did not change from befor and after breakage) so the current kernel used is shr, noch chenges
Dec 21 07:10:29 <JesusMcCloud> JaMa, thx. reistlallign fsousaged
Dec 21 07:10:57 <DocScrutinizer51> moin
Dec 21 07:11:21 <JesusMcCloud> moin
Dec 21 07:16:41 <JesusMcCloud> JaMa, thx, works fine now.. though i still wonder what broke it
Dec 21 07:16:48 <JesusMcCloud> anyways, gtg
Dec 21 07:17:55 <JaMa> mrmoku|away: was that task-shr-feed built? I see only shr-feed from testing2009 in tinderbox..
Dec 21 07:18:46 <JaMa> mrmoku|away: hmm but shr-launcher is in ipk dir.. so nvm
Dec 21 07:30:18 <tmzt> sat/ sorry not a bitbake person
Dec 21 07:30:46 <tmzt> sat/
Dec 21 07:31:12 <tmzt> satish:
Dec 21 08:09:38 <morphis> heyho
Dec 21 08:12:10 <satish> hi
Dec 21 08:12:25 <satish> i'm failed to build the shr-testing image
Dec 21 08:12:52 <satish> any one has expertize to help me ?
Dec 21 08:13:05 <satish> i got the below error
Dec 21 08:13:07 <satish> ERROR: Build of /home/satish/shr/shr-testing/openembedded/recipes/eglibc/eglibc_2.10.bb do_configure failed ERROR: Task 202 (/home/satish/shr/shr-testing/openembedded/recipes/eglibc/eglibc_2.10.bb, do_configure) failed NOTE: Tasks Summary: Attempted 273 tasks of which 273 didn't need to be rerun and 1 failed. ERROR: '/home/satish/shr/shr-testing/openembedded/recipes/eglibc/eglibc_2.10.bb' failed make: *** [image] Error 1
Dec 21 08:14:10 <morphis> satish: do you use the shr makefile?
Dec 21 08:14:32 <satish> yes
Dec 21 08:15:20 <morphis> hm, you can try a 'bitbake -c clean eglibc' and then retry
Dec 21 08:15:35 <satish> yes..i did the same
Dec 21 08:15:49 <morphis> maybe a 'make update' will help (cause there are maybe some bugs in oe recipes for eglibc?)
Dec 21 08:16:24 <satish> i got the below message in log
Dec 21 08:16:26 <satish> checking whether we are using the GNU C compiler... yes checking whether arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb accepts -g... yes checking for arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb option to accept ANSI C... none needed checking for gcc... gcc checking how to run the C preprocessor... arm-oe-linux-gnueabi-gcc -E configure: error: C pr
Dec 21 08:16:42 <satish> configure: error: C preprocessor "arm-oe-linux-gnueabi-gcc -E" fails sanity check See `config.log' for more details. FATAL: oe_runconf failed
Dec 21 08:17:21 <JaMa> satish: you need also -c clean eglibc-initial
Dec 21 08:17:37 <satish> ok... let me try
Dec 21 08:17:51 <JaMa> and I merged eglibc bump few minutes ago..
Dec 21 08:18:10 <JaMa> so if you haven't updated in last 10 mins or so.. do it now to get latest version
Dec 21 08:18:55 <satish> ok
Dec 21 08:19:09 <satish> make update will do that ?
Dec 21 08:19:17 <Heinervdm> JaMa: he is building shr-testing
Dec 21 08:19:36 <satish> yes.....i'm building shr-testing.
Dec 21 08:19:56 <JaMa> satish: ah then just clean eglibc-initial and if it doesn't help then whole gcc-*4.4.2*bb
Dec 21 08:20:38 <satish> should i need to clean gcc-*4.4.2*bb ?
Dec 21 08:20:49 <JaMa> maybe I had with last eglibc bump
Dec 21 08:21:59 <satish> ok
Dec 21 08:23:23 <JaMa> its just becase both recipes installs same file to stagging area and when the later is updated (cleaned and then tried to build) it fails because needed files (originaly from eglibc-initial) are missing from staging area.
Dec 21 08:23:51 <satish> ok
Dec 21 08:25:23 <satish> i got the below message
Dec 21 08:25:26 <satish> Legacy staging mode for /home/satish/shr/shr-testing/openembedded/recipes/eglibc/eglibc-initial_2.10.bb
Dec 21 08:35:05 <JaMa> Heinervdm: btw in latest evdev xorg drivers is calibration config available in xorg.conf, I haven't tried it yet, but maybe we could replace our kernel driver calibration with that..
Dec 21 08:35:57 <JaMa> http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?h=evdev-2.3-branch&id=57b54ee3995f2f678ef359e7663cad517a8b2433
Dec 21 08:36:04 <Heinervdm> but then we need a calibration utility...
Dec 21 08:36:21 <Heinervdm> i would vote for using tslib ;)
Dec 21 08:38:02 <JaMa> why utility.. I guess we just need those 4 magic numbers to update our xorg.conf :)
Dec 21 08:38:15 <Heinervdm> and writing with a script into the xorg.conf is a pain, we should wait for xserver 1.8 with taht
Dec 21 08:38:17 <tmzt> did you ever get the script?
Dec 21 08:38:25 <tmzt> anyway
Dec 21 08:38:39 <tmzt> just use a small script in xinit.d
Dec 21 08:38:53 <tmzt> use xinput to set the values
Dec 21 08:38:55 <Heinervdm> JaMa: there are users that not fit our calibration
Dec 21 08:39:22 <JaMa> Heinervdm: ah then I see
Dec 21 08:39:35 <Heinervdm> JaMa: most gta02 have similar calibration but not all
Dec 21 08:41:47 <DocScrutinizer51> but each device comes with a somewhat working calibration don at factory
Dec 21 08:42:23 <Heinervdm> DocScrutinizer51: calibration is done in software
Dec 21 08:43:34 <Heinervdm> DocScrutinizer51: i think the ones that don't fit our calibration are some with a defect or were disasembled once 
Dec 21 08:43:39 <lindi-> DocScrutinizer51: hmm really? where is that saved?
Dec 21 08:44:10 <DocScrutinizer51> disassembling can not decalibrate ts
Dec 21 08:44:54 <Heinervdm> DocScrutinizer51: don't know, nerver disassembled mine, only other ts devices
Dec 21 08:45:52 <Heinervdm> but there are users that complain about decalibrated ts, so we should provide sth to calibrate the screen
Dec 21 08:47:44 <DocScrutinizer51> sure we should
Dec 21 08:48:17 <Heinervdm> with tslib we have everthing for that, but with evdev we don't :)
Dec 21 08:48:19 <DocScrutinizer51> I always was puzzled and it boggled me how FR can ship without any
Dec 21 08:59:09 <tmzt> http://ibot.rikers.org/%23htc-linux/20091008.html.gz
Dec 21 09:00:01 <tmzt> search for xinput
Dec 21 09:09:44 <schasch> playya
Dec 21 09:20:59 <JaMa> radekp: do you still need that qt* for tests?
Dec 21 09:27:29 <JaMa> radekp: nvm it was python-pyqt for vanous123
Dec 21 09:30:11 <beniwtv> Hey all... Anyone knows how to get libsyncml on SHR-U? It doesn't seem to be in the feeds.
Dec 21 09:46:55 <von_fritz> benitw wait until mrmoku returns and request building on buildhost :) 
Dec 21 09:47:56 <von_fritz> ehhm sorry it was beniwtv ;)
Dec 21 09:48:22 <beniwtv> von_fritz: thanks, will do
Dec 21 09:53:04 <JaMa> satish: eglibc just failed for me again after gcc-cross bump and eglibc bump (missing headers like stdio.h, sys/types.h, limits.h..) for i in recipes/gcc/*4.4.2*bb recipes/eglibc/*2.10*bb; do echo $i; bitbake -c clean -b $i; done and build image is easiest way to fix it (fastest for your time, but definitely not fastest wrt cputime)
Dec 21 11:46:47 <BillK> JaMa: re the email about "Re: [Shr-Devel] shr-image.bb do_rootfs failed"
Dec 21 11:47:17 <BillK> JaMa: still fails with same error I posted in reply to the email
Dec 21 11:47:25 <JaMa> re: re
Dec 21 11:47:30 <JaMa> shr/testing?
Dec 21 11:47:38 <BillK> shr-u 
Dec 21 11:47:52 <JaMa> I haven't seen that one ever.. and it updated today just fine..
Dec 21 11:48:21 <BillK> removed /tmp a couple of days ago and had an error to with openmoko-icon-theme-standard2 which wouldnt build
Dec 21 11:48:27 <JaMa> BillK: have you tried -c clean -c build for that package?
Dec 21 11:48:29 <Heinervdm> BillK: spaetz fixed the openmoko-icon-theme-standard2 yesterday
Dec 21 11:48:40 <BillK> was able to build it an hour ago, but then this error when it got to the image
Dec 21 11:48:55 <BillK> ok, will try again.
Dec 21 11:49:12 <JaMa> if it still fails try to rebuild task-shr-minimal-gtk
Dec 21 11:49:26 <BillK> ok
Dec 21 11:50:06 <JaMa> hmm seems like broken somehow.. NOTE: Not creating empty archive for openmoko-icon-theme-standard2-0.1.0+svnr4232-r2.4
Dec 21 11:50:35 <Heinervdm> then spaetzN800 fixed it the wrong way :D
Dec 21 11:50:36 <JaMa> /usr/share/icons/openmoko-standard/ is not in FILES anymore..
Dec 21 11:52:32 <JaMa> mmt I'll push it..
Dec 21 11:54:26 <JaMa> BillK: try it now
Dec 21 11:58:40 <daniele_athome> !logs
Dec 21 11:58:42 <cdbot2> Channel logs for #openmoko-cdevel are archived at:
Dec 21 11:58:42 <cdbot2> http://hentges.net/tmp/logs/irc/%23openmoko-cdevel
Dec 21 11:58:43 <cdbot2> Live-logs are available at
Dec 21 11:58:45 <cdbot2> http://hentges.net/tmp/logs/irc/livelogs/%23openmoko-cdevel.livelog
Dec 21 11:58:47 <cdbot2> See ?? help-logs for usage instructions
Dec 21 11:58:51 <daniele_athome> ~logs
Dec 21 11:59:09 <apt> All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged.
Dec 21 13:08:37 <BillK> JaMa: fixed, have an image. Tkx.
Dec 21 13:38:09 <mrmoku> beniwtv: libsyncml? let me check...
Dec 21 13:39:10 <JaMa> mrmoku: I checked that its not in depend of any our recipe .. so we would need it in task-shr-feed directrly
Dec 21 13:39:23 <mrmoku> yup, trying if it builds and will add it then
Dec 21 13:39:59 <JaMa> mrmoku: new eglibc bump needs to clean eglibc* and gcc* again :/
Dec 21 13:40:09 <JaMa> for i in recipes/gcc/*4.4.2*bb recipes/eglibc/*2.10*bb; do echo $i; bitbake -c clean -b $i; done; bitbake -k shr-image
Dec 21 13:40:53 <JaMa> strange because gcc recipes were bumped in same changeset.. and INC_PR was increased so both eglibc ang eglibc-initial were updated in paralel
Dec 21 13:56:57 <mrmoku> NOTE: The MD5Sums did not match. Wanted: '5aa77f55c0e0aab8eb8ed982335daac8' and Got: 'ef3e66df3c4223ce5ce0a70ded5c5221'
Dec 21 13:57:05 <mrmoku> JaMa: what to do in such a case?
Dec 21 13:57:54 <JaMa> mrmoku: check diff between upstream tarball and yours
Dec 21 13:58:22 <mrmoku> it just downloaded it...
Dec 21 13:58:46 <JaMa> mrmoku: last time I checked some libsdl* and it was the same content (diff -rq showed nothing) only dates were different so .tar.gz was different
Dec 21 13:58:53 <JaMa> ah so you don't have old tarbal?
Dec 21 13:58:57 <JaMa> which one?
Dec 21 13:59:12 <mrmoku> wbxml from opensync
Dec 21 13:59:27 <mrmoku> dep of libsyncml :|
Dec 21 13:59:29 <JaMa> mrmoku: or if there is some info about tarbal recreatin in news or changelog..
Dec 21 13:59:42 <JaMa> I'll check it.. maybe I have one in my dir
Dec 21 13:59:43 <mrmoku> JaMa: ok, will take a look on upstream pages
Dec 21 14:00:20 <JaMa> mrmoku: btw do you have insecure downloads still enabled in Makefile?
Dec 21 14:00:57 <JaMa> mrmoku: I've today noticed one broken checksum in latest pisi..
Dec 21 14:01:41 <mrmoku> hmm... probably... should I disable it?
Dec 21 14:03:46 <JaMa> maybe yes as we're pussing everything to oe.dev and they are a bit more carefull about checksums.conf
Dec 21 14:05:05 <mrmoku> JaMa: upstream has a md5sum file which matches the ef3e66 one...
Dec 21 14:05:15 <mrmoku> so I guess it is just a wrong one in checksums.ini
Dec 21 14:06:44 * JaMa is still building cmake-native...
Dec 21 14:08:33 <JaMa> mrmoku: but yes I have same checksum as you..
Dec 21 14:09:28 <JaMa> mrmoku: hehe its wrong in checksums.ini for sure..
Dec 21 14:09:49 <JaMa> mrmoku: see checksum of http://downloads.xiph.org/releases/vorbis/libvorbis-1.2.3.tar.gz just above libwbxml :)
Dec 21 14:13:24 <JaMa> mrmoku: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=f519bc2e363cc4ccb8acf5f1a7faa335e9e07d1d
Dec 21 14:14:28 <JaMa> mrmoku: should I push it?
Dec 21 14:14:44 <mrmoku> JaMa: hehe ouch
Dec 21 14:14:48 <mrmoku> JaMa: yes please :)
Dec 21 14:15:12 <mrmoku> beniwtv: libsyncml is in the feed now
Dec 21 14:20:51 <JaMa> mrmoku: pushed/merged/pushed
Dec 21 15:04:24 <daniele_athome> hello, I have problems in shr-unstable build
Dec 21 15:04:31 <daniele_athome> building freetype, configure step: "Too many open files"
Dec 21 15:04:44 <daniele_athome> i'm googling around but there seems to be nothing
Dec 21 15:07:11 <AntonTakk> maybe hitting kernel.maxfiles?
Dec 21 15:08:20 <daniele_athome> AntonTakk, I set ulimit for files to 16k
Dec 21 15:08:48 <AntonTakk> ah, would think that should be enough
Dec 21 15:13:36 <sybren> hey all
Dec 21 15:14:49 <sybren> I've got navit running with fsoraw -r Display,CPU
Dec 21 15:15:26 <sybren> I'd like it to keep the Display resource (ie not lock, dim nor blank) as it does now, but when manually locking the screen with the AUX button I'd like the display to blank
Dec 21 15:15:46 <sybren> is there any way of doing this?
Dec 21 15:30:14 <CIA-78> freesmartphone.org: 03mickey 07cornucopia * r13a86f659f11 10/libfsobasics/ (fsobasics/threading.vala tests/testthreading.vala): libfsobasics: calling selector, err... function on main thread works now
Dec 21 16:57:58 <TAsn> hey. :P
Dec 21 17:03:19 <mrmoku> TAsn: bbl :P
Dec 21 17:03:24 <TAsn> same here.
Dec 21 17:03:26 <TAsn> ciao.
Dec 21 17:33:49 <DocScrutinizer51> sybren: this *should* work exactly that way. Allocating resources should stop *automatic* dim/suspend only. User triggered dim/lock/suspend should still work as expected. Btw when you allocated Display you shouldn't need CPU anyway, as CPU can't suspend with display on. Though.. on second thought this might be needed to stop suspending when user dims display as suggested by you
Dec 21 17:39:12 <DocScrutinizer51> sybren: so your problem seems to map AUX to the correct call to dim or lock the screen
Dec 21 17:40:18 <DocScrutinizer51> s/ms to map/ms to be mapping/
Dec 21 17:40:19 <apt> DocScrutinizer51 meant: sybren: so your problem seems to be mapping AUX to the correct call to dim or lock the screen
Dec 21 18:11:41 <TAsn> mrmoku, how's the phonelog going on?
Dec 21 18:11:50 * TAsn is so tired :(
Dec 21 18:12:17 <TAsn> all the moko deving I did in the last couple of days, is investigating a bug and studying opimd (not even writing anything) :(
Dec 21 18:17:18 <gena2x> ~logs
Dec 21 18:17:23 <apt> All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged.
Dec 21 18:51:25 <mrmoku> TAsn: I'm hanging with grouping... probably won't finish before 24th :|
Dec 21 18:51:50 <TAsn> :P that's ok.
Dec 21 19:25:34 <CIA-78> freesmartphone.org: 03mickey 07specs * rb757e73545c8 10/org.freesmartphone.Preferences/Makefile: disable preferences service as long as https://bugzilla.gnome.org/show_bug.cgi?id=602510 is open
Dec 21 19:31:06 <CIA-78> freesmartphone.org: 03mickey 07specs * r243b3e929ae4 10/xml/ (2 files): dito
Dec 21 19:48:45 <mrmoku> spaetzN800: guess I found why ssh takes that long for you :)
Dec 21 19:58:14 <TAsn> mrmoku, why?
Dec 21 19:58:23 <TAsn> (it also took a long time here, but it works now)
Dec 21 20:00:25 <mrmoku> TAsn: add 192.168.0.200 to /etc/hosts on the FR :P
Dec 21 20:00:29 <mrmoku> and it will be fast
Dec 21 20:00:44 <mrmoku> it works as long as it can resolve
Dec 21 20:00:49 <TAsn> on the FR?
Dec 21 20:00:52 <mrmoku> yup
Dec 21 20:01:08 <TAsn> why?
Dec 21 20:01:26 <TAsn> what for?
Dec 21 20:02:07 <mrmoku> #UseDNS yes
Dec 21 20:02:16 <mrmoku> to see if resolving the host name matches the ip
Dec 21 20:02:24 <TAsn> i c.
Dec 21 20:02:29 * mrmoku tries to turn it off
Dec 21 20:02:38 <TAsn> tries to reverse dns my ip?
Dec 21 20:02:59 <mrmoku> yup
Dec 21 20:03:00 <PaulFertser> mrmoku: _nice_ catch
Dec 21 20:03:12 <mrmoku> turning it off (and removing it from hosts) it is still fast :)
Dec 21 20:03:14 <mrmoku> PaulFertser: :)
Dec 21 20:03:24 <TAsn> mrmoku, so fix config :P
Dec 21 20:03:27 <TAsn> and yeah, nice catch.
Dec 21 20:03:57 <mrmoku> PaulFertser: in germany we say... even a blind chicken finds a corn from time to time... or something like that :P
Dec 21 20:04:27 <PaulFertser> mrmoku: come on, you're doing really good and it's not by pure chance :)
Dec 21 20:04:44 <mrmoku> PaulFertser: thanks :)
Dec 21 20:04:57 * mrmoku was just fishing for compliments :P
Dec 21 20:05:02 <TAsn> mrmoku, :P
Dec 21 20:05:12 <mrmoku> TAsn: I'm wondering what the better fix is?
Dec 21 20:05:21 <mrmoku> add 192.168.0.200 to /etc/hosts or turn it off
Dec 21 20:05:22 <TAsn> remove usedns from sshd
Dec 21 20:05:26 <TAsn> turn off.
Dec 21 20:05:46 <TAsn> you don't have to use 192.168.0.200
Dec 21 20:05:47 <TAsn> on the pc
Dec 21 20:05:50 <mrmoku> which is more work... but you're right
Dec 21 20:06:32 <TAsn> why more work?
Dec 21 20:07:11 <mrmoku> because we have no SHR custom config for sshd
Dec 21 20:07:18 <mrmoku> have to add one
Dec 21 20:07:24 <TAsn> i c.
Dec 21 20:07:30 <TAsn> that's a good idea anyway.
Dec 21 20:07:33 <TAsn> while you are at it.
Dec 21 20:07:47 <TAsn> allow empty password logins
Dec 21 20:07:57 <TAsn> or I don't know what :|
Dec 21 20:08:00 <mrmoku> huh
Dec 21 20:08:11 <TAsn> I mean, I also think it's a bad idea, but users disagree :|
Dec 21 20:08:21 <mrmoku> after 2 weeks of educating people that it is a bad idea?
Dec 21 20:08:35 <TAsn> hehe ok
Dec 21 20:08:38 <TAsn> so keep it :>
Dec 21 20:08:42 <TAsn> that's better.
Dec 21 20:10:39 * DocScrutinizer51 wonders if sshd even allows empty passwords at all
Dec 21 20:10:49 <mrmoku> DocScrutinizer51: you can configure that, yes
Dec 21 20:11:02 <DocScrutinizer51> anyway it's utterly nonsense
Dec 21 20:11:13 <DocScrutinizer51> use telnet then XD
Dec 21 20:12:29 <DocScrutinizer51> btw "empty pw" != "no pw"
Dec 21 20:13:06 <DocScrutinizer51> you still need to hit enter which essentially breaks piping anything into ssh
Dec 21 20:13:51 <mrmoku> DocScrutinizer51: no, sshd does not request you to enter an empty password
Dec 21 20:14:06 <DocScrutinizer51> so where is the rationale of having empty rather than default bassword. Like 0000 or password or 1234
Dec 21 20:16:28 <TAsn> DocScrutinizer51, laziness :P
Dec 21 20:16:44 <TAsn> slugos did an ugly hack to add a default password
Dec 21 20:16:46 <TAsn> so ugly :P
Dec 21 20:17:03 <TAsn> we should just force users to set a legit pass :P
Dec 21 20:18:38 <mwester> Very ugly. :)
Dec 21 20:18:59 <TAsn> here's the man to blame :P
Dec 21 20:19:39 <mwester> But SlugOS runs on a device with no console at all, so there's no alternative -- the GTA0x devices can at least force the user to enter a password on-screen as a last resort...
Dec 21 20:19:51 <TAsn> mwester, I agree.
Dec 21 20:20:05 <TAsn> mwester, I liked the comment there btw :P
Dec 21 20:20:33 <TAsn> "This isn't even slightly more secure than having no password at all, should change password as soon as possible"
Dec 21 20:20:35 <TAsn> :P
Dec 21 20:20:52 <mwester> Yeah, how many users do you think actually ever do that? :D
Dec 21 20:21:49 <TAsn> none, but thanks to them many of friends got jobs :P (as security experts)
Dec 21 20:54:22 <sybren> DocScrutinizer51: mapping AUX to dim/blank + lock sounds like exactly what I want :)
Dec 21 20:56:24 <sybren> DocScrutinizer51: can you give a hint as to where to find the right setting?
Dec 21 20:56:50 <DocScrutinizer51> sorry, no. Ask the SHR core devels
Dec 21 20:57:43 <DocScrutinizer51> sybren: at least I know it's feasible
Dec 21 20:58:19 <DocScrutinizer51> TAsn: ^ ?
Dec 21 20:58:24 <sybren> DocScrutinizer51: and that's a lot  :)
Dec 21 20:59:43 <DocScrutinizer51> sybren: tbh I don't even know what's linked to AUX atm
Dec 21 21:00:35 <sybren> DocScrutinizer51: phonefsod.conf contains "idle_screen = aux,lock", I'm fairly sure it has something to do with things
Dec 21 21:01:00 <DocScrutinizer51> yep
Dec 21 21:01:26 <sybren> but it doesn't contain "phone" on that line, and still my phone locks the screen during an active call... :(
Dec 21 21:03:21 <DocScrutinizer51> ouch
Dec 21 21:05:17 <DocScrutinizer51> that's probably heritage of the silly "we want screen dimming during caal - to save power" gang ;-P
Dec 21 21:05:50 <sybren> another thing, perhaps you guys know about this already - after booting the phone suspends before the booting process has finished, i.e. I have to keep it awake by fiddling with the screen just to get to the sim auth dialog
Dec 21 21:06:14 <sybren> DocScrutinizer51: dimming is fine by me, but locking costs CPU cycles hence doesn't save power
Dec 21 21:06:14 <lindi-> DocScrutinizer51: does not sound silly at all, surely it saves energy?
Dec 21 21:06:28 * DocScrutinizer51 really wonders how it can be so hard to get dim/suspend right
Dec 21 21:06:42 * sybren too
Dec 21 21:08:56 <mrmoku> sybren: aux,lock means you can turn on idle-screen (aka shr-today) with Aux press and it comes automatically by idle_lock state (from FSO)
Dec 21 21:09:36 <DocScrutinizer51> well. I really won't continue to argue about nonsense to deprive user from interface during call. that topic I'm done with
Dec 21 21:09:39 <mrmoku> it has nothing to do with dimming though
Dec 21 21:09:56 <mrmoku> DocScrutinizer51: ?
Dec 21 21:10:30 <mrmoku> DocScrutinizer51: you mean not turning on idle screen while having an active call?
Dec 21 21:10:52 <sybren> mrmoku: indeed
Dec 21 21:11:11 <mrmoku> there is another config option: phone
Dec 21 21:11:11 <DocScrutinizer51> esp not dimming/locking/overlaying the dialer during call
Dec 21 21:11:31 <TAsn> mrmoku, btw, did you figure the bug about lock screen disappearing when call comes up?
Dec 21 21:11:42 <TAsn> and what about listening to suspend signal to pop it as well? :P
Dec 21 21:11:44 <mrmoku> which is meant to explicitely turn it on for phone calls
Dec 21 21:11:47 <TAsn> both are giving me hell
Dec 21 21:11:54 <mrmoku> default should be off. if not that is a bug
Dec 21 21:11:55 <dos1> obviously i want screen to be dimmed during call
Dec 21 21:11:56 <mrmoku> TAsn: no
Dec 21 21:11:56 <TAsn> as I drive on my motorcycle and when I miss a call
Dec 21 21:12:00 <TAsn> I get mokomaze open :P
Dec 21 21:12:02 * mrmoku too
Dec 21 21:12:10 <TAsn> dos1, same here, but not everyone agree.
Dec 21 21:12:10 * mrmoku r
Dec 21 21:12:11 <mrmoku> b
Dec 21 21:12:14 <mrmoku> brb
Dec 21 21:12:42 <dos1> it's really simple to configure oeventsd to request Display resource during call
Dec 21 21:13:25 <sybren> dos1: and how difficult would it be to partially dim the screen (say to 20%) but not lock it?
Dec 21 21:13:42 <dos1> sybren: not difficult at all
Dec 21 21:14:00 <dos1> just remove "phone" from idle_screen option in phonefsod config
Dec 21 21:14:15 <sybren> dos1: see my point above: I have no "phone" there, but still the phone locks during calls
Dec 21 21:14:16 <DocScrutinizer51> dos1: enjoy your next phone bill when you forget t end a call (maybe you assumed far end did that) and place the dimmed device with active call on the table. idling and burning money there for hours
Dec 21 21:14:19 <dos1> AFAIK it's even not enabled by default
Dec 21 21:14:21 <TAsn> dos1, we really want to drop oevents :P
Dec 21 21:14:53 <dos1> DocScrutinizer51: i never had such problem, and all my phones were dimming screen during call
Dec 21 21:15:18 <DocScrutinizer51> tsss. which phones were that?
Dec 21 21:15:49 <DocScrutinizer51> bah. nevermind. I'm definitely thru with it
Dec 21 21:15:53 <TAsn> :P
Dec 21 21:15:58 <dos1> two nokias (3410 and 6230i), one motorola (c651)
Dec 21 21:16:06 <dos1> even my landline dimms screen during call
Dec 21 21:16:07 <dos1> :P
Dec 21 21:16:48 <dos1> and i never had problems with not ended call
Dec 21 21:16:51 <DocScrutinizer51> dos1: oh yeah I see. all were phones which show a black screen when dimming the backlight. all had no hw kbd
Dec 21 21:17:10 <DocScrutinizer51> please don't bother to answer
Dec 21 21:17:13 <dos1> but i has "problems" with neo getting too hot during ~1h call with screen not blanker ;p
Dec 21 21:17:33 <dos1> s/has/had/
Dec 21 21:17:33 <apt> dos1 meant: but i had "problems" with neo getting too hot during ~1h call with screen not blanker ;p
Dec 21 21:17:40 <dos1> s/blanker/blanked/
Dec 21 21:17:42 <apt> dos1 meant: but i has "problems" with neo getting too hot during ~1h call with screen not blanked ;p
Dec 21 21:19:04 <dos1> so maybe use led to indicate phone call? i'm strongly against not dimming screen
Dec 21 21:19:20 <DocScrutinizer51> dos1: there's not a single (!) report about a FR getting *too* hot
Dec 21 21:19:21 <dos1> it would be nice to have proximity sensor, like iPhone has...
Dec 21 21:19:43 <dos1> DocScrutinizer51: because screen dims during call ;P
Dec 21 21:20:07 <DocScrutinizer51> ff...... :-(
Dec 21 21:20:17 * DocScrutinizer51 away
Dec 21 21:20:23 <dos1> DocScrutinizer51: my experiences are from om2007.2, intensively hacked by me so i had almost always something broken ;P
Dec 21 21:20:41 <dos1> sometimes also screen dimming :P
Dec 21 21:21:49 <TAsn> DocScrutinizer51, define *too hot
Dec 21 21:22:45 <mrmoku> sybren: screen _locking_ without phone in config is a bug
Dec 21 21:22:51 <mrmoku> dimming is a different thing
Dec 21 21:24:52 <mrmoku> we might want to add another config option to not turn off the backlight while on call though
Dec 21 21:25:06 <mrmoku> or even to not dim at all
Dec 21 21:25:21 <DocScrutinizer51> TAsn: you bet *you* don't define it
Dec 21 21:25:31 <TAsn> I know :P
Dec 21 21:25:40 <TAsn> but I do define it for me
Dec 21 21:25:44 <TAsn> and dos defines it for him
Dec 21 21:25:47 <TAsn> and it gets too hot for us.
Dec 21 21:25:50 <TAsn> maybe not for the fcc
Dec 21 21:25:52 <TAsn> but for us.
Dec 21 21:26:17 <TAsn> anyhow, I'm off.
Dec 21 21:26:49 <sybren> mrmoku: I'll test it some time the next days, after a reboot so that I'm 100% sure that the config files have been loaded by the running daemons
Dec 21 21:27:00 * DocScrutinizer51 passes a burn curing medicine to TAsn and definitely leaves this nonsense debate
Dec 21 21:27:27 <mrmoku> sybren: it is very much possible that there is still a bug in phonefsod
Dec 21 21:27:53 <mrmoku> I do not test on-call behaviour that much... as calling myself costs money and I do not get many phone calls :P
Dec 21 21:28:21 <sybren> mrmoku: bugs are a reality in every bit of software ;-)
Dec 21 21:28:34 <mrmoku> unfortunately yes :|
Dec 21 21:28:44 <lindi-> mrmoku: calls don't cost if you don't answe them?
Dec 21 21:28:56 <sybren> lindi-: but that hardly lets you test in-call behaviour
Dec 21 21:29:08 <mrmoku> lindi-: don't know if it is ringing long enough to test if it idle_locks though
Dec 21 21:29:48 <sybren> right, time to hit the sack
Dec 21 21:30:03 <mrmoku> sybren: I will see if I can test a bit tomorrow...
Dec 21 21:30:07 * mrmoku into the sack to
Dec 21 21:30:12 <mrmoku> gnight all
Dec 21 21:30:19 <sybren> sleep tight, don't let the phonefsod bug bite ;-)
Dec 21 21:37:47 <spaetzN800> mrmoku|away, nicee sshd catch
Dec 21 21:38:11 <spaetzN800> and having our custom config file should be fine...
Dec 21 21:38:22 <spaetzN800> night
Dec 21 21:44:30 <gnutoo_> hi:     $ blipomoko => import blipapi=>ImportError: No module named blipapi => and opkg list | grep blip finds only blipmoko
Dec 21 21:56:40 * lindi- found a reproducible way to crash andy-tracking kernel :)
Dec 21 21:59:24 <spaetzN800> lindi-, use it? :-pp
Dec 21 22:04:18 <gnutoo_> btw another thing...there is no eglibc-dev 
Dec 21 22:04:24 <gnutoo_> so no libc_nonshared.a
Dec 21 22:04:31 <gnutoo_> so not possible to compile on the device
Dec 21 22:04:34 <gnutoo_> is it normal?
Dec 21 22:15:17 <gnutoo_> hi, is there a very unstable feed with this fix: 237917b03120fbd49a5bcb9967dce8ae815cdf5d ?
Dec 21 22:31:19 <daniele_athome> JaMa, hi
Dec 21 22:31:22 <daniele_athome> no way for freetype...
Dec 21 22:31:35 <daniele_athome> how could shr guys compile it?
Dec 21 22:32:35 <larsc> btw.: for anyone interested in experimental software: i pushed 2.6.32 branches of the openmoko kernel earlier today
Dec 21 22:33:36 <gena2x> larsc: where?
Dec 21 22:34:04 <gena2x> larsc: I mean it's in git?
Dec 21 22:34:39 <larsc> gena2x: http://git.openmoko.org/?p=kernel.git;a=summary
Dec 21 22:35:41 <gena2x> larsc:ok, found it...
Dec 21 22:36:06 <gena2x> larsc I wanted to try logfs
Dec 21 23:40:12 <JaMa> daniele_athome: stamps/armv4t-oe-linux-gnueabi/freetype-2.3.6-r0.do_build compiled fine here..
Dec 21 23:40:28 <JaMa> daniele_athome: if you want logs from successfull build for compare..
Dec 21 23:40:49 <JaMa> larsc: thanks, I'll try tomorrow
Dec 21 23:41:01 <daniele_athome> JaMa, please :)
Dec 21 23:41:25 <daniele_athome> JaMa, anyway I succeded to compile by doing some "manual tricks"
Dec 21 23:41:35 <daniele_athome> like modifying a some makefiles and copying some files
Dec 21 23:41:54 <daniele_athome> but I'll be glad to know how to fix this the usual way
Dec 21 23:41:58 <JaMa> daniele_athome: freetype-native compiled fine for you?
Dec 21 23:42:10 <daniele_athome> JaMa, yes but with my modifications
Dec 21 23:42:15 <daniele_athome> as I said.
Dec 21 23:42:55 <JaMa> daniele_athome: I didn't remember if it failed for you just for freetype or freetype-native or both
Dec 21 23:43:07 <daniele_athome> freetype-native
Dec 21 23:43:12 <daniele_athome> didn't try freetype
Dec 21 23:44:24 <JaMa> mmt rebuilding and then sleep()
Dec 21 23:44:40 <daniele_athome> ok
Dec 21 23:45:08 <pbaxter> daniele_athome: pvt
Dec 21 23:46:34 <JaMa> daniele_athome: http://jama.homelinux.org/org.openembedded.shr/freetype-native-2.3.6-r0.workdir.tar.gz
Dec 21 23:49:25 <daniele_athome> JaMa, thank
Dec 21 23:49:40 <daniele_athome> downloading
Dec 22 01:49:23 <prahal> hi where is autoreconf in SHR ?
Dec 22 01:49:48 <prahal> if one want to built on the freerunner (small application )
Dec 22 01:52:03 <pieterc> prahal: what app?
Dec 22 01:52:13 <prahal> eve
Dec 22 01:52:30 <prahal> and exhibit ... they still rely on old e libs 
Dec 22 01:54:25 <prahal> but there is no package description and no configure inside , only autogen.sh and  configure.ac
Dec 22 01:54:38 <prahal> inside the source package that is
Dec 22 01:57:39 <prahal> bah I ll cross compile in my emdebian toolchain as I don't have (room for) the shr one
Dec 22 01:57:44 <prahal> yet
Dec 22 01:58:22 <prahal> agh my lib won't match :-/
Dec 22 02:25:02 <prahal> ok I got the recipe ... now the issue is that I cannot tell from bug reports and ml if the om toolchain is valid for shr-unstable
**** ENDING LOGGING AT Tue Dec 22 02:59:56 2009