From owner-svn-doc-all@FreeBSD.ORG  Tue Jan 13 02:40:18 2015
Return-Path: <owner-svn-doc-all@FreeBSD.ORG>
Delivered-To: svn-doc-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 4B1D749D;
 Tue, 13 Jan 2015 02:40:18 +0000 (UTC)
Received: from svn.freebsd.org (svn.freebsd.org
 [IPv6:2001:1900:2254:2068::e6a:0])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 32D262EE;
 Tue, 13 Jan 2015 02:40:18 +0000 (UTC)
Received: from svn.freebsd.org ([127.0.1.70])
 by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id t0D2eI1q093176;
 Tue, 13 Jan 2015 02:40:18 GMT (envelope-from wblock@FreeBSD.org)
Received: (from wblock@localhost)
 by svn.freebsd.org (8.14.9/8.14.9/Submit) id t0D2eISI093175;
 Tue, 13 Jan 2015 02:40:18 GMT (envelope-from wblock@FreeBSD.org)
Message-Id: <201501130240.t0D2eISI093175@svn.freebsd.org>
X-Authentication-Warning: svn.freebsd.org: wblock set sender to
 wblock@FreeBSD.org using -f
From: Warren Block <wblock@FreeBSD.org>
Date: Tue, 13 Jan 2015 02:40:18 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
 svn-doc-head@freebsd.org
Subject: svn commit: r46196 - head/en_US.ISO8859-1/htdocs/news/status
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: svn-doc-all@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "SVN commit messages for the entire doc trees \(except for &quot;
 user&quot; , &quot; projects&quot; , and &quot; translations&quot;
 \)" <svn-doc-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-doc-all>,
 <mailto:svn-doc-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-doc-all/>
List-Post: <mailto:svn-doc-all@freebsd.org>
List-Help: <mailto:svn-doc-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-doc-all>,
 <mailto:svn-doc-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jan 2015 02:40:18 -0000

Author: wblock
Date: Tue Jan 13 02:40:17 2015
New Revision: 46196
URL: https://svnweb.freebsd.org/changeset/doc/46196

Log:
  Whitespace-only fixes, translators please ignore.

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2014-10-2014-12.xml

Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2014-10-2014-12.xml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2014-10-2014-12.xml	Tue Jan 13 01:51:36 2015	(r46195)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2014-10-2014-12.xml	Tue Jan 13 02:40:17 2015	(r46196)
@@ -16,28 +16,30 @@
     <title>Introduction</title>
 
 <!-- <?ignore -->
-    <p><strong>This is a draft of the October&ndash;December 2014 status
-	report.	 Please check back after it is finalized, and an
-	announcement email is sent to the &os;-Announce mailing
-	list.</strong></p>
+    <p><strong>This is a draft of the October&ndash;December 2014
+      status report.  Please check back after it is finalized, and
+      an announcement email is sent to the &os;-Announce mailing
+      list.</strong></p>
 <!-- ?> -->
 
     <p>This report covers &os;-related projects between October and
       December 2014.  This is the last of four reports planned for
       2014.</p>
 
-    <p>The fourth quarter of 2014 included a number of significant improvements to the &os;
-      system.  In particular, compatibility with other systems was enhanced.  This included
-      significant improvements to the Linux compatibility layer, used to
-      run Linux binaries on &os;, and the port of WINE, used to run Windows
-      applications.  Hypervisor support improved, with &os; gaining the ability
-      to run as domain 0 on Xen's new high-performance PVH mode, bhyve gaining
-      AMD support, and new tools for creating &os; VM images arriving.</p>
-
-    <p>This quarter was also an active time for the toolchain, with numerous
-	improvements to the compiler, debugger, and other components, including
-	initial support for C++14, which should be complete by
-	&os;&nbsp;10.2.</p>
+    <p>The fourth quarter of 2014 included a number of significant
+      improvements to the &os; system.  In particular, compatibility
+      with other systems was enhanced.  This included significant
+      improvements to the Linux compatibility layer, used to run Linux
+      binaries on &os;, and the port of WINE, used to run Windows
+      applications.  Hypervisor support improved, with &os; gaining
+      the ability to run as domain 0 on Xen's new high-performance PVH
+      mode, bhyve gaining AMD support, and new tools for creating &os;
+      VM images arriving.</p>
+
+    <p>This quarter was also an active time for the toolchain, with
+      numerous improvements to the compiler, debugger, and other
+      components, including initial support for C++14, which should be
+      complete by &os;&nbsp;10.2.</p>
 
     <p>Thanks to all the reporters for the excellent work!</p>
 
@@ -105,17 +107,18 @@
 
     <body>
       <p>With funding from the &os; Foundation, the &os; forums
-	were migrated to the XenForo software.  The new software is far more
-	capable and easy to use.  While the entire forum team
-	contributed, &a.danger; did an excellent job
-	importing existing users and messages and bringing back the
-	often-requested "Thanks" feature.  The upgrade was completed in
-	time to be ready for the influx of new users from the release of
-	&os; 10.1, and we have already seen an increase in usage.</p>
+	were migrated to the XenForo software.  The new software is
+	far more capable and easy to use.  While the entire forum team
+	contributed, &a.danger; did an excellent job importing
+	existing users and messages and bringing back the
+	often-requested "Thanks" feature.  The upgrade was completed
+	in time to be ready for the influx of new users from the
+	release of &os; 10.1, and we have already seen an increase in
+	usage.</p>
 
       <p>Developers with an @FreeBSD.org address can contact forum
-	administrators to obtain the highly-desired "@"	suffix on their
-	forum user name along with a Developer flag.</p>
+	administrators to obtain the highly-desired "@" suffix on
+	their forum user name along with a Developer flag.</p>
 
       <p>We want to thank the Foundation for making this possible, and
 	the users for their patience and continued presence on the
@@ -128,7 +131,8 @@
 
     <help>
       <task>
- 	<p>Encourage more developers and users to try the new forums.</p>
+	<p>Encourage more developers and users to try the new
+	  forums.</p>
       </task>
 
       <task>
@@ -149,6 +153,7 @@
 	</name>
 	<email>kib@FreeBSD.org</email>
       </person>
+
       <person>
 	<name>
 	  <given>Peter</given>
@@ -163,49 +168,47 @@
 	management last quarter.</p>
     <!-- This needs some markup from someone with more docbook-fu than me -->
 
-      <p>The Reaper facility was added, allowing a process to reliably track the
-	running and exiting state of the whole subtree of the processes.
-	It is intended to improve tools like timeout(1) or
-	poudriere, by making it impossible for the runaway grandchild to
-	escape the controlling process.  The feature was designed based on
-	similar facilities in DragonFlyBSD and Linux, with some
-	references to Solaris contracts.  Committed to HEAD in
-	r275800.</p>
-
-      <p>The FreeBSD suspension code does not
-	ensure that the system, both software and hardware,
-	is in a steady and consistent state.  One aspect is 
-	usermode process activity, which is not yet stopped, continuing to
-	making requests to the hardware.  It is not realistic to expect
-	drivers to be able to correctly handle the calls after
-	SUSPEND_CHILD.</p>
-
-      <p>We developed a facility to stop
-	usermode threads at safe points, where they are known to not
-	own and to not wait for kernel resources, in particular, not
-	waiting for device requests finishing.  It is based on the
-	existing single-threading code, but extending it to allow external
-	thread to put some processes into stopped state.  Also, a facility
-	to sync filesystems before suspend was added, to ensure that
-	consistent metadata and as much as possible of the cached user
-	data are on stable storage, to minimize damage of failed
-	resume.</p>
+      <p>The Reaper facility was added, allowing a process to reliably
+	track the running and exiting state of the whole subtree of
+	the processes.  It is intended to improve tools like
+	timeout(1) or poudriere, by making it impossible for the
+	runaway grandchild to escape the controlling process.  The
+	feature was designed based on similar facilities in
+	DragonFlyBSD and Linux, with some references to Solaris
+	contracts.  Committed to HEAD in r275800.</p>
+
+      <p>The FreeBSD suspension code does not ensure that the system,
+	both software and hardware, is in a steady and consistent
+	state.  One aspect is usermode process activity, which is not
+	yet stopped, continuing to making requests to the hardware.
+	It is not realistic to expect drivers to be able to correctly
+	handle the calls after SUSPEND_CHILD.</p>
+
+      <p>We developed a facility to stop usermode threads at safe
+	points, where they are known to not own and to not wait for
+	kernel resources, in particular, not waiting for device
+	requests finishing.  It is based on the existing
+	single-threading code, but extending it to allow external
+	thread to put some processes into stopped state.  Also, a
+	facility to sync filesystems before suspend was added, to
+	ensure that consistent metadata and as much as possible of the
+	cached user data are on stable storage, to minimize damage of
+	failed resume.</p>
 
       <p>The code stressed some parts of the system and has led to
-	discovery of a number of bugs in different areas,
-	including process management, buffer cache, and syscall
-	handlers.  The bugs were fixed, and the fixes and features commmitted
-	by a series culminating in r275745.</p>
-
-      <p>During the work described above, it
-	was noted that process spinlock duties are significantly
-	overloaded (the same is true for the process lock).  The spinlock
-	was split into per-feature locks in r275121.  As result, it
-	was also possible to eliminate recursion on it in r275372.</p>
+	discovery of a number of bugs in different areas, including
+	process management, buffer cache, and syscall handlers.  The
+	bugs were fixed, and the fixes and features commmitted by a
+	series culminating in r275745.</p>
+
+      <p>During the work described above, it was noted that process
+	spinlock duties are significantly overloaded (the same is true
+	for the process lock).  The spinlock was split into
+	per-feature locks in r275121.  As result, it was also possible
+	to eliminate recursion on it in r275372.</p>
     </body>
 
     <sponsor>The FreeBSD Foundation</sponsor>
-
   </project>
 
   <project cat='proj'>
@@ -227,7 +230,8 @@
 
     <body>
       <p>Most system features work, including keyboard, WiFi, sound,
-	VESA graphics, touchpad, USB and decent battery life (5 to 6 hours).</p>
+	VESA graphics, touchpad, USB and decent battery life (5 to 6
+	hours).</p>
     </body>
 
     <help>
@@ -264,16 +268,16 @@
 	Vagrant images to run on VMware and VirtualBox.</p>
 
       <p><a href="https://www.packer.io/">Packer</a> is a tool for
-	creating identical machine images for multiple platforms from a
-	single source configuration.</p>
+	creating identical machine images for multiple platforms from
+	a single source configuration.</p>
 
       <p><a href="https://www.vagrantup.com/">Vagrant</a> is a tool to
 	create and configure lightweight, reproducible, and portable
 	development environments.</p>
 
-      <p>To get started, clone the Git repo and follow the directions in
-	the README.  More information is available from the Packer and
-	Vagrant websites.</p>
+      <p>To get started, clone the Git repo and follow the directions
+	in the README.  More information is available from the Packer
+	and Vagrant websites.</p>
     </body>
   </project>
 
@@ -293,24 +297,30 @@
     </links>
 
     <body>
-      <p>The package development team has released <tt>pkg(8)</tt> 1.4.
-	This release fixes lots of bugs and adds some new features:
+      <p>The package development team has released <tt>pkg(8)</tt>
+	1.4.  This release fixes lots of bugs and adds some new
+	features:
 	<ul>
 	  <li>Stricter checking of the path passed via the plist</li>
+
 	  <li>Change in the ABI to be closer to MACHINE_ARCH</li>
+
 	  <li>Add three-way merge functionality</li>
-	  <li>Add conservative upgrade support for multi repository configurations</li>
+
+	  <li>Add conservative upgrade support for multi repository
+	    configurations</li>
+
 	  <li>Multirepository priority</li>
 	</ul>
       </p>
 
       <p>An important part of the development direction for the 1.4
-	release was stabilizing the existing features and
-	improving the <tt>pkg(8)</tt> experience on small/embedded
-	machines (reducing memory usage and speeding up operations).</p>
+	release was stabilizing the existing features and improving
+	the <tt>pkg(8)</tt> experience on small/embedded machines
+	(reducing memory usage and speeding up operations).</p>
 
-      <p><tt>pkg(8)</tt> is not only the &os; Package Manager, but also the
-	Package Manager for DragonflyBSD.  Support has been
+      <p><tt>pkg(8)</tt> is not only the &os; Package Manager, but
+	also the Package Manager for DragonflyBSD.  Support has been
 	added to build <tt>pkg(8)</tt> on OS X and Linux.  This work
 	will allow other Operating Systems the option of adopting
 	<tt>pkg(8)</tt> to manage their packages and bring new
@@ -321,18 +331,23 @@
       <task>
 	<p>Add more regression tests.</p>
       </task>
+
       <task>
 	<p>Package FreeBSD base.</p>
       </task>
+
       <task>
 	<p>Allow using mtree as a plist when creating a package.</p>
       </task>
+
       <task>
 	<p>Implement flexible dependencies.</p>
       </task>
+
       <task>
 	<p>Test the development branch.</p>
       </task>
+
       <task>
 	<p>More developers are needed, check the Issues on Github.</p>
       </task>
@@ -350,6 +365,7 @@
 	</name>
 	<email>bapt@FreeBSD.org</email>
       </person>
+
       <person>
 	<name>
 	  <given>Ulrich</given>
@@ -357,6 +373,7 @@
 	</name>
 	<email>uqs@FreeBSD.org</email>
       </person>
+
       <person>
 	<name>
 	  <given>The Documentation Team</given>
@@ -374,25 +391,25 @@
 	formatter on HEAD -- man(1) will use <tt>mandoc(1)</tt> to
 	format manual pages by default, then fall back to
 	<tt>groff(1)</tt> if it fails.</p>
- 
+
       <p>This change also fixes an issue with the &os; <tt>man(1)</tt>
-	command not being able to properly deal with ".so" in gzipped manual
-	pages.</p>
- 
+	command not being able to properly deal with ".so" in gzipped
+	manual pages.</p>
+
       <p>The documentation team has spent a lot of time fixing issues
-	reported by <tt>mdoc(7)</tt> in the FreeBSD manual pages.  This
-	greatly improves the quality of our manual pages.</p>
- 
-      <p>Most manual pages with remaining issues are from contrib/, for
-	which changes should be reported and fixed upstream.</p>
- 
-      <p>The "manlint" target has also been switched to use <tt>mandoc
-	-Tlint</tt>, which results in the target being more useful
-	when working on manual pages.</p>
- 
+	reported by <tt>mdoc(7)</tt> in the FreeBSD manual pages.
+	This greatly improves the quality of our manual pages.</p>
+
+      <p>Most manual pages with remaining issues are from contrib/,
+	for which changes should be reported and fixed upstream.</p>
+
+      <p>The "manlint" target has also been switched to use
+	<tt>mandoc -Tlint</tt>, which results in the target being more
+	useful when working on manual pages.</p>
+
       <p>Some <tt>groff(1)</tt> versus <tt>mandoc(1)</tt> formatting
-	differences have been spotted and reported to mandoc's upstream
-	developers.</p>
+	differences have been spotted and reported to mandoc's
+	upstream developers.</p>
     </body>
 
     <help>
@@ -422,6 +439,7 @@
 	</name>
 	<email>bapt@FreeBSD.org</email>
       </person>
+
       <person>
 	<name>
 	  <given>Warner</given>
@@ -429,6 +447,7 @@
 	</name>
 	<email>imp@FreeBSD.org</email>
       </person>
+
       <person>
 	<name>
 	  <given>Brooks</given>
@@ -444,49 +463,57 @@
 
     <body>
       <p>The main goal of the external toolchain project is to be able
-	to build world and kernel with non-default toolchain.  It can be
-	helpful to:
+	to build world and kernel with non-default toolchain.  It can
+	be helpful to:
 	<ul>
-	  <li>Prepare a migration to a newer version of toolchain components.</li>
+	  <li>Prepare a migration to a newer version of toolchain
+	    components.</li>
+
 	  <li>Port &os; to a new architecture</li>
-	  <li>Upgrade from a &os; that ships with GCC 4.2 to a version that ships with clang 3.5+ (which needs a more modern toolchain than GCC 4.2 to bootstrap).</li>
+
+	  <li>Upgrade from a &os; that ships with GCC 4.2 to a version
+	    that ships with clang 3.5+ (which needs a more modern
+	    toolchain than GCC 4.2 to bootstrap).</li>
 	</ul>
       </p>
 
-      <p>The initial external toolchain work only supported
-	clang.  It has been extended to support recent GCC (4.9.1 has
-	been tested) and recent binutils (2.24 and 2.25).</p>
-
-      <p>A large number of fixes have been committed to HEAD to support
-	incompatible behaviour changes between <tt>ld(1)</tt> from
-	binutils 2.17.50 (the version in base) and binutils 2.24+.</p>
-
-      <p>A large number of warnings have been deactivated when building
-	the kernel to make sure it is possible to build the kernel with
-	recent GCC (first 4.6 and then 4.9.1)</p>
+      <p>The initial external toolchain work only supported clang.  It
+	has been extended to support recent GCC (4.9.1 has been
+	tested) and recent binutils (2.24 and 2.25).</p>
+
+      <p>A large number of fixes have been committed to HEAD to
+	support incompatible behaviour changes between <tt>ld(1)</tt>
+	from binutils 2.17.50 (the version in base) and binutils
+	2.24+.</p>
+
+      <p>A large number of warnings have been deactivated when
+	building the kernel to make sure it is possible to build the
+	kernel with recent GCC (first 4.6 and then 4.9.1)</p>
 
       <p>The build system has been changed to build libc++ as the C++
-	standard library implementation when a recent enough GCC (4.6+) is used to build world.
-	</p>
+	standard library implementation when a recent enough GCC
+	(4.6+) is used to build world.</p>
 
       <p>To simplify using an external toolchain, the following
 	pre-seeded configurations have been added to the ports tree:
 	<ul>
 	  <li>amd64-xtoolchain-gcc</li>
+
 	  <li>powerpc64-xtoolchain-gcc</li>
+
 	  <li>sparc64-xtoolchain-gcc</li>
 	</ul>
       </p>
 
       <p>Those packages will depend on special versions of GCC
 	(minimalistic cross-built ready GCC) and on binutils.  To use
-	them, run: <tt>make CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc
-	TARGET_ARCH=powerpc64</tt></p>
+	them, run: <tt>make CROSS_TOOLCHAIN=powerpc64-gcc
+	  TARGET=powerpc TARGET_ARCH=powerpc64</tt></p>
 
       <p>As a result of this effort, it has been possible to
 	successfully build and run a kernel and world built with GCC
-	4.9.1 and binutils 2.24 on sparc64, amd64 (with minor tweaks for
-	amd64), powerpc and powerpc64.</p>
+	4.9.1 and binutils 2.24 on sparc64, amd64 (with minor tweaks
+	for amd64), powerpc and powerpc64.</p>
     </body>
 
     <help>
@@ -494,9 +521,12 @@
 	<p>Patch and upstream GCC 4.9 to support &os; mips, arm and
 	aarch64.</p>
       </task>
+
       <task>
-	<p>Adapt and upstream the aarch64 patches for binutils 2.25.</p>
+	<p>Adapt and upstream the aarch64 patches for binutils
+	  2.25.</p>
       </task>
+
       <task>
 	<p>Add more pre-seeded configurations.</p>
       </task>
@@ -518,10 +548,9 @@
 
     <body>
       <p>Since 2006, initial support for Linux timer function
-	compatibility support was present but untested.
-	This update corrects the initial implementation and makes it
-	available to the 32-bit Linuxulator on amd64, not just on i386.
-      </p>
+	compatibility support was present but untested.  This update
+	corrects the initial implementation and makes it available to
+	the 32-bit Linuxulator on amd64, not just on i386.</p>
 
       <p>Starting with &os; 10.1, this enables users to run another
 	FPGA high-level synthesis toolchain and emulation platform
@@ -530,6 +559,7 @@
     </body>
 
     <sponsor>DARPA</sponsor>
+
     <sponsor>AFRL</sponsor>
 
   </project>
@@ -551,32 +581,32 @@
     </links>
 
     <body>
-      <p>The &os; GNOME Team maintains the GNOME, MATE, and CINNAMON desktop
-	environments and graphical user interfaces for &os;. GNOME 3 is part
-	of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON
-	is a desktop environment using GNOME 3 technologies but with a GNOME 2
-	look and feel.</p>
-
-      <p>This quarter was an exciting time for the GNOME Team. We imported
-	GNOME 3.14.0 and CINNAMON 2.2.16 into the ports tree. At the same
-	time, we removed the old GNOME 2.32 desktop. And two weeks later
-	we updated GNOME to 3.14.2 and CINNAMON to 2.4.2, which was collected
-	while the preparation for the initial GNOME 3.14.0 import was
-	under way.</p>
-
-      <p>We moved our development repo to GitHub. 
-	The repo is structured as follows: the <tt>master</tt> branch
-	is vanilla &os; Ports, and we have <tt>theme branches</tt> for topics
-	such as the porting of MATE 1.9 (mate-1.10 branch) and GNOME 3.15
-	(gnome-3.16 branch). The GNOME 3.14 branch (gnome-3.14) is not
-	used or updated any more because the content has been committed to
-	ports, but is kept around for the history.</p>
+      <p>The &os; GNOME Team maintains the GNOME, MATE, and CINNAMON
+	desktop environments and graphical user interfaces for &os;.
+	GNOME 3 is part of the GNU Project.  MATE is a fork of the
+	GNOME 2 desktop.  CINNAMON is a desktop environment using
+	GNOME 3 technologies but with a GNOME 2 look and feel.</p>
+
+      <p>This quarter was an exciting time for the GNOME Team.  We
+	imported GNOME 3.14.0 and CINNAMON 2.2.16 into the ports tree.
+	At the same time, we removed the old GNOME 2.32 desktop.  And
+	two weeks later we updated GNOME to 3.14.2 and CINNAMON to
+	2.4.2, which was collected while the preparation for the
+	initial GNOME 3.14.0 import was under way.</p>
+
+      <p>We moved our development repo to GitHub.  The repo is
+	structured as follows: the <tt>master</tt> branch is vanilla
+	&os; Ports, and we have <tt>theme branches</tt> for topics
+	such as the porting of MATE 1.9 (mate-1.10 branch) and GNOME
+	3.15 (gnome-3.16 branch).  The GNOME 3.14 branch (gnome-3.14)
+	is not used or updated any more because the content has been
+	committed to ports, but is kept around for the history.</p>
     </body>
 
     <help>
       <task>
-	<p>The GNOME website is stale. Work is starting on updating
-	  the development section. We could use some help here.</p>
+	<p>The GNOME website is stale.  Work is starting on updating
+	  the development section.  We could use some help here.</p>
       </task>
 
       <task>
@@ -603,15 +633,15 @@
 
     <body>
       <p>The &os; Core Team constitutes the project's "Board of
-	Directors", responsible for deciding the project's overall goals
-	and direction as well as managing specific areas of the &os;
-	project landscape.</p>
+	Directors", responsible for deciding the project's overall
+	goals and direction as well as managing specific areas of the
+	&os; project landscape.</p>
 
       <p>During the fourth quarter of 2014, the &os; Core team saw the
 	culmination of a long-running project to rebuild the &os;
-	Forums.  The chosen solution was to license XenForo; core would
-	like to thank the FreeBSD Foundation for paying the licensing
-	costs of this software.</p>
+	Forums.  The chosen solution was to license XenForo; core
+	would like to thank the FreeBSD Foundation for paying the
+	licensing costs of this software.</p>
 
       <p>Much discussion ensued concerning the "New Support Model"
 	following Core's meeting at EuroBSDCon in September.  It was
@@ -620,9 +650,9 @@
 	at 11.0-RELEASE.</p>
 
       <p>In order to ensure that 10.1-RELEASE shipped with support for
-	up-to-date X Windows and KDE4, core approved the switch to 'new
-	Xorg' as the default in time for building the packages for that
-	release.</p>
+	up-to-date X Windows and KDE4, core approved the switch to
+	'new Xorg' as the default in time for building the packages
+	for that release.</p>
 
       <p>Git was officially promoted from beta to an officially
 	supported version control system.  Git is available as a
@@ -630,32 +660,32 @@
 	exported copy from SVN, the primary and only read-write
 	repository.  The &os; git repositories (exported from the
 	master SVN version control) will shortly be available at
-	https://git.freebsd.org/, and core has been active
-	in ensuring that there is a sufficient body of Git
-	administrators available with access to appropriate
-	documentation in order to maintain a good git service.</p>
+	https://git.freebsd.org/, and core has been active in ensuring
+	that there is a sufficient body of Git administrators
+	available with access to appropriate documentation in order to
+	maintain a good git service.</p>
 
       <p>Core mediated in disputes between a number of committers over
 	some updates to system sources, and fielded complaints about
-	code quality of some other work in critical areas.
-	While such disagreements will occasionally occur, core is
-	promoting the routine use of the Phabricator service in order to
-	review work before committal.  Catching problems early is in the
-	project's best interests, and discussion of changes in an open
-	review context should minimize confrontational demands for
-	immediate back-out of changes.</p>
+	code quality of some other work in critical areas.  While such
+	disagreements will occasionally occur, core is promoting the
+	routine use of the Phabricator service in order to review work
+	before committal.  Catching problems early is in the project's
+	best interests, and discussion of changes in an open review
+	context should minimize confrontational demands for immediate
+	back-out of changes.</p>
 
       <p>Core is working on a charter for a proposed new QA team, to
-	encompass members of the Release Engineering and Security teams,
-	as well as committers with interests in standards compliance.
-	It is envisioned that the QA team will take responsibility for
-	merging code from HEAD into the STABLE branches, run integration
-	testing against those updates and handle merging patches and
-	bug-fixes submitted to the &os; project from third parties.</p>
-
-      <p>During this quarter, core issued two new commit bits, and also
-	took two commit bits into safe-keeping.</p>
-	
+	encompass members of the Release Engineering and Security
+	teams, as well as committers with interests in standards
+	compliance.  It is envisioned that the QA team will take
+	responsibility for merging code from HEAD into the STABLE
+	branches, run integration testing against those updates and
+	handle merging patches and bug-fixes submitted to the &os;
+	project from third parties.</p>
+
+      <p>During this quarter, core issued two new commit bits, and
+	also took two commit bits into safe-keeping.</p>
     </body>
   </project>
 
@@ -680,36 +710,45 @@
     </links>
 
     <body>
-      <p>The KDE on &os; team focuses on packaging and making sure that the
-	experience of KDE and Qt on &os; is as good as possible.</p>
+      <p>The KDE on &os; team focuses on packaging and making sure
+	that the experience of KDE and Qt on &os; is as good as
+	possible.</p>
 
       <p>As mentioned last quarter, Alonso Schaich (alonso@) became a
-	committer and since then has made good progress helping his mentors
-	Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@) maintain all
-	Qt and KDE-related ports.</p>
+	committer and since then has made good progress helping his
+	mentors Raphael Kubo da Costa (rakuco@) and Max Brazhnikov
+	(makc@) maintain all Qt and KDE-related ports.</p>
 
       <p>This quarter, Qt 5.3 was finally committed to the ports tree.
-	Extensive work was required, including cleaning up and/or changing a lot of
-	the Qt5 ports infrastructure to make it both easier to maintain the Qt
-	ports as well as finally make it possible to build newer versions when
-	older ones are already installed on the system.</p>
-
-      <p>We have also updated KDE in our experimental area51 repository
-	and committed several updates to other ports such as KDevelop and KDE
-	Telepathy. Overall, we have worked on the following releases:
+	Extensive work was required, including cleaning up and/or
+	changing a lot of the Qt5 ports infrastructure to make it both
+	easier to maintain the Qt ports as well as finally make it
+	possible to build newer versions when older ones are already
+	installed on the system.</p>
+
+      <p>We have also updated KDE in our experimental area51
+	repository and committed several updates to other ports such
+	as KDevelop and KDE Telepathy.  Overall, we have worked on the
+	following releases:
 	<ul>
-	  <li>CMake 3.1.0 (in area51, exp-run in progress for it to be committed to the ports tree)</li>
+	  <li>CMake 3.1.0 (in area51, exp-run in progress for it to be
+	    committed to the ports tree)</li>
+
 	  <li>Calligra 2.8.6 (in area51)</li>
+
 	  <li>KDE 4.14.2 (committed to ports), 4.14.3 (in area51)</li>
+
 	  <li>KDE Telepathy 0.8.0 (committed to ports)</li>
+
 	  <li>KDevelop 4.7.0 (committed to ports)</li>
+
 	  <li>Qt 5.3.2 (committed to ports)</li>
 	</ul>
       </p>
 
-      <p>Tobias Berner has contributed patches to update QtCreator to 3.3.0 as
-	well as KDE Frameworks 5 ports which are under review for inclusion
-	in our experimental area51 repository.</p>
+      <p>Tobias Berner has contributed patches to update QtCreator to
+	3.3.0 as well as KDE Frameworks 5 ports which are under review
+	for inclusion in our experimental area51 repository.</p>
     </body>
 
     <help>
@@ -718,11 +757,13 @@
       </task>
 
       <task>
-	<p>Try to contribute to the work on getting rid of HAL on &os;,
-	  which seems to be gaining more traction recently.</p>
+	<p>Try to contribute to the work on getting rid of HAL on
+	  &os;, which seems to be gaining more traction recently.</p>
       </task>
+
       <task>
-	<p>Add KDE Frameworks 5 ports to our experimental repository.</p>
+	<p>Add KDE Frameworks 5 ports to our experimental
+	  repository.</p>
       </task>
     </help>
   </project>
@@ -750,10 +791,11 @@
 	Essentials" is available.</p>
 
       <p>Lucas is moving on to &os; books on ZFS, Specialty
-	Filesystems, and jails. They will hopefully be available by
+	Filesystems, and jails.  They will hopefully be available by
 	BSDCan 2015.</p>
 
-      <p>Get status updates on his blog, or follow @mwlauthor on Twitter.</p>
+      <p>Get status updates on his blog, or follow @mwlauthor on
+	Twitter.</p>
     </body>
 
     <help>
@@ -851,22 +893,23 @@
 	and Testing in &os;.  Some of the highlights include:</p>
 
       <ul>
-	<li>The Jenkins project mentioned on their blog how FreeBSD is using
-	  Jenkins and kyua to run OS-level tests.</li>
+	<li>The Jenkins project mentioned on their blog how FreeBSD is
+	  using Jenkins and kyua to run OS-level tests.</li>
 
-	<li>&a.rodrigc; submitted patches to upgrade Jenkins to use JNA 4.1.0.
-	  The Jenkins project accepted these patches [JENKINS-24521] in
-	  the Jenkins 1.586 release.  This fixed problems with PAM
-	  authentication support in Jenkins on FreeBSD [JENKINS-21507].</li>
+	<li>&a.rodrigc; submitted patches to upgrade Jenkins to use
+	  JNA 4.1.0.  The Jenkins project accepted these patches
+	  [JENKINS-24521] in the Jenkins 1.586 release.  This fixed
+	  problems with PAM authentication support in Jenkins on
+	  FreeBSD [JENKINS-21507].</li>
 
 	<li>&a.rodrigc; gave a presentation "Kyua and Jenkins Testing
 	  Framework" for BSD at the Developer and Vendor summit on
-	  November 3, 2014 in San Jose, California.  In the presentation,
-	  &a.rodrigc; described how, for every commit to the FreeBSD source
-	  tree, nearly 3000 tests are run using kyua inside a bhyve virtual
-	  machine.  The kyua test results are exported to JUnit XML format,
-	  which is then used by Jenkins to generate web-based test reports with
-	  graphs.</li>
+	  November 3, 2014 in San Jose, California.  In the
+	  presentation, &a.rodrigc; described how, for every commit to
+	  the FreeBSD source tree, nearly 3000 tests are run using
+	  kyua inside a bhyve virtual machine.  The kyua test results
+	  are exported to JUnit XML format, which is then used by
+	  Jenkins to generate web-based test reports with graphs.</li>
 
 	<li>&a.lwhsu; set up a Jenkins build named FreeBSD_Doc-igor
 	  to run the Igor tool written by &a.wblock;.  Igor proofreads
@@ -876,8 +919,8 @@
 	  FreeBSD_HEAD_sparc64 to build the FreeBSD HEAD branch for
 	  the sparc64 architecture</li>
 
-	<li>&a.ngie; imported more tests from NetBSD.  After this import,
-	  there are now over 3000 tests in the /usr/tests
+	<li>&a.ngie; imported more tests from NetBSD.  After this
+	  import, there are now over 3000 tests in the /usr/tests
 	  directory.</li>
 
 	<li>Susan Stanziano from Xinuous ran kyua tests and provided
@@ -888,31 +931,35 @@
 	  feedback about test errors running in a Hyper-V 2012R2
 	  VM.</li>
 
-	<li>&a.swills; ran the &os; tests in Google Compute Engine and provided
-	  the test results.</li>
+	<li>&a.swills; ran the &os; tests in Google Compute Engine and
+	  provided the test results.</li>
 
 	<li>&a.rodrigc; submitted a formula to create a package for
-	  kyua in the Homebrew packaging system on OS X.  The Homebrew project
-	  accepted this.  Now, kyua can easily be installed on OS X via a
-	  Homebrew package.  Hopefully this will make it easier to share
-	  more test infrastructure and scripts with OS X.</li>
+	  kyua in the Homebrew packaging system on OS X.  The Homebrew
+	  project accepted this.  Now, kyua can easily be installed on
+	  OS X via a Homebrew package.  Hopefully this will make it
+	  easier to share more test infrastructure and scripts with OS
+	  X.</li>
 
 	<li>&a.rodrigc; submitted to the Debian project a kyua
 	  package.  Approval for this is still pending.  A package
-	  will make it much easier to install kyua on Linux distributions which
-	  use Debian packages such as Debian, Ubuntu, and Linux Mint.  Hopefully
-	  &os; this will make it easier to share more test infrastructure and
-	  scripts with Linux.</li>
+	  will make it much easier to install kyua on Linux
+	  distributions which use Debian packages such as Debian,
+	  Ubuntu, and Linux Mint.  Hopefully &os; this will make it
+	  easier to share more test infrastructure and scripts with
+	  Linux.</li>
 
 	<li>Brian Gardner submitted scripts to run the Regression Test
-	  Harness for OpenJDK (jtreg).  The test results are in JUnit XML
-	  format, which can be natively imported into Jenkins.</li>
+	  Harness for OpenJDK (jtreg).  The test results are in JUnit
+	  XML format, which can be natively imported into
+	  Jenkins.</li>
 
 	<li>Ahmed Kamal, an experienced devops expert and past
 	  contributor to the Ubuntu project, offered to help
 	  &a.rodrigc; with improving the automation and deployment of
-	  Jenkins nodes in the &os; cluster using the Saltstack automation
-	  framework.  Ahmed is interested in helping the &os; project.</li>
+	  Jenkins nodes in the &os; cluster using the Saltstack
+	  automation framework.  Ahmed is interested in helping the
+	  &os; project.</li>
 
 	<li>&a.rodrigc; worked with &a.adrian; to set up Jenkins
 	  builds of MIPS targets.  The next step will be to get kyua
@@ -927,7 +974,7 @@
 
       <task>
 	<p>Improve the maintenance of nodes in the Jenkins cluster
-	 using devops frameworks such as Saltstack.</p>
+	  using devops frameworks such as Saltstack.</p>
       </task>
 
       <task>
@@ -957,35 +1004,48 @@
 
     <body>
       <p>Xfce is a free software desktop environment for Unix and
-	Unix-like platforms, such as &os;. It aims to be fast and
-	lightweight, while still being visually appealing and easy to use.</p>
+	Unix-like platforms, such as &os;.  It aims to be fast and
+	lightweight, while still being visually appealing and easy to
+	use.</p>
 
-      <p>During this quarter, the team has kept these applications up-to-date:</p>
+      <p>During this quarter, the team has kept these applications
+	up-to-date:</p>
 
       <ul>
 	<li>misc/xfce4-weather-plugin 0.8.5</li>
+
 	<li>science/xfce4-equake-plugin 1.3.6</li>
+
 	<li>sysutils/xfce4-netload-plugin 1.2.4</li>
+
 	<li>sysutils/xfce4-systemload-plugin 1.1.2</li>
+
 	<li>www/midori 0.5.9</li>
+
 	<li>x11/xfce4-taskmanager 1.1.0</li>
+
 	<li>x11/xfce4-whiskermenu-plugin 1.4.2</li>
+
 	<li>x11-wm/xfce4-desktop 4.10.3</li>
       </ul>
 
-      <p>Two new ports have also been added (taken from our repository):</p>
+      <p>Two new ports have also been added (taken from our
+	repository):</p>
 
       <ul>
 	<li>deskutils/xfce4-volumed-pulse</li>
+
 	<li>x11/xfce4-dashboard</li>
       </ul>
 
-      <p>Moreover, we are working on the next stable release, with these
-	ports being updated:</p>
+      <p>Moreover, we are working on the next stable release, with
+	these ports being updated:</p>
 
       <ul>
 	<li>sysutils/xfce4-power-manager 1.4.2</li>
+
 	<li>x11/xfce4-dashboard 0.3.4</li>
+
 	<li>x11-wm/xfce4-session 4.11.1</li>
       </ul>
 
@@ -993,22 +1053,28 @@
 
       <ul>
 	<li>bug <a href="https://bugzilla.xfce.org/show_bug.cgi?id=11104">#11104</a>, to keep 'wallpaper settings' in Ristretto with xfdesktop >= 4.11</li>
+
 	<li>bug <a href="https://bugzilla.xfce.org/show_bug.cgi?id=11249">#11249</a>, add 'Hidden' option in desktop item editor (refused)</li>
+
 	<li>bug <a href="https://bugzilla.xfce.org/show_bug.cgi?id=11413">#11413</a>, to use sysctl(3) and acpi_video(4) for backlight support</li>
       </ul>
 
-      <p>A FAQ is being written <a href="https://reviews.freebsd.org/D1305">D1305</a>.</p>
+      <p>A FAQ is being written
+	<a href="https://reviews.freebsd.org/D1305">D1305</a>.</p>
     </body>
 
     <help>
       <task>
-	<p>Find workaround <tt>when acpi_video(4)</tt> is not functional
-	  (panel crashes); OpenBSD seems to have same problem.</p>
+	<p>Find workaround <tt>when acpi_video(4)</tt> is not
+	  functional (panel crashes); OpenBSD seems to have same
+	  problem.</p>
       </task>
+
       <task>
 	<p>Clean up patch in order to add new panel plugin in ports
 	  tree.</p>
       </task>
+
       <task>
 	<p>Continue to work on documentation, especially the Porter's
 	  Handbook.</p>
@@ -1036,17 +1102,15 @@
 
     <body>
       <p>The project adds support for AES-GCM and AES-CTR mode to the
-	OpenCrypto framework.  Both software and AES-NI accelerated versions
-	are functional, working and committed.  Ermal Luçi (eri@) is working
-	on adding support for the additional modes to IPsec.</p>
+	OpenCrypto framework.  Both software and AES-NI accelerated
+	versions are functional, working and committed.  Ermal Luçi
+	(eri@) is working on adding support for the additional modes
+	to IPsec.</p>
     </body>
 
-    <sponsor>
-      The &os; Foundation
-    </sponsor>
-    <sponsor>
-      Netgate
-    </sponsor>
+    <sponsor>The &os; Foundation</sponsor>
+
+    <sponsor>Netgate</sponsor>
 
     <help>
       <task>
@@ -1073,72 +1137,81 @@
     </links>
 
     <body>
-      <p>Mesa was upgraded to 10.3, then 10.4 for FreeBSD 10.1-RELEASE and
-	11-CURRENT.  We test release candidates and therefore this port is
-	now usually updated shortly after a new release.  Mesa 10.x brings
-	huge improvements in terms of OpenGL standards support, performance
-	and stability, especially for Radeon owners.  Mesa 9.1 is kept for
-	&os; 9.x, but we have plans to fix this; see below.</p>
-
-      <p><tt>graphics/gbm</tt> and <tt>devel/libclc</tt> are new ports used
-	by Mesa to implement OpenCL.  The next step is to finish the port for
-	Mesa's libOpenCL.so, named Clover.  This will permit users to run
-	OpenCL programs on Radeon GPUs for now.</p>
-
-      <p>xserver was upgraded from 1.12 to 1.14.  This is the last version
-	of xserver supporting Mesa 9.1.  Changes are described in an article
-	on the blog.  The most noticeable one is the switch from
-	the input device detection back-end based on HAL to the one based on
-	<tt>devd(8)</tt>. <tt>hald(8)</tt> is still required by many desktop environments, but
-	the X.Org server itself is free from it.</p>
-
-      <p>xserver was the last port supporting the <tt>WITH_NEW_XORG</tt>
-	knob.  The knob is now completely removed. This was the occasion to
-	add <tt>WITH_NEW_XORG</tt> and <tt>WITH_KMS</tt> to the list of
-	deprecated knobs to help people clean up their <tt>make.conf</tt>.
-	At the same time, the new-xorg alternate pkg repository was
-	deprecated.</p>
+      <p>Mesa was upgraded to 10.3, then 10.4 for FreeBSD 10.1-RELEASE
+	and 11-CURRENT.  We test release candidates and therefore this
+	port is now usually updated shortly after a new release.  Mesa
+	10.x brings huge improvements in terms of OpenGL standards
+	support, performance and stability, especially for Radeon
+	owners.  Mesa 9.1 is kept for &os; 9.x, but we have plans to
+	fix this; see below.</p>
+
+      <p><tt>graphics/gbm</tt> and <tt>devel/libclc</tt> are new ports
+	used by Mesa to implement OpenCL.  The next step is to finish
+	the port for Mesa's libOpenCL.so, named Clover.  This will
+	permit users to run OpenCL programs on Radeon GPUs for
+	now.</p>
+
+      <p>xserver was upgraded from 1.12 to 1.14.  This is the last
+	version of xserver supporting Mesa 9.1.  Changes are described
+	in an article on the blog.  The most noticeable one is the
+	switch from the input device detection back-end based on HAL
+	to the one based on <tt>devd(8)</tt>.  <tt>hald(8)</tt> is
+	still required by many desktop environments, but the X.Org
+	server itself is free from it.</p>
+
+      <p>xserver was the last port supporting the
+	<tt>WITH_NEW_XORG</tt> knob.  The knob is now completely
+	removed.  This was the occasion to add <tt>WITH_NEW_XORG</tt>
+	and <tt>WITH_KMS</tt> to the list of deprecated knobs to help
+	people clean up their <tt>make.conf</tt>.  At the same time,
+	the new-xorg alternate pkg repository was deprecated.</p>
 
       <p>After discussion, two options were enabled by default:</p>
       <ul>
-	<li><tt>TEXTURE_FLOAT</tt> in graphics/dri, which allows Mesa to
-	  advertise the support for OpenGL 3.0+;</li>
-	<li><tt>LCD_FILTERING</tt> in <tt>print/freetype2</tt>, which enables the
-	  subpixel rendering engine, improving font anti-aliasing.</li>
+	<li><tt>TEXTURE_FLOAT</tt> in graphics/dri, which allows Mesa
+	  to advertise the support for OpenGL 3.0+;</li>
+
+	<li><tt>LCD_FILTERING</tt> in <tt>print/freetype2</tt>, which
+	  enables the subpixel rendering engine, improving font
+	  anti-aliasing.</li>
       </ul>
 
       <p>These two packages now provide a better user experience
-	out-of-the-box.  Users who are uncomfortable with the options may
-	unset them and rebuild the ports.  There is no need to rebuild
-	anything else.</p>
-
-      <p>On the kernel side, Tijl Coosemans added AGP support back to the
-	TTM memory manager and therefore to the Radeon driver.  His work was

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***