Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark mark.skarpn...@intel.comwrote: Yes, that's exactly what we expect. One version for every MeeGo compliant device. Device-specific tailoring will be the exception - it's expensive, time consuming, and results in an app that will run on fewer devices. This certainly makes sense from a developer/vendor standpoint. Unfortunately, I'm not so sure about the user angle as they don't care if an app works on OTHER devices than their own. The Symbian experience so far is suggesting that quite a few developers believe that having generic apps able to run on a hundred different devices are a dubious match for apps tailored to maximize user experience on a small number of bestseller devices. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] mkcal: CREATED/LAST-MODIFIED/DTSTAMP
Hi... I might have missed it... I have checked the implementation and we have that in DB, so it is only missing in Incidence or IncidenceBase. Right now the field is ignored. Alvaro On Wednesday 15 September 2010 17:55:30 ext Patrick Ohly wrote: Hello Alvaro! We lost the list on CC - may I add it again? On Wed, 2010-09-15 at 06:25 +0100, Álvaro Manera wrote: On Tuesday 14 September 2010 12:01:01 you wrote: On Tue, 2010-09-14 at 07:20 +0100, Álvaro Manera wrote: It should have been resolved and fixed already. What about DTSTAMP? Is importing that from an iCalendar 2.0 item possible? Should it be added? Hi, It can be added but it will require a db schema change because that property isn't defined there. So I don't know what is the meego stand on those changes. Software updates should always work automatically, without user intervention or forcing them to reinstall. Are db schema changes like that possible in principle? For DTSTAMP, I'm not sure how important it is in practice. According to the RFC, it MUST be present: 4.8.7.2 Date/Time Stamp Property Name: DTSTAMP Conformance: This property MUST be included in the VEVENT, VTODO, VJOURNAL or VFREEBUSY calendar components. What is created by mkcal at the moment if there is nothing corresponding to DTSTAMP in the local data storage? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/15/2010 08:13 PM, Skarpness, Mark wrote: Hi Dave, On Sep 15, 2010, at 1:51 AM, Dave Neary wrote: I can get that a commercial application developer wants to be able to build a package which will install on any MeeGo device... we're not talking about requiring that people split off dependencies, but allowing that things can be done like that. The problem is that once we allow it, then we require everyone building a compliant device to support it. Otherwise we will miss the primary objective of compliance: every compliant app will run on every compliant device. One of possible approaches may be to have a second class of compliant applications with a separate name and a limited promise: Every second class compliant app will run on every compliant device if the device satisfies extra hardware requirements. Please check your device capabilities! It might be useful for apps tightly depending on some specific hardware features that cannot be added to MeeGo minimum hardware requirements by some reason. Support for MeeGo Extras/Surrounds can be considered as an extra hardware feature of a device as well. Alexey Khoroshilov, ISPRAS / Linux Foundation ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo Website suggestion
Hi , I have one suggestion regarding MeeGo Website. We can put some Flash Plugins for better User Experience Other than Static web pages we can put some Dynamic Webpage. I think it will improve the accessibility, Interaction, navigation factors Best Regards Hari. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] thumbnailing system (was: Re: QtContacts + Tracker: PHOTO not stored (BMC #5879))
Hello! Thanks for the pointers. On Wed, 2010-09-15 at 21:52 +0100, Ivan Frade wrote: the thumbnailing system - this is the first time I hear about this. Do you have pointers to further information about it? Maybe the name is too ambitious, but it is the combination of: * the freedesktop spec about how and where to store thumbnails: http://jens.triq.net/thumbnail-spec/ * this spec of an API for a dbus thumbnail service: http://live.gnome.org/ThumbnailerSpec * tumblerd implementing those two specs: http://maemo.gitorious.org/maemo-af/tumbler * libthumbnailer wrapping the thumbnailer dbus API and adding a couple of useful functions: http://maemo.gitorious.org/maemo-af/libthumbnailer Shortly after you mentioned thumbailing, libthumbnailer was accepted into MeeGo. tumbler supports in-process and out-of-process plugins. On the second category we have for example maemo-video-thumbnailer: http://maemo.gitorious.com/maemo-af/maemo-video-thumbnailer It needs some renaming and meego integration, i guess. I just checked, it's already included. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: RE: MeeGo Porting Guide available for reading)
This is my view, too. Basically the key point of GeoClue would be to offer an agreed (low level) C API to the location services in MeeGo OS. The Qt Mobility location API back-end could be written on top of that but would not have to be (e.g. if that would be an issue from performance perspective). So in addition to requiring support for the Qt Mobility location API, we'd be requiring GeoClue API support as well. But, enough said about that. Regards, Jari P.S. the Sensors section in the MeeGo Porting Guide still states that the assumed HW adaptation interface is a Sensor Framework plugin interface. If someone sees this differently, please let me/us know... -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Shin Minjung (Nokia-MS-Qt/Brisbane) Sent: 16. syyskuuta 2010 08:00 To: thi...@kde.org; meego-dev@meego.com Subject: Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: RE: MeeGo Porting Guide available for reading) Hi, The primary goal of Qt Mobility API is to provide useful mobile functionalities to the application developers. So let's make it clear that Mobility should not be considered as a means of Qt-ifing every low level APIs. :) Regarding Location API, Location API has a plugin system for the backends, so it does not enforce anyone to use only one backend. MeeGo porting guide has some more information. http://wiki.meego.com/MeeGo_Porting_Guide#Location Regards, Min -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Thiago Macieira Sent: Thursday, 16 September 2010 7:36 AM To: meego-dev@meego.com Subject: Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: RE: MeeGo Porting Guide available for reading) On Wednesday 15. September 2010 20.42.40 jari.paloja...@nokia.com wrote: Standardizing a low(er) level C API to each middleware level “service” in MeeGo OS would have two benefits: - A single Qt Mobility API backend implementation would suffice = no need for vendor specific implementations - There would be a standard way to integrate middleware level SW components via C APIs = less need for vendor specifics in the middleware level (C++ APIs such as the Qt Mobility APIs are somewhat hard to use from C so middleware components written in C will typically use some other integration routes) And a drawback: - it's another level of indirection and abstraction, introducing potential delays and complexity (translating information from one format to another) and it's also a source of potential bugs. I'm not saying the middlewares are of bad quality. Not at all. But I don't want to see a middleware be written and added just because none existed before. A middleware has to have a reason to exist, a value to add. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo image for armv6
Hi, Do we have MeeGo image which can run on armv6 ?? Any work is going on for porting MeeGo on armv4 ?? If anybody have QEMU image (For any armv6) please share the same. Regards, Vij ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Website suggestion
Hi, I have one suggestion regarding MeeGo Website. Thank you for your ideas. We ask contributors to propose website features or improvements via http://bugs.meego.com . The more specific the easier is to discuss, agree and implement. For the rest, the meego-community list is the right place to discuss about meego.com. meego-dev is about platform development. Thank you! -- Quim Gil We can put some Flash Plugins for better User Experience Other than Static web pages we can put some Dynamic Webpage. I think it will improve the accessibility, Interaction, navigation factors Best Regards Hari. Attachment ATT1..txt ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
ext Skarpness, Mark mark.skarpn...@intel.com writes: But my point was really that this decision does matter and does have an impact - if we allow applications to have external dependencies then someone has to pay to host them in a commercially scalable and reliable way. What about _internal_ dependencies? Should we allow applications to have dependencies to other packages in the same store? I think this is up to the store, but the MeeGo package management should be prepared for it. Or in other words, if MeeGo doesn't get a credible Extras or Surrounds happen itself, others will hopefully do it without us, and we should at least not make it unecessarily hard for them to use dependencies between their packages. They might want to have their own UI for discovering things in their repository, but they should not need to implement their own package manager, of course. If MeeGo gets a credible Extras / Surrounds going, we need to support dependencies anyway (because without them I wouldn't call it credible). ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi, I'm starting to see some of the subtleties here, I think - and I'm not sure we're all talking about the same things - it seems to me like the various constraints, goals value of an application compliance programme are not exactly the same for the different actors here. Skarpness, Mark wrote: On Sep 15, 2010, at 1:16 PM, Graham Cobb wrote: But app stores are not going to be in the business of selling compliant apps! yes they will - that is the whole point of MeeGo compliance - to get scale in the application ecosystem by enabling applications to run across multiple devices. If there is a very well-stocked repository of community applications which are non-compliant, resulting in many people running non-compliant apps on their devices, then the value of a MeeGo compliant label for application developers will go down. To me, the whole point of having MeeGo compliant applications is to (1) give users a way to know which apps are of a certain standard (kind of a quality mark) and (2) to let application developers know what best practices are for application development (endorsed APIs distribution channel). If a substantial number of the most commonly used apps are not compliant, won't that muddy the waters at both ends of the pool? The third axis of application compliance you've hinted at are the implied responsibilities of stack vendors. This, it seems to me, is the key difficulty we have. You are saying (if I understand correctly) that every MeeGo stack must provide access to every MeeGo compliant application. Is this a requirement? If platforms must allow installation of all MeeGo compliant applications, and MeeGo Extras (or whatever the shared repository of community-packaged applications will be called) applications which depend on libraries in the usual way can be compliant, then yes, you're requiring stack vendors to provide a mechanism for enabling Extras and doing dependency resolution. Perhaps there is a way to phrase this so that vendors must support the installation of apps which are self-encapsulated, and may provide a means to install apps which have MeeGo compliant dependencies? 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. No, I don't agree. MeeGo compliance is about creating a large, unified application ecosystem with apps sold through multiple app stores on multiple devices. How do you see the end result looking? Let's take an example of 2 vendors: let's say Linpus and Novell. In my mind: MeeGo provides the app store infrastructure (similar to Android Market) which both Linpus Novell are required to enable access to in their devices. MeeGo also provides build, packaging hosting facilities for the MeeGo Extras, which may or may not be enabled by default on Linpus Novell devices. If enabled by default, MeeGo Extras applications would show up in the app store as free applications (similar to Hildon Application Manager). If Novell or Linpus wanted to provide vendor- or device-specific app stores, they could also do that, provide the upload hosting facilities, and have those extra applications also show up in the app store client. The user would be able to see in the interface which apps are MeeGo compliant, and which come from the vendor app store. I could also imagine the potential for a Nettbook app store for applications tailored for the netbook UX, which would be another common app store between Novell Linpus, but which would not be used by GENIVI or Nokia. It seems that in your mind, each vendor will provide their own app store, that MeeGo will not provide any build, packaging or hosting facilities, and that the products of the MeeGo project will start end with the core distribution + specs on what makes up a compliant application. The burden of providing a distribution channel hosting is entirely pushed to the vendors. Is that a fair assessment? If it is, where do you see community apps being distributed? How would Linpus users be able to get at install applications from the Novell app store? Perhaps I'm misunderstanding how you see this working in practice. If so, perhaps you could clear up my misunderstanding a little? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: RE: MeeGo Porting Guide available for reading)
On 09/15/2010 10:24 AM, jari.paloja...@nokia.com wrote: I _currently_ see this quite differently. The attached picture explains my views. Applied to this case, GeoClue defines the platform / core OS level APIs and would need to be supported in any MeeGo compliant device that supports location services. The Qt Mobility API back-end would be written on top of GeoClue APIs. The other way (that Michael is proposing) to handle this is that Qt Mobility APIs effectively become full members of the MeeGo core OS. So SW components in the core OS level would also use Qt Mobility APIs to access location services if they need them. And GeoClue would become something that vendors could use in their devices if they wish (would be fully optional). But if we move in this direction, then e.g. the Sensor Framework vs. Qt Mobility sensor APIs question is analogous to this (and I guess there are other examples as well). I think that this is a pretty important generic architectural question in MeeGo OS and would appreciate guidance from Arjan and other MeeGo architects. Technically both options can be made to work. The main difference is in what kind of dependencies we create into MeeGo OS. Regards, Jari backend Hello, How about standardizing the feature-sets and document well the current cross-dependencies rather than fix the projects providing the stuff currently. The ongoing way feels fine as a just another concept to provide a bit more properly defined applications API. But I sense many of us would like to see the Meego as more flexible and open to future devices of any kind. I could consider e.g. graphics and multimedia as an analogous example to this. Khronos APIs reached Qt native implementations years ago and now we have that for fixed certain graphics stacks. Its similarly just because it happened to evolve like this. How about allowing advertising that OpenVG efforts are welcome to use Meego as playground as well. I feel also that OpenMAX AL could head up as Meego multimedia middleware. Do we have followers to comment on closer to Khronos ideology in general ? Such openness would reach aplenty of talented engineers to contribute along with manufacturer's derived products. They break the stacks anyway, so why not politely try to take it into control of the community ? I realize that with such visionaries Meego wouldn't be as far as it is, but in my opinion its more a matter of appearance with compliance specifications and less affective to current roadmap with reference devices middleware. regards, -Teemu ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] what dependence packages will needed to compile MeeGo sensor fw
For mce, remove lines about MCE in sensord/sensord.pro I don't meet gconf issue properly because gconf has been installed in my system. From: Chang, Esmond Sent: Wednesday, September 15, 2010 7:22 PM To: meego-dev@meego.com Cc: Zhang, Xing Z Subject: what dependence packages will needed to compile MeeGo sensor fw Hi, I git clone the meego sfw source from http://gitorious.org/sensorfw/sensorfw and try to build source in my two platforms but failed -MeeGo netbook 1.0 with qt-devel-4.6 and qt4.6.2, when compile with the source it shows mcewatcher.cpp:27:28: error : mce/mode-names.h: No Such file or directory mcewatcher.cpp:28:28: error : mce/dbus-names.h: No Such file or directory -MeeGo handset0817 in netbook with qt 4.7, when compile with source it shows declinationfilter.cpp:26:32: fatal error: gconf/gconf-client.h No such file or directory My question is, what's the packages needed in order to compile sfw? Or any tips for compilation? Thanks... Regards, Esmond ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 1:02 AM, ext Skarpness, Mark wrote: On Sep 15, 2010, at 1:16 PM, Graham Cobb wrote: 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! yes they will - that is the whole point of MeeGo compliance - to get scale in the application ecosystem by enabling applications to run across multiple devices. Allowing applications to depend extra libraries that are also compliant does not affect this at all. It does not make difference any bit if application uses some library X is X comes with application or comes from public quality controlled repository. 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. No, I don't agree. MeeGo compliance is about creating a large, unified application ecosystem with apps sold through multiple app stores on multiple devices. High end applications made by pig companies usually does not need to depend some extra libraries and they has man force to maintain packetize all libraries they need. In other end, there are big amount of smaller developers that rather would like to use ready made libraries tested and proof to work and without all hassle involved integrating and maintaining library. But mostly i where is the point, what we will achieve by forcing every developer pack and maintain copy of library and not allowing them to use tested and quality controlled version from repository ? Kate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 08:12, Attila Csipa wrote: On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark mark.skarpn...@intel.com wrote: Yes, that's exactly what we expect. One version for every MeeGo compliant device. Device-specific tailoring will be the exception - it's expensive, time consuming, and results in an app that will run on fewer devices. This certainly makes sense from a developer/vendor standpoint. Unfortunately, I'm not so sure about the user angle as they don't care if an app works on OTHER devices than their own. I disagree. Users want to move their photos easily from their phone to their TV, move their phone calls from the phone to the car, etc. The Symbian experience so far is suggesting that quite a few developers believe that having generic apps able to run on a hundred different devices are a dubious match for apps tailored to maximize user experience on a small number of bestseller devices. If you have _one_ OS with _one_ well defined API, you will gain a great deal from a developers standpoint. Jeremiah___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 9/16/2010 12:33 AM, Dave Neary wrote: It seems that in your mind, each vendor will provide their own app store, it will be the very common case where the vendor will decide which of the various app stores he will use. appstores are 'the thing' nowadays, and Nokia and Intel each have their own already I wouldn't be surprised if others either do their own completely, or syndicate an existing one but with their own control. that MeeGo will not provide any build, packaging or hosting facilities, and that the products of the MeeGo project will start end with the core distribution + specs on what makes up a compliant application. The burden of providing a distribution channel hosting is entirely pushed to the vendors. Is that a fair assessment? If it is, where do you see community apps being distributed? How would Linpus users be able to get at install applications from the Novell app store? Perhaps I'm misunderstanding how you see this working in practice. If so, perhaps you could clear up my misunderstanding a little? I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. Other categories may or may not be more open than that... but the locked down model also needs to work for compliance. Compliance is your app will work on all meego compliant devices (and yes work will mean as well as it did on your original device form factor, not it'll be perfect even if you move a phone app to your tv), not your app will work on all meego compliant devices except those that are locked down or do not use Extras. now MeeGo extras is a great idea, and I can't wait to see all those MeeGo Touch Framework apps show up and be available for the meego.com users. But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Still question on MeeGo on devkit8000
On Thu, Sep 16, 2010 at 3:35 PM, Samuel Xu samuel.xu.t...@gmail.com wrote: Hi: I hit the simiar issue(booted, while no X) as vijay singh, when I want to run MeeGo on top of devkit8000. I followed Steps to modify an N900 image for BeagleBoard at http://wiki.meego.com/ARM/Meego_on_the_Beagle, using http://repo.meego.com/MeeGo/releases/1.0/core/images/meego-n900-open-armv7l/meego-n900-open-armv7l-1.0.0.20100525.1-sda.raw.bz2 and http://wiki.meego.com/images/Meego-beagle-kernel.tar.bz2 My u-boot cmd is: setenv bootcmd 'mmcinit; fatload mmc 0 0x8200 uImage;bootm 0x8200' setenv bootargs 'mem=256M console=ttyS2,115200n8 mpurate=600 buddy=unknown vram=12M omapfb.mode=dvi:1024x768mr...@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait' boot Hi, I got it running few weeks back by following the instructions from here http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch I hope things will work out fine for you as well. MeeGo can boot into shell in serial cmd prompt. while I found the external monitor (connected via HDMI=DVI) is black after a blinking. Boot information(boot-log) is attached. I also tried startx from serial cmd shell, I know it is not reasonable to start x from this shell, while the attached debug information(startx) might be useful. Appreciate guide on how to process to start X on my devkit8000. If you do exactly the same as mentioned in that wiki page, you will land safely :) because I made some mistakes while copying the rootfs to MMC card and that gave a set of permission errors. Due to which my UI was not coming up. Make sure you are copying the rootfs onto the card as mentioned in the wiki to retain the same set of permissions/privileges as needed. Regards, Amit Pundir Samuel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 3:05 AM, ext quim@nokia.commailto:quim@nokia.com wrote: The MeeGo commercial offering doesn't *require* Extras but can benefit from a successful Extras anyway. Letting Extras out of the Compliance program makes sense, especialy now that the comercial part still needs to be created and consolidated. Please explain, how leaving extras out helps consolidate, it is mode fragmenting. If you say that there may not be one lib X in extras but rather multiple copies of lib X maintained all app developers, how it helps consolidate ? If app needs lib X it does not help any bit saying that they should fake it not being lib but just part of app. Let's get one other view, and look also to back to history. Platform can't be ready in day one. There will be new needs and new innovations. Some of them begin their live in extras, some of them will be approved to be part of future platform versions. All innovation is not centralized into Nokia and Intel, lot of it happens in community and independent communities. No one can predict what they will be. We just can imagine game engines, physics libraries, image processing libraries, augmented reality libraries, voice synthesizers and recognition, you name it. I think that it's best to everyone that these libraries will be one maintained and quality controlled version in Extras and that also helps pick these ones that will be part of future versions of platform. Other questions is that is there sense to have even all these libraries always in base platform at all. Is there any sense have game engines in dedicated car computer or GPS device as mandatory part ? Kate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 11:26, Arjan van de Ven ar...@linux.intel.com wrote: now MeeGo extras is a great idea, and I can't wait to see all those MeeGo Touch Framework apps show up and be available for the meego.com users. But to be honest, I somewhat doubt that hardware vendors or the operators Indeed. will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Nokia are a very conservative company but, with Maemo 5, enabled Maemo Extras - run by the community - out of the box on the N900; and, following various discussions, the consensus was that there would be no obvious reason to not do so in future devices as it had been an enormous success. Yes, there were one or two apps which got through the QA process with problems (either technical or perceived legal by a third party); but these were dealt with and rectified. If Nokia can be convinced about the value of enabling a repository out of the box, any vendor should be able to be convinced! Anyway, we seem to be going round the houses. Can't the problem be simplified to: * A MeeGo-compliant package MUST depend on other MeeGo-compliant packages or the packages in MeeGo Core. * A MeeGo-compliant package with dependencies on other MeeGo-compliant packages MUST be delivered through a mechanism (such as a repository) which can deliver the other dependencies. For example, a MeeGo-compliant package in Ovi Store could depend on MeeGo Core packages and a MeeGo-compliant package in MeeGo Extras. It is then a Nokia issue to ensure that all devices with access to Ovi Store also have access to MeeGo Extras; but this is not any additional burden on the MeeGo project, or any other vendor. Similarly, it's then a policy issue for Nokia Ovi Store to decide whether or not to allow non-compliant packages into their store; but again, this doesn't impact us on meego.com. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 1:26 PM, ext Arjan van de Ven wrote: that MeeGo will not provide any build, packaging or hosting facilities, and that the products of the MeeGo project will start end with the core distribution + specs on what makes up a compliant application. The burden of providing a distribution channel hosting is entirely pushed to the vendors. Is that a fair assessment? If it is, where do you see community apps being distributed? How would Linpus users be able to get at install applications from the Novell app store? Perhaps I'm misunderstanding how you see this working in practice. If so, perhaps you could clear up my misunderstanding a little? I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. Other categories may or may not be more open than that... but the locked down model also needs to work for compliance. Compliance is your app will work on all meego compliant devices (and yes work will mean as well as it did on your original device form factor, not it'll be perfect even if you move a phone app to your tv), not your app will work on all meego compliant devices except those that are locked down or do not use Extras. Sometimes we need to learn from history, do you remember days when operators wanted to control what internet pages you could access and in most cases only their own ones ? iPhone has only one app store, how many there is for android ? Does every operator have own and do they lock down their devices only some fractional fragment limited app store ? I think that app store field fragmentation is no ones advantage. There is better question, how much we would like protection against stupidity in compatibility specs ? Having none is not good. now MeeGo extras is a great idea, and I can't wait to see all those MeeGo Touch Framework apps show up and be available for the meego.com users. But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com We can have three levels of extras extras-devel as in Maemo that is full open and without any quality control and mostly used by developers. Then extras that has quality gate by community. For MeeGo we could add third one, official Meego-extras that has other OC gate by meego.com and having this repo would be requirement to get device as MeeGo compliant. That leaves door open to us quickly react to future needs. Kate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 1:15 PM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark mark.skarpn...@intel.com wrote: Yes, that's exactly what we expect. One version for every MeeGo compliant device. Device-specific tailoring will be the exception - it's expensive, time consuming, and results in an app that will run on fewer devices. This certainly makes sense from a developer/vendor standpoint. Unfortunately, I'm not so sure about the user angle as they don't care if an app works on OTHER devices than their own. I disagree. Users want to move their photos easily from their phone to their TV, move their phone calls from the phone to the car, etc. That I believe still falls under their own devices :) What I was saying is that an N8 owner doesn't care much if an Epic Citadel type of thing runs on a C7 or not (let's pretend for a moment that those two are MeeGo devices). If compliance means forcing developers to go for a single lowest common denominator version of the MeeGo APIs, you will never see cool stuff on MeeGo once the first wave of devices passes (and that's something high-end device users DO care about). The Symbian experience so far is suggesting that quite a few developers believe that having generic apps able to run on a hundred different devices are a dubious match for apps tailored to maximize user experience on a small number of bestseller devices. If you have _one_ OS with _one_ well defined API, you will gain a great deal from a developers standpoint. With the various UXes it already is failing on that promise, but that is not the point. The problem is that it's a black and white setup with a conflict of interest. You want developers to only use your API (so make it as all-encompassing as possible), but also have the need to make this API as small as possible due to financial/technical constraints. For example, MeeGo currently has no gaming or social networking oriented APIs, which are a must have category on many of its device categories. Existing Linux libs/apps *can* mitigate this if done properly. The only trick is to make the compatibility/compliancy thing a CONTAINS relation, and make proper, clear names for them, so that whatever compatibility level you are aiming at, you know exactly what is beneath that - MeeGo Core, UX, Extras, Surrounds, etc... Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
-Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16 September 2010 11:27 To: Dave Neary Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] Meego spec - for comment On 9/16/2010 12:33 AM, Dave Neary wrote: It seems that in your mind, each vendor will provide their own app store, it will be the very common case where the vendor will decide which of the various app stores he will use. appstores are 'the thing' nowadays, and Nokia and Intel each have their own already I wouldn't be surprised if others either do their own completely, or syndicate an existing one but with their own control. that MeeGo will not provide any build, packaging or hosting facilities, and that the products of the MeeGo project will start end with the core distribution + specs on what makes up a compliant application. The burden of providing a distribution channel hosting is entirely pushed to the vendors. Is that a fair assessment? If it is, where do you see community apps being distributed? How would Linpus users be able to get at install applications from the Novell app store? Perhaps I'm misunderstanding how you see this working in practice. If so, perhaps you could clear up my misunderstanding a little? I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. Other categories may or may not be more open than that... but the locked down model also needs to work for compliance. Compliance is your app will work on all meego compliant devices (and yes work will mean as well as it did on your original device form factor, not it'll be perfect even if you move a phone app to your tv), not your app will work on all meego compliant devices except those that are locked down or do not use Extras. now MeeGo extras is a great idea, and I can't wait to see all those MeeGo Touch Framework apps show up and be available for the meego.com users. But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 11:26, Arjan van de Ven wrote: But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Precisely. Whereas if apps linking to Surrounds were compliant then maybe they'd think a little harder. Remember. They still have policy in their app store that can say no apps with external dependencies. But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 11:52, Counihan, Tom wrote: [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16 I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? Yes. So clearly this vendor has a policy to restrict which apps can run. Some may choose to be draconian fearing US litigation; others may go for a more liberated approach to the market. Why is MeeGo compliance mandating the draconian and forbidding the liberated? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 2:20 PM, David Greaves da...@dgreaves.com wrote: Some may choose to be draconian fearing US litigation; others may go for a more liberated approach to the market. Why is MeeGo compliance mandating the draconian and forbidding the liberated? I can't emphasize this enough - where is the need to transform vendor choices into OS policies coming from ? Vendors can lock down/filter repositories all they want and that's OK, it's their product - it's their call. After all, if the vendor is (for whatever reason) against installing a certain app (or any app for that matter), it doesn't matter how big your MeeGo Compliant sticker is - you're not getting on that device. But I don't really see why that, existing, valid choice is considered as a good baseline policy *for MeeGo* as such ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 15/09/10 23:59, Skarpness, Mark wrote: I view it the other way around: what requirements is compliance placing on the device manufacturer and are those reasonable and supportable. Setting the details of how compliant apps are packaged and delivered aside - compliance does not dictate whether or not a device allows apps to be installed (or which app sources are allowed) - that is a choice made by the device creator / distributor. Excellent. So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. So which of the previous arguments against Surrounds are still valid? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Alhola Kate (Nokia-FNDC/Helsinki) kate.alh...@nokia.com writes: I think that app store field fragmentation is no ones advantage. I fully agree but I would like to add that a app store monopoly is also not the optimum. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
-Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of David Greaves Sent: 16 September 2010 12:20 To: meego-dev@meego.com Subject: Re: [MeeGo-dev] Meego spec - for comment On 16/09/10 11:52, Counihan, Tom wrote: [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16 I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? Yes. So clearly this vendor has a policy to restrict which apps can run. Some may choose to be draconian fearing US litigation; others may go for a more liberated approach to the market. Why is MeeGo compliance mandating the draconian and forbidding the liberated? My comment was not to pass judgment on whether IVI OEMs are of a liberated or draconian bent. It is simply to present and perhaps shine some small light on what behavior and mindset we could expect from OEMs today. An OEM's HMI is a radically controlled and tested environment today. This ranges from 6 figure purpose built vehicles per model, facilitation 1000's of hours drive time testing in various climates ranging from sub-Sahara to arctic circle. Staff are encouraged to take advance health checks and advanced driving lesson, stuck in a 300+bhp 1 ton machine and told hare around Nurnberg or Fiorano as fast as insanely possible and change the radio station or take a hands free phone call. But they are inspired by mobile device movement in terms of accommodating rapid innovation, time to market and the app market is a key value for them. So, something like Meego Compliance for an app will be important in terms of assurance, but I suspect they will go through some extra post validation before they pull them into their app store - which I think reflects what Mark said earlier on this thread in terms of the choice being made by the distributor. Warm Regards Tom. -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Porting Guide available for reading
Don't know the schedules but I wouldn't make any final conclusions just based on the 1.1 release content. Things may change after that. Regards, Jari From: ext Jarmo Kuronen [mailto:jarmo.kuro...@symbio.com] Sent: 14. syyskuuta 2010 09:43 To: Palojarvi Jari (Nokia-MS/Tampere) Cc: meego-dev@meego.com Subject: RE: [MeeGo-dev] MeeGo Porting Guide available for reading Hi, -Original Message- From: jari.paloja...@nokia.com [mailto:jari.paloja...@nokia.com] Sent: Mon 9/13/2010 13:26 To: Jarmo Kuronen Cc: meego-dev@meego.com Subject: RE: [MeeGo-dev] MeeGo Porting Guide available for reading Hi, Does this mean that there will be no generic policy enforcement support for example to PulseAudio but All adaptations will roll-out their own PulseAudio enforcement modules from scratch? No. I just don't know enough details to say how this goes in reality at this point. Naturally it would be good to have all generic functionality readily available to all MeeGo OS users and thus minimize the need for vendor-specific adjustments. Do You know is there any schedule for these decisions - meaning that if those related components are not opened for example when MeeGo 1.1 is released - should one assume that those will not be opened at all? Br, Jarmo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Compliance spec and 3rd party dependencies: why are we all fighting?
So, I have personally lost complete track of the spec thread and decided to re-read the actual spec draft, that is, http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf After doing this, I'm wondering what exact wording in the spec we're fighting over. What I wondered after reading the thread - We have advanced package management, repositories, dependency solving, garage clients (OCS), app store like things. but the premise seemed to be: that we resort to what's essentially: if rpm -i packagename.rpm doesn't succeed on a fresh MeeGo device, packagename.rpm is not a MeeGo compliant application However. Did anyone -actually- read the spec? Let's start - in reverse: 227 Compliant Application Executables 228 All MeeGo compliant application executables shall be in the ELF format as described above and they shall import external interfaces from one of the following sources: 230 • shared libraries supplied as a part of the application package; 231 • shared libraries from third party packages that are MeeGo compliant itself and are 232 listed in the RPM package dependencies; 233 • MeeGo Core shared libraries if the interface is a part of the public interface of that 234 library as it is described in Appendix B. 235 If the executable is a plugin for a MeeGo system component it may import interfaces from 236 an executable of the system component and from shared libraries loading as part of that 237 executable. 238 Additionally, the executable may use public interfaces from shared libraries specific to a 239 MeeGo Profile, but in this case the application will be compliant with that Profile only. I would probably instead of shared libraries say 'services (shared libraries, d-bus services, etc)'. In this particular wording, there is nothing that blocks both vendors, or Maemo Extras from having shared libraries amongst components in a repository. Nor does it stop a vendor from having a closed source API which a compliant app would use which is maybe more of a problem. In the spec, there is already a hint of Unstable public interfaces – may be used by compliant applications but forward compatibility is not guaranteed for next MeeGo versions. (lines 222-223). How does this (philosophically) differ from a 3rd party dependency? I propose we add a section about dependency solving in the spec. And that it starts with: A MeeGo package can only be compliant if all it's dependencies can be found and retrieved and properly installed by all MeeGo reference devices during automatic compliance testing based on public repository information provided with compliance testing materials. And in this section try to counter 'bad' practices with regards to repositories. Last thing: Page 4, line 70-71: It shall use only external commands and other facilities described in this specification, whether for installation tasks or run-time tasks. A rather vague statement, which I read as that it should only use external commands or other facilities provided by the above API/Core packages and 3rd party packages that are compliant. Best regards, Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Port MeeGo on ARM11
Hi, To my understanding the MeeGo.com builds are for ARMv7. To compile for ARMv6, I would think that you need to have your own OBS that links to the MeeGo.com OBS + the necessary ARMv6 tool chain integrated to your own OBS. There's one link to OBS installation instructions on the MPG page. Other instructions may be found from the OBS pages on the web. If this is not a good way, I hope that someone tells the right way... Regards, Jari From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext evolution test Sent: 14. syyskuuta 2010 09:26 To: meego-dev@meego.com Subject: Re: [MeeGo-dev] Port MeeGo on ARM11 Hi, I have checked the link below. http://wiki.meego.com/MeeGo_Porting_Guide I need info on below points - - Currently i have base kernel avail for my board. To boot up board, image avail at below link will work for ARM6 architecture or do i need to create new image. (If yes - can any one provide me ks file for image creation) http://repo.meego.com/MeeGo/builds/trunk/0.9.80.1.20100330.1/n900/images/meego-codedrop-arm-developer. - It is possible to do source build for MeeGo by using toolchain (from codesourcey) for ARM6 architecture. (If yes - Is their any guideline doc available for the same) Regards, Vij As mentioned in below link first step is to try out already build image for N900 On Mon, Sep 13, 2010 at 5:55 PM, Jure Repinc j...@holodeck1.commailto:j...@holodeck1.com wrote: On Monday 13 of September 2010 13:11:54 evolution test wrote: Hello, I want to port MeeGo on ARM11MPcore (400 MHz/1440DMIPS). Can anyone suggest me how to proceed ?? For a start, have you already checked out The MeeGo Porting Guide? http://wiki.meego.com/MeeGo_Porting_Guide -- Nokia Certified Qt Developer Contributor to: Thousand Parsec - http://www.thousandparsec.net/ KDE - http://www.kde.org/ My Blog: http://jlp.holodeck1.com/blog/ ___ MeeGo-dev mailing list MeeGo-dev@meego.commailto:MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compliance spec and 3rd party dependencies: why are we all fighting?
On 16/09/10 13:55, Carsten Munk wrote: So, I have personally lost complete track of the spec thread and decided to re-read the actual spec draft, that is, http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf After doing this, I'm wondering what exact wording in the spec we're fighting over. What I wondered after reading the thread - We have advanced package management, repositories, dependency solving, garage clients (OCS), app store like things. but the premise seemed to be: that we resort to what's essentially: if rpm -i packagename.rpm doesn't succeed on a fresh MeeGo device, packagename.rpm is not a MeeGo compliant application However. Did anyone -actually- read the spec? Yes... However Arjan then said: http://lists.meego.com/pipermail/meego-dev/2010-September/005466.html which appears to have kicked the whole thing off :) However his statement has lead to a deep discussion; so even if it is (hopefully) rescinded, we've learned a lot in the debate. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 9/16/2010 4:06 AM, David Greaves wrote: On 16/09/10 11:26, Arjan van de Ven wrote: But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Precisely. Whereas if apps linking to Surrounds were compliant then maybe they'd think a little harder. Remember. They still have policy in their app store that can say no apps with external dependencies. But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 15:03, Arjan van de Ven ar...@linux.intel.com wrote: On 9/16/2010 4:06 AM, David Greaves wrote: But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. Can you clarify? The N900 is sold subsidised in the UK with Extras enabled. We've not heard anything that the Harmattan device will change this (apart from the security framework and the permissions granted to apps from particular repos); indeed, there was a discussion about this very topic: http://talk.maemo.org/showthread.php?t=56073 If you've got experience (or, even more importantly, knowledge) that this is going to change; I'm sure we'd like to know :-) Anyway, there's a lot of similar discussion in that thread once it gets into the realm of operator preferences. Similarly, it's not outside the realms of possibility that the customisations that an operator does on a phone may make the device no longer MeeGo compliant. This is one of the tools used by the OHA to try and minimise Android fragementation. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 2010-09-16, at 12:20 PM, David Greaves wrote: On 16/09/10 11:52, Counihan, Tom wrote: [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16 I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? So in case of a road death, who is liable for this Surrounds library exactly? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] meego-trunk: bluetooth problems caused by autosuspend patch
Hi All, I see lots of btusb_bulk_complete (...) failed to resubmit errors with the latest netbook image (meego-netbook-ia32-1.0.90.2.20100914.1) on my EeePC 1005-HA. The bluetooth connection(s) are flaky and unstable. I recompiled the kernel and removed the linux-2.6-usb-bt-autosuspend.patch and now it works fine. Is this the right place to report this? -Rolf -- Rolf Offermanns rofferma...@sysgo.com SYSGO AG Tel.: +49-6136-9948-0 Am Pfaffenstein 14 Fax: +49-6136-9948-10 55270 Klein-Winternheim http://www.sysgo.com Handelsregister: HRB Mainz 90 HRB 8066 Vorstand: Michael Tiedemann Aufsichtsratsvorsitzender: Juergen Bullacher USt(VAT)-Id-Nr.: DE 149062328 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, 16 Sep 2010 15:28:19 +0100 Anas Nashif nas...@linux.intel.com wrote: On 2010-09-16, at 12:20 PM, David Greaves wrote: On 16/09/10 11:52, Counihan, Tom wrote: [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16 I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? So in case of a road death, who is liable for this Surrounds library exactly? There is always the quality assurance justfication for locking down markets. You see this for example in the health care professions. There also is always the business reason for locking down markets. You see this for example in the health care professions. So let us be honest here, in the case of phones the business reason dominates by far. There is concern about liability of course, But the main reason is control of the market. The question in this discussion was whether a very strict compliance measure is needed. There are technical reasons for and against it. WIll the reason for strict compliance be the business reason of helping with control of the market? Manufacturers will face competition for the applications that run on their products, wether they want to or not. Forcing users to install multiple copies of libraries, that result in bloated application size, will make the device look bad, not just the installed application. Bernd -- Bernd Stramm bernd.str...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 15:28, Anas Nashif wrote: On 2010-09-16, at 12:20 PM, David Greaves wrote: On 16/09/10 11:52, Counihan, Tom wrote: The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? So in case of a road death, who is liable for this Surrounds library exactly? My comment was meant to support them in their action for exactly this reason. It did however suggest that if they were not restricted by their self-imposed policy, there would be no technical issues. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
- Original message - On 9/16/2010 4:06 AM, David Greaves wrote: On 16/09/10 11:26, Arjan van de Ven wrote: But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Precisely. Whereas if apps linking to Surrounds were compliant then maybe they'd think a little harder. Remember. They still have policy in their app store that can say no apps with external dependencies. But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. So why do we want to pander to that in meego.com? Isn't this about open source values, or did I misunderstand why helping the Maemo Community out with the OBS was such a huge issue? -- Ryan Abel Maemo Community Council member ___ 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 17:28:19 you wrote: *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? So in case of a road death, who is liable for this Surrounds library exactly? In case of a road death, who is liable for the MeeGo compliant application that has the same library bundled within it (as that is the alternative of not having Extras/Surrounds) ? Though I would ask myself first why anyone would allow Joe Coder's 3D pacman (MeeGo compliant or not) to run on mission critical hardware in the first place ? I'm still not sure if we are all on the same page here. The original stated compliance program goal was that if something is MeeGo compliant, it should be *ABLE* to run on a MeeGo compliant device and not that it *must* be allowed to run on it. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 4:36 AM, David Greaves wrote: On 15/09/10 23:59, Skarpness, Mark wrote: I view it the other way around: what requirements is compliance placing on the device manufacturer and are those reasonable and supportable. Setting the details of how compliant apps are packaged and delivered aside - compliance does not dictate whether or not a device allows apps to be installed (or which app sources are allowed) - that is a choice made by the device creator / distributor. Excellent. So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? Yes If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? No - that is a different problem. If compliance says that compliant apps can have external dependencies, then every compliant device MUST support those dependencies and ensure they are available to every device. That is the burden we are debating. This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. Device vendors are obliged to have the ability to run every compliant app. They are not obliged to allow the user to install every compliant app. So which of the previous arguments against Surrounds are still valid? The burden placed on the device vendor to ensure that all possible external dependencies are available to every device. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 15, 2010, at 11:39 PM, Alexey Khoroshilov wrote: On 09/15/2010 08:13 PM, Skarpness, Mark wrote: Hi Dave, On Sep 15, 2010, at 1:51 AM, Dave Neary wrote: I can get that a commercial application developer wants to be able to build a package which will install on any MeeGo device... we're not talking about requiring that people split off dependencies, but allowing that things can be done like that. The problem is that once we allow it, then we require everyone building a compliant device to support it. Otherwise we will miss the primary objective of compliance: every compliant app will run on every compliant device. One of possible approaches may be to have a second class of compliant applications with a separate name and a limited promise: Every second class compliant app will run on every compliant device if the device satisfies extra hardware requirements. Please check your device capabilities! While this is possible, it creates fragmentation. We want to have a simple, unified compliance story for MeeGo. Of course device vendors are free to add whatever they want on top of a compliant device (special apps that take advantage of unique hardware or software features, enable the use of external dependencies, ) - but those additions are specific to the device. It might be useful for apps tightly depending on some specific hardware features that cannot be added to MeeGo minimum hardware requirements by some reason. Support for MeeGo Extras/Surrounds can be considered as an extra hardware feature of a device as well. It's absolutely fine for a device to enable these - what we are debating is what MeeGo compliance will require all devices to support. Alexey Khoroshilov, ISPRAS / Linux Foundation ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 12:10 AM, Marius Vollmer wrote: ext Skarpness, Mark mark.skarpn...@intel.com writes: But my point was really that this decision does matter and does have an impact - if we allow applications to have external dependencies then someone has to pay to host them in a commercially scalable and reliable way. What about _internal_ dependencies? Should we allow applications to have dependencies to other packages in the same store? From a compliance point of view, the application needs to be self-contained (i.e. have no external dependencies that are not satisfied by the MeeGo required on-device package set). Compliance does not dictate the mechanics of how a compliant app is delivered to a device. I think this is up to the store, but the MeeGo package management should be prepared for it. Or in other words, if MeeGo doesn't get a credible Extras or Surrounds happen itself, others will hopefully do it without us, and we should at least not make it unecessarily hard for them to use dependencies between their packages. They might want to have their own UI for discovering things in their repository, but they should not need to implement their own package manager, of course. I'm not aware of any technical issues in making extras or surrounds work - what we are discussing is whether or not compliance will mandate that every device must support external dependencies for compliant apps. If MeeGo gets a credible Extras / Surrounds going, we need to support dependencies anyway (because without them I wouldn't call it credible). ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 7:24 PM, Skarpness, Mark mark.skarpn...@intel.comwrote: If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? No - that is a different problem. If compliance says that compliant apps can have external dependencies, then every compliant device MUST support those dependencies and ensure they are available to every device. That is the burden we are debating. Even though they might never ever allow an application with those dependencies to reach the device ? That sounds like quite a bit of dead weight, especially if, say, Python apps start aspiring for MeeGo compliancy at some point. This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. Device vendors are obliged to have the ability to run every compliant app. They are not obliged to allow the user to install every compliant app. That's OK. I'm curious, though, how this reflects on, say, hardware limitations - for example if someone submits an app that requires 1GB of RAM, there can be devices that cannot provide those resources and hence no ability to run it, while others will. Does that mean that devices can 'lose' compliancy over time, or that, depending on hardware, Compliant application might still not work on Compliant devices even with the same UX and same target API version, depending on actual resource requirements ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 1:36 AM, kate.alh...@nokia.commailto:kate.alh...@nokia.com kate.alh...@nokia.commailto:kate.alh...@nokia.com wrote: On Sep 16, 2010, at 1:02 AM, ext Skarpness, Mark wrote: On Sep 15, 2010, at 1:16 PM, Graham Cobb wrote: 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! yes they will - that is the whole point of MeeGo compliance - to get scale in the application ecosystem by enabling applications to run across multiple devices. Allowing applications to depend extra libraries that are also compliant does not affect this at all. It does not make difference any bit if application uses some library X is X comes with application or comes from public quality controlled repository. It may not matter to you as a developer but it definitely does matter if you are the person deploying the device. It adds significant cost and complexity to the deployment process. 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. No, I don't agree. MeeGo compliance is about creating a large, unified application ecosystem with apps sold through multiple app stores on multiple devices. High end applications made by pig companies usually does not need to depend some extra libraries and they has man force to maintain packetize all libraries they need. In other end, there are big amount of smaller developers that rather would like to use ready made libraries tested and proof to work and without all hassle involved integrating and maintaining library. We have a solution for widely used libraries - we put them into MeeGo core so they show up on all devices. But mostly i where is the point, what we will achieve by forcing every developer pack and maintain copy of library and not allowing them to use tested and quality controlled version from repository Kate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Le jeudi 16 septembre 2010 à 19:47 +0300, Attila Csipa a écrit : Does that mean that devices can 'lose' compliancy over time I think this should be solved with versionning. So program X can be shipped as being compliant to spec 1.0 and lower. This indeed assumes every major increments of the spec will raise or keep the minimum hardware requirement. Also, it might be best for OEM if those bumped are schedule with fixed cycle, especially for deployment of lower cost devices. This would help determine the live time of those devices. Nicolas signature.asc Description: This is a digitally signed message part ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 10:07 AM, Nicolas Dufresne wrote: Le jeudi 16 septembre 2010 à 19:47 +0300, Attila Csipa a écrit : Does that mean that devices can 'lose' compliancy over time I think this should be solved with versionning. So program X can be shipped as being compliant to spec 1.0 and lower. This indeed assumes every major increments of the spec will raise or keep the minimum hardware requirement. Also, it might be best for OEM if those bumped are schedule with fixed cycle, especially for deployment of lower cost devices. This would help determine the live time of those devices. Yes, that's right - compliance is to a specific MeeGo version and the spec for each version will include minimum hardware reqts. Over time, those reqts will go up and older devices will no longer be able to upgrade. We'll need to agree together on what is a reasonable upgrade window - I would guess on the order of 2-3 years. Nicolas ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 17:24, Skarpness, Mark wrote: On Sep 16, 2010, at 4:36 AM, David Greaves wrote: So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? Yes Good. If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? No - that is a different problem. If compliance says that compliant apps can have external dependencies, As it does: http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 231/232 then every compliant device MUST support those dependencies and ensure they are available to every device. That is the burden we are debating. If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? The burden of dependency resolution... which is specifically required to be compliant (http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf lines 231/232 again) This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. Device vendors are obliged to have the ability to run every compliant app. Fine. They *could* run every compliant app that depended on another compliant app *if* they permitted it to be installed. But, since They are not obliged to allow the user to install every compliant app. Then they simply forbid installation. So which of the previous arguments against Surrounds are still valid? The burden placed on the device vendor to ensure that all possible external dependencies are available to every device. No. You said yourself : They are not obliged to allow the user to install every compliant app. They simply forbid the installation of apps for which they cannot provide dependencies. So what does this achieve? Apps depending on shared libraries can be labelled compliant. Vendors are under no obligation to support Extras and have zero additional burden. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] threm event
Hi all, My /var/log/message is getting filled with localhost klogd: []called:mid_therm_event Is there a bug on this and can we get this turned off in debug levels? Thanks, Dana Ferguson UMSE Validation Oregon Desk/Lab : (503) 264-6773 dana.r.fergu...@intel.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Don't mix app compliance with enabled repos (was Re: Meego spec - for comment)
if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. So why do we want to pander to that in meego.com? Isn't this about open source values, or did I misunderstand why helping the Maemo Community out with the OBS was such a huge issue? Please don't mix the discussion about application compliance with the discussion about enabling repositories. They are orthogonal. The MeeGo project will offer to MeeGo vendors a flexible approach starting with the Security Framework (allowing fully open and fully closed options) and ending to the gateways to Extras, AppUp, Ovi and whatever else comes. But it's up to the vendors to decide the openness ans the allowed sources for each product. There is nothing really to be discussed about this here at meego-dev. Let's keep the discussion in the MeeGo Compliance until we are all in the same page, please. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 10:42 AM, David Greaves wrote: On 16/09/10 17:24, Skarpness, Mark wrote: On Sep 16, 2010, at 4:36 AM, David Greaves wrote: So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? Yes Good. If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? No - that is a different problem. If compliance says that compliant apps can have external dependencies, As it does: http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 231/232 I did not catch that in the draft - thanks for pointing it out. then every compliant device MUST support those dependencies and ensure they are available to every device. That is the burden we are debating. If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). The burden of dependency resolution... which is specifically required to be compliant (http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf lines 231/232 again) That will be removed in the next rev...this is the first draft. This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. Device vendors are obliged to have the ability to run every compliant app. Fine. They *could* run every compliant app that depended on another compliant app *if* they permitted it to be installed. But, since They are not obliged to allow the user to install every compliant app. Then they simply forbid installation. So which of the previous arguments against Surrounds are still valid? The burden placed on the device vendor to ensure that all possible external dependencies are available to every device. No. You said yourself : They are not obliged to allow the user to install every compliant app. They simply forbid the installation of apps for which they cannot provide dependencies. So what does this achieve? Apps depending on shared libraries can be labelled compliant. Vendors are under no obligation to support Extras and have zero additional burden. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications * define the spec in a way to minimise the imposed burden on vendors Arjan, Mark : do you want to achieve this? If we, as MeeGo, believe in the opensource build on the work of others and co-develop shared components ... then why do we prohibit the underlying development model that got us here? What message does that send to the Vendors? So I want to leave the door open for community developed apps that build upon the work of other compliant apps to be accepted (optionally!) into app stores and be of equal standing to statically-linked apps. To do this they *must* have a compliance label. You need a spec that ensures that apps are widely deployable and reliable? We have established that vendors need not provide a way to install every compliant app. Given that vendors can prohibit some compliant apps then the spec should allow them to prohibit compliant apps that depend on unavailable compliant libraries. How could we word this to say that? Something around 157 where it says Applicaiton packages SHALL require (in RPM terminology) all system and third party comonents add: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hello, I was originally against Mark's ideas, but I think I finally got his point. I'll try my best at explaining the argument as clearly as possible. On Thu, 2010-09-16 at 18:42 +0100, David Greaves wrote: On 16/09/10 17:24, Skarpness, Mark wrote: On Sep 16, 2010, at 4:36 AM, David Greaves wrote: So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? Yes Good. If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? No - that is a different problem. If compliance says that compliant apps can have external dependencies, As it does: http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 231/232 I believe that part of the spec will have to be changed. then every compliant device MUST support those dependencies and ensure they are available to every device. That is the burden we are debating. If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. I agree that it can be labelled compliant. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? If no external dependencies are allowed, the device vendor only has the burden of providing the core api. Since every device provides this api, every compliant app is guaranteed to be able to run on the device. If a developer wants an application to run on all Meego devices, the developer has only one task: get the app in enough repositories so that they together cover every Meego device. If external dependencies, let's say to compliant software in the Surrounds repo, are allowed, then the device vendor must provide access to the Surrounds repo. That is the additional burden. Now you probably ask why it is mandatory to provide access to Surrounds. Because if it's not mandatory, and a developer wants the application to run on all Meego devices, then the developer has two tasks: get the app in enough repositories so that they together cover every Meego device AND convince the all device vendors to enable the Surrounds repo. The difference between the two tasks is that getting an app in enough repositories is not necessarily a technical problem, and hopefully possible to solve in most cases, but getting all device vendors to enable some external repo (e.g. Surrounds) is probably pretty impossible. Therefore, allowing external dependencies causes severe fragmentation among Meego Compliant applications. There are probably Meego compliant applications that have no chance to get accepted in all repositories, which also causes fragmentation, but I guess people are expecting that fragmentation to be small enough to be tolerable. I was a bit disappointed when I realized this. This means that many Meego Compliant applications will contain who knows how old and insecure library versions bundled with the main app. The Meego Compliant label won't have any value for me personally, I'll stick to the properly packaged Extras... -- Tanu Kaskinen ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 9/16/2010 11:44 AM, David Greaves wrote: On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications I strongly object to the use of the term open source here. It's not open source, it's not even about the development model. It's about a componentized application with cross app shared components. * define the spec in a way to minimise the imposed burden on vendors It's not about minimizing the burden (although that's part of it). It's about having something that is viable and interesting for vendors and operators alike. These guys have a set of strong desires that you need to be able to meet to have a product (and meego is just a component of such a product) that interests them. I know a lot of people here don't like or agree with that model. But the model is just market reality right now. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 19:09, Skarpness, Mark mark.skarpn...@intel.com wrote: On Sep 16, 2010, at 10:42 AM, David Greaves wrote: If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). And, and this is the kicker, *how* did the device get the dependee *without* also having a mechanism to get the dependencies? Whilst the only mechanism of getting the second package is to get it from the same repo as the first; cannot *both* be Compliant? Take the second package as a file, without the dependencies, on a USB stick and - perhaps - it's *not* Compliant. Is that viable? A package can be Compliant if it's alongside its dependencies (or if the installation of its dependencies, which must be Compliant as well). Take the package *out* of that environment and it becomes not Compliant. Thoughts? Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 9/16/2010 12:42 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010Agreed. Mandating Surrounds would be a burden. What about, then, as a compromise going back to one of the earlier suggestions and saying that each repo containing MeeGo Compliant packages can depend on a well-defined set of other repos. For some vendors that may include MeeGo Surrounds; but for others it won't. realistically, we can't even mandate the core meego.com repo. Many of these vendors will run their own whole repo set ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 20:45, Arjan van de Ven ar...@linux.intel.com wrote: realistically, we can't even mandate the core meego.com repo. Many of these vendors will run their own whole repo set Indeed. So mandate none. Make compliance of a package dependent on the ability of the repository to guarantee that all its dependencies can be met. For Extras/Surrounds that'd be itself and the Core. Is there some technical or theoretical reason that *couldn't* work? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 19:09, Skarpness, Mark mark.skarpn...@intel.com wrote: On Sep 16, 2010, at 10:42 AM, David Greaves wrote: If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). And, and this is the kicker, *how* did the device get the dependee *without* also having a mechanism to get the dependencies? That is the crux of the problem - if you allow compliant apps to have external dependencies, then you require compliant devices to provide a mechanism to get the dependencies. Whilst the only mechanism of getting the second package is to get it from the same repo as the first; cannot *both* be Compliant? Take the second package as a file, without the dependencies, on a USB stick and - perhaps - it's *not* Compliant. Each could be compliant on their own - but if App A requires App B to run, then App A is not compliant (unless App B is included with App A). Is that viable? A package can be Compliant if it's alongside its dependencies (or if the installation of its dependencies, which must be Compliant as well). Take the package *out* of that environment and it becomes not Compliant. We run into trouble when a compliant app requires the installation of something else from an external source in order to run. If we can find a solution to that problem - then it could work. Thoughts? Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 20:45, Arjan van de Ven ar...@linux.intel.com wrote: realistically, we can't even mandate the core meego.com repo. Many of these vendors will run their own whole repo set Indeed. So mandate none. Make compliance of a package dependent on the ability of the repository to guarantee that all its dependencies can be met. For Extras/Surrounds that'd be itself and the Core. You lost me here - it sounds like we are still mandating the availability of repositories to enable a compliant application to run. Can you say more about how this would work? Is there some technical or theoretical reason that *couldn't* work? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 20:06, Arjan van de Ven wrote: On 9/16/2010 11:44 AM, David Greaves wrote: On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications I strongly object to the use of the term open source here. It's not open source, it's not even about the development model. However it is the the archetypal open source development model. It's about a componentized application with cross app shared components. Yes... it is. So maybe you could address this point where I clarified that : If we, as MeeGo, believe in the open source model that builds on the work of others and co-develop shared components ... then why do we prohibit the underlying development model that got us here? * define the spec in a way to minimise the imposed burden on vendors It's not about minimizing the burden (although that's part of it). I would apologise... but I could go back and quote each of the objections and that's how they tend to start. I can only address the objections raised. It's about having something that is viable and interesting for vendors and operators alike. These guys have a set of strong desires that you need to be able to meet to have a product (and meego is just a component of such a product) that interests them. I know a lot of people here don't like or agree with that model. But the model is just market reality right now. Again, many of us are not naieve or dim. I'd like to see the problems put into a crystaline form or we're tilting at windmills. And you haven't answered the million dollar question: Arjan, Mark : do you *want* to aim to permit the componentized application with cross app shared components that so typifies the way 99% of open-source development works for compliant applications *Please* note I said permit and not mandate. Given both of your histories I cannot believe we are not ultimately aiming for a very, very similar goal. So how do we identify it and achieve this? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 21:00, Skarpness, Mark mark.skarpn...@intel.com wrote: On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote: Is that viable? A package can be Compliant if it's alongside its dependencies (or if the installation of its dependencies, which must be Compliant as well). Take the package *out* of that environment and it becomes not Compliant. We run into trouble when a compliant app requires the installation of something else from an external source in order to run. If we can find a solution to that problem - then it could work. Suggested wording: If a package requires anything from outside the Core, it is Compliant only if it is provided via a mechanism which can also provide all its dependencies. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 21:00, Skarpness, Mark wrote: On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 19:09, Skarpness, Markmark.skarpn...@intel.com wrote: On Sep 16, 2010, at 10:42 AM, David Greaves wrote: If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). And, and this is the kicker, *how* did the device get the dependee *without* also having a mechanism to get the dependencies? That is the crux of the problem - if you allow compliant apps to have external dependencies, then you require compliant devices to provide a mechanism to get the dependencies So this require compliant devices to provide a mechanism to get the dependencies is a problem. OK Whilst the only mechanism of getting the second package is to get it from the same repo as the first; cannot *both* be Compliant? Take the second package as a file, without the dependencies, on a USB stick and - perhaps - it's *not* Compliant. Each could be compliant on their own - but if App A requires App B to run, then App A is not compliant (unless App B is included with App A). Actually, it is by the current draft :) However, I take your point. Is that viable? A package can be Compliant if it's alongside its dependencies (or if the installation of its dependencies, which must be Compliant as well). Take the package *out* of that environment and it becomes not Compliant. We run into trouble when a compliant app requires the installation of something else from an external source in order to run. If we can find a solution to that problem - then it could work. Did you manage to read my email in this torrent :) In that I suggested we add: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. This keeps us pure. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. This could be your solution. At this point, to use your words: when a compliant app requires the installation of something else from an external source in order to run. it MUST NOT be installed if the something else from an external source cannot be provided. Can we work on this approach? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
actually, please ignore this email... I stand by it but I think maybe it is more argumentative than constructive ... I was trying to get at the goals/objectives but it's not well phrased.sorry if I offended. The next one focuses on Mark's issues and has more concrete proposals. David On 16/09/10 21:05, David Greaves wrote: On 16/09/10 20:06, Arjan van de Ven wrote: On 9/16/2010 11:44 AM, David Greaves wrote: On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications I strongly object to the use of the term open source here. It's not open source, it's not even about the development model. However it is the the archetypal open source development model. It's about a componentized application with cross app shared components. Yes... it is. So maybe you could address this point where I clarified that : If we, as MeeGo, believe in the open source model that builds on the work of others and co-develop shared components ... then why do we prohibit the underlying development model that got us here? * define the spec in a way to minimise the imposed burden on vendors It's not about minimizing the burden (although that's part of it). I would apologise... but I could go back and quote each of the objections and that's how they tend to start. I can only address the objections raised. It's about having something that is viable and interesting for vendors and operators alike. These guys have a set of strong desires that you need to be able to meet to have a product (and meego is just a component of such a product) that interests them. I know a lot of people here don't like or agree with that model. But the model is just market reality right now. Again, many of us are not naieve or dim. I'd like to see the problems put into a crystaline form or we're tilting at windmills. And you haven't answered the million dollar question: Arjan, Mark : do you *want* to aim to permit the componentized application with cross app shared components that so typifies the way 99% of open-source development works for compliant applications *Please* note I said permit and not mandate. Given both of your histories I cannot believe we are not ultimately aiming for a very, very similar goal. So how do we identify it and achieve this? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 19:50, Tanu Kaskinen wrote: If no external dependencies are allowed, the device vendor only has the burden of providing the core api. Since every device provides this api, every compliant app is guaranteed to be able to run on the device. If a developer wants an application to run on all Meego devices, the developer has only one task: get the app in enough repositories so that they together cover every Meego device. If external dependencies, let's say to compliant software in the Surrounds repo, are allowed, then the device vendor must provide access to the Surrounds repo. That is the additional burden. Agreed. See my wording proposal to the spec: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. Ta da... burden lifted. Surrounds friendly vendors (like Nokia) can still support MeeGo compliant Extras that make use of Surrounds. Nasty and mean vendors who don't want to risk killing all the people in their car (ok, that makes them not-so-mean) don't provide access to Surrounds and must not install Extras apps. Now you probably ask why it is mandatory to provide access to Surrounds. Because if it's not mandatory, and a developer wants the application to run on all Meego devices, then the developer has two tasks: get the app in enough repositories so that they together cover every Meego device AND convince the all device vendors to enable the Surrounds repo. Not at all. That risk is assumed by a developer who uses Surrounds. http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 157 No right minded commercial vendor will do this; nor will any GPL vendor aiming for mass market appeal. The objective is *not* to get Surrounds into devices by the back door it is to *not forbid* the eventual inclusion. Massive difference. Caveat Developer. The difference between the two tasks is that getting an app in enough repositories is not necessarily a technical problem, and hopefully possible to solve in most cases, but getting all device vendors to enable some external repo (e.g. Surrounds) is probably pretty impossible. It is pretty damned hard. Is it easier if the spec says Applications using the optional Surrounds repo are compliant Now, if the spec says Applications using the optional Surrounds repo are not compliant Which one bodes well for the long term acceptance of Surrounds? Maemo has shown it can be done. Nokia enable Maemo Community Extras *by default* on their top-end device... the N900. And they promised (?) to do this in the future... but only when you don't buy a subsidised carrier version. Now... when vendors sell an unsubsidised version of a device they *could* follow Nokias lead but they won't if it's against the spec. Therefore, allowing external dependencies causes severe fragmentation among Meego Compliant applications. There are probably Meego compliant applications that have no chance to get accepted in all repositories, which also causes fragmentation, but I guess people are expecting that fragmentation to be small enough to be tolerable. I was a bit disappointed when I realized this. This means that many Meego Compliant applications will contain who knows how old and insecure library versions bundled with the main app. The Meego Compliant label won't have any value for me personally, I'll stick to the properly packaged Extras... Indeed... and if we slowly and gently make people aware of the benefits ... and haven't pre-emptively branded 'Surrounds/Extras' as non-compliant... then we can start to influence them. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 2:44 PM, David Greaves da...@dgreaves.com wrote: I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications * define the spec in a way to minimise the imposed burden on vendors Thanks for trying to pull things back to the basics --- I think the discussion has kinda gone all over the place... From what I've seen, I at least do agree with these two goals --- We definitely need a model that will work for hardware vendors - otherwise we won't get anywhere... However, I also think that for many use cases, mandating full inclusion of all dependencies will hurt a lot - it'll cause package bloat, and cause tonnes of old, bug ridden copies of libraries to be floating around on users drives. Earlier in the thread there was discussion around 2 levels of compliance - a 'strict' compliance that requires inclusion of all dependencies, and a more relaxed compliance that allows dependencies on an 'Extras' style repository... To me, this still seems like the best approach - I think we need some kind of official recognition for well-formed, tested apps that include dependencies... Thoughts? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 21:04, Skarpness, Mark mark.skarpn...@intel.com wrote: On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote: Make compliance of a package dependent on the ability of the repository to guarantee that all its dependencies can be met. For Extras/Surrounds that'd be itself and the Core. You lost me here - it sounds like we are still mandating the availability of repositories to enable a compliant application to run. Can you say more about how this would work? Example, we have fooapp, bobapp, libbaz, libbar and libc. * libc is in MeeGo Core and can be depended on by anything. * libbaz is in MeeGo Extras, depends on libc and is Compliant. * libbar is in MeeGo Extras. It depends on libbaz and is ALSO Compliant, because it is in Extras; and since it can only be got from Extras, the thing retrieving it must be able to get libbaz as well. * fooapp is in MeeGo Extras. It depends on libbar and is ALSO Compliant, for the same reasons as libbar. * bobapp also depends on libbar. It's in Ovi Store. Imagine that Nokia ship Extras and Ovi enabled in all their devices. bobapp is in Ovi, and can be in MeeGo Compliant as only Nokia devices can have Ovi and all Nokia devices have Extras available and enabled to provide their dependencies. However, if the bobapp developer uploaded the package to another repo, it may not be Compliant, as the covenant that it's dependencies MUST be resolvable isn't met. Then, the developer would have to upload the source packages (or binary) from Extras to that third party repo as well; or link them in statically. Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 4:42 PM, Warren Baird wjba...@alumni.uwaterloo.ca wrote: Earlier in the thread there was discussion around 2 levels of compliance - a 'strict' compliance that requires inclusion of all dependencies, and a more relaxed compliance that allows dependencies on an 'Extras' style repository... Just to be clear - 'strictly' compliant apps would then be able to run on all devices - 'relaxed' compliant apps would be able to run on all devices that can access the 'Extras' style repo... To me, this still seems like the best approach - I think we need some kind of official recognition for well-formed, tested apps that include dependencies... Thoughts? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, 2010-09-16 at 20:42 +0100, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 19:50, Tanu Kaskinen ta...@iki.fi wrote: If no external dependencies are allowed, the device vendor only has the burden of providing the core api. Since every device provides this api, every compliant app is guaranteed to be able to run on the device. If a developer wants an application to run on all Meego devices, the developer has only one task: get the app in enough repositories so that they together cover every Meego device. And if they have external dependencies they have to ensure that *those* are in as many repos as possible. That's a developer problem, not a vendor problem. Hmm... For some reason I didn't consider this - I sort of assumed that if some library is in Surrounds, then every device must get it from Surrounds. But like applications, libraries can of course also be published in multiple repositories. This may cause some problems with different versions of the same package being available in different repositories, but the big fragmentation problem that I was presenting doesn't really exist, as far as I can see. I'm back in the allow dependencies camp. -- Tanu Kaskinen ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hello! It seems that in your mind, each vendor will provide their own app store, it will be the very common case where the vendor will decide which of the various app stores he will use. appstores are 'the thing' nowadays, and Nokia and Intel each have their own already I wouldn't be surprised if others either do their own completely, or syndicate an existing one but with their own control. now MeeGo extras is a great idea, and I can't wait to see all those MeeGo Touch Framework apps show up and be available for the meego.com users. But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com My comments regarding AppStores: * The central AppStore that Apple offers likely sounds good to a provider (control, central, big) but what I read from the press is that besides the political aspects the Apple AppStore is neither safe nor secure. Apple is likely only doing automated scans of the software so bad software did get through and likely a lot of softare that crashes also gets through. So the application in the Apple appstore are not better than the apps in the maemo repositories because the Apple app store is save or Apple is doing fancy checks on the software. There are likely others reasons for that, some of them are related to critical masses of apps, users and users. * Fragmented app stores on the other hand have marketing problems because they are simply smaller and quality is poor (seems like that sometimes is the case with Adroid app stores, having a natial app store version already has negative influence). App stores in this case start to be a burdon for the provider not a feature. Conclusion: app stores are very new and everybody tries to immitate the currently successful model, but this model has its defiencies , too, and it is possible that providers opinion will change and there will be room for other solutions, that are centralized, of high quality and have very low entry barrier. Thus we should not get too influenced by the current situation but strongly sell our vision als alternative and better aproach. If we are not talking about phone, things might be different (cars, TVs) since Apple and Android have not app stor yet and thus the starting sutuation is different. -- Gruß... Tim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hello! Imagine that Nokia ship Extras and Ovi enabled in all their devices. bobapp is in Ovi, and can be in MeeGo Compliant as only Nokia devices can have Ovi and all Nokia devices have Extras available and enabled to provide their dependencies. However, if the bobapp developer uploaded the package to another repo, it may not be Compliant, as the covenant that it's dependencies MUST be resolvable isn't met. Then, the developer would have to upload the source packages (or binary) from Extras to that third party repo as well; or link them in statically. This however means that there can be no central instance to decide if an application is compliant or not just based on the application package and its contents and thus an applications compliance is in relation to the platform it is running. So bobapp's web page and package description would say: * This is the wonderful bobapp. It is Meego compliant for Device Zupp and Device Wusch but not for Device ExtraLess. Is this the kind of complicance statement that e.g. marketing has ordered ;-)? Would such compliance statement be of any help? -- Gruß... Tim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Le jeudi 16 septembre 2010 à 20:49 +0100, Andrew Flegg a écrit : Is there some technical or theoretical reason that *couldn't* work? Actually users will have problems when two repositories start providing same package (name clash or file clash) and user problems result in customer support fees. regards, Nicolas signature.asc Description: This is a digitally signed message part ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 9/16/2010 1:45 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 21:04, Skarpness, Markmark.skarpn...@intel.com wrote: On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote: Make compliance of a package dependent on the ability of the repository to guarantee that all its dependencies can be met. For Extras/Surrounds that'd be itself and the Core. You lost me here - it sounds like we are still mandating the availability of repositories to enable a compliant application to run. Can you say more about how this would work? Example, we have fooapp, bobapp, libbaz, libbar and libc. * libc is in MeeGo Core and can be depended on by anything. * libbaz is in MeeGo Extras, depends on libc and is Compliant. * libbar is in MeeGo Extras. It depends on libbaz and is ALSO Compliant, because it is in Extras; and since it can only be got from Extras, the thing retrieving it must be able to get libbaz as well. * fooapp is in MeeGo Extras. It depends on libbar and is ALSO Compliant, for the same reasons as libbar. * bobapp also depends on libbar. It's in Ovi Store. 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
(high latency due to draft email hiding behind open windows) On 16/09/10 15:03, Arjan van de Ven wrote: On 9/16/2010 4:06 AM, David Greaves wrote: On 16/09/10 11:26, Arjan van de Ven wrote: But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Precisely. Whereas if apps linking to Surrounds were compliant then maybe they'd think a little harder. Remember. They still have policy in their app store that can say no apps with external dependencies. But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. That is indeed why I said Nokia, not Vodafone. Vodafone probably won't allow Surrounds/Extras (initially) - but at the idea is that at least they won't be able to say you're not compliant. Nokia, as you know, ships the N900 with Extras enabled out of the box. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 9/16/2010 3:05 PM, David Greaves wrot That is indeed why I said Nokia, not Vodafone. Vodafone probably won't allow Surrounds/Extras (initially) - but at the idea is that at least they won't be able to say you're not compliant. Nokia, as you know, ships the N900 with Extras enabled out of the box. ... and then you have apps that claim compliance that work on some version on phone X930 but not on other versions of phone X930 does not sound like a winning proposition to the value of compliance to me. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 23:13, Arjan van de Ven wrote: On 9/16/2010 3:05 PM, David Greaves wrot That is indeed why I said Nokia, not Vodafone. Vodafone probably won't allow Surrounds/Extras (initially) - but at the idea is that at least they won't be able to say you're not compliant. Nokia, as you know, ships the N900 with Extras enabled out of the box. ... and then you have apps that claim compliance that work on some version on phone X930 but not on other versions of phone X930 does not sound like a winning proposition to the value of compliance to me. Aside: very selective emails you're replying to here Arjan - I'd be grateful if you could find the time to respond to some of the ones that have concrete solutions too. Technically the apps will, of course, work on all X930s if the vendor permits. Let us say there is a fully compliant adult app and two carriers offering the X930 who only offer apps via their app store. I daresay that it will be allowed in some regions and not others. ... and then you have apps that claim compliance that work on some version on phone X930 but not on other versions of phone X930. So mere compliance does not protect you from fragmentation due to policy. But you knew that. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo image for armv6
On Thursday 16. September 2010 08.49.59 evolution test wrote: Hi, Do we have MeeGo image which can run on armv6 ?? The ARMv5 image should run on ARMv6. Unfortunately, due to server capacity issues, the ARMv5 builds have been disabled for now. They'll return in the future. Any work is going on for porting MeeGo on armv4 ?? No. Is there any reason why we should consider ARMv4? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ 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] Still question on MeeGo on devkit8000
Thanks Amit Pundir! Does it mean I should not follow http://wiki.meego.com/ARM/Meego_on_the_Beagle, and should follow http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch? I guess Meego_on_Beagleboard_from_scratch page is guide us to self-build a kernel and rootfs, instead of quick installing a pre-compiled one for N900. Is my understanding correctly? Samuel 2010/9/16 Amit Pundir pundira...@gmail.com: On Thu, Sep 16, 2010 at 3:35 PM, Samuel Xu samuel.xu.t...@gmail.com wrote: Hi: I hit the simiar issue(booted, while no X) as vijay singh, when I want to run MeeGo on top of devkit8000. I followed Steps to modify an N900 image for BeagleBoard at http://wiki.meego.com/ARM/Meego_on_the_Beagle, using http://repo.meego.com/MeeGo/releases/1.0/core/images/meego-n900-open-armv7l/meego-n900-open-armv7l-1.0.0.20100525.1-sda.raw.bz2 and http://wiki.meego.com/images/Meego-beagle-kernel.tar.bz2 My u-boot cmd is: setenv bootcmd 'mmcinit; fatload mmc 0 0x8200 uImage;bootm 0x8200' setenv bootargs 'mem=256M console=ttyS2,115200n8 mpurate=600 buddy=unknown vram=12M omapfb.mode=dvi:1024x768mr...@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait' boot Hi, I got it running few weeks back by following the instructions from here http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch I hope things will work out fine for you as well. MeeGo can boot into shell in serial cmd prompt. while I found the external monitor (connected via HDMI=DVI) is black after a blinking. Boot information(boot-log) is attached. I also tried startx from serial cmd shell, I know it is not reasonable to start x from this shell, while the attached debug information(startx) might be useful. Appreciate guide on how to process to start X on my devkit8000. If you do exactly the same as mentioned in that wiki page, you will land safely :) because I made some mistakes while copying the rootfs to MMC card and that gave a set of permission errors. Due to which my UI was not coming up. Make sure you are copying the rootfs onto the card as mentioned in the wiki to retain the same set of permissions/privileges as needed. Regards, Amit Pundir Samuel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo image for armv6
On Fri, Sep 17, 2010 at 4:05 AM, Thiago Macieira thi...@kde.org wrote: On Thursday 16. September 2010 08.49.59 evolution test wrote: Hi, Do we have MeeGo image which can run on armv6 ?? The ARMv5 image should run on ARMv6. Unfortunately, due to server capacity issues, the ARMv5 builds have been disabled for now. They'll return in the future. Thanks for answer.. Currently my board have ARM11 MPcore(X3) I am planning to run MeeGo on 1 of the ARM11 core. Based on your answer it is possible to run ARMv5 build MeeGO image on ARMv6K (ARM11 Mp Core). It means i can create MeeGo image from : // http://repo.meego.com/MeeGo/releases/1.0.1/core/repos/armv5tel/ Do any one already tested armv5tel image on ARMv6K architecture.?? Any work is going on for porting MeeGo on armv4 ?? No. Is there any reason why we should consider ARMv4? Just want to check about support for the same. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Friday 17 September 2010 00:44:43 you 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. ...which is not that much of an issue, because with proper path/rpath handling those libraries would not conflict the vendor supplied ones (Compliant ones can't dump their stuff in /usr/lib anyway, right ?), and if they do conflict, due to some shared resources like ports or magic files/sockets somewhere, the same would happen if libbar was statically linked into fooapp. Been there, done that (this has come up in Maemo between Nokia repos and Extras, and has been acted upon, so Extras now contain even alternative versions of Qt). Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
