Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Status Update
Date: Sun, 09 Mar 2014 19:20:34 -0700	[thread overview]
Message-ID: <1394418034.7883.50.camel@ted> (raw)

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?
* 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:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10  2:20 Richard Purdie [this message]
2014-03-10  2:43 ` Status Update Robert Yang
  -- 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=1394418034.7883.50.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox