**** BEGIN LOGGING AT Thu Jan 03 02:59:56 2008 Jan 03 05:12:01 * * OM Bug 1154 has been created by mail(AT)mmontour.net Jan 03 05:12:02 * * gsmd at 100% CPU (sigsegv-handling problem) Jan 03 05:12:03 * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1154 Jan 03 05:39:25 i am a lite confused, if I install what's indicated in this link : http://wiki.openmoko.org/wiki/How_to_run_OpenMoko_Apps_on_PC will I be able to run open moko on my PC? Jan 03 05:40:16 but in order to develope new tools, I must install Xoo . http://wiki.openmoko.org/wiki/Host-based_development_with_Xoo_and_Xephyr, is that correct? Jan 03 05:41:32 matux, yes; new tools? Xoo, Xephyr are for GUI Jan 03 05:43:14 sorry i meant new applications Jan 03 05:44:47 matux, sure; as long as you have the necessary libraries installed for your application Jan 03 07:18:24 my gps antenna broke where the wire is attached to the antenna (square thingy) Jan 03 07:18:52 Who can I contact to get a new one. I would try to solder it myself, but the wire is so damn small. Jan 03 08:35:28 mornin' Jan 03 08:36:48 moin Jan 03 09:13:22 openmoko: 03erin_yueh * r3760 10/trunk/src/target/gsm/ (5 files in 5 dirs): gsmd: add Call Forwarding function (Sean Chiang) Jan 03 10:09:57 Beep Jan 03 10:09:59 Anyone awake Jan 03 10:13:14 nope Jan 03 10:15:58 XorA: Sup Jan 03 10:16:21 I'm trying to debrick a GTA01BV4 Jan 03 10:16:38 derekcorwin: got debug board? Jan 03 10:16:44 Yes Jan 03 10:16:53 When I try to run openocd it gives me errors Jan 03 10:16:53 no probs then :-D Jan 03 10:17:13 just keep hitting reset then start openocd as fast as possible, eventually it should connect Jan 03 10:18:54 XorA: Jan 03 10:18:54 http://pastebin.com/m6f2e7110 Jan 03 10:19:13 The moko just has a black screen Jan 03 10:19:24 Your talking about the reset button on the debug board correct? Jan 03 10:19:28 yes Jan 03 10:19:47 Will the moko light up when it works? Jan 03 10:20:00 you didnt follow the wiki right, you forgot the (ft2232) with correct params Jan 03 10:21:00 You mean the kernel module with params? Jan 03 10:22:36 modprobe ftdi_sio vendor=0x1457 product=0x5118 Jan 03 10:27:06 XorA: Beep Jan 03 10:27:13 Been working on this for a bit need help Jan 03 10:28:07 and you dmesg shows debug board was recognised? Jan 03 10:30:46 Yes Jan 03 10:31:43 * XorA is stumped Jan 03 10:32:05 http://pastebin.com/m15a23737 Jan 03 10:33:09 XorA: There is some of the dmesg output Jan 03 10:33:55 [ 4471.440000] usb 1-1.4: device descriptor read/64, error -71 Jan 03 10:34:02 that is a busted USB device Jan 03 10:34:08 I assume that is the neo Jan 03 10:34:52 Could it be the debug board? Jan 03 10:35:19 no idea, I cant see what you plugged into your machine Jan 03 10:36:31 Damn Jan 03 10:52:18 FreeRunner ! Jan 03 10:53:32 :-) Jan 03 10:54:07 so it is March I guess Jan 03 11:25:24 hi Jan 03 11:26:37 anyone here who can give me a hand with a problem with one of my neos? Jan 03 11:29:56 don't know. What's it? Jan 03 11:30:07 I can't help with emotional problems. Jan 03 11:30:23 :) Jan 03 11:30:36 well the problem is my neo powers down during bootup Jan 03 11:30:48 unplug battery for 10 min Jan 03 11:30:56 (and usb) Jan 03 11:31:02 ok Jan 03 11:31:06 and this does what? Jan 03 11:31:15 replace battery, plug in USB, leave charging for 5 hours Jan 03 11:31:32 the battery managment at low battery levels is not great Jan 03 11:31:40 hmm Jan 03 11:31:53 it should work, if i just use another battery? Jan 03 11:31:58 probably, yes Jan 03 11:32:09 ok, i'll give it a try ... Jan 03 11:34:39 recharged battery - which works on another neo doesn't work Jan 03 11:34:47 i'll let it Jan 03 11:35:01 settle down and try the battery remove thingy Jan 03 11:36:41 power managment is unfortunately rudimentary Jan 03 11:36:51 :( Jan 03 11:36:54 and has bugs Jan 03 11:37:06 most software fixable hopefully Jan 03 11:37:15 good to hear Jan 03 11:37:34 strangely enough that does only happen for 1 of 3 neos Jan 03 13:28:29 is it very bad if i'm getting the $PGLOR,IGR sentence from the hammerhead? Jan 03 13:29:00 or does everyone get this before they have a fix? Jan 03 13:29:43 in the agps-ui sources $PGLOR,IGR is described as platform integration problem indication which doesn't sound very optimistic Jan 03 13:29:46 IIRC yes Jan 03 13:30:04 balrog-kun: I got this kind of frames too until I have a fix (I get $PGLOR,FIX after iirc) Jan 03 13:30:06 oh good Jan 03 13:30:16 I'm feeling horrible and finding out woild involve me getting out og bed Jan 03 13:30:16 rtp: great, thanks Jan 03 13:31:19 SpeedEvil: thanks either way, hope you get better :) Jan 03 13:31:35 I am slowly Jan 03 13:33:39 * balrog-kun wonders if it's possibly that my windows are so dirty that the gps saw no single satellite running for one hour indoor but at the window Jan 03 13:34:02 Especially igf they are energy saving ones, they may be coated so that you can't Jan 03 13:34:04 or are there real "platform intgration" problems Jan 03 13:34:27 energy saving windows? Jan 03 13:34:47 ones produced in the last 10-15 years or so Jan 03 13:34:55 they can have IR reflective coatings. Jan 03 13:35:02 my gps has been haning on the window for months without fix, all because the window is looking north Jan 03 13:35:08 oh yeah, they look modern Jan 03 13:35:21 IR reflective coatings can be moderately efficient shielding Jan 03 13:36:52 i'll try again with windows open when the neo charges enough to be able boot and run for a while Jan 03 13:37:16 * balrog-kun will resist the cold for the science sake Jan 03 13:39:52 does anyone have a gllin setup that is known to work, i.e. give correct coordinates, and a charged battery? Jan 03 13:41:44 balrog-kun: charging battery with gllin?? Jan 03 13:42:25 mine simply spits out the NMEA and does quite well doing so Jan 03 13:43:15 actually it gets a fix from a cold start in less than a minute under open skies, that is Jan 03 13:43:37 gamin: no, just a charged battery so that they can power the phone up right now Jan 03 13:44:34 balrog-kun: you need a tester? Jan 03 13:44:46 gamin: yes, for an alternative gllin setup Jan 03 13:45:44 that uses no oabi chroot Jan 03 13:46:40 Hi. I'm new to openmoko. Tried to build images with MokoMakefile, but got package error. Jan 03 13:47:07 NOTE: package openmoko-terminal2-2.1.1+svnr3542-r2: task do_fetch: failed Jan 03 13:47:33 !ombug 1152 Jan 03 13:47:34 * * Bug 1152, Status: RESOLVED (WORKSFORME), Created: Unknown Jan 03 13:47:35 * * thomas(AT)openedhand.com: openmoko-terminal2 is missing vala dependancy Jan 03 13:47:36 * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1152 Jan 03 13:47:40 alberto: ^^ Jan 03 13:47:45 Thanks! Jan 03 13:47:56 I'll look at it. Jan 03 13:48:33 oh, it fails in do_fetch, that may be a different problem then Jan 03 13:49:31 I'm trying to understand how to post the full log in celpaste ... Jan 03 13:49:50 http://celpaste.morb-design.com/pastebin.php?show=d7d6079a0 Jan 03 13:50:43 i got gllin running without the OABI chroot (thus saving lots of space) but i couldn't get a fix or even see a single satellite and i was wondering if my hack was breaking gllin Jan 03 13:51:08 seems unlikely but it would be nice if someone else could test it with a known working setup Jan 03 13:54:34 It looks like package terminal2 disappeared in http://downloads.openmoko.org/sources/ Jan 03 13:55:35 I tried with make update-makefile && make setup && make update Jan 03 13:55:44 make clean-package-terminal2 Jan 03 13:55:59 But i get the same error, package cannot be found. Jan 03 13:56:04 * balrog-kun estimates he could get the whole gllin package to under 1MB Jan 03 13:56:33 Is there another package repository I can tell MokoMakefile to search for ? Jan 03 14:04:26 if it works out it should also allow folks to run gllin with reduced priviledges Jan 03 14:04:30 i.e. non-root Jan 03 14:05:18 hello all Jan 03 14:05:27 hey Sup3rkiddo Jan 03 14:05:45 * Sup3rkiddo bows Jan 03 14:19:34 http://www.phoronix.com/scan.php?page=news_item&px=NjI2OQ Jan 03 14:19:35 :O Jan 03 14:19:46 how to fix this? Jan 03 14:19:46 ERROR: No providers of build target u-boot-openmoko (for []) Jan 03 14:20:23 HI. I got the same error. Is your related to missing package openmoko-terminal2-2.1.1+svnr3542-r2 ? Jan 03 14:22:19 torpor, can u post your output to pastebin or celpaste ? Jan 03 14:22:43 alberto: that is the output Jan 03 14:22:48 i get ERROR: No providers of build target u-boot-openmoko (for []) Jan 03 14:22:55 make openmoko-devel-image Jan 03 14:23:10 Sure, but the output is longer. Jan 03 14:23:44 no Jan 03 14:23:45 I have posted mine at http://celpaste.morb-design.com/pastebin.php?show=d7d6079a0 Jan 03 14:23:52 Have a look at it. Jan 03 14:25:40 The last 2 lines are yours ... Jan 03 14:36:24 update your OE tree Jan 03 14:39:59 Can anybody help with MokoMakefile compilation ? Jan 03 14:40:09 I tried the procedure Jan 03 14:40:20 make update-makefile && make setup update openmoko-devel-image Jan 03 14:40:39 but I get errors while fetching terminal2 package Jan 03 14:40:54 I posted the full output to http://celpaste.morb-design.com/pastebin.php?show=m216847d Jan 03 14:41:16 Is it due to bug 1152 fixing ? Jan 03 14:41:59 Is there a workaround ? Jan 03 14:42:12 hi Jan 03 14:42:25 tried updating MokoMakefile? Jan 03 14:42:35 Yes Jan 03 14:42:55 Indeed I run make update-makefile && make setup && make update Jan 03 14:42:57 ERROR: No providers of build target u-boot-openmoko means your OE tree is too old Jan 03 14:43:11 the name was changed last week or so... Jan 03 14:43:12 i have one dtupid question: how do i switch the lcd to 240*320 stretch mode? Jan 03 14:43:16 So I should start from scratch ? Jan 03 14:43:31 alberto: you should update your OE tree Jan 03 14:43:35 I started from scratch yesterday night (I mean new Makefile) Jan 03 14:43:40 alberto: make update Jan 03 14:43:55 done Jan 03 14:44:01 hmm Jan 03 14:44:10 shred: try playing with xrandr and fbset Jan 03 14:44:26 thx Jan 03 14:45:21 alberto: so you can try make update-bleeding-edge Jan 03 14:45:43 OK ... I'm trying .... Jan 03 14:56:11 when i click on the upper menu with gsm, bluetooth, etc symbols, all the symbols disappear. what is the reason? Jan 03 14:56:39 I think the applets crash Jan 03 14:56:40 Does anyone know if gps & bluetooth work from QTopia on the neo? Jan 03 14:57:23 if any bluetooth works, the bluetooth should wortk - it's a standard module connected via USB Jan 03 14:57:54 that makes sense Jan 03 14:58:01 only gotcha is the 'power on' toggle Jan 03 14:58:16 Are the /sys devices all the same in QTopia? Jan 03 14:58:26 I don't know what the kernel does Jan 03 14:58:29 NineX: I've done update-bleeding-edge. Jan 03 14:58:33 It seems they would be 'cause they're mounted... Jan 03 14:58:43 K, thanks Jan 03 14:58:45 Shall I just make the image ? Jan 03 14:59:02 wurp2: apparently people got the gps to work on qtopia Jan 03 14:59:33 someone posted a qtopia rootfs to the list tuned for gps Jan 03 14:59:53 balrog-kun: Thanks! I missed that post - do you remember what list it was posted to? Jan 03 15:00:23 alberto: yes make openmoko-devel-image Jan 03 15:00:33 wurp2: community, i've been browsing the january archive of the community list and i saw responses to this person's original posting there Jan 03 15:01:50 hey, I have a question about the hardware architecture of open moko. Is this the right place to ask the question? Jan 03 15:02:22 Sure. Jan 03 15:02:30 NineX: I still get the same error message: package openmoko-terminal2-2.1.1+svnr3542-r2: task do_fetch: failed Jan 03 15:02:37 open moko is not a hardware :) Jan 03 15:02:46 well - that too. Jan 03 15:02:54 Does the linux kernel run on the samsung apps processor and any proprietary code on the GSM modem processor? Jan 03 15:03:00 vick1: no Jan 03 15:03:05 vick1: there is only GSM code on that Jan 03 15:03:14 vick1: it's an AT modem Jan 03 15:03:21 conforming to normal standards Jan 03 15:03:23 Is the L4 micro kernel involved in the architecture? Jan 03 15:03:30 dunno Jan 03 15:03:30 sorry it was "Is there" Jan 03 15:03:52 in the modem's architecture? Jan 03 15:03:52 vick: no. you should look for qualcomm msm7x00 based like htc kaiser if you want l4 Jan 03 15:03:57 the GSM just appears as a modem, on a serial port of the CPU Jan 03 15:04:05 you cannot do anything else with it. Jan 03 15:04:05 ok Jan 03 15:04:24 (well, you can, but you'd have to convince TI to let you, which approches can't) Jan 03 15:04:28 i think they wouldn't use L4 for the kernel because they would have to release the sources then to comply with license Jan 03 15:04:40 balrog: NACK Jan 03 15:04:56 balrog: there are L4 variants under dual licensing Jan 03 15:05:02 I think is L4 microkernel source is freely available Jan 03 15:05:07 ok Jan 03 15:05:16 i see Jan 03 15:08:15 the other license being non-free? Jan 03 15:09:15 hi all Jan 03 15:09:49 did anyone notice a GPS outage around 6:20-7:00 am Eastern time this morning? Jan 03 15:10:04 PWizard: timezone? Jan 03 15:10:20 what's that, GMT-5 ? Jan 03 15:10:22 (I'm not US, so eastern doesn't help) Jan 03 15:10:31 cjb_ie, that's right Jan 03 15:10:33 GMT-5 Jan 03 15:10:59 Where are you? Jan 03 15:11:04 pw: Jan 03 15:11:05 ok, that was at night. it worked fine at 7:00 UTC Jan 03 15:11:33 North Carolina, but I observed an outage across ~80-100 devices up and down the eastern seaboard Jan 03 15:11:34 nah, that would've been noonish - about three hours ago, PWizard? Jan 03 15:11:45 not sure if it was an external issue or if I'm a shite coder Jan 03 15:11:52 GPS is _trivial_ to jam Jan 03 15:12:04 cjb_ie, yes, between 4 to 3 hours ago approx. Jan 03 15:12:13 checked NOTAM? Jan 03 15:12:16 pwi: Jan 03 15:12:20 SpeedEvil, what's NOTAM? Jan 03 15:12:31 Notice to Airmen Jan 03 15:12:48 basically 'gps will be at risk in these areas at these times' Jan 03 15:13:12 SpeedEvil, no I have not, googled it just now Jan 03 15:13:18 http://www.arpro.com/basics.php Jan 03 15:13:21 err Jan 03 15:13:26 http://www.fly-low.com/features02/gpsdenial.html Jan 03 15:14:35 what sort of outage? Jan 03 15:14:43 'I can't find a signal' Jan 03 15:14:49 position inaccuracy Jan 03 15:14:57 No fix, it appears Jan 03 15:15:19 do you have gpss that were not affected? Jan 03 15:15:29 SpeedEvil: it's no problem to jam gsm, gps if far easier Jan 03 15:15:48 so I agree, it's trivial Jan 03 15:15:54 I was unable to observe it directly, but the nature of the error generated implied that either the units could not obtain a fix or the gps device itself simply failed to generate data on the serial line that attaches it (USB USGlobalSat receivers) Jan 03 15:16:30 thomasg: no, it's much, much easier, in that wiht a few watt trasmitter, on a baloon you can wipe out most of a small country. Jan 03 15:17:02 the hemispherical per-satellite power is 50W Jan 03 15:17:22 Speedevil, one that I can identify, I'll see if it was active during the outage Jan 03 15:18:29 The locations of the units are approximately New Haven, Connecticut, Atlanta, Georgia, and Raleigh, NC Jan 03 15:18:36 SpeedEvil: yes, the gps signal is in a usual band without techical barriers and the signal strength is pretty weak Jan 03 15:19:05 Fortunately, intentional long-range jamming is rare. Jan 03 15:20:28 SpeedEvil, I don't think anything intentional was involved. More likely it was the result of atmospheric effects Jan 03 15:20:36 http://www.fly-low.com/features02/gpsdenial.html Jan 03 15:20:39 err Jan 03 15:20:45 http://www.navcen.uscg.gov/gps/status_and_outage_info.htm Jan 03 15:20:54 ionospheric effects don't really do that Jan 03 15:23:06 http://www.navcen.uscg.gov/gps/gpsnotices/GPS_Interference.pdf may be of more use Jan 03 15:23:47 is the USB port of the GTA02 powered? Jan 03 15:23:59 yes - low power as I understand it Jan 03 15:24:18 yeah, roh said it is powered Jan 03 15:24:39 SpeedEvil, yeah, none of that seems pertinent to my app, but is useful if we wind up deploying in those regions Jan 03 15:25:23 PWizard: is it a secret? Jan 03 15:25:47 SpeedEvil, what, my app? Jan 03 15:25:50 yes Jan 03 15:26:26 oh, FYI I was referred here from #mobitopia, on the basis that y'all would be knowledgable of GPS issues and probably faster to reply than the folks in #mobitopia. :) Jan 03 15:26:36 SpeedEvil, not really - www.transloc-inc.com' Jan 03 15:26:39 -' Jan 03 15:26:54 Is there a common reason that a neo would get hung up at the logo screen with the text please wait? This is the first time I have had one not fully boot and I was wondering if anyone has had a similar problem Jan 03 15:27:38 PWizard: does your system log actual NMEA out? Jan 03 15:28:19 magellan: I'd first try taking the battery otu, leaving a couple of minutes, then retrying. Jan 03 15:28:50 SpeedEvil, no, our device interprets NMEA sentences and encodes them in a simple proprietary packet format and sends them to our server Jan 03 15:30:36 SpeedEvil, the "student-facing" portion of our app can be seen in action here, if you have a java plugin for your browser: yale.transloc-inc.com Jan 03 15:33:32 When i try to use the command "xrandr" i always get "cant open display". what do i need to configure before? Jan 03 15:33:50 pwizard do u use a binary protocol to encode the data to your server? is it public? Jan 03 15:34:29 PWizard: do you have devices that were not affected? Jan 03 15:34:48 for GPS to be out over that area, I'd expect actual news stories. Jan 03 15:35:15 SpeedEvil, it's unclear, but it doesn't appear so. Unfortunately all but one of our biggest deployments aren't running their buses today Jan 03 15:35:21 between semesters. :) Jan 03 15:36:19 zedstar, it's not public yet, but we're planning on releasing specs eventually. There's some pressure from student groups from some of our client universities, but really the data isn't very useful yet Jan 03 15:36:32 unless you want to draw a map of the university and see where the bus is. :) Jan 03 15:37:05 pwizard is it binary the protocol or text-based im just curious Jan 03 15:37:53 zedstar: it's binary, yes. Jan 03 15:38:10 It's sent over SMS or something? Jan 03 15:38:56 SpeedEvil, no, TCP/IP Jan 03 15:39:01 GSM/GPRS Jan 03 15:39:24 are you getting no packets, or packets that say no fix? Jan 03 15:39:30 pwizard ok thanks...i would be interested to see the encoding if it goes public....i do quite a bit of binary protocol stuff Jan 03 15:40:22 SpeedEvil, no packets, because there's no fix. The device sends a log after a while that indicates the cause of the outage, in this case no fix. :/ Jan 03 15:40:42 RE Jan 03 15:40:45 Has this been going on for some days? Jan 03 15:40:51 it tries to send a log for network outages as well, but as you might imagine that rarely winds up working. :) Jan 03 15:40:56 SpeedEvil, Just this morning Jan 03 15:41:26 it's still going on? Jan 03 15:41:28 specifically around 6:20 and 6:26 am, with decreasing amounts of instances until around 7 am Jan 03 15:41:34 ah Jan 03 15:41:39 SpeedEvil, does not appear to be continuing now Jan 03 15:42:04 how often do you sample position? Jan 03 15:42:20 1Hz Jan 03 15:42:26 or rather - how often will it give no fix errors if there isn't one? Jan 03 15:43:01 the GPS receiver feeds our hardware the coordinates, we are not actively sampling Jan 03 15:43:39 no fix is indicated by NMEA sentence with no coords or 0,0 coords Jan 03 15:44:11 Yes - I mean - if you plot fix/no-fix vs lat/lon on a 3d graph, might something be revealed, or is the temporal resolution too bad Jan 03 15:44:56 are all the devices parked in several spots controlled by one authority? Jan 03 15:45:07 (at the time) Jan 03 15:47:02 wondering if someones installed a new system Jan 03 15:47:07 which is interfering Jan 03 15:47:37 SpeedEvil, The devices in atlanta had the same outage at the same time, despite being up to 10 miles apart Jan 03 15:48:14 that is, the outage doesn't seem to be geographically linked. Jan 03 15:48:33 10 miles is nothing Jan 03 15:49:03 We get at least 1 coordinate per second, so graphing the outages is helpful and usually we do that, except google earth for linux doesn't work with the driver for my current graphics card. :( Jan 03 15:49:13 gnuplot Jan 03 15:50:02 cjb_ie, 10 miles at Atlanta, 4-7 miles at Newhaven, 8ish miles at Raleigh Jan 03 15:50:10 was there heavy rain/snow/hail then? Jan 03 15:50:11 SpeedEvil, never used gnuplot before Jan 03 15:50:21 PWizard: but how did the timing compare between the three sites? Jan 03 15:50:22 SpeedEvil, nope, just cold Jan 03 15:50:38 cjb_ie, the outage occurred at the same time everywhere Jan 03 15:51:35 PWizard: on another topic. Might you consider donating the GPS tracks to openstreetmap? Jan 03 15:51:54 (where 'you' is the appropriate authority) Jan 03 15:52:50 PWizard: that smells _really_ like software. Jan 03 15:53:07 PWizard: assuming that GPS has gone out over 1000 miles basically. Jan 03 15:53:56 PWizard: same time, measured by GPS, or by your device clocks? Jan 03 15:54:16 SpeedEvil, That's what I thought, but I can't think of what might have caused such a weird outage to occur on even one device, and less so how they would synchronize so perfectly Jan 03 15:54:34 The devices went out all at one time? Jan 03 15:54:37 SpeedEvil, by our server clock, upon receipt of the log Jan 03 15:54:42 SpeedEvil, yes Jan 03 15:54:51 And came back - sort-of as if they were cold restarting? Jan 03 15:55:03 with that sort of delay. Jan 03 15:55:36 After a certain period of time, the device resorts to a reboot to recover from an outage. Jan 03 15:55:44 The period depends upon the type of outage Jan 03 15:55:48 might it be doing that? Jan 03 15:55:49 freesmartphone.org: 03mickeyl * r20 10/trunk/ (README standards/otapi/ standards/telephony/): README: add py-proto Jan 03 15:56:03 freesmartphone.org: 03emdete * r21 10/trunk/software/py-proto/ (pygpsd.py pygsmd.py pyneod.py pypwrd.py): three in one: pyneod Jan 03 15:56:09 freesmartphone.org: 03emdete * r22 10/trunk/software/py-proto/ (README pygpsd.py pygsmd.py pyneod.py pypwrd.py): dbus methods work Jan 03 15:56:11 I'd wonder if my GPS devices had crashed due to an internal software problem. Jan 03 15:56:19 if they are all the same brand. Jan 03 15:56:56 SpeedEvil, exactly, that's what I'm arriving at. They're SiRF-III devices, the GlobalSat BU-355 Jan 03 15:57:36 I suppose you've got no raw NMEA logs of what happened? Jan 03 15:57:54 freesmartphone.org: 03emdete * r23 10/trunk/software/py-proto/README: more doc Jan 03 15:58:01 maybe there's some arcane bug in the firmware for the device that was triggered by some generalized GPS transmission... Jan 03 15:58:16 or by an internal rollover of some sort Jan 03 15:58:45 SpeedEvil, correct, we're basically transmitting the logs over a 57,600baud modem, sending all the NMEA coords would hose the connection. :) Jan 03 15:58:50 freesmartphone.org: 03mickeyl * r24 10/trunk/standards/otapi/README: add README Jan 03 15:59:32 Actually, I did that. - for a subset. grep (a subset of GPS strings)|ssh Jan 03 15:59:45 but it's not exactly efficient Jan 03 16:00:34 We were logging every 10th GGA/RMC but even that was bloating the logs Jan 03 16:01:34 I'd probably - though certainly after something like this - log the last 10 lines before an error Jan 03 16:01:36 freesmartphone.org: 03mickeyl * r25 10/trunk/standards/otapi/org.freesmartphone.GSM.Device.xml: otapi: add introspection file for org.freesmartphone.GSM.Device Jan 03 16:01:39 funny thing is if the outage was synchronised, i'd have expected the reboots to be pretty synchronised too Jan 03 16:01:46 cjb_ie: not really. Jan 03 16:01:59 cjb_ie, they were. Jan 03 16:01:59 cjb_ie: GPSs vary in lock times due to 'stuff' Jan 03 16:02:14 so they vary a bit Jan 03 16:02:20 not exactly synced, but within about 30sec Jan 03 16:20:58 whats up with freerunner? Jan 03 16:21:39 freerunner? Jan 03 16:21:59 http://gizmodo.com/339965/openmoko-launches-neo-freerunner-open+source-smartphone-for-the-masses Jan 03 16:22:06 whats that about? Jan 03 16:23:27 * SpeedEvil sighs. Jan 03 16:23:52 does anybody know from where the neo is shipping? Jan 03 16:24:13 us Jan 03 16:24:19 k thnx Jan 03 16:24:27 or taipei Jan 03 16:24:39 but not europe Jan 03 16:24:45 no europe Jan 03 16:24:49 ok Jan 03 16:24:53 what I needed to know :) Jan 03 16:25:13 I'd like to know WHEN it's shipping. :P Jan 03 16:25:17 I'm so impatient. :S Jan 03 16:29:48 aha, so freerunner = gta02 Jan 03 16:30:45 I think this is just holding up GTA02v4 and saying 'shiny'. Jan 03 16:30:56 rather than actual progress. Jan 03 16:32:08 The press release does say that there will be an 850-MHz variant of the phone, so that's progress (for North American customers) Jan 03 16:34:59 yeah Jan 03 16:35:02 yeah well, that's certainly nice to verify Jan 03 16:35:22 other than that, yeah, "look, shiny" Jan 03 16:38:49 And this is, I assume, to drum up hype rather than actually prepare for the release. Jan 03 17:08:06 hi there Jan 03 17:12:27 witch language openmoko developers use? Jan 03 17:12:39 is it c++ Jan 03 17:12:42 ? Jan 03 17:13:17 depends I guess Jan 03 17:13:22 C, C++, Python Jan 03 17:13:56 k thx Jan 03 17:14:14 np Jan 03 17:16:21 vala Jan 03 17:16:27 openmoko: 03mickey * r3761 10/trunk/src/target/OM-2007.2/applications/openmoko-terminal2/src/mokoterminal.vala: openmoko-terminal2: set colors properly (found 'ref' keyword ;) and more compact Jan 03 17:22:07 Hi. Back from rebuilding openmoko images from stratch. Jan 03 17:22:21 And I get exactly the same error message as before. Jan 03 17:22:22 I just started, again Jan 03 17:22:33 what error Jan 03 17:22:34 ? Jan 03 17:22:36 I started from a fresh downloaderd moko makefile Jan 03 17:22:44 naming question: "GetCurrentOperator", "GetProviderName", or "GetOperatorName" ? Jan 03 17:22:45 me too Jan 03 17:23:15 Anybody can help with moko makefile problems ? Jan 03 17:23:26 not if you don't pastebin the actual error Jan 03 17:23:35 mickeyl: provider IMO Jan 03 17:23:44 mickeyl: operator seems veru EU-centric Jan 03 17:23:46 *very Jan 03 17:23:57 Here it is: http://celpaste.morb-design.com/pastebin.php?show=d7d6079a0 Jan 03 17:24:00 * * OM Bug 1155 has been created by mail(AT)mmontour.net Jan 03 17:24:01 * * gsmd segfault in network_opers_parse Jan 03 17:24:02 * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1155 Jan 03 17:24:50 ok, there are multiple problems Jan 03 17:24:58 I'm reading ... Jan 03 17:25:20 (I meant I'm listening ...) Jan 03 17:25:22 one is do_fetch failing in openmoko-terminal2, you can fix that by removing the svn/openmoko-terminal2 directory in your downloaded source dir Jan 03 17:25:39 Why ? We do not need it ? Jan 03 17:26:09 i removed the dir in svn and readded Jan 03 17:26:21 this -- unfortunately -- has problems on svn update Jan 03 17:26:26 so you can remove it Jan 03 17:26:29 and let OE recheckout Jan 03 17:26:52 after that, we need to fix the u-boot-openmoko error Jan 03 17:26:52 OK. Since I'm new, which subdirectory ? Jan 03 17:27:05 dunno where mokomake file stores its stuff Jan 03 17:27:26 I'm in the main directory, were the moko makefile is. Jan 03 17:27:38 guys is there an SDK for openmoko? Jan 03 17:28:00 OK found it. Jan 03 17:28:07 http://www.forbes.com/businesswire/feeds/businesswire/2008/01/03/businesswire20080103005343r1.html Jan 03 17:28:16 so it's now 500MHz? Jan 03 17:28:18 bedboi: there's a toolchain Jan 03 17:28:35 bedboi: and you can develop in multiple ways, see wiki Jan 03 17:28:36 mickeyl: does this mean at the end someone realized armv4 sucks in 2997/8? ;) Jan 03 17:28:36 host-based Jan 03 17:28:38 or cross Jan 03 17:28:47 host-based? Jan 03 17:28:47 s/2997/2007/ Jan 03 17:28:47 Kaloz meant: mickeyl: does this mean at the end someone realized armv4 sucks in 2007/8? ;) Jan 03 17:28:49 :p Jan 03 17:28:50 Oh yeah - I thought it had been announced as 400 Jan 03 17:28:55 well Jan 03 17:28:57 please please Jan 03 17:29:01 forget that you read 500 Jan 03 17:29:07 think 400 Jan 03 17:29:09 and don't ask Jan 03 17:29:13 mickeyl: i want to forget you stil lwant armv4 :PPPP Jan 03 17:29:27 I'm holding that as a guarantee that it'll overclock :) Jan 03 17:29:35 it's armv4 Jan 03 17:29:38 still samsung s3c Jan 03 17:29:39 i know the topic says "don't ask about the GTA02" but is March a real release date this time or another theoretical pencilled in possibility? :) Jan 03 17:29:51 mickeyl: evne samsung s3c has armv5 ;P Jan 03 17:29:59 Moniker42: the latter I guess Jan 03 17:30:00 ya, but not the one we use Jan 03 17:30:07 Indeed. Can you expand on what's going on with the current testing mickeyl? Jan 03 17:30:10 i once remember thinking "well it can't possibly be so late that i can't get it for christmas at the end of 2007" Jan 03 17:30:17 mickeyl: hence I got my hopes up reading 500MHz ;) Jan 03 17:30:21 SpeedEvil: unfortunately not. i must confess i'm a bit out of the loop here in .de Jan 03 17:30:32 Kaloz: no, still s3c24 Jan 03 17:30:35 Does there exist a revision of the board that's got the known bugs fixed? Jan 03 17:30:40 :/ Jan 03 17:30:53 Or is that still being held off till the video and wifi are more fully tested. Jan 03 17:30:59 Kaloz: you won't expect an incompatiblöe CPU change shortly before a launch will you? Jan 03 17:31:05 half of the routers here are faster than that :/ Jan 03 17:31:11 SpeedEvil: still being held off Jan 03 17:31:18 mickeyl: armv5 is halrdy incompatible Jan 03 17:31:29 mickeyl: worst cxase it would run the same binaries faster Jan 03 17:31:29 Kaloz: think form-factor Jan 03 17:31:31 think pinout Jan 03 17:31:35 don't think architecture Jan 03 17:31:45 think delay loops? Jan 03 17:31:48 At the moment any changes are scary Jan 03 17:31:51 well, irrc 2440 is pin compatible with 2410 Jan 03 17:31:53 or what it was Jan 03 17:32:00 yes Jan 03 17:32:03 that's why we could use it Jan 03 17:32:08 The current 2 hardware is at its 4th revision. Jan 03 17:32:08 mickeyl: I've found and removed the openmoko-terminal2 directory. Jan 03 17:32:14 SpeedEvil: well, at the moment not changing is scary as well Jan 03 17:32:26 if you change anything non-trivial, you can induce more bugs. Jan 03 17:32:41 A new non-pin-compatible CPU is basically 1/2 a complete redesign. Jan 03 17:32:48 that's the eternal software development problem, isn't it? Jan 03 17:32:52 SpeedEvil: most of the new toys are armv6 (arm11) now, and cortex toys are in the pipeline, too Jan 03 17:32:53 alberto: good. next, you may edit a filename in packages/uboot Jan 03 17:32:58 and to fix those bugs you might need to change more non-trivial things... Jan 03 17:33:05 alberto: it was renamed to u-boot- Jan 03 17:33:11 from uboot- Jan 03 17:33:17 and the OM tree probably didn't catch up yet Jan 03 17:33:25 kaz: I know. I want someone to do something like microchip - with their 'flex' pin layouts. Jan 03 17:33:37 mickeyl: OK, thk Jan 03 17:33:41 np Jan 03 17:33:48 I cannot find ogg123 in my 2007.11 Snapshot. Is it gone ? Jan 03 17:34:12 kaz: instead of being able to choose between GPIO and serial for a port, for example, you can map any peripheral to a pin. Jan 03 17:35:03 mickeyl: Where did the name FreeRunner come from :-) ? Jan 03 17:35:10 CVirus: i have no idea Jan 03 17:35:19 LOL Jan 03 17:35:22 i know since today Jan 03 17:35:22 CVirus: run for your money *g* Jan 03 17:35:23 like you Jan 03 17:35:24 ;) Jan 03 17:35:33 mickeyl: who called it then ? Jan 03 17:35:34 mickeyl: Which file ? I've posted the list in http://celpaste.morb-design.com/pastebin.php?show=m5dcc48a8 Jan 03 17:35:56 CVirus: no idea, i suspect, the president, the vice president of marketing, or the product manager Jan 03 17:36:02 or all three Jan 03 17:36:28 I get it Jan 03 17:37:10 alberto: hmm d'oh, you're missing uboot-openmoko.bb Jan 03 17:37:17 don't ask me why Jan 03 17:37:41 is this the result of a 'find' ? Jan 03 17:37:42 You are right. Jan 03 17:38:06 I also did find . -name "*uboot-openmoko.bb*" -print Jan 03 17:38:12 And no result. Jan 03 17:38:18 mickeyl: hmz - for me it seems the 2410 isn't pin comaptible with the 2440, but with the 2412 Jan 03 17:38:23 mickeyl: weird Jan 03 17:38:41 Is should be there, isn't it ? Jan 03 17:39:41 SpeedEvil: so the gta02 has a not-pin-compatible cpu upgrade ;) Jan 03 17:40:10 Kaloz: the decision to choose a component depends on a multitude of factors Jan 03 17:40:42 mickeyl: But I have this file: ./openembedded/packages/uboot/uboot-openmoko_svn.bb Jan 03 17:40:55 and this one: ./openembedded/packages/uboot/uboot-openmoko_1.2.0+gitf34024d4a328e6edd906456da98d2c537155c4f7+svn2943.bb Jan 03 17:41:09 mickeyl: I know, just weird that you went redesigning a product to use another (faster but still obsolete) core :) anyways, I hope it will succeed, don't get me wrong Jan 03 17:42:15 obsolete is an overused word Jan 03 17:42:16 alberto: try to rename them to u-boot-openmoko Jan 03 17:42:35 Kaloz: do you know when hardware design started? Jan 03 17:42:38 With .bb at the end ? Jan 03 17:42:55 alberto: just change uboot to u-boot, everything else leave Jan 03 17:43:33 ljp: overused/cruel/etc, but still fits most of the time Jan 03 17:43:35 mickeyl: done Jan 03 17:43:57 mickeyl: I can guess so but the decision on bumping the cpu happened later Jan 03 17:44:11 Shall I make the image, now ? Jan 03 17:45:48 obsolete means no longer in use. if the freerunner uses something, its not obsolete Jan 03 17:47:59 wouldn't you call an 5x86 core obsolete either now? ;) Jan 03 17:48:20 if its still in use, no Jan 03 17:49:35 would you call a canoe obsolete? Jan 03 17:50:53 alberto: sure, go ahead and try Jan 03 17:51:02 * alberto compiling. Jan 03 17:51:09 It seems to work!! Jan 03 17:51:17 Now is building the locales ... Jan 03 17:51:56 good Jan 03 17:54:10 mickeyl: I suppose you build everything by hand, w/out the moko makefile, do you ? Jan 03 17:54:49 yes. i never used mokomakefile. i'm one of the founders of OpenEmbedded and BitBake, i'm a bit too used to using 'bitbake' instead of 'make' Jan 03 17:55:20 hmm too many usages of 'using' in the previous sentence Jan 03 17:55:21 heh Jan 03 17:55:39 =) Jan 03 17:56:09 I suppose I can learn how they work (O.E + bitbake) from their web sites ? Jan 03 17:56:17 Or is there a tutorial ? Jan 03 17:56:32 the wiki is pretty detailed Jan 03 17:56:39 e.g. GettingStarted on openembedded.org Jan 03 17:56:51 but don't get me wrong, mokomakefile is cool Jan 03 17:56:58 if all you want is building Jan 03 17:57:06 yes, it worked before Xmas. Jan 03 17:57:30 I would like to build the image and then start to write some small programs Jan 03 17:57:36 Of course, the problems that alberto was experiencing would also be encountered by those who are *NOT* using the MokoMakefile either - be fair. Jan 03 17:57:58 We would like to use the moko for the remote monitoring of our experiment Jan 03 17:58:13 (It's a neutrino experiment in Gran Sasso) Jan 03 17:58:21 Those issues are OE issues, not the MokoMakefile -- the makefile knows nothing at all of .bb files and such. Jan 03 17:59:17 Indeed, I think the makefile is really cool... Jan 03 17:59:47 But I understand that the full distribution is "unstable" (a'la debian ...) Jan 03 18:00:05 So today it compiles, and tomorrow it doesn't Jan 03 18:00:34 well, that's why it pulls from monotone.openmoko.org Jan 03 18:00:38 not from openembedded.org Jan 03 18:01:02 * CoreDump is building against oe.dev...no probs Jan 03 18:02:11 * mwester built yesterday against oe.dev -- and it built ok for the first time in several weeks ;) Jan 03 18:08:16 mickeyl: i'm trying to crosscompile using the toolchain but om-config is failing Jan 03 18:08:25 configure: error: C compiler cannot create executables Jan 03 18:08:50 of course i've run source /usr/local/openmoko/arm/setup-env Jan 03 18:09:32 examine config.log Jan 03 18:11:23 alberto: It's strange that you had that u-boot/uboot problem. The MokoMakefile that I'm using will try to build it using both names. Are you sure you're using the most recent version? Jan 03 18:11:36 Yes. Jan 03 18:11:47 I downloaded it three hours ago Jan 03 18:11:58 From which URL? Jan 03 18:12:03 http://www.rwhitby.net/files/openmoko/Makefile Jan 03 18:12:15 I've found it on the openmoko wiki Jan 03 18:13:12 The "make update-makefile" target in my version downloads from http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile Jan 03 18:13:49 On the wiki it says to get it from the first URL Jan 03 18:13:59 and if it did not work, from the second Jan 03 18:14:15 Actually, I also tried the update-makefile make command Jan 03 18:14:29 And at the end I started everything from scratch. Jan 03 18:16:00 mmontour: Actually, while downloading from the first address it fails Jan 03 18:16:12 The timestamp on the www.rwhitby.net version is "26-Feb-2007" so I suspect the wiki may be out of date, but it's really a question for rwhitby himself. Jan 03 18:16:15 and than it gets it form http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile Jan 03 18:16:55 mmountour: indeed I got it from "your" address Jan 03 18:18:19 Shall I write to Rod Whitby ? Jan 03 18:18:41 or maybe he reads on this channel... Jan 03 18:19:06 Is there a possibility left to play an ogg file from the command line in 2007.11 ? Jan 03 18:19:17 He's often on this channel. Jan 03 18:19:24 mickeyl: ah, ccache is missing Jan 03 18:19:57 mickeyl, mmontour: IT FAILED AGAIN !!!! :( Jan 03 18:20:13 It tells me: Jan 03 18:20:21 ERROR: '/data3/omoko/openembedded/packages/openmoko2/openmoko-terminal2_svn.bb' failed Jan 03 18:20:52 there are over 300 people in this channel, but it's not more active that one with 100 people Jan 03 18:20:56 My MokoMakefile has this logic: ( bitbake openmoko-devel-image uboot-openmoko ) || ( bitbake openmoko-devel-image u-boot-openmoko ) so it should handle either u-boot name Jan 03 18:20:57 I thought I removed the file ... Jan 03 18:21:16 i'm betting most others (like me) are just keeping tabs on the release date and want to order a gta02 as soon as it is released Jan 03 18:21:23 alberto: fetching now probably works, but there are still some updates Jan 03 18:21:38 alberto: copy the file from org.oe.dev over the one you have atm. Jan 03 18:21:38 OK ... Shall I start from scratch ? Jan 03 18:21:42 no need Jan 03 18:21:48 just use the file from org.oe.dve Jan 03 18:22:01 You mean the terminal2* ? Jan 03 18:22:38 (Sorry, but I'm new, and I still have to understand which file and form where is needed) Jan 03 18:23:22 well Jan 03 18:23:32 ideally nothing of this hand tweaking is necessary Jan 03 18:23:46 but i guess the OM build guys just had bad luck this time Jan 03 18:23:54 picking an inconsistent state of org.oe.dev Jan 03 18:24:08 So just a make update will do it ? Jan 03 18:24:10 all problems have been fixed in OE since then Jan 03 18:24:17 depends on where make update pulls Jan 03 18:24:25 perhaps they have been fixed Jan 03 18:24:29 just try Jan 03 18:24:38 if not, you may try to grab the offending files from org.oe.dev Jan 03 18:24:39 OK Jan 03 18:24:43 http://openembedded.org Jan 03 18:24:52 -> browse tree Jan 03 18:25:15 or use monotone to check out a copy from org.oe.dev. may be more handy than browsing through the web Jan 03 18:26:47 mmontour: My make file is doing: ( cd build && . ../setup-env && \ Jan 03 18:26:47 ( ( bitbake openmoko-devel-image uboot-openmoko ) || \ Jan 03 18:26:47 ( bitbake openmoko-devel-image u-boot-openmoko ) ) ) Jan 03 18:28:04 * alberto now compiling .... Jan 03 18:32:07 is it possible to restart the UI over ssh, similar to startx Jan 03 18:32:12 ? Jan 03 18:35:03 Are there any images of FreeRunner? Jan 03 18:35:25 or any further infos anywhere.. something to feast on :P Jan 03 18:37:42 magellan: /etc/init.d/x-something Jan 03 18:39:35 coredump: my neo boots but gets stuck at the OM screen with "please wait ..." displayed Jan 03 18:39:48 oh Jan 03 18:40:06 chvt 1 ;) Jan 03 18:40:15 I can ping and ssh it but can't get to the UI, I can't figure out what is haning it up Jan 03 18:41:45 magellan: /etc/init.d/xserver-nodm restart Jan 03 18:42:02 thanks, lets see if this works Jan 03 18:44:27 nope failed. I've screwed up my build under mokomakefile Jan 03 18:44:41 I think I quilted something wrong Jan 03 18:55:12 magellan: I get that sometimes Jan 03 18:55:25 because I made /home/root a symlink to /media/card/home/root Jan 03 18:55:43 404: NOTE: fetch http://downloads.openmoko.org/sources/openmoko-terminal2_svn.openmoko.org_.trunk.src.target.OM-2007.2.applications_3542_.tar.gz Jan 03 18:55:43 So I get the hanging at Please wait... when I have a new card in it Jan 03 18:55:46 anyone got that file handy? Jan 03 18:56:00 not getting past "Please wait..."? Jan 03 18:56:06 Right Jan 03 18:56:16 I get that as a symptom when /home/root isn't there Jan 03 18:56:38 which happens to me because I put /home/root as a symlink on the sd card, and sometimes I have a new card in there Jan 03 18:56:55 anyway, I just wanted to bring it up as something to think about in case you have a similar situation Jan 03 18:57:21 well /home/root is there and I don't have a symlink for it. Jan 03 18:57:44 but thanks anyway Jan 03 18:58:14 alberto: the www.rwhitby.net URL is OK. That webserver redirects to the nslu2-linux.org version. Jan 03 18:58:15 is still http://wiki.openmoko.org/wiki/Information_Dialog not implemented? Jan 03 18:58:28 right now Ive started a make clean make openmoko-devel-image Jan 03 18:58:35 so Im pretty much starting over Jan 03 18:58:40 mmontour: Thanks, I verified it, too. Jan 03 20:07:03 seriously, who came up with 'freerunner' Jan 03 20:07:13 :-) Jan 03 20:07:41 I wonder based on mickeyl's response if it is yet another release or something Jan 03 20:07:49 he kind of waffled on the 400/500 mhz issue Jan 03 20:08:09 ScaredyCat, I assure you it will "sell" better than NeoSomeNumberThatMeansNothingToMostPeople Jan 03 20:08:53 that's probably true too, regardless of how lame it is Jan 03 20:09:00 !logs Jan 03 20:09:01 Channel logs for #openmoko are archived at: Jan 03 20:09:02 http://hentges.net/tmp/logs/irc/%23openmoko Jan 03 20:09:03 Live-logs are available at Jan 03 20:09:04 http://hentges.net/tmp/logs/irc/livelogs/%23openmoko.livelog Jan 03 20:09:05 ScaredyCat: I agree, not so good name ... Jan 03 20:09:05 I know at home we just call it the neo Jan 03 20:09:06 See ?? help-logs for usage instructions Jan 03 20:09:24 neoneo Jan 03 20:09:41 neo2 Jan 03 20:09:53 or just neo, with the developer's version falling into obscurity Jan 03 20:10:11 alberto: http://www.rwhitby.net/files/openmoko/Makefile is an apache redirect to http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile Jan 03 20:11:26 kdean06: I doubt the name will make any difference. To be frank, the 'consumer' isn;t going to be your average person Jan 03 20:12:17 Hopefully eventually it will be :-) Jan 03 20:13:45 reading the backlog it just seems that this is a press release just to be sure people haven't forgotten about the project... Jan 03 20:14:01 * ScaredyCat also points at his prediction for March Jan 03 20:14:19 which is the press release? Jan 03 20:14:35 I'm not sure there is a such thing as an "average" customer. Jan 03 20:14:52 yeah, I'm sure the press release is just another heads up Jan 03 20:15:04 It did interest me to see them commit in a press release to the 850mhz version Jan 03 20:15:28 Although frankly when I ordered my neo, the reply I got told me that they were putting out such a version Jan 03 20:15:34 * balrog-kun thinks there shoiuld be more such press releases even if they don't announce anything new Jan 03 20:15:35 The goal, as I understand it, is to make a decently usable phone powered by Free Software. That last part won't mean much to a lot of people but it being expandable, decently cheap and sexy looking WILL sell units assuming FIC doesn't totally botch this thing. Jan 03 20:15:59 And I also thought it was interesting that they talk about doing gestures with the accelerometer. I had thought of that, but I didn't realize there were already plans in the works for it. Jan 03 20:17:11 kdean06: I don't really think a lot of end users will jump on it at first, but being open & linux compatible means LOTS of software for it, and no paying for ring tones & lots of free games, which will attract users Jan 03 20:18:03 I just hope someone with the money to spend on it will spend some time prettifying the GUIs of the open softare on it and perhaps putting it together as a coherent & beautiful package Jan 03 20:18:07 a la iphone Jan 03 20:18:22 wurp2, I agree. I think the largest market are the people who might, when they need a new one. I'm sure in the next 3 years iPhone's numbers will double from what they are simply for the people who like the idea, but aren't willing to shell out that much for it. Jan 03 20:19:16 anyone got the link to the press release? I think I must have missed it when reading up Jan 03 20:19:55 You can look in the logs for #openmoko today on the web; search for 'press release' Jan 03 20:22:24 I'll have to wait until I get my Neo but from what I've seen thus far, OpenMoko is one of the most unified "distros" I've seen. Jan 03 20:23:52 actually,... Jan 03 20:24:26 gizmodo is the only source I can find. It's not even on FIC's site, or openmoko.com Jan 03 20:24:31 Here's a copy of the press release: http://www.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20080103005343&newsLang=en Jan 03 20:25:20 ta Jan 03 20:25:44 * mstevens fails to boot the 2007.11 snapshot and wonders if I've just bricked it. Jan 03 20:26:16 still seems odd that FIC don;t have their press release on their press releases page Jan 03 20:26:19 Whoever maintains www.openmoko.com might want to update the "Latest on OpenMoko" section - the last article is from July 20, 2007. Jan 03 20:26:34 yeah... old. Jan 03 20:26:47 mstevens: did you update your u-boot? Jan 03 20:27:47 mmontour: yep Jan 03 20:28:12 mmontour: mmontour that part I think is okay, I can get to the boot menu and it's definitely the updated one Jan 03 20:28:14 FIC seems quite slow to do things. Jan 03 20:28:29 It doesn't surprise me that Gizmodo moves faster on it than they do. :P Jan 03 20:28:44 In that case it's not bricked. Can you boot from the u-boot menu? Jan 03 20:29:18 mmontour: I'm just fiddling with the u-boot menu trying to do the serial console thing Jan 03 20:29:34 try to boot from there Jan 03 20:29:39 mickeyl, mmontour: Compilation of openmoko terminated and failed again :( Jan 03 20:29:50 I get the same two errors: Jan 03 20:29:59 Bug 887 can cause a hang on boot, bug 799 will crash if you try to boot from the SD card Jan 03 20:30:06 it gets as far as the boot splash screen, then nothing Jan 03 20:30:08 complaining about missing openmoko-terminal2-2.1.1+svnr3542-r2 Jan 03 20:30:18 * mstevens hits cu with stick Jan 03 20:30:29 ScaredyCat: isn't the pressrelease supposed to be released in CES ? Jan 03 20:30:50 No actually, it is the only error i get (but it is fatal) Jan 03 20:31:09 cu: open (/dev/ttyACM0): Permission denied Jan 03 20:32:37 mstevens: 'cu' wants you to be a member of the 'uucp' group or something. I usually use 'screen /dev/ttyACM0' instead. Jan 03 20:33:17 screen ftw Jan 03 20:33:34 mstevens: just type: chown uucp.uucp /dev/ttyACM0 Jan 03 20:33:48 mstevens: and afterwards cu should work Jan 03 20:34:37 may I ask for some help in getting the images built with the openmoko makefile ? Jan 03 20:34:52 Has anybody built yesterday night or today ? Jan 03 20:35:41 Probably I should read how monotone and OE work and understand packages dependencies and repositories .... Jan 03 20:40:25 alberto: Can you 'pastebin' the exact error message and some of the text leading up to it? Jan 03 20:40:39 mmountour: OK ... Jan 03 20:42:10 mmountour: Here is the link: http://celpaste.morb-design.com/pastebin.php?show=d37de2d2b Jan 03 20:43:02 Afterwards I tried again the full chain: make setup update openmoko-devel-image Jan 03 20:43:32 But again it complains it cannot fetch openmoko-terminal2-2.1.1+svnr3542-r2 Jan 03 20:44:12 ooh! Jan 03 20:44:16 I made my first phone call! Jan 03 20:44:19 * mstevens gets overexcited Jan 03 20:45:42 it seems to boot fine from the u-boot menu, but not directly Jan 03 20:46:15 :) Jan 03 20:47:33 Is it normal that neod take 3M in memory ? Jan 03 20:48:55 It seems a lot, I'll look at sources Jan 03 20:49:21 it's not really that much is it? Jan 03 20:49:22 (Don't try Openmoko with 32Megs ...) Jan 03 20:49:48 1197 root 15 0 22356 3796 3132 S 0.0 3.0 0:01.09 neod Jan 03 20:50:01 SpeedEvil: thanks. Jan 03 20:50:07 mstevens: there's a patch for tht i believe Jan 03 20:50:14 on bugzilla Jan 03 20:50:30 I don't know what the purpose of neod, I was thinking of it like another dbus ... Jan 03 20:50:32 (image of last week or so) Jan 03 21:00:06 alberto: sorry, I don't recognize that error. Maybe someone else can help. Jan 03 21:00:51 mmontour: Thanks, anyway! Jan 03 21:01:44 balrog-kun: I put a patch for #887 on bugzilla that works for me, but mickey said it made the problem worse on his neo. It would be good if a few other people could look at it (and at the #799 patch) Jan 03 21:02:26 !bug 887 Jan 03 21:02:36 what is it? Jan 03 21:02:53 !ombug 887 Jan 03 21:02:55 * * Bug 887, Status: ASSIGNED, Created: Unknown Jan 03 21:02:56 * * mickey(AT)vanille-media.de: U-Boot initialization race condition: Hangs on boot Jan 03 21:02:57 * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=887 Jan 03 21:03:03 ah Jan 03 21:04:05 "887" may actually be a few different bugs with the same symptom (hanging at the splash screen on boot) Jan 03 21:11:09 ~patebin Jan 03 21:11:10 hmm... patebin is your friend Jan 03 21:11:12 ~pastebin Jan 03 21:11:13 [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste Jan 03 21:17:37 mmontour: oh, that's the patch i was referring to Jan 03 21:18:28 mmontour: i was just looking at #1155 now, but it seems the gdb symbols are bogus because usock.c:661 is far outside network_opers_parse Jan 03 21:19:02 mmontour: i suppose you didn't modify usock.c to avoid bug #1154? Jan 03 21:20:07 it seems like the mlbuf is getting corrupt somewhere in atcmd.c because in the call to network_opers_cb the value is already wrong in the backtrace, but i don't know if we can trust the backtrace Jan 03 21:26:18 balrog-kun: I'm at home and I've a fix with my neo. Do you still look for someone to test your gps stuff ? Jan 03 21:27:31 rtp: yes, i even uploaded a ready to use binary now :) Jan 03 21:27:41 * balrog-kun wonders if his neo is now charged.. Jan 03 21:29:12 oh, let me make a replacement script and upload it too Jan 03 21:29:14 are there any feeds with the 2.6.23.1 kernel+modules? Jan 03 21:32:22 ok, done Jan 03 21:32:56 rtp: can you test my gllin hack? Jan 03 21:33:16 balrog-kun: sure. What's the url ? Jan 03 21:33:57 rtp: the script is at http://folks.o-hand.com/andrew/gllin.ld4 and the loader at http://folks.o-hand.com/andrew/ld4 Jan 03 21:34:10 they need to both be placed in the gllin directory and made executable Jan 03 21:35:01 then ./gllin.ld4 should run gllin as usually, just without using the chroot Jan 03 21:36:07 if i made no mistake in the script... Jan 03 21:37:01 where is the gps package normally? Jan 03 21:37:25 ah Jan 03 21:41:28 balrog-kun: should it turn the GPS on? Jan 03 21:41:49 balrog-kun: I think we must have different source trees. My line 661 is in that function: Jan 03 21:41:58 SpeedEvil: yes, if it doesn't segfault before :p Jan 03 21:42:11 if (n < 10 || str[n - 1] != ')') Jan 03 21:42:23 SpeedEvil: it's supposed to work exactly like the provided script Jan 03 21:42:32 I've never used that Jan 03 21:42:32 i mean the one from ipkg Jan 03 21:43:11 i never ran it either, but i had a look at it Jan 03 21:43:20 mmontour: lemme re-checkout Jan 03 21:43:59 mmontour: this is line 807 in current svn Jan 03 21:47:10 balrog-kun: I've theses messages : http://rafb.net/p/kRPyBC35.html do you get them ? Jan 03 21:47:51 rtp: yes, this is ok Jan 03 21:48:06 unless that's all you get Jan 03 21:50:19 balrog-kun: no, I'm getting something on /tmp/nmeaNP but the gps doesn't seem to work. Jan 03 21:50:55 rtp: i see :( Jan 03 21:51:22 rtp: do you get nonsense in /tmp/nmeaNP or just no fix indication? Jan 03 21:51:52 balrog-kun: I suggest something like gzip -1 >/media/card/`date "+%s"`.strace.gz Jan 03 21:52:45 SpeedEvil: this script is a copy of the original script from OpenMoko with just the chroot invocation replaced Jan 03 21:52:52 ah - right Jan 03 21:52:53 it looks like when the gps is trying to find a satellite. the time in the gpgga frame does not change Jan 03 21:53:34 rtp: this is supposed to be time of the last fix, Jan 03 21:53:42 so if there's no new fix i think it shouldn't change Jan 03 21:53:59 balrog-kun: looks like there were some gsmd checkins this morning that added code to usock.c (I build at tested last night, Canada/Pacific timezone) Jan 03 21:54:32 mmontour: i see Jan 03 21:54:33 afaik as soon you have a satellite, the time is set to current time and changing even if you have no fix Jan 03 21:54:58 mmontour: so probably n is 0 (because the parsed string is rubbish) and n - 1 evaulates to -1 Jan 03 21:55:50 rtp: are there any satellites in the GPGSA sentences? Jan 03 21:56:07 it was seeing none on my neo (but it was indoor) Jan 03 21:56:17 ah - I needed I think to +x ld4 Jan 03 21:56:27 or not Jan 03 21:56:35 doesn't seem to start fgllin Jan 03 21:56:37 SpeedEvil: both files need to be executable Jan 03 21:56:39 balrog-kun: Yes, probably something like that but I haven't had time to look at it in detail Jan 03 21:57:23 balrog-kun: i've restarted the gllin.ld4 script. I don't get anything at all on the nmeaNP pipe now :( Jan 03 21:57:57 rtp: strange Jan 03 21:58:24 balrog-kun: it never (with both files +x) seems to start the gps Jan 03 21:58:34 the original script does Jan 03 21:59:21 i'm afraid there may be some floating point errors introduced by ld4 and that may hose gllin interaction with the hammerhead (which needs very exact directions) and it's unable to do its job right Jan 03 21:59:45 oh well, i'll need to do some more work on it, just don't have time now Jan 03 22:00:45 "/ Jan 03 22:00:47 :/ Jan 03 22:01:18 balrog-kun: ok Jan 03 22:01:27 thanks for the testing though Jan 03 22:02:44 you're welcome :) Jan 03 22:09:25 balrog-kun: I'll take a look at your 'ld4' this weekend if I have time. Is there source available? Jan 03 22:10:37 mmontour: yes, although it will be in heavy restructuring when i have time Jan 03 22:10:50 mmontour: source is at http://folks.o-hand.com/andrew/schwartz.git Jan 03 22:10:55 Hi there. Quick question: Any idea why the OpenMoko "FreeRunner" release isn't mentionend on the openmoko.(org|com) site? Jan 03 22:11:44 mmontour: i plan a write-up how it works and how to use it, just want to get gllin running first Jan 03 22:11:50 there's zero documentation now Jan 03 22:12:11 s/how/on how/ Jan 03 22:15:55 But this FreeRunner _is_ the GTA02 model, right? Hmm.. Jan 03 22:16:39 yes, it appears to be the market name for it Jan 03 22:17:40 mjr: Thanks Jan 03 22:23:29 What's the technical name for the connector for the GPS on the Neo? Is that an "MCX"? Jan 03 22:23:57 balrog-kun: thanks, I'll take a look at it later. I'm used to "zero documentation" when it comes to the Hammerhead. :) Jan 03 22:25:51 mmontour: :p Jan 03 22:26:53 actually it may be useful in the reverse engineering of gllin but it doesn't attempt to do the reverse engineering alone Jan 03 22:27:11 it provides higher level output than strace Jan 03 22:27:53 like values passed by glling to strlen, strcpy and other external functions Jan 03 22:31:04 Yes, that might be useful. I'll have to see if I can merge any of it with one of my utilities that intercepts+modifies the packets exchanged between gllin and the HH Jan 03 22:34:15 balrog-kun: I'm sorry but git doesn't like your repository :( Jan 03 22:42:27 rtp: indeed, sorry, i needed to run git-update-server-info Jan 03 22:42:47 should work now, i never had this error issue before Jan 03 22:45:12 balrog-kun: it's working. Thanks. Btw, what about using git.o-hand.com ? :) Jan 03 22:49:33 hm, is there a tar.bz2/gz archive of the kernel patchset, too? Jan 03 22:50:47 pardon my ignorance, but why do i need to shut down the gsmd if i want to start a pppd/gprs connection ? Jan 03 22:51:26 rtp: good idea, i'll ask about it, but after i get gllin to run Jan 03 22:53:24 doesn't the modem supports TS 07.10 multiplex ? Jan 03 22:53:58 thseiler: The modem does. gsmd doesn't. Jan 03 22:54:52 mwester: ah, ok. What is the plan, add this to gsmd ? Jan 03 22:55:10 mwester: and provide a socked for pppd ? Jan 03 22:56:23 I confess that I don't know the plan; I've chosen to step back a bit from this project for the past weeks. But as of 4 weeks ago, there was general community agreement that an alternate implementation of gsmd that would support muxing was required. Jan 03 22:57:29 At that time, it was also felt that the current gsmd could not be rewritten to do muxing. Yet work continues on the un-muxable gsmd -- so I have absolutely no idea what the plan is!! Jan 03 22:59:50 gsmd could easily do muxing and i partially implemented that but later was told that the muxing should be done in the kernel only Jan 03 23:00:46 and it makes sense because muxing in gsmd will be much more cpu intensive and may not keep up with the amount of data in gprs/edge Jan 03 23:07:11 that makes sense Jan 03 23:07:40 i have found references to a kernel driver called mux_cli but no source Jan 03 23:08:46 mux_cli won't work on neo1973 Jan 03 23:09:01 ok, there is another one, called ts0710.patch Jan 03 23:10:17 wow this thing is huge Jan 03 23:10:50 from the openmoko svn? Jan 03 23:10:54 this one has no actual TS0710 in it imlementation iirc :P Jan 03 23:11:07 *implementation in it Jan 03 23:12:01 http://svnweb.openmoko.org/trunk/src/target/kernel/patches/ts0710.patch?rev=2802&sortby=date&view=log Jan 03 23:12:09 really no official tarball for the kernel patchset? Jan 03 23:12:28 no idea if this is out-of-date Jan 03 23:12:36 thseiler: oh, this is the mux_cli code copied as is Jan 03 23:12:52 ah, outch Jan 03 23:13:07 LaF0rge: was going to rewrite it but then gave it up i believe Jan 03 23:13:10 Happy new year, thomas Jan 03 23:13:18 Hi mickeyl ! Jan 03 23:13:26 Happy new year too ! Jan 03 23:13:41 and now Writchie was working on his own kernel implementation, not based on mux_cli, Jan 03 23:13:47 re. MUX implementation. I'm waiting for Writchie to release it Jan 03 23:13:51 righto Jan 03 23:13:52 but it smelled awfully with vaporware to me Jan 03 23:14:35 hmm Jan 03 23:14:46 well, no one has seen anything of it yet, yeah Jan 03 23:14:58 i told to Writchie about two months ago and he had no comments Jan 03 23:15:07 s/told/told it/ Jan 03 23:15:07 balrog-kun meant: i told it to Writchie about two months ago and he had no comments Jan 03 23:15:09 it not an easy thing to do this right Jan 03 23:15:46 thseiler: yeah, i had my attempt on it too and the modem just wasn't responding consistently Jan 03 23:15:56 i suspect the s3c24xx serial driver Jan 03 23:16:45 * mwester suspects the serial driver is not as clean as it should be. :( Jan 03 23:17:00 and btw there was an interesting patch for it posted on LAKML today, fixing the baud rate generation Jan 03 23:17:12 Particularly the HW flow control; it doesn't look very well tested based on some of the issues around it. Jan 03 23:17:18 got the URI offhand? Jan 03 23:17:22 I saw that patch too. Jan 03 23:18:03 And another proposal from Ben Dooks just now suggesting that the s3c2410.c file be split up. Jan 03 23:18:54 http://lists.arm.linux.org.uk/lurker/thread/20080103.224911.b806f8d1.en.html Jan 03 23:19:08 and http://lists.arm.linux.org.uk/lurker/message/20080103.225556.fa1dbbd3.en.html Jan 03 23:19:25 mwester: yep that's it, i couldn't find it in google Jan 03 23:20:03 I didn't do the math to see if 115200 might be an affected baud rate, though. Jan 03 23:20:28 the serial driver also has a bug in no-fifo mode but this isn't used by default in the neo1973 kernel Jan 03 23:21:38 Hmmm... I've been tempted to turn off the hardware fifo so that one could test to see if an issue is related to the HW fifo or not (as in suspend/resume issues that I suspect exist) Jan 03 23:21:49 I guess that would only trigger more problems, huh? Jan 03 23:22:24 mwester: i turned off the fifo it to see if that would make the communication better but it turns out it couldn't keep up with 115200 bps without the fifo Jan 03 23:22:32 question: is the GSM uart exposed on testpoints, so that one could hook a logic analyzer ? Jan 03 23:22:52 the fix is quite simple for the bug, but im afraid it's inherently slower without fifo Jan 03 23:23:59 wasn't it also used for the kernel console ? so it might be available on the debug board... Jan 03 23:25:02 Probably it's wired *after* the chip that does the switching between the console and the modem. Jan 03 23:25:30 *is* there a switch in the first place ? Jan 03 23:26:11 Yes. There is a switch controlled by a GPIO that switches the serial port from the GSM modem to the console wires. Jan 03 23:26:34 as per the wiki http://wiki.openmoko.org/wiki/Debug_Board#Serial_Port Jan 03 23:26:47 anyone know if there is work to get OM reading SMS and phone book off SIMs? Jan 03 23:28:32 to bad... Jan 03 23:29:28 daMaestro: the libgsmtool is able to read SMS from the sim, but its a shell application. Jan 03 23:29:53 daMaestro: can't comment on the phonebook Jan 03 23:34:26 mickeyl: Is there a way to register another onscreen keyboard ? Jan 03 23:34:56 not with the current matchbox input method stuff Jan 03 23:35:15 we probably want to use hildon's new IM architecture Jan 03 23:35:24 so if i want to add another input method, i have to hack it into matchbox-keyboard atm ? Jan 03 23:35:48 ah wait Jan 03 23:35:50 no Jan 03 23:35:56 we already have multiple IMs Jan 03 23:35:57 yes, that would be a nice thing, don't know how much it ties into other hildon stuff. Jan 03 23:36:00 you just can't switch easily Jan 03 23:36:05 ah Jan 03 23:36:07 since the icon is not there Jan 03 23:36:29 if you manage to find the right spot, a popup menu should be visible Jan 03 23:36:38 right next to the open/close widget IIRC Jan 03 23:36:53 at least that's how it was last time i looked at it Jan 03 23:36:58 ok, something to investigate :-) Jan 03 23:37:24 a lot of plans have changed. will you be in Bern ? Jan 03 23:37:42 freesmartphone.org: 03mickeyl * r26 10/trunk/standards/otapi/org.freesmartphone.GSM.Network.xml: otapi: add service description for org.freesmartphone.GSM.Network Jan 03 23:38:30 you bet ! Jan 03 23:38:36 excellent Jan 03 23:39:52 i have unfortunately not yet found to time to deeply read trough the freesmartphne.org wiki :-( Jan 03 23:40:08 s/freesmartphne/freesmartphone Jan 03 23:40:12 take your time, it's just kicking off atm. Jan 03 23:40:26 mickeyl: have you looked at using telepathy APIs to cover at least call control and messaging? Jan 03 23:40:29 i'm working on a first draft of APIs and will launch an RFC soon Jan 03 23:41:33 Robot101: not yet. still on network. call and sms are next. got a link to the best API specs? Jan 03 23:42:00 well, the full d-bus API spec is at http://telepathy.freedesktop.org/spec.html Jan 03 23:42:11 we could do with some better overview docs but let me know if I can explain stuff to you Jan 03 23:42:43 there are already some codebases for using telepathy for SMS, and obviously with the SIP backend using the same API for calling and SMSing is an immediate benefit Jan 03 23:43:02 (SMS <- bluetooth -> GSM handset that is) Jan 03 23:43:02 is this spec file handcoded or generated from the xml description? Jan 03 23:43:08 autogenerated Jan 03 23:43:14 take a look in telepathy-spec Jan 03 23:43:14 cool! Jan 03 23:43:18 ok, will do Jan 03 23:43:18 we have some awesome generation stuff Jan 03 23:43:28 nice, i need that Jan 03 23:43:50 Just asking, the Freerunner is that the next OpenMoko phone, or is that the GTA02 (assuming new phone, but only just heard mention of it) Jan 03 23:44:06 gta02 Jan 03 23:44:15 we generate glib client and service side interfaces, python classes, and HTML docs, from an extended D-Bus introspection format Jan 03 23:44:17 It's the GTA02 Jan 03 23:44:18 Right Jan 03 23:45:00 Why is it they say on many sites it's just about to be unveiled, I mean we've known of it for ages Jan 03 23:45:38 mickeyl: you at any conferences soon? we should chat more :) Jan 03 23:45:58 Robot101: cutting down the number of conferences this year Jan 03 23:46:03 international only FOSDEM Jan 03 23:46:07 Robot101: Quick Question: How would you "hook" / intercept a connection request, aka implement some least cost routing / number prefix stuff ? Jan 03 23:47:04 thseiler: in telepathy? it would be a layer above. we've been considering some aggregate connection manager utility libraries, so you can actually run several protocols in th ebackend but present them upwards as one in the API, so that might be helpful Jan 03 23:47:14 Ah well Jan 03 23:47:16 Night :) Jan 03 23:48:35 bit would be the same way we'd handle weird stuff like yanoo/MSN actually using SIP to do their calling, or gizmo which has XMPP for roster/presence but SIP for calling Jan 03 23:48:44 s/^b// Jan 03 23:49:14 allow an intermediary connection manager to implement some policy for combining others, and expose a sane API that behaves as expected to the UIs that use it Jan 03 23:49:28 Robot101: So at the telephathy level it is already decided if its going to be a GSMcall or a SIP call. Jan 03 23:49:48 when it hits the telepathy API of ther GSM backend or the SIP backend, yes Jan 03 23:50:16 UI -> connection manager -> telephathy -> backend Jan 03 23:50:32 but if you wanted to export a "phone" backend that made some choices about which to use, you /could/ possibly implement that so that it just looked like another telepathy backend, but chose between SIP or GSM internally Jan 03 23:51:05 ah, terminology: telepathy is an API primarily, and a backend that implements the API is called a connection manager Jan 03 23:52:02 ok yes, i got it wrong Jan 03 23:53:52 so it could be: UI(s) -tp-> "phone" CM -tp-> SIP/GSM CM Jan 03 23:54:20 but that doesn't necessarily make sense, if you want the UI to show/allow you to choose which is being used, maybe the phone UI could actually know the difference between VOIP and GSM Jan 03 23:55:02 given you can only meaningfully have one GSM stack on a phone handset anyway, it's reasonable that the UI might special case its handling a bit Jan 03 23:55:11 right Jan 03 23:55:20 but that any other supported VOIP protocol will be handled by similar code paths too Jan 03 23:55:31 we made the telepathy SIP backend work on the iphone Jan 03 23:55:39 Robot101: can you comment on using dbus properties vs. "regular" Get methods? Jan 03 23:55:52 respect... Jan 03 23:56:30 mickeyl: d-bus properties are pretty lame IME because they don't have change notifications, don't have readability/writability changes, and are very poorly supported by any bindings Jan 03 23:56:42 mickeyl: so we have telepathy properties for stuff such as IRC/MUC settings, and a few other things Jan 03 23:56:57 mickeyl: we have Get methods when you might expect the CM to go and do some network requests and stuff to find information out Jan 03 23:57:15 properties are more "just there", and we use methods for "go and get something, go and change it" etc Jan 03 23:57:53 i see. ok, i will refrain from using them now Jan 03 23:58:28 a bit like GET / POST distinction with html... Jan 04 00:00:09 Robot101: How about conference calls and hold Jan 04 00:00:53 I'm about to update those interfaces, but basically holding is pretty straightforward, you just toggle a boolean on the channel Jan 04 00:02:10 Well the thing is , in GSM its not boolean... When you have two calls, and you put one on hold, you get the other. Jan 04 00:02:45 and un-holding two connection would merge them into a conference. Jan 04 00:02:59 not quite Jan 04 00:03:10 you have an active call, a held call, and a waiting call Jan 04 00:03:36 right and an at command to swictch them Jan 04 00:03:43 ah, and a conference call Jan 04 00:04:12 you can roll the active or held call into the conference, or split a participant back out ((maybe, although I've yet to see a handset that would let you :D) Jan 04 00:04:30 if it's a 2 way conference i guess its not hard, but the menu gets clunky if you want to chuck one guy out :) Jan 04 00:04:46 :-) Jan 04 00:04:54 the telepathy interface would look roughly like "merge that channel into this one", or "split this guy out into a new channel" Jan 04 00:05:24 so you start with channel #1 calling alice Jan 04 00:05:29 put her on hold Jan 04 00:05:40 call with channel #2 bob Jan 04 00:05:41 we want to draft this so we can cover the call handling you could expect to do on a GSM phone, prototype it with tp-phony, hadess' backend which talks to handsets with bluetooth Jan 04 00:05:52 then merge both channels. Jan 04 00:06:13 yeah, well the object path of either call is pretty arbitrary, so you pick one and merge the other into it Jan 04 00:06:19 and you're left with one channel with alice and bob in Jan 04 00:06:34 and I guess it's either held or not depending which the channel you started with is Jan 04 00:07:49 sounds simple to implement in the UI, and that is nice. Jan 04 00:07:54 but this is the same kind of API you need to drive a CTI phone too Jan 04 00:08:20 so if it hangs off a PBX and you have a conference button you can press or unpress to merge the held call with the active one, or unmerge them Jan 04 00:08:23 it works there too Jan 04 00:08:50 ok, one last thing that comes into mind: USSD Jan 04 00:09:09 Unstructured Supplementary Service Data Jan 04 00:09:15 ah, train is arriving, will need to get back in a bit Jan 04 00:09:28 ok, was a nice talk, thanks a lot Jan 04 00:15:08 ok, N810 :) Jan 04 00:15:29 * Robot101 looks up USSD Jan 04 00:18:21 hehe Jan 04 00:19:06 its used behind the scenes for things like enable voicebox, etc... Jan 04 00:19:36 basically you call (usind ATD command) a number that looks like *1234...# Jan 04 00:19:45 But you get a text message back Jan 04 00:20:02 that's the unstructured Jan 04 00:21:20 its also used to query the amount of money left on your prepaid, cost of last call, date and time Jan 04 00:22:59 right Jan 04 00:23:01 The complex thing is, that is has a session context, meaning that once you have dialed, you can send unstructured text messages back. Jan 04 00:23:28 so we'd need to add API for it I guess Jan 04 00:23:40 but thats not a problem Jan 04 00:23:54 question is of its possible to wrap it into a messageing session Jan 04 00:24:09 you can add interfaces to the Connection, or new channel types, etc Jan 04 00:24:31 well, not whether its possible, but whether its desirable Jan 04 00:24:48 right, everithing is possible Jan 04 00:24:59 if its giving you a menu and you're picking choices, it doesn't make sense to use a chat UI fori Jan 04 00:25:04 *it Jan 04 00:25:21 its a rather complex beast Jan 04 00:25:37 you can have it the menu way, or you can have free form text answer Jan 04 00:26:11 so I'd imagine we'd write gsm-specific extensions to allow a UI to do what it wanted Jan 04 00:26:41 its ok to do that in telepathy, you're not restricted to just the stuff we thought about in the spec Jan 04 00:27:02 you can extend anything with extra interfaces or new types Jan 04 00:27:34 great, so i need to read the whole specs, i guess Jan 04 00:27:41 and re-use all the handy code gen tools to make client/service code to speak your extensions too Jan 04 00:28:09 now that is a *very* nice feature Jan 04 00:28:19 :) Jan 04 00:28:52 * Robot101 is very pleased with our code generation and spec wrangling ninja, smcv :) Jan 04 00:29:35 Ganneff \o/ Jan 04 00:29:50 * LarstiQ couldn't find the previous topic in his backlog Jan 04 00:29:58 you want topicdiff.pl in irssi Jan 04 00:30:06 Ganneff: thanks Jan 04 00:32:28 i hate those idiotic kids Jan 04 00:44:20 was anyone on here earlier when albrite was having problems getting mokomakefile to compile u-boot-openmoko? I am having the same problem and think it my be systemic. Jan 04 00:44:25 any help? Jan 04 00:45:24 sounds like you need to rename uboot-openmoko_foo to u-boot-openmoko_foo until OM resyncs with OE Jan 04 00:45:52 what is the source of this problem? Jan 04 00:46:43 someone from OpenMoko build team pulled from OE without checking whether the particular HEAD revision actually builds Jan 04 00:46:57 hence had the bad luck to sync with a non-building rev Jan 04 00:47:03 some revs after that rev it was ok again Jan 04 00:47:10 but they did not sync. again yet Jan 04 00:48:42 will they realize their error and fix it in the near future or is this going to be a continuin problem, my first complete build went so nicely that Im kinda surprised about this Jan 04 00:48:55 well Jan 04 00:49:08 i will tell them Jan 04 00:49:23 no guarantee it'll never happen again though :D Jan 04 00:49:23 I don't expect you to know, I just want your thoughts on it Jan 04 00:49:38 it should not happen Jan 04 00:49:57 the whole idea of being some revs after HEAD is keeping a rev that builds Jan 04 00:50:10 generally Jan 04 00:50:35 yea Jan 04 00:50:53 and only updating once a full rebuild run through successful Jan 04 00:50:58 at least that's the idea Jan 04 00:51:27 guess what Im wondering is should I try to fix this now or just wait until 9ish in the morning and retry then Jan 04 00:52:30 i don't know how often the sync happens Jan 04 00:52:43 might as well try org.oe.dev for once Jan 04 00:53:00 once the sync happens, will I have to undo changes I make? Jan 04 00:53:23 mickeyl: couldn't you add the syncscript to some automated buildhost as the last target ? Jan 04 00:53:43 then it would only get executed when the build was successfull, or so goes the theory Jan 04 00:55:07 it's the build team's call, but yes, i can suggest that Jan 04 00:55:37 i dropped that responsibility *phew* :) Jan 04 00:56:54 haha, you said to try org.oe.dev, what would I need to do Jan 04 00:56:54 ? Jan 04 00:57:09 mtn pull org.openembedded.dev Jan 04 00:57:17 no idea offhand using mokomakefile Jan 04 00:57:19 some make command Jan 04 00:57:23 but i can't remember these targets Jan 04 00:57:29 anyone ? Jan 04 00:57:47 mokomakefile is make openmoko-devel-image Jan 04 00:58:04 but would this be using openembedded instead Jan 04 00:58:07 no Jan 04 00:58:15 mokomakefile encodes every operation into a make target Jan 04 00:58:25 you need to check the actual Makefile to see which target pulls from OE Jan 04 00:58:33 or just call mtn manually :D Jan 04 01:00:09 * thseiler imaginges a "make menuconfig" :-) Jan 04 01:01:28 well, it's a fundamental disagreement whether to use make targets to enable people getting stuff done or to promote using the native commands so that people actually learn what they are doing Jan 04 01:01:40 s/it's/there's/ Jan 04 01:01:40 mickeyl meant: well, there's a fundamental disagreement whether to use make targets to enable people getting stuff done or to promote using the native commands so that people actually learn what they are doing Jan 04 01:01:56 the jury is still out on that :) Jan 04 01:02:20 guess it isn't possible to use a rev which isn't HEAD is it? Jan 04 01:02:35 mtn checkout -rev Jan 04 01:02:55 (no idea using the mokomakefile, sorry) Jan 04 01:04:41 I've only been doing embedded development for about a month, can you give me the rundown of how you do your development for this and other things like it. Ive been watching this channel and you know what you are doing so I would always like more info on the process Jan 04 01:05:36 depends on the layer you are actually working on Jan 04 01:05:36 freesmartphone.org: 03mickeyl * r27 10/trunk/standards/otapi/ (3 files): otapi: first cut at org.freesmartphone.GSM.SIM Jan 04 01:05:45 so GTA02 is 500mhz? :) should help video playback nicely Jan 04 01:05:45 i develop my applications using X Jan 04 01:05:58 only if they run i cross-compile using OpenEmbedded Jan 04 01:05:59 Psi_: yes. Jan 04 01:06:03 :) Jan 04 01:06:03 Psi_: the power of typos Jan 04 01:06:25 you can do application development using a cross toolchain that's already made Jan 04 01:06:29 no need to use OE for that Jan 04 01:06:35 but if you are into distro customization Jan 04 01:06:37 you better use OE Jan 04 01:06:44 err, is it yes or a typo Jan 04 01:07:17 * mickeyl mumbles about the chip theoretically being able to run at 500, but no one would want to do that Jan 04 01:07:26 magellan: http://wiki.openmoko.org/wiki/Toolchain Jan 04 01:08:33 it works fine Jan 04 01:08:35 I have made an application and it compiles with toolchain, I also needed to patch in the usbhost patch which now works too. so most everything Im working on now is doing ok, but yesterday I screwed up my moko build directory and now Im starting over Jan 04 01:09:08 hmm Jan 04 01:09:12 moko makefile says you can do development with that, is that common? seems a little hacked Jan 04 01:09:38 mokomakefile comes from days where we did not have a toolchain Jan 04 01:09:47 now 90% should not be using OE nor mokomakefile Jan 04 01:09:48 ah Jan 04 01:10:01 anyone knowing offhand what's the AT command to get the auth code retry counter? Jan 04 01:11:24 Im going to be doing more development for this in the future, should I start migrating to OE? Jan 04 01:11:54 like i said, if you are into actual distro customizing, i.e. removing packages, adding new ones, custom image types etc. Jan 04 01:11:56 then yes Jan 04 01:12:05 if you just want to build a recent image once and then Jan 04 01:12:07 stay with mokomakefile Jan 04 01:12:26 plus there are nightly builds nowadays IIRC Jan 04 01:12:53 speaking about nightly Jan 04 01:12:55 it's time for me Jan 04 01:12:57 g'night Jan 04 01:13:08 good night Jan 04 01:16:45 mickeyl: thanks for all the help! Jan 04 01:18:01 I think someone should update the topic to spring Jan 04 01:43:51 http://myex.ath.cx/?id=5b23b90f **** ENDING LOGGING AT Fri Jan 04 02:59:56 2008