**** BEGIN LOGGING AT Sun May 09 02:59:56 2010
May 09 04:58:52 <PaulFertser> mrmoku|away: what dbus proxy are you using, Gabriel?
May 09 05:56:03 <PaulFertser> mickey|away: now after i've received the second call while already talking on the first, i started to understand the frustration about that part of FSO API...
May 09 05:56:38 <PaulFertser> mickey|away: i know GSM sucks and you basically just expose what it provides. And it's unfun.
May 09 05:56:52 <PaulFertser> Moreover, it doesn't work :(
May 09 06:00:09 <PaulFertser> mickey|away: looks like oeventsd doesn't understand the fact CallStatus() belongs to another call and so untriggers SetScenario(gsmhandset).
May 09 06:02:00 <PaulFertser> mickey|away: from a UI pov it's also unclear what to do after i received a signal that some call is "RELEASED", should i simply forget about the call, or should i store somewhere the reason? But it'll be overwritten because it reuses ids... All that doesn't make much sense.
May 09 06:02:30 <PaulFertser> And anyway, i wasn't able to talk to neither peer after i received the second call.
May 09 06:02:55 <PaulFertser> mickey|away: what bothers me is why the first call was put on hold automatically just after i received the second?
May 09 06:16:06 <PaulFertser> JaMa: hey :) Not meaning to push you but what about getting emacs23 in the feeds, is it too hard? ;)
May 09 07:11:43 <JaMa> PaulFertser: starting the build, if it compiles fine (IIRC last time it failed) then it will be in feeds today emacs-23.1
May 09 07:52:34 <mrmoku> PaulFertser: dbus-daemon-proxy
May 09 07:53:02 <mrmoku> PaulFertser: git://git.collabora.co.uk/git/user/alban/dbus-daemon-proxy
May 09 07:54:29 <mrmoku> PaulFertser: and I really fell in love with it :)
May 09 08:20:13 <mrmoku> mickey|away: duh... the extra debug goes to stdout and not the logfile ;)
May 09 09:02:37 <McKael> Hi!
May 09 09:02:52 <McKael> I've just rebooted and the touchscreen doesn't react anymore
May 09 09:03:09 <McKael> Have you seen seen before?
May 09 09:07:24 <misc> on debian, i think i did, yes 
May 09 09:07:33 <misc> but I didn't know how i solved it 
May 09 09:08:23 <McKael> According to X logs, the touchscreen is still detected
May 09 09:09:03 <McKael> Uh.  xserver was upgraded yesterday!
May 09 09:19:15 <lindi-> McKael: debian?
May 09 09:19:24 <McKael> lindi-, yes
May 09 09:19:33 <lindi-> McKael: xorg.conf? ps axuf?
May 09 09:19:37 <lindi-> McKael: Xorg.0.log?
May 09 09:19:42 <McKael> wrong channel, I guess :)
May 09 10:15:07 <\marco> hi to all
May 09 10:17:14 <\marco> I've lastest shr-u and I've noticed that after manual suspend ( since the know xorg vt problem ) the phone keeps waking after a while
May 09 10:17:25 <\marco> any hint or logfile to check?
May 09 10:39:57 <\marco> maybe is it related to gsm registration?
May 09 10:40:50 <lindi-> \marco: what's resume reason?
May 09 10:41:37 <\marco> link: I can't see ant reason :/
May 09 10:41:39 <\marco> oops
May 09 10:41:44 <\marco> lindi-, 
May 09 10:41:56 <\marco> *any
May 09 10:42:28 <\marco> which log file I've to check?
May 09 10:42:51 <lindi-> \marco: "om resume-reason" is a command to see it, not sure if it is in shr
May 09 10:43:02 <Bane^> \marco, /var/log/fsousaged.log tells the resume reason 
May 09 10:43:05 <Bane^> I think
May 09 10:43:06 <lindi-> \marco: alternatively you can look for resume_reason files in /sys if you know
May 09 10:43:18 <\marco> oh good to know
May 09 10:43:19 <\marco> let me check
May 09 10:45:35 <\marco> Indeed:  UsageController <9 R>: Resume reason seems to be FSO_USAGE_RESUME_REASON_GSM
May 09 10:45:36 <mrmoku> \marco: was it already registered when you suspended?
May 09 10:45:39 <\marco> !!
May 09 10:45:52 <\marco> mrmoku, yes, it is
May 09 10:46:15 <lindi-> \marco: what did GSM say?
May 09 10:46:37 <\marco> lindi-, GSM?
May 09 10:46:48 <\marco> where=
May 09 10:46:51 <\marco> where?
May 09 10:47:02 <\marco> frameworkd?
May 09 10:47:05 <\marco> or fsogsm?
May 09 10:47:39 <lindi-> \marco: you talk to gsm chip over a serial line
May 09 10:47:57 <\marco> mhm fsogsm says: libfsotransport <0710:4>: URC: [ "+CMS ERROR: 322" ]
May 09 10:48:15 <\marco> TiCalypsoModem <4C>: No handler for URC +CMS ERROR w/ rhs 3
May 09 10:48:15 <\marco> 22, please report to Mickey <smartphones-userland@linuxtogo.org>
May 09 10:48:45 <\marco> TiCalypsoModem <4C>: Modem Status changed to FSO_GSM_MODEM_
May 09 10:48:46 <\marco> STATUS_RESUMING
May 09 10:50:45 <\marco> it seems the resume reason
May 09 10:52:54 <\marco> lindi-, any idea?
May 09 10:54:00 <lindi-> \marco: the gsm woke the phone up just to say CMS ERROR: 322?
May 09 10:54:17 <lindi-> \marco: have you checked what 322 means?
May 09 10:54:39 <\marco> mhm no where I've to look at?
May 09 10:55:06 <lindi-> just google for  cms error 322
May 09 10:55:08 <\marco> is there an error code list? I don't know :)
May 09 10:55:11 <\marco> oh ok
May 09 10:55:19 <\marco> ( it's a surprise? :D )
May 09 10:56:26 <\marco> LOOOL
May 09 10:56:34 <\marco> sorry :)
May 09 10:56:49 <\marco> memory full!
May 09 11:01:45 <\marco> in previous shr-release there was a pop-up for memory-full, where's now?
May 09 11:09:01 <\marco> mhm... I've used mdbus to delete messages some times ago , what I've to use now?
May 09 11:09:11 <\marco> sorry to bother :)
May 09 11:11:17 <\marco> ( in the message-ui I've no message but they are on SIM, I suppose)
May 09 11:47:50 <mickey|away> mrmoku: i can't see any obvious problems, but please try with the next commit
May 09 11:48:31 <mrmoku> morphis: any news? I'm wondering if it does not work because it needs rw on start
May 09 11:48:40 <mrmoku> mickey|away: ok
May 09 11:48:52 <CIA-36> freesmartphone.org: 03mickey 07cornucopia * r7364f17bd92c 10/fsogsmd/src/lib/atpdp.vala: 
May 09 11:48:52 <CIA-36> freesmartphone.org: fsogsmd: ppp: deactivate context via AT command rather than killing ppp
May 09 11:48:52 <CIA-36> freesmartphone.org: LCP should then terminate due to the modem
May 09 11:49:25 <mrmoku> when bsck home :)
May 09 11:52:17 <morphis> mrmoku: hm, I am doing a 'mount -o remount,rw /' 
May 09 11:56:29 <mrmoku> morphis: i mean even before
May 09 11:57:09 <morphis> hm
May 09 11:57:25 <mrmoku> k
May 09 11:58:01 <morphis> but why should be have / mounted rw before fsoinitd has started?
May 09 12:00:01 <[Rui]> I'm supposed to have received an SMS by now, is there a way I can force a check for SMS, or is it always (and only) a push from the operator?
May 09 12:00:11 <CIA-36> freesmartphone.org: 03mickey 07cornucopia * r53cedaf25c29 10/fsogsmd/ (4 files in 3 dirs): fsogsmd: add default configuration for singleline modem as starting point
May 09 12:00:12 <CIA-36> freesmartphone.org: 03mickey 07cornucopia * r9009482db673 10/fsogsmd/src/lib/modem.vala: fsogsmd: modem: prepare for configuring whether SMS handling works direct or buffered
May 09 12:00:20 <lindi-> morphis: you are writing your own init now?
May 09 12:00:29 <dos1> [Rui]: check if you have free slots on SIM
May 09 12:00:37 <morphis> lindi-: jepp, a fsoinitd
May 09 12:01:03 <dos1> mickey|away: hmm? "prepare for configuring whether SMS handling works direct or buffered" -> pushing to opimd?
May 09 12:01:43 <lindi-> morphis: is the goal to have it in other distros as well, fedora, debian, ubuntu?
May 09 12:02:18 <morphis> lindi-: it should be a embedded-only init-replacement
May 09 12:02:43 <morphis> nothing big like systemd or upstart
May 09 12:03:25 <mickey|away> dos1: no, that's the 2nd step. first step is how the SMS arrives at all
May 09 12:03:31 <morphis> intention ist: keep everything as small as possible, just start what we actually need (dbus, network, fs, x)
May 09 12:03:46 <lindi-> morphis: doesn't busybox already have a tiny init?
May 09 12:04:22 <dos1> mickey|away: yup, i just was curious if what i saw was that first step ;)
May 09 12:04:25 <morphis> thats what you are using on most embedded platforms
May 09 12:04:36 <morphis> but, we don't need that
May 09 12:05:01 <lindi-> it's not custom enough? ;)
May 09 12:05:02 <morphis> we have the Usage-API to do things like reboot/shutdown/suspend/resume why not have them directly within the init-process?
May 09 12:05:56 <[Rui]> dos1: it's supposed to use opimd
May 09 12:06:00 <lindi-> morphis: surely possible but takes you quite far from a typical gnu/linux system
May 09 12:06:33 <morphis> hm, you just replace this /etc/init.d thing
May 09 12:06:46 <morphis> you just have a reboot/shutdown command like everywhere else
May 09 12:07:05 <lindi-> morphis: and no manual pages for all this? ;)
May 09 12:07:38 <morphis> manual pages,for fsoinitd? I am sure, we will have one, one day .... :)
May 09 12:08:00 <lindi-> i wouldn't be so sure :)
May 09 12:08:29 <morphis> you don't define your machine configuration in /etc/init.d scripts, you do that within fsoinitd
May 09 12:09:03 <morphis> in the end you will have very small init process which starts up in some seconds
May 09 12:09:13 <morphis> and everything you need is already there
May 09 12:09:33 <lindi-> morphis: but if I want to customize it i need to recompile fsoinitd?
May 09 12:10:23 <morphis> what do you want to costomize? this is the question you have to ask first
May 09 12:11:24 <morphis> just launch another daemon?
May 09 12:11:30 <lindi-> morphis: configure what vts are going to run getty
May 09 12:11:51 <morphis> ok, thats one thing you have to do within fsoinitd one time
May 09 12:12:32 <lindi-> morphis: any idea if fso-gsmd is going to require this new init any time soon?
May 09 12:12:54 <morphis> no, you should use FSO without fsoinitd
May 09 12:13:02 <morphis> äh can use
May 09 12:13:35 <morphis> fsoinitd will be merged with fsousaged in the next time, but you should have the option to compile it without fsoinitd-support
May 09 12:13:37 <lindi-> maybe it's the fso name that confused me
May 09 12:13:43 <morphis> so you can every other init-system
May 09 12:13:51 <morphis> :)
May 09 12:13:55 <lindi-> project, distro and software should have a different name :)
May 09 12:14:29 <morphis> read this one: http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=tools/fso-boot/README;h=7840dac5949e77ef0fd933a70cebc1c1e905bf89;hb=HEAD
May 09 12:16:04 <lindi-> sounds like android
May 09 12:17:20 <morphis> android is much more :)
May 09 12:17:42 <morphis> android does static device file configuration
May 09 12:17:49 <morphis> this is something we would never do
May 09 12:59:40 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * ra50ca354a71f 10/fsoinitd/src/ (configurations/palmpre.vala setuphostnameaction.vala): fsoinitd: fix getty parameters in palmpre configuration
May 09 12:59:40 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * rf0b454871689 10/fsoinitd/src/main.vala: fsoinitd: check on startup wether we are running as real init or not
May 09 12:59:40 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * re634114d04b6 10/fsoinitd/src/configurations/palmpre.vala: fsoinitd: fix path for mount command in palmpre configuration
May 09 12:59:41 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * rf973ef578aae 10/fsogsmd/ (12 files in 7 dirs): Merge branch 'master' of ssh://git.freesmartphone.org/cornucopia
May 09 13:36:43 <mickey|away> drumroll...
May 09 13:36:50 <CIA-36> freesmartphone.org: 03mickey 07cornucopia * redb261f3a84f 10/fsogsmd/ (10 files in 3 dirs): 
May 09 13:36:50 <CIA-36> freesmartphone.org: fsogsmd: due to popular demand (*cough*), here comes direct delivery of SMS
May 09 13:36:50 <CIA-36> freesmartphone.org: without touching the SIM
May 09 13:42:48 <Kensan> mickey|away: hehe nice one. PaulFertser will be pleased ;)
May 09 13:49:30 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * r2c15e213d702 10/libfsobasics/fsobasics/logger.vala: libfsobasics: implement basic kmsg logger
May 09 13:49:31 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * ra840eb33aaab 10/fsogsmd/ (10 files in 3 dirs): Merge branch 'master' of ssh://git.freesmartphone.org/cornucopia
May 09 13:59:07 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * r2914a2ea4eb3 10/libfsobasics/tests/ (.testlogger.ini testlogger.vala): libfsobasics: add tests for kmsg logger
May 09 13:59:08 <CIA-36> freesmartphone.org: 03morphis 07cornucopia * r20acc3db16a5 10/libfsobasics/tests/testlogger.vala: libfsobasics: there is not destination for kmsg logger
May 09 14:28:44 <\marco> I need to delete messages from sim, which program I've to use? mdbus seems disappeared :/
May 09 14:29:13 <pespin> \marco, try installing/using mdbus2 ;)
May 09 14:29:17 <\marco> LOL
May 09 14:29:47 <\marco> I thought it was installed by default
May 09 14:30:01 <\marco> thank you pespin :)
May 09 14:30:51 <mrmoku> mickey|away: yay... works :D
May 09 14:40:02 <\marco> mhm the dbus path is changed.. is there a simple way to browse dbus services? I need to retrieve Messagebook from sim
May 09 14:41:26 <\marco> ( today I'm really annoying )
May 09 14:41:34 <\marco> :)
May 09 14:42:08 <dos1> \marco: mdbus2 -s -i
May 09 14:42:09 <\marco> found it
May 09 14:42:16 <\marco> dos1, thank you :)
May 09 14:42:26 <dos1> and use tab autocompletion ;)
May 09 14:42:27 <\marco> I'm just reading the openmoko wiki page
May 09 14:42:46 <\marco> is there tab autocompletion????? 
May 09 14:42:51 <\marco> good :)
May 09 14:45:50 <Q-Master> mrmoku:  [ 3429.000000] Alignment trap: enlightenment (840) PC=0x402a6306 Instr=0x6027 Address=0xbea828a7 FSR 0x813
May 09 14:45:56 <Q-Master> ?
May 09 14:46:25 <raster> ooh thats no good
May 09 14:46:38 <raster> whats the bt?
May 09 14:47:27 <Q-Master> raster: sorry, that was from dmesg
May 09 14:48:04 <raster> cant be fixed without a backtrace
May 09 14:48:07 <raster> ie disable kernel fixups
May 09 14:48:08 <\marco> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.SIM.RetrieveMessage all returns me only one message. But if I substitute 1 or 2 to "all" my messages are there... what's wrong?
May 09 14:48:13 <raster> and thus force a sibgus
May 09 14:48:22 <raster> and gdb attach and get bt when that happens
May 09 14:49:10 <\marco> mhm ok.. wrong method
May 09 14:54:29 <mrmoku> raster: we have those quite frequently :/
May 09 14:55:43 <mrmoku> raster: send backtraces for that to e-devel?
May 09 15:01:03 <\marco> the battery gadget isn't part of shr-e-gadget?
May 09 15:04:41 <raster> mrmoku: yeah. send them. if we have a bt (line numbers please from src files - not just func calls)
May 09 15:04:44 <raster> we'll find and fix
May 09 15:08:29 <mrmoku> raster: yeah... line numbers... will give me a hard time with OE :P
May 09 15:08:51 <mrmoku> \marco: no
May 09 15:10:01 <\marco> mrmoku, just curious about the little bug of the gadget :) is there already a fix?
May 09 15:10:06 <mrmoku> no
May 09 15:10:22 <mrmoku> at least nothing I would know of
May 09 15:10:40 <\marco> oh :( 
May 09 15:10:40 <lindi-> bug report url?
May 09 15:11:18 <\marco> lindi-, about the battery gadget?
May 09 15:12:16 <lindi-> \marco: hard to say, what bug were you talking about?
May 09 15:13:04 <\marco> lindi-, :D sorry.. The battery gadget is always blank
May 09 15:13:17 <lindi-> \marco: some ui thing?
May 09 15:13:36 <\marco> I don't know :/
May 09 15:13:55 <\marco> with shr-settings I can see the battery status
May 09 15:14:19 <\marco> so it's a problem with the gadget, I suppose
May 09 15:16:38 <\marco> mhm It seems there's no ticket about this ( or I can't find it :P )
May 09 15:18:34 <lindi-> \marco: gadget?
May 09 15:18:48 <lindi-> \marco: create a ticket and maybe i'll understand what you are talking about
May 09 15:18:59 <\marco> lindi-, the battery gadget.. in the shelf
May 09 15:19:24 <mrmoku> lindi-: he's talking about the enlightenment battery gadget
May 09 15:19:30 <\marco> :D
May 09 15:19:42 <raster> works on laptop here
May 09 15:19:47 <mrmoku> raster: sure :)
May 09 15:20:13 <lindi-> i thought he was talking about some usb gadget that implements the battery charging spec
May 09 15:20:18 <mrmoku> raster: since latest EFL bump it started to always show empty battery on FR though
May 09 15:20:20 <raster> in autodetect mode
May 09 15:20:28 <raster> hal is the base subsyetem being used
May 09 15:20:34 <\marco> lindi-, oops.. sorry I wasn't clear
May 09 15:21:47 <mrmoku> raster: we should just do our own using FSO's API... and we would get rid of the batget process too :)
May 09 15:22:02 <raster> batget wont start if hal works
May 09 15:22:11 <raster> or if u explicitly say "hal only"
May 09 15:22:34 <raster> (internal == batget)
May 09 15:22:40 <mrmoku> yep
May 09 15:22:45 <raster> batget hasnt changed in ages
May 09 15:22:52 <\marco> what method use shr-settings?
May 09 15:24:12 <raster> as for fso - why? u have hal there
May 09 15:24:14 * \marco would help.. so, building shr in progress :)
May 09 15:24:15 <raster> it does it already
May 09 15:24:29 <raster> if u ditch hal - ua re going to udev/udisks/upower etc. anyway
May 09 15:24:41 <mrmoku> raster: we want to get rid of hal, yes
May 09 15:24:43 <raster> unless of course you love inventing your own ways of doing the exact same thing
May 09 15:24:52 <mrmoku> and hal does not even show the correct percentage
May 09 15:25:36 <mrmoku> gives me 19% when the battery is about 80%
May 09 15:26:24 <mrmoku> IIRC problem was hal seeing more than one battery...
May 09 15:26:35 <raster> thats what i remember
May 09 15:26:42 <raster> and 2 of the batteries are "empty"
May 09 15:26:46 <raster> for some reason
May 09 15:26:56 <raster> so in gthe end e shows 33% battery full
May 09 15:27:01 <raster> when u are actually at 100%
May 09 15:27:01 <\marco> ( after make setup: "fatal: git checkout: branch org.openembedded.dev already exists"  . I'm following the "Building SHR" wiki page)
May 09 15:27:13 <mrmoku> yep
May 09 15:27:20 <raster> as e is averaging all battery % fulls it sees
May 09 15:27:57 <raster> thats from memory (and thats generally correct - well if u have batteries with vastly different capacities, it's wrong - but thats not generally the case)
May 09 15:28:08 <raster> anyway
May 09 15:29:15 <mrmoku> raster: btw. we want to ditch udev too ;)
May 09 15:29:40 <raster> imho - not smart
May 09 15:29:48 <mrmoku> we need all computing powers for our graphics chip :P
May 09 15:29:54 <raster> as all you do is make yourselves less and less compatible with existing desktop
May 09 15:30:12 <raster> i doubt udev matters in the compute power dept
May 09 15:30:14 <raster> :)
May 09 15:30:24 <mrmoku> yeah... more boot time dept
May 09 15:30:50 <\marco> ( ok make setup done. ( was a network error ) )
May 09 15:30:53 <raster> yeah
May 09 15:30:58 <raster> it will impact boot - sure
May 09 15:31:14 <mrmoku> and now that there is devtmpfs...
May 09 15:31:22 <mrmoku> tempting to try that :)
May 09 15:32:36 <raster> but be realistic
May 09 15:32:38 <raster> its a phone
May 09 15:32:55 <raster> how often do u boot it (unless of course its so buggy that it crashes so often u need to reboot so much :))
May 09 15:33:13 <raster> shaving a few seconds off boot... is it worth diverging from desktop/laptop support?
May 09 15:33:33 <\marco> in shr-unstable/conf/local.conf the guide says that  OE_ALLOW_INSECURE_DOWNLOADS=1 is there by default. But I don't have that var. I've to add it? or the guide needs to be updated?
May 09 15:34:41 <\marco> on that point, IMHO I think I agree with raster
May 09 15:34:53 <mrmoku> raster: hmm... how many parts of the desktop have to directly handle with udev?
May 09 15:35:30 <raster> udev is a more minimal hal
May 09 15:35:33 <raster> its split
May 09 15:35:36 <raster> u have udisks and upower too
May 09 15:35:48 <raster> u can possibly drop udisks as u dont need removable storage
May 09 15:36:06 <raster> unless u cound opening back case of phone, battery etc. ot get sd card in and out as "removable"
May 09 15:36:11 <raster> (at runtime)
May 09 15:37:08 <Kensan> raster: I had a Samsung phone on which you could hotplug a microsd card while the phone was running.
May 09 15:37:12 <Kensan> raster: hi btw :)
May 09 15:37:21 <raster> Kensan:  i know. talking of freerunner
May 09 15:37:24 <raster> :)
May 09 15:37:37 <Kensan> raster: but there's probably just one or two of these phones...
May 09 15:37:39 <raster> nigh anythign else is going to be much more powerful
May 09 15:38:01 <raster> so really.. does it matter if uit is all udev/udisks/upower etc. etc.
May 09 15:38:06 <Kensan> isn't devkit et al supposed to replace hal?
May 09 15:38:08 <mrmoku> what is upower?
May 09 15:38:18 <raster> devkit is dead
May 09 15:38:36 <raster> the bitd of devkit that did disks/power became udiss/upower etc.
May 09 15:38:54 <Kensan> right
May 09 15:39:30 <Kensan> I just remembered that hal was getting dropped. I am too slow to keep up with the changes *heh*
May 09 15:40:06 <mrmoku> raster: so the battery gadget will support upower some day I guess
May 09 15:40:12 <mrmoku> but what do we do until then?
May 09 15:40:57 <mrmoku> mickeyl: works great thanks :)
May 09 15:41:19 <raster> it already does
May 09 15:41:23 <mrmoku> well... did not yet stress test it ;) but second ContextActivate works now
May 09 15:41:37 <mrmoku> raster: ahh, because configuration gives me only internal or hal
May 09 15:42:11 <mickeyl> mrmoku: glad to hear
May 09 15:42:28 <mickeyl> mrmoku: it's still a bit strange why it works without explicit deactivation here, but oh well
May 09 15:42:30 <\marco> sorry to bother again :P Is possible to run shr-image with qemu? I know that it wasn't possible some times ago
May 09 15:42:38 <mickeyl> stopped thinking much about calypso mysteries
May 09 15:42:42 <mrmoku> :)
May 09 15:42:44 <raster> hall = upower for it
May 09 15:42:49 <raster> ui hasnt beeen .. updated
May 09 15:42:54 <mrmoku> oh ok
May 09 16:19:36 <GNUtoo> hi
May 09 16:20:11 <GNUtoo> I've sysrq on serial console and on the screen while using the power adapter+the debug board
May 09 16:22:36 <GNUtoo> mickeyl, hi any news ? btw is there something quick and easy to work on? gps? look if there are newer compat-wireless?
May 09 16:22:50 <GNUtoo> news about htcdream,gta02,or palm pre
May 09 16:25:07 <GNUtoo> hi Kayin 
May 09 16:25:08 <GNUtoo> oops
May 09 16:25:10 <GNUtoo> hi Kensan 
May 09 16:27:18 <mickeyl> hi GNUtoo, no news here, the little time that i have i did spend with Calypsoisms. Quick and easy might be looking into Bluetooth, which has still status 'not working'
May 09 16:27:39 <GNUtoo> ah but you already tried hard
May 09 16:27:52 <GNUtoo> and it's not very important right(I never used bluetooth)
May 09 16:28:09 <mickeyl> well
May 09 16:28:12 <GNUtoo> but maybe it could be used for tethering
May 09 16:28:15 <mickeyl> yeah
May 09 16:28:18 <mickeyl> since Ad-hoc mode is broken as well
May 09 16:28:23 <GNUtoo> ok
May 09 16:28:26 <mickeyl> we need any way to tether
May 09 16:28:32 <mickeyl> (wireless)
May 09 16:28:37 <mickeyl> i would prefer wifi
May 09 16:28:38 <GNUtoo> ok
May 09 16:28:41 <GNUtoo> me too
May 09 16:28:54 <GNUtoo> maybe I'll try to see if there are newer compat-wireless
May 09 16:28:56 <mickeyl> but it looks like the wl1251 in mainline has no ad-hoc mode
May 09 16:29:05 <GNUtoo> indeed
May 09 16:29:22 <mickeyl> the latest compat-wireless for 2.6.32 works fine, the latest at all did not work 
May 09 16:29:27 <GNUtoo> but I heard that the ti driver is even hard to compile
May 09 16:29:35 <mickeyl> after 2.6.32 they introduced their own firmware loader which doesn't work with our stuff
May 09 16:29:40 <GNUtoo> which version works?
May 09 16:29:44 <mickeyl> 2.6.32.x
May 09 16:29:47 <mickeyl> latest one
May 09 16:29:47 <GNUtoo> and which version doesn't
May 09 16:29:52 <mickeyl> 2.6.34 or 33
May 09 16:29:53 <GNUtoo> no compat-wireless
May 09 16:29:54 <mickeyl> can't remember
May 09 16:29:58 <GNUtoo> ok
May 09 16:29:59 <mickeyl> yes, compat-wireless
May 09 16:30:01 <GNUtoo> I'll look
May 09 16:30:20 <GNUtoo> but this one worked if you disabled PSM:
May 09 16:30:41 <GNUtoo> compat-wireless-2010-04-26
May 09 16:30:42 <mickeyl> http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.11.tar.bz2 works fine
May 09 16:30:57 <GNUtoo> I've open pandora patches on top of it
May 09 16:31:04 <GNUtoo> ah this one
May 09 16:31:12 <GNUtoo> is it really a compat wireless?
May 09 16:31:16 <GNUtoo> or a full kenrel tree
May 09 16:31:34 <GNUtoo> mine is a compat-wireless
May 09 16:32:19 <mickeyl> compat-wireless
May 09 16:32:43 <mickeyl> they have different types of releases
May 09 16:32:52 <mickeyl> stable and daily
May 09 16:33:04 <mickeyl> stable are IMO preferred as they received more testing
May 09 16:33:51 <GNUtoo> ok
May 09 16:33:57 <GNUtoo> I didn't know and used daily
May 09 16:34:08 <GNUtoo> I'll try with lastest daily + pandora patches
May 09 16:36:25 <mickeyl> ok
May 09 16:36:41 <mickeyl> the TIWLan thing sucks
May 09 16:36:56 <mickeyl> it comes with a complete own stack :/
May 09 16:37:06 <mickeyl> so i would only go there as last resort, if all else fails
May 09 16:41:19 <GNUtoo> ok
May 09 16:41:35 <GNUtoo> note that pandora guys have the same wifi chip and are working on it too
May 09 16:41:41 <GNUtoo> s/guys/people
May 09 16:43:17 <mickeyl> right
May 09 16:46:18 <mickeyl> what's the status of GPS after all your tests w/ phh?
May 09 16:47:53 <GNUtoo> I asked him to test more and he said:
May 09 16:48:07 <GNUtoo> <GNUtoo> any gps test?
May 09 16:48:07 <GNUtoo> <phh> pffff
May 09 16:48:07 <GNUtoo> <phh> no
May 09 16:55:05 <mickeyl> heh, k
May 09 17:04:02 <GNUtoo> mickeyl, btw I don't remember well but there were issues with fb driver,what were they? and can I return to before the FBIOBLANK ioctls?
May 09 17:14:20 <PaulFertser> mickeyl: hey :)
May 09 17:14:39 <mickeyl> GNUtoo: i don't remember any issues. fb worked fine for me
May 09 17:14:55 <mickeyl> GNUtoo: i don't see any reason to revert those patches
May 09 17:14:56 <PaulFertser> mickeyl: do you want libfsotranport DEBUG log for the case when i was talking and somebody else called me and the first call was put on hold without my intervention?
May 09 17:15:03 <GNUtoo> ok,maybe some kenrel crash
May 09 17:15:04 <mickeyl> PaulFertser: yes
May 09 17:15:19 <GNUtoo> I'll try newer changes then
May 09 17:15:39 <mickeyl> PaulFertser: fsogsmd does not put calls on hold on its own, so I'm curious to see what is happening there
May 09 17:15:45 <PaulFertser> mickeyl: ok, will provide you with it soon.
May 09 17:16:13 <PaulFertser> mickeyl: and i have a problem with multiple call handling in general. I think oeventsd can't manage it properly or the default config is very wrong.
May 09 17:16:50 <PaulFertser> mickeyl: also i can now tell for sure that low-level very much GSM-specs api is uncool and that i understand the frustration about it others expressed.
May 09 17:16:58 <mickeyl> hehe
May 09 17:17:01 <GNUtoo> maybe kernel crash when xorg quits
May 09 17:17:24 <PaulFertser> mickeyl: because i do not understand how to make a nice ui for it. I.e. i have no idea what to do about "RELEASED" calls. Should i just forget about them immediately?
May 09 17:17:32 <TAsn> [Rui], ping
May 09 17:17:41 <[Rui]> TAsn: pong?
May 09 17:17:59 <TAsn> [Rui], do you follow the israeli news? (what made me ask: http://scap.linuxtogo.org/files/092081e760ebcb494d0871c9c52175ef.png )
May 09 17:18:23 <mickeyl> PaulFertser: depends on your needs. if you want to implement full conferencing and call logging, it might be necessary to react to released calls
May 09 17:18:28 <[Rui]> TAsn: no, a friend of mine apparently does :)
May 09 17:18:41 <TAsn> [Rui], :)
May 09 17:18:50 <TAsn> [Rui], haaretz is a big newspaper here :)
May 09 17:19:14 <[Rui]> ah
May 09 17:19:17 <PaulFertser> mickeyl: i do not want to implement full conferencing, but i need something i can daily use. Currently it's a little bit frustrating to be losing calls because somebody else's calling while i'm already talking.
May 09 17:19:54 <mickeyl> yeah, that'd be annoying
May 09 17:19:56 <TAsn> [Rui], well, just wondered :)
May 09 17:20:05 <[Rui]> TAsn: anyway, I'm going to drop the "... ago" for time references and just place date + hour as now I'm optimizing the generation of the time list and not remaking it all the time...
May 09 17:20:42 <TAsn> :)
May 09 17:20:49 <TAsn> I don't do social networking anyway
May 09 17:20:51 <PaulFertser> mickeyl: LOL, in fact it is ;)
May 09 17:20:58 <TAsn> so I don't really care/have an opinion.
May 09 17:35:59 <PaulFertser> TAsn: do you think there should be a separate signal for the increment of unread messages or calls? I mean it can be useful for the apps that do not keep state (currently oeventsd plays a "new message" signal for me even when i delete or read an unread message).
May 09 17:36:41 <TAsn> PaulFertser, bah? :P
May 09 17:36:51 <TAsn> here it doesn't btw.
May 09 17:37:00 <TAsn> I wonder how come it's different for me and you.
May 09 17:37:20 <PaulFertser> TAsn: you do not use oeventsd for that.
May 09 17:37:23 <PaulFertser> Most probably
May 09 17:37:47 <PaulFertser> TAsn: anyway there should definetely be a signal for any change (to update indication in statusbars etc) 
May 09 17:37:58 <TAsn> PaulFertser, yes we do.
May 09 17:38:26 <PaulFertser> The question is if there should be another signal for increase.
May 09 17:38:36 <TAsn>     trigger: IncomingMessage()
May 09 17:38:36 <TAsn>     actions: MessageTone(play)
May 09 17:39:27 <TAsn> in calls we have
May 09 17:39:29 <TAsn> [SIGNAL]    org.freesmartphone.PIM.Calls.MissedCall( s:path )
May 09 17:40:03 <TAsn> and in messages we have
May 09 17:40:05 <TAsn> [SIGNAL]    org.freesmartphone.PIM.Messages.IncomingMessage( s:message_path )
May 09 17:40:11 <TAsn> I don't get what you are missing.
May 09 17:40:20 <TAsn> Those are the "inc" ones :)
May 09 17:40:41 <PaulFertser> TAsn: ok, i'll check and tell you something more meaningful a bit later.
May 09 17:41:00 <TAsn> sure tihn.g
May 09 17:41:02 <TAsn> thing.*
May 09 17:41:18 <PaulFertser> mickeyl: fyi with ogsmd it was like that: i heard a gentle beep and the active call was automatically put on hold while a new was automatically activated. Not anywhere near correct as well.
May 09 17:41:27 <PaulFertser> (log sent in privmsg)
May 09 17:42:35 <PaulFertser> TAsn: looks like i've overlooked those, right, sorry for the noise.
May 09 17:44:49 <TAsn> PaulFertser, don't worry.
May 09 17:48:04 <GNUtoo> mickeyl, first time it came out of range,second time it had the usual issue,third time: still running (started 10min ago)
May 09 17:48:35 <mickeyl> PaulFertser: interesting. can't see which magic should put a call on hold
May 09 17:48:37 <GNUtoo> using a different application tough
May 09 17:48:42 <mickeyl> perhaps your SIM/provider is doing that
May 09 17:48:58 <GNUtoo> first and second time: midori or ventura,third mplayer playing a web radio
May 09 17:49:25 <mickeyl> you're talking about wifi now?
May 09 17:54:08 <GNUtoo> yes
May 09 17:54:29 <GNUtoo> lastest wireless-compat+pandora patches + a patch from me(adapted from the net)
May 09 17:54:53 <GNUtoo> compat-wireless-2010-05-08.tar.bz2
May 09 17:54:56 <GNUtoo> still running
May 09 17:56:29 <mickeyl> ok
May 09 17:56:34 <mickeyl> still no ad-hoc though, right?
May 09 17:58:00 <mrmoku> TAsn: did you see mickeyl implemented direct delivery without SIM buffering?
May 09 17:59:11 <TAsn> mickeyl, you gave up? :P
May 09 18:00:03 <TAsn> mickeyl, I prefer correct handling of buffered sms, since as you said, some modems don't support direct delivery.
May 09 18:01:50 <GNUtoo> no
May 09 18:02:03 <GNUtoo> 23min...it lasted 23 min...not enough
May 09 18:05:30 <mickeyl> 23minutes of what?
May 09 18:05:38 <mickeyl> WiFi until power drain?
May 09 18:06:37 <GNUtoo> no
May 09 18:06:44 <GNUtoo> wifi until the connection breaks
May 09 18:06:48 <GNUtoo> with PSM
May 09 18:07:01 <GNUtoo> maybe it's my router tough
May 09 18:07:09 <GNUtoo> I use an old version of hostapd
May 09 18:07:15 <GNUtoo> 0.6.9 or smoething like that
May 09 18:07:40 <GNUtoo> maybe I should upgrade to 0.7.1
May 09 18:19:14 <PaulFertser> TAsn: IncomingMessage trigger is wrong for those purposes
May 09 18:19:37 <TAsn> PaulFertser, please elaborate.
May 09 18:20:00 <PaulFertser> TAsn: that trigger corresponds to org.freesmartphone.GSM.SIM.IncomingStoredMessage
May 09 18:20:11 <TAsn> huh?
May 09 18:20:26 <TAsn> IncomingStoredMessage "triggers" IncomingMessage
May 09 18:20:43 <PaulFertser> TAsn: in oeventsd we use "trigger" names, not signal names.
May 09 18:21:12 <PaulFertser> TAsn: and that particular trigger is hooked to SIM.IncomingStoredMessage which is wrong if we consider multipart messages.
May 09 18:21:54 <TAsn> PaulFertser, yeah, that's wrong.
May 09 18:21:58 <PaulFertser> TAsn: there's only one PIM.Messages trigger and that's org.freesmartphone.PIM.Messages.UnreadMessages which triggers on any change.
May 09 18:22:15 <TAsn> PaulFertser, that's just oevents trying to be "general"
May 09 18:22:26 <TAsn> (i.e support not using opimd)
May 09 18:22:30 <PaulFertser> TAsn: moreover "IncomingMessage" never fires at all because fsogsmd doesn't emit IncomingStoredMessage i guess.
May 09 18:22:58 <TAsn> PaulFertser, IncomingMessage is also triggered by IncomingTextMessage
May 09 18:23:50 <TAsn> I'm talking about the opimd signal
May 09 18:24:01 <TAsn> PaulFertser, ok, let's start from the beginning
May 09 18:24:05 <PaulFertser> TAsn: i'm talking about oeventsd trigger
May 09 18:24:10 <TAsn> yes, I figured that.
May 09 18:24:13 <PaulFertser> :)
May 09 18:24:15 <TAsn> PaulFertser, oevents trigger
May 09 18:24:22 <TAsn> should really listen to the opimd signal
May 09 18:24:35 <mrmoku> morphis: I'm trying to build fsoinitd on my laptop to try it with UML.. and it does not build due to missing stropts.h
May 09 18:24:44 <TAsn> it doesn't because mickey wants to support working without opimd
May 09 18:25:02 <TAsn> It should though.
May 09 18:25:07 <TAsn> Anyhow, quick shower.
May 09 18:25:08 <mrmoku> morphis: I found the following fedora bug entry https://bugzilla.redhat.com/show_bug.cgi?id=439403 which says stropts.h is no more
May 09 18:25:12 <TAsn> PaulFertser, brb.
May 09 18:27:35 <mrmoku> morphis: configurenetworkinterfaceaction is the one wanting it... any idea why?
May 09 18:29:01 <PaulFertser> mrmoku: btw, what about dbus folks? I tried to look into "i want to connect to dbus daemon via different socket sometimes" idea and came to the conclusion tweaking env variable is not the nice way (but the only one available for now).
May 09 18:29:59 <mrmoku> PaulFertser: yeah, and has the advantage that the app needs no change
May 09 18:30:18 <mrmoku> PaulFertser: did you take a look at dbus-daemon-proxy?
May 09 18:30:29 <mrmoku> morphis: it's posix.vapi needing it
May 09 18:30:59 <PaulFertser> mrmoku: i was looking into how to make my fso.el connect to a remote dbus message bus. The problem is that the env variable is per-process.
May 09 18:31:22 <mrmoku> mickeyl: posix.vapi needs stropts.h, which is not available on fedora
May 09 18:31:49 <mrmoku> mickeyl: citing the bug entry: stropts.h is part of a POSIX XSR option, which Linux now, matching reality, says
May 09 18:31:52 <mrmoku> it is not supported
May 09 18:36:02 <mrmoku> mickeyl: posix.vapi needs it for ioctl... which I have in sys/ioctl.h
May 09 18:36:52 <TAsn> PaulFertser, back.
May 09 18:43:28 <GNUtoo> btw I'll re-ask but how do I disable frame pointer in the freerunner kernel. it seem that the option can't be removed
May 09 18:50:23 <mrmoku> mickeyl: interesting enough fedora ships a vala with posix.vapi that needs stropts.h ;)
May 09 18:57:02 <PaulFertser> mrmoku: after reading enough of python debug bindings and d-feet sources i see i was wrong about the dbus, it offers a possibility to connect anywhere at the same time within the same program.
May 09 18:57:45 <PaulFertser> s/debug/dbus/
May 09 18:57:47 <apt> PaulFertser meant: mrmoku: after reading enough of python dbus bindings and d-feet sources i see i was wrong about the dbus, it offers a possibility to connect anywhere at the same time within the same program.
May 09 18:58:50 <mickeyl> mrmoku: hmm, so what do we need to do?
May 09 18:59:08 <mrmoku> mickeyl: s/stropts.h/sys\/ioctl.h/g :)
May 09 18:59:19 <mrmoku> mickeyl: then it builds
May 09 18:59:26 <mickeyl> in posix.vapi?
May 09 18:59:28 <mrmoku> yep
May 09 18:59:52 <mickeyl> ok, i need to investigate that, since it's a change that has to be carried out upstream
May 09 19:00:00 <mrmoku> yep
May 09 19:00:36 * mrmoku needs to investigate how to build fsoinitd statically
May 09 19:02:28 <mickeyl> hmm
May 09 19:02:30 <mickeyl> ok, so
May 09 19:02:37 <mickeyl> can you grep for MOREDATA plesae
May 09 19:02:51 <mickeyl> and
May 09 19:02:57 <mickeyl> S_INPUT
May 09 19:03:01 <mickeyl> to have two Stichproben
May 09 19:03:15 <mrmoku> in posix.vapi?
May 09 19:04:15 <mrmoku> posix.vapi:     public const int MOREDATA;
May 09 19:04:17 <mickeyl> no, i'd like to know where in your include path those are
May 09 19:04:22 <mrmoku> ahh
May 09 19:04:29 <mickeyl> since here they're all in stropts.h
May 09 19:05:20 <mrmoku> 0002 mok@gonzales[pts/1]:~/share/vala/vapi-> grep MOREDATA /usr/include/*/*
May 09 19:05:23 <mrmoku> nothing :/
May 09 19:05:39 <mickeyl> hmm :/
May 09 19:05:46 <mrmoku> same for 0002 mok@gonzales[pts/1]:~/share/vala/vapi-> grep -w S_INPUT /usr/include/*/*
May 09 19:06:36 <mickeyl> ok, there are about 20 flags and the ioctl call itself
May 09 19:06:54 <mickeyl> iirc fsoinitd only needs the ioctl, right?
May 09 19:08:25 <mickeyl> http://www.mail-archive.com/vala-list@gnome.org/msg02685.html
May 09 19:08:37 <mrmoku> yep, only ioctl
May 09 19:08:45 <mrmoku> no
May 09 19:09:13 <mickeyl> suprkiddo noticed this one year ago
May 09 19:09:29 <mickeyl> unfortunately noone replied
May 09 19:11:21 <mickeyl> interestingly enough, POSIX doesn't seem to specify ioctl(2) at all
May 09 19:12:20 <mickeyl> hmm, well
May 09 19:12:43 <mickeyl> it defines it as part of the STREAMS API
May 09 19:12:58 <mickeyl> ok
May 09 19:13:04 <mickeyl> i guess what we should do is define it in linux.vapi
May 09 19:13:18 <mickeyl> requiring the proper headers there
May 09 19:13:32 <mickeyl> and then use Linux.ioctl everywhere instead of Posix.ioctl
May 09 19:14:57 <mrmoku> sounds sane
May 09 19:15:12 <mrmoku> any hint how to shrink that list: http://pastie.org/952760
May 09 19:15:21 <mrmoku> fsoinitd_LDFLAGS = -static
May 09 19:15:24 <mrmoku> doesn't hit it
May 09 19:15:31 <mickeyl> uah
May 09 19:15:36 <mrmoku> :P
May 09 19:15:54 <mickeyl> ok, two things
May 09 19:16:03 <mickeyl> first you need to find out how to link statically with libtool
May 09 19:16:06 <mickeyl> that's not 100% trivial :)
May 09 19:16:19 <mickeyl> second, why are we linking against all that stuff?
May 09 19:16:27 <mickeyl> aah, let me guess
May 09 19:16:32 <mickeyl> libfsobasics?
May 09 19:16:36 <mrmoku> yup
May 09 19:16:40 <mickeyl> libfsobasics should not link against dbus
May 09 19:16:58 <mrmoku> dbus we need for the dbusactivation action I guess
May 09 19:16:58 <mickeyl> yep, doesn't
May 09 19:17:02 <mickeyl> hmm
May 09 19:18:39 <mickeyl> in that case you can't remove much from it
May 09 19:18:53 <mickeyl> static linking will only add the necessary things though, so it should be ok
May 09 19:19:14 <mickeyl> iirc you need to provide --all-static
May 09 19:19:18 <mickeyl> to libtool
May 09 19:25:59 <mickeyl> right, -all-static attempts to do it
May 09 19:26:11 <mickeyl> so try
May 09 19:26:17 <mickeyl> fsoinitd_LDFLAGS = -all-static
May 09 19:27:02 <mickeyl> building it on your host might be a problem though
May 09 19:27:11 <mickeyl> since many distros do not ship static libraries these days
May 09 19:27:17 <mrmoku> mickeyl: yeah, googled and tried all-static... does not change though
May 09 19:27:35 <mrmoku> ahh... after make clean things change :)
May 09 19:27:43 <mrmoku> /usr/bin/ld: cannot find -ldbus-glib-1
May 09 19:27:55 <mickeyl> yep
May 09 19:27:59 <mickeyl> missing static library
May 09 19:28:08 <mickeyl> so you need all the static libraries for the dependencies of course
May 09 19:28:55 <mrmoku> heh... then I give up :P
May 09 19:29:01 <mrmoku> fedora has no static libs :/
May 09 19:30:15 <mrmoku> and my busybox rootfs has none of those libs needed
May 09 19:30:27 <mickeyl> then ignore that for now
May 09 19:30:31 <mickeyl> in OE it should just work
May 09 19:30:46 <mrmoku> yeah, but I wanted to try it with UML
May 09 19:31:14 * mrmoku wonders if he should try to build a x86 fso-console-image
May 09 19:31:15 <mickeyl> at all or just the static?
May 09 19:31:26 <mrmoku> ?
May 09 19:31:31 <mickeyl> dynamically linked will work as well
May 09 19:31:34 <mickeyl> (with UML)
May 09 19:31:40 <mrmoku> yeah, but I need the libs in my rootfs then
May 09 19:31:49 <mickeyl> ah, that was it , right
May 09 19:32:02 <mickeyl> what i did was copying them all in
May 09 19:32:08 <mickeyl> just 15 or so :)
May 09 19:32:14 <mickeyl> and you only have to do it once
May 09 19:32:36 <mickeyl> x86 console image should work fine as well though
May 09 19:32:37 <mickeyl> bbl
May 09 19:32:41 <mrmoku> ok, thanks
May 09 20:50:51 <Kayin> Heh, hi GNUtoo.
May 09 20:51:21 <GNUtoo> hi
May 09 20:52:06 <GNUtoo> does anyone know how to remove frame pointer from the kernel?
May 09 20:52:14 <GNUtoo> and if it's possible
May 09 20:52:17 <GNUtoo> is it a bug?
May 09 20:52:27 <Wonka> no, a diagnostic tool
May 09 20:52:38 <GNUtoo> I know but I want to remove it
May 09 20:52:44 <GNUtoo> I can't
May 09 20:52:48 <Wonka> you need to recompile your kernel
May 09 20:52:51 <GNUtoo> last time that I looked I couldn't
May 09 20:52:56 <GNUtoo> make ARCH=arm xconfig
May 09 20:53:00 <GNUtoo> didn't let me remove it
May 09 20:53:10 <Wonka> something depended on it then
May 09 20:53:19 <GNUtoo> it seemed to be selected by some core dependencies
May 09 20:53:35 <Wonka> haven't built an arm kernel yet...
May 09 20:53:40 <GNUtoo> ah ok
May 09 20:53:49 <GNUtoo> on other devices kernel it can be removed
May 09 20:53:59 <GNUtoo> like bug device,htcdream etc...
May 09 20:54:09 <GNUtoo> and on htcdream there is a huge performance impact
May 09 20:54:14 <GNUtoo> from unusable to usable
May 09 20:54:45 <GNUtoo> so I bet it's the same for the freerunner
May 09 20:57:40 <Kensan> GNUtoo: look for CONFIG_FRAME_POINTER
May 09 20:57:48 <Kensan> GNUtoo: can you disable it by hand in your .config?
May 09 20:59:36 <GNUtoo> yes
May 09 20:59:44 <GNUtoo> by hand I'll try
May 09 21:00:05 <Kensan> GNUtoo: compilation will probably fail if something really depends on it...
May 09 21:00:11 <GNUtoo> ok
May 09 21:01:13 <Kensan> GNUtoo: you could grep for "depends on CONFIG_FRAME_POINTER" in your tree's Kconfig files to figure out where that dependency comes from.
May 09 21:01:33 <GNUtoo> I did that long time ago
May 09 21:01:37 <GNUtoo> I'll re-do it
May 09 21:03:57 <GNUtoo> btw is the kernel still developped?
May 09 21:04:55 <lindi-> GNUtoo: what kind of question is that? there are hundreds of people working on linux
May 09 21:05:13 <GNUtoo> I meant the openmoko kernel
May 09 21:05:13 <Weiss> also.. why on earth would you want to remove the frame pointer?
May 09 21:05:22 <GNUtoo> speed
May 09 21:05:39 <GNUtoo> If you say Y here the resulting kernel image will be slightly larger and slower
May 09 21:05:44 <GNUtoo> note the slower
May 09 21:06:36 <GNUtoo> oops
May 09 21:06:40 <GNUtoo> If you say N here, the resulting kernel will be slightly smaller and faster.
May 09 21:07:33 <GNUtoo> oucch
May 09 21:07:39 <GNUtoo> there are 2 frame pointer options
May 09 21:08:34 <GNUtoo> http://pastebin.com/hLtAJcv7
May 09 21:10:54 <GNUtoo> HAVE_FUNCTION_TRACER selects it
May 09 21:11:24 <GNUtoo> let me verify
May 09 21:13:27 <GNUtoo> STACKTRACE_SUPPORT HAVE_LATENCYTOP_SUPPORT  HAVE_FUNCTION_TRACER selects this one : defined at lib/Kconfig.debug:581
May 09 21:15:38 <GNUtoo> wait a sec.I'll look better (it's late here)
May 09 21:16:56 <Kensan> GNUtoo: the revdep that pull's in frame pointer should be present in your .config.
May 09 21:17:07 <GNUtoo> ok
May 09 21:17:23 <GNUtoo> it seem an old kconfig system
May 09 21:17:35 <Kensan> GNUtoo: what kernel are you building btw?
May 09 21:17:59 <GNUtoo> this one:
May 09 21:18:05 <lindi-> GNUtoo: have you disabled debugging?
May 09 21:18:08 <GNUtoo> linux-openmoko-shr-devel-2.6.29-oe11+gitra15608f241a40b41fed5bffe511355c2067c4e88-r8
May 09 21:18:11 <GNUtoo> yes
May 09 21:18:16 <GNUtoo> every debug is disabled
May 09 21:22:38 <GNUtoo> I don't understand...all what I looked "select FRAME_POINTER" are disabled
May 09 21:31:13 <GNUtoo> make menuconfig seem more clear
May 09 21:32:21 <GNUtoo> normally it should not be selected according to make ARCH=arm menuconfig
May 09 21:32:28 <GNUtoo> but there are 2 FRAME_POINTER
May 09 21:33:29 <GNUtoo> I'll remove one of them
May 09 21:34:48 <GNUtoo> ok was the arm one
May 09 21:34:52 <GNUtoo> it was hardcoded to y
May 09 21:35:46 <GNUtoo> http://pastebin.com/espgSBbB I hope I won't be killed by the arm maintainer
May 09 21:36:42 <GNUtoo> thanks a lot for making me persisting
May 09 21:39:45 <GNUtoo> because he has an ARMy
May 09 22:15:26 <Kensan> GNUtoo: hehe, that's quite funny.
May 10 01:34:56 <DocScrutinizer> ~ping
May 10 01:35:27 <DocScrutinizer> ~ping
May 10 01:35:29 <apt> ~pong
May 10 01:35:39 <DocScrutinizer> ~chaninfo
May 10 01:35:40 <apt> I'm on 15 channels: #openmoko-cdevel/95, ##guleague/13, #webos-internals/4, ##bz-inc/4, ##icf/3, #maemo/1, #asterisk/1, #utah/1, #oe/1, #meego/1, #elinux/1, ##pxe/1, #tomcat/1, #bzflag/0
May 10 01:35:41 <apt> i've cached 127 users, 117 unique users, distributed over 15 channels.
**** ENDING LOGGING AT Mon May 10 02:59:57 2010