From: Richard Purdie <rpurdie@rpsys.net>
To: bitbake-dev <bitbake-dev@lists.berlios.de>,
openembedded-devel <openembedded-devel@openembedded.org>
Subject: Bitbake Request for Testing of bitbake 1.8
Date: Mon, 05 Mar 2007 21:55:31 +0000 [thread overview]
Message-ID: <1173131731.5842.140.camel@localhost.localdomain> (raw)
I've been putting this off for a while but bitbake trunk has branched
for a new stable release series, 1.8.x which will ultimately replace the
1.6.x stable series.
Could people give the 1.8 branch in bitbake a try? If you have problems,
I will do my best to resolve them before 1.8.0 is released. I estimate
1.8.0 is say a week away, I want to release soon.
For what its worth, some of the core devs have been using trunk for a
while with success and its been used in poky without incident for a
while now too.
What's will be new in 1.8?
* We basically rewrote half the core. Bitbake used to calculate the
build path "on the fly" which was no use for multithreading, its now
been replaced with a calculation in advance (taskdata and runqueue).
This allows it to do simplistic multithreading. Set BB_NUMBER_THREADS =
"100" in local.conf to lock your machine up or something lower to try
multithreading ;-).
* The -g dependency graph output has changed and now includes a task
dependency file. Has anyone got a good way to view these graphically
yet?
* The fetchers were refactored removing duplicate code and standardising
behaviour.
* Numerous code changes were made internally to refactor/modularise the
code. This will be useful in future developments (the last code I
checked in prepares for the UI).
What will happen in trunk?
I've branched as I have some fairly invasive changes planned for trunk.
The aim of these is to split bitbake into a client/server and look at
UIs. Whilst 1.7.x was very stable more recently, 1.9.x is going to
break ;-).
The current UI code I have is about as secure as publishing your IP
address and root password on the web and leaving the telnet port open so
when I check it in, use at your own risk. I will accept patches to
address these issues ;-). My main concern is the structure at the moment
rather than security or functionality which can come later.
So please do test the bitbake 1.8 branch and lets make it as successful
as 1.6!
Cheers,
Richard
next reply other threads:[~2007-03-05 21:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-05 21:55 Richard Purdie [this message]
2007-03-06 4:15 ` Bitbake Request for Testing of bitbake 1.8 Mark Gross
2007-03-07 9:20 ` Richard Purdie
2007-03-07 14:05 ` Henning Heinold
2007-03-07 11:17 ` Christopher Lang
2007-03-07 14:26 ` Richard Purdie
2007-03-08 19:46 ` Christopher Lang
2007-03-08 20:26 ` Christopher Lang
2007-03-08 22:31 ` Richard Purdie
2007-03-09 9:33 ` Christopher Lang
2007-03-09 11:09 ` 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=1173131731.5842.140.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=bitbake-dev@lists.berlios.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@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.