**** BEGIN LOGGING AT Sun Sep 06 02:59:57 2009 Sep 06 08:17:25 good morning Sep 06 08:44:59 morning Sep 06 09:09:02 Ainulindale: when will SHR finally switch either to GNU utilities or to more sane busybox config?! :( Sep 06 09:10:55 Ainulindale: i'm using SHR on gta01 and limitations of busybox's sh (mainly i lack M-b and M-. keybindings) are quite annoying. Sep 06 09:17:30 PaulFertser: why not install bash? Sep 06 09:17:54 but yes, M-. is really missing, as well as sane history functionality Sep 06 09:19:30 blindcoder: i can install bash, no problem with that (except that some other parts stop working, e.g. xserver-nodm if /bin/sh is symlinked to bash)... Sep 06 09:20:14 blindcoder: but such a limited shell on a device like ours is just stupid, especially if one plans to use vala-term and has troubles typing many letters with on-screen-keyboard. Sep 06 09:21:13 hi, installed shr yesterday on my gta2. Everything seems to be fine, ecxept 2 things - Locking isn't working and i have sometimes trouble to activate my gsm connection - are this common problems? Sep 06 09:23:25 kratos: what program do you use for locking? Sep 06 09:23:42 PaulFertser: I don't have sh symlinked, but I have /bin/bash in /etc/passwd Sep 06 09:25:50 i tried to activate locking over the url (push power button -> select Lock) , didn't start a prg over the conole. are there more than one locking prg? Sep 06 09:27:54 try elock Sep 06 09:27:57 kratos: url? Sep 06 09:28:06 simply run it in the background Sep 06 09:28:07 sorry gui nor url Sep 06 09:28:12 pressing the AUX button then locks the screen Sep 06 09:28:28 or waiting for the "lock" timeout specified with the settings app Sep 06 09:28:30 kratos: "the gui" does not help me much since i do did not install shr two days ago :( Sep 06 09:29:50 @farhaven: thanks, that AUX button worked. Sep 06 09:31:58 the builtin lock is far less functional than elock though :) Sep 06 09:33:51 can you tell me where i can find the log for openphonekitd? Sep 06 09:34:18 /var/log/ophonekitd.log Sep 06 09:34:33 thanks Sep 06 09:45:31 khiraly1: btw, that dbus warning is present only in OE, it was added there on purpose to force somebody to make bindings more safe. Sep 06 09:45:44 dont care Sep 06 09:46:01 just remove this warning. IT is really pain in the ass to do any sane developping on the device Sep 06 09:46:43 khiraly1: not really Sep 06 09:46:54 lindi-: ? Sep 06 09:46:58 uh? Sep 06 09:47:00 khiraly1: git and emacs work. small programs compile reasonably fast Sep 06 09:47:04 where does it hinder developing? Sep 06 09:47:35 ok, when your app use dbus (fso), and you output useful info to the console Sep 06 09:47:47 it is just polluted with this f*cking warning Sep 06 09:47:59 hrm, I need to alias opkg=apt-get on my desktop machine :) Sep 06 09:48:07 blindcoder: same here :) Sep 06 09:48:18 khiraly1: what warning? Sep 06 09:48:26 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:48:26 btw, where can I find git send-email? Sep 06 09:48:27 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:48:29 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:48:31 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:48:39 khiraly1: heh :) Sep 06 09:48:43 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:48:50 this one^ Sep 06 09:48:52 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:49:00 and it clutters the conversation too Sep 06 09:49:02 Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged Sep 06 09:49:06 well, you can do | grep -v pending_return Sep 06 09:49:08 see http://paste.pocoo.org/show/138295/ Sep 06 09:49:14 khiraly1: is that mdbus issue? Sep 06 09:49:15 that should solve your problem :) Sep 06 09:49:25 lindi-: no Sep 06 09:49:25 farhaven: that's a workaround, not a fix Sep 06 09:49:46 lindi-: it's the worning added to dbus in OE to force users to switch to more thread-safe api. Sep 06 09:50:26 lindi-: upstream dbus folks are seemingly not concerned with the issue. And also nobody updated any dbus bindings even in OE, so this warning is there for every dbus-using app. Sep 06 09:50:32 any application is suffering from this: cli-framework, paroli, etc, etc Sep 06 09:50:32 PaulFertser: could it just be not output if /etc/dbus/i_am_just_a_user_not_a_developer exists :P Sep 06 09:50:36 PaulFertser: hrm Sep 06 09:51:22 this error message takes the half of a 200 line of output Sep 06 09:51:36 PaulFertser: i wish I had time to dump dbus Sep 06 09:53:18 Man, dropbear init.d script is stupid! It shouldn't kill existing connections on "restart" obviously. But it does just start-stop-daemon instead of more sensible approach :( Sep 06 09:54:08 PaulFertser: there is some more thread-safe api? Sep 06 09:54:24 lindi-: kinda Sep 06 09:54:36 lindi-: i forget the details every time i don't think about them. Sep 06 09:55:04 PaulFertser: is it enough for the dbus clients to use it or do services need to be rewritten too? Sep 06 09:55:18 (including hal and Xorg) Sep 06 09:55:43 lindi-: probably it's not thread-safe even but using that "strongly discouraged pending_return" was proved to cause problems in RL for FSO. Sep 06 09:55:45 maybe it would be nice.. to make this message a bit shorter... not >2 lines on moko screen :) Sep 06 09:57:19 btw, is there someone with a 16GB sd card? Sep 06 09:57:47 8GB here Sep 06 09:57:54 I have 4GB too Sep 06 09:57:58 but looks really tiny Sep 06 09:58:13 and 8GB would not make much more difference;) Sep 06 09:58:19 still my musics dont fit there Sep 06 09:59:04 /dev/root 1968544 1161644 706900 62% / Sep 06 09:59:10 I only use 2 GB :P Sep 06 10:10:53 khiraly1: I got 3 16GB uSDHC cards Sep 06 10:11:00 from Sandisk Sep 06 10:11:03 all works Sep 06 10:11:09 super Sep 06 10:11:20 how much it costs? Sep 06 10:11:53 they are expensive... about twice as much as 8GB Sep 06 10:12:54 but I will not confuse you with norwegian prices:D Sep 06 10:13:58 give me approx in EUR Sep 06 10:14:38 50€ here Sep 06 10:15:13 hmm, it really scales linearly Sep 06 10:15:49 btw nokia uSD really is competitive Sep 06 10:16:02 * rhkfin remembres buying his first USB flash: 512MB, about 120eur (in 2004) Sep 06 10:17:32 is there any theoretical limit of uSD capacity what can be put in the freerunner? Sep 06 10:17:46 2TB Sep 06 10:18:16 no way Sep 06 10:18:27 it must be some limitation of glamo, whatever Sep 06 10:18:51 I do not think so Sep 06 10:19:16 32GB aiui Sep 06 10:19:19 anyway, uSDHC cards will not be bigger than 32 GB Sep 06 10:19:41 "Capacity limit in all SD/MMC formats appears to be 128 GB in LBA mode (28-bit sector address)." Sep 06 10:19:49 (wikipedia / microSD) Sep 06 10:20:01 definietly not 2TB Sep 06 10:20:43 ok 16GB is working, with a bit of chance 32GB will work too. And the limit is about there. Do not expect 64GB to work ... Sep 06 10:21:10 there will never be 64GB uSDHC cards Sep 06 10:21:25 because there is a new standard Sep 06 10:21:41 which will replace SDHC Sep 06 10:21:46 xHC? Sep 06 10:21:52 something like that Sep 06 10:22:04 if there is a demand for it, and technically possible, why not? Sep 06 10:22:50 anyway, in a year, I will have a cheap 32GB one;) Sep 06 10:22:58 until maybe I get a 16GB Sep 06 10:27:25 next will be SDXC Sep 06 10:27:36 or sth like that Sep 06 10:28:07 With proprietary patent-tainted exfat "filesystem" Sep 06 10:28:45 and more transmission lines to limit the radiation Sep 06 10:32:52 http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.Device.html;hb=HEAD#SetSpeakerVolume Sep 06 10:33:20 could somebody explain what is the goal of GSM.Device.SetSpeakerVolume? Sep 06 10:33:27 when we could manipulate the Scenario file? Sep 06 10:33:39 it says this: This maps to the GSM 07.07 command +CFUN=?, see 3GPP TS 07.07 Chapter 8.2. Sep 06 10:34:21 khiraly1: speaker volume is CLVL Sep 06 10:34:25 khiraly1: not CFUN Sep 06 10:34:47 and what is CLVL? Sep 06 10:35:08 anywhay why I should set the speakerVolume thourgh this fucntion and not by manipulating the scenario file? Sep 06 10:35:34 khiraly1: check the specs please. '8.23 Loudspeaker volume level +CLVL $(AT R97)$' Sep 06 10:35:35 khiraly1: there's no infrastracture to manipulate scenario files in a sane way, that's why Mirko decided to use that kludge. Sep 06 10:35:55 khiraly1: well this setting affects calypso output level Sep 06 10:36:06 aham, so better to not touch it Sep 06 10:36:07 no? Sep 06 10:37:56 I would like to see a scenario saving functionality through fso Sep 06 10:38:04 Im reading elmixer.py Sep 06 10:38:42 khiraly1: scenario is brain-dead concept, defective by design. Sep 06 10:38:51 elaborate please Sep 06 10:39:59 elmixer.py: http://paste.pocoo.org/show/138309/ Sep 06 10:40:34 line 315 and line 326 Sep 06 10:40:44 the scenario saving is a bit of hackish Sep 06 10:41:08 PaulFertser: I would like to implement something better in paroli Sep 06 10:41:13 khiraly1: configuration files do not belong to /usr Sep 06 10:41:20 khiraly1: /usr should be read-only mountable Sep 06 10:41:42 lindi-: om2009 and shr before august: /usr/share/openmoko/scenarios Sep 06 10:41:52 shr after august: /usr/share/shr/scenarii Sep 06 10:42:07 somebody thought is a good joke messing with the paths Sep 06 10:42:20 khiraly1: both are bad Sep 06 10:42:30 khiraly1: I keep them in /etc/alsa-scenarios/ Sep 06 10:42:31 currently on shr all the two directories are exist Sep 06 10:42:47 khiraly1: onlky after installing paroli? Sep 06 10:43:03 rhkfin: honestly dont know Sep 06 10:43:07 or what cretes the /openmoko/scenarios? Sep 06 10:43:08 ok Sep 06 10:43:12 scenarios aren't configuration files Sep 06 10:43:22 rue Sep 06 10:43:24 true Sep 06 10:43:32 template for alsamixer Sep 06 10:43:33 dos1: they should be? users need to adjust volume settings Sep 06 10:43:35 or alsa Sep 06 10:43:37 dos1: whattahell? They are, I can set the volume through it Sep 06 10:43:49 lindi-: they shouldn't be, as we shouldn't use scenarios at all Sep 06 10:44:06 dos1: but we use scenarios now and they are definitely configuration files in that use Sep 06 10:44:17 we should use something like resources in (fs)ousaged Sep 06 10:44:23 dos1: not true. shr telephony apps *do* use scenarios especially when they switch between earspeaker and main speaker Sep 06 10:44:46 khiraly1: but they shouldn't and they'll stop doing that soon (i hope) Sep 06 10:45:12 PaulFertser and DocScrutinizer know more, ask they for details Sep 06 10:45:43 Device.Audio.* the whole class purpose to manipulate scenario files Sep 06 10:45:46 http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Audio.html;hb=HEAD Sep 06 10:45:49 khiraly1: ... Sep 06 10:45:51 khiraly1: so? Sep 06 10:45:57 khiraly1: it's bad and it's going to be replaced Sep 06 10:46:11 and why other ways are better? Sep 06 10:46:14 khiraly1: so why for wasting time to adjust something we'll abbandon soon? Sep 06 10:46:24 khiraly1: http://people.openmoko.org/joerg/ALSA/ACI/ Sep 06 10:46:33 dos1: I want something which works *now* Sep 06 10:46:48 khiraly1: bad approach Sep 06 10:46:54 khiraly1: well, maybe good in long-term Sep 06 10:47:02 s/long/short/ Sep 06 10:47:03 dos1 meant: khiraly1: well, maybe good in short-term Sep 06 10:47:09 currently paroli wants, that frameworkd sets the scenario for him (rules.yaml), however on shr it is disabled, as shr telephony apps sets scenarios for themselves Sep 06 10:47:09 khiraly1: but really bad in long-term :P Sep 06 10:47:32 khiraly1: setting scenarios by phone apps was first step to abbandon scenarios at all Sep 06 10:47:40 so we keeps overwriting rules.yaml, and that way shr telephony app and paroli excludes each others Sep 06 10:48:05 khiraly1: as now we can just replace calls to switch scenario with calls to request audio resource Sep 06 10:48:29 khiraly1: and switching scenarios by oeventsd is even worse :P Sep 06 10:48:37 khiraly1: it's buggy as hell and just doesn't work Sep 06 10:48:45 dos1: great Sep 06 10:48:46 khiraly1: so paroli shouldn't rely on it Sep 06 10:49:06 ok, what shr telephony apps use? I do think they are using oeventsd too Sep 06 10:49:13 khiraly1: also you might want to read my unfinished ideas at https://paulfertser.is-a-geek.org/sarbiterd.rfc Sep 06 10:49:28 khiraly1: ATM they are switching scenarios by odeviced Sep 06 10:49:47 ehh guys, I wont have a working phone by this evening, if you are pushing new ideas on me;-) Sep 06 10:49:56 khiraly1: but as i said, that was only first step to remove scenario handling at all and use better approaches Sep 06 10:50:45 ok, I'll start a wiki page about all this daemons name because these are a mess Sep 06 10:52:09 * rhkfin thinks adding stuff to the wiki is not very efficient as it's lost 'somewhere there' - the wiki would need a huge cleanup.. Sep 06 10:56:05 freesmartphone.org: seba.dos1 dos/opimd-tracking * r6e08102520f2 framework/framework/subsystems/opimd/pimd_messages.py: opimd: Message: fix deleting messages without MessageRead and Direction fields (most often messages from SIM backend) Sep 06 10:57:08 rhkfin: it is just a personal note. Im really lost all this messes. Sep 06 10:57:24 khiraly1: right... Sep 06 10:58:45 freesmartphone.org: seba.dos1 dos/opimd-tracking * r1a7ce1710876 framework/framework/subsystems/opimd/docs/TODO: opimd: update TODO Sep 06 10:58:46 freesmartphone.org: seba.dos1 dos/opimd-tracking * r64cce4a79877 framework/framework/subsystems/ (5 files in 4 dirs): Merge branch 'dos/opimd-tracking' of git@git.freesmartphone.org:framework into dos/opimd-tracking Sep 06 11:09:41 btw, is ther ea wiki page where all the wiki features are showed? Sep 06 11:10:01 like tables, images, enumeration (including codeblock at some points) Sep 06 11:10:04 etc, etc Sep 06 11:10:16 Im such a wiki noob Sep 06 11:11:25 khiraly1: on the bottom of the edit view there's a link to edit manual or similar Sep 06 11:12:08 Editing help? Sep 06 11:12:35 super Sep 06 11:12:42 thats what I was looking for Sep 06 11:15:40 yepo Sep 06 11:18:31 SHR: seba.dos1 opimd-utils * r559b81a15f5a /opimd-contacts: opimd-contacts: few changes in UI for future Sep 06 11:18:39 SHR: seba.dos1 shr-installer * rac7d19e47a60 / (TODO shr-installer): Few changes in UI for future Sep 06 11:21:56 SHR: alexxy opimd-utils * rcd4f6ae82be7 / (5 files in 2 dirs): Add russian translation Sep 06 11:24:05 DocScrutinizer: lite image is built Sep 06 11:24:19 DocScrutinizer: but fat image hanged on rm -rf o_O Sep 06 11:24:20 dos1: INCREDIBLE!!!! Sep 06 11:25:30 -> ~safe to upgrade? Sep 06 11:26:34 rhkfin: safe to upgrade is for about week :P Sep 06 11:26:38 or even more Sep 06 11:26:46 but new image isn't synced yet Sep 06 11:28:52 dos1: ok :) (I've upgraded ~daily :) Sep 06 11:30:36 dos1: how could be solved in a sane way to select which daemon to run at startup? (ophonekitd (shr telephony app) versus paroli) Sep 06 11:31:07 I would like something enduser friendly, preferrably in shr-settings. What do you think? Sep 06 11:31:50 i would like paroli being libframeworkd-phonegui backend... it would make everything easier :x Sep 06 11:31:52 khiraly1: startup = the first run? Sep 06 11:32:03 rhkfin: when you boot your phone Sep 06 11:32:07 khiraly1: ok Sep 06 11:32:48 dos1: libframeworkd-phonegui == ophonekitd binary? Sep 06 11:32:55 ? Sep 06 11:32:56 no Sep 06 11:33:11 then a link please to libframeworkd-phonegui Sep 06 11:33:16 ophonekitd uses libframeworkd-phonegui to display UI Sep 06 11:33:32 I would like SHR to stay at SHR phone aps by default, and make paroli an installable option like it is right now Sep 06 11:33:48 well, paroli is too different by design, i don't think it could be possible :P Sep 06 11:33:59 paroli has its own daemon, and many developers do like it (including me) Sep 06 11:34:14 DocScrutinizer: I would like to be switchable the two solution. No harms on either side Sep 06 11:34:17 dos1: I don't think it's even desirable Sep 06 11:35:17 DocScrutinizer: to the rescue I can always use bruteforce, what firefox do (firefox detected he is not the default browser, would you like to make it the default?) Sep 06 11:35:48 ok for paroli with comprehensive postinstall to fully switch. NAK!! for a selector on standard install of SHR Sep 06 11:36:32 DocScrutinizer: what you was experiencing (overwritten rules.yaml and frameworkd.conf) I try to get rid of it Sep 06 11:36:39 so paroli should not touch shr's configs Sep 06 11:36:43 khiraly1: ... Sep 06 11:36:46 khiraly1: it's already fixed Sep 06 11:36:52 khiraly1: and i already told you that Sep 06 11:36:58 khiraly1: (nytowl fixed that) Sep 06 11:37:12 dos1: not really. rules.yaml conflicts between shr apps and paroli Sep 06 11:37:27 paroli package doesn't override anything now Sep 06 11:37:43 dos1: yepp, but does not work out of the box either Sep 06 11:38:08 but that's paroli issue relying on braindead scenarios in oeventsd concept ;P Sep 06 11:38:15 and nothing more Sep 06 11:38:15 khiraly1: if you want paroli ootb, then use OM2009 :-P Sep 06 11:38:43 khiraly1: implement swithing scenarios by paroli. that's only one dbus call Sep 06 11:38:58 and you'll fix problems with waiting calls for free too :P Sep 06 11:39:06 dos1: Im doing it right now, just was slowed down with future concepts Sep 06 11:39:24 khiraly1: ok then :) Sep 06 11:39:58 wtf! selector for paroli on first boot Sep 06 11:40:09 nope!! Sep 06 11:40:29 DocScrutinizer: no :P Sep 06 11:41:17 maybe another selector for debian Sep 06 11:41:31 DocScrutinizer: (in meaning - noone is proposing such selector) Sep 06 11:41:48 (and i'm against something like that too :P) Sep 06 11:42:17 i would like to have first boot wizard Sep 06 11:43:01 and only then selecting paroli, litephone or anything else (and installing it by shr-installer) could be in "Advanced settings" ;) Sep 06 11:43:43 [13:30] dos1: how could be solved in a sane way to select which daemon to run at startup? (ophonekitd (shr telephony app) versus paroli) [13:31] khiraly1: startup = the first run? Sep 06 11:44:36 DocScrutinizer: he mean "select, which daemon user wants to start while booting", not "select while booting, which daemon user wants to start" :P Sep 06 11:44:58 (i think) Sep 06 11:45:14 yeah, something permanent, not needing to select on every boot. That would be insane Sep 06 11:45:40 so like goind in shr settings-> advanced-> default telephony suit-> [shr][paroli][litephone] Sep 06 11:45:50 and needs a reboot for activating it. Sep 06 11:46:09 I think you both suggesting to have a "kde or gnome?" err paroli selector on install time. I don't think I want to be nagged with such requester Sep 06 11:47:05 DocScrutinizer: first boot wizard is needed for things like libphone-utils configuration Sep 06 11:47:22 DocScrutinizer: when clicking on "Advanced settings" you could also change default phone suite Sep 06 11:47:25 there is already a first boot wizard asking for language, etc Sep 06 11:47:36 khiraly1: which we want to remove :P Sep 06 11:47:41 I'm fine with wizard. I'n not fine with paroli being an option there Sep 06 11:48:15 DocScrutinizer: i'm not fine with handcoding paroli in wizard Sep 06 11:48:35 DocScrutinizer: i'm fine with displaying phone packages from repo using shr-installer Sep 06 11:49:25 you got shr-installer, and you got ipkg postinstall scripts. I guess that's more than needed Sep 06 11:49:37 dos1: ack Sep 06 11:51:06 if paroli wants to play SHR, it has to learn how to do that. not the other way round Sep 06 11:53:04 in the end SHR has recently become reference platform for FSO. So it won't adapt to paroli. never ever Sep 06 11:53:43 rather paroli has to adhere to SHR/FSO standards Sep 06 11:53:58 DocScrutinizer: yup Sep 06 11:54:49 DocScrutinizer: i want generic way to selecting FSO based phone suites, without adapting to specific ones Sep 06 11:55:56 mickey mentioned we eventually want a means in FSO to handle concurrent clients Sep 06 11:56:58 dos1, please build latest git of shr-today, as new frameworkd is now in the feed (it has the changed RTC api) Sep 06 11:57:14 14:51 < DocScrutinizer> if paroli wants to play SHR, it has to learn how to do that. not the other way round <- I'd guess this is one of the issues that's.. well.. making the SHR & paroli live together hard.. We'll see.. Sep 06 11:57:20 Slyon: it's built Sep 06 11:57:21 for now I am completely happy with any clients being mutually exclusive Sep 06 11:57:43 DocScrutinizer: well, they are not exclusive Sep 06 11:57:45 dos1: the revision before the rtc catchup was build Sep 06 11:58:04 you can have paroli, ophonekitd and opimd-utils running at once :P Sep 06 11:58:29 just 5 windows with incoming message and 2 notifications about call will be annoying ;) Sep 06 11:59:11 dos1|away: that's exactly my point. they *should* be mutually exclusive Sep 06 11:59:24 like alternatives Sep 06 12:00:32 but *please* don't implement another config option in shr-settings to enable/disable each and every client Sep 06 12:01:22 just nobody except a few weird devels will ever need that Sep 06 12:02:01 and those devels can use -force-depends or whatever to override the mutex in opkg install Sep 06 12:06:05 so paroli, ophonekitd and opimd-utils ipks should have a mutex dependency on each other, and that's it Sep 06 12:06:40 DocScrutinizer: ont agree Sep 06 12:06:41 dont Sep 06 12:07:37 dont agree, that you install one program which disables an another. And when you want to use the other program you need to remove the current one. Sep 06 12:07:47 I don't care, until you come up with a usecase that makes a strong point against it Sep 06 12:07:49 just it is not a good way imho. Sep 06 12:08:02 bbl Sep 06 12:09:34 i don't agree with being exclusive at opkg stage Sep 06 12:09:38 and in the end it's up to you if you want to override those dependencies on opkg install Sep 06 12:09:56 with other things i agree ;P Sep 06 12:09:56 I agree with dos1;) Sep 06 12:12:07 dos1: pls build shr-today, git-rev 35c0b779e74cf7be93e763c0f90e291c7d019313 is in feed, but git-rev 33ede719bf0092da434f289fc49a2c66aeeb224b needs to be in the feed. atm it'll crash due to the api change Sep 06 12:12:58 so you suggest either a) we allow installing, but fuck up e.g. initscripts so it's no clean install, b) fuck up user experience by actually starting all clients concurrently (resulting in screens mess dos mentioned), c) actually inplement a selector to change initscripts (I hate that idea, as I told above) Sep 06 12:14:03 i suggest b) from SHR side Sep 06 12:14:52 as that's other clients job to provide easy way to disable/enable Sep 06 12:15:07 or provide a mechanism to enable/disable clients Sep 06 12:15:19 so what's wrong with having a protection of standard noob against that with a mutex dep, which is easily to override with -force-depends or whatever? Sep 06 12:15:34 khiraly1: no, not that one!! Sep 06 12:16:16 preferably through fso Sep 06 12:16:35 khiraly1: USECASE! Sep 06 12:17:59 you want to try out a new phonesuite without the fear of messnig things up. Thats it Sep 06 12:18:07 anyway, it is just a personal opinon Sep 06 12:18:52 DocScrutinizer: i don't want to have protection of standard noob ;p Sep 06 12:18:53 khiraly1: that's as moot as it might get Sep 06 12:21:38 khiraly1: actually you couldn't toss me a better argument why we do NOT need any standard means to en/dis-able concurrent clients Sep 06 12:25:21 khiraly1: it's an argument for mutex dependency in fact, as those clients aren't designed for concurrent use and most probably enabling them concurrently *will* mess things up. And user won't understand that better if you provide a standard means to manage enabling of installed clients Sep 06 12:32:41 I didnt suggested anywhere to be able enable more then one telephony app Sep 06 12:33:41 so you suggest having a means to switch clients different than opkg install is inherently more "safe" wrt to "messing up things" - or what? Sep 06 12:34:22 nope, I suggested to be able switch between clients if you have more then one client installed Sep 06 12:34:28 without opkg remove one of them Sep 06 12:34:37 why??? Sep 06 12:35:13 to try out other client without removing your current one? Sep 06 12:35:20 why??? Sep 06 12:35:43 why trying out new client? dunno Sep 06 12:36:43 ok, if the answer to second half of your reasonng also is "dunno" then we probably don't have to continue arguing Sep 06 12:36:58 i dont plan to argue with you Sep 06 12:37:24 but suggesting that noone wnat to try out other telephony app then the default one, is just does not make sense Sep 06 12:37:45 YOUR words Sep 06 12:37:56 I *never* said that Sep 06 12:39:00 and why to not remove telephony app, when you want to try out an other one, is perfectly valid case. I dont want to loose my settings, my tweekings (ie. background picture), dont want to touch my current one at all. But indeed Im curious what other telephony apps may know more than my current one Sep 06 12:39:08 i think it is a perfectly valid usecase Sep 06 12:39:33 you still have only one reasoning why you don't want to remove a client to test another one, and that's "the fear of messnig things up" Sep 06 12:40:15 and fear of loosing costumization Sep 06 12:40:30 I do want many thing to be costumizable in paroli (like background picture) Sep 06 12:40:31 and this mplies opkg is messing thing up, and a additional means of whatever nature as you suggested doesn't. I don't see that Sep 06 12:41:10 removing packages usually *does NOT* remove settings et al Sep 06 12:41:53 and you also implies, that the other telephony apps works stable;) So keeping the old one, and when it does not work out great (and usually you have not inernetconnection when this happens) you should be able to switch back without installing/removing packages Sep 06 12:41:54 at least it's up to the packet manager to configure it as he thinks is the "least messing way" Sep 06 12:42:22 I honestly disagree Sep 06 12:42:35 you can;) Sep 06 12:42:50 I don't want to carry a test- and debug-system with me when I don't have nternet Sep 06 12:43:11 let's allow user making whatever mess he wants Sep 06 12:43:23 only defaults need to be sane Sep 06 12:43:27 that's my opinion ;P Sep 06 12:43:35 if you want to accomplish that task, then simply download both packages, so you can install any time you like Sep 06 12:43:51 and how you know than a telephony app is stable enough to carry with you for multiple days? Or even if it turns out in the middle of day, you missed a call because of the app? Of yourse you want to switch back when you discover this issue, at least you want your old system back Sep 06 12:44:23 that's why i like linux - it let's me doing what i want Sep 06 12:44:30 anyway, time will tell, which one is the best soliution Sep 06 12:44:34 dos1: my opinion is I don't want to have usually useless functionality (to switch clients) in a small system like FR Sep 06 12:45:31 dos1: especially if that function is easily accomplished by standard means like "opkg install" Sep 06 12:45:54 DocScrutinizer: neither me (about switching clients) Sep 06 12:47:01 i just would like to have (after doing things with more priority) way to *install* different phone suites, window managers etc. Sep 06 12:47:06 under "Advanced settings" button Sep 06 12:47:17 without any selecting, playing with configurations Sep 06 12:47:17 khiraly1 is assuming a missed call can be recovered by "switching back to old system". That's a misconception. If the call is logged in new client, then switching back to old client won't help much to further investigate Sep 06 12:47:46 dos1: I fully agree on hat Sep 06 12:47:48 just installing. what to do next is up to user, who accepts he is advanced user by clicking "advances settings" Sep 06 12:47:49 That Sep 06 12:47:50 DocScrutinizer: but I dont want to miss more calls on that day Sep 06 12:48:40 khiraly1: then do "opkg install -force-override /mystore/opimd-utils" and you're done Sep 06 12:49:52 ok. it will not be more productive. Im out of that discussion;) Sep 06 12:50:21 would be nice to debug while my code hangs on PushScenario call;) Sep 06 12:51:20 scenario, what's that? nah wait, you're talking about that obsolete stuff...? ;-P Sep 06 12:53:23 DocScrutinizer: im talking about the *current* stuff Sep 06 12:53:43 when there will be more clever solution in fso, I will happily integrate it into paroli Sep 06 12:53:49 but currently thats what I get Sep 06 12:56:54 khiraly1: the beauty of the "more clever stuff" will be you simply don't need to implement it. That holds true for real audio-apps though. If paroli (and the other dialers) would learn to behave "like real audio apps" then you wouldn't have to care about it any more Sep 06 12:57:31 khiraly1: but you're rigt currently that's all you got Sep 06 12:57:34 ok. I will do it when its available. Currently I want to use my phone from tomorrow Sep 06 13:01:37 I'm using it today ;-P Sep 06 13:02:14 then write the missing fso daemon for it;) Sep 06 13:02:44 what a missing fso-daemon? o.O Sep 06 13:04:39 http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Audio.html;hb=HEAD#PushScenario Sep 06 13:04:49 ^^into Device.Audio or other interface Sep 06 13:05:36 nah, fsodeviced has to learn audio is just another hw resource Sep 06 13:06:59 but for the very usual case we don't even need that, as it just does arbiting of exclusive resources if we need to deprive an app of a resource if higher priority request is pending Sep 06 13:07:55 without fsodeviced we just don't provide resource allocation priorities Sep 06 13:08:09 this is chinese to me Sep 06 13:08:14 ;) Sep 06 13:08:31 khiraly1: well, that's quite strange Sep 06 13:08:39 all the "scenario" stuff will move into generic alsa devices that work autonomously Sep 06 13:08:48 khiraly1: you are developing FSO client, and you don't know basics of FSO? ;x Sep 06 13:08:55 dos1: yepp Sep 06 13:10:00 I do, what nobody else is doing (it seems). The necessity is a lord;) Sep 06 13:11:19 khiraly1: i did the same for opimd Sep 06 13:11:38 but first few days i spent on learning how it looks and how it does things ;) Sep 06 13:12:16 I modify, I experiment, I modify, I experiment, and so on Sep 06 13:12:34 it's really simple to understand when you hear an example: if an app wants to record from headset mic, it opens not "hw:0.0" but rather "handsetmic" for alsa device. And alsa does the "loading scenario" stuff internally. No framework needed at all Sep 06 13:14:18 s/headset/handset/g Sep 06 13:14:18 DocScrutinizer meant: it's really simple to understand when you hear an example: if an app wants to record from handset mic, it opens not "hw:0.0" but rather "handsetmic" for alsa device. And alsa does the "loading scenario" stuff internally. No framework needed at all Sep 06 13:14:23 So I still request soemthing on dbus, just it will not be fso, but rather an alsa touching daemon Sep 06 13:14:38 huh? Sep 06 13:14:48 from my point of view (enable gsmhandset when making call, and remove them after) does not make any difference Sep 06 13:15:00 or are you suggesting, that the app should touch directly alsa? Sep 06 13:15:26 sure, how do you open a audiodevice otherwise? Sep 06 13:17:37 Is paroli requesting audio interface? honestly I dont know. I thought everything is handled by fso. And just talk to fso what to do Sep 06 13:18:31 we're not talking about "the way it *is* now", are we? Sep 06 13:19:30 and gsmhandset is a special case Sep 06 13:19:38 the current way is rather comfortable, no real effort from applicatoin side. I say to fso enable audio profile for me, and thats it. And now what exactly your suggestion? I did read your scripts on the website, but dont really get it. Sep 06 13:20:04 they are just play alsa commands timed with time command Sep 06 13:20:10 as dialers aren't "real" audioapps. I mentioned already Sep 06 13:20:35