HOWTO Interpret the Names of Packages Distributed by MinGW

Many of the files on the MinGW Sourceforge File Release System have very long and intricate names, and it's often hard to determine (a) exactly what you need to download, and (b) what each of the various downloads actually contains. For example:


is gibberish, unless you know how to interpret it. Well, gentle reader, you're come to the right place!

First, a disclaimer: at the time of writing, most of the files on the File Release System do not yet follow the naming scheme described below. However, we expect that once this schema is finalized, many packages will be rapidly repackaged to adhere to the new standard. Until then...

Second, Keith Marshall has written a program to automatically parse, validate, interpret, and display package names in a human-readable format. See the Automated Parser section, below.


The MinGW project has developed a schema for naming packages distributed by the project. In general, package names are structured as a sequence of fields delimited by hyphens, and terminated with archive and/or compression extensions. The schema is defined as follows:

<archive-name>      ::= <package-id>[["-"<system-id>]][[-<status>]]"-"<type-id>
<package-id>        ::= <package-name>"-"<version>[["-"<build-id>]]
<system-id>         ::= <system-name>[["-"<version>[["-"<build-id>]]]]
<type-id>           ::= <component-id>"."<format-type>[["."<compression-type>]]
<package-name>      ::= !"-"{!"-"}
<version>           ::= <major>[["."<minor>[["."<patchlevel>]]]]
<major>             ::= "0".."9"{"0".."9"}
<minor>             ::= "0".."9"{"0".."9"}[[<suffix>]]
<patchlevel>        ::= "0".."9"{"0".."9"}[[<suffix>]]
<suffix>            ::= {!("0".."9"|"-"|".")}
<build-id>          ::= <datestamp>|<serial-number>{"-"<serial-number>}
<serial-number>     ::= "0".."9"{"0".."9"}
<datestamp>         ::= <serial-number> ; nominally 8 digit date as YYYYMMDD
                                         ; (currently unenforced, however)

<system-name>       ::= !("0".."9"|"-"|"."){!("-"|".")}

<status>            ::= ("alpha"|"beta"|"stable")[[-<build-id>]]

<component-id>      ::= <component-class>[["-"<component-version>]]

<component-class>   ::= !("0".."9"|"-"|"."){!("-"|".")}
<component-version> ::= "0".."9"{!("-"|".")}

<format-type>       ::= !("-"|"."){!("-"|".")}
<compression-type>  ::= !("-"|"."){!("-"|".")}

<format-type> is expected to take one of the nominal values from the
    set "exe"|"tar"|"zip"; however, this is not enforced.
<compression-type> is expected to take one of the nominal values from the
    set "bz2"|"gz"|"lzma"; however, this is similarly not enforced.

While at first glance this schema may seem complicated, its flexibility is necessary to support the various goals and requirements of the packaging system under development:

  • Implicit association between source packages and compiled binaries. Aside from representing good practice and promoting repeatability, many of the binary packages provided by the MinGW project are licensed under the GPL. Obvious source-binary association aids in GPL compliance.
  • The MinGW project supports three (possibly four) different build environments. These can include "native" win32 binaries; "MSYS" binaries used to enhance the development process when using MinGW tools to compile native win32 binaries; and "MSYS" binaries used to self-host the MSYS tools themselves. (The fourth build environment would include such things as cross-compilers and cross-sysroot packages. At present, MinGW supports only a build script so that interested parties can construct these cross-toolchains themselves. MinGW does not currently distribute pre-built cross-compilers).
  • Increased granularity of compiled products compared to earlier MinGW products. This allows end users to download only what is explicitly needed for their environments, without forcing all users to download the universe of precompiled MinGW packages.
  • Explicit version tracking, including upstream package versions and MinGW-specific build versions.
  • Parseable: the package names must be explicitly parseable by an automated utility. This will allow a future MinGW installer to be used for maintaining and upgrading existing MinGW installations, as well as allowing that installer to understand the dependencies between binary packages.


For example, consider the following package name:


By parsing the name using the schema above, we have

Package Name:      guile
Package Version:   1.8.4
Package Build:     1
Subsystem Name:    msys
Subsystem Version: 1.0.11
Subsystem Build:   <unspecified>
Release Status:    <unspecified>
Release Reference: <unspecified>
Component Type:    dll
Component Version: 17
Archive Format:    tar
Compression Type:   lzma

In other words, this package contains one or more DLLs that are part of the guile distribution. These DLLs have an associated version number "17"; the upstream package version is 1.8.4. For more information about DLL version numbering on win32, this page, while specific to cygwin and libpng, gives a good overview of the issues and rationale, and is applicable here. The package has been compiled such that it requires the MSYS environment, specifically version 1.0.11, of MSYS (it may or may not work with other versions of MSYS). This is the first build of this specific package for this subsystem. It is distributed as an lzma-compressed tar file.


Each field within the package name is described below, including various notes about the possible or typical values.

Package Name

This is usually the name of the "upstream" source project. For instance, if the upstream project is called flex, then the main executables from that project, as compiled by the MinGW or MSYS team, will be distributed using the Package Name flex. In some cases, a single "upstream" project may be distributed by in several separately downloadable files. These separate files will, in general, have the following characteristics:

  • Their contents will be disjoint; that is, no individual installed file will be provided by more than one downloadable package of the same subsystem-id, version, and release.
  • The union of all such packages for a single "upstream" source project, of the same subsystem-id, version, and release, will provide the complete installation profile of that upstream project, as compiled for the MinGW or MSYS environment.
  • All such packages for a single "upstream" source project, with the same subsystem-id, version, and release, will be identically named with the following exceptions:
    • The Component Type will differ
    • The Component Version may be present on some, but not all, of the packages in the set
    • The Package Name may, in some circumstances, vary. For instance, the bzip2 upstream project will be distributed by the MinGW team in five separate packages (see Component Type, below, for a description of the difference between these five (sub)packages). The -dll- package has a different name, reflecting the name of the actual DLL that it provides, rather than the base name of the package. This helps when specifying dependencies between packages.
      • bzip2-1.0.5-1-mingw32-bin.tar.lzma
      • bzip2-1.0.5-1-mingw32-dev.tar.lzma
      • bzip2-1.0.5-1-mingw32-doc.tar.lzma
      • libbz2-1.0.5-1-mingw32-dll-1.tar.lzma
      • bzip2-1.0.5-1-mingw32-src.tar.lzma
    • Typically, all such packages for a single "upstream" source project, with the same subsystem-id, version, and release, will be presented on the SourceForge File Release System as the elements of a specific Release of a specific Package (where the terms Release and Package in this sentence refer to the SourceForge FRS nomenclature). For instance, the example above would be presented in the File Release System as:
      Package: MinGW Utilities - bzip2
          Release: bzip2-1.0.5-1-mingw32
              File: bzip2-1.0.5-1-mingw32-bin.tar.lzma
              File: bzip2-1.0.5-1-mingw32-dev.tar.lzma
              File: bzip2-1.0.5-1-mingw32-doc.tar.lzma
              File: libbz2-1.0.5-1-mingw32-dll-1.tar.lzma
              File: bzip2-1.0.5-1-mingw32-src.tar.lzma
          Release: bzip2-SomeOtherVersion-N-mingw32
              File(s): ...
      Package: MSYS Utilities - bzip2
          Release: bzip2-1.0.5-1-msys
              File(s): ...

Package Version

This field represents the version of the source code for the project, as obtained from the "upstream" project site. It is generally the dot-delimited numeric version number of the "upstream" project in the form X.Y.Z, where X is the major version, Y is the minor version, and Z (if present) is the micro version or patchlevel. The last such "number" may also have an alphabetic suffix, such as 2.3beta, or 1.4.5rc.

When building packages derived from unofficial upstream releases (such as a snapshot of the upstream project's ongoing development), it is helpful to specify either a serial number or a datestamp as part of the Package Version. This is may be indicated in one of several ways:

  • specify the version AND a datestamp within the Package Version field, as in libtool-2.2.7a_20090710 (note that there is an underscore separating 2.2.7a and 20090710, not a hyphen or decimal point. Using a hyphen would cause the datestamp to be interpreted as part of the Package Build; see below for why that is discouraged. Using a decimal point could interfere with the major/minor/patchlevel interpretation.)
  • specify only the datestamp, with a source control suffix, as in libtool-20090710git_pr. This example indicates a snapshot of the upstream git repository taken on July 10, 2009, from the pr branch. No hyphens should be used. If the default branch is used (project dependent, but generally trunk for cvs or svn; master for git), then it need not be specified: libtool-20090710git.
  • use a serial number indicating successive snapshots from the upstream source control repository, as in libtool-2.2.7a_14 which indicates the fourteenth snapshot taken by the MinGW team of the libtool development branch. This is less informative than the other two alternatives, as it requires the end user to do some investigation to determine exactly when the fourteenth snapshot was taken.

Package Build

 This field is reserved for indicating successive builds of the '''same''' upstream source. For instance, suppose the official upstream <nowiki>zlib-1.2.3.tar.gz</nowiki> source distribution is used, in two successive instances, to build packages for the ''mingw32'' subsystem, '''but''' with the following distinctions:

  • In the first case, the upstream source distribution is used unmodified
  • In the second case, the upstream source distribution is used, but the zlib-1.2.3-mingw32-src.tar.gz package distributed from includes a build script that applies a custom patch to correct some portability issue.

In both cases, the "upstream" project version is 1.2.3. To distinguish between the two builds, the Package Build field is used. Generally, it is a sequential build serial number (zlib-1.2.3-1, zlib-1.2.3-2, etc) but may instead be a datestamp as in zlib-1.2.3-20090710. Generally a sequential serial number is preferred, as the combination of upstream source control datestamps and build datestamps can become confusing while providing no useful additional information: libtool-2.2.7a_20090710-20090712.

As an alternative, packages unique to the MinGW project which undergo heavy development outside of the confines of the upstream project -- such as the elements of the MinGW gcc packages themselves -- can also use the Release Status and Release Reference fields below, instead of the Package Build field.

Subsystem Name

The Subsystem Name indicates the "host" for which the package was configured (as in, --host=mingw32 or --host=msys). Indirectly, for official MinGW-project distributed packages, it also indicates the standard installation prefix for which the package was configured.

Generally speaking, there are three possible values for the Subsystem Name. These are mingw32, msys, and mingwPORT. In the future, other subsystems such as mingw64 may be supported. Also, if no specific subsystem applies, then the Subsystem Name may be omitted. This would be the case for completely unmodified -src packages (see Component Type, below) or for the mingw-cross build script package which is intended for use on any non-MinGW host, such as cygwin or GNU/Linux.


In general, these packages were configured using --host=mingw32 (or, were configured and built "natively" within an MSYS environment, in which --host was not explicitly specified; in this circumstance, these builds behave as if --host=mingw32 was specified). In addition, these packages were all configured using --prefix=/mingw (or, in many cases, --prefix=`cd /mingw && pwd -W`; this formulation should always resolve to C:\MinGW for official MinGW packages).

In almost all cases, these packages contain native win32 executables and libraries, and are usable without an MSYS installation. However, in some few cases the packages may also contain scripts written in shell or perl. In these cases, the scripts may not operate correctly unless an MSYS installation also exists.

One notable group of packages that contain such scripts are the family of autotool packages with the mingw32 Subsystem Name. These package are:

  • autoconf
  • automake
  • libtool
  • gettext

Other packages, such as bzip2, provide primary functionality via native executables and libraries. Such executables and libraries may be expected to operate correctly in the absence of MSYS. However, such packages may provide additional features via scripts; these scripts are likely to require MSYS.

In most cases, official MinGW packages with the mingw32 Subsystem Name should be installed into the C:\MinGW directory. You may achieve limited success installing these packages into a different directory, but this is not generally recommended. (If you do choose to install in a different directory, please ensure that you choose a location which does not have white space within its absolute path name. In particular, no package designated by a Subsystem Name of mingw32 should ever be installed into the Program Files tree, so popular among MS-Windows developers -- if you ignore this advice, you will break your installation; please resist the temptation to email us, or to file a bug report, telling us so). The official recommendation is to install pre-compiled packages from with the mingw32 Subsystem Name into C:\MinGW.

If you intend to use MinGW packages bearing the mingw32 Subsystem Name in an MSYS hosted environment, (as several are intended to be used), you should ensure that the MinGW installation tree is mounted on the MSYS /mingw mount point; this is achieved, by ensuring that the MSYS /etc/fstab file contains an entry of the form:--

C:/MinGW   /mingw

(This is applicable for a completely standard MinGW installation. If you chose an alternative installation directory, you should substitute the appropriate full absolute path, in place of C:/MinGW).


These packages were configured using --host=msys and compiled using the special msysdvlpr environment. Binary executables and libraries in these packages depend on the MSYS DLL; they are not "native" mingw32 applications. These packages were configured using --prefix=/usr (and will never have been configured using the --prefix=`cd foo && pwd -W` formulation). It is expected that these packages will be unpacked in the /usr==/ directory -- that is, they should be unpacked into the versioned root directory for msys. Typically, this is C:\msys\1.0, (subject to the same caveats regarding white space, as stipulated above for the mingw32 subsystem, should you choose to relocate this).

Packages with the msys Subsystem Name are part of the msys environment, and generally help to provide a more "unix-like" experience for users building native mingw32 applications.


These packages consist entirely of shell scripts automating the process of building software on your own computer in a repeatable manner. mingwPORTs can be used to download the original source code, unpack, patch, compile it using the MinGW GCC compiler tools using customized settings, and install the newly-compiled software on your system. These packages can only be used from within an MSYS environment. As the installed results will have been compiled using the MinGW compiler, these installed results could be considered similar in most respects to the prepackaged binary distributions in the mingw32 subsystem as described above. In the future, it is possible that some mingwPORTs may support a mingw64 compiler; so it is possible that, depending on the characteristics of the compiler you choose to use when "running" the mingwPORT script(s), the installed results may instead be similar to some hypothetical mingw64 subsystem.

However, the mingwPORT itself is neither fish nor fowl: it is not itself an msys package, nor a mingw32 package. mingwPORTs are not "configured" and thus there is no tell-tale --host=??? argument we could use to infer a specific subsystem. Therefore, mingwPORTs are given their own Subsystem Name.


To sum up, if the package was configured using --host=mingw32 either explicitly or implicitly, then it will have the mingw32 Subsystem Name, AND it will have been configured using --prefix=/mingw or --prefix=`cd /mingw && pwd -W`, whichever is appropriate. Note that this will be true regardless of the contents of the package:

  • If the package's functionality is primarily provided by compiled executables and libraries, then the fact that it may happen to also provide a few ancillary scripts, which only work on MSYS, is immaterial. The --host for the compiled executables controls, and the "extras" are just carried along for the ride.
  • If the package's functionality is primarily provided by scripts which require an msys scripting host for proper operation, then the --host still controls, even if it makes little difference to the actual content of the scripts themselves, and even if it differs from the required script host. For example, automake-*-mingw32 is completely useless without an MSYS script host, but because the package was configured with --host=mingw32 (and --prefix=/mingw), it has a Subsystem Name of mingw32 and should be installed/unpacked into C:\MinGW.

Subsystem Version

In some cases, it is important to distinguish between different versions of the Subsystem Name. That is, some packages may be specific to MSYS-1.0.10, while others may require MSYS-1.0.11. Still others may require features present only in the (future) MSYS-1.0.12beta. It is also possible that some binary packages for the mingw32 subsystem may be specific to some version of the windows operating system, although that is unlikely. To distinguish these builds, the Subsystem Version and Subsystem Build fields may be used. As with the Package Version, this field is generally a "dotted triple" version number, such as 1.3.2.

To specify windows operating system versions, these rules may be adopted:

  • For NT and above, use the dwMajorVersion and dwMinorVersion version numbers from OSVERSIONINFOEX.
  • For win9x, use "95sp2", "98", "Me" etc.

However, it is not expected that this sort of qualification of Subsystem Version value, specifying the required windows OS for a mingw32 package, will be necessary. In most cases, mingw32 itself is already sufficiently explicit, (and any future package, built explicitly for 64-bit systems, would bear a mingw64 Subsystem Name).

Subsystem Build

If necessary to distinguish between two different builds of the same Subsystem Version, such that a particular package will work with MSYS-1.0.11-20080908 but not MSYS-1.0.11-20080712, this field is available. We do not expect this field to be used often.

Release Status

Generally, this field is used only for packages that undergo extensive, and iterative, development by the MinGW team, outside the confines of the upstream project. The prime example here is the elements of the MinGW GCC packages themselves. There are several possible values:

  • alpha: Unstable, work in progress. Probably has many known and unknown sharp edges; you will get cut.
  • beta: Unstable, but suitable for most users to begin experimenting. Don't use it for production code.
  • rc: Release candidate. Ready for general use, and needs community involvement to flush out and fix any last minute bugs. These will probably be minor.
  • stable: Final production release. Most stable releases will omit the Release Status field entirely; thus, it follows that any current package which omits this qualifier is considered to be a stable release.

Release Reference

Like the Release Status field, this one is used only for packages that undergo extensive, and iterative, development by the MinGW team, outside the confines of the upstream project. This field consists of either a serial number, or (more commonly) a datestamp indicating the release date. It cannot appear unless there is also a Release Status value. For example, the current gcc-core package is named:


but it could have been named:


The next refresh (if there is one prior to the upstream rollout of 4.4.1) of MinGW gcc 4.4.0 could be named one of


without confusion.

Component Type

This field is required. It is generally a short (three-character) string that indicates the type of files contained in the package. The following list is not exhaustive:

  • bin: Contains the "compiled" results of the package, with certain exceptions if one of the other Component Types provides a better fit. Generally, these are binary executables for the specified Subsystem Name, but bin packages may also include scripts written in various languages, configuration files necessary for proper operation of the included executables, and other items. bin packages do not typically contain documentation such as man pages or info files.
  • dev: There are generally two types of projects whose MinGW package set includes a dev package: those projects that provide reusable libraries; and those packages that provide both utilities of general use, and other utilities that are of interest only to developers. The former category includes such projects as zlib, libpng, or libxml. These projects may also provide utility programs (which MinGW would distribute in a bin package). The latter category includes projects such as gettext, which provides general use tools such as gettext.exe, but also developer-centric utilities such as msgcat.exe and autopoint. For libraries, the dev package contains the header files, static libraries, import libraries, and sometimes API documentation of interest and use to developers. dev packages may also contain the developer-centric utilities and associated documentation. These packages may also contain coding examples and demonstration projects. In short, dev packages are a grab-bag of all the items of interest to developers. The intention is to allow the size of the other (sub)packages, such as bin, doc, and dll packages, to be minimized.
  • doc: Generally contains the man pages and info files associated with the applications in the related bin package. May also contain README files and other documentation (typically whatever is installed into {prefix}/share/doc).
  • man: In some cases, the package set maintainer may choose to separate unix-style manual page documentation into a separate package. More rarely, some package sets may ship only man documentation and no other documentation at all. In these cases, the man Component Type is available.
  • sh: Generally used with packages whose Subsystem Name is mingwPORT. As mingwPORTs consist entirely of shell scripts used to build mingw32 packages, but operate only in MSYS-hosted mingw32 environments (or possibly, mingw64 environments), the other Component Types could be misleading. Therefore, this one was invented. The package name also then becomes a mnemonic for the proper use of the mingwPORT script itself:

    is a reminder that you should do


    after unpacking the mingwPORT.

  • dll: Contains one or more DLLs, and only DLLs. These packages are often listed as dependencies of other dll or bin packages. Keeping these packages limited to DLLs alone helps minimize the installation footprint of MinGW and MSYS components. Generally, these packages are the only ones to use the Component Version field, to help distinguish between library versions that provide (incompatible) ABIs. Often, these packages' Package Name will differ from that of the other (sub)packages derived from the same src, even when the Package Version, Package Build, and Subsystem Name are otherwise identical; in these cases, the Package Name of the dll package is patterned after the name of the actual DLL provided. This helps when identifying dependencies between (other) packages.
  • src: This package provides the source code used to create all of the other associated (sub)packages. If the installed packages are created from unmodified upstream source code, using a standard configure --prefix= --host= && make && make install procedure, then this package can simply be a renamed version of the upstream source "tarball" AND the Subsystem Name may be ommitted. That is
    cp foo-1.0.0.tar.gz foo-1.0.0-1-src.tar.gz

    However, if the source as built differs at all from that provided by the upstream project, then it is recommended to structure the src package as a "tarball within a tarball", as follows:

    foo-1.0.0-1-msys-src.tar.lzma contains:
        foo-1.0.0.tar.gz (upstream source tarball) (or similar. Basically, a build script. Debian fans use a GNUMakefile)

    where the build script can automatically unpack the "inner" tarball, apply the associated patches, and drive the configure/build process. For extra credit, the build script could also make install --prefix=/tmp/prefix and create the associated bin (and doc, and dev, etc) packages. For those familiar with the mingwPORT system, an alternative src structure is

    foo-1.0.0-1-mingw32-src.tar.lzma contains:
        foo-1.0.0.tar.gz (upstream source tarball)
        foo-1.0.0-1-mingwPORT-sh.tar.gz (the mingwPORT bundle)

    To use this variant, one would unpack the "outer" tarball, unpack the inner mingwPORT, and then run the script after changing the current directory to foo-1.0.0/mingwPORT/. Packagers should take care to ensure that the distributed foo-1.0.0/mingwPORT/mingwPORT.ini contains appropriate defaults. Because mingwPORTs are specifically designed to automate repeatable builds of mingw32 packages (or possibly, mingw64 ones), this src variant is useful only for package sets whose Subsystem Name is mingw32 (or possibly, mingw64).

  • ext: Anything that doesn't fit in the other categories.

Component Version

In most cases, packages whose Component Type is dll will also specify a numeric Component Version. Generally, dll packages contain a single DLL whose name is, for example, msys-intl-8.dll. The Component Version should match the version number of that DLL -- in this case, 8, as in libintl-*-msys-dll-8.tar.lzma.

Archive Format

Usually one of four values:

  • tar: Most common and recommended; this archive format is the lingua franca of the unix world. Tar archives distributed by the MinGW project should never contain hard links; this is to ensure that the archives may be unpacked by tools which do not understand those constructs, and to ensure that the distribution can be installed on FAT drives that do not support hardlinks. To ensure this, packagers should use the --hard-dereference option when generating archives for distribution. Tar archives with Subsystem Name mingw32 must not contain symbolic links; this is automatic when generating distributable installations from a "native" environment (that is, an MSYS environment in its normal, impersonate mingw32 personality). Packagers who use a cross-compile environment should take special care, and use the --dereference or -h option when generating archives for distribution.
  • zip: Discouraged. While .zip files are common on windows and implicitly supported by modern versions of the OS, most windows tools for manipulating .zip files do so in ways that can badly break a MinGW or MSYS installation. (In particular, many unzip tools automatically convert line endings from "unix" to "dos" format; this often has unforeseen, and quite unfortunate, results.)
  • exe: Self-extracting archives.
  • 7z: An inherently compressed multifile archive format. 7zip has good compression characteristics and the format is widely supported. However, it is still unfamiliar to many windows users. So far, only a few MinGW packages use this format.

Compression Type

For packages whose Archive Format is tar, one of several compression types is generally used:

  • lzma: Recommended for new packages. lzma is a relatively new compression format, similar to the compression scheme used in 7z archives. Very fast decompression; fairly slow compression but gives superior results to bz2 and gz. Performs very well on archives that contain multiple copies of large executables (as is the case when the tar file was created using --hard-dereference). Supported by current and future MinGW installers. Supported by the MSYS tar available as part of the core MSYS installation. NOT supported by the native GNU tar and bsdtar ports provided by the GnuWin32 project. The MinGW team intends soon to provide both native and msys ports of bsdtar that support this compression format.
  • bz2: Good compression, fairly common. Unfortunately, neither the built-in Windows Explorer archive facility, nor most common windows archive programs, support this format. It is, however, supported by the current and future MinGW installers, GnuWin32 GNU tar.exe, GnuWin32 bsdtar.exe, and the MSYS GNU tar available as part of the core MSYS installation. Does not perform well on archives that contain multiple copies of large executables (as is the case when the tar file was created using --hard-dereference).
  • gz: The most common compression format in the unix world. Supported by everything. Very fast decompression, but compression ratio is generally unimpressive. Does not perform well on archives that contain multiple copies of large executables (as is the case when the tar file was created using --hard-dereference).
  • xz: A refinement of the .lzma compression format provides a more robust file structure. Not yet supported by anything.

Automated Parser

To facilitate automatic machine parsed interpretation of package names, an automated parsing function has been developed, and will be deployed within the forthcoming mingw-get installation tool. This may also be deployed as a free standing command line tool, as an aid to validation and interpretation of package names; currently available as source code only, it may be found in the pkginfo subdirectory of the mingw-get CVS; (you will need both GCC and FLEX, to build pkginfo.exe from driver.c and pkginfo.l).

This wiki is not a forum for discussion of usage issues. Please use the list instead. We do not allow creation of comments by anonymous or untrusted users, on any page.
Site Status

Site maintenance performed successfully, site online Dec 13th 12:00 AM Eastern.