Re: adaptation of Extras QA hurdles

[Riku Voipio]

On 01/27/2011 10:24 AM, ext Thomas Perl wrote:
> 2011/1/27 Riku Voipio :
>> For new versions, the set of checks should still be shorter and less
>> votes needed. Basically the only check to be done is "has the new
>> version any regressions compared to the version already in extras".
> 
> So a rouge developer could just upload a well-behaving tool at the
> first time (where a more thorough check takes place and more votes are
> needed), and then upload another release later on with some dangerous
> code which sets the device on fire, and this update does not need so
> any votes? 

Read again. I did not say "no checks" or "no votes" for upgrades. I said
*less* checks and *less* votes.

> It does not even have to be a rouge developer - just think
> about the Debian SSL vulnerability.

And you think that our current 10 voters process would catch *that*? You
can't complain that we should not go down 5 votes on upgrades when 10
testers wont catch bugs like that anyways..

> I'd consider a normal update as important as a new release. 

There is a big difference - when new version is uploaded, there is
already a version in extras. Thus there is only one question that needs
answering - is the version in extras-testing better or worse than the in
extras.

If there is bug in the version in extras, people will be installing the
buggy version as long as the new version drags it feet extras-testing.

> If we were
> doing some kind of fast-tracking for minor updates, we should at least
> show a debdiff of both source packages somewhere in the web UI, so
> that a fellow developer can check what source code changes are in
> there, and have a better understanding of the changes (it should be
> obvious from the source diff what changes there are, and if they are
> minor and really just aim to fix a bug).

Showing debdiff on new versions would be a good idea. Still, I'd also go
with less votes (like 5) to encourage people to upload bugfixes often.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: adaptation of Extras QA hurdles

[Riku Voipio]

On 01/25/2011 05:24 PM, ext Andrew Flegg wrote:
> On Tue, Jan 25, 2011 at 15:03, Felipe Crochik  wrote:
>> A new version of an existing application should have a lower barrier to
>> promotion than a new application.

> It's obvious; but even a minor change can have an enormous impact.
> However, it's unlikely that the package (once optified) will become
> non-optified and numerous other things (descriptions will only bitrot
> when major new features are introduced; icons won't disappear; bug
> trackers are fairly persistent etc.)

For new versions, the set of checks should still be shorter and less
votes needed. Basically the only check to be done is "has the new
version any regressions compared to the version already in extras".

Riku
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to optify in MADDE?

[Riku Voipio]

On 06/10/2010 11:32 AM, ext Daniil Ivanov wrote:
> Hi Daniel!
> 
>   Of course manual optification is the way to go when there is no other way.
>   But is it so that installing scratchbox and performing optification
> there is considered as too difficult?
>   BTW, are there any chances maemo-optify will be included into MADDE?

IMHO Rather than adding support for maemo-optify, madde should optify
(eg. install everything under /opt/projectname/) builds by default when
targeting n900.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Cannot install Maemo SDK 1.2 in Ubuntu Lucid: dependencies problems

[Riku Voipio]

On 05/03/2010 09:40 PM, ext Marcin Juszkiewicz wrote:
> Dnia poniedziałek, 3 maja 2010 o 08:03:57 tero.k...@nokia.com napisał(a):
>> Try:
>> ~# echo 0 > /proc/sys/vm/mmap_min_addr
>>
>> At least that is what people more knowledgeable than me tell to do. It has
>> something to do with the recent kernels and QEMU.

> Better would be qemu update to 0.12 which does not need that trick anymore. 
> But such sugestion is WONTFIX for fremantle rather.

scratchbox qemu has had that fix for ages... The bug is in ubuntu
lucid's kernel. As non-root you no longer can read
/proc/sys/vm/mmap_min_addr. See:

https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/568844
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Extras-testing improvements

[Riku Voipio]

On 03/09/2010 02:19 PM, ext Simon Pickering wrote:

Also, the idea that an application can both be "low quality" and "end
user ready" is bizarre.



If the general Nokia view is that Extras apps should also look pretty
and have nice design (i.e. so they reflect well on the device), which is
a good goal for all apps, but should not be a requirement, then we need
another repo layer between Extras-testing and Extras proper, where apps
that work but are perhaps not up to the stringent prettiness standards
can be placed.


I do not represent the general view of my employer or anyone else, just 
myself. But poor quality applications reflect badly on maemo.org 
community as well. Do you want to be part of a community which is known 
for its low quality standards? Notice that the current extras-testing QA 
requirements are quite low:


1. [ ] Bug database exist.

Annoying, but not hard to add (particularly if you choose a tmo thread 
instead of bugzilla).


2. [ ] Licensing ok.
3. [ ] No illegal/dubious content.

Yep, no piracy is acceptable.

4. [ ] Working provided features.

Yep. crashing apps are bad.

5. [ ] No missing announced features.

If something doesn't work (yet), don't advertize it. Don't dissapoint users.

6. [ ] Optification ok.

Should we start accepting packages that break SSUs ?

7. [ ] No performance problems.
8. [ ] No power management issues.

This could be clarified to belong only to always-running apps (such as 
hildon-desktop plugins).


9. [ ] No known security risks.

This is a bit sketchy, but certainly allowing things like "default 
password ssh server" would be very very bad for endusers.





___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Extras-testing improvements

[Riku Voipio]

On 03/09/2010 01:29 PM, ext Matan Ziv-Av wrote:

On Tue, 9 Mar 2010, Attila Csipa wrote:


On Tuesday 09 March 2010 11:56:49 Matan Ziv-Av wrote:

On Tue, 9 Mar 2010, Niels Breet wrote:

You have to see that Extras should be for applications that are of a high
quality. The Extras repository should not give any problems to people who
are new to Maemo and have no clue how to work with linux for instance.


Here's the problem, there seems to be two (almost opposite) goals for
this extras repository: one is to be a collection of all maemo software,
eliminating the use of external repositories, the other is having a
collection only of high quality software. Until you accept that
you can't have both, those discussions will go on repeating.


There is nothing preventing (well, apart from autobuilder issues) people
putting things into Extras-devel. It *is* a valid place for software, it's
not the gutter, and not every application there is expected to enter Extras.
I often feel the issues brought up in relation with the term 'quality' stem
from different interpretations of the term ->  terminology.


The extras-devel wiki page defines this repository as a repository of
programs that are not ready for end-users. Since my package is ready for
end users, extras-devel is not the repository for it. It also makes no
sense for me to suggest to users who want to install my package to
enable a repository that may crash and burn their device.


The whole point of extras-testing is to weed out enduser ready 
applications from applications from applications that crash and burn 
your device. If your application is ready for endusers, it should pass 
via extras-testing. If it doesn't pass, either it is not ready, or the 
extras-testing process is broken. The latter is what we are fixing here 
in this thread.


Also, the idea that an application can both be "low quality" and "end 
user ready" is a bizarre.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Extras-testing improvements

[Riku Voipio]

On 03/09/2010 01:04 AM, ext Attila Csipa wrote:

I hope Valerio won't mind me taking the initiative here, but I'd like once
again to underline the testing-squad is not the Spanish Inquisiton nor do we
adhere to a dogma which makes testing procedures unchangeable (and we
certainly don't want to create/impose them without a general consent). Many of
the problems brought up have been met before, are already known and have
been/are being worked on to make Extras-testing as painless as possible (and
yes, I also personally have several packages in Extras-testing that make me
curse at some of the current rules, so I know both sides of this occasionally
painful story :). I invite everyone who has not alredy done so to take a good
look at



http://wiki.maemo.org/Extras-testing/QA_Checklist/QA_Improvements


From what I see, the problem is mostly that there is not enough 
voters.. Well, there are probably lots of more people who add 
extras-testing and even extras-devel to their devices and test random 
applications from there, but can't bother to vote the maemo.org website. 
I can see several reasons for this.


1) extras-testing voting is well hidden in maze of the website
2) Once you find the place, you get an ugly list (especially if viewed 
with n900):

http://maemo.org/packages/repository/qa/fremantle_extras-testing/
There is no correlation with packages you have actually installed on 
your n900, so you need to browse around to actually find what to vote for.

3) the website kicks you out randomly

etc. no wonder we don't get many testers..

If we want to insist on quality on 3rd party applications, we should 
start by having good UX design and QA on the maemo.org website too...


But I think perhaps the website is the wrong place anyway. a 
"extras-testing-assistant" application in extras that allows you to 
add/remove
extras-testing to application manager, shows a list of packages 
installed from extras-testing and gives you a chance to thumb up/down.


Oh, And I also suggest cutting down the requirement for _upgrades_. For 
upgrade, the test checklist should be:


[ ] No regressions observed (everything that worked on previous version 
still works)

[ ] New functionality/bugfixes work as advertised

And cut down the delay to 5 days with 5 votes.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Is mauku open source, i.e free or is in non-free?

[Riku Voipio]

On 01/27/2010 05:04 PM, ext Dave Neary wrote:

Hi,

Riku Voipio wrote:

Well, such misunderstandings are likely to be caused by the poor extras
instructions. Which exact page should Henrik read to get enlightened?


David King&  I are working on improving these. Having not gone through
the process myself, I need help. Your questions are great, because they
help me identify the questions I need to ask&  get answered.


As someone who went through the whole undocumented experience of getting 
a package to extras, I can help in any questions.



For the current best information on uploading to extras, there are:

http://wiki.maemo.org/Uploading_to_extras and


This document is generally ok, but the link to next step, extras-testing
leaves developers lost.

http://wiki.maemo.org/Extras-testing

Which is, in fact, a document for endusers and testers, not developers. 
At this point the, developer faces a bunch of questions;


1) where did my package go after dput
2) what exactly do I need to "promote" the package
3) how can I follow the whole process

Eventually I found the

http://maemo.org/packages/view/package/

link, and figured out that one needs to click on latest armel version 
while being logged in, to see the "promote" link.


(Why are x86 packages shown in the first place here?)

After you have got this far, you get your first tester that tells you 
that you need to have bugtracker. Ofcourse, this was not documented on
any of the previous steps, and conviniently not mentioned at 
extras-testing wikipage either. Google to help. Apparently one needs
a XSBC-Bugtracker: field in debian/control and request a bugzilla 
section at bugs.maemo.org.


Next, once one has managed to get the 10 votes, one is left wondering 
what happens. Apparently one will get a mail about "promotion unlocked"

when you can finally push it to extras.

Now people are asking me to add a "screenshot". But I couldn't find out
where or howto do that. Turns out the promoting to extras creates a:

http://maemo.org/downloads/product/Maemo5/package/

page. But even after loggin in, there is no explanation howto add a 
screenshot...


What is worrying, that this was a major struggle for me. And I
actually know a lot about debian and maemo, how much more lost
someone who just arrived to maemo would be?


http://wiki.maemo.org/Extras right now.


This is clearly a enduser doc.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Is mauku open source, i.e free or is in non-free?

[Riku Voipio]

On 01/27/2010 09:54 AM, ext Ryan Abel wrote:

On Jan 27, 2010, at 2:28 AM, Henrik Hedberg wrote:



   Thanks, I know. But as I said, "[t]here have not been any discussion, 
announcements or instructions how to really handle QA in the non-free section." 
Thus, the non-free section in Extras does not officially exists. There is only procedures 
how to upload it into extras-devel.



Er, yeah, as far as I'm aware the process is very nearly the same. . . . I'm 
inclined to believe that you should probably seek to enlighten your opinions 
with more fact before spreading them around.


Well, such misunderstandings are likely to be caused by the poor extras 
instructions. Which exact page should Henrik read to get enlightened?


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: mafw-lasftm: installed, configured, restarted the device, but plugin is not started

[Riku Voipio]

ext Claudio Saavedra wrote:
> El mar, 08-12-2009 a las 17:50 +, Graham Cobb escribió:
>> On Tuesday 08 December 2009 17:23:15 Claudio Saavedra wrote:
>>> I noticed that the postinst script was missing the debhelper token used
>>> by dh_installxsession to plug its magic. Now the Xsession script should
>>> be installed properly.
>> What is dh_installxsession?  I can't find any documentation on it.  Probably 
>> looking in the wrong place!

> It's part of upstart-dev. I don't know where it's documented, though. I
> simply looked at hildon-desktop and some other modules' packages.

It is not really necessary/recommended to use it anymore. One can just
copy the startup script into /etc/X11/Xession.post like one would do to
any file in /etc. Same is true to dh_installupstart.

But why does mafw-lastfm need to start at boot time and keep running all
the time? Is it not possible to make it start/stop when playback
stops/starts?

Still, looking forward to seeing mafw-lastfm in extras-testing =)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Can't debug an application under FREMANTLE_ARMEL target in Scratchbox

[Riku Voipio]

ext Burka Victor wrote:
> [sbox-FREMANTLE_ARMEL: ~/Projects/simple] > gdb simple
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu 
> --target=arm-none-linux-gnueabi"...
> (gdb) break main.cpp:6
> Breakpoint 1 at 0x885c: file main.cpp, line 6.
> (gdb) run
> Starting program: /home/victor/Projects/simple/simple
> Don't know how to run.  Try "help target".
> (gdb)

cross-gdb doesn't know howto run code. It is basically a tool to look at
coredumps.

> 
> 3.2.
> 
> [sbox-FREMANTLE_ARMEL: ~/Projects/simple] > native-gdb simple
> GNU gdb (GDB) 6.8.50.20090417-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi".
> For bug reporting instructions, please see:
> ...
> (gdb) break main.cpp:6
> Breakpoint 1 at 0x885c: file main.cpp, line 6.
> (gdb) run
> Starting program: /home/victor/Projects/simple/simple
> qemu: Unsupported syscall: 26

qemu doesn't support ptrace syscall. gdb is basicly a glorified ptrace
wrapper. adding ptrace support to qemu would require quite a bit of
work.

> If anybody knows how to solve that problem, I would appreciate that.

Apart from from implementing ptrace in qemu, there little once can do
(currently). The closest one can do is abort(); at some point and the
use gdb to examine the coredump.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA process = bug fixing disincentive?

[Riku Voipio]

ext Henrik Hedberg wrote:
> Tim Teulings wrote:
>
>   
>>> Except how do you try to prevent abuse (whether intentional or
>>> accidental)? At least with the version number you've got some safety
>>> check (although it is in no way comprehensive). It also requires more
>>> changes at more levels (I bet), so harder to implement.
>>>   
>> I think it is time to decide (again?) if we trust developers in their
>> atempt to get their software/package into extras or not. 
>> 
>
> Currently, we trust ten random testers rather than one well-known 
> developer.
>
> Why could not we trust well-known developers who have track record 
> of producing high-enough quality software? They may have their own 
> methods for testing, like couple of active and skilful dedicated testers 
> for the application domain. I see that more trustful than those random 
> testers who vote subjectively based on their opinions of an user interface.

Every company has software testers, yet it doesn't mean they dont trust
their developers :) But even highly skilled, well-known developers are
just humans and make mistakes every now and then. Therefor, testing and
QA process is needed.

The problem with "just trust the developer" and "skillful dedicated
testers" is exactly that they become rapidly used to their own UI
mistakes and stop caring about them. 10 random users is a bit extreme,
but in principle it is a very good idea. If random extras-testing users
don't like the Use Experience, chances are very high that actual
"extras" endusers don't like it either! Certainly there are cases where
testers will thumb down unfairly, but if we have enough testers it
doesn't matter.

QA process is always going to somewhat painful. Still, the pain needs to
minimized and the QA process must be presented in a way that developers
can see the advantages of it rather than consider it as arbitrary
hurdle. Currently it appears the package promotion website is simply too
crude for both developers and testers. At the minimum we need a better
communication channel between developers and testers so that any
misunderstandings can be cleared directly without resorting to ranting
here :)

> Sounds familiar? See Debian New Maintainers Process [1].


Being a longterm Debian Developer, and a for a while a Application
Manager for the New Maintainer process, I think applying such model for
maemo extras would be a very bad idea.

1. It is a massive hurdle of contribution, discouraging people from
joining (I don't see you in debian or NM although you create Debian
packages;)
2. "Accredited" Debian Developers still upload crap all the time
3. It leads to complex workarounds such as sponsoring uploads for others

(In fact I hope we can some day dismantle NM it in Debian as well, and
move to a model where more people can upload directly, but _all_ uploads
are reviewed before accepting them in.)

ps. I also agree that guessing from version number is bad.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA process = bug fixing disincentive?

[Riku Voipio]

ext Jeremiah Foster wrote:
> On Nov 1, 2009, at 11:02, Henrik Hedberg wrote:
>
>   
>> Martin Grimme wrote:
>>
>> 
>>> resetting Karma on a new version leads to one very bad issue, IMHO:
>>>
>>> Developers of packages with some Karma will hold back bugfix-updates
>>> until the unfixed version has reached extras.
>>>   
>
> This is a real problem that will have to be addressed.

What need is a way to split bugfix changes and new major versions.

1) We must encourage developers to provide bug fixes often and be able
to deliver them quickly to endusers
2) New major versions still need QA testing - against regressions. Even
more than bugs endusers hate when things that used to work stopped working.

Now, I think it is impossible to automatically detect if a upload is
bugfix or "major" upgrade. Thus, we have to trust the developer to set
the major-/bugfix upgrade flag correctly somehere ( debian/changelog, a
menu item in the package promotion ui or whatever ).
The question then comes, can we trust the developers to do the right
thing and not abuse the "minor upgrade" to shove in any package with
shorter quarentee and less votes?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo on Beagle (alpha): error processing base-passwd

[Riku Voipio]

