On 30 March 2014 16:14, Martin Jansa <[email protected]> wrote: > On Sun, Mar 30, 2014 at 03:48:09PM +0100, Paul Barker wrote: >> - We could create a new layer for unstable recipes which are 'use at >> your own risk'. That may be a good place for recipes which don't work >> on the jenkins builds but do work for some people and are in use (and >> so probably don't belong in nonworking). This is similar to the >> meta-broken or meta-nonworking layer idea but would take slightly more >> recipes in. > > The difference between meta-broken and meta-unstable from my POV is > that, "broken" should be just temporary place and someone should > eventually fix it, but if we move stuff to meta-unstable and stop > testing it, then I fear that it will became just junkyard. > > If some recipe works fine for someone when building for arm, but > triggers "jenkins/world" build issues for x86* then lets restrict it > only for arm with comment which shows the error - that's better than > moving it to "broken" or "unstable". >
I agree with the worry that this could turn into a junkyard. The problem is, the junk is currently mixed in with the good recipes. >> - It may be worth taking some aggressive action in sync with the >> upcoming oe-core release to get us to a green build, possibly by >> throwing things into meta-nonworking and meta-unstable layers. That >> may break a few people's builds, but the fix for them should just be >> to add the meta-unstable layer. If they're building against the master >> branch that should be tolerable and it won't affect anyone building >> from a released/stable branch until the next oe-core release in 6 >> months time. Once we have a green build it'll be much easier to QA >> patches and reject those which break the build. > > you mean being aggressive before or after creating the "next-release" > branch? I would prefer to be aggressive before to have green builds in > release branch. That would probably make more sense. > >> I don't have much time to give to fixing this myself as I'm busy with >> other projects. I do have idle computer time though so could run an >> automated build regularly (probably just a script and a cron job >> rather than buildbot/jenkins/etc). I won't be able to do a world build >> for every layer for multiple machines, but I should be able to do some >> subset. I may also be able to commandeer a spare server over the next >> few weeks. Is there any particular config which would be beneficial to >> build regularly? > > Doing "big" builds in different setups is of course useful, but right > now I think we already have "more logs than what we're processing". > > So I think that building not whole world, but those recipes which are > regularly failing would be good start, if people cannot reproduce some > issues which are shown in my jenkins builds we should compare the builds > and narrow possible reasons (e.g. failing only with dash, failing only > with some PACKAGECONFIG enabled or disabled). > > I'm trying to stay close to distroless config, but some tweaks are > needed in order to have bigger test coverage (e.g. enabling some > PACKAGECONFIGs which are disabled by default, but something requires > them, or changing P_V to newer again because something else needs it, > enabling gold, because it's more strict so it can catch more issues..) > > Jenkins builds are running almost non-stop (because it usually takes > around 24 hours per architecture), so often when I want to debug the > issue directly on that server in WORKDIR where it failed it's already > gone from tmpfs and the workspace is already "blocked" by next build. > Having a more focussed build would help but I can't really give any ability to debug it on the machine I run builds on and I don't really have time to debug much myself. It would literally just be a status and a set of logs for a different config. I think we need to prioritise what needs fixing first. I think doing a build of meta-oe only with no PACKAGECONFIG changes, disabling anything that requires PACKAGECONFIG changes, for qemuarm and qemux86 (and qemux86_64 if I have time) would be a good start to see what fails in that case. Then step out to further layers once meta-oe is green. -- Paul Barker Email: [email protected] http://www.paulbarker.me.uk -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
