From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com ([134.134.136.20]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1QDJAg-00030B-WB for openembedded-core@lists.openembedded.org; Fri, 22 Apr 2011 18:25:31 +0200 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 22 Apr 2011 09:23:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.64,254,1301900400"; d="scan'208";a="737101196" Received: from unknown (HELO [10.255.12.218]) ([10.255.12.218]) by orsmga001.jf.intel.com with ESMTP; 22 Apr 2011 09:23:04 -0700 From: Joshua Lock To: openembedded-core@lists.openembedded.org Date: Fri, 22 Apr 2011 09:23:04 -0700 In-Reply-To: <76BC4841-53CE-4F09-A5CE-7B627922451E@dominion.thruhere.net> References: <8313867A-EA5C-473D-A82B-D8338186BF5F@dominion.thruhere.net> <201104211605.28351.paul.eggleton@linux.intel.com> <1303404025.9960.6.camel@vorpal> <6252772B-4D5D-4E5D-BCD5-1A53C1D25AFA@dominion.thruhere.net> <1303407705.9960.51.camel@vorpal> <76BC4841-53CE-4F09-A5CE-7B627922451E@dominion.thruhere.net> X-Mailer: Evolution 3.0.0 (3.0.0-1.fc15) Message-ID: <1303489384.2293.5.camel@scimitar> Mime-Version: 1.0 Subject: Re: [RFC] Working toward a GNOME layer X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:25:31 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2011-04-21 at 20:12 +0200, Koen Kooi wrote: > Op 21 apr 2011, om 19:41 heeft Joshua Lock het volgende geschreven: > > > On Thu, 2011-04-21 at 19:29 +0200, Koen Kooi wrote: > >> Op 21 apr 2011, om 18:40 heeft Joshua Lock het volgende geschreven: > >> > >>> On Thu, 2011-04-21 at 16:05 +0100, Paul Eggleton wrote: > >>>> On Thursday 21 April 2011 15:02:49 Koen Kooi wrote: > >>>>> and possibly more. I would like to create a meta-gnome layer in the > >>>>> meta-openembedded repository where new recipes get added and things from > >>>>> meta-demoapps can get moved over into. Long term recipes-gnome in oe-core > >>>>> should move there as well. > >>>>> > >>>>> What are your thoughts on this? > >>> > >>> +1 > >>> > >>>> > >>>> From my perspective this sounds like a great idea. The only question would be > >>>> how much of the "GNOME" libs would remain in oe-core as some of them are quite > >>>> widely used outside of GNOME proper; however that can easily be worked out as > >>>> these things mature. > >>> > >>> +1 > >>> > >>> My personal opinion would be that we start with glib & gtk+ (plus their > >>> dependencies, i.e. pango, atk, etc) in core and move the rest out to a > >>> layer. > >>> > >>> I feel that Gtk+ is used by enough non-gnome software that it belongs in > >>> core but others may disagree? > >>> > >>> Between meta/recipes-gnome and meta-demoapps we have a reasonable start > >>> to a meta-gnome/ > >> > >> Where did meta-demoapps go? It's not in OE-core anymore by the looks of it. > > > > Hmm, still exists for me: > > > > joshual@vorpal:~/Projects/Yocto/oe-core/meta-demoapps[master] > > $ pwd > > /home/joshual/Projects/Yocto/oe-core/meta-demoapps > > > > > >> > >>> I'd be happy to help with this layer. > >> > >> Awesome, do you have any objection to put meta-gnome into the meta-openembedded repo for the time being? Once we get better tooling we can move it elsewhere, of course. > > > > None whatsoever. I keep meaning to push some recipes into that layer > > anyway. > > I just sent out 10 patches for review that import recipes-gnome from meta-demoapps into meta-gnome. Please review :) The way I see it there are two approaches, tidy & test the recipes then merge *or* merge then fix. If we're going for the latter approach let's get your patches merged! This does raise another question, is meta-oe striving for the same standards of metadata as oe-core? i.e. SRC_URI & license checksums, updated patch syntax, etc. Also, how much gnome do we want to support? Are we trying to be all new and shiny and drop deprecated libraries (gnome-vfs)? Just trying to work out what patches to work on ;-) Perhaps we can define a policy of what's appropriate for the layer in a README? Cheers, Joshua -- Joshua Lock Yocto Build System Monkey Intel Open Source Technology Centre