ext Dirk Behme wrote:
> After having now configured the correct sources.list (thanks Juha!), 
> after some time
>
>  > fakeroot ./make_rootfs.sh
>
> stops now with
>
> -- cut --
> ...
> Selecting previously deselected package mini-rc.
> Unpacking mini-rc (from .../mini-rc_0.2.40_all.deb) ...
> Setting up base-passwd (3.5.11.osso4) ...
> mmap: Permission denied
>   
I take it that /proc is not mounted inside your scratchbox? are you 
running scratchbox in a chroot or some other container?
in that case:

/etc/init.d/scratchbox-core stop
# command to mount /proc inside your chroot
/etc/init.d/scratchbox-core start
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: sem_post: Function not implemented

[Riku Voipio]

ext Kenneth Loafman wrote:
> I keep getting this error with the DIABLO_ARMEL target and it makes
> testing difficult.  Hundreds of these interspersed with unit test logs
> makes for hard-to-read results.
>   
First, scratchbox (and qemu linux-user) is not really representative of 
the real target hardware environment, and thus running the unit tests in 
it may not be very useful.
> I found the following link for Chinook... will it work for Diablo?
> http://maemogeek.blogspot.com/2007/11/installing-qemu-arm-eabi-patch-into.html
>
>   
That qemu is quite old. You might want to pick up scratchbox-devkit-qemu 
and configure your DIABLO_ARMEL target to use 
/scratchbox/devkits/qemu/bin/qemu-arm-sb cpu transparency method.

scratchbox-devkit-qemu is available from normal scratchbox repositories and:

https://garage.maemo.org/frs/?group_id=877&release_id=2619



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: qemu 0.10

[Riku Voipio]

ext Cornelius Hald wrote:
> - "Riku Voipio"  wrote:
>   
>> We have now qemu 0.10 based packages for scratchbox1 and scratchbox2:
>>
>> https://garage.maemo.org/frs/?group_id=877&release_id=2506
>>
>> These packages are still very much experimental, eventually the 
>> sb2-qemu-arm packages will replace the current qemu packages that come
>>
>> maemo-sdk (the scratchbox2-based build environment).
>> 
>
> I tried the new package for sb1 and it works for me. However, not better then 
> my self-hacked version... I was hoping to be able to run Mono inside the ARM 
> target, but that is still not possible. It look like at least the syscall 242 
> is still unsupported.
>   
242 is sched_getaffinity(), it's not supported on qemu, but on the other 
hand missing it shouldn't cause a application to crash.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: qemu 0.10

[Riku Voipio]

Hi,

ext Cornelius Hald wrote:
> I just saw that a new version of qemu was released. Did anyone try to use 
> this with scratchbox? If I understand it correctly it should improve the 
> compatibility with the tablets. Is it worth a try?
>
>   
We have now qemu 0.10 based packages for scratchbox1 and scratchbox2:

https://garage.maemo.org/frs/?group_id=877&release_id=2506

These packages are still very much experimental, eventually the 
sb2-qemu-arm packages will replace the current qemu packages that come 
maemo-sdk (the scratchbox2-based build environment).




___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: [LWN] Embedded Linux and the community

[Riku Voipio]

Eero Tamminen wrote:
> Hi,
>
> ext Dave Neary wrote:
>   
>> Andrew Flegg wrote:
>> 
>>> It then goes on to explain "Woodhouse couldn't even find the kernel
>>> source for Maemo".
>>>   
>
> If you look at the LWN kernel page article "Most active 2.6.27
> employers" table "changed lines" side, Nokia is at least for that
> kernel version listed higher than for example Novell or Intel.
>
> I.e. you got it a bit wrong, Nokia works with the upstream community
> so that less Maemo specific changes are needed.

But in this talk David is not interested in what nokia is or is
not doing. He is interested in what the communities are (not)
doing.

An example of a great embedded Linux _community_ is the nslu-2 Linux
port. They took a crappy vendor kernel port, rewrote drivers to
match mainline expectations and got eventually everything into the
mainline kernel and multiple distributions.

An example in maemo's case, some of the 770, N800 and N810
drivers never ended up in the mainline kernel. Nobody in the
maemo (or linux-omap) community adopted the left behind
drivers and submitted them for inclusion.

Woodhouse summed up his talk with a simple statement:

"We need to work better as a community before we can point fingers at
companies who don't play nicely".
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Modest/TinyMail problems (continue from the blog comments)

[Riku Voipio]

Philip Van Hoof wrote:
> About the threading we have discussed this on this mailing list, so you
> can read in this discussion-thread the possibilities and POV being
> taken. One of the conclusions is that a fully threaded view wastes too
> much screen space. Most people just need grouping "discussions", so that
> is one possibility indeed. 
Like gmail does? :) Gmail seems to use screen estate very well.

1) the splitted-pane (or even triple-pane!)approach of tradional email 
clients
vs gmails list of discussion and per-discussion view
2) gmail only shows  the latest 50 messsage, no need to fit all
messages to the same list/treeview.
3) discussions waste less screen space than threaded views.
Also, all the quoting of previous messages is folded away by default.
discussions are a great way to read mails in todays top-posting culture...
4) If you have more than a few screenfulls of mails, you probably want 
to use
freetext search anyway.


Admittedly gmail approach might be tricky offline usage. With server
side support, it should be work well with slow network links. I still think
it serves as a better UI to aspire to than thunderbird/outlook style ui.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Curious: Maemo devices other than Nokia?

[Riku Voipio]

>>> Is it?  The framework, yes, but I think the actual virtual keyboard and
>>> handwriting recognition plugins are closed.
>>>   
>>> 
>>>   
>> The input framework is OSS and it includes a example VKB. I
>> believe the example VKB is different from what is included
>> in ITOS.
>>   
>> 
> Has anyone had any problem ever with the example VKB?
>
>   
In my testing it has worked fine.  My intention was to say
to Marius that the "actual virtual keyboard" included in ITOS
is still closed, but hildon-input includes a functional
VKB nevertheless.

>>
>> The layering violation is including a function
>> hildon_gtk_im_context_show() inside *gtk-2-0*. And the call for
>>   
>> 
> What's the problem? Why we could not have our own custom functionality
> in our Gtk+ tree?
>
>   

It breaks API and ABI compatibility, and makes it very probable
that future ITOS editions are not binary compatible with applications
compiled with current version. It becomes a maintenance headache
for Nokia when you cannot upgrade to new versions of gtk+2.0 before
extracting all the modifications from the old versions.

If adding hildon_* functions to gtk is not a problem, why bother creating
a libhildon in first place?

Custom functionality in gtk is evil. Adding functionality to gtk that
have been coordinated with upstream to be added in future versions of
gtk is good.




___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Curious: Maemo devices other than Nokia?

[Riku Voipio]

Marius Gedminas wrote:
> On Tue, Jan 22, 2008 at 06:42:00PM +0200, Riku Voipio wrote:
>   
>> 
>> Firstly, one needs a VKB. now hildon-input is mostly open source,
>> 
>
> Is it?  The framework, yes, but I think the actual virtual keyboard and
> handwriting recognition plugins are closed.
>   
The input framework is OSS and it includes a example VKB. I
believe the example VKB is different from what is included
in ITOS.
>   
>> but when you have a real distribution, it's a lot more annoying that
>> only gtk2 applications have input. Acceptable, at least we have osso-xterm -
>> Oops no, xterm uses hildon_gtk_im_context_show() to show the vkb,
>> which is only available in maemo version of *gtk+2.0* - what a lovely
>> layering violation.
>> 
>
> What layering violation?  osso-xterm is entirely based on gnome-terminal
> (libvte, actually).  The name is a bit misleading -- it's not related to
> the real xterm, it just performs the same function.
>   
The layering violation is including a function
hildon_gtk_im_context_show() inside *gtk-2-0*. And the call for
that is in osso-xterm because vte doesn't appear as a normal
gtk input field, and thus osso-xterm needs to summon the input
method itself.
>> But it just a matter of sorting all pieces together
>> to get fully OSS rootfs built out of Debian to support the basic use cases
>> of internet browsing, email and so on.
>> 
>
> But not fast battery charging.  IIRC.
>   
I don't think that is part of the rootfs.


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Curious: Maemo devices other than Nokia?

[Riku Voipio]

Mikhail Sobolev wrote:
> Exactly, Ross! I usually visualize relationship between different bits
> using the following picture (please use a fixed width font):
>
>   +--++--+
>   |  | Maemo SDK  |  |
>   +--+++--+--+
>   |API   |Open|Open| Open |Closed|
>   +--+++--+--+
>   |Implementation|Open|Open|Closed|Closed|
>   +--+++--+--+
>   |   |  IT OS 200X  |
>   +---+--+
>
> The part that is covered by "Maemo" (and Maemo SDK) is not enough to
> produce a somewhat reasonable system, which:
>  1) is bootable
>  2) has support for all hardware
>  3) has a comparable to IT OS 2008 set of applications
>
> The really "challenging" areas are 2) and 3).  I believe certain work to
> make sure that 1) does not have any challenges is planned, but probably
> it's up to Quim to confirm. :)
>   
This what Debian pkg-maemo[1] and armel[2] projects intend to do.
Progress is slow but firm, now with hildon-desktop recently uploaded to
Debian and armel port in good condition (although still unofficial..). And
indeed it's the applications and  UI that are the main problem.


