On Fri, Sep 30, 2011 at 12:08 PM, Tethys . tet...@gmail.com wrote:
On Fri, Sep 30, 2011 at 6:59 PM, quim@nokia.com wrote:
The trend of using web technologies to cover the apps space is clear
and pushed by many factors e.g. something simple to develop simple features
and compatibility
On Tue, Aug 16, 2011 at 2:48 PM, Bogdan Cristea crist...@gmail.com wrote:
On Sunday 14 August 2011 23:16:11 you wrote:
On 8/14/2011 1:09 PM, Bogdan Cristea wrote:
I have updated MeeGo to kernel 2.6.37.2-8.43 on a Lenovo hybrid
netbook,
but the wireless connection is no
On Tue, Aug 9, 2011 at 12:15 PM, Steve McIntyre
steve.mcint...@linaro.orgwrote:
The initial proposed agenda is:
* ARM hard-float
+ What is it and why does it matter?
+ How can distributions keep compatible (i.e. gcc triplet to
describe the port)?
* Adding support for ARM as an
On Fri, Jul 29, 2011 at 11:46 AM, Ware, Ryan R ryan.r.w...@intel.comwrote:
On 7/28/11 10:04 PM, Timo Härkönen timo.harko...@digia.com wrote:
On Fri, 2011-07-29 at 07:52 +0300, Zhou, JieX A wrote:
Hi all,
There is no scrub meeting for bugs assigned to
triaget...@meego.bugs today.
By
On Sat, Jul 16, 2011 at 8:56 AM, David Boosalis david.boosa...@gmail.comwrote:
Thank you for taking the time to reply and the list of commits is very
impressive. How does one get the commits, is there a repository I can add.
And is is there any plans to get Meego SDK working on Ubuntu 11.04
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)
On Mon, Jun 20, 2011 at 10:40 AM, Sergio Schvezov sergius...@ieee.orgwrote:
I'm currently taking recommendations to implement obtaining the proxy
from system configuration, most people seem to recommend libproxy,
which is fine. The problem I see with it is that if you take a look at
the MeeGo
On Sat, Jun 18, 2011 at 6:55 AM, Andrey Ponomarenko
aponomare...@ispras.ruwrote:
**
Hi there,
The MeeGo SDK for Linux [1] officially supports only Ubuntu and Fedora.
I've checked it on popular openSUSE and Debian 5 and it doesn't work there
(it hangs on the first one and crashes on the
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.
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
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
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
meego-dev-boun...@meego.com wrote:
On 07/05/11 23:00, Jeremiah Foster wrote:
On Tue, May 3, 2011 at 10:43 PM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
meego-dev-boun...@meego.com wrote:
http://www.meego.com/Quality/Compliance_Implementation
hope that's of some use
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
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
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
meego-dev-boun...@meego.com wrote:
2011/3/30 Leonardo Luiz Padovani da Mata leonar...@syst.com.br:
On Wed, Mar 30, 2011 at 12:03 PM, Pei Lin
telent...@gmail.com wrote:
2011/3/30 Thiago Macieira thi...@kde.org:
On Wednesday, 30 de March de 2011 11:20:35 Leonardo Luiz Padovani
da Mata wrote:
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,
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
I think you're missing some details here. It's not the Red Hat version,
sources.redhat.com is merely a hosting site, and that version is in fact the
official GNU libc, the ones you'd get from ftp.gnu.orgftp://ftp.gnu.org.
eglibc is a fork, created initially because the glibc project declined
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
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
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
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
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
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
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
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
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
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
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,
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,
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
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
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
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:
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
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
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
Skarpness, Mark wrote:
On 10/22/10 8:56 AM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
meego-dev-boun...@meego.com wrote:
Em Sexta-feira 22 Outubro 2010, às 17:28:36, Carsten Munk escreveu:
'A MeeGo compliant distribution MUST use the same tool chain and the
same compiler options
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,
meego-dev-boun...@meego.com wrote:
On 19/10/10 6:47 PM, ext Thiago Macieira thi...@kde.org wrote:
Em Terça-feira 19 Outubro 2010, às 17:31:10,
sakari.pou...@nokia.com escreveu:
Hi,
For MeeGo 1.2 the X.org 1.10 release is too late. We did not upgrade
kernel and X in the beginning of the
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
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
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-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
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
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
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
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
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
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
- 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
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.
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 /
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
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
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
meego-dev-boun...@meego.com wrote:
On Fri, Aug 20, 2010 at 11:56 AM, Arjan van de Ven
ar...@linux.intel.com wrote:
On 8/20/2010 8:51 AM, Tobias Renz wrote:
Thanks already for your answers!
The targeted device is like a measurement device. So It's not too
important to have MeeGo
Matt Porter wrote:
On Fri, Aug 20, 2010 at 12:46 PM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
meego-dev-boun...@meego.com wrote:
Is there a possibility for MeeGo adapting compliance for a different
class/tier of vertical markets? Or is this a path that just shouldn't
be bothered
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
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
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
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
64 matches
Mail list logo
