**** BEGIN LOGGING AT Tue Jun 23 02:59:57 2009 Jun 23 03:49:55 morning guys Jun 23 08:39:50 Can anyone who knows something about framework check if this is because of FSO or Paroli: http://www.paroli-project.org/trac/ticket/155#comment:3 Jun 23 08:43:44 rhkfin: have you tried to deleting messages? Or you can't get any notification at all? Jun 23 08:45:16 maybe you deleted wrong messages Jun 23 08:45:27 some on your device, not on the SIM card Jun 23 08:47:46 PaulFertser: Yes, deleted and seems to help but I just wonder that it doens't make any sense as all (new) messages should be stored on flash, not on SIM.. Jun 23 08:49:01 pah Jun 23 08:49:13 sorry wrong window :( Jun 23 08:49:17 rhkfin: that's a current limitation of Paroli and FSO. dos1 is actively working on bringing opimd into shape, as soon as it's ready, paroli can switch to storing messages in a sane database/csv/other opimd backends. Jun 23 08:49:45 PaulFertser: so are the messages really stored on SIM or just a bug/something? Jun 23 08:50:40 And yes, opimd sound's good :) Jun 23 08:51:25 rhkfin: yes, messages are really stored on SIM. Jun 23 08:53:59 PaulFertser: oh, ok.. That's a surprise.. So do you know if /home/root/.paroli/messages/phone is regenerated on each load of paroli (=all messages read from SIM on each boot -> that's part of the reason it's slow?) Jun 23 08:56:30 any neo disto has 1000 reasons to boot slowly Jun 23 08:57:22 rhkfin: no idea, i think paroli source code has a fast answer. I can say that Zhone reads all the messages on each boot but it doesn't seem to be slow (except that one needs to wait for half a minute for the sim to become "ready"). Jun 23 08:57:33 max_posedon: thanks :) Jun 23 09:16:44 dos1: please finish opimd soon :) Just realized Paroli still saves messages on SIM, not on the phone.. Jun 23 09:17:10 rhkfin: working on it :) Jun 23 09:17:23 dos1: great :) Jun 23 09:18:00 rhkfin: now i have really nice GUI, with storing sent messages and handling errors when sending (ability to retry) Jun 23 09:18:20 rhkfin: for basics needed in paroli now there is only one bug ATM i think Jun 23 09:18:47 rhkfin: imagine you have 10 messages, and every message has ID (0, 1, 2, ..., 10) Jun 23 09:19:04 rhkfin: you delete message with ID = 9, and... Jun 23 09:19:18 dos1: nice! Jun 23 09:19:27 rhkfin: message nr 10 has recalculated ID, so it's ID is now 9 Jun 23 09:19:37 dos1: hmm.. that's bad, I'd think.. Jun 23 09:19:55 rhkfin: from my testing script with CLI it was ok, but for my testing script with GUI it isn't ;) Jun 23 09:20:07 dos1: hmm.. Are you telling me I could run you GUI next to Paroli and write & read SMS's with that? Jun 23 09:20:09 rhkfin: so i'll fix that (maybe today) and announce, how to test opimd :) Jun 23 09:20:13 ok, nice! Jun 23 09:20:53 rhkfin: when you have selected backend different than SIM in opimd, then SimBuffersSms is disabled Jun 23 09:21:05 rhkfin: so then Paroli don't even know about messages Jun 23 09:21:22 I'd like that (ok, need something to tell me there are new messages.. but anyway :) Jun 23 09:21:36 rhkfin: that's why i have that scripts Jun 23 09:21:58 dos1: nice Jun 23 09:22:17 dos1: so atm it only manages SMS's: does it know anything about contacts (to link name to a SMS number)? Jun 23 09:22:45 rhkfin: now i have opimd-cli, opimd-notifier (daemon for incoming messages), opimd-messages (inbox), opimd-resolve (for resolving contact from number), opimd-config (for selecting default backends) Jun 23 09:22:58 rhkfin: no. on contacts i was working before ;) Jun 23 09:23:17 rhkfin: and i think basics are working (but bug with IDs is also there ATM) Jun 23 09:24:13 dos1: ok.. so what will the ID bug cause? Jun 23 09:26:36 rhkfin: you have GUI to list all contacts or messages Jun 23 09:26:47 rhkfin: and then you select to delete one from the middle Jun 23 09:26:57 rhkfin: and after that, you select to delete another one Jun 23 09:27:21 rhkfin: when deleting that another one, it's possible that you app wants to delete message with non-existent ID Jun 23 09:27:46 dos1: ah, ok, so refreshing/loading GUI is needed (or a better delete-method /smth..) Jun 23 09:29:06 dos1: how come you don't have unique monotone primary key for ID (of SIM and Contacts) in all your database-backends? Jun 23 09:29:26 rhkfin: refreshing GUI is bad, so i'll fix delete methods Jun 23 09:29:41 DocScrutinizer: backends have unique monotone primary key Jun 23 09:30:04 DocScrutinizer: but imagine, when you want to use few backends Jun 23 09:30:16 some messages on SIM, some on CSV, some on SQLite Jun 23 09:30:45 then three different backends can have contact, with the same ID Jun 23 09:30:48 dos1: right. Anyway, great to see opimd progressing. Is there anyone else working on it or you alone? Jun 23 09:31:03 ID visible for apps is not ID in database Jun 23 09:31:40 hmmm, then your gui needs to keep primary_key;database_resource tuple for each sim/contact object Jun 23 09:31:56 rhkfin: right now no. i'm alone :P Jun 23 09:31:59 for each backend Jun 23 09:32:04 DocScrutinizer: no! that's opimd job Jun 23 09:32:14 DocScrutinizer: gui shouldn't care about backends Jun 23 09:32:41 DocScrutinizer: i'll just make IDs unique at each opimd lifecycle :P Jun 23 09:32:46 then pimd needs to provide an own primary key Jun 23 09:33:03 DocScrutinizer: it provides not key, but it's not unique ATM Jun 23 09:33:09 DocScrutinizer: i want to make it unique ;) Jun 23 09:33:16 DocScrutinizer: so problem will be solved Jun 23 09:33:33 s/it provides not key/it provides key/ Jun 23 09:33:38 wtf i'm writing? :x Jun 23 09:59:31 ok, some fso-gurus around. Calypso receives an SMS and saves it to SIM. Framework tells this to Paroli. Paroli ask FSO for the message and saves it on /home. After this Paroli asks FSO to delete the message from SIM? Jun 23 09:59:46 Could someone tell me which part fails here, when the SIM is filled with messages? Jun 23 10:00:07 rhkfin: i think paroli doesn't ask to delete from SIM Jun 23 10:00:38 PaulFertser: I have 112 messages on phone and 29 on sim -> at least it's been working earlier Jun 23 10:01:06 rhkfin: see #openmoko Jun 23 10:01:28 ok :) Jun 23 10:01:34 rhkfin: and sorry for providing you with wrong guesses :-/ Jun 23 10:01:56 np (I feel more sorry to pass on these wrong guesses.... :/ Jun 23 10:04:30 hi everyone Jun 23 10:04:48 rhkfin: Zork|Gone sent so many sells, that it has not been processed yet! Jun 23 10:05:05 onen|openBmap: autch!!!! Jun 23 10:05:13 * rhkfin is worried :) Jun 23 10:05:32 rhkfin: by the way, I am still testing the debian version of 0.3.1 Jun 23 10:05:36 onen|openBmap: ok Jun 23 10:06:12 rhkfin: time outs in fso raised bugs in my app, and it lead me to put better data quality assurance in the loop Jun 23 10:06:39 ok Jun 23 10:06:45 onen: hi Jun 23 10:06:53 rhkfin: I am very much happy with this addition, as it will prevent bad data which would occur because of any kind of reason while gathering gsm/gps data for a log Jun 23 10:07:00 Q-Master: hi, wassup? Jun 23 10:07:12 onen|openBmap: nothing, just greeting. 8) Jun 23 10:07:18 onen|openBmap: ok, nice Jun 23 10:08:05 rhkfin: next step gui overhaul ;-) Jun 23 10:08:15 rhkfin: I know you are very much waiting for this :-) Jun 23 10:09:30 onen|openBmap: TELLMETELLME!! Jun 23 10:10:22 rhkfin: sorry, not very much to tell. Last things in mind is a panel with big sized labels for most important things, and small for the rest Jun 23 10:10:39 rhkfin: so that you can read it while driving or so on Jun 23 10:10:44 onen|openBmap: ok.. Jun 23 10:11:22 onen|openBmap: I jsut thought some days ago that you could've made a small upgrade to show the # of cells and that's it, not make a full rework for the next release, just the most important little changes. Jun 23 10:11:34 this damn thing refuse to time out again since I added code to take care of it, thus I cannot test my patch >:-( Jun 23 10:12:28 rhkfin: I will probably make new release before complete rework done. 1. better feedback sooner. 2. I also want to have some gui improvements for my own use :-) Jun 23 10:13:46 onen|openBmap: nice! Jun 23 10:17:14 onen|openBmap: two days ago i uploaded some logfiles in openbmap, but nothing happend yet (the cells are not on the map yet and i saw no twitter message)... what now? :( Jun 23 10:19:15 agg1n: hi. two days ago? I know Zork|Gone uploaded a lot of data, and these have not been processed yet. But other nicknames have been twittered... maybe you are running out of luck, and the quantity of upload from Zork|Gone Jun 23 10:19:53 agg1n: does not allow the server to process all the uploads so far. and your file was not taken into account every time Jun 23 10:20:41 agg1n: twitter message should appear when the system starts processing it (or detect your upload, I have to ask Nick) Jun 23 10:21:40 agg1n: once the Zork|Gone wave will be over, if your upload has not appeared, then ping me again. I will see this with nick Jun 23 10:23:31 onen|openBmap: ok, why does it take so long, does the server perform some checks on the data? Jun 23 10:24:02 twitter message onen|openBmap ? Jun 23 10:24:49 agg1n: we had an hardware failure last week or the one before. thus, Nick did put the server in "testing"mode, it does run twice a day on average, instead of dynamically when uploads detected Jun 23 10:25:08 playya: ??? Jun 23 10:25:18 playya: hallo :-) Jun 23 10:25:23 hi Jun 23 10:25:52 to you twitter when you server processes date? Jun 23 10:26:04 agg1n: so when uploading, you should see your uploads appear in a day, maximum or so Jun 23 10:26:45 playya: twitt occurs when processing of your upload starts (IIRC) Jun 23 10:27:23 playya: I think the amount of data zork sent is taking all the server ressource so far Jun 23 10:27:36 ok Jun 23 10:31:12 agg1n: I see a twitt for you on 21st, isn't it what you were looking for? Jun 23 10:32:49 onen|openBmap: i did two uploads on the 21st, one small and one bigger (250km drive) Jun 23 10:33:03 onen|openBmap: i think that on twitter is the small one Jun 23 10:34:28 agg1n: I see. please come back to me after the next update or so, to see if it has been taken into account or not. I will keep an eye on it also Jun 23 10:34:54 onen|openBmap: k, will do :) Jun 23 10:36:25 agg1n: Zork|Gone rhkfin and I are very much waiting for the update, because of the number of cells Zork|Gone brought to the project :-) Jun 23 11:01:26 rhkfin: opimd, when backend different than SIM is selected, disables storing messages on SIM - they are recievied directly Jun 23 11:09:01 dos1: I just learned that Paroli doesn't save SMS's on SIM at all.. Calypso stores it there but then Paroli asks FSO to copy it to /home and then asks FSO to delete the message Jun 23 11:09:51 llo onen|openBmap :) Jun 23 11:10:06 sorry for the hassle :P Jun 23 11:12:33 rhkfin: with opimd, calypso doesn't store it on SIM - it goes directly to FSO. and you don't need client app to store it. it's stored by FSO. client app is only needed to notify user about incoming message Jun 23 11:12:41 onen|openBmap: you definitely need more processing power.. Jun 23 11:12:47 dos1: ok Jun 23 11:13:07 dos1: good news to hear you're work on opimd is going well! Jun 23 11:13:42 onen|openBmap: I'd also like to see the total of cells contributed directly to openbmap in the stats page (=SUM of the cells). Jun 23 11:14:09 rhkfin: isn't that the "trusted cells" ? Jun 23 11:14:15 29823 Jun 23 11:14:16 onen|openBmap: And I'm not sure if I like the "415124 cells Jun 23 11:14:18 which 29823 are trusted Jun 23 11:14:30 Zorkman: yes, but I think it should be in the stats page. Jun 23 11:14:40 rhkfin: true Jun 23 11:15:06 The attitude of the word 'trusted' is not nice -> it tells you that the rest (=from opencellid an cellhunter) is 'not trusted'... So if it's not trusted, why is it there? Jun 23 11:15:21 -> confirmed would be a bit more friendlier.. Jun 23 11:15:45 Zorkman: rhkfin: yes, trusted cells == total cells contributed directly to obm Jun 23 11:16:34 rhkfin: your interpretation is correct. and that is the mean of it. oci is full of garbage Jun 23 11:16:46 rhkfin: (we don't import ch so far) Jun 23 11:17:02 onen|openBmap: but oci imports ch. Jun 23 11:17:31 rhkfin: and the idea was to bring coverage to users, but as data comes in, untrusted data will be replaced by trusted one Jun 23 11:17:53 rhkfin: no. ch said he would upload to oci. so far it only an intention, AFAIK Jun 23 11:17:54 onen|openBmap: So basicly you are saying (here & on the web page): 'we have imported over 10 times more cells than we have, but it's worth nothing, but we still imported it because it's a big number' Jun 23 11:18:39 onen|openBmap: how about replacing the 'trusted' with 'confirmed'.. I know it might sound stupid but.. I think there's a difference there.. Jun 23 11:18:42 onen|openBmap: you could concisder cells of "high precision" (=trusted ones) and of "lower precision" (the cellID ones) Jun 23 11:18:43 rhkfin: no i say we cannot guarantee the quality of this data, but to bring coverage to our users, we imported it Jun 23 11:19:06 onen|openBmap: ok.. Jun 23 11:19:22 onen|openBmap, rhkfin: have there been tests to see how correct the cellID db is? Jun 23 11:19:35 Zorkman: no idea Jun 23 11:19:48 rhkfin: Zorkman: I got your point. I will talk about it with Nick. But the idea was exactly that : it comes from an untrusted source Jun 23 11:20:02 Zorkman: which one, oci? Jun 23 11:20:09 yes Jun 23 11:20:25 onen|openBmap: is the data or the source untrusted? Jun 23 11:21:30 Zorkman: Nick told me he did some cleaning, for what he saw (cellid with too many digits to be a real value, etc.) Jun 23 11:21:53 Zorkman: and we don't have gps speed and so on, so we don't know how accurate is the data Jun 23 11:22:30 rhkfin: ah ah, good question :-) the data is untrusted. I don't think oci would put wrong data on purpose Jun 23 11:23:08 onen|openBmap: how often is the data of oci saved? every 10s? Jun 23 11:23:28 rhkfin: sorry, do you mean obm? Jun 23 11:23:51 onen|openBmap: no, oci Jun 23 11:24:19 rhkfin: well then I don't understand your question. could you explain? Jun 23 11:24:42 onen|openBmap: I was thinking if the speed could be generated from GPS data (if you have coordinates & time -> speed can be generated.) - if you have also the time. Jun 23 11:24:55 * onen|openBmap is refreshing is obm webpage all the time to see if zorkman's contribution finally hit the site Jun 23 11:25:24 :) Jun 23 11:25:31 the lol would be that I only traveled on roads that were already covered D Jun 23 11:25:40 Zorkman: any guesses how many will you have? Jun 23 11:25:50 rhkfin: does not work. if you have two points with time, you can compute average speed in between. but what if the first point was at 70 km/h, and the second at 0km/h (a red light) Jun 23 11:25:57 * Zorkman is hoping for 3k Jun 23 11:26:28 onen|openBmap: yes but that'd still be better than.. nothing.. Jun 23 11:26:56 onen|openBmap: does it really matter that much which speed you are traveling? Jun 23 11:27:17 rhkfin: please understand that our goal is not to but patches on bad data from other sources. but convince people to contribute to our because our approach brings better quality. Jun 23 11:27:40 onen|openBmap: Hmm.. Jun 23 11:27:42 Zorkman: :-D if it does not, then obm is unuseful ;-) Jun 23 11:28:07 onen|openBmap: i have btw still all the logs on my phone, I forgot to delete them the first time i uploaded them; but yesterday i drove to holland and resubmitted everything, so I just hope this doesn't increase the load on server (that I didn't delete them) Jun 23 11:28:16 Zorkman: 50 km/h you move about 15 m/s. in a city where you have cells of 200 meters, it is important Jun 23 11:28:23 true Jun 23 11:28:35 but on highways this is less important, no? Jun 23 11:29:23 maybe you could check wich oci cells are on highways and trust those? Jun 23 11:29:27 * rhkfin thought the goal was to get good coverage using all the available means & data, not to do it 'the right way' (especially if the data will be improved along time..) Jun 23 11:30:01 Zorkman: the server can respond: ok, exists, or sth like this, you would have seen in the app log that it considers the upload a success and moves the data to Processed_logs directory, and logs: probalby already uploaded, file exists on server Jun 23 11:30:56 Zorkman: on highway cells are bigger, but your speed too. so proportionally you bring as much inacurracy Jun 23 11:31:40 Zorkman: rhkfin: of course we could do a lot of work to test data and see what could be extrapolated, but I really think we have better to do Jun 23 11:32:24 well, as long as there's no client apps using the data, it really doesn't matter.. Jun 23 11:33:48 Zorkman: it also depends on the client. our windows mobile client works only if dll has some entry points. so not with all phones. and sometimes it caches data (e.g. you get on the plane in France, you step out in Bulgaria, you turn the phone+obm back on, first log uses the data from France!) Jun 23 11:34:24 But when the first clients 'hit the street', having 35000 'trusted' cells vs. having 350 000 'untrusted' makes a huge difference to users -> some work to better the precision of the OCI data might be useful. But if OBM has more points than 200 000 when the client's released, I understand.. Jun 23 11:35:00 rhkfin: I see you point. indeed a good one. Jun 23 11:35:18 onen|openBmap: have you tried to contact opencellid to ask them to improve their method of logging? Jun 23 11:35:38 rhkfin: let's say I hope the contributions will go up, and that in 2-3 months, we will not see the overhead work to qualify oci data useful anymore :-) Jun 23 11:35:39 onen|openBmap: thanks :) Jun 23 11:36:49 onen|openBmap: cell size doesn't matter, if you follow a properties-per-point paradigm Jun 23 11:36:58 rhkfin: please understand that if s.o. looks for cell db, and see 30K for obm and 300K for oci, he will pick oci right away. if he sees we use oci, but have some more trusted cells, then he might wonder what it is (a section "what makes us different" is needed on our website) Jun 23 11:37:43 Zorkman: we even proposed back in january or feb, to merge our db in their, and disband obm as a standalone project Jun 23 11:38:07 Zorkman: stefan also asked questions (see ML archive, community), we have been ignored Jun 23 11:38:28 Zorkman: oci is there to welcome your uploads, with a big smile, but ignores all the rest Jun 23 11:39:28 DocMobilizer: Hallo Doc. It does. if you have a point at 150 km/h or at 1km/h, the second is most probably more precise than the first. isn't it? Jun 23 11:39:34 onen|openBmap: ok, understood. But until obm has enough data to 'run on your own', it'd be fair to respect what OCI has done: you're working on their shoulders for a long time still (regarding the no of cells = possibility to be located based on cells) Jun 23 11:41:23 rhkfin: we imported their data for a month or so, obm exists since last october I think. so I don'tsee it as a long time. Jun 23 11:41:36 onen|openBmap: yes, but in your equation there's no cell size mentioned Jun 23 11:41:41 rhkfin: but what do you mean by respect to what they have done? Jun 23 11:42:32 DocScrutinizer: ok, I meant cell size. You know our (better :-P) approach differs from yours :-P Jun 23 11:42:54 onen|openBmap: e.g. TA is same "size" no matter how large the cell is Jun 23 11:42:56 onen|openBmap: rhkfin just means it's not "nice" to call their data (indirect) untrustworthy Jun 23 11:44:04 Zorkman: rhkfin: to be honnest at the time we settled for that, we were pissed off by the attitude from oci, so maybe we used a stronger word as what we would normally have Jun 23 11:44:28 DocScrutinizer: indeed Jun 23 11:45:13 onen|openBmap: it'll take a while (maybe an year?) until you can tell people why you actually are bigger/better. Precision's nice but if you have only 10% of 'own' data and 90% from OCI, most of the data comes from OCI -> when someone is located using data in OBM, it's 90% likely to happen with OCI data -> some respect is fair. If you dont' agree what they do but still use their data.. some respect is required. Jun 23 11:45:18 Zorkman: rhkfin: I got your point, and will discuss it with Nick. I always think that if many voices from our users go in the same direction, I might (no it can't be) be wrong Jun 23 11:45:19 onen|openBmap: please elaborate about *my* approach and where it's differing from yours Jun 23 11:45:27 onen|openBmap: ok, thanks .) Jun 23 11:46:04 (and I wish OBM will be PR'd well to get a big used community to make precise location estimates usable!) Jun 23 11:46:10 user community Jun 23 11:46:57 * Zorkman thought DocScrutinizer and onen|openBmap had the same view (a program is always better with the "approved by the Doc" logo on it ;-)) Jun 23 11:47:04 onen|openBmap: "I always think that if many voices from our users go in the same direction, I might (no it can't be) be wrong" <- I respect this! Some projects just won't listen to the community (well, some of them even don't want a community to exist :) Jun 23 11:47:49 Zorkman: that's what puzzled me as well Jun 23 11:48:02 rhkfin: well if I let my pissed off side talk, I would say he talked to us as kinds who did not think when they made obm, as oci already existed, he simply say our approach brings nothing, and ignores all the requests. He did not do a lot of work, most of the work has been contributed by community, through clients. but you could argue that I then talk bad of the community work too Jun 23 11:48:36 rhkfin: what do you mean, you think we PR badly? Jun 23 11:49:14 DocScrutinizer: we draw a coverage of a cell, out of the points. and try to get some barycentre Jun 23 11:49:58 Zorkman: DocScrutinizer: we agree on the fact to collect good data, and a lot of data (arfcn, ta, etc.). but we have different approaches to how to get your location out of it Jun 23 11:50:49 onen|openBmap: no, I'm not saying you're PR'ing badly: however every OS project could do better regarding to marketing (in my case releasing a version with new features that I know are easy to implement and the next version will have it, would be a hit - also visualization of the data on the database would make one more interested :) Jun 23 11:50:58 onen|openBmap: once there is an api to use on our phone it will be quite simple to test: have two databases (one with your approuch and one with what DocScrutinizer suggests and compare it with the actual gps reading) Jun 23 11:51:37 the one with the smallest error wins and rules the world for a while :) Jun 23 11:52:14 Zorkman: you don'tneed it. you have the gps+gsm data on the server, you can compare approaches directly there! Jun 23 11:52:45 DocScrutinizer: or did I say sth wrong? Jun 23 11:52:52 no Jun 23 11:52:52 onen|openBmap: and did you test which way is best? Jun 23 11:53:01 err yes Jun 23 11:53:39 your statement your approach is better obviously is completely wrong ;-P Jun 23 11:53:55 onen|openBmap: but I think that the equation is not correct: due to the way you measure barycentrum it would always seem the best way **with the points you already have** Jun 23 11:54:08 Zorkman: no, we are still fighting with our approach. I did some work to log ta for DocScrutinizer, but it is not there yet Jun 23 11:54:36 we should test it by measuring DIFFERENT points, and comparing to what the data would predict in both cases Jun 23 11:55:11 Zorkman: sure. then you could wonder if nobody ever saw this cell somewhere else (let's say because of a bulding hiding it), maybe it is not that bad Jun 23 11:55:47 anyway, this is only usefull once there will be an api Jun 23 11:55:58 Zorkman: I know our approach is not bullet proof, but for the moment I really much work on getting data for all the people interested to test their way, and try to make the project known Jun 23 11:56:20 DocScrutinizer: :-D Jun 23 11:56:47 onen|openBmap: i know and i agree Jun 23 11:57:45 anybody else gets a lot of error messages when opkg upgrading (about /usr/lib/python2.6/ files and /usr/share/etk/themes/default.edj) ? Jun 23 11:57:45 Zorkman: (test with points not in db) agreed, but on the server side would already give you a good idea. e.g. for this cell, we have 50 points, and the average inacuraccy is 258m from real position,or so Jun 23 12:04:33 rhkfin: you said it is not nice to call data from oci untrusted. but what if they are labeled "low precision". it is also pointing them as bad, isn't it? Jun 23 12:08:38 onen|openBmap: you could just say 415124 cells, of which 29823 are high-precision ones Jun 23 12:09:16 Zorkman: then you suggest the rest is not high precision. ... I don't know... Jun 23 12:10:08 then you could just post the total (415125) and put the openBmap ones on the stat pages... Jun 23 12:10:22 in any case, I don't find it very important, but rhkfin does have a point Jun 23 12:11:06 Zorkman: then you kind of steal the data from oci, because you state in capital letters: we have 400K cells, but in small letters down the page, we import oci data Jun 23 12:12:23 you have 400k cells? o.O Jun 23 12:12:46 isn't that 400k points? Jun 23 12:12:53 Zorkman: rhkfin: well will talk with Nick about this. thanks for raising the issue. Let's hope we soon have enough data from ourselves Jun 23 12:13:41 DocMobilizer: no cells. ch 90K the last time I looked, and we should be above 30K thanks to Zorkman soon Jun 23 12:14:17 DocScrutinizer: oci got massive import for soem country. (GB, I think). IIUC Jun 23 12:14:55 mere cell knowledge is rather useless Jun 23 12:15:19 what do you mean? Jun 23 12:15:27 as you don't know the rf field characteristics of each cell Jun 23 12:16:14 sorry I don'tfollow you Jun 23 12:17:21 if I know the cell data (and nothing more) I can get a location not any beter than "I'm max 30Km away from that cell" Jun 23 12:17:29 do you mean having massive import of basic data does not bring much? Jun 23 12:18:04 DocMobilizer: for agps a 30km radius does help Jun 23 12:18:15 *DocScrutinizer Jun 23 12:18:51 well, my approach is more like 30m precission Jun 23 12:19:22 diameter of probable location Jun 23 12:19:35 not 30km radius Jun 23 12:19:35 DocMobilizer: but better to have 30m were possible and 30km where not possible? Jun 23 12:20:03 sure, but the point is you never know Jun 23 12:22:03 as there's no way to tell about actual current precission if you don't have a data-per-point approach Jun 23 12:22:47 anyway, bbl Jun 23 12:22:56 me too Jun 23 12:22:57 bye Jun 23 12:23:41 cant build an image (shr-unstable) as intone wont build - http://pastebin.com/m6d079df0 Jun 23 12:23:58 rebuilt libID3, but it still cant find it Jun 23 12:55:23 dos1: hey, why now gprs.pickle is stored in /etc/shr-settings and not created automatically? Jun 23 12:56:11 Q-Master, its updated on successfull connect Jun 23 12:56:41 max_posedon: not right IMO. Jun 23 12:57:12 if I don't want to connect right now i will be forced to print it several times... Jun 23 12:58:10 anyway there's needed a button to clear the contents of the fields. doing this by hands is a pain. Jun 23 12:58:16 why you want print it when you don't want connect?! Jun 23 13:00:34 to enter it 1 time when setting everything and forget till i want to connect Jun 23 13:00:54 like i'm doing right now on my SE phone Jun 23 13:01:35 IMO settings MUST store everything i've changed there. without any "if" Jun 23 13:01:55 but we need 2 exit buttons then Jun 23 13:02:06 1 to store, and 1 to exit Jun 23 13:02:09 without storing Jun 23 13:02:37 neo has small screen Jun 23 13:02:50 we should avoid any buttons as much as we can Jun 23 13:03:13 I dislike your idea with one extra button Jun 23 13:03:58 also there is a problem in concept Jun 23 13:04:23 Q-Master, WHEN shr-setting should save apn/login/password Jun 23 13:04:39 if you don't connect and want be able press "don't save" button? Jun 23 13:05:38 I don't like the idea when connecting to somewhere is spreaded into tonns of different progs Jun 23 13:06:03 settings should set up, but not call, connect, send messages, bring coffee Jun 23 13:06:33 connection IMO should be as automatic as possible Jun 23 13:06:43 like gps Jun 23 13:06:46 Q-Master, anyway, try answer to my question connected with your concept Jun 23 13:07:19 2 buttons with store/exit much worse Jun 23 13:07:21 max_posedon: there should be 1 key: "Save" in exchange of "connect" Jun 23 13:07:31 but when connect?! Jun 23 13:07:41 automatically Jun 23 13:07:49 using the priority Jun 23 13:08:04 like now I do have in SE phones. That should be great Jun 23 13:08:05 big problems in rouming Jun 23 13:08:52 there's no problem to popup the query with the question to connect or to skip Jun 23 13:08:53 also framework right now isn't stable enough to have fulltime gprs connected on Jun 23 13:09:08 that is a bad idea Jun 23 13:09:16 after a while gsm will dead Jun 23 13:09:26 your SE always connected Jun 23 13:09:28 coz in beeline when gprs is connected there'll be no incoming calls Jun 23 13:09:52 max_posedon: nop, only when prog is trying to connect somewhere Jun 23 13:10:00 so, one more reason for manually on/off Jun 23 13:10:24 and my SE connects/disconnects AUTOMATICALLY Jun 23 13:10:25 I want control my phone, if you want some phone that will control me, I'll take iPhone Jun 23 13:10:38 Q-Master, it doesn't work like you think about it Jun 23 13:11:13 just need a popup with permission, but not crowling through a menues, then entering tonns of info and then connecting Jun 23 13:12:29 I remind you that shr saves apn/login/password Jun 23 13:12:42 only when i press "connect" Jun 23 13:12:46 yep Jun 23 13:12:50 otherwise it is not Jun 23 13:12:56 so, since 2nd connect all is fine. Jun 23 13:13:19 also, if you want automatically connect/disconnect gprs Jun 23 13:13:20 so setting my phone at work, having internet with needed apn data is not possible if i don't want to connect now Jun 23 13:13:32 go ahead, try find docs how to do this in Linux Jun 23 13:13:59 it's easy in terms of FSO Jun 23 13:14:04 really? Jun 23 13:14:09 just need to obtain a resource Jun 23 13:14:09 I do ping google.com Jun 23 13:14:23 hehe, from where? Jun 23 13:14:24 how FSO will on gprs? Jun 23 13:14:27 from terminal Jun 23 13:14:28 from console? Jun 23 13:14:29 yep Jun 23 13:14:35 on the phone? Jun 23 13:14:38 yep Jun 23 13:14:45 how many ppl would do so? Jun 23 13:14:54 doesn't metter Jun 23 13:14:54 some 10 freaks like us? Jun 23 13:15:16 I just want to say, that your concept isn't very good Jun 23 13:15:17 normal user wont ask for console. Jun 23 13:15:27 neo users aren't normal Jun 23 13:15:40 and I really need ssh to my servers Jun 23 13:15:51 max_posedon: FSO is not positioned only for a Neo HW Jun 23 13:16:11 max_posedon: so you are able to dbus a needed resource Jun 23 13:16:18 I understand it Jun 23 13:16:22 just like ping 8) Jun 23 13:16:31 but wrapping pings... Jun 23 13:16:48 ok, we can have vala-terminal-with-internet icon) Jun 23 13:17:10 nop. just write a script which will start/stop the connection when you really need it Jun 23 13:17:38 gprs/wifi/ethernet Jun 23 13:17:48 I still doesn't understand how you want handle this? Jun 23 13:17:49 anyway when preparing the software one should write a needed wrapper Jun 23 13:18:04 we need a priority. Jun 23 13:18:19 but I'll need change this priority *very* often Jun 23 13:18:32 no ethernet => trying wifi, no wifi => trying gprs Jun 23 13:18:38 nop Jun 23 13:18:55 onen|openBmap: low precision is smoother than untrusted, yes. Jun 23 13:18:59 -> out.. Jun 23 13:19:00 I assure you that you'll need to set it once Jun 23 13:19:56 right now neo use internet through laptop, in a hour laptop will use internet via neo. Jun 23 13:20:19 so? Jun 23 13:20:24 onen|openBmap untrusted might not be ideal wording. Perhaps "unconfirmed" and "confirmed" is better wording Jun 23 13:20:32 when I attach usb-lan to neo it should stop grps and try usb0? Jun 23 13:20:32 but no big ideal IMHO Jun 23 13:20:51 max_posedon: nop. it shouldn't do anything Jun 23 13:21:06 max_posedon: you already have a connection Jun 23 13:21:26 max_posedon: you should drop it by hands if you want Jun 23 13:21:45 but very expensive and very slow... so, in all cases I have a lot of to do with my fingers Jun 23 13:22:01 just press 1 time an icon Jun 23 13:22:14 anyway you are not a normal user. 8) Jun 23 13:22:16 same as now, I press 1 icon to connect Jun 23 13:22:26 (or, 3 buttons) Jun 23 13:22:27 3 icons Jun 23 13:22:32 not 1 Jun 23 13:22:48 it can be moved to desktop even now Jun 23 13:23:02 that's 3 times longer including the loading of shr-settings and then all it's needed modules (4 imo) Jun 23 13:23:27 you switched to another topic little bit Jun 23 13:23:40 max_posedon: easy way: a popup with a choice of all available connections Jun 23 13:24:13 with possibility of connecting/disconnecting Jun 23 13:25:28 the best way is an icon in a top shelf Jun 23 13:25:50 it is the best way even now Jun 23 13:26:43 we even don't have any info on do we have a connection now or not Jun 23 13:30:05 hehe... shr-messages segfaulted Jun 23 13:32:06 dos1: 2009.06.21 16:35:05.244 opimd ERROR SIM-Contacts-FSO: Could not request SIM phonebook from ogsmd : org.freedesktop.DBus.Error.ServiceUnknown: The name org.freesmartphone.ogsmd was not p Jun 23 13:32:06 rovided by any .service files Jun 23 13:32:06 2009.06.21 16:35:05.264 opimd ERROR SIM-Contacts-FSO: Could not install signal handlers! Jun 23 13:33:03 just after starting of frameworkd Jun 23 13:37:15 bye Jun 23 13:41:24 Somehow I'm unable to create an image for shr because libtool doesn't want to be unpacked. Jun 23 13:42:20 I already tried to rm the downloaded files and download them manually but libtool-1.5.10 still hangs. Jun 23 13:49:01 damn tuxbrain :( does anyone know how can I reach them? they are not replying my mails :( Jun 23 13:54:44 TAsn, still waiting for you leather pocket? :P Jun 23 13:54:51 +r Jun 23 13:54:56 yes Jun 23 13:54:59 and payment Jun 23 13:55:00 ouch Jun 23 13:55:00 :\ Jun 23 13:55:15 very unprofessional Jun 23 13:55:25 yup Jun 23 13:55:30 ;( Jun 23 13:55:40 actually I talked with david from tuxbrain for a bit Jun 23 13:55:45 (gave him my bank info) Jun 23 13:55:54 for the wire transfer Jun 23 13:55:58 and the shipping addr Jun 23 13:56:11 though he's gone Jun 23 13:56:25 same goes for trying to get them from their website Jun 23 13:56:42 (contact form) Jun 23 13:56:46 this sucks :( Jun 23 13:56:52 it's not a lot of money Jun 23 13:56:58 though it's the principle Jun 23 13:57:06 and it's still money Jun 23 13:57:09 50 euros Jun 23 13:57:10 ;\ Jun 23 13:57:25 TAsn: they are on holiday till tomorrow Jun 23 13:57:27 http://www.tuxbrain.com/en/content/pause-vacations Jun 23 13:57:28 actually it's also the money :) Jun 23 13:57:34 tig|, since when? Jun 23 13:57:40 I'm trying to reach them for two months now Jun 23 13:57:41 ... Jun 23 13:57:44 even more Jun 23 13:57:45 "We will have a little break from today Friday June 19th to Wednesday June 24th. Orders along this period will be attended in order of entrance on Thursday June 25th." Jun 23 13:57:49 ah Jun 23 13:57:55 yeah ;\ Jun 23 13:58:08 I wish this was the case Jun 23 13:58:30 actually I'm checking my back account info every now and then, suspecting I'm a victim to a fraud. Jun 23 13:59:02 although no money lost yet. Jun 23 13:59:08 none that I noticed anyway Jun 23 13:59:10 :| Jun 23 14:00:00 anyhow I'm off Jun 23 14:00:01 ciao. Jun 23 14:01:23 TAsn: if all else fails, bitch on the community list. that tends to wake people up :) Jun 23 14:02:21 :) Jun 23 14:03:08 There is no phone number only a postal address on the whois on the contact page Jun 23 14:04:25 TAsn: I have found a phone number Jun 23 14:04:57 TAsn: Tuxbrain David Samblas, +34 937 069 787 Jun 23 14:05:21 from their joint press release with Openmoko announcing their distributor status Jun 23 14:18:04 @dos1, i think i get a usable version of gsm_gad till end of the week Jun 23 14:28:35 freesmartphone.org: 03mickey 07mickey * rd6f702a9a693 10alsa-scenario/DEPRECATED: alsa-scenario is dead, we now talk to alsa directly. Jun 23 14:40:50 freesmartphone.org: 03mickey 07specs * r846bb6733607 10/LICENSE: add LICENSE file Jun 23 14:46:30 mrmoku ? Jun 23 14:46:36 Ainulindale, yep Jun 23 14:46:43 http://patchwork.dev.bearstech.com/ <= and spaetz too Jun 23 14:46:52 Everything is not yet ready (link to ML particularly) Jun 23 14:46:55 But at least it's functional Jun 23 14:47:41 good Jun 23 14:47:55 We can upload them manually Jun 23 14:49:20 mrmoku: I set you as a maintainer Jun 23 14:50:01 freesmartphone.org: 03mickey 07cornucopia * r8428748cf506 10/misc-vapi/COPYING: misc-vapi: add COPYING file; this is licensed under LGPL 2.1 Jun 23 14:51:19 freesmartphone.org: 03mickey 07cornucopia * r3eb618d65692 10/misc-vapi/vapi/posixextra.vapi: misc-vapi: posixextra: add license header Jun 23 14:53:43 freesmartphone.org: 03mickey 07libfso-glib * rb855b0297ff6 10/COPYING: relicense under LGPL 2.1 to be more permissive Jun 23 14:55:37 mickeyl: hey Jun 23 14:55:41 mickeyl: again, great article Jun 23 14:55:47 mickeyl: published on july 11th Jun 23 14:55:57 mickeyl: the editor in chief told me the paper was great Jun 23 14:56:04 thanks :) i think it's quite ok considering the amount of time we had Jun 23 14:56:04 28 pages in the end Jun 23 14:56:12 next time I'd love to have more time though :) Jun 23 14:56:28 Well we can plan a better paper another time if you want to :-) Jun 23 14:56:58 righto Jun 23 14:57:51 meanwhile do not forget you don't legally have the rights to publish your paper before 4 months Jun 23 14:57:59 and you'll have to publish it according to CC-NC-ND Jun 23 14:58:05 (no derivative, no commercial use) Jun 23 14:58:32 it may be annoying, but that's you got for being famous :-p Jun 23 14:58:37 +what Jun 23 14:59:28 freesmartphone.org: 03mickey 07cornucopia * r647352c96582 10/fsousaged/src/plugins/controller/plugin.vala: fsousaged: check for invalid parameters in {Get|Set}ResourcePolicy Jun 23 14:59:34 Ainulindale: understood. Jun 23 15:08:35 Ainulindale, do you think it will send me the confirmation mail someday? :P Jun 23 15:09:07 It should have Jun 23 15:09:32 k, will be more patient then :) Jun 23 15:13:44 freesmartphone.org: 03mickey 07cornucopia * r6f3d1e5dea60 10/fsousaged/src/plugins/controller/plugin.vala: fsousaged: remove warnings and secure against more potential failures Jun 23 15:13:49 mickeyl: in which prestigious journal did you land a publication ? Jun 23 15:14:13 i forgot the exact name, Ainulindale ? Jun 23 15:14:25 we did a cooperation in a french journal Jun 23 15:14:27 s/in/for/ Jun 23 15:15:36 GNU/Linux Magazine France Jun 23 15:15:37 mrmoku: please update to fsousage HEAD Jun 23 15:15:58 mrmoku: this one should fix all the remaining problems Jun 23 15:16:30 bbiab, need to pick up Sabine from the airport Jun 23 15:16:30 mickeyl, great, ok :) Jun 23 15:16:36 thanks Jun 23 15:16:51 Ainulindale, buildhost has serious connectivity problems :( Jun 23 15:17:02 noticed already last night that it does not resolve addresses Jun 23 15:17:10 and connecting to it is slow like hell Jun 23 15:17:20 might be the reason for not getting out the mail Jun 23 15:18:08 mrmoku: DNS changed Jun 23 15:18:14 I edited the zones Jun 23 15:18:18 (yesterday) Jun 23 15:18:33 well... ssh to the buildhost and try to ping something Jun 23 15:18:42 has nothing to do with your zones Jun 23 15:20:07 mrmoku: just transmitted the info Jun 23 15:20:49 mrmoku: I'll be back in 3 hours I'll keep you in touch Jun 23 15:20:57 k Jun 23 15:32:17 (trying to compile SHR) I'm stuck with libtool. gzip always tells me "gzip: stdout: Broken pipe". Is there a way to fix this? Jun 23 15:40:51 DeGT, which package and can you paste the log? Jun 23 15:43:27 NOTE: package libtool-native-1.5.10-r10: task do_unpack: started Jun 23 15:43:27 NOTE: Unpacking /home/arne/freerunner/shr/selbermachen/downloads/libtool-1.5.10.tar.gz to /home/arne/freerunner/shr/selbermachen/shr-unstable/tmp/work/i686-linux/libtool-native-1.5.10-r10/ Jun 23 15:43:27 Jun 23 15:43:27 gzip: stdout: Broken pipe Jun 23 15:43:27 tar: Child returned status 1 Jun 23 15:43:29 tar: Exiting with failure status due to previous errors Jun 23 15:43:31 NOTE: Task failed: Jun 23 15:43:33 [...] Jun 23 15:44:48 the file is okay, I can unpack it without problems. Jun 23 15:55:07 DeGT: gzip: stdout: Broken pipe -- is the important bit of info Jun 23 15:56:29 Yes, but how can I fix it? Jun 23 15:57:14 DeGT: probably something like "tar -xv libtool-1.5.10.tar.gz | someborkedprogram " Jun 23 15:57:15 tracfeed: Ticket #528 (Python-email package conflicts with python-misc) created Jun 23 15:57:39 DeGT: fix someborkedprogram Jun 23 16:00:50 I don't know anything about bitbake, so how can I see what the borked program is? Jun 23 16:01:13 paste the log, like playya suggested Jun 23 16:01:46 or find the insulting line in script and scrutinize Jun 23 16:01:48 tracfeed: Ticket #529 (No package for python gzip module) created Jun 23 16:03:08 DeGT: "set -x" at start of script is really helpful Jun 23 16:03:44 though I fear I heard bitbake is python, so I'm out of ideas Jun 23 16:05:11 I ran "make image" and the relevant part of the log seems to be the bit I pasted. Jun 23 16:09:25 I can also paste a little bit more of the log if it helps. Jun 23 16:11:17 DeGT, there is a advanced log in /home/arne/freerunner/shr/selbermachen/shr-unstable/tmp/work/i686-linux/libtool-native-1.5.10-r10/temp(log.* Jun 23 16:11:31 s/(/\// Jun 23 16:14:00 playya: forget apt. doesn't know about proper escaping Jun 23 16:14:16 ok Jun 23 16:14:34 lemme test: Jun 23 16:14:46 hmm, there is no directory called temp atm. I'll retry and see if it pops up. Jun 23 16:14:54 s|mm|xx| Jun 23 16:15:04 though no luck as well Jun 23 16:25:34 There is still no folder called temp... Jun 23 16:26:03 only libtool-1.5.10 Jun 23 16:27:43 hmm, seems like unstable isn't exactly a daily-build Jun 23 16:28:19 mrmoku: isn't there a more recent image? Jun 23 16:28:55 freesmartphone.org: 03seba.dos1 07framework * rcbf3d7b9f925 10/framework/subsystems/opimd/ (pimb_sqlite_messages.py pimd_messages.py): opimd: Messages: implement Update method Jun 23 16:28:55 dos1: e.g. an image with the most current settings and opimd? Jun 23 16:29:09 I already had that problem a few months ago. Then I didn't have the time to investigate and now I'm trying again. Jun 23 16:29:20 DocScrutinizer: well, just commited, so there is no even package with most current opimd ;) Jun 23 16:29:57 unstable is like a week old :-/ Jun 23 16:30:48 DocScrutinizer, buildhost has some problems Jun 23 16:30:51 DNS does not work Jun 23 16:30:59 ouch Jun 23 16:31:19 as soon as its working again I will build one - promissed :) Jun 23 16:31:37 mrmoku: :-) Jun 23 16:35:23 freesmartphone.org: 03seba.dos1 07framework * r5a2d3945e63d 10/framework/subsystems/opimd/pimb_sqlite_messages.py: opimd: SQLite-Messages: change read and sent to MessageRead and MessageSent, and add Processing field Jun 23 16:38:14 Okay, maybe I should just start from scratch. Jun 23 16:38:24 freesmartphone.org: 03seba.dos1 07framework * r8dfb95a79b09 10/framework/subsystems/opimd/docs/ (api_overview.txt contact_fields.txt message_fields.txt): opimd: update docs Jun 23 16:41:13 mrmoku: is upgrade supposed to work? Jun 23 16:41:40 (with swap etc...) Jun 23 16:43:13 freesmartphone.org: 03seba.dos1 07specs * r972f5d410305 10/org.freesmartphone.PIM/org.freesmartphone.PIM.Message.xml.in: org.freesmartphone.PIM.Message: add Update and Delete methods Jun 23 16:43:14 freesmartphone.org: 03seba.dos1 07specs * r17f8082e4da7 10/org.freesmartphone.PIM/org.freesmartphone.PIM.Messages.xml.in: org.freesmartphone.PIM.Messages: add IncomingMessage signal and change description of NewMessage signal Jun 23 16:51:25 DocScrutinizer, from when? Jun 23 16:51:42 last unstable image Jun 23 16:54:08 DocScrutinizer, with my upgrade script that upgrades one package after the other... Jun 23 16:56:50 ok then. Can't wait any longer to test new settings Jun 23 16:57:53 DocScrutinizer, will ping you when buildhost is up again Jun 23 17:04:12 is there some way to override /etc/resolv.conf as normal (non root) user? Jun 23 17:05:42 mrmoku: sudo? Jun 23 17:06:27 or chmod a+w Jun 23 17:06:51 no Jun 23 17:07:42 DocScrutinizer: on my repo are latest frameworkd, shr-settings and opimd-utils Jun 23 17:08:00 DocScrutinizer: do you want link? Jun 23 17:10:12 mrmoku: ldpreload a local patched resolver lib? Jun 23 17:10:22 hehe... overkill Jun 23 17:10:45 guess it will be fixed before I would be able to set up something like that Jun 23 17:11:58 Is it normal that a lot of patches do not apply? Jun 23 17:12:08 DeGT, testing? Jun 23 17:12:43 seems so. Jun 23 17:13:04 don't build it :P and don't care Jun 23 17:13:05 running make setup gives me a lot of errors. Jun 23 17:13:19 yeah... you can ignore them Jun 23 17:13:49 how can I be sure that it is testing? Jun 23 17:13:51 DeGT: you can ignore -testing Jun 23 17:14:01 DeGT: -unstable doesn't have patches :D Jun 23 17:14:51 ok. Jun 23 17:14:55 DeGT, you can even rm -rf shr-testing Jun 23 17:16:03 Can I use distcc or something similar? Jun 23 17:16:42 would someone help with opimd? :P Jun 23 17:17:02 it would be nice to have ability to sort query results on opimd side :P Jun 23 17:18:23 dos1: I guess they *are* sorted. Maybe select another sort key ;-) Jun 23 17:20:05 DocScrutinizer: they are sorted, true (best matched on top) Jun 23 17:20:25 DocScrutinizer: but when you request all messages, they comes as they was registered Jun 23 17:20:45 DocScrutinizer: so messages with ID 0, 1, 2, 3, 4, ..., n Jun 23 17:20:50 so probably sorted by primary key then Jun 23 17:20:58 yup ;-D Jun 23 17:21:48 DocScrutinizer: well. there is no sorting. just something like "for message in messages:", where messages is tuple :P Jun 23 17:22:07 or array. dunno what exactly python's "tuple" mean :D Jun 23 17:22:22 so you get implicit sort order, which is primary key Jun 23 17:22:42 DocScrutinizer: yep Jun 23 17:22:54 DocScrutinizer: but sorting needs to be implemented on opimd side Jun 23 17:23:29 which db do you use? sqlite? Jun 23 17:23:41 create a view sort by ? (sorry long ago since I last used SQL) Jun 23 17:23:45 DocScrutinizer: if some client app requests 10 results for query {} (so - all messages), then it'll get 10 first messages Jun 23 17:24:03 playya: SQLite is used as backend Jun 23 17:24:11 playya: but i'm talking about python code, not database Jun 23 17:24:40 yes Jun 23 17:24:46 pure opimd doesn't use SQL... and i think that's bad :P Jun 23 17:24:55 let me check sqlite feature list Jun 23 17:25:05 playya: it won't give me anything useful Jun 23 17:25:16 playya: i know how to sort with SQL ;) Jun 23 17:25:31 because you have to merge different results? Jun 23 17:25:47 playya: no. because it isn't SQL Jun 23 17:25:54 ouch, that will get nasty Jun 23 17:26:27 opimd reads all contacts/messages from all backends at startup... Jun 23 17:26:41 dos1, i mean you have to merge results of differen backends Jun 23 17:27:05 eeek, so it *is* as nasty as it possibly get already. Where's the problem to sort the python list then? Jun 23 17:27:30 DocScrutinizer: there is no problem :D Jun 23 17:27:40 DocScrutinizer: i only said that it needs to be implemented Jun 23 17:27:42 ;) Jun 23 17:28:00 but that design needs to be changed Jun 23 17:28:12 now loading 170 messages takes ~70 seconds Jun 23 17:28:15 ... Jun 23 17:29:05 I bet Jun 23 17:29:40 I also bet loading 300 contacts will take even linger Jun 23 17:30:18 that's why I always said a cache in opimd is a bad thing Jun 23 17:30:43 DocScrutinizer: yep. i agree Jun 23 17:31:12 but changing that is harder to implement than Update and Delete methods ;) Jun 23 17:31:27 i wish after ms5.5 release there will be more work at opimd Jun 23 17:34:01 things are looking good for a ms5.5 release RSN (tm) Jun 23 17:35:27 also, i might be able to finish fsodeviced during LinuxTag Jun 23 17:35:35 can't wait for the speed boost ,) Jun 23 17:38:30 sounds great! thx alot :) Jun 23 17:39:24 i can't stand the latency when accepting a call ;) Jun 23 17:46:26 max_posedon: i'm trying to build abyss now :) Jun 23 18:10:59 can it be that oe is relying on the assumption that the standard shell is sh compatible? Jun 23 18:11:39 I was trying to compile everything from scratch and gcc fails. Jun 23 18:12:06 IIRC somebody had problems like that... yeah Jun 23 18:12:22 changing shell helped in that case Jun 23 18:14:17 changing the shell alone doesn't help. I anticipated that kind of problems and used bash. But my login shell was still fish., Jun 23 18:14:40 Deubeuliou: i've managed SQLite messages backend to work ;) Jun 23 18:32:57 mickey|bbiab: could you please rename "FSO FW Mark II" to something bit more descriptive? Jun 23 18:41:46 DeGT, sh should link to bash Jun 23 18:51:13 roh, afair you are one of the server admins Jun 23 18:51:57 is it possible to trigger a rebuild of libfso-glib on every pull on the specs? Jun 23 18:52:03 lindi-: better now? Jun 23 18:55:00 freesmartphone.org: 03seba.dos1 07framework * r5836b034a0ad 10/framework/subsystems/opimd/ (pimb_sim_contacts_fso.py pimb_sim_messages_fso.py): opimd: install GSM signal handlers even if ogsmd isn't present when initing opimd Jun 23 18:57:43 dos1, buildhost is working again... more commits to come? Jun 23 18:57:53 mrmoku: yep, wait for one Jun 23 18:58:14 k Jun 23 18:58:42 naaah, wait??? Jun 23 19:00:05 np :-) dos1, take your time. Me off for TV Jun 23 19:00:36 DocScrutinizer: it's ready, testing now and commiting soon :P Jun 23 19:01:09 freesmartphone.org: 03mickey 07cornucopia * r7b86ed451d49 10/libfsoframework/ (6 files in 2 dirs): fsoframework: more work on SoundSystem class (using alsa backend) Jun 23 19:01:11 freesmartphone.org: 03mickey 07cornucopia * r0437e385a4d2 10/misc-vapi/vapi/libasound.vapi: misc-vapi: libasound.vapi: add aes ice 958 Jun 23 19:01:11 freesmartphone.org: 03mickey 07cornucopia * r932a54ae4152 10/libfsoframework/ (3 files in 2 dirs): fsoframework: save/restore groups of mixer controls Jun 23 19:01:14 freesmartphone.org: 03mickey 07cornucopia * r012a876ec8b9 10/libfsoframework/fsoframework/alsa.vala: Jun 23 19:01:14 freesmartphone.org: fsoframework: alsa: refactor Jun 23 19:01:16 freesmartphone.org: We keep the list of controls now in the alsa object, Jun 23 19:01:18 freesmartphone.org: based on the assumption that it doesn't change over the lifetime Jun 23 19:01:20 freesmartphone.org: 03mickey 07cornucopia * r79b99e28e553 10/libfsoframework/fsoframework/ (alsa.vala fsoframework-2.0.vapi): fsoframework: alsa: add method to create a MixerControl from a string description Jun 23 19:01:37 dos1: test as long as you like, if only build id finished in 70min ;-P Jun 23 19:03:02 playya: sh links to dash, but that's not the point. the gcc build script just takes the my login shell to execute a shell script. Jun 23 19:03:18 and I'm using fish Jun 23 19:03:48 do you use parallell build? Jun 23 19:03:53 no Jun 23 19:04:31 chsh -s /bin/sh and ssh localhost make image works Jun 23 19:04:52 but I had to change my default shell and that shouldn't happen. Jun 23 19:09:40 a simple 'sh' doesn't do? then maybe your /bin/sh is a link to some non-compatible shell Jun 23 19:11:01 no, /bin/sh is a symlink to dash. That's the default in debian. Jun 23 19:11:15 freesmartphone.org: 03seba.dos1 07framework * r065ff1fb9b78 10/framework/subsystems/opimd/ (pimb_sim_contacts_fso.py pimb_sim_messages_fso.py): opimd: use better way for installing ReadyStatus signal handler Jun 23 19:11:51 mrmoku: i'll try to work now on not changing ID when deleting and handling message receipts, but dunno when i'll finish Jun 23 19:11:56 mrmoku: so i think you can build now ;) Jun 23 19:12:02 DeGT, afaik built-in sh in busybox does not compitable with bash as of for example user defined variables are not inherited Jun 23 19:12:08 dos1, ok Jun 23 19:13:17 mqy: I'm talking about cross-compiling on my laptop. No busybox. The build script used /usr/bin/fish instead of /bin/sh. That's an error. Jun 23 19:13:54 No script should assume that your login shell is sh compliant. Jun 23 19:14:51 DeGT, :) Jun 23 19:19:15 anyone using libfso-glib for a dbus client? Jun 23 19:19:29 3 hours ago, I finished building SHR unstable on my T43, it took almost 2 days Jun 23 19:20:15 mqy: first build always takes long ;) Jun 23 19:21:35 bumbl: sure, this is the second build, but a clean rebuild from scratch Jun 23 19:23:51 mrmoku: my test script has now one really *BIG* advantage when comparing to libframeworkd-phonegui-efl ;) Jun 23 19:24:28 mrmoku: it has error handling when sending SMS, and when error happens it allows to retry ;) Jun 23 19:24:31 dos1: where can i get it? :> Jun 23 19:24:56 agg1n1: in SHR feed after build finishes ;) Jun 23 19:25:15 agg1n1: that's test script for messages opimd interface Jun 23 19:36:38 dos1: any chance that some day all messages could be "load" to a list faster with opimd than with framework from sim today? :/ Jun 23 19:36:59 agg1n1: it already loads faster Jun 23 19:37:04 (for ~20 messages :P) Jun 23 19:38:49 dos1: ok nice :)) because waiting 10 seconds on starting shr-messages really sucks :p Jun 23 19:41:24 dos1: async loading possible? Jun 23 19:41:43 bumbl: how async? Jun 23 19:41:48 bumbl: with reply_handler? why not? Jun 23 19:42:58 opimd loads item from database, sends it out, loads next item Jun 23 19:43:09 so that list generation starts immediatly Jun 23 19:46:01 bumbl: possible Jun 23 19:46:44 because if the list grows over the time it is better for userexperience than to load ages Jun 23 19:47:22 bumbl: thanks for idea (in opimd it's implemented, but it isn't in my test gui ;)) Jun 23 19:48:01 mrmoku: sorry :x bugfix comes to frameworkd :x Jun 23 19:48:31 dos1, you're doomed to die ;) Jun 23 19:48:39 dos1: hehe Jun 23 19:50:04 freesmartphone.org: 03seba.dos1 07framework * r1c72f34ba722 10/framework/subsystems/opimd/pimb_sqlite_messages.py: opimd: SQLite-Messages: fix adding new messages to database Jun 23 19:52:47 mickeyl: ok, is it possible to use abyss with frameworkd written in python? Jun 23 19:54:32 and i start porting monitord to libfso-glib Jun 23 19:55:22 lindi-: it's possible (i'm using it) Jun 23 19:55:31 mrmoku: you'll be more angry :D Jun 23 19:56:00 mrmoku: i think i have fixed that issue with IDs Jun 23 19:56:10 dos1: how? there's a build dependency on cornucopia Jun 23 19:58:15 lindi-, really?! Jun 23 19:58:21 lindi-: build dependency, not runtime dependency Jun 23 19:58:26 because I'm sure it haven't Jun 23 19:58:45 because I built in on gentoo, where I haven't concucopia Jun 23 20:01:24 dos1, well go ahead Jun 23 20:02:21 did not restart the build yet Jun 23 20:02:29 mickeyl, what about adding a .vapi file to dbus-hlid? Jun 23 20:03:11 lindi-: yes, that's perfectly possible. you just have to tell frameworkd that you're using abyss Jun 23 20:03:16 [ogsmd] Jun 23 20:03:20 ti_calypso_muxer = fso-abyss Jun 23 20:03:22 that's all Jun 23 20:03:25 playya: which one? Jun 23 20:03:47 to provide the dbus interface Jun 23 20:04:23 brrr. don't eat ice cream to fast Jun 23 20:04:32 hmm, yeah, we could think about that Jun 23 20:04:54 (dependency) fso-abyss needs libfsotransport, which is a part of cornucopia project, yes. Jun 23 20:04:58 max_posedon: fso-abyss -> gsm0710mux -> libgsm0710mux -> fsotransport Jun 23 20:05:07 right, as lindi says Jun 23 20:05:31 mickeyl: and fsotransport is part of cornucopia Jun 23 20:05:37 thats only ~10 lines of code but useful for others Jun 23 20:05:44 playya: agreed Jun 23 20:05:47 max_posedon: maybe you built older version? Jun 23 20:06:03 mickeyl: but how do I build abyss without cornupia? Jun 23 20:06:05 may be, 0.3.4 Jun 23 20:06:08 cornucopia Jun 23 20:06:17 lindi-: well, cornucopia is just the code name of all that Jun 23 20:06:23 it's not a seperate library nor framework Jun 23 20:06:28 (libgsm0710mux-0.3.4) Jun 23 20:06:29 libfsotransport is standalone Jun 23 20:06:38 how do i enable swap in SHR, opkg fails Jun 23 20:06:45 mickeyl: ah the git repo just has several libraries? Jun 23 20:06:48 correct Jun 23 20:07:10 mickeyl: is the old gsm0710muxd code still in there somewhere or was it rewritten? Jun 23 20:07:27 lindi-: no gsm0710muxd code in abyss nor libgsm0710muxd nor libgsm0710 Jun 23 20:07:34 everything was created from scratch Jun 23 20:07:40 using some parts of qt/embedded btw. Jun 23 20:07:48 (libgsm0710) Jun 23 20:07:54 fredrin, create some bug file, mkswap/swapon Jun 23 20:08:03 mickeyl: ok, then it maybe shouldn't install /sbin/gsm0710muxd? Jun 23 20:08:09 of course not Jun 23 20:08:12 and it doesn't Jun 23 20:08:17 it installs fso-abyss Jun 23 20:08:21 and nothing else Jun 23 20:08:51 gsm0710muxd is still in our repository, but it bears no relation to the new fso-abyss stuff Jun 23 20:09:07 just there for reference, since something may point to the SRC_URI Jun 23 20:09:43 mickeyl: ah, I was confused by the naming Jun 23 20:10:07 the full story is: libgsm0710 = protocol engine, libgsm0710mux = muxer engine based on libgsm0710, fso-abyss = dbus/pty muxer using libgsm0710mux and libfsotransport Jun 23 20:10:26 need to wake up tomorrow by 05:00, so I'm going to bed Jun 23 20:10:27 g'night Jun 23 20:10:37 freesmartphone.org: 03seba.dos1 07framework * r582aa3e1646b 10/framework/subsystems/opimd/ (pimd_contacts.py pimd_messages.py): opimd: don't change paths when deleting contact/message Jun 23 20:10:49 mickey|zzZZzz: btw, ./configure --help in abyss says that sysconfdir would default to PREFIX/etc but it doesn't Jun 23 20:11:04 mickey|zzZZzz: I need to pass --sysconfdir=/home/lindi/install/etc explicitely or it tries to write to /etc Jun 23 20:11:13 ok, we should fix that Jun 23 20:11:21 will try to rmemeber, thanks Jun 23 20:11:24 l8er Jun 23 20:22:00 hmm Jun 23 20:22:09 ophonekitd crashed with: Jun 23 20:22:11 Jun 23 16:18:57 nibbly-bits user.warn kernel: [67508.045000] Alignment trap: ophonekitd (1539) PC=0x40be81e0 Instr=0xe594c010 Address=0x6f742039 FSR 0x003 Jun 23 20:22:41 15 minutes into my phone call when an incoming text message popped up Jun 23 20:23:14 iirc, that happened last time too Jun 23 20:26:00 Blu3: alignment trap itself is almost harmless on arm, it's just a notice that some data stucture is improperly designed and that access on most architectures will be slower. Jun 23 20:26:16 dos1|neo: hey, do you know about alignment rules? Jun 23 20:26:55 aye, it just seemed coincidental. the crash occurred as the text message arrived Jun 23 20:27:08 PaulFertser: alignment rules? Jun 23 20:27:59 PaulFertser: talking about that alignment trap? then no :x Jun 23 20:28:19 dos1|neo: ok, it's easy, let me explain. Jun 23 20:29:42 dos1|neo: when you access any data in RAM you're supposed to access everything aligned to the size of the variable you access. That means you can access a single byte on any address, a word on even addresses, a dword only on addresses that are divideable by 4. Jun 23 20:30:11 dos1|neo: so any data stucture you design should be conformant to that rules. Jun 23 20:30:51 PaulFertser: ok, understand Jun 23 20:31:14 dos1|neo: i think gcc adds padding by default to data structs but i suspect something like "(int*)&buffer[5] = 0xfefe;" was done in ophonekitd that lead to that alignment trap. Jun 23 20:31:27 PaulFertser: what happens when that rules are broken? Jun 23 20:31:45 Jun 23 16:18:57 nibbly-bits user.warn kernel: [67508.045000] Alignment trap: ophonekitd (1539) PC=0x40be81e0 Instr=0xe594c010 Address=0x6f742039 FSR 0x003 Jun 23 20:32:23 dos1|neo: on ARM the kernel does the right thing for you but the access will be slower. On x86 just a little invisible slowdown. On some architectures (Alpha?) it might not work at all. Jun 23 20:32:39 PaulFertser: highly possible. ophonekitd code isn't so pretty :x Jun 23 20:32:43 dos1|neo: or probably Itanium, i don't remember exactly. Jun 23 20:33:42 dos1|neo: so, regular "structs" are padded by gcc itself to meet those rules (unless you use special pragmas/attributes). But the example i gave you i think will lead to that alignment trap. That should be avoided. Jun 23 20:36:11 dos1|neo: (my example lacks dereference operation * so won't compile. But i think you got the idea) Jun 23 20:36:54 yep Jun 23 20:37:44 max_posedon: k, how do i make the file that i'm going to use as swap? Jun 23 20:38:25 fredrin, cat /dev/zero > file; ctrl+c after few seconds; Jun 23 20:38:37 :) Jun 23 20:38:48 fredrin: and check size Jun 23 20:38:54 Linux is more forgiving on alignment too... Jun 23 20:39:10 dos1|neo: who is going to audit ophonekitd code? ;) Jun 23 20:39:20 bricode: more forgiving comparing to what? Jun 23 20:39:26 aren't there some better way to just make a file of like 128MB? Jun 23 20:39:32 It allows byte addressing for structs, whereas Solaris for example requires word alignment ("see Bus error") Jun 23 20:39:33 fredrin: dd Jun 23 20:39:44 PaulFertser: Solaris. Jun 23 20:39:50 PaulFertser: noone, it's going to be replaced by vala rewrite soon ]:-> Jun 23 20:39:52 bricode: on ARM? Jun 23 20:40:28 PaulFertser: Sorry, more on an OS level instead of architecture level. Jun 23 20:40:54 PaulFertser: From my understanding there was never a Solaris port to ARM. Jun 23 20:40:57 bricode: sorry i can't understand how os can influence accessing struct members. Jun 23 20:41:19 bricode: btw, why don't we hear much about android on gta02 lately? Jun 23 20:41:31 bricode: are you guys hiding from the rest of community? ;) Jun 23 20:42:18 PaulFertser: OS can influence how structs are accessed, especially bit-fields. Jun 23 20:42:39 PaulFertser: We're busily getting the latest Android (Android 1.5) code integrated from Google. Jun 23 20:42:45 bricode: if there's no exception, how can OS affect that? Jun 23 20:42:46 PaulFertser: Hiding, no. Jun 23 20:44:04 bricode: do you do any kernel work? I haven't seen anything about wakelocks since they were disabled, e.g. Jun 23 20:44:36 PaulFertser: Here's an example: int a; char *b; b = (char *) a[1]; From my recollection, such an action would fail under Solaris, but skip along merrily under Linux. Jun 23 20:44:46 bricode: on what arch? Jun 23 20:45:20 PaulFertser: Marcelo has been doing the kernel work lately. Mostly integration with andy-tracking branch, and making sure the upper levels of Android work with it. Jun 23 20:45:38 PaulFertser: x86 for certain. Seem to remember it being an issue on alpha too. Jun 23 20:46:35 bricode: do you know that the intention was to use the kernel from OM for android too? So we all have a common kernel to debug. I mean, you seem to have forked it :-/ Jun 23 20:47:03 PaulFertser: Yes, I was around for that discussion and was a part of it. Jun 23 20:47:10 bricode: i'm afraid i can't understand your example, i'm not sure [] is applicable to an int. Jun 23 20:47:25 bricode: (common kernel) and? Jun 23 20:47:36 PaulFertser: That should have been a cast to a char. Jun 23 20:48:37 dd if=/dev/zero of=myharddisk.img bs=1000 count=0 seek=$[1000*128] <-- found this oneliner but it wont work Jun 23 20:48:42 PaulFertser: There seemed to be some breakage in the OM branches, so we've basically taken snapshots of the OM kernel. Jun 23 20:48:52 bricode: also i've heard that koolu uses their own version of Qi that affects NAND partitioning. Unfortunately, users are unaware of it, they think that Qi is Qi and works with any OS. Can you take care of doing something so users will know about that pitfall? Jun 23 20:50:26 bricode: Hm, i haven't seen reports about breakages on the andy-tracking branch. Can you be more specific please? I mean, i hope that you and other android devs can collaborate properly with OM community (despite working on android which i'm very allergic to). Can you please clarify your position about that? Jun 23 20:50:57 PaulFertser: There was a regression in the wifi stuff which Marcelo seems to have sorted out. Jun 23 20:51:28 PaulFertser: In addition, Michael Trimarchi has commit access to the OM git, and is an active Android developer. Jun 23 20:51:31 bricode: and please, even if i sound harsh or say other inappropriate things, partially that's because i'm not native speaker, partially because i'm insane. Anyway, no personal offence meant ever. Jun 23 20:51:46 PaulFertser: No worries. Jun 23 20:52:26 bricode: do i understand you right that Marcelo is going to post a good patch soon? Jun 23 20:53:30 bricode: and what about having a common kernel? Jun 23 20:55:16 PaulFertser: This is the kernel we're using: http://git.koolu.org/?p=kernel/openmoko.git;a=shortlog;h=refs/heads/andy-tracking Jun 23 20:55:29 That looks pretty common to me. Jun 23 20:55:44 bricode: it still doesn't quite answer my question, i'm afraid. Jun 23 20:56:00 PaulFertser: The common kernel one? Jun 23 20:56:11 bricode: yes Jun 23 20:56:16 bricode: also the wlan patch Jun 23 20:56:45 PaulFertser: I'm not sure there's a wlan patch, just that Marcelo had to merge with a particular commit level of andy-tracking Jun 23 20:57:18 PaulFertser: As for the common kernel, we are essentially using andy-tracking, just with different commit levels. Jun 23 20:57:46 PaulFertser: We need to have staged merges so that we can ensure that there aren't any regressions with the upper layers of Android. Jun 23 20:57:54 bricode: to my uneducated understanding that's not the right way to solve kernel problems is it? If you were using "our" andy-tracking, you'd contribute directly to the OM project. So everybody benefits. Jun 23 20:59:03 PaulFertser: In principal, I agree. There isn't a whole lot of kernel work done from the Android point of view (ie: active development). More like pull from OM, test to see if it works, modify upper Android levels as necessary. Jun 23 20:59:37 bricode: why don't you use our repo directly? Jun 23 20:59:50 PaulFertser: Marcelo and I have talked that if anything needs to be changed in the kernel, that it would be pushed back to OM (that wasn't specifically needed for configuration). Jun 23 21:00:05 dd if=/dev/zero of=swp.file bs=1k count=128000 <-- this worked Jun 23 21:00:31 bricode: can you please explain this: http://git.koolu.org/?p=kernel/openmoko.git;a=commit;h=630205a92fa2fe40749a08d152c3c81cad81cdbe ? Jun 23 21:01:37 PaulFertser: A minor deviation from the OM tree so that Android can work. Jun 23 21:01:50 bricode: Have you seen the commit diff? Jun 23 21:02:14 bricode: i'm sorry but how can it make sense? Jun 23 21:03:04 PaulFertser: That's a good question. Jun 23 21:03:10 just defining loglevel makes android working? :o Jun 23 21:03:34 s/loglevel/debug level/ Jun 23 21:03:49 dos1|neo: what worries me is obviously the fact that instead of fixing something in android boot process or the kernel they added a debug kludge again. :-/ Jun 23 21:04:02 dos1|neo, intone does not build :( Jun 23 21:04:28 mrmoku: why? is there newer version? Jun 23 21:05:02 I've taken hours to build intone Jun 23 21:05:29 it's slow to access code.google.com from here Jun 23 21:05:40 PaulFertser: The funny part is that wasn't even used in the last Beta release from us. Jun 23 21:06:28 dos1|neo, looks like Jun 23 21:07:09 yep new version Jun 23 21:07:15 PaulFertser: Err, I meant to type it looks like it was... Jun 23 21:07:18 well... not version... svn commit Jun 23 21:07:50 svn: OPTIONS of 'http://intone.googlecode.com/svn/trunk': could not connect to server (http://intone.googlecode.com) Jun 23 21:08:13 mqy, hmm... don't have that problem Jun 23 21:08:20 looks like it is missing some lib Jun 23 21:08:39 Is there any distro that understands MMS ? Jun 23 21:08:44 bricode: you remember how Andy did integrate all that kernel stuff that (for some obscure reason) Android needs to work. That's exactly to have you (android devs) participate actively in community work. Now you seem to fork the kernel instead of really helping us (i mean community) :-/ Can't you understand what i'm talking about? You might fix a bug and then due to 'deadline' or something you'll fail to notify upstream (openmoko-kernel). If y Jun 23 21:08:50 ... pulled directly from our repo, things like that just wouldn't happen. Did i expressed my thoughts clearly enough? Jun 23 21:09:04 mrmoku, strange that I'm just building omgps... Jun 23 21:09:10 (obviously not grammatically correct enough but i hope you'll excuse a foreigner) Jun 23 21:09:28 PaulFertser: You make your point clear. Jun 23 21:09:46 viq: somobody (Blu3?) is working on a custom SMS app with support for that questionable feature. Jun 23 21:10:23 mqy, uhhh... I'm interested in that recipe :) Jun 23 21:10:23 sorry, on the fone. yes, i'm writing an sms app and i have partial mms support in it Jun 23 21:10:29 PaulFertser: thanks. For SHR, or something else? Jun 23 21:10:38 viq: any FSO-based distro Jun 23 21:10:39 PaulFertser: As I said, we effectively operate on the same tree (very small differences). Any major patches are pushed to the OM community (is there even anyone full time at OM working on the kernel?). In addition, to satisfy the requirements of the GPL, we must host any code that we distribute. Jun 23 21:10:45 thanks Jun 23 21:10:52 it's not shr-specific, it uses fso's dbus api Jun 23 21:11:45 bricode: devil is in the details, you know... (no, there is nobody who is payed for gta02 programming work left at OM) Jun 23 21:12:01 mrmoku: it almost passed build, but build process is blocked by intone now Jun 23 21:12:30 bricode: i see frequent merges from our tree, yes. But i also seem to see ugly kludges (take that with a grain of salt). Jun 23 21:12:37 PaulFertser: So, that's the other thing. If Koolu has commercial obligations, there is difficulty in not maintaining our own kernel tree for a number of reasons. Jun 23 21:12:42 *sigh* one thing I like hackable1 for is the main screen, where you have large clock, with status from messages app, the calendar and todo displayed. If only it worked better... Jun 23 21:13:39 bricode: why haven't you written anything about Qi "fork" to the kernel ML? It'd help us a lot in troubleshooting users' problems that decided to switch back to regular distros. Jun 23 21:14:11 bricode: one of the examples that you seem to have failed to communicate with the community in a decent way, i'm sorry to say that but it seems to be true. Jun 23 21:15:33 mrmoku, whom to contact to add new recipe? Jun 23 21:15:47 mqy: mrmoku ;D Jun 23 21:16:37 mqy, yeah, me :) Jun 23 21:17:24 PaulFertser: One might ask if the kernel mailing list is the proper place for Qi info. Jun 23 21:17:35 PaulFertser: Secondly, all of the code and changes are available in our git. Jun 23 21:17:54 bricode: i don't say you infringe the license. Jun 23 21:18:07 bricode: and yes, Qi was always discussed at the kernel ML. Jun 23 21:18:34 bricode: problem is not licensees, problem is inter-developer communication. And forks! Jun 23 21:19:49 PaulFertser: I would tend to argue that Android is a pretty large fork in the first place. We've tried to keep it as close to the standard OM stuff as possible, but have had to change things to either deal with the requirements of the Android OS, or the build system. Jun 23 21:19:55 bricode: i can see why one might want to fork e.g. qtopia because they never had a sensible patch accepting policy. But forking the kernel for minor tweaks is usually considered wrong, afaik. Jun 23 21:20:43 PaulFertser: Usually if you're talking strictly community based projects. When you get into commercial interests, things change a bit. Jun 23 21:20:52 ie: Redhat, Novel, Xen... Jun 23 21:21:01 bricode: and OM community had and still has a very sensible patch acceptance policy. Andy integrated all that stuff even (despite many devs including Alan Cox consider it to be shit). And you still fork the kernel. Jun 23 21:21:46 OM's kernel is in shambles anyway. It's quite far off from the actual kernel mainline. Jun 23 21:22:01 bricode: i'm talking technical. You said "commercial" twice already. Jun 23 21:22:03 You know how hard it is to integrate something from another 2.6.29 tree for example? Jun 23 21:22:32 bricode: not that far. Nelson sent basic support upstream and we hope it will come back after the next merge window. Jun 23 21:22:37 PaulFertser: Unfortunately I'm in a position where I don't have the luxury of thinking about things on a purely technical level. Jun 23 21:22:48 bricode: why don't you want to help us rebase it to 2.6.30 then? Jun 23 21:23:03 PaulFertser: We're cut short on manpower as it is. Jun 23 21:23:54 bricode: OM has _zero_ payed developers now. So you're supposed to help us (i mean real kernel devs here, not me), as you still has some manpower. Jun 23 21:24:28 PaulFertser: That's an interesting interpretation. Jun 23 21:25:43 i think supposed is wrong word Jun 23 21:25:52 bricode: as for now it seems that you just prove that android is about "opensource" and not "free software". That OM community shouldn't care a bit about android just for that reason. Opensource is different. Just parallel universe. Why should we care, why did Andy integrated that questionable kernel stuff? Jun 23 21:26:03 maybe "that's in good taste" :P Jun 23 21:26:17 dos1|neo: no, i mean exactly suppose. I suppose that good developers will help those in need. Jun 23 21:26:30 dos1|neo: looks like i'm too naive :-/ Jun 23 21:26:48 dos1|neo: fuck my life Jun 23 21:27:19 PaulFertser: supposing anything from other people is naive i think ;x Jun 23 21:27:54 dos1|neo: i still assume people to be "good" by default, you know Jun 23 21:28:34 PaulFertser: good for you ;) Jun 23 21:29:11 i assume the same, but unfortunately sometimes that assumption is wrong... Jun 23 21:29:13 dos1|neo: i'd not be very sure that's really good. Sometimes real life comes and proves me wrong :( Jun 23 21:32:27 PaulFertser: Last time I checked, the Freerunner was an Open phone. Not a free phone. Jun 23 21:32:59 dos1|neo: btw, you remember that time when all that Android talks started? I suspected that OM community won't benefit from that. But nobody agreed. Seems like i was right all along. Now i'm "right" again but you see how it goes? Nobody supports me in this "discussion". Jun 23 21:33:19 PaulFertser: The only thing that's left with this phone is the community. Jun 23 21:33:31 PaulFertser: What if OM decides to stop manufacturing the phone? Jun 23 21:33:37 What will become of the community then? Jun 23 21:34:03 Android was added to the mix to give people another choice and potentially boost the volumes of the phones so that it could continue to exist. Jun 23 21:34:30 bricode: no, the official slogan is "Free Your Phone." Jun 23 21:34:43 bricode: stopping manufacturing won't make my phone disappear, so i'll still work on it Jun 23 21:34:43 PaulFertser: Yeah, a marketing slogan. Jun 23 21:35:10 DocScrutinizer: ping Jun 23 21:35:26 dos1|neo: Yes, that's true, but how is that helping the larger Free Software community? If there is no hardware for them to use, it's of little use. Jun 23 21:36:03 bricode: FSO and SHR don't target only om phones Jun 23 21:36:06 bricode: there's like 10000-15000 units (including gta01) all over the world that can be used as a good development platform. Jun 23 21:36:17 DocMobilizer: ping? Jun 23 21:36:46 bricode: FSO and SHR are still in active development. And those thousands of units will help them to go forward no matter what happens to OM inc. Jun 23 21:37:04 PaulFertser, nobody want support you because this discussion is little bit useless Jun 23 21:37:10 dos1|neo: By your logic, neither does Android. Jun 23 21:37:16 bricode: and what did Android give to the free software community? Android market? Jun 23 21:37:17 bricode: my code is high level, so i can even develop for PC on my neo, or develop phone apps which are working on neo AND other phones Jun 23 21:37:17 android *already* beacome not interested for developers Jun 23 21:37:19 Toaster`: pong Jun 23 21:37:20 max_posedon: life is useless Jun 23 21:37:41 only enterprise/marketing continue think about it Jun 23 21:37:44 max_posedon: if we really shared a common kernel, android devs could help us. Jun 23 21:37:45 DocScrutinizer: all my parts for buzz-fix, bass-boost, and #1024 fix cam in today Jun 23 21:38:02 PaulFertser, you aren't right, not android devs Jun 23 21:38:21 android devs focused ONLY on this java wramework Jun 23 21:38:25 DocScrutinizer: They are bloody small parts! I'm glad I'm not doing the soldering :) Jun 23 21:38:27 *framework Jun 23 21:38:45 max_posedon: i hoped they're responsible enough. And by android devs i mean those guys who work on getting android run on gta02. Jun 23 21:38:54 yes, some koolu's developers might be can help Jun 23 21:39:12 max_posedon: also Michael Trimachi is a really nice guy. Jun 23 21:39:22 but android itself as platfrom is so... Jun 23 21:39:46 ... not interesting Jun 23 21:39:52 got this error when i tried to upgrade shr-unstable: Jun 23 21:39:52 Collected errors: Jun 23 21:39:52 * Package python-multiprocessing wants to install file /usr/lib/python2.6/lib-dynload/_multiprocessing.so Jun 23 21:39:52 But that file is already provided by package * python-misc Jun 23 21:39:53 max_posedon: the plan was to share a kernel to unite efforts on getting it stable and cool. Jun 23 21:40:00 Android has different spirit, which most of us dislike Jun 23 21:40:19 open source != free software Jun 23 21:40:29 good plan, but... its only about kernel Jun 23 21:40:40 * bricode sits in the open source land. Jun 23 21:40:49 and most of active developers here = free software Jun 23 21:40:51 max_posedon: not that unimportant Jun 23 21:40:53 (i think) Jun 23 21:41:17 and freankly speaking, as I saw, android is just use linux kernel Jun 23 21:41:31 max_posedon: with ugly "inventions", yes Jun 23 21:41:31 DocScrutinizer: so hopefully I should have a fully re-worked A5 within a week or so. Jun 23 21:41:31 I even remember that they prefer some hacks Jun 23 21:41:39 sometimes i don't agree with RMS, but with Android spirit i don't agree more :P Jun 23 21:41:48 and nobody interested on this hacks Jun 23 21:41:54 Toaster`: fine Jun 23 21:42:18 mqy, you can set an explicit rev for intone to make it build Jun 23 21:42:24 max_posedon: that's what i said months ago. But nobody agreed. They all said we need to help android on gta02, we'll collaborate, we'll get more users etc. Jun 23 21:42:38 mqy, open shr-unstable/conf/distro/include/shr-autorev-unstable.inc Jun 23 21:42:48 mrmoku, ? Jun 23 21:42:58 mqy, and change ${AUTOREV} for intone to 11 Jun 23 21:43:10 PaulFertser, as for me I have 2 different apinions Jun 23 21:43:26 I guess cc did not commit all stuff needed to build with id3lib Jun 23 21:43:29 PaulFertser: well. it's nice to see android on gta02 Jun 23 21:43:41 if helping koolu with android could bring to market 10k neo's - it is reason to help them Jun 23 21:44:08 PaulFertser: it proves that gta02 is open and free platform Jun 23 21:44:20 mrmoku, that files does not exist Jun 23 21:44:32 PaulFertser: but we shouldn't rely on android Jun 23 21:44:39 ahh... forgot openembedded after shr-unstable :P Jun 23 21:44:52 that's what you get when you type paths out of memory ;) Jun 23 21:44:55 if only for fun... for make people be able switch from android and shr - nope Jun 23 21:45:27 bricode: sorry, i didn't intend to make a Two-Minute Hate for A. It's just that i'm very dissatisfied with how koolu developers and users behave. They don't even use community ML! I've heard that some web-forum exists (and every web-forum is stupid by definition). Not the kind of responsible attitude to the OM community i expected. :-/ Jun 23 21:45:32 DocScrutinizer, 70 min already passed? still watching tv? :P Jun 23 21:45:54 mrmoku, I know you mean shr-unstable/openembedded/conf/distro/... Jun 23 21:46:01 yep Jun 23 21:46:21 as for me, I tried port android to Gentoo Jun 23 21:46:37 dos1|neo: in fact, first A porting efforts proved that A is not open and free OS! Do you remember that heroic stuff on emulating armv5 on armv4? That was clearly a sign that A was not the right way to go. Jun 23 21:46:51 when I saw, that this guys asking me download 1.2G, I just stopped Jun 23 21:46:53 mrmoku: http://pastebin.com/m65f9b598 <-- you how i can fix, or is it not so important? Jun 23 21:47:06 max_posedon: of course if someone want to port even Windows Mobile to FreeRunner, then don't forbid. it's free platform. but we really don't have to help him with that ;p Jun 23 21:47:10 I don't want work on obfuscated softare Jun 23 21:47:12 mrmoku: actually I slept away Jun 23 21:47:14 dos1|neo: OM never needed to prove that the development platform is open. Jun 23 21:47:27 DocScrutinizer, good... still have to sleep a little :) Jun 23 21:47:47 mrmoku: I have to get me a coffe... ;-) Jun 23 21:48:03 mrmoku: build thru? Jun 23 21:48:06 dos1|neo, You know, any changes in windows mobiles is doesn't allowed Jun 23 21:48:19 its open source only for reading Jun 23 21:48:23 max_posedon: that was example Jun 23 21:48:33 DocScrutinizer, no... not yet Jun 23 21:48:35 so, if some person porting WM to neo, it just should hide from M$ Jun 23 21:48:47 s/it/he Jun 23 21:48:50 fredrin, you could try to opkg remove -force-depends python-misc Jun 23 21:48:56 no guarantee though.... Jun 23 21:49:34 mrmoku: worth a try Jun 23 21:49:42 fredrin: why not -force-overwrite? Jun 23 21:50:21 what about deleting *.py? just keeping the "compiled" versions? Jun 23 21:50:53 got it going now Jun 23 21:51:11 a reboot and hopefully my cell becomes sane again Jun 23 21:51:21 PaulFertser: We've already had this discussion about Forums vs. ML's and whatnot. Jun 23 21:51:39 PaulFertser: Also, some people on the OM lists don't make Android people feel particularly welcome... Jun 23 21:51:55 forums are more for younger people, could be nice to have both Jun 23 21:52:58 forums for users/housewifes, maillists for developers/geeks Jun 23 21:53:00 bricode: when people are exchanging closed-source binaries on kernel ML that's for sure not welcomed, you know. And no koolu dev did anything to stop that in a first place before i complained. Jun 23 21:53:05 sometimes forums really better) Jun 23 21:53:49 it's important for expanding the comunity Jun 23 21:54:34 PaulFertser: We have always put out source before binaries at Koolu. Jun 23 21:54:35 bricode: you can ask Michael Trimachi if he liked talking to me or not. I seem to remember to have tried to help him supplying information about AT commands for calypso and stuff. Jun 23 21:54:55 DocScrutinizer, going to bed now... if Ainulindale passes... bug him to sync the build when it finished successfully Jun 23 21:54:57 bricode: at that time it wasn't the case. RIL for communicating with GSM modem was closed. Jun 23 21:55:08 if not I will do that tomorrow morning Jun 23 21:55:19 gnight all Jun 23 21:55:20 PaulFertser: Granted that was the case, but it is now available. Jun 23 21:55:41 PaulFertser: We were forced to wait until Sean McNeil opened that portion of code. Jun 23 21:55:44 gnight mrmoku|away Jun 23 21:56:05 bricode: so you should not have released the binaries according to your policy. Jun 23 21:56:42 * fredrin woke up at 19:00 CET time today.... pretty fucked sleeping schedule Jun 23 21:57:08 PaulFertser: Yeah, that was a catch-22. Put *something* out there so that people could look at 98% of it, or wait until that part was opened. Jun 23 21:57:19 bricode: developers who care about community are always welcome, don't get me wrong. Jun 23 21:57:43 bricode: so? The right answer in the free software world would be to wait obviously. Jun 23 21:58:24 PaulFertser: Well, we have 2000+ subscribers on the forum, a separate mailing list, and public git repository. We've created a community, albeit an open source one. Jun 23 21:58:43 bricode: and you even hadn't shared with the fellow developer, Michael Trimachi who had to write his own RIL because of his own deadline. Jun 23 21:58:52 PaulFertser: Which is somewhat in conflict to "release early, release often". Jun 23 21:59:23 PaulFertser: We were unable to use Michael's RIL at the time due to licensing conflicts. Jun 23 21:59:53 bricode: but why did he write it? Because Sean McNeil (or whomever) didn't share. Jun 23 22:01:10 There was a working RIL but he had to write his own because of licencees or some other shit. Jun 23 22:01:33 fredrin: welcome to the club ;-) Jun 23 22:01:40 :) Jun 23 22:01:57 PaulFertser: Sean McNeil needed clearance from his employer (Windriver) to b able to release it under the Apache license. Jun 23 22:02:45 bricode: does it somehow prove that that story about RIL is not dirty? Quite the contrary, imho. Jun 23 22:08:19 bricode: i still hope that you're a good guy, just with wrong opinions ;) Have a nice day (it seems opensource-minded people are thick-skinned enough to not take ramblings of "religios fanatics" too seriously, so this little "discussion" won't have impact on you personally). Jun 23 22:09:55 PaulFertser: I find it entertaining really. It's my opinion that people interact and impact the community in different ways. I've chosen Android (although admittedly Debian would be my second choice) because where I think it's headed and the impact that it will have on a more global scale. Jun 23 22:10:23 PaulFertser: For me, pragmatism always trumps dogma. Jun 23 22:10:53 bricode: between ethics and pragmatism i obviously choose ethics. Jun 23 22:11:49 PaulFertser: A true martyr :) Jun 23 22:17:51 hmmm, no fresh image tonight it seems... *sigh* Jun 23 22:19:21 I fail to adequately retort this sarcastic comment. I'll resort to reading a good book instead. Good night everyone, i hope i'll be able to do some little good thing for the free software tomorrow. Jun 23 22:20:10 PaulFertser: :-) Jun 23 22:56:16 PaulFertser: I remember when I had a DSL-modem (no router) I had to DISable LCP for PPP otherwise the line broke down when my PC went to suspend (yes I used to do those strange things ;-) Jun 23 23:57:57 freesmartphone.org: 03seba.dos1 07framework * r4e46a14131c7 10/framework/subsystems/opimd/pimb_sim_messages_fso.py: opimd: SIM-Messages-FSO: disable SIM SMS buffering after installing signal handlers Jun 24 02:06:55 is intone building (shr-unstable image) for anyone? **** ENDING LOGGING AT Wed Jun 24 02:59:57 2009