Section Navigation

Introduction

This report covers FreeBSD-related projects between October and
December 2013. This is the last of four reports planned for
2013.

The last quarter of 2013 was very active for the FreeBSD
community, much like the preceding quarters. Many advances were
made in getting FreeBSD to run on ARM-based System-on-Chip boards
like Cubieboard, Rockchip, Snapdragon, S4, Freescale i.MX6, and
Vybrid VF6xx. FreeBSD is also becoming a better platform for Xen
and the Amazon Elastic Compute Cloud. There are plans for FreeBSD
to become a fully supported compute host for OpenStack. The I/O
stack has again received some performance boosts on
multi-processor systems through work touching the CAM and GEOM
subsystems, and through better adaptation of UMA caches to
system memory constraints for ZFS. The FreeBSD Foundation did an
excellent job in this quarter, and many of their sponsored
projects like VT-d and UEFI support, iSCSI stack, Capsicum, and
auditdistd are about to complete. At the same time, new projects
like Automounter and Intel GPU updates have just been launched.
The Newcons project has been merged into -CURRENT, which will
make it possible to finally move to the latest version of X.Org
in the Ports Collection. Efforts are also under way to improve
testing with Jenkins and Kyua. It is an exciting time for users
and developers of FreeBSD!

Thanks to all the reporters for the excellent work! This report
contains 37 entries and we hope you enjoy reading it.

The deadline for submissions covering between January and
March 2014 is April 7th, 2014.

Miscellaneous

The FreeBSD 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 the last quarter of 2013, they continued
general maintenance of the FreeBSD cluster across all sites.

In addition to general upkeep tasks, additional
cluster-related items were addressed. Some of these
items include:

Added several machines for the Kyua testing framework.

Replaced failed hardware hosting various web services.

Coordinated with the FreeBSD Security Officer and Ports
Management Teams to implement signed binary packages.

Added the redports.org machines to the list of
machines managed by the Cluster Administration Team.

Began discussion with contacts at Yandex regarding the
addition of a mirror site for binary packages and Subversion
repositories.

The FreeBSD 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
FreeBSD project landscape.

In the fourth quarter of 2013, the Core Team finally reached
its previous goal of launching the official repositories for
pkg(8)-based binary packages. The Core Team also
unified the commit bit expiration policies for all Project
repositories, allowing committers to idle for 18 months before
their commit bits are automatically taken into safekeeping.
This was then followed by an extension to suspension of cluster
accounts for the committers who lost all of their commit bits.
This helps to improve the security of the Project server cluster
by temporarily disabling inactive accounts. In addition to the
above efforts, Thomas Abthorpe resurrected the Grim
Reaper service which helps to enforce the aforementioned
policy.

With the work of John Baldwin, Hiroki Sato, and others, many
licenses in the base system source code have been revisited and
cleaned up. Furthermore, the Core Team is hoping that the
situation can be improved by introducing periodic automated
checks of the license agreements, and by providing developers
guidelines on questions of licensing. John Baldwin and David
Chisnall have been guiding the work of the FreeBSD Graphics Team on
moving to the newer version of X.Org and related software in the
Ports Collection, in coordination with the switch to Newcons on
FreeBSD 10.x.

It was a busy quarter for the src repository as well. The Core
Team was happy to welcome Jordan K. Hubbard (jkh) back,
who has recently returned to the FreeBSD business, and joined
iXsystems as project manager and release engineer of FreeNAS.
In addition to this, there were three commit bits offered for new
developers, two committers were upgraded, one commit bit was taken
for safekeeping, and one src bit was reactivated.

The FreeBSD Ports collection is a package management system for
the FreeBSD operating system, providing an easy and consistent way of
installing software packages. The FreeBSD Ports Collection now
contains approximately 24,500 ports, while the PR count exceeds
1,900.

The FreeBSD Port Management Team ensures that the FreeBSD ports
developer community provides a Ports Collection that is
functional, stable, up-to-date, and full-featured. Its secondary
responsibility is to coordinate among the committers and
developers who work on it. As part of these efforts, we added three
new committers, took in three commit bits for safe keeping, and
reinstated one commit bit in the fourth quarter of 2013.

Ongoing effort went into testing larger changes, as many as eight a
week, including sweeping changes to the tree, moderization of
the infrastructure, and basic quality assurance (QA) runs. Many
iterations of tests against 10.0-RELEASE were run to
ensure that the maximum number of packages would be available
for the release.

We now have pkg(8) packages for the releases 8.3, 8.4,
9.1, 9.2, 10.0 and -CURRENT on pkg.FreeBSD.org. During
this same time, further enhancements were put into
pkg(8), including secure package signing.