Firstly, one needs a VKB. now hildon-input is mostly open source,
but when you have a real distribution, it's a lot more annoying that
only gtk2 applications have input. Acceptable, at least we have osso-xterm -
Oops no, xterm uses hildon_gtk_im_context_show() to show the vkb,
which is only available in maemo version of *gtk+2.0* - what a lovely
layering violation. So matchbox-keyboard is currently used, which
perhaps isn't as pretty as hildon-im, but atleast it works everywhere.
Another common grief in compiling hildon apps with stock gtk is the
infamous tap-and-hold menu, which apparently is going to be adapted
in upstream gtk in a completely different way.


So now there is a hildon-desktop, terminal, network-manager and a vkb.
Only such minor details as web browser is missing, and the themes/icons
having a funny license.  But it just a matter of sorting all pieces 
together
to get fully OSS rootfs built out of Debian to support the basic use cases
of internet browsing, email and so on. Once we are the (might take a while
since I'm busy ATM), it should be easily adaptable to other portable
devices. Hopefully it will also motivate people to work on OSS replacements
for the rest of the stuff, IE the initfs and wifi driver. I don't hold 
much hope for
the DSP thou, as long as TI holds it as a proprietary architecture with
a proprietary toolchain and bios.. I prefer forgetting the dsp exists and
just using the audio codec directly with alsa.

[1] http://wiki.debian.org/pkg-maemo
[2] http://wiki.debian.org/ArmEabiTodo
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Pascal on armel Was: [Re: About the upcoming maemo user karma]

[Riku Voipio]

Igor Stoppa wrote:
> Hi,
> On Tue, 2007-11-06 at 12:56 +0100, ext Luca Olivetti wrote:
>   
>> En/na vicente garcia ha escrit:
>> 
> Finally after 4 hours of fiddeling I want the old days with my old
> TurboPascal back. ;-)
>   
>>> Are you crazy? I must develop some applications with pascal + mysql +
>>> gtk 2 then I felt in the Hell. I hate pascal but I learn so many gtk
>>> tricks :)
>>>   
>> It's not my intention to start a language flame war >:-) but
>> evidently you never heard of delphi and lazarus. It's sad that the 
>> "pascal" word is automatically associated to a clumsy, outdated language 
>> by most developers, since, while lazarus is not 100% mature, being 
>> modelled after delphi it blows away anything else for database and gui 
>> development (at least under linux, where there's no other comparable 
>> product).
>> In fact, having started (real time) pascal development a long time ago, 
>> followed through to delphi and now using freepascal and lazarus when I 
>> can, I find the various C/C++/Java/whatever development environments 
>> really primitive (unsurprisingly, since they're only now trying to do 
>> what borland already did almost 15 years ago).
>> 
>
> ok, so maybe you can help me: I'm trying to get the NBC compiler 
>
> http://bricxcc.sourceforge.net/nbc/
>
> working on the tablet.
>
> Currently i'm stuck with having source code for Delphi/FreePascal and
> not being able to compile it since (to the best of my knowledge)
> FreePascal only supports ABI, not EABI.
>
> GPC would be a much better alternative since it basically can generate
> executables for whatever is supported by the backend of gcc.
>
> So, is this attempt reasonable? Do you use gpc on the tablet?
>   
gpc-4.1 is available[1] in debian/armel repo. However, according to the
testsuite results in build log[2] working might be spotty...

=== gpc Summary ===

# of tests5111
# of expected passes  1697
# of unexpected failures  3411
# of unsupported tests3



[1] http://ftp.gnuab.org/debian/pool-armel/main/g/gpc-4.1/
[2] 
http://experimental.debian.net/fetch.php?&pkg=gpc-4.1&ver=2.1-4.1.2-17&arch=armel&stamp=1192946588&file=log&as=raw
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo localization to officially non-supported languages

[Riku Voipio]

Mohammed Hassan wrote:
>> It would be interesting to take our current translations and mine them
>> for the logical ids that map to the same Engineering English, but at
>> the same time have different translations in some language.  These are
>> the cases where we would need to use the "menu|Open" construct in the
>> code instead of the existing Engineering English string.  Identifying
>> and handling these cases is where I see a large part of the effort
>> needed to move away from logical ids, so it would be good to get an
>> overview.
>> 
>
> Multiple logical IDs with the same Engineering English string are needed
> because the translation might change according to the context.
>
>   

Actually, gettext already has tools to handle same text in different context
without using logical id:s

http://www.gnu.org/software/gettext/manual/gettext.html#Contexts


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: sbox2 & maemo

[Riku Voipio]

Marius Vollmer wrote:
> There are two kinds of borders: one kind isolates OSs from each other;
> this could be done with some virtualization tool like xen, uml, or
> maybe chroot.  The other kind isolates different architectures within
> the same distribution; this is what SB2 does.
>   
There has been some thinking about this dilemma, and we have
pretty much decided that we will not implement anything that does
the first kind of isolation in sb2. A separate tool can be created for
that purpose.

Lets try to keep sb simple this time :)

> In order for me to use SB2 and still retain control over my host OS, I
> would have to install the OS that SB2 wants as its host inside a
> virtual machine.  That's not a problem, of course.  I think I found my
> weekend project...
>   
That is not that different than what Debian/Ubuntu developers
already do. Their host OS is whatever it is (etch/testing/sid
or dapper/gutsy or whatever), with whatever crap and extra
hacks installed. When building packages to distro, a clean
chroot of target distro or pbuilder is used.
> So, in the end, I think it's actually all quite simple: we make a OS
> that runs on real x86 hardware, inside Xen on x86 and on a Internet
> Tablet arm device and can be used both as a development environment as
> well as the basis for IT OS.  That OS includes sb2 which is used to
> 'cross-compile' software from i386 to armel.
>   
The *main* point here needs to be that all development tools
inside the X86 development system need to unmodified packages
from some mainstream distro. Else we end up maintaining a
similar soup of patched and hacked packages that nobody
dares to upgrade.



___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: sbox2 & maemo

[Riku Voipio]

Koen Kooi wrote:
> The big problem is that hildon depends on an old, forked version of gtk+ that 
> nobody in
> their right mind wants on their x86 systems. The nokia people at guadec were 
> unable to
> give me an ETA on when that will be fixed :(
>
>   
Guadec of what year? :P

http://packages.ubuntu.com/gutsy/x11/hildon-desktop

looks like a recent enough non-forked gtk to me...[1]
>> One day we will anyway be
>> running debian/stable with a few custom components on the tablets.
>> 
>
> You mean switching back to OABI?
>
>   
unofficial[2] Debian EABI port is pretty much ready for what
tablet's would need from it. D-I, java (argh, but being worked on)
and FORTRAN (Argh!!) are the main incomplete things, but they
do not really touch tablet usage.

What _is_ missing for tablet usage is free UI's for selected things
(input, wifi/bluetooth network connectivity etc), which I expect
the Ubuntu mobile people already be working on.

[1] Well it's still patched but the patches are included in mainstream
distros' gtk and being integrated upstream.
[2] http://lists.debian.org/debian-arm/2007/07/msg00076.html

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Java acceleration/Jazelle

[Riku Voipio]

Simon Pickering wrote:
>>   The second thought is learn the ABI convention for calling C methods
>> from assembly and you can pass whatever data you need to a function
>> that will do the printing for you.  I'd suggest going with this route
>> since it will be the most straightforward without soldering but also
>> the least versatile.  --You may end up rebooting many, many times and
>> the less overhead there is to initialize before playing around the
>> faster you can try a new idea.  At any rate, I believe the ABI changed
>> when we went to the armel format and so there's a handy description on
>> changes to system calls and so forth here:
>> http://wiki.debian.org/ArmEabiPort  Sorry if I'm pointing out anything
>> that might be obvious, these are just things I had to work through
>> when I was working on this type of thing on OS-less boards.
>> 
>
> Thanks for that pointer, I'd forgotten about that page. It does say how
> registers are passed (but I think it says to system calls rather than some
> random function). I'll have to look at it again and do some more digging (and 
> in
> the meantime save the value of R14 to an array each time the handler code is
> called, then print it out in C after the asm has completed). 
>   
That part is talking about normal function calls. So you have 4 
registers to pass arguments,
rest is passed in stack.

