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] updated MeeGo compliance spec available for review
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. -- Antti Kaijanmäki Software Architect Team Manager m. +358 41 440 4187 linkedin.com/in/anttikaijanmaki www.nomovok.com Nomovok Ltd. Keilasatama 3 FI-02150 Espoo Finland ___ 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
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 :) -- Antti ___ 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
-Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Wichmann, Mats D Sent: Friday, February 04, 2011 12:44 PM To: meego-dev@meego.com Subject: [MeeGo-dev] updated MeeGo compliance spec available for review ... 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. 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. Thanks, Gabriel ___ 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] updated MeeGo compliance spec available for review
On Mon, 2011-02-07 at 08:28 -0600, Gabriel M. Beddingfield wrote:
On Mon, 7 Feb 2011, Miretti, Gabriel wrote:
Hi, I just begin to work with Meego and particularly with Meego Compliance.
In 3.2.2, the specification says:
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.
Suppose that your app needs 3rd party libs and you install
them in the folder /opt/foo/lib. Before you start your app,
you can manipulate the LD_LIBRARY_PATH to pull in your lib
folder.
### BEGIN STARTUP SCRIPT ###
#!/bin/sh
LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
export LD_LIBRARY_PATH
exec /opt/foo/foo.bin $@
### END ###
So imagine the case of openssl, you provide it as it is not Meego Core,
it's linked to a specific version. Meego provides a different one, you
an't link to it in theory as it is not a core lib. In this example you
then bring in Qt to your application which does a dlopen on it's
openssl. This basically crashes your app.
My point being, some libs just probably shouldn't be allowed even in an
LD_LIBRARY_PATH.
___
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
On 2/7/2011 4:41 AM, 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. well yes... it applies to both there is just no requirement that the components that you ship on a device must all be compliant. ___ 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
On Mon, 7 Feb 2011, Sergio Schvezov wrote: Suppose that your app needs 3rd party libs and you install them in the folder /opt/foo/lib. Before you start your app, you can manipulate the LD_LIBRARY_PATH to pull in your lib folder. [snip] So imagine the case of openssl, you provide it as it is not Meego Core, it's linked to a specific version. Meego provides a different one, you an't link to it in theory as it is not a core lib. In this example you then bring in Qt to your application which does a dlopen on it's openssl. This basically crashes your app. What a mess! I hadn't thought of that. My point being, some libs just probably shouldn't be allowed even in an LD_LIBRARY_PATH. I.e. We refuse to supply openssl as part of MeeGo core, but you can't use openssl as your own private library because QtNetwork is covertly loading it with dlopen(). That's nuts. Would it be more sane to prohibit libs in MeeGo core from using dlopen()? -gabriel ___ 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
On 2/7/2011 9:03 AM, Gabriel M. Beddingfield wrote: On Mon, 7 Feb 2011, Sergio Schvezov wrote: Suppose that your app needs 3rd party libs and you install them in the folder /opt/foo/lib. Before you start your app, you can manipulate the LD_LIBRARY_PATH to pull in your lib folder. [snip] So imagine the case of openssl, you provide it as it is not Meego Core, it's linked to a specific version. Meego provides a different one, you an't link to it in theory as it is not a core lib. In this example you then bring in Qt to your application which does a dlopen on it's openssl. This basically crashes your app. What a mess! I hadn't thought of that. My point being, some libs just probably shouldn't be allowed even in an LD_LIBRARY_PATH. I.e. We refuse to supply openssl as part of MeeGo core, but you can't use openssl as your own private library because QtNetwork is covertly loading it with dlopen(). That's nuts. I'm pretty sure openssl is part of the actual compliance package list (which is core + dependencies, not just core') ___ 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
On Mon, 7 Feb 2011, Arjan van de Ven wrote: I.e. We refuse to supply openssl as part of MeeGo core, but you can't use openssl as your own private library because QtNetwork is covertly loading it with dlopen(). That's nuts. I'm pretty sure openssl is part of the actual compliance package list (which is core + dependencies, not just core') Good call. It is. So how about this approach: Compliant apps must not provide any private libs that are also in Core or the Core Dependencies. If you must use a private version of these libraries, then you shall either statically link to them or downgrade to Platform API Compliance. -gabriel ___ 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
On Mon, 2011-02-07 at 11:43 -0600, Gabriel M. Beddingfield wrote: On Mon, 7 Feb 2011, Arjan van de Ven wrote: I.e. We refuse to supply openssl as part of MeeGo core, but you can't use openssl as your own private library because QtNetwork is covertly loading it with dlopen(). That's nuts. I'm pretty sure openssl is part of the actual compliance package list (which is core + dependencies, not just core') Good call. It is. So how about this approach: Compliant apps must not provide any private libs that are also in Core or the Core Dependencies. If you must use a private version of these libraries, then you shall either statically link to them or downgrade to Platform API Compliance. +1 The whole situation where application would include it's own version of a Core library sounds pretty fishy, but anyway; there's always the option to provide the libraries statically linked and keep this all nicely under /opt/package/ Indeed the whole point to target some platform is to adapt the code for that platform as far as possible, even downgrading to older APIs. And if that's not an option for some reason, just go all static. -- Antti Kaijanmäki Software Architect Team Manager m. +358 41 440 4187 linkedin.com/in/anttikaijanmaki www.nomovok.com Nomovok Ltd. Keilasatama 3 FI-02150 Espoo Finland ___ 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
On 2/7/2011 10:0st core') If you compile your app against libssl in Meego 1.1 it will link against libssl.so.8, when you go to Meego 1.1.90-1.2 your app won't load as libssl.so.10 is there. If you symlink it may work, but you can never know as that's why the version changed in the first place. Same applies for libcrypto. if we break ABI between 1.1 and 1.2 we, MeeGo, fscked up and must provide a compatibility package. doesn't matter if this was only a dependency or not. ___ 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
On Fri, 04 Feb 2011 21:21:04 +0200 Antti Kaijanmäki antti.kaijanm...@nomovok.com wrote: On Fri, 2011-02-04 at 11:57 -0700, Wichmann, Mats D wrote: Antti Kaijanmäki wrote: ... last someone talked about kernels, there was a plan to list manadatory parts of the kernel config in the next spec (1.2), although not in this one. is that good enough? I think IPv6 is mandatory for any product that comes out these days. Even more importantly now that the IPv4 address pool has finally been completely depleted. So yes I think MeeGo 1.1 compliance spec should mention at least even vaguely that IPv6 is required if you don't want to specify any mandatory kernel configuration at this time. On the other hand if you think nobody is going to release MeeGo 1.1 product then this can wait to 1.2 ;) Kernels have supported IPv6 for years, unless they are specifically configured not to. It would be nice if key core applications would also support it. :Like ConnMan for example. Currently the ConnMan applet blissfully ignores IPv6 even if you are connected: https://bugs.meego.com/show_bug.cgi?id=10878 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] updated MeeGo compliance spec available for review
On Fri, 2011-02-04 at 14:32 -0500, Bernd Stramm wrote: On Fri, 04 Feb 2011 21:21:04 +0200 Kernels have supported IPv6 for years, unless they are specifically configured not to. Yes, but sadly there are products where kernels are specifically configured not to have IPv6. By stating it's mandatory we can prevent that happening on MeeGo. It would be nice if key core applications would also support it. :Like ConnMan for example. Currently the ConnMan applet blissfully ignores IPv6 even if you are connected: https://bugs.meego.com/show_bug.cgi?id=10878 IMO any component which does not support IPv6 fully must have bugs opened against them with High priority. -- Antti ___ 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
On Friday, 4 de February de 2011 21:21:04 Antti Kaijanmäki wrote: I think IPv6 is mandatory for any product that comes out these days. Even more importantly now that the IPv4 address pool has finally been completely depleted. So yes I think MeeGo 1.1 compliance spec should mention at least even vaguely that IPv6 is required if you don't want to specify any mandatory kernel configuration at this time. Huh... just to correct a little your information: the IPv4 address pool has not been depleted. The IANA has exhausted its pool. But the 5 registries still have some more IPs left, with the APNIC and RIPE NCC expected to exhaust theirs still in 2011, ARIN in 2012 and the LACNIC between 2012 and 2014. However, that is not to dissuade from the urgency. IPv6 support should have been required for any and all devices shipped since 2007, at least. -- Thiago acieira - 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 pgpKmOwTf1tec.pgp 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] updated MeeGo compliance spec available for review
On 2/4/2011 12:10 PM, Antti Kaijanmäki wrote: On Fri, 2011-02-04 at 14:32 -0500, Bernd Stramm wrote: On Fri, 04 Feb 2011 21:21:04 +0200 Kernels have supported IPv6 for years, unless they are specifically configured not to. Yes, but sadly there are products where kernels are specifically configured not to have IPv6. By stating it's mandatory we can prevent that happening on MeeGo. It would be nice if key core applications would also support it. :Like ConnMan for example. Currently the ConnMan applet blissfully ignores IPv6 even if you are connected: https://bugs.meego.com/show_bug.cgi?id=10878 IMO any component which does not support IPv6 fully must have bugs opened against them with High priority. 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) ___ 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
On Feb 4, 2011, at 11:32 AM, Bernd Stramm wrote: On Fri, 04 Feb 2011 21:21:04 +0200 Antti Kaijanmäki antti.kaijanm...@nomovok.com wrote: On Fri, 2011-02-04 at 11:57 -0700, Wichmann, Mats D wrote: Antti Kaijanmäki wrote: ... last someone talked about kernels, there was a plan to list manadatory parts of the kernel config in the next spec (1.2), although not in this one. is that good enough? I think IPv6 is mandatory for any product that comes out these days. Even more importantly now that the IPv4 address pool has finally been completely depleted. So yes I think MeeGo 1.1 compliance spec should mention at least even vaguely that IPv6 is required if you don't want to specify any mandatory kernel configuration at this time. On the other hand if you think nobody is going to release MeeGo 1.1 product then this can wait to 1.2 ;) Kernels have supported IPv6 for years, unless they are specifically configured not to. It would be nice if key core applications would also support it. :Like ConnMan for example. Currently the ConnMan applet blissfully ignores IPv6 even if you are connected: https://bugs.meego.com/show_bug.cgi?id=10878 ConnMan actually supports ipv6 now, and they are working to make the implementation better. As you said, the applet on the MeeGo netbook unfortunately doesn't give people the options needed for ipv6. So, this is more of a user interface issue, rather than a core application deficiency. This doesn't reduce the need to get it fixed, but it should be relatively easy to add support in the interface for ipv6, since it is already supported in ConnMan. Dawn ___ 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
On Fri, 4 Feb 2011 15:26:39 -0800 Foster, Dawn M dawn.m.fos...@intel.com wrote: On Feb 4, 2011, at 11:32 AM, Bernd Stramm wrote: On Fri, 04 Feb 2011 21:21:04 +0200 Antti Kaijanmäki antti.kaijanm...@nomovok.com wrote: On Fri, 2011-02-04 at 11:57 -0700, Wichmann, Mats D wrote: Antti Kaijanmäki wrote: ... last someone talked about kernels, there was a plan to list manadatory parts of the kernel config in the next spec (1.2), although not in this one. is that good enough? I think IPv6 is mandatory for any product that comes out these days. Even more importantly now that the IPv4 address pool has finally been completely depleted. So yes I think MeeGo 1.1 compliance spec should mention at least even vaguely that IPv6 is required if you don't want to specify any mandatory kernel configuration at this time. On the other hand if you think nobody is going to release MeeGo 1.1 product then this can wait to 1.2 ;) Kernels have supported IPv6 for years, unless they are specifically configured not to. It would be nice if key core applications would also support it. :Like ConnMan for example. Currently the ConnMan applet blissfully ignores IPv6 even if you are connected: https://bugs.meego.com/show_bug.cgi?id=10878 ConnMan actually supports ipv6 now, and they are working to make the implementation better. As you said, the applet on the MeeGo netbook unfortunately doesn't give people the options needed for ipv6. So, this is more of a user interface issue, rather than a core application deficiency. Yes that is correct, ipv6 does work. Packets are sent and received, ip6tables does what it is supposed to and all that. I don't know if ConnMan has anything to do with that. The problem in the applet is a bug though, not a deficiency. Users cannot detect the state of their ipv6 connection if they try. So they can for example be connected, not have a firewall, and not know anything about it. That's a bug. This doesn't reduce the need to get it fixed, but it should be relatively easy to add support in the interface for ipv6, since it is already supported in ConnMan. Dawn -- Bernd Stramm bernd.str...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
