Source string Read only

(itstool) path: sect2/screen

400/4000
Context English State
The per-build configuration file naming scheme is in the form of <filename>${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf</filename>, where the uppercase variables are equivalent to what <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> uses in the build system, and lowercase variables are set within the configuration files, mapping to the major version of the respective branch.
Each branch also has its own <filename>builds-X.conf</filename> configuration, which is used by <filename>thermite.sh</filename>. The <filename>thermite.sh</filename> script iterates through each ${revision}, ${TARGET_ARCH}, ${KERNCONF}, and ${type} value, creating a master list of what to build. However, a given combination from the list will only be built if the respective configuration file exists, which is where the naming scheme above is relevant.
There are two paths of file sourcing:
<filename>builds-<replaceable>12</replaceable>.conf</filename> -&gt; <filename>main.conf</filename>
This controls <filename>thermite.sh</filename> behavior
<filename><replaceable>12</replaceable>-<replaceable>amd64</replaceable>-<replaceable>GENERIC</replaceable>-<replaceable>snap</replaceable>.conf</filename> -&gt; <filename>defaults-<replaceable>12</replaceable>.conf</filename> -&gt; <filename>main.conf</filename>
This controls <filename>release/release.sh</filename> behavior within the build <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>8</manvolnum></citerefentry>
The <filename>builds-<replaceable>12</replaceable>.conf</filename>, <filename>defaults-<replaceable>12</replaceable>.conf</filename>, and <filename>main.conf</filename> configuration files exist to reduce repetition between the various per-build files.
Building FreeBSD Development Snapshots
The official release build machines have a specific filesystem layout, which using <acronym>ZFS</acronym>, <filename>thermite.sh</filename> takes heavy advantage of with clones and snapshots, ensuring a pristine build environment.
The build scripts reside in <filename class="directory">/releng/scripts-snapshot/scripts</filename> or <filename class="directory">/releng/scripts-release/scripts</filename> respectively, to avoid collisions between an <literal>RC</literal> build from a releng branch versus a <literal>STABLE</literal> snapshot from the respective stable branch.
A separate dataset exists for the final build images, <filename class="directory">/snap/ftp</filename>. This directory contains both snapshots and releases directories. They are only used if the <literal>EVERYTHINGISFINE</literal> variable is defined in <filename>main.conf</filename>.
The <literal>EVERYTHINGISFINE</literal> variable name was chosen to avoid colliding with a variable that might be possibly set in the user environment, accidentally enabling the behavior that depends on it being defined.
As <filename>thermite.sh</filename> iterates through the master list of combinations and locates the per-build configuration file, a <acronym>ZFS</acronym> dataset is created under <filename class="directory">/releng</filename>, such as <filename class="directory">/releng/12-amd64-GENERIC-snap</filename>. The <literal>src/</literal>, <literal>ports/</literal>, and <literal>doc/</literal> trees are checked out to separate <acronym>ZFS</acronym> datasets, such as <filename class="directory">/releng/12-src-snap</filename>, which are then cloned and mounted into the respective build datasets. This is done to avoid checking out a given tree more than once.
Assuming these filesystem paths, <filename>thermite.sh</filename> would be invoked as:
<prompt>#</prompt> <userinput>cd /releng/scripts-snapshot/scripts</userinput>
<prompt>#</prompt> <userinput>./setrev.sh -b <literal>stable/<replaceable>12</replaceable>/</literal></userinput>
<prompt>#</prompt> <userinput>./zfs-cleanup.sh -c ./builds-<replaceable>12</replaceable>.conf</userinput>
<prompt>#</prompt> <userinput>./thermite.sh -c ./builds-<replaceable>12</replaceable>.conf</userinput>
Once the builds have completed, additional helper scripts are available to generate development snapshot emails which are sent to the <literal>freebsd-snapshots@freebsd.org</literal> mailing list:
<prompt>#</prompt> <userinput>cd /releng/scripts-snapshot/scripts</userinput>
<prompt>#</prompt> <userinput>./get-checksums.sh -c ./builds-<replaceable>12</replaceable>.conf | ./generate-email.pl &gt; snapshot-<replaceable>12</replaceable>-mail</userinput>
The generated output should be double-checked for correctness, and the email itself should be PGP signed, in-line.
These helper scripts only apply to development snapshot builds. Announcements during the release cycle (excluding the final release announcement) are created from an email template. A sample of the email template currently used can be found <link xlink:href="https://svn.freebsd.org/base/user/gjb/thermite/non-release-template-mail.txt">here</link>.
Building FreeBSD Releases
Similar to building FreeBSD development snapshots, <filename>thermite.sh</filename> would be invoked the same way. The difference between development snapshots and release builds, <literal>BETA</literal> and <literal>RC</literal> included, is that the <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>8</manvolnum></citerefentry> configuration files must be named with <literal>release</literal> instead of <literal>snap</literal> as the "type", as mentioned above.
In addition, the <literal>BUILDTYPE</literal> and <literal>types</literal> must be changed from <literal>snap</literal> to <literal>release</literal> in <filename>defaults-<replaceable>12</replaceable>.conf</filename> and <filename>builds-<replaceable>12</replaceable>.conf</filename>, respectively.
When building <literal>BETA</literal>, <literal>RC</literal>, and the final <literal>RELEASE</literal>, also statically set <literal>BUILDSVNREV</literal> to the revision on the branch reflecting the name change, <literal>BUILDDATE</literal> to the date the builds are started in <literal>YYYYMMDD</literal> format. If the <literal>doc/</literal> and <literal>ports/</literal> trees have been tagged, also set <literal>PORTBRANCH</literal> and <literal>DOCBRANCH</literal> to the relevant tag path in the Subversion repository, replacing <literal>HEAD</literal> with the last changed revision. Also set <literal>releasesrc</literal> in <filename>builds-<replaceable>12</replaceable>.conf</filename> to the relevant branch, such as <literal>stable/<replaceable>12</replaceable>/</literal> or <literal>releng/<replaceable>12.0</replaceable>/</literal>.
During the release cycle, a copy of <filename>CHECKSUM.SHA512</filename> and <filename>CHECKSUM.SHA256</filename> for each architecture are stored in the FreeBSD Release Engineering Team internal repository in addition to being included in the various announcement emails. Each <filename>MANIFEST</filename> containing the hashes of <filename>base.txz</filename>, <filename>kernel.txz</filename>, etc. are added to <package>misc/freebsd-release-manifests</package> in the Ports Collection, as well.
In preparation for the release build, several files need to be updated:
Update the <varname>BRANCH</varname> value to <literal>RELEASE</literal>
<filename>UPDATING</filename>
Add the anticipated announcement date
<filename>lib/csu/common/crtbrand.c</filename>
Replace <literal>__FreeBSD_version</literal> with the value in <filename>sys/sys/param.h</filename>

Loading…

User avatar None

New source string

FreeBSD Doc / articles_freebsd-relengEnglish

New source string 7 months ago
Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment

(itstool) path: sect2/screen

Flags
no-wrap, read-only
Source string location
article.translate.xml:1301
String age
7 months ago
Source string age
7 months ago
Translation file
articles/freebsd-releng.pot, string 256