[QTMOKO] - list of questions from a new user..

[Risto H. Kurppa]

On Mon, Mar 15, 2010 at 11:38 AM, Radek Polak <psonek2 at seznam.cz> wrote:
> On Monday 15 March 2010 09:48:48 Risto H. Kurppa wrote:
>
>> How to export the SMS's qtmoko moved from SMS to a sane format.. say
>> txt file or whatever..
>
> You can check this directory:
>
> /home/root/Applications/qtopiamail/mail
>
> I think it's quite standard mail format.

Yes, kmail for example was able to open it, or manually I can decode
it like this:

begin-base64 644 a
three rows of hash
====

and giving this to uudecode

A bit of a pain but now they're readable at least. A tool to export
SMS's to a readable format would be nice.


>> Is there a plan to make qtmoko NOT touch the SMS's on the SIM..? Big
>> fail to remove all SMS's from SIM without warning the user..
>
> In Qt Extended 4.4.3 it was keeping them on SIM. But it was causing bug where
> all SMS were getting doubled and after every new SMS.

OK, I see, so this should only be a temporary solution. Thanks!

>> Is qtmoko using the latest alsastate files - What I heard was very
>> silent and the other end didn't hear a thing..
>
> I think we need two sets for alsa state files - for buzz fixed and non buzz fixed
> freerunners. Mine freerunner does not have buzz fix, so i am shipping only non
> buzz fixed state files in my releases.

I actually copied alsa statefiles from debian and it didn't improve.
I'll try to check more closely at some stage.

> Or we can implement some volume control during call - i think the api is there
> and it should be quite easy.

Would be very useful.. THere's a reason why all other phones have
volume control during call :)

> Or application in feeds that replaces state files or it can be another step in
> the startup screen where you can selected that you have buzz fixed freerunner.

see http://lists.openmoko.org/pipermail/community/2010-March/060800.html
<- the same idea has been thought also for other distros :)
I think the problem here is, who's able to provide the 'best'
alsastates for each configuration..

>> Who's developing qtmoko?
>
> It depends with every release. I am always trying to credit everyone who
> helped in the release mail in this community ML.

I see that your git is the only one that has changes so from now on I
consider you as the developer unless something proofs me wrong :)

>> Are the FSO-based and debian based developed at the same time?
>
> In short: I am focusing just on debian. I dont have time to do images for two
> rootfs.

Very good!

> There are basically 2 things we are now developing. Qtopia which is more or
> less just big application. It should run on any rootfs. I am trying to avoid
> debian specific stuff. I have reports that some users run Qtopia on Arch so it
> will probably run on FSO too. It would be interesting to run Qtopia on Openwrt
> with uclibc - could be faster then debian.

Sound's very good, thank you!

>> How do v18 and v19 compare? Why v18 is 'preferred download' at
>> sourceforge (http://sourceforge.net/projects/qtmoko/files/)?
>
> Because i uploaded them in reverse order and i dont know how to tell
> sourceforge to prefer v19 ;-)
>
> v19 is the most "stable", v18 has some problems related to new 2.6.32 kernel,
> but still is quite usable.

ah, ok :) So maybe I'll try to flash v19 and let you know how it turns
out :) At least the resume speed of v18 is amazing!

>> Why is the access to qtmoko bugtracker at
>> http://bugs.qtmoko.org/login_page.php for registered users only?
>
> We had a lot of spam there. I havent configured the bug tracker, but i can
> check if i can change it.

If you wish people to report bugs, I understand that registration is
useful - but it's a pain to have all of it hidden behind password so
that you can't even see what bugs there are..
The anonymous login doesn't work.

>> I apt-get upgrade, do I get to v19 from v18?
>
> No, apt-get upgrade now just upgrades the rootfs. Upgrading kernel+qtopia had
> to be done manually.

ok, thanks

>> Is the kernel provided at sourceforge
>> (http://sourceforge.net/projects/qtmoko/files/) with or without DEBUG
>> ie. is it the 'new, fast' or 'older, not so fast'?
>
> The uImage-v18.bin is fast 2.6.32 nodebug kernel.
>
> If you use qtmoko v19 then you have to decide between kernels (slow and
> reliable or fast with some problems debug/nodebug).

At this stage I might try the reliable one first :)

>> Where is the qtmoko community? Openmoko-community mailing list? This
>> channel? Other places? Blogs, forums?
>
> This mailing list and IRC are probably the best choices.

ok, will keep my eye on these two :)

Thanks for the answers!



r

-- 
| risto h. kurppa
| risto at kurppa dot fi
| http://risto.kurppa.fi