**** BEGIN LOGGING AT Tue Apr 12 02:59:57 2011
Apr 12 06:16:06 <pespin> gmorning
Apr 12 08:03:28 <CIA-10> freesmartphone.org: 03morphis 07aurora * r426c429070dc 10/libaurora/ (16 files in 3 dirs): libaurora: add initial skeleton
Apr 12 08:03:29 <CIA-10> freesmartphone.org: 03morphis 07aurora * r0d79689b713f 10/aurora-settings/ (17 files in 6 dirs): aurora-settings: add skeleton
Apr 12 08:03:31 <CIA-10> freesmartphone.org: 03morphis 07aurora * r0a6308a002e3 10/ (.gitignore zhone2/.gitignore): Move .gitignore to root directory
Apr 12 08:03:32 <CIA-10> freesmartphone.org: 03morphis 07aurora * re05e919eb138 10/libaurora/aurora/ (Makefile.am init.vala session.vala): libaurora: implement application session handling
Apr 12 08:03:34 <CIA-10> freesmartphone.org: 03morphis 07aurora * rde903cc54036 10/libaurora/aurora/ (init.vala session.vala): libaurora: correct application session registering
Apr 12 08:03:48 <CIA-10> freesmartphone.org: 03morphis 07aurora * r86f5076e4466 10/libaurora/ (6 files in 2 dirs): libaurora: add initialization/shutdown logic and event handler registration
Apr 12 08:03:48 <CIA-10> freesmartphone.org: 03morphis 07aurora * r669ce2569898 10/libaurora/aurora/init.vala: libaurora: application session should be registered when application starts
Apr 12 08:22:53 <CIA-10> freesmartphone.org: 03morphis 07aurora * r71a2512ae087 10/aurora-settings/ (configure.ac src/Makefile.am src/main.vala): aurora-settings: implement basic application setup structure
Apr 12 08:24:42 <morphis> heyho
Apr 12 08:25:59 <JaMa|Wrk> hey
Apr 12 08:30:59 <mrmoku> JaMa|Wrk: ho
Apr 12 08:31:20 <mrmoku> JaMa|Wrk: did you push phonet-utils to oe too?
Apr 12 08:31:32 <mrmoku> asking because I had a typo in the license
Apr 12 08:33:46 <DocScrutinizer> ~moo
Apr 12 08:33:47 * apt mooooooooo! I am cow, hear me moo, I weigh twice as much as you. I am cow, eating grass, methane gas comes out my ass
Apr 12 08:37:21 <JaMa|Wrk> mrmoku: yes and IIRC I've fixed license
Apr 12 08:37:41 <JaMa|Wrk> ah didn't
Apr 12 08:38:27 <JaMa|Wrk> only in meta-oe
Apr 12 08:38:33 <JaMa|Wrk> +LICENSE = "GPLv2"
Apr 12 08:38:33 <JaMa|Wrk> +LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
Apr 12 08:42:37 <mrmoku> JaMa|Wrk: ok
Apr 12 08:43:29 <JaMa|Wrk> is that the typo you found?
Apr 12 08:44:00 <mrmoku> JaMa|Wrk: the typo GNUtoo found... GPLV2 instead of GPLv2
Apr 12 08:45:29 <JaMa|Wrk> ok pusing
Apr 12 08:45:36 <JaMa|Wrk> +h
Apr 12 08:45:47 <mrmoku> thx
Apr 12 08:54:32 <sC2> GarthPS: ping
Apr 12 09:13:23 <morphis> so, people let plays license guessing, which license has the md5 hashsum fbc093901857fcd118f065f900982c24? :D
Apr 12 09:13:57 <JaMa|Wrk> morphis: ?
Apr 12 09:14:10 <morphis> you want the solution?
Apr 12 09:14:24 <morphis> it's GPLv2.1
Apr 12 09:14:46 <morphis> license = COPYING file
Apr 12 09:15:19 <lindi-> 2.1?
Apr 12 09:15:26 <JaMa|Wrk> you have both LICENSE nad LIC_FILES_CHKSUMs field
Apr 12 09:16:05 <JaMa|Wrk> morphis: and LIC_FILES_CHKSUM are used to check that ie COPYING (or whatever file defines license in source tarball) is still the same when you upgrade recipe
Apr 12 09:16:51 <JaMa|Wrk> and do_configure will fail if upstream updates COPYING to say ie GPLv3 instead of GPLv2
Apr 12 09:17:56 <morphis> I know
Apr 12 09:18:17 <morphis> I find it just funny to guess the license based on the md5sum of it
Apr 12 09:18:30 <morphis> as GPLv2 should have most times the same hash
Apr 12 09:18:45 <morphis> (if it ist really GPLv2 without any modifcations to the COPYING file)
Apr 12 09:19:39 <JaMa|Wrk> many projects preppend some header to it (ie with project name)
Apr 12 09:20:27 <JaMa|Wrk> that's at least my conclusion after adding some 100+ LIC_FILES_CHKSUMs
Apr 12 09:20:46 <morphis> ok
Apr 12 09:21:03 <morphis> than it's no that easy to guess the license :)
Apr 12 09:21:33 <morphis> btw. I started yesterday to improve meta-shr to support palmpre machine
Apr 12 09:21:36 <GarthPS> sC2: i just answered to your last mail . I am busy here so I will not be able to answer frequently to you right now
Apr 12 09:22:15 <sC2> GarthPS: i know, i just saw that you sent a email 5 mins ago and i thought you may be here so i could irc it to you :)
Apr 12 09:24:18 <JaMa|Wrk> morphis: great
Apr 12 09:26:00 <morphis> JaMa|Wrk: should I open another branch in meta-shr for that which you merge later into the master?
Apr 12 09:27:07 <sC2> do sms work in the current SHR-U?
Apr 12 09:27:18 <morphis> sC2: you mean for palmpre?
Apr 12 09:27:31 <sC2> nope FR
Apr 12 09:27:51 <sC2> the shr on the pre is too buggy for daily use at that time :)
Apr 12 09:28:07 <GarthPS> sC2: but you can ask your question :)
Apr 12 09:28:24 <sC2> GarthPS: i sent you the mail already :)
Apr 12 09:28:33 <JaMa|Wrk> morphis: as you wish, if you wont break nokia900/om-gta02 builds while improving palmpre, I'm fine with you doing it in master branch
Apr 12 09:28:44 <sC2> ill be here in 20 mins again, getting some food :)
Apr 12 09:30:08 <morphis> JaMa|Wrk: ok, do I have commit access for meta-shr?
Apr 12 09:31:46 <JaMa|Wrk> you have, now
Apr 12 09:31:50 <morphis> thx
Apr 12 09:38:01 <morphis> JaMa|Wrk: but how is the workflow for adding system programs like lvm2? as it is something that should be in meta-oe or oe-core. Should I create another pull branch for it and send later a pull request to upstream?
Apr 12 09:39:53 <JaMa|Wrk> morphis: you can add it to meta-shr first to test it, then SHR makefile is using meta-oe-contrib (branch shr) and oe-core-contrib (branch shr), so you can move it there
Apr 12 09:40:03 <morphis> ok
Apr 12 09:40:24 <JaMa|Wrk> morphis: and when it's ready you can send pull request from some other branch, or I'll do it for you
Apr 12 09:40:30 <morphis> ok
Apr 12 09:40:54 <morphis> another question, in old OE we have recipes/palmpre folder with machine specific dependencies, should they go into recipes-bsp?
Apr 12 09:41:46 <JaMa|Wrk> yes.. we should even create separate bsp layers, but for now I'm not sure if it's worth it
Apr 12 09:42:17 <morphis> ok
Apr 12 09:42:22 <morphis> but maybe it is
Apr 12 09:42:34 <JaMa|Wrk> see http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/
Apr 12 09:42:37 <morphis> to create a recipes-palmpre/recipes-n900
Apr 12 09:43:45 <morphis> btw. I love working with oe-core, meta-oe and meta-shr as it's very fast with parsing less recipes than in old OE :)
Apr 12 09:44:04 <JaMa|Wrk> the problem is that I don't want too many layers, so if we can consolidate few kernel recipes then omap-bsp layer would be better then nokia900-bsp,palmpre-bsp etc
Apr 12 09:45:05 <morphis> hm ok
Apr 12 09:45:30 <morphis> I have currently seven recipes only usable for palmpre machine
Apr 12 09:45:34 <JaMa|Wrk> but if you really want palmpre-bsp I won't stop you :)
Apr 12 09:46:06 <morphis> hm
Apr 12 09:46:29 <morphis> layout is always recipes-x/*/*.bb or is it even allowed to do recipes-x/*.bb ?
Apr 12 09:46:31 <JaMa|Wrk> recipes-palmpre is good interim solution imho
Apr 12 09:46:49 <JaMa|Wrk> BBFILES := "${BBFILES} ${LAYERDIR}/recipes*/*/*.bb \ ${LAYERDIR}/recipes*/*/*.bbappend"
Apr 12 09:46:58 <morphis> ok
Apr 12 09:47:25 <morphis> and one directory in recipes-* should be only for one application?
Apr 12 09:47:51 <morphis> as now I have recipes/palmpre/ which different applications in it
Apr 12 09:48:34 <JaMa|Wrk> recipes-palmpre/android-rpc/android-rpc.bb is common
Apr 12 09:49:02 <morphis> ok
Apr 12 09:49:39 <morphis> mickey|office: heyho
Apr 12 09:49:44 <mickey|office> moinmoin
Apr 12 09:50:36 * JaMa|Wrk lunch
Apr 12 09:50:53 <morphis> JaMa|Wrk: happy eating
Apr 12 09:53:37 <morphis> JaMa|Wrk: should I reset PR when importing the recipes?
Apr 12 09:54:48 * mickey|office just payed EUR 99 for gasoline
Apr 12 09:54:51 <mickey|office> is that crazy or what?
Apr 12 09:54:52 <mickey|office> *sigh*
Apr 12 09:55:06 <morphis> really
Apr 12 09:55:14 <mickey|office> (just an ordinary car... not a plane)
Apr 12 09:55:32 <morphis> so you have a full tank now?
Apr 12 09:55:57 <mickey|office> yeah
Apr 12 09:56:39 <mickey|office> too much driving in the city... needing about 12l/100kmH these days
Apr 12 09:56:40 <morphis> :)
Apr 12 09:56:46 <mickey|office> err
Apr 12 09:56:49 <mickey|office> km, not kmH
Apr 12 10:10:11 <sC2> how to enable the celluar data on the pre vie terminal? ;)
Apr 12 10:14:33 <mickey|office> if you have the latest packages, the easiest way is to run cli-framework
Apr 12 10:14:36 <mickey|office> then on the prompt
Apr 12 10:14:43 * pespin just discovered libsocialweb which can be really useful to write nice apps ;)
Apr 12 10:14:45 <pespin> http://git.gnome.org/browse/libsocialweb/
Apr 12 10:14:49 <mickey|office> gsmpdp.SetCredentials( <your APN>, <your user>, <your password> )
Apr 12 10:14:53 <mickey|office> gsmpdp.ActivateContext()
Apr 12 10:14:54 <pespin> libfolks has a backend for it too I think
Apr 12 10:14:56 <mickey|office> and that should be it
Apr 12 10:15:10 <sC2> thank you mickey :)
Apr 12 10:22:02 <DocScrutinizer> для вашего здоровья, Юрий
Apr 12 10:22:18 <mickey|office> �h, wie?
Apr 12 10:22:34 <DocScrutinizer> (auf dein Wohl, Juri)
Apr 12 10:23:31 <PaulFertser> DocScrutinizer: :-O
Apr 12 10:23:49 <DocScrutinizer> PaulFertser: what?
Apr 12 10:24:01 <PaulFertser> DocScrutinizer: why are you writing some cryptic text in russian?
Apr 12 10:24:27 <DocScrutinizer> sorry, seems I'm not good in Russian
Apr 12 10:24:44 <DocScrutinizer> Juri Gagarin memorial minute
Apr 12 10:25:15 <PaulFertser> DocScrutinizer: :))
Apr 12 10:32:31 <sC> is there a way to enable the hardware keyboard from the pre in shr? it does work in ttys but not in apps :/
Apr 12 13:06:19 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r5fb8f5c4e86c 10/fsoappd/ (11 files in 6 dirs): fsoappd: some restructuring and renaming
Apr 12 13:06:20 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r84a3bd8728ca 10/fsoappd/src/ (5 files in 2 dirs): fsoappd: implement application storage to gather information about available applications
Apr 12 13:06:22 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r9b77500a1e74 10/libfsobasics/fsobasics/checksum.vala: libfsobasics: adjust style to match common style
Apr 12 13:06:27 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r4fd957dc45b7 10/fsoaudiod/src/alsa_hooks/ (4 files): fsoaudiod: alsa_hooks: we only need one plugin to do the session handling
Apr 12 13:06:32 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r821eabe7d046 10/fsoaudiod/src/alsa_hooks/ (Makefile.am plugin.vala): fsoaudiod: alsa_hooks: make it possible to write parts of the plugin with vala
Apr 12 13:06:33 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r07ba5cabff6f 10/fsoaudiod/src/alsa_hooks/alsa-wrapper.c: fsoaudiod: alsa_hooks: register hooks to alsa
Apr 12 13:28:32 <jfthomps> is SHR unstable somewhat stable at the moment?
Apr 12 13:32:47 <GNUtoo|laptop> jfthomps, what device?
Apr 12 13:33:04 <jfthomps> oh, sorry - freerunner
Apr 12 13:33:52 <GNUtoo|laptop> np
Apr 12 13:34:08 <GNUtoo|laptop> it seem so but I don't use it enough to be sure
Apr 12 13:34:16 <GNUtoo|laptop> (for the freerunner)
Apr 12 13:34:29 <GNUtoo|laptop> what functionality do you depend on?
Apr 12 13:35:52 <jfthomps> most of it :) - phone calls, texts, wifi; would prefer that it not have random lockups
Apr 12 13:36:46 <jfthomps> I ran unstable for quite a while; I can't remember what issue caused me to switch back to testing, but testing can't do qvga (at least not for me), and I'm interested in that at the moment
Apr 12 13:36:57 <GNUtoo|laptop> I can look
Apr 12 13:37:08 <GNUtoo|laptop> phone seem to work
Apr 12 13:37:15 <GNUtoo|laptop> wifi too
Apr 12 13:37:24 <GNUtoo|laptop> but I'm not sure for QVGA
Apr 12 13:37:26 <GNUtoo|laptop> I must test
Apr 12 13:38:05 <GNUtoo|laptop> btw the internet will cut at some point here
Apr 12 13:38:52 <jfthomps> ok
Apr 12 13:45:39 <morphis> heyho
Apr 12 14:08:41 <mickey|office> yo
Apr 12 14:10:48 <mrmoku> huh... getting wet outside
Apr 12 14:30:14 <mickey|office> morphis: classical april's weather
Apr 12 14:31:23 <morphis> :)
Apr 12 14:31:49 <morphis> mickey|office: I am currently thinking about the audio session thing with the alsa-hooks
Apr 12 14:32:08 <morphis> I want to register a audio session with fsoaudiod whenever a alsa device is opened
Apr 12 14:32:26 <morphis> so fsoaudiod knows how much and which devices are opened at any time
Apr 12 14:32:41 <morphis> my problem currently is how to tell fsoaudiod about it
Apr 12 14:33:02 <morphis> as we have no mainloop within the hook, we can just send simple dbus commands to fsoaudiod
Apr 12 14:33:13 <morphis> so I thought about the following:
Apr 12 14:33:39 <morphis> * org.freesmartphone.Audio.Manager.RegisterSession(string token, FreeSmartphone.Audio.Stream stream_type)
Apr 12 14:33:50 <morphis> * org.freesmartphone.Audio.Manager.ReleaseSession(string token)
Apr 12 14:34:00 <morphis> so we do the identifcation of the session with the token
Apr 12 14:34:43 <morphis> or the other way round, that fsoaudiod is suggesting the token and returns it to the caller
Apr 12 14:35:16 <mickey|office> yep, the latter. fsoaudiod can then ensure the tokens are unique and can store them in a hashtable
Apr 12 14:36:30 <morphis> ok
Apr 12 14:37:29 <morphis> next think is, should I really do the session register call within the alsa plugin or just calling some binary which does the job?
Apr 12 14:41:10 <mickey|office> an additional binary only adds complexity IMO
Apr 12 14:42:35 <morphis> ok, so we should do it in the alsa plugin itself?
Apr 12 14:44:46 <mickey|office> i'd say why not
Apr 12 14:44:49 <mickey|office> :)
Apr 12 14:45:09 <morphis> ok
Apr 12 14:45:41 <morphis> maybe latency when the action to open the audio device hangs cause of the dbus action behind
Apr 12 14:49:01 <mickey|office> async
Apr 12 14:49:26 <mickey|office> or rather not, if we want to allow fsoaudiod to decline the request...
Apr 12 14:49:44 <mickey|office> which speaks even more for handling it in the plugin itself
Apr 12 14:49:46 <morphis> we can't do it async
Apr 12 14:50:00 <morphis> but the decline aspect is a good reason
Apr 12 14:50:13 <morphis> otherwise we have to parse the stdout/stderr of the called binary
Apr 12 14:50:28 <mickey|office> yep
Apr 12 14:52:27 <morphis> I am happy about this solution with doing the alsa plugin as it means nobody has to care about audio priority stuff, it is handled automatically :)
Apr 12 14:52:54 <mickey|office> hopefully. i'm not 100% convinced yet that this will work out, but i'll be pleased, if it actually does
Apr 12 14:54:24 <morphis> what are your doubts?
Apr 12 14:55:52 <mickey|office> nothing concrete, just a mild sceptism whether it works in practice
Apr 12 14:56:01 <morphis> ok :)
Apr 12 14:56:16 <morphis> then I will show you that it works
Apr 12 14:56:32 <mickey|office> excellent :)
Apr 12 14:56:42 <mickey|office> ~spell scepticism
Apr 12 14:56:44 <apt> possible spellings for scepticism: skepticism Stoicism stoicism septicemia septicemia's Spitz's spadices
Apr 12 15:02:59 <DocScrutinizer> my libhookexec works on return code of system() as well
Apr 12 15:06:53 <CIA-10> freesmartphone.org: 03morphis 07specs * r5383abaf90ea 10/html/ (2 files): Add missing html documentation of Application API
Apr 12 15:06:54 <CIA-10> freesmartphone.org: 03morphis 07specs * r7d457c37971a 10/ (2 files in 2 dirs): Extended Audio API to support register/release a audio session
Apr 12 15:06:55 <CIA-10> freesmartphone.org: 03morphis 07specs * r84b70233a121 10/ (4 files in 2 dirs): Some little updates for the Application API
Apr 12 15:06:56 <CIA-10> freesmartphone.org: 03morphis 07specs * r5719341411a1 10/org.freesmartphone.Audio/org.freesmartphone.Audio.Manager.xml.in: Extend Audio API to make it possible to register/release a audio session
Apr 12 15:06:56 <CIA-10> freesmartphone.org: 03morphis 07specs * r7a2db4c6b058 10/configure.ac: Bump version for recent changes
Apr 12 15:08:57 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r90646e6b9630 10/fsoaudiod/src/plugins/manager/plugin.vala: fsoaudiod: manager: implement new methods to register/release a audio session
Apr 12 15:15:23 <Q-Master> JaMa|Wrk: ping
Apr 12 15:29:02 <DocScrutinizer> morphis: I'm really glad to hear you're picking up this open end
Apr 12 15:30:14 <morphis> DocScrutinizer: jepp, thats something someone should have discovered and implemented earlier
Apr 12 15:30:22 <morphis> as it's so simple and cute
Apr 12 15:30:33 <DocScrutinizer> I discovered it like 2 years ago
Apr 12 15:30:48 <DocScrutinizer> :-)
Apr 12 15:31:18 <DocScrutinizer> I stopped to implement anything when it became obvious nobody was really interested in it
Apr 12 15:32:06 <morphis> it's mainly because the people who are interested and have the knowledge to implement it was quite busy with other things or lost interest for doing such a thing for a FOSS mobile phone
Apr 12 15:33:44 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * rf4266111760c 10/fsoaudiod/src/ (3 files in 2 dirs): fsoaudiod: implement session handler to register/release audio sessions
Apr 12 15:38:55 <DocScrutinizer> morphis: a good argument to implement the dbus calls inside alsa-plugin is to exploit the auto-release feature analog to fsoraw resource allocation (i.e. to keep the busname active as long as app is running and has audiodev opened, but release the 'scenario' automatically even when app segfaults)
Apr 12 15:39:49 * morphis things he should really take a look at fsoraw's source code
Apr 12 15:40:10 <DocScrutinizer> actually I think audio "scenarios" are exactly like resources
Apr 12 15:40:19 <DocScrutinizer> almost exactly
Apr 12 15:40:44 <morphis> jepp
Apr 12 15:41:01 <morphis> it's the same thing, just with another name and identifier
Apr 12 15:41:12 <DocScrutinizer> and I stopped development on ACI when mickey wasn't interested to support it by extending resources to handle audio
Apr 12 15:41:59 <morphis> ok
Apr 12 15:42:22 <morphis> the resource handling as it is is not the best place to do the audio thing
Apr 12 15:42:49 <morphis> I think the audio daemon is the right place, as it will do volume adjustments later when sessions are registered and so on
Apr 12 15:43:13 <morphis> ah fsoraw simply forks to keep the registered resources alive
Apr 12 15:48:43 <morphis> DocScrutinizer: thats a good idea to even take the busname for identifying the audio session
Apr 12 15:48:58 <morphis> as the dbus connection will stay alive as long as we keep it open (or the app segfaults)
Apr 12 15:49:19 <morphis> so we can listen for the busname to disappear and than release the session automatically
Apr 12 16:10:51 <DocScrutinizer> exactly
Apr 12 16:19:18 <morphis> DocScrutinizer: when I return within the alsa hook function with a error code, the open call of the process which wants to open the audio devices fails?
Apr 12 16:20:23 <DocScrutinizer> if the fsoaudiod sends a resurce-not-available (i.e. resource *becomes* unavailable after initially it had been allocated successfully) then my idea been to allow alternative actions to the default muting of app's individual softvol: I thought about 3 different classes of actions that could work without major security issues: a) alsa-plugin sends arbitrary signal (sigstop, sigint) to own master process aka the_app  b) sends 
Apr 12 16:20:24 <DocScrutinizer> arbitrary keystrokes -like P for pause- to stdin/fd3 (dunno if that's even feasible)  c) fsoaudiod sends an arbitrary dbus msg to app
Apr 12 16:20:36 <DocScrutinizer> morphis: yes, it fails
Apr 12 16:21:01 <morphis> great
Apr 12 16:21:09 <DocScrutinizer> see my original PoC code with system()
Apr 12 16:21:31 <morphis> ok
Apr 12 16:24:04 <DocScrutinizer> bbl
Apr 12 16:24:08 <DocScrutinizer> o/
Apr 12 16:43:35 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * radf5075bdd26 10/fsoaudiod/ (5 files in 3 dirs): fsoaudiod: implement abstract type for a audio session policy
Apr 12 16:43:36 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * r8a1ea83d95e9 10/fsoaudiod/src/alsa_hooks/ (alsa-wrapper.c plugin.vala): fsoaudiod: first draft version of the alsa plugin to control audio session
Apr 12 16:44:08 <morphis> DocScrutinizer: so first steps are done, see commits above :)
Apr 12 16:52:11 <CIA-10> freesmartphone.org: 03mickey 07cornucopia * rfee9a45ec37e 10/fsoaudiod/src/bin/.gitignore: fsoaudiod: add .gitignore
Apr 12 17:00:16 <morphis> mickeyl: ah good thing :)
Apr 12 17:12:22 <jfthomps> I just installed the latest shr-u on my freerunner. I'm working with switching to qvga using "xrandr -s 240x320" to play a video. When I first run xrandr, the screen just goes white. However, if I use dbus to set the idle state to lock, then wait a few seconds, then touch the screen, it is fixed. Any idea what may be happening that "resets" the screen?
Apr 12 17:29:47 <Lopi> pespin: ping
Apr 12 17:51:00 <GNUtoo> http://www.pastie.org/private/vbjmh2csrhvebjjjlzfnsa
Apr 12 17:51:14 <GNUtoo> that error made me out of bound exception
Apr 12 17:55:20 <TAsn> mrmoku, ahhh .38 hit stable, I'm scared, upgrading but scared. :)
Apr 12 17:55:24 <jfthomps> how does one edit/delete contacts in latest shr-u?
Apr 12 17:56:10 <mrmoku> TAsn: :P
Apr 12 17:56:22 <GNUtoo> FORWARDING DOESN"T WORK
Apr 12 17:56:37 <GNUtoo> maybe I should stop USING the om-gta02
Apr 12 17:57:48 <mrmoku> GNUtoo: last time I tried it had problems with ppp in general
Apr 12 17:57:56 <GNUtoo> not PPP
Apr 12 17:58:00 <GNUtoo> but computer->phone
Apr 12 17:58:04 <mrmoku> ahh, ok
Apr 12 17:58:07 <GNUtoo> internet trough computer
Apr 12 17:58:13 <GNUtoo> nano /etc/resolv.conf didn't solve
Apr 12 17:58:16 <GNUtoo> DNS doesn't work
Apr 12 17:59:04 <GNUtoo> the rest work
Apr 12 18:04:50 <mrmoku> GNUtoo: dunno if connman hit the gta02 too... on n900 it is overwriting resolv.conf
Apr 12 18:10:15 <pespin> Lopi, pong
Apr 12 18:10:49 <Lopi> pespin: I'm giving a presentation about my project at my uni ;)
Apr 12 18:11:10 <pespin> mrmoku, yeah, it overwrites it (or it did some days ago)
Apr 12 18:11:34 <pespin> Lopi, ah great, I'll pass you the presentation I used :)
Apr 12 18:11:37 <pespin> when do you have it?
Apr 12 18:12:08 <pespin> because I'm quite busy this week and I still have to translate it :P
Apr 12 18:12:47 <pespin> s/have/give
Apr 12 18:17:41 <GNUtoo> it hit om-gta02 too
Apr 12 18:17:49 <GNUtoo> bbs
Apr 12 18:22:00 <CIA-10> freesmartphone.org: 03morphis 07utilities * r5556a445b165 10/palmpre/fso-installer/Makefile: fso-installer: correct target dependencies so the webOS doctor is only extracted once
Apr 12 18:22:02 <CIA-10> freesmartphone.org: 03morphis 07utilities * r4399a6ad54c5 10/palmpre/fso-installer/Makefile: fso-installer: cleanup and enhancements
Apr 12 18:23:08 <morphis> GarthPS: ping
Apr 12 18:23:21 <GarthPS> morphis: yop
Apr 12 18:23:49 <morphis> GarthPS: you got the bug report from sC about his failures with the fso-installer?
Apr 12 18:24:23 <GarthPS> yep but it is not suffisant for the momment to know what went wrong.. I send you by mail ?
Apr 12 18:24:40 <morphis> don't think so
Apr 12 18:24:51 <morphis> btw. I fixed the unpack-doctor-everytime bug
Apr 12 18:25:41 <morphis> GarthPS: but you will take care about his report?
Apr 12 18:25:42 <GarthPS> morphis: yep I am reading through the diff 
Apr 12 18:26:06 <GarthPS> morphis: yep but I need him do respond some more of my questions :)
Apr 12 18:26:26 <GarthPS> we know where it hang but don't know why
Apr 12 18:26:59 <morphis> ok
Apr 12 18:27:11 <morphis> but it is good to know you both are working on this
Apr 12 18:28:26 <GarthPS> morphis: yep. it is just not alway easy to  find what is done differently. but ther are some weird thing like "I used root as i got some java errors as a normal user..."
Apr 12 18:28:49 <GarthPS> that I don't underdstand for the moment.
Apr 12 18:35:16 <morphis> ok
Apr 12 18:35:21 <captainigloo> morphis, i just commit regression correction for elfe
Apr 12 18:35:44 <captainigloo> ah i forgot saving config for dock .... grrrrr
Apr 12 18:35:48 <morphis> captainigloo: yeah :)
Apr 12 19:09:40 <CIA-10> freesmartphone.org: 03mickey 07cornucopia * rf377baaf8c7a 10/fsogsmd/src/plugins/modem_nokia_isi/ (isitransport.vala mediators.vala): fsogsmd: modem_nokia_isi: misc changes in startup sequence
Apr 12 19:09:45 <CIA-10> freesmartphone.org: 03mickey 07libgisi * r251d01a41762 10/ (gisicomm/gisicomm.vala tests/testping.vala): gisicomm: misc. additions in startup sequence
Apr 12 19:23:06 <JaMa|Wrk> Q-Master: pong
Apr 12 19:24:04 <Q-Master> JaMa|Wrk: do you know how to make networkmanager to set nameserver to what i want but not it wants?
Apr 12 19:25:13 <JaMa|Wrk> Q-Master: you mean connman? and no :/
Apr 12 19:25:40 * JaMa|Wrk prefers static configuration :/
Apr 12 19:25:56 <Q-Master> JaMa|Wrk: damn. searched why there's no ping to www.ru from my neo after previous update...
Apr 12 19:26:47 <mickeyl> mrmoku: if you want, you can run another test w/ the current state of fsogsmd and libgisi. I'm not too enthusiastic, but at least it would be interesting to see what happens now that we send the STARTUP_SYNQ. I'm afraid if this doesn't work, we need to try sending the whole startup sequence via sendisi to see whether this cuts it.
Apr 12 19:27:54 <mickeyl> mrmoku: the MTC state is looking quite good via the indications (MTC_NORMAL, MTC_READY), but the actual call still errors out with 224, which is quite strange
Apr 12 19:29:03 <Q-Master> JaMa|Wrk: why connman again?
Apr 12 19:35:34 <JaMa|Wrk> fsodeviced connman plugin, but don't know why exactly
Apr 12 19:35:51 <JaMa|Wrk> s/fsodeviced/fsogsmd/
Apr 12 19:35:51 <apt> JaMa|Wrk meant: fsogsmd connman plugin, but don't know why exactly
Apr 12 19:36:26 <JaMa|Wrk> probably to handle ppp connection like every other available connection
Apr 12 19:42:39 <morphis> Q-Master: as JaMa|Wrk said, fsogsmd has a connman plugin for handling ppp connections since one week
Apr 12 19:42:53 <morphis> Q-Master: but it's not needed
Apr 12 19:43:02 <morphis> if you don't want connman
Apr 12 19:43:15 <morphis> it's only a DEPEND not a RDEPEND
Apr 12 19:45:12 <mrmoku> mickeyl: great, will try :)
Apr 12 19:45:37 <mrmoku> mickeyl: hacking on the wireshark plugin slowed down a bit unfortunately
Apr 12 19:45:47 * mrmoku having father in law in da house :P
Apr 12 19:46:22 <mickeyl> hehe
Apr 12 19:46:24 <mickeyl> ok
Apr 12 19:47:13 <mickeyl> i'm afraid I'm missing something essential and won't find out what until i have replicated the whole startup sequence up to 1:1 *sigh*
Apr 12 19:47:29 <mrmoku> heh... yeah... fun :/
Apr 12 19:47:50 <mrmoku> maybe I should take a closer look at the differences between ofono and maemo
Apr 12 19:47:54 <mrmoku> see what they have in common
Apr 12 19:48:51 <mickeyl> it might also be helpful to see whether ofono also manages to setup the thing via forwarding. if they fail the same way as we do, then i should probably stop trying that and rather move on to the device
Apr 12 19:49:10 <mrmoku> yeah, interesting too
Apr 12 19:49:38 <mrmoku> though I think in the beginning that was the way to try ofono on the n900
Apr 12 19:51:47 <mickeyl> yes. the critical thing is the init
Apr 12 19:52:01 <mickeyl> everything works fine via forwarding e.g. in parallel to maemo
Apr 12 19:52:12 <mickeyl> but the init sequence is just killing me
Apr 12 19:52:20 <CIA-10> freesmartphone.org: 03morphis 07utilities * r8dbafe67e314 10/palmpre/fso-installer/Makefile: fso-installer: fix path to nova installer
Apr 12 19:52:59 <CIA-10> freesmartphone.org: 03mickey 07libgisi * re3636358e2f0 10/ (data/libgisi.vapi gisicomm/gisicomm.vala): add GSS (General Stack Server) client
Apr 12 20:02:34 <CIA-10> freesmartphone.org: 03morphis 07cornucopia * rfd923b2dc33a 10/fsoaudiod/MAINTAINERS: fsoaudiod: correct MAINTAINERS file
Apr 12 20:05:23 <CIA-10> freesmartphone.org: 03mickey 07libgisi * r9df8dcaabd9e 10/data/libgisi.vapi: add SS (Subscriber Services) client
Apr 12 20:05:25 <CIA-10> freesmartphone.org: 03mickey 07libgisi * r7b6ec459fe66 10/gisicomm/gisicomm.vala: gisicomm: add GSS and SS high level clients
Apr 12 20:11:55 <mrmoku> mickeyl: should I restart my build? :P
Apr 12 20:12:14 <mrmoku> nah, as it finished will try first :)
Apr 12 20:12:47 <mickeyl> no, the additions are irrelevant for now
Apr 12 20:12:50 <mrmoku> ok
Apr 12 20:12:57 <mickeyl> they are in preparation of replicating the startup sequence 1:1 :/
Apr 12 20:18:00 <mrmoku> ok... lets see
Apr 12 20:18:44 <mrmoku> mickeyl: hmm... no
Apr 12 20:18:44 <mrmoku> 1970-01-01T00:04:17.329956Z [DEBUG] fsogsmd : GLib <gisicomm>: gisicomm.vala:102: NETLINK STATE = PN_LINK_DOWN
Apr 12 20:18:50 <mrmoku> right after SendAuthCode
Apr 12 20:19:11 <mickeyl> fun, this again
Apr 12 20:19:35 <mickeyl> i thought we were over at least that link thingy
Apr 12 20:19:58 <mrmoku> hmm... ofono was running :/
Apr 12 20:20:05 * mrmoku retries with a clean boot and without ofono
Apr 12 20:24:41 <mrmoku> mickeyl: the same without ofono
Apr 12 20:24:57 <mickeyl> ok
Apr 12 20:25:07 <mrmoku> 1970-01-01T00:01:47.020777Z [DEBUG] NokiaIsiModem <phonet:phonet0>: Created mediator FsoGsmSimSendAuthCode
Apr 12 20:25:10 <mrmoku> 1970-01-01T00:01:47.083191Z [INFO]  NokiaIsiModem <phonet:phonet0>: Modem Status changed to FSO_GSM_MODEM_STATUS_ALIVE_SIM_READY
Apr 12 20:25:13 <mrmoku> 1970-01-01T00:01:52.162384Z [DEBUG] fsogsmd : GLib <gisicomm>: gisicomm.vala:102: NETLINK STATE = PN_LINK_DOWN
Apr 12 20:25:16 <mrmoku> 1970-01-01T00:01:52.164093Z [DEBUG] fsogsmd : GLib <gisicomm>: gisicomm.vala:102: NETLINK STATE = PN_LINK_UP
Apr 12 20:25:29 <mickeyl> when i have some time i try to replicate the startup sequence exactly. if it still doesn't work after that, i finally throw the towel.
Apr 12 20:25:39 <mrmoku> heh, ok
Apr 12 20:25:53 <mickeyl> it's too much pain, really
Apr 12 20:26:16 <mickeyl> foss ought to be fun and i don't mind an occasional painful phase, but that has been going on for too long
Apr 12 20:26:28 <mrmoku> yup :/
Apr 12 20:28:11 <mickeyl> anyways, your work on the dissector will help me to replicate the startup sequence, so thanks for working on that
Apr 12 20:28:25 <mrmoku> well thank you still working on isi :-)
Apr 12 20:28:35 <mrmoku> I like this piece of hw... 
Apr 12 20:35:41 <mrmoku> mickeyl: hmm...maybe the link going down is 'normal' and we just react wrong?
Apr 12 20:36:12 <mrmoku> the last packet in the dump is a net_ciphering_ind
Apr 12 20:36:38 <mickeyl> net ciphering ind means we're almost registered
Apr 12 20:36:45 <mickeyl> otherwise we wouldn't get any
Apr 12 20:37:09 <mrmoku> yeah, so your changes had the effect that it does something more automatically
Apr 12 20:37:19 <mrmoku> and in the end the link is going down at the same point
Apr 12 20:37:24 <mickeyl> yep
Apr 12 20:37:44 <mrmoku> but maybe the link is allowed to go down?
Apr 12 20:38:54 <mickeyl> hmm
Apr 12 20:39:09 <mickeyl> uhmm
Apr 12 20:39:25 <mickeyl> n900.c is not calling netlink_start anymore
Apr 12 20:40:34 <mickeyl> ah, wait it's in nokia-gpio.c
Apr 12 20:41:26 <mickeyl> hmm
Apr 12 20:41:27 <mickeyl> say...
Apr 12 20:41:31 <mrmoku> aka our lowlevel... where we removed the netlink stuff...
Apr 12 20:41:34 <mickeyl> do we actually do what they do in there?
Apr 12 20:41:46 <mickeyl> like in phonet_status_cb
Apr 12 20:41:52 <mickeyl> that looks interesting
Apr 12 20:41:58 <mickeyl> it might be a watchdog
Apr 12 20:42:15 <mickeyl> we're not lowering cmt_rst_rq after netlink comes up...
Apr 12 20:42:26 <mickeyl> that might be it
Apr 12 20:42:38 <mrmoku> ohh
Apr 12 20:42:44 <mrmoku> and then after some time it goes boom
Apr 12 20:42:48 <mrmoku> that would make sense :-)
Apr 12 20:42:48 <mickeyl> yes
Apr 12 20:43:23 <mickeyl> what do i need to write where to to replicate  GPIO_WRITE(cmt_rst_rq, 0); ?
Apr 12 20:43:33 <mickeyl> it needs to be done in the gisicomm code, so i'd try that
Apr 12 20:43:59 <mickeyl> or perhaps you can try that
Apr 12 20:44:03 <mickeyl> i need to run now
Apr 12 20:44:15 <mickeyl> the line would have to be inserted in
Apr 12 20:44:19 <mrmoku> mickeyl:         FsoFramework.FileHandling.write( value_to_gpio_string( value ), filename_for_gpio_line( line ) );
Apr 12 20:44:23 <mrmoku> is what it does
Apr 12 20:44:29 <mrmoku> value is "1" or "0"
Apr 12 20:44:29 <mickeyl> gisicomm.vala:108
Apr 12 20:44:45 <mrmoku> mickeyl: ok, will try
Apr 12 20:45:01 <mickeyl> thanks a lot
Apr 12 20:45:03 <mickeyl> good luck...
Apr 12 20:45:27 <mickeyl> bbl
Apr 12 20:45:47 <mrmoku> thanks
Apr 12 21:01:28 <mrmoku> morphis: hmm... what is the next best thing to FileHandling.write if I have no FsoFramework available?
Apr 12 21:09:13 <mrmoku> probably Posix.write
Apr 12 21:30:25 <CIA-10> freesmartphone.org: 03mok 07libgisi * r6bfbd47f0d81 10/gisicomm/ (Makefile.am gisicomm.vala): 
Apr 12 21:30:25 <CIA-10> freesmartphone.org: gisicomm: lower cmt_rst_rq when the link comes up
Apr 12 21:30:25 <CIA-10> freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Apr 12 21:33:54 <CIA-10> freesmartphone.org: 03mok 07libgisi * raf57d23430f4 10/gisicomm/gisicomm.vala: 
Apr 12 21:33:54 <CIA-10> freesmartphone.org: gisicomm: duh... lower - not the contrary
Apr 12 21:33:54 <CIA-10> freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Apr 12 21:39:40 <GNUtoo|bug20> lol
Apr 12 21:39:55 <GNUtoo|bug20> anyway is the modem supposed to work now?
Apr 12 21:43:23 <mrmoku> no :/
Apr 12 21:43:31 <mrmoku> probably I did something wrong though
Apr 12 21:45:27 <mrmoku> duhh... indeed I did something wrong :P
Apr 12 21:46:22 <CIA-10> freesmartphone.org: 03mok 07libgisi * r2aca0a7bf518 10/gisicomm/gisicomm.vala: 
Apr 12 21:46:22 <CIA-10> freesmartphone.org: gisicomm: cmt_rst_rq is a directory... write to value in there instead :P
Apr 12 21:46:22 <CIA-10> freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Apr 12 21:46:40 <mrmoku> lets see if that is better :)
Apr 12 21:49:36 <mrmoku> no :/
Apr 12 21:49:42 * mrmoku gives up for today
Apr 12 21:49:54 <mrmoku> gnight all
**** ENDING LOGGING AT Wed Apr 13 02:59:57 2011