**** BEGIN LOGGING AT Sat Apr 24 02:59:56 2010 Apr 24 04:06:26 raster: hey :) Apr 24 04:06:48 burrp Apr 24 04:07:09 Ha, alive and kicking :) Apr 24 04:08:46 raster: i might have forgotten but do you consider a phone part open enough to be able to easily port FSO to it an important part of a device "open enough"? I mean can a device be cool without ability to use telephony API of your choice and any of the UIs written for it? Apr 24 04:09:43 DocScrutinizer51: Doc! :) Got your n900 back? Apr 24 04:10:03 aaaah Apr 24 04:10:11 welll here is my take Apr 24 04:10:58 if there is a phone api that is documented and easy to use - via some ipc mechanism (not linking) if the daemons on the other end are closed and hw closed - thats just snuck in as "open enough" for developers/community in general Apr 24 04:11:12 for the more hardline/purist open peolpe its not open enough Apr 24 04:11:32 for them open enough is protocol docs for talking to the hw Apr 24 04:11:42 but that doesnt mean the maker has to provide an open solution to do that Apr 24 04:11:46 just as long as its documented Apr 24 04:11:50 it can be replaced Apr 24 04:12:13 imho there is relatively littel value in the middelware layer between apps and telephony hw Apr 24 04:12:19 so it isnt worth trying to be closed Apr 24 04:12:23 it just doesnt help you Apr 24 04:12:32 in the end - it hinders you Apr 24 04:12:41 u dont need to give docs on the protocol Apr 24 04:12:53 simply gpl your daemon/handler and thats it Apr 24 04:13:03 if peolpe want to spend the time documenting it fromy our code - fine Apr 24 04:13:09 if tyhey want to replace it - fine Apr 24 04:13:12 BUt this hits a problem Apr 24 04:13:18 u now have 2 incompatible access api's Apr 24 04:13:24 and have to support both Apr 24 04:13:35 they need to play nice Apr 24 04:13:49 and that may not be possible, depending on the assumptions of each with respect to state etc. Apr 24 04:14:42 raster: why use 2 apis at the same time at all? If user chooses FSO it means he wants interoperability with many phone apps written for it. And he doesn't need the vendor tools anymore. Apr 24 04:15:14 one thing you need to be aware of - there is massive resistance to even making the protcol open and accessible outside vendor apps Apr 24 04:15:34 What is their reasoning? Apr 24 04:15:45 the fear is the users will blame the vendor when they download some app that maliciously goes and sends sms's to those high-price sms numbers or phone sex line calls etc. Apr 24 04:15:47 if it has access Apr 24 04:16:01 yes i know - i knoes. user decided to run app - its their fault Apr 24 04:16:10 but humans are irrational Apr 24 04:16:27 Moreover, anything a user can do, an app can do, xtest extension blabla here it comes. Apr 24 04:16:30 and they will say "well this phone sucks. i just got a bill for $500 because of it! why didnt they protect me!" Apr 24 04:16:48 but mind u - their way of stopping access is to #ifdef out api calls in the .h file Apr 24 04:16:54 symbol still there Apr 24 04:16:55 still usable Apr 24 04:16:57 :) Apr 24 04:17:02 so moot Apr 24 04:17:15 anyway Apr 24 04:17:17 as for 2 api's Apr 24 04:17:25 u have all the default stuff already supplied by the maker Apr 24 04:17:43 from config thru to messaging, calls, incoming call handling OTA updates.. and more Apr 24 04:17:52 u choose to throw all of that out Apr 24 04:18:01 (if you get rid of their protocol) Apr 24 04:18:09 I would choose exactly that, of course. Apr 24 04:18:20 you'd be in a minority of cusotmers Apr 24 04:18:25 like 0.001% Apr 24 04:18:35 and thus something the vendor just doesn't care about :) Apr 24 04:18:40 just remember that Apr 24 04:18:53 as mickey keeps saying - playing anti-vendor is a losing game Apr 24 04:19:02 You're now sound like a vendor who doesn't provide any info or driver for desktop GNU/Linux users. Apr 24 04:19:15 the only chance you hve is to first be compatible Apr 24 04:19:21 and work simultaneously with no hassles Apr 24 04:19:33 then build a strong base of support so much stonger than the vendors Apr 24 04:19:38 and then convince the vendor to change Apr 24 04:20:15 linux users are large enough in things like the server market and workstation market Apr 24 04:20:29 But not desktop. Apr 24 04:20:36 in the world of "i have a phone and am going to completely replace the whole telephony stack and suite" you are a tiny minority Apr 24 04:20:53 even on desktop - desktop linux users represent a few % of the market Apr 24 04:21:10 and desktop inherits a lot of the server market support Apr 24 04:21:11 #openmoko-cdevel: Total of 97 nicks Apr 24 04:21:14 not for gfx, audio etc. Apr 24 04:21:15 Hm, probably you're right Apr 24 04:21:28 anmd guess why those are still poorly supported on linux? :) Apr 24 04:21:54 I thought audio is decently supported. Apr 24 04:21:55 things where server and desktop share (latest cpu's, io, disk, network etc.) things work very well Apr 24 04:21:59 depends Apr 24 04:22:11 it works "to an extent" Apr 24 04:22:14 often mixer is your issue Apr 24 04:22:38 for example - without finding a special "model" for my vaio - i couldnt get speakers and headphones to work Apr 24 04:23:04 even now its buggy - i stick headphones in and it doesnt know to turn off speakers without unmuting first, playing some pcm audio, then pluggin in headphones Apr 24 04:23:15 (plug in while muted and not playing doesnt work) Apr 24 04:23:17 another laptop here Apr 24 04:23:24 compaq/hp - speakers dont work at all Apr 24 04:23:26 How's so? I've read alsa-devel ML for some time, and the problem is mostly complexity of HDA specification (too easy to misimplement some tiny device) and buggy vendor info needed for autodetection of gpio's etc. Apr 24 04:23:26 tried everything Apr 24 04:23:32 onyl headphones Apr 24 04:23:42 and yes Apr 24 04:23:47 but thats not relevant Apr 24 04:23:53 the FACt isw... audio doesnt work properly Apr 24 04:24:06 It was really imporved after 2.6.30 release. Apr 24 04:24:08 why - thats a separate matter Apr 24 04:24:12 thats possible Apr 24 04:24:19 and these are on older kernels Apr 24 04:24:29 Also it's impossible to improve audio without "hda-info" user reports. Apr 24 04:24:45 Takashi knows how to decipher those really fast :) Apr 24 04:24:47 sure Apr 24 04:25:10 but - windows on those laptops comes with everything set up right in the vendor supplied drivers Apr 24 04:25:20 linxu gets nothing until enough people bitch and send in bug reports and info Apr 24 04:25:22 But sometimes you need to manually play with hda-verb to find the needed gpio, indeed. But that's because some particular laptop vendor sucks, not because HDA or alsa suck. Apr 24 04:25:38 audio is not relevant to the server market Apr 24 04:25:39 Yep, but that's uncool. Apr 24 04:25:48 so it isnto solved "in advance" by intel/hp/whoever Apr 24 04:25:54 its sucky Apr 24 04:25:58 but thats reality Apr 24 04:26:15 And if you say that the first thing a tinkerer like me would want to do with the new cool "open enough" device is to port FSO to work over theirs undocumented API is not cool either. Apr 24 04:26:43 nvidia do their closed drivers for 1 reason - they have high end workstations customers who push them to and these guys buy high end expensive hw and the margins there are high Apr 24 04:27:15 not saying you dont want to Apr 24 04:27:21 but5 you need to know the vendor point of view Apr 24 04:27:42 u will forever be fighting a losing battle if you dont work WITH them Apr 24 04:27:50 ask mickey about anti-vendor porting Apr 24 04:28:01 you need to find a wayto get them to help you Apr 24 04:28:05 raster: i know precisely what he'd say Apr 24 04:28:15 once they care - the rest will be easy Apr 24 04:28:47 one thing they fear is their phones being the ones known to be used to "hack cellphone networks" Apr 24 04:28:57 or cause bad PR with customers and stupidly high bills Apr 24 04:28:59 etc. etc. Apr 24 04:29:22 but you need fso to work on their stuff in parallel withotu throwing out existing things Apr 24 04:29:34 that means u need to get toe into the water Apr 24 04:29:40 and that means not totally throw it all out Apr 24 04:29:53 I know for sure iPhone (1st gen) baseband firmware was analised to quite an extent and i guess if folks wanted to disrupt cellphone networks they would already implemented that functionality. Apr 24 04:30:11 u can be logical all you want Apr 24 04:30:17 telling me doesnt change anything Apr 24 04:30:30 you need to get the vendors to REALLY know this Apr 24 04:30:35 u can say that all you want Apr 24 04:30:44 their minds are made up otherwise Apr 24 04:30:56 the3y quite happily believe apple being as closed as possible helps prevent that Apr 24 04:31:10 and even if they dont think that Apr 24 04:31:14 why shoudl they bother with fso/ Apr 24 04:31:21 they already have their own standards pre-dating fso Apr 24 04:31:34 and those standards are shared between other vendors and industry bodies Apr 24 04:31:47 why should they throw out all their work Apr 24 04:31:56 To provide users with diversity, with choice of GUI. Apr 24 04:31:57 (move to fso) Apr 24 04:32:03 useless Apr 24 04:32:11 they have more phone apps that fsop has already Apr 24 04:32:15 and that are of better quality Apr 24 04:32:21 you dont know it Apr 24 04:32:26 also rememebr u fight a political battle Apr 24 04:32:26 Do they really? Where can i download and try those? Apr 24 04:32:33 a gorup WORKED on their phone infra Apr 24 04:32:37 ands then another on each phone app Apr 24 04:32:43 u think they want to see their work ditched? Apr 24 04:32:59 u have to have such a winning argument that all the politics cant beat it Apr 24 04:33:06 they have them internally Apr 24 04:33:13 Also i've never seen a vendor phone app _i_ would like. They either have too much animation (or just slow) or make incorrect assumptions or do not provide enough shortcuts etc etc. Apr 24 04:33:16 and between vendors Apr 24 04:33:19 u dont download them Apr 24 04:33:21 they come with the phone Apr 24 04:33:35 but if u like it or not Apr 24 04:33:47 their view is "well here is the phone access api/protocol - use it and do your own" Apr 24 04:33:59 that is IF they make that open Apr 24 04:34:04 which they dont like the idea of Apr 24 04:34:28 you need them to like and care abotu what you do Apr 24 04:34:46 imho - u need fso to be much mroe than yet another phone control api Apr 24 04:34:54 They should also restrict the internet access for the downloaded apps then, since those can be used "to hack the internet". Apr 24 04:34:55 u need things like social network integration built in Apr 24 04:35:06 all sorts of "already there winners" Apr 24 04:35:16 that are worth throwing out what they have for your new extras Apr 24 04:35:35 get them to want fso and care Apr 24 04:35:41 and they will port fso for you to their hw Apr 24 04:35:49 fso license will ensure that those bits are then open Apr 24 04:36:32 now u need them to actually know you exist Apr 24 04:36:36 as such they dont know Apr 24 04:36:42 (and frankly are not looking) Apr 24 04:36:54 they have the likes of meego breathing at them to join Apr 24 04:37:01 or other industry bodies (limo) Apr 24 04:37:06 or jjust plain screw linux and go android Apr 24 04:37:17 Social networks integration? Hm. There's no decent social network out there... Apr 24 04:37:25 those other voices are a lot louder than fso's Apr 24 04:37:38 facebook, google wave etc. Apr 24 04:37:41 take your pick Apr 24 04:37:43 pick multiple Apr 24 04:38:02 integrate to google talk contacts, gmail contacts, other im systems Apr 24 04:38:11 if skypoe do finally go open on the back-end Apr 24 04:38:14 there too Apr 24 04:38:23 raster: nah, they all suck. Too inflexible, too dumb, and the usage patterns i observe are not worth caring about. Apr 24 04:38:26 u dont have to care if its decent Apr 24 04:38:30 facebook is a big name Apr 24 04:38:32 it matters Apr 24 04:38:35 google is a big name - it matters Apr 24 04:38:51 Those are not networks i would like to use. Because they're doing it all wrong. Apr 24 04:38:57 well then - if u dont want to play a game so the vendors care.. you will forever fight against them Apr 24 04:39:00 and they wont care about you Apr 24 04:39:03 and so you'll be stuck Apr 24 04:39:17 Instead of providing an open API they use a dumb inflexible web-browser UI targetted for stupids. Apr 24 04:39:20 if u are willing to do some shit you dont like in order to get a foot in the door - then you have a chance Apr 24 04:39:42 facebook has an actual app for phones Apr 24 04:39:43 not a wbe ui Apr 24 04:39:45 web ui Apr 24 04:39:49 they have a protocol Apr 24 04:39:55 wave i believe has somethinig too Apr 24 04:39:58 some xml over http Apr 24 04:40:00 or what not Apr 24 04:40:02 maybe soap Apr 24 04:40:03 not sure Apr 24 04:40:07 but it exists Apr 24 04:40:15 but - up to yoou Apr 24 04:40:29 Facebook API is too inflexible. You can't have a seamless integration between Facebook, github, gitpaste and bugzilla, e.g. Apr 24 04:40:33 as such other apps exist that can integrate with all these "social network things" Apr 24 04:40:50 Too much done on the server side. Apr 24 04:41:08 well then - you're stuck. Apr 24 04:41:18 i see nothing to sell a vendor on Apr 24 04:41:51 simply being open is not a sales point Apr 24 04:42:01 I can imagine a social network that would suit everybody's needs (i mean needs of different groups: programmers, musicians, artists, modders etc etc) with an approach of more extensible functionality implemented client-side. None of the social networks allows that currently. Apr 24 04:42:28 as such that'd be your job to implement as part of fso Apr 24 04:42:30 client-side handles that Apr 24 04:42:40 but you cant write on someones facebook wall Apr 24 04:42:46 or send a facebook message Apr 24 04:43:01 or get a feed of their photo updates or what not without talking TO facebook with the api Apr 24 04:43:08 and same wioth everything else Apr 24 04:43:17 some of them will simply not do everything you want Apr 24 04:43:43 but facebook and the likes are driving a lot of consumer use and are an attractive market for vendors tro pander to Apr 24 04:44:25 My brother and my students and many folks around use a russian facebook clone. And their usage patterns are total stupidity and waste of time. I do not like the idea of endorsing that. All i want are means allowing me (or any more capable programmer) to port any telephony framework to the device, i do not want vendor doing that, i just need an open opportunity. Apr 24 04:45:51 PaulFertser: well if you dont ewant to.. fine - but then be assured that if you find no other way to become valuable to a vendor - you will fight the vendors forever, and will lose. they have 1000's of fulltime paid engineers working on products. you dont have even a fraction of that. they will always out-code you. even if they are 1% as efficient due to overhead :) Apr 24 04:46:04 you need something they dont have Apr 24 04:46:06 cant do Apr 24 04:46:08 are3 too slow to do Apr 24 04:46:17 or simply didnt realise they could/should do Apr 24 04:46:24 until someone in marketing demanded it Apr 24 04:46:30 and now they need it in a hurry Apr 24 04:46:39 and going fso is the fastest and simplest way to get there Apr 24 04:47:45 raster: ok, i see your point. I hope mickey|tv'll read that because it might be interesting for him. I personally know that i will lose regardless because life's a game one can't win and so i'm ok with losing. Apr 24 04:47:49 get them to care Apr 24 04:47:59 if they care - they will pay attention Apr 24 04:48:14 recently openstreetmaps is getting some commercial attention? Apr 24 04:48:26 why? because watchwolf wrote the elementary map widget Apr 24 04:48:41 it just beautifully accts as a "google maps in a widget" Apr 24 04:48:47 no license agreements to sign with google Apr 24 04:48:52 nothnig extra Apr 24 04:48:57 low barrier of entry Apr 24 04:49:05 and it got some real "wow" attention Apr 24 04:49:12 and now things are being looked at Apr 24 04:49:22 that is the kind of swtuff that may get things like osm good support Apr 24 04:49:36 Managers are so stupid :( Apr 24 04:49:36 not t mention maybe give osm a commercial funding path in future Apr 24 04:49:42 advertising. and so on Apr 24 04:49:46 no - thisisnt managers Apr 24 04:49:54 i cant give yoou all the details Apr 24 04:49:55 It's like they haven't heard about/used OSM before. Apr 24 04:50:04 only whats already been sent to peolpe not under nda Apr 24 04:50:11 (thus that info is public) Apr 24 04:50:16 no - they havent Apr 24 04:50:27 u have no idea how much shit passes by them every day Apr 24 04:50:34 they have very little view of thse kind of things Apr 24 04:50:43 they get 20 others every day float by they should chekc out Apr 24 04:50:50 they have no time to look at evverything Apr 24 04:50:58 i'm suggesting you open such a door for fso Apr 24 04:52:07 one thing i think would be valuable to fso is integrating things other than telephony Apr 24 04:52:14 as everyone has full telephony stuff already Apr 24 04:52:31 fso is "yet another implementation that we dont even know works properly - and has no port to our hw anyway" Apr 24 04:52:35 so - sweeten the deal Apr 24 04:52:42 make fso somkething hyper-attractive Apr 24 04:53:09 what is in fso's "world" - i'd say things like unified contact management - that means integrating to all the other contact sotrage/whatever out ther Apr 24 04:53:33 from gmail to facebook, wave, orkut, blah blah blah blah Apr 24 04:53:48 unified message handling comes as well Apr 24 04:53:52 raster: sounds like a plan... Thanks for the valueable suggestions. Of course it's not something i want or plan to do (because for me "wow" would be e.g. emacs integration or some haskell app and that's totally uninteresting to the vendors) but probably it'll give mickey|tv some ideas. Apr 24 04:53:53 and unified voice and video calling Apr 24 04:54:16 if u can make fso simply "just work" for all of thse non-phone specific things Apr 24 04:54:24 (and u can demonstrate that and it canbe tested) Apr 24 04:54:30 then u have a big plus Apr 24 04:54:41 if in addition it has phone integration too for 1 or some phone models Apr 24 04:54:47 as a "yes - see. it can be done" Apr 24 04:54:57 the3 last bits will end up being done for you by the vendor Apr 24 04:55:01 license will mean it is open Apr 24 04:55:03 you are now happy Apr 24 04:55:09 u have fso support - from the vendor Apr 24 04:55:20 raster: do you understand there's also a developer aesthestetics problem: when you need integrate with shit (or shitty api) your architecture and code becomes shittier. Not something a developer happy with. Apr 24 04:55:30 hell chances are the vendor will contact you and pay you to help them Apr 24 04:55:38 but you need the "sales proposition" :) Apr 24 04:56:14 and yes - i know about the developer aesthetics Apr 24 04:56:30 one thing you might not know is.. the culture in companies makes such aesthetics almost irrelevant Apr 24 04:56:40 so many things are dirty and ugly Apr 24 04:56:44 and thats how it's always been Apr 24 04:56:45 its normal Apr 24 04:56:51 I know :( Apr 24 04:56:55 its a value without any "takes" Apr 24 04:56:57 err Apr 24 04:56:59 "takers" Apr 24 04:57:03 its a "so what?" Apr 24 04:57:12 you need something else to sell them Apr 24 04:57:23 if uc an also introduct good api/design etc. at the same time - awesome Apr 24 04:58:06 to care about such aesthetics you need to have ownership Apr 24 04:58:13 ie some enigneer or 2 get tot "own" some code Apr 24 04:58:14 for years Apr 24 04:58:19 and it becomes personal to them Apr 24 04:58:26 and these engineers have to care about that Apr 24 04:58:37 they wont care if they are shutned from project to project every 3 or 6 months Apr 24 04:58:44 as it becomes someoen elses problem really quickly Apr 24 04:59:06 as long as it works and satisfies requirements Apr 24 04:59:19 (none of the reqs ever say anything about code/design quality) Apr 24 04:59:22 they dont care Apr 24 04:59:37 It looks like well-intended folks should move to some academic research rather than try to fight against the vendors and other real-life stuff. Apr 24 04:59:46 its like trying to get everyone to install linux on desktosp Apr 24 04:59:48 same pricniple Apr 24 04:59:56 u are selling stuff to peolpe they just dont care about Apr 24 05:00:01 windows is "good enough" Apr 24 05:00:05 their values are not your values Apr 24 05:00:17 yeah Apr 24 05:00:21 dont FIGHT vendors Apr 24 05:00:42 either attract them and suck them in - and for that you need bait, or indeed - go to academia Apr 24 05:00:55 as they care about the same things you do - the commercial world has very different values Apr 24 05:01:17 i'm trying to help here so that fso can be successful Apr 24 05:01:21 and stop having to fight Apr 24 05:01:36 trying to help you with the things you actually can make a difference with Apr 24 05:01:46 u cant change what companies think and value Apr 24 05:01:58 you cant make them care or change Apr 24 05:02:19 but you can "entice them" to get something "for free" they would like to have - but then have to give up something (be open) in return Apr 24 05:02:23 Ok, i got it. Apr 24 05:03:38 Quite an insightful and well-reasoned idea, i'll get Mickey to read the conversation log. Big thanks! :D Apr 24 05:03:50 sure Apr 24 05:03:54 don t get me wrong Apr 24 05:03:56 i want open Apr 24 05:03:57 i like it Apr 24 05:04:03 for me its just a damned practical thing Apr 24 05:04:18 but even i have to fight against those wanting to keep things as it is Apr 24 05:04:46 and when i fight - i have a lot of weapons at my disposal as i directly influence and control many aspecs of the system already Apr 24 05:05:10 and i also seem to have the blessing of top level management Apr 24 05:05:24 but its hard for me - and i know a fight is not worth fighting until i have the right argument for it Apr 24 05:05:34 right now - fso is lacking a good argument Apr 24 05:05:56 in the face of ofono - which intel is pushing and nokia will adopt - thats got a lot more going for it just due to vendor support Apr 24 05:06:26 there are existing api's for things like limo - which have a lot of existing apps and infra built around them Apr 24 05:07:15 fso needs something it can sell that the others don't have or do very badly - so badly that fso will save a tonne of work and pain almost overnight (and you can really see that it will) :) Apr 24 05:13:11 raster: good thing about ofono is that most probably vendors will use open code for the hardware support because ofono license doesn't make using proprietary code for that easy. Apr 24 05:13:44 thats a good thing Apr 24 05:13:46 for openness Apr 24 05:13:51 but bad for fso Apr 24 05:15:43 The bad thing is that i asked ofono devs about openness and they told me they won't make a public fuss if someone invents a way to workaround the licence. They said they wouldn't care. They like openness but they won't say publically anything like "that company are stupid fuckers, we're unhappy that they use ofono the way they do". Apr 24 05:18:29 thats probably smart Apr 24 05:18:35 very smart Apr 24 05:18:40 first... get it used Apr 24 05:18:47 be "nice". dont make a fuss Apr 24 05:18:52 then.. once is entrenced Apr 24 05:18:55 much like patents Apr 24 05:19:09 send a nice "by the way.. u know thats gpl and.. you do need to comply" Apr 24 05:23:25 raster: there're ways to comply with gpl by using a wrapper and some dbus ipc, so if the vendor really wants that, he'll do that. My problem is with people's attitude. And if i'm choosing between "smart" (in your sense) and "frank", i'm choosing the latter of course. Apr 24 05:24:32 then your choice is to keep the tonens fo different protocols and closed implementations Apr 24 05:24:36 its not a step in the right direction Apr 24 05:24:43 your way is "all or nothing" i guess Apr 24 05:24:57 and the ofono way is "well i'm happy we;ve moved some way towards the right path" Apr 24 05:25:15 just a universal protocol you know works on ALL "linux phones" is a huge plus Apr 24 05:25:24 regardless if the daemon behind it is open or not Apr 24 05:25:34 encouraging that alone is a big thing Apr 24 05:26:49 raster: i guess your way is much better for you since you seem to be 10x happier than e.g. me. Well, i'm glad because happy smart people definetely make this world a better place and i like seeing people happy. So my congratulations. Apr 24 05:28:01 sorry that its not good for you :( Apr 24 05:28:09 i'm more - lenient - like the ofono guys i guess Apr 24 05:28:10 That's my choice Apr 24 05:28:21 and the march to freedom is a slow onw with many steps along the way Apr 24 05:28:25 i'm happy to see the first steps Apr 24 05:31:14 I think the world needs both pragmatic and idealist people. So that's actually a good thing everybody's different. Apr 24 05:46:39 PaulFertser: you're probably right Apr 24 05:46:46 the idealists keep pulling at one end Apr 24 05:46:54 the pargamatists keep trying to have a middleground Apr 24 05:47:13 http://www.hadess.net/2010/04/hardware-enablement.html Apr 24 05:47:18 without the idealists pulling that middleground would move a lot closer to the other end and get "absorbed" evenntually Apr 24 05:47:20 (Gypsy GPS patches) Apr 24 07:02:47 mickey|tv: I'll go fishing now Apr 24 07:02:58 if GNUtoo asks Apr 24 07:03:03 tell him please :) Apr 24 07:03:24 I'm back around 12°° or 13°° Apr 24 07:03:25 :) Apr 24 07:03:28 cu Apr 24 07:48:16 I think yahoo uses osm for something by the way Apr 24 08:32:45 TAsn: not sure why but currently i do not receive NewMissedCalls upon setting New to 0 but i do receive CallUpdated and UpdatedCall Apr 24 08:34:37 TAsn: to be more precise i receive NewMissedCalls but not every time. Apr 24 08:45:18 very weird. Apr 24 08:45:28 PaulFertser, please try setting new missed calls back to 1 and then back to 0 Apr 24 08:45:37 and tell me if you get the signal Apr 24 08:45:44 in either of those. Apr 24 08:46:31 TAsn: ok Apr 24 08:47:59 If it won't work again, this will mean it's reproduce-able so I'll probably ask for your db to test with (when I'll have time to debug). Apr 24 08:53:45 TAsn: http://paste.debian.net/70420/ Apr 24 08:54:28 Setting to back to 0 didn't produce the desired event. Apr 24 08:54:44 [SIGNAL] org.freesmartphone.PIM.Calls.UpdatedCall /org/freesmartphone/PIM/Calls :1.143 Apr 24 08:54:44 ( "/org/freesmartphone/PIM/Calls/0", { } ) Apr 24 08:54:53 I don't remember, but I think this hash should provide the changes. Apr 24 08:54:59 that occured. Apr 24 08:55:51 And thanks for reminding me I need to remove those signals. Apr 24 08:56:04 I mean, the fact that there are two. Apr 24 08:56:55 freesmartphone.org: 03tom 07framework * r0541e4fcabea 10/framework/subsystems/opimd/TODO: opimd: updated TODO. Apr 24 09:04:54 Anyhow, the empty hash table is really weird, will have to take a look. Apr 24 09:04:58 Ciao. Apr 24 09:08:58 TAsn: thanks :) Apr 24 09:25:21 PaulFertser, this thanks is premature, as I won't be able to check it until monday night. :( Apr 24 09:25:53 TAsn: np, take you time to prepare for the damn test Apr 24 09:26:19 yeah. :( Apr 24 09:26:23 thxp Apr 24 09:26:32 -p Apr 24 09:30:39 <\marco> hi to all :) Apr 24 09:31:39 good morning! Apr 24 09:46:51 shr-u upgrade and got conflict Package alsa-states wants to install file /etc/asound.state is already provided by package alsa-scenarii-shr I removed alsa-scenarii-shr then got /usr/sbin/alsactl: parse:1639: Unable to open file '/usr/share/alsa/init/00main' Apr 24 09:58:32 never mind it seems to work Apr 24 10:21:59 http://pastebin.com/TVrtkfiT - same for /home/w/OM/SHR/build/shr-unstable/openembedded/recipes/images/shr-lite-image.bb Apr 24 10:22:14 what's wrong here? Apr 24 10:45:33 mickey|tv: ping Apr 24 10:46:03 mickey|tv, I sent a fsogsmd log file to the e-mail I found in the log Apr 24 12:28:39 TAsn: i think i know why i didn't get the signal. I tried to set New on an outgoing call, sorry for the noise. Apr 24 12:29:30 PaulFertser, To be honest, I thought about asking you to make sure you are doing it on a "Missed" call, but then I assumed you would check that before :P Apr 24 12:29:52 TAsn: well, it's new... Apr 24 12:30:39 Maybe I should remove New from outgoing/whatever. Apr 24 12:30:41 what do you think? Apr 24 12:33:21 but still Apr 24 12:33:26 Empty hash table Apr 24 12:33:32 in the signals Apr 24 12:33:37 is bad. Apr 24 12:35:35 freesmartphone.org: 03tom 07framework * rc3a175d14b2f 10/framework/subsystems/opimd/TODO: opimd: Updated TODO. Apr 24 12:35:56 Hell, Release doesn't work for incoming calls :( Apr 24 12:38:20 Only ReleaseAll() Apr 24 12:38:23 :( Apr 24 12:38:26