Sorry for the OT, this is a request from a next OSSO team member
trying to allocate the family in Finland.
Do you have any opinion about this area in Helsinki:
http://maps.google.com/?q=Helsinki,+Finlandie=UTF8z=17ll=60.221902,24.841837spn=0.002552,0.01354t=hom=1
We have found a house to rent
DJ Delorie wrote:
I'm pretty sure the jffs2 image is OK, as I can mount it on my desktop
via mtdram.
Better would be to paste your mkfs.jffs2 line directly. I guess you did
use something like
# mkfs.jffs2 -r rootfs -o rootfs.jffs2 -e 128 -l -n
right? I guess '-e 128 -l' is critical.
You can
Hi,
I've noticed something odd in maemo 2.1.
When installing / upgrading packages in scratchbox, in the Setting up
stage apt/dpkg can get stuck for large amounts of time (forever?).
I've found this in gtk2.0-examples for instance, in the context of
sardine work.
It looks like apt/dpkg gets
Hey!
Oh! i haven't been living in espoo myself (although on the border
area) but afaik, it's a nice place to live espcially if you have a
car. At least i would prefer to live somewhere in Helsinki if my
office is in Helsinki since i don't have a car. Two reasons:
1. It's easier and faster to
On Wed, 2006-12-13 at 13:07 +0200, Carlos Guerreiro wrote:
Hi,
I've noticed something odd in maemo 2.1.
When installing / upgrading packages in scratchbox, in the Setting up
stage apt/dpkg can get stuck for large amounts of time (forever?).
I've found this in gtk2.0-examples for instance,
Better would be to paste your mkfs.jffs2 line directly. I guess you did
use something like
# mkfs.jffs2 -r rootfs -o rootfs.jffs2 -e 128 -l -n
right? I guess '-e 128 -l' is critical.
Yup, right from the tar2jffs2.sh script:
mkfs.jffs2 -r $TEMPDIR -o $name.temp -e 128 -l -n
It does the
DJ Delorie wrote:
Yup, right from the tar2jffs2.sh script:
mkfs.jffs2 -r $TEMPDIR -o $name.temp -e 128 -l -n
It does the sumtool line too:
sumtool -i $name.temp -o $name -e 128KiB -l -n
Well, then it looks OK. Maybe your image is too small (4MB from your
output? some test?) and this is
Well, then it looks OK. Maybe your image is too small (4MB from your
output? some test?)
I was working on a minimum rootfs to get a console shell test. The
next step is minimum rootfs to get an X app.
In any case if you are sure the image is ok and want experiment with
booting from mmc,
On Wed, Dec 13, 2006 at 11:48:58AM -0500, ext DJ Delorie wrote:
Well, then it looks OK. Maybe your image is too small (4MB from your
output? some test?)
I was working on a minimum rootfs to get a console shell test. The
next step is minimum rootfs to get an X app.
The minimum size for a
The minimum size for a rootfs is 4MB at the moment.
The image was a little bigger than 4Mb, but that was enough to help me
out. I added gcc to the rootfs (now 12Mb) and if flashes now. I'll
try to track down a more precise minimum size. Can you add a message
to the flasher tool? Or release
In the Maemo coding style and programming guidelines document on
maemo.org, it states the following: Avoid updating the GUI when the
application running on the background and when the screen has been turned
off. Remove unnecessary graphical elements or constantly updated screen
components. Now,
The minimum size for a rootfs is 4MB at the moment.
My testing shows that a jffs2 file of *exactly* 8 Mb (8,388,608 bytes)
will NOT flash. Anything bigger than that (the next largest jffs2
image is 8,389,752 bytes) WILL flash.
Note that this is the jffs2 image as produced by tar2jffs,
On Wed, Dec 13, 2006, Aaron Levinson wrote:
In the Maemo coding style and programming guidelines document on
maemo.org, it states the following: Avoid updating the GUI when the
application running on the background and when the screen has been turned
off. Remove unnecessary graphical elements
Aaron Levinson wrote:
Well, I had already examining the libosso APIs before sending the e-mail,
and I did notice the system_inactivity_ind flag in the osso_hw_state_t
struct. However, according to the libosso documentation, if the callback
is called for system inactivity, this means that the
14 matches
Mail list logo
