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
>
>
next prev parent reply other threads:[~2014-03-10 2:43 UTC|newest]
Thread overview: 29+ 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-05-07 16:29 ` Trevor Woerner
2013-05-07 17:13 ` Burton, Ross
2013-05-07 17:57 ` Trevor Woerner
2013-05-08 10:35 ` Burton, Ross
2013-05-08 12:46 ` Trevor Woerner
2013-04-29 20:57 Richard Purdie
2013-03-20 23:45 Richard Purdie
2010-06-29 17:25 Status update Eduard - Gabriel Munteanu
2010-06-30 8:37 ` Stefan Hajnoczi
2010-07-01 19:30 ` Eduard - Gabriel Munteanu
2010-07-02 8:03 ` Stefan Hajnoczi
2010-07-02 17:05 ` Eduard - Gabriel Munteanu
2006-12-28 12:25 status update Pam Phillips
2006-12-28 10:38 Connie Copeland
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 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.