https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=EflanaganYocto Project - User contributions [en]2026-04-13T09:11:55ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=16030BuildLog2015-10-01T17:08:59Z<p>Eflanagan: </p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 558 ==<br />
* jethro 2.0 rc1 fired by eflanagan<br />
* meta-intel/meta-fsl* still at master.<br />
<br />
== Nightly 555 ==<br />
<br />
* master-next fired by RP, same as 554 but curl dropped, sigchld and make test in sdk fixed<br />
* RP killed stuck processes on nightly-x86 build<br />
<br />
== Nightly 554 ==<br />
<br />
* master-next fired by RP, same as 553 but curl dropped, runqemu permissions fixed<br />
* problems with qemurunner sigchld patch only on debian ABs<br />
* problems with make test in SDK hardcoded "gcc"<br />
<br />
== Nightly 553 ==<br />
<br />
* master-next fired by RP, test multilib fixes, pixbuf fixes, various mailing list patches, sstate fix<br />
* curl-native failure (deb-non-deb) reported on mailing list<br />
* runqemu permissions issue resolved in patch<br />
<br />
<br />
== Nightly 552 ==<br />
<br />
* master-next fired by Beth for RP, test sstate and multilib changes (tweaked rpm color on AB)<br />
<br />
== Nightly 551 ==<br />
<br />
* master-next fired by RP, test next round of fixes.<br />
* nightly-multilib likely from Robert's patches in that area, reported on list to Robert<br />
* nightly-arm-lsb - qemuarm segfault we already have bug for<br />
* nightly-intel-gpl - revision issues in meta-intel, sgw working on it<br />
<br />
== Nightly 550 ==<br />
<br />
* master-next fired by RP<br />
* contained fixed for kernel issues from Bruce<br />
* meta-intel-gpl revision not found in meta-intel issue reported to Bruce/Saul<br />
* nightly-ipk (qemux86) runtime test failure on connman tests [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8381 #8381] <br />
* nightly-qa-systemd (qemux86-64) internal server error sending error report - previously seen [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* nightly-ppc-lsb (mpc8315e-rdb) and nightly-x86-64-lsb (genericx86-64) smart runtime test failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8383 #8383]<br />
* nightly-qa-systemd (qemux86-64) avahi service failure - looks to be [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8142 #8142]<br />
<br />
== Nightly 549 ==<br />
<br />
* master-next fired by RP<br />
* srcrev in kernel issues reported to Bruce<br />
* oe-core failed due to kernel repo corruption (reported to Bruce)<br />
* nightly-arm hang due to gcc5 patch being lost in the kerne (reported to Bruce)<br />
<br />
== Nightly 547 ==<br />
* fido-next test build<br />
<br />
== Nightly 546 ==<br />
* master fired by eflanagan as replacement for 545<br />
* M3.rc1<br />
* some issues with release destination directory. ab patch pending<br />
<br />
== Nightly 545 ==<br />
* master fired by eflanagan as replacement for M3<br />
* failed immediately due to incorrect version set. DISTRO_VERSION QA check failed it out. Not planned but good to know it's working.<br />
<br />
== Nightly 544 ==<br />
* master-next fired by eflanagan as replacement for 543<br />
<br />
== Nightly 543 ==<br />
* master-next fired by RP<br />
* eflanagan killed after 54 minutes as fedora22 was locked on nightly git step. Tried sshing into machine, but is in dead lock.<br />
* eflanagan removed fedora22 from pool until mhalstead can resolve. Also fixed update-history buildset to run on fedora21 only.<br />
<br />
== Nightly 542 ==<br />
* master fired by RP<br />
* should be as 541 minus world failures (double check nothing else has issues)<br />
<br />
== Nightly 541 ==<br />
* master-next fired by RP<br />
* test out mips-lsb sanity test timeout issue<br />
* test qemuarm64 SDK fixes (and cover test arches with changes)<br />
<br />
== Nightly 540 ==<br />
* master-next fired and aborted by RP, user error<br />
<br />
== Nightly 539 ==<br />
* master-next fired by RP<br />
* incorrect data in branch, near enough master<br />
<br />
== Nightly 538 ==<br />
* master fired by eflanagan<br />
* no master fired in a while, let's get a baseline even though master-next has been close to master<br />
* RP aborted trailing two remaining targets to start master-next<br />
<br />
== Nightly 537 ==<br />
<br />
* master-next fired by RP<br />
* buildappliance webkitgtk build failure reported to alex in chat<br />
* sanity kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060] seems to be localised to the opensuse131 worker (nightly-arm-lsb, nightly-rpm)<br />
* nightly-mips-lsb sanity is timing out still<br />
* nightly-multilib nightly-ipk opkg error at do_rootfs [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8284 #8284]<br />
* nightly-world failed to apply a patch. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8285 #8285]<br />
* buildappliance failed to do_compile webkitgtk. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8286 #8286]<br />
* nightly-fsl builds fail with a perf QA install error. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8287 #8287]<br />
* oeselftest fails test_image_manifest_entries [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8288 #8288]<br />
<br />
== Nightly 535 ==<br />
<br />
* master-next fired by RP<br />
* includes yet more patches and may fix the mips build (try again)<br />
* should get better selftest failure output<br />
* nightly-oecore failure is qemuarm issue which has patch in -next (was oecore master build without patch)<br />
<br />
== Nightly 534 ==<br />
<br />
* master-next fired by RP<br />
* includes new systemd patches, new qemu arm segv fix, fix for selftest wic issue, fix for killing mips build (hopefully)<br />
* fix for killing mips does not work on mips-lsb it seems.<br />
* arm sanity test kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8269 #8269]<br />
* nightly-qa-systemd fails date test [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8270 #8270]<br />
* still seeing oeselftest and fsl-arm issues.<br />
<br />
== Nightly 533 ==<br />
<br />
* master-next fired by RP<br />
* as 532 but qemu arm segv fix test included too<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* oe-selftest: wic fix from Ed on mailing list<br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15794BuildLog2015-09-15T18:04:37Z<p>Eflanagan: </p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 546 ==<br />
* master fired by eflanagan as replacement for 545<br />
* M3.rc1<br />
* some issues with release destination directory. ab patch pending<br />
<br />
== Nightly 545 ==<br />
* master fired by eflanagan as replacement for M3<br />
* failed immediately due to incorrect version set. DISTRO_VERSION QA check failed it out. Not planned but good to know it's working.<br />
<br />
== Nightly 544 ==<br />
* master-next fired by eflanagan as replacement for 543<br />
<br />
== Nightly 543 ==<br />
* master-next fired by RP<br />
* eflanagan killed after 54 minutes as fedora22 was locked on nightly git step. Tried sshing into machine, but is in dead lock.<br />
* eflanagan removed fedora22 from pool until mhalstead can resolve. Also fixed update-history buildset to run on fedora21 only.<br />
<br />
== Nightly 542 ==<br />
* master fired by RP<br />
* should be as 541 minus world failures (double check nothing else has issues)<br />
<br />
== Nightly 541 ==<br />
* master-next fired by RP<br />
* test out mips-lsb sanity test timeout issue<br />
* test qemuarm64 SDK fixes (and cover test arches with changes)<br />
<br />
== Nightly 540 ==<br />
* master-next fired and aborted by RP, user error<br />
<br />
== Nightly 539 ==<br />
* master-next fired by RP<br />
* incorrect data in branch, near enough master<br />
<br />
== Nightly 538 ==<br />
* master fired by eflanagan<br />
* no master fired in a while, let's get a baseline even though master-next has been close to master<br />
* RP aborted trailing two remaining targets to start master-next<br />
<br />
== Nightly 537 ==<br />
<br />
* master-next fired by RP<br />
* buildappliance webkitgtk build failure reported to alex in chat<br />
* sanity kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060] seems to be localised to the opensuse131 worker (nightly-arm-lsb, nightly-rpm)<br />
* nightly-mips-lsb sanity is timing out still<br />
* nightly-multilib nightly-ipk opkg error at do_rootfs [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8284 #8284]<br />
* nightly-world failed to apply a patch. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8285 #8285]<br />
* buildappliance failed to do_compile webkitgtk. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8286 #8286]<br />
* nightly-fsl builds fail with a perf QA install error. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8287 #8287]<br />
* oeselftest fails test_image_manifest_entries [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8288 #8288]<br />
<br />
== Nightly 535 ==<br />
<br />
* master-next fired by RP<br />
* includes yet more patches and may fix the mips build (try again)<br />
* should get better selftest failure output<br />
* nightly-oecore failure is qemuarm issue which has patch in -next (was oecore master build without patch)<br />
<br />
== Nightly 534 ==<br />
<br />
* master-next fired by RP<br />
* includes new systemd patches, new qemu arm segv fix, fix for selftest wic issue, fix for killing mips build (hopefully)<br />
* fix for killing mips does not work on mips-lsb it seems.<br />
* arm sanity test kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8269 #8269]<br />
* nightly-qa-systemd fails date test [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8270 #8270]<br />
* still seeing oeselftest and fsl-arm issues.<br />
<br />
== Nightly 533 ==<br />
<br />
* master-next fired by RP<br />
* as 532 but qemu arm segv fix test included too<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* oe-selftest: wic fix from Ed on mailing list<br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15779BuildLog2015-09-14T11:31:51Z<p>Eflanagan: </p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
<br />
== Nightly 544 ==<br />
* master-next fired by eflanagan as replacement for 543<br />
<br />
== Nightly 543 ==<br />
* master-next fired by RP<br />
* eflanagan killed after 54 minutes as fedora22 was locked on nightly git step. Tried sshing into machine, but is in dead lock.<br />
* eflanagan removed fedora22 from pool until mhalstead can resolve. Also fixed update-history buildset to run on fedora21 only.<br />
<br />
== Nightly 542 ==<br />
* master fired by RP<br />
* should be as 541 minus world failures (double check nothing else has issues)<br />
<br />
== Nightly 541 ==<br />
* master-next fired by RP<br />
* test out mips-lsb sanity test timeout issue<br />
* test qemuarm64 SDK fixes (and cover test arches with changes)<br />
<br />
== Nightly 540 ==<br />
* master-next fired and aborted by RP, user error<br />
<br />
== Nightly 539 ==<br />
* master-next fired by RP<br />
* incorrect data in branch, near enough master<br />
<br />
== Nightly 538 ==<br />
* master fired by eflanagan<br />
* no master fired in a while, let's get a baseline even though master-next has been close to master<br />
* RP aborted trailing two remaining targets to start master-next<br />
<br />
== Nightly 537 ==<br />
<br />
* master-next fired by RP<br />
* buildappliance webkitgtk build failure reported to alex in chat<br />
* sanity kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060] seems to be localised to the opensuse131 worker (nightly-arm-lsb, nightly-rpm)<br />
* nightly-mips-lsb sanity is timing out still<br />
* nightly-multilib nightly-ipk opkg error at do_rootfs [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8284 #8284]<br />
* nightly-world failed to apply a patch. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8285 #8285]<br />
* buildappliance failed to do_compile webkitgtk. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8286 #8286]<br />
* nightly-fsl builds fail with a perf QA install error. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8287 #8287]<br />
* oeselftest fails test_image_manifest_entries [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8288 #8288]<br />
<br />
== Nightly 535 ==<br />
<br />
* master-next fired by RP<br />
* includes yet more patches and may fix the mips build (try again)<br />
* should get better selftest failure output<br />
* nightly-oecore failure is qemuarm issue which has patch in -next (was oecore master build without patch)<br />
<br />
== Nightly 534 ==<br />
<br />
* master-next fired by RP<br />
* includes new systemd patches, new qemu arm segv fix, fix for selftest wic issue, fix for killing mips build (hopefully)<br />
* fix for killing mips does not work on mips-lsb it seems.<br />
* arm sanity test kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8269 #8269]<br />
* nightly-qa-systemd fails date test [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8270 #8270]<br />
* still seeing oeselftest and fsl-arm issues.<br />
<br />
== Nightly 533 ==<br />
<br />
* master-next fired by RP<br />
* as 532 but qemu arm segv fix test included too<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* oe-selftest: wic fix from Ed on mailing list<br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15768BuildLog2015-09-11T16:39:38Z<p>Eflanagan: </p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 538 ==<br />
* master fired by eflanagan<br />
* no master fired in a while, let's get a baseline even though master-next has been close to master<br />
<br />
== Nightly 537 ==<br />
<br />
* master-next fired by RP<br />
* buildappliance webkitgtk build failure reported to alex in chat<br />
* sanity kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060] seems to be localised to the opensuse131 worker (nightly-arm-lsb, nightly-rpm)<br />
* nightly-mips-lsb sanity is timing out still<br />
* nightly-multilib nightly-ipk opkg error at do_rootfs [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8284 #8284]<br />
* nightly-world failed to apply a patch. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8285 #8285]<br />
* buildappliance failed to do_compile webkitgtk. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8286 #8286]<br />
* nightly-fsl builds fail with a perf QA install error. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8287 #8287]<br />
* oeselftest fails test_image_manifest_entries [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8288 #8288]<br />
<br />
== Nightly 535 ==<br />
<br />
* master-next fired by RP<br />
* includes yet more patches and may fix the mips build (try again)<br />
* should get better selftest failure output<br />
* nightly-oecore failure is qemuarm issue which has patch in -next (was oecore master build without patch)<br />
<br />
== Nightly 534 ==<br />
<br />
* master-next fired by RP<br />
* includes new systemd patches, new qemu arm segv fix, fix for selftest wic issue, fix for killing mips build (hopefully)<br />
* fix for killing mips does not work on mips-lsb it seems.<br />
* arm sanity test kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8269 #8269]<br />
* nightly-qa-systemd fails date test [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8270 #8270]<br />
* still seeing oeselftest and fsl-arm issues.<br />
<br />
== Nightly 533 ==<br />
<br />
* master-next fired by RP<br />
* as 532 but qemu arm segv fix test included too<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* oe-selftest: wic fix from Ed on mailing list<br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15764BuildLog2015-09-11T12:17:41Z<p>Eflanagan: /* Nightly 537 */</p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 537 ==<br />
<br />
* master-next fired by RP<br />
* buildappliance webkitgtk build failure reported to alex in chat<br />
* sanity kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060] seems to be localised to the opensuse131 worker (nightly-arm-lsb, nightly-rpm)<br />
* nightly-mips-lsb sanity is timing out still<br />
* nightly-multilib nightly-ipk opkg error at do_rootfs [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8284 #8284]<br />
* nightly-world failed to apply a patch. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8285 #8285]<br />
* buildappliance failed to do_compile webkitgtk. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8286 #8286]<br />
* nightly-fsl builds fail with a perf QA install error. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8287 #8287]<br />
* oeselftest fails test_image_manifest_entries [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8288 #8288]<br />
<br />
== Nightly 535 ==<br />
<br />
* master-next fired by RP<br />
* includes yet more patches and may fix the mips build (try again)<br />
* should get better selftest failure output<br />
* nightly-oecore failure is qemuarm issue which has patch in -next (was oecore master build without patch)<br />
<br />
== Nightly 534 ==<br />
<br />
* master-next fired by RP<br />
* includes new systemd patches, new qemu arm segv fix, fix for selftest wic issue, fix for killing mips build (hopefully)<br />
* fix for killing mips does not work on mips-lsb it seems.<br />
* arm sanity test kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8269 #8269]<br />
* nightly-qa-systemd fails date test [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8270 #8270]<br />
* still seeing oeselftest and fsl-arm issues.<br />
<br />
== Nightly 533 ==<br />
<br />
* master-next fired by RP<br />
* as 532 but qemu arm segv fix test included too<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* oe-selftest: wic fix from Ed on mailing list<br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15732BuildLog2015-09-08T16:39:33Z<p>Eflanagan: /* Nightly 534 */</p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 534 ==<br />
<br />
* master-next fired by RP<br />
* includes new systemd patches, new qemu arm segv fix, fix for selftest wic issue, fix for killing mips build (hopefully)<br />
* fix for killing mips does not work on mips-lsb it seems.<br />
* arm sanity test kernel panic [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8269 #8269]<br />
* nightly-qa-systemd fails date test [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8270 #8270]<br />
* still seeing oeselftest and fsl-arm issues.<br />
<br />
== Nightly 533 ==<br />
<br />
* master-next fired by RP<br />
* as 532 but qemu arm segv fix test included too<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* oe-selftest: wic fix from Ed on mailing list<br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15723BuildLog2015-09-07T12:50:01Z<p>Eflanagan: /* Nightly 532 */</p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 532 ==<br />
<br />
* master-next fired by RP<br />
* has fixed pseudo 1.7.3<br />
* RP's qemu error handling should be fixed<br />
* mips-lsb sanitytest: probably [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] and [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8257 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
* x86-64-lsb sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8264 #8239] Logrotate setup failed causing test to error out<br />
* oe-selftest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8265 #8265] oe-selftest sstatetests failed test_sstate_cache_management_script_using_machine <br />
* meta-fsl-arm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8266 #8266] fails do_compile of xf86-video-imxfb-vivante<br />
<br />
== Nightly 531 ==<br />
<br />
* master-next fired by RP<br />
* sanity failures from RP's qemu error handling patch, aborted near end<br />
* poky-tiny issue from Khem's busybox patch (reported to list), patch dropped<br />
<br />
== Nightly 530 ==<br />
<br />
* master-next fired by RP<br />
* Joshua's kmod patch had issues with ln -r (reported to list), patch dropped, build aborted<br />
<br />
== Nightly 529 ==<br />
<br />
* master-next fired by RP<br />
* pseudo issues, build aborted<br />
<br />
== Nightly 528 ==<br />
<br />
* master-next fired by RP<br />
* fsl-arm build: reported on meta-freescale<br />
* mips-lsb sanitytest: probably same old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* mips-lsb build: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] ERROR: Only one copy of bitbake should be run against a build directory<br />
<br />
== Nightly 525 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list (some dropped, more added including psuedo 1.7.1)<br />
* build failures: reported by RP on list (pseudo issue)<br />
* qa-skeleton sanitytest (errors in dmesg log): [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 #8245]<br />
* x86 sanitytest: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* arm sanitytest: old [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] test image stops responding<br />
* intel-gpl buildimages: RP reported to pidge on chat <br />
<br />
== Nightly 524 ==<br />
<br />
* master-next fired by RP<br />
* Test of patches from mailing list<br />
* nightly-ipk opkg failure reported on list to opkg patch sender, looks like image.poy volatiles patch now?<br />
* arm-lsb testimage failure looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8210 #8210] -- needs manual cleanup?<br />
* mip64 testimage failure probably caused the above problem [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8241 #8241] "qemu ended unexpectedly"<br />
* oe-selftest failure reported on list to ed bartosh, looks like Markus devtool patches<br />
* rpm-non-rpm: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* systemd sanity test seems similar to earlier testimage failures: works fine until suddenly no response at all [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
<br />
== Nightly 523 ==<br />
<br />
* master-next fired by RP<br />
* DOA due to bitbake bug, replied on list about patch issue to Alex Franco<br />
<br />
== Nightly 522 ==<br />
<br />
* master fired by RP<br />
* test current status after merging various patches<br />
* nightly-deb sanitytest2 failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8061 #8061] "Occasional qemux86 segfault"<br />
* nightly-arm sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234] (same testimage fails as some previous builds)<br />
* nightly-mips sanitytest failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8139 #8139] "smart failures occur ... on several builders"<br />
* mips-lsb build failure: [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8239 #8239] "strange build failure with no output"<br />
<br />
== Nightly 521 ==<br />
<br />
* poky:master fired by halstead for testing build failure mails<br />
* nightly-arm-lsb (core-image-lsb-sdk) testimage failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8234 #8234]<br />
* RP killed in favour of 522<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
* ccache build failure (upgrade related) reported by RP on mailing list<br />
* Race between a qa check and packaging reported in ML thread ''Add checks for "host user contamination"''<br />
* imagetest timeout [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8229 #8229]<br />
* toaster upload failures (and strange successes) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8230 #8230]<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Build_Failure_Swat_Team&diff=15722Yocto Build Failure Swat Team2015-09-07T12:07:29Z<p>Eflanagan: /* Scope of Responsibility */</p>
<hr />
<div>==Overview==<br />
<br />
The assembly of the Yocto Project SWAT team is mainly to tackle urgent technical problems that break build on the master branch or major release branches in a timely manner, thus to maintain the stability of the master and release branch. The SWAT team includes volunteers or appointed members of the Yocto Project team. Community members can also volunteer to be part of the SWAT team.<br />
<br />
==Scope of Responsibility==<br />
<br />
Whenever a build (nightly build if master or master-next, weekly build, release build) fails, the SWAT team is responsible for ensuring the necessary debugging occurs and organizing resources to solve the issue and ensure successful builds. If resolving the issues requires schedule or resource adjustment, the SWAT team should work with program and development management to accommodate the change in the overall planning. If resolving the issues requires access to the autobuilder, please contact either [[User:Eflangan| Beth Flanagan]] or [[User:Mhalstead| Michael Halstead]] for access rights.<br />
<br />
In general, priority should always go first towards major release candidates and secondly to master failures. <br />
<br />
Point releases (yocto-1.X.x) should have minimal problems in the first place. As well, stable branch maintainers should be paying attention to their own point release candidate builds.<br />
<br />
Build failures are reported on the [https://lists.yoctoproject.org/listinfo/yocto-builds yocto-build mailing list].<br />
<br />
Please review the [[Media:Swat.odp]] presentation.<br />
<br />
==Members==<br />
<br />
* Elizabeth Flanagan (IE) (Autobuilder Maintainer)<br />
* Saul Wold (US) (Autobuilder Administrator)<br />
* Paul Eggleton (UK)<br />
* Ross Burton (UK)<br />
* Cristian Iorga (RO)<br />
* Randy Witt (US)<br />
* Benjamin Esquivel (MX)<br />
* Juro Bystricky (US)<br />
* Anibal Limon (MX)<br />
* Tracy Graydon (US)<br />
* Alejandro Hermandez (MX)<br />
* Jussi Kukkonen (FI)<br />
<br />
==Chair==<br />
A chairperson role will be rotated among team members each week on Friday. The Chairperson should monitor the build status for the entire week. Whenever a build is broken, the Chairperson should do necessary debugging and organize resources to solve the problems in a timely manner to meet the overall project and release schedule. The Chairperson serves as the focal point of the SWAT team to external people such as program managers or development managers.<br />
<br />
==Rotation Process==<br />
The Chairperson rotation takes place during the weekly when the Friday morning status report is sent. Usually, this will take a simple round robin order. In case the next person cannot take the role due to tight schedule, vacation or some other reasons, the role will be passed to the next person.<br />
<br />
==Process==<br />
<br />
The wiki page [[BuildLog]] will list why a build has been triggered and what the expectations of that build are. For each build failure that occurs, the expectation is a bug is opened for each issue found, or, if there is already a bug for the issue, that the new failure is appended to that bugzilla entry. There are some exceptions to this:<br />
<br />
* If the build is a master-next or mut build, then an alternative is to reply to the unmerged patch causing the problem on the mailing list with a link to the failure<br />
* If the BuildLog mentions that bugs are not to be filed, there is no need.<br />
* If someone has sent out a patch for the issue already.<br />
<br />
You can always check with the person who triggered the build but if in doubt file a bug. Failures on master should always have corresponding bug entries.<br />
<br />
Whatever the outcome, you should add a note to the BuildLog page explaining which action was taken for each failure.<br />
<br />
The primary responsibility is to ensure that any failures are categorized correctly and that the right people get to know about them. It's important *someone* is then tasked with fixing it. To fulfill the primary responsibility, bugs are opened on the bugzilla for each type of failure. This way, appropriate people can be brought into the discussion and a specific owner of the failure can be assigned. Replying to the build failure with the bug ID and also bringing the bug to the attention of anyone you suspect was responsible for the problem are also good practices.<br />
<br />
Ideally we want to get the failure reported to the person who knows something about the area and can come up with a fix without it distracting them too much.<br />
As a secondary responsibility, it's often helpful to triage the failure. This might mean documenting a way to reproduce the failure outside a full build and/or documenting how the failure is happening and maybe even propose a fix. The SWAT team is not responsible for debugging the failure though, only ensuring it is reported and that someone is found to look at the issue.<br />
<br />
When filing the bug, please cut and paste the relevant error in the bug comment, and include the log file as an attachment. This ensures the assignee and triage team can quickly asses this issue.<br />
'''In the bug report, do not post links to any Autobuilder log. The logs are non-persistent and hence the bug report will eventually end up with a dead link.'''<br />
'''Sometimes, failures occur on autobuilders on private company networks. Do not post links into the bugzilla for these failures, its pointless as nobody else can access them.'''<br />
<br />
Every build failure should be responded to. If it is a known issue, a response with a single line containing "Known Issue" is sufficient. This assures others that the failure has been looked at and is being worked on.<br />
<br />
==Debugging BKMs==<br />
<br />
When looking at a failure, the first question is what the baseline was and what changed. If there were recent known good builds it helps to narrow down the number of changes that were likely responsible for the failure. It's also useful to note if the build was from scratch or from existing sstate files. You can tell by seeing what "setscene" tasks run in the log.<br />
<br />
Image failures are particular tricky since its likely some component of the image that failed and the question is then whether that component changed recently, whether it was some kind of core functionality at fault and so on.<br />
<br />
If a build fails, you can check which branch the build failure occurred on in the error log, i.e. the log contains:<br />
<br />
''branch : master-next''<br />
<br />
==Autobuilder BKMs==<br />
<br />
Sometimes failures are difficult to understand and can require direct ssh access to the autobuilder so the issue can be debugged passively on the system to examine contents of files and so forth. If doing this ensure you don't change any of the file system for example adding files that couldn't then be deleted by the autobuilder when it rebuilds.<br />
<br />
Rarely, "live" debugging might be needed where you'd su to the pokybuild user and run a build manually to see the failure in real time. If doing this, ensure you only create files as the pokybuild user and you are careful not to generate sstate packages which shouldn't be present or any other bad state that might get reused. In general its recommended not to do "live" debugging. This can be escalated to RP/Saul/Beth if needed.<br />
<br />
Live debugging is generally something we try to avoid doing. It should only occur if an issue can only be reproduced on the autobuilder.<br />
<br />
===Autobuilder Overview===<br />
<br />
====Infrastructure Overview====<br />
ab01: The yocto master autobuilder. This runs one low utility slave which does, universe fetch, package index, bitbake self test, builds the adt-installer and generally acts as the release mechanism for the Yocto Project. It also acts as a trigger parent for our full nightly build. This nightly build is essentially what builds our release, minus release notes.<br />
<br />
ab02, ab04, ab05, ab06, ab10: Generic nightly slaves. These run three slaves a piece. ab10 also runs our eclipse plugin build<br />
<br />
====Build Targets====<br />
Nightly is a "dummy" buildset that does relatively few things and is only ever run on ab01. It mainly does universe fetch, building<br />
adt-installer and building the eclipse plugin. It's main function is to trigger nightly-${ARCH} and wait until they're done. ab02, ab04,<br />
ab05, ab06 are what is used to run this pool of nightly arch builds. <br />
<br />
NOTE: Just because nightly-* ran on ab04 the last time does not mean it will again. It's semi random. In order to find out what host you need to log into, please look for the buildstep that says:<br />
<br />
Building on<br />
autobuilder04<br />
Linux autobuilder04 2.6.37.6-0.9-default #1 SMP 2011-10-19 22:33:27<br />
+0200 x86_64 x86_64 x86_64 GNU/Linux<br />
<br />
====Build "gotchas"====<br />
Currently, we share sstate-cache and downloads between these slaves via NAS. For the moment we are also splitting up sstate and lsb-sstate. They are currently stored in /srv/www/vhosts/autobuilder.yoctoproject.org/pub/[sstate|lsb-sstate]. This will change after M2 to be combined into one directory; /srv/www/vhosts/autobuilder.yoctoproject.org/pub/sstate<br />
<br />
TMPDIR between distros (poky and poky-lsb) is not shared. $TMPDIR ends up being moved to ~pokybuild/yocto-autobuilder/yocto-slave/nightly-${ARCH}/build/build/nonlsb-tmp and poky-lsb is left in the above path's tmp. <br />
<br />
<br />
====Live Debugging Process====<br />
If you need to do live debugging on the autobuilder, you want to:<br />
<br />
* Check that nothing is running on the builder:<br />
https://autobuilder.yoctoproject.org/main/buildslaves<br />
<br />
* If nothing is running, remove the buildslave from the pool. Please let either Beth or sgw know if you're planning on doing this. Email/IRC is fine.<br />
<br />
Keep in mind that we are currently utilizing two autobuilders. One is just for bugzilla reference (logs and whatnot), the other is production. There have been instances of people not know where the running autobuilder lives.<br />
<br />
The new autobuilder lives in ~/pokybuild/yocto-autobuilder-new. This will eventually change when I EOL the old autobuilder. However, when in doubt about where to find the base dir of the slave, always check the Create BBLayers Configuration step of the build you want. From this you can derive the base dir.<br />
<br />
Example:<br />
<br />
http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101<br />
<br />
Looking at: http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101/steps/CreateAutoConf/logs/stdio shows that we've not moved TMPDIR<br />
<br />
Looking at: http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101/steps/Create%20BBLayers%20Configuration/logs/stdio<br />
<br />
"BBLAYERS += " \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-yocto \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-yocto-bsp \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-qt3 \ <br />
" <br />
<br />
indicates that the layers all exist in the slave's build dir for that build set. Which means that TMPDIR is most likely in:<br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/build/tmp<br />
<br />
<nowiki><br />
sudo -i -u pokybuild<br />
cd yocto-autobuilder-new<br />
. ./yocto-autobuilder-setup<br />
./yocto-stop-autobuilder slave<br />
</nowiki><br />
<br />
This will ensure that the directory you are working in doesn't disappear out from under you. Please make sure that after you are done, you restart:<br />
<br />
<nowiki><br />
sudo -i -u pokybuild<br />
cd yocto-autobuilder-new<br />
. ./yocto-autobuilder-setup<br />
./yocto-start-autobuilder slave<br />
</nowiki><br />
<br />
=====Things to never do=====<br />
* NEVER clean sstate (cleanall, cleansstate). As sstate is shared across builders, you do not want it wiped like this. If you need to toss sstate, let Beth/sgw/RP know. We try not to remove sstate as it speeds up build times dramatically. As it's fairly large and takes a while to wipe, we try to avoid this.<br />
* NEVER stop ab01's master/slave. If you need to debug something on ab01, let sgw, RP and Beth know. As we're the only three who can kick builds off, it's really important they all know so they don't kick off a build and tromp on live debugging. If you need to work on ab01 one of them must know about it *and* have given the ok.<br />
* NEVER create a file as yourself under ~pokybuild/yocto-autobuilder/* This can cause future builds to fail and is frustrating to debug.<br />
* NEVER post links to any Autobuilder log in bug reports. The logs are non-persistent and hence the bug report will eventually end up with a dead link.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Build_Failure_Swat_Team&diff=15721Yocto Build Failure Swat Team2015-09-07T11:58:48Z<p>Eflanagan: /* Members */</p>
<hr />
<div>==Overview==<br />
<br />
The assembly of the Yocto Project SWAT team is mainly to tackle urgent technical problems that break build on the master branch or major release branches in a timely manner, thus to maintain the stability of the master and release branch. The SWAT team includes volunteers or appointed members of the Yocto Project team. Community members can also volunteer to be part of the SWAT team.<br />
<br />
==Scope of Responsibility==<br />
<br />
Whenever a build (nightly build, weekly build, release build) fails, the SWAT team is responsible for ensuring the necessary debugging occurs and organizing resources to solve the issue and ensure successful builds. If resolving the issues requires schedule or resource adjustment, the SWAT team should work with program and development management to accommodate the change in the overall planning. If resolving the issues requires access to the autobuilder, please contact either [[User:Eflangan| Beth Flanagan]] or [[User:Mhalstead| Michael Halstead]] for access rights.<br />
<br />
In general, priority should always go first towards major release candidates and secondly to master failures. <br />
<br />
Point releases (yocto-1.X.x) should have minimal problems in the first place. As well, stable branch maintainers should be paying attention to their own point release candidate builds.<br />
<br />
Build failures are reported on the [https://lists.yoctoproject.org/listinfo/yocto-builds yocto-build mailing list].<br />
<br />
Please review the [[Media:Swat.odp]] presentation.<br />
<br />
==Members==<br />
<br />
* Elizabeth Flanagan (IE) (Autobuilder Maintainer)<br />
* Saul Wold (US) (Autobuilder Administrator)<br />
* Paul Eggleton (UK)<br />
* Ross Burton (UK)<br />
* Cristian Iorga (RO)<br />
* Randy Witt (US)<br />
* Benjamin Esquivel (MX)<br />
* Juro Bystricky (US)<br />
* Anibal Limon (MX)<br />
* Tracy Graydon (US)<br />
* Alejandro Hermandez (MX)<br />
* Jussi Kukkonen (FI)<br />
<br />
==Chair==<br />
A chairperson role will be rotated among team members each week on Friday. The Chairperson should monitor the build status for the entire week. Whenever a build is broken, the Chairperson should do necessary debugging and organize resources to solve the problems in a timely manner to meet the overall project and release schedule. The Chairperson serves as the focal point of the SWAT team to external people such as program managers or development managers.<br />
<br />
==Rotation Process==<br />
The Chairperson rotation takes place during the weekly when the Friday morning status report is sent. Usually, this will take a simple round robin order. In case the next person cannot take the role due to tight schedule, vacation or some other reasons, the role will be passed to the next person.<br />
<br />
==Process==<br />
<br />
The wiki page [[BuildLog]] will list why a build has been triggered and what the expectations of that build are. For each build failure that occurs, the expectation is a bug is opened for each issue found, or, if there is already a bug for the issue, that the new failure is appended to that bugzilla entry. There are some exceptions to this:<br />
<br />
* If the build is a master-next or mut build, then an alternative is to reply to the unmerged patch causing the problem on the mailing list with a link to the failure<br />
* If the BuildLog mentions that bugs are not to be filed, there is no need.<br />
* If someone has sent out a patch for the issue already.<br />
<br />
You can always check with the person who triggered the build but if in doubt file a bug. Failures on master should always have corresponding bug entries.<br />
<br />
Whatever the outcome, you should add a note to the BuildLog page explaining which action was taken for each failure.<br />
<br />
The primary responsibility is to ensure that any failures are categorized correctly and that the right people get to know about them. It's important *someone* is then tasked with fixing it. To fulfill the primary responsibility, bugs are opened on the bugzilla for each type of failure. This way, appropriate people can be brought into the discussion and a specific owner of the failure can be assigned. Replying to the build failure with the bug ID and also bringing the bug to the attention of anyone you suspect was responsible for the problem are also good practices.<br />
<br />
Ideally we want to get the failure reported to the person who knows something about the area and can come up with a fix without it distracting them too much.<br />
As a secondary responsibility, it's often helpful to triage the failure. This might mean documenting a way to reproduce the failure outside a full build and/or documenting how the failure is happening and maybe even propose a fix. The SWAT team is not responsible for debugging the failure though, only ensuring it is reported and that someone is found to look at the issue.<br />
<br />
When filing the bug, please cut and paste the relevant error in the bug comment, and include the log file as an attachment. This ensures the assignee and triage team can quickly asses this issue.<br />
'''In the bug report, do not post links to any Autobuilder log. The logs are non-persistent and hence the bug report will eventually end up with a dead link.'''<br />
'''Sometimes, failures occur on autobuilders on private company networks. Do not post links into the bugzilla for these failures, its pointless as nobody else can access them.'''<br />
<br />
Every build failure should be responded to. If it is a known issue, a response with a single line containing "Known Issue" is sufficient. This assures others that the failure has been looked at and is being worked on.<br />
<br />
==Debugging BKMs==<br />
<br />
When looking at a failure, the first question is what the baseline was and what changed. If there were recent known good builds it helps to narrow down the number of changes that were likely responsible for the failure. It's also useful to note if the build was from scratch or from existing sstate files. You can tell by seeing what "setscene" tasks run in the log.<br />
<br />
Image failures are particular tricky since its likely some component of the image that failed and the question is then whether that component changed recently, whether it was some kind of core functionality at fault and so on.<br />
<br />
If a build fails, you can check which branch the build failure occurred on in the error log, i.e. the log contains:<br />
<br />
''branch : master-next''<br />
<br />
==Autobuilder BKMs==<br />
<br />
Sometimes failures are difficult to understand and can require direct ssh access to the autobuilder so the issue can be debugged passively on the system to examine contents of files and so forth. If doing this ensure you don't change any of the file system for example adding files that couldn't then be deleted by the autobuilder when it rebuilds.<br />
<br />
Rarely, "live" debugging might be needed where you'd su to the pokybuild user and run a build manually to see the failure in real time. If doing this, ensure you only create files as the pokybuild user and you are careful not to generate sstate packages which shouldn't be present or any other bad state that might get reused. In general its recommended not to do "live" debugging. This can be escalated to RP/Saul/Beth if needed.<br />
<br />
Live debugging is generally something we try to avoid doing. It should only occur if an issue can only be reproduced on the autobuilder.<br />
<br />
===Autobuilder Overview===<br />
<br />
====Infrastructure Overview====<br />
ab01: The yocto master autobuilder. This runs one low utility slave which does, universe fetch, package index, bitbake self test, builds the adt-installer and generally acts as the release mechanism for the Yocto Project. It also acts as a trigger parent for our full nightly build. This nightly build is essentially what builds our release, minus release notes.<br />
<br />
ab02, ab04, ab05, ab06, ab10: Generic nightly slaves. These run three slaves a piece. ab10 also runs our eclipse plugin build<br />
<br />
====Build Targets====<br />
Nightly is a "dummy" buildset that does relatively few things and is only ever run on ab01. It mainly does universe fetch, building<br />
adt-installer and building the eclipse plugin. It's main function is to trigger nightly-${ARCH} and wait until they're done. ab02, ab04,<br />
ab05, ab06 are what is used to run this pool of nightly arch builds. <br />
<br />
NOTE: Just because nightly-* ran on ab04 the last time does not mean it will again. It's semi random. In order to find out what host you need to log into, please look for the buildstep that says:<br />
<br />
Building on<br />
autobuilder04<br />
Linux autobuilder04 2.6.37.6-0.9-default #1 SMP 2011-10-19 22:33:27<br />
+0200 x86_64 x86_64 x86_64 GNU/Linux<br />
<br />
====Build "gotchas"====<br />
Currently, we share sstate-cache and downloads between these slaves via NAS. For the moment we are also splitting up sstate and lsb-sstate. They are currently stored in /srv/www/vhosts/autobuilder.yoctoproject.org/pub/[sstate|lsb-sstate]. This will change after M2 to be combined into one directory; /srv/www/vhosts/autobuilder.yoctoproject.org/pub/sstate<br />
<br />
TMPDIR between distros (poky and poky-lsb) is not shared. $TMPDIR ends up being moved to ~pokybuild/yocto-autobuilder/yocto-slave/nightly-${ARCH}/build/build/nonlsb-tmp and poky-lsb is left in the above path's tmp. <br />
<br />
<br />
====Live Debugging Process====<br />
If you need to do live debugging on the autobuilder, you want to:<br />
<br />
* Check that nothing is running on the builder:<br />
https://autobuilder.yoctoproject.org/main/buildslaves<br />
<br />
* If nothing is running, remove the buildslave from the pool. Please let either Beth or sgw know if you're planning on doing this. Email/IRC is fine.<br />
<br />
Keep in mind that we are currently utilizing two autobuilders. One is just for bugzilla reference (logs and whatnot), the other is production. There have been instances of people not know where the running autobuilder lives.<br />
<br />
The new autobuilder lives in ~/pokybuild/yocto-autobuilder-new. This will eventually change when I EOL the old autobuilder. However, when in doubt about where to find the base dir of the slave, always check the Create BBLayers Configuration step of the build you want. From this you can derive the base dir.<br />
<br />
Example:<br />
<br />
http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101<br />
<br />
Looking at: http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101/steps/CreateAutoConf/logs/stdio shows that we've not moved TMPDIR<br />
<br />
Looking at: http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101/steps/Create%20BBLayers%20Configuration/logs/stdio<br />
<br />
"BBLAYERS += " \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-yocto \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-yocto-bsp \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-qt3 \ <br />
" <br />
<br />
indicates that the layers all exist in the slave's build dir for that build set. Which means that TMPDIR is most likely in:<br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/build/tmp<br />
<br />
<nowiki><br />
sudo -i -u pokybuild<br />
cd yocto-autobuilder-new<br />
. ./yocto-autobuilder-setup<br />
./yocto-stop-autobuilder slave<br />
</nowiki><br />
<br />
This will ensure that the directory you are working in doesn't disappear out from under you. Please make sure that after you are done, you restart:<br />
<br />
<nowiki><br />
sudo -i -u pokybuild<br />
cd yocto-autobuilder-new<br />
. ./yocto-autobuilder-setup<br />
./yocto-start-autobuilder slave<br />
</nowiki><br />
<br />
=====Things to never do=====<br />
* NEVER clean sstate (cleanall, cleansstate). As sstate is shared across builders, you do not want it wiped like this. If you need to toss sstate, let Beth/sgw/RP know. We try not to remove sstate as it speeds up build times dramatically. As it's fairly large and takes a while to wipe, we try to avoid this.<br />
* NEVER stop ab01's master/slave. If you need to debug something on ab01, let sgw, RP and Beth know. As we're the only three who can kick builds off, it's really important they all know so they don't kick off a build and tromp on live debugging. If you need to work on ab01 one of them must know about it *and* have given the ok.<br />
* NEVER create a file as yourself under ~pokybuild/yocto-autobuilder/* This can cause future builds to fail and is frustrating to debug.<br />
* NEVER post links to any Autobuilder log in bug reports. The logs are non-persistent and hence the bug report will eventually end up with a dead link.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BuildLog&diff=15658BuildLog2015-08-31T12:04:53Z<p>Eflanagan: </p>
<hr />
<div>This is a rolling log of builds being run on the autobuilder. The person triggering the build should note here what the expectations of the build are. Anyone following up on that build (such as the SWAT team) should note what they've done about any failures. Ordering is more recent at the top.<br />
<br />
== Nightly 520 ==<br />
<br />
* poky:master-next fired by pidge<br />
* Test mailing list submissions merged into master-next<br />
* Test some bugfixes that went into master<br />
<br />
== Nightly 519 ==<br />
<br />
* master fired by RP<br />
* Test master status after merge of various fixes.<br />
* nightly-arm-lsb segfault looks like [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8060 #8060]<br />
* nightly-arm-lsb error submission failure [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8225 #8225]<br />
* autobuilder current link not set when set to not publish artifacts [https://bugzilla.yoctoproject.org/show_bug.cgi?id=8226 #8226]<br />
* wic issue in nighttly-oe-selftest reported to Ed<br />
* Need to look into second image failure for nightly-mips-lsb (on edgerouter), failed after 2 seconds, no error shown<br />
* Need to look into nightly-mips-lsb sanity test failure (command timeout)<br />
<br />
== Nightly 518 ==<br />
<br />
* master fired by RP<br />
* Try and figure out where we are having merged patches from various places<br />
* failure in nightly-ppc-lsb due to incorrect SRCREV in 3.14 kernel recipe (attempted fix merged)<br />
* failure in nightly-mips-lsb in linux-yocto -3.14 do_patch reported to Bruce, *also* edgerouter issue with compile failure (not reported, need bug)<br />
* failure in nightly-oe-selftest due to dump.py oeqa changes (workaround merged)<br />
* failure in mightly-mips due to random smart test failures (bug needed)<br />
* failure in nightly-x86 due to qemu thread kick issue, bactrace still corrupt but may be decodable using TMPDIR on AB. [RP added notes to 8143 with backtrace info]<br />
<br />
== Nightly 517 ==<br />
<br />
* ross/mut2 fired by Ross<br />
* Patch sweep from oe-core<br />
* Includes Bruce's kernel patches, will break as 515 did<br />
* nightly-arm SDK fail - transient sourceforge fetch failure (change test URL to YP mirror?) (need bug)<br />
* nightly-arm-lsb, nightly-fsl-arm-lsb, nightly-world-lsb, nightly-x86-lsb, nightly-x86_64-lsb - busybox compile failure (Khem's patch?)<br />
* nightly-deb - kernel segfault in sanity test (need bug)<br />
* nightly-mips - smart sanity test issues (need bug)<br />
* nightly-systemd-qa - two different failures, date issue and avahi (same as previous build) (need bug)<br />
* nightly-oe-selftest - two issues, one function parameter change and one from the new test (patch from Mariano and RP likely at fault)<br />
<br />
== Nightly 515 ==<br />
<br />
* ross/mut fired by Ross<br />
* Most of master-next rebased upon ross/for-master (fixes to make master mostly build green) <br />
* Should be green.<br />
* oe-selftest: failed in devtool (fixed in updated mut)<br />
* mips-lsb, x86-lsb: kernel sanity test fails<br />
* mips-lsb: specific kernel build failed (#8224, master also)<br />
* ppc-lsb: kernel 3.14 fetch fail<br />
* multilib: sanity test failed (#8219, fixed in updated mut)<br />
* systemd: qemu_cpu_kick_thread (#8143)<br />
* '''Conclusion''': drop kernel patches, merged updated ross/mut (not mut2)<br />
<br />
==Nightly 505 ==<br />
<br />
* ross/mut-next, experimental sweep of patches from the list<br />
* BOOM<br />
<br />
==Nightly 503 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/503<br />
* Lucky five hundred and three!<br />
* Triggered by Ross (ross/mut)<br />
* <s>Build 500 plus a LSB test suite fix, should be 100% green</s><br />
* Aborted!<br />
<br />
==Nightly 500 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/500<br />
* Lucky five hundred?<br />
* Triggered by Ross (ross/qemu)<br />
* Just master plus Anibal's qemu poll patch<br />
<br />
==Nightly 499 ==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/499<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Including Randy's qemu fix!<br />
* Won't force push this time, should build 100% green<br />
<br />
==Nightly 497==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/497<br />
* Triggered by Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* Many failures due to a force push during build (8195 8196)<br />
<br />
==Nightly 492==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/492<br />
* Triggered by Beth for Ross (ross/mut)<br />
* Test of patches from mailing list<br />
* SWAT: Needs bugs for lsb test image failures and systemd failure (mention on related bug)<br />
<br />
==Nightly 489==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/489<br />
* Triggered by Beth for RP (master-next)<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
* SWAT: Need bug for weston failure in nightly-world (https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/450/steps/BuildImages/logs/stdio)<br />
* SWAT: Need bug for qemuarm hang with gcc 5.x (if not one already, assign to Bruce Ashfield)<br />
<br />
==Nightly 483==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/483<br />
* Triggered by RP<br />
* Test of gcc 5.x, also keep AB loaded to try and reproduce 'random' failures with new logging<br />
<br />
==Nightly 482==<br />
<br />
* Incorrectly setup, immediate abort<br />
<br />
==Nightly 481==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/481<br />
* Triggered by RP<br />
* upgrades and other improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Successful - merged to master<br />
<br />
==Nightly 480==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/480<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* Aborted by RP due to boot issues, suspect nfs-utils<br />
<br />
==Nightly 479==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/479<br />
* Triggered by RP<br />
* upgrades and qemu improvements to test their status<br />
* includes test of glibc upgrade which may have issues<br />
* do_rootfs failures from rpm/db upgrade, aborted build due to this<br />
<br />
==Nightly 478==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/478<br />
* Triggered by RP for Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
* Successful - merged to master<br />
<br />
==Nightly 477==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/477<br />
* Triggered by Ross<br />
* master plus "safe" upgrades and qemu improvements<br />
<br />
==Nightly 475==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/475<br />
* Triggered by Ross<br />
* 473 without openssh, should build green.<br />
* Include the qemu_cpu_kick_thread debugging<br />
<br />
==Nightly 473==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/473<br />
* Triggered by Ross<br />
* 472 without the ext4 patches to determine if they broke sanity<br />
<br />
==Nightly 472==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/472<br />
* Triggered by Ross<br />
* Mainly to test glibc 2.22<br />
<br />
==Nightly 471==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/471<br />
* Triggered by Ross<br />
* Mostly patches from oe-core list, lots of upgrades.<br />
<br />
==Nightly 469==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/469<br />
* master build destined to become 1.9M2.rc2.<br />
* has fixes for pam issue, fedora22 runqemu issues, weston parallel make race<br />
<br />
==Nightly 468==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/468<br />
* master-next triggered by RP to test fix for fedora22 runqemu issues<br />
<br />
<br />
==Nightly 467==<br />
<br />
* https://autobuilder.yoctoproject.org/main/builders/nightly/builds/467<br />
* master-next triggered by RP to test incoming changes from mailing list<br />
* SWAT Status: All issues show were not due to master-next and therefore bugs need to be filed.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Distro_Tracking&diff=14481Distro Tracking2015-04-16T12:37:24Z<p>Eflanagan: /* More information for using the DISTRO_PN_ALIAS variable */</p>
<hr />
<div>= Motivation =<br />
<br />
The Distro Tracking Fields (meta/conf/distro/include/distro_tracking_fields.inc) is a<br />
location for sharing information about the status of recipes and tracking version information.<br />
Not all of this information can be generated automatically (yet), so the manual editing is needed.<br />
<br />
== Package Tracking Website ==<br />
<br />
The Yocto Project hosts a package tracking website, that show information about the version and maintainership.<br />
The webpage can be found at http://packages.yoctoproject.org<br />
<br />
== Package Tracking Process ==<br />
<br />
If we want to track the recipes latest status and do some upgrade work, below is the guideline. <br />
* Visit Packages Report System to get upgrade and manual check list.<br />
Visit http://packages.yoctoproject.org, check the Upgrade Packages List and Manual Check Packages List, find out how many recipes you need to upgrade or manual check.<br />
<br />
* Upgrade recipes<br />
Please refer to: Best Known Methods(BKMS) for Package Updating<br />
https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs)_for_Package_Updating<br />
<br />
* Update distro_tracking_fields.inc<br />
For the explanation about fields in distro_tracking_fields.inc, please refer to https://wiki.yoctoproject.org/wiki/Distro_Tracking#Distro_Tracking_Fields<br />
<br />
There are two fields in the distro_tracking_fields.inc, one field is RECIPE_MANUAL_CHECK_DATE, and this is for those recipes which can't be checked upstream version automatically, if you checked the upstream version manually, please update it. <br />
<br />
Another field is RECIPE_LAST_UPDATE, this field record your last upgrade time, you need to update this field after you upgrade the recipe.<br />
<br />
It means that if you upgrade one recipe which on the Manual Check Packages List, you need to update those two fields at the same time.<br />
<br />
When you decide not to upgrade one recipe, for the "git" type, please fill in the "RECIPE_NO_UPDATE_REASON " with first previous eight number, for other types, please fill in that field with the latest version you don't want to upgrade to. The report system will remove the recipe from the "need to upgrade packages" list if he detects the commit number or the latest version has existed in the "RECIPE_NO_UPDATE_REASON ".<br />
<br />
= Distro Tracking Fields =<br />
<br />
The file meta/conf/distro/include/distro_tracking_fields.inc exists to allow us to track various pieces of information about recipes and upstream versions (e.g, recipe maintainer contact information, date of latest upstream release, alternate names used for this recipe in other Linux distros, etc). We keep the metadata via [[#BitBake_Overides|BitBake Overrides]]. The following defines the meaning of each field:<br />
<br />
;RECIPE_STATUS<br />
: Indicates whether the recipe has been reviewed for basic quality control information (e.g, has had its software license verified). "red" indicates these checks have not been done, and "green" indicates that they have been done.<br />
;RECIPE_DEPENDENCY_CHECK<br />
: Indicates whether the recipe has been built from scratch to verify that all of its build and runtime dependencies have been specified. Value is either "not done" or "done"<br />
;RECIPE_LATEST_VERSION<br />
: The latest upstream stable version, "3.0"<br />
;RECIPE_MANUAL_CHECK_DATE<br />
: This is the date of the last manual check for those packages that can not be checked automatically Date format is "Dec 10, 2010"<br />
;RECIPE_NO_UPDATE_REASON<br />
: An explaination as to why a recipe has not been updated to latest version, for example non stable or development version.<br />
;RECIPE_NO_OF_PATCHES<br />
: The number of patches we ship with the recipe.<br />
;RECIPE_PATCH<br />
: Summarizes the purpose of each patch associated with a recipe.<br />
;RECIPE_LATEST_RELEASE_DATE<br />
: The date at which the latest upstream stable version (mentioned in RECIPE_LATEST_VERSION) was released, "03/2010"<br />
;RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES<br />
: The amount of time which passed between the most recent two upstream stable releases, "2 months"<br />
;RECIPE_COMMENTS<br />
: A field to mention comments, such as why a recipe can't be brought up to the latest upstream release, or unusual build issues that need to be worked around.<br />
;RECIPE_LAST_UPDATE<br />
: Date of the last changes to the recipe, "Dec 10, 2010"<br />
;RECIPE_MAINTAINER<br />
: Name and email address of the person maintaining the recipe, "Firstname Lastname <email.address>"<br />
;RECIPE_DISTRO_PN_ALIAS<br />
: See below for mre details<br />
<br />
==== More information for using the DISTRO_PN_ALIAS variable ====<br />
* Configuring the DISTRO_PN_ALIAS variable<br />
Sometimes the names of the same packages are different in different linux distributions; and that<br />
can becomes an issue for the distro_check task to check if the given recipe package exists in other<br />
linux distros. This issue is avoided by defining per distro recipe name alias: DISTRO_PN_ALIAS<br />
* Specifying the DISTRO_PN_ALIAS variable<br />
DISTRO_PN_ALIAS_pn-xset = "Fedora=xorg-x11-server-utils Ubuntu=x11-xserver-utils Debian=x11-xserver-utils Opensuse=xorg-x11"<br />
Note that 'space' is used as delimiter here<br />
* Tip<br />
The current code can check if the src package for a recipe exists in the latest releases of<br />
these distributions automatically: Fedora, OpenSuSE, Debian, Ubuntu, Mandrina<br />
<br />
For example, this command will generate a report, listing which linux distros include the<br />
sources for each of the poky recipe. <br />
<br />
bitbake world -f -c distro_check<br />
<br />
Note. You should have the following in your local.conf (or auto.conf):<br />
<br />
include conf/distro/include/distro_alias.inc<br />
include conf/distro/include/recipe_color.inc<br />
include conf/distro/include/maintainers.inc<br />
include conf/distro/include/upstream_tracking.inc <br />
include conf/distro/include/package_regex.inc <br />
INHERIT+= "distrodata"<br />
<br />
The results will be stored in the build/tmp/log/distro_check-${DATETIME}.results file.<br />
<br />
==== Other Distribution Package Search Tools ====<br />
<br />
;Debian<br />
: http://www.debian.org/distrib/packages<br />
;Fedora<br />
: https://admin.fedoraproject.org/pkgdb<br />
;Ubuntu<br />
: http://packages.ubuntu.com<br />
;OpenSUSE<br />
: http://packages.opensuse-community.org/<br />
; RedHat:<br />
: http://www.rpmfind.net/linux/RPM/<br />
<br />
=== BitBake Overrides ===<br />
We will create a set of BitBake Overides for DEPENDENCY_CHECK and RECIPE_STATUS with defaults of "not done" and as recipes are checked the appropriate file will be updated to contain the status, these files will then be used to generate the spreadsheet / progress report so we know where we stand.<br />
<br />
There're also additional overrides we'd like to track for project progress:<br />
* RECIPE_LATEST_VERSION_pn+<packagename>="x.y.z"; Override for missing or inaccurate version information from kevin’s script<br />
* RECIPE_PATCH_pn+<packagename>+<patchname>="description/status"; Description about a patch's purpose and its status whether necessary to keep<br />
* RECIPE_COMMENTS_pn+<packagename>="comments"; Contain micellaneous useful information about the package<br />
* RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn+<packagename>="5 months"; Activity tracking information<br />
* RECIPE_LATEST_RELEASE_DATE_pn+<packagename>="2010/03/03"; Last release date<br />
* RECIPE_INTEL_SECTION_pn="base"; section info defined by distro team, which may replace current SECTION later</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Distro_Tracking&diff=14480Distro Tracking2015-04-16T12:37:07Z<p>Eflanagan: /* More information for using the DISTRO_PN_ALIAS variable */</p>
<hr />
<div>= Motivation =<br />
<br />
The Distro Tracking Fields (meta/conf/distro/include/distro_tracking_fields.inc) is a<br />
location for sharing information about the status of recipes and tracking version information.<br />
Not all of this information can be generated automatically (yet), so the manual editing is needed.<br />
<br />
== Package Tracking Website ==<br />
<br />
The Yocto Project hosts a package tracking website, that show information about the version and maintainership.<br />
The webpage can be found at http://packages.yoctoproject.org<br />
<br />
== Package Tracking Process ==<br />
<br />
If we want to track the recipes latest status and do some upgrade work, below is the guideline. <br />
* Visit Packages Report System to get upgrade and manual check list.<br />
Visit http://packages.yoctoproject.org, check the Upgrade Packages List and Manual Check Packages List, find out how many recipes you need to upgrade or manual check.<br />
<br />
* Upgrade recipes<br />
Please refer to: Best Known Methods(BKMS) for Package Updating<br />
https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs)_for_Package_Updating<br />
<br />
* Update distro_tracking_fields.inc<br />
For the explanation about fields in distro_tracking_fields.inc, please refer to https://wiki.yoctoproject.org/wiki/Distro_Tracking#Distro_Tracking_Fields<br />
<br />
There are two fields in the distro_tracking_fields.inc, one field is RECIPE_MANUAL_CHECK_DATE, and this is for those recipes which can't be checked upstream version automatically, if you checked the upstream version manually, please update it. <br />
<br />
Another field is RECIPE_LAST_UPDATE, this field record your last upgrade time, you need to update this field after you upgrade the recipe.<br />
<br />
It means that if you upgrade one recipe which on the Manual Check Packages List, you need to update those two fields at the same time.<br />
<br />
When you decide not to upgrade one recipe, for the "git" type, please fill in the "RECIPE_NO_UPDATE_REASON " with first previous eight number, for other types, please fill in that field with the latest version you don't want to upgrade to. The report system will remove the recipe from the "need to upgrade packages" list if he detects the commit number or the latest version has existed in the "RECIPE_NO_UPDATE_REASON ".<br />
<br />
= Distro Tracking Fields =<br />
<br />
The file meta/conf/distro/include/distro_tracking_fields.inc exists to allow us to track various pieces of information about recipes and upstream versions (e.g, recipe maintainer contact information, date of latest upstream release, alternate names used for this recipe in other Linux distros, etc). We keep the metadata via [[#BitBake_Overides|BitBake Overrides]]. The following defines the meaning of each field:<br />
<br />
;RECIPE_STATUS<br />
: Indicates whether the recipe has been reviewed for basic quality control information (e.g, has had its software license verified). "red" indicates these checks have not been done, and "green" indicates that they have been done.<br />
;RECIPE_DEPENDENCY_CHECK<br />
: Indicates whether the recipe has been built from scratch to verify that all of its build and runtime dependencies have been specified. Value is either "not done" or "done"<br />
;RECIPE_LATEST_VERSION<br />
: The latest upstream stable version, "3.0"<br />
;RECIPE_MANUAL_CHECK_DATE<br />
: This is the date of the last manual check for those packages that can not be checked automatically Date format is "Dec 10, 2010"<br />
;RECIPE_NO_UPDATE_REASON<br />
: An explaination as to why a recipe has not been updated to latest version, for example non stable or development version.<br />
;RECIPE_NO_OF_PATCHES<br />
: The number of patches we ship with the recipe.<br />
;RECIPE_PATCH<br />
: Summarizes the purpose of each patch associated with a recipe.<br />
;RECIPE_LATEST_RELEASE_DATE<br />
: The date at which the latest upstream stable version (mentioned in RECIPE_LATEST_VERSION) was released, "03/2010"<br />
;RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES<br />
: The amount of time which passed between the most recent two upstream stable releases, "2 months"<br />
;RECIPE_COMMENTS<br />
: A field to mention comments, such as why a recipe can't be brought up to the latest upstream release, or unusual build issues that need to be worked around.<br />
;RECIPE_LAST_UPDATE<br />
: Date of the last changes to the recipe, "Dec 10, 2010"<br />
;RECIPE_MAINTAINER<br />
: Name and email address of the person maintaining the recipe, "Firstname Lastname <email.address>"<br />
;RECIPE_DISTRO_PN_ALIAS<br />
: See below for mre details<br />
<br />
==== More information for using the DISTRO_PN_ALIAS variable ====<br />
* Configuring the DISTRO_PN_ALIAS variable<br />
Sometimes the names of the same packages are different in different linux distributions; and that<br />
can becomes an issue for the distro_check task to check if the given recipe package exists in other<br />
linux distros. This issue is avoided by defining per distro recipe name alias: DISTRO_PN_ALIAS<br />
* Specifying the DISTRO_PN_ALIAS variable<br />
DISTRO_PN_ALIAS_pn-xset = "Fedora=xorg-x11-server-utils Ubuntu=x11-xserver-utils Debian=x11-xserver-utils Opensuse=xorg-x11"<br />
Note that 'space' is used as delimiter here<br />
* Tip<br />
The current code can check if the src package for a recipe exists in the latest releases of<br />
these distributions automatically: Fedora, OpenSuSE, Debian, Ubuntu, Mandrina<br />
<br />
For example, this command will generate a report, listing which linux distros include the<br />
sources for each of the poky recipe. <br />
<br />
bitbake world -f -c distro_check<br />
<br />
Note. You should have the following in your local.conf (or auto.conf):<br />
<br />
include conf/distro/include/distro_alias.inc<br />
include conf/distro/include/recipe_color.inc<br />
include conf/distro/include/maintainers.inc<br />
include conf/distro/include/upstream_tracking.inc <br />
include conf/distro/include/package_regex.inc <br />
INHERIT+= "distrodata"<br />
<br />
The results will be stored in the build/tmp/log/distro_check-${DATETIME}.results file.<br />
<br />
==== Other Distribution Package Search Tools ====<br />
<br />
;Debian<br />
: http://www.debian.org/distrib/packages<br />
;Fedora<br />
: https://admin.fedoraproject.org/pkgdb<br />
;Ubuntu<br />
: http://packages.ubuntu.com<br />
;OpenSUSE<br />
: http://packages.opensuse-community.org/<br />
; RedHat:<br />
: http://www.rpmfind.net/linux/RPM/<br />
<br />
=== BitBake Overrides ===<br />
We will create a set of BitBake Overides for DEPENDENCY_CHECK and RECIPE_STATUS with defaults of "not done" and as recipes are checked the appropriate file will be updated to contain the status, these files will then be used to generate the spreadsheet / progress report so we know where we stand.<br />
<br />
There're also additional overrides we'd like to track for project progress:<br />
* RECIPE_LATEST_VERSION_pn+<packagename>="x.y.z"; Override for missing or inaccurate version information from kevin’s script<br />
* RECIPE_PATCH_pn+<packagename>+<patchname>="description/status"; Description about a patch's purpose and its status whether necessary to keep<br />
* RECIPE_COMMENTS_pn+<packagename>="comments"; Contain micellaneous useful information about the package<br />
* RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn+<packagename>="5 months"; Activity tracking information<br />
* RECIPE_LATEST_RELEASE_DATE_pn+<packagename>="2010/03/03"; Last release date<br />
* RECIPE_INTEL_SECTION_pn="base"; section info defined by distro team, which may replace current SECTION later</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Build_Failure_Swat_Team&diff=14400Yocto Build Failure Swat Team2015-04-07T15:40:37Z<p>Eflanagan: /* Scope of Responsibility */</p>
<hr />
<div>==Overview==<br />
<br />
The assembly of the Yocto Project SWAT team is mainly to tackle urgent technical problems that break build on the master branch or major release branches in a timely manner, thus to maintain the stability of the master and release branch. The SWAT team includes volunteers or appointed members of the Yocto Project team. Community members can also volunteer to be part of the SWAT team.<br />
<br />
==Scope of Responsibility==<br />
<br />
Whenever a build (nightly build, weekly build, release build) fails, the SWAT team is responsible for ensuring the necessary debugging occurs and organizing resources to solve the issue and ensure successful builds. If resolving the issues requires schedule or resource adjustment, the SWAT team should work with program and development management to accommodate the change in the overall planning. If resolving the issues requires access to the autobuilder, please contact either [[User:Eflangan| Beth Flanagan]] or [[User:Mhalstead| Michael Halstead]] for access rights.<br />
<br />
In general, priority should always go first towards major release candidates and secondly to master failures. <br />
<br />
Point releases (yocto-1.X.x) should have minimal problems in the first place. As well, stable branch maintainers should be paying attention to their own point release candidate builds.<br />
<br />
Build failures are reported on the [https://lists.yoctoproject.org/listinfo/yocto-builds yocto-build mailing list].<br />
<br />
Please review the [[Media:Swat.odp]] presentation.<br />
<br />
==Members==<br />
<br />
* Elizabeth Flanagan (US) (Autobuilder Maintainer)<br />
* Saul Wold (US) (Autobuilder Administrator)<br />
* Paul Eggleton (UK)<br />
* Ross Burton (UK)<br />
* Cristian Iorga (RO)<br />
* Randy Witt (US)<br />
* Benjamin Esquivel (MX)<br />
* Juro Bystricky (US)<br />
* Anibal Limon (MX)<br />
* Tracy Graydon (US)<br />
* Alejandro Hermandez (MX)<br />
<br />
==Chair==<br />
A chairperson role will be rotated among team members each other week. The Chairperson should monitor the build status for the entire two weeks. Whenever a build is broken, the Chairperson should do necessary debugging and organize resources to solve the problems in a timely manner to meet the overall project and release schedule. The Chairperson serves as the focal point of the SWAT team to external people such as program managers or development managers.<br />
<br />
==Rotation Process==<br />
The Chairperson rotation takes place during the bi-weekly technical project meeting (Every other Tuesday at 8:00 AM PT). Usually, this will take a simple round robin order. In case the next person cannot take the role due to tight schedule, vacation or some other reasons, the role will be passed to the next person.<br />
<br />
==Debugging BKMs==<br />
<br />
When looking at a failure, the first question is what the baseline was and what changed. If there were recent known good builds it helps to narrow down the number of changes that were likely responsible for the failure. It's also useful to note if the build was from scratch or from existing sstate files. You can tell by seeing what "setscene" tasks run in the log.<br />
<br />
The primary responsibility is to ensure that any failures are categorized correctly and that the right people get to know about them.<br />
<br />
It's important *someone* is then tasked with fixing it. Image failures are particular tricky since its likely some component of the image that failed and the question is then whether that component changed recently, whether it was some kind of core functionality at fault and so on.<br />
<br />
Ideally we want to get the failure reported to the person who knows something about the area and can come up with a fix without it distracting them too much.<br />
As a secondary responsibility, it's often helpful to triage the failure. This might mean documenting a way to reproduce the failure outside a full build and/or documenting how the failure is happening and maybe even propose a fix.<br />
<br />
To fulfill the primary responsibility, it's suggested that bugs are opened on the bugzilla for each type of failure. This way, appropriate people can be brought into the discussion and a specific owner of the failure can be assigned. Replying to the build failure with the bug ID and also bringing the bug to the attention of anyone you suspect was responsible for the problem are also good practices.<br />
<br />
When filing the bug, please cut and paste the relevant error in the bug comment, and include the log file as an attachement. This ensures the assignee and triage team can quickly asses this issue.<br />
<br />
Every build failure should be responded to. If it is a known issue, a response with a single line containing "Known Issue" is sufficient. This assures others that the failure has been looked at and is being worked on.<br />
<br />
==Autobuilder BKMs==<br />
<br />
Sometimes failures are difficult to understand and can require direct ssh access to the autobuilder so the issue can be debugged passively on the system to examine contents of files and so forth. If doing this ensure you don't change any of the file system for example adding files that couldn't then be deleted by the autobuilder when it rebuilds.<br />
<br />
Rarely, "live" debugging might be needed where you'd su to the pokybuild user and run a build manually to see the failure in real time. If doing this, ensure you only create files as the pokybuild user and you are careful not to generate sstate packages which shouldn't be present or any other bad state that might get reused. In general its recommended not to do "live" debugging. This can be escalated to RP/Saul/Beth if needed.<br />
<br />
Live debugging is generally something we try to avoid doing. It should only occur if an issue can only be reproduced on the autobuilder.<br />
<br />
===Autobuilder Overview===<br />
<br />
====Infrastructure Overview====<br />
ab01: The yocto master autobuilder. This runs one low utility slave which does, universe fetch, package index, bitbake self test, builds the adt-installer and generally acts as the release mechanism for the Yocto Project. It also acts as a trigger parent for our full nightly build. This nightly build is essentially what builds our release, minus release notes.<br />
<br />
ab02, ab04, ab05, ab06, ab10: Generic nightly slaves. These run three slaves a piece. ab10 also runs our eclipse plugin build<br />
<br />
====Build Targets====<br />
Nightly is a "dummy" buildset that does relatively few things and is only ever run on ab01. It mainly does universe fetch, building<br />
adt-installer and building the eclipse plugin. It's main function is to trigger nightly-${ARCH} and wait until they're done. ab02, ab04,<br />
ab05, ab06 are what is used to run this pool of nightly arch builds. <br />
<br />
NOTE: Just because nightly-* ran on ab04 the last time does not mean it will again. It's semi random. In order to find out what host you need to log into, please look for the buildstep that says:<br />
<br />
Building on<br />
autobuilder04<br />
Linux autobuilder04 2.6.37.6-0.9-default #1 SMP 2011-10-19 22:33:27<br />
+0200 x86_64 x86_64 x86_64 GNU/Linux<br />
<br />
====Build "gotchas"====<br />
Currently, we share sstate-cache and downloads between these slaves via NAS. For the moment we are also splitting up sstate and lsb-sstate. They are currently stored in /srv/www/vhosts/autobuilder.yoctoproject.org/pub/[sstate|lsb-sstate]. This will change after M2 to be combined into one directory; /srv/www/vhosts/autobuilder.yoctoproject.org/pub/sstate<br />
<br />
TMPDIR between distros (poky and poky-lsb) is not shared. $TMPDIR ends up being moved to ~pokybuild/yocto-autobuilder/yocto-slave/nightly-${ARCH}/build/build/nonlsb-tmp and poky-lsb is left in the above path's tmp. <br />
<br />
<br />
====Live Debugging Process====<br />
If you need to do live debugging on the autobuilder, you want to:<br />
<br />
* Check that nothing is running on the builder:<br />
http://autobuilder.yoctoproject.org:8010/buildslaves<br />
<br />
* If nothing is running, remove the buildslave from the pool. Please let either Beth or sgw know if you're planning on doing this. Email/IRC is fine.<br />
<br />
Keep in mind that we are currently utilizing two autobuilders. One is just for bugzilla reference (logs and whatnot), the other is production. There have been instances of people not know where the running autobuilder lives.<br />
<br />
The new autobuilder lives in ~/pokybuild/yocto-autobuilder-new. This will eventually change when I EOL the old autobuilder. However, when in doubt about where to find the base dir of the slave, always check the Create BBLayers Configuration step of the build you want. From this you can derive the base dir.<br />
<br />
Example:<br />
<br />
http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101<br />
<br />
Looking at: http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101/steps/CreateAutoConf/logs/stdio shows that we've not moved TMPDIR<br />
<br />
Looking at: http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/101/steps/Create%20BBLayers%20Configuration/logs/stdio<br />
<br />
"BBLAYERS += " \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-yocto \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-yocto-bsp \ <br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/meta-qt3 \ <br />
" <br />
<br />
indicates that the layers all exist in the slave's build dir for that build set. Which means that TMPDIR is most likely in:<br />
/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly/build/build/tmp<br />
<br />
<nowiki><br />
sudo -i -u pokybuild<br />
cd yocto-autobuilder-new<br />
. ./yocto-autobuilder-setup<br />
./yocto-stop-autobuilder slave<br />
</nowiki><br />
<br />
This will ensure that the directory you are working in doesn't disappear out from under you. Please make sure that after you are done, you restart:<br />
<br />
<nowiki><br />
sudo -i -u pokybuild<br />
cd yocto-autobuilder-new<br />
. ./yocto-autobuilder-setup<br />
./yocto-start-autobuilder slave<br />
</nowiki><br />
<br />
=====Things to never do=====<br />
* NEVER clean sstate (cleanall, cleansstate). As sstate is shared across builders, you do not want it wiped like this. If you need to toss sstate, let Beth/sgw/RP know. We try not to remove sstate as it speeds up build times dramatically. As it's fairly large and takes a while to wipe, we try to avoid this.<br />
* NEVER stop ab01's master/slave. If you need to debug something on ab01, let sgw, RP and Beth know. As we're the only three who can kick builds off, it's really important they all know so they don't kick off a build and tromp on live debugging. If you need to work on ab01 one of them must know about it *and* have given the ok.<br />
* NEVER create a file as yourself under ~pokybuild/yocto-autobuilder/* This can cause future builds to fail and is frustrating to debug.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Checklist&diff=14362Yocto Project Release Checklist2015-03-31T22:46:51Z<p>Eflanagan: </p>
<hr />
<div>Major Release <br />
<br />
- Week prior to build of release candidate<br />
- Updates to the following packages will have occurred. DO NO PANIC, these come late in the release cycle<br />
- wic <br />
- meta-yocto-bsp <br />
- meta-yocto<br />
- linux-firmware <br />
- bootloaders (grub, syslinux, u-boot, gummiboot, etc..) <br />
- hwdata <br />
- pciutils <br />
- util-linux <br />
- i2c-tools <br />
- alsa <br />
- graphics drivers <br />
- cryptodev <br />
- systemtap<br />
- perf<br />
- linux-yocto<br />
<br />
- Prior to build of the first release candidate<br />
- Is DISTRO_VERSION updated in poky.conf?<br />
- Is SDK_VERSION updated in poky.conf?<br />
- Is SANITY_TESTED_DISTROS updated in poky.conf?<br />
- Are yocto-docs merged to the release branch?<br />
- Has bitbake -f -c distrodata universe been run?<br />
- Has an updated distro_alias.inc patch been accepted?<br />
<br />
- After the final release candidate has returned from QA and is approved<br />
- Have we checked and updated all tarballs if needed using consistent naming conventions?<br />
- Have we removed rpm and deb directories?<br />
- Have we cleaned up image directories and removed duplicate entries?<br />
- Have we moved eclipse archives to their proper spots?<br />
- Have we published the ADT?<br />
- Have we produced an md5sum file for the entire build?<br />
- Have we begun the mirror sync 5 days prior to release?<br />
- Have we checked that the mirror sync is working?<br />
- Have we created release notes?<br />
- Does it have a link to the QA tests?<br />
- Have we tagged the needed repos?<br />
- Have we inserted the easter egg?<br />
- Have we packaged the bsps?<br />
- Have we put them up on the yoctoproject.org website?<br />
- Have we tested their downloads?<br />
- Have we verified the README for each release on the website?<br />
- Have we sent out the release email?</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=14031Yocto Project Release Process2015-01-16T14:52:30Z<p>Eflanagan: /* Release of Build */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, we generate a release candidate from master. After each release candidate has cleared QA, the branch is tagged (M.m_M1).<br />
<br />
The milestone is copied to the release area preserving links and then cleaned up. We remove rpm/deb directories and then remove .gz files in machines (except for p1022), bz2 files (except for p1022) and then all ext3 files for everything except qemu machines.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Release Process for the Yocto Project ====<br />
<br />
===== Prior to last milestone =====<br />
* Release Engineer gets release name from Richard Purdie and announces it via yocto@yoctoproject.org<br />
* Release Engineer informs Documentation of the new release names so that they have time to modify documentation<br />
<br />
===== Last milestone =====<br />
During the last milestone we generally will build from master and then branch when things are at the point where they're mostly stable. We do this to reduce the amount of work required to maintain two branches. Once we're seeing good daily builds and feel confident enough to branch, we will branch the poky, meta-qt3 and eclipse repos to a branch named after the name of the release (dora, dylan, laverne, etc).<br />
<br />
===== Prior to release build ===== <br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers.<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Release of Build =====<br />
* Copy the build from the autobuilder directory to the main release directory ( cp http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable)<br />
* For final release, copy the DL_DIR to yocto_M.m/sources<br />
* We remove rpm/deb directories and then remove .gz files in machines (except for p1022), bz2 files (except for p1022) and then all ext3 files for everything except qemu machines.<br />
* Rename tarballs if necessary, including top level directories to comply with documentation. For example. poky-<githash>.tar.bz2 should be renamed to poky-<release_name>-<release_number>.tar.bz2 and the top lever directory renamed accordingly.<br />
* Rename BSP tarballs if necessary, as above.<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* Copy the adt-dev repo to the live site<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Publish BSPs to the webpage.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
* Update DISTRO and DISTRO_VERSION in master to be the main release+snapshot<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
* Does the adt-repo work</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=14030Yocto Project Release Process2015-01-16T14:51:55Z<p>Eflanagan: /* Milestone Releases */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, we generate a release candidate from master. After each release candidate has cleared QA, the branch is tagged (M.m_M1).<br />
<br />
The milestone is copied to the release area preserving links and then cleaned up. We remove rpm/deb directories and then remove .gz files in machines (except for p1022), bz2 files (except for p1022) and then all ext3 files for everything except qemu machines.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Release Process for the Yocto Project ====<br />
<br />
===== Prior to last milestone =====<br />
* Release Engineer gets release name from Richard Purdie and announces it via yocto@yoctoproject.org<br />
* Release Engineer informs Documentation of the new release names so that they have time to modify documentation<br />
<br />
===== Last milestone =====<br />
During the last milestone we generally will build from master and then branch when things are at the point where they're mostly stable. We do this to reduce the amount of work required to maintain two branches. Once we're seeing good daily builds and feel confident enough to branch, we will branch the poky, meta-qt3 and eclipse repos to a branch named after the name of the release (dora, dylan, laverne, etc).<br />
<br />
===== Prior to release build ===== <br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers.<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Release of Build =====<br />
* Copy the build from the autobuilder directory to the main release directory ( cp http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable)<br />
* For final release, copy the DL_DIR to yocto_M.m/sources<br />
* Rename tarballs if necessary, including top level directories to comply with documentation. For example. poky-<githash>.tar.bz2 should be renamed to poky-<release_name>-<release_number>.tar.bz2 and the top lever directory renamed accordingly.<br />
* Rename BSP tarballs if necessary, as above.<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* Copy the adt-dev repo to the live site<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Publish BSPs to the webpage.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
* Update DISTRO and DISTRO_VERSION in master to be the main release+snapshot<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
* Does the adt-repo work</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Tagging_Conventions&diff=13173Yocto Project Tagging Conventions2014-07-15T17:26:06Z<p>Eflanagan: /* Yocto Project Tagging Conventions */</p>
<hr />
<div><br />
=== Yocto Project Tags ===<br />
<br />
In order to understand the tagging used within the Yocto Project, it is important to note what we release. We can break up our releases into three types. Major, minor, milestone. For each of these we release both the Yocto Project as well as the reference distribution, "poky", that we built with this version of the Yocto Project's build system.<br />
<br />
During Milestone releases, we utilize the milestone naming convention to denote both poky and Yocto Project milestone releases. So, for example, during 1.4's milestone 4 release, we would use 1.4_M4.<br />
<br />
Once we've branched to a major or minor named release branch, we no longer use the milestone name. We denote yocto releases and poky releases with different tags. There is no technical reason for this, it is merely for convenience. Some people are more familiar with Yocto release names over poky release names<br />
<br />
=== Yocto Project Tagging Conventions ===<br />
<br />
In general, we utilize 3 main types of tags in the main Yocto Project repositories:<br />
<br />
Milestone Tags:<br />
M.m_M<milestone number><br />
1.4_M2<br />
<br />
Poky Tags:<br />
<name>-M.m.p<br />
dora-10.0.0<br />
<br />
Yocto Project Tags:<br />
yocto-M.m<br />
yocto-1.5<br />
<br />
We also have a few prefixes that we've utilized for tags in the past:<br />
<br />
* release candidate<br />
Used to denote a release candidate<br />
yocto-1.5_M5.rc1<br />
dora-10.0.0.rc8<br />
<br />
* final release<br />
Used to denote "final". Because we are aggressive in our release schedule, and because we do not delete tags, we utilize .final to denote the final version of a major and point releases.Most times, the .final tag will match up with the <name>-M.m.p tag. But we utilize .final when we sometimes have to slip a few changes into the release before it goes it. This is especially useful for documentation.<br />
<br />
dora-10.0.0.final<br />
<br />
When in doubt, always utilize the .final tag.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP_for_Release&diff=13075BKM: Packaging a BSP for Release2014-07-01T22:42:17Z<p>Eflanagan: /* Packaging a BSP for Release */</p>
<hr />
<div>== Packaging a BSP for Release ==<br />
<br />
This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]<br />
<br />
=== General Guidelines ===<br />
<br />
* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP<br />
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.<br />
* A BSP tarball should contain a MAINTAINERS and a README file<br />
* A BSP tarball should contain licensing information<br />
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core<br />
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.<br />
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.<br />
<br />
=== Example structure ===<br />
<br />
For our example, we will utilize the meta-intel BSP, meta-fri2.<br />
<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-chiefriver<br />
d--------- meta-crownbay<br />
d--------- meta-crystalforest<br />
d--------- meta-emenlow<br />
d--------- meta-fri2<br />
d--------- meta-isg<br />
d--------- meta-jasperforest<br />
d--------- meta-n450<br />
d--------- meta-nuc<br />
d--------- meta-romley<br />
d--------- meta-sugarbay<br />
d--------- meta-sys940x<br />
d--------- meta-tlk<br />
</nowiki><br />
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories. <br />
<br />
For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- binary<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
Next, we will add a binary directory. This should contain the images needed to get hardware to boot.<br />
<br />
We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.<br />
<br />
The naming convention for the tarball is:<br />
<br />
<name of bsp>-<name of release it was built against>-M.m.p<br />
<br />
We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.<br />
<br />
=== Addendum on why to include or not to include poky/oe-core ===<br />
<br />
There are a few very good reasons why you would not want to include poky with your BSP, as well a some good ones as to why. Previously, organizations released with poky at the root directory and their BSP included in the directory.<br />
<br />
We initially suggested including poky with the BSP releases for two major reasons. GPL compliance and ease of use for the end user. The general consensus now, is that this is generally something we want to avoid.<br />
<br />
While a single checkout BSP may make things a bit easier for the end user, it can lead to the end user not being up to date with poky and thus releasing against an old poky release which may include unresolved CVEs. Also a BSP should always be able to build against the HEAD of the branch it was originally released against. For example, a BSP released and built against the yocto-1.5 "dora" release should always be able to build against future revisions of yocto-1.5. By releasing a BSP with a pegged version of poky, the end user can get confused as to this concept.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Third_Party_BSP_Release_Process&diff=13074Third Party BSP Release Process2014-07-01T22:15:23Z<p>Eflanagan: /* Overview */</p>
<hr />
<div>==Overview==<br />
<br />
Third Party BSPs may be released with any major/minor Yocto release by the maintainers of the various BSP layers. The process for including a BSP release into a yocto release has a few routes, some less complicated than others.<br />
<br />
===Release Requirements===<br />
* If your DL_DIR contains source which we are required to provide and that source package/revision does not exist at http://downloads.yoctoproject.org/mirror/sources/ you MUST provide the source, as generated from your DL_DIR.<br />
* md5sums must be generated for EVERY file to be included in the release. Please use something similar to <code> find . -type f -exec md5sum {} \; >> ../mybsp-poky-edison-6.0.md5sum </code> to generate.<br />
** This should include additional files needed from your DL_DIR. <br />
** I do validate every file's md5sum prior to release and will not gpg sign an invalid .md5sum <br />
* You must include release notes.<br />
* You should include some sort of QA report, preferably a link to the QA report on the yocto wiki.<br />
* You should inform the Yocto Release Engineer (elizabeth.flanagan@intel.com) at least 2 weeks prior to your intended release date (We prefer 4 weeks so we don't surprise those kind folks who mirror yocto). <br />
* Everything required for release must available to the Yocto Release Engineer at least 48 hours prior to release. This time is needed for mirror propagation.<br />
* Please do NOT mix major releases (e.g. building a meta-foo bsp layer with edison 6.0 and meta-qt3 5.0.1 ).<br />
* Please ensure that your release is built with a known poky release.<br />
* While you can include the poky release with your BSP, it is *STRONGLY* suggested that you do not, but rather provide a link to it. See [[BKM:_Packaging_a_BSP_for_Release]]<br />
<br />
===Release Checklist===<br />
<br />
2-4 Weeks Prior:<br />
* You have emailed the Yocto Release Engineer with your intention to release. Please try to give an estimate size of the release and against what released version of yocto you are building against.<br />
<p></p><br />
Prior to the Release:<br />
* You have generated a tested BSP release against a known released version of yocto. Please include the git hash for EVERY official yocto layer you have built against. (meta-qt3, etc). <br />
* You have created a publicly accessible QA report that the release may link against.<br />
* You have generated an md5sum file of all files needed.<br />
* You have validated that all required source files are either in http://downloads.yoctoproject.org/sources or in the area to be used for the release.<br />
* You have created a valid and documented BSP layer tarball named LAYERNAME-RELEASENAME-M.m.p.tar.bz2<br />
<p></p>48 Hours Prior to your release:<br />
* You have emailed the Yocto Release Engineer a link to download all files needed for the release<br />
* I validate the md5sums<br />
* I gpg sign the .md5sum file and prepare the release for the release directory/mirrors<br />
<p></p><br />
Hours Prior to release:<br />
* Download links are made live and verified by both the Yocto Release Engineer and You.<br />
* If you would like the release announcement to be sent out to yocto-announce you have provided the text to the Yocto Community Manager (Jefro) and the Yocto Release Engineer.<br />
<br />
===Release Checklist===</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Checklist&diff=12978Yocto Project Release Checklist2014-06-02T18:14:27Z<p>Eflanagan: Created page with "Major Release - Week prior to build of release candidate - Updates to the following packages will have occurred. DO NO PANIC, these come late in the release cycle - wic ..."</p>
<hr />
<div>Major Release <br />
<br />
- Week prior to build of release candidate<br />
- Updates to the following packages will have occurred. DO NO PANIC, these come late in the release cycle<br />
- wic <br />
- meta-yocto-bsp <br />
- meta-yocto<br />
- linux-firmware <br />
- bootloaders (grub, syslinux, u-boot, gummiboot, etc..) <br />
- hwdata <br />
- pciutils <br />
- util-linux <br />
- i2c-tools <br />
- alsa <br />
- graphics drivers <br />
- cryptodev <br />
- systemtap<br />
- perf<br />
- linux-yocto<br />
<br />
- Prior to build of release candidate<br />
- Is DISTRO_VERSION updated?<br />
- Is SDK_VERSION updated?<br />
- Is SANITY_TESTED_DISTROS updated?</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Release_Engineering&diff=12968Yocto Release Engineering2014-05-23T16:45:56Z<p>Eflanagan: </p>
<hr />
<div>== Yocto Project Release Engineering ==<br />
<br />
Welcome to Yocto Project Release Engineering.<br />
<br />
=== Processes ===<br />
<br />
* [[Yocto Project Release Checklist]]<br />
* [[Yocto Project Release Process]]<br />
* [[Third_Party_BSP_Release_Process | Third Party BSP Release Guidelines]]<br />
<br />
=== Conventions ===<br />
<br />
* [[Yocto Project Tagging Conventions]]<br />
* [[Yocto Project Branch Conventions]]<br />
<br />
=== Resources ===<br />
<br />
* [[The Yocto Autobuilder]]<br />
* [[Frequently Asked Release Engineering Questions]]<br />
* [[Frequently Asked Yocto Autobuilder Questions]]<br />
<br />
=== Best Known Methods ===<br />
<br />
* [[BKM: Packaging a BSP for Release]]<br />
* [[BKM: Releasing a source archive]]<br />
<br />
=== Release Engineering Team ===<br />
<br />
The Yocto Project's Release Engineering is mostly handled by Beth "pidge" Flanagan with support from Michael Halstead.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Toaster&diff=12256Toaster2014-03-31T20:25:26Z<p>Eflanagan: Correcting pip install line.</p>
<hr />
<div>[[Category:Toaster]]<br />
[[Toaster]] is a Web-based interface to the Bitbake build system and the Poky distribution inside the Yocto Project.<br />
This project was formely known as Web Hob / Webhob / webhob, and you may still find references to the old name in the documentation.<br />
<br />
General discussion about '''Toaster''' happens on a dedicated mailing list: [https://lists.yoctoproject.org/listinfo/toaster https://lists.yoctoproject.org/listinfo/toaster]<br />
<br />
Project planning is available below, are the design documents we follow.<br />
<br />
== User interface ==<br />
The design of the user interface takes place in iterations, and most recent designs supersede older ones.<br />
<br />
The latest iteration is always available at: http://www.yoctoproject.org/toaster<br />
<br />
The document [[File:Toaster_1.6_content_structure.pdf]] shows the content structure of Toaster in the 1.6 release.<br />
<br />
=== Other design documentation ===<br />
* [[Visualisations]] - an inventory of data visualisations we aim to include in the first release of Toaster<br />
* [[File:WH_roadmap.pdf]] - the roadmap for Toaster development produced by the London-based agency Tobias&Tobias<br />
* [[File:Multiuser_support_in_Web_Hob.pdf]] - different design approaches to handle multi-user scenarios<br />
* [[File:Web_Hob_content_structure.pdf]] - Toaster information architecture, as it came out from the design project with Tobias&Tobias<br />
<br />
=== Old design documents ===<br />
* [[Web_Hob_design_project_with_T%26T]] - The outcome of the design project with the external agency Tobias&Tobias<br />
* [[Yocto Web Hob Design 0.0 — Archived|A preliminary design project]] by [http://www.jimkosem.com/ Jim Kosem]<br />
<br />
== Architecture and component design ==<br />
<br />
<br />
We are planning the capabilities of [[Toaster]] based on evolutive stages of implementation, using community feedback on each stage to plan, design and implement a set of capabilities for the next stage.<br />
In the first stage, synchronized with the planning of [https://www.yoctoproject.org/download/toaster-web-interface Yocto Project 1.5 release], we implemented the back end of a build analysis / image inspection module. <br />
As part of the Yocto Project 1.6 release, we are building a web-based graphical user interface for the build analysis / image inspection module.<br />
<br />
[[Toaster]] is designed as a collection of components that will run independently performing isolated functions. The interfaces between components are documented on this wiki as to ease interoperability with newer components. From design phase, we've taken care to account for further expansion needs, and account for scalability problems.<br />
<br />
* [[ Data store investigation results and choices ]]<br />
<br />
* [[ Django models ]]<br />
<br />
* [[ REST API Contracts ]]<br />
<br />
* [[Bugzilla feature list]]<br />
<br />
== Installation and Running ==<br />
<br />
Before you start, make sure you install the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#intro-requirements packages required by the Yocto Project]<br />
<br />
=== Using the master branch ===<br />
<br />
==== You need this stuff ready ====<br />
<br />
* Django 1.5; easiest way is to install system wide with <code> pip install django=="1.5" </code><br />
* Make sure that port 8000 and 8200 are free, i.e. no servers on them<br />
<br />
==== To get it up and running ====<br />
<br />
* clone the master tree: http://git.yoctoproject.org/git/poky<br />
* set up a build as normal: <code> source poky/oe-init-build-env </code><br />
* at this point edit <code>local.conf</code>, or layers, etc.<br />
* start Toaster system: <code> source toaster start </code><br />
* run builds normally: <code> bitbake core-image-minimal </code><br />
* to see the web interface: <code> xdg-open http://localhost:8000/ </code><br />
* to stop Toaster: <code> source toaster stop </code><br />
<br />
=== Using the Dora + Toaster release (part of Yocto Project 1.5) ===<br />
<br />
==== You need this stuff ready ====<br />
<br />
* Django 1.4.5; easiest way is to install system wide with <code> pip install django=="1.4.5" </code><br />
* Make sure that port 8000 and 8200 are free, i.e. no servers on them<br />
<br />
==== To get it up and running ====<br />
<br />
* checkout the Dora + Toaster release tree: http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dora-toaster<br />
* set up a build as normal: <code> source poky/oe-init-build-env </code><br />
* at this point edit <code>local.conf</code>, or layers, etc.<br />
* start Toaster system: <code> source toaster start </code><br />
* run builds normally: <code> bitbake core-image-minimal </code><br />
* to see the web interface: <code> xdg-open http://localhost:8000/ </code><br />
* to stop Toaster: <code> source toaster stop </code><br />
<br />
===Bitbake extra options ===<br />
<br />
This is an overview of extra options needed for Bitbake. These should be automatically added by Toaster<br />
in a conf/toaster.conf file that is enabled when the system starts through the toaster command.<br />
<br />
The gritty details are here:<br />
<br />
[[Toaster]] needs the '''toaster''' bbclass enabled in Bitbake in order to record target image package information.<br />
<code> INHERIT += "toaster" </code><br />
<br />
This enables the '''toaster''' bbclass in Bitbake, needed to record target image package information.<br />
<br />
<code> INHERIT += "buildhistory" </code> <br />
<br /><br />
<code> BUILDHISTORY_COMMIT = "1" </code><br />
<br />
This enables '''buildhistory''' in Bitbake, needed to record target image package information.<br />
This last command is not strictly needed, yet without it '''buildhistory''' will not work right in it's own right.<br />
<br />
==== A bunch of files are created and used under the build/ directory: ====<br />
<br />
* toaster.sqlite - the database file<br />
* toaster_web.log - the log file of the web server<br />
* toaster_ui.log - the log file of the ui component<br />
* .toastermain.pid - contains the pid of the web server<br />
* .toasterui.pid - contains the pid of the DSI data bridge<br />
* bitbake-cookerdaemon.log - the log file of the bitbake server<br />
<br />
== Testing ==<br />
Documentation and results related to [[Toaster]] Quality Assurance.<br />
<br />
* [[ Toaster testing plan ]]<br />
<br />
== Contributing to Toaster ==<br />
Toaster is a community effort and welcomes your contribution. <br />
<br />
* [[Contribute to Toaster]]<br />
<br />
== Old page content ==<br />
<br />
This page is about the Web Hob project. Web Hob is a web-based interface to the Yocto Project. <br />
<br />
General discussion about '''Web Hob''' happens on a dedicated mailing list: [https://lists.yoctoproject.org/listinfo/webhob https://lists.yoctoproject.org/listinfo/webhob]<br />
<br />
There have been 2 main pieces of work related to Web Hob so far:<br />
<br />
* [[Web Hob design project with T&T|A design project with the London-based agency Tobias & Tobias]]<br />
* [[Yocto Web Hob Design 0.0 — Archived|A preliminary design project]] by [http://www.jimkosem.com/ Jim Kosem]<br />
<br />
=== Web Hob information architecture ===<br />
<br />
This document represents the content structure of the Web Hob application.<br />
<br />
[[File:Web_Hob_content_structure.pdf]]<br />
<br />
=== Different approaches to multi-user workflows ===<br />
<br />
This document outlines the different approaches we have uncovered so far to facilitate multi-user and team work with Web Hob. <br />
<br />
* [[File:Multiuser_support_in_Web_Hob.pdf]]<br />
<br />
=== Visualisations index ===<br />
<br />
The build analysis functionality in Web Hob will include several graphical presentations of build data. The first step to design them is [[visualisations |listing them all]].</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Toaster&diff=12255Toaster2014-03-31T20:25:08Z<p>Eflanagan: Correcting pip install line.</p>
<hr />
<div>[[Category:Toaster]]<br />
[[Toaster]] is a Web-based interface to the Bitbake build system and the Poky distribution inside the Yocto Project.<br />
This project was formely known as Web Hob / Webhob / webhob, and you may still find references to the old name in the documentation.<br />
<br />
General discussion about '''Toaster''' happens on a dedicated mailing list: [https://lists.yoctoproject.org/listinfo/toaster https://lists.yoctoproject.org/listinfo/toaster]<br />
<br />
Project planning is available below, are the design documents we follow.<br />
<br />
== User interface ==<br />
The design of the user interface takes place in iterations, and most recent designs supersede older ones.<br />
<br />
The latest iteration is always available at: http://www.yoctoproject.org/toaster<br />
<br />
The document [[File:Toaster_1.6_content_structure.pdf]] shows the content structure of Toaster in the 1.6 release.<br />
<br />
=== Other design documentation ===<br />
* [[Visualisations]] - an inventory of data visualisations we aim to include in the first release of Toaster<br />
* [[File:WH_roadmap.pdf]] - the roadmap for Toaster development produced by the London-based agency Tobias&Tobias<br />
* [[File:Multiuser_support_in_Web_Hob.pdf]] - different design approaches to handle multi-user scenarios<br />
* [[File:Web_Hob_content_structure.pdf]] - Toaster information architecture, as it came out from the design project with Tobias&Tobias<br />
<br />
=== Old design documents ===<br />
* [[Web_Hob_design_project_with_T%26T]] - The outcome of the design project with the external agency Tobias&Tobias<br />
* [[Yocto Web Hob Design 0.0 — Archived|A preliminary design project]] by [http://www.jimkosem.com/ Jim Kosem]<br />
<br />
== Architecture and component design ==<br />
<br />
<br />
We are planning the capabilities of [[Toaster]] based on evolutive stages of implementation, using community feedback on each stage to plan, design and implement a set of capabilities for the next stage.<br />
In the first stage, synchronized with the planning of [https://www.yoctoproject.org/download/toaster-web-interface Yocto Project 1.5 release], we implemented the back end of a build analysis / image inspection module. <br />
As part of the Yocto Project 1.6 release, we are building a web-based graphical user interface for the build analysis / image inspection module.<br />
<br />
[[Toaster]] is designed as a collection of components that will run independently performing isolated functions. The interfaces between components are documented on this wiki as to ease interoperability with newer components. From design phase, we've taken care to account for further expansion needs, and account for scalability problems.<br />
<br />
* [[ Data store investigation results and choices ]]<br />
<br />
* [[ Django models ]]<br />
<br />
* [[ REST API Contracts ]]<br />
<br />
* [[Bugzilla feature list]]<br />
<br />
== Installation and Running ==<br />
<br />
Before you start, make sure you install the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#intro-requirements packages required by the Yocto Project]<br />
<br />
=== Using the master branch ===<br />
<br />
==== You need this stuff ready ====<br />
<br />
* Django 1.5; easiest way is to install system wide with <code> pip install django=="1.5" </code><br />
* Make sure that port 8000 and 8200 are free, i.e. no servers on them<br />
<br />
==== To get it up and running ====<br />
<br />
* clone the master tree: http://git.yoctoproject.org/git/poky<br />
* set up a build as normal: <code> source poky/oe-init-build-env </code><br />
* at this point edit <code>local.conf</code>, or layers, etc.<br />
* start Toaster system: <code> source toaster start </code><br />
* run builds normally: <code> bitbake core-image-minimal </code><br />
* to see the web interface: <code> xdg-open http://localhost:8000/ </code><br />
* to stop Toaster: <code> source toaster stop </code><br />
<br />
=== Using the Dora + Toaster release (part of Yocto Project 1.5) ===<br />
<br />
==== You need this stuff ready ====<br />
<br />
* Django 1.4.5; easiest way is to install system wide with <code> pip install django==1.4.5 </code><br />
* Make sure that port 8000 and 8200 are free, i.e. no servers on them<br />
<br />
==== To get it up and running ====<br />
<br />
* checkout the Dora + Toaster release tree: http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dora-toaster<br />
* set up a build as normal: <code> source poky/oe-init-build-env </code><br />
* at this point edit <code>local.conf</code>, or layers, etc.<br />
* start Toaster system: <code> source toaster start </code><br />
* run builds normally: <code> bitbake core-image-minimal </code><br />
* to see the web interface: <code> xdg-open http://localhost:8000/ </code><br />
* to stop Toaster: <code> source toaster stop </code><br />
<br />
===Bitbake extra options ===<br />
<br />
This is an overview of extra options needed for Bitbake. These should be automatically added by Toaster<br />
in a conf/toaster.conf file that is enabled when the system starts through the toaster command.<br />
<br />
The gritty details are here:<br />
<br />
[[Toaster]] needs the '''toaster''' bbclass enabled in Bitbake in order to record target image package information.<br />
<code> INHERIT += "toaster" </code><br />
<br />
This enables the '''toaster''' bbclass in Bitbake, needed to record target image package information.<br />
<br />
<code> INHERIT += "buildhistory" </code> <br />
<br /><br />
<code> BUILDHISTORY_COMMIT = "1" </code><br />
<br />
This enables '''buildhistory''' in Bitbake, needed to record target image package information.<br />
This last command is not strictly needed, yet without it '''buildhistory''' will not work right in it's own right.<br />
<br />
==== A bunch of files are created and used under the build/ directory: ====<br />
<br />
* toaster.sqlite - the database file<br />
* toaster_web.log - the log file of the web server<br />
* toaster_ui.log - the log file of the ui component<br />
* .toastermain.pid - contains the pid of the web server<br />
* .toasterui.pid - contains the pid of the DSI data bridge<br />
* bitbake-cookerdaemon.log - the log file of the bitbake server<br />
<br />
== Testing ==<br />
Documentation and results related to [[Toaster]] Quality Assurance.<br />
<br />
* [[ Toaster testing plan ]]<br />
<br />
== Contributing to Toaster ==<br />
Toaster is a community effort and welcomes your contribution. <br />
<br />
* [[Contribute to Toaster]]<br />
<br />
== Old page content ==<br />
<br />
This page is about the Web Hob project. Web Hob is a web-based interface to the Yocto Project. <br />
<br />
General discussion about '''Web Hob''' happens on a dedicated mailing list: [https://lists.yoctoproject.org/listinfo/webhob https://lists.yoctoproject.org/listinfo/webhob]<br />
<br />
There have been 2 main pieces of work related to Web Hob so far:<br />
<br />
* [[Web Hob design project with T&T|A design project with the London-based agency Tobias & Tobias]]<br />
* [[Yocto Web Hob Design 0.0 — Archived|A preliminary design project]] by [http://www.jimkosem.com/ Jim Kosem]<br />
<br />
=== Web Hob information architecture ===<br />
<br />
This document represents the content structure of the Web Hob application.<br />
<br />
[[File:Web_Hob_content_structure.pdf]]<br />
<br />
=== Different approaches to multi-user workflows ===<br />
<br />
This document outlines the different approaches we have uncovered so far to facilitate multi-user and team work with Web Hob. <br />
<br />
* [[File:Multiuser_support_in_Web_Hob.pdf]]<br />
<br />
=== Visualisations index ===<br />
<br />
The build analysis functionality in Web Hob will include several graphical presentations of build data. The first step to design them is [[visualisations |listing them all]].</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP_for_Release&diff=11697BKM: Packaging a BSP for Release2013-12-04T16:40:42Z<p>Eflanagan: /* Releasing a BSP */</p>
<hr />
<div>== Packaging a BSP for Release ==<br />
<br />
This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]<br />
<br />
=== General Guidelines ===<br />
<br />
* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP<br />
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.<br />
* A BSP tarball should contain a MAINTAINERS and a README file<br />
* A BSP tarball should contain licensing information<br />
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core<br />
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.<br />
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.<br />
<br />
=== Example structure ===<br />
<br />
For our example, we will utilize the meta-intel BSP, meta-fri2.<br />
<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-chiefriver<br />
d--------- meta-crownbay<br />
d--------- meta-crystalforest<br />
d--------- meta-emenlow<br />
d--------- meta-fri2<br />
d--------- meta-isg<br />
d--------- meta-jasperforest<br />
d--------- meta-n450<br />
d--------- meta-nuc<br />
d--------- meta-romley<br />
d--------- meta-sugarbay<br />
d--------- meta-sys940x<br />
d--------- meta-tlk<br />
</nowiki><br />
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories. <br />
<br />
For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- binary<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
Next, we will add a binary directory. This should contain the images needed to get hardware to boot.<br />
<br />
We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.<br />
<br />
The naming convention for the tarball is:<br />
<br />
<name of bsp>-<name of release it was built against>-M.m.p<br />
<br />
We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Release_Engineering&diff=11696Yocto Release Engineering2013-12-04T16:38:21Z<p>Eflanagan: /* Best Known Methods */</p>
<hr />
<div>== Yocto Project Release Engineering ==<br />
<br />
Welcome to Yocto Project Release Engineering.<br />
<br />
=== Processes ===<br />
<br />
* [[Yocto Project Release Process]]<br />
* [[Third_Party_BSP_Release_Process | Third Party BSP Release Guidelines]]<br />
<br />
=== Conventions ===<br />
<br />
* [[Yocto Project Tagging Conventions]]<br />
* [[Yocto Project Branch Conventions]]<br />
<br />
=== Resources ===<br />
<br />
* [[The Yocto Autobuilder]]<br />
* [[Frequently Asked Release Engineering Questions]]<br />
* [[Frequently Asked Yocto Autobuilder Questions]]<br />
<br />
=== Best Known Methods ===<br />
<br />
* [[BKM: Packaging a BSP for Release]]<br />
* [[BKM: Releasing a source archive]]<br />
<br />
=== Release Engineering Team ===<br />
<br />
The Yocto Project's Release Engineering is mostly handled by Beth "pidge" Flanagan with support from Michael Halstead.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Releasing_a_BSP&diff=11695BKM: Releasing a BSP2013-12-04T16:37:49Z<p>Eflanagan: moved BKM: Releasing a BSP to BKM: Packaging a BSP for Release: Better title</p>
<hr />
<div>#REDIRECT [[BKM: Packaging a BSP for Release]]</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP_for_Release&diff=11694BKM: Packaging a BSP for Release2013-12-04T16:37:49Z<p>Eflanagan: moved BKM: Releasing a BSP to BKM: Packaging a BSP for Release: Better title</p>
<hr />
<div>== Releasing a BSP ==<br />
<br />
This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]<br />
<br />
=== General Guidelines ===<br />
<br />
* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP<br />
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.<br />
* A BSP tarball should contain a MAINTAINERS and a README file<br />
* A BSP tarball should contain licensing information<br />
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core<br />
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.<br />
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.<br />
<br />
=== Example structure ===<br />
<br />
For our example, we will utilize the meta-intel BSP, meta-fri2.<br />
<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-chiefriver<br />
d--------- meta-crownbay<br />
d--------- meta-crystalforest<br />
d--------- meta-emenlow<br />
d--------- meta-fri2<br />
d--------- meta-isg<br />
d--------- meta-jasperforest<br />
d--------- meta-n450<br />
d--------- meta-nuc<br />
d--------- meta-romley<br />
d--------- meta-sugarbay<br />
d--------- meta-sys940x<br />
d--------- meta-tlk<br />
</nowiki><br />
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories. <br />
<br />
For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- binary<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
Next, we will add a binary directory. This should contain the images needed to get hardware to boot.<br />
<br />
We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.<br />
<br />
The naming convention for the tarball is:<br />
<br />
<name of bsp>-<name of release it was built against>-M.m.p<br />
<br />
We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP&diff=11693BKM: Packaging a BSP2013-12-04T16:37:33Z<p>Eflanagan: moved BKM: Packaging a BSP to BKM: Packaging a BSP Trash</p>
<hr />
<div>#REDIRECT [[BKM: Packaging a BSP Trash]]</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP_Trash&diff=11692BKM: Packaging a BSP Trash2013-12-04T16:37:33Z<p>Eflanagan: moved BKM: Packaging a BSP to BKM: Packaging a BSP Trash</p>
<hr />
<div>== Packaging a BSP ==<br />
<br />
This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]<br />
<br />
=== General Guidelines ===<br />
<br />
* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP<br />
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.<br />
* A BSP tarball should contain a MAINTAINERS and a README file<br />
* A BSP tarball should contain licensing information<br />
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core<br />
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.<br />
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.<br />
<br />
=== Example structure ===<br />
<br />
For our example, we will utilize the meta-intel BSP, meta-fri2.<br />
<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-chiefriver<br />
d--------- meta-crownbay<br />
d--------- meta-crystalforest<br />
d--------- meta-emenlow<br />
d--------- meta-fri2<br />
d--------- meta-isg<br />
d--------- meta-jasperforest<br />
d--------- meta-n450<br />
d--------- meta-nuc<br />
d--------- meta-romley<br />
d--------- meta-sugarbay<br />
d--------- meta-sys940x<br />
d--------- meta-tlk<br />
</nowiki><br />
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories. <br />
<br />
For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- binary<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
Next, we will add a binary directory. This should contain the images needed to get hardware to boot.<br />
<br />
We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.<br />
<br />
The naming convention for the tarball is:<br />
<br />
<name of bsp>-<name of release it was built against>-M.m.p<br />
<br />
We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP_Trash&diff=11691BKM: Packaging a BSP Trash2013-12-04T16:36:35Z<p>Eflanagan: Created page with "== Packaging a BSP == This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, w..."</p>
<hr />
<div>== Packaging a BSP ==<br />
<br />
This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]<br />
<br />
=== General Guidelines ===<br />
<br />
* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP<br />
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.<br />
* A BSP tarball should contain a MAINTAINERS and a README file<br />
* A BSP tarball should contain licensing information<br />
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core<br />
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.<br />
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.<br />
<br />
=== Example structure ===<br />
<br />
For our example, we will utilize the meta-intel BSP, meta-fri2.<br />
<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-chiefriver<br />
d--------- meta-crownbay<br />
d--------- meta-crystalforest<br />
d--------- meta-emenlow<br />
d--------- meta-fri2<br />
d--------- meta-isg<br />
d--------- meta-jasperforest<br />
d--------- meta-n450<br />
d--------- meta-nuc<br />
d--------- meta-romley<br />
d--------- meta-sugarbay<br />
d--------- meta-sys940x<br />
d--------- meta-tlk<br />
</nowiki><br />
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories. <br />
<br />
For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- binary<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
Next, we will add a binary directory. This should contain the images needed to get hardware to boot.<br />
<br />
We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.<br />
<br />
The naming convention for the tarball is:<br />
<br />
<name of bsp>-<name of release it was built against>-M.m.p<br />
<br />
We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Release_Engineering&diff=11690Yocto Release Engineering2013-12-04T16:35:38Z<p>Eflanagan: /* Best Known Methods */</p>
<hr />
<div>== Yocto Project Release Engineering ==<br />
<br />
Welcome to Yocto Project Release Engineering.<br />
<br />
=== Processes ===<br />
<br />
* [[Yocto Project Release Process]]<br />
* [[Third_Party_BSP_Release_Process | Third Party BSP Release Guidelines]]<br />
<br />
=== Conventions ===<br />
<br />
* [[Yocto Project Tagging Conventions]]<br />
* [[Yocto Project Branch Conventions]]<br />
<br />
=== Resources ===<br />
<br />
* [[The Yocto Autobuilder]]<br />
* [[Frequently Asked Release Engineering Questions]]<br />
* [[Frequently Asked Yocto Autobuilder Questions]]<br />
<br />
=== Best Known Methods ===<br />
<br />
* [[BKM: Packaging a BSP]]<br />
* [[BKM: Releasing a source archive]]<br />
<br />
=== Release Engineering Team ===<br />
<br />
The Yocto Project's Release Engineering is mostly handled by Beth "pidge" Flanagan with support from Michael Halstead.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=BKM:_Packaging_a_BSP_for_Release&diff=11689BKM: Packaging a BSP for Release2013-12-04T16:01:48Z<p>Eflanagan: Created page with "== Releasing a BSP == This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, w..."</p>
<hr />
<div>== Releasing a BSP ==<br />
<br />
This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]<br />
<br />
=== General Guidelines ===<br />
<br />
* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP<br />
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.<br />
* A BSP tarball should contain a MAINTAINERS and a README file<br />
* A BSP tarball should contain licensing information<br />
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core<br />
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.<br />
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.<br />
<br />
=== Example structure ===<br />
<br />
For our example, we will utilize the meta-intel BSP, meta-fri2.<br />
<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-chiefriver<br />
d--------- meta-crownbay<br />
d--------- meta-crystalforest<br />
d--------- meta-emenlow<br />
d--------- meta-fri2<br />
d--------- meta-isg<br />
d--------- meta-jasperforest<br />
d--------- meta-n450<br />
d--------- meta-nuc<br />
d--------- meta-romley<br />
d--------- meta-sugarbay<br />
d--------- meta-sys940x<br />
d--------- meta-tlk<br />
</nowiki><br />
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories. <br />
<br />
For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.<br />
<br />
<nowiki><br />
-rw-r--r-- MAINTAINERS<br />
-rw-r--r-- README<br />
d--------- binary<br />
d--------- classes<br />
d--------- common<br />
d--------- conf<br />
d--------- meta-fri2<br />
d--------- meta-tlk<br />
</nowiki><br />
<br />
Next, we will add a binary directory. This should contain the images needed to get hardware to boot.<br />
<br />
We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.<br />
<br />
The naming convention for the tarball is:<br />
<br />
<name of bsp>-<name of release it was built against>-M.m.p<br />
<br />
We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Branch_Conventions&diff=11688Yocto Project Branch Conventions2013-12-04T15:27:29Z<p>Eflanagan: Created page with "== Branching Conventions == === Introduction === This page explains when we branch certain Yocto Project repositories, the naming conventions used and what we require from third..."</p>
<hr />
<div>== Branching Conventions ==<br />
=== Introduction ===<br />
<br />
This page explains when we branch certain Yocto Project repositories, the naming conventions used and what we require from third party BSP maintainers if their BSPs are built via the Yocto Autobuilder<br />
<br />
==== Branching Philosophy ====<br />
<br />
We try to limit the number of branches in the main Yocto Project repository to feature branches, master, master-next and release branches. At one point in the past, we regularly utilized branches for milestones. In general, we no longer do so, however, we can and will utilize milestone branches when we're trying to maintain the stability of master, but get a very large feature into a milestone.<br />
<br />
==== Naming Conventions ====<br />
<br />
We utilize for the poky, eclipse-plugin-*, meta-qt3 repos the following convention<br />
<br />
1. If it is a milestone branch, which should be rare, the branch name will be M.m_M<milestone_number>. Example: 1.5_M1<br />
2. If it is a release branch, the branch name will be the name of the release (dylan, dora, etc)<br />
3. If it is a next branch, the branch name will be the name of what it is the next of, appended with a -next (master-next, dora-next)<br />
<br />
==== BSP repo maintainers ====<br />
<br />
At one point in the past, we required BSP repo maintainers to maintain their repos utilizing our naming convention if they were utilizing the autobuilder infrastructure to maintain their builds. We no longer require this. However, BSP repo maintainers, should take note that it is their job to inform Build and Release of what branches/tags they wish to have included in a milestone/release build. It is also their job to make sure that the release branches are kept up to date.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Main_Page&diff=11686Main Page2013-12-04T15:11:47Z<p>Eflanagan: /* Main Wiki Sections */</p>
<hr />
<div>== Welcome to the Yocto Project Wiki! ==<br />
=== Current Project Status and Schedule ===<br />
* [[Yocto Project v1.6 Status]]<br />
* [[Yocto 1.6 Schedule]]<br />
* [[1.6 qa run history]]<br />
* [[1.6 QA Status]]<br />
<br />
=== Main Wiki Sections ===<br />
* [[Planning and Governance]]<br />
* [[Community Guidelines]]<br />
* [[Yocto Release Engineering | Yocto Project Release Engineering]]<br />
* [[Processes and Activities]]<br />
** [[YoctoCalendar]]<br />
* [[Projects]]<br />
* [[Yocto Interest Groups]]<br />
* [[FAQ]]<br />
* [[How do I]]<br />
* [[Contributors]]<br />
* [[Training]]<br />
* [[Testopia]] - The Yocto Project's community-opened test case management platform<br />
* [[Toaster]] - the web interface | [[Web UI]] - The design plans for the new Web UI<br />
<br />
== Other resources ==<br />
* [http://yoctoproject.org Yocto Project Front Page]</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Release_Engineering&diff=11685Yocto Release Engineering2013-12-04T13:32:38Z<p>Eflanagan: /* Resources */</p>
<hr />
<div>== Yocto Project Release Engineering ==<br />
<br />
Welcome to Yocto Project Release Engineering.<br />
<br />
=== Processes ===<br />
<br />
* [[Yocto Project Release Process]]<br />
* [[Third_Party_BSP_Release_Process | Third Party BSP Release Guidelines]]<br />
<br />
=== Conventions ===<br />
<br />
* [[Yocto Project Tagging Conventions]]<br />
* [[Yocto Project Branch Conventions]]<br />
<br />
=== Resources ===<br />
<br />
* [[The Yocto Autobuilder]]<br />
* [[Frequently Asked Release Engineering Questions]]<br />
* [[Frequently Asked Yocto Autobuilder Questions]]<br />
<br />
=== Best Known Methods ===<br />
<br />
* [[BKM: Releasing a BSP]]<br />
* [[BKM: Releasing a source archive]]<br />
<br />
=== Release Engineering Team ===<br />
<br />
The Yocto Project's Release Engineering is mostly handled by Beth "pidge" Flanagan with support from Michael Halstead.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Frequently_Asked_Release_Engineering_Questions&diff=11677Frequently Asked Release Engineering Questions2013-12-03T15:08:59Z<p>Eflanagan: /* When is the next major release? When is the next X.X.x release? */</p>
<hr />
<div>=== Frequently Asked Questions (Release Engineering) ==<br />
<br />
=== How often are these pages updated? Who updates them? ===<br />
<br />
The main Release wiki pages will be reviewed by the Yocto Project release engineer, half way between each major release and immediately after a major release, to ensure that information is kept up to date. <br />
<br />
=== When is the next major release? When is the next X.X.x release? ===<br />
<br />
We release major releases at a 6 month interval. Generally, odd numbered releases fall sometime in mid-late October, even releases fall mid-late April. The next major release is due out sometime around April 2014.<br />
<br />
Point releases are released on an adhoc basis.<br />
<br />
=== How long are point releases supported ===<br />
<br />
We will produce point releases of prior major releases:<br />
* to fix critical bugs and security issues (CVEs) for the first 6 months after release<br />
* to fix security issues(CVEs) for the first year after release<br />
<br />
From an autobuilder standpoint, we generally maintain autobuilder backwards compatibility for at least 5 major releases. This is slowly getting better, with the goal of being able to be backwards compatible for at least 3 years worth of releases.<br />
<br />
=== Danny? Dylan? Denzil? How can I find out the name of the next Yocto Project major release? ===<br />
<br />
We generally call the next major release by it's major.minor number up until about a month or so prior to the major release. <br />
In the spirit of full disclosure, we don't even know the name of the release until Richard Purdie comes up with it. <br />
<br />
=== Where does the naming convention come from? ===<br />
<br />
It's a secret!<br />
<br />
=== How does the Yocto Project release software? ===<br />
<br />
The [[Yocto_Project_Release_Process | Yocto Project's Release Process]] establishes the full process for both major and point releases.<br />
<br />
=== How do I release my own board support package and put them up on the Yocto Project downloads site? ===<br />
<br />
The [[Third_Party_BSP_Release_Process | Third Party BSP Release Process]] establishes the full process for BSP releases.<br />
<br />
=== How do I maintain compliance with open source licenses? ===<br />
<br />
Coming Soon<br />
<br />
=== How do I release a product using the Yocto Project? ===<br />
<br />
Coming Soon<br />
<br />
=== meta-jarvis layer? kernel 0.98pl13? What is wrong with you people? ===<br />
<br />
Every major release includes an easter egg or two within the Yocto Project's release notes.<br />
<br />
Prior Easter Eggs included:<br />
<br />
* Implementation of a magic smoke generator<br />
* The meta-jarvis layer for the Iron Man suit<br />
* The meta-yocto-classic layer, which includes mc.<br />
<br />
Most of these are inside project jokes. For example, our community manager, Jeff "jefro" Osier-Mixon bears a resemblance to Robert Downey Jr. <br />
Richard Purdie has a love of mc. They're generally pretty obvious jokes, except when they're [https://plus.google.com/111049168280159033135/posts/hTcunXAqCHU not].</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Tagging_Conventions&diff=11676Yocto Project Tagging Conventions2013-12-03T14:06:02Z<p>Eflanagan: Created page with " === Yocto Project Tags === In order to understand the tagging used within the Yocto Project, it is important to note what we release. We can break up our releases into three ty..."</p>
<hr />
<div><br />
=== Yocto Project Tags ===<br />
<br />
In order to understand the tagging used within the Yocto Project, it is important to note what we release. We can break up our releases into three types. Major, minor, milestone. For each of these we release both the Yocto Project as well as the reference distribution, "poky", that we built with this version of the Yocto Project's build system.<br />
<br />
During Milestone releases, we utilize the milestone naming convention to denote both poky and Yocto Project milestone releases. So, for example, during 1.4's milestone 4 release, we would use 1.4_M4.<br />
<br />
Once we've branched to a major or minor named release branch, we no longer use the milestone name. We denote yocto releases and poky releases with different tags. There is no technical reason for this, it is merely for convenience. Some people are more familiar with Yocto release names over poky release names<br />
<br />
=== Yocto Project Tagging Conventions ===<br />
<br />
In general, we utilize 3 main types of tags in the main Yocto Project repositories:<br />
<br />
Milestone Tags:<br />
M.m_M<milestone number><br />
1.4_M2<br />
<br />
Poky Tags:<br />
<name>-M.m.p<br />
dora-10.0.0<br />
<br />
Yocto Project Tags:<br />
yocto-M.m<br />
yocto-1.5<br />
<br />
We also have a few prefixes that we utilize for tags:<br />
<br />
* release candidate<br />
Used to denote a release candidate<br />
yocto-1.5_M5.rc1<br />
dora-10.0.0.rc8<br />
<br />
* final release<br />
Used to denote "final". Because we are aggressive in our release schedule, and because we do not delete tags, we utilize .final to denote the final version of a major and point releases.Most times, the .final tag will match up with the <name>-M.m.p tag. But we utilize .final when we sometimes have to slip a few changes into the release before it goes it. This is especially useful for documentation.<br />
<br />
dora-10.0.0.final<br />
<br />
When in doubt, always utilize the .final tag.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Release_Engineering&diff=11675Yocto Release Engineering2013-12-03T13:51:22Z<p>Eflanagan: /* Resources */</p>
<hr />
<div>== Yocto Project Release Engineering ==<br />
<br />
Welcome to Yocto Project Release Engineering.<br />
<br />
=== Resources ===<br />
<br />
* [[Yocto Project Release Process]]<br />
* [[Third_Party_BSP_Release_Process | Third Party BSP Release Guidelines]]<br />
* [[Yocto Project Tagging Conventions]]<br />
* [[The Yocto Autobuilder]]<br />
* [[Frequently Asked Release Engineering Questions]]<br />
* [[Frequently Asked Yocto Autobuilder Questions]]<br />
<br />
=== Release Engineering Team ===<br />
<br />
The Yocto Project's Release Engineering is mostly handled by Beth "pidge" Flanagan with support from Michael Halstead.</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11674Yocto Project Release Process2013-12-03T13:50:44Z<p>Eflanagan: </p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Release Process for the Yocto Project ====<br />
<br />
===== Prior to last milestone =====<br />
* Release Engineer gets release name from Richard Purdie and announces it via yocto@yoctoproject.org<br />
* Release Engineer informs Documentation of the new release names so that they have time to modify documentation<br />
<br />
===== Last milestone =====<br />
During the last milestone we generally will build from master and then branch when things are at the point where they're mostly stable. We do this to reduce the amount of work required to maintain two branches. Once we're seeing good daily builds and feel confident enough to branch, we will branch the poky, meta-qt3 and eclipse repos to a branch named after the name of the release (dora, dylan, laverne, etc).<br />
<br />
===== Prior to release build ===== <br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers.<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Release of Build =====<br />
* Copy the build from the autobuilder directory to the main release directory ( cp http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable)<br />
* For final release, copy the DL_DIR to yocto_M.m/sources<br />
* Rename tarballs if necessary, including top level directories to comply with documentation. For example. poky-<githash>.tar.bz2 should be renamed to poky-<release_name>-<release_number>.tar.bz2 and the top lever directory renamed accordingly.<br />
* Rename BSP tarballs if necessary, as above.<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* Copy the adt-dev repo to the live site<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Publish BSPs to the webpage.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
* Update DISTRO and DISTRO_VERSION in master to be the main release+snapshot<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
* Does the adt-repo work</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11673Yocto Project Release Process2013-12-03T13:20:46Z<p>Eflanagan: /* Major/Point Release Procedures */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Release Process for the Yocto Project ====<br />
<br />
===== Prior to last milestone =====<br />
* Release Engineer gets release name from Richard Purdie and announces it via yocto@yoctoproject.org<br />
* Release Engineer informs Documentation of the new release names so that they have time to modify documentation<br />
<br />
===== Last milestone =====<br />
During the last milestone we generally will build from master and then branch when things are at the point where they're mostly stable. We do this to reduce the amount of work required to maintain two branches. Once we're seeing good daily builds and feel confident enough to branch, we will branch the poky, meta-qt3 and eclipse repos to a branch named after the name of the release (dora, dylan, laverne, etc).<br />
<br />
===== Prior to release build =====<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers.<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Release of Build =====<br />
* Copy the build from the autobuilder directory to the main release directory ( cp http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable)<br />
* For final release, copy the DL_DIR to yocto_M.m/sources<br />
* Rename tarballs if necessary, including top level directories to comply with documentation. For example. poky-<githash>.tar.bz2 should be renamed to poky-<release_name>-<release_number>.tar.bz2 and the top lever directory renamed accordingly.<br />
* Rename BSP tarballs if necessary, as above.<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* Copy the adt-dev repo to the live site<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Publish BSPs to the webpage.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
* Update DISTRO and DISTRO_VERSION in master to be the main release+snapshot<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
* Does the adt-repo work</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11672Yocto Project Release Process2013-12-03T13:15:48Z<p>Eflanagan: /* Release Process for the Yocto Project */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Release Process for the Yocto Project ====<br />
<br />
Prior to last milestone:<br />
* Release Engineer gets release name from Richard Purdie and announces it via yocto@yoctoproject.org<br />
* Release Engineer informs Documentation of the new release names so that they have time to modify documentation<br />
<br />
Last milestone:<br />
During the last milestone we generally will build from master and then branch when things are at the point where they're mostly stable. We do this to reduce the amount of work required to maintain two branches. Once we're seeing good daily builds and feel confident enough to branch, we will branch the poky, meta-qt3 and eclipse repos to a branch named after the name of the release (dora, dylan, laverne, etc).<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers.<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
Release of Build:<br />
* Copy the build from the autobuilder directory to the main release directory<br />
* Rename tarballs if necessary, including top level directories to comply with documentation. For example. poky-<githash>.tar.bz2 should be renamed to poky-<release_name>-<release_number>.tar.bz2 and the top lever directory renamed accordingly.<br />
* Rename BSP tarballs if necessary, as above.<br />
<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
* Does the adt-repo work<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11671Yocto Project Release Process2013-12-03T13:06:52Z<p>Eflanagan: /* Steps to building a release for Yocto */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Release Process for the Yocto Project ====<br />
<br />
Prior to last milestone:<br />
* Release Engineer gets release name from Richard Purdie and announces it via yocto@yoctoproject.org<br />
* Release Engineer informs Documentation of the new release names so that they have time to modify documentation<br />
<br />
Last milestone:<br />
During the last milestone we generally will build from master and then branch when things are at the point where they're mostly stable. We do this to reduce the amount of work required to maintain two branches. Once we're seeing good daily builds and feel confident enough to branch, we will branch the poky, meta-qt3 and eclipse repos to a branch named after the name of the release (dora, dylan, laverne, etc).<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- eclipse-plugin<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
Release of Build:<br />
* Copy the build from the autobuilder directory to the main release directory<br />
* Rename tarballs if necessary, including top level directories to comply with documentation. For example. poky-<githash>.tar.bz2 should be renamed to poky-<release_name>-<release_number>.tar.bz2 and the top lever directory renamed accordingly.<br />
* Rename BSP tarballs if necessary, as above.<br />
<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
* Does the adt-repo work<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11670Yocto Project Release Process2013-12-03T12:54:11Z<p>Eflanagan: /* Other components */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
* adt repository - A repository of all ipk packages used to build the images<br />
* RELEASENOTES - a gpg signed file with all bugfixes, added features and git hash info for a release<br />
* *.md5sums - md5sum files of all files within the release<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11669Yocto Project Release Process2013-12-03T12:43:23Z<p>Eflanagan: /* Other components */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* named git archives - a file with each git archived named with the hash of the git commit used the images were built from<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11668Yocto Project Release Process2013-12-03T12:41:54Z<p>Eflanagan: /* Release Matrix */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released at the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* gitinfo - a file which includes information about which commit the images were built from<br />
* Changelog - a file which includes git log information between the last released version and the newly built version<br />
* Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=The_Yocto_Autobuilder&diff=11602The Yocto Autobuilder2013-11-08T10:33:30Z<p>Eflanagan: /* The Yocto Autobuilder */</p>
<hr />
<div>== The Yocto Autobuilder ==<br />
<br />
The Yocto Autobuilder is a buildbot based autobuilder implementation that can be used to build out custom distros utilizing OE-Core (either bare or through the poky repository)<br />
<br />
The source code can be downloaded from [[git://git.yoctoproject.org/yocto-autobuilder]]<br />
<br />
The yocto-autobuilder maintainer is Elizabeth Flanagan. All patches to the yocto-autobuilder should be sent to yocto@yoctoproject.org. Please either CC: elizabeth.flanagan@intel.com or add [Autobuilder] to the subject line.<br />
<br />
If you have access to our production autobuilder, please read the documentation on [https://wiki.yoctoproject.org/wiki/How_to_start_a_build_on_the_Autobuilder how to kick off builds.]</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11291Yocto Project Release Process2013-09-30T17:38:49Z<p>Eflanagan: /* Release Matrix */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
Yocto Project/Poky Releases, while they do not share the same numbering, are released ate the same time. This includes point releases. So, for example, the 1.4.1 Yocto Project point release, was used to build the dylan-9.0.1 poky point release.<br />
<br />
<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|+Yocto Project/Poky Releases<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|-<br />
|1.2.x<br />
|denzil<br />
|7.0.x<br />
|-<br />
|1.1.x<br />
|edison<br />
|6.0.x<br />
|-<br />
|1.0.x<br />
|bernard<br />
|5.0.x<br />
|-<br />
|0.9.x<br />
|laverne<br />
|4.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* gitinfo - a file which includes information about which commit the images were built from<br />
* Changelog - a file which includes git log information between the last released version and the newly built version<br />
* Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11290Yocto Project Release Process2013-09-30T17:33:08Z<p>Eflanagan: /* Release Matrix */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* gitinfo - a file which includes information about which commit the images were built from<br />
* Changelog - a file which includes git log information between the last released version and the newly built version<br />
* Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11289Yocto Project Release Process2013-09-30T17:31:18Z<p>Eflanagan: /* Release Matrix */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Yocto Project Release<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Name<br />
! style="border-style: solid; border-width: 0 1px 1px 0" | Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* gitinfo - a file which includes information about which commit the images were built from<br />
* Changelog - a file which includes git log information between the last released version and the newly built version<br />
* Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanaganhttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Release_Process&diff=11288Yocto Project Release Process2013-09-30T17:30:30Z<p>Eflanagan: /* Release Matrix */</p>
<hr />
<div>== Yocto Linux Release Engineering Procedures ==<br />
<br />
This document describes release engineering procedures for the Yocto Linux project. <br />
<br />
== Yocto Project Naming Conventions ==<br />
<br />
Official/public releases will use the following scheme: '''M.m.p'''<br />
<br />
* M = major release number<br />
* m = minor release number<br />
* p = minor rev release number<br />
<br />
Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc. <br />
<br />
Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.<br />
<br />
Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.<br />
<br />
Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.<br />
<br />
=== Yocto Project Releases ===<br />
<br />
Yocto Project releases are known by their Major.Minor.patch number. For example:<br />
<br />
yocto-1.4.2<br />
<br />
The main download directory utilizes this naming convention.<br />
<br />
=== Poky Releases ===<br />
<br />
Poky is the reference distro the Yocto Project releases with each Yocto Project release. These releases are named releases (danny, dora, dylan, edison, etc.) as well as numbered utilizing Major.minor.patch numbering. <br />
<br />
=== Release Matrix ===<br />
<br />
{| style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
! align="left"| Yocto Project Release<br />
! Poky Name<br />
! Poky Release<br />
|-<br />
|1.5.x<br />
|dora<br />
|10.0.x<br />
|-<br />
|1.4.x<br />
|dylan<br />
|9.0.x<br />
|-<br />
|1.3.x<br />
|danny<br />
|8.0.x<br />
|}<br />
<br />
== Types of Releases ==<br />
<br />
==== Internal/Nightly Releases ====<br />
<br />
Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.<br />
<br />
==== Internal/QA Weekly Releases ====<br />
<br />
These releases are the basic unit of internal progress for the Yocto project.<br />
<br />
Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).<br />
<br />
If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.<br />
<br />
If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again. <br />
<br />
Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient. <br />
<br />
==== Milestone Releases ====<br />
<br />
These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.<br />
<br />
To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.<br />
<br />
After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.<br />
<br />
==== Point releases/Major Releases ====<br />
<br />
These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!<br />
<br />
== Release Components ==<br />
<br />
Yocto Linux includes a number of software components to be included in each release. These include:<br />
<br />
==== Distro Components ====<br />
<br />
* Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball<br />
* Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.<br />
<br />
==== SDK Components ====<br />
<br />
* meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]<br />
* Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc<br />
* SDK plugins for the following IDEs: Anjuta, Eclipse<br />
<br />
Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example). <br />
<br />
==== Other components ====<br />
<br />
* gitinfo - a file which includes information about which commit the images were built from<br />
* Changelog - a file which includes git log information between the last released version and the newly built version<br />
* Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version<br />
<br />
== Major/Point Release Procedures ==<br />
<br />
=== Release Readiness Review ===<br />
<br />
The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.<br />
<br />
=== Technical Release Procedures ===<br />
<br />
24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:<br />
<br />
* Move the release directory from a staging area into the public web server area<br />
* Push the web site update including new release information<br />
* Post the pre-written release announcement on the blog and mailing lists<br />
<br />
==== Steps to building a release for Yocto ====<br />
<br />
Prior to release build:<br />
* If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:<br />
- poky<br />
- meta-qt3<br />
- meta-intel<br />
- eclipse-plugin<br />
- meta-x32<br />
* Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf<br />
* Update handbook references to stable release (introduction.xml, master branch needs this too)<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.<br />
* If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number><br />
* Update MIRRORS to use the autobuilders source dir<br />
<br />
===== Checklist =====<br />
* Are docs within the release branch current and correct?<br />
* Is the tarball location within the release branch correct?<br />
* Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?<br />
* Have we branched/tagged poky/meta-intel/meta-qt3 etc?<br />
* Do the mirrors work?<br />
<br />
==== Steps to release Yocto ====<br />
<br />
Once a release candidate has been validated as a GO:<br />
* git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.<br />
* git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.<br />
* Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable<br />
* Remove all timestamp images from machines/*<br />
* For final release, copy DL_DIR to yocto_M.m/sources<br />
* Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.<br />
* Create the ADT repo using the ipk directory<br />
* Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version<br />
* create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m><br />
* gpg sign the md5sum table<br />
* create release notes<br />
* verify new handbook as been published<br />
* Set release directory to world readable. Verify release access.<br />
* Post release announcement on Blog <br />
* Post release announcement on mailing list<br />
<br />
On master branch:<br />
* Set DISTRO_VERSION in poky.conf to new version<br />
* Update version reference and updated date in handbook (poky-handbook.xml)<br />
* cd handbook<br />
* make<br />
* scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/<br />
* scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/<br />
(or copy across by hand when remotely connected to machine?)<br />
* Edit web pages (website is controlled from a git repo) <br />
**support/index.php<br />
**getit/index.php<br />
**index.php<br />
**poky-wp-theme/common-funcs.inc<br />
**poky-wp-theme/front-page.php</div>Eflanagan