> Does anyone know whether there are there any good docs/books on ARM asm
> programming, telling people these sort of things? This is an interesting (and
> hopefully useful) learning experience, but can be really frustrating when I 
> know
> what I want to do, and pretty much how to, but not quite! :) E.g. calling
> functions in linked libraries, how to call .s file functions from C, what is 
> and
> isn't allowed in in-line asm, etc.
>   
I don't think there is really such a book, but you can use gcc -S to see 
what kind of assembler
gcc generates to call functions. Otoh it sounds what want to know is 
already in jalimo jamvm
in src/os/linux/arm/callNative.S =)

Since the virtual machine is not only running the bytecode, taking jamvm 
(or something else)
as the base could make sense.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: New release of Python2.5 for Maemo (r0.4-11)

[Riku Voipio]

Quim Gil wrote:
> Hi Riku,
>
> On Thu, 2007-06-28 at 16:53 +0300, ext Riku Voipio wrote:
>   
>> Why would that need python support *in* the platform?
>> 
>
> Let me explain why full Python support in the maemo roadmap has little
> to do with (improvable) install files or repositories. In fact it's all
> about official commitment.
>   
(snipped rest)

Thanks, this was very insightfull.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: New release of Python2.5 for Maemo (r0.4-11)

[Riku Voipio]

MoRpHeUz wrote:
>   If with "in" you mean being distributed by default with the
> platform, why should not as the number of applications requiring it
> are increasing and it should be easier for a regular user to install
> these applications without the need of installing "by hand" python as
> well ?
>   
What I'm trying to say is that we have dependencies and apt - why would 
python
need to be installed by default in the platform when it can get 
automatically
installed when user installs first application that is written in python?

I agree that python is nice, but after one adds python to platform, 
someone will ask
for ruby, java, mono, gfortran, cobol, php5, ocaml, erlang, lisp, emacs, 
pike, tcl, yforth,
basic, brainf*ck, and so on.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: New release of Python2.5 for Maemo (r0.4-11)

[Riku Voipio]

MoRpHeUz wrote:
>   Great applications like Carman, Konttouri's player and others were
> written in python. And the final users wont have this applications
> working well if we dont have python support for the platform.
>   
Why would that need python support *in* the platform? It should jsut be 
a matter
of putting ukmp and pymaemo in maemo extras and having a proper install file
for ukmp.

I see it's not true for now.

1) pymaemo needs clicks on two install files "base repo" and "pymaemo" why?
2) ukmp does not have a install file, but a .deb. according to 
maintainer uploading
to extras is "too hard"

^ those are the issues that need fixing, not adding arbitrary bloat[1] 
to the base system.
Which basically  foils down either limits in .install files and/or 
problems with using
garage. Next time someone is going to write a neat ruby application, it 
needs to be easily
installable as well, and you can't solve all dependency problems by 
adding everything
to official(tm) firmware.

[1] I do not mean python specifically, which I actually like.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Toolchain upgrade? (Was: Instructions cache flush on ARM)

[Riku Voipio]

Siarhei Siamashka wrote:

Hm.  The toolchain might not be built with -pg support.
As to using gprof, that produces fairly unreliable results.
I'd recommend building Oprofile kernel and latest oprofile
user-space tools.



Maybe Oprofile is good, but  gprof is better than nothing and does not require
recompiling kernel.

  

OTOH you don't need to recompile apps with -pg to profile with oprofile.
One needs to "just" recompile the kernel once.

Well, I'm worried not about how to workaround ICE but about the overall
quality of the compiler. I wonder how many compiler related bugs are lurking
in maemo software but are not caught yet? 
  

Me too..

Did anybody try installing newer toolchains in scratchbox and use them with
maemo SDK? I just don't have much free time for these experiments and 
don't want to break my installation of scratchbox which works now (more or

less acceptable)
  
No reason why it shouldn't work, one just needs to be sure the 
glibc/libstd++

built is matching enough. I tried the newer codesourcery toolchain (based
on gcc 4.1, and it mostly worked, except for apps using certain depreciated
syscalls. (i've forgotten already which ones).

http://www.scratchbox.org/wiki/ForeignToolchains


Enabling unaligned memory support will make life much easier for developers
unfamiliar with ARM platform. The number of applications for N800 should 
grow up, as less newbee developers will be turned away frustrated by the

alignment bugs they have never heared about before.
  
Alignment issues exist for other risc processors as well (hppa, alpha, 
ia64),

so most Linux programs to be ported to n800 should already be fixed.  Also,
who says all maemo products will be arm11 based? arm9 isn't going to
disappear overnight, especially it seems xscales will continue to evolve as
arm9-based.

This is of course just objecting for the sake of it:) I don't have
anything against enabling unaligned memory support, so tested patches
would be appreciated ;)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: getty over serial is running

[Riku Voipio]

František Dufka wrote:

Mystery solved. There is clear bug in the script. While the comment above dd 
talks about reading it writes to /dev/ttyS0 creating 1 byte regular file in 
/dev.

#test if we can read ttyS0, we have serial console
if dd of=/dev/ttyS0 count=1 bs=1 if=/dev/zero ; then

So everybody should have getty running in latest FW.
Or did I change the script while sleeping?

  
This script is unmodified from older releases. What has changed is that 
kernel
has been fixed not to create ttyS0 if serial port is not enabled. The 
check should now be


if [ -c /dev/ttyS0 ] ; then

to have the intended effect.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Moving windows in Maemo

[Riku Voipio]

Mika Yrjölä wrote:

For me, the main benefit for being able to move the dialogs around at
will would be the ability to position the dialog so that no
information relevant for deciding how to react to the dialog is hidden
below it. While the current default of the dialog changing to display
just a wireframe of its geometry of course allows user to see what's
below, it's not possible to interact with the dialog while looking at
the information and vice versa. 
The UI should not use a dialog if it ends up hiding relevant information 
below

it... IMNHO current UI overuses dialogs. Just count how many popup dialogs
you need to get a http proxy set for a new wlan connection...
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers

Re: sb2 wishlist

[Riku Voipio]

Lauri Leukkunen wrote:

- documentation, primarily man pages

I have some basic man pages since lintian wants them ;) I'll complete
them tonight. I might end up rewrite^Wclean sb2 shell script while at it ;)

Emulation mode testing can be more of a
challenge as there it would need to be decided what is actually wanted
from it in the first place.

It might be worth doing all target managment (apt/dpkg/debootstrap work) in
emulation mode, atleast in the beginning, and just operate the actual 
builds

( dpkg-buildpackage && ./configure && make && etc) in emulation.
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] 'Locking down' software installation

[Riku Voipio]

Marius Vollmer wrote:


The locked-down upgrade path could support more than one set of
trusted sources down to the granularity of repositories.  This would
allow other parties than Nokia to make use of this feature.  That's
just a smop and might be done.
  

I think this the best approach. It would also be useful outside
maemo, aka at debian and at ubuntu. So it would be nice
if it can be implement at the lower levels, ie apt/dpkg.

One way of implementing this is:

1) When installing package store the origin (available from the Relese 
file of

repository) of the package into package /var/lib/dpkg/status.

2) When upgrading, refuse upgrading that package from other origins. Provide
a --force-override origin for power users.

First is easy to implement, second is hard :)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Problem using dpkg-buildpackage under Maemo-2.1 /Scratchbox apophis

[Riku Voipio]

[EMAIL PROTECTED] wrote:


 

[sbox-HOST: ~/maemopad_graeme] > dpkg-buildpackage -rfakeroot -uc -us 
-sa -D


 


which gives me the error

 


unable to get login information for username "wrap"

at /scratchbox/devkits/debian-sarge/lib/dpkg/controllib.pl line 59. 
Compilation failed in require


at /scratchbox/devkits/debian-sarge/bin/dpkg-parsechangelog line 15.


*snip*


 


Can anyone tell what is going wrong here ?

 

Someone isn't following the instructions and is using debian-sarge 
devkit. recreate the target
with the devkit selection given in installation instructions or use the 
install script to do it automatically

for you.


This electronic message contains information from British 
Telecommunications plc which may be privileged or confidential. The 
information is intended to be for the use of the individual(s) or 
entity named above. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of 
this information is prohibited. If you have received this electronic 
message in error, please notify us by telephone or email (to the 
numbers or address above) immediately.


Activity and use of the British Telecommunications plc email system is 
monitored to secure its effective operation and for other lawful 
business purposes. Communications using this system will also be 
monitored and may be recorded to secure effective operation and for 
other lawful business purposes.


 


You scare me.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] armel-debs.applieddata

[Riku Voipio]

Zoran Kolic wrote:

Howdy!
Any experience with "armel-debs.applieddata.net/debian/pool/main" ?
Would be nice to use some precompiled binaries without bricking
the device.

 

debian/armel a newer glibc (2.5) and gcc (4.1) than maemo. While
in mostly compatible, there is a problem with syscall(), as
existing applications in maemo give the argument to syscall() using
oldabi numbering, and the glibc expects EABI numbering.

Another issue that several of the packages in maemo are forked (gtk..),
and upgrading or accidentally pulling those packages from debian
would likely break existing applications.

