**** BEGIN LOGGING AT Wed Jun 06 02:59:58 2012
Jun 06 07:22:29 <CIA-76> freesmartphone.org: 03morphis 07specs * r4b88cfe8bc9b 10/html/index.html: Bumping the version changed html index page too
Jun 06 07:22:31 <CIA-76> freesmartphone.org: 03morphis 07specs * rb2ddf04d2121 10/ (3 files in 3 dirs): Rework the org.freesmartphone.GSM.CallForwarding completely
Jun 06 07:22:31 <CIA-76> freesmartphone.org: 03morphis 07specs * r784287e631dc 10/ (configure.ac html/index.html): Bump version to 2012.06.06.01
Jun 06 07:23:04 <CIA-76> freesmartphone.org: 03morphis 07libfso-glib * r0f17bd56dd54 10/configure.ac: Keep up with fso-specs version
Jun 06 07:24:29 <CIA-76> freesmartphone.org: 03morphis 07specs * r415b5cf119fa 10/ (2 files in 2 dirs): It should be doc:summary instead of doc:description for arguments
Jun 06 07:25:12 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * re9a66834f03d 10/ (13 files in 13 dirs): Bump required libfso-glib version to 2012.06.06.01
Jun 06 07:25:12 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * re7986cfc5b87 10/fsogsmd/src/plugins/dbus_service/gsm_call_forwarding_service.vala: fsogsmd: dbus_service: implement recent version of the call forwarding dbus interface
Jun 06 09:54:19 <CIA-76> SHR: 03Martin.Jansa 07meta-smartphone * rc228db37c848 10/meta-fso/recipes-freesmartphone/cornucopia/fsodeviced-modules_1.0.bb: meta-fso: drop fsodeviced-modules_1.0 it was replaced by 0.11.0 and git version with higher PE
Jun 06 09:54:28 <CIA-76> SHR: 03Martin.Jansa 07meta-smartphone * rf5f2f1c0bcce 10/meta-shr/recipes-core/dbus/dbus_1.4.16.bbappend: dbus: drop bbappend with PRINC
Jun 06 09:54:28 <CIA-76> SHR: 03Martin.Jansa 07meta-smartphone * r6213f446ace9 10/meta-shr/conf/distro/include/preferred-shr-versions.inc: meta-shr: prefer dbus-1.5%
Jun 06 10:12:00 <JaMa> dos1: hi, do you plan to fix that jquery thing any time soon or should I disable it to allow users download shr-2012.01 release?
Jun 06 11:18:00 <CIA-76> SHR: 03shr-devel 07buildhistory * r456844ab9005 10/packages/ (670 files in 670 dirs): packages: Build 201206061205 of shr 20120606 for machine om-gta02 on opmbuild
Jun 06 11:27:32 <ayaka> Alex[sp3dev] hello
Jun 06 11:28:06 <ayaka> you aren't sleep, are you
Jun 06 11:28:15 <Alex[sp3dev]> ayaka: hi. my mind is full of fuck
Jun 06 11:28:50 <ayaka> Alex[sp3dev] I am sorry, I can't understnad you, are you busy
Jun 06 11:29:08 <ayaka> understand
Jun 06 11:31:16 <ayaka> could I ask you some question about lk_bootloader
Jun 06 11:35:02 <ayaka> what is the SCRATCH_ADDR, and how shall I set MEMSIZE,
Jun 06 11:42:05 <ayaka> sorry, I knew the sentence, wish you well
Jun 06 12:00:30 <Alex[sp3dev]> ayaka: SCRATCH_ADDR is used to hold zImage/boot.img when it is downloaded from usb
Jun 06 12:00:36 <Alex[sp3dev]> memsize doesn't matter
Jun 06 12:06:28 <ayaka> Alex[sp3dev] I see, but where is an empty place to load lk_bootloader, it is chainboot, it may cover some bios rom
Jun 06 12:08:03 <ayaka> is there nothing in 0x0
Jun 06 12:10:09 <ayaka> Alex[sp3dev]  http://paste.debian.net/173128/  and in this file, it doesn't have my mem setting
Jun 06 12:11:23 <ayaka> http://paste.debian.net/173129/ it is my rules.mk
Jun 06 12:12:53 <Alex[sp3dev]> ayaka: i'm busy debugging uboot, sorry. will email you tonight
Jun 06 12:13:54 <ayaka> sorry, it is me that disturb you, please tell me more detail and some debugging way
Jun 06 12:14:26 <ayaka> in the mail
Jun 06 12:20:24 <CIA-76> SHR: 03shr-devel 07buildhistory * rf930107f7d33 10/packages/ (670 files in 670 dirs): packages: Build 201206061327 of shr 20120606 for machine nokia900 on opmbuild
Jun 06 12:47:57 <CIA-76> SHR: 03shr-devel 07buildhistory * rd60077d8a214 10/packages/om_gta04-oe-linux-gnueabi/ (24 files in 24 dirs): packages: Build 201206061429 of shr 20120606 for machine om-gta04 on opmbuild
Jun 06 13:14:34 <CIA-76> SHR: 03shr-devel 07buildhistory * rb724d1f225d4 10/images/crespo/eglibc/chroot-image/ (build-id image-info.txt installed-package-sizes.txt): images: Build 201206061456 of shr 20120606 for machine crespo on opmbuild
Jun 06 13:14:44 <CIA-76> SHR: 03shr-devel 07buildhistory * re1d3a3c6cb5d 10/packages/crespo-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201206061456 of shr 20120606 for machine crespo on opmbuild
Jun 06 13:33:40 <GNUtoo-desktop> morphis, hi
Jun 06 13:36:01 <morphis> GNUtoo-desktop: heyho
Jun 06 13:37:23 <GNUtoo-desktop> morphis, http://trac.freesmartphone.org/ticket/687 :  GTA04: mdbus2 -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.ListResources => (['GSM', 'Display', 'CPU'],)
Jun 06 13:38:15 <GNUtoo-desktop> any ideas for that?
Jun 06 13:38:18 <morphis> whats Data?
Jun 06 13:38:29 <GNUtoo-desktop> what do you mean?
Jun 06 13:38:59 <GNUtoo-desktop> ah ok
Jun 06 13:39:03 <GNUtoo-desktop> 3G I guess
Jun 06 13:39:08 <GNUtoo-desktop> it doesn't work either
Jun 06 13:39:12 <GNUtoo-desktop> and wifi is broken too
Jun 06 13:39:23 <GNUtoo-desktop> I forgott to add it in the bugreport for wifi
Jun 06 13:39:45 <morphis> what does this mean, wifi is broken?
Jun 06 13:39:49 <morphis> resource is missing?
Jun 06 13:40:01 <GNUtoo-desktop> yes
Jun 06 13:40:24 <GNUtoo-desktop> GSM Display and CPU are the only resources on gta04
Jun 06 13:40:35 <GNUtoo-desktop> oops
Jun 06 13:40:45 <GNUtoo-desktop> s/oops//
Jun 06 13:40:45 <apt> GNUtoo-desktop meant: 
Jun 06 13:40:55 <mrmoku> morphis: that was the thing you wanted to fix we talked about the other day :-)
Jun 06 13:41:14 <GNUtoo-desktop> when?
Jun 06 13:41:22 <GNUtoo-desktop> if it was yesterday,no
Jun 06 13:41:24 <morphis> mrmoku: I fixed the rfkill ralted issue for fsodeviced
Jun 06 13:41:30 <GNUtoo-desktop> when?
Jun 06 13:41:30 <morphis> s/ralted/related/
Jun 06 13:41:32 <apt> morphis meant: mrmoku: I fixed the rfkill related issue for fsodeviced
Jun 06 13:41:34 <mrmoku> hmm
Jun 06 13:41:44 <morphis> with 0.11.4 of fsodeviced
Jun 06 13:41:48 <morphis> and that fix is also in master
Jun 06 13:41:49 <GNUtoo-desktop> because that issue is from an image built yesterday
Jun 06 13:41:56 <morphis> hm
Jun 06 13:42:05 <GNUtoo-desktop> with autorev of course
Jun 06 13:42:08 <morphis> is it also in the staging images?
Jun 06 13:42:18 <GNUtoo-desktop> no idea
Jun 06 13:42:27 <GNUtoo-desktop> I don't think staging images uses autorev
Jun 06 13:42:28 <morphis> ok
Jun 06 13:42:31 <morphis> yes
Jun 06 13:42:36 <morphis> they are at 0.11
Jun 06 13:42:39 <GNUtoo-desktop> but maybe it's old enough to get the bug
Jun 06 13:42:43 <GNUtoo-desktop> ok
Jun 06 13:42:48 <morphis> but they are counting for the SHR project
Jun 06 13:43:03 <morphis> if we want SHR stable, get the staging images stable
Jun 06 13:43:06 <GNUtoo-desktop> I'm trying to get GTA04 usable
Jun 06 13:43:19 <GNUtoo-desktop> that implies making sure HEAD work
Jun 06 13:43:32 <CIA-76> SHR: 03shr-devel 07buildhistory * rf15554af2dfe 10/packages/palmpre-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201206061525 of shr 20120606 for machine palmpre on opmbuild
Jun 06 13:43:32 <GNUtoo-desktop> because HEAD will hit shr-stable at some point
Jun 06 13:43:34 <morphis> HEAD of master you mean
Jun 06 13:43:38 <GNUtoo-desktop> yes
Jun 06 13:44:06 <morphis> yes and no
Jun 06 13:44:24 <morphis> if we have a bug in 0.11 I will make a bug fix release
Jun 06 13:44:33 <morphis> as I can not say when 0.12 will happen
Jun 06 13:44:41 <morphis> so maybe it's too late for SHR 2012.07
Jun 06 13:44:58 <morphis> so from the SHR point of view 0.11 should get stable as possible
Jun 06 13:45:17 <morphis> and I can not take care of that master will all time be stable and usable
Jun 06 13:45:24 <GNUtoo-desktop> I want to fix in master, what should I do
Jun 06 13:45:33 <GNUtoo-desktop> I've no clues when reading the logs
Jun 06 13:45:40 <morphis> check wether it's relevant for 0.11 too
Jun 06 13:45:50 <morphis> then we can port it over to 0.11
Jun 06 13:45:55 <morphis> (if it's a bug)
Jun 06 13:46:03 <GNUtoo-desktop> ok I'll do once the bug is fixed
Jun 06 13:46:33 <morphis> for the resource thing it is related to the configure option
Jun 06 13:46:44 <morphis> as there is a #ifdef in the source to register the resources or not
Jun 06 13:46:46 <GNUtoo-desktop> ahhh ok
Jun 06 13:46:51 <morphis> in kernel26_rfkill/plugin.vala
Jun 06 13:46:53 <GNUtoo-desktop> like rfkill disabled
Jun 06 13:47:00 <morphis> yes
Jun 06 13:47:08 <GNUtoo-desktop> let me look
Jun 06 13:47:08 <morphis> or no
Jun 06 13:47:14 <morphis> resource integration disabled
Jun 06 13:47:55 <GNUtoo-desktop> in fsodeviced or fsousaged?
Jun 06 13:48:17 <GNUtoo-desktop> --enable-kernel26-rfkill
Jun 06 13:48:17 <morphis> look for WANT_FSO_RESOURCE
Jun 06 13:48:20 <morphis> in fsodeviced
Jun 06 13:48:21 <GNUtoo-desktop> ah ok
Jun 06 13:48:25 <morphis> it's no necessary
Jun 06 13:48:34 <morphis> per default resource integration is enabled
Jun 06 13:49:48 <GNUtoo-desktop> http://pastie.org/private/o5kw1ehjhl5bdkuhlrbsw
Jun 06 13:51:06 <morphis> ah I got the problem
Jun 06 13:51:13 <morphis> the bug is not in 0.1
Jun 06 13:51:14 <morphis> 1
Jun 06 13:51:18 <morphis> only in master
Jun 06 13:51:55 <GNUtoo-desktop> ok
Jun 06 13:51:59 <GNUtoo-desktop> what is the problem then?
Jun 06 13:52:06 <GNUtoo-desktop> the WANT_FSO_RESOURCE ?
Jun 06 13:53:01 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * rbebfaa55d106 10/fsogsmd/src/ (4 files in 3 dirs): fsogsmd: dbus_service: implement call forwarding API and forward handling to mediators
Jun 06 13:53:02 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * r4cffb1636b11 10/fsodeviced/src/plugins/kernel26_rfkill/Makefile.am: fsodeviced: kernel26_rfkill: use AM_VALAFLAGS for compilation; fixes #687
Jun 06 13:53:09 <morphis> GNUtoo-desktop: ^^
Jun 06 13:53:15 <GNUtoo-desktop> ok thanks a lot!!!!
Jun 06 13:53:28 <prahal>   would http://git.prahal.homelinux.net/~prahal/phone/udev/usb-net.rules be of interest to shr ?
Jun 06 13:54:08 <prahal> I at least need it when using iface usb0 inet dhcp in /etc/network/interfaces
Jun 06 13:54:11 <GNUtoo-desktop> prahal, is it for doing ifup usb0 only when usb is plugged?
Jun 06 13:55:00 <JaMa> yes staging 061 has this fix, but 062 is waiting for fsogsmd fix..
Jun 06 13:55:09 <JaMa> ^ this fsodeviced fix
Jun 06 13:55:11 <prahal> and ifdown when it is unplugged (otherwise with dhcp I loose the ip on unplug but do not get it back on plug
Jun 06 13:56:41 <prahal> with thiose (the script and the interfaces set to dhcp) I only need to create a connection in NM and set ipv4 to "share with other computers" and I am done
Jun 06 13:57:29 <prahal> it requires NM 0.9.4 s before the shared with other computers settings was buggy
Jun 06 13:58:16 <morphis> JaMa: staging 061 boots for me directly into emergency mode on GTA02
Jun 06 13:58:34 <morphis> with "Dependency failed. Aborted start of /media/card"
Jun 06 13:58:58 <prahal> suc a setup might be better left for testers on the wiki at first . though it might be of interest (work out of the box, no need to setup iptables or anything command line related)
Jun 06 13:59:26 <morphis> JaMa: yeah the fix is in 0.11 but with my recent changes in master I reintroduced it :)
Jun 06 13:59:45 <GNUtoo-desktop> prahal, ifdown when no usb is used is very good and fixes some bugs
Jun 06 13:59:49 <morphis> btw. as prahal is mentioned usbnet here
Jun 06 13:59:55 <GNUtoo-desktop> maybe JaMa could add it
Jun 06 13:59:55 <morphis> what about a dhcp server on the phone?
Jun 06 14:00:15 <morphis> so I don't have to do anything one my PC/laptop when attaching the phone
Jun 06 14:00:16 <GNUtoo-desktop> morphis, part of FSO/SHR depend on installing that
Jun 06 14:00:33 <morphis> GNUtoo-desktop: which one?
Jun 06 14:00:34 <GNUtoo-desktop> like the forwarding of the data connection(3g/gprs)
Jun 06 14:00:42 <JaMa> morphis: without uSD?
Jun 06 14:00:45 <JaMa> morphis: just jffs?
Jun 06 14:00:45 <morphis> JaMa: yes
Jun 06 14:01:02 <JaMa> morphis: you have to remove mmc line from fstab :/
Jun 06 14:01:11 <morphis> JaMa: why that?
Jun 06 14:01:20 <prahal> morphis: you would have to setup iptables on the computer with a dhcp server on the phone to forward traffic
Jun 06 14:01:48 <morphis> prahal: yeah, but that should not be a problem when the phone as a static ip address
Jun 06 14:02:02 <prahal> but yes I have not investigated the other option . use the pĥone as AP for a computer
Jun 06 14:02:10 <JaMa> morphis: I've seen the same on gta04 where I had fstab entry to mount /data from non-existent partition on uSD
Jun 06 14:02:27 <GNUtoo-desktop> morphis, btw is there some progress on bluetooth integration design?
Jun 06 14:02:35 <JaMa> morphis: systemd tries to mount all fstab entries and when fails it goest to emergency mode
Jun 06 14:02:43 <morphis> baah
Jun 06 14:02:43 <JaMa> morphis: adding noauto to /data is enough
Jun 06 14:02:45 <GNUtoo-desktop> like SCO and A2DP
Jun 06 14:03:07 <morphis> GNUtoo-desktop: not SCO/A2DP but I took a look at HFP
Jun 06 14:03:27 <morphis> but HFP is using SCO right?
Jun 06 14:03:38 <GNUtoo-desktop> morphis, what's HFP?
Jun 06 14:03:48 <morphis> hands-free-protocol
Jun 06 14:03:53 <GNUtoo-desktop> ok
Jun 06 14:04:08 <JaMa> morphis: http://www.shr-project.org/trac/ticket/1958
Jun 06 14:04:24 <prahal> JaMa: lines ending with "1" only I believe
Jun 06 14:04:46 <JaMa> ?
Jun 06 14:05:21 <prahal> the "pass" column
Jun 06 14:05:33 <morphis> JaMa: ok, will take a look
Jun 06 14:06:03 <JaMa> prahal: haven't tested this, but you're probably right
Jun 06 14:06:36 <prahal> ie I was looking for a systemd+fstab issue yesterday and stumbled on a post of maintainer telling the 6 field was the critical one for systemd
Jun 06 14:07:48 <JaMa> hmm looking at old fstab with /data entry it was failing even without pass == 1
Jun 06 14:08:31 <JaMa> and on gta02 we have
Jun 06 14:08:33 <JaMa> /dev/mmcblk0p1       /media/card          auto       defaults,sync         0  0
Jun 06 14:09:31 <prahal>  http://lists.freedesktop.org/archives/systemd-devel/2011-June/002600.html <- might be unrelated to your issue .... in fact the 6th field is used by systemd to find which partitions it should fsck
Jun 06 14:10:20 <CIA-76> SHR: 03shr-devel 07buildhistory * r36488137ab5c 10/packages/palmpre2-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201206061552 of shr 20120606 for machine palmpre2 on opmbuild
Jun 06 14:10:46 <JaMa> ah, yes it fails to mount not for fsck
Jun 06 14:12:06 <JaMa> morphis: if you confirm it starts to work with noauto I'll update fstab in gta02 base-files
Jun 06 14:12:27 <JaMa> morphis: I can even provide you with meta-smartphone patch if you want to just rebuild jffs2 image
Jun 06 14:12:58 <prahal> ok then unrelated (and it was rebooting undefinitely due to fsck failing - libcomerr was removed by a crash and it depended on this lib - not going to emergency) sorry for the noise
Jun 06 14:31:35 <morphis> JaMa: no I don't have and environment to build the image locally
Jun 06 14:31:39 <morphis> only GTA04
Jun 06 14:31:43 <morphis> so no armv4t
Jun 06 14:34:01 <JaMa> and do you have free uSD card to install it there (and possibly fix fstab in NAND from there?) or I can give you image..
Jun 06 14:34:12 <GNUtoo-desktop> morphis, should I bugreport for that too:
Jun 06 14:34:22 <GNUtoo-desktop> root@om-gta04:~# mdbus2 -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.ActivateContext => [ERR]: GDBus.Error:org.freesmartphone.InternalError: Failed to active PDP context: OK
Jun 06 14:35:11 <JaMa> morphis: jffs2 or ubi?
Jun 06 14:35:11 <morphis> GNUtoo-desktop: yes, please but if the steps you did to setup up the context
Jun 06 14:35:14 <morphis> JaMa: jffs2
Jun 06 14:43:33 <GNUtoo-desktop> http://trac.freesmartphone.org/ticket/688
Jun 06 14:46:51 <JaMa> morphis: http://jama.dyndns-home.com/org.openembedded.shr-core.images/om-gta02/shr-image-om-gta02-20120606143523.rootfs.jffs2
Jun 06 14:48:38 <morphis> JaMa: FEHLER 404: Not Found.
Jun 06 14:49:37 <morphis> JaMa: you copied only shr-image-om-gta02-20120606143523.rootfs.jffs2.nosummary
Jun 06 14:56:43 <JaMa> sorry I've added only jffs2 to IMAGE_TYPES.. not both "jffs2 sum.jffs2" so it was removed after that
Jun 06 15:00:21 <morphis> ok
Jun 06 15:09:01 <JaMa> morphis: this one should stay :) http://jama.dyndns-home.com/org.openembedded.shr-core.images/om-gta02/shr-image-om-gta02-20120606145721.rootfs.jffs2
Jun 06 15:45:36 <GNUtoo-desktop> morphis, do you want me to move the palmpre in the hardware status comparaison for you?
Jun 06 16:02:43 <morphis> GNUtoo-desktop: I would let it stay there for a while
Jun 06 16:02:52 <morphis> maybe someone comes a long and is interested in it
Jun 06 16:03:41 <GNUtoo-desktop> I've already moved it
Jun 06 16:03:52 <GNUtoo-desktop> but it clearly says:
Jun 06 16:03:59 <GNUtoo-desktop> [edit] Looking for maintainers hardware 
Jun 06 16:05:09 <morphis> ah ok
Jun 06 16:08:44 <GNUtoo-desktop> any idea on what that means:
Jun 06 16:08:49 <GNUtoo-desktop> 2000-01-02T18:08:34.647795Z [WARN]  Gtm601Modem <>: Unexpected length 1 for Gtm601UnderscoreOWANDATA
Jun 06 16:09:01 <GNUtoo-desktop> it's in my PDP context activation bugreport
Jun 06 16:09:23 <GNUtoo-desktop> beside I tested crespo:
Jun 06 16:09:43 <GNUtoo-desktop> good: usb0 seem to work if you ifdown ifup usb0
Jun 06 16:09:52 <GNUtoo-desktop> bad: still the same MNC MCC bug
Jun 06 16:10:15 <GNUtoo-desktop> build is from some minutes ago
Jun 06 16:28:16 <prahal>  which wifi connection manager would one suggest for PEAP WPA2 ?
Jun 06 16:28:47 <prahal> NM or connman ?
Jun 06 16:29:15 <GNUtoo-desktop> JaMa, that package doesn't go in my Image:
Jun 06 16:29:20 <GNUtoo-desktop> gta04-gps-handler-systemd
Jun 06 16:32:17 <prahal> well looks like shr does not ship NM ...
Jun 06 16:32:56 <GNUtoo-desktop> prahal, wpa_supplicant should be shipped tough
Jun 06 16:33:15 <prahal> I am looking after a gui
Jun 06 16:33:24 <GNUtoo-desktop> then there is iliwi
Jun 06 16:33:31 <GNUtoo-desktop> it's the default wifi client
Jun 06 16:33:31 <prahal> does not support PEAP
Jun 06 16:33:38 <GNUtoo-desktop> then add support for PEAP
Jun 06 16:33:42 <GNUtoo-desktop> else there is another way
Jun 06 16:33:47 <GNUtoo-desktop> opkg install connman
Jun 06 16:33:59 <GNUtoo-desktop> and use the integrated efl widget
Jun 06 16:34:02 <prahal> is there a point doing so ... I mean it heavily looks like reinventing the whell
Jun 06 16:34:19 <GNUtoo-desktop> previously we based on connman or something like that
Jun 06 16:34:22 <prahal> hell or wheel :)
Jun 06 16:34:27 <GNUtoo-desktop> people complained because it didn't work well
Jun 06 16:34:47 <prahal> and NM ?
Jun 06 16:34:48 <GNUtoo-desktop> now it works better and people are happier, and also the GUI is better
Jun 06 16:35:03 <GNUtoo-desktop> nm could be bitbaken
Jun 06 16:35:07 <prahal> is there a rationale for it not being shipped ?
Jun 06 16:35:16 <GNUtoo-desktop> network-manager?
Jun 06 16:35:19 <GNUtoo-desktop> or connman
Jun 06 16:35:20 <prahal> yes
Jun 06 16:35:23 <GNUtoo-desktop> connman broke iliwi
Jun 06 16:35:25 <prahal> network-manager
Jun 06 16:35:49 <GNUtoo-desktop> no idea about network-manager
Jun 06 16:35:55 <GNUtoo-desktop> you could try to bitbake it
Jun 06 16:36:00 <prahal> does iliwi add something to fso or is it just for the gui that it is shipped ?
Jun 06 16:36:03 <GNUtoo-desktop> what's your phone?
Jun 06 16:36:09 <prahal> gta02 and gta04
Jun 06 16:36:13 <GNUtoo-desktop> ok
Jun 06 16:36:38 <GNUtoo-desktop> iliwi only uses fso for the resource handling
Jun 06 16:36:49 <GNUtoo-desktop> like "please activate me the wifi card"
Jun 06 16:36:51 <prahal> because indeed running two wifi manager cannot work well (thus iliwi cannot work well with anything else
Jun 06 16:37:15 <GNUtoo-desktop> yes, but currently there is nothing better than iliwi for SHR
Jun 06 16:37:30 <prahal> ok like intone only point is to be able to talk to fso
Jun 06 16:37:31 <GNUtoo-desktop> and connman interfeared with the resource plugin
Jun 06 16:37:53 <GNUtoo-desktop> in gta02 the wifi needs to be unblocked by rfkill
Jun 06 16:38:01 <GNUtoo-desktop> in gta04 it also need ifconfig wlan0 up
Jun 06 16:38:13 <GNUtoo-desktop> on some other device you need to modprobe a module
Jun 06 16:38:28 <GNUtoo-desktop> the way to activate wifi depend on your device
Jun 06 16:38:34 <GNUtoo-desktop> so fso handle that transparently
Jun 06 16:38:37 <GNUtoo-desktop> phone ringing
Jun 06 16:38:51 <prahal> oh I misunderstood something then . fso mangle with the wifi settings directly ?
Jun 06 16:39:03 <prahal> if so it cannot work with any network manager 
Jun 06 16:39:52 <prahal> and we need to reimplement everything 
Jun 06 16:40:28 <prahal> which is like more than the wine project is trying to achieve
Jun 06 16:41:30 <prahal> ie maybe in 20 years it we will reach the feature set of the current gnu/linux layers (but then we will lag by 20 years
Jun 06 16:43:34 <jake42> prahal: fso just makes sure that your wifichip is up and running
Jun 06 16:43:50 <GNUtoo-desktop> indeed
Jun 06 16:44:00 <GNUtoo-desktop> else you need to hook connman or something like that
Jun 06 16:44:26 <GNUtoo-desktop> like connman<->some new fso daemon or fsonetworkd or something like that
Jun 06 16:44:32 <GNUtoo-desktop> but we failed at that
Jun 06 16:44:37 <GNUtoo-desktop> because connman does that:
Jun 06 16:44:55 <GNUtoo-desktop> I don't remember the exact issues
Jun 06 16:45:08 <GNUtoo-desktop> but we had issues with resources conflict between connman and fso
Jun 06 16:45:12 <GNUtoo-desktop> like for instance:
Jun 06 16:45:20 <GNUtoo-desktop> fso want to bring up an interface
Jun 06 16:45:27 <GNUtoo-desktop> and connman put it back down
Jun 06 16:46:34 <jake42> one just would have to finish the work on the iliwi-branch which is using dbus
Jun 06 16:46:35 <prahal> I only workeds on network-manager ... though if using NM one should always use it (ie bring the interface up or down via NM
Jun 06 16:47:00 <jake42> and then extend it to be able to connect to wpa-enterprise
Jun 06 16:47:26 <jake42> networks
Jun 06 16:48:03 <prahal> yes this is the reimplement everything route
Jun 06 16:48:43 <prahal> though this is a road I avoided like hell for 10 years
Jun 06 16:49:08 <jake42> prahal: as I understand it it's just configuring wpa_supplicant over dbus
Jun 06 16:49:40 <jake42> NM is doing the same afaik
Jun 06 16:49:42 <prahal> I need a good rationale when I go against this rule (like it cannot be done otherwise , but it has one bug due to fso calling ifdown directly is weird a rationale
Jun 06 16:49:42 <jake42> thats right
Jun 06 16:50:08 <prahal> ie does not connman provide an API to bring down/up interrfaces ?
Jun 06 16:50:38 <jake42> it does
Jun 06 16:50:55 <jake42> which was the problem
Jun 06 16:51:22 <prahal> then to resolve this bug is just a matter of telling fso to check if connman is managing the net and if so uses its API
Jun 06 16:51:25 * jake42 is goning to have dinner
Jun 06 16:52:16 <JaMa> GNUtoo-desktop: add it to ./meta-openmoko/recipes-core/systemd/systemd-machine-units_1.0.bbappend
Jun 06 16:52:18 <jake42> prahal: should be about right
Jun 06 16:52:56 <GNUtoo-desktop> JaMa, ? you mean I should remove it from the gps activator recipe?
Jun 06 16:53:11 <GNUtoo-desktop> I just need RDEPENDS += somewhere
Jun 06 16:53:14 <GNUtoo-desktop> but I'll look
Jun 06 16:53:45 <GNUtoo-desktop> because I already pushed it
Jun 06 16:54:40 <prahal> because at least on NM when it came to ipv6 or connection sharing the issue was not only about wpa_supplicant (the kernel does slaac which you have to behaves well with , iptables masquerading, sysctl , etc 
Jun 06 16:55:25 <prahal> and complex scenarii like usb0 , wifi , gprs at the same time
Jun 06 16:58:59 <prahal> I was asking whether to use connman or NM merely to know if connman was able to cope or is too simplistic (ie I irond out ipv6 slaac  and sharing connection issues on NM side ... if I could avoid to do it on  connman too it would save time
Jun 06 17:00:25 <JaMa> GNUtoo-desktop: yes, just add RDEPENDS in that bbappend (only for gta04)
Jun 06 17:00:31 <GNUtoo-desktop> ok
Jun 06 17:00:44 <GNUtoo-desktop> without forgetting PN
Jun 06 17:01:11 <JaMa> true
Jun 06 17:03:01 <GNUtoo-desktop> JaMa, also we need to remove fsosystemd
Jun 06 17:03:14 <GNUtoo-desktop> it conflicts with uboot's firmware loading
Jun 06 17:03:23 <GNUtoo-desktop> and prevent firmwares from beeing loaded
Jun 06 17:05:30 <JaMa> I've seen the report
Jun 06 17:05:47 * JaMa still at work..
Jun 06 17:06:10 <GNUtoo-desktop> JaMa, ok
Jun 06 17:08:12 <Alex[sp3dev]> hmm. anyone familiar with omap secure boot? does each OEM have their own private signing key or just TI signs the xloader?
Jun 06 17:15:13 <GNUtoo-desktop> no idea sorry, but if it could be broken that would be interesting
Jun 06 17:15:24 <GNUtoo-desktop> for instance for n900, motorola milestone etc...
Jun 06 17:22:47 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * rf23f746df024 10/fsogsmd/ (src/lib/at/atcommands.vala tests/testatcommand.vala): fsogsmd: lib: at: rework +CCFC command to use regular expressions instead of our AT parser
Jun 06 17:25:10 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * re050cb5c147b 10/fsogsmd/src/lib/consts.vala: fsogsmd: lib: remove unused struct and add default value for BearerClass enumeration
Jun 06 17:26:48 <CIA-76> SHR: 03GNUtoo 07meta-smartphone * r172f3153d0f4 10/meta-openmoko/recipes-core/systemd/systemd-machine-units_1.0.bbappend: meta-openmoko: systemd-machine-units: pull gta04-gps-handler-systemd
Jun 06 17:29:26 <CIA-76> freesmartphone.org: 03morphis 07specs * r74dc4246e8e1 10/ (3 files in 3 dirs): org.freesmartphone.GSM.CallForwarding: use method for status retrieval instead of properties
Jun 06 17:29:29 <CIA-76> freesmartphone.org: 03morphis 07cornucopia * rc0399d4e6cf1 10/fsogsmd/src/ (4 files in 3 dirs): fsogsmd: dbus_service: implement org.freesmartphone.GSM.CallForwarding.GetStatus method
Jun 06 18:09:42 <morphis> GNUtoo-desktop: for #688 can you please enable log level DEBUG for libfsotransport too
Jun 06 18:24:51 <prahal> I found an issue which could be the one at stack when we talked about connman .. ie if connman is started first rfkill cannot get unblocked
Jun 06 18:25:18 <prahal> but ... I also found that if one set to manual then wifi to on in shr settings the same happens
Jun 06 18:26:49 <prahal> or using rfkill commandto blokc unblock also leads to the same issue
Jun 06 18:27:26 <prahal> and modprobe -r libertas_sdio libertas ; modprobe libertas_sdio -> -16 EBUSY
Jun 06 18:28:04 <nschle85> GNUtoo-desktop: i have  cross read the irc log, i was still investiagting the iliwi Wifi resource problem in N900 but no result at the moment, do you know a little bit more about the problem ?
Jun 06 18:28:48 <prahal> might be all those are about the same issue ... fw interaction might be as bad as with mrv8k (ie works the first time but then on reload of the module no go
Jun 06 18:31:12 <prahal> but indeed connman does not look like it is really smart .... ie it set the route and ip right but keeps on setting a nameserver of localhost
Jun 06 18:33:04 <nschle85> GNUtoo-desktop: i dont like the fso implementation, is consuming too much code and does not delegate to existing stuff, so why not have a shell scrift for power on /off wifi and fso is calling that configurable script ?
Jun 06 18:36:29 <prahal> nschle85: looks like we are on the same boat ... wifi+fso+why reimplement the wheel
Jun 06 18:37:13 <prahal> it seems wifi driver quality is at fault
Jun 06 18:37:41 <prahal> so akk kind of tweaks are used to workaround the buggy drivers
Jun 06 18:38:00 <prahal> which plays badly with existing network manager thus network manager are reimplemented
Jun 06 18:38:20 <prahal> and thus we need new gui .... and so forth
Jun 06 18:38:28 <nschle85> prahal: i dont understand why  fso code is full of execs, this is not flexible
Jun 06 18:39:32 <nschle85> in my oppinion fso should be the control structure and the translator from/to dbus interface, the work itself should not be implemented in the fso daemons
Jun 06 18:39:48 <prahal> I have not looked at the code of fso wifi ... only tested the fso api , rfkill , connman at this point (though I did works in the kernel on wifi drivers , and work in network manager
Jun 06 18:40:42 <prahal> might be good to understand that users complaining about NM not working was mostly due to NM developers refusing to work around wifi driver bugs
Jun 06 18:40:58 <prahal> instead they prefer to push for the drivers to get fixed
Jun 06 18:41:28 <nschle85> prahal: thare are different plugins for wifi, one is for ifconfig, but thats not necessary , there should be one for shell scripts and machine /distro specific stuff should be in shell scripts
Jun 06 18:41:30 <prahal> a lot of drivers have improved due to this requirement
Jun 06 18:42:01 <nschle85> for instance the path to ifconfig is hardcoded to /sbin/ifconfig 
Jun 06 18:42:11 <prahal> gee
Jun 06 18:43:10 <nschle85> for a simple change a new compilation is necessary, thats not flexible
Jun 06 18:43:43 <nschle85> fso knows too much about distros and devices...
Jun 06 18:45:33 <prahal> could be in binary form though that would be in blobs that one can compile without resorting to compile fso itself (like e17 is doing for most of its stuff 
Jun 06 18:46:39 <nschle85> prahal: yes delegating to something existing (binary or not)
Jun 06 18:46:42 <prahal> though I bet the hurry is on to get things working always .. and we ends up with a big binary 
Jun 06 18:47:10 <nschle85> prahal: but this is windows style not unix
Jun 06 18:47:18 <prahal> yup
Jun 06 18:47:54 <prahal> and in the end it means everything needs to ciomply to this new big binary interface
Jun 06 18:48:15 <prahal> thus we have a linux without the gnu 
Jun 06 18:48:35 <nschle85> prahal: i agree
Jun 06 18:48:49 <prahal> time to send patches :)
Jun 06 18:49:16 <nschle85> but now we should  make things working because changing working things is much easier :-)
Jun 06 18:51:26 <prahal> not always ... improving step by step is way more efficient than going from a working unflexible base
Jun 06 18:52:53 <prahal> I found so while working on ralink drivers ... they provide gpl drivers ... so tied to windows (they use the same codebase for windows, mac and linux ) that in the end I spent less time reverse engineering the windows only driver than navigating through the layers of abstractions of the existing gpl driver
Jun 06 18:56:35 <nschle85> prahal: i also dont like tweaks  but its one way tzo avoid duplicate code
Jun 06 18:57:55 <nschle85> prahal: in non object oriented environments its usual
Jun 06 19:00:03 <PaulFertser> prahal: does ralink still maintain their gpl linux drivers? I thought they now contribute directly to the rt2x00, don't they?
Jun 06 19:00:36 <prahal> could be ... I did not had time to work on rt2x00 since nearly 2 years
Jun 06 19:01:08 <prahal> on opensync the same
Jun 06 19:01:59 <slyon_> hey!
Jun 06 19:02:09 <GNUtoo-desktop> morphis, ok
Jun 06 19:02:10 <PaulFertser> btw, my personal opinion on rfkill is that softblock rfkill should never be used for power control (or anything else at all).
Jun 06 19:02:31 <GNUtoo-desktop> nschle85, opkg remove fsosystemd
Jun 06 19:03:22 <nschle85> GNUtoo-desktop: ?? ironic ?
Jun 06 19:04:14 <mickeyl> yo
Jun 06 19:04:50 <prahal> PaulFertser: fsodeviced disagree from the log 
Jun 06 19:05:06 <nschle85> hello mickeyl :-)
Jun 06 19:06:08 <slyon_> hey mickeyl
Jun 06 19:06:09 <GNUtoo-desktop> nschle85, not at all
Jun 06 19:06:15 <GNUtoo-desktop> fsosystemd conflicts with dbus
Jun 06 19:06:20 <GNUtoo-desktop> oops
Jun 06 19:06:23 <GNUtoo-desktop> fsosystemd conflicts with udev
Jun 06 19:06:32 <GNUtoo-desktop> hi mickeyl 
Jun 06 19:06:52 <GNUtoo-desktop> for firmware loading
Jun 06 19:08:17 <slyon_> JaMa, is there a possibility to install some file only for one machine, e.g. do_install_append_gta04() ?
Jun 06 19:08:17 <GNUtoo-desktop> slyon_, hi
Jun 06 19:08:30 <JaMa> slyon_: e.g. base-files
Jun 06 19:08:31 <GNUtoo-desktop> slyon_, what files do you want to install?
Jun 06 19:08:40 <nschle85> mickeyl: i hope you are not angry about me when i say that i dont like fso architecture/implementation
Jun 06 19:08:52 <slyon_> hey GNUtoo-desktop. I saw you fixed the alsa_fowarder. great you! kudos!
Jun 06 19:09:02 <GNUtoo-desktop> kudos to DocScrutinizer 
Jun 06 19:09:09 <DocScrutinizer06> hmm?
Jun 06 19:09:23 <nschle85> GNUtoo-desktop: which forwarder for n900 ?
Jun 06 19:09:25 <DocScrutinizer06> oh
Jun 06 19:09:32 <GNUtoo-desktop> gta04
Jun 06 19:09:38 <mickeyl> nschle85: heh, not at all, anyone here is entitled to his own opinion :)
Jun 06 19:09:38 <prahal> PaulFertser: also how could you control the wifi by software ?
Jun 06 19:09:39 <DocScrutinizer06> GNUtoo-desktop: it workedß :-d
Jun 06 19:09:42 <DocScrutinizer06> :-D
Jun 06 19:09:46 <DocScrutinizer06> dang
Jun 06 19:09:54 <DocScrutinizer06> GNUtoo-desktop: it worked? :-D
Jun 06 19:09:54 <GNUtoo-desktop> indeed
Jun 06 19:09:57 <GNUtoo-desktop> yes
Jun 06 19:10:11 <PaulFertser> prahal: you can bring interfaces up and down with "ip l" (or directly via netlink) and wireless-specific stuff with nl80211.
Jun 06 19:10:36 <nschle85> mickeyl: i think fso should act as a framework but it provides API for concrete implementations
Jun 06 19:10:39 <morphis> nschle85: what in detail you don't like within the fso architecture/implementation?
Jun 06 19:10:57 <slyon_> GNUtoo-desktop, i want to install a shr logo for radeks graphical boot initrd
Jun 06 19:11:20 <prahal> PaulFertser: but the radio ?
Jun 06 19:11:30 <GNUtoo-desktop> morphis, it worked this time....strange
Jun 06 19:11:41 <mickeyl> nschle85: well, we have the consumer API and the services reference implementation. which one (or both?) is your grief about?
Jun 06 19:11:42 <GNUtoo-desktop> slyon_, ok good idea
Jun 06 19:11:44 <PaulFertser> prahal: when all the interfaces are down the driver puts the device to sleep, that's all one might need.
Jun 06 19:12:21 <nschle85> morphis: concrete: activating Wifi is done by the N900 plugin why ? a hook for a script or binary should be enough, so no machine dependency should be necessary
Jun 06 19:12:39 <nschle85> pathes are hardcoded /sbin/ifconfig 
Jun 06 19:12:50 <morphis> :)
Jun 06 19:13:05 <mickeyl> that boils down to breakage of indivdual plugins
Jun 06 19:13:12 <morphis> there is some quick-and-dirty code in FSO :)
Jun 06 19:13:51 <mickeyl> indeed, there is
Jun 06 19:14:09 <GNUtoo-desktop> morphis, I've that currently: 2012-06-06T19:11:02.191009Z [DEBUG] libfsotransport <Serial /dev/ttyHS_Application@115200 (fd 20)>: SRC: "_OWANDATA?" -> [ "_OWANDATA: 1, 151.82.117.169, 0.0.0.0, 193.70.152.25, 212.52.97.25, 0.0.0.0, 0.0.0.0,144000", "OK" ] 2012-06-06T19:11:02.191680Z [DEBUG] Gtm601Modem <>: Did receive a valid response for Gtm601UnderscoreOWANDATA
Jun 06 19:14:32 <morphis> GNUtoo-desktop: and interace is up and configured?
Jun 06 19:14:39 <nschle85> so every plugin using exec calls should be evaluated, so change exec calls to external hooks is more flexible and frees fso from machine / distro knowledge
Jun 06 19:14:49 <GNUtoo-desktop> yes apart a small SHR bug
Jun 06 19:15:25 <GNUtoo-desktop> http://shr-project.org/trac/ticket/2016
Jun 06 19:15:52 <slyon> JaMa, hmm in base files it is somehow done using directories... can't i just use do_install_append_om-gta04() in the recipe?
Jun 06 19:16:36 <nschle85> mickeyl: morphis: so why make use of  fso specific audio scenario files ?
Jun 06 19:16:56 <mickeyl> nschle85: yes to part 1. part 2 is a matter of the plugin implementation. fsoXXXd _is_ the actual framework, the plugins are of varying quality. i don't believe dropping off to external binaries will be a valid way to implement some of the tough things, but it might be a nice addition for simple things.
Jun 06 19:16:57 <morphis> nschle85: they are not FSO specific
Jun 06 19:17:53 <nschle85> mickeyl: morphis: who else can read that files ?
Jun 06 19:18:11 <mickeyl> everything that uses libascenario
Jun 06 19:18:35 <mickeyl> that's the library the asoc inventor came up with
Jun 06 19:19:53 <morphis> nschle85: and who else uses scenarios files that way we're using them today?
Jun 06 19:20:00 <prahal> is there an alsa plugin for to select a default scenario (applications not talking to fso) which could for example tell fso about this access ?
Jun 06 19:20:23 <GNUtoo-desktop> morphis, aha now I've the error
Jun 06 19:20:25 <GNUtoo-desktop> let me look
Jun 06 19:20:42 <morphis> prahal: not really, there is a plugin for alsa tells fsoaudiod when a applications uses ALSA to play some audio
Jun 06 19:21:35 <morphis> nschle85: and when you're dropping of to external scripts/binaries you're still machine specific
Jun 06 19:21:41 <DocScrutinizer06> hi mickeyl, hi PaulFertser
Jun 06 19:21:43 <mickeyl> hi DocScrutinizer06 
Jun 06 19:21:50 <CIA-76> SHR: 03lukasmaerdian 07shr-themes * ra746d723fb79 10/shr-splash/shr-splash-theme-logo/om-gta04/logo.bmp: shr-splash-theme-logo: add logo for gta04 initrd bootloader
Jun 06 19:21:59 <morphis> we're trying to avoid the be too much machine specific but sometimes it's impossible
Jun 06 19:22:09 <morphis> s/the//
Jun 06 19:22:12 <apt> morphis meant: we're trying to avoid  be too much machine specific but sometimes it's impossible
Jun 06 19:22:49 <morphis> nschle85: and if you're looking at the concrete plugins they are small, most things are done outside in a general fashin so other plugins can use them too
Jun 06 19:23:05 <morphis> mickeyl: I hope you're now fine with this: http://git.freesmartphone.org/?p=cornucopia.git;a=commit;h=f23f746df02433ce9ff72c4697bc7017a818832e
Jun 06 19:23:08 <morphis> :)
Jun 06 19:23:29 <nschle85> morphis: true but  fso itself  is more stable and  its not necessary to recompile fso
Jun 06 19:23:54 <morphis> in detail you just need to recompile the plugin
Jun 06 19:23:54 <DocScrutinizer06> prahal: (there is a plugin for alsa tells fsoaudiod) that's core of my ACI concept
Jun 06 19:23:59 <morphis> the core stays untouched
Jun 06 19:24:08 <morphis> but I know what you want to say
Jun 06 19:24:15 <nschle85> with alsa you can save the current configuration and activate them with alsactl
Jun 06 19:24:22 <morphis> having a stable generic core and separating the plugins
Jun 06 19:24:24 <GNUtoo-desktop> ah I think the APN vanish somehow
Jun 06 19:24:41 <mickeyl> morphis: i am, thanks for reconsidering that!
Jun 06 19:24:47 <morphis> :)
Jun 06 19:24:56 <morphis> mickeyl: btw. do you have some free time this weekend?
Jun 06 19:25:01 <GNUtoo-desktop> ah no
Jun 06 19:25:19 <morphis> GNUtoo-desktop: sometimes we're too fast with the _OWANDATA call so it returns no data at all
Jun 06 19:25:38 <mickeyl> morphis: i take the next 4 days off, so i might have. what should i do?
Jun 06 19:25:47 <morphis> mickeyl: some skype session
Jun 06 19:25:51 <prahal> DocScrutinizer06: thanks ... I planned to look at this issue (still on gta02 I frequently have scenario mixup .... time to look at this plugin and its interactions
Jun 06 19:26:01 <morphis> mickeyl: taking about various things
Jun 06 19:26:06 <mickeyl> morphis: sounds good
Jun 06 19:26:17 <GNUtoo-desktop> morphis, http://trac.freesmartphone.org/ticket/688#comment:2
Jun 06 19:26:41 <morphis> mickeyl: do you have some prefered time or day?
Jun 06 19:26:58 <prahal> about plugins ... something like edje_cc would be neat :)
Jun 06 19:27:03 <GNUtoo-desktop> will bluetooth be included in the talks?
Jun 06 19:27:19 <morphis> GNUtoo-desktop: with that log you don't get an active context?
Jun 06 19:27:20 <mickeyl> morphis: saturday afternoon might work best
Jun 06 19:27:26 <morphis> GNUtoo-desktop: yes
Jun 06 19:27:30 <morphis> mickeyl: ok
Jun 06 19:27:31 <mickeyl> morphis: somewhat between 15 and 18 or so
Jun 06 19:27:41 <morphis> mickeyl: ok, I will be online, just call me
Jun 06 19:27:45 <mickeyl> excellent, will do
Jun 06 19:27:48 <morphis> great
Jun 06 19:28:43 <GNUtoo-desktop> morphis, yes
Jun 06 19:28:51 <GNUtoo-desktop> and thanks for caring about bluetooth
Jun 06 19:28:58 <GNUtoo-desktop> I want bluetooth since ages
Jun 06 19:29:00 <morphis> GNUtoo-desktop: :)
Jun 06 19:30:44 <DocScrutinizer06> prahal: the very basic idea is to have a plugin in ALSA thjat executes arbitrary command on an app opening and on closing an alsadevice. This command in most basic case is a script that executes amixer commands rather than loading a whole scenario via alsactl
Jun 06 19:31:44 <DocScrutinizer06> the amixer commands are designed/selected carefully to only affect those mixer controls that actually are involved with the stuff this particular app wants to do
Jun 06 19:32:28 <DocScrutinizer06> e.g for palyback of touchscreen audible feedback there's no need and reason to mess with microphone settings
Jun 06 19:33:00 <prahal> ok ... might by that "Media" control is not taken into account 
Jun 06 19:34:06 <DocScrutinizer06> next layer of "intelligence" and specialization on top of this is a central process that executes the scripts, so it always knows about which app occupied which mixer control, so any conflicts will get handled by that arbiter process
Jun 06 19:34:06 <prahal> I saw it was not included in the scenarii
Jun 06 19:35:49 <morphis> GNUtoo-desktop: you tested the PDP stuff with master, right?
Jun 06 19:36:28 <GNUtoo-desktop> yes
Jun 06 19:36:38 <nschle85> DocScrutinizer06:  but  are scenario files the right thing for that ?
Jun 06 19:37:01 <DocScrutinizer06> another detail already existing in alsa since ages but needed for a working ACI are softvol plugins, which allow a dedicated volume slider in arbitrary audio mixer app for each app using ACI alsadevice
Jun 06 19:37:15 <prahal> DocScrutinizer06: perfect . thus any issue I found is just a matter of a missing control or a bug . less fun but easier target
Jun 06 19:37:18 <DocScrutinizer06> nschle85: definitely not
Jun 06 19:38:21 <nschle85> so you are talking about a problem which is  more complicated i was talking about
Jun 06 19:39:02 <DocScrutinizer06> possible
Jun 06 19:39:34 <DocScrutinizer06> I was mentioning ACI, as it has plugins to notify on opening audio device
Jun 06 19:39:59 <DocScrutinizer06> which is the core idea of ACI
Jun 06 19:40:26 <nschle85> DocScrutinizer06:  do you like  fso architecture ?
Jun 06 19:40:51 <DocScrutinizer06> basically yes, modulo a few minor implementation details
Jun 06 19:41:21 <DocScrutinizer06> e.g. I don't think alsa-forwarder should run in fso context
Jun 06 19:41:27 <nschle85> so why do i have to learn and compile fso to get wifi powered on ?
Jun 06 19:41:34 <DocScrutinizer06> it should just get started and stopped by fso
Jun 06 19:41:51 <nschle85> DocScrutinizer06: i mean learn vala
Jun 06 19:42:09 <DocScrutinizer06> vala being another point that doesn't make me cheer
Jun 06 19:42:23 <nschle85> but at the moment fso=vala
Jun 06 19:42:30 <DocScrutinizer06> :nod:
Jun 06 19:43:05 <DocScrutinizer06> which more than once defeated the widespread use (or even consideration of use) of fso
Jun 06 19:43:42 <DocScrutinizer06> system architects are amazingly concervative
Jun 06 19:44:17 <DocScrutinizer06> so e.g. mer and meego (and tizen) didn't consider using fso
Jun 06 19:44:54 <DocScrutinizer06> I suggest mickeyl renames to lennart ;-D
Jun 06 19:45:55 <mickeyl> if it wasn't for the vala reimplementation FSO would be dead by now
Jun 06 19:46:04 <nschle85> DocScrutinizer06:  but to make  fso  more attractive , "plugins" may have been developed in all other languages
Jun 06 19:46:10 <DocScrutinizer06> I guess systemd could've been written in prolog or whitespace and still we would see it replacing sysV-init in each and every distro, just like we do now ;-)
Jun 06 19:46:30 <mickeyl> no problem with plugins in other languages
Jun 06 19:46:33 <mickeyl> as long as they have a C ABI
Jun 06 19:47:16 <DocScrutinizer06> ~poettering
Jun 06 19:47:17 <apt> 'sth is poettering' means it acts invasive, possessive, destructive, and generally in an egocentric exacerbating negative way. ``this cancer is extremely poettering''
Jun 06 19:47:19 <nschle85> mickey, thats the problem, FSO forces API  and is not only a framework
Jun 06 19:47:33 <mickeyl> well
Jun 06 19:47:38 <mickeyl> rm -rf *plugins*
Jun 06 19:47:42 <mickeyl> then you have the framework
Jun 06 19:47:54 <mickeyl> without the API FSO is useless
Jun 06 19:48:03 <DocScrutinizer06> indeed
Jun 06 19:48:05 <mickeyl> as it has been written to offer services to apps
Jun 06 19:48:37 <DocScrutinizer06> well, for that I'd think the API is plain dbus, noß
Jun 06 19:48:51 <mickeyl> FSO is not a self-powered thing, it exists because we want to write apps that do not have to cope with many low level things
Jun 06 19:48:51 <DocScrutinizer06> dafaq, ?
Jun 06 19:49:16 <mickeyl> yes, the API is dbus, that's it. nothing more, nothing less
Jun 06 19:49:29 * DocScrutinizer06 wonders why his fingers love "ß" that much
Jun 06 19:50:30 <morphis> nschle85: what in detail you want to do in FSO to get the WiFI on the N900 working?
Jun 06 19:50:49 <DocScrutinizer06> and despite I think dbus is a special piece of  crap on its own, I couldn't come up with a better idea for an API for a framework like FSO
Jun 06 19:51:00 <prahal> my main issue is about how the framework (plugins) interact with the underlying system ... 
Jun 06 19:51:03 <prahal> not the api
Jun 06 19:51:08 <nschle85> mickeyl: but fso is reimplementing too many things or is strong coupled to underlying software
Jun 06 19:51:28 <mickeyl> you think so? 
Jun 06 19:51:32 <mickeyl> what for example?
Jun 06 19:51:44 <mickeyl> if there's something you rather want to control on your own, deactivate the plugin
Jun 06 19:51:52 <mickeyl> it's mix and match for system integrators
Jun 06 19:52:13 <mickeyl> although you might stop apps from being able to control the things then
Jun 06 19:52:23 <nschle85> mickeyl: hard coded pathes,  activating wifi
Jun 06 19:52:35 <DocScrutinizer06> uh?
Jun 06 19:52:41 <mickeyl> please don't judge from the n900 plugins
Jun 06 19:52:53 <mickeyl> FSO can't be blamed for odd ways to control hardware
Jun 06 19:52:55 <nschle85> mickeyl: ok shutdown
Jun 06 19:52:55 <morphis> nschle85: as we already said, some stuff is crap, done quick and dirty
Jun 06 19:53:20 <nschle85> mickeyl: shutdown was the example
Jun 06 19:53:31 <morphis> nschle85: system shutdown?
Jun 06 19:53:37 <nschle85> yes
Jun 06 19:53:38 <mickeyl> suspend, resume, and shutdown should go through FSO in order to provide a safe deactivating of resources
Jun 06 19:53:54 <mickeyl> that's a common problem of a demultiplexer
Jun 06 19:54:08 <mickeyl> i.e. something that channels multiple ways of access to one physical resourc
Jun 06 19:54:10 <nschle85> and the shutdown command itself ?
Jun 06 19:54:19 <GNUtoo-desktop> hmmm
Jun 06 19:54:21 <nschle85> where is it configured ?
Jun 06 19:54:24 <GNUtoo-desktop> | gsm_call_forwarding_service.vala:116.18-116.56: error: The type name `FreeSmartphone.GSM.CallForwardingStatus' could not be found
Jun 06 19:54:28 <GNUtoo-desktop> I'll retry
Jun 06 19:54:42 <mickeyl> no idea, do we use a command or do we call the kernel facilities?
Jun 06 19:54:55 <mickeyl> if we use a command, it might as well be configurable
Jun 06 19:55:02 <morphis> GNUtoo-desktop: you need to rebuild libfso-glib and specs
Jun 06 19:55:09 <mickeyl> no problem with adding that, if it's missing
Jun 06 19:55:10 <GNUtoo-desktop> ok
Jun 06 19:55:16 <GNUtoo-desktop> thanks
Jun 06 19:55:19 <prahal> could not this be done in systemd ? or via a systemd unit
Jun 06 19:55:34 <nschle85> the correct answer should be we use the command configured in .
Jun 06 19:56:13 <mickeyl> cooperating with init daemons is something that has been on the list of things to improve since ages. but what to support? sysv, upstart, systemd?
Jun 06 19:56:15 <mickeyl> it's not trivial
Jun 06 19:56:40 <nschle85> mickeyl: the one the distribution configured 
Jun 06 19:56:48 * DocScrutinizer06 kills systemd with fire
Jun 06 19:56:54 <morphis> nschle85: look into fsousaged.conf, there is a section called fsousage with an entry shutdown_command
Jun 06 19:56:58 <prahal> sysv has no concept of deps, upstart what s the point
Jun 06 19:57:26 <DocScrutinizer06> meh
Jun 06 19:57:40 <mickeyl> you see, there it starts
Jun 06 19:57:42 <JaMa> slyon: yes you can in ./meta-openmoko/recipes-core/base-files/base-files_3.0.14.bbappend
Jun 06 19:57:46 <mickeyl> everyone wants support for another init system
Jun 06 19:57:49 <DocScrutinizer06> suse flavour of sysv-init has deps since decades, literally
Jun 06 19:57:51 <prahal> DocScrutinizer06: systemd or upstart/systemd/inserv
Jun 06 19:57:52 <mickeyl> and there are millions of
Jun 06 19:57:53 <morphis> nschle85: if the distribution wants to it can use a different shutdown command and most init systems implements their own shutdown command
Jun 06 19:58:02 <nschle85> morphis: this exists because i telled mrmoku it should be configurable but fso is not configurable  as it should be
Jun 06 19:58:19 <morphis> nschle85: thats because FSO is developed on demands of users
Jun 06 19:58:24 <morphis> it's not complete
Jun 06 19:58:26 <morphis> or finished
Jun 06 19:58:29 <morphis> just in development
Jun 06 19:58:32 <morphis> not finished
Jun 06 19:58:51 <morphis> if I as developer implement something I can have all use cases in mind
Jun 06 19:59:11 <morphis> I am trying to implement the common solution everybody can live with 
Jun 06 19:59:27 <morphis> if the config option is missing, go and add it
Jun 06 19:59:30 <morphis> nobody cares
Jun 06 19:59:39 <morphis> but thats not fundamental
Jun 06 19:59:47 <DocScrutinizer06> sure we care - supply patches!
Jun 06 20:00:23 <DocScrutinizer06> the pint is FSO is modular
Jun 06 20:00:28 <DocScrutinizer06> point
Jun 06 20:00:34 * DocScrutinizer06 heads out for a pint
Jun 06 20:00:37 <mickeyl> heh
Jun 06 20:01:03 <morphis> nschle85: FSO is a real community project
Jun 06 20:01:27 <morphis> no big company behind just a few people having fun with doing development for FSO
Jun 06 20:01:42 <DocScrutinizer06> with a competent mastermind doing the hard lifting of keeping the concept coherent
Jun 06 20:01:51 <morphis> DocScrutinizer: yes
Jun 06 20:01:52 <nschle85> the problem is that fso is defined in face of dbus api but underlying api is growing .... and not flexible enough
Jun 06 20:02:15 <morphis> underlying API?
Jun 06 20:03:57 <morphis> FSO's API is defined from the view of the applications on top of it
Jun 06 20:04:30 <morphis> as mickeyl said, it abstracts the lowlevel things like powercontrol so a application just has to say it wants Wifi and gets wifi without caring about to many low level stuff
Jun 06 20:04:49 <morphis> it can abstract most things
Jun 06 20:05:02 <mickeyl> if the dbus API turns out to be not flexible enough, since the underlying hardware can do more than the API would allow, then it might be time to enhance the API
Jun 06 20:05:08 <mickeyl> or augment
Jun 06 20:05:37 <morphis> I dealt with a lot of different subsystems, palmpre, nexus s, gta04 ... and never I got into the situation to change the API cause I can not integrate something the devices offer
Jun 06 20:05:40 <morphis> just take the GSM API
Jun 06 20:06:02 <morphis> it takes all aspects and is suitable for a lot of different modem protocols
Jun 06 20:06:23 <morphis> it suites for AT, Samung IPC, Msmcomm, Ponet, .... whats greater than that?
Jun 06 20:06:39 <nschle85> morphis: but implementig ""wants  wifi" has to be  done by learning vala and fso plugin api
Jun 06 20:07:24 <morphis> nschle85: if the device would follow common concepts it would not be needed
Jun 06 20:07:37 <nschle85> morphis: fso should be an intelligent layer between dbus and well defined hooks
Jun 06 20:07:48 <morphis> what you would do in Meego or Ubuntu to get wifi working?
Jun 06 20:07:54 <morphis> nschle85: it is
Jun 06 20:08:18 <morphis> just say you want to do a shell script for getting wifi working, right?
Jun 06 20:09:01 <nschle85> morphis: i would like to remove the intelligence to get wifi working from fso
Jun 06 20:09:15 <morphis> and do where?
Jun 06 20:09:41 <nschle85> somewhere else
Jun 06 20:10:05 <GNUtoo-desktop> prahal, btw could you bugreport your udev thing for ifup ifdown?
Jun 06 20:10:33 <morphis> nschle85: but still integrate it with FSO powercontrol API?
Jun 06 20:11:07 <nschle85> yes
Jun 06 20:11:55 <morphis> so you don't like doing it with vala?
Jun 06 20:12:34 <morphis> you want to do it in another daemon?
Jun 06 20:12:47 <nschle85> morphis: yes for this task it should not be necessary to change the framework
Jun 06 20:13:49 <morphis> nschle85: you're not changing the framework
Jun 06 20:13:57 <morphis> with doing another power control
Jun 06 20:14:06 <nschle85> morphis: its also not necessary to recompile systemd if i develop a new daemon
Jun 06 20:14:40 <morphis> nschle85: as I said you just have to recompile the plugin and deliver it
Jun 06 20:14:49 <morphis> but as things are we can't do this today
Jun 06 20:15:05 <morphis> thats an infrastructure thing
Jun 06 20:16:24 <mickeyl> the analogy between systemd and fso does not work 100%. systemd is more loosely coupled towards its "plugins", since it merely does process control. FSO is more than starting and stopping. How do you want to implement a GSM plugin with a bunch of scripts?
Jun 06 20:16:31 <nschle85> morphis: yup, its a question of current infrastructure
Jun 06 20:17:10 <morphis> nschle85: so we agree that there is no problem with the framework or the implementation itself
Jun 06 20:17:27 <morphis> nschle85: you can do out-of-tree plugins
Jun 06 20:17:40 <nschle85> mickeyl: what is the interface of a gsm plugin ?
Jun 06 20:17:54 <mickeyl> nschle85: it would be about 50 different methods
Jun 06 20:18:00 <mickeyl> or more
Jun 06 20:18:16 <mickeyl> and if you want to call a script every time, you will not get much of a phone call ;)
Jun 06 20:18:26 <morphis> :)
Jun 06 20:18:30 <mickeyl> seriously, unfortunately due to the way hardware vendors to their stuff, something simple as power control is completely non-trivial on many devices :/
Jun 06 20:18:53 <mickeyl> if all you want is writing scripts for power control, it's easy enough to implement a script proxy plugin in fsodeviced
Jun 06 20:19:05 <mickeyl> that delegates powering on and off to your script
Jun 06 20:19:13 <nschle85> mickeyl: the interface should not be wider than the current fso or ofono interface
Jun 06 20:19:16 <mickeyl> i don't think it's a good idea
Jun 06 20:19:20 <mickeyl> but if you want... do it
Jun 06 20:19:24 <morphis> there is still a bug in our trac to do this for hooks on suspend and resume
Jun 06 20:20:21 <mickeyl> yeah, i remember
Jun 06 20:20:35 <mickeyl> it complicated things a lot, that's why it hasn't been implemented yet
Jun 06 20:20:46 <mickeyl> all the bridging to external processes is a can of worms
Jun 06 20:20:56 <mickeyl> as you have to do lots of code to handle all possible failure cases
Jun 06 20:21:03 <morphis> yes
Jun 06 20:21:06 <mickeyl> and even then... it gets unreliable
Jun 06 20:21:08 <mickeyl> IMO
Jun 06 20:21:22 <morphis> and it's still unclear if anybody really needs it
Jun 06 20:21:37 <mickeyl> yep
Jun 06 20:21:54 <mickeyl> if absolutely necessary on one device, it might as well find the way into a quirks plugin
Jun 06 20:22:01 <morphis> for sure
Jun 06 20:22:13 <mickeyl> so we have the quirks at least in one place, not spread over into dozens of scripts
Jun 06 20:22:20 <morphis> nschle85: you mean the interface between the modem plugins and the core?
Jun 06 20:22:38 <nschle85> mickeyl: morphis: what i want to tell is: fso should be more flexible for developers, tasks like switch something on / off or get some information should not be implemented in bash style in vala and hardcoded in fso
Jun 06 20:23:09 <nschle85> morphis: i mean the  dbus apis 
Jun 06 20:23:20 <mickeyl> what is bash style?
Jun 06 20:23:36 <nschle85> exec(a) exec(b)
Jun 06 20:23:40 <DocScrutinizer06> WUT?
Jun 06 20:24:50 <mickeyl> well
Jun 06 20:24:51 <mickeyl> again
Jun 06 20:25:06 <mickeyl> exec is probably called in less than 10 places
Jun 06 20:25:21 <mickeyl> that's almost nothing
Jun 06 20:25:39 <mickeyl> but still, i welcome those calls to be either made configurable or removed, so that we don't call external processes
Jun 06 20:25:53 <mickeyl> if that's all your complaint, we can easily enough fix that part ;)
Jun 06 20:26:05 <DocScrutinizer06> that's a detail where I like to differ
Jun 06 20:26:15 <mrmoku> :)
Jun 06 20:26:20 <mickeyl> heh
Jun 06 20:26:26 <DocScrutinizer06> hi mrmoku
Jun 06 20:26:30 <mrmoku> yo all
Jun 06 20:27:10 <nschle85> mickeyl: morphis: but why reimplement all N900 stuff and not reuse ofono ?
Jun 06 20:27:37 <morphis> nschle85: we're resuing ofono parts for N900
Jun 06 20:27:41 <mickeyl> because FSO was first. because FSO has the better API.
Jun 06 20:27:42 <DocScrutinizer06> WAAAAH!
Jun 06 20:27:48 <morphis> :D
Jun 06 20:28:11 <morphis> nschle85: we're believing in FSO
Jun 06 20:28:16 <DocScrutinizer06> why didn't ofono reuse FSO??
Jun 06 20:28:24 <morphis> ask intel :)
Jun 06 20:28:31 <mickeyl> (and again, it's mix and match... if you don't like fsogsmd, you can just not use it)
Jun 06 20:28:45 <DocScrutinizer06> was a rhethorical question
Jun 06 20:28:53 <morphis> yes, you don't need to use the FSO GSM api but can use the rest
Jun 06 20:28:53 <nschle85> DocScrutinizer06: because sms  wouldnt work
Jun 06 20:29:18 <DocScrutinizer06> *burrp* -- time for some dinner&booze fun
Jun 06 20:30:07 <morphis> nschle85: sms for n900 in FSO does not work as nobody implemented it
Jun 06 20:30:31 <nschle85> this is what i want to tell: ofono=sms working fso=wont use ofono  so no sms
Jun 06 20:30:46 <morphis> then go and use ofono on the N900
Jun 06 20:30:55 <morphis> thats all I can say
Jun 06 20:31:07 <morphis> but it's not a decision for the framework
Jun 06 20:31:16 <morphis> s/framework/stack/
Jun 06 20:31:17 <apt> morphis meant: but it's not a decision for the stack
Jun 06 20:31:31 <morphis> it's a implementation detail for the N900 system
Jun 06 20:31:46 <nschle85> morphis: so why fso framework cannot use ofono ?
Jun 06 20:32:25 <mrmoku> well... making ofono work with the SHR gui is certainly more work than making sms in fsogsmd work for n900 ;-)
Jun 06 20:33:05 <mickeyl> nschle85: because the ofono guys don't have a reusable library
Jun 06 20:33:16 <mickeyl> and doing a Dbus mapping is braindead
Jun 06 20:33:42 <mrmoku> indeed :-P
Jun 06 20:35:59 <GNUtoo-desktop> again as I told before the problem is the forwarder not the rest
Jun 06 20:36:02 <GNUtoo-desktop> for n900
Jun 06 20:36:07 <DocScrutinizer06> because ofono is braindead, from beginning. They accused FOS to "simply implement an AT interface to modem, while 'we' can do soooo much more and better" - now it looks to me it's exactly the other way round: ofono is implementing the AT interface and can't do anything but phone, while FSO always been designed and specified to deal with *all* middleware issues on an embedded device
Jun 06 20:36:27 <mickeyl> can't say it more elegant, DocScrutinizer06 .
Jun 06 20:36:29 <GNUtoo-desktop> lol 
Jun 06 20:36:31 <mickeyl> *nod*
Jun 06 20:36:48 <DocScrutinizer06> s/FOS/FSO/.
Jun 06 20:37:10 <morphis> DocScrutinizer: great words!
Jun 06 20:37:12 <mickeyl> sms might take a week of work to get it integrated in fsogsmd
Jun 06 20:37:30 <mickeyl> as things stand, i can't see neither time nor motivation to do that
Jun 06 20:37:31 <morphis> mickeyl: less as I abstracted most things already
Jun 06 20:37:37 <mickeyl> ok, even less
Jun 06 20:38:25 <morphis> four methods to implement
Jun 06 20:38:26 <morphis>     protected abstract async string retrieveImsiFromSIM();
Jun 06 20:38:26 <morphis>     protected abstract async void fillStorageWithMessageFromSIM();
Jun 06 20:38:26 <morphis>     protected abstract async bool readSmsMessageFromSIM( uint index, out string hexpdu, out int tpdulen );
Jun 06 20:38:26 <morphis>     protected abstract async bool acknowledgeSmsMessage( int id );
Jun 06 20:38:40 <morphis> + one mediator for sending the message
Jun 06 20:38:46 <mickeyl> cool
Jun 06 20:39:08 <morphis> storage etc. is shared with the other implementations
Jun 06 20:39:19 <morphis> nschle85: so if you want, go and implement SMS for the N900
Jun 06 20:39:57 <morphis> AT one is done in less than 150 lines (minus lines for comments etc.)
Jun 06 20:40:16 <morphis> if you go over to ofono you have to take care about all the message c foo stuff
Jun 06 20:42:26 <GNUtoo-desktop> nschle85, what's your current problem with wifi?
Jun 06 20:42:39 <GNUtoo-desktop> then you should make better audio scenarios
Jun 06 20:42:40 <nschle85> mickeyl: morphis: so why not write a ofono plugin instead of reimplementing all the stuff ?
Jun 06 20:42:44 <GNUtoo-desktop> else I'll have to do it
Jun 06 20:42:50 <DocScrutinizer06> nschle85: if you think ofono is the better fsogsmd, you're free to develop a fsofono-janus plugin
Jun 06 20:43:10 <prahal> GNUtoo-desktop: yes . I will post it (though it adds more binding to a non hardcoded utility : ifupdown ... might be able to do this via fso api + mdbus ?
Jun 06 20:43:26 <prahal> reading the backlog as I want to eat something
Jun 06 20:43:28 <DocScrutinizer06> sth I suggested several times, just to ashame those ofono guys ;-)
Jun 06 20:43:29 <nschle85> GNUtoo-desktop: if i start iliwi i cannot scan because  wifi is not up
Jun 06 20:43:34 <morphis> nschle85: what kind of ofono plugin?
Jun 06 20:44:06 <GNUtoo-desktop> nschle85, ah simple stuff
Jun 06 20:44:12 <GNUtoo-desktop> nschle85, try ifconfig wlan0 up
Jun 06 20:44:14 <nschle85> morphis: i mean a fso plugin mappinmg to ofono
Jun 06 20:44:16 <GNUtoo-desktop> if it works try that:
Jun 06 20:44:25 <morphis> nschle85: you really want to do that?
Jun 06 20:44:30 <GNUtoo-desktop> there is a plugin for ifconfig wlan0 up
Jun 06 20:44:51 <GNUtoo-desktop> nschle85, we must make a plan for n900
Jun 06 20:44:56 <GNUtoo-desktop> what to do first
Jun 06 20:45:12 <morphis> nschle85: is it worse to do it?
Jun 06 20:45:23 <DocScrutinizer06> morphis: see my last line
Jun 06 20:45:48 <morphis> :)
Jun 06 20:45:55 <DocScrutinizer06> fsofono-janus plugin instead of the current fsogsmd
Jun 06 20:46:02 <nschle85> DocScrutinizer06: but copying them is ok ?
Jun 06 20:46:24 <GNUtoo-desktop> prahal, ifup/down is good
Jun 06 20:46:48 <morphis> thats like combing an apple with a banana
Jun 06 20:46:51 <DocScrutinizer06> nschle85: hm? you mean copying of some sourcecode? sure, it's the most used technique in FOSS
Jun 06 20:47:19 <GNUtoo-desktop> yes for instance in the linux kenrel it's very used
Jun 06 20:47:25 <GNUtoo-desktop> *used a lot
Jun 06 20:47:29 <DocScrutinizer06> morphis: which is rather tasty, so please don't insult banana-apple mix ;-D
Jun 06 20:47:32 <morphis> that would mean copy the whole ofono code a put it into a plugin
Jun 06 20:47:38 <morphis> DocScrutinizer: :D
Jun 06 20:47:42 <nschle85> GNUtoo-desktop: in my logs i can see that iliwi wants  WiFi resource but wlan0 is not up after it
Jun 06 20:47:55 <GNUtoo-desktop> nschle85, I'll try with master
Jun 06 20:47:57 <morphis> nothing that makes any sence
Jun 06 20:48:41 <DocScrutinizer06> nschle85: http://lxr.free-electrons.com/source/net/caif/caif_socket.c#L346
Jun 06 20:49:32 <DocScrutinizer06> doing it any other way has a name: NIH-syndrome
Jun 06 20:49:52 <nschle85> DocScrutinizer06:  i  dont understand you
Jun 06 20:49:53 <GNUtoo-desktop> nschle85, I think you should identify the shortest path to get n900 working and that's probably not ofono, unless you want to rewrite the telephony apps
Jun 06 20:50:08 <GNUtoo-desktop> but maybe there are some gtk+ apps for telephony
Jun 06 20:50:10 <GNUtoo-desktop> so it could work
Jun 06 20:50:46 <nschle85> GNUtoo-desktop: why rewrite ? the plugin translates between ofono and fso
Jun 06 20:50:52 <morphis> I am off guys
Jun 06 20:50:55 <morphis> gn8
Jun 06 20:50:59 <GNUtoo-desktop> good night
Jun 06 20:51:04 <GNUtoo-desktop> nschle85, a plugin already exists?
Jun 06 20:51:06 <DocScrutinizer06> [06.06.2012 22:45:58] <nschle85> DocScrutinizer06: but copying them is ok ? /// 346  * Copied from unix_stream_recvmsg, but removed credit checks,
Jun 06 20:51:29 <nschle85> GNUtoo-desktop: no . sms exists ?
Jun 06 20:51:48 <GNUtoo-desktop> nschle85, I mean fso<->ofono already exists?
Jun 06 20:51:57 <nschle85> GNUtoo-desktop: no
Jun 06 20:52:19 <DocScrutinizer06> I'm off to get some soup or tea (or hop-tea ;-D)
Jun 06 20:52:38 <nschle85> DocScrutinizer06: bye
Jun 06 20:52:43 <slyon> fso is using parts of ofonos sms library
Jun 06 20:52:57 <GNUtoo-desktop> nschle85, ofono is already in oe but it's not adapted to fso phones
Jun 06 20:53:18 <nschle85> slyon: for what ?? sms is not implemented
Jun 06 20:53:18 <DocScrutinizer06> and quite probably never will be
Jun 06 20:53:36 <GNUtoo-desktop> will never be unless someone help me fixing the forwarder
Jun 06 20:53:52 <GNUtoo-desktop> I tried many many times
Jun 06 20:53:55 <GNUtoo-desktop> I always failed
Jun 06 20:54:04 <DocScrutinizer06> GNUtoo-desktop: what got the forwarder to do with ofonoß
Jun 06 20:54:12 <DocScrutinizer06> damndamndamn
Jun 06 20:54:14 <DocScrutinizer06> ??????
Jun 06 20:54:20 <GNUtoo-desktop> n900 forwarder is needed for phone calls
Jun 06 20:54:35 <GNUtoo-desktop> and once we have phone call working I would be very interested at making n900 work
Jun 06 20:54:48 <DocScrutinizer06> still
Jun 06 20:54:49 <GNUtoo-desktop> like adding scenarios  + sms
Jun 06 20:54:57 <DocScrutinizer06> what got all this to do with ofono?
Jun 06 20:55:23 <slyon> nschle85, the at sms library. dunno about n900 specific stuff
Jun 06 20:55:24 <nschle85> DocScrutinizer06: ofono is not alsa... so forwarder may be needed
Jun 06 20:55:58 <GNUtoo-desktop> DocScrutinizer06, nschle85 seem desesperated to get something working on n900 so as usual like people do he think of other(wrongs) ways
Jun 06 20:56:03 <DocScrutinizer06> ooh you thought my "and never will2 was answer to SMS. No I replied to your comment about "adapetd to fso"
Jun 06 20:56:46 <nschle85> DocScrutinizer06:  i also think it will never be implemented
Jun 06 20:57:02 <GNUtoo-desktop> nschle85, what is your order of priorities:
Jun 06 20:57:04 <GNUtoo-desktop> 1)wifi
Jun 06 20:57:06 <GNUtoo-desktop> 2) ?
Jun 06 20:57:59 <IanWizard-Cloud> Anyone know where I could find the old boots splash?  http://goo.gl/UTztP
Jun 06 20:58:31 <nschle85> I am trying to solve some problems, but  i ever did not finish because i dont have the knwoledge  how to do
Jun 06 20:58:49 <GNUtoo-desktop> nschle85, alsa scenarios were quite easy
Jun 06 20:58:58 <GNUtoo-desktop> I gave you a method of trial and error
Jun 06 20:59:05 <GNUtoo-desktop> you chose to go the complicated way
Jun 06 20:59:13 <GNUtoo-desktop> with the datasheets and such
Jun 06 20:59:38 <IanWizard-Cloud> GarthPS: haha, nice nick :P
Jun 06 20:59:45 <nschle85> GNUtoo-desktop: i needed the datasheets to know what iam talking about
Jun 06 20:59:56 <GNUtoo-desktop> ok
Jun 06 21:01:01 <nschle85> GNUtoo-desktop: at the momenmt i wanted to activate wifi... first problem it does not work if my router is configured as wpa+wpa2 
Jun 06 21:01:13 <GNUtoo-desktop> ok
Jun 06 21:01:14 <nschle85> GNUtoo-desktop: this i know now
Jun 06 21:01:15 <GNUtoo-desktop> let me try
Jun 06 21:01:37 <nschle85> GNUtoo-desktop: net i wanted to try is to use iliwi
Jun 06 21:01:43 <GNUtoo-desktop> for me it works
Jun 06 21:01:47 <GNUtoo-desktop> iliwi works
Jun 06 21:01:49 <GNUtoo-desktop> with master
Jun 06 21:01:52 <GNUtoo-desktop> so try that:
Jun 06 21:01:52 <nschle85> GNUtoo-desktop: but wlan0 is not activated
Jun 06 21:01:55 <GNUtoo-desktop> ifconfig wlan0 up
Jun 06 21:02:02 <GNUtoo-desktop> and see if it gives an error
Jun 06 21:02:16 <nschle85> GNUtoo-desktop: i know but using fso should do that
Jun 06 21:02:43 <mrmoku> iliwi does not work for me with wpa2 either
Jun 06 21:02:53 <mrmoku> because it is parsing iwconfig output
Jun 06 21:02:56 <GNUtoo-desktop> I've open wifi
Jun 06 21:03:02 <mrmoku> and that is different on n900 and gta04 too 
Jun 06 21:03:16 <GNUtoo-desktop> but I can try making an AP
Jun 06 21:03:17 <mrmoku> should be quite easy to fix though in iliwi
Jun 06 21:03:48 <nschle85> mrmoku: my problem on n900 is that scanning does not work because  fso does not invoke ifconfig wlan0 up ?
Jun 06 21:04:02 <prahal> GNUtoo-desktop: bug 2019
Jun 06 21:04:03 <GNUtoo-desktop> nschle85, try what I said
Jun 06 21:04:09 <GNUtoo-desktop> prahal, thanks
Jun 06 21:04:25 <DocScrutinizer06> IanWizard-Cloud: well, according to your link to http://www.teaparty.net/technotes/openmoko-2.html it seems the boots picture is a part of  http://downloads.openmoko.org/releases/Om2008.8-update/  -  I'd think you could either extract the boot-boots there from image, or find the source repo for the 2008.08
Jun 06 21:04:33 <nschle85> GNUtoo-desktop: ifconfig ... works and then iliwi can scan
Jun 06 21:04:47 <GNUtoo-desktop> nschle85, ok let me reboot and see
Jun 06 21:05:17 <DocScrutinizer06> anybody knows where 2008.08 source collects dust?
Jun 06 21:05:18 <IanWizard-Cloud> DocScrutinizer06: in hind sight, maybe I should have read the link, instead of just linking the image :(
Jun 06 21:05:24 <nschle85> but starting iliwi should fso force to do a ifconfig wlan0 up
Jun 06 21:05:38 <GNUtoo-desktop> nschle85, yes there are even plugins for that
Jun 06 21:05:41 <GNUtoo-desktop> try that command:
Jun 06 21:06:03 <IanWizard-Cloud> DocScrutinizer06: I used to have a copy of it.  I'll dig around a bit, see if it's still on my backup drive.
Jun 06 21:06:19 <DocScrutinizer06> :-D
Jun 06 21:07:06 <GNUtoo-desktop> ah iliwi makes enlightenment restart....
Jun 06 21:07:36 <nschle85> GNUtoo-desktop: i guess missing lib :-)
Jun 06 21:08:06 <GNUtoo-desktop> nschle85, mdbus2 -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.ListResources
Jun 06 21:08:37 <GNUtoo-desktop> ah now it works again
Jun 06 21:09:15 <DocScrutinizer06> GNUtoo-desktop: fsoraw!
Jun 06 21:10:01 <GNUtoo-desktop> ok
Jun 06 21:10:11 <CIA-76> SHR: 03lukasmaerdian 07meta-smartphone * r3192f99cc148 10/meta-shr/recipes-shr/shr/ (shr-splash-theme-logo_git.bb shr-splash-theme.inc): meta-shr: shr-splash-theme-logo: add gta04 initrd logo.bmp
Jun 06 21:10:20 <GNUtoo-desktop> but fsoraw is less easy to paste
Jun 06 21:11:48 <slyon> mrmoku, afaik iliwi was fixed to be usable on both: new and old iwconfig
Jun 06 21:12:04 <mrmoku> really?
Jun 06 21:12:08 <slyon> GNUtoo-desktop, now we should have a SHR logo in gta04-init
Jun 06 21:12:16 <mrmoku> ok, I did not try for some time...
Jun 06 21:12:31 <slyon> mrmoku, https://github.com/shr-project/Iliwi/commit/be1ebf0978deb3b16f69e65af225b2630128e612
Jun 06 21:12:38 <GNUtoo-desktop> slyon, nice
Jun 06 21:12:48 <mrmoku> cool
Jun 06 21:13:28 <DocScrutinizer06> ([06.06.2012 23:02:49] <mrmoku> because it is parsing iwconfig output) hehehe, it's no 3 days ago I posted sth like "NEVER parse stdout of any cmdline tool. If you actually need to do nevertheless, then don't forget LANG=C"
Jun 06 21:13:55 <nschle85> GNUtoo-desktop: give me please 5 minutes, i install my fresh image
Jun 06 21:14:01 <GNUtoo-desktop> nschle85, ok
Jun 06 21:14:34 <mrmoku> DocScrutinizer06: hehe, LANG=C would not have helped in this specific case :-P
Jun 06 21:14:42 <DocScrutinizer06> btw iirc the reason why maemo initscripts had (and still have) a dependency to messybox
Jun 06 21:15:43 <DocScrutinizer06> I.E. replacing messybox by proper bash+unixtools will cause a bootloop
Jun 06 21:17:40 <DocScrutinizer06> ~ping DocScrutinizer
Jun 06 21:17:41 <apt> pong DocScrutinizer
Jun 06 21:17:51 <DocScrutinizer06> ~ping DocScrutinizer06
Jun 06 21:17:52 <apt> pong DocScrutinizer06
Jun 06 21:18:00 <DocScrutinizer06> o.O
Jun 06 21:18:55 <GNUtoo-desktop> nschle85, after rebooting it works perfectly for me with master
Jun 06 21:19:03 <GNUtoo-desktop> maybe my fixes from today or yesterday
Jun 06 21:19:38 <DocScrutinizer06> ~ping DocScrutinizer06
Jun 06 21:19:39 <apt> pong DocScrutinizer06
Jun 06 21:19:43 <DocScrutinizer06> HAH
Jun 06 21:19:56 <DocScrutinizer06> Konversation is kinda weird
Jun 06 21:20:12 <DocScrutinizer06> sorry for the noise
Jun 06 21:20:29 <nschle85> DocScrutinizer06:  whats up ?
Jun 06 21:20:45 <DocScrutinizer06> just had issues with highlight on my nick
Jun 06 21:21:00 <GNUtoo-desktop> nschle85, I run DISPLAY=:0 iliwi and wlan0 appear in ifconfig then I close it and wlan0 disapear
Jun 06 21:21:03 <GNUtoo-desktop> beside I can scan
Jun 06 21:21:05 <DocScrutinizer06> it did highlight but not play the configured sound
Jun 06 21:21:52 <nschle85> GNUtoo-desktop: this i also expect  but let me check it 
Jun 06 21:21:55 <DocScrutinizer06> turns out "highlight own nick" overrides "highlight regex *docscr*" and only the latter will play sound
Jun 06 21:22:21 <nschle85> DocScrutinizer06: ok you are talkig to yourself :-)
Jun 06 21:22:28 <DocScrutinizer06> indeed
Jun 06 21:22:51 <DocScrutinizer06> as I didn't want to bother somebody else to highlight me
Jun 06 21:22:58 <nschle85> DocScrutinizer06: so you should say everything you want :-)
Jun 06 21:24:02 <DocScrutinizer06> nschle85: anyway thanks for testing my highlighting and plop-sound - works great now that I have unchecked the "highlight own nick" option :-)
Jun 06 21:25:10 <nschle85> DocScrutinizer06: hmm  i dont know what its for
Jun 06 21:25:21 <DocScrutinizer06> hmmm?
Jun 06 21:26:22 <nschle85> DocScrutinizer06:  iam using  broken kvirk with default settings :-)
Jun 06 21:26:25 * DocScrutinizer06 waves and heads out to finally get some decent meal
Jun 06 21:26:34 <GNUtoo-desktop> nschle85, also try more than once because sometimes it doesn't scan 
Jun 06 21:28:28 <nschle85> GNUtoo-desktop: ok installation wizard was running and no pin ddialog appeared
Jun 06 21:28:38 <nschle85> now rebooting
Jun 06 21:30:24 <GNUtoo-desktop> [  944.973785] wlan0: deauthenticating from 74:de:2b:18:fd:93 by local choice (reason=1)
Jun 06 21:30:32 <GNUtoo-desktop> that's with WPA
Jun 06 21:31:15 <nschle85> GNUtoo-desktop: my router was configured  wpa+wpa2
Jun 06 21:31:49 <GNUtoo-desktop> ok so the kernel doesn't know why it disassociate
Jun 06 21:33:47 <nschle85> GNUtoo-desktop: pin did not appear 
Jun 06 21:33:55 <GNUtoo-desktop> hmmm
Jun 06 21:34:03 <GNUtoo-desktop> can we see one problem at the same time
Jun 06 21:34:10 <GNUtoo-desktop> for me it connect to the network
Jun 06 21:34:13 <slyon> GNUtoo-desktop, what do i need to test the alsa_forwarder. is just using fso-autorev enough?
Jun 06 21:34:43 <GNUtoo-desktop> slyon, yes it's enough
Jun 06 21:34:59 <GNUtoo-desktop> note that it might segfaut from time to time
Jun 06 21:35:04 <GNUtoo-desktop> we need to resolve theses
Jun 06 21:35:34 <slyon> ok
Jun 06 21:36:33 <nschle85> GNUtoo-desktop: ups i tried to connect via usb:    no route to host
Jun 06 21:38:17 <GNUtoo-desktop> I've to ifdown usb0 ;ifup usb0 to make it work
Jun 06 21:38:21 <GNUtoo-desktop> but that'll be fixed
Jun 06 21:38:36 <nschle85> GNUtoo-desktop: did not help
Jun 06 21:38:37 <GNUtoo-desktop> someone put a solution in a bugreport today
Jun 06 21:38:43 <GNUtoo-desktop> on target of course
Jun 06 21:39:30 <nschle85> pressing power button on N900 does also not bring up the reboot disalog
Jun 06 21:40:28 <GNUtoo-desktop> WPA: Failed to set PTK to the driver (alg=2 keylen=32 bssid=74:de:2b:18:fd:93)
Jun 06 21:40:44 <GNUtoo-desktop> maybe some missing modules
Jun 06 21:41:44 <nschle85> GNUtoo-desktop: you are investigating on driver level, i see problems in application level
Jun 06 21:42:32 <GNUtoo-desktop> nschle85, maybe it lacks the wpa module
Jun 06 21:43:14 <nschle85> reconfiguring my router to  wpa2 only it worked
Jun 06 21:44:03 <nschle85> GNUtoo-desktop: but in parallel there are problems for users using iliwi
Jun 06 21:44:04 <GNUtoo-desktop> ok
Jun 06 21:44:37 <nschle85> GNUtoo-desktop: now i have kernel dumps and reboot within 20 seconds
Jun 06 21:45:35 <GNUtoo-desktop> ok
Jun 06 21:45:41 <GNUtoo-desktop> look here:
Jun 06 21:46:07 <GNUtoo-desktop> stuff like LIB80211_CRYPT_TKIP is not enabled
Jun 06 21:46:08 <GNUtoo-desktop> strange
Jun 06 21:46:43 <GNUtoo-desktop> Selected by: HOSTAP [=n] && NETDEVICES [=y] && WLAN [=y] || LIBIPW [=n] && NETDEVICES [=y] && WLAN [=y] && PCI [=y] && CFG80211 [=m]
Jun 06 21:47:30 <GNUtoo-desktop> ah ok
Jun 06 21:47:33 <GNUtoo-desktop> it's old stuff
Jun 06 21:47:37 <GNUtoo-desktop> I was mistaken then
Jun 06 21:47:38 <GNUtoo-desktop> sorry
Jun 06 21:48:05 <GNUtoo-desktop> it's the pre-mac80211 stuff
Jun 06 21:49:24 <nschle85> GNUtoo-desktop: what should i do ? reinstall or reboot ?
Jun 06 21:50:35 <GNUtoo-desktop> what are the kernel problem?
Jun 06 21:50:41 <GNUtoo-desktop> what do you want me to solve first?
Jun 06 21:51:15 <nschle85> GNUtoo-desktop: i hoped you are not involved to do anything
Jun 06 21:51:37 <GNUtoo-desktop> it won't advance if I don't do something
Jun 06 21:51:42 <GNUtoo-desktop> I mean the status
Jun 06 21:52:06 <nschle85> GNUtoo-desktop: i ll reboot and investigate the display
Jun 06 21:52:10 <GNUtoo-desktop> ok
Jun 06 21:52:35 <GNUtoo-desktop> maybe since the wireless work for me and that I don't have your setup....maybe I should rather try the audio rather
Jun 06 21:52:39 <GNUtoo-desktop> the sceanrios
Jun 06 21:53:18 <nschle85> GNUtoo-desktop: the phone booted now, may be a race condittion
Jun 06 21:53:27 <GNUtoo-desktop> ok
Jun 06 21:54:49 <nschle85> GNUtoo-desktop: now i am connected via usb
Jun 06 21:54:59 <GNUtoo-desktop> ok
Jun 06 21:56:34 <nschle85> GNUtoo-desktop: http://pastebin.com/vaBaq8rd 
Jun 06 21:56:49 <nschle85> now ill start iliwi
Jun 06 21:57:14 <GNUtoo-desktop> wlan0 should be down
Jun 06 21:57:16 <GNUtoo-desktop> at boot
Jun 06 21:57:56 <nschle85> GNUtoo-desktop: it is as you can see
Jun 06 21:58:08 <GNUtoo-desktop> ok
Jun 06 21:58:36 <GNUtoo-desktop> I tought it was ifconfig
Jun 06 21:58:40 <GNUtoo-desktop> and not ifconfig -a
Jun 06 21:59:08 <nschle85> now ifconfig -a hangs in the call
Jun 06 22:01:40 <nschle85> GNUtoo-desktop: ill reboot the phone
Jun 06 22:07:16 <nschle85> GNUtoo-desktop: i should test  my image now and get in contact  with you if i think something is wrong
Jun 06 22:07:40 <GNUtoo-desktop> yes
Jun 06 22:07:45 <GNUtoo-desktop> but I'm solving the audio
Jun 06 22:07:48 <GNUtoo-desktop> stuff got changed
Jun 06 22:07:57 <GNUtoo-desktop> like control 64 is not Speaker function
Jun 06 22:08:30 <nschle85> we should talk about it tomororrow
Jun 06 22:08:49 <nschle85> now i ahave to test and go to bed
Jun 06 22:08:53 <GNUtoo-desktop> ok
Jun 06 22:08:59 <GNUtoo-desktop> I'll try to fix and go to bed
Jun 06 22:09:35 <nschle85> GNUtoo-desktop: if you are to tired you should to go to bed now :-)
Jun 06 22:10:13 <GNUtoo-desktop> see you later
Jun 06 22:10:32 <slyon> I'll leave as well. see you guys!
Jun 06 22:19:21 <nschle85> bye
Jun 06 22:21:41 <mrmoku> looks like bed time :-)
**** ENDING LOGGING AT Thu Jun 07 02:59:58 2012