Index: head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml	(revision 47072)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml	(revision 47073)
@@ -1,3141 +1,3142 @@
 <?xml version="1.0" encoding="utf-8" ?>
 <!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
   Status Report//EN"
   "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
 
 <!-- $FreeBSD$ -->
 
 <report>
   <date>
     <month>April-June</month>
 
     <year>2015</year>
   </date>
 
   <section>
     <title>Introduction</title>
 
     <?ignore
     <p><strong>This is a draft of the April&ndash;June 2015
       status report.  Please check back after it is finalized, and
       an announcement email is sent to the &os;-Announce mailing
       list.</strong></p>
     ?>
 
     <p>The second quarter of 2015, from April to June, was another
       period of busy activity for &os;.  This report is the largest we
       have published so far.</p>
 
     <p>The cluster and release engineering teams continued to improve
       the structures that support &os;'s build, maintenance, and
       installation.  Projects ran the gamut from security and speed
       improvements to virtualization and storage appliances.  New
       kernel drivers and capabilities were added, while work to make
       &os; run on various ARM architectures continued at a rapid pace.
       The Ports Collection grew, even while adding capabilities and
       fixing problems.  Outside projects like <tt>pkgsrc</tt> have
       become interested in adding support.  Documentation was a major
       focus, one that is often complimented by people new to &os;.
       BSDCan 2015 was a great success, turning many hours of sleep
       deprivation into an even greater amount of inspiration.</p>
 
     <p>As always, a great deal of this activity was directly sponsored
       by the Foundation.  The project's status as a first-class
       operating system owes a great deal to the Foundation's past and
       ongoing work.</p>
 
     <p>The number and detail of these reports really gives only a tiny
       glimpse of all that is happening.  A huge portion of &os;
       development takes place all the time, including bug fixes,
       feature improvements, rewrites, and imports of new code.  This
       ongoing work is difficult, time-consuming, and, far too often,
       unrecognized.  We should take a moment to consider and thank
       not just the contributors listed here, but also the end users,
       bug submitters, port maintainers, coders, security analysts,
       infrastructure defenders, tinkerers, scientists, designers,
       questioners, answerers, rule makers, testers, documenters,
       sysadmins, dogmatists, iconoclasts, and crazed geniuses who make
       &os; such an effective and useful operating system.  If you are
       reading this, you are one of these people, too.  Thank you.</p>
 
     <p><i>&mdash;Warren Block</i></p>
 
     <p><hr /></p>
 
     <p>This status report was compiled by
       <a href="mailto:bjk@FreeBSD.org">Benjamin Kaduk</a> and
       <a href="mailto:wblock@FreeBSD.org">Warren Block</a>.  Please
       submit status reports for the third quarter of 2015 (July to
       September) by October 1, 2015.</p>
   </section>
 
   <category>
     <name>team</name>
 
     <description>&os; Team Reports</description>
   </category>
 
   <category>
     <name>proj</name>
 
     <description>Projects</description>
   </category>
 
   <category>
     <name>kern</name>
 
     <description>Kernel</description>
   </category>
 
   <category>
     <name>arch</name>
 
     <description>Architectures</description>
   </category>
 
   <category>
     <name>bin</name>
 
     <description>Userland Programs</description>
   </category>
 
   <category>
     <name>ports</name>
 
     <description>Ports</description>
   </category>
 
   <category>
     <name>doc</name>
 
     <description>Documentation</description>
   </category>
 
   <category>
     <name>gsoc</name>
 
     <description>Google Summer of Code</description>
   </category>
 
   <category>
     <name>misc</name>
 
     <description>Miscellaneous</description>
   </category>
 
   <project cat='doc'>
     <title>New Documentation Committers</title>
 
     <contact>
       <person>
 	<name>&os; Documentation Engineering Team</name>
 	<email>doceng@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/">&os;
 	Porter's Handbook</url>
       <url href="https://www.freebsd.org/">&os; Web Site</url>
       <url href="https://www.freebsdfoundation.org/">FreeBSD Foundation
 	Web Site</url>
     </links>
 
     <body>
       <p>Two new documentation committers were added to the team in
 	the second quarter of 2015.</p>
 
       <p>Mathieu Arnold is a member of the &os; Ports Management Team.
 	Over the past year, he has worked on many large and complex
 	updates to keep the Porter's Handbook current, and
 	continues to update this important document.</p>
 
       <p>Anne Dickison is Marketing Director for the FreeBSD Foundation.
 	She will focus on updating and improving the &os; main web
 	site.</p>
 
       <p>We welcome both new committers and look forward to their
 	additional contributions!</p>
     </body>
   </project>
 
   <project cat='doc'>
     <title>Documentation Working Group at BSDCan</title>
 
     <contact>
       <person>
 	<name>&os; Documentation Team</name>
 	<email>freebsd-doc@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.bsdcan.org/">BSDCan</url>
       <url href="http://docutils.sourceforge.net/rst.html">reStructured
 	Text</url>
       <url href="http://daringfireball.net/projects/markdown/">Markdown</url>
       <url href="http://asciidoc.org/">AsciiDoc</url>
       <url href="https://wiki.freebsd.org/">&os; Wiki</url>
       <url href="https://www.freebsd.org/">&os; Web Site</url>
       <url href="http://annotatorjs.org/">Annotator</url>
       <url href="https://github.com/openannotation/annotator/wiki#backend-stores">Annotator
 	Backend Stores</url>
     </links>
 
     <body>
       <p>During the Developer Summit held in the two days before
 	BSDCan, a documentation working group meeting was held.  We
 	discussed some of the biggest opportunities available to the
 	documentation team.</p>
 
       <p>Modernizing our translation system was, again, a major topic.
 	Making it easier for translators to do their work is vitally
 	important.  Translations make &os; much more accessible for
 	non-English speakers, and those people and the translators
 	themselves often become valuable technical contributors in
 	other areas.  Progress was made in this area, and we hope to
 	have more news soon.</p>
 
       <p>Methods of making it easier for people to contribute to
 	documentation was another major topic.  At present, we use
 	DocBook XML for articles and books, and mdoc(7) for man pages.
 	These markup languages are not very welcoming for new users.
 	There are simpler documentation markup languages like
 	reStructured Text (RST),
 	Markdown, and AsciiDoc that take less time to learn and use.
 	In fact, these markup systems are all similar to each other.
 	These systems tend to be more oriented towards visual
 	appearance rather than the semantic markup of our present
 	systems, although there might be ways to work around that.</p>
 
       <p>Following the theme of making contributing easier, we also
 	discussed whether access to the &os; Wiki can be more easily
 	granted, facilitating user contributions.
 	After the wiki was set up, automated account creation abuse
 	forced access to be limited.
 	It is tricky to allow submissions yet keep the
 	quality of submitted information usefully high.</p>
 
       <p>Due to the markup systems used, it is difficult to review
 	documents for the quality of their information.  Annotator is
 	a Javascript system that allows adding notes to an existing
 	web page.  This would allow us to hold content-only reviews of
 	documentation web pages.  Reviewers would not see markup, so
 	they could concentrate only on whether the information was
 	accurate and complete.  To use this as desired, we need some
 	help with ports and testing.</p>
     </body>
 
     <help>
       <task>
 	<p>Complete a port for the backend storage component of
 	  Annotator.  Preferably this would be the lowest overhead and
 	  most open-licensed version available.  Assistance from those
 	  familiar with Python and Javascript web development is
 	  welcome.</p>
       </task>
     </help>
   </project>
 
   <project cat='misc'>
     <title>&os; Support in <tt>pkgsrc</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>Sevan</given>
 	  <common>Janiyan</common>
 	</name>
 	<email>venture37@geeklan.co.uk</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.pkgsrc.org">pkgsrc home page</url>
       <url href="http://bulktracker.appspot.com">BulkTracker:
 	Track bulk build status</url>
       <url href="https://www.geeklan.co.uk/?tag=pkgsrc">Blog posts
 	on pkgsrc</url>
     </links>
 
     <body>
       <p><tt>pkgsrc</tt> is a fork of the &os; Ports Collection by
 	the NetBSD
 	project with a focus on portability and multi-platform
 	support.  At present, pkgsrc supports building packages on 23
 	different platforms from a single tree, including &os;</p>
 
       <p>While <tt>pkgsrc</tt> is not a replacement for ports in most
 	use cases, it holds a unique position in mixed-platform
 	environments where software needs to be the same
 	version across all systems and built in a consistent
 	manner, saving the user from having to resort to manually
 	building programs or re-implementing a mechanism to do so.</p>
 
       <p>With the recent
 	<a href="http://mail-index.netbsd.org/pkgsrc-users/2015/07/06/msg021778.html">2015Q2 release</a>
 	earlier this month, it is now possible to generate over 14000
 	packages on FreeBSD 10.1-RELEASE (up from 12800 last
 	quarter).</p>
 
       <p>Work is in progress to add
 	<a href="https://vimeo.com/132766052">pkg support to pkgsrc.</a></p>
     </body>
 
     <help>
       <task>
 	<p>Improve platform support to skip libusb on &os; where
 	libusb is bundled in base.  This is causing the biggest
 	breakage at the moment.</p>
       </task>
 
       <task>
 	<p>Expand the effort to the -STABLE and -CURRENT branches and, if
 	  possible, architectures other than amd64.  Contributing
 	  shell access to such machines would be helpful (an unprivileged
 	  account is sufficient).</p>
       </task>
     </help>
   </project>
 
   <project cat='misc'>
     <title>ZFS Support for UEFI Boot/Loader</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Eric</given>
 	  <common>McCorkle</common>
 	</name>
 	<email>emc2@metricspace.net</email>
       </person>
     </contact>
 
     <body>
       <p>UEFI-enabled <tt>boot1.efi</tt> and <tt>loader.efi</tt> have
 	been modified to support loading and booting from a ZFS
 	filesystem.  The patch currently works with
 	<tt>buildworld</tt>, and successfully boots on a test machine
 	with a ZFS partition.  In addition, the ZFS-enabled
 	<tt>loader.efi</tt> can be treated as a chainloader using
 	ZFS-enabled GRUB.</p>
 
       <p>The work on <tt>boot1.efi</tt> also reorganizes the code
 	somewhat, splitting out the filesystem-specific parts into a
 	modular framework.</p>
     </body>
 
     <help>
       <task>
 	<p>More testing is needed for the following use cases: ZFS with
 	  GRUB+<tt>loader.efi</tt>, ZFS with
 	  <tt>boot1</tt>+<tt>loader.efi</tt>, UFS with
 	  <tt>boot1</tt>+<tt>loader.efi</tt> (to test the modularization of
 	  <tt>boot1.efi</tt>)</p>
       </task>
 
       <task>
 	<p>Have <tt>boot1.efi</tt> check partition type GUIDs before
 	  probing for filesystems.</p>
       </task>
 
       <task>
 	<p>Get patch accepted upstream and committed.</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title>Xfce on FreeBSD</title>
 
     <contact>
       <person>
 	<name>
 	  <given>&os; Xfce Team</given>
 	</name>
 	<email>xfce@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/Xfce">&os; Xfce
 	Project</url>
       <url href="https://www.assembla.com/code/xfce4/subversion/nodes">&os;
 	Xfce Repository</url>
     </links>
 
     <body>
       <p><tt>Xfce</tt> 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>
 
       <p>During this quarter, the team has kept these applications
 	up-to-date:</p>
 
       <ul>
 	<li><tt>audio/xfce4-pulseaudio-plugin</tt> 0.2.3</li>
 	<li><tt>deskutils/orage</tt> 4.12.1</li>
 	<li><tt>deskutils/xfce4-notes-plugin</tt> 1.8.1</li>
 	<li><tt>misc/xfce4-weather-plugin</tt> 0.8.6</li>
 	<li><tt>science/xfce4-equake-plugin</tt> 1.3.7</li>
 	<li><tt>sysutils/xfburn</tt> 0.5.4</li>
 	<li><tt>sysutils/xfce4-power-manager</tt> 1.5.0 (committed to
 	  ports), 1.5.2 (committed to devel repository)</li>
 	<li><tt>x11/libexo</tt> 0.10.6</li>
 	<li><tt>x11/xfce4-dashboard</tt> 0.4.2</li>
 	<li><tt>x11-fm/thunar</tt> 1.6.10</li>
 	<li><tt>x11-wm/xfce4-desktop</tt> 4.12.2</li>
 	<li><tt>x11-wm/xfce4-wm</tt> 4.12.3</li>
 	<li><tt>www/midori</tt> 0.5.10</li>
       </ul>
 
       <p>Mathieu Arnold (<tt>mat@</tt>) committed
 	<a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197878">PR
 	  197878</a>,
 	updating the Xfce section in the Porter's Handbook.</p>
 
       <p>We also follow the unstable releases (available in our
 	experimental repository) of:</p>
 
       <ul>
 	<li><tt>sysutils/garcon</tt> 0.5.0 (supports both GTK2 and
 	  GTK3 toolkits)</li>
 	<li><tt>x11/xfce4-dashboard</tt> 0.5.0</li>
 	<li><tt>x11/xfce4-hotcorner-plugin</tt> 0.0.2 (new
 	  plugin)</li>
       </ul>
     </body>
 
     <help>
       <task>
 	<p>Create documentation for the usage of
 	  <tt>sysutils/xfce4-power-manager</tt> (it needs some love,
 	  <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199166">PR
 	    199166</a>).</p>
 
 	<p>Some hidden features were introduced in the 1.5.1 release,
 	  and as we also support ConsoleKit2 (a fork of
 	  <tt>sysutils/consolekit</tt>), help for users is
 	  required.</p>
       </task>
     </help>
   </project>
 
   <project cat='doc'>
     <title>FreeBSD Mastery: ZFS Now Available</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Michael</given>
 	  <common>Lucas</common>
 	</name>
 	<email>mwlucas@michaelwlucas.com</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.zfsbook.com">FreeBSD Mastery: ZFS</url>
       <url href="https://www.michaelwlucas.com">Michael W. Lucas</url>
     </links>
 
     <body>
       <p>The first ZFS book is now available at your favorite
 	bookstore.  Find a whole bunch of links at
 	<a href="http://www.zfsbook.com"><tt>zfsbook.com</tt></a>.</p>
 
       <p>Work is proceeding apace on "FreeBSD Mastery: Advanced ZFS"
 	and "FreeBSD Mastery: Specialty Filesystems."  Lucas hopes to
 	have FMAZ complete and available before the next status
 	report.</p>
     </body>
   </project>
 
   <project cat='doc'>
     <title>The FreeBSD German Documentation Project</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Bj&ouml;rn</given>
 	  <common>Heidotting</common>
 	</name>
 	<email>bhd@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Johann</given>
 	  <common>Kois</common>
 	</name>
 	<email>jkois@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Benedict</given>
 	  <common>Reuschling</common>
 	</name>
 	<email>bcr@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.freebsd.org/de/docs.html">Main
 	German Documentation Project page</url>
       <url href="https://people.freebsd.org/~jkois/FreeBSDde/de/">How
 	you can help with German translations</url>
     </links>
 
     <body>
       <p>The &os; German Documentation project maintains the German
 	translations of &os;'s documents such as the Handbook and the
 	website.</p>
 
       <p>In the second quarter of 2015, we managed to catch up with
 	the translation work of the Handbook.  Two chapters are now
 	back in sync with their English reference chapters:
 	filesystems and ZFS.  The former was mainly done by Bj&ouml;rn
 	Heidotting as part of his mentee process.  The latter was done
 	by Benedict Reuschling, with valuable corrections by
 	Bj&ouml;rn.</p>
 
       <p>Additionally, we updated many of our translation markers from
 	pre-SVN times.  This will help us get an overview of the
 	outstanding work in each chapter.  We are working on
 	integrating this into our website using a script, so people
 	can see which chapters need the most work or are most
 	up-to-date.</p>
 
       <p>Johann made efforts to update the &os; Documentation Project
 	Primer as well, so that translators willing to help us can
 	read the information in German.  He also made efforts to
 	revive the Documentation Project website, which was previously
 	hosted elsewhere, but disappeared.  Now, it is tied into the
 	German FreeBSD.org website again and has the same look and
 	feel.</p>
 
       <p>Occasionally, people contact us and offer their help with the
 	translation effort.  We are happy to help newcomers get to
 	know everything about the translation process and look forward
 	to more contributions.  Even small updates make a big
 	difference and if you are considering helping, please contact
 	us.</p>
     </body>
 
     <help>
       <task>
 	<p>Continue translating the Handbook and website into
 	  German.</p>
       </task>
 
       <task>
 	<p>Integrate a script that shows outstanding work into the
 	  German documentation webpages.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>Multiqueue Testing</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Tiwei</given>
 	  <common>Bie</common>
 	</name>
 	<email>btw@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Hiren</given>
 	  <common>Panchasara</common>
 	</name>
 	<email>hiren@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/SummerOfCode2015/MultiqueueTestingProject">Multiqueue
 	Testing Project</url>
     </links>
 
     <body>
       <p>The aim of this project is to design and implement an
 	infrastructure to validate that a number of the network
 	stack's multiqueue behaviours are as expected.</p>
 
       <p>It mainly consists of extending <tt>tap(4)</tt> to provide
 	the same RSS behaviours as the hardware multiqueue network
 	cards, developing simple test applications using multiqueue
 	<tt>tap(4)</tt> and <tt>socket(2)</tt>, adding hooks in each
 	layer of the network stack to collect the per-ring per-cpu
 	per-layer statistics, and extending <tt>netstat(1)</tt> to
 	report these statistics.</p>
 
       <p>At present, most parts of this project have been implemented.
 	The focus is on the code review, and API/KPI freeze.</p>
     </body>
 
     <sponsor>
       Google Summer Of Code 2015
     </sponsor>
   </project>
 
   <project cat='team'>
     <title>&os; Release Engineering Team</title>
 
     <contact>
       <person>
 	<name>&os;&nbsp;Release Engineering Team</name>
 	<email>re@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.freebsd.org/releases/10.2R/schedule.html">&os;&nbsp;10.2-RELEASE
 	schedule</url>
       <url href="http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/">&os;
 	development snapshots</url>
       <url href="https://lists.freebsd.org/pipermail/freebsd-snapshots/">&os;
 	development snapshots announcements list</url>
     </links>
 
     <body>
       <p>The &os; Release Engineering Team is responsible for setting
 	and publishing release schedules for official project releases
 	of &os;, announcing code freezes, and maintaining the
 	respective branches, among other things.</p>
 
       <p>The &os;&nbsp;10.2-RELEASE cycle began in mid-June, with the
 	final release expected to be available in late August, and as
 	this quarterly status update shows, &os;&nbsp;10.2-RELEASE is
 	going to be a very exciting release.</p>
 
       <p>The &os; Release Engineering Team has been extremely busy
 	this quarter, with much of the focus targeted at adding
 	support for additional hardware and integration with
 	third-party hosting providers (aka &quot;cloud&quot;
 	hosting).</p>
 
       <p>Following up on the work done by &a.andrew; to port &os; to
 	the arm64 (aarch64) architecture, the Release Engineering
 	build tools were updated to produce &os;/aarch64 memory stick
 	images and virtual machine images for use with Qemu
 	(<tt>emulators/qemu-devel</tt>).  At present, the Qemu virtual
 	machine images require an external EFI file to boot.  Details
 	on how to boot &os;/aarch64 virtual machine images are
 	available in the linked &os; development snapshot announcement email
 	archives.</p>
 
       <p>Last quarter, several parts of the build tools were rewritten
 	to allow greater extensibility and granularity, which has
 	simplified the code required for new virtual machine
 	images.</p>
 
       <p>In collaboration with several developers, the Release
 	Engineering build tools were updated to provide new support
 	for several hosting providers, as well as provide mechanisms
 	to automatically upload (and publish, where possible) &os;
 	virtual machine images.</p>
 
       <p>This quarter, in addition to the existing support for the
 	Microsoft Azure platform, the build tools also natively
 	support:</p>
 
       <ul>
 	<li>Amazon EC2 (thanks to &a.cperciva;)</li>
 	<li>Google Compute Engine (thanks to &a.swills;)</li>
 	<li>Vagrant/Hashicorp Atlas (thanks to &a.brd;)</li>
       </ul>
 
       <p>The &os; Release Engineering Team would like to thank these
 	developers for all of the work that went into making this
 	possible, and would like to especially thank &a.marcel; for
 	all of his work on the <tt>mkimg(1)</tt> utility, especially
 	for adding support for the various file formats requested.</p>
 
       <p>In addition to the enhancements to the virtual machine build
 	tools, a significant amount of work went into refactoring the
 	build code used to produce &os;/arm images.</p>
 
       <p>With much of the logic resembling how the <tt>Crochet</tt>
 	utility (written by &a.kientzle;) works, and a significant
 	amount of work, input, and advice from &a.ian;, &a.imp;,
 	&a.andrew;, &a.loos;, and a large number of contributors on
 	the <tt>freebsd-arm@FreeBSD.org</tt> mailing list, the &os;
 	Release Engineering tools now natively support producing
 	&os;/arm images without external build tools.</p>
 
       <p>At present, the build tools support building &os;/arm
 	images for:</p>
 
       <ul>
 	<li><tt>BEAGLEBONE</tt></li>
 	<li><tt>CUBOX/HUMMINGBOARD</tt></li>
 	<li><tt>GUMSTIX</tt></li>
 	<li><tt>RPI-B</tt></li>
 	<li><tt>RPI2</tt> (&os;-CURRENT only)</li>
 	<li><tt>PANDABOARD</tt></li>
 	<li><tt>WANDBOARD</tt></li>
       </ul>
 
       <p>The &os; Release Engineering Team would like to thank each
 	of these people for their support and input, and would like to
 	especially thank &a.kientzle; for his work on
 	<tt>Crochet</tt>.  Without it, we might not have been able to
 	produce images for the various boards that we are able to
 	now.</p>
 
       <p>For more information on what else has changed in &os; since
 	10.1-RELEASE, see the
 	<a href="https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html">&os;&nbsp;10.1-STABLE release notes</a>
 	(which will become the release notes for 10.2-RELEASE).</p>
 
       <p>Additionally, &a.gjb; would like to thank Jim Thompson for
 	providing a BeagleBone Black board (replacing one that no
 	longer worked), and Benjamin Perrault for providing
 	a PandaBoard ES, both of which are used for locally testing
 	the images produced by the build tools.</p>
 
       <p>Last, and certainly not least, &a.gjb; would also like to
 	thank the &os;&nbsp;Foundation for their support, and for
 	providing the resources (time and hardware) required to make
 	all of the items mentioned in this status report possible.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
   </project>
 
   <project cat='misc'>
     <title>BSDCan 2015</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Dan</given>
 	  <common>Langille</common>
 	</name>
 	<email>dvl@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.bsdcan.org/2015/">BSDCan 2015</url>
       <url href="https://www.youtube.com/playlist?list=PLWW0CjV-TafY0NqFDvD4k31CtnX-CGn8f">BSDCan
 	2015 Video Playlist</url>
     </links>
 
     <body>
       <p>BSDCan, a conference for people working on and with
 	4.4BSD-based operating systems and related projects, was held
 	in Ottawa, Ontario on June 12 and 13.  A two-day &os;
 	developer summit event preceded it on June 10 and 11.</p>
 
       <p>This was the largest BSDCan ever, with over 280 attendees, up
 	by more than 40 people over the 2014 event.  There were a
 	record number of speakers and talks.  An additional room and
 	"track" was added to provide even more choices for concurrent
 	talks on both days of the conference.  Social media response
 	to the whole conference has been very positive.</p>
 
       <p>The keynote talk by Stephen Bourne was very popular.  So
 	popular, in fact, that the main conference room could not hold
 	all the attendees.  An overflow room with live video was set
 	up to hold the extra people.  The
 	<a href="https://www.youtube.com/watch?v=2kEJoWfobpA">video</a>
 	of the presentation has had over 6300 views in the first
 	twelve days.</p>
 
       <p>Andrew Tanenbaum's talk on
 	<a href="https://www.youtube.com/watch?v=0pebP891V0c">reimplementing NetBSD using a MicroKernel</a>
 	was so well-attended it was standing room only.</p>
 
       <p>There were many other excellent talks, and we recommend
 	browsing through the playlist in the links above.</p>
 
       <p>Activity was not limited to the talks.  Each night, the
 	"Hacker Lounge" was used by developers to cooperate and
 	interact on projects.  Embedded projects were popular this
 	year, as FreeBSD was installed directly on wireless
 	routers.</p>
 
       <p>The very successful and well-attended closing event, held
 	at the Lowerton Brewery, provided an elegant closure to the
 	whole conference.</p>
 
       <p>We would like to thank everyone who made BSDCan 2015 such a
 	success, and look forward to next year!</p>
     </body>
   </project>
 
   <project cat='kern'>
     <title>Adding PCIe Hot-plug Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>John-Mark</given>
 	  <common>Gurney</common>
 	</name>
 	<email>jmg@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/pciehotplug">PCIe
 	Hot-plug P4 Branch</url>
       <url href="https://svnweb.freebsd.org/changeset/base/r281874">Commit
 	adding bridge save/restore.</url>
       <url href="https://github.com/FreeBSDFoundation/freebsd/tree/pciehp">Github
 	branch with patches</url>
     </links>
 
     <body>
       <p>PCI Express (PCIe) hot-plug is used on both laptops and
 	servers to allow peripheral devices to be added or removed
 	while the system is running.  Laptops commonly include
 	hot-pluggable PCIe as either an ExpressCard slot or
 	a Thunderbolt interface.  ExpressCard has built in USB support
 	that is already supported by &os;, but ExpressCard PCIe
 	devices like Gigabit Ethernet adapters and eSATA cards are
 	only supported when they are present at boot, and removal may
 	cause &os; to crash.</p>
 
       <p>The goal of this project is to allow these devices to be
 	inserted and removed while &os; is running.  The work will
 	provide the basic infrastructure to support adding and
 	removing devices, though it is expected that additional work
 	will be needed to update individual drivers to support
 	hot-plug.</p>
 
       <p>Current testing is focused on getting a simple UART device
 	functional.  Basic hot swap is functional.</p>
 
       <p>A set of the patches is now available on github.com.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <help>
       <task>
 	<p>Get suspend/resume functional by save/restoring necessary
 	  registers.  This should be addressed by r281874.</p>
       </task>
 
       <task>
 	<p>Make sure that upon suspend, devices are removed so that
 	  any hardware changes made while the machine is suspended
 	  are correctly handled.</p>
       </task>
 
       <task>
 	<p>Improve how state transitions are handled, possibly by
 	  using a proper state machine.</p>
       </task>
     </help>
   </project>
 
   <project cat='doc'>
     <title>Leap Seconds Article</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Warren</given>
 	  <common>Block</common>
 	</name>
 	<email>wblock@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html">Leap
 	Seconds Article</url>
     </links>
 
     <body>
       <p>As the leap second scheduled for the end of June approached,
 	Bartek Rutkowski and others raised questions about how &os;
 	handled leap seconds.  Leap seconds have caused serious
 	problems for other operating systems in the last few years,
 	and there was understandable concern.</p>
 
       <p>It was reasonably pointed out that &os; had encountered leap
 	seconds before, and would be fine this time also.  Still, the
 	absence of reported problems is not really a substitute for a
 	description of what to expect and how to know if a system is
 	prepared.</p>
 
       <p>To address concerns and also provide a resource for future
 	leap seconds, several experts were pestered relentlessly,
 	with the results compiled into a short article.  Beyond merely
 	allaying fears about what might happen, this article received
 	positive responses on the web for how it demonstrated &os;'s
 	maturity and preparedness.</p>
 
       <p>Great thanks for their patience and expertise are owed to
 	Peter Jeremy, Poul-Henning Kamp, Ian Lepore, Xin LI, Warner
 	Losh, and George Neville-Neil.</p>
     </body>
 
     <help>
       <task>
 	<p>Compile other short articles on things that &os; does
 	  really well.  Of particular interest are features that make
 	  life easier for sysadmins, or how problems on other systems
 	  are dealt with or even made non-problems on &os;.</p>
       </task>
     </help>
   </project>
 
   <project cat='team'>
     <title>The &os; Core Team</title>
 
     <contact>
       <person>
 	<name>&os; Core Team</name>
 	<email>core@FreeBSD.org</email>
       </person>
     </contact>
 
     <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>
 
       <p>In order to help attract fresh developer talent to &os;, Core
 	has a general policy to make available an up-to-the-minute
 	suite of developer tools and services.  Core has long been
 	encouraging &os; committers to make full use of the project's
 	Phabricator instance at
 	<a href="https://reviews.FreeBSD.org/">https://reviews.FreeBSD.org</a>,
 	and now has supported the Phabricator admins in opening access
 	to anyone interested enough to sign up for an account.</p>
 
       <p>Further developments under consideration include setting up a
 	FreeBSD.org OAuth 2 provider and permitting OAuth-style Single
 	Sign-On access to most FreeBSD web-based services.  Developers
 	and members of the public would additionally be able to use
 	credentials from other providers such as GitHub, Twitter, or
 	Google to authenticate themselves to &os; web services.</p>
 
       <p>Mark Murray raised a problem he has been having for some time
 	with getting adequate security review of his proposed changes
 	to <tt>random(9)</tt>.  This is an extremely security
 	sensitive area of the kernel where errors can have disastrous
 	consequences.  Core has been able to drum up a number of
 	reviewers and they have made significant progress in
 	simplifying the design, eliminating some difficult portions of
 	code, and reducing any potential attack surface.  Work is
 	still ongoing and Core remains open to the idea of bringing in
 	external reviewers with specialist cryptographic
 	knowledge.</p>
 
       <p>Dag-Erling Sm&oslash;rgrav resigned as Security Officer
 	towards the end of May.  Core was sorry to see him step down,
 	but unanimously pleased to welcome his nominee and former
 	deputy, Xin Li, as his successor.  Xin has since appointed
 	Gleb Smirnoff (who also happens to be a current member of
 	core) as his new deputy.  Between them and Core they have some
 	fairly radical ideas under discussion about how to improve the
 	project's responsiveness to security issues.</p>
 
       <p>In mid-June, a change to <tt>style(9)</tt> was proposed, and
 	resulted in much lively discussion.  Warner Losh conducted an
 	informal poll with Phabricator and the change was approved and
 	committed within a couple of days.  Unfortunately, complaints
 	were raised about the timing and voting methods and Core was
 	called upon to arbitrate.  The change was backed out
 	voluntarily, a new poll was held with more time to vote, and
 	the change was approved.</p>
 
       <p>During this period we had two new commit bits awarded, and
 	one taken in for safekeeping.  Welcome aboard to Chris Torek
 	and Mariusz Zaborski, and we were very sorry indeed to see
 	Steve Kargl decide to call it a day.</p>
     </body>
   </project>
 
   <project cat='kern'>
     <title>CloudABI: Capability-Based Runtime Environment</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Schouten</common>
 	</name>
 	<email>ed@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://github.com/NuxiNL/cloudlibc">CloudABI
 	on GitHub</url>
       <url href="https://github.com/NuxiNL/freebsd">FreeBSD patchset
 	on GitHub</url>
     </links>
 
     <body>
       <p>CloudABI is a compact UNIX-like runtime environment that is
 	purely based on capability-based security (Capsicum).  All
 	features that are incompatible with this model have been
 	removed.  Advantages of using a pure capability-based
 	environment include improved security, testability, and
 	reusability.  CloudABI should make it possible to run
 	arbitrary third-party executables directly on top of &os;
 	without any impact on system security, making it a good
 	building block for a cluster/cloud computing setup.  See
 	<a href="https://github.com/NuxiNL/cloudlibc">the project on GitHub</a>
 	for a more detailed explanation.</p>
 
       <p>Last month I added a number of packages for the &os; Ports
 	tree.  We now have a full C/C++ cross compiler that can be
 	installed very easily
 	(<a href="http://www.freshports.org/devel/cloudabi-toolchain">devel/cloudabi-toolchain</a>).
 	I also imported a tool called <tt>cloudabi-run</tt> that can
 	be used to start programs safely, only granting access to
 	files and network sockets listed in the program's
 	configuration file
 	(<a href="http://www.freshports.org/sysutils/cloudabi-utils">sysutils/cloudabi-utils</a>).</p>
 
       <p>I have also imported some kernelspace modifications into the
 	&os; source tree for executing CloudABI programs.  After all
 	of these changes have been imported, just loading a kernel
 	module will allow executing CloudABI programs.  Right now, the
 	"cloudabi" branch on GitHub is still required.</p>
     </body>
 
     <sponsor>
       Nuxi, the Netherlands
     </sponsor>
 
     <help>
       <task>
 	<p>Polish up the kernelspace modifications and send them out
 	  for review.</p>
       </task>
 
       <task>
 	<p>Complete the Linux and NetBSD kernel patchsets and send
 	  those out to the respective maintainers.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>Sleep States Enhancements on <tt>x86</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>Konstantin</given>
 	  <common>Belousov</common>
 	</name>
 	<email>kib@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://svnweb.freebsd.org/base?view=revision&amp;revision=282678">Commit
 	r282678</url>
     </links>
 
     <body>
       <p>The ACPI specication defines CPU Cx states, which are idle
 	states.  Methods to enter the state and miscellaneous
 	information like the state-leave latency are returned by the _CST
 	ACPI method.  To save energy and reduce useless heating, the
 	operating system enters a Cx state when the CPU has no work
 	to do.  C0 is the non-idle state, while C1, C2, and C3
 	(defined by ACPI) each represent an idle state with
 	sequentially more energy saving, but also with higher latency
 	of leave and possibly greater secondary costs.  For example,
 	C1 is entered by executing the HLT instruction and has no
 	architecturally visible side effects, while entering C3 drops
 	the CPU cache and usually requires special chipset programming
 	to correctly handle requests from I/O devices to the CPU.  Do
 	not confuse Cx, Px and Sx: Cx states are only meaningful when
 	the system is in the fully operational state S0; Px states are
 	only meaningful when the system is not in the idle state,
 	C0.</p>
 
       <p>Modern Intel CPUs enter Cx (x &gt;= 1) states with the
 	dedicated instruction MWAIT, which enters a specified
 	low-power state until a specific write is observed by the CPU
 	bus logic.  There is a complimentary MONITOR instruction to
 	set the monitored bus address.  The legacy port I/O method of
 	entering Cx state is emulated by CPU microcode, which
 	intercepts the port I/O and executes MWAIT internally.  Using
 	MWAIT as the method of entering Cx requires following
 	processor-specific procedures, which are communicated to the
 	operating system by the vendor-specific extensions in _CST.
 	The operating system must indicate readiness to support MWAIT
 	when calling _CST. Claimed benefits of using MWAIT are reduced
 	latencies of leaving the idle state, and visibility of more
 	deep states than defined by the common ACPI specification.
 	Still, modern Intel platforms report deep states as C2 to
 	avoid the not needed bus-mastering avoidance.</p>
 
       <p>The new code asks ACPI for the Intel vendor-specific _CST
 	extensions, parses them, and uses MWAIT Cx entrance methods
 	when available.  The change was committed as r282678 to
 	HEAD.</p>
 
       <p>For Linux, Intel provides a driver which does not depend on
 	the ACPI tables to use MWAIT for entering Cx states.  For all
 	Intel CPUs after Core2, the driver contains the description of
 	the Cx mode latencies and quirks, eliminating dependency on
 	correct BIOS information, since the BIOS information is often
 	incorrect.  The
 	approach of porting the Linux driver was considered by several
 	people, but all evaluators independently concluded that the
 	project cannot maintain such an approach without direct
 	involvement from Intel.</p>
 
       <p>During the work, around 500 lines of identical code between
 	the i386 and amd64 versions of idle handling were moved to
 	a common location <tt>x86/x86/cpu_machdep.c</tt>.  Now the
 	i386 and amd64 <tt>machdep.c</tt> files contain only unique
 	machine-dependent routines.  This advance depended on John
 	Baldwin's elimination of the unmaintained Xen PVM i386
 	port.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
   </project>
 
   <project cat='kern'>
     <title>Rewritten PCID Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Konstantin</given>
 	  <common>Belousov</common>
 	</name>
 	<email>kib@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://svnweb.freebsd.org/base?view=revision&amp;revision=282684">Commit
 	r282684</url>
     </links>
 
     <body>
       <p>A Process-Context Identifier (PCID) is a
 	performance-enhancing feature of the Translation Lookaside
 	Buffer (TLB) on Intel processors, introduced with the Sandy
 	Bridge micro-architecture.  It allows the TLB to
 	simultaneously cache translation information for several
 	address spaces, and gives an opportunity for the operating
 	system context switch code to avoid flushing the TLB upon
 	process switch.  Each cached translation is tagged with some
 	context identifier, and at context switch time, the operating
 	system instructs the processor which context is becoming
 	active.  The feature slightly reduces context switch time by
 	avoiding TLB flushes, and more importantly, reduces the warm-up
 	period for a thread after context switch.</p>
 
       <p>&os; already used PCID, but the existing implementation
 	had several shortcomings.  The <tt>amd64</tt> pmap (the
 	machine-dependent portion of the virtual memory subsystem)
 	maintained a bitmap of all CPUs which ever loaded a
 	translation for the given address space, and avoided TLB flush
 	on the context switch.  The bitmap was used to direct
 	Inter-Processor Interrupts to the marked CPU when the
 	operating system needed to perform TLB invalidation.  The most
 	significant deficiency of the old implementation was the increase of
 	TLB invalidation IPIs, since the bitmap could only grow until
 	a full TLB shootdown was performed.  It increased the TLB rate,
 	which negated the positive effects of avoiding TLB flushes on
 	large machines.  Secondarily, the bitmap maintenance in both
 	the pmap and the context code was quite complicated, leading
 	to bugs.  These issues resulted in the PCID feature being
 	disabled by default.</p>
 
       <p>The new PCID implementation uses an algorithm described in
 	the U. Vahalia book "UNIX Internals: The New Frontiers".  The
 	algorithm is already used, for example, by the MIPS pmap for
 	assigning Address Space Identifiers (ASIDs) to
 	software-managed TLB entries.  The pmap maintains a per-CPU
 	generation count, which is assigned to the next unused PCID
 	when the context is activated on CPU.  TLB invalidation
 	includes resetting the generation count, which causes
 	reallocation of the PCID when a context switch is performed.
 	As result, the new implementation issues exactly the same
 	amount of shootdown IPIs as a pmap which does not utilize
 	PCID.</p>
 
       <p>Another change included with the PCID rewrite is a move of
 	the address space switching code from assembler to C source,
 	making the algorithm easier to understand and validate.</p>
 
       <p>Measurements done with <tt>hwpmc(4)</tt> on a Haswell machine
 	indicated that the new implementation reduced the TLB miss
 	rate by up to 10 times, without an increase in TLB shootdown
 	IPIs.</p>
 
       <p>The rewrite was committed to HEAD at r282684.</p>
 
       <p>Note: AMD processors do not have the PCID feature for host paging
 	(AMD provides ASIDs for SVM use).  But it is likely that AMD
 	processors do cache TLB translations for different address
 	spaces transparently, and snoop writes to the page tables to
 	invalidate the caches.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title>Mellanox iSCSI Extensions For RDMA (iSER) Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Max</given>
 	  <common>Gurtovoy</common>
 	</name>
 	<email>maxg@mellanox.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Sagi</given>
 	  <common>Grimberg</common>
 	</name>
 	<email>sagig@mellanox.com</email>
       </person>
     </contact>
 
     <links>
       <url
 	href="https://github.com/sagigrimberg/iser-freebsd">iser-freebsd
 	on GitHub</url>
     </links>
 
     <body>
       <p>Building on the new in-kernel iSCSI initiator stack released
 	in &os; 10.0 and the recently added iSCSI offload interface,
 	Mellanox Technologies has begun developing iSCSI extensions
 	for RDMA (iSER) initiator support to enable efficient data
 	movement using the hardware offload capabilities of Mellanox's
 	10, 40, 56 and 100 Gigabit IB/Ethernet adapters.</p>
 
       <p>Remote Direct Memory Access (RDMA) has been shown to have a
 	great value for storage applications.  RDMA infrastructure
 	provides benefits such as Zero-Copy, CPU offload, Reliable
 	transport, Fabric consolidation, and many more.  The iSER
 	protocol eliminates some of the bottlenecks in the traditional
 	iSCSI/TCP stack, provides low latency and high throughput, and
 	is well suited for latency aware workloads.</p>
 
       <p>This work includes a new ICL module that implements the iSER
 	initiator.  The iSCSI stack is slightly modified to support
 	some extra features such as asynchronous IO completions,
 	unmapped data buffers, and data-transfer offloads.  The user
 	will be able to choose iSER as the iSCSI transport with
 	<tt>iscsictl</tt>.</p>
 
       <p>The project is in its beta phase.  Recent additions
 	include:</p>
 
       <ul>
 	<li>Rebased on top of 11-CURRENT (r284921)</li>
 	<li>Added discovery over iSER support</li>
 	<li>HA and automatic session re-establishment support</li>
 	<li>Split iSER from iSCSI module</li>
       </ul>
 
       <p>In addition, the <tt>iser</tt> driver has been and continues
 	to be thoroughly tested.  The test suite includes:</p>
 
       <ul>
 	<li>traffic</li>
 	<li>FS tests</li>
 	<li>compliance tests</li>
 	<li>traffic failover/failback</li>
 	<li>session recovery</li>
 	<li>dynamic module load/unload</li>
       </ul>
 
       <p>The code is ready for inclusion and will be released under
 	the BSD license.</p>
     </body>
 
     <sponsor>
       Mellanox Technologies
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title>Root Remount</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Edward Tomasz</given>
 	  <common>Napiera&lstrok;a</common>
 	</name>
 	<email>trasz@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>One of the long missing features of &os; was the ability to
 	boot with a temporary rootfs, configure the kernel to be able
 	to access the real rootfs, and then replace the temporary root
 	with the real one.  In Linux, the functionality is known as
 	<tt>pivot_root</tt>.  The reroot project aims to provide
 	similar functionality in a different, slightly more
 	user-friendly way: rerooting.  Simply put, from the user point
 	of view it looks like the system performs a partial shutdown,
 	killing all processes and unmounting the rootfs, and then
 	partial bringup, mounting the new rootfs, running init, and
 	running the startup scripts as usual.</p>
 
       <p>The project is in the late implementation phase.  A working
 	prototype was written, and work is in process to rewrite it in
 	an architecturally nicer way.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <help>
       <task>
 	<p>Complete debugging</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title>Ports Collection</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Frederic</given>
 	  <common>Culot</common>
 	</name>
 	<email>portmgr-secretary@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>&os; Ports Management Team</name>
 	<email>portmgr@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.FreeBSD.org/ports/">The Ports
 	Collection</url>
       <url href="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/">Contributing
 	to Ports</url>
       <url href="http://portsmon.freebsd.org/index.html">&os; Ports
 	Monitoring System</url>
       <url href="http://www.freebsd.org/portmgr/index.html">Ports
 	Management Team</url>
       <url href="http://blogs.freebsdish.org/portmgr/">portmgr
 	Blog</url>
       <url href="http://www.twitter.com/freebsd_portmgr/">portmgr on
 	Twitter</url>
       <url href="http://www.facebook.com/portmgr">portmgr on
 	Facebook</url>
       <url href="http://plus.google.com/communities/108335846196454338383">portmgr
 	on Google+</url>
     </links>
 
     <body>
       <p>As of the end of the second quarter, the ports tree holds
 	nearly 25,000 ports and the PR count is about 1,800.  Once
 	again, the tree saw more activity than during the previous
 	quarter, with almost 8,000 commits performed by 153 active
 	committers.  On the other hand, the number of problem reports
 	closed decreased slightly, with a bit less than 1,700 problem
 	reports fixed.</p>
 
       <p>In the second quarter, several commit bits were taken in for
 	safekeeping, following an inactivity period of more than 18
 	months (clsung, dhn, obrien, tmseck), or on committer's
 	request (sahil).  Two new developers were granted a ports
 	commit bit (Michael Moll - mmoll@, and Bernard Spil -
 	brnrd@).</p>
 
       <p>On the management side, pgollucci@ started his four-month
 	term as portmgr-lurker in June, and no changes were made to
 	the portmgr team during the second quarter.</p>
 
       <p>This quarter also saw the release of the second quarterly
 	branch, namely <tt>2015Q2</tt>.  On this branch, 39 committers
 	applied 305 patches, which is more than twice as many updates
 	as during the last quarter.</p>
 
       <p>On the quality assurance side, 30 exp-runs were performed to
 	validate sensitive updates or cleanups.  Amongst those
 	noticeable changes are the update to pkg 1.5.4, three new
 	<tt>USES</tt> (<tt>waf</tt>, <tt>gnustep</tt>, <tt>jpeg</tt>),
 	the Perl default switch to 5.20, Ruby to 2.1.6, Firefox
 	38.0.6, and Chromium 43.0.2357.130.</p>
     </body>
 
     <help>
       <task>
 	<p>As in the previous quarter, a tremendous amount of work
 	  was done on the tree to update major ports and to close even
 	  more PRs than in 2015 Q1, but as always, any additional help
 	  is greatly appreciated!</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>OpenBSM</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Robert</given>
 	  <common>Watson</common>
 	</name>
 	<email>rwatson@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Christian</given>
 	  <common>Brueffer</common>
 	</name>
 	<email>brueffer@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>TrustedBSD audit mailing list</name>
 	<email>trustedbsd-audit@TrustedBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.openbsm.org/">OpenBSM: Open Source Basic
 	Security Module (BSM) Audit Implementation</url>
       <url href="https://github.com/openbsm/openbsm">openbsm on
 	GitHub</url>
     </links>
 
     <body>
       <p>OpenBSM is a BSD-licensed implementation of Sun's Basic
 	Security Module (BSM) API and file format.  It is the user
 	space side of the CAPP Audit implementations in &os; and Mac
 	OS X.  Additionally, the audit trail processing tools are
 	expected to work on Linux.</p>
 
       <p>After a period of dormancy, the project is slowly picking up
 	steam again.  The OpenBSM source code repository was migrated
 	from &os;'s Perforce server to GitHub.  We hope this will make
 	the code more accessible and stimulate outside contributions.
 	In addition to the repository migration, automated build
 	testing using Travis CI has been enabled, and initial steps
 	towards a new test release have been made.</p>
     </body>
 
     <help>
       <task>
 	<p>Test the code on GitHub on different releases of Mac OS X
-	  and Linux</p>
+	  and Linux.  Especially testing on Mac OS X 10.9 (Mavericks)
+	  and newer would be greatly appreciated.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>Address Space Layout Randomization (ASLR)</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Shawn</given>
 	  <common>Webb</common>
 	</name>
 	<email>shawn.webb@hardenedbsd.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Oliver</given>
 	  <common>Pinter</common>
 	</name>
 	<email>oliver.pinter@hardenedbsd.org</email>
       </person>
 
       <person>
 	<name>HardenedBSD</name>
 	<email>core@hardenedbsd.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://hardenedbsd.org/">HardenedBSD</url>
       <url href="https://hardenedbsd.org/article/shawn-webb/2015-06-30/introducing-true-stack-randomization">True
 	Stack Randomization</url>
       <url href="https://hardenedbsd.org/article/shawn-webb/2015-07-06/announcing-aslr-completion">Announcing
 	ASLR Completion</url>
       <url href="https://hardenedbsd.org/article/shawn-webb/2015-07-11/call-donations">Call
 	for Donations</url>
       <url href="https://www.soldierx.com/">SoldierX</url>
     </links>
 
     <body>
       <p>HardenedBSD is a downstream distribution of &os; aimed at
 	implementing exploit mitigation and security technologies.
 	The HardenedBSD development team has focused on several key
 	features, one being Address Space Layout Randomization (ASLR).
 	ASLR is a computer security technique that aids in mitigating
 	low-level vulnerabilities such as buffer overflows.  ASLR
 	randomizes the memory layout of running applications to
 	prevent an attacker from knowing where a given vulnerability
 	lies in memory.</p>
 
       <p>This last quarter, the HardenedBSD team has finalized the
 	core implementation of ASLR.  We implemented true stack
 	randomization along with a random stack gap.  This change
 	allows us to apply 42 bits of entropy to the stack, the
 	highest of any operating system.  We bumped the
 	<tt>hardening.pax.aslr.stack_len</tt> <tt>sysctl(8)</tt> to 42
 	by default on amd64.</p>
 
       <p>We also now randomize the Virtual Dynamic Shared Object
 	(VDSO).  The VDSO is one or more pages of memory shared
 	between the kernel and the userland.  On amd64, it contains
 	the signal trampoline and timing code
 	(<tt>gettimeofday(4)</tt>, for example).</p>
 
       <p>With these two changes, the ASLR implementation is now
 	complete.  There are still tasks to work on, however.  We need
 	to update our documentation and enhance a few pieces of code.
 	Our ASLR implementation is in use in production by HardenedBSD
 	and is performing robustly.</p>
 
       <p>Additionally, we are currently running a fundraiser to help
 	us establish a not-for-profit organization and for hardware
 	updates.  We have received a lot of help from the community
 	and we greatly appreciate the help.  We need further help
 	to take the project to the next level.  We look forward to
 	working with the &os; project in providing excellent
 	security.</p>
     </body>
 
     <sponsor>
       SoldierX
     </sponsor>
 
     <help>
       <task>
 	<p>Update the <tt>aslr(4)</tt> manpage and the wiki
 	page.</p>
       </task>
 
       <task>
 	<p>Improve the Shared Object load order feature with Michael
 	  Zandi's improvements.</p>
       </task>
 
       <task>
 	<p>Re-port the ASLR work to vanilla &os;.  Include the
 	  custom work requested by &os; developers.</p>
       </task>
 
       <task>
 	<p>Close the existing review on Phabricator.</p>
       </task>
 
       <task>
 	<p>Open multiple smaller reviews for pieces of the ASLR
 	  patch that can be split out logically.</p>
       </task>
 
       <task>
 	<p>Perform a special backport to HardenedBSD 10-STABLE for
 	  OPNSense to pull in.</p>
       </task>
 
       <task>
 	<p><tt>golang</tt> segfaults in HardenedBSD.  Help would be
 	  nice in debugging.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>OPNsense</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Franco</given>
 	  <common>Fichtner</common>
 	</name>
 	<email>franco@opnsense.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ad</given>
 	  <common>Schellevis</common>
 	</name>
 	<email>ad@opnsense.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Jos</given>
 	  <common>Schellevis</common>
 	</name>
 	<email>jos@opnsense.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://opnsense.org">OPNsense website</url>
       <url href="https://github.com/opnsense">OPNsense source
 	code</url>
     </links>
 
     <body>
       <p>OPNsense is a fork of pfSense that aims to follow &os;'s
 	code base and ecosystem quickly and closely while retaining
 	the parent's powerful firewall capabilities.  The new 15.7
 	release includes efforts such as firmware upgrades and
 	packaging fully based on <tt>pkg</tt>, weekly security
 	updates, the replacement of ALTQ-based traffic shaping with
 	IPFW/dummynet, and production-ready LibreSSL integration as an
 	alternative to OpenSSL.</p>
 
       <p>Contributors and testers are welcome as we work on
 	redesigning plugin support, rework the GUI according to modern
 	coding standards (MVC) and privilege separation.</p>
     </body>
 
     <sponsor>
       Deciso
     </sponsor>
   </project>
 
   <project cat="proj">
     <title>Linux Binary Emulation Layer Upgrade</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Allan</given>
 	  <common>Jude</common>
 	</name>
 	<email>AllanJude@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Dmitry</given>
 	  <common>Chagin</common>
 	</name>
 	<email>dchagin@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Maste</common>
 	</name>
 	<email>emaste@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Edward Tomasz</given>
 	  <common>Napiera&lstrok;a</common>
 	</name>
 	<email>trasz@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Johannes</given>
 	  <common>Meixner</common>
 	</name>
 	<email>xmj@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>FreeBSD Emulation Team</name>
 	<email>emulation@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/Emulation">Emulation team
 	on &os; wiki</url>
     </links>
 
     <body>
       <p>The &os; emulation team has done extensive work on polishing
 	&os;'s Linux emulation layer.  After more than a year and a
 	half, Dmitry Chagin's changes to the Linux binary emulation
 	layer were merged into &os; 11.0-CURRENT.  Before merging the
 	more than 115 individual changes into <tt>base/head</tt>, Ed
 	Maste and Edward Tomasz Napiera&lstrok;a were able to help by
 	reviewing and improving the code quality.</p>
 
       <p>Work has begun on backporting these changes into &os;
 	10-STABLE, with the current 10.2 release cycle in mind.  We
 	hope to have that backport ready before 10.2-PRERELEASE turns
 	into 10.2-RELEASE.</p>
 
       <p>In that same vein, Allan Jude was able to upload and improve
 	a recent Differential Revision that will eventually lead to
 	our having both 32-bit and 64-bit ports for CentOS 6.  Port
 	review activity started during the BSDCan conference's
 	developer summit, and will be continued extensively during the
 	Cambridge Developer Summit.</p>
 
       <p>We are currently expecting to have both Fedora 10, Centos 6
 	32-bit- and CentOS 6 64-bit-compatible frameworks available by
 	Q4/2015.</p>
 
       <p>Call for Help: Contributing</p>
 
       <p>People can contribute to the Emulation team's efforts by
 	testing the CentOS 64-bit changes on a &os; 11.0-CURRENT
 	system.  Please use Bugzilla to report any bugs or oddities
 	encountered.</p>
 
       <p>For the ambitious: we are planning to start working on a
 	CentOS 7 framework.  CentOS7 is 64-bit only, uses a newer
 	kernel, and has <tt>systemd</tt>, so this work is highly
 	experimental.  We hope to have a usable port by Q2/2016.</p>
     </body>
 
     <sponsor>
       Perceivon Hosting Inc.
     </sponsor>
 
     <sponsor>
       ScaleEngine Inc.
     </sponsor>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <!-- Dmitry, think about putting your employer here ;-)
     <sponsor>
       Optional sponsor
     </sponsor> -->
 
     <help>
       <task>
 	<p>Test 64-bit Linux emulation on 11.0-CURRENT</p>
       </task>
 
       <task>
 	<p>Backport 64-bit Linux emulation to 10-STABLE</p>
       </task>
 
       <task>
 	<p>Review 64-bit CentOS 6 ports and merge changes</p>
       </task>
 
       <task>
 	<p>Create/heavily update existing 64-bit CentOS 7 ports</p>
       </task>
 
       <task>
 	<p>Anyone who would like to get in touch should not hesitate
 	  to contact any of the <tt>emulation@</tt> team members.
 	  Similarly, a mail to <tt>emulation@FreeBSD.org</tt> is
 	  always welcome.</p>
       </task>
     </help>
   </project>
 
   <project cat='team'>
     <title>&os; Cluster Administration Team</title>
 
     <contact>
       <person>
 	<name>&os; Cluster Administration Team</name>
 	<!-- email intentionally left incomplete -->
 	<email>clusteradm@</email>
       </person>
     </contact>
 
     <body>
       <p>The &os; Cluster Administration Team consists of the people
 	responsible for administering the machines that the project
 	relies on for its distributed work and communications to be
 	synchronised.  In this quarter, the team has been extremely
 	busy with work both visible and invisible from outside of the
 	&os;&nbsp;infrastructure.</p>
 
       <ul>
 	<li>Migrated reference machines used by &os; developers to the
 	  new machines purchased by the &os;&nbsp;Foundation at
 	  New York Internet</li>
 
 	<li>Separated email services (and single-point-of-failure
 	  cases) from the machine that has been handling this task for
 	  over 18 years, to new, single-purpose service
 	  installations</li>
 
 	<li>Reorganized the infrastructure, serving repositories
 	  hosted by <tt>svn.freebsd.org</tt> to GeoDNS-backed mirrors,
 	  all with a single, official SSL certificate</li>
 
 	<li>Increased multi-site redundancy for public and non-public
 	  services throughout, at present, eight world-wide geographic
 	  sites</li>
       </ul>
 
       <p>While an enormous amount of this work was volunteer-driven,
 	resources (time and hardware) were generously provided by the
 	&os;&nbsp;Foundation.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation (time and hardware)
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title><tt>bhyve</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>Peter</given>
 	  <common>Grehan</common>
 	</name>
 	<email>grehan@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Neel</given>
 	  <common>Natu</common>
 	</name>
 	<email>neel@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Tycho</given>
 	  <common>Nightingale</common>
 	</name>
 	<email>tychon@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Allan</given>
 	  <common>Jude</common>
 	</name>
 	<email>freebsd@allanjude.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Alexander</given>
 	  <common>Motin</common>
 	</name>
 	<email>mav@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Marcelo</given>
 	  <common>Araujo</common>
 	</name>
 	<email>araujo@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.bhyve.org">bhyve FAQ and talks</url>
     </links>
 
     <body>
       <p><tt>bhyve</tt> is a hypervisor that runs on the FreeBSD/amd64
 	platform.  At present, it runs FreeBSD (8.x or later), Linux
 	i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests.
 	Current development is focused on enabling additional guest
 	operating systems and implementing features found in other
 	hypervisors.</p>
 
       <p><tt>bhyve</tt> BoF at BSDCan 2015</p>
 
       <p>A <tt>bhyve</tt> BoF was held during lunch hour at BSDCan
 	2015.  It was attended by approximately 60 people.</p>
 
       <p>Michael Dexter showed Windows Server 2012 running inside
 	bhyve.</p>
 
       <p>Common themes that came up during the discussion were:
 	<tt>bhyve</tt> configuration, libvirt and OpenStack
 	integration, best practices, <tt>bhyve</tt> with ZFS,
 	additional guest support and live migration.</p>
 
       <p>Google Summer of Code 2015</p>
 
       <p>A number of bhyve-related proposals were submitted for GSoC
 	2015 and these four were accepted:</p>
 
       <ul>
 	<li><a
 	    href="https://wiki.freebsd.org/SummerOfCode2015/NE2000EmulationForBhyve">NE2000
 	    device emulation</a></li>
 
 	<li><a
 	    href="https://wiki.freebsd.org/SummerOfCode2015/PortingBhyveToArm">Porting
 	    bhyve to ARM</a></li>
 
 	<li><a
 	    href="https://wiki.freebsd.org/SummerOfCode2015/ptnetmapOnBhyve">ptnetmap
 	    support in bhyve</a></li>
 
 	<li><a
 	    href="https://wiki.freebsd.org/SummerOfCode2015/PXEbhyve">PXE
 	    boot support in bhyveload</a></li>
       </ul>
 
       <p>A number of improvements were made to <tt>bhyve</tt> this
 	quarter:</p>
 
       <ul>
 	<li>GEOM storage backend now works properly with
 	  <tt>bhyve</tt>.</li>
 
 	<li>Device model enhancements and new instruction emulations
 	  to support Windows guests.</li>
 
 	<li>Improve virtio-net performance by disabling queue
 	  notifications when not needed.</li>
 
 	<li>The dtrace FBT provider now works properly with
 	  vmm.ko.</li>
       </ul>
 
       <p>Marcelo Araujo and Allan Jude created a rough patch to make
 	<tt>bhyve</tt> parse a config file to replace the existing
 	method of configuration by command line invocation.  The rapid
 	pace of advancement in <tt>bhyve</tt> resulted in requiring a
 	much more complex config file.  A new design for the config
 	file, with support for the plugin architecture that will
 	eventually be introduced into <tt>bhyve</tt>, is now being
 	discussed.</p>
     </body>
 
     <help>
       <task>Improve documentation.</task>
 
       <task><tt>bhyveucl</tt> is a script for starting <tt>bhyve</tt>
 	instances based on a libUCL config file.  More information at
 	<a href="https://github.com/allanjude/bhyveucl">https://github.com/allanjude/bhyveucl</a>.</task>
 
       <task>Add support for <tt>virtio-scsi</tt>.</task>
 
       <task>Flexible networking backend: <tt>wanproxy</tt>,
 	<tt>vhost-net</tt></task>
 
       <task>Support running <tt>bhyve</tt> as non-root.</task>
 
       <task>Add filters for popular VM file formats (VMDK, VHD,
 	QCOW2).</task>
 
       <task>Implement an abstraction layer for video (no X11 or SDL in
 	base system).</task>
 
       <task>Suspend/resume support.</task>
 
       <task>Live Migration.</task>
 
       <task>Nested VT-x support (<tt>bhyve</tt> in
 	<tt>bhyve</tt>).</task>
 
       <task>Support for other architectures (ARM, MIPS, PPC).</task>
     </help>
   </project>
 
   <project cat='bin'>
     <title>Cleanup on <tt>pw(8)</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>Baptiste</given>
 	  <common>Daroussin</common>
 	</name>
 	<email>bapt@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p><tt>pw(8)</tt> is the utility to create, delete, and
 	modify users.  This tool has remained mostly untouched since
 	its creation, but needed updating.</p>
 
       <p>Lots of cleanup has been done:</p>
 
       <ul>
 	<li>Deduplication of code</li>
 
 	<li>Reduction of complexity by splitting into smaller
 	  functions</li>
 
 	<li>Reuse of existing code in base:
 	  <ul>
 	    <li><tt>sbuf(9)</tt> for buffered string</li>
 
 	    <li><tt>stringlist(3)</tt> for string arrays</li>
 
 	    <li><tt>gr_utils</tt> (from libutil) instead of homemade
 	      group manipulation</li>
 
 	    <li><tt>strptime(3)</tt> to parse time strings</li>
 	  </ul>
 	</li>
 
 	<li>Added validation on most input options, fixing some
 	  serious bugs due to bad usage of <tt>atoi(3)</tt></li>
 
 	<li>many regression tests added to test for regressions due to
 	  all of these changes</li>
       </ul>
 
       <p>A new feature was added:
 	<tt>pw -R <u>rootdir</u> <i>cmd</i></tt> which allows
 	cross manipulation of users.</p>
     </body>
 
     <help>
       <task>
 	<p>More cleanup.</p>
       </task>
 
       <task>
 	<p>More regression tests.</p>
       </task>
 
       <task>
 	<p>LDAP support?</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>1-Wire Kernel Driver Implementation</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Warner</given>
 	  <common>Losh</common>
 	</name>
 	<email>imp@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://reviews.freebsd.org/D2956">1-Wire Stuff:
 	Basics and Temperature</url>
     </links>
 
     <body>
       <p>This is a kernel driver implemetation of the Dallas
 	Semiconductor 1-Wire bus in a generic fashion.  While
 	temperature sensors are the only devices initially supported,
 	other devices should be easy to add.  Multiple devices on one
 	bus are supported.  Both normal and overdrive modes are
 	supported.</p>
 
       <p>Multiple temperature sensors have been well tested, but
 	there is a high bit error rate.  There are indications that
 	this is due to bad bit-read times.  The code is written with
 	enough resilience to cope with the problem by retrying, and
 	the error rate is low enough that a couple of retries paper
 	over many marginal issues.</p>
     </body>
 
     <help>
       <task>
 	<p>Implement the overdrive device.  Add overdrive capability
 	  to <tt>owc</tt> and provide an <tt>own</tt> method to allow
 	  the presentation drivers to know when it is safe to use the
 	  overdrive ROM commands.</p>
       </task>
 
       <task>
 	<p>Implement the Identification device.  This device just has
 	a class of 1 and no registers.</p>
       </task>
 
       <task>
 	<p>Implement non-FDT <tt>gpiobus</tt> attachment.</p>
       </task>
 
       <task>
 	<p>Test overdrive timings.</p>
       </task>
 
       <task>
 	<p>Implement other attachments for things like serial port or
 	  specialized 1-Wire controllers.</p>
       </task>
 
       <task>
 	<p>Use the system clock to implement more precise delays
 	  to improve the error rate.</p>
       </task>
 
       <task>
 	<p>Use interrupt mode for GPIO pins to time the transitions
 	  of the line to determine the bit values without busy
 	  waiting.  Use &os;'s fine-grained sleeping to do the same
 	  for write-one and write-zero routines.</p>
       </task>
 
       <task>
 	<p>Review the code at the URL above.</p>
       </task>
 
       <task>
 	<p>Test the code on a device other than a RPi, RPi 2, or
 	  BeagleBone Black.</p>
       </task>
 
       <task>
 	<p>Test the code on architectures besides <tt>armv6</tt>.</p>
       </task>
 
       <task>
 	<p>Implement streamlined temperature mode where the
 	  <tt>convert_t</tt> command is broadcast and a callback
 	  reads the values for all the devices detected on the
 	  bus.</p>
       </task>
 
       <task>
 	<p>Implement parasitic power mode.</p>
       </task>
     </help>
   </project>
 
   <project cat='arch'>
     <title>&os; on Cavium ThunderX (<tt>arm64</tt>)</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Dominik</given>
 	  <common>Ermel</common>
 	</name>
 	<email>der@semihalf.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Wojciech</given>
 	  <common>Macek</common>
 	</name>
 	<email>wma@semihalf.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Michal</given>
 	  <common>Stanek</common>
 	</name>
 	<email>mst@semihalf.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Zbigniew</given>
 	  <common>Bodek</common>
 	</name>
 	<email>zbb@semihalf.com</email>
       </person>
     </contact>
 
     <links>
       <url href="http://wiki.freebsd.org/arm64">&os; Wiki: arm64 page</url>
       <url href="https://youtu.be/lLgc4FJLJ3Y">Video: &os; on the 48-core
 	ThunderX (ARMv8)</url>
     </links>
 
     <body>
       <p>Since the previous report, ThunderX gained SMP support and
 	&os; is now running on 48 real-life ARMv8 CPU cores!  The
 	newly introduced functionality was based on initial
 	foundational work submitted by Andrew Turner and Robin
 	Randhawa, with emulation as the primary target.</p>
 
       <p>Semihalf's efforts focused on hardware, and include:</p>
 
       <ul>
 	<li>Multicore support for the newer Generic Interrupt
 	  Controller GICv3</li>
 
 	<li>Numerous bug fixes for:
 	  <ul>
 	    <li><tt>pmap(9)</tt> - memory attributes and TLB
 	    management</li>
 
 	    <li><tt>locore.S</tt> - secondary core initialization</li>
 
 	    <li>IPI (inter-processor interrupts)</li>
 
 	    <li>Per-CPU timers</li>
 
 	    <li>Size of early UMA allocations</li>
 
 	    <li>Cache maintenance</li>
 
 	    <li>Exceptions handling</li>
 
 	    <li>Stack issues</li>
 	  </ul></li>
 
 	<li>ThunderX-specific changes and quirks</li>
       </ul>
 
       <p>This support was introduced to the public at the &os; 2015
 	Developer Summit in Ottawa at a demo held by Semihalf and the
 	FreeBSD Foundation.  Cavium's ThunderX server CRB (Customer
 	Reference Board) is now capable of booting SMP &os; from both
 	the hard disk and from an NFS root using a PCIe networking
 	card.  The example setup is now available on the &os; test
 	cluster hosted at Sentex Communications.</p>
 
       <p>ThunderX support changes are currently being reviewed and
 	integrated into mainline &os;.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <sponsor>
       ARM Ltd.
     </sponsor>
 
     <sponsor>
       Cavium
     </sponsor>
 
     <sponsor>
       Semihalf
     </sponsor>
 
     <help>
       <task>
 	<p>Upstream ThunderX support to &os; HEAD</p>
       </task>
 
       <task>
 	<p>Support for multi-socket configuration of ThunderX (96 CPUs
 	  connected through coherent fabric)</p>
       </task>
 
       <task>
 	<p>Implement VNIC support (ThunderX networking controller)</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>ZFSguru</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Jason</given>
 	  <common>Edwards</common>
 	</name>
 	<email>sub.mesa@gmail.com</email>
       </person>
     </contact>
 
     <links>
       <url href="http://zfsguru.com">ZFSguru</url>
     </links>
 
     <body>
       <p>ZFSguru is a multifunctional server appliance with a strong
 	emphasis on storage.  ZFSguru began as simple web-interface
 	frontend to ZFS, but has since grown into a &os; derivative
 	with its own infrastructure.  The scope of the project has
 	also grown with the inclusion of add-on packages that add
 	functionality beyond the traditional NAS functionality found
 	in similar product like FreeNAS and NAS4Free.  ZFSguru aims to
 	be a true multifunctional server appliance that is extremely
 	easy to set up and can unite both novice and more experienced
 	users in a single user interface.  The modular nature of the
 	project combats the danger of bloat, whilst still allowing
 	extended functionality to be easily deployed.</p>
 
       <p>The ZFSguru project is nearing the release of version 0.3, a
 	major milestone for the project.  In this new version, major
 	work has been done on fundamentals.  An overview:</p>
 
       <ul>
 	<li>New build infrastructure allows for frequent releases of
 	  system images and services in a semi-automated way.</li>
 
 	<li>New GuruDB database allows for a growing number of system
 	  images and servers, and provides good caching to accelerate
 	  pages.</li>
 
 	<li>Redesigned installation procedure, and addition of new
 	  distributions Root-on-RAM and Root-on-Media aside from the
 	  already supported Root-on-ZFS.</li>
 
 	<li>Both LiveCD and USB images will be provided.  The USB
 	  image also has UEFI boot support working alongside the
 	  regular MBR boot support so both are available.</li>
 
 	<li>Many overhauled libraries and additions to the web
 	  interface.</li>
 
 	<li>Many improvements to services, such as the new Gnome 3
 	  graphical environment.</li>
       </ul>
 
       <p>ZFSguru version 0.3 will be released on the first of
 	August.</p>
     </body>
   </project>
 
   <project cat="arch">
     <title>&os;/arm64</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Andrew</given>
 	  <common>Turner</common>
 	</name>
 	<email>andrew@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Maste</common>
 	</name>
 	<email>emaste@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ruslan</given>
 	  <common>Bukin</common>
 	</name>
 	<email>br@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/arm64" >&os; arm64
 	wiki</url>
     </links>
 
     <body>
       <p>Since the last status report, support for building &os; for
 	AArch64 (arm64) has been committed to Subversion.  This has
 	initially been targeting qemu, with more hardware support
 	being added after review.</p>
 
       <p>Support for ACPI, SMP, DTrace, and <tt>hwpmc</tt> has been
 	added.  ACPI is able to enumerate devices and get to the
 	<tt>mountroot</tt> prompt.  Further work is needed to get into
 	userland.  SMP has been tested on qemu with two cores, and
 	work is under way to support SMP on hardware.  The
 	<tt>hwpmc</tt> driver includes support for the Cortex-A53,
 	Cortex-A57, and Cortex-A72 cores from ARM.</p>
 
       <p>Poudriere has been used with user-mode qemu to test building
 	packages.  Over 14,000 ports were successfully built.  A
 	number of issues have been found and fixed from this first
 	run.  These fixes should unblock about 5,000 additional
 	ports.</p>
     </body>
 
     <sponsor>The FreeBSD Foundation</sponsor>
 
     <sponsor>ABT Systems Ltd</sponsor>
 
     <sponsor>ARM Ltd</sponsor>
 
     <help>
       <task>
 	<p>Port to more SoCs</p>
       </task>
 
       <task>
 	<p>Test Poudriere on native hardware</p>
       </task>
     </help>
   </project>
 
   <project cat='misc'>
     <title>The FreeBSD Foundation</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Deb</given>
 	  <common>Goodkin</common>
 	</name>
 	<email>deb@FreeBSDFoundation.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.FreeBSDFoundation.org/">Foundation
 	website</url>
       <url href="http://freebsdjournal.com/">&os; Journal</url>
     </links>
 
     <body>
       <p>The FreeBSD Foundation is a 501(c)(3) non-profit organization
 	dedicated to supporting and promoting the &os; Project and
 	community worldwide.  Funding comes from individual and
 	corporate donations and is used to fund and manage development
 	projects, conferences and developer summits, and provide
 	travel grants to &os; developers.  The Foundation purchases
 	hardware to improve and maintain &os; infrastructure and
 	publishes &os; white papers and marketing material to promote,
 	educate, and advocate for the &os; Project.  The Foundation
 	also represents the &os; Project in executing contracts,
 	license agreements, and other legal arrangements that require
 	a recognized legal entity.</p>
 
       <p>Here are some highlights of what we did to help &os; during
 	the last quarter:</p>
 
       <ul>
 	<li>
 	  <p>We were a Platinum Sponsor for BSDCan 2015 and the
 	    sponsor for the Ottawa developer and vendor summits.  We
 	    were pleased to provide 12 travel grants for &os;
 	    contributors to attend the conference and have
 	    opportunities to meet face-to-face with other &os;
 	    contributors.  You can read some of their trip reports
 	    <a href="http://freebsdfoundation.blogspot.com/2015_06_01_archive.html">here</a>.</p>
 
 	  <p>In celebration of our 15th anniversary we provided a
 	    delicious &os; cake, which was happily devoured by
 	    conference attendees.</p>
 
 	  <p>Various Foundation team members gave talks, attended
 	    talks, participated in doc sprints, worked on efforts to
 	    improve &os;, worked at our booth, and spent time
 	    talking to our constituents about areas where we can help
 	    with &os;.</p>
 
 	  <p>Foundation members gave these talks:</p>
 
 	  <p><ul>
 	    <li> Anne Dickison: "&os; Advocacy: How you can spread
 	      the word"</li>
 
 	    <li>Kirk McKusick:
 	      <a href="http://www.bsdcan.org/2015/schedule/events/525.en.html">"An Introduction to the Implementation of ZFS"</a>
 	    </li>
 
 	    <li>George Neville-Neil:
 	      <a href="http://www.bsdcan.org/2015/schedule/events/528.en.html">"Measure Twice, Code Once"</a>
 	      and
 	      <a href="http://www.bsdcan.org/2015/schedule/events/566.en.html">"Cambridge L41: Teaching Advanced Operating Systems with &os;"</a>
 	    </li>
 
 	    <li>Ed Maste:
 	      <a href="http://www.bsdcan.org/2015/schedule/events/567.en.html">"The LLDB Debugger in &os;"</a>
 	      and Ed Maste also ran the Vendor Summit.
 	    </li>
 	  </ul></p>
 	</li>
 
 	<li>
 	  <p>We held our annual board meeting in Ottawa.  We are
 	    pleased to announce the addition of Benedict Reuschling to
 	    our board of directors.  Read his interview
 	    <a href="http://freebsdfoundation.blogspot.com/2015/07/freebsd-foundation-welcomes-new-board.html">here</a>.
 	    The current board of directors and officers were all
 	    re-elected.  You can find out who is on our board
 	    <a href="https://www.freebsdfoundation.org/board">here</a>.
 	    We spent the day planning our 12-month goals, project
 	    roadmapping, FreeBSD education offerings, fundraising, and
 	    advocacy efforts.</p>
 	</li>
 
 	<li>
 	  <p>Dru Lavigne promoted and gave a presentation on &os;
 	    at
 	    <a href="http://linuxfestnorthwest.org/2015">LinuxFest
 	      Northwest 2015</a>.</p>
 	</li>
 
 	<li>
 	  <p>We have committed to sponsoring several upcoming conferences:
 	    vBSDCon, womENcourage 2015, EuroBSDCon 2015, Grace Hopper
 	    conference, BSDCon Brasil, Cambridge Developer Summit, and
 	    OpenZFS. You'll also find us at OSCON, July 21-23, and the
 	    SNIA Storage Developer Conference, Sept 21-24.</p>
 	</li>
 
 	<li>
 	  <p>Fundraising</p>
 
 	  <p>So far, we have raised $361,000 for 2015 from over 500
 	    donors.  Juniper became a Gold level donor.  We are
 	    actively approaching commercial &os; users for Silver-plus
 	    donations, and asking large tech companies for separate
 	    women in tech funding, to help us recruit more women to
 	    the &os; Project.  We are also asking companies for
 	    funding to help with our &os; education efforts.</p>
 	</li>
 
 	<li>
 	  <p>We had the pleasure of hosting Groff the BSD Goat here in
 	    Colorado in April.</p>
 	</li>
 
 	<li>
 	  <p>Infrastructure Support</p>
 
 	  <p>The Foundation funded almost $50,000 of equipment to support &os;
 	    infrastructure.  Most of this went towards new and
 	    upgraded servers at the NYI facility.  We sent Glen Barber
 	    there to install the new servers.  You can read all about
 	    <a href="http://freebsdfoundation.blogspot.com/2015/05/another-data-center-site-visit-nyi.html">his
 	      trip</a>.</p>
 	</li>
 
 	<li>
 	  <p>Advocacy Work</p>
 
 	  <p>The &os; Journal has over 9200 subscribers, with a 98%
 	    renewal rate.  Our marketing director, Anne Dickison, was
 	    busy providing advocacy work for the Project.  She helped
 	    provide more &os; marketing literature and material.  This
 	    included the cool <i>I Choose &os;</i> sticker and very
 	    popular <i>I Love FreeBSD</i> temporary tattoos that are available
 	    at conferences.  We published April, May, and June
 	    Foundation Newsletters to highlight the work being done by
 	    the Foundation to support &os;.  These newsletters also
 	    include company &os; testimonials, upcoming events where
 	    &os; will be promoted, and the new From the Trenches
 	    articles from &os; contributor experiences working with
 	    &os;.</p>
 	</li>
 
 	<li>
 	  <p>One of the Foundation's responsibilities is to protect
 	    &os; intellectual property (IP).  This includes protecting
 	    the &os; trademarks.  We granted trademark usage
 	    permission to various companies who want to show their
 	    support for &os;.  To get permission to use the
 	    trademarks, interested parties must agree to our
 	    <a href="https://www.freebsdfoundation.org/documents/guidelines">Trademark
 	      Usage Terms and Conditions</a>.</p>
 	</li>
 
 	<li>
 	  <p>Project Development Work</p>
 
 	  <p>George Neville-Neil signed up new universities to look at
 	    the &os; course including George Washington University,
 	    Johns Hopkins, and UC Santa Cruz.  He is working with
 	    Verisign on the DevSummit that will be held at vBSDCon.
 	    He also worked with ARM to set up meeting with 18 hardware
 	    and silicon vendors at the ARM Partner Meeting in
 	    August.</p>
 
 	  <p>Ed Maste continued managing the &os;/arm64 porting
 	    project.  He also continued with updates to the ELF
 	    Toolchain tools in the &os; base system and incorporated a
 	    set of fixes from the upstream project to fix issues with
 	    the <tt>strip</tt> tool.  Ed investigated and fixed a set
 	    of outstanding issues with the new <tt>vt(4)</tt> console
 	    in the &os; installer.</p>
 
 	  <p>Staff member Edward Napiera&lstrok;a committed a number of bug
 	    fix merges to the stable/10 branch for inclusion in &os;
 	    10.2, and continued investigation of a project to support
 	    runtime switching of the root file system.  He merged a
 	    large number of improvements to the <tt>autofs</tt>
 	    <tt>automount</tt> daemon.  He also supported &os;
 	    developer Dmitry Chagin's work on 64-bit Linux binary
 	    emulation support by reviewing the extensive patch set.
 	    Those changes are now committed to FreeBSD's Subversion
 	    tree, and will arrive in &os; 11.0.</p>
 
 	  <p>Staff member Konstantin Belousov continued development on
 	    the Intel DMA remap (DMAR) and Process Context Identifier
 	    (PCID) infrastructure projects.  Kostik also contributed
 	    an extensive set of changes to multiple aspects of &os;:
 	    stability improvements in the virtual memory subsystem,
 	    improved compatibility in options handling in the runtime
 	    loader, thread library improvements, and GDB debugger
 	    enhancements.</p>
 
 	  <p>Glen Barber, who is a Foundation employee, is also a
 	    release engineer for the Project.  Here are some
 	    highlights of what he did to help the Project:</p>
 
 	  <ul>
 	    <li>Added support to the release build code in 11-CURRENT
 	      for producing &os;/aarch64 (arm64) memory stick images
 	      and virtual machine disk images for use within
 	      Qemu.</li>
 
 	    <li>Worked with Colin Percival and Brad Davis on testing
 	      and refining the release build code to support building
 	      Amazon EC2 images, and Vagrant images for Hashicorp
 	      Atlas, respectively.</li>
 
 	    <li>Reworked the &os;/arm build code to provide a
 	      fully-native build infrastructure for the existing
 	      images (BEAGLEBONE, RPI-B, PANDABOARD, WANDBOARD), and
 	      add support for additional images (GUMSTIX,
 	      CUBOX/HUMMINGBOARD).</li>
 
 	    <li>Wrote several additional utilities to reduce human
 	      error in several areas of Release Engineering, including
 	      producing the filesystem hierarchy used by the FTP
 	      mirrors, enhancements to the internal build scripts used
 	      by Release Engineering, and support for automatically
 	      uploading and publishing virtual machine images.</li>
 
 	    <li>While attending BSDCan 2015, Glen worked with several
 	      developers and teams on various items, such as
 	      discussing packaging the base system with
 	      <tt>pkg(8)</tt>, migrating internal &os; servers to the
 	      new machines the Foundation purchased for the NYI
 	      facility, and discussing further possible future
 	      enhancements to the &os; build infrastructure.</li>
 
 	    <li>Started the 10.2-RELEASE cycle.</li>
 
 	  </ul>
 	</li>
       </ul>
     </body>
   </project>
 
   <project cat='ports'>
     <title>Wine/&os;</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Gerald</given>
 	  <common>Pfeifer</common>
 	</name>
 	<email>gerald@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>David</given>
 	  <common>Naylor</common>
 	</name>
 	<email>dbn@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://wiki.FreeBSD.org/Wine">Wine wiki</url>
       <url href="http://wiki.FreeBSD.org/i386-Wine">Wine on amd64
 	wiki</url>
       <url href="http://www.winehq.org">Wine homepage</url>
     </links>
 
     <body>
       <p>This quarter has seen seven updates to the
 	<tt>wine-devel</tt> port that closely tracks upstream
 	development as well as updates to its helper ports
 	(<tt>wine-gecko-devel</tt> and <tt>wine-mono-devel</tt>):</p>
 
       <ul>
 	<li>Stable releases: 1.6.2 (1 port revision)</li>
 
 	<li>Development releases: 1.7.40 through 1.7.46</li>
       </ul>
 
       <p>The <tt>i386-wine-devel</tt> port has packages built for
 	amd64 for &os; 8.4, 9.1+, 10.1+ and CURRENT.</p>
 
       <p>Accomplishments include:</p>
 
       <ul>
 	<li>Rename <tt>wine-compholio</tt> to
 	  <tt>wine-staging</tt> (to match upstream developments).</li>
       </ul>
 
       <p>Future development on Wine will focus on:</p>
       <ul>
 	<li>Add the <tt>getdirentries(2)</tt> patch to the
 	  <tt>wine-devel</tt> port.</li>
 
 	<li>Redevelop and upstream the <tt>getdirentries(2)</tt>
 	  patch.</li>
 
 	<li>Redevelop and upstream the kernel32 <tt>Makefile</tt>
 	  patch.</li>
 
 	<li>Add support to the <tt>i386-wine</tt> port for
 	  <tt>pkg</tt> 1.5 (library conflicts currently prevent
 	  support).</li>
 
 	<li>Add support for Windows 32-bit on Windows 64-bit (WoW64):
 	  <ul>
 	    <li>Reduce the <tt>i386-wine</tt> port to just the
 	      components required for WoW64.</li>
 
 	    <li>Rename the <tt>i386-wine</tt> port to
 	      <tt>wow64</tt>.</li>
 
 	    <li>Make the wine ports depend on the wow64 ports when
 	      built on amd64.</li>
 
 	    <li>Investigate and verify the interactions between Wine64
 	      and WoW64.</li>
 
 	    <li>Investigate possible update approaches for the
 	      wow64 ports (that have to be pre-compiled) and how
 	      updating with the wine ports will work.</li>
 	  </ul>
 	</li>
       </ul>
 
       <p> Maintaining and improving Wine is a major undertaking
 	that directly impacts end-users on &os; (including many
 	gamers).  If you are interested in helping please contact us.
 	We will happily accept patches, suggest areas of focus or have
 	a chat.</p>
     </body>
 
     <help>
       <task>
 	<p>Open Tasks and Known Problems (see the
 	  <a href="http://wiki.FreeBSD.org/Wine">Wine wiki</a>)</p>
       </task>
 
       <task>
 	<p>&os;/amd64 integration (see the
 	  <a href="http://wiki.FreeBSD.org/i386-Wine">i386-Wine
 	    wiki</a>)</p>
       </task>
 
       <task>
 	<p>Porting Windows 32-bit on Windows 64-bit (WoW64)</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title>KDE on &os;</title>
 
     <contact>
       <person>
 	<name>KDE on &os; team</name>
 	<email>kde@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://freebsd.kde.org/">KDE on &os; website</url>
       <url href="https://freebsd.kde.org/area51.php">KDE ports staging
 	area</url>
       <url href="https://wiki.freebsd.org/KDE">KDE on &os; wiki</url>
       <url href="https://mail.kde.org/mailman/listinfo/kde-freebsd">KDE/&os;
 	mailing list</url>
       <url href="https://github.com/tcberner/kde5">Development
 	repository for integrating KDE 5</url>
     </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>Brad Davis has been working on CMake, resulting in an update
 	to version 3.2.3 being committed to ports.</p>
 
       <p>Overall, we have updated the following ports in this
 	quarter:</p>
 
       <ul>
 	<li>CMake 3.2.3 (committed to ports)</li>
 	<li>Qt 4.8.7 (committed to area51)</li>
 	<li>Qt 5.4.1 (refinements committed to ports)</li>
       </ul>
     </body>
 
     <help>
       <task>
 	<p>Put more effort into the Qt5-related ports: KDE Frameworks
 	  5 (currently worked on by Tobias Berner) and PyQt 5.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>Warner's ARMv6 Hard Float Experiment</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Warner</given>
 	  <common>Losh</common>
 	</name>
 	<email>imp@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/armv6tohardfloat">Moving
 	armv6 from Soft Float to Hard Float</url>
     </links>
 
     <body>
       <p>The plan for the transition to hard float on ARMv6 involved
 	having a new <tt>MACHINE_ARCH</tt>.  That seemed expedient,
 	but inelegant to me.  The kernel can easily run both soft and
 	hard floating point binaries, assuming that the proper
 	libraries are available.</p>
 
       <p>As an experiment, I have been investigating how hard it would
 	be to just start generating hard float binaries starting with
 	&os; 11.0 and what issues this causes.  I am most interested
 	in the source, the effects on ports, and any binary/package
 	upgrade issues from &os; 10.X to 11.</p>
 
       <p>If successful, this will allow the project to move more
 	quickly away from a soft-floating point default.  Users
 	upgrading from &os; 10 will automatically be upgraded to hard
 	float.  All supported ARMv6 and ARMv7 processors have hardware
 	floating point, so this will not be a problem for the vast
 	majority of users.  In addition, many of the build scripts
 	know about all values of <tt>MACHINE_ARCH</tt>, and not
 	changing the <tt>MACHINE_ARCH</tt> will allow those scripts to
 	continue to function without additional changes.</p>
 
       <p>I am about three fourths of the way through investigating
 	this possibility and coding up solutions to the problems
 	encountered so far.</p>
 
       <p>The risks from this experiment are that it will encounter
 	unforseen dependencies.  This could force us to go with the
 	original plan for migration to hard floating point.</p>
 
       <p>The hope for this experiment is to pave the way for using the
 	superior hard floating point in &os; 11 with minimal impact to
 	our users and their current build scripts and processes.
 	Backwards compatibility will be ensured with the libsoft tasks
 	if users need to run &os; 10.X ARMv6 softfloat binaries on
 	&os; 11.0 with its new hardfloat libraries.  Packages should
 	automatically update once the new hardfloat packages are put
 	into place.</p>
     </body>
 
     <help>
       <task>
 	<p>Building seat belts into <tt>ld.so</tt> to not cross-thread
 	  libraries of differing floating point implementations.</p>
       </task>
 
       <task>
 	<p>Clang should properly mark hard versus soft floating point
 	  <tt>.o</tt>s.  This is a minor issue, since <tt>ld</tt>
 	  handles things correctly.</p>
       </task>
 
       <task>
 	<p><tt>libsoft</tt>, the analog of <tt>lib32</tt>, needs to be
 	  completed.</p>
       </task>
 
       <task>
 	<p>Patches to flip the switch from soft to hard for builds for
 	  <tt>armv6</tt>.  Some additional code needed to build soft
 	  float may be needed for the prior task.</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title>Official Packages</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Bryan</given>
 	  <common>Drewery</common>
 	</name>
 	<email>bdrewery@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>Ports Management Team</name>
 	<email>portmgr@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Sean</given>
 	  <common>Bruno</common>
 	</name>
 	<email>sbruno@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://pkg-status.FreeBSD.org">Package Status</url>
     </links>
 
     <body>
       <p>x86 Packages</p>
 
       <p>With the help of the FreeBSD Foundation providing more
 	build servers, we have increased the build frequency of
 	packages from weekly to about every other day.  Packages are
 	provided for all currently supported releases and head on
 	<tt>i386</tt> and <tt>amd64</tt> from the ports head branch,
 	and quarterly packages for &os; 10.1 and 9.3 release
 	branches.</p>
 
       <p>We are using eight different systems for building packages.
 	The build process has been fully automated and is
 	more fault tolerant now.  More details on this will be
 	available in an upcoming &os; Journal article.  About eleven
 	servers are used for daily test builds.  To make it simpler for
 	everyone to find the status and results of these builds,
 	<a href="http://pkg-status.FreeBSD.org">pkg-status.FreeBSD.org</a>
 	has been developed by Bryan Drewery.  Its intent is to show
 	all systems and builds in nearly real-time.  It is currently
 	in a beta stage and will be improved over time.  At the time
 	of this writing, it is temporarily down, but will be restored
 	soon.</p>
 
       <p>ARM/MIPS Packages</p>
 
       <p>The FreeBSD Foundation purchased servers for the project to
 	begin building and providing ARM and MIPS packages.  These
 	packages are currently built from x86 systems using QEMU.
 	More details on this can be found in the
 	<a href="http://www.bsdcan.org/2015/schedule/events/532.en.html">BSDCan
 	  2015 Presentation</a>.  The work to do this has been
 	shepherded by Sean Bruno and has had help from many people
 	including but not limited to Juergen Lock, Stacey Son, Ed
 	Maste, Peter Wemm, Alexander Kabaev, Adrian Chadd, Baptiste
 	Daroussin, Bryan Drewery, Dimitry Andric, Andrew Turner,
 	Warner Losh, Ian Lapore, and Brooks Davis.</p>
 
       <p>We are currently targeting packages for head on
 	<tt>mips</tt>, <tt>mips64</tt> and <tt>armv6</tt>.  Each set
 	takes one to two weeks to build on QEMU.  They will be
 	provided on a best effort basis for now on the default
 	repository of <tt>pkg.FreeBSD.org</tt>.</p>
     </body>
 
     <sponsor>
       FreeBSD Foundation (package building hardware)
     </sponsor>
 
     <help>
       <task>
 	<p>Portmgr met at BSDCan and decided that the default package
 	  set should be provided based on the Ports Quarterly branch.
 	  This will provide more stable packages by default and allow
 	  users who wish to have the bleeding edge to use the head
 	  packages.  The Quarterly branch is currently updated in full
 	  every three months from head and otherwise receives security
 	  and critical fixes.  Moving towards this plan will also
 	  require a change to how we update the Quarterly branch.
 	  More details will be provided later.</p>
       </task>
 
       <task>
 	<p>Performance and stability of QEMU continues to improve.
 	  Native cross-building support in ports needs more work and
 	  testing to be viable.</p>
       </task>
 
       <task>
 	<p>The package builds currently run from a <tt>crontab</tt>
 	  every other day.  Some of the builds take two hours
 	  (incremental), while others can take up to 30 hours for a
 	  full build.  An open task here is to implement a better
 	  OS ABI check to see if incremental builds can be done, or if
 	  a full rebuild is needed when an SA/EN comes out.  The plan
 	  for this is detailed at
 	  <a href="https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017025.html">https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017025.html</a>.</p>
 
 	<p>Another open task is to implement a master queue
 	  coordinator to start the next builds as soon as all others
 	  are done.  This will also allow improving the pkg-status
 	  site's view of everything.</p>
       </task>
     </help>
   </project>
 
   <project cat='gsoc'>
     <title>GSoC 2015: <tt>libc</tt> Security Extensions</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Pedro</given>
 	  <common>Giffuni</common>
 	</name>
 	<email>pfg@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Oliver</given>
 	  <common>Pinter</common>
 	</name>
 	<email>op@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/SummerOfCode2015/FreeBSDLibcSecurityExtensions">Project
 	Wiki Page</url>
       <url href="https://reviews.freebsd.org/D3043">Code Review
 	Differential</url>
     </links>
 
     <body>
       <p>As part of this year's Google Summer of Code, we have been
 	adding support for the <tt>_FORTIFY_SOURCE</tt> extension to
 	<tt>libc</tt>.  This extension uses the GCC
 	<tt>builtin_object_size</tt> information to prevent buffer overflows in
 	existing code.  The compiler and the C library can effectively
 	detect a set of common programming mistakes.</p>
 
       <p>A mixed version of the NetBSD and
 	Android implementations has been ported and is currently
 	undergoing heavy testing.  On &os;, this code has already
 	found two small bugs.  On the other hand, the &os; codebase
 	is extremely useful to test the framework.</p>
     </body>
 
     <sponsor>
       Google Summer of Code Program
     </sponsor>
 
     <help>
       <task>
 	<p>Code review and more buildworld testing with GCC.</p>
       </task>
 
       <task>
 	<p>Integration tests, especially on non-x86 platforms.</p>
       </task>
 
       <task>
 	<p>Documentation: the framework is relatively popular on GNU
 	  <tt>libc</tt> but we still have to work on better documentation.</p>
       </task>
 
       <task>
 	<p>Testing and possibly integrating with ports.</p>
       </task>
 
       <task>
 	<p>We will have to re-schedule the GSoC project, as we were
 	  expecting to spend less time on this.</p>
       </task>
     </help>
   </project>
 
   <project cat="ports">
     <title>The Graphics Stack on &os;</title>
 
     <contact>
       <person>
 	<name>
 	  <common>FreeBSD Graphics Team</common>
 	</name>
 	<email>freebsd-x11@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/Graphics">Graphics stack
 	roadmap and supported hardware matrix</url>
       <url href="http://blogs.freebsdish.org/graphics/">Graphics stack
 	team blog</url>
       <url href="https://github.com/freebsd/freebsd-ports-graphics">Ports
 	development tree on GitHub</url>
     </links>
 
     <body>
       <p>The members of the graphics team were lacking spare
 	time during this quarter, and only few things could be
 	improved.</p>
 
       <p>Our ports development tree still holds an update to Mesa 10.6
 	along with many cleanups and bug fixes.  (It was 10.5 in the
 	previous quarterly report.)  Initially, we planned to commit
 	it in early July, just after the &os; 8.4-RELEASE end-of-life date, but the EOL
 	was delayed to the 31st of July.  Therefore, we will send a
 	Call For Testers near the end of July, with the update to be
 	committed in early August.  Of course, the update can still be
 	obtained and tested directly from the Ports development tree
 	by using the <tt>mesa-next</tt> branch.</p>
 
       <p>Several smaller updates to X.Org-related ports were committed
 	to the Ports tree.</p>
 
       <p>The work on the i915 kernel driver update made no progress
 	during this quarter due to the lack of free time.
 	Fortunately, it can resume in Q3 with the hope to have
 	something ready to test in September 2015.</p>
 
       <p>The update to the DRM device-independent code was merged to
 	<tt>stable/10</tt>.  This means it will be available in the
 	upcoming &os;&nbsp;10.2-RELEASE.</p>
 
       <p>Recently, the website hosting our blog has been down
 	frequently.  It is again the case at the time of this
 	writing.  We exported the data the last time it was up,
 	so we will probably move to another system.  Of course, the
 	URL will change as well.</p>
     </body>
 
     <help>
       <task>
 	<p>See the Graphics wiki page for up-to-date information.</p>
       </task>
     </help>
   </project>
 </report>