But there is plans to make stuff compatible eventually.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] [maemo-announce] maemo 2.2 'gregale' is released

[Riku Voipio]

Aaron Levinson wrote:
Yep, I'm aware of this option, but I'd rather keep 2.0 on my system and 
have two scratchbox installations than implement this kludge.  I would 
have to maintain separate control files if I went with this option, one 
for 2.x and one for 3.0.


  

Executive summary:

Just use the maemo 2.2/maemo 3.0 scratchbox install instructions, but
instead of installing maemo 2.2/3.0 rootstrap, just install the 2.0 
rootstrap.

absolutely no reason whatsoever to keep the old scratchbox around.

Long version:

You guys need stop thinking dependencies and scratchbox versions are
black magic!!

1) The maemo 2.0 rootstrap should work just fine with latest scratchbox.

Why was the older scratchbox neccesary previously? Because at one point
of time only 0.9.8.8 had right toolchain and patched dpkg to produce armel
.deb files. These features are now also present the lates 1.0 scratchbox.

2) shared library dependencies work just like in debian.

So, the version of library your package depends, is created from the 
.shlibs[1]

file included in the -dev package. Now, since maemo 2.0 -> 2.2 includes only
bugfixes, there should be no new REAL incompatibilities. Which would consist
of adding, removing or modifiyng a exported symbol of the library. So if 
there

is a library package that bumps the version requirement in maemo 2.x, It's
probably a bug[2] and should be reported.

