Re: [MeeGo-dev] Who will keep pushing MeeGo?

[Wichmann, Mats D]

On Fri, Sep 30, 2011 at 12:08 PM, Tethys .  wrote:

> On Fri, Sep 30, 2011 at 6:59 PM,   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

[Wichmann, Mats D]

On Tue, Aug 16, 2011 at 2:48 PM, Bogdan Cristea  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

[Wichmann, Mats D]

On Tue, Aug 9, 2011 at 12:15 PM, Steve McIntyre
wrote:

>  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] how to get a meego-sdk for ubuntu 1104?

[Wichmann, Mats D]

On Tue, Aug 2, 2011 at 8:37 PM, pingwei...@cs2c.com.cn <
pingwei...@cs2c.com.cn> wrote:

> hi,
>all, my work computer's os is ubuntu1104, how can I get the proper
> meego-sdk for it or how to make a sdk by myself? I need to using it to
> build packages.



this should be possible now. See
http://wiki.meego.com/SDK/1.2/Installer_Status
___
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

[Wichmann, Mats D]

On Fri, Jul 29, 2011 at 11:46 AM, Ware, Ryan R wrote:

> On 7/28/11 10:04 PM, "Timo Härkönen"  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:
> >
> >
> >
> >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 ?

[Wichmann, Mats D]

On Sat, Jul 16, 2011 at 8:56 AM, David Boosalis wrote:

> 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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

On Mon, Jun 20, 2011 at 10:40 AM, Sergio Schvezov wrote:

> 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?

[Wichmann, Mats D]

On Sat, Jun 18, 2011 at 6:55 AM, Andrey Ponomarenko
wrote:

> **
> 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 app model in 2012: Rethinking the MeeGo app model to be more platform agnostic

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> On 5/31/2011 9:40 AM, Tomasz Sterna wrote:

>> You are missing the original question: "How to give developpers a way
>> to create one-size-fits-all package?"

switch to html5 :)

___
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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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] 1.1 and 1.2 Compliance

[Wichmann, Mats D]

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
>>   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] [Meego-architecture] MeeGo Compliance, specifically IVI

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:

> So compliance gets defined, then one might say it gets "validated" by
> being made concrete in the package "patterns?" This seems to present a
> logical process that one can follow.

to be clear, it's really the other way around: the compliance spec
aims to codify existing practice, not lead it; so the package patterns
come first and the spec essentially inherits from that.

___
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

[Wichmann, Mats D]

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] [Meego-architecture] MeeGo Compliance, specifically IVI

[Wichmann, Mats D]

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] 1.1 and 1.2 Compliance

[Wichmann, Mats D]

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] 1.1 and 1.2 Compliance

[Wichmann, Mats D]

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] MeeGo compliance and Qt Commercial license

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:

> I'm a bit confused, so MeeGo compliant OS can only be compliant if it
> uses the exact packages from MeeGo? So it is not about the API's but
> about the exact packages? 

if you look at the rules has having two sides - the requirement on
the system to provide an API set, and the requirement on the app
to consume (only) that API set, then using exact bits is part of
the way consistency is ensured on the system side, while from the
app view it's "about the APIs".  the full API set is a long way from
having behavioral specification and test to the level that you can
be fully confident of binary compatibility (some people argue 
passionately it's something you can never prove, but that's perhaps
a different question), so "use the meego source" is the position taken. 

> Just a theoretical questions, if one would get packages from
> fedora/opensuse or any other distribution and create an image
> that would pass the MeeGo Compliance tools test set would that
> image be compliant? 

under current rules, no.  the tests will look for versions,
and if they match, the tools are not any the wiser, but the
rule still wants you to use the meego bits.

___
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?

[Wichmann, Mats D]

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

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> 2011/3/30 Leonardo Luiz Padovani da Mata :
>> On Wed, Mar 30, 2011 at 12:03 PM, Pei Lin
>  wrote:
>>> 2011/3/30 Thiago Macieira :
 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] Freedesktop.org specifications and compliance

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> On 02/08/11 06:11, Ville M. Vainio 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
>> 
> 
> Uxlaunch is the component I maintain for handling autostart, and I've
> attempted to get as close as possible to the spec you list above.
> 
> If you have specific concerns about uxlaunch not honoring parts of the
> standard, go ahead and file a bugzilla against uxlaunch and we
> can work to resolve the issue.

there is also now a [MeeGo Spec and Compliance] product to file
against in bugzilla if the specification ought to say something 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] how to play a video is h.264 in meego-handset-video player

[Wichmann, Mats D]

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 
mailto:cars...@maemo.org>> wrote:
2011/2/17 ssuk hyun kim mailto: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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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.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] Fail to run the Phoronix "qgears2" test suit for 3D benchmark.

[Wichmann, Mats D]

