Re: [MeeGo-dev] POCO C++ libraries integration

[Arjan van de Ven]

On 3/8/2010 1:31, Mr. Todorov Todor wrote:

Hi,
does somebody has experience on deployin POCO (C++ libraries
http://pocoproject.org/ ) on MeeGo.
Or generally what is your oppinion on making this library available on MeeGo?
Todor


the "should this library be included" question usually has 3 components

1) Is something relevant actually going to use it for some useful functionality?
   (without a "yes" to that it usually is an irrelevant library)
2) Does it overlap with something that we already have?
   (if there's overlap, extending what is already there may well be the better 
solution)
3) How is the quality/maintenance/etc?
   (if the code is full of security holes, or the upstream project is mostly 
dead, then it's probably not a good idea)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] POCO C++ libraries integration

[Arjan van de Ven]

But I would also like to understand more about what "included" might mean.  If
MeeGo were an ordinary distribution (like Debian, say) then "included" would
mean things like: built as part of the distribution, included in the output
(repository, CD, ...) of the distribution, supported (at least for bug
reporting, possibly for security patches) by the distribution.  For most
distributions the key thing controlling inclusion is someone offering to
provide the packaging and support required.


I was assuming the request was for this level.



But for MeeGo, "included" might mean something different.  It might mean, for
example, guaranteed to be present on any device which claims to use "MeeGo
Vx".  Is this going to be true for everything "included" in MeeGo?  Or will
there be something like Debian's "essential" category: packages guaranteed to
be present?


there is this yes; this is a work in progress obviously (like everything else);
the architecture diagram on the website is sort of a high level view of this.
The idea is that there is a basic set of services/apis that an app can assume 
to be there,
and to be consistent between types of devices.

The threshold to be part of this set obviously is a LOT higher, as it should 
be.
(this set defines pretty much the minimum footprint after all)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Perl / CPAN integration on MeeGo?

[Arjan van de Ven]

On 3/8/2010 1:11, Jeremiah Foster wrote:


On Mar 5, 2010, at 11:01 PM, M. Edward (Ed) Borasky wrote:


I'm doing some Perl development and would like to port my code to MeeGo. How is 
the integration of Perl and CPAN going to be handled? Will it resemble 
openSUSE, Fedora/Red Hat, Debian/Ubuntu, Gentoo or something else?


A lot of perl in the various linux distributions comes directly from packagers 
packaging modules from CPAN. This means that they are put into packages native 
to that distro and in MeeGo's case that distro will be built on rpm packages.


I'm currently on openSUSE, and I've found that I pretty much have to go 
directly to CPAN for almost everything except the Perl interpreter itself. Is 
that going to be true on MeeGo as well, or will there be a tighter integration, 
like there is (or used to be) with Gentoo?



CPAN is vast - there are tens of thousands of modules, and that is not even 
counting the Backpan or Darkpan. There is no way any single linux distribution 
can package all of CPAN, nor would it be a good idea, so whichever linux 
distribution you choose, you will have to complement its selection of perl 
packages with packages from CPAN, especially if you want something esoteric or 
new, like perl5i.

Fortunately, the good news is that MeeGo should be able to install most 
pre-packages perl modules in the form of rpms with little or no modification. 
This means that MeeGo can use packages from both Fedora and SUSE for example. 
Debian uses debs as their package format, and while debian has more perl 
packages than any other linux distribution, you'll not be able to install 
debian perl packages as easily as you will rpms.



btw I would really like to have some good tooling, that would make it basically 
automatic to create a package for a (sane) CPAN project,
in a way that it is a good, valid and clean package. We can then build a 2nd 
layer of tooling around that, that would scan CPAN for updates
and notify the maintainer of the package for evaluation to see if the new 
version should be used...

I'm sure various pieces already exist.. just a matter of getting enough glue to 
make it fit together nicely.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Perl / CPAN integration on MeeGo?

[Arjan van de Ven]

How different are Fedora Perl module RPMs from openSUSE Perl module
RPMs? I've not spent enough time on Fedora to get into the Perl
packaging and repository game - I went straight from Gentoo to openSUSE
in mid-2008.


what Fedora does is not very relevant.

what MeeGo should do is

For me, we SHOULD do two things
1) Provide a clean packaging standard for CPAN modules
2) Have good tooling to add and maintain such packages

if it is easy for a package maintainer to get notified when there's a new 
version on CPAN,
then build a test package, test it sufficiently, and when it passes, push it 
into the distro...
... then we have a standing chance of getting really good, current CPAN modules 
into MeeGo.

If the process is too manual, error prone and cumbersome, it'll be FAIL instead.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] What are you waiting for to happen in MeeGo?

[Arjan van de Ven]

On 3/8/2010 9:32, M. Edward (Ed) Borasky wrote:

On 03/08/2010 01:18 AM, Jeremiah Foster wrote:


On Mar 6, 2010, at 9:37 PM, Ville M. Vainio wrote:


On Sat, Mar 6, 2010 at 10:31 PM, M. Edward (Ed) Borasky
  wrote:


keyboards and more RAM / CPU power? Am I stuck with C++ for efficiency
reasons, or can I get away with a scripting language? And which scripting
languages are going to be feasible in the pocket form factors?


Just look at Maemo right now, you'll get a pretty good idea. There's
lots of Python apps around in maemoland, and they run reasonably well
even if they take a few secs to launch.


The perl interpreter is also on the N900, version 5.8.3

Jeremiah


What are the odds of 5.10 or 5.12 making it into MeeGo? I can live with
5.8, I think, but I've been on 5.10 so long now I'm not at all sure my
stuff would work with 5.8.


I would expect 5.10 at minimum; for the short term release. Longer term I'd 
expect
newer versions to be followed.
But perl is like the C compiler, you do freeze that somewhat in the first half 
of your development cycle
since so many other things depend on it.


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

Re: [MeeGo-dev] Perl / CPAN integration on MeeGo?

[Arjan van de Ven]

On 3/8/2010 9:47, Jani Mikkonen wrote:



btw I would really like to have some good tooling, that would make it basically 
automatic to create a package for a (sane) CPAN project,


Hint: cpan2rpm. There should be also some yum repo's that stock with
cpan modules that are already processed.


something like that is only half the story though

also need the monitor and update part


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

Re: [MeeGo-dev] Perl / CPAN integration on MeeGo?

[Arjan van de Ven]

On 3/9/2010 2:31, Jeremiah Foster wrote:


I guess we should start talking about this stuff on the openSUSE Build
Service mailing list - I think I'm still on it, although I'm sort of
tied up in Twitter stuff till after Chirp.


This is the model we should follow, since this is the model that MeeGo 
apparently will use:

1. Write your perl software
2. Upload to CPAN
3. Pull from CPAN into OBS
4. Pull from OBS to MeeGo
5. Profit


step 3 and 4 are the same; OBS is the build system that MeeGo uses, it's not something 
"magic"
that happens before MeeGo ;-)

you get a package into MeeGo by sending it to the MeeGo OBS to build it into 
MeeGo.

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

Re: [MeeGo-dev] Source Code for meego/Mounting ntsf in moblin

[Arjan van de Ven]

On 3/9/2010 18:44, Tzeng, Tonny wrote:

In Moblin 2.1 release, NTFS is not enabled by default, you have to rebuild the 
kernel.  FYI.


unfortunately this is not a correct answer.
NTFS support isn't done by the kernel in Linux anymore, but by the userspace 
NTFS3G componentat
that uses the FUSE interface to the kernel.

Inclusion of the ntfs3g component is up to the person shipping the device I 
suppose; it's obviously
not a mandatory component.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] directfb will be integrated?

[Arjan van de Ven]

On 3/13/2010 20:06, zwolfox_meego wrote:

Hi,
Does Meego will integrate directfb to support high resolution of display
device such as 1080p TV or STB ?



MeeGo's visualization system is based on a complete X windows stack; not on 
directfb.
For the kind of user experiences that MeeGo is aiming for, as well as for 
compatibility between various MeeGo devices,
directfb is just not an option.

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

Re: [MeeGo-dev] Power Tuning?

[Arjan van de Ven]

On 3/18/2010 17:46, Chad Spears wrote:


I was curious to see who is working on power tuning in the core
development. This is an area I will be interested in as soon as I get a
copy of meego. Is the focus mostly on mobiles?


I suspect I and a bunch of others will end up involved in that.

The good news, to me at least, is that power tuning by and large is universal...
it is extremely rare (in fact I cannot think of anything right now) that 
something that's
good for one type of device for power, is bad for any other type.

there are a set of universal things for power, and then some device specific 
ones

1) Do not waste performance. A 10% waste in performance tends to be a similar 
loss in power.
   (this is good news, many people know how to tune for performance already)
2) Mind your wakeups, and use all the available techniques to reduce them. Eg 
run powertop
   and fix anything that shows up. Fix software to not do stupid polling. Use 
range timers.
   etc etc
3) Have high quality, good device drivers. Device drivers own their device's 
power, and a good
   driver makes all the difference in the world for the final power result.
4) Keep an eye on background activity... any percent of CPU that you steal in 
the background is
   also power that you steal. "timechart" is a good tool to chase these down

in general the "one bad guy can ruin it all" rule applies


there are some device specific items to tune, the most obvious one I can think 
of is the policy
for CPU frequency/voltage, and generally the CPU vendor is expected to provide 
good code to Linux
for this.

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

Re: [MeeGo-dev] N900 Questions...

[Arjan van de Ven]

On 3/19/2010 8:19, Igor Stoppa wrote:

ext Adrian Yanes wrote:


I hope that here Meego follows the guidelines of other linux distros,
it means non-free disable by default. If someone is interested in
non-free stuff they can enable the option.

In other words, the Debian Social contract has a good advice:

"We will never make the system require the use of a non-free component."


Even if that practically makes the display unusable?


surely there is a 2D only driver that's open? Most binary graphics stuff 
applies to accelerated 3D only..

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

Re: [MeeGo-dev] Kernel version?

[Arjan van de Ven]

On 3/19/2010 14:25, Gary Castillo Gorbunov wrote:

After reading the thread "N900 questions" I assume that the development
of Meego will start from the Kernel level, which Linux Kernel version
will be used? Will It use the 2.6.33.1 and it's features for with
limited resources devices or some optimized tested version on Maemo or
Moblin?


the objective for MeeGo is to ship an "as close to upstream" as possible kernel.
like any distro, we obviously will have some "tweak this constant" kind of 
patches; those arent' too big a deal.

we may have some patches for hardware for which the code is on it's way to 
upstream (already submitted to the maintainer etc)
and which are required for some key hardware to work... basically this is time 
travel to not block work until an upstream maintainer
hits a merge window.

but there is no big kernel fork where we deviate greatly from the kernel.org 
kernel.

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

Re: [MeeGo-dev] OpenGL or OpenGLES?

[Arjan van de Ven]

On 3/22/2010 17:26, Justin Ohkyoung Kwon wrote:

Hi,
I'd like to know what 3D library in MeeGo.
As far as I know OpenGLES2.0 is used in Maemo5 but OpenGL is used for Moblin.
But, It may seems not defined detailed spec of MeeGo yet.
I wonder about OpenGLES is used for ARM based SOC whereis OpenGL is used for 
ATOM.
Does anybody know about what 3D library is used?


so... it's a little more tricky.
opengles2.0 and opengl are very close to eachother... basically they are 
slightly different subsets of the
whole "cloud" of GL extensions
for rich user interfaces and game like apps, opengl is just a bit more 
powerful, and I suspect that even
non-x86 chips will be moving to opengl for competitive reasons a more sexy 
UI is just very important
today in the market..

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

Re: [MeeGo-dev] The nativer rendering model proposal in Fennec

[Arjan van de Ven]

On 3/22/2010 22:53, Wu, Yong wrote:

Background:
Fennec uses a different rendering model as Firefox,


I would be seriously concerned about using either Firefox or Fennec on a mobile 
device.

Looking at the current ecosystem, it's very clear that webkit is winning on the 
small side of
the hardware world, and on the big side, it's making big strides as well with 
Chrome.

While I don't want to discourage discussion, I think taking one step back and 
wondering if Fennec
is the right choice in the first place would be very appropriate
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] The nativer rendering model proposal in Fennec

[Arjan van de Ven]

On 3/23/2010 10:41, Jeremiah Foster wrote:


On Mar 23, 2010, at 3:48 PM, Arjan van de Ven wrote:


On 3/22/2010 22:53, Wu, Yong wrote:

Background:
Fennec uses a different rendering model as Firefox,


I would be seriously concerned about using either Firefox or Fennec on a mobile 
device.


Fennec (or really Firefox Mobile) is popular, fast, and innovative. It is 
already available for the N900 which is a MeeGo platform. I don't share your 
concerns but I also don't think having to html rendering engines in MeeGo is 
necessary.



yeah and if I'd have to pick one right now I'd pick webkit to be honest...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] browser engine and other big architectural decisions

[Arjan van de Ven]

On 3/24/2010 7:47, George Matveev wrote:

Hi,

this browser *engine* question was already touched upon many times
here and it is certainly puzzling and deserves attention of those who are
responsible for (architectural) decision making in this project
(hopefully Intel team is reading this).



I'm reading ;-)


so from where I sit there are 2 separate questions, from an architecture pov.

1) The browser application

2) The "embedded web component" as used by various applications

for 2), there is no question for me that webkit is the right answer for this.

for 1), this is not really an architectural decision, it's an application that 
does not impact
other pieces around it per se... and this application is likely device class 
specific.
(phone, netbook, TV, etc all likely will use very different applications for 
browsing after all)
As such different device profiles in principle can have completely different 
technology for the implementation
internally to the application.
Having said that, personally I think that if you're doing a new browser or 
making a new decision, you pick
a webkit based implementation. But that's a personal opinion, not something 
that I feel belongs as an architectural
rule.

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

Re: [MeeGo-dev] [Meego-community] Proposal: A vendor social contract

[Arjan van de Ven]

On 3/24/2010 10:38, Adrian Yanes wrote:

For this reason a social contract could help us, establishing a
default requirements if you want  to integrate a component/driver in
the MeeGo project.


how is all of this different from the hardware enabling flow already 
established on meego.com ???
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] [Meego-community] Proposal: A vendor social contract

[Arjan van de Ven]

On 3/24/2010 11:10, Wichmann, Mats D wrote:

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

For this reason a social contract could help us, establishing a
default requirements if you want  to integrate a component/driver in the
MeeGo project.

Maybe the social contract sounds very free-software "fanatic" for a
company, but is one of the best warranties to offer a complete open
source project.

Besides, it would be a signal of commitment with the community, and it
will encourage participation in the development.


My completely personal, completely unofficial reaction is
that this would have a LOT of problems on the Tivoization
front, as it seems to me everybody below the netbook and
possible tablet type device is interested in some level of
locking down their image... Don't know if it looks that
way to the rest of you or I'm just being too pessimistic?



this level of device lock went out of the window once people wanted app stores.
the moment you want an app store of any relevance you're no longer completely
locked down, which means you need some smarter technology regardless...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Day 1 is here - opening up the MeeGo development

[Arjan van de Ven]

But normal tarballs are better anyway for distributions wanting
to package parts of MeeGo for their own use.


but distributions wanting to package stuff also need the patches etc...
they can just rpm2cpio the src.rpm's. much more complete.

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

Re: [MeeGo-dev] Day 1 is here - opening up the MeeGo development

[Arjan van de Ven]

On 3/31/2010 22:24, Julian Andres Klode wrote:

On Wed, Mar 31, 2010 at 10:09:31PM +0300, Arjan van de Ven wrote:



But normal tarballs are better anyway for distributions wanting
to package parts of MeeGo for their own use.


but distributions wanting to package stuff also need the patches etc...
they can just rpm2cpio the src.rpm's. much more complete.


That would be repackaging, not packaging.


no it's extracting the source and patches from the src.rpm
into a directory.

>

And furthermore,
I am talking about software maintained by MeeGo; for which
there should be no patches but only releases. And source
tarballs are handier than extracting them from srpms


theory and practice may be different things. Even though meego engineers
may be upstream maintainers for some of these projects, there can and
will be situations where the distribution team needs to put a temporary
patch in/
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] can't clone the meego-os-kernel source code ?

[Arjan van de Ven]

On 4/1/2010 16:39, Greg KH wrote:

On Thu, Apr 01, 2010 at 04:17:19PM +1000, Sebastian Lauwers wrote:

2010/4/1 paizzj:

Hi? all:
?it seems I can git clone the meego-os-base source code .e.g:
$ git clone git://gitorious.org/meego-os-base/kernel-source.git
$ fatal: no matching remote head


That's because there have been no commits yet. As far as I can tell,
it's just a placeholder at the moment.


Which makes no sense to me, as the kernel source is really in a
different repo.

Wierd, why are there two repos named kernel-source?



there will not be a "real" source there, but the content of the src.rpm
so that people can get our patches, as few as they are, in incremental steps
rather than having to re-install the src.rpm


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

Re: [MeeGo-dev] kernel panic with 2.6.33.1-8.2-netbook

[Arjan van de Ven]

On 4/2/2010 0:13, Leonardo Luiz Padovani da Mata wrote:

On Thu, Apr 01, 2010 at 05:44:32PM -0300, Leonardo Luiz Padovani da Mata wrote:

BTW, i've just downloaded the kernel package from the repository,
installed, and tried to boot in the  moblin version 2.1. It producess
a kernel panic. i still need to test and see what's going on, but the
kernel isn't very stable yet.
:-)


Post the kernel panic here and/or open a bug in the bugzilla.

thanks,

greg k-h



So, the kernel is dump lot's of messages that represents the stack
trace, btw, is there a easy way to dump that messages to a file (LKCD
does that)?

they look like:
[0.184003] Call Trace:
[0.184003] [] do_exit
and so on..

the message on kernel panic was:
Kernel panic - not syncing: Attempted to kill init!



also.. what type of machine is this?
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] IEGD and MeeGo

[Arjan van de Ven]

On 4/1/2010 11:27, cphe...@rockwellcollins.com wrote:



The MeeGo repo has X-Server 1.7.


just to correct this; MeeGo uses X server 1.8; the version in the repo is to 
indicate that the package is a release candidate.
(to be updated any minute now that the final 1.8 is out)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Building the Meego Dev Environment

[Arjan van de Ven]

On 4/1/2010 20:56, An Yang wrote:

There are 287 rpm packages in day one release, most of them come from
Fedora 13, so I think fedora 13 is the prefer DEV ENV.


I'm sorry but MeeGo does not come Fedora...
Please don't spread this misinformation any further...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Building the Meego Dev Environment

[Arjan van de Ven]

Who build the package is not important, what's in the package and the
quality is more important.
what I want to express is if the packages without meego's special
patches, meego should just use/rebuild it from fedora, it reduce the
cost of the project.


that sounds nice in theory, but does not work in practice. MeeGo and Fedora
have very different objectives and that makes what you describe not a good 
option,
and not current practice.

As an example, Maemo started with Debian, but current Maemo and Debian are 
rather
far apart.


MeeGo does borrow some packages from Fedora (like glibc) just like we borrow 
some packages
from OpenSUSE. I don't expect this to grow dramatically over time; in fact as 
things evolve further
I'd not be surprised if the opposite happens.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Building the Meego Dev Environment

[Arjan van de Ven]

My question initially was if there was a preferred platform for Meego.
  Just like the statement above, it seemed like trying to build Meego's
dev or final-2.1 environment on Fedora was a lot less problematic then
the Ubuntu version.  I've had a much easier time building Meego on FC.
  If Nokia's developers generally prefer working on FC, then odds are
things will be first documented and more likely to work in the
environment they primarily work in.  I'm sure it'll work on every
flavor of Linux with a bit of work... I'd just rather spend the time
on actual code for meego rather then making meego work.

That being said... fedora, ubuntu, SuSe... as long as we have a
product it doesn't matter what it is based on, used, as long as it
works.



to answer your question (and I think Auke already did it as well),
I and several of my coworkers run MeeGo to develop MeeGo.
It's the one environment that we can make sure works, and also that
many of us now run ;-)

(I'm running it on a rather beefy Core i7 box for the more heavy work,
but also on a Core2duo laptop for more portable uses)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] CPU Architectures (was Re: Build for a standard PC)

[Arjan van de Ven]

On 4/4/2010 9:52, Nick Thomas wrote:

On 04/04/10 16:41, ezjd wrote:

You need make sure your PC CPU is supported (with SSE3 at least), for
example, pentium-m isn't as I saw pretty much same thing as yours but
c2d or above is OK and Atom of course.

VirtaulBox way worked in my AMD Athlon64X2 PC w/ this one
http://cross-lfs.org/~cosmo/meego/meego-iso.vdi
 but I didn't try qemu.

JD Zheng


So far, it's seemed to be a fairly weird collection of architectures.

I kind of expected N900-specific and LPIA builds, potentially + a
generic-as-possible ARM, a highish-power x86, and an amd64 image.

Can anyone comment on the list of architectures meego is planned to
support? Obviously, "ARM and x86" is the general idea, but there's
plenty of potential subdivision within that.

Old ARM, new ARM, lpia, old x86, new x86, amd64 would be my preferred
list ;) - for a weedy netbook or phone, CPU optimisations could make a
noticeable difference to performance.

Presumably, OBS makes building for additional architectures not too big
of a deal - although I realize it increases kernel and testing somewhat.



the big deal is in the amount of build capacity needed and the maintenance and 
work
it is to keep track of all this.



on the x86 side, I kinda disagree with your choices.
Every linux distribution to date picks one "start point" in the x86 evolution,
and supports everything after that. Right now, MeeGo uses "Core2Duo" as that 
starting point
(which is now 4 years old or so), which includes Atom as well.

That captures a very large amount of machines out there, while still working 
optimally on Atom...
(the SSSE3 choice comes from using SSE not x87 for floating point math, which 
helps atom a *ton*, but is
also very good for core2 and later... frankly, x87 is nasty for the compiler 
which means the generated
code isn't always so nice)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Building the Meego Dev Environment

[Arjan van de Ven]

On 4/2/2010 13:35, Jean-Christian de Rivaz wrote:

Arjan van de Ven a écrit :

Who build the package is not important, what's in the package and the
quality is more important.
what I want to express is if the packages without meego's special
patches, meego should just use/rebuild it from fedora, it reduce the
cost of the project.


that sounds nice in theory, but does not work in practice. MeeGo and
Fedora
have very different objectives and that makes what you describe not a
good option,
and not current practice.


This make me even more less optimist about the future of Meego. The
interesting concept of Maemo was to lower the difference between a PC
and a mobile computer. There is already a lot of mobile products that do
a lot of fun stuff in a very different way as in a PC. And in this area,
Meego is so late and immature that is have no chance at all.


MeeGo is by no means restricted to mobile, but it does have a very strong focus on 
"client device"
and does not want to compromise the client experience for server kind of things.

lets face reality, if I compare MeeGo on a netbook to, say, Fedora (but the same comparison holds pretty much wrt suse or debian or ubuntu, 
although there a few things on the list will be in common)


MeeGo has a different
* buildsystem (OBS)
* bootloader (syslinux)
* kernel
* way of booting the OS (fastinit)
* filesystem (btrfs)
* network configuration and start (connman)
* way of starting the user session (uxlaunch)
* X packaging/versions/stack/etc including non-root-X
* desktop environments (continuation of the Moblin netbook UI for netbooks, 
others for different device types)
* preferred application UI toolkit (Qt)
* package updater (zypper)
* ...
* ...

eg a long list of differences (and it's longer than this).

each of these differences, we think, contribute to what we think is a better 
client experience either for the 1.0 release or for a next version.
It's not that I WANT to be different no matter what, but at the same time I 
don't accept an inferior experience
for the sake of sharing some technology that does not really fit. If things can 
be shared, great! If not, so be it.

Is it still a "PC linux like OS" ? Absolutely. Just because it has a somewhat different architecture in how things are put together, for the 
user and applications it's still very much intended to be a quite complete *client* PC linux.

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

Re: [MeeGo-dev] CPU Architectures (was Re: Build for a standard PC)

[Arjan van de Ven]

On 4/5/2010 2:51, Nick Thomas wrote:


Obviously, extra architectures aren't free - and you're probably right
when it comes to the x86 side of things. For phones, 'lowest common
denominator' is unlikely to help much, I fear.

I must admit, I'll be really disappointed if amd64/x86_64 isn't
supported - even Slackware has one of those now ;), and my 'connected
tv' is currently amd64. Of course, not supporting amd64 means several
whole classes of bugs will never be exposed - so it does lower the
maintenance burden.


My current thinking is to try a x86-64 kernel, with 32 bit userspace, for the 
release after the upcoming one.
We know there is a clear advantage in that (for the graphics driver to be 
specific), and it has very limited
impact on everything else in the system.

As for doing most of the OS as 64 bit that's a lot of compatibility pain 
(MeeGo after all is trying hard
to provide a unified base for software vendors to write to, which thus must 
include 32 bit compat for such
an offering and that is where things get messy)



Additional: kind of related to this, and kind of to your other email to
Jean - one space I've not seen MeeGo make any overtures to yet (and
possibly rightly, I don't know) is the router space. At least in the UK,
there's a (slow but steady) drive to oust ADSL and give everyone a fibre
termination to their home. Kind-of coupled to that is a tendency for
home routers to gain more and more in the way of functionality - Home
Hub, Be Box, what have you. VoIP and online-TV is starting to get
built-in and bundled with the BB. Generally MIPS boxes, they act as
gateway devices and tend to be stuffed-up linux builds with no future.

Does MeeGo have a (distant, perhaps dimly-realised) future integrating
that kind of device, or is it something there's no interest in?
Obviously, neither nokia or intel care a jot about MIPS - so I'm not
necessarily suggesting that there should be a mips port - but I do hate
the necessity of having several different boxes to do similar functions.
Right now, my 'router' is actually a
router-fileserver-soon-to-be-the-connected-tv-and-phone-too ('just' need
to add TV tuner support and wire the phone into it). Of course, it's
Debian at the moment...


I'm not sure. It comes down to focus and objective; the focus and objective of 
MeeGo
currently are to provide a minimum-but-rich-enough set of functionality 
everywhere
that application writers can write to. This is in direct conflict with the "super 
mini embedded"
desire that I suspect some of the people making such boxes would want...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] WayLand

[Arjan van de Ven]

On 4/5/2010 19:16, Zhang, Xing Z wrote:

I have heard about it for a while, however, I didn’t see more details
except a few advertorials from google.

Is it still in developing? Would it be used in Meego to replace Xorg?



Wayland is still in development, however the timeline for it being ready for
replacing Xorg as the primary display application is quite a while out...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] CPU Architectures (was Re: Build for a standard PC)

[Arjan van de Ven]

After I checked a few source rpm, I still can't tell. Probably I need to
build some to figure out, but I suspect it may be different for various
pkgs.



build flags are a global setting

for the x86 build we use

-march=core2 -mtune=atom -O2 -mfpmath=sse -mssse3

(the later is technically implied by -march=core2)

for the code generation options; there's also some options around the various 
security options
(stack protector etc)

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

Re: [MeeGo-dev] CPU Architectures (was Re: Build for a standard PC)

[Arjan van de Ven]

On 4/6/2010 23:56, Riku Voipio wrote:

On 04/05/2010 06:04 AM, ext Arjan van de Ven wrote:

On 4/4/2010 9:52, Nick Thomas wrote:



Presumably, OBS makes building for additional architectures not too big
of a deal - although I realize it increases kernel and testing somewhat.



the big deal is in the amount of build capacity needed and the
maintenance and work
it is to keep track of all this.


Build capacity is trivial on X86 side.


I'm happy that your department is volunteering to budget for this...
let is know when the machines and rack space in the data center arrive ;)


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

Re: [MeeGo-dev] How to boot the meego-preview-netbook-core-20100330-001.usbimg

[Arjan van de Ven]

On 4/6/2010 23:32, Zheng Zhang wrote:

Hi, I have downloaded the meego-preview-netbook-core-20100330-001.usbimg
from the website, and use the command "sudo dd
if=meego-preview-netbook-core-20100330-001.usbimg of=/dev/sdb1" to copy
it to the usb disk, but when I boot the netbook from the usb disk, the
prompt is" no operating system ", so what I want to know is how to boot
the usbimg correctly. Thank you!



typo in the command.. it's sdb not sdb1
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego Preview + Menlow + GMA500

[Arjan van de Ven]

On 4/7/2010 4:58, Arthur Hsiao wrote:

Does anyone check if Meego Preview fully supports Menlow+GMA500?  Is
there any release note for Meego Preview?


there is no support for gma500 in meego currently.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego Preview + Menlow + GMA500

[Arjan van de Ven]

On 4/7/2010 6:58, Arthur Hsiao wrote:

Does Moorestown use GMA500?


I'm not authorized to speak publically about what Moorsetown includes
but whatever it is, it's not "GMA500".

GMA500 is the marketing name for the combined GPU and graphics component in the Menlow/Poulsbo (US15 or something in marketing speak) 
chipsets...

and whatever Moorsetown has is not identical.



(Just to clarify something in general: a graphics chip is more than just the GPU compute core, it includes a 2D/display/output part as well 
as a bunch of other logic)

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

Re: [MeeGo-dev] QT licenses issues for commercial developers

[Arjan van de Ven]

On 4/7/2010 9:15, Dengyi Wang wrote:

Hi,

 From http://qt.nokia.com/products/licensing, I noticed QT have 3
licenses: Commercial/LGPL v2.1/GPL V3.

We all knew Meego UI applications are based on QT. If someone wants to
develop an "closed source" UI application, then he/she must purchase the
commercial license. Is it correct understanding?

 From the FAQ page, I learned QT libraries are different for GPL or
Commercial license. I assume QT libraries for Meego is under LGPL. Does
it mean that all UI applications must be open sources?



this is a question for lawyers... but notice the L in LGPL.
Does glibc being LGPL licensed mean that all Linux applications must be open 
sourced?

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

Re: [MeeGo-dev] Meego Preview + Menlow + GMA500

[Arjan van de Ven]

On 4/7/2010 10:00, Arthur Hsiao wrote:

But again, I was told that Sodaville also uses GMA500?!


you were told incorrectly. Sodaville does not use GMA500.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego Preview + Menlow + GMA500

[Arjan van de Ven]

On 4/7/2010 10:19, Cory T. Tusar wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arjan van de Ven wrote:

On 4/7/2010 10:00, Arthur Hsiao wrote:

But again, I was told that Sodaville also uses GMA500?!


you were told incorrectly. Sodaville does not use GMA500.


Erm... I believe the CE4100 family (Sodaville) does include the same
PowerVR SGX535 core as in the GMA500, no?



that is not the same as using GMA500.

A graphics chip contains many components, the 3D compute engine (SGX535) is 
only one part of it.
the 2D part as well as the various outputs, setup, initialization etc are other 
parts.

GMA500 is the Menlow incarnation of this whole set. CE4100 has a very different 
mix with even different programming
models etc.

(And "SGX535" is a family designation, there's quite a few variations on that 
with the same name)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego Preview + Menlow + GMA500

[Arjan van de Ven]

On 4/7/2010 10:50, Thom Cherryhomes wrote:

I am also trying to find any Moorestown sample boards etc, for
prototypingnd development purposes, but I can't seem to find any
significant information...



that would be because Moorsetown is not a shipping platform yet.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] CPU Architectures (was Re: Build for a standard PC)

[Arjan van de Ven]

On 4/7/2010 11:13, ezjd wrote:

Mandatory GL support is appealing and I basically agree with it,
however, there are at least 2 scenarios I'd like to see MeeGo UI can run
w/o it:


GL (or GLES which is just a slightly smaller subset functionality wise) is a 
mandatory
component of any MeeGo OS; you're not compliant without it (and thus cannot 
call your OS MeeGo)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Building the Meego Dev Environment

[Arjan van de Ven]

On 4/7/2010 12:13, Jean-Christian de Rivaz wrote:


I made this clear as clear as Meego team have made there choices. Now
you could at least see that I try to improve the situation (using the
few spars time I have), before fighting against me with arguments that
simply forget years of history.


guys please take a deep breath :)

We as MeeGo would absolutely like to have MIC2 and our other tools work well
on top of/as part of Debian. In fact, we've pretty much had this at some point
in Moblin etc. If things are missing in terms of documentation or workarounds,
lets all work on closing the gaps rather than yelling at eachother


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

Re: [MeeGo-dev] CPU Architectures (was Re: Build for a standard PC)

[Arjan van de Ven]

On 4/7/2010 18:38, An Yang wrote:

在 2010-04-04日的 20:04 -0700，Arjan van de Ven写道：

Every linux distribution to date picks one "start point" in the x86
evolution,
and supports everything after that. Right now, MeeGo uses "Core2Duo"
as that starting point
(which is now 4 years old or so), which includes Atom as well.


just glibc use -march=core2 -mtune=atom;
in kernel CONFIG_MPENTIUMM=y;
in meego-rpm-config optflags: i586 %（__global_cflags) -m32 -march=i586
-fasynchronous-unwind-tables
do you think meego should optimize all of the sourcecode with
-march=core2 -mtune=atom?


we actually do. this is an OBS setting



BTW, gcc 4.5, which support -march=atom -mtune=atom, did you ever try
it? there are gcc 4.5 rpm package in opensuse factory.



our gcc also supports this.

-march=atom does not gain you any performance, but makes things a pain for the 
build
system... so we're not doing that.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] after updates, X still refuse to work!

[Arjan van de Ven]

On 4/8/2010 1:57, An Yang wrote:

在 2010-04-08四的 16:02 +0800，Roger WANG写道：

An Yang writes:

>  Hi, I find 66 updates in meego-devel repo today, include kernel,
>  Xorg-server and Xorg-intel-driver, but when I updates all the
>  packages, X still refuse to work.

Could you provide more information than"refuse to work"?

just type X in the command line.


but that's not how you're supposed to start X.

how about typing

telinit 5

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

Re: [MeeGo-dev] Proposal for a Debian working group denied

[Arjan van de Ven]

On 4/8/2010 5:39, Jeremiah Foster wrote:


Well there are things like fastboot too which might be nice to package. In any 
case, I'll join the alioth project.


sorry you're hitting a pet peeve of mine...

fastboot is not a patch or a package it's how the OS is set up.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] after updates, X still refuse to work!

[Arjan van de Ven]

On 4/8/2010 18:50, An Yang wrote:

I have installed uxlaunch from repo, but still got X failed in VT7.



uxlaunch does not start X in vt7...

it starts it in the current tty (which tends to be 2; over time we'll move this 
to 1)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Proposal for a Debian working group denied

[Arjan van de Ven]

On 4/9/2010 5:58, Jeremiah Foster wrote:


On Apr 8, 2010, at 7:53 PM, Arjan van de Ven wrote:


On 4/8/2010 5:39, Jeremiah Foster wrote:


Well there are things like fastboot too which might be nice to package. In any 
case, I'll join the alioth project.


sorry you're hitting a pet peeve of mine...

fastboot is not a patch or a package it's how the OS is set up.


Is there a git repo or documentation I might look at to get a better 
understanding?


you have the OS image...

really fast boot is not one package or one software component. It's *ALL* about 
how the whole OS is set up.
(yes there are software items in various places, but if you only look at those 
you don't get any result)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Why writing DPI value hardy in uxlaunch?

[Arjan van de Ven]

On 4/13/2010 2:53, Zhao, Juan J wrote:

Hi all,
I have found that when running uxlaunch, it send "-dpi 120" to Xorg. 
Why doing this?
I have found that this is written hardly in xserver.c.




this is on the request of our UI designers; it turns out that most hardware 
lies badly about it's dpi and it's not possible
to get a consistent experience without setting it to a fixed value.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Why writing DPI value hardy in uxlaunch?

[Arjan van de Ven]

On 4/13/2010 17:56, Zhao, Juan J wrote:

Yes, here is one bug in my platform. The characters are in a mess with
dpi 120. And the command option sent to X has the highest priority and I
can not set the specific DPI value by xorg.conf except using the
workaround "xrandr --output default --dpi 96".



it is very unlikely that your platform has an actual dpi of 96, so when we 
provide a
mechanism to provide the actual DPI, you will still hit your bug... I suspect 
you have
some work to do ;-)

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

Re: [MeeGo-dev] can not startx on MeeGo

[Arjan van de Ven]

On 4/16/2010 1:00, USA Linux UAE wrote:

you need to type uxlaunch.



actually

telinit 5

and just go to runlevel 5.

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

Re: [MeeGo-dev] patches for fixing ARM build

[Arjan van de Ven]

On 4/19/2010 2:47, Roger Quadros wrote:

Hi,

I have some patches for fixing ARM build and some patches for N900 build
for meego kernel.
What is the best way to get these patches into
meego-os-base/kernel-source:master and Meego OBS Trunk:kernel?

Is a gitorious merge request sufficient?


no



Is there a different mailing list for kernel discussions where patches
get reviewed?


bugzilla or meego-dev please...

(and as per the rules on meego.com.. substantial kernel patches need to have 
their upstream submission
information with them)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

+n900: kernel.spec.in series makespec.pl
+   @touch N900;
+   @perl makespec.pl<  kernel.spec.in>  kernel-n900.spec ;


why make a separate spec like this? sounds completely unneeded to me
for arm it will only build the n900 anyway right now


-tmp-arm-config: config-arm-generic config-generic
-   perl merge.pl $^>  $@
-
-kernel-n900.config: config-arm-n900 tmp-arm-config
-   perl merge.pl $^>  $@
+kernel-arm-n900.config: config-arm-n900
+   cp $^ $@


please don't do this and use our hierarchical configuration system
it's very important for meego to have as consistent configurations as possible.






@@ -676,13 +683,13 @@ for cfg in kernel-*.config; do
  done

  # now run oldconfig over all the config files
-for i in *.config
+for i in %{all_arch_configs}


please always run all oldconfigs for all architectures for each build.
this way a developer that adds a config option is reminded to add it to all the 
right places
on his own machine, independent of what architecture he is currently building 
on.



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

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

On 4/20/2010 3:57, Roger Quadros wrote:

Hi,

It seems all_arch_configs is not set correctly for x86 builds.

in current kernel.spec, for x86,

all_arch_configs is kernel-*.config

This is wrong as it will include non x86 configs too thus resulting in
build failure.



it should not. Because the other arch configs get done with

make ARCH=arm oldconfig

and that should succeed.

It is really important that we validate the configuration of all architectures 
for
each build, to avoid developers breaking other architectures.. it's not a build 
time issue;
oldconfig is plenty fast.


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

Re: [MeeGo-dev] Adding a kernel config to the MeeGo kernel source

[Arjan van de Ven]

On 4/20/2010 8:05, Carsten Munk wrote:

Current documentation only covers how to make kernel patches and a
brief mention of the seperation between a generic config with common
options and then having kernel configs which inherits from the generic
config.

Also, 'CONFIG_X86_32=y' in config-generic?


that just means that 32 bit is used for all x86 builds by default.

all options you put in config-generic that are not present for the architecture 
in question will just be ignored...
(and that's just fine)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] VT_GETMODE failed Function not implemented

[Arjan van de Ven]

On 4/20/2010 1:58, paler.tw wrote:

When I try to launch Xorg, it show "xf86OpenConsole: VT_GETMODE failed
Function not implemented"
Is there any thing wrong about my image or Xorg?



how are you starting X???

I assume you're doing a runlevel 5 thing?
(telinit 5 or so)

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

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

I notice there's a config-generic. What is this supposed to be for?
I'd expect it to contain the policy level kernel decisions like yes/no for
process accounting, ipv6, netlink, security etc.




basically how it works is that you have

config-generic   -- contains all standard answers for all config options
config--generic -- architecture specific overrides on top of 
config-generic
config- -- overrides that are board specific on top of 
config--generic


the goal for the last two config files is to be as small as possible; basically 
any option
that is not strictly required to be different should not be in them.

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

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

On 4/20/2010 8:44, Arjan van de Ven wrote:


I notice there's a config-generic. What is this supposed to be for?
I'd expect it to contain the policy level kernel decisions like yes/no
for
process accounting, ipv6, netlink, security etc.




basically how it works is that you have

config-generic -- contains all standard answers for all config options
config--generic -- architecture specific overrides on top of
config-generic
config- -- overrides that are board specific on top of
config--generic


the goal for the last two config files is to be as small as possible;
basically any option
that is not strictly required to be different should not be in them.

_


just to be clear; the later two are *overlays*. They inherit all options from 
the previous layer in the stack
that are not in these config files themselves.
Typically on a PC like platform, the platform specific one tends to be around a 
dozen options only, the rest is generic.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] VT_GETMODE failed Function not implemented

[Arjan van de Ven]

On 4/20/2010 18:18, paler...@gmail.com wrote:

I use the Xorg.
Is it a wrong command?



yes please use "telinit 5" to go to graphics mode...

starting a graphical session is a bit more involved than only starting the X 
server ;(

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

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

On 4/21/2010 0:22, Roger Quadros wrote:

ext Arjan van de Ven wrote:

+n900: kernel.spec.in series makespec.pl
+ @touch N900;
+ @perl makespec.pl< kernel.spec.in> kernel-n900.spec ;


why make a separate spec like this? sounds completely unneeded to me
for arm it will only build the n900 anyway right now


In future we should see more ARM platforms. we cannot say that arm = N900.


so? just stick it in kernel.spec.




Currently config-generic is more x86 specific it even has ARCH=x86.
so currently config-generic is broken.


so fix it ? But what you mention is not broken. It's by design.
config-generic is the superset of all config options.



And how can we ensure that this config-generic is compatible to all
platforms?


I think you misunderstood; config-generic is the basis for the configs, and 
architectures override
individual pieces they need and then the board config overrides on top of 
that.
and any option that does not actually exist for the platform will go away 
automatically.



please always run all oldconfigs for all architectures for each build.
this way a developer that adds a config option is reminded to add it
to all the right places
on his own machine, independent of what architecture he is currently
building on.



this is the snippet which runs before the run oldconfig

# Remove configs not for the buildarch
for cfg in kernel-*.config; do
if [ `echo %{all_arch_configs} | grep -c $cfg` -eq 0 ]; then
rm -f $cfg
fi
done

So are u suggesting that this must not be done?



correct

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

Re: [MeeGo-dev] [PATCH 1/10] OMAP: DSS2: Add Kconfig option for DPI display type

[Arjan van de Ven]

On 4/21/2010 1:12, Roger Quadros wrote:

From: Roger Quadros

Patch-mainline: 2.6.35?
Git-repo: 
http://www.gitorious.org/linux-omap-dss2/linux/commit/36b33efe80eb07e3447107c2bdba3c674c10a41a

This allows us to disable DPI on systems that do not have it


this does not look like a very pretty patch to me;


+#ifdef CONFIG_OMAP2_DSS_DPI
dpi_exit();
+#endif


at least, Linux style is to make dpi_*() a noop i the header via one global 
ifdef in the .h,
rather than doing ifdefs all over the code
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

On 4/21/2010 6:22, Roger Quadros wrote:


Isn't it simpler to have one config file per variant than doing this
automagical merging with 3 config files?


absolutely not.
not only do you then need to edit 15 files each time a new config option comes 
into life,
it becomes totally impossible to keep consistency between the config files.


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

Re: [MeeGo-dev] [PATCH] Fix ARM N900 build

[Arjan van de Ven]

On 4/22/2010 0:08, Roger Quadros wrote:

ext An Yang wrote:

� 2010-04-21�� 08:04 -0700�Greg KH���

As someone who has maintained kernels with a few dozen config files for
a long time, for different arches and flavors, no, this seems much
easier to keep everything in sync properly.

Let's try it and see, individual config files are very hard to ensure
that they are consistant.


absolutely right. consistant means less mistake.

but to solve is problem, the kernel maintainer should have a clear
maintain rules.
which driver should be in, which driver should be module, which driver
should be out?


Right.

This is what i think.

Minimally there should be 2 config files

1) config-generic
2) config-platform (e.g. config-menlow or config-n900)

config-generic should only stuff that is not specific to any
Architecture. It definitely cannot have any Kconfig option that comes
from arch directory. So usually config-generic would only contain
Network protocols, File systems. I don't think this should contain any
device driver options.


I disagree. It should be the superset of everything possible, as much as 
possible.
That way, anything that is "don't care exactly" for a platform/board will be 
consistent
no matter what.



I don't think it is necessary to have an additional config-arch-generic
for ARM since for example we can't have a config-arm-generic that keeps
all ARM platforms happy and is at the same time optimal.


actually that's based on an incorrect assumption. You can and should pick sane 
arm defaults
that override config-generic... and specific boards then only need to do the 
minimal deltas.

it's perfectly fine for a specific config option to be in all three of 
config-generic, config-arch-generic
and config-board; the merge process will make sure that the board one wins..
but for all options that are not in config-board the generic ones win.

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

Re: [MeeGo-dev] Booting IA 32 MeeGo without real mode int 13 BIOS support

[Arjan van de Ven]

On 4/22/2010 12:14, Picard, Tom S wrote:

Is it possible to boot (and install) Meego on an Atom Platform with UEFI
compatible BIOS, without the real mode dos (int 13) compatibility layer?


the netbook builds do not have UEFI support currently.
this is not a fundamental limitation of "MeeGo" but more a property of those 
specific builds.

Linux does support 64 bit UEFI, but in 32 bit this support is severely lacking
(someone once submitted code for it but it is effectively unmaintained since; I 
would
quite strongly recommend against assuming it's a productizable solution at this 
point)



I am working with a BIOS vendor and would like to do this in order to
accomplish fast boot for an InVehicle Infotainment platform



is the platform 64 bit capable? Using a 64 bit kernel could be an outcome
for making this work; note that adding UEFI also needs installer/bootloader/etc
work that should be scheduled and resourced.

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

Re: [MeeGo-dev] Booting IA 32 MeeGo without real mode int 13 BIOS support

[Arjan van de Ven]

On 4/22/2010 15:09, Picard, Tom S wrote:

Greg, Arjan,

Thanks for advice, after further discussion with BIOS engineer,
It is NOT that I/this project explicitly require UEFI.

What we require is that the Linux bootloader (grub or whatever MeeGo uses (I 
know Moblin used Grub)) NOT have transitioned into 16 bit real mode when it, 
calls BIOS for disk reads.


MeeGo uses syslinux for netbooks and most other IA platforms.



I assumed that meant UEFI, but maybe not.
Is there any other way.




Adding HPA to the CC.. as author of syslinux he might want to chime in
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] [PATCH 00/10] Patches for N900

[Arjan van de Ven]

On 4/26/2010 3:27, Poussa Sakari wrote:

Arjan,

I think we should integrate the patch set to the meego kernel. In my
mind it meets the criteria that the patches are on their way to upstream.



yeah they're on their way just fine.

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

Re: [MeeGo-dev] how to start developing on MeeGo?

[Arjan van de Ven]

On 4/26/2010 16:30, Graham Cobb wrote:

On Monday 26 April 2010 20:58:34 Graham Cobb wrote:

I am trying that now.  I have now managed to boot a MeeGo Intel image (in
QEMU).  Where can I find an RPM repository with all the tools I need (svn
is the first one)?


I think I have found the answer to my own question.  The following two
repositories seem to be the ones:

http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/
http://repo.meego.com/MeeGo/devel/extra/repo/ia32/os/

I have found subversion, but I still can't find nfs -- anyone know how I can
install NFS?



I would strongly suggest using sshfs instead of nfs
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Kernel process comment

[Arjan van de Ven]

On 4/28/2010 9:05, Bradley Smith wrote:

When exactly did Intel solely become responsible for kernel tree?


It's not Intel solely being responsible.

But Intel is a large contributor to both the kernel and meego;
and obviously many of the meego maintainters will be from Intel, just like
many maintainers will be from the other obvious big contributor, Nokia.

Also I don't understand what the beef is. Really.
The meego kernel has a very small delta on top of the kernel.org kernel. Do you 
complain
that Linus Torvalds is the maintainer for the kernel.org kernel.. and that 
since he works for LF he can't be?
Of course you don't!

If you want to improve the MeeGo kernel, by all means, send 
patches/suggestions/etc. Even better, get those patches
into Linus' kernel! Do you have one single example where we did not follow one 
of your suggestions for the kernel?

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

Re: [MeeGo-dev] Kernel process comment

[Arjan van de Ven]

On 4/28/2010 13:29, Andrew Flegg wrote:

Arjan wrote:


It's not Intel solely being responsible.


[...]


Also I don't understand what the beef is.


The problem, as I see it, is that *any* Intel employee can bypass the sign-off 
procedure for the MeeGo kernel, whereas no-one else can.

Intel may have internal processes that prevent that, but it's not something the 
*MeeGo* project should rely on.

I'm fine with a defined group of Intel engineers being the initial gatekeepers 
of the MeeGo kernel, but an @intel.com email address shouldn't let you bypass 
those gatekeepers - which is the point that started this thread.



I think this indeed is a bug in the document for sure.

Ideally, we follow the exact same format for patches that lkml follows. And for sure, the output of "git format-patch" on a Linus git tree 
should be perfectly fine for us backporting a patch from upstream git should always be fine and clean.

I don't think we should make things more heavy weight than this.

If you want a patch included, and it's already upstream, posting the git-format-patch for that patch to the mailing list or bugzilla (with 
of course a few sentences of why you want this patch backported) should be all that's needed.

If your patch is not upstream quite yet, same format but with explanation of 
where it is at in the upstream process should be fine as well.

for non-patch additions, such as config changes... just sending an email with why/what/where. and we can either just do that or discuss 
more if there's side effects or other things the maintainers might be worried about. There's nothing wrong with some healthy discussion to 
get to the best outcome.

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

Re: [MeeGo-dev] [PATCH] Fix Config generation Logic

[Arjan van de Ven]

On 4/29/2010 7:52, Roger Quadros wrote:

Move x86 ARCH stuff from config-generic to config-x86-generic and
config-arm-generic. config-generic cannot contain ARCH_xxx stuff.


this is NOT a correct statement per se;
config-generic is a superset of various things!
in addition, most ARCH_HAS stuff is completely fine to be there, we run "make 
oldconfig"
over the output before using it which fixes any discrepancies

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

Re: [MeeGo-dev] Kernel process comment

[Arjan van de Ven]

On 4/29/2010 21:16, Greg KH wrote:

On Fri, Apr 30, 2010 at 12:03:17PM +0800, Yin Kangkai wrote:

We have no problem to add others outside of Intel into the MeeGo
kernel maintainer team, actually we welcome that, as long as he can
take the responsibilities.


Great, how does one go about signing themselves up to do this?



right now we're not quite ready for that as a project.
(needs a project structure to be more formalized as well as various legal contributor agreements created and agreed on by a whole bunch of 
lawyers)

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

Re: [MeeGo-dev] MIC2 policy about using closed source tools

[Arjan van de Ven]

On 4/30/2010 3:54, Carsten Munk wrote:

Hi,

Was looking into the code and was wondering if there's any problem
submitting patches against MIC2 which uses closed source tools (ie,
open source patches, but may execute closed source tools).

Things that come to mind is for example Nokia's FIASCO image generator
or other device makers firmware format makers. While it would be good
to have those fully open, this luxury may not always exist, but the
important thing is that we can build images for these things and flash
our own system..



while it's obviously nicer if such tools are open, I don't see a fundamental
issue by doing an exec() to such a tool in terms of open source issues.
this is the last stage of creating an image and is generally done by some
external program (eg for cd's it'd be mkisofs etc)


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

Re: [MeeGo-dev] Visual Service of the Meego OS Middleware. ???

[Arjan van de Ven]

On 5/9/2010 19:25, 张胜衡 wrote:

hi:

It tell the architecture of the Meego in this.
http://meego.com/developers/meego-architecture


MeeGo OS Middleware


  Visual Services

The Visual Services subsystem provides the core 2D and 3D graphics
capabilities for the platform, including support for rendering
internationalized text and taking advantage of underlying hardware
platform acceleration for graphics.


But my questions are:

 1. The information about the Virtual Services is so little that I
can not understander it well.
 Can anyone tell me where can I find more information about the
Virtual Services?


freedesktop.org has most of the stack;it's X, Mesa and such.



 2. If I chose meego, I must use the "underlying hardware platform
acceleration for graphics"?
 Can I use software acceleration for graphics instead of hardware ?


Nope... You really need to use hw acceleration. You can't currently do 
meaningful 3D
in software... and the MeeGo software stack greatly depends on fast and usable 
3D
(and apps can depend on this as well)



 3. If I use software acceleration for graphics instead of hardware,
what should I do ?


you really should use the hardware acceleration!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/11/2010 4:00, Ameya Palande wrote:

Hi,

I wanted to know why Btrfs is selected as default file system for MeeGo.
Following text is copied from Btrfs kernel Kconfig option:

Btrfs filesystem (EXPERIMENTAL) Unstable disk format


the Kconfig text is out of date.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/11/2010 4:00, Ameya Palande wrote:

Hi,

I wanted to know why Btrfs is selected as default file system for MeeGo.


we made a positive choice for btrfs for a list of reasons
* It's the future of Linux filesystems. We had a case where the old guard (ext3) is getting retired, and there are two new filesystmes on 
the table (btrfs and ext4). We felt that if we picked ext4, we'd have all the pain of a new filesystem, and we'd then change again a year 
later to btrfs.

* BTRFS has a strong focus on data integrity, while many other filesystems 
focus mostly on metadata integrity. For most cases this
  extra focus is free, however for database applications there is a moderate 
performance impact.
  This includes things like duplicating key metadata structures on disk twice, 
having data checksums, can mark files as critical and for
  duplication (RAID1)... but basically the whole COW design (never overwrite 
data) means that you never get garbage in files.
* BTRFS supports on-disk compression, giving both a smaller footprint (factory 
preload time!) as well as higher throughput on really slow
  storage.
* BTRFS has writable snapshots. This opens the door to features in MeeGo 1.1 
like atomic package updates (already a Fedora 13 feature with
  btrfs) but also the "Restore to factory defaults" becomes easy: just blow 
away the snapshot and create a new one and the device is as new.
  You can even use it to have "true multiple users" in the system, both users 
have the whole device for themselves with a boot time switch
* Performance for small files. Small files are very common, and BTRFS stores 
these very efficiently on disk. Whereas other filesystems
  generally need upto 3 IOs (and thus 3 seeks if your storage rotates) to 
access a file, BTRFS stores everything together and needs only 1
  IO.
* Built in defragmentation - performance feature for things like boot time
* Storage pools: Add and remove storage on the fly. (Yes even for phones this can matter... lets say you have a small flash chip you 
populate in the factory; this feature allows you to then expand to a secondary storage during first use as if it's one big filesystem... no 
more /opt issues etc)

* ...

well it's a long list of things that made us chose btrfs over its competition.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/11/2010 6:47, Graham Cobb wrote:

On Tuesday 11 May 2010 14:03:00 Arjan van de Ven wrote:

On 5/11/2010 4:00, Ameya Palande wrote:

Hi,

I wanted to know why Btrfs is selected as default file system for MeeGo.
Following text is copied from Btrfs kernel Kconfig option:

Btrfs filesystem (EXPERIMENTAL) Unstable disk format


the Kconfig text is out of date.


I am interested in the answer to the question, however.  Why was Btrfs chosen?
I asked before but got no answer.


is my previous mail useful for this?



I'm not questioning the decision -- I would like to understand the attributes
of btrfs which have made it worth your while to choose it as, at first sight,
it seems a very strange choice for a small, low-end system.


the data compression and integrity features are actually quite attractive for 
low end systems..
as are snapshots due to the easy "restore to factory defaults"


I would also
like to understand the possible implications of someone choosing to use MeeGo
with a different filesystem.


if you pick another filesystem like ext3, you're going to run in a 
configuration that we don't test extensively,
and you're going to lose performance in addition to all the snapshotting/etc 
capabilities that btrfs gets.
But I suspect it'll run fine otherwise...


Also, will it be used on the handset platforms as well as netbooks?


this is a "it depends"; if you have "Real Flash" (not ssd) exposed on the 
platform, you'd currently not run btrfs, but a
flash filesystem instead (ubifs or similar). There are plans to extend btrfs to run on real flash as well... but that's at this point just 
plans not code.


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

Re: [MeeGo-dev] Kernel Patches missing Patch-mainline tag

[Arjan van de Ven]

On 5/11/2010 10:21, Ameya Palande wrote:

Hi,

Following patches (total 70) are missing the mandatory "Patch-mainline:"



since Patch-mainline: is not a requirement in an upstream git patch,
we cannot and will not require such tag inside the patch either.
We really do not want to do more (or less) paperwork than an 
upstream-included-in-git
patch takes. And that includes the ability to do git format-patch on the 
upstream
git tree and put the patch in as is.

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

Re: [MeeGo-dev] does meego support SDL？

[Arjan van de Ven]

On 5/11/2010 0:58, ws we wrote:

Hi all,
  I want to port  my SDL based program to meego ,  It seems SDL worked
well on Android ?
will Meego support SDL?



SDL is not a recommended API or component, and if you use it your application is
likely not MeeGo compliant

having said that, we may well have SDL in the repositories, but likely not in 
the default installs...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/11/2010 13:26, JD Zheng wrote:

Besides the overhead btrfs might introduce, I am wondering how it work
on flash chip and how it compares with flash fs like ubifs.


currently btrfs does not run on "real flash".



As far as I understand, btrfs can work with SSD but not on bare flash
chip and that was one of reasons we didn't see ext3 on flash chip.




however, btrfs is ALMOST like a log structured filesystem already, so there
are some research ideas on how to make it work. Assume that is 1+ year out 
though..
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/12/2010 12:22, Greg KH wrote:

On Tue, May 11, 2010 at 01:09:16PM +0100, Neil McGovern wrote:

On Tue, May 11, 2010 at 02:00:46PM +0300, Ameya Palande wrote:

Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET
FINALIZED. You should say N here unless you are interested in
testing Btrfs with non-critical data.



I would tend to agree, btrfs looks great, but it's just not ready yet.


ready for what?  Looks to be ready for MeeGo :)


yup it is...

blanket "it's not just ready" not based on actual arguments are a bit useless 
to me.
we've been using BTRFS in all builds for a long time now, and frankly we have 
had more
issues with the ext3 side of the world than with btrfs ;)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/12/2010 14:45, Warren Baird wrote:

On Wed, May 12, 2010 at 3:37 PM, Greg KH  wrote:


Neil, what is the specific problems you are having with btrfs on "real"
sized storage devices (not for 1-2Gb devices, that's a different issue.)



Greg - on an N900, 1-2Gb *is* a real partition size...If Brtfs
doesn't work well on that size partition, I don't think we can
standardize on it as *the* filesystem for MeeGo.

Warren


btw we're actively working with/in btrfs to reduce this overhead.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

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

[Arjan van de Ven]

On 5/12/2010 17:38, David Austin wrote:

My two cents' worth as a N900 owner:  I feel that the advantages of btrfs
far outweigh the costs even on a platform like the N900.  Losing 30%
of storage space is not pretty but the /opt "solution" is an ugly hack
that has wasted considerable dev time and could be neatly sidestepped
by btrfs.

Also, if btrfs is the preferred filesystem for MeeGo then future devices
will have better configurations to support it.  It's pretty clear that the
N900 is going to be the minimum (or worst) hardware that MeeGo will
run on.  We have to expect that the N900 will suffer a little because
of that.




and again.. we're working with the upstream developers to reduce this "cost".
Most of it is a pessimistic estimation of how much space is needed, to be on 
the safe side no matter
what.

The estimation algorithms have been improved in the development tree for btrfs, 
and we're looking
at how/if to backport this optimization to MeeGo 1.0.

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

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

[Arjan van de Ven]

On 5/12/2010 20:25, JD Zheng wrote:

"btrfs as default fs" isn't a clear statement.


"btrfs is default for block based storage" is a more accurate statement.



-- btrfs can only use on HD/SSD/MMC, which is actually used in
netbook/desktop/PC like device.
-- Currently, mobile phone, etc. doesn't use these but bare flash
instead as main persistent storage, so that jffs2/yaffs2/ubifs applies.


I'd think ubifs is the FS of choice both Intel and Nokia experts are behind 
that choice.

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

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

[Arjan van de Ven]

On 5/14/2010 1:32, Neil McGovern wrote:

On Wed, May 12, 2010 at 12:37:44PM -0700, Greg KH wrote:

Neil, what is the specific problems you are having with btrfs on "real"
sized storage devices (not for 1-2Gb devices, that's a different issue.)



The remaining issues with btrfs that I'm aware of, (and please note, I'm
really quite excited by it, it'll be great when it's ready)

1) On disk format - This was due to be stabilised by 2009, and it's
still not. A standardised on disk format must be a pre-requisite to
using it as a default file system.


it is stabilized.. I don't understand why you claim it's not.
The upstream developers say it is (but of course they reserve the right to 
extend
it with new features, just like ext3 and ext4 have been doing for years),
and have shown since 2.6.30 or so that they can keep it stable.



2) File system support - various utilities still don't support btrfs,
especially bootloaders (RedBoot, grub etc)


MeeGo uses syslinux as bootloader, and we've added support to that (for 1.1). 
My understanding
is that grub2 also works with btrfs, but we're not using that.



3) btrfs still does not handle all out-of-space conditions gracefully


we haven't seen any oops like things since 2.6.33-stable anymore
earlier we saw one or two, and worked together with the upstream developers
to resolve those quickly.


4) lvm useage requires write-caching turned off, but if it's not, it
can't handle the corruption


* MeeGo does not support LVM.
* Why run LVM when the filesystem has a volume manager inside it
* EXT3/4 have the same issue. Running with write caching on and without 
barriers (because that's the change LVM does)
  is just asking for trouble, btrfs or ext3.. does not matter.

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

Re: [MeeGo-dev] How to see graphics for Meego in a VM

[Arjan van de Ven]

On 5/15/2010 11:29, adhyas.avas...@nokia.com wrote:

I built another vmdk image with the repo at 
http://repo.meego.com/MeeGo/builds/trunk/daily/core/repos/ia32/packages/ in the 
hope that I can see some graphics screen but it just hangs like other images.
Does the kernel not have appropriate drivers in the image at this repo? Should 
I try compiling the kernel image with some specific graphics drivers to see the 
graphics boot? I would really like to see some Graphical UI before 1.0 is 
released. Should I try qemu instead of vmware?

On bugs.meego.com, I can see several bugs related to Graphical UI, how can I 
reproduce the developer environment on my box? What repo should I use?

at least for the netbook/x86 UI, your VM is not going to work... really. I don't want anyone to have false hope on this it's just not 
something that's going to work; and even if someone spends a lot of time to get it sort of working, it's going to be a rather shitty

experience. We've seen in this since Moblin 2.0 days and nobody really got this 
to work nice.
Now if you want you can blow some hours of time on this, and by all means, 
don't let me stop you.
But I want to at least not give you or anyone else false hope or false 
expectations upfront


no 3D acceleration -> No UI. Seriously.
in fact, for netbook: if your X server or gfx driver would need root privileges 
-> no graphics in default image.
(yes you can make your X server setuid-root yourself and accept the security 
risk.. but our default images
behave securely in this regard)

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

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

[Arjan van de Ven]

On 5/16/2010 10:11, Jan Knutar wrote:


Time taken for rsync of 2gbyte of data:

ext2:  110m28.319s
ext4:   29m42.082s
btrfs:   46m36.385s
nilfs2: 16m02.786s


did you have compression on or off? did you have checksums on or off? (if so, 
what kind of cpu did you have?)
was SSD mode being used?




ext3 was same speed class as ext2. I did these tests some months ago and
didn't seem to write down the ext3 results.

-o noatime for everything except btrfs where I used -o
noatime,ssd_spread,compress

Kernel 2.6.32


oh.

yeah btrfa also got a lot better in .33 (and again in .34)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] multiuser login

[Arjan van de Ven]

On 5/17/2010 3:30, linuxm...@gmx.de wrote:

Hello.

After scanning the wiki, the mailing list archive and the forum I decided to 
join this mailing list to get an answer to the following question:

Is it planned to provide a graphical multiuser login screen in the first 
release (or maybe in future releases) of MeeGo?


for the netbook UI, the first release will not have such a thing.

MeeGo is primarily aimed at very personal devices (for example, some surveys show that there are classes of people who rather ditch their 
girlfriend/boyfriend than to lose their phone). In light of this personal nature, having multiple users isn't our first priority.

We are looking for future releases at things like "guest mode" or "kid mode" 
kind of things to allow guest users etc to use the device..
... but this is research at this point, not plan.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] multiuser login

[Arjan van de Ven]

On 5/17/2010 12:06, Glen Gray wrote:

While I agree that the primary netbook audience will only care about
thier own account, I'd like to know if there will be wake from sleep
login security feature? This was something badly missing from moblin IMO



we have this including the capability to ask for a password at boot
(both implemented using the screensaver)

Moblin 2.1 mostly had this, but there were some interesting details missing
(like the screensaver window being layered wrongly ;-)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Bluetooth

[Arjan van de Ven]

On 5/18/2010 11:02, Muthu Kumar wrote:

Could someone provide any details on Bluetooth support on Meego? I'm interested
to know which Bluetooth stack (Bluez etc) will be used,


of course it's bluez; there is no alternative even if we wanted to ;-)

(even android uses bluez ;-)


host interface
support (usb,SDIO etc)


this is a kernel driver question; it's not so much the interface, but the actual 
bluetooth "dongle"
that needs support.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Trouble porting Qt app to Intel Z5xx SBC

[Arjan van de Ven]

On 5/18/2010 12:32, Jack Nadelman wrote:


Which MeeGo release (if any) should I try on the Eurotech.com Intel Atom
Z5xx SBC?


unfortunately, neither MeeGo nor Moblin 2.x have support for the Menlow 
platform,
and also unfortunately, I don't see that changing any time soon.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] MeeGo compliance

[Arjan van de Ven]

Does it mean that an OSV can merge its own patches on top of the source
packages from the reference MeeGo repository?

For example, Mandriva as a distribution editor is interested in
maintaining a common set of source rpm packages for both its classical
"Mandriva Linux" distribution and its MeeGo-based distribution, to
factorize maintenance.

Can we be called MeeGo-compliant as long as userspace is ABI compliant,
even if we have our own patches in kernel/udev/qt/dbus/...?




you should be able to add your own patches on top of the meego packages,
provided that these patches don't break the application ABI (of course); common
sense applies wrt this...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] MeeGo compliance

[Arjan van de Ven]

On 5/19/2010 10:30, Thiago Mac

Maybe distros that are binary-compatible with MeeGo but aren't building on top
of MeeGo need a separate sticker. This could include the .deb-based distros.



I don't think that at this point that would be called compliant.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] What is the default file system for Meego, when using Nand flash directly ?

[Arjan van de Ven]

On 5/19/2010 17:45, zhangshengheng wrote:

Hi:
As I know, Meego will use the Btrfs as the default file system.But in my
opinion, Btrfs can be used for SSD, so it will be good for netbook. When
used by Media phone, it will be not suitable. The Media phone usually
use the Nand flash directly instead of SSD.
So, when we use Nand flash directly, what is the default file system for
Meego ?
UBIFS?



I'd think UBIFS is indeed the prefered filesystem.
I don't know if we'll see many devices with raw nand; I get the impression
a lot of people are increasingly switching to "managed nand"...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Installation of Meego on Dell Latitude XT2 tablet PC

[Arjan van de Ven]

On 5/21/2010 13:06, adhyas.avas...@nokia.com wrote:

The installation works fine. I should say, pretty fast as well. Touch
screen works out of the box (Could not make the pointer’s right click
work on Meego though).

Then I pointed meego-updates.repo file to builds/trunk/daily/core
packages and ran yum update (installed all the packages).

On reboot, it says:

INIT: cannot execute “/usr/sbin/moblin-dm”

INIT: Id “x” respawning too fast: disabled for 5 minutes

What does that mean and what can I do now?

Would there be a separate updates repo for 1.0 releases that work much
better?



we had an unfortunate compatibility break that we did not catch in time.
to fix it you need to log in, and edit /etc/inittab for the moblin-dm line
to say "meego-dm" instead of "moblin-dm".


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

Re: [MeeGo-dev] Future of hildon?

[Arjan van de Ven]

On 5/22/2010 23:40, Till Harbaum / Lists wrote:


So is there some plan to include hildon into meego?


there is no plan for this at this time.
I would have said "something great for the cummunity repo" if it wasn't for 
hildon patching core GTK in an incompatible way ;-(
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Future of hildon?

[Arjan van de Ven]

I also wonder what is the real status of this community support, and the
willingness of the current Hildon and/or GTK+ maintainers and developers
to bring Hildon and Hildon based applications to the MeeGo community
repositories.

There has been some discussion about this at GNOME's mobile-devel-list
but honestly I had expected a more concrete or articulated answer by
now. See the whole "What would you do to encourage application
developers on GNOME Mobile?" discussion starting at
http://mail.gnome.org/archives/mobile-devel-list/2010-April/msg3.html
and even my own post back in February that got basically no traction
from anybody involved in GTK+ development -
http://mail.gnome.org/archives/mobile-devel-list/2010-February/msg00010.html




just to clarify; "GNOME Mobile" is not part of MeeGo really (although on the 
netbook,
we've borrowed some components for the UI implementation), and nobody should 
depend
on this being there for app development for MeeGo. Use Qt for that.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Why is the download URL hidden? or "why control freaks make me mad"...

[Arjan van de Ven]

On 5/26/2010 13:40, Ibrahim Haddad wrote:

Collabora was kind to offer us a mirror: http://meego.collabora.co.uk



we have lots of mirrors, including mirrors.kernel.org
for all the free-to-distribute bits that's not the problem
(we have I think between 5 and 10 gigabit of mirror capacity)

we're happy to add more always of course
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Installing MeeGo 1.0 Issue

[Arjan van de Ven]

On 5/26/2010 19:09, kelvinz wrote:

Hi all,

I tried to install MeeGo 1.0 netbook release on N270 and N470.
The installing process stopped at installing bootloader. Restart the
netbook and only found the vmlinux.. in the /boot directory.
I use the installed grub booting meego for walking around.

Does MeeGo 1.0 use grub or other for booting? if not use grub, how to
boot MeeGo if no other bootloader installed?


MeeGo uses syslinux, not grub.

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

Re: [MeeGo-dev] Location of Kernel Headers

[Arjan van de Ven]

On 5/26/2010 22:54, adhyas.avas...@nokia.com wrote:

Where are the kernel headers located for Meego 1.0? I tried yum install 
kernel-headers and it says they are already located.
When I tried to install some custom apps that use kernel headers they complain 
that the headers are not located in the usual place, so I should check with the 
distro documentation.
When I try to compile kvm-kmod on Meego, it complains that the kernel version 
not found.


the kernel headers for applications (and glibc) are in the kernel-headers 
package.

if you want to compile kernel modules instead, you need to have the 
kernel-netbook-devel package instead.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] How can I start developing application for Meego.

[Arjan van de Ven]

On 5/27/2010 5:20, Abdul Mateen wrote:

Hi,
How can I start development, I am from strong Android background
Developer, is there any SDK available for download, that includes the
toolchains / tools to setup. and I can start developing Meego
Applications. OR that is planned in June ?
\

there's a bunch of things, various items are put on the website already,
and there's a qtcreator package with the basic QT development environment...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Qt for all UX? (was: Re: Qt/Quick Netbook UI)

[Arjan van de Ven]

On 5/27/2010 10:37, JD Zheng wrote:

Hi,

We were told Qt will be the primary UI toolkit (and App framework) for
MeeGo from the day we heard MeeGo,  but seems people, esp. developer who
is doing *real* UX development, have different ideas about it (see
original thread).


All applications/etc will use Qt. Even the MeeGo ones. We have some legacy apps
that don't use Qt, but those are on a path to be converted to use Qt or be 
replaced.
(and there may be 3rd party legacy apps that will keep using what they do; 
Chromium
could be an example of that)

The Window Manager (and it's very close friends) are not "Applications" in this 
sense,
and may use technology that is appropriate for their problem domain, which may 
or may
not include Qt.



Also if we were going to do Qt for some UX and, for example, GTK for
others, do we still think we would have a unified platform? Shall we
focus on one framework after 1.0 was out?


GTK is only available to run legacy applications, and should not be used
for any new development for MeeGo.
(This "for legacy only" also means that for example we're unlikely to go to gtk 
3.0
when it comes out, but rather we stay at the 2.x version train)


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

Re: [MeeGo-dev] Kernel Process Changed

[Arjan van de Ven]

On 5/27/2010 16:52, Greg KH wrote:



Who at Intel is responsible for the kernel these days?


I am.


What happened to
the proceedures they said would be put into place?


they're being finalized right now and documented.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev