Re: Information about linux drivers for voice in neofreerunner........
On Wednesday, January 18, 2012 18:19:41 Arslan Abbasi wrote: Simple recording and playback of recorded sounds can be done but, can anyone give me some clue if it has enough processing power to do real time voice processing and transmitting processed voice at the same time. And please, if anybody has any code related to voice manipulations on this phone or in particular real time voice processing while transmitting through gsm, share it. It'll be very nice of you. @Dave... Encrypting gsm is legal in our country, and as far as i think encryption shouldn't be illegal coz voice/data is your private property so protecting it further shouldn't be a problem with anybody as long as it doesn't affects their systems. What I've found in the archive is this thread: http://lists.openmoko.org/pipermail/community/2007-February/002878.html But it's not the thread I remember, i think there was somone who did it for real as a bachlor thesis or sth like this... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Information about linux drivers for voice in neofreerunner........
On Wednesday, January 18, 2012 08:56:45 Radek Polak wrote: On Wednesday 18 January 2012 07:16:06 Arslan Abbasi wrote: The Inter IC sound pins interfaced with the audio codec. I need help regarding any sound manipulation on this platform, if any code is available. IIRC there was a program which recorded phone call if this is what you need. I dont know how it's done on GTA02 but on GTA04 phone modem is just another sound card which can be used by alsa programs. E.g. you can play mp3 instead of speaking. Regards Radek There was already somebody who developed a program to do encrypted GSM calls with two FR. But i don't remeber who it was. But one should find something in the archive of this mailinglist. Regards, Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [opkg] Cannot install package package.tar.gz
Am Freitag, 24. Juni 2011, 15:41:38 schrieb Gilles Ganault: Hello I've never built packages before (Debian or opkg). I used the following short article, but it doesn't work: http://inportb.com/2010/10/19/making-an-opkg-package/ When I try to install the package on a Linux appliance: = var/tmp ./opkg-cl install package.tar.gz Unknown package 'package.tar.gz'. Collected errors: * opkg_install_cmd: Cannot install package package.tar.gz. = A opkg package is ar package not a tar.gz. So just package it the right way and it should work. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[ANNOUNCE] release candidate 4 for new SHR-testing 2011.1
Hi, yesterday we hopefully fixed the bug that shr_elm_softkey doesn't start. The problem was, that a part of the autostart function of e17 uses mmap, but mmap doesn't work on jffs2. We bumped the version of efreet to a newer version where some of the mmap usages were removed. But raster likes mmap very much, so we will probably see more of these failures in e17 when it's used on jffs2. So we have 2 possiblilities for the future, either drop jffs2 images in favor of ubifs or move all parts where e17 writes to to a tmpfs. I would prefere the first one, because it's less work. But i won't decide this on my own. Because this was one of the two major bugs, i made an RC4. Changes since RC3: * shr_elm_softkey bug fixed * foxtrotgps bumped to version 1.0.1 * some toolchain improvements * fixed voiphandset statefile * small fix in shr-settings (timezone lable) * fix segfault when new desktop item is added * fix segfault in libphone-ui messages list * E battery indicator now uses FSO as backend * fix sefault when GSM provider lable contains garbage * newer ffphonelog version * newer iliwi version Thanks to all the people who helped fixing these bugs. Regards, Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANNOUNCE] release candidate 1 for new SHR-testing 2011.1
Am Mittwoch 23 März 2011, 22:47:56 schrieb Jan Vlug: I've been using SHR-testing 2011.1 for a while now and experienced the following problems: - white screen after reception of a text message. i will look if i can reproduce this. - not always new message icon on lock screen. the lockscreen is a bit slow in refreshing those informations, doesn't it show the new message even after one or two minutes? - unable to add number to contacts (issue#1310) #1310 is about a bug in pyphonelog, i will look if i can reproduce this. - sometimes gsm network lost according to the icon in the top bar This is known and like i've written on shr-user list we need logs from this crash to find the cause because i can't really reproduce it. - shutdown from quick settings menu does not work (related to issue #1170 or issue #1205?) #1170 and #1205 are fixed, and shutdown from quick settings works fine for me, just the first try doesn't work because of a bug in elm_add_lable. I'm currently trying to debug this. - complete freeze (I have to take of the battery to reboot) I need logs for this too. -once tangogps did not update the map anymore have you tried foxtrotgps if it's there too? Anyway tangogps and foxtrotgps bugs should be reported upstream as we can't fix them. Would you like me to create issues in trac for all mentioned problems ? if you like you can do so. I've no additional programs installed. In general I can use the freerunner as a daily phone. Kind regards, Jan. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANNOUNCE] release candidate 1 for new SHR-testing 2011.1
Am Dienstag 14 Dezember 2010, 19:15:37 schrieb omcomali@porcupinefactory.org: Fortunately, only root folder's metadata were lost. Everything important was recovered and backed up :) More tests: the pim database, keyboards and dictionaries worked after I found the correct paths. To replace pim, I stopped phoneui, put it in the right place, started phoneui again, worked great. After 2 days of uptime, something broke and neither wlan or modem work. I tried disabling and enabling the modem (it was pretty common for it to fail like that with my SIM), but the logs say something about operation not permitted while modem is suspended. When trying to access wifi via the Connectivity dialog or fsoraw the respective program freezes for a few minutes, and I'm getting some DBus timeouts. That's it for today. Cheers, rhn Can you provide some logs about this issue? Regards Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANNOUNCE] release candidate 1 for new SHR-testing 2011.1
Am Sonntag 12 Dezember 2010, 11:16:41 schrieb Dr. H. Nikolaus Schaller: Am 11.12.2010 um 13:47 schrieb Thomas Zimmermann: Hi, i want announce the RC1 for the upcomming SHR-testing release in 2011. http://build.shr-project.org/tests/shr-testing/images/om-gta02/ So please test these images and report the bugs so that we can release a really working SHR-testing. Good work! Does the kernel already support the Freerunner Navigation Board? Nikolaus No idea about this, perhaps Radek or JaMa can tell us. If there is support for the Freerunner Navigation Board in the official om-2.6.34 kernel then it is in this kernel also. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANNOUNCE] release candidate 1 for new SHR-testing 2011.1
Am Sonntag 12 Dezember 2010, 13:54:33 schrieb omcomali@porcupinefactory.org: Hey, The moment I read this email, I forced myself to do a reinstall. So far, so good. The switch from Illume to Illume2 was a bit confusing, but I got used to the interface. The first impression: it's so fast! Scrolling is finally smooth! And it doesn't have problems with my SIM card any more (old shr-testing always complained that no sim card is present but sometimes managed to start GSM). The speed after 1 day of usage is rather good. Now on to the bugs: TangoGPS was having trouble displaying the correct time from GPS the first time I ran it. It stayed at ~epoch, while position was more or less correct. The top shelf and home screen clocks don't update after resume (I noticed this only today, after the alarm clock set off), until the minute changes. There are some trouble with resizing windows properly when a new window is shown and the keyboard was visible. The keyboard hides, but the new window is not fully sized. Try showing the keyboard and pressing AUX. Eve crashes with illegal instruction. Soon I will restore my custom settings (PIM, maps, keyboards) and report again. Thanks for restoring SHR-t to life! rhn The bug with the keyboard resizing is known too, i forgot to mention this. Bug it is just ugly and i don't know if i will switch to a newer E just for this, because newer E means often more new Bugs :) For eve and ewebkit i have to take a look there were some more problems and i thought i included the working version :) For the other bugs i will have a look too in the next days. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[ANNOUNCE] release candidate 1 for new SHR-testing 2011.1
Hi, i want announce the RC1 for the upcomming SHR-testing release in 2011. http://build.shr-project.org/tests/shr-testing/images/om-gta02/ So please test these images and report the bugs so that we can release a really working SHR-testing. The image is based on the 2010.12 release of OpenEmbedded and has latest versions of E, SHR and FSO apps. Since last testing a lot has changed: * Switch to illume2 as illume(1) isn't maintained anymore * Switch from ogsmd to much faster fsogsmd * Switch to 2.6.34 kernel (without KMS because this causes some problems with SD-cards for some SHR-u users) * Everything faster ;) * And much more i don't remember Known Bugs: * There is a problem with the autostart of applications in E, because of that the shr_elm_softkey is not always started. * The wizard is only working if you wait until FSO is fully started (When FSO is started the display started dimming). If you don't want to wait that long you can exit the wizard with the Exit button and do the configurations in shr-settings afterwards. Untested: * All feed packages not in the full image. * All day usage (so GPRS/GPS after several suspends) Because of a missunderstanding this SHR-testing version was synced to the normal shr-testing feed and some users have already upgraded theire old SHR- testing to this version. We reverted this for now and moved the old SHR- testing files back in it's place. Those and all Tester should change the package feeds from: http://build.shr-project.org/shr-testing/ipk/... to: http://build.shr-project.org/tests/shr-testing/ipk/... to get the corresponding feed packages. An upgrade from older SHR-testing seems to be broken, so for first tests you should flash a new image. If you backup your homefolder and copy it back then you should remove ~/.e from this backup as the shr-wizard won't run if this folder exists. And the wizard is responsible for the creation of some important files. The future plans are to release another RC this year and then release the final image in the first week of 2011. I hope that i said everything and a lot of people will test these images :) Regards Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Voicerecording software needed
Am Montag 04 Oktober 2010, 19:57:40 schrieb Alexander Lehner: On Mon, 4 Oct 2010, Rui Miguel Silva Seabra wrote: Dictator worked just fine for me a few months ago. Maybe it's a new problem. Can you try to explain how or why it doesn't work? I first forgot to mention that I'm using the latest SHR. I installed it the way the wiki page says http://wiki.openmoko.org/wiki/Dictator My problem seems the wave support for python: o...@om-gta02 /media/card # opkg install -force-depends Have you tried to install the version of dictator wich is in the SHR feed? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Voicerecording software needed
Am Dienstag 05 Oktober 2010, 12:10:19 schrieb Alexander Lehner: On Tue, 5 Oct 2010, Thomas Zimmermann wrote: Have you tried to install the version of dictator wich is in the SHR feed? I did not find it. It's in the SHR-u feed: http://build.shr-project.org/shr- unstable/ipk/armv4t/dictator_0.2-r3.5_armv4t.ipk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] toolchain (again)
Am Freitag 20 August 2010, 01:04:55 schrieb W. B. Kranendonk: Hi List, I'd like to start trying to contribute to the Openmoko-ecosystem in a more meaningful manner than lurking the mailinglists. I also like to see if I can add my own twist to my phone (running SHR-U). I imagined combining those two wishes by getting a toolchain running and see what happens to the code I put through it. Hi, there is a problem with a toolchain for SHR-U: in SHR-unstable eglibc and gcc changes really often. If one of those changes the whole toolchain needs to be recompiled, because every lib needs to be build with the current eglibc and gcc version to run properly. In this case you would have to download a new toolchain about every week, because of that there is no toolchain for SHR-U. So to build an app for SHR-u you have to set up a bitbake enviroment like discribt in [1] and then create a recipe for your app like discribet in [2]. But this is a long process, it needs about 10 hours on my PC (2,8GHz core2duo, 8Gb ram) and downloads about 15Gb of data, so a more powerfull machine then your laptop would be good. If you don't have another PC you can come to the #openmoko-devel IRC channel, perhaps we can find a solution for you. Greets Thomas [1] http://shr-project.org/trac/wiki/Building%20SHR [2] http://shr- project.org/trac/wiki/Howto%20get%20my%20application%20in%20the%20SHR%20feed ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-T] Images from 29th of May
Am Donnerstag 22 Juli 2010, 10:33:58 schrieb Risto H. Kurppa: Some things I've noticed that propably exist also in the latest unstable images: 1) Importing contacts from SIM sometimes imports only partial number, the last digit is missing Can you send me the (uncensord) log while importing contacts of phoneuid in debug mode? 2) The contacts are sorted case-sensitively: [A-Z][a-z]: Alpha is the first, alpha is then somewhere in the middle, after Zulu. 3) Same issue as 2) - but with home view icons: Ventura and Zorro are listed before alpha and omgps 4) Iliwi is missing a button to disconnect from a network 5) SIM manager doesn't sort contacts alphabetically The SIM manager sorts the contacts accordingly to the slots number on your SIM. But seems to work for phone calls quite well. Risto Regards Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing feature
Am Montag 21 Juni 2010, 11:54:57 schrieb Fox Mulder: I had to replace a few program paths which were no more correct. But then the first try was not so successfull as i hoped. It seems that the script tries to create a simple gui which fails with an AttributeError. /usr/lib/python2.6/site-packages/dbus/connection.py:242: DeprecationWarning: object.__init__() takes no parameters super(Connection, self).__init__(*args, **kwargs) Let's go on Traceback (most recent call last): File ./notifier, line 337, in module win.destroy = destroy AttributeError: 'elementary.c_elementary.Window' object has no attribute 'destroy' When i just remove the line 337 and run it i got another error: Traceback (most recent call last): File ./notifier, line 360, in module bt_calls.clicked = show_missed_calls AttributeError: 'elementary.c_elementary.Button' object has no attribute 'clicked' When i also remove the two lines for the clicked event the script seems to run. But when i call myself and hang up nothing happens. I don't know if nothing hapens because of the commented out gui lines or if the code doesn't work anymore in general. I see that there are quite some dbus calls and maybe the syntax for them also has changed. :/ When i interpret it right then the gui part only shows the missed calls/sms. So maybe the gui part isn't needed anymore because we can use opimd-notifier to show the missed calls/sms. But without the script's gui we need another way to confirm and deactivate the reminder. Ciao, Rainer Callback handling in python elementary changed in november 2009: http://lists.shr-project.org/pipermail/shr-devel/2009-November/001374.html That script still uses the old way, so you have to change it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U: Empty VT on resume
Am Donnerstag 17 Juni 2010, 00:06:59 schrieb pike: Hi has this SHR-U: Empty VT on resume http://shr-users-discussions.2691941.n2.nabble.com/SHR-U-Empty-VT-on-resume -td5005437.html ever been solved ? I've basicly stopped taking my phone with me once this has started. people refer to me as the guy with the open-no-phone :-) For me the issue was gone with the images from mid may. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] feeling less adventurous
Am Samstag 08 Mai 2010, 12:18:25 schrieb pike: Hi I flashed shr-u onto my Neo twice yesterday, and both times, though it worked fine at first, it didnt survive a deep sleep and never successfully booted again (*). So, I'm feeling less adventurous already. This used to be my daily phone :-/ What would be a best choice to have a working phone that uses FSO ? SHR-t ? Debian ? curious, *-pike (*) after deep sleep, it returns to a black window with a blinking cursor - looks like x doesnt start. after reboot, i get the wellknown unknown boot option g_ether_bla, i get the pinguin for a while, then it returns to unknown boot option g_ether_bla. again it looks like x is not starting; I hear interference over my stereo, as if GSM is booting. If anyone has an idea, let me know. We are analysing this problem. The discussion about this is on the SHR-user ML. The Thread about Empty VT. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: player
Am Donnerstag 08 April 2010 05:42:41 schrieb jeremy jozwik: On Wed, Apr 7, 2010 at 8:39 PM, Rafael Ignacio Zurita rizur...@yahoo.com wrote: mplayer via command line on ffs (and using qtmoko) works okey (pause and other functions) eh, shr-u here... We are currently trying to stablize SHR, and intone (mplayer) isn't part of our milestone 1. Because of that it's not getting that much attention from us. I think the correct solution would be to compile mplayer with alsa support. To workaround the oss problem you can install alsa-oss and then use aoss to start intone. Or install kernel-modules-snd-oss, but i think there were some problems with oss kernel modules installed... But there can also be a problem in intone that it doesn't work with newer E. Please try and report the results. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thone 0.5
Am Donnerstag 01 April 2010 00:29:47 schrieb pike: Hi http://wiki.openmoko.org/wiki/User:Pike/Thone I have .ipk now http://jama.homelinux.org/org.openembedded.shr/all/thone_0.5-r0.4_all.ipk Cool! Thanks! Now, as was to be expected, I fixed some bugs and upped a new version, 0.6 .. with a different url .. wouldnt it be easier if I hosted that ipk myself, on googlecode ? .. so i was trying to untarzip your ipk file to see if I could update it but it gives tar: invalid tar magic. isnt it a tarzip ? .ipk are ar archives containing 2 tar.gz archives I'm wondering how to proceed. Never done this. Given the way .ipk works, I dont see the need for a makefile. I can imagine how Martin's recipe looks like and it's probably very ugly and just for your current version. If you add an additional file or rename one then that recipe won't work anymore. If you provide a Makefile then it will look nice and be independent on what you in your programm. That way it's much much easier to maintain for the package maintainer. And writing a Makefile is a matter of 5 minutes for you... BTW: Haven't seen your real name to fill AUTHOR field properly.. but nick will be enough if it is intentional ;) . Yeah, pike will do :-) thanks, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing-latest] can't read SIM contacts and messages
Am Montag 29 März 2010 10:49:06 schrieb Tony Berth: Dear Team, I just did a new install of the latest SHR-testing image but can't get the existing SIM contacts and messages! Is that a known problem? Thanks Tony It's explained on the shr-user ML: http://lists.shr-project.org/pipermail/shr-user/2010-March/003972.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: elm_browser initial release
Am Sonntag 14 Februar 2010 11:39:18 schrieb Lars Hennig: Am Sonntag 14 Februar 2010 schrieb Petr Vanek: How about ~ by default but having it as a configurable string? And the downloader perhaps too? wget. Some might change it to wget -c (continue downloading) Even better would be /media/card as there is usually more space... And what is, if someone has no sd card, or is running from it? Then that directory is missing. This should be sth the user can choose. So please include a option to configure that directory. Regards ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Jefliks Jabber-Client release
Am Sonntag 14 Februar 2010 21:46:29 schrieb Richy: On opkg jefliks was just posted. afaik it is the fastest JabberClient out there. (And the only one I know that is based on EFL) http://www.opkg.org/package_331.html Enjoy 668c16bc69 668c16bc69 I tried to package it for SHR but i can't get it compile. I think it's taking the wrong pkg-config. Is it possible that the author switches to autotools? Then it would be much easier to package. Regards Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External blkid library not found
Am Donnerstag 21 Januar 2010 09:49:48 schrieb Vaudano Luca: Hello, I'm trying to compile a simple Elementary application against SHR-Testing with the bitbake system. I stuck on this error: http://lists.uclibc.org/pipermail/uclibc/2009-August/042875.html I installed libblkid-dev and uuid-dev packages but anything changed. Any hint? Thanks in advance Luca Did you add a DEPENDS on blktool to your bitbake recipe? Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External blkid library not found
Am Donnerstag 21 Januar 2010 10:06:50 schrieb Vaudano Luca: No, I didn't. Now it's only DEPENDS = elementary. Thanks Then you should do it. You need the libary in your bitbake tree and not on your buildhost system. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: elm_browser initial release
Am Donnerstag 14 Januar 2010 09:00:27 schrieb c_c: Petr Vanek wrote: toggle loading-displaying images Any ideas how webkit does that? Don't know about ewebkit, but with webkit-gtk it's just setting settings = webkit_web_view_get_settings(WEBKIT_WEB_VIEW(web_view)); g_object_set ( settings, auto-load-images, active, NULL); webkit_web_view_set_settings (WEBKIT_WEB_VIEW(web_view), WEBKIT_WEB_SETTINGS (settings)); Thanks. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth PBAP support for FSO
Am Dienstag 05 Januar 2010 21:55:33 schrieb Thomas Franck: On 01/04/2010 11:46 AM, Thomas Zimmermann wrote: http://downloads.vdm-design.de/obexd_0.20-r0.4_armv4t.ipk downloaded and installed that.. But i think sth more is needed. We need an bluetooth agent that knows about obexd. Perhaps simple-agent does. I used simple-agent before (see the thread here: http://n2.nabble.com/SHR-unstable-Bluetooth-pairing-with-BMW-Pro-Radio-car- handsfree-fails-tp3060247p3060247.html ) will try when I manage to set everything up.. :) then obexd needs to be started with -p option, the /etc/dbus-1/services config file doesn't do that in my current version, so you have to add that option there. I don't even have a obexd.conf in the system.d folder.. :S Cheers, Now i've implented all mehtods avaible in obexd. And changed the dbus service file. You can download the package at: http://downloads.vdm-design.de/obexd_0.20-r1.4_armv4t.ipk Please try and report the result. I hope it's working but i'm not sure. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: phonefsod: duplicates frameworkd configurations?
Am Sonntag 10 Januar 2010 16:35:24 schrieb arne anka: looking into phonefsod.conf i see, that it duplicates already existing fso configuration: - brighness - dim - idle_screen - suspend none of the above strikes me as especially particular to the _phone_ functionality -- in fact, imo they heavily interfere with settings made elsewhere in frameworkd.conf or rules.yaml and being applied to the device as a whole. why tries a _phone_ daemon to handle stuff common to the overall functionality? Such questions about SHR apps should be asked on the shr-devel mailinglist, because half of the authors of phonefsod aren't reading this ML. As far as i know phonefsod does these things because FSO doesn't handle it correctly. So until it's working correctly in FSO this is done in phonefsod too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fake nmea device
Am Samstag 09 Januar 2010 12:44:36 schrieb Christian Rüb: Hi as I am still debugging my Qt dbus problem I installed DSO packages from [1] on my local Debian box. But I do not have a real GPS and no blueetooth. So, is there a way to fake a GPS device (something like cat'ing a NMEA log to a FIFO) to trick frameworkd? Thanks for your help. Cheers, Christian What about gpsfake[1].? Should be part of gpsd-clients in debian. Thomas [1] http://gpsd.berlios.de/gpsfake.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth PBAP support for FSO
Am Montag 04 Januar 2010 11:12:11 schrieb Thomas Franck: Happy New Year! Happy New Year :) I'm back home.. well.. at work now.. What do I have to prepare in order to test your plugin? I think it's not working, because i implemented just 1 of the 3 calls. And it seems the other 2 are more often used :) I will do the other too this week. But if you want you can try the current version. http://downloads.vdm-design.de/obexd_0.20-r0.4_armv4t.ipk But i think sth more is needed. We need an bluetooth agent that knows about obexd. Perhaps simple-agent does. then obexd needs to be started with -p option, the /etc/dbus-1/services config file doesn't do that in my current version, so you have to add that option there. Cheers, ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Quick e-mail poll: Still using your Freerunner?
Am Dienstag 29 Dezember 2009 21:30:53 schrieb Risto H. Kurppa: Do you use FR as your daily/primary phone? No Do you use FR as your primary PDA? No What distribution you run most of the time? SHR unstable If you don't use FR as your daily phone/PDA, what phone did you change over to, and why? Palm Pre (but never used FR as primary phone), i'm seeing the FR as my toy. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth PBAP support for FSO
Am Freitag 25 Dezember 2009 17:53:43 schrieb Thomas Franck: I am very interested in this, too.. I've wanted to get my FR to connect to my bmw car system ever since I got it.. and it always played up, didn't want to talk to the car at all.. FR was happy with the BT connect but my radio was still asking for data (IIRC, the error codes that the FR BT stack gave was that it got a PBAP request which it just simply dropped due to lack of support).. So a connection never ever got properly established.. :( I'll be back home and able to test things on the 3rd of January.. Cheers, That's great. The first test resulted in a crash of the PBAP plugin, so i've to look at this. Will tell you if i have an new version, but i will wait till the new year before i do some more on this. Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth PBAP support for FSO
Am Donnerstag 24 Dezember 2009 00:23:50 schrieb Denis Johnson: On Thu, Dec 24, 2009 at 3:31 AM, Thomas Zimmermann m...@vdm-design.de wrote: So is someone out there who owns a handsfree, car or sth else that supports showing contacts and/or missed calls over bluetooth? I have a Ipaq 4150 running Windows CE and CoPilot Navigator which uses bluetooth gps and software supports various live communications for things like traffic, live location feed and receiving trips from base info but I think that's all using GPRS so probably not much help to you I think so too, PBAP is a special protocol developed form the automotion industrie, primarly for buildin handsfree (as far as i understood). So i think the same as you, but i found someone that has such an device. So he can try it for me :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Midori Browser Config
Am Donnerstag 24 Dezember 2009 12:30:21 schrieb Michal Brzozowski: 2009/12/9 Andrew Stephen andrew.step...@gmail.com Hi Thomas, I've just tried 1) with literki and it doesn't have the same problem, so I think you're right, and it does seem to be an Illume keyboard problem. Is there an way to turn off autocompletion? The menu with completion choices appears on top of literki, and it's impossible to write anything. There is a menu option to disable the autmatic search. But nothing to disable the autocompletion. But that feature causes problems for us, so we should ask the midori guys to add an configure option to disable this. Midori guys are nice, best and fastest way to talk to them is just joining there IRC channel (#midori @ freenode) and ask. So feel free to ask them :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Bluetooth PBAP support for FSO
I'm currently trying to add FSO support to obexd. With these plugins it will be possible to see missed calls and contacts from the FR (or any other phone running FSO) on a bluetooth device supporting PBAP (Phone Book Access Profile). Half of work is done. But now i'm looking for someone who can test the implementation for me. So is someone out there who owns a handsfree, car or sth else that supports showing contacts and/or missed calls over bluetooth? Please let me know. Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: [Shr-User] SHR-testing upgrade. PLEASE READ BEFORE UPGRADING
-- Weitergeleitete Nachricht -- Betreff: [Shr-User] SHR-testing upgrade. PLEASE READ BEFORE UPGRADING Datum: Dienstag 22 Dezember 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: SHR-user shr-u...@lists.shr-project.org, SHR-devel shr- de...@lists.shr-project.org I just pushed an update to the shr-testing repository. How to upgrade and what has changed? -- Make big upgrades work -- This upgrade will unfortunately require manual attention. Why? opkg downloads all upgrades to /tmp (which is in RAM), so for big upgrades your RAM will be full even before it starts upgrading. There are 2 solutions for this: 1. Only install one package at a time, calling opkg multiple time. This is quite easy and described here: http://trac.shr-project.org/trac/wiki/opkg#Installonepackageatatime 2. Create a swap file that allows to swap out the downloads on the SD card. I recommend this anyway: http://trac.shr-project.org/trac/wiki/swap#Createaswapfile. If you are afraid that your SD card will die soon because of this, I don't think so and they are cheap anyway, so if you need to buy a new one every 2 years, what the heck. -- Remove SHR-TODAY -- Before starting the upgrade do opkg remove -force-depends shr-today. Opkg *should* be removing this automatically, however according to some reports opkg failed to do so (due to opkg stupidness), and keeping shr-today seems to cause weird lockups. So get rid of it in advance. -- Safety tipp: screen session -- - Do run this upgrade (as in every upgrade) in a screen session. My FR display froze during the upgrade (access through ssh still worked) - It's a big upgrade unfortunately which takes some time. All kernel modules and all the efl stuff seems to have been bumped. -- What is new: -- - Plenty of changes to the shr phone apps... - Dimming is now done with a dim phase rather than the simple on/off. Timeouts can be set for the Idle and Idle_dim timeouts. To make these changes persistent, modify the values in /etc/frameworkd.conf - python-based shr-today is no more. It is now rewritten in C and integrated into the shr UI. It's reportedly faster than the old lock screen. Bugs that I have seen: - The new idle screen does not show the signal strength for me - During the opkg upgrade process my phone suspended and this aborted the upgrading Annoying, I know. I now tap on the screen while updating which is pretty silly but Of course, what you should be doing is to automatically request the CPU resource while running updates using this technique: http://trac.shr-project.org/trac/wiki/opkg#Preventsuspendwhileupgrading To sum it up: if you see mysterious screen hangs, you have still shr-today installed and/or running. ___ Shr-User mailing list shr-u...@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-user - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Midori Browser Config
Am Dienstag 08 Dezember 2009 21:51:42 schrieb Andrew Stephen: I am using Midori 0.2.1-r1.4 on SHR-U. There are two usability issues which are causing me problems: 1) Location bar suggestions drop-down As I type a URL which matches anything in the history a dropdown appears and the last character I type gets erpeated no matter what other character I actually type. As I type I need to tap in the location bar in between each letter. 2) No way to exit full screen mode In a previous shr-u release there was an icon shown in fuill-screen mode which allowed me to exit full-screen. This no longer appears and I can see no way of returning to windowed mode. Has anybody else experienced these and found a fix? Thanks, I'm just talking to the midori guys how we can solve 2) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Midori Browser Config
Am Dienstag 08 Dezember 2009 21:59:10 schrieb Adam Jimerson: On Tue, Dec 8, 2009 at 3:51 PM, Andrew Stephen andrew.step...@gmail.comwrote: I am using Midori 0.2.1-r1.4 on SHR-U. There are two usability issues which are causing me problems: 1) Location bar suggestions drop-down As I type a URL which matches anything in the history a dropdown appears and the last character I type gets erpeated no matter what other character I actually type. As I type I need to tap in the location bar in between each letter. Happens here as well, and it gets annoying fast. I hope this gets disabled in a update to Midori (if there will ever be such a thing) Midori developemnt is very active, they released 5 versions in the last few months. I'm sure we will have a solution soon. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Midori Browser Config
Am Dienstag 08 Dezember 2009 22:03:44 schrieb Thomas Zimmermann: Am Dienstag 08 Dezember 2009 21:51:42 schrieb Andrew Stephen: I am using Midori 0.2.1-r1.4 on SHR-U. There are two usability issues which are causing me problems: 1) Location bar suggestions drop-down As I type a URL which matches anything in the history a dropdown appears and the last character I type gets erpeated no matter what other character I actually type. As I type I need to tap in the location bar in between each letter. 2) No way to exit full screen mode In a previous shr-u release there was an icon shown in fuill-screen mode which allowed me to exit full-screen. This no longer appears and I can see no way of returning to windowed mode. Has anybody else experienced these and found a fix? Thanks, I'm just talking to the midori guys how we can solve 2) Midori guys are looking for a solution for 2), i think we will have it in the next release of midori. to 1) i think it's a illume keyboard problem. Some problems to comunicate with gtk apps. Can someone try with another keyboard? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to make a screenshot
Am Mittwoch 09 Dezember 2009 00:02:38 schrieb Ivo van den Maagdenberg: Forgive me for asking one of those silly questions: How do I make a screenshot of an openmoko screen, without a photo camera? Install gpe-scap and call it over ssh to make a screenshot of the current screen. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: [Shr-User] ANNOUNCE: new shr-testing image
-- Weitergeleitete Nachricht -- Betreff: [Shr-User] ANNOUNCE: new shr-testing image Datum: Freitag 04 Dezember 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: SHR-user shr-u...@lists.shr-project.org, SHR-devel shr- de...@lists.shr-project.org After a long fight with our SHR buildhost, I finally managed it: I created a new shr-testing image which is supposed to do the following: - always give you a working phone - care about opkg upgrade'ability - Be conservative in the number of cool on-the-edge features it takes I expect that upgrades will hapen every 3-4 weeks or so. I will try to upgrade things to a working set of revisions. All testing that I can promise will be restricted to shr-lite-image things (there will be a full image soon, but I haven't tested things there). I can also not test GPRS (not using it). Get it here: http://build.shr-project.org/shr-testing Upgrading from a current shr-unstable might or might not work (I have not tested that). I forked off on November 30 or so, and I haven't tested whether a lot of packages would need downgrading from -unstable. Install it, set your root password manually (if you care about ssh login) and you should be good to go. Installing on NAND, you will see tons of error messages pass by on the 1st boot, that seems normal and will go away after some time (1st boot takes longer!). If you want to help out: http://trac.shr-project.org/trac/wiki/shr-testing2009 is a page with my commit policy. (it's flexible though) :-) Bug reports agains shr-testing (via trac) are welcome too. spaetz - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-u status (was Re: [Community Updates] 2009-11-25 released)
Am Sonntag 29 November 2009 10:46:38 schrieb Al Johnson: On Sunday 29 November 2009, Tony Berth wrote: what is the current staus of SHR-U? Can be used as daily distro? Are the problems fixed by now? I still have the version from September which rather works and try to avoid potential problems. From what I've seen on the list most of the original bugs have now been fixed, and it should now be usable as a phone. I've not actually tried it yet though - a job for later today. There was a similar request on shr-users Mailinglist, so i forward the answer spaetz has given there: -- Weitergeleitete Nachricht -- Betreff: Re: [Shr-User] update request Datum: Sonntag 29 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: sam tygier wrote: I wonder if we could have a new update on the progress on the new SHR releases. This is a tricky request, as there are so many things going on in parallel, that just keeping trac of regressions/fixes/improvements is a hard task. Additionally, the core devs are not constantly reflashing a new image on their devices and some of the regressions are only being noticed by installing a fresh image. But let me try to summarize: - Incoming calls when suspended don't work. (one ringtone and then it aborts). This has been fixed. - Ringtone continues ringing even when user aborts call. This has been fixed, but I think it's not in the latest image/feed yet. We are currently rebuilding from scratch so that might still take a few hours to hit the feed. Also this caused some audio stuttering during the first seconds of a call, I think. - Phone suspends when booted with USB plugged in. You have to work around by unplugging/replugging - ogsmd has been improved to start up 9 seconds quicker than before, (don't know if the new revision is already being used, but it should go in soon). - One thing that is still left: It appears that e-wm-illume-config-shr is not in the images by default (although it should be). Thus, you can select Illume but not Illume SHR in the initial wizard. If this is the case you have to manually install e-wm-illume-config-shr and delete /home/root/.e to get back to the initial qizard thingie. - Much more has happened on the audio tweaking side, eg. the Mute and speaker buttons in the active call dialog should be functional now. -Currently there is ongoing work to integrate shr-today into the phone apps (it's a standalone-python app now), and to integrate some quick settings app that is reachable from the phone apps. Also the 1st time shr-wizard is being worked on. -mokonnect was updated and allows me to connect to WLAN again and seems to be able to power on the WLAN now (except when you used shr-settings to turn OFF WiFi, as that set the WiFi Policy to disabled) - MOre apps are added to the feed, eg babiloo, a dictionary, working through the package request list. And existing apps that fail to compile are being looked at to make them compile. Sure, I forgot lots of things, but this is what I know - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Babiloo on Openmoko - Second milestone
Am Freitag 27 November 2009 14:48:26 schrieb Vaudano Luca: I saw now the SHR recipe. I don't know why, but it is on revision 288 instead of 294. The latest version without problems, it is on opkg website. (I solved also the 'Invalid magic' problem) Ciao Luca On Fri, Nov 27, 2009 at 1:51 PM, David Garabana Barro da...@garabana.com wrote: On Tuesday 24 November 2009 16:55:14 Vaudano Luca wrote: I solved the second problem, messages always on top, and I released the file 2.0.9-2b as usual in the opkg website. The one on shr feeds still have these problems. I looked at you site and there you've written: Second Milestone - Current Babiloo version 2.0.9 Bazaar revision: 288 So i took this ;) JaMa is already trying to update it, but bitbake seems to have some problems with bazaar... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Babiloo on Openmoko - Second milestone
Am Freitag 27 November 2009 15:11:33 schrieb Vaudano Luca: Oh sorry my bad! Thanks for including my project in the feed! Ciao Luca On Fri, Nov 27, 2009 at 3:07 PM, Thomas Zimmermann m...@vdm-design.de wrote: Am Freitag 27 November 2009 14:48:26 schrieb Vaudano Luca: I saw now the SHR recipe. I don't know why, but it is on revision 288 instead of 294. The latest version without problems, it is on opkg website. (I solved also the 'Invalid magic' problem) Ciao Luca On Fri, Nov 27, 2009 at 1:51 PM, David Garabana Barro da...@garabana.com wrote: On Tuesday 24 November 2009 16:55:14 Vaudano Luca wrote: I solved the second problem, messages always on top, and I released the file 2.0.9-2b as usual in the opkg website. The one on shr feeds still have these problems. I looked at you site and there you've written: Second Milestone - Current Babiloo version 2.0.9 Bazaar revision: 288 So i took this ;) JaMa is already trying to update it, but bitbake seems to have some problems with bazaar... It would be nice if you could use distutils or setuputils to install babiloo. Because now i copied all files and directorys to the package, without creating any .pyc. This way the recipe is a bit ugly and will breake if you change anything :) Additionally it would be nice if you can host the source tarball somewhere else, because the URL to the bazaar tarball isn't nice to handle. And as last point: including the locals and the needed docs in the tarball would be nice too :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] SHR-unstable got a facelift. And you a christmas present....
Am Montag 23 November 2009 01:16:04 schrieb Cristian Gómez: In my previous post I forgot to put the link [1] http://build.shr-project.org/shr-unstable/images/om-gta02/ Sorry about that full-om-gta02.jffs2 is always a symlink to the latest image greets ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] SHR-unstable got a facelift. And you a christmas present....
Am Freitag 20 November 2009 14:16:54 schrieb Steven Le Roux: Congrats for the great work ! I just wonder, there is still a lot of work or is there any other reason to not integrate paroli ? There is still a lot of work that has to be done. In both places SHR and Paroli. If your are interessted in paroli on SHR then, join us :) As far as i know most work is done. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: [Shr-User] SHR-unstable got a facelift. And you a christmas present....
-- Weitergeleitete Nachricht -- Betreff: [Shr-User] SHR-unstable got a facelift. And you a christmas present Datum: Donnerstag 19 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: SHR-devel shr-de...@lists.shr-project.org, SHR-user shr- u...@lists.shr-project.org [Nov 19 2009, The Internets] It's been psychologically proven that the longer you wait for your presents, the more happy you will be when you finally get them. It seems, the SHR team wants to make you REALLY happy and has let you waiting for quite some time without updates to shr-unstable... ENOUGH WAITING. Christmas comes a bit early this year, and a new SHR-unstable image is out for public consumption. Keep in mind that this is the first snapshot after quite many major transitions, so don't complain if things are a bit ..well... unstable in the beginning. We are working hard to stabilize things. If you depend on your phone, you will probably not yet want to use this, e.g. right now the ringtones aren't working (it just vibrates). We had no resources to provide a nice and working upgrade path, so an opkg upgrade is very likely to lead to a non-working system. (Really! It won't work. We know you'll try anyway :). It still won't work). So download the image (http://build.shr-project.org/shr-unstable), flash it and start afresh. I am writing this before the new images are out there, so be a bit patient before you can really grab them. We will take a branch off current shr-unstable in a couple of weeks (after the dust has settled a bit) and start a conservative branch that will allow for more -testing releases and -finally- a stable snapshot. If others want to volunteer to do that, I'll happy hand over that job though. So what has changed, and what to expect: * First don't expect any miracles. While stuff has changed under the hood, you are still owning a fine piece of open. but outdated hardware. But a path has been laid for future improvements (also performance wise), so this is the way to go. Also, we have tried to keep the look and feel as similar as possible in the new phone apps. You will feel very much at home there. But improvements are much easier now. * xorg server rather than glamo kdrive. We switched to using a proper xorg-server, with a graphics driver that is actively maintained. There have been some improvements, and developer Weiss thinks that there are more perf improvements to get. * eglibc rather than glibc. Just like Debian did, we switched our libc library from glibc to eglibc which (apparently) is a bit better suited to embedded devices. * While the theme contest is still ongoing, we have decided to install the gry theme by Bernd Pruenster by default, it is faster than the default theme, which is not designed for obsolete embedded hardware. The illume theme is still set to default or Illume SHR, so try stasetting it to *gry* through the top bar wrench (preference settings) * The neo theme is also nice and fast. It is not installed by default, but it is in the feeds. You can easily install in with opkg install shr-theme-neo. Another theme to try out is the niebiee theme which has been designed with speed in mind (opkg install shr-theme-niebiee). * the python-based frameworkd is being replaced bit by bit with components written in Vala. The first components that we use are fsousaged (which replaces ousaged), fsodeviced, and fsonetworkd. Mickey posted a status update (http://www.vanille-media.de/site/index.php/2009/11/10/towards-the-end- of-2009/) on the new fso stuff. * phonefsod replaces the ophonekitd phone daemon and and phoneuid/libphoneui are now responsible for all things GUI with the phone apps. * opimd is included and we have the possibility to save incoming and outgoing SMS as well as contacts on the SIM card or on the SD card (using the sqlite backend). New SMS/contacts are now by default saved in a database on the FreeRunner (SD card or NAND), so be careful before reflashing! (Someone should probabably give instructions somewhere on how to change the configuration to use the SIM card as default and how to transfer data from one backend to another.) * We have proceeded with the integration work with openembedded.org and we are very close to their development branch now, patches will be submitted to really merge SHR with upstream. This also means that we now have updated versions of basically every software component in this image. This migration has unfortunately caused quite some head aches and build problems... * mokonnect was finally able to connect to my WEP WLAN without crashing the kernel :). * We will be providing a possibilitiy to upgrade the kernel to 2.6.31 (including KMS goodness, see http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html) for adventurous users some time after this release. We just had to make a cut somewhere and this did not make it in yet. What is NOT working: * Ringtones are not working yet after the
Re: Fwd: [Shr-User] SHR-unstable got a facelift. And you a christmas present....
Original discusion is at shr-us...@lists.shr-project.org, it would be best if all users interested in SHR join that list. I will forward important Messages to community@lists.openmoko.org but not everything. -- Weitergeleitete Nachricht -- Betreff: Re: [Shr-Devel] [Shr-User] SHR-unstable got a facelift. And you a christmas present Datum: Donnerstag 19 November 2009 Von: Tom t...@stosb.com An: Sebastian Spaeth sebast...@sspaeth.de We already fixed a couple of things: * Ringtones are not working yet after the first call (it just vibrates). There is an issue related to the new fsodeviced and how it handles alsa sound profiles. We are investigating this issue. * Phonelog: can't select items from list. * Shr-settings: can't turn wifi on. Opkg upgrade to get the fix for those. -- Tom. - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
What's going on (3)
-- Weitergeleitete Nachricht -- Betreff: [Shr-User] What's going on (3) Datum: Dienstag 17 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: SHR-user shr-u...@lists.shr-project.org Hi all, every day we think, THIS is the day we finally push out the new shr-unstable, and then something happens that prevents it. Just last week, upstream OE made a major transition that broke the compilation of many packages and introduced weird errors (some required files were not being installed any more, some library symlinks were missing, etc). We have dealt with that now. The last thing we are grappling with before we can push out: JaMa wanted to fix version numbering so we can offer opkg upgrades rather than requiring reflashes (too often) in the future. This was supposed to be easy but turned out to be a nightmare. Again about 50 packages failed to compile and we have to deal with that fall out. Once the image compiles and boots flawlessly, we'll push it out immediately, promised :). There will be a few glitches, but overall it is shaping up to be a nice image. spaetz - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community Updates] 2009-11-11 released!
Am Donnerstag 12 November 2009 10:53:15 schrieb Patryk Benderz: Hello everybody, recent Community Update is out! Take a look at: http://wiki.openmoko.org/wiki/Community_Updates/2009-11-11 and contribute to the new draft at: http://wiki.openmoko.org/wiki/Community_Updates/Draft_2009-11-25 Thanks to all contributors: Any Key Zeusone Toams Sveinung Jldominguez Pieterc Valos Thanks for releasing the CU. I had to change a small thing, because the summary of what's going on in the SHR land wasn't from. I just forwarded the original message from Sebastian Spaeth :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: [Shr-User] What's going on in SHR land
For the SHR users that aren't reading the SHR mailing lists i'm forwarding this message from spaetz: Betreff: [Shr-User] What's going on in SHR land Datum: Sonntag 01 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: shr-de...@lists.shr-project.org, shr-u...@lists.shr-project.org Hi all, for those of you few that do not live 24/7 in IRC land, here is a not-so-brief update on what is happening in SHR land. No, we are not all dead :). There are a couple of major transitions that have slowed down new images or indeed any updates in the SHR feed. Let me try to sum up a few and I am sure others will chime in and list whatever I have forgotten: - Transition from the obsolete kdrive-glamo driver to a proper xorg server infrastructure. This took some time, but it appears that it is working fine now. Don't expect any (initial) performance boosts, but being on a regular xorg server and having a driver that is actually being developed and maintained is a good thing for the future (thanks to Weiss and others for some really hard work here). - More fso...d goodness. Rather than having Mickey Lauer's python prototyped phone backend, we are starting to his re-written bits and pieces (coded in vala, which should give us a nice performance boost over python). For the beginning we have the resource handling (fsoresourced) on board and look forward to the next bits and pieces. I know very little about the state of things here, so others might have more information. -New phone apps: As if that were not enough changes, the core team (mrmoku, tasn, dos1, and others?) has started to redevelop the frontend applications for SHR. the old ophonekitd was initially developed by a guy called quickev who has been missing in action since quite some months now. Don't ask ME why, but apparently the now design allows for better/quicker/whatnot development. I'll let one of them speak out for themselves about the motivations. Besides lots of work,this gives us also a chance to redesign the screens and make the UI better. So goodbuy ophonekitd and libphone-efl, welcome phoneui, and libphoneui-shr. -Bernd Prünzler(spelling?) is kind enough to help out with some theme development (BTW, you did know there is a theme contest going on, do you? So, go and design and submit something already!). The default theme has been designed for powerful desktops, and is using more transparency and other fancy stuff than the slow graphics can do. He is developing a theme that should be much faster on the Freerunner (but don't expect miracles, the hardware will still be barely able to drive a full VGA-resolution screen). So expect a big fight between dos1 (niebee theme) and bernd (gry theme) for the fastest performance (while retaining good looks). Last but not least: what we had done the last few months, is basically taking a fork of OpenEmbedded and developing from that. While this gave us the stability to code apps without having others break our stuff (we are quite capabable of doing that ourselves it seems :-) ), this led to a quickly diverging SHR and OE tree. It was decided that we really should include our stuff into OpenEmbedded proper, rather than just doing our stuff in parallel. So we had first put all the stuff into an SHR/import git tree which is in the openembedded code repository. Next, mrmoku created the shr/merge tree which is kept in sync with the OpenEmbedded tree and we ported all our enhancements there. The plan is to take our bits and pieces from here and merge them into OE over time. This is where we currently stand, we want to keep using the shr/merge tree which gives us a current OE tree, but of courseby using more updated components, lots of stuff was broken. The guys have fought really hard in the last days (and weeks) to overcome compilation errors, nonbooting phones, and crashing components. It seems we are now really close. The new images compile fine (yay!), the phone actually boots, and many of the crashes have been eliminated. AFAIK, we are currently still stuck with a segfaulting dbus. As soon as these issues are ironed out, mrmoku will continue to put updated SHR-unstable images and packages out. This could take 1,2, or 4 days. I don't know how long and it depends on how good things will turn out. But there will be a new image soon. Expect some teething troubles with the new images at first (I am not sure an opkg upgrade will work), but this is all fancy new stuff that we are very happy about. spaetz ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] What's going on in SHR land
Am Sonntag 01 November 2009 17:20:31 schrieb jeremy jozwik: On Sun, Nov 1, 2009 at 8:04 AM, Thomas Zimmermann zimmerm...@vdm-design.de wrote: For the SHR users that aren't reading the SHR mailing lists i'm forwarding this message from spaetz: Hi all, for those of you few that do not live 24/7 in IRC land, here is a not-so-brief update on what is happening in SHR land. No, we are not all dead :). good to hear my openmoko is not in danger of stagnating! what really interests me here is themes, being a visual person the code part is interesting in a getting my hands dirty aspect. but the visual aspects of the phone need some work. is there a link to the contest page? The contest page is located at the shr trac: http://shr-project.org/trac//wiki/ThemeContest ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] building packages
Am Mittwoch 28 Oktober 2009 12:10:39 schrieb Davide Scaini: Hi guys, i would like to build some packages for shr that i feel i miss (like gnuplot or so... and maybe do some stupid interface, but not in the immediate future). Where do i start? I tried to find a source on the openmoko wiki, but with no sure answers... I'm sure you can give me a simple reference to start ;-) thanks d You can look at this: http://trac.shr- project.org/trac/wiki/Howto%20get%20my%20application%20in%20the%20SHR%20feed Or to build gnuplut, just do: wget http://build.shr-project.org/Makefile make setup cd shr-unstable . ./setup-env bitbake gnuplot Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: E17 default scaling factor
Am Montag 26 Oktober 2009 16:08:26 schrieb jeremy jozwik: On Mon, Oct 26, 2009 at 7:57 AM, Marcel tan...@googlemail.com wrote: Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... might not help but i know its less then 177dpi [what i run] did you do this from the gui options or via a command? The slider in the E wrench is set to 140dpi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U latest] phonelog DB
Am Samstag 24 Oktober 2009 10:08:22 schrieb Tony Berth: I think it used to exist a file called 'phonelog.db' in the past? I can't fond that any more. Where is phonelog saving the current data? How can I export them, view or delete? Thanks Tony Phonelog uses calls backend of opimd. So everything is saved within opimd. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] fsousaged upgrade failed; needs libfso-glib0 ver 0.2.1
Am Freitag 23 Oktober 2009 20:56:18 schrieb Greg Bonett: Hi, I'm running an unstable image from Aug 8th. opkg-cl update; opkg-cl upgrade; gives the following error: * ERROR: Cannot satisfy the following dependencies for fsousaged: * libfso-glib0 (= 0.2.1+gitr47+7608c8d98bb65bb5beca6621eb86920b71df1b opkg-cl update; opkg-cl list | grep libfso-glib returns: libfso-glib0 - 0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0 - so it looks like the version of libfso-glib0 in the repo doesn't meet the requirements for fsousaged is anyone else having this problem? Is there somewhere I can get the libgso-glib0 0.2.1 package? Thanks, Greg Please have a look at that ticket: http://trac.shr-project.org/trac/ticket/651 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Desktop based on openbox and idesk
Am Donnerstag 22 Oktober 2009 07:57:15 schrieb Matthias Huber: Thomas Zimmermann schrieb: Am Mittwoch 21 Oktober 2009 22:35:38 schrieb ajvogel: Thomas Zimmermann wrote: To build the whole feed you have to download about 6 GByte of Sourcepackages. Just for 1 package it won't be that much, perhaps about 2 GByte. And during build it will connect several times to some git servers. Unfortunately thats more than I have available. :( and that rules me out for trying to get openbox/idesk in the feeds. Looks like our only hope is, that one of the shr-devs that already have an environment setup help with the compilation and packaging. Anybody? I can help you, no problem with that. But i don't know either openbox nor idesk, so all patches must be provided by you. And testing also has to be done by you. very good, thank you. there is only one patch for openbox, idesk runs out of the box. how do we now ? Send me all information for the recipe, or better a recipe and the needed patch. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] TangoGPS
Am Donnerstag 22 Oktober 2009 13:33:22 schrieb William Kenworthy: I am building shr-unstable locally and tried 9.7 when it first came out - often crashed when changing between certain resolutions. Not sure if it was the -r1 version or if that has fixed the problem? It is in the shr-u builds I did yesterday (which killed my FR when trying to upgrade so went back to what I have before :( anyone able to says 9.7-r1 is stable on shr-u? I have it on my gentoo desktop and that runs fine. BillK I played a bit around with it, but not much. For me no crash with 0.9.7-r2. r1 was without the zoom fix patch. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Desktop based on openbox and idesk
Am Donnerstag 22 Oktober 2009 13:17:42 schrieb Matthias Huber: Thomas Zimmermann schrieb: Send me all information for the recipe, or better a recipe and the needed patch. Here we go, wenn noch was nicht stimmt, bitte Rückmeldung an mich, werd's korrigieren und auf neuere Versionen schauen. Viele Grüße, Matze Ok, i commited openbox and obconf. It builds and packages are avaible at tests/mrmoku/unstable feed: http://build.shr-project.org/tests/mrmoku/unstable/feed/armv4t/ Do not do opkg upgrade from this feed if you do not know what it is! idesk does not build, because of some problems with imlib2, have to look a bit deeper into it. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Glamo
Am Dienstag 20 Oktober 2009 16:59:04 schrieb abatrour: Does anyone remember who was assigned to work on glamo while openmoko was still developing software? I'm trying to round up some of the old crew to see if I can gather some knowledge and possibly some code to help get the glamo working as intended. I have already contacted koolu and am waiting a response. Does anyone know if that Sean guy (sorry forgot his last name) still checks out these forums? You should look at the IRC Channel, we are speaking nearly every day about Xorg and xf86-video-glamo. And xf86-video-glamo is actively developed as you can see in the git repo at git.openmoko.org. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Glamo
Am Mittwoch 21 Oktober 2009 11:26:35 schrieb Laszlo KREKACS: On Wed, Oct 21, 2009 at 9:45 AM, Thomas Zimmermann zimmerm...@vdm-design.de wrote: You should look at the IRC Channel, we are speaking nearly every day about Xorg and xf86-video-glamo. #openmoko-cdevel ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Yes A very long mail :D ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Desktop based on openbox and idesk
Am Mittwoch 21 Oktober 2009 20:40:56 schrieb ajvogel: matzehuber wrote: here is what i found: http://shr-project.org/trac/wiki/Howto%20get%20my%20application%20in%20t he%20SHR%20feed As far as I understand you have to setup the SHR environment by downloading the Makefile and running make setup. Which downloads and sets up the environment. Unfortunately, my bandwidth is limited. Does anyone know how much bandwidth is used during setup? (10s, 100s MB?) If its not too much Ill try and setup the environment and see if I can get openbox ready for the feeds. Regards, Adolph To build the whole feed you have to download about 6 GByte of Sourcepackages. Just for 1 package it won't be that much, perhaps about 2 GByte. And during build it will connect several times to some git servers. Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Desktop based on openbox and idesk
Am Mittwoch 21 Oktober 2009 22:35:38 schrieb ajvogel: Thomas Zimmermann wrote: To build the whole feed you have to download about 6 GByte of Sourcepackages. Just for 1 package it won't be that much, perhaps about 2 GByte. And during build it will connect several times to some git servers. Unfortunately thats more than I have available. :( and that rules me out for trying to get openbox/idesk in the feeds. Looks like our only hope is, that one of the shr-devs that already have an environment setup help with the compilation and packaging. Anybody? I can help you, no problem with that. But i don't know either openbox nor idesk, so all patches must be provided by you. And testing also has to be done by you. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.7 release
Am Montag 21 September 2009 18:43:37 schrieb Marcus Bauer: Heya out there! First of all thanks for the many positive emails I got over the last months, motivating me to bring a new release of tangoGPS to the coolest open hardware gadget on earth - the openmoko phone. The new features include: * overzoom until level 20 * upscaling of missing tiles * a map scale indicator * overhauled this point function - easy measuring of distances and ways - display of bearing = useful for navigation * friend function simplified and you can now add a message to your position As always, it runs well on your laptop/netbook too. The full release announcement is here: http://www.tangogps.org/gps/cat/News I am currently looking for cool stories/photos/blog entries for featuring on the website. Thus send me your stories, pictures or links - be it on the Freerunner or any other device. Have fun! Marcus Hi, i tried tangogps 0.9.7 on SHR today and it segfaults on zooming. So i assume that the runtimedepencies changed. Can you announce the runtimedepencies for it? I installed all depencies mentioned in the debian lenny package: - libatk-1.0-0 (1.20.0-r0) libcairo2 (1.8.0-r0) libcurl4 (7.18.2-r1) libexif12 (0.6.17-r0) gconf-dbus (2.16.0+svnr641-r0) libglib-2.0-0 (2.18.3-r1) gtk+ (2.14.2-r1) pango (1.22.0-r2) libsqlite3-0 (3.6.5-r0) libc6 (2.6.1-r16) - But it still segfaults, plz help :) Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.7 release
Am Dienstag 22 September 2009 11:33:34 schrieb Robin Paulson: 2009/9/22 Marcus Bauer marcus.ba...@gmail.com: First of all thanks for the many positive emails I got over the last months, motivating me to bring a new release of tangoGPS to the coolest open hardware gadget on earth - the openmoko phone. excellent work, marcus. looking forward to using it is there a binary for openmoko? shr devs, could you get the new version in the repos? cheers It's build but it can't be sync to the feed. The package can be found here: http://build.shr- project.org/tests/mrmoku/unstable/feed/armv4t/tangogps_0.9.7-r1_armv4t.ipk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U/all?] Midori and Wap
Am Dienstag 22 September 2009 17:00:22 schrieb D. Gassen: Hi all, Since I recently upgraded Midori from 0.0.x to 0.1.x that is now regularly updated in the SHR-U feeds Midori doesn't want to display WAP pages anymore (mime type: text/vnd.wap.wml, example: http://www.bofa.mobi ) but rather offers to download the file. This used to work in 0.0.x. Is that actually a problem with the new version of Midori? If so, is there some config file that could be tweaked? (I couldn't find one) Or does Midori need to be recompiled with some option? Dirk SHR uses plain Midori, so i think you should ask this the Midori devs. I just made the recipe and don't want to patch to much in Midori. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.2.4 -- now looks Elementary, LED color configurable
Am Montag 21 September 2009 10:58:15 schrieb Łukasz Pankowski:
Hi
I have removed libeflvala from dependencies in ffalarms.bb as ffalarms.c
is included in the source tarball so valac should not start if you
compile from source tarball.
It is that way to minimize compilation problems, for example I compiled
ffalarms 0.2.4 with valac 0.7.5 (0.7.6 was not yet in Debian that day)
and the problem you encountered is with valac 0.7.6. I just committed a
quick fix to subversion repository [1].
[1] The change
(http://projects.openmoko.org/plugins/scmsvn/viewcvs.php/trunk/?root=ffala
rms):
--- trunk/ffalarms.vala 2009/09/19 12:02:37 53
+++ trunk/ffalarms.vala 2009/09/21 08:30:14 54
@@ -60,7 +60,7 @@
time_t next_hm(int hour, int minute)
{
var now = time_t();
-var t = Time.local(now) { hour=hour, minute=minute, second=0 };
+var t = Time.local(now); t.hour=hour; t.minute=minute; t.second=0;
var timestamp = t.mktime();
if (timestamp = now) {
t.day += 1;
Thanks it's working now :)
I sent a patch to update ffalarms in SHR to 0.2.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Countdown app using PyGTK
Am Montag 21 September 2009 13:58:16 schrieb Marcel: Moin! I've written a little python app that can count down for a given amount of time, either just seconds or hh:mm. I always missed that feature in ffalarms (which also only does 5min-steps, not sufficient for my needs) but I'm not willing to fiddle with elm, so here it's in GTK, feel free to try it. Although the GUI fits nicely with the illume keyboard visible, I'd like to have the text entry field for the countdown time a little larger. How can I do that independently (that word looks strange to me...) from the GTK theme? Here it is: http://d-a300.selfip.net/files/eieruhr.tar.gz Just the python script and a desktop file yet, is there some minimal sample for a bb recipe somewhere? if you inlcude a setup.py for distutils, then the essentials for the recipe are: RDEPENDS = python-pygtk SRC_URI = http://yourpage.org/app.tar.gz; inherit disutils That's all. Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.2.4 -- now looks Elementary, LED color configurable
Am Samstag 19 September 2009 14:20:12 schrieb Łukasz Pankowski:
Hi
I have just released ffalarms 0.2.4. Features:
- now looks like other Elementary programs
- LED clock: add configuration option to change color of LED digits.
You can change the color by setting ``color`` to ``red, blue,
green`` (numbers in range 0-255) in your ~/.ffalarmsrc. For
example:
[ledclock]
color=255, 255, 0
Download page:
http://projects.openmoko.org/frs/?group_id=260release_id=575
Hi tried to compile ffalarms 0.2.4 for SHR, but i'm getting the following
errors, any idea what's wrong?
First error was, that it should depend on libeflvala, that's fixed.
Thomas
( In the case that the atachmend won't work: http://shr.pastebin.com/d348b88cb
)
NOTE: make -j 4 -e MAKEFLAGS=
VAPIDIR=/home/thomas/SHR/SHR/shr-unstable/tmp/staging/armv4t-angstrom-linux-gnueabi/usr/share/vala/vapi
valac
--vapidir=/home/thomas/SHR/SHR/shr-unstable/tmp/staging/armv4t-angstrom-linux-gnueabi/usr/share/vala/vapi
--pkg=elm --pkg=edje --pkg=dbus-glib-1 --pkg posix -C ffalarms.vala
ffalarms.vapi
edje_cc data/ffalarms.edc data/ffalarms.edj
ffalarms.vala:63.13-63.66: error: `GLib.Time.local' is not a creation method
var t = Time.local(now) { hour=hour, minute=minute, second=0 };
^^
ffalarms.vala:63.9-63.66: error: var declaration not allowed with non-typed
initializer
var t = Time.local(now) { hour=hour, minute=minute, second=0 };
^^
ffalarms.vala:64.21-64.21: error: The name `t' does not exist in the context of
`next_hm'
var timestamp = t.mktime();
^
ffalarms.vala:64.9-64.30: error: var declaration not allowed with non-typed
initializer
var timestamp = t.mktime();
^^
ffalarms.vala:65.9-65.17: error: The name `timestamp' does not exist in the
context of `next_hm'
if (timestamp = now) {
^
ffalarms.vala:66.2-66.2: error: The name `t' does not exist in the context of
`next_hm'
t.day += 1;
^
ffalarms.vala:67.2-67.10: error: The name `timestamp' does not exist in the
context of `next_hm'
timestamp = t.mktime(); // also normalizes Time
^
ffalarms.vala:69.9-69.9: error: The name `t' does not exist in the context of
`next_hm'
if (t.hour != hour) {
^
ffalarms.vala:70.2-70.2: error: The name `t' does not exist in the context of
`next_hm'
t.hour = hour;
^
ffalarms.vala:71.2-71.10: error: The name `timestamp' does not exist in the
context of `next_hm'
timestamp = t.mktime();
^
ffalarms.vala:73.12-73.20: error: The name `timestamp' does not exist in the
context of `next_hm'
return timestamp;
^
ffalarms.vala:643.6-643.36: warning: unhandled error `MyError'
cfg.load_from_file(config_file);
^^^
ffalarms.vala:823.2-823.42: warning: unhandled error `GLib.ShellError'
Shell.parse_argv(play_cmd, out play_argv);
^
Compilation failed: 11 error(s), 2 warning(s)
make: *** [ffalarms.c] Error 1
FATAL: oe_runmake failed
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: nEo theme issues
Am Montag 14 September 2009 13:49:56 schrieb Martin Jansa: Now I've repacked all your files to one tarball and I'm using it locally but before sending patch incorporating theme to shr we need files somewhere (SCM would be better, tarball good, extracting your ipkgs just to get files to pack them again is no go :)) I'm sure mrmoku can grant hin git access to shr-themes.git so that he can store the theme there. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] first impressions
Am Donnerstag 10 September 2009 11:00:59 schrieb arne anka: after having trashed my debian/fso for the moment, i decided to try out shr for a while until i get fso working again. while i try to read almost all mails on community, i can't claim to have followed the shr development that close. i got some first impressions i'd like to share -- if they are addressed already, simply ignore them, if i miss something point it out. skin is illume-shr since i figured it would fit the freerunner's screen best. version is the image from august 8th with the matching kernel (what are the modules for?) without any updates so far, thus probably some of my complaints are addressed already. - imo the default font is far to big -- i set it to small but got the distinct impression that illume crashes really often now, luckely enough mostly it recovers, i had to reboot only once or twice because it locked hard (fso still worked, since the screen blanked and the fr suspended). - with the default font the x crashed screen and some settings screens are unreadable since a lot of text is invisible - the font setting is a) to big for the screen and b) confusing. from the plethora of options i am unable to decide, which is the one i want (having very small columns with only the first letter visible does not help either) -- switching to landscape helped only marginally and left me with a corrupted screen after switching back to porttrait (coordinates where still landscape and the lower part of the screen, 480 were ... gaudy) - basic preview text - scrolling in the settings app is cumbersome -- a) buttons are too close to the border, i live always in fear to accidently hit one without knowing what it will do, b) the ok button at bottom is to wide, more than once while scrolling i hit that ok button and was sent back to the main menu - i tried to minimize the font of the clock in the top shelf -- it is somewhat affected by the size setting of top shelf gadgets, but far from sufficient. while that signal level gadget and the battery gadget are minimized into illegibility, the clock still is big (about 4/5 of the shelf height, while the other gadgets are less than 1/2), overlays signal/battery and is cut off at the top slightly (since it is not vertically centered but aligns to the top). only setting the actual date/time is possible, font used or font size are not. - bottom shelf seems not to be affected by changing the shel size, it seems to retain the very same height as before, but the font displaying loading gets smaller i think, i'll attempt an update tonight and see, what changes. All thing's, expect for shr-settings, are e releated so they won't change (soon). And shr-settings layout hasn't changed since 8.8. too, so an update won't change anything you mentioned. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: german fixing the #1024 bug party
Am Dienstag 01 September 2009 22:33:53 schrieb Fox Mulder: Kahless wrote: hi all, I'm interested in fixing my #1024 bug but i don't want to send it somewhere. (it's my main phone and i love it too much :) ) Is anyone near /North-Rhine/-Westphalia interested in starting a small bug fix party? I would be willing to do the buzz-fix solution with adding a 10µF cap to the existing which i already did to my own freerunner. But i live near Frankfurt a.M. which is not very near to NRW. Ciao, Rainer I would join the bug fix party, i'm living near Koblenz, so for me it's no difference between Frankfurt and NRW. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] Don't answer a call by turning FR upside down..
Am Freitag 28 August 2009 09:48:46 schrieb Niels Heyvaert: Shouldn't be very hard but it'd be extremely cool. Integration to a distro (SHR maybe :) might be a bit more of a hack (adding GUI to enable/disable this feature etc) though.. Yes, it does sound like a cool feature, as long as it is turned off by default :-). Question is, is this the right time to add these type of features? Keeping in mind the limited resources we have, wouldn't it be better to concentrate on fixing all the current issues and bugs (see trac, there are many), improving speed and stability, getting a decent testing version for SHR, work on some proper documentation etc. Adding a nice to have feature would only complicate things further, causing more energy of the community going to waste. I guess it's all a matter of priorities... Niels. There are a few thousend people having a FR and less then 100 are developing software. I think if a new one will try to implement this, it's a very good point to start with framworkd programming for him. He will have a deep look into frameworkd and after implementing this he can help with other things because he knows the framework now. So if a new one wants to implement this: Go for it! Python ins't really hard to learn, i learned it just for extending opimd :) Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
Am Donnerstag 27 August 2009 00:08:44 schrieb Kero van Gelder:
If you set _at_least_one to some non-false value, opimd will switch
into at least one field mode. Query {'Name':'dos', 'Content' :
'Test', '_at_least_one': True} will return entries with Name = dos
*or* Content = Test. Without '_at_least_one', opimd checks if entry
matches to all fields in query (so Name = dos *and* Content = Test) .
Now you can also query values greater or lower than specified. To do
that, you can use '_gt_Timestamp' or '_lt_Timestamp' fields (replace
Timestamp with whatever you want). Those field names are equal to
'_float_gt_Timestamp', '_float_lt_Timestamp'. There are also
'_int_gt_Timestamp' and '_int_lt_Timestamp' fields which you can use
with integer values, when you don't need float. Maybe it gives some
performance speed-up ;)
Is that _gt_20090101: birthday or _gt_birthday: 20090101 ?
(and if the latter, I think _birthday_gt: 20090101 reads better since
it is infix notation; I find prefix notation ambiguous to read)
I have no idea why you want to make a distinction between floats and
int on dates. Either your underlying format is based on floats, or it
isn't. and I would need to know whether your int is a day, or a second.
Instead, I'd like you to convert my query to the underlying format, so I do
not have to worry about it, ever.
In my experience, using OS native time is no too bad. -131 is
December 1901, there are not too many things I'd like to put in a
pim suite, that happen(ed) before that. And I guess anything non OS native
is likely slower than OS native. That's assuming the comparison of
timestamps is taking more CPU cycles than parsing my timestamp-string in
the first place.
Bye,
Kero.
I think Sebastian implemented these gt and lt functions because of me. I need
them for opimd-dates.
The Problem with a timestamp string is: what format does it have? In this case
we have to include the format defenition into the API. Then it's a lot easier
to use unix-timestamps they are easy to parse and compare...
Thomas
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
Am Donnerstag 27 August 2009 11:41:42 schrieb Al Johnson:
On Thursday 27 August 2009, Thomas Zimmermann wrote:
Am Donnerstag 27 August 2009 00:08:44 schrieb Kero van Gelder:
If you set _at_least_one to some non-false value, opimd will switch
into at least one field mode. Query {'Name':'dos', 'Content' :
'Test', '_at_least_one': True} will return entries with Name = dos
*or* Content = Test. Without '_at_least_one', opimd checks if entry
matches to all fields in query (so Name = dos *and* Content = Test) .
Now you can also query values greater or lower than specified. To do
that, you can use '_gt_Timestamp' or '_lt_Timestamp' fields (replace
Timestamp with whatever you want). Those field names are equal to
'_float_gt_Timestamp', '_float_lt_Timestamp'. There are also
'_int_gt_Timestamp' and '_int_lt_Timestamp' fields which you can use
with integer values, when you don't need float. Maybe it gives some
performance speed-up ;)
Is that _gt_20090101: birthday or _gt_birthday: 20090101 ?
(and if the latter, I think _birthday_gt: 20090101 reads better since
it is infix notation; I find prefix notation ambiguous to read)
I have no idea why you want to make a distinction between floats and
int on dates. Either your underlying format is based on floats, or it
isn't. and I would need to know whether your int is a day, or a
second. Instead, I'd like you to convert my query to the underlying
format, so I do not have to worry about it, ever.
In my experience, using OS native time is no too bad. -131 is
December 1901, there are not too many things I'd like to put in a
pim suite, that happen(ed) before that. And I guess anything non OS
native is likely slower than OS native. That's assuming the comparison
of timestamps is taking more CPU cycles than parsing my
timestamp-string in the first place.
Bye,
Kero.
I think Sebastian implemented these gt and lt functions because of me. I
need them for opimd-dates.
The Problem with a timestamp string is: what format does it have? In this
case we have to include the format defenition into the API. Then it's a
lot easier to use unix-timestamps they are easy to parse and compare...
Is there any documentation for date related opimd entries? I'm worried that
if timestamps are being used for date/time storage there will be no way to
store timezone.
Currently there is no documentation. I thought to store the timestamp as UTC.
And it looks like dos1 stores timestamps too in opimd-notes.
Any suggestion how to query dates through DBUS? Perhaps we can add a date
datatype to DBUS, i think that would be the best way :)
Thomas
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Wiki] Neon into Hall of Fame (2 Votes)
Am Mittwoch 12 August 2009 17:34:24 schrieb c_c: Hi, I agree - it does seem rather chaotic. We should move to a poll. Here are my candidates (obviously limited by what I use):- Neon, Orrery, numptyphysics, sms-sentry I suggest to discuss programs on ML and just move the vote to the Talk page of the wiki. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
Am Donnerstag 06 August 2009 09:09:58 schrieb Michael Pilgermann: Many thanks for all your input ... I had noticed already by going through the opimd code / db scheme that the selection of fields is dynamic. However, I think there is really a need to agree upon a common set of attributes (maybe core attributes), which are supported. With the contacts-shr support for opimd (some additional phone-gui packacke, I recently installed - which, by the way, is not working for me yet due to some import error), it could be interesting, which fields are used in there (well, that will be from my point of view the most frequently used contacts app in the end) ... From my experiences with developing PISI as a contact sync engine, I realized that fields out there are really different - e.g.: - LDAP (with different schemes; for Contacts use additional mozilla scheme) - VCF-Files (vcard) - DB-Structures (e.g. QTopia) There is a standard available for PIM synchronization by OMA called SynML (http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html) . If you look at it, they use vcard (vcf) as well for carrying the content. VCard is a standard - so it might be worthwile to take a deeper look in which fields they are using and how they structure the content. (http://www.imc.org/pdi/) Mike I would vote for syncML structure, even opimd can hold a more flexible structure. But syncML is used in a lot of phones and this way i can be easier to integradte opimd in exisiting sync programms, perhaps on windows too. So syncML: +1 Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reading binary messages
Am Mittwoch 05 August 2009 15:46:12 schrieb Helge Hafting: Sebastian Krzyszkowiak wrote: On 8/4/09, Brock awwa...@thelackthereof.org wrote: this actually difficult or is it a matter of nobody having the time / care to do it? I think noone cares. I don't need MMS at all, Yes, we care. I don't send MMS myself, but others send me pictures occationally - it'd sure be nice to see them on the excellent display... Helge Hafting I got an MMS last week and looked around if i can find some dokumentation for MMS. I found this page [1] with the spezification. But i didn't feeled like looking at it. It's a bit too much. Perhaps someone can summerize the data format. After that implementing is a lot easier, i think. Thomas [1] http://www.openmobilealliance.org/Technical/release_program/mms_v1_3.aspx ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR annoyances (+ a few workarounds)
Am Mittwoch 24 Juni 2009 22:25:47 schrieb Jon Levell: Vagalume in the repo/image == It crashes Workaround: Use the one from opkg.org I've added a bug report including a new .bb for vagalume to OE a month ago, but nobody cares. And on the SHR trac a similar bug report was closed as upstream... I hope someone will add the .bb in the near future. Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone (0.20 - alpha release) Elementary based mplayer frontend
Hi, there is a discussion on the shr-user mailinglist to add intone as default mp3 player to the full image. But to do this it's nesecary that the current version in the svn builds. So it would be nice if you commit only code that builds to the svn und add the images used in intone and the .desktop file to the svn. greets ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: USB Kernel problem with latest SHR unstable
Am Freitag 24 April 2009 12:20:00 schrieb Robin Paulson: 2009/4/24 Ben Thompson b...@york.ac.uk: ok, i'm confused now. why do i want to run this on my host? the problem's with the phone, isn't it? I don't know why, but the interface name on my host changed. For me it's now eth1. dmesg looks like this when i plug in my neo: usb 8-1: new full speed USB device using uhci_hcd and address 5 usb 8-1: New USB device found, idVendor=1457, idProduct=5122 usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 8-1: Product: RNDIS/Ethernet Gadget usb 8-1: Manufacturer: Linux 2.6.29-rc3 with s3c2410_udc usb 8-1: configuration #1 chosen from 2 choices eth1 (cdc_ether): not using net_device_ops yet eth1: register 'cdc_ether' at usb-:00:1d.3-1, CDC Ethernet Device, 00:1f:11:01:72:33 eth1: no IPv6 routers present so if u look at the beginning of the last three lines you see the interface name. greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] and illume, wooow!
Am Dienstag 21 April 2009 06:33:05 schrieb Konstantin: Joerg Reisenweber wrote: give GPRS a try. works out of the box for me (as do lots of other things, midori e.g. Me was googling with O2-loop and right APN within 3 min ;) /j Speaking of O2, I was looking for the right settings for O2 (Germany) a while, but was unable to find them. Could you post/pm them to me, or point me to a site I can find them? Thanks :) Regards, Konstantin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Have a look at the FAQ of o2 ;) http://www.o2online.de/nw/support/mobilfunk/surfmobil/surfhandy/einstellungen/index.html Best regards Heiner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Troubles with opkg.org repo
Am Sunday 08 March 2009 14:30:36 schrieb Risto H. Kurppa: On Sat, Mar 7, 2009 at 10:09 AM, Tobias Kündig tobias.kuen...@gmail.com wrote: This is a little summary of what I do: http://www.opkg.org/repo.html Thanks Tobias! At #openmoko tried to figure out what's wrong. Someone pointed out that ftp uses ascii mode by default - I suppose you're uploading at least the Packages -ascii file. How about packages.gz. Man ftp says that ascii upload of binary files might corrupt it - this might be the problem - using binary format shouldn't corrupt the .gz Another find was that 22 packages out of 93 were other than Debian Binary when checked with file *ipk. The list file types listed below: DEBIAN BINARY – CORRECT!!! neon_0.9.8-r1_all.ipk openmoocow_0.3_armv4t.ipk nethack_3.4.3-10.1-0.4_armv4t.ipk openmiaocat_0.2.2_armv4t.ipk orrery_2.4_arm_2008.8.ipk pyring_1.1.6-r1_armv4t.ipk python-pyalsaaudio_0.3-ml0_armv4t.ipk perpendicular_0.1_armv4t.ipk pong_0.1_armv4t.ipk liquidwar_5.6.4-2_armv4t.ipk moko-eightball_0.20080721_om-gta02.ipk mokogeocaching_0.2_all.ipk meooem_0.1_armv4t.ipk minimo_0.02+cvs20070626-r1_armv4t.ipk mokomaze_0.2.2-1_armv4t.ipk mokox48_1.0_arm_2008.8.ipk mutagen_svn-4350-2_armv4t.ipk mokopod_0.1.5_armv4t.ipk mokosync_0.1_arm.ipk tangogps_0.9.6-r0_armv4t.ipk wicd_1.5.6_armv4t.ipk wlan_0.3_arm.ipk tor-0.2.0.34_0.1_armv4t.ipk usbmode-button_0.3_armv4t.ipk xmahjongg-3.7_0.2_armv4t.ipk zinnia-tomoe-ja_0.6.0-20080911_armv4t.ipk zinnia-tomoe-zh_0.6.0-20080911_armv4t.ipk zedlock_0.1_armv4t.ipk zinnia_0.02_armv4t.ipk pytomboy_0.1_armv4t.ipk remoko-server_0.2.1_svnr119-r0_armv4t.ipk rotate_0.0.2_armv4t.ipk qwo_0.4_armv4t.ipk remoko_0.3.2_armv4t.ipk rotator_0.1_all.ipk sms-sentry_1.0-r0_armv4t.ipk swedish-illume_0.1_armv4t.ipk satan_0.4_armv4t.ipk scummvm_0.12.0_armv4t.ipk deforaos-browser_0.1.0_armv4t.ipk epiano_0.3.1-r1_armv4t.ipk ethtool_6_armv4t.ipk deforaos-editor_0.1.0_armv4t.ipk enscribi_0.1_armv4t.ipk euphony_0.1.3-r0_armv4t.ipk ffalarms_0.2-r0_all.ipk fido_0.2.2-r0_armv4t.ipk evopedia_0.1_any.ipk fbreader_0.8.2a-r7+elleopatches_om-gta02.ipk 0_pythm_0.5.5-dmr_armv4t.ipk 1_wireshark_1.0.99+svnr26030_armv4t.ipk acceleroids_0.1.0-0_armv4t.ipk 0_tshark_1.0.99+svnr26030_armv4t.ipk 0_wireshark-common_1.0.99+svnr26030_armv4t.ipk bt-gps_1.0-r0_armv4t.ipk cellhunter_0.4.2_armv4t.ipk agps_0.1_armv4t.ipk danish-illume-0.0.1.ipk batalarm_0.2_all.ipk illume-default-alt_0.1_arm.ipk guitartune_0.31_arm.ipk gtick_0.1_armv4t.ipk fourier_1.1_arm.ipk leafpad_0.8.15-r1_armv4t.ipk libsystem_0.1.0_armv4t.ipk gwaterpas_0.2_armv4t.ipk ledclock_0.6_all.ipk flashlight_0.1_armv4t.ipk gridpad_2.0-r0.1_armv4t.ipk gridpad_1.432-r0.1_armv4t.ipk libboost-signals1.33.1_1.33.1-r3_armv4t.ipk DATA gpssight_0.8.4_freerunner.armv4t.ipk EMPTY sortdesk_1.2_armv4t.ipk jdd_0.1_all.ipk usbmode_0.1_armv4t.ipk accel-rotate_0.41_armv4t.ipk 0_multitap-pad_0.1_armv4t.ipk omview_r32_armv4t.ipk deforaos-player_0.1.0_armv4t.ipk illume-keyboards-ru_0.2_om-gta02.ipk GZIP yphonekitd_0.4.3_any.ipk zomg_0.0.6-r2_armv4t.ipk mbac_0.3_all.ipk ylock_0.2_all.ipk mofi_0.02_armv4t.ipk illume-keyboards-norwegian-no_0.1_all.ipk efplayer_0.3_arm.ipk playstankontakarta_0.4_any.ipk osmupdater_0.4_any.ipk voicenote_0.3_arm.ipk mokocard_0.1_all.ipk mokoconv_0.1_all.ipk shortom_0.2_all.ipk So things seem to fail because: - Empty file is an empty file, not much to discuss about that. Only need to find out the reason for that: did the authors really upload an empty package or did the upload fail but an empty file was created? - ar isn't able to extract gzip files so all files recognized as gzip will not get listed properly in the Packages file. Again the reason for the wrong file type should be found: did the packages package it wrong or did the type/mime/something get corrupted along the way, during the upload or on the server? So if YOU reader have packaged some of the packages not recognized as debian binary please make sure that the package you upload is recognized as debian binary with the command 'file packagename.ipk' and then upload it again.. Now we only need to find out a way to contact all packagers... r Additionally there are a lot of Packages that don't contain a control file with depencies and so on: Form the packages in debian format are these: 0_tshark_1.0.99+svnr26030_armv4t.ipk danish-illume-0.0.1.ipk gtick_0.1_armv4t.ipk numptyphysics_0.3-svn118_armv4t.opk wicd_1.5.6_armv4t.ipk 0_wireshark-common_1.0.99+svnr26030_armv4t.ipk deforaos-browser_0.1.0_armv4t.ipk guitartune_0.31_arm.ipk openttd_0.6-r0.6_armv4t.opk xmahjongg-3.7_0.2_armv4t.ipk 0_xlogical_1.0-8-r0.4_armv4t.opk deforaos-editor_0.1.0_armv4t.ipk illume-keyboards-dutch-nl_0.3_all.opk pong_0.1_armv4t.ipk
Re: 2.5mm or 3.5mm
2.5mm. If you want to buy some earphones for a mobile, than you will get only some with 2.5mm connectors. Thomas Am Freitag 30 Mai 2008 09:35:36 schrieb Rahul Joshi: Exactly. 3.5mm for the same reason. Are there any tangible benefits to using 2.5mm though? Rahul J On Fri, May 30, 2008 at 12:05 PM, Richard Reichenbacher [EMAIL PROTECTED] wrote: 3.5mm. I'd rather be able to take any headphones I have laying around and use them for music. If I wanted a headset I would buy a Bluetooth headset. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joerg Reisenweber Sent: Thursday, May 29, 2008 11:18 PM To: community@lists.openmoko.org Subject: 2.5mm or 3.5mm Hi community! A short poll: on a future GTA0x (2), would you prefer to have A) standard 2.5mm headset (mic+phones) connector, where you have to buy a cheap adapter if you want to use your old headphones, (the way like it's for GTA01/02) or B) classic 3.5mm headphones Walkman(R) connector, where you have to DIY an adapter for any standard cellphone headset? (or does anybody know of 3.5mm headSET standards or adapters?) please hurry to vote, we have to make a decision. Thanks cheers jOERG Openmoko-HW-development ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
