Re: [MeeGo-dev] Revoked Certificate api.meego.com new one being installed.

[Jeremiah Foster]

Since this mostly affects the MeeGo OBS, it might be nice if you could
point to the documentation on the MeeGo wiki for OSC and the web
interface to OBS on how one can accept new certs from OBS.

Thanks,

Jeremiah

On Tue, Jan 3, 2012 at 9:22 PM, adam.gretzin...@linux.intel.com
adam.gretzin...@linux.intel.com wrote:


 api.meego.com has been operating with a Revoked SSL Certificate for a few
 days. In the next 10 minutes or so i'll be switching us over to a
 commercially issued certificate for api.meego.com.  The last time we did
 this we ended up backing it out, mainly because people had to accept the new
 certificate, this time we can't move backwards since the old cert was
 revoked.




 Adam Gretzinger
 Intel Open Source Technology Center
 ___
 MeeGo-dev mailing list
 MeeGo-dev@meego.com
 http://lists.meego.com/listinfo/meego-dev
 http://wiki.meego.com/Mailing_list_guidelines



-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
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] Yocto (new release)

[Jeremiah Foster]

On Tue, Oct 25, 2011 at 1:03 PM, Ross Burton r...@linux.intel.com wrote:
 On Sun, 2011-10-23 at 23:51 +0200, Jeremiah Foster wrote:
 Has anyone tried to build MeeGo with Yocto? It looks like its starting
 to mature a great deal as a project, lots of cross-platform support.
 Any feedback on Yocto, OE, or Bitbake from this list?

 Starting to mature?  Poky had been used in commercial products for
 several years when it was acquired by Intel in 2008. :)

I meant no slight or insult. I only meant that it seems to be getting
features and bug fixes at a more rapid rate. I didn't mean to impugn
its quality.

Regards,

Jeremiah
___
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] Yocto (new release)

[Jeremiah Foster]

On Tue, Oct 25, 2011 at 4:06 PM, Samuel Stirtzel
s.stirt...@googlemail.com wrote:
 2011/10/25 Ross Burton r...@linux.intel.com:
 On Sun, 2011-10-23 at 23:51 +0200, Jeremiah Foster wrote:
 Has anyone tried to build MeeGo with Yocto? It looks like its starting
 to mature a great deal as a project, lots of cross-platform support.
 Any feedback on Yocto, OE, or Bitbake from this list?

 Hi Jeremiah, a colleague got parts of the Netbook UX running with
 OpenEmbedded, but this was back at the time of OpenEmbedded classic.
 Currently I mainly use OpenEmbedded Core, but lately I tried the new
 Poky release and liked it.
 Using a GUI (Hob) to get an overview of available packages is very 
 comfortable.

I saw that they've added a GUI front end for that. Should make it easier to use.


 Bitbake itself is a really smart program, using Autotools informations
 that already exists for most packages makes it very easy to add new
 software.
 In example I took an already programmed Qt application and slightly
 adjusted the makefile, used a basic recipe template and compiled it,
 that's all and IMHO it is amazing.
 Of course it is not always that simple, but for stand alone
 applications that only provide a GUI and some logic it works well out
 of the box.

Fascinating. Thanks for the feedback!

 Starting to mature?  Poky had been used in commercial products for
 several years when it was acquired by Intel in 2008. :)

 Ross, looking at the realignment of OpenEmbedded Core and Yocto, IMO,
 the new release was a great step forward.
 Personally I pretty much like the process, in which Yocto benefits
 from patches sent for OE Core and vice versa.

 Now and then I still wondered about why Intel didn't adapt Meego in
 Yocto/Poky, because both are very interesting projects.
 And right now I wonder where Meego will be in the future.

Well there are a lot of people with @intel.com in their email
addresses that seem to be involved in the project so perhaps we'll see
some use of it in the future. With Tizen perhaps?

Regards,

Jeremiah
___
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] Cross compilation tools (Was: MeeGo Reconstructed)

[Jeremiah Foster]

On Mon, Oct 24, 2011 at 2:02 PM, Lauri T. Aarnio
lauri.t.aar...@nokia.com wrote:
 On Oct 21, 2011, at 9:33 PM, ext Carsten Munk wrote:
 2011/10/21 Lauri T. Aarnio lauri.t.aar...@nokia.com:
 On Oct 21, 2011, at 4:05 PM, ext Carsten Munk wrote:


 OK, that is a fairly clever approach. I wonder if
 we could do something similar with the approach we currently use for
 cross compilation.

 Probably not, without risking something else.

 Perl is an extremely tricky tool, which makes already itself use of far too 
 many clever features that are available.

 One example is that built-in variable $^X is implemented by reading where 
 /proc/self/exe symlink points to.
 And many scripts actually record that to something what they produce [this 
 was the original reason why SB2 got a special handler for the /proc FS!]

 This means that you should not install perl anywhere else than to 
 /usr/bin/perl. So something like a simple redirector at /usr/bin, which would 
 determine what version to use and then exec a perl from somewhere else, would 
 just create more problems that what it would solve.

 The same applies to the locations of the libraries, etc. = In theory it is 
 possible to change the default locations, but in practice it it just a stupid 
 thing to try.

You're spreading FUD. Perl runs a lot of architectures and platforms
because it is flexible. Because you can't configure it for your
cross-compilation environment is not the fault of how the language
gets built. If you have problems, look at tools like perlbrew for
pointers on how to install many perls, or ask questions on
perl-5-porters.

Regards,

Jeremiah
___
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] Cross compilation tools (Was: MeeGo Reconstructed)

[Jeremiah Foster]

On Fri, Oct 21, 2011 at 3:05 PM, Carsten Munk cars...@maemo.org wrote:
 2011/10/21 Lauri T. Aarnio lauri.t.aar...@nokia.com:

 On Oct 19, 2011, at 2:44 PM, ext Carsten Munk wrote:

 That is in fact what we did for an experimental SB2-based SDK for Harmattan. 
 There are even two perls, the ARM version and the x86 version (both are 
 known as /usr/bin/perl.) They don't have to have similar configurations; the 
 x86 side contains only selected tools and doesn't have to be updated so 
 often.

 Okay, so, let me elaborate - what I meant was - imagine this situation:

 1) Source package build-depends on, random example, perl-SSLeay, which
 is a perl extension that's built with native code

That is really a corner case. Most perl modules don't use XS (what you
refer to as native code) and the perl-SSLeay module has been a
particular problem over the years because it has some pretty gnarly
dependencies. You won't see this problem with most of the perl modules
in MeeGo for example.

What package as a build time dependency on perl-SSLeay? And is that a
good idea? Why is a module designed to do SSL communication a build
dependency?

 2) We have SB2 doing mapping to a x86 perl and has selected
 tools/extensions compiled for x86 too which doesn't include
 perl-SSLeay

Again, this is only for perl modules that use XS.

 3) For this compile to be successful with an accelerated perl, this
 extension would be have to be added for x86 too and otherwise cause a
 fail in compilation due to missing extension

 I feel there's unforseen consequences if we don't keep sources and
 versions in sync on both X86 and ARM side, just try to remember how
 much of a mess SB1 devkits turned out to be in non-upgradability and
 being out of sync with what actually existed :) - and potential
 differences in how a native machine would build a package vs how a
 cross compiled one would be.

Seems like a pretty reasonable argument.

 I'm aware this approach with maintaining a tools distribution that
 doesn't have to be updated so often probably works in a
 most-developers-inside-one-company and strict requirements/dependency
 checking but this was a problem that people in community hit quite a
 lot when building software for Maemo as an example.

 That said - if you keep the source packages in sync (as OBS can do)
 and map a x86 version instead of ARM version of each
 interpreted-language-extension through SB2 mapping, it might work.

 I'd like to see a SB2 approach to OBS building of RPMs - it might have
 some benefits (such as non-root local builds) and perhaps can do it
 faster. Would be good to get statistics on the table for what speed
 benefit it has :). If you'd like to start with that, you can try to
 package up sb2 for RPM, and hack the 'build' package to be running SB2
 instead of rpmbuild. You can do this on local builds too.

 But a definite no to a tools distribution that we map to that's not
 updated so often. It's a maintainability nightmare. Packages that are
 being built should be built using tools that are from the OS they're
 being built for or we're in for a world of hurt.

But you have to recognize that people are not going to just use your
packages, they're going to rebuild them. If they're not rebuilding
your packages, then your particular software or image is not
interesting for their particular problem. A reliance on a
overly-complicated toolchain that makes the current process hard to
reproduce and packages hard to rebuild on a new target or in a
different build system. Everyone says use our tool! but in fact in
open source you will find there are lots of tools, some of them as
good as yours.

Regards,

Jeremiah



-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
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] Cross compilation tools (Was: MeeGo Reconstructed)

[Jeremiah Foster]

On Fri, Oct 21, 2011 at 3:46 PM, Carsten Munk cars...@maemo.org wrote:
 2011/10/21 Jeremiah Foster jeremiah.fos...@pelagicore.com:
 On Fri, Oct 21, 2011 at 3:05 PM, Carsten Munk cars...@maemo.org wrote:
 2011/10/21 Lauri T. Aarnio lauri.t.aar...@nokia.com:

 On Oct 19, 2011, at 2:44 PM, ext Carsten Munk wrote:

 But you have to recognize that people are not going to just use your
 packages, they're going to rebuild them. If they're not rebuilding
 your packages, then your particular software or image is not
 interesting for their particular problem. A reliance on a
 overly-complicated toolchain that makes the current process hard to
 reproduce and packages hard to rebuild on a new target or in a
 different build system. Everyone says use our tool! but in fact in
 open source you will find there are lots of tools, some of them as
 good as yours.

 I'm not sure what you mean exactly, please elaborate.

Cross-compilation of packages may make it hard to rebuild packages on
the target.

 Besides that,
 this discussion is actually about discussing cross compilation
 approaches, alternatives, explaining each other's approaches :) For
 some cases, multiarch might be good too.

 With regards to 'hard to reproduce', two sides/things we've learnt from 
 history:

 1) Packages must not rely on being built inside a specific cross
 compilation environment

One might argue that you should remove the word specific from that
sentence and you'd get to a more simple solution. I.e. compile on the
target.

 This is what made Maemo packages so bloody hard to reproduce on top of
 Debian/Ubuntu - they relied on things Scratchbox did. In the OBS
 'cross' approach we try to be as close as possible to as how an ARM
 machine would build the package.

 2) MeeGo cross compilation was a nightmare to reproduce and copy to
 other OBS'es and get working properly, due to source packages not
 representing the needed contents / links between packages (like gcc to
 cross-armv7l-gcc-accel, etc)

 obstag has helped this to some extent and now that we utilize fakeobs
  rsyncable source releases in Mer, anyone can set up a working setup
 with ease.

[snip legalese]

 Someone should outlaw these signatures or at least create logic that
 disables them from mailing lists..

Sadly its a requirement in some quarters. :-/ I'll try to remember to trim mine.

Regards,

Jeremiah
___
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] Cross compilation tools (Was: MeeGo Reconstructed)

[Jeremiah Foster]

On Fri, Oct 21, 2011 at 6:25 PM, Lauri T. Aarnio
lauri.t.aar...@nokia.com wrote:

 On Oct 21, 2011, at 4:36 PM, ext Jeremiah Foster wrote:

 On Fri, Oct 21, 2011 at 3:05 PM, Carsten Munk cars...@maemo.org wrote:

 1) Source package build-depends on, random example, perl-SSLeay, which
 is a perl extension that's built with native code

 That is really a corner case. Most perl modules don't use XS (what you
 refer to as native code) and the perl-SSLeay module has been a
 particular problem over the years because it has some pretty gnarly
 dependencies. You won't see this problem with most of the perl modules
 in MeeGo for example.

 Unfortunately corner cases matter, too. Most is not enough, if there are 
 hundreds or thousands of packets to compile.

A corner case is not most, it is usually a singleton or a handful. I
still think this is a remarkable example of a corner case, a perl
module with XS that is a build dependency because it provides an SSL
library!

Regards,

Jeremiah
___
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] The future for the MeeGo OBS

[Jeremiah Foster]

Hi,

Everyone on this list ought to recognize that you have the legal right
to fork the source code and that others have the legal right to ignore
you.

Its time to move on and to focus on more constructive things.

Regards,

Jeremiah

On Wed, Oct 12, 2011 at 6:28 PM, David Greaves da...@dgreaves.com wrote:
 I'm sorry Ryan I thought I was being polite and constructive so I'm not sure
 where the since long before you came aboard the project is coming from?

 I also realise I've only been around MeeGo almost every single day since the
 day it launched - I'll try harder to be more passionate, more visible and
 part of it for longer next time around :D

 So, back to the question: We, as members of the 'official' MeeGo IT team,
 are offering to help support some MeeGo infrastructure which is clearly not
 being maintained to anything like a professional standard.

 I did copy the only known member of the TSG in on the email as well as Anas
 and Brian.

 I'm sure many others in both the hacker community and the commercial
 community feel that there's a very high risk associated with relying on an
 apparently absent RE team and on a service which is now at 80%
 availability.

 At least the MeeGo IT team are present and replying to email and irc - both
 in US and EU timezones.

 David

 PS I do get the impression that people think we're on some kind of
 power-trip and want to take over the main OBS. Well, trust me, looking
 after an OBS as well as the rest of the MeeGo.com infrastructure is a HUGE
 chore, *not* fun. It eats massively into our personal time and can be
 immensley frustrating. We do however take our responsibility seriously and
 as professionals and community members we hate to stand by and let people
 suffer when we could easily help out.


 On 12/10/11 15:32, Ware, Ryan R wrote:

 David,

 The MeeGo OBS is the purview of the Release Engineering team.  It has been
 that way since long before you came aboard the project.  If you have
 concerns about that, please bring it up with the TSG.

 Ryan

 -Original Message-
 From: David Greaves [mailto:da...@dgreaves.com]
 Sent: Wednesday, October 12, 2011 2:40 AM
 To: meego-dev@meego.com; Ware, Ryan R;
 brian.war...@linuxfoundation.org; Sousou, Imad; Anas Nashif; meego-
 i...@meego.com
 Subject: The future for the MeeGo OBS

 The MeeGo OBS at build.meego.com is down... again.

 The MeeGo IT team renew their offer to provide additional service level
 support for the main OBS.

 This would allows the community to have some confidence in the continuity
 and availability of these important services and provides the commercial
 organisations still working on MeeGo with the same confidence.

 This means that everyone who wants to work on any aspect of MeeGo Trunk
 is essentially blocked.

 This is not a recent issue:
    https://bugs.meego.com/show_bug.cgi?id=22134

 A few weeks ago the MeeGo IT team (ie the guys who run DNS,
 www.meego.com, the mailing lists, the forum, the community OBS etc)
 asked for permission to access the main OBS to provide support. This was
 refused. An explanation was due to be given but some urgent issues
 apparently prevented that. Since this was mere weeks before the shift to
 Tizen it is possible that that was related. In any case it is time to
 revisit this
 request.

 Ryan - I think you got landed with being point-man last time so I'm
 cc'ing you
 directly :) Since MeeGo is a Linux Foundation project I'm cc'ing you too
 Brian.
 Anas - I guess the OBS used to be your responsibility but I have no idea
 if it
 still is.
 Imad - just so you know.

 To illustrate the problem this graph shows availability of the main OBS:

 http://isobsdown.bfst.de/trends.api-obs_api.1314144000_1317921806_2011-
 10-06T17.23.26.png

 This shows corresponding availability of the community OBS:

 http://isobsdown.bfst.de/trends.cobs_api-
 obs_api.1314144000_1317921806_2011-10-06T17.23.26.png

 David
 Niels
 (Stefano is on vacation)

 --
 Don't worry, you'll be fine; I saw it work in a cartoon once...


 --
 Don't worry, you'll be fine; I saw it work in a cartoon once...
 ___
 MeeGo-dev mailing list
 MeeGo-dev@meego.com
 http://lists.meego.com/listinfo/meego-dev
 http://wiki.meego.com/Mailing_list_guidelines




-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Wed, Oct 5, 2011 at 10:09 AM, Stefan Werden stefan.wer...@open-slx.dewrote:

 Jeremiah Foster jeremiah.fos...@pelagicore.com hat am 4. Oktober 2011 um
 20:42
 geschrieben:

  On Tue, Oct 4, 2011 at 6:48 PM, Stefan Werden
  stefan.wer...@open-slx.dewrote:
 
   Hi,
  
   switching to debian would mean making a complete new projekt.
 
 
  Nope, it would merely mean adding software to the Debian project, it
  wouldn't require a new project at all. Debian would host the
 infrastructure
  (it has its own IRC, build farm, hosting, project software, email lists,
  funding, non-profit status, social contract, shell accounts, git server,
 svn
  server, well, you get the picture.) You could turn Mer into a Debian
 blend
  for example: http://wiki.debian.org/DebianPureBlends or you could become
 a
  Debian derivative: http://wiki.debian.org/Derivatives/Census
 
  Debian derivatives currently dominate the Linux landscape. Of the top
 four
  distros on Distro Watch, three of them are deb based. This means you get
 a
  huge development ecosystem when you use debs, as well as a lot of users.



 Distrowatch are server and dektop disties. The special thing in MeeGo was
 that
 the focus was on emerging devices.


And how exactly did it do that? By using Connman? By using an embedded
Linux kernel? Btrfs? By being small? What exactly makes MeeGo different
from other desktop distros? Or was it just a little bit of marketing?


 So this makes it special, because it does not
 need to care about the old stuff. So bcoming a debian flavour feels not
 really
 like an option to me.


That's fine. It doesn't have to be an option for you. It should be described
as a potential option for others on this list however since they may not
have made up their minds yet and the FUD that is being thrown about here is
misleading.

Regards,