[1] they are in /var/lib/dpkg/info/*.shilbs
[2] most probably the library packaging brainlessly uses "dh_makeshlibs -V"
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo 2.1 and 3.0 SDKs at the same time

[Riku Voipio]

Andrew Barr wrote:

Apologies if this has already been asked...but I was wondering if there
are any issues I should be aware of having both the Maemo 2.1 and 3.0
SDKs installed on a machine (e.g. just running both installer scripts
one after the other).
Just use the sbox 1.0 needed by bora. The scratchbox target 
configuration for
maemo 2.1 and 3.0 is identical, the ONLY difference which rootstrap you 
unpack

to the target.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] OS2006 roadmap

[Riku Voipio]

Dave Neuer wrote:

The prices are almost the same,
Except the price of the other is with a 24 month lock-in contract. We 
don't know
the real unsubsidized price. We don't even know if the other allows you 
to install
your _own_ applications or any other minor details. Apple certainly has 
created

something sleek, but we don't know yet for example how well web pages will
render on it's 320 by 480 display.

Also based on Apple's track record
I think their openness will be much less than Nokia's in regards to this
device. The whole Darwin joke hasn't exactly shown Apple to really give
a shit.


You are missing my point. Apple's platform doesn't have to be open,
because their device will work exactly the way most people want it to
right out of the box. 

Why shouldn't nokia then do like Apple, create a propiertary platform
and make it work exactly like people want it to, right out of the box?

This theme seems to be recurring here. "Nokia isn't open/free enough,
so I'll rather choose a more propiertary PRODUCT". There is far more
than enough information and code to create your own, 100% Free 
rootfilesystem.

The few needed binary blobs (wlan driver and bt firmware) are already in the
initfs. Yet, what people ask, is new new versions of Opera, flash, etc.
Or that the default Nokia PRODUCT does not come with some component
that is possible to install yourself (such as ogg playback ). I'm having a
hard time of buying the argument of "lack of openness", when real issue
appears to be that product isn't as solid as it could be.


Nokia was counting on the community to provide
that level of functionality for them, but won't pay us w/ the only
thing the open-source community cares about: code and documentation of
hardware.

Specifics please? What code/documentation are you missing and what would you
create with them? And how are going to do the same things with iPhone?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Scratchbox 1.x with scirocco/mistral

[Riku Voipio]

Ilpo Stenberg wrote:
I have used scratchbox-1.0.6 (apophis) to compile couple of extra 
kernel modules
(for 2.6.16-2.6.16.rel kernel IST 2006?). I had lot of problems with 
installation -

binary tar balls didn't work, but .deb -packages did, and so on.

Can you please specify any problems you had?


http://syslog.movial.fi/archives/38-Scratchbox-Apophis-R4-released.html

(though sb-conf didn't work, but sb-menu does)
Noticed one error in that page, updated (and use 2.1 rootstraps while at 
it).


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Unresolved issues (Week 44)

[Riku Voipio]

Michael Kostrzewa (Nokia-M/Helsinki) wrote:

On Mon, Nov 06, 2006 at 11:18:16AM +0200, ext Daniel Stone wrote:
  

On Mon, Nov 06, 2006 at 10:22:20AM +0200, ext Tommi Komulainen wrote:


  * http://maemo.org/pipermail/maemo-developers/2006-October/005976.html
Proper version of scratchbox? suse 9.2?

"crazy bugs" after following the tutorial to the letter. 2.6.18

kernel problems?
  

2.6.18 is known to break Scratchbox, given that they decided to randomly
change /proc's behaviour.



BTW, is there any working solution to this problem? (Except from downgrading 
the kernel). 


Scratchbox Apophis is not affected by the 2.6.18 bug. The latest release,
Apophis R4 also fixes the issues with ubuntu edgy and supports armel +
maemo 2.0 toolchains.

http://scratchbox.org/download/scratchbox-apophis/



___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Unresolved issues (Week 41)

[Riku Voipio]

Tommi Komulainen wrote:

  * http://maemo.org/pipermail/maemo-developers/2006-October/005721.html
compiling problems in scrathcbox

gcc fails with 'sbox-i686-linux-gcc: -lgthread-2.0: linker input

file unused because linking not done'

solved (gcc -c -lfoo is not a valid gcc command) on different list:

http://lists.scratchbox.org/pipermail/scratchbox-devel/2006-October/000225.html

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: Maemo and Ubuntu Edgy: Is it safe?

[Riku Voipio]

Ross Burton wrote:

On Wed, 2006-10-18 at 10:47 +0300, Santtu Lakkala wrote:
  

Edgy has changed the default shell (/bin/sh) to dash (from bash), and
the scratchbox pre/postinst scripts don't like it too much. After
changing the shell back to bash everything went smoothly, and sbox is
working just fine.



Has someone reported this to scratchbox so the scripts are updated to
ask for bash instead of sh?

Dafydd Harries already fixed the scripts and they are in Scratchbox
version management now.

In other news, linux 2.6.18 brings more serious breakage due to changing
the semantics of "readlink /proc/$pid/exe" and it hasn't  been fixed yet.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] RE: Nokia 770 sources...

[Riku Voipio]

Michael Wiktowy wrote:


IANAL but it is my understanding that most countries have RFI laws 
that do not allow RF chip manufacturers to allow their users to modify 
their chips to switch to licensed bands or use an amount of power that 
brings it into a licenseable realm. It is not just the case of the law 
saying that a user can't operate in certain realms ... the user can't 
even be allowed to *possibly* operate in certain realms. So if an 
embedded chip is flexible enough, the manufacturers nerf it with a 
binary blob.
If that would be the case, HW vendors should put the transmission power 
restrictions in the hardware. a binary blob doesn't prevent 
modification, it's security via obscurity. And since this blob is often 
just arm instructions, it's not particularly good obfuscation either. 
This is only slightly more effective than actually releasing the C code, 
if the code uses all the HW registers via hex values and other 
undocumented magic numbers, instead of using #define:d values[1] to 
actually describe what the driver does.


More likely manufacturers feel that there is valuable IP in their blobs 
and would prefer not to give it around to everyone for free, especially 
in a highly competitive market like wlan chipsets are.


Riku

[1] It can be argued that such form is actually not the "preferred form 
of modification" required by GPL.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Xserver and Re-flashing error

[Riku Voipio]

Dan Brinks wrote:

Hello-
I've been trying to see if I could modify the X server running on the 
N770. So firstly I extracted the rootfs from the OS2006 .bin file. I 
then downloaded the xserver-kdrive .deb file from the repository and 
extracted it to my rootfs, packaged it all up and flashed my device 
with it. This worked fine. I then downloaded the source of 
xserver-kdrive, also from the repository. After expending some effort, 
I was able to get that to compile. I had to download a couple 
extensions from other places -- xproto, resourceext, damageext, xdmcp, 
compositeext; I also had to add one struct definition in spext.h (from 
the xsp folder in the tar'd xserver-kdrive source). However, it did 
eventually compile. I then replaced the Xomap executable file in the 
rootfs with the new one which I had just compiled and flashed the device.
The canonical way to compile kdrive (or any other component for 770) 
inside scratchbox:


apt-get source xserver-kdrive
fakeroot apt-get build-dep xserver-kdrive [1]
cd xserver-kdrive-version
dpkg-buildpackage -rfakeroot

After this you have a nice .deb you can install with "dpkg -i" on the 
device. Any other way

you might lack some of dependencies and/or have incorrect configure flags.

> Now, when my device boots, there is no longer the blue progress bar 
along the bottom. It merely shows the "Nokia" screen for a second or two 
and then shows the handshaking screen. As such, I can no longer flash my 
device with anything at all. Any thoughts?


Are you following instructions here? 
http://www.maemo.org/maemowiki/HOWTO_FlashLatestNokiaImageWithLinux


[1] Now that I test it "libxproto-composite libxproto-damage 
libxproto-colorkey libxproto-resource libxres-dev libxkbfile-dev 
libxdmcp-dev" packages are missing from maemo.org repository. However 
these are all opensource and available from other

sources (with different names, I think).
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: libfakeroot errors

[Riku Voipio]

On Sunday 26 March 2006 16:15, Neil Jerram wrote:
> >> libfakeroot: connect: Cannot assign requested address

> For the record, I've now managed to avoid these errors by moving my
> maemo work to a higher spec machine.  (Specifically, from a Pentium
> III 800MHz with 128Mb RAM, to a Pentium III 935MHz with 256Mb RAM.)

> Of course, it could be that some other factor in the move was
> relevant, such as the way I installed or used scratchbox (with the
> benefit of more experience), but my guess is that performance was the
> main factor.

You are running out out tcp/ip local port range. Linux kernel will assign a 
static amount of local ports on your system startup, with a quite low default
for systems with little ram (1024 ports minimum afaik). 
use /proc/sys/net/ipv4/ip_local_port_range to set the range. Non-ancienct 
versions of scratchbox have already measures against this issue.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo 1.1 Debian repository updates

[Riku Voipio]

On Thursday 09 February 2006 11:18, Luca Donaggio wrote:
> [sbox-SDK_PC: ~] > apt-get update; fakeroot apt-get dist-upgrade
> Err http://repository.maemo.org maemo1.1/free Packages
>   Temporary failure resolving 'repository.maemo.org'

Inside your scratchbox, is /etc/resolv.conf correct? Ie similar than the one 
outside scratchbox?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: 770 Power Management and power states --- WAS: Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Riku Voipio]

On Wednesday 18 January 2006 15:07, Igor Stoppa wrote:
> The price for it is that we had to fix drivers and applications so that
> they would behave decently, without keeping resources (clocks)
> constantly allocated and without generating unnecessary activity.

The problem is 3rd party developers who are not aware of such situation.
for example, a periodically updating statusbar plugin will eat your battery
away. "STOP DOING STUFF WHEN YOU GET system_inactivity_ind" should
be in big red letters in the first part of api documentation.

> But that is GOOD anyway because it means having better code, better
> algorithms.

With this argument, multitasking of windows 3.11 is better since it forces 
developers to write code so that they give time to others.

> So the 770 can save power even when you have the device in your hand
> with the screen lit and a wireless connection open, as long as it's not
> actually doing something, like rendering a web page.

Which is a *very* good thing, I don't think anyone suggested removing current
dyntick and PM setup, but rather added suspend as well. Many users have grown
accustomed in manual suspending, so perhaps adding no-op "suspend" button
to the powerkey menu would make them happy =) hmm.. maybe just sending
SIGSTOP to all user apps is enough to make them release clocks? 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Using Nokia 770 in vertical mode

[Riku Voipio]

On Wednesday 18 January 2006 10:13, Tapani Pälli wrote:
> It is possible to do rotations even hardware accelerated. However the
> current UI does not scale to it well (as seen from screenshot) and
> therefore it is not a supported feature. nchip is using software xrandr
> but you still need to compile kernel since screen updates don't work
> correctly otherwise ... however using software xrandr you will loose a
> bit in performance (additional copy in memory) and quite much in memory
> (~750kb).

Indeed, it would be preferrable to use HW acceleration, that was only a very 
quick hack. Since the user interface latency is usually not X-related, the 
perfomance loss of additional copy does not make the UI noticably less
unresponsive. 

But ofcourse, this xrandr implementation: 
http://lemody.blogspot.com/2005/11/xrandr-o-2.html Is much more cool :) 
Any chances for a unofficial X binary for hackers with this?-) 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] testing pango with 770

[Riku Voipio]

On Wednesday 21 December 2005 16:47, Kalle Vahlman wrote:
> On 12/21/05, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote:
> > One might think "why don't this guy optimize it?" Answer is simple:
> > it's easier to pango developers to know where to optimize, they know
> > what to optimize and they know the code. So a week or so in feature
> > freeze dedicated to "speeding up" will give more results than me
> > spending a whole semester looking at it.

> And as I pointed out, this has been happening. Wether or not the
> performance improvements apply for the 770 (which has no FP etc) is
> another thing though.

Another issue that hits 770 bad is the lack of RAM and cpu cache. since each 
and every new version these libraries is bigger than the old ones, you are 
simply bound to get more cache misses.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] OT: scratchbox lists (was Re: ELF file OS ABI invalid)

[Riku Voipio]

On Saturday 26 November 2005 22:06, you wrote:
> Riku Voipio <[EMAIL PROTECTED]> writes:
> > This and similar questions belong to the scratchbox mailing lists...

> Even more off topic: would it be possible to get sratchbox mailing
> lists mirrored to gmane.org?

Sure. You can subscribe any mailing lists to gmane at: 

http://gmane.org/subscribe.php

I just subscribed scratchbox-users and scratchbox-devel, they will probably 
get added sometime next week to gmane.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Driver development for Maemo

[Riku Voipio]

On Wednesday 23 November 2005 01:12, Dieter Govaerts wrote:
> 1) As is stands now, I would probably have to implement a virtual
> filesystem on the mobile device which would require me to develop the
> necessary systemdrivers for it. Is there a driver development kit
> available or is this included in the SDK?

You can either create a linux kernel (nothing maemo-specific) or a 
gnome-vfs[1] module (also not maemo-specific), which easier 
and good enough, if you only need the VFS only for your own applications.

Oh, and one easy option is write your own nfs server, and use stock nfs client
on your maemo device. There is already several userland nfs servers, like 
pinefs[2] which is written in python and should be easy to adapt for many 
purposes...

> 2) Is it possible to develop such a driver in a reasonable timeframe? I
> don't want to spend a few years finishing my Master thesis. I'm not
> afraid to dig deep for this, I just want to know if it can be done by 1
> person or if its better to stick with M$ on this.

It is indeed possible to write a (simple) new filesystem in a year. Even a 
kernel driver, but it depends on your skills and learning abilities. FWIW, if 
you really need to write a new filesystem driver, windows is going to be a 
lot *harder*. there is hardly any third party filesystems for windows, while 
people have written support for 40+ filesystems in mainline kernel alone.

> 3) Is there any place or person were I can redirect my questions to
> regarding driver development for Maemo?

google[3] and various other places like LDD book[4]. 

Cheers,
Riku

[1] http://developer.gnome.org/doc/API/gnome-vfs/
[2] http://www.panix.com/~asl2/software/Pinefs/
[3] http://www.google.com/
[4] http://lwn.net/Kernel/LDD3/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] ELF file OS ABI invalid

[Riku Voipio]

On Thursday 17 November 2005 14:58, Timo Steuerwald wrote:
> <-snip-->
> /scratchbox/tools/bin/sh: error while loading shared libraries:
> /usr/lib/installwatch.so: ELF file OS ABI invalid
> <-snip-->

> What does this mean?

This and similar questions belong to the scratchbox mailing lists...

It means you are trying to run x86 binaries while having an arm
library in LD_PRELOAD.  since checkinstall most likely tries to
override same functions as fakeroot and libsb, making it work is
not trivial. 

nevertheless, checkinstall does not support application installer varian deb 
packages, so it isn't going to help you much.. 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] debugging on real 770 ?

[Riku Voipio]

On Thursday 17 November 2005 02:49, Patrice Tisserand wrote:
> Hi,
> I'm currently trying to add Tcl/Tk support on maemo in order to run PDa [1]
> Everything seems to be ok in scratchbox/qemu-arm but not on real 770.
> Each time I try to add a widget via wish console, the 770 reboot.

Someone else can probably answer the debugging questions better, but
my 0.05 euro on the reboot:

flasher --set-rd-flags=no-lifeguard-reset 

will disable reboot when one of the
"life-critical" services crashes. As out-of-my-fedora guess, check what font
your widgets are using. Using non-existent fonts on kdrive xserver has some
suprising effects.. 

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Bug in Maemo's version of GTK-2.6 (Please nokia-devs look into this)

[Riku Voipio]

On Thursday 10 November 2005 11:52, Tommi Komulainen wrote:
> On Wed, 2005-11-09 at 11:15 +, ext Clemens Eisserer wrote:
> > I tried it on 7 different Linux desktop systems and it always returns
> > the deth at which the display is running so why should it be different
> > when running on the 770?
>
> There appears to be a bug in the Xserver so that it's claiming to
> support all visuals. Which is of course wrong, it only supports 16-bits.

Xserver claims to support all visuals since it has xcomposite extenstion 
enabled.  If I understand correctly, if there was a composite manager 
running, the non-16bit pixmaps would actually work.  

> Sorry for the confusion. Couldn't (actually still can't) quite see the
> actual problem. Using pixmaps of any depth should be fine, assuming you
> know what you're doing, so the problem is somewhere else?

The problem is that many existing pixmap-using programs do not work without 
major modifications in maemo/n770, and porting measures for pixmap issues are 
not documented anywhere. Also, like mentioned elsewhere, 24bit pixmaps are a 
resource waste.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] The future of the Application installer

[Riku Voipio]

On Monday 07 November 2005 18:35, Marius Vollmer wrote:
> "ext Koen Kooi" <[EMAIL PROTECTED]> writes:
> > I like the idea of extra software being in /var/lib/install so it can't
> > mess up the rootfs is something goes wrongs.

> Hmm.  That is something I have been thinking about, but it would
> require changes to the way dpkg etc work, no?

Isn't that the entire point of free software? :)

> The cleanest way to get this would probably be to add an option to
> dpkg that would make it perform the unpacking and configuring of
> packages as a specified user (instead of as root).  I think I would
> still have it update the package database as root since anything else
> seems to require too big changes.

In an ideal world, most applications would be installed with minimal 
privileges, but there is a possibility of installing applications requiring 
more privileges (like vpn applications or device drivers for add-on 
hardware).

Also, I find it quite important that software compilation process does not 
need to be changed much. Currently you have to configure with 
--prefix=/var/lib/install and then in debian/rules move the files back around 
to /. 

One way of making this possible would be installing normal apps 
to /var/lib/install, privileged apps in /var/lib/install-trusted, and make an 
unionfs[1] of these and /. Probably to somewhere else than /, so that stock 
applications don't get broken if applications install for example a broken 
gtk. 

So in the end we would have in fstab something like:

none /union/lib  
dirs=/lib=ro, /var/lib/install-trusted/lib=ro,/var/lib/install/lib=rw
none /union/usr  
dirs=/usr=ro, /var/lib/install-trusted/usr=ro,/var/lib/install/usr=rw
...

and all user application are run as "chroot /union userapp", where chrooting 
is automatically done by tasknavigator. 

unionfs with one leaf being user-writable however has some security 
implications, so the whole thing needs carefull review.  However, the 
possibility of having the cake (of safe app installation) and eating it (of 
almost unmodified debs) it seems worth it.

Cheers,
Riku

[1] http://www.fsl.cs.sunysb.edu/project-unionfs.html
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Questions to HOWTO:Set up CPU transparency with your device and sbrsh

[Riku Voipio]

On Thursday 03 November 2005 18:46, Timo Steuerwald wrote:
> I already have written that here:
> http://maemo.org/pipermail/maemo-developers/2005-November/001665.html

doh, this messages has splitted to so many threads it's hard to follow...

> <--snip--->
> [sbox-OLD_ARM: ~] > sbrsh OLD_ARM
> sbrsh: Permission denied
> <--snip--->

That would indicate that sbrshd (the daemon on the target device) is faling to 
mount. Which user is sbrshd running as? with kill -SIGUSR1 `pidof sbrshd` you 
can get it to log to /tmp
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Questions to HOWTO:Set up CPU transparency with your device and sbrsh

[Riku Voipio]

On Wednesday 02 November 2005 19:54, Timo Steuerwald wrote:
> - I've set my new target to sbrsh and the rest the same as described in 
>http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html#Building-for-ARM

how did you configure sbrsh (in sbox) and sbrshd (on target machine) ?

You need to follow this document:

http://scratchbox.org/download/files/sbox-releases/0.9.8/doc/installdoc.html#cputransp

> checking whether the C compiler works... configure: error: cannot run C
> compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.

So what does config.log say?

You can also try "sbrsh targetname --mount" directly to see if you have 
problem in nfs mounting or somewhere else. If mounting works, but apps still 
dont, try tcp networking or
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] OGG support

[Riku Voipio]

On Monday 31 October 2005 14:36, Paul Mundt wrote:
> Some versions of the ARM9 support VFP, which allows for partial hardware
> FP support for some basic single and double precision opcodes, and traps
> for the rest (it however does not offer a IEEE754 compliant interface in
> hardware, and requires quite a bit of help from software to do so). OMAP
> 2420 supports this, OMAP 1710 does not. As such, we presently use
> in-kernel NWFPE.

As I understand, trapping happens if you want the VFP to signal if it's 
results are inaccurate or non-IEEE. The logic appears to be, that for most 
users it is more important to have a fast fpu than high quality math results.  

It would need some more investigating to find out how bad the inaccuracies 
are, and if you can use it as the fpu for off-the-shelf software expecting 
IEEE semantics, or if it's usefullness is limited to code written 
specifically for it. From Debian/Alpha experiences, I would bet for the 
latter. Especially considering that pre-EV6 alpha fpu did not suck - it was 
just not perfectly IEEE compatible..

> This is not necessarily true either, and is one of the bigger reasons for
> pushing EABI. It makes sense to use VFP for what it supports natively,
> most of the rest of it is better left to something like soft-float.
> Kernel FP emulation is slow by definition.

Agreed. Even if VFP turns out to be really fast and usefull, most arm cpu's 
will still be fpuless for a long time from now. 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Cairo benchmarking

[Riku Voipio]

On Friday 28 October 2005 10:08, Kalle Vahlman wrote:
> 2005/10/28, Clemens Eisserer <[EMAIL PROTECTED]>:
> > Btw. a simple test to see wether its really the FP API which causes
> > the bad performance would be to render the whole stuff into a very
> > small surface and see wether the performance improves a lot.
> 
> I was going to test it with different xlib surface size but since the
> older SW did not allow me to kill matchbox without rebooting the whole
> thing and matchbox is kind enough to maximize the window regardless...

Just stop matchbox with dsmetool if you want to avoid reboot. 

-- 
Riku
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Unable to install development-enviroment :-(

[Riku Voipio]

On Tuesday 25 October 2005 15:22, Clemens Eisserer wrote:

> Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion
> `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
> The group 'sbox' does not seem to exist!
> Would you like me to create the group 'sbox' for you? [yes/no] (yes): yes
> Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion
> `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
 
> Any ideas what could be wrong and are there any chances that I may
> proceed further?
> I am using Fedora-Core 4 updated to the latest packages.

Fedora core 4 has vdso switched on, which breaks chrooting. 

echo 0 > /proc/sys/kernel/vdso

or at kernel command line with

vdso=0

-- 
Riku
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] relocation error during porting of an application

[Riku Voipio]

On Friday 07 October 2005 15:55, Timo Steuerwald wrote:

> <---snip-->
> [sbox-SDK_PC: ~/vover/sipX/sipXcallLib/examples/sipXezPhone] >
> run-standalone.sh ~/vover/sipX/sipXcallLib/examples/sipXezPhone/sipXezPhone
> /home/timo/vover/sipX/sipXcallLib/examples/sipXezPhone/.libs/lt-sipXezPhone
>: relocation error:
> /scratchbox/compilers/i686-linux-gcc-3.3_3.3.4-glibc-2.3.2.ds1/i686-linux/l
>ib/librt.so.1: symbol __pthread_clock_settime, version GLIBC_PRIVATE not
> defined in file libpthread.so.0 with link time reference
> [sbox-SDK_PC: ~/vover/sipX/sipXcallLib/examples/sipXezPhone] >

looks like sipXezPhone is linking against -rt. The version old of glibc in 
scratchbox gcc3.3 toolchains, and thus maemo platform provide librt only for 
glibc's internal use. Try looking of there is explict -lrt somewhere in the 
makefiles and recompiling.

Cheers,
Riku
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [Scratchbox-devel] Re: [maemo-developers] build system

[Riku Voipio]

> While trying to build it by hand and also create an ebuild (Gentoo),
> I've found out that many other things are hard coded and the build
> process is not that usual (ie: doesn't use autotools and stuff like
> that). There is any reason?

We look forward for your patches...

The reason autools isn't used is the same reason gentoo isn't built with 
autotools - scratchbox is a distribution of collected software, not a 
singe homogenic application.

Hardcoded non-FHS paths are used because FHS directories point to the
target directories. If an embedded device developer wants to put
applications into /opt (which is common), scratchbox tools cant
be in /opt/scratchbox

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Usa of "source" in startup scripts

[Riku Voipio]

On Friday 17 June 2005 14:26, Florian Boor wrote:
> while integrating some maemo software into OpenEmbedded i ran into trouble
> because many startup scripts used "source" instead of "." to source external
> files. This seems to be a feature of bash and isn't implemented in busybox 
ash i

It's a POSIX feature. And support for it can be added to busybox ash with a 
massive one-line patch. Ofcourse, "." is 5 chars shorter than "source", but 
that is a micro-optimization in maemo platform scale... :-)

-- 
Riku
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers