On 21 Aug 2009, at 16:15, Al Johnson wrote:
> On Friday 21 August 2009, Olivier Migeot wrote:
>> On Fri, Aug 21, 2009 at 4:44 PM, Helge
>> Hafting wrote:
>>> Could that be the default configuration?
>>
>> That would also listen on ppp0. Which could be problematic if - dunno
>> if many operators
Hi,
Al Johnson wrote:
>
> On Friday 21 August 2009, c_c wrote:
> Have you tried unregistering then reregistering, or
> shutting down then restarting the GSM module?
>
Both do the trick. It seems as if this service is really optimised. Data
is sent only on registration. I guess I'll have to k
Hi guys,
I am new to this community. I am a software developer from india.
Would anybody suggest how to begin with.
What are the technologies and programming languages I have to know to
contribute in this project?
Anybody from India in this group?
Regards,
Soumik.
___
AFAIK, Michael still hasn't published his changes in a public repository.
To improve the speed of the Koolu build, see the patch in this email:
http://android.koolu.org/pipermail/android-freerunner-koolu.org/2009-July/001149.html
Jim
On Fri, Aug 21, 2009 at 7:28 PM, Chris Samuel wrote:
> On Sat,
On Sat, 22 Aug 2009 01:49:09 am Christopher Friedt wrote:
> I've since become a bit fixated with Android Donut on my FreeRunner,
> and am just about finished building an ARMv4T generic version of Donut
> (hopefully everything links ok without relocations!). Next I'll have
> to try to integrate a m
2009/8/21 Sebastian Krzyszkowiak :
> On 8/21/09, Risto H. Kurppa wrote:
>> On Fri, Aug 21, 2009 at 7:01 PM, David Reyes Samblas
>> Martinez wrote:
>>> 2009/8/21 Risto H. Kurppa :
I had a closer look at apt-portal at https://launchpad.net/apt-portal
>>>
>>> Tried to istall on Ubuntu 8.10 mach
On Sat, Aug 22, 2009 at 12:51 AM, Vikas Saurabh wrote:
> Then we would call for the FR from outside Delhi (I know only 2 up
> till now...chetan and alok...both, i guess, in bangalore) and then get
> them for fix. I thought sending the FRs is a far bigger problem than
> actually getting it down to t
> Do you pplan it on any particular date? IMHO it is worth to put it into
> CU, but need date details also.
We haven't yet decided on the dates. In fact we were trying to figure
out if we can do #1024 and bass fix as well alongwith buzz fix. I have
been neck-deep in work this week and i think same
On Friday 21 August 2009 18:13:14 Tilman Baumann wrote:
> Booting after init still takes ages. I don't know, but it seems to be a IO
> throughput problem rather then CPU speed.
We're just doing too much at this stage.
> What I would wish for is quicker GSM login. I think have the latest
> firmwar
> today i did the rework for bug #1024 to my freerunner. First i tried to
> remove C1009 and replace it with a 22µF capacitor but i had no luck
> getting it off the board with my tools. Maybe it was glued to good and i
> have no smd tweezer iron to heat up both ends of C1009 at the same time.
> So
On 21 Aug 2009, at 18:10, Edder wrote:
> On Fri, Aug 21, 2009 at 6:52 PM, Michal
> Brzozowski wrote:
>> 2009/8/21 Tilman Baumann
>>>
>>> Remember, there is almost absolutely no use case for total shutoff
>>> and
>>> suspend to 'Disk' since you want your GSM to stay on line on
>>> suspend.
On Friday 21 August 2009, Fox Mulder wrote:
> Now i only need a reliable testcase where i can see if the rework helped
> or not. Is there any scenario i can try to find out if #1024 is fixed or
> not?
Good to see the pics. All I can suggest is to enable deep sleep, enable
logging to file on SD, a
On Thursday 20 August 2009 09:30:32 pm c_c wrote:
> Hi,
> Did anyone get their location data? (Should come under the date and above
> where the LOADING.. message appears).
> Any feedback about the phonelog, reminders etc?
>
Location data doesn't work for me, also can't get it to display the t
On Fri, Aug 21, 2009 at 6:52 PM, Michal Brzozowski wrote:
> 2009/8/21 Tilman Baumann
>>
>> Remember, there is almost absolutely no use case for total shutoff and
>> suspend to 'Disk' since you want your GSM to stay on line on suspend. And
>> for that everything but past resume from RAM is useless.
2009/8/21 Tilman Baumann
>
> Remember, there is almost absolutely no use case for total shutoff and
> suspend to 'Disk' since you want your GSM to stay on line on suspend. And
> for that everything but past resume from RAM is useless.
>
There are many use cases if you're on battery for an extende
On 8/21/09, Risto H. Kurppa wrote:
> On Fri, Aug 21, 2009 at 7:01 PM, David Reyes Samblas
> Martinez wrote:
>> 2009/8/21 Risto H. Kurppa :
>>> I had a closer look at apt-portal at https://launchpad.net/apt-portal
>>
>> Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but
>> fails
On Fri, Aug 21, 2009 at 7:01 PM, David Reyes Samblas
Martinez wrote:
> 2009/8/21 Risto H. Kurppa :
>> I had a closer look at apt-portal at https://launchpad.net/apt-portal
>
> Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but
> fails on running the scripts
> Seems to need Jaunt
Michael 'Mickey' Lauer wrote:
> On Friday 21 August 2009 16:36:07 Helge Hafting wrote:
>> Now, implement suspend-to-disk (SD-card), and you can start
>> reasonably quick after changing the battery.
>
> It should take around 40 seconds to read the memory back from SD, so if
> you
> can live with th
Hi all,
today i did the rework for bug #1024 to my freerunner. First i tried to
remove C1009 and replace it with a 22µF capacitor but i had no luck
getting it off the board with my tools. Maybe it was glued to good and i
have no smd tweezer iron to heat up both ends of C1009 at the same time.
So i
2009/8/21 Risto H. Kurppa :
> I had a closer look at apt-portal at https://launchpad.net/apt-portal
Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but
fails on running the scripts
Seems to need Jaunty to work out of the box, I will try to install
Jaunt in some some partition and
On Friday 21 August 2009, Nathan Kinkade wrote:
> I'm running SHR unstable. A number of days ago I decided to try to
> turning ti_calypso_deep_sleep to adaptive to see what would happen.
> Everything *seems* okay, and though I haven't done any formal test of
> battery life some anecdotal evidence
Hi Tom,
It's nice to know that you're still working on this [1]. I had a bit
of a 'break' after I moved back to Germany and got back into my msc
program. Things are naturally quite busy because I'm still working
remotely at my engineering job in Canada, so it wasn't really that
much of a break in
Michael 'Mickey' Lauer wrote:
> The only sane way to substantially improve booting time is to stop booting
> like a desktop PC, that is move away from starting all services just because
> you can. Start them on demand and bring only the bare necessities up on boot
> (filesystems, dbus, X).
Yes,
On Friday 21 August 2009, Olivier Migeot wrote:
> On Fri, Aug 21, 2009 at 4:44 PM, Helge Hafting wrote:
> > Could that be the default configuration?
>
> That would also listen on ppp0. Which could be problematic if - dunno
> if many operators do that - its IP is directly reachable from the Wild
> (
On Friday 21 August 2009, c_c wrote:
> Hi,
> Going to a different geographical location gives me the location string
> of the new cell for the first time. But, re-starting launcher doesn't.
> Something to do with the calypso?
Or the cell tower. Have you tried unregistering then reregistering, or
On Friday 21 August 2009 16:36:07 Helge Hafting wrote:
> Now, implement suspend-to-disk (SD-card), and you can start
> reasonably quick after changing the battery.
It should take around 40 seconds to read the memory back from SD, so if you
can live with that, implementing suspend-to-disk might be
On Fri, Aug 21, 2009 at 4:44 PM, Helge Hafting wrote:
> Could that be the default configuration?
That would also listen on ppp0. Which could be problematic if - dunno
if many operators do that - its IP is directly reachable from the Wild
(i.e. anybody could be able to know where you are... ).
Wi
Patryk Benderz wrote:
> [cut]
>> DAEMON_OPTS="-S localhost:gpsd -P $PIDFILE"
> r...@om-gta02 ~ $ fso-gpsd -?
> [...]
> -S integer (default 2947) Set port for daemon
> [...]
> so you could provide just "-S gpsd" so daemon listen an all IPs...
>
Could that be the default configuration?
A laptop
Michael 'Mickey' Lauer wrote:
> On Friday 21 August 2009 06:21:52 Wolfgang Spraul wrote:
>>> Not really. Reloading (in the worst case) 128MB from an SD is not exactly
>>> fast either.
>>>
>>> The only sane way to substantially improve booting time is to stop
>>> booting like a desktop PC, that is m
Yeah, that makes sense - using the bb info if there's nothing else - maybe
we just initially populate the frappdb from the bb files...
Hmm. On the other hand, if someone writes a more detailed description on
frappdb, should that description get pushed back into the bb files?
Warren
On Fri, Au
On Wed, 19 Aug 2009 10:01:53 pm Thomas White wrote:
> It's important to note that, at this stage, the work is less about
> performance and more about laying a solid basis for DRI [1].
I don't know if it's of interest, but Michael Trimarchi who does the Panicking
port of Android to the FreeRunner
I had a closer look at apt-portal at https://launchpad.net/apt-portal
To me this sounds like exactly something we're looking for:
-
APT-Portal is a web content management system that retrieves
information from a Debian APT repository and presents an application
list on a user friendl
[cut]
> Maybe we should get something like frappdb.org or something like that?
I like it :)
[cut]
--
Kind Regards
Patryk Benderz
IT Specialist
Linux Registered User #377521
+48 22 538 6292
ERSTE Securities Polska S.A.
ul. Królewska 16
Warszawa 00-103
KRS 065121
NIP 526-10-27-638
REGON 0111
On Fri, Aug 21, 2009 at 04:10:05PM +0300, Risto H. Kurppa wrote:
> Rui: well done trying to call!
:)
> And I also agree that the name opkg.org is not the best one as opk is
> used in other platforms and other formats are used on FR too..
Ok, so maybe we'll just let opkg.org die then.
> I think
rusolis wrote:
>
> I hope you have fun
>
Ok... I use litephone as dailyphone since 2 weeks now and I really love it!
:)
--
View this message in context:
http://n2.nabble.com/testing-Litephone-new-phone-interface-tp3336730p3489235.html
Sent from the Openmoko Community mailing list archive
I like that idea. :)
We could combine both approaches - a showroom for apps (making the Hall
of Fame on the wiki obsolete which is kinda hard to keep up to date...)
with possibility to comment on different
app-distro-whatever-combinations. We could even consider having
different kinds of hardware i
On 8/21/09, Warren Baird wrote:
> I'm not sure about tying it directly to the bb files - it's not clear to me
> that the formating and information appropriate for a web-based db is the
> same as what you'd want in a bb file...
Well, list of packages would be done by scanning bb files, but
descrip
On Fri, Aug 21, 2009 at 3:45 PM, Warren
Baird wrote:
> Funnily enough, I was just thinking about posting about something very
> similar to this a couple of days ago...
So there are more of us who want something like this and are not happy
with the current solution. Good to hear!
> The model I was
On 8/21/09, Michael Pilgermann wrote:
>> * Also create a client for FR to search & install apps
> (+) low prio
I would change this one into " * Integrate SHR Installer with showroom"
--
Sebastian Krzyszkowiak
dos
___
Openmoko community mailing list
c
Agreed, when opkg.org started I insisted a bit with Tobias so that he
wouldn't make it a distribution point but a facilitator towards finding
interesting apps *from*the*repos* :)
Rui
On Fri, Aug 21, 2009 at 09:01:56AM -0400, Warren Baird wrote:
> Frankly, I'm not that fond of the name opkg.org...
Frankly, I'm not that fond of the name opkg.org...
As I said, I'd rather have some kind of an application database - something
that explicitly *does not* provide opkg files.
Maybe we should get something like frappdb.org or something like that?
Warren
On Fri, Aug 21, 2009 at 8:58 AM, Rui Migue
On Fri, Aug 21, 2009 at 01:46:05PM +0100, Rui Miguel Silva Seabra wrote:
> On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa wrote:
> > Opkg.org seems to be owned by the author so if the author is not
> > co-operative (cannot be reached, doesn't answer e-mails or jabber)
> > there's not muc
On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa wrote:
> Opkg.org seems to be owned by the author so if the author is not
> co-operative (cannot be reached, doesn't answer e-mails or jabber)
> there's not much we or OM can do about it.
Have any of these physical contacts been tried?
We
Funnily enough, I was just thinking about posting about something very
similar to this a couple of days ago...
I definitely agree that opkg.org is broken in many ways, and impossible to
fix atm. And I think some kind of application database is very important.
The model I was thinking about was a
Original-Nachricht
> Datum: Fri, 21 Aug 2009 15:25:25 +0300
> Von: "Risto H. Kurppa"
> An: List for Openmoko community discussion
> Betreff: Re: [ALL] New showroom for Openmoko apps
> Opkg.org seems to be owned by the author so if the author is not
> co-operative (cannot be re
Robin Paulson writes:
> Using **pending_return in dbus_connection_send_with_reply_setup()
> without pending_setup is deprecated and strongly discouraged
That's a warning, not error. Just ignore it for now.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer
Opkg.org seems to be owned by the author so if the author is not
co-operative (cannot be reached, doesn't answer e-mails or jabber)
there's not much we or OM can do about it.
Summa summarum:
* Looks like there are people around who support the idea of showroom.
* Showroom, not a repository
* Read
hi all,
i've been trying out osm2go recently on the freerunner, for offline
editing. has anyone else had a go with it? there are ipk packages and
deps at the links below. problem is, i get a segfault whenever i try
to load a project. also, i'm getting the following python error on
start:
Using **p
Dnia 21 sierpnia 2009 7:33 Radek Polak napisał(a):
> > Do You know why bluetooth couldn't be enabled by btsettings ?
> > I mean checkbox m_powerCheckBox is checked but Options are disabled.
>
> This is bug in version v6. Thanks for finding it out. I tried to speedup
> phone start by delaying init
2009/8/21 Risto H. Kurppa :
> On Fri, Aug 21, 2009 at 1:12 PM, Sebastian
> Krzyszkowiak wrote:
>> On 8/21/09, David Reyes Samblas Martinez wrote:
>>> Just an idea, why not use the bb file and source files as README,
>>> INSTALL, Changelog, and .desktop files if exist as source for this
>>> showroo
On 8/21/09, Patryk Benderz wrote:
>> Official Openmoko distributions are Om2009 and SHR (as now it's
> Really? I have just checked here:
> http://wiki.openmoko.org/wiki/Distributions#Official_Openmoko_releases
> and SHR is not listed as official. Should it be updated?
Openmoko Inc. is no longer s
[cut]
> So what? Then such "showroom" should have Android, OpenWrt, Qtopia,
> OE, Gentoo, Debian, Arch... and other versions of packages for one
> app? Who'll package it then? Application developer? Showroom
> maintainer? Please be serious...
and that is exactly why "Showroom" should be showroom on
On Fri, Aug 21, 2009 at 11:59:30AM +0200, Sebastian Krzyszkowiak wrote:
> On 8/21/09, Martin Jansa wrote:
> > On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote:
> >> -> Still I think there's a need for a platform to promote ~working
> >> apps in an appealing way.
> >
> > Yes that's t
2009/8/21 Michal Brzozowski :
> Sounds like a good idea. But don't forget other features that people demand.
> Voting, popularity ranks, comments, testing reports on various distros, etc.
> We need a website in my opinion.
Nothing stops a frontend to add features to the basic showing
functionality,
[cut]
> It does not look good! Wiki is a nice idea, freely editable for
> everyone - but it just doesn't work for all purposes.
Such a showroom doesn't need to look fancy - it has to be informative!
Something like:
http://wiki.openmoko.org/index.php?title=Main_Page/pl&oldid=40837
is nice enough for
On Fri, Aug 21, 2009 at 04:45:00AM -0500, KaZeR wrote:
> One problem is that distro packaged apps sometimes lag way behind bleeding
> edge.
> e.g. : navit in SHR : r2309, navit via navit's feed : r2511 : that's quite a
> lot.
>
> It's not a criticism, just my 2 cents :)
And sometimes its vice-ve
On 8/21/09, Risto H. Kurppa wrote:
> On Fri, Aug 21, 2009 at 1:12 PM, Sebastian
> Krzyszkowiak wrote:
>> On 8/21/09, David Reyes Samblas Martinez wrote:
>>> Just an idea, why not use the bb file and source files as README,
>>> INSTALL, Changelog, and .desktop files if exist as source for this
>>>
I dont think its a good idea to have the app showroom just "browse" a
distribution repository.
However, ...
If the showroom is made so that it uses bb files etc, to get the application
information. Then getting your application into the showroom would also imply
that it gets into the distribu
On Fri, Aug 21, 2009 at 1:12 PM, Sebastian
Krzyszkowiak wrote:
> On 8/21/09, David Reyes Samblas Martinez wrote:
>> Just an idea, why not use the bb file and source files as README,
>> INSTALL, Changelog, and .desktop files if exist as source for this
>> showroom?
> ++ from me! Some way for brows
Sounds like a good idea. But don't forget other features that people demand.
Voting, popularity ranks, comments, testing reports on various distros, etc.
We need a website in my opinion.
2009/8/21 David Reyes Samblas Martinez
> Just an idea, why not use the bb file and source files as README,
>
Hi,
as there are some notable differences between navit from SHR[1] and navit
directly [2]. Does someone know how the navit binary from [2] is built? Maybe
advantages can be merged?
Navit version from [1] is 0.1.0+svnrev2309-r3 from [2] is svn-2511
differences I noticed so far:
[1]:
honours $H
On 8/21/09, David Reyes Samblas Martinez wrote:
> Just an idea, why not use the bb file and source files as README,
> INSTALL, Changelog, and .desktop files if exist as source for this
> showroom?
> bb files has a DESCRIPTION field that can be a little wikified (==, *,
> ) to have a bare minimum p
Just an idea, why not use the bb file and source files as README,
INSTALL, Changelog, and .desktop files if exist as source for this
showroom?
bb files has a DESCRIPTION field that can be a little wikified (==, *,
) to have a bare minimum presentation card and can be enriched with
the other files ,
On 8/21/09, Sebastian Krzyszkowiak wrote:
> I have one idea: how do you want to catch up with library changes
> (...)
STFU, s/idea/question/. It's still a little bit too early for me :x
--
Sebastian Krzyszkowiak
dos
___
Openmoko community mailing lis
On 8/21/09, Martin Jansa wrote:
> On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote:
>> -> Still I think there's a need for a platform to promote ~working
>> apps in an appealing way.
>
> Yes that's true and I think that opkg.org is doing just that.
>
> Only few small parts are missi
2009/8/21 Martin Jansa
> IMHO only few improvements of opkg.org are needed..
>
I agree. And since the opkg.org source code is available, we can add those
improvements, fix the few bugs, and put it somewhere like
www.openmoko.org/showroom (if we don't manage to contact opkg.org author)
__
On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote:
> -> Still I think there's a need for a platform to promote ~working
> apps in an appealing way.
Yes that's true and I think that opkg.org is doing just that.
Only few small parts are missing.
1) Use it rather as nice showroom, not
On 8/21/09, KaZeR wrote:
>
>
>
> Sebastian Krzyszkowiak wrote:
>>
>> My opinion is simple. Developer of app provides bb file (or asks
>> someone to write it) and then all distros provide that app in repo.
>> And that's all.
>>
>> That's distro maintainers who should do packages, not app developers
Sebastian Krzyszkowiak wrote:
>
> My opinion is simple. Developer of app provides bb file (or asks
> someone to write it) and then all distros provide that app in repo.
> And that's all.
>
> That's distro maintainers who should do packages, not app developers!
> When app developers do packagin
Arne & Sebastian, let's try to cool down.
Sebastian: if you don't agree that something like this is needed,
fine, thanks for letting us know, now would you please let us to work
on it if we want.
Android already has it's own showroom (as pointed out in the original
mail). So does QT extended: htt
> So what? Then such "showroom" should have Android, OpenWrt, Qtopia,
> OE, Gentoo, Debian, Arch... and other versions of packages for one
> Ok, so we can't talk about any distro here, cause it isn't "Android
> centric"? I can't recommend Debian for someone here, cause it's not
> "Debian centric"?
On 8/21/09, Risto H. Kurppa wrote:
>>Regardless of the above, we should not compare Ubuntu/Debian
>> repositories with opkg.org, simply because opkg is not repository.
>
> Not? See http://www.opkg.org/packages ...
It is, but it really shouldn't be and that repo just sucks. People who
don'
On 8/21/09, arne anka wrote:
>> Maybe you don't know, but SHR is based on OpenEmbedded, so every
>> Openmoko OE based distro can benefit from bb files in SHR (and after
>> commiting our work to org.openembedded.dev not only Openmoko distros
>> will be able to use that).
>
> ok, i try again: not ev
On Fri, Aug 21, 2009 at 11:46 AM, Patryk Benderz wrote:
>> ABSTRACT
>> I think a new showroom for community created application is needed to
> I think instead of creating new showroom it is better to improve
> existing ones.
>> boost the development and help users to get to know new apps easily.
>
On 8/20/09, William Kenworthy wrote:
> err, which version? - I did a make update, built and upgraded yesterday
> (shr-u) and its not there (though the new pin dialog is - Yeah!)
>
> or is it only visible on a non-gta02 battery?
>
> BillK
It's only visible when you have "smart battery" driver load
> Maybe you don't know, but SHR is based on OpenEmbedded, so every
> Openmoko OE based distro can benefit from bb files in SHR (and after
> commiting our work to org.openembedded.dev not only Openmoko distros
> will be able to use that).
ok, i try again: not every distribution used on the fr is ba
On Fri, Aug 21, 2009 at 10:44 AM, Michael Pilgermann wrote:
> Dear all,
>
> maybe, another perspective here from an apps developer's point of view:
>
> I do believe, that we need a proper / nice directory of applications, which
> users may browse through. I am aware of the following repositories r
On 8/21/09, arne anka wrote:
>> shr-de...@lists.shr-project.org
>> This maillist has patchwork on top of it on
>> http://patchwork.dev.bearstech.com/
>> I think that's enough.
>
> maybe you haven't heard yet -- but not everybody uses shr.
> and since the subject clearly states ALL, i don't really
Hi,
Am 21.08.2009 06:17, schrieb c_c:
>Well, thats one issue. Could you copy all the icons from
> /usr/share/icons/shr/86x86/apps to /usr/share/pixmaps ?
cd /usr/share/icons/shr/86x86/apps
for i in *; do
if [ ! -f /usr/share/pixmaps/$i ]
then ln -s /usr/share/icons/shr/86x86/apps/$i \
> shr-de...@lists.shr-project.org
> This maillist has patchwork on top of it on
> http://patchwork.dev.bearstech.com/
> I think that's enough.
maybe you haven't heard yet -- but not everybody uses shr.
and since the subject clearly states ALL, i don't really see what makes
you so adamant about
> My opinion is simple. Developer of app provides bb file (or asks
> someone to write it) and then all distros provide that app in repo.
> And that's all.
I agree, however after going through all the development pages in a wiki. The
steps involved in creating an application and making a *.bb file
On 8/21/09, Fabian Henze wrote:
> On Thursday, 20th of August 2009 14:04:49 UTC Sebastian Krzyszkowiak wrote:
>> My opinion is simple. Developer of app provides bb file (or asks
>> someone to write it) and then all distros provide that app in repo.
>> And that's all.
>
> That's a great idea. But t
On 8/21/09, Michael Pilgermann wrote:
> For the packaging issue - I really like the idea of boosting the process to
> integrate into reps / distributions. (this would btw. ease the process of
> installation).
> However, documentation on how to do this is really rare. One could probably
> find a wa
Dnia 2009-08-20, czw o godzinie 16:46 +0300, Risto H. Kurppa pisze:
> Hi there!
>
> ABSTRACT
> I think a new showroom for community created application is needed to
I think instead of creating new showroom it is better to improve
existing ones.
> boost the development and help users to get to know
On Thursday, 20th of August 2009 14:04:49 UTC Sebastian Krzyszkowiak wrote:
> My opinion is simple. Developer of app provides bb file (or asks
> someone to write it) and then all distros provide that app in repo.
> And that's all.
That's a great idea. But there has to be some way for a distro main
On Friday 21 August 2009 06:21:52 Wolfgang Spraul wrote:
> > Not really. Reloading (in the worst case) 128MB from an SD is not exactly
> > fast either.
> >
> > The only sane way to substantially improve booting time is to stop
> > booting like a desktop PC, that is move away from starting all servi
[cut]
> My opinion is simple. Developer of app provides bb file (or asks
> someone to write it) and then all distros provide that app in repo.
> And that's all.
+1
--
Kind Regards, Patryk "LeadMan" Benderz
Linux Registered User #377521
() ascii ribbon campaign - against
Hello community,
The first builds of navit for android are now available here :
http://download.navit-project.org/navit/android/
Comments, bug reports and suggestions are welcome, either here or via
navit's tracker : http://trac.navit-project.org
Enjoy!
--
View this message in context:
http:/
[cut]
> We are planning a buzz fix for FRs in India. As Rakshat has already
Do you pplan it on any particular date? IMHO it is worth to put it into
CU, but need date details also.
[cut]
--
Kind Regards, Patryk "LeadMan" Benderz
Linux Registered User #377521
() ascii rib
Dear all,
maybe, another perspective here from an apps developer's point of view:
I do believe, that we need a proper / nice directory of applications, which
users may browse through. I am aware of the following repositories right now:
- openmoko wiki - applications (I think, it is a good start
On Thu, Aug 20, 2009 at 08:28:51PM -0500, c_c wrote:
> Rui Miguel Silva Seabra wrote:
> > My veredict: not yet ready for reliable use, but much better than
> > illume-launcher
> > feature-wise :)
> >
> Can you tell me the problems you faced?
One is quite predictable: it's still way too slow on
91 matches
Mail list logo
