Tracking FreeBSD Development Branches
I "track" FreeBSD development branches (stable/9 and head,
currently) on each of a couple of personal machines -- a laptop and
a "build machine" -- on a daily basis. Please look here for information on the process I use for
this and here for a historical record.
I plan to update this page for each update of the machines, with
the most recent entry at the top. (Note that I've been doing this for
a few years before starting this page.)
Branch
|
buildworld
|
buildkernel
|
installkernel
|
installworld
|
boot/smoke test
|
Revision |
Date
|
Notes
|
stable/9 | OK | OK[2] | OK | OK | OK | r248858M/248873 | 29 Mar 2013 | 9.1-STABLE |
head | OK |
OK[2] | OK | OK | OK[1] | r248872M/248873 | 29 Mar
2013 | 10.0-CURRENT |
Note: The form of the information in the
"Revision" column is r branch_GRN flag /
repository_GRN, where:
- r
- is a literal "r" (for "revision").
- branch_GRN
- is the GRN of the newest commit to the
branch at the time of the most recent "svn update" of the working
copy prior to the build.
- flag
- is
optional; if there is no flag, the source tree has not been modified;
a flag of "M" indicates that it has been modified. See output
of "svnversion --help" for more details.
- /
- is
a literal "/".
- repository_GRN
- is the GRN of the newest commit to the repository at the
time of the most recent "svn update" of the working copy prior to
the build,
- As is usual for my systems
that run multiple versions of FreeBSD but share a common /usr/local,
I build the ports (other than any applicable misc/compatNx ports)
under the oldest version of FreeBSD I run, and use the misc/compatNx
ports to handle older versions of libraries. In the case of
the (new) laptop, I found that (at minimum) sudo and apache needed
libutil.so.8 and libz.so.5, which are not provided in FreeBSD
10.0-CURRENT (as they had been replaced by libutil.so.9 and libz.so.6,
respectively). And since FreeBSD 10.0-CURRENT has (obviously!)
not been RELEASEd, there is no misc/compat9x port available.
Accordingly, I copied the needed libraries from the stable/8 slice
to /usr/lib/compat on the "head" slice, and each of sudo and apache
work under head now.
- src/sys/conf/newvers.sh has
been subjected to a variety of changes over the years, some of which
were in support of various VCSen that folks used to maintain the
sources. The most recent official change was to address a
concern I had raised: the then-current version of newvers.sh made
a determination as to whether or not the VCS in question was
subversion by looking for a .svn (sub)directory in the system sources
directory. This worked, through subversion-1.6; as of
subversion-1.7, Subversion only has a .svn (sub)directory at the
top level of the working copy; in the default case, that would be
/usr/src -- and not /usr/src/sys. As
a result, newvers.sh failed to augment the version information with
the working copy's GRN. I filed a PR, along with a patch,
suggesting that instead of looking for ${SYSDIR}/.svn, that the svn
stanza might follow the pattern used by git and look in ${SYSDIR}/../
-- though I pointed out in the commentary that I believed that the
ideal approach would be to make sys/conf/newvers.sh completely
VCS-agnostic, e.g., by using an external (shell) function to retrieve
the information wanted. (This last was a repeat of an idea I
had suggested a year or two ago, probably in -hackers@.) I
believe I had one positive response -- and several howls of anguish,
claiming that the proposal would break the way certain committers
do things. Finally, Doug Barton (formerly dbarton@freebsd.org)
wrote some code to implement an alternative approach, and committed
that change (to head). As that addressed my primary concern
(getting the working copy's GRN into the version string even if
subversion-1.7 was being used), I requested closure of my PR, and
adopted Doug's change. After about 16 days, I sent a note to
re@ & Doug, suggesting that it was time to MFC that change.
Doug agreed, and a few days later, did so. Then someone (else)
posted to -current@, claiming that the change broke
his approach to VCS. Given that, I
finally got around to writing some code to implement my idea of a
VCS-agnostic newvers.sh. And that is why my
GRN has an "M" at the end for head. [ARRGH!
avg@ did it again, in r234210 on stable/8 and r234209 in stable/9.
Blecch.]
Note that the "uname GRN" doesn't always change
even though the "make buildworld" was done: the uname GRN only
tracks the kernel sources, so a userland-only change doesn't change
it. To compesate for that, the "Source GRN" should reflect
the latest commit to the src repository that could have affected
the /usr/src workig copy. I am also using "Repository GRN"
to indicate the last commit to the src repository when my source
working copy was last updated.
Note that I am using clang as the
FreeBSD "system compiler" for both stable/9 and head.
I
have resumed updating installed ports on a regular (usually, daily)
basis. Also, as of 14 Jul 2012, the FreeBSD CVS ports repository
is a generated file: the master ports repo is SVN.
I
am now using the "highly experimental" tmpfs(5) for /tmp on the
branches of FreeBSD that I am tracking, instead of a swap-backed
md(4) device. No problems so far. (As of 11 Apr 2010,
I am now also using it on my home "firewall" machine -- in
production.) I am using tmpfs for /tmp on my desktop
at work (dwolf-bsd), as well.
I am using Perl 5.14.2_3.
Firefox (on my laptop) is now firefox-19.0.2,1, and Flash
works, as does Java -- though I needed to turn off the PGO configuration
option in order to build Firefox. (For firefox-19.x, which
defaults to building with clang, I needed to force the use
of gcc; apparently clang-3.2 is OK, but 3.1 is not.) I also
built & installed the ports/x11/nvidia-driver port, so accelerated
2-D graphics is working, though in order to avoid some odd
changes in font sizes for some applications, I needed to lie to X11
about the dimensions of the laptop's screen: it turns out that using
the nv driver, the screen was detected at 508x317mm, vs. the actual
330x210mm. Also, I added x11/nvidia-driver to the
definition of PORTS_MODULES in /etc/src.conf, but I find that
nvidia.ko is not always loaded successfully from FreeBSD 9.x &
10.x -- and sometimes it is. [Note 12 Jan 2012: I think I've
resolved this: if the port working directory is cleaned before the
build, things seem OK.] [Note 31 Aug 2012: For reasons that are not
yet clear to me, this whole business of specifying PORTS_MODULES
is /etc/src.conf came crashing down -- for stable/8, stable/9, and
head. I ended up running "portmaster graphics/libGL
x11/nvidia-driver" for each branch, then (finally) booting stable/8
in single-user mode and running it again. So far, things seem
OK.]
The version of SVN I use is subversion-1.7.7,1
[r1393599] (from ports, with FreeBSD.org options selected),
last built 11 Dec 2012.
I will plan on updating this document
often.