Commencing November 1, the Port Management Team undertook a
portmgr-lurkers pilot project in which ports committers
could volunteer to assist the Port Management Team for a
four-month duration. The first two candiates are Mathieu Arnold
(mat) and Antoine Brodin (antoine).

The FreeBSD Release Engineering Team is finishing the
10.0-RELEASE cycle. The release cycle changed with two
last-minute release candidate builds, each addressing
fixes critical to include in the final release.

The FreeBSD 10.0-RELEASE cycle is expected to be completed by
mid-January, approximately eight weeks behind the original
schedule.

CBSD is another FreeBSD jail management solution, aimed at
combining various features, such as racct(8),
vnet, zfs(8), carp(4), and
hastd(8), into a single tool. This provides a more
comprehensive way to build application servers using
pre-installed jails with a typical set of software, and requires
minimal effort to configure.

At the November 2013 FreeBSD Vendor Summit, some work was
presented that Craig Rodrigues has been doing with Continuous
Integration and Testing at iXsystems. Craig's presentation
described how iXsystems is using modern best practices for
building and testing the FreeNAS code. Jenkins is a framework
for doing continuous builds and integration that is used by
hundreds of companies. BHyve (BSD Hypvervisor) is the new
virtual machine system which will be part of FreeBSDÂ 10.
Webdriver is a Python toolkit for testing web applications. By
combining these technologies, iXsystems is developing a modern
and sophisticated workflow for testing and improving the quality
of FreeNAS.

Ed Maste from The FreeBSD Foundation was interested in this work,
and based on this interest, it is now being ported to FreeBSD.
Currently, a machine in the FreeBSD cluster has been allocated for
this purpose, where a bhyve(4)-based virtual machine
was set up and Jenkins was installed. The remainder is still in
progress.

The CAM and GEOM multi-processor scalability improvement
project has completed. The corresponding code has been committed
to FreeBSD head and recently merged to the
stable/10 branch; it shall appear in
10.1-RELEASE.

As part of this project, cam(4) (the ATA/SCSI subsystem)
has received more fine-grained locking for better utilization of
multi-core systems. In addition, the locking in geom(4)
(the block storage subsystem) has also been polished, and a new
direct dispatch functionality was implemented to spread the load
between multiple threads and processors, and reduce the number
of context switches.

Thanks to these cam(4) and geom(4) changes,
the peak I/O rate has doubled on contemporary hardware, reaching
up to 1,000,000Â IOPS!

This project is sponsored by iXsystems, Inc.

Open tasks:

Some CAM controller drivers (SIMs) could also be optimized
to get more benefits from this project, utilizing the new locking
models and direct command completions from multiple interrupt
threads.

This project will update the Intel graphics chipset driver,
i915kms, to a recent snapshot of the Linux upstream
code. The update will provide at least 1.5 years of bugfixes
from the Intel team, and introduce support for the newest
hardware — in particular Haswell and ValleyView. The
IvyBridge code will also be updated. The addition of several
features which are required to update X.Org and Mesa
is also planned.

iSCSI is a popular block storage protocol. Under this project,
a new, fast, and reliable kernel-based iSCSI initiator (client)
and target (server) have been implemented.

During October to December, the work focused on performance and
scalability. The target and the initiator now spread the load
over multiple kernel threads, and the locking is optimized to
reduce contention. This makes better use of multiple processor
cores.

Work to finish iSER support is ongoing. All those
optimizations will be gradually merged to head in
February, and are expected to merged back to stable/10
and finally arrive in 10.1-RELEASE.

Research and prototyping has begun on a new project to
implement autofs(4) — an automounter filesystem
— and its userland counterpart, automountd(8).
The idea is to provide a very similar user experience to the
automounters available on Linux, MacOS X, and Solaris, including
using the same map format. The automounter will also integrate
with directory services, such as LDAP.

The Unified Extensible Firmware Interface (UEFI) provides boot-
and run-time services for x86 computers, and is a replacement for
the legacy BIOS. This project will adapt the FreeBSD loader and
kernel boot process for compatibility with UEFI firmware, found
on contemporary servers, desktops, and laptops.

In 2013, The FreeBSD Foundation sponsored Benno Rice for a short
project to improve the UEFI bootloader. This resulted in a
working proof-of-concept in the UEFI project branch, but it was
not ready to be merged to FreeBSD head.

Ed Maste has taken that original work and, with review feedback
from Konstantin Belousov, been preparing it for integration into
FreeBSD head. Some changes have been merged to
head already. The rest will be merged as they are
refined.

Intel provided a motherboard and CPU for the project, which
proved invaluable for addressing bugs that did not appear while
testing with the QEMU emulator.

The performance of ZFS and NFS was suboptimal in FreeBSD, so we
have recently investigated some possible improvement paths. The
uma(9) memory allocator caching code was improved to
adapt better to system memory constraints. Combined with other
virtual memory subsystem improvements done in the previous
years, it should be safe to actively use uma(9) caches
now. Their use in ZFS for ZIO/ARC may be enabled via the
vfs.zfs.zio.use_umaloader(8) tunable, which
is now the default for amd64, where it is recommended. Use of
uma(9) caches for LZ4 compression buffers is
unconditionally enabled on all architectures as it is has no
serious drawbacks. On systems with many CPUs, these changes
doubled the performance in the benchmarks.

Several areas of the NFS server stack (RPC, FHA, DRC) got a
number of fixes and performance optimizations that significantly
improve performance and reduce the CPU usage in a number of
tests. Together with the ZFS memory allocator changes mentioned
above, it was possible to reach 200K NFS block read IOPS and 55K
SPEC NFS IOPS.

The code was committed to head. The uma(9)
ZFS commits have been already merged to stable/10, and
the remainder will be done soon as well.

This project is sponsored by iXsystems, Inc.

Open tasks:

The SPEC NFS test hits lock congestion on several global
locks in the file system layer when a quite intensive
READDIRPLUS NFS request is received. Fixing this
problem could improve performance on large systems even
further.

Colloquially known as Newcons, vt(9) is a modern
replacement for the existing, quite old, virtual terminal
emulator called syscons(4). Initially motivated by the
lack of Unicode support in syscons(4), the project was
later expanded to cover the new requirement of supporting Kernel
Mode Switching (KMS).

The project is now approaching completion and is ready for
wider testing, as the related code was already merged to FreeBSD
head. Hence, vt(9) can be tested easily by
replacing the following two lines in the kernel config file:

device sc
device vga

with the following ones:

device vt
device vt_vga

Major highlights:

Unicode support.

Double-width character support for CJK characters.

xterm(1)-like terminal emulation.

Support for Kernel Mode Setting (KMS) drivers
(i915kms, radeonkms).

Support for different fonts per terminal window.

Simplified drivers.

Brief status of supported architectures and hardware:

amd64 (VGA/i915kms/radeonkms) — works.

ARM framebuffer — works.

i386 (VGA/i915kms/radeonkms) — works.

IA64 — untested.

MIPS — untested.

PPC and PPC64 — works, but without X.Org yet.

SPARC — works on certain hardware (e.g., Ultra 5).

vesa(4) — in progress.

i386/amd64 nVidia driver — need testing.

Xbox framebuffer driver — need testing.

Known Issues:

Switching to vty0 from X.Org on Fatal events will not work.

Certain hardware (e.g., Lenovo X220) get a black screen when
i915kms is preloaded.

Scrolling can be slow;

Screen borders are not cleared when changing fonts.

vt(9) locks up with the gallant12x22 font in VirtualBox.

This project is sponsored by The FreeBSD Foundation.

Open tasks:

Create sub-directories for vt(9) under
/usr/share/ to store key maps and fonts.

OpenStack is a cloud operating system that controls large pools
of compute, storage, and networking resources in a data center.
OpenContrail is a network virtualization (SDN) solution
comprising a network controller, a virtual router, and an
analytics engine, which can be integrated with cloud
orchestration systems like OpenStack or CloudStack.

The goal of this work is to enable FreeBSD as a fully supported
compute host for OpenStack, using OpenContrail virtualized
networking. The main areas of development are the
following:

The current state of development features a working demo of
OpenStack with compute node components running on a FreeBSD host:

The native bhyve(4) hypervisor is driven by a
nova-compute component for spawning guest instances
and a nova-network component for providing simple
networking between those guests.

The nova-network approach (based on local host
bridging) is becoming an obsolete technology in OpenStack and
was used here only for demonstration and proof-of-concept
purposes, without exploring all the possible features.

The main objective is to move to OpenContrail-based
networking, therefore becoming compliant with the modern
OpenStack networking API ("neutron").

This project is sponsored by Juniper Networks, Inc.

Open tasks:

Decide how to integrate bhyve(4) with
nova-compute, either natively or via the
libvirt management layer.

Cubieboard is a single-board computer based on the AllWinner
A10 SoC, popular on cheap tablets, phones and media PCs. The
second version enhances the board mainly by replacing the
AllWinner A10 SoC with an AllWinner A20 which contains 2 ARM
Cortex-A7 MPCore CPUs and 2 Mali-400 GPUs (Mali-400MP2). In the
last few months, work has continued on their FreeBSD port, and
some work was done on the EMAC 10/100 Ethernet driver (see
link). The driver is now in a good shape, however the RX side
is very slow and there is need to have an external DMA driver that
can be used in this case.

The i.MX range is a family of Freescale Semiconductor
proprietary microprocessors for multimedia applications based on
the ARM architecture and focused on low power consumption. The
i.MX6x series is based on the ARM Cortex A9 solo, dual, or quad
cores. Initial support for them has been committed to
head, and merged to stable/10. All members of
the i.MX6 family (Solo, Dual, and Quad core) are supported, but
SMP support on the multi-core SoCs has not yet been enabled.

Initial driver support includes:

USB (EHCI)

Ethernet (Gigabit)

SD Card

UART

The initial hardware bringup was done on Wandboard hardware,
see the announcement on freebsd-arm in the links section
for more information.

Basic support for the Freescale Vybrid Family VF6xx
heterogeneous ARM Cortex-A5/M4 System-on-Chip (SoC) was added to
FreeBSD head. The Vybrid VF6xx family is an
implementation of the new modern Cortex-A5-based low-power ARM
SoC boards. Vybrid devices are ideal for applications including
simple HMI in appliances and industrial machines, secure control
of infrastructure and manufacturing equipment, energy conversion
applications such as motor drives and power inverters,
ruggedized wired and wireless connectivity, and control of
mobile battery-operated systems such as robots and industrial
vehicles.

Supported device drivers:

NAND Flash Controller (NFC)

USB Enhanced Host Controller Interface (EHCI)

General-Purpose Input/Output (GPIO)

Universal Asynchronous Receiver/Transmitter (UART)

Also supported:

Generic Interrupt Controller (GIC)

MPCore timer

ffec Ethernet driver

Open tasks:

Add support for a number of different VF5xx- and VF6xx-based
development boards.

Expand device driver support, including framebuffer and
other devices.

Rockchip is a series of SoC (System on Chip) integrated
circuits that are mainly for embedded systems applications in
mobile entertainment devices such as smartphones, tablets, e-books,
set-top boxes, media players, personal video, and MP3 players.
Due to their evolution from the MP3/MP4 player market, most
Rockchip ICs feature advanced media decoding logic but lack
integrated cellular radio basebands. Initial support for the
Rockchip RK3188 (Quad core Cortex A9) SoC is committed to
head. Now FreeBSD runs on Radxa Rock and it supports
the following peripherals:

Existing DWC OTG driver in host mode

GPIO

Some work was also done on initial support for the Qualcomm
Snapdragon S4 SoC, featuring the Krait CPU, which is considered
a "platform" for use in smartphones, tablets, and smartbook
devices. Krait has many similarities with the ARM Cortex-A15
CPU and is also based on the ARMv7 instruction set. A minimal
console driver was written, and FreeBSD's early boot messages can
be now seen on the serial console. The timer driver works too,
and the boot now stops at the mountroot prompt.

An Amazon Machine Image (AMI) is a special type of virtual
appliance that is used to create a virtual machine within the
Amazon Elastic Compute Cloud ("EC2"). It serves as the basic
unit of deployment for services delivered using EC2. Such AMIs
are available for 8.3-RELEASE and later FreeBSD releases,
and every ALPHA, BETA, and RC of FreeBSDÂ 10.0. Starting from
FreeBSDÂ 10.0-BETA1, FreeBSD/EC2 images are running
"fully supported" FreeBSD binaries, and starting from
FreeBSDÂ 10.0-RC1, FreeBSD/EC2 images include a
"configinit" system for autoconfiguration using EC2
user-data.

Due to limitations of old (m1, m2,
c1, t1) instance types,
"Windows"-labelled images are required for those
instance types; however all of the recent instances types
— m3 (general purpose), c3 (high-CPU),
and i2 (high-I/O) — support FreeBSD at the
"unix" pricing rates.

The maintainer of this platform considers it to be ready for
production use.

Open tasks:

Hand over the task of building FreeBSD AMIs to the Release
Engineering Team.

Get Amazon to add "FreeBSD" to the list of platforms
supported by EC2, so that it can stop showing up as "Other
Linux".

Xen is a native (bare-metal) hypervisor providing services that
allow multiple computer operating systems to execute on the same
computer hardware concurrently. XenÂ 4.4 will bring a
virtualization mode called PVH — PV (paravirtualization)
in an HVM (fully-virtual) container. This is essentially a
paravirtualized guest using paravirtualized drivers for boot and
I/O. Otherwise it uses hardware virtualization extensions,
without the need for emulation.

After merging the changes to improve Xen PVHVM
support, work has shifted on getting PVH DomU support on FreeBSD.
Patches have been posted, and after a couple of rounds of review,
the series looks almost ready for merging into head.
Also, very initial patches for FreeBSD PVH Dom0 support has been
posted. So far the posted series only focuses on getting FreeBSD
booting as a Dom0 and being able to interact with the
hardware.

This project is sponsored by Citrix Systems R&D, and Spectra Logic Corporation.

An Input/Output Memory Management Unit (IOMMU) is a Memory
Management Unit (MMU) that connects a Direct Memory
Access-capable (DMA-capable) I/O bus to main memory; therefore,
I/O virtualization is performed by the chipset. An example
IOMMU is the graphics address remapping table (GART) used by AGP
and PCI Express graphics cards. Intel has published a
specification for IOMMU technology as Virtualization Technology
for Directed I/O, abbreviated VT-d.

A VT-d driver was committed to head and
stable/10, so busdma(9) is now able to utilize
VT-d. The feature is disabled by default, but it may be enabled
via the hw.dmar.enableloader(8) tunable
— see the links for more information. The immediate plans
include increasing the support for this kind of hardware by
testing and providing workarounds for specific issues, and
by adding features of the next generation of Intel IOMMU.
Hopefully, the existing and new consumers of VT-d will start to
use the driver soon.

The auditdistd(8) daemon is responsible for
distributing audit trail files over TCP/IP networks securely and
reliably. Currently, the daemon uses Transport Layer Security
(TLS) for communication, but only server-side certificates are
verified, based on the certificate's fingerprint. The ongoing
work will make it possible to use client-side certificates and
will support more complete public-key infastructure, which
includes validation of the entire certificate chain, including
revocation checking against Certification Revocation Lists at
every level. From now on, auditdistd(8) will support
TLSv1.2 and PFS modes only. In addition, it will be possible to
send audit trail files to multiple receivers.

The GCC compiler in the FreeBSD base system is on its way to
deprecation and is only used by some Tier-2 platforms at this
time. While Clang is much better in many aspects, we still
cannot use all the new features that it
brings in the base system until we can drop GCC completely. As a stop-gap
solution, several bug fixes and features from Apple GCC and
other sources have been ported to our version of GCCÂ 4.2.1
to make it more compatible with Clang. FreeBSD's GCC has added
more warnings and some enhancements like -Wmost and
-Wnewline-eof. An implementation for Apple's blocks
extension is now available, too, and it will be very useful to
enhance FreeBSD's support for Apple's Grand Central Dispatch
(GCD).

Open tasks:

A merge from head to stable/9 is being
considered but it disables nested functions by default, so the
impact on the Ports Collection needs to be evaluated.

BSDInstall has been the default installation program since
FreeBSDÂ 9.0-RELEASE. However, it could not utilize
one of the best features of FreeBSD, ZFS.

The ZFSBoot project started at EuroBSDConÂ 2013 and reached
stable status in December, just in time for
FreeBSDÂ 10.0-RELEASE. Currently, ZFSBoot implements
root-on-ZFS with 4k partition alignment, optional forced 4k
sectors, optional geli(8) full disk encryption, and
support for boot environments.

As part of ZFSBoot, BSDInstall itself also received a number of
updates, including enhanced debugging, more scriptability, a new
keymap selection menu, and a number of other small changes to
streamline the installation process. The new keymap menu allows
the user to test the selected keymap before continuing, to
ensure it is the desired keymap. Minor changes were made to the
network configuration dialogues to make the identification of
wireless interfaces easier.

A number of additional features are also planned. The
user should be able to create additional datasets and adjust the properties on
all datasets in an interactive menu. There should also be integration with BSDConfig
to allow users to install packages and the various other
functionality that was previously provided by
sysinstall.

Open tasks:

Interactive dataset editor.

Dataset property editor.

Consider using shell geom(4) parser.

BSDConfig integration.

UFS as a file system option, to allow users to create
encrypted UFS installs.

Capsicum is a lightweight OS capability and sandbox framework
implementing a hybrid capability system model. The Casper
daemon enables sandboxed application to use functionality
normally unavailable in capability-mode sandboxes.

The Casper daemon, libcasper, libcapsicum(3),
libnv(3) and Casper services (system.dns,
system.grp, system.pwd, system.random
and system.sysctl) have been committed to FreeBSD
head. The tcpdump(8) utility in head
now uses the system.dns service to do DNS lookups. The
kdump(1) utility in head now uses the
system.pwd and system.grp services to convert
user and group identifiers to user and group names.

There is ongoing work to sandbox more applications. If you are
interested in helping to make FreeBSD more secure and would like to
learn about Capsicum and Casper, do not hesitate to contact
Pawel — he can provide candidate programs that could use
sandboxing.

With the sysutils/panicmail port, a mechanism is now
in place for automated submission of
kernel panic reports to a central location. It is hoped that
this will prove useful, as similar systems have for other
operating systems, in identifying common panics so that
developers can be alerted and they can be fixed faster.

In the first two months that this mechanism has been in place,
28 kernel panics have been reported. This is nowhere near enough
to be useful, so readers are strongly encouraged to install the
sysutils/panicmail port and follow the instructions to
enable it.

The FreeBSD Test Suite project aims to equip FreeBSD with a
comprehensive test suite that is easy to run out of the box and
during the development of the system. The test suite is
installed into /usr/tests/ and the kyua(1)
command-line tool (devel/kyua in the Ports Collection)
is used to run them.

The benefits of having a test suite that is easy to use and
continuously run are obvious: regressions can be caught sooner
rather than later and the Release Engineering Team can better
assess the quality of the tree before deciding to cut a release.
Additionally, because we choose to install the tests, we allow
any end user to perform sanity checks on new installations of
the system on their particular hardware configuration — a
very attractive thing to do when deploying production
servers.

During the last few months, we have added the necessary pieces to
the build system to support building and installing test programs of
various kinds. To demonstrate the functionality of these, some test
programs were added and others were migrated from the old testing tree
in tools/regression/ to the new layout for tests.

The current test suite should be seen as a proof of concept at this
point: it is only composed of a small set of test programs and the goal
is to get the infrastructure in place before mass-migrating existing
test code and/or importing external tests.

As part of this work, two new releases of Kyua were published.
Of special interest is the addition of a TAP-compliant backend so
that existing tests from tools/regression/ can be
plugged into the test suite with minimum effort.

As of December 31st, the basic continuous testing
infrastructure is up and running, see the links section for the
home page. For further information, please see the related
announcement and blog post on the subject (also in the links
section).

Open tasks:

We have three machines for the test cluster. At the
moment, only one of them is in use to continuously test amd64 on
both head and stable/10. We need to figure
out the right level of parallelization to put other machines to
use — but a first easy cut may be to just test different
architectures (with the help of QEMU).

Related to the above, the Kyua reporting engine needs
significant tuning to make the reports nice and clean. Ideally,
Kyua should be able to coalesce results from different runs into
a single location and generate cohesive reports out of them.
Fixing this is a high priority.

A tutorial on writing tests for FreeBSD has been proposed for
AsiaBSDConÂ 2014. The outcome of the proposal is still
unknown, but stay tuned!

Port, port, and port more tests to the new test suite. A
test suite is worthless if it does not validate stuff. Stay tuned
for a request for help once we have put all basic pieces in
place and have streamlined the migration process.

LLDB is the debugger in the LLVM family of projects. It
supports Mac OS X, Linux, and FreeBSD, with ongoing work to support
Windows.

In the last quarter of 2013, LLDB gained support for live
(ptrace(2)-based) debugging of multithreaded processes
on FreeBSD. Initial FreeBSD MIPS target support has also been
committed, along with a number of endianness fixes in the
general LLDB infrastructure.

The LLDB snapshot in the FreeBSD tree was updated to
r196322. Currently disabled by default, it will be
enabled for amd64 after the import of ClangÂ 3.4.
In the interim, it may be enabled by adding WITH_LLDB=
to src.conf(5).

This project is sponsored by DARPA/AFRL, SRI International, and University of Cambridge.

Open tasks:

Update the in-tree snapshot to build after the Clang 3.4
import.

Fix amd64 watchpoints.

Test and fix the i386 port.

Implement FreeBSD ARM support.

Add support for kernel debugging (live local and remote
debugging, and core files).

Python is a widely used general-purpose, high-level programming
language. For many operating systems, Python is a standard
component; it ships with FreeBSD as well. A lot of progress has
been made around the FreeBSD Python ports in the last quarter.

The devel/py-distribute port has been replaced by the
refreshed devel/py-setuptools port, which comes with a
lot of features that simplify the methods of installing Python
packages. The change also led us to install everything through
Setuptools now, which resembles PyIP a bit and allows us to
perform some major cleanup on the distutils installation
behaviour.

The implicit lang/python build and run-time dependency
was removed from the ports infrastructure. Every port now
depends on a specific Python version or on the
lang/python metaport. This prevents compatibility
issues for ports that depend on PythonÂ 2.x OR
PythonÂ 3.x exclusively, but use the python
command, which might point to a version of incompatible user
choice.

The lang/python27 port was updated to version 2.7.6,
and the lang/python33 port was updated to version
3.3.3, and the lang/pypy port was updated to version
2.2.1.

We are currently working on the necessary infrastructure quirks
to support different Python versions for the same port. Most of
the work has been done and needs to be tested before it can be
integrated.

Open tasks:

Develop a high-level and lightweight Python Ports Policy.

Add support for granular dependencies (for example
>=1.0 or <2.0).

Look at what adding pip support looks like.

Convert all USE_PYDISTUTILS=easy_install entries to
yes and remove the use of easy_install from
the ports infrastructure.

GNOME is a desktop environment and graphical user interface
that runs on top of a computer operating system. GNOME is part
of the GNU Project and can be used with various Unix-like
operating systems, including FreeBSD.

In this quarter, MATEÂ 1.6 was finally imported into the
Ports Collection, thanks to the efforts of Jeremy Messenger.
MATE is a desktop environment forked from the now-unmaintained
code base of GNOMEÂ 2, therefore it is basically a
replacement for GNOMEÂ 2. Users wanting
to keep GNOMEÂ 2 as their desktop are advised to switch to MATE since
GNOMEÂ 2 will be replaced by GNOMEÂ 3 in the near
future. This switch will be announced in advance, so people
will have time to move to MATE if they have not already. The
complete MATE-based desktop environment can be installed via the
x11/mate port, or, for a minimal install,
x11/mate-base.

Our home page is quite out of date. An update for it for
GNOMEÂ 3.6 is underway. Part of this update is rewriting
and updating the old GNOME porting guide as a chapter of the
Porter's Handbook.

Another major task required for getting a bleeding-edge GNOME
to build on FreeBSD mostly out-of-the box is moving to JHbuild with
some custom rules. This is done to find and fix compile issues
on other BSDs more quickly.

Open tasks:

GNOMEÂ 2 ports still need to be sorted out to evaluate
which GNOMEÂ 2 components will be gone or be replaced with
their newer GNOMEÂ 3 versions. This task is currently halted
until we can get the documentation into a shape good enough to
gather the issues and document the migration, including how
to avoid the migration if the upgrade is not preferred. (This
does not mean we do not want to know about issues with
upgrading, though).

Help the X11 Team with CairoÂ 1.12, since the next
version of GNOMEÂ 3 (3.12) will need an up-to-date version
of Pango and GTKÂ 3.

KDE is an international free software community producing an
integrated set of cross-platform applications designed to run on
Linux, FreeBSD, Solaris, Microsoft Windows, and OS X systems. The
KDE/FreeBSD Team have continued to improve the experience of KDE
software and Qt under FreeBSD.

During the last quarter, the team has kept most of the KDE and Qt
ports up-to-date, working on the following releases:

KDE SC (area51): 4.11.2, 4.11.3, 4.11.4

Qt: 4.8.5 and 5.2 (area51)

PyQt: 4.10.3; SIP: 4.15.2; QScintilla2: 2.8

Qt Creator 2.8.0

KDevelop: 4.5.2

Calligra: 2.7.5

CMake: 2.8.12, 2.8.12.1

As a result, according to PortScout, our team has 464 ports
(down from 473), of which 88.15% are up-to-date (down from
98.73%). iXsystems Inc. continues to provide a machine for
the team to build packages and to test updates. iXsystems Inc.
has been providing the KDE/FreeBSD Team with support for quite a
long time and we are very grateful for that.

As usual, the team is always looking for more testers and
porters, so please contact us or visit our home page (see links).
It would be especially useful to have more helping hands on
tasks such as getting rid of the dependency on the defunct HAL
project and providing integration with KDE's Bluedevil Bluetooth
interface.

Open tasks:

Update out-of-date ports, see links for a list.

Worke on KDEÂ 4.12 and QtÂ 5.

Make sure the whole KDE stack (including Qt) builds and
works correctly with Clang and libc++.

Wine is a free and open source software application that aims
to allow applications designed for Microsoft Windows to run on
Unix-like operating systems, such as FreeBSD. The Wine/FreeBSD Team
have continued to improve the experience of Wine under FreeBSD.

During the fourth quarter of 2013, the team has kept Wine
updated by porting:

Stable releases: 1.6 and 1.6.1

Development releases: 1.7.4 through 1.7.8

The ports have included packages built for amd64
(available through the Ports Collection).

The Wine ports have been kept up-to-date with the changes in
the Ports Collection, including some improvements:

Building with Clang by default (via USES=compiler:c11).

Conditional X11 support (on by default; allowing for
headless instances of Wine).

Staging support and other ports best practices.

Support in improving the experience of Wine on FreeBSD is needed.
Key areas including fixing regressions, adding copy protection
scheme support, and fixing regressions when using Wine under
FreeBSD/amd64.

This change makes X.Org on FreeBSD head work
out-of-the-box on workstations and laptops based on recent Intel
and Radeon GPUs. FreeBSDÂ 10.x will follow in a few weeks or
months.

Some software has started to require CairoÂ 1.12, for
example GTK+Â 3.10 and Pango. Unfortunately, this version
of Cairo triggers a bug in the old Intel driver (2.7.1,
installed when WITH_NEW_XORG is not set), which causes
display artifacts. A "Call For Testers" mail was posted on the
freebsd-x11 mailing-list (see the links above) to
gather information about the behavior on other configurations
(new Intel driver and non-Intel drivers). As of this writing,
the reports received talk about improvements or, at least, no
change noticed.

To better manage changes such as the WITH_NEW_XORG and
the CairoÂ 1.12 changes mentioned above, we asked on the
freebsd-x11 mailing-list if people are using
FreeBSDÂ 8.x on their desktop computers and why they do not
upgrade to FreeBSDÂ 9.x or 10.x. So far, we received very few
answers to this.

The Radeon KMS driver in FreeBSDÂ 10.x is now considered
stable, especially now that integrated GPUs are properly
initialized. One of the next steps will be to merge this to
stable/9.

A "Graphics" wiki article (see links) was created to centralize
and coordinate the work being done on both the ports and the
kernel. It contains the following important information:

A roadmap of the team.

A matrix of supported hardware.

Instructions on upgrading to KMS.

Project status and results.

This starting page then points to project- and topic-specific
articles where more detailed information is available.

Open tasks:

Report why FreeBSDÂ 8.x is still used on your desktop and
why moving to FreeBSDÂ 9.x or 10.x is not an option.

Xfce is a free software desktop environment for Unix and
Unix-like platforms, such as FreeBSD. It aims to be fast and
lightweight, while still being visually appealing and easy to
use. The FreeBSD Xfce Team has kept most of the Xfce ports
up-to-date, while fixing many issues along the way in this
quarter.

Currently, the following components with the following versions
are available:

Applications:

Orage (4.10.0)

Midori (0.5.6)

xfce4-terminal (0.6.3)

xfce4-parole (0.5.3, 0.5.4)

Panel plugins:

xfce4-whiskermenu-plugin (1.2.0, 1.2.1, 1.2.2, 1.3.0)

xfce4-mailwatch-plugin (1.2.0)

xfce4-wmdock-plugin (0.6.0)

We helped Midori's upstream switch from Waf (Python script)
to CMake. Xfce now also supports Gtk2, Gtk3, and the new
WebKitGtk API, available from the 2.x branch, not present in our
ports tree at the moment, though. Most of the ports now use
stage directories, with only some plugins left to convert.

We also removed obsolete ports:

x11-themes/lila-xfwm4 (Xfwm4 theme)

multimedia/xfce4-media (multimedia player)

net-im/xfce4-messenger-plugin

Besides, we followed the development of the Xfce core
components and Parole closely. See the links for documentation
on how to upgrade those libraries.

Open tasks:

Fix Midori's build on DragonFly, through DPorts.

Fix build of the Granite framework (it is an extension to
Gtk and Midori uses it) on FreeBSDÂ 10 and head.
Those are mostly LLVM failures.

The FreeBSD Foundation is a 501(c)(3) non-profit organization
dedicated to supporting and promoting the FreeBSD Project and
community worldwide. Most of the funding is used to support
FreeBSD development projects, conferences and developer summits,
purchase equipment to grow and improve the FreeBSD infrastructure,
and provide legal support for the Project.

We held our year-end fundraising campaign. We are still
processing donations and will post the final numbers by
mid-January. We are extremely grateful to all the individuals
and organizations that supported us and the Project by making a
donation in 2013. We have already started our fundraising
efforts for 2014.

Continued work on the FreeBSD Journal, our new online FreeBSD magazine,
which debuts on January 27th (see links).

Sponsored, organized, and ran the Bay Area Developer Summit.

Sponsored and attended the first ever vBSDCon, which had an
impressive attendance.

Sponsored and attended the OpenZFS developer summit.

Represented the foundation at the following conferences: All
Things Open in Raleigh, NC and LISA in Washington, DC.

Sponsored the FreeBSD 20th Birthday Party, held in San
Francisco.

Attended the ICANN meeting in Buenos Aires in November and
gave a short presentation on the change from BIND to unbound in
FreeBSDÂ 10.0 during the ccNSO Tech Day.

Met with a few companies to discuss their FreeBSD use, what
they would like to see supported in FreeBSD, and assist with
collaboration between them and the Project.

Purchased an 80-core server to reside at Sentex for the
Project to use for stability, scalability, and performance
improvements. It is a big step forwards for the Foundation in
providing this kind of hardware to the Project's developers.
It will let us test our scaling to 80 simultaneous cores and
1Â TB of RAM. It will also be used to do performance
analysis on large workloads, such as large databases etc.

Acquired a second rack to use at Sentex.

We received a commitment from VMware, Inc. for BSD-licensed
drivers. They also committed to a yearly silver level
donation.

Signed up as a Google Compute trusted tester for the
Project.

Funded a project to produce a white paper titled Managed
Services Using FreeBSD at NYI.

Finally, we published our semi-annual newsletter (see links)
highlighting what we did to support the FreeBSD Project and
Community in 2013.