Cygwin Package Contributor's Guide

This document is intended for people who upload packages to sourceware.org, to be made available through the standard Cygwin setup program.

Contents

• Making a package with cygport
• Locally installing your package for testing
• Marking your package as a test version
• Submitting a package
• Updating or adopting an orphaned package
• Uploading a package
• Updating a package
• Historical packaging methods

Making a package with cygport

Suppose that the upstream's boffo-1.0.tar.xz source tar file, that you downloaded from the boffo homepage, unpacks into boffo-1.0/.

Further, suppose you've got boffo ported to Cygwin. It took some work, but you've got a patch file, which we will name boffo-1.0-fix-whatever.patch, and with that applied boffo builds and runs.

All that remains is to write a boffo.cygport file which will describe how to unpack, configure, build and package. See these examples for a quick introduction to these files.

# package name
NAME="boffo"
VERSION=1.0
RELEASE=1

# package metadata
CATEGORY="Games"
SUMMARY="A whackamole simulation in ASCII art"
DESCRIPTION="A whackamole simulation in ASCII art.
Intended for use on VT100 terminals at BAUD rates 1200 and
above.  Uses arrow keys for positioning over moles.  Space
bar whacks the mole.
No actual moles will be harmed during execution of this game."
HOMEPAGE="https://boffo.org"
LICENSE="BSD-3-Clause"

# source and patch files
SRC_URI="https://boffo.org/downloads/boffo-${VERSION}.tar.xz"
PATCH_URI="boffo-1.0-fix-whatever.patch"

# use the standard autotools src_compile, src_install and src_test

The source and binary packages can then be built and metadata .hint files generated by running cygport, e.g.

$ cygport boffo.cygport download
--2017-04-01 11:59:59--  https://boffo.org/downloads/boffo-1.0.tar.xz
Resolving boffo.org... 203.0.113.1
Connecting to boffo.org|203.0.113.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 352 [application/x-tar]
Saving to: ‘boffo-1.0.tar.xz.tmp’

boffo-1.0.tar.xz.tmp 100%[===================>]     352  --.-KB/s    in 0s

2017-04-01 11:59:59 (8.06 MB/s) - ‘boffo-1.0.tar.xz.tmp’ saved [352/352]

$ cygport boffo.cygport all
>>> Preparing boffo-1.0-1.x86_64
>>> Unpacking source boffo-1.0.tar.xz
*** Info: applying patch boffo-1.0-fix-whatever.patch:
>>> Preparing working source directory
>>> Compiling boffo-1.0-1.x86_64
[...]
>>> Installing boffo-1.0-1.x86_64
[...]
Fixing symlinks:
Stripping executables:
        usr/bin/boffo.exe
Preparing debuginfo source files:
        1 files
>>> Packaging boffo-1.0-1.x86_64
>>> Creating binary package(s)
>>> boffo-1.0-1.tar.xz
usr/
usr/bin/
usr/bin/boffo.exe
usr/lib/
usr/share/
usr/share/doc/
usr/share/doc/boffo/
usr/share/doc/boffo/README

>>> boffo-debuginfo-1.0-1.tar.xz
usr/lib/debug/
usr/lib/debug/usr/
usr/lib/debug/usr/bin/
usr/lib/debug/usr/bin/boffo.exe.dbg
usr/src/debug/
usr/src/debug/boffo-1.0-1/
usr/src/debug/boffo-1.0-1/boffo.c

>>> Checking packages for missing or duplicate files

>>> Creating source patches
 0 files changed
>>> Creating source package
boffo-1.0-1.src/
boffo-1.0-1.src/boffo-1.0-fix-whatever.patch
boffo-1.0-1.src/boffo-1.0.tar.xz
boffo-1.0-1.src/boffo.cygport

>>> boffo requires: cygwin libncursesw10

For more information on using cygport consult the man page, README, reference manual, cygport tips page and sample .cygport files.

The cygport file for any existing cygwin package can be found in /usr/src/package_name after installing the source package, or in the packaging repositories.

• For simple packages you can fake installation by directly untarring the package file and then running any postinstall scripts manually:

        $ tar -C / -xvf boffo-1.0-1.x86_64/dist/boffo/boffo-1.0-1.tar.xz
        $ /etc/postinstall/boffo.sh

