Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Status Update
Date: Mon, 10 Mar 2014 10:43:33 +0800	[thread overview]
Message-ID: <531D26D5.3050700@windriver.com> (raw)
In-Reply-To: <1394418034.7883.50.camel@ted>



On 03/10/2014 10:20 AM, Richard Purdie wrote:
> Its been a while since I sent one of these out, I never got back into
> the habit after I was away last year. I'm told they're useful to various
> people and they stop me having to repeat myself to people so I'm going
> to give them another go.
>
> Pending Patches
> ===============
>
> The feature freeze point for the 1.6 release is today. Some things of
> note that have merged recently including:
>
> * Reworked ext2/3/4 rootfs generation. Great work to the people involved
>    in getting the patches upstream! Can we delete genext2fs now? Please?

Yes, I think that we can delete the genext2fs since the "mke2fs -d" can
do the same thing as genext2fs.

// Robert

> * ToasterUI Updates
> * Systemd Upgrade to 209/210ish
> * lttng updates
> * core-image-basic renaming
> * PRINC deprecation warning
> * autotools aclocal improvements
> * using the separate build include by default
> * bitbake manual updates
> * various oe-selftest improvements/tweaks
>
> Its good to see many of these coming in, some have been long awaited.
>
> I'm aware we don't quite have some things yet, in particular the 3.14
> kernel so there are some changes to still to come in. We've been testing
> the -dev kernel on the autobuilder, we have a list of issues we need to
> resolve (perf mainly at this point) and as soon as 3.14 is officially
> released we'll be good to go. Other things I'm aware of as pending for
> 1.6 are:
>
> * gummiboot recipes (various versions exist in various layers, this
>    pulls things together hopefully)
> * oe-init-build-env tweaks from Gary
> * some parts of the "on hardware" automated testing
> * possibly some bitbake fetcher extension code for automated "upgrade"
>    detection
> * Enabling Separate B from S by default. Martin asked me to hold off
>    this until the issues form the previous changes get sorted out.
>    OE-Core is ready for it, the question is the other layers. We
>    probably need to bump the tmpdir ABI number for this change.
>
> I get the feeling there may be some other things which I don't have on
> the list too, please let me know of major pending features I don't have
> here.
>
> There are also some things looking very unlikely to get done in 1.6 at
> this point. These include:
>
> * Memory Resident and Interactive Bitbake work
> * Kernel installation footprint optimisation
> * python devshell
> * PR Server improvements
> * Locked SState support
>
> Patches for some parts of these exist but we're running out of runway to
> get them into a state ready to merge.
>
> The recent autobuilder changes did cause a backlog of patches waiting
> for testing. On the positive side the autobuilder does seem to have
> stabilised now and the changes present there have been worth waiting
> for. I believe we have caught up with most of the backlog now and had a
> mostly green build on Friday.
>
>
> Bitbake Changes
> ===============
>
> We found there were some issues when SIGTERM was sent to bitbake's
> various (sub)processes, as might happen on a buildbot or jenkins setup
> when stopping builds. The exact effect depended on the order the
> processes received the signal and ranged from locking up to using 100%
> CPU. There is a fairly comprehensive set of patches on the bitbake-devel
> list which should make things behave better.
>
> I've also been a little frustrated with the latency of certain bitbake
> commands, it seems to do nothing at some points and debugging confirmed
> that (e.g. setting the server/process.py select call timeout to 5s made
> the issues extremely obvious). Again, there are patches out to try and
> optimise out the various delays which are pointless and bitbake feels
> snappier as a result, at least to me anyway.
>
> I'd also like to give a mention to the BitBake manual once again. Its
> been heavily reworked, improved and brought up to date. The edits are
> now in bitbake master branch.
>
> 1.4.3
> =====
>
> This was held back due to the recent gnutls CVE, its now undergoing
> testing and should be ready for release soon if that is successful. If
> not, it will have to wait until after 1.6 ships.
>
>
> Cheers,
>
> Richard
>
>


  reply	other threads:[~2014-03-10  2:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10  2:20 Status Update Richard Purdie
2014-03-10  2:43 ` Robert Yang [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-03 12:01 Richard Purdie
2014-04-29  8:49 Richard Purdie
2014-04-29 11:29 ` Richard Purdie
2014-04-29 17:31   ` Otavio Salvador
2014-04-15 18:45 Richard Purdie
2014-04-08 12:25 Richard Purdie
2014-04-01 13:51 Richard Purdie
2014-03-24 11:53 Richard Purdie
2014-03-18 13:09 Richard Purdie
2013-07-01  7:01 Richard Purdie
2013-05-28 17:35 Richard Purdie
2013-05-28 19:34 ` Jack Mitchell
2013-05-07 12:45 Richard Purdie
2013-04-29 20:57 Richard Purdie
2013-03-20 23:45 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=531D26D5.3050700@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox