MeeGo-dev Digest, Vol 3, Issue 20
Send MeeGo-dev mailing list submissions to
meego-dev@meego.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.meego.com/listinfo/meego-dev
or, via email, send a message with subject or body 'help' to
meego-dev-request@meego.com
You can reach the person managing the list at
meego-dev-owner@meego.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MeeGo-dev digest..."
Today's Topics:
1. Re: OMTP Bondi - any plans yet? (Jose Manrique Lopez de la Fuente)
2. Re: OMTP Bondi - any plans yet? (Rogers, Rick)
3. Re: OMTP Bondi - any plans yet? (Jose Manrique Lopez de la Fuente)
4. Missing Messages & Issues posting to this list (Foster, Dawn M)
5. ADSL support (Leonardo Luiz Padovani da Mata)
6. Repository Working Group - next steps (David Greaves)
7. Re: ADSL support (Greg KH)
8. Re: ADSL support (Leonardo Luiz Padovani da Mata)
9. Re: mic.imgcreate.errors.MountError (paler.tw)
10. Re: how to start developing on MeeGo? (Tom Chen)
11. Re: mic.imgcreate.errors.MountError (Yang, Yi Y)
12. VT_GETMODE failed Function not implemented (paler.tw)
13. [PATCH] Fix ARM N900 build (Roger Quadros)
14. Re: Repository Working Group - next steps (Jeremiah Foster)
15. Re: Repository Working Group - next steps (Marko Vertainen)
16. Re: Repository Working Group - next steps (Glen Gray)
17. Re: [PATCH] Fix ARM N900 build (Roger Quadros)
18. Re: OMTP Bondi - any plans yet? (Nils Faerber)
19. NFC (Mr. Todorov Todor)
20. Re: [PATCH] Fix ARM N900 build (Arjan van de Ven)
21. Re: [PATCH] Fix ARM N900 build (Arjan van de Ven)
22. Adding a kernel config to the MeeGo kernel source (Carsten Munk)
23. Re: Adding a kernel config to the MeeGo kernel source
(Arjan van de Ven)
24. Re: Adding a kernel config to the MeeGo kernel source (Greg KH)
25. Re: VT_GETMODE failed Function not implemented (Arjan van de Ven)
26. Re: Adding a kernel config to the MeeGo kernel source
(Carsten Munk)
27. Re: [PATCH] Fix ARM N900 build (David Greaves)
28. Re: [PATCH] Fix ARM N900 build (Arjan van de Ven)
29. Re: [PATCH] Fix ARM N900 build (Arjan van de Ven)
30. How to discover screen size from Mx? (Elliot Smith)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Apr 2010 20:05:46 +0200
From: Jose Manrique Lopez de la Fuente <jsmanrique@gmail.com>
To: meego-dev <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] OMTP Bondi - any plans yet?
Message-ID:
<j2h66d9130a1004191105t694ad980wd081c16a2f412c5b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
Nobody has W3C into account? (even when they are getting input from
Nokia, BONDI, operators, browser developers,...)
http://www.w3.org/2009/dap/
That's the way!
2010/4/18 Nils Faerber <nils.faerber@kernelconcepts.de>:
> Rogers, Rick schrieb:
>> Nils,
> Hi Rick!
>
>> BONDI, JIL and WAC (add
>> http://www.wholesaleappcommunity.com/docs/whitepaper.pdf to your list)
>
> Ah, didn't know JIl and WAC yet, thanks ;)
>
>> all converge around web applications written to HTML5, with extensions
>> to support handset features that are beyond HTML5. I don't know of
>> anyone working on BONDI for MeeGo, but would be very interested in
>> learning anything you come across. I think you're right, it wouldn't be
>> that hard - maybe WAC is the place to focus moving forward? ?I know the
>
> I had a brief look at all three again, I started with WAC and stumbled
> accross an issue - I think... the governance. So I checked that again
> with all three.
>
> What I do not like about WAC is that it is 100% operator focussed and
> the name of the project makes IMHO their intention pretty clear
> "Wholesale Application" - they are only interested in creating a broad
> application market.
>
> While this is of course one of the valid goals it should not be the only
> one. As a developer I miss the "level of invention" here. The governance
> of WAC though suggests that selling applications is *the* driving factor
> for the project and to the few major players in it: There are a few core
> operators that build the board of directors and new (operator) members
> can only get a non-voting visitor seat in the board. No mention of other
> possibly parties (like vendors or makers) and especially not mention of
> third party developers e.g. from the open source.
>
> This sounds pretty limited - sounds like a pretty narrow minded club to
> me so I would personally not like to pursue that road. Also from
> technology standpoint it seems to me that they are only up to taking up
> existing bits and specify a (sub-)set they want to support in WAC. It
> does not seem that they want to actually do much own development.
>
> JIL is similar, only members are China Mobile, SoftBank Mobile, Verizon
> Wireless, and Vodafone, 100% operator driven again. But they are up to
> do own development and want to provide an SDK - well...
>
> In contrast to those two OMTP is a quite larger organisation, current
> OMTP members:
> http://www.omtp.org/Membership.aspx
> and Bondi seems to be pretty open, it is Apache licensed and announced
> as an open source project which at least suggests that open source
> developers can take some part in it.
>
> I should probably note that I am not affiliated with OMTP nor Bondi ;)
>
>> folks at Aplix and ACCESS were involved with the OMTP reference
>> implementation of BONDI.
>
> Yes, since they are LiMo foundation members (as is Wind River) and LiMo
> seems to go away from native applications towards Web2.0 someone had to
> do the job ;)
>
>> Rick Rogers
>> Wind River
> Cheers
> ?nils
>
> --
> kernel concepts GbR ? ? ?Tel: +49-271-771091-12
> Sieghuetter Hauptweg 48 ?Fax: +49-271-771091-19
> D-57072 Siegen ? ? ? ? ? Mob: +49-176-21024535
> http://www.kernelconcepts.de
> _______________________________________________
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
--
J. Manrique L?pez de la Fuente
http://www.jsmanrique.es
------------------------------
Message: 2
Date: Mon, 19 Apr 2010 11:08:01 -0700
From: "Rogers, Rick" <Rick.Rogers@windriver.com>
To: "Jose Manrique Lopez de la Fuente" <jsmanrique@gmail.com>,
"meego-dev" <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] OMTP Bondi - any plans yet?
Message-ID:
<5B86E4528138AE4189EF52D5C72B494401910C27@ala-mail09.corp.ad.wrs.com>
Content-Type: text/plain; charset="iso-8859-1"
HTML5 = W3C in this context
-----Original Message-----
From: meego-dev-bounces@meego.com [mailto:meego-dev-bounces@meego.com] On Behalf Of Jose Manrique Lopez de la Fuente
Sent: Monday, April 19, 2010 2:06 PM
To: meego-dev
Subject: Re: [MeeGo-dev] OMTP Bondi - any plans yet?
Hello,
Nobody has W3C into account? (even when they are getting input from Nokia, BONDI, operators, browser developers,...)
http://www.w3.org/2009/dap/
That's the way!
2010/4/18 Nils Faerber <nils.faerber@kernelconcepts.de>:
> Rogers, Rick schrieb:
>> Nils,
> Hi Rick!
>
>> BONDI, JIL and WAC (add
>> http://www.wholesaleappcommunity.com/docs/whitepaper.pdf to your
>> list)
>
> Ah, didn't know JIl and WAC yet, thanks ;)
>
>> all converge around web applications written to HTML5, with
>> extensions to support handset features that are beyond HTML5. I don't
>> know of anyone working on BONDI for MeeGo, but would be very
>> interested in learning anything you come across. I think you're
>> right, it wouldn't be that hard - maybe WAC is the place to focus
>> moving forward? ?I know the
>
> I had a brief look at all three again, I started with WAC and stumbled
> accross an issue - I think... the governance. So I checked that again
> with all three.
>
> What I do not like about WAC is that it is 100% operator focussed and
> the name of the project makes IMHO their intention pretty clear
> "Wholesale Application" - they are only interested in creating a broad
> application market.
>
> While this is of course one of the valid goals it should not be the
> only one. As a developer I miss the "level of invention" here. The
> governance of WAC though suggests that selling applications is *the*
> driving factor for the project and to the few major players in it:
> There are a few core operators that build the board of directors and
> new (operator) members can only get a non-voting visitor seat in the
> board. No mention of other possibly parties (like vendors or makers)
> and especially not mention of third party developers e.g. from the open source.
>
> This sounds pretty limited - sounds like a pretty narrow minded club
> to me so I would personally not like to pursue that road. Also from
> technology standpoint it seems to me that they are only up to taking
> up existing bits and specify a (sub-)set they want to support in WAC.
> It does not seem that they want to actually do much own development.
>
> JIL is similar, only members are China Mobile, SoftBank Mobile,
> Verizon Wireless, and Vodafone, 100% operator driven again. But they
> are up to do own development and want to provide an SDK - well...
>
> In contrast to those two OMTP is a quite larger organisation, current
> OMTP members:
> http://www.omtp.org/Membership.aspx
> and Bondi seems to be pretty open, it is Apache licensed and announced
> as an open source project which at least suggests that open source
> developers can take some part in it.
>
> I should probably note that I am not affiliated with OMTP nor Bondi ;)
>
>> folks at Aplix and ACCESS were involved with the OMTP reference
>> implementation of BONDI.
>
> Yes, since they are LiMo foundation members (as is Wind River) and
> LiMo seems to go away from native applications towards Web2.0 someone
> had to do the job ;)
>
>> Rick Rogers
>> Wind River
> Cheers
> ?nils
>
> --
> kernel concepts GbR ? ? ?Tel: +49-271-771091-12 Sieghuetter Hauptweg
> 48 ?Fax: +49-271-771091-19
> D-57072 Siegen ? ? ? ? ? Mob: +49-176-21024535
> http://www.kernelconcepts.de
> _______________________________________________
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
--
J. Manrique L?pez de la Fuente
http://www.jsmanrique.es
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
------------------------------
Message: 3
Date: Mon, 19 Apr 2010 20:23:56 +0200
From: Jose Manrique Lopez de la Fuente <jsmanrique@gmail.com>
To: meego-dev <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] OMTP Bondi - any plans yet?
Message-ID:
<k2n66d9130a1004191123we83eb851k64f408055f7b2aef@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Well, I think that W3C is more than HTML5, at least the Device APIs
Working Group is more focused on device and APIs, not in HTML5
2010/4/19 Rogers, Rick <Rick.Rogers@windriver.com>:
> HTML5 = W3C in this context
>
> -----Original Message-----
> From: meego-dev-bounces@meego.com [mailto:meego-dev-bounces@meego.com] On Behalf Of Jose Manrique Lopez de la Fuente
> Sent: Monday, April 19, 2010 2:06 PM
> To: meego-dev
> Subject: Re: [MeeGo-dev] OMTP Bondi - any plans yet?
>
> Hello,
>
> Nobody has W3C into account? (even when they are getting input from Nokia, BONDI, operators, browser developers,...)
>
> http://www.w3.org/2009/dap/
>
> That's the way!
>
> 2010/4/18 Nils Faerber <nils.faerber@kernelconcepts.de>:
>> Rogers, Rick schrieb:
>>> Nils,
>> Hi Rick!
>>
>>> BONDI, JIL and WAC (add
>>> http://www.wholesaleappcommunity.com/docs/whitepaper.pdf to your
>>> list)
>>
>> Ah, didn't know JIl and WAC yet, thanks ;)
>>
>>> all converge around web applications written to HTML5, with
>>> extensions to support handset features that are beyond HTML5. I don't
>>> know of anyone working on BONDI for MeeGo, but would be very
>>> interested in learning anything you come across. I think you're
>>> right, it wouldn't be that hard - maybe WAC is the place to focus
>>> moving forward? ?I know the
>>
>> I had a brief look at all three again, I started with WAC and stumbled
>> accross an issue - I think... the governance. So I checked that again
>> with all three.
>>
>> What I do not like about WAC is that it is 100% operator focussed and
>> the name of the project makes IMHO their intention pretty clear
>> "Wholesale Application" - they are only interested in creating a broad
>> application market.
>>
>> While this is of course one of the valid goals it should not be the
>> only one. As a developer I miss the "level of invention" here. The
>> governance of WAC though suggests that selling applications is *the*
>> driving factor for the project and to the few major players in it:
>> There are a few core operators that build the board of directors and
>> new (operator) members can only get a non-voting visitor seat in the
>> board. No mention of other possibly parties (like vendors or makers)
>> and especially not mention of third party developers e.g. from the open source.
>>
>> This sounds pretty limited - sounds like a pretty narrow minded club
>> to me so I would personally not like to pursue that road. Also from
>> technology standpoint it seems to me that they are only up to taking
>> up existing bits and specify a (sub-)set they want to support in WAC.
>> It does not seem that they want to actually do much own development.
>>
>> JIL is similar, only members are China Mobile, SoftBank Mobile,
>> Verizon Wireless, and Vodafone, 100% operator driven again. But they
>> are up to do own development and want to provide an SDK - well...
>>
>> In contrast to those two OMTP is a quite larger organisation, current
>> OMTP members:
>> http://www.omtp.org/Membership.aspx
>> and Bondi seems to be pretty open, it is Apache licensed and announced
>> as an open source project which at least suggests that open source
>> developers can take some part in it.
>>
>> I should probably note that I am not affiliated with OMTP nor Bondi ;)
>>
>>> folks at Aplix and ACCESS were involved with the OMTP reference
>>> implementation of BONDI.
>>
>> Yes, since they are LiMo foundation members (as is Wind River) and
>> LiMo seems to go away from native applications towards Web2.0 someone
>> had to do the job ;)
>>
>>> Rick Rogers
>>> Wind River
>> Cheers
>> ?nils
>>
>> --
>> kernel concepts GbR ? ? ?Tel: +49-271-771091-12 Sieghuetter Hauptweg
>> 48 ?Fax: +49-271-771091-19
>> D-57072 Siegen ? ? ? ? ? Mob: +49-176-21024535
>> http://www.kernelconcepts.de
>> _______________________________________________
>> MeeGo-dev mailing list
>> MeeGo-dev@meego.com
>> http://lists.meego.com/listinfo/meego-dev
>>
>
>
>
> --
> J. Manrique L?pez de la Fuente
> http://www.jsmanrique.es
> _______________________________________________
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
--
J. Manrique L?pez de la Fuente
http://www.jsmanrique.es
------------------------------
Message: 4
Date: Mon, 19 Apr 2010 11:56:57 -0700
From: "Foster, Dawn M" <dawn.m.foster@intel.com>
To: "meego-dev@meego.com" <meego-dev@meego.com>
Subject: [MeeGo-dev] Missing Messages & Issues posting to this list
Message-ID: <08F143CB-6FF3-486D-8303-2E743A0BEDDB@intel.com>
Content-Type: text/plain; charset="us-ascii"
We're having an issue with some people's messages never making it to this list, and I'm trying to track down the problem. In some cases (Randall) it seems to be intermittent - some messages from machines with certain configurations are getting through, but others are disappearing before they make it to the list. Since this only happens with certain people, my working theory is that we have an overly aggressive content filter of some kind, but I don't see anything that looks too aggressive.
If you are having problems, please email me directly (off-list) with the following information:
* email address that is subscribed
* the text of any bounce-back messages
* description of any pattern or other information that might help me diagnose the issue.
Dawn
------------------------------
Message: 5
Date: Mon, 19 Apr 2010 16:50:50 -0300
From: Leonardo Luiz Padovani da Mata <leonardol@syst.com.br>
To: meego-dev@meego.com
Subject: [MeeGo-dev] ADSL support
Message-ID:
<u2h25a8797c1004191250wdc3d4f56z9fc3daf28ed1be2d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello, how to connect using pppoe under meego? Do i need to install
kppp from fedora to use ADSL connection?
Thanks
--
Leonardo Luiz Padovani da Mata
barroca@syst.com.br
"May the force be with you, always"
"Nerd Pride... eu tenho. Voce tem?"
------------------------------
Message: 6
Date: Mon, 19 Apr 2010 23:24:51 +0100
From: David Greaves <david@dgreaves.com>
To: meego-dev@meego.com
Subject: [MeeGo-dev] Repository Working Group - next steps
Message-ID: <4BCCD833.2030309@dgreaves.com>
Content-Type: text/plain; charset=ISO-8859-1
So it's been a while since the TSG meeting when the RWG was proposed [1];
not a lot of discussion has arisen naturally (not surprising, there's not a lot
for the community to build around yet).
So maybe we can review what we think will be needed.
I think two main issues were raised: [2]
* Is a WG needed?
* Isn't this covered in the MeeGo 'Core' project structure?
I think there is general agreement that Imad was correct in saying "it is larger
than a working group" - so I'd like to recap the proposal here and consider the
points above for each of the areas. The main interest areas for the RWG are,
naturally, the repositories and arising from that, build and documentation. So
lets review the scope and relate that to the MeeGo Distribution.
Repositories
============
The proposal is that the RWG take responsibility for managing the applications
repository and the community supported packages repository; more specifically
the associated QA, policies and processes.
The first thing to notice is that there are 2 kinds of repository areas.
a) Individual packages
b) Community non-core packages : Surrounds
The individual packages have a development/release cycle which is independent of
other packages and independent of MeeGo itself. Indeed they may support
multiple releases of MeeGo over time (eg the GPE suite).
This part of the RWG is comparable to a community app-store and has roots in
Maemo's Extras and the Moblin garage.
As we've seen in Maemo Extras we can provide a lot of community support to this
area; but that support needs to adapt to the dynamic needs of a growing
community. I suggest that a decision making group is needed to enforce, accept,
review and agree changes to policy covering:
* QA
* package acceptance/removal
* security
* delivery
* infrastructure requirements
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.
This is clearly an area where independent application developers are growing out
of the community and providing an ecosystem around MeeGo.
However it is equally clear that the success of this ecosystem is crucial to the
successful growth of a development community around MeeGo that clearly does not
exist yet. Both corporate and individual members of the MeeGo family should be
looking to allocate resource to this area. Yes a group is needed;
Finally, IMHO this is a technical working group, and I would be surprised to see
it within the CWG.
The second major area is the community non-core packages; this area provides a
more coherent set of inter-related or depended-upon libraries and applications.
This entire collection would follow the same release cycle (which may well be
the same as MeeGo core). The Surrounds area would also probably support
historical releases of Meego for situations where vendors didn't provide updates
for devices.
As originally proposed, it may make sense for the Surrounds area to establish
relationships (close, arms-length, formal or informal) to maintainers in other
community distros to share the burden of maintaining some packages.
So first "Isn't this covered in the MeeGo 'Core' project structure?".
No; this is, pretty much by definition, a wider and community managed set of
applications. MeeGo cannot possibly accept every library, application or
subsystem that is requested by random community members; nor do we want to
create a multitude of independent repositories or one-shot packages.
However, it does make sense to have an area where code is evaluated and may
eventually be sponsored into the core distribution. Packages which become (by
some metric) popular and which demonstrate a suitable level of maintainer-ship
whilst in the Surrounds may be promoted into the core repository.
Additionally, packages which, for whatever reason, are deprecated from the core
may continue to be supported in the Surrounds.
Similar bi-directional migration paths may apply to people as well as code!
Secondly, is a WG neede? Clearly there is a relationship between core, surrounds
and individual packages; managing them in a consistent manner seems rational.
The purpose of a working group is to provide that consistency and focus.
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.
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 would once again like to clarify: the RWG is not meant be the team managing
the day-to-day operations of any autobuilder-like infrastructure; they would
instead be providing community objectives and goals to that team.
With this in mind the RWG would be the place where the community would work with
the build service implementation team to realise the polices and processes
outlined above. Whilst it is possible to segregate the repository work described
above from the build activity it would appear to make more sense to collaborate
closely; certainly a close relationship between the Maemo community and the
autobuilder teams has been very successful.
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.
I hope this provides some foundation for discussion and enables the TSG to
consider the proposal further.
David/lbt
[1]http://wiki.meego.com/Proposal_for_a_Repository_working_group
[2]http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-03-31-19.58.log.html#l-100
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
------------------------------
Message: 7
Date: Mon, 19 Apr 2010 15:23:13 -0700
From: Greg KH <gregkh@suse.de>
To: Leonardo Luiz Padovani da Mata <leonardol@syst.com.br>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] ADSL support
Message-ID: <20100419222312.GA3333@suse.de>
Content-Type: text/plain; charset=us-ascii
On Mon, Apr 19, 2010 at 04:50:50PM -0300, Leonardo Luiz Padovani da Mata wrote:
> Hello, how to connect using pppoe under meego? Do i need to install
> kppp from fedora to use ADSL connection?
ConMan should support this, if not, file a bug.
thanks,
greg k-h
------------------------------
Message: 8
Date: Mon, 19 Apr 2010 19:48:48 -0300
From: Leonardo Luiz Padovani da Mata <leonardol@syst.com.br>
To: Greg KH <gregkh@suse.de>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] ADSL support
Message-ID:
<y2o25a8797c1004191548pb0d690bcuae891c1518f05db6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 19, 2010 at 7:23 PM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Apr 19, 2010 at 04:50:50PM -0300, Leonardo Luiz Padovani da Mata wrote:
>> Hello, how to connect using pppoe under meego? Do i need to install
>> kppp from fedora to use ADSL connection?
>
> ConMan should support this, if not, file a bug.
Ok, i will give a try today...
>
> thanks,
>
> greg k-h
>
--
Leonardo Luiz Padovani da Mata
barroca@syst.com.br
"May the force be with you, always"
"Nerd Pride... eu tenho. Voce tem?"
------------------------------
Message: 9
Date: Tue, 20 Apr 2010 09:48:44 +0800
From: "paler.tw" <paler.tw@gmail.com>
To: ext-vasily.gurevich@nokia.com
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] mic.imgcreate.errors.MountError
Message-ID:
<v2o99e3a5a1004191848m880fe2bbw33207c6d63a07164@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I do use the qemu-binfmt-conf.sh and install the qemu-arm-static package.
It still shows those error messages even though I did those things.
2010/4/20 <ext-vasily.gurevich@nokia.com>
> You can use qemu-binfmt-conf.sh from git://
> gitorious.org/qemu-maemo/qemu.git and you need to install qemu-arm-static
> package. Install qemu from git://gitorious.org/qemu-maemo/qemu.git as
> well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meego.com/pipermail/meego-dev/attachments/20100420/95f0f75c/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 20 Apr 2010 09:54:38 +0800
From: Tom Chen <funpig@gmail.com>
To: meego-dev List <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] how to start developing on MeeGo?
Message-ID:
<t2x211cdee01004191854md230acffq7ce7cf175373968b@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
MADDE is good dev tools for Maemo platform. it's easy to integration
with QtCreator. but unfortunately, MADDE has NO emulator for debug now, but
it'll come soon as nokia guys said. MADDE could sent app to N900 and run it.
more detail please see http://wiki.maemo.org/.
Br
Tom
On Mon, Apr 19, 2010 at 5:06 PM, Jeremiah Foster <
jeremiah.foster@pelagicore.com> wrote:
>
> On Apr 16, 2010, at 8:33 PM, Dengyi Wang wrote:
>
> On 04/16/2010 01:50 PM, Greg KH wrote:
>
> On Fri, Apr 16, 2010 at 11:33:40AM -0400, Dengyi Wang wrote:
>
>
>
> Personally, I prefer Fedora 12. I believe it's more close to MeeGo's image.
>
> (RPM based). Any comments?
>
>
>
> Why not just use MeeGo to develop it? That works for me. And again,
>
> just because the distro is RPM based, doesn't mean that MeeGo is based
>
> on it at all.
>
>
> <snip>
>
> Intel used to have Moblin SDK, which is cross-compile + sysroot. I prefer
> that way. And it could be used for ARM development too.
>
>
> You may want to look at MADDE which is going to be developed further for
> MeeGo and is an SDK with the features you mentioned.
>
> Jeremiah
>
> _______________________________________________
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meego.com/pipermail/meego-dev/attachments/20100420/bba4ae3f/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 20 Apr 2010 10:09:48 +0800
From: "Yang, Yi Y" <yi.y.yang@intel.com>
To: paler.tw <paler.tw@gmail.com>, "ext-vasily.gurevich@nokia.com"
<ext-vasily.gurevich@nokia.com>
Cc: "meego-dev@meego.com" <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] mic.imgcreate.errors.MountError
Message-ID:
<FC2FB65B4D919844ADE4BE3C2BB739AD1E33F94D@shsmsx501.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Please file a bug on http://bugzilla.meego.com/enter_bug.cgi?product=Development%20Tools, component is MIC, describe your issue in details and how to produce, also paste your error log.
From: meego-dev-bounces@meego.com [mailto:meego-dev-bounces@meego.com] On Behalf Of paler.tw
Sent: Tuesday, April 20, 2010 9:49 AM
To: ext-vasily.gurevich@nokia.com
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] mic.imgcreate.errors.MountError
I do use the qemu-binfmt-conf.sh and install the qemu-arm-static package.
It still shows those error messages even though I did those things.
2010/4/20 <ext-vasily.gurevich@nokia.com<mailto:ext-vasily.gurevich@nokia.com>>
You can use qemu-binfmt-conf.sh from git://gitorious.org/qemu-maemo/qemu.git<http://gitorious.org/qemu-maemo/qemu.git> and you need to install qemu-arm-static package. Install qemu from git://gitorious.org/qemu-maemo/qemu.git<http://gitorious.org/qemu-maemo/qemu.git> as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meego.com/pipermail/meego-dev/attachments/20100420/2d4108d4/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 20 Apr 2010 16:58:49 +0800
From: "paler.tw" <paler.tw@gmail.com>
To: meego-dev@meego.com
Subject: [MeeGo-dev] VT_GETMODE failed Function not implemented
Message-ID:
<v2x99e3a5a1004200158r9a2f5c21ucfe65ceb97b207ad@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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?
The following message is from /var/log/Xorg.0.log
1. [ 91775.918] Warning: getifaddrs returns Address family not supported
by protocol
2. [ 91775.920] Warning: getifaddrs returns Address family not supported
by protocol
3. [ 91775.933]
4. This is a pre-release version of the X server from The X.Org
Foundation.
5. It is not supported in any way.
6. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
7. Select the "xorg" product for bugs you find in this release.
8. Before reporting bugs in pre-release versions please check the
9. latest version in the X.Org Foundation git repository.
10. See http://wiki.x.org/wiki/GitPage for git access instructions.
11. [ 91775.934]
12. X.Org X Server 1.7.99.902 (1.8.0 RC 2)
13. Release Date: 2010-03-21
14. [ 91775.934] X Protocol Version 11, Revision 0
15. [ 91775.934] Build Operating System: Linux 2.6.27.42-0.1-pae armv5tel
16. [ 91775.934] Current Operating System: Linux Meego.fedora
2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST 2009 armv5tel
17. [ 91775.934] Kernel command line: ro
root=/dev/mapper/vg_meego-lv_root LANG=zh_TW.UTF-8 KEYBOARDTYPE=pc
KEYTABLE=us rhgb quiet
18. [ 91775.935] Build Date: 30 March 2010 08:17:16AM
19. [ 91775.935] Build ID: xorg-x11-server 1.7.99.902~git3083c5d0c4-1.10
20. [ 91775.935] Current version of pixman: 0.17.4
21. [ 91775.935] Before reporting problems, check http://wiki.x.org
22. to make sure that you have the latest version.
23. [ 91775.935] Markers: (--) probed, (**) from config file, (==)
default setting,
24. (++) from command line, (!!) notice, (II) informational,
25. (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
26. [ 91775.938] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 20
04:29:17 2010
27. [ 91775.939] (==) Using config file: "/etc/X11/xorg.conf"
28. [ 91775.942] (==) ServerLayout "Server"
29. [ 91775.942] (==) No screen section available. Using defaults.
30. [ 91775.942] (**) |-->Screen "Default Screen Section" (0)
31. [ 91775.942] (**) | |-->Monitor "<default monitor>"
32. [ 91775.945] (==) No monitor specified for screen "Default Screen
Section".
33. Using a default monitor configuration.
34. [ 91775.945] (**) |-->Input Device "Touchscreen"
35. [ 91775.945] (**) |-->Input Device "Keyboard"
36. [ 91775.946] (==) Automatically adding devices
37. [ 91775.946] (==) Automatically enabling devices
38. [ 91775.947] (==) FontPath set to:
39. catalogue:/etc/X11/fontpath.d,
40. built-ins
41. [ 91775.947] (==) ModulePath set to "/usr/lib/xorg/modules"
42. [ 91775.947] (II) The server relies on udev to provide the list of
input devices.
43. If no devices become available, reconfigure udev or disable
AutoAddDevices.
44. [ 91775.948] (II) Loader magic: 0x198e64
45. [ 91775.948] (II) Module ABI versions:
46. [ 91775.948] X.Org ANSI C Emulation: 0.4
47. [ 91775.948] X.Org Video Driver: 7.0
48. [ 91775.948] X.Org XInput driver : 9.0
49. [ 91775.948] X.Org Server Extension : 3.0
50. [ 91776.115] (--) PCI:*(0:0:2:0) 8086:2e32:17aa:304f Intel
Corporation 4 Series Chipset Integrated Graphics Controller rev 3, Mem @
0xfe400000/4194304, 0xd0000000/268435456, I/O @ 0x0000dc00/8
51. [ 91776.116] (II) LoadModule: "extmod"
52. [ 91776.123] (II) Loading
/usr/lib/xorg/modules/extensions/libextmod.so
53. [ 91776.124] (II) Module extmod: vendor="X.Org Foundation"
54. [ 91776.124] compiled for 1.7.99.902, module version = 1.0.0
55. [ 91776.125] Module class: X.Org Server Extension
56. [ 91776.125] ABI class: X.Org Server Extension, version 3.0
57. [ 91776.125] (II) Loading extension MIT-SCREEN-SAVER
58. [ 91776.125] (II) Loading extension XFree86-VidModeExtension
59. [ 91776.125] (II) Loading extension XFree86-DGA
60. [ 91776.125] (II) Loading extension DPMS
61. [ 91776.125] (II) Loading extension XVideo
62. [ 91776.125] (II) Loading extension XVideo-MotionCompensation
63. [ 91776.125] (II) Loading extension X-Resource
64. [ 91776.126] (II) LoadModule: "dbe"
65. [ 91776.126] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
66. [ 91776.127] (II) Module dbe: vendor="X.Org Foundation"
67. [ 91776.127] compiled for 1.7.99.902, module version = 1.0.0
68. [ 91776.127] Module class: X.Org Server Extension
69. [ 91776.127] ABI class: X.Org Server Extension, version 3.0
70. [ 91776.127] (II) Loading extension DOUBLE-BUFFER
71. [ 91776.127] (II) LoadModule: "glx"
72. [ 91776.127] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
73. [ 91776.128] (II) Module glx: vendor="X.Org Foundation"
74. [ 91776.128] compiled for 1.7.99.902, module version = 1.0.0
75. [ 91776.128] ABI class: X.Org Server Extension, version 3.0
76. [ 91776.128] (==) AIGLX enabled
77. [ 91776.128] (II) Loading extension GLX
78. [ 91776.128] (II) LoadModule: "dri"
79. [ 91776.129] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
80. [ 91776.130] (II) Module dri: vendor="X.Org Foundation"
81. [ 91776.130] compiled for 1.7.99.902, module version = 1.0.0
82. [ 91776.130] ABI class: X.Org Server Extension, version 3.0
83. [ 91776.130] (II) Loading extension XFree86-DRI
84. [ 91776.130] (II) LoadModule: "dri2"
85. [ 91776.131] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
86. [ 91776.131] (II) Module dri2: vendor="X.Org Foundation"
87. [ 91776.131] compiled for 1.7.99.902, module version = 1.2.0
88. [ 91776.131] ABI class: X.Org Server Extension, version 3.0
89. [ 91776.132] (II) Loading extension DRI2
90. [ 91776.132] (==) Matched intel for the autoconfigured driver
91. [ 91776.132] (==) Assigned the driver to the xf86ConfigLayout
92. [ 91776.132] (II) LoadModule: "intel"
93. [ 91776.133] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
94. [ 91776.135] (II) Module intel: vendor="X.Org Foundation"
95. [ 91776.135] compiled for 1.7.99.902, module version = 2.10.903
96. [ 91776.135] Module class: X.Org Video Driver
97. [ 91776.135] ABI class: X.Org Video Driver, version 7.0
98. [ 91776.136] (II) LoadModule: "evdev"
99. [ 91776.136] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
100. [ 91776.137] (II) Module evdev: vendor="X.Org Foundation"
101. [ 91776.137] compiled for 1.7.99.902, module version = 2.3.2
102. [ 91776.137] Module class: X.Org XInput Driver
103. [ 91776.137] ABI class: X.Org XInput driver, version 9.0
104. [ 91776.137] (II) intel: Driver for Intel Integrated Graphics
Chipsets: i810,
105. i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G,
915G,
106. E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G,
107. 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45,
108. 4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
109. [ 91776.138] (--) using VT number 7
110.
111. [ 91776.145]
112. Fatal server error:
113. [ 91776.145] xf86OpenConsole: VT_GETMODE failed Function not
implemented
114. [ 91776.145]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meego.com/pipermail/meego-dev/attachments/20100420/5b3f6693/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 20 Apr 2010 12:19:59 +0300
From: Roger Quadros <roger.quadros@nokia.com>
To: yong.y.wang@intel.com
Cc: meego-dev@meego.com
Subject: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID:
<1271755199-29707-1-git-send-email-roger.quadros@nokia.com>
Fixes OBS build for ARM N900. This will not affect existing
x86 or x86_64 builds.
Signed-off-by: Roger Quadros <roger.quadros@nokia.com>
---
Makefile | 5 ++++
Makefile.config | 9 ++-----
kernel.spec | 63 ++++++++++++++++++++++++++++++++++-----------------
kernel.spec.in | 67 ++++++++++++++++++++++++++++++++++++-------------------
makespec.pl | 2 +-
5 files changed, 95 insertions(+), 51 deletions(-)
diff --git a/Makefile b/Makefile
index ba92df0..d8deed5 100644
--- a/Makefile
+++ b/Makefile
@@ -26,3 +26,8 @@ menlow: kernel.spec.in series makespec.pl
@touch MENLOW;
@perl makespec.pl < kernel.spec.in > kernel-menlow.spec ;
@rm MENLOW;
+
+n900: kernel.spec.in series makespec.pl
+ @touch N900;
+ @perl makespec.pl < kernel.spec.in > kernel-n900.spec ;
+ @rm N900;
diff --git a/Makefile.config b/Makefile.config
index 27f8071..3cabb6a 100644
--- a/Makefile.config
+++ b/Makefile.config
@@ -10,7 +10,7 @@ CONFIGFILES = /
$(CFG)-shcdk.config /
$(CFG)-aava.config /
$(CFG)-ivi.config /
- $(CFG)-n900.config
+ $(CFG)-arm-n900.config
PLATFORMS = x86
TEMPFILES = $(addprefix temp-, $(addsuffix -generic, $(PLATFORMS)))
@@ -39,8 +39,5 @@ kernel-shcdk.config: config-shcdk config-generic
kernel-aava.config: config-aava kernel-shcdk.config
perl merge.pl $^ > $@
-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 $^ $@
diff --git a/kernel.spec b/kernel.spec
index a1dfb3b..a5c62fe 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -60,7 +60,7 @@ Summary: The Linux kernel (the core of the Linux operating system)
%define all_x86 i386 i586 i686 %{ix86}
-%define all_arm arm armv5el
+%define all_arm %{arm}
# Overrides for generic default options
%define all_arch_configs kernel-*.config
@@ -81,10 +81,10 @@ Summary: The Linux kernel (the core of the Linux operating system)
%endif
%ifarch %{all_arm}
-%define all_arch_configs kernel-*.config
+%define all_arch_configs kernel-arm-*.config
%define image_install_path boot
-%define kernel_image vmlinux
-%define make_target vmlinux
+%define kernel_image arch/arm/boot/zImage
+%define make_target zImage
%endif
%define oldconfig_target nonint_oldconfig
@@ -384,11 +384,18 @@ This package contains the kernel optimized for the Moorsetown platform for Aava
%description ivi
This package contains the kernel optimized for In Vehicle Infotainment segments
-%else
+%endif
+
+%ifarch %{all_arm}
+
+#N900 ARM variant
%define variant_summary Kernel for the Nokia N900
-%kernel_variant_package n900
-%description n900
+%kernel_variant_package arm-n900
+%description arm-n900
This package contains the kernel optimized for the Nokia N900 device
+
+#Put other ARM variants here
+
%endif
@@ -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}
do
mv $i .config
Arch="x86"
- if [ `echo $i | grep -c n900` -eq 1 ]; then
- Arch="arm"
- fi
+%ifarch %{all_arm}
+ Arch="arm"
+%endif
# make oldconfig > /dev/null
echo Doing $i
make ARCH=$Arch %{oldconfig_target} > /dev/null
@@ -739,9 +746,6 @@ BuildKernel() {
cp configs/$Config .config
Arch="x86"
- if [ `echo $Config | grep -c n900` -eq 1 ]; then
- Arch="arm"
- fi
%ifarch %{all_arm}
Arch="arm"
%endif
@@ -766,7 +770,9 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer
+%ifnarch %{all_arm}
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer
+%endif
# And save the headers/makefiles etc for building modules against
#
@@ -801,7 +807,12 @@ BuildKernel() {
fi
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*.o
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*/*.o
+%ifarch %{all_x86}
cp -a --parents arch/x86/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+%endif
+%ifarch %{all_arm}
+ cp -a --parents arch/arm/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+%endif
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
cd include
cp -a acpi asm-generic config crypto drm generated keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound video trace $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
@@ -877,8 +888,10 @@ BuildKernel %make_target %kernel_image shcdk
BuildKernel %make_target %kernel_image aava
BuildKernel %make_target %kernel_image netbook
BuildKernel %make_target %kernel_image ivi
-%else
-BuildKernel %make_target %kernel_image n900
+%endif
+
+%ifarch %all_arm
+BuildKernel %make_target %kernel_image arm-n900
%endif
cd tools/perf
@@ -994,17 +1007,21 @@ fi}/
%kernel_variant_preun ivi
%kernel_variant_post -v ivi
-%else
+%endif
-%kernel_variant_preun n900
-%kernel_variant_post -v n900
+%ifarch %{all_arm}
+
+%kernel_variant_preun arm-n900
+%kernel_variant_post -v arm-n900
%endif
+%ifnarch %{all_arm}
if [ -x /sbin/ldconfig ]
then
/sbin/ldconfig -X || exit $?
fi
+%endif
###
### file lists
@@ -1034,7 +1051,9 @@ fi
/lib/modules/%{KVERREL}%{?2:-%{2}}/kernel/
/lib/modules/%{KVERREL}%{?2:-%{2}}/build/
/lib/modules/%{KVERREL}%{?2:-%{2}}/source/
+%ifnarch %{all_arm}/
/lib/modules/%{KVERREL}%{?2:-%{2}}/vdso/
+%endif/
/lib/modules/%{KVERREL}%{?2:-%{2}}/modules.block/
/lib/modules/%{KVERREL}%{?2:-%{2}}/modules.dep.bin/
/lib/modules/%{KVERREL}%{?2:-%{2}}/modules.alias.bin/
@@ -1061,8 +1080,10 @@ fi
%kernel_variant_files 1 shcdk
%kernel_variant_files 1 aava
%kernel_variant_files 1 ivi
-%else
-%kernel_variant_files 1 n900
+%endif
+
+%ifarch %{all_arm}
+%kernel_variant_files 1 arm-n900
%endif
diff --git a/kernel.spec.in b/kernel.spec.in
index 9bdfc7f..daaea1b 100644
--- a/kernel.spec.in
+++ b/kernel.spec.in
@@ -60,7 +60,7 @@ Summary: The Linux kernel (the core of the Linux operating system)
%define all_x86 i386 i586 i686 %{ix86}
-%define all_arm arm armv5el
+%define all_arm %{arm}
# Overrides for generic default options
%define all_arch_configs kernel-*.config
@@ -81,10 +81,10 @@ Summary: The Linux kernel (the core of the Linux operating system)
%endif
%ifarch %{all_arm}
-%define all_arch_configs kernel-*.config
+%define all_arch_configs kernel-arm-*.config
%define image_install_path boot
-%define kernel_image vmlinux
-%define make_target vmlinux
+%define kernel_image arch/arm/boot/zImage
+%define make_target zImage
%endif
%define oldconfig_target nonint_oldconfig
@@ -246,11 +246,18 @@ This package contains the kernel optimized for the Menlow platform
%description ivi
This package contains the kernel optimized for In Vehicle Infotainment segments
-%else
-%define variant_summary Kernel for the Nokia N900
-%kernel_variant_package n900
-%description n900
-This package contains the kernel optimized for the Nokia N900 device
+%endif
+
+%ifarch %{all_arm}
+
+@@N900 #N900 ARM variant
+@@N900 %define variant_summary Kernel for the Nokia N900
+@@N900 %kernel_variant_package arm-n900
+@@N900 %description arm-n900
+@@N900 This package contains the kernel optimized for the Nokia N900 device
+
+#Put other ARM variants here
+
%endif
@@ -336,13 +343,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}
do
mv $i .config
Arch="x86"
- if [ `echo $i | grep -c n900` -eq 1 ]; then
- Arch="arm"
- fi
+%ifarch %{all_arm}
+ Arch="arm"
+%endif
# make oldconfig > /dev/null
echo Doing $i
make ARCH=$Arch %{oldconfig_target} > /dev/null
@@ -399,9 +406,6 @@ BuildKernel() {
cp configs/$Config .config
Arch="x86"
- if [ `echo $Config | grep -c n900` -eq 1 ]; then
- Arch="arm"
- fi
%ifarch %{all_arm}
Arch="arm"
%endif
@@ -426,7 +430,9 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer
+%ifnarch %{all_arm}
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer
+%endif
# And save the headers/makefiles etc for building modules against
#
@@ -461,7 +467,12 @@ BuildKernel() {
fi
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*.o
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*/*.o
+%ifarch %{all_x86}
cp -a --parents arch/x86/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+%endif
+%ifarch %{all_arm}
+ cp -a --parents arch/arm/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+%endif
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
cd include
cp -a acpi asm-generic config crypto drm generated keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound video trace $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
@@ -538,8 +549,10 @@ cd linux-%{kversion}
@@N BuildKernel %make_target %kernel_image netbook
@@W BuildKernel %make_target %kernel_image menlow
@@I BuildKernel %make_target %kernel_image ivi
-%else
-@@A BuildKernel %make_target %kernel_image n900
+%endif
+
+%ifarch %all_arm
+@@N900 BuildKernel %make_target %kernel_image arm-n900
%endif
cd tools/perf
@@ -657,17 +670,21 @@ fi}/
@@I %kernel_variant_preun ivi
@@I %kernel_variant_post -v ivi
-%else
+%endif
-@@A %kernel_variant_preun n900
-@@A %kernel_variant_post -v n900
+%ifarch %{all_arm}
+
+@@N900 %kernel_variant_preun arm-n900
+@@N900 %kernel_variant_post -v arm-n900
%endif
+%ifnarch %{all_arm}
if [ -x /sbin/ldconfig ]
then
/sbin/ldconfig -X || exit $?
fi
+%endif
###
### file lists
@@ -697,7 +714,9 @@ fi
/lib/modules/%{KVERREL}%{?2:-%{2}}/kernel/
/lib/modules/%{KVERREL}%{?2:-%{2}}/build/
/lib/modules/%{KVERREL}%{?2:-%{2}}/source/
+%ifnarch %{all_arm}/
/lib/modules/%{KVERREL}%{?2:-%{2}}/vdso/
+%endif/
/lib/modules/%{KVERREL}%{?2:-%{2}}/modules.block/
/lib/modules/%{KVERREL}%{?2:-%{2}}/modules.dep.bin/
/lib/modules/%{KVERREL}%{?2:-%{2}}/modules.alias.bin/
@@ -725,8 +744,10 @@ fi
@@M %kernel_variant_files 1 shcdk
@@M %kernel_variant_files 1 aava
@@I %kernel_variant_files 1 ivi
-%else
-@@A %kernel_variant_files 1 n900
+%endif
+
+%ifarch %{all_arm}
+@@N900 %kernel_variant_files 1 arm-n900
%endif
diff --git a/makespec.pl b/makespec.pl
index 79cb8d6..5c432fb 100644
--- a/makespec.pl
+++ b/makespec.pl
@@ -107,7 +107,7 @@ while (<>) {
print "$1/n";
next;
}
- if ($want_n900 > 0 && $line =~ //@/@A (.*)/) {
+ if ($want_n900 > 0 && $line =~ //@/@N900 (.*)/) {
print "$1/n";
next;
}
--
1.6.0.4
------------------------------
Message: 14
Date: Tue, 20 Apr 2010 11:44:12 +0200
From: Jeremiah Foster <jeremiah.foster@pelagicore.com>
To: meego-dev List <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] Repository Working Group - next steps
Message-ID: <ACB29101-4080-4388-8C48-160F11CE5CC7@pelagicore.com>
Content-Type: text/plain; charset="us-ascii"
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.foster@pelagicore.com
=============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meego.com/pipermail/meego-dev/attachments/20100420/008b40a9/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 20 Apr 2010 12:56:22 +0300
From: Marko Vertainen <marko.vertainen@iki.fi>
To: Jeremiah Foster <jeremiah.foster@pelagicore.com>
Cc: meego-dev List <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] Repository Working Group - next steps
Message-ID:
<m2s835849a31004200256ybf7f25e1u14fee90302b5ffea@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/4/20 Jeremiah Foster <jeremiah.foster@pelagicore.com>:
> If there is no access to the build system, MeeGo is effectively closed.
There is open bug for this: http://bugzilla.meego.com/show_bug.cgi?id=615
--
Marko
------------------------------
Message: 16
Date: Tue, 20 Apr 2010 11:04:01 +0100
From: Glen Gray <slaine@slaine.org>
To: David Greaves <david@dgreaves.com>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] Repository Working Group - next steps
Message-ID: <9DE03B24-01A1-4D8E-84A8-C76F1574C925@slaine.org>
Content-Type: text/plain; charset=us-ascii
On 19 Apr 2010, at 23:24, David Greaves wrote:
> So it's been a while since the TSG meeting when the RWG was proposed [1];
> not a lot of discussion has arisen naturally (not surprising, there's not a lot
> for the community to build around yet).
>
> So maybe we can review what we think will be needed.
[SNIP]
Thanks David,
That was an excellent overview of the situation and sums up nicely the different elements currently at play.
It falls now to the TSG and the teams to let us in and participate. I'm not sure we have a clear understanding of how open meego is supposed to be and how involved we're allowed to be. Day 1 has been and gone but not much has changed. The collab talks where excellent, but left me confused. Claims of meego development happening out in the open now are not reflected in any public mailing list, forum or irc logs that I've seen. Third parties having significant access to code to present demonstration units IDF etc. all leave a rather unsettling feeling that all is not as it's presented.
Perhaps we should get together ahead of the TSG tomorrow and get a clear set of questions together to find out where we stand. I'd also like to push to get some formal backing to Carsten's "Proposal for Best Practices for working in a MeeGo team"
Kind Regards,
--
Glen Gray
slaine@slaine.org
------------------------------
Message: 17
Date: Tue, 20 Apr 2010 13:57:13 +0300
From: Roger Quadros <roger.quadros@nokia.com>
To: "meego-dev@meego.com" <meego-dev@meego.com>, kangkai.yin@intel.com
Subject: Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID: <4BCD8889.8080303@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
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.
One way to solve this is to rename all x86 based kernel configs to
kernel-x86-*.config and use
#define all_arch_configs kernel-x86-*.config
the other way is to remove non x86 configs when build is not x86. but this is a
hack.
any better suggestions how to fix this?
cheers,
-roger
Quadros Roger (Nokia-D/Helsinki) wrote:
> Fixes OBS build for ARM N900. This will not affect existing
> x86 or x86_64 builds.
>
> Signed-off-by: Roger Quadros <roger.quadros@nokia.com>
> ---
> Makefile | 5 ++++
> Makefile.config | 9 ++-----
> kernel.spec | 63 ++++++++++++++++++++++++++++++++++-----------------
> kernel.spec.in | 67 ++++++++++++++++++++++++++++++++++++-------------------
> makespec.pl | 2 +-
> 5 files changed, 95 insertions(+), 51 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ba92df0..d8deed5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -26,3 +26,8 @@ menlow: kernel.spec.in series makespec.pl
> @touch MENLOW;
> @perl makespec.pl < kernel.spec.in > kernel-menlow.spec ;
> @rm MENLOW;
> +
> +n900: kernel.spec.in series makespec.pl
> + @touch N900;
> + @perl makespec.pl < kernel.spec.in > kernel-n900.spec ;
> + @rm N900;
> diff --git a/Makefile.config b/Makefile.config
> index 27f8071..3cabb6a 100644
> --- a/Makefile.config
> +++ b/Makefile.config
> @@ -10,7 +10,7 @@ CONFIGFILES = /
> $(CFG)-shcdk.config /
> $(CFG)-aava.config /
> $(CFG)-ivi.config /
> - $(CFG)-n900.config
> + $(CFG)-arm-n900.config
>
> PLATFORMS = x86
> TEMPFILES = $(addprefix temp-, $(addsuffix -generic, $(PLATFORMS)))
> @@ -39,8 +39,5 @@ kernel-shcdk.config: config-shcdk config-generic
> kernel-aava.config: config-aava kernel-shcdk.config
> perl merge.pl $^ > $@
>
> -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 $^ $@
> diff --git a/kernel.spec b/kernel.spec
> index a1dfb3b..a5c62fe 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -60,7 +60,7 @@ Summary: The Linux kernel (the core of the Linux operating system)
>
> %define all_x86 i386 i586 i686 %{ix86}
>
> -%define all_arm arm armv5el
> +%define all_arm %{arm}
>
> # Overrides for generic default options
> %define all_arch_configs kernel-*.config
> @@ -81,10 +81,10 @@ Summary: The Linux kernel (the core of the Linux operating system)
> %endif
>
> %ifarch %{all_arm}
> -%define all_arch_configs kernel-*.config
> +%define all_arch_configs kernel-arm-*.config
> %define image_install_path boot
> -%define kernel_image vmlinux
> -%define make_target vmlinux
> +%define kernel_image arch/arm/boot/zImage
> +%define make_target zImage
> %endif
>
> %define oldconfig_target nonint_oldconfig
> @@ -384,11 +384,18 @@ This package contains the kernel optimized for the Moorsetown platform for Aava
> %description ivi
> This package contains the kernel optimized for In Vehicle Infotainment segments
>
> -%else
> +%endif
> +
> +%ifarch %{all_arm}
> +
> +#N900 ARM variant
> %define variant_summary Kernel for the Nokia N900
> -%kernel_variant_package n900
> -%description n900
> +%kernel_variant_package arm-n900
> +%description arm-n900
> This package contains the kernel optimized for the Nokia N900 device
> +
> +#Put other ARM variants here
> +
> %endif
>
>
> @@ -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}
> do
> mv $i .config
> Arch="x86"
> - if [ `echo $i | grep -c n900` -eq 1 ]; then
> - Arch="arm"
> - fi
> +%ifarch %{all_arm}
> + Arch="arm"
> +%endif
> # make oldconfig > /dev/null
> echo Doing $i
> make ARCH=$Arch %{oldconfig_target} > /dev/null
> @@ -739,9 +746,6 @@ BuildKernel() {
> cp configs/$Config .config
>
> Arch="x86"
> - if [ `echo $Config | grep -c n900` -eq 1 ]; then
> - Arch="arm"
> - fi
> %ifarch %{all_arm}
> Arch="arm"
> %endif
> @@ -766,7 +770,9 @@ BuildKernel() {
>
> mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
> make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer
> +%ifnarch %{all_arm}
> make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer
> +%endif
>
> # And save the headers/makefiles etc for building modules against
> #
> @@ -801,7 +807,12 @@ BuildKernel() {
> fi
> rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*.o
> rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*/*.o
> +%ifarch %{all_x86}
> cp -a --parents arch/x86/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
> +%endif
> +%ifarch %{all_arm}
> + cp -a --parents arch/arm/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
> +%endif
> mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
> cd include
> cp -a acpi asm-generic config crypto drm generated keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound video trace $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
> @@ -877,8 +888,10 @@ BuildKernel %make_target %kernel_image shcdk
> BuildKernel %make_target %kernel_image aava
> BuildKernel %make_target %kernel_image netbook
> BuildKernel %make_target %kernel_image ivi
> -%else
> -BuildKernel %make_target %kernel_image n900
> +%endif
> +
> +%ifarch %all_arm
> +BuildKernel %make_target %kernel_image arm-n900
> %endif
>
> cd tools/perf
> @@ -994,17 +1007,21 @@ fi}/
> %kernel_variant_preun ivi
> %kernel_variant_post -v ivi
>
> -%else
> +%endif
>
> -%kernel_variant_preun n900
> -%kernel_variant_post -v n900
> +%ifarch %{all_arm}
> +
> +%kernel_variant_preun arm-n900
> +%kernel_variant_post -v arm-n900
>
> %endif
>
> +%ifnarch %{all_arm}
> if [ -x /sbin/ldconfig ]
> then
> /sbin/ldconfig -X || exit $?
> fi
> +%endif
>
> ###
> ### file lists
> @@ -1034,7 +1051,9 @@ fi
> /lib/modules/%{KVERREL}%{?2:-%{2}}/kernel/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/build/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/source/
> +%ifnarch %{all_arm}/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/vdso/
> +%endif/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/modules.block/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/modules.dep.bin/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/modules.alias.bin/
> @@ -1061,8 +1080,10 @@ fi
> %kernel_variant_files 1 shcdk
> %kernel_variant_files 1 aava
> %kernel_variant_files 1 ivi
> -%else
> -%kernel_variant_files 1 n900
> +%endif
> +
> +%ifarch %{all_arm}
> +%kernel_variant_files 1 arm-n900
> %endif
>
>
> diff --git a/kernel.spec.in b/kernel.spec.in
> index 9bdfc7f..daaea1b 100644
> --- a/kernel.spec.in
> +++ b/kernel.spec.in
> @@ -60,7 +60,7 @@ Summary: The Linux kernel (the core of the Linux operating system)
>
> %define all_x86 i386 i586 i686 %{ix86}
>
> -%define all_arm arm armv5el
> +%define all_arm %{arm}
>
> # Overrides for generic default options
> %define all_arch_configs kernel-*.config
> @@ -81,10 +81,10 @@ Summary: The Linux kernel (the core of the Linux operating system)
> %endif
>
> %ifarch %{all_arm}
> -%define all_arch_configs kernel-*.config
> +%define all_arch_configs kernel-arm-*.config
> %define image_install_path boot
> -%define kernel_image vmlinux
> -%define make_target vmlinux
> +%define kernel_image arch/arm/boot/zImage
> +%define make_target zImage
> %endif
>
> %define oldconfig_target nonint_oldconfig
> @@ -246,11 +246,18 @@ This package contains the kernel optimized for the Menlow platform
> %description ivi
> This package contains the kernel optimized for In Vehicle Infotainment segments
>
> -%else
> -%define variant_summary Kernel for the Nokia N900
> -%kernel_variant_package n900
> -%description n900
> -This package contains the kernel optimized for the Nokia N900 device
> +%endif
> +
> +%ifarch %{all_arm}
> +
> +@@N900 #N900 ARM variant
> +@@N900 %define variant_summary Kernel for the Nokia N900
> +@@N900 %kernel_variant_package arm-n900
> +@@N900 %description arm-n900
> +@@N900 This package contains the kernel optimized for the Nokia N900 device
> +
> +#Put other ARM variants here
> +
> %endif
>
>
> @@ -336,13 +343,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}
> do
> mv $i .config
> Arch="x86"
> - if [ `echo $i | grep -c n900` -eq 1 ]; then
> - Arch="arm"
> - fi
> +%ifarch %{all_arm}
> + Arch="arm"
> +%endif
> # make oldconfig > /dev/null
> echo Doing $i
> make ARCH=$Arch %{oldconfig_target} > /dev/null
> @@ -399,9 +406,6 @@ BuildKernel() {
> cp configs/$Config .config
>
> Arch="x86"
> - if [ `echo $Config | grep -c n900` -eq 1 ]; then
> - Arch="arm"
> - fi
> %ifarch %{all_arm}
> Arch="arm"
> %endif
> @@ -426,7 +430,9 @@ BuildKernel() {
>
> mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
> make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer
> +%ifnarch %{all_arm}
> make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer
> +%endif
>
> # And save the headers/makefiles etc for building modules against
> #
> @@ -461,7 +467,12 @@ BuildKernel() {
> fi
> rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*.o
> rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*/*.o
> +%ifarch %{all_x86}
> cp -a --parents arch/x86/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
> +%endif
> +%ifarch %{all_arm}
> + cp -a --parents arch/arm/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
> +%endif
> mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
> cd include
> cp -a acpi asm-generic config crypto drm generated keys linux math-emu media mtd net pcmcia rdma rxrpc scsi sound video trace $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
> @@ -538,8 +549,10 @@ cd linux-%{kversion}
> @@N BuildKernel %make_target %kernel_image netbook
> @@W BuildKernel %make_target %kernel_image menlow
> @@I BuildKernel %make_target %kernel_image ivi
> -%else
> -@@A BuildKernel %make_target %kernel_image n900
> +%endif
> +
> +%ifarch %all_arm
> +@@N900 BuildKernel %make_target %kernel_image arm-n900
> %endif
>
> cd tools/perf
> @@ -657,17 +670,21 @@ fi}/
> @@I %kernel_variant_preun ivi
> @@I %kernel_variant_post -v ivi
>
> -%else
> +%endif
>
> -@@A %kernel_variant_preun n900
> -@@A %kernel_variant_post -v n900
> +%ifarch %{all_arm}
> +
> +@@N900 %kernel_variant_preun arm-n900
> +@@N900 %kernel_variant_post -v arm-n900
>
> %endif
>
> +%ifnarch %{all_arm}
> if [ -x /sbin/ldconfig ]
> then
> /sbin/ldconfig -X || exit $?
> fi
> +%endif
>
> ###
> ### file lists
> @@ -697,7 +714,9 @@ fi
> /lib/modules/%{KVERREL}%{?2:-%{2}}/kernel/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/build/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/source/
> +%ifnarch %{all_arm}/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/vdso/
> +%endif/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/modules.block/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/modules.dep.bin/
> /lib/modules/%{KVERREL}%{?2:-%{2}}/modules.alias.bin/
> @@ -725,8 +744,10 @@ fi
> @@M %kernel_variant_files 1 shcdk
> @@M %kernel_variant_files 1 aava
> @@I %kernel_variant_files 1 ivi
> -%else
> -@@A %kernel_variant_files 1 n900
> +%endif
> +
> +%ifarch %{all_arm}
> +@@N900 %kernel_variant_files 1 arm-n900
> %endif
>
>
> diff --git a/makespec.pl b/makespec.pl
> index 79cb8d6..5c432fb 100644
> --- a/makespec.pl
> +++ b/makespec.pl
> @@ -107,7 +107,7 @@ while (<>) {
> print "$1/n";
> next;
> }
> - if ($want_n900 > 0 && $line =~ //@/@A (.*)/) {
> + if ($want_n900 > 0 && $line =~ //@/@N900 (.*)/) {
> print "$1/n";
> next;
> }
> --
> 1.6.0.4
>
> _______________________________________________
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
------------------------------
Message: 18
Date: Tue, 20 Apr 2010 13:31:00 +0200
From: Nils Faerber <nils.faerber@kernelconcepts.de>
To: meego-dev <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] OMTP Bondi - any plans yet?
Message-ID: <4BCD9074.5080907@kernelconcepts.de>
Content-Type: text/plain; charset=ISO-8859-1
Jose Manrique Lopez de la Fuente wrote:
> Hello,
Hi!
> Nobody has W3C into account? (even when they are getting input from
> Nokia, BONDI, operators, browser developers,...)
>
> http://www.w3.org/2009/dap/
>
> That's the way!
Oh yes, this looks good!
Any comment from the MeeGo "managers"?
Is there a plan for this?
Could W3C-DAP be it?
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48 Fax: +49-271-771091-19
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
------------------------------
Message: 19
Date: Tue, 20 Apr 2010 14:42:41 +0300
From: "Mr. Todorov Todor" <tushe.todorov@gmail.com>
To: meego-dev@meego.com
Subject: [MeeGo-dev] NFC
Message-ID:
<l2w9d94b4651004200442ka99a78b7m95657b35e0bd9405@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi guys,
I am interested in what is the state of NFC, (near field
communication) on MeeGo.
Will there be protocol stack included, or will there be some high
level APIs exposed to the app developers?
Best regards
Todor
------------------------------
Message: 20
Date: Tue, 20 Apr 2010 07:48:52 -0700
From: Arjan van de Ven <arjan@linux.intel.com>
To: Roger Quadros <roger.quadros@nokia.com>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID: <4BCDBED4.60804@linux.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> +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.
------------------------------
Message: 21
Date: Tue, 20 Apr 2010 07:54:24 -0700
From: Arjan van de Ven <arjan@linux.intel.com>
To: Roger Quadros <roger.quadros@nokia.com>
Cc: "meego-dev@meego.com" <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID: <4BCDC020.50004@linux.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
------------------------------
Message: 22
Date: Tue, 20 Apr 2010 17:05:24 +0200
From: Carsten Munk <carsten@maemo.org>
To: meego-dev <meego-dev@meego.com>
Subject: [MeeGo-dev] Adding a kernel config to the MeeGo kernel source
Message-ID:
<t2wbcf450661004200805p156df3c3kb57203c61784c56@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
In the Nokia N8x0 hardware adaptation we're needing to add another
kernel config to the MeeGo kernel and I think many others may be
sitting with the same problem.
Is there any HOWTO/Documentation on how to add a new kernel
configuration (generally, not only ARM) into the packaging from
http://meego.gitorious.org/meego-os-base/kernel-source?
Currently it looks a little hairy,
http://meego.gitorious.org/meego-os-base/kernel-source/blobs/master/makespec.pl
and http://meego.gitorious.org/meego-os-base/kernel-source/blobs/master/kernel.spec.in,
for instance.
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?
Regards,
Carsten Munk
maemo.org distmaster
------------------------------
Message: 23
Date: Tue, 20 Apr 2010 08:11:18 -0700
From: Arjan van de Ven <arjan@linux.intel.com>
To: Carsten Munk <carsten@maemo.org>
Cc: meego-dev <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] Adding a kernel config to the MeeGo kernel
source
Message-ID: <4BCDC416.6000809@linux.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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)
------------------------------
Message: 24
Date: Tue, 20 Apr 2010 08:16:18 -0700
From: Greg KH <gregkh@suse.de>
To: Carsten Munk <carsten@maemo.org>
Cc: meego-dev <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] Adding a kernel config to the MeeGo kernel
source
Message-ID: <20100420151618.GB29179@suse.de>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 20, 2010 at 05:05:24PM +0200, Carsten Munk wrote:
> In the Nokia N8x0 hardware adaptation we're needing to add another
> kernel config to the MeeGo kernel and I think many others may be
> sitting with the same problem.
>
> Is there any HOWTO/Documentation on how to add a new kernel
> configuration (generally, not only ARM) into the packaging from
> http://meego.gitorious.org/meego-os-base/kernel-source?
File a bug with your new config added to it :)
> Currently it looks a little hairy,
> http://meego.gitorious.org/meego-os-base/kernel-source/blobs/master/makespec.pl
> and http://meego.gitorious.org/meego-os-base/kernel-source/blobs/master/kernel.spec.in,
> for instance.
>
> 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?
It gets overridden by the other config files.
Basically make a config file that is the difference between the generic
one, and yours, and add it to the spec file and it should all work
properly.
good luck,
greg k-h
------------------------------
Message: 25
Date: Tue, 20 Apr 2010 08:17:44 -0700
From: Arjan van de Ven <arjan@linux.intel.com>
To: "paler.tw" <paler.tw@gmail.com>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] VT_GETMODE failed Function not implemented
Message-ID: <4BCDC598.6020905@linux.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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)
------------------------------
Message: 26
Date: Tue, 20 Apr 2010 17:25:41 +0200
From: Carsten Munk <carsten@maemo.org>
To: Greg KH <gregkh@suse.de>
Cc: meego-dev <meego-dev@meego.com>
Subject: Re: [MeeGo-dev] Adding a kernel config to the MeeGo kernel
source
Message-ID:
<y2nbcf450661004200825ndfb3cdebk7b729f72e12b495c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/4/20 Greg KH <gregkh@suse.de>:
> On Tue, Apr 20, 2010 at 05:05:24PM +0200, Carsten Munk wrote:
>> Is there any HOWTO/Documentation on how to add a new kernel
>> configuration (generally, not only ARM) into the packaging from
>> http://meego.gitorious.org/meego-os-base/kernel-source?
>
> File a bug with your new config added to it :)
>
Probably better to test it locally before submitting, hence my
quseston. Even though I must admit that would encourage open
development by it being co-developed with the people receiving the
bugs ;)
> Basically make a config file that is the difference between the generic
> one, and yours, and add it to the spec file and it should all work
> properly.
Right, my point being however that it is not entirely clear how this
is supposed to be done properly by looking at the spec.in and the
scripts.
It is easy to butcher the spec a bit to make it build, but it would be
good to be able to do 'by the book' the first time, hence my question
about documentation. In order to limit work on both sides of a bug
report with a patch attached :)
Having it clearly documented also encourages hardware ports of MeeGo,
in my opinion ('So you'd like to get MeeGo onto your development
board..' type of guide)
Regards,
Carsten Munk
maemo.org distmaster
------------------------------
Message: 27
Date: Tue, 20 Apr 2010 16:41:38 +0100
From: David Greaves <david@dgreaves.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID: <4BCDCB32.6060902@dgreaves.com>
Content-Type: text/plain; charset=ISO-8859-1
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
>
>> -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.
I'd certainly like to; could you point me at the docs/README for the various
scripts in that package?
Essentially if I have a working .config file for a kernel for my new device how
do I package it?
Clearly there's a kernel.spec.in with the magical spec.in @@M macros but your
comment above suggests that that shouldn't be used in the way I'd assumed?
We have:
* configcommon.pl
* makespec.pl
* merge.pl
* Makefile.config
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.
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
------------------------------
Message: 28
Date: Tue, 20 Apr 2010 08:44:36 -0700
From: Arjan van de Ven <arjan@linux.intel.com>
To: David Greaves <david@dgreaves.com>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID: <4BCDCBE4.70302@linux.intel.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> 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-<arch>-generic -- architecture specific overrides on top of config-generic
config-<board> -- overrides that are board specific on top of config-<arch>-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.
------------------------------
Message: 29
Date: Tue, 20 Apr 2010 08:47:28 -0700
From: Arjan van de Ven <arjan@linux.intel.com>
To: David Greaves <david@dgreaves.com>
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Message-ID: <4BCDCC90.70802@linux.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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-<arch>-generic -- architecture specific overrides on top of
> config-generic
> config-<board> -- overrides that are board specific on top of
> config-<arch>-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.
------------------------------
Message: 30
Date: Tue, 20 Apr 2010 17:35:51 +0100
From: Elliot Smith <elliot.smith@intel.com>
To: meego-dev@meego.com
Subject: [MeeGo-dev] How to discover screen size from Mx?
Message-ID: <1271781351.13102.30.camel@localhost.localdomain>
Content-Type: text/plain; charset="us-ascii"
Hello,
How would I go about finding out the size of the current screen from an
Mx application (so I can use Mx.Window.set_small_screen(false) if on a
large monitor etc.)?
I'm assuming get_small_screen() will only tell me the current setting
for the small_screen property. Is that correct?
Thanks.
Elliot
--
Elliot Smith
Intel Open Source Technology Centre
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
------------------------------
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
End of MeeGo-dev Digest, Vol 3, Issue 20
****************************************
2764
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
