App-DocKnot

 view release on metacpan or  search on metacpan

lib/App/DocKnot/Spin/Text.pm  view on Meta::CPAN

            $INDENT = indent $_;
            s%(\n\s*\S)%<br />$1%g if ($broken || $contents);
            $self->_output(start($INDENT, 'ol'));
            $self->_output(li($INDENT, p(_format_bold($_)), $number));
            next;
        }

        # Check for things that look like description lists and handle them.
        # Note that we don't allow indented description lists, because they're
        # usually something we actually want to make <pre>.  This is another
        # fairly fragile heuristic.
        if (_is_description ($_) && defined $INDENT) {
            my (@title, $body);
            ($title[0], $body) = split ("\n", $_, 2);
            my ($space) = ($title[0] =~ /^(\s*)/);
            while ($body =~ /^$space\S/) {
                my $title;
                ($title, $body) = split ("\n", $body, 2);
                push (@title, $title);
            }
            if ($indent == $INDENT || indent ($body) == $INDENT) {

t/data/generate/control-archive/docknot.yaml  view on Meta::CPAN

      title: export-control manual page
    - name: generate-files
      title: generate-files manual page
    - name: process-control
      title: process-control manual page
    - name: update-control
      title: update-control manual page

blurb: |
  This software generates an INN control.ctl configuration file from
  hierarchy configuration fragments, verifies control messages using GnuPG
  where possible, processes new control messages to update a newsgroup list,
  archives new control messages, and exports the list of newsgroups in a
  format suitable for synchronizing the newsgroup list of a Netnews news
  server.  It is the software that maintains the control message and
  newsgroup lists available from ftp.isc.org.

description: |
  This package contains three major components:

  * All of the configuration used to generate a `control.ctl` file for INN

t/data/generate/control-archive/docknot.yaml  view on Meta::CPAN

      changes, the second number will be incremented for any change to the
      code or functioning of the software.  A change to the third part of
      the version number indicates a release with changes only to the
      configuration, PGP keys, and documentation files.
  - title: Layout
    body: |
      The configuration data is in one file per hierarchy in the `config`
      directory.  Each file has the format specified in FORMAT and is
      designed to be readable by INN's new configuration parser in case
      this can be further automated down the road.  The `config/special`
      directory contains overrides, raw `control.ctl` fragments that
      should be used for particular hierarchies instead of
      automatically-generated entries (usually for special comments).
      Eventually, the format should be extended to handle as many of these
      cases as possible.

      The `keys` directory contains the PGP public keys for every
      hierarchy that has one.  The user IDs on these keys must match the
      signer expected by the configuration data for the corresponding
      hierarchy.

t/data/generate/control-archive/docknot.yaml  view on Meta::CPAN

         download tool that understands FTP, such as wget, but please use
         the options that add delays and don't hammer the server to death.

      After finishing those steps, you will have a copy of the ftp.isc.org
      archive and can start processing control messages, possibly with
      different configuration choices.  You can generate the files that
      are found in ftp://ftp.isc.org/pub/usenet/CONFIG/ by running
      `scripts/export-control` as described above.
  - title: Maintenance
    body: |
      To add a new hierarchy, add a configuration fragment in the `config`
      directory named after the hierarchy, following the format of the
      existing files, and run `scripts/generate-files` to create a new
      `control.ctl` file.  See the documentation in
      `scripts/generate-files` for details about the supported
      configuration keys.

      If the hierarchy uses PGP-signed control messages, also put the PGP
      key into the `keys` directory in a file named after the hierarchy.
      Then, run:

t/data/generate/control-archive/output/readme  view on Meta::CPAN

               Maintained by Russ Allbery <eagle@eyrie.org>

  Copyright 2002-2004, 2007-2014, 2016-2018 Russ Allbery
  <eagle@eyrie.org>.  Copyright 2001 Marco d'Itri.  Copyright 1996 UUNET
  Technologies, Inc..  This software is distributed under a BSD-style
  license.  Please see the section LICENSE below for more information.

BLURB

  This software generates an INN control.ctl configuration file from
  hierarchy configuration fragments, verifies control messages using GnuPG
  where possible, processes new control messages to update a newsgroup
  list, archives new control messages, and exports the list of newsgroups
  in a format suitable for synchronizing the newsgroup list of a Netnews
  news server.  It is the software that maintains the control message and
  newsgroup lists available from ftp.isc.org.

DESCRIPTION

  This package contains three major components:

t/data/generate/control-archive/output/readme  view on Meta::CPAN

  software.  A change to the third part of the version number indicates a
  release with changes only to the configuration, PGP keys, and
  documentation files.

LAYOUT

  The configuration data is in one file per hierarchy in the config
  directory.  Each file has the format specified in FORMAT and is designed
  to be readable by INN's new configuration parser in case this can be
  further automated down the road.  The config/special directory contains
  overrides, raw control.ctl fragments that should be used for particular
  hierarchies instead of automatically-generated entries (usually for
  special comments).  Eventually, the format should be extended to handle
  as many of these cases as possible.

  The keys directory contains the PGP public keys for every hierarchy that
  has one.  The user IDs on these keys must match the signer expected by
  the configuration data for the corresponding hierarchy.

  The forms directory contains the basic file structure for the three
  generated files.

t/data/generate/control-archive/output/readme  view on Meta::CPAN

     that add delays and don't hammer the server to death.

  After finishing those steps, you will have a copy of the ftp.isc.org
  archive and can start processing control messages, possibly with
  different configuration choices.  You can generate the files that are
  found in ftp://ftp.isc.org/pub/usenet/CONFIG/ by running
  scripts/export-control as described above.

MAINTENANCE

  To add a new hierarchy, add a configuration fragment in the config
  directory named after the hierarchy, following the format of the
  existing files, and run scripts/generate-files to create a new
  control.ctl file.  See the documentation in scripts/generate-files for
  details about the supported configuration keys.

  If the hierarchy uses PGP-signed control messages, also put the PGP key
  into the keys directory in a file named after the hierarchy.  Then, run:

      gpg --homedir=keyring --import keys/<hierarchy>

t/data/generate/control-archive/output/readme-md  view on Meta::CPAN

# control-archive

Copyright 2002-2004, 2007-2014, 2016-2018 Russ Allbery <eagle@eyrie.org>.
Copyright 2001 Marco d'Itri.  Copyright 1996 UUNET Technologies, Inc..
This software is distributed under a BSD-style license.  Please see the
section [License](#license) below for more information.

## Blurb

This software generates an INN control.ctl configuration file from
hierarchy configuration fragments, verifies control messages using GnuPG
where possible, processes new control messages to update a newsgroup list,
archives new control messages, and exports the list of newsgroups in a
format suitable for synchronizing the newsgroup list of a Netnews news
server.  It is the software that maintains the control message and
newsgroup lists available from ftp.isc.org.

## Description

This package contains three major components:

t/data/generate/control-archive/output/readme-md  view on Meta::CPAN

incremented for any change to the code or functioning of the software.  A
change to the third part of the version number indicates a release with
changes only to the configuration, PGP keys, and documentation files.

## Layout

The configuration data is in one file per hierarchy in the `config`
directory.  Each file has the format specified in FORMAT and is designed
to be readable by INN's new configuration parser in case this can be
further automated down the road.  The `config/special` directory contains
overrides, raw `control.ctl` fragments that should be used for particular
hierarchies instead of automatically-generated entries (usually for
special comments).  Eventually, the format should be extended to handle as
many of these cases as possible.

The `keys` directory contains the PGP public keys for every hierarchy that
has one.  The user IDs on these keys must match the signer expected by the
configuration data for the corresponding hierarchy.

The `forms` directory contains the basic file structure for the three
generated files.

t/data/generate/control-archive/output/readme-md  view on Meta::CPAN

   that add delays and don't hammer the server to death.

After finishing those steps, you will have a copy of the ftp.isc.org
archive and can start processing control messages, possibly with different
configuration choices.  You can generate the files that are found in
ftp://ftp.isc.org/pub/usenet/CONFIG/ by running `scripts/export-control`
as described above.

## Maintenance

To add a new hierarchy, add a configuration fragment in the `config`
directory named after the hierarchy, following the format of the existing
files, and run `scripts/generate-files` to create a new `control.ctl`
file.  See the documentation in `scripts/generate-files` for details about
the supported configuration keys.

If the hierarchy uses PGP-signed control messages, also put the PGP key
into the `keys` directory in a file named after the hierarchy.  Then, run:

```sh
    gpg --homedir=keyring --import keys/<hierarchy>

t/data/generate/control-archive/output/thread  view on Meta::CPAN

         [GitHub] \break
    \link[https://github.com/rra/control-archive/issues]
         [Bug tracker] \break
    \link[https://git.eyrie.org/?p=usenet/control.archive.git]
         [Git repository] \break
]

\h2[Blurb]

This software generates an INN control.ctl configuration file from
hierarchy configuration fragments, verifies control messages using GnuPG
where possible, processes new control messages to update a newsgroup list,
archives new control messages, and exports the list of newsgroups in a
format suitable for synchronizing the newsgroup list of a Netnews news
server.  It is the software that maintains the control message and
newsgroup lists available from ftp.isc.org.

\h2[Description]

This package contains three major components:

t/data/generate/rra-c-util/docknot.yaml  view on Meta::CPAN

        build `libutil.la` and change some of the Automake variables.

      * If your package uses a TAP-based test suite written in C, consider
        using the additional TAP utility functions in `tests/tap`
        (specifically `messages.*`, `process.*`, and `string.*`).

      * If you're using the Kerberos portability code, copy over
        `portable/krb5.h`, `portable/krb5-extra.c`, `m4/krb5.m4`,
        `m4/lib-depends.m4`, `m4/lib-pathname.m4`, and optionally
        `util/messages-krb5.[ch]`.  You'll also need the relevant
        fragments of `configure.ac`.  You may want to remove some things
        from `krb5.h` and `krb5-extra.c` the corresponding configure
        checks if your code doesn't need all of those functions.  If you
        need `krb5_get_renewed_creds`, also copy over `krb5-renew.c`.
        Don't forget to add `$(KRB5_CPPFLAGS)` to `CPPFLAGS` for
        `libportable` and possibly `libutil`, and if you're building a
        shared library, also add `$(KRB5_LDFLAGS)` to `LDFLAGS` and
        `$(KRB5_LIBS)` to `LIBADD` for those libraries.

        For a Kerberos-enabled test suite, also consider copying the
        `kerberos.*` libraries in `tests/tap` for a Kerberos-enabled test

t/data/generate/rra-c-util/docknot.yaml  view on Meta::CPAN

      * For testing that requires making Kerberos administrative changes,
        consider copying over the `kadmin.*` libraries in `tests/tap`.

      * For testing packages that use remctl, see the `tests/tap/remctl.c`
        and `tests/tap/remctl.h` files for C tests and
        `tests/tap/remctl.sh` for shell scripts.

      * If you're using the kafs portability code, copy over the `kafs`
        directory, `m4/kafs.m4`, `m4/lib-pathname.m4`,
        `portable/k_haspag.c`, the code to build kafs from `Makefile.am`,
        and the relevant fragments of `configure.ac`.

      * If you're using the PAM portability code, copy over `pam-util/*`,
        `portable/pam*`, `m4/pam-const.m4`, and the relevant fragments of
        `configure.ac`.

      * Copy over any other Autoconf macros that you want to use in your
        package from the m4 directory.

      * Copy over any generic tests from `tests/docs` and `tests/perl`
        that are appropriate for your package.  If you use any of these,
        also copy over the `tests/tap/perl` directory and
        `tests/data/perl.conf` (and customize the latter for your
        package).

t/data/generate/rra-c-util/output/readme  view on Meta::CPAN

    shared library, you'll need to instead build libutil.la and change
    some of the Automake variables.

  * If your package uses a TAP-based test suite written in C, consider
    using the additional TAP utility functions in tests/tap (specifically
    messages.*, process.*, and string.*).

  * If you're using the Kerberos portability code, copy over
    portable/krb5.h, portable/krb5-extra.c, m4/krb5.m4, m4/lib-depends.m4,
    m4/lib-pathname.m4, and optionally util/messages-krb5.[ch].  You'll
    also need the relevant fragments of configure.ac.  You may want to
    remove some things from krb5.h and krb5-extra.c the corresponding
    configure checks if your code doesn't need all of those functions.  If
    you need krb5_get_renewed_creds, also copy over krb5-renew.c.  Don't
    forget to add $(KRB5_CPPFLAGS) to CPPFLAGS for libportable and
    possibly libutil, and if you're building a shared library, also add
    $(KRB5_LDFLAGS) to LDFLAGS and $(KRB5_LIBS) to LIBADD for those
    libraries.

    For a Kerberos-enabled test suite, also consider copying the
    kerberos.* libraries in tests/tap for a Kerberos-enabled test suite.

t/data/generate/rra-c-util/output/readme  view on Meta::CPAN

  * For testing that requires making Kerberos administrative changes,
    consider copying over the kadmin.* libraries in tests/tap.

  * For testing packages that use remctl, see the tests/tap/remctl.c and
    tests/tap/remctl.h files for C tests and tests/tap/remctl.sh for shell
    scripts.

  * If you're using the kafs portability code, copy over the kafs
    directory, m4/kafs.m4, m4/lib-pathname.m4, portable/k_haspag.c, the
    code to build kafs from Makefile.am, and the relevant fragments of
    configure.ac.

  * If you're using the PAM portability code, copy over pam-util/*,
    portable/pam*, m4/pam-const.m4, and the relevant fragments of
    configure.ac.

  * Copy over any other Autoconf macros that you want to use in your
    package from the m4 directory.

  * Copy over any generic tests from tests/docs and tests/perl that are
    appropriate for your package.  If you use any of these, also copy over
    the tests/tap/perl directory and tests/data/perl.conf (and customize
    the latter for your package).

t/data/generate/rra-c-util/output/readme-md  view on Meta::CPAN

  shared library, you'll need to instead build `libutil.la` and change
  some of the Automake variables.

* If your package uses a TAP-based test suite written in C, consider using
  the additional TAP utility functions in `tests/tap` (specifically
  `messages.*`, `process.*`, and `string.*`).

* If you're using the Kerberos portability code, copy over
  `portable/krb5.h`, `portable/krb5-extra.c`, `m4/krb5.m4`,
  `m4/lib-depends.m4`, `m4/lib-pathname.m4`, and optionally
  `util/messages-krb5.[ch]`.  You'll also need the relevant fragments of
  `configure.ac`.  You may want to remove some things from `krb5.h` and
  `krb5-extra.c` the corresponding configure checks if your code doesn't
  need all of those functions.  If you need `krb5_get_renewed_creds`, also
  copy over `krb5-renew.c`.  Don't forget to add `$(KRB5_CPPFLAGS)` to
  `CPPFLAGS` for `libportable` and possibly `libutil`, and if you're
  building a shared library, also add `$(KRB5_LDFLAGS)` to `LDFLAGS` and
  `$(KRB5_LIBS)` to `LIBADD` for those libraries.

  For a Kerberos-enabled test suite, also consider copying the
  `kerberos.*` libraries in `tests/tap` for a Kerberos-enabled test suite.

t/data/generate/rra-c-util/output/readme-md  view on Meta::CPAN

* For testing that requires making Kerberos administrative changes,
  consider copying over the `kadmin.*` libraries in `tests/tap`.

* For testing packages that use remctl, see the `tests/tap/remctl.c` and
  `tests/tap/remctl.h` files for C tests and `tests/tap/remctl.sh` for
  shell scripts.

* If you're using the kafs portability code, copy over the `kafs`
  directory, `m4/kafs.m4`, `m4/lib-pathname.m4`, `portable/k_haspag.c`,
  the code to build kafs from `Makefile.am`, and the relevant fragments of
  `configure.ac`.

* If you're using the PAM portability code, copy over `pam-util/*`,
  `portable/pam*`, `m4/pam-const.m4`, and the relevant fragments of
  `configure.ac`.

* Copy over any other Autoconf macros that you want to use in your package
  from the m4 directory.

* Copy over any generic tests from `tests/docs` and `tests/perl` that are
  appropriate for your package.  If you use any of these, also copy over
  the `tests/tap/perl` directory and `tests/data/perl.conf` (and customize
  the latter for your package).

t/data/update/control-archive/docknot.yaml  view on Meta::CPAN

---
blurb: |
  This software generates an INN control.ctl configuration file from
  hierarchy configuration fragments, verifies control messages using GnuPG
  where possible, processes new control messages to update a newsgroup list,
  archives new control messages, and exports the list of newsgroups in a
  format suitable for synchronizing the newsgroup list of a Netnews news
  server.  It is the software that maintains the control message and
  newsgroup lists available from ftp.isc.org.
build:
  install: false
  type: make
copyrights:
- holder: Russ Allbery <eagle@eyrie.org>

t/data/update/control-archive/docknot.yaml  view on Meta::CPAN

    similar disruptive changes.  For lesser changes, the second number will be
    incremented for any change to the code or functioning of the software.  A
    change to the third part of the version number indicates a release with
    changes only to the configuration, PGP keys, and documentation files.
  title: Versioning
- body: |
    The configuration data is in one file per hierarchy in the `config`
    directory.  Each file has the format specified in FORMAT and is designed
    to be readable by INN's new configuration parser in case this can be
    further automated down the road.  The `config/special` directory contains
    overrides, raw `control.ctl` fragments that should be used for particular
    hierarchies instead of automatically-generated entries (usually for
    special comments).  Eventually, the format should be extended to handle as
    many of these cases as possible.

    The `keys` directory contains the PGP public keys for every hierarchy that
    has one.  The user IDs on these keys must match the signer expected by the
    configuration data for the corresponding hierarchy.

    The `forms` directory contains the basic file structure for the three
    generated files.

t/data/update/control-archive/docknot.yaml  view on Meta::CPAN

       tool that understands FTP, such as wget, but please use the options
       that add delays and don't hammer the server to death.

    After finishing those steps, you will have a copy of the ftp.isc.org
    archive and can start processing control messages, possibly with different
    configuration choices.  You can generate the files that are found in
    ftp://ftp.isc.org/pub/usenet/CONFIG/ by running `scripts/export-control`
    as described above.
  title: Bootstrapping
- body: |
    To add a new hierarchy, add a configuration fragment in the `config`
    directory named after the hierarchy, following the format of the existing
    files, and run `scripts/generate-files` to create a new `control.ctl`
    file.  See the documentation in `scripts/generate-files` for details about
    the supported configuration keys.

    If the hierarchy uses PGP-signed control messages, also put the PGP key
    into the `keys` directory in a file named after the hierarchy.  Then, run:

    ```sh
        gpg --homedir=keyring --import keys/<hierarchy>

t/data/update/control-archive/old/blurb  view on Meta::CPAN

This software generates an INN control.ctl configuration file from
hierarchy configuration fragments, verifies control messages using GnuPG
where possible, processes new control messages to update a newsgroup list,
archives new control messages, and exports the list of newsgroups in a
format suitable for synchronizing the newsgroup list of a Netnews news
server.  It is the software that maintains the control message and
newsgroup lists available from ftp.isc.org.

t/data/update/control-archive/old/sections/layout  view on Meta::CPAN

The configuration data is in one file per hierarchy in the `config`
directory.  Each file has the format specified in FORMAT and is designed
to be readable by INN's new configuration parser in case this can be
further automated down the road.  The `config/special` directory contains
overrides, raw `control.ctl` fragments that should be used for particular
hierarchies instead of automatically-generated entries (usually for
special comments).  Eventually, the format should be extended to handle as
many of these cases as possible.

The `keys` directory contains the PGP public keys for every hierarchy that
has one.  The user IDs on these keys must match the signer expected by the
configuration data for the corresponding hierarchy.

The `forms` directory contains the basic file structure for the three
generated files.

t/data/update/control-archive/old/sections/maintenance  view on Meta::CPAN

To add a new hierarchy, add a configuration fragment in the `config`
directory named after the hierarchy, following the format of the existing
files, and run `scripts/generate-files` to create a new `control.ctl`
file.  See the documentation in `scripts/generate-files` for details about
the supported configuration keys.

If the hierarchy uses PGP-signed control messages, also put the PGP key
into the `keys` directory in a file named after the hierarchy.  Then, run:

```sh
    gpg --homedir=keyring --import keys/<hierarchy>

t/data/update/rra-c-util/docknot.yaml  view on Meta::CPAN

      shared library, you'll need to instead build `libutil.la` and change
      some of the Automake variables.

    * If your package uses a TAP-based test suite written in C, consider using
      the additional TAP utility functions in `tests/tap` (specifically
      `messages.*`, `process.*`, and `string.*`).

    * If you're using the Kerberos portability code, copy over
      `portable/krb5.h`, `portable/krb5-extra.c`, `m4/krb5.m4`,
      `m4/lib-depends.m4`, `m4/lib-pathname.m4`, and optionally
      `util/messages-krb5.[ch]`.  You'll also need the relevant fragments of
      `configure.ac`.  You may want to remove some things from `krb5.h` and
      `krb5-extra.c` the corresponding configure checks if your code doesn't
      need all of those functions.  If you need `krb5_get_renewed_creds`, also
      copy over `krb5-renew.c`.  Don't forget to add `$(KRB5_CPPFLAGS)` to
      `CPPFLAGS` for `libportable` and possibly `libutil`, and if you're
      building a shared library, also add `$(KRB5_LDFLAGS)` to `LDFLAGS` and
      `$(KRB5_LIBS)` to `LIBADD` for those libraries.

      For a Kerberos-enabled test suite, also consider copying the
      `kerberos.*` libraries in `tests/tap` for a Kerberos-enabled test suite.

t/data/update/rra-c-util/docknot.yaml  view on Meta::CPAN

    * For testing that requires making Kerberos administrative changes,
      consider copying over the `kadmin.*` libraries in `tests/tap`.

    * For testing packages that use remctl, see the `tests/tap/remctl.c` and
      `tests/tap/remctl.h` files for C tests and `tests/tap/remctl.sh` for
      shell scripts.

    * If you're using the kafs portability code, copy over the `kafs`
      directory, `m4/kafs.m4`, `m4/lib-pathname.m4`, `portable/k_haspag.c`,
      the code to build kafs from `Makefile.am`, and the relevant fragments of
      `configure.ac`.

    * If you're using the PAM portability code, copy over `pam-util/*`,
      `portable/pam*`, `m4/pam-const.m4`, and the relevant fragments of
      `configure.ac`.

    * Copy over any other Autoconf macros that you want to use in your
      package from the m4 directory.

    * Copy over any generic tests from `tests/docs` and `tests/perl` that are
      appropriate for your package.  If you use any of these, also copy over
      the `tests/tap/perl` directory and `tests/data/perl.conf` (and customize
      the latter for your package).

t/data/update/rra-c-util/old/sections/using-this-code  view on Meta::CPAN

  shared library, you'll need to instead build `libutil.la` and change
  some of the Automake variables.

* If your package uses a TAP-based test suite written in C, consider using
  the additional TAP utility functions in `tests/tap` (specifically
  `messages.*`, `process.*`, and `string.*`).

* If you're using the Kerberos portability code, copy over
  `portable/krb5.h`, `portable/krb5-extra.c`, `m4/krb5.m4`,
  `m4/lib-depends.m4`, `m4/lib-pathname.m4`, and optionally
  `util/messages-krb5.[ch]`.  You'll also need the relevant fragments of
  `configure.ac`.  You may want to remove some things from `krb5.h` and
  `krb5-extra.c` the corresponding configure checks if your code doesn't
  need all of those functions.  If you need `krb5_get_renewed_creds`, also
  copy over `krb5-renew.c`.  Don't forget to add `$(KRB5_CPPFLAGS)` to
  `CPPFLAGS` for `libportable` and possibly `libutil`, and if you're
  building a shared library, also add `$(KRB5_LDFLAGS)` to `LDFLAGS` and
  `$(KRB5_LIBS)` to `LIBADD` for those libraries.

  For a Kerberos-enabled test suite, also consider copying the
  `kerberos.*` libraries in `tests/tap` for a Kerberos-enabled test suite.

t/data/update/rra-c-util/old/sections/using-this-code  view on Meta::CPAN

* For testing that requires making Kerberos administrative changes,
  consider copying over the `kadmin.*` libraries in `tests/tap`.

* For testing packages that use remctl, see the `tests/tap/remctl.c` and
  `tests/tap/remctl.h` files for C tests and `tests/tap/remctl.sh` for
  shell scripts.

* If you're using the kafs portability code, copy over the `kafs`
  directory, `m4/kafs.m4`, `m4/lib-pathname.m4`, `portable/k_haspag.c`,
  the code to build kafs from `Makefile.am`, and the relevant fragments of
  `configure.ac`.

* If you're using the PAM portability code, copy over `pam-util/*`,
  `portable/pam*`, `m4/pam-const.m4`, and the relevant fragments of
  `configure.ac`.

* Copy over any other Autoconf macros that you want to use in your
  package from the m4 directory.

* Copy over any generic tests from `tests/docs` and `tests/perl` that are
  appropriate for your package.  If you use any of these, also copy over
  the `tests/tap/perl` directory and `tests/data/perl.conf` (and customize
  the latter for your package).