Re: [MeeGo-community] Open Letter/Proposal to allow Maemo on the MeeGo Community OBS
This issue has recently received some attention from this post onwards: http://bugs.meego.com/show_bug.cgi?id=615#c26 so I felt it worth re-posting this to remind people of the original request. Summary : We would like to support the Maemo community in migrating to MeeGo by allowing them to build open-source applications that link against a mix of open _and closed_ libraries on the MeeGo _Community_ OBS. Cross-posted again... please discuss on meego-community. Thanks. David PS as an aside we have almost finished the OSU deployment thanks to a long weekend. Details here: http://wiki.meego.com/Build_Infrastructure/Community_Builder/Installation On 15/06/10 18:16, David Greaves wrote: This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project. *Please discuss on meego-community mailing list* I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia. At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise. The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo. Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible. However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers. Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of "opening the door" to closed binaries and suggest that this arrangement could be agreed as a one-time "grandfathering in" (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community. However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo: * developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner. * many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance. * resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises. * new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes. and perhaps most important of all: * users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available. The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS. The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional. Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account. The proposal therefore is: * To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS. * To grant ACL based access to this repository based on acceptance of an EULA * To *not* require any such EULA for 'MeeGo-only' accounts on the service I've run this by Tero Kejo in Nokia and he's very supportive of the idea. From: David Greaves / lbt Community Member and build systems guy. Niels Breet / X-Fade maemo.org webmaster and autobuild owner Carsten Munk / Stskeeps maemo.org distmaster Andrew Flegg / Jaffa on behalf of the Maemo C
Community OBS looking for beta testers
Hi We're looking for beta testers for the community OBS. The current focus is on ensuring non-core apps (and libs) can be built against MeeGo and Maemo. We need people who know how to use the OBS and can identify (and ideally help fix) issues. Please contact me or Neils if you can help; ideally on irc : lbt (me) or X-fade (Niels) @ #meego David PS Currently ARM is slightly problematic; no cross-compile yet so building is a bit slow; Qt apps don't build. However most gtk apps are fine. -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OBS for Freemantle (really Chinook)
On Thu, 2010-06-17 at 11:25 +0200, Bas Vermeulen wrote: > On 15.06.10 17:35, David Greaves wrote: > > On 15/06/10 14:34, Bas Vermeulen wrote: > > > >> Hello David, > >> > >> I'm trying to set up a private OBS to be able to automatically > >> build/rebuild Chinook instead of Freemantle. > >> I'm getting stuck on the first few steps in your description, > >> specifically where to get the maemo_sdk_5 /maemo_sdk_4 stuff you refer > >> to in the Stable part. Where can I get those? > >> > >> Thanks for any help you can give, > >> > > Sure... you may want to take this onto the maemo-dev list too? > > > > What pages are you using? > > http://wiki.maemo.org/OpenSuse_Build_Service/Fremantle_Setup ? > > > Yup, that's the one. I've set up OBS on a private server, and that's > working so far. I've created a Maemo:4.1 project on the OBS web > interface, including a repository there. My question is how to populate > that so I can build and/or rebuild any packages in the base distribution > (and what other repositories I'd need). I've copied the configuration > from build.opensuse.org's Maemo 4.1 project, but I believe it doesn't > have anything else there. I suggest you document the steps you're taking (following the same overall process as Fremantle). Do that in http://wiki.maemo.org/OpenSuse_Build_Service/Chinook_Setup Then I'll have a much clearer idea of what the problems are. This is a complex and iterative process BTW... don't expect it to be simple ... David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Open Letter/Proposal to allow Maemo on the MeeGo Community OBS
On 15/06/10 18:16, David Greaves wrote: This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project. *Please discuss on meego-community mailing list* DocScrutinizer on irc pointed out that a url might be useful but was too shy to post himself ;) http://lists.meego.com/listinfo/meego-community David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Open Letter/Proposal to allow Maemo on the MeeGo Community OBS
This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project. *Please discuss on meego-community mailing list* I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia. At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise. The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo. Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible. However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers. Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of "opening the door" to closed binaries and suggest that this arrangement could be agreed as a one-time "grandfathering in" (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community. However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo: * developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner. * many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance. * resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises. * new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes. and perhaps most important of all: * users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available. The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS. The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional. Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account. The proposal therefore is: * To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS. * To grant ACL based access to this repository based on acceptance of an EULA * To *not* require any such EULA for 'MeeGo-only' accounts on the service I've run this by Tero Kejo in Nokia and he's very supportive of the idea. From: David Greaves / lbt Community Member and build systems guy. Niels Breet / X-Fade maemo.org webmaster and autobuild owner Carsten Munk / Stskeeps maemo.org distmaster Andrew Flegg / Jaffa on behalf of the Maemo Community Council ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: EDS groupware "plugin" development
On Fri, 2010-06-04 at 11:48 +0200, Nils Faerber wrote: > Hello! > We are currently evaluating the possibilities to attach the N900/Maemo5 > to a groupware server for synchronising PIM data - primarily contacts > and calendar events. > > Maemo5 quite obviously uses EDS EDS? Electronic Data Sync ? http://en.wikipedia.org/wiki/EDS Not a term I'm familiar with :) > in some form to handle some PIM data but > by quick searching I was not yet able to verify how EDS is used in > Maemo5. E.g. it is not fully obvious to me if EDS is used for all PIM > data or just for the address since I only see this > /usr/lib/evolution-data-server/e-addressbook-factory > in my process list. Try: http://syncevolution.org/ http://wiki.maemo.org/Sync syncevolution is also part of MeeGo and has an active mailing list. > And since the calendar and addressbook applications seem to be > non-open-source I cannot check in them either. > > The intention is to create something, like an EDS plugin, that will > allow the standard Maemo5 applications to transparently use another > groupware server, like e.g. Kolab. So SyncML is the likely answer AIUI. > - For the other non EDS type(s) what would be the best way to create > alternate source connectors? HTH David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QA Proposals (was Re: Quality assurance of "stable" software: my battery drained in few hours)
On 29/05/10 17:52, Sivan Greenberg wrote: Yes, I am working on this :) Real life and bills paying can sometimes get in the way but I'm slowly going back to being fully active with MeeGo. I will send a notification to go over and review [0] once it is finished, as so far I outlined the tools that will enable us better QA but have not expanded them and elaborated. Then I would ask the TSG to approve the team creation, which would also attempt to engage users in QA and specific niche testing of the software we deliver. Hi Sivan Just checking : [0]: http://wiki.meego.com/Proposal_for_a_Quality_Assurance_working_group and maemo-developers mailing list So we should really take (or at least cc) the QAWG to meego-dev (but see later) However could you look at: http://wiki.meego.com/Proposal_for_a_Repository_working_group Having spent quite a lot of time pushing for *something* to be done in this area I'd like to suggest that the successor to the RWG encompases this kind of QA activity. Personally, I'd also suggest that you forget about Working Groups the powers that be don't seem interested in setting up WGs for much other than product direction at the moment; certainly they won't (AFAIUI) set one up for just QA; it would be expected to fall under a larger umbrella. See the various TSG logs for the past few months for my (lbt) attempts and more useful URLs. Of course there's also the "Meeting call for Community application support" that you responded to on the -community ml. Lets follow up in that meeting. Right... now the "see later": I actually don't think there's much point in doing MeeGo QA policy right now anyway; I think we'd be *far* better off working on Maemo QA for Fremantle ... and Harmattan. We have an established community and real devices to work with. We're also working on moving the build and QA infrastructure in Maemo towards the same basic shape that I think we'll see in MeeGo (ie an OBS driven approach). FYI I'm also working on workflow automation and integration with image and test systems internally for Nokia and we expect those solutions to be OSS and deployed on maemo.org meego.com(munity) So if we work on a decent solution for Maemo and ensure it's suitable for MeeGo then we solve a lot of real-world issues. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OBS and Fremantle .... 193 Extras apps built...
Ville M. Vainio wrote: > On Sun, May 16, 2010 at 4:59 PM, David Greaves wrote: > >> A couple of posts on Planet Maemo[0] that may be interesting > > Not sure I understood correctly, but does this mean that we'll have a > PPA-like thingie for Fremantle soon? Yes, that's likely to be one of the side-effects of an OBS - but it's certainly not the main objective :) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
OBS and Fremantle .... 193 Extras apps built...
A couple of posts on Planet Maemo[0] that may be interesting * Community Building for Maemo and MeeGo - What does the OBS *Do*? [1] and * OBS and Fremantle ... huge success and HELP [2] Essentially work has been proceeding on the OBS and we now need experienced maemo build system people to help get it working properly. I also realise I didn't post about the startup of the OBS work [3]. I've also tried to put everything on a wiki [4] so it can be maintained Talk to Neils or I for more details. For when they've scrolled off into the the planet's crust: [0]http://maemo.org/news/planet-maemo/ [1]http://mer-l-in.blogspot.com/2010/05/community-building-for-maemo-and-meego.html [2]http://mer-l-in.blogspot.com/2010/05/obs-and-fremantle-huge-success-and-help.html [3]http://mer-l-in.blogspot.com/2010/05/it-was-dawn-of-3rd-age.html [4]http://wiki.maemo.org/OpenSuse_Build_Service David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to remove a package from repositories
David Hautbois wrote: > Hello > I'm the maintainer of qypy : > http://maemo.org/packages/view/qypy/ > > I'm not allowed to use this name. Interesting. Says who? > How to remove a package from devel and extras-testing repositories ? Talk to Neils, cc'ed David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
Graham Cobb wrote: > On Monday 08 March 2010 23:04:36 Attila Csipa wrote: >> I invite everyone who has not alredy done so >> to take a good look at >> >> http://wiki.maemo.org/Extras-testing/QA_Checklist/QA_Improvements > > Scary. Well, trying to solve a bigger problem than the process originally intended to address. I think what's being proposed (Atilla: BUG: I can't easily tell what's new and what exists) is that the functionality of the software is assessed and then the tester makes a call as to whether that functional bug warrants blocking promotion. I think this should be permitted *if the developer agrees* - maybe we'd need to note applications that want the QA team to do application QA too. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Marius Vollmer wrote: > ext David Greaves writes: > >> My wife must have done an 'ignore' on a Maemo5 update sometime in oct/nov. >> >> The device never reminded her again. She only got pr1.1.1 because she >> noticed my >> device made a sound on account connections and hers didn't... I did 2 >> upgrades >> in succession. Normal users wouldn't have even noticed. > > That's a bug in the "ignore" machinery: I think we only store which > packages have been ignored, but not which versions. This means that if > you ignore a OS update, you will never be notified again about OS > updates ever. Has a fairly big impact on the assumptions being made including those who will never see the update that fixes the bug... David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Graham Cobb wrote: > My personal view is that there will be a lot of > people running earlier software for quite a long time. How long do Nokia > believe it will be before 80% of new devices being sold in retail stores have > PR1.2 pre-installed? FYI My wife must have done an 'ignore' on a Maemo5 update sometime in oct/nov. The device never reminded her again. She only got pr1.1.1 because she noticed my device made a sound on account connections and hers didn't... I did 2 upgrades in succession. Normal users wouldn't have even noticed. I've filed a bug but if this is normal behaviour then I guess a *lot* of devices will never be upgraded. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: FatELF Re: rpm vs. deb and "universal binaries/packages"
Andrew Flegg wrote: > FatELF or some new extensions to an existing packaging format would be > wonderful if having users install random binaries from random > locations on the Internet was a useful requirement. ie virus heaven I have to agree wholeheartedly. FatELF is totally inappropriate for Meego/Maemo (and IMHO most Linux distros). I'd say thanks for suggesting it, now let it die :) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tue, 2010-02-16 at 12:17 +0100, Christopher Intemann wrote: > On Tue, Feb 16, 2010 at 11:56 AM, Andrew Flegg > wrote: > > Sure, but is there a recent i386 port of Maemo at all? :-) > No one is running Maemo on i386, not even Nokia on their Booklet 3G. Mer is - I run Mer/Maemo on the O2 Joggler which is Atom iirc. David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [New Developer]: Questions - Python Packaging / Free or Non-Free / Software Licensing
Sanjeev (EIPI) wrote: > Thank you for the reply. To clarify this particular situation a bit > more... The API key is available only on a paid basis. For some novel or > new devices, a limited use (read: non-commercial) key is given to > developers that apply for one. So, a casual user is not able to obtain > their own API key. I have obtained one of these limited use keys for use > in my application. > > This is the reason why I was inquiring about how to protect the API key > within the application. (nb try not to top-post) This is not a licensing issue, it's a security issue. (Well, actually, you may contravene the api publisher's license since you probably can't avoid publishing your personal credentials to the world). In general if you distribute a binary containing credentials then the credentials can be extracted. You need a fairly complex security system to avoid this (eg Harmattan's upcoming DRM management which is the problem you're attempting to solve - and look how well that worked out so far). You have several obvious problems: * python is distributed as source - it's hard to obfuscate * the api key will almost certainly be clear in the source * if you encrypt the credentials then the decryption routine will be clear * if you obfuscate it (eg compile) then it has to be capable of being read by the CPU - or by a debugger. One solution is to use a proxy. Provide an 'open' service that your app calls and which then passes the request on to the paid service using credentials kept on the proxy. This is likely a breach of the terms-of-use license. As the problem is outlined I think you're out of luck - sorry. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sensing change in System Clock using Qt
ibrahim wrote: > remi.denis-courm...@nokia.com wrote: >>Hello, >> >> - Message d'origine - >> >>> But the problem that can face me is the case when the user changes his >>> clock settings (i.e adjust phone's time to a different time). in this >>> case, the timer that has been set to some fixed duration can go wrong. >>> >> >> As a general rule, delay measurements should be done with the >> monotonic clock, not the wall clock (the real-time clock). As far as I >> know, Qt timers already do so internally. But of course, your own code >> should never request and use the wall clock for time measurements. >> >> > I don't think I follow you! What do you mean by monotonic clock ? If I > don't depend on the system's clock to get current time, where else can I > get it from ? > Let me explain my problem again briefly, I want to know the current > time, calculate some future durations depending on it. Then I figure > out the time left to the upcoming duration and set it as interval to a > QTimer Object. But I'm afraid that user may change the system clock > (adjust the clock) So that my preset time will be invalid. Just so you know... you're describing an implementation and asking if it does what you want without describing what you want. Example: "At 4am the user wants to play a sound at 8am (in 4hrs). At 6am the user changes timezone and it becomes 7am. The alarm should sound at 8am in the new timezone." My guess is that you know about interval timers but you should be using a wall-clock. Since you haven't specified what you want it's hard to know. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Tue, 2010-01-26 at 12:52 +0100, Ove Kaaven wrote: > > Mer builds packages on OBS - why can't we do that for Maemo? > > I thought you wanted to use Debian tools? Besides, I believe OBS is > based on a standard Debian install, which Mer probably aims to be > compatible with, but Maemo isn't. (For those who don't know, I'm the build guy for Mer) I don't think it would be hard to build Fremantle in OBS. There may be some policy issues using the public OBS server (they don't like closed binaries) but Mer may be setting up a 'private' OBS anyhow to handle the opengl dev binaries - In general OBS is certainly a good approach IMHO. I spent a few minutes on this for fun last year and made good progress. My approach was to fake out scratchboxisms and it worked pretty damned well. Mer already uses a sophisticated (ie clever hack) debian derived cross-compiler with qemu - more info on the Mer Build pages. Actually there's a *lot* there :) Answering a later thread: OBS is working on linking to VCS too David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Graham Cobb wrote: > I do think there may be an option 1.5: create multiple autobuilder queues > which feed the same repository but build against different SDK releases. For > example, a "fremantle" queue which builds against the base release (for > ever), and a "fremantle-pr1.1" queue which builds against the new SDK (for > ever), but both populate the same repository (extras-devel fremantle). That > would allow the applciation developer to decide which users they are willing > to support. If the application supports all fremantle users it submits to > the fremantle queue. But if it uses a new feature (or even an important bug > fix) from the pr1.1 release the maintainer could submit it to the > fremantle-pr1.1 queue. > > If we did this, I wouldn't object to automatically adding a dependency on the > device software version, as long as it is worked out from which queue you > submit to. I like - but as someone mentioned to me in a similar situation: testing. We'd need testers for each queue and that may be tricky. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Mustali Dalal wrote: > Till, > > It is obvious that your angst is against my thumbs-down to your app due > to my perceived understanding of optification which is at odds with yours. > > I take testing seriously and do this as a way of giving back to the > open-source community. Thanks > I am a developer too; but still on the maemo-developer learning curve. > The experience with rating your app is not something I would consider a > high-point of maemo. So long as you take it as an outlier :) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
Jeff Moe wrote: > As far as I can tell, there are no mirrors of the repositories. Pretty sure Nokia/maemo.org went with a CDN which satisfies all the points you raised. The maemo.org infrastructure problems are more to do with dynamic content and build services and are being addressed AFAIUI. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SyncEvolution in Fremantle
Eugene Agafonov wrote: >> Update: >> >> I've built a far better .deb based on SyncEvolution 0.9.1, and put it up >> at http://people.debian.org/~ovek/maemo/ >> >> It can't yet be built with a buildbot, primarily because not all of its >> build-dependencies exist in maemo-devel, cppunit in particular. > > I tried to build fro source package you provided but build fails because of > boostlib. > > How did you solve it? > > I couldn't find boost packages for Maemo5 so I have to build boost from > source. Any other options? It's named oddly http://repository.maemo.org/extras-devel/pool/fremantle/free/source/b/boost1.38/ David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [SyncEvolution] SyncEvolution in Fremantle
Ove Kaaven wrote: > David Greaves skrev: >> Ove, Patrick >> >> I'll volunteer to do the packaging for maemo for this if you like? > > Well, there's already packaging (last updated for OS2008 I think) and > the .debs were built from it. Only thing that remains, apart from > submitting patches upstream, is maybe clean up debian/rules a bit, > update the build-deps, and select the final configure options to use, > and maybe other nitpicks like that. I could probably manage that. OK then. I've sent libxmltok-1.2 to the autobuilder already. >> boostlib1.38 is in extras-devel but it looks like I'll need to package >> synthesis >> from git://git.moblin.org/libsynthesis.git - which branch? master? > > You won't have to. The syncevolution build system can build synthesis on > its own as part of the syncevolution build tree, so it's just a matter > of putting synthesis into the same source package as syncevolution, no > need for a separate package (unless you really want it). That's what I > did for now, anyway. I thought that in general shipping a library's source inside another package is a bad idea. If libsynthesis was a part of syncevolution then it would make sense but in this case (and given that Debian already has a package and a debian/ dir for it) I'd keep it separate. We do need to downgrade debhelper from 7 to 5 though as Maemo is a bit behind there. I also made http://gitorious.org/mer-extras/libsynthesis to manage the tweaks to that libraries package. > What branch to use was answered elsewhere in this thread - best to use > the tag that corresponds to whatever syncevolution version we want to build. Sounds reasonable - I didn't spot that. >> Nb personally I use eGroupware and I'm getting some success (especially now I >> have this stuff in: >> http://k.noc.de/index.php?option=com_content&view=article&id=6&Itemid=8 but >> there are still some issues) > > Anything in particular? like this: http://www.mail-archive.com/syncevolution-iss...@syncevolution.org/msg00412.html Most of my contact and calendar data goes from the device to egw but nothing comes back. I upgraded egw to the nightly release with the new syncml patches and enabled the syncml option in the prefs but no change. I thought I'd get the packages built and get a little more familiar with the code first; right now I get the session messages but egw isn't putting a log where it's supposed to. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [SyncEvolution] SyncEvolution in Fremantle
Ove, Patrick I'll volunteer to do the packaging for maemo for this if you like? I'd put them on gitorious.org/mer-extras (until we get some kind of community area at maemo.gitorious.org). I'll use the packaging approach I use for Mer and create suitable branches cppunit is ready (I won't push it to the builder until I can get a clean build locally) and I'm looking at syncevolution and dependencies now. I notice that syncevolution should build-depend on boostlib and synthesis too. boostlib1.38 is in extras-devel but it looks like I'll need to package synthesis from git://git.moblin.org/libsynthesis.git - which branch? master? Nb personally I use eGroupware and I'm getting some success (especially now I have this stuff in: http://k.noc.de/index.php?option=com_content&view=article&id=6&Itemid=8 but there are still some issues) David/lbt -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
Ed Bartosh wrote: > It's just ridiculous to have bug against autobuilder about > maemo-optify is not taking care of build dependency to pymaemo-optify > considering the fact that at the moment maemo-optify doesn't even try > to do anything unless it founds debian/optify file with the line > 'auto' inside it. > Of course it's invalid and confusing. What is bugzilla policy for misfiled bugs? I suspect that, whilst satisfying, closing them as invalid until the reporter eventually gets the right package is not the best policy :) Ed... 2 questions: 1. are you happy that "/usr/sbin/dpkg-preconfigure: No such file or directory" is a bug (as you said a couple of emails back)? 2. what section do you think the bug should be against? Cheers David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SyncEvolution in Fremantle
Ove Kaaven wrote: > Update: > > I've built a far better .deb based on SyncEvolution 0.9.1, and put it up > at http://people.debian.org/~ovek/maemo/ Thanks Ove, got it, installed it. > It'd be great > if anyone would try to put cppunit into extras-devel (the debian package > of cppunit can't be ported directly since it depends on qt3, I'll take a look at cppunit and see if I can produce a non-qt maemo variant. > However, the binary package is probably fairly ready for testing. It is > compiled with optimization, optified, and stuff. It will synchronize > your addressbook via the Evolution backend, as well as your calendar > (including tasks and notes), via the Maemo-Calendar backend which I've > spent the last two days writing, and which now seems to work fine for me. OK, I'd love to help get this moved forwards but I'm not familiar with linux syncing (I run IMAP/LDAP at home and used to use eGroupWare/iCal so I've not needed to be up to now). Could you help me get it working and I'll put some wiki docs up? > Wasn't sure what URI scheme to use to let the user configure which > calendar to sync, for now I've settled on "id:", and > defaulting to the same calendar that Nokia PC Suite would sync to. So I have no idea what you mean here... I'll start digging ut if yo could expand that'd be great. I'll be around on #maemo on freenode over the holidays. > Anyway, everything I've got on ScheduleWorld is now also available on > the N900's builtin contacts and calendar apps... rockin', Sounds brilliant. Lets start with a simple "howto"... assuming this allows syncing against evolution on the desktop and also assuming a linux only setup (no PC-Suite) how do I find out what values to put in what fields in what desktop apps? Then what do I type where to do a sync? (meaning do I ssh into the N900 and push, or pull from the desktop cli?) > There's still no GUI. For fun I tried to run the gtk+ ui (and again > stumbled across missing build-deps when building it - the 0.9.1 version > can't be built because of missing gnome-keyring, the git head version is > slightly easier to build), but it was totally worthless on the N900. > Guess it'd be necessary for someone to build a new GUI for this. Or > maybe a control panel applet or something. Hmm. > > Still, it seems to work fine from the command line, if you really need > to sync your stuff. That's all I need, at least... It's a great start :) David/lbt -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SyncEvolution in Fremantle
Ove Kaaven wrote: > Hi, Patrick. > > I'm new to Maemo, but I've been a Debian Developer for a long time. I > recently got a N900, and decided I really want to sync my stuff. Hi Ove, welcome to maemo-dev :) Just breaking lurker status on this thread and saying that I'm really pleased that someone's making an effort - if you could push your git tree to gitorious.org (maemo's de-facto git-sharing service) that would be really nice even though I realise it is likely to be ugly atm. Also maybe start scribbling on the maemo.org wiki too? Cheers David/lbt -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build-Depends for several Maemo versions
On Fri, 2009-12-11 at 14:34 +0100, Cornelius Hald wrote: > What am I missing? In the general sense: A way to specify per-build-target .dsc files (for pre-calculation of the build-deps & setup of the chroot) and easy access to per-build-target source variations in debian/ (either through patches or tag-based pulls from a vcs). I say this because that's an area the OBS we use for Mer is pretty good at. I'm sorry I don't know how to work around it for Garage. I would have done exactly what you're doing. David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dbus on Mer
Jeffrey Barish wrote: > I am trying to activate the display on an N800 using dbus. On maemo, my > code works fine. On Mer, I get > > osso.OssoException: Cannot initialize context. > > I have fiddled with the X-Osso-Service entry in my .desktop file in > /usr/share/applications and with the Name entry in my .service file in > /usr/share/dbus-1/services. Everything that I have tried produces the same > error message. Has anyone had any luck using osso.Context on Mer? Hmm, I've done this at a low level from python-dbus and hal iirc. I can't get at that code at the moment but it may well change in the near future anyhow; see below. > BTW, is Mer still alive? Yes, very much so however > I see that there has been some occasional chat > about it, but the release schedule for version 0.17 hasn't been updated for > a long time. Nor, I believe, has the hardware support table. ...as you've noticed we've slipped when it comes to releases. One key reason is that we're integrating the Fremantle packages into Mer and this is hard work; another is that both Carsten and I have been tied up on other work too. However this should pay dividends over the hols and into the new year :) We've had a lot of new interest in Mer recently so we're hoping this will improve moving the fremantle code back to the N8x0 devices; and now we have sniffs of the 3D drivers that could be rather good. David/lbt (Ignoring the followup to news... I'm on maemo-developers) -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Best Practices
Edward Page wrote: > Hi All, > > I was talking to texrat recently who had the idea of organizing best > practices for app development. Currently I really only have a couple > of categories with limited ideas for each. I'm curious what you all > think before running off and creating the wiki page. Out of laziness, > I did some wiki syntax but not all of it is. Just snipping the content and responding to the concept... The documentation stream at the Barcelona weekend proposed just such an idea. We're looking to make this pervasive; to include best practices with examples as a part of each area in the docs rather than an area in itself. A challenge is to find a way to introduce these things and structure them into the overall set of docs. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Double checking free/nonfree packages
On Mon, 2009-11-30 at 22:16 -0600, Christopher Allan Webber wrote: > Hello, > > I'm compiling a list on the Libre Planet wiki to determine what packages > are nonfree, and what steps would need to be taken to make the n900 a > fully free phone: > > http://groups.fsf.org/wiki/FreeMaemo Hi Christopher As another Mer person I'm also very interested in this work. Mer on any Nokia device out today is not (and realistically has zero chance of ever being) 100% fsf-free. However every step the community takes in the right direction moves us towards that milestone and I personally feel that Nokia are "doing freedom" in a better way than most (which is one reason I'm here!) If this is a reasonable compromise then it would be great to see this work integrated with the maemo community efforts - IIRC there have been other initiatives to investigate this kind of data so maybe they could be dug up? David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line apps & Extras
Andrew Flegg wrote: > On Sat, Nov 28, 2009 at 15:57, Valerio Valerio wrote: >> Based in your feedback, here are the best solutions in my opinion, let's try >> to reach a good solution that can make both sides happy: >> >> 1 - Modify the HAM code in order to add some kind of switcher for the CLI >> apps - Very good solution IMO, but very hard to accomplish in the short >> term. > > Should we introduce an `XSBC-Maemo-Type' header which can have the > following values: Or we could use debtags... interface::text-mode interface::shell interface::daemon http://debtags.alioth.debian.org/ [snipped the rest which is fine] David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
Do you have a URL for the .dsc and tarball David Teemu Ikonen wrote: > Hi, > > I'm trying to compile / port some C libraries from Debian to Maemo 5. > The actual compilation goes without problems, but the packaging > scripts use the (very nice) command sequencer functionality of > debhelper v. 7, while the SDK has only debhelper 5. > > There is an up-to-date 'maemofied' debhelper in maemo.gitorious.org, > but trying to compile it in the SDK fails miserably. The problem seems > to be related to perl, which is also of similar vintage (i.e. > obsolete) in the SDK. > > Has anyone else tried or managed to get debhelper 7 running on maemo > 5? Having to rewrite the packaging on every library I need would be a > major suck. > > Teemu > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ 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
On Wed, 2009-11-25 at 15:07 +, Andrew Flegg wrote: > On Wed, Nov 25, 2009 at 14:55, David Greaves wrote: > > > > Does the community really have so much spare resource that we can QA > > non-free (and presumably non-community) apps? > > fms/RST38h's emulators are non-free. However much I'd prefer to have > the source and not special case them, they are useful packages and the > author's intention should be respected. Yep - my 2nd para was about the balance. > Whether they get highlighted in a different queue is an interesting > question; but will probably push non-Ovi, non-free apps away into > their own repositories. Why? It's a different queue, not a different community. > The point of community QA is to make sure only > good apps get to users: we're doing it because we're selfish. Yes. > It's not > free bug finding for commercial software teams; Agreed, the non-free apps you identified are non-commercial. Do you see non-free apps which are commercial (eg crippleware needing an email supplied EIN-keyed password or adware) going through the same process? Would that fail the Extras QA? Why? Would it fail a non-free queue's QA? How do testers QA such (IMHO perfectly reasonable) applications? Should the test process require a password for testers? > and so saying "we're > only go to QA it for you if you give us the source" would seem to be a > change in the purpose and intent of the QA process. Fair, but some of us (and note that I've spent time testing RST38h's "Master Gear" emulator) do and will continue to care about free rather than no-cost. Are you as a community member happy to QA a binary app from a polite and well spoken community noobie without even having the *option* of reviewing the source? What if I'm not? Will it be obvious that there's no source for that app (ie marked non-free) in the testing queue? /me sees quite a bit of grey. David ___ 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
On Wed, 2009-11-25 at 12:04 +0100, Jeremiah Foster wrote: >> We are seeing more questions about this and actually the current > >> information is misleading since it suggests that non-free packages can > >> bypass the Extras-testing QA process, which is not true. > > I am hesitant here, some of the testing process may require source packages, > either now or in the future. I am not certain that non-free packages deserve > to get all the free quality assurance that the community provides. I think > they should be grateful that they are included at all and if they want to go > through testing, they need to at least provide a source package. Does the community really have so much spare resource that we can QA non-free (and presumably non-community) apps? I suppose one way to look at it is that these are no-cost apps that the community can't have unless it QA's them; from that PoV I think providing a place for the app's userbase to QA the apps is fine but I feel that they should be separate to a community queue. David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging a bookmark?
confession: I was all set to rant about 'web apps' in HAM :) However, I apologise : it's a nice app. I can see why you'd want it packaged and visible; I've added it to my desktop. (Nb, map needs to be scrollable - but you knew that) I think it would make sense for you to get karma for it and for it to be published via the Extras process; it truly is an N900 web application (heck, it even has a dependency on maemo-geolocation). I also think it makes sense for HAM to allow web-apps to be published but I personally don't think it's there yet - maybe packaging this up as a desktop/app mgr launch icon is the way to go. Nokia led the way with the 'ovi store' link. Eventually maybe we'll see better presentation... but the issue may need forcing. I do worry about a proliferation of packaged web links though - I thin I'd like some kind of bar to be set here. David Till Harbaum / Lists wrote: > Hi, > > as long as the app manager is a flat list of things i'd oppose to > this. It's already a problem to finger scroll to the list of > gcompris-packages. > Having to also scroll though a list of bookmarks would make things worse. > > Till > > Am Freitag 20 November 2009 schrieb Thomas Waelti: >> Hello list >> >> Some of you might have seen my Google Maps "webapplication" called maeMaps >> (http://tomch.com/maemaps.html) >> >> As it is a always online app anyway, I would like to distribute through >> Extras not an offline version, but just a bookmark to the online version. >> This would have the advantage for endusers that people can easily find it >> through the Application Catalog and for me as a developer greater freedom in >> updaating and integration with other services. >> >> Is that allowed and acceptable? Does it make sense in my case? What would >> you do in such a case? >> >> Best regards and a happy weekend >> -Tom -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
On Mon, 2009-11-09 at 12:16 +0200, Gabriel Schulhof wrote: > Hey, all! > > I added a package to the extras(-devel)? repositories called > maemo-release. It has version 1.0.0 in gregale, 2.0.0 in bora, 3.0.0 in > Chinook, etc. ... Cool... what values did you pick for Mer? David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
> On Mon, Nov 2, 2009 at 11:48 AM, Andrew Flegg wrote: > Alan wrote: > > Grrr! > > > > I hate that kind of talk. It only makes the problem worse. > What problem? This mailing list has a higher concentration of > involved (and affected) developers than talk. You can have an > intelligent discussion here without it devolving into petty > spats or rampaging off topic. This is the official mailing > list for the development of (and developers for) Maemo. [corrected the top-posting] On Mon, 2009-11-02 at 12:07 -0800, Qole wrote: > Your reply continues to sound like the middle class moms who argue for > private schools. How will our children ever get ahead if they go to > that school down the street? It is full of common children who will > only slow our gifted children down. Hmm, your argument sounds like something from talk :) ie it's not technical, not related to the objective and just invites a massive off-topic debate; all fine in a casual conversation but not in a focussed discussion. I'd suggest that the barrier to entry for a mailing list cf talk is substantially less than the barrier to entry of a private school. Anyone from talk is welcome to join the list provided they plan on engaging in development oriented discussions (and yes, they do meander - no-one cares *that* much). David ___ 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?
On Mon, 2009-11-02 at 06:47 +0100, Benoît HERVIER wrote: > Are you all kidding ? seriously ? > "The bug "Way too geeky to present to most users" should, IMHO be an > 'extras user/*' criteria." I am serious. For goodness sake didn't you spot that the device ships with a Facebook applet? If the device is to succeed then even people who believe horoscopes must be comfortable using it! "Accidentally" presenting them with a network sniffer application is, IMHO, a user experience bug. > Does we need to come back to the old days where each user have his own > repository ? To be honest i ll be far away easier to do than the > actual one. Well, yes - and clearly NO. But through the marvel of views and filters we can tailor a single repository to multiple kinds of user. Maybe have the HAM run in 3 views: casual : games, social, media, music professional: spreadsheets, sync apps technical: network sniffers, encryption tools, CLI David ___ 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?
On Sat, 2009-10-31 at 19:10 -0700, tz wrote: > I'm a power user and not the only one. Agreed. > And what I used my current > tablets for were testing networks and doing other low level stuff, > mainly from xterm, but sometimes from python front-ends to linux. So > I ported a number of utilities under Linux to maemo/diablo and started > to do it for fremantle. And this is the problem. If you got all the people in the world who want to use the tablet/phone in this manner you wouldn't have a market that warranted making the device. Personally I want the thing to be uber-successful and I want to be on the inside where I can ensure *my* niche needs are met by working collaboratively with those who have to support the masses. Otherwise good luck writing socat for a nailed down iPhone (in a year or few). > Way back when, I complained that half of what I wanted to install was > invisible except under "red pill mode", and after getting all the > noise about not using it and explanations, for those utilities I > thought were significant, I created versions in user/* because it is > the only way they would be visible. > One of them was socat. So I ported it and now that I submitted it for > fremantle they say it shouldn't be put in user/ so I'm both confused > and annoyed. Really? Because you think that 'socat' is something that a wide cross-section of the target audience will use? > This is the iTunes Application Store by mob justice. > "I don't like your app so you can't have it in extras!". ROFL. > No one reported > any actual bug, or problem, they just don't want to make it available > to users or anyone else using the normal means. However, that's a valid point. The bug "Way too geeky to present to most users" should, IMHO be an 'extras user/*' criteria. > There is only one option and I'm trying to play by the rules - and > going thorough all the steps. rant about turmoil when involved in the early phases of something and identifying a bug in a process. > Is there some category under user/* I can put it in without worrying > about being rejected except for actual bugs, or did all the discussion > about how to avoid the ugly hacks yet be able for users to actually > get to my programs result in nothing? Ah, the actual point :) (and a good one too). Alongside 'user/*' I wonder if we should have a 'geek/*' section ? Or make 'user/development' and some other categories only visible if enabled in preferences. Personally I think we're back at the Categories argument that was never really taken seriously. David ___ 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
On Fri, 2009-10-30 at 13:20 +, Andrew Flegg wrote: > On Fri, Oct 30, 2009 at 12:55, Graham Cobb wrote: > > On Friday 30 October 2009 11:44:17 Juha Kallioinen wrote: > >> And a perfectly good one too! :) It's useful not to change the upstream > >> package version too much so that it's easier to see that a package could > >> use updating. > > > > I agree with all Juha's points (but I would, wouldn't I!). > > Simplest solution I can see, whilst still giving the user some > indication of version number (3.4.1 tells you something over 0.0.1): > the Application Manager only shows things of the form (\d+)(\.\d+)*? > > So, the example of 2.0.0+cvs20040908+mp4v2+bmp-0ubuntu6maemo1 would > just appear as 2.0.0 in the view. /me would be confused. Why is it upgrading 2.0.0 to 2.0.0 *again* ? David (Who presumably wouldn't see the -local_bugfix1 and -local_bugfix2 suffixes) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The issue of version strings
Ryan Abel wrote: > One thing I think it might be worth working on is the user- > friendliness of the version strings of packages in Extras. We want the > Application manager to be as friendly and approachable for the average > user as possible and long incomprehensible lines of alphanumerics are > a surefire way to scare people off. ;) > > So, this is just my humble request that people be considerate of users > when crafting their version strings and try to it reasonable. Avoiding > date/svn-based versions would probably be a good idea. So you're thinking that a git sha1 is 'suboptimal' ? I thought Shopper v.fc42f5c26bbc257cf782679f7b40075e05322647 ? -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What's the best attack? (Re: How to use extras-testing correctly?)`
tero.k...@nokia.com wrote:
> - Original message -
>>
>> I realise this is a slightly different question (hence the new subject)
>>
>> OK, say I have an evil twin who wants to attack ('own') a lot of Nokia
> N900
>> devices. How do I do this?
>
> I hope that was retorical. Tell your evil twin to do something usefull.
Err, no it wasn't retorical; it was hypothetical though in case you were
worried.
It's more about being responsible :)
Actually it is very late in the day to be asking... but hey, it sounds like a
topic worth raising.
>> Does extras-testing factor into this?
>
> At least so that I would prefer maemo.org extras to be clean from
> malware. It is much easier to promote it in Nokia internally when extras
> contains good software.
I agree 100% ... all it takes is one example of malware introduced into an OSS
product and we (and Nokia) could lose a lot of credibility.
I wonder how much that could be worth to some people? Maybe worth a deliberate
attack? Maybe someone is playing a longer game?
I just hope we are not planning on taking the "cross your fingers and toes
*REALLY HARD* and hope everyone is nice to us" approach to security ;)
Discuss...
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
What's the best attack? (Re: How to use extras-testing correctly?)`
I realise this is a slightly different question (hence the new subject)
OK, say I have an evil twin who wants to attack ('own') a lot of Nokia N900
devices. How do I do this?
Does extras-testing factor into this?
David
tero.k...@nokia.com wrote:
> - Original message -
>>
>> On Thu, September 24, 2009 13:01, Aniello Del Sorbo wrote:
>>
>> > > > I am well aware of that :)
>> > > > But if I go thru extras-testing (and I really want to!) then it
> looks
>> > > > like the Community has the last word on my application.
>> > > >
>> > > Yes, they do. It's a community effort, but look at it from the other
>> > > side. Not one single person or entitiy can block your app. It
> takes more
>> > > people to block it.
>> > >
>> >
>> > I know.. but still.. scares me.. :)
>> >
>> I tried to make this as transparent as possible, by showing each vote
>> together with the user. If people are trolling we should be easily be
> able
>> to spot this.
>>
>> By letting the community doing this QA out in the open, we can prevent
>> rejections without reasoning by a certain entity like we have seen in the
>> news lately.
>
> This transparency is actually the thing that makes me feel secure about
> the process. The testers are independent and operate with their own names.
>
> The (ex-)qa-manager in me is also excited by the fact that for once the
> testers are really independant.
>
>> However, in a democracy not everybody can be satisfied. Let's tackle
>> issues when we actually get there.
>
> Hear hear!
> If the process does not work, then it get's changed. If it works we'll
> just be happy and discuss how to make it more efficient.
>
> I'm already thinking that there might be a need for a Maemo testers'
> club that makes sure that even niche apps don't get stranded in testing.
>
> Also I'll take the time to ask Nokia testing to look at the tooling
> issue. I would like to have some nice set of tools for testing the
> measurable aspects of applications (like battery usage as Igor pointed
> out).
>
> And in any case we need to talk about Anidello's idea on feedback, with
> beer or not.
>
> Tero
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 usb host + power charge
quim@nokia.com wrote: > Hi, > >> > > I plan to create a proposal for the push n900[1] and I plan to use > the >> > > usb port. I have the following question. >> > > When the device is in usb-host mode it should of course provide > power does >> > > it? Is it possible to charge the device while it's in usb-host mode? > > The N900 comes without USB host mode. When I asked I was told that the > limitation comes at hardware level. > > The reason for this decision was the complexity of providing support for > charging, PC connectivity and USB OTG efficiently through the same Micro > USB port within the project deadlines. We needed to make choices and the > decision was to sacrify USB OTG and concentrate on the essential use > cases of charging and connecting to the PC, bringing the N900 to the > market in its due time. Sigh :( I realised today that PUSH needed a way for software people to get at it easily. So I spent the entire day packaging an I/O library and porting it to Maemo so there was a python app that could do: ReadDigitalChannel(1) or WriteAllDigital(17) to do the I/O This afternoon I created a garage project and then wrote an article: http://mer-l-in.blogspot.com/2009/09/want-to-push-need-kickstart.html Never mind... Hmm, can I get dispensation to enter PUSH using a $100 SmartQ ? Maybe I could run ssh from the N900 and have the N900 drive a Maemo powered SmartQ... proxy host mode... David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 usb host + power charge
Kees Jongenburger wrote: > Hi, > > I plan to create a proposal for the push n900[1] and I plan to use the > usb port. I have the following question. > When the device is in usb-host mode it should of course provide power does it? > Is it possible to charge the device while it's in usb-host mode? > > Greetings > > [1] http://blogs.nokia.com/pushn900/ I saw the interesting responses to the 'hijack' about gadget mode - but did you get an answer to the host mode question Kees? I'm quite interested in this too... David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle: Opening URLs and local files
Thomas Perl wrote: > Hello! > > What is the canonical way of opening a browser and the media player > (or more general: opening a URL and opening a local file) from code > on Fremantle? > > Is there a command-line utility that can be used or a D-Bus call? If so, > where is the D-Bus call documented (sample code would be enough ;). Try this http://blogs.gnome.org/tthurman/2009/09/03/writing-apps-for-the-n900-part-1/ This came up a few days back; subject: Proper Way To Call Browser (Fremantle) there's a bit more in that thread David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Matan Ziv-Av wrote: > I then interpreted your "*cough* Mer*cough*" comment as saying > that compatibility with OS2008 is irrelevant, since Mer is expected to > be installed on every N800/N810 device. Ah. That would be nice but we know we're not close to that yet. > We actually seem to be in agreement here: Fremantle packaging decisions > should take other systems (OS2008, Mer, etc.) into account. Sure - lets chalk it down to email missing the nuances :) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Marius Vollmer wrote: > ext Thomas Perl writes: > >> 2009/9/9 Marius Vollmer : >>> ext David Greaves writes: >>> >>>> Hmm, seems like another solution would be to have the opt partition >>>> mounted as >>>> /usr and install all the 'standard' stuff into /root_usr/ and preinstall >>>> symlinks into /usr -> /root_usr >>> Yeah, that would work but we unfortunately can only install into the >>> rootfs partition when creating FIASCO images, due to the tools that >>> create these images. >> I think David's suggestion would be more sane, > > Yes, immensely so. > >> as packages don't have to be changed (Debian packages normally install >> into /usr, so that's already standard and works well). > > Exactly. If we really want to split our roofs over two partitions, we > should put / and the first and /usr on the second. No symlinks etc > would be needed; we can mount /usr as early as needed. > > However, spreading the rootfs over two partitions makes things more > complicated, of course. For example, preparing a FIASCO for the rootfs > now must prepare two filesystem images, and flashing such a FIASCO must > write to those two partitions. This is of course doable, but it > requires changes that we are unfortunately not able to do for > Fremantle. The shit hit the fan too late, you might say. Really? I would think you could prepare /usr_root and /usr on the single partition. /usr contains per-file symlinks to /usr_root and is hidden when the real /usr is mounted. Voila - one fs image for FIASCO and no need to mount /usr early. The problem is now getting the updated symlinks onto the real /usr Maybe something like: As the fiasco boots it mounts partition for /usr on /usr_old Checks /usr_old/version against /usr/version If there is a mismatch it tars up /usr/ and untars it to /usr_old Then remount /usr_old on /usr The tar thing could include a manifest from the previous image so you could tidy up properly. I realise we have optify for now... Just exploring for fun. > We will get rid of this abuse of /opt as fast as we can. Thanks :) -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Graham Cobb wrote: > I would suggest that Nokia add /opt/bin to the PATH, add /opt/lib to the > LD_LIBRARY_PATH and add /opt/lib/pkgconfig to PKG_CONFIG_PATH (all on the > device and in scratchbox) and that we ignore the FHS rule that packages > should not install into those directories. That would make things a little > easier and more robust. We can then build with --prefix=/opt and add a > couple of softlinks if necessary for files which still need to be elsewhere. And if you depend on porting in a few other debian packages you'll repackage them for maemo? Doable - but to expect other devs to do that? At the moment 'porting' an app is usually a semi-automated process. Having to figure out the debian/rules for each and then hacking their ./configure to --prefix=/opt Oh boy PLEASE don't require a ./configure change optify is the lesser evil David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Matan Ziv-Av wrote: > On Wed, 9 Sep 2009, David Greaves wrote: > >> Matan Ziv-Av wrote: >>> On Wed, 9 Sep 2009, Andrew Flegg wrote: >>>> * Use of /opt is perhaps now a QA requirement for Extras >>>> * Can we somehow add a /opt check into minimae/maemian? Is it >>>> possible, and is it sensible? >>> >>> Please recall that maemo5 is not the only maemo. Maemo4 is the latest >>> availble for N800/N810 and maemo2 is the latest officailly available on >>> 770. Many packages can compile from same source for all versions. Don't >>> add artificial obstacles to force developers to make their packages >>> incompatible with older versions. >> >> *cough* Mer*cough* > > Call me when Mer is a reasonable replacement for OS2008 on N810. Until > then, please don't try to fragment the community for no reason except for > planned obsolescence. Had I ranted on how it was essential to do something different to provide definite support for Mer then that would have been a reasonable although impolite response. However since it was a gentle reminder that Mer *may* be on the horizon as yet another environment that packagers may like to support from the same tarball - and one that doesn't currently make use of /opt - then I really don't understand it. However I don't see much evidence that Nokia are considering the legacy community here - over time application writers are likely to package for the current platform and it's going to make supporting the N810 and older even harder for the few of us that are working very, very hard on a way to extend the useable life of those devices. Now this /opt thing may not affect packaging for Maemo4 or Maemo2 or Mer - but I'm not convinced that that is down to luck, not design. (However if the decision to use /opt and the current proposed solution *does* have "supporting Maemo4" as a requirement and not just a side-effect then I apologise.) Oh, and Matan, having potential users tell us to shut up and "call them when it's ready" is frankly offensive. If you want your N810 (I assume) to have something that runs apps from fremantle-extras then come and lend a hand. > If you are going to use symlinks anyway, let the > package installer make them, so the same package can be used for various > system. > > A lot of packages available for maemo are merely debian/ubuntu packages > built in maemo environment. This /opt idea will reduce the amount of > software available for maemo5 devices. So despite the comment above you appear to be in agreement with my comments supporting consistency with Debian a few mails above... It certainly does have the potential to make porting more complex packages harder than it needs to be. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Matan Ziv-Av wrote: > On Wed, 9 Sep 2009, Andrew Flegg wrote: >> * Use of /opt is perhaps now a QA requirement for Extras >> * Can we somehow add a /opt check into minimae/maemian? Is it >> possible, and is it sensible? > > Please recall that maemo5 is not the only maemo. Maemo4 is the latest > availble for N800/N810 and maemo2 is the latest officailly available on > 770. Many packages can compile from same source for all versions. Don't > add artificial obstacles to force developers to make their packages > incompatible with older versions. *cough* Mer*cough* David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Quim Gil wrote: > Hi Maemo developers, > > This is an important information specially for those handling large > packages. You can find an online version updated at > http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs > (or http://tr.im/yeWM in short) > > The N900 has about 100MB of free space in the root file system > partition. This is not very much and would fill up quite quickly when > installing additional applications. As a workaround, the /opt directory > has been linked to a different partition with more space (about 1 GB) > and /home/user/MyDocs is also available in certain cases, with even more > space (about 25 GB). Developers are encouraged to make good use of them, > specially for applications requiring more than 500KB, including > dependencies. > > /opt as a good alternative Hmm, seems like another solution would be to have the opt partition mounted as /usr and install all the 'standard' stuff into /root_usr/ and preinstall symlinks into /usr -> /root_usr You could have the root partition's /usr full of symlinks to /root_usr/ and then it works without /usr mounted and when it is overmounted by the other partition it wouldn't change. Then /usr would be much like Debian upstream - the place to install larger data files David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Qt4Maemo-devel] The Summit: Git/Gitorious - Untracked talks: consider adding them...
Kees Jongenburger wrote: > Hi David, > > I assume you want to present to also have some discussion. so let's > start with that. This is all IMHO. Sure. > I don't believe that version control system is what is keeping us back > from collaborating. I do use git myself > when I feel like it to "grab" projects and start hacking on it but > this is not what you are talking about. It's part of it but not what I was interested in. When you have even 2 or 3 people working on a project you begin to *need* a process to handle submitting changes to manage bugs and new features. There are obviously lots of social issues - but I'm not planning on discussing that side of it. >> Maybe it's just me but I see a lot of devs who are new to DVCS and very few >> community guidelines on how to use DVCS. Qt uses it but, as we've recently >> been >> discussing, it could be going better. > > One can solve many problems in many ways. it's very hard to find a > common way of doing things but this is apparently the design goals of > the git system I wouldn't say that. There are lots of ways to use git - and *that* is actually one of the problems. > and it's very hard to learn from other just because > it's distributed(you can't look over somebody's shoulder). Even for > developers git is a huge learning curve. While it's not bad to learn > at first sight I don't think it solves and problems we have(it > probably even make us have more problems because we have more choice) So yes it does bring choices - and it needs some getting used to. I am sure that git is not "the best" DVCS for everyone, all the time. I am equally sure that it is a perfectly good solution for most OSS people, most of the time. >> Frankly I don't care which 'good practice' I use - I can go out and find >> lots of >> them. But it strikes me that as a community we should at least say "hey, >> quite a >> few of us are using this approach - if you don't have any strong preferences >> then you can use it too" > > This is not clear to me. what people what problem,project are you > thinking about? what is your target audience? Any maemo C/C++/python devs. Most non-trival projects. The problem is how you handle having a release branch that allows bugs to be fixed; another allowing features to be added and how a team interact around them. Here are some diagrams I use in Mer: http://wiki.maemo.org/Mer/Build/UsingGitorious That's not ready for a presentation but I'd hope to discuss lots of the concepts. eg: >> Well, real soon now (I hope) we're going to have 3 different versions to >> support. >> >>* Fremantle >>* Diablo >>* Mer >> So how do we (you) manage the build-variations (ie debian/* may well vary for >> each of them. Maybe ./configure too)? Do we use branches? How? > I hope not, I know git is good a branches but how confusing will this > be for others?. Well, if there's some commonality in terms and approaches then "less confusing". > To me divide and conquerer doesn't mean every body > gets' it's own branch. No, it doesn't - not even close. But with git everybody gets their own copy of a repository and can, eg, ask a core team to review a change and consider merging it back into a master repo. > For this specific problem (debian stuff) I > would suggest using whatever packager use to solve this problem It's not a packaging issue - it's mainly a development/QA issue with minor packaging details. > and I > don't think it's put everything in a git. No. However the debian vcs-pkg group have been discussing this - as have others. git is an answer (a popular one) but the principles are DVCS agnostic. >> Now how do we manage adding features and back-porting simple bug fixes to the >> stable release whilst you work on that big new feature set. > > This is a typical problem of people working with closed source. In > open-source you release once and might do some minor update > for "real" big problems but overall should not have to maintain a > release branch to to long as everybody wants the Latest & Greatest. > "Release often" mantra Heh - no. A huge number of debian/ubuntu packages are 'release-branch' based. Just look at the version numbers anything that ends in -n is 'release branched' However - you do describe the naive approach taken by a large number of OSS applications. And with a little support it is perfectly possible to provide these solid sw-engineering principles to even the smallest package with almost no overhead. >> How are contributions and teams handled? >> >> It sounds horrendous - and it can be! > > Indeed it sound overcomplicated. first make it easy to contribute and > if it gets out of hand start using tools. Try to keep > working with as many people as possible on the same branch to force > yourself to think about other people's problems. I think we're talking at cross-purposes here. I'm talking about organising a dvcs to provide consistent code releases. I expect to suggest some techniques (as per that l
Re: Proper Way To Call Browser (Fremantle)
> ext Brent Chiodo wrote: >> Ideally, I want to open the browser in a new window to a specific page >> and in the current browser process if there is already one open. daniel wilms wrote: > the browser can be opened by using a dbus-service. The package is called > "tablet-browser-interface" and you find the header in the dev-package. > Here is an example how to call the service from the command line: > > dbus-send --system --type=method_call --dest="com.nokia.osso_browser" > --print-reply /com/nokia/osso_browser/request > com.nokia.osso_browser.load_url string:"http://www.google.com"; > Brent, try this too - it shows usage of the interface daniel refers to. http://blogs.gnome.org/tthurman/2009/09/03/writing-apps-for-the-n900-part-1/ I assume C - I'm doing something similar in python later too David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
karoliina.t.salmi...@nokia.com wrote: >> If you have custom widgets in every program on a system, users will find >> it harder to use. They will not know what to expect when they tap on a >> widget they never saw before... that's the point of having guidelines. > > Please read my sentences above. I meant about replicating the functionality > of the widget > done with other technology with another and ending up with exactly the same > user experience. > It is possible and the guidelines can be followed to create the new widgets. > There is nothing that prevents that, it is just some additional work required > for the developer > as there are hildon widgets lacking from the selection of widgets on the Qt > side. Agreed. I've asked Antontio to start a project so we can create a set of hildon-widgets. What would be good would be some collaboration on creating a prioritised list and documenting the required behaviour. http://wiki.maemo.org/Qt4_Hildon#Where_are_the_Hildon_Widgets_for_Qt http://wiki.maemo.org/Qt4_Hildon/Qt_Hildon_Widgets > If you compare the kinetic scroll list on the startup wizard to the kinetic > scroll list elsewhere, > you may find that it functions the same way, despite that is Clutter and > elsewhere it is Gtk. > Similarly I am sure it can be done also with the Qt in the same way, so that > as end user you can't see the difference > (except that on different toolkits there may be slight performance > differences, e.g. pure clutter > can be obviously faster than Gtk and similarly the performance may differ on > the Qt version to direction or another > depending on the case). > > It just requires accurate tuning for all the parameters to get the scroll > behavior exactly the same and > What comes to the kinetic scroll list, it has certain little details that are > important, otherwise it will feel different (and not right): > - edge bounce > - easing on edge bounce (the movement decelerates before it stops instead of > stopping mechanically) > - friction > - inertia > - scrolling speed (comes from the physics of the friction, inertia, and the > initial speed given by the finger) > - finger following > - item selection sensitivity from touch > - item deselection sensitivity from following movement > - stoppable movement (despite of high inertia, stopped finger stops the > movement immediately) > > To get these right, it really requires trying out on the device how it feels. > When doing the startup wizard we found that > some sensitivities (e.g. selection sensitivity) need to be a bit different > when operated on mouse than when operated on finger on the device. I (and others) wrote the Qt fingerscroll that we have (had?) in experimental. All those factors are parameters. It also works on any scroll-based widget 'for free' and allows highlighting and drag'n'drop. I completely agree that it needs tuning on the device... sadly I don't have one... but if someone wants to send me one... > Once the list is perfected, all the other widgets are easily composited from > these lists and other widgets. > So it is a good idea to start from making a list on Qt to function exactly > like it functions on the Hildon. I've asked Antontio to start a project so we can create a set of hildon-widgets. IIRC we also need to do dbus integration too. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Kate Alhola wrote: > As I said before, we are doing examples how to do many of > these things with Qt . > > I can put this on the list to make example. > > At the moment i just wrote example how to make desktop applets > and desktop applets with Webkit . > > More is coming ... Cool - what's the gitorious url ;) We have: http://gitorious.org/qt-maemo So: http://gitorious.org/qt-maemo/hildon-widgets sounds good Antonio ... want to set it up? (I can't) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
ext-mox.so...@nokia.com wrote: > Since QT is not just a language binding to gtk/hildon, but rather an > independent toolkit in it's own right... > > Is there equivalent and finger sized QT widget for the following hildon > widgets? > - hildon banner > - hildon confirmation note > - hildon dialog (with buttons on the bottom right side in landscape) > - hildon app menu (i.e. two column finger sized view menu) > - hildon time picker (not the legacy one) > - hildon date picker (not the legacy one) > - hildon picker button > - hildon touch selector > - hildon stackable window > - hildon entry (including the possibility for placeholder text) > - hildon edit toolbar (as used in the edit mode view) Not AFAIK, but one reason I asked for a gallery of hildon widgets back at the Danish weekend event was so we (the community) could create a similar set of widgets for Qt (where needed) > See https://projects.maemo.org/svn/af/projects/hildon-widgets/trunk/src/ for > details of the hildon widgets. Is that the maemo.org credentials? I can't get access :( Is it related to this bug: https://bugs.maemo.org/show_bug.cgi?id=4625 We have these figures from the maemomm project: http://maemomm.garage.maemo.org/docs_unstable/tutorial/figures/ David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The Summit: Git/Gitorious - Untracked talks: consider adding them...
First off, I hope this didn't come across as insisting or complaining - I tried to express that. Maybe 'mistake' was wrong - I just carried on writing :) As much as anything I wanted to open discussions as to how important people felt DVCS is. For me it's crucial for Mer and Qt - maybe not so much for others? Jamie Bennett wrote: > Please see my comments in-line below. > > On Fri, 2009-09-04 at 12:57 +0100, David Greaves wrote: >> I proposed a talk at the summit on DVCS and git and it has not been accepted >> by >> the talk selection group. This isn't a complaint :) . . . . . however >> I >> do worry that it might be a mistake... what do you think? > > Its good to bring any doubts about the selection process out to a wider > audience, thanks. I'll try to explain why _I_ voted a no (although it > wasn't a definite no, see below). > > You have another talk, "An Alternative to Autobuilder/Scratchbox" which > would be a talk, in your own words, "about the processes around Mer > builds, access controls, managing integration with our DVCS (git), > acceleration tricks and generally how to make good use of things you > find lying about on the web." > > Now I see this as overlapping somewhat with the DVCS talk and my > suggestion was to combine the two to give a higher level but more > complete picture of development with the current tools we have. Yes, I'll certainly do that. > But does this admiral goal translate well to a presentation or something > else? > > I see this not as a presentation, but more of a collaborative effort > with like-minded individuals hence I suggest a BOF. We have a lot of > physical space at the Summit. I'm sure we can get room for a BOF session > on DVCS practices with the results presented in a lightening talk the > next day and reported on the wiki. How does that sound? I kinda don't know how things are being set out - that sounds really good though - maybe we can do a lightning talks beforehand to set the scene too (and encourage attendance)? Still interested in developer comments about DVCS processes too - what areas (if any!) are of interest - if there's no interest then maybe it's not worth worrying about. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The Summit: Git/Gitorious - Untracked talks: consider adding them...
Graham Cobb wrote: >However, time is limited and if it has to be bumped for other > good sessions then so be it. Fully agree. My intention was to raise it and sound out the developers. see Jamie's comments too. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
The Summit: Git/Gitorious - Untracked talks: consider adding them...
Hi all I'm posting this on planet.maemo.org as well as here - I think the dev-list is the real target :) I proposed a talk at the summit on DVCS and git and it has not been accepted by the talk selection group. This isn't a complaint :) . . . . . however I do worry that it might be a mistake... what do you think? This message is just to solicit opinions and hopefully will validate their decision. If it causes a rethink then that's fine too. Heh - I could do without the extra work involved!! I personally thing think that as a development community with git on garage and gitorious.org we should be making efforts to understand how best to use DVCS processes to collaborate. Maybe it's just me but I see a lot of devs who are new to DVCS and very few community guidelines on how to use DVCS. Qt uses it but, as we've recently been discussing, it could be going better. Frankly I don't care which 'good practice' I use - I can go out and find lots of them. But it strikes me that as a community we should at least say "hey, quite a few of us are using this approach - if you don't have any strong preferences then you can use it too" So why now? Well, real soon now (I hope) we're going to have 3 different versions to support. * Fremantle * Diablo * Mer They'll each have different capabilities and some apps just won't care - they'll support Fremantle or Diablo and ignore the others. That's fine :) (Although being open-source you might find patches being sent in to add support for another flavour - how will you cope?) Other apps will decide to embrace that diversity from the start. So how do we (you) manage the build-variations (ie debian/* may well vary for each of them. Maybe ./configure too)? Do we use branches? How? Now how do we manage adding features and back-porting simple bug fixes to the stable release whilst you work on that big new feature set. How are contributions and teams handled? It sounds horrendous - and it can be! But actually this is all fairly simple stuff with DVCS once you have it explained and once you grok it - but it's bloody hard to figure out from scratch and it's also very unlikely that you'll arrive at the same solution as another team. Which means if you're a member of multiple teams you might find they each have different approaches - "whoo hoo!" - not! So anyway... I thought a talk would be a good idea. Now at the time no-one had volunteered so I did - some of you may have noticed my name at the bottom of http://www.kernel.org/pub/software/scm/git/docs/git.html Now you may think that qualifies me to offer this talk - you'd be wrong ;) I was hanging around the kernel lists at the time, got interested and acted as an 'editor' pulling together words of wisdom. Since then I've used git a little but it wasn't until we started to need it in Mer that I reviewed the state-of-play and tried to pull in other people's good ideas - so that's what I'd use as a base. However we also have Johan Sørensen (cc'd as I don't think he's on-list) who wrote Gitorious.org - I think having him speak on using git and gitorious would be an opportunity that we shouldn't miss. Equally there must be developers in Nokia/Trolltech who could say "we know this stuff and this is how we think you might want to do it." So... speak now... David PS If anyone fancies collaborating and doing a multi-person presentation then I'm up for it. -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Commenting and doc annotation (was: Code cookbook for Maemo?)
Klaus Rotter wrote: > Andrea Grandi wrote: >> I think it's a good idea! Anyway I'll try to propose again the same >> idea I told to Quim during the Maemo Summit 2008: why don't we try to >> write a book on Maemo programming? > > There is already a book on maemo development. What would you like to change? > > http://maemo.org/maemo_release_documentation/maemo4.1.x/Maemo_Diablo_Reference_Manual_for_maemo_4.1.pdf cc +docmaster ;) Have a look at this: http://www.djangobook.com/en/2.0/chapter01/ That kind of collaborative comment system would be great for the Maemo docs; it needs some work but... David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
Marius Vollmer wrote: > ext Ed Bartosh writes: > >> As I already said building in a proper order is already solved task. >> There is no need to upload packages in build order if it can be done >> automatically. It will only create extra job for developers. > > Here is something to consider: > I think the most advanced buildbot out there is the OpenSUSE one, which > is also by Mer,right? Yes. It copes with all of the above and will cycle builds to ensure a solution. (I actually have this behaviour when building a few build-essentials for our version of sbox2 acceleration). IIRC It bootstraps the binary runtime dependency from an old version eg it will use an old version of make to build glibc. Then it uses the newly built glibc to build make. Then it rebuilds glibc using the new make. Then it rebuilds make using the new glibc. Note this is not just a make-like timestamp dependency. Of course this is rarely needed - thank goodness! And there are options to avoid rebuilds when needed. Equally there are cycle busting hints in the OBS build-config for these packages. > Can't find a link right now. Start here for all your OBS/Mer build needs: http://wiki.maemo.org/Mer/Build I've started some light blogging about how we use OBS: http://mer-l-in.blogspot.com/2009/08/make-distro.html David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
Ed Bartosh wrote: > 2009/8/26 David Greaves : >> Ed Bartosh wrote: >>> 2009/8/26 Graham Cobb : >>>> Will it handle build dependencies? I.e. if I create an autobuild tag for >>>> libaaa and also for application-aaa (with a build dependency on libaaa), >>>> will >>>> it submit the library build first? Will it wait for it to finish before >>>> submitting the application build? >>>> >>> This is another story and much more complicated to implement. >>> However if community wants this we can start to discuss possible ways >>> to implement it. >> Like the Open Build Service that Mer uses. >> >> If we change a library and cause a regeneration of the -dev then any project >> (in >> Extras:Devel) that build-depends on it is rebuilt. >> > This is again another story. It can be done by performing nightly > builds for all packages from extras*. Of course developers would have > build results not immediately, but it's acceptable soultion. At least > if end users would not use extras-devel and positive nightly build > result would be mandatory for promoting package from extras-devel to > extras. OBS is designed to work on a pool of builders so it scales well - when quiet the builder is almost interactive. > Well, in our case it's not hard to implement building tags. But it > looks like people want something else. Having used both systems I can't help pushing the one I prefer ;) I would be delighted to show you around OBS sometime via an irc chat... It may not persuade you to switch but it may give you some ideas. -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
Ed Bartosh wrote: > 2009/8/26 Graham Cobb : >> Will it handle build dependencies? I.e. if I create an autobuild tag for >> libaaa and also for application-aaa (with a build dependency on libaaa), will >> it submit the library build first? Will it wait for it to finish before >> submitting the application build? >> > This is another story and much more complicated to implement. > However if community wants this we can start to discuss possible ways > to implement it. Like the Open Build Service that Mer uses. If we change a library and cause a regeneration of the -dev then any project (in Extras:Devel) that build-depends on it is rebuilt. Our Extras packages also build against the current version of the OS, the last released version, any testing version and the experimental releases too. This means that you get early notification of upcoming build issues. Of course this happens on multiple architectures too. >> Personally, I would much rather the autobuilder dependency problem was fixed >> (with some method for submiting multiple packages with build dependencies and >> having them build in the right order, with the dependencies being satisfied) >> instead of this particular feature. >> > Submitting is the main problem. As far as I know dput can't upload > several packages at the same time. Any ideas how to do this? Yes, we do it all the time :) But having working dependencies simply means they stay 'blocked' until the required package is ready. >> But I realise others may disagree! > True. Most of developers developing one application and don't care > about this feature. > Main supporters for it is your project, pymaemo, efl and a few others, > who has a lot of packages. And most of them have their own workarounds > implemented. Again true. However we also handle community contributed shared libraries. What happens if someone uploads (and so owns) eg libsqlite3 Now other people build against it. Then the uploader upgrades it to an API-incompatible version... Without dependency tracking no-one even notices. So whilst they may not clamour for it, they probably do need it. Oh, and OBS is looking at exactly the same tag->build too. Seems a shame that there are so many partially finished wheels around... David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: cgdb (full-screen debugger) works in scratchbox (!)
Ville M. Vainio wrote: > Just a quick heads up: > > http://cgdb.sourceforge.net/ > http://cgdb.sourceforge.net/screenshots.php > > As it appears we won't be running emacs' gud mode in scratchbox any > time soon, it may be a relief to know that cgdb works ok, by just > compiling it (tried w/ fremantle x86). cgdb provides a full-screen > mode that sucks much less than the 'tui' mode of gdb (while still > providing all the gdb goodies). Basically, someone should *run*, not > walk, to package this up for the sdk (it should be just a trivial > import from debian/ubuntu, really). > > Version I compiled is 0.6.4, from Jaunty repos. Hmm, let me just apt-get install emacs in my Mer SDK; yep and gud... yep that's fine. All running in arm under qemu... yep. Cool. David PS Heh - now if only apt-get source worked we'd be laughing! -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Request for assistance for Mer.. technical cross-compile packaging day 15th + 19th July
As you may know, Mer uses OBS to build packages inside a chroot running qemu - like scratchbox. However OBS emulates *everything* this makes it very stable but also a bit slow. To improve this the OBS guys have a solution that involves installing a few cross-compiled applications. ie they install i586 apps into the qemu chroot. These apps replace the arm binaries (so no paths to /scratchbox/* that won't build elsewhere). However there are issues with library paths etc. that need resolving. They have this solution working for spec/rpm packages but not dsc/deb packages... which we of course need. So in the best open source spirit we're going to have a hackday or two to try and get this to work. We'll be meeting around 10am CEST (8am UTC, 9am BST) on the 15th in #opensuse-buildservice and #mer on freenode. If (!) we don't finish it then we'll be having another crack on the 19th. The main skills needed are going to be packaging related although if you know about cross-compiling and are around then (hopefully) we may have some questions at some point. If you are interested and feel you can help then please let me know and turn up; if you're not sure, ask me. David PS For those who don't understand then start here: http://wiki.maemo.org/Mer/Build -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clean build environment
Kees Jongenburger wrote: > On Wed, Jul 8, 2009 at 6:57 PM, David Greaves wrote: >> Graham Cobb wrote: >>> On Wednesday 08 July 2009 12:35:35 Ed Bartosh wrote: >>>> There is such a tool and autobuilder is uses it. >>>> It's called sbdmock and you can find it here: >>>> http://github.com/kad/sbdmock/tree/master >>> I thought it was just a build tool -- can it also be used to provide an >>> environment where the developer can sit in a scratchbox target which has >>> been >>> cleanly created and test things out from a command line (e.g. try a build, >>> then look for the missing files configure is complaining about, try manually >>> installing something and see if that fixes the problem, etc, etc?). >> OBS (which we're using in Mer) does something like this too >> http://wiki.maemo.org/Mer/Build >> >> Everything builds from a pristine chroot. >> >> I'm working on creating a pseudo package called 'sdk' which gives you more of >> what you want. > Sounds very interesting! Got the first version running tonight. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clean build environment
Graham Cobb wrote: > On Wednesday 08 July 2009 12:35:35 Ed Bartosh wrote: >> There is such a tool and autobuilder is uses it. >> It's called sbdmock and you can find it here: >> http://github.com/kad/sbdmock/tree/master > > I thought it was just a build tool -- can it also be used to provide an > environment where the developer can sit in a scratchbox target which has been > cleanly created and test things out from a command line (e.g. try a build, > then look for the missing files configure is complaining about, try manually > installing something and see if that fixes the problem, etc, etc?). OBS (which we're using in Mer) does something like this too http://wiki.maemo.org/Mer/Build Everything builds from a pristine chroot. I'm working on creating a pseudo package called 'sdk' which gives you more of what you want. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo will switch (completely?) to Qt?
Aniello Del Sorbo wrote: > > That makes full sense and I was expecting the switch over to Qt. > It's only a shame, for me, that this requires C++ (no idea to which extent). I'm a novice C++ programmer with basic C skills and experience playing with OO langages over the years - I found it fairly simple to write a reasonable application in C++. I also found the Qt toolkit much easier to read and explore. From never using it before to writing a Qt version of pannable-area took me a few months. Before I learned Qt I learned C++/gtkmm and it was a little rough and undocumented - that was actually the motivation to learn a cleaner OO solution. In porting the Gtk app to Qt I practically replaced the widgets with the same text in camelCase and even the arguments were mostly the same. It was astonishing how similar that was. I doubt it's an automatable process but it's not as hard as, eg, a java swing re-write would be. Finally the Qt docs are really superb - and that makes a huge difference. http://doc.trolltech.com/4.5/index.html Obviously these are just my preferences :) Jean-Christian de Rivaz wrote: > And each new languages need a manual custom binding to use QT because of > C++. The GObject model has been designed exactly to avoid a such big > wast of time. GObject allow automatic binding in any languages. This is > why GTK is technically superior to QT. GObject is a hug success in a lot > of very important libraries. Will this help? http://www.kdedevelopers.org/node/3878 David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Accessing contacts via d-bus
Tatu, could you post a link to your code? I'm really interested in seeing an example of the addressbook connectivity. Also I came across this: http://www.kdedevelopers.org/node/3878 which may be useful. David Tatu Lahtela wrote: > Ok talking to my self now :) > > Thanks Antonio, that QT library loading seemed to do the trick. I was > able to access the data with the libebook c api, that osso api wasn't > required. -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
FYI : ConnMan deconstructed : http://blogs.gnome.org/dcbw/2009/06/25/networkmanager-and-connman/
I thought this would be of interest to the list. Also some good comments here: http://lwn.net/Articles/338715/ David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beagleboard touchscreens?
David Greaves wrote: > Murray Cumming wrote: >> I'm going to buy some BeagleBoards for the Openismus office. >> http://beagleboard.org/ >> I'd like to try installing Maemo 5 on them, which I believe is possible, >> and which will be a learning experience. >> >> I hear that Mer can be used with a mouse instead of just a touchscreen, >> but I'd like to install Maemo as intended, so I think we'll need >> touchscreen displays. So does anyone know of any touchscreen hardware >> that will definitely work with beagleboard and Maemo? > > Hmmm > > For a few dollars more you could get a cheap SmartQ 5/7, install Mer on it, > disable Mer and run VNC or just remote X. > > presto... untethered display (or use a USB cable for that 20th century feel) > BTW, for those interested this shop/site is run by a member of our community : goshawk on irc; he's too busy with exams (and too polite) to promote it himself; however, I thought it on-topic here: http://eshopen.com/shop David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beagleboard touchscreens?
Murray Cumming wrote: > I'm going to buy some BeagleBoards for the Openismus office. > http://beagleboard.org/ > I'd like to try installing Maemo 5 on them, which I believe is possible, > and which will be a learning experience. > > I hear that Mer can be used with a mouse instead of just a touchscreen, > but I'd like to install Maemo as intended, so I think we'll need > touchscreen displays. So does anyone know of any touchscreen hardware > that will definitely work with beagleboard and Maemo? Hmmm For a few dollars more you could get a cheap SmartQ 5/7, install Mer on it, disable Mer and run VNC or just remote X. presto... untethered display (or use a USB cable for that 20th century feel) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mer Development Update
Ian wrote: > Hi >>> If anyone is *really* interested there is some work we're doing to >>> try and use >>> DVCS in the packaging process too. It looks really complex at first >>> sight but >>> actually it's fairly simple - there's often just a lot of it. Ask if >>> you're >>> interested :) >> I have followed some of the discussion around that process, if I'm not >> mistaken Martin Krafft from debian fame started this. I wonder if you >> guys have a document describing the process as used inside mer, if so >> I'd like to read it. I think there is room for lots of innovation here. > > Here is the talk from Debconf 8: > > Packaging with version control systems > http://caesar.acc.umu.se/pub/debian-meetings/2008/debconf8/high/547_Packaging_with_version_control_systems.ogg Ah, yes now if you'd said madduck on #vcs-pkg then I'd have known ;) We've discussed this a bit and he's advised me. I'm going to publish this to their mailing list and you may well recognise the diagrams on my page and those on vcs-pkg.org... Also, FWIW we are attempting to satisfy the Ubuntu-MID (or other) needs from an upstream PoV; we'd like to see the Nokia devs do this too :) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mer Development Update
Jeremiah Foster wrote: > I have followed some of the discussion around that process, if I'm not > mistaken Martin Krafft from debian fame started this. I wonder if you > guys have a document describing the process as used inside mer, if so > I'd like to read it. I think there is room for lots of innovation here. I've just updated this... not had chance to proof read it even :) http://wiki.maemo.org/Mer/Build/UsingGitorious nb Maint diagram is missing a yellow tag dot at the very least David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Mer Development Update
Hi I realise that we spend a lot of time on irc and it may be worth mentioning some things on email. First off - please ask if there are any Mer questions... I'll do my best to answer. I've updated pages around here recently: http://wiki.maemo.org/Mer/Build There is a step-by-step guide to installing OBS[1] and building a gtk application to run on mer (merpad!) We're talking about getting apps submitted to the garage autobuilder to also be submitted to Mer too. If anyone is *really* interested there is some work we're doing to try and use DVCS in the packaging process too. It looks really complex at first sight but actually it's fairly simple - there's often just a lot of it. Ask if you're interested :) I am planning on developing an 'SDK' which is essentially a well-populated OBS chroot. [1] http://wiki.maemo.org/Mer/Build/Install_OBS [2] http://wiki.maemo.org/Mer/Build/Application_Building -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
WONTFIX BUGS.... was Re: Default nice value setting
Frantisek Dufka wrote: > Which OS version it is? This is a bug, both should have priority 0. Can > you reopen that bug Faheem linked with details about your OS version if > you see it on current OS version? Oh wait, maybe just forget it, it'll > be WONTFIXed anyway for any current system :-) Just thinking that it would be interesting and productive for Nokians to do a trawl of WONTFIXes and add "but if I were going to fix it, this is where I'd start"... and then possibly work with us on re-assigning them to an appropriate Mer category... David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
kate.alh...@nokia.com wrote: >> From: maemo-developers-boun...@maemo.org >> [maemo-developers-boun...@maemo.org] On Behalf Of ext Qole >> [qole.tab...@gmail.com] >> Hi all, >> >> I'm not much of a developer, but I really think it would be a good idea to >> get a couple OpenGL wrappers ready for Fremantle. > > What do you like the wrapper do ? If you like to get easiest way to run > OpenGL you can take example skeleton > from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need > to compile them > or then you can take Qt GLWidget as it is done in hellogl_es2 that is part > of Qt4.5 source. > I also runs nicely in Fremantle. > > Good thing using Qt as a wrapper is that you can use full GL but you can mix > it with Qt UI widgets > or QGraphicsWiew higer level drawing primitives. I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Henrik Hedberg wrote:
> Murray Cumming wrote:
>> On Fri, 2009-05-29 at 13:20 +0200, Alberto Garcia wrote:
>>> To detect screen orientation changes you can e.g. use the
>>> "size-changed" signal of GdkScreen.
>> This seems like a rather long-winded way to detect landscape or portrait
>> mode, requiring the hard coding of the dimensions.
>
> if (width > height) {
> /* landscape */
> } else if (width < height) {
> /* portrait */
> } else {
> /* square :) */
> }
>
> However, usually developer should not need to know mode but Hildon
> widgets should adjust themselves as much as possible during the
> relayout. Unfortunately that seems not to be the case, as Conny
> demonstrated earlier with some screenshots.
Mmm... what could possibly go wrong ... eg when we look at maemo on a slightly
squarer device with a different windowmanager layout.
Surely
XRRScreenChangeNotifyEvent
should be supported since this actually provides 'orientation' which is what IU
the UI guidelines suggest working to.
Maybe even abstracted to a high level 'RandRChanged' signal?
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with the fremantle autobuilder...
Jeremiah Foster wrote: > On May 26, 2009, at 14:27, Tim Teulings wrote: > > If you upload a version that already exists, the autobuilder will > reject it. This makes sense. Sadly this statement is ambiguous. "that already exists" exists on what? in what state? I and others think that if a package P with a given version X is uploaded and fails to build then a subsequent attempt to upload package P version X should not be rejected. Once package P version X has been successfully built then a subsequent attempt to upload package P version X should be rejected. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with the fremantle autobuilder...
Jeremiah Foster wrote: > On May 26, 2009, at 13:53, Anderson Lizardo wrote: > >> I suppose that if a package is rejected, we can upload it with the >> same version number ? Requiring to increment the version on each >> failed/rejected upload would seem strange IMHO :) > > Why would you want to upload a package with the same version number? > Incrementing the version number is the purpose of the version number, > so of course you would want to change the version number every time > there is a new package. The version number is incremented when an app is packaged _and shipped_. Submitting to the autobuilder to 'check it builds' is similar to running gcc to 'check it compiles'. You don't increment the version number each time you do that. (If we did that I would run out of numbers!) Then, once built you can do a test install and see if you need to tweak a path or something; again you don't record all that in different changelog entries. IMHO promotion/publish is the only time an autobuilder should refuse to run if the version is <= the last published version. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Maemo's Qt look like Hildon?
Antonio Aloisio wrote: > Hi David, > > IMHO most of the extended hildon widgets could be dropped. > Hildon widgets like hildon banners instead need to be integrated inside Qt. Agreed - there are many Qt widgets which could simply be hildonised. I wonder about session management and hibernation for example. > Extended widget could be shipped in an external library if necessary.. > but I won't care about them. Sadly the version 5 gallery includes lots of deprecated widgets and few (if any) new ones: http://maemo.org/api_refs/5.0/beta/hildon/ch02.html Some make sense though and I'd like to see them up for community contribution? Ideally there would be agreement on which and what API would be acceptable and then refinement of implementation. > About IPC Qt classes for system interaction.. I working on them... Is this something that can be put up on the wiki? What's planned (ever) and where we are? David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Maemo's Qt look like Hildon?
Murray Cumming wrote: > On Mon, 2009-05-25 at 12:25 +0300, Antonio Aloisio wrote: > >> While we are on the subject of Qt looking like Maemo without >> API >> changes, how are you dealing with the need for Maemo-specific >> API such >> as that in HildonWindow: >> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html >> >> This trick is possible because Maemo applications have menus, toolbars >> as any normal >> desktop application. Okay they look different, but we can instruct Qt >> to give them the looks that >> we want... >> The same thing happens for the other official supported Qt platforms >> (mac, s60 ans so on) > > Yes, I know that's the Qt philosphy, but repeating it doesn't answer my > question. For instance: > > I guess, Qt windows can't usually have markup in their titles, so you'd > be changing the documented behaviour (therefore subtly changing the API) > if you parsed the regular title as markup, instead of offering separate > API: > http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-markup > (I think that the new API should be added to upstream GTK+ instead > anyway.) > > I guess, Qt windows don't usually have a concept of "activated by the > window manager": > http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-get-is-topmost > (This is presumably something different than gtk_window_is_active(): > http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-is-active > ) > > Also, I doubt that the Qt menu and toolbar API easily supports the idea > of one-single "edit" toolbar, introduced in Maemo 5: > http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-edit-toolbar It seems to me that there are several areas where Hildon is extending Gtk + Qt * new hildon-specific widgets (pannable, HildonWindow... http://maemo.org/api_refs/5.0/beta/hildon/hildonobjects.html ) * integrating/extending existing widgets (text entry + virtual keyboard) * visual style (thin scrollbars,radiobuttons...) * system interaction (essentially dbus and WM comms via API calls like can_hibernate, is_topmost) Is the aim to map to these in Hildon Qt? In which case it would be good to identify and prioritise targets and achievements and it would also be nice to have reference information for IPC for things like system interaction. I also wonder about better handling for applications not written for Maemo; should the core widgets be extended to handle Maemo at the system interaction level and provide derived widgets to expose the API. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt/hildon input integration ?
Attila Csipa wrote: > I know that by now I must be dead boring (and/or wished to worse places than > hell by the Maemo-Qt team) with these questions, but... > > How does one disable the (presumably) hildon text input related bar on the > bottom for QGraphicsView-s or specific items ? I have a qgview that contains > HTML formatted *non-editable* items (QGraphicsTextItem), but when people > select/focus them, the bar pops up which is somewhat unexpected/annoying. Tell me about it :) It is triggered by a mouse-release event; I am thinking about how to fix that. My thoughts are that it should really be triggered by some kind of focus/cursor-set event (is there one?) Also I wonder about using dynamic properties... Should the keyboard query the object for a "no-hildon-keyb" property and not display one if it is set? David ps cc'ing qt4-devel -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Aw: Re: Fremantle user interface behaviour and API
Alberto Garcia wrote: > On Tue, May 19, 2009 at 04:51:47PM +0200, Cornelius Hald wrote: > >> When using HildonTextView inside a PanableArea panning is working >> fine, but I can no longer select text. Are those two mutual >> exclusive? > > In HildonTextView you cannot select text with the pointer. This is so > by design: > > https://git.maemo.org/projects/hildon/gitweb?p=hildon;a=commit;h=b34c64c879c7e86488adbe8000f2f3f2be162a73 > > I think that with both features enabled user interaction can be quite > difficult/confusing if e.g. there's a big text view occupying a > significant part of the screen. Personally I think the developer should have the choice :) http://www.youtube.com/watch?v=4TxAIScXQvk Look at 3:20 onwards David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Aw: Re: Fremantle user interface behaviour and API
Cornelius Hald wrote: > That sounds nice, but I was more hoping for a out-of-the-box solution. I > think this use-case is quite common - it's just a scrollable (ok > panable) text view. So doing like you did I would consider as last > resort. > > Anyways, thanks for explaining your solution :) Err I implemented that into the framework so it *is* an "out of the box solution" for Qt :) I kinda meant that it could/should be doable for the pannable gtk too. Nb the source to both is available so you can see how I did it in Qt and port it and submit it if you like. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Aw: Re: Fremantle user interface behaviour and API
Cornelius Hald wrote: > Thanks to Claudio and API almost all my questions have been answered and > the Fremantle version of Conboy is looking better then ever :) > > There is (for now) only one question left: > When using HildonTextView inside a PanableArea panning is working fine, > but I can no longer select text. Are those two mutual exclusive? FWIW, I managed to implement this quite easily for Qt so I'm sure it's do-able in gtk too. The trick I used is to create a queue of mouse events until I could determine whether or not the incoming gesture was a panning gesture. If it was the queue was discarded; if not the events were replayed to the correct widgets. The decision was simply delta mouse movement within a time period. This allowed selection and even drag'n'drop to "just work". David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
Jeremiah Foster wrote: > Good point. But haven't we avoided the issue of requiring "that > packages have bug trackers, and use them for QA"? How is one going to > enforce bug trackers on applications submitted to Maemo? And if > someone does not want to create a bug tracker, for whatever reason, > how can we convince them not to open their own repo if Maemo rejects > their package? Maemo will never 'reject' a package; extras-devel and extras-testing are always open However a package may not be deemed to meet the QA criteria for "extras" (one of which is a bug tracker). Maybe we should have extras-wild ? (So that non-QA-ed packages aren't bundled with QA-able ones that are on their way to Extras) Users can add Extras and Extras-wild if they wish. FWIW, Nokia would *never* enable (or even mention!) Extras-wild on an out-of-the-box tablet. Extras, we hope, would be suitable. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
Matan Ziv-Av wrote: > On Thu, 30 Apr 2009, Quim Gil wrote: > >> What we shouldn't do is to create extras-testing or extras and let >> packages jump in without the QA process in place. Taking a buggy package >> out because of a new policy is going to be much more complicated. > > Let's see: > > Just a few months ago there was a great effort to close external > repositories and move everything to extras repositrory. You may mean "extras family of repositories. ie extras, extras-testing and extras-devel > Extras repository was open for everyone. Still is. So is extras-devel And users now know that extras has QA and extras-devel or extras-testing is less stable. > Now you suddenly change the rules and ask developers to jump thru who > knows how many hoops to get packages to extras. That does not improve > my confidence in the way Nokia manages maemo. Err, could you please stop giving Nokia all the credit for the maturity of the community. Maemo is growing up and wants users to have some confidence that the app they just installed won't crash their tablet. If they don't then extras-devel is still the wild-west. > How about leaving extras as is, and setting up a new repository called > nokia_approved_applications_if_you_install_packages_from_another_repository_the_world_will_end > where you do whatever QA you want to do. The repository you want: maemo_unapproved_applications_if_you_install_packages_from_this_repository_the_world_may_end is called extras-devel; feel free to add it to your sources.list David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reduce fremantle button spacing
Andrew Flegg wrote: > On Thu, Apr 16, 2009 at 20:36, Till Harbaum / Lists wrote: >> fremantle increases button sizes significantly to make them more >> finger friendly. However, some applications like osm2go are imho >> not suited for finger usage and those big buttons thus waste >> screen space. > > I don't know the answer to your question, but the "right" answer would > be to redesign the application such that it /was/ suited for finger > usage. That's the direction the platform is going in and consistency > between applications on Maemo should be pretty high up everyone's > priority lists IMNSHO. Disagree. I think you propose a possible answer - but although the platform should be striving to make it very easy to develop finger-friendly applications, I am *firmly* of the belief that it should not prevent or hinder those who see mobility of stylus-based apps as a tremendous benefit that the tablets provide. If the gtk or Qt frameworks forced things like minimum button size that (IMNSHO) would be making a huge blunder :) (And I'm betting the answer is something like a larger default setting for the equivalent of http://doc.trolltech.com/4.5/qapplication.html#globalStrut-prop - but I guess you use gtk) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where To Upload GPG Key??
Sebastian 'CrashandDie' Lauwers wrote: sig: question = ( to ) ? be : ! be; PATCH: - question = ( to ) ? be : ! be; + question = ( to ) ? be : be; since: to -> be, (! to) -> be => question David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
Simon Pickering wrote: Also, i think we should look at GOCR as the alternate toolkit that can be used for the project. >>> Looks like that project has been renamed to Conjecture now >>> (http://www.corollarium.com/conjecture/). >> Reading the EAN-13 barcode should not require to complicated ocr software >> I think the basic is to draw 3 lines over an image , make it black white >> and look for known patterns (first only a series of black white and >> then looking at the length). >> >> Do you think I am underestimating this part of the problem? > > No you're not underestimating it really, though in real life the black > and white are not so black and white, more shades of grey ;) > > Anyway this particular part of the problem (1D decoding) has already > been solved many times and it seems somewhat pointless to do it again > (as the existing 1D codes are pretty fast). > > Producing a useful interface to let people obtain a decoded > string/etc. from whatever sort of barcode is a worthy goal (and having > the code select from a range of decoders preferably), as is improving > the speed of some of the 2D decoders, as is producing web scraping > functions that could be used to obtain info about a decoded barcode. This came up in discussion recently on irc. Can I suggest you look at providing a dbus interface. This should give you hooks into a few areas and some well defined but well linked breakpoints for the project. It also lets you link to non-python solutions. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
It seems to me that the hildon 'platform' uses dbus and if we have some widgets that are designed to interact with the platform environment (like notifiers or session) then, when built for that platform, they can depend on platform specific things. so yes, I thing showMessage should use dbus for WS_HILDON David Antonio Aloisio wrote: > Hi, > IMHO using the Qt D-Bus API to rewrite some parts of libosso is more > easy that resolve the symobls, load and use libosso in Qt. > Kimmo said adding D-Bus dependencies in the widget is ugly, I agree > with him.. but... is this also true for the QStatusBar? > > In Qt we have a statusBar that manages and displays messages. > Currently this status bar is hidden just because we don't have it in > Hildon. I don't compiled out in order to preserve > the compatibility with the Qt Desktop application. > > Adding D-Bus into the status bar, we can display messages using hildon > passive notification dialogs just calling > > void QStatusBar::showMessage ( const QString & message, int timeout = 0 ). > > Is it cool? Any comment is welcome. > > Cheers, > Antonio > > On Wed, Mar 25, 2009 at 9:12 PM, Santtu Lakkala wrote: > David Greaves wrote: >>>> I meant gtk apps need to use osso-initialize() or they just don't work. >>>> Since libosso uses glib, I expect that's not really right for Qt apps. >>>> >>>> In particular I think osso-init.c calls glib setups that seem to hook into >>>> the >>>> glib context and I think the glib main loop - not used in Qt apps. >>>> >>>> eg line 503 in osso-init.c calls dbus_connection_setup_with_g_main() >>>> which: >>>> "Sets the watch and timeout functions of a DBusConnection to integrate the >>>> connection with the GLib main loop. " >>>> see: >>>> http://dbus.freedesktop.org/doc/api/html/group__DBusGLib.html#ga754eed235cc2b8153bd8f824b687d9e >>>> >>>> >>>> so libosso, as it stands, isn't suitable for Qt apps unless I'm >>>> confused :) > > Actually Qt has supported GLib context stuff since 4.2 (IIRC), so > libosso is suitable. That doesn't say that it's practical or nice, but > it should work. > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers > -- > Isaac Asimov - "I do not fear computers. I fear the lack of them." -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
Kimmo Hämäläinen wrote: > Haloo! Hi > The code is not that hard to follow, just take a look. (Btw. most of the > code/API was not written by me.) Basically it just connects to D-Bus > busses and allows further use of libosso functions to abstract some D- > Bus messaging/signals. OK. Searching for dbus interfaces etc will probably help here. >> OK - but do you have a list of things that we should do to make Qt >> equivalent to >> gtk? > > Gtk does not use Libosso :) I meant gtk apps need to use osso-initialize() or they just don't work. Since libosso uses glib, I expect that's not really right for Qt apps. In particular I think osso-init.c calls glib setups that seem to hook into the glib context and I think the glib main loop - not used in Qt apps. eg line 503 in osso-init.c calls dbus_connection_setup_with_g_main() which: "Sets the watch and timeout functions of a DBusConnection to integrate the connection with the GLib main loop. " see: http://dbus.freedesktop.org/doc/api/html/group__DBusGLib.html#ga754eed235cc2b8153bd8f824b687d9e so libosso, as it stands, isn't suitable for Qt apps unless I'm confused :) >> I seem to recall things like dbus messages on low memory and others. Are >> these >> documented? > > Check osso-hw.c. Code is still in SVN (login: guest/guest): > https://stage.maemo.org/svn/maemo/projects/haf/trunk/libosso/src/ Good pointer... yep, things like: com.nokia.dsme.signal shutdown_ind and save_unsaved_data_ind We don't want Qt apps ignoring these do we? >> The banner would be nice - but the dbus services listed above don't seem to >> be >> correct - and I can't find them using a dbus introspect (qdbusviewer) >> ie this bit (from original email) > > We don't have that in Fremantle. Currently I'm looking at Diablo... > We have a new service for starting > applications in hildon-desktop. You can learn these API things from > http://www7.connecting.nokia.com/nmp/osso/ossodm.nsf/WebAllByID2/DSD07052-EN > (currently in Nokia intranet only) Ah, I don't have that - can you post it? > As I said, Hildon widgets and Gtk do not use libosso at all (it would be > quite ugly since libosso depends on D-Bus connections). agreed - I am not sure how best to proceed with Qt - one of the trolls (I think) suggested extending QSession. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
Kimmo Hämäläinen wrote: > On Mon, 2009-03-23 at 14:44 +0100, ext David Greaves wrote: >> Hi >> >> Crossposting as I think this is a maemo-dev question of interest to Qt devs >> :) >> >> I am having a problem with my Qt applications and the osso window manager. >> Essentially the window manager is doing a sigkill which doesn't allow Qt to >> emit >> a closeEvent(). > > You mean D-Bus daemon is killing you 20-30s after you are D-Bus > activated? No. I know about that one :) ah, and as I write this I see Antonio has solved it :) \o/ But we still have issues > Maybe looking at this example helps: > https://garage.maemo.org/svn/maemoexamples/tags/maemo_4.1/maemopad/ Yes, used that - happy with osso_initialize() I actually would like to know what osso_initialize() should do so we can do the right things in a Qt app though. And your name appears a lot in the source Kimmo :) >> Digging into libosso and libossowm/osso-rpc.c I find >> >> #define HILDON_DESKTOP_SERVICE "com.nokia.hildon-desktop" >> #define HDWM_STARTUP_NOTIFICATION_IFACE >> "com.nokia.hildon.hdwm.startupnotification" >> #define HDWM_OBJECT_PATH"/com/nokia/hildon/hdwm" >> #define HDWM_STARTUP_NOTIFICATION_STARTING "starting" > > You don't need this. It's just for the "Loading..." banner in Diablo. OK - but do you have a list of things that we should do to make Qt equivalent to gtk? I seem to recall things like dbus messages on low memory and others. Are these documented? The banner would be nice - but the dbus services listed above don't seem to be correct - and I can't find them using a dbus introspect (qdbusviewer) ie this bit (from original email) >> Message:Method "starting" with signature "" on interface >> "com.nokia.hildon.hdwm.startupnotification" doesn't exist >> >> I installed qdbusmonitor and "com.nokia.hildon-desktop" doesn't provide >> hdwm.startupnotification or starting >> >> Nor do I see it on the dbus-monitor --session when my gtk app runs. Are you in a postion to help us write the Qt equivalent of osso_initialize() and help make Qt == Gtk David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
osso, muali , dbus and Qt closeEvent()s
Hi Crossposting as I think this is a maemo-dev question of interest to Qt devs :) I am having a problem with my Qt applications and the osso window manager. Essentially the window manager is doing a sigkill which doesn't allow Qt to emit a closeEvent(). A gtk app calls osso_initialize() which amongst other things registers a service name to the DBus.freedestop.org service. I've been through osso-init.c and osso-rpc.c to try and figure it out but, whilst I've made progress, I've not finished. So far I have: * added an entry into the desktop file for X-Osso-Service=com.dgreaves.shopper * created : /usr/share/dbus-1/services/com.dgreaves.shopper.service * added a QDBusConnection::sessionBus().interface()->registerService (name, 1 ); and connect(iface, SIGNAL(serviceOwnerChanged(QString,QString,QString)), this, SLOT(serviceOwnerChanged(QString,QString,QString))); dbus-monitor is showing very similar messages for gtk and my Qt apps now. I've hooked serviceOwnerChanged and try to send out a ReleaseName to org.freedesktop.DBus. However I'm still getting killed. Digging into libosso and libossowm/osso-rpc.c I find #define HILDON_DESKTOP_SERVICE "com.nokia.hildon-desktop" #define HDWM_STARTUP_NOTIFICATION_IFACE "com.nokia.hildon.hdwm.startupnotification" #define HDWM_OBJECT_PATH"/com/nokia/hildon/hdwm" #define HDWM_STARTUP_NOTIFICATION_STARTING "starting" This failed as Name:org.freedesktop.DBus.Error.UnknownMethod Message:Method "starting" with signature "" on interface "com.nokia.hildon.hdwm.startupnotification" doesn't exist I installed qdbusmonitor and "com.nokia.hildon-desktop" doesn't provide hdwm.startupnotification or starting Nor do I see it on the dbus-monitor --session when my gtk app runs. Any pointers? David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo & Linux mainstream
Karl Eichwalder wrote: > [EMAIL PROTECTED] writes: > >> > > Nice things, but first try to get the basics right ;) > > I'd like to record GPS tracks while hiking for 7 x 8 hrs (= 1 week) > without recharging. Then buy one of these: http://www.amazon.com/i-Blue-Bluetooth-Data-Logger-Receiver/dp/B000NK3G2Q iBlue 747 (because that's essentially a hardware requirement unless you're wish-listing for the N9xx) David PS Really - the 747 sounds perfect for whay you want - rugged, small, long lasting, excellent GPS performance. -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PIM stuff (was Re: Projects Nokia should support (yours?))
Graham Cobb wrote: > On Friday 24 October 2008 16:46:12 Sarah Newman wrote: >> David Greaves wrote: >>> I propose: >>> * The GPE suite (especially synchronising) >>> * Canola (some limitations that become annoying quickly) >> GPE seconded FWIW. I might be able to help with finger-friendliness and >> maybe location-based task reminders (as I have the time, no kidding this >> is short for many of us.) > > I didn't suggest GPE because I had the impression that Nokia may have plans > to > solve the PIM problem in some different way (some other app?) So, lets see if their money and mouths match ;) Rather than "not invented here" - lets see a superb foundation enhanced in ways that benefit the linux ecosystem at large... David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PIM stuff (was Re: Projects Nokia should support (yours?))
Quim Gil wrote: > More? I propose: * The GPE suite (especially synchronising) * Canola (some limitations that become annoying quickly) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
