**** BEGIN LOGGING AT Mon Dec 01 02:59:58 2008 Dec 01 05:05:01 DocScrutinizer, Good day. Dec 01 05:13:48 Sargun: hi Dec 01 09:42:44 freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * reb4ccedc5ed3 10/fsod/src/fsod.vala: Fix syntax error in fsod.vala Dec 01 09:42:45 freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * r8477f8dc4b48 10/fsod/configure.ac: Check for libnl during the configure process. Thanks Frederik Sdun Dec 01 09:56:03 good morning Dec 01 10:03:09 * raster hides Dec 01 10:03:29 raster, still awake? hehe Dec 01 10:03:43 * raster hides some more Dec 01 10:03:46 :) Dec 01 10:04:37 duck and cover ;-) Dec 01 10:04:50 gah Dec 01 10:04:53 50s Dec 01 10:04:56 how do i re-enable blocking on an fd... Dec 01 10:05:52 hmm Dec 01 10:05:56 i gtuess set flags to 0... Dec 01 10:06:24 hmm Dec 01 10:06:27 but i dont want that Dec 01 10:06:29 i want select Dec 01 10:08:25 Hello! Dec 01 10:08:32 quickdev: hello Dec 01 10:08:38 hey ptitjes Dec 01 10:08:48 sorry I did not gave news Dec 01 10:09:21 in fact I'm sound engineer and worked for 5 five consecutive days (and nights)... Dec 01 10:09:48 I had my first long night this morning :) Dec 01 10:10:41 hehe :) Dec 01 10:11:13 anyway the call event logging is quite done Dec 01 10:13:00 you were working on the sqlite call event logger? or am I wrong? Dec 01 10:13:42 yes Dec 01 10:15:08 I've only made database setup and logging yet Dec 01 10:15:44 sounds fine :) Dec 01 10:18:13 I'm still wondering what api I must provide for query Dec 01 10:18:18 also I've got question for you Dec 01 10:18:36 if you are available Dec 01 10:19:07 no problem, if I can answer you ;) Dec 01 10:19:36 aaaah Dec 01 10:19:44 i think i know why exquiositie slowed boot down so much Dec 01 10:19:56 a condition i'v never seen on a desktop... Dec 01 10:20:03 and some animation.. Dec 01 10:21:00 quickdev: who will show call history ? Dec 01 10:21:08 s/who/what/ Dec 01 10:21:30 om-dialer3 ? Dec 01 10:21:32 ptitjes, an independent app at first and maybe later some gadgets of illume Dec 01 10:21:42 why is that interesting? :) Dec 01 10:22:29 currently I've made two new files in ophonekitd (ophonekitd-phonelog.h|.c) Dec 01 10:22:57 phonelog_init_database() is called in main() Dec 01 10:23:19 phonelog_close_database() is called in exit_callback(...) Dec 01 10:23:54 and phonelog_log_call_event(...) is called in ophonekitd_call_status_handler(...) Dec 01 10:24:13 now I will make a function to query the call log Dec 01 10:24:54 but does this query function must have a dbus binding ? Dec 01 10:25:18 good question. Ainulindale, here? Dec 01 10:25:29 and the "om-call-history" app to query via dbus ? Dec 01 10:27:03 another possibility would be to implement the phonelog things in an additional library Dec 01 10:28:25 and add the two show|hide functions in ophonekitd-phonegui ? am I right ? Dec 01 10:28:56 this was the path I was taking... Dec 01 10:32:36 ptitjes, I don't know. You should ask Ainulindale as soon as he's here :) Dec 01 10:32:43 quickdev: also another question but that is sqlite-related... don't know if you have an opinion. Dec 01 10:32:47 someone slaps him Dec 01 10:33:06 i am tired.. i closed my account bank today Dec 01 10:33:13 ptitjes, never worked with sqlite yet :) Dec 01 10:33:31 should I open/close the database before/after every query or should I open at ophonekitd startup and close at exit as I do now ? Dec 01 10:34:23 are we sure the exit_callback() is called when ophonekitd ends ? Dec 01 10:35:01 else I would have a lock attribute that remains set on the /var/log/phonelog.db file... Dec 01 10:35:16 we cannot be 100% sure. You should save things frequently Dec 01 10:36:17 oh I think sqlite updates the file at every query but it only let the file accessible to other processes only when I close the db Dec 01 10:36:48 however who might want to use that file if there is a dbus api to query it Dec 01 10:36:49 ? Dec 01 10:37:21 yes, it depends on the api question Dec 01 10:38:18 another question... ?? :) Dec 01 10:38:37 how should I produce a .ipk file from my source ? Dec 01 10:38:44 the question you asked me before. Wether we want to use dbus for the interface Dec 01 10:38:54 I use bitbake devshell to make the project Dec 01 10:39:41 or should I simply replace the ophonekitd binary on my phone to test it ? Dec 01 10:39:53 how do you proceed ? Dec 01 10:40:29 bitbake ophonekitd (if your ophonekitd recipe is modified and uses local sources) Dec 01 10:40:57 I'm developing and testing on my x86, no need to package anything :) Dec 01 10:41:54 arf! could you elaborate how do this ? qemu thing ? Dec 01 10:42:49 not qemu, I'm running it natively Dec 01 10:42:55 frameworkd is running on my phone Dec 01 10:43:02 and dbus listens on a certain port Dec 01 10:43:14 then I can connect to frameworkd from my development box Dec 01 10:43:24 I had to patch dbus to make it work Dec 01 10:43:32 I should write a wiki text for it Dec 01 10:43:43 yeah you should ;) Dec 01 10:44:13 quickdev: here Dec 01 10:44:41 ptitjes: I had to revert your commit Dec 01 10:46:01 ouch Dec 01 10:46:15 ? Dec 01 10:46:28 because I did not add sqlite to the bb recipe ? Dec 01 10:46:39 Because nothing was working =) Dec 01 10:47:00 I commited no code yet ? Dec 01 10:47:08 there was nothing to work... Dec 01 10:47:11 Yes you did Dec 01 10:47:18 what code ? Dec 01 10:47:18 configure.ac and Makefile.am Dec 01 10:47:29 yeah config stuff but this did work! Dec 01 10:47:36 Not without the depends Dec 01 10:47:47 yeah in the bb recipe Dec 01 10:47:57 Well anyway I had no time to check when I reverted this Dec 01 10:48:01 should add RDEPENDS+=" sqlite" Dec 01 10:48:03 I just reverted it because I needed to produce an image Dec 01 10:48:19 s/sqlite/sqlite3/ Dec 01 10:48:36 so what shoud I do with git now ? Dec 01 10:48:56 well, no idea =) Dec 01 10:49:01 could you rerevert it ? Dec 01 10:49:07 No Dec 01 10:49:11 Well anyway the diff is here Dec 01 10:49:20 SO just update your local repo and apply the diff Dec 01 10:50:26 hi * ! :) Dec 01 10:53:01 sorry Ainulindale : I've reported as defect #173 but it's an enhancement Dec 01 11:05:06 Ainulindale: If you have time, I'm staying here for 6 other hours ;) Dec 01 11:05:22 hi dolf1074 :) Dec 01 11:05:29 hi Dec 01 11:05:31 hey dolf1074 Dec 01 11:05:40 hey Dec 01 11:05:46 quickdev :) Dec 01 11:06:04 o/ Dec 01 11:11:09 Little question: I've read about 'om-call-history' in this chat. Is that something temporary till opimd is ready? Or is the way to the future changed :p Dec 01 11:12:33 I use pyphonelog Dec 01 11:13:05 it's almost raw... but works ;) Dec 01 11:13:09 I also heard about that Dec 01 11:15:11 a21_work: and is it usable? Dec 01 11:15:46 yes, it do what it says ;) Dec 01 11:15:57 nice Dec 01 11:16:35 but no more :) Dec 01 11:17:37 dolf1074: I'm sorry - but IMHO call history has nothing to do with personnal information Dec 01 11:17:51 and now a little question from me: how I could play midi on FR? Dec 01 11:18:08 a21_work: just like on your PC Dec 01 11:18:27 ow so opimd doesn't do call history (That would explain a lot :) ) Dec 01 11:18:39 a21_work: (hint: use timidity) Dec 01 11:19:01 dolf1074: personnal information management is long-term data management Dec 01 11:19:05 mh... ok, also on my pc I'm not able to play them :) you got me :P Dec 01 11:19:21 whereas call history is a short-term logging thing Dec 01 11:19:46 but maybe I don't understand the whole opimd story... Dec 01 11:20:42 shouldn't everything be in the long-term data management? Dec 01 11:20:51 or is there a disadvantagement? Dec 01 11:23:08 arf dunno... Dec 01 11:24:28 then we are with 2 who don't know Dec 01 11:25:05 I think call history is not as sensitive as contact for instance Dec 01 11:26:30 maybe, or maybe opimd only save the call history of contacts Dec 01 11:26:48 that would not be very coherent Dec 01 11:26:59 I know, but I'm just guessing Dec 01 11:33:08 ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory Dec 01 11:33:22 maybe we have not any seq module? Dec 01 11:33:33 a21_work: i don't think there is hardware seq support, just use timdity Dec 01 11:34:20 mh... sure? under qtopia I can play midis but I doubt there is timidity installed... Dec 01 11:34:30 a21_work: strace how it does it Dec 01 11:34:50 mh ok, ....let's try! :) Dec 01 11:34:54 rebooting moko Dec 01 11:35:01 quickdevarf I've got a segfault in ophonkitd after "DEBUG: list_ressources()" Dec 01 11:36:07 ptitjes, start gdb :) Dec 01 11:37:09 * a21_work still rebooting FR Dec 01 11:37:30 * a21_work now booting qtopia 4.3.2 Dec 01 11:37:58 could someone do a one-line howto for gdb ? Dec 01 11:38:07 ptitjes: one-line? ;) Dec 01 11:38:18 yeah :) Dec 01 11:38:22 a21_work: why not just chroot to qtopia? Dec 01 11:38:32 ptitjes: that's bit difficult Dec 01 11:38:51 lindi-: maybe different kernel and different loaded modules Dec 01 11:39:12 a21_work: that should be easy to verify? Dec 01 11:45:09 quickdev: I'm not the one responsible for this ;) : #3 0x40371300 in ui_init () from /usr/lib/libframeworkd-phonegui-efl.so.0 Dec 01 11:45:23 ptitjes, try export DISPLAY=:0.0 Dec 01 11:45:27 and then run it again Dec 01 11:45:30 arf Dec 01 11:45:36 so sorry Dec 01 11:45:43 no, anyway, it's my fault Dec 01 11:52:06 or 'DISPLAY=:0.0 guiapptorun' Dec 01 11:55:38 quickdev: in ophonekitd_call_status_handler(...), I receive \u000b in the number variable (gchar *) when a call is released instead of the real number Dec 01 11:56:07 I receive the correct number when outgoing Dec 01 11:58:05 ptitjes, the caller can suppress it's number Dec 01 11:58:39 but there's a little bug in ophonekitd. number should be NULL, if it's suppressed. Atm it has no standard value. Have a look at the declartion of number Dec 01 12:00:30 in fact this was my answering machine Dec 01 12:00:32 123 Dec 01 12:00:57 and I received the correct number when status was OUTGOING Dec 01 12:01:27 you have an answering machine? i thought those died out and all thats around is VoiceMailbox systems Dec 01 12:01:49 is it the lil black box from sneakers? Dec 01 12:02:01 (actuall answering machine) Dec 01 12:02:46 ;D Dec 01 12:03:33 ptitjes, yes, but it's status = INCOMING, not? Dec 01 12:04:05 I'm calling my answering machine to test my phone log stuff Dec 01 12:04:28 so when status=OUTGOING I get the correct number in the number variable Dec 01 12:04:41 but when status=RELEASED I get \u000b Dec 01 12:05:56 aah :) afaik RELEASED does not give a number. thus number should be NULL Dec 01 12:06:46 aargh Dec 01 12:06:57 so I only get the id Dec 01 12:07:05 but the id is internal to ophonkitd Dec 01 12:08:40 I'm wondering why there's no number in the RELEASED signal Dec 01 12:09:04 should I ask to mickeyl ? Dec 01 12:09:14 try to listen to signals with dbus-monitor (--system or --monitor, can't remember) and see if there really is no number Dec 01 12:09:23 and then ask mickeyl or alphaone Dec 01 12:09:36 ok Dec 01 12:11:31 i don't see numberin RELEASED Dec 01 12:11:42 cbCallStatus 1, release, dbus.Dictionary({dbus.String(u'status'): dbus.String(u'release', variant_level=1)}, signature=dbus.Signature('sv')) Dec 01 12:12:44 alphaone, here? Dec 01 12:14:00 quickdev: yeah Dec 01 12:14:49 please submit a ticket, I'm quite busy right now with non OM stuff (yeah, I know, hang me :-) Dec 01 12:15:07 * Sup3rkiddo hangs alphaone Dec 01 12:15:12 ok, thanks anyway Dec 01 12:15:42 quickdev: yes there is no number Dec 01 12:15:53 just the id and the status Dec 01 12:17:35 one should patch frameworkd :) Dec 01 12:20:28 lindi-: no success... I'm to lamer (and busy) to hack how to strace the mediaserver in qtopia... but I see there is not any seq module loaded Dec 01 12:22:09 alphaone, http://rafb.net/p/qnhZSv49.html <- could that be my fault? Dec 01 12:22:57 quickdev: didn't receive a SMS Dec 01 12:23:06 (by the way) Dec 01 12:23:14 quickdev: Why is featuremap boolean there? Dec 01 12:23:22 alphaone, I don't know Dec 01 12:23:24 Ainulindale, I know Dec 01 12:23:25 don't really understand that Dec 01 12:23:36 And got to do other stuff now, sorry Dec 01 12:24:03 quickdev: you're using frameworkd or frameworkd-devel? Dec 01 12:24:08 frameworkd Dec 01 12:24:16 but some days old Dec 01 12:24:23 Latest is on the buildhost Dec 01 12:26:38 Are all SMSes always stored on the SIM? Dec 01 12:26:52 Right now yes Dec 01 12:26:56 ptitjes? Dec 01 12:29:12 Ainulindale: yeah ? Dec 01 12:29:45 how is it going for the sqlite thing? Dec 01 12:30:01 this is working :) Dec 01 12:30:04 very fine :) Dec 01 12:30:11 When will you commit then? Dec 01 12:30:25 except that I don't get the number from frameworkd when a caller is released Dec 01 12:30:33 a call Dec 01 12:30:40 You have an id Dec 01 12:30:51 yes but the id is temporary Dec 01 12:30:52 Did you try with dbus-monitor? Dec 01 12:30:58 ptitjes: then store the number Dec 01 12:31:00 yeah! no number Dec 01 12:31:27 you mean I modify the incomming_calls and outgoing_calls to store the number... Dec 01 12:31:29 pffffffff Dec 01 12:31:37 Yeah, pfff ;-) Dec 01 12:31:45 this is too much for a hack Dec 01 12:32:08 This is currently the only solution Dec 01 12:32:10 maybe this wold be simpler to patch frameworkd Dec 01 12:32:18 s/wold/wold/ Dec 01 12:32:24 No Dec 01 12:32:24 ahhhhhhh wold Dec 01 12:32:37 oh my U do not wokr anymore Dec 01 12:33:00 u Dec 01 12:33:02 ok :) Dec 01 12:33:19 Ainulindale: why this wouldn't be simpler ? Dec 01 12:34:13 Because frameworkd is a huge beast with teeeetthhhhhhh Dec 01 12:34:30 Just implement a work around in between and it'll be ok, trust me =) Dec 01 12:38:00 ok Dec 01 12:38:01 :( Dec 01 12:38:28 Ainulindale: feeling better? Dec 01 12:39:47 doing it right now Dec 01 12:40:01 dolf1074: Nope but I'll look nonetheless Dec 01 12:40:04 I didn't go to work today Dec 01 12:40:21 I think mickey|flu|zzZZz is contagious Dec 01 12:40:24 Watch his DCC Dec 01 12:40:31 Ainulindale: but if you don't feel good, then we can postpone it Dec 01 12:40:41 No, no, that's good Dec 01 12:41:10 What I'd suggest first dolf1074 Dec 01 12:41:19 Is to rethink what you thought in dbus terms Dec 01 12:41:38 This is the only way to have a central access point (ophonekitd) Dec 01 12:42:02 okay Dec 01 12:42:17 So you want to make ophonekitd the crown of shr Dec 01 12:42:26 For what I just saifd Dec 01 12:42:27 -f Dec 01 12:42:39 It's only pertinent if you want to expose these methods to the outside Dec 01 12:42:50 I'd be you, I'd write down two sets of method Dec 01 12:42:54 What the library has to declare Dec 01 12:43:00 And what is callable from an external point of view Dec 01 12:43:21 (i.e. phonegui_show_incoming vs. phonegui_show_contact) Dec 01 12:43:23 Ainulindale: ahem! Dec 01 12:43:26 (the former is triggered) Dec 01 12:43:29 raster: what? Dec 01 12:43:35 :) Dec 01 12:43:40 aha it worked Dec 01 12:43:46 got your attention Dec 01 12:43:46 raster: What? Dec 01 12:43:49 :) Dec 01 12:43:52 You have a question? Dec 01 12:43:56 i looked into the exquisite thing Dec 01 12:44:00 Ah, nice Dec 01 12:44:01 i think i've found it Dec 01 12:44:04 What was it? Dec 01 12:44:05 let me do some more tests Dec 01 12:44:10 So the functions that ophonekit uses vs the functions that other things may need to use Dec 01 12:44:15 raster: If it's not your priority, you might as well forget about it Dec 01 12:44:17 well exquisite was eating about 15-20% cpu for the animation Dec 01 12:44:27 and exqusitie-write is eating cpu flushing buffer in a spinning loop Dec 01 12:44:27 dolf1074: there's two situations, independent Dec 01 12:44:39 dolf1074: events and user initiated things Dec 01 12:44:40 so all in all 30-40$ of cpu vanish into that Dec 01 12:44:42 er Dec 01 12:44:45 30-40$ Dec 01 12:44:46 % Dec 01 12:44:50 i mean Dec 01 12:44:53 events can't, and won't, be called through dbus Dec 01 12:44:57 so that'd explain the "doubles boot time" Dec 01 12:44:58 whereas user initiated methods will Dec 01 12:45:02 raster: that's good to know :-) Dec 01 12:45:09 can follow you Dec 01 12:45:15 dolf1074: can or can't? Dec 01 12:45:18 can Dec 01 12:45:29 So do you agree with me? Dec 01 12:45:35 yes, perfectly Dec 01 12:45:37 My point is, this is a good start indeed Dec 01 12:45:46 Though you would have to write down two different sets Dec 01 12:45:49 Possibly in a table Dec 01 12:45:57 1) litteral prototypes for the C implementation Dec 01 12:46:05 2) dbus calls Dec 01 12:46:14 And link the dbus calls with the method which will be called Dec 01 12:46:59 yes, though I will need to learn dbus Dec 01 12:47:05 Nothing to learn here dolf1074 Dec 01 12:47:25 Just picture different objects exposed to the outside Dec 01 12:47:32 How will you name them, and what will they be able to do? Dec 01 12:47:36 e.g. Dec 01 12:47:53 org.shr.ophonekitd.Usage currently allows the user to request/release resources as if the user was ophonekitd Dec 01 12:47:59 Which is useful to release/request GSM Dec 01 12:48:09 okay, but it should be nice if the dbus calls are already in the format dbus uses Dec 01 12:48:18 There's no format Dec 01 12:48:25 No "true" format I mean Dec 01 12:48:35 Just look at frameworkd specs if you want to do it that way Dec 01 12:48:38 it would be nice if dbus-monitor would show return values ;) Dec 01 12:48:44 okay Dec 01 12:48:45 What I'd suggest is to keep org.shr.ophonekitd Dec 01 12:48:55 Then build a service provider for Dialer, Messages, etc Dec 01 12:49:02 i.e. org.shr.ophonekitd.Dialer Dec 01 12:49:09 And then describe methods upon this object Dec 01 12:49:19 i.e. org.shr.ophonekitd.Dialer.ShowKeypad() Dec 01 12:49:34 Is this clear enough? Dec 01 12:49:43 very clear Dec 01 12:49:49 Problem is Dec 01 12:49:53 You're venturing in UMAF here Dec 01 12:50:21 This is also a spec? Dec 01 12:50:28 Yep Dec 01 12:50:31 But don't care about that Dec 01 12:50:34 Do your thing first Dec 01 12:50:43 Ah and Dec 01 12:50:46 Please prefix your method Dec 01 12:50:51 phonegui_ isn't enough Dec 01 12:50:54 phonegui_dialer is Dec 01 12:51:02 e.g. phonegui_dialer_show_keypad Dec 01 12:51:06 they are Dec 01 12:51:11 int phonegui_messages_show_folders(); Dec 01 12:51:20 I saw some which weren't Dec 01 12:51:28 e.g. dialer :-) Dec 01 12:51:39 ow yes Dec 01 12:51:45 And make all the prototypes return void Dec 01 12:51:46 my fault :) Dec 01 12:52:01 and work with callbacks? Dec 01 12:52:07 Callbacks for what? Dec 01 12:52:17 Why would we want callbacks? Dec 01 12:52:20 for getting data Dec 01 12:52:25 Getting data for what? Dec 01 12:52:32 Ainulindale: have u read my hilight? Dec 01 12:52:35 Give me a good example and I'll destroy it for you :-) Dec 01 12:52:40 a21_work: which one? Dec 01 12:52:46 If you show a keypad, the user can enter some data Dec 01 12:52:52 if the user then press ok Dec 01 12:53:03 the data will be send to the program that has opened the keypad Dec 01 12:53:08 dolf1074: What for? Dec 01 12:53:13 about my apologies: 173 is not a defect but an enhancement Dec 01 12:53:18 Initiate a call dolf1074? Dec 01 12:53:35 the keypad can be used for multiple things Dec 01 12:53:37 What if, say, user checks an option Dec 01 12:53:45 How will you managet hat? Dec 01 12:53:50 (Hint: you won't be able to) Dec 01 12:53:56 IMHO Dec 01 12:54:04 The UI should manage itself this data Dec 01 12:54:28 a21_work: yeah, saw that, nevermind Dec 01 12:54:36 ok Dec 01 12:55:11 yes, but the phonegui_show_keypad(); can be used in more than one way. For example, it can be used for calling. Another example, it can be used for entering the number of a cellphone, when you save a number Dec 01 12:55:26 dolf1074: that isn't done that way Dec 01 12:55:32 So if the keypad return the value that is inserted, it can be used in the 2 examples Dec 01 12:55:32 You're mixing two ideas here Dec 01 12:55:35 Widgets and screens Dec 01 12:55:56 Adding a contact is a different screen compared to Calling a contact Dec 01 12:56:00 Even if both may use the same keypad Dec 01 12:56:13 This shouldn't be known from the master daemon Dec 01 12:56:19 This is the internal behavior of the UI Dec 01 12:56:31 The daemon does one and only one thing Dec 01 12:56:38 User wants to call? Fine, it displays the call screen Dec 01 12:56:44 It won't be able to tell that it has to compose stuff Dec 01 12:57:25 Your idea, even if it's sensible, makes no sense if we take into account the context of the use we will do of that spec Dec 01 12:57:29 If makes sense UI wise Dec 01 12:57:32 Not daemon wise Dec 01 12:57:38 Do you get what I mean? Dec 01 12:57:51 I do get it, but finds it a very thin line Dec 01 12:58:01 I will explain Dec 01 12:58:03 What do you mean a thin line? Dec 01 12:58:50 please have a look at how this is done in shell for instance Dec 01 12:58:52 As an application maker, it should be handy if I can show a contact list and get back what contact the user has choosen Dec 01 12:59:18 dolf1074: As an application maker, you won't do it like that Dec 01 12:59:28 Let's take a use case Dec 01 12:59:36 ok Dec 01 12:59:36 User asks to display the contact list Dec 01 12:59:43 ophonekitd calls the right method Dec 01 13:00:00 What on earth should it do, with the info in this screen, selected, or whatever? Dec 01 13:00:08 How can it tell what the user did, without knowing of the UI works? Dec 01 13:00:19 You tell me now that you want to know, say, the user selected Dec 01 13:00:28 Tomorrow someone will tell me he needs the user deleted Dec 01 13:00:42 Two weeks from now, I'll have a struct for returns with 100+ entries in it Dec 01 13:00:51 Because there's infinite possibilites/needs Dec 01 13:00:57 I know Dec 01 13:01:10 Hi! I'm trying using qemu gta01 emulator, with MokoMakefile I did make qemu and the end, qemu runs successfully, shows uboot menu, but when I begining booting kernel "virtual neo" restarts (also tryed different kernels/rootfs). May somebody descibe how to run qemu gta01(or gta02fake) successfuly? Dec 01 13:01:14 That's why this shouldn't, and won't, be handled in this kind of spec, to me Dec 01 13:01:27 dolf1074: this is pertinent for UI spec Dec 01 13:01:33 not Daemon-to-UI spec Dec 01 13:01:50 the daemon has to know only what screens it has to display Dec 01 13:02:03 But with my implementation I want to give the programmers a handy library for making their programs. If you want the user to select something, you call a libframeworkd-phonegui function Dec 01 13:02:08 You can think about a way to write template libs, and cut that down to unitary things Dec 01 13:02:14 But this still won't be related to the daemon Dec 01 13:02:23 dolf1074: you're mistaken here Dec 01 13:02:26 This won't work Dec 01 13:02:44 You simply can't do that, it's the best way to build a gas factory :-) Dec 01 13:02:47 If you want to open a real working messaging program, you have to launch messages program Dec 01 13:02:49 loud and noisy, and pretty much buggy :-) Dec 01 13:03:15 don't need to Dec 01 13:03:37 you define screens, and the return value is only when someone selected something Dec 01 13:03:47 dolf1074: In our case, this can't be done that way Dec 01 13:04:04 There's infinite situations Dec 01 13:04:04 why? Dec 01 13:04:21 And we can't handle every one of them because only the UI/initiator of the event knows what to do Dec 01 13:05:13 But every screen is isolated. It's like a new program. The only data you get from it is if someone selects something Dec 01 13:05:24 The problem is that Dec 01 13:05:28 This something is undefinited Dec 01 13:05:34 a Dec 01 13:05:35 You can't make the choice for the UI developer Dec 01 13:05:43 And there's plenty of results possible Dec 01 13:05:51 And the only piece of code which will be sure of that result is the UI Dec 01 13:06:00 If say, now, you tell me there are 3 actions possible Dec 01 13:06:20 I bet that putting a raster on the case he'll pinpoint 42 supplementary actions Dec 01 13:06:28 The screens aren't defined for returning every action on the screen Dec 01 13:06:32 And we can't simply handle that many actions in a daemon Dec 01 13:06:37 It's a band aid, to me Dec 01 13:06:46 Each screen has only one action Dec 01 13:06:49 A band aid to replace the fact that the UI has to know what it does Dec 01 13:06:54 You're wrong :-) Dec 01 13:06:55 int phonegui_messages_show_folders(): selecting folder Dec 01 13:07:02 delete folder? Dec 01 13:07:04 int phonegui_messages_show_messages( int folder ): selecting message Dec 01 13:07:06 rename folder? Dec 01 13:07:14 (same here) Dec 01 13:07:35 Ainulindale: that's handled inside the screen. The programs doesn't have to know Dec 01 13:07:41 That's my point Dec 01 13:07:48 The daemon doesn't have to know a thing Dec 01 13:07:57 because it won't be able to manage all the thing the developer will want to do Dec 01 13:08:01 +s Dec 01 13:08:09 And as we won't be able to implement everything Dec 01 13:08:21 but you don't have to implement delete folder Dec 01 13:08:26 Why ? Dec 01 13:09:00 quickdev? Dec 01 13:09:04 that's like you're showing a 'save as..' screen in gedit. Gedit doesn't have functionallity for deleting folders Dec 01 13:09:14 but the 'save as..' dialog has Dec 01 13:09:20 dolf1074: you're taking a wrong example here Dec 01 13:09:32 and gedit doesn't has method for knowing those events Dec 01 13:09:42 I tell you, and you can seriously trust me on that :-) Dec 01 13:09:48 Return values won't be doable Dec 01 13:09:58 It can't be done this way, IMHO Dec 01 13:10:20 And anyway Dec 01 13:10:28 I know return values can't be done. (because of threads that need to loop) Dec 01 13:10:29 As this won't be callable but by the daemon Dec 01 13:10:38 It has no meaning Dec 01 13:10:45 Because the daemon will only have one behavior Dec 01 13:10:47 but with callbacks it is already doable without the dbus Dec 01 13:10:48 This behavior will be user initiated Dec 01 13:11:16 No, you can't either :-) Dec 01 13:11:29 I told you, a return value is an undefinite thing Dec 01 13:11:34 Today you need this, tomorrow you'll need that Dec 01 13:11:39 This isn't the way to do things Dec 01 13:11:43 For a daemon to UI spec Dec 01 13:11:47 We have to define unitary functional screens Dec 01 13:11:50 No, it isn't an undefinite thing Dec 01 13:11:54 Which then will be handled by the UI itself Dec 01 13:11:56 Ainulindale, ? Dec 01 13:11:58 And I tell you it is :-) Dec 01 13:12:04 quickdev: backlog, tell your opinion please :-) Dec 01 13:12:25 I say we only return the thing wherefor the screen is designed Dec 01 13:12:38 And I tell you this puts too much UI logic in the daemon Dec 01 13:12:41 And it's not doable Dec 01 13:12:50 It even breaks layers Dec 01 13:13:00 The daemon shouldn't be aware of what the UI does Dec 01 13:13:12 And shouldn't be aware of the results of its actions Dec 01 13:13:18 It launches a screen, then forgets about it Dec 01 13:13:19 I think of what I have made, like a library for the user to use screens Dec 01 13:13:31 *the developer Dec 01 13:13:31 (god you're stubborn =) ) Dec 01 13:13:44 Ainulindale: sorry :) Dec 01 13:13:55 dolf1074: Been there, done that, seriously Dec 01 13:13:59 Don't try to reinvent the wheel =) Dec 01 13:14:19 Your idea is based on a good intention but as I told you Dec 01 13:14:22 This, in the context of a daemon Dec 01 13:14:25 Isn't doable at all Dec 01 13:14:37 If you want to cut down an UI library into pieces this way Dec 01 13:14:43 It's doable, UI wise Dec 01 13:14:47 But not by the daemon Dec 01 13:15:05 That's was the intention, providing an UI library (Al least I thought) Dec 01 13:15:17 The intention is to expose the UI library to the daemon Dec 01 13:15:22 But as I told you Dec 01 13:15:31 It has to be cut down into functional pieces Dec 01 13:15:39 show keypad is a piece Dec 01 13:15:47 but not show keypad widget Dec 01 13:15:54 next to it, we can make something called shr-launcher that is a daemon for launching the different apps Dec 01 13:15:56 show keypad widget is UI, and only UI Dec 01 13:16:27 (I'm damn hungry) Dec 01 13:17:42 dolf1074, I'm sharing Ainulindale's opinion. ophonekitd should not be aware of any UI state. For your use case, displaying the keyboard, you could build a library that is linked in your UI module, but not through ophonekitd :) Dec 01 13:18:36 dolf1074: (do you know about MVC?) Dec 01 13:19:14 quickdev: I share also your opinion ;) We are talking about 2 different things. I made a ui library (Which I hope you find good) and Ainulindale wanted a 'apps launcher' throught ophonekitd that handles all the events Dec 01 13:19:32 dolf1074: eerrr Dec 01 13:19:35 That's what phonegui is Dec 01 13:19:43 That's what it's supposed to be Dec 01 13:20:02 I thought it was a gui library, sorry my fault Dec 01 13:20:05 If you want to break down phonegui into pieces, this belongs to the UI realm, else you'll break the layer consistency Dec 01 13:20:14 And if you want to do that Dec 01 13:20:20 You'll be confronted to tons and tons of problems Dec 01 13:20:26 Because you'll be reinventing a toolkit Dec 01 13:20:41 And I'm not sure you want to do that Dec 01 13:20:50 wait a sec. Just simple questions, please answer with yes or no Dec 01 13:20:58 (heh =) ) Dec 01 13:21:24 If you see the thing I made as a UI library, do you thing it 's good? Dec 01 13:21:44 For all the reasons I told you before, sorry to say but no :-) Dec 01 13:21:49 Because things are missing Dec 01 13:21:57 And if you "implement" these specs Dec 01 13:22:03 You'll be closer to a toolkit Dec 01 13:22:12 If you see the thing I made as a Screen library, do you thing it 's good? Dec 01 13:22:14 And you'll tie the hands of anyone who'll want to use this library Dec 01 13:22:21 You'll be closer to an implementation than to a library Dec 01 13:22:30 screen library ? Dec 01 13:22:34 As I described it? Dec 01 13:22:42 i.e. break down into functional screens? Dec 01 13:22:57 yes Dec 01 13:23:06 For that type of thing, yes, it's good Dec 01 13:23:11 Even if it's alpha spec :-) Dec 01 13:23:23 (I didn't read all the pages, please minde that) Dec 01 13:23:28 (Just two of them) Dec 01 13:23:36 (I have to eat before anything else :-) ) Dec 01 13:24:16 Now if libframeworkd-phonegui is split into functional program's that can be launched by ophonekit or through dbus. And these programs use the screen library for making some screen. Dec 01 13:24:28 Do you think it should be good? Dec 01 13:25:25 Indeed, that's t he whole idea of phonegui :-) Dec 01 13:25:39 freesmartphone.org: 03ainulindale 07libframeworkd-glib * r703017c8f874 10/src/ (4 files in 2 dirs): Dec 01 13:25:39 freesmartphone.org: * Implemented a FrameworkdHandlers constructor, in order to avoid duplication. Dec 01 13:25:39 freesmartphone.org: * Corrected a typo in frameworkd-glib-ogsmd-sim.[c|h]. Thanks to "gotterdammerung" Dec 01 13:27:09 Ainulindale: okay, was my fault. Didn't know the exact idea of libframeworkd-phonegui Dec 01 13:27:22 But now we agree :) Dec 01 13:27:24 dolf1074: That's why I tried to explain that to you last week :-) Dec 01 13:27:40 And for your UI break down thing Dec 01 13:27:46 Even though I know you think it's good Dec 01 13:27:48 Be wary of that Dec 01 13:27:51 It's a treacherous road Dec 01 13:28:15 Ainulindale: You and quickdev has to decide if you want to take that road Dec 01 13:28:22 (And I mean by that it's a lot of work, for something which might not worth it) Dec 01 13:28:52 dolf1074: If you think you'd enjoy that, then do it, but as I told you, I don't think developers will find it simpler Dec 01 13:29:16 I, for one, would feel tied to something, some business logic, I can't modify :-) Dec 01 13:29:28 But that's me Dec 01 13:29:44 why you would feel like that? Dec 01 13:30:11 Because your idea implies some businness logic idea Dec 01 13:30:16 I would feel relieved, because I don't have to make a contacts selection screen for example Dec 01 13:30:17 s/idea/management/ Dec 01 13:30:26 You would have to do it in the end anyway Dec 01 13:30:34 why? Dec 01 13:30:35 I don't understand why you think you wouldn't have to do it Dec 01 13:30:53 Ainulindale: I mean, you don't have to make it twice Dec 01 13:31:05 yes you would Dec 01 13:31:31 Once for the contacts selection, when you are dialing. And once for the contacts selection, when you are sms Dec 01 13:31:45 dolf1074: Ah but here you're mistaken :-) Dec 01 13:31:59 show me Dec 01 13:32:01 Exposing methods to the daemon doesn't mean you can't factorize in the UI Dec 01 13:32:54 And as I told you Dec 01 13:33:02 Defining standards for the implementing UI libraries makes sense Dec 01 13:33:09 But it's hard, time consuming Dec 01 13:33:19 And it hardly ends Dec 01 13:34:22 Now we can reuse code behind the scenes. But if I make a new application that will store the adress for every contact. (dumb example) and I need the user to select a contact, I can use that screen Dec 01 13:34:41 Didn't understand your example Dec 01 13:34:43 jhi Dec 01 13:34:56 mickey|flu|zzZZz around? Dec 01 13:35:21 I think he flu^Wflew away Dec 01 13:35:34 I make a new application that is some sort of GPS program. When You are at someone's home, you can press a button for saving that location to one of the contacts Dec 01 13:35:44 Ainulindale the what? Dec 01 13:35:46 The GPS program will save that location Dec 01 13:36:16 but It would be handy if I can use the screen for selecting contacts that I have used in sms and dialer Dec 01 13:37:45 dolf1074: still don't get what you mean Dec 01 13:37:52 dolf1074, I get what you mean Dec 01 13:38:04 I programmed a "contactlist"-widget for that Dec 01 13:38:45 quickdev: that is good. But that has several disadvantagements Dec 01 13:39:10 I want to compare my contactlist-screen as something like a save-dialog Dec 01 13:39:33 It's main reason is to select a contact. (save-dialog: save a document) Dec 01 13:39:35 and for that yuo want to have a phonegui_ method Dec 01 13:39:37 But it can do more Dec 01 13:39:56 It can delete contact on the road (save-dialog: delete folders) Dec 01 13:39:59 I understand you Dec 01 13:40:03 And therefor I made a library Dec 01 13:40:13 it makes sense Dec 01 13:40:21 (I called it wrongly libframeworkd-phonegui Dec 01 13:40:23 ) Dec 01 13:40:38 Ainulindale, think about phonegui_dialog_show. It's something like that, which we already have. Dec 01 13:40:58 dolf1074, the interface should be in libframeworkd-phonegui Dec 01 13:41:02 but not the implementation Dec 01 13:41:18 the impletation belongs (for example) to libframeworkd-phonegui-efl Dec 01 13:42:02 quickdev: yes? Dec 01 13:42:39 I though libframeworkd-phonegui was designed to launch full applications. through ophonekitd events or throught the user. Dec 01 13:42:39 dolf1074, each ui library, for example EFL / GTK / KDE can implement their own contacts dialog Dec 01 13:42:47 thus you need a common interface Dec 01 13:43:23 Okay, so my spec on trac is good? http://shr.bearstech.com/trac/wiki/libframeworkd-phonegui Dec 01 13:43:34 dolf1074, sorry, you're right Dec 01 13:43:45 libframeworkd-phonegui is only supposed to load the libs Dec 01 13:44:48 but in my opinion the function prototypes for the phonegui_* functiosn should go there Dec 01 13:44:54 Ainulindale, what do you think? Dec 01 13:45:21 Ainulindale: doesn't want those functions and my spec in libframeworkd-phonegui Dec 01 13:46:11 because for him libframeworkd-phonegui will call fully functional programs. So p.e. launch the message program Dec 01 13:46:18 show the active calls Dec 01 13:46:25 and so on Dec 01 13:46:48 While my specs are in fact a screen library. (or something like that) Dec 01 13:47:08 It aren't real programs, but screens that can be used in other programs Dec 01 13:48:04 So I suggest to make libframeworkd-phonegui and libframeworkd-abstractgui Dec 01 13:49:42 You're mixing things up Dec 01 13:49:51 I want the phonegui spec to be a screen library Dec 01 13:50:05 But the inner functionnalities of the UI should be abstracted in this spec Dec 01 13:50:14 ophonekitd doesn't have to know the UI logic Dec 01 13:50:22 (anyway, going away before I'll digest myself) Dec 01 13:50:43 how I could manually (terminal cmd) shut down wifi? (i tried ifdown eth0 and ifconfig eth0 down... iwconfig... but wifi gadget icon remains lit) Dec 01 13:51:24 Hi, everybody :) Can anyone evaluate my bugreport on the ml about gsm0710muxd and probably compile a fixed version? (i've been struggling today with qemubuilder but after trying several kernels without necessary hard disk support and finding a correct one it seems that it's non-trivial to use a proxy inside the builder. I've given up for now). Dec 01 13:58:08 Ainulindale, in which case would ophonekitd know the UI logic? It doesn't have to. dolf1074's functions are called by the libframworkd-phonegui-* libs only. Dec 01 13:58:31 shr feed down? Dec 01 13:58:39 quickdev: that's my point Dec 01 13:58:48 Zorkman: no Dec 01 13:58:53 quickdev: and maybe other application, if they want to insert a select_contact_dialog Dec 01 13:59:53 Ainulindale, you want to seperate functions called by ophonekitd and functions not called by ophonekitd? Dec 01 14:00:05 Huh? Dec 01 14:00:50 Ainulindale, you said that's my point. But what exactly is your point? Dec 01 14:01:16 14:50:14 < Ainulindale> ophonekitd doesn't have to know the UI logic Dec 01 14:01:29 Ainulindale: i can ping google, but can't opkg update; when i open http://shr.bearstech.com/shr-testing/ipk/all/Packages.gz in my browser it also times out Dec 01 14:03:17 Ainulindale, in fact is does not know, because it does not call any additional functions in comparison to now. But i you don't want to have those things in the same header file or lib, one could create another Dec 01 14:03:49 I didn't understand your sentence quickdev Dec 01 14:03:50 Ainulindale: So therefor we should stick some library between ophonekitd and phonegui ( that I call phonescreens) Dec 01 14:04:00 Stop Dec 01 14:04:05 phonegui IS a screen library Dec 01 14:04:08 It has been that way from the start Dec 01 14:04:17 And it'll stay that way Dec 01 14:04:20 dolf1074, no library between Dec 01 14:04:28 Because ophonekitd shouldn't know what the UI does Dec 01 14:05:28 Ainulindale: so you want function to call (from ophonekitd) to real working and complete apps Dec 01 14:05:35 No Dec 01 14:05:37 (that are located in a library) Dec 01 14:05:50 15:04:06 < Ainulindale> phonegui IS a screen library Dec 01 14:06:44 But it is a screen library, where each screen has to work completely and does all functionality. I call that an app Dec 01 14:06:56 It's a screen Dec 01 14:07:03 What you call screens are widgets Dec 01 14:07:18 In some parts, it has more than 1 screen Dec 01 14:07:37 Ophonekitd doesn't know that, and this is a matter managed by the UI Dec 01 14:07:43 I know Dec 01 14:07:47 ophonekitd asks the UI to display messages Dec 01 14:07:51 Whatever the UI does, it doesn't care Dec 01 14:07:53 And that is logical Dec 01 14:08:02 But my spec is a real screen library. It only handles one screen per function Dec 01 14:08:02 if the UI wants to display naked pictures of me in between Dec 01 14:08:07 It's the matter of the UI Dec 01 14:08:18 That I call apps Dec 01 14:08:22 dolf1074: And as I told you Dec 01 14:08:25 This is *wrong* Dec 01 14:08:30 Because it puts the logic in ophonekitd Dec 01 14:08:34 And I simply won't put it there Dec 01 14:09:22 I know, therefor I want to make another library Dec 01 14:09:34 And as I told you Dec 01 14:09:45 I think this library you're talking about is more a burden than anything Dec 01 14:09:50 I know Dec 01 14:09:54 And were I to conceive an UI library Dec 01 14:09:54 you told me Dec 01 14:09:55 I wouldn't use it Dec 01 14:10:33 And I then tried to explain why it is handy. But I you don't find it handy, I should bury my spec Dec 01 14:10:41 It isn't that I don't find it handy Dec 01 14:10:45 As I told you Dec 01 14:10:49 It's too much work Dec 01 14:10:53 And relative to the developer Dec 01 14:11:03 Too much things which he can't do if it implements this lib Dec 01 14:11:08 Or too much things he has to do Dec 01 14:11:13 That's my point to view Dec 01 14:11:16 s/to/of/ Dec 01 14:11:41 As I told before, I don't tell you it's useless, I tell you this is far from being a priority to me, and I think it's too much work to maintain or implement this Dec 01 14:12:09 And I tried to explain it isn't. By referring to the save-dialog in gtk. But yeah I will stop praising my spec ;) Dec 01 14:12:18 And again Dec 01 14:12:22 The save dialog is a widget Dec 01 14:12:25 Not a screen Dec 01 14:12:37 Save dialog does one thing, and I agree with you on that Dec 01 14:12:42 But we're not talking here about "one thing" Dec 01 14:12:48 A contact list may be used for several actions Dec 01 14:13:02 not in the spec I wrote Dec 01 14:13:11 That's why I tell you it's bad Dec 01 14:13:19 A save-dialog can also be used for several actions Dec 01 14:13:38 but it's main goal is to save Dec 01 14:13:45 Yes but this has no impact on the caller Dec 01 14:13:46 and give the location back to the main window Dec 01 14:13:59 Whereas what you want to do is to return stuff, based on actions you assume are the actions Dec 01 14:14:12 selecting a contact isn't solely your possibility on a contact list Dec 01 14:14:36 Because you might want to select several contacts, rename one, etc Dec 01 14:14:41 And in that case, you have to describe all the actions Dec 01 14:14:47 And that is just too much work to me Dec 01 14:14:54 that's all handled in that window Dec 01 14:15:06 Then returning something has no meaning Dec 01 14:15:10 As I told you before Dec 01 14:15:23 because if you select something Dec 01 14:15:25 nice Dec 01 14:15:27 To sump up, you're halfway between solution A and solution B Dec 01 14:15:30 And you just can't Dec 01 14:15:33 a catfight before i go out :D Dec 01 14:15:40 Because it breaks layering, because it implies to much things Dec 01 14:15:47 +o Dec 01 14:15:59 But once again Dec 01 14:16:01 That's my opinion Dec 01 14:16:06 You asked for it, I gave it Dec 01 14:16:12 where does it break layering? Dec 01 14:16:21 *Gaah* Dec 01 14:16:24 Backlog please :-) Dec 01 14:16:31 Ainulindale: that's good, discussion is always good. Dec 01 14:16:45 Yes, discussion is good, but please remember I have an headache =) Dec 01 14:16:54 okay Dec 01 14:17:14 dolf1074: My problem with your idea, as I told before Dec 01 14:17:26 Is that it has nothing, and I really mean nothing, to do with ophonekitd Dec 01 14:17:39 I know Dec 01 14:17:43 ophonekitd doesn't, and won't, have to know the inner functionnalities of the UI Dec 01 14:17:47 If you want to do that kind of thing in the UI Dec 01 14:17:52 that's correct Dec 01 14:17:53 I don't care, do it if you feel like it Dec 01 14:18:06 My point is just to tell you that this has nothing to do with phonegui Dec 01 14:18:16 As phonegui is solely there to link the UI with ophonekitd Dec 01 14:18:22 Not to define widgets Dec 01 14:18:34 But I though it was clear, I don't want this in phonegui or that this is related to ophonekitd Dec 01 14:18:51 therefor I said, there has to be something in between ophonekitd and my spec Dec 01 14:18:56 namely the phonegui Dec 01 14:19:08 the phonegui will make full working screens Dec 01 14:19:31 based on the widgets (I like to call them screen, because it's just one screen) in the spec I made Dec 01 14:19:51 You're wrong again :-) Dec 01 14:19:54 And my widgets you have to see like save-dialogs Dec 01 14:19:55 the order is as follows Dec 01 14:20:03 ophonektid <= screens => phonegui Dec 01 14:20:15 phonegui <= screens definition => phonegui-implementation Dec 01 14:20:18 And here you can do, if you want Dec 01 14:20:28 phonegui-implementation <= compose => phonegui-widgets Dec 01 14:20:41 But this is the lower layer of the UI, and this isn't screens Dec 01 14:20:48 What you're describing is to me a composition of widget Dec 01 14:20:59 That's why I'm telling you to be wary as it seems to me you're reinventing a toolkit Dec 01 14:21:28 but a select_contact_dialog isn't something is already in some toolkit Dec 01 14:21:40 It's a meta widget Dec 01 14:21:48 Same thing than a keypad is Dec 01 14:21:53 quickdev did a keypad widget, for example Dec 01 14:22:51 I already explained there is a difference between a contacts widget and select contact screen. Dec 01 14:23:00 You explained what seems logical to you Dec 01 14:23:03 It doesn't seem logiacl to me Dec 01 14:23:34 I have other problems with that, anyway Dec 01 14:23:41 What if I want to filter the contact list natively? Dec 01 14:23:46 What if I want to display it in a different way? Dec 01 14:23:51 okay then we should burry my spec, if it isn't logical to you. Dec 01 14:23:51 (icons, list, who knows) Dec 01 14:24:03 Stop being stubborn will you :è) Dec 01 14:24:20 My suggestion is to do it one step at a time Dec 01 14:24:25 I should then better use my programming skills for other aspect of SHR Dec 01 14:24:27 First, making the interface between the daemon and the gui Dec 01 14:24:34 That's an important thing Dec 01 14:24:46 Then, if you want to define micro widgets Dec 01 14:24:54 This has to be though about thoroughly Dec 01 14:25:04 This isn't a matter of one or two days of reflexion, seriously Dec 01 14:25:28 I've been there, I've done that, and I regretted it utterly Dec 01 14:25:32 You can have my word on that Dec 01 14:25:47 I just don't want to see people work on something that won't be usable because we just forgot one aspect of it Dec 01 14:25:58 And breaking down things into tiny pieces which are simple to take a grasp on is easier Dec 01 14:26:19 For example, separating the libs as you describe it is a good idea Dec 01 14:26:31 And it's simple, and the outcome of this is clear for everyone Dec 01 14:26:40 Readability, segregation and such Dec 01 14:27:07 I know, but if you can't find it in the base of my spec. Than we shouldn't pinpoint us on that spec. But try to make something different. ;) Dec 01 14:27:27 WHat I find in your spec isn't what you think you put in there Dec 01 14:27:40 The base idea is the same, except you're pushing further than what I thought Dec 01 14:28:24 I knew what I was describing, it was only not what you expected. Because I wanted to go a step further Dec 01 14:28:38 So I will use the elevator up again ;) Dec 01 14:39:22 hmm, some days inactive and openmoko-calculator fails to build. I bet it is Ainulindales fault. :D Dec 01 14:40:37 it is always an Ainulindale's fault Dec 01 14:40:50 Hire: Indeed Dec 01 14:41:30 i am always right Dec 01 14:42:15 however i want to see, before I got out, how finish the match: ainulindale vs dolf1074 :D Dec 01 14:46:16 Hire: the world isn't always black and white Dec 01 14:47:02 :/ Dec 01 14:47:50 It wasn't a battle between Ainulindale and me, It was a discussion to make good libraries for the programmer and the user Dec 01 14:48:26 i am kidding :) Dec 01 14:52:51 Ainulindale: changed the libframeworkd-phonegui spec http://shr.bearstech.com/trac/wiki/libframeworkd-phonegui Dec 01 14:54:03 will tonight or tomorrow look at the dbus separation Dec 01 14:54:58 sorry, mean the separation of the dbus functions and the c implementation Dec 01 14:59:03 http://shr.bearstech.com/ still timesout here (on FR and on host) Dec 01 14:59:23 Zorkman: no problems here Dec 01 15:00:05 strange....; all other websites i try to visit work... Dec 01 15:21:04 did the ntpclient dissapeared from the repo ? Dec 01 15:25:26 stefan_schmidt: calc builds here Dec 01 15:28:28 Ainulindale: hu? You added the LICENSE to it? Dec 01 15:28:37 That's what breaking here Dec 01 15:29:13 Well are you sure about that? Dec 01 15:29:23 Ainulindale: yes Dec 01 15:29:25 openmoko-calculator2 ? Dec 01 15:29:32 yes Dec 01 15:29:44 Was there an update recently? Dec 01 15:29:52 Works with the LICENSE set explicit in the bb Dec 01 15:29:59 Ainulindale: Could be Dec 01 15:30:15 LICENSE should be set by default in the bbclass Dec 01 15:30:16 Ainulindale: I'm just catching up after some days of lazyness and X200s fun Dec 01 15:30:45 Well it isn't, so yes there's a problem Dec 01 15:30:46 Ainulindale: Python barks out in the openmoko2 bbclass Dec 01 15:30:47 openmoko_two_get_license Dec 01 15:30:54 Though I can't understand why it worked before Dec 01 15:31:02 (and just so you know, I didn't touch that =) ) Dec 01 15:31:22 Though this won't work because of the PKG_TAGS Dec 01 15:31:31 err Dec 01 15:31:33 the section I mean Dec 01 15:31:42 But then the section is good there Dec 01 15:31:53 stefan_schmidt: for this function it's based on SECTION Dec 01 15:32:07 stefan_schmidt: if it's openmoko/libs it's LGPL, GPL in the other case Dec 01 15:32:22 But if you put something without a / it fails Dec 01 15:32:30 (as long as you inherit openmoko2) Dec 01 15:33:21 Ainulindale, alphaone band-aid pushed Dec 01 15:33:42 what for? Dec 01 15:33:55 Ainulindale: mom, call Dec 01 15:34:42 I'll be keeping this log preciously Dec 01 15:34:53 As it can be widely misinterpreted Dec 01 15:35:02 And it's something to have good leverage on you :-) Dec 01 15:36:04 Ainulindale: heh Dec 01 15:36:28 Ainulindale: I just commited the LICENSE field to om-calc to let it build Dec 01 15:36:45 Ainulindale: Fixing ths python magic would be appreciated Dec 01 15:36:57 Ainulindale: I've been called for a job tonight, so I won't be able to commit today. Also I've got memory management problems so I must test it more extensively Dec 01 15:37:23 ptitjes: no problem Dec 01 15:37:32 nomeata: meh Dec 01 15:37:39 Got my answer on smartphones-thingy? Dec 01 15:38:27 Ainulindale: about the suspend thing? yes, thanks for the clarification Dec 01 15:38:46 nomeata: I don't think that it's currently possible to do a proper auto suspend with frameworkd without having some issues Dec 01 15:39:07 I tried to do it, but it implies a more robust way to handle rules Dec 01 15:39:29 And as the rules will be obsoleted when vala/oeventsd will kick in Dec 01 15:39:43 It seems quite unecessary to focus on that Dec 01 15:40:06 ok Dec 01 15:54:28 <[Rui]> Ainulindale: hi, I finally got to adapting omnewrotate to auto* but I'm running into some troubles... I hope you, or someone else, can help me kickstart Dec 01 15:54:59 <[Rui]> I couldn't get frameworkd from the toolchain, so I decided that maybe I should try building FSO in order to get it available Dec 01 15:55:22 <[Rui]> maybe I chose the wrong path.... but it really is somewhat foggy :) Dec 01 15:55:38 <[Rui]> the problem seems to be that making FSO blows up Dec 01 15:56:44 <[Rui]> like this: http://pastebin.com/m76dbae4c Dec 01 16:01:14 freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * r834a1418ed6c 10/fsod/ (11 files in 10 dirs): Dec 01 16:01:14 freesmartphone.org: 1.) Fix mem leaks in Dec 01 16:01:14 freesmartphone.org: ODeviced.get_device() Dec 01 16:01:14 freesmartphone.org: input-helpers.c Dec 01 16:01:14 freesmartphone.org: 2.) Add GetTimeOuts in idlenotifier plugin Dec 01 16:01:18 freesmartphone.org: 3.) Fix some warnings Dec 01 16:19:18 [Rui]: know problem Dec 01 16:19:24 edit the bb file and put LICENSE="GPL" in it Dec 01 16:40:56 <[Rui]> Ainulindale: hi thanks, but am I going in the right direction? It takes so long compiling I'd prefer it wasn't for nothing :) Dec 01 16:59:05 [Rui]: don't do a 'make clean', so next time will take shorter (usually) Dec 01 17:01:26 <[Rui]> DocScrutinizer: yeah :) but what I need is an environment where I can compile stuff Dec 01 17:02:04 <[Rui]> DocScrutinizer: I was trying to adapt omnewrotate to frameworkd and found out that the prebuilt toolchain wouldn't help me anymore :| Dec 01 17:02:32 hmm that's beyond me Dec 01 17:07:25 [Rui]: don't worry, this environment is a good thing to have Dec 01 17:07:40 Though you don't have to build a fully working image Dec 01 17:07:48 Just build a bb recipe for your stuff with all the dependencies Dec 01 17:07:55 Then export your ipk as a feed Dec 01 17:07:58 (Make them accessible through http) Dec 01 17:08:02 or copy over the ipk to your device Dec 01 17:08:38 <[Rui]> Ainulindale: hms... Dec 01 17:10:00 <[Rui]> Ainulindale: ok. Dec 01 17:28:46 BluesLee :) Dec 01 17:30:09 dave :-) Dec 01 17:31:00 i lost sim authentification again, nirvana, bermuda ... Dec 01 17:33:07 hahaha Dec 01 17:33:12 nirvana, bermuda? Dec 01 17:35:26 reflashing .. Dec 01 17:35:55 Aruba, jamaica ooo I wanna take you Dec 01 17:36:26 uh oh :p Dec 01 17:38:03 Bermuda, bahama come on pretty mama Dec 01 17:38:15 was the quote i meant,; couldn't remember it immeddiatly Dec 01 17:38:44 :) Dec 01 17:55:14 <[Rui]> this takes so loooooong :) it started about 17h ago Dec 01 17:55:41 [Rui]: get faster hardware Dec 01 17:56:10 or hack a supercomputer? Dec 01 17:56:18 <[Rui]> I've got a dual core AMD Turion(tm) 64 X2 Mobile Technology TL-60 Dec 01 17:56:26 get four of them! Dec 01 17:56:28 <[Rui]> and 2GB of RAM Dec 01 17:56:49 use ducktape to put them together for maximum pwnage Dec 01 17:56:58 [Rui]: muppet check: did you ask it to build the whole image (or worse: the whole repository), or just the package you want (+dependencies)? Dec 01 17:56:58 <[Rui]> :) Dec 01 17:57:22 <[Rui]> Weiss: well, I did delete the lines on Makefile to avoid building the shr release Dec 01 17:57:28 <[Rui]> but I'm fearing that wasn't enough Dec 01 17:58:18 <[Rui]> then I did make setup, and then make Dec 01 17:58:22 raster: you are a C developer only I guess? because it seems I can't find the right position to place a checkup ( if entry.is_focused(): self.object.x_window_virtual_keyboard_state_set(4) Dec 01 17:58:44 <[Rui]> I thought the whole thing was needed and now why not let it finish :) I'm curious at the result Dec 01 17:58:49 python, edje, evas + SWALLOW etk entries Dec 01 17:59:49 [Rui]: i haven't looked at what that makefile does.. just getting GTK+ took about 2 hours (very roughly) for me - that's building all the cross-compiler and library stuff it needs Dec 01 18:01:37 [Rui]: and of course, the more things you build, the more places there are for it to break... Dec 01 18:01:51 <[Rui]> Weiss: yeah ;) Dec 01 18:25:44 if i would like to restore the u-boot in NAND on the FR, from where can I get it the bootable one from? Dec 01 18:26:43 mbuf: is http://people.openmoko.org/andy/ not ok? Dec 01 18:27:13 PaulFertser, haven't seen it before Dec 01 18:27:47 PaulFertser, have re-compiled my u-boot for openmoko, and trying it to run it from RAM with openocd Dec 01 18:28:46 PaulFertser, can I flash any one of the u-boot-gta02v5v6-stable... to NAND? Dec 01 18:29:46 mbuf: i have to admit i've never tried to use uboot but i see no reason why this should fail. Either way, you'll still have a working one in NOR, so give it a try. Dec 01 18:29:58 mbuf: So yes, any. Dec 01 18:30:22 PaulFertser, no, my own cross-compiled u-boot version didn't boot from NAND, when I had flashed it from NOR :p Dec 01 18:30:23 Don't forget that if you trashed your original u-boot env, you'll need to re-create that as well. Dec 01 18:36:01 ok, u-boot booted from NAND after flashing it with dfu-util Dec 01 18:36:04 Does anyone know why i can't lookup a commit by its hash mentioned in file names at Andy's directory using gitweb at http://git.openmoko.org/ ? AFAIK he doesn't rewrite history for andy-tracking and public Qi branch. Dec 01 18:56:47 hmmm Dec 01 18:57:24 calling freerunner <-> lg renoir kc910 is unusable Dec 01 18:57:36 I hardly heared anything Dec 01 18:57:38 what is the /proc value to check battery status? Dec 01 19:05:26 i am now unable to get openocd from after flashing u-boot on NAND flash; http://pastebin.ca/1272565 Dec 01 19:05:31 what could be the reason? Dec 01 19:05:46 mbuf: look for the files in /sys/devices/platform/bq27000-battery.0/power_supply/bat/ Dec 01 19:06:33 can i load u-boot from RAM, after booting from NOR flash? Dec 01 19:17:35 hi Dec 01 19:17:52 is there a more efficient way to do the following check? Dec 01 19:17:53 http://rafb.net/p/1q2Sor75.html Dec 01 19:18:44 after reflashing new u-boot to NAND, what should be the u-boot env settings that need to be set to use openocd? Dec 01 19:18:56 i am stuck at, http://pastebin.ca/1272565 Dec 01 19:19:07 openocd? Dec 01 19:19:23 lindi-, open on chip debugger Dec 01 19:19:27 ah Dec 01 19:19:40 mbuf: needs debug board? Dec 01 19:19:43 lindi-, yes Dec 01 19:20:05 lindi-, i was able to use it properly, until, i re-flashed new u-boot from Andy's Dec 01 19:20:20 to NAND flash; i am able to boot from NOR and NAND flash; Dec 01 19:20:33 but, openocd exits with unable to detect the target device Dec 01 19:23:03 lindi-, never mind, connected; cable connection problem Dec 01 19:23:10 Someone got any news on rootfs of Android? Dec 01 19:43:36 <[Rui]> ok, I give up trying to compile it all ;) Dec 01 19:49:07 <[Rui]> this is interesting Dec 01 19:49:09 <[Rui]> rms@roque:~/moko/FSO$ ls -laF conf/bitbake.conf Dec 01 19:49:09 <[Rui]> -rw-r--r-- 1 rms rms 396 2008-12-01 19:42 conf/bitbake.conf Dec 01 19:49:09 <[Rui]> rms@roque:~/moko/FSO$ bitbake omnewrotate Dec 01 19:49:09 <[Rui]> ERROR: Unable to open conf/bitbake.conf Dec 01 20:00:19 Which kernel shall I install? FSO, or standard? Dec 01 20:00:42 [Rui]: check your env vars Dec 01 20:02:00 <[Rui]> Ainulindale: well, strace shows me something VERY peculiar... it tries to open in a series of places, one succeeds, but still it fails Dec 01 20:02:31 Well anyway I don't have this file here Dec 01 20:02:46 It's under bitbake/conf/bitbake.conf Dec 01 20:04:41 <[Rui]> even when I put it in a ./conf/bitbake.conf it wouldn't find it Dec 01 20:06:00 <[Rui]> ah... interesting... bitbake may be giving misleading output Dec 01 20:09:53 <[Rui]> this looks like an obstacle race, jump over one obstacle and then there's another one right in front of you :( Dec 01 20:10:54 you need to learn how to fly Dec 01 20:12:01 <[Rui]> sicu: it doesn't help when the docs evidently weren't tested on a clean install Dec 01 20:14:56 Our docs were Dec 01 20:17:47 <[Rui]> that must be why stuff like this happens Dec 01 20:17:50 <[Rui]> rms@roque:/opt/openmoko$ bitbake omnewrotate Dec 01 20:17:50 <[Rui]> ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable. Dec 01 20:17:50 <[Rui]> rms@roque:/opt/openmoko$ grep PERSISTENT_DIR local/conf/local.conf Dec 01 20:17:50 <[Rui]> PERSISTENT_DIR = "/opt/openmoko/cache" Dec 01 20:17:51 <[Rui]> :) Dec 01 20:18:26 <[Rui]> I'll figure it out, eventually, but it's a bore to spend so much time getting a development environment working :) Dec 01 20:21:57 opkg install development-environment Dec 01 20:22:10 u-boot built for qt2410 can be booted from RAM? Dec 01 20:22:17 with openocd? Dec 01 20:24:12 <[Rui]> sicu: I'd be happy with info that just works :) Dec 01 20:24:17 openocd sounds fit for the freerunner Dec 01 20:24:22 Open Obsessive Compulsive Disorder Dec 01 20:25:38 <[Rui]> lol Dec 01 20:27:18 <[Rui]> I don't even see it trying to read that variable with strace Dec 01 20:37:27 git push ssh://bricode@208.43.195.116:922/srv/git.koolu.org/git/freerunner/platform/manifest.git Dec 01 20:37:27 bricode@208.43.195.116's password: Dec 01 20:37:27 Counting objects: 5, done. Dec 01 20:37:27 Compressing objects: 100% (2/2), done. Dec 01 20:37:27 Writing objects: 100% (3/3), 437 bytes, done. Dec 01 20:37:27 Total 3 (delta 1), reused 0 (delta 0) Dec 01 20:37:29 error: unable to create temporary sha1 filename ./objects/tmp_obj_sik85m: Permission denied Dec 01 20:37:31 fatal: failed to write object Dec 01 20:37:33 error: unpack failed: unpacker exited with error code Dec 01 20:37:35 To ssh://bricode@208.43.195.116:922/srv/git.koolu.org/git/freerunner/platform/manifest.git Dec 01 20:37:37 ! [remote rejected] master -> master (n/a (unpacker error)) Dec 01 20:37:39 error: failed to push some refs to 'ssh://bricode@208.43.195.116:922/srv/git.koolu.org/git/freerunner/platform/manifest.git' Dec 01 20:37:42 Whoops. Wrong window. Dec 01 20:38:12 working diligently on android i see, bricode Dec 01 20:38:48 kd8ikt: Yeah. Trying to bring it out into the open. Dec 01 20:39:07 everybody wants to play with Dec 01 20:39:57 bricode: will you guys release it today as planned? Dec 01 20:40:30 Zorkman: Sean had said he was working on an image for today. Dec 01 20:40:53 We're looking at tomorrow for source/build tools/instructions. Dec 01 20:41:18 yeah I read that announcement of Sean, just starting to wonder if he'll make it today Dec 01 20:42:05 -repartitioning my micro sd card- Dec 01 20:42:08 ;) Dec 01 20:43:32 my friend has an HTC, he is able to open his webbrowser to wap.maps.google.com or something, it was neat cause the browser had access to the gps somehow Dec 01 20:43:50 hey bricode Dec 01 20:44:21 <[Rui]> ok, the bitbake that was brought down doesn't work. I have another so called bitbake-om which seems to work better Dec 01 20:44:25 i thought that was cool but i still like tangogps's caching ablilities cause GPRS cost me $ Dec 01 20:44:48 bricode: the last time i tried android it didnt accepted my sim pin, is this solved? Dec 01 20:44:53 kd8ikt: is it neat that a web page can track down where you move? ;) Dec 01 20:45:20 BluesLee: We're currently evaluating a couple of different OSK's. Dec 01 20:45:31 BluesLee: Still working on it. Dec 01 20:45:40 and suspend? will that work bricode? Dec 01 20:45:52 :D Dec 01 20:46:00 bricode: osk? Dec 01 20:46:03 (if you don't have time for questions i will be able to answer myself in a day, just say so :)) Dec 01 20:47:31 On screen keyboard. Dec 01 20:47:56 Zorkman: Suspend depends largely on kernel. stable-tracking has been not so stable. Dec 01 20:48:07 nomeata: r.e. OpenMooCow git repository... sorry for not replying. on its way, i just need to filter out an old version of the sound effect which doesn't have a suitable licence before i can publish it Dec 01 20:48:20 Zorkman: But we're looking at andy-tracking to round out. Dec 01 20:48:29 thanks for the info Dec 01 20:48:43 bricode: my question was about the sim pin which i could type in without the missing kbd Dec 01 20:48:46 Right now I'm focused on getting the source out there and easily buildable, because that's a pretty big hurdle at the moment. Dec 01 20:48:56 Weiss: allright Dec 01 20:49:14 BluesLee: I don't have an answer at the moment for that. Dec 01 20:49:21 bricode: okay Dec 01 20:50:02 bricode: did anything changed concerning the assumptions on the additional partition needed on the sd card? Dec 01 20:50:46 <[Rui]> ok, that last problem was left over environment variables, I think, now persistent_dir is jumped over, "ERROR: Nothing PROVIDES 'omnewrotate'" Dec 01 20:50:58 * [Rui] goes heat his soup. Sobbing. Dec 01 20:53:37 BluesLee: Not at the moment, although people will be able to choose what partitions they want to use and how they want to use them. Dec 01 20:54:22 hi all! o/ Dec 01 20:56:01 bricode: i am not sure if this android stuff is the right thing for me as i do not use the google apps but it has a good ui feeling, i like the landscape effect on the desktop;-) Dec 01 20:59:29 BluesLee: It doesn't necessarily need to be used with Google Apps. Dec 01 21:00:10 bricode: will this release be usable as a daily phone? Dec 01 21:00:55 meaning: min 20h bat life, reliable sms and call (and reasonably audio) Dec 01 21:01:50 Zorkman: No. Not yet. Dec 01 21:01:52 Ainulindale: anything wrong with the git? no changes sice 2 days ;-) Dec 01 21:04:36 Zorkman: This release is aimed so developers can easily build/change and submit patches. Dec 01 21:06:31 ok Dec 01 21:10:52 [Rui]: bitbake -b path/to/omnewrotate.bb Dec 01 21:11:04 Try that or add the bb file to your BBFILES env thingie Dec 01 21:12:52 <[Rui]> Ainulindale: thanks! Dec 01 21:13:30 <[Rui]> Ainulindale: but I had already tried that, I was trying to figureout the huge traceback it produced Dec 01 21:14:21 [Rui]: pastebin that to me please Dec 01 21:14:38 <[Rui]> Ainulindale: found it, it didn't like the "inherits" flag Dec 01 21:16:31 It should Dec 01 21:16:39 Could you pastebin your bb recipe? Dec 01 21:16:43 I'll tell you if something is wrong Dec 01 21:18:15 <[Rui]> sure Dec 01 21:18:32 (Though if you use the autotools, the bb recipe should be reaaaaaaally simple) Dec 01 21:18:56 <[Rui]> http://pastebin.com/d5c8c86b3 Dec 01 21:19:14 Ok you're wrong Dec 01 21:19:16 <[Rui]> Ainulindale: right now it would seem to not even fail :) Dec 01 21:19:16 it's not distutils Dec 01 21:19:19 That's for python Dec 01 21:19:29 PN is useless Dec 01 21:19:29 <[Rui]> oh.. I did copy it from remoko Dec 01 21:19:38 <[Rui]> thinking it would be a reasonably compact app Dec 01 21:19:39 It's whatever is before _.*.bb Dec 01 21:19:45 <[Rui]> ah Dec 01 21:19:48 so if you do omnewrotate_svn.bb Dec 01 21:19:51 PN will be omnewrotate Dec 01 21:19:58 Second, AUTHOR Dec 01 21:20:00 this is too long Dec 01 21:20:01 Change your name Dec 01 21:20:03 :-) Dec 01 21:20:15 <[Rui]> is there a SECTION list of values? Dec 01 21:20:15 get rid of PE Dec 01 21:20:17 <[Rui]> ok Dec 01 21:20:17 And put PR Dec 01 21:20:22 PR="r0" Dec 01 21:20:25 (package revision) Dec 01 21:20:31 That way if you change the bb recipe it'll force rebuild Dec 01 21:20:51 Ainulindale, could we raise EFL's SRCREV to 37843 ? There are some code pieces of python-evas that are needed in python-elementary bindings :) Dec 01 21:21:16 <[Rui]> so PR is only for bb package, yes? Dec 01 21:21:46 THere's a list of the sections on wiki.openembedded.net Dec 01 21:21:46 change inherit distutils by inherit autotools Dec 01 21:21:48 <[Rui]> I'm going to shortly replace the release thingie wih an svn http url so it goes to the trunk Dec 01 21:22:01 quickdev: not now Dec 01 21:22:12 quickdev: this needs heavy testing as last time it borked our config Dec 01 21:22:38 [Rui]: you can do that, and if you do that, tell me the SRCREV (i.e. release number) you consider stable Dec 01 21:22:45 <[Rui]> ouchie! bb.parse.ParseError: Could not inherit file classes/autotools.bbclass Dec 01 21:22:57 Let me see Dec 01 21:24:07 autotools should work Dec 01 21:24:07 It's working here Dec 01 21:24:07 [Rui]: http://bec-systems.com/oe/html/section_variable.html Dec 01 21:24:09 <[Rui]> Ainulindale: ok, but first I'm converting to autotools. I had to stop all that, though, because I needed an environment with libframeworkd_glib :) Dec 01 21:24:24 Why did you need libframeworkd-glib again? Dec 01 21:24:38 (Because it may be lacking the functions you need, and in that case tell me I'll implement them) Dec 01 21:24:59 <[Rui]> yeah, the traceback is similar Dec 01 21:25:01 <[Rui]> http://pastebin.com/d48ceeee Dec 01 21:25:12 [Rui]: if you look for an example of autotools with libframeworkd-glib Dec 01 21:25:16 there's one on SHR git, ophonekitd Dec 01 21:25:18 configure.ac and such Dec 01 21:25:24 <[Rui]> Ainulindale: so I could ask wether the screen is locked, dimmed, change brightness, etc... Dec 01 21:25:36 stop there Dec 01 21:25:48 change brightness isn't a good idea Dec 01 21:25:56 even if I know what you want to do =) Dec 01 21:26:03 (ie. changing brightness before the rotate) Dec 01 21:26:11 for lock/dim and such everything is here Dec 01 21:26:17 But be wary of the brightness settings Dec 01 21:26:44 [Rui]: this backtrace is weird Dec 01 21:26:52 Are you sure you setup your env vars? Dec 01 21:27:11 Could you echo $BBPATH for me please? Dec 01 21:27:17 <[Rui]> sure Dec 01 21:27:32 <[Rui]> rms@roque:/opt/openmoko$ echo $BBPATH Dec 01 21:27:32 <[Rui]> /opt/openmoko/local:/home/rms/moko/bitbake-om Dec 01 21:27:46 And where is your OE tree here? Dec 01 21:27:51 in /opt/openmoko/local/? Dec 01 21:27:57 <[Rui]> AH Dec 01 21:28:04 Well here you are Dec 01 21:28:09 <[Rui]> so it should ALSO have the OE, now I glued it Dec 01 21:28:16 Indeed you should Dec 01 21:28:35 It's as if you told me, "I want to build an house, but I need more than one brick?" :-) Dec 01 21:29:17 [Rui]: had you used mokomakefile or some stuff similar it'd have been a lot easier your know :-) Dec 01 21:29:29 <[Rui]> Ainulindale: this isn't very clear: http://wiki.openmoko.org/wiki/BitBake Dec 01 21:29:39 That's because you shouldn't look at that :-) Dec 01 21:29:47 <[Rui]> Ainulindale: I tried once mokomakefile and decided a shot in the head was less painful ;) Dec 01 21:29:56 Well Dec 01 21:30:00 You can use the SHR version Dec 01 21:30:04 It's quite easy and painless Dec 01 21:30:07 Even if it's merely the same Dec 01 21:30:10 But it comes with SHR Dec 01 21:30:19 http://shr.bearstech.com/trac/wiki/Building%20SHR <= Dec 01 21:30:22 <[Rui]> Ainulindale: it was some time ago :) I used the Makefile in the fso site, it seemed equal to shr's Dec 01 21:30:24 (same makefile for fso by the way) Dec 01 21:30:29 <[Rui]> Ainulindale: yeah :) Dec 01 21:30:31 yeah but if you used that Dec 01 21:30:35 then you already have an OE tree Dec 01 21:30:39 and a "setup-env" file Dec 01 21:30:45 which should set everything for you Dec 01 21:31:06 <[Rui]> Ainulindale: I do Dec 01 21:31:13 Did you use it? :-) Dec 01 21:31:16 <[Rui]> but I was really missing the link Dec 01 21:31:32 Well, when I want to develop Dec 01 21:31:34 <[Rui]> Ainulindale: yeah, make setup, make (until after almost 24h I gave up compiling everything) Dec 01 21:31:45 I go to my shr directory which contains the OE tree Dec 01 21:31:47 . setup-env Dec 01 21:31:50 then I bitbake this or that Dec 01 21:31:53 And you shouldn't do make Dec 01 21:31:55 <[Rui]> because in the meanwhile I understood it didn't need all :) Dec 01 21:31:59 just bitbake what you want Dec 01 21:32:02 <[Rui]> Ainulindale: learnt that the hardway :) Dec 01 21:32:08 this will give you an ipk in tmp/deploy/glibc/ Dec 01 21:33:00 <[Rui]> ok, no traceback, but not even downloaded Dec 01 21:33:00 well anyway, ping me if you need me Dec 01 21:33:08 bitbake -c clean first Dec 01 21:33:10 before anything Dec 01 21:33:12 <[Rui]> ok Dec 01 21:33:19 bitbake -c clean -b yourbbfile Dec 01 21:33:22 <[Rui]> I will try to hit the brick wall a few more times :) Dec 01 21:33:24 this will clean everything Dec 01 21:33:34 then bitbake -c mrproper -b yourbbfile will clean your file downloads too Dec 01 21:33:58 It may complain about the fact that your download is unsigned Dec 01 21:33:59 In this case Dec 01 21:34:05 There's a variable for that Dec 01 21:34:13 OE_ALLOW_INSECURE_DOWNLOADS=1 Dec 01 21:34:18 In conf/local.conf Dec 01 21:34:25 <[Rui]> I don't think it even tried. Dec 01 21:34:33 Then clean, and retry Dec 01 21:34:40 It'll give you an error if it doesn't manage to download the file Dec 01 21:34:43 <[Rui]> will it use my pgp keyring for it? because I have signed it Dec 01 21:34:52 Your pgp keyring for what? Dec 01 21:34:55 Signature of the download? Dec 01 21:35:22 ENABLE_BINARY_LOCALE_GENERATION = "0" Dec 01 21:35:22 <------- and that one to avoid spending half a lifetime building locales for 10,000,000 different locales. Dec 01 21:35:24 <[Rui]> Ainulindale: it complains about not having a do_clean Dec 01 21:35:36 Huh? Dec 01 21:35:41 Did you inherit autotools? Dec 01 21:35:58 (well anyway, it has a do_clean by default IIRC) Dec 01 21:36:16 <[Rui]> Ainulindale: I posted the signature alongside the package, so if it uses my gpg ring to verify the signature, it should find it, yes? Dec 01 21:36:23 [Rui]: it won't do that, no Dec 01 21:36:28 <[Rui]> oh, ok Dec 01 21:36:39 <[Rui]> yes it is inheriting autotools Dec 01 21:36:55 Well it should have a do_clean nonetheless Dec 01 21:37:08 Are you sure you typed bitbake -c clean -b path/to/the/bbfile.bb ? Dec 01 21:37:34 <[Rui]> yes. it complained it didn't have a do_clean task Dec 01 21:37:42 <[Rui]> listtasks indeed doesn't show a do_clean Dec 01 21:37:49 <[Rui]> do_build Dec 01 21:37:49 <[Rui]> do_showdata Dec 01 21:37:49 <[Rui]> do_listtasks Dec 01 21:37:53 <[Rui]> only these 3 Dec 01 21:37:57 please repaste your bb file Dec 01 21:38:24 <[Rui]> ERROR: Task do_clean does not exist for target omnewrotate Dec 01 21:38:32 your bb file plese =) Dec 01 21:38:35 oh and by the way Dec 01 21:38:43 DEPENDS on libframeworkd-glib is wrong Dec 01 21:38:45 You want a RDEPENDS Dec 01 21:38:47 (run time depends) Dec 01 21:38:58 <[Rui]> http://pastebin.com/d45b8b270 Dec 01 21:39:53 <[Rui]> runtime? don't I need it's presence to compile? Dec 01 21:40:07 You need it at runtime and at compilation Dec 01 21:40:32 mwester: any idea why he has no clean task? Dec 01 21:40:44 <[Rui]> Ainulindale: ok, I change the pastebin to include that change Dec 01 21:42:04 Just so you know Dec 01 21:42:11 here it went through everything and failed at install Dec 01 21:42:13 (same bb file) Dec 01 21:42:14 <[Rui]> Ainulindale: now I learned a bit more how to glue these things, I should probably try to do it all over from the start Dec 01 21:42:50 But as there's no autotools file in the tgz Dec 01 21:42:52 That's normal Dec 01 21:42:55 It didn't find configure Dec 01 21:42:57 Didn't find a makefile Dec 01 21:43:03 So it went through everything and failed at install Dec 01 21:43:09 The bb file is good for me [Rui] Dec 01 21:43:58 <[Rui]> Ainulindale: ok, but it didn't look like it even tried to download the file Dec 01 21:44:07 Well here it did Dec 01 21:44:12 So my guess is you did something wrong =) Dec 01 21:44:30 What do you mean by it didn't download the file? Stack? Dec 01 21:44:48 If it's complaining about checksums.ini, do as I told before Dec 01 21:44:51 <[Rui]> Ainulindale: you're probably right. I'm going to start all over from the beggining (preserving the bb file) Dec 01 21:44:59 <[Rui]> Ainulindale: thank you very much Dec 01 21:45:02 You're welcome Dec 01 21:45:15 Going to pop myself a beer and linger in my couch for a while Dec 01 21:45:19 Be back later :-) Dec 01 21:45:29 hehe Dec 01 21:45:48 alcoholic dictator;-) Dec 01 21:46:56 <[Rui]> Ainulindale: when I get this working properly, I'll be sure to send you a six pack of the nices portuguese blonde beer ;) Dec 01 21:47:00 <[Rui]> nicest Dec 01 21:54:25 <[Rui]> make setup'ing Dec 01 21:57:38 somebody know example of sending text message in cli-framework? Dec 01 21:58:42 dcordes: zhone has one? Dec 01 21:59:30 lindi-, I have no gui only cli-framework Dec 01 21:59:42 dcordes: read the zhone source Dec 01 21:59:45 dcordes: dbus_object.gsm_sim_iface.SendStoredMessage( index, reply_handler=self.cbSendReply, error_handler=self.cbSendError ) Dec 01 22:00:02 and before that dbus_object.gsm_sim_iface.StoreMessage( number, text, reply_handler=self.cbStoreReply, error_handler=self.cbStoreError ) Dec 01 22:00:52 ok thanks for that valuable hint Dec 01 22:01:14 dcordes: i send my SMS through my operator's web interface since that is gratis ;) Dec 01 22:03:57 lindi-, lucyk you Dec 01 22:05:45 I thank mjr for the shell script to talk to them using curl Dec 01 22:06:42 what do u think about Minimo? Dec 01 22:07:00 maybe fennec is better Dec 01 22:07:10 fennec=? Dec 01 22:10:04 found Dec 01 22:10:49 <[Rui]> bah, 1. wget Makefile; 2. make setup; 3. place build-env; 4. place local; 5. bitbake: same results as previously Dec 01 22:12:43 What does "place" mean? Dec 01 22:13:34 mwester, where? Dec 01 22:14:00 ah oops Dec 01 22:14:03 4. Dec 01 22:14:23 1. wget Makefile 2. make setup 3. make update 4. make fso-console-image .... let it get started and run for a while, you need that cross dev env built anyway. Dec 01 22:16:02 I'm sleeping on the keyboard :D c ya next time Dec 01 22:17:12 <[Rui]> mwester: just copy it into /opt/openmoko Dec 01 22:17:31 any copying will break the structure. Dec 01 22:17:38 <[Rui]> http://pastebin.com/d24d451c1 Dec 01 22:18:16 you need to start by getting a basic, standard, unmodified, completely normal OE build going. then you can start customizing. Dec 01 22:18:51 <[Rui]> mwester: oh, I did that, then stopped after almost 24h of yet unfinished build :) Dec 01 22:19:34 So don't copy anything -- just follow the standard procedure, so that you get the smallest possible image built, that will ensure you have the cross tools and the base libs, etc, and then you can start on adding your stuff. And yes, it takes a long time to build it all (about 8 hours on a dual-core 2GB RAM 2.6 GHz P4). Dec 01 22:19:39 <[Rui]> I don't call this customizing, I call this making it work Dec 01 22:20:29 Hmmm. It works for everyone else who just follows the standard procedure, it breaks for you when you copy things about, but that's making it "work"? Dec 01 22:20:35 <[Rui]> mwester: ok, making fso-console-image Dec 01 22:20:57 <[Rui]> mwester: build-env is *only* pointing out the stuff needed to build the package Dec 01 22:21:49 <[Rui]> but right now the only change that is in effect is sudo sysctl -w vm.mmap_min_addr=0 Dec 01 22:21:53 <[Rui]> which is needed anyway Dec 01 22:22:28 <[Rui]> mwester: oh noes... I don't want to waste time building for gta-01 right now Dec 01 22:22:41 Yeah, change that. Dec 01 22:23:09 I guess that's the default then? Dec 01 22:24:08 <[Rui]> mwester: change where? Dec 01 22:24:42 <[Rui]> openembedded/conf/bitbake.conf ? Dec 01 22:24:59 <[Rui]> nopes, that mustn't be it Dec 01 22:25:16 There's a make target you can execute that will change that setting for you. Or you can edit one of the config files in your build/conf directory IIRC. Dec 01 22:25:58 Don't edit anything beneath openemebedded. All normal settings should be done in your conf directory, usually in the build directory. Dec 01 22:26:14 * [Rui] nods Dec 01 22:26:21 <[Rui]> build doesn't exist though Dec 01 22:27:11 Might be named "fso" -- it will contain the conf directory and a "tmp" directory Dec 01 22:28:01 <[Rui]> I see fso-console and fso-milestone4 Dec 01 22:28:26 <[Rui]> which have a local.conf but it only includes something else Dec 01 22:29:16 Look for "auto.conf" Dec 01 22:31:40 <[Rui]> mwester: aha, fso-console has gta01 Dec 01 22:31:48 mickey|flu|zzZZz, ping? Dec 01 22:33:52 <[Rui]> mwester: I'm typing this all down so maybe other newcomer's will have a cut & paste recipe Dec 01 22:34:39 Well, if you're going to put it on the wiki, the *right* way should be published there -- there's a "make something-or-other" command that is used to switch between the gta01 and gta02 targets. Dec 01 22:34:49 <[Rui]> GAH it's even worse than that. Dec 01 22:34:54 <[Rui]> sed -i -e 's/^MACHINE[[:space:]]*=[[:space:]]*\".*\"/MACHINE = \"om-gta01\"/' conf/auto.conf Dec 01 22:35:08 <[Rui]> I need to find what that one is Dec 01 22:35:18 <[Rui]> whatever I change will be changed back by that sed -i Dec 01 22:35:27 do you not have a conf/auto.conf file anywhere then? Dec 01 22:35:38 That's where that rule is changing the value. Dec 01 22:37:05 <[Rui]> mwester: I do, I do, but make fso-console-image changes the value back into gta-01 Dec 01 22:37:22 <[Rui]> that sed there replaces MACHINE = " fubar " with MACHINE = "om-gta01" Dec 01 22:37:25 <[Rui]> bummer Dec 01 22:41:22 heh! ok, that's not nice. Must be new changes then. Frankly, don't worry about it. It'll build both, but the delta in time to build the second one is very small (a new kernel and a couple of tiny device-specific packages). Dec 01 22:43:02 But if it really bothers you, just edit the makefile to remove the "( cd fso-$* ; \ ${MAKE} setup-.... ${MAKE} -k image )" bit for the gta01 for the target you desire to build. Dec 01 22:45:20 <[Rui]> mwester: if the difference is only that... I'll be sleeping anyway, so... Dec 01 22:45:31 <[Rui]> I just hope it's done by the morning when I have to take the laptop home Dec 01 22:45:35 <[Rui]> s/home/work/ Dec 01 22:46:01 ooh. laptop? dual core? Dec 01 22:49:15 <[Rui]> mwester: AMD Turion(tm) 64 X2 Mobile Technology TL-60 with 2GB of RAM Dec 01 22:50:44 nice. hopefully it has good cooling, the build will give it a good workout. :) Dec 01 23:19:13 <[Rui]> mwester: sure hope so :) Dec 01 23:19:22 <[Rui]> mwester: good night and thanks Dec 02 02:14:28 jhdsfdand have a pleasant tomorrow **** ENDING LOGGING AT Tue Dec 02 02:59:57 2008