All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: openembedded-core git repository
Date: Tue, 25 Jan 2011 21:26:43 +0000	[thread overview]
Message-ID: <1295990803.27814.36.camel@rex> (raw)
In-Reply-To: <AANLkTi=ABs-jwjo=q5xGrKxvmYaLe05ePEtOez57E7ms@mail.gmail.com>

On Tue, 2011-01-25 at 11:19 -0700, Chris Larson wrote:
> On Tue, Jan 25, 2011 at 10:53 AM, Tom Rini <tom_rini@mentor.com> wrote:
> >>> * start an integration branch
> >>>  o remove bitbake
> >>
> >> Not sure what you mean with that. Which BB do you propose to use?
> >
> > Chris Larson has been doing a lot of work (and Richard has been confirming,
> > testing, etc, etc) to try and keep poky's bitbake changes in sync with
> > master when at all possible (the delta has gotten very very small, iirc).
> 
> I would personally like to see yocto use upstream bitbake with git
> submodules or similar, rather than maintaining its own bitbake
> directory.  I'd also like to see the bitbake sync completed, but it
> seems like it's a low priority for Richard at this time.  As you say,
> though, the delta is fairly small, considering.

I don't consider it a low priority and fully agree it needs to be fixed,
there needs to be no delta. I doubt I'd go for submodules but making it
match 1:1 commits with upstream bitbake is the intent and to script it.

The Yocto development window is closing which has influenced my priority
list. I'm also very conscious that we want to sort out a number of the
fetcher problems and we're not there with that yet so I'm having to make
some difficult choices over what I work on and in what order.

On the plus side two features have just landed in Poky/Yocto:

* Improved toolchain bootstrap process (no file overwriting)
* A sysroot per machine

which are both things we've wanted in OE for years and help in various
ways (e.g. making sstate/pstage easier and reliable).

We also merged libtool 2.4 and found a security hole that OE hadn't
spotted. Those problems have been reported to libtool upstream.

Cheers,

Richard




  reply	other threads:[~2011-01-25 21:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19 14:48 openembedded-core git repository Graeme Gregory
2011-01-19 15:32 ` Eric Bénard
2011-01-19 16:01   ` Graeme Gregory
2011-01-19 15:33 ` Frans Meulenbroeks
2011-01-19 15:59   ` Graeme Gregory
2011-01-19 17:14     ` Khem Raj
2011-01-19 18:52     ` Frans Meulenbroeks
2011-01-19 22:43       ` Graham Gower
2011-01-20 10:21         ` Frans Meulenbroeks
2011-01-20 15:24           ` Chris Larson
2011-01-19 19:43 ` Philip Balister
2011-01-21 11:22   ` Bernhard Guillon
2011-01-24 16:39 ` Philip Balister
2011-01-24 17:48   ` Khem Raj
2011-01-25 11:05     ` Koen Kooi
2011-01-25 14:49       ` Frans Meulenbroeks
2011-01-25 17:53         ` Tom Rini
2011-01-25 18:19           ` Chris Larson
2011-01-25 21:26             ` Richard Purdie [this message]
2011-01-25 15:23       ` Richard Purdie
2011-01-25 15:56         ` Koen Kooi
2011-01-25 18:28         ` Khem Raj
2011-01-25 18:24       ` Khem Raj
2011-01-24 21:43   ` Koen Kooi
2011-01-24 21:57     ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295990803.27814.36.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.