From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of maceo_y...@acer.com.tw
Sent: Monday, February 14, 2011 8:14 PM
To: meego-dev@meego.com
Subject: [MeeGo-dev] Fail to run the Phoronix "qgears2" test suit for 3D 
benchmark.


Hi There
I've been try to run part of the PTS(Phoronix Test Suit) tests for system 
benchmark of my Meego device.
I manually zypper installed some packages(php-cli, libX11-devel, 
libXrender-devel, libqtopengl-develand its dependencies ) in order to make 
qgears2 to run correctly.
(Attached file record the manual installed packages in order to run the PTS 
test.)

I met a fatal error as below and return right away without a result comes out 
when I runs the qgears2 sub-item OpenGL->Gears.

"PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 192771641 bytes) in 
/usr/share/phoronix-test-suite/pts-core/library/pts-includes-run.php on line 
624"

I did check the free memory and storage left after error return, I think they 
are all enough for the test at the moment.
Do I have to run-time check it ?
the message in red is php's limit, you can up the size in /etc/php.ini, look 
for memory_limit


___
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

[Wichmann, Mats D]

 
> 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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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.)

if you get an app built and checked as compliant, the binary
better stay working, as Arjan says.  The spec still contains
a bit on this:


1.4.3 Forward and Backward Compatibility
Forward compatibility for compliant binaries (ABI) is promised for future 
versions of MeeGo with the same major version number.


The Platform API thing is more a source-level consideration:
interfaces may vanish, move into Qt, etc. so you can't
/build/ against them in future versions.  But the ABI
has to stay working over versions.  How would we handle
devices upgrading to a new release otherwise?  "All your
apps are broken, check back when vendors have had a chance
to build new versions?"  We'd look pretty bad in comparison
to a couple of well-known systems currently on the market...



___
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

[Wichmann, Mats D]

 

> 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.

 
The whole openssl situation is horribly broken and it's openssl that 
ought not to be allowed (indeed this is probably why it's not in core)

but yes, we need to develop knowledge about things that are going
to cause problems.


___
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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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 depleted[0]. It has been
> known fact for
> few years that the depletion will happen "soon", but still we have
> relatively new products that do not support IPv6[1].
> 
> We can at least make sure that no vendor will release MeeGo
> device which
> can't handle the Internet we live in today. 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.2),
although not in this one.

is that good enough?
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] updated MeeGo compliance spec available for review

[Wichmann, Mats D]

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 diff-marking tools
make it look like an incredibly massive change when
it really wasn't; if left diffmarked it would just have
been a whole lot harder to read ("why did they remove
this"?  ... a few minutes later, "oh, I see, this looks
like the bit that dropped out earlier that I wondered
about, looks like it just moved")

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.

thanks,

-- mats
___
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?

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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?

[Wichmann, Mats D]

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] Is MeeGo a Google product?

[Wichmann, Mats D]

>> Is this the image we want to project?
>> 
> 
> There's no "bad image" projected by MeeGo here.  There will
> always be people who, for whatever reason, can't or don't
> comprehend what's in front of them.  In my estimation the
> MeeGo project has made very clear what it is and isn't, and
> the message is being refined as needed.
> 
> In this case, I could see room for some improvement. instead
> of just "(Google Chrome Browser)", maybe the link should say
> "(includes Google Chrome Browser)" to make the situation a bit
> clearer. 

Yes, the way that one works out ends up appearing a little unbalanced
in favor of one specific component.

This wording isn't snappy enough to be usable, but this is what
we really mean:

1.  unsrestricted image
2.  image with more functionality, requires one-time acceptance of one or more 
EULAs

Maybe someone's smart enough to figure a way to express that
in a better way...

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] MeeGo migration path?

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

Re: [MeeGo-dev] Comments to MeeGo 1.1 Compliance Specification (v. 1.0.99.4)

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> Hi,
> 
> I went through the MeeGo 1.1 Compliance Specification
> (v. 1.0.99.4) with people from Nokia MeeGo team.

Thanks, some good comments there.

There's just now a new version which doesn't take
into account these comments, but possibly the changes
mitigate a couple of the concerns a bit.


A lot of the "unknown" items are that way... because
they are unknown.  That is, nobody's come up with a 
versioning scheme, so it's unspecified.  I haven't heard 
the ABI issues around hardftp/softfp really have a good
answer across versions, so the spec only captures the
current state.  If there's something we can say that
captures a future direction /that we know for sure/
we could look at that.

The "versioning policy" is a good point, there may be
some architectural decisions that have looked at that
but I haven't heard it.  What would make us flip from
1.x to 2.0?  I'm sensitive to this because I've spent
years on a project (LSB) that has had some real issues
with this, for example a "Deprecation Policy" that
says you must keep a deprecated feature for two major
releases but then not defined a major-version cadence
or policy (i.e. 3.0->3.1 was a huge transition that 
shoul have been a major version bump; 3.2->4.0 was
rather a much smaller change)

___
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

[Wichmann, Mats D]

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] compliance spec questions

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> My apologies if this is not the best mailing list on which to ask:
> 
> 1. Would the Compliance spec prevent the problems that MS has caused
> with the encrypted SD card in Windows Phone 7?
> 
> Reference:
> http://www.engadget.com/2010/11/17/windows-phone-7s-microsd-mess-the-full-story-and-how-nokia-ca/

I haven't heard anything mentioned about this - there are at the
moment neither timing requirements nor comments on expandability.

> 2. Would the Compliance spec prevent vendors from putting system files
> in non-standard locations?  

As currently written, the prohibition on "repackaging" the reference
sources would effectively prevent this.  

> It can be a major annoyance for
> application developers if (for example)  /etc/resolv.conf gets stuffed
> in /etc/someuseulessgarbage/resolv.conf instead.   Vendors should be
> able to put their own config files wherever they want, although an
> ideal spec might want to suggest the usual places even there.

Application vendors shouldn't be mucking with /etc/resolv.conf,
especially not on MeeGo (yes, I know you said it was just an example).

If there's something that's particularly important to be in a
specific place that *does* have app impacts, there's no problem
with calling it out, as a practical matter it's more likely to
get tested for explicitly in the system tests if it's called out.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] "MeeGo" vs. "Platform" API ambiguity

[Wichmann, Mats D]

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

Re: [MeeGo-dev] "MeeGo" vs. "Platform" API ambiguity

[Wichmann, Mats D]

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] New version of compliance specification

[Wichmann, Mats D]

>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

[MeeGo-dev] New version of compliance specification

[Wichmann, Mats D]

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] Compliance spec updated 1.0.99.2

[Wichmann, Mats D]

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

Re: [MeeGo-dev] [Meego-architecture] MeeGo compliance questions (Platform API definition, and X11 presence)

[Wichmann, Mats D]

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

[MeeGo-dev] Compliance spec updated 1.0.99.2

[Wichmann, Mats D]

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

[Wichmann, Mats D]

Skarpness, Mark wrote:
> On 10/22/10 8:56 AM, "Wichmann, Mats D"
>  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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[MeeGo-dev] new draft of MeeGo compliance specification

[Wichmann, Mats D]

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] Touch support in X (was: QtMobility has branched)

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> On 19/10/10 6:47 PM, "ext Thiago Macieira"  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

Re: [MeeGo-dev] How to get a unique uid for a device running meego?

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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 ?

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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.

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego spec - for comment

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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//)?
> 
>> The structure of the directories below /opt/ is left up to
>> the packager of the software, though it is recommended that packages
>> are installed in /opt// 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//lib or
>> /opt//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

[Wichmann, Mats D]

> - 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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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?

[Wichmann, Mats D]

Matt Porter wrote:
> On Fri, Aug 20, 2010 at 12:46 PM, Wichmann, Mats D
>  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] Does MeeGo need OpenGL/ES or OpenVG Hardware?

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
> On Fri, Aug 20, 2010 at 11:56 AM, Arjan van de Ven
>  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] Building the Meego Dev Environment

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

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

[Wichmann, Mats D]

M. Edward (Ed) Borasky wrote:
> A little research:
> 
> 1. "zypper info gnash" on openSUSE 11.2 yields the following
> 
> Repository: openSUSE-11.2-Oss
> Name: gnash
> Version: 0.8.5-2.3
> Arch: x86_64
> Vendor: openSUSE
> Installed: No
> Status: not installed
> Installed Size: 9.4 MiB
> Summary: Free Flash movie player
> Description:
> Gnash is a Free Flash movie player, which works either standalone, or as
> a Firefox/Mozilla plugin. Gnash supports the current Shockwave format,
> version 7. While all the ActionScript classes exist, not all of the
> methods defined by the SWF format documentation are implemented however,
> so not all flash movies work 100% if they utilize any of the
> unimplemented methods. This is one of the areas to work on to achieve
> full version 7 compliance. 
> Authors:
> 
> Rob Savoye 
> 
> 2. The Gnash web site at http://www.gnu.org/software/gnash/ states:
> 
> "Gnash is based on GameSWF, and supports most SWF v7 features
> and some
> SWF v8 and v9.


It seems the most current info is at www.gnashdev.org, and
there have been two releases since the 0.8.5 version listed
above, which have further improved (supposedly) the situation.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Adobe Flash 10.1 on Meego

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:

> Nokia ships devices with Flash support, both on the Symbian
> and Maemo worlds.
> It's the Adobe version, so it must be a separate deal between Adobe and
> Nokia. 
> 
> Intel doesn't have devices to ship, just chips.
> 
> Either way, Adobe Flash will never make it into MeeGo, unless Adobe
> decides to open-source it and relicense under an approved license.

I think I started from this point, it's Adobe's call, and no it's
not going into the MeeGo repository - but so what, it can live
in Adobe's repository which you can add if you wish (at least this 
is currently the case for x86 side, perhaps not so for ARM yet?)

> But OEMs can still put Flash on top of the MeeGo core for
> their devices. My guess is Nokia will do that.

Since you say this already happens for pre-MeeGo devices, 
that will not surprise people then.


And in a different message, Auke writes:

> Let's just focus on Open Source issues with MeeGo?

Bdale mentioned Gnash, and other folks said it's not good enough.
Can we help with this as individuals?  For example, WINE has
had an active program to have people report details of Windows apps
that don't work, so they can be addressed.  Does Gnash have a
similarly active program that people could be reporting websites
that won't play with the gnash/gnash plugin?  I see a wiki page 
of "key sites" that ought to work, but that doesn't seem quite the
same, that's more like a QA target (these sites ought to be checked
for a new release).  And does it help if we do that, or does it
overwhelm?

 

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Adobe Flash 10.1 on Meego

[Wichmann, Mats D]

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

Re: [MeeGo-dev] Adobe Flash 10.1 on Meego

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:
>>  Do you
>> actually want this on your device?
> 
> Indeed, and some companies do want it.

Well of course, I was being silly.  "Everybody has it"
is a powerful argument that consumer-device mfg's
will have a very hard time saying no to, and perhaps
they should not say no, that's not something I should 
render a judgement on.  But we've got this proliferation
of websites with these pointless videos that are driving
this, and I think it's really an issue we're going to 
have trouble with.  I hope that website designers can get
a little more polite, like not playing stuff unless it's 
asked for.  I have one system set up so that it drops 
flash video files into /tmp, and if the browser tab in
which they played stays open, the file stays there...
and sometimes I'll see multiple multi-megabyte files
sitting there - sometimes rather significant sizes like
10 or more megabytes.  If I'm on my mobile device
connecting only through an expensive data plan, that's
not something I want going on without my consent just
because I browsed to a particular site on it. 
So for me personally (not the device mfg.), I don't
want it on my device even if I'll take it on my
notebook.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Adobe Flash 10.1 on Meego

[Wichmann, Mats D]

meego-dev-boun...@meego.com wrote:

> Thus Apples refusal to allow Flash on their Messiah
> pad/pod/phone gives everyone else an incentive to support it!


Well, let's make a couple of observations:

1. supporting Flash is not up to anyone but Adobe,
as they control the code and it's definitely not open.
Once there's a deal in place someone can presumably 
provide advice or more, but only to the extent
Adobe is willing to accept it.

2. it might behoove people to look at why Apple
is resistant to Flash.  Yes, of course there's
the aspect of control of the platform, etc.  But
if the anecdotes are accurate, Flash is a major
(maybe THE major) source of instability in MacOS
where it exists, and the fact that this proprietary
component is controlled by someone else means you
can do nothing about it but beg, not the best for
building a superior customer experience.  Do you
actually want this on your device?



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] MeeGo core utiltities, coreutils or busybox?

[Wichmann, Mats D]

- Original message -
btw, personally I don't think it is good solution as Moblin image is so big
at GB level and I'd recommend starting from much smaller one like Maemo and
"enrich" it.
Even more important; scrap the idea of changing from deb to rpm. What on earth 
were they smoking when they made that decsion!

this doesn't really help the discussion at all.

the decision to stick with rpm was made inside smoke-free buildings.


It seems the .rpm format allows to include special distribution licenses while 
the .deb don't. Both formats are very good and IMHO will be great if we see the 
.deb used for core distribution packages (OS) while .rpm handles third party 
apps and contributions.


Krohon



Speaking from personal experience, there are deb-derived package formats (e.g
ipkg) intended for embedded devices but the standard one isn't really 
appreciably
different from rpm in terms of space consumption - once the assumption is that
the device contains a complete package database of what's on the device, you
get what you get, which is a fair bit of "bloat".

As I've said elsewhere, there's kind of a divide between "stuff in the distro's
repository" and "stuff outside", and rpm vs. deb doesn't really end up being
the major issue here, the major issue is whether a package that's essentially
outside ("third party app") needs to depend on the internal details of the
particular version of the particular repository.   I've not been convinced any
of the efforts at more independent packaging have done better than rpm/deb
for third-party. but there are lots of folks who disagree.  And for internal,
as long as things are self-consistent, it doesn't seem to matter a whole lot,
if you take the body of what rpm/deb do/don't support there's far more in
common than different.






___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev