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/9OKOK[2]OKOKOKr248858M/24887329 Mar 20139.1-STABLE
head

OK

OK[2]OKOK

OK[1]

r248872M/24887329 Mar  201310.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,

 

  1. 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.
  2. 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.