Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Thursday 06 October 2011 07:33:24 Carsten Munk wrote: We have chosen to move out the hardware adaptations and UX'es out of the core, into the community surrounding it, to get rid of a lot of politics - to concentrate on what's technically good and benefits us all - not having to maintain our own mobile distribution ourselves. I think I understand your point but there is a big danger there. My day job is marketing. And there is a lot of marketing involved in building an open- source community. In order to get contributors, or to get vendors to use you, you need to be seen as viable and successful. And a lot of that is tied up with end-users: the blogs and web sites will be talking about you if users are talking about you. Your strategy is going to require that you have a successful and visible vendor project and, even then, you need to make sure that people are mentioning your core when talking about the associated project. My personal view (which is partly based on my marketing job) is that you have to start off focused on a very visible end user experience in order to get the project the necessary publicity. For your own governance reasons you will probably want to make sure the split between core and vendor is clear, but from the outside world they have to look like one to start with. The bottom line is that many potential community members will be doubtful that your project can be successful, unless you can show them a working (preferably great) end user experience (including hardware). Many projects have been and gone, either sponsored by big companies (we are all familiar with those!) or purely hobbyist (e.g. Cordia now that the Cordia Tab seems dead). If the Cordia Tab was going to happen then Cordia might have been the viable end user project to get you the publicity but without hardware it seems to be going nowhere as well. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
On Tuesday 08 March 2011 12:55:45 Philip Van Hoof wrote: But I have the feeling that we won't see *any* numbers whatsoever. I realise the question was directed at the MeeGo architects but I would hope that the Nokia product managers for the PIM/tracker developments had quantitative requirements for performance and scalability. What were they? Did you meet them? If I had been the product manager I would have tried to get requirements in three ways: 1) Put an engineer for a couple of days on testing market leading enterprise devices (hint, Blackberry). Determine any practical scalability limits (numbers of events, contacts, emails, etc) as well as performance with large databases (update, lookup, etc). 2) Ask my own (Nokia) sales people how they actually use their handheld devices: how many events, contacts, emails, etc they have on their device? How many different folders they have them divided into? How and why do they look people up? Do they use a card scanning app on their phone to import business cards? Do they consider the phone or Exchange to be the master? What would happen if you stole their phone now and refused to give it back? Etc. I am sure the answers would be very different to the way the engineers or even product managers use their devices. 3) Ask the network operators what their requirements are: many of them have pretty clear requirements. Nokia used to be the best at understanding and interpreting market requirements. In the old days, that was not only for the consumer segment but even for business (there is a reason the 6310i is still available on eBay today!). Are there really no quantitative requirements you can tell us about, Philip? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] compliance spec questions
On Sunday 28 November 2010 05:41:44 Alison Chaiken wrote: My apologies if this is not the best mailing list on which to ask: I suspect meego-community may be a better list for the first question. 1. Would the Compliance spec prevent the problems that MS has caused with the encrypted SD card in Windows Phone 7? I think it is unlikely, as Nokia will obviously be making sure that the Linux Foundation does nothing to prevent them imposing the restriction in their devices that having purchased the device you have to allow it to register with My Nokia, and provide unspecified personal information, before you can use the device (see http://wiki.maemo.org/PR1.2_compulsory_My_Nokia_subscription for more information on this). Microsoft's decision to password protect SD cards seems minor in comparison. The fact that MeeGo brand compliance will not prevent that sort of unethical behaviour from device manufacturers is the reason I stopped all my contributions to MeeGo and Maemo, I now only plan to contribute community applications, not to the testing or development of the base platform or tools. A purely personal decision, of course. I am sure the meego-dev participants would prefer us to take any further discussion of this issue to the -community list. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
On Thursday 11 November 2010 22:15:26 Quim Gil wrote: For the big majority of application developers targeting MeeGo, the Qt / Qt Mobility APIs should suffice (plus OpenGL ES for the specific segment willing to use it). If any of these developers is not finding what he is looking for, then bugs against Qt Mobility are welcome (I asked the maintainers and this is the answer they gave). It depends on what you mean by application. If you mean the sort of apps that you find in the Apple iStore or on Ovi then I agree: the majority of app developers have what they need in Qt (although there is a substantial minority who need platform APIs as well -- even 10% would be a lot of developers). On the other hand, I don't agree that it is true for the large applications that don't exist in the handset world today but which many people are working on (like the mobile device equivalent of application suites routinely found on PCs such as MS Office/OpenOffice or Kdepim, or social network integrators, or augmented reality experiences and more). Those sorts of applications are multi-faceted and will build on many libraries of their own and others, require carefully tuned databases, specialised backup and synchronisation, will provide their own APIs and be extendible with other applications layered on top, plugins, etc. As we say in the telecom network world, one man's service is another man's enabler -- a mantra which is only just starting to be adopted in the handset app world. Proprietary platforms, of course, deliberately try to make it hard for people to develop those sorts of large applications (particularly the ones which provide an environment in which the user spends most of their time) because they would compete with the device brand itself for the mindshare of the user. Apple wants people to buy an iPhone and get lots of apps which add value to it. They don't want people to decide they need a certain application and then go looking for a device to run it on. But MeeGo, controlled by the LF and supporting a range of devices, should be taking the opposite approach: it should be encouraging people to build compelling and exciting environments, re-using free software, and running on a large range of platforms. I am disappointed that the LF appear to have let MeeGo compliance be captured by Intel and Nokia to make it hard to create these game-changing applications. MeeGo compliance certainly should sit on clear principles, and those principles should be that a compliant platform offers all the APIs and tools to allow creation of these sorts of new applications, as well as the openness to allow users to install them. Maybe a philosophical discussion over a Guinness next week! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Monday 20 September 2010 00:46:32 Skarpness, Mark wrote: On Sep 19, 2010, at 4:23 PM, Graham Cobb wrote: Take the compliant word off the table, reduce the heat in this thread, and let marketing do their job of brand creation, don't try to guess what they will decide. Of course we are not focused on the exact marketing name here (though a name like DLNA certified, which shows up on lots of consumer devices, is pretty similar to MeeGo Compliant). My point is that the technical contents of the MeeGo compliance spec absolutely do matter to the marketing people...because that's the foundation of the marketing messages (i.e. what does MeeGo Compliant actually mean...). Great, it looks like we are making progress. Here are my proposals for the small number of text changes required to make this a technical definition of applications which will qualify for the marketing brand. I suggest the following replacement text for the Introduction (lines 5-11): --- start replacement text --- This specification defines the operating system interface and environment of the MeeGo operating system to enable binary application compatibility. It is intended to be used by both application developers and system implementers. This spec defines the requirements for a system to be MeeGo Compliant and the requirements for applications to receive guarantees of compatability across MeeGo Compliant systems. MeeGo is a registered trademark of the Linux Foundation, which controls the usage of the brand and trademark. A requirement for permission to use is compliance with the requirements of this specification. An additional MeeGo brand will be defined for applications which will allow users to quickly recognise applications which are guaranteed to be compatible with their system (possibly subject to the Profile). In this version of MeeGo, this brand will only be available to MeeGo Core Apps (as defined below). Possible extension to other applications is a matter for further study and will be considered for future MeeGo versions. --- end replacement text --- Replace lines 21-22: System implementations may only claim compliance to a specific profile. Applications may claim compatability with a specific Profile or more generally to MeeGo to target multiple profiles. Delete lines 23-24. The substantive change is the following replacement text for sections 1.3.2 and 1.3.3. --- start replacement text --- 1.3.2 MeeGo Platform App An application is defined to be a MeeGo Platform App if it meets the following requirements: Include list from existing section 1.3.2 o It shall be packaged into a single package file with no dependencies on any packages except packages which form part of the MeeGo API or Platform API. o It shall only use APIs and features included in the MeeGo API or Platform API sets. 1.3.3 MeeGo Core App An application is defined to be a MeeGo Core App is it meets the following requirements: o It meets all requirements for a MeeGo Platform App o It shall be packaged into a single package file with no dependencies on any packages except packages which form part of the MeeGo API. o It shall only use APIs and features included in the MeeGo API set. Note that MeeGo Core Apps are a subset of MeeGo Platform Apps. 1.3.4 Forward and Backward Compatability MeeGo Core Apps are assured compatibility with all future versions with the same MeeGo major version number. MeeGo Platform Apps are assured compatibility only with the specific MeeGo version they were built for. There are no assurances that an application constructed for a particular version will run on any earlier version. --- end replacement text --- In section 3.1, only two small changes are required: Line 141: Application Packages Line 142: Applications SHALL be packaged in RPM package file format. Similarly, in section 3.3: Line 227: Application Executables Line 228: Application executables shall be in the ELF format as described above Lines 231-232: delete. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [compliance] Different view on app compliance
On Sunday 19 September 2010 08:55:13 Carsten Munk wrote: 2010/9/19 Graham Cobb g+me...@cobb.uk.net: Personally I don't think Staging is needed as part of the Compliance definition (it might be needed for other reasons). The rule should be: an app can depend on any other package which is maintained by the same entity (person/company/project team/whatever) and which is available from the same repository. Can we test this rule properly? Staging would have to be part of compliance for the reason that we can't assume a MeeGo compliant app would install otherwise. Sure we can test it: the candidate submits all the source packages which are required for the app -- the testing script can check they all have the same maintainer and that (between them) they satisfy the dependencies. It can even build them and use them to install the candidate app on a test system if you want. This can even be extended to non-free packages (the candidate can have the choice of submitting source or binary packages or any combination). Actually, I think it is your proposal which can't be tested: non-free apps will not submit any source packages to the tester so you don't know if they are built from the same source package (unless you choose to just believe the information in the binary package). Of course, we can't test the available from the same repo bit, but that is no different with your proposal of having the apps built from the same source package. App-stores will not take source packages as submissions, they will take binary packages (as many apps will not be OSS) -- it is up to the app-store to determine that all the necessary dependencies have been submitted before letting the app go live. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Saturday 18 September 2010 19:48:04 Skarpness, Mark wrote: I don't agree that having MeeGo compliance support componentised applications is an objective we should take for the near term. I would rather us focus on solving the core problem (self-contained compliant app runs on any compliant device). I could agree with, and support, that view if you remove the term compliance. That is what is causing a lot of the concern and heat on this topic. There is nothing non-compliant to MeeGo about componentised apps but there are good, practical, reasons to first solve the run anywhere problem for non-componentised apps. So, how about taking the heat out of the argument by replacing the concept with words that are more neutral. Also recognise that the compliance doc is essentially technical and any term used should be independent of the marketing brand used to publicise the concept. Instead of MeeGo Compliant apps create a new term for the compliance document to describe those apps which are simple (one package) and which only depend on the MeeGo Core. How about MeeGo Core Apps? The name doesn't have to be perfect because it is a technical definition, not a marketing term. Then get the Marketing team to decide on how those MeeGo Core Apps will be branded in the outside world. My suggestion: MeeGo World -- a world of apps for all MeeGo devices. The MeeGo 1.1 version of the branding rules will state that only apps that meet the defintion of MeeGo Core Apps can call themselves MeeGo World apps. Before we require compliant devices to support apps with external dependencies, I think we need to demonstrate that the value of that justifies the cost and complexity. For example - show what can be done with MeeGo Extras following this model. We can add this to a future version of compliance if everyone says wow, that's great - I really want this on my next device Fine, but just delete the concept of compliance for apps altogether and replace it with what we really need -- a simple marketing concept which can be explained to both vendors and users but which does not imply that there is something bad about apps which don't meet the criteria. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sunday 19 September 2010 23:30:18 Skarpness, Mark wrote: I want to make the marketing team job really simple - market MeeGo Compliant Applications Sorry, my day job is marketing. We don't let engineers choose names! And for good reasons!! I have no idea what brand MeeGo marketing will choose for the apps which work on all devices, but I do know it won't contain the word compliant -- not for B2C marketing. Look around you -- do you see the word compliant on any consumer equipment or service (even on the box, let alone in the brand)? Does your HD TV say it is HD compliant? No, it says it is an HD TV. Take the compliant word off the table, reduce the heat in this thread, and let marketing do their job of brand creation, don't try to guess what they will decide. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [compliance] Different view on app compliance
On Saturday 18 September 2010 20:58:23 Carsten Munk wrote: If you have an API you'd like to share with the world, put it in Staging and take responsibility for it. But not all the packages that form part of an Application will be built from the same source package or be suitable for general use by the world. Consider any suite of related applications (e.g. an office suite or a set of games using a common engine or the GPE suite). These will generally consist of several apps (of which the user may install one or more) and several libraries which support those apps but which are internal to the suite. For example, if I created a suite of apps to read and write Microsoft Office files I would certainly create libraries to handle the various file formats and then access them from my documents, spreadsheets and presentation applications. You are saying these apps could not be MeeGo Compliant unless the libraries were all put in Staging (and, presumably, proposed for future inclusion in MeeGo). But that condition is unreasonable: the app developer may not be willing to offer support to anyone outside his own project using the libraries -- that shouldn't stop his app being Compliant. * Remove all dependencies which originate from the installation source and is produced by the same source package as application A workable condition might be to say maintained by the same maintainer (instead of produced by the same source package). In that case, we would still be able to avoid the problem of someone else making incompatible changes to the library (because it is owned by the same person who owns the app). There is the problem of Staging that app stores that do not allow other installation sources than themselves would have trouble. The solution is obviously that Staging repo inclusion is part of MeeGo compliance for dependency solving, but we're not quite there yet to convince this is worthwhile. Personally I don't think Staging is needed as part of the Compliance definition (it might be needed for other reasons). The rule should be: an app can depend on any other package which is maintained by the same entity (person/company/project team/whatever) and which is available from the same repository. If an app store doesn't make packages available as a repository (for example it sends an RPM to the device) then the app-store app on the device would have to be extended very slightly to be able to receive multiple rpms (for example as a zipfile or tar file), split them out and install all of them. This is not a heavyweight requirement for any device vendor (MeeGo could even provide example code). Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thursday 16 September 2010 22:44:43 Arjan van de Ven wrote: this is where you get in trouble if vendor Z ships libbar but in a different configuration/version for some widgety nifty thing that they do... ... and that version/configuration is not ABI compatible. So, instead, you propose that every user is exposed to major security issues when a security bug is found in a popular library which many applications statically link with? Problems that they have no way of being notified about because nobody knows which applications use the compromised library? And even if they know about it, no way of fixing it except removing the app and waiting for an update from the author, if they can be bothered (after all, they already got their money). To me, this issue is the killer, which makes encouraging single package applications a complete non-starter. Just imagine the Engadget article when a serious security issue is found in a popular Twitter or Facebook library: All MeeGo users told to uninstall all MeeGo Compliant social networking apps while vendors rush to fix problems. MeeGo Extras apps can be left installed because the security update is being pushed automatically to affected devices. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tuesday 14 September 2010 08:26:23 Dave Neary wrote: I agree - MeeGo Extras should be a repository of compliant applications. And a compliant application, in this context, should be an application which uses only MeeGo core APIs or MeeGo compliant libraries distributed in Extras. I am a strong supporter of the Extras concept but, after reading this thread (I have been away) I believe we do not need the term MeeGo compliant to apply to Extras. What we *do* need is to be able to use the MeeGo name, in a separate brand for Extras. I think MeeGo Extras can be that brand. The MeeGo trademark usage rules should be extended to say that any package can claim to be a MeeGo Extra if and only if it has been accepted into the MeeGo community Extras repository. And one of the conditions for acceptance need to be that it depends only on MeeGo core repositories or other MeeGo Extra packages. My day job is marketing, and I think that if the mark is properly protected, we (the community) can make MeeGo Extra a recognised and valuable term. This does not solve the problem of how vendors encourage open source developers to create and make available apps which depend not only on MeeGo core but on the vendor additions (and also on each other). Any app built for a vendor-specific GUI will have dependencies on packages in neither MeeGo core nor in MeeGo Extras so can't use the MeeGo name. But that is the vendor's problem (and Nokia will need to solve it for Ovi if they want the equivalent of the GPE apps, say, to be made available for their Nokia-specific GUI environment). Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Wednesday 15 September 2010 17:13:43 Skarpness, Mark wrote: But that would mean that app stores would not be able to sell all compliant apps - which is not what we want. But app stores are not going to be in the business of selling compliant apps! Most commercial apps (which is what apps stores will be selling, as opposed to giving away for free) will want to be tightly integrated with the platform, using all the vendor extensions and features. So, they will not be MeeGo compliant anyway! Surely no one expects that Angry Birds will just have one MeeGo version, that is MeeGo compliant? I assume it will have one version using the Nokia proprietary GUI, one using another vendor's proprietary sound system, another using another vendor's proprietary haptic feedback system, etc. Each version will be tailored before being put in that vendor's app store. This whole MeeGo compliant thing is about creating very high volumes of low-end, mainly free, apps. The high value apps that app stores care about are not affected. And for low end apps, it has to be quick, easy and cheap to develop or port them. And many of them will be in MeeGo Extras. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo / data synchronization in MeeGo: hello world!
On Friday 20 August 2010 07:54:00 Patrick Ohly wrote: This thread is in danger of being off-topic for this list. I'll try to keep it focused on the Buteo design and source code; hopefully that'll keep it relevant for this list, otherwise we should move the thread. Thanks for your response, Patrick. I certainly hope it is on-topic for this list (and I note your other email asking Dawn for clarification) as Buteo is a MeeGo component. Note that I am not interested (at the moment) in either what features are exposed to the users by the UI, nor in the API for adding and controlling sync. I am interested in the design decisions of the sync service itself and the requirements they are based on and, in the absence of documents, I am using use-cases to try to clarify my questions about the design. And it is working because we seem to have uncovered two design bugs already. One already reported and the other not. I am sure none of the other meego- lists is more relevant for this discussion. If this is not the right list then there needs to be a Buteo-specific list (with Buteo viewed as an upstream project that MeeGo is using instead of as part of MeeGo). That would also avoid the need for this cumbersome CC: list. Note that this requirements for service profiles in /etc is by design. It has the side effect that the user cannot define a custom sync service in the GUI (see http://bugs.meego.com/show_bug.cgi?id=4941). I see this as a bug and will work the issue in bugzilla. One additional question, though, does the design allow for multiple user sync profiles which use the same service profile? For example, having installed the ScheduleWorld service profile, can the user profiles specify multiple local calendars to synchronise with different remote ScheduleWorld calendars (with different usernames)? There is nothing that prevents defining multiple calendar entries under different names in a service profile, but again, this is nothing that the user can change. Putting aside the user access for the moment, is there anything to stop the same local calendar instance appearing in multiple service profiles? For example, synchronising one local calendar against two remote calendars? 4) Each calendar can synchronise as a master (not a device) with other devices (e.g. other phones or a kitchen clock or something). This is particularly important for netbook mode but it should also be available on handsets. Note that there are currently issues with data loss when doing two-way sync, primarily in this mode, but also when syncing as device with a less capable master: http://bugs.meego.com/show_bug.cgi?id=4897 Thanks, that is a big part of what makes sync complicated and a big part of what Synthesis and OpenSync do. I will add myself to the CC: list to watch that bug. 6) It should be possible to schedule syncs (the scheduling is a system issue, not a Buteo issue) msyncd is the core Buteo daemon, and it controls the schedule for running syncs. Why is there a scheduler in a sync subsystem? That seems to be a design bug. It should be using whatever the system provides as a scheduler (note: I am not talking about the UI -- it may well be relevant to present scheduling screens to the user as part of configuring sync). Is there an API (e.g. using dbus) to allow syncs to be initiated under control of some other scheduler (or, for that matter, some other component's UI)? [multiple calendars] [SK] This agreement is something that would be part of the protocol in use. Apparently SyncML does not have this facility. It does. uri=calendar/work and uri=calendar/personal can be used. The only problem is that most existing services do not offer that. In my limited experience, most services seem to allow the URI to be specified (not least because of the different values expected by different devices). It isn't clear to me how the URI the remote side specifies in the SyncML request interacts with the URI values in the service profiles (or, more importantly, the values in the user's own sync profiles). Can you explain a bit more how the LocalURI and RemoteURI are used? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo / data synchronization in MeeGo: hello world!
On Friday 20 August 2010 13:39:34 Patrick Ohly wrote: On Fri, 2010-08-20 at 11:41 +0100, Graham Cobb wrote: On Friday 20 August 2010 07:54:00 Patrick Ohly wrote: [...] And it is working because we seem to have uncovered two design bugs already. One already reported and the other not. Which one wasn't reported? The scheduler. See http://bugs.meego.com/show_bug.cgi?id=5619. I am not saying it was necessarily the wrong decision when it was merged, but that doesn't stop it needing to be fixed as soon as a system scheduler is available. [multiple calendars] [SK] This agreement is something that would be part of the protocol in use. Apparently SyncML does not have this facility. It does. uri=calendar/work and uri=calendar/personal can be used. The only problem is that most existing services do not offer that. In my limited experience, most services seem to allow the URI to be specified (not least because of the different values expected by different devices). Sync client allow it to be specified because it typically varies among services, as you said, but which service let's you configure multiple URIs? SyncEvolution and your custom Synthesis allow that, but I'm not aware of a consumer service supporting that. In the sense that one can set up different accounts which sync the same device but specify different URIs. By the way, the various bug reports make mention of required use cases. Can these requirements be published somewhere so we can all read them? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo / data synchronization in MeeGo: hello world!
On Thursday 19 August 2010 13:09:02 sateesh.kav...@nokia.com wrote: -Original Message- From: ext Yves-Alexis Perez [mailto:cor...@debian.org] Sent: 19 August, 2010 17:15 Emphasis on *at a time*. And by the way it's not possible to do that at the moment to do that, everything as to be in the same calendar if you ever want to sync it somewhere. When using sync with the device as a “server” (meaning, another, non MeeGo device, requests the sync), it should ask for which calendar/contact/task/... it wants specifically. [SK] This is infact possible in N900. There is a pop-up dialog box that asks the user to choose the dialog and this choice very much depends on the kind of concept we define for MeeGo (for which the UI spec. is not yet defined) It feels like this is being implemented without any clear requirements being specified -- is there a requirements spec that can be published? Sync is a horribly complex area (as those of us who have worked on OpenSync on and off for many years know only too well!). And different users have different requirements. I am wondering whether my use cases are being allowed for -- it is hard to work out from what has been said so far. Let me try to describe them (note the usage of client and server in SyncML can get quite confusing -- to try to reduce confusion, I will use device for the typical role of a handset and master for something like google or exchange). 1) I have multiple calendars on my device (say work, personal, children). 2) Each calendar synchronises (as a device) with a different master (say MS Exchange for work, google for personal, etc). Some of these are SyncML interfaces, others may be applications directly on the device (e.g. MfE), others may use protocols which I, as a developer, want to add. 3) Each calendar can synchronise (as a device) with multiple masters (personal calendar synchronises with google and also synchronises with kontact on my desktop). This is very often used as a poor man's way to sync two applications which won't sync directly! 4) Each calendar can synchronise as a master (not a device) with other devices (e.g. other phones or a kitchen clock or something). This is particularly important for netbook mode but it should also be available on handsets. 5) External masters must be able to initiate syncs with various calendars on the device without any user intervention (with approriate access credentials, user approvals, and calendar names). So, for example, my desktop might synchronise automatically every night if I have my device plugged in, or might synchronise automatically as soon as it sees me come within bluetooth range. 6) It should be possible to schedule syncs (the scheduling is a system issue, not a Buteo issue) to be initiated by the device, without user intervention, to various masters (for example, my personal calendar might sync with Google at 23:00 every day and my work calednar with MfE at 08:00 every day). 7) It should be possible for the user to initiate a sync where the MeeGo system acts as a master for another device, and it should be possible for external devices to initiate syncs with the MeeGo system acting as a master. 8) Everything I have said about calendar applies to contacts and other PIM items in the same way. These use cases are real. With the exception of the acting as a master, I use these with GPE on my Maemo device today (but not using SyncML). The master mode does not currently work just because I have not maintained my port of OpenSync to Maemo but I did use it in the past. When using sync with the device as the “client” (for another device or to http servers or something) then when configuring that agreement on the device, one would chose which calendar/contacts/tasks/.. to be part of that agreement. [SK] This agreement is something that would be part of the protocol in use. Apparently SyncML does not have this facility. One way is to define an extension to SyncML and hope that the target also supports it (Google anyway uses REST for Calendar sync, so this is out of question) Hmm. Patrick knows much more about SyncML than I do but I thought there was a database name in SyncML. I would expect the database name to be something like calendar/work or calendar/personal (with just calendar being a valid name for a default calendar). For Google I would assume that different URLs would be used for different calendars. Not sure if I use “client”/“server” correctly, feel free to point me to the correct terms. My understanding of the SyncML terms is that they are the other way around. But I may be wrong. That is why I avoided using client and server above! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] nfs package in meego ?
On Monday 26 July 2010 10:29:19 Jeremiah Foster wrote: I'm not fully convinced there is a need to maintain NFS in MeeGo and I think everyone would prefer less complexity so perhaps we can define an end user use case which clearly demonstrates the need for NFS that sshfs doesn't fill? I think end-user use cases will be quite rare -- but then that is what the community is for: to support rare or niche end-user requirements. My use case is a developer use case. I am sure I am not the only developer to have my development environment built around NFS. Files live on servers and are accessed over NFS. Workstations, build machines, regression test machines, manual test machines all create, edit or access the files in the same way, over NFS. While NFS is not perfect, it works quite well for this sort of setup and I have been using it for close to 20 years. Many of those machines are virtual, and are running all sorts of strange software (for example I have several different VMs running different Maemo build instances). Not only am I unwilling to completely change my development environment for one target platform, but my use of VMs means I really feel the impact of every CPU cycle expended, particularly in automatic (nightly) builds and automatic testing. My builds already can't all run in one night so some platforms only build every 2 nights. If I had to use sshfs I am sure the slowdown would be very significant and I would be looking at nightlies happening every 3 or 4 nights! The lack of NFS means I am currently limited to doing all MeeGo building and testing in chroots, not in VMs. If/when I want to start supporting MeeGo Handset that will probably be a problem. My guess is that this sort of environment is not that unusual. On the other hand, it could be supported just as an SDK configuration, without being available on production systems. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] nfs package in meego ?
On Saturday 24 July 2010 07:26:21 Yves-Alexis Perez wrote: On sam., 2010-07-24 at 00:07 +0200, adhyas.avas...@nokia.com wrote: How do I access my videos/files on that server from my MeeGo handset? Or do you think this is not a common use case? Imho that would be a use case for some UPnP stuff, which I guess is something Meego (will?) support. Maybe, although there are many setups where UPNP doesn't work (mainly across routers). I think it is fair to say that NFS will be an unusual requirement but not a non-existent requirement. Ideal for community support. If it is possible for a community member to create a package to put in the community repository with the necessary kernel modules and userspace utilities then that seems reasonable. On the other hand, Arjan seemed to say that necessary options were not enabled in the kernel build -- if so, that is a mistake which should be fixed. Community packages should not be replacing the kernel! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Bugs being incorrectly closed as INVALID
Three of my nine bug reports have now been incorrectly closed as INVALID. I'm not precious about resolution status, as long as problems are reported and then resolved but this seems to have got out of hand. Just in case anyone is using the statuses in any sort of reports it would be useful if we were all provided some guidance in the use of the correct resolution reasons! The Bugmaster (do we have one for MeeGo?) might also like to occasionally review some of the RESOLVED bugs to make sure their status is correct and fix ones which are not (with a comment, so that both submitter and developer understand what status should have been used and why). Bug 2705 is the most ridiculous -- it was closed as INVALID because the fix was already in git but will not be available until the 1.1 release! It should have been closed as FIXED. Bug 3058 should have been closed as WONTFIX. Bug 446 should not have been closed at all until the documentation in the Wiki had been updated, then it should have been closed as FIXED (in the end, I fixed the documentation myself after the developer closed the bug as invalid). Either don't use statuses at all or use them correctly. If we need more statuses, then add them. The INVALID status should be reserved for bugs which are incorrectly formatted, spam, insufficient information, etc. It is not reasonable to use it for genuine and meaningful bug reports even if you disagree that they are a bug (that is what WONTFIX is for). It is even less correct to use it for bugs you have actually fixed!! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Power Managemengards
On Wednesday 23 June 2010 16:24:39 Arjan van de Ven wrote: i can go on and on, but... with devices being almost always on battery, and your examples very visibly and annoyingly degrading the experience... (and often NOT being about AC/Battery but about where the device is at that point in time) You may be right. But, on the other hand, you may not be. I want the system to enable great and innovative ideas for apps. Unfortunately, that also means it enables crappy and useless ideas. So be it. Let the users decide which app behaviours they prefer: the apps the users prefer will win. It should be up to the app developer. If they have a neat idea for how to adjust behaviour dependent on whatever they feel are the appropriate parameters (power, temperature, connectivity, time since last update, what I had for breakfast...) then they should be able to do it. The system should provide the information the app developer needs to implement their ideas and the users will judge them. They may even be developing an app which is completely different to the way anyone on this list expected the device to be used. Great! Graham P.S. Personally I think that after the hype about the iPad has died down, tablets will go back to being kitchen devices -- normally sitting in a charging rack, picked up for a few minutes to walk around the kitchen measuring out ingredients, etc. So, they will spend most of their time connected to power, although not necessarily to a high speed network. I might be wrong -- I have been before :-) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Show white window when run the simulator on MeeGo-SDK
On Wednesday 16 June 2010 05:34:42 Xu Cheng wrote: Graham Cobb, thank u very much. But i didn't solve the problem. I may not have made myself clear. Try either (or both) of the following: I input command by your way: $ xhost +local: $su -c meego-sdk-chroot Downloads/meego-sdk-0524 root Try using: su -c meego-sdk-chroot Downloads/meego-sdk-0524 - root (note that the - is preceded and followed by a space) r...@meego-netbook-sdk:/# export DBUS_SESSION_BUS_ADDRESS=startmeego-debug r...@meego-netbook-sdk:/# startmeego-debug Try: export DBUS_SESSION_BUS_ADDRESS= startmeego-debug The problem is that DBUS_SESSION_BUS_ADDRESS must either be undefined or must be a null string before invoking startmeego-debug. It seems to be deliberate that startmeego-debug doesn't start dbus if it is already running but I am beginning to think it should be changed. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Show white window when run the simulator on MeeGo-SDK
On Wednesday 16 June 2010 11:58:25 Graham Cobb wrote: The problem is that DBUS_SESSION_BUS_ADDRESS must either be undefined or must be a null string before invoking startmeego-debug. It seems to be deliberate that startmeego-debug doesn't start dbus if it is already running but I am beginning to think it should be changed. Reported as bug 3156. By the way, if this turns out to be your problem you may want to vote for the bug! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Window management for GTK apps
On Monday 14 June 2010 15:31:14 Tomas Frydrych wrote: Nope, the WM is not supposed to do that, if you want the window undecorated (e.g., you providing your own decors), you need to tell the WM. Oh, so it is not part of the MeeGo style guide that full-screen apps are not supposed to have titles? I had assumed, from looking mainly at Calendar and Contacts, that that was a requirement. It certainly seems to look nicer that way. By the way, where do I find the MeeGo Netbook UI style guide? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Window management for GTK apps
I am trying to port the GPE apps to MeeGo (mainly for my own use, as I maintain these apps in Maemo, but it is also a learning experience and others may find them useful). These are GTK-based apps. So far, I have got gpe-filemanager (a simple GPE app) working in the Netbook SDK environment. The first thing I have noticed is that it comes up in a relatively small window, with no window manager decoration except a title and a Close button (and a small window border which cannot be grabbed). There is no way to change the window size, maximise, minimise, etc. I think the MeeGo UI model seems to be that every application is maximised. I had assumed the WM would either do that or provide buttons for the user to request it. Should I be doing that myself in my app (i.e. explicitly maximising it on startup). Or should I submit a bug report on the WM that it isn't maximising my app (by the way, at some point during the usage of the app it does suddenly decide to maximise it --- I haven't worked out what is going on yet)? By the way, any suggestions for how the app works out it is running in an environment where it should start out maximised (or any other MeeGo specific actions)? Of course, I can just add some conditional code and create a configure option but it would be nicer if it could work it out for itself. Graham P.S, In case it isn't obvious, and you aren't familiar with the dumb questions I have previously asked in the Maemo world, I am not a GUI guy -- I am much happier with kernel code. But I am learning more than I ever thought I would about GUIs! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Sqlite2
I am trying to port an application which uses Sqlite2. Does anyone have a MeeGo rpm for sqlite2? I realise Sqlite2 is no longer supported or recommended. But this application uses it (and users may have existing databases they want to move over). I built Sqlite2 for Maemo and will do the same for MeeGo if necessary but I am wondering if anyone has already done it. If I am going to build it myself, is there somewhere I should look for a pre-existing RPM source package (e.g. from Fedora) which I can use rpmbuild --rpmrebuild to build for MeeGo? That would be the analogy of what I did for Maemo: take the source package from Debian and just build it for Maemo. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego 1.0 SDK issues
On Friday 28 May 2010 09:03:59 Wu, Jackie wrote: Currently, it does not work in a virtual box. The pre-requisites to run the SDK is at http://wiki.meego.com/Getting_started_with_the_MeeGo_SDK_for_Linux#Pre-requ isites. So, I guess it is time to have this discussion, which has been the elephant in the room for some time. Those requirements, for the SDK, are completely unacceptable. I understand the requirements for optimising MeeGo to certain platforms and limiting the supported targets (although I can't say I am happy with limiting it to particular manufacturer's CPUs). But that only applies to the target systems. As a developer, it is not acceptable to me for MeeGo to limit my choice of development system. Although I am a hobbyist developer, I believe that would be true even if I were a professional developer: MeeGo would not be my only target platform and decisions on development systems are not made on the basis of requirements for one particular target. It is essential that the MeeGo SDK works on any major platform. In particular, AMD64 as well as IA32 and any desktop or server Intel or AMD chip from at least the last 3 years. And any graphics device supported by a major Linux distribution. works primarily means development tools: compilers, debuggers, etc. The graphical environment doesn't have to work well, just well enough that programs can be developed, tested and debugged. Of course they will have to be tested again on real targets but that may not be a development machine but a special test machine. And the answer isn't application developers will just use Qt -- the SDK is for platform development. Many developers, of applications that are more than just toys, need to use the full SDK. Certainly in my case, if those requirements for the SDK stand, I am not able to join the MeeGo community. I believe the solution is going to be that MeeGo has to provide a third target: not just the existing Intel and ARM targets but a standard x86 target. Only supported, by the SDK team, for development, not for users. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of hildon?
On Monday 24 May 2010 11:43:25 kate.alh...@nokia.com wrote: As general view, plain applications made with plain desktop UI toolkit will have very poor usability in mobile device. Usage paradigm with touchscreen and finger is so different than in desktop with mouse. Thanks, Kate. Those are good points. In the case of GPE the apps are already designed to be usable on a handheld, but with a stylus rather than fingers. My assumption is that GTK apps will never be able to provide the same look and feel as the Qt-based handheld UX, that good finger friendly behaviour will be hard to achieve (whether by using Hildon or just implementing it in the app), but that stylus usage will probably be fairly straightforward. Text input may be an issue -- it probably depends whether an on-screen keyboard is available which will act as a standard input method or whether it is bound up with Qt widgets. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance
On Wednesday 19 May 2010 18:50:01 Jeff Licquia wrote: There could be an issue with newer MeeGo releases, say a MeeGo 1.1 app running on a MeeGo 1.0 device. But there are other hurdles to cross if we want to support that model (what to do with new 1.1 functionality, for instance). As long as we do our job correctly, and 1.0 apps continue to work on 1.1 devices, then we have at least a 90% solution: just build your app against the oldest MeeGo version you want to support. This has always been an issue in the Maemo world and recently became a really big issue. I am a strong advocate for building your app against the oldest platform version which can support it and relying on ABI compatability to mean it will run on newer versions. But this turned out to be very hard to support in the Maemo world. Will the Meego OBS have an easy way to support this (create an app at at time when version 3.4 is current, build it against version 2.3 and install it in a repository which will allow it to be found by all users using versions later than 2.3 including versions that don't exist yet)? I also recognise that not all developers agree with my preferred approach. There are many who wish to only support the latest platform and would be quite happy (possibly even prefer) if their app did not run against earlier versions. This is primarily to reduce support costs (mainly testing) but a desire to make use of new platform features also plays a part. These developers may intend to release a new version of their app with most platform releases and always delete old versions so it cannot be installed on old releases any more. Both sorts of developers exist in the Maemo world today and can be expected in the Meego world as well, I guess. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
David, A few questions/comments: 1) It is not clear whether this is policy for Meego core packages or for community packages (or both). I assume it is Core, as that is all that exists at the moment. And if we end up with multiple community repositories there may well end up with multiple policies. 2) Four days is not long to spot, review and comment on a proposal if one is not a paid developer. For example, I have been travelling doing my day job all this week and have had no time to look at this list since Monday. If this is just Core policy that is probably fine -- all Core package maintianers are expected to be paid developers, who track the mailing list as part of their job. 3) You really need to be clear where/how discussion is expected to happen (this is separate from the issue fo where the approved policy is published). Personally I would prefer the mailing list (proposed content changes may be in a Wiki page but discussion should be on the list). That is probably partly becuase I have yet to discover how I tell the Wiki to email me on changes to a particular page! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Btrfs as default file system
On Thursday 13 May 2010 10:44:29 Yves-Alexis Perez wrote: On jeu., 2010-05-13 at 10:22 +0100, Graham Cobb wrote: I agree with that decision but we need to realise that that is fine as a test system for developers, but is not a supportable end user configuration. I'm not sure “Meego on n900” is intended to be a “supportable end user configuration”. As far as I understood it, the target is developers. I don't think there has been any announcement one way or the other about their medium term plans for “Meego on n900”, has there? The immediate plans are clearly only for developers. I was just pointing out my take on the implication of the currently described plans. Of course, if Nokia decided they did want to support users there would be nothing to stop them doing additional work to support a fully installed MeeGo configuration (but it would probably still have the /opt problem, or be noticeably slower). Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Voting in bugs.maemo.org
On Tuesday 11 May 2010 10:44:04 Neil McGovern wrote: Bugs shoudn't be subject to a popularity contest. They're subject to a technical evaluation. As a developer, I disagree completely. Popularity is one of the factors to be considered. Knowing that a lot of people are being inconvenienced by a bug or it is affecting a lot of people's perceptions of the quality of my product is one of the important factors in setting priority, along with others that you mention. Setting bug priorities has never been (and never will be) a purely technical issue. For good reasons. And, in any case, votes are purely informative -- they don't change the priority, just provide more information, allowing you to change a priority if you wish to. If you don't allow voting then users will achieve the same objective by adding a lot of me too comments to each bug -- making the comments much less useful. Voting is a lot more efficient, and can also be easily incorporated into reports. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Btrfs as default file system
On Tuesday 11 May 2010 14:03:00 Arjan van de Ven wrote: On 5/11/2010 4:00, Ameya Palande wrote: Hi, I wanted to know why Btrfs is selected as default file system for MeeGo. Following text is copied from Btrfs kernel Kconfig option: Btrfs filesystem (EXPERIMENTAL) Unstable disk format the Kconfig text is out of date. I am interested in the answer to the question, however. Why was Btrfs chosen? I asked before but got no answer. I'm not questioning the decision -- I would like to understand the attributes of btrfs which have made it worth your while to choose it as, at first sight, it seems a very strange choice for a small, low-end system. I would also like to understand the possible implications of someone choosing to use MeeGo with a different filesystem. Also, will it be used on the handset platforms as well as netbooks? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Image Creation Troubles
On Thursday 06 May 2010 15:00:16 Naresh Mehta wrote: Do keep updating on if it worked with the VMDK image instead. I guess it will be the same problem since I suspect the image creation is messing up somehow (.ks is a definite suspect). BTW, I used 0.17 tag for my mic2 compilation. 0.9 was giving a lot of compile errors as well as errors wrt yum version (it wanted .24 whereas the latest is .23). I am interested to hear if anyone else has tried a CD image (not a real CD, just pointing QEMU at the .iso). It worked for me although neither USB nor RAW worked. But if CD doesn't work for others then there must be some other difference in the way I built it and I will go back and try to work out what is going on. I tried the USB image instead. Am able boot but am stuck at ACPI startup. As I mentioned in my earlier email in this thread, I found it necessary to specify -no-acpi on the QEMU command line. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Let's discuss the build.meego.com open
On Monday 03 May 2010 10:05:04 Andreas Jaeger wrote: On Monday 03 May 2010 10:51:38 Jeremiah Foster wrote: [...] Good stuff. I look forward to pushing sources into OBS. I think it would be great if I could just set up a cron job to push a tag from my git repo into OBS. Is that sort of automated building possible on the OBS side? i.e. can a process push to the OBS or does it have to be a human? The command line client for obs called osc allows to do quite a lot of scripting. And if that fails, you can access the public API directly (via curl or osc). So, you need to setup the cron job on your site but should be able to push to obs from it without problems, While we are asking questions... Will I be able to run the build itself on my own system? I.e. replicate the MeeGo OBS environment (when it exists) on my own system so that I can do builds locally but be confident they will work when I submit them to the real OBS? My reasoning is that for Maemo today I automatically build about 120 packages every night. I don't suppose that the MeeGo OBS wants to support each developer doing so many builds every day. I also do not want all the results from those builds necessarily going straight into some repository that users might be using (we haven't worked out the repositories yet, but I wouldn't want every nightly build to end up in extras-devel for Maemo -- I wouldn't want to release until code is tested). So, I assume I will want to build locally. But I really want confidence that if my local build succeeds, the real OBS build will also succeed (no problems with build dependencies, for example) so I want to reproduce the OBS as closely as possible. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] using mic-image-creator for vdi images (VirtualBox)
On Friday 30 April 2010 11:42:44 Naresh Mehta wrote: Hi People, Now the symptoms are different. I don't get a crash, I just get a grey screen on which Starting MeeGo... appears briefly and then disappears. But no terminal. Has anybody got past this error? I am able to load the image in QEMU and then it gets stuck into a loop at the boot prompt. How do I proceed from here? I have got past that point, but not using a vdi image. I built a CD image -- QEMU booted that for me, I could select the option to boot MeeGo and it worked. But, of course, it didn't save anything between boots (as it was running from a CD). The install to disk option didn't work but I was able to just copy everything from the root of the CD-booted image (using tar cf - / | tar xf - -C /my/disk/). I then just had to sort out booting from the disk image (copy the kernel and the initrd from the real root of the CD, install extlinux, create the extlinux.conf, copy an MBR onto the disk). So, I now have a disk image which will boot in QEMU. There may have been an easier way, but I didn't find it. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to start developing on MeeGo?
On Wednesday 28 April 2010 22:12:07 David Greaves wrote: Well, the build systems team inside Nokia has begun writing some docs to assist internal developers with much the same issues. We're starting to publish some of them. A first page came out today http://wiki.meego.com/Packaging/Deb_conversion_example Thanks. I have been reading some tutorials as well as the Fedora documentation (which is not as complete as I would like). And this page is certainly useful. I have managed to create (and install) my first rpm but I have a few questions which I haven't found answers to yet: 1) Some of my packages are built from SVN (nightly builds). There are no .tar files, just SVN access. On Maemo I use MUD which effectively fetches the files from SVN into a directory of the right name, applies patches and then invokes the right tools to create the packages. What is the usual way to handle this case in the rpm world? I have yet to find any example which does not use a .tar file for the sources. I currently have a .spec file which uses an empty SOURCES directory and the %prep uses svn to fetch the sources directly into the build directory. This creates a valid binary rpm but does not create a source rpm! I would assume that I could use svn to fetch the source into the SOURCES directory before calling rpmbuild and make the %prep do cp -r to copy them. Or I could go the whole hog and fetch the sources from svn into a separate directory, tar it up and put the tar file in SOURCES. Is one of these (or something else) the normal way to handle this issue in the rpm world? 2) It seems that some stuff for the .spec file is often stored in source files instead (the %changelog and the %files sections particularly). Are these normally created using patch files (as they won't normally be in the upstream tar file)? In that case, I presume it is not problem that they don't exist until after the %prep stage. 3) What role is spectacle intended to play? Is this a general rpm-world tool or something meego-specific? Is it completely optional, recommended, or required? The README is useful but some more explanation of how it is actually used would be nice. At first sight it is really not clear what advantage this has over maintaining the spec file itself. 4) What will the input to the build system look like (once it is available)? Will it be like the Maemo autobuilder (i.e. submit a source RPM) or will some other control file be required? 5) I have glib2-devel and gtk2-devel in my BuildRequires: line. But I have seen (in some mail message) a reference to pkgconfig in the BuildRequires line and, when I tried running spec2spectacle it told me it wanted to see things like gthread-2.0 (and a bunch of others) in place of these. What should I be using in my BuildRequires: line? Any answers to these questions would be useful. And they might be useful info for other Debian packagers on the Deb conversion wiki page. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to start developing on MeeGo?
On Tuesday 27 April 2010 00:30:50 Graham Cobb wrote: I think I have found the answer to my own question. The following two repositories seem to be the ones: http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/ http://repo.meego.com/MeeGo/devel/extra/repo/ia32/os/ I have now been able to compile my first GPE component (just a library -- I am not trying any GUI code yet) under MeeGo, using my QEMU MeeGo system. Hooray! However, as NFS is not available for the MeeGo system, I have to go back to trying to get the chroot environment working. Maybe a task for the weekend. Once I have that, I have to teach myself how to create an rpm. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] can't install grub when installing meego system into the hard disk by liveusb.
On Tuesday 27 April 2010 03:57:30 Zhang, Austin wrote: Meego didn't use grub as below said. If you are partitioning _manually_, please don't format '/' as ext3 instead as btrfs, and please have a separated '/boot' formatted as ext3. Purely, out of interest -- why did you go for btrfs? It doesn't look like many of the attributes of btrfs are relevant for the classes of devices MeeGo is aimed at so I am interested in why you chose it. For my current dev testing, I am using ext2fs because it is a QEMU environment that is slow enough already and I need minimum CPU cycles more than any other attribute! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] can't install grub when installing meego system into the hard disk by liveusb.
On Tuesday 27 April 2010 04:21:08 xin li wrote: I have only one partition '/' as ext3 and using moblin2.1's grub to boot it.The syslinux can load kernel at ext3 partition?I conceive it only work at fat32 partition. I think MeeGo includes EXTLINUX (it is certainly on the MeeGo CD image I created), which is a variant of SYSLINUX which can boot from ext3. I am using that to boot MeeGo from an ext2 partition. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
On Tuesday 27 April 2010 17:59:16 Shaver, Michael R wrote: I think coming up with the overall name will inform how we name the various processes and components that make up this. An example would be if the overall name to end users was called Extras, then for the developer uploading their source it might be called Extras Source Repositories. Or you get the idea. Yes, but that is about choosing the name of the repository. This discussion is about choosing the name for the working team which will discuss setting up the repositories! I would prefer not to constrain the MeeGo Marketing Working Group (or whatever they end up being called) in what they want to call the repositories this team creates -- we are much better off having a team name which cannot be confused with the repositories we will create. Especially as my view is that we will end up with several different repositories with different names (but that is a discussion for later!). The Team name should be something dull. Personally I would have been happy with the Repositories Team (and for the scope to include the Core repos as well -- I think we will find it is important to have some consistency between the core and the supplemental repos, in things like how many there are, how they relate to releases, how they relate to UX's, etc.). But if others are not happy with a converged team, why don't we call this the Community Repositories Team. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Building the Meego Dev Environment
On Tuesday 06 April 2010 10:41:21 Dave Joubert wrote: On 6 April 2010 10:33, Graham Cobb g+me...@cobb.uk.net wrote: I am next going to try to see if I can find a bootable MeeGo image I can stick on a memory card and boot my laptop with so I can try that on a 12 hour flight I have coming up! Graham If you do find one, please let the rest of us know where we can download a copy. I know this thread is old but just in case anyone is interested... Due to a certain unpronounceable volcano, I had a lot of time sitting around on this trip and I eventually got somewhere. First of all I booted Xubuntu using QEMU on my (work-supplied) Windows PC and used it to follow the instructions on how to build a MeeGo image. This worked better than my previous attempts using my Debian system (now I am back home I may try to work out why and fix the Debian instructions). I decided to try building a CD image this time. The CD image boots using QEMU! Hooray! So, I can now boot into MeeGo. Unfortunately, none of my changes get written back (even if I boot the cd image as a QEMU hard disk) and (as pointed out in other threads) the install to disk option doesn't work. My planned next step is to just use tar to clone the booted system to a hard disk image and get that bootable so that I can make changes to the environment. Then, all I need is access to an RPM repository for MeeGo on Intel which has the developer tools I need (svn is the first one so I can access my code). Then I can start actually trying to build some components. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to start developing on MeeGo?
On Friday 16 April 2010 18:50:31 Greg KH wrote: Why not just use MeeGo to develop it? That works for me. And again, just because the distro is RPM based, doesn't mean that MeeGo is based on it at all. Greg, I am trying that now. I have now managed to boot a MeeGo Intel image (in QEMU). Where can I find an RPM repository with all the tools I need (svn is the first one)? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] About chrooting into the development image
On Monday 26 April 2010 08:30:38 Carsten Munk wrote: 2010/4/26 Zheng Zhang zwxp...@gmail.com: Hi, I run the sudo mic-chroot meego-codedrop-ia32-developer-201003311106.img following the instruction Building your package: Step by step, but the error info is Error: I can't recognize this image type. Why it happens? Hi, You need to download the development branch of mic2 - the feature for chrooting into a loopback image was not submitted in time for 0.17 release. Or, create a loop device pointing to the image, mount that somewhere and use mic-chroot to chroot into the mounted directory. You will need to unmount it and destroy the loop device once you have finished. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to start developing on MeeGo?
On Monday 26 April 2010 20:58:34 Graham Cobb wrote: I am trying that now. I have now managed to boot a MeeGo Intel image (in QEMU). Where can I find an RPM repository with all the tools I need (svn is the first one)? I think I have found the answer to my own question. The following two repositories seem to be the ones: http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/ http://repo.meego.com/MeeGo/devel/extra/repo/ia32/os/ I have found subversion, but I still can't find nfs -- anyone know how I can install NFS? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Development images won't boot in QEMU
I am trying to follow http://wiki.meego.com/Developing_in_a_Meego_Environment but, as I can't use mic-chroot on Debian, I am trying to use QEMU to run a MeeGo VM instead. If I build a raw image using the standard kickstart file, I can boot it in QEMU. However, if I use Carsten's X86 kickstart file from http://wiki.meego.com/images/Devel-ia32.ks, the resulting raw file will not boot in QEMU (it looks like syslinux is in a loop complaining about LABEL). Any chance the Devel kickstart file could be fixed to produce a bootable raw image? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Development images won't boot in QEMU
On Wednesday 07 April 2010 13:35:49 Carsten Munk wrote: No, as it is not their purpose - the devel-ia32.ks's on the wiki make a filesystem for chroot development (building), not for running actual systems. It is comparable to rootstraps. Use the standard kickstart files for generating system images. Shame, it would have been useful (I use qemu -nographic environments for some of my nightly Maemo builds). When will we be able to get a mic-chroot that will run on Debian Squeeze and can read the chroot images? 0.17 doesn't handle loop files and git master won't build on Debian Squeeze because of the yum version. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] using mic-image-creator for vdi images (VirtualBox)
On Tuesday 06 April 2010 12:43:03 Ross Kendall wrote: I did manage to successfully make a livecd iso image and mount it under virtualbox, however that seemed to crash half way through loading the MeeGo kernel. Got as far as the following line: [ 0.337016] [c1002cf6] kernel_thread_helper+0x6/0x10 I have no idea if it is related but I saw something similar using QEMU. I built a raw IA image using the standard kickstart file and tried to boot it using QEMU (both on my Debian system and on a Windows system). In both cases, the boot would start but it would shortly crash with a traceback that ended in the same line you posted. I got better results when I made a change to the kickstart file. I changed: bootloader --timeout=0 --append=quiet to... bootloader --timeout=10 --append=clock=pit The timeout doesn't do anything but the clock setting seemed to help (this is from a note in the QEMU documentation). Now the symptoms are different. I don't get a crash, I just get a grey screen on which Starting MeeGo... appears briefly and then disappears. But no terminal. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Building meego images on Debian
I am trying to work out how to have a working MeeGo development environment on my Debian Squeeze desktop. I have found a few problems, reported a few bugs and documented some issues and workrounds (see http://wiki.meego.com/MIC_on_Debian). But I am a bit stumped by the latest problem... I can build USB images (I haven't tried booting them yet, though) and I can build raw images (which won't boot in QEMU -- but I suspect I know why that is), however, when I try to build a livecd image I get the following error message from mic-image-creator: Error: failed to create image : Unable to find valid kernels, please check the repo Any ideas what that is telling me? Or why it only occurs with the livecd build and not with raw or liveusb? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] On device help framework
On Tuesday 30 March 2010 06:47:37 tero.k...@nokia.com wrote: There are pretty strict legal regulations, depending on sales location, on what kind of documentation has to be available to the person purchasing a mobile phone. The legal requirements for netbooks are different, as are for in-vehicle systems. So this will require a bit of differentiation depending on system type. Making it easy for the community to submit changes, fix bugs, improve (or create) translations and rewrite parts of the documentation is not incompatible with legal restrictions, just as it is not incompatible with translation, good editing and, even branding policing. The critical thing is to make it easy for (i) the community to submit improvements, and (ii) users to have speedy access to those improvements. There is no reason why those changes should not ubsequently be carefully reviewed, edited and, possibly, even rejected as part of a release process. This is the big advantage of a Wiki-based approach. The commmunity can make changes and those improvements can be immediately available to users in the Wiki (which can include a legal disclaimer). The techical author/editor can review the changes and fix any problems before taking the material and using it to create formal documentation. Reviews by legal, marketing and other interested parties can still occur before the formal documentation is released. However, the key thing is that for the process to be effective, the version the community is working with, and the formal released version, have to be kept in sync. As legal (and other) reviews happen, the changes have to be fed back into the version the community uses and is fixing. Unfortunately, the tools generally used by technical writers, in my experience, are not designed for that sort of co-operative development (and, also, often have high barriers to entry such as training or, worse, commercial licences). Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 Questions...
On Monday 22 March 2010 09:10:21 Carsten Munk wrote: We have to make a proper and competitive end-user product with MeeGo in the short term. We can create world peace in the long term. Time to strike with a open source platform is now, not in 5 years. Or we'll be run over by 20% open source platforms on closed devices. I agree with Carsten. My, personal, reason for compromise is that I believe any efforts I put in will go to waste unless the devices built on this platform are truly successful -- amongst the top smartphones. But the really high-end smartphone market is critically dependent on leading edge hardware: some of the most sophisticated hardware development today is aimed at that market. Displays, radios, displays, chipset integration, processors, batteries -- all have to be small, cheap, power efficient and extremely performant -- an imposible demand! This is leading edge stuff and there is little competition for the most innovative vendors. That leading edge hardware is provided by companies who, for various reasons, are not interested in producing open source drivers. We can, and should, continue to emphasise to them how their own business can be improved by going open source, but they have less incentive to do so than a Nokia -- they are looking at small amounts of software and they are very worried that their competitors will learn some of the secrets of their hardware designs if they were to open their software. I think they are wrong and that, on balance, it would be a win for them to open their code but I acknowledge their worries. In the meantime, I recognise that any device which chooses not to use their hardware will not be a successful top-end smartphone. That is an unfortunate fact of the phone business. I don't personally believe militant open source is the way to go. I think practical open source is the way to go, seeing the big picture. Changing the world piece by piece instead of revolution. I'm not interested in contributing to a project which fails, because it is not capable of building a successful device. So, I am much more concerned that MeeGo has an open process, that open software can be added to any MeeGo device and that as much of MeeGo as possible is open, than in stopping its use with proprietary software. I realise others may have different priorities. That is fine. But please accept that some of us do not share them. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-community] First Repository Working Group Meeting @ Sun 21 March - 20:00 UTC
On Friday 19 March 2010 20:13:18 Andreas Osowski wrote: The meeting will be logged and moderated by Stskeeps, Carsten Munk, (as I'm unable to attend due to recent changes) Is the log available? Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] TSG meetings schedule (was Re: First TSG meeting...)
On Friday 19 March 2010 04:52:52 quim@nokia.com wrote: The suitable times for the TSG meeting are the times suitable for those having to take part in there. Obvious? :) The question is: who *must* attend the TSG meetings? Sure, the bot suggestion was a bit tounge-in-cheek (but this is a -dev list, after all!). Of course the scheduling needs to take into account the actual availability of the key people. However, there are a couple of general principles I would ask the TSG to consider: 1) avoid Friday's -- they seem to have the largest number of people who will not be available, for all sorts of reasons (although not too bad for me personally), and 2) have occasional meetings at times which are antisocial for (some of) the TSG members, in order to show a commitment to a global project. [Of course, if they are clever, they set those up for occasions when some, at least, of them are travelling on the other side of the world anyway] Also most of the questions you would like to address now to the TSG will be better addressd to the specific working group or the specific channel where the maintainers and specialists can be found. Maybe the working groups should be forced to use the bot! :-) Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