Jeremiah
___
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 Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Wed, Oct 5, 2011 at 9:39 AM, Samuel Stirtzel
s.stirt...@googlemail.com wrote:

 2011/10/4 Jeremiah Foster jeremiah.fos...@pelagicore.com:

  Can a mobile
  segment distro like MeeGo be really compared with a desktop segment
  distro like e.g. embedded Ubuntu? (This is not relative to your
  message but a general rhetorical question.)
 
  I don't understand what you mean by segment here. And I also don't
  understand what you're referring to with embedded Ubuntu.

 What I meant is that a embedded desktop OS targets another audience
 than the embedded mobile OS (or in other terms a different market
 segment).

 Well I'm sorry for using the term embedded Ubuntu, I've assumed that
 others refer to projects like Linaro-Ubuntu [1], the TI-OMAP Ubuntu
 [2] and in general ARM Ubuntu as embedded Ubuntu too.

No reason to apologize! I was just not certain what you were referring to. :)

 
   Before it was just big companies that could create their own Linux
   distros
   (before that everyone had their bespoke UNIX distro) nowadays
   fragmentation
   is brought to you by every Tom, Dick and Harry with an OBS login.
   I've been down the fragmentation road before. It always ends with
   retracing
   your path back to the main highway.
 
  There seems to be much standardization work going on in the Yocto
  Project / OpenEmbedded Core (see [3], also Carsten already mentioned
  the Yocto Project in context of governance), anyone evaluated it?
 
  Yocto is very interesting indeed, as is OpenEmbedded, though the claim is
  that Yocto is open embedded done right. But for the purposes of a distro I
  don't think Yocto is the silver bullet people are looking for. Firstly, it
  seems focused on Intel Atom BSPs and overall seems designed to help in board
  bring-up. Yes you can create a complete distro, but like a misused OBS
  repository, creating your own complete distro is not a good idea. Unless of
  course yours is THE ONE.

 Your statement about Yocto is right, but OpenEmbedded isn't
 OpenEmbedded anymore, alot has changed since this statement was true.

 OpenEmbedded Core (the new OpenEmbedded) and the Yocto Project merged
 their efforts and created an unified code base

I tried to point that out by saying Yocto is 'open embedded done
right.' But I guess I was unclear. From what I understand bitbake is
still at the heart of both these projects and that is a pretty
interesting piece of technology.


 (see [3] and [4]), also
 OpenEmbedded Core + Yocto supports a larger audience (see [5] for the
 approved list of BSP layers).

 In OSS systems there should not be a THE ONE distribution, for end
 users this is out of the question, they might not want to create their
 own distro, but (IMHO) developers should not be restricted in this
 direction.

But that is precisely the point. To serve end users you need a
consistent, easy to use platform, with a large ecosystem of developers
to create new applications. This is one of the reasons why Debian is
useful: its foundation is that it puts users first. From the Debian
Social Contract; We will be guided by the needs of our users and the
free software community.

Yocto puts developers first which is great - but it doesn't make for a
consistent, easy to use platform, with a large ecosystem. It creates
different chunks which are little Linux stacks which one places over
the layers which seem to be like Linaro Hardware Packs, i.e. BSPs
and drivers. These chunks function as a Linux distro, you can add
packages and UIs and all kinds of amazing stuff, but you have no
community. You have no ecosystem, you don't scale.

 
  The Yocto Project / OpenEmbedded was discussed before in the IVI
  mailing list (see [4]), but it lacks any technical explanations and
  arguments why it cannot be used / or get adapted, also OpenEmbedded
  progressed into the new OpenEmbedded Core Project (the next release is
  just one step away).
 
  https://wiki.yoctoproject.org/wiki/FAQ
  OpenEmbedded is widely used in commercial embedded systems. Those systems
  tend to not be open source systems and end up costing lots of money.
  Regards,
  Jeremiah

 Sorry I don't get your point here, no offense but if I would say:
 Debian is widely used in commercial desktop systems. Would your
 statement be the same?

No offense taken. I was purposely vague because I don't want to
publicly deride commercial Linux companies and other hardware
companies that use OE and Yocto.

The difference for me is that commercial Linux companies see Linux as
a technology. In my mind, that is a misunderstanding. Linux is a
kernel, combined with a userland (Android, GNU, etc.) and a license
group. This combination is where the magic occurs because it enforces
useful changes back into GNU/Linux distros and encourages a thriving
ecosystem. This thriving ecosystem is what makes Linux run on
everything from MIPS, to Xeon, to ARM M5, to A11, from old desktops to
the world's fastest computers, from phones to satellites.

 If you care about

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.comwrote:

 On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote:
  Long story short: buildd and launchpad is very useful but only when
  you're doing Debian and Debian only.


Except it was built by Canonical for Ubuntu and is used by Linaro. But
perhaps those two things are Debian too?


 OBS is different in many
  different ways and allows a proper productization environment as well
  as growing an organisation organically.


What does that even mean?



 I see, thanks for enlightening me.


You're not enlightened, you've just gotten a perspective from one developer
on why they like what they like.


 We should then look to add the
 missing features like Feature Planning (blueprint) and others from
 Launchpad, although we could just use the wiki for everything not
 build / commit stuff.


NB - Not all of Launchpad is open source.


 
  The choice has been made to go for OBS and RPM in Mer - we'll be in a
  even longer cycle if we were to revert to Debian based things and it's
  not obvious there'll be any benefit - I personally got bitten badly by
  basing on Debian/Ubuntu in the first iteration of Mer. We're here now
  and we have something that works and expertise in these areas. That's
  the direction we're going in.
 
  (I swear, if we are going to have the RPM vs DEB talk, I'll propose we
  switch to rot13 encrypted zip files and actually go ahead with it!)


Ignorance is bliss.

Regards,

Jeremiah
___
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 Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com 
karoliina.t.salmi...@gmail.com wrote:

 Hello,

 This is just my 0.02 cents. I would think it should be done like this:

 - Take the debian based distro and development environment (that works) as
 a basis. It works. Look at Harmattan and all previous Nokia Maemo devices.


This makes way too much sense to be adopted. :-)

Don't start your own project, join someone else's.
- Dan Frye:

Regards,

Jeremiah
___
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 Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 2:08 PM, Tom Swindell t.swind...@rubyx.co.uk wrote:

 On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote:
  On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.com
  wrote:
  On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk
  cars...@maemo.org wrote:
   Long story short: buildd and launchpad is very useful but
  only when
   you're doing Debian and Debian only.
 
 
  Except it was built by Canonical for Ubuntu and is used by Linaro. But
  perhaps those two things are Debian too?
 
  OBS is different in many
   different ways and allows a proper productization
  environment as well
   as growing an organisation organically.
 
 
 
  What does that even mean?

 OBS is built with packaging in mind, so it builds packages locally and
 on servers in a sanitized environment. Scratchbox may be polluted by
 whatever packages a developer has installed and makes dependency
 tracking a bit harder IMO.


I agree that working in a dirty chroot is problematic. That is why there is
pbuilder and cowdancer.



 I think what Carsten means by growing an organisation organically is
 that OBS allows multiple users to create their own repositories, it
 allows us to separate different projects into different repositories for
 staging or logical separation and it's easy and intuitive to do all of
 this from the web interface and to tools provided.


This is likely what he's referring to. But as someone who is concerned with
integration, this is bordering on a misfeature. What is happening is that
each repository is a separate Linux distro. This makes integration a
complete nightmare and unlikely to occur. Look a the ABI break that occurred
in MeeGo for ARM. That effectively killed any release of that distro.

Just because you can build your own Linux distro doesn't mean you should.


 OBS may not offer anything more or less than Launchpad or buildd, but it
 is completely open source and it targets many more distributions than
 Launchpad or buildd do.


And more package formats, processor virtualization, per-package compiler
flags, and a mock version control tool, etc. But all these things can mean
that your package will not work with other distros and then we are back to
everyone doing their own thing. How does that help move free software
forward? It doesn't, it only encourages the silo effect and Not Invented
Here.

Before it was just big companies that could create their own Linux distros
(before that everyone had their bespoke UNIX distro) nowadays fragmentation
is brought to you by every Tom, Dick and Harry with an OBS login.

I've been down the fragmentation road before. It always ends with retracing
your path back to the main highway.

Regards,

Jeremiah
___
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 Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 4:19 PM, Samuel Stirtzel
s.stirt...@googlemail.comwrote:

[snip]


 2011/10/4 Jeremiah Foster jeremiah.fos...@pelagicore.com:
  OBS is built with packaging in mind, so it builds packages locally and
  on servers in a sanitized environment. Scratchbox may be polluted by
  whatever packages a developer has installed and makes dependency
  tracking a bit harder IMO.
 
  I agree that working in a dirty chroot is problematic. That is why there
 is
  pbuilder and cowdancer.
 

 Wouldn't it be better to use a decentral build system?


Sometimes embedded developers only have the target and their laptop. So
often having your complete toolchain on your laptop while you work on site
at a customer for example can be part of a developer's work flow. This means
a decentralized system can be a necessity. But you have to make sure you
send back your patches.


 Can a mobile
 segment distro like MeeGo be really compared with a desktop segment
 distro like e.g. embedded Ubuntu? (This is not relative to your
 message but a general rhetorical question.)


I don't understand what you mean by segment here. And I also don't
understand what you're referring to with embedded Ubuntu.


 Well I didn't use embedded Debian as example because Emdebian mailing
 lilsts seem to be pretty dead [2].


Embedian is very much alive. More here:
http://www.debian.org/News/weekly/2011/12/#emdebian


  Before it was just big companies that could create their own Linux
 distros
  (before that everyone had their bespoke UNIX distro) nowadays
 fragmentation
  is brought to you by every Tom, Dick and Harry with an OBS login.
  I've been down the fragmentation road before. It always ends with
 retracing
  your path back to the main highway.

 There seems to be much standardization work going on in the Yocto
 Project / OpenEmbedded Core (see [3], also Carsten already mentioned
 the Yocto Project in context of governance), anyone evaluated it?


Yocto is very interesting indeed, as is OpenEmbedded, though the claim is
that Yocto is open embedded done right. But for the purposes of a distro I
don't think Yocto is the silver bullet people are looking for. Firstly, it
seems focused on Intel Atom BSPs and overall seems designed to help in board
bring-up. Yes you can create a complete distro, but like a misused OBS
repository, creating your own complete distro is not a good idea. Unless of
course yours is THE ONE.


 The Yocto Project / OpenEmbedded was discussed before in the IVI
 mailing list (see [4]), but it lacks any technical explanations and
 arguments why it cannot be used / or get adapted, also OpenEmbedded
 progressed into the new OpenEmbedded Core Project (the next release is
 just one step away).


https://wiki.yoctoproject.org/wiki/FAQ

OpenEmbedded is widely used in commercial embedded systems. Those systems
tend to not be open source systems and end up costing lots of money.

Regards,

Jeremiah


 On a technical point of view it is possible to port over to Yocto
 Project, and it would make sence to concentrate the development of
 embedded linux distributions to unify them into a single development
 base instead of fragmenting the communities.

 Well I just stated my opinion here.

 [1] http://lists.scratchbox.org/pipermail/scratchbox-devel/
 [2] http://lists.debian.org/debian-embedded/2011/09/threads.html
 [3] http://www.yoctoproject.org/projects/openembedded-core
 [4] http://lists.meego.com/pipermail/meego-ivi/2011-February/000198.html

  Regards,
  Jeremiah
 
 
  ___
  MeeGo-dev mailing list
  MeeGo-dev@meego.com
  http://lists.meego.com/listinfo/meego-dev
  http://wiki.meego.com/Mailing_list_guidelines
 

 --
 Regards
 Samuel
 ___
 MeeGo-dev mailing list
 MeeGo-dev@meego.com
 http://lists.meego.com/listinfo/meego-dev
 http://wiki.meego.com/Mailing_list_guidelines




-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
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 Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 6:48 PM, Stefan Werden stefan.wer...@open-slx.dewrote:

 Hi,

 switching to debian would mean making a complete new projekt.


Nope, it would merely mean adding software to the Debian project, it
wouldn't require a new project at all. Debian would host the infrastructure
(it has its own IRC, build farm, hosting, project software, email lists,
funding, non-profit status, social contract, shell accounts, git server, svn
server, well, you get the picture.) You could turn Mer into a Debian blend
for example: http://wiki.debian.org/DebianPureBlends or you could become a
Debian derivative: http://wiki.debian.org/Derivatives/Census

Debian derivatives currently dominate the Linux landscape. Of the top four
distros on Distro Watch, three of them are deb based. This means you get a
huge development ecosystem when you use debs, as well as a lot of users.


 I would prefer to
 just continure the current running stack.

It saves time and people know how to handle it.


*sigh*



 regards,

 Stefan


 Jeremiah Foster jeremiah.fos...@pelagicore.com hat am 4. Oktober 2011 um
 14:03
 geschrieben:

  On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com 
  karoliina.t.salmi...@gmail.com wrote:
 
   Hello,
  
   This is just my 0.02 cents. I would think it should be done like this:
  
   - Take the debian based distro and development environment (that works)
 as
   a basis. It works. Look at Harmattan and all previous Nokia Maemo
 devices.
  
 
  This makes way too much sense to be adopted. :-)
 
  Don't start your own project, join someone else's.
  - Dan Frye:
 
  Regards,
 
  Jeremiah
 --
 Dr. Stefan Werden
 Managing Director
 open-slx gmbh, HRB 25876,
 Einsteinring 7, 90453 Nürnberg, Germany




-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
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] Where's the evidence that Tizen will contain *any* MeeGo code?

[Jeremiah Foster]

On Fri, Sep 30, 2011 at 6:45 PM, Robin Burchell robin+me...@viroteck.netwrote:


  LiFo owns MeeGo and won't let us the name, to be sure,

 I'm not so sure about that, and nothing stops us from asking. The
 worst that can happen is that we're told no, and have to come up
 with a new name.


Why would you want it? It is a name synonymous with failure now.


  But seriously, if the worst case occurs and Tizen bears nearly no
  resemblance to MeeGo, why shouldn't we consider working on Qt
  development with Ubuntu Core, which is focused on ARM?


Different silicon for different situations.


 From previous experiments that I've seen with Ubuntu,
 performance-wise, I don't think this would be an option.


Okay, now you're starting to wander off into the woods here. You're going to
have to be very specific with what you claim are performance problems, don't
just throw out unsupported claims because you've got some random anecdotal
evidence. Linaro has made Android run 11% faster and I'm certain other Linux
optimizations have come along with that as well that affect the GNU
userland. If anything, deb based systems running Linaro perform much better
than rpm systems which traditionally are not multi-platform and are aimed at
the server.


 MeeGo Core is
 deliciously bare, which is one of the reasons it is a good choice for
 mobile (and also one of the reasons that makes me think we'll see
 parts of it live on in Tizen). Abandoning that legacy and jumping on
 board another distro is certainly an option, but not, I believe, the
 best available.


Linaro has done huge amounts of work on the Linux kernel on ARM silicon. ARM
chips have extraordinary price to performance ratio and can scale down as
well as up to multicore. If you're serious about Mobile Computing, you have
to look seriously at the ARM processor. Debian and Ubuntu are the two
distributions that have;

- Commercial support
- A decade long history of supporting ARM (and other platforms)
- A large highly-competent ecosystem

It makes a great deal of sense to just port some of the MeeGo stuff over to
deb-based systems, at least some of it, other parts of it already exist.



 [ of course, you're free to make your own decision ]

  Intel's possible complete departure, MeeGo development on Atom may
  completely stop, while Ubuntu Core is completely focused on ARM.


Wrong. Ubuntu works very hard to stress that they are not just an ARM distro
- they have a great x86 distro too.


 And that complete focus is a bad thing,


Again, wrong. Your making assumptions.


 it just minimalises your
 portability,


Now you just don't know what you're talking about. Debian is much, much more
portable than MeeGo is or Tizen will ever be.

Regards,

Jeremiah
___
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] Who will keep pushing MeeGo?

[Jeremiah Foster]

On Fri, Sep 30, 2011 at 7:40 PM, quim@nokia.com wrote:

 Dave wrote:
  and at best an improvement (HTML5 vs QML).

 Fwiw QML doesn't stop any HTML5 improvement. In fact it plays perfectly
 well with HTML  Javascript next to its neighbor QtWebKit, and bridges web
 development with native development (if you need it) down to core C/C++. If
 you need additional features not covered that web engine/framework X
 provides, you can add such engine/framework or you can improve/add to the Qt
 web engine/framework.


This is what is important to remember; that Qt and its ecosystem will likely
just work on Tizen. But, and this is a big but, will Nokia try and kill Qt
now that it is under Microsoft's boot?


 The strategic reasoning behind HTML5 is understandable: it is a general
 trend. The WAC part makes sense if you have a customer requiring it. Looking
 forward to the announcement of a native SDK and the reasoning behind it.



 And of course looking forward to see the work of the new Tizen stakeholders
 working on the Qt integration. The Qt Project will provide tools for them to
 make Tizen a first class Qt platform if they wish.


If we look at LiMo we can see it supports Qt and GTK+. I think that Tizen
will likely do so as well, if not, it will be trivially to port and I'm sure
Quim is right about tools being available for the work, as well as
developers and documentation. A toolkit is always needed, even if its just
to build browser windows. :-)

Regards,

Jeremiah
___
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] Who will keep pushing MeeGo?

[Jeremiah Foster]

On Mon, Oct 3, 2011 at 1:41 PM, kate.alh...@nokia.com wrote:


 On Oct 3, 2011, at 1:08 PM, ext Jeremiah Foster wrote:

 
  This is what is important to remember; that Qt and its ecosystem will
 likely just work on Tizen. But, and this is a big but, will Nokia try and
 kill Qt now that it is under Microsoft's boot?

 Nokia has clearly announced that Qt plays key role in next billion project
 and Nokia continues active Qt development. Nokia has two separate units,
 Smart devices that makes N9 and what is moving to MS stuff and then
 Mobile phones that currently makes S40 phones and will do this next
 billion project. Next billion project will make Qt handsets as mass
 products to mass markets.


Hmm, that is quite a different story from what I hear from Nokia's marketing
material. Somewhere there is a disconnect, either Nokia _is_ porting Qt to
WP*, Nokia will continue with Linux for the next billion, or Nokia will use
Symbian. Nokia publicly keeps saying the direct opposite of all these
options.

I realize you don't speak for Nokia's business plans per se but you can
understand that developers will be skeptical about certain technologies if
they aren't commercially viable. Free Software developers have to eat too.


 Just some numbers, devices called as smart phones were sold 300M in 2010
 but all handset market were 1.3 Billion. This 1 billion is not market that
 Nokia can just ignore.


Then why abandon what is likely the best smartphone platform out there right
now? I.e. N9?

Regards,

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

[Jeremiah Foster]

On Thu, Sep 29, 2011 at 7:07 AM, Peter Jespersen flywh...@illogical.dkwrote:

 Den 29-09-2011 00:46, Clint Christopher Cañada skrev:

  It's kinda disappointing though with what's happening.  Burned me once,
 that's ok, burned me twice, fine, but the third time (after speaking about
 Meego in some other engagements)?  You've got to have a pretty good reason
 why I'm gonna trust this new development.


 Got the same feeling here

 In short why ?

 Is this a way to make further distance from Nokia (Qt) via a rebranding ?

 Is it because you feel that MeeGo is getting nowehere (even though real
 units has seen the light of day) and that LiMo has a better chance (better
 support from hardware manufacturers) ?

 Is it Intel ?

 What does the Genivi Alliance have to say ?


I don't speak for the GENIVI Alliance. But from where I sit I see GENIVI is
a set of automotive middleware that runs on a number of operating systems in
a number of configurations. MeeGo is only one of those operating systems,
there are a number of others. A quick search for GENIVI compliance will
likely turn up some press releases about who else has a GENIVI compliant
distro.

Regards,

Jeremiah


 And why this secrecy ?

 Also it does sound a bit like Tizen will be LiMo-based


 Live long and prosper...


 __**_
 MeeGo-dev mailing list
 MeeGo-dev@meego.com
 http://lists.meego.com/**listinfo/meego-devhttp://lists.meego.com/listinfo/meego-dev
 http://wiki.meego.com/Mailing_**list_guidelineshttp://wiki.meego.com/Mailing_list_guidelines




-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
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...

[Jeremiah Foster]

On Wed, Sep 28, 2011 at 1:03 PM, Ross Burton r...@linux.intel.com wrote:

 On Wed, 2011-09-28 at 07:57 -0300, Fernando Cassia wrote:
  Tell me how an HTML5 app will interface to a camera or gps device, for
  instance

 Something like this I guess:

 http://www.w3.org/TR/html-media-capture/

 http://www.w3.org/TR/geolocation-API/



Those documents only show how you pass audio, media, and other streams into
HTML. It doesn't describe how you actually drive the hardware or how you
connect the hardware to the operating system. While this answers the
question how will an HTML5 app interface with a camera it doesn't obviate
the need for native drivers and modules to talk to the hardware, which was
partly the OP's point.

Regards,

Jeremiah




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




-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
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] WTF is Tizen !?!?! A takeover on MeeGo open governance!

[Jeremiah Foster]

Hi Florent,

Your frustration is understandable, but somewhat misplaced. It is entirely
okay to change the branding and governance of MeeGo, or any project. Open
Source licenses say nothing about project governance as long as the licenses
are respected. Much of MeeGo is under an Open Source license so it is
completely okay to make this change to Tizen, even if it discomfits
developers.

If you want more control over how your contributions are used, I'd recommend
using a strong copyleft license when you contribute software, like the GPL.
You may also want to contribute to truly open projects that have a clear
governance model and a proven track record of transparency. A project like
GNU, Debian, or Fedora for example might be more to your liking.

Regards,

Jeremiah

On Wed, Sep 28, 2011 at 2:35 PM, Florent Viard fvi...@gmail.com wrote:

 Hi,

 From where come the decision of switching to tizen? MeeGo guideline
 was supposed to be driven by open governance and meetings open to
 everyone, what does this mean to switch like that without asking to
 people of the community?

 Who is the stupid guy that though that switching everything to HTML5
 was the future? Someone coming from the wonderful failure that is the
 google chromeOS project?

 I don't say that adding an additional support for html5 apps in MeeGo
 is not good. But today, you have a system that start to become usable
 and to have its brand well known and you trash all of this in one day
 without discussion?

 Tell the truth, Tizen is an hostile action against MeeGo that is a
 serious concurrent to LiMo that is currently nothing. Without Tizen,
 Limo project would have been dead in few time as there is nothing and
 no one is willing to use it.

 Anyway, my MAIN CONCERN IS ABOUT THE GOVERNANCE:
 Tizen looks like to be more a takeover against the open governance of
 MeeGo.


 Just compare the governance of the two projects as stated in the
 about pages of each one:
 MEEGO:
 
 Governance
 MeeGo™ is an open source project created by merging the Moblin and
 Maemo software platforms, and is led by the MeeGo Technical Steering
 Group (TSG). The governance model is based on meritocracy and the best
 practices and values of the Open Source culture. The MeeGo project
 lives under the auspices of the Linux Foundation.

 MeeGo is open to all contributors
 There are no admission processes, contracts, or membership fees for
 MeeGo, just your desire to join the project and contribute.
 

 TIZEN: https://www.tizen.org/community
 
 Anyone can contribute by:

 Submitting patches
 Filing bugs
 Developing applications
 Helping with wiki documentation
 Participating in other community efforts and programs

 Membership in most project teams (Release Engineering, QA, Program
 Management, etc.) is invite-only and will mainly be open to people at
 companies who are building products based on Tizen. However, Community
 Office, Localization, and some Middleware development teams will be
 open to participation on a merit basis.
 
 Compare the: open to all contributors to the invite-only to companies.

 So, If you are not working at Intel or Samsung, the only part that you
 will be able to take in this project is to fill bugs and dev apps.

 Question: How the linux foundation legitimate a project that is not
 based on open governance and transparency?


 To anyone, please show here your agreement if you share the same
 feelings ! And don't legitimate this takeover!


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

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

[Jeremiah Foster]

On Wed, Sep 28, 2011 at 10:42 PM, S. Howard howa...@gmx.co.uk wrote:
 The APIs only show media streams being parsed through HTML. Interpreted
 languages are still developing and can sill be surpassed by compiled
 languages such as C/Python.

Eh? Python is not compiled, it is interpreted.

Regards,

Jeremiah
___
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] Adding Repo to OBS

[Jeremiah Foster]

On Sun, Aug 14, 2011 at 9:29 PM, Nasa nas...@comcast.net wrote:
 So,

 I continued to try and get this to work...  I came across somethings -
 build.meego.com == MeeGo.com:xxx  (for trunk it's
 MeeGo.com:Trunk).

Wow, interesting, I didn't know that. So anything that ends up in the
build repos can be used to build against? That is cool but I wish it
were documented somewhere.

 The field wants to give you other options -- I ignored
 that and kept with what I entered, for 1.2oss I put in MeeGo.com:1.2oss

 I still didn't see anything related to 1.2.0.90 (is it actually being
 worked on?).

 Looking at the official OBS, you can see a lot of projects -- their names
 don't clearly identify what they are for (what's the difference between
 1.2oss and 1.2.0oss, and they are different).  The paths for these projects
 repo is http://download.meego.com/live/MeeGo:/, may vary depending on project.
 This gives an insight on what files  versions a particular project is working
 with.

 The single problem I am still working on is building my project against one
 of those repositories.  The repository screen (for the project) shows it 
 listed,
 but none of my packages show it at all.

 Guess I'll keep looking...

The versioning scheme for MeeGo has become very confusing, I agree.

Regards,

Jeremiah
___
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] Adding Repo to OBS

[Jeremiah Foster]

On Fri, Aug 12, 2011 at 2:32 AM, Nasa nas...@comcast.net wrote:

  Rudi
 
 Thanks Rudi,

 I will have to take a read.  I obviously didn't explain what I was after
 very well.  On the
 https://build.pub.meego.com/project/add_repository_from_default_list?project=home%3Anasa
 page there a list of repositories one can add (such as Meego 1.1, 1.2, 
 debian, etc),
 however, there isn't one for some of the development tracks.  For my 
 interest, 1.2.0.90
 (ie: future 1.2.1) is the repository I would like to build some updated 
 packages against.
 I have already done it against Meego 1.2 and Current:Core.

 From your example, how was the repo for trunk added?  It's not listed as a 
 repo that can be
 added...

You should be able to add various repos in the advanced tab on that
same page, where it says: Or pick one via advanced interface. There
are a lot of distros to build against, I haven't seen the one you're
after but I didn't go through the whole list. It isn't obvious, but
that form is partial an auto-complete form. So start typing in the
project field until you find the repo you want to build against.

Regards,

Jeremiah
___
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] Adding Repo to OBS

[Jeremiah Foster]

On Fri, Aug 12, 2011 at 1:14 PM, Nasa nas...@comcast.net wrote:
 - Original Message -
 On Fri, Aug 12, 2011 at 2:32 AM, Nasa nas...@comcast.net wrote:
 
   Rudi
  
  Thanks Rudi,
 
  I will have to take a read.  I obviously didn't explain what I was
  after
  very well.  On the
  https://build.pub.meego.com/project/add_repository_from_default_list?project=home%3Anasa
  page there a list of repositories one can add (such as Meego 1.1,
  1.2, debian, etc),
  however, there isn't one for some of the development tracks.  For my
  interest, 1.2.0.90
  (ie: future 1.2.1) is the repository I would like to build some
  updated packages against.
  I have already done it against Meego 1.2 and Current:Core.
 
  From your example, how was the repo for trunk added?  It's not
  listed as a repo that can be
  added...

 You should be able to add various repos in the advanced tab on that
 same page, where it says: Or pick one via advanced interface. There
 are a lot of distros to build against, I haven't seen the one you're
 after but I didn't go through the whole list. It isn't obvious, but
 that form is partial an auto-complete form. So start typing in the
 project field until you find the repo you want to build against.

 Thanks Jeremiah,

 I was putting in the name of my project in that field instead of
 other projects.  Once I did things like meego a whole lot more options
 showed up...  However, I didn't see anything related to 1.2.0.90 and/or
 1.3.  It looks like this field is only pulling from projects listed on pub
 OBS - not the build one.  Is there a way to cross connect the two?

Good question. I don't know the answer. I know that one can upload an
entire distro and load that into the OBS to build against, you'll
likely need special permissions to do that on the official OBS though
I'm not sure. At this point, I think we need to get some more info on;

1. The nature and purpose of the various 1.2 point releases
2. How to configure these to build against in the MeeGo OBS

I think perhaps Joel C. can answer the first one and Anas the second one?

 The one thing that I am still confused on...  When I add a repository I assume
 I am building against a list of packages included in said repo.  But I don't
 see a way to see what packages are actually included in the repo I may have
 just added.

That is a very good question. To peer into the repo I think you'll
have to go to the separate repo URL. I am not sure if there is a way
to introspect the entire package list of one of those repos from the
OBS though that sounds like a very good feature.

 Thanks for putting up with us old, slow men.

heh, you can't be older than me. :) Nor slower.

Regards,

Jeremiah
___
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] Speech Recognition on MeeGo

[Jeremiah Foster]

On Thu, Aug 11, 2011 at 8:02 AM, manikanta gupta gupta_m...@sify.comwrote:

 On Wed, Aug 10, 2011 at 8:17 PM, Jeremiah Foster 
 jeremiah.fos...@pelagicore.com wrote:

 On Wed, Aug 10, 2011 at 1:42 PM, manikanta gupta gupta_m...@sify.comwrote:



 So I'm assuming your running on an ARM platform. Is your entire platform
 MeeGo IVI? I ask because you're calling your system sbox-maemo-arm-7 and
 that might not necessarily be MeeGo.

  I am using arm platform,but my entire platform is not MeegoIVI, i am
 using a normal maemo sdk rootstrap,i am trying to port the meegoivi on
 device,

  the following opengl packages are already installed on my scrathbox

 libqt4-opengl libqt4-opengl-dbg libqt4-opengl-dev

 later  i have also installed the following openGL ES packages ,as some more
 open GL packages may be missing

 libgles2
 libgles2-dev
 libgles1-dev
 libgles2-sgx-img-dev


  when i tried to compile with the above packages installed  the following
 output was shown

 sbox-maemo-arm-7: ~/meego-ivi-ux-ivihome]  ./ivihome
 Using the meego graphics system
 QEgl::display(): Cannot initialize EGL display: Bad alloc (0x3003)
 QEglContext::chooseConfig(): Could not find a suitable EGL configuration
 Requested: type=es2 rgba=0,0,0,0 surface-type=window
 Available:
 QGLContext::makeCurrent(): Cannot make invalid context current
 QEgl::display(): Cannot initialize EGL display: Bad alloc (0x3003)
 QEglContext::chooseConfig(): Could not find a suitable EGL configuration
 Requested: type=es2 rgba=0,0,0,0 surface-type=window
 Available:
 QEgl::display(): Cannot initialize EGL display: Bad alloc (0x3003)
 unable to dump 0004a800


I am just guessing but it looks like you've got an issue with Qt interfacing
with GLES. I don't think your issue is necessarily MeeGo specific frankly.

Regards,

Jeremiah



___
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] Speech Recognition on MeeGo

[Jeremiah Foster]

Hi,

On Wed, Aug 10, 2011 at 1:42 PM, manikanta gupta gupta_m...@sify.comwrote:

 HI

 I am newbie and

 I am trying to run the sampe application of speechrecogintion of ivi on
 scrathbox .I have taken the source files of the pocketsphinx and sphinxbase
 from the following source
  http://repo.meego.com/MeeGo/releases/1.1/ivi/repos/source/

 i was able to compile and generate the executable for meego-ivi-home
 (sample application )which was taken from
 https://meego.gitorious.org/meego-ivi-ux/ivihome/trees/v1.10

 When i had tried to run the executable on scrathbox by launching the Xephyr
 using the commond Xephyr  :2 -host-cursor -screen 800x480x16 -dpi 96 -ac
 (from host terminal)

 i was given the following output

 [sbox-maemo-arm-7: ~/meego-ivi-ux-ivihome]  ./ivihome


So I'm assuming your running on an ARM platform. Is your entire platform
MeeGo IVI? I ask because you're calling your system sbox-maemo-arm-7 and
that might not necessarily be MeeGo.


 Using the meego graphics system
 QEgl::display(): Cannot initialize EGL display: Bad alloc (0x3003)
 QEglContext::chooseConfig(): Could not find a suitable EGL configuration
 Requested: type=es2 rgba=0,0,0,0 surface-type=window
 Available:
 QGLContext::makeCurrent(): Cannot make invalid context current
 QEgl::display(): Cannot initialize EGL display: Bad alloc (0x3003)
 QEglContext::chooseConfig(): Could not find a suitable EGL configuration
 Requested: type=es2 rgba=0,0,0,0 surface-type=window
 Available:
 QEgl::display(): Cannot initialize EGL display: Bad alloc (0x3003)
 unable to dump 0004a800


It looks like you don't have OpenGL ES installed? Can you confirm?

Regards,

Jeremiah
___
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] LF will not permit apps.meego.com : say hello to apps.formeego.org

[Jeremiah Foster]

On Tue, Aug 2, 2011 at 8:27 PM, Dave Neary dne...@gnome.org wrote:
 Hi,

 On 08/02/2011 11:59 AM, Jeremiah Foster wrote:

 On Tue, Aug 2, 2011 at 9:44 AM, David Greavesda...@dgreaves.com  wrote:

 The Linux Foundation have told us in private conversations that they
 will
 not permit apps.meego.com to be served from the  MeeGo.com infrastructure
 hosted by them. They do not have the resource at this time to provide a
 statement giving their reasons. We can not assess what other services may
 be
 impacted in the future.

 This type of behavior is fundamentally anti-community. This shows the
 Linux Foundation's complete disinterest in users and developers,
 they're beholden to the corporate sponsors and donors who pay their
 bills.

 It's certainly easy to characterise things this way - but I think it's a
 cheap shot, and not a fair reflection on the Linux Foundation.

Hardly cheap Dave. I'd say its rather expensive as my company and many
of the companies we work with have assigned developers to work with LF
tools and distro's like MeeGo and OBS. If we cannot develop things
like app stores to compete with Google and Apple then we've invested
considerable money at a significant loss. We cannot generate revenue
through the authorized app delivery mechanism. Sorry, I don't see
how this is not a fair reflection of the Linux Foundation.

 From where I am standing, with no special knowledge at all, it looks like
 the Linux Foundation is simply a risk-averse organisation, conscious of the
 potential knock-on effects that any legal issues could cause for their
 members and the projects they host.

This is extremely dangerous. It goes against the precedent that says
there exist no legal claims against Linux. Linus has always said, if
there is something in Linux that belongs to someone else, point to the
code. That hasn't happened. Microsoft used to scream and shout that
they have proprietary technology in Linux, but they've never pointed
to a single line of code and today they contribute to Linux. This is
the path every company should take and if the LF itself starts to
doubt it's own legal positions, where will we end up? We'll end up
with a lot of vague patent claims and no users.

  It looks to me like legal counsel has a
 pretty big say in some strategic decisions the foundation makes, more so
 than corporate members (in fact, there are a couple of examples of corporate
 members pushing for things which met with some resistance in the Linux
 Foundation).

I don't know what you're referring to - perhaps you do have some
special knowledge?

 If my impression is correct, then you're not achieving anything with this
 characterisation -

Obviously I disagree. I think devs who get involved with a LF project
should know how they treat devs and the faux legal hurdles they face.
Knowing this before hand helps them make the right decision when it is
time to contribute code.

 on the contrary, our potential advocates inside the
 foundation

