FreeBSD's documentation falls into three basic categories:
The Project does not really concern itself with these, since they are a part of the base system. The exception to this is the Japanese team, who are translating them. There is no reason other volunteers could not step in to translate the manual pages to other languages as well.
That is not to say that the manual pages are unimportant, far from it. It is just that they are intimately tied to specific systems of FreeBSD, and most of the time the best person to write the manual page is the person that wrote that part of FreeBSD.
The project has a large amount of documentation that is "book length", or becoming that way. These include the FreeBSD FAQ and the FreeBSD Handbook.
FreeBSD has a wealth of information available in shorter, article form -- similar to the tutorials or HOWTO documentation of other projects.
This document assumes that you already know how the port system works, and therefore only provides GNOME-specific hints and tips. General instructions can be found in the FreeBSD Porter's Handbook.
There is an example Makefile for a GNOME port, which uses many of the tricks outlined in this document. Please feel free to use it as a guide for creating your own ports.
GNOME applications under FreeBSD use the USE_GNOME infrastructure. To specify which components of the GNOME system your port needs in order to build, simply list them all as a space-separated list. For example:
USE_XLIB= yes USE_GNOME= gnomeprefix gnomehack libgnomeui
The USE_GNOME components are divided into the following two lists:
If your port needs only GTK2 libraries, the following is the shortest way to define this:
USE_GNOME= gtk20
If your port needs only GTK1 libraries, the following is the shortest way to define this:
USE_GNOME= gtk12
Even if your application needs only the GTK libraries, other USE_GNOME components may be useful. Please scan the entire list to make sure your port uses all relevant components.
Once you have finished with your port, it is a good idea to verify that your port depends on the correct list of components. To see a list of what packages your port will actually require, use the command make package-depends from within your port's directory.
To aid in creating the list of necessary components, it can be helpful to examine the output of make configure. At the end of the checking for... list, there will be a line similar to this:
checking for libgnomeui-2.0 >= 2.0.0 cspi-1.0 >= 1.1.7 libspi-1.0 >= 1.1.7 libbonobo-2.0 >= 2.0.0 atk >= 1.0.0 gtk+-2.0 >= 2.0.0 gail libwnck-1.0 esound... yes
This is a list of the components upon which this application relies to build. Pay close attention to the hierarchical layout of the USE_GNOME system; many components are implied from other USE_GNOME directives. In the above example, USE_GNOME= libgnomeui implies use of libbonoboui, which implies libgnomecanvas, which implies libglade2, which implies gtk20. Thus, even though gtk+-2.0 appears in the list of requisite components, gtk20 can be eliminated from the USE_GNOME list. There are a number of other such redundancies that can be eliminated from this list.
For the above list (taken from sysutils/gok), the following is defined in the Makefile:
USE_GNOME= gnomehack gnomeprefix libgnomeui atspi libwnck
In the beginning, there was only GNOME 1. When the GNOME 2 desktop came around, maximum backwards compatibility was ensured, within reason. GNOME 1 applications can run fine under the GNOME 2 desktop, provided that the applications do not utilize functionality specific to the GNOME 1 desktop environment.
The GNOME 1 desktop, and all applications that will not run under the GNOME 2 desktop, have been removed from the ports tree.
What this means for you, as an application porter, is simply that you should not add GNOME 1-specific applications to the ports tree.
If you wish to determine which version of the GNOME desktop environment is present on a user's machine, you can check the value of GNOME_DESKTOP_VERSION. This variable is set to either "1" or "2" depending upon whether the GNOME 1 or GNOME 2 desktop is installed.
If your port can optionally use GNOME, you must set WANT_GNOME= yes in your Makefile, then check to see if HAVE_GNOME is set for each component from the list above that your port can use. Since this is a conditional evaluation, you need to stick it between bsd.port.pre.mk and bsd.port.post.mk. For example:
WANT_GNOME= yes
.include <bsd.port.pre.mk>
.if ${HAVE_GNOME:Mgnomepanel}!=""
USE_GNOME+= gnomeprefix gnomepanel
CONFIGURE_ARGS+= --with-gnome
PKGNAMESUFFIX= -gnome
.else
CONFIGURE_ARGS+= --without-gnome
.endif
.include <bsd.port.post.mk>
Here, WANT_GNOME tells the ports system to check for the existence of the various GNOME components listed above. For each component found, its name is appended to HAVE_GNOME. Since this port can use gnomepanel, we check HAVE_GNOME to see if it contains gnomepanel (for more on the :Mpattern make syntax, please refer to the - make(1) manpage). + make(1) manpage). If gnomepanel is found, then it is added the list of USE_GNOME dependencies, and the port-specific --with-gnome CONFIGURE_ARG is passed. In an old GNOME infrastructure, PKGNAMESUFFIX was automatically adjusted by the proper USE_* macro. Now it is up to the individual porter to do this. Our example port appends -gnome to the port name to indicate it has been built with GNOME support. The same is true for the DATADIR PLIST_SUB. The individual porter must decide when do the DATADIR substitution. A good rule of thumb is to add the DATADIR PLIST_SUB when using the gnomeprefix component.
Note: You cannot add extra default USE_GNOME components after the .include <bsd.port.pre.mk>. That is, the following is wrong :
.include <bsd.port.pre.mk>
.if ${HAVE_GNOME:Mgnomelibs}!=""
USE_GNOME+= libgnome
.else
USE_GNOME+= gtk12 # WRONG!
.endif
This will make the build system think that GNOME is desired, and mark the pkg-plist accordingly, thus breaking package builds. If you need to add default USE_GNOME components, do so above the .include <bsd.port.pre.mk> line.
To enforce use of optional GNOME dependencies unconditionally, you can add WITH_GNOME= yes to /etc/make.conf or on the make command line. This will always return true when checking for optional GNOME dependencies. If you want the system to always return false when checking for optional GNOME dependencies, you can add WITHOUT_GNOME= yes to /etc/make.conf or to the make command line.
More information on the USE_GNOME infrastructure can be found by looking at the source and comments of ${PORTSDIR}/Mk/bsd.gnome.mk.
Since the release of 2.16, GNOME now lives in LOCALBASE instead of X11BASE. To make it easier for GNOME ports that must also be installed into the same PREFIX as GNOME, a hack has been added to bsd.gnome.mk to force the PREFIX to LOCALBASE whenever the gnomeprefix component is used. This can be overridden by manually specifying PREFIX in your port's Makefile or on the command line.
A large number of GNOME applications (especially GNOME 2 applications) install Open Source Metadata Framework (OMF) files which contain the help file information for those applications. These OMF files require special processing by ScrollKeeper in order for applications like Yelp to find help documentation. In order to accomplish proper registry of these OMF files when installing GNOME applications from packages, you should make sure that omf files are listed in pkg-plist and that your Makefile has this defined:
INSTALLS_OMF="yes"
GConf is the XML-based database that virtually all GNOME applications use for storing their settings. This database is defined by installed schema files that are used to generate %gconf.xml key files. Previously, these schema files and %gconf.xml key files were listed in the port's pkg-plist. Since this proved to be problematic, handling of GConf schemas was changed to something similar to that of MANn files. That is, for each schema file installed by your port, you must have the following listed in the Makefile:
GCONF_SCHEMAS= my_app.schemas my_app2.schemas my_app3.schemas
For example in audio/gnome-media:
GCONF_SCHEMAS= CDDB-Slave2.schemas gnome-audio-profiles.schemas \ gnome-cd.schemas gnome-sound-recorder.schemas
The schema files and %gconf.xml key files should not be in the pkg-plist. If you notice that the port doesn't has any %gconf.xml key files, but has schema files then you should not be use GCONF_SCHEMAS. It means, this port has broke either schema files or installation of GConf.
If your port install files like application/x-portname.xml in share/mime, you have to add these two lines at the end of the pkg-plist:
@exec %%LOCALBASE%%/bin/update-mime-database %D/share/mime @unexec %%LOCALBASE%%/bin/update-mime-database %D/share/mime
Also make sure shared-mime-info is among the dependencies of your port. If your port use gtk20, you will have shared-mime-info indirectly. You can check indirect dependencies with make describe.
Example port to look at: deskutils/drivel
Some ports provide MIME definitions in their .desktop files. If your port install .desktop file into share/applications and there is a line starting with MimeType in it, you need to update desktop database after install and deinstall. This database is represented by share/applications/mimeinfo.cache file. Add dependency on GNOME component desktopfileutils and these lines to the end of pkg-plist:
@exec %%LOCALBASE%%/bin/update-desktop-database > /dev/null || /usr/bin/true @unexec %%LOCALBASE%%/bin/update-desktop-database > /dev/null || /usr/bin/true
Also add following to the post-install target in port's Makefile:
-@update-desktop-database
Example port to look at: editors/leafpad
Most, if not all, GNOME applications depend on GNU's libtool. They also use the GNU configure system. If your port installs shared libraries, and includes an ltmain.sh script in its ${WRKSRC} directory, you should add USES=libtool to your port's Makefile.
To separate GNOME 2 distfiles from the GNOME 1 distfiles, and to keep the distfiles directory clean, GNOME 1 ports that download their distfiles from ${MASTER_SITE_GNOME} must add the following to their Makefile:
DIST_SUBDIR= gnome
GNOME 2 ports that download their distfiles from ${MASTER_SITE_GNOME} must include the following in their Makefile:
DIST_SUBDIR= gnome2
Some GNOME distfiles come in both tar gzip as well as tar bzip2 format. To save time when downloading distfiles over slow links, you should use the bzip2 distfiles whenever possible. To do this, add the following to your port's Makefile:
USE_BZIP2= yes
If you still need help with your port, have a look at some of the existing ports for examples. The freebsd-gnome mailing list is also there for you.
Index: head/en_US.ISO8859-1/htdocs/ipv6/index.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/ipv6/index.xml (revision 45653) +++ head/en_US.ISO8859-1/htdocs/ipv6/index.xml (revision 45654) @@ -1,131 +1,131 @@ %catnav; ]>&os; has shipped tightly integrated IPv6 support for over a decade, with the &os; 4.0 in 2000 the first release to include "out-of-the-box" IPv6 support. These web pages document on-going IPv6 development in the FreeBSD community, including participation in IPv6 World Day 2011.
&os; is a widely used, open source operating system whose network stack has been the foundation for decades of research, as well as a reference implementation of IPv6 (developed by the KAME project). &os; first shipped IPv6 support in March 2000 as part of &os; 4.0-Release.
The &os; Project has been an early adopter and active participant in the IPv6 community. With the help of the community, we have been serving releases from IPv6-enabled servers since May 2003 and &os;'s website, mailing lists, and developer infrastructure have been IPv6 enabled since 2007.
&os; is used by critical Internet infrastructure such as root name servers, routers, firewalls and some of the world's busiest and most reliable web sites as well as embedded into many products all in the need for the best IPv6 support. To read more about some companies using the &os; operating system in their products, see the &os; Foundation Testimonials page.
Index: head/en_US.ISO8859-1/htdocs/platforms/ia64/index.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/platforms/ia64/index.xml (revision 45653) +++ head/en_US.ISO8859-1/htdocs/platforms/ia64/index.xml (revision 45654) @@ -1,69 +1,69 @@ ]>
Search the ia64 mailing list archives:
-The FreeBSD/ia64 project pages contain information about the FreeBSD port to Intel's IA-64 architecture; officially known as the Intel Itanium® Processor Family (IPF). As with the port itself, these pages are still mostly a work in progress.
The ia64 port is still considered a tier 2 platform. This boils
down to not being fully supported by our security officer, release
engineers and toolchain maintainers. In practice however the
distinction between a tier 1 platform (which is fully supported)
and a tier 2 platform is not as strict as it seems. In almost all
aspects the ia64 port is a tier 1 platform.
From a developer point of view there's an advantage to have the ia64
port be a tier 2 platform for a while longer. We still have a couple
of ABI breaking changes in the pipeline and having to maintain
backward compatibility this early in a ports life is less than
ideal.
The acpi driver provides support for the Intel/Microsoft/Compaq/Toshiba ACPI standard. This support includes platform hardware discovery (superseding the PnP and PCI BIOS), as well as power management (superseding APM) and other features. ACPI core support is provided by the ACPI-CA reference implementation from Intel.
Information on using and debugging ACPI can be found in the handbook entry and - man page.
+ man page.If you are looking for the list of completed projects not located on this page, it can be found here.
| Task | Responsible | Last updated | Priority | Notes |
|---|---|---|---|---|
| Save/Restore PCI capabilities lists and MSI config space | &a.njl; | August 3, 2006 | &status.wip; | |
| Investigate disabling the LAPIC timer when using ACPI C2-3 states. Otherwise, the system hangs and no timer interrupts occur while idle. | August 3, 2006 | &status.new; | ||
| acpi_cpu — Finish work on CPU driver | ||||
| _CST re-evaluation | &a.njl; | December 4, 2004 | &status.new; | Needs testing/debugging |
| Fix shared user of a P_BLK (refcount) | &a.njl; | December 4, 2004 | &status.new; | |
| Disable acpi_cpu taking over idling if only C1 available | &a.njl; | December 4, 2004 | &status.new; | I still want to keep acpi_cpu in the loop on SMP systems so we should leave this as-is for now. |
| eject methods — implement eject and dynamic reprobing of acpi namespace | &a.njl; | December 4, 2004 | &status.untested; | |
| Hotkey/backlight/sound generic driver -- Add a driver that generalizes the various device-specific ways of adjusting backlight, sound volume, hotkey support, etc. It should provide generic sysctls for these and attach to the hw-specific drivers (acpi_video, acpi_asus, acpi_toshiba, etc.) | &status.new; |
| Implement X suspend/resume notification. Currently, the X server on FreeBSD is not notified of a suspend. We explicitly switch to a VTY on syscons before resume to get the server to save and then restore all the registers. This works for many systems but not if the display is left in less initialized at resume than the VTY switch code can handle. There is an interface (in the X server bsd_apm.c) for doing ioctls to find out about the suspend. First, check if this file is built on FreeBSD as it appears to only be built on NetBSD. Then implement the ioctls in both apm and acpi (on the apm compat device). Here is a patch to help the X file compile. For acpi, we do not want a user process dying to hold up the suspend process so implement the notification with a timeout. That is, if the kernel generates a APM_STANDBY_REQ notification and it doesn't receive a APM_IOC_STANDBY within say 5 seconds, continue the suspend process. This is needed for standby when X is not running, for instance, or when an emergency suspend is generated by a battery going critical. | &status.new; | |||
| Examine the two video resume hacks (int 0x10, lcall 0xc000). Linux has begun to test calling the "lcall" VESA reset after PCI devices (including the video card) have been fully resumed, including power state set to PS0. This works for many Radeon cards but fails for others. We could implement this in vm86 calls from a proper video driver resume method. Investigate integrate the techniques used by the Radeontool + href="&cgibase;/url.cgi?ports/sysutils/radeontool/pkg-descr">Radeontool port in video resume. | &status.new; | |||
| ACPI-CA should really enable GPEs before calling \_WAK. Currently it does the opposite. This does not match the ACPI spec where \_WAK should be called after the system is up and running (\_BFS is what should be called as soon as possible after waking.) | &status.new; | |||
| Potential ASL bug: We may need to work around some systems having the S3 object listed under the LPC bus device (PNP0A03) instead of root (\). This is ACPI-CA's responsibility. | &status.new; | |||
| For systems that fail to power off, try using the suspend code (acpi_SetSleepState) instead. | &status.new; | |||
| See if we can enable EC access early even if an ECDT is not present. The _INI method for some ECs accesses the EC region even though _REG has not been called since the region is not initialized yet. It is likely that Windows hard-codes the EC resources and enables the region before initializing the device even though this is not allowed by the spec. | &status.new; | |||
| Implement reset register functionality for rebooting systems that lack a keyboard controller (see ACPI v2 FADT->ResetRegister). | &status.new; | |||
| Be sure not to try to disable ACPI on systems that do not have SMI_CMD or ACPI_ENABLE/DISABLE values in the FADT. The ia64 machines specify ACPI-only (no legacy mode) so they have 0 for these values and we should not enable/disable ACPI on them. Doing so gives a "failed to switch modes" warning but no real problems, apparently. | &status.new; | |||
| Check our implementation of AcpiOsDerivePciId(). It is probably not quite right. Compare against Linux. | &status.new; | |||
| Run instructions on cpu0 for suspend/resume. We currently do this for shutdown in kern_shutdown.c:boot(). This will also be required for SMP cpufreq drivers that set the frequency via a CPU-specific MSR. | &status.new; | |||
| Traverse local reference (scope) types in namespace when probing devices. | &status.new; | |||
| Implement support for _PRS/_SRS and dependent functions. This will allow serial port configuration to occur. | &status.new; | |||
| Add EC burst mode -- Code was written before to add burst mode to the EC. Unfortunately, it had to be disabled since it did not appear to work on all systems. Perhaps on some systems do not function correctly without burst mode, so it will be added back with some logic to fallback if it fails. | &status.new; | |||
| Intel firmware seems to describe the PCI root bridge where chipset configuration space lives with _STA=="0x8". The spec says this means "functional, but not present". The current code ignores things that are "not present" ( msg). It is suggested that this should be handled by not attaching a driver to the device (i.e. bridge) but probe its children. Present on Big Sur and Bull systems. | &status.new; | |||
| Re-work device wake setup to not be recursive. The acpi_wake_sysctl_walk() syscall has to call itself to handle child devices on other busses (PCI). This should probably be changed to be a DEVMETHOD. | &status.new; | |||
| device_power -- Add a "power" argument to devctl(8) that allows a device to be set into various low power or off states. | &status.new; | |||
| device_eject -- Add a devctl(8) program that has an "eject" argument. Allow users to eject various object names ("/dev/cdrom", "/mnt/flashdrive", "wi0", "pci0:2:0"). Call the appropriate _EJD and _EJx methods if appropriate. | &a.imp;, &a.jhb;, and &a.takawata; | &status.wip; | ||
| suspend to disk -- Implement a suspend/resume from disk mechanism. Possibly use the dump functions to dump pages to disk, then use ACPI to put the system in S4 or power-off. Resume would require changes to the loader to load the memory image directly and then begin executing again. | &status.new; | |||
| HP/Toshiba Satellite driver -- Enabling the extra one-touch/multimedia keys, console blanking, battery and temperature reporting, etc. Get an idea of what is needed from the Linux OMKE project . | &status.new; | |||
| ASL capture bootable CD-R -- Build a set of scripts to generate a bootable CD-R. It should have a GENERIC kernel and acpidump/iasl as well as all support libraries. Replace init with a script such that booting the CD generates an acpidump -t -d > machine.asl and dmesg > machine.dmesg in an MFS partition. Then burn this info to a second track on the CD-R. This will make an easy way to take a batch of CDRWs to the local computer store, place them in the CDRW drive, boot FreeBSD and get the ASL. | &status.new; | |||
| ASL Explorer -- Graphical utility for examining the output of acpidump(8). Contact &a.njl; for info about the design if you are interested in implementing this. | &status.new; | |||
| Document acpi kernel interfaces -- Document the interfaces for drivers found in acpivar.h. | &status.new; | |||
| KTR support for ACPI debug messages -- Use the KTR logging facility instead of printf for ACPI debugging messages. This would allow more verbose messages and fast dumping. | &status.new; | |||
| Add support for the real-time clock (RTC) to use to wake or power-on systems at a certain time of day. | &status.new; | |||
| Quiesce USB when no device is attached (see Linux UHCI) -- this would help such systems use C3 more, saving power with USB loaded. While at it, fix uhci suspend/resume. | &status.new; |
You can search only the mail header keywords Message-ID, Resent-Message-id, In-Reply-to, and References. A Message-ID looks like <199802242058.MAA24843@monk.via.net>. No other mail header keywords are supported. The Message-ID database will be updated every hour.
Full text mailing list archives. Index: head/en_US.ISO8859-1/htdocs/search/search.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/search/search.xml (revision 45653) +++ head/en_US.ISO8859-1/htdocs/search/search.xml (revision 45654) @@ -1,710 +1,710 @@ ]>List of FreeBSD OpenSearch Plugins
The mailing list archive indexes are now updated weekly!
An alternative way to read the mailing lists archives is to use the Mailman/Pipermail list archive (note that this archive only carries messages from March 2003 onward).
The mailing lists (as well as many others) have also been archived by MarkMail.
- Index: head/share/xml/common.ent =================================================================== --- head/share/xml/common.ent (revision 45653) +++ head/share/xml/common.ent (revision 45654) @@ -1,86 +1,86 @@ ]]> - - + + - +