**** BEGIN LOGGING AT Sat Jan 07 02:59:57 2012 Jan 07 08:29:22 moinmoin Jan 07 08:29:33 mrmoku: i'll work on the sharing plugin today Jan 07 08:36:15 moin mickeyl, cool Jan 07 08:36:55 TAsn: yeah, found it in eina Jan 07 08:43:10 hmm... what's that: http://dev.3v1n0.net/gitweb/cornucopia.git/commit/b2f9bb696f80c5f2cf3edf155927b371acad7b96 Jan 07 08:43:16 fsopimd... Jan 07 08:44:40 hmm... diving into libnl again and realizing why it's so cumbersome Jan 07 08:44:47 it's so underdocumented, it hurts Jan 07 08:50:57 heh Jan 07 08:51:43 trevinho working on fsopimd... interesting Jan 07 09:05:17 hmm Jan 07 09:05:26 * mickeyl discovers getifaddrs(3) Jan 07 09:08:55 in earlier times we used ioctls to configure the network, may someone remind me why the hotness went to netlink sockets instead? Jan 07 09:44:38 mickeyl: i think ioctls are not flexible and are hard to use (e.g. for passing an array of structs) comparing to netlink. Jan 07 09:44:51 And are harder to extend etc. Jan 07 09:46:10 It's like you'd be asking why use dbus when there's shared memory and semaphores ;) Jan 07 09:48:09 freesmartphone.org: 03mickey 07cornucopia * r6dd8ccb009ac 10/misc/ (README tests/Makefile.am tests/testlinux.vala): misc: add file for testing various aspects of linux.vapi Jan 07 09:48:22 PaulFertser: :) Jan 07 09:48:23 ok, thanks Jan 07 09:48:26 i understand that Jan 07 09:48:49 sysv ipc... oh the good times ;) Jan 07 10:26:33 hi JaMa|Wrk Jan 07 10:28:26 hi mickeyl Jan 07 10:28:44 working on a saturday? Jan 07 10:29:02 yeah :/ Jan 07 10:29:21 working weekends for last 3 months or so.. Jan 07 10:29:29 oh, bummer Jan 07 10:31:54 indeed, at least I don't have to stay 8hours :) Jan 07 10:32:04 4-6hours/day suits me much more Jan 07 10:32:57 heh, right Jan 07 10:33:06 same here Jan 07 10:33:46 SHR: 03mok 07libphone-ui-shr * r6c8163502391 10/src/view/contact-list-common.c: contact-list-common: disable multiselect for now Jan 07 10:33:51 SHR: 03mok 07libphone-ui-shr * rded3da7cec12 10/src/view/contact-list-view.c: contact-list-view: make the ctxpopup work correctly Jan 07 10:35:31 SHR: 03Martin.Jansa 07shr-chroot * r0bfd200220a5 10/ (1548 files in 71 dirs): system upgrade Jan 07 10:44:16 SHR: 03mok 07libphone-ui-shr * r6c8163502391 10/src/view/contact-list-common.c: contact-list-common: disable multiselect for now Jan 07 10:44:20 SHR: 03Martin.Jansa 07libphone-ui-shr * rbd9bc19995ba 10/src/view/quick-settings-view.c: quick-settings-view: adapt to new hoversel API Jan 07 10:44:24 SHR: 03Martin.Jansa 07libphone-ui-shr * rbf10534dbf79 10/src/view/ (phone-log-view.c quick-settings-view.c): adapt to ELM toolbar API change Jan 07 10:44:24 SHR: 03mok 07libphone-ui-shr * rded3da7cec12 10/src/view/contact-list-view.c: contact-list-view: make the ctxpopup work correctly Jan 07 10:44:26 SHR: 03Martin.Jansa 07libphone-ui-shr * r82b017ddd11b 10/src/util/ (ui-utils-contacts.c ui-utils.c): adapt to elm_list API changes from r66796 Jan 07 10:50:39 btw 017 feed still building Jan 07 10:50:47 mrmoku: do you want this bumped fro 017? ^ Jan 07 10:52:02 JaMa|Wrk: would be nice Jan 07 10:52:05 JaMa|Wrk: EFL bump ahead? Jan 07 10:52:23 or is that in some branch of yours? Jan 07 10:52:35 mrmoku: it's in my branch, but fwiw I promised no EFL bump before release Jan 07 10:52:48 mrmoku: yes those commits are only in efl branch of libphone-ui-shr Jan 07 10:52:57 ok :) Jan 07 10:52:58 and jansa/test branches in OE Jan 07 10:53:10 great :) Jan 07 10:53:24 * mrmoku will fix the UI dialogs next Jan 07 10:53:56 JaMa|Wrk: btw. what is aclocal-copy for and why do I have to rm -rf it manually for libphone-ui-shr local builds? any idea? Jan 07 10:53:57 ah problem with bump is that images are already created for some machines :/ Jan 07 10:54:08 nah, tehn for the next staging Jan 07 10:54:22 qt was bumped again so still building feeds :/ Jan 07 10:54:53 mrmoku: rm -rf to make your local dir clean or between each build? Jan 07 10:55:06 JaMa|Wrk: between each build :/ Jan 07 10:55:26 if I forget I get some strange MKINSTALLDIRS error Jan 07 10:55:37 during do_install right? Jan 07 10:55:40 yup Jan 07 10:55:52 seen it here too, not sure about proper fix Jan 07 10:55:56 ok Jan 07 14:50:58 SHR: 03lukasmaerdian 07meta-smartphone * r3fbfffe30426 10/meta-openmoko/recipes-kernel/linux/ (linux-gta04/defconfig linux-gta04_git.bb): meta-openmoko: gta04: switch to neil's 3.2-gta04 stable branch Jan 07 17:37:54 TAsn: gah, this elm stuff is driving me mad Jan 07 17:38:40 TAsn: trying for some hour now to find out why our inwin dialogs are mostly sized and positioned wrong :/ Jan 07 17:43:39 Random nice pic: http://cs303909.vkontakte.ru/u3803862/46423668/x_d4be5066.jpg Jan 07 17:45:53 * angelox|laptop does not get it :( Jan 07 17:47:32 angelox|laptop: Led Zeppelin rocks, and knowing how to play some of their songs helps with other important matters too :) Jan 07 17:48:10 hahah good one Jan 07 17:48:37 PaulFertser: ah ok, understood, i didn't get it because the actual cultural condition of music in Brazil. You have no idea of the shit it is now Jan 07 17:48:45 I'd start learning some Led Zepelin song then ;) Jan 07 17:49:30 pespin: just do not play Black Dog to a big-legged woman ;) Jan 07 17:49:42 angelox|laptop, like the song ai se eu te pego? lol Jan 07 17:50:18 I'm actually discovering nice music from brazil these days, mostly bossa nova like Jan 07 17:50:23 pespin: yeah, that is bad stuff, but not so bad like the 'Rio Funk' Jan 07 17:50:37 pespin: bossa nova and mpb are old musical style that were REALLY GREAT Jan 07 17:50:48 PaulFertser, I'll listen to it first hehe Jan 07 17:51:01 mpb? Jan 07 17:51:06 pespin: read the lyrics too. Truly shocking ;) Jan 07 17:51:30 PaulFertser: I know a lot of music from Led Zeppelin, Black Dog hard to play lol Jan 07 17:51:40 I'm trying to lern a bit of bossa nova these days, but the harmony is quite complex :) Jan 07 17:52:00 pespin: MPB = Musica Popular Brasileira, sth like: Brazillian Popular Music ;D Jan 07 17:52:31 pespin: of course, a lot more hard than rock ;) Jan 07 17:52:32 yep, I understand portguese more a less :) (I speak catalan and spanish which are similar) Jan 07 17:53:45 yes, there are some words in Portuguese that are almost same in English, that made easier to learn english for me Jan 07 17:54:47 e.g.: Film - Filme ; Personal - Pessoal; Photo - Foto Jan 07 17:54:53 and a lot more i don't remember :D Jan 07 17:55:52 mrmoku, for some reason, lately people started doing irresponsible changes and breaking stuff. :( Jan 07 17:55:55 mrmoku, I'm really sorry. Jan 07 17:56:03 mrmoku, please send a mail to edevel and I'll back you up. Jan 07 17:56:11 my colleague finished writing a test suite Jan 07 17:56:13 hopefully Jan 07 17:56:17 we'll start using it Jan 07 17:56:21 TAsn, stop apoligizing and fix genlist! :P Jan 07 17:56:27 genlist? Jan 07 17:56:54 yeah, just read on #edevelop what me and other people are saying since about 3 days ago :) Jan 07 17:57:49 pespin: lol, that was a nice one! Jan 07 17:57:53 TAsn: hey hey :) Jan 07 17:58:20 PaulFertser, long time. ;P Jan 07 17:58:29 PaulFertser, sup? Jan 07 17:58:36 TAsn: how's it going, enjoying your new job? ;) Jan 07 17:59:02 pespin, bah, it's broken in many ways, not sure which break you are referring to. :P Jan 07 17:59:17 PaulFertser, old job, I'm there for more than 1.5 years now. :) Jan 07 17:59:42 TAsn, using inserted_sort after having called genlist_item_del() before, makes my app segfault Jan 07 17:59:48 TAsn: i'm damn fine, thanks. Just not much time on FR. Though i'm still not that fancy about FSO, probably that's a better explanation. Jan 07 18:00:10 pespin, omg, I'm sorrry to hear. :* Jan 07 18:00:22 and I pray for having naviframe fixed before apocalypse day :P Jan 07 18:00:25 TAsn: are you hacking on E for 1.5 years already? Man, the time is mad fast sometimes. Jan 07 18:00:34 Fluent even Jan 07 18:00:38 I'm hacking on e for more than that even Jan 07 18:00:42 I'm doing it as a job Jan 07 18:00:45 for 1.5 years Jan 07 18:00:46 :) Jan 07 18:01:30 PaulFertser, ah, so whato do you do nowadays? (if not fr) Jan 07 18:03:27 btw, heads up: I'm out in 5-7 minutes. :) Jan 07 18:04:03 TAsn: i'm still using FR as a daily phone though. Not actively involved in anything, though i gained quite some OpenWrt experience, hacking on barebox+kernel+OpenWrt on i.MX at work, and stm32 etc. Jan 07 18:05:04 openwrt is awesome, just bought my first supported router a couple of months ago and installed tomato on it Jan 07 18:05:07 it really changed my life Jan 07 18:05:07 :) Jan 07 18:05:17 PaulFertser, what's barebox? Jan 07 18:06:07 TAsn: u-boot reimplemented from scratch by passionate Linux kernel devs :) Jan 07 18:06:39 isn't that's exactly what the other thing was? (forgot the other one's name) Jan 07 18:08:11 ok sry, gtg. Jan 07 18:08:20 concert Jan 07 18:08:23 later Jan 07 18:08:25 TAsn: enjoy! Jan 07 18:08:35 thanks. Jan 07 20:11:23 nschle85: pongping Jan 07 20:17:07 rah: pong pong ping :-) Jan 07 20:17:21 :-) Jan 07 20:17:27 nschle85: hello :-) Jan 07 20:17:34 nschle85: what was it you wanted me for? Jan 07 20:17:54 * mrmoku likes playing table-tennis too :) Jan 07 20:18:19 rah: http://shr-project.org/trac/wiki/Building%20SHR%20quickly Jan 07 20:18:41 nschle85|2: aye, that was me Jan 07 20:19:17 the idea to make a simplier description is very good but... Jan 07 20:19:47 mrmoku, hey, did you start the work to move the dbus vapis from telepathy to a new lib? Jan 07 20:19:58 pespin: hah, no Jan 07 20:20:04 I was just thinking it would be nice to have once we start doing the fso telepathy daemon Jan 07 20:20:13 pespin: tp works are delayed way after release Jan 07 20:20:20 i think we should delete outdated and wrong information instead of creating new wiki pages Jan 07 20:20:33 mrmoku, ok, seems fair :) Jan 07 20:20:42 pespin: but feel free to start something :-) Jan 07 20:20:53 I may once I finish exams the 18th Jan 07 20:21:02 then I have holidays till 12th feb I think hehe Jan 07 20:21:07 gah, everybody busy doing exams ;) Jan 07 20:21:09 rah: you page contains new information, like: shr from scratch :-) Jan 07 20:21:23 today it's pub time though hehe Jan 07 20:21:30 hah Jan 07 20:21:31 rah: but your description is not the fastest and is incomplete Jan 07 20:21:50 nschle85|2: yes, I realise the other instructions should be cleaned Jan 07 20:22:27 rah: so can i merge your information in the shr build page ? Jan 07 20:22:34 nschle85|2: I just wanted to get up my instructions on non-chroot building so they didn't get lost Jan 07 20:22:37 I was thinking on doing the move while i wait for the efl fixes, as I'm having lots of weird bugs with etalk and i don't want to continue adding things till I get those fixed Jan 07 20:22:38 rah: and delete your page ? Jan 07 20:22:53 nschle85|2: yes, I'm happy if the information is merged with the normal build page, you can delete mine Jan 07 20:22:54 nschle85|2: yes, I'm happy if the information is merged with the normal build page, you can delete mine Jan 07 20:22:56 oops Jan 07 20:22:57 rah: the other page is not only chroot Jan 07 20:23:24 i am not using chroot and i update the other page Jan 07 20:23:31 ok Jan 07 20:23:39 rah: thank you :-) Jan 07 20:23:42 nschle85|2: are there faster and more complete instructions for non-chroot building? :-) Jan 07 20:23:59 let's see if I have time to finish updating the eflvala bindings Jan 07 20:24:11 rah: yes :-) Jan 07 20:24:30 but they are hidden between the other lines :-) Jan 07 20:24:31 at least elementary.vapi.. I don't think I'm updating other ones in the nearly future, too much work. Only on request Jan 07 20:24:35 hah Jan 07 20:24:37 ok :-) Jan 07 20:24:46 rah: i am using the Makefile way Jan 07 20:24:51 I see Jan 07 20:25:05 mrmoku, was you the one who requsted vapi files to write E modules? Jan 07 20:25:14 umm Jan 07 20:25:32 nschle85|2: what Makefile, one you've written? Jan 07 20:25:57 no the one JaMa is developing Jan 07 20:26:20 http://shr-project.org/trac/wiki/Building%20SHR#Beforebeginning Jan 07 20:27:42 you're using that but not setting up a chroot? Jan 07 20:28:09 yes Jan 07 20:28:49 i never used chroot Jan 07 20:29:29 hmm Jan 07 20:29:43 well, I wanted to avoid the Makefile Jan 07 20:29:57 rah: you can avoud Jan 07 20:29:58 on account of updates doing git reset --hard Jan 07 20:30:35 rah: thats i also do not like, but for inital setup its nice Jan 07 20:30:48 rah: so we should change the Makefile Jan 07 20:31:42 pespin: yeah, was talking about that Jan 07 20:32:02 pespin: no current need right now though Jan 07 20:32:08 just would be nice if that were possible Jan 07 20:32:11 I'll add those once I finish with elementary then Jan 07 20:32:18 good :) Jan 07 20:32:26 ahh, no I remember Jan 07 20:32:31 was telepathy related too Jan 07 20:32:32 rah: but anyway, your idea to have a short introduction how to build shr for newcomers i support Jan 07 20:32:40 to have a gadget for my voip app Jan 07 20:32:52 but as that's delayed into somewhere in the future... Jan 07 20:32:54 nschle85|2: I'm not sure I agree with just changing the Makefile Jan 07 20:32:55 take your time :-) Jan 07 20:33:00 ok :) Jan 07 20:33:17 rah: why ? Jan 07 20:33:30 nschle85|2: as it is, I would like to have a set of instructions for setting up an shr-core build Jan 07 20:33:33 btw, autosuspend is not working by default, I guess that's wrong behaviour Jan 07 20:33:50 nschle85|2: I have that in the script (it's essentially just a shell script) I put on the wiki Jan 07 20:34:06 nschle85|2: you're arguing to replace that with an updated Makefile Jan 07 20:34:48 nschle85|2: if that short, simple script was converted to a Makefile, it would be nothing like the existing Makefile Jan 07 20:35:08 nschle85|2: in which case, I cannot see the value of making it into a Makefile instead of just a script Jan 07 20:36:27 rah: no, there is a misunderstanding Jan 07 20:37:05 rah: the makefile does already what you are doing describing in wiki Jan 07 20:37:37 rah: but make update always overwrites local changes, this is what i wanted to have changed Jan 07 20:39:11 nschle85|2: it does more than what is in the wiki; it creates stamp files Jan 07 20:39:34 nschle85|2: it's also significantly more complex Jan 07 20:39:52 what are stamp files for ? Jan 07 20:40:28 eg: Jan 07 20:40:31 setup-openembedded openembedded/.git/config: Jan 07 20:40:32 ... Jan 07 20:40:41 touch openembedded/.git/config Jan 07 20:42:30 rah: cannot find touch... in your wiki page Jan 07 20:43:11 nschle85|2: misunderstanding here; the Makefile does more than what's in my wiki page; the Makefile creates stamp files Jan 07 20:43:50 rah: is that bad ? i never cared (or now) about Jan 07 20:44:09 nschle85|2: I don't like it Jan 07 20:44:16 why ? Jan 07 20:44:48 it's messy and seems to be unnecessary Jan 07 20:44:58 nschle85|2: in fact, I dislike it so much that I stopped using the Makefile and created a wiki page containing instructions on how to build shr-core without it :-) Jan 07 20:49:21 nschle85|2: the Makefile will not work properly unless you use it from the start, and it controls your build tree (ie, unless it scatters its stamp files everywhere) Jan 07 20:49:26 I don't like that Jan 07 20:53:56 rah: so you should talk to JaMa what can be improved Jan 07 20:54:21 rah: are yiu subsribed to shr-devel ML ? Jan 07 20:54:31 nschle85|2: I am, yes Jan 07 20:54:31 you Jan 07 20:54:50 have you got my mail about wiki cleanup ? Jan 07 20:54:54 I did Jan 07 20:55:09 hmm what should we do ? Jan 07 20:56:08 I see three sets of instructions: building with chroot, building with Makefile but without chroot, building without chroot and without Makefile Jan 07 20:57:00 perhaps the building page needs to explain the basic principles (OE, bitbake, etc), explain that there are three different methods, what their advantages/disadvantages are, and then link to separate pages containing the actual instructions? Jan 07 20:58:34 rah: what should building with shr-chroot about ? with or without Makefile ? Jan 07 20:59:36 nschle85: I would say with Makefile Jan 07 20:59:40 nschle85|2: (I don't think it makes much sense to try and build shr-chroot without the Makefile) Jan 07 21:00:10 ? why ? Jan 07 21:00:49 chroot is a well defined build environment its independent of makefile Jan 07 21:01:29 so we should distinguish between host and how to build Jan 07 21:01:30 shr-chroot creates 1000x more files than the Makefile so if you're not worried about those, I doubt you'd worry about the extra stuff brought in by the Makefile :-) Jan 07 21:02:22 rah: chroot is only a build environment Jan 07 21:03:46 rah: ok we should do the following: Jan 07 21:04:01 nschle85|2: if that's the case, then the shr-chroot rules should be separated into its own Makefile Jan 07 21:05:42 rah: hmm, its hard to argument, but the makefile works well in chroot and non-chroot Jan 07 21:06:15 rah: so chroot is additional stuff in makefile Jan 07 21:07:03 rah: so it can be separated or not .... Jan 07 21:07:42 rah: it would me made things more complicated (download 2 makefiles) Jan 07 21:08:22 rah: hmm.. how can we get to a consense ? Jan 07 21:09:33 nschle85: the shr-chroot makefile could be told to download the build makefile automatically Jan 07 21:09:41 so the user would still only download one makefile Jan 07 21:10:30 the only issue is there would be two separate makefiles to maintain, but really that should be the case if they're two independent aspects of the system Jan 07 21:10:50 rah: can you please merge your page into build shr page ? i propose: manually setup shr build from scratch Jan 07 21:11:22 me? Jan 07 21:11:24 oh man Jan 07 21:11:31 I thought someone was going to do it :-) Jan 07 21:11:41 err.. someone *else* :-) Jan 07 21:11:54 rah: i can do it :-) Jan 07 21:12:23 nschle85|2: nice one :-) Jan 07 21:13:21 rah: so my intention was not to talk about how to build shr, i wanted to clean up and simplify the wiki Jan 07 21:13:35 aye Jan 07 21:13:56 nschle85|2: if you're taking on the rest of the wiki cleanup, it makes more sense for you to it really; if it's only one person, they'll do it consistently, which means neatly :-) Jan 07 21:15:27 rah: pardon, my english is not very good, so what you wanted to tell me ? Jan 07 21:16:22 nschle85|2: it's good if one person does the wiki clean up because there will only be one style Jan 07 21:18:43 rah: ok i understand, but style is not the question, content is more important here so everybody can change here :-) Jan 07 21:20:23 rah: ill change the page, afterwards we can talk about it, btw your input was very important for me. Jan 07 21:22:41 nschle85: cool Jan 07 21:22:44 nschle85: np :-) Jan 07 21:23:05 np ? null pointer ? Jan 07 21:24:23 heh Jan 07 21:24:24 np == 'no problem' :-) Jan 07 21:25:05 ah, ok saved ... Jan 07 21:26:48 rah: before i merge there are some parts like emacs conf/local.conf do you have any content for that ? Jan 07 21:30:14 nschle85|2: not really, just "edit as directed by comments" I guess Jan 07 21:30:43 ok Jan 07 21:33:54 rah do you see any other hotspots in wiki we should clean up ? Jan 07 21:41:27 nschle85|2: IMHO, it would be good if the device-specific pages all followed the same format and contained similar information Jan 07 21:42:03 nschle85|2: not just the installation instructions Jan 07 21:42:30 nschle85|2: but that's probably a pretty big job; I imagine you would have to talk to lots of devs for different devices Jan 07 21:42:54 rah: i agree, but installation instructions are very important, so i f they where uptodate it would be nice :-) Jan 07 21:43:05 nschle85|2: yes, indeed Jan 07 21:43:49 perhaps it would be enough to have a template device information page, and ask whoever edits device pages to follow the template Jan 07 21:44:48 hmm, but as ik can the the template will not give enough format Jan 07 21:45:24 the installation instructions for gta02 and n900 are differing very lot Jan 07 21:46:19 rah: please give me some minutes to merge your information Jan 07 21:46:40 ok Jan 07 21:59:20 rah: ok merged Jan 07 22:00:21 nschle85|2: cool Jan 07 22:00:51 now we can discuss about structure of http://shr-project.org/trac/wiki/Building%20SHR Jan 07 22:02:06 :-) Jan 07 22:02:26 well, unfortunately it's nearly time for me to do to bed :-) Jan 07 22:02:30 s/do/go/ Jan 07 22:02:31 rah meant: well, unfortunately it's nearly time for me to go to bed :-) Jan 07 22:04:12 rah: +ap i do understand :-) Jan 07 22:05:26 rah: sweet dreams... Jan 07 22:05:30 bye Jan 07 22:05:36 g'night Jan 07 22:05:57 rah: do you agree with my merge ? Jan 07 22:06:08 (last question) Jan 07 22:06:33 nschle85|2: looks ok yes :-) Jan 07 23:09:15 good night bye Jan 07 23:13:41 hi mrmoku Jan 07 23:47:32 hi mickeyl Jan 07 23:49:34 hi Jan 07 23:55:36 mickeyl, I've logs for you Jan 07 23:56:34 mickeyl, when the modem doesn't want to hangup.... Jan 07 23:56:40 do you want them Jan 07 23:56:44 sure Jan 07 23:56:47 or are the infos on the gta04 ml enough? Jan 07 23:56:48 which modem? Jan 07 23:56:49 ok Jan 07 23:56:54 option from gta04 Jan 07 23:56:58 k Jan 07 23:58:31 http://gnutoo.homelinux.org/downloads/people/mickeyl/logs.tar.bz2 Jan 07 23:58:45 I've included all logs but I guess you want only fsogsmd Jan 07 23:59:12 are you suscribed to gta04-owner? Jan 08 00:00:10 ah yes right you are Jan 08 00:00:13 since you posted there Jan 08 00:01:31 can't see a problem on first glance Jan 08 00:02:34 ah, i think i know what you mean Jan 08 00:02:57 was your battery charged? Jan 08 00:03:16 that doesn't look like a problem in fsogsmd. we don't get any more responses from the modem Jan 08 00:05:28 ah ok Jan 08 00:05:36 modem continue to respond Jan 08 00:05:45 the +VTS=2 seems to timeout and then we're lost Jan 08 00:05:46 because I still have sound Jan 08 00:06:08 and battery indicate 100% Jan 08 00:06:15 and I've an USB cable attached Jan 08 00:06:23 if you ever see that behaviour again, it would be interesting to stop fsogsmd and try to connect via mterm2 (or anything else) to the modem on the same serial node and check whether it responds Jan 08 00:06:26 but maybe the battery is not good either Jan 08 00:06:36 I can do it now Jan 08 00:06:43 I't still not hanged up Jan 08 00:07:03 good. do that, don't kill -9, but just send SIGSTOP to fsogsmd so that it doesn't try to cleanup Jan 08 00:07:09 then use the same node fsogsmd uses Jan 08 00:07:15 because only one channel my have hung up Jan 08 00:07:36 so I kill fsogsmd but not -9 Jan 08 00:08:51 ya, 19 or os Jan 08 00:08:52 so Jan 08 00:08:57 yes right Jan 08 00:09:02 19 according to htop Jan 08 00:10:02 it doesn't kill it.... Jan 08 00:10:11 yes, correct Jan 08 00:10:17 SIGSTOP doesn't kill, but STOP Jan 08 00:10:23 which is what it's supposed to do Jan 08 00:10:39 ok anyway I'll pastebin new logs then Jan 08 00:10:52 which are the same than before but go until the sigstop and after Jan 08 00:13:12 http://gnutoo.homelinux.org/downloads/people/mickeyl/fsogsmd.log Jan 08 00:13:18 maybe I should have compressed it Jan 08 00:13:46 note that I've done sigstop more than once Jan 08 00:13:54 because it didn't do what I expected Jan 08 00:14:32 it should just halt the process and not eat any further input from the serial node Jan 08 00:14:39 so that you can connect with another process Jan 08 00:14:41 and have a look Jan 08 00:14:42 ok Jan 08 00:14:46 then I do mickeyterm Jan 08 00:15:18 you need to wait until you get the hang again though Jan 08 00:15:24 otherwise you can't reproduce the same situation Jan 08 00:15:41 ah it's not hanged anymore? Jan 08 00:16:10 at least the GUI is still hanged and mdbus2 too Jan 08 00:17:02 mdbus2 -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Call.ReleaseAll hangs Jan 08 00:18:22 I can AT tough Jan 08 00:18:29 with picocom Jan 08 00:19:02 it responds to other commands Jan 08 00:19:06 AT+CPBR=? Jan 08 00:20:10 same serial node? Jan 08 00:21:46 yes Jan 08 00:21:50 ttyHS3 Jan 08 00:22:00 same than in the fsogsmd.conf Jan 08 00:22:18 hmm, ok, then we need to take a look whether fsogsmd correctly deals with timeouts Jan 08 00:22:39 http://www.pastie.org/3145892 Jan 08 00:22:44 should I restart fsogsmd? Jan 08 00:22:55 like with sigstart if that exists Jan 08 00:24:40 in that case it would be a SIGCONT Jan 08 00:27:28 good night guys Jan 08 00:27:33 good night Jan 08 00:29:40 mickeyl, I guess using documented non-AT protocols would be too hard for us Jan 08 00:29:52 apart if we get morphis on board Jan 08 00:30:02 I mean it would end up like n900 Jan 08 00:30:16 everything is documented, but no one works on it Jan 08 00:31:36 I fear that after the initial wow-boost gta04 get in the same state with very few people like me working on it.... Jan 08 00:32:03 only time will tell Jan 08 00:32:15 but i think chances are good Jan 08 00:32:35 chances were huge with n900 and we missed it Jan 08 00:32:51 standard kernel, many people having the device etc... Jan 08 00:33:03 and somewhat documented isi protocol Jan 08 00:33:10 many people having the device did not count Jan 08 00:33:16 only few people actually working Jan 08 00:33:39 04 already looks much better than the 900, doesn't it? Jan 08 00:33:41 I mean many people like dos1 for instance are SHR devs and got a device from nokia Jan 08 00:33:56 it's like comparing oranges and apples Jan 08 00:34:07 gta04 is not ready under SHR Jan 08 00:34:23 no? what's missing? Jan 08 00:34:33 mainly forwarding Jan 08 00:34:35 for audio Jan 08 00:34:49 then better fsodeviced plugin Jan 08 00:34:56 that handle ifconfig+rfkill Jan 08 00:35:10 then better AT modem handling Jan 08 00:35:15 sounds little compared to the 900 issues Jan 08 00:35:16 to me Jan 08 00:35:22 ah? Jan 08 00:35:41 it's subjective, but with the 04 i don't feel i'm doing something against the vendor Jan 08 00:35:43 and audio scenarios Jan 08 00:35:44 that's more motivating Jan 08 00:35:50 at least for me Jan 08 00:35:53 ok Jan 08 00:36:08 there are no hidden nightmares except hardware bugs :) Jan 08 00:36:13 indeed Jan 08 00:36:29 and since I got it for free and that it costs a lot etc... I *have to* work on it Jan 08 00:36:40 and I got the best version etc... Jan 08 00:36:57 but I can't do the AT part Jan 08 00:37:04 I know a bit AT Jan 08 00:37:24 i'll deal with the AT part, it might take a bit longer, since i have very few occasions, but i'll keep on Jan 08 00:37:25 but not up to the point of doing workarrounds for firmware bugs Jan 08 00:37:34 ok nice Jan 08 00:37:45 for forwarding there are many choices to be dones Jan 08 00:37:46 *done Jan 08 00:38:03 for instance do we use the code of alsaloop? (yes/no) Jan 08 00:38:04 if no: Jan 08 00:38:22 the forwarder I have works quite well Jan 08 00:38:28 with big buffers Jan 08 00:38:40 but it does some buffer underruns still Jan 08 00:38:45 specially at the beginning Jan 08 00:38:55 so the possibilities are: Jan 08 00:39:29 * rework the buffer management(unrelated to the buffer underrun problem but cleaner code) to use queues with semaphores (yes/no) Jan 08 00:39:39 or : Jan 08 00:39:49 * use the same buffer management Jan 08 00:39:52 or: Jan 08 00:40:07 * use a simplier approach with no external buffer Jan 08 00:40:32 and on top of that I've to solve the buffer underrun issue Jan 08 00:40:42 the sound is perfect Jan 08 00:40:47 but sometimes it's cut Jan 08 00:40:50 for too long Jan 08 00:40:55 like one second Jan 08 00:40:58 so you miss part Jan 08 00:41:04 I've just tried alsaloop Jan 08 00:41:12 here what it does: Jan 08 00:41:42 I ran that ( compiled with automatic detection of libsamplerate): Jan 08 00:41:43 ./alsaloop -P plug:dmix:0 -C plug:dsnoop:1 -S 0 Jan 08 00:41:56 at first it uses near 100% CPU Jan 08 00:42:01 oops wrong command Jan 08 00:42:25 ./alsaloop -P plughw:0 -C hw:1 -S 0 -f S16_LE -r 8000 -c 1 -t 1000000 Jan 08 00:42:34 because else it really uses too much CPU Jan 08 00:42:51 then I call Jan 08 00:42:59 and the CPU usage drops to 10% Jan 08 00:43:18 but no buffer underruns Jan 08 00:44:49 cool. why not just taking the code, stripping the command line parsing out, and making a nice library out of it and then plugging it into fsoaudiod? Jan 08 00:45:42 possible too Jan 08 00:45:50 that's what I meant by: Jan 08 00:45:53 for instance do we use the code of alsaloop? (yes/no) Jan 08 00:46:02 yeah, i'd vote for that Jan 08 00:46:07 might be less of a hassle Jan 08 00:46:16 less controls more quality Jan 08 00:46:23 *less control Jan 08 00:46:29 (less customizable) Jan 08 00:46:42 what's the license of fsoaudiod? Jan 08 00:47:06 lgpl i guess like almost all our others Jan 08 00:47:21 is that compatible with GPLv2 or later? Jan 08 00:47:33 no Jan 08 00:47:36 ok Jan 08 00:47:38 we have to make it gpl then Jan 08 00:47:39 that's a problem then Jan 08 00:47:42 ok nice Jan 08 00:48:22 anyway you built cornucopia, you spent a lot of time on it etc...the community too Jan 08 00:48:36 we spent huge time fighting with anti-vendor port Jan 08 00:49:03 and it would be quite an irony to have a vendor use our stuff and put proprietary stuff for accessing the hardware Jan 08 00:49:25 ya, i have no problem with gpl Jan 08 00:49:26 so GPL is good and since it's over dbus there is no issue making an fso GUI proprietary Jan 08 00:49:33 we can use more existing code then Jan 08 00:49:37 *nod* Jan 08 00:49:48 but the hardware access should be GPL in my opinion Jan 08 00:50:07 (else maybe samsung could do bad stuff) Jan 08 00:50:53 who should do the forwarding then now Jan 08 00:51:02 I mean I'm not that good in vala Jan 08 00:51:12 I would have to do the vapi which I fear Jan 08 00:51:30 altough I know how to use extern in vala Jan 08 00:51:45 I could then do an extern for activation Jan 08 00:51:50 i can help you with the vapi. i guess it would be just a bunch of functions, like start/stop/process Jan 08 00:51:51 and an extern for deactivation Jan 08 00:52:02 and handle everything in C? Jan 08 00:52:19 but the best would be to pass many arguments to it Jan 08 00:52:29 and to make it configurable in fsoaudiod.conf Jan 08 00:52:33 ya. i would expect the alsaloop being roughly structured like that Jan 08 00:52:42 so it could be re-used for instance by antrik Jan 08 00:52:46 start takes all params and sets it up Jan 08 00:52:52 process is done regularly in a loop Jan 08 00:53:04 and stop on shutdown of the call Jan 08 00:53:26 but i have to go to bed now Jan 08 00:53:29 g'night Jan 08 00:53:38 thanks Jan 08 00:53:43 np, cu Jan 08 00:53:45 I'll try to sleep too at some point Jan 08 00:53:53 since I cannot work on audio the night Jan 08 00:54:19 it's not very good for me to stay too late but all the fests shifted me towards the night **** ENDING LOGGING AT Sun Jan 08 02:59:57 2012