[oe] [OE-core] State of bitbake world

Martin Jansa martin.jansa at gmail.com
Sat Apr 27 17:06:08 UTC 2013


On Sat, Apr 27, 2013 at 05:27:49PM +0100, Paul Barker wrote:
> On 27 April 2013 12:35, Martin Jansa <martin.jansa at gmail.com> wrote:
> >
> > I was hoping that people who care about them will step up and fix them
> > to build at least in default configuration - that's why I started to
> > send "state of bitbake world" emails.
> >
> 
> Most of the patches I've sent so far have resulted from running
> 'bitbake world' and seeing what warnings/errors I get. For raspberrypi
> my current BBMASK is:

That's great, I'm glad that I'm not the only one..

> /(rpi-first-run-wizard|qcanobserver|mesa-demos|packagegroup-core-tools|weston|gperftools|gst-plugins-gl|omxplayer|php|luajit|strongswan|mplayer2|net-snmp|openmotif|lzip|mg|vlc)

Some of those were already fixed, I've similar list, you can see it in
those directories with world build logs:
http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20130427_044751.log/world_mask.inc

but in some builds I tend to disable this .inc, because sometimes I add
stuff I know is broken to this file and then forget about it.. that's
why libunwind was merged, even when it was broken on qemuarm..

Moving broken recipes to "nonworking" directory instead of adding
PNBLACKLIST in this file is more visible to others (and in some cases it
forces people to really fix that - e.g. koen fixed couple of recipes he
cares about after I've sent removal commits and that's of course better
then (re)moving them.

Maybe we can share this list as some .inc file in meta-openembedded
repository but still looks a bit weird to keep broken recipes and then
exclude them explicitly.

Some recipes aren't broken per se, just pickly about enabled
DISTRO_FEATURES, TARGET_ARCH or kernel config etc.., but those should be
fixed too. Skipping package when required DISTRO_FEATURE is missing is
better then failing do_compile a bit later, comment will also help
someone to find out what he needs to enable to build that, example:
http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb?id=4c2434271cfc41e910969266ced9e5f06ee0c732

Also when some recipe in given version is known to be broken for some
arch, then imho better to explicitly say so and then maybe remove that
restriction later when newer version fixes that, example:
https://github.com/shr-distribution/meta-smartphone/commit/53271cc6637c759fff04e25cc262d43530a3b0fd

And worst is last group of packages failing because something else was
upgraded or changed and now it fails, e.g. emacs is now failing when
building for x86/x86-64 because qemu-native is segfaulting, but the same
qemu-native works fine when building emacs for arm..
It's not emacs fault, if I mark it as incompatible with x86* then when
qemu is fixed, nobody will notice and change emacs recipe to show it's
working for x86* again.

> Though that includes a few fetch fails which might work now. My notes say:
> 
> # rpi-first-run-wizard: no provider for zenity
> # qcanobserver: compile error
> # soft66: warning: Includes host paths
> # strongswan: fetch failure
> # lzip: fetch failure
> # mg: can't find term.h
> # zram: warning: systemd unshipped files
> # cloud9: warning: systemd unshipped files
> 
> I'll be adding more notes and taking another look over this, if
> there's anything in particular that should definitely be working but
> I've had to mask out, let me know and I'll give it another look.
> 
> (apologies for the noise due to gmail's big send button being so close
> to the bottom of the edit window and needing no confirmation)

I print qa.log at the end of world builds just to see if some new
changes I'm testing are creating new QA issues, now the list is not so
long as it used to be, so there is higher chance I'll notice new
entries, but it has 2 problems

1) QA issues are not listed when something is reused from sstate-cache
-> I'm removing sstate-cache when I can afford to keep jenkins busy for
3 days rebuilding 3 qemu* MACHINEs

2) not all WARNINGs shown when building are considered as QA issues and
not listed in qa.log, especially those about overwriting files in
sysroot are interesting in world builds, there is bug about that
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4085

Yes I can grep cooker log for all WARNINGs, but it's quite long in world
build and harder to extract that warning, because it has variable number
of lines and there isn't any closing "tag" 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20130427/378ed706/attachment-0002.sig>


More information about the Openembedded-devel mailing list