• For multiple packages with complex dependencies, you can use an overlay package server. Note that setup can accept paths and file:// URLs so an FTP or HTTP server is not necessary.

Marking your package as a test version

Submitting a new package

So you've got a package you want to submit. Follow the following checklist before emailing the cygwin-apps mailing list, and you'll almost certainly save time.

• Do you have the time to maintain the package?

  Packages without an active maintainer may be pulled from the distribution. Generally speaking the time commitment is relatively low, simply subscribe to the cygwin mailing list. When a bug in your package is reported in the cygwin mailing list, address the bug (if it's a Cygwin-only bug) or pass back to the upstream. When a solution exists, create and upload an updated package with the fix in it. Note that you are not expected to be a helpdesk for the package - the users should be pointed upstream if you've determined that the bug is not a Cygwin-related bug.

• Propose on the cygwin-apps mailing list that you are interested in becoming a package maintainer for package "foo" using a subject like "[ITP] foo 0.10".

  Submission rules:
  
  • If the new package is already included in a major Linux distribution (e.g. Debian, Fedora, SuSE) please mention that.
  • If the package is not included in any major Linux distro it must receive five positive votes from other package maintainers in order to be accepted.
  • Mention which open source license applies to the source.
  • We generally follow Fedora guidelines on what packages can be accepted, which excludes content which potentially infringes on patents or trademarks, or is illegal or offensive.

• Write good package metadata

  • In order to select an appropriate a correct category you can look in e.g. the Debian package list and identify the section that your package is present in there - if it's available via Debian. If it's not, have a look and take a sensible guess. Use existing categories if at all possible.
  • Do not use the package name in sdesc, as it is added automatically by the setup program.
• If the package has a test-suite, run cygport test and note the results: success, or failures you have determined are not significant.

• If at all possible, build the package and place the package files on a publicly accessible HTTP/FTP site, and provide the URL in your mail.

• There is no need to increase the release number if the package has not been officially released. So, if you are releasing a -1 release of a package keep using -1 for any refinements until the package has been uploaded.
• Each new package must in any case receive one GTG vote from a package maintainer, meaning that an existing maintainer has downloaded the package, inspected the tar file contents, tested the applications, and rebuilt the package from the source tar file without incident. Once a successful package is produced, you become a maintainer yourself and can provide GTG reviews for others as well.

Updating or adopting an orphaned package

Unfortunately some packages are without a maintainer, and volunteers to take over are welcome.

• Find the appropriate source package in the source package list.
• The package summary page should link to the packaging git repository, containing the .cygport and patch files. git clone that repository from the listed URL (for some older packages, this repository may not exist yet, in which case, install the source package using setup instead).
• Edit the .cygport file to adjust the version appropriately.
• cygport package.cygport download all check
• Hopefully it all 'just works', but maybe there are some problems to fix! (Consider looking at e.g. upstream bug reports and fixes, and patches applied in Linux distributions to avoid duplicating effort).

• email the cygwin-apps mailing list, as in submitting a new package, except use "[ITA]" rather than "[ITP]" in the subject.

  Even if you don't wish to become a maintainer, sharing your updated cygport with the cygwin-apps list, and a report of success or failure is helpful.

Uploading a package

• Once you have your GTG, follow the instructions for submitting a ssh key.
• either
  • Upload your package files.
  • Please remember to build and upload packages for all architectures (only x86_64 currently).
  • Feel free to delete your local copy once the files have been uploaded to sourceware.org.

  or

  • push to the packaging git repository with '--push-option=deploy', which will cause packages to be built and uploaded for you.

• Announce via the cygwin-announce mailing list that the new package is available. See the announce message template later in this page.

• If you encounter any problems, email the cygwin-apps mailing list.

Updating a package

So you've got an updated package. You should already have upload privileges, and should be able to do the entire process yourself.

• You must increase the version or release number. Reset the release number to 1 on a version increase.
• Follow the steps to upload, as above.

Composing an announcement mail

cygport announce can help you compose and send an announcement mail, based on the following template.

Be sure the unsubscribe instructions are included at the end of the email, since cygwin-announce does not add any.

Once sent, your message will be reviewed by one of the cygwin-announce moderators and, once approved, will be automatically forwarded to the cygwin mailing list with [ANNOUNCEMENT] prepended to the subject.

Historical packaging methods

The cygport framework improves on previous Cygwin build scripts.