Re: [MeeGo-dev] Who will keep pushing MeeGo?
On Fri, Sep 30, 2011 at 12:08 PM, Tethys . tet...@gmail.com wrote: On Fri, Sep 30, 2011 at 6:59 PM, quim@nokia.com wrote: The trend of using web technologies to cover the apps space is clear and pushed by many factors e.g. something simple to develop simple features and compatibility across the jungle of platforms. I actually agree with it. To an extent, but I'd say the web is only simple to develop for if you're writing simple apps. For anything more complex, I'd *much* rather have a proper native development environment. I'd even go as far as to say that the web is a developer-hostile environment for anything but trivial apps. I'm not particularly wedded to MeeGo, and I'll quite happily use Tizen instead. But only if I can develop in my choice of languages and for me that means writing native code. I think there are plenty of people who would disagree (about web being developer-hostile). You could look at the Microsoft Windows 8 activities that recently had so much blogged and otherwise written from the recent event. Whether web replaces native, here's one man's opinion: http://www.informationweek.com/news/development/web/231500197?cid=nl_IW_daily_2011-08-18_html there are plenty of others, of course. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Wireless network is no longer detected on Lenovo hybrid netbook
On Tue, Aug 16, 2011 at 2:48 PM, Bogdan Cristea crist...@gmail.com wrote: On Sunday 14 August 2011 23:16:11 you wrote: On 8/14/2011 1:09 PM, Bogdan Cristea wrote: I have updated MeeGo to kernel 2.6.37.2-8.43 on a Lenovo hybrid netbook, but the wireless connection is no longer available. With the default MeeGo installation (1.1.99.0.20110330) everything worked fine, but the configured repository was no longer available and I have switched to a new one (version 1.2.0.90.12.20110805). Could you provide a link to a stable MeeGo repository ? you're using the wrong kernel.. netbooks should be using the kernel-adaptation-pinetrail kernel which is 2.6.38 not 2.6.37 based thanks Hi I have installed MeeGo 1.2 stable release and updated the kernel to 2.6.38.2-8.9 adaptation pinetrail but still the wireless connection is disabled. I have checked in bios menu that the wireless is enabled. Does anyone know how can I have a working wireless connection on Lenovo S10-3t ? there's a physical switch on the case as well, I managed to get that turned off by accident a while back and had lost my wireless that way. can you check? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] ARM summit at Plumbers 2011
On Tue, Aug 9, 2011 at 12:15 PM, Steve McIntyre steve.mcint...@linaro.orgwrote: The initial proposed agenda is: * ARM hard-float + What is it and why does it matter? + How can distributions keep compatible (i.e. gcc triplet to describe the port)? * Adding support for ARM as an architecture to the Linux Standard Base (LSB) + Does it matter? + What's needed? * FHS - multi-arch coming soon, how do we proceed? * 3D support on ARM platforms + Open GL vs. GLES - which is appropriate? but I'm sure that other people will think of more issues they'd like to discuss. :-) from the point of LSB and FHS (as I'm part of both of those workgroups), I don't know if there will be anyone there representing those groups, but if that would be valuable it might be possible to prod LF into sending Jeff Licquia - just ask early enough! Otherwise... Steve, you know where to poke at us. My email address might hint that I might not have any time to work on it, but I'll always answer questions :) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-qa] No scrub meeting for bugs assigned to triaget...@meego.bugs
On Fri, Jul 29, 2011 at 11:46 AM, Ware, Ryan R ryan.r.w...@intel.comwrote: On 7/28/11 10:04 PM, Timo Härkönen timo.harko...@digia.com wrote: On Fri, 2011-07-29 at 07:52 +0300, Zhou, JieX A wrote: Hi all, There is no scrub meeting for bugs assigned to triaget...@meego.bugs today. By our last scrub meeting, all the open bugs assigned to this account have been scrubbed and now all these bugs have been updated accordingly. And by now, there are still 5 open bugs waiting for further action: snip I don't know how good idea it is to copy-paste descriptions of security bugs here. Those have limited access in bugzilla for a reason. Yes Please! Now we've announced to the world that MeeGo is vulnerable to CVE-2010-3879 and CVE-2011-0640 and that we have no current fix for it. Security bugs are private for a reason. well, it's worth remembering they're not really that private no matter what their bz status may be, especially once a CVE is issued. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego sill alive ?
On Sat, Jul 16, 2011 at 8:56 AM, David Boosalis david.boosa...@gmail.comwrote: Thank you for taking the time to reply and the list of commits is very impressive. How does one get the commits, is there a repository I can add. And is is there any plans to get Meego SDK working on Ubuntu 11.04 before 11.11 ships. yes. it works now, but the announcement is held up waiting for QA to finish. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] GLES v1/v2 -- compliance
For the purposes of compliance is only GLESv2 required, or is v1 also required? If the latter, we have an issue to figure out in that there seems to be some variance in library names (the Mesa version is /usr/lib/libGLESv1_CM.so.1 and the EMGD version is /usr/lib/libGLES_CM.so.1) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libproxy and core compliance
On Mon, Jun 20, 2011 at 10:40 AM, Sergio Schvezov sergius...@ieee.orgwrote: I'm currently taking recommendations to implement obtaining the proxy from system configuration, most people seem to recommend libproxy, which is fine. The problem I see with it is that if you take a look at the MeeGo Compliance document (latest: http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.1.80.1.pdf), you'll find it is marked as dep and not as core. As an application developer that might seek forward compatibility, the fact that this is not part of the *MeeGo API* and secondly, that it is marked as dep bring in concerns. Is it possible to have this included as part of the API or is there a project underway to have Qt implement this functionality wrapping around libproxy or something? core, is forward compatibility guaranteed if linking against core symbols which are not listed in the MeeGo API? I had responded privately that libproxy didn't seem to be in the set at all for 1.2, but it turns out it's now provided by the pacrunner package. It's still in the category of not being part of the MeeGo API and that means there are no promises outside of the release in which it appears. The core/dependency distinction is conceptually that core means it appears in the architecture diagram, and dependency means it doesn't, but is still needed for a functional stack. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Why the list of supported hosts for SDK is too short?
On Sat, Jun 18, 2011 at 6:55 AM, Andrey Ponomarenko aponomare...@ispras.ruwrote: ** Hi there, The MeeGo SDK for Linux [1] officially supports only Ubuntu and Fedora. I've checked it on popular openSUSE and Debian 5 and it doesn't work there (it hangs on the first one and crashes on the second one). hmmm, those two are supposed to work. could you file a bug on the Debian issue? on openSUSE... as a wild guess, does it hang at 34%? these seem to be a couple of things that go wrong here, at the beginning of trying to modify the system it does a sudo and I've seen it sometimes not launch, or launch hidden, or get confused because there's no entry in the sudoers file. as part of the same step it also seems to get stuck trying to figure out if a proxy is needed, and ends up connecting to localhost instead of the intended remote host, and then looping endlessly on this step. Why the list of supported hosts is too short? because it's a bit tricky and effort has gone other places. I know that MeeGo is Moblin + Maemo. Why not to use the Maemo-like SDK installer [2] based on the Scratchbox [3]? It supports much more (if not all) Linux hosts. something like this is under consideration. but the current release has to get working right for people, so further details would certainly be useful (bugzilla's a good place to track) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Handset Profile
Hi Guys, Is this page still current? http://wiki.meego.com/Quality/Compliance/HandsetProfile I hear there are changes afoot in the handset UX. It hasn't really received any attention from anyone in the know, if that helps answer the currency question. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Update/RFC on MeeGo Compliance Spec == 1.2
The pdf upload bug on the wiki has been squished (thanks!) so I've made sure the page now shows both the 1.1 approved spec and the first iteration of the 1.2 spec, only minimally changed from 1.1. At this point, comments are welcome (well, of course they're welcome at any time). The spec is still in PDF format which I know is not the ideal review medium as it makes it hard to submit patches. Remember, for issues that should be tracked, bug/feature filings are good, it's easy to miss nuances that are just on the list, or on IRC, etc. At the same time, there are now three work-in-progress Profile specs, which are directly on the Wiki. I don't know yet which ones of these will end up in the 1.2 specification - that's up to the workgroups to push - but if you have insights into filling these in, please share. http://wiki.meego.com/Quality/Compliance -- mats ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-architecture] MeeGo Compliance, specifically IVI
meego-architecture-boun...@lists.meego.com wrote: Hello, I'd like to discuss a specific area of compliance for IVI systems. Before I get to the subject matter, I'd like to know if I'm following the correct process so I can address the right people. My first stop was the MeeGo wiki where I searched for Compliance and arrived here: http://wiki.meego.com/Compliance_primer_draft_Feb2011 Is this the current canonical source for compliance in MeeGo? the up to date/approved version of that is at: http://wiki.meego.com/Quality/Compliance_primer_1.0 but really, the canonical source is the compliance spec itself. In that document it states Currently MeeGo supports five different verticals: Netbooks, Handsets, Connected-TVs, In-Vehicle Infotainment systems and tablets. Each of these verticals will have a Compliance Profile. I take that to mean that the In-Vehicle Infotainment (IVI) will have a separate compliance specification. Does that mean the IVI compliance specification is independent of the overall MeeGo compliance specification? The intent is that each workgroup/vertical write (*) a layer document, which adds on to the base compliance. At the moment the implementation of that is a chapter in the single compliance document, describing the profile for the vertical. There's only one instance in 1.1, the Netbook profile, which says very little, so it's not clear to me if that model is actually going to work long term, but let's try it. There's a second example on the wiki, which was an initial effort at a handset profile: http://wiki.meego.com/Quality/Compliance/HandsetProfile (*) write could consist of just feeding me (as the spec editor) the appropriate information, and then doing reviews. Lastly, I'd like to know the specifics about OpenGL, particularly OpenGL ES. Is OpenGL ES going to be part of compliance in MeeGo IVI? it's going to be part of the core compliance as of 1.2. I don't think we've envisioned a model where a vertical /removes/ any components from the core, so that would make the answer Yes, I guess, without knowing anything specific about IVI. Hope this helps. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-architecture] MeeGo Compliance, specifically IVI
meego-architecture-boun...@lists.meego.com wrote: That document has a version number very similar to the MeeGo version numbers. Does that mean they track each other? Or is that just a coincidence? If they follow each other, are there relevant documents for MeeGo 1.2? Does the spec change significantly from one version to the other? it's not a coincidence, there should be a matching compliance spec for each meego.com release. changes will be very small once things settle, however the likelihood of changes at this stage is still fairly high - much more on the application viewpoint than the system viewpoint. there's no public draft of 1.2 compliance yet; think of 1.1 with the exceptions removed (there's one indicting the ARM abi will change, another that the GL-GLES change is happening); and that there will be a different package list, determined by the patterns described at http://wiki.meego.com/Quality/Compliance_Implementation (Incidentally 1.1 is complete/approved, the fact that the wiki still only has drafts is due to a strange config problem that wasn't allowing pdfs to update, I need to check if that's resolved now and update if it is) (we shouuld probably trim the number of lists this goes to; meego-dev is considered the home for compliance discussion, but it's okay to keep it on the IVI list if you prefer, I'm signed up there now) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] 1.1 and 1.2 Compliance
meego-dev-boun...@meego.com wrote: On 07/05/11 23:00, Jeremiah Foster wrote: On Tue, May 3, 2011 at 10:43 PM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: meego-dev-boun...@meego.com wrote: http://www.meego.com/Quality/Compliance_Implementation hope that's of some use... and of course here too comments are more than welcome. That is giving me a 404 error currently. Try: http://wiki.meego.com/Quality/Compliance_Implementation oops, sorry about that typo (in normal circumstances I'd paste but there are some weird doings when I'm going through the corporate vpn) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] 1.1 and 1.2 Compliance
meego-dev-boun...@meego.com wrote: I heard at the last TSG meeting that the 1.1 compliance spec is approved. Any idea when we'll see a 1.2 compliance draft? Also, this page also seems out-of-date: http://wiki.meego.com/Quality/Compliance If the out of date is due to not showing a released 1.1 spec, true. There is/was a problem with uploading of pdf files (only), which has prevented me from adding the final copy - note the last review copy points to my directory on the LF site, as that's a place it worked to put it. There are some other out of dates on the page, true. There's some work started on the 1.2 draft, could upload one any time, but not sure at the moment there's enough update to make things interesting. Comments/suggestions/bug filings/anything else relevant are quite welcome - not stalling, just collecting material to the point where new drafts are worthwhile! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] 1.1 and 1.2 Compliance
meego-dev-boun...@meego.com wrote: knowing that not much will change for 1.2 compliance -- I think that's interesting to know, since I hope to ship a 1.2 compliant device soon. :-) it's a fair point. the biggest changes I know of are the ABI issues related to GL (Atom Qt libs linked against GLES now, to match ARM) and ARM ABI (hardfp vs. softfp), which are things clearly reflected in the actual package builds anyway; plus refinements in the required package list, which are reflected in the group patterns. On the latter point, there's a new wiki page which tries to pull together how compliance is developed from the distribution side, it hasn't really been circulated yet and is kinda unpolished, but this seems as reasonable a moment as any to mention it: http://www.meego.com/Quality/Compliance_Implementation hope that's of some use... and of course here too comments are more than welcome. -- mats ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Is there any compliance document of UI for Meego Netbook?
There is a Netbook profile (it's about a page in the main compliance document), and one could expect a Tablet profile in the next generation of the Compliance Spec. But note that the User Experience (UX) layer is outside the scope of compliance, since it's considered replaceable if a vendor wants to do so. Is that the question you're asking? -- mats From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Rohit Baravkar Sent: Monday, April 18, 2011 6:38 AM To: meego-dev Subject: [MeeGo-dev] Is there any compliance document of UI for Meego Netbook? Hi, Is there any compliance document of UI for Meego Netbook/Tablet? There is compliance document for Handset-UI, but not for netbook. Any updates on it? Thanks, Rohit ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Systray
meego-dev-boun...@meego.com wrote: 2011/3/30 Leonardo Luiz Padovani da Mata leonar...@syst.com.br: On Wed, Mar 30, 2011 at 12:03 PM, Pei Lin telent...@gmail.com wrote: 2011/3/30 Thiago Macieira thi...@kde.org: On Wednesday, 30 de March de 2011 11:20:35 Leonardo Luiz Padovani da Mata wrote: There is an QT API for that: http://doc.qt.nokia.com/latest/desktop-systray.html Using the new protocol for the system tray is preferable. It requires updating QSystemTray to support it, though. THank you. Yes, QT have the api for systray, it is ok for KDE. But in Meego netbook UX, display icons in bottom blank tray bar looks bad. i want to put my application icon on the top toolbar in Meego as http://help.meego.com/netbook/settings/customize-toolbar/custom ize-toolbar But didn't find the API to handle it. Check the code and find meego toolbar writed by GTK + Clutter. I don't know about an API, maybe other people may help, but you can add a Menu on toolbar by adding it's .desktop and add X-Meego-Panel entries. Check the .desktop with this entries on /usr/share/mutter-meego/panels Also, you should add the service on dbus, check the contents of the package meego-panel-pasteboard, you will see the .desktop file and the dbus file that register the service. Thank you. The information is very useful for me. I will try it. :-) it's worth considering that the Netbook UX is simply a different design concept, it was never intended to provide the system tray concept. this topic has come up a number of times before, maybe there's some of the older advice archived somewhere or someone who knows the area well can comment. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] how to play a video is h.264 in meego-handset-video player
try installing gst-ffmpeg plugins which contains h264 decoder and since meego-video player uses playbin2, once your ffmpeg plugins are installed, you should readily be able to play your h264 video. that's not in the public repository... which was the point. On Thu, Feb 17, 2011 at 3:04 PM, Carsten Munk cars...@maemo.orgmailto:cars...@maemo.org wrote: 2011/2/17 ssuk hyun kim ssukh...@gmail.commailto:ssukh...@gmail.com: Hi All, I am trying to play a video which is h.264 via meego-handset-video player on N900. But it doesn't play. ogg plays well. N900 is installed MeeGo handset 1.1 image. Please let me know how to video can play mp4 and h.264. Regards, SH MP4 and H264 aren't supported in MeeGo out of the box because of royalty/patent issues. It's possible to install codecs manually though. /Carsten ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
There's a section of the document that talks about forward compatibility. In theory, developing your app on MeeGo 1.1 would allow it to work on 1.1 and on for the whole life of 1.x, to my understanding at least. If you target 1.2, from 1.2 and onwards. Should rpm be relied on fully to capture the symbols or would it be ok to forcefully/explicitly 'Require' a meego-release = desired_version. meego-release is not in the appendix, that's why I'm asking. If I've missed another way to accomplish this I'd really like to know. yeah, it's a good question, one I've chatted with a few people about. depending on meego-release of particular versions is the only way right now, but it seems there was some reluctance to formally require that apps do so - leaving it optional, I guess. I hadn't noticed it wasn't in the package list, that seems a problem. what do other people think we should do here? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] glibc vs. eglibc
I think you're missing some details here. It's not the Red Hat version, sources.redhat.com is merely a hosting site, and that version is in fact the official GNU libc, the ones you'd get from ftp.gnu.orgftp://ftp.gnu.org. eglibc is a fork, created initially because the glibc project declined to continue full support for certain embedded scenarios. So while you might be right that eglibc is more suited to certain situations (basically, if the processor architecture is not well supported by glibc), the terms you've used to describe this are incorrect. From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Jeremiah Foster Sent: Tuesday, February 15, 2011 7:27 AM To: meego-dev@meego.com Subject: [MeeGo-dev] glibc vs. eglibc Hello, Is there a reason that MeeGo uses the Red Hat version of glibc[0] versus the GNU version of glibc[1]? It seems eglibc is more appropriate for embedded systems. 0. http://sources.redhat.com/glibc/ 1. http://www.eglibc.org/home -- Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance primer - consolidated and ready for reviews
it would be helpful to have a thorough review of the FAQs at the end, as there may be common questions that haven't been answered yet. I think the first one which comes to mind, as I've gotten this question frequently already, is around kernel configuration. adaptation is likely to involve adding a driver or two - how is this done without triggering the checker tool's objection about spec changes? can any of the configuration options be changed? can unused drivers be omitted? etc. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Freedesktop.org specifications and compliance
meego-dev-boun...@meego.com wrote: Freedesktop.org has some specifications that are relevant to developers: http://www.freedesktop.org/wiki/Specifications Does being MeeGo include a promise to follow some of these specifications, or is it left entirely up to the vendor to implement whatever they deem fit? My primary interest at this point is the autostart spec: http://www.freedesktop.org/wiki/Specifications/autostart-spec I've been assuming that the ones mentioned in LSB can be considered a given (Base Directory, Desktop Entry, Desktop Menu, Icon Theme) although it's possible nothing says so explicitly. The rest... it sure seems like Autostart is being followed, should this and others be added to the compliance spec? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
Antti Kaijanmäki wrote: On Fri, 2011-02-04 at 08:43 -0700, Wichmann, Mats D wrote: Hoping some of you have time to take a look and supply comments... http://wiki.meego.com/Quality/Compliance, as usual. current version is the .7 revision. Section 3: Application Compatibility I assume this section talks about 3rd party applications like the ones you go and buy from Ovi-store, right? Could you please add a clause to clarify that system integration and vendor software (components in section 2) are not required to follow this scheme. A component might still be an application, like some applet or UX related software, and this might cause some confusion without the clause. yes, you're right, it's just for 3rd party (there's no really good term for this, not part of the distribution is another way that doesn't sound good). what sort of clarification did you have in mind? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
meego-dev-boun...@meego.com wrote: On Fri, 2011-02-04 at 12:39 -0800, Arjan van de Ven wrote: this would be a great idea for the 1.2 compliance spec to add imo. (but this doc is still the old 1.1 compliance) OK, so you don't want to add anything new to this 1.1, right? When will we begin to draft 1.2? It seems there's quite a lot of things to specify so better get started sooner than later :) about now would be the answer... were just hoping to get 1.1 into a somewhat official state so there's a clear starting point. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
meego-dev-boun...@meego.com wrote: Hi, I just begin to work with Meego and particularly with Meego Compliance. In 3.2.2, the specification says: They shall import external interfaces only from the following sources: * shared libraries supplied as a part of the application package My question: There is a preferred/recommended/mandatory method to load this libraries in order to avoid clashes shared libraries of different applications? For example, two 3rd party applications supplied libgsoap.so, one libgsoap.so.1 and the other libgsoap.so.0, if both exposes its shared libraries one of them probably will crash. There's no brilliant answer here. If a number of apps need the same library there's probably a case it ought to be promoted to become a system library. If an app has to supply its own shared library, the namespacing rules come into effect - the library should be located in the app's own file hierarchy, say for foo it would be located somewhere under /opt/foo, and in this case there should be no risk of another application accidentally finding that copy and running into problems because it's not quite compatible. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How can I know one package is built from which source package with zypper tool?
meego-dev-boun...@meego.com wrote:
Hi,
zhu wrote:
For example.
I know libqtopengl4 is built from qt-4.7.1-3.1.src.rpm.
Does any zypper command can know libqtopengl4 came's from
qt-4.7.1-3.1.src.rpm.
like what yumdownloader do:
yumdownloader --source libqtopengl4 .
Does this do what you want?
zypper wp libqtopengl4
(wp is short for whatprovides).
You can then install the source package by taking the entry in the
Name column as the package name:
zypper si qt-4.7.1
or whatever.
Would you mind documenting your conclusion in the wiki page when
you're finished, please? http://wiki.meego.com/Zypper
I thought zypper si would do that correctly just given a binary
pkg name... if not:
you could define a macro that uses rpm to fetch the name, which
it knows... it's a little grotty I guess, but you want something
like:
zypper si `rpm -q --qf '%{SOURCERPM}\n' libqtopengl4`
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Broadcom WiFi guide updated
meego-dev-boun...@meego.com wrote: Hey Folks, Just a heads up that the Broadcom drivers have gone through a revision over christmas. I've updated my guide and source rpm to pull down the latest driver. See http://slaine.org/_slaine/Meego_1.1_Wifi.html why does it say for the upcoming MeeGo 1.1 release ? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Do someone know how to disable ScreenSave in handset image?
I know in Android it's possible to do this programmatically (and screen blank control rights are part of what you have to accept when installing such an app). I believe we'll have to provide something similar. individual apps shouldn't need to (or be allowed to) fiddle the system in the ways suggested below. What happens after the app quits? Screen blank is still off... From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Zhao, Forrest Sent: Wednesday, December 29, 2010 1:10 AM To: Zhu, Junmin; meego-dev@meego.com Subject: Re: [MeeGo-dev] Do someone know how to disable ScreenSave in handset image? In general it's related to DPMS or screen saver daemon. Try the below 2 methods as is suggested at http://ubuntuforums.org/showthread.php?t=639639 1 xset s off; xset -dpms 2 kill the screensaver daemon on your system Thanks, Forrest From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Zhu, Junmin Sent: Wednesday, December 29, 2010 3:53 PM To: meego-dev@meego.com Subject: [MeeGo-dev] Do someone know how to disable ScreenSave in handset image? Hi all, Because we need to run application on handset image with screen non-black for long time. After I remove libXScrnSaver, xorg-x11-proto-scrnsaverproto, but the screen will turn black all the same. Here, anyone know how to disable screensaver? Thanks best wishes Junmin Zhu OTC/SSD/SSG Tel: 86 21 - 6116 7375 Cube: 3w186 / Inet: 88217375 No. 880 Zi Xing Road, Shanghai Zizhu Science Park, Min Hang District Shanghai (200241) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo migration path?
meego-dev-boun...@meego.com wrote: Em Terça-feira, 14 de Dezembro de 2010, às 16:45:28, Jechlitschek, Christoph escreveu: Hi all, I was wondering if there exists a migration path from MeeGo 1.0 to MeeGo 1.1 and later to MeeGo 1.2. This is very interesting for companies that have devices in the field and want to push an upgrade to the next higher version (instead of just an update within a version). Is it just a zypper dist-upgrade with new repositories? Yeah, sounds about right. :-) in theory, but things do change and I've certainly seen cases on other distros where that doesn't work correctly. so the question is, is version upgrading a supported target? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] progressing on compliance spec
since there still seem to be a number of open questions, I'd like to set up a #meego-meeting on a regular basis until we've come to more agreement. For those who are interested, are there particular times that would be bad (obviously already taken times are out since the meeting channel is single-threaded) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] New MeeGo Compliance Spec for TSG meeting Dec 1
There's a new version of the document up on the wiki page now (http://wiki.meego.com/Quality/Compliance#Specification) In the previous TSG consideration of the spec, there were concerns around the GL/GLES question, and around the description of the Platform API. To attempt to address those, changes: - in section 2.5, it's noted that Atom platforms use OpenGL and ARM platforms OpenGL ES - in section 3.4, the MeeGo API bullet list no longer includes GL or WRT - in section 3.5, the Platform API now calls out GL, notes the arch difference, and indicates a future direction that's known (all GLES) and one that's possible (once it's all GLES, move to MeeGo API) - also in 3.5, wording changed to indicate the Platform API is everything else in Core model is the current state, but might not always be the case, hopefully providing a bit further incentive for developers to consider the MeeGo API the thing to look at. There's also a line added to the warning about lesser compatibility, that it's possible the Platform API might be reduced in size in future. these changes are diff-marked. if there are further changes before tomorrow, let me know - one change already got caught after my first effort (I hadn't understood the state of GL was different between ARM and Atom, hopefully that's now expressed in a way that matches the implementations) -- mats ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
meego-dev-boun...@meego.com wrote: The subject of how the MeeGo API is defined came up in the TSG yesterday, and against my better judgement I managed to inject myself into a discussion about standards. The way it's currently phrased, the MeeGo API is a very limited set of libraries (Qt, QtMobility and GLES, plus the web framework). Everything else is reserved for the Platform API, which carries no promise of future availability. I made the point that a literal reading here would make applications that link against the POSIX.1 symbols noncompliant. The answer came back that glibc was an obvious candidate for the MeeGo API, and didn't need to be specified. And for the C library I suppose that's true. But I think the issue is a more complicated spectrum than that. What about other useful APIs that are always present for a Qt app on linux? Is an app directly linking to zlib compliant (I don't think Qt wraps this)? How about libjpeg (which is abstracted by the framework)? What about an app which executes a shell script; can we assume a /bin/sh (or /bin/bash) will be present? What about a shell script that invokes tar or bzip2? I can understand the need for excluding a bunch of low level facilities that may be deprecated in the future, and limiting what constitutes MeeGo for forward-portable applications. But the way it's done right now rules out a lot of stuff that I don't think was intended. Is it worth going through the core package list more carefully and expanding the MeeGo API definition? I expect you'll get divided opinions on that, let's see what the reactions are. For me, we should identify stuff that's truly useful, and stable, and promote it to first class status. But I think there is a constituency that believes program to Qt and as an emergency exception if Qt doesn't wrap that yet there are a few other things you maybe could use - for now. And yes, you're allowed a shell script; tar/bzip2 don't appear to be in the package list (bzip2-libs is) though. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
meego-dev-boun...@meego.com wrote: On Thu, Nov 11, 2010 at 01:27:44PM -0800, Andy Ross wrote: The subject of how the MeeGo API is defined came up in the TSG yesterday, and against my better judgement I managed to inject myself into a discussion about standards. The way it's currently phrased, the MeeGo API is a very limited set of libraries (Qt, QtMobility and GLES, plus the web framework). Everything else is reserved for the Platform API, which carries no promise of future availability. I have just recently read the developer pages on this very subject, and I was surprised to find the distinction, that Meego Touch Framework and the Web Runtime are in a Platform API with warnings against using them. More clarification is indeed needed, as far as I am concerned. In the case of these two, it's a question of maturity. Since the current versions aren't fully mature, it can't be promised they won't change in the next version. There's nothing to prevent, and indeed it's the intent, to promote these to high-guarantee status once the right level of maturity is reached. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] New version of compliance specification
All: There's a new version of the specification on the wiki page (http://wiki.meego.com/Quality/Compliance) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] New version of compliance specification
Line 250: Isn't the GL ES 2.0 thing more of a MeeGo 1.2 thing? I would actually state GL as base requirement for IA as the Qt is built against GL. On ARM it's GL ES 2.0 minimum.. hmmm, I thought I was reacting correctly to what people were telling me works now. if not, we'll have to fix it again. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-architecture] MeeGo compliance questions (Platform API definition, and X11 presence)
meego-architecture-boun...@lists.meego.com wrote: Hello, We encountered some matters with the recent MeeGo 1.1 Compliance Specification (draft 1.0.99.3) that would be nice to be clarified. Is there someone who could comment on these? 1) Specific definition of Platform API Line 279: The Platform API consists of public interfaces from all libraries provided by MeeGo Core (see Appendix A). As the packages in Appendix A have been split to core and dep(endencies) categories, and the dep packages are included in MeeGo mostly due to being the dependencies for required core packages, and interesting question emerges: Does the Platform API consist of public APIs of just the core packages in list, or both core and dep packages? Both. The core/dep column is intended only as a guide as to why a package is present in the required list, not to provide any sort of recommendation. 2) Inclusion of X.org in the Platform API In chapter 2.5 Graphical Subsystem, seems that OpenGL ES support is not required to be tied to X11 in any way (on EGL level window/display tidbits obviously need to be adapted for whatever there is as the window system, but that does not concern application developers). For the ordinary UI level code then, Qt 4.7 is there in the MeeGo API. Looks like there is no definite need for X11 to be part of the API, even though it of course can be part of the underlying implementation. However, an X11 implementation (specifically X.org) is present in the Platform API. What are the reasons to provide any layers below Qt and OpenGL ES for the 3rd party developers to use? Supporting the use of X11 calls directly from 3rd party applications creates an unnecessary X11 lock-in for cases, where a MeeGo-compliant product could be otherwise done with a much more streamlined (and better performing) architecture. Are 3rd party developers expected to use X11 for some specific purposes in their new code, or is this more of an attempt to ease porting of legacy applications to the platform? Some of the platforms may well eventuall not have X11 underneath, so you're right about this. I think opinions were somewhat divided for a while about whether the whole stack was allowable, or whether it should be more limited. For this version at least, the choice was that if it's in the required set you can use it - but whether you *should* use it is a different question. You've highlighted a reason why one might not, and why the Platform API comes with much weaker guarantees than the MeeGo API. Hopefully the SDK and checker tools will be able to provide portability advice in a sensible fashion to help with this. P.S. Sorry about posting on two separate mailing lists; was a bit unsure on how much people follow meego-architecture list. Followups to just the meego-architecture list perhaps. although it's in a sense an architectural topic, compliance questions have lived on meego-dev so far so I've actually sent it there. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compliance spec updated 1.0.99.2
jari.paloja...@nokia.com wrote: Hi, Just took a look at 1.0.99.3. I'd like to point out one potential issue related to System Implementation / Platform Compliance and the MeeGo Core Packages list. If all compliant platforms must include the binary packages listed in the MeeGo Core Packages list, I suppose that all SW components in those packages are also expected to be present and work in all compliant platforms (%files in spec files not allowed to be changed)? However, as we all know, compliant platforms can differ from each other when it comes to device/HW adaptation. Device/HW adaptation typically consists of plugins to some user space frameworks (GStreamer, PulseAudio, Resource Policy, Sensor Framework, oFono, X, Qt Mobility APIs etc.) and device drivers (plugins to Linux kernel). And different platforms can have a different set of HW adaptation related plugins. Do the packages now listed in MeeGo Core Packages include device/HW adaptation related SW components that are specific to some HW environment? E.g. do the oFono, Sensor Framework and PulseAudio packages contain SW components that are not applicable/sensible in all environments? If they do, isn't that a bit problematic (components required to be present but not used/functional)? Or have I misunderstood something? I don't think there's adaptation stuff in there - but I haven't worked on the package list, just been handed it, so we'll need to wait for others to comment. How should we handle/mention this aspect in the compliance specification? There's two parts to it: (1) bits which are unique to a whole platform family should be in the profile (2) bits which aren't even that common, such as down to a specific device, need to be fuzzed in a way that make it clear it's a behavior and not a specific package that is required. An example of this style (the only case at the moment) is saying GLES is needed but not mandating that it come from Mesa. This kind of stuff needs to be called out to avoid the issues you mention (e.g., requiring non-functional or not-needed bits), and to do that, someone has to identify those piece so they can be covered - I don't have any of that information! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Compliance spec updated 1.0.99.2
Things still seem to be in some state of flux, but there's an updated edition on the page now. http://wiki.meego.com/Quality/Compliance ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] new draft of MeeGo compliance specification
meego-dev-boun...@meego.com wrote: Em Sexta-feira 22 Outubro 2010, às 17:28:36, Carsten Munk escreveu: 'A MeeGo compliant distribution MUST use the same tool chain and the same compiler options as the reference implementation. The tool chain MAY be patched to solve compiler bugfixes accepted in upstream GCC as long as they do not break ABI or API' maybe? Compiling with a different compiler (like RVCT or ICC) is not compliant then? The required ABI is clearly GCC's, so any deviation by another toolchain is a bug in that toolchain. Again, I'm just able to repeat what people have said to me... there's nervousness about rebuilding the distribution with anything other than what it was originally built and QA'd with. Applications are a different story, it should be possible to use alternate toolchains there. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] new draft of MeeGo compliance specification
Skarpness, Mark wrote: On 10/22/10 8:56 AM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: meego-dev-boun...@meego.com wrote: Em Sexta-feira 22 Outubro 2010, às 17:28:36, Carsten Munk escreveu: 'A MeeGo compliant distribution MUST use the same tool chain and the same compiler options as the reference implementation. The tool chain MAY be patched to solve compiler bugfixes accepted in upstream GCC as long as they do not break ABI or API' maybe? Compiling with a different compiler (like RVCT or ICC) is not compliant then? The required ABI is clearly GCC's, so any deviation by another toolchain is a bug in that toolchain. Again, I'm just able to repeat what people have said to me... there's nervousness about rebuilding the distribution with anything other than what it was originally built and QA'd with. Applications are a different story, it should be possible to use alternate toolchains there. I don't think we should forbid the use of other toolchains - but say that the MeeGo toolchain is recommended and others are allowed (with wording around the GCC ABI compatibility as Thiago suggests). okay, I'll make that change with a few others that are pending and put the revision back up this weekend ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] new draft of MeeGo compliance specification
Carsten Munk wrote: Quick run through - hope this is constructive criticism: yes, it was good stuff, thanks. Line 72, we really need to spell out that it is ARMv7, EABI, softfp (for 1.1) as there is emerging tendancies in industry to use hardfp too. I'll take any info I can get here, nobody's given me any details for this area. Do you have proposed wording? Line 75-76, IVI is not a supported profile? Lines 127-129, given that GCC 4.5 in MeeGo 1.1 isn't exactly the best when it comes to compiler bugs on ARM and some other areas, is there an exception to compiler bug fixes as these might be needed to actually productize? suggestions for a way to say this? I'll poke around and see if there are objections. Line 182, MeeGo 1.1 Xorg server actually has --disable-xinerama so we can't demand this as compliance (please verify rest on a running implementation). Hmmm, good point. For GLESv2 you should require that an implementation must Provide: libGLESv2.so.2 exists (can be a symlink) and libEGL.so.1 (can be a symlink) Line 187, don't we need more than 'uses 2.6.35 kernel or later'? There should be a requirement on the minimum of options to provide on a MeeGo install for a userland to run. I think so, but so far despite a few references about as detailed as yours (should have a list of config options), the details haven't been forthcoming. Lines 241-242, regarding the heated issue: I agree there's no good technical way to test for compliance with non-core-non-ux-deps right now, but I would propose we set up a work group to work on this exact issue to come up with a proper solution for 1.2 timeframe - you agree? There certainly seems to be enough people passionate about the issue and we should be able to come up with a good solution in a proper constructive work group. I'd like to think so. Lines 249-250: This doesn't ring true in my ears - MeeGo compliant app means that my app will install and run, right? I think this needs more work and specification before it should be allowed - the RPM subarchitecture stuff might be a direction but (d) must always be true or we can't rely an app being compliant meaning it will install and work on my device. yeah, not enough detail here for it to be useful. Didn't quite know what to do with this proposal that came in privately, and didn't get any comments later to resolve it. Lines 262: there's also a patchlevel (.35) in current MeeGo 1.1 Is it important to add this (ref: bash version, which is only listed as 4.0)? MeeGo Core packages: most apps will base on let's say, libGLESv2.so.2 instead of 'mesa' - is it stated anywhere that for these things, a drop-in ABI-API compatible .so is OK too? the GL stuff is a special case, yes. The distro chapter suggests this by not calling out an implementation, but rather that GLES support is what matters. sound like there should be something in the application chapter as well. General comment: I think it would be wise to state something about compliant package distribution. It would be good to discourage straight-rpm downloads and encourage repositories instead due to making it possible to receive security updates of the application. And the philosophical comment: compliance document only states what MeeGo requires, not what too much about what it promises in terms of it's platform development. Let's say, if we do ABI/API breaks doing major releases or not.. the hard part will be not doing them on minor releases :( what did you have in mind here? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Touch support in X (was: QtMobility has branched)
meego-dev-boun...@meego.com wrote: On 19/10/10 6:47 PM, ext Thiago Macieira thi...@kde.org wrote: Em Terça-feira 19 Outubro 2010, às 17:31:10, sakari.pou...@nokia.com escreveu: Hi, For MeeGo 1.2 the X.org 1.10 release is too late. We did not upgrade kernel and X in the beginning of the 1.2 cycle because we wanted to keep the codeline stable and working. We would not upgrade X in the end of the cycle either. That should be pretty clear common sense. The only solution that I can see is to go with what Thiago proposed below. That is a solution which works now in Harmattan. The maintainer of the code is open as stated below. Thanks for replying Sakari. I'll check what we can do to reduce the maintenance burden of the patch. This is a bit unfortunate for us since we do need to focus on XInput 2.1 anyway: other teams will not stop because of MeeGo. If they forge ahead with the development, we need to be a part of it to ensure our needs are met. Yes - I agree. It is unfortunate but many times the upstream schedules don't match with distro's. that is certainly true, but can we really afford to have 1.2 without proper touch support unless we use a dead-end fork that nobody at the moment wants to spend time on? this sounds like a pretty big issue to me. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] new draft of MeeGo compliance specification
There's a fresh draft up, finally: http://wiki.meego.com/Quality/Compliance#Specification Please comment on this one. Note: last time, the issue of dependencies, or not, generated a lot of heat. This version states pretty clearly that dependencies outside the required minimum install are not allowed. That's simply the current direction, I can't predict if a future direction will expand the scope. This version contains a package list, but no version numbers. -- mats ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to get a unique uid for a device running meego?
meego-dev-boun...@meego.com wrote: On Mon, 18 Oct 2010, Nicolas Dufresne wrote: Le lundi 18 octobre 2010 à 02:32 +0100, Radi, Rami a écrit : How can one get a unique device uid in meego which can be easily read from an application. This question is a little ambiguous. Do you want to generate a UUID ? in which case you can read from /proc/sys/kernel/random/uuid or use libuuid. Maybe you need a UID for specific file in /dev ? for that you can use libudev. But if you need a system unique identifier, I don't think that this can be made portable. As an example, on Phones, you want to use the IMEI (which can be read using oFono), but on Netbooks, you may want to go with the CPU ID (/dev/cpu/*/cpuid). There is also gethostid(), but it relies on /etc/hostid, which is not currently generated on Meego (and any distribution I have tested). Or perhaps are you looking for an easy way to get `sudo blkid /dev/sda1` ?? I'm guessing here, but this question has been raised almost since time immemorial regarding UNIX/Linux systems by app developers who want a kind of lock-to-device (license management, as it were) scheme. Normally expected is a simple API call to get a unique identifier... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compliance spec before final approval
meego-dev-boun...@meego.com wrote: Hi, Has a new revision of the Compliance Spec been released? I cannot find anything more recent than the 1.0.80.8 from September 3. No, you're not missing anything. Real Soon Now (tm). /another Mats :) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compliance spec before final approval
meego-dev-boun...@meego.com wrote: Hi Mark, I noticed at the TSG meeting schedule on wiki that the final compliance spec will be scheduled for final approval either on oct 13 or 20 by TSG. Would it be possible to publish the intended-to-be-approved compliance spec publically either one or two weeks before final approval so there is time for possibly implicated people and companies to comment on the spec before it's approved? it will be. there should be a new draft Friday or perhaps early next week depending on receipt of some pending materials (like the infamous core package list), and hopefully that one will generate productive discussion to start finalizing things. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] RFC : should new kernel be installed in parallel on a stable release ?
meego-dev-boun...@meego.com wrote: yum has the feature that it will leave the last 3 kernels installed... (as well as the currently running one). this is very important so that you have a fail safe; you can always boot back into a known good kernel, this helps support a lot. I assumed that zypper has a similar feature to yum; if not that's a gap that we need to address urgently with feature development. the number of instances is tunable, maybe three is too many and two would be preferred in MeeGo? it actually implements a separate class of package install only of which I assume the kernel is the only current member. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Warren Baird wrote: Seems to me like the wind is blowing in the other direction, at least on this mailing list... yes it is, I didn't mean to imply otherwise. more that the architects has seem pretty set on this idea. For commercial dependencies it might make sense to include everything in one package, just to simplify pricing and distribution. But for open-source dependancies I really don't think it makes sense to disallow non-meego dependancies... Take a look at any modern linux distro. How many packages are there that depend on other 3rd party libraries and tools? It's going to make the open-source developers life a lot more complicated if they have to bundle *everything* in their package - not to mention the wasted disk space, which can be at a premium on a handset... I think if there's something used widely enough there's a space wastage issue by it not being shared then there's a case it belongs in the core after all. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
meego-dev-boun...@meego.com wrote: Em Quarta-feira 08 Setembro 2010, às 15:35:33, Wichmann, Mats D escreveu: By the way, an area I'm really looking for help on is the one on WRT (Web RunTime)... been kind of told that's going to be a part of 1.1, and the spec should say something about WRT apps so they don't look like they're prohibited, but I don't have any further info. Well, WRT apps aren't packaged as .rpms, but as a special format. They need an interpreter to be installed, just like Python and Perl, except it's based on QtWebKit. that much I had found - I guess it's a zipfile (or some other such archiving format) with a special suffix to identify it, and a few special files like a manifest that help describe the contents, and done in javascript (which webkit would handle) some people seem to think these could be dropped inside of rpms for installation but that seems kind of redundant I know the WRT team is working towards the open-sourcing and releasing so it can be in 1.1, but I don't have more info. I'll see if I can poke them into contributing for the specification. that would be great!!! is there actually time for this to make 1.1? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Warren Baird wrote: Looks like a great start... I agree with a lot of the other comments here - especially about splitting it up into two sections for apps and implementations. Lines 60-62 seem to disallow the possibility of producing apps using byte-code compiled languages like java or C# - is that intentional? No, indeed the fuzzy wording at the end is supposed to allow that: or any other supported language format. (an early reviewer objected to calling out bytecode, at least partly because the languages you mention aren't in the current required stack) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Gabriel M. Beddingfield wrote: But, if I supply extra applications/packages with my device... things that are core to my OEM product... is it OK to package them according to LSB? Obviously, all the packages in MeeGo Core have been installed using LSB. Yes, and no. For things you add on as a device builder you can choose; the idea of the FHS filesystem namespace rules (which are imported into LSB and slightly expanded there because FHS is OS-agnostic and misses some Linux conventions as a result) is the separate three roles and keep them from stepping on each other with their installs - (1) OS vendor, (2) ISV, (3) local system operator/administrator/owner, whichever term fits. As a device builder you're perhaps some of (1) and (2) both, and you can make sure to avoid conflicts. On the other hand, there's no particular /need/ for the core or profile pieces to follow the addon paths, because they are firmly in category (1). Operating system standard locations: If I'm writing an app that, for instance, lists all the applications installed (*.desktop)... where do I go to find these? According to this, I would need to `find /opt -name *.desktop`, and there's no mention of /usr/share/applications or an LSB spec. What I'm getting at (to be a little more clear) is that when an application NEEDS something from the OS, this spec doesn't provide any information about where to go. Right now, reference to LSB is limited to application binary format (ELF).[1] It might be good to appeal to more of the LSB Core[2] and even LSB Desktop.[3] some of that will perhaps happen but LSB, which itself refers to several other docs, is a smaller set than MeeGo Core and too many levels of reference means nobody will bother to follow the references - I'm working on the idea that this spec ought to be a relatively complete description of what people need. Without becoming a 1000-page doc, that is! :) All that subject to adjustment as things evolve, I guess. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Damien Lespiau wrote: On Fri, 2010-09-03 at 23:59 +0100, Wichmann, Mats D wrote: There's a rough early version available on http://wiki.meego.com/Quality/Compliance So I'm proposing we just follow up to this thread - edits, questions, comments, etc. A general comment is the lack of reference to the relevant freedesktop specifications both on the application side (ie Making a MeeGo compliant application) and on the device side (ie Making a MeeGo compliant device). I understand that the focus has naturally been on the lower parts of the platform though. Whether MeeGo should comply with fdo specs seems to still be TBD but given that we actually provide and use quite a lot of the pieces (if not all), I would really expect to have this written in the compliance document. That would be useful to sort out. A reference to FDO (at least four of the specs) is easy enough to add if it's wanted. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
- 106-109: System implementers MUST use the source code of the MeeGo 1.1 Reference Implementation and SHALL NOT replace or omit Core or Profile components. There are cases where a vendor might want to substitute equivalent (read: identical API ABI) components to take advantage of specific platform features. Some examples of this might be codecs that run on a DSP, hardware-accelerated SSL engines and so on. The substitute's licence should also match the reference implementation's to avoid unintentional issues with run-time linkage etc, but otherwise I think this should be allowed. On a limited basis; there's a reason why people have asked for use the reference source, because otherwise you have to get into detailed behavioral descriptions and tests to be sure you haven't broken the ABI by replacing pieces. There's a flag in the draft about this - codecs might not be an applicable example, but specialized opengl libraries that go with a specific hardware/driver combination could be. I'm really uncomfortable with that as there's been more than one instance out in the wild of replaced gl drivers causing problems, missing interfaces, etc. - but I'm assuming that's a reality. I hope the replacement list will be small and possibly ought to be bounded in some way so that people don't end up surprised. - 3.4 Interpreted languages IMHO the location of the site/vendor trees should also be standardised here. Makes packaging extra modules unambiguous, plus similar considerations as above. Sounds like a sensible suggestion. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
meego-dev-boun...@meego.com wrote: Hi, Application shall be installed to /opt/packagename/ and /var/opt/packagename/ directories. System wide configuration files shall be stored in /etc/opt/packagename directory. User specific files shall be stored in ~/.config/packagename directory. It's following FHS 2.2. Could we use FHS 2.3 recommendation instead (/opt/provider/package)? The structure of the directories below /opt/provider is left up to the packager of the software, though it is recommended that packages are installed in /opt/provider/package and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/provider/lib or /opt/provider/bin. Sounds fine to me, unless other people think this is an extra complexity that isn't wanted. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
meego-dev-boun...@meego.com wrote: Arjan wrote: On 9/6/2010 4:00 PM, Lucas Maneos wrote: - 70-71: It shall use only external commands and other facilities described in this specification, whether for installation tasks or run-time tasks. It should be allowed to use commands / facilities provided by third-party packages it explicitly depends on. I think that's the intent anyway based on other parts of the document. 3rd party apps must only depend on the core components or on things that are included with the app. not other (4th party?) things. Can you clarify the scope of this must not. It'd be very limiting if we can't build on each others work, especially in the community repo - but also in the sanctioned commercial services. Clearly this is a key point for the number of times it's come up. Someone else said there are simply two different models: the repository-based model where the installer resolves certain dependencies (and it's easy enough to SAY something like may only depend on components of MeeGo core, or from MeeGo compliant packages); and one where an app may have no dependencies at all, basically depend on MeeGo is it, everything else is self contained. It seems like the wind is blowing in the direction of the latter, for all that it's easy to envision very useful uses for the former. It went in the spec that way based on what people who worked on this were told; hoping the discussion will make it clear what the spec actually needs to forbid/allow in this area. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
tatu.manni...@nokia.com wrote: I think there should something stated about the instruction set and compiler targets used, at least on ARM side. Simply stating ARMv7 is not enough as the architecture leaves too much as optional (like VFP, NEON) and details like instruction timings etc may differ greatly between different implementations of the architecture. Also architecture licensees of the ARMv7 may more or less implement whatever they feel like on top of the architecture. Sure you can build compliant binaries using only ARMv7 but they will not be optimal at all in real life. I know less about the ARM side of the story than many other ABI targets, except that there seem to be a nearly infinite number of variations; however as a general statement any bits on architecture now are only placeholders until content is written/supplied/magically appears. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Some really useful comments here already, I'll respond in more detail later. Gabriel M. Beddingfield wrote: General: This specification seems to be a mash-up of what is a MeeGo-complient DEVICE, and what is a MeeGo-compliant APPLICATION/package. If this is the case, it would be worthwhile to clearly distinguish these. Maybe even divide them out. Yes, there are definitely two distinct audiences. They don't completely divide out since in the end the API/ABI set is the same, the device acting as the producer and the app as the consumer. But I bet we can do better at keeping things clear when there is a logical distinction. There are also two somewhat distinct environments being discussed, there's the run-time environment and there's the installation-time environment and it's worth making more clear there's a separation here as well. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Meego spec - for comment
There's a rough early version available on http://wiki.meego.com/Quality/Compliance We'd like to ask for feeback on this at various levels, the most important being the highest level: does it get anywhere close to describing an implementation of the basic principles, as presented most recently at the TSC meeting: http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-08-18-18.58.html (follow to full logs to see the discussion) and mainly the reference: http://wiki.meego.com/Technical_Steering_Group_meetings/Compliance_Update_8-18-10 Probably it's not worth worrying about small items (spelling, grammar) at the moment as there are likely to be large changes which could make those disappear as a side effect. For the moment this is too rudimentary for it to make a lot of sense to tie it in to bugzilla entries, but we'll add a category there later as the document matures. So I'm proposing we just follow up to this thread - edits, questions, comments, etc. Thanks, -- mats ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Does MeeGo need OpenGL/ES or OpenVG Hardware?
meego-dev-boun...@meego.com wrote: On Fri, Aug 20, 2010 at 11:56 AM, Arjan van de Ven ar...@linux.intel.com wrote: On 8/20/2010 8:51 AM, Tobias Renz wrote: Thanks already for your answers! The targeted device is like a measurement device. So It's not too important to have MeeGo compliance as a label. Also we would have an overview of all third party apps that we would let the customer install or offer to him. I guess that also 3rd party apps that would run with OpenGL in mind would just run damn slow. But then we would just avoid such apps for our customers. at some point you need to ask yourself... am I still really using meego. Is there a possibility for MeeGo adapting compliance for a different class/tier of vertical markets? Or is this a path that just shouldn't be bothered with for those of us wanting to use it (in a branded way, and working with the project to define compatibility) on platforms that the originators aren't interested in? It's theoretically possible, based on the claim: Compliance is profile based where a profile specifies a device category. Profiles are approved by the MeeGo TSG. I guess it would mean convincing the Steering Group of the value... (seems like this twist of the topic is more appropriate moved to another location per Dawn's request the other day) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Does MeeGo need OpenGL/ES or OpenVG Hardware?
Matt Porter wrote: On Fri, Aug 20, 2010 at 12:46 PM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: meego-dev-boun...@meego.com wrote: Is there a possibility for MeeGo adapting compliance for a different class/tier of vertical markets? Or is this a path that just shouldn't be bothered with for those of us wanting to use it (in a branded way, and working with the project to define compatibility) on platforms that the originators aren't interested in? It's theoretically possible, based on the claim: Compliance is profile based where a profile specifies a device category. Profiles are approved by the MeeGo TSG. I guess it would mean convincing the Steering Group of the value... (seems like this twist of the topic is more appropriate moved to another location per Dawn's request the other day) Ok, she also requested at the last TSG meeting to post followup compliance questions to meego-dev. I'll move to -community as the catch all. missed that bit, in that case maybe this was the right place? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Building the Meego Dev Environment
meego-dev-boun...@meego.com wrote: On Tue, Apr 06, 2010 at 08:28:48AM -0700, ezjd wrote: I am wondering why we stay with glibc for MeeGo. Because it works and is supported. Debian/Ubuntu has moved to eglibc and even WindRiver Linux (now part of Intel) uses eglibc too. The major reason is that eglibc makes life easier for architecture other than x86 like ARM. Are you sure that eglibc is really needed for arm? Look at the released glibc package to see if something you require is missing for arm and if so, please file a bug. Not being a Debian guy, I never quite understood the motivation for eglibc... is it that the glibc ARM stuff is off in ports and so doesn't look mainline? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-community] Proposal: A vendor social contract
meego-dev-boun...@meego.com wrote: For this reason a social contract could help us, establishing a default requirements if you want to integrate a component/driver in the MeeGo project. Maybe the social contract sounds very free-software fanatic for a company, but is one of the best warranties to offer a complete open source project. Besides, it would be a signal of commitment with the community, and it will encourage participation in the development. My completely personal, completely unofficial reaction is that this would have a LOT of problems on the Tivoization front, as it seems to me everybody below the netbook and possible tablet type device is interested in some level of locking down their image... Don't know if it looks that way to the rest of you or I'm just being too pessimistic? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-community] First MeeGo Repository Working Group Meeting
Lintian is debian's policy checker. It checks that a given package adheres to the debian policy. That is to say; does the package ship UTF-8 files, man pages, is the control file correct, etc. This tool checks large parts of debian policy and fairly thoroughly takes apart a package. It does more than just a lint check, which is often just related to programming language specific files, i.e. check C files for errors. Is there something like this in the RPM world? If not, will there be hooks available to do system and functional tests? well, there's always rpmlint. it's not as explicit about policy checks but it does indeed perform them, and is configurable. I don't know how much tuning has been done for the former-Moblin environment. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Adobe Flash 10.1 on Meego
Katrina Niolet wrote: Keep in mind that flash is not used only for pointless youtube videos and bad programming, there are sites like hulu.com which rely on flash because there is no widely available alternative currently for delivering the kind of media experience they want to give. While long term some of the features of HTML5 are designed to fix these problems, it's still way off and content providers won't be shifting overnight either. Users may incorrectly blame the device manufacturer for their memory filling up or slow connections but they would not be incorrect to blame a manufacturer who sells devices they can't access their favorite websites on simply because of political reasons. Yes, I keep forgetting about hulu, which is a mistake on my part (because it's inaccessible to me: I'm total-data limited on my connection so something like that is way too expensive). It's political no matter what you do, but I think there's one thing we can take as a concrete suggestion: we ought to encourage whatever implementations do exist to be location aware, or more precisely connection-aware. A settings box could be fine, e.g. I could tick a box that says don't auto-play video content if I'm on my phone network, but go ahead if I'm on wifi - that sort of thing. And of course if I'm on a settop box and it's directly connected to a nice fat pipe, maybe I don't even worry about asking. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
