login
Search
Hi, With the gust of fresh air everywhere, I took the liberty of joining the mess that was combined http://wiki.openmoko.org/wiki/Debian + http://wiki.debian.org/DebianOnFreeRunner , so that in the end the Openmoko wiki page is just a brief showcase about Debian and all information is included in a sensible, structured way on the Debian's wiki. There is still the problem of install.sh having problems, but besides that (waiting for debian-installer support) I believe trying Debian out is much more easier now if you just tumble upon the wiki and start exploring, instead of already knowing someone who uses Debian. Using Debian on the FreeRunner is quite a great joy for anyone using Debian/Ubuntu/etc. on the desktop. Feel free to continue the work of cleaning up wiki(s). I was inspired by Risto's call for wiki cleaning, and I had already for some time thought the Debian side of instructions is in a terrible state. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Nice, well done! I like that the moko page of Debian is a graphical showcase (add your OpenOffice screenshot there!) and the install instructions are separated (to debian wiki). I don't really remember calling for wiki cleaning, maybe mentioned the messy wiki somewhere but yes, the wiki needs a cleanup! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Done :) Thanks. I added some examples, though I haven't myself installed Debian for a while since everything works and I haven't had a working This should theoretically be correct, though the possible environment variables matching the previously done partition setup would not hurt. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I installed debian a couple of days ago. 1st try with a new 8GB sandisk uSDHC card, which failed with IO errors. I assume this is because of the SD card speed. Tried with a sandisk 4GB uSDHC, using install.sh, with VFAT boot partition. Install worked fine. Some problems encountered :- Re-camping. I can only tell it is doing this because I left it near my PC and the speakers were picking it up! Happens about every 5-10mins. I did not have this problem with SHR, it is stable for GSM. SMS has a few quirks, but nothing major. I know there is a hardware fix for this, but why no problems with SHR? Wifi, could not connect to my T-Com (Germany) wireless router (WEP). It was picked up using wifi-radar, but failed to get an IP address. I have never been able to connect to this router though, even using command line and config files etc. I have a new linksys N wifi router which I will try it on soon. GPRS worked fine. Midori and tangoGPS do not pick anything up from the internet via USB connection to PC. I can ping google no problem. Midori worked via GPRS. Not sure how to put it into suspend, seems a bit flakey! I have not had time to look into any of these problems yet, but will report findings when I do. -Lee
Possibly because newest FSO release (5.5?) has not yet come to Debian. I don't remember if 2.6.28 or 2.6.29 is now the default in Debian. One should generally install the 2.6.29 kernel - but the lingering problem regarding 2.6.29 there is the omission of the patch that makes wifi really work there http://docs.openmoko.org/trac/ticket/2277 . 2.6.28 has other problems, but 2.6.29 with that patch basically rocks for Works fine with my USB, I have the usual NAT forwarding on my laptop. Though nowadays I actually forward the network via Bluetooth to Neo :) Press the power button? Also, in the wiki guide there are instructions about suspend settings in general. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Debian uses "adaptive" as default for "ti_calypso_deep_sleep", and SHR uses "never" With "adaptive", FSO should detect your freerunners's recamping and disable deep_sleep. With "never", as you probably guessed, FSO will never try to deep_sleep, and recamping will *NEVER* happen. Take in account that with "adaptive", recamping *WILL* happen at the beggining, but should stop as soon as FSO detects it. If adaptive is not working on your case (e.g. if recampings are not frecuent), you should change in /etc/frameworkd.conf: ti_calypso_deep_sleep = adaptive to ti_calypso_deep_sleep = never and your problems will dissapear. -- David Garabana Barro jabber & google talk ID: david@garabana.com Clave pública PGP/GPG: http://davide.garabana.com/pgp.html
Tried to install debian today: INST_MIRROR=http://ftp.fi.debian.org/debian HOST=ribian TASKS=ALL SINGLE_PART=true QI=true ./install.sh all problem #1: fdisk fails. (copied from irc..) 10:08 < rhkfin> Syncing disks. 10:08 < rhkfin> Partitioning failed, could not execute with fdisk: 10:08 < rhkfin> n 10:08 < rhkfin> p 10:09 < rhkfin> 1 10:09 < rhkfin> 249296 10:09 < rhkfin> w and executing stops.. -> I created the partition manually and tried again with INST_MIRROR=http://ftp.fi.debian.org/debian HOST=ribian TASKS=ALL SINGLE_PART=true QI=true ./install.sh testing time format mount debian apt fso configuration tasks kernel cleanup unmount E: Internal error: install Some more hacking and I got 11:03 < rhkfin> O: Errors were encountered while processing: 11:03 < rhkfin> O: readline-common 11:03 < rhkfin> O: libreadline5 11:03 < rhkfin> O: gpgv 11:03 < rhkfin> O: gnupg 11:03 < rhkfin> O: debian-archive-keyring 11:03 < rhkfin> O: apt 11:03 < rhkfin> E: Internal error: install Added installation-info to the code (per this patch: http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2009-August/001752.html ) Tried again: O: Unpacking apt (from .../bootstrap/apt_0.7.23_armel.deb) ... P: Unpacking package apt O: Setting up libbz2-1.0 (1.0.5-3) ... P: Configuring package libbz2-1.0 O: dpkg: dependency problems prevent configuration of readline-common: O: readline-common depends on dpkg (>= 1.15.4) | install-info; however: O: Version of dpkg on system is 1.15.3.1+b3. O: Package install-info is not installed. O: dpkg: error processing readline-common (--install): O: dependency problems - leaving unconfigured O: dpkg: dependency problems prevent configuration of libreadline5: O: libreadline5 depends on readline-common; however: O: Package readline-common is not configured yet. O: dpkg: error processing libreadline5 (--install): O: dependency problems - leaving unconfigured O: Setting up libusb-0.1-4 (2:0.1.12-13) ... P: Configuring ...
I really dont like these long install scripts. When it works it's good but if not, it's really hard to find where is problem. I think Debian should be offered as ready-for-flash image. I am creating debian images from scratch for every QtMoko release using instructions in simple txt document [1] and it always works perfectly. In contrast with the install script - i never managed to install debian with it. Btw you can flash QtMoko images, delete /opt and /etc/inid.d/qpe and you Btw that poll is not very well done. QtMoko is the very last column that is not visible (in firefox on jaunty). I am doing that distro and i nearly havent voted for it :) Radek [1] http://github.com/radekp/qtmoko/blob/9f1ca538c388cc3f4d4614e6d25c9ef17e2c5295/doc/txt/... [2] http://activationrecord.net/radekp/qtmoko/download/ _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I can't see why copypasteing 100 lines would be different from running a script with the same commands? (ok, except that you can stop, make No no, it's very well made, on purpose I left QTmoko to be the last one so no-one would vote it! The truth is that it wasn't there at all when I published the poll - because I forgot it, not having followed closely what happens in the QT world. SOmeone pointed it out for me and I added it, and I only could add it as the last one. And someone's got to be the last one. And if you vote, you try to look for your distro, no matter if it's the last or the first? I'd like the doodle layout to allow more space but I guess the scroll bar is visible enough.. and one more, the poll only represents the part of the community that's 'active' ie. reading mailing lists, irc etc: as over 10 000 units are sold (with uboot and OM200x in them) this really doesn't represent the whole population.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Unfortunately it was found out installing Debian via the install.sh script is broken until dpkg 1.15.4 lands in unstable. So, keep eye on http://packages.qa.debian.org/d/dpkg.html Only manual installation using debootstrap is possible meanwhile. Updated http://wiki.debian.org/DebianOnFreeRunner#CurrentStatusofInstallation -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
1.15.4 ARM build has now landed in the Debian archive (at least ftp.debian.org, mirrors soon follow, check ftp://ftp.XX.debian.org/debian/pool/main/d/dpkg/ for armel 1.15.4 deb). Additionally install.sh was earlier updated to offer optional debootsrap-instead-of-cdebootstrap option. For this and future updates on the status of installing Debian, until proper debian-installer support is there, please see the page / section: http://wiki.debian.org/DebianOnFreeRunner#CurrentStatusofInstallation I (at least) will try to keep that up-to-date. Currently the chances of getting Debian installed with install.sh sound quite high, but I haven't tested it myself right now. Please tell your experiences if you try the installation with the tips on that page... meanwhile, I will also update the page myself if I test it with an extra SD card again some time next week. I'm quite glad with the new E17 and Zhone packages in the main Debian archive. The only package you really need from the (still enabled by default) pkg-fso archive is the kernel, so this is very good progress. The kernel is of course a hard thing and involves work from all Openmoko kernel developers who have time to get stuff upstream, but after that it would be not a big way to proper Debian installer support - which eventually even leads to a Debian stable release with official support for FreeRunner. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Doing debian install with (c)debootstrap, as current install.sh does and as debian installer does, although being a standard way, is somewhat questionable on slow devices such as freerunner. This is plainly slow, compared to reflashing or archive unpacking. Also it is vulnerable to temporary archive breakages, as the current story with dpkg 1.15.4 shows. Because of that, and also given quite a big challenge to make d-i working on freerunner itself (no keyboard, no serial console, etc), it may be much better to look not at d-i porting, but at archive preparation on server and untarring on user device. Optionally, such a process could be implemented as a d-i module that will run instead of (c)debootstrap. And, after all, installation is not the only thing that should work :) Besides installation, there is still a long path to make debian of freerunner as usable as debian should be. There is large, and constantly increasing number of freerunner software. Att hose need to be packaged for debian. If they won't, user will end with instaslling unpackaged software and breaking their systems. Remenber, zhone is not intended to be end-user phone app. We should package paroli, and/or litephone, and/or shr phone tools. Also, something should be done such that packages provide good user experience just after installation. For example, it's nice that mokomaze is in debian, but if you install it and run it, you will get your screen blanked after a minute. To avoid that, one needs to start mokomaze under fsoraw wrapper. Making this happen automatically while staying within debian policy could be a challenge: debian package is not for freerunner only, modifying files installed by other packages (hi hi appraw) is denied by policy, etc And it was just an example. Another one: after aptitude install mplayer, I get mplayer icon in illume, that launches mplayer gui, next to useless on freerunner. But if/when we will have intone packaged, we will want to have mplayer ...
There is truth to that, but I just personally prefer "real" installation to .tar.gz:s. Of course, with a grain of trustworthiness of having the .tar.gz:s hosted under Debian it would be better than However, zhone works quite well. But yes paroli for example definitely - and we're on a very good path now. Elementary is now (again) in NEW queue (http://ftp-master.debian.org/new.html), after that there is only python-elementary bindings left to have everything ready for Yeah, thanks for bringing me back to Earth :) I just accept almost anything if I just get to use Debian, and I'm happy the ground work starts to be ready, but those two examples are quite good about the real polishing need. TangoGPS of course works quite flawlessly at the moment, but MPlayer with Tremor support and without confusing GUI option would be good, as well as a fixed mokomaze. I believe there are always ways to fix the problems in an acceptable way, but it may indeed need some work. Maybe something can be done in the openmoko-files-config to trigger some stuff in eg. mokomaze. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Why would you need to? You can create another package, with a dependency on mokomaze and fsoraw, to install the necessary .desktop file. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Why would I need what? When some piece of software is packaged for Debian, the same package is becoming available for all architectures and devices that Debian supports. For FR, it is a good idea to wrap some binaries with fsoraw. For other devices, this is not needed. This is a difference that should be handled somehow. Although creating a wrapper packages that dpkg-divert's files from original packages and installs better versions, will likely work, this is somewhat ugly. Better to create single 'freerunner-support' package that will contain knowledge about many other packages, and hook into installation process. Nikita _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Why would you need to modify files installed by other packages? Just create a package with this as /usr/share/applications/mokomaze-noblank.desktop: [Desktop Entry] Name=Mokomaze (no blanker) Comment=Ball-in-the-labyrinth game Encoding=UTF-8 Version=0.5 Type=Application Exec=fsoraw -r Display -- mokomaze Terminal=false Categories=Game; X-MB-SingleInstance=true Icon=mokomaze -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
That will result in two icons in launchers. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
> That will result in two icons in launchers. why nor let the user decide on installation or check in postinst for arm and copy the matching one? _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Not "for arm" but for "fso-controlled device". And depending on a result of such a check, different .desktop files should be installed under /usr/share/applications/ ... This looks more tricky and ugly for me than install-time-hook approach. Anyway currently there are more urgent things to do :) _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Or more precisely, for "$DISPLAY on fso-controlled device" at runtime, not installation time. I think that mess will be larger than that of having two icons, menu items or whatever the launcher makes of it, for the user to choose between. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
The solution is to use a scheme where the blanking code and the
application use a standard protocol to sync-up.
AFAIK, there is such a protocol already (which is hopefully used by all
tools like VLC, Xine, mplayer, totem, at least when in fullscreen
mode). So mokomaze should use it. And the FSO side should also
support it.
Stefan
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
On Sun, 13 Sep 2009 21:42:49 -0400 Stefan Monnier <monnier@iro.umontreal.ca> x screensaver extension. you can request x to suspend blanking until u un-suspend it (or your x connection closes - eg u exit or crash). FSO tho wants to re-invent this wheel. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) raster@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Indeed... sounds like a bug report to the FSO guys is in order.
Stefan
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
This could be likely implememted in form of a X "screen saver" application that will e.g. keep FSO's "Display" resource requested until it is time to "save screen", at which moment "Display" resource should be released. And re-requested when screen should no longer be "saved".
On Mon, 14 Sep 2009 09:38:49 -0400 Stefan Monnier <monnier@iro.umontreal.ca> well fso wants to implement this so it works outside of x11. personally i dont think fso should be blanking, playing with or otherwise having anything to do with the screen. the display system does that, be it x11, dfb or some dumb fb app. these apps should/could feed fso with idle information, if they please, but this should be left to the windowing system and its environment to handle. imho. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) raster@rasterman.com _______________________________________________ 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
On Tue, 15 Sep 2009 00:11:54 +0200 "Michael 'Mickey' Lauer" thats where i disagree. you have e-invented fso handling idle detection, even if optional. it should b the other way. fso is notified of idleness by the respective management systems. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) raster@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkqxbrgACgkQ9ijrk0dDIGwndQCguazKvA+K0qfoNVDop0z0F5J8 WtMAoM+bFNqDUNLRaAffAaa6I/I0jmlW =QvI1 -----END PGP SIGNATURE-----
Cant think out a use case when same device will run a window manager (or whatever component that uses .desktop files) sometimes with fso and sometimes not ... _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Eh? $DISPLAY can point to another device than the one running the window manager and/or launcher, this setup is standard practice in the X world. Please refer to e.g. <URL:http://en.wikipedia.org/wiki/X_display_manager>. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Sure. I use such configurations heavily myself. But doing so from a phone-like device is a very strange idea IMO. Could you find a useful use-case for that? Nikita
Nice as the FR screen and illume keyboard are, I sometimes wish I had a bigger screen, or a real keyboard. Or a mouse. Navit and tangogps in particular benefit from a bigger screen. Until recently neither were on my netbook, but a quick bit of display forwarding took care of that. I've also used it while developing python apps because it's more convenient to have app appear on the screen where I'm doing the editing. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
For those of you (like me) who don't read help texts, I added the pretty useful information about needing to install perl on the "host" system before running the install script :) Also linked to the latest success report of installing Debian, requiring 1 workaround to finish. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Could you please post an explanation on how to test/use gprs on debian?
Maybe see http://wiki.openmoko.org/wiki/GPRS_FSO#Using_scripts ? I added now a link to that page also from DebianOnFreeRunner. I'm myself actually using old method from my Om2008.12, since it seems to work. I launch this from a PyGTK application: identvar=$(date +%s) ptsvar=$(dbus-send --system --print-reply --type=method_call --dest=org.pyneo.muxer /org/pyneo/Muxer org.freesmartphone.GSM.MUX.AllocChannel string:$identvar | grep string | awk -F '"' '{ print $2 }') sleep 2 echo $identvar $ptsvar pppd $ptsvar 115200 call gprs ...and have setup /etc/ppp/gprs-connect-chat + /etc/ppp/peers gprs. But I guess it's pretty useless if FSO stack takes care of all that when sending a single dbus message like described on the GPRS_FSO wiki page. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I had been looking at installing debian a couple of days ago and it seems that this is a definite improvement! The only suggestion I have is to add some more examples for the install.sh script. An example that shows how to install debian on an already existing (empty) partition would be great. From the documentation I gather that this could be done by doing: mount /dev/your-partition /mnt/debian ./install.sh debian apt fso configuration tasks kernel cleanup unmount but I didn't test this (don't want it to start installing it on the _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
