On Sat, Apr 27, 2013 at 05:27:49PM +0100, Paul Barker wrote: > On 27 April 2013 12:35, Martin Jansa <martin.ja...@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.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
