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
On Fri, 2011-02-04 at 08:43 -0700, Wichmann, Mats D wrote:
> After a bunch of review there's an updated copy of
> the 1.1 spec available... sorry this isn't diffmarked,
> there was quite a bit of rearranging of pieces to make
> flow better (thanks to Mikko Ylinen for most of this,
> and for a lot
On Mon, 2011-02-07 at 11:36 -0700, Wichmann, Mats D wrote:
> meego-dev-boun...@meego.com wrote:
>
> >> if we break ABI between 1.1 and 1.2 we, MeeGo, fscked up and must
> >> provide a compatibility package.
So this is real today, if packages marked as dep should also stay stable
something must
"ext Gabriel M. Beddingfield" writes:
> Would it be more sane to prohibit libs in MeeGo core from using
> dlopen()?
Uhh, that would be a bit much. But maybe we can make the rule that you
can not use RTLD_GLOBAL with anything that is not directly in /lib and
/usr/lib.
___
meego-dev-boun...@meego.com wrote:
>> if we break ABI between 1.1 and 1.2 we, MeeGo, fscked up and must
>> provide a compatibility package.
>
> libssl is Platform API, so there are no ABI promises made
> (sect 3.2.1). (However, the spec used to promise ABI
> compatability within a 1.x release.)
On Mon, 7 Feb 2011, Arjan van de Ven wrote:
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
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 pla
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(
On Mon, 2011-02-07 at 09:16 -0800, Arjan van de Ven wrote:
> 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,
>
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
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]
S
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 i
On Fri, 2011-02-04 at 12:39 -0800, Arjan van de Ven wrote:
> On 2/4/2011 12:10 PM, Antti Kaijanmäki wrote:
> > 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.
> (bu
> 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
> ope
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 Compatibil
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/mandator
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:
"They shall import external interfaces only from the
following sources:
* shared libraries supplied as a part of the application
package"
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"
>-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
>
>
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
On Mon, 2011-02-07 at 05:53 -0700, Wichmann, Mats D wrote:
> 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?
In the empty space be
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
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 Compatibili
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 abou
On Feb 4, 2011, at 3:33 PM, Bernd Stramm wrote:
> On Fri, 4 Feb 2011 15:26:39 -0800
> "Foster, Dawn M" wrote:
>
>>
>> On Feb 4, 2011, at 11:32 AM, Bernd Stramm wrote:
>>
>>> On Fri, 04 Feb 2011 21:21:04 +0200
>>> Antti Kaijanmäki wrote:
>>>
On Fri, 2011-02-04 at 11:57 -0700, Wichmann,
On Fri, 4 Feb 2011 15:26:39 -0800
"Foster, Dawn M" wrote:
>
> On Feb 4, 2011, at 11:32 AM, Bernd Stramm wrote:
>
> > On Fri, 04 Feb 2011 21:21:04 +0200
> > Antti Kaijanmäki wrote:
> >
> >> On Fri, 2011-02-04 at 11:57 -0700, Wichmann, Mats D wrote:
> >>> Antti Kaijanmäki wrote:
> >>> ...
> >>>
On Feb 4, 2011, at 11:32 AM, Bernd Stramm wrote:
> On Fri, 04 Feb 2011 21:21:04 +0200
> Antti Kaijanmäki 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 part
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
configu
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
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 manda
On Fri, 04 Feb 2011 21:21:04 +0200
Antti Kaijanmäki 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
On Fri, 2011-02-04 at 11:57 -0700, Wichmann, Mats D wrote:
> Antti Kaijanmäki wrote:
> > This would at least
> > require that kernels are compiled with IPv6 support enabled.
>
> last someone talked about kernels, there was a plan to list
> manadatory parts of the kernel config in the next spec (1.
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...
>
> How about IPv6 support?
>
> It's clear that any sane device has to support IPv6 now that the IPv4
> address pool has been completely de
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...
How about IPv6 support?
It's clear that any sane device has to support IPv6 now that the IPv4
address pool has been completely depleted[0]. It has been known fact for
After a bunch of review there's an updated copy of
the 1.1 spec available... sorry this isn't diffmarked,
there was quite a bit of rearranging of pieces to make
flow better (thanks to Mikko Ylinen for most of this,
and for a lot of useful comments/changes), and an
unfortunate side effect is that
35 matches
Mail list logo
