QtMoko and FSO (was: qtmoko v33)
Radek Polak, Mar. 04, 2011, 07:37 +0100: > i have uploaded new qtmoko v33 images to sourceforge now [1]. [...] > The list is quite short on how much of work it was. Hello, Radek! Thank you for the work you are doing. > Most of the effort was to package everything with debian package system. This > should be done now except for kernel which is on the list for next release. > [...] > My plan for next version is to fix regression if you find any, package > properly > also kernel and release it as stable. > > Plans for future is FSO framework in qtmoko. I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like "about a year" or, say, "not less than four months". Thanks once more. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Gennady Kupava, Mar. 09, 2011, 22:48 +0300: > 1. qt stack has richer functionalily, better performance, and less bugs > than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) > 2. qt has it's own resource management, FSO - it's own, rewriting qt one > to FSO one is worthless effort OK, I'd like to ask one question now. Is there a reasonable technical way to *control* qt-stack-managed Freerunner without GUI? This means sending SMS from CLI and all these small things. In other words, I'm interested in command-line interface instead of programming interface. I believe the latter is up and running, but is the former implemented? Frankly, I do not know what the answer is. And yes, in case it is like "You just invoke this function from this library with proper arguments", I think I'll go and write a simple CLI wrapper, for this is just what makes Unix-like systems so usable. But if the only correct implementation lives deep in the code of qt stack, then we'd better try and separate it. Generally speaking, I guess it's convenient and powerful interfaces, rather than compatibility with existing applications, that matter more just here. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Dictopia & Qgcide
> About Qgcide: I let it download the dictionary > (/media/card/.qgcide/gcide-entries.xml.gz) but it turn out that I've not > enough space on the partition. Moreover that is a vfat partition and so > I can't make symbolic links in it. Is there a way to set a different > location for the dictionary? You can try mount --bind PATH MOUNTPOINT (that is, PATH is a directory where you have enough available disk space and MOUNTPOINT is a directory where you want to have it) or something similar (man mount/bind). -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[debian] cannot bootstrap libc6
Hello, I'm trying to install Debian on Openmoko Freerunner and have encountered the following problem. Both cdebootstrap and debootstrap fail to install a basic Debian system (stage "debian" of install.sh). Packages are downloaded and extracted, but dpkg is refusing to install libc6: === [...] I: Extracting zlib1g... I: Installing core packages... W: Failure trying to run: chroot /mnt/debian dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-8_armel.deb root@hackable1:~# chroot /mnt/debian dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-8_armel.deb (Reading database ... 349 files and directories currently installed.) Unpacking libc6 (from .../libc6_2.13-8_armel.deb) ... A copy of the C library was found in an unexpected directory: '/lib/arm-linux-gnueabi/libc-2.13.so' It is not safe to upgrade the C library in this situation; please remove that copy of the C library or get it out of '/lib/arm-linux-gnueabi' and try again. dpkg: error processing /var/cache/apt/archives/libc6_2.13-8_armel.deb (--install): subprocess new pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/libc6_2.13-8_armel.deb === If libc-2.13.so and libc.so.6 are then moved to /lib, then dpkg begins to wail about /lib/arm-linux-gnueabi/libdl-2.13.so, which suddenly emerges out of nowhere. On next iteration there appears libm... So, as far as I can see, all these files are just being unpacked from the very package I ask dpkg to install. Does this mean that Debian sid (unstable) armel is broken at the moment? How can this problem be dealt with? Changing --force-depends to --force-all does not help. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] fso stack does not work
Timo Jyrinki, Jul. 02, 2011, 08:51 +0300:
> You can try to use stable repositories instead by modifying the
> install.sh script [...]
Thank you for your advice. I managed to install from wheezy branch
instead of sid. I got tslib with Timo Juhani Lindfors' patch from
http://lindi.iki.fi/lindi/tslib/ and your kernel
linux-image-2.6.34-openmoko-gta02_20101212.git049b71de-2 from
http://pkg-fso.alioth.debian.org/incoming/ . Touchscreen now works
(thanks to both of you!).
Unfortunately, I was not able to get the FSO stack to work. When I start
fso-frameworkd service and invoke zhone, the latter reports "gsm ok:
implementing 'org.freesmartphone.GSM.Network' at
0x4059aa90>", but then stucks with "Requesting resource GSM" (full log
attached). fsousage log says:
"Resource GSM can't be enabled: Did not receive a reply. Possible causes
include: the remote application did not send a reply, the message bus
security policy blocked the reply, the reply timeout expired, or the
network connection was broken.. Trying to disable instead".
frameworkd contains several errors, including two python-related ones.
While googleing reveals that the absence of pyrtc (python-rtc) is not
fatal (is that correct?), there is more sinister-looking one:
"frameworkd.subsystem ERRORfactory method not successfully completed
for module "
...and a python call stack ending with "NameError: global name 'c' is not
defined". At the first glance I did not manage to mend it, though the
issue is quite clear: c is a global variable initialized at the module
level ("c" stands for "C library"). The log ends with a long sequence
of messages from ogsmd continuously trying (unsuccessfully) to "open
channels" MISC, UNSOL, CALL.
FSO package versions are included in a separate attachment.
Zhone is 0-git20110224+6bcb7fc4-1.
Has anyone encountered the same issue? Am I missing something? or is it
that Debian FSO packages are broken at the moment?
--
Dmitry Chistikov
fso-config-gta02 20100210
fso-frameworkd 0.9.5.9+git20100131-4
fso-gpsd 0.8-3.1
fso-gsm0710muxd 0.9.3.1-3
fso-sounds-yue-base 20081031-2
fso-usaged 0.9.1.1+git20100507-1
fso-utils 0.git20090919.1
libfso-glib0 2010.05.11.2-1.2
libfsobasics0 0.9.0+git20100509-2
libfsoframework0 0.2.4+git20100501-1
2011-07-04 19:47:55,605 WARNING could not load illume interface module
2011-07-04 19:47:56,344 DEBUG GUI init
2011-07-04 19:47:59,434 DEBUG GUI init done
2011-07-04 19:47:59,444 DEBUG entering mainloop
2011-07-04 19:47:59,643 DEBUG dbus_objectInit...
2011-07-04 19:47:59,696 INFO cached proxy for
org.freesmartphone.frameworkd:/org/freesmartphone/Framework
2011-07-04 19:47:59,745 INFO cached proxy for
org.freesmartphone.ousaged:/org/freesmartphone/Usage
2011-07-04 19:47:59,798 DEBUG usage ok: :1.104 /org/freesmartphone/Usage
at 0x4053dc30> implementing 'org.freesmartphone.Usage' at 0x4053dd10>
2011-07-04 19:47:59,818 INFO cached proxy for
org.freesmartphone.ogpsd:/org/freedesktop/Gypsy
2011-07-04 19:48:00,020 DEBUG gps ok: :1.96 /org/freedesktop/Gypsy at
0x4053df10> implementing 'org.freedesktop.Gypsy.Accuracy' at 0x4059a110>,
:1.96 /org/freedesktop/Gypsy at 0x4053df10> implementing
'org.freedesktop.Gypsy.Position' at 0x4059a390>, :1.96
/org/freedesktop/Gypsy at 0x4053df10> implementing
'org.freedesktop.Gypsy.Satellite' at 0x4059a4d0>
2011-07-04 19:48:00,048 INFO cached proxy for
org.freesmartphone.ogsmd:/org/freesmartphone/GSM/Device
2011-07-04 19:48:00,088 INFO cached proxy for
org.freesmartphone.ogsmd:/org/freesmartphone/GSM/Server
2011-07-04 19:48:00,283 DEBUG gsm ok: :1.97
/org/freesmartphone/GSM/Device at 0x4059a8b0> implementing
'org.freesmartphone.GSM.Network' at 0x4059aa90>
2011-07-04 19:48:00,326 INFO cached proxy for
org.freesmartphone.odeviced:/org/freesmartphone/Device
2011-07-04 19:48:00,364 INFO cached proxy for
org.freesmartphone.odeviced:/org/freesmartphone/Device/IdleNotifier/0
2011-07-04 19:48:00,463 DEBUG device ok: :1.94 /org/freesmartphone/Device
at 0x405a00d0> implementing 'org.freesmartphone.Device' at 0x405a0190>
2011-07-04 19:48:00,483 INFO cached proxy for
org.freesmartphone.opreferencesd:/org/freesmartphone/Preferences
2011-07-04 19:48:00,503 DEBUG preferences ok: :1.101
/org/freesmartphone/Preferences at 0x405a05b0> implementing
'org.freesmartphone.Preferences' at 0x405a0690>
2011-07-04 19:48:00,521 DEBUG failcount = 0
2011-07-04 19:48:00,532 DEBUG dbus_objectInitOK!
2011-07-04 19:48:00,542 DEBUG Requesting resource list
2011-07-04 19:48:00,619 DEBUG Requesting resource GSM
2011.07.04 19:47:27.851 odeviced.audio WARNING GST can't parse modplug;
Not adding mod to decoderMap
2011.07.04 19:47:27.860 odeviced.audio WARNING GST can't parse mad; Not
adding mp3 to decoderMap
2011.07.04 19:4
Re: [debian] fso stack does not work
Dmitry Chistikov, Jul. 05, 2011, 09:07 +0400:
> "frameworkd.subsystem ERRORfactory method not successfully completed
> for module '/usr/lib/pymodules/python2.6/framework/subsystems/odeviced/input.pyc'>"
>
> ...and a python call stack ending with "NameError: global name 'c' is not
> defined". At the first glance I did not manage to mend it, though the
> issue is quite clear: c is a global variable initialized at the module
> level ("c" stands for "C library"). [...]
I solved this with the following code:
--- linux.py.orig 2011-07-05 15:29:11.0 +0400
+++ linux.py2011-07-05 15:26:20.0 +0400
@@ -19,12 +19,14 @@
re = compile('^libc.so.[0-9]$')
libs = os.listdir('/lib')
for lib in libs:
if re.match(lib):
c = ctypes.cdll.LoadLibrary(lib)
break
+else:
+c = ctypes.cdll.LoadLibrary('libc.so.6')
_IOC_NRBITS = 8
_IOC_TYPEBITS = 8
_IOC_SIZEBITS = 14
_IOC_DIRBITS = 2
The reason the original version does not work is as follows:
root@ziggy:~# ls /lib | fgrep libc.
root@ziggy:~# find /lib -name 'libc.*'
/lib/arm-linux-gnueabi/libc.so.6
Is anyone interested in fixing this packaging bug?
The main problem still persists, though =(
--
Dmitry Chistikov
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Some newbee questions about Qtmoko, navit, Vodafone GPRS and battery capacity
Patryk Benderz, Jul. 25, 2011, 14:42 +0200: > > and any ping s were done by using usb0- device...strange. If I switch > > of the usb0- device, the route entry of usb0 is automatically deleted > Are you sure. Few lines above you have mentioned, that you have two > GW... anyway, I would avoid setting up routing to your PC host via usb0 > interface as a default route. Use static route instead. I would suggest simply setting the metric of the default route via usb0 to, say, 10. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] How do you manage your free space ?
Sebastian Reinhardt, Aug. 05, 2011, 19:20 +0200:
> Am 05.08.2011 19:01, schrieb Xavier Cremaschi:
> To save some space, You can copy whole directory "/usr" to sd-card and
> create an symbolic link ("ln -s path-to-sd-card/usr /usr"). This can
> help a little, because many data of additional packages is stored to
> directory "/usr"
First, I'd recommend using an fstab line instead of a symlink.
It's a more standard method of "joining" filesystems on different devices.
If one cannot allocate a separate partition for /usr for some reason,
it is advisable to use a bind mount (man mount, search for "bind mounts")
as an fstab line.
It should be checked, however, whether the system is able to boot
correctly, when configured in any of these ways (including one with
a symlink). According to FHS, it must be able to boot, but things
might have been broken accidentally. (Though I hope they are not.)
--
Dmitry Chistikov
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] How do you manage your free space ?
Gennady Kupava, Aug. 06, 2011, 23:42 +0400:
> Also i think it's probably better to have
> single tree in fstab, not a graph of mounts until [...]
$ whatis fstab
fstab(5) - static information about the filesystems
I'd think a piece of information of this kind should be placed
exactly in fstab ;)
> Also you free to create,
> rename or remove symlink, while bind-mount is sligly more difficult to
> manage.
To tell you the truth, I see only one difference between
ln <-> mount --bind, mv <-> mount --move, rm <-> umount:
before mounting, one is to make sure that mount points (directories)
exist.
Paths to files "under" symlinks are easily shown to be inherently
different: one is "real" ("absolute", see realpath(3) or realpath(3p))
and the other is not. For bind mounts, the same is not true.
# pwd
/tmp
# mkdir -p a/a0 b
# ln -s /tmp/a/a0 b/b1
# mkdir b/b2
# mount --bind /tmp/a/a0 b/b2
# touch a/a0/f
# realpath b/b1/f
/tmp/a/a0/f
# realpath b/b2/f
/tmp/b/b2/f
The realpath utility simply resolves a path with a standard libc
function realpath(3). Its source code can be found, e. g., at [1].
Note that while information on bind mounts can still be extracted
from /proc, filenames under a/a0 and b/b2 are equally "good" for all
reasonable userspace applications.
In rare cases, using symlinks for directories can result in strange
behaviour. Link [2] (in Russian) leads to ALT Linux Bugzilla and points
to a bug caused by a symlink /home -> /srv/home.
On the whole, I think that bind mounts are somewhat "safer" and less prone
to errors.
And yes, a normal device mount, if possible, looks even better to me.
[1]
http://git.altlinux.org/gears/c/coreutils.git?p=coreutils.git;a=blob;f=alt/realpath.c;h=5e8f50dbc4d10e02389a004178bb6ba606d0b2ed;hb=85e67589a5e9784918145d17200416afcea7d809
[2] (in Russian)
https://bugzilla.altlinux.org/show_bug.cgi?id=25786
--
Dmitry Chistikov
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] breaking thread MUA (WAS:Re: TSM30 source found!)
Michael Sokolov, Sep. 30, 2011, 19:14 +: > That's right, it doesn't. It is 30 y old and well predates those > conventions. > [...] I cannot / will not use a "modern" mail client. > For personal reasons which I *will not go into*. I'm sure your skills are strong enough to improve your MUA, i.e., to teach it how to insert proper References:/In-Reply-To:. Could you devote a small amount of your time to this thing? I'm quite convinced that all of your correspondents, including people reading this mailing list, will *greatly* appreciate this. (For me, reading broken threads is a rather unpleasant activity, and so it may be for a significant fraction of the community at large.) Thank you. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] breaking thread MUA (WAS:Re: TSM30 source found!)
Dmitry Chistikov, Oct. 02, 2011, 00:33 +0400: > Michael Sokolov, Sep. 30, 2011, 19:14 +: > > That's right, it doesn't. It is 30 y old and well predates those > > conventions. > > [...] > (For me, reading broken threads is a rather unpleasant activity, and so it > may be for a significant fraction of the community at large.) Another bit, JFYI. RFC 2822 says: RFC> reply messages SHOULD have "In-Reply-To:" and "References:" fields" (the meaning of SHOULD is described in RFC 2119). Actually, I'm quite surprised that your mail client, even if 30-year-old, does not insert these fields, since they were described in RFC 724 as early as in 1979. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