I prefer my real advocates to the potential ones. And I have enough of
those, Software Freedom Law Center, Software in the Public Interest,
Free Software Foundation, Free Software Foundation Europe, etc.

 and among their members are reading what you write,

I doubt it, but I hope so.

 while the
 legal advisors responsible for the decision are not; you're potentially
 forcing potential allies to circle the wagons, so to speak.

An 18th century metaphor for a 21st century problem! :-)

 I obviously hope that we find a way around the issues - perhaps EU hosting,
 a different domain name, or a second legal opinion judging that the risk is
 acceptable - but let's try not to be too hasty with the finger-pointing.

Let's have a discussion about it shall we? And during the discussion
some people might express strong opinions about the best way to do
things. They may be right. But in the end, developers vote with their
contributions, so we can molly coddle a thousand legal eagles and not
advance GNU/Linux one tiny inch forward. David Greaves has done the
only logical thing when you hit an impasse; fork. LF bears some of the
responsibility for this situation and to let them avoid it in their
stony silence is irresponsible.

Regards,

Jeremiah
___
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] LF will not permit apps.meego.com : say hello to apps.formeego.org

[Jeremiah Foster]

On Wed, Aug 3, 2011 at 6:55 PM, David Greaves da...@dgreaves.com wrote:

 Take a deep breath Jeremiah :)


meh. The ad hominem attacks are irrelevant.



 This is not a good situation but it is managable and may help resolve
 some organisational issues wrt MeeGo - silver lining :)


I have no idea what you're now trying to say. Are you saying; It's okay
that I forked the official apps for MeeGo! Because forking is generally
considered a Bad Thing.


 On 03/08/11 10:05, Jeremiah Foster wrote:

 Hardly cheap Dave. I'd say its rather expensive as my company and many
 of the companies we work with have assigned developers to work with LF
 tools and distro's like MeeGo and OBS. If we cannot develop things
 like app stores to compete with Google and Apple then we've invested
 considerable money at a significant loss. We cannot generate revenue
 through the authorized app delivery mechanism. Sorry, I don't see
 how this is not a fair reflection of the Linux Foundation.


 IMO this is nothing to do with App Stores generally.


Yeah, someone else mentioned this is limited to the Linux kernel only. I
really don't understand that approach. Free Software is governed by a
license, not by some arbitrary location in the stack. The point would be to
create a free software app store. Or at least give people the license to and
tools create their own for MeeGo. Or perhaps just let them use the trademark
if it works with MeeGo, but I guess we're going with the Android or iOS
approach here.


 This is LF refusing to take a legal risk on an area they feel that they
 have limited control over. It is a bit sad but litigation in the US is not
 something a small company messes with.


But if they do not stand up for developers creating apps for GNU/Linux
distros, who will?

How can the LF be scared of lawsuits? What happened to that giant trove of
patents that IBM donated to Open Source? I'm sorry, I'm not buying it.



 MeeGo as a project never (AIUI) promised to deliver an app store or a
 mechanism to deploy a local one. We in the hacker community wanted to
 support MeeGo by bringing OSS developers into the fold. Hopefully they'd
 help polish the tools and processes - and of course we'd get to publish our
 apps. So it was - and remains - a good idea for MeeGo. See later for why.


   From where I am standing, with no special knowledge at all, it looks like
 the Linux Foundation is simply a risk-averse organisation, conscious of
 the
 potential knock-on effects that any legal issues could cause for their
 members and the projects they host.


 Yes.

 The question this raises for me is : is LF a suitable host for the MeeGo
 community.


If you think that MeeGo is going to somehow magically escape the clutches of
the LF you need to take a deep breath. They're not even going to provide
an rsync server for the repos: https://bugs.meego.com/show_bug.cgi?id=19745



  This is extremely dangerous. It goes against the precedent that says
 there exist no legal claims against Linux.


 Total red herring Linux != OSS Apps.


Totally not. There is no proprietary code in the GNU userland either. There
are also tools that go through GNU/Linux packages regularly looking for
stolen code, things like FOSSology and protec so I think in general the
GNU/Linux kernel and userland are pretty well covered as, at the very least,
prior art. I'm sure we could get permission from one of those company's to
use their tools on our app repos which would go a long way towards
indemnifying LF.


   It looks to me like legal counsel has a
 pretty big say in some strategic decisions the foundation makes, more so
 than corporate members (in fact, there are a couple of examples of
 corporate
 members pushing for things which met with some resistance in the Linux
 Foundation).


 I don't know what you're referring to - perhaps you do have some
 special knowledge?


 All idle speculation  but WTF are we supposed to do?


Is there a distro that you can work on that isn't controlled by the LF? Are
there other Linux distros out there? I've heard of one or two.


 The LF are just not communicating.


And yet you've decided to create your own app store with the trademarked
term MeeGo in the name!



 I suggest that all we can do is some risk assesment as a project. Right now
 the limited information we have is that LF will not expose themselves to
 legal risk associated with binary distribution... so what happens to the
 main OBS? Home projects in the main OBS? Community OBS? CE project on the
 Community OBS?


Use something else?


  If my impression is correct, then you're not achieving anything with this
 characterisation -


 Obviously I disagree. I think devs who get involved with a LF project
 should know how they treat devs and the faux legal hurdles they face.
 Knowing this before hand helps them make the right decision when it is
 time to contribute code.


 Given a choice I personally would not currently choose to use the LF to
 host an OSS project. Maybe I

Re: [MeeGo-dev] LF will not permit apps.meego.com : say hello to apps.formeego.org

[Jeremiah Foster]

On Tue, Aug 2, 2011 at 9:44 AM, David Greaves da...@dgreaves.com wrote:
 cc'ed meego-dev as this may be of interest. Followup to meego-community
 please.

 Over the past few weeks a few of us who have been involved in the MeeGo
 community infrastructure have been trying to solve a problem relating to
 MeeGo Apps : apps.meego.com

Thanks David for bring this important issue to the community's
attention. I'm certain the community can solve this issue more quickly
and effectively than the LF.

 The Linux Foundation have told us in private conversations that they will
 not permit apps.meego.com to be served from the  MeeGo.com infrastructure
 hosted by them. They do not have the resource at this time to provide a
 statement giving their reasons. We can not assess what other services may be
 impacted in the future.

This type of behavior is fundamentally anti-community. This shows the
Linux Foundation's complete disinterest in users and developers,
they're beholden to the corporate sponsors and donors who pay their
bills.

 In the meantime we have moved ahead to provide apps.formeego.org (thanks to
 Thomas for acquiring that domain - see
 https://bugs.meego.com/show_bug.cgi?id=20531). There are plans being worked
 on to setup infrastructure to host apps there - the community needs to
 decide how to manage that infrastructure and domain.

Shouldn't the same folks who do the Maemo forums and garage be
involved? They have experience in this sort of infrastructure.

 On a personal note I am very disappointed by the Linux Foundation's response
 to this situation. There has been no open discussion, the verbal reasons
 provided were vague (although, I must emphasise, I am not doubting that
 there are valid concerns given the nature of the legal framework in the US)
 and insufficient effort has been made to assist the community in resolving
 (or even understanding) this problem - as I mention, since we're not clear
 about what the reason is we have no idea what other services may be
 impacted.

I agree David and I must say I'm disappointed too, but I cannot say
I'm surprised.

Regards,

Jeremiah
___
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] creating image for oaktrail platform using mic-image-creator

[Jeremiah Foster]

On Thu, Jul 7, 2011 at 2:52 PM, bradleyyan bradley...@linpus.com wrote:
 On 07/07/2011 03:24 PM, bradleyyan wrote:

 On 07/07/2011 11:30 AM, Arjan van de Ven wrote:

 On 7/6/2011 7:30 PM, bradleyyan wrote:

 It is my mistake,I forgetten to install install related packages.

 also make sure to upgrade your firmware; this was a bug in early
 firmwares that got since fixed...

 I downloaded the meego repo to local machine,using the local repo to
 install packages.
 And when install image in machine using GUI mode,it said:
 X startup failed
 /usr/sbin/liveinst: line93: kill: `': not a pid or valid job spec

 Problem had been solved,

How was it solved?

 the meego img doesn't support GUI mode
 installation.

Is that correct for all images built with mic-image-creator? You
cannot install in graphical mode?

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

[MeeGo-dev] MeeGo Compliance, specifically IVI

[Jeremiah Foster]

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?

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?

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?

Thanks,

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

[Jeremiah Foster]

On Sat, May 7, 2011 at 2:23 PM, Counihan, Tom tom.couni...@intel.com wrote:

[...]


 Does that mean the IVI compliance specification is independent of the
 overall MeeGo compliance specification?

 Mark gives a great insight into the compliance structure here: 
 http://conference2010.meego.com/session/app-compatibility-and-meego-compliance-program
 It's worth a view as it addresses many of the questions.

Thanks. I'll read that.

 In essence, IVI will have an additional spec, but an IVI compliant system is 
 a combination of the 'core' compliance, plus the additional IVI spec.

So each vertical's compliance profile is a compliment to the overall
MeeGo Compliance, if I understand things correctly?


 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?

 http://dev.linuxfoundation.org/~mats/MeeGo-Compliance-Spec-1.0.99.9.pdf 
 states:

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?

 Implementations must support MeeGo API. The MeeGo API consists of the 
 following:
 * Qt 4.7 [Qt47]
 * Qt Mobility 1.0 [QtMob]
 * OpenGL ES 2.0 [OGLES] (ARM) or OpenGL [OGL] (Atom)

 So, ES is part of Core, ergo it is automatically part of IVI compliance.

So this means that one can specify in the compliance profile for the
IVI vertical OpenGL ES?

Regards,

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

[Jeremiah Foster]

On Sat, May 7, 2011 at 2:40 PM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
 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.

Where can I find that document?

 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.

Okay, so a specific vertical might inherit from the core compliance?
Would it be possible to state this along the lines of OpenGL ES is in
MeeGo Core so using OpenGL ES in MeeGo IVI is compliant?

 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.

Makes sense to me. I think it is definitely worth trying since having
inter-device compatibility is a significant innovation, at least on
the API level.

 There's a second example on the wiki, which was an initial effort at
 a handset profile:
 http://wiki.meego.com/Quality/Compliance/HandsetProfile

Thanks, I'll look at that and propose that as an input to the IVI
compliance discussion.

 (*) write could consist of just feeding me (as the spec editor)
 the appropriate information, and then doing reviews.

Can I propose specific compliance packages directly to you? Obviously
I'd be wearing my MeeGo IVI Release Manager hat and would have
something for compliance that has received consensus in the IVI
project group, but is this a reasonable description of the compliance
process?

 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.

The specifics are (roughly) OpenGL is used only in OpenGL ES format on
ARM. This means that there can be different OpenGL renderers and an
application written against one rendering backend will not work with
another rendering backend. To reach the point where we can specify
renderers, we'll need to determine if in MeeGo IVI we want to be
OpenGL ES compliant or OpenGL compliant. This decision has
implications for the different architectures so needs to be carefully
addressed. I think it would be difficult to end up in a situation
where one platform is specifying OpenGL and the other OpenGL ES in the
same vertical, though it probably could be managed.

 Hope this helps.

Yes, a lot! Thanks.

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

[Jeremiah Foster]

On Sat, May 7, 2011 at 3:47 PM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
 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.

Okay, that clears things up for me.

 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.

That makes sense especially in light of recent events the last six months or so.

 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

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.

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

Good to know.

 (we shouuld probably trim the number of lists this goes to;

Trimmed MeeGo-Architecture from CC list, trimmed individuals from the
CC list. I'd like to keep this on IVI as well since I think we're
going to begin to focus a bit more on our IVI profile and I hope that
this discussion can be part of that work.

 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)


Great. :-)

Thanks very much for your participation Mats, very useful.

Regards,

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

[Jeremiah Foster]

On Sat, May 7, 2011 at 5:52 PM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
 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.

A key distinction. Thanks for clarifying.

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

[Jeremiah Foster]

On Tue, May 3, 2011 at 10:43 PM, Wichmann, Mats D
mats.d.wichm...@intel.com wrote:
 meego-dev-boun...@meego.com wrote:

 http://www.meego.com/Quality/Compliance_Implementation

 hope that's of some use... and of course here too
 comments are more than welcome.

That is giving me a 404 error currently.
___
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 source building error

[Jeremiah Foster]

On Mon, Apr 25, 2011 at 11:23 AM, venkatesh aeturi@gmail.com wrote:

 Hi,

 We are trying to build the meego source code using kickstart file:

 For building using kickstart file we are following the procedure mentioned
 in
 this link: http://wiki.meego.com/Image_Creation.

 but while executing the command to create image we are getting error like
 this:

 Error: failed to create image : History:
 - [|] Error trying to read from
 '
 http://download.meego.com/snapshots/1.1.99.2.20110412.6/repos/non-oss/ia32/packages/
 '
 - Download (curl) error for
 '
 http://download.meego.com/snapshots/1.1.99.2.20110412.6/repos/non-oss/ia32/packages/content
 ':
 Error code: Connection failed
 Error message: couldn't connect to host

 [|] Valid metadata not found at specified URL(s)


Hi Venkatesh,

Looks like a network error. Can you check that the URL you're trying to
build an image from can be reached by other means? Can you ping the URL for
example? That is a good place to start.

Regards,

Jeremiah
___
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-SDK] About Meego Handset for armv7l

[Jeremiah Foster]

Hi,

On Tue, Apr 5, 2011 at 8:32 AM, Wang Qiang k...@isb.co.jp wrote:

  Hello All,



 I am making meego handset for armv7l work on BeagleTouch board.



 I have finished porting the kernel and building the rootfs.



 I just followed the instruction in
 http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch.



 But I found that some application can not work properly.



 Such as music, video  and photo.



 So can anybody successes to run these application on the arm architecture?


Can you describe which specifica applications are not working? Or if you get
error messages, can you put them in your email?

Regards,

Jeremiah
___
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] Technical Steering Group Meeting: New Day / Time

[Jeremiah Foster]

On Sun, Apr 3, 2011 at 6:21 AM, Thiago Macieira thi...@kde.org wrote:
 On Sunday, 3 de April de 2011 01:15:18 Jeremiah Foster wrote:
 By what measure? Most of the people on the mailing lists are from
 Europe and US. Are we talking corporate head counts or developer
 participation?

 Are you on the same mailing lists as I am? There are many Chinese names
 posting on these mailing lists...

I mentioned specifically the MeeGo community list. I went through the
archives for 2011 and saw very few Asian email addresses comparative
to European and US based. Granted this is merely checking things like
some...@somecompany.in or intel.com and not some...@gmail.com. There
is no way to know just by name which region someone works in. This is
why it is so important that those who want to attend the meetings
speak up and address the community list. I saw not one single request
for meeting times on that list. Shouldn't the TSG meeting times be
supported by requests from those who want to attend? Where are those
requests?

Regards,

Jeremiah
___
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] Technical Steering Group Meeting: New Day / Time

[Jeremiah Foster]

On Sun, Apr 3, 2011 at 7:04 AM, Carsten Munk cars...@maemo.org wrote:
 On Sun Apr   3 2011 01:15:18 AM CEST, Jeremiah Foster 
 jeremiah.fos...@pelagicore.com wrote:
 On Sat, Apr 2, 2011 at 5:23 PM, Foster, Dawn M dawn.m.fos...@intel.com 
 wrote:
  On Apr 2, 2011, at 6:53 AM, Jeremiah Foster wrote
   On Fri, Apr 1, 2011 at 8:31 PM, Foster, Dawn M dawn.m.fos...@intel.com 
   wrote:

I wanted to let everyone know that we have a new time for our
Technical Steering Group meetings. While the 20:00 UTC meetings
were convenient for the Americas and Europe, it was very difficult
for people in Asia to participate.

[...]

 If you have a better time that works
  for more people than the current time, I encourage you to propose it.

   I propose we leave the time as it is until there is more open
 discussion about when these meetings should occur. I don't see a
 consensus forming around the time yet.

 Do those who plan to attend the TSG have opinions on when the meeting
 should be held?

 While it is my belief that the time schedules of the TSG meeting is up to the 
 members of the TSG to decide

The TSG unilaterally decides policy and process in MeeGo. This is a
problem because those who sit on the TSG have their company's
interests at heart (naturally.) This means that Nokia and Intel decide
MeeGo policy along with a member of the Linux Foundation. Shouldn't
that be solely the Linux Foundation instead which presumably will be
less biased? Currently its just two companies business interests that
shape MeeGo policy, one of those companies is scaling back its
contribution significantly.

 Rotating the meeting from noon pacific, 10pm finland, 3am Asia to
 11pm pacific, 9am finland, 2pm(?) asia seems like a fair time. If there is a 
 topic you're especially passionate about, it's possible to post comments on 
 mailing list/have someone be your proxy or show up - 3am in Asia made this 
 impossible for many to show up.

But there has been no presence of LG and China Mobile at the TSG
meetings. They didn't show up at the nomination which is reasonable
since it was at a ridiculous time for them. But there is no email from
Yonghui Wang from China Mobile, for example, on any of the lists I
follow or on the Handset list. Yet he's been appointed to the Handset
WG.

Your suggestion of sending mail to the list or sending a proxy to the
meetings is a good one, why hasn't this been done? In fact, why don't
we move the decision making process for the TSG to a mailing list
where people from any time zone can participate and decision making is
done in the open?

 Given we have two new players (at least) such as China Mobile and LGE in 
 MeeGo, it is fair to schedule the meetings to allow them to participate 
 properly. For those thinking they won't show up anyway, at least LGE guys 
 (plus handset WG member) already hang out in the MeeGo IRC channels, so not a 
 big leap to join another IRC channel.

If by players you mean companies that will make decisions about
MeeGo then I don't think it is in fact fair. I thought that
participation in the workgroups was going to be contribution based;
where is the contribution from these two players? What code has been
contributed? What architectural decisions made?

If positions in the workgroups are not contribution based, what are
they based on?

Regards,

Jeremiah
___
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] Technical Steering Group Meeting: New Day / Time

[Jeremiah Foster]

On Fri, Apr 1, 2011 at 8:31 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote:
 I wanted to let everyone know that we have a new time for our Technical 
 Steering Group meetings. While the 20:00 UTC meetings were convenient for the 
 Americas and Europe, it was very difficult for people in Asia to participate.

Can you explain the decision making process behind this decision?

Naturally MeeGo needs to have times that are friendly to all regions
but this decision seems to have been made without any consultation
whatsoever with MeeGo developers.

Regards,

Jeremiah
___
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] Technical Steering Group Meeting: New Day / Time

[Jeremiah Foster]

On Sat, Apr 2, 2011 at 5:23 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote:
 On Apr 2, 2011, at 6:53 AM, Jeremiah Foster wrote:

 On Fri, Apr 1, 2011 at 8:31 PM, Foster, Dawn M dawn.m.fos...@intel.com 
 wrote:
 I wanted to let everyone know that we have a new time for our Technical 
 Steering Group meetings. While the 20:00 UTC meetings were convenient for 
 the Americas and Europe, it was very difficult for people in Asia to 
 participate.

 Can you explain the decision making process behind this decision?

 Here's the logic ...

 Needless to say, scheduling global meetings is challenging,

Understood.

 I sat down with a spreadsheet marked with times for US west coast,
 western Europe and eastern Asia, which seems to be where most
 of the people working on MeeGo are located,

By what measure? Most of the people on the mailing lists are from
Europe and US. Are we talking corporate head counts or developer
participation?

 Clearly, our previous TSG meeting time, 20:00 UTC, Noon Pacific
 and 2:00 / 3:00 am in eastern Asia was making it nearly impossible
 for people from Asia to attend, and the TSG had been receiving
 requests to move the meeting to a time that was more Asia-friendly.

But wouldn't these requests show up on the mailing list? I went
through the MeeGo community list and I saw very few participants from
Asia at all. And for 2011 I saw not one single request to change the
time of the TSG meeting. If the TSG is receiving these requests, from
whom are they coming and how?

 I see this not as something that gets decided once and never
 changed. I expect these meetings to move around in time to
 share the burden of early / late meetings and to adapt to locations
 where we have people working on MeeGo.

I totally agree. But there has to be consultation with those who will
actually attend the meetings.

 Naturally MeeGo needs to have times that are friendly to all regions
 but this decision seems to have been made without any consultation
 whatsoever with MeeGo developers.


 In all fairness, I did post this new time to the mailing lists almost 2
 weeks in advance of the first meeting to give people time to ask
 questions or voice objections. If you have a better time that works
 for more people than the current time, I encourage you to propose it.

 I propose we leave the time as it is until there is more open
discussion about when these meetings should occur. I don't see a
consensus forming around the time yet.

Do those who plan to attend the TSG have opinions on when the meeting
should be held?

Regards,

Jeremiah
___
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 qemu minimal console image howto

[Jeremiah Foster]

On Fri, Mar 25, 2011 at 2:51 PM, Ameya Palande ameya.pala...@nokia.com wrote:
 On 03/24/2011 04:16 PM, ext Jeremiah Foster wrote:
 On Wed, Mar 23, 2011 at 6:07 PM, Ameya Palandeameya.pala...@nokia.com

 I have created a small howto for creating a minimal MeeGo Qemu console
 image.

 http://wiki.meego.com/Minimal_image

 Comments/Suggestions/Contributions are welcome!

 Thanks for doing this!

 A couple questions the link on the wiki goes to the repository of
 MeeGo package patterns on Gitorious but I don't seem
 meego-minimal-console there.

 My intention is to create such a pattern!

 The meego-minimal that is there has X, is
 that the one you're using?

 I used core-ia32-base-nodocs as my base kickstart file.

 Secondly, what is the goal? Is it to create the smallest set of
 packages and dependencies that will boot? How does this interact with
 MeeGo Core?

 This image can be used for debugging meego startup scripts, reducing meego
 footprint etc.

Sounds very useful. I look forward to trying it out!

Jeremiah
___
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] Architecture decisions (was Re: migration (back) to EDS)

[Jeremiah Foster]

On Wed, Mar 23, 2011 at 11:53 AM, Dave Neary dne...@maemo.org wrote:
 Hi,

 A quick note on meritocracies.

 Andrew Flegg wrote:
 According to Imad Sousou at the last TSG meeting[1], the MeeGo
 Technical Steering Group consists of two seats:

   * Intel (Imad Sousou)
   * Nokia (currently vacant after Valtteri Halla left Nokia)

 Companies typically don't have inherent merit. To cite one example, when
 Mitchell Baker left AOL (I can't remember whether she resigned or was
 laid off, it's irrelevant), AOL decided to appoint someone to take over
 from her as Chief Lizard Wrangler. But Mitchell said Hello, I'm still
 here - I don't work for AOL any more, but I'm *still* the Chief Lizard
 Wranger - and people followed her, and not the AOL appointee.

 I had understood that the TSG was made up of Imad  Valtteri, not Intel
  Nokia. Has Valtteri resigned from the TSG officially?

 Combined with appointments of companies (whose representatives, with the
 exception of Yonghui Wang of China Mobile, have not sent even one email
 to any MeeGo lists) this makes MeeGo look less  less like a meritocracy
 and more  more like a collection of corporate partnerships.

Dave before you start writing off MeeGo meritocracy you may want to
look at all the mailing lists a little more closely. For example,
MeeGo IVI had as its second post to the IVI mailing list this missive
from myself: 
http://lists.meego.com/pipermail/meego-ivi/2010-September/01.html
Pelagicore had announced itself as a contributor long before we
volunteered to officially participate by assuming roles within the IVI
project and long, long before we were confirmed in those roles by the
TSG.

From my personal perspective as Release Manager for MeeGo IVI
meritocracy is not a buzz word but the way releases get made - you
need code to release after all. I take meritocratic and open
governance quite seriously and want it to be clear that I'll always do
everything I can to ensure that is the case in MeeGo IVI.

snip

Regards,

Jeremiah
___
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 qemu minimal console image howto

[Jeremiah Foster]

On Wed, Mar 23, 2011 at 6:07 PM, Ameya Palande ameya.pala...@nokia.com wrote:
 Hi,

 I have created a small howto for creating a minimal MeeGo Qemu console
 image.

 http://wiki.meego.com/Minimal_image

 Comments/Suggestions/Contributions are welcome!

Thanks for doing this!

A couple questions the link on the wiki goes to the repository of
MeeGo package patterns on Gitorious but I don't seem
meego-minimal-console there. The meego-minimal that is there has X, is
that the one you're using?

Secondly, what is the goal? Is it to create the smallest set of
packages and dependencies that will boot? How does this interact with
MeeGo Core?

Regards,

Jeremiah
___
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] Unable to get image-creator

[Jeremiah Foster]

On Wed, Mar 23, 2011 at 11:30 PM, Perambalam, Sivaguru
sivaguru.peramba...@intel.com wrote:
 Hello,



 I get the following error while I try to download mic2 image-creator



 speramba@siva-desktop:~/Meego$ git clone
 git://gitorious.org/meego-developer-tools/image-creator.git

 Initialized empty Git repository in /home/speramba/Meego/image-creator/.git/

 gitorious.org[0: 87.238.52.168]: errno=Connection timed out

 gitorious.org[0: 2a02:c0:1014::1]: errno=Network is unreachable

 fatal: unable to connect a socket (Network is unreachable)


 Can someone tell me what’s wrong ? I suspect something related to proxy
 settings is incorrect.

Do you have a proxy? Is it letting out traffic on port 80? (That is
the port that curl will use when called by git for http.)

This seems like a network issue on your side and not anything MeeGo related.

Jeremiah
___
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] Cannot login to Gerrit

[Jeremiah Foster]

On Thu, Mar 24, 2011 at 10:46 PM, Perambalam, Sivaguru
sivaguru.peramba...@intel.com wrote:
 Hello,



 I am trying to setup my Linux host (Ubuntu 10.04 x64) for Meego dev.

 I was following instructions on http://moblin.intel.com/wiki/Umgsetup

You're using Moblin documentation for MeeGo. You may want to look at
more recent documentation for Umgsetup or even documentation for your
specific platform which appears to be Ubuntu and not MeeGo.

Regards,

Jeremiah
___
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] Building meego input methods

[Jeremiah Foster]

On Thu, Feb 17, 2011 at 2:05 PM, Gabriel M. Beddingfield gabrb...@gmail.com
 wrote:

 Hello,

 On Thursday, February 17, 2011 02:39:59 am naresh nallamothu
 wrote:
  Hi,
 
  I Installed Qt 4.7.0 on ubuntu10.04 and able to build
  libmeegotouch and meegotouch-theme components
 
  But while building input method framework and keyboard
 [snip]

 This is an off-topic post.  This mailing list is for the
 development of MeeGo.


Why is it off-topic? MeeGo Touch Framework is a part of MeeGo isn't it?
Doesn't one discuss MeeGo software on the MeeGo dev list?

Jeremiah
___
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] netbook kernel compilation

[Jeremiah Foster]

On Tue, Feb 15, 2011 at 8:45 PM, Gabriel M. Beddingfield gabrb...@gmail.com
 wrote:


 On Tue, 15 Feb 2011, Mark S. Townsley wrote:

  Hi:

 I have Meego 1.1 on a netbook and with kernel 2.6.35.3.10.3-netbook.
 I need to re-compile the kernel to turn on deadline IO.   Via zypper, I
 installed kernel-netbook and kernel-netbook-devel.   kernel-headers are
 already installed.


 No, you need to:

   $ sudo zypper si kernel-netbook

 Then the .src.rpm will be in $HOME/rpmbuild/SRPMS/

 To unpack the .src.rpm to a folder so that you can change the config,
 you'll need to do something like:

   $ mkdir sandbox/
   $ cd sandbox/
   $ rpm2cpio /path/to/kernel.src.rpm | cpio -id --no-absolute-filenames

 This will unpack all the patches, .spec files, and tarballs into the
 current directory.

 From here, what you want to do depends on whether or not you want to
 package your work.  My suggestion is to:

   1. Unpack the tarball.
   2. Patch the tarball using quilt
   3. Borrow the config file from a kernel that's close.
   4. make menuconfig
   5. make  make modules_install  make install
   6. If !satisfied GOTO 4

 After that, you can worry about creating an RPM.

 -gabriel


Good stuff Gabriel. Perhaps we can put this on the MeeGo wiki somewhere? I
haven't checked recently, it may already be there, but if it isn't I think a
page on recompiling the kernel to add functionality would be useful.

Thanks,

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

[MeeGo-dev] glibc vs. eglibc

[Jeremiah Foster]

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] glibc vs. eglibc

[Jeremiah Foster]

None of the replies answers the question, which I'll repeat; is there a
reason why MeeGo uses one and not the other?

On Tue, Feb 15, 2011 at 3:52 PM, Simon McVittie s...@collabora.co.ukwrote:

 On Tue, 15 Feb 2011 at 15:27:02 +0100, Jeremiah Foster wrote:
  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

 You seem to be slightly confused about the status of glibc vs. eglibc,
 hopefully this clarifies things:

 glibc [0] is GNU libc, primarily maintained by Ulrich Drepper at Red Hat.

 eglibc [1] is a (semi-)fork of glibc maintained by a group coordinated by
 CodeSourcery, which is more willing to accept patches, particularly those
 that support what Mr. Drepper calls embedded crap. Debian = 6.0 uses
 eglibc as its libc implementation (http://blog.aurel32.net/?p=47).

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




-- 
=
Jeremiah C. Foster
Open Source Technology Strategist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] mic2 error when building new image

[Jeremiah Foster]

Hi,

I've started to test the kickstart file I posted to meego-ivi
previously. Available here:
http://lists.meego.com/pipermail/meego-ivi/attachments/20110131/ebcedff5/attachment.obj
Note: I've removed the harbaum repo in case that was an issue, still
get the same result.

It is giving me problems when I try to build an image. Here's the
error message from mic2;

Error: failed to create image : Failed to find package 'meego-repos' :
No packages available to install

Anyone have any clues?

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

Re: [MeeGo-dev] Is MeeGo a Google product?

[Jeremiah Foster]

Hi Tomasz,

On Fri, Dec 24, 2010 at 4:53 PM, Tomasz Sterna to...@xiaoka.com wrote:
 This just came on #meego @freenode

 [16:36:26] welfg: meego is google's company?
 [16:36:39] thiago: no
 [...]
 [16:41:40] welfg: Download.MeeGo v1.1 for Netbooks (Google Chrome Browser)
 [16:41:50] welfg: This release requires accepting the Google Chrome end user 
 license agreement (EULA).
 [16:42:11] welfg: looks like made by google

 Is this the image we want to project?

MeeGo is an Open Source Linux distribution. This means that it
provides Open Source software packages conveniently installed for
those who download MeeGo or those who buy a computer with MeeGo on it.
Some of those Open Source software packages have end user license
agreements, some don't. The Google Chrome browser is one of those that
do. But the Google Chrome browser is just one of literally thousands
of applications available on MeeGo and its end user license agreement
has no bearing on MeeGo as a whole. Users can simply remove the
browser if they don't like the agreement and download another browser
whose agreement they do like, or even on without a EULA. The important
point is that MeeGo is Open Source, so you're free to customize and
add and remove whatever you want.

In no way is MeeGo controlled by Google or any other single commercial
entity. Rather MeeGo is hosted under the auspices of a foundation and
policy decisions are made by the Technical Steering Committee who make
their decisions out in the open in consultation with everyone in the
community - including yourself if you wish to participate.

So don't let someone else's casual interpretation fool you - MeeGo is
pure Open Source and not part of Google.

Regards,

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

Re: [MeeGo-dev] meegomusic issue

[Jeremiah Foster]

On Wed, Dec 22, 2010 at 1:45 PM, umang gupta umang@gmail.com wrote:
 Hi All ,

Hi Umang,

 I am using Meego - IVI platform systems on one of my hardware embedded
 boards

Can you provide some more details? Like what architecture and which
chip you are using, etc.

 I've installed following packages into file system  .

 meego-handset-music
 meego-handset-music-branding-meego

 When I click on IVI task bar for Music , Music player screen  is launched
 along with listed longs .
 But while clicking  on Play button , song doesn't played .

 Can anyone tell me how to look for this problem . Is there any guide
 available  .

One good place to start is the system logs - look in /var/log/syslog

 When I run megomusic from command line , It says :

 Running non-meego graphics system enabled  MeeGo touch, forcing native
 graphicssystem
 Invalid MIT-MAGIC-COOKIE-1 keymeegomusic: cannot connect to X server :0.0

Hard to say exactly why this is happening, but it is most surely
connected to the X server sine X uses MIT magic cookies. Google might
have more info.

Jeremiah

PS - there is an IVI specific mailing list as well if you have MeeGo
IVI specific questions.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Packaging the MeeGo stack on Debian - Use the name ?

[Jeremiah Foster]

David Greaves wrote;

snip

 We would ask you to move away from using {M,m}-e-e-{G,g}-o or any subset
 of those letters or sounds in that order, alone or in combination with
 other letters, words or marks that would tend to cause someone to make a
 reasonable connection of the reference with the MeeGo mark. We
 specifically discussed one possibility for illustration purposes – which
 is to use MG in the place of MeeGo.  We do not think that a plain text
 MG, when used in reference to the code, as in a file or project or team
 name, would cause a reasonable person to be confused.

 Can I ask how this applies to the 50+ packages which are currently part of
 meego but which are opensource and many of which we presumably expect to be
 used elsewhere?

 eg:
 libmeegochat
 libmeegotouch
 maemo-meegotouch-interfaces (!)
 meego-handset-* (21)
 meegotouch-* (14)
 meegotouchcp-* (8)
 pulseaudio-modules-meego

 I assume the MeeGo project is implicitly giving permission to use these as
 package and library names by publishing the packaging and tarballs under the
 relevant license?

We cannot make that assumption. We'll need an explicit statement on
trademark from the Linux Foundation regarding the MeeGo trademark if
the Linux Foundation wants MeeGo branded software available in
Debian. I'm no expert on the trademarking of software libraries but I
understand it is difficult to exercise trademark claims against
software libraries. In this case it would seem highly problematic for
some of the libraries, like maemo-meegotouch-interfaces, since it
would appear to be two separate trademarks (maemo and meego) with two
separate trademark holders, Nokia and LF respectively.

There appears to be some intentional bias with regard to naming, as if
the Linux Foundation wanted to specify their provenance as opposed
making these libraries more generic and thereby potentially widening
their appeal. While I understand the need for trademark to some
degree, and while the use of trademark protection for Linux seems
useful, protecting the trademark of one distro at the cost of the
other distros seems to be counter to the Linux Foundation's charter.

Clearly the fairest naming scheme would to change the library names to
something without the trademark.

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

Re: [MeeGo-dev] /proc/version

[Jeremiah Foster]

On Nov 10, 2010, at 17:19, Mark S. Townsley wrote:

 Hi:
 
 I like a way to find out the meego version from within my code.  When I look 
 at /proc/version on my MeeGo 1.1 netbook installation,
 it says  (MeeGo 4.5.0-1).How do I usually translate that number to the 
 actual MeeGo version?
 Is there another way/file I can look up this info?

I often look in /etc/meego-release

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

Re: [MeeGo-dev] Meego Bugs Access Denied

[Jeremiah Foster]

On Nov 1, 2010, at 20:03, Ryan Ware wrote:

 
 On Mon, Nov 1, 2010 at 10:51 AM, Jeremiah Foster 
 jeremiah.fos...@pelagicore.com wrote:
 
 ...snip...
 
 My understanding with most Open Source projects is that bugs would never be 
 hidden - the current policy, even if it applies to just one hardware vendor, 
 seems to be in direct contradiction to the Linux Foundation claims to 
 openness. I'd like to point out that the Linux Foundation bylaws state;  The 
 purposes of this corporation include promoting, protecting, and standardizing 
 Linux and open source software.
 
 Then your understanding is incorrect. 

Is it? 

Debian is one of the oldest Linux distros, the largest in terms of packages, 
and the most successful in terms of deployment if you count derivatives such as 
Ubuntu, Mint, etc. Here's their bug policy: 
http://www.debian.org/social_contract from which I quote; We will keep our 
entire bug report database open for public view at all times.

Fedora is also a large, highly successful Linux Distro, here is their policy: 
http://fedoraproject.org/wiki/Security/TrackingBugs I'll highlight a quote: 
Parent bug is publicly viewable. 

The GNU project which comprises a significant portion of any Linux 
distribution, including MeeGo, also has an open bug policy. 

Gentoo's policy has an exception that they have a security embargo: 
http://www.gentoo.org/security/en/vulnerability-policy.xml Gentoo's policy is 
reasonable because they are aiming to protect their users from known zero day 
exploits which may directly affect users. It is interesting to note that other 
Open Source projects have also considered this policy, but rejected it as 
offering no real security advantage.

I don't think my understanding is incorrect; Open Source projects have open 
bugtrackers. 


 As I've previously explained the vast majority (if not all) highly visible 
 open source projects keep security issues closed until they are resolved.

I don't think anyone has a problem with a MeeGo Bugzilla security embargo as 
long as that embargo is clearly explained, and reaches a consensus in the 
community. My understanding was that the policy that was in place in MeeGo's 
bug tracker met neither of those conditions.

Jeremiah

 
 That said, there is no reason I see that this particular bug should have been 
 anything but open.
 
 Ryan


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

Re: [MeeGo-dev] meego account in IVI image

[Jeremiah Foster]

On Oct 31, 2010, at 19:29, Mark S. Townsley wrote:
 
 Hi
 
 I just brought up the IVI image but it seems to be different from the netbook 
 one in that I was not given the 
 option to create user accounts.
 It comes with a meego user login.   Does anyone know what is the password 
 for this meego account?

As previously mentioned, the password is meego. Note that you can change this 
if you create your image from a kickstart file. In the kickstart file there is 
a field where you can specify a password.

Regards,

Jeremiah

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

Re: [MeeGo-dev] Meego Bugs Access Denied

[Jeremiah Foster]

On Nov 2, 2010, at 11:48, Jussi Kukkonen wrote:

 On 11/02/2010 11:43 AM, Jeremiah Foster wrote:
 On Nov 1, 2010, at 20:03, Ryan Ware wrote:
 
 On Mon, Nov 1, 2010 at 10:51 AM, Jeremiah Foster
 jeremiah.fos...@pelagicore.com wrote:
 
 My understanding with most Open Source projects is that bugs would
 never be hidden - the current policy, even if it applies to just
 one hardware vendor, seems to be in direct contradiction to the
 Linux Foundation claims to openness. I'd like to point out that the
 Linux Foundation bylaws state;  The purposes of this corporation
 include promoting, protecting, and standardizing Linux and open
 source software.
 
 Then your understanding is incorrect.
 
 Is it?
 
 Debian is one of the oldest Linux distros, the largest in terms of
 packages, and the most successful in terms of deployment if you count
 derivatives such as Ubuntu, Mint, etc. Here's their bug policy:
 http://www.debian.org/social_contract from which I quote; We will
 keep our entire bug report database open for public view at all
 times.
 
 Fedora is also a large, highly successful Linux Distro, here is their
 policy: http://fedoraproject.org/wiki/Security/TrackingBugs I'll
 highlight a quote: Parent bug is publicly viewable.
 
 The GNU project which comprises a significant portion of any Linux
 distribution, including MeeGo, also has an open bug policy.
 
 Gentoo's policy has an exception that they have a security embargo:
 http://www.gentoo.org/security/en/vulnerability-policy.xml Gentoo's
 policy is reasonable because they are aiming to protect their users
 from known zero day exploits which may directly affect users. It is
 interesting to note that other Open Source projects have also
 considered this policy, but rejected it as offering no real security
 advantage.
 
 I don't think my understanding is incorrect; Open Source projects
 have open bugtrackers.
 
 It is incorrect, at least with regard to distros.

Your statement has no basis in fact. There is not a single closed bug in 
Debian's BTS. Please point to a closed bug in Debian to back up your statement.

 There are various ways
 to deal with this and a very common approach is to keep selected bugs
 closed (this is also a requirement for access to various vulnerability
 information sources).

If you are referring to the Vendor-sec mailing list: 
http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec then yes that is 
one of the various ways to deal with security bugs. But this list is not 
closed; The mailing list is unmoderated, but requests for membership are 
manually vetted to ensure that only the target audience may join. This is done 
to avoid leaking the potentially sensitive discussions, as vendor-sec members 
often have access to information about vulnerabilities before they become 
public

 As an example, these distros embargo security information in some form:
 * Debian

There is a security team inside Debian and the Debian Developers reference 
document refers to the handling of security critical bugs; 
http://www.debian.org/doc/developers-reference/pkgs.html#bug-security To quote 
from that; http://www.debian.org/doc/developers-reference/pkgs.html#bug-security

If this is what you are referring to, please note this is NOT the BTS, this is 
the separate Security Tracker, and even here that secrecy is limited.

 * Gentoo

I already identified Gentoo as imposing an embargo.

 * Fedora
 * Ubuntu
 * Mint
 That's five out of the five distros you mentioned. At least four last
 ones use a bug tracking system in the same way meego does.

 If a bug is open in Debian, it is most likely open in Ubuntu since Ubuntu is 
quite close to Debian, and Mint is based on Ubuntu (moving to Debian) so that 
point is moot too. Fedora's policy needs more scrutiny, I'm not convinced it is 
as you say it is, I think it is closer to Debian's policy.

 Whether MeeGo bugzilla is the right place for other limited access bugs
 may be debatable. Arguing that vulnerability information embargo is an
 uncommon policy among distros is just silly.

That is not the argument. The argument was whether or not to close bugs in the 
bug tracking system. I argue this is the wrong thing to do. I also concede that 
some form of security embargo is warranted. These two positions are not 
mutually exclusive.

Jeremiah



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

Re: [MeeGo-dev] Meego Bugs Access Denied

[Jeremiah Foster]

On Oct 29, 2010, at 22:45, Auke Kok wrote:

 On 10/29/10 02:28, Igor Stoppa wrote:
 Hi,
 On Fri, 2010-10-29 at 09:22 +0100, ext Andrew Flegg wrote:
 The lack of information can lead to the
 frustration in this thread - especially if there are still mistakes
 slipping through (such as #8474).
 
 Let's try to clarify some aspect that seems to be going under the radar.
 Here we are dealing also with 3rd party IPs, including - mostly - HW/FW.

There is no place for third party non-OSI approved software or firmware in an 
Open Source bugtracker. Please see bug 9525 which blocks the MeeGo Meta 
Openness bug 4898  (http://bugs.meego.com/show_bug.cgi?id=9525)

Having third party firmware of software opens MeeGo up to patent litigation. 

 While the goal is obviously to be as open as possible, it's a fact hat
 some _HW_ companies might get - rightfully - touchy if their data is
 published in an uncontrolled way.

This seems incompatible with Open Source development. I don't think this is in 
fact a reasonable request and I don't think it should be honored. Intel and 
other companies are being very open with the MeeGo software and hardware, it 
seems completely unfair that bugs can't get fixed due to hardware vendor's 
unreasonable demands. Filing bugs is clearly within a user's rights, after all, 
it is their hardware and they should be allowed to get it to work and a bug 
report is a fundamental part of this.

Furthermore, I am certain that at least some of the closed bugs in Bugzilla are 
also filed in other places, so you are not closing the bugs or the issues with 
the buggy firmware, you are only closing off the opportunity for someone to fix 
the issue for you in MeeGo. You will now be dependent on other software 
projects, like Debian (who never close bugs) because people will actually be 
able to see the bugs in Debian's system and fix them there instead of in MeeGo. 
 
 There are processes in place to ensure that data is published in a
 controlled way, but they take time.

Is this policy part of an official Linux Foundation document? My understanding 
with most Open Source projects is that bugs would never be hidden - the current 
policy, even if it applies to just one hardware vendor, seems to be in direct 
contradiction to the Linux Foundation claims to openness. I'd like to point out 
that the Linux Foundation bylaws state;  The purposes of this corporation 
include promoting, protecting, and standardizing Linux and open source 
software. 
 
 #8474 was a mistake in the sense that it should have not gone public at
 all - at least not now. And the following glitch closed-public-closed
 was another thing that could have been avoided.
 
 this is a rather misrepresentation of the problem.
 
 bug #8474 is in fact titled:
 
 ===
 Bug 8474 - [1.2] org.oFono service can not be found on Dbus with 
 voicecallhistory issue
 ===
 
 There is nothing about this bug that should have been private to begin with. 
 The real issue is that information was entered into this bug report that was 
 irrelevant that forced me to reclose the bug (although I still highly object 
 to this bug being closed).
 
 here is the original core content of bug 8474:
 
 ===
 1.Boot image to home screen. Check the default configuration of
 /etc/ofonod/modem.conf [phonesim] section is commented.
 2.Launch dialer, the dialog Fail to connect to org.ofonod.Manager: is ofonod
 running? pops up while ofonod process is running.
 3.Uncomment the [phonesim] section and make sure address is 127.0.0.1.
 4.Dialer is uable to launcher from quick launch bar.
 ===
 
 nothing in here that can't be disclosed and doesn't accurately describe the 
 bug to begin with.
 
 This bug should have been filed properly without referencing content that 
 couldn't be disclosed, then the whole discussion would have never happened.
 
 Auke
 

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

Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion

[Jeremiah Foster]

On Oct 27, 2010, at 07:07, jarmo.k...@nokia.com jarmo.k...@nokia.com wrote:
 
 1.1 schedule for hardfp would be *very* challenging since we are still 
 working in order to get hardfp toolchain working. After that testing (incl. 
 performance testing) can be start. 
 
 From: Arjan van de Ven [ar...@linux.intel.com]
 Sent: Tuesday, October 26, 2010 10:24 PM
 On 10/26/2010 12:18 PM, Quim Gil wrote:
 On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote:
 This is why I was wondering why we're not using hardfp *now* for 1.1.0.
 
 We shouldn't be breaking binary compatibility.
 
 We shouldn't be softp either.
 Just reminding the obvious, but as for today there is no major MeeGo
 products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras
 for MeeGo. Even the MeeGo SDK itself is in its first iterations.
 
 which will change once we release 1.1.
 
 I fully argee with Quim here, we have to act on this now, when the installed 
 base does not exist.

It does seem an advantage to act now in order to impose the least amount of 
disruption possible on the installed user base. 

Can we sketch out a roadmap? It seems evident that a MeeGo 1.1 hardfloat is 
difficult. How difficult will a 1.2 be? And if the toolchain is prepared for 
building a hardfloat 1.2, then we should build in parallel, as if this was a 
separate port, correct? (This is in fact what Debian does, their ARM hardfloat 
is essentially a separate port.) 

If this path is the appropriate path then we might need a target end of life of 
the softfloat ARM port, how do we identify that?

 I see Arjan's point made from an architecture consistency point of view
 - but from a marketing point of view 1.2 and following releases will be
 a lot more used and scrutinized than 1.1.x releases. If this soft-hard
 break is unavoidable then it seems that now it will create a lot less
 hassle than in 6 months or later.
 
 based on the discussion here... the technology is at least several
 months away.

There is work underway already. Already ~80% of the main Debian archive is 
being built against the hardfloat port.
https://wiki.linaro.org/Linaro-arm-hardfloat
 
 and breaking compatibility in an upgrade is even worse than breaking it
 n a new release...
  really.

Clearly MeeGo ought to be following your advice. But I think that you may be 
persuaded if we take into account;

1. There is a significant set of optimizations in the hardfloat ARM port [0.]
2. ARM softfloat will be less relevant once a hardfloat is present
3. Much of the ARM Linux community is already moving in this direction

0. http://www.powerdeveloper.org/forums/viewtopic.php?t=1821

 We need to address those concerns by talking bout this openly.
 According to best experts this will take some time, so unfortunatelly
 it seems that we will have 2 ARM architecture builds towards 1.2, 
 and we can only make final judgement when we know that hardfp
 will work as intended.

This seems like a logical path forward. Yes there will be some difficulty, but 
this seems the only way to ensure that ARM devices are performant as soon as 
possible. 

Jeremiah

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

Re: [MeeGo-dev] Trademark compliance, name usage, etc.

[Jeremiah Foster]

On Sep 23, 2010, at 18:06, Ibrahim Haddad wrote:

 Hi Jared,
 
 I am confirming that we were contacted by RH and you were cc-ed on the 
 emails. We agreed on the wording of your spin (which is inline with the 
 trademark policy and guidelines [1]), and approval was given conditional to 
 meeting the compliance requirements.  
 
 As for the remark on connman, my personal thoughts on this are the following: 
 MeeGo compliance is stack based meaning you need to use MeeGo Core as-is - 
 you need to use same base code, same package format, same package 
 naming/versionning, etc. You can apply patches against components in the 
 MeeGo Core stack and you can add new components but not to replace  existing 
 MeeGo components.

This falls under section 5 of my handy compliance FAQ:

Q: Okay, I'll build in OBS and against your APIs, can I get in MeeGo?
A: We already have an app that does what yours does.

Jeremiah

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

Re: [MeeGo-dev] [compliance] Different view on app compliance

[Jeremiah Foster]

On Sep 19, 2010, at 10:57, Carsten Munk wrote:

 No, my hope is that compliance would discourage this behaviour and
 make people push APIs to Staging and take responsibility for them
 instead (security fixes, updates, etc)
 
 Can applications using non-OSS libraries from 3rd parties be compliant?
 
 No - if someone uses for example Nokia Ovi Store specific APIs, how
 can this expect to run on all MeeGo devices?

Except of course if Nokia uses Nokia specific APIs, then it is automatically 
compliant.

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

Re: [MeeGo-dev] [compliance] Different view on app compliance

[Jeremiah Foster]

On Sep 19, 2010, at 12:31, Carsten Munk wrote:

 2010/9/19 Adrian Bunk b...@stusta.de:
 Could I ask for how you would word the rules and at the same time,
 make this type of compliance testable by a machine? - keep the eye on
 the ball, MeeGo compliant applications that is stated as compliant for
 MeeGo version X, optionally only profile Y, must install without
 errors on MeeGo version X, profile Y if specified.
 
 Let's get a hands-on approach for this.
 
 I'd suggest to add library repositories:
 - libraries in a library repository have to fulfill compliance rules
  similar to applications
 - a repository must specify which library repositories it uses
 - a library can only be in one repository (unless it changed the soname)
 
 
 Right - I agree with the first 2, but the third one is difficult, how
 can you prove it's only in one repository?
 
 I'm thinking compliance only allowed based on signature and a central
 API registry with public keys/certificates..

How on earth will you do that? That doesn't sound like something that will 
scale.

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

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

[Jeremiah Foster]

On Sep 16, 2010, at 08:12, Attila Csipa wrote:

 On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark mark.skarpn...@intel.com 
 wrote:
 Yes, that's exactly what we expect.  One version for every MeeGo compliant 
 device.  Device-specific tailoring will be the exception - it's expensive, 
 time consuming, and results in an app that will run on fewer devices.
 
 This certainly makes sense from a developer/vendor standpoint. Unfortunately, 
 I'm not so sure about the user angle as they don't care if an app works on 
 OTHER devices than their own.

I disagree. Users want to move their photos easily from their phone to their 
TV, move their phone calls from the phone to the car, etc.

 The Symbian experience so far is suggesting that quite a few developers 
 believe that having generic apps able to run on a hundred different devices 
 are a dubious match for apps tailored to maximize user experience on a small 
 number of bestseller devices.

If you have _one_ OS  with _one_ well defined API, you will gain a great deal 
from a developers standpoint.

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

Re: [MeeGo-dev] mic and building images

[Jeremiah Foster]

On Sep 8, 2010, at 15:09, Carsten Munk wrote:

 2010/9/8 Jeremiah Foster jeremiah.fos...@pelagicore.com:
 Hello,
 I've tried the mic2 tool on three separate distros now: OpenSuSE, Debian
 testing, and MeeGo itself. It works on none of them.
 I have reported bugs on all these issues, both upstream and in the distro
 itself.
 I'd like to know a definitive platform upon which mic2 will work to build
 MeeGo images. Is there a distro that has been tested extensively? Is there a
 preferred distro?
 Thank you,
 Jeremiah
 
 For further discussion, could you elaborate a bit more than 'works on
 none of them'?


Error in Debian Testing: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594590
Error in OpenSuse: http://bugs.meego.com/show_bug.cgi?id=6096#c3
Error in MeeGo IVI: http://bugs.meego.com/show_bug.cgi?id=5812

There has been bug fixes and updates, especially to the first and second bugs, 
no movement on the last bug however. 

What I'd like is a Know Best Practice, for example;

- Use Fedora 13
- Install mic with yum
- Call command line thusly . . .

Currently the documentation is somewhat misleading since it seems to imply that 
building images is possible on many distros. In fact testing has been rather 
light on certain distros so that building images requires a lot more work than 
just installing mic with your package manager. The path that the MeeGo 
developers use would be great to know so it can be copied.

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

Re: [MeeGo-dev] Dual Touchscreen Support

[Jeremiah Foster]

On Aug 19, 2010, at 13:25, Auke Kok wrote:
 On 08/19/2010 09:54 AM, Abraham Arce wrote:
 
 http://www.spinics.net/lists/linux-input/msg10503.html
 
 I'm not aware of any specific requirement for this, and it's really not that 
 simple per se, and several packages are involved:

I'm not aware of a specific requirement at the moment, but I can imagine an IVI 
situation where you'd want to run MeeGo on two screens in the two headrests of 
a car.

Jeremiah

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

Re: [MeeGo-dev] [MeeGo-SDK] Meeting about gcc/toolchain/sdk/cross-compiler

[Jeremiah Foster]

On Aug 9, 2010, at 11:57, Jan-Simon Möller wrote:

 Hi all!
 
 There will be a meeting about the toolchain/sdk/cross-compilers on

I'm sorry I couldn't attend this meeting. Are there any meeting minutes, IRC 
log, or similar?

Thanks!

Jeremiah

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

[MeeGo-dev] ARM softfloat or hardfloat?

[Jeremiah Foster]

Hello,

What is MeeGo planning to do with regards to ARM hardfloat or 
softfloat? What is the rationale behind the choice?

Some background information here: 
http://wiki.debian.org/ArmHardFloatPort

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

Re: [MeeGo-dev] MeeGo IVI release

[Jeremiah Foster]

On Jul 29, 2010, at 21:35, Arthur Hsiao wrote:

 http://www.eetimes.com/electronics-news/4204956/MeeGo-in-vehicle-win
 
 Anyone gets more details?  When can a full-blown MeeGo IVI be released to 
 public?

GENIVI is planning a release in October code-named 'Apollo'. That release will 
be followed six months later by another release since GENIVI is planning to 
release every six months. Currently there are ongoing discussions between the 
Linux Foundation and the GENIVI Alliance that will shape the nature and depth 
of the collaboration between the two projects. Once those details are hammered 
out - and there is a lot to discuss - a more public and official announcement 
will be made.

Warm regards,

Jeremiah

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

Re: [MeeGo-dev] Difference between MeeGo and Android?

[Jeremiah Foster]

On Jul 26, 2010, at 19:33, Felipe Contreras wrote:

 fathi.bou...@nokia.com wrote:
 * MeeGo: Intel, Nokia
 
 http://www.linuxfoundation.org/news-media/announcements/2010/07/meego-software-platform-chosen-genivi-alliance
 
 That's a very interesting announcement indeed, but we still have to see
 how it translates to actual collaboration.

In GENIVI we're taking collaboration very seriously. The GENIVI alliance get's 
it, they understand Open Source, and lots of work that the alliance is doing, 
indeed, has already done, is being done upstream. Ofono for example is a 
project that GENIVI has contributed too. 

We also plan to work very closely with the IVI profile in MeeGo. I'll be at 
DebConf10 and LinuxCon Boston if anyone on this list wants to stop by and talk 
about opportunities to work on the computers in the next generation of cars.

Warm regards,

Jeremiah

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

Re: [MeeGo-dev] nfs package in meego ?

[Jeremiah Foster]

On Jul 26, 2010, at 07:25, Carsten Munk wrote:

 2010/7/23 Auke Kok auke-jan.h@intel.com:
 On 07/23/10 14:23, adhyas.avas...@nokia.com wrote:
 
 Do we have the nfs-utils and nfs-utils-lib package for MeeGo 1.0 somewhere
 in the repo? Can you please point me to it?
 I tried installing a public rpm but that is not sufficient to configure
 the nfs server on MeeGo.
 
 neither, MeeGo doesn't support NFS, nor do we have the needed kernel options
 enabled or tools packaged.
 
 There is one quite legit use for NFS, which is general handset
 development. Traditionally many porters use NFS as boot medium for
 their boards to not constantly rewrite NAND or SD cards with system
 images on them, effectively speeding up their development cycles.
 
 For non-netbook configurations like handsets or development boards,
 modules may be considered useful to have enabled. Chances are though
 that board porters will just enable NFS in their kernel
 configurations.
 
 This doesn't mean the utils have to be there, at least in N900, we use
 busybox to fullfill that within a boot initrd.

There are always going to be use cases for NFS, especially from developers or 
sysadmins who are more familiar with NFS than something else. But I think as 
far as the current discussion goes, Arjan is making sense. sshfs can pretty 
much replace NFS plus it gives you encryption for free! It has somewhat less 
complexity that NFS, and has somewhat fewer dependencies. I use it to develop 
on my N900 and don't miss NFS at all. 

I'm not fully convinced there is a need to maintain NFS in MeeGo and I think 
everyone would prefer less complexity so perhaps we can define an end user use 
case which clearly demonstrates the need for NFS that sshfs doesn't fill?

Jeremiah

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

Re: [MeeGo-dev] repo.meego.com down?

[Jeremiah Foster]

Works for me.

Jeremiah

On Jul 20, 2010, at 14:31, Andrew Savory wrote:

 Hi,
 
 repo.meego.com appears to be down. Any idea when it will be back?
 
 Also - is there a web page / twitter feed / rss feed where we can get status 
 of MeeGo infrastructure?
 
 
 Thanks,
 
 Andrew.
 --
 asav...@apache.org / cont...@andrewsavory.com
 http://www.andrewsavory.com/
 ___
 MeeGo-dev mailing list
 MeeGo-dev@meego.com
 http://lists.meego.com/listinfo/meego-dev


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

Re: [MeeGo-dev] Suggestions to Meego site Administrators / Developers

[Jeremiah Foster]

On Jul 14, 2010, at 22:06, Auke Kok wrote:

 On 07/14/10 06:44, Alex Butum wrote:
 1) Why Meego Project does not provide alternative downloads by
 Bittorrent protocol ? The way to download Meego now is *amazingly
 SLOW* and unreliable; using BitTorrent protocol would be better for
 data integrity and speed.
 
 We have discussed using alternate methods, including frontend hosting on 
 akamai/amazon cloud (like we do now for official releases) and using 
 bittorrent.

I would like to ask that we not use Akamai and Amazon EC2. My reasons are 
technical and strategic;

1. Akamai and Amazon use proprietary technology which conflicts with 
Free Software practices
2. Akamai and Amazon have latency issues, bandwidth issues and in 
general are not as good as other solutions

There is an excellent tool called MirrorBrain which is widely used, hooks into 
the OBS, works really well, can trivially be extended both with new mirrors and 
with new code, costs significantly less that Akamai, and has an attractive 
license. Why not consider using that?

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

Re: [MeeGo-dev] Beagleboard support HDMI or TV/Out?

[Jeremiah Foster]

On Jul 13, 2010, at 22:38, Cristopherson Torres Martinez wrote:

 Hi,
 
 I have been able to boot Meego on a Beagle C2 using either of the
 following instructions.

Can you get your hands on a later version of the Beagle board? The C4 for 
example has DVI-D output which you can use with a DVI-D to HDMI cable for 
output on a TV.

Jeremiah

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

Re: [MeeGo-dev] meego-dev or meego-sdk?

[Jeremiah Foster]

On Jul 9, 2010, at 00:42, Foster, Dawn M wrote:

 We've been seeing quite a few application developer emails on the MeeGo-Dev 
 mailing list that would more appropriately posted on MeeGo-sdk. As a quick 
 reminder, here is how we're using these 2 mailing lists.
 
 MeeGo-Dev:
 The MeeGo-Dev list is mainly for development of the core MeeGo platform and 
 development of the related UXs. 
 
 MeeGo-SDK:
 Application development, SDK, API, Xephyr / chroot environments, 
 virtualization and related discussions should posted on the MeeGo-sdk mailing 
 list (or application developer forum if you prefer forums 
 http://forum.meego.com/forumdisplay.php?f=3)

Is the omission of the MeeGo Packaging list conscious?

Jeremiah

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

Re: [MeeGo-dev] Optimization flags considered harmful (Was Re: After handset day one - a plea for openness)

[Jeremiah Foster]

On Jul 8, 2010, at 18:21, Carsten Munk wrote:

 To deal with this in terms of compliance, I suggest we establish a
 MeeGo oompliance baseline for SDKs and community OBS to follow for
 applications. It doesn't have to be what Core is compiled for in
 MeeGo.com if we want to encourage MeeGo use on many different
 processors and devices.
 
 Your thoughts?

I'm not certain that creating a compliance path for SDKs and community build 
systems is the way to go - it seems like an undue burden to force compliance 
upon the tools a developer uses. Compliance should be centered around APIs 
perhaps instead, although even this is kind of hard. If you change a part of a 
low-lying API, for example, that can impact dozens of applications.

In any case, shouldn't there be a separate mailing list for compliance? There 
is a lot of strategy and standards discussion there that may be orthogonal to 
development.

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

Re: [MeeGo-dev] MeeGo deliberately incompatible with other distros

[Jeremiah Foster]

On Jul 9, 2010, at 20:01, Samir Faci (Dev) wrote:

 It's not like debian packages for debian are just like the ones for
 Ubuntu.  *shurg*.  

Debian derived systems often need to make no changes at all to a debian package 
for it to 'just work'. 

Jeremiah

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

Re: [MeeGo-dev] After handset day one - a plea for openness

[Jeremiah Foster]

On Jul 7, 2010, at 18:28, Thiago Macieira wrote:

 On Wednesday 7. July 2010 14.22.56 Nicola Mfb wrote:
 Just for example and fun, there is an alpha totally free linux
 distribution (coded in the spare time by very few guys where I
 contribute) that runs on the OpenMoko freerunner since september 2009
 and uses Qt (over X11) and above all ofono (and now qt-mobility versit
 too, to import contacts) while we cannot do it just on the n900 (last
 time I checked) due to closed csd, pulse audio routing, etc.! is so
 frustrating and incredible on a device from a vendor that develops
 ofono itself in this new open meego age!!!
 
 It's not incredible.
 
 It just means ofono is a good piece of software.
 
 Kudos to Marcel and other contributors.

Yeah, I'd have to agree with Thiago here, kudos to the ofono guys and gals!
Also, if you look closely, I strongly suspect you'll see lots of nokia.com and 
intel.com email addresses in the commit logs for ofono.

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

Re: [MeeGo-dev] After handset day one - a plea for openness

[Jeremiah Foster]

On Jul 8, 2010, at 17:46, David Greaves wrote:

 On 07/07/10 00:32, Dirk Hohndel wrote:
 Again, the default builds that we provide are optimized for Atom - I
 don't think there's anything wrong with that. It's fairly straight
 forward to build for other platforms if you need that, but I think it is
 not a reasonable request that we shouldn't optimize for our platform.
 
 I think this is one area where people really need to think carefully about 
 whether they have an Intel, Nokia or MeeGo hat on. The wes in that sentence 
 are a tad ambiguous.
 
 Clearly when *Intel* ship MeeGo-on-atom it should be polished, focused and 
 optimised.
 
 However, MeeGo makes many claims to be open and inclusive; shouldn't it seek 
 to minimise barriers to entry?


Furthermore, when people make the claim that it is 'cross-platform' is that a 
valid claim if MeeGo does not work identically well on ARM as it does on Atom? 
If Nokia and Intel are not responsible for the effective working of MeeGo on 
the ARM platform, then who is?

Jeremiah

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

Re: [MeeGo-dev] MeeGo cross toolchain usage

[Jeremiah Foster]

On Jul 7, 2010, at 14:55, Jan-Simon Möller wrote:

 On Wednesday 07 July 2010 14:03:43 Jeremiah Foster wrote:
 On Jul 7, 2010, at 11:31, Jan-Simon Möller wrote:
 To clarify: these are the basic bits of a x86-ARM cross toolchain for
 using on a x86 meego host. Building ARM _inside_ OBS works different.
 
 Are there proprietary binaries on the OBS that builds ARM v7?
 No! All is there, all is open. Don't mix 'different' with 'proprietary'.

I don't think I am confusing these two.

 We need more documentation - this is WIP.

So if there is incomplete documentation, how would I know what 'different' 
means?
 
 And if yes,
 is it then impossible to duplicate the same build toolchain that exists
 inside the OBS for MeeGo?

 If you're on a interlinked OBS, you'll inherit the cross-compiler.
 If you're cloning, then you need to do an _exact_ clone.
 
 An high level overview is:
 
 armv5 and armv7 use a cross-compiler build as part of the MeeGo Core and from 
 the gcc package (currently in Trunk:Testing, gcc+gcc-cross in current Trunk).
 This cross-compiler comes in 2 flavours (same applies to binutils):
 * cross-armv5tel-gcc.i586.rpm (cross-armv7l-gcc.i586.rpm)
   -- this is a cross-compiler running on a MeeGo i586 host compiling for ARM
  using /opt/cross as prefix and /opt/cross/target-tuple/sysroot as
  sysroot. We don't use this in OBS.
 * cross-armv5tel-gcc-accel.armv5tel.rpm (cross-armv7l-gcc-accel.armv7l.rpm)
  -- this is a cross-compiler designed for OBS internal compilation 
  it has a specialized prefix, uses changed -rpath. Note the
  armv5tel.rpm/armv7l.rpm - these claim to be ARM binaries (by
  intention), but actually they're i586.
  -- this compiler (given all dependencies are installed) will also run in an 
 chrooted ARM rootfs. This is then very similar to scratchbox, with less 
 sb-ishms. This is what 'osc build' will download/install to the build
 chroot, btw.


So conceivably we could take this compiler (with dependencies) and create a 
chroot and build for ARM v7 in that chroot?

Jeremiah

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

Re: [MeeGo-dev] Technical Steering Group Meeting 9 June 2010 at 19:00 UTC

[Jeremiah Foster]

On Jun 9, 2010, at 22:44, Foster, Dawn M wrote:

 On Jun 8, 2010, at 1:53 PM, Foster, Dawn M wrote:
 
 I wanted to remind everyone that we have a Technical Steering Group Meeting 
 (TSG) scheduled for tomorrow, 9 June 2010 at 19:00 UTC in #meego-meeting on 
 IRC. 
 
 For more details and meeting logistics, you can visit 
 http://wiki.meego.com/Technical_Steering_Group_meetings
 
 Agenda:
 * MeeGo Project Structure / Roles
 
 
 
 In the meeting today, we talked about the project structure, roles and 
 nominations for MeeGo listed here: http://meego.com/about/governance

Broken links on that page: 
- http://meego.com/governance/distribution-development
- http://meego.com/governance/quality-assurance
- http://meego.com/governance/

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

Re: [MeeGo-dev] MeeGo Summit - Structured brainstorming format in the form of BOFs and Wiki Specs.

[Jeremiah Foster]

On Jun 3, 2010, at 14:21, David Greaves wrote:

 On 03/06/10 10:05, Dave Neary wrote:
 
 
 Dirk Hohndel wrote:
 On Sat, 29 May 2010 02:04:23 -0600, Andrew Fleggand...@bleb.org  wrote:
 Firstly, this would probably be best on the forum - or meego-community

[snip]

 GET THE BLOODY THING FIXED!
 
 Please :)

Well said! 

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

Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal

[Jeremiah Foster]

On May 21, 2010, at 12:14 AM, David Greaves wrote:
 Dave Neary wrote:
 
 Warren Baird wrote:
 On Thu, May 20, 2010 at 3:28 PM, David Greaves da...@dgreaves.com wrote:
 
 OTOH a wiki has a 'talk' page; the ability to trivially host 'draft' 
 versions of
 pages nearby; email notification of changes; and I've proposed a reasonable
 process that, together with the great audit trail that a wiki offers should
 trivially identify and allow reversion of any unwanted edits.
 I think it makes perfect sense to *develop* policy on the wiki, for
 all of the reasons you mention...   I'm less convinced it makes sense
 to use it to host published, fairly static policy docs that you
 definitely *do* not want people changing, accidentally or otherwise...
 
 Your joint proposal to use the wiki for drafting  revisions, and the
 CMS for agreed final policy is very wise.
 
 OK, I'm happy with the wiki is authoritative until an alternative (drupal)
 solution is in place

This is contrary to current best practices. Wikis should be authoritative, no 
CMS required. Anyone who defaces the wiki ruins their public reputation which 
seems both logical and effective. Adding a layer of bureaucracy to the wiki 
seems unnecessary.

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

Re: [MeeGo-dev] MeeGo compliance

[Jeremiah Foster]

On May 19, 2010, at 11:04 AM, Dave Neary wrote:
 
 Quim Gil wrote:
 Ibrahim from The Linux Foundation is driving the MeeGo compliance
 definition. Hopefully we can have a first version of the guidelines
 published soon, currently under private drafting and review to sync
 legal, technical, marketing and resourcing aspects.
 
 This is the kind of thing I think could benefit enormously from being
 written  revised in the MeeGo wiki. It's of vital importance to all
 contributors, and yet only a privileged few will see anything but a
 finished product/fait accompli.

Well said. I might add that it is imperative that the compliance path be fully 
communicated - otherwise being compliant will be nigh on impossible.
 
 In fact, I think that the community as a whole would benefit from being
 exposed to (and forced to take into consideration) the legal, technical,
 marketing  resourcing aspects of compliance, since I'm sure that these
 are not things most people think about at all :)

Spot on Dave.
 
 Ibrahim, is it possible for you to publish whatever draft you have now,
 even if it's protected for writing, and integrate any comments 
 feeedback into the page as you get them? Or, perhaps, prepare a draft
 for review by legal here, based on what you have now, to avoid excessive
 to-and-froing?

Do we know if Ibrahim received this request? I don't see his reply to the list.

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

Re: [MeeGo-dev] MeeGo compliance

[Jeremiah Foster]

On May 24, 2010, at 2:13 PM, David Greaves wrote:

 On 24/05/10 11:11, Jeremiah Foster wrote:
 
 On May 24, 2010, at 10:48 AM, David Greaves wrote:
 
 On 23/05/10 20:32, Graham Cobb wrote:
 On Wednesday 19 May 2010 18:50:01 Jeff Licquia wrote:
 
 (...)
 
 Debian:5.0 x86/ARM
 
 Where are you getting the ARM V7 libs to build for debian?
 
 $ cat $davids_mail | grep -i v7 | wc -l
 0
 
 Jeremiah, it feels like I offer you the moon and you complain because it's 
 not made of cheese...

while ($not_done) {
sleep(10);
$proj-ask_for_sources();
 }
 
Open Source is all about getting others to do your work for you.  =)  

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

Re: [MeeGo-dev] Btrfs as default file system

[Jeremiah Foster]

On May 19, 2010, at 4:32 PM, Lauri Leukkunen wrote:

 On 19/05/10 15:38 +0200, ext Carsten Munk wrote:
 2010/5/17 Esben Haabendal e...@dev.doredevelopment.dk:
 Sorry, but it is a bit disturbing how often Meego is mentioned as being
 an Intel architecture.  When talking about bootloader, grub and syslinux
 clearly does not cover the whole architecture.  Or is the N900/ARM
 already going to be phased out?
 
 On the other hand, they're also leaving the stage to the ARM people on
 how it can be done/is done on their side - not overstepping eachothers
 territory. Intel knows IA best, ARM guys knows ARM best.
 
 On ARM tradition seems to be a kernel in a NAND area or a kernel in a
 FAT32 file system. On N900, kernel is flashed to NAND and loaded by
 NOLO. Kernel then knows about btrfs as a root filesystem and boots it
 happily. Btrfs in u-boot would probably be the obvious question, if it
 exists?
 
 On ARM the bootloader doesn't have such a uniform environment to execute in
 as on the IA. I think it would be fair to compare the ARM bootloaders to the
 BIOS + bootloader combo on IA. Very often product revision specific things
 are done in the bootloader. It's not entirely impossible to have something
 like u-boot be a standard MeeGo bootloader for ARM, but it's by no means a
 given that it would satisfy for example Nokia's requirements for actual
 product. MeeGo would be perhaps best to prepare for having a per-product
 bootloader binary in the repository.

Why stop there? Why not climb up the stack with per-product OS and userland?

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

Re: [MeeGo-dev] Questions for TSG regarding big reveals and impact on open development

[Jeremiah Foster]

On May 16, 2010, at 1:52 PM, David Greaves wrote:
 
 Carsten Munk wrote:
 So, this is primarily an e-mail to ask some questions to the two
 members of the TSG, that I think would not be sufficiently covered in
 a TSG meeting and answers might be better suited for the e-mail form.
 
 I think there are others who can contribute to the conversation too.
 
 There are systems around meego that are only open to members for technical
 reasons so the discussions around them could be opened up. (Yes, there'll be
 some frustration at inaccessible links ... but that may help prioritise which
 systems to allocate opening-up resource to. For those involved : Why isn't
 this happening? What do you need to start discussions on open mailing lists?

Open Source is not just open source code - it is an open way of working. This 
means that we can have an opinion on the default file system in MeeGo and if we 
feel that btrfs is not yet ready, we can push ext3 to the repos to give 
ourselves a choice. The open source way of working does not yet exist in MeeGo, 
it is not yet an open project just a collection of git repos on gitorious.
 
 We're not working in the open like we're supposed to - even though as
 has been said - Intel, Nokia and we all know how to do it! But when
 there's a big reveal mentality active, the mode of the people
 participating switches to internal/private development, even if you
 are only tangentially related to the object/UX being revealed.
 
 And I think that's the main source of all our so called 'openness'
 problems - not malice, conspiracy, laziness or whatever.

I don't think there is a conspiracy or anything malicious either. These are two 
very large companies who now see the advantages of Open Source. It is a lot to 
expect that they will suddenly 'get it' and OPK and Ottellini will be showing 
up at FOSDEM with a penguin T-shirt and a UNIX beard. What is happening is 
these two large dinosaurs are learning to dance to an open source beat - that 
is pretty cool. I think we all need to have a bit of patience and be more 
proactive in helping them with the transition from proprietary and closed to 
open and shared. Your email was a positive, proactive step Carsten.

 For the near
 future until UX'es are out, the big reveal mentality will have to stay
 - and I respect that. I want a blazing start on a good future in this
 project with big fanfare. It's the future I'm worried about.
 
 It's the credibility of MeeGo as an open project that I'm worried about.

It has all the credibility it needs. It has credibility inside the walled 
garden that is corporate Linux. MeeGo is not meant for ordinary hackers - they 
are encouraged to work and commit upstream. MeeGo is a 'curated computing 
environment' where the file system is the best of breed but the only one and 
MeeGo will not listen to the debate. Its a lot like Flash on the iPhone - ain't 
gonna happen. If MeeGo alienates a few smart hackers . . . well, they can 
always contribute to Debian. What MeeGo wants is the appearance of meritocratic 
openness while retaining control over the infrastructure. Nokia did this with 
Maemo, and it caused certain problems, and it looks like MeeGo will go down 
this path too.
 
 Finally, my questions to the two members of the TSG are:
 [snip]
 Thanks in advance for your answers.
 I too look forward to the response - nb maybe you should cc/mail them to 
 ensure
 they don't miss such an important discussion.

They're powerless! Quim Gil is doing his level best to make sure MeeGo is as 
open as possible, but what leverage does he have? He can persuade people to 
contribute, but he can't force them. And once we have moved past deciding the 
forums and other bike shedding, we are back to actual work on the actual 
distro. (And it is a distro, no matter how close to upstream they claim it is. 
Debian only ships _pristine_ upstream sources, so you don't get closer to 
upstream than that.)

MeeGo's real audience is industry. It is a standardized. GNU / Linux API with 
key components supported by large multinationals and a compliance path so that 
other large multinationals can be confident that their code will be supported 
and gratuitous API changes will not occur. It is a commercial Linux distro, not 
an open source project.

Maybe that is good thing?

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

Re: [MeeGo-dev] N900 Testing for Btrfs needed (RE: Btrfs as default file system)

[Jeremiah Foster]

On May 11, 2010, at 8:42 PM, Carsten Munk wrote:

 2010/5/11  harri.hakuli...@nokia.com wrote:
 As reasoning from Arjan sounds good, we obviously
 now need to do some testing with N900  Btrfs as well.
 
 While filesystem is perhaps not something that must be
 the same between devices, it would be nice to use same.
 
 
 One initial worry would be kernel bloat/size - on a N900, we have a
 limit of a 2MB zImage kernel. We had some problems trying to move from
 ext3 to ext4 at some point and my worry is that btrfs would bring us
 above that again.

What about the lack of support for Flash memory? Not being able to put files on 
flash would be a significant set back in a embedded environment. 
 
 Howeer, Marko Saukko did make a (rescue) initrd we can be utilizing to
 load btrfs modules. Not as elegant as booting straight to a ext3 fs,
 but it would do the trick.
 
 On a 2gb microSD, 200-300mb of metadata would be quite a fair bit*.
 Has there been any studies on how well btrfs fares on SD cards/eMMC
 type chips?
 
 (*) Not against the selection of btrfs - I use ZFS on my servers
 extensively and it has saved my data on more than one occasion, so I
 understand why btrfs would be useful on mobile devices.

ZFS and btrfs are great. Perhaps they will fit well into a Mobile computing 
environment, but I have some concerns about a truly embedded environment.

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

[MeeGo-dev] Build server crecdentials

[Jeremiah Foster]

Hello,

The credentials for http://build.meego.com are not the same apparently 
for SUSE's OBS. There appears to be no way to create new credentials for this 
service either. Could someone please clarify the login method and process for 
getting access to this service? 

Thank you,

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

Re: [MeeGo-dev] Build server crecdentials

[Jeremiah Foster]

On May 4, 2010, at 12:39 PM, Robin Burchell wrote:

 On Tue, May 4, 2010 at 10:58 AM, Jeremiah Foster
 jeremiah.fos...@pelagicore.com wrote:
 Hello,
 
The credentials for http://build.meego.com are not the same 
 apparently for SUSE's OBS. There appears to be no way to create new 
 credentials for this service either. Could someone please clarify the login 
 method and process for getting access to this service?
 
 See: http://bugs.meego.com/show_bug.cgi?id=615
 
 I'm quite disheartened by the lack of activity on there.
 

Thanks for pointing that out to me Robin - at least I am cc'd on that now.

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

Re: [MeeGo-dev] Let's discuss the build.meego.com open

[Jeremiah Foster]

On May 3, 2010, at 10:46 AM, Andreas Jaeger wrote:

 On Friday 30 April 2010 04:16:07 An Yang wrote:
 Hi kojo,
 
 在 2010-04-29四的 11:22 +0200，tero.k...@nokia.com写道：
 
 I don't think the MeeGo core OBS that is used to make the MeeGo
 distribution releases will be opened to just anybody. Gaining access
 to that will always be a merit based thing based on working on a core
 project.
 
 I do NOT like OBS, it's not opened totally!
 in koji.fedoraproject.org, anybody can check any version+release of any
 rpm packages included in fedora, both binary or srpm even any build
 logs, no matter released or release candidates or just for testing
 packages.
 
 This is already implemented for obs version 2.0, you can check it today with 
 going to http://build.opensuse.org/stage - completely anonymous access.

Well, it doesn't get much more open than that. :-)

 I do NOT want to discuss who is better, but fedora is more open than
 opensuse.
 
 Yeah, a bit design decision in the beginning that needed to be changed.  Hope 
 you're happy with the way it will be for 2.0,

Good stuff. I look forward to pushing sources into OBS. I think it would be 
great if I could just set up a cron job to push a tag from my git repo into 
OBS. Is that sort of automated building possible on the OBS side? i.e. can a 
process push to the OBS or does it have to be a human? 

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

Re: [MeeGo-dev] Repository Working Group - next steps

[Jeremiah Foster]

On Apr 29, 2010, at 5:16 PM, Dave Neary wrote:

 
 Because we may still need some distinction between app store 
 downloads, I'm still inclined to name these Add ons or
 Extras.
 Maybe think of the name from the end-user perspective? Those people
 will see different stores and then this community place. How to make it
 obvious to a user that this place caters community built open
 applications. I.e. it is not a store, but you can get useful things from
 there. Community apps ?
 
 
 Why do we need a distinction? Can't we just have an app store where lots
 of applications are free? If the goal is to communicate the
 communitiness/freedom of the applications, perhaps there's another way
 to do that, but having a separate distribution channel just seems to me
 to make it less likely that people will go there.

Look at it from the position of the vendor (because MeeGo is being designed for 
their needs). If a vendor's email client sucks, they don't want a community 
version to take its place because then they lose all their super-duper 
analytics of what their users are doing and saying. How can they prevent that 
free, better community app from being used? Ban it to the loser community repo 
from the beginning and slap a big warning on it saying it causes cancer. 
Problem averted.

In an open marketplace people use applications that best suit their needs. Many 
large companies find this type of meritocratic system hard to compete in 
because they are used to either marketing their way to success or owning the 
channel. (Hello Apple!) MeeGo aims to be open enough that vendors feel they are 
on equal footing with other vendors, but they certainly don't want to compete 
with rogue developers who have years of experience in their domain and whose 
only motivation is to write great software. 

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

Re: [MeeGo-dev] Let's discuss the build.meego.com open

[Jeremiah Foster]

On Apr 30, 2010, at 9:59 AM, David Greaves wrote:

 MeeGo core OBS will not be open to any user; invitation only based on merit.


Please define 'merit' in clear, explicit terms in a public forum so that 
community members might understand what you mean.

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

Re: [MeeGo-dev] Let's discuss the build.meego.com open

[Jeremiah Foster]

On Apr 30, 2010, at 11:31 AM, David Greaves wrote:

 David Greaves wrote:
 Jeremiah Foster wrote:
 On Apr 30, 2010, at 9:59 AM, David Greaves wrote:
 
 MeeGo core OBS will not be open to any user; invitation only based on 
 merit.
 
 Please define 'merit' in clear, explicit terms in a public forum so that 
 community members might understand what you mean.
 
 Google Debian Developer and s/Debian Developer/MeeGo Maintainer/g

Are you saying officially that MeeGo development access to MeeGo build tools, 
repos and infrastructure will be done in the same manner as the Debian policy 
describes for Debian? (I know the Debian policy well and I'll be happy to point 
out where the MeeGo policy differs.)

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

Re: [MeeGo-dev] Let's discuss the build.meego.com open

[Jeremiah Foster]

On Apr 30, 2010, at 12:02 PM, David Greaves wrote:

 Jeremiah Foster wrote:
 On Apr 30, 2010, at 11:31 AM, David Greaves wrote:
 
 David Greaves wrote:
 Jeremiah Foster wrote:
 On Apr 30, 2010, at 9:59 AM, David Greaves wrote:
 
 MeeGo core OBS will not be open to any user; invitation only based on 
 merit.
 Please define 'merit' in clear, explicit terms in a public forum so that 
 community members might understand what you mean.
 Google Debian Developer and s/Debian Developer/MeeGo Maintainer/g
 
 Are you saying officially that MeeGo development access to MeeGo build 
 tools, repos and infrastructure will be done in the same manner as the 
 Debian policy describes for Debian? (I know the Debian policy well and I'll 
 be happy to point out where the MeeGo policy differs.)
 
 No. I see no written policy - merely comments scattered across blog posts, irc
 and email. Not a sustainable situation IMHO.
 
 Would you care to draft a MeeGo policy based on the Debian one and I'll gladly
 work with you to change it to fit the needs of the MeeGo community based on
 feedback from the community and the TSG. We can then get that proposed and 
 accepted.
 
 Frankly I think one of the biggest losses to MeeGo from the rpm/deb decision
 wasn't anything to do with deb. It was the clarity of the policy documentation
 (and the tools that helped enforce it) - and that's something we can work on.

This seems like a positive solution. I think have a web of trust in MeeGo 
perhaps based on previously contributed code, bug fixes, documentation, etc. in 
conjunction with a shared ssh key is a good basis to build that web of trust. A 
clear policy on how one contributes and maybe even a social contract ala 
Ubuntu's social contract. This should give developers a clear path towards 
participation.

I'll start on the wiki with the policy outline and seek comment on the lists 
and the forum.

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

Re: [MeeGo-dev] Repository Working Group - next steps

[Jeremiah Foster]

On Apr 30, 2010, at 12:06 PM, tero.k...@nokia.com tero.k...@nokia.com wrote:
 On Apr 29, 2010, at 5:16 PM, Dave Neary wrote:
 
 
 Because we may still need some distinction between app store
 downloads, I'm still inclined to name these Add ons or
 Extras.
 Maybe think of the name from the end-user perspective? Those people
 will see different stores and then this community place. How to make
 it
 obvious to a user that this place caters community built open
 applications. I.e. it is not a store, but you can get useful things
 from
 there. Community apps ?
 
 
 Why do we need a distinction? Can't we just have an app store where
 lots
 of applications are free? If the goal is to communicate the
 communitiness/freedom of the applications, perhaps there's another
 way
 to do that, but having a separate distribution channel just seems to
 me
 to make it less likely that people will go there.
 
 Ok, who's store? Intel? Nokia? Samsung? Asus? Acer?
 Commercial is commercial, this is supposed to be open.
 
 Look at it from the position of the vendor (because MeeGo is being
 designed for their needs). If a vendor's email client sucks, they don't
 want a community version to take its place because then they lose all
 their super-duper analytics of what their users are doing and saying.
 How can they prevent that free, better community app from being used?
 Ban it to the loser community repo from the beginning and slap a big
 warning on it saying it causes cancer. Problem averted.
 
 A bit paranoid today?

I like to call it a healthy skepticism. But I understand rhetorical subtlety is 
something of a challenge so I understand why you might resort to name calling. 
I don't understand why you corporate guys feel so threatened though, you always 
seem to resort to ad hominem attack.

Jeremiah


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

Re: [MeeGo-dev] Repository Working Group - next steps

[Jeremiah Foster]

On Apr 20, 2010, at 12:24 AM, David Greaves wrote:
 
 
 So is this area managed by the core project?
 How can it be? MeeGo core is a distro, not an app-store or sourceforge. It has
 no policies or processes for handling non-affiliated applications. There isn't
 even community access to the core build system.

If there is no access to the build system, MeeGo is effectively closed. 

We'll have to evaluate the efficacy of MeeGo as a distribution in that case for 
our project. A clear, unequivocal statement about the build system's 
accessibility to outside developers, including submission of sources, timely 
availability of resources, as well as documentation and input into toolchain is 
critical for our evaluation of a platform to build on.

 
 Build
 =
 Having outlined what repositories are covered we need to look at how community
 code gets into those repositories; the build service.
 
 The build service is a crucial part of both packages and surrounds; the
 selection of the OBS allows effective integration between build, QA and
 publication (and potentially DVCS too). This is another key reason for the
 end-2-end scoping for the RWG in the proposal.

At this point, lack of access to OBS and the lack of documentation of OBS are 
two risks for the wider adoption of MeeGo. Is there work being done in this 
regard? Particularly interesting is thorough OBS documentation.
 
 Whilst a case can be made to limit access to the core MeeGo build system to
 ensure finite compute resources are available to the core developers, it makes
 no sense for the community to have independent build systems for both packages
 and surrounds; a single service would cover both; this is another reason why
 applications and surrounds are both within the RWG.

I strongly suspect that separate independent build systems will blossom anyway 
due to the closed nature of proprietary code being placed in so-called app 
stores. I think that a lot of application vendors see their build systems as 
strategic, MeeGo will have to convince them that they can build in the open.

 
 Document
 
 
 The community already puts a lot of effort into the documentation; the RWG 
 would
 provide a focus for areas within its scope.
 
 Much of the RWG's work would result in additional documentation; indeed it is
 quite likely that issues arising would not be considered closed until they 
 were
 documented appropriately.

Good documentation will make MeeGo much more valuable to vendors as well as 
upstream.

 
 I hope this provides some foundation for discussion and enables the TSG to
 consider the proposal further.

Thank you David, good stuff.

Jeremiah

=
Jeremiah C. Foster  
Core Integration Team Lead, GENIVI
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

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

Re: [MeeGo-dev] mic.imgcreate.errors.MountError

[Jeremiah Foster]

On Apr 19, 2010, at 3:52 AM, Steven Tao wrote:

 I still got the 0.17 version from 
 git://gitorious.org/meego-developer-tools/image-creator.git
 Where can I get the latest version?

For MIC that is the latest version. 

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