ed that to
bb.utils.vercmp_string.
Most of the patches for 2.17.2 apply unchanged, so renamed the directory
meta/recipes-core/util-linux/util-linux-2.17.2 to
meta/recipes-core/util-linux/util-linux so that they can be shared
between package revisions.
Signed-off-by: Chris Elston
---
meta/lib/o
> Chris, Saul updated to 2.19.1 two weeks ago:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=596e6807826c34a4f93d7cb26052d1bd7a985201
>
> It doesn't seem to have the vercmp change you mentioned, could you try to
> rebase your changes against that?
Thanks for pointing me
oe.dev may also be broken,
depending on the version of opkg in use.
Signed-off-by: Chris Elston
---
meta/classes/rootfs_ipk.bbclass | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass
b/meta/classes/rootfs_ipk.bbclass
index
We're looking to base an embedded development on oe-core in the near
future, and one of the things we must have is the ability to configure
features in/out of recipes per distro.
At the moment some recipes have a configuration / set of dependencies
baked in to the recipe. For example, gstreamer h
On Thu, 2011-06-30 at 16:13 -0700, Saul Wold wrote:
> On 06/30/2011 04:10 AM, Chris Elston wrote:
> > As discussed on IRC on 30/06/11, this patch adds support for
> > BAD_RECOMMENDATIONS to rootfs_ipk, which is a list of packages NOT to
> > install if suggested or recommende
> > I'm proposing something along the lines of the following:
>
> This is actually along the lines of what I've been thinking too!
Cool, I'm glad I'm not alone on this one :)
> How about something like the syntax for the recipe:
>
> PACKAGECONFIG[ogg] = "--enable-ogg, --disable-ogg, libogg"
> P
Since responses to my previous mail were generally positive, I've
reworked the package feature switches so that the interface is as RP
suggested.
In the recipe for foo you would have a set of features defined like
this:
PACKAGE_CONFIG[bar] = "--enable-bar, --disable-bar, libbar"
PACKAGE_CONFIG[ba
> Hi, with my Angstrom cap on I like this syntax and I think it will be
> really useful.
>
> A second level concern I have is about conflicting features, its not
> something we will come across probably in DISTRO land as we are sensible
> enough not to select them. But users could select them in l
On Mon, 2011-07-04 at 17:44 +0100, Graeme Gregory wrote:
> On 07/04/2011 05:12 PM, Chris Elston wrote:
> >> Hi, with my Angstrom cap on I like this syntax and I think it will be
> >> really useful.
> >>
> >> A second level concern I have is about conflict
On Mon, 2011-07-04 at 14:58 +0100, Richard Purdie wrote:
> On Mon, 2011-07-04 at 12:54 +0100, Chris Elston wrote:
> > Since responses to my previous mail were generally positive, I've
> > reworked the package feature switches so that the interface is as RP
> > suggested.
On Fri, 2011-07-08 at 09:38 +0100, Paul Eggleton wrote:
> On Friday 08 July 2011 06:21:16 Khem Raj wrote:
> > If oe-core never supported older kernel than 2.6.37 then setting it to
> > 2.6.37 would be better IMO
>
> It's not necessarily just about oe-core - it's about what layers get used on
> to
On Wed, 2011-07-06 at 15:25 -0700, Saul Wold wrote:
> On 07/01/2011 02:20 AM, Phil Blundell wrote:
> > On Fri, 2011-07-01 at 10:06 +0100, Chris Elston wrote:
> >> + STATUS=${IMAGE_ROOTFS}/var/lib/opkg/status
> >
> > Please make that use ${opkglibdir} like the rest of
On Mon, 2011-07-11 at 10:00 +0100, Phil Blundell wrote:
> On Mon, 2011-07-11 at 09:53 +0100, Chris Elston wrote:
> > + STATUS=${IMAGE_ROOTFS}${opkglibdir}/status
> > + mkdir -p `dirname ${STATUS}`
>
> Not that it's a massive deal, but this call to &quo
13 matches
Mail list logo