Re: replacement for wl1251-cal

[Eero Tamminen]

Hi,

On 08/03/2012 11:03 PM, ext Jonathan Wilson wrote:

6.My tool may leak resources (e.g. not closing handles properly) where
the Nokia tool does not (or in some cases the Nokia tool may leak
resources that my tool does not)


AFAIK there are no known leaks with these Nokia tools.

To measure and graph resource usage changes in the whole system,
you can use sp-endurance:
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc

The docs for the newer Harmattan version are here:
http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Performance_testing_tools_Using_sp-endurance.html
http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Performance_testing_tools_Using_sp-endurance-postproc.html


To analyze the leakage... If it's about memory, Valgrind Memcheck
and Massif tools might help you if pointers are lost or leak is large:
http://wiki.maemo.org/Documentation/devtools/maemo5/valgrind

For smaller and non-memory leaks sp-rtrace & functracer are most
likely best alternatives:
http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Debugging_tools_Using_functracer.html
http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Debugging_tools_Using_sp-rtrace.html
http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Debugging_tools_Using_sp-rtrace-visualize.html

Sources for the sp-* tools are here:
https://maemo.gitorious.org/maemo-tools

(Debian/Maemo packaging is typically in the "maemo-packaging" branch.)


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

Re: N950 SEGFAULT - help?

[Eero Tamminen]

Hi,

On 11/06/2011 01:03 AM, ext Nicolai Hess wrote:

2011/11/5 Felipe Crochik


Unfortunately It didn't do the trick I can't tell any difference
...still crashes with the QPainter::save()

Please let me know if any of you have any more ideas... I will play a
little more tomorrow.


Note that in general GL context should be dropped in applications
when they aren't visible. Main exception for this rule are plain GL
games because they cannot do this easily and user isn't typically
running many such games at the same time, like could be the case
with normal apps.

This is because GL contexts are severely limited resource and after
system runs out of them, any new processes just abort/crash on startup
because GL init fails.

Dropping GL context on background should happen automatically for
most MeegoTouch and QML applications.  If you're directly using GL
operations in such applications without taking this account, and
e.g. trying to do GL drawing in the background, funny things may
happen.


- Eero



Felipe


2011/11/5 Kristóf Timur


   That’s not how it’s done.

1. In your .pro file, add:
QT += opengl

2. at the top of your cpp, add:
#include

3. when you initialize your QDeclarativeView:
QGLWidget glWidget;
QDeclarativeView view;
view.setViewport(&glWidget);

Cheers,
Timur

  *From:* Felipe Crochik
*Sent:* Saturday, November 05, 2011 11:26 PM
*To:* nicolaih...@web.de
*Cc:* maemo-developers
*Subject:* Re: N950 SEGFAULT - help?

Nicolai,

I tried the application using (I assume that is what you meant):
QApplication::setGraphicsSystem("opengl");

and haven't been able to crash the application but it gets really slow
and unresponsive. Also I get these error messages on my log:

Valid eglHandle received but not running with meego compatible
graphicssystem.

Any ideas?

Thanks,
Felipe



2011/10/7 Nicolai Hess


Have you tried to use a QGLWidget for the qmlviewer ?
This works for the QML Camera element which has the
same behavior, segfaults when application moved to background.


2011/10/7 Felipe Crochik


That is the "next" problem. They are not available - maybe I need to
add some extra repository? sorry if I missed some obvious "development"
required step It is hard to start over!


2011/10/7 Daniil Ivanov


apt-get install libqtwebkit4-dbg
or
apt-get install libqt4-webkit-dbg.

2011/10/7 Ивайло Димитров:
  >  Why not install Qt debug symbols on the device and run/attach to
your

program there under gdb?



 Оригинално писмо 
От: Felipe Crochik
Относно: N950 SEGFAULT - help?
До: maemo-developers@maemo.org
Изпратено на: Петък, 2011, Октомври 7 05:20:55 EEST
I hit a wall with my application so I am looking for someone to help
everywhere I can.

The short version: how can I get qt creator to debug my application

on the

device. Right now I get CRC mismatch warnings for all libraries and

I assume

this is what prevents me to see any trace information

That is what I get when I start to debug:
...
the debug information found in


"c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvrPVR2D_DRI2WSEGL_r125.so"

does not match


"c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvrPVR2D_DRI2WSEGL.so"

(CRC mismatch).

the debug information found in


"c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvr2d_r125.so"

does not match


"c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvr2d.so"

(CRC mismatch).

...

I assume I need to install "debug symbols/versions" for the qt

libraries on

the device somehow. Am I right? How can I accomplish this?

The long version:

My applications uses qml\webview and everything works fine until I

swipe out

of my application and then later come back to it. With one click or

two I

get a segfault. This is all the information that I managed to get

running

gdb on the device:

(gdb) backtrace
#0  0x42068924 in QPainter::save() () from /usr/lib/libQtGui.so.4
#1  0x48ec294c in ?? () from /usr/lib/libQtWebKit.so.4
#2  0x48ec294c in ?? () from /usr/lib/libQtWebKit.so.4

Program received signal SIGSEGV, Segmentation fault.

Any suggestions?

Thanks in advance,
Felipe

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







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






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






Can you give a link to your source.

nicolai




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


__

Re: Aegis - Upstart script not working in Harmattan

[Eero Tamminen]

Hi,

On 08/05/2011 09:17 AM, ext Sudheer K. wrote:

Thanks a lot Tumi. The upstart script is finally working.

I ran /etc/init/xsession/app-precheck.sh and it gave errors on script, if,
fi and end stanzas. I removed all of them and just called another shell
script using exec. Here [1] is the final upstart script that worked. Thanks
again for your help.

Just a note for others creating custom upstart scripts, the upstart script
in /etc/init/apps folder is started almost 1 minute (or more) after device
is booted and applications become ready for use.


There are quite a few apps that are pre-started[1], additional things
are run after the standard pre-started apps have been started, otherwise
those additional things could slow down their startup.

[1] See:
ps|grep prestart|grep -v invoker

(Several of these are started before desktop is up, but most are started
after that.)


- Eero


This made me think lot of times that the syntax in upstart script is incorrect
(even though it is perfectly fine).

~Sudheer

[1] - http://pastebin.com/sYrq4ss6



On Wed, Aug 3, 2011 at 12:15 AM, Tuomo Tanskanen  wrote:


Hi,

Like I said, there is restrictions. In week 22 build, any violation causes
outright reject. IIRC (cannot verify right now) there is script called
/etc/init/xsession/app-precheck.sh that checks the job validity. Run that
and it'll let you know whars wrong. (that script is gone in later builds,
btw and no job is rejected but just sanitized.)

Most likely your error is in using script stanza, which in week 22 was
restricted (no longer in later). Workaround would be avoiding script in job,
but using exec stanza and doing scripty things in separate scripts (like
"exec /usr/bin/start-daemon.sh" and "pre-start exec
/usr/bin/prestart-daemon.sh" etc) Its clumsy, but luckily fixed already.

Initctl commands identify jobs by path, excluding leading /etc/init/ and
trailing . conf so in 3rd party app case start and stop commands look like:
start apps/

Hope this helps. Writing long answers on mobile+vkb isn't that handy :-)

Cheers, Tumi

On 3.8.2011, at 7.54, "Sudheer K."  wrote:



On Tue, Aug 2, 2011 at 2:29 AM, Tuomo Tanskanen<  
t...@tumi.fi>  wrote:


(Posting from mobile, excuse top post)

Hi,

Harmatran has Upstart 1.2 and since 0.5 the init job directory has been
/etc/init/ . /etc/event.d/ is not used. This is the main reason for your
failure.

Secondly, in SDK docs (dunno URL) it is suggested that 3rd party apps are
installed to /etc/init/apps/ which is dedicated for this purpose and which
imposes couple limitatations to jobs in it. There has been changes in those
since n950 sw version and latest internal builds.

I think Aegis might prevent your job to be run from /etc/init/ so you
should install to /etc/init/apps/. Most notably, jobs launched from there
cannot have "start on" stanza, but they're executed at end of boot sequence.

Hope this helps.

Cheers, Tumi



Hi Tumi,

Thanks for your response. I changed my upstart file and deployed the file
to /etc/init/apps. This time there are no errors while deploying or in the
syslog, but the job is not started. I am using build
1.2011.22-6_PR_RM680. Is there a way to troubleshoot or solve this?

I tried to start the job manually by using "start shake2skip-daemon"
command but it fails with error "Unknown job". Here is the job configuration
[1].  Any thoughts?

  ~Sudheer

[1] -http://pastebin.com/zbfBtt5f






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


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

Re: Qt application crashes after 2 minutes if started from app grid

[Eero Tamminen]

Hi,

On 05/09/2011 08:44 PM, ext Timur Kristóf wrote:

On 05/09/2011 04:43 PM, Kimmo Hämäläinen wrote:

If you don't use D-Bus at all, you need to implement this
single-instance and window raising yourself.

>
> This can be easily done with the QtSingleApplication class.

If that works by starting a new instance of the application
which them notices that it's already running and exits,
that makes window topping a really heavy operation...


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

Re: Performance of floating point instructions

[Eero Tamminen]

Hi,

(I resurrected this old thread because there was on meego-dev
mailing list a comment about possibility for RunFast float mode
being enabled by default on MeeGo...)

ext Alberto Mardegan wrote:

Eero Tamminen wrote:

Hamalainen Kimmo (Nokia-D/Helsinki) wrote:

On Wed, 2010-03-10 at 12:57 +0100, ext Alberto Mardegan wrote:

Not the libosso osso_fpu_set_mode() function?


I can't find this in libosso.h. :-(


It's defined in osso-fpu.h (since summer 2009):
http://maemo.gitorious.org/fremantle-hildon-desktop/libosso/blobs/master/src/osso-fpu.h


If somebody's using a lot of floats (RunFast mode affects only floats)
and they're a bottleneck, it would be interesting to know how much this
(setting the RunFast mode at program start) helps.


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

Re: Crash reporting

[Eero Tamminen]

Hi,

ext david.hag...@gmail.com wrote:

There's been a Crash reporter available for several years & Maemo
releases, it's even open sourced:
http://wiki.maemo.org/Documentation/devtools/maemo5/crash-reporter
http://repository.maemo.org/pool/maemo5.0/free/c/crash-reporter/



I have never been able to get this to work: Every time I have a crash
report and try to submit it, I get a "Nitro: Failed to connect" error.
I've tried having the network up, but looking at the tcpdump's it looks
like all I am getting it errors from the server.


Please file a bug.

Note that one can also have a "private" crash uploading server.

Just provide a suitable (trivial) settings package for crash
reporter which tells where to upload the cores and preferably
also sets crash reporter include/exclude files in /etc so that
only your program's core dumps get uploaded to that server.


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

Re: Crash reporting (was: Package promoting)

[Eero Tamminen]

Hi,

ext Naresh Mehta wrote:

Good comments on both the sides. Some of the points made by developers
are very valid. But a query though. Why can't Maemo make a crash
reporting system  like the one Android has?


There's been a Crash reporter available for several years & Maemo
releases, it's even open sourced:
http://wiki.maemo.org/Documentation/devtools/maemo5/crash-reporter
http://repository.maemo.org/pool/maemo5.0/free/c/crash-reporter/

However, the collected crash information isn't publicly available
because crash data (coredumps[1], logs etc) can contain private
information (passwords, URLs etc).  Because of this, the program
will show a prominent warning about this when it's installed and
asks confirmation before uploading each core dump.


The crash information wouldn't usually be that useful for the 3rd
party developers because their packages create rarely debug package
needed for getting backtraces (Maemo infra doesn't create those
automatically as it's Debian derived. RedHat and Ubuntu package
building infra create those automatically though if developer has
built his sources with debug symbols).



In short, a crash reporting system like Android


Do you have a link to what kind of information their crash reporting
system provides for 3rd party developers and users?


- Eero

[1] On Maemo5 and earlier ARM versions use of minimal crash information
wasn't possible like on Desktop Linux systems because getting
backtraces out of ARM binaries core dumps needed debug symbols
(which aren't installed on the devices).

Harmattan & Meego toolchains can & will automatically generate unwind
tables for all binaries.  With those it's possible to get working
backtraces on the device even without debug symbols (debug symbols
are then needed only to resolve the backtrace addresses to correct
function/method names, but this can be done outside the device).
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: libesd -- sound in Fremantle

[Eero Tamminen]

Hi,

(replying to this old mail)

ext Graham Cobb wrote:

On Wednesday 02 September 2009 11:50:17 Graham Cobb wrote:

However, there is no libesd for Maemo 5.  "esound" is the debian package
which builds libesd.  Anyone feel like volunteering to build a libesd from
esound? If not, I will have a go later once I have got the rest of GPE
running on Fremantle.


OK.  I have sent a cut-down esound package to the autobuilder and libesd0 and 
libesd0-dev are now in Fremantle extras-devel.  Of course, I have no way of 
knowing whether it works without a device -- someone can try it when 
gpe-calendar is available.


Pulseaudio should be used for sound output on Fremantle.

Note: using Alsa directly isn't good as it skips the speaker
protection algorithms in pulseaudio.


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

Re: suspendprocess - poor man's power save

[Eero Tamminen]

Hi,

ext Attila Csipa wrote:

On Monday 20 September 2010 17:35:34 you wrote:

There are some potential downsides for just suspending processes
completely.  Most of the processes have subscribed to several
different D-BUS messages, X events etc.

For example D-BUS will infinitely buffer messages that are sent
to a connected client but not read by it.  If these messages can
be very frequent (say device orientation & network condition messages),
this will soon bloat D-BUS memory usage quite a bit.  After D-BUS


Hmm... the external launcher that suspends is meant for apps that cannot 
really handle/listen to dbus in the first place

- if they can, they should react to the lose-focus / screen off messages
directly,  not through intermediary daemons, right ?


All UI apps (including SDL games) get focus events and can react to
them.  If e.g. game continues although it's not focused i.e. user
cannot interact with it, that's pretty bad usability.

But games ported from Desktop might still be showing e.g. some
"pause" animations when they aren't focused.  If they aren't on D-BUS,
suspending might be an OK hack for them.  IMHO it's better to fix
the program properly though, but that takes more time...


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

Re: suspendprocess - poor man's power save

[Eero Tamminen]

Hi,

ext Andrew Flegg wrote:

On Sun, Sep 19, 2010 at 17:58, Robin Burchell  wrote:

Anyway: this was pretty much in keeping with my idea: move it into the task
switcher (hildon-desktop/other) so that applications which are moved to
background are stopped (unless they signal for whatever reason that they
need to be kept running, but I'm not even sure that is necessary: if
you really need to do background processing constantly, why do it in a
GUI application?)


I suggested something similar three years ago (wow, Maemo's old ;-))
and the reaction was less favourable:

http://www.gossamer-threads.com/lists/maemo/users/26337

For example, Igor Stoppa wrote:

You are proposing a shortcut that is encouraging crappy code to be
written, since the system will always take care of saying: "psst,
pretend to be a properly written piece of code".

If an application has nothing to do, it _must_ be blocked waiting for
something, such as an event, a timer, whatever it cares about, nothing
else.


Personally, I think it'd still be useful; without going to the
(almost) co-operative multi-tasking of iOS.


There are some potential downsides for just suspending processes
completely.  Most of the processes have subscribed to several
different D-BUS messages, X events etc.

For example D-BUS will infinitely buffer messages that are sent
to a connected client but not read by it.  If these messages can
be very frequent (say device orientation & network condition messages),
this will soon bloat D-BUS memory usage quite a bit.  After D-BUS
starts to swap, it won't perform very well.

These kind of services cannot be restarted without restarting the whole
device (as all connected clients would exit), so there's no easy fix for
that effect either, like there's for example for a leaky in-process
3rd party Home applet (restarting Home).


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

Re: X server / RECORD extension problem (Xnee)

[Eero Tamminen]

Hi,

Vollmer Marius (Nokia-MS/Helsinki) wrote:

"Tamminen Eero (Nokia-MS/Helsinki)"  writes:

When I do:
   dpkg -x xnee_3.02-2maemo2_all.deb .

all I see is some docs

It's a virtual package depending on the actual binary implementation
package.


Virtual packages don't exist as archives, they are only mentioned in
"Provides".  (Sometimes there is a virtual package with the same name as
a real package, but that is best avoided.)


Sorry, I forgot "virtual package" has a specific meaning in Debian.
Anyway, "xnee" is a package that doesn't provide the functionality
itself, but through its dependencies.


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

Re: X server / RECORD extension problem (Xnee)

[Eero Tamminen]

Hi,

ext h...@mail.sandklef.com wrote:

Can't install it:(

dpkg --install xnee_3.02-2maemo2_all.deb
Selecting previously deselected package xnee.
(Reading database ... 52579 files and directories currently installed.)
Unpacking xnee (from xnee_3.02-2maemo2_all.deb) ...
dpkg: dependency problems prevent configuration of xnee:
 xnee depends on cnee | gnee; however:
  Package cnee is not installed.
  Package gnee is not installed.
dpkg: error processing xnee (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 xnee


If you use dpkg you (of course) need to install also the package
dependencies.  Apt pulls the deps too.



When I do:
   dpkg -x xnee_3.02-2maemo2_all.deb .

all I see is some docs


It's a virtual package depending on the actual binary implementation
package.



/hesa


Hi,

ext Henrik Sandklef wrote:

  just compiled and tested GNU Xnee* on Maemo. Replaying key/mouse
events (Key Press/Release, Motion, Button Press/Release) worked fine.
When it comes to recording I don't get any data although RECORD
extension is there in the X server.

  Does anyone know if there's anything strange with RECORD extension in
Maemo's X server?


There have been known issues also with upstream X server in this
respect.  See the freedesktop.org bugzilla.

I don't remember in which versions of X they were fixed (and there
were some workarounds for Xnee too I think).



/hesa

SW info:
-
Xnee:  3.06 (tweaked for Maemo)
X:  Nokia / 10699001
N900: 10.2010.19-1

Is there some problem with the current xnee/cnee packages already
in Maemo:
http://maemo.org/packages/view/xnee/
http://wiki.maemo.org/Documentation/devtools/maemo5/xnee
?


- Eero

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

Re: how to get crash stack trace in Maemo 2.2 (Nokia 770)

[Eero Tamminen]

Hi,

ext Han wrote:

On Tue, Aug 31, 2010 at 8:37 AM, Eero Tamminen  wrote:
I tried Valgrind, and it did report memory leaks.  However, most are
from gtk/gdk libs and not obvious to me if something is wrong in my
program. For example:

==19494== 2,356 (256 direct, 2,100 indirect) bytes in 1 blocks are
definitely lost in loss record 5,620 of 5,662
==19494==at 0x4024D12: realloc (vg_replace_malloc.c:476)
==19494==by 0x4747951: ??? (in /usr/lib/libfontconfig.so.1.3.0)
==19494==by 0x47483C7: ??? (in /usr/lib/libfontconfig.so.1.3.0)
==19494==by 0x4748A0B: ??? (in /usr/lib/libfontconfig.so.1.3.0)
==19494==by 0x4748A4F: ??? (in /usr/lib/libfontconfig.so.1.3.0)
==19494==by 0x473CE25: FcDefaultSubstitute (in
/usr/lib/libfontconfig.so.1.3.0)


You can probably ignore all fontconfig "leaks".  Fontconfig does stupid
pointer tricks (uses offsets instead of actual pointers) so that
Valgrind cannot know whether fontconfig still retains a pointer to
its allocations.

Note that after you've fixed some leaks, Valgrinding again may reveal
new leaks, Valgrind doesn't always see all leaks when there are lots
of them.


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

Re: how to get crash stack trace in Maemo 2.2 (Nokia 770)

[Eero Tamminen]

Hi,

ext Alexandre Fayolle wrote:
Oh, I was not clear about this : I'm a linux coder, and I have not yet started 
coding on maemo but intend to do so soon (hence my subscribing to this list). 
Sorry for throwing you on a path harder than it seamed. OTOH, compiling strace 
should not be a problem as it is a very classic Unix tool, available in all 
the distributions for all the platforms. Maybe you can even grab a precompiled 
Debian package and install it. 


Debian version is probably ABI incompatible and lacking some ARM support
(depending from which Debian version you take it).  Strace binary &
source packages are already in the Maemo SDK tools repository.  If not
for 770, take the source package from later Maemo version & build that.


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

Re: how to get crash stack trace in Maemo 2.2 (Nokia 770)

[Eero Tamminen]

Hi,

ext Alexandre Fayolle wrote:

On Tuesday 31 August 2010 09:07:01 Han wrote:

Hi,
I am using Maemo 2.2 to develop some programs for Nokia 770. Things
run pretty well except sometime my program would crash for unknown
reason. Normally I start the program from x terminal, and  it would
crash with only message "Killed".

I am wondering if possible to get a stack trace when the program
crashes?  so that I can find out where the crash happened in the code.


This looks like the executable was killed by the OS.  This can happen on Linux
because of memory exhaustion (Out Of Memory killer: see e.g. http://linux-
mm.org/OOM_Killer for more information on that). I'd advise monitoring memory 
consumption of your program. 


And Valgrinding it on x86 to see what kind of memory leaks and
other issues it has.


You could also use strace to check what's happening in your program and what 
signal is received which causes termination.


The OOM Killer uses SIGTERM, which your program can intercept if its memory 
consumption is not a bug. 


Kernel OOM killing doesn't use SIGTERM and isn't interceptable,
for a good reason.


- Eero

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

Re: Horrible performance of GL rendering; why? (Qt, N900)

[Eero Tamminen]

Hi,

ext Robin Burchell wrote:

Also note that pushing rotation updates every 10ms means you're trying to push 
100fps
(1000ms in a second, 1000/10 = 100), which is faster than the eye can percieve,
and also faster than hardware can usually manage. 60fps is usually the upper
bound, and anything over that is generally not going to be noticed except as
additional burden on the system.


Yes, LCD is refreshed at ~60fps so anything over that is just stupid.
Trying to push more frames than the can actually go through the graphics
pipeline can support, can noticeably slow down / stall things.

If the app is non-fullscreen (= composited), the limit must be much
lower (at least down to 30fps), otherwise compositor won't even get
the boxed XDamage events for all the updates (X "boxes" them together).


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

Re: How to block the camera app from starting on lens cover open

[Eero Tamminen]

Hi,

ext Martin Storsjö wrote:

On Sat, 24 Jul 2010, Yves-Alexis Perez wrote:

On ven., 2010-07-23 at 19:20 +0300, Martin Storsjö wrote:
Any hints on how to solve this in the best way? I don't want my app to 
fail in the next QA round with the reason "camera app is launched and 
closes immediately if the lens cover is opened while your app is running". 

Did you check how fcamera is doing it?


Thanks for the pointer!

It seems that the FCam library kills camera-ui using dsmetool - which 
totally makes sense for an application that tries to grab the camera 
button for itself, too.


And what happens in the application crashes without restoring camera-ui,
user needs to reboot to get camera working again?


- Eero

(better may be a small wrapper / watchdog for the process that does
the camera-ui removal before launching the program and restores it
after the program terminates?)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to catch “lock screen event”?

[Eero Tamminen]

Hi,

ext Xin Zhang wrote:
I'm developing a game for n900 using SDL. How do I catch system events (like lock screen switch turned on/off, screen gets locked automatically, or incoming call during game play)? 

Right now when the game is running, I could not catch the system events (like lock screen switch turned on/off, screen gets locked automatically, or incoming call during game play). Therefore, the game is still active running even screen is locked. I hope I can catch these system events and make the game paused. Could anyone give me some direction in fixing the problem? 


I've posted a thread in [http://talk.maemo.org/showthread.php?t=59238]. Many 
thanks!


Your window loses focus and it isn't anymore the topmost window.
When the screen is blanked, there's additionally also a D-BUS message.


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

Re: Extras QA checklist

[Eero Tamminen]

Hi,

ext Thomas Perl wrote:

2010/7/22 Eero Tamminen :

[1] For example popular gPodder application is buggy because it
apparently listens to orientation changes when it's not visible and
does e.g. lots of operations when user tries to answer a call.


If you reported a bug against said app, the developer would know about it ;)


Sure, but such bugs should be done by somebody using gPodder,
I've never tried it myself (sorry).

I just bumped in bugs.maemo.org into an issue resulting from
the bg activity by gPodder and some other apps.


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

Re: Extras QA checklist

[Eero Tamminen]

Hi,

ext Kamen Bundev wrote:
> On Tue, Oct 27, 2009 at 11:20 AM, Andrew Flegg
>> * MUST NOT waste battery life when in background or in "normal" use.
>
> What about applications that can't control what they are showing
> and such that shouldn't be suspended when in background?

They don't belong to a battery powered mobile device.


There are very few valid application use-cases for waking up on
the background:
- downloading data user has requested
- playing music (or other audio)
- tracking a route

However, even while doing these, application should never update its
window when on background as window updates are a much heavier operation
and can slow down the foreground application noticeably[1].

This is easy to test with xresponse from the SDK tools repository, just
do in SSH console:
xresponse -w '0' -a '*'

And see whether it reports anything when the app is on background.

To check for wakeups in general, one can do this in console:
strace -f -p 


E.g. Games should automatically pause when they go to background
for obvious usability reasons, not just because of battery consumption.


ext Graham Cobb wrote:

On Wednesday 28 October 2009 18:28:24 Antti Vähä-Sipilä wrote:

 * MUST NOT introduce security risks.

I'd rephrase "MUST NOT contain known security vulnerabilities" and


So a release that fixes only some of the issues won't get promoted
until all (known) issues are fixed (and potentially new unknown ones
added)?

I would rephrase this as "MUST NOT introduce (additional) security
risks."


Then one thing missing from the QA checklist completely is checking
for resource leakage.  A leaky home applet can slow down home a lot
and the caused increased swapping probably slows also rest of the device
to some extent.

Any tested application should be used for couple of days to see
that it doesn't cause problems for the device.


- Eero

[1] For example popular gPodder application is buggy because it
apparently listens to orientation changes when it's not visible and
does e.g. lots of operations when user tries to answer a call.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: X server / RECORD extension problem (Xnee)

[Eero Tamminen]

Hi,

ext Henrik Sandklef wrote:
  just compiled and tested GNU Xnee* on Maemo. Replaying key/mouse 
events (Key Press/Release, Motion, Button Press/Release) worked fine. 
When it comes to recording I don't get any data although RECORD 
extension is there in the X server.


  Does anyone know if there's anything strange with RECORD extension in 
Maemo's X server?


/hesa

SW info:
-
Xnee:  3.06 (tweaked for Maemo)
X:  Nokia / 10699001
N900: 10.2010.19-1


Is there some problem with the current xnee/cnee packages already
in Maemo:
http://maemo.org/packages/view/xnee/
http://wiki.maemo.org/Documentation/devtools/maemo5/xnee
?


- Eero

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

Re: N810 upgrades

[Eero Tamminen]

Hi,

(commenting on this old mail...)

ext Martin Grimme wrote:

the N810 supports over-the-air updates since Diablo OS. So there's no
need for flashing for an update.

Maemo5 does not run on the N810.


Although 3D is given as one reason for this, I think Fremantle memory
usage and N810 having only half the RAM in N900 would actually be bigger
obstacle.  Fremantle apps take about 2x more memory than Diablo ones,
partly due to compositing used by the desktop, partly due to
panning buffers etc.



The closest you can get is the alternative Mer OS


As to the community efforts, I think the Fremantle features
that would be most beneficial for the N8x0 base system would be:
- replacing JFFS2 with faster and less RAM using UBIFS[1].
  This would require kernel upgrade and remaking/reflashing
  the rootfs image.
- using swap partition from a memory card instead of a swap file
  on FAT file system.  This would be much more robust.
- replacing Busybox with a newer version in Fremantle (using
  the Diablo configuration though) to make it more compatible
  with Debian stuff.


[1] For full file systems.  Unlike JFFS2, UBIFS doesn't keep the whole
file system in RAM so it uses less RAM, and it also mounts full
file system _much_ faster than JFFS2.  However, there are some
gotchas when moving from JFFS2 to UBIFS (writeback/synching,
space accounting), mentioned here:
http://www.linux-mtd.infradead.org/doc/ubifs.html



> which tries to backport Maemo5 stuff onto a Ubuntu
> based OS running on the N810.

With Ubuntu's base memory usage, that seemed a bit
strange choice.  (I've never tried Mer though, this
was just idle speculation)


> It's still in an early stage, though.

But now that Mer people have changed to base things on MeeGo, maybe
the base system memory usage is less of a concern.


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

Re: sp-endurance and device memory usage

[Eero Tamminen]

Hi,

ext Dawid Lorenz wrote:

PR1.2 fixes last known wakeup-on-background issue in microb engine
(related to animated images, reported also to upstream mozilla).
When I last tested Fennec few months ago on my N900, it was constantly
waking up on the background, so I would suggest at least closing it
when you don't use it.

Is there a way to determine if application is waking up in the background
constantly?


Check whether the value in TIME+ column changes in the "htop" output.

Attach to the process with "strace -f -p PID"[1] and see whether it
does anything.

[1] htop has "s" keyboard shortcut to trace processes, but it doesn't
give the "-f" option so that all process' threads would be tracked.
Upstream "htop" seems to have a bug about this:
http://sourceforge.net/tracker/?func=detail&aid=2987532&group_id=108839&atid=651635


(htop and strace are both available from the SDK tools repo.)



I might be wrong, but I think I've seen that issue about
Fennec somewhere and have a feeling it got addressed. Well, certainly
many issues in Fennec were addressed, as the latest beta (and nightly
builds) are actually usable and not that terribly slow as version 1.0
final and earlier.


If you check this, please tell whether it's (fully) fixed now. :-)


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

Re: sp-endurance and device memory usage (was: Why should I write apps for Maemo?)

[Eero Tamminen]

Hi,

(CCing to maemo-devel as this might contain useful info also
for others.)

ext Dawid Lorenz (maemobile) wrote:

There's one thing missing from these graphs - Modest.
I am pretty sure it could have major impact on memory
usage/performance. Or maybe I'm wrong?


sp-endurance in the public repositories lists only processes that
are both present in multiple endurance snapshots and which memory
usage changes.

In your data, the Modest PID changed in every snapshot.



To see a summary of the leaks, look at the summary sections at
the end of the HTML files.  The leakers differ after you had
rebooted the device (e.g. systemui doesn't leak nearly as much).


Hmm... could systemui be related with the way I lock my device,
ie. using power key button doble-click? I sometimes do that, but not always.


Apparently it leaked (very, very little) whenever it was topped or
lock/unlock was used, both of these issue are fixed in PR1.2.

Before that's released, systemui should be safely killable
(& auto-restarted) as long as you don't do it too often in a row.



You could try whether killing the leakers you see in the endurance
report help with the device usability.  Except for things like X
and D-BUS, killing them should usually just re-start them (when
needed), not cause device reboots. :-)


I just killed addressbook-factory and that instantly released
8% of swap space! Killing off browser & browserd release another 2%.
I try killing off pulseaudio and mafw wrapper once I get home and
stop listening to the music as I type this email on the train ;)


(Note to others: addressbook-factory, browser ui and mafw-wrapper
memory leakages are fixed in soon-to-come PR1.2.  Pulseaudio memory
usage is dependent on what it's clients do.)



Btw, what exactly is browserd for and is there a way of completly turning it off


There's a master browser daemon for quickly forking pre-initialized
browser engine instances.  Then there are separate pre-started browser
engines for Browser and Messaging apps.  Without pre-starting, the
startup would take close to 10s.



(if for example I decided to switch to Fennec completely)?


PR1.2 fixes last known wakeup-on-background issue in microb engine
(related to animated images, reported also to upstream mozilla).
When I last tested Fennec few months ago on my N900, it was constantly
waking up on the background, so I would suggest at least closing it
when you don't use it.

Note that worse than something using a lot of memory, is it being
active and using it also on the background like Fennec does
(I've also noticed Maep to do that, I've filed Garage bugs about
that)...

It's useful to check occasionally with "top" whether some application
you left on background is active or not.  If it is, without a good
reason, please file a bug.

Of the pre-installed apps, browser stops activity 1/2 min after going
to background (this www-page JS timers disabling timeout is configurable
from Browser options), and media player of course continues playing
music on bg, but everything else should stop working once it's finished
what user asked it to do.



Could be.  Maybe you could run "mem-cpu-monitor" from the sp-memusage
package in XTerm and ask it to track pulseaudio to catch what causes
it to grow?


Wow, that mem-cpu-monitor is very nice tool. Like it. I need to
get my head around all these tools at some point, however I might
just stick to endless (?) wait for PR1.2 first, just to see whether
leaking issues have been indeed ironed out in that release. :)



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

Re: Howto grab all Maemo5 zoom key events in SDL/SDL_gles app?

[Eero Tamminen]

Hi,

Hamalainen Kimmo (Nokia-D/Helsinki) wrote:

On Sun, 2010-05-02 at 13:26 +0200, ext Till Harbaum / Lists wrote:

i'd like to access the zoom keys in a SDL/SDL_gles app (the 3d globe
i uploaded to extras-devel).

The odd thing is that my solution only partly works. Some key presses actually
reach my app as function key presses, but still most of them reach the volume
control. So when repeatedly pressing the zoom buttons my app zooms but also
the volume is changed.

I am using the following code which is inspired by code from scummvm. I am 
calling this code once immediately after the SDL setup is done.


Any idea why this still delivers some key events to the volume control?


It could be that _NET_ACTIVE_WINDOW or MB_CURRENT_APP_WINDOW on the root
window does not correspond to your window.  The volume app is tracking
one of these (I think _NET_ACTIVE_WINDOW) to determine the window whose
ZOOM_KEY window property matters.


Maemo SDL doesn't seem to set all required window properties for
fullscreen windows for tracking of the topmost application to work
properly.  See this bug:
  https://bugs.maemo.org/show_bug.cgi?id=6175#c3

"xprop -root" produces this when there's a fullscreen SDL window:
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x3e2 


_MB_CURRENT_APP_WINDOW(WINDOW): window id # 0x3e1

I.e. for SDL applications the value in these properties differ,
unlike for normal applications.

_MB_CURRENT_APP_WINDOW is the fullscreen SDL window and
_NET_ACTIVE_WINDOW is the non-fullscreen SDL window.

(I think SDL uses fullscreen window for output and non-fullscreen
one for input.)


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

Re: Why should I write apps for Maemo?

[Eero Tamminen]

Hi,

ext Dawid Lorenz wrote:

On 10 May 2010 14:09, Eero Tamminen 
mailto:eero.tammi...@nokia.com>> wrote:
Actually, what I'd love to be able to do is simply flush swap space
periodically. I've noticed that once swap space usage passes approx.
20%, device gradually becomes unbearable with regular day-to-day usage,
hence reboot is essential.


I think the problem you're getting that almost all of that 20% is
fairly actively used.

Rest of the swap is mainly useful for the cases when there's just a very
temporary large memory need, or for applications that leak large amounts
of memory they'll never again touch.



Manually restarting
/etc/init.d/tablet-browser-daemon doesn't help much, yet it seems that
browsing web is quite sluggish regardless of restarting browserd. I'd
simply like to know the way to release swap space somehow, instead of
rebooting device.


Something that could help slightly is disabling pre-starting for
applications that you don't use. Comment out the pre-starting lines
where  appropriate:
  grep Prestarted /usr/share/applications/hildon/*.desktop


> Perhaps restarting some other services?

sp-endurance is created for catching things that leak resources:
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc

Probably the best way to use it in your case is to write a small script
that takes a snapshot to some directory under MyDocs every night
(untested):
-- snapshot.sh ---
#!/bin/sh
# take endurance snapshot once a day
while true; do
save-incremental-endurance-stats /home/user/MyDocs/endurance
sleep $((24*60*60))
done
--

Then run it as root, so that it gets started first time some
time at night (let's assume night is in 6 hours):
# sleep $((6*60*60)); ./snapshot.sh

The reason to take the snapshots at night is that usually the device
is then in consistent state, apps aren't actively used etc.  Best would
be if you could always leave the device to same state for the night.


After device starts to be slow (you said 5-6 days?), post-process
the data:
parse-endurance-measurements /home/user/MyDocs/endurance/1*

And see what processes it reports to be growing in memory usage.

If the process specific bar charts show something going to swap
and coming back from there, it means that this amount of memory is
actively used, not just dormant.



The other option is tell specific "core" (like phone app) applications
to be never swapped away, yet I don't know whether that's possible at all.


This is already done to a reasonable level with memory locking and
the policy daemon.


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

Re: Why should I write apps for Maemo?

[Eero Tamminen]

Hi,

ext Dawid Lorenz wrote:

On 7 May 2010 09:48, mailto:tero.k...@nokia.com>> wrote:
Very good point, seriously. Yet I think Marcin had ever better:


(Hm. Is Maemo showing its Debian roots?)


Good attempt for joke but failed. Debian has 'testing' branch which users can
use, test, report bugs against and got them fixed before release. Maemo does
not give any of those.


I'd really love if we would have something like that.

(No idea how, I'm not related to how our releases are done.)

There can always be some regression that's slipped through our
(extensive) internal testing.  Some kind of a "monthly developer
snapshot" would help in catching those.



Releasing "test-and-strictly-developer-aka-geek-oriented" images on regular
basis would be simply great. Think of it like extras and extras-testing/devel
- yet not for apps, but full-blown OS images. Normal users should strictly
stay away from these, but whole bunch of geek folks who imho are the essence
of Maemo/MeeGo platforms would jump high in joy and that would definitely keep
guys on both sides of the fence relatively happy. Just my three cents.

Btw, I am also uber-eager to see PR1.2 on my device, especially after seeing
what Eero said about Browser and performance, as currently I simply need to
reboot my N900 every 5-6 days to keep my sanity while using it...


Several of the 3rd party things leak memory and especially if that
happens with a 3rd party in-process home applet, the result is not
pretty in long run...  But you can get rid of the memory usage by
restarting the process.

If the issue is with Browser, just kill it and it will be restarted,
just don't start it too many times in a row or you trigger SW watchdog.
Browser can with long time usage also cause some swap fragmentation
(=> extra swap activity), you can get rid of that also by restarting it.

If the issue is with hildon-home (plugin), you need to stop and start
it with the dsmetool SW watchdog, plain "killall hildon-home" would
cause Home to think that there was some stability issue with applets
and disable 3rd party plugins (to prevent restart/reboot loop).


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

Re: Why should I write apps for Maemo?

[Eero Tamminen]

Hi,

(standard disclaimer: below are my personal opinions)

ext Michael Cronenworth wrote:
At most, the SDK should have been released two weeks ahead of the final 
release.


Agree.


With a little over a month now on the clock, people can only 
begin to speculate as to how poor Nokia's release management is working. 


Releases are not based on calendar, but on them being ready, based
on testing results. (Hm. Is Maemo showing its Debian roots?)


I, as a software developer, realize that unexpected issues can occur 
causing unexpected delays,


I think it's mainly due to wanting something that doesn't have
any known regressions in any area from the previous release while
significantly[1] improving some areas.  And this requiring
somewhat unexpected amount of iterations.


As one example, when we optified some of the rootfs content to make
more space on it (for SSUs), we had to deal with the slowdowns coming
from those packages being now on eMMC (which is slower than rootfs
especially when the device is swapping).  This required quite a lot
of iteration on what to optify, SSU issues, policy & memory locking
finetuning, otherwise optimizing slow things etc.


Another example, which some might think funny, is Browser related.

Browser + Flash combination had some crashes which were fixed
(because UI restarts engine automatically, user might not even
have noticed these except as larger browsing slowdown).  However,
with the fixes single Browser engine instance could keep up so long
that several days of Browsing increased its memory usage a lot.
Which then caused performance issues...

Finding that this was one cause for longer term usage slowdowns took
quite a while, as did hunting down[2] and fixing these previously
unnoticeable[2] memory leak(s).


We also wanted to fix all the SGX related issues, but I think one
is going to be left after PR1.2 as it's not reproducible.  A lot
of other SGX issues that were eventually to some extent reproducible
by someone internally, either with specifically crafted test-case or
some already existing SW, have been already fixed in internal PR1.2
releases.


[1] While some things are obvious, improvements in some other areas
aren't necessarily directly visible to (all) users, because many
of the issues we've fixed (use-time, reliability etc), happen only
in very specific conditions or use-cases.


> -Is PR1.2 still going to be released?

Definitely.


- Eero

[2] In case somebody hasn't hunted down Mozilla memory leaks,
maybe mentioning these gives some light on it:
- Valgrind doesn't produce very useful results with it because of
  the JavaScript (and multiple Flashplayer) interpreters
- Browser is an application doing both largest number and largest
  total amount of allocations of the applications in the device and
  those are completely controlled by content on the www-pages
  and this content changes[2] from one page refresh to another.

[3] If testing would use just static browser content, it would
miss new issues with latest real & live web content.  Non-
changing test content can find just regressions.

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

Re: xdg-mime missing: is there a way to find out the default application for a given mime type

[Eero Tamminen]

Hi,

ext Felipe Crochik wrote:

How can I find out what is the default application associated to a file type 
(or preferably a mime type)?

I found out that, at least, on ubuntu you can use xdg-mime for that.


xdg-utils is supposed to come in Harmattan:
https://bugs.maemo.org/show_bug.cgi?id=2724


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

Re: Squeeze devkit to be installed to autobuilder

[Eero Tamminen]

Hi,

ext Marcin Juszkiewicz wrote:
[sbox-FREMANTLE_ARMEL: ~] > 


CFLAGS="-Wall -g -O2 -mthumb" ./configure --host=arm-linux-gnueabi --
build=arm-linux-gnueabi --prefix=/usr --sysconfdir=/etc --
mandir=\${prefix}/share/man --infodir=\${prefix}/share/info 
checking for a BSD-compatible install... /scratchbox/tools/bin/install -c

checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
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.
make: *** [configure-stamp] Error 1



Then you apt-get install maemo-sdk-symbols from extras-devel and you are
done.


mdbus2 package fails at configure step


What sets the CFLAGS and configure flags?

CFLAGS are broken as N900 OMAP3 revision doesn't reliably support thumb
(see ARM errata).

With Sbox you don't need to set --host or --build options.


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

Re: Is it possible to use SCHED_FIFO policy on N900?

[Eero Tamminen]

Hi,

ext tarantism wrote:

On Mon, 2010-04-26 at 16:19 +0300, Eero Tamminen wrote:

ext tarantism wrote:

_POSIX_PRIORITY_SCHEDULING is defined but attempting to create a pthread
with SCHED_FIFO returns an error. Calling pthread_setschedparam with
policy of SCHED_FIFO doesn't complain but checking with
pthread_getschedparam shows a policy of SCHED_OTHER.

Is it possible to set a policy of SCHED_FIFO (or SCHED_RR) or am I
wasting my time?

Are you running as root?


Thanks for the reply.
Yes, I'm running as root.
Code that works fine on Ubuntu returns an error from pthread_create.
Can you confirm that SCHED_FIFO works on Fremantle? If it does, I'll
happily keep plugging away but it would be nice to know that what I'm
trying to do is possible!


There's a stress-test package that has a tool with options
for selecting the scheduler:
http://repository.maemo.org/pool/maemo5.0/free/s/sp-stress/

Changing the scheduler doesn't for some reason seem to work now:
-
# cpuload -s f 10


CPU load generator, build Sep  4 2009 15:09:38. 

Copyright (C) 2006,2008 Nokia Corporation. 




WARNING: setting scheduler failed failed: operating with default. 


Reason: Operation not permitted
...
# strace cpuload -s f 10 


  ...
sched_get_priority_max(SCHED_FIFO)  = 99 

sched_setscheduler(0, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not 
permitted)

-

But it definitely worked last summer when this option was added to it.
I'm not sure what's happened in the meanwhile.

Maybe the issues is with the used realtime priority:
-
# cat /proc/self/limits |grep realtime
Max realtime priority 00 


Max realtime timeout  unlimitedunlimitedus
-

Does setting SCHED_FIFO with priority 0 work?


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

Re: Is it possible to use SCHED_FIFO policy on N900?

[Eero Tamminen]

Hi,

ext tarantism wrote:

_POSIX_PRIORITY_SCHEDULING is defined but attempting to create a pthread
with SCHED_FIFO returns an error. Calling pthread_setschedparam with
policy of SCHED_FIFO doesn't complain but checking with
pthread_getschedparam shows a policy of SCHED_OTHER.

Is it possible to set a policy of SCHED_FIFO (or SCHED_RR) or am I
wasting my time?


Are you running as root?


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

Re: phone case?

[Eero Tamminen]

Hi,

ext Christopher Intemann wrote:

I'm looking  for a nice case for the N900.
It should not noticeable thicken the device, since the N900 is quite big 
already. Leather is ok, but anything else would be fine as well.
And, I will absolutely not wear the phone on my belt, so, no need for clips or 
anything like that.
Thanks for recommendations.


Make sure that it doesn't have magnets, see:
https://bugs.maemo.org/show_bug.cgi?id=8235

(That should be mentioned in documentation
somewhere, but who reads them?)


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

Re: Did Nokia alter kernel's OOM handling for the 770?

[Eero Tamminen]

Hi,

ext Clemens Eisserer wrote:

I am using my Nokia-770 as allround-server running
postgres+tor+routing+lighthttp.
It works quite great (except the broken wlan-driver causing crashes
all few days when running a tor-relay).
However from time to time the OOM killer kicks in, although there's
plenty RAM and swap available.

Any idea whats causing the kernel to go mad?
Was it altered intentionally (if so, what was changes so that I can
revert it), or is it a bug somewhere?


AFAIK only to be able to tell it to try to avoid couple of processes
without needing to run them as root (OOM-killer heuristics try by
default avoid root processes).

The limit when to start doing OOM-killing is also set from user-space,
but it might be related to the amount of free RAM, I'm not sure whether
it on 770 takes into account swap.


- Eero


Thank you in advance, Clemens

[17676.783874] oom-killer: gfp_mask=0x201d2, order=0
[17676.797241] [] (dump_stack+0x0/0x14) from []
(out_of_memory+0x40/0x1d8)
[17676.797393] [] (out_of_memory+0x0/0x1d8) from
[] (__alloc_pages+0x240/0x2c4)
[17676.797515] [] (__alloc_pages+0x0/0x2c4) from
[] (__do_page_cache_readahead+0x150/0x324)
[17676.797637] [] (__do_page_cache_readahead+0x0/0x324) from
[] (do_page_cache_readahead+0x64/0x70)
[17676.797760] [] (do_page_cache_readahead+0x0/0x70) from
[] (filemap_nopage+0x190/0x3ec)
[17676.797943]  r7 =   r6 = 00219560  r5 =   r4 =
C25E
[17676.798004] [] (filemap_nopage+0x0/0x3ec) from
[] (__handle_mm_fault+0x2fc/0x96c)
[17676.798126] [] (__handle_mm_fault+0x0/0x96c) from
[] (do_page_fault+0xe4/0x214)
[17676.798248] [] (do_page_fault+0x0/0x214) from
[] (do_DataAbort+0x3c/0xa4)
[17676.798339] [] (do_DataAbort+0x0/0xa4) from []
(ret_from_exception+0x0/0x10)
[17676.798461]  r8 =   r7 = 40639540  r6 = 40639560  r5 =
0001
[17676.798553]  r4 = 
[17676.798583] Mem-info:
[17676.798614] DMA per-cpu:
[17676.798675] cpu 0 hot: high 18, batch 3 used:2
[17676.798706] cpu 0 cold: high 6, batch 1 used:0
[17676.798767] DMA32 per-cpu: empty
[17676.798797] Normal per-cpu: empty
[17676.798828] HighMem per-cpu: empty
[17676.798950] Free pages:1172kB (0kB HighMem)
[17676.799011] Active:5576 inactive:6815 dirty:0 writeback:231
unstable:0 free:293 slab:1257 mapped:12129 pagetables:374
[17676.799133] DMA free:1172kB min:1024kB low:1280kB high:1536kB
active:22304kB inactive:27260kB present:65536kB pages_scanned:91
all_unreclaimable? no
[17676.799224] lowmem_reserve[]: 0 0 0 0
[17676.799285] DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB
inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
[17676.799377] lowmem_reserve[]: 0 0 0 0
[17676.799468] Normal free:0kB min:0kB low:0kB high:0kB active:0kB
inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
[17676.799530] lowmem_reserve[]: 0 0 0 0
[17676.799621] HighMem free:0kB min:128kB low:128kB high:128kB
active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable?
no
[17676.799682] lowmem_reserve[]: 0 0 0 0
[17676.799743] DMA: 33*4kB 4*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 1172kB
[17676.799896] DMA32: empty
[17676.799926] Normal: empty
[17676.799957] HighMem: empty
[17676.800018] Swap cache: add 12847, delete 11756, find 42323/43010, race 0+0
[17676.800079] Free swap  = 167716kB
[17676.800109] Total swap = 198272kB
[17676.800170] Free swap:   167716kB
[17676.804534] 16384 pages of RAM
[17676.804565] 638 free pages
[17676.804595] 1096 reserved pages
[17676.804626] 1257 slab pages
[17676.804656] 19580 pages shared
[17676.804718] 1091 pages swap cached
[17676.805267] Out of Memory: Kill process 1535 (postgres) score 11478
and children.
[17676.805358] Out of memory: Killed process 1537 (postgres).
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers



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

Re: N900 kernel module recompile

[Eero Tamminen]

Hi,

ext Nils Faerber wrote:

Frantisek Dufka schrieb:

Nils Faerber wrote:

Then kernel config:
cp arch/arm/configs/rx51_defconfig ./.config
make oldconfig
A "make modules" does cleanly compile the modules. Fine so far (except
for that te modules are *huge* and a "arm-none-linux-gnueabi-strip -R
.not -R .comment --strip-unneeded" seems reasonable).

Looks like this strips module version symbols too. Tried similar
approach with same result before.


Just tried it - works like a charm ;)
And the module shrinks from ~200k to ~20k.


I think the kernel debian source package should be using dh_strip to
automatically separate the debug symbols to a separate (kernel-debug?)
package.  Debug symbol package is handy for debugging if you get any
issues


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

Re: Performance of floating point instructions

[Eero Tamminen]

Hi,

ext Alberto Mardegan wrote:

Right. Just to complete the picture, here's the same data with -O2:

float (fast mode enabled):
map_path_calculate_distances: 40 ms for 8250 points
map_path_calculate_distances: 2 ms for 430 points

double (fast mode enabled):


Note that fast mode affects only floats.



map_path_calculate_distances: 93 ms for 8250 points
map_path_calculate_distances: 4 ms for 430 points

(I'm not posting the same data with fast mode disabled, as it cannot be 
worse than the -O0 case, which is anyway not too far from these values)
The relative preformance seems to be about the same. But then of course, 
it might not be because of the FPU, but of the data transfers.



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

Re: N900: Mapper, device deadlocks and clutter/GL errors

[Eero Tamminen]

Hi,

ext Alberto Mardegan wrote:

Hi all,
   I've some issue with Maemo Mapper which I cannot solve by myself and are 
unfortunately quite severe:


- Sometimes, a "HWRecoveryResetSGX: SGX Hardware Recovery triggered" line 
appears on the syslog. Most of the times, without any visible effects.


It means that SGX HW got into state from which it cannot recover, so it
reseted itself.  When that happens, the current SGX HW state is lost.


- Rarely, the device freezes for several seconds. It seems to me that this is 
solved by pressing the power key and waiting a few seconds -- but it might be 
just a coincidence.


When that happens, it can (will) cause temporary slowdown on display
updates.


- Always: when I'm drawing on a texture (either loading a map tile, or using 
cairo on a texture) and a Hildon banner/notification appears (either from Mapper 
itself, or even an incoming chat notification), the texture is corrupted, and it 
will contain a small rectangle with pseudorandom pixels.


And the graphics being drawn when the SGX HW reset happened can be
corrupted (as the operation was interrupted and state before the reset
isn't recoverable).



I'm using clutter 1.0, from extras-devel.

When running the application in Scratchbox i486 with valgrind, it is damn slow 
but I don't see any errors reported while rendering the tiles.


Can you help me to debug this? I suspect it is all due to some bugs in clutter 
(or maybe in the SGX driver), but I have no idea where to start from.


It's currently assumed to be a SGX driver issue[1].  As it's non-
reproducible, it's hard to get it fixed _and_ to be verified to be
fixed.  The next release will have an updated SGX driver with changes
which which should at least make the issue much rarer.

Note that on most(?) devices it doesn't seem to happen at all, at least
with the pre-installed software.

But e.g. the 3rd party Maep application seems to make triggering of this
issue (at least on some devices) easier, especially as/when it's doing
window updates even when it's not visible (which is a clear use-time
and resource usage bug in Maep).


- Eero

[1] See e.g. https://bugs.maemo.org/show_bug.cgi?id=9150
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Performance of floating point instructions

[Eero Tamminen]

Hi,

Hamalainen Kimmo (Nokia-D/Helsinki) wrote:

On Wed, 2010-03-10 at 12:57 +0100, ext Alberto Mardegan wrote:

Kimmo Hämäläinen wrote:

You can also put the CPU to a "fast floats" mode, see hd_fpu_set_mode()
in
http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/main.c


Not the libosso osso_fpu_set_mode() function?


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

Re: Performance of floating point instructions

[Eero Tamminen]

Hi,

ext Alberto Mardegan wrote:

Kimmo Hämäläinen wrote:

You can also put the CPU to a "fast floats" mode, see hd_fpu_set_mode()
in
http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/main.c

N900 has support for NEON instructions also.


This sounds interesting!

Is there any performance penalty if this switch is done often?


Why you would switch it off?

Operations on "fast floats" aren't IEEE compatible, but as far as
I've understood, they should differ only for numbers that are very close
to zero, close enough that repeating your algorithm few more times would
produce divide by zero even with IEEE semantics (i.e. if "fast float"
causes you issues, it's indicating that there's most likely some issue
in your algorithm).


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

Re: Extras-testing improvements

[Eero Tamminen]

Hi,

Voipio Riku (Nokia-D/Helsinki) wrote:
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


If application does things on the background without user requesting
it (like e.g. Maep), that's bad for the performance of the application
on top (the one user is trying to interact with) and for the device
battery life.


App should do only things as response to what user requested.

In the Maep case, it should do things on the background only if it's
requested to track a route, and even then, skip its window updates
to minimize its CPU usage.

Tester can see CPU usage from SSH console with "top"
and screen updates with:
xresponse -w 0 -a '*'


If there were some easy way for the user to see that bg app is slowing
down things & eating battery, I think letting them to do that would
be more acceptable.  Then it's user's choice to use the badly behaving
(but potentially otherwise very useful) application.  She knows to
close the application when not needing it or low on battery.


> (such as hildon-desktop plugins).

But for applets in home or statusbar, using CPU when home isn't
visible or leaking memory etc is inexcusable.



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.


Here's the quality awareness pages for Diablo and earlier:
https://garage.maemo.org/plugins/wiki/index.php?id=253&type=g
http://maemo.org/maemo_release_documentation/maemo4.1.x/node16.html

Didn't find it for Fremantle though.


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

Re: Fw: Proposal: MeeGo User Experience Framework working group

[Eero Tamminen]

Hi,

ext Randall Arnold wrote:

Thanks Attila!  I just uploaded a more recent update to the PDF
(http://maemo-daemons.org/MeeGo_User_Experience_Framework.pdf)
based on helpful feedback so far.


Some comments on the bug reporting thing.

We already have Crash reporter which collects crashes.


Creating automated bug reports from crashes isn't useful because:

* Users don't write detailed enough use-case descriptions
  to the crash uploads.  It's slightly too inconvenient to
  do that with the device.

* Bugs are related to use-cases, not crashes.  Without a reproducible
  use-case, bugs are usually worthless as you cannot even verify
  potential fixes to them i.e. tell when the issue is fixed.


Telling for which _already existing_ bug crash is related to is
useful though and Crash reporter already supports that for (internal)
bugs. Due to screen size constraints bug number is given as a keyword
in note field instead of there being a separate field for it though.
There are going to be some updates to Crash reporter soon so that user
can select which bugs to upload (so that unrelated core dumps can be
uploaded separately or ignored).


Crash reporting isn't currently targeted for normal users
for few reasons:

* Crash dumps are large and can contain private information
  (like passwords).  Hopefully in Harmattan we can can use
  minidumps that contain only enough information for backtraces,
  not all the process data.

* Installing syslog means that user's rootfs can run out of space
  if the log file grows too large (syslog is run as root).  Syslog
  can also contain private information (user names etc).

* Crash dumps in heavily loaded device will make the situation
  worse (whole crashing process needs to be swapped in for core
  dump etc).


- Eero

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

Re: MeeGo

[Eero Tamminen]

Hi,

ext Carlos Morgado wrote:
> What platforms will it run on ?

Read the MeeGo site (like I just did).  Based on it, different
product categories are going to have different UIs, but the toolkit
below them used by the application developers will be the same (Qt).


> Does Nokia have arm kernel people ?
> Don't think so, but I dunno intel has loads of x86 kernel people.

You really don't know?  Linux kernel development is open, you can
just subscribe to arm/omap kernel mailing list and see yourself.

Linux Weekly News (http://lwn.net/) even publishes regularly statistics
on which companies develop Linux kernel (based on the commit logs).



The whole Qt run everywhere pipe dream is just laughable.


Could you detail which GUI toolkits you think to do this better
than Qt and how/why?


- Eero

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

Re: Maemo 5 and hw accelerated X.Org?

[Eero Tamminen]

Hi,

ext Kuba Irzabek wrote:
Is xserver in Maemo 5 (Nokia N900 OMAP 3) using hardware acceleration 
(SGX)?


Yes, to some extent, but SGX is 3D accelerator, you cannot really expect
it to make much difference for most 2D operations.

For simple 2D operations like blitting, SGX is actually slower. In those
kind of operations both CPU and SGX are memory bandwidth bound, but SGX
is run at slower speed than CPU and has command setup cost.

Memory ownership change between CPU and SGX has also a performance cost
because this requires cache flush.


I cannot find confirmation on that anywhere. I found inforamtion
that accelerated user interface on omap 3 can be done using qt embedded 
or clutter and not xserver. Where can I find more on that topic?



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

Re: Browser Switchboard, MicroB, and application prestart in Fremantle

[Eero Tamminen]

Hi,

ext Steven Luo wrote:

I'm the maintainer of Browser Switchboard [1], which is a program
that's supposed to make it possible for the user to choose the
default browser on his/her Maemo device.  Packages are available in
extras for Diablo and extras-devel for Fremantle.

In order to control the default browser, Browser Switchboard takes
over handling of the com.nokia.osso_browser D-Bus methods.  Since
launching MicroB from the menus invokes
com.nokia.osso_browser.top_application, it has to be able to launch
MicroB.

For Diablo, we do this by exec() of /usr/bin/browser(*), but this
doesn't seem to bring up a browser window in Fremantle (see the
discussion on talk.maemo.org [2]).

Also, at least in testing with my half-broken SDK, the Fremantle
browser process remains in memory even after the last browser window
closes.  This poses a problem for Browser Switchboard, which releases
com.nokia.osso_browser before starting MicroB (so that MicroB handles
the methods while it's open, giving users an easy way to temporarily
open links in MicroB no matter what their default browser is set to),
and needs to be able to reclaim the name when the last browser window
closes.

I can only assume this behavior is related to the prestarting of the
browser process in Fremantle, but I'm unclear on how Browser
Switchboard interacts with prestarting in the first place (is a
browser process prestarted on boot when Browser Switchboard is
installed?), and I don't have a Fremantle device to test any of this
on.

That leaves me with the following questions:

* How does one open a new browser window from an application,
  preferably without using the D-Bus interface?  (If there is no
  other way to bring up a new window except D-Bus, I assume I'd have
  to try something like launching the browser process, waiting for it
  to acquire the com.nokia.osso_browser name, then making the method
  call, which wouldn't be pretty, and also precludes the possibility
  of working with a prestarted browser process).

>

* Is there a way to ensure the browser process quits when the last
  browser window closes?  If not, is there a way to receive a signal
  when the last browser window closes?  (It's probably possible to
  poll for the existence of a browser window, but I can't think of a
  way of doing it that doesn't impact battery life and doesn't
  introduce a potential race condition.)


Browser has normally several processes in the device:
- The UI, which is prestarted
- The master browser daemon which provides it's clients
  with app specific browser daemon instances
- Browser daemon instance for the browser UI
- Browser daemon instance for the messaging UI

The UI pre-starting is controlled from the browser .desktop file.
Comment out the prestart line there and kill browser UI to get
rid of it.

Application specific browser daemon instances are started by a request
from the app to the master daemon.  To get rid all of those daemons,
make sure those apps are not prestarted and kill the apps.

Browser master daemon is started during the X session startup and
restarted by the dsme SW watchdog when it exits.  To make it go
away, use:
dsmetool -k "/usr/sbin/browserd -d"

If master browser daemon isn't running, I don't think normal Browser UI
or messaging UI to work (they open, but their windows lack useful
content...) though.


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

Re: Maemo extras repository package uploader/maintainer verification?

[Eero Tamminen]

Hi,

ext Marcin Juszkiewicz wrote:

Dnia piątek, 22 stycznia 2010 o 14:03:18 Andrew Flegg napisał(a):
On Fri, Jan 22, 2010 at 12:59, Simon Pickering  

wrote:

I'd suggest that the autobuilder checks to see that the uploader's email
address is included in one of the *Maintainer fields; but there is the
slight problem of what happens when someone is uploading someone else's
package (e.g. as a favour when they are away from a build machine)?

There's also packages which are maintained by a team but uploaded by
an individual.


There must be somebody who is responsible for the uploaded package and
some way to contact him.  The uploader must have somehow verified that
the package isn't e.g. malicious (even if it's just taken from a trusted
source).

If it's a team, they might even share the ssh-key.  But I think it would
be better to have some configuration thing where Maintainer can grant
upload rights for his package to others he trusts.


Let's take the hypothetical case of there being a malicious Garage
developer and somebody finds that e.g. his funny fart app is actually
a trojan.  How we can identify and check what else that person has
uploaded to Maemo repos?  After there's notification about the issue
to users, how they can check whether the specific version of a foobar
applications they've downloaded from the extras isn't actually uploaded
by this suspicious person?

The maintainer field gives users some trust: "Oh, this app is
from the same maintainer / uploader as all these other nice apps, so
I can trust it".  If the maintainer field isn't validated in anyway,
this trust is misplaced.


Sure, but iirc Debian handles it by having Maintainer and Uploaders fields. 


Sounds a good idea.  I think maintainer fields should still be checked
as that's what's presented to users, not Uploader field.


From my point of view Maemo packages should have Maintainer field changed even 
when there is no changes in Debian package (other then recompilation).


Why? Simple - how original maintainer can maintain package on platform unknown 
to him? On system which is not Debian even...


Agree 100%.


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

Re: Maemo extras repository package uploader/maintainer verification?

[Eero Tamminen]

Hi,

ext Jeremiah Foster wrote:

On Jan 22, 2010, at 11:49 AM, Eero Tamminen wrote:

I was recently notified that in extras repository some package for
which I've been marked as maintainer, was causing an SSU (testing)
issue.

However, I hadn't uploaded that package.

The package was from SDK tools repository were I was the correct contact
person for that package.  The package in Extras had the same version,
but not the same size i.e. it was modified (or at least different).


What checks there are in place to verify that the package uploader and
the package maintainer field (shown to people who install the packages)
match?


I think Niels has a check for that in the QA software he has written,
in fact, I am certain of it. :) This check does not currently default
to stopping the incorrect uploader / maintainer from uploading the package.
It is possible to change this behavior and I think in the future this check
will default to stopping package uploads that do not have the correct
maintainer information.

Unfortunately, people do not change the maintainer field of the packages
they upload very often, this is a big problem.


Sorry, I didn't understand this.  If one is the principal maintainer
(uploads the package often), why putting one's name to the maintainer
field is a big problem?



But stopping everyone without warning is not the solution. I think we
will move towards stricter testing however in the near future, but final
decisions should be discussed with Niels.


There needs to be some way to contact people who have uploaded
problematic packages to the repository.  How that works now?



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

Maemo extras repository package uploader/maintainer verification?

[Eero Tamminen]

Hi,

I was recently notified that in extras repository some package for
which I've been marked as maintainer, was causing an SSU (testing)
issue.

However, I hadn't uploaded that package.

The package was from SDK tools repository were I was the correct contact
person for that package.  The package in Extras had the same version,
but not the same size i.e. it was modified (or at least different).


What checks there are in place to verify that the package uploader and
the package maintainer field (shown to people who install the packages)
match?


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

Re: Backwards compatibility broken PR1.1 SDK

[Eero Tamminen]

Hi,

Stoppa Igor (Nokia-D/Helsinki) wrote:
This really isn't hard!  For the vast majority of applications there is no 
reason at all why they cannot be built against the first software release and 
install on all later releases, taking advantage of the bug fixes made since.  
I have been doing that for GPE since the first Maemo release.  That is what 
the autobuilder should be doing by default -- no need to make life hard for 
users **by default**!


Building is not so much my concern, but rather testing: what is going to 
be the accepted environment for approving and releasing a new version of 
your sw? Hopefully not the first sales release.


Although SW would be built against the shared libraries from the initial
release, they should of course be tested against the latest release.

If the software doesn't work in the latest release because minor Maemo
update broke binary _backwards_ compatibility in some library, only then
it needs a separate build (also) for latest release SW libraries.


One of the problems is that we don't have any automated thing that would
report about ABI incompatibilities between shared library version.  This
would also tell developers who've integrated an application to first
release, to build and check it against a latest one because it had
a binary incompatible change for one of their direct dependencies.


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

Re: Disable portrait support for dialog with Hildon

[Eero Tamminen]

Hi,

ext Cornelius Hald wrote:

On Thu, 2009-10-29 at 17:31 +0100, Piñeiro wrote:

From: Cornelius Hald 


the main window of my app supports portrait mode. Now I have a settings
dialog which does not support portrait mode but it inherits those flags
from the main window.

So you'll have the main window in portrait mode, and there is a
possibility that a dialog in non-portrait mode appear?


No, the dialog is only accessible in landscape mode. But if the dialog
is open, I want it to stay in landscape mode.


I'm not a expert in usability, but this would be confusing for me, and
it would force me to rotate 90 degrees the device in order to read
properly the dialog.

There isn't any possibility to support the portrait mode in the
dialog?


Of course there is, but the dialog does not make much sense in portrait
mode because it also contains text fields. And of course it's additional
work.


Several other possible solutions.

* Change to portrait mode support of the parent window before showing
  the dialog.

* Change settings dialog to a settings window.

* Remove settings option from the main window menu when it's in
  portrait mode.

I think last would be nicest solution.


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

Re: gtk clutter tearing

[Eero Tamminen]

Hi,

ext Frantisek Dufka wrote:

Recent
hildon-desktop versions disable compositing automatically for fullscreen
windows, unless you use HildonStackableWindow (which requires the
sliding animation).


I wonder what happens to translucent information messages (charger 
attached/removed, ...) in fullscreen SDL applications, are these not 
shown when compositing is off or are they done in different way and 
still shown?


hildon-desktop automatically switches to composited mode when needed.

(Making this transition without a temporary user visible visual
"glitch", has taken quite a bit of effort, AFAIK including fixes to
upstream X server too.)


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

Re: gtk clutter tearing

[Eero Tamminen]

Hi,

ext Michael Cronenworth wrote:

Eero Tamminen on 12/30/2009 04:09 AM wrote:

Incorrect.


I guess there's some illegal black magic happening in-between compiz and 
apps regardless of UI toolkit libraries. Apps such as dasher that 
present rectangles and text at fast speeds do not present any tearing 
when I have the *compositor* set to vsync. Firefox with the SmoothWheel 
extension for liquid smooth scrolling is tear free until I turn vsync 
off on the *compositor*.


If the related toolkit updates gets into same boxed XDamage event going
to the compositor and compositor blocks X updates to the composite
buffer while compositing it to screen, you don't get tearing.  In
practice this may be enough, especially on faster machines, but
I think it's more due to fortunate co-incidences than something
really being guaranteed by the (current Gtk) toolkit.


> My own apps are tear free until I turn off..
> you get the point, I hope.

Try for example pannable Gtk treeview with your own cell renderer
and add some suitable wait into that renderer to make sure that your
renderers' window update gets timewise separated from rest of
the treeview update and see whether you get tearing.


Of course, I could get into a technical acronym-fest with you, but that 
wouldn't be very helpful as real world examples would.


 > If application updates to it's composite buffer aren't
 > in sync with the compositor display updates, there's obviously
 > a possibility for tearing.

I don't think you understand how X works. :)


Hm. Do you? :-)


- Eero

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

Re: gtk clutter tearing

[Eero Tamminen]

Hi,

ext Xavier Bestel wrote:
>> But where inside the application process they happen (app or Gtk code)
>> is not so important.  The issue is that Gtk (AFAIK) has no mechanism to
>> synchronize this drawing with the compositor and doesn't offer
>> applications any mechanism for it either.  If painting/redrawing
>> takes too long (there's some delay between the X draw commands due
>> to what application does internally), it doesn't go the the same boxed
>> XDamage event to the compositor.
> 
> AFAIK GTK+ redraws are double-buffered, so if it takes too long to
> redraw a frame it's simply delayed until the next one.

That double buffering overhead is used to get rid of flickering
resulting from successive clear+draw operations, (AFAIK) it's not
whole window buffer (for obvious memory usage reasons), so it's not
relevant for the tearing issue.


- Eero

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

Re: /usr/local

[Eero Tamminen]

Hi,

ext Thomas Tanner wrote:
> sorry for my ignorance - I've only recently started following the
> optification discussion.
> 
> Is there any good reason why Maemo does not follow the standard UNIX
> layout with user applications in /usr/local ?
> /usr/local seems to be in all search paths and if /usr/local
> would be just a symlink to /home/local there would be no need
> for further symlink tricks.

According to the filesystem hierarchy standard, /usr/local is for
things that are NOT tracked by system package management:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY

Whereas /opt is standardized place for 3rd party software:
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

I haven't looked what maemo-optify exactly does, but I think
the standard compliant way would be to install package contents
to /opt// (with ./configure --prefix).  The .desktop file
will tell to invoke the /opt binaries from a correct place.
If autotools doesn't automatically put things like icons and
.desktop files to correct place, those could have symlinks to
rootfs.

Problematic issues would be how to deal with shared libraries,
for those symlinks would probably be still the best option.
I mean, adding symlink to /opt/lib and having that in $LD_LIBRARY_PATH,
not symlinking the libs to rootfs.

Direct invocations of binaries from scripts could also be problematic.
For those there could be a symlink to /opt/bin and that could be
in $PATH.


- Eero

(And if somebody would want more space for applications than is
available on /home partition, he could change the /opt symlink to
point to a memory card with suitable file system and prepare for
the issues resulting from having programs on removable media...)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: gtk clutter tearing

[Eero Tamminen]

Hi,

ext Claudio Saavedra wrote:
> El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
>> This is not really 
>> fixable due to how Gtk painting is arranged, parts of the window are
>> painted in application callbacks. 
> 
> This is not totally correct. Application callbacks can only cause GTK+
> to *invalidate* regions. In sane code, redrawing *never* happens in a
> user callback but only in expose event callbacks, which are triggered by
> GTK+ *only* when the time for redrawing comes.

Application (expose event) callbacks implement painting for
application's own widgets and treeview cell renderers.

But where inside the application process they happen (app or Gtk code)
is not so important.  The issue is that Gtk (AFAIK) has no mechanism to
synchronize this drawing with the compositor and doesn't offer
applications any mechanism for it either.  If painting/redrawing
takes too long (there's some delay between the X draw commands due
to what application does internally), it doesn't go the the same boxed
XDamage event to the compositor.


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

Re: gtk clutter tearing

[Eero Tamminen]

Hi,

ext Michael Cronenworth wrote:
> Eero Tamminen on 12/29/2009 09:17 AM wrote:
>> because Gtk doesn't have any support for Vsync.
> 
> Gtk doesn't need to support Vsync. Qt won't magically fix this problem 
> either.
> 
> Only the compositor needs to support Vsync. Once it does then *all* 2D 
> operations will be tear-free. Gtk, Qt, terminal-based, etc.

Incorrect.  If application updates to it's composite buffer aren't
in sync with the compositor display updates, there's obviously
a possibility for tearing.

In practice, if application callbacks paint their own parts fast enough
after Gtk does window scroll, they get in to same boxed XDamage event
and usually everything looks fine.  If they don't, there's tearing.
If Gtk happens to draw to its backbuffer while HW is compositing
(as requested by compositor), there's also tearing (whether it's visible
to user, depends on what's drawn).  I think compositor does either
input or server grab while compositing, so this might not be a problem.
Former can be though.

In summary, all of these three steps need to be synchronized for
tearing to be completely eliminated:
  app -> composite buffer -> framebuffer -> LCD

Synchronization means waiting / extra buffers so it will slow down
screen updates to some extent.  Any extra copying done for this would
have a large effect on performance because the device is memory
bandwidth constrained (like all computers nowadays), buffer swapping
is better in this respect.  But extra buffers mean increased memory
consumption (800x...@16-bit RGB surface is 750kB, at 32-bit RGBA
it's 1.5MB).


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

Re: gtk clutter tearing

[Eero Tamminen]

Hi,

ext Mark Clarkson wrote:
> I have made a simple animation using a clutter timeline with clutter-gtk-0.10 
> and clutter-1.0 but there is excessive tearing when the animation plays 
> making the animation look terrible.
> 
> I have tried none, dri and glx values for the CLUTTER_VBLANK environment 
> variable but this seems to have no effect at all.
> 
> Is there a way to fix this?

Screen update isn't yet synched to LCD refresh.  Please file a bug about
it to bugs.maemo.org (it needs support from kernel display driver, X
server, SGX driver, Clutter and hildon-desktop compositor, but I guess
you could file it against Official platform -> Core -> X).

After this I think things should look fine in Clutter when app does
things right.  E.g. panning in normal applications can still tear though
because Gtk doesn't have any support for Vsync.  This is not really 
fixable due to how Gtk painting is arranged, parts of the window are
painted in application callbacks.  If application callback is fast
enough that it gets into same boxed damage event from X server (to
compositor) as the internal Gtk pannable area scroll, there's no
tearing, if it gets drawn later, then update for that part of the window
goes to screen on next compositor screen update.


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

Re: New optification issues in extras-testing

[Eero Tamminen]

Hi,

ext Andrew Flegg wrote:
>> "The application or its dependencies ignore the recommendation to
>> use the eMMC to install as much files as possible, filling the root
 >> partition with 500kb or more. "
>>
>> It does not say that the _sum_ of all dependencies has to be below 500k.
> 
> I agree, it looks ambiguous. The *intent* seems to be that installing
> an application shouldn't take up more than 500KB of the rootfs (your
> Python example on the package page is specious, BTW, as Python is now
> optified).
> 
> If the dependencies are used by lots of apps, and have separate
> maintainers; I can understand your point. However, since:
> 
>   * you maintain both libgoocanvas3 and osm2go
>   * neither are optified (according to the comments)
>   * I *imagine* there aren't lots of other apps depending on
> libgoocanvas3 which have been let through QA

Where this 500kB figure for these packages come from?

If it's uncompressed size, then it's bogus as the rootfs is compressed.

The script attachment here:
https://bugs.maemo.org/show_bug.cgi?id=5795

Tries to give a more realistic[1] estimate on how much space
a package actually takes from the rootfs.


- Eero

[1] Note that the documentation is removed with an apt hook.
If one installs package directly with dpkg to the device, this
hook doesn't get called.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Package Building HOWTO

[Eero Tamminen]

Hi,

ext Joseph Charpak wrote:
> On Tue, 2009-12-22 at 18:24 -0300, Jeff Moe wrote:
>> I have written up a Package Building HOWTO.
>>
>> You can find it here:
>> http://wiki.maemo.org/User:Jebba#Package_Building_HOWTO
>>
> 
> Looks good although I'd swap the order of compile for armel with compile
> for x86. First you compile for x86 and run the resulting app to see if
> it works in scratchbox.

I'd add here also testing for:
- install, remove & re-install package (maybe also upgrade)
- run lintian on the packages (outside of sbox) and fix relevant
   reported packaging issues:
 lintian *.deb
- test the software when run under Valgrind to see whether that
   reports any memory handling issues:
  fakeroot apt-get install valgrind maemo-debug scripts
  run-with-memcheck 
   (relevant for C & C++ code, not for interpreted stuff)


- Eero

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

Re: Debhelper 7

[Eero Tamminen]

Hi,

ext Jussi Hakala wrote:
> ext Anderson Lizardo wrote:
>> Now things might get complex if the packaging already uses some new
>> features of level 7, like those CDBS-like helper rules. In such cases,
>> looking at versions prior to the compatibility level upgrade might
>> help doing the downgrade (and most Debian packages are kept in public
>> SCMs like svn.debian.org).
> 
> You can also try the debian-squeeze devkit available from scratchbox.org.
> 
> Note that this is not (yet) supported by Fremantle SDK and you need to 
> create your scratchbox targets by hand instead of the installation 
> script, but should be enough to allow you to use debhelper 7.

But I think using something like that would require that Maemo
auto-builder supports it too...


- Eero

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

Re: Updating the info for Extras-devel non-free

[Eero Tamminen]

Hi,

ext Stephan Jaensch wrote:
> First of all, my viewpoint as a user: I want as many apps
> as possible. Choice is always good. I own an iPod Touch,
> and I can say with confidence that my criteria for selecting
> an app is always functionality, quality (hard to gauge since
> there is no "try before you buy", so I'm judging by user
> ratings for that) and price. As a user, I don't care about
> source code availability.

Without source code availability others cannot help in fixing
the bugs in the application or start maintaining the package
when the original package maintainer goes away (as they always
eventually will).

I.e. source code is some level of guarantee about the functionality
and quality being there for the long term, even if the author gets
other priorities.   If the software is such that you need to invest
time to learning it, then also long term matters.  If it's e.g. a
game that you'll play through once, then it's not so important.

Source code availability matters then more for the possibility of
being able to verify things that cannot be (easily) verified from
the binary alone (e.g. security, actual changes between versions etc).


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

Re: Double checking free/nonfree packages

[Eero Tamminen]

Hi,

ext Christopher Allan Webber wrote:
> For now there seem to be two main pages on which the documentation of
> what is free/nonfree is:
>  - 
> http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Top_Level_Architecture
>  - http://wiki.maemo.org/Why_the_closed_packages
> 
> The first contains that rather informative graph, but I suspect that the
> intended purpose of that page would be made less useful if we put all of
> the documentation of free/nonfree components on there.  The second one
> seems to be a good start,

I think main issue is that it's not really updated for Fremantle, a lot
of the stuff there would seem to be Diablo release specific...


> but I think the naming of that particular page
> helps defeat our purpose, as it seems to say "here is why these are
> closed" as just an explanation, and does not indicate "this is a record
> of pieces that we are working to free."  So, unless there are any
> objections, I think it would be better to start a page with a name such
> as Free_Maemo or something similar that indicates a kind of "free and
> open source todo-list" that I think everyone here seems to want.  I'll
> work on incorporating the "Why the closed packages" page within that
> document, and if that proves to be satisfactory, we can probably have
> the Why_the_closed_packages page redirect to the new one.


What about following page structure?

Index page:
* with explanation about:
   - Why it makes sense to open sources and what should
 be prioritized (the list below)
   - Why Nokia has some packages closed
 (top part of existing page)
* Link to page listing closed packages in Diablo
   (bottom part of existing page)
* Link to page listing closed packages in Fremantle
* Link to TODO list(s) about opening or replacing above packages
   with free alternatives


>> The criteria to prioritize components could be (improvising a bit, feel
>> free to suggest improvements):
>>
>> 1. Fixing a bug. I mean a real objective bug: package is in non-free
>> although it looks like it's actually an open piece of software.
>>
>> 2. Nurturing application development. There is a strong argument proving
>> that opening a component will bring more and better apps for end users.
>>
>> 3. Spread of Maemo driven technologies to other platforms. A component
>> fits well in a gap existing in other Linux/OSS based projects and there
>> is a concrete interest on collaborating and contributing to a component
>> if it's opened.
>>
>> 4. Community maintenance. A component is receiving low attention from
>> the official maintainers even if it has high attention from the
>> community and there are developers volunteering to contribute to it if
>> the source code is available.
>>
>> 5. Better architecture. Probably covered by 2 or 3 but just in case. A
>> closed component is sitting in the midle of open components making
>> things more difficult that needed to developers interested in that area.

Good list!


- Eero

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

Re: Extras Testing to Extras, again...

[Eero Tamminen]

Hi,

ext Aniello Del Sorbo wrote:
> I am sure I missed something... but what actions were taken to address
> this issue?
 >
> I do have Xournal pacakge 20 for more than 10 days with 6 thumbs up
> out of 10 (i.e. more than 50% of people voted OK).
> 
> I want to promote it to Extras.
> And I don't want to depend on others.
> 
> I REALLY would like to see a Promote to Extras earlier in the process.
> It's up to me to wait enough time so that people can test it.
> Again, what I think it's missing is something to vote after the
> packages has been promoted to Extras so that the bad ones can
> be pulled out.
> 
> If the fear is for malicious applications, then there's no way we can
> prevent those from going to Extras no matter how many days
> it's been in Testing.
> (a timer comes to mind).

I'm not really happy with this process either.

There should be some kind of checklist which people go through,
that has items like:

[x] Tested with "htop" + T (to sort output according to Time column)
 to see that application doesn't wakeup on the background and when
 screen is blanked (if the application time column doesn't
 increase during 10 mins).  CPU usage when application is visible,
 but not interacting with the user could also be checked.
 These require ssh connection to the device.

[x] Checked normal application memory usage with mem-monitor
 (from sp-memusage) on a freshly booted device and that it was
 below X MB as required for this class of applications
 (i.e. diff from before app started and when it is running).

[x] Used application for few hours with endurance snapshots (tool
 from sp-endurance package) being taken at regular intervals.
 The report generated from this data didn't show any
 (significant) resource leakage.

Random comments about things working for people are not really
useful if at least someone of them hasn't checked properly also
things that aren't immediately visible to the user (effect on
battery usage and general device stability over longer period
of time etc).


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

Re: Bug#6203, rotation and OHMD

[Eero Tamminen]

Hi,

ext Martin Grimme wrote:
> How about another XAtom (since we already have so many on Maemo ;) )
> on the application window, saying "I rotate well and quickly." ?
> 
> The ohmd could take care of this atom and refrain from freezing the
> app during rotation, iff it is the currently visible one.
> 
> Of course applications could lie about their rotation capabilities,
> but that's what we have the extras-testing Q&A for.

The rotation case is a minor issue and I think it can be handled OK
for unknown applications without this kind of kludges.  Let's just
hope we can get a fix for that included to the next release.

The main issue with policy is handling of unknown processes in
general and for that more feedback is needed.


(A hint: MAFW is a known system service, so it's good to use
that for music playback...  Tracker use is a bit more problematic
because it's resource usage can fluctuate pretty much according
to content it processes and what kind of requests it gets.  And
policy daemon doesn't currently know whether foreground application
needs tracker or not.)


- Eero

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

Re: Bug#6203, rotation and OHMD

[Eero Tamminen]

Hi,

ext Aniello Del Sorbo wrote:
> why don't you guys simply allow only the foremost (i.e. the currently
> visible one)
> application to rotate and send the rotation event to the other apps
> AFTER the animation has completed.

Background applications don't get the rotation / redraw messages at all.
You can check this with xresponse and/or xev.

(Fixing that in X and composite/window manager required a lot of work,
but AFAIK applicable parts of this work are now in upstream.)


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

Re: Bug#6203, rotation and OHMD

[Eero Tamminen]

Hi,

ext Eugene Antimirov wrote:
>> It handles also audio policies and tries to make sure that you get
>> your phone calls when the device is heavily loaded and some other
>> minor things.
> 
> Just to know.
 >
> I see now this `ohmd` process in my 41-10. I did not get it, was this
> daemon improved or made worse in new firmware released lately?

Better for known (pre-installed) applications, worse for unknown
applications.  The reason for this is that unknown applications have
unknown resource usage so system policy treats them with more care.


It's a bit of a chicken and egg problem.  Changing the policy is slow
iterative work requiring lots of testing that the policy change doesn't
significantly worsen other use-cases in some situations (e.g. for things
for which there are certain certification & legal requirements).

Developers can now experiment and report/discuss things which they would
like policy to handle better (for certain classes of 3rd applications
and their use-cases). I.e. in regards to 3rd party applications, the
policies could be considered work-in-progress.


Things that could potentially be done for 3rd party applications
policy handling:

- Default policy is improved in regards to unknown processes.
   It's yet unknown whether this can be done well enough without
   sacrificing the known functionality, that's why feedback is needed
   on the behavior of 3rd party application use-cases.

- Applications themselves specify the required policy on install.
   This is extra work for apps, and requires extensive testing to
   guarantee that the policy they choose is good match for
   the application in all cases. (application doesn't leak or
   otherwise hog resources)

- Some way for user to specify per-application policy.
   I'm sure power-users would like that... :-)


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

Re: The issue of version strings / improving Application manager view

[Eero Tamminen]

Hi,

Kallioinen Juha (Nokia-D/Helsinki) wrote:
> The problem is imho the Application manager, not the version numbers.
> 
> What's the point of even displaying the version number in the Application 
> manager's default view? I personally don't care about the version at all and 
> I certainly won't remember if an application's version has been updated by 
> looking at the list view. Am I alone with this opinion? Why do you need to 
> see the version there? The update manager will gladly tell me if I have an 
> older version installed and if I don't, won't I just install whatever the 
> Application manager offers me?

The alpha/beta/stable status would be interesting.

I.e. is this a bugfix release or one with new buggy features?


> The package version can anyways be found from the package details page, 
> where there's more space available for it too.

A link to package page that opens Browser would be best I think.


> A much more interesting bit of data instead of the package version to be 
> shown by default might be the date when the package was uploaded. Also the 
> Application manager could use a 'show new packages' view.
> 
> But these of course require changes to the Application manager and maybe 
> even to apt/dpkg database to be able to show the package's date and are more 
> difficult to implement than just making nicer version numbers.
> 
> Maybe a nice version number could really just be the date the package was 
> created. That would fulfill my first wish, but we'd lose the upstream 
> version trackability :)


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

Re: Bug#6203, rotation and OHMD

[Eero Tamminen]

Hi,

ext Aniello Del Sorbo wrote:
>>> Is the purpose of OHMD ONLY to pause not whitelisted applications when
>>> rotating?
 >>>
>>> As if it is so, I'd put a "stop ohmd" every time I run Xournal to make
>>> sure it rotates smoothly.
 >>
>> It handles also audio policies and tries to make sure that you get
>> your phone calls when the device is heavily loaded and some other
>> minor things.
> 
> Not something you may want to stop then.
> 
> I'll wait for a fix.

The policy configuration is in:
/usr/share/policy/etc/current/syspart.conf

As a temporary hack for your own device, you might try to modify
that file as root and then do "killall ohmd" to restart it with
the new policy.

This way you get to decide what has the priority instead of it
being dictated by Nokia. :-)

In future there may be some way to install extra policies.


NOTE: if this conf file has errors, ohmd isn't started and your
device will most likely behave strangely as result (cannot play
music etc).

DISCLAIMER: if it breaks, you get to keep all the pieces.
I.e. have an up to date backup of your data and be ready to
reflash in the case that things really break.  Modified policy
is an untested configuration.


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

Re: Bug#6203, rotation and OHMD

[Eero Tamminen]

Hi,

ext Aniello Del Sorbo wrote:
> according to bug 6203 (https://bugs.maemo.org/show_bug.cgi?id=6203)
> Nokia introduced this "ohmd" daemon that
> pauses applications not whitelisted so that the rotation itself would
> proceed smoothly.
> 
> In the meanwhile Collabora had fixed and improved a lot rotation
> itself, so that this "pausing" is not needed anymore.
> In fact, it make thinks worse.
> 
> Is the purpose of OHMD ONLY to pause not whitelisted applications when 
> rotating?
> As if it is so, I'd put a "stop ohmd" every time I run Xournal to make
> sure it rotates smoothly.

It handles also audio policies and tries to make sure that you get
your phone calls when the device is heavily loaded and some other
minor things.


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

Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))

[Eero Tamminen]

Hi,

ext Anderson Lizardo wrote:
> On Tue, Nov 10, 2009 at 12:11 PM, Andrew Flegg  wrote:
>> On Tue, Nov 10, 2009 at 16:00, Anderson Lizardo
>>  wrote:
>>> The PyMaemo team is pleased to announce the final release of PyMaemo
>>> for Maemo 5!
>> BTW, I've tested with bind mounts and /opt.
>> [...]
> 
> Nice to hear that! We decided to leave out the optification for the
> final release, just not to delay it even more. But now I believe we
> can work on it as an update through extras-devel (I just hope that
> that QA process will take any possible regressions with the new
> packages we upload).
> 
>> I've done the following and it seems to work well:
>>
>>   * Created /opt/python2.5/lib
>>   * Moved the contents of /usr/lib/python2.5 to /opt/python2.5/lib
>>   * Created an init script, symlinked to S20python-optify, which does
>> (on start):
>>
>>mount --bind /opt/python2.5/lib /usr/lib/python2.5
>>
>> This freed up lots of space on the rootfs and does not seem to have
>> impacted start-up time of Python apps particularly noticably.
>>
>> I can share the startup/shutdown script and maybe even package this as
>> a "Python Optifier" if you want.
> 
> Do you think it can be made a generic dh_* like tool that handles this
> automatically? This way it could be called from debian/rules as e.g.:
> 
> maemo-python-optify /usr/lib/python2.5
> 
> and the init scripts be generated automatically. What do you think?

Are you suggesting that each python package would themselves do
the bind mount?  And hide anything that was before in that directory?

Saner solution is that the bind mount is done by something from which
the package depends from (be it python package itself or something
else).


>> I think this is one of the best ways of optifying Python and without
>> any patches. I'd suggest this gets included in the next release of
>> PyMaemo.
> 
> Did you do any kind of upgrade tests? I'm worried how that would work
> if you are upgrading from an older non-optitified python installation.
> 
> I also suppose that this implicitly moves files from other packages to
> /opt/python2.5 ? E.g. from python-hildon, python-gtk2 etc. ?
> 
> What about the /usr/bin/python2.5 binary (which takes some MB) did you
> move it to /opt too?


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

Re: Why should it be so hard and should I even bother with Extras for fremantle?

[Eero Tamminen]

Hi,

ext Andrew Flegg wrote:
> On Mon, Nov 2, 2009 at 10:47, Marius Vollmer  wrote:
>> ext Jeremiah Foster  writes:
>>
>>> Then Application Manager has to change. It does not scale to have
>>> categories when there are thousands of apps.
>> Yes, this is overdue.  We also need a way to handle application specific
>> add-ons, like language packs.
> 
> Instead of debtags, the subsection approach of
> user/network/command-line (or user/network/advanced) could solve both
> problems in one.

I don't understand why CLI tools need any specific section.

That just makes porting (re-compiling) them from Debian more hassle.

The value of being able to install them from AM GUI in addition to using
"apt-get install" on command line seems also dubious (especially
if one has installed Bash and package name completion).


Current user/* category should be used for normal, end-user visible
UI applications.

If AM support for CLI utility installation is really needed, I would
propose an option for AM like:
[ ] List non-UI/command line utilities

Then enabling that in AM would get one also categories which don't start
with "user/".

I think AM should still skip showing library packages.  They should
get pulled in by the applications and utilities when needed, one usually
doesn't need a library in itself...


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

Re: Call for testers with N900 for vncviewer

[Eero Tamminen]

Hi,

ext ds wrote:
> Am Dienstag, den 20.10.2009, 20:08 +0200 schrieb Cornelius Hald: 
>> On Tue, 2009-10-20 at 15:01 +0200, ds wrote:
>>> I have no feeling for N900 at the moment. But yes, I have some feature
>>> requests left on garage, and as there is not too much UI it should not
>>> be a big deal:-)
>>>
>>> But first I want to have it running an the N900.
>> I got it working now :) Attached is a screenshot (in case the list
>> allows that).
> 
> Thanks, at least my copy allowed it! 
>> Getting the UI Fremantle conform should be straight forward, at least it
>> looks like that to me. If you need help there, just tell me.
>>
> I got a message from maemo admin:
> After disabling the toolbar and switching to fullscreen mode there seems
> to be no way get out of full screen or getting the toolbar back.
> 
> Can you confirm this? Is no Hardwarebutton bringing up the menu or
> toggle full screen anymore?

Correct.  I would suggest supporting additional shortcut like Ctrl-f as
proposed in another mail.


- Eero

PS. User can switch to other apps by using the Ctrl-backspace shortcut
for the task switcher (or by launching Camera app with the camera button
or closing the application from the power menu "End task" button).
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Considering /opt and MyDocs in your packages

[Eero Tamminen]

Hi,

ext Graham Cobb wrote:
> On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote:
> By the way, I have been experimenting with maemo-optify.  I think it is 
> currently generating too many links for quite small files.

All files, even symlinks, take some space.  On UBIFS single file
overhead is about 1/4 KB (inodes + filename).


> I think 20K would 
> be a better default for the size and, if feasible, I would like to see the 
> size settable as an option on the command line, to allow the developer to 
> tune it for their particular package.

As UBIFS compresses the file contents[1] with LZO, it's the lzop
  compressed file sizes which should be used for this kind of decision.

Does maemo-optify compare the lzop'ed or non-compressed ones file sizes?


- Eero

[1] /opt is on ext3 which isn't compressed.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: N800 Power cycles

[Eero Tamminen]

Hi,

ext Rainer Dorsch wrote:
> I run into the power cycles problem again (w/o having added the text2screen 
> output, but I will try that now). I observed two things:
> -> I had to remove the battery to get out of the power cycles loop
> -> after removing the battery and normal bootup (w/o power supply plugged) I 
> found in the /var/lib/dsme/stats/ files
> 
> Nokia-N800-23-14:/var/lib/dsme/stats#

You don't have the latest release?


  for f in *; do echo $f:; cat $f; done
> 32wd_to:
> 4
> lifeguard_restarts:
> /usr/bin/hildon-input-method  :  5
> /usr/sbin/ke-recv :  5
> /usr/sbin/multimediad  :  7
> /usr/bin/esd :  8
> /usr/bin/osso-media-server  :  3
> /usr/sbin/dsp_dld -p --disable-restart -c /lib/dsp/dsp_dld_avs.conf :  7 *
> /usr/bin/hildon-desktop  :  3
> /sbin/mce --force-syslog  : 1
> sw_rst:
> 4
> Nokia-N800-23-14:/var/lib/dsme/stats#
> 
> Does the * behind 
>   /usr/sbin/dsp_dld -p --disable-restart -c /lib/dsp/dsp_dld_avs.conf :  
> 7 *
> mean, that caused the last reboot?

Yes, I think so.


> What is /usr/sbin/dsp doing?

AFAIK dsp_dld loads the DSP programs to DSP.  That needs to be re-done
after the DSP is reseted (which gets done when there's some issue with
the DSP side).


> Does removing the battery change anything in this area?


- Eero

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

Re: Howto correctly place data on the memory card?

[Eero Tamminen]

Hi,

ext Till Harbaum / Lists wrote:
> Am Montag 22 Juni 2009 schrieb Kimmo Hämäläinen:
>> Use MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT environment variables,
>> available since Nokia 770 Internet Tablet.  I'm not sure about
>> Scratchbox, since it does not have memory card emulation.
> The scratchbox doesn't have this which is perfectly fine as i'll then just 
> fall
> back to using $HOME.
> 
> But i still have a major problem with this: It doesn't work in the
> debian/postinst script when running the application installer.
> 
> I simply added a call to "env" to my postinst script to be able to see the
> environment bein used in the application installers log. See below the
> log i get on my n810. It seems that the worker thread of the app manager that
> deals with this has been started before the environment was complete.
> So there are no MMC related entries at all which makes this useless to 
> install data on the memory card.
> 
> So please let me re-phrase my question: How does a postinst script know
> where the memory card is?

I guess the script could get (source) the information
from /etc/osso-af-init/af-defines.sh file?


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

Re: Autobuilder and build-dependencies from extras-devel

[Eero Tamminen]

Hi,

ext Ed Bartosh wrote:
>> I haven't used the autobuilder.  Is it possible to see how many/what
>> packages are in the queue?
>>
>> (if there are lot and/or large/slow to build packages, one would
>> know not to wait anything to happen very soon...)
>>
> Unfortunately there is no such a possiblility. Autobuilder doesn't
> have any web interface at all. You can only see build results and logs
> after build is finished. However, considering the fact that we have
> only one builder machine even if users would know how many packages in
> the queue it wouldn't help them much. What would help is to know which
> packages are being built at the moment + amount of packages waiting in
> the queue.

Thanks!  I guess there's no way dput could tell that information?


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

Re: Autobuilder and build-dependencies from extras-devel

[Eero Tamminen]

Hi,

ext Ed Bartosh wrote:
> 2009/6/24 Henrik Hedberg :
>> 1. Upload your library into the extras assistant
>> 2. Wait unspecified time (usually at least ten minutes)
>> 3. See if the build succeeded. If not, go to 1.
>> 4. Wait unspecified time (one hour perhaps) until the library is
>> actually in the extras-devel.
>> 5. Upload your application into the extras assistant.
>> 6. Wait unspecified time (usually at least ten minutes)
>> 7. See if the build succeeded. If not, go to 5.
>> 8. Wait unspecified time (one hour perhaps) until the application is
>> actually in the extras-devel.
>> 9. Promote the library and the application to the extras.
>> 10. Wait unspecified time (one hour perhaps) until the library and the
>> application is actually in the extras.
>> 11. Announce the new version of your application to users.
>>
>> How many hours is 1 -> 10?
>>
>>Is there any possibility to make this time shorter?
>>
> Sure! We just need to think about it and we'll found how to do this. I
> explained my ideas above. You can share yours.

I haven't used the autobuilder.  Is it possible to see how many/what
packages are in the queue?

(if there are lot and/or large/slow to build packages, one would
know not to wait anything to happen very soon...)


- Eero

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

Re: Optimal battery life considerations in apps

[Eero Tamminen]

Hi,

ext Henrik Hedberg wrote:
> There is a standard X event for that: XVisibilityEvent. The X server 
> (and a window manager) can keep window contents cached (backing store) 
> and decide not to send exposure events, but my interpretation is that if 
> it is not sending visibility events it is broken (and it is currently as 
> I showed in my earlier post).

This is not the case with Compositing enabled (Maemo 5).
Only compositing manager can know whether something is visible,
X cannot.  I think there's an extra API provided for that in
Maemo 5.


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

Re: N800 Power cycles

[Eero Tamminen]

Hi,

ext Rainer Dorsch wrote:
>> I modified that too
>>
>> if [ x"$bootreason" = x"charger" ]; then
>> echo "Showing the 'charger connected' image"
>> /usr/bin/fb-chaimage -l
>> /usr/share/images/qgn_indi_charger_connection_detected -b 0 -c -p 0 -s 15 &
>> else
>>   text2screen -t "Bootreason: `cat /proc/bootreason`" -H center -y
>> 360 -s 6 -B 0x
>> fi
>>
>> This way I have at least some information when I run in that problem next
>> time.
>>
>> Is there any other debug information which would be useful to print?

maybe statistics from /var/lib/dsme/stats/ files?


>> Is
>> there a way (by changing linuxrc further) to get a lot more information
>> during boot instead of the nice but almost informationfree image?

Using the text2screen utility above?


> I just noticed that I cannot write that file, the fs is mounted readonly:
> 
> /dev/root on /mnt/initfs type jffs2 (ro)
> 
> If I remount it rw
> 
> mount -o remount,rw /mnt/initfs
> 
> to do the change, would that break something?

Initfs may be too full for changes.  You need to remove things first
(e.g. initfs factory test stuff you can "find -name '*test*'").


- Eero

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

Re: N800 Power cycles

[Eero Tamminen]

Hi,

ext Rainer Dorsch wrote:
> One thing I noticed and maybe I did not highlight that enough:
> -> yesterday in the boot loops, the N800 started itself after I plugged the 
> powersupply (no matter if I removed the battery before or not).
> -> today plugging the power supply does not start the N800 anymore, just 
> showing that it is charging the battery
> 
> Under which circumstances is the N800 started automatically, when the power 
> supply is plugged in?

Always.  It will then go to Charging mode.

If you in that state:
- unplug the charger -> device powers down.
- press power key -> device comes fully up.


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

Re: N800 Power cycles

[Eero Tamminen]

Hi,

ext Rainer Dorsch wrote:
>> my N800 crashed after running navit. During the reboot, the blue bar
>> completed, then it paused sometime and it rebooted again. This now cycles
>> so that the N800 is doing nothing else than power cycling.

With which OS version this is?


>> Is there a better way to fix that than reflashing the device?

For normal users, no.


>> Is there a way to find out what the root cause of the problem is?

If the device eventually boots up and you had syslog installed and
free disk space, then yes.  Otherwise you'd need serial access.


>> Can R&D mode help to be more verbose during the boot process?
>>
> 
> Weired, after waiting a few hours and booting the N800 w/o a power cable, it 
> booted again.

In this case I assume the reason for the boot loop was that "navit"
(what is that?) "trashed" your rootfs contents in a very fragmented way
so that JFFS2 mounting[1] took too long (>1/2min without kicking
the watchdog) & triggered the HW watchdog.

[1] The reason why I asked about OS version is that in very old releases
JFFS2 garbage collecting could also happen at mount time which could
take a lot of time.  In later releases it's postponed.


> Are there any logs which show what went wrong before?
> 
> Can I do something to better protect myself against such "boot loops"?

Avoid SW that can fill your rootfs, runs as root and doesn't
have proper error handling for disk writes (remove data if
disk fills up, have strict limits on log etc file sizes etc).
If something *running as root* fills the rootfs, your device
is in boot-loop and needs to be reflashed.

Explanation:
The device needs a small amount of free space at bootup (JFFS2 needs
some space even to remove data), otherwise it doesn't boot.  There
should be enough allocated for "root" for this purpose ("user" cannot
fill it, only root can).  However if a bad process running as root is
installed that fills disk, or *anything* you install (installation
happens as root) has badly behaving package install scripts, you can
get screwed.

Because this kind of issue may happen e.g. only in an uncommon
error situations, normal testing might not catch them.

Everything pre-installed to the device should behave fine, but
3rd party packages can do funny things.  I'd suggest taking
backups at least before installing something that's not widely
used.


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

Re: Unsatisfied with bugs.maemo.org

[Eero Tamminen]

Hi,

ext Till Harbaum / Lists wrote:
> sorry, but i don't get your point. You say that you'd need tests and things
> for the themeing and thus you don't do it at all? You mean it's acceptible
> to not theme them at all and have them look ugly but it's not acceptible
> to give them a quick/untested themeing? Why?

To theme something, there needs to be something on which it can be
tested.  You cannot have a theme for something that doesn't exist
on the device (from a graphics artist point of view).

UI & graphics design is something that starts much earlier than SW
development and it moves to future releases much earlier than
the SW develoment / bugfixing.  By the time there's a public release
and public bugs based on it, I don't think there's anymore anybody
allocated to do graphics work for that particular release.


> You basically say "either we do things perfectly or we do them in
> the worse possible way".

UI designers aren't clairvoyant.  They don't know what specific thing
community will want to have been themed few years later.

Bugs for previous releases could of course be used as input for this
(still needs a test SW though!), but they don't always exist or be
appropriate and I don't think that has really been done for graphics
like it was done for SW and some UI issues. So, we should improve here.

With Fremantle we've started providing regular pre-releases so that
things like this can be tested by the community before the release,
when there's still time to do also feature requests & non-critical
fixes for that release.

(With the pre-releases you won't see final graphics, but at least it can
be tested whether some widget is lacking themeing.)


> I'd say:
> If you don't support that feature, then remove it entirely from the libs 

That would be making them deliberately API & ABI incompatible which
would kind of make moot the point of using open source components.
So, no.


> and from the api docs. But distributing a library containing stuff you just 
> won't support is pretty odd.

But I think it would be appropriate to note in API documents which
widgets aren't supported by our UI guidelines / with themeing.

Can you make a bug about that so that can be fixed for Fremantle
(or Harmattan) API docs?


> You could avoid a lot of internal testing if you'd actually make use of
> the fact that bugs.maemo.org gives you a bunch of external testers.
> Actually that's what happening here: You provide a library containing
> functionality that is incomplete and untested.  And the community did 
> the testing for you and now tells you that what you deliver is incomplete.

For graphics the testing needs to happen way before public release
of the device.  Unfortunately before Fremantle that wasn't possible.


> And what do you mean by wanting this to be a community project?
> Is there an easy way the community can replace nokia provided core
> libraries and theme files?  Or do you suggest people should switch to mer
> if they are unsatisfied with some half-hearted nokia implementation? 

As the bug is wontfix for Diablo, obviously the only alternative for
Diablo is something done by the community.  Maybe a new theme based
on the default themes on which the app requiring it depends on?
Gil, does our theme license allows derivatives?

For Fremantle and later releases, community can provide information
and working test-cases (applications) for what additional
widgets/features should be themed.


> You say you only fix those features that are actually a problem 
> for your own product and you don't care  for widgets that are "only" 
> used by third party applications. Are you serious? Nokia really isn't 
> interested
> in supporting third party apps?

I was saying that UI designers and graphics artists can fix only
problems that they know about, and only if they get to know about
them when they still have time to do something about that.  Which
in case of theme graphics unfortunately is way before the product
is released.


 > Support is only provided if there's also
 > a benefit for nokias own applications? Wow ...

You can test whether something works, only if you have something
that you can test it with.  Should be obvious. :-)


- Eero

PS. It was really annoying/frustrating (not only for 3rd parties,
but Nokia developers too) that in earlier products we didn't have 
regular pre-releases which mean that by the time people were able
to test the software and file bugs about it, there wasn't anymore
much that could be done about it e.g. feature-wise.  Things are
much better now with Fremantle.


> Till
> 
> Am Freitag 05 Juni 2009 schrieb Eero Tamminen:
>> Bug 4630 & 1504 are about themeing a single Gtk widget aspect.
>>

Re: Multiple instances of Maemo

[Eero Tamminen]

Hi,

ext Graham Cobb wrote:
> On Thursday 04 June 2009 20:11:41 Qole wrote:
>> I've asked a similar question before. It seems that maemo-launcher can only
>> have one instance running at a time, so that effectively limits the number
>> of Hildon desktops that can be running to one as well.
> 
> The answer is to run each one in a separate virtual machine environment.  
> This 
> is also useful for keeping scratchbox instances separate for doing things 
> like compilations against different SDK versions at the same time (scratchbox 
> insists that only one target is running on a single machine at a time).
> 
> This can be done using full virtualisation environments like VMware or Qemu.  
> Or it can be done using user-mode-linux to run a separate linux instance.  
> What I don't know is if it can be done just using chroot's to separate the 
> environments -- if so, that would be much faster (although there are other 
> disadvantages like having to run as root).
> 
> Of course, setting up multiple virtual machines might be overkill for what 
> you 
> are trying to achieve. And it may be too slow.

Scratchbox1 used by the current SDK shares the /tmp with the host so
that apps run in it can  e.g. access Xephyr display running on host.
If process has a fixed socket location in /tmp, you cannot run multiple
instances of it.

SB2 doesn't have this limitation (it can redirect /tmp).
SB2 is used by SDK+, maybe it helps:
http://maemo-sdk.garage.maemo.org/index.html
?

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

Re: Unsatisfied with bugs.maemo.org

[Eero Tamminen]

Hi,

Gil Quim (Nokia-D/Helsinki) wrote:
> ext Till Harbaum / Lists wrote:
>> i am really unsatisfied with bugs.maemo.org. The reason is simple: Just too 
>> many
>> bugs are just closed with WONTFIX which basically means: We understand and
>> acknowledge the problem, but we won't spend any time on it.
> 
> bugs.maemo.org is only the messenger...
> 
>> This would be acceptible if maemo would be a really open plattform and 
>> anybody
>> could just fix things. But that's not how maemo works and there's such a huge
>> number of bugs that never get fixed and the same issues appear ever now and 
>> then
>> again. I e.g. just filed bug 4630 and should have noticed myself that 1504 
>> was 
>> the same one filed june 2007. It was never fixed but was just WONFIX'd. And 
>> we
>> are not just talking about some weird feature. We are actually talking about
>> something being documented in the maemo api docs.
> 
> I think Andre and you can still try with bug 4630 if it relates to the
> Maemo 5 API.

Bug 4630 & 1504 are about themeing a single Gtk widget aspect.

There are many other Gtk widgets and icons which aren't (at least fully)
themed although they otherwise work fine.  This is because it would
require (internally):
* UI specifications about these widget features and their themeing
* Themeing these things (gtkrc & graphics) for all themes according
   to the specification
* Writing test programs for these features
   (as they're not used by the product itself)
* Regular testing that the widget features and themeing work
   (in all themes) according to the specification

Which is quite a lot of extra work for things that aren't used at all
in the product itself.  So, it's not done.

If the community wants the extra widgets / widget features and icons to
be themed because they actually have some program(s) that use them, I
think its better to handle that as a community project...?


>> Why is there a bug reporting system if so many bugs end up with WONTFIX? This
>> doesn't make much sense to me.
> 
> Again, don't kill the messenger.
> 
> Maemo 5 bug handling has been already a lot more efficient than in
> previous versions, thanks to people reproducing old bugs in the
> Fremantle pre-releases. We expect the good responsiveness to be kept
> once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting
> the fixes out in new updates.
> 
> What we have is a bag of bugs still open affecting mostly Diablo.
> Because of many reasons those bugs were not handled in time or there
> were no resources to fix them at the time.

The main reason was that we didn't have regular pre-releases of the
software before Fremantle.

The situation of what happens after the official release, is similar as
with the other Linux Distros, once e.g. Ubuntu releases a new version of
its distribution, implementing feature bugs and minor bug fixes happen
to  the next release having new features (currently Fremantle on Maemo),
the old release will get only bugfixes to security and other critical
issues and eventually even those stop.  Ubuntu does new releases at
fixed 6 months schedule and the bugfixes to them stop for them pretty
quickly except for the LTS releases.

Our schedule differs (much) more. Also, we don't currently provide LTS
releases (partly because Nokia business model is different, we sell
products whereas most other Linux distros basically sell services).
Unlike Ubuntu we have a few bugfix releases (like e.g. Debian has)
because our releases happen at longer intervals.

Because of the more radical HW platform differencies between the device
targets of the Maemo SW releases, we cannot (at least currently) offer
as good backwards HW compatibility support as can be done on x86.  This
is something that we need to work with the community (and is currently
being done e.g. in context of Mer).


> Now we are cleaning those
> bugs week after week and yes, this brings lots of WONTFIX among those
> that are not an issue anymore in Fremantle. It's more a consequence of a
> past problem than a reflection of a current problem, though.


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

Re: fremantle gettext version too old

[Eero Tamminen]

Hi,

ext Christian Persch wrote:
> I just installed the fremantle beta SDK to port an application of mine
> to maemo 5. I ran into a problem though, since the gettext version
> (0.14.1) that comes with it is too old. The app is a port of a Gnome app
> that uses msgctxt in its po files; building it in the scratchbox stops
> with an error like this:
> 
> Making all in po
> ../../../po/de.po:1064: keyword "msgctxt" unknown
> [etc]
> 
> Would it be possible to ship fremantle final with a gettext version
> that supports msgctxt, so that one can build this app without first
> locally installing a newer gettext in the scratchbox? gettext 0.15 is
> the first version that supports this, but of course using the latest
> (0.17) would be preferable.

Could you file a bug to bugs.maemo.org (if there isn't yet a one)?

Thanks!


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

Re: Fremantle UI Portrait Mode

[Eero Tamminen]

Hi,

ext Cornelius Hald wrote:
> as I was asked to write a bit about the fremantle-ization of the Conboy 
> UI, I first would like to ask some more UI specific questions. Then I 
> can complete this process and write about it.
> 
> * What happens with the AppMenu-Filters when in portrait mode? The HIG 
> tells me that the 2x5 button layout of the AppMenu will change into a 
> 1x10 button layout. But what happens with the single row of Filters? 
> Will it still be a single row? This is important to know, because it 
> would mean that we have to reduce the length of our labels by around 50%.
> 
> * What happens to toolbars when in portrait mode? Is there some 
> automatic behavior like showing the toolbar as two rows instead of a 
> single row? Is it scaled? Is the space between the buttons reduced?
> Or do we have to care about this by ourself, for example listen to some 
> signal and then hiding some buttons or rearranging them?
> 
> * What happens to any other widget when in portrait mode?
> 
> * Is there a signal which signals that the screen orientation changed?

Application needs to specifically request portrait mode with a window
property (I guess there's some API for that), otherwise window manager
uses landscape mode for the application window.

App can listen to standard XRandr messages for this transition if
it wants to, but it's not necessary.


> * Is there a function to change the screen orientation and can we 
> somehow use this with the beta SDK?

It's just a question whether your distro's Xephyr version has XRandR
enabled.  It should.

Then just use "xrandr -o " for Xephyr's display.


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

Re: policy updates (was: Problems with the fremantle autobuilder...)

[Eero Tamminen]

Hi,

ext Jeremiah Foster wrote:
> If they are "illegal" this needs to be clearly communicated in the  
> Packaging Policy document so that packagers know what to name their  
> packages. Currently the version naming is rather unclear and version  
> strings like the one mentioned above is confusing at best. Can we  
> encourage Nokia to work with Maemo to clarify and complete the Maemo  
> Packaging Policy.

If there are updates you would want to get to the Maemo policy,
please put them to the updates wiki page:
   http://wiki.maemo.org/Task:Packaging_policy_proposed_changes

Before or after discussion on this list.

There was earlier (when policy was originally released) also some
discussion about minor updates people would want to the policy.
If somebody could go through the mailing list (all mails on policy
have "policy" in their subject) and add the suggestions to the
proposed changes page, this could speed up getting the policy
updated for Fremantle(/Mer/...).

Btw. We hope to get the next policy update out as a Debian package
which source package will contain the LyX sources for the policy
PDF file.


- Eero

Ps. I added the "policy" keyword to the subject line of this mail too. :-)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to get a program window into the task/window switcher?

[Eero Tamminen]

Hi,

ext Martin Wegner wrote:
> Hello Faheem,
> 
> thank you so much for your detailed "manual" :)
> 
> I got xprop from here:
> 
> deb http://austinche.name/maemo/ bora/

In Diablo xprop is in x-debug-tools package along with a couple
of other X tools.  In Fremantle it's in (a stripped version of
Debian) x11-utils package.


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

Re: QA from extras-devel to extras-testing

[Eero Tamminen]

Hi,

ext Graham Cobb wrote:
>> 3. In extras-testing the betatesters put the software into stress,
>> equipped with Nitro (crash reporter installed in their devices) plus
>> whatever tools they can use voluntarily.
> 
> Not sure about the requirement to have Nitro installed.

The name of this is Crash reporter.  (nitro was internal name that's
not used anywhere anymore)


> In particular, what 
> happens to the (potentially large number) of people using maemo-testing who 
> do not have Nitro installed?  What happens if none of the people who want to 
> beta test this package have Nitro installed.

Using Crash reporter should be voluntary.  Depending on application,
core dumps may contain information that is private (even passwords).

Btw. Crash reporter upload URL can be configured and there can be
another configuration file where one can set which apps cores are 
generated (by default all).  This can be used by community projects
to collect their own core dumps (but they should take the privacy
issue into account).

If somebody wants to look into this (based on Fremantle crash-reporter),
I can provide more information (names of config files etc).


- Eero

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

Re: microb consumes too much memory?

[Eero Tamminen]

Hi,

ext Zhihai Wang wrote:
> I use N800 for web surfing www.taobao.com, after 
> opening 5 or 6 pages, the whole system becomes very very slow. This always 
> happens!
> It sometimes even takes 5-6 seconds to bring LCD from dark state to normal 
> state.
> All the icons in the navigation bar disappeared. But this doesn't happen 
> every time.
> ps show that browserd and hildon-desktop run into DW state.

I.e. disk wait...

[...]
>  5673 user 211944 DW  /usr/sbin/browserd -s 5673
>  5703 root   5728 SW  sshd: r...@pts/0
>  5705 root   1960 SW  -sh
>  5722 user  26072 DW  /usr/bin/modest
>  5727 user  26072 DW  /usr/bin/modest
> 
> Then the system auto rebooted when I was writting this email.

Have you swap enabled?  It may cause issues:
   https://bugs.maemo.org/show_bug.cgi?id=2615


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

Re: policy: "B.3 Parallel option" needs updating

[Eero Tamminen]

Hi,

ext Faheem Pervez wrote:
> Hmm, the example given there didn't work for me on the autobuilder.
> 
> ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))
>  PARALLEL += -j$(patsubst parallel=%,%,$(filter 
> parallel=%,$(DEB_BUILD_OPTIONS)))
> endif
> 
> ^ works for me.
> 
> On Sat, Mar 28, 2009 at 9:20 AM, Faheem Pervez 
> mailto:tripp...@gmail.com>> wrote:
> Hi,
> 
> In the maemo-policy, the "B.3 Parallel option" currently says:
> "TODO: When this option has been added to the Debian policy, add link here to 
> an
> appropriate section. For now, see the discussion in the following Debian 
> policy bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209008";
> 
> The debian bug linked to has been marked as done as comment #252 says 
> debian-policy_3.8.0.0 has a parallel section.
> 
> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options 
> has a section explaining the parallel DEB_BUILD_OPTION and an example that 
> can be used.

Thanks!  Could you add a note about this also to:
http://wiki.maemo.org/Task:Packaging_policy_proposed_changes
?

We'll update the policy eventually.

(At least the essentials section needs updating for Fremantle.)


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

Re: xresponse / cnee question re: mimic of multi-key event

[Eero Tamminen]

Hi,

ext Burke, James wrote:
> Is there a way to use xresponse (or cnee) to mimic a multi-key event such as 
> Alt+F10 ?

I haven't tried cnee, but I think it should be able to record Alt+F10
(and then replay it).

With Xresponse it would go something like this:
xresponse -k "ISO_Level3_Shift,2000" &
xresponse -w 2 -k "F10"

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

Re: Autobuilder for Fremantle now available

[Eero Tamminen]

Hi,

ext Till Harbaum wrote:
> sorry, i don't understand your reply. Why do you think _i_ am using the wrong 
> version
> of something? This is the output of the autobuilder. These are all 
> programs/tools/devkits
> running on the nokia/maemo.org side. I just uploaded a source tarball via scp.

Oh, sorry.

-> bug in in opengles-sgx-img-common dependencies
and autobuilder minimal target setup.


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

Re: Autobuilder for Fremantle now available

[Eero Tamminen]

Hi,

ext Till Harbaum / Lists wrote:
> hmm, something seems still to be broken. Looks like opengles-sgx-img-common 
> tries
> to load a kernel module from its init script but can't due to missing 
> modutils.
> 
> See
> https://garage.maemo.org/builder/fremantle/clutter-gtk_0.8.2-maemo0/armel.root.log.FAILED.txt
> 
> Setting up opengles-sgx-img-common (0.20081031.1-18) ...
> /scratchbox/devkits/debian-etch/bin/invoke-rc.d: line 1: /sbin/runlevel: No 
> such file or directory

I think you're using wrong devkit.  What the SDK docs say?

> Starting SGX services: /etc/init.d/opengles-sgx-img-common: line 46: 
> modprobe: command not found

On Debian (Stable/Lenny):
- "modprobe" comes from "module-init-tools"
- "runlevel" comes from "sysvinit" package
- "invoke-rc.d" comes from "sysv-rc"

"sysvinit" is an essential, others aren't, so on Debian sysvinit should
be already present and opengles-sgx-img-common should depend from
module-init-tools.


However, on Maemo / Fremantle (device):
- "module-init-tools" package is like on Debian
- "upstart" is essential package and provides "sysvinit" package,
   BUT doesn't provide "runlevel" tool
- "runlevel" and "invoke-rc.d" come from "mini-rc" package
   which is NOT essential

So... Clearly "opengles-sgx-img-common" has the bug that it doesn't
depend on "module-init-tools" although it should.  Could you make
a bug about this?


I'm not sure about "runlevel" though.  Should "runlevel" be in "upstart" 
package, or should packages have dependency to "mini-rc", or should
"mini-rc" be essential?


SDK should contain everything that is essential, because
essentials are by definition needed for installing additional
packages.  If SDK (or its minimal rootstrap) doesn't contain them,
it's an SDK bug.


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

Re: qemu 0.10

[Eero Tamminen]

Hi,

ext Cornelius Hald wrote:
> Relying to myself :) It seems like I found the problem. If I try to run the 
> new qemu from inside scratchbox I get this:
> [sbox-DIABLO_ARMEL: ~] > /scratchbox/devkits/cputransp/bin/qemu-arm-0.10
> /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: 
> /scratchbox/host_shared/lib/libc.so.6: version `GLIBC_2.4' not found 
> (required by /scratchbox/devkits/cputransp/bin/qemu-arm-0.10)
> /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: 
> /scratchbox/host_shared/lib/libc.so.6: version `GLIBC_2.8' not found 
> (required by /scratchbox/devkits/cputransp/bin/qemu-arm-0.10)
> /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: 
> /scratchbox/host_shared/lib/libc.so.6: version `GLIBC_2.3.4' not found 
> (required by /scratchbox/devkits/cputransp/bin/qemu-arm-0.10)
> 
> So it seems that the problem is the compilation of qemu on the host. Because 
> of this qemu has dependencies to different versions of libc6. Versions that 
> are not available from inside scratchbox. I'll try to fix that...

Scratchbox is a chroot.  If the libraries you compiled something against
aren't inside the chroot, the binary won't work.

You need to use the scratchbox host toolchain to compile the tools.
(SDK installation should include a target for this)


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

Re: Frets on Fire on Fremantle

[Eero Tamminen]

Hi,

ext Jayesh Salvi wrote:
> I'm not sure why the Fremantle SDK ships with the desktop OpenGL
> libraries in the first place, though.

To be able to run and debug stuff using Clutter (which can use OpenGL
or GLES as backend) on x86.  The proprietary SGX drivers work only on
the device (SGX HW / ARM).


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

Re: multiple SDKs on the same sbox

[Eero Tamminen]

Hi,

Gil Quim (Nokia-D/Helsinki) wrote:
>> On Sun, Feb 15, 2009 at 05:17:12PM -0800, Daniel Monteiro wrote:
>>> Hello folks,
>>> long time since my last email here. I've been silently developing my
>>> games for Maemo,but now here I am with a new question regarding
>>> Freemantle:
>>>
>>> Can I have Freemantle and Gregalle in the same sbox?
>> This used to work with older SDK versions, see
>> http://inz.fi/blog/2007/10/22/multi-target-development-for-maemo/
> 
> You might want to have a look at the beta release of the Maemo SDK+
> based in Scratchbox2: http://maemo-sdk.garage.maemo.org/

SB2 is necessary only if one wants to develop for two different
targets *at the same time*.  Fremantle SDK supports just fine
doing development both for Fremantle and Diablo, just not at
the same time[1].

[1] in SB1, one can have only one target selected at the time
in the whole system (changed by "sb-conf select ").

target = set of specific rootstrap (root file system), toolchain,
qemu and scratchbox devkits versions enabled.

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

Re: Upstart vs. sysvinit (roadmap)

[Eero Tamminen]

Hi,

ext Mika Yrjölä wrote:
>>> Is there a very compelling reason to move away from something as
>>> standard as sysvinit? I haven't even heard about "Upstart".
>> Ubuntu has had Upstart since 2006:
>>https://wiki.ubuntu.com/ReplacementInit
>>
>> And started using it in Feisty (i.e. two years ago):
>>http://packages.ubuntu.com/feisty/upstart
>>
>> In Debian it's only in experimental:
>>http://packages.debian.org/source/experimental/upstart
> 
> Of the other major distributions, I'm under the impression that at
> least Fedora is also using Upstart these days, 

So it seems:
https://admin.fedoraproject.org/pkgdb/packages/name/upstart


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

Re: Upstart vs. sysvinit (roadmap)

[Eero Tamminen]

Hi,

ext Tor wrote:
> Sorry if this has been discussed, but a search revealed nothing.
> 
> On the Maemo roadmap
> (http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle) I noticed this:
> 
> "Device startup handled by Upstart instead of sysvinit. Location and
> format of init scripts differ."
> 
> This makes me a bit concerned. It sounds like moving away from what's
> standard (sysvinit), i.e. porting packages will need more work.
> Daemons I've ported in the past has been mostly just to drop in the
> Debian package, and a quick check of the init.d script for anything
> more complex than the slightly limited (but otherwise compatible)
> feature set available on Maemo. Very very little work.
> 
> Is there a very compelling reason to move away from something as
> standard as sysvinit? I haven't even heard about "Upstart".

Ubuntu has had Upstart since 2006:
https://wiki.ubuntu.com/ReplacementInit

And started using it in Feisty (i.e. two years ago):
http://packages.ubuntu.com/feisty/upstart

In Debian it's only in experimental:
http://packages.debian.org/source/experimental/upstart

(Although Ubuntu is Debian based, it has pretty major differences;
uses Upstart instead of sysvinit, uses Dash as /bin/sh instead of
Bash[1], has Python as essential package...)



- Eero

[1] Using interactive shell like Bash as /bin/sh slows down bootup
 quite considerably.  I think Debian's going to do similar switch
 at some point.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: scratchbox ide

[Eero Tamminen]

Hi,

ext Marius Gedminas wrote:
> (vim also has smart autocompletion, called omnicomplete, but I rarely
> use that -- Python programs are *very* hard to statically analyze).

For Python programs I'd recommend using PyLint:
http://pydev.sourceforge.net/pylint.html
http://www.logilab.org/card/pylintfeatures

(And PyDev is Python extension to Eclipse IDE)


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

Re: gprof-base Profiling: "no time accumulated"

[Eero Tamminen]

Hi,

ext Thomas Thrainer wrote:
>> On the other hand, do you really need to use gprof? Profiling on N810 can
>> be done with oprofile, which covers all the gprof functionality and
>> provides a lot more features. Please check the following page:
>> http://maemo.org/development/tools/doc/diablo/oprofile/
>>
>> If you think that for your specific case gprof is better and doubt that
>> oprofile can handle it well, please describe what exactly you want to do.
>> I'll try to advice something.
> 
> I tried oprofile, and it worked nicely for me. I actually wanted to use gprof 
> because I used it on my development machine too and I wanted to use the same 
> tool in order to get comparable results.
> But anyway, now I have my profiling results, so thanks for the tip.

On development environment I'd recommend using valgrind/callgrind
and viewing the results with Kcachegrind:
http://www.valgrind.org/docs/manual/cl-manual.html
http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindShot

Valgrind is a bit slower and works only on x86, but in all other
respects this tool combination is way better for analyzing program
performance than gprof.

My recommendation:
- Adding measurements to the software & running those on device
   (without measurements, optimization is pretty pointless)
- First using CPU and oprofile on device to get system bottlenecks
- Then analyzing those bottlenecks with x86/Sbox[1] using
   Valgrind/Callgrind & Kcachegrind

[1] This assumes that the same source code is used on ARM and x86.


For the Maemo Sbox environment, the maemo-debug-scripts package offers
some useful wrappers for running things (like "run-with-callgrind").


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