Whitespace-only fixes, translators please ignore.

This commit is contained in:
Warren Block 2014-07-14 12:40:42 +00:00
parent aabc276df3
commit 4d15e8e653
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=45285

View file

@ -1,6 +1,10 @@
<?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" >
<!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>
@ -11,8 +15,7 @@
<section>
<title>Introduction</title>
<p>
<strong>This is a draft of the April-June 2014 status report.
<p><strong>This is a draft of the April-June 2014 status report.
Please check back after it is finalized, and an announcement
email is sent to the FreeBSD-Announce mailing
list.</strong></p>
@ -26,17 +29,17 @@
productive time for &os;. The Ports team released their
landmark first quarterly <q>stable</q> branch. &os; continues
to grow on the ARM architecture, now running on an ARM-based
ChromeBook. SMP is now possible on multi-core ARM systems.
ChromeBook. SMP is now possible on multi-core ARM systems.
bhyve, the native &os; hypervisor, continues to improve. An
integral test suite is taking shape, and the Jenkins Continuous
Integration system has been implemented. &os; patches to GCC
are being <q>forward-ported</q>, and LLDB, the Clang/LLVM
debugger is being ported. Desktop use has also seen
debugger is being ported. Desktop use has also seen
improvements, with work on Gnome, KDE, Xfce, KMS video drivers,
X.org, and <tt>vt</tt>, the new console driver which supports
KMS and Unicode. Linux and Wine binary compatibility layers
have been improved. UEFI booting support has been merged to
head. The &os; Foundation continues to assist in moving &os;
head. The &os; Foundation continues to assist in moving &os;
forward, sponsoring conferences and meetings and numerous
development projects. And these are only some of the things
that happened! Read on for even more.</p>
@ -168,7 +171,7 @@
<p>With all above, and earlier improvements in CAM, GEOM, ZFS
and number of other kernel areas coming soon FreeBSD 10.1 may
become the fastest storage release ever. ;)</p>
become the fastest storage release ever. ;)</p>
<p>These projects are sponsored by iXsystems, Inc.</p>
</body>
@ -179,11 +182,11 @@
<contact>
<person>
<name>
<name>
<given>Andrew</given>
<common>Turner</common>
</name>
<email>andrew@FreeBSD.org</email>
</name>
<email>andrew@FreeBSD.org</email>
</person>
</contact>
@ -193,19 +196,19 @@
<body>
<p>Arm64 is the name of the in-progress port of &os; to the
ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM
CPU designs were 32-bit only. With the introduction of the
ARMv8 architecture, ARM has added a new 64-bit mode. This new
ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM
CPU designs were 32-bit only. With the introduction of the
ARMv8 architecture, ARM has added a new 64-bit mode. This new
mode has been named AArch64.</p>
<p>Booting &os; on the ARM Foundation Model has made a lot of
progress since the last status report. An initial pmap
progress since the last status report. An initial pmap
implementation has been written. With this &os; is able to
enter the Machine Independent boot code. The required autoconf
functions have been added allowing &os; to start scheduling
tasks. Finally the cpu_switch and copystr functions were
added. With these two &os; will boot to the mountroot
prompt.</p>
enter the Machine Independent boot code. The required
autoconf functions have been added allowing &os; to start
scheduling tasks. Finally the cpu_switch and copystr
functions were added. With these two &os; will boot to the
mountroot prompt.</p>
<p>Work has started on supporting exceptions, including
interrupts. This will start to allow more developers to start
@ -214,7 +217,9 @@
<help>
<task>Finish exception and interrupt handling</task>
<task>Read the Device Tree or ACPI tables from UEFI</task>
<task>Test on real hardware</task>
</help>
</project>
@ -285,18 +290,23 @@
next 10-STABLE release and &os;&nbsp;10.1-RELEASE.</p>
<p>Project finally get his man page, so now <tt>vt(4)</tt> not
only project name, but also link to its documentation. Great
only project name, but also link to its documentation. Great
thanks to &a.wblock; for that.</p>
<p>Major highlights:</p>
<ul>
<li>Unicode support.</li>
<li>Double-width character support for CJK characters.</li>
<li><tt>xterm(1)</tt>-like terminal emulation.</li>
<li>Support for Kernel Mode Setting (KMS) drivers
(<tt>i915kms</tt>, <tt>radeonkms</tt>).</li>
<li>Support for different fonts per terminal window.</li>
<li>Simplified drivers.</li>
</ul>
@ -305,17 +315,26 @@
<ul>
<li>amd64 (VGA/<tt>i915kms</tt>/<tt>radeonkms</tt>) &mdash;
works.</li>
<li>ARM framebuffer &mdash; works.</li>
<li>i386 (VGA/<tt>i915kms</tt>/<tt>radeonkms</tt>) &mdash;
works.</li>
<li>IA64 &mdash; untested.</li>
<li>MIPS &mdash; untested.</li>
<li>PPC and PPC64 &mdash; work, but without X.Org yet.</li>
<li>SPARC &mdash; works on certain hardware (e.g., Ultra
5).</li>
<li><tt>vesa(4)</tt> &mdash; in progress.</li>
<li>i386/amd64 nVidia driver &mdash; not supported. VGA
should be used (VESA planned).</li>
<li>Xbox framebuffer driver &mdash; will be deleted as
unused.</li>
</ul>
@ -334,9 +353,13 @@
device (without <tt>kbdmux(4)</tt>).</task>
<task>CJK fonts. (This is in progress).</task>
<task>Address performance issues on some architectures.</task>
<task>Switch to <tt>vt(4)</tt> by default.</task>
<task>Convert keyboard maps for use with <tt>vt(4)</tt>.</task>
<task>Implement compatibility mode to be able to use single-byte
charsets/key-codes in the <tt>vt(4)</tt>.</task>
</help>
@ -347,32 +370,39 @@
<contact>
<person>
<name>
<given>Stacey</given>
<common>Son</common>
</name>
<email>sson@freebsd.org</email>
<name>
<given>Stacey</given>
<common>Son</common>
</name>
<email>sson@freebsd.org</email>
</person>
<person>
<name>
<given>Juergen</given>
<common>Lock</common>
</name>
<email>nox@freebsd.org</email>
<name>
<given>Juergen</given>
<common>Lock</common>
</name>
<email>nox@freebsd.org</email>
</person>
<person>
<name>
<given>Sean</given>
<common>Bruno</common>
</name>
<email>sbruno@freebsd.org</email>
<name>
<given>Sean</given>
<common>Bruno</common>
</name>
<email>sbruno@freebsd.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/QemuUserModeHowTo">Overview of technology</url>
<url href="http://dirty.ysv.freebsd.org/">Status of ports building</url>
<url href="https://github.com/seanbruno/qemu-bsd-user">Master respository for collaboration</url>
<url href="https://wiki.freebsd.org/QemuUserModeHowTo">Overview
of technology</url>
<url href="http://dirty.ysv.freebsd.org/">Status of ports
building</url>
<url href="https://github.com/seanbruno/qemu-bsd-user">Master
respository for collaboration</url>
</links>
<body>
@ -382,15 +412,16 @@
run.</p>
<p>ARMV6, MIPS32 and MIPS64 packages can be produced via full
emulation. There are several packages that block a full run of
builds. They can be viewed on the Status of ports building
link.</p>
emulation. There are several packages that block a full run
of builds. They can be viewed on the Status of ports building
link.</p>
<p>On current or latest stable/10:</p>
<p>Clone the <url href="https://github.com/seanbruno/qemu-bsd-user">github</url>
repository of qemu, and switch to
the bsd-user branch. Then run:</p>
<p>Clone the <url
href="https://github.com/seanbruno/qemu-bsd-user">github</url>
repository of qemu, and switch to the bsd-user branch. Then
run:</p>
<p><tt>./configure --static \<br/>
--target-list="arm-bsd-user i386-bsd-user \<br/>
@ -409,7 +440,7 @@
\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff \<br/>
\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled</tt></p>
<p>Install poudriere-devel from ports. It knows how to setup
<p>Install poudriere-devel from ports. It knows how to set up
things.</p>
<p>Build poudriere jail to do all the magic:</p>
@ -426,6 +457,7 @@
<p><tt>mkdir /usr/local/poudriere/jails/11armv632/usr/ports<br/>
mount -t nullfs /usr/ports /usr/local/poudriere/jails/11armv632/usr/ports</tt></p>
<p>To chroot into the jail:</p>
<p><tt>mount -t devfs devfs /usr/local/poudriere/jails/11armv632/dev<br/>
@ -436,18 +468,22 @@
<task>PPC on AMD64 emulation. WIP as there appears to be some
serious issues running the bsd-user binary on big endian
hardware. Justin Hibbits working on this.</task>
<task>SPARC64 on AMD64 emulation is non-functional and instantly
segfaults. Looking for someone to poke at the bits
here.</task>
<task>External Tool Chain, XDEV support. Partial support for
using an AMD64 tool chain that can output other architecture
(use AMD64 toolchain to build MIPS64 packages). Currently
tracking a linking issue with ports-mgmt/pkg. Thanks to
Warner Losh, Baptiste Daroussin, Dimitry Andric for poking at
bits in here to make the XDEV target useful.</task>
<task>Signal Handling, MIPS/ARMV6 target still displays
a failure that manifests itself when building
<task>Signal Handling, MIPS/ARMV6 target still displays a
failure that manifests itself when building
devel/p5-Sys-SigAction.</task>
<task>Massive documentation update needed. These modifications
actually allow you to chroot into a MIPS or ARMv6 environment
and use native tool chains and libraries to prototype your
@ -460,62 +496,74 @@
<contact>
<person>
<name>
<given>&os;</given>
<common>Python Team</common>
</name>
<email>python@FreeBSD.org</email>
<name>
<given>&os;</given>
<common>Python Team</common>
</name>
<email>python@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.FreeBSD.org/Python">The &os; Python Team Page</url>
<url href="irc://freebsd-python@irc.freenode.net">IRC channel</url>
<url href="https://wiki.FreeBSD.org/Python">The &os; Python Team
Page</url>
<url href="irc://freebsd-python@irc.freenode.net">IRC
channel</url>
</links>
<body>
<p>We are pleased to announce the availability of conflict-free
Python package support across different Python versions based on the
USES=uniquefiles feature recently introduced to the Ports framework.
A Python package can be marked as buildable and installable in
parallel for different Python versions at the same time on the same
host. The package building tools, however, do not support this feature
yet and the Python team will work closely with portmgr and pkg
developers to enable support on a global ports and package scale.
</p>
<p>We are pleased to announce the availability of conflict-free
Python package support across different Python versions based
on the USES=uniquefiles feature recently introduced to the
Ports framework. A Python package can be marked as buildable
and installable in parallel for different Python versions at
the same time on the same host. The package building tools,
however, do not support this feature yet and the Python team
will work closely with portmgr and pkg developers to enable
support on a global ports and package scale.</p>
<p>In May and June a huge clean-up operation took place to remove
the last bits and pieces targeting easy_install. In the beginning of
July we committed the final changes to remove easy_install support
completely from the ports framework. This greatly simplifies the
infrastructure and allows us to modernize and maintain it with less
effort.</p>
<p>In May and June a huge clean-up operation took place to
remove the last bits and pieces targeting easy_install. In
the beginning of July we committed the final changes to remove
easy_install support completely from the ports framework.
This greatly simplifies the infrastructure and allows us to
modernize and maintain it with less effort.</p>
<p>We added Python 3.4, removed Python 3.1 after its end of life,
updated the setuptools ports to version 5.1 and PyPy's development
version to 2.3.1. The latest Python 2.7.8 and an updated setuptools
will hit the tree shortly.</p>
<p>We added Python 3.4, removed Python 3.1 after its end of
life, updated the setuptools ports to version 5.1 and PyPy's
development version to 2.3.1. The latest Python 2.7.8 and an
updated setuptools will hit the tree shortly.</p>
<p>Our upstreaming effort continues to produce good outcomes for
simplifying maintenance and reducing complexity.</p>
<p>Our upstreaming effort continues to produce good outcomes for
simplifying maintenance and reducing complexity.</p>
<p>Looking forward, one of the top priorities is to comply with
the USES framework in the foreseeable future and to roll out a
consistent maintainer policy for integrating new Python-related ports
into the tree.</p>
<p>Looking forward, one of the top priorities is to comply with
the USES framework in the foreseeable future and to roll out a
consistent maintainer policy for integrating new
Python-related ports into the tree.</p>
</body>
<help>
<task>Migrate bsd.python.mk to the Uses framework.</task>
<task>Develop a high-level and lightweight Python Ports Policy.</task>
<task>Add support for granular dependencies (for example &gt;=1.0,&lt;2.0).</task>
<task>Develop a high-level and lightweight Python Ports
Policy.</task>
<task>Add support for granular dependencies (for example
&gt;=1.0,&lt;2.0).</task>
<task>See what adding pip (Python Package Index) support will
require.</task>
<task>Add default QA targets and functions for Python ports (TEST_DEPENDS,
regression-test, etc.)</task>
<task>More tasks can be found on the team's wiki page (see links).</task>
<task>To get involved, interested people can say hello on IRC and let us
know their areas of interest!</task>
require.</task>
<task>Add default QA targets and functions for Python ports
(TEST_DEPENDS, regression-test, etc.)</task>
<task>More tasks can be found on the team's wiki page (see
links).</task>
<task>To get involved, interested people can say hello on IRC
and let us know their areas of interest!</task>
</help>
</project>
@ -524,23 +572,25 @@
<contact>
<person>
<name>
<name>
<given>Ed</given>
<common>Maste</common>
</name>
<email>emaste@FreeBSD.org</email>
</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>
<name>
<given>Nathan</given>
<common>Whitehorn</common>
</name>
<email>nwhitehorn@freebsd.org</email>
</name>
<email>nwhitehorn@freebsd.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/UEFI">&os; UEFI wiki page</url>
<url href="https://wiki.freebsd.org/UEFI">&os; UEFI wiki
page</url>
</links>
<body>
@ -564,7 +614,8 @@
syscons(4) console. Ed added automatic vt(4) selection to the
UEFI boot path.</p>
<p><url href="http://www.freebsd.org/snapshots/">&os;&nbsp;snapshots</url>
<p><url
href="http://www.freebsd.org/snapshots/">&os;&nbsp;snapshots</url>
are now built as dual-mode images, and should boot via BIOS
and UEFI. Our plan is to merge the UEFI and vt(4) work to
stable/10 to appear in &os; 10.1-RELEASE.</p>
@ -575,11 +626,15 @@
<help>
<task>Document manual installation, including dual-boot
configurations.</task>
<task>Implement boot1.efi for ZFS file systems.</task>
<task>Add support for UEFI variables stored in non-volatile
memory (NVRAM).</task>
<task>Debug boot failures with certain UEFI firmware
implementations.</task>
<task>Support secure boot.</task>
</